Archives du mot-clef user plane

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

Posté le by - 3 172 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

 

Présentation de l’architecture CUPS : Control and Use Plane separation

Posté le by - 8 808 vues
Répondre

I) L’architecture du réseau mobile 4G

Le réseau de mobiles 2G/3G/4G est rappelé sur la figure 1 :

Figure 1 : Architecture des réseaux de  mobiles

Le réseau est composé de trois accès radios complémentaires (2G/3G/4G) et de deux trois cœurs réseaux, l’un dédié à la gestion des appels téléphoniques (exploitant la technique de commutation de circuit – MSC), le second dédié à la gestion des sessions Data (exploitant la technique de commutation de paquets) en 2.5G/3G (SGSN, GGSN), le troisième est le cœur réseau tout IP pour la 4G. Ce cœur réseau est représenté sur la figure 2.

Sur la figure 2 apparaît une nouvelle entité nommée TDF (Traffic Detection Function). Son rôle est d’analyser le trafic (DPI – Detection Packet Inspector) pour détecter des flux sous surveillance de l’opérateur afin de proposer des fonctions réseaux spécifiques aux flux détectés.

Figure 2 : Evolution de l’architecture réseau 4G (R11)

Lorsque l’utilisateur souhaite établir une session Data, l’entité MME transmet à l’entité SGW et à l’entité PGW (via le protocole GTP-C) la requête de création de support avec les caractéristiques associées au support (priorité, débit, temps réel, …)

Ainsi, les entités SGW et PGW gèrent à la fois le plan de contrôle et le plan de données utilisateurs.

II) L’approche SDN : CUPS (Control User Plane Separation)

Le CUPS propose de séparer en deux parties les entités SGW et PGW. Le contrôleur se nomme SGW-C et PGW-C et le plan de données deviennent les entités SGW-U et PGW-U.

Les règles de traitement de flux sont transmises du contrôleur aux entités du plan utilisateur par une session de règle SX. Cette session permet d’injecter les règles de traitement via le protocole PFCP

Figure 3 : La séparation du plan de contrôle et du plan utilisateur (CUPS)

L’entité fonctionnelle CP s’interface avec plusieurs entités fonctionnelles UP et une entité fonctionnelle UP peut être partagée par plusieurs entités fonctionnelles CP. Le contrôle des flux reste ancré sur un unique SGW-C mais différents SGW-U peuvent être choisis pour différentes connexion PDN. L’entité fonctionnelle CP (SGW-C et PGW-C) fait une sélection (via une recherche DNS évoluée) de l’entité UP en prenant en compte :

  • la localisation de l’entité UE afin de réduire la latence si besoin
  • la capacité de l’entité fonctionnelle UP de prendre en compte les caractéristiques de l’entité UE
  • La charge (overload) de l’entité SGW-U

Pour le dernier point, l’entité SGW-C doit supporter les caractéristiques Load Control transmises sur l’interface Sx.

Localisation de l’UE

Selon la définition, l’aire de service de l’entité SGW est un ensemble de zone de suivis (Tracking Area  TAI) entiers. A chaque mise à jour de localisation, l’entité UE reçoit de la part du MME une liste de zone de suivi (TA) correspondant à la position du mobile UE couvert par le SGW. Deux mobiles UE dans la même cellule peuvent avoir des listes de TA différentes pour ne pas solliciter des ressources réseaux sur les mêmes eNB.

Dans le cas de la séparation en plan de contrôle et plan utilisateur, le SGW-C n’a pas de lien physique avec les stations de base eNB mais communiquent avec les entités fonctionnels comme le MME, le SGSN, le PGW et le SeGW (Security Gateway pour la demande de création de connexions PDN. Le lien avec les eNB est maintenu via l’interface S1-U avec l’entité SGW-U. Dans le cas du CUPS, l’aire de service du SGW-U correspond à l’aire de service du SGW.

Ainsi, en cas de relocalisation sur une entité fonctionnelle SGW-U, il est préférable de trouver l’entité  SGW-U qui couvre la liste de TA (TA1, TA2, TA3) fournit par l’entité MME au mobile UE.

Capacité de l’entité fonctionnelle UP

Les entités fonctionnelles du plan utilisateur peuvent implémenter des fonctionnalités spécifiques qui ne seront utilisées que par des nombre limités d’entités UE comme par exemple, un type de service supportant les communications à haute latence (High Latency Communication HLcom). Pour ce type de service, le SGW-U implémente des fonctionnalités spécifiques de buffer.

Ainsi, en cas de relocalisation sur une entité SGW-U, il est préférable de trouver l’entité  SGW-U qui supporte les fonctionnalités attendues, comme par exemple un buffer étendu pour les communications à latences élévées.

Les conséquences du CUPS

L’avantage de contrôler plusieurs entités SGW-U par un seul SGW-C est de simplifier la gestion de la mobilité et mieux gérer l’équilibrage de charge. De plus, avec la virtualisation du SGW-U, il est possible d’allouer plus ou moins de ressources au SGW-U.

La zone de service du SGW-C peut être plus grande que la zone de service du SGW-U. Dans ce cas, le SGW-C est partitionné et chaque SGW-C gère un SGW-U. Pour assurer la compatibilité entre les différentes évolutions du standard, le MME considère le SGW-C comme un SGW classique. L’alignement de la zone de service du SGW-C partitionné avec le SGW-U assure que la liste de TAI fournie par le MME au SGW-C partitionné permet de sélectionner les SGW-U couvrant ces zones de suivis (la liste de TAI).

Si, pour un UE donné, le SGW-C a sélectionné plusieurs entités SGW-U dans ce cas, la zone de service des SGW-Us réunis couvrent au moins la zone de service du SGW-C.

III) SDN et PFCP : les protocoles d’injections de règles

L’entité de contrôle SGW-C et PGW-C injecte les règles de traitement de flux aux SGW-U et PGW-U afin de connaître les règles d’acheminements des paquets. L’injection de règles s’effectue via l’interface Sxa ou Sxb. Le contrôleur crée une session Sx avec la fonction du plan utilisateur via le protocole d’injection PFCP (Packet Forwarding Control Plane).

Les protocoles OpenFlow, Forces n’ont pas été retenu car ils ne répondaient pas aux critères recherchés :

  • facilité d’implémentation aux fonctions du plan de contrôle (SGW-U, PGW-U) ;
  • latence faible ;
  • gestion de toutes les caractéristiques existantes 3GPP
  • facilité d’étendre ou maintenir le protocole pour supporter les fonctions 3GPP
  • Compatibilités avec les standards 3GPP précédents

Ainsi, le protocole PFCP a été retenu et propose les propriétés suivantes :

  • Une association Sx doit être établie entre la fonction CP et la fonction UP avant d’établir une session Sx (injection de règles). La fonction CP et UP sont appelés Nœuds Sx.
  • Les procédures entre les nœuds Sx sont :
    • Procédure d’établissement, de mise à jour ou de libération de l’association Sx
    • Procédure vérifiant que la session Sx est active (alive)
    • Procédure de contrôle de charge et de congestion afin d’équilibrer la charge sur d’autres fonctions du plan utilisateur (SGW-U, PGW-U) et réduire la signalisation vers l’UP en cas de congestion.
  • La session Sx provisionne les règles d’acheminements de flux du contrôleur vers l’entité du plan utilisateur. La session Sx peut correspondre aux règles d’une connexion PDN pour un UE ou pour une session TDF
  • Procédure de gestion Sx PFD pour injecter les PFD (Packet Flow Descriptions) pour chaque application.