En el artículo «», al hablar sobre la arquitectura del núcleo de paquetes de la red NB-IoT, mencionamos la aparición de un nuevo nodo SCEF. Explicamos en la tercera parte qué es y para qué sirve.
Al crear un servicio M2M, los desarrolladores de aplicaciones se enfrentan a las siguientes preguntas:
- ¿cómo identificar los dispositivos;
- ¿qué algoritmo utilizar para verificar y confirmar la autenticidad;
- ¿qué protocolo de transporte elegir para interactuar con los dispositivos;
- ¿cómo garantizar la entrega de datos a los dispositivos;
- ¿cómo organizar y establecer reglas para el intercambio de datos con ellos;
- ¿cómo controlar y obtener información sobre su estado en tiempo real;
- ¿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 los servicios adicionales del operador para gestionar su dispositivo.
Para resolver estas cuestiones, es necesario crear soluciones técnicas propietarias «pesadas», lo que lleva a un aumento en el esfuerzo y el tiempo de comercialización de los servicios. Aquí es donde el nuevo nodo SCEF viene al rescate.
Según la definición de 3GPP, SCEF (función de exposición de capacidades de servicio) es un nuevo componente de la arquitectura 3GPP, cuya función es exponer de manera segura los servicios y capacidades proporcionados por las interfaces de red 3GPP a través de API.
En términos sencillos, SCEF es un intermediario entre la red y el servidor de aplicaciones (application server — AS), una única ventana de acceso a los servicios del operador para gestionar 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 del operador, permitiendo a los desarrolladores de aplicaciones abstraerse de los mecánicos específicos complejos de interacción con los dispositivos.
Mediante la transformación de los protocolos de red en una interfaz API familiar para los desarrolladores de aplicaciones, SCEF facilita la creación de nuevos servicios y reduce el tiempo de comercialización. Además, el nuevo nodo incluye funciones de identificación/autenticación de dispositivos móviles 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.
SCEF agrupa las interfaces necesarias para la autenticación y autorización de los servidores de aplicaciones, el mantenimiento de la movilidad de UE, la transmisión de datos y el disparo de dispositivos, así como el acceso a servicios adicionales y funciones de la red del operador.
Hacia AS va una única interfaz T8, la interfaz API (HTTP/JSON), estandarizada por 3GPP. Todas las interfaces, excepto T8, operan sobre el protocolo DIAMETER (ver Figura 1).
T6a es la interfaz entre SCEF y MME. Se utiliza para 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 los mismos.
S6t es la interfaz entre SCEF y HSS. Es necesaria para la autenticación del abonado, la autorización de los servidores de aplicaciones, la obtención del vínculo ID externo y IMSI/MSISDN, el aprovisionamiento de eventos de monitoreo y la recepción de informes sobre los mismos.
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á integrada en SCEF, por lo que para simplificar el diagrama no lo consideraremos por separado). Se utilizan para obtener información de ruta para el envío de SMS e interacción con el centro de SMS.
T8 es la interfaz API de interacción entre SCEF y los servidores de aplicaciones. A través de esta interfaz se transmiten tanto comandos de control como tráfico.
*en realidad hay más interfaces, aquí solo se enumeran las más básicas. La lista completa se presenta en 3GPP 23.682 (4.3.2 Lista de Puntos de Referencia).
A continuación se presentan las funciones y servicios clave de SCEF:
- vinculación del identificador de tarjeta SIM (IMSI) a ID externo;
- transmisión de tráfico no IP (Non-IP Data Delivery, NIDD);
- operaciones grupales, utilizando ID de grupo externo;
- soporte para el modo de transmisión de datos con confirmación;
- almacenamiento en búfer de datos MO (Mobile Originated) y MT (Mobile Terminated);
- autenticación y autorización de dispositivos y servidores de aplicaciones;
- uso simultáneo de los datos de un único UE por múltiples AS;
- soporte para funciones especiales de control del estado de UE (MONTE – Monitoring Events);
- disparo de dispositivos;
- provisión de roaming de datos no IP.
El principio fundamental de interacción entre AS y SCEF se basa en el esquema de las llamadas suscripciones. Cuando se necesita acceder a algún servicio SCEF para un UE específico, el servidor de aplicaciones debe crear una suscripción enviando un comando específico a la API del servicio solicitado y recibir a cambio un identificador único. A partir de ahí, todas las acciones y comunicaciones con el UE en el marco de este servicio se llevarán a cabo utilizando este identificador.
External ID: identificador universal del dispositivo
Uno de los cambios más importantes en el esquema de interacción entre AS y los dispositivos al trabajar a través de SCEF es la aparición del identificador universal. Ahora, en lugar del número de teléfono (MSISDN) o la dirección IP, como ocurría en las antiguas redes 2G/3G/LTE, el identificador del dispositivo para el servidor de aplicaciones se convierte en "external ID". Este 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. El external ID se vincula al IMSI, y el desarrollador puede estar seguro de que al dirigirse a un external ID específico, está interactuando con una tarjeta SIM concreta. Al utilizar un chip SIM, se crea una situación única en la que el external ID identifica de manera inequívoca un dispositivo específico.
Además, a un IMSI se le pueden vincular varios external ID, lo que genera una situación aún más interesante, donde el external ID identifica claramente una aplicación específica que es responsable de un servicio en un dispositivo concreto.
También 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últiples dispositivos, agrupados en una única lógica.
Debido a que para los desarrolladores, la transición al nuevo identificador de dispositivo no puede ser instantánea, SCEF ha dejado la posibilidad de comunicación entre AS y UE a través del número estándar: MSISDN.
Transmisión de tráfico non-IP (Non-IP Data Delivery, NIDD)
En NB-IoT, como parte de la optimización de los mecanismos de transmisión de pequeños volúmenes de datos, además 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ón IP, y los datos se transmiten sin utilizar el protocolo IP. El tráfico para estas conexiones puede ser enrutado de dos maneras: la clásica — MME -> SGW -> PGW y luego a través del túnel PtP hasta AS (fig. 2) o utilizando SCEF (fig. 3).
El método clásico no presenta ventajas significativas sobre el tráfico IP, salvo la reducción del tamaño 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ón con los dispositivos.
Al transferir datos a través de SCEF, surgen dos ventajas muy importantes sobre el tráfico IP clásico:
• Entrega de tráfico MT al dispositivo mediante ID externo.
Para enviar un mensaje a un dispositivo IP clásico, AS debe conocer su dirección IP. Aquí surge el problema: dado que el dispositivo normalmente recibe 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 se transforma la dirección gris en blanca. La asociación de direcciones IP grises y blancas dura un tiempo limitado, dependiendo de la configuración del NAT. En promedio, para TCP o UDP, no más de cinco minutos. Es decir, si durante 5 minutos no ha habido intercambio de datos con este dispositivo, la asociación se romperá y el dispositivo dejará de ser accesible a través de la dirección blanca con la cual se inició la sesión con AS. Hay varias soluciones:
1. Usar heartbeat. Una vez establecida la conexión, el dispositivo debe intercambiar paquetes con AS cada pocos minutos, evitando así que se cierre la traducción en el NAT. Pero aquí no puede haber ninguna consideración sobre la eficiencia energética.
2. Cada vez que sea necesario, verificar la existencia de paquetes para el dispositivo en AS — enviar un mensaje en uplink.
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áticas a los dispositivos. Esto funcionará, pero es casi irrealizable cuando se trata de un parque de miles o decenas de miles de dispositivos.
4. Finalmente, la opción más 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á una nueva dirección IPv6 y ya no será accesible a través de la anterior.
Por lo tanto, es necesario enviar un paquete de inicialización con el identificador del dispositivo al servidor para notificar la nueva dirección IP del dispositivo. Luego, se debe esperar a que llegue un paquete de confirmación de AS, lo que también afecta la eficiencia energética.
Estos métodos funcionan bien para dispositivos 2G/3G/LTE, donde no se establecen requisitos estrictos de autonomía y, como consecuencia, no hay restricciones en el 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 del dispositivo para AS es el ID externo, AS solo necesita enviar un paquete de datos a SCEF para un ID externo específico, y SCEF se encargará 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 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 de inmediato. Esto también se aplica a los comandos de control.
En cualquier momento, AS puede revocar un mensaje almacenado en búfer hacia UE o reemplazarlo por uno nuevo.
El mecanismo de almacenamiento en búfer también 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án en búfer y se entregarán garantizados tan pronto como AS esté disponible.
Como se mencionó anteriormente, el acceso a un servicio específico y a UE para AS (y NIDD es un servicio) está regulado por reglas y políticas del lado de SCEF, lo que permite implementar una funcionalidad única de uso simultáneo de los datos de un solo UE por múltiples AS. Es decir, si varios AS se han suscrito a un UE, después de recibir datos de UE, SCEF enviará esa información 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ógicas que operan con NB-IoT, se pueden vender los datos de ellas a muchos servicios simultáneamente.
Mecanismo de entrega garantizada de mensajes
Reliable Data Service — 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ón 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ón de tráfico es decisión del AS.
Si el mecanismo está activado, la UE incluye una bandera especial en el encabezado del paquete para la entrega garantizada del tráfico MO. Al recibir dicho paquete, el SCEF responde a la UE con una confirmación. Si la UE no recibe el paquete de confirmación, el paquete se reenvía hacia el SCEF. Lo mismo ocurre con el tráfico MT.
Monitoreo de dispositivos (monitoring events - MONTE)
Como se mencionó 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ón 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ámetros del dispositivo como el estado de conexión, disponibilidad para la comunicación, ubicación, estado de roaming, etc. Hablaremos más en detalle sobre cada uno 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 al SCEF un comando de la API MONTE, que incluye parámetros 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á autorizado para realizar la solicitud, el SCEF provisiona el evento en el HSS o en el MME según el tipo (ver figura 4). Cuando ocurre el evento, el MME o el HSS generan un informe hacia el SCEF, que lo envía al AS.
El aprovisionamiento de todos los eventos, excepto el "Número de UEs presentes en un área geográfica", se realiza a través del HSS. Los dos eventos "Cambio de Asociación IMSI-IMEI" y "Estado de Roaming" son rastreados directamente en el HSS, mientras que los demás son provisionados en el MME por el HSS.
Los eventos pueden ser tanto puntuales como periódicos, y dependen de su tipo.
El envío del informe de eventos (reporting) es realizado por el nodo que supervisa el evento, directamente al SCEF (ver figura 5).
Punto importante: los eventos de monitoreo pueden aplicarse tanto a dispositivos non-IP conectados a través de SCEF como a dispositivos IP que transmiten datos de la manera clásica a través de MME-SGW-PGW.
Analicemos cada uno de los eventos de monitoreo con más detalle:
Pérdida de conectividad — informa al AS que el UE ya no está disponible ni para tráfico de datos ni para intercambio de señales. Este evento ocurre cuando el temporizador de 'alcance móvil' 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áximo de Detección' — si durante este tiempo el UE no muestra ninguna actividad, el AS será informado de que el UE no está disponible, indicando la razón. También ocurre el evento si el UE ha sido forzado a salir de la red por alguna razón.
* Para que la red sepa que el dispositivo sigue estando disponible, este inicia periódicamente el procedimiento de actualización — Actualización de Área 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ía al dispositivo durante el procedimiento de Attach o el siguiente TAU. El temporizador de alcance móvil generalmente es varios minutos más largo que el T3412. Si el UE no realiza un TAU antes de que expire el 'temporizador de alcance móvil', la red lo considera como no disponible.
Disponibilidad del UE – Muestra cuándo el UE se vuelve disponible para tráfico 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ía un paquete uplink.
Informe de ubicación – Este tipo de eventos de monitoreo permite al AS solicitar datos sobre la ubicación del UE. Puede solicitarse la ubicación actual (Current Location) o la última conocida (Last Known Location, que se determina por el ID de celda desde la cual el dispositivo realizó TAU o transmitió tráfico por ú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 informes repetidos, notificando el MME al AS cada vez que el dispositivo cambie de ubicación.
Cambio de asociación IMSI-IMEI – Al activar este evento, SCEF comienza a rastrear el cambio de la asociación IMSI (identificador de la tarjeta SIM) e IMEI (identificador del dispositivo). Al ocurrir el evento, informa a AS. Puede ser utilizado para la reasignación automática de un ID externo al dispositivo durante el mantenimiento programado o para servir como identificador del robo del dispositivo.
Estado de Roaming – Este tipo de monitoreo es utilizado por AS para determinar si la UE está en la red nacional o en la red del socio de roaming. Opcionalmente, se puede transmitir el PLMN (Red Pública Mobile Nacional) del operador en el que el dispositivo está registrado.
Fallo de Comunicación — Este tipo de monitoreo informa a AS sobre fallos en la comunicación con el dispositivo, basándose en las razones de la interrupción de la conexión (código de causa de liberación) recibidas de la red de acceso radioeléctrico (protocolo S1-AP). Este evento puede ayudar a determinar la causa del fallo en la comunicación: 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ón de radio perdida con la UE).
Disponibilidad tras el fallo de DDN – Este evento informa a AS que el dispositivo se ha vuelto disponible después de un fallo de comunicación. Puede ser utilizado cuando es necesario enviar datos al dispositivo, pero el intento anterior fue fallido, ya que la UE no respondió a la notificación de la red (paginación), y los datos no fueron entregados. Si este tipo de monitoreo fue solicitado para la UE, tan pronto como el dispositivo inicie una comunicación entrante, realice un TAU o envíe datos en uplink, AS será informado de que el dispositivo se ha vuelto disponible. Dado que el procedimiento DDN (notificación de datos de bajada) funciona entre MME y S/P-GW, este tipo de monitoreo está disponible solo para dispositivos IP.
Estado de Conectividad PDN – Informa a AS sobre el cambio de estado del dispositivo (estado de conectividad PDN) — conexión (activación de PDN) o desconexión (eliminación de PDN). Esto puede ser utilizado por AS para iniciar la comunicación con la UE, o viceversa, para entender que la comunicación ya no es posible. Este tipo de monitoreo está disponible para dispositivos IP y non-IP.
Número de UEs presentes en un área geográfica – Este tipo de monitoreo es utilizado por AS para determinar la cantidad de UE en una zona geográfica específica.
Dispositivos de activación)
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ón 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és 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ón de la conexión PDN (análoga al PDP en 2G/3G) a través de eNodeB a MME-SGW-PGW.
En NB-IoT se define un método de conexión como "adjunto sin PDN", es decir, el UE se adjunta sin establecer la conexión PDN. En este caso, no está disponible para la transmisión de tráfico y solo puede enviar o recibir SMS. Para enviar un comando a dicho dispositivo para la activación de PDN y la conexión a AS, se desarrolló la funcionalidad "Dispositivo activado".
Al recibir un comando para conectar tal UE desde AS, SCEF, a través del centro de SMS, inicia el envío 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.
Pueden haber casos en los que la suscripción del SCEF al dispositivo expire. Sí, la suscripción tiene un período de validez, establecido por el operador o acordado con AS. Al expirar, el PDN será desactivado en MME y el dispositivo se volverá inaccesible para AS. En este caso, la funcionalidad "Dispositivo activado" también será útil. Al recibir nuevos datos de AS, SCEF determinará 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 evoluciona y se expande constantemente. En este momento, ya se han estandarizado más de una docena de servicios para SCEF. Ahora hemos cubierto solo las funciones principales y más demandadas por los desarrolladores; sobre las demás hablaremos en futuros artículos.
Inmediatamente surge la pregunta de cómo obtener acceso de prueba a este "maravilloso" nodo para pruebas preliminares y depuración 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ósito de la conexión, una descripción del posible caso y la información de contacto para la comunicación.
¡Hasta la próxima!
Autores:
- experto senior en soluciones convergentes y servicios multimedia Sergey Novikov ,
- experto en soluciones convergentes y servicios multimedia Alexey Lapshin
Fuente: habr.com
