Archives du mot-clef SCEF

L’IoT – Evolutions R16 et R17

Posté le by - 602 vues
Répondre

Introduction

Le standard 3GPP a démarré ses travaux de normalisation pour l’IoT à partir de la R.10 pour définir une liste de spécifications pour les terminaux et le cœur de réseau afin d’éviter la congestion (Extended Access Barring), d’avoir moins d’impact sur les smartphones (LAPI), réduire la complexité (Half Duplex, réduction de la puissance, bande plus petite …), avoir une meilleure sensibilité pour une transmission à faible débit (bande plus petite).

Dans la R.11, la 3GPP propose une méthode de réveil de terminaux et une transmission de données par SMS.

Dans la R.12, la 3GPP propose des optimisations pour la réduction de la consommation énergétique (UEPCOP : mode PSM et eDRX) et une méthode de transmission de données de taille réduite (Small Data)

Figure 1 : Le standard 3GPP R10 à R12 pour l’IoT

Dans la R.13, la 3GPP une optimisation du cœur de réseau pour prendre en charge la transmission de données :

  • dans le plan de contrôle Control-Plane CIoT EPS Optimization ;
  • dans le plan de trafic User-Plane CIoT EPS Optimization.

L’optimisation CP CIoT EPS Optimization propose de transmettre des données dans un message NAS entre l’UE et le MME. Sur l’interface radioélectrique, le message NAS est encapsulé dans un message RRC, lorsque le mobile est à l’état RRC_CONNECTED, c’est-à-dire à la suite de la procédure d’accès aléatoire. Dans l’optimisation CP CIoT EPS Optimization , la mise en sécurité AS n’est pas mise en œuvre, c’est-à-dire la connexion RRC n’est ni chiffrée, ni authentifié (intégrité).

L’optimisation UP CIoT EPS Optimization permet de transmettre des données entre l’UE et le MME lorsque le mobile est à l’état RRC_CONNECTED avec la mise en sécurité AS. Cela suppose que le contexte AS soit conservé au niveau du terminal UE et de la station de base. La R.13 propose une procédure de suspension/reprise de la connexion RRC lorsque le mobile passe de l’état RRC_CONNECTED à l’état RRC_IDLE.

Figure 2 : L’optimisation du coeur de réseau

Sur l’interface LTE, l’optimisation CIoT EPS Optimization permet de transporter les données sur la couche RRC. Le MME peut ensuite transférer les données vers le plan de transport SGW ou l’entité SCEF (Service Capability Exposure Function).

La R.14 introduit les spécifications à mettre en oeuvre pour le 5G MTC.

Figure 3 : Les améliorations proposées de la spécification R.10 à la R.14

La transmission EDT

Pour réduire la signalisation, la transmission EDT (Early Data Transmission [1]) propose de transmettre les données dans un message RRC au cours de la procédure d’accès aléatoire (RACH EDT). On distingue la transmission CP-EDT s’appuyant sur l’optimisation du plan de contrôle CP-EDT (sans chiffrement) de l’optimisation du plan utilisateur UP-EDT (avec chiffrement).

L’inconvénient de la procédure EDT est la transmission du message sur le canal de contrôle commun. Celle-ci est donc interférée par les demande d’accès aléatoire pouvant simultanément avoir lieu sur les mêmes bandes de fréquences.

La transmission UP-EDT est :

    • soit à l’initiative du terminal (Mobile Originated MO-EDT) spécifiée dans la R.15
    • soit à destination du terminal (Mobile Terminated MT-EDT) spécifiée dans la R.16.

La transmission EDT a été proposée dans la R.15 pour optimiser la transmission de messages courts lors de la procédure d’accès aléatoire. Au cours de cette procédure, le mobile reste à l’état RRC_IDLE sans contexte AS (CP EDT – Contol Plane EDT) ou en ayant conservé le contexte AS (UP EDT – User Plane EDT). A l’issue de la demande d’accès aléatoire, la transmission EDT étant finalisée, le mobile rester à l’état RRC_IDLE. Si d’autres données doivent être émises ou reçues, le terminal passe à l’état RRC_CONNECTED.

Dans ce cas, le premier paquet est transmis selon la procédure EDT, les autres paquets seront transmis de manière traditionnel.

La transmission PUR (Preconfigured Uplink Resource) consiste à pré-configurer les ressources du lien montant (UL) au cours d’une première connexion radioélectrique (RRC_CONNECTED). Cela signifie que la transmission PUR nécessite qu’en amont le terminal ait été dans l’état RRC_CONNECTED afin de recevoir la pré-configuration désirée.

La transmission PUR est utilisable par le terminal à l’état RRC_IDLE sans nécessité de procédure d’accès aléatoire mais en ayant conservé un contexte AS et l’allocation UL.

Ensuite, lorsque le mobile est en mode de veille, il peut utiliser les ressources qui lui sont réservées pour transmettre ses données sans avoir à mettre en œuvre la procédure d’accès aléatoire

Sur un cœur de réseau 5GC, la 3GPP propose un nouvel état radioélectrique du mobile nommé RRC_INACTIVE dédié aux terminaux IoT.

Le cœur de réseau 5GC pouvant être connecté à l’interface radioélectrique 4G E-UTRA et 5G-NR, l’état RRC_INACTVE s’appliquera à l’UE sur chacune des interfaces.

La transmission SDT (Small Data Transmission) est une procédure permettant de transmettre des petites quantités de données entre un terminal UE et le cœur de réseau 5GC en passant soit par l’accès radioélectrique 4G E-UTRA ou l’accès radioélectrique 5G-NR lorsque le terminal UE reste à l’état RRC_INACTIVE. La transmission SDT peut se faire sur l’interface E-UTRA comme sur l’interface 5G-NR.

La transmission non SDT correspond à la transmission traditionnelle de données entre un UE et le cœur de réseau 5GC via l’établissement de bearers lorsque l’UE est à l’état RRC_CONNECTED.

La transmission SDT sur l’interface 5G-NR a été introduite dans la spécification R.16 sous le nom NR SDT. La spécification R.17 propose deux technologies nommées RA-SDT (RACH SDT) et CG-SDT (Configured Grant SDT) lorsque le mobile est à l’état RRC_INACTIVE.

Figure 4 : Les types de transmissions IoT sur les réseaux 4G et 5G

[1] Andreas Höglund, Dung Pham Van, Tuomas Tirronen, Olof Liberg, Yutao Sui, and Emre A. Yavuz, “3GPP Release 15 Early Data Transmission”, 2018, IEEE Communications Standards Magazine ( Volume: 2, Issue: 2, JUNE 2018), p90-96, https://doi.org/10.1109/MCOMSTD.2018.1800002

Evolution de l’architecture du réseau 4G pour le M2M : AESE – Part 2

Posté le by - 2 028 vues
Répondre

(Suite de l’article précédent)

2) La procédure de déclenchement

La procédure de déclenchement a été proposée dans la recommandation technique de la release R.10 afin de permettre à un dispositif IoT de répondre à une sollicitation du portail client (SCS). La procédure de déclenchement de dispositif est normalisée dans la release R.11 et nécessite une première phase d’enregistrement de la part du serveur SCS auprès de l’entité SCEF ou MTC-IWF avec comme droit d’émettre des requêtes de réveil (Trigger Request). La phase d’enregistrement a pour but de créer un identifiant de transaction et les droits de requêtes formant ainsi une entrée dans la table de contexte de l’entité MTC-IWF/SCEF à laquelle se rajoute l’identifiant du ou des dispositifs à réveiller. Le dispositif peut s’identifier à partir de son numéro MSISDN, d’un identifiant externe sauvegardé sur le serveur MTC AAA de l’opérateur ou d’un identifiant de groupe.

Dans les spécifications 3GPP de la Release 11, l’entité SCS contacte l’entité MTC-IWF via une requête DIAMETER afin que ce dernier puisse réveiller le dispositif. Lorsque l’entité MTC-IWF reçoit une demande de réveil, il contacte d’abord la base de données HSS (ou le HLR) afin de convertir l’identité publique en une identité interne au réseau opérateur (identifiant IMSI). L’entité HSS/HLR peut éventuellement contacter un serveur d’authentification MTC-AAA pour convertir une identité externe en un numéro IMSI. Si l’identité de l’UE MTC est reconnue, l’entité MTC-IWF récupère les informations de souscription du afin de mettre en relation le portail client SCS avec le dispositif.

L’entité MTC-IWF définit la méthode de réveil la plus adéquate sur le plan de contrôle pour déclencher une mesure au niveau du dispositif à partir des informations suivantes :

  • Les informations actuelles d’accessibilités de l’UE (sur quel réseau l’UE est situé, et sur quel zone) ;
  • Les méthodes de déclenchement de service supporté par le réseau HPLMN ou VPLMN ;
  • Les méthodes de déclenchement supportées par l’UE ;
  • Les politiques de déclenchement de réveil de l’opérateur ;
  • Autres informations reçues de la part du serveur SCS dont potentiellement la localisation du dispositif si celle-ci est connue. La localisation permet d’optimiser le paging à la cellule et non à la zone de localisation TAI (Tracking Area Identifier).

Les méthodes de réveil possible sont :

  • MT SMS. L’UE doit pouvoir reconnaître dans le message un MT SMS provenant du SCS ;
  • Cell Broadcast : La procédure Cell Broadcast permet de réveiller un dispositif UE en émettant des informations sur les SIB portés par le canal balise ;
  • Signalisation NAS ;
  • Messages IMS.

De manière plus explicite, la figure 3 présente le call flow de la procédure de déclenchement. On suppose que le serveur SCS s’est préalablement enregistrée auprès de l’entité MTC-IWF et au cours de la procédure d’enregistrement, le portail client SCS a associé le dispositif UE à réveiller. L’entité SCS connait l’adresse IP de l’entité MTC-IWF, dans le cas contraire, le portail client SCS fait une requête DNS.

La demande de réveil est initialement déclenchée par une API provenant du serveur d’application Client vers l’entité SCS (non présente sur le call-flow). L’entité SCS transmet le message Request Device trigger à l’entité MTC-IWF (éventuellement après une requête DNS) dans la commande DIAMETER DAR (Device Action Request) à travers l’interface Tsp.

Le message DAR contient les informations suivantes (AVP) :

  • Le type de message : Device Trigger Request
  • Le MSISDN ou une identité externe correspondant à l’UE MTC à réveiller
  • L’identité du SCS qui émet la requête.
  • Un numéro de référence de la demande de requête de réveil
  • Les données de Trigger contenant données à transmettre à l’UE MTC lors de la demande de réveil comme :
  • Priorité du trigger
  • L’identification du port de l’application à exécuter au niveau du dispositif
  • Une durée de validité du message de réveil. Un temporisateur est déclenché au niveau du MTC-IWF qui reçoit le message DAR.

Figure 2. Call Flow d’un réveil de dispositif par SMS

L’entité MTC-IWF peut interdire ou autoriser la requête de réveil à partir de l’identité du serveur SCS si le serveur SCS n’est pas reconnu ou si le serveur SCS a dépassé le nombre de requêtes autorisées.

La durée de validité permettra à l’entité MTC-IWF de savoir si le dispositif sera joignable avant la fin du temporisateur. L’entité MTC-IWF aura besoin de connaitre la durée pendant laquelle le dispositif est soit à l’état dormant, soit en mode de veille avant la prochaine écoute de paging (Paging Occasion). Si le dispositif ne peut pas être réveillé pendant la durée de validité du message de réveil, alors l’entité MTC-IWF retourne un rapport d’erreur dans le message DAA.

L’entité MTC-IWF contacte l’entité HSS (éventuellement après une résolution HSS via la fonction de localisation SLF). A la réception de la requête DIAMETER SIR, l’entité HSS réalise les opérations suivantes :

  • Correspondance entre le numéro publique (MSISDN ou identité MTC externe) avec l’identité privée IMSI du dispositif ;
  • Récupère -si le dispositif est enregistré- le nœud de service actuel du dispositif (soit l’entité MME, l’entité SGSN, ou l’entité MSC) ;
  • Vérifie les droits de souscriptions du dispositif en correspondance avec l’identification du serveur SCS pour valider ou non la requête de réveil.

L’entité HSS répond à l’entité MTC-IWF par la requête SIA avec les éléments suivants :

  • Le nœud de service (MSC, SGSN, SGW) actuel du dispositif ;
  • Renvoie le statut du dispositif (UE State Information) permettant de savoir si le dispositif est à l’état connecté, de veille, ou non enregistré (absent). Cette information est apportée par le HSS ;
  • Le ou les mécanismes supportés par le dispositif (information apportée par le HSS) ;
  • Les capacités de services offertes par le réseau de l’opérateur Home (framework implémenté dans le MTC-IWF) et éventuellement par l’opérateur visité en cas de roaming ;
  • Autres informations transmises par le SCS (localisation du dispositif, demande de réveil groupé, …).

A partir des informations reçues, l’entité MTC-IWF sélectionne le mécanisme pour transmettre la requête de réveil au dispositif le plus efficace (SMS, Cell Broadcast, …) et génère un ticket de taxation.

L’entité MTC-IWF sélectionne la méthode SMS pour réveiller le dispositif. Il émet au serveur SMC-SC (SMS Service Center) la requête DTR.

Le message DTR contient :

  • le numéro IMSI du dispositif et éventuellement le MSISDN si le MTC-IWF le connait (si le SCS a donné l’identité MSISDN au MTC-IWF et non un identifiant MTC externe) ;
  • l’identité de l’entité SCS ;
  • l’identité du nœud de service (SGSN, MSC ou MME) si connu ;
  • le statut du dispositif ;
  • le numéro de référence de la demande de requête de réveil ;
  • la durée de validité du message de réveil ;
  • la Priorité du trigger ;
  • l’identification du port d’application du SMS.

Une fois le message DTR reçu, si le dispositif est joignable le centre de service SMS (SMS-SC) n’a pas besoin de contacter l’entité HSS. Il doit néanmoins :

  • vérifier l’identité du dispositif (IMSI ou MSISDN). Si l’UE n’est pas reconnu (DIAMETER_ERROR_USER_UNKNOWN) ;
  • vérifier l’identité du SCS. Si l’identité du SCS n’est pas reconnu (DIAMETER_ERROR_INVALID_SME_ADDRESS) ;
  • Router l’information vers le nœud de service (SGSN, MSC ou MME). Il renvoie alors l’information DIAMETER_SUCCESS à l’entité MTC-IWF.

Si le dispositif est non enregistré (absent), le centre SMS-SC va stocker le message et envoyer une notification à l’entité HSS (SM Message Delivery Status Report) afin que l’entité HSS rajoute l’adresse du centre SMS-SC dans la liste des messages d’attentes. Ainsi, lorsque le terminal MTC UE fera une demande d’attachement, il prendra connaissance du trigger.

Le centre SMS-SC renvoi le résultat de la demande DTR dans le message DTA. Le code de résultat AVP indique si la requête est acceptée (SUCCESS) ou refusée (FAILURE) avec le code d’erreur correspondant :

  • congestion du SMS-SC ;
  • adresse SME non valide ;
  • erreur de protocole SM.

A ce stade, l’entité MCT-IWF acquitte le message DAR par la réponse DAA, ce qui confirme que la demande de réveil a bien été transmise au SMS-SC.

Le message DAA contient :

  • le numéro de référence de la demande de requête de réveil ;
  • l’état du statut de la requête de réveil.

Si la requête est acceptée, le centre SMS-SC envoie le SMS vers le MTC UE et attend la notification de SMS. Cette notification est transférée du SMS-SC vers l’entité MTC-IWF dans le message DIAMETER DRR (Delivery Report Request) et l’entité MTC-IWF répondra au SMS-SC par la réponse DRA (Delivery Report Answer).

Le message DRR transmet le rapport de succès ou d’échec de transfert su Trigger par SMS, il contient les informations suivantes :

  • l’identité IMSI de l’UE et éventuellement le MSISDN ;
  • l’identité du SCS ;
  • le résultat de la requête :
  • Client Absent
  • Mémoire de l’UE remplie
  • Transfert réussi.

L’entité MTC IWF informe l’entité SCS de la réception du SMS de la part de l’UE. L’entité MTC-IWF envoie le message DIAMETER DNR (Device Notification Request) au serveur SCS et attend la réponse DNA (Device Notification Accept)

Le DNR contient les informations suivantes :

  • le MSISDN ou l’identité externe du dispositif ;
  • l’identité du SCS qui a fait la demande de réveil ;
  • le numéro de référence de la demande de requête de réveil ;
  • la réponse à la demande de réveil.

L’entité SCS acquitte la réception de cette requête en répondant par le message DIAMETER DNA.

Enfin, l’entité MTC-IWF répond à la requête DRR émis par le SMS-SC par la réponse DRA, informant ainsi le SMS-SC d’un succès ou d’une erreur sur l’interface T4.

Evolution de l’architecture du réseau 4G pour le M2M : AESE

Posté le by - 3 281 vues
1

1) Le cœur réseau 4G/EPC pour les communications machines MTC (Machine Type Communication)

En s’appuyant sur la spécification de l’ETSI, l’organisation 3GPP propose au niveau du cœur réseau EPC une nouvelle entité nommée SCEF (Service Capability Exposure Function) ou MTC-IWF (InterWorking Function). L’entité SCEF est connectée au portail client (SCS – Service Capacity Server) par une interface API proposée par l’opérateur (interface T8) alors que l’entité MTC-IWF est connectée au portail client par le protocole DIAMETER. L’architecture évolue particulièrement autour du SCEF (AESE Architecture Enhancement for Service capability Exposure).

Figure 1 : Les entités et les interfaces liées au MTC-IWF et SCEF en R.13 et R.14

L’entité SCEF supporte la demande d’échange de données entre le serveur et les terminaux IoT mais elle supporte en plus la supervision d’événements même en cas d’itinérance (roaming).

Les rôles de l’entité SCEF sont :

  • Authentification et l’autorisation d’une requête du SCS ;
    • Identification du SCS ;
    • Gestion des listes d’accès (ACL : Access Control list);
  • Gère les frameworks pour apporter des capacités du service du réseau 3GPP au SCS ;
  • Masque le réseau opérateur ;
  • Configure les événements à surveiller et récupère les événements ;
  • Gère les politiques de priorité et de capacité du réseau opérateur (évite la saturation des nœuds de service) ;
  • Génère des compte-rendu d’appels (CDR) pour la taxation.

En cas d’itinérance, l’entité SCEF du réseau home possède une interface avec l’entité IWK-SCEF (InterWorKing SCEF) du réseau visité.

L’entité IWK-SCEF est optionnelle. Elle est située dans le réseau visité pour dialoguer avec l’entité SCEF du réseau Home via l’interface T7. L’entité IWK-SCEF relaie les données non IP entre l’entité MME et l’entité SCEF. Si le réseau visité ne déploie par d’entité IWK-SCEF alors le dispositif devra établir une connexion PDN avec le routeur de passerelle PGW pour pouvoir transmettre ou recevoir des données.

L’entité MME évolue pour pouvoir gérer de façon efficace la création de tunnel entre le terminal et le serveur d’application. Le tunnel est créé soit sur le plan utilisateur (eNB/SGW/PGW), soit sur le plan de contrôle (eNB/MME) suivant l’évolution du réseau opérateur (User Plane EPS evolution et/ou Control Plane EPS evolution)

La formation SE26 présente en détail l’évolution du réseau pour les communication machines, le rôle des entités, les interfaces et les procédures permettant :

  • l’attachement du terminal avec l’optimisation sans PDN ;
  • l’établissement et le rétablissement des supports ;
  • la supervision d’évènements ;
  • la procédure de déclenchement (Trigger device) ;
  • la transmission NIDD (Non IP Data Delivery) ;
  • la transmission de messages en unicast ou en groupes.

 

Architecture du réseau M2M

Posté le by - 2 530 vues
Répondre

Cet article est la suite des deux précédents :

  1. http://blogs.univ-poitiers.fr/f-launay/2019/02/15/iot-blockchain-ia-machine-learning-des-technologies-disruptives/
  2. http://blogs.univ-poitiers.fr/f-launay/2019/03/18/iot-bigdata-ia-un-monde-100-connecte-pour-les-systemes-cyber-physique-cps/
  • Architecture du réseau M2M

L’architecture générique du réseau M2M a été spécifiée par l’institut ETSI qui a défini les fonctions de bases pour pouvoir échanger des données entre un objet et un serveur. Cette architecture s’appuie sur un ensemble de fonctionnalités logicielles déployées dans un framework.

Le but du framework est de décrire les services qui permettent de gérer l’objet : enregistrement, authentification, récupération des données de manière périodique ou par une méthode de réveil, accessibilité de l’objet, localisation, type de réseau supporté, … Les applications sont réunies dans une bibliothèque logicielle générique prenant en charge l’objet quel que soit le réseau de connectivité, auxquelles se rajoutent des applications spécifiques permettant de gérer les caractéristiques de chaque réseau de connectivité. On parle de Capacité du réseau (ou service capabilities), les fonctionnalités proposées par le réseau d’accès et gérées par le framework.

L’architecture du réseau M2M se décompose en trois parties :

  • Le domaine d’application ;
  • Le domaine des réseaux ;
  • Le domaine des dispositifs ;

Figure 1. L’architecture fonctionnelle du M2M

Le domaine des dispositifs est composé des éléments suivants :

Le domaine des réseaux gère la connectivité de l’objet. Cela suppose l’enregistrement de l’objet, la gestion du plan de transport (établissement d’un tunnel pour la Data),  la gestion de la mobilité, la gestion de la qualité de service et la facturation. Le domaine des réseaux se découpent en trois parties :

  • Réseau d’accès : Il s’agit d’une connexion soit en tout IP via un support en cuivre, un support optique, un lien cellulaire (GPRS, 4G, WiMax), lien satellitaire ou d’une connexion non IP via le réseau GSM ;
  • Cœur réseau : Il fournit les fonctions comme la connectivité (IP ou SMS), les fonctions de contrôle du réseau (qualité de service) et l’autorisation du service demandé ;
  • Les capacités de Service (M2M Service Capabilities). Il fournit les fonctions M2M qui sont offertes aux serveurs d’applications client via des interfaces ouvertes (API) en s’appuyant sur les fonctionnalités du cœur réseau à travers les interfaces normalisées (Gx,Gi) ;

Le domaine d’application est composé :

  • D’un serveur d’application client (AS)
  • D’un portail client qui fournit des fonctionnalités au client.

La première fonctionnalité du portail client consiste à inscrire l’objet  via une interface https. L’étape de provisioning consiste à enregistrer le n-uplet identifiant(s) dispositif(s), clé(s) privée(s) et identifiant(s) applicatif(s)  dans le cœur réseau de l’opérateur. Cette étape est partiellement réalisée par l’opérateur pour le réseau cellulaire et entièrement réalisée par le client dans le cas du réseau LoRa.

Les autres fonctionnalités sont proposées au client par une interface API permettant au client d’accéder à un serveur de données dont le rôle est de stocker les informations fournies par l’objet ou par le réseau. En général le client se connecte via le protocole http (API REST), ou un protocole plus léger comme le protocole MQTT, XAP, XMPP ou COAP. La demande d’accès est contrôlée par un jeton d’authentification (Token) transmis au moment de la requête http. Le client doit donc activer un compte auprès de l’opérateur (lors de la première étape) pour utiliser une ou plusieurs API. Chaque API est associée à un jeton (comme par exemple, l’identifiant APPEUI pour LoRa).

Au niveau du portail client, l’opérateur dispose en plus :

  • d’outils de supervision du réseau et des sauvegardes de logs ;
  • des bases de données contenant les informations de souscriptions de chaque client : identité et clé privée de chaque objet pouvant s’enregistrer sur le réseau ainsi que les règles à appliquer pour chaque objet et les droits (les jetons d’authentification) ;
  • d’un serveur de facturation et de gestion de la politique des droits;