No artigo " NB-IoT: como funciona?" Parte 2 ”, falando sobre a arquitetura do núcleo de pacotes da rede NB-IoT, mencionamos a aparência 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 são confrontados com as seguintes perguntas:
- Como identificar dispositivos
- Qual autenticação e algoritmo de autenticação usar;
- qual protocolo de transporte usar para interagir com dispositivos;
- Como entregar dados com segurança aos dispositivos
- como organizar e estabelecer regras para a troca de dados com eles;
- como monitorar e receber informações on-line sobre seu status;
- 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, é preciso criar soluções tecnicamente “pesadas” proprietárias, o que leva a um aumento nos custos de mão-de-obra e nos serviços de time-to-market. É aqui que o novo nó SCEF vem ao resgate.
De acordo com a definição de 3GPP, o 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 recursos fornecidos pelas interfaces de rede 3GPP por meio da API.
Em palavras simples, o SCEF é um intermediário entre a rede e o servidor de aplicativos (AS), uma única janela de acesso aos serviços do operador para gerenciar seu dispositivo M2M na rede NB-IoT por meio de uma API padronizada e intuitiva.
O SCEF oculta a complexidade da rede da operadora, permitindo que os desenvolvedores de aplicativos abstrajam de mecanismos específicos complexos para interagir com os dispositivos.
Ao transformar protocolos de rede em familiares aos desenvolvedores de aplicativos, a API do SCEF facilita a criação de novos serviços e reduz o tempo de colocação no mercado. Além disso, o novo nó inclui as funções de identificação / autenticação de dispositivos móveis, determinando as regras para a troca de dados entre o dispositivo e o AS, eliminando a necessidade de implementação dessas funções pelos desenvolvedores de aplicativos, deslocando essas funções para os ombros do operador.
O SCEF fecha 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 recursos de rede da operadora.
Em relação ao AS, existe uma única interface T8, uma API (HTTP / JSON), um 3GPP padronizado. Todas as interfaces, com exceção do T8, operam com base no protocolo DIAMETER (Fig. 1).
T6a é a interface entre o SCEF e o MME. Usado 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 é a interface entre o SCEF e o HSS. É necessário para autenticação do assinante, autorização dos servidores de aplicativos, obtenção de um ID externo e IMSI / MSISDN, fornecendo eventos de monitoramento e recebendo relatórios sobre eles.
S6m / T4 - interfaces do SCEF para HSS e SMS-C (o nó MTC-IWF é definido no 3GPP, usado para acionar dispositivos e enviar SMS nas redes NB-IoT. No entanto, em todas as implementações, a funcionalidade desse nó é integrada ao SCEF, portanto, para simplificação do esquema, não o consideraremos separadamente). Usado para obter informações de roteamento para enviar SMS e interagir com o centro de SMS.
T8 - API SCEF para interação com servidores de aplicativos. Os comandos de controle e o tráfego são transmitidos por essa interface.
* Na realidade, existem mais interfaces, apenas as mais básicas estão listadas aqui. Uma lista completa é fornecida no 3GPP 23.682 (4.3.2 Lista de pontos de referência).
Abaixo estão os principais recursos e serviços do SCEF:
- vincular um identificador de cartão SIM (IMSI) a um ID externo;
- entrega de tráfego não IP (entrega de dados não IP, NIDD);
- operações de grupo usando um ID de grupo externo;
- suporte para o modo de transferência de dados com confirmação;
- buffer de dados MO (Mobile Originated) e MT (Mobile Terminated);
- autenticação e autorização de dispositivos e servidores de aplicativos;
- uso simultâneo dos dados de um UE por vários SA;
- suporte de funções especiais de monitoramento do status do UE (MONTE - Monitoring Events);
- disparo de dispositivo;
- Fornecendo dados não IP de roaming.
O princípio básico de interação entre AS e SCEF baseia-se no chamado assinaturas. Se você precisar acessar qualquer serviço SCEF para um UE específico, o servidor de aplicativos precisará criar uma assinatura enviando um comando para a API específica do serviço solicitado e em resposta para receber um identificador exclusivo. Depois disso, todas as ações e comunicações adicionais com o UE dentro da estrutura deste serviço ocorrerão usando esse identificador.
ID externo: identificador universal do dispositivoUma das mudanças mais importantes no esquema de interação entre o AS e os dispositivos ao trabalhar com o SCEF é o surgimento de um identificador universal. Agora, em vez de um número de telefone (MSISDN) ou endereço IP, como na rede 2G / 3G / LTE clássica, o identificador de dispositivo do servidor de aplicativos se torna "ID externo". É definido pelo padrão no formato familiar aos desenvolvedores de aplicativos "<Identificador Local> @ <Identificador de Domínio>".
Os desenvolvedores não precisam mais implementar algoritmos de autenticação de dispositivo, a rede assume completamente essa função. O ID externo está anexado ao IMSI, e o desenvolvedor pode ter certeza de que, referindo-se a um ID externo específico, ele interage com um cartão SIM específico. Ao usar um chip SIM, uma situação geralmente única é obtida quando o ID externo identifica exclusivamente um dispositivo específico!
Além disso, vários IDs externos podem ser atribuídos a um IMSI - uma situação ainda mais interessante é obtida 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 - um ID de grupo externo, que inclui um conjunto de IDs externos separados. Agora, com uma única solicitação ao SCEF, o AS pode iniciar operações de grupo - enviando dados ou comandos de controle para vários dispositivos combinados em um único grupo lógico.
Devido ao fato de que, para desenvolvedores de AS, a transição para um novo identificador de dispositivo não pode ser instantânea, a SCEF deixou a possibilidade de comunicação de AS com o UE através do número padrão - MSISDN.
Entrega de dados não IP (NIDD)No NB-IoT, além de otimizar os mecanismos de transferência de pequenas quantidades de dados, além dos tipos de PDNs existentes, como IPv4, IPv6 e IPv4v6, apareceu outro tipo - não 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: classic - MME -> SGW -> PGW e, em seguida, através do túnel PtP para AS (Fig. 2) ou usando SCEF (Fig. 3).
O método clássico não possui vantagens especiais sobre o tráfego IP, exceto para reduzir o tamanho dos pacotes transmitidos devido à ausência de cabeçalhos IP. O uso do SCEF abre várias novas oportunidades e simplifica bastante os procedimentos para interagir com os dispositivos.
Ao transmitir dados através do SCEF, existem duas vantagens muito importantes sobre o tráfego IP clássico:
Entrega de tráfego MT ao dispositivo por ID externoPara enviar uma mensagem para um dispositivo IP clássico, o AS deve saber seu endereço IP. Aqui surge um problema: como o dispositivo geralmente se registra com um endereço IP “cinza”, ele se comunica com o servidor de aplicativos, localizado na Internet, através do nó NAT, onde o endereço cinza é traduzido para branco. Um monte 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 dentro de 5 minutos não houve troca de dados com este dispositivo, o pacote será interrompido e o dispositivo não estará mais acessível no endereço branco com o qual a sessão com o AS foi iniciada. Existem várias soluções:
1. Use um batimento cardíaco. Depois que uma conexão é estabelecida, o dispositivo deve trocar com pacotes AS a cada poucos minutos, impedindo o fechamento das traduções NAT. Mas não há dúvida de eficiência energética.
2. Sempre que necessário, verifique se há 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. Funcionará, mas isso é quase impossível quando se trata de uma frota de milhares, dezenas de milhares de dispositivos.
4. Finalmente, a opção mais adequada: use o IPv6, ele não precisa de NAT, pois os endereços IPv6 são diretamente acessíveis na Internet. No entanto, mesmo nesse caso, ao registrar novamente o dispositivo, ele receberá um novo endereço IPv6 e não estará mais disponível no endereço anterior.
Portanto, é necessário enviar um determinado pacote de inicialização com o identificador do dispositivo para o servidor para relatar o novo endereço IP do dispositivo. Depois aguarde o pacote de confirmação do AS, 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á limites de tempo no ar e no 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 de dispositivo para o AS é um ID externo, basta que o AS envie um pacote de dados ao SCEF para um ID externo específico, o SCEF cuidará do resto. Se o dispositivo estiver 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 vale para as equipes de gerenciamento.
A qualquer momento, o AS pode retirar a mensagem em buffer para o UE ou substituí-la por uma nova.
O mecanismo de tamponamento também pode ser usado ao transferir dados MO do UE para o lado AS. Se o SCEF não conseguir entregar dados ao AS imediatamente, por exemplo, se o serviço estiver em andamento nos servidores do AS, esses pacotes serão armazenados em buffer e garantidos para entrega assim que o AS estiver disponível.
Como observado acima, o acesso a um serviço específico e o UE para AS (e o NIDD é um serviço) é regulado por regras e políticas do lado do SCEF, o que permite perceber a capacidade exclusiva de usar simultaneamente os dados de um UE por vários ASs. I.e. se vários ASs se inscreveram em um UE, depois de receber dados do UE, o SCEF os enviará a todos os ASs assinados. Isso é adequado para casos em que o criador de uma frota de dispositivos especializados confunde dados entre vários clientes. Por exemplo, ao criar uma rede de estações meteorológicas operando no NB-IoT, você pode vender dados deles para vários serviços ao mesmo tempo.
Mecanismo de Entrega de Mensagens GarantidoServiço de dados confiáveis - um mecanismo para entrega garantida de mensagens MO e MT sem o uso de algoritmos especializados no nível do protocolo, como, por exemplo, handshake no TCP. Funciona incluindo uma bandeira especial na parte de serviço da mensagem durante a troca entre o UE e o SCEF. A ativação ou não desse mecanismo ao transmitir tráfego é decidida pelo AS.
Se o mecanismo estiver ativado, o UE, se necessário, entrega garantida de tráfego MO inclui um sinalizador especial na parte de serviço do pacote. Após o recebimento de tal pacote, o SCEF responde ao UE com uma confirmação. Se o UE não recebeu um pacote de confirmação, o pacote será encaminhado para o SCEF. O mesmo acontece com o tráfego MT.
Monitoramento de dispositivos (eventos de monitoramento - MONTE)Como mencionado acima, o SCEF funcional, entre outras coisas, inclui funções para monitorar o estado do UE, o chamado monitoramento de dispositivos. E se novos identificadores e mecanismos de transferência de dados são otimizações (embora muito sérias) dos procedimentos existentes, o MONTE é uma funcionalidade completamente nova que não está disponível nas redes 2G / 3G / LTE. O MONTE permite que o AS monitore os parâmetros do dispositivo, como status da conexão, disponibilidade de comunicação, localização, status de roaming etc. Falaremos mais sobre cada um deles mais tarde.
Se for necessário ativar um evento de monitoramento para um dispositivo ou grupo de dispositivos, o AS assina o serviço correspondente enviando ao SCEF o comando MONTE API correspondente, que inclui parâmetros como ID externo ou ID do grupo externo, identificador AS, tipo de monitoramento, número de relatórios, qual AS deseja receber. Se o AS estiver autorizado a executar a solicitação, o SCEF, dependendo do tipo, acionará o evento no HSS ou MME (Fig. 4). Quando um evento ocorre, o MME ou HSS gera um relatório para o lado do SCEF, que o envia ao AS.
Todos os eventos, exceto "Número de UEs presentes em uma área geográfica" são fornecidos pelo HSS. Os dois eventos "Alteração da associação IMSI-IMEI" e "Status de roaming" são rastreados diretamente no HSS; o restante do HSS será provisionado no MME.
Os eventos podem ser únicos ou periódicos e são determinados por seu tipo.
O relatório de eventos (relatório) é enviado pelo nó de rastreamento de eventos diretamente para o SCEF (Fig. 5).
Um 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 de maneira clássica via MME-SGW-PGW.
Vamos dar uma olhada em cada um dos eventos de monitoramento:
Perda de conectividade - informa que o UE não está mais disponível para tráfego de dados ou sinalização. O evento ocorre quando o "timer de acessibilidade móvel" para o UE expira no MME. Na solicitação para esse tipo de monitoramento, o AS pode indicar seu valor "Tempo Máximo de Detecção" - se o UE não mostrar nenhuma atividade durante esse tempo, o AS será informado de que o UE está indisponível, indicando o motivo. O evento também ocorre se o UE foi removido à força pela rede por qualquer motivo.
* Para que a rede saiba que o dispositivo ainda está disponível, inicia periodicamente o procedimento de atualização - Atualização da área de rastreamento (TAU). A frequência deste procedimento é definida pela rede usando o timer T3412 ou (T3412_ extendido no caso de PSM), cujo valor é transmitido ao dispositivo durante o procedimento Attach ou a próxima TAU. O cronômetro de acessibilidade móvel geralmente é vários minutos mais longo que o T3412. Se o UE não fizer uma TAU antes que o cronômetro de acessibilidade móvel expire, a rede considerará que ela não está mais disponível.
Acessibilidade no UE - Mostra quando o UE fica disponível para tráfego DL ou SMS. Isso acontece quando o UE fica disponível para paginação (para o UE no modo eDRX) ou quando o UE alterna para o modo CONECTADO ECM (para o UE no modo PSM ou eDRX), ou seja, faz uma TAU ou envia um pacote de ligação ascendente.
Relatório de localização - Este tipo de evento de monitoramento permite que o AS solicite dados de localização do UE. É possível solicitar o local atual (Último local) ou o último conhecido (Último local conhecido, determinado pelo ID da célula a partir da qual o dispositivo efetuou a TAU ou o tráfego transmitido pela última vez), o que é importante para dispositivos nos modos de economia de energia PSM ou eDRX. Para "Local atual", o AS pode solicitar repetições repetidas, com o MME informando o AS cada vez que a localização do dispositivo é alterada.
Alteração da associação IMSI-IMEI - Quando esse evento é ativado, o SCEF começa a rastrear a alteração na conexão entre IMSI (identificador de cartão SIM) e IMEI (identificador de dispositivo). Quando ocorre um evento - informa AS. Ele pode ser usado para reatribuir automaticamente o ID externo ao dispositivo durante o trabalho de substituição planejado ou servir como um identificador para o roubo do dispositivo.
Status de roaming - esse tipo de monitoramento é usado pelo AS para determinar se o UE está na rede doméstica ou na rede do parceiro de roaming. Opcionalmente, o PLMN (Rede Móvel Terrestre Pública) da operadora na qual o dispositivo está registrado pode ser transferido.
Falha na comunicação - Este tipo de monitoramento informa o SA sobre falhas na comunicação com o dispositivo, com base nos motivos da conexão (código de causa da liberação) recebida da rede de acesso por rádio (protocolo S1-AP). Este evento pode ajudar a determinar o motivo da falha de comunicação - devido a problemas de rede, por exemplo, quando o eNodeb (recursos de rádio não disponível) está sobrecarregado ou porque o próprio dispositivo (conexão de rádio com UE perdida) falhou.
Disponibilidade após falha no DDN - esse evento informa ao AS que o dispositivo ficou disponível após uma falha de comunicação. Pode ser utilizado quando é necessário transferir dados para o dispositivo, mas a tentativa anterior não teve êxito, uma vez que o UE não respondeu à notificação da rede (paginação) e os dados não foram entregues. Se esse tipo de monitoramento foi solicitado para o UE, assim que o dispositivo fizer a comunicação de entrada, fizer uma TAU ou enviar dados para a ligação ascendente, o AS será informado de que o dispositivo ficou disponível. Como o procedimento DDN (notificação de dados de downlink) funciona entre o MME e o S / P-GW, esse tipo de monitoramento está disponível apenas para dispositivos IP.
Status de conectividade do PDN - informa o AS ao alterar o status do dispositivo (status de conectividade do PDN) - conectar (ativar o PDN) ou desconectar (excluir o PDN). Isso pode ser usado pelo AS para iniciar a comunicação com o UE, ou vice-versa, para entender que a comunicação não é mais possível. Esse tipo de monitoramento está disponível para dispositivos IP e não IP.
Número de UEs presentes em uma área geográfica - esse tipo de monitoramento é usado pelo AS para determinar o número de UEs em uma área geográfica específica.
Disparo do dispositivoNas redes 2G / 3G, o procedimento de registro na rede era de duas etapas: primeiro, o dispositivo era registrado no SGSN (procedimento de conexão) e, se necessário, transmitia o contexto do PDP ativado por dados - conexão ao gateway de pacote (GGSN). Nas redes 3G, esses dois procedimentos foram seqüenciais, ou seja, o dispositivo não esperou o momento em que era necessário transferir dados, mas ativou o PDP imediatamente após a conclusão do procedimento de conexão. No LTE, esses dois procedimentos foram combinados em um, ou seja, quando conectado, o dispositivo solicitou imediatamente a ativação da conexão PDN (analógica do PDP em 2G / 3G) via eNodeB para MME-SGW-PGW.
NB-IoT define um método de conexão como "anexar sem PDN", ou seja, o UE faz a conexão sem estabelecer uma conexão PDN. Nesse caso, ele não está disponível para transmissão de tráfego e só pode receber ou enviar SMS. Para enviar um comando para ativar um PDN e conectar-se ao AS nesse dispositivo, foi desenvolvida a funcionalidade "Device triggering".
Após o recebimento de um comando para conectar esse UE do AS, o SCEF através do centro de SMS inicia o envio de um SMS de controle para o dispositivo. Ao receber um SMS, o dispositivo ativa o PDN e se conecta ao AS para receber instruções subseqüentes ou transferir dados.
Pode haver momentos em que uma assinatura de um dispositivo expire no SCEF. Sim, a assinatura tem seu próprio tempo de vida, definido pelo operador ou acordado com o AS. MME PDN, AS. “Device triggering”. AS SCEF SMS-.
ConclusãoSCEF, , . SCEF . , .
, «»- ? . nidd_scef@mts.ru, , .
!
: