NB-IoT: como funciona? Parte 3: SCEF – xanela única de acceso aos servizos do operador

No artigo “NB-IoT: como funciona? Parte 2", falando da arquitectura do núcleo de paquetes da rede NB-IoT, mencionamos a aparición dun novo nodo SCEF. Explicamos na terceira parte que é e por que é necesario?

Ao crear un servizo M2M, os desenvolvedores de aplicacións enfróntanse ás seguintes preguntas:

• como identificar os dispositivos;
• que algoritmo de verificación e autenticación usar;
• que protocolo de transporte escoller para interactuar cos dispositivos;
• como entregar datos de forma fiable aos dispositivos;
• como organizar e establecer regras para o intercambio de datos con eles;
• como controlar e obter información sobre o seu estado en liña;
• como entregar datos simultaneamente a un grupo dos teus dispositivos;
• como enviar datos simultáneamente dun dispositivo a varios clientes;
• como obter acceso unificado a servizos adicionais do operador para xestionar o seu dispositivo.

Para resolvelos, é necesario crear solucións propietarias tecnicamente "pesadas", o que leva a un aumento dos custos laborais e dos servizos de tempo de comercialización. Aquí é onde o novo nodo SCEF vén ao rescate.

Tal e como define 3GPP, a SCEF (función de exposición da capacidade de servizo) é un compoñente completamente novo da arquitectura 3GPP, cuxa función é expoñer de forma segura os servizos e as capacidades proporcionadas polas interfaces de rede 3GPP a través das API.

En palabras sinxelas, SCEF é un intermediario entre a rede e o servidor de aplicacións (AS), unha única fiestra de acceso aos servizos do operador para xestionar o seu dispositivo M2M na rede NB-IoT a través dunha interface API intuitiva e estandarizada.

SCEF oculta a complexidade da rede dun operador, o que permite aos desenvolvedores de aplicacións abstraer mecanismos complexos e específicos do dispositivo para interactuar cos dispositivos.

Ao transformar os protocolos de rede nunha API familiar para os desenvolvedores de aplicacións, a API SCEF facilita a creación de novos servizos e reduce o tempo de comercialización. O novo nodo tamén inclúe funcións para identificar/autenticar dispositivos móbiles, definindo as regras de intercambio de datos entre o dispositivo e AS, eliminando a necesidade de que os desenvolvedores de aplicacións implementen estas funcións pola súa banda, trasladando estas funcións aos ombreiros do operador.

SCEF abrangue as interfaces necesarias para a autenticación e autorización dos servidores de aplicacións, o mantemento da mobilidade da UE, a transferencia de datos e a activación do dispositivo, o acceso a servizos adicionais e as capacidades de rede do operador.

Cara ao AS hai unha única interface T8, unha API (HTTP/JSON) estandarizada por 3GPP. Todas as interfaces, a excepción da T8, funcionan baseándose no protocolo DIAMETER (Fig. 1).

T6a: interface entre SCEF e MME. Úsase para procedementos de xestión de Mobilidade/Sesión, transmisión de datos non IP, provisión de eventos de seguimento e recepción de informes sobre eles.

S6t: interface entre SCEF e HSS. Necesario para a autenticación de subscritores, autorización de servidores de aplicacións, obtención dunha combinación de ID externo e IMSI/MSISDN, aprovisionamento de eventos de seguimento e recepción de informes sobre eles.

S6m/T4: interfaces de SCEF a HSS e SMS-C (3GPP define o nodo MTC-IWF, que se usa para a activación do dispositivo e a transmisión de SMS en redes NB-IoT. Non obstante, en todas as implementacións a funcionalidade deste nodo está integrada en SCEF, polo que para simplificar o circuíto, non o consideraremos por separado). Úsase para obter información de enrutamento para enviar SMS e interactuar co centro de SMS.

T8 – Interface API para a interacción SCEF cos servidores de aplicacións. Tanto os comandos de control como o tráfico transmítense a través desta interface.

*en realidade hai máis interfaces; aquí se enumeran só as máis básicas. Unha lista completa aparece en 3GPP 23.682 (4.3.2 Lista de puntos de referencia).

Abaixo amósanse as funcións e servizos clave de SCEF:

• vincular o identificador da tarxeta SIM (IMSI) coa identificación externa;
• transmisión de tráfico non IP (Non-IP Data Delivery, NIDD);
• operacións de grupo utilizando ID de grupo externo;
• soporte para o modo de transmisión de datos con confirmación;
• almacenamento en búfer de datos MO (Mobile Originated) e MT (Mobile Terminated);
• autenticación e autorización de dispositivos e servidores de aplicacións;
• uso simultáneo de datos dun UE por varios AS;
• soporte para funcións especiais de monitorización do estado da UE (MONTE – Monitoring Events);
• disparo do dispositivo;
• proporcionando itinerancia de datos non IP.

O principio básico de interacción entre AS e SCEF baséase no chamado esquema. subscricións. Se é necesario acceder a calquera servizo SCEF para un UE específico, o servidor de aplicacións debe crear unha subscrición enviando un comando á API específica do servizo solicitado e recibir un identificador único como resposta. Despois diso, realizaranse todas as accións e comunicacións posteriores coa UE no marco deste servizo utilizando este identificador.

ID externo: identificador universal do dispositivo

Un dos cambios máis importantes no esquema de interacción entre AS e dispositivos cando se traballa a través de SCEF é a aparición dun identificador universal. Agora, en lugar dun número de teléfono (MSISDN) ou enderezo IP, como era o caso da clásica rede 2G/3G/LTE, o identificador do dispositivo para o servidor de aplicacións pasa a ser "ID externo". Está definido polo estándar nun formato familiar para os desenvolvedores de aplicacións " @ "

Os desenvolvedores xa non precisan implementar algoritmos de autenticación de dispositivos; a rede asume completamente esta función. O ID externo está vinculado a IMSI e o programador pode estar seguro de que ao acceder a un ID externo específico, interactúa cunha tarxeta SIM específica. Ao usar un chip SIM, obtén unha situación completamente única cando o ID externo identifica un dispositivo específico.

Ademais, pódense vincular varios ID externos a un IMSI; unha situación aínda máis interesante xorde cando o ID externo identifica de forma única unha aplicación específica responsable dun servizo específico nun dispositivo específico.

Tamén aparece un identificador de grupo: ID de grupo externo, que inclúe un conxunto de ID externos individuais. Agora, cunha solicitude a SCEF, AS pode iniciar operacións de grupo: enviar datos ou comandos de control a varios dispositivos unidos nun único grupo lóxico.

Debido ao feito de que para os desenvolvedores de AS a transición a un novo identificador de dispositivo non pode ser instantánea, SCEF deixou a posibilidade de comunicación de AS coa UE a través dun número estándar - MSISDN.

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

En NB-IoT, como parte da optimización dos mecanismos para transmitir pequenas cantidades de datos, ademais dos tipos de PDN xa existentes, como IPv4, IPv6 e IPv4v6, apareceu outro tipo: non IP. Neste caso, ao dispositivo (UE) non se lle asigna un enderezo IP e os datos transmítense sen utilizar o protocolo IP. O tráfico para tales conexións pódese enrutar de dúas formas: clásica - MME -> SGW -> PGW e despois a través do túnel PtP ata AS (Fig. 2) ou usando SCEF (Fig. 3).

O método clásico non ofrece vantaxes especiais sobre o tráfico IP, agás a redución do tamaño dos paquetes transmitidos debido á ausencia de cabeceiras IP. O uso de SCEF abre unha serie de novas posibilidades e simplifica significativamente os procedementos para interactuar cos dispositivos.

Ao transmitir datos a través de SCEF, aparecen dúas vantaxes moi importantes sobre o tráfico IP clásico:


Entrega de tráfico MT ao dispositivo mediante ID externo

Para enviar unha mensaxe a un dispositivo IP clásico, o AS debe coñecer o seu enderezo IP. Aquí xorde un problema: dado que o dispositivo adoita recibir un enderezo IP "gris" ao rexistrarse, comunícase co servidor de aplicacións, que se atopa en Internet, a través dun nodo NAT, onde o enderezo gris se traduce en branco. A combinación de enderezos IP grises e brancos dura un tempo limitado, dependendo da configuración do NAT. De media, para TCP ou UDP - non máis de cinco minutos. É dicir, se non hai intercambio de datos con este dispositivo nun prazo de 5 minutos, a conexión desintegrarase e xa non se poderá acceder ao dispositivo no enderezo branco co que se iniciou a sesión con AS. Hai varias solucións:

1. Usa o latido do corazón. Unha vez establecida a conexión, o dispositivo debe intercambiar paquetes co AS cada poucos minutos, evitando así o peche das traducións NAT. Pero aquí non se pode falar de eficiencia enerxética.

2. Cada vez, se é necesario, comprobe a dispoñibilidade de paquetes para o dispositivo no AS: envíe unha mensaxe ao enlace ascendente.

3. Cree un APN privado (VRF), onde o servidor de aplicacións e os dispositivos estarán na mesma subrede e asigne enderezos IP estáticos aos dispositivos. Funcionará, pero é case imposible cando falamos dunha flota de miles, decenas de miles de dispositivos.

4. Por último, a opción máis axeitada: empregar IPv6, non precisa de NAT, xa que os enderezos IPv6 son directamente accesibles desde Internet. Non obstante, mesmo neste caso, cando o dispositivo se rexistre de novo, recibirá un novo enderezo IPv6 e xa non será accesible mediante o anterior.

En consecuencia, é necesario enviar algún paquete de inicialización cun identificador de dispositivo ao servidor para informar do novo enderezo IP do dispositivo. A continuación, agarde un paquete de confirmación de AS, que tamén afecta á eficiencia enerxética.

Estes métodos funcionan ben para dispositivos 2G/3G/LTE, onde o dispositivo non ten requisitos estritos de autonomía e, como resultado, non hai restricións de tempo e tráfico. Estes métodos non son axeitados para NB-IoT debido ao seu alto consumo de enerxía.

SCEF resolve este problema: dado que o único identificador de dispositivo para un AS é un ID externo, o AS só necesita enviar un paquete de datos a SCEF para un ID externo específico e SCEF encárgase do resto. No caso de que o dispositivo estea no modo de aforro de enerxía PSM ou eDRX, os datos almacenaranse e entregaranse cando o dispositivo estea dispoñible. Se o dispositivo está dispoñible para o tráfico, os datos entregaranse inmediatamente. O mesmo ocorre cos equipos directivos.

En calquera momento, o AS pode recuperar a mensaxe almacenada no búfer ao UE ou substituíla por unha nova.

O mecanismo de búfer tamén se pode usar cando se transmiten datos MO desde o UE ao AS. Se SCEF non puido entregar datos ao AS inmediatamente, por exemplo, se se está a realizar traballos de mantemento nos servidores AS, estes paquetes almacenaranse e garantiranse que se entregarán en canto o AS estea dispoñible.

Como se indicou anteriormente, o acceso a un servizo e UE específicos para un AS (e NIDD é un servizo) está regulado por regras e políticas do lado SCEF, o que permite a posibilidade única de usar simultáneamente datos dun UE por varios AS. Eses. se varios AS están subscritos a un UE, despois de recibir datos do UE, SCEF enviaraos a todos os AS subscritos. Isto é moi axeitado para os casos nos que o creador dunha flota de dispositivos especializados comparte datos entre varios clientes. Por exemplo, ao crear unha rede de estacións meteorolóxicas que funcionan en NB-IoT, podes vender os datos delas a moitos servizos simultaneamente.

Mecanismo de entrega de mensaxes garantido

Reliable Data Service é un mecanismo para a entrega garantida de mensaxes MO e MT sen o uso de algoritmos especializados a nivel de protocolo, como, por exemplo, o handshake en TCP. Funciona incluíndo unha bandeira especial na parte de servizo da mensaxe cando se intercambia entre o UE e o SCEF. A AS decide se activar ou non este mecanismo ao transmitir o tráfico.

Se o mecanismo está activado, o UE inclúe unha bandeira especial na parte superior do paquete cando require a entrega garantida do tráfico MO. Tras recibir tal paquete, o SCEF responde á UE cun acuse de recibo. Se o UE non recibe o paquete de acuse de recibo, o paquete a SCEF será enviado de novo. O mesmo ocorre co tráfico MT.

Monitorización de dispositivos (seguimento de eventos - MONTE)

Como se mencionou anteriormente, a funcionalidade SCEF, entre outras cousas, inclúe funcións de vixilancia do estado da UE, as denominadas. monitorización do dispositivo. E se os novos identificadores e mecanismos de transferencia de datos son optimizacións (aínda que moi graves) dos procedementos existentes, entón MONTE é unha funcionalidade completamente nova que non está dispoñible nas redes 2G/3G/LTE. MONTE permite que AS monitoree os parámetros do dispositivo como o estado da conexión, a dispoñibilidade da comunicación, a localización, o estado de itinerancia, etc. Falaremos de cada un con máis detalle un pouco máis adiante.

Se é necesario activar algún evento de monitorización para un dispositivo ou grupo de dispositivos, o AS subscríbese ao servizo correspondente enviando a SCEF o comando API MONTE correspondente, que inclúe parámetros como ID externo ou ID de grupo externo, identificador AS, monitorización. tipo, número de informes, que AS quere recibir. Se o AS está autorizado para executar a solicitude, SCEF, segundo o tipo, subministrará o evento ao HSS ou MME (Fig. 4). Cando se produce un evento, o MME ou HSS xera un informe a SCEF, que o envía ao AS.

O aprovisionamento de todos os eventos, a excepción do "Número de UE presentes nunha zona xeográfica", prodúcese a través de HSS. Dous eventos "Cambio da asociación IMSI-IMEI" e "Estado de itinerancia" son rastrexados directamente en HSS, o resto será subministrado por HSS en MME.
Os eventos poden ser puntuais ou periódicos e están determinados polo seu tipo.

O envío dun informe sobre un evento (informe) realízao o nodo que rastrexa o evento directamente a SCEF (Fig. 5).

Punto importante: Os eventos de monitorización pódense aplicar tanto a dispositivos non IP conectados a través de SCEF como a dispositivos IP que transmiten datos do xeito clásico a través de MME-SGW-PGW.

Vexamos máis de cerca cada un dos eventos de seguimento:

Perda de conectividade — informa ao AS de que o UE xa non está dispoñible para o tráfico de datos nin para a sinalización. O evento ocorre cando o "temporizador de accesibilidade móbil" para a UE caduca no MME. Nunha solicitude deste tipo de vixilancia, o AS pode indicar o seu valor de "Tempo máximo de detección" - se durante este tempo o UE non mostra actividade, o AS será informado de que o UE non está dispoñible, indicando o motivo. O evento tamén ocorre se a UE foi eliminada pola rede por calquera motivo.

* Para que a rede saiba que o dispositivo aínda está dispoñible, inicia periodicamente un procedemento de actualización: Actualización da área de seguimento (TAU). A frecuencia deste procedemento é definida pola rede mediante o temporizador T3412 ou (T3412_extended no caso de PSM), cuxo valor se transmite ao dispositivo durante o procedemento de conexión ou a seguinte TAU. O temporizador de accesibilidade móbil adoita ser varios minutos máis longo que o T3412. Se a UE non fixo unha TAU antes do vencemento do "Temporizador de accesibilidade móbil", a rede considera que xa non é accesible.

Accesibilidade da UE – Indica cando o UE está dispoñible para o tráfico DL ou SMS. Isto ocorre cando o UE está dispoñible para paginación (para un UE no modo eDRX) ou cando o UE entra no modo ECM-CONNECTED (para un UE en modo PSM ou eDRX), é dicir. fai un TAU ou envía un paquete de enlace ascendente.

Informe de localización – Este tipo de eventos de monitorización permite ao AS consultar a localización do UE. Pódese solicitar a localización actual (Localización actual) ou a última localización coñecida (Determinada polo ID da célula desde a que o dispositivo fixo TAU ou transmitiu tráfico a última vez), o que é relevante para os dispositivos en modos de aforro de enerxía PSM ou eDRX. Para a "Localización actual", o AS pode solicitar respostas repetidas, e o MME informará ao AS cada vez que cambia a localización do dispositivo.

Cambio de Asociación IMSI-IMEI – Cando este evento está activado, SCEF comeza a supervisar os cambios na combinación de IMSI (identificador de tarxeta SIM) e IMEI (identificador de dispositivo). Cando ocorre un evento, informa AS. Pódese usar para vincular automaticamente un ID externo a un dispositivo durante o traballo de substitución programado ou servir como identificador para o roubo dun dispositivo.

Estado de itinerancia – AS utiliza este tipo de vixilancia para determinar se o UE está na rede doméstica ou na rede dun socio itinerante. Opcionalmente pódese transmitir a PLMN (Public Land Mobile Network) da operadora na que estea rexistrado o dispositivo.

Fallo de comunicación — Este tipo de monitorización informa ao AS sobre fallos na comunicación co dispositivo, en función dos motivos da perda de conexión (código de causa de liberación) recibidos da rede de acceso radioeléctrico (protocolo S1-AP). Este evento pode axudar a determinar por que fallou a comunicación, debido a problemas na rede, por exemplo, cando o eNodeb está sobrecargado (recursos de radio non dispoñibles) ou debido a un fallo do propio dispositivo (conexión de radio con UE perdido).

Dispoñibilidade despois dun fallo de DDN – este evento informa ao AS de que o dispositivo está dispoñible despois dun fallo de comunicación. Pódese usar cando hai que transferir datos a un dispositivo, pero o intento anterior non foi exitoso porque o UE non respondeu a unha notificación da rede (paging) e os datos non foron entregados. Se se solicitou este tipo de monitorización para a UE, en canto o dispositivo realice unha comunicación entrante, realice unha TAU ou envíe datos ao enlace ascendente, o AS será informado de que o dispositivo está dispoñible. Dado que o procedemento DDN (notificación de datos de enlace descendente) funciona entre MME e S/P-GW, este tipo de monitorización só está dispoñible para dispositivos IP.

Estado de conectividade PDN – informa a AS cando o estado do dispositivo cambia (estado de conectividade PDN) - conexión (activación PDN) ou desconexión (eliminación de PDN). Isto pode ser usado polo AS para iniciar a comunicación co UE, ou viceversa, para entender que a comunicación xa non é posible. Este tipo de monitorización está dispoñible para dispositivos IP e non IP.

Número de UE presentes nunha zona xeográfica – Este tipo de seguimento é utilizado polo AS para determinar o número de UEs nunha determinada área xeográfica.

Dispositivo de disparo)

Nas redes 2G/3G, o procedemento de rexistro na rede foi de dúas etapas: primeiro, o dispositivo rexistrado co SGSN (procedemento de conexión), despois, se é necesario, activou o contexto PDP: unha conexión coa pasarela de paquetes (GGSN). para transmitir datos. Nas redes 3G, estes dous procedementos ocorreron secuencialmente, é dicir. o dispositivo non agardou o momento no que precisaba transferir datos, senón que activou o PDP inmediatamente despois de completar o procedemento de conexión. En LTE, estes dous procedementos combináronse nun só, é dicir, ao conectar, o dispositivo solicitaba inmediatamente a activación da conexión PDN (análoga a PDP en 2G/3G) a través do eNodeB ao MME-SGW-PGW.

NB-IoT define un método de conexión como "unir sen PDN", é dicir, o UE se conecta sen establecer unha conexión PDN. Neste caso, non está dispoñible para transmitir tráfico e só pode recibir ou enviar SMS. Para enviar un comando a un dispositivo deste tipo para activar PDN e conectarse a AS, desenvolveuse a funcionalidade "Disparo do dispositivo".

Ao recibir un comando para conectar un UE deste tipo do AS, SCEF inicia o envío dun SMS de control ao dispositivo a través do centro de SMS. Ao recibir unha SMS, o dispositivo activa o PDN e conéctase ao AS para recibir máis instrucións ou transferir datos.

Pode haber momentos nos que a subscrición do teu dispositivo caduque en SCEF. Si, a subscrición ten a súa propia vida útil, definida polo operador ou acordada con AS. Ao caducar, o PDN desactivarase no MME e o dispositivo non estará dispoñible para o AS. Neste caso, a funcionalidade de "Activación do dispositivo" tamén axudará. Ao recibir novos datos de AS, SCEF descubrirá o estado da conexión do dispositivo e entregará os datos a través da canle SMS.

Conclusión

A funcionalidade de SCEF, por suposto, non se limita aos servizos descritos anteriormente e está en constante evolución e expansión. Actualmente, xa están estandarizados máis dunha ducia de servizos para SCEF. Agora tocamos só as funcións principais que demandan os desenvolvedores; do resto falaremos en artigos futuros.

Xorde inmediatamente a pregunta: como conseguir o acceso de proba a este nodo "milagre" para probas preliminares e depuración de posibles casos? Todo é moi sinxelo. Calquera desenvolvedor pode enviar unha solicitude a [protexido por correo electrónico], no que abonda con indicar a finalidade da conexión, unha descrición dun posible caso e información de contacto para a comunicación.

Ata a próxima!

Os autores:

• experto senior do departamento de solucións converxentes e servizos multimedia Sergey Novikov sanov,
• experto do departamento de solucións converxentes e servizos multimedia Alexey Lapshin asalto

Fonte: www.habr.com