En el artículo " NB-IoT: ¿Cómo funciona?" Parte 2 ”, hablando de la arquitectura del núcleo del paquete de la red NB-IoT, mencionamos la aparición de un nuevo nodo SCEF. Explicamos en la tercera parte, ¿qué es y por qué es necesario?
Al crear un servicio M2M, los desarrolladores de aplicaciones se enfrentan a las siguientes preguntas:
- Cómo identificar dispositivos
- Qué autenticación y algoritmo de autenticación usar;
- qué protocolo de transporte utilizar para interactuar con dispositivos;
- Cómo entregar datos de forma segura a los dispositivos
- cómo organizar y establecer reglas para intercambiar datos con ellos;
- cómo monitorear y recibir información sobre su estado en línea;
- cómo entregar datos simultáneamente a un grupo de sus dispositivos;
- Cómo enviar datos simultáneamente desde un dispositivo a varios clientes;
- cómo obtener acceso unificado a servicios de operador adicionales para administrar su dispositivo.
Para resolverlos, uno tiene que crear soluciones patentadas técnicamente "pesadas", lo que conduce a un aumento en los costos laborales y los servicios de tiempo de comercialización. Aquí es donde el nuevo nodo SCEF viene al rescate.
Según la definición de 3GPP, SCEF (función de exposición de capacidad de servicio) es un componente completamente nuevo de la arquitectura 3GPP, cuya función es exponer de forma segura los servicios y capacidades proporcionados por las interfaces de red 3GPP a través de la API.
En palabras simples, SCEF es un intermediario entre la red y el servidor de aplicaciones (AS), una única ventana de acceso a los servicios del operador para administrar su dispositivo M2M en la red NB-IoT a través de una API estandarizada intuitiva.
SCEF oculta la complejidad de la red del operador, lo que permite a los desarrolladores de aplicaciones abstraerse de mecanismos complejos y específicos para interactuar con los dispositivos.
Al transformar los protocolos de red en familiares para los desarrolladores de aplicaciones, la API SCEF facilita la creación de nuevos servicios y reduce el tiempo de comercialización. Además, el nuevo nodo incluye las funciones de identificación / autenticación de dispositivos móviles, determinando las reglas para el intercambio de datos entre el dispositivo y AS, eliminando la necesidad de la implementación de estas funciones por parte de los desarrolladores de aplicaciones, transfiriendo estas funciones a los hombros del operador.
SCEF cierra las interfaces necesarias para la autenticación y autorización de los servidores de aplicaciones, manteniendo la movilidad del UE, la transferencia de datos y la activación de dispositivos, el acceso a servicios adicionales y las capacidades de red del operador.
Hacia AS hay una única interfaz T8, una API (HTTP / JSON), un 3GPP estandarizado. Todas las interfaces, con la excepción de T8, funcionan según el protocolo DIAMETER (Fig. 1).
T6a es la interfaz entre SCEF y MME. Se utiliza para los procedimientos de gestión de movilidad / sesión, transmisión de datos no IP, aprovisionamiento de eventos de monitoreo y recepción de informes sobre ellos.
S6t es la interfaz entre SCEF y HSS. Es necesario para la autenticación del suscriptor, la autorización de los servidores de aplicaciones, la obtención de una gran cantidad de identificación externa e IMSI / MSISDN, el suministro de eventos de monitoreo y la recepción de informes sobre ellos.
S6m / T4: interfaces de SCEF a HSS y SMS-C (el nodo MTC-IWF se define en 3GPP, que se utiliza para activar dispositivos y enviar SMS en redes NB-IoT. Sin embargo, en todas las implementaciones, la funcionalidad de este nodo está integrada en SCEF, por lo que simplificación del esquema, no lo consideraremos por separado). Se utiliza para obtener información de enrutamiento para enviar SMS e interactuar con el centro de SMS.
T8: API SCEF para la interacción con servidores de aplicaciones. Tanto los comandos de control como el tráfico se transmiten a través de esta interfaz.
* En realidad, hay más interfaces, aquí solo se enumeran las más básicas. Se proporciona una lista completa en 3GPP 23.682 (4.3.2 Lista de puntos de referencia).
A continuación se presentan las características y servicios clave de SCEF:
- vincular un identificador de tarjeta SIM (IMSI) a una identificación externa;
- entrega de tráfico no IP (entrega de datos no IP, NIDD);
- operaciones de grupo usando una ID de grupo externo;
- soporte para el modo de transferencia de datos con confirmación;
- almacenamiento en búfer de datos MO (originados en móviles) y MT (terminados en móviles);
- autenticación y autorización de dispositivos y servidores de aplicaciones;
- uso simultáneo de los datos de un UE por varios AS;
- soporte de funciones especiales de monitoreo del estado del UE (MONTE - Monitoreo de eventos);
- activación del dispositivo;
- Proporcionar datos de itinerancia no IP.
El principio básico de interacción entre AS y SCEF se basa en el llamado suscripciones Si necesita acceder a cualquier servicio SCEF para un UE específico, el servidor de aplicaciones debe crear una suscripción enviando un comando a la API específica del servicio solicitado y en respuesta para recibir un identificador único. Después de eso, todas las acciones y comunicaciones adicionales con el UE en el marco de este servicio se llevarán a cabo utilizando este identificador.
Identificación externa: identificador universal del dispositivoUno de los cambios más importantes en el esquema de interacción entre AS y dispositivos cuando se trabaja a través de SCEF es la aparición de un identificador universal. Ahora, en lugar de un número de teléfono (MSISDN) o una dirección IP, como estaba en la red clásica 2G / 3G / LTE, el identificador del dispositivo para el servidor de aplicaciones se convierte en "ID externo". Está definido por el estándar en el formato familiar para los desarrolladores de aplicaciones "<Local Identifier> @ <Domain Identifier>".
Los desarrolladores ya no necesitan implementar algoritmos de autenticación de dispositivos, la red asume completamente esta función. La identificación externa se adjunta a IMSI, y el desarrollador puede estar seguro de que, refiriéndose a una identificación externa específica, interactúa con una tarjeta SIM específica. ¡Cuando se usa un chip SIM, se obtiene una situación generalmente única cuando la identificación externa identifica de manera única un dispositivo específico!
Además, se pueden adjuntar varias ID externas a un IMSI; se obtiene una situación aún más interesante cuando la ID externa identifica de forma exclusiva una aplicación específica que es responsable de un servicio particular en un dispositivo en particular.
También aparece un identificador de grupo: una ID de grupo externa, que incluye un conjunto de ID externas independientes. Ahora, con una sola solicitud a SCEF, AS puede iniciar operaciones grupales, enviando datos o comandos de control a múltiples dispositivos combinados en un solo grupo lógico.
Debido al hecho de que para los desarrolladores de AS, la transición a un nuevo identificador de dispositivo no puede ser instantánea, SCEF dejó la posibilidad de comunicación de AS con el UE a través del número estándar: MSISDN.
Entrega de datos sin IP (NIDD)En NB-IoT, además de optimizar los mecanismos para transferir pequeñas cantidades de datos, además de los tipos existentes de PDN, como IPv4, IPv6 e IPv4v6, apareció otro tipo: no IP. En este caso, el dispositivo (UE) no tiene asignada una dirección IP y los datos se transmiten sin usar el protocolo IP. El tráfico para tales conexiones se puede enrutar de dos maneras: clásico - MME -> SGW -> PGW y luego a través del túnel PtP a AS (Fig. 2) o usando SCEF (Fig. 3).
El método clásico no tiene ventajas especiales sobre el tráfico IP, excepto por reducir el tamaño de los paquetes transmitidos debido a la ausencia de encabezados IP. El uso de SCEF abre una serie de nuevas oportunidades y simplifica enormemente los procedimientos para interactuar con los dispositivos.
Al transmitir datos a través de SCEF, hay dos ventajas muy importantes sobre el tráfico IP clásico:
Entrega de tráfico MT al dispositivo por ID externoPara enviar un mensaje a un dispositivo IP clásico, el AS debe conocer su dirección IP. Aquí surge un problema: dado que el dispositivo generalmente se registra con una dirección IP "gris", se comunica con el servidor de aplicaciones, que se encuentra en Internet, a través del nodo NAT, donde la dirección gris se traduce en blanco. Un grupo de direcciones IP grises y blancas dura un tiempo limitado, dependiendo de la configuración de NAT. En promedio, para TCP o UDP, no más de cinco minutos. Es decir, si dentro de 5 minutos no hubo intercambio de datos con este dispositivo, el paquete se romperá y el dispositivo ya no será accesible en la dirección blanca con la que se inició la sesión con AS. Hay varias soluciones:
1. Use un latido del corazón. Una vez que se establece una conexión, el dispositivo debe intercambiar con paquetes AS cada pocos minutos, evitando así que se cierren las traducciones NAT. Pero no puede haber ninguna cuestión de eficiencia energética.
2. Cada vez, si es necesario, verifique si hay paquetes para el dispositivo en el AS: envíe un mensaje al enlace ascendente.
3. Cree un APN privado (VRF), donde el servidor de aplicaciones y los dispositivos estarán en la misma subred, y asigne direcciones IP estáticas a los dispositivos. Funcionará, pero esto es casi imposible cuando se trata de una flota de miles, decenas de miles de dispositivos.
4. Finalmente, la opción más adecuada: usar IPv6, no necesita NAT, ya que las direcciones IPv6 son directamente accesibles desde Internet. Sin embargo, incluso en este caso, al volver a registrar el dispositivo, recibirá una nueva dirección IPv6 y ya no estará disponible en la anterior.
En consecuencia, es necesario enviar un cierto paquete de inicialización con el identificador del dispositivo al servidor para informar la nueva dirección IP del dispositivo. Luego, espere el paquete de confirmación de AS, que también afecta la eficiencia energética.
Estos métodos funcionan bien para dispositivos 2G / 3G / LTE, donde el dispositivo no tiene requisitos estrictos de autonomía y, como resultado, no hay límites de tiempo en el aire y el tráfico. Para NB-IoT, estos métodos no son adecuados debido a su alto consumo de energía.
SCEF resuelve este problema: dado que el único identificador de dispositivo para AS es una ID externa, es suficiente para que AS envíe un paquete de datos a SCEF para una ID externa específica, SCEF se encargará del resto. Si el dispositivo está en modo de ahorro de energía PSM o eDRX, los datos se almacenarán en la memoria intermedia y se entregarán cuando el dispositivo esté disponible. Si el dispositivo está disponible para el tráfico, los datos se entregarán de inmediato. Lo mismo es cierto para los equipos de gestión.
En cualquier momento, el AS puede retirar el mensaje almacenado en el búfer al UE o reemplazarlo por uno nuevo.
El mecanismo de almacenamiento en búfer también se puede utilizar al transferir datos MO desde el UE al lado AS. Si SCEF no pudo entregar datos a AS de inmediato, por ejemplo, si el trabajo de servicio está en marcha en los servidores de AS, estos paquetes se almacenarán en búfer y se garantizará que se entreguen tan pronto como el AS esté disponible.
Como se señaló anteriormente, el acceso a un servicio específico y UE para AS (y NIDD es un servicio) está regulado por reglas y políticas en el lado SCEF, lo que permite realizar la capacidad única de usar simultáneamente los datos de un UE por varios AS. Es decir Si varios AS se han suscrito a un UE, luego de recibir los datos del UE, SCEF los enviará a todos los AS firmados. Esto es muy adecuado para casos en los que el creador de una flota de dispositivos especializados confunde datos entre varios clientes. Por ejemplo, al crear una red de estaciones meteorológicas que funcionan con NB-IoT, puede vender sus datos a muchos servicios al mismo tiempo.
Mecanismo de entrega de mensajes garantizadoServicio de datos confiable: un mecanismo para la entrega garantizada de mensajes MO y MT sin el uso de algoritmos especializados a nivel de protocolo, como, por ejemplo, el protocolo de enlace en TCP. Funciona al incluir una bandera especial en la parte de servicio del mensaje durante el intercambio entre el UE y SCEF. El AS decide si activar o no este mecanismo cuando se transmite tráfico.
Si el mecanismo está activado, el UE, si es necesario, entrega garantizada de tráfico MO incluye una bandera especial en la parte de servicio del paquete. Al recibir dicho paquete, el SCEF responde al UE con una confirmación. Si el UE no ha recibido un paquete de confirmación, el paquete será enviado a SCEF. Lo mismo sucede con el tráfico MT.
Monitoreo de dispositivos (monitoreo de eventos - MONTE)Como se mencionó anteriormente, el SCEF funcional, entre otras cosas, incluye funciones para monitorear el estado del UE, el llamado Monitoreo del dispositivo. Y si los nuevos identificadores y los mecanismos de transferencia de datos son optimizaciones (aunque muy serias) de los procedimientos existentes, entonces MONTE es una funcionalidad completamente nueva que no está disponible en las redes 2G / 3G / LTE. MONTE permite a AS monitorear parámetros del dispositivo como el estado de la conexión, la disponibilidad de la comunicación, la ubicación, el estado de roaming, etc. Le contaremos más sobre cada uno más tarde.
Si es necesario activar un evento de monitoreo para un dispositivo o un grupo de dispositivos, AS se suscribe al servicio correspondiente enviando a SCEF el comando correspondiente de la API de MONTE, que incluye parámetros tales como ID externo o ID de grupo externo, identificador AS, tipo de monitoreo, número de informes, que AS quiere recibir. Si el AS está autorizado para ejecutar la solicitud, SCEF, dependiendo del tipo, activará el evento en el HSS o MME (Fig. 4). Cuando ocurre un evento, el MME o el HSS genera un informe al lado SCEF, que lo envía al AS.
Todos los eventos excepto "Número de UE presentes en un área geográfica" se proporcionan a través de HSS. Los dos eventos "Cambio de Asociación IMSI-IMEI" y "Estado de itinerancia" se rastrean directamente en el HSS, el resto del HSS se aprovisionará en el MME.
Los eventos pueden ser únicos o periódicos, y están determinados por su tipo.
El nodo de seguimiento de eventos envía el informe de eventos (informes) directamente a SCEF (Fig. 5).
Un punto importante: los eventos de monitoreo pueden aplicarse tanto a dispositivos no IP conectados a través de SCEF como a dispositivos IP que transmiten datos de manera clásica a través de MME-SGW-PGW.
Echemos un vistazo más de cerca a cada uno de los eventos de monitoreo:
Pérdida de conectividad : informa a AS que el UE ya no está disponible para tráfico de datos o señalización. El evento ocurre cuando el "temporizador de accesibilidad móvil" para el UE expira en el MME. En la solicitud de este tipo de monitoreo, el AS puede indicar su valor de "Tiempo máximo de detección"; si el UE no muestra ninguna actividad durante este tiempo, se le informará al AS que el UE no está disponible, indicando el motivo. El evento también ocurre si el UE fue eliminado por la red por la fuerza por algún motivo.
* Para que la red sepa que el dispositivo todavía está disponible, inicia periódicamente el procedimiento de actualización: Actualización del área de seguimiento (TAU). La red establece la frecuencia de este procedimiento utilizando el temporizador T3412 o (T3412_extender en el caso de PSM), cuyo valor se transmite al dispositivo durante el procedimiento de conexión o el próximo TAU. El temporizador de accesibilidad móvil suele ser varios minutos más largo que el T3412. Si el UE no realiza una TAU antes de que expire el temporizador de accesibilidad móvil, la red considera que ya no está disponible.
Accesibilidad de UE : muestra cuándo el UE está disponible para tráfico DL o SMS. Esto sucede cuando el UE está disponible para paginación (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. crea un TAU o envía un paquete de enlace ascendente.
Informes de ubicación : este tipo de evento de supervisión permite al AS solicitar datos de ubicación del UE. Se puede solicitar la ubicación actual (Última ubicación) o la última conocida (Última ubicación conocida, determinada por la ID de la celda desde la cual el dispositivo realizó el TAU o el tráfico transmitido por última vez), lo cual es importante para los dispositivos en los modos de ahorro de energía PSM o eDRX. Para “Ubicación actual”, el AS puede solicitar repeticiones repetidas, y el MME informa al AS cada vez que se cambia la ubicación del dispositivo.
Cambio de asociación IMSI-IMEI : cuando se activa este evento, SCEF comienza a rastrear los cambios en la conexión entre IMSI (identificador de tarjeta SIM) e IMEI (identificador de dispositivo). Cuando ocurre un evento, informa AS. Se puede usar para reasignar automáticamente la identificación externa al dispositivo durante el trabajo de reemplazo planificado o servir como un identificador para el robo del dispositivo.
Estado de itinerancia : el AS utiliza este tipo de supervisión para determinar si el UE está en la red doméstica o en la red del socio de itinerancia. Opcionalmente, se puede transferir la PLMN (Red pública de telefonía móvil terrestre) del operador en el que está registrado el dispositivo.
Falla de comunicación : este tipo de monitoreo informa al AS sobre fallas en la comunicación con el dispositivo, en función de los motivos de la conexión (código de causa de liberación) recibida de la red de acceso de radio (protocolo S1-AP). Este evento puede ayudar a determinar el motivo de la falla de comunicación, debido a problemas de red, por ejemplo, cuando eNodeb (recursos de radio no disponibles) está sobrecargado o porque el dispositivo en sí (Radio Connection With UE Lost) falló.
Disponibilidad después de una falla DDN : este evento informa al AS que el dispositivo estuvo disponible después de una falla de comunicación. Se puede usar cuando es necesario transferir datos al dispositivo, pero el intento anterior no tuvo éxito, ya que el UE no respondió a la notificación de la red (paginación) y los datos no se entregaron. Si se solicitó este tipo de monitoreo para el UE, tan pronto como el dispositivo realice la comunicación entrante, realice un TAU o envíe datos al enlace ascendente, AS será informado de que el dispositivo ha estado disponible. Dado que el procedimiento DDN (notificación de datos de enlace descendente) funciona entre MME y S / P-GW, este tipo de monitoreo solo está disponible para dispositivos IP.
Estado de conectividad PDN : informa al AS al cambiar el estado del dispositivo (estado de conectividad PDN): conectando (activando PDN) o desconectando (eliminando PDN). El AS puede usar esto para iniciar la comunicación con el UE, o viceversa, para comprender que la comunicación ya no es posible. Este tipo de monitoreo está disponible para dispositivos IP y no IP.
Número de UE presentes en un área geográfica : el AS utiliza este tipo de monitoreo para determinar el número de UE en un área geográfica específica.
Dispositivo de disparoEn las redes 2G / 3G, el procedimiento de registro en la red fue de dos pasos: primero, el dispositivo se registró en SGSN (procedimiento de conexión), luego, si es necesario, transmita el contexto PDP activado por datos: conexión a la puerta de enlace de paquetes (GGSN). En las redes 3G, estos dos procedimientos fueron secuencialmente, es decir. el dispositivo no esperó el momento en que era necesario transferir datos, pero activó PDP inmediatamente después de que se completó el procedimiento de conexión. En LTE, estos dos procedimientos se combinaron en uno, es decir, cuando se conectó, el dispositivo solicitó de inmediato la activación de la conexión PDN (análogo de PDP en 2G / 3G) a través de eNodeB a MME-SGW-PGW.
NB-IoT define un método de conexión como "adjuntar sin PDN", es decir, el UE realiza la conexión sin establecer una conexión PDN. En este caso, no está disponible para la transmisión de tráfico y solo puede recibir o enviar SMS. Para enviar un comando para activar un PDN y conectarse a AS a dicho dispositivo, se desarrolló la funcionalidad "Activación de dispositivo".
Al recibir un comando para conectar dicho UE desde AS, SCEF a través del centro de SMS inicia el envío de un SMS de control al dispositivo. Al recibir un SMS, el dispositivo activa el PDN y se conecta al AS para recibir instrucciones posteriores o transferir datos.
Puede haber ocasiones en que una suscripción a un dispositivo caduque en SCEF. Sí, la suscripción tiene su propia vida, establecida por el operador o acordada con AS. MME PDN, AS. “Device triggering”. AS SCEF SMS-.
ConclusiónSCEF, , . SCEF . , .
, «»- ? . nidd_scef@mts.ru, , .
!
: