Notions sur le SD-WAN et positionnement par rapport aux réseaux de mobiles

Posté le by - 1 825 vues
2

Dans l’article précédent, nous avons présenté le principe du Network Slicing, consistant à définir des règles d’acheminement pour un réseau particulier. Le Network Slicing s’appuie sur le principe de découpage de la fonction de contrôle et du plan utilisateur (SDN), la virtualisation des services réseaux (NFV) et du chaînage des services réseaux (SFC).

L’objectif du SD-WAN est aussi d’assurer une bonne connectivité aux outils cloud à travers internet (google suite pour le travail collaboratif, Microsoft 360, Amazon, azur …).  Le SD-WAN utilise donc les mêmes technologies vu précédemment (SDN, NFV, SFC) pour programmer rapidement l’accès d’un nouveau site  (en général il s’agit de connecter une entreprise) sur le réseau opérateur et offrir à ce dernier les différents services (cloud, FTP, tunnels entre site, …) demandés. On  parle  de  « zero touch  deployment », l’objectif  est  de  pouvoir provisionner (pousser automatiquement)  un  logiciel  et  une  configuration  sur  un  nouvel  équipement  SD-WAN  installé avec l’agilité réseau possible par ce type d’équipement (cf. la solution easy go network).

Le SD-WAN est une solution permettant à l’opérateur de déployer une solution de connectivité réseau pour tout nouveau site via des outils de provisionning réseau de haut niveau et d’assurer une interconnexion des différents sites de l’entreprise entre eux.

Ainsi, le SD-WAN permet à l’opérateur de fournir les règles d’acheminements au niveau de ces équipements pour gérer les applications critiques vers un réseau implémentant du MPLS et les applications non critiques vers des solutions de best-effort. L’opérateur peut ainsi, via une plateforme, provisionner et orchestrer ses équipements réseaux pour garantir à  l’entreprise l’accès à  Internet, l’accès à la téléphonie, l’accès à des services FTP sécurisés entre les différents sites de l’entreprise ou vers un Cloud et ceci quel que soit l’emplacement géographique du nouveau site par rapport aux autres sites de l’entreprises ou des solutions hébergées.

La notion de WAN dans l’approche SD-WAN indique que le pilotage du réseau est autorisé entre plusieurs opérateurs, afin qu’un entreprise dans un pays puisse installer une entité dans un autre pays et profiter des mêmes accès et services réseaux avec la même qualité. Ainsi, le SD-WAN supporte différents types de connectivités (MPLS, xDSL, FTTx, LTE, …).

Le SD-WAN est donc une solution de connectivité sur les différents types de réseau (fixe et mobile) ) travers le monde. Son application est ciblée sur les entreprises et sur les applicatifs utilisés par les entreprises à travers leur réseau de connectivité.

Les tranches de réseau : Network Slicing

Posté le by - 3 497 vues
Répondre

Cet article propose de faire une première synthèse des technologies abordées dans les articles précédents comme la virtualisation matérielle, la virtualisation des fonctions réseaux NFV, le chaînage des fonctions service (SFC) et l’approche de découpage du plan de données et du plan de contrôle (SDN).

La programmation des réseaux est une tendance émergente qui permet de transformer l’usage du réseau en s’appuyant sur des solutions logicielles. Si la virtualisation (cf  article : http://blogs.univ-poitiers.fr/f-launay/2018/01/23/virtualisation-du-reseau-epc-concept-nfvsdn/ )a permis de déployer des services réseaux facilement sous le contrôle d’un orchestrateur (cf article : http://blogs.univ-poitiers.fr/f-launay/2018/02/04/network-functions-virtualisation-nfv-pour-le-reseau-4g5g/), l’enchainement des fonctions de services (NVFFG ou SFC : article http://blogs.univ-poitiers.fr/f-launay/2018/01/28/le-sfc-service-function-chaining-mise-en-oeuvre-du-sdnnfv-sur-le-reseau-de-mobile-4g/) permet la flexibilité et l’adaptabilité du réseau en fonction de la demande.

Le chainage de fonction service s’appuie sur une approche SDN (cf article http://blogs.univ-poitiers.fr/f-launay/2018/01/15/principe-du-sdn-dans-une-architecture-reseau-classique/) pour programmer les besoins de services d’acheminements de flux et de contrôle de flux en proposant une abstraction de la couche réseau aux services applicatifs.

Grâce à ces différentes technologies (SDN, NFV, SFC), la programmation du réseau apporte une flexibilité et une modularité permettant de créer simultanément plusieurs réseaux logiques (virtual network) pilotés par la couche application via des API. Les descripteurs (NVFD) permettant de définir chaque besoin permettent ainsi de tailler un réseau à la demande et adapté au besoin (NFV MANO)

Ces différents réseaux logiques sont appelés des tranches de réseaux ou network slices et correspond à la mise en réseau de bout en bout entre un client UE et un service réseau (IoT, IP, IMS, …) en s’appuyant sur une infrastructure réseau virtuelle (SDN Overlay) ou physique (SDN). Chaque tranche de réseau est isolée des autres et gérée/contrôlée de manière indépendante (bac à sable grâce à la virtualisation et à la gestion NFV MANO) et s’adapte à la demande (easy go network).

Une tranche de réseau (network slice) est une collection de ressources, qui combinées ensemble de manière appropriées, permettent de créer un support réseau répondant aux exigences demandées. Les types de ressources pour le network slicing sont :

  • Fonction réseaux (NF : Network Function) : Bloc fonctionnel qui fournit une capacité réseau spécifique et réalise une fonction demandée. La fonction réseau est généralement une instance logicielle tournant sur une infrastructure physique mais, il peut aussi s’agir d’un équipement matériel dédie ou une combinaison des deux.
  • Infrastructure matérielle  dédiée ou partagée pouvant héberger les fonctions réseaux.

La figure 1 représente ainsi un exemple d’architecture du network slicing.

Figure 1 : L’architecture réseau en tranche

En proposant un réseau pour les différents besoins, le réseau opérateur supporte des besoins en terme de qualité de service (temps réel ou non, débit garanti ou non, bande passante, latence) très différent en fonction des besoins, comme le montre la figure 2.

Figure 2 : Approche horizontale des sous réseaux logiques de l’opérateur

I) Approche NFV

Orchestration

L’orchestration est un processus clé pour le network slicing qui s’appuie sur des descripteurs définies par exemple sur des accords de niveau de service SLA. L’orchestration est définie comme un processus de sélection optimale de ressources pour répondre entièrement aux demandes de service de chaque client. Le terme optimal réfère à l’optimisation de la politique de flux en fonction de l’abonnement du client (SLA) qui gouverne les choix du processus d’orchestration sur la sélection de ressources au niveau de l’infrastructure physique sur les POP.

Isolation

L’isolation est une exigence primordiale afin de pouvoir faire fonctionner en parallèle plusieurs tranches de réseau qui se partagent les mêmes ressources physique et les mêmes infrastructures.

L’isolation fait référence à :

  • Performance : Chaque tranche est définie par rapport à une exigence de service particulière et exprimées sous forme de KPI. L’isolation assure le respect du KPI si le service est accepté quel que soit la congestion ou les niveaux de performances des autres tranches
  • Sécurité et confidentialité : les fautes ou les attaques sur une tranche n’aura aucune incidence sur les autres tranches. De plus, chaque tranche met en œuvre ses propres fonctions de sécurités qui interdit entre autre à ce que des entités non autorisés aient un droit de lecture ou d’écriture sur la configuration d’une tranche de réseau.
  • Gestion : Chaque tranche est gérée de manière indépendante comme un réseau séparé.

II) Approche SDN

L’architecture SDN découple le plan de contrôle du plan de données permettant de configurer dynamiquement le plan d’acheminements des données comme un service à la demande du client. Cela répond aux attentes du network slicing qui a besoin de satisfaire à la demande à un large éventail de services de manière agile et à un coût optimal.

Concernant le réseau SDN, une ressource est une instance ou une entité qui peut être utilisé pour fournir un service en réponse aux demandes d’un client.  Le contrôleur est une entité centralisée qui planifie les ressources en fonction du contexte du client :

  • Contexte du client représente toutes les informations qui le contrôleur a besoin pour un client donné. Il contient :
    • un groupe de ressource : Le groupe de ressource est une vue de toutes les ressources que le contrôleur peut offrir pour répondre sur mesure à la demande du client. Le groupe de ressources est proposée par des API sur l’interface nord et correspond donc à une couche d’abstraction du réseau pour répondre au besoin du client ;
    • le support client contient les opérations et les règles de politique autorisées pour le client, ainsi que des informations relatives aux services demandés pour ajuster les actions entre la demande du client et le contrôleur.
  • Contexte serveur représente toutes les informations nécessaires au contrôleur pour interagir avec les ressources physiques accessibles via son interface sud.

Figure 3 : L’architecture SDN du network slicing

 

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

Posté le by - 2 660 vues
Répondre

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.

 

Le SFC – Service Function Chaining. Mise en oeuvre du SDN/NFV sur le réseau de mobiles 4G

Posté le by - 2 005 vues
Répondre

I) Rappel de l’approche SDN/NFV

Les réseaux traditionnels ont été conçus à partir d’équipements dédiés à une fonction réseau (routeurs, commutateurs, pare-feu, équilibrage de charge, accélérateur WAN, …). Ces équipements sont présents dans le réseau mobile afin d’interconnecter les entités du cœur réseau (EPC) comme le MME, le SGW et le PGW. Chaque équipement est programmé selon une interface logicielle définie par l’équipementier. Le réseau de bout en bout nécessite le déploiement d’un ensemble d’équipements réseaux hétérogènes programmés selon une architecture réseau figée. La modification de cette architecture (nécessaire par exemple pour augmenter la bande passante par l’ajout de nouveaux équipements ou par l’agrégation de lien, …) nécessite un investissement humain important et un investissement matériel

Dans le précédent article, nous avons présenté l’approche SDN qui permet d’augmenter la flexibilité et la disponibilité du réseau et d’accélérer le déploiement de nouvelles applications. Le SDN se définit comme une approche consistant à séparer le plan de contrôle du plan de données. Le plan de contrôle est géré par un équipement nommé contrôleur qui a pour but de piloter l’équipement réseau à travers lequel les données sont traitées. Les équipements réseaux constituent le plan de données.

Le premier avantage est de pouvoir exécuter une ou plusieurs règles de réseau sur un équipement standard (nommé COTS signifiant équipement sur l’étagère), autrement dit sans être dépendant de l’évolution logicielle de l’équipementier. Les règles à appliquer sur les flux de données sont fournies par le contrôleur (commutation, VLAN, routage, tag, ..). Lorsque le flux de données doit transiter par plusieurs équipements, il est nécessaire d’activer plusieurs contrôleurs. Les contrôleurs s’échangent des informations sur les interfaces est/ouest afin de piloter l’ensemble du réseau. On parle alors d’orchestration, le pilotage simultané de plusieurs entités réseau du plan de données en vue de gérer le trafic d’un flux de données.

Les contrôleurs ont donc en charge la gestion du réseau c’est à dire l’orchestration et l’automatisation des équipements réseau de différents fournisseurs (chaque fournisseur doit proposer un protocole de signalisation avec le contrôleur comme openflow par exemple).

Le SDN s’associe à une autre technologie, nommée Network Functions Virtualization (NFV). La virtualisation des fonctions réseaux NFV offre la capacité à virtualiser les fonctions du réseau telles que les pare-feu, les mécanismes d’équilibrage de charge et les accélérateurs WAN (cf. note en bas de page). Le contrôle centralisé qu’offre le SDN peut efficacement gérer et orchestrer les fonctions virtuelles qu’offre la NFV ;

Pour résumer, les objectifs du SDN-NFV sont :

  • améliorer l’efficacité opérationnelle
  • rendre plus flexible le réseau et un ajustement des besoins immédiat
  • automatiser la gestion
  • permettre le routage dynamique de trafic et le chaînage de fonctions service
  • réduire considérablement le temps de mise sur le marché des applications
  • provisionnement des fonctions réseaux et création agile de service
  • améliorer la satisfaction du client

II L’orientation du trafic (Traffic Steering)

II-1) Les fonctions service

Quand un mobile souhaite accéder au réseau IP, son flux est transmis vers la passerelle PGW ou GGSN. Cette passerelle réalise la fonction de translation d’adresse (NAT) en convertissant l’adresse privée attribuée au mobile en adresse publique et un réacheminement de port (Port Forwarding). L’opérateur peut également déployer un deuxième NAT derrière la passerelle, effectuant ainsi la fonction de Carrier Grade NAT (CGN ou NAT 444).

Cette fonction de NAT est obligatoire, il s’agit de convertir une adresse privée et un port en adresse public et un autre port, l’entité effectuant la translation d’adresse et de port sauvegarde dans une table de correspondance chaque translation privée/publique. Cette fonction service peut être virtualisée et réalisée sur n’importe quel serveur.

Afin de surveiller les flux et bloquer certains type de flux, l’opérateur peut souhaiter activer un service de détection de paquets (DPI : Deep Packet Inspectrion), lequel est associé à un pare-feu (firewall). Enfin, pour équilibrer les flux, il est également possible de rajouter un équilibrage de charge (load balancing), lequel peut orienter le trafic en fonction du port demandé ou du service demandé.

L’opérateur peut imposer, à tous les types de flux, d’être routés à travers ces différentes fonctions service. Les fonctions service classiques sont le NAT, le DPI, le Firewall, et le loadbalancing.

Mohammed Boucadair et David Binet défini [1] :

« Une fonction service (SF, Service Function) désigne une fonction embarquée dans un environnement. Elle peut être co-localisée avec d’autres fonctions service au sein du même équipement, lequel peut être un routeur, un serveur, un commutateur, etc. De telles fonctions SF incluent notamment les fonctions NAT, NAT64, pare-feu IPv4, pare-feu IPv6, TCP Optimizer, NPTv6 »

L’opérateur peut également proposer d’autres fonctions de services comme la détection et l’élimination de malware, le control parental, l’optimisation du cache, une accélération WAN, ou encore un optimisateur de flux vidéos.

Figure 1 :L’orientation statique de trafic

Sur la figure 1, on présente l’exemple ou tous les flux sur le port 80 sont chaînés à toutes les fonctions services d’une plate-forme VAS (Optimisation vidéo, cache, control parental et passerelle WAP) avant d’être acheminés au DPI et au pare-feu.

Dans cet article, on fera régulièrement référence à des fonctions services. Les fonctions services de l’opérateur sont :

  • des fonctions de protections du réseau de l’opérateur et des données du client comme le DPI, le pare-feu, les règles d’admissions (ACL), les opérations de chiffrement et déchiffrement, contrôle parental, détection de malware
  • des fonctions qui assurent le respect de la qualité d’expérience par des optimisations du trafic (PEP : Performance Enhancement Proxies, optimisation vidéos, optimisation TCP, accélérateur WAN, enrichissement d’entête HTTP…)
  • fonction NAPT et CG NAT

 

II-2) Chaînage de fonctions service statique

Afin d’éviter une surcharge des fonctions réseaux, l’opérateur défini un enchaînement de fonctions service selon le point d’accès APN demandé, c’est-à-dire un ensemble de fonctions service dans un ordre pré-établi.

L’orientation de flux par APN est une orientation dite statique qui s’applique à tous les clients. Il est évidemment possible d’invoquer une orientation de trafic et un enchaînement de fonctions service spécifique par client (gold, silver, bronze) et par application.

Figure 2 : L’orientation du trafic selon l’APN

II-3) Chaînage de fonctions service dynamique

L’opérateur peut choisir d’orienter le trafic en fonction du flux et des droits de l’usager. Pour ce faire, il doit s’appuyer sur un contrôleur centralisé qui analyse les types de flux (modèle hairpin).

Figure 3 : L’orientation de trafic via un controleur (Hairpinning)

Pour atteindre ces objectifs, le contrôleur doit interroger l’entité PCRF pour récupérer le profil et les services avec la QoS associée. Le choix d’orientation de trafic est basé sur la politique des qualités de services par flux (Policy-Based “per-flow” Steering) et le contrôleur effectue un choix selon les informations suivantes (une ou plusieurs informations) :

  • Politique de tarification de l’usager (gold, silver, bronze)
  • Type de réseau d’accès RAT (2G / 3G / 4G/ Wifi)
  • Localisation (roaming)
  • Problème de congestion de réseau
  • Type de dispositif (IMEI, HTTP User-Agent)
  • Type de contenu (HTTP Content-Type, DPI signature) …

Exemple (https://f5.com/portals/1/pdf/events/Traffic-Steering-PEM.pdf) :

Figure 4 a/b/c/d : Exemple d’orientation de trafic

III Chaînage de fonction services (SFC : Service Function Chaining)

Lors de la construction d’un support (bearer), la sélection de l’entité PGW s’effectue à partir du nom du point d’accès APN. Le chaînage de fonctions service statique, vu précédemment, est donc réalisé en ordonnant les fonctions service en sortie du PGW (cf .figure 2). Cependant, en récupérant des informations du PCRF, la fonction PCEF (située dans le PGW) peut réaliser la fonction d’orientation de trafic (traffic steering).

Le service de chaînage de fonctions service (SFC) est une architecture définit par l’IETF de manière à établir une liste ordonnée de fonctions service réseau.

Figure 5 : L’architecture SFC

Afin de rendre enchaînement de service plus flexible, le chaînage de fonctions service permet de définir une liste ordonnée de services réseaux (pour rappel, pare-feu, équilibrage de charge, optimisation WAN, …   ) et d’assembler ces services ensemble pour créer un enchaînement de services. L’architecture proposée par l’IETF est basée sur le principe du SDN. Le contrôleur SFC s’appuie sur une base de données pour connaitre les règles de politiques (table de politique SFC) pouvant être appliquées sur chaque flux et pour chaque abonné.

Pour réaliser cette fonction de chaînage, un classificateur de service (SFC Classifier) est une entité qui classe les flux de trafic en fonction des règles fournies par le contrôleur SFC. Les trames/paquets du flux sont ensuite marqués par un indicateur de chaînage de fonctions service (SFCI Service Function Chain Identifier) à l’intérieure d’une entête NSH (Network Service Header – RFC 8300). Le NSH est un protocole d’encapsulation et l’entête NSH est insérée comme metadata en plus de la data et l’extension d’entête http (http header extension) informe l’existence de la metadata.

En reprenant les définitions proposées dans la référence [1] :

« Un classificateur est une entité qui classe les paquets selon les chaînes SFC auxquels ils sont associés, conformément aux rêgles de classifications définies par le PDP – Policy Decision Point( et stockées dans une table de politique SFC. Les paquets sont ensuite marqués pour identifier la chaîne SFC à laquelle les paquets sont associés »

Il y a ainsi deux approches :

  • la première consiste à utiliser le SDN overlay (cf. article portant sur le SDN) et l’entête NSH est encapsulée dans le protocole VXLAN ;
  • la seconde approche s’appuie sur les équipements existants dans le réseau mobile, c’est donc celle que nous allons étudier. L’entête NSH est encapsulée dans le protocole GTP-U.

La 3GPP propose dans la release R.11 une nouvelle entité nommée  fonction de détection de trafic TDF (Trafic Detection Function). Cette fonction est destinée à analyser les requêtes issues du PGW en faisant de l’inspection de paquet (DPI) et à filtrer uniquement les applications selon des règles de détection d’application (ADC : Application Detection and Control) fournies par le PCRF via une requête Diameter.

La décision sur les règles ADC fournies par le PCRF est basée sur :

  • des informations fournies par le PCEF comme par exemple : Type de requête, des informations sur le client ou l’entité UE (IMSI ou IMEI), la localisation ;
  • des informations fournies par l’entité SPR tels que des informations sur la QoS pour l’abonnée (débit garanti, AMBR, …)

Le rôle premier de l’entité TDF est d’améliorer les fonctions de tarification de l’opérateur. La fonction TDF est intégrée dans le bloc PCC (Policy and Charging Control). Le TDF a pour rôle d’inspecter le trafic utilisateur à la sortie du PGW et d’assister les outils de taxation sur l’usage du réseau mobile effectué par le client. Ainsi, si pour un accès sur le port 80, l’utilisateur veut lancer une application OTT, via le TDF l’opérateur peut détecter cette application. Une fois l’application détectée, soit la fonction TDF réalise une mesure de la volumétrie consommée pour cette application (dans le sens montant et/ou descendant) spécifiquement, soit la fonction TDF informe l’entité PCRF afin que ce dernier réalise une politique de traitement pour cette application. La politique de traitement correspond à l’un des trois cas suivants :

  • Blocage de l’application : Gating;
  • Limitation de débit;
  • Redirection : Enchainement de fonctions service particulier

L’entité TDF, via l’analyse de la couche application, est en mesure de classifier plus finement le trafic issu du PGW afin de proposer des fonctions réseaux dédiées à chaque application (autrement dit pour appliques des fonctions de service spécifique).  L’entité TDF est donc un classificateur de service (SFC Classifier) et le PCRF est vu comme la table de politique de chaînage de fonctions service ( SFC Policy Table).

Figure 6 : L’architecture 3GPP et SFC

Le figure 6 met en avant deux domaines SFC (un domaine SFC est un réseau qui met en oeuvre le chaînage de fonctions service). L’entité TDF est un nœud de bordure sortant (SFC Egress Node) et l’entité IETF SFC Classifier est un nœud de bordure entant (SFC Ingress Node)

La norme 3GPP propose, dans la release R.13, une nouvelle entité TSSF (Traffic Steering Support Function). La fonction TSSF est extraite de l’entité TDF et elle est destinée à la classification du trafic afin de spécifier les fonctions de service à appliquer selon la classification de l’application.  Le TSSF met en œuvre l’orientation de trafic sur l’interface Gi (SGi) à partir des règles reçues par le PCRF. La principale différence est l’utilisation du protocole JSON sur l’interface St entre l’entité PCRF et l’entité TSSF qui permet d’échanger les règles de classification de flux plus simplement que l’interface Diameter entre l’entité PCRF et l’entité TDF. L’entité TSSF peut transmettre les métadatas reçus du PCRF sur l’interface Gi LAN.

Selon l’approche SDN, la fonction TSSF est un contrôleur SDN qui injecte ses règles à l’entité TDF.

Dans le prochain article, nous étudierons le chaînage de fonctions service (SFC) avec la virtualisation : Le VNFFG (Virtual Network Function Forwarding Graph).

Merci à Mohamed Boucadair et Christian Jacquenet d’avoir apporté des précisions sur l’article.

A lire :

[1] Mohamed Boucadair, David Binet, « Structuration dynamique de services- Introduction au chaînage de fonctions service (SFC) », Techniques de l’Ingénieur, publié le 10 octobre 2015.

Annexe : Protocoles d’échange entre le PCRF et le TDF sur l’interface Sd

Virtualisation du réseau EPC : Concept NFV/SDN

Posté le by - 2 936 vues
Répondre

La virtualisation du réseau permet  la montée rapide en charge de travail en mettant en route plusieurs machines virtuelles (VM) et les services réseaux associés (commutation logique, routage logique, pare-feu logique, équilibrage de charge logique, VPN logique, accélération WAN, compression d’entête, …) pour chaque charge de travail.

Les avantages de la virtualisation sont les suivants :

  • amélioration de l’efficacité des serveurs ;
  • gestion des charges de travail grâce au déploiement de VM et des services réseaux;
  • gain des performances du réseau et flexibilité;
    • déplacement de VM
    • équilibrage de charge
    • agilité de l’infrastructure réseau
    • Réduction du temps de déploiement : Time To Market
    • Chaînage de service en déployant les VMs  par application

I – La virtualisation du réseau

La virtualisation consiste à déployer plusieurs machines virtuelles sur un serveur physique. Afin de pouvoir partager les ressources matérielles (CPU, cartes réseaux, ….), il est nécessaire d’installer un logiciel de virtualisation appelé hyperviseur. Chaque machine virtuelle dispose de son propre système d’exploitation. Les pilotes et les périphériques sont stockés dans un domaine de l’hyperviseur accessible à chaque VM, les VMs utilisent des périphériques virtuels.

Un hyperviseur de type paravirtualisation nommé bare-metal ou type 1 s’exécute directement sur le serveur physique.

La gestion des VM et la sécurité est un point critique : les règles de pare-feu doivent être modifiées (rajoutées ou supprimées) à chaque fois qu’une nouvelle VM est rajoutée ou supprimée. Les premières solutions déployées pour les Datacenters permettent l’automatisation du provisionnement (provisionning) en fonction de l’ajout, la suppression ou la modification de VM.

Ainsi, lorsque le client exprime un besoin, par exemple mettre à jour des données sur son site web hébergé au niveau d’un Datacenter, cette charge de travail peut nécessiter la collecte et la fusion de données, des calculs, un stockage et une mise en forme spécifique des résultats à travers un tableur. L’hébergeur peut ainsi activer plusieurs VM (ou container) sur un seul serveur ou sur plusieurs serveurs. Dans ce cas il est nécessaire que les serveurs communiquent les uns avec les autres, on parle de communication est/ouest afin de répondre à la requête du client (communication nord/sud).

Au niveau du serveur physique, les VM sont isolées les unes des autres. L’isolation de VM non chaînées garantie qu’aucun échange ne peut s’effectuer entre les deux VM.  Cependant, l’échange de données entre les VMs est possible via un routage mais cela nécessite l’établissement de règles de sécurité : les règles du pare-feu entre chaque VM doivent être définies par rapport aux applications hébergées sur la VM. La micro-segmentation qui consiste à mettre en réseau plusieurs VM pour une charge de travail donnée peut être sécurisée par des pare-feux virtuels.

Dans le cas d’architecture réseau traditionnel, le trafic des charges de travail doit passer par un point de contrôle unique comme par exemple un pare-feu physique avec des règles établies pour tous les types d’application. Cette architecture, nommée hairpinning, créée un goulot d’étranglement ce qui rend donc cette architecture inefficace lorsque les charges de travail ne nécessitent pas les mêmes traitements. Son avantage est la stabilité du réseau et son prix.

Grace au déploiement du réseau virtuel :

  • la charge de travail est indépendante du réseau physique, c’est-à-dire de la configuration de VLAN, de la liste de contrôle d’accès, des règles de pare-feu. La micro-segmentation permet le transfert de données entre VMs isolées via un routage logiciel et un pare-feu logiciel ;
  • plusieurs charges de travail peuvent co-exister sur le même réseau physique et sur les mêmes entités, permet ainsi de partitionner virtuellement plusieurs services (slicing network).

L’automatisation permet de mettre en route ou d’éteindre l’ensemble des VM concernés et de provisionner les politiques adéquates des pare-feux pour chaque charge de travail.

L’orchestration permet de configurer toutes les charges de travail sur les serveurs physiques (planification des VMs en fonction des serveurs physiques existants et gestion des réseaux virtuels en fonction des capacités physiques réelles de la couche de transport).

II – Network Functions Virtualization

Jusqu’à présent, nous avons vu que la virtualisation permettaient de déplacer vers des serveurs banalisés :

  • les équipements de traitement de réseau (pare-feu, dpi, accélérateur WAN, équilibrage de charge, …)
  • les équipements de fonction réseau (commutateur, routeur)
  • les serveurs de stockage et serveur cache

Figure 1 : Virtualisation de fonctions réseaux

D’autres fonctions réseaux sont également virtualisables :

  • les entités du réseau mobiles : HSS, HLR, MME, SGW, PGW, SGSN, GGSN
  • les réseaux d’accès : BTS, BSC, NB, RNC, eNB

L’approche NFV a été initiée par l’organisme ETSI dans l’objectif de virtualiser les services et fonctions du réseau et de gérer les VMs en fonction des demandes des utilisateurs. Nous définirons l’architecture NFV dans un prochain article.

III – NFV/SDN

On distingue :

  • la virtualisation du réseau consistant à virtualiser sur des pools de ressources des applications (calcul, stockage et service réseau –DHCP – DNS – Parefeu logiciel – équilibrage de charge) et à gérer au niveau de l’hyperviseur les fonctions réseaux logiciel et la sécurité logicielle;
  • le NFV qui exploite les fonctions de la virtualisation en gérant et orchestrant les fonctions de virtualisation par un contrôleur. Le NFV est une architecture de virtualisation s’appuyant sur l’infrastructure physique (NFVI) sur laquelle tourne plusieurs VM. La gestion des ressources physiques du serveur (CPU, RAM, accès réseau, disques virtuels, switchs/routeurs virtuels, …), et la durée de vie des VMs sont contrôlés par une couche de gestion et d’orchestration NFV nommé MANO (Management and Orchestration) et qui est piloté par le système BSS/OSS de l’opérateur
  • le SDN consistant à séparer le plan de contrôle et le plan de données en centralisant au niveau d’un contrôleur l’intelligence de l’infrastructure matérielle. L’objectif est de provisionner automatiquement les fonctions du réseau de transport

 

Le concept de SDN (Software Defined Networking) repose sur un découplage entre le plan de commutation local aux équipements réseaux et le plan de contrôle. Le NFV peut s’appuyer sur le SDN en autorisant une gestion centralisée du réseau. La conséquence majeure est que le réseau devient programmable et peut être couplé aux applications métiers des usagers.

L’approche NFV propose d’extraire les fonctions réseaux des équipements dédiés et de les faire fonctionner dans un environnement virtualisé. Pour les opérateurs réseau, l’approche NFV constitue une opportunité de proposer des services de manière plus agile, capable de fonctionner à des échelles extrêmement importantes, mais surtout de manière plus rapide en exploitant les propriétés intrinsèques à la virtualisation. Ainsi, la virtualisation du réseau et de la sécurité permet de gérer des commutateurs virtuels et routeurs virtuels à la charge de l’hyperviseur, ainsi que la sécurité (pare-feu logique, VPN logique et équilibrage de charge logique).  On parle de réseau Overlay car les VMs et les services exploitent le réseau physique sous-jacent (cf.http://blogs.univ-poitiers.fr/f-launay/2018/01/15/principe-du-sdn-dans-une-architecture-reseau-classique/ ).

Ainsi, le contrôleur SDN est utilisé

  • pour programmer l’infrastructure réseau virtuel afin de définir les règles de routages et de sous-réseaux pouvant être utilisées pour interconnecter des fonctions réseaux virtualisés (VNF) : SDN Overlay ;
  • par une fonction réseau virtualisée afin de traduire la fonctionnalité réseau virtualisée attendue à la configuration physique du réseau. Le contrôleur SDN est donc une fonction VNF dans l’infrastructure NFV.

A titre d’exemple, l’un des avantages du SDN/NFV est le chaînage de service dynamique virtuel (traffic steering and chaining service) défini par une politique de flux. Lorsque l’utilisateur souhaite accéder à un service, le contrôleur SDN défini un ensemble de fonction réseaux à déployer. Le rôle du NFV est alors de gérer les VMs à mettre en œuvre et le contrôleur SDN gère le routage des flux.

Nous étudierons le SFC – Service Function Chaining dans le prochain article

Les deux technologies SDN/NFV réduisent ainsi l’OPEX (un seul environnement, automatisation des taches, …) et le CAPEX (remplacement du matériel devient une mise à jour logicielle).

Principe du SDN dans une architecture réseau classique

Posté le by - 4 824 vues
5

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 NSX, Midokura 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é

Posté le by - 1 090 vues
Répondre

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

Posté le by - 1 362 vues
Répondre

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 Gigabit

Posté le by - 2 059 vues
2

Entre la Release 8 qui normalise le LTE et la Release 15 qui a va standardiser le réseau 5G, le réseau LTE a connu trois phases d’évolution importante :

  • LTE – R8/R.9
  • LTE-Advanced aussi nommé la 4.5G : R10 à R12.
  • LTE-Advanced Pro ou 4.9 G : R13/R14.

Réseau opérateur : Accès radio

L’évolution du cœur radio du LTE-Advanced permet d’atteindre des performances allant à 1 Gb/s sur le lien radio. On retrouve ainsi cette norme sous le nom commercial LTE Gigabit. Le premier déploiement du LTE Gigabit a été lancé par Telstra en février 2017 avec Qualcomm et Ericsson mais Monaco a également déployé ce réseau.

Pour comprendre les performances atteintes, revenons sur le principe radio du LTE :

  • Bande spectrale : 20 MHz
  • Modulation DL : QPSK, 16 QAM, 64 QAM et 256 QAM
  • MIMO : Pas de MIMO, MIMO 2×2, MIMO 4×4.
  • Agrégation de porteuse (CA).

Dans un précédent article, nous avions estimé le débit total LTE à 100 Mbps sans MIMO et avec une modulation 64 QAM. L’estimation était biaisée car le trafic estimé prenait en compte à la fois les signaux de références et les canaux de contrôle PDCCH, ainsi que les canaux de synchronisation et de broadcast (PSS, SSS, BCCH). Prenant en compte que le PDSCH, le débit utile maximal était de 75 Mbps.

L’évolution de la modulation de 64 QAM à 256 QAM permet de transmettre 8 bits par symbole (256 QAM) au lieu de 6 bits par symbole (64 QAM), améliorant d’un rapport 4/3 le débit.

L’utilisation de 4 antennes en émission et en réception permet la transmission simultanée de 4 flux de données, soit une augmentation de débit 4 fois supérieure.

Au total, on arrive donc à un débit maximum de 400 Mbps.

L’agrégation de porteuses permet à l’opérateur de proposer plusieurs bandes LTE pour un seul UE. Le LTE a terme proposera, pour un seul UE, jusqu’à 5 bandes LTE. L’opérateur dispose de plusieurs bandes LTE. En France, les opérateurs disposent de bande de 10 MHz, 15 MHz ou 20 MHz sur les fréquences de 800 MHz, 2600 MHz et 1800 MHz. Prochainement, les opérateurs utiliseront les bandes de 700 MHz.

Avec 20 MHz de bande, le 4×4 MIMO et une modulation de 256 QAM, le débit utilisateur maximal est de 400 Mbps. Ainsi, avec 30 MHz de bandes supplémentaires sur 3 porteuses différences, les opérateurs en France pourront proposer du Gigabit LTE.

Pour résumer, l’opérateur doit disposer d’un minimum de 50 MHz de bande pour pouvoir commercialiser du Gigabit LTE sur 3 porteuses différentes.

Les terminaux : Catégorie de UE

Les terminaux doivent aussi supporter de telles fonctionnalités. La 3GPP a défini différentes catégories de terminaux, et seuls les terminaux de catégorie 16 vendus actuellement supportent de telles performances. Le premier terminal est le Samsung S8 avec la puce Exynos 8895.

A ce jour, on liste :

  • HTC U11
  • LG V30
  • Sony Xperia XZ1
  • Iphone X

L’IPhone 8 n’utilise pour l’instant que du MIMO 2×2, mais les prochains terminaux vendus en 2018 devraient (?) profiter de nouvelles puces pour exploiter le MIMO 4×4.

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

Posté le by - 4 804 vues
Répondre
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