NB-IoT : comment ça fonctionne ? Partie 3 : SCEF – une fenêtre unique d'accès aux services de l'opérateur

Dans l'article «NB-IoT : comment ça fonctionne ? Partie 2», en parlant de l'architecture du noyau de réseau NB-IoT, nous avons mentionné l'émergence d'un nouveau nœud, le SCEF. Nous expliquons dans cette troisième partie ce que c'est et à quoi cela sert.

Lors de la création d'un service M2M, les développeurs d'applications sont confrontés aux questions suivantes :

• comment identifier les appareils ;
• quel algorithme utiliser pour la vérification et l'authentification ;
• quel protocole de transport choisir pour interagir avec les appareils ;
• comment garantir la livraison des données aux appareils ;
• comment organiser et établir des règles pour l'échange de données avec eux ;
• comment contrôler et obtenir des informations sur leur état en temps réel ;
• comment livrer simultanément des données à un groupe d'appareils ;
• comment envoyer simultanément des données d'un appareil à plusieurs clients ;
• comment obtenir un accès unifié aux services supplémentaires de l'opérateur pour gérer son appareil.

Pour résoudre ces problèmes, il est nécessaire de créer des solutions techniques propriétaires « lourdes », ce qui entraîne une augmentation du temps de travail et du délai de commercialisation des services. C'est là qu'intervient le nouveau nœud SCEF.

Selon la définition du 3GPP, le SCEF (service capability exposure function) est un tout nouveau composant de l'architecture 3GPP, dont la fonction est d'exposer en toute sécurité les services et les capacités fournis par les interfaces du réseau 3GPP via des API.

En termes simples, le SCEF est un intermédiaire entre le réseau et le serveur d'applications (application server — AS), un point d'accès unique aux services de l'opérateur pour gérer son appareil M2M dans le réseau NB-IoT via une interface API standardisée intuitive.

Le SCEF masque la complexité du réseau de l'opérateur, permettant aux développeurs d'applications de s'abstraire des mécanismes d'interaction complexes et spécifiques avec les appareils.

Grâce à la transformation des protocoles réseau en une interface API familière pour les développeurs d'applications, SCEF facilite la création de nouveaux services et réduit le time-to-market. De plus, ce nouveau nœud inclut des fonctions d'identification/authentification des appareils mobiles, définit les règles d'échange de données entre l'appareil et l'AS, déchargeant ainsi les développeurs d'applications de la nécessité de mettre en œuvre ces fonctions de leur côté, les transférant aux opérateurs.

SCEF regroupe les interfaces nécessaires à l'authentification et l'autorisation des serveurs d'applications, au maintien de la mobilité de l'UE, au transfert de données et au déclenchement des appareils, à l'accès aux services supplémentaires et aux fonctionnalités du réseau de l'opérateur.

Un seul et unique interface T8, interface API (HTTP/JSON), standardisée par le 3GPP, est dirigé vers l'AS. Toutes les interfaces, excepté T8, fonctionnent sur la base du protocole DIAMETER (voir fig. 1).

T6a – interface entre SCEF et MME. Utilisé pour les procédures de gestion de la mobilité/de session, le transfert de données non IP, le provisionnement d'événements de surveillance et la réception de rapports à leur sujet.

S6t – interface entre SCEF et HSS. Nécessaire pour l'authentification de l'abonné, l'autorisation des serveurs d'applications, la récupération de l'association ID externe et IMSI/MSISDN, le provisionnement d'événements de surveillance et la réception de rapports à leur sujet.

S6m/T4 – interfaces de SCEF à HSS et SMS-C (dans le 3GPP, un nœud MTC-IWF est défini, qui est utilisé pour le déclenchement d'appareils et le transfert de SMS dans les réseaux NB-IoT. Cependant, dans toutes les implémentations, les fonctionnalités de ce nœud sont intégrées à SCEF, de sorte que pour simplifier le schéma, nous ne le considérerons pas séparément). Utilisées pour obtenir des informations de routage pour l'envoi de SMS et l'interaction avec le centre SMS.

T8 – interface API de SCEF avec les serveurs d'applications. À travers cette interface, des commandes de gestion ainsi que du trafic sont transmis.

*En réalité, il existe plus d'interfaces, seules les plus fondamentales sont énumérées ici. La liste complète est fournie dans 3GPP 23.682 (4.3.2 Liste des points de référence).

Voici les fonctions et services clés de SCEF :

• liaison de l'identifiant de la carte SIM (IMSI) à l'ID externe ;
• transfert de trafic non IP (Non-IP Data Delivery, NIDD);
• opérations groupées, avec utilisation de l'ID de groupe externe;
• prise en charge du mode de transfert de données avec accusé de réception;
• mise en tampon des données MO (Mobile Originated) et MT (Mobile Terminated);
• authentification et autorisation des appareils et des serveurs d'applications;
• utilisation simultanée des données d'un UE par plusieurs AS;
• prise en charge de fonctionnalités spéciales de contrôle de l'état de l'UE (MONTE – Surveillance des événements);
• déclenchement des dispositifs;
• assurance du roaming des données non-IP.

Le principe fondamental de l'interaction entre AS et SCEF repose sur un schéma de ce qu'on appelle les abonnements. Lorsqu'un accès à un service est nécessaire pour un UE donné, le serveur d'applications doit créer un abonnement en envoyant une commande à une API spécifique du service demandé et en recevant en réponse un identifiant unique. Par la suite, toutes les actions et communications avec l'UE dans le cadre de ce service se feront en utilisant cet identifiant.

ID externe : identifiant unique de l'appareil

Un des changements les plus importants dans le schéma d'interaction entre AS et les dispositifs lors de l'utilisation de SCEF est l'apparition de l'identifiant universel. Désormais, au lieu du numéro de téléphone (MSISDN) ou de l'adresse IP, comme c'était le cas dans les réseaux classiques 2G/3G/LTE, l'identifiant de l'appareil pour le serveur d'applications devient l'« ID externe ». Il est défini par la norme dans un format familier pour les développeurs d'applications « @ ».

Les développeurs n'ont plus besoin de mettre en œuvre des algorithmes d'authentification des appareils, le réseau prend entièrement cette fonction en charge. L'ID externe est lié à l'IMSI, et le développeur peut être sûr qu'en accédant à un ID externe spécifique, il interagit avec une carte SIM précise. Lors de l'utilisation d'une puce SIM, une situation unique se présente où l'ID externe identifie de manière unique un appareil spécifique !

De plus, plusieurs ID externes peuvent être liés à un même IMSI — ce qui donne lieu à une situation encore plus intéressante, où l'ID externe identifie de manière unique une application spécifique responsable d'un service sur un appareil donné.

Un identifiant de groupe apparaît également — ID de groupe externe, qui inclut un ensemble d'ID externes distincts. Désormais, avec une seule requête au SCEF, l'AS peut initier des opérations groupées — envoyer des données ou des commandes de contrôle à de nombreux appareils regroupés dans une seule logique de groupe.

Étant donné que pour les développeurs, le passage à un nouvel identifiant d'appareil ne peut pas être instantané, le SCEF a laissé la possibilité de communication entre AS et UE via le numéro standard – MSISDN.

Transmission de données non-IP (Non-IP Data Delivery, NIDD)

Dans le NB-IoT, dans le cadre de l'optimisation des mécanismes de transmission de petites quantités de données, un nouveau type de PDN a été introduit, en plus des types existants tels qu'IPv4, IPv6 et IPv4v6 — le type non-IP. Dans ce cas, l'appareil (UE) ne se voit pas attribuer d'adresse IP, et les données sont transmises sans utiliser le protocole IP. Le trafic pour ces connexions peut être acheminé de deux manières : de manière classique — MME -> SGW -> PGW puis via un tunnel PtP jusqu'à AS (voir fig. 2) ou en utilisant SCEF (voir fig. 3).

La méthode classique n'offre pas d'avantages particuliers par rapport au trafic IP, sauf pour la réduction de la taille des paquets transmis en raison de l'absence d'en-têtes IP. L'utilisation de SCEF ouvre un large éventail de nouvelles possibilités et simplifie considérablement les procédures d'interaction avec les appareils.

Avec la transmission de données via SCEF, deux avantages très importants par rapport au trafic IP classique apparaissent :

La livraison du trafic MT à l'appareil via l'ID externe

Pour envoyer un message à un appareil IP classique, l'AS doit connaître son adresse IP. Le problème est que, lors de l'enregistrement, un appareil reçoit généralement une adresse IP « grise » et communique avec le serveur d'applications situé sur Internet via un nœud NAT, où l'adresse grise est traduite en adresse blanche. La liaison entre les adresses grise et blanche ne dure qu'un temps limité, selon les paramètres du NAT. En moyenne, pour TCP ou UDP, cela ne dépasse pas cinq minutes. Cela signifie que si, au cours de ces 5 minutes, il n'y a pas d'échange de données avec cet appareil, la liaison se désagrège et l'appareil devient inaccessible par l'adresse blanche avec laquelle la session a été initiée avec l'AS. Il existe plusieurs solutions :

1. Utiliser un heartbeat. Une fois la connexion établie, l'appareil doit échanger des paquets avec l'AS toutes les quelques minutes, empêchant ainsi la traduction sur le NAT de se fermer. Mais ici, il ne peut pas être question d'efficacité énergétique.

2. Chaque fois que nécessaire, vérifier la présence de paquets pour l'appareil sur l'AS — envoyer un message en uplink.

3. Créer un APN privé (VRF), où le serveur d'applications et les appareils seront dans le même sous-réseau, et attribuer des adresses IP statiques aux appareils. Cela fonctionnera, mais c'est presque irréalisable lorsqu'il s'agit d'un parc de milliers, voire de dizaines de milliers d'appareils.

4. Enfin, l'option la plus appropriée : utiliser l'IPv6, car il n'a pas besoin de NAT, puisque les adresses IPv6 sont disponibles directement sur Internet. Cependant, même dans ce cas, lors de la réinscription d'un appareil, celui-ci recevra une nouvelle adresse IPv6 et ne sera plus accessible à l'ancienne.

Il est donc nécessaire d'envoyer un paquet d'initialisation avec l'identifiant de l'appareil au serveur, afin d'informer de la nouvelle adresse IP de l'appareil. Ensuite, il faut attendre un paquet de confirmation de l'AS, ce qui affecte également l'efficacité énergétique.

Ces méthodes fonctionnent bien pour les appareils 2G/3G/LTE, où il n'y a pas d'exigences strictes en matière d'autonomie et, par conséquent, pas de restrictions sur le temps en ligne et le trafic. Pour le NB-IoT, ces méthodes ne conviennent pas en raison de leur forte consommation d'énergie.

Le SCEF résout ce problème : puisque le seul identifiant de l'appareil pour l'AS est l'ID externe, l'AS peut simplement envoyer un paquet de données au SCEF pour un ID externe spécifique, le SCEF s'occupe du reste. Si l'appareil est en mode d'économie d'énergie PSM ou eDRX, les données seront mises en mémoire tampon et livrées lorsque l'appareil sera disponible. Si l'appareil est accessible au trafic, les données seront livrées immédiatement. Cela s'applique également aux commandes de contrôle.

À tout moment, l'AS peut rappeler le message mis en mémoire tampon vers l'UE ou le remplacer par un nouveau.

Le mécanisme de mise en mémoire tampon peut également être utilisé lors de la transmission de données MO de l'UE vers l'AS. Si le SCEF n'a pas pu livrer les données à l'AS immédiatement, par exemple en cas de travaux de maintenance sur les serveurs de l'AS, ces paquets seront mis en mémoire tampon et garantis livrés dès que l'AS sera disponible.

Comme mentionné précédemment, l'accès à un certain service et l'UE pour l'AS (et NIDD – c'est un service) est régi par les règles et politiques du côté du SCEF, ce qui permet de réaliser la capacité unique d'utiliser simultanément les données d'un même UE par plusieurs AS. C'est-à-dire que si plusieurs AS se sont abonnés à un même UE, alors après avoir reçu les données de l'UE, le SCEF les enverra à tous les AS abonnés. Cela convient bien aux cas où le créateur du parc d'appareils spécialisés partage des données entre plusieurs clients. Par exemple, en créant un réseau de stations météorologiques fonctionnant sur NB-IoT, il est possible de vendre les données de ces stations à de nombreux services simultanément.

Mécanisme de livraison garantie des messages

Reliable Data Service — un mécanisme de livraison garantie des messages MO et MT sans utiliser d'algorithmes spécialisés au niveau du protocole, comme par exemple le handshake dans TCP. Il fonctionne grâce à l'activation d'un drapeau spécial dans la partie de service du message lors des échanges entre UE et SCEF. C'est à l'AS de décider d'activer ou non ce mécanisme lors de la transmission du trafic.

Si le mécanisme est activé, l'UE inclut un drapeau spécial dans la partie de service du paquet en cas de besoin de livraison garantie des trafics MO. Lors de la réception d'un tel paquet, le SCEF répond à l'UE par une confirmation. Si l'UE ne reçoit pas le paquet de confirmation, le paquet sera réexpédié vers le SCEF. Le même processus s'applique pour les trafics MT.

Surveillance des appareils (monitoring events - MONTE)

Comme mentionné précédemment, la fonctionnalité du SCEF inclut, entre autres, les fonctions de contrôle de l'état de l'UE, appelées surveillance des appareils. Si de nouveaux identifiants et mécanismes de transmission de données sont des optimisations (même très sérieuses) des procédures existantes, le MONTE est une fonctionnalité complètement nouvelle, non disponible dans les réseaux 2G/3G/LTE. Le MONTE permet à l'AS de suivre des paramètres tels que l'état de connexion, la disponibilité pour la communication, la localisation, le statut de roaming, etc. Nous expliquerons plus en détail chacun de ces points un peu plus tard.

Pour activer un événement de surveillance pour un appareil ou un groupe d'appareils, l'AS s'abonne au service correspondant en envoyant à SCEF une commande de l'API MONTE, qui inclut des paramètres tels que l'ID externe ou l'ID de groupe externe, l'identifiant de l'AS, le type de surveillance, le nombre de rapports que l'AS souhaite obtenir. Si l'AS est autorisé à effectuer la demande, le SCEF provisionne l'événement sur le HSS ou le MME en fonction du type (voir fig. 4). En cas d'événement, le MME ou le HSS génère un rapport vers SCEF, qui l'envoie à l'AS.

Le provisionnement de tous les événements, à l'exception de "Number of UEs present in a geographic area", se fait via le HSS. Deux événements, "Change of IMSI-IMEI Association" et "Roaming Status", sont suivis directement sur le HSS, les autres étant provisionnés par le HSS sur le MME.
Les événements peuvent être ponctuels ou périodiques, selon leur type.

L'envoi du rapport d'événement (reporting) est effectué par le nœud surveillant l'événement directement sur SCEF (Fig. 5).

Point important : les événements de surveillance peuvent s'appliquer à la fois aux dispositifs non-IP connectés via SCEF et aux dispositifs IP transmettant des données par des moyens classiques via MME-SGW-PGW.

Examinons plus en détail chacun des événements de surveillance :

Perte de connectivité — informe l'AS que l'UE n'est plus disponible pour le trafic de données ni pour les échanges de signalisation. Cet événement se produit lorsque le 'mobile reachability timer' pour l'UE expire au niveau du MME. Dans la demande de ce type de surveillance, l'AS peut indiquer sa valeur de 'Maximum Detection Time' — si pendant cette période, l'UE ne montre aucune activité, l'AS sera informé que l'UE est inaccessible, avec une indication de la raison. Cet événement se produit également si l'UE a été supprimée de force du réseau pour une raison quelconque.

* Pour que le réseau sache que l'appareil est toujours accessible, il initie périodiquement la procédure de mise à jour — Tracking Area Update (TAU). La fréquence de cette procédure est définie par le réseau à l'aide du timer T3412 ou (T3412_extended dans le cas de PSM), dont la valeur est transmise à l'appareil lors de la procédure d'Attachement ou du TAU suivant. Le mobile reachability timer est généralement de quelques minutes supérieur à T3412. Si l'UE n'effectue pas de TAU avant l'expiration du 'Mobile reachability timer', le réseau la considère comme inaccessible.

Accessibilité de l’UE – Indique quand l’UE devient accessible pour le trafic DL ou les SMS. Cela se produit lorsque l'UE devient disponible pour le paging (pour l'UE en mode eDRX) ou lorsque l'UE passe en mode ECM-CONNECTÉ (pour l'UE en mode PSM ou eDRX), c'est-à-dire lorsqu'elle effectue un TAU ou envoie un paquet uplink.

Reporting de localisation – Ce type d'événements de surveillance permet à l'AS de demander des données sur la position de l'UE. Il peut s'agir soit de la position actuelle (Current Location), soit de la dernière connue (Last Known Location, déterminée par le cell ID depuis lequel l'appareil a fait un TAU ou a transmis du trafic pour la dernière fois), ce qui est pertinent pour les dispositifs en modes d'économie d'énergie PSM ou eDRX. Pour 'Current Location', l'AS peut demander des rapports répétés, l'MME informant l'AS à chaque changement de position de l'appareil.

Changement de l'association IMSI-IMEI – Lors de l'activation de cet événement, SCEF commence à suivre le changement du lien IMSI (identifiant de la carte SIM) et IMEI (identifiant de l'appareil). Lorsqu'un événement se produit, il informe l'AS. Cela peut être utilisé pour le réassignement automatique de l'ID externe à l'appareil lors de travaux de maintenance ou pour servir d'identifiant pour le vol de l'appareil.

Statut du Roaming – Ce type de surveillance est utilisé par l'AS pour déterminer si l'UE se trouve dans le réseau domestique ou dans le réseau d'un partenaire de roaming. Le PLMN (Public Land Mobile Network) de l'opérateur où l'appareil est enregistré peut être transmis de manière optionnelle.

Échec de communication — Ce type de surveillance informe l'AS des pannes de communication avec l'appareil, en se basant sur les raisons de l'interruption de la connexion (code de cause de libération) reçues du réseau d'accès radio (protocole S1-AP). Cet événement peut aider à déterminer la raison de l'échec de la communication - en raison de problèmes sur le réseau, par exemple, lors de la surcharge de l'eNodeb (ressources radio non disponibles) ou en raison d'une panne de l'appareil lui-même (connexion radio avec l'UE perdue).

Disponibilité après une défaillance DDN – Cet événement informe l'AS que l'appareil est devenu disponible après une défaillance de communication. Cela peut être utilisé lorsqu'il est nécessaire d'envoyer des données à l'appareil, mais que la tentative précédente a échoué, car l'UE n'a pas répondu à la notification du réseau (paging), et les données n'ont pas été livrées. Si ce type de surveillance a été demandé pour l'UE, dès que l'appareil établit une communication entrante, effectue un TAU ou envoie des données en uplink, l'AS sera informé que l'appareil est devenu disponible. Étant donné que la procédure DDN (notification de données descendantes) fonctionne entre MME et S/P-GW, ce type de surveillance n'est disponible que pour les dispositifs IP.

Statut de connectivité PDN – Informe l'AS lors du changement de statut de l'appareil (statut de connectivité PDN) - connexion (activation du PDN) ou déconnexion (suppression du PDN). Cela peut être utilisé par l'AS pour initier une communication avec l'UE, ou inversement, pour comprendre que la communication n'est plus possible. Ce type de surveillance est disponible pour les appareils IP et non-IP.

Nombre d'UE présentes dans une zone géographique – Ce type de surveillance est utilisé par l'AS pour déterminer le nombre d'UE dans une zone géographique donnée.

Déclenchement d'appareils)

Dans les réseaux 2G/3G, le processus d'enregistrement dans le réseau se faisait en deux étapes : d'abord l'appareil s'enregistrait auprès du SGSN (procédure d'attach), puis, si nécessaire pour transmettre des données, il activait le contexte PDP – la connexion avec le passerelle de paquet (GGSN). Dans les réseaux 3G, ces deux étapes se succédaient, c'est-à-dire que l'appareil ne devait pas attendre le moment où il devait transmettre des données, mais activait immédiatement le PDP dès la fin de la procédure d'attach. Dans LTE, ces deux procédures ont été unifiées en une seule, c'est-à-dire qu'au moment de l'attach, l'appareil demandait immédiatement l'activation de la connexion PDN (équivalent PDP en 2G/3G) via l'eNodeB vers le MME-SGW-PGW.

Dans le NB-IoT, un mode de connexion est défini comme "attach without PDN", c'est-à-dire que l'UE réalise un attach sans établir de connexion PDN. Dans ce cas, il n'est pas disponible pour le transfert de trafic et ne peut que recevoir ou envoyer des SMS. Pour transmettre à un tel appareil une commande d'activation de la PDN et de connexion à l'AS, une fonctionnalité appelée "Device triggering" a été développée.

À la réception d'une commande de connexion de cet UE depuis l'AS, SCEF initie l'envoi d'un SMS de commande à l'appareil via le centre SMS. À la réception du SMS, l'appareil active la PDN et se connecte à l'AS pour recevoir des instructions ultérieures ou transmettre des données.

Il peut arriver que l'abonnement de l'appareil à SCEF expire. Oui, l'abonnement a sa durée de vie, fixée par l'opérateur ou convenue avec l'AS. À son expiration, la PDN sera désactivée sur le MME, et l'appareil ne sera plus disponible pour l'AS. Dans ce cas, la fonctionnalité "Device triggering" sera également utile. Lors de la réception de nouvelles données de l'AS, SCEF vérifie l'état de connexion de l'appareil et délivre les données par le canal SMS.

Conclusion

La fonctionnalité SCEF, bien sûr, ne se limite pas aux services décrits ci-dessus et évolue et s'étend constamment. Actuellement, plus d'une dizaine de services ont déjà été standardisés pour SCEF. Nous n'avons abordé que les fonctions principales et demandées par les développeurs, et nous discuterons des autres dans de futurs articles.

La question se pose immédiatement : comment obtenir un accès de test à ce nœud "miraculeux" pour des tests préliminaires et le débogage de cas possibles ? C'est très simple. Tout développeur peut envoyer une demande à iot.info@mts.ru, dans laquelle il suffit d'indiquer l'objectif de la connexion, la description du cas possible et les coordonnées pour être contacté.

À bientôt !

Auteurs :

• expert senior en solutions convergentes et services multimédias Sergey Novikov sanov,
• expert en solutions convergentes et services multimédias Alexey Lapshin aslapsh

Source : habr.com