Interacción con NIDD a través de SCEF utilizando la utilidad Postman. Un breve recorrido por SCEF y sus características

Este artículo permitirá a aquellos que recién están comenzando su desarrollo o que ya están aplicando tecnología NB-IoT tener una idea de cómo interactuar remotamente con el dispositivo NB-IoT.

imagen

Breve reseña


NB-IoT pisa fácilmente los talones de 2G y se ha establecido como un estándar de energía eficiente para las comunicaciones celulares, que en el futuro previsible podrá exprimir el 2G que ha fortalecido su posición. La razón de esto es la capacidad de abordar de manera flexible el tema del consumo de energía de una de las partes más consumidoras del dispositivo: el transmisor de radio. Si no profundiza en los detalles, entonces, junto con NB-IoT, tenemos la oportunidad de configurar de manera flexible los modos de funcionamiento del dispositivo configurando el horario de comunicación del dispositivo y la interacción del dispositivo con los servidores en Internet.

Paralelamente a esto, el número de dispositivos de suscriptor conectados simultáneamente a una celda está aumentando significativamente, así como los costos del operador móvil para mantener la operatividad de esta comunicación.

Se supone que el lector tiene una comprensión aproximada de la tecnología NB-IoT y hay una experiencia mínima de interacción.
El artículo se actualiza y actualiza periódicamente.


Dificultades dentro de la red NB-IoT


Junto con la capacidad de controlar el transmisor de radio y la alta eficiencia energética, ha surgido el problema de enviar datos en la dirección del servidor al módulo (dispositivo). La razón es que es posible proporcionar cientos de miles de dispositivos con direcciones IP blancas, pero esto implica una gran cantidad de sobrecarga y reduce la fiabilidad general de la red debido a su complejidad. El módulo recibe la dirección para el NAT del operador y es difícil para el operador traducirlo "fuera" debido a la gran cantidad de dispositivos. Por ejemplo: 100 mil dispositivos es el mismo número de direcciones IP y, en el marco de IPv4, simplemente no parece posible implementar esto. Cambiar a IPv6 puede resolver este problema, pero aún debe pagar por la dirección "blanca" del dispositivo en la red, lo que afectará significativamente el bolsillo de los clientes corporativos.

Es decir, en el caso general, resulta que el dispositivo solo puede funcionar en modo unidireccional transmitiendo datos al servidor sin la posibilidad de recibir datos del servidor, porque el servidor prácticamente no se da cuenta cuando el dispositivo se pone en contacto por primera vez. O, use en promedio no más de cinco minutos después de que se establezca la conexión entre el dispositivo y el servidor para transferir datos del servidor al dispositivo.

NIDD (Entrega de datos no IP): ¿por qué es necesario?


Cuando se trabaja con la red NB-IoT, es muy difícil recurrir a un dispositivo para transmitir un comando o algunos datos. Para resolver este problema, se inventó un mecanismo para optimizar la transferencia de pequeñas cantidades de datos, la entrega de datos no IP (NIDD). El mecanismo reduce el tamaño general del mensaje transmitido al reducir los encabezados. Esto, a su vez, afecta positivamente las características del dispositivo: reduce el consumo de energía y aumenta la autonomía (duración de la batería). Como resultado, el rechazo del soporte de IP conduce a dispositivos más baratos, menor tiempo de desarrollo, mayor competitividad en el mercado de dispositivos IoT, etc.

SCEF (Función de exposición de capacidad de servicio): un regalo para los usuarios


SCEF es un elemento funcional de la red que apareció por primera vez y 3GPP Release 13, implementado en el lado del operador móvil y que proporciona un canal de comunicación seguro entre el SCS / AS (Servidor de capacidad de servicio / Servidor de aplicaciones) y el dispositivo NB-IoT. SCEF proporciona un canal de comunicación cuando se comunica con el dispositivo a través de NIDD y proporciona acceso a capacidades / servicios de red adicionales de la red NB-IoT a través de una única interfaz de programación de aplicaciones (de la descripción de API T8). En 3GPP Release 13, solo se estandarizó el mecanismo SCEF para interactuar con las interfaces de red celular. Por lo tanto, la carga de la red se optimiza, la interacción con el dispositivo se simplifica, el algoritmo del propio dispositivo se simplifica.SCEF también cumple altos requisitos para la seguridad de la transmisión de datos y el cumplimiento de los requisitos para confirmar la transferencia exitosa de datos en ambas direcciones.


SCEF le permite abstraerse de sistemas complejos de interacción con el dispositivo NB-IoT, incluso cuando este último está en modo eDRX o PSM y no está disponible para la transferencia de datos en la dirección del servidor-> dispositivo. Cuando el dispositivo ha recibido el registro y está "de acuerdo" con la red del operador de red sobre el cronograma de comunicación, utilizando una interfaz simple, puede transferir datos al dispositivo y recibir datos del mismo, administrar la "suscripción" de su dispositivo y AS a ciertos eventos, establecer y vincular los únicos usted mismo Nombres de identificación universal y más. Todo esto a través de la misma interfaz: T8 API.

Es importante tener en cuenta que un servidor (AS) no puede ser uno, sino varios, y puede configurar de manera flexible la distribución de información entre servidores para ciertos eventos o grupos de dispositivos.

Cómo funciona


La solución más popular para organizar el acceso de un dispositivo a una red celular es el uso de un módulo celular, por ejemplo:


Al registrarse en una red celular, dicho módulo transmite al operador cierta información, incluido el IMSI de una tarjeta SIM de suscriptor que el operador puede asociar con la cuenta del suscriptor o el propio suscriptor si tiene acceso a la cuenta personal del operador. Detrás de la pantalla SCEF se esconde el conocimiento de la próxima sesión de comunicación con el dispositivo. El registro de un dispositivo no IP en la red del operador solo es posible si hay al menos una suscripción de SCS / AS a este dispositivo. Sin suscripción: nadie se comunicará con este dispositivo a través de NIDD, y el dispositivo no se registrará en la red. Por lo tanto, SCEF, al conocer la próxima sesión de comunicación, puede transferir datos desde / hacia el dispositivo, de acuerdo con los parámetros de entrega especificados y la vida útil del mensaje transmitido, sin la necesidad de organizar un monitoreo adicional del estado de la transferencia de datos y el control de entrega.

Ligereza


Encapsular unidades de bytes de datos del dispositivo en el protocolo TCP y transferirlo al servidor es costoso en términos de cientos de miles de dispositivos de suscriptores en la flota de la compañía. SCEF le permite abandonar la IP en el dispositivo y transferir solo datos que no sean IP, sin encabezados IP a través del canal de señal, lo que contribuye a una reducción múltiple en el costo del byte transmitido y proporciona beneficios adicionales del uso del servicio. Además, SCEF no realiza ningún cambio en los datos transmitidos tanto al dispositivo como desde este, la carga útil se transmite de forma transparente. Por lo tanto, usando NIDD es posible transferir no solo datos no estructurados, sino también datos "empaquetados" en un formato estandarizado comprensible, como JSON, para simplificar el procesamiento de datos en el lado AS.

Comienzo de trabajo


La estructura del URI (Identificador Uniforme de Recursos) en el ejemplo de Cartero


En primer lugar, debe obtener acceso a su cuenta personal del operador (servicio M2M-manager). Para la implementación comercial de MTS, se proporciona una única interfaz de cuenta personal, donde puede crear independientemente APN, acceso de acceso / contraseña a la API y asignar los nombres ScsAsID, extID para sus dispositivos.

Aquellos. al menos necesitaremos:
  • ScsAsID: su ID de AS
  • APN: el que generalmente se usa para interactuar con la red no funcionará
  • Inicio de sesión / Contraseña: datos para acceder a su cuenta personal e interacción con SCEF
  • URI: dirección HTTTP y puerto en la red que le proporciona SCEF
  • externalID - ID de nuestro dispositivo


Pasemos a practicar


La teoría ha terminado, pasemos a la parte más interesante: la práctica en el módulo de producción de SIMCom Wireless Solutions: SIM7020E .

Primero debe configurar el módulo para que funcione con NIDD. Para hacer esto, primero ponga el módulo en modo CFUN = 0 y configúrelo:

AT+CFUN=0
+CPIN: NOT READY

OK
AT+ENVDM=1,tel_conn_mgr,default_pdn_flag,1,30
OK
AT*MCGDEFCONT="Non-IP","<APN>"
OK
AT+CFUN=1
OK

+CPIN: READY
AT+EGACT=1,4,"<APN>"
+EGACT:1

OK

+EGACT:1,1,1,4

Comprobación del registro del módulo en la red de paquetes de datos

AT+CGREG?
+CGREG: 0,1

OK

Y termine de configurar NIDD

AT+NIDD=0,"<APN>","<login>","<pass>"
+NIDD=0,0

OK

La respuesta del módulo contendrá account_id aquí: + NIDD = 0, <account_id>: esto será útil al activar NIDD en el módulo.

AT+NIDD=1,0
+NIDD=1,0

OK

En este caso, account_id es 0.

Listo. En esta etapa, se completa el trabajo con el módulo. Pasemos a configurar SCEF.

Un punto importante: sin una suscripción registrada en SCEF, ¡el módulo no recibirá registro en la red!

SCEF


API T8


Hay un documento especial que detalla la interacción con SCEF. Esta API define un conjunto de modelos de datos, recursos y procedimientos relacionados para transmitir datos que no son IP.



Trabajar con SCEF y suscripciones de servicio: JSON (JavaScript Object Notation)


Los datos que incluyen la configuración de SCEF y se transmiten a través de HTTP / 1.1 a SCEF deben codificarse en formato JSON, y el cuerpo de la solicitud HTTP en el campo Tipo de contenido debe incluir el encabezado "application / json". Al mismo tiempo, si el mensaje se entregó al destinatario y se recibió la confirmación de entrega, SCEF debe eliminar la configuración adecuada, enviar el mensaje a través de HTTP POST para AS con el código de estado "200 OK" y activar el informe del evento.

Cartero


No profundizaré en cómo trabajar con esta utilidad, en Internet puedes encontrar muchas reseñas. Solo puedo decir que tiene algunas limitaciones en su versión gratuita, pero no necesitamos mucho, la funcionalidad proporcionada de forma gratuita es más que suficiente para nuestras tareas.

Después de descargarlo y abrirlo, la primera pestaña nos dará la bienvenida: Launchpad, donde se nos ofrecerá crear nuestra primera solicitud, no la rechazaremos.


Proceda inmediatamente a la configuración de nuestro nuevo dispositivo.

Inicialmente, hemos configurado el método GET, cámbielo a POST (un poco más tarde quedará claro por qué es necesario). En la pestaña "Autorización", ingrese las "credenciales" que tenemos a mano:


Ahora cree nuestra primera solicitud:


En el cuerpo de la solicitud, indicamos:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "pdnEstablishmentOption": "WAIT_FOR_UE",
    "duration":"2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>"
}

¡Importante!
:
  • “duration” – duration SLA SCEF (SCSAS/ID) , SCEF ,
  • “maximumPacketSize” – /

Observemos de inmediato que las siguientes opciones son posibles en "pdnEstablishmentOption":
  • WAIT_FOR_UE - búfer si el dispositivo no está disponible (no registrado en la red o en el PSM o en otro estado)
  • INDICATE_ERROR: responde inmediatamente con un error si el dispositivo no está disponible
  • SEND_TRIGGER: utilice el servicio de activación de dispositivos (canal de entrega alternativo a través de SMS). Este artículo no se considera.

Usamos el mismo parámetro para enviar datos al dispositivo. Y al crear una suscripción, podemos enviar datos de inmediato al dispositivo, reduciendo la cantidad de solicitudes de API.
¡Todas! Puede hacer clic en el botón Enviar y examinar cuidadosamente lo que obtenemos en respuesta de SCEF:

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>",
    “reliableDataService": false,
    "maximumPacketSize": 500,
    "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >",
    "status": "ACTIVE"
}

En la línea automática, estamos interesados ​​principalmente en la ID de la configuración que creamos, es extremadamente indeseable perderla, ya que lo más probable es que los operadores no admitan la función de solicitud de todas las configuraciones creadas. Cuando se crean varios miles de dispositivos en el marco de un ScsAsID, se creará demasiada carga en los servidores SCEF para transmitir todas las configuraciones de dispositivos. Lo tomamos como una regla: un dispositivo = una suscripción como parte del servicio ScsAsID.

Por lo tanto, ya podemos recibir datos del módulo en el servidor, la dirección IP y el puerto que indicamos anteriormente.

Transferencia de datos del módulo a AS


Intentemos transferir datos del dispositivo a AS, regrese al módulo SIM7020E y si no lo tocamos desde el capítulo anterior y no lo apagamos, le enviaremos el comando:

AT+NIDD=3,<account_id>,"6162636465"
OK

Tenga en cuenta que nuestro mensaje está codificado en HEX y contiene una secuencia simple: "abcde".
Casi inmediatamente en el servidor (AS), que es el host, veremos:

POST / HTTP/1.1
OCSGHTTPProcessor: 147ff7c6-a43d-4fc9-b303-0ca50f497747
X-callback-t8-type: 3
X-callback-url: http://<IP >:<port>
X-api-network-service-node: 0
Content-Type: application/json
Content-Length: 214
Host: <IP >:<port>
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.1.3 (Java/1.8.0_181)

{"externalId":"<ID >","niddConfiguration":"/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >","data":"YWJjZGU=","reliableDataService":false}

El mensaje en sí llegó en la codificación Base64 y se ve así:
YWJjZGU=

Si traducimos de la codificación Base64, obtenemos nuestro mensaje original:
abcde

La codificación Base64 se usa debido al hecho de que cuando se usa la codificación ASCII, a veces se pierden algunos datos y el uso de Base64 hace que la transmisión sea más confiable.

También debe tenerse en cuenta que en este caso la información transmitida desde el módulo no se almacena dentro de SCEF y se transmite inmediatamente a nuestro servidor a través de HTTP.

Transferencia de datos de AS a módulo


Para enviar datos en la dirección de nuestro AS al módulo, regresemos a Postman y creemos una nueva solicitud utilizando el método POST y la codificación Base64. Enviaremos 1234567890 (en Base64: MTIzNDU2Nzg5MA ==) a nuestro módulo:



Tenga en cuenta que ha aparecido un apéndice en el campo "dirección", en el que indicamos para qué configuración queremos enviar el mensaje. Si se incluyen varios dispositivos en nuestra configuración, puede usar el identificador "externalGroupID" y luego todos recibirán estos datos. Otro punto importante es la vida útil del mensaje enviado, indicado en segundos y tiene un rango bastante amplio.

Por cierto, si el dispositivo no está en línea en este momento, nuestro mensaje se almacenará en SCEF, y la línea "MaximumLatency" nos dirá cuántos segundos quedan hasta que se destruya el mensaje si el dispositivo no se pone en contacto antes del temporizador que configuramos. . A continuación se muestra cómo se verá la configuración SCEF actual solicitada (utilizando el mecanismo GET, más sobre eso a continuación):

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": "http://<IP >:<port>",
    "reliableDataService": false,
    "status": "ACTIVE",
    "niddDownlinkDataTransfers": [
    {
        "externalId": "<ID >",
        "reliableDataService": false,
        "data": "MDEyMzQ1Njc4OTA=",
        "maximumLatency": 96,
        "priority": 1,
        "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1"
    }
}

Si, después de que expira el temporizador, el dispositivo aún no ha sido contactado, SCEF informará a su servidor (AS) que el mensaje no se entregó debido a la expiración del temporizador y el mensaje se eliminará:

POST / HTTP/1.1
OCSGHTTPProcessor: 14c8cab8-ecce-4868-a59e-1f784224518b
X-callback-t8-type: 4
X-callback-url: http://<IP >:<port>
X-api-network-service-node: 0
Content-Type: application/json
Content-Length: 139
Host: <IP >:<port>
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.1.3 (Java/1.8.0_181)

{"niddDownlinkDataTransfer":"/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1","status":"FAILURE"}

Si tiene éxito, SCEF responderá de inmediato:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "status": "SUCCESS"
}

Puede agregar la capacidad de priorizar mensajes en caso de que estén almacenados en el búfer. Ajustado por parámetro de "prioridad". Cuando se envía un nuevo mensaje al dispositivo y si SCEF supera el búfer de entrega, el mensaje será reemplazado por un mensaje con una prioridad más baja; de lo contrario, el mensaje no será aceptado para la entrega. También es posible eliminar un mensaje del búfer.

Si el mensaje no se puede entregar y se almacena en el búfer, recibirá lo siguiente:

{
    "externalId": "<ID >",
    "reliableDataService": false,
    "self": "/3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/2",
   "status": "BUFFERING"
}

¡Importante!
:
/<ID >/downlink-data-deliveries/1
– SCEF. , . .

Al recibir el mensaje, el módulo informará el siguiente URC:

+NIDD=4,0,11,0,"3031323334353637383930"

Que en traducción de HEX a ASCII será nuestro mensaje:

1234567890

Solo déjalo aquí. Notificación de entrega de un mensaje "almacenado":

{
"niddDownlinkDataTransfer":"3gpp-nidd/v1/<ScsAsID>/configurations/<ID >/downlink-data-deliveries/1",
"status":"SUCCESS"
}

Es posible monitorear el estado del dispositivo a través de otro servicio SCEF llamado "Evento de Monitoreo (MONTE)". Dentro de MONTE, es posible recibir notificaciones de eventos y hora (por ejemplo, cuando el dispositivo esté disponible), utilizando un sistema de suscripción similar. Pero hablemos de esto en otro momento.

Obteniendo configuración de SCEF


Probablemente haya notado que puede obtener la configuración actual de SCEF. Vamos a hacer eso. Tomamos el Cartero que ya nos ha encantado y creamos la siguiente solicitud utilizando el método GET:


Aquellos. Dejamos vacío el cuerpo del mensaje, y en la barra de direcciones solo necesitamos especificar el ID de la configuración creada para nosotros para recibir su estado actual en respuesta:

{
    "externalId": "<ID >",
    "duration": "2020-12-31T23:59:59Z",
    "notificationDestination": " http://<IP >:<port>",
    "reliableDataService": false,
    "status": "ACTIVE",
    "niddDownlinkDataTransfers": []
}

Eliminar una configuración en SCEF


Bueno y lo último: eliminaremos la configuración creada por nosotros. Para hacer esto, use la misma barra de direcciones que en la configuración actual, pero cámbiela a DELETE:


En respuesta, recibiremos:

{
    "externalId": " <ID >",
    "duration": "2020-12-31T23:59:59Z",
    " notificationDestination": " http://<IP >:<port>",
    "reliableDataService": false,
    "status": "TERMINATED"
}

Donde en la línea "estado" veremos que la configuración creada por nosotros es eliminada.

Conclusión


Se puede escribir más de una disertación sobre el tema del uso de SCEF, el tema es extenso y pronto se volverá extremadamente relevante para muchos dispositivos M2M en todas las áreas, y especialmente para Internet de las cosas. Lo principal que quería transmitirles era cómo comenzar a trabajar con NIDD y SCEF fuera de la caja para que puedan resolverlo por su cuenta. Pero también siempre estoy dispuesto a ayudarlo: support@simcom.com (marcado para el equipo RUS), en la carta debe indicar sus datos de contacto y algunas palabras sobre su proyecto.

En los siguientes artículos analizaremos cuidadosamente otros aspectos del trabajo con módulos celulares y usted escribirá en los comentarios qué tema le interesará.

Quiero agradecer especialmente a Sergey Novikov, el experto principal de soluciones convergentes y servicios multimedia.sanov) de MTS por su valiosa ayuda en la preparación del artículo.

Fuentes utilizadas


NB-IoT: ¿cómo funciona? Parte 3: SCEF: una única ventana de acceso a los servicios del operador
ETSI TS 129 122

All Articles