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

Objectifs :

Comprendre :

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

Introduction

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

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

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

Figure 1 : Architecture NFV

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

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

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

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

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

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

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

L’architecture NFV est constituée de :

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

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

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

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

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

II-1) L’infrastructure NFV (NFVI)

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

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

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

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

Figure 3 : L’infrastructure et la para-virtualisation

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

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

Figure 4 : Le chainage de service réseaux virtuels

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

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

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

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

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

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

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

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

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

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

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

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

De plus, il est nécessaire :

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

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

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

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

 

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

 

Virtualisation du réseau EPC : Concept NFV/SDN

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 montant les VMs par utilisateur et 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 vers 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 associé garanti 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, 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 qui devient déporté, 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).

MTC : Le réseau M2M / IoT sur la 4G – 2ème partie

Au cours de l’article précédent, nous avions évoqué les évolutions du réseau 4G vers le MTC. Cette évolution est une brique de base pour le réseau 5G et les fonctionnalités que nous avions décrites sont les 4 suivantes :
• control plane CIoT EPS optimization
• user plane CIoT EPS optimization
• EMM-REGISTERED without PDN connection
• S1-U data transfer and header compression

(Je vais reprendre la notation de l’article précédent)
II-3-a) Control plane CIoT EPS optimisation
C-Plane CIoT EPS Optimization est une méthode destinée à encapsuler les données utilisateurs dans les messages du plan de contrôle. En évitant de mettre en place de la signalisation pour rétablir les bearer, cette méthode permet de réduire le nombre de message sur le plan de contrôle lorsque les données à transmettre sont de petites tailles et par conséquent, on réduit la bande utilisée et la consommation du dispositif.
Les fonctionnalités supportées par cette méthode sont :
• Transport de données utilisateurs (IP et Non IP)
• Point d’ancrage de la mobilité du dispositif
• Compression d’entête pour les flux IP
• Protection par intégrité et chiffrement de la Data transmise dans le plan de contrôle
• Interception légale.
Cette méthode s’appuie sur le MME, ce dernier est considéré comme un nœud de transfert de données et l’eNb est vu comme un relai :
• entre l’UE et le PGW (connectivité PDN : UE -> eNb -> MME -> SGW -> PGW) en utilisant les protocoles de signalisation (S1-AP et GTP-C)
• ou entre l’UE et l’entité SCEF (connectivité PDN : UE -> eNb -> MME -> SCEF).

Si l’UE a un stack IP, les données sont transmises en IP de l’UE vers le PGW.

Figure 5a : Control plane IP DATA

Si l’UE ne contient pas de stack IP (NIDD), les données sont transmises au MME via le protocole S1-AP et envoyées soit vers le PGW soit vers le SCEF. Lorsque l’UE fait une demande de connexion vers l’AS en non IP, l’UE indique l’APN  de passerelle. Le choix de la connectivité PDN entre le PGW et le SCEF est défini au niveau du HSS dans la donnée de souscription APN.

Le profil du device au niveau du HSS indique l’APN que doit utiliser le dispositif pour transmettre des données non IP. L’APN route les messages vers le PGW ou vers le SCEF.

On considère ici que l’APN renvoie vers le PGW.

Lorsque l’UE fait une demande d’attachement, il indique :

  • Qu’il souhaite une connection PDN non IP
  • Le réseau utilise l’APN fourni par l’UE ou l’APN contenu dans le profil de l’UE au niveau du HSS et transmis au MME
  • Le PGW donne à l’UE la taille maximale autorisée des paquets (qui peut etre de 128 octets)
  • Les paquets non IP sont transmis via le plan de contrôle par des messages NAS

 

Figure 5b : Control plane Non IP DATA vers le SGW

 

Connection non IP via le SCEF

Dans les deux cas, l’UE émet une demande de transmission de données via la procédure RRC SERVICE REQUEST en encapsulant le message ESM DATA TRANSPORT (message NAS entre l’UE et le MME via l’eNb en relais). Dans le cas précis ou l’UE ne contient pas de stack IP, il informe le MME qu’il souhaite établir une connexion PDN non IP.

Dans le cas de données entrantes :

  • Les données peuvent être bufferisées dans le SGW lequel transmet un message de notification « Downlink Data Notification Message » au C-SGN. Le C-SGN répond au SGW en indiquant le temps restant avant que le device soit joignable (PSM Mode). Cela permet au SGW d’étendre le temps pendant lequel le message sera conservé.
  • Les données peuvent être bufférisées dans le SCEF

 

II-3-b) User plane CIoT EPS optimisation

Dans le cas ou l’UE supporte l’optimisation sur le plan de données (User Plane CIoT EPS Optimization), il doit obligatoirement supporter la méthode S1-U Data transfer. Ainsi,  les données sont transmises via l’interface S1-U, c’est-à-dire entre l’eNb et le SGW.

L’optimisation User plane CIoT EPS optimisation est apportée par une amélioration du contrôle de bearer et par de nouveaux messages RRC ainsi que de nouveaux états RRC permettant un établissement de bearer plus rapide et plus efficace.

 

Les nouveaux états RRC sont : RRC-Suspend et RRC-Resume.

  • Procédure RRC Suspend. Cette procédure est activée par l’eNb permet de libérer le bearer radio entre l’eNb et le device, ainsi que le bearer S1 entre l’eNb et le SGW. Au niveau du SGW, cela supprime dans la table de contexte le numéro d’identifiant TEID du flux et l’adresse IP du eNb mais les autres informations sont conservées (QoS, clé de sécurité,…). Le MME conserve les informations de la connexion S1-AP et du bearer, place le device dans l’état ECM-Idle et répond à l’eNB de la libération du bearer par le message UE Context Suspend response. Le eNB conserve le contexte mais transmet à l’UE le message « RRC Connection Suspend ». Le device conserve les informations AS (clé de sécurité, information sur le flux de trafic) et se met en état ECM-Idle et RRC-Idle
  • Procédude RRC Resume permet de ré-activer les états qui ont été sauvegardés au niveau du device, de l’eNb et du MME. Dans un premier temps, le device récupère les informations de la couche AS et contacte l’eNB. Ce dernier accomplit une vérification de la sécurité pour ré-établir le bearer radio. L’eNB informe le MME par le message « UE Context Resume Request » de la ré-activation du bearer radio. Le MME récupère le profil du S1-AP et place le device dans l’état ECM-Connected. Il retourne vers l’eNb une confirmation « UE REsume Context Response » contenant l’adresse IP du SGW et le MME envoie l’adresse du eNb et le TEID du eNB (informations S1-AP conservées) vers le SGW.

Figure 6 : Messages RRC reprendre ou suspendre un contexte

 

Figure 7 : Call Flow

Pendant l’état RRC-Suspend, le device n’a plus de connexion radio. Il peut de plus être en mode eDRX, donc en cas de mobilité il ne détecte pas le changement d’eNB. Lorsque le device exécutera la procédure RRC Resume vers le nouvel eNb, celui-ci va demander à l’ancien eNb de lui transférer les informations AS. L’ancien eNb en profite pour supprimer le contexte (clé de sécurite, …). Le nouveau eNb crée un TEID, informe le MME lequel transfère le nouveau TEID et l’adresse du nouvel eNb vers le SGW.

De plus, cette méthode permet aussi de transférer des données non IP entre le SGW et le PGW

II-3-c) EMM-REGISTERED without PDN connection

Lors de la procédure d’attachement, l’UE informe le MME qu’il peut être dans l’état EMM-REGISTERED without PDN connection par le message “attachwithoutPDN Connectivity”. Classiquement, un smartphone (Human UE) émet dans la requête EMM d’attachement  un message ESM pour définir les caractéristiques du bearer par défaut. Dans le cas qui nous intéresse, le message ESM PDN CONNECTIVITY REQUEST est remplacé par le message ESM DUTY MESSAGE, l’UE reste connecté au réseau (EPS attached) même si toutes les connexions PDN ont été libérées. On se retrouve donc dans le cas 3G ou le contexte de l’UE n’existe pas au niveau des entités du réseau.

Remarque : « EMM-REGISTERED without PDN connection » à la même signification que « EPS attach without PDN connectivity

Lorsque le dispositif s’allume, avant d’émettre sa demande d’attachement, il lit le SIB2 transmis par l’eNb pour savoir vérifier la compatibilité de la cellule. Si le MME ne supporte pas l’état « EMM-REGISTERED without PDN connection » alors l’UE établie un bearer par défaut. Lorsque l’UE souhaitera émettre des données, un bearer EPS par défaut sera mis en place sauf si l’UE indique une méthode de transmission, par exemple SMS seulement, lors de son attachement.

II-3-d) S1-U data transfer and header compression

L’UE qui supporte le User Plane Optimisation EPS doit supporter le S1-U data transfer afin de transmettre les données sur le plan utilisateur.

On suppose maintenant que l’UE et le MME supporte à la fois la fonctionnalité S1-U data transfer et la fonctionnalité Control Plane EPS Optimization pour encapsuler la DATA entre le CN et l’UE dans des messages NAS

Lorsque le MME reçoit une requête de connexion PDN, le MME détermine la quantité de données à transmettre sur le lien UL et DL et décide ainsi si les données doivent être transmises sur le plan de contrôle ou sur le plan utilisateur. Il vérifie également si l’UE peut supporter

 

Figure 8 :  Etablissement du S1-U bearer pendant le transport de données dans le plan de Controle

1 – L’UE transmet/reçoit des données dans le plan de control (Control Plane CIoT EPS Optimisation).

2 –3 L’UE reçoit une réponse pour faire une demande d’établissement de bearer dans le plan utilisateur (User Plane Bearer). Dans ce cas, l’UE envoie un message NAS vers le MME. Le message est encapsulé dans un message RRC-Service Request émis au eNb, et un message S1-AP UL entre le eNb et MME. De manière classique, le message contient les informations suivantes :

  • NAS message
  • TAI+ECGI de la cellule sur laquelle l’UE est en communication
  • S-TMSI
  • CSG ID (si la cellule sur laquelle est connectée le mobile est une cellule CSG)
  • CSG access Mode

4 – Le MME fait le transfert des données transmises sur le plan de signalisation vers le bearer

Dans le prochain article, nous décrirons certaines procédures et protocoles

Panne chez SFR – Rappel d’une autre panne en 2012

Le 6 juillet 2012, Orange était affecté par une panne nationale, l’équioement en défaut avait été identifié : le HLR/HSS  lors de la mise à jour de ce dernier via Alcatel Lucent. Se référer à l’article : http://4glte.over-blog.com/article-panne-chez-orange-107869233.htm

Dans cet article, un ensemble d’hypothèse avait été faite pour lancer des pistes sur les pannes possible.

Aujourd’hui, jeudi 24 juillet, SFR fait façe à une panne nationale, les résultats de l’enquète incrime à nouveau la mise à jour du (d’un?) HLR par Alcatel Lucent,.

On peut alors se poser la question sur les procédures de mises à jour du HLR et pourquoi l’équipe Alcatel-Lucent est prise à défaut 2 ans près sur la mise à jour du HLR, d’autant plus  que chaque HLR dispose d’un système de backup comme solution de secours. C’est ce qui avait d’ailleurs été fait en 2012 par Orange : Le logiciel NG HLR (Lew Generation HLR) avait été mis à jour la veille. Vers 17h30, le réseau a rebasculer sur des bases non mises à jour mais sans effet et pourtant, il s’agissait bien de l’équipement défectueux. Le NG-HLR contient une base de données définissant le type d’abonnement de tous les clients de l’opérateur et qui contient aussi la localisation des abonnés. Ces éléments sont stockés dans la partie Back End du NG-HLR et mise à jour chaque fois qu’un client se déplace dans une nouvelle zone de localisation (LAC). La mémoire de cette base de données était saturée. Pour résoudre ce problème, il a néanmoins fallu d’un grande concertation entre Orange et Alcatal Lucentet un travail remarquable de toutes les équipes.

Malgré l’analogie entre ces deux pannes, est ce la même panne?

Orange avait publié une vidéo didactique présentant la panne : http://www.dailymotion.com/video/xs4bs8_resolution-de-l-incident-reseau-le-deroule-en-details_tech

A priori il y a deux ans la panne touchait tous les abonnés, hors l’opérateur possède plusieurs HLR. Pour SFR, un ensemble de clients sont affectés (les nouveaux clients 3G et 4G). Un HLR peut on être incriminé par contre en 2012, un seul HLR ne pouvait pas être responsable de la panne des 26 millions de clients. Une autre hypothèse était de supposer que le HLR en question était le V-HLR, un HLR virtualisé jouant le rôle d’administration et d’interconnexion des HLR. Mais, cela n’a pas été évoqué ni par Orange, ni par Alcatel.

Pour anecdote, le site Presse-citron terminait l’article en relatant la vidéo par cette conclusion « Reste à savoir si Orange et ses concurrents sauront tirer toutes les conséquences de ce dysfonctionnement pour faire en sorte que cela n’arrive plus. »

 

LTE-Advanced (4G+) sera prochainement commercialisé

LTE-Advanced

Le LTE-Advanced, dénommé aussi LTE-A, a été défini dans la R10 (démarré en octobre 2009) et prévoyait une augmentation du débit en utilisant plusieurs porteuses (agrégation de porteuses). En 2013, les équipementiers expérimentaient les premiers smartphones (cf article S4-LTE-A) et depuis quelques mois les opérateurs Français (notamment Bouygues, Orange et Free) expérimente le LTE-A.

L’idée à déjà été exploitée en 3G avec la dénomination Dual Carrier et s’appuie sur le fait que le débit dépend de la bande de fréquence utilisée : Plus la bande est importante, plus le débit est élevé.

Concernant le LTE, celui-ci exploite une bande de 20 MHz au maximum ce qui permet d’avoir un débit de 150 Mbit/s. En agrégeant 5 porteuses, la bande totale atteint 100 MHz, le débit peut donc être 5 fois plus élevé. En augmentant le nombre d’antennes (MIMO) au niveau de l’émetteur et du récepteur et en améliorant la modulation radio (jusqu’à 256 QAM) lorsque les conditions radios sont excellentes (smartphone proche de l’antenne), le débit peut dépasser le Gbps.

Le LTE-A est défini pour atteindre des débits descendants de 1 Gbps. Son successeur, Le LTE-B, selon Huawei pourrait atteindre plusieurs dizaines de Gbps.

Figure 1

Expérimentation en France de la 4G+

En février, Bouygues dégainait en annonçant le réseau 4G sur Bordeaux et Lyon à partir de Juin 2014 en profitant du re-farming pour avoir la bande suffisante. Orange répliquait en annonçant l’expérimentation du LTE-A sur Bordeaux (pour un débit de 300 Mbps et une bande de 2*20 MHz).

Pour profiter du LTE-A, il faudra un nouvel abonnement (en augmentant la volumétrie de votre abonnement) mais également un smartphone compatible (évolution logicielle)

Free a utilisé un drone pour expérimenter la couverture en 4G+. Cela rappelle l’expérimentation Globalstar et Iridium avec des satellites en basses altitudes (LEO), enfin lisez bien la note du bas d’article (et regardez la date de publication).

Image

Après ce coup de buzz de ZDnet (qui publie de très bons articles), retenez l’arrivée de la 4G+ pour Bouygues et Orange en Juin 2014, et SFR à partir de septembre.

Technologie de transport de la voix en 4G : CSFB (part 2)

Gestion de la mobilité entre le réeau 2G/3G et LTE

Comme nous l’avons entrevu dans le précédent article, un réseau doit en permanence savoir localiser un mobile afin de fournir les services à l’ayant droit. La procédure de localisation se nomme « Mobility Management », c’est-à-dire Gestion de la mobilité.

Pour terminer un appel via la fonction CS Fallback, le domain CS doit connaitre la position du mobile en se référant à la localisation fournie par le réseau LTE, c’est-à-dire en se basant sur l’aire d’enregistrement du mobile indiquée par le MME. Le MME a donc la charge d’informer la VLR de la zone de localisation du mobile sur le réseau 4G.

Le cœur de réseau 3G possède déjà la fonction permettant de gérer simultanément la mobilité sur le réseau en commutation de circuit (CS) et en commutation de paquets(PS), chaque mobile étant géré sur une zone nommée LA (Location Area) pour la partie CS et RA (Routage Area) pour la partie PS.

Afin de réduire le trafic de signalisation sur les réseaux mobiles 2G/3G et 4G, l’enregistrement de localisation du mobile sur le réseau SGSN par la VLR est ré-utilisé par la technologie CS FallBack : Concernant les informations de localisation du mobile sur le réseau 4G (TA : Tracking Area), le MSC/VLR exploite donc la même logique que pour le réseau PS en 3G, c’est-à-dire la VLR demande les données d’enregistrement du mobile sur le réseau 4G et les exploite de manière identiques aux données d’enregistrement de localisation fournies par les requêtes venant du SGSN.

 DoCoMo_MME1_database

Cela permet d’une part d’éviter une mise à jour trop fastidieuse des MSC pour prendre en compte les requêtes de localisation sur le réseau 4G pour la voix.

Il faut également se rappeler qu’un terminal sur le réseau 4G ne peut être sur le réseau 2G/3G en même temps. Ceci implique que le MME, qui contient la zone d’enregistrement du mobile sur le réseau LTE (TA) doit être en mesure d’identifier vers quel VLR il doit envoyer ses messages de gestion de mobilité. Le MME contient donc une base de données de localisation permettant d’avoir la correspondance entre la zone de localisation du réseau 4G (TA) avec la zone de localisation du mobile sur la VLR (LA). Cette base de données permet donc de déterminer quel MSC/VLR doit être contacté pour l’enregistrement de la localisation du mobile.

La figure 2 détaille l’échange d’information entre le MME et la VLR : La VLR a identifié le MME sur lequel était géré le mobile et le MME connait la VLR et le LA associé à la position du mobile si ce dernier est sur le réseau 3G CS. A l’inverse, la VLR connait l’équipement MME associé.

 

DoCoMo_MME_database

Figure 2 : Mise à jour des données de localization sur la VLR et le MME

 

Si nous reprenons la figure précédente, le call flow est le suivant :

  1. L’UE envoie une requête Tracking Area Update (TAU) vers le MME indiquant la position actuelle (TA) du mobile
  2. Le MME accomplie la mise à jour de la position du mobile vers le HSS via une procédure Location Update
  3. Le MME exploite la base de correspondance TA/LA pour identifier d’une part la zone de localisation LA du mobile correspondant au réseau de CS 2G/3G et la VLR correspondant, c’est-à-dire celui qui gère cette zone (LA). Via l’interface SGs, le MME envoie une requête LAU (Location Area Update) au MSC/VLR avec la valeur du LA correspondante.
  4. La VLR qui reçoit la demande de mise à jour de localisation enregistre la correspondance de l’identité du MME ayant fait la requête de mise à jour (comme c’est le cas avec le SGSN) et l’identité unique du mobile (IMSI). Cela permet au VLR de savoir sur quel MME (comme c’est le cas avec le SGSN) le UE est actuellement connecté, ce qui est nécessaire pour un appel à destination d’un mobile connecté sur le réseau 4G.
  5. La VLR lance une procédure d’enregistrement vers le HSS permettant à ce dernier de savoir sur quel VLR est maintenant enregistré le UE, et informe le MME du numéro TMSI affecté au mobile (Temporary Mobile Subscriber Identity).
  6. Le MME informe le mobile de son identité TMSI et de sa localisation LA.

Technologie de transport de la voix en 4G : CSFB

CSFB : Circuit Switched FallBack

Le réseau cœur déployé pour la 4G (nommé EPC : Evolved Packet Core) a été conçu pour s’interconnecter aux réseaux IP comme le LAN, la 3G, et évidemment le LTE.

Le principe du CS FallBack est assez simple : Lorsqu’un terminal mobile reçoit un appel téléphonique (Voix), il est informé via le message de Paging que le réseau auquel il doit accéder est le réseau de Commutation de Circuit (CS). Par conséquent, si le mobile était attaché sur le réseau 4G, il bascule vers le réseau 3G, et le mobile envoie une réponse d’acquittement vers le cœur de réseau en commutation de circuit (CS-Core). A partir de ce moment, toute la signalisation pour la session d’appel téléphonique est prise en charge par le réseau 3G. La figure 1 rappelle l’architecture des deux réseaux : CS sur le réseau 3G et PS sur le réseau 4G (EPC)

CSFB_DoCoMO

Figure 1 : Coeur Réseau 2G/3G et 4G

Pour que le Coeur de réseau 4G (EPC : Evolved Packet Core) soit compatible avec la technologie CSFB, il est nécessaire que ce dernier puisse communiquer avec le cœur de réseau en commutation de circuit CS-Core du réseau 2G/3G. En effet, le MME (mobility Management Entity) doit pouvoir contacter le MSC (Mobile Switch Center) et la VLR afin de donner procuration au réseau 2G/3G de la gestion de la mobilité. L’interface utilisée se nomme SG, et fait référence, en reprenant son rôle, à l’interface Gs existante entre le SGSN et le MSC dans le réseau 3G.

Lorsque l’appel est accepté, la technologie CSFB utilise à nouveau l’interface SG pour informer le réseau LTE de l’acceptation de l’appel. L’acquittement est donc transmis par le réseau en Commutation de Circuit (CS) vers le réseau LTE en empruntant l’interface SG.

Gestion de l’itinérance (Part 2) : la mobilité des UE

Part 2 : Gestion de la mobilité

II-1) – La signalisation


Le réseau GSM et 3G s’appuie sur l’architecture traditionnelle de la téléphonie commuté et exploite le protocole de signalisation SS7 (cf. http://mooc-ipad-formation.eu).
Ainsi, la gestion de la mobilité, la gestion de la localisation et de l’authentification étaient pris en charge par le protocole MAP (Mobile Application Part).

Ce protocole décrit les messages transmis entre les différents équipements du réseau de l’opérateur Home (HPLMN) et l’opérateur visité (VPLMN). Lors d’une première phase de migration vers l’IP, la signalisation SS7 initialement transportée sur des liens traditionnels TDM comme le E1/T1 est dorénavant encapsulée sur l’IP via le protocole SIGTRAN.

Mais, le réseau LTE n’utilise pas le protocole de signalisation SS7 : Diameter a été préféré et remplace le protocole MAP en supportant toutes ses fonctionnalités.

Le protocole DIAMETER a été adapté pour le LTE afin de gérer la gestion de mobilité des UE au sein du LTE mais le protocole doit également assurer l’interconnexion entre le LTE et les réseaux 2G/3G (DIAMETER to MAP). Pour échanger des données de signalisation, DIAMETER utilise des AVPs (Attribute Variable Pair) afin d’encapsuler les données en provenance d’applications reconnues.

Sur le tableau suivant, en guise d’exemple, nous donnons la traduction des messages MAP/DIAMETER.

diameter_map

II-2) L’architecture du réseau LTE

Pour comprendre la gestion de la mobilité sur le réseau LTE, il est nécessaire de revenir sur l’architecture du réseau en insistant (en rouge) sur la partie roaming (cf. article précédent).

LTE_roamingLes interfaces en rouges sont exploitées lors du roaming, nous allons les détailler pour plus de clarté :

  • Gestion de la mobilité :

L’interface S6a permet de transférer des données d’authentification et de localisation entre le MME et le HSS via Diameter afin d’autoriser ou non l’accès d’un utilisateur au réseau LTE.
En général, l’authentification est réalisée en respectant le protocole AAA lequel réalise trois fonctions : l’authentification, l’autorisation, et la traçabilité (en anglais : Authentication, Authorization, Accounting/Auditing)
L’interface S6d autorise les échanges d’informations relatives au protocole AAA entre le SGSN et HSS sur (over) DIAMETER.

  • Policy Control and Charging

L’interface S9 transfère la politique de contrôle de la QoS et les informations de taxation entre le HPCRF (Home Policy and Charging Rules Functionality) et le PCRF (Policy and Charging Rules Function) du V-PLMN toujours sur Diameter (cf. architecture SAE/LTE)
Le PCRF supervise les flux sur le réseau LTE : Il peut détecter les types de flux et de services (DPI : Deep packet Inspector) et met en relation la taxation adaptée (abonnement, calendrier) sur ce type de flux.

  • GTP Traffic

Le flux de données est transporté via un tunnel entre le SGW et le PGW sur l’interface S8. On retrouve le même fonctionnement en 2G et 3G, entre le SGSN et le GGSN.

II-3) Mise à jour de la localisation

Lorsqu’un utilisateur authentifié est en déplacement, le premier message reçu par le cœur de réseau est un message de Mise à Jour de la localisation (Location Update), quel que soit le protocole MAP ou DIAMETER utilisé.

Cependant, dans le cas

  • GSM MAP; le message ISD (Insert Subscriber Data) transporte le profil complet de l’abonné et si l’information complète ne peut être transmise dans un seul message ISD, le V_PLMN demande la transmission des informations complémentaires via d’autres messages ISD.

En 2G/3G, le protocole INAP/CAMEL est utilisé chaque fois qu’un utilisateur est en itinérance sur un autre réseau. LTE ne supporte pas le protocole CAMEL, il n’existe pas de traduction de message INAP vers le protocole DIAMETER

  • Pour DIAMETER, le LUA (Location Update Answer) transporte le profil de l’abonné. Ainsi, le DIAMETER ISD n’est utilisé que lorsque le H-PLMN demande un changement dans le profil de l’abonné.

Sur les figures ci-dessous, nous illustrons la partie Location Update via le protocole MAP (figure de gauche) et via le protocole Diameter (figure de droite)

Loc_Update_MAP_Diameter

II-4) Contrôle de la politique de QoS et facturation en temps réel

Dans le précédent article, nous avions vu deux techniques de routage de trafic, soit via le P-GW du réseau visité (Local Breakout) soit via le P-GW du réseau home (Home Routing).

Dans le premier cas, il est nécessaire de définir un accord pour échanger les informations de contrôle d’appel via l’interface Gy entre les deux PLMN. Ainsi, le PDN du V-PLMN peut interagir directement avec le système de tarification (charging system) du H-PLMN.

II-4.1) Home Routing

Basons-nous sur l’architecture du LTE, en focalisant notre attention sur les équipements impliqués lors du roaming. Sur la figure suivante, le V-PCRF communique avec le H-PCRF via l’interface S9 mais la facturation en temps réel (Real Time Charging) n’est pas transmise sur l’interface S9, mais via l’interface Gy selon le protocole DIAMETER RFC 3588.

Chaging_system_HPLMN

Concernant le roaming 2G/3G vers la 4G (on parle de roaming INTER-RAT), il faut savoir que le PCEF n’est pas pris en charge sur le réseau 2G/3G, ce qui pose un souci de QoS lors d’un roaming inter-RAT. En effet, dans le cas du réseau 2G ou 3G, le GGSN était dédié aux données et la QoS était spécifiée par la création d’un PDP context, la téléphonie était géré par le MSC, les SMS par le SMSC, et les services avancés par CAMEL.

II-4.2) Local Breakout

La procédure est légèrement différente, puisque c’est le PCEF du réseau visité qui transmet les informations de facturation en temps réel au H-PLMN. Les mêmes interfaces que précédemment sont utilisées.

Chaging_system_PLMNs

Gratuité de l’itinérance (Part 1): Bouygues dégaine en premier

Architecture du Roaming LTE

En début d’année, les opérateurs (Free, suivi de Bouygues puis Orange) avaient annoncé la gratuité du Roaming (itinérance) sur l’ensemble de l’Europe ou dans certains pays (Italie, Portugal pour Free), et/ou réservé à quelques abonnements. Ainsi, par exemple Bouygues avait annoncé le 22 janvier l’itinérance gratuite en Europe sur ses forfaits Sensation à partir du 24 février.

Nous allons montrer dans cet article comment la gratuité peut être effective sur le réseau 4G. Mais, comme l’objectif de toute entreprise, c’est de gagner de l’argent, nous aborderons donc dans cet article la partie facturation (billing) et le chargement d’information de tarification sur le type de service (charging).

Dans un premier temps, il faut revenir sur le concept de routage pour la LTE, le fonctionnement du LTE se diffère à ce niveau par rapport à la téléphonie 2G/3G. En effet, il existe deux méthodes de routage, le Home Routing et le Local breakout. A chaque méthode est associée des processus de tarification qui différent par conséquent par rapport à la 2G et 3G).

Nous allons donc naturellement commencer cet article par l’architecture de Roaming du LTE

I-1) Roaming LTE

Un réseau mobile déployé par un opérateur dans un pays se nomme PLMN (Public Land Mobile Network). Chaque utilisateur ayant souscrit à un opérateur utilise de préférence le réseau de cet opérateur, on parle de H-PLMN (Home PLMN). L’itinérance (roaming) permet à cet utilisateur de se déplacer en dehors du réseau de son opérateur et d’utiliser les ressources d’un autre opérateur (concurrent ou complémentaire). Cet opérateur est appelé V-PLMN (Visited PLMN).

Un utilisateur en itinérance est connecté à l’interface E-UTRAN, au MME et au S-GW du réseau LTE visité. Cependant le LTE/SAE permet de router les paquets vers un P-GW lequel appartient soit au réseau de l’opérateur visité (V-PLMN) soit à celui de son propre opérateur (H-PLMN), comme le montre la figure ci-dessous.

roaming

L’avantage du Home Routing est la capacité d’accéder aux services souscrits chez son opérateur (H-PLMN) même si le client (abonné) est sur un réseau visité. Le P-GW dans le réseau visité permet à l’abonné un accès local (Local Breakout) au réseau Internet via le réseau de l’opérateur visité.

L’interface entre le S-GW (Serving Gateway) et la passerelle P-GW permettant d’accéder au réseau de données (PDN : Packet Data Networks) est nommée S5 dans le cas du Local Breakout ou S8 pour le Home Routing.

I-2) LTE roaming Charging

La complexité des nouveaux modèles de taxations pour supporter l’itinérance en 4G sont plus nombreux que pour la 3G

  • Les cartes Pré-payées. Le standard CAMEL, qui permet l’accès par pré-payement aux services 3G n’est pas compatible avec la 4G. Ains, les accès au réseau PDN par des utilsateurs de cartes pré-payées doivent être obligatoirement routées vers le H-PLMN et ne peuvent donc pas être routés via le V-PLMN. Les opérateurs doivent donc mettre en place un flux de taxation spécialement dédié au clients de carte prépayé afin que ces derniers puissent accéder au PDN via leur P-GW
  • Les forfaits : La facturation s’appuie sur les mêmes tickets que le 3G.

Dans le cas de Local breakout, les opérateurs n’ont pas la même visibilité sur les activités des abonnés puisque la connexion de l’abonnée est gérée par le V-PLMN. Cependant, afin que l’opérateur Home puisse avoir des informations en temps réels (nécessaire entre autre pour les forfaits bloqués), il doit établir une interface DIAMETER entre son système de facturation et le P-GW du réseau visité.

Dans le cas d’un Local Breakout sur des services IMS, le réseau visité crée un CDR (Call Detail Records ) en provenance du S-GWS-Gateway(s). Cependant le CDR ne contient pas toutes les informations requises pour créer un TAP selon la version 3.12 pour le service utilisé (évènement ou session). En conséquence de quoi, les opérateurs doivent corréler les CDRs émis par leur proper réseau avec le CDR crée par l’IMS pour constituer un enregistrement TAP.

I-3) TAP 3.12

TAP : Transferred Account Procedure est le mécanisme permettant aux opérateurs d’échanger des informations de facturations des clients en roaming. TAP 3.12 correspond à la version 12 et la release 3, laquelle décrit la syntaxe des fichiers TAP transmis entre les opérateurs depuis le 1er mai 2013.

tap

Le TAP est transmis au HPLMN au plus tard 36 heures après la fin de la session.

Enquête UFC Que Choisir

Récemment,  UFC que choisir a mandaté une entreprise pour réaliser une campagne de mesure radio sur les débits atteints en 4G dans la capitale. L’étude vient de paraître, et je vous livre le résultat de l’enquête et mes impressions.

Enquête UFC : UFC porte plainte contre orange et SFR pour publicité mensongère

UFC que Choisir a récemment publié une enquête : Etude 4G, prouvant que le réseau 4G d’Orange et SFR ne couvre pas à 100% Paris IntraMuros.

Orange et SFR n’ont pas d’obligation légale à ce jour pour couvrir 100% de Paris en 4G, malheureusement ces 2 opérateurs communiquent sur une couverture totale comme le démontre les articles suivants

UFC que choisir porte plainte pour Publicité Mensongère car au vu des études 80% de Paris serait couvert par Orange et SFR, alors, qu’Orange, se félicitait le 9 septembre d’une couverture qui sera totale sur Paris fin septembre, mettant en avant une carte 4G.

Notez bien sur la courbe les zones sur Paris ou les villes devaient être couvertes à fin septembre.

Orange se différenciait alors de SFR, lequel 2 semaines plus tôt annonçait une couverture partielle :

  • Communiqué du 27 aout : « Fin août, SFR possède la couverture 4G parisienne la plus importante et couvrira l’intégralité de la capitale fin 2013 »

Cependant, SFR indique sur son site web une présence sur tous les arrondissements de Paris (http://assistance.sfr.fr/mobile_support/reseau/couverture-reseau/en-3233-62267).

Cependant cette animation Flash n’indique pas une couverture à 100%, SFR présente les villes couvertes en France ce qui peut provoquer une confusion.

Remise en cause des mesures effectuées par UFC

Le lendemain de la publication du rapport, ZDnet sorti un article mettant en cause les mesures réalisées. La remise en cause est légitime, d’une part nous n’avons que peu d’information sur le protocole de mesure sur lequel s’appuie les conclusions de l’UFC, et d’autre part la durée de l’expérimentation est relativement faible.

Cependant,  l’importance d’une telle étude nécessite une compétence technique, et d’ailleurs UFC a délégué ce travail à un prestataire professionnel. Je ne remettrais pas en cause pour ma part une défaillance technique, les mesures ont été réalisées de manière stricto-identique pour les 3 opérateurs et je ne suis personnellement pas plus surpris que cela par l’annonce de ces résultats.

Il existe plusieurs types de test, on peut tester le débit, la Qualité d’experience, le taux d’échec en termes de paquets, le handover et la continuité de la session ou des sessions, … Les tests doivent être répétés dans le temps car les performances du réseau dépendent du nombre de connexions simultanées. A une heure de fort trafic (BHCA), la disponibilité est moindre.

Quelques points à préciser dans ce rapport :

  • Le protocole de mesure.
    • Le prestataire a utilisé 3 SIII, est ce qu’un S3 est dédié par opérateur ?
    • Combien de fois le prestataire est il passé dans la même zone ?
    • Le parcours
      • Vitesse de déplacement

Des précisions au niveau du rapport Etude 4G pourraient être apportées sur les points suivants :

Nous lisons en page 6-7 la base du test :

« Un test d’accessibilité aux réseaux 4G correspond à une tentative de chargement de cette page qui est faite simultanément avec les trois appareils. Le test se clôt une fois que la page est chargée sur les trois appareils, ou si au bout d’une minute la page n’est pas chargée sur au moins l’un des appareils (Note4). Une fois le test clôt, un autre test se lance après un timer de 40 secondes. »

Ainsi, « L’inaccessibilité à un réseau 4G est caractérisée lorsqu’au cours d’un test le réseau 4G n’a pas pu être accroché, c’est-à-dire lorsque la page web n’a pas pu être chargée sur le réseau 4G. ».

La note 4 précise que « Cette dernière configuration n’a été constatée que dans 0,05 % des cas » ce qui semble confirmer que :

  • Les 3 téléphones sont utilisés pour tester un opérateur, 22 000 mesures ont donc été faites par opérateur.
  • 0,05% soit un test sur 2000 par conséquent 11 mesures sur les 22 000 effectuées par opérateurs, un téléphone sur 3 n’a pas réussi à charger sa page alors que les deux autres ont terminé.

Il y a une différence fondamentale entre l’échec et la réussite :

  • En cas de réussite, une deuxième mesure reprend au bout de 40 secondes.
  • En cas d’échec, il faut attendre 1m40 avant de faire une deuxième mesure.

En première lecture, ce constat serait à l’avantage de l’opérateur, la question sous-jacente est de combien de mètre s’est déplacé le véhicule entre ces deux mesures ?

Mes conclusions

Les opérateurs se livrent à une course Marketing de la 4G, accélérant le déploiement d’antenne, mais pas les tests qui vont avec.

Dans l’article ZDNet, on pouvait lire une remarque concernant le nombre d’antennes :

« sur ces résultats, en particulier pour la zone Sud-Ouest de Paris, qui dispose d’un nombre de sites 4G identique aux autres arrondissements. »

Le nombre d’antennes n’est pas un gage de couverture. Il faut se préoccuper :

  • De la puissance d’émission de chaque antenne
  • Du tiltage des antennes
  • De la position de chaque antenne permettant un taux de recouvrement suffisant.

L’opérateur se préoccupe en premier lieu de la capacité d’une antenne et non de sa couverture. La capacité permet de gérer un certain nombre d’utilisateurs simultanément. Or dans une zone très dense, il faut rajouter des antennes et réduire ensuite la puissance d’émission de chaque antenne pour réduire sa couverture.

Partant sur le principe que le prestataire UFC a réalisé des tests dans les mêmes conditions pour les 3 opérateurs, mettant néanmoins en cause la notion de répétabilités des tests, j’en conclue que SFR et Orange n’ont pas déployé le réseau sur Paris à 100% en 4G. Mais 100% de Paris semble être couverte en Très haut débit, c’est-à-dire que la H+ doit couvrir les zones ou la 4G est encore défaillante. N’oublions pas qu’en 2012, Orange et SFR ont investi dans la H+ avant l’arrivée de la 4G.

Je vais terminer cet article sur la polémique du débit. L’ARCEP, le 5 septembre 2013, a classifié comme Très Haut Débit, un débit de 30 Mbps.

Quant au 150 Mbits par seconde, seul orange est en mesure de le fournir actuellement sur les bandes qui lui sont allouées car Orange dispose de 30 MHz de bande, 20 MHz actuellement permettent d’atteindre un débit de 100 Mbits, un débit théorique rappelons le. Cependant, prochainement avec 20 MHz de bande, les opérateurs pourront fournir un débit de 150 Mbits, il faut une évolution au niveau des antennes et des téléphones compatibles…