Dans l'article « NB-IoT: comment ça marche?» Partie 2 ”, parlant de l'architecture du cœur de paquet du réseau NB-IoT, nous avons évoqué l'apparition d'un nouveau nœud SCEF. Nous expliquons dans la troisième partie, de quoi s'agit-il et pourquoi est-il 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
- L'authentification et l'algorithme d'authentification à utiliser;
- quel protocole de transport utiliser pour interagir avec les appareils;
- Comment fournir des données de manière garantie aux appareils
- comment organiser et établir des règles pour l'échange de données avec eux;
- comment surveiller et recevoir des informations sur leur statut en ligne;
- comment livrer simultanément des données à un groupe de leurs appareils;
- Comment envoyer simultanément des données d'un appareil à plusieurs clients;
- comment obtenir un accès unifié à des services d'opérateur supplémentaires pour gérer votre appareil.
Pour les résoudre, il faut 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 commercialisation. C'est là que le nouveau nœud SCEF vient à la rescousse.
Selon la définition du 3GPP, SCEF (fonction de capacité d'exposition de service) est un composant complètement nouveau de l'architecture 3GPP, dont la fonction est d'exposer en toute sécurité les services et capacités fournis par les interfaces réseau 3GPP via l'API.
En termes simples, SCEF est un intermédiaire entre le réseau et le serveur d'applications (AS), une fenêtre d'accès unique aux services de l'opérateur pour gérer son appareil M2M dans le réseau NB-IoT via une API standardisée intuitive.
SCEF cache la complexité du réseau de l'opérateur, permettant aux développeurs d'applications de s'abstenir de mécanismes complexes et spécifiques pour interagir avec les appareils.
En transformant les protocoles réseau en familiers aux développeurs d'applications, l'API SCEF facilite la création de nouveaux services et réduit les délais de commercialisation. En outre, le nouveau nœud comprend les fonctions d'identification / d'authentification des appareils mobiles, déterminant les règles d'échange de données entre l'appareil et l'AS, supprimant la nécessité de la mise en œuvre de ces fonctions par les développeurs d'applications de leur côté, transférant ces fonctions aux épaules de l'opérateur.
SCEF ferme les interfaces nécessaires à l'authentification et à l'autorisation des serveurs d'applications, en maintenant la mobilité UE, le transfert de données et le déclenchement des appareils, l'accès à des services supplémentaires et les capacités du réseau de l'opérateur.
Vers AS, il existe une seule interface T8, une API (HTTP / JSON), un 3GPP normalisé. Toutes les interfaces, à l'exception de T8, fonctionnent sur la base du protocole DIAMETER (Fig. 1).
T6a est l'interface entre SCEF et MME. Utilisé pour les procédures de gestion de la mobilité / session, la transmission de données non IP, l'approvisionnement des événements de surveillance et la réception de rapports à leur sujet.
S6t est l'interface entre SCEF et HSS. Il est nécessaire pour l'authentification de l'abonné, l'autorisation des serveurs d'applications, l'obtention d'un groupe d'ID externes et IMSI / MSISDN, la fourniture d'événements de surveillance et la réception de rapports à leur sujet.
S6m / T4 sont les interfaces de SCEF vers HSS et SMS-C (le nœud MTC-IWF est défini dans 3GPP, qui est utilisé pour déclencher des appareils et envoyer des 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 pour simplification du schéma, 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 - API SCEF pour l'interaction 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 3GPP 23.682 (4.3.2 Liste des points de référence).
Voici les principales fonctionnalités et services de SCEF:
- lier un identifiant de carte SIM (IMSI) à un ID externe;
- livraison de trafic non IP (livraison de données non IP, NIDD);
- opérations de groupe à l'aide d'un ID de groupe externe;
- prise en charge du mode de transfert de données avec confirmation;
- mise en mémoire tampon des données MO (Mobile Originated) et MT (Mobile Terminated);
- l'authentification et l'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;
- Fourniture de données itinérantes non IP.
Le principe de base de l'interaction entre AS et SCEF repose sur ce que l'on appelle abonnements. Si vous devez accéder à un service SCEF pour un UE spécifique, le serveur d'applications doit créer un abonnement en envoyant une commande à une API spécifique du service demandé et en réponse à recevoir un identifiant unique. Après cela, toutes les autres actions et communications avec l'UE dans le cadre de ce service auront lieu à l'aide de cet identifiant.
ID externe: identifiant universel de l'appareilL'un des changements les plus importants dans le schéma d'interaction entre l'AS et les appareils lors de l'utilisation du SCEF est l'émergence 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 sur le réseau 2G / 3G / LTE classique, l'identifiant d'appareil du serveur d'application devient «ID externe». Il est défini par la norme dans le format familier aux développeurs d'applications "<Local Identifier> @ <Domain Identifier>".
Les développeurs n'ont plus besoin d'implémenter des algorithmes d'authentification de périphérique, le réseau prend entièrement cette fonction à sa charge. L'ID externe est attaché à IMSI, et le développeur peut être sûr qu'en se référant à un ID externe spécifique, il interagit avec une carte SIM spécifique. Lorsque vous utilisez une puce SIM, une situation généralement unique est obtenue lorsque l'ID externe identifie de manière unique un appareil spécifique!
De plus, plusieurs ID externes peuvent être attribués à un IMSI - une situation encore plus intéressante est obtenue lorsque l'ID externe identifie de manière unique une application spécifique qui est responsable d'un service particulier sur un appareil particulier.
Un identifiant de groupe apparaît également - un ID de groupe externe, qui comprend un ensemble d'ID externes distincts. Désormais, avec une seule demande à SCEF, AS peut lancer des opérations de groupe - envoyer des données ou des commandes de contrôle à plusieurs appareils combinés en un seul groupe logique.
En raison du fait 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 communication AS avec l'UE via le numéro standard - MSISDN.
Livraison de données non IP (NIDD)Dans NB-IoT, en plus d'optimiser les mécanismes de transfert de petites quantités de données, en plus des types de PDN existants, tels que IPv4, IPv6 et IPv4v6, un autre type est apparu - non IP. Dans ce cas, le périphérique (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: classique - MME -> SGW -> PGW, puis via le tunnel PtP vers AS (Fig. 2) ou en utilisant SCEF (Fig. 3).
La méthode classique n'a pas d'avantages particuliers par rapport au trafic IP, sauf pour réduire la taille des paquets transmis en raison de l'absence d'en-têtes IP. L'utilisation de SCEF ouvre un certain nombre de nouvelles opportunités et simplifie considérablement les procédures d'interaction avec les appareils.
Lors de la transmission de données via SCEF, il existe deux avantages très importants par rapport au trafic IP classique:
Livraison du trafic MT vers l'appareil par ID externePour envoyer un message à un appareil IP classique, l'AS doit connaître son adresse IP. Ici, un problème se pose: puisque l'appareil s'enregistre généralement avec une adresse IP «grise», il communique avec le serveur d'applications, qui se trouve sur Internet, via le nœud NAT, où l'adresse grise est traduite en blanc. Un tas d'adresses IP grises et blanches dure un temps limité, selon les paramètres NAT. En moyenne, pour TCP ou UDP - pas plus de cinq minutes. Autrement dit, si, dans les 5 minutes, il n'y a pas eu d'échange de données avec cet appareil, le forfait sera rompu et l'appareil ne sera plus accessible à l'adresse blanche avec laquelle la session avec AS a été lancée. Il existe plusieurs solutions:
1. Utilisez un rythme cardiaque. Une fois la connexion établie, l'appareil doit échanger avec les paquets AS toutes les quelques minutes, empêchant ainsi la fermeture des traductions NAT. Mais il ne peut être question d'aucune efficacité énergétique.
2. Chaque fois, si nécessaire, vérifiez les packages pour le périphérique sur l'AS - envoyez un message à la liaison montante.
3. Créez un APN privé (VRF), où le serveur d'applications et les périphériques seront sur le même sous-réseau et attribuez des adresses IP statiques aux périphériques. Cela fonctionnera, mais cela est presque impossible lorsqu'il s'agit d'un parc de milliers, des dizaines de milliers d'appareils.
4. Enfin, l'option la plus appropriée: utilisez IPv6, elle n'a pas besoin de NAT, car les adresses IPv6 sont directement accessibles depuis Internet. Cependant, même dans ce cas, lors de la réinscription de l'appareil, il recevra une nouvelle adresse IPv6 et ne sera plus disponible à la précédente.
En conséquence, il est nécessaire d'envoyer un certain paquet d'initialisation avec l'identifiant de périphérique au serveur afin de signaler la nouvelle adresse IP du périphérique. Attendez ensuite le package de confirmation d'AS, 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 d'autonomie et, par conséquent, il n'y a pas de limites de temps sur l'air et le trafic. Pour NB-IoT, ces méthodes ne conviennent pas en raison de leur forte consommation d'énergie.
SCEF résout ce problème: puisque le seul identifiant de périphérique pour AS est un ID externe, il suffit que AS envoie un paquet de données à SCEF pour un ID externe spécifique, 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 deviendra disponible. Si l'appareil est disponible pour le trafic, les données seront livrées immédiatement. Il en va de même pour les équipes de direction.
À tout moment, l'AS peut retirer le message mis en mémoire tampon à l'UE ou le remplacer par un nouveau.
Le mécanisme de mise en mémoire tampon peut également être utilisé lors du transfert de données MO de l'UE vers le côté AS. Si SCEF n'a pas pu livrer les données à 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 pour être livrés dès que l'AS sera disponible.
Comme indiqué ci-dessus, l'accès à un service spécifique et à un UE pour AS (et NIDD est un service) est réglementé par des règles et des politiques du côté SCEF, ce qui permet de réaliser la capacité unique d'utiliser simultanément les données d'un UE par plusieurs AS. C'est-à-dire si plusieurs AS ont souscrit à un UE, alors après avoir reçu des données de l'UE, SCEF les enverra à tous les AS signés. Ceci est bien adapté aux cas où le créateur d'une flotte d'appareils spécialisés fouille 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 des données de celles-ci à de nombreux services en même temps.
Mécanisme de remise de messages garantiReliable Data Service - un mécanisme pour une livraison garantie des messages MO et MT sans l'utilisation d'algorithmes spécialisés au niveau du protocole, comme, par exemple, une prise de contact dans TCP. Il fonctionne en incluant un drapeau spécial dans la partie service du message pendant l'échange entre l'UE et 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, si nécessaire, la livraison garantie du trafic MO inclut un drapeau spécial dans la partie service du paquet. Dès réception d'un tel paquet, le SCEF répond à l'UE avec une confirmation. Si l'UE n'a pas reçu de paquet de confirmation, le paquet sera transmis à SCEF. La même chose se produit pour le trafic MT.
Surveillance des appareils (surveillance des événements - MONTE)Comme mentionné ci-dessus, la fonction SCEF, entre autres, comprend des fonctions de surveillance de l'état de l'UE, ce que l'on appelle surveillance de l'appareil. Et si de nouveaux identifiants et mécanismes de transfert de données sont des optimisations (bien que très sérieuses) des procédures existantes, alors MONTE est une fonctionnalité complètement nouvelle 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 de l'itinérance, etc. Nous vous en dirons plus sur chacun plus tard.
S'il est nécessaire d'activer un événement de surveillance pour un appareil ou un groupe d'appareils, AS souscrit au service correspondant en envoyant à SCEF la commande API MONTE correspondante, qui comprend des paramètres tels que l'ID externe ou l'ID de groupe externe, l'identifiant AS, le type de surveillance, le nombre de rapports, que AS souhaite recevoir. Si l'AS est autorisé à exécuter la demande, SCEF, selon le type, déclenchera l'événement sur le HSS ou le MME (Fig. 4). Lorsqu'un événement se produit, le MME ou le HSS génère un rapport du côté SCEF, qui l'envoie à l'AS.
Tous les événements, à l'exception du «nombre d'UE présents dans une zone géographique», sont fournis par le biais du RSS. Les deux événements «Changement d'IMSI-IMEI Association» et «Roaming Status» sont suivis directement sur le HSS, le reste du HSS sera provisionné sur MME.
Les événements peuvent être ponctuels ou périodiques et sont déterminés par leur type.
Le rapport d'événement (rapport) est envoyé par le nœud de suivi d'événement directement à SCEF (figure 5).
Un 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 qui transmettent les données de 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 pour le trafic de données ou la signalisation. L'événement se produit lorsque le «temporisateur d'accessibilité mobile» pour l'UE expire sur le MME. Dans la demande pour ce type de surveillance, l'AS peut indiquer sa valeur de "Temps de détection maximum" - si l'UE ne montre aucune activité pendant ce temps, 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 que le réseau sache que le périphérique est toujours disponible, il lance périodiquement la 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 de 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 plusieurs minutes plus long que le T3412. Si l'UE n'effectue pas de TAU avant l'expiration du temporisateur d'accessibilité mobile, le réseau considère qu'il n'est plus disponible.
Accessibilité UE - Indique quand l'UE devient disponible pour le trafic DL ou SMS. Cela se produit lorsque l'UE devient disponible pour la pagination (pour l'UE en mode eDRX) ou lorsque l'UE passe en mode ECM-CONNECTED (pour l'UE en mode PSM ou eDRX), c'est-à-dire crée un TAU ou envoie un paquet de liaison montante.
Rapports de localisation - Ce type d'événement de surveillance permet à l'AS de demander des données de localisation UE. L'emplacement actuel (dernier emplacement) ou le dernier emplacement connu (dernier emplacement connu, déterminé par l'ID de cellule à partir duquel l'appareil a créé la TAU ou le trafic transmis pour la dernière fois) peut être demandé, ce qui est important pour les appareils en mode d'économie d'énergie PSM ou eDRX. Pour «Emplacement actuel», l'AS peut demander des répétitions répétées, le MME informant l'AS chaque fois que l'emplacement de l'appareil est modifié.
Changement d'association IMSI-IMEI - Lorsque cet événement est activé, SCEF commence à suivre le changement de connexion entre IMSI (identifiant de carte SIM) et IMEI (identifiant d'appareil). Lorsqu'un événement se produit - informe AS. Il peut être utilisé pour réaffecter automatiquement l'ID externe à l'appareil lors des travaux de remplacement prévus ou servir d'identifiant pour le vol de l'appareil.
État d'itinérance - ce type de surveillance est utilisé par l'AS pour déterminer si l'UE est dans le réseau domestique ou dans le réseau du partenaire d'itinérance. En option, le PLMN (Public Land Mobile Network) de l'opérateur auprès duquel l'appareil est enregistré peut être transféré.
Échec de communication - Ce type de surveillance informe l'AS des échecs de communication avec l'appareil, en fonction des raisons de la connexion (code de cause de libération) reçue du réseau d'accès radio (protocole S1-AP). Cet événement peut aider à déterminer la raison de l'échec de communication - en raison de problèmes de réseau, par exemple, lorsque eNodeb (ressources radio non disponibles) est surchargé ou parce que le périphérique lui-même (connexion radio avec UE perdue) a échoué.
Disponibilité après l'échec du DDN - cet événement informe l'AS que le périphérique est devenu disponible après un échec de communication. Il peut être utilisé lorsqu'il est nécessaire de transférer des données vers l'appareil, mais la tentative précédente a échoué, car l'UE n'a pas répondu à la notification du réseau (pagination) et les données n'ont pas été transmises. Si ce type de surveillance a été demandé pour l'UE, dès que le périphérique établit une communication entrante, établit une TAU ou envoie des données à la liaison montante, AS sera informé que le périphérique est devenu disponible. Étant donné que la procédure DDN (Downlink Data Notification) fonctionne entre le MME et le S / P-GW, ce type de surveillance n'est disponible que pour les appareils IP.
PDN Connectivity Status - informe l'AS lors du changement de l'état de l'appareil (état 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 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 zone géographique spécifique.
Déclenchement de l'appareilDans les réseaux 2G / 3G, la procédure d'enregistrement dans le réseau était en deux étapes: d'abord, le périphérique était enregistré dans SGSN (procédure d'attachement), puis, si nécessaire, transmettait le contexte PDP activé par les données - connexion à la passerelle de paquets (GGSN). Dans les réseaux 3G, ces deux procédures se sont succédées, c'est-à-dire l'appareil n'a pas attendu le moment où il était nécessaire de transférer des données, mais a activé PDP immédiatement après la fin de la procédure de connexion. Dans 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 (analogique de PDP en 2G / 3G) via eNodeB vers MME-SGW-PGW.
NB-IoT définit une méthode de connexion telle que «attacher sans PDN», c'est-à-dire que l'UE établit l'attachement sans établir de connexion PDN. Dans ce cas, il n'est pas disponible pour la transmission du trafic et ne peut que recevoir ou envoyer des SMS. Afin d'envoyer une commande pour activer un PDN et se connecter à l'AS à un tel appareil, la fonctionnalité «Déclenchement d'appareil» a été développée.
Dès réception d'une commande de connexion d'un tel UE à partir de l'AS, le SCEF via le centre SMS initie l'envoi d'un SMS de contrôle au dispositif. Lors de la réception d'un SMS, l'appareil active le PDN et se connecte à l'AS pour recevoir des instructions ultérieures ou transférer des données.
Il peut arriver qu'un abonnement à un appareil expire sur SCEF. Oui, l'abonnement a sa propre durée de vie, fixée par l'opérateur ou convenue avec AS. MME PDN, AS. “Device triggering”. AS SCEF SMS-.
ConclusionSCEF, , . SCEF . , .
, «»- ? . nidd_scef@mts.ru, , .
!
: