{"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\/es\/blog\/administrirovanie\/nb-iot-kak-on-rabotaet-chast-3-scef-edinoe-okno-dostupa-k-uslugam-operatora","title":{"rendered":"NB-IoT: \u00bfc\u00f3mo funciona? Parte 3: SCEF \u2013 una ventana \u00fanica de acceso a los servicios del operador","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b>En el art\u00edculo \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ru_mts\/blog\/431648\/\">NB-IoT: \u00bfc\u00f3mo funciona? Parte 2<\/a><\/noindex>\u00bb, al hablar sobre la arquitectura del n\u00facleo de paquetes de la red NB-IoT, mencionamos la aparici\u00f3n de un nuevo nodo SCEF. Explicamos en la tercera parte qu\u00e9 es y para qu\u00e9 sirve.<\/b><\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: \u00bfc\u00f3mo funciona? Parte 3: SCEF \u2013 una ventana \u00fanica de acceso a los servicios del operador\" src=\"\/wp-content\/uploads\/2019\/11\/95652a1e2bfce0589b51b106ebf6e64f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl crear un servicio M2M, los desarrolladores de aplicaciones se enfrentan a las siguientes preguntas:<\/p>\n<ul>\n<li>\u00bfc\u00f3mo identificar los dispositivos;<\/li>\n<li>\u00bfqu\u00e9 algoritmo utilizar para verificar y confirmar la autenticidad;<\/li>\n<li>\u00bfqu\u00e9 protocolo de transporte elegir para interactuar con los dispositivos;<\/li>\n<li>\u00bfc\u00f3mo garantizar la entrega de datos a los dispositivos;<\/li>\n<li>\u00bfc\u00f3mo organizar y establecer reglas para el intercambio de datos con ellos;<\/li>\n<li>\u00bfc\u00f3mo controlar y obtener informaci\u00f3n sobre su estado en tiempo real;<\/li>\n<li>\u00bfc\u00f3mo entregar datos simult\u00e1neamente a un grupo de sus dispositivos;<\/li>\n<li>\u00bfc\u00f3mo enviar datos simult\u00e1neamente desde un dispositivo a varios clientes;<\/li>\n<li>\u00bfc\u00f3mo obtener acceso unificado a los servicios adicionales del operador para gestionar su dispositivo. <\/li>\n<\/ul>\n<p>\nPara resolver estas cuestiones, es necesario crear soluciones t\u00e9cnicas propietarias \u00abpesadas\u00bb, lo que lleva a un aumento en el esfuerzo y el tiempo de comercializaci\u00f3n de los servicios. Aqu\u00ed es donde el nuevo nodo SCEF viene al rescate.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Seg\u00fan la definici\u00f3n de 3GPP, SCEF (funci\u00f3n de exposici\u00f3n de capacidades de servicio) es un nuevo componente de la arquitectura 3GPP, cuya funci\u00f3n es exponer de manera segura los servicios y capacidades proporcionados por las interfaces de red 3GPP a trav\u00e9s de API. <\/p>\n<p>En t\u00e9rminos sencillos, SCEF es un intermediario entre la red y el servidor de aplicaciones (application server \u2014 AS), una \u00fanica ventana de acceso a los servicios del operador para gestionar su dispositivo M2M en la red NB-IoT a trav\u00e9s de una interfaz API estandarizada e intuitiva.<\/p>\n<p>SCEF oculta la complejidad de la red del operador, permitiendo a los desarrolladores de aplicaciones abstraerse de los mec\u00e1nicos espec\u00edficos complejos de interacci\u00f3n con los dispositivos.<\/p>\n<p>Mediante la transformaci\u00f3n de los protocolos de red en una interfaz API familiar para los desarrolladores de aplicaciones, SCEF facilita la creaci\u00f3n de nuevos servicios y reduce el tiempo de comercializaci\u00f3n. Adem\u00e1s, el nuevo nodo incluye funciones de identificaci\u00f3n\/autenticaci\u00f3n de dispositivos m\u00f3viles y establece reglas para el intercambio de datos entre el dispositivo y el AS, aliviando a los desarrolladores de aplicaciones de la necesidad de implementar estas funciones en su lado, delegando estas responsabilidades al operador.<\/p>\n<p>SCEF agrupa las interfaces necesarias para la autenticaci\u00f3n y autorizaci\u00f3n de los servidores de aplicaciones, el mantenimiento de la movilidad de UE, la transmisi\u00f3n de datos y el disparo de dispositivos, as\u00ed como el acceso a servicios adicionales y funciones de la red del operador.<\/p>\n<p>Hacia AS va una \u00fanica interfaz T8, la interfaz API (HTTP\/JSON), estandarizada por 3GPP. Todas las interfaces, excepto T8, operan sobre el protocolo DIAMETER (ver Figura 1).<\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: \u00bfc\u00f3mo funciona? Parte 3: SCEF \u2013 una ventana \u00fanica de acceso a los servicios del operador\" src=\"\/wp-content\/uploads\/2019\/11\/6538d7d9e0d94244e6415b78f080b159.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nT6a es la interfaz entre SCEF y MME. Se utiliza para procedimientos de gesti\u00f3n de movilidad\/sesi\u00f3n, transmisi\u00f3n de datos no IP, aprovisionamiento de eventos de monitoreo y recepci\u00f3n de informes sobre los mismos.<\/p>\n<p>S6t es la interfaz entre SCEF y HSS. Es necesaria para la autenticaci\u00f3n del abonado, la autorizaci\u00f3n de los servidores de aplicaciones, la obtenci\u00f3n del v\u00ednculo ID externo y IMSI\/MSISDN, el aprovisionamiento de eventos de monitoreo y la recepci\u00f3n de informes sobre los mismos.<\/p>\n<p>S6m\/T4 son las interfaces de SCEF a HSS y SMS-C (en 3GPP se define el nodo MTC-IWF, que se utiliza para disparar dispositivos y enviar SMS en redes NB-IoT. Sin embargo, en todas las implementaciones, la funcionalidad de este nodo est\u00e1 integrada en SCEF, por lo que para simplificar el diagrama no lo consideraremos por separado). Se utilizan para obtener informaci\u00f3n de ruta para el env\u00edo de SMS e interacci\u00f3n con el centro de SMS.<\/p>\n<p>T8 es la interfaz API de interacci\u00f3n entre SCEF y los servidores de aplicaciones. A trav\u00e9s de esta interfaz se transmiten tanto comandos de control como tr\u00e1fico.<\/p>\n<p>*en realidad hay m\u00e1s interfaces, aqu\u00ed solo se enumeran las m\u00e1s b\u00e1sicas. La lista completa se presenta en 3GPP 23.682 (4.3.2 Lista de Puntos de Referencia).<\/p>\n<p>A continuaci\u00f3n se presentan las funciones y servicios clave de SCEF:<\/p>\n<ul>\n<li>vinculaci\u00f3n del identificador de tarjeta SIM (IMSI) a ID externo; <\/li>\n<li>transmisi\u00f3n de tr\u00e1fico no IP (Non-IP Data Delivery, NIDD);<\/li>\n<li>operaciones grupales, utilizando ID de grupo externo;<\/li>\n<li>soporte para el modo de transmisi\u00f3n de datos con confirmaci\u00f3n;<\/li>\n<li>almacenamiento en b\u00fafer de datos MO (Mobile Originated) y MT (Mobile Terminated);<\/li>\n<li>autenticaci\u00f3n y autorizaci\u00f3n de dispositivos y servidores de aplicaciones;<\/li>\n<li>uso simult\u00e1neo de los datos de un \u00fanico UE por m\u00faltiples AS;<\/li>\n<li>soporte para funciones especiales de control del estado de UE (MONTE \u2013 Monitoring Events);<\/li>\n<li>disparo de dispositivos;<\/li>\n<li>provisi\u00f3n de roaming de datos no IP.<\/li>\n<\/ul>\n<p>\nEl principio fundamental de interacci\u00f3n entre AS y SCEF se basa en el esquema de las llamadas suscripciones. Cuando se necesita acceder a alg\u00fan servicio SCEF para un UE espec\u00edfico, el servidor de aplicaciones debe crear una suscripci\u00f3n enviando un comando espec\u00edfico a la API del servicio solicitado y recibir a cambio un identificador \u00fanico. A partir de ah\u00ed, todas las acciones y comunicaciones con el UE en el marco de este servicio se llevar\u00e1n a cabo utilizando este identificador.<\/p>\n<p><b>External ID: identificador universal del dispositivo<\/b><\/p>\n<p>Uno de los cambios m\u00e1s importantes en el esquema de interacci\u00f3n entre AS y los dispositivos al trabajar a trav\u00e9s de SCEF es la aparici\u00f3n del identificador universal. Ahora, en lugar del n\u00famero de tel\u00e9fono (MSISDN) o la direcci\u00f3n IP, como ocurr\u00eda en las antiguas redes 2G\/3G\/LTE, el identificador del dispositivo para el servidor de aplicaciones se convierte en \"external ID\". Este est\u00e1 definido por el est\u00e1ndar en un formato familiar para los desarrolladores de aplicaciones \"@\".<\/p>\n<p>Los desarrolladores ya no necesitan implementar algoritmos de autenticaci\u00f3n de dispositivos, la red asume completamente esta funci\u00f3n. El external ID se vincula al IMSI, y el desarrollador puede estar seguro de que al dirigirse a un external ID espec\u00edfico, est\u00e1 interactuando con una tarjeta SIM concreta. Al utilizar un chip SIM, se crea una situaci\u00f3n \u00fanica en la que el external ID identifica de manera inequ\u00edvoca un dispositivo espec\u00edfico.<\/p>\n<p>Adem\u00e1s, a un IMSI se le pueden vincular varios external ID, lo que genera una situaci\u00f3n a\u00fan m\u00e1s interesante, donde el external ID identifica claramente una aplicaci\u00f3n espec\u00edfica que es responsable de un servicio en un dispositivo concreto.<\/p>\n<p>Tambi\u00e9n aparece un identificador grupal: external group ID, que incluye un conjunto de external ID individuales. Ahora, con un solo requerimiento al SCEF, AS puede iniciar operaciones grupales: enviar datos o comandos de control a m\u00faltiples dispositivos, agrupados en una \u00fanica l\u00f3gica.<\/p>\n<p>Debido a que para los desarrolladores, la transici\u00f3n al nuevo identificador de dispositivo no puede ser instant\u00e1nea, SCEF ha dejado la posibilidad de comunicaci\u00f3n entre AS y UE a trav\u00e9s del n\u00famero est\u00e1ndar: MSISDN.<\/p>\n<p><b>Transmisi\u00f3n de tr\u00e1fico non-IP (Non-IP Data Delivery, NIDD)<\/b><\/p>\n<p>En NB-IoT, como parte de la optimizaci\u00f3n de los mecanismos de transmisi\u00f3n de peque\u00f1os vol\u00famenes de datos, adem\u00e1s de los tipos de PDN ya existentes, como IPv4, IPv6 y IPv4v6, ha aparecido otro tipo: non-IP. En este caso, al dispositivo (UE) no se le asigna una direcci\u00f3n IP, y los datos se transmiten sin utilizar el protocolo IP. El tr\u00e1fico para estas conexiones puede ser enrutado de dos maneras: la cl\u00e1sica \u2014 MME -&gt; SGW -&gt; PGW y luego a trav\u00e9s del t\u00fanel PtP hasta AS (fig. 2) o utilizando SCEF (fig. 3). <\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: \u00bfc\u00f3mo funciona? Parte 3: SCEF \u2013 una ventana \u00fanica de acceso a los servicios del operador\" src=\"\/wp-content\/uploads\/2019\/11\/557caf393c9da84fc635c57bb5ecf4a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl m\u00e9todo cl\u00e1sico no presenta ventajas significativas sobre el tr\u00e1fico IP, salvo la reducci\u00f3n del tama\u00f1o de los paquetes transmitidos gracias a la ausencia de encabezados IP. El uso de SCEF, por su parte, abre una serie de nuevas posibilidades y simplifica considerablemente los procedimientos de interacci\u00f3n con los dispositivos.<\/p>\n<p>Al transferir datos a trav\u00e9s de SCEF, surgen dos ventajas muy importantes sobre el tr\u00e1fico IP cl\u00e1sico: <\/p>\n<p><u>\u2022 Entrega de tr\u00e1fico MT al dispositivo mediante ID externo.<\/u><\/p>\n<p>Para enviar un mensaje a un dispositivo IP cl\u00e1sico, AS debe conocer su direcci\u00f3n IP. Aqu\u00ed surge el problema: dado que el dispositivo normalmente recibe una direcci\u00f3n IP 'gris' al registrarse, se comunica con el servidor de aplicaciones ubicado en Internet a trav\u00e9s de un nodo NAT, donde se transforma la direcci\u00f3n gris en blanca. La asociaci\u00f3n de direcciones IP grises y blancas dura un tiempo limitado, dependiendo de la configuraci\u00f3n del NAT. En promedio, para TCP o UDP, no m\u00e1s de cinco minutos. Es decir, si durante 5 minutos no ha habido intercambio de datos con este dispositivo, la asociaci\u00f3n se romper\u00e1 y el dispositivo dejar\u00e1 de ser accesible a trav\u00e9s de la direcci\u00f3n blanca con la cual se inici\u00f3 la sesi\u00f3n con AS. Hay varias soluciones: <\/p>\n<p>1. Usar heartbeat. Una vez establecida la conexi\u00f3n, el dispositivo debe intercambiar paquetes con AS cada pocos minutos, evitando as\u00ed que se cierre la traducci\u00f3n en el NAT. Pero aqu\u00ed no puede haber ninguna consideraci\u00f3n sobre la eficiencia energ\u00e9tica. <\/p>\n<p>2. Cada vez que sea necesario, verificar la existencia de paquetes para el dispositivo en AS \u2014 enviar un mensaje en uplink.<\/p>\n<p>3. Crear un APN privado (VRF), donde el servidor de aplicaciones y los dispositivos se encuentren en la misma subred, y asignar direcciones IP est\u00e1ticas a los dispositivos. Esto funcionar\u00e1, pero es casi irrealizable cuando se trata de un parque de miles o decenas de miles de dispositivos.<\/p>\n<p>4. Finalmente, la opci\u00f3n m\u00e1s adecuada es utilizar IPv6, ya que no requiere NAT, dado que las direcciones IPv6 son accesibles directamente desde Internet. Sin embargo, incluso en este caso, al reenviar el dispositivo, obtendr\u00e1 una nueva direcci\u00f3n IPv6 y ya no ser\u00e1 accesible a trav\u00e9s de la anterior. <\/p>\n<p>Por lo tanto, es necesario enviar un paquete de inicializaci\u00f3n con el identificador del dispositivo al servidor para notificar la nueva direcci\u00f3n IP del dispositivo. Luego, se debe esperar a que llegue un paquete de confirmaci\u00f3n de AS, lo que tambi\u00e9n afecta la eficiencia energ\u00e9tica.<\/p>\n<p>Estos m\u00e9todos funcionan bien para dispositivos 2G\/3G\/LTE, donde no se establecen requisitos estrictos de autonom\u00eda y, como consecuencia, no hay restricciones en el tiempo en el aire y el tr\u00e1fico. Para NB-IoT, estos m\u00e9todos no son adecuados debido a su alto consumo de energ\u00eda.<\/p>\n<p>SCEF resuelve este problema: dado que el \u00fanico identificador del dispositivo para AS es el ID externo, AS solo necesita enviar un paquete de datos a SCEF para un ID externo espec\u00edfico, y SCEF se encargar\u00e1 del resto. En caso de que el dispositivo est\u00e9 en modo de ahorro de energ\u00eda PSM o eDRX, los datos se almacenar\u00e1n en b\u00fafer y se entregar\u00e1n cuando el dispositivo est\u00e9 disponible. Si el dispositivo est\u00e1 disponible para el tr\u00e1fico, los datos se entregar\u00e1n de inmediato. Esto tambi\u00e9n se aplica a los comandos de control.<\/p>\n<p>En cualquier momento, AS puede revocar un mensaje almacenado en b\u00fafer hacia UE o reemplazarlo por uno nuevo.<\/p>\n<p>El mecanismo de almacenamiento en b\u00fafer tambi\u00e9n puede aplicarse cuando se transmiten datos MO desde UE hacia AS. Si SCEF no pudo entregar los datos a AS de inmediato, por ejemplo, debido a trabajos de mantenimiento en los servidores de AS, esos paquetes se almacenar\u00e1n en b\u00fafer y se entregar\u00e1n garantizados tan pronto como AS est\u00e9 disponible.<\/p>\n<p>Como se mencion\u00f3 anteriormente, el acceso a un servicio espec\u00edfico y a UE para AS (y NIDD es un servicio) est\u00e1 regulado por reglas y pol\u00edticas del lado de SCEF, lo que permite implementar una funcionalidad \u00fanica de uso simult\u00e1neo de los datos de un solo UE por m\u00faltiples AS. Es decir, si varios AS se han suscrito a un UE, despu\u00e9s de recibir datos de UE, SCEF enviar\u00e1 esa informaci\u00f3n a todos los AS suscritos. Esto es muy adecuado para casos en los que el creador de un parque de dispositivos especializados comparte datos entre varios clientes. Por ejemplo, al crear una red de estaciones meteorol\u00f3gicas que operan con NB-IoT, se pueden vender los datos de ellas a muchos servicios simult\u00e1neamente.<\/p>\n<p><b>Mecanismo de entrega garantizada de mensajes <\/b><\/p>\n<p>Reliable Data Service \u2014 es un mecanismo de entrega garantizada de mensajes MO y MT sin utilizar algoritmos especializados a nivel de protocolo, como el handshake en TCP. Funciona mediante la inclusi\u00f3n de una bandera especial en el encabezado del mensaje durante el intercambio entre UE y SCEF. Activar o no activar este mecanismo durante la transmisi\u00f3n de tr\u00e1fico es decisi\u00f3n del AS.<\/p>\n<p>Si el mecanismo est\u00e1 activado, la UE incluye una bandera especial en el encabezado del paquete para la entrega garantizada del tr\u00e1fico MO. Al recibir dicho paquete, el SCEF responde a la UE con una confirmaci\u00f3n. Si la UE no recibe el paquete de confirmaci\u00f3n, el paquete se reenv\u00eda hacia el SCEF. Lo mismo ocurre con el tr\u00e1fico MT.<\/p>\n<p><b>Monitoreo de dispositivos (monitoring events - MONTE)<\/b><\/p>\n<p>Como se mencion\u00f3 anteriormente, la funcionalidad del SCEF incluye, entre otras cosas, funciones de control de estado de la UE, conocido como monitoreo de dispositivos. Mientras que nuevos identificadores y mecanismos de transmisi\u00f3n de datos son optimizaciones (aunque muy serias) de procedimientos existentes, MONTE es una funcionalidad completamente nueva, no disponible en redes 2G\/3G\/LTE. MONTE permite al AS rastrear par\u00e1metros del dispositivo como el estado de conexi\u00f3n, disponibilidad para la comunicaci\u00f3n, ubicaci\u00f3n, estado de roaming, etc. Hablaremos m\u00e1s en detalle sobre cada uno m\u00e1s adelante.<\/p>\n<p>Si es necesario activar alg\u00fan evento de monitoreo para un dispositivo o grupo de dispositivos, el AS se suscribe al servicio correspondiente enviando al SCEF un comando de la API MONTE, que incluye par\u00e1metros como external Id o external group ID, identificador del AS, tipo de monitoreo, y la cantidad de informes que el AS desea recibir. Si el AS est\u00e1 autorizado para realizar la solicitud, el SCEF provisiona el evento en el HSS o en el MME seg\u00fan el tipo (ver figura 4). Cuando ocurre el evento, el MME o el HSS generan un informe hacia el SCEF, que lo env\u00eda al AS.<\/p>\n<p>El aprovisionamiento de todos los eventos, excepto el \"N\u00famero de UEs presentes en un \u00e1rea geogr\u00e1fica\", se realiza a trav\u00e9s del HSS. Los dos eventos \"Cambio de Asociaci\u00f3n IMSI-IMEI\" y \"Estado de Roaming\" son rastreados directamente en el HSS, mientras que los dem\u00e1s son provisionados en el MME por el HSS.<br \/>\nLos eventos pueden ser tanto puntuales como peri\u00f3dicos, y dependen de su tipo.<\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: \u00bfc\u00f3mo funciona? Parte 3: SCEF \u2013 una ventana \u00fanica de acceso a los servicios del operador\" src=\"\/wp-content\/uploads\/2019\/11\/da265ed0443b7459d28101aa07adf221.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl env\u00edo del informe de eventos (reporting) es realizado por el nodo que supervisa el evento, directamente al SCEF (ver figura 5).<\/p>\n<p><img decoding=\"async\" alt=\"NB-IoT: \u00bfc\u00f3mo funciona? Parte 3: SCEF \u2013 una ventana \u00fanica de acceso a los servicios del operador\" src=\"\/wp-content\/uploads\/2019\/11\/9b385bbc324f14e1d484f1949d926b34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Punto importante:<\/b> los eventos de monitoreo pueden aplicarse tanto a dispositivos non-IP conectados a trav\u00e9s de SCEF como a dispositivos IP que transmiten datos de la manera cl\u00e1sica a trav\u00e9s de MME-SGW-PGW.<\/p>\n<p>Analicemos cada uno de los eventos de monitoreo con m\u00e1s detalle:<\/p>\n<p><u>P\u00e9rdida de conectividad<\/u> \u2014 informa al AS que el UE ya no est\u00e1 disponible ni para tr\u00e1fico de datos ni para intercambio de se\u00f1ales. Este evento ocurre cuando el temporizador de 'alcance m\u00f3vil' para el UE expira en el MME. En la solicitud para este tipo de monitoreo, el AS puede especificar su propio valor para el 'Tiempo M\u00e1ximo de Detecci\u00f3n' \u2014 si durante este tiempo el UE no muestra ninguna actividad, el AS ser\u00e1 informado de que el UE no est\u00e1 disponible, indicando la raz\u00f3n. Tambi\u00e9n ocurre el evento si el UE ha sido forzado a salir de la red por alguna raz\u00f3n.<\/p>\n<p>* Para que la red sepa que el dispositivo sigue estando disponible, este inicia peri\u00f3dicamente el procedimiento de actualizaci\u00f3n \u2014 Actualizaci\u00f3n de \u00c1rea de Seguimiento (TAU). La frecuencia de este procedimiento es establecida por la red mediante el temporizador T3412 o (T3412_extended en el caso de PSM), cuyo valor se env\u00eda al dispositivo durante el procedimiento de Attach o el siguiente TAU. El temporizador de alcance m\u00f3vil generalmente es varios minutos m\u00e1s largo que el T3412. Si el UE no realiza un TAU antes de que expire el 'temporizador de alcance m\u00f3vil', la red lo considera como no disponible. <\/p>\n<p><u>Disponibilidad del UE<\/u> \u2013 Muestra cu\u00e1ndo el UE se vuelve disponible para tr\u00e1fico DL o SMS. Esto ocurre cuando el UE se vuelve disponible para el paginamiento (para el UE en modo eDRX) o cuando el UE cambia al modo ECM-CONNECTED (para el UE en modo PSM o eDRX), es decir, realiza TAU o env\u00eda un paquete uplink.<\/p>\n<p><u>Informe de ubicaci\u00f3n<\/u> \u2013 Este tipo de eventos de monitoreo permite al AS solicitar datos sobre la ubicaci\u00f3n del UE. Puede solicitarse la ubicaci\u00f3n actual (Current Location) o la \u00faltima conocida (Last Known Location, que se determina por el ID de celda desde la cual el dispositivo realiz\u00f3 TAU o transmiti\u00f3 tr\u00e1fico por \u00faltima vez), lo cual es relevante para dispositivos en modos de ahorro de energ\u00eda PSM o eDRX. Para la 'Ubicaci\u00f3n Actual', el AS puede solicitar informes repetidos, notificando el MME al AS cada vez que el dispositivo cambie de ubicaci\u00f3n. <\/p>\n<p><u>Cambio de asociaci\u00f3n IMSI-IMEI<\/u> \u2013 Al activar este evento, SCEF comienza a rastrear el cambio de la asociaci\u00f3n IMSI (identificador de la tarjeta SIM) e IMEI (identificador del dispositivo). Al ocurrir el evento, informa a AS. Puede ser utilizado para la reasignaci\u00f3n autom\u00e1tica de un ID externo al dispositivo durante el mantenimiento programado o para servir como identificador del robo del dispositivo.<\/p>\n<p><u>Estado de Roaming<\/u> \u2013 Este tipo de monitoreo es utilizado por AS para determinar si la UE est\u00e1 en la red nacional o en la red del socio de roaming. Opcionalmente, se puede transmitir el PLMN (Red P\u00fablica Mobile Nacional) del operador en el que el dispositivo est\u00e1 registrado.<\/p>\n<p><u>Fallo de Comunicaci\u00f3n<\/u> \u2014 Este tipo de monitoreo informa a AS sobre fallos en la comunicaci\u00f3n con el dispositivo, bas\u00e1ndose en las razones de la interrupci\u00f3n de la conexi\u00f3n (c\u00f3digo de causa de liberaci\u00f3n) recibidas de la red de acceso radioel\u00e9ctrico (protocolo S1-AP). Este evento puede ayudar a determinar la causa del fallo en la comunicaci\u00f3n: debido a problemas en la red, por ejemplo, durante la sobrecarga de eNodeb (recursos de radio no disponibles) o a causa de una falla en el propio dispositivo (conexi\u00f3n de radio perdida con la UE). <\/p>\n<p><u>Disponibilidad tras el fallo de DDN<\/u> \u2013 Este evento informa a AS que el dispositivo se ha vuelto disponible despu\u00e9s de un fallo de comunicaci\u00f3n. Puede ser utilizado cuando es necesario enviar datos al dispositivo, pero el intento anterior fue fallido, ya que la UE no respondi\u00f3 a la notificaci\u00f3n de la red (paginaci\u00f3n), y los datos no fueron entregados. Si este tipo de monitoreo fue solicitado para la UE, tan pronto como el dispositivo inicie una comunicaci\u00f3n entrante, realice un TAU o env\u00ede datos en uplink, AS ser\u00e1 informado de que el dispositivo se ha vuelto disponible. Dado que el procedimiento DDN (notificaci\u00f3n de datos de bajada) funciona entre MME y S\/P-GW, este tipo de monitoreo est\u00e1 disponible solo para dispositivos IP.<\/p>\n<p><u>Estado de Conectividad PDN<\/u> \u2013 Informa a AS sobre el cambio de estado del dispositivo (estado de conectividad PDN) \u2014 conexi\u00f3n (activaci\u00f3n de PDN) o desconexi\u00f3n (eliminaci\u00f3n de PDN). Esto puede ser utilizado por AS para iniciar la comunicaci\u00f3n con la UE, o viceversa, para entender que la comunicaci\u00f3n ya no es posible. Este tipo de monitoreo est\u00e1 disponible para dispositivos IP y non-IP.<\/p>\n<p><u>N\u00famero de UEs presentes en un \u00e1rea geogr\u00e1fica<\/u> \u2013 Este tipo de monitoreo es utilizado por AS para determinar la cantidad de UE en una zona geogr\u00e1fica espec\u00edfica.<\/p>\n<p><b>Dispositivos de activaci\u00f3n<\/b>)<\/p>\n<p>En las redes 2G\/3G, el procedimiento de registro en la red era de dos etapas: primero, el dispositivo se registraba en el SGSN (procedimiento de adjunto), luego, si era necesario transmitir datos, se activaba el contexto PDP, es decir, la conexi\u00f3n con el gateway de paquetes (GGSN). En las redes 3G, estos dos procedimientos se llevaban a cabo de forma secuencial, es decir, el dispositivo no esperaba el momento de transmitir datos, sino que activaba el PDP inmediatamente despu\u00e9s de completar el procedimiento de adjunto. En LTE, estos dos procedimientos se unificaron en uno, por lo que al adjuntarse, el dispositivo solicitaba inmediatamente la activaci\u00f3n de la conexi\u00f3n PDN (an\u00e1loga al PDP en 2G\/3G) a trav\u00e9s de eNodeB a MME-SGW-PGW.<\/p>\n<p>En NB-IoT se define un m\u00e9todo de conexi\u00f3n como \"adjunto sin PDN\", es decir, el UE se adjunta sin establecer la conexi\u00f3n PDN. En este caso, no est\u00e1 disponible para la transmisi\u00f3n de tr\u00e1fico y solo puede enviar o recibir SMS. Para enviar un comando a dicho dispositivo para la activaci\u00f3n de PDN y la conexi\u00f3n a AS, se desarroll\u00f3 la funcionalidad \"Dispositivo activado\". <\/p>\n<p>Al recibir un comando para conectar tal UE desde AS, SCEF, a trav\u00e9s del centro de SMS, inicia el env\u00edo de un SMS de control al dispositivo. Al recibir el SMS, el dispositivo activa el PDN y se conecta a AS para recibir instrucciones posteriores o transmitir datos.<\/p>\n<p>Pueden haber casos en los que la suscripci\u00f3n del SCEF al dispositivo expire. S\u00ed, la suscripci\u00f3n tiene un per\u00edodo de validez, establecido por el operador o acordado con AS. Al expirar, el PDN ser\u00e1 desactivado en MME y el dispositivo se volver\u00e1 inaccesible para AS. En este caso, la funcionalidad \"Dispositivo activado\" tambi\u00e9n ser\u00e1 \u00fatil. Al recibir nuevos datos de AS, SCEF determinar\u00e1 el estado de conexi\u00f3n del dispositivo y entregar\u00e1 los datos a trav\u00e9s del canal SMS.<\/p>\n<p><b>Conclusi\u00f3n<\/b><\/p>\n<p>La funcionalidad de SCEF, por supuesto, no se limita a los servicios descritos anteriormente y evoluciona y se expande constantemente. En este momento, ya se han estandarizado m\u00e1s de una docena de servicios para SCEF. Ahora hemos cubierto solo las funciones principales y m\u00e1s demandadas por los desarrolladores; sobre las dem\u00e1s hablaremos en futuros art\u00edculos. <\/p>\n<p><b>Inmediatamente surge la pregunta de c\u00f3mo obtener acceso de prueba a este \"maravilloso\" nodo para pruebas preliminares y depuraci\u00f3n de posibles casos. Es muy sencillo. Cualquier desarrollador puede enviar una solicitud a iot.info@mts.ru, en la que basta con indicar el prop\u00f3sito de la conexi\u00f3n, una descripci\u00f3n del posible caso y la informaci\u00f3n de contacto para la comunicaci\u00f3n.<br \/>\n<\/b><br \/>\n\u00a1Hasta la pr\u00f3xima!<\/p>\n<p><i>Autores: <\/p>\n<ul>\n<li>experto senior en soluciones convergentes y servicios multimedia Sergey Novikov <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/sanov\/\" class=\"user_link\">sanov<\/a><\/noindex>, <\/li>\n<li>experto en soluciones convergentes y servicios multimedia 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 \/>Fuente: <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.2 - 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\/es\/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.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\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\/es\/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: \u00bfc\u00f3mo funciona? Parte 3: SCEF \u2013 ventana \u00fanica de acceso a los servicios del operador | ProHoster","description":"En el art\u00edculo \u00abNB-IoT: \u00bfc\u00f3mo funciona?","canonical_url":"https:\/\/prohoster.info\/es\/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":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/52138","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=52138"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/52138\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=52138"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=52138"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=52138"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}