Get best of the week

Interação com o NIDD via SCEF usando o utilitário Postman. Um breve tour pelo SCEF e suas características

Este artigo permitirá que aqueles que estão iniciando seu desenvolvimento ou que já estejam aplicando a tecnologia NB-IoT tenham uma idéia de como interagir remotamente com dispositivos NB-IoT.

imagem

Breve revisão


O NB-IoT se destaca facilmente do 2G e se estabeleceu como um padrão energeticamente eficiente para comunicações celulares, que em um futuro próximo poderá espremer o 2G, o que fortaleceu sua posição. A razão para isso é a capacidade de abordar com flexibilidade a questão do consumo de energia de uma das partes mais consumidoras do dispositivo - o transmissor de rádio. Se você não se aprofundar nos detalhes, juntamente com o NB-IoT, temos a oportunidade de configurar com flexibilidade os modos de operação do dispositivo, definindo a programação de comunicação do dispositivo e a interação do dispositivo com os servidores na Internet.

Paralelamente, o número de dispositivos de assinante conectados simultaneamente a uma célula está aumentando significativamente, assim como os custos da operadora móvel de manter a operabilidade dessa própria comunicação.

Supõe-se que o leitor tenha uma compreensão aproximada da tecnologia NB-IoT e que haja uma experiência mínima de interação.
O artigo é atualizado e atualizado regularmente.


Dificuldades na rede NB-IoT


Juntamente com a capacidade de controlar o transmissor de rádio e a alta eficiência energética, surgiu o problema de enviar dados na direção do servidor para o módulo (dispositivo). O motivo é que é possível fornecer centenas de milhares de dispositivos com endereços IP brancos, mas isso implica uma grande quantidade de sobrecarga e reduz a confiabilidade geral da rede devido à sua complexidade. O módulo recebe o endereço para o NAT do operador e é difícil para o operador convertê-lo "fora" devido ao grande número de dispositivos. Por exemplo: 100 mil dispositivos são o mesmo número de endereços IP e, dentro da estrutura do IPv4, simplesmente não parece possível implementá-lo. A transição para o IPv6 pode resolver esse problema, mas você ainda precisa pagar pelo endereço “branco” do dispositivo na rede, o que afetará significativamente o bolso dos clientes corporativos.

Ou seja, no caso geral, verifica-se que o dispositivo só pode funcionar no modo unidirecional transmitindo dados para o servidor sem a possibilidade de receber dados do servidor, porque o servidor praticamente não tem conhecimento quando o dispositivo entra em contato pela primeira vez. Ou use, em média, não mais de cinco minutos após o estabelecimento da conexão entre o dispositivo e o servidor para transferir dados do servidor para o dispositivo.

NIDD (Entrega de dados não IP) - por que isso é necessário?


Ao trabalhar com a rede NB-IoT, é muito difícil recorrer a um dispositivo para transmitir um comando ou alguns dados. Para resolver esse problema, foi inventado um mecanismo para otimizar a transferência de pequenas quantidades de dados, a Entrega de Dados Não-IP (NIDD). O mecanismo reduz o tamanho geral da mensagem transmitida, reduzindo os cabeçalhos. Isso, por sua vez, afeta positivamente as características do dispositivo: reduz o consumo de energia e aumenta a autonomia (duração da bateria). Como resultado, a rejeição do suporte IP leva a dispositivos mais baratos, tempo de desenvolvimento reduzido, aumento da competitividade no mercado de dispositivos IoT, etc.

SCEF (Função de Exposição de Capacidade de Serviço) - um presente para os usuários


O SCEF é um elemento de rede funcional que apareceu pela primeira vez e o 3GPP Release 13, implantado no lado da operadora móvel e fornecendo um canal de comunicação seguro entre o SCS / AS (Servidor de Capabilidade de Serviço / Servidor de Aplicativos) e o dispositivo NB-IoT. O SCEF fornece um canal de comunicação ao se comunicar com o dispositivo via NIDD e fornece acesso a recursos / serviços de rede adicionais da rede NB-IoT através de uma única interface de programação de aplicativos (da descrição da API T8). No 3GPP Release 13, apenas o mecanismo SCEF para interface com interfaces de rede celular foi padronizado. Assim, a carga da rede é otimizada, a interação com o dispositivo é simplificada, o algoritmo do próprio dispositivo é simplificado.O SCEF também cumpre altos requisitos para a segurança da transmissão de dados e o cumprimento de requisitos para confirmar a transferência bem-sucedida de dados em ambas as direções.


O SCEF permite que você abstraia de sistemas complexos de interação com o dispositivo NB-IoT, inclusive quando este está no modo eDRX ou PSM e não está disponível para transferência de dados na direção do servidor-> dispositivo. Quando o dispositivo recebe registro e "concorda" com a rede da operadora sobre a programação da comunicação, usando uma interface simples, você pode transferir dados para o dispositivo e receber dados dele, gerenciar a "assinatura" do seu dispositivo e AS para determinados eventos, definir e vincular você mesmo. Nomes de identificação universal e muito mais. Tudo isso através da mesma interface - API T8.

É importante observar que um servidor (AS) não pode ser um, mas vários, e você pode configurar com flexibilidade a distribuição de informações entre servidores para determinados eventos ou grupos de dispositivos.

Como funciona


A solução mais popular para organizar o acesso de um dispositivo a uma rede celular é o uso de um módulo celular, por exemplo:


Ao se registrar em uma rede celular, esse módulo transmite ao operador algumas informações, incluindo o IMSI de um cartão SIM de assinante que o operador pode associar à conta do assinante ou ao próprio assinante, se ele tiver acesso à conta pessoal do operador. Por trás da tela do SCEF está oculto o conhecimento da próxima sessão de comunicação com o dispositivo. O registro de um dispositivo não IP na rede da operadora só é possível se houver pelo menos uma assinatura do SCS / AS para este dispositivo. Sem assinatura - ninguém se comunicará com este dispositivo via NIDD, e o dispositivo não será registrado na rede. Assim, o SCEF, sabendo da próxima sessão de comunicação, é capaz de transferir dados de / para o dispositivo, de acordo com os parâmetros de entrega especificados e o tempo de vida da mensagem transmitida, sem a necessidade de organizar um monitoramento adicional do status da transferência e controle de entrega de dados.

Leveza


Encapsular unidades de bytes de dados do dispositivo no protocolo TCP e transferi-lo para o servidor é caro em termos de centenas de milhares de dispositivos de assinante na frota da empresa. O SCEF permite que você abandone o IP no dispositivo e transfira apenas dados não IP, sem cabeçalhos IP através do canal de sinal, o que contribui para uma redução múltipla no custo do byte transmitido e oferece benefícios adicionais com o uso do serviço. Além disso, o SCEF não faz nenhuma alteração nos dados transmitidos, tanto no dispositivo quanto a partir dele, a carga útil é transmitida de forma transparente. Portanto, usando o NIDD, é possível transferir não apenas dados não estruturados, mas também dados "agrupados" em um formato padronizado compreensível, como JSON, para simplificar o processamento de dados no lado AS.

Início do trabalho


A estrutura do URI (Uniform Resource Identifier) ​​no exemplo do Postman


Primeiro de tudo, você precisa acessar sua conta pessoal da operadora (serviço M2M-manager). Para a implementação comercial do MTS, é fornecida uma única interface de Conta Pessoal, na qual você pode criar de forma independente o APN, acessar a API de login / senha e atribuir nomes de ScsAsID, extID para seus dispositivos.

Essa. pelo menos precisaremos de:
  • ScsAsID - Seu ID de AS
  • APN - aquele que geralmente é usado para interagir com a rede não funcionará
  • Login / Senha - dados para acesso à sua conta pessoal e interação com o SCEF
  • URI - endereço e porta HTTP na rede fornecida pelo SCEF
  • externalID - ID do nosso dispositivo


Vamos seguir praticando


A teoria acabou, vamos para a parte mais interessante - a prática no módulo de produção SIMCom Wireless Solutions - SIM7020E .

Primeiro, você precisa configurar o próprio módulo para trabalhar com o NIDD. Para fazer isso, primeiro coloque o módulo no modo CFUN = 0 e configure-o:

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

Verificando o registro do módulo na rede de dados por pacote

AT+CGREG?
+CGREG: 0,1

OK

E termine de configurar o NIDD

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

OK

A resposta do módulo conterá account_id aqui: + NIDD = 0, <account_id> - isso será útil ao ativar o NIDD no módulo.

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

OK

Nesse caso, account_id é 0.

Concluído. Nesta fase, o trabalho com o módulo está concluído. Vamos seguir para a configuração do SCEF.

Um ponto importante: sem uma assinatura registrada no SCEF, o módulo não receberá registro na rede!

SCEF


API T8


Há um documento especial detalhando a interação com o SCEF. Essa API define um conjunto de modelos de dados, recursos e procedimentos relacionados para a transmissão de dados não IP.



Trabalhar com SCEF e assinaturas de serviço - JSON (JavaScript Object Notation)


Os dados que incluem a configuração do SCEF e são transmitidos via HTTP / 1.1 para o SCEF devem ser codificados no formato JSON, e o corpo da própria solicitação HTTP no campo Tipo de Conteúdo deve incluir o cabeçalho "application / json". Ao mesmo tempo, se a mensagem foi entregue ao destinatário e a confirmação da entrega foi recebida - o SCEF deve excluir a configuração apropriada, envie a mensagem via HTTP POST para AS com o código de status "200 OK" e ative o relatório no evento.

Carteiro


Não vou me aprofundar em como trabalhar com esse utilitário. Na Internet, você pode encontrar muitas críticas. Só posso dizer que ele tem algumas limitações em sua versão gratuita, mas não precisamos de muito, a funcionalidade fornecida gratuitamente é mais que suficiente para nossas tarefas.

Após o download e a abertura, a primeira guia nos dará as boas-vindas - Launchpad, onde seremos oferecidos para criar nossa primeira solicitação, não recusaremos.


Prossiga imediatamente para a configuração do nosso novo dispositivo.

Inicialmente, configuramos o método GET, alterne para POST (um pouco mais tarde, ficará claro por que isso é necessário). Na guia "Autorização", insira as "credenciais" que temos disponíveis:


Agora crie nosso primeiro pedido:


No corpo da solicitação, indicamos:

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

Importante!
Prestar atenção em:
  • “duration” – duration SLA SCEF (SCSAS/ID) , SCEF ,
  • “maximumPacketSize” – /

Vamos observar imediatamente que as seguintes opções são possíveis em "pdnEstablishmentOption":
  • WAIT_FOR_UE - buffer se o dispositivo não estiver disponível (não registrado na rede ou no PSM ou em outro estado)
  • INDICATE_ERROR - responda imediatamente com um erro se o dispositivo estiver indisponível
  • SEND_TRIGGER - use o serviço de acionamento de dispositivos (canal de entrega alternativo via SMS). Este artigo não é considerado.

Usamos o mesmo parâmetro para enviar dados para o dispositivo. E ao criar uma assinatura, podemos enviar dados imediatamente para o dispositivo, reduzindo o número de solicitações de API.
Todos! Você pode clicar no botão Enviar e examinar cuidadosamente o que obtemos em resposta do 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"
}

Na linha própria, estamos interessados ​​principalmente no ID da configuração que criamos, é extremamente indesejável perdê-lo, pois é muito provável que os operadores não suportem a função de solicitação de todas as configurações criadas. Quando houver vários milhares de dispositivos criados na estrutura de um ScsAsID, muita carga será criada nos servidores SCEF para transmitir todas as configurações do dispositivo. Tomamos como regra: um dispositivo = uma assinatura como parte do serviço ScsAsID.

Assim, já podemos receber dados do módulo no servidor, cujo endereço IP e porta foram indicados acima.

Transferência de dados do módulo para o AS


Vamos tentar transferir dados do dispositivo para o AS, retornar ao módulo SIM7020E e, se não tocamos no capítulo anterior e não o desativamos, enviaremos o comando para ele:

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

Observe que nossa mensagem é codificada em HEX e contém uma sequência simples: "abcde".
Quase imediatamente no servidor (AS), que é o 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}

A mensagem em si chegou na codificação Base64 e fica assim:
YWJjZGU=

Se traduzirmos da codificação Base64, receberemos nossa mensagem original:
abcde

A codificação Base64 é usada devido ao fato de que ao usar a codificação ASCII, alguns dados são perdidos às vezes e o uso do Base64 torna a transmissão mais confiável.

Note-se também que, neste caso, as informações transmitidas pelo módulo não são armazenadas no SCEF e são imediatamente transmitidas ao nosso servidor via HTTP.

Transferência de dados do AS para o módulo


Para enviar dados na direção do nosso AS para o módulo, vamos voltar ao Postman e criar uma nova solicitação usando o método POST e a codificação Base64. Enviaremos 1234567890 (na Base64: MTIzNDU2Nzg5MA ==) para o nosso módulo:



Observe que um adendo apareceu no campo "endereço", no qual indicamos para qual configuração queremos enviar a mensagem. Se vários dispositivos estiverem incluídos em nossa configuração, você poderá usar o identificador “externalGroupID” e todos receberão esses dados. Outro ponto importante é o tempo de vida da mensagem enviada, indicada em segundos e com uma faixa bastante ampla.

A propósito, se o dispositivo não estiver online no momento, nossa mensagem será armazenada em buffer no SCEF, e a linha "maximumLatency" nos dirá quantos segundos restam até que a mensagem seja destruída se o dispositivo não entrar em contato antes do cronômetro definido. . Abaixo está a aparência da configuração atual solicitada do SCEF (usando o mecanismo GET, mais sobre isso abaixo):

{
    "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"
    }
}

Se, depois que o cronômetro expirar, o dispositivo ainda não entrou em contato, o SCEF notificará seu servidor (AS) de que a mensagem não foi entregue devido à expiração do cronômetro e a mensagem será excluída:

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"}

Se for bem-sucedido, o SCEF responderá imediatamente:

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

Você pode adicionar a capacidade de priorizar mensagens caso elas sejam armazenadas em buffer. É regulado pelo parâmetro "priority". Quando uma nova mensagem é enviada ao dispositivo e se o buffer de entrega for excedido pelo SCEF, a mensagem será substituída por uma mensagem com prioridade mais baixa, caso contrário, a mensagem não será aceita para entrega. Também é possível excluir uma mensagem do buffer.

Se a mensagem não puder ser entregue e estiver em buffer, você receberá o seguinte:

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

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

Após o recebimento da mensagem, o módulo relatará o seguinte URC:

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

Que na tradução de HEX para ASCII será a nossa mensagem:

1234567890

Apenas deixe aqui. Notificação de entrega de uma mensagem "em buffer":

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

O monitoramento do status do dispositivo é possível através de outro serviço SCEF chamado “Monitoring Event (MONTE)”. No MONTE, é possível receber notificações sobre eventos e horários (por exemplo, quando o dispositivo estiver disponível), usando um sistema de assinatura semelhante. Mas vamos falar sobre isso outra hora.

Obtendo configuração do SCEF


Você provavelmente percebeu que pode obter a configuração atual do SCEF. Vamos fazer isso. Pegamos o Postman que já amamos e criamos a seguinte solicitação usando o método GET:


Essa. deixamos o corpo da mensagem em branco e, na barra de endereço, precisamos apenas especificar o ID da configuração criada para nós, a fim de receber seu estado atual em resposta:

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

Excluindo uma configuração no SCEF


Bem e o último - excluiremos a configuração criada por nós. Para fazer isso, use a mesma barra de endereço da configuração atual, mas altere-a para DELETE:


Em resposta, receberemos:

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

Onde na linha "status" veremos que a configuração criada por nós é excluída.

Conclusão


Mais de uma dissertação pode ser escrita sobre o tema do uso do SCEF, o tópico é extenso e em breve se tornará extremamente relevante para muitos dispositivos M2M em todas as áreas, e especialmente para a Internet das coisas. A principal coisa que eu queria transmitir a você era como começar a trabalhar com o NIDD e o SCEF imediatamente, para que você possa descobrir por conta própria. Mas também estou sempre feliz em ajudá-lo: support@simcom.com (marcado para a Equipe RUS). Na carta, você deve indicar seus detalhes de contato e algumas palavras sobre seu projeto.

Nos artigos a seguir, analisaremos cuidadosamente outros aspectos do trabalho com módulos celulares e você escreverá nos comentários qual tópico será do seu interesse.

Quero agradecer especialmente a Sergey Novikov, especialista sênior de soluções convergentes e serviços de multimídia.sanov) do MTS pela assistência inestimável na preparação do artigo.

Fontes utilizadas


NB-IoT: como funciona? Parte 3: SCEF - uma única janela de acesso aos serviços do operador
ETSI TS 129 122

More articles:


All Articles