E2E Network Slicing : le découpage du réseau de bout en bout (Partie 3)

Voici la troisième et dernière partie

E2E Network Slicing : le découpage du réseau de bout en bout (Partie 1)

E2E Network Slicing : le découpage du réseau de bout en bout (Partie 2)

IV) La virtualisation de l’accès radio

IV-1) Description des fonctionnalités de la station de base

Le découpage du réseau est une tranche de bout en bout comme le montre la figure 13.

Figure 13 : Le découpage du réseau de bout en bout.

Les fonctionnalités réseaux sont partagées au niveau du cœur de réseau (SNI CN) et de l’accès radioélectrique (SNI RAN). Nous allons maintenant nous intéresser au découpage sur l’infrastructure radioélectrique et à la gestion de ressources.

Une station de base 5G réalise les tâches suivantes :

  • fonction RRM pour la gestion de ressources radioélectriques : Contrôle du support radioélectrique, contrôle d’admission radioélectrique, contrôle de la mobilité pour les mobiles connectés, allocation dynamique des ressources radioélectriques dans le sens montant et descendant (ordonnancement) ;
  • compression d’entêtes IP, chiffrement et intégrité des données ;
  • sélection de la fonction AMF lors de l’attachement du mobile ;
  • routage des données du plan de transport dans un tunnel ;
  • routage des informations de signalisation vers la fonction AMF ;
  • établissement et libération de la connexion ;
  • mesures radioélectriques et configuration du rapport de mesures demandé au mobile ;
  • ordonnancement et transmission des informations de diffusions SIB (System Information Block);
  • marquage des paquets dans le sens montant (étiquettes DSCP) ;
  • gestion des sessions ;
  • support du découpage en tranche de réseaux ;
  • gestion de la QoS et correspondance entre les flux IP provenant du plan de transport UPF en support radioélectrique ;
  • partage de l’accès radioélectrique ;
  • gestion de la double connectivité ;
  • interfonctionnement entre les fonctions 5G-NR et 4G-LTE.

Pour réaliser ces tâches, la station de base s’appuie sur la pile protocolaire présentée sur la figure 14. La station de base 5G peut également se décomposer en deux unités : une unité centralisée gNB-CU et une unité distribuée gNB-DU).

Figure 14 : Présentation de la pile protocolaire de la station de base 5G

La spécification 3GPP propose le découpage du plan de contrôle (RRC) et du plan de trafic IP (SDAP). La signalisation et les données sont gérées par la couche de niveau 2 décomposée en trois sous-couches : PDCP, RLC, MAC et par la couche physique.

La couche physique réalise la modulation et la démodulation de données des signaux sur l’interface radioélectriques.

Le rôle de la sous-couche MAC est de faire :

  • la correspondance entre les canaux logiques et les canaux de transport ;
  • le multiplexage/démultiplexage des unités de données MAC SDU en provenance d’un canal logique ou de plusieurs canaux de transport (TB) ou de plusieurs canaux de transport à destination des canaux logiques ;
  • la correction d’erreur rapide HARQ ;
  • la gestion de priorité entre les mobiles ;
  • la gestion de priorité sur les canaux logiques pour un mobile.

Le rôle de la sous-couche RLC est de faire :

  • le transfert des paquets PDU issu de la couche supérieure ;
  • une numérotation des séquences RLC pour le mode sans acquittement UM et avec acquittement AM;
  • la correction d’erreur ;
  • la segmentation/re-segmentation des données ;
  • la détection d’erreur (pour le mode AM).

Le rôle de la sous-couche PDCP est de faire pour le plan utilisateur :

  • la numérotation de séquence ;
  • la compression et décompression d’entête ;
  • le transfert des données ;
  • la détection des paquets dupliqués et la mise en ordre ;
  • le routage des bearer PDCP PDU dans le cas de la double connectivité ;
  • le chiffrement/déchiffrement et la protection d’intégrité;
  • le rétablissement des données PDCP et la récupération des données pour le mode RLC ;
  • la duplication des paquets PDCP PDU.

Le rôle de la sous-couche SDAP est :

  • la correspondance entre la QoS d’un flux IP et le support radioélectrique ;
  • le marquage de l’identité de la QoS sur les paquets UL.

Le partage de la station de base gNB en deux unités gNB-DU et gNB-CU est spécifié par le standard 3GPP lequel propose différentes options. Toutefois actuellement le gNB reste mono-constructeur même en cas de découpage en deux sous unités gNB-CU et gNB-DU.

Les différentes options sont proposées sur la figure 15 :

Figure 15 : Le découpage des fonctions du gNB

A titre d’exemple, on pourrait imaginer le découpage suivant :

Figure 16 : Un découpage du gNB

Actuellement (standard R.15) l’unité gNB-CU est composée de la sous-couche RRC/SDAP et PDCP, l’unité gNB-DU est composée des sous-couches RLC et MAC et physique. Mais les autres partages de fonctions décrites sur la figure 11 peuvent virtuellement être mise en œuvre.

La couche physique a pour rôle de transférer le signal issu de la couche MAC (le bloc de transport) en un signal RF et inversement récupérer un signal RF pour l’envoyer vers la couche MAC.

La couche physique se compose de plusieurs fonctions :

  • code détecteur d’erreurs CRC ;
  • code correcteur d’erreur et adaptation de débit ;
  • embrouillage ;
  • modulation ;
  • affectation des symboles par sous-couches antennaires ;
  • précodage numérique ;
  • affectation des signaux et canaux sur chaque élément de ressources ;
  • transformée de Fourier Discrète et insertion d’un préfixe cyclique ;
  • chaîne RF (convertisseur CNA, conversion RF, amplification).

Les signal RF est envoyé à l’antenne.

La tête radioélectrique déportée (RRH) correspond à la chaîne RF. Pour la 4G, l’entité eNB se composait de deux parties : BBU et RRH. Cette option est maintenue pour la 5G (option 8) toutefois, le débit du bus série CPRI (Common Public Radio Interface) qui transporte les symboles I/Q est d’autant plus élevé que :

  • la bande de fréquence est importante (cellule principale et secondaire en cas d’agrégation de porteuses) ;
  • le nombre d’antennes est élevé (FD-MIMO ou Massive MIMO).

Pour réduire le débit entre le gNB-DU et la tête radioélectrique déportée, il est également prévu de proposer un découpage au niveau de la couche physique différent (figure 17) :

Figure 17 : Les options de décomposition de la station de base gNB

Le transport des données sur les interfaces optionnelles est normalisé par le protocole eCPRI  (evolved Common Public Radio Interface) et est véhiculé sur une fibre optique.

La gestion des ressources radioélectrique (protocole RRM) est réalisée par la station de base gNB. La gestion des ressources radioélectrique a pour objectif :

  • de gérer le spectre de fréquence : cette fonction décide comment les ressources spectrales sont réparties en porteuses 5G-NR et comment ces porteuses sont allouées aux différents site;
  • de gérer l’interférences entre cellules (mécanisme ICIC). Dans la continuité de la gestion du spectre, le mécanisme ICIC impose une puissance limitée sur un ensemble de sous-porteuses afin d’éviter les interférences avec un point de transmission voisin utilisant les mêmes sous-porteuses ;
  • d’ordonnancer les paquets : cette fonction décide, pour chaque porteuse 5G-NR affectée à une cellule, quelles sont les ressources bloc (RB) disponibles pour transférer les paquets sur chaque bearer radioélectrique établi ;
  • de réaliser les fonctions liées à la prise en charge radioélectrique tels que le contrôle de bearer, le contrôle d’admission radioélectrique, le contrôle de la mobilité (lorsque le mobile est en mode connecté).

L’implémentation logicielle de la partie RRM n’est pas du ressort de la 3GPP, c’est pour cela qu’il n’est pas envisageable d’avoir une unité gNB-CU et gNB-DU de deux équipementiers différents.

IV-2) La virtualisation de la station de base : C-RAN

Le point de départ consiste à respecter le contrat SLA et d’apporter la QoE défini par le contrat. Ce contrat peut concerner la QoS pour un utilisateur. Toutefois, la virtualisation et l’isolation des slices permet à l’opérateur de louer les services de la station de base à des opérateurs virtuels ou à des entreprises.

Pour des entreprises privées, cela revient à mettre en place un DAS et la station de base est uniquement dédiée à l’entreprise.

Pour les opérateurs, il est possible de faire un partage de l’accès radioélectrique (Shared RAN) connecté directement au cœur réseau des différents opérateurs (MOCN : Multi-operator Core Network).

Jusqu’à présent, les stations de base étaient des entités physiques (PNF) installées au niveau de l’antenne. Ainsi, la gestion du spectre (contrôle d’admission, séquencement), la gestion des acquittements (HARQ/ARQ), le chiffrement étaient réalisés localement.

Dans le cas où l’entité est physique (PNF) alors les ressources matérielles de la station de base (CPU/RAM/Carte réseaux) doivent gérer les différents services (eMBB/mMTC pour la 4G).

Le découpage de la station de base en deux unités permet de mieux allouer les ressources matérielles aux fonctions protocolaires de la station de base. Excepté la tête radioélectrique déportée, les fonctionnalités de la station de base gNB-CU et gNB-DU sont toutes virtualisables.

La virtualisation est demandée par le support opérationnel OSS/BSS qui utilise le gabarit NST du slice pour imposer à l’orchestrateur (MANO ou ONAP) de gérer le cycle de vie dans l’instance virtuelle.

L’alliance O-RAN  portée par les opérateurs propose une normalisation (figure 18) sur la gestion du slice RAN. L’orchestrateur dispose d’un contrôleur SDN nommé RIC non-RT (RAN Intelligent Controller non Real Time) permettant de configurer le déploiement, la mise en échelle ou le relâchement de la sous-instance radioélectrique par un découplage du plan de contrôle et du plan utilisateur.

Figure 18 : Le fonctionnement du Cloud-RAN

La virtualisation du RAN est réalisée en suivant le protocole NFV de l’ETSI. Nous n’aborderons pas ici les solutions OpenSource existantes (OPNFV, OpenStack, QEMU, …).

Pour l’alliance O-RAN,

  • Le RIC non-RT a pour objectif le respect du SLA et de la supervision en gérant le déploiement, la mise à l’échelle ou la libération des sous-couches de virtualisations radioélectrique SNI.
  • Le contrôleur RIC near RT gère les ressources radioélectrique (fonctionnalités RRM) en proposant un découpage fonctionnel entre l’unité gNB-CU et les entités gNB-DU.

La configuration des gNB permet de définir la liste des services S-NSSAI supportés par le gNB par une procédure de configuration du paramétrage des stations de base (cf. figure 8). Cette phase de provisionning est gérée au moment de la création du slice radioélectrique (figure 19).

Figure 19 : La configuration des slices supportées par les gNB

Lorsque le gNB s’active, il informe la fonction AMF de l’ensemble des slices supportés avec la localisation TAC correspondante. Si la station de base est connectée à plusieurs fonctions AMF, alors elle transmet l’information à toutes les fonctions AMF. Chaque fonction AMF l’informe en retour des services S-NSSAIs supportés par la fonction AMF.

Au niveau du gNB, le découpage entre le gNB-DU et le gNB-CU est ordonné au niveau du contrôleur RIC-near RT. Un descripteur de slice permet de définir les fonctions gérées au niveau de chaque unité (gNB-CU et gNB-DU).

Une entité gNB peut supporter plusieurs slices. Le découpage entre gNB-CU et le gNB-DU est identique pour chaque slice par contre les fonctions utilisées sur chaque sous-couches peuvent être communes ou spécifiques. Par exemple, il est possible de définir un slice pour les terminaux statiques et de désactiver la fonction handover pour ce slice.

Figure 20 : La mise en place de plusieurs slices au niveau d’un gNB

On définit ainsi le comportement attendu pour chaque sous-couche et lorsque le mobile fera une demande de connexion radioélectrique, le message RRC transmis du mobile à l’entité gNB-CU contiendra l’information S-NSSAI du slice demandé. Ainsi, lors de la connexion radioélectrique, l’entité gNB créera un context UE avec le numéro de slice correspondant (figure 21).

 

Figure 21 : L’identification du slice

IV-3) Exemple de C-RAN

L’objectif de la virtualisation consiste à répartir la charge sur différents serveurs en fonction de la QoE demandée.  Ainsi :

  • Pour les terminaux IoT, la station de base devant couvrir une superficie sur laquelle on peut avoir 1 million d’IoT par km2 (ce chiffre est la limite haute du standard), les ressources matérielles de la station de base peuvent rapidement saturer si, il y a un réveil en cascade des terminaux IoT, ou si plusieurs terminaux sont dans le mode RRC_Inactive, ou … Il est donc recommandé de déporter les fonctions suivantes vers un DataCenter (DC) :
    • contrôle RRC de chaque terminal IoT ;
    • chiffrement/déchiffrement ;
    • segmentation, contrôle d’erreur ARQ ;
    • multiplexage, contrôle d’erreur HARQ.

En contrepartie, le fait de déporter les calculs vers le DataCenter va avoir comme incidence d’augmenter la latence, ce qui n’a aucune importante pour les terminaux IoT HLCom (High Latency Communication). En effet, la QoS pour le service IoT n’est pas la latence mais la problématique est la gestion d’un nombre très élevé de terminaux (mMTC :massive MTC).

  • Pour les smartphones eMBB, la station de base doit offrir des services avec une latence d’environ 10 ms pour le plan de trafic et 100 ms pour le plan de transport. On peut donc envisager un découpage avec l’unité gNB-CU au niveau du point de présence (PoP) sur lequel l’opérateur déploie des lames de serveurs (mini Data Center nommé MEC – Mobile Edge Computing). Ainsi :
    • l’entité gNB-CU gère la couche RRC/PDCP haute ;
    • l’entité gNB-DU au niveau de la station de base gère les sous-couches PDCP base, RLC, MAC et physique.
  • Pour les communications critiques (URLLC et V2X), afin de réduire la latence, tout le traitement du gNB s’effectue au niveau local (près de l’antenne).

Toutefois, le mobile n’est pris en charge que par une seule paire gNB-CU et gNB-DU, le choix du gNB-CU s’effectue par rapport aux paramétrages radioélectrique du mobile sur le module USIM (PLMN), c’est-à-dire par la sélection d’un PLMN.

La tranche de réseau par PLMN est identifiée par un indicateur de slice Slide ID NSSAI. Les slices gérés par le PLMN sont stockés au niveau du gNB-CU.

L’exemple (figure 22) ci-dessous est extraite de l’article [ferrus] :

Figure 22 : Déploiement 5G-NR

La figure présente 2 PLMN différents, PLMN#A et PLMN#B.

Le PLMN#A est géré par une entité gNB monolithique déployée sur un MEC du PoP #1 puisqu’on est sur une infrastructure légère (LW NFVI)

Le PLMN#B est géré par une unité gNB-CU qui est située sur le DC du PoP #2. L’unité gNB-CU est connectée à deux unités gNB-DU, une située sur le MEC PoP#1 et l’autre sur le MEC #PoP3.

Lorsque le mobile s’allume, il cherche le PLMN correspondant, soit le PLMN#A soit PLMN#B.

On peut supposer que le PLMN#A est dédié pour l’IoT sur une bande de fréquences à 700 MHz (@RF Carrier#1), la zone de couverture est étendue (NR Cell#1). Lorsque le terminal s’allume, il scanne une fréquence basse et cherche le PLMN #A. Une fois synchronisé, il fait une demande de connexion radioélectrique avec le gNB#1.

Le PLMN#B exploite une bande de fréquence @RF Carrier#2 sur deux cellules NR Cell#2 et NR Cell#3. Lorsque le smartphone s’allume, il scanne la bande de fréquences et une fois synchronisée il fait une demande de connexion auprès du gNB-CU. Selon sa position, il fait la demande auprès du gNB-DU du PoP#1 ou du PoP#3.

Conclusion

Le découpage du réseau en tranche est constitué de deux sous instances virtuelles (NSI), une sous-instance au niveau du cœur de réseau et une sous-instance au niveau de l’accès radioélectrique.

Le mobile est enregistré sur une seule fonction AMF mais peut activer plusieurs slice simultanément. Au niveau accès radioélectrique, le mobile est géré par un unique gNB.

La figure 23 est issue d’une documentation NoKia et réprésente le découpage du réseau 5G.

La figure 24 est issu d’une documentation Samsung et réprésente le découpage du réseau, l’orchestration de bout en bout. Ce document reprend donc l’ensemble des fonctionnalités et le découpage du réseau décrit dans cet article.

Figure 23 : Un découpage de réseau de bout en bout [Nokia]

Figure 24: Un découpage de réseau de bout en bout [Samsung]

References :

Liens 3GPP :

3GPP TS 28.530 V16.1.0 : Management and orchestration; Concepts, use cases and requirements

3GPP TS 38.300 : NR; NR and NG-RAN Overall Description; Stage 2, Release 16

  • http://www.3gpp.org/ftp//Specs/archive/38_series/38.300/38300-g10.zip

3GPP TS 23.501 V16.1.0 : System architecture for the 5G System (5GS); Stage 2, Release 16

3GPP TS 29.510 V15.1.0 : 5G System; Network function repository services; Stage 3, Release 15

3GPP TS 29.531 V15.1.0 : 5G System; Network Slice Selection Services; Stage 3, Release 15

3GPP TS 28.500 : Management concept, architecture and requirements for mobile networks that include virtualized network functions, Release 15

3GPP TS 24.501 : Non-Access-Stratum (NAS) protocol  for 5G System (5GS); Stage 3;             (Release 16)

  • http://www.3gpp.org/ftp//Specs/archive/24_series/24.501/24501-g41.zip

3GPP TS 21.915 : Release Description ; Release 15

 

ETSI

Article

[ferrus] R. Ferrús, O. Sallent, J. Pérez-Romero, R. Agustí , « Management of Network Slicing in 5G Radio Access Networks: Functional Framework and Information Models ».

https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/onf2015.310_Architectural_comparison.08-2.pdf

Equipementiers

  • Huawei : 5G Network Slicing for Vertical Industries
  • Huawei : 5G Network Slicing for Cross Industry Digitization Position Paper
  • Nokia : Network Slicing in 5GS E2E
  • Samsung

 

https://www.huawei.com/minisite/5g/img/gsa-5g-network-slicing-for-vertical-industries.pdf

http://www-file.huawei.com/-/media/CORPORATE/PDF/white%20paper/5G-Network-Slicing-for-Cross-Industry-Digitization-Position-Paper.pdf

Figure 13 : https://www.5g-ks.org/pdf/Network_Slicing_in_5GS-E2E_View-Nokia.pdf

Figure 23 : https://www.5g-ks.org/pdf/Network_Slicing_in_5GS-E2E_View-Nokia.pdf

Figure 24 : https://images.samsung.com/is/content/samsung/p5/global/business/networks/insights/white-paper/network-slicing/200420_Samsung_Network_Slicing_Final.pdf

Bearer EPS

Lors des articles précédent, nous avions décrit le rôle de l’ESM et la mise en place d’une session EPS. Nous allons maintenant expliquer la mise en place de bearer pour le trafic utilisateur.

I) Généralité sur le Bearer EPS

Le bearer EPS est un tuyau (tunnel) construit entre l’UE et le P-GW selon les caractéristiques contenues dans l’EPS session. Le premier bearer EPS construit, nommé default bearer EPS est mis en place lors de la procédure d’enregistrement.

Un bearer EPS est un tuyau caractérisé par des paramètres de QoS car les applications n’ont pas les mêmes besoins : Certaines applications comme le streaming, la visio et la phonie nécessitent un débit garanti (GBR) alors que  le browsing et le téléchargement se suffisent de Best Effort (Débit Non Garanti). On peut envisager à terme l’attribution de critères pour différencier les users premium, gold ou silver.

Pour différencier les bearer, les flux sont identifiés par deux critères :

  • QCI : QoS Class Identifier que l’on traduit par Identifiant de Qualité de Service
  • ARP : Allocation and Retention Priority est la priorité d’allocation et de rétention.

Ces critères sont spécifiés lors de la mise en place du PDN connection (EPS session). Pour plus de renseignement, se référer à l’article ESM – EPS Session Manager

Figure 1. Overview of Session Bearer IDs

Le Bearer EPS traverse plusieurs interfaces, sur chacune de ces interfaces un bearer de niveau inférieur est établi entre les équipements de proche en proche : Data RAdio Bearer, S1 Bearer et un S5 Bearer.

II) Différents Bearer physique

Chaque bearer est identifié par l’identifiant de tunnel TEID (Tunnel Endpoint ID) sur chacune des interfaces. Evidemment, les paramètres CQI/ARP sont identiques sur chaque bearer mis en place pour une EPS session donnée. N’oubliez pas que l’EPS session se charge de gérer les flux sur chaque équipement, autrement dit gère les Bearer entre l’UE-eNb-SGW-PGW.

L’utilisateur pouvant lancer plusieurs applications simultanément, plusieurs EPS bearer peuvent être établis pour un même utilisateur. Chaque EPS bearer est identifié par l’EPS bearer ID, lequel est alloué par le MME.

  • [UE] – [eNB]: Data Radio Bearer (DRB)

EPS bearer est établi sur l’interface LTE-Uu. Le trafic utilisateur (IP packet) est délivré dans le DRB. Differents DRBs sont identifiés par le DRB ID alloués par le eNb

  • [eNB] – [S-GW]: S1 bearer

EPS bearer établi sur l »interface sur l’interface S1-U interface. Le trafic utilisateur est délivré via un tunnel GTP (GTP-U)  Différents S1 bearers sont identifiés par le TEID, qui est alloué par les équipements périphérique (eNB et S-GW).

  • [S-GW] – [P-GW]: S5 bearer

EPS bearer est établi sur l’interface S5.. Le trafic utilisateur est délivré via un tunnel GTP (GTP-U)  Différents S5 bearers sont identifiés par le TEID, qui est alloué par les équipements périphérique (S-GW et P-GW)

  • [UE] – [S-GW]: E-RAB bearer

E-RAB est un bearer logique entre l’UEet le S-GW. Il est constitué du DRB et du S1 bearer

III) Deux types d’EPS Bearer

Nous avons défini au cours du premier paragraphe un EPS bearer, il existe deux types d’EPS Bearer :

  1. EPS Bearer par défaut : Default bearer
  2. EPS Bearer dédié : Dedicated bearer

Figure 2. EPS Bearer Types

Je rappelle que le bearer par défaut est établi pour chaque UE lors de la procédure d’attachement (enregistrement) au réseau. Nous verrons plus en détail le call flow dans un prochain article.

Le bearer par défaut (Default Bearer) est établi avec les paramètres QCI et ARP fournis par le MME. Ces valeurs sont définies par l’abonnement de l’utilisateur dont les données de souscriptions sont sauvegardées dans le HSS. Le bearer par défaut fourni une connectivité IP, le débit n’est pas garanti.

Les dedicated bearers sont des bearer établis à n’importe quel moment après la procédure d’enregistrement pour que l’utilisateur puisse profiter de services nécessitant de la QoS spécifique (latence, débit, …) et sur d’autres PDN. Les valeurs de QoS sont reçues au niveau du P-GW par le PCRF et transférées ensuite au S-GW. Enfin, le MME transfère les valeurs reçues par le S-GW vers le eNb (interface S11)

Gestion de l’itinérance (Part 3) : IP eXchange – IPX

IPX : IP eXchange

Le roaming de Data (et de la VoIP) n’est pas qu’un simple échange de flux entre les différents opérateurs car les opérateurs (V-PLMN et H-PLMN) doivent aussi assurer sur le réseau visité la même qualité  pour les services souscrits par l’abonné par rapport à l’accès aux services sur le réseau nominal (HPLMN), tout en assurant l’intégrité des données et la sécurisation du flux. C’est à ce prix-là que les opérateurs pourront se différencier des OTTs et vendre la plus-value des services proposés (RCS, VOLTE, …)

Le réseau IPX est un réseau IP autorisant une interconnexion entre plusieurs opérateurs mobiles et opérateurs fixes, dont les conditions de raccordements (interconnexion) et surtout de services sont stipulés par des accords entre les opérateurs et les fournisseurs de services. L’objectif est d’assurer la qualité d’expérience du client (QoE) en spécifiant contractuellement les accords entre les différents acteurs et monnayer la plus-value apportée par chaque maillon de la chaine de transport (SLA : Service Level Agreement).

IPX est donc un réseau IP d’interconnexion proposé par les opérateurs afin de garantir une qualité d’échange de données via des accords commerciaux sur des spécifications techniques. Chaque service doit être transmis sur le réseau d’un opérateur selon la spécification de QoS correspondant au service en question : La voix et la Vidéo supposant une demande de QoS élevée doit être transmises  sur des bearers (Canaux de Données) prioritaires alors que les MMS seront transportés sur des bearers de priorités basses. Cela nécessite donc que la facturation pour chaque flux soit contractualisée entre les différents opérateurs pour que la rémunération soit couplée au type de réservation de liens mis en place par les opérateurs.

IPX

L’IPX permet aux opérateurs de définir plusieurs accords afin de garantir les services proposés à ses abonnés ou qu’il soit dans le monde  comme par exemple les services suivants : Rich Communication Suite-enhanced (RCS-e), Near Field Communication (NFC),  Voice over LTE (VoLTE), Mobile Money (paiement par mobile).

L’IPBX doit donc répondre aux points suivants :

  • Un Environnement sécurisé : Le réseau IPX est un réseau IP transparent non accessible depuis Internet.
  • Des services d’interconnexions IP flexibles et ouvert à tout opérateur fixe ou mobile et fournisseur de service (ISP): Un seul contrat pour des accès plus facile et plus rapide aux services « à la carte »
    • Contrat Bilatéral : Le fournisseur de service paye un lien assurant la QoS de bout en bout (comme une demande de lien privé sur différents opérateurs)
    • Contrat Multilatéral : Un seule contrat mais de multiples connexions. Un fournisseur de service peut joindre plusieurs pays.
    • Suivi de la Facturation (Cascading Payments) : Gestion des flux d’informations nécessaire à la mise en place des connexions entre les opérateurs et les fournisseurs de services. Chaque opérateur est responsable des performances des flux sur la partie du réseau qu’il exploite.
    • Qualité d’interconnexion : Le trafic doit être géré en respectant la QoS et les niveaux de services doivent être spécifiés par contrat entre opérateurs (SLA)

SLA

 

Sur ce lien, vous trouverez le communiqué de Presse d’Orange du 2 mai 2012 : « Orange lance son offre Multiservice IP eXchange et propose des services de convergence IP de haute qualité »

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