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

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

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

(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

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.

 

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

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

 

Network Functions Virtualisation (NFV) pour le réseau 4G/5G

Objectifs :

Comprendre :

  • l’infrastucture du NFV (NFVI);
  • la gestion et l’orchestration des VM (MANO)
  • la fonction de chainâge de service VNFFG (Virtual Network Function Forwarding Graph). Le VNFFG correspond à la fonction SFC pour le NFV (reprendre l’article précédent pour le SFC)

Introduction

L’approche NFV permet à l’opérateur de déployer des fonctions réseaux en tant qu’instances virtualisées au lieu d’entités matérielles dédiées. L’approche NFV s’appuyant sur la virtualisation informatique permet la création de partition réseau isolée sur une infrastructure réseau partagée permettant ainsi à de multiples réseaux virtuels hétérogènes de co-exister simultanément sur les mêmes équipements matériels.

L’architecture NFV définie par l’ETSI est représentée sur la figure 1. La couche horizontale VNF correspond aux fonctions réseaux virtualisée (VNF : Virtualised Network Function). Il s’agit de machines virtuelles (VM) fonctionnant sur l’infrastructure NFV (NFVI). L’infrastructure NFVI est une infrastructure physique de stockage, de calcul et de réseau. La gestion et l’orchestration des VM est sous la responsabilité de la fonction MANO (Management and orchestration). La fonction MANO doit gérer les ressources de l’infrastructure NFVI (capacité réseau, la puissance de calcul, l’espace mémoire) et la durée de vie des fonctions virtuelles en fonctionnement sur l’infrastructure NFVI (création et allocation des VMs).

Les nœuds de l’infrastructure NFV (NFVI nodes) sont déployés sur les points de présence POP de l’opérateur afin de répondre aux exigences de latence selon les cas d’usages client. Les fonctions réseaux virtualisés (VNF) peuvent ainsi être déployées dynamiquement sur les infrastructures NFVI à la demande d’un orchestrateur et sous réserve de la limite de capacités des nœuds NFI (POP).

Figure 1 : Architecture NFV

La virtualisation élimine la dépendance entre les fonctions réseaux (NF : Network Function) et le matériel. Dans le cas du réseau de mobiles, les entités pouvant être virtualisées sont :

  • dans le cœur réseau EPC : l’entité MME, le SGW, le PGW
  • dans le cœur réseau IMS : P/I/S-CSCF

Une fois que les entités sont virtualisées (on parle alors de VNF), il est nécessaire de chaîner le trafic à travers les VNF dans un graphe ordonné pour appliquer les services réseaux. Dans le cas du NFV, le chaînage s’appelle le graphe d’acheminement des fonctions réseaux virtualisées (VNFFG – VNF  Forwarding Graph) et non le chaînage de fonctions service SFC (Service Function Chain) pour prendre en compte la virtualisation sur un réseau Overlay.

Le graphe d’acheminement des fonctions réseaux virtualisées VNF-FG fourni un niveau d’abstraction afin que l’opérateur puisse en temps réel composer les services réseaux.

Figure 2 : Exemple de graphe d’acheminement des fonctions réseaux virtualisées

Figure extrait de l’article Network Functions Virtualisation  -Update White Paper (https://portal.etsi.org/nfv/nfv_white_paper2.pdf)

II) L’architecture NFV définie par l’ETSI

L’architecture NFV est constituée de :

  • l’insfrastructure NFV : NFVI (Network Function Virtualisation Infrastructure) fournit les ressources matérielles (serveurs, COTS – Commercial Off The Sheld, cartes électroniques, …) et le logiciel de virtualisation. Le NFVI se compose donc :
    • d’une interface matérielle (stockage, réseau, calcul)
    • d’une interface virtuelle (stockage, réseau, calcul)
    • d’une couche de virtualisation entre le matériel et le logiciel
  • Le VNF (Virtualised Network Function) correspond aux fonctions réseaux virtualisées pouvant être exécutées sur les équipements du NFVI
  • NFV M&O (Management and Orchestration) permettant de gérer les services réseaux de bout en bout est composé de trois blocs
    • L’orchestrateur (NFV Orchestrator) : L’entité d’orchestration est responsable du cycle de vie des services réseau tant au niveau logiciel que matériel sur plusieurs domaines en contrôlant les VIM de chaque domaine;
    • un  gestionnaire (VNFM) en charge du cycle de vie des VNFs ;
    • un gestionnaire (VIM) en charge de la gestion des ressources du NFVI à l’intérieur d’un domaine.

Les services OSS/BSS doivent pouvoir transmettre au bloc NFV M&O des informations sur le profil des utilisateurs, la facturation, les politiques de qualités, les accords entre domaine, …

Couplé à un portail de supervision, cette architecture permet aussi de déployer des services réseaux à la demande pour les entreprises (exemple Network as a service  de la solution  Easy Go Network).

L’infrastructure NFV (NFVI) est donc répartie sur des points de présence de l’opérateur (POP) afin de réduire la latence du réseau pour ses clients : les services réseaux sont déployés sur les nœuds d’infrastructure (NFVI Node) au plus proche des clients.

Les fonctions réseaux virtualisées (VNF) peuvent ainsi être déployées dynamiquement à la demande dans la limite des capacités des nœuds NFVI.

II-1) L’infrastructure NFV (NFVI)

L’infrastructure NFV se découpe en trois domaines :

  • domaine de calcul virtualisé (processeurs, accélérateurs, …) ;
  • domaine de l’hyperviseur : système d’exploitation supportant la virtualisation (machines virtuelles) et/ou des containeurs pour faire fonctionner les VNF, ainsi que les capacités de commutateurs virtuels (vSwitch).
  • domaine réseau de l’infrastructure

En général, l’infrastructure NFV s’appuie sur la paravirtualisation et non la virtualisation : les systèmes d’exploitation des machines virtualisés n’évoluent pas dans un environnement physique virtuel mais dialogue avec l’hyperviseur via des API. La para-virtualisation réduit la consommation de ressources processeur de la virtualisation afin d’améliorer les performances en modifiant le noyau du système d’exploitation invité. Une couche de virtualisation est insérée entre le matériel et le système d’exploitation.

Le coeur de la paravirtualisation est un hyperviseur fonctionnant au plus près du matériel, et fournissant une interface qui permet à plusieurs systèmes hôtes d’accéder de manière concurrente aux ressources. Les systèmes d’exploitation hôte et invités sont modifiés pour fonctionner sur la couche de virtualisation

Figure 3 : L’infrastructure et la para-virtualisation

Les fonctions réseaux virtualisées seront déployées dans des conteneurs au-dessus de la couche de virtualisation. Un conteneur est une instance complète de système d’exploitation, avec son système de fichiers, ses comptes utilisateurs, ses processus, etc. Ainsi, les conteneurs logiciels sont considérés comme des applications pour le serveur. Sur cette application (système d’exploitation), il est possible de faire tourner des fonctions réseaux virtuels, nommés VNF

Enfin, les VNF sont interconnectées entre elles pour constituer un service réseau (NS).

Figure 4 : Le chainage de service réseaux virtuels

II-2) La gestion et l’orchestration NVF (NFV MANO – Management and Orchestration)

La couche de virtualisation permet de découpler l’implémentation logicielle des fonctions réseaux aux ressources matérielles (calcul, accélérateur et ressources réseaux). Ce découplage nécessite de nouvelles fonctions de gestion et d’orchestration et créé de nouvelles dépendances entre les ressources matérielles et les solutions logicielles virtualisées.

Une des premières motivations du NFV est l’agilité à déployer des nouvelles fonctions réseaux et d’accroitre les capacités de ces fonctions à la demande (exemple : une entreprise qui souhaite une bande passante plus importante une heure particulière dans la semaine, cf : https://www.youtube.com/watch?v=niHSqvKz4U0).

Afin de pouvoir profiter de cette agilité, un niveau d’automatisation de haut niveau est nécessaire pour provisionner, configurer et tester les performances des fonctions réseaux virtualisées.

La gestion et l’orchestration NFV (MANO) automatise le déploiement de fonctions réseaux virtualisées (VNF). Pour cela, il faut superviser :

  • L’infrastructure pour la gestion du matériel (capacité, réseau, calcul, …)
  • Le déploiement de fonctions réseaux (VNF)
  • Le chaînage de fonctions réseaux pour réaliser des services réseaux

Ainsi, l’entité MANO est constituée de trois fonctions :

  • Gestion des ressources
  • Gestions des VNF
  • Gestion des NS

Figure 5 : L’orchestration et la gestion des services et des ressources

L’objectif est de pouvoir mettre en œuvre des fonctions pour fournir des fonctions réseaux virtualisés et des services réseaux avec les ressources nécessaires pour s’exécuter correctement : les types d’instances à déployer, adapter la taille de l’instance en fonction de la demande (scaling) , mettre à jour une fonction réseau virtualisée (VNF), ou éteindre l’instance.

Au niveau réseau, les opérations de déploiement de service réseaux s’appuient des descripteurs décrivant les ressources et les opérations nécessaires. Les différents types de descripteurs sont :

  • Descripteurs VNF (VNFD) sont des gabarits permettant de définir les instances à mettre en œuvre et les besoins en ressource de chaque instance (CPU, mémoire, interface et réseau). Le descripteur défini également les types d’interfaces avec l’infrastructure NFVI et les KPI attendues.
  • Descripteur NS (NSD) : Le descripteur NSD contient les attributs pour un groupe de fonctions réseaux qui constituent ensemble un service réseau. Ces attribues contiennent aussi les exigences pour chaîner les VNF ensemble et fournir le service réseau.
  • Descripteur VNFFG (VNFFGD) contient des metadata concernant le graphe d’acheminement des fonctions réseaux virtualisées VNF, ainsi que les références aux conteneurs de l’infrastructure, aux instances VNFs et au lien entre les VNFs. Les métadonnées contiennent de plus des règles de politiques pour les fonctions d’acheminement (règle de routage et de commutation).

De plus, il est nécessaire :

  • d’automatiser les fonctions de supervisions en collectant les métriques de performances sur des instances et du matériel à des niveaux différents
  • de corréler les mesures effectuées afin d’apporter une solution sur les fautes détectées pour que le service fonctionne de manière fiable sur des équipements distribués.
  • de définir des performances KPI (Key Performance Indicator) au niveau des services réseaux (NS)

Comme évoqué précédemement, le bloc NFV M&O (Management and Orchestration) permet de gérer les services réseaux de bout en bout est composé de trois blocs

  • L’orchestrateur (NFV Orchestrator) : L’entité d’orchestration est responsable du cycle de vie des services réseau tant au niveau logicielle que matérielle sur plusieurs domaines en contrôlant les VIM de chaque domaine;
  • un  gestionnaire (VNFM) en charge du cycle de vie des instances VNFs en fonction des données contenues dans le descripteur. Il démarre les instances VNF, les gères, les adapte et récupère des indicateurs de supervision. Le gestionnaire VNFM utilise donc le descripteur VNFD durant la procédure d’instanciation de la fonction réseau virtualisée VNF et pendant toute la durée de vie de la VNF ;
  • un gestionnaire (VIM) en charge de la gestion des ressources du NFVI à l’intérieur d’un domaine.

Le gestionnaire VIM est une abstraction matérielle qui fourni une interface nord pour le VNFM et l’orchestrateur NFV. L’interface sud supporte les interfaces Nf-Vi pour piloter les instances sur l’infrastructure NFVI.

 

La figure ci-dessous présente un schéma de déploiement au sein d’Orange avec l’appui de Juniper et d’un controleur sous Openstack.

 

Principe du SDN dans une architecture réseau classique

I – Généralités sur le réseau IP

I-1) Les équipements de routage et de commutation

Sur un réseau IP, la mise en relation entre un client et un serveur s’appuie sur des équipements de routage et des équipements de commutation.

Le rôle du routeur est d’acheminer chaque paquet IP au nœud suivant afin que chaque paquet puisse être transporté de bout en bout, du client IP au serveur et inversement. Avant d’être déployés sur le réseau, les routeurs doivent être configurés. La configuration permet au minima de définir les adresses IP des interfaces physiques et virtuelles du routeur et d’informer le routeur des protocoles de routage à appliquer pour acheminer les paquets IP.

Les protocoles de routage permettent à chaque routeur de récupérer des informations des routeurs voisins afin de constituer localement des informations de routage (RIB : Routing Information Base). Ainsi, les informations de routage sont actualisées pour prendre en compte l’état de chaque nœud (saturé, hors ligne, …) de manière dynamique : les routeurs échangent entre eux des informations par l’intermédiaire du protocole de routage choisi. Ensuite, les informations de routage permettent de construire une table d’acheminement (Forwarding Information Base). La table d’acheminement est exploitée par le routeur pour définir l’interface sur laquelle envoyer le paquet (adresse de destination, classe de service).

Ainsi, le protocole de routage RIB permet de constituer des règles qui sont synthétisées dans une table d’acheminement FIB afin de router le paquet IP vers le prochain saut (next-hop) selon un critère de  coût (nombre de saut, débit, délai, …) géré par le RIB. L’avantage du routage dynamique est l’adaptation  aux évolutions du réseau (nouvelles routes, routeur saturé ou lien défaillant) en temps réels.

Les informations de routages transmises entre routeurs dépendent du protocole de routage choisi :

  • états de lien, chaque routeur s’appuie sur la qualité et les performances du lien et de la bande passante qui le relie les uns aux autres. Cet échange permet de définir une cartographie complète du réseau au niveau de chaque routeur. Ce protocole de routage s’appelle OSPF (Open Shortest Path First) et il est également utilisé par le réseau MPLS ;
  • vecteur de distance se base sur le principe que chaque routeur dispose d’une table de routage indiquant, pour chaque réseau de destination, l’interface locale permettant de l’atteindre et la meilleure distance qui lui est associée (exemple de protocole RIP, EIGRP) ;
  • label, les routeurs échangent des informations de label dans le contexte MPLS (LDP : Label Distribution Protocol) ;
  • bordure, en bordure de deux réseaux différents (on parle de domaine), les routeurs échangent des informations de routage et d’accessibilité : BGP (Border Gateway Protocol).

Deux grandes familles de protocole sont définies : Le protocole interne domaine (OSPF, RIP, MPLS) et le protocole d’interconnexion inter domaine  (BGP, EGP – Exterieur Gateway Protocol, …).

I-2) Le réseau opérateur 4G

Si on s’intéresse plus particulièrement au réseau opérateur, le réseau de transport de l’opérateur PLMN permet de fournir une interconnexion entre les différentes entités du réseau mobiles 4G. Cette interconnexion s’appuie sur deux types de réseaux principaux :

  • le réseau MPLS-VPN (Multi-Protocol Label Switching – Virtual Private Network) constituant le réseau de transport du réseau EPC
  • le réseau VPLS (Virtual Private Lan Service) assurant l’interconnexion de niveau 2 entre les eNB et le cœur réseau (MME, SGW)

Afin d’assurer le trafic des flux IP, le réseau MPLS utilise deux types de routeurs :

  • les routeurs EDGE LSR ( Label Edge Router ou Ingress LER) sont les routeurs de passerelle vers un autre réseau (Ingress LER pour le routeur entrant et Egress LER pour le routeur sortant)
  • les routeurs Core LSR constituent le domaine réseau MPLS. Ils réalisent le routage et l’étiquetage des premiers paquets et ensuite de la commutation de label.

Figure 1 : L’architecture du réseau MPLS

Le réseau VPLS est un réseau virtuel de niveau 2 qui s’appuie sur les trames Ethernet pour réaliser de la commutation Ethernet et de la commutation de label. Les tables de labels sont échangées via le protocole LDP (Label Distribution Protocol) entre les équipements du réseau VPLS.

II – Compréhension du protocole de routage

La représentation simplifiée d’un routeur est décrite sur la figure 2 par un plan de contrôle qui décide de la route et d’un plan de données pour prendre en charge le trafic. Pour les équipements de réseaux traditionnels, les plans de contrôle et le plan de données sont localisés dans le même équipement.

Figure  2 : La configuration simplifiée d’un routeur

La souplesse apportée par les algorithmes de routage permet d’allouer dynamiquement les routes optimales en fonction de l’évolution de charge du trafic. Cependant, cette solution souffre de deux défauts majeurs.

Le premier défaut est lié au coût d’exploitation (OPEX) pour faire évoluer l’architecture réseau. En effet, les équipements du réseau de transport (commutateurs et routeurs) sont déployés en fonction du trafic estimé. Le réseau de transport est donc surdimensionné par rapport au besoin moyen des clients mais au vu des prévisions de charge pour les années à venir, l’opérateur devra déployer et programmer d’autres équipements de routage et de commutation.

Le deuxième défaut est le manque de flexibilité du réseau vis-à-vis de l’installation de nouvelles fonctions réseaux comme l’équilibrage de charge, des pare-feux, ou le déploiement de nouveaux serveurs. Si par exemple, une entreprise multi-site souhaite installer un pare-feu uniquement et un détecteur de malware uniquement pour filtrer les connexion Internet, alors de telles modifications nécessitent soit la reconfiguration du réseau (séparation des flux entre l’accès Internet et l’accès VPN inter-site) soit la contrainte de respecter la topologie actuelle du réseau pour rajouter de nouveaux services (dans ce cas, tout le trafic VPN et Internet passera par le pare-feu et le contrôleur de malware).

Afin d’apporter de la souplesse au déploiement de services réseaux sur le réseau de transport, le SDN (Software Defined Networking) repose sur :

  • l’idée de séparer le plan d’acheminement des flux IP (FIB) et le plan de contrôle constituant les informations de routages (RIB)
  • d’apporter de la souplesse en donnant des ordres au plan de contrôle à partir d’API REST transmises par des applications (ingénierie de routage, Network as a Service).

Il existe deux modèles SDN :

  • Programmabilité via un contrôleur. Dans ce modèle, une application donne un ordre abstrait et global à un contrôleur, qui à son tour traduit cette requête en une suite d’ordres auprès des équipements du réseau concerné.
  • SDN Overlay: Création d’un réseau virtuel au-dessus du réseau physique. Dans ce modèle, les applications créent leur propre réseau « overlay », s’affranchissant des contraintes du réseau physique sous jacent. Ce dernier n’a pour mission que la simple connectivité entre les noeuds d’extrémité des tunnels, et le réseau d’overlay assure l’intégralité des services.

Programmabilité via un contrôleur

Le positionnement du SDN est donc de remplacer les routeurs et commutateurs de niveau 1 à 4 par une machine physique universelle dont le traitement des flux IP est modifié en temps réel par une couche de contrôle, appelée contrôleur SDN.

La couche de contrôle a pour rôle d’implémenter des règles  sur le commutateur SDN. Les règles peuvent concerner des affectations de VLANs (port d’accès), du routage et des traitements spécifiques de services réseaux (équilibrage de charge, haute disponibilité, QoS,…)

Ainsi, l’architecture SDN est basé sur l’évolution de l’architecture suivante (figure 3):

Figure 3 : Architecture SDN

Le protocole d’injection de règles SDN le plus connu est OpenFlow (version 1.0 à 1.5)

Le contrôleur est, quant à lui, piloté par le besoin des applications. On dit que le contrôleur fournit une abstraction du plan de transport aux applications. La notion d’abstraction signifie que le contrôleur offre des interfaces programmables aux applications réseaux (les interfaces sont nommées API) et le contrôleur se charge de piloter le plan de données en injectant des règles d’acheminement spécifiques répondant aux besoins des applications sans que les applications connaissent ces règles.

Ainsi, comme le montre la figure 4, la couche d’abstraction du contrôleur comporte une interface de programmation (interface Nord) qui fournit des fonctions génériques et banalisées de manipulation du réseau de transport en cachant les détails techniques des entités du réseau.  Ceci permet à une application d’informer le contrôleur des besoins de traitement de flux de manière générale en faisant abstraction des détails technique du matériel.

Figure 4 : Le principe du SDN

Le contrôleur dispose d’une interface nord appelé Northbound API afin de proposer des API de haut niveau aux applications SDN. Les applications SDN peuvent être une demande de gestion du réseau, un contrôle d’accès, une priorité de service à mettre en œuvre, …

Le plan de contrôle va orchestrer la demande des applications en transmettant via l’interface sud les tables d’acheminements correspondantes. Les protocoles utilisés sur l’interface sud peut être le protocole CLI (Command Line Interface), le protocole OpenFlow, ou d’autres protocoles (NETCONF/YANG, …)

Le terme d’orchestration désigne le processus qui permet au contrôleur de satisfaire les demandes de service de plusieurs clients selon une politique d’optimisation pour chaque service.

Le plan de données ou plan usager est chargé de l’acheminement (forwarding) du trafic des utilisateurs et de l’application de politique de trafic (parefeu, VLAN, …) dont les règles ont été transmises par le contrôleur. La politique réseau étant définie par les applications.

 

SDN Overlay

Principe de l’Overlay

Le réseau overlay est une solution initialement dédiée aux hébergeurs de Cloud Center afin que deux serveurs de l’hébergeur, physiquement éloignés, puissent communiquer entre eux via  un réseau de transport opérateur (réseau d’interconnexion externe aux hébergeurs donc non modifiable).

Les réseaux Overlay (over-layer) signifie construire un réseau virtuel de couche 2 au-dessus d’un réseau de couche 3 : Les paquets du réseau sont encapsulés puis routés à travers l’infrastructure existante. Un des protocoles proposé est le VxLAN (Virtual eXtensible LAN) proposé dans le RFC 7348. Il encapsule les trames Ethernet dans un datagramme UDP.

A l’origine, cette solution a été proposée pour faciliter l’interconnexion des serveurs de cloud qui sont basés sur le principe de virtualisation : un hébergeur dispose de plusieurs salles de serveurs. Chaque serveur est une machine physique pouvant recevoir plusieurs machines virtuelles (VM). Afin de partager les ressources physiques (RAM, CPU, cartes réseau, …), il est nécessaire d’installer sur le serveur un logiciel nommé hyperviseur. Un hyperviseur (VMM : Virtual Machine Monitor ou Virtual Machine Manager) est un moniteur de machines virtuelles installé directement sur la machine physique (hyperviseur bare metal) ou sur un système d’exploitation. Son rôle est de contrôler l’accès au matériel et de partager les ressources physiques entre toutes les machines virtuelles (VM : Virtual Machine).

L’hyperviseur virtualise l’interface de réseau physique et la partage entre toutes les machines virtuelles. Chaque VM dispose de sa propre adresse MAC et adresse IP. Les VMs sont configurées en mode pont, NAT ou sont isolées des autres VMs (Host Only ou réseau privé). Le mode host only permet de créer un réseau privé entre la VM et le machine hôte.

La virtualisation du réseau coordonne par conséquent les commutateurs virtuels dans les hyperviseurs du serveur et les services réseaux pour les VM connectées.

L’hyperviseur réalise ainsi un commutateur virtuel permettant de connecter les VM les unes aux autres. Le commutateur virtuel supporte le VLAN, mais le protocole 802.1Q limite à 4096 le nombre de VLAN. Lorsque l’hébergeur de solution cloud souhaite exploiter le réseau IP opérateur pour transmettre des paquets IP entre deux serveurs situés sur le même réseau virtuel, il est nécessaire d’encapsuler les trames dans une couche supérieure.

Les hébergeurs exploitent le protocole VxLAN, chaque VM sur une machine physique est identifiée par un identifiant réseau VxLAN sur 24 bits, nommé VNI. L’hyperviseur de chaque serveur gère l’encapsulation et la désencapsulation des trames contenues dans les VxLANs (VTEP : VxLAN Tunnel EndPoint).

Supposons qu’une machine virtuelle située sur un réseau virtuel (VxLAN) dans un serveur physique souhaite transmettre des données vers une machine virtuelle située dans un autre serveur physique (VxLAN). La machine virtuelle source construit sa trame Ethernet avec les champs suivants :

Figure 5 : L’architecture réseau entre deux serveurs interconnecté par le réseau IP opérateur

La figure 6 représente l’encapsulation et les entêtes associées :

Trame Ethernet VM: VxLAN ID/Mac Dest/Mac Src VM/ IP Src VM/ Ip Dest VM/ TCP ou UDP Data

L’hyperviseur de la machine virtuelle encapsule la trame Ethernet dans la couche UDP :

MAC VTEP Dest ou MAC GW/ MAC VTEP Source/IP VTEP source/IP VTEP Destination/ UDP/Data contenant laTrame Ethernet VM.

Figure 6 : L’encapsulation VxLAN

Nous venons de voir l’overlay, mais pas encore le SDN.

SDN Overlay ou Overlay réseau programmable

Nous savons que le principe du SDN réside dans la séparation du plan de contrôle et du plan utilisateur. Dans le cas du SDN overlay, le réseau physique sous-jacent ne peut pas être contrôlé, le SDN s’applique donc au réseau overlay.

Les datacenters doivent aussi être flexibles et gérer au mieux les flux de réseaux. La programmabilité s’exprime surtout ici avec l’orchestration des ressources : comment coordonner intelligemment le processus de mise à disposition d’infrastructure en entreprise. Ainsi, la virtualisation permet à l’intelligence de l’infrastructure des hébergeurs Cloud de contrôler et de déployer automatiques les serveurs. Les éléments de l’infrastructure (stockage, calcul, mis en réseau) sont virtualisés et regroupés en pools de ressources. De plus les applications doivent être mobiles et répliquées sur un Cloud distant afin de permettre une reprise après sinistre.

L’utilisation d’une plate-forme de gestion du Cloud (CMP – Cloud Management Platform) permet de provisionner des réseaux virtuels en activant les services réseaux et les services de sécurité virtuels en fonction des charges de travail.

Il existe plusieurs solutions virtuelles ( VMware NSXMidokura MidoNet et Nuage Networks) afin de contrôler dynamiquement les routeurs virtuels, les commutateurs virtuels grâce à un contrôleur de service virtualisé qui permet également de déplacer, créer ou détruire un VM afin de répondre au mieux au besoin du client

Le rôle du SDN est donc d’orchestrer les VMs afin d’adapter les ressources de l’hébergeur cloud (Amazon SE3, …) au besoin du client en assurant la fiabilité de l’interconnexion, l’accès rapide au données, ….

 

Merci à Sébastien Couderc d’avoir accepté de relire cet article

Dual Connectivity : La Double Connectivité

I) Introduction

La double connectivité (DC : dual connectivity) est une évolution fondamentale de la norme 4G. Celle-ci est définie dans la release R.12 et elle doit être comprise pour deux raisons principales :

  • le fonctionnement du mécanisme DC est exploité par les mécanismes LWIP et LWA ;
  • la double connectivité sera mise en œuvre pour le déploiement de la 5G en mode non autonome (NSA : non standalone). La double connectivité fait donc parti des mécanismes transitoires vers la 5G.

La double connectivité signifie que le mobile UE va établir simultanément deux supports radios (RAB : Radio Access Bearer) avec deux stations de bases. Ces stations de bases peuvent être des entités eNB pour la 4G et à terme, on parle de double connectivité entre une station de base eNB (ou ng eNB) et une station de base gNB (station de base 5G). La station de base ng eNB est une station de base 4G évoluée qui communique avec le cœur réseau 5G (le cœur réseau 5G se nomme 5GC).

II Explication de la double connectivité

La double connectivité différencie le plan de contrôle (control plane) et le plan de transport des données, c’est-à-dire le plan utilisateur (user plane). Lorsque le mobile UE veut établir un support EPS (EPS bearer) il commence par demander l’établissement d’un support de signalisation radio (SRB : Signalling Radio Bearer) avec une station de base eNB. Cette station de base eNB sera nommée par la suite entité MeNB (Master eNb). L’échange de signalisation (couche RRC) s’effectuera entre le mobile UE et la station de base MeNB.

Figure 1 : Le plan de contrôle pour la double connectivité

 

La double connectivité suppose l’établissement de deux supports radios (RAB) : un support radio avec l’entité MeNB et un support radio avec une deuxième station de base eNB nommée SeNB. Les deux stations de bases MeNB et SeNB impliquées dans la double connectivité doivent impérativement avoir une interface X2.

Les fonctions du MeNB sont les suivantes :

  • établir un support data radio entre la station de base MeNB et le mobile UE ;
  • échanger des informations de contrôle avec une station de base SeNB (Secondary eNB) ;
  • établir un support data radio entre la station de base SeNB et le mobile UE ;
  • récupérer les mesures radios de l’UE correspondant à la station de base MeNB et la station de base SeNB (dans le cas de la station de base SeNB les mesures sont transmises via l’interface X2 entre le SeNB et le MeNB) ;
  • échanger des informations de contrôle avec le MME ;
  • demander l’établissement, via le MME, d’un support S1 entre le MeNB et le SGW sur l’interface S1-U U entre la station de base MeNB et l’entité SGW;
  • éventuellement, demander l’établissement via le MME, d’un support S1 entre le SeNB et le SGW sur l’interface S1-U entre la station de base SeNB et l’entité SGW;
  • contrôler le handover entre le mobile UE et la station de base SeNB
  • contrôler le handover entre le mobile UE et la station de base MeNB, et dans ce cas, libérer le RAB avec le SeNB

Concernant le plan de transport, il existe sept architectures DC différentes reposant sur le principe d’ancrage du support soit au niveau de la station de base MeNB, soit au niveau de l’entité SGW : Deux supports radios sont établis entre le mobile UE et avec chacune des stations de base (MeNB et SeNB) et un support S1-U est établi entre la station de base MeNB et l’entité SGW. Un deuxième support S1-U peut être établi entre la station de base SeNB et l’entité SGW.

Chaque station de base eNB (MeNB et le SeNB) gère le trafic de manière autonome sur les sous-couches MAC et RLC de la couche 2 et chacun station de base eNb gère sa couche physique.

Ainsi, une fois la signalisation échangée entre le mobile UE et la station de base MeNB (couche RRC) et une fois l’établissement des supports radios, les 7 architectures sont les suivantes :

  • Architecture 1A : un support S1-U est établi entre la station de base MeNB et l’entité SGW et un support S1-U est également établi entre la station de base SeNB et l’entité SGW. Au niveau du SeNB, le flux est géré par la couche PDCP du SeNB indépendamment du MeNB
  • Architecture 2 : Au moins deux supports S1-U sont établis entre l’entité SGW la station de base MeNB. L’un des supports sera associé au support radio du MeNB, le deuxième support sera associé au SeNB. Aucun support S1-U n’est établi entre l’entité SGW et la station de base SeNB. La séparation des supports est à la charge du SGW et le MeNB va gérer la redirection du trafic vers le SeNB :
    • Architecture 2A : La redirection du flux est routée du MeNB vers le SeNB. Le flux est donc pris en charge par la sous-couche PDCP de la station de base SeNB.
    • architecture 2B : La redirection du flux est gérée par la couche PDCP de la station de base MeNB et envoyé à la sous-couche RLC de la station de base SeNB. C’est donc le MeNB qui gère le chiffrement des données;
    • architecture 2C : La redirection du flux est gérée par la couche RLC de la station de base MeNB vers la sous-couche RLC du SeNB. La sous-couche RLC de la station de base est configuré en mode transparent, le contrôle et l’acquittement des trames est effectuée au niveau de la station de base SeNB.
  • Architectures 3A/3B/3C se differencient des architectures 2A/2B/3C par le fait que la commutation des supports est à la charge de la station de base MeNB. Le SGW établi au moins un bearer radio S1-U avec le MeNB. Le ou les supports S1-U sont séparés au niveau de la station de base MeNB
    • Architecture 3A : une partie des paquets est transmis vers la sous-couche PDCP de la station de base MeNB, l’autre partie vers la sous-couche PDCP de la station de base SeNB
    • Architecture 3B : L’ensemble des paquets est traité par la sous-couche PDCP de la station de base MeNB, une partie des paquets est ensuite transmise vers la sous-couche RLC de la station de base MeNB, l’autre partie vers la sous-couche RLC de la station de base SeNB
    • Architecture 3C : L’ensemble des paquets est traité par la sous-couche PDCP de la station de base MeNB et transféré à la sous-couche RLC de la station de base MeNB. Une partie des paquets est dirigé vers la sous-couche RLC de la station de base secondaire SeNB, la sous-couche RLC de la station de base SeNB fonctionne en mode transparent .

Les architectures 2 et 3 ont l’avantage d’être transparentes pour le cœur réseau CN, la gestion de la mobilité est donc réalisée uniquement au niveau de la station de base MeNB, ce qui simplifie la signalisation avec le cœur réseau, surtout si on considère les stations de base secondaire SeNB comme des petites ou micro stations de base.

L’architecture 3C présente l’avantage de laisser la station de base MeNB gérer la séparation des supports S1-U. Cette fonction dévolue à la station de base MeNB lui permet, à partir de la connaissance de la qualité du lien radio (CQI : Channel Quality Indicator)  du support RAB entre le mobile UE et la station de base MeNB, ainsi que le CQI entre le mobile UE et la station de base secondaire SeNB d’ordonnancer de manière optimale les flux IP ce qui permet d’améliorer le débit au niveau du mobile UE.

L’architecture 1A a l’avantage de ne pas surcharger le réseau de transport backhaul contrairement aux architectures 2 et 3. L’opérateur doit en effet sur-dimensionner son réseau de transport par un facteur 3 lorsqu’il choisit de déployer les architectures 2 ou 3.

Au final, seules les architectures 1A et 3C ont été retenues pour la double connectivité. L’architecture 3C est plus fexible pour gérer la mobilité et le handover par rapport aux architectures 3A et 3B.

Interfonctionnement du LTE et du WiFi

Cet article est une extension de l’article de l’article du 8 octobre : LTE et WiFi : Les attentes de la R.13 et R.14

L’architecture EPC (Evolvec Packet Core) est le cœur réseau tout IP définie dans la release R.8 pour le réseau de mobiles 4G. Le réseau EPC supporte l’interconnexion avec les réseaux  de mobiles 2G et 3G ainsi que le réseau WiFi. Il devient ainsi le point d’ancrage pour la mobilité des utilisateurs sur les réseaux d’accès 3GPP et les réseaux d’accès non 3GPP. Il est également le point d’ancrage pour la politique de QoS, de taxation et de services de facturation. Par contre, les fonctionnalités décrites dans la release R.8 n’autorise pas le mobile UE d’être sur le réseau 3GPP et non 3GPP simultanément. Par contre, dans la release R.10 plusieurs mécanismes sont proposés pour autoriser le mobile UE accéder aux deux réseaux d’accès LTE et WLAN simultanément soit :

  • en établissement une ou plusieurs connexions portées par un support radio (bearer) sur l’interface LTE et un accès radio sur le WLAN. Il s’agit du mécanisme MAPCON Multi-access PDN Connectivity) ;
  • en établissant une connexion PDN entre l’UE et le PGW, avec un mécanisme permettant de router le flux data vers l’UE (qui conserve toujours la même adresse IP) par routage vers le réseau d’accès LTE ou le réseau d’accès WiFi. Il s’agit du mécanisme IFOM (IP Flow Mobility) qui nécessite de la part du mobile UE et de l’entité PGW (nommé HA Home Agent) de supporter le protocole DSIMPv6 (Dual Stack Mobile IPv6) afin de pouvoir établir un routage sur le réseau IpV4 ou IPv6.

L’architecture du réseau 4G est rappelée sur la figure 1 :

Figure 1 : Architecture du réseau 4G

Le routage des flux entre le réseau WiFi et le réseau opérateur est conditionné au type de flux à transmettre. Afin de satisfaire la qualité d’expérience de l’utilisateur, les flux exigeant une QoS (Qualité de service) particulière comme un débit garanti, une priorité seront pris en charge par le réseau 4G alors que les autre flux seront transportés sur le réseau Best Effort via l’accès WiFi.

Le réseau opérateur doit donc analyser les types de flux et définir l’accès adéquat. Cette fonction est supportée par l’entité ANDSF (Access Network Discovery and Selection Function). Ce dernier doit donc connaitre le profil de l’utilisateur et doit pouvoir joindre l’entité  PCRF pour connaître la QoS à appliquer. A chaque demande de l’utilisateur, l’ANDSF :

  • Transmet les politiques sur le routage de flux en fonction de la capacité du mobile UE :
    • politique de mobilité ISMP (Inter-system Mobility Policy) permet de sélectionner le type de réseau 3GPP ou non 3GPP dans le cas où le mobile UE ne supporte pas une connexion simultanée sur les deux réseaux ;
    • politique de routage ISRP (Inter-System Routing Policy) permet de mettre en œuvre les mécanismes IFOM ou MAPCON
  • Détecte les réseaux d’accès pouvant apporter une connectivité radio avec le mobile UE et gère les listes des accès réseaux disponibles à proximité de l’UE (localisation et profil du mobile UE).

Les rôles de la politique de mobilité ISMP (release R.8) sont :

  • Définir les règles de priorité des réseaux d’accès (PLMN, TAC, RAC, EUTRAN, UTRAN, GERAN, SSID, …)
  • Définir le choix au réseau d’accès 3GPP/WiFi
  • Mettre à jour des règles de politiques à la demande du mobile UE ou à l’initiative du réseau (PUSH/PULL)

La politique de mobilité ISMP permet de choisir un type de réseau d’accès. Ainsi, dans ce cas si l’opérateur choisit de délester un utilisateur UE vers le WiFi, c’est tout le trafic IP de cet utilisateur UE qui sera délesté vers le réseau WiFi.

Pour avoir une granularité sur les types de flux à délester, il est nécessaire d’analyser la demande de connexion PDN.

Les rôles de la politique de routage ISRP (release R.10) sont :

  • Autoriser l’UE à accéder à deux réseaux simultanément en établissant plusieurs PDN
  • Sélectionner le réseau pour délester le trafic

L’ISRP s’appuie sur l’identité du nom de point d’accès APN pour définir la règle de routage (MAPCON), ou sur le type de flux grâce aux informations récupérées par l’entité ANDSF en consultant le PCRF.

Dans le cas de la procédure IFOM, le PGW est le Home Agent. Il définit une adresse IPv6 permanente au mobile UE qui est l’adresse IP sur  le réseau 3GPP et une adresse IP temporaire (CoA : Care of Address) pour échanger avec le mobile UE via le réseau d’accès WiFi. Ainsi, lorsque l’entité ANDSF décide d’utiliser le réseau d’accès WiFi, il informe le PGW via un message PBU (Proxy Binding Update) et l’UE du changement d’adresse IP (stockée au niveau du PGW). Pour pouvoir différencier les flux, IFOM étend la notion de CoA à plusieurs adresses CoA dans une table étendue (binding cache) et une table d’association de flux (flow binding). La table d’association de flux est une table contenant autant d’entrée que de flux. Chaque entrée de la table est définie par un identifiant de flux, par une priorité, un champ de sélection de trafic (traffic selector) et un champ d’identification de la table de cache nommé BID : Binding Identification.

Pour faciliter la compréhension, j’ai remplacé l’adresse source par le nom de domaine.

Ainsi, lorsque le PGW reçoit un paquet provenant de l’adresse univ-poitiers.fr, il va utiliser l’adresse dans le cache (Binding cache) :

L’UE dispose ainsi de plusieurs adresses IPv4 ou IPv6 qui l’obtient lors de la procédure d’établissement de connexion (PDN Connexion) soit réalisé à travers le réseau 3GPP ou via le réseau d’accès WLAN.

 

Selon le type d’accès WiFi (trusted ou non trusted), le support data est établi :

  • Trusted : Directement entre la station de base AP WiFi à l’entité PGW grâce à l’algorithme d’authentification EAP-AKA ou EAP-SIM avec les informations contenues dans l’application USIM;
  • Non Trusted : Via une entité ePDG sous le contrôle de l’opérateur afin d’établir un tunnel sécurisé IPSEC pour le transport des données entre l’UE et l’EPC. L’entité ePDG est une passerelle pour sécuriser le réseau d’accès non 3GPP.

 

Dans la release R.13, trois autres mécanismes sont proposés :

  • LWIP : LTE / WLAN radio level integration with IPsec tunnel. Le mobile UE est connecté au SGW via un support 3GPP et un support chiffré non 3GPP. Le SGW commute le trafic vers chaque point d’accès.
  • LWA : La station de base eNB contrôle la station de base AP WiFi (Control Plane) et établit un tunnel Data (User Plane) pour échanger le trafic. Le LWA va donc séparer et séquencer les flux de données entre l’accès LTE e t l’accès WiFi. L’avantage de cette solution est la possibilité pour la station de base LTE d’ordonnancer les flux en fonction des conditions radios entre le mobile UE et chaque point d’accès (LTE et WiFi). Le mécanisme LWA est transparent pour l’utilisateur.
  • LAA : La station de base supporte le LTE mais exploite la bande radio WiFi. Le LAA s’appuie sur la procédure d’ajout d’établissement de support (bearer) du CA.

 

 

 

LTE et WiFi : Les attentes de la R.13 et R.14

WIFI et LTE
En général, on choisit un mode d’accès WiFi ou LTE pour accéder à Internet et pourtant, actuellement, les terminaux peuvent se connecter simultanément au WiFi pour toutes les sessions IP ne nécessitant pas de QoS, et au réseau LTE. L’accès au WiFI est souvent préférable pour l’utilisateur lorsqu’il peut profiter d’un débit plus élevé que par le LTE et préférable pour l’opérateur qui décharge ainsi ses stations de base pour un trafic vers des utilisateurs résidents.
Par contre, dans le cas ou le débit du WiFi est faible (soit ponctuellement à cause d’un encombrement ou factuellement car le point d’accès est loin du DSLAM), lorsque l’utilisateur configure son smartphone pour un accès WiFi, ce dernier utilisera cet accès même si la qualité d’expérience serait meilleure en LTE.
Afin d’aider l’UE à se connecter au meilleur réseau, et définir des règles de politiques en fonction des applications (temps réels ou non), l’opérateur déploie l’entité ANDSF (Access Network Discovery Selection Function) dans le cœur du réseau.
Dans la R.8, lorsque l’UE détecte la présence du WiFi, tout le trafic était routé via le point d’accès WiFi ou restait en 4G.
La R.10 propose un mécanisme (MAPCON : Multi Access PDN Connectivity) permettant plusieurs connexions IP sur le réseau WiFi et sur le réseau LTE.  Dans ce cas, l’entité ANDSF indique quel accès radio choisir pour différentes applications en fonction de règle de trafic se basant sur l’identification de l’APN, l’adresse IP et le port de destination. Les règles s’appellent ISRP (Inter System Routing Policies).
La R.11 apporte plus de flexibilité sur l’analyse des flux comme par exemple séparé des applications temps réel ou non qui utilisent le même port http, définir une règle en fonction du débit attendu, de la taille du fichier, …
La R.10 propose également une mobilité des flux : un flux IP sur un réseau d’accès peut sans coupure être dirigé vers un autre réseau d’acccès (DSMIPv6 : Dual Stack Mobile IPv6), cependant les opérateurs ont préféré utiliser la mobilité sur le protocole GTP, et la R.13  propose la solution de mobilité IFOM (IP Flow Mobility)
Dans la release R.12, le réseau LTE propose une procédure de sélection du réseau afin d’aider le smartphone à choisir le meilleur réseau d’accès. Dans cette release, le réseau configure un niveau de puissance du signal ce qui permet au dispositif de comparer la puissance reçue à ce niveau et ainsi déterminer sur quel réseau d’accès exécuter la session IP.
La R.12 propose aussi à l’UE de profiter d’une double connexion : Connexion LTE et connexion WiFI simultanée. Il s’agit d’aggrégation dans le cœur réseau et celle-ci s’effectue au niveau de l’entité PGW (PDN Gateway).
Deux scénarios d’agrégation existent :
  1. LWA : L’agrégation des accès LWA (LTE / WLAN Aggregation) s’effectue au niveau de la couche PDCP de l’eNb et le point d’accès WiFI
  2. LWIP L’agrégation des accès LWIP (LTE / WLAN radio level integration with IPsec tunnel) s’effectue au niveau du SGW et le point d’accès WiFi

La R.13 propose l’utilisation du spectre WiFi pour émettre des signaux LTE. L’opérateur déploie des eNb qui émettent dans la bande du WiFi pour faire de l’agrégation de porteuses (CA). Les eNb déployés ne doivent pas interférer avec les bornes WiFi, il est donc nécessaire de mettre en œuvre des mécanismes d’écoute avant émission (LBT/CCA) avant d’émettre. On parle de LAA – License Assisted Access.

  • La R.13 propose le LAA uniquement sur le DL
  • La R.14 propose le LAA sur le DL et UL sur 32 bandes de 20 MHz