La sécurité sur les réseaux de mobiles – Part 3

Précédents articles : 

La sécurité sur les réseaux de mobiles – Part 1

La sécurité sur les réseaux de mobiles – Part 2

2. La protocole AKA

II-1) La sécurité sur le réseau 3G :

Le protocole d’authentification GSM n’est pas fiable. D’une part, l’authentification étant unilatérale, le mobile peut s’attacher à un réseau pirate et d’autre part, l’algorithme COMP128 a été cassé en 1997 (figure 3 : attaque Narrow Pipe en 1998) :

Figure 5 : L’algorithme COMP128 [1]

De plus, le réseau pouvant négocier l’algorithme de chiffrement en 2G, il est possible de récupérer en clair les données échangées.

Afin de sécuriser l’attachement du mobile et interdire l’attachement sur un réseau pirate, le protocole AKA (Authentication and Key Agreement) exige une authentification bilatérale.

Le cœur de réseau 3G est identique au cœur de réseau 2G, l’amélioration de la sécurité est apportée au niveau du mobile par l’application USIM sur la carte UICC et d’une mise à jour de la fonction AuC du serveur d’authentification HLR. Pour réaliser l’authentification du réseau, une nouvelle clé AMF (Authentication Management Field) est inscrite dans la carte UICC et dans le HLR.

Le vecteur d’authentification généré par l’AuC contient :

  • l’aléa RAND sur 128 bits ;
  • le résultat d’authentification attendu SRES (32 bits à 128 bits);
  • le sceau d’authentification du réseau opérateur AUTN (128 bits);
  • une clé de chiffrement Ck(128 bits) ;
  • une clé d’intégrité Ik (128 bits).

Le résultat SRES, le sceau AUTN, les clés de chiffrements Ck et Ik sont calculés à partir de l’aléa RAND, de la clé privé symétrique Ki et d’une séquence SQN (figure 6).

Figure 6 : Calcul du vecteur d’authentification 3G

Le vecteur d’authentification est transmis à l’authentificateur VLR ou SGSN. Ce dernier envoie l’aléa RAND et la sceau d’authentification AUTN au mobile, lequel le transfert à la carte UICC.

Le sceau d’authentification est composé de 3 champs qui sont embrouillés par une séquence de 128 bits :

  • une clé d’anonymat Ak (Anonimity Key) sur 48 bits ;
  • la valeur AMF (Authentication Management Field) sur 16 bits ;
  • d’un message de signature d’authentification MAC.

f1 et f2 sont deux fonctions d’authentification. f3, f4 et f5 sont des fonctions de génération de clés (KDF : Key Derivation Function).

Le choix des algorithmes f1, f2, f3, f4 et f5 est spécifique à l’opérateur. Cependant un choix d’algorithmes appelé MILENAGE est proposé par la spécification 3GPP [2] [3].

A partir de sa clé Ki, et de l’aléa, l’application USIM calcule d’abord la clé d’anonymat et récupère ainsi la valeur SQN (par un OU exclusif avec AK et le premier champs AUTN).

Ensuite, le mobile calcule :

  • le message d’authentification XMAC=f1(Ki, AMF, SQN) ;
  • le résultat RES attendu par le cœur de réseau f2(Ki,RAND).

Le résultat RES calculé au niveau de la carte UICC est transmis au mobile qui l’envoie à l’authentificateur. L’authentificateur compare le résultat RES du mobile avec la valeur attendue SRES.

Enfin, la carte UICC vérifie la correspondance entre la signature XMAC calculée avec le champ MAC contenu dans le sceau d’authentification AUTN. Cela permet d’éviter les attaques de type Man In The Middle. Si les valeurs sont identiques, l’application USIM calcule le résultat d’authentification (figure 7).

Figure 7 : Les étapes d’authentification pour la 3G et détection d’une station de base pirate

Ensuite, le mobile dérive les clés de chiffrement Ck et d’intégrité Ik à partir des fonctions f3 et f4.

Alors qu’en 2G le chiffrement et le déchiffrement sont réalisés au niveau de la BTS pour les sessions téléphoniques et au niveau du SGSN pour le trafic IP, en 3G le chiffrement et le déchiffrement s’effectuent au niveau du RNC (Radio Network Controller).

Ainsi, la clé CK doit être transférée du VLR au RNC via la commande security mode command gérée par le protocole RANAP (Radio Access Network Application Part). Ensuite, le RNC active le chiffrement au niveau du mobile via le message RRC security mode command.

Figure 8 : La procédure d’authentification et de chiffrement [5]

La clé Ck est calculée à chaque processus d’authentification. Le chiffrement est réalisé par un ou exclusif entre un bloc de données et un flux de chiffrement. Le flux de chiffrement est calculé à partir de l’algorithme f8 avec comme paramètres :

  • la clé Ck;
  • un compteur COUNT-C sur 32 bits ;
  • l’identité du support radio (BEARER) sur 5 bits ;
  • la direction de transmission (UpLink =0/DownLink =1) ;
  • la longueur du flux de chiffrement (le bloc de donnée à chiffrer).

Figure 9: Le chiffrement des données

L’algorithme f9 est utilisé pour le calcul d’intégrité :

Figure 10 : La signature d’intégrité des données

La valeur FRESH est une variable aléatoire généré par le RNC. La clé IK étant générée lors de l’enregistrement, celle-ci n’est pas modifiée tant que le mobile ne se détache pas. La valeur FRESH permet de modifier régulièrement la signature. Cette valeur est transmise au mobile au cours de la demande de connexion RRC.

D’un point de vue implémentation algorithmique, la valeur FRESH n’est pas réellement aléatoire, elle est souvent prise égale à la valeur du BEARER.

Le compteur COUNT-I protège le récepteur d’une attaque Man In The Middle : le prochain message, le compteur est incrémenté et la signature MAC pour le même message sera différente.

Les algorithmes d’authentification sont connus sous le nom de MILENAGE.

Les algorithmes de chiffrement f8 et f9 sont des algorithmes de KASUMI (déjà utilisé en 2G pour l’algorithme A5/3). Plus récemment, l’algorithme Snow 3G est un algorithme de chiffrement à flot pouvant remplacer l’algorithme KASUMI. L’algorithme SNOW3G est aussi utilisé pour fournir un message d’intégrité MAC (aussi nommé algorithme UIA2).

Figure 11 : Le calcul des clés en 3G

L’intégrité est calculé au niveau de la couche RRC, le chiffrement est réalisé au niveau de la couche RLC (sauf pour le mode transparent ou le chiffrement est réalisé par la couche MAC)

Architecture SBA du réseau 5G : Microservices et SOA

L’objectif de cet article est de comprendre l’évolution du cœur de réseau mobile entre l’architecture 4G monolithique et l’architecture 5G basée sur les services.

La nouvelle architecture 5G a été pensée pour pouvoir ajouter des briques logicielles innovantes et une mise sur marché rapide de ces nouvelles fonctionnalités. Ainsi, à l’instar des solutions proposées par Amazon ou Windows Azur, le réseau 5G s’appuie sur les solutions Cloud et la méthodologie DevOps.

Au cours de cet article, nous allons décrire le cœur de réseau 4G, puis les architectures SOA (Service Oriented Architecture) et microservice pour décrire et comprendre l’architecture SBA (Services Based Architecture) du réseau 5G.

Je remercie Mickael BARON [2] d’avoir pris le temps de relire l’article, le corriger et d’avoir contribué aux améliorations de cet article.

  1. L’architecture du réseau 4G

Le cœur de réseau de mobiles 4G (cf. figure 1) est construit à partir des entités fonctionnelles suivantes :

  • l’entité MME (Mobility Management Entity) a pour rôle de gérer :
    • l’attachement des mobile ;
    • le suivi de la mobilité ;
    • l’établissement de sessions IP prenant en compte la politique de taxation de l’usager ;
    • l’établissement d’un appel voix.
  • l’entité SGW (Serving Gateway) est le point d’ancrage des flux de sessions IP. Le SGW gère l’établissement d’un bearer (un bearer est un tunnel IP de bout en bout associée à une qualité de service QoS). Le bearer s’établit du mobile jusqu’à l’entité PGW. Le SGW mesure le trafic consommé par utilisateur et, en cas de demande judiciaire, dérive le trafic (cas d’interception légale).
  • l’entité PGW (PDN Gateway) est la passerelle de routage entre le réseau opérateur et un réseau IP (PDN : Packet Data Network). L’entité PGW réalise l’inspection de trafic, met en place les bearer avec le SGW, est en charge de fournir une adresse IP au mobile pour chaque bearer, mesure le trafic consommé et, en cas de demande, dérive le trafic dans le cas d’interception légale.
  • l’entité PCRF (Policy Charging Rule Function) gère la mise en œuvre de la QoS pour les bearer dédiés et la gestion dynamique de la facturation.

Figure 1 : Le réseau 4G, les bases de données et l’échange d’information

Chaque entité fonctionnelle contient un ensemble de lignes de codes pour pouvoir apporter les fonctionnalités attendues. On parle de bloc monolithique : le langage de programmation choisi pour chaque entité fonctionnelle dépend de l’équipementier. La mise à jour d’une entité nécessite la recompilation de l’ensemble du programme (toutes les lignes de code), ce qui met à jour toutes les fonctions. L’équipementier doit s’assurer que la modification d’une fonction n’ait aucun impact sur le reste du programme.

Chaque entité fonctionnelle contient une base de données importante (une table avec des millions d’entrées). A titre d’exemple, la figure 1 représente en couleur bleue une partie du contexte sauvegardé dans la base de données des entités pour un mobile. Les entités fonctionnelles partagent leurs données aux autres entités dans des appels à fonction. La technologie utilisée pour la base de données est propre à l’équipementier (mariadb, PostgreSQL, …). Ainsi, deux entités MME provenant de deux équipementiers différents (Nokia/Ericsson par exemple) peuvent utiliser des bases de données différentes et un langage de programmation différent. Mais les échanges entre entités sont normalisés.

Enfin, une ou plusieurs entités fonctionnelles peuvent être intégrées dans une seule entité matérielle. A titre d’exemple, le SGW et le PGW peuvent former l’entité S/PGW. L’entité matérielle est dite monolithe.

Définition : en génie logiciel, un modèle monolithique fait référence à une seule unité indivisible.

Par dérivation, le concept de logiciel monolithique réside dans la combinaison de différents composants d’une application en un seul programme sur une seule plateforme. Habituellement, une application monolithique se compose d’une base de données, d’une interface utilisateur côté client et d’une application côté serveur. Toutes les parties du logiciel sont unifiées et toutes ses fonctions sont gérées en un seul endroit.

Comme le montre la figure 1, dans l’architecture 4G, les entités sont connectées les unes aux autres, par une connexion point à point. Cette connexion est nécessaire afin d’échanger des données.

L’architecture 4G est une architecture composée d’entité monolithe modulaire autonome : chaque entité est responsable d’un ensemble de fonctions et fournit aux autres entités les données nécessaires à l’exécution d’un service.

Par exemple :

  • l’identification, l’authentification et les droits d’accès du mobile sont gérées par l’entité HSS : l’entité MME interroge l’entité HSS pour pouvoir identifier le mobile en lui transmettant l’identité IMSI du mobile. Le HSS transmet à l’entité MME les données d’authentification. L’entité MME va ensuite réaliser la procédure d’authentification avec le mobile ;
  • lorsque le mobile est en mode connecté, l’entité MME connait l’identité de la station de base (eCGI) sur laquelle le mobile échange des données. L’entité MME peut donc demander à l’entité SGW de mettre en place, pour ce mobile, un nouveau bearer (dédié) vers la station de base.

Les spécifications 3GPP standardisent les interfaces entre chaque entité fonctionnelle en définissant :

  • les applications au niveau des interfaces (par exemple GTP-C, S1-AP, DIAMETER) ;
  • les messages échangés entre chaque interface (cf. figure 1).

Dans le cas de l’architecture 4G, une fonction (une portion du code) est sollicitée par une autre entité : à titre d’exemple la fonction PCEF intégrée au niveau de l’entité PGW applique les règles fixées par l’entité PCRF. L’entité PCRF transmet une requête DIAMETER à l’entité PGW sur l’interface Gx. Chaque entité gérant des millions d’utilisateurs, il est nécessaire d’identifier le mobile concerné. Ainsi, chaque entité source soumet à l’entité cible les informations nécessaires (l’identité GUTI ou IMSI, le numéro de tunnel TEID, …comme le montre la figure 1). Les informations à transmettre sont normalisées.

Cette architecture monolithe modulaire facilite l’ajout de nouvelles entités fonctionnelle. Toutefois, puisque les entités communiquent les unes avec les autres selon les spécifications 3GPP, il est nécessaire de respecter les spécifications sur les interfaces. Malgré les efforts de spécifications, l’interprétation de la norme peut être perçue différemment par chaque équipementier.

Ainsi, lorsque l’opérateur ajoute une nouvelle entité, cela nécessite du temps pour vérifier l’intégration de cette nouvelle entité avec les autres entités existantes provenant de constructeurs différents.

En général, une fois la normalisation d’un réseau mobile gelé, l’architecture du réseau de mobiles n’évolue pas.  C’est le cas pour la 2G, puis la 3G. Cela aurait dû être le cas pour la 4G, mais l’arrivée de l’IoT a nécessité une évolution de l’architecture du réseau 4G par l’ajout d’une nouvelle entité. Ainsi, initialement la 3GPP a proposé l’ajout d’une entité MTC-IWF pour les cas d’usage du MTC (Machine Type Communication) et a spécifié l’interface DIAMETER entre l’entité fonctionnelle MTC-IWF et les autres entités.

Toutefois, prenant compte qu’il est plus simple de faire évoluer l’architecture du réseau 4G par l’ajout d’une fonction qui expose des services [1], la spécification 3GPP a proposé l’ajout d’une nouvelle entité matérielle. Ainsi, l’entité fonctionnelle MTC-IWF a été abandonnée au profit de la fonction SCEF : Service Capacité Exposure Function.

Pour résumer, chaque entité fonctionnelle de l’architecture 4G est connectée point à point avec les autres entités par une interface normalisée.

A travers cet interface, les entités offrent des services à une autre entité : le service est une action exécutée par un « fournisseur » (ou « producteur ») à l’intention d’un « client » (ou « consommateur »).

A l’instar du rôle des entités de la 4G, l’architecture SOA (Service Oriented Architecture) s’appuie sur deux éléments principaux : un fournisseur de services et un consommateur de services. Ces deux rôles peuvent être joués par un agent logiciel.

La différence importante entre une architecture 4G et l’architecture SOA concerne la mise en relation des fonctions. Nous allons maintenant nous intéresser aux architectures SOA et microservices facilitant le développement logiciel de nouvelles fonctions.

2. Evolution du réseau de mobile vers l’architecture SOA et l’architecture microservices

II-a) L’architecture SOA

Définition : une architecture orientée services (SOA) est une architecture logicielle qui fait référence à une application composée d’agents logiciels discrets et faiblement couplés qui exécutent une fonction requise. Le concept de SOA est le suivant : une application peut être conçue et construite de manière à ce que ses modules soient intégrés de manière transparente et puissent être facilement réutilisés.

Dans une architecture SOA, les fonctions sont connectées les unes aux autres par un médiateur nommé bus d’intégration ESB.

Le bus d’intégration ESB est un logiciel (middleware) facilitant l’échange de données entre différentes fonctions logicielles (application).

Le logiciel ESB est le point de connectivité pour toutes les applications, et il garantit la sécurisation des échanges.

Le logiciel ESB enregistre les services que fournit chaque application (appelée capacité de service) dans un registre. Les applications publient une ou plusieurs de leurs capacités via le bus ESB et les consommateurs peuvent interagir avec ces applications sans même savoir ce qu’est une application

Le bus ESB centralise les informations et répartit le travail entre les applications. Le bus ESB agit comme un pont de données entre les applications. Le routage des données et la répartition de charge sont assurées par l’application BPM (Business Process Management).

Le bus d’intégration ESB permet de fusionner (interconnecter) diverses applications, anciennes comme récentes, pouvant fonctionner sur des systèmes d’exploitation différents et pouvant utiliser des protocoles différents [2]. Le bus d’intégration s’appuie sur des connecteurs sur lesquelles sont connectées les applications. Les connecteurs garantissent l’interopérabilité entre les applications.

Chaque application fournit et consomme des services : les applications exposent des services à travers des interfaces de programmation d’application API (Application Programming Interface). La gestion des API est fondamentale, elle permet aux développeurs d’utiliser des services back-end pour la supervision et permet de garantir l’agilité du réseau (Agilité [3] : Capacité de changer les choses rapidement).

L’architecture SOA permet donc de réduire le temps de déploiement de nouveaux services.

II-b) L’architecture microservices

L’architecture en microservices consiste à concevoir un ensemble de services autonomes qui communiquent entre eux via une API. Les microservices communiquent via des protocoles HTTP (REST), ou via AMQP (Advanced Message Queuing Protocol) en asynchrone chaque fois que cela est possible, surtout pendant la propagation de mises à jour avec des événements d’intégration. Cette communication se produit par le biais d’un bus d’événements pour propager les mises à jour sur les microservices ou pour s’intégrer à des applications externes.

Un microservice [2] doit réaliser une seule fonctionnalité de l’application globale. En général, chaque microservice est déployé en tant que conteneur indépendant, ou dans une machine virtuelle.

Le concept de conteneur est le plus généralement adopté car il consomme peu de ressource (l’application n’a pas besoin d’un système d’exploitation complet) et il améliore la sécurité, puisque la containerisation permet d’exécuter un programme de manière isolée du noyau d’un système d’exploitation (kernel).

Cette architecture apporte :

  • de la souplesse puisqu’il est possible de développer ou modifier un microservice sans affecter les autres sous-systèmes : chaque microservice étant déployé indépendamment grâce aux solutions de virtualisation et de conteneur, une nouvelle évolution d’un seul service peut rapidement être testée et re-déployée ;
  • de l’élasticité puisqu’il est possible de dimensionner dynamiquement le réseau en fonction du nombre de sollicitation (montée en charge = scalabilité). En cas de trafic croissant, il suffit de multiplier le nombre d’instances d’un microservice.

Chaque microservice dispose si possible de sa propre base de données, ce qui le découple entièrement des autres microservices. Quand elle est nécessaire, la cohérence entre les bases de données des différents microservices est obtenue à travers l’utilisation d’événements d’intégration au niveau de l’application (via un bus d’événements logiques)

A l’instar d’un bus d’intégration, l’architecture microservice utilise un bus d’évènement et un logiciel d’équilibrage de charge (load balancer) afin de mettre en relation des services.

Un bus d’événements est un logiciel (middleware) qui permet une communication de type publication/abonnement entre les microservices, sans nécessiter que les composants soient explicitement informés de la présence des uns des autres.

Figure 2 : Bus d’évènement

Lorsque le microservice publie un évènement, il ne sait pas que cet évènement sera diffusé vers les microservices B et C. Il ne connait pas les abonnés, ceux-ci se sont enregistrés auprès du bus d’évènement MOM (Message Oriented Middleware comme par exemple RabbitMQ).

Si le microservice est stateless, une même requête produit toujours la même réponse. Ainsi, le bus d’évènement met en relation les deux services qui doivent communiquer directement l’un à l’autre. Lorsque plusieurs instances sont activées, l’équilibrage de charge définit quelles instances doivent être sollicitées. L’architecture microservice est donc bien adapté pour dimensionner le système en fonction de la charge.

En contrepartie, cette architecture peut entraîner des soucis de performance puisque chaque microservice peut faire appel à plusieurs microservices. Ainsi, le temps de réponse du plan de contrôle (ce qui revient à la latence) est accru pour chaque dépendance supplémentaire entre microservices.

II-c) Microservices : les bonnes pratiques du SOA

L’architecture SOA est composée d’applications logicielles réutilisables. Les services sont exposés via des API. L’interface, c’est-à-dire le couplage entre applications est faible ce qui permet d’appeler ces services avec peu de connaissance sur la manière dont les services sont implémentés. Cela permet de réutiliser rapidement des services.

A l’instar du SOA, l’architecture microservice est conçu sur un ensemble de fonctions faiblement couplés.

3. Architecture des réseaux de mobile 5G

III-1) Architecture SBA

Les fonctions du cœur de réseau 5G sont très proches des fonctionnalités du cœur de réseau 4G. L’évolution Next-Gen (NG Core) consiste à séparer le plan de contrôle du plan de trafic. Concernant le trafic, pour le réseau 5G comme pour le réseau 4G, les données IP sont encapsulées par le protocole GTP-U à travers un tunnel. Le protocole GTP-U est utilisé entre la station de base gNB et les fonctions UPF (User Plane Function).

L’architecture du plan de contrôle du réseau de mobiles 5G est une architecture hybride entre des applications Cloud Native, et la virtualisation.

Sur la figure 3, on présente à gauche l’architecture monolithique traditionnelle, et deux solutions complémentaires : la virtualisation des fonctions réseaux (NFV : Network Function Virtualization) et la méthodologie Cloud Native.

Figure 3 : L’architecture monolithique, l’architecture de virtualisation VNF et l’architecture Cloud CNF

Une application Cloud Native (CNA) est développée sous forme de microservices faiblement couplés. Chaque microservice est conditionné dans un conteneur. Un orchestrateur central planifie les conteneurs pour gérer efficacement les ressources du serveur et réduire coûts opérationnels. Les CNA nécessitent également un environnement DevOps.

DevOps fait référence à une méthodologie qui prend en compte le développement logiciel avec les contraintes d’administration des infrastructures informatiques. La partie développement (Dev) intègre le développement logiciel, l’automatisation et le suivi du projet informatique et la partie opérationnelle (ops) intègre l’exploitation, la maintenance et la supervision de l’infrastructure informatique. L’équipe opérationnelle (ops) gère la stabilité du système et le contrôle de la qualité des services, et l’équipe développement (Dev) cherche à améliorer les services à moindre coût en ajoutant de nouvelles fonctionnalités. L’équipe ops doit donc constamment valider les évolutions proposées par l’équipe dev.

La méthodologie DevOps permet d’obtenir les avantages suivant pour les applications Cloud Native :

  • une évolutivité facilitée par une architecture modulaires (microservice) ;
  • la réduction du CAPEX et de l’OPEX par mutualisation des applications (hébergement sur des machines virtuelles ou conteneurs) ;
  • l’automatisation des fonctions applicatives.

La solution alternative NFV (Network Function Virtualization) a été initialement proposée et adaptée au cœur de réseau 5G par le groupe de travail de l’ETSI. L’architecture NFV décrit les interactions entre l’infrastructure matérielle (NFVI), la gestion des machine virtuelles (VNFM : Virtual Network Function Manager) et l’automatisation des VM sur les infrastructures matérielles.

La spécification NFV a permis de définir un environnement stable pour la mise en place automatisée de machines virtuelles et de conteneurs, chaque VM ou conteneur exécutant une fonction du réseau 5G (NFV : Network Function Virtualized).

L’architecture SBA du cœur du réseau de contrôle 5G est une solution hybride SOA/microservices.

Figure 4: L’architecture SBA du réseau 5G [9]

La mise en place des fonctions réseaux, la supervision (monitoring) nécessite un orchestrateur afin d’automatiser le déploiement des services (établissement ou relâchement d’un service ou d’un microservice). Une plateforme de service permet de fournir un environnement temps-réel qui utilise une pile de protocoles open-source pour le déploiement de fonction réseaux NF.

La plateforme de service permet l’intégration et le déploiement de nouvelles fonctions sur un réseau en production :

  • CI : l’intégration continue de nouvelles fonctionnalités (CI – Continuous Integration) ;
  • CD : le déploiement continue ou la distribution continue permettant d’automatiser l’ajout d’un nouveau code dans une bibliothèque de code partagé et dans un environnement de production (CD – Continuous delivery/continuous deployment), et résoudre ainsi la difficulté connue sous le nom « integration hell», ou l’enfer de l’intégration.

L’approche CI/CD permet de créer de créer plusieurs versions d’une application, chaque version étant gérées par un serveur de distribution (un serveur référentiel comme github) et de développer l’environnement client afin de tester rapidement la nouvelle version.

Une fois testée en laboratoire, il est assez rapide de rajouter une nouvelle fonction réseau NF (avec la nouvelle version) tout en conservant en parallèle l’ancienne version de la fonction. Le client peut ainsi tester sur son environnement réel la nouvelle version et la conserver en production.

Figure 5 : L’approche CI/CD [9]

L’environnement complet est représenté sur la figure 6 suivante

Figure 6 : L’environnement de production du cœur de réseau 5G [8]

L’approche CI/CD est parfaitement adaptée pour la mise en place du découpage de réseau (Network Slicing) puisqu’elle permet de déployer des nouvelles fonctionnalités rapidement en fonction des spécificités de chaque service.

Figure 7 : L’architecture SBA [10]

MOLI : Management and Orchestration Layer Interface

SOBI : Southbound Interface (SoBI)

III-2) Les fonctions réseau NF (Network Function)

Les fonctions réseau NF se compose d’opérations basées sur un modèle de demande-réponse ou sur un modèle de souscription/notification.

Le protocole HTTP2 est un protocole commun à l’ensemble des fonctions du réseau (NF) remplaçant ainsi les protocoles DIAMETER, GTP-C du réseau de mobiles 4G. Les fonctions réseaux NF communiquent à travers l’interface SBI grâce à un système d’API, principalement le JSON.

Figure 8 : L’interface SBI entre deux fonctions NF

Dans l’architecture SOA, un bus d’intégration permet la communication entre chaque fonction NF. Lorsqu’une fonction NF démarre, elle interroge dans un premier temps un catalogue de fonction pour découvrir les fonctions existantes et communiquer avec elles. Nous avons vu précédemment que le bus ESB enregistre les services que fournit chaque application (appelée capacité de service) dans un registre.

Dans l’architecture réseau 5G, le catalogue de fonction se nomme NRF (Network Repository function). Il offre un service de découverte des fonctions du réseau de mobile et un service d’enregistrement (service registration management et service discovery mechanisms).

La fonction NRF:

  • implémente une fonction d’authentification via une règle de sécurité d’accès sur chaque requête de services reçue
  • délivre un certificat à la fonction NF qui l’interroge. La fonction NF initiatrice d’une requête pourra ainsi prouver son authenticité à la fonction NF cible (qui rend le service).

Figure 9 : L’interface SBI et la communication JSON

Dans le cas de l’architecture SOA, les événements d’intégration sont utilisés pour synchroniser l’état du domaine sur plusieurs fonctions (microservices ou systèmes externes). Cette fonctionnalité est effectuée en publiant des événements d’intégration.

La fonction NF peut se décomposer en plusieurs microservices, notamment un agent_NRF permettant à la fonction NF de se déclarer auprès du NRF. Ainsi, en cas d’évolution de la fonction du NF, l’agent_NRF peut mettre à jour les fonctionnalités au niveau du NRF.

Lorsqu’un événement est publié sur plusieurs microservices récepteurs (sur tous les microservices abonnés à l’événement d’intégration), le gestionnaire d’événements de chaque microservice récepteur gère l’événement.

Figure 10 : Le NF découpé en microservice (Source China Telecom [11])

Dans l’architecture microservices, chaque microservice dispose de sa propre base de données. Pour l’architecture SBA du réseau 5G, la fonction réseau NF (microservice) dispose soit de sa propre base de données UDSF (Unstructured Data Storage Function) soit partage la base de données UDSF avec plusieurs NF.

Comme en 4G, la base de données UDSF contient le contexte de chaque mobile UE (User Equipment).

Figure 11 : La base de données

   4. Conclusion

Si le cœur de réseau 5G présente beaucoup d’analogie fonctionnelle avec le cœur de réseau 4G, l’évolution majeure consiste en un découpage de fonction réseau NF dans un environnement agile permettant de déployer et adapter dynamiquement le cœur de réseau en fonction de la charge et d’apporter rapidement de nouvelles fonctionnalités.

La méthodologie DevOps et l’approche CD/CI permet la mise à jour de certains microservices tout en conservant des microservices de versions plus anciennes pour assurer la stabilité avec des terminaux non compatibles avec cette mise à jour.

Ainsi en maintenant des microservices en fonction (version 1.0) tout en proposant des microservices dans une nouvelle version (version 1.1) cela permet à certains téléphones de profiter des dernières évolutions sans impacter certains terminaux mobiles qui peuvent continuer à fonctionner sur les anciennes versions.

Figure 12 : Le cœur de réseau 5G [7]

L’architecture SBA permet donc une meilleure adaptation aux évolutions de service (Network Slicing).

Figure 13 : Comparaison de l’architecture monolithique et SBA (HPE [12])

La figure 14 fait une synthèse des améliorations ainsi apportées par l’architecture SBA

Figure 14 : Comparaison des architectures [4]

 

Références :

[1] Andrea Zerial

https://www.organisation-performante.com/le-monolithe-dans-l-it-pour-en-comprendre-l-origine/

https://www.organisation-performante.com/les-evolutions-du-si-2-soa-et-le-monolithe-seffrita/

[2] Mickael BARON :  https://mickael-baron.fr/soa/introduction-microservices

[3] Thimothée Barray : https://slides.com/tyx/sflive2020-bb8c28

[4] Michael Sukachev : https://fr.slideshare.net/MichaelSukachev/soa-vs-microservices-vs-sba

[5] Jonathan Huteau, Jérôme Cognet,

https://blog.link-value.fr/architectures-de-projet-b42dc5213857

[6] https://www.ibm.com/cloud/blog/soa-vs-microservices

[7] https://docs.microsoft.com/fr-fr/dotnet/architecture/microservices/multi-container-microservice-net-applications/integration-event-based-microservice-communications

[8] https://images.samsung.com/is/content/samsung/p5/global/business/networks/insights/white-paper/cloud-native-5g-core/Cloud-Native-5G-Core-Samsung-5G-Core-Volume-2.pdf

[9] https://www.redhat.com/fr/topics/devops/what-is-ci-cd

[10] https://5g-monarch.eu/wp-content/uploads/2019/05/5G-MoNArch_761445_D2.3_Final_overall_architecture_v1.0.pdf

[11] https://www.3g4g.co.uk/5G/5Gtech_6004_2017_11_Service-Based-Architecture-for-5G-Core-Networks_HR_Huawei.pdf

[12] http://www.hpe.com/info/5g

 

 

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

[bws_captcha]Cet article est la suite de :

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

III) La virtualisation du cœur de réseau

Les entités du cœur de réseau AMF, SMF, NEF, PCF sont des fonctions qui peuvent être virtualisées. Ces fonctions gèrent le plan de contrôle du réseau de mobiles et les performances fonctionnelles sont analysées au niveau du support opérationnel OSS (FCAPS).

L’entité UPF peut également être virtualisée, cette fonction gère le plan utilisateur. La fonction UPF possède des capacités d’aiguillage de trafic à partir de la classification de flux UL-CL (Uplink Classifier). Ainsi, la fonction UPF peut avoir le rôle de point de branchement (multi-homing), point d’ancrage de session (PSA : PDU Session Anchor) ou classificateur de flux pour définir le prochain saut. La classification de flux est une fonctionnalité supportée par la fonction UPF afin de diriger le trafic localement en fonction des filtres appliqués au trafic UE.

Le contrôle des fonctions virtuelles dans le cœur de réseau 5G est réalisé par deux fonctions nommées NSSF (Network Slice Selection Function) et NRF (Network Repository Function).

  • Le rôle du NSSF est de sélectionner le jeu de tranches réseau que l’utilisateur va pouvoir utiliser en fonction de son contrat d’abonnement (SLA) pour lui apporter la QoE (Quality of Experience) souhaitée. Le choix du slice se faisant au moment de l’enregistrement du mobile, la fonction NSSF dialogue avec la fonction AMF ou la fonction NSSF d’un autre PLMN.
  • Le rôle du NRF est de fournir un contrôle des fonctions virtuelles (NF) et des services proposés par les fonctions virtuelles.
    • La fonction NRF est un catalogue qui est mis à jour au moment de l’activation de la fonction virtuelle (enregistrement) et mis à jour lorsque la fonction virtuelle est redimensionnée. Elle propose ainsi un service de découverte de fonctions virtuelles
    • Toute fonction virtuelle NF peut demander à la fonction NRF, par une procédure de souscription, d’être informée dès qu’une nouvelle instance est créée.

Figure 5 : Inscription d’une fonction virtuelle au niveau de la fonction NRF (TS 29.510)

Une sous-instance virtuelle est composée au minimum de fonctions AMF, SMF, PCF, NRF. L’opérateur (OSS) met en place un ou plusieurs sous réseaux virtuels SNI et peut à tout moment activer ou désactiver un sous-réseau (procédure NSI figure 3). Chaque fonction activée vient se déclarer auprès de la fonction NRF (figure 5).

Une instance de réseau permet de gérer un type de service. Le type de service est défini par la variable S-NSSAI. Le S-NSSAI contient 2 champs :

  • SST sur 8 bits défini le type de slice (Slice Service Type)
    • SST = 1 : eMBB (normalisée 3GPP) ;
    • SST = 2 : URLLC (normalisée 3GPP) ;
    • SST = 3 : mMTC (normalisée 3GPP) ;
    • SST = 4 : V2X (normalisée 3GPP) ;
    • SST= 5 : HMTC (High Performance MTC normalisée 3GPP – R.17 – mise à jour janvier 2022);
    • SST=6 : HDLLC (High Data Low Latency Communication 3GPP – R.18 mise à jour juin 2023)
    • SST de 128 à 255 sont définis par l’opérateur.
  • SD (Slice Differentiator) est une information optionnelle qui permet de décliner plusieurs types de sous-service dans une catégorie SST donnée afin de différencier les clients.

La fonction NSSF permet d’identifier les NSI. Cette fonction est configurable via une API REST.

Voici un exemple de configuration de la fonction NSSF :

https://host:port/v1/nssf/configurations/nsiprofiles
POST
Content-Type: application/json
BODY
{
    « name »: « NSI001 »,
    « nrfUri »: « https://nrf.bloglaunay.com »,
    « nsiId »: « 1 »,
    « targetAmfSets »:
    [
        {
            « regionId »: « 01 »,
            « setId »: « 001 »,
            « setFqdn »: « set001.region01.amfset.5gc.mnc111.mcc208.3gppnetwork.org »
        },
        {
            « regionId »: « 01 »,
            « setId »: « 002 »,
            « setFqdn »: « set002.region01.amfset.5gc.mnc111.mcc208.3gppnetwork.org »
        }
    ]
}

Pour être plus complet, la configuration de la fonction NSSF permet aussi de diriger le choix de la fonction NRF en fonction du NSSAI demandé.

D’un point de vue opérateur : Lorsqu’une tranche de réseau est mise en œuvre, la fonction AMF peut toujours mettre à jour la configuration S-NSSAI de la fonction NSSF afin d’informer celle-ci des types de service supportés par la fonction AMF sur une zone de localisation TA.

Une fonction AMF peut gérer plusieurs tranches de réseaux S-NSSAI (il n’y a pas de limite fixée au niveau du cœur de réseau).

Figure 6 : La mise à jour de la fonction NSSF

L’entité NSSF sélectionne le (ou les) instances de réseau NSI correspondant(s) à la demande du mobile à partir du (ou de la liste des) S-NSSAI et détermine ainsi les fonctions AMF candidates correspondant spécifiquement (ou au mieux) à la demande de l’UE. Eventuellement, l’entité NSSF interroge la base de données NRF (Network Repository Function).

Figure 7 : Procédure d’enregistrement et sélection du NSI

L’entité NSSF renvoie à la fonction AMF qui l’a interrogée, la valeur NSSAI autorisée sur la zone TA et la liste des fonctions AMF candidates (figure 7).

Lorsque la station de base s’active (mise en route ou suite à une procédure de ré-initialisation), elle interroge les fonctions AMF pour connaître les tranches de réseaux (slices) supportées par chaque fonction AMF accessible comme le montre la figure 8.

 

Figure 8 : La déclaration des slices supportées par les fonctions AMF auprès de l’entité gNB

Si la station de base gNB était déjà en fonctionnement, alors elle est informée des modifications NSSAI apportées au niveau de la fonction AMF via le message NG Setup request (figure 9).

Figure 9 : La mise à jour des slices supportées par les fonctions AMF auprès de l’entité gNB

Lorsque le mobile s’active, il réalise une procédure d’attachement auprès d’une fonction AMF. L’attachement se fait sur une fonction AMF parmi toutes les fonctions AMF qui ont été activées par le support opérationnel OSS et accessible par la station de base gNB.

La sélection de l’entité AMF est réalisée au moment de la procédure d’attachement. Le choix est effectué à partir de l’identifiant NSSAI émis dans la requête NAS REGISTER. La station de base gNB reçoit la requête RRC qui porte le message NAS et l’indicateur NSSAI à partir duquel il sélectionne une fonction AMF. Si plusieurs fonctions AMF candidates peuvent être choisies (cf figure 8), la station de base gNB fait son choix par équilibrage de charge.

La fonction AMF sélectionnée par l’entité gNB interroge la base de données UDM pour vérifier que l’indicateur NSSAI demandé par le terminal (requested NSSAI) est accepté. L’entité UDM transmet à la fonction AMF le NSSAI autorisé pour ce client (allowed NSSAI). A partir de ce moment, la fonction AMF consulte la fonction NSSF (Network Slicing Selection Function) à partir d’une requête GET en indiquant la liste des S-NSSAI autorisés.

Si après consultation de la fonction NSSF, la fonction AMF sélectionnée initialement (appelée AMF source) par la station de base n’est pas appropriée pour les services demandés (NSSAI), alors la fonction AMF source réalise la procédure de ré-allocation de la fonction AMF.

Concernant la ré-allocation (lors de la procédure d’attachement), deux options sont possibles :

Dans le cas de l’option A (figure 10), en fonction des informations de souscription et de politique locale, la fonction AMF source décide d’envoyer la requête initiale vers la fonction AMF cible via le message Namf_Communication_N1MessageNotify portant le message NG-RAN Reroute Message.

Cependant, comme il ne peut y avoir qu’un seul point de terminaison N2 entre l’entité gNB et la fonction AMF pour un UE donné, la fonction AMF cible met à jour le point de terminaison auprès du gNB via le message NG AMF Configuration Update.

 

Figure 10 : Procédure de ré-allocation de la fonction AMF pour la gestion des transches de réseau du mobile UE : Option A

Dans le cas de l’option B (figure 11), en fonction des informations de souscriptions et de politique locale, la fonction AMF source décide d’envoyer le message NGAP Reroute NAS Message à l’entité gNB afin que celle-ci formule une nouvelle requête d’attachement vers la fonction AMF cible.

Figure 11 : Procédure de ré-allocation de la fonction AMF pour la gestion des tranches de réseau du mobile UE : Option B

Au niveau du cœur de réseau, le mobile s’enregistre sur une seule fonction AMF.

Le mobile peut demander à profiter de plusieurs tranches de réseaux (figure 12), les fonctions AMF, NSSF font parties des fonctions communes à toutes les tranches. Les fonctions PCF et NRF peuvent être communes ou spécifiques à une tranche de réseau.

Pour que le mobile puisse recevoir ou émettre des données, il faut mettre en place une session PDU. La session PDU est contrôlée par la fonction SMF, avec des règles PCF spécifiques.

Figure 12 : Les tranches de réseaux : Fonctions communes et spécifiques.

Il est aussi possible d’ajouter des fonctionnalités supplémentaires comme imposer la direction de trafic (trafic steering) en sortie du réseau de mobiles Gi-LAN afin d’apporter des services comme de l’optimisation vidéo, optimisation http, un cache CDN, un cache de réalité virtuelle, un détecteur de malware, une fonction parentale, un parefeu, …

Au niveau du mobile, le mobile fait une demande d’enregistrement auprès du cœur de réseau. Le mobile indique dans sa requête NAS les tranches de réseaux souhaitées (Requested NSSAI). Le requested NSSAI correspond soit au NSSAI configuré pour le PLMN (configured NSSAI), soit au NSSAI autorisé pour le PLMN (allowed NSSAI). Ce dernier (allowed NSSAI) a été récupéré lors d’un précédent enregistrement. Si le mobile n’a aucun NSSAI configuré pour le PLMN sur lequel il s’enregistre, alors il transmet l’information NSSAI configurée par défaut (Default configured NSSAI).

L’information NSSAI est configurée sur la mémoire non volatile du mobile. Il ne revient pas au standard 3GPP d’indiquer où est stockée cette information mais aux fabricants de terminaux. Le mobile peut contenir plusieurs informations NSSAI, chaque NSSAI est couplée à l’identifiant SUPI et est identifiée par le PLMN ID (cf. TS 24.501). Si on change l’identifiant SUPI, les informations NSSAI sont supprimées de la mémoire du terminal.

Dans le cas des smartphones, l’information NSSAI est configurée par défaut (Default configured NSSAI).

Dans le cas des terminaux IoT et URLCC, l’information NSSAI devrait être provisionnée afin de limiter l’impact de charge au niveau de la fonction AMF grand public lorsque les terminaux IoT s’allumeront.

Le mobile doit stocker les informations S-NSSAI du HPLMN. Si le mobile est enregistré sur un réseau visité VPLMN, le mobile doit aussi sauvegarder le NSSAI configuré pour ce VPLMN et doit faire la correspondance avec les S-NSSAI qu’il peut exploiter sur le réseau HPLMN. Le mapped NSSAI est utilisé en roaming pour faire la correspondance entre un S-NSSAI spécifique (128 à 255) du réseau H-PLMN et le S-NSSAI correspondant dans le VPLMN.

Lorsque le mobile demande l’établissement d’une session PDU, il transmet dans le message NAS l’information S-NSSAI souhaitée et des règles URSP (UE Route Selection Policy).

 

Le dernier paragraphe sera traité dans un autre article.

Le réseau 5G – 5GS

Le réseau 5G (5G System) se compose d’un accès Radio (NG-RAN : Next Generation RAN) et d’un cœur réseau (5G Core).

I. L’accès radio 5G

L’accès radio 5G est constitué de stations de base de nouvelle génération qui forment le nœud de connexion des mobiles avec le cœur réseau 5G (5GC)

Les mobiles UE communiquent avec les stations de base soient par un lien radio 5G, soit par un lien radio 4G. Si la communication est en 5G, la station de base se nomme gNB (next Generation Node Base Station), si la communication est en 4G, la station de base est une station de base 4G eNB évoluée pour s’interconnecter avec le cœur réseau 5G. La station de base se nomme ng-eNb (Next Generation eNb).

Les fonctions de la station de base gNb sont  assez similaires avec l’entité eNB. Cependant, les différences concernent la gestion de la qualité de service par flux et non par support (bearer) et la gestion des tranches de réseau (Slices) sur l’interface radio.

Pour rappel, un slice est composé d’instances logiques du réseau mobile permettant d’apporter un service réseau de manière efficace en vue de répondre à une qualité de service QoS spécifique à ce service (se référer à l’article Network Slicing).

II. Le cœur réseau 5G (5GC)

Le cœur réseau 5G est adapté pour la virtualisation du réseau et s’appuie sur le découpage du plan de contrôle (Control Plane) et du plan utilisateur (User Plane) définit dans l’architecture CUPS.

Par comparaison avec la 4G CUPS, on pourrait dire que  :

  • L’entité AMF (Access and Mobility Managmenent Function) reprend le rôle de l’entité MME. L’entité AMF établit une connexion NAS avec le mobile UE et a pour rôle d’enregistrer (attachement) les mobiles UE et de gérer la localisation des mobiles sur le réseau 3GPP et/ou non 3GPP.
  • L’entité SMF (Session Management Funtion) reprend le rôle de l’entité SGW-C et PGW-C. L’entité SMF permet de contrôler les sessions PDN. L’entité SMF est choisie par l’entité AMF puisque l’entité AMF  gère la signalisation NAS avec le mobile. L’entité SMF est responsable de la gestion du plan de contrôle. L’entité SMF a une interface avec l’entité qui gère la politique des flux (PCF : Policy Charging Function).

Le plan de transport est composé de passerelles de données qui réalise des mesures sur les données transportées et réalise l’interconnexion avec les réseaux Data (PDN). Dans l’architecture CUPS, les fonctions du plan de transport sont gérées par les entités SGW-U et PGW-U. Pour le cœur réseau 5G, les fonctions du plan de transport sont à la charge de l’entité UPF (User Plane Function). L’entité UPF communique avec l’entité SMF par l’interfae Sx et selon le protocole PFCP. Se référer à l’article présentant l’architecture CUPS.

L’entité PCRF de l’architecture 4G permet de définir les règles de contrôle et les politiques de flux avec l’entité SGW/PGW. En 5G, l’entité PCRF se renomme PCF et permet de contrôler les flux à la fois au niveau de l’entité SMF mais également au niveau de l’entité AMF afin de pouvoir apporter une meilleure granularité sur les flux autorisés en prenant en compte la localisation du mobile UE.

Le profil utilisateur (son abonnement, ses droits, …) sont sauvegardées dans une base de données UDR accessible via l’entité UDM (Unified Data Management). L’entité UDM conserve les profils de sessions de données (sessions PDU) et de l’entité AMF sur laquelle est attachée le mobile UE (éventuellement les entités AMF pour un accès 3GPP et non 3GPP sur un autre opérateur).

L’enregistrement du mobile nécessite une double authentification réalisée au niveau de l’entité AMF et du mobile UE à partir de vecteurs d’authentifications fournies par l’entité AUSF (AUthentication Server Function).

Enfin, l’entité NSSF (Network Slice Selection Function) est une entité permettant d’assister l’entité AMF de la sélection des instances logiques du réseau pour une tranche de réseau (slice) défini.

La figure 1 présente l’architecture 5G et les interfaces entre chaque entité.

Figure 1 : L’architecture du réseau 5G point à point (R.15)