Tutoriel pour comprendre l'architecture SBA du réseau 5G : SOA et Microservices

| Frédéric Launay | Mickael Baron |

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.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum Commentez .

- Titre : Tutoriel pour comprendre l'architecture SBA du réseau 5G : SOA et Microservices

- Auteurs : Frédéric Launay, Mickael Baron

- Parution : 29 mars 2021

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2021 Frédéric Launay. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. L'architecture du réseau 4G

- III. Évolution du réseau de mobiles vers l'architecture SOA et l'architecture microservice

- III-A. L'architecture SOA

- III-B. L'architecture en microservices

- III-C. Microservices : les bonnes pratiques du SOA

- IV. Architecture des réseaux de mobile 5G

- IV-A. Architecture SBA

- IV-B. Les fonctions réseau NF (Network Function)

- V. Conclusion

- VI. Remerciements

I - Introduction

La nouvelle architecture 5G a été pensée pour pouvoir ajouter des briques logicielles innovantes et une mise sur le marché rapide de ces nouvelles fonctionnalités. Ainsi, à l’instar des solutions proposées par Amazon ou Microsoft Azure, 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.

II - L'architecture du réseau 4G

Le cœur de réseau de mobiles 4G (voir figure ci-dessous) est construit à partir des entités fonctionnelles suivantes.

- L’entité MME (Mobility Management Entity) a pour rôle de gérer :

- l’attachement des mobiles ;

- 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 bearers avec le SGW, fournit 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 bearers dédiés et la gestion dynamique de la facturation.

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'a 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). À titre d'exemple, la figure précédente 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 avec les 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 et 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. À 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 précédente, 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.

Nous donnons ci-dessous deux exemples d'entités.

- L'identification, l'authentification et les droits d'accès du mobile sont gérés 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 précédente).

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 précédente). Les informations à transmettre sont normalisées.

Cette architecture monolithe modulaire facilite l'ajout de nouvelles entités fonctionnelles. 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ée, 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 Capabilities 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.

À travers cette 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 »).

À 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.

III - Évolution du réseau de mobiles vers l'architecture SOA et l'architecture microservice

III-A - L'architecture SOA

Une architecture orientée services (SOA) est une architecture logicielle qui fait référence à une application composée d'agents logiciels indépendants 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 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és 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 lesquels 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.

III-B - L'architecture en 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 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 containérisation 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 redéployée ;

- de l'élasticité puisqu'il est possible de dimensionner dynamiquement le réseau en fonction du nombre de sollicitations (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).

À l'instar d'un bus d'intégration, l'architecture microservice utilise un bus d'évènements 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 les uns des autres.

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).

Le microservice est sans état (stateless), une même requête produit toujours la même réponse. Ainsi, le bus d'évènements 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ée 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.

III-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.

À l'instar de l'architecture SOA, l'architecture microservice est conçue sur un ensemble de fonctions faiblement couplées.

IV - Architecture des réseaux de mobile 5G

IV-A - 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 suivante, on présente à gauche l'architecture monolithique traditionnelle, et deux solutions complémentaires : la virtualisation des fonctions réseau (NFV : Network Function Virtualization) et la méthodologie Cloud Native.

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 les 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 suivants pour les applications Cloud Native :

- une évolutivité facilitée par une architecture modulaire (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 machines 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 (4).

La mise en place des fonctions réseau, la supervision (monitoring) nécessitent 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 fonctions réseau 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 continu 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 plusieurs versions d'une application, chaque version étant gérée par un serveur de distribution (un serveur référentiel comme Git) 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.

L'environnement complet est représenté sur la figure suivante(5).

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 (6).

IV-B - Les fonctions réseau NF (Network Function)

Les fonctions réseau NF se composent 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 et GTP-C du réseau de mobiles 4G. Les fonctions réseau NF communiquent à travers l'interface SBI grâce à un système d'API, principalement le JSON.

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 fonctions 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 fonctions se nomme NRF (Network Repository Function). Il offre un service de découverte des fonctions du réseau de mobiles 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).

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 (7).

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).

V - Conclusion

Si le cœur de réseau 5G présente beaucoup d'analogies fonctionnelles avec le cœur de réseau 4G, l'évolution majeure consiste en un découpage de fonctions 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 permettent 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.

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

La figure ci-dessous fait une synthèse des améliorations ainsi apportées par l'architecture SBA(9).

VI - Remerciements

Cet article a été publié avec l'aimable autorisation de Frédéric Launay. L'article original peut être vu sur son blog.

Nous remercions également dourouc05 pour la relecture de l'article et Claude Leloup pour la relecture orthographique de cet article.

(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)https://www.redhat.com/fr/topics/devops/what-is-ci-cd

(5)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

(6)https://5g-monarch.eu/wp-content/uploads/2019/05/5G-MoNArch_761445_D2.3_Final_overall_architecture_v1.0.pdf

(7)https://www.3g4g.co.uk/5G/5Gtech_6004_2017_11_Service-Based-Architecture-for-5G-Core-Networks_HR_Huawei.pdf

(8)http://www.hpe.com/info/5g

(9)Michael Sukachev : https://fr.slideshare.net/MichaelSukachev/soa-vs-microservices-vs-sba