NB-IoT : comment ça marche ? Volet 3 : SCEF – guichet unique d'accès aux services de l'opérateur

Dans l'article "NB-IoT : comment ça marche ? Partie 2", en parlant de l'architecture du cœur de paquets du réseau NB-IoT, nous avons évoqué l'apparition d'un nouveau nœud SCEF. Nous expliquons dans la troisième partie ce que c'est et pourquoi c'est nécessaire ?

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 de vérification et d'authentification utiliser ;
• quel protocole de transport choisir pour interagir avec les appareils ;
• comment fournir des données de manière fiable aux appareils ;
• comment organiser et établir des règles d'échange de données avec eux ;
• comment surveiller et obtenir des informations sur leur état en ligne ;
• comment transmettre simultanément des données à un groupe de vos 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 votre appareil.

Pour les résoudre, il est nécessaire de créer des solutions propriétaires techniquement « lourdes », ce qui entraîne une augmentation des coûts de main-d'œuvre et des délais de mise sur le marché des services. C'est là que le nouveau nœud SCEF vient à la rescousse.

Tel que défini par 3GPP, SCEF (fonction d'exposition des capacités de service) 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 réseau 3GPP via des API.

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

SCEF masque la complexité du réseau d'un opérateur, permettant aux développeurs d'applications d'abstraire les mécanismes complexes et spécifiques aux appareils pour interagir avec les appareils.

En transformant les protocoles réseau en une API familière aux développeurs d'applications, l'API SCEF facilite la création de nouveaux services et réduit les délais de mise sur le marché. Le nouveau nœud comprend également des fonctions d'identification/authentification des appareils mobiles, définissant les règles d'échange de données entre l'appareil et l'AS, éliminant ainsi la nécessité pour les développeurs d'applications de mettre en œuvre ces fonctions de leur côté, déplaçant ces fonctions vers les épaules de l'opérateur.

SCEF couvre 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 à des services supplémentaires et aux capacités du réseau de l'opérateur.

Vers l'AS il existe une seule interface T8, une API (HTTP/JSON) standardisée par 3GPP. Toutes les interfaces, à l'exception de T8, fonctionnent sur la base du protocole DIAMETER (Fig. 1).

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

S6t – interface entre SCEF et HSS. Requis pour l'authentification des abonnés, l'autorisation des serveurs d'applications, l'obtention d'une combinaison d'ID externe et IMSI/MSISDN, le provisionnement des événements de surveillance et la réception de rapports les concernant.

S6m/T4 – interfaces de SCEF vers HSS et SMS-C (3GPP définit le nœud MTC-IWF, qui est utilisé pour le déclenchement des appareils et la transmission de SMS dans les réseaux NB-IoT. Cependant, dans toutes les implémentations, la fonctionnalité de ce nœud est intégrée dans SCEF, donc par souci de simplification du circuit, nous ne le considérerons pas séparément). Utilisé pour obtenir des informations de routage pour l'envoi de SMS et l'interaction avec le centre SMS.

T8 – Interface API pour l'interaction SCEF avec les serveurs d'applications. Les commandes de contrôle et le trafic sont transmis via cette interface.

*en réalité il y a plus d'interfaces ; seules les plus basiques sont listées ici. Une liste complète est donnée dans le 3GPP 23.682 (4.3.2 Liste des points de référence).

Vous trouverez ci-dessous les principales fonctions et services de SCEF :

• relier l'identifiant de la carte SIM (IMSI) à un identifiant externe ;
• transmission de trafic non IP (Non-IP Data Delivery, NIDD) ;
• opérations de groupe utilisant un ID de groupe externe ;
• prise en charge du mode de transmission de données avec confirmation ;
• mise en mémoire tampon des données MO (Mobile Originated) et MT (Mobile Terended);
• 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 fonctions spéciales de surveillance de l'état de l'UE (MONTE – Monitoring Events) ;
• déclenchement de l'appareil ;
• fournir une itinérance de données non IP.

Le principe de base de l'interaction entre AS et SCEF est basé sur ce qu'on appelle le schéma. abonnements. S'il est nécessaire d'accéder à un service SCEF pour un UE spécifique, le serveur d'applications doit créer un abonnement en envoyant une commande à l'API spécifique du service demandé et recevoir un identifiant unique en réponse. Après quoi, toutes les autres actions et communications avec l'UE dans le cadre de ce service auront lieu en utilisant cet identifiant.

ID externe : identifiant universel de l'appareil

L'un des changements les plus importants dans le schéma d'interaction entre l'AS et les appareils lors du travail via SCEF est l'apparition d'un identifiant universel. Désormais, au lieu d'un numéro de téléphone (MSISDN) ou d'une adresse IP, comme c'était le cas dans le réseau 2G/3G/LTE classique, l'identifiant de l'appareil du serveur d'applications devient un « identifiant externe ». Il est défini par la norme dans un format familier aux 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 en charge cette fonction. L'ID externe est lié à IMSI et le développeur peut être sûr que lorsqu'il accède à un ID externe spécifique, il interagit avec une carte SIM spécifique. Lorsque vous utilisez une puce SIM, vous obtenez une situation tout à fait unique lorsque l'ID externe identifie de manière unique un appareil spécifique !

De plus, plusieurs identifiants externes peuvent être liés à un seul IMSI - une situation encore plus intéressante se produit lorsque l'identifiant externe identifie de manière unique une application spécifique responsable d'un service spécifique sur un appareil spécifique.

Un identifiant de groupe apparaît également - un identifiant de groupe externe, qui comprend un ensemble d'identifiants externes individuels. Désormais, avec une seule requête adressée à SCEF, AS peut lancer des opérations de groupe : envoyer des données ou des commandes de contrôle à plusieurs appareils réunis dans un seul groupe logique.

Étant donné que pour les développeurs AS, la transition vers un nouvel identifiant d'appareil ne peut pas être instantanée, SCEF a laissé la possibilité de communiquer AS avec l'UE via un numéro standard - MSISDN.

Transmission de trafic non IP (Non-IP Data Delivery, NIDD)

Dans NB-IoT, dans le cadre de l'optimisation des mécanismes de transmission de petites quantités de données, en plus des types PDN déjà existants, tels que IPv4, IPv6 et IPv4v6, un autre type est apparu - le non-IP. Dans ce cas, aucune adresse IP n'est attribuée à l'appareil (UE) et les données sont transmises sans utiliser le protocole IP. Le trafic pour de telles connexions peut être acheminé de deux manières : classique - MME -> SGW -> PGW puis via le tunnel PtP vers AS (Fig. 2) ou en utilisant SCEF (Fig. 3).

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

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


Livraison du trafic MT à l'appareil via un identifiant externe

Pour envoyer un message à un équipement IP classique, l'AS doit connaître son adresse IP. Ici, un problème se pose : puisque l'appareil reçoit généralement une adresse IP « grise » lors de l'enregistrement, il communique avec le serveur d'applications, qui se trouve sur Internet, via un nœud NAT, où l'adresse grise est traduite en blanc. La combinaison d'adresses IP grises et blanches dure une durée limitée, en fonction des paramètres NAT. En moyenne, pour TCP ou UDP, pas plus de cinq minutes. Autrement dit, s'il n'y a pas d'échange de données avec cet appareil dans les 5 minutes, la connexion sera rompue et l'appareil ne sera plus accessible à l'adresse blanche avec laquelle la session avec AS a été initiée. Il existe plusieurs solutions :

1. Utilisez le rythme cardiaque. Une fois la connexion établie, l'appareil doit échanger des paquets avec l'AS toutes les quelques minutes, empêchant ainsi la fermeture des traductions NAT. Mais on ne peut pas parler ici d’efficacité énergétique.

2. À chaque fois, si nécessaire, vérifiez la disponibilité des packages pour l'appareil sur l'AS - envoyez un message à la liaison montante.

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

4. Enfin, l'option la plus adaptée : utiliser IPv6, elle ne nécessite pas de NAT, puisque les adresses IPv6 sont directement accessibles depuis Internet. Cependant, même dans ce cas, lorsque l'appareil sera réenregistré, il recevra une nouvelle adresse IPv6 et ne sera plus accessible avec la précédente.

Par conséquent, il est nécessaire d'envoyer un paquet d'initialisation avec un identifiant de périphérique au serveur afin de signaler la nouvelle adresse IP de l'appareil. Attendez ensuite un paquet de confirmation d’AS, ce qui affecte également l’efficacité énergétique.

Ces méthodes fonctionnent bien pour les appareils 2G/3G/LTE, où l'appareil n'a pas d'exigences strictes en matière d'autonomie et, par conséquent, il n'y a aucune restriction sur le temps d'antenne et le trafic. Ces méthodes ne sont pas adaptées au NB-IoT en raison de leur forte consommation d'énergie.

SCEF résout ce problème : puisque le seul identifiant de périphérique pour un AS est un identifiant externe, l'AS n'a besoin que d'envoyer un paquet de données au SCEF pour un ID externe spécifique, et 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 disponible pour le trafic, les données seront transmises immédiatement. Il en va de même pour les équipes de direction.

A 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 SCEF n'a pas pu fournir des données à l'AS immédiatement, par exemple si des travaux de maintenance sont en cours sur les serveurs AS, ces paquets seront mis en mémoire tampon et garantis d'être livrés dès que l'AS sera disponible.

Comme indiqué ci-dessus, l'accès à un service et à un UE spécifiques pour un AS (et NIDD est un service) est réglementé par des règles et des politiques du côté SCEF, ce qui offre la possibilité unique d'utiliser simultanément les données d'un UE par plusieurs AS. Ceux. si plusieurs AS sont abonnés à un UE, alors après avoir reçu des données de l'UE, SCEF les enverra à tous les AS abonnés. Ceci est bien adapté aux cas où le créateur d'un 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, vous pouvez vendre leurs données à de nombreux services simultanément.

Mécanisme de livraison de messages garanti

Reliable Data Service est un mécanisme garantissant la livraison des messages MO et MT sans utiliser d'algorithmes spécialisés au niveau du protocole, comme, par exemple, la prise de contact dans TCP. Il fonctionne en incluant un indicateur spécial dans la partie service du message lors de l'échange entre l'UE et le SCEF. L'activation ou non de ce mécanisme lors de la transmission du trafic est décidée par l'AS.

Si le mécanisme est activé, l'UE inclut un indicateur spécial dans la partie de surdébit du paquet lorsqu'il nécessite une livraison garantie du trafic MO. Dès réception d'un tel paquet, le SCEF répond à l'UE par un accusé de réception. Si l'UE ne reçoit pas le paquet d'accusé de réception, le paquet vers le SCEF sera renvoyé. La même chose se produit pour le trafic MT.

Surveillance des appareils (surveillance des événements - MONTE)

Comme mentionné ci-dessus, la fonctionnalité SCEF comprend, entre autres, des fonctions de surveillance de l'état de l'UE, ce qu'on appelle. surveillance des appareils. Et si les nouveaux identifiants et mécanismes de transfert de données sont des optimisations (quoique très sérieuses) des procédures existantes, alors MONTE est une toute nouvelle fonctionnalité qui n'est pas disponible dans les réseaux 2G/3G/LTE. MONTE permet à AS de surveiller les paramètres de l'appareil tels que l'état de la connexion, la disponibilité de la communication, l'emplacement, l'état d'itinérance, etc. Nous parlerons de chacun plus en détail un peu plus tard.

S'il est nécessaire d'activer un événement de surveillance pour un appareil ou un groupe d'appareils, l'AS s'abonne au service correspondant en envoyant la commande API MONTE correspondante au SCEF, qui comprend des paramètres tels que l'ID externe ou l'ID de groupe externe, l'identifiant AS, la surveillance. type, nombre de rapports que AS souhaite recevoir. Si l'AS est autorisé à exécuter la requête, SCEF, selon le type, fournira l'événement au HSS ou au MME (Fig. 4). Lorsqu'un événement se produit, le MME ou le HSS génère un rapport au SCEF, qui l'envoie à l'AS.

La fourniture de tous les événements, à l'exception du « Nombre d'UE présents dans une zone géographique », s'effectue via HSS. Deux événements « Changement d'association IMSI-IMEI » et « Statut d'itinérance » sont suivis directement sur HSS, le reste sera fourni par HSS sur MME.
Les événements peuvent être ponctuels ou périodiques et sont déterminés par leur type.

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

Point important: Les événements de surveillance peuvent être appliqués à la fois aux appareils non IP connectés via SCEF et aux appareils IP transmettant des données de la manière classique via MME-SGW-PGW.

Examinons de plus près chacun des événements de surveillance :

Perte de connectivité — informe l'AS que l'UE n'est plus disponible ni pour le trafic de données ni pour la signalisation. L'événement se produit lorsque le « temporisateur d'accessibilité mobile » pour l'UE expire sur la MME. Dans une demande pour ce type de surveillance, l'AS peut indiquer sa valeur « Temps de détection maximum » - si pendant ce temps l'UE ne montre aucune activité, l'AS sera informé que l'UE n'est pas disponible, en indiquant la raison. L'événement se produit également si l'UE a été supprimé de force par le réseau pour une raison quelconque.

* Pour informer le réseau que l'appareil est toujours disponible, il lance périodiquement une procédure de mise à jour - Tracking Area Update (TAU). La fréquence de cette procédure est fixée par le réseau à l'aide du temporisateur T3412 ou (T3412_extended dans le cas du PSM), dont la valeur est transmise à l'appareil lors de la procédure Attach ou de la prochaine TAU. Le minuteur d’accessibilité mobile est généralement supérieur de plusieurs minutes à celui du T3412. Si l'UE n'a pas effectué de TAU avant l'expiration du « Mobile reachability timer », le réseau considère qu'il n'est plus joignable.

Accessibilité de l'UE – Indique quand l’UE devient disponible pour le trafic DL ou SMS. Cela se produit lorsque l'UE devient disponible pour la recherche de personnes (pour un UE en mode eDRX) ou lorsque l'UE entre en mode ECM-CONNECTED (pour un UE en mode PSM ou eDRX), c'est-à-dire crée une TAU ou envoie un paquet de liaison montante.

Rapports de localisation – Ce type d'événements de surveillance permet à l'AS d'interroger l'emplacement de l'UE. L'emplacement actuel (emplacement actuel) ou le dernier emplacement connu (dernier emplacement connu, déterminé par l'ID de cellule à partir duquel l'appareil a effectué la TAU ou transmis le trafic la dernière fois) peut être demandé, ce qui est pertinent pour les appareils en mode d'économie d'énergie PSM ou eDRX. modes. Pour « Emplacement actuel », l'AS peut demander des réponses répétées, la MME informant l'AS à chaque fois que l'emplacement de l'appareil change.

Changement d'association IMSI-IMEI – Lorsque cet événement est activé, SCEF commence à surveiller les changements dans la combinaison IMSI (identifiant de la carte SIM) ​​et IMEI (identifiant de l'appareil). Lorsqu'un événement survient, informe AS. Peut être utilisé pour relier automatiquement un identifiant externe à un appareil lors d'un travail de remplacement programmé ou servir d'identifiant en cas de vol d'un appareil.

Statut d'itinérance – ce type de surveillance est utilisé par AS pour déterminer si l'UE se trouve dans le réseau domestique ou dans le réseau d'un partenaire itinérant. En option, le PLMN (Public Land Mobile Network) de l'opérateur auprès duquel l'appareil est enregistré peut être transmis.

Échec de la communication — Ce type de surveillance informe l'AS des échecs de communication avec l'appareil, en fonction des raisons de la perte de connexion (release cause code) reçues du réseau d'accès radio (protocole S1-AP). Cet événement peut aider à déterminer pourquoi la communication a échoué - en raison de problèmes sur le réseau, par exemple lorsque l'eNodeb est surchargé (ressources radio non disponibles) ou en raison d'une défaillance de l'appareil lui-même (connexion radio avec UE perdue).

Disponibilité après un échec DDN – cet événement informe l'AS que l'appareil est devenu disponible après un échec de communication. Peut être utilisé lorsqu'il est nécessaire de transférer des données vers un appareil, mais que la tentative précédente n'a pas abouti car l'UE n'a pas répondu à une notification du réseau (pagination) et les données n'ont pas été livrées. Si ce type de surveillance a été demandé pour l'UE, alors dès que le dispositif établit une communication entrante, effectue une TAU ou envoie des données à la liaison montante, l'AS sera informé que le dispositif est devenu disponible. La procédure DDN (downlink data notification) fonctionnant entre MME et S/P-GW, ce type de surveillance n'est disponible que pour les appareils IP.

État de la connectivité PDN – informe AS lorsque l'état de l'appareil change (état de connectivité PDN) - connexion (activation PDN) ou déconnexion (suppression PDN). Ceci peut être utilisé par l'AS pour initier la communication avec l'UE, ou vice versa, 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ésents dans une zone géographique – Ce type de surveillance est utilisé par l'AS pour déterminer le nombre d'UE dans une certaine zone géographique.

Déclenchement de l'appareil)

Dans les réseaux 2G/3G, la procédure d'enregistrement dans le réseau était en deux étapes : d'abord, l'appareil s'enregistrait auprès du SGSN (procédure d'attachement), puis, si nécessaire, il activait le contexte PDP - une connexion avec la passerelle de paquets (GGSN). pour transmettre des données. Dans les réseaux 3G, ces deux procédures se sont déroulées séquentiellement, c'est-à-dire l'appareil n'a pas attendu le moment où il avait besoin de transférer des données, mais a activé PDP immédiatement après la fin de la procédure de connexion. En LTE, ces deux procédures ont été combinées en une seule, c'est-à-dire que lors de la connexion, l'appareil a immédiatement demandé l'activation de la connexion PDN (analogue au PDP en 2G/3G) via l'eNodeB vers le MME-SGW-PGW.

NB-IoT définit une méthode de connexion comme « attachement sans PDN », c'est-à-dire que l'UE s'attache sans établir de connexion PDN. Dans ce cas, il n'est pas disponible pour transmettre du trafic et peut uniquement recevoir ou envoyer des SMS. Afin d'envoyer une commande à un tel appareil pour activer le PDN et se connecter à l'AS, la fonctionnalité « Déclenchement de l'appareil » a été développée.

Lors de la réception d'une commande pour connecter un tel UE depuis l'AS, SCEF lance l'envoi d'un SMS de contrôle au dispositif via le centre SMS. Lors de la réception d'un SMS, l'appareil active le PDN et se connecte à l'AS pour recevoir des instructions supplémentaires ou transférer des données.

Il peut arriver que l'abonnement de votre appareil expire sur SCEF. Oui, l'abonnement a sa propre durée de vie, fixée par l'opérateur ou convenue avec AS. À l'expiration, le PDN sera désactivé sur le MME et l'appareil deviendra indisponible pour l'AS. Dans ce cas, la fonctionnalité « Déclenchement de l'appareil » sera également utile. Lors de la réception de nouvelles données d'AS, SCEF découvrira l'état de connexion de l'appareil et transmettra les données via le canal SMS.

Conclusion

Bien entendu, les fonctionnalités de SCEF ne se limitent pas aux services décrits ci-dessus et évoluent et s’étendent constamment. Actuellement, plus d'une douzaine de services ont déjà été standardisés pour SCEF. Nous n'avons maintenant abordé que les principales fonctions demandées par les développeurs, nous parlerons du reste dans les prochains articles.

La question se pose immédiatement : comment obtenir un accès test à ce nœud « miracle » pour des tests préliminaires et le débogage des cas possibles ? Tout est très simple. Tout développeur peut soumettre une demande à [email protected], dans lequel il suffit d'indiquer le but de la connexion, une description d'un cas possible et les coordonnées pour la communication.

Jusqu'à la prochaine fois!

Auteurs:

• expert senior du département des solutions convergentes et des services multimédia Sergueï Novikov sanov,
• expert du département solutions convergentes et services multimédia Alexey Lapshin aslapsh

Source: habr.com