I) Introduction
L’évolution de la 4G vers la 5G n’est pas uniquement une virtualisation des entités 4G (ex: DECOR ou eDECOR – Dedicated Core) mais un déploiement automatisé des fonctions réseaux sur une architecture basée sur les services (SOA).
Une application est dite « native pour le cloud », lorsqu’elle est conçue autour d’instances gérées de façon automatisée dans les clouds privés, publics et hybrides. Aujourd’hui, les entreprises adoptent le Cloud Computing [1] pour améliorer l’évolutivité et la disponibilité de leurs applications.
Le principal avantage d’une stratégie cloud-native est qu’elle permet d’accélérer le développement des applications dont les ressources de calcul sont réparties dans différents environnements [2].
Selon [1], « le cloud computing consiste à exécuter des charges de travail dans des clouds, des environnements qui dissocient, regroupent et partagent des ressources évolutives sur un réseau. »
Les concepteurs DevOps réalisent une architecture composée de ressources en libre-service et à la demande ainsi qu’à l’automatisation du cycle de vie des applications (de la phase de développement jusqu’à la production).
La 5G est dite cloud Native, la 3GPP propose une architecture composée de fonctions réseaux (NF) faiblement couplées. Une fonction réseau peut être découpée en microservices qui communiquent entre elles via des interfaces de programmation d’application (API).
Dans une architecture de microservices, les applications sont décomposées en éléments les plus simples et indépendants.
Les interfaces de programmation d’application (API) sont des ensembles d’outils, de définitions et de protocoles qui facilitent la création de fonctions d’applications (réseau). Elles connectent les producteurs de services et les consommateurs de services sans connaître les détails de leur mise en œuvre [1].
Le modèle DevOps est une approche d’automatisation et de conception de plateformes pour une solution logicielle complexe [3].
II) Cloud Public, privé, hybride, multicloud
Selon [1] :
Cloud Public : Environnements cloud créés à partir de ressources qui n’appartiennent pas à l’utilisateur final et qui peuvent être redistribuées à d’autres clients.
Cloud Privé : Généralement décrits comme des environnements cloud réservés à l’utilisateur final, la plupart du temps à l’intérieur du pare-feu et parfois sur site.
Cloud hybride : Plusieurs environnements cloud qui offrent différents degrés de portabilité, d’orchestration et de gestion de la charge de travail.
Multicloud : Systèmes informatiques qui comprennent au moins deux clouds (privés ou publics) qui peuvent être mis en réseau ou non.
Un cloud public est un pool de ressources virtuelles, créées à partir de matériel détenu et géré par une entreprise tierce, qui sont automatiquement provisionnées et allouées à différents clients via une interface en libre-service. Il s’agit d’une méthode simple qui permet de faire évoluer les charges de travail soumises à des fluctuations imprévues de la demande.
Déploiement de la 5G SA sur un Cloud Public
Les entités du coeur de réseau 2G/3G/4G stockent des informations, nommées contextes, relatives aux utilisateurs ou à l’association de couche transport (Tunnels). Ces contextes doivent être résilientes à toutes pannes.
La 3GPP propose une architecture sans état (Stateless) pour optimiser le déploiement des fonctions réseaux, en découplant le stockage des contextes et les couches applicatives. Les données sont sauvegardées dans des fonctions UDSF (Unstructured Data Storage Function [5]).
A titre d’exemple, le Cloud Public Amazon propose Elasticache et Google propose Google Cloud Memorystore, l’un et l’autre surtout connus pour leur capacité à sauvegarder des données en mémoire rapide de type NoSQL (REDIS : Remote Dictionary Server – Serveur de dictionnaire à distance).
Le découpage du réseau en tranche (Network Slicing) s’appuie sur l’architecture Cloud Native et les technologies SDN/NFV pour apporter des services à faible latence, haut débit, …
Les microservices n’ont pas nécessité de s’appuyer sur des conteneurs, néanmoins les solutions K3s ou K8s apportent plus de la flexibilité et de la scalabilité des fonctions réseaux par rapport aux VM.
Dans le cas de l’architecture NFV [6], une solution basée sur les VM nécessite des gestionnaires spécifiques S-VNFM (vendor-specific VNF manager) ou générique (generic VNF manager) pour la gestion des durées de vie des VMs.
Une application basée sur Kubernetes permet de gérer la durée de vie des conteneurs et des fonctions réseaux NF.
Les conteneurs permettent de gérer efficacement les fonctions du cœur de réseau (AMF/SMF/…).
Par contre les fonctions UPF sont plutôt distribués sur les MEC et la localisation étant imposée, la gestion par VM est plus efficace.
L’approche Cloud Native impose également un seul protocole http2 entre les fonctions réseaux, à l’exception du protocole PFCP sur l’interface N4.
Au niveau du plan de transport, l’établissement d’une session PDU signifie que le réseau 5G transporte du trafic Ethernet, IP ou non structuré. L’utilisation de PoD multi-homed permet d’avoir plusieurs interfaces et permet aussi de gérer différents protocoles (SCTP par exemple)
[1] https://www.redhat.com/fr/topics/cloud
[2] https://www.redhat.com/fr/topics/cloud-native-apps
[3] https://www.redhat.com/fr/topics/cloud-native-apps
[4] https://d1.awsstatic.com/whitepapers/5g-network-evolution-with-aws.pdf
[5] TS 21.195
[6] https://www.etsi.org/technologies/nfv