No artigo "", ao falar sobre a arquitetura do núcleo de pacotes da rede NB-IoT, mencionamos a introdução de um novo nó SCEF. Explicamos na terceira parte o que é e por que é necessário?
Ao criar um serviço M2M, os desenvolvedores de aplicativos enfrentam as seguintes questões:
- como identificar dispositivos;
- qual algoritmo utilizar para verificação e autenticação;
- qual protocolo de transporte escolher para interagir com os dispositivos;
- como garantir a entrega de dados nos dispositivos;
- como organizar e estabelecer regras para a troca de dados com eles;
- como monitorar e obter informações sobre seu estado em tempo real;
- como entregar dados simultaneamente a um grupo de dispositivos;
- como enviar dados de um dispositivo para vários clientes simultaneamente;
- como obter acesso unificado a serviços adicionais do operador para gerenciar seu dispositivo.
Para resolver essas questões, é necessário criar soluções técnicas proprietárias "pesadas", o que aumenta o tempo e os recursos necessários para o desenvolvimento dos serviços. É aqui que o novo nó SCEF entra em cena.
De acordo com a definição da 3GPP, SCEF (função de exposição de capacidade de serviço) é um componente completamente novo da arquitetura 3GPP, cuja função é expor de forma segura serviços e capacidades oferecidas pelas interfaces de rede 3GPP através de API.
De forma simples, SCEF é um intermediário entre a rede e o servidor de aplicativos (application server — AS), servindo como uma única interface de acesso aos serviços do operador para gerenciar seu dispositivo M2M na rede NB-IoT por meio de uma interface de API padronizada e intuitiva.
O SCEF oculta a complexidade da rede do operador, permitindo que os desenvolvedores de aplicativos se abstraiam de mecanismos de interação complexos e específicos com os dispositivos.
Por meio da conversão de protocolos de rede em uma interface de API familiar para os desenvolvedores, o SCEF facilita a criação de novos serviços e reduz o tempo de lançamento no mercado. Além disso, o novo nó inclui funções de identificação/autenticação de dispositivos móveis e a definição de regras de troca de dados entre o dispositivo e o AS, eliminando a necessidade de os desenvolvedores implementarem essas funções em seu lado e transferindo essas responsabilidades para o operador.
O SCEF agrega as interfaces necessárias para a autenticação e autorização de servidores de aplicativos, manutenção da mobilidade do UE, transmissão de dados e acionamento de dispositivos, acesso a serviços adicionais e recursos da rede do operador.
Para o AS, existe uma única interface T8, uma interface API (HTTP/JSON) padronizada pelo 3GPP. Todas as interfaces, exceto a T8, operam com base no protocolo DIAMETER (veja a Figura 1).
T6a – interface entre SCEF e MME. É usada para procedimentos de gerenciamento de mobilidade/sessão, transmissão de dados non-IP, provisionamento de eventos de monitoramento e recebimento de relatórios sobre eles.
S6t – interface entre SCEF e HSS. Necessária para a autenticação do assinante, autorização de servidores de aplicativos, obtenção da combinação de ID externo e IMSI/MSISDN, provisionamento de eventos de monitoramento e recebimento de relatórios sobre eles.
S6m/T4 – interfaces do SCEF para HSS e SMS-C (no 3GPP, o nó MTC-IWF é definido, que é usado para acionamento de dispositivos e transmissão de SMS nas redes NB-IoT. No entanto, em todas as implementações, a funcionalidade desse nó está integrada ao SCEF, de modo que para simplificar o esquema não o discutiremos separadamente). Usadas para obter informações de roteamento para o envio de SMS e interação com o centro de SMS.
T8 – interface API para interação do SCEF com servidores de aplicativos. Através dessa interface são transmitidos tanto comandos de controle quanto tráfego.
*na verdade, há mais interfaces, aqui estão listadas apenas as principais. A lista completa pode ser encontrada no 3GPP 23.682 (4.3.2 Lista de Pontos de Referência).
Abaixo estão as principais funcionalidades e serviços do SCEF:
- vinculação do identificador do cartão SIM (IMSI) ao ID externo;
- transmissão de tráfego non-IP (Non-IP Data Delivery, NIDD);
- operações em grupo, utilizando o ID de grupo externo;
- apoio ao modo de transmissão de dados com confirmação;
- bufferização de dados MO (Mobile Originated) e MT (Mobile Terminated);
- autenticação e autorização de dispositivos e servidores de aplicativos;
- uso simultâneo de dados de um único UE por vários AS;
- apoio a funções especiais de controle de estado do UE (MONTE – Monitoring Events);
- acionamento de dispositivos;
- garantia de roaming de dados non-IP.
O princípio fundamental da interação entre AS e SCEF é baseado em um esquema de chamadas de assinatura. Se houver a necessidade de acessar um determinado serviço SCEF para um UE específico, o servidor de aplicativos precisa criar uma assinatura, enviando um comando para uma API específica do serviço solicitado e recebendo em resposta um identificador único. Após isso, todas as ações e comunicações com o UE dentro do referido serviço ocorrerão utilizando este identificador.
ID Externo: identificador universal do dispositivo
Uma das principais mudanças no esquema de interação do AS com os dispositivos ao trabalhar através do SCEF é a introdução do identificador universal. Agora, em vez do número de telefone (MSISDN) ou do endereço IP, como era nas redes clássicas 2G/3G/LTE, o identificador do dispositivo para o servidor de aplicativos torna-se o "ID externo". Este está definido pelo padrão no formato familiar para desenvolvedores de aplicativos "@".
Os desenvolvedores não precisam mais implementar algoritmos de autenticação de dispositivos, pois a rede assume completamente essa função. O ID externo está vinculado ao IMSI, e o desenvolvedor pode ter certeza de que ao se referir a um determinado ID externo, ele está interagindo com um cartão SIM específico. Com o uso do chip SIM, ocorre uma situação especialmente única, onde o ID externo identifica de forma clara um dispositivo específico!
Além disso, um único IMSI pode estar vinculado a vários IDs externos — isso cria uma situação ainda mais interessante, onde o ID externo identifica de forma clara um aplicativo específico, responsável por um determinado serviço em um dispositivo específico.
Também surge um identificador de grupo — ID de grupo externo, que inclui um conjunto de IDs externos individuais. Agora, com uma única solicitação ao SCEF, o AS pode iniciar operações em grupo — envio de dados ou comandos de controle para muitos dispositivos, agrupados em uma única lógica.
Devido ao fato de que a transição para o novo identificador de dispositivo não pode ser imediata para os desenvolvedores de AS, o SCEF deixou a possibilidade de comunicação do AS com o UE através do número padrão – MSISDN.
Transferência de tráfego non-IP (Non-IP Data Delivery, NIDD)
No NB-IoT, na otimização dos mecanismos de transmissão de pequenos volumes de dados, além dos tipos de PDN já existentes, como IPv4, IPv6 e IPv4v6, surgiu um novo tipo — non-IP. Nesse caso, o dispositivo (UE) não recebe um endereço IP, e os dados são transmitidos sem o uso do protocolo IP. O tráfego para essas conexões pode ser roteado de duas maneiras: de forma clássica — MME -> SGW -> PGW e daí através do túnel PtP até AS (fig. 2) ou utilizando SCEF (fig. 3).
O método clássico não traz vantagens significativas em relação ao tráfego IP, exceto a redução do tamanho dos pacotes transmitidos devido à ausência de cabeçalhos IP. Por outro lado, o uso do SCEF abre uma série de novas oportunidades e simplifica consideravelmente os procedimentos de interação com os dispositivos.
Na transmissão de dados via SCEF, surgem duas vantagens muito importantes em relação ao tráfego IP clássico:
• Entrega de tráfego MT ao dispositivo por meio do ID externo.
Para enviar uma mensagem a um dispositivo IP clássico — AS deve conhecer seu endereço IP. Aqui surge um problema: como o dispositivo, durante o registro, geralmente recebe um endereço IP 'cinza', ele se comunica com o servidor de aplicativos, que está na internet, através de um nó NAT, onde ocorre a tradução do endereço cinza para um endereço público. A associação entre os endereços IP cinza e público dura um tempo limitado, dependendo das configurações do NAT. Em média, para TCP ou UDP — não mais que cinco minutos. Ou seja, se dentro de 5 minutos não houve troca de dados com esse dispositivo, a associação se dissolve, e o dispositivo deixa de ser acessível pelo endereço público que foi usado para iniciar a sessão com AS. Existem algumas soluções:
1. Usar heartbeat. Uma vez estabelecida a conexão, o dispositivo deve trocar pacotes com AS a cada poucos minutos, evitando assim que a tradução no NAT se feche. Mas aqui não se pode falar sobre eficiência energética.
2. Sempre que necessário, verificar a presença de pacotes para o dispositivo no AS — enviando uma mensagem no uplink.
3. Criar um APN privado (VRF), onde o servidor de aplicativos e os dispositivos estarão na mesma sub-rede, e atribuir endereços IP estáticos aos dispositivos. Isso funcionará, mas é quase irrealizável quando se trata de um parque com milhares ou dezenas de milhares de dispositivos.
4. Finalmente, a opção mais adequada: usar IPv6, pois não precisa de NAT, uma vez que os endereços IPv6 estão diretamente disponíveis na internet. No entanto, mesmo neste caso, ao registrar novamente o dispositivo, ele receberá um novo endereço IPv6 e não estará mais acessível pelo anterior.
Portanto, é necessário enviar um pacote de inicialização com o identificador do dispositivo para o servidor, a fim de informar o novo endereço IP do dispositivo. Em seguida, aguardar um pacote de confirmação do AS, o que também afeta a eficiência energética.
Esses métodos funcionam bem para dispositivos 2G/3G/LTE, onde não há exigências rigorosas em termos de autonomia e, consequentemente, não existem restrições em relação ao tempo em operação e ao tráfego. Para NB-IoT, esses métodos não são adequados devido ao seu alto consumo de energia.
O SCEF resolve esse problema: como o único identificador do dispositivo para o AS é o ID externo, o AS só precisa enviar um pacote de dados para o SCEF para o ID externo específico, sendo que o SCEF cuidará de todo o resto. Se o dispositivo estiver em modo de economia de energia PSM ou eDRX, os dados serão armazenados em buffer e entregues quando o dispositivo estiver disponível. Caso o dispositivo esteja disponível para tráfego, os dados serão entregues imediatamente. Isso também se aplica a comandos de controle.
A qualquer momento, o AS pode revogar a mensagem armazenada em buffer para o UE ou substituí-la por uma nova.
O mecanismo de buffer também pode ser aplicado na transmissão de dados MO do UE para o AS. Se o SCEF não conseguir entregar os dados ao AS imediatamente, por exemplo, se estiverem sendo realizadas manutenções nos servidores do AS, esses pacotes serão armazenados em buffer e garantidamente entregues assim que o AS estiver disponível.
Como mencionado anteriormente, o acesso a um determinado serviço e ao UE para o AS (sendo que NIDD é um serviço) é regulado por regras e políticas do lado do SCEF, o que possibilita a implementação da única capacidade de uso simultâneo dos dados de um único UE por vários AS. Ou seja, se vários AS se inscreverem em um único UE, após receber os dados do UE, o SCEF os enviará para todos os AS inscritos. Isso é muito adequado para casos em que o criador de um parque de dispositivos especializados compartilha dados entre vários clientes. Por exemplo, ao criar uma rede de estações meteorológicas funcionando em NB-IoT, é possível vender os dados delas para muitos serviços simultaneamente.
Mecanismo de entrega garantida de mensagens
Serviço de Dados Confiável — mecanismo de entrega garantida de mensagens MO e MT sem o uso de algoritmos especializados a nível de protocolo, como, por exemplo, o handshake no TCP. Funciona através da inclusão de um sinalizador especial na parte de serviço da mensagem durante a troca entre UE e SCEF. Ativar ou não este mecanismo ao transmitir tráfego é uma decisão do AS.
Se o mecanismo estiver ativado, a UE, em caso de necessidade de entrega garantida de tráfego MO, inclui um sinalizador especial na parte de serviço do pacote. Ao receber tal pacote, o SCEF responde à UE com uma confirmação. Se a UE não receber um pacote de confirmação, o pacote para o SCEF será retransmitido. O mesmo acontece para o tráfego MT.
Monitoramento de Dispositivos (monitoring events- MONTE)
Como mencionado anteriormente, a funcionalidade do SCEF, além de outras, inclui funções de controle de estado da UE, ou seja, monitoramento de dispositivos. E se novos identificadores e mecanismos de transmissão de dados são otimizações (embora muito significativas) de procedimentos já existentes, o MONTE é uma funcionalidade completamente nova, não disponível em redes 2G/3G/LTE. O MONTE permite que o AS monitore parâmetros do dispositivo, como status de conexão, disponibilidade para comunicação, localização, status de roaming, etc. Faremos uma descrição mais detalhada de cada um logo em seguida.
Se necessário ativar algum evento de monitoramento para um dispositivo ou grupo de dispositivos, o AS se inscreve no serviço correspondente enviando ao SCEF um comando da API MONTE correspondente, que inclui parâmetros como external Id ou external group ID, identificador do AS, tipo de monitoramento, quantidade de relatórios que o AS deseja receber. Se o AS estiver autorizado a executar a solicitação, o SCEF provisiona o evento no HSS ou MME dependendo do tipo (Fig. 4). Quando o evento ocorrer, o MME ou HSS gera um relatório para o SCEF, que o envia ao AS.
O provisionamento de todos os eventos, exceto “Número de UEs presentes em uma área geográfica”, ocorre através do HSS. Os dois eventos “Mudança de Associação IMSI-IMEI” e “Status de Roaming” são monitorados diretamente no HSS, enquanto os demais são provisionados pelo HSS no MME.
Os eventos podem ser tanto pontuais quanto periódicos, dependendo do seu tipo.
O envio do relatório de eventos (reporting) é realizado pelo nó que monitora o evento, diretamente para o SCEF (fig. 5).
Ponto importante: os eventos de monitoramento podem ser aplicados tanto a dispositivos non-IP conectados via SCEF quanto a dispositivos IP que transmitem dados de maneira clássica através de MME-SGW-PGW.
Vamos analisar mais detalhadamente cada um dos eventos de monitoramento:
Perda de conectividade — informa o AS que o UE não está mais disponível nem para tráfego de dados, nem para troca de sinal. O evento ocorre quando o 'mobile reachability timer' para o UE expira no MME. Na solicitação para esse tipo de monitoramento, o AS pode especificar seu valor de 'Maximum Detection Time' — se durante esse tempo o UE não mostrar qualquer atividade, o AS será informado de que o UE está indisponível, com a razão indicada. O evento também ocorre se o UE foi forçosamente removido da rede por algum motivo.
* Para que a rede saiba que o dispositivo ainda está disponível, este inicia periodicamente o procedimento de atualização — Tracking Area Update (TAU). A frequência desse procedimento é determinada pela rede através do timer T3412 ou (T3412_extended no caso de PSM), cujo valor é transmitido ao dispositivo durante o procedimento de Attach ou na TAU subsequente. O 'mobile reachability timer' geralmente é alguns minutos mais longo do que o T3412. Se o UE não realizar uma TAU antes do término do 'Mobile reachability timer', a rede o considera indisponível.
Acessibilidade do UE – Indica quando o UE se torna disponível para tráfego DL ou SMS. Isso ocorre quando o UE se torna disponível para paginação (para UE no modo eDRX) ou quando o UE muda para o modo ECM-CONNECTED (para UE no modo PSM ou eDRX), ou seja, realiza a TAU ou envia um pacote uplink.
Relatório de localizações – Este tipo de evento de monitoramento permite que o AS solicite dados sobre a localização do UE. Pode ser solicitado tanto a localização atual (Current Location) quanto a última conhecida (Last Known Location, determinada pelo cell ID do qual o dispositivo realizou a TAU ou transmitiu tráfego pela última vez), o que é relevante para dispositivos em modos de economia de energia PSM ou eDRX. Para a 'Current Location', o AS pode solicitar relatórios repetidos, com o MME informando o AS toda vez que há uma mudança na localização do dispositivo.
Alteração da Associação IMSI-IMEI – Ao ativar este evento, o SCEF começa a rastrear a mudança na combinação de IMSI (identificador do chip SIM) e IMEI (identificador do dispositivo). Quando o evento ocorre, informa o AS. Pode ser utilizado para reatribuição automática do ID externo ao dispositivo durante manutenções programadas ou para atuar como identificador de roubo do dispositivo.
Status de Roaming – Este tipo de monitoramento é utilizado pelo AS para determinar se o UE está na rede doméstica ou na rede de um parceiro de roaming. Opcionalmente, pode ser enviado o PLMN (Rede Móvel Terrestre Pública) do operador onde o dispositivo está registrado.
Falha de Comunicação — Este tipo de monitoramento informa o AS sobre falhas na comunicação com o dispositivo, com base em razões de interrupção da conexão (código de causa de liberação) recebidas da rede de acesso rádio (protocolo S1-AP). Este evento pode ajudar a determinar a razão da falha de comunicação — devido a problemas na rede, por exemplo, quando a eNodeB está sobrecarregada (recursos de rádio não disponíveis) ou devido a uma falha no próprio dispositivo (Conexão de Rádio com UE Perdida).
Disponibilidade após Falha de DDN – Este evento informa o AS que o dispositivo se tornou disponível após uma falha de comunicação. Pode ser utilizado quando é necessário enviar dados para o dispositivo, mas a tentativa anterior não foi bem-sucedida, pois o UE não respondeu à notificação da rede (paging), e os dados não foram entregues. Se este tipo de monitoramento foi solicitado para o UE, assim que o dispositivo realizar uma comunicação de entrada, fizer um TAU ou enviar dados no uplink, o AS será informado de que o dispositivo se tornou disponível. Como o procedimento DDN (notificação de dados de downlink) funciona entre o MME e S/P-GW, este tipo de monitoramento está disponível apenas para dispositivos IP.
Status de Conectividade PDN – Informa o AS sobre a mudança de status do dispositivo (status de conectividade PDN) — ao conectar (ativação do PDN) ou desconectar (remoção do PDN). Isso pode ser usado pelo AS para iniciar comunicação com o UE, ou vice-versa, para entender que a comunicação não é mais possível. Este tipo de monitoramento está disponível para dispositivos IP e non-IP.
Número de UEs presentes em uma área geográfica – Este tipo de monitoramento é utilizado pelo AS para determinar o número de UE em uma determinada zona geográfica.
Dispositivos de Triggering (Device triggering)
Em redes 2G/3G, o processo de registro na rede era em duas etapas: primeiro, o dispositivo se registrava no SGSN (processo de attach), e depois, se necessário para transmitir dados, ativava o contexto PDP – a conexão com o gateway de pacotes (GGSN). Nas redes 3G, essas duas etapas ocorriam sequencialmente, ou seja, o dispositivo não esperava o momento de transmitir dados, mas ativava o PDP imediatamente após concluir o processo de attach. No LTE, essas duas etapas foram combinadas em uma, ou seja, durante o attach, o dispositivo pedia imediatamente a ativação da conexão PDN (equivalente ao PDP em 2G/3G) através do eNodeB para o MME-SGW-PGW.
No NB-IoT, foi definido um método de conexão chamado 'attach without PDN', ou seja, o UE realiza o attach sem estabelecer uma conexão PDN. Nesse caso, ele não está disponível para a transmissão de tráfego e pode apenas receber ou enviar SMS. Para enviar a este dispositivo um comando para ativar a PDN e conectá-lo ao AS, foi desenvolvido o recurso 'Device triggering'.
Ao receber um comando para conectar esse UE do AS, o SCEF, através do centro de SMS, inicia o envio de um SMS de controle ao dispositivo. Ao receber o SMS, o dispositivo ativa a PDN e se conecta ao AS para receber instruções subsequentes ou transmitir dados.
Podem ocorrer casos em que a assinatura do dispositivo no SCEF expire. Sim, a assinatura tem um prazo de validade estabelecido pelo operador ou acordado com o AS. Após a expiração, a PDN será desativada no MME, e o dispositivo se tornará indisponível para o AS. Nesse caso, o recurso 'Device triggering' também pode ajudar. Ao receber novos dados do AS, o SCEF verificará o status da conexão do dispositivo e entregará os dados pelo canal SMS.
Conclusão
O recurso SCEF, claro, não se limita aos serviços descritos acima e está constantemente em evolução e expansão. No momento, mais de dez serviços já estão padronizados para o SCEF. Agora, abordamos apenas as funções principais e mais solicitadas pelos desenvolvedores, sobre as quais falaremos em artigos futuros.
Imediatamente surge a questão: como obter acesso de teste a este 'maravilhoso' nó para testes preliminares e depuração de possíveis casos? É muito simples. Qualquer desenvolvedor pode enviar uma solicitação para iot.info@mts.ru, onde basta indicar o objetivo da conexão, uma descrição do possível caso e informações de contato para retorno.
Até a próxima!
Autores:
- senior expert in convergent solutions and multimedia services Sergey Novikov ,
- expert in convergent solutions and multimedia services Alexey Lapshin
Fonte: habr.com
