No artigo "", falando sobre a arquitetura do núcleo de pacotes da rede NB-IoT, mencionamos o surgimento 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 de verificação e autenticação usar;
- qual protocolo de transporte escolher para interagir com dispositivos;
- como entregar dados de forma confiável aos dispositivos;
- como organizar e estabelecer regras para troca de dados com eles;
- como monitorar e obter informações sobre sua condição on-line;
- como entregar dados simultaneamente a um grupo de seus dispositivos;
- como enviar dados simultaneamente de um dispositivo para vários clientes;
- como obter acesso unificado a serviços adicionais da operadora para gerenciar seu dispositivo.
Para resolvê-los, é necessário criar soluções proprietárias tecnicamente “pesadas”, o que leva ao aumento dos custos trabalhistas e do tempo de colocação no mercado dos serviços. É aqui que o novo nó SCEF vem em socorro.
Conforme definido pelo 3GPP, SCEF (função de exposição de capacidade de serviço) é um componente completamente novo da arquitetura 3GPP cuja função é expor com segurança os serviços e capacidades fornecidos pelas interfaces de rede 3GPP através de APIs.
Em palavras simples, o SCEF é um intermediário entre a rede e o servidor de aplicação (AS), uma janela única de acesso aos serviços da operadora para gerenciamento do seu dispositivo M2M na rede NB-IoT através de uma interface API intuitiva e padronizada.
O SCEF esconde a complexidade da rede de uma operadora, permitindo que os desenvolvedores de aplicativos abstraiam mecanismos complexos e específicos de dispositivos para interagir com dispositivos.
Ao transformar protocolos de rede em uma API familiar para desenvolvedores de aplicativos, a API SCEF facilita a criação de novos serviços e reduz o tempo de lançamento no mercado. O novo nó também inclui funções de identificação/autenticação de dispositivos móveis, definindo as regras para troca de dados entre o dispositivo e o AS, eliminando a necessidade de os desenvolvedores de aplicativos implementarem essas funções do seu lado, transferindo essas funções para os ombros do operador.
O SCEF cobre as interfaces necessárias para autenticação e autorização de servidores de aplicativos, mantendo a mobilidade do UE, transferência de dados e acionamento de dispositivos, acesso a serviços adicionais e capacidades de rede da operadora.
Para o AS existe uma única interface T8, uma API (HTTP/JSON) padronizada pelo 3GPP. Todas as interfaces, com exceção do T8, operam com base no protocolo DIAMETER (Fig. 1).
T6a – interface entre SCEF e MME. Utilizado para procedimentos de gerenciamento de mobilidade/sessão, transmissão de dados não IP, provisionamento de eventos de monitoramento e recebimento de relatórios sobre eles.
S6t – interface entre SCEF e HSS. Necessário para autenticação de assinantes, autorização de servidores de aplicação, obtenção de uma combinação de ID externo e IMSI/MSISDN, provisionamento de eventos de monitoramento e recebimento de relatórios sobre eles.
S6m/T4 – interfaces de SCEF para HSS e SMS-C (3GPP define o nó MTC-IWF, que é utilizado para acionamento de dispositivos e transmissão de SMS em redes NB-IoT. Porém, em todas as implementações a funcionalidade deste nó está integrada em SCEF, portanto, para simplificação do circuito, não o consideraremos separadamente). Usado para obter informações de roteamento para envio de SMS e interação com a central de SMS.
T8 – Interface API para interação do SCEF com servidores de aplicação. Tanto os comandos de controle quanto o tráfego são transmitidos através desta interface.
*na realidade existem mais interfaces; apenas as mais básicas estão listadas aqui. Uma lista completa é fornecida em 3GPP 23.682 (4.3.2 Lista de Pontos de Referência).
Abaixo estão as principais funções e serviços do SCEF:
- vincular o identificador do cartão SIM (IMSI) ao ID externo;
- transmissão de tráfego não IP (Non-IP Data Delivery, NIDD);
- operações de grupo usando ID de grupo externo;
- suporte para modo de transmissão de dados com confirmação;
- buffer de dados MO (originados em dispositivos móveis) e MT (terminados em dispositivos móveis);
- autenticação e autorização de dispositivos e servidores de aplicativos;
- utilização simultânea de dados de um UE por vários ASes;
- suporte para funções especiais de monitorização do estado do UE (MONTE – Monitoring Events);
- acionamento do dispositivo;
- fornecendo roaming de dados não IP.
O princípio básico da interação entre AS e SCEF baseia-se no chamado esquema. assinaturas. Caso seja necessário obter acesso a qualquer serviço SCEF para um UE específico, o servidor de aplicação precisa criar uma assinatura enviando um comando para a API específica do serviço solicitado e receber um identificador exclusivo em resposta. Após o que todas as outras ações e comunicações com o UE no âmbito deste serviço ocorrerão utilizando este identificador.
ID externo: identificador universal do dispositivo
Uma das mudanças mais importantes no esquema de interação entre AS e dispositivos ao trabalhar através do SCEF é o surgimento de um identificador universal. Agora, em vez de um número de telefone (MSISDN) ou endereço IP, como acontecia na rede 2G/3G/LTE clássica, o identificador do dispositivo para o servidor de aplicação passa a ser “ID externo”. É definido pelo padrão em um formato familiar aos desenvolvedores de aplicativos “ @ "
Os desenvolvedores não precisam mais implementar algoritmos de autenticação de dispositivos; a rede assume completamente essa função. O ID externo está vinculado ao IMSI, e o desenvolvedor pode ter certeza de que, ao acessar um ID externo específico, ele interage com um cartão SIM específico. Ao usar um chip SIM, você terá uma situação completamente única quando o ID externo identifica exclusivamente um dispositivo específico!
Além disso, vários IDs externos podem ser vinculados a um IMSI - uma situação ainda mais interessante surge quando o ID externo identifica exclusivamente um aplicativo específico responsável por um serviço específico em um dispositivo específico.
Um identificador de grupo também aparece - ID de grupo externo, que inclui um conjunto de IDs externos individuais. Agora, com uma solicitação ao SCEF, o AS pode iniciar operações de grupo - enviando dados ou comandos de controle para vários dispositivos unidos em um único grupo lógico.
Devido ao fato de que para os desenvolvedores de AS a transição para um novo identificador de dispositivo não pode ser instantânea, o SCEF deixou a possibilidade de comunicação do AS com o UE através de um número padrão - MSISDN.
Transmissão de tráfego não IP (Non-IP Data Delivery, NIDD)
No NB-IoT, no âmbito da otimização dos mecanismos de transmissão de pequenas quantidades de dados, além dos tipos de PDN já existentes, como IPv4, IPv6 e IPv4v6, surgiu outro tipo - o não IP. Neste caso, o dispositivo (UE) não recebe um endereço IP e os dados são transmitidos sem usar o protocolo IP. O tráfego para tais conexões pode ser roteado de duas maneiras: clássica - MME -> SGW -> PGW e depois através do túnel PtP para AS (Fig. 2) ou usando SCEF (Fig. 3).
O método clássico não oferece vantagens especiais sobre o tráfego IP, exceto a redução do tamanho dos pacotes transmitidos devido à ausência de cabeçalhos IP. A utilização do SCEF abre uma série de novas possibilidades e simplifica significativamente os procedimentos de interação com os dispositivos.
Ao transmitir dados via SCEF, aparecem duas vantagens muito importantes em relação ao tráfego IP clássico:
Entrega de tráfego MT ao dispositivo via ID externo
Para enviar uma mensagem a um dispositivo IP clássico, o AS deve conhecer o seu endereço IP. Aqui surge um problema: como o dispositivo normalmente recebe um endereço IP “cinza” no momento do registro, ele se comunica com o servidor de aplicação, que está localizado na Internet, através de um nó NAT, onde o endereço cinza é traduzido para branco. A combinação de endereços IP cinza e branco dura um tempo limitado, dependendo das configurações de NAT. Em média, para TCP ou UDP - não mais que cinco minutos. Ou seja, se não houver troca de dados com este dispositivo em até 5 minutos, a conexão será desintegrada e o dispositivo não estará mais acessível no endereço branco com o qual a sessão com AS foi iniciada. Existem várias soluções:
1. Use batimentos cardíacos. Uma vez estabelecida uma conexão, o dispositivo deve trocar pacotes com o AS a cada poucos minutos, evitando assim o fechamento das traduções NAT. Mas não se pode falar de qualquer eficiência energética aqui.
2. Sempre que necessário, verifique a disponibilidade de pacotes para o dispositivo no AS - envie uma mensagem para o uplink.
3. Crie um APN privado (VRF), onde o servidor de aplicativos e os dispositivos estarão na mesma sub-rede, e atribua endereços IP estáticos aos dispositivos. Vai funcionar, mas é quase impossível quando falamos de uma frota de milhares, dezenas de milhares de dispositivos.
4. Por fim, a opção mais adequada: utilizar IPv6, não necessita de NAT, pois os endereços IPv6 são acessíveis diretamente pela Internet. Porém, mesmo neste caso, quando o dispositivo for registrado novamente, ele receberá um novo endereço IPv6 e não estará mais acessível através do anterior.
Assim, é necessário enviar algum pacote de inicialização com um identificador de dispositivo ao servidor para reportar o novo endereço IP do dispositivo. Em seguida, aguarde 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 o dispositivo não possui requisitos rígidos de autonomia e, como resultado, não há restrições de tempo de antena e tráfego. Esses métodos não são adequados para NB-IoT devido ao seu alto consumo de energia.
O SCEF resolve este problema: como o único identificador de dispositivo para um AS é um ID externo, o AS só precisa enviar um pacote de dados ao SCEF para um ID externo específico, e o SCEF cuida do resto. Caso o dispositivo esteja no modo de economia de energia PSM ou eDRX, os dados serão armazenados em buffer e entregues quando o dispositivo estiver disponível. Se o dispositivo estiver disponível para tráfego, os dados serão entregues imediatamente. O mesmo se aplica às equipes de gestão.
A qualquer momento, o AS pode recuperar a mensagem armazenada no UE ou substituí-la por uma nova.
O mecanismo de buffer também pode ser usado ao transmitir dados MO do UE para o AS. Se o SCEF não conseguir entregar os dados ao AS imediatamente, por exemplo, se o trabalho de manutenção estiver em andamento nos servidores do AS, esses pacotes serão armazenados em buffer e terão entrega garantida assim que o AS estiver disponível.
Conforme observado acima, o acesso a um serviço e UE específico para um AS (e NIDD é um serviço) é regulado por regras e políticas do lado do SCEF, o que permite a possibilidade única de utilização simultânea de dados de um UE por vários ASes. Aqueles. se vários AS assinarem um UE, então, após receber dados do UE, o SCEF os enviará para todos os AS inscritos. Isto é adequado para casos em que o criador de uma frota de dispositivos especializados compartilha dados entre vários clientes. Por exemplo, ao criar uma rede de estações meteorológicas executadas em NB-IoT, você pode vender dados delas para vários serviços simultaneamente.
Mecanismo de entrega de mensagens garantido
Reliable Data Service é um mecanismo para entrega garantida de mensagens MO e MT sem a utilização de algoritmos especializados em nível de protocolo, como, por exemplo, handshake em TCP. Funciona incluindo um sinalizador especial na parte de serviço da mensagem quando trocada entre o UE e o SCEF. A ativação ou não deste mecanismo durante a transmissão de tráfego é decidida pelo AS.
Se o mecanismo for ativado, o UE inclui um sinalizador especial na parte complementar do pacote quando requer entrega garantida de tráfego MO. Após a recepção de tal pacote, o SCEF responde ao UE com uma confirmação. Se o UE não receber o pacote de confirmação, o pacote para SCEF será reenviado. A mesma coisa acontece com o tráfego MT.
Monitoramento de dispositivos (monitoramento de eventos - MONTE)
Conforme mencionado acima, a funcionalidade SCEF, entre outras coisas, inclui funções de monitoramento do estado do UE, as chamadas. monitoramento do dispositivo. E se os novos identificadores e mecanismos de transferência de dados são otimizações (ainda que muito graves) de procedimentos existentes, então o MONTE é uma funcionalidade completamente nova que não está disponível nas redes 2G/3G/LTE. O MONTE permite que o AS monitore parâmetros do dispositivo, como status da conexão, disponibilidade de comunicação, localização, status de roaming, etc. Falaremos sobre cada um com mais detalhes um pouco mais tarde.
Caso seja necessário ativar algum evento de monitoramento para um dispositivo ou grupo de dispositivos, o AS assina o serviço correspondente enviando o comando API MONTE correspondente ao SCEF, que inclui parâmetros como Id externo ou ID de grupo externo, identificador AS, monitoramento tipo, quantidade de relatórios que o AS deseja receber. Caso o AS esteja autorizado a executar a solicitação, o SCEF, dependendo do tipo, provisionará o evento ao HSS ou MME (Fig. 4). Quando ocorre um evento, o MME ou HSS gera um relatório ao SCEF, que o envia ao AS.
O provisionamento de todos os eventos, com exceção do “Número de UEs presentes numa área geográfica”, ocorre através do HSS. Dois eventos “Mudança de Associação IMSI-IMEI” e “Status de Roaming” são rastreados diretamente no HSS, o restante será provisionado pelo HSS no MME.
Os eventos podem ser únicos ou periódicos e são determinados pelo seu tipo.
O envio de um relatório sobre um evento (reporting) é realizado pelo nó que rastreia o evento diretamente para o SCEF (Fig. 5).
Ponto importante: Os eventos de monitoramento podem ser aplicados tanto a dispositivos não IP conectados via SCEF quanto a dispositivos IP que transmitem dados da maneira clássica via MME-SGW-PGW.
Vamos dar uma olhada mais de perto em cada um dos eventos de monitoramento:
Perda de conectividade — informa o AS que o UE não está mais disponível para tráfego de dados ou sinalização. O evento ocorre quando o “temporizador de acessibilidade móvel” do UE expira no MME. Num pedido deste tipo de monitorização, o AS pode indicar o seu valor de “Tempo Máximo de Detecção” - se durante este tempo o UE não apresentar qualquer atividade, o AS será informado de que o UE está indisponível, indicando o motivo. O evento também ocorre se o UE for removido à força pela rede por qualquer motivo.
* Para informar à rede que o dispositivo ainda está disponível, ela inicia periodicamente um procedimento de atualização - Tracking Area Update (TAU). A frequência deste procedimento é definida pela rede através do temporizador T3412 ou (T3412_extended no caso do PSM), cujo valor é transmitido ao dispositivo durante o procedimento Attach ou no próximo TAU. O temporizador de acessibilidade móvel geralmente é vários minutos a mais que o T3412. Se o UE não tiver feito um TAU antes do término do “temporizador de acessibilidade móvel”, a rede considera que ele não está mais acessível.
Acessibilidade do UE – Indica quando o UE fica disponível para tráfego DL ou SMS. Isto ocorre quando o UE fica disponível para paging (para um UE no modo eDRX) ou quando o UE entra no modo ECM-CONNECTED (para um UE no modo PSM ou eDRX), ou seja, faz um TAU ou envia um pacote de uplink.
Relatório de localização – Este tipo de eventos de monitorização permite ao AS consultar a localização do UE. Tanto a localização atual (Local Atual) quanto a última localização conhecida (Determinada pelo ID da célula a partir da qual o dispositivo fez TAU ou transmitiu tráfego da última vez) podem ser solicitadas, o que é relevante para dispositivos nos modos de economia de energia PSM ou eDRX. Para “Localização Atual”, o AS pode solicitar respostas repetidas, sendo que o MME informa o AS cada vez que a localização do dispositivo muda.
Mudança de Associação IMSI-IMEI – Quando este evento é ativado, o SCEF passa a monitorar alterações na combinação de IMSI (identificador do cartão SIM) e IMEI (identificador do dispositivo). Quando ocorre um evento, informa o AS. Pode ser usado para religar automaticamente um ID externo a um dispositivo durante um trabalho de substituição programado ou servir como um identificador para roubo de um dispositivo.
Status de roaming – este tipo de monitorização é utilizado pelo AS para determinar se o UE está na rede doméstica ou na rede de um parceiro de roaming. Opcionalmente, pode ser transmitida a PLMN (Rede Móvel Terrestre Pública) da operadora na qual o dispositivo está cadastrado.
Falha de comunicação — Este tipo de monitoramento informa ao AS sobre falhas na comunicação com o dispositivo, com base nos motivos da perda de conexão (código de causa de liberação) recebidos da rede de acesso rádio (protocolo S1-AP). Este evento pode ajudar a determinar o motivo da falha na comunicação - devido a problemas na rede, por exemplo, quando o eNodeb está sobrecarregado (Recursos de rádio não disponíveis) ou devido a uma falha do próprio dispositivo (Conexão de rádio com UE perdida).
Disponibilidade após falha DDN – este evento informa ao AS que o dispositivo ficou disponível após uma falha de comunicação. Pode ser utilizado quando há necessidade de transferir dados para um dispositivo, mas a tentativa anterior não obteve sucesso porque o UE não respondeu a uma notificação da rede (paging) e os dados não foram entregues. Caso este tipo de monitoramento tenha sido solicitado para o UE, então assim que o dispositivo fizer uma comunicação de entrada, fizer um TAU ou enviar dados para o uplink, o AS será informado que o dispositivo ficou disponível. Como o procedimento DDN (notificação de dados de downlink) funciona entre MME e S/P-GW, este tipo de monitoramento está disponível apenas para dispositivos IP.
Status de conectividade PDN – informa o AS quando o status do dispositivo muda (status de conectividade PDN) - conexão (ativação PDN) ou desconexão (exclusão PDN). Isto pode ser utilizado pelo AS para iniciar a comunicação com o UE, ou vice-versa, para compreender que a comunicação já não é possível. Este tipo de monitoramento está disponível para dispositivos IP e não IP.
Número de UEs presentes numa área geográfica – Este tipo de monitorização é utilizado pelo AS para determinar o número de UEs numa determinada área geográfica.
Acionamento do dispositivo)
Nas redes 2G/3G, o procedimento de registro na rede era em duas etapas: primeiro, o dispositivo registrava-se no SGSN (procedimento de anexação), depois, se necessário, ativava o contexto PDP - uma conexão com o gateway de pacotes (GGSN). para transmitir dados. Nas redes 3G, esses dois procedimentos ocorreram de forma sequencial, ou seja, o dispositivo não esperou o momento em que precisava transferir os dados, mas ativou o PDP imediatamente após a conclusão do procedimento de anexação. No LTE, esses dois procedimentos foram combinados em um só, ou seja, ao conectar, o dispositivo solicitou imediatamente a ativação da conexão PDN (análoga ao PDP em 2G/3G) via eNodeB ao MME-SGW-PGW.
NB-IoT define um método de conexão como “anexação sem PDN”, ou seja, o UE se conecta sem estabelecer uma conexão PDN. Neste caso, não está disponível para transmitir tráfego, podendo apenas receber ou enviar SMS. Para enviar um comando a tal dispositivo para ativar o PDN e conectar-se ao AS, foi desenvolvida a funcionalidade “Disparo de dispositivo”.
Ao receber um comando para conectar tal UE do AS, o SCEF inicia o envio de um SMS de controle para o dispositivo através do centro de SMS. Ao receber um SMS, o dispositivo ativa o PDN e se conecta ao AS para receber mais instruções ou transferir dados.
Pode haver momentos em que a assinatura do seu dispositivo expire no SCEF. Sim, a assinatura tem prazo de validade próprio, definido pelo operador ou acordado com o AS. Ao expirar, o PDN será desativado no MME e o dispositivo ficará indisponível para o AS. Neste caso, a funcionalidade “Acionamento do dispositivo” também ajudará. Ao receber novos dados do AS, o SCEF descobrirá o status da conexão do dispositivo e entregará os dados via canal SMS.
Conclusão
A funcionalidade do SCEF, é claro, não se limita aos serviços descritos acima e está em constante evolução e expansão. Atualmente, mais de uma dezena de serviços já foram padronizados para o SCEF. Agora tocamos apenas nas principais funções exigidas pelos desenvolvedores, falaremos sobre o resto em artigos futuros.
A questão surge imediatamente: como obter acesso de teste a este nó “milagroso” para testes preliminares e depuração de possíveis casos? Tudo é muito simples. Qualquer desenvolvedor pode enviar uma solicitação para [email protegido], onde basta indicar a finalidade da conexão, a descrição de um possível caso e dados de contato para comunicação.
Até nos encontrarmos novamente!
Autores:
- especialista sênior do departamento de soluções convergentes e serviços multimídia Sergey Novikov ,
- especialista do departamento de soluções convergentes e serviços multimídia Alexey Lapshin
Fonte: habr.com