Double Connectivité (DC – Dual Connectivity) 4G/5G

Posté le by - 840 vues
Répondre

La 5G arrivera en Juillet 2020, le déploiement sera un déploiement au niveau de la couche radio. Comment la 5G sera déployée? Quels services va t’elle apporter? Quelles performances? Comment la station de base 5G (gNB) sera controlée? Peut on parler de 5G si le coeur réseau est 4G?

Ces réponses seront apportées dans une série d’articles, et voici le premier article d’une longue série sur la double connectivité.

Introduction

La double connectivité implique la présence de deux stations de base pour apporter des ressources radio-électrique vers un terminal mais un seul point de terminaison de signalisation vers le coeur réseau. Dans une première phase, le coeur de réseau est le coeur de réseau 4G (EPC), le point de terminaison est donc l’interface S1-MME.

La double connexion implique soit deux stations de bases LTE (se référer à l’article suivant) soit une station de base NR et une station de base LTE (Multi-Radio DC – MR-DC aussi nommé NR-DC).

Chaque nœud radio contient plusieurs cellules (une cellule pour une antenne omni-directionnelle, trois cellules, 6 cellules pour des antennes multi-sectorielles, …), et chaque nœud gère plusieurs porteuses LTE ou NR (agrégation de porteuses).

La double connexion implique donc la gestion de groupe de cellules (GC : Group Cell) pour chaque nœud radio. L’objectif d’un groupe de cellules est de gérer les données sur une ou plusieurs porteuses pour augmenter le débit. Dans un groupe de cellules (GC), on identifie la cellule principale (SpCell) qui est en charge de contrôler toutes les cellules du groupe et optionnellement une ou plusieurs cellules secondaires (SCell).

La double connectivité définie la notion de support MCG (Master Cell Group) et SCG (Secondary Cell Group bearer). Le support MCG est géré par la station de base maitresse, le support SCG correspond aux supports de la station de base secondaire. La double connexion permet de modifier la terminaison du plan de transport (U-plane termination) vers le support MCG ou SCG via la signalisation S1-MME sans modifier le point de terminaison du nœud de contrôle S1-MME (la signalisation est toujours définie entre le cœur de réseau et la station de base maîtresse).

Ainsi, si on appelle MCG le groupe de cellule maître et SCG le groupe de cellules secondaires, le MSG et le SCG peuvent avoit un SpCELL et des SCELL.

La fonctionnalité Double Connectivité (Dual Connectivity DC) a initialement été spécifiée sur le réseau de mobiles 4G entre deux stations de bases eNB différentes (sur des porteuses différentes) avec l’objectif d’augmenter le débit ressenti par l’utilisateur en agrégeant des flux des deux eNB en dépit de la latence provoquée par le lien X2 (backhaul). Cela constitue une différence avec l’agrégation de porteuses ou l’agrégation des flux est réalisée sur la même station de base dans deux bandes radios différentes. Dans le cas de la double connexion, les stations de base n’ont pas besoin d’être synchronisées (et peuvent donc être non co-localisées).

Figure 1 : Agrégation de porteuses et Double Connexion

L’interface X2 est une interface physique, généralement en Fibre Optique. L’interface X2 peut être séparée en deux interfaces, l’interface X2-U pour l’échange de données du plan utilisateur entre la station de base maîtresse et secondaire (handover, double connexion), et l’interface X2-C permettant l’échange des informations de contrôle entre les deux stations de base.

La pile protocolaire pour le plan de transport sur l’interface X2-U utilise les couches protocolaires GTP-U, UDP, IP et la couche de niveau 2

  1. La double connectivité DC 4G-4G (se référer à l’article DC 4G/4G)

L’option DC 4G-4G a déjà été présentée dans un article précédent, on différencie le plan de contrôle et le plan de trafic. L’une des deux stations de base est responsable de la signalisation avec le cœur réseau et le terminal. Les supports (nommés bearer) de signalisation correspondent aux bearer SRB1 et SRB2 entre le terminal Ue et la station de base maîtresse (MeNB). La station de base secondaire est responsable de la connexion de données additionnelles sur le lien radio (DRB) et vers le cœur réseau.

Plan de contrôle :  La station de base maîtresse (MeNB) établie la connexion RRC avec le terminal UE et la connexion radio avec l’entité SeNB (Secondary eNB) est contrôlée par la station de base maîtresse.

Plan utilisateur : Deux options sont supportées pour la DC 4G-4G :

  • Option 1A : Le cœur de réseau établit deux supports (bearer) avec chacun des entités eNB ;
  • Option 3C : Le support est séparé par l’entité MeNB : Split Bearer

Figure 2 : Pile protocolaire DC 4G-4G

Le terminal UE ne dispose que d’une seule entité RRC.

Dans le cas de la double connexion 4G-4G, les deux options retenues parmi toutes les options possibles sont l’architecture 1A et 3C.

Pour l’option 1A, la séparation des flux est gérée au niveau du cœur réseau (SGW).

Pour l’option 3C, la séparation des données est basée sur le routage de support de données PDCP.

Figure 3 : Double Connexion 4G-4G

  1. DC 4G-5G : Déploiement NSA

Le mode de déploiement de la 5G s’appuiera en 2020 sur une double connectivité 4G-5G (mode NSA – Non Standalone Architecture). L’opérateur conserve le cœur de réseau 4G (EPC), la signalisation entre l’accès radio et le cœur de réseau est réalisée par l’entité eNB. On parle d’option 3

Remarque : si le cœur de réseau était 5G on parlerait alors d’option 7, tout chose égale par ailleurs.

Pour l’option 3, le terminal UE est sous le contrôle de la station de base 4G et lors de la demande de connexion radio avec la station de base eNB (LTE PCell), le terminal va être configuré pour monter un support radio NR avec la station de base gNB (dénommée en-gNb : E-UTRAN – NR gNB pour rappeler le mode DC).

Plan de contrôle : Sur l’interface radio, le terminal UE est contrôlé par l’entité eNB et en-gNB (par des messages RRC). La signalisation (CP : Control Plane) est échangée entre les deux stations de base via le lien backhaul X2.

L’application X2AP réalise plusieurs fonctions comme le rappelle la figure 4 :

Figure 4 : les fonctions supportées par l’application X2AP

Plan Utilisateur : Le terminal UE peut être connecté simultanément sur l’entité eNB et en-gNB pour le plan utilisateur ou uniquement avec l’entité en-gNB.

La fonction DC 4G-5G option 3 se décline en trois sous options (figure 4) en séparant le support au niveau de l’accès radio (split bearer) ou en créant un support au niveau du cœur de réseau (MCG ou SCG) :

  • option 3 : La séparation du support (split bearer) est réalisée par l’entité MeNB. Le trafic (UP : User Plane) est transmis à travers le lien X2 vers l’entité SgNB (Slave en-gNB) ;
  • option 3a : La création d’un bearer secondaire (SGC) s’effectue au niveau du cœur réseau (SGW) et le flux de données est transmis sur deux supports (bearer) complémentaires, l’un vers l’entité MeNB, l’autre vers l’entité SgNB ;
  • option 3x : La création d’un bearer est réalisée au niveau du cœur radio (SCG) et la séparation du bearer est réalisée par la station de base secondaire (SCG split bearer).

Figure 5 : Les options 3/7 vert à gauche, 3a/7a (en bleu), 3x/7x vert à droite du mode NSA

L’option 3x consiste à séparer le support DC au niveau de la station de base gNB. L’entité eNB peut conserver un ou plusieurs bearer avec le cœur de réseau (MCG bearer) ou ne gérer que la signalisation entre l’accès radio (eNB/en-gNb) et le cœur de réseau.

Dans le cas du split-bearer, les données sont distribuées ou dupliquées entre les deux nœuds radios. L’équilibrage de charge est réalisé de manière dynamique par le nœud d’ancrage (MeNB ou SgNB) en fonction du trafic, c’est-à-dire par l’entité PDCP du nœud d’ancrage (MeNB pour l’option 3 et SgNB pour l’option 3x).

Dans la suite, on appellera indifférent SgNb ou en-gNB.

L’interface radio-électrique LTE-M : 2ème article

Posté le by - 651 vues
Répondre

Afin de réduire la signalisation, la procédure de mise à jour périodique de la localisation a été étendue et une nouvelle procédure de connexion radio a été proposée.

La procédure PTAU (Periodic Tracking Area Update) est périodiquement exécutée par un dispositif pour notifier auprès de l’entité MME de sa joignabilité sur le réseau d’accès radio 3GPP. Cette procédure est réalisée à l’expiration du Timer T.3412 lequel est ré-initialisé à chaque message NAS. Sa valeur par défaut est de 54 mn : la valeur du Timer T.3412 est transmise par le cœur réseau vers le mobile UE au cours de la procédure d’attachement ou lors de la mise à jour de la localisation en cas de changement d’indicateur de zone de tracking TAI.

Pour réduire ce message de signalisation, l’organisme de normalisation 3GPP propose d’étendre la temporisation périodique de localisation en augmentant la valeur du timer T.3412 (timer étendu).

Lorsque le terminal demande une connexion radio, la station de base eNB réalise une mise en sécurité des commandes NAS et une mise en sécurité de la transmission de données en échangeant. Ce contexte de mise en sécurité AS (Access Stratum) est sauvegardé au niveau du terminal UE et de la station de base eNB. L’établissement de ce lien permet au terminal de passer de l’état de veille à l’état connecté.

Pour éviter l’échange d’information AS chaque fois que le mobile souhaite passer du mode de veille au mode connecté, deux nouvelles requêtes RRC ont été introduites. Ces requêtes permettent de suspendre le lien radio et de passer en mode de veille tout en conservant le contexte AS au niveau du terminal et de la station de base. On dit alors que le terminal est à l’état Inactif (Inactive State) : Après une période d’inactivité, le terminal suspend sa transmission par le message RRC Suspend. La station de base eNB suspend alors la communication en relâchant le lien radio avec le terminal mais en conservant le contexte du terminal.

Le lien radio sera rétabli à l’initiative de la station de base (par une notification de paging) ou à l’initiative du terminal via la requête RRC Resume.

IV-1-c) La durée de vie de la batterie

Les terminaux IoT doivent pouvoir être connectés au cœur réseau sans la moindre recharge pendant plusieurs années. Cette autonomie s’obtient en apportant plusieurs mécanismes complémentaires au terminal comme le mode PSM (Power Saving Mode) défini dans la Release R.12 et l’évolution du DRX définie dans la Release R.13 (eDRX). Ces deux modes définissent une durée pendant laquelle le terminal éteint son interface radio dans le but de prolonger la durée de vie de sa batterie.

IV-2) L’interface radio LTE-M

Le réseau d’accès LTE-M hérite des canaux physiques du LTE-M. La bande totale du réseau LTE est divisée en bande étroite occupant chacune 6 PRB (soit 1.4 MHz) comme le montre la figure 3.

Figure 3 : La division de la bande LTE de 10 MHz en sous bandes étroites LTE-M de 1.4 MHz

Le nombre de sous bandes étroites dépendent de la bande LTE sur laquelle le réseau LTE-M s ‘adosse :

Table 1: La configuration des bandes étroites LTE-M

A l’instar de tous terminaux LTE, le terminal IoT écoute le centre de la bande du réseau d’accès LTE afin de récupérer les signaux de synchronisations et le message MIB transmis dans le canal de diffusion (PBCH)

Pour les terminaux IoT, les informations MIB sont transportées sur le canal physique MPBCH avec une périodicité de 10 ms. Un nouveau MIB est transmis toutes les 40 ms et par conséquent chaque MIB est répété 4 fois. Le nombre de répétitions peut être augmenté afin d’améliorer la couverture du canal MPBCH. Le nombre de répétitions est connu par le terminal via le paramètre CATMPR:mibRepEnabledCatM.

Figure 5 : La répétition du MPBCH

La station de base LTE-M transmet en plus des informations de signalisation SIB, lesquelles sont indiquées par le canal de diffusion MPBCH. Les informations SIB1-BR permet d’informer le terminal IoT du numéro de bande étroite exploité sur la bande LTE pour des communications sur le réseau d’accès LTE-M. Ainsi, en reprenant comme exemple le tableau 11.2, les communications sur l’accès radio LTE-M peuvent utiliser les 3 premières sous-bandes (NB1 à NB3) ou les trois dernières sous-bandes NB6 à NB8 : SIB1-BR indique les sous-bandes valides du lien descendant, et exclue automatiquement les 72 sous-porteuses centrales.

L’information DCI portée par le canal MPDCCH permet de transmettre :

  • les informations de séquencement DL (DCI Format 6-1A/6-1B dans le mode CE A/B ;
  • les commandes de contrôle de puissance du lien montant (DCI Format 3/3A) ;
  • les informations d’allocation de ressource pour le lien montant (DCI Format 6-0A/6-0B pour les modes CE A/B) ;
  • un indicateur de paging ou une mise à jour des informations de SI (DCI Format 6-2).

Les terminaux de catégorie CAT-M1 répondent aux spécifications proposées par le réseau d’accès LTE-M et les évolutions du cœur réseau.

  • Conclusion

Le marché du Wireless IoT est très concurrentiel : les opérateurs Orange et Bouygues ont déployé la solution LoRa pour ne pas laisser aux opérateurs Sigfox ou QoWiSio le marché du M2M en France. Orange a récemment ouvert un deuxième réseau d’objet connecté via l’accès radio 4G/LTE-M. Cela permet de répondre à des cas d’usage différents puisque le réseau d’accès LTE-M permet :

  • des débits de transmission plus important ;
  • des appels téléphonique via le mécanisme VoLTE ;
  • des accords de roaming avec les opérateurs pour le trafic
  • des accords de roaming avec les opérateurs ayant déployé l’entité d’interfonctionnement IWK-SCEF pour les notifications

Les solutions LoRa propose des accords de roaming entre opérateurs (LoRAWAN 1.1) cependant, le dispositif doit pouvoir se caler sur le plan de fréquence du pays visité. Cette solution a été mise en œuvre par Sigfox par le mécanisme MONARCH.

L’opérateur SFR est aussi présent sur le marché via un accord commercial avec SIGFOX mais SFR ouvre le réseau d’accès NB-IoT.

Ces informations ont été recueillies à partir de la formation SE26 de la société NEXCOM Systems (https://www.nexcom.fr/formation/comprendre-le-deploiement-de-la-4g-m2m-lte-m-mtc-pour-liot/). Cette formation présente les évolutions de l’interface radio et les canaux logiques/physiques, notamment les impacts sur les canaux physiques (MPBCH, MPRACH, MPDCCH/MPUCCH, MPDSCH/MPUSCH) et de synchronisation (PSS, SSS). Vous pouvez contacter formation@nexcom.fr pour obtenir des informations sur le contenu des formations qu’ils proposent, en indiquant que vous avez découvert leur formation à travers ce blog.

L’interface radio LTE-M – 1er article

Posté le by - 609 vues
2

L’accès radio LTE a initialement été conçu pour optimiser les communications à haut débit (MBB : Mobile BroadBand, mobiles larges bandes) en prenant en compte une mobilité élevée et une latence faible pour le transport des données (10 ms). Les exigences en termes de performances 4G sont encore mesurées à ce jour par le débit maximum et la réduction de la latence sur le plan de transport (UP : User Plane).

Le marché de l’Internet des Objets a longtemps été supporté par le réseau GPRS. Cela s’explique par le faible coût des modems GPRS comparé aux modems 4G. Toutefois, les performances de l’accès radio LTE sont attractives :

  • meilleure efficacité spectrale ;
  • disponibilité de l’interface radio pour du long terme ;
  • couverture globale.

De par ses atouts, une optimisation du lien radio LTE et du cœur réseau (MTC : Machine Type Communication) sont mises en œuvre pour répondre aux spécificités du marché de l’IoT.

Les optimisations portent sur :

  • le contrôle de la congestion et la maximisation de la capacité de la cellule ;
  • la réduction de la signalisation 4G ;
  • l’augmentation de la durée de vie de la batterie ;
  • l’augmentation de la Couverture.

De surcroît, pour devenir compétitif sur le marché de l’IoT, une réduction importante du prix des modems LTE est nécessaire. Dans la Release R.13, l’organisme 3GPP propose une simplification des terminaux en définissant deux nouvelles catégories de terminaux sous l’appellation cat-M1 et cat-NB1.

IV-1) Les améliorations sur l’interface radio

Le réseau d’accès doit pouvoir supporter un très grand nombre de terminaux (mMTC massive MTC) tout en conservant une QoS (Quality Of Service) pour les communications humaines. Pour répondre à cet impératif :

  • des procédures de contrôle de congestion et le paramétrage d’objets tolérants au délai permet d’optimiser le fonctionnement du réseau tout en différenciant la requête de service émise par le terminal UE ;
  • des procédures de réduction de la signalisation permet d’optimiser le plan de signalisation.

De plus, les terminaux IoT doivent obligatoirement avoir une autonomie de plusieurs années, ce qui nécessite de mettre en œuvre des mécanismes de gestion d’énergie (DRX – Discontinuous Reception et PSM – Power Saving Mode) en contrepartie d’une latence élevée (HL Com High Latency Communication).

IV-1-a) Le contrôle de la congestion

La saturation du réseau peut se produire :

  • Au niveau de l’interface radio lorsque de nombreux terminaux se connectent ou tentent de se connecter simultanément vers la même station de base eNB ;
  • Au niveau du cœur réseau EPC (Evolved Packet Network) : la congestion peut se produire au niveau de l’entité MME pour la signalisation ou au niveau des entités SGW/PGW pour le trafic. L’entité MME peut être fortement sollicitée lorsque le nombre de terminaux établissant une communication NAS est élevé. Pour réduire sa charge, l’entité MME contrôle principalement la congestion avec les entités eNB.

Pour gérer de manière sélective la congestion sur l’interface radio, la Release R.10 introduit un indicateur de faible priorité (LAPI : Low Access Priority Indicator) destiné aux terminaux IoT. Cet indicateur est implémenté dans les dispositifs soit au cours de leur fabrication, soit lors du provisionnement via l’interface radio par le mécanisme OTA (Over The Air). Lorsque le terminal fait sa demande de connexion radio, il transmet au cours de la requête RRC_Connection_Request la cause de sa demande (delay tolerant). En cas de saturation de la station de base eNB, celle-ci rejette la demande de connexion en demandant au terminal, dans le message RRC_Connexion_Reject, d’attendre jusqu’à 30 mn avant de refaire une nouvelle demande de connexion radio (Extended Wait Time).

Dans la Release 11 l’entité eNB contrôle la congestion via l’interface LTE-Uu en diffusant un message d’information SIB 14.

Le message diffusé par le SIB14 transporte une information de restriction de cellule (EAB : Extended Access Barring). Ce message est destiné à interdire aux terminaux de faible latence (LAPI) toute demande de requête de service. Afin de prendre connaissance de la modification du SIB14, les terminaux configurés avec l’identifiant LAPI reçoivent une notification par la procédure de paging les informant d’écouter le message d’information SIB14 diffusé par la station de base eNB. La procédure EAB ne concerne donc qu’une partie des terminaux.

Ce nouveau mécanisme offre deux avantages : Le premier avantage est la réduction de la signalisation au niveau de la station de base eNB, le deuxième avantage est une réduction de la puissance consommée par le mobile UE.

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

Posté le by - 458 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 - 541 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 - 615 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;

IoT, BigData, IA : Un monde 100% connecté pour les systèmes cyber-physique (CPS)

Posté le by - 866 vues
Répondre

Dans le précédent article, j’ai évoqué différentes technologies complémentaires, sans illustrer par des exemples concrets les applications attendues. Je vais présenter dans cet article la notion de système cyber-physique (CPS : Cyber Physical System).

Un système cyber-physique est un système bouclé qui intégre la remonté d’informations issues de capteurs physiques via des réseaux de connectivités vers un serveur de décision lequel par une boucle de rétroaction contrôle les processus physique.

(image issue du site suivant : https://smart-industries.fr/fr/challenges-et-opportunites-des-systemes-cyber-physiques)

Le serveur décisionnel permet de superviser les processus physiques, les commander et de faire de la détection de fautes afin de planifier une réparation avant l’apparition de défaut. On parle alors de reconfiguration ou de ré-organisation dynamique.

Un système de production CPPS (Cyber Physical Production System) concernent la coopération entre sous-systèmes autonomes afin de reconfigurer dynamiquement une chaîne de production. A titre d’exemple, une chaîne de fabrication est caractérisée par un ensemble de flux comme :

  • une prévision à la demande (flux poussée : on planifie les ressources dont on aura besoin lors de la conception d’un produit) ;
  • une prévision en temps réel (flux tirés : on commande à la demande pour satisfaire le besoin);
  • une prévision au plus juste de la demande (flux tendus)

L’objectif est donc de mesurer en temps réel le stock existant, de prévoir la commande en prenant en compte les délais d’approvisionnement et en fonction de la demande du produit, de reconfigurer la chaîne de production à la volée en cas de défaut d’un élément afin de maintenir l’activité de la chaîne de production. A cela, le système CPSS vise à prendre en compte d’autres paramètres comme :

  • le coût fluctuant de la matière première
  • le coût de l’énergie ou l’équilibrage de la consommation/production d’électricité

afin de réduire le coût énergétique (énergie verte).

C’est dans cette vision d’optimisation de la logistique, de la consommation énergétique que s’inscrit l’industrie 4.0 (e-usine ou smart-factory : les usines intelligentes).

Un autre exemple est le chargement/déchargement de cargo. Aujourd’hui, les opérateurs déploient des solutions de tracker sur les conteneurs. Ces solutions doivent fonctionner tout autour de la terre, ainsi on peut citer comme technologies qui nous intéressent ici le réseau d’accès LTE-M et NB-IoT. Ce dernier est plus adapté pour de faible quantité d’information. En dehors du blog, on peut aussi citer l’exemple MONARCH de Sigfox qui permet de réaliser le roaming vers les pays qui sont couverts par cet opérateur.

Rajoutons maintenant une connectivité sur les grues et les véhicules guidés (AGV : Automatic Guided Vehicule) et revenons à notre exemple : les ports de futur.

On peut ainsi imaginer une communication entre les grues, les véhicules, les conteneurs, et un serveur centralisé (fog) qui orchestre toute la logistique permet ainsi de réduire la durée d’attente de chargement ou déchargement.

Le déploiement d’antennes 4G et 5G à l’intérieur des entreprises (exemple de DAS : Distributed Antenna System) permettront de commander automatiquement les chariots élévateurs en fonction de toutes les informations recueillies et traitées (Big Data) comme les produits finis, les stocks en cours, …

A moins que … ce soient les machines qui commandent les hommes?

https://www.francetvinfo.fr/economie/emploi/video-cash-investigation-travail-vis-ma-vie-de-manutentionnaire-chez-lidl_2381539.html

Il faudra que je pense à écrire un article sur : Faut il avoir peur des nouvelles technologies?

IoT, Blockchain, IA, machine learning : Des technologies disruptives?

Posté le by - 2 005 vues
2

Les évolutions technologiques récentes vont apporter des changements profonds dans les domaines de la santé, de la logistique, le transport, l’énergie, l’agriculture, …

Si le déploiement de l’IoT (Internet of Things) destiné à collecter un ensemble d’informations constitue la première brique de cette évolution, la plus-value de cette transversalité numérique ne peut être obtenue qu’en garantissant la sécurisation des données collectées et le traitement efficace de ces données.

En cela, la technologie Blockchain s’insère dans l’écosystème de l’IoT en apportant un stockage des données, en assurant le transport sécurisé des données échangées et en permettant la traçabilité des données.

Quant aux traitements des données, l’intelligence artificielle (IA) permet de les valoriser et de les traduire en informations exploitables facilitant ainsi l’analyse décisionnelle des systèmes complexes. De surcroît, les méthodes d’apprentissages autonomes (Machine Learning) permettent également de classifier les données et d’apporter des outils de prédictions des pannes.

Les applications IA pourraient être mise en œuvre sur des lames de serveurs au plus proches des données collectées (MEC : Mobile Edge Computing).

Ainsi, les secteurs de la santé (capteurs et IA pour détecter l’évolution des maladies), du transport (véhicules autonomes), des chaînes d’approvisionnement (réparation des chaînes de production avant la cassure des pièces usées, l’approvisionnement en flux tendus), de l’énergie (délestages des sites industriels en assurant un transport de l’énergie au plus proche) seront impactés par la complémentarité de ces technologies disruptives.

Dans ces écosystèmes de plus en plus complexes, la donnée reste l’élément fondamental et le premier maillon d’une nouvelle ère économique. Les cabinets d’analystes estiment une évolution constante du marché des capteurs de l’IoT pour atteindre une centaine de milliards de dollars d’ici 2023 et une croissance du taux actuariel (CAGR – Compound annual growth rate) de 13%.

SigFox est le premier opérateur à s’être positionné sur le marché de la transmission sans fil des données issues des capteurs en déployant le réseau de transmission longue portée à basse consommation (LPWAN : LoW Power WAN).  Ce réseau LPWAN répond à la demande des compteurs intelligents (smart-meters, compteur d’eau, compteur de gaz), à la gestion des villes (smart-city) pour lesquels la communication est à latence élevée.

Aujourd’hui, l’opérateur Télécom SigFox est concurrencé par l’opérateur QoWiSio, l’opérateur Américain Ingénu, et l’alliance LoRaWAN avec le déploiement de LoRa par les opérateurs télécoms historiques.

Le réseau cellulaire 4G se positionne également sur ce secteur en étendant ses fonctionnalités pour répondre à l’émergence du marché de l’Internet des Objets. Ce réseau dédié aux communications Machine à Machine (MTC – Machine Type Communication) est destiné à devenir le premier réseau cellulaire LPWAN (Low Power WAN). Le premier avantage est de pouvoir rapidement apporter une couverture mondiale avec optionnellement une qualité de service.

L’IoT cellulaire (par son réseau d’accès NB-IoT, LTE-M et prochainement 5G NR) devrait connaître la plus forte croissance avec en point de mire, entre 10 000 et 100 000 objets connectés sous la couverture d’une seule station de base. Orange a ouvert son réseau LTE-M en novembre 2018, comme annoncé dans un précédent article traitant du cellular IoT.

Le réseau 5G quant à lui va permettre d’apporter de nouvelles solutions pour les communications M2M à temps réel (missions critiques URLLC : Ultra Reliable Low Latency Communication) pour répondre au besoin du secteur de l’automobile et de l’industrie (IIoT – Industrial IoT).

Le laboratoire LIAS s’intéresse à ces différentes technologies notamment comme application visée (de manière non exhaustive) le smart-grid, le secteur du transport,…

Dans les prochains articles je reviendrai plus particulièrement sur le MTC (réseau 4G).

Il est à rappeler que ces métiers s’adressent aux femmes et aux hommes, je vous invite à consulter le site femmes-numérique.fr

Blockchain, intelligence artificielle, big data, cyber sécurité, objets connectés, cloud…

 

L’initiative

 

Le réseau 5G – 5GS

Posté le by - 6 909 vues
Répondre

Le réseau 5G (5G System) se compose d’un accès Radio (NG-RAN : Next Generation RAN) et d’un cœur réseau (5G Core).

I. L’accès radio 5G

L’accès radio 5G est constitué de stations de base de nouvelle génération qui forment le nœud de connexion des mobiles avec le cœur réseau 5G (5GC)

Les mobiles UE communiquent avec les stations de base soient par un lien radio 5G, soit par un lien radio 4G. Si la communication est en 5G, la station de base se nomme gNB (next Generation Node Base Station), si la communication est en 4G, la station de base est une station de base 4G eNB évoluée pour s’interconnecter avec le cœur réseau 5G. La station de base se nomme ng-eNb (Next Generation eNb).

Les fonctions de la station de base gNb sont  assez similaires avec l’entité eNB. Cependant, les différences concernent la gestion de la qualité de service par flux et non par support (bearer) et la gestion des tranches de réseau (Slices) sur l’interface radio.

Pour rappel, un slice est composé d’instances logiques du réseau mobile permettant d’apporter un service réseau de manière efficace en vue de répondre à une qualité de service QoS spécifique à ce service (se référer à l’article Network Slicing).

II. Le cœur réseau 5G (5GC)

Le cœur réseau 5G est adapté pour la virtualisation du réseau et s’appuie sur le découpage du plan de contrôle (Control Plane) et du plan utilisateur (User Plane) définit dans l’architecture CUPS.

Ainsi, l’entité MME qui gère à la fois l’attachement des mobiles, la localisation et la création des supports (bearers) se décompose en deux entités fonctionnelles en 5G :

  • L’entité AMF (Access and Mobility Managmenent Function). L’entité AMF établit une connexion NAS avec le mobile UE et a pour rôle d’enregistrer (attachement) les mobiles UE et de gérer la localisation des mobiles sur le réseau 3GPP et/ou non 3GPP.
  • L’entité SMF (Session Management Funtion). L’entité SMF permet de contrôler les sessions PDN. L’entité SMF est choisie par l’entité AMF puisque l’entité AMF  gère la signalisation NAS avec le mobile. L’entité SMF est responsable de la gestion du plan de contrôle. Autrement dit, l’entité SMF correspond à l’entité SGW-C et PGW-C de l’architecture CUPS. L’entité SMF a une interface avec l’entité qui gère la politique des flux (PCF : Policy Charging Function).

Le plan de transport est composé de passerelle de données qui réalise des mesures sur les données transportées et réalise l’interconnexion avec les réseaux Data (PDN). Dans l’architecture CUPS, les fonctions du plan de transport sont gérées par les entités SGW-U et PGW-U. Pour le cœur réseau 5G, les fonctions du plan de transport sont à la charge de l’entité UPF (User Plane Function). L’entité UPF communique avec l’entité SMF par l’interfae Sx et selon le protocole PFCP. Se référer à l’article présentant l’architecture CUPS.

L’entité PCRF de l’architecture 4G permet de définir les règles de contrôle et les politiques de flux avec l’entité SGW/PGW. En 5G, l’entité PCRF se renomme PCF et permet de contrôler les flux à la fois au niveau de l’entité SMF mais également au niveau de l’entité AMF afin de pouvoir apporter une meilleure granularité sur les flux autorisés en prenant en compte la localisation du mobile UE.

Le profil utilisateur (son abonnement, ses droits, …) sont sauvegardées dans une base de données UDR accessible via l’entité UDM (Unified Data Management). L’entité UDM conserve les profils de sessions de données (sessions PDU) et de l’entité AMF sur laquelle est attachée le mobile UE (éventuellement les entités AMF pour un accès 3GPP et non 3GPP sur un autre opérateur).

L’enregistrement du mobile nécessite une double authentification réalisée au niveau de l’entité AMF et du mobile UE à partir de vecteurs d’authentifications fournies par l’entité AUSF (AUthentication Server Function).

Enfin, l’entité NSSF (Network Slice Selection Function) est une entité permettant d’assister l’entité AMF de la sélection des instances logiques du réseau pour une tranche de réseau (slice) défini.

La figure 1 présente l’architecture 5G et les interfaces entre chaque entité.

Figure 1 : L’architecture du réseau 5G point à point (R.15)

Les procédures liées aux supports (bearers) dans l’architecture CUPS

Posté le by - 1 438 vues
Répondre

Avant de lire cet article, il est préférable d’avoir lu l’article précédent présentant l’architecture CUPS. Dans cet article nous allons voir les modifications apportées sur les protocoles d’établissement de support suite au découpage des entités SGW et PGW en deux parties (plan de contrôle et plan utilisateur).

I) Protocole de gestion des sessions et de handover

Le protocole de gestion de sessions a pour but d’ajouter, de modifier ou supprimer une entrée des tables de contextes au niveau des entités SGW et PGW  afin de permettre :

  • l’établissement du support par défaut ;
  • l’établissement du support dédié ;
  • la modification des caractéristiques du support
  • la désactivation du support

En cas de handover, sous la direction de l’entité MME, la table de contexte du SGW doit être modifiée afin de gérer le transfert de l’entité eNB source vers l’entité eNB cible.

Pour assurer la compatibilité avec les différentes évolutions du réseau opérateur, les entités fonctionnelles SGW-C et SGW-U doivent assurer les mêmes fonctionnalités.

Ainsi, concernant la gestion des sessions, les sous-fonctionnalités sont réparties de la manière suivante :

  • La gestion des supports (bearer) est sous la responsabilité des entités SGW-C ou SGW-U
  • L’allocation des identifiants de tunnels TEID est obligatoirement sous la responsabilité de l’entité SGW-C et optionnellement, l’entité SGW-C peut léguer cette fonctionnalité à l’entité SGW-U.
  • Le transfert des paquets est géré par l’entité SGW-U
  • Le marquage des paquets est géré par l’entité SGW-U

L’identifiant de tunnel TEID est unique pour chaque entité SGW-U, ce dernier est alloué lors de l’activation d’un support et supprimé lors de la désactivation du support.

En cas de handover de la station de base eNb source vers une station de base eNb cible sans changement d’entité SGW-U, l’entité fonctionnelle  SGW-C (qui est le contrôleur SDN) injecte une modification de règles de transfert à l’entité SGW-U via la requête Sx session modification request supportée par le protocole PFCP. La table de flux au niveau de l’entité SGW-U doit remplacer l’adresse IP de l’eNB source et l’identifiant de tunnel associé au bearer sur l’eNB source par l’adresse IP et le TEID correspondant de l’eNB cible (et ceci pour  tous les tunnels activés lors de la procédure de handover).

En cas de handover d’un eNb source vers un eNb cible avec changement d’entité SGW-U, l’entité fonctionnelle PGW-C (contrôleur SDN) doit en plus injecter une modification de règles (protocole PFCP)à l’entité PWG-U pour commuter le tunnel S5/S8 de l’entité SGW-U  vers l’entité SGW-U cible. Le message Sx session modification request transmis de l’entité PGW-C vers l’entité PGW-U contient l’identifiant du support (bearer ID), l’adresse IP de l’entité SGW-U cible et le nouvel identifiant de support TEID de l’entité SGW-U.

La procédure de handover se déroule en trois étapes :

  • Préparation des ressources radios entre l’entité UE et l’eNB cible
  • Modification de la table de contexte du SGW-U provoquée par l’échange suivant
    • SGW-C vers SGW-U: requête Sx session modification request
    • Après avoir transmis le dernier paquet PDU à l’entité eNB source, le SGW-U confirme la modification de sa table de flux
    • SGW-C U vers SGW-C: requête Sx session modification response
  • Une fois pris en compte le changement de chemin S1 path au niveau du SGW-U, il faut en informer l’entité eNB source :
    • SGW-C transmet au SGW-U un marqueur de fin de paquets (end marker packet)
    • SGW-U transmet à l’entité eNB source le marqueur de fin de paquets (end marker packet)
    • l’entité eNB source peut relâcher les supports radios avec l’entité UE.

Si le handover nécessite un changement de SGW-U, dans ce cas, la gestion du marqueur de fin de paquets (end marker packet) est sous le contrôle du PGW-C.

II) Protocole pour la fonction HLCom

Dans le cas de dispositifs IoT à latence élevée, l’organisme 3GPP a introduit des solutions de buffer étendu afin de conserver les données à transmettre aux dispositifs lorsque ces derniers ne sont plus joignables (EMM Registered mais à l’état dormant). Les données sont bufférisées au niveau du SGW jusqu’à ce que le dispositif soit de nouveau dans l’état idle ou connected.

Avec la séparation de l’entité SGW en plan de contrôle et plan utilisateur, la sauvegarde des données doit obligatoirement être supportée par l’entité fonctionnelle SGW-U et optionnellement par l’entité SGW-C.

Premier Cas :

Dans le cas où l’entité SGW-C support la capacité de sauvegarde des données (buffering capacity), lorsque le dispositif UE est dans l’état ECM_idle pour une durée eDRX ou PSM connue, l’entité SGW-C informe l’entité SGW-U (injection de règles) de ne plus transmettre les données à la station de base eNB mais de commencer à transférer les données vers l’entité SGW-C.

Lorsque l’entité UE passe à l’état ECM-CONNECTED, alors l’entité SGW-C met à jour les tables de flux du SGW-U avec l’identifiant TEID du eNB correspondant. Si des données ont été sauvegardées au niveau de l’entité SGW-C, alors les données sont encapsulées dans l’injection de règles Sx. L’encapsulation GTP-U permet à l’entité SGW-U d’identifier la connexion PDN et l’identité du support.

Deuxième Cas :

L’entité SGW-U conserve les données à destinations des dispositifs UE non joignable mais enregistrés sur le réseau.  Ainsi, lorsque le mobile UE passe à l’état en veille (ECM-IDLE), l’entité SGW-C est informée par le MME et doit à son tour en informer l’entité SGW-U par le message Sx session modification.  Dans ce deuxième cas, l’entité SGW-C décide que la bufferisation des données est à la charge de l’entité SGW-U et informe ce dernier. De plus, l’entité SGW-C demande à l’entité SGW-U d’être notifié ou non lorsque le premier paquet en provenance du PDN et à destination du dispositif UE est transmis à l’entité SGW-U

Ainsi, lorsque le premier paquet à destination du dispositif UE est transmis à l’entité SGW-U, ce dernier doit informer le contrôleur SGW-C par le message Sx reporting message ou non. A la réception de ce message, l’entité SGW-C décide d’informer ou non l’entité MME en transmettant la requête Downlink Data Notification.

Lorsque le dispositif UE passe à l’état ECM-CONNECTED, l’entité MME informe l’entité SGW-C et ce dernier notifie l’entité SGW-U via l’interface Sxa en indiquant l’identifiant de tunnel de l’eNB (ou éventuellement le RNC/SGSN).  Les données sont transmises de l’entité SGW-U à l’eNB (ou RNC ou SGSN) et en cas de la mobilité du dispositif UE sur un autre SGW-U, les données sont transmsises de l’entité SGW-U source (l’entité qui a bufferisé les données) vers l’entité SGW-U cible.

III) Les Procédures Sx Sessions Management

Les procédures Sx Sessions Management permettent de contrôler les fonctionnalités des entités fonctionnelles du plan de transport. Le contrôleur peut créer, mettre à jour, ou supprimer les contextes de sessions Sx, c’est-à-dire les paramètres de contextes concernant une connexion PDN pour le support par défaut et pour le support dédié.

Figure 1 : La procédure d’établissement de contexte

Une fois le contexte crée pour une connexion PDN, il est possible de modifier les caractéristiques du contexte par la procédure Sx Session Modification Procedure.

Pour désactiver le contexte, la procédure se nomme Sx Session termination procedure.

Nous allons illustrer la procédure sur une demande d’attachement d’un mobile UE. On suppose que la demande s’effectue sur le MME défini par l’identité GUTI conservé par le mobile UE mais de par le déplacement du mobile UE, on suppose que le mobile UE est sous la couverture d’une cellule connectée à une entité SGW (nommée nouveau SGW) différente de l’entité SGW (nommée ancien SGW) sur lequel le mobile UE était connecté avant le détachement.

On allume  le mobile, le SGW-U ayant été modifié, alors :

  • Au cours de la procédure d’attachement, la modification du SGW source au SGW cible nécessite de supprimer les tables de flux au niveau des entités SGW-U et PGW-U. Ainsi, les entités old SGW-C et old PGW-C exécutent la procédure Sx Session termination
  • Lors de la requête PDN connectivity, la table de flux au niveau du SGW-U et PGW-U doit être fournie. Ainsi, les contrôleurs SDN SGW-C et PGW-C injectent les règles par la procédure Sx Session Establishment.

Nous allons découper le call flow en deux parties :

Première partie

  • Procédure d’établissement du lien radio
  • Demande d’attachement, authentification et mise en sécurité

Deuxième partie

  • Suppression du contexte sur l’entité Old SGW
  • Création du support avec le nouveau SGW

    Figure 2 : La première partie de demande d’attachement

    Figure 3 : La procédure d’établissement de support