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.