Interaction avec NIDD via SCEF à l'aide de l'utilitaire Postman. Une brève visite de SCEF et de ses fonctionnalités

Cet article permettra à ceux qui commencent tout juste leur développement ou qui appliquent déjà la technologie NB-IoT de se faire une idée de la façon d'interagir à distance avec le dispositif NB-IoT.

image

Bref avis


NB-IoT marche facilement sur les talons de la 2G et s'est imposé comme une norme écoénergétique pour les communications cellulaires, qui dans un avenir prévisible sera en mesure de faire sortir la 2G, ce qui a renforcé sa position. La raison en est la capacité à aborder avec souplesse le problème de la consommation d'énergie de l'une des parties les plus consommatrices de l'appareil - l'émetteur radio. Si vous n'entrez pas dans les détails, alors avec NB-IoT, nous avons la possibilité de configurer de manière flexible les modes de fonctionnement de l'appareil en définissant le calendrier de communication de l'appareil et l'interaction de l'appareil avec les serveurs sur Internet.

Parallèlement à cela, le nombre de dispositifs d'abonnés connectés simultanément à une cellule augmente considérablement, ainsi que les coûts de l'opérateur mobile pour maintenir l'opérabilité de cette communication elle-même.

On suppose que le lecteur a une compréhension approximative de la technologie NB-IoT et qu'il y a une expérience d'interaction minimale.
L'article est régulièrement mis à jour et mis à jour.


Difficultés au sein du réseau NB-IoT


Associé à la capacité de contrôler l'émetteur radio et à une efficacité énergétique élevée, le problème de l'envoi de données en direction du serveur vers le module (périphérique) est venu. La raison en est qu'il est possible de fournir des centaines de milliers de périphériques avec des adresses IP blanches, mais cela implique une grande quantité de surcharge et réduit la fiabilité globale du réseau en raison de sa complexité. Le module reçoit l'adresse du NAT de l'opérateur et il est difficile pour l'opérateur de la traduire "out" en raison du grand nombre d'appareils. Par exemple: 100 000 appareils, c'est le même nombre d'adresses IP et dans le cadre d'IPv4, il ne semble tout simplement pas possible de le mettre en œuvre. La transition vers IPv6 peut résoudre ce problème, mais vous devez toujours payer pour l'adresse «blanche» de l'appareil sur le réseau, ce qui affectera considérablement la poche des clients d'entreprise.

Autrement dit, dans le cas général, il s'avère que l'appareil ne peut fonctionner qu'en mode unidirectionnel, en transmettant des données au serveur sans possibilité de recevoir des données du serveur, car le serveur n'est pratiquement pas au courant lorsque l'appareil entre en contact pour la première fois. Ou, utilisez en moyenne pas plus de cinq minutes après l'établissement de la connexion entre l'appareil et le serveur pour transférer des données du serveur vers l'appareil.

NIDD (Non-IP Data Delivery) - pourquoi est-ce nécessaire?


Lorsque vous travaillez avec le réseau NB-IoT, il est très difficile de se tourner vers un appareil pour transmettre une commande ou certaines données. Pour résoudre ce problème, un mécanisme d'optimisation du transfert de petites quantités de données, la livraison de données non IP (NIDD), a été inventé. Le mécanisme réduit la taille globale du message transmis en réduisant les en-têtes. Ceci, à son tour, affecte positivement les caractéristiques de l'appareil: il réduit la consommation d'énergie et augmente l'autonomie (autonomie de la batterie). En conséquence, le rejet de la prise en charge IP entraîne des appareils moins chers, un temps de développement réduit, une compétitivité accrue sur le marché des appareils IoT, etc.

SCEF (Service Capability Exposure Function) - un cadeau pour les utilisateurs


Le SCEF est un élément de réseau fonctionnel qui est apparu pour la première fois et le 3GPP version 13, déployé du côté de l'opérateur mobile et fournissant un canal de communication sécurisé entre le SCS / AS (Service Capability Server / Application Server) et le dispositif NB-IoT. SCEF fournit un canal de communication lors de la communication avec l'appareil via NIDD et donne accès à des capacités / services réseau supplémentaires du réseau NB-IoT via une interface de programmation d'application unique (à partir de la description de l'API T8). Dans la version 13 du 3GPP, seul le mécanisme SCEF d'interfaçage avec les interfaces de réseau cellulaire a été normalisé. Ainsi, la charge du réseau est optimisée, l'interaction avec l'appareil est simplifiée, l'algorithme de l'appareil lui-même est simplifié.SCEF répond également à des exigences élevées en matière de sécurité de la transmission de données et de satisfaction des exigences pour confirmer le transfert de données réussi dans les deux sens.


SCEF vous permet d'abstraire de systèmes complexes d'interaction avec le dispositif NB-IoT, y compris lorsque ce dernier est en mode eDRX ou PSM et n'est pas disponible pour le transfert de données en direction du serveur-> dispositif. Lorsque l'appareil a été enregistré et «convenu» avec le réseau de l'opérateur du réseau au sujet du calendrier de communication, à l'aide d'une interface simple, vous pouvez transférer des données vers l'appareil et en recevoir des données, gérer «l'abonnement» de votre appareil et de l'AS à certains événements, définir et lier vous-même des événements uniques. Noms d'identification universels et plus. Tout cela via la même interface - API T8.

Il est important de noter qu'un serveur (AS) peut être non pas un, mais plusieurs, et vous pouvez configurer de manière flexible la distribution des informations entre les serveurs pour certains événements ou groupes de périphériques.

Comment ça fonctionne


La solution la plus populaire pour organiser l'accès d'un appareil à un réseau cellulaire est l'utilisation d'un module cellulaire, par exemple:


Lors de son inscription dans un réseau cellulaire, un tel module transmet à l'opérateur certaines informations, notamment l'IMSI d'une carte SIM d'abonné que l'opérateur peut associer au compte d'abonné ou à l'abonné lui-même s'il a accès au compte personnel de l'opérateur. Derrière l'écran SCEF se cache la connaissance de la prochaine session de communication avec l'appareil. L'enregistrement d'un appareil non IP sur le réseau de l'opérateur n'est possible que s'il existe au moins un abonnement SCS / AS à cet appareil. Aucun abonnement - personne ne communiquera avec cet appareil via NIDD, et l'appareil ne sera pas enregistré sur le réseau. Ainsi, SCEF, connaissant la prochaine session de communication, est en mesure de transférer des données depuis / vers l'appareil, conformément aux paramètres de livraison spécifiés et à la durée de vie du message transmis, sans avoir besoin d'organiser une surveillance supplémentaire de l'état du transfert de données et du contrôle de livraison.

Légèreté


L'encapsulation d'unités d'octets de données de l'appareil dans le protocole TCP et leur transfert vers le serveur sont coûteux en termes de centaines de milliers d'appareils abonnés dans le parc de l'entreprise. SCEF vous permet d'abandonner l'IP sur l'appareil et de transférer uniquement des données non IP, sans en-têtes IP via le canal de signal, ce qui contribue à une réduction multiple du coût de l'octet transmis et offre des avantages supplémentaires de l'utilisation du service. De plus, SCEF n'apporte aucune modification aux données transmises à la fois à l'appareil et à partir de celui-ci, la charge utile est transmise de manière transparente. Par conséquent, en utilisant NIDD, il est possible de transférer non seulement des données non structurées, mais également des données «enveloppées» dans un format standardisé compréhensible, tel que JSON, pour simplifier le traitement des données côté AS.

Début des travaux


La structure de l'URI (Uniform Resource Identifier) ​​sur l'exemple de Postman


Tout d'abord, vous devez avoir accès à votre compte personnel auprès de l'opérateur (service M2M-manager). Pour la mise en œuvre commerciale de MTS, une seule interface de compte personnel est fournie, où vous pouvez créer indépendamment un APN, un accès de connexion / mot de passe à l'API et attribuer les noms ScsAsID, extID pour vos appareils.

Ceux. nous aurons au moins besoin:
  • ScsAsID - Votre ID AS
  • APN - celui qui est généralement utilisé pour interagir avec le réseau ne fonctionnera pas
  • Login / Password - données d'accès à votre compte personnel et d'interaction avec SCEF
  • URI - Adresse HTT et port sur le réseau mis à votre disposition par SCEF
  • externalID - ID de notre appareil


Passons à la pratique


La théorie est terminée, passons à la partie la plus intéressante - la pratique sur le module de production SIMCom Wireless Solutions - SIM7020E .

Vous devez d'abord configurer le module lui-même pour qu'il fonctionne avec NIDD. Pour ce faire, mettez d'abord le module en mode CFUN = 0 et configurez-le:

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

Vérification de l'enregistrement du module dans le réseau de données par paquets

AT+CGREG?
+CGREG: 0,1

OK

Et terminer la configuration de NIDD

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

OK

La réponse du module contiendra account_id ici: + NIDD = 0, <account_id> - cela sera utile lors de l'activation de NIDD sur le module.

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

OK

Dans ce cas, account_id est 0.

Terminé. À ce stade, le travail avec le module est terminé. Passons à la configuration de SCEF.

Un point important: sans abonnement enregistré au SCEF, le module ne recevra pas d'inscription sur le réseau!

SCEF


API T8


Il existe un document spécial détaillant l'interaction avec SCEF. Cette API définit un ensemble de modèles de données, de ressources et de procédures connexes pour la transmission de données non IP.



Travailler avec SCEF et les abonnements aux services - JSON (JavaScript Object Notation)


Les données qui incluent la configuration SCEF et qui sont transmises via HTTP / 1.1 à SCEF doivent être encodées au format JSON, et le corps de la requête HTTP elle-même dans le champ Content-Type doit inclure l'en-tête "application / json". Dans le même temps, si le message a été remis au destinataire et que la confirmation de livraison a été reçue - SCEF doit supprimer la configuration appropriée, envoyer le message via HTTP POST for AS avec le code d'état «200 OK» et activer le rapport d'événement.

Facteur


Je ne m'attarderai pas sur la façon de travailler avec cet utilitaire, sur Internet, vous pouvez trouver de nombreuses critiques. Je peux seulement dire qu'il a quelques limitations dans sa version gratuite, mais nous n'avons pas besoin de beaucoup, la fonctionnalité fournie gratuitement est plus que suffisante pour nos tâches.

Après l'avoir téléchargé et ouvert, le premier onglet nous accueillera - Launchpad, où il nous sera proposé de créer notre première demande, nous ne refuserons pas.


Procédez immédiatement à la configuration de notre nouvel appareil.

Dans un premier temps, nous avons configuré la méthode GET, basculez-la en POST (un peu plus tard, il sera clair pourquoi cela est nécessaire). Dans l'onglet «Autorisation», entrez les «informations d'identification» que nous avons sous la main:


Créez maintenant notre première demande:


Dans le corps de la demande, nous indiquons:

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

Important!
:
  • “duration” – duration SLA SCEF (SCSAS/ID) , SCEF ,
  • “maximumPacketSize” – /

Notons immédiatement que les options suivantes sont possibles dans «pdnEstablishmentOption»:
  • WAIT_FOR_UE - tampon si le périphérique n'est pas disponible (non enregistré sur le réseau ou dans le PSM ou dans un autre état)
  • INDICATE_ERROR - répond immédiatement avec une erreur si le périphérique n'est pas disponible
  • SEND_TRIGGER - utilisez le service de déclenchement d'appareil (canal de livraison alternatif via SMS). Cet article n'est pas pris en compte.

Nous utilisons le même paramètre pour envoyer des données à l'appareil. Et lors de la création d'un abonnement, nous pouvons immédiatement envoyer des données à l'appareil, ce qui réduit le nombre de demandes d'API.
Tout! Vous pouvez cliquer sur le bouton Envoyer et examiner attentivement ce que nous recevons en réponse de 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"
}

Dans l'auto-ligne, nous sommes principalement intéressés par l'ID de la configuration que nous avons créée, il est extrêmement indésirable de la perdre, car les opérateurs ne prendront probablement pas en charge la fonction de demande de toutes les configurations créées. Lorsqu'il y a plusieurs milliers de périphériques créés dans le cadre d'un ScsAsID, trop de charge sera créée sur les serveurs SCEF pour diffuser toutes les configurations de périphériques. Nous prenons cela comme une règle: un appareil = un abonnement dans le cadre du service ScsAsID.

Ainsi, nous pouvons déjà recevoir des données du module sur le serveur, l'adresse IP et le port dont nous avons indiqué ci-dessus.

Transfert de données du module vers l'AS


Essayons de transférer les données de l'appareil vers AS, revenons au module SIM7020E et si nous ne l'avons pas touché depuis le chapitre précédent et ne l'avons pas éteint, nous lui enverrons la commande:

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

Veuillez noter que notre message est encodé en HEX et contient une séquence simple: «abcde».
Presque immédiatement sur le serveur (AS), qui est l'hôte, nous verrons:

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}

Le message lui-même est arrivé dans le codage Base64 et ressemble à ceci:
YWJjZGU=

Si nous traduisons à partir de l'encodage Base64, nous obtenons notre message d'origine:
abcde

Le codage Base64 est utilisé car, lors de l'utilisation du codage ASCII, certaines données sont parfois perdues et l'utilisation de Base64 rend la transmission plus fiable.

Il convient également de noter que dans ce cas, les informations transmises par le module ne sont pas stockées dans SCEF et sont immédiatement transmises à notre serveur via HTTP.

Transfert de données de l'AS vers le module


Afin d'envoyer des données dans le sens de notre AS vers le module, revenons à Postman et créons une nouvelle requête en utilisant la méthode POST et l'encodage Base64. Nous enverrons 1234567890 (en Base64: MTIzNDU2Nzg5MA ==) à notre module:



Veuillez noter qu'un addendum est apparu dans le champ "adresse", dans lequel nous avons indiqué pour quelle configuration nous voulons envoyer le message. Si plusieurs appareils sont inclus dans notre configuration, vous pouvez utiliser l'identifiant «externalGroupID» et tous recevront ces données. Un autre point important est la durée de vie du message envoyé, indiquée en secondes et a une plage assez large.

Soit dit en passant, si l'appareil n'est pas en ligne à ce moment-là, notre message sera mis en mémoire tampon sur SCEF, et la ligne «maximumLatency» nous dira combien de secondes il reste jusqu'à ce que le message soit détruit si l'appareil ne nous contacte pas avant la minuterie que nous avons définie. . Voici à quoi ressemblera la configuration SCEF actuelle demandée (en utilisant le mécanisme GET, plus d'informations ci-dessous):

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

Si, après expiration du délai, l'appareil n'a toujours pas contacté, SCEF informera votre serveur (AS) que le message n'a pas été remis en raison de l'expiration du délai et le message sera supprimé:

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

En cas de succès, SCEF répondra immédiatement:

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

Vous pouvez ajouter la possibilité de hiérarchiser les messages au cas où ils seraient mis en mémoire tampon. Il est régulé par le paramètre «priorité». Lorsqu'un nouveau message est envoyé à l'appareil et si le tampon de remise est dépassé par SCEF, le message sera remplacé par un message de priorité inférieure, sinon le message ne sera pas accepté pour la remise. Il est également possible de supprimer un message du tampon.

Si le message ne peut pas être remis et qu'il est mis en mémoire tampon, vous recevrez ce qui suit:

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

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

À la réception du message, le module signalera l'URC suivant:

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

Lequel en traduction de HEX en ASCII sera notre message:

1234567890

Laissez-le ici. Notification de remise d'un message "tamponné":

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

La surveillance de l'état de l'état de l'appareil est possible via un autre service SCEF appelé «Monitoring Event (MONTE)». Au sein de MONTE, il est possible de recevoir des notifications sur les événements et l'heure (par exemple, lorsque l'appareil devient disponible), en utilisant un système d'abonnement similaire. Mais parlons-en une autre fois.

Obtenir la configuration de SCEF


Vous avez probablement remarqué que vous pouvez obtenir la configuration actuelle de SCEF. Faisons cela. Nous prenons le facteur que nous avons déjà aimé et créons la demande suivante en utilisant la méthode GET:


Ceux. nous laissons le corps du message lui-même vide, et dans la barre d'adresse nous avons juste besoin de spécifier l'ID de la configuration créée pour nous afin de recevoir son état actuel en réponse:

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

Suppression d'une configuration sur SCEF


Eh bien et le dernier - nous supprimerons la configuration créée par nous. Pour ce faire, utilisez la même barre d'adresse que dans la configuration actuelle, mais changez-la en SUPPRIMER:


En réponse, nous recevrons:

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

Où dans la ligne «état», nous verrons que la configuration que nous avons créée est supprimée.

Conclusion


Plus d'une thèse peut être écrite sur le sujet de l'utilisation de SCEF, le sujet est vaste et deviendra bientôt extrêmement pertinent pour de nombreux appareils M2M dans tous les domaines, et en particulier pour l'Internet des objets. La principale chose que je voulais vous dire était comment commencer à travailler avec NIDD et SCEF hors de la boîte afin que vous puissiez le découvrir par vous-même. Mais je suis également toujours heureux de vous aider: support@simcom.com (marqué pour l'équipe RUS), dans la lettre, vous devez indiquer vos coordonnées et quelques mots sur votre projet.

Dans les articles suivants, nous analyserons soigneusement d'autres aspects du travail avec les modules cellulaires, et vous écrivez dans les commentaires quel sujet vous intéressera.

Je tiens à remercier tout particulièrement Sergey Novikov, l'expert principal des solutions convergentes et des services multimédias.sanov) de MTS pour une aide inestimable dans la préparation de l'article.

Sources utilisées


NB-IoT: comment ça marche? Partie 3: SCEF - un guichet unique d'accès aux services de l'opérateur
ETSI TS 129 122

All Articles