NB-IoT: ¿cómo funciona? Parte 3: SCEF – ventanilla única de acceso a los servicios del operador

En el articuloNB-IoT: ¿cómo funciona? Parte 2", hablando de la arquitectura del núcleo de paquetes de la red NB-IoT, mencionamos la aparición de un nuevo nodo SCEF. ¿Te 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é algoritmo de verificación y autenticación utilizar;
• qué protocolo de transporte elegir para interactuar con los dispositivos;
• cómo entregar datos de manera confiable a los dispositivos;
• cómo organizar y establecer reglas para el intercambio de datos con ellos;
• cómo monitorear y obtener información sobre su condición 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 adicionales del operador para administrar su dispositivo.

Para resolverlos, es necesario crear soluciones patentadas técnicamente “pesadas”, lo que conduce a mayores costos laborales y plazos de comercialización de los servicios. Aquí es donde el nuevo nodo SCEF viene al rescate.

Según lo define 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 API.

En palabras simples, SCEF es un intermediario entre la red y el servidor de aplicaciones (AS), una ventana única de acceso a los servicios del operador para administrar su dispositivo M2M en la red NB-IoT a través de una interfaz API estandarizada e intuitiva.

SCEF oculta la complejidad de la red de un operador, lo que permite a los desarrolladores de aplicaciones abstraer mecanismos complejos y específicos de cada dispositivo para interactuar con ellos.

Al transformar los protocolos de red en una API familiar para los desarrolladores de aplicaciones, la API de SCEF facilita la creación de nuevos servicios y reduce el tiempo de comercialización. El nuevo nodo también incluye funciones para identificar/autenticar dispositivos móviles, definir las reglas para el intercambio de datos entre el dispositivo y el AS, eliminando la necesidad de que los desarrolladores de aplicaciones implementen estas funciones por su parte, transfiriendo estas funciones a los hombros del operador.

SCEF cubre las interfaces necesarias para la autenticación y autorización de servidores de aplicaciones, manteniendo la movilidad del UE, transferencia de datos y activación de dispositivos, acceso a servicios adicionales y capacidades de red del operador.

Hacia el AS existe una única interfaz T8, una API (HTTP/JSON) estandarizada por 3GPP. Todas las interfaces, a excepción de T8, funcionan según el protocolo DIAMETER (Fig. 1).

T6a – interfaz entre SCEF y MME. Se utiliza para procedimientos de gestión de movilidad/sesiones, transmisión de datos no IP, aprovisionamiento de eventos de monitoreo y recepción de informes sobre los mismos.

S6t – interfaz entre SCEF y HSS. Requerido para la autenticación de suscriptores, autorización de servidores de aplicaciones, obtención de una combinación de ID externa e IMSI/MSISDN, aprovisionamiento de eventos de monitoreo y recepción de informes sobre ellos.

S6m/T4: interfaces de SCEF a HSS y SMS-C (3GPP define el nodo MTC-IWF, que se utiliza para la activación de dispositivos y la transmisión de SMS en redes NB-IoT. Sin embargo, en todas las implementaciones la funcionalidad de este nodo está integrada en SCEF, por lo que para simplificar el circuito no lo consideraremos por separado). Se utiliza para obtener información de enrutamiento para enviar SMS e interactuar con el centro de SMS.

T8 – Interfaz API para la interacción SCEF 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 detallan las funciones y servicios clave de SCEF:

• vincular el identificador de la tarjeta SIM (IMSI) a una identificación externa;
• transmisión de tráfico no IP (Non-IP Data Delivery, NIDD);
• operaciones de grupo utilizando ID de grupo externo;
• soporte para modo de transmisión de datos con confirmación;
• almacenamiento en búfer de datos MO (originados en dispositivos móviles) y MT (terminados en dispositivos móviles);
• autenticación y autorización de dispositivos y servidores de aplicaciones;
• uso simultáneo de datos de un UE por varios AS;
• soporte para funciones especiales de monitoreo del estado del UE (MONTE – Monitoreo de eventos);
• activación del dispositivo;
• proporcionar roaming de datos no IP.

El principio básico de interacción entre AS y SCEF se basa en el llamado esquema. suscripciones. Si es necesario obtener acceso 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 recibir un identificador único en respuesta. Después de lo cual todas las demás acciones y comunicaciones con el UE en el marco de este servicio se realizarán utilizando este identificador.

ID externo: identificador de dispositivo universal

Uno 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 ocurría en la clásica red 2G/3G/LTE, el identificador del dispositivo para el servidor de aplicaciones se convierte en "ID externo". Está definido por el estándar en un formato familiar para los desarrolladores de aplicaciones " @ "

Los desarrolladores ya no necesitan implementar algoritmos de autenticación de dispositivos, la red asume completamente esta función. La identificación externa está vinculada a IMSI y el desarrollador puede estar seguro de que al acceder a una identificación externa específica, interactúa con una tarjeta SIM específica. Cuando se utiliza un chip SIM, se obtiene una situación completamente única cuando la identificación externa identifica de forma única un dispositivo específico.

Además, se pueden vincular varias ID externas a un IMSI; surge una situación aún más interesante cuando la ID externa identifica de forma única una aplicación específica responsable de un servicio específico en un dispositivo específico.

También aparece un identificador de grupo: ID de grupo externo, que incluye un conjunto de ID externos individuales. Ahora, con una solicitud a SCEF, AS puede iniciar operaciones grupales: enviar datos o comandos de control a múltiples dispositivos unidos en un solo grupo lógico.

Debido a 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 de un número estándar: MSISDN.

Transmisión de tráfico no IP (Non-IP Data Delivery, NIDD)

En NB-IoT, como parte de la optimización de los mecanismos para transmitir pequeñas cantidades de datos, además de los tipos PDN ya existentes, como IPv4, IPv6 e IPv4v6, apareció otro tipo: no IP. En este caso, al dispositivo (UE) no se le asigna una dirección IP y los datos se transmiten sin utilizar 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 ofrece ninguna ventaja especial sobre el tráfico IP, salvo la reducción del tamaño de los paquetes transmitidos debido a la ausencia de encabezados IP. El uso de SCEF abre una serie de nuevas posibilidades y simplifica significativamente los procedimientos para interactuar con los dispositivos.

Al transmitir datos vía SCEF aparecen dos ventajas muy importantes respecto al tráfico IP clásico:


Entrega de tráfico MT al dispositivo mediante ID externa

Para 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 suele recibir una dirección IP "gris" al registrarse, se comunica con el servidor de aplicaciones ubicado en Internet a través de un nodo NAT, donde la dirección gris se traduce en blanca. La combinación 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 no hay intercambio de datos con este dispositivo dentro de 5 minutos, la conexión se desintegrará y ya no se podrá acceder al dispositivo en la dirección blanca con la que se inició la sesión con AS. Hay varias soluciones:

1. Utilice los latidos del corazón. Una vez que se ha establecido una conexión, el dispositivo debe intercambiar paquetes con el AS cada pocos minutos, evitando así que se cierren las traducciones NAT. Pero aquí no se puede hablar de eficiencia energética.

2. Cada vez, si es necesario, verifique la disponibilidad de 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 es casi imposible cuando hablamos de una flota de miles, decenas de miles de dispositivos.

4. Finalmente, la opción más adecuada: utilizar IPv6, no requiere NAT, ya que las direcciones IPv6 son directamente accesibles desde Internet. Sin embargo, incluso en este caso, cuando se vuelva a registrar el dispositivo, recibirá una nueva dirección IPv6 y ya no será accesible utilizando la anterior.

En consecuencia, es necesario enviar algún paquete de inicialización con un identificador de dispositivo al servidor para informar la nueva dirección IP del dispositivo. Luego espere un paquete de confirmación de AS, lo que también afecta a 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 restricciones de tiempo aire ni de tráfico. Estos métodos no son adecuados para NB-IoT debido a su alto consumo de energía.

SCEF resuelve este problema: dado que el único identificador de dispositivo para un AS es una ID externa, el AS sólo necesita enviar un paquete de datos a SCEF para una ID externa específica y SCEF se encarga del resto. En caso de que el dispositivo esté en modo de ahorro de energía PSM o eDRX, los datos se almacenarán en el búfer y se entregarán cuando el dispositivo esté disponible. Si el dispositivo está disponible para el tráfico, los datos se entregarán inmediatamente. Lo mismo ocurre con los equipos directivos.

En cualquier momento, el AS puede recuperar el mensaje almacenado en la memoria intermedia al UE o reemplazarlo por uno nuevo.

El mecanismo de almacenamiento en memoria intermedia también se puede utilizar al transmitir datos de MO desde el UE al AS. Si SCEF no pudo entregar datos al AS inmediatamente, por ejemplo, si se están realizando trabajos de mantenimiento en los servidores del AS, estos paquetes se almacenarán en un buffer y se garantizará que se entregarán tan pronto como el AS esté disponible.

Como se señaló anteriormente, el acceso a un servicio y UE específicos para un AS (y NIDD es un servicio) está regulado por reglas y políticas del lado SCEF, lo que permite la posibilidad única de uso simultáneo de datos de un UE por varios AS. Aquellos. Si varios AS se han suscrito a un UE, después de recibir datos del UE, SCEF los enviará a todos los AS suscritos. Esto es muy adecuado para casos en los que el creador de una flota de dispositivos especializados comparte datos entre varios clientes. Por ejemplo, al crear una red de estaciones meteorológicas que funcionan con NB-IoT, puede vender datos de ellas a muchos servicios simultáneamente.

Mecanismo de entrega de mensajes garantizado

Reliable Data Service es 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 incluyendo una bandera especial en la parte de servicio del mensaje cuando se intercambia entre el UE y SCEF. El AS decide si activar o no este mecanismo al transmitir tráfico.

Si el mecanismo está activado, el UE incluye una bandera especial en la parte superior del paquete cuando requiere una entrega garantizada de tráfico MO. Al recibir dicho paquete, la SCEF responde al UE con un acuse de recibo. Si el UE no recibe el paquete de acuse de recibo, se reenviará el paquete hacia SCEF. Lo mismo ocurre con el tráfico MT.

Monitoreo de dispositivos (monitoreo de eventos - MONTE)

Como se mencionó anteriormente, la funcionalidad SCEF, entre otras cosas, incluye funciones para monitorear el estado del UE, el llamado. Monitoreo de dispositivos. Y si los nuevos identificadores y 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 estado de conexión, disponibilidad de comunicación, ubicación, estado de roaming, etc. Hablaremos de cada uno con más detalle un poco más adelante.

Si es necesario activar algún evento de monitoreo para un dispositivo o grupo de dispositivos, el AS se suscribe al servicio correspondiente enviando el comando API MONTE correspondiente a SCEF, que incluye parámetros como ID externo o ID de grupo externo, identificador de AS, monitoreo tipo, número de informes que AS quiere recibir. Si el AS está autorizado a ejecutar la solicitud, SCEF, según el tipo, proporcionará el evento al HSS o MME (Fig. 4). Cuando ocurre un evento, la MME o HSS genera un informe a SCEF, que lo envía al AS.

El aprovisionamiento de todos los eventos, con excepción del "Número de UE presentes en un área geográfica", se produce a través de HSS. Dos eventos, “Cambio de asociación IMSI-IMEI” y “Estado de roaming”, se rastrean directamente en HSS; el resto lo proporcionará HSS en MME.
Los eventos pueden ser únicos o periódicos y están determinados por su tipo.

El envío de un informe sobre un evento (reporting) lo realiza el nodo que rastrea el evento directamente a SCEF (Fig. 5).

Punto importante: La monitorización de eventos se puede aplicar tanto a dispositivos no IP conectados a través de SCEF como a dispositivos IP que transmiten datos de la forma 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 al AS que el UE ya no está disponible ni para tráfico de datos ni para señalización. El evento ocurre cuando el "temporizador de accesibilidad móvil" para el UE expira en la MME. En una solicitud de este tipo de monitoreo, el AS puede indicar su valor de “Tiempo máximo de detección”; si durante este tiempo el UE no muestra ninguna actividad, se informará al AS que el UE no está disponible, indicando el motivo. El evento también ocurre si la red eliminó por la fuerza el UE por cualquier motivo.

* Para que la red sepa que el dispositivo aún está disponible, periódicamente inicia un procedimiento de actualización: Actualización del área de seguimiento (TAU). La frecuencia de este procedimiento la establece la red mediante el temporizador T3412 o (T3412_extended en el caso de PSM), cuyo valor se transmite al dispositivo durante el procedimiento de conexión o la siguiente TAU. El temporizador de accesibilidad móvil suele ser varios minutos más largo que el T3412. Si el UE no ha realizado una TAU antes de que expire el "temporizador de accesibilidad móvil", la red considera que ya no es accesible.

Accesibilidad UE – Indica cuando el UE está disponible para tráfico DL o SMS. Esto ocurre cuando el UE está disponible para localización (para un UE en modo eDRX) o cuando el UE ingresa al modo ECM-CONNECTED (para un UE en modo PSM o eDRX), es decir. realiza una TAU o envía un paquete de enlace ascendente.

Informes de ubicación – Este tipo de eventos de monitoreo permite al AS consultar la ubicación del UE. Se puede solicitar la ubicación actual (Ubicación actual) o la última ubicación conocida (determinada por la identificación de la celda desde la cual el dispositivo realizó TAU o transmitió tráfico la última vez), lo cual es relevante para dispositivos en modos de ahorro de energía PSM o eDRX. Para la "Ubicación actual", el AS puede solicitar respuestas repetidas, y la MME informa al AS cada vez que cambia la ubicación del dispositivo.

Cambio de Asociación IMSI-IMEI – Cuando se activa este evento, SCEF comienza a monitorear los cambios en la combinación de IMSI (identificador de tarjeta SIM) e IMEI (identificador de dispositivo). Cuando se produce un evento, informa a AS. Se puede utilizar para volver a vincular automáticamente una identificación externa a un dispositivo durante el trabajo de reemplazo programado o servir como identificador en caso de robo de un dispositivo.

Estado de itinerancia – el AS utiliza este tipo de supervisión para determinar si el UE está en la red local o en la red de un socio de itinerancia. Opcionalmente se puede transmitir la PLMN (Red Móvil Terrestre Pública) del operador en el que está registrado el dispositivo.

Fallo de comunicación — Este tipo de monitoreo informa al AS sobre fallas en la comunicación con el dispositivo, según los motivos de la pérdida de conexión (código de causa de liberación) recibidos de la red de acceso radio (protocolo S1-AP). Este evento puede ayudar a determinar por qué falló la comunicación: debido a problemas en la red, por ejemplo, cuando el eNodeb está sobrecargado (recursos de radio no disponibles) o debido a una falla del propio dispositivo (Conexión de radio con UE perdida).

Disponibilidad después de una falla de DDN – este evento informa al AS que el dispositivo está disponible después de un fallo de comunicación. Se puede utilizar cuando es necesario transferir datos a un dispositivo, pero el intento anterior no tuvo éxito porque el UE no respondió a una notificación de la red (búsqueda) y los datos no se entregaron. Si se ha solicitado este tipo de monitoreo para el UE, tan pronto como el dispositivo realice una comunicación entrante, realice una TAU o envíe datos al enlace ascendente, se informará al AS que el dispositivo está 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 cuando cambia el estado del dispositivo (estado de conectividad PDN) - conexión (activación PDN) o desconexión (eliminación de PDN). El AS puede utilizar 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 – Este tipo de seguimiento lo utiliza el AS para determinar el número de UE en una determinada zona geográfica.

Activación del dispositivo)

En las redes 2G/3G, el procedimiento de registro en la red constaba de dos etapas: primero, el dispositivo se registraba en el SGSN (procedimiento de conexión) y luego, si era necesario, activaba el contexto PDP, una conexión con la puerta de enlace de paquetes (GGSN). para transmitir datos. En las redes 3G, estos dos procedimientos se produjeron de forma secuencial, es decir. el dispositivo no esperó el momento en que necesitaba transferir datos, sino que activó PDP inmediatamente después de completar el procedimiento de conexión. En LTE, estos dos procedimientos se combinaron en uno, es decir, al conectarse, el dispositivo solicitó inmediatamente la activación de la conexión PDN (análoga a PDP en 2G/3G) a través del eNodeB al MME-SGW-PGW.

NB-IoT define un método de conexión como "conectar sin PDN", es decir, el UE se conecta sin establecer una conexión PDN. En este caso, no está disponible para transmitir tráfico, y sólo puede recibir o enviar SMS. Para enviar un comando a dicho dispositivo para activar PDN y conectarse a AS, se desarrolló la funcionalidad "Activación de dispositivo".

Al recibir un comando para conectar dicho UE desde el AS, SCEF inicia el envío de un SMS de control al dispositivo a través del centro de SMS. Al recibir un SMS, el dispositivo activa el PDN y se conecta al AS para recibir más instrucciones o transferir datos.

Puede haber ocasiones en las que la suscripción de su dispositivo caduque en SCEF. Sí, la suscripción tiene una vida útil propia, fijada por el operador o pactada con AS. Al vencimiento, el PDN se desactivará en el MME y el dispositivo dejará de estar disponible para el AS. En este caso, la funcionalidad "Activación del dispositivo" también será de ayuda. Al recibir nuevos datos de AS, SCEF descubrirá el estado de conexión del dispositivo y entregará los datos a través del canal SMS.

Conclusión

La funcionalidad de SCEF, por supuesto, no se limita a los servicios descritos anteriormente y está en constante evolución y expansión. Actualmente, ya se han estandarizado más de una docena de servicios para SCEF. Ahora hemos tocado solo las funciones principales que demandan los desarrolladores, hablaremos del resto en futuros artículos.

Inmediatamente surge la pregunta: ¿cómo obtener acceso de prueba a este nodo "milagroso" para realizar pruebas preliminares y depurar posibles casos? Todo es muy sencillo. Cualquier desarrollador puede enviar una solicitud a [email protected], en el que basta con indicar el propósito de la conexión, una descripción de un posible caso y datos de contacto para la comunicación.

Hasta la próxima!

Autores:

• experto senior del departamento de soluciones convergentes y servicios multimedia Sergey Novikov sanov,
• experto del departamento de soluciones convergentes y servicios multimedia Alexey Lapshin aslap

Fuente: habr.com