Cas d’usage et architecture de référence

L’architecture xHaul 5G comprend trois segments physiques : Fronthaul, Midhaul et Backhaul, comme illustré sur la Figure 1.

La conception validée répond à la convergence du xHaul 5G en tirant parti de technologies de routage de segments transparentes.

Le segment fronthaul active la connectivité de couche 2 entre l’unité radio ouverte (O-RU) (site cellulaire) et l’unité distribuée ouverte (O-DU) (représentée par RU et DU dans la Figure 1) dans le réseau d’accès radio (RAN), ce qui leur permet de communiquer pour le trafic de contrôle, de données et de gestion. Il assure également la synchronisation du temps et de la fréquence entre les éléments RAN. Étant donné qu’une faible latence est cruciale (elle doit être inférieure à 150 μs entre RU et DU), le segment Fronthaul comporte très peu d’éléments réseau, généralement limités à un ou deux sauts. La solution actuelle pour le transport fronthaul 5G est basée sur l’architecture de l’Alliance O-RAN [ORAN-WG9. XPSAAS.0-v00.01].

Le segment midhaul de l’infrastructure réseau 5G définit le RAN désagrégé, responsable de la prise en charge de la communication entre l’unité centralisée gNodeB (gNB-CU) et gNB-DU. Le gNB désagrégé se compose du plan de contrôle O-CU (O-CU-CP) et du plan utilisateur CU (O-CU-UP), connectés aux interfaces O-DU correspondantes sur F1-C (contrôle) et F1-U (données). Interconnexion CU-CP et CU-UP par l’interface E1 spécifiée par le projet de partenariat de 3e génération (3GPP) TS 38.401.

Le réseau de backhaul définit l’infrastructure qui relie le cœur mobile 5G à CU. Les plans de contrôle et d’utilisateur sont affectés à des VPN uniques pour la séparation entre les données de l’utilisateur et le plan de contrôle 3GPP.

Les architectures Midhaul et Backhaul ne nécessitent pas les mêmes budgets de latence que Fronthaul et sont représentées sous forme de topologies en anneau, maillées, en étoile ou Spine et Leaf.

La conception validée établit ces domaines et rôles d’équipement en suivant les recommandations de l’Alliance O-RAN [ORAN-WG9. XPSAAS.0-v00.01]. Les attributs clés des architectures de réseau de transport sont pris en compte avec l’établissement de budgets de latence stricts, la hiérarchisation du trafic, la tolérance aux pertes de paquets, la gestion des pannes et les exigences en matière de bande passante pour répondre aux demandes sur les segments Fronthaul, Midhaul et Backhaul. Pour la JVD xHaul 5G, l’accent est mis sur l’architecture et les services de transport de backhaul mobile (MBH) à grande échelle. L’infrastructure devrait prendre en charge divers services résidentiels, commerciaux et wholesale en même temps que les applications des opérateurs mobiles 4G/5G de bout en bout. Le JVD propose un mappage de services sensible aux couleurs qui permet une orientation granulaire du trafic de bout en bout sur des domaines disparates.

L’évolution du RAN englobe des architectures 4G distribuées, centralisées et virtuelles qui doivent coexister avec l’O-RAN désagrégé 5G. Ces divers écosystèmes permettent des points d’insertion flexibles pour les composants O-DU/O-CU. La dissection des divisions fonctionnelles RAN proposée par le 3GPP et l’O-RAN pour la prise en charge des modèles de déploiement désagrégés sort du domaine d’application du présent document, mais constitue un attribut important de l’architecture proposée.

Figure 2 telle que référencée par l’O-RAN Alliance [O-RAN. GT 9. XPSAAS-v02.00], résume les scénarios de déploiement RAN conformément à la norme UIT-T GSTP-TN5G pour la prise en charge simultanée de la 4G et de la 5G.

Ce JVD n’essaie pas de couvrir toutes les possibilités et déploie plutôt un modèle de backhaul intégré. Des points d’insertion supplémentaires pour les architectures fractionnées peuvent être conçus pour prendre en charge la désagrégation entre les segments Midhaul et Backhaul en étendant les services appropriés.

La capacité à prendre en charge des architectures réseau concurrentes complexes donne la priorité à la fourniture de solutions transparentes de bout en bout. La solution 5G xHaul JVD met l’accent sur la démonstration de solutions de pré-découpage du réseau, dans lesquelles les services de superposition peuvent être mappés au transport sous-jacent sur un réseau mobile convergé transparent.

La figure 3 montre un réseau MBH de bout en bout transparent, modelé sur la topologie commune [O-RAN. GT 9. XPSAAS-v02.00], qui définit quatre segments d’infrastructure de transport : l’accès, la préagrégation, l’agrégation et le cœur de transport.

Définitions de la topologie :

• Accès : inclut les routeurs ACX710 et les nœuds d’accès ACX5448 (AN1, AN2, AN3).
• Pré-agrégation : inclut les routeurs de site ACX5448 hub AG1.1 et AG1.2.
• Agrégation : inclut les routeurs d’agrégation AG2.1/AG2.2 (MX204) et AG3.1/AG3.2 (MX10003/MX480).
• Réseau central : comprend les routeurs centraux CR1/CR2 (PTX1000/MX10003) et le routeur de service SAG (MX10003).

La topologie d’accès Spine-leaf établit le segment Fronthaul 5G avec des routeurs de site hub (HSR) redondants (AG1.1 et AG1.2) dans la Figure 3 et regroupe les rôles de pré-agrégation 4G et de TGV 5G. Les nœuds AG1 de pré-agrégation incluent des points d’insertion d’accès (RT) supplémentaires pour la mise à l’échelle de l’environnement. Les segments Midhaul et Backhaul, représentés par des topologies en anneau, sont combinés pour inclure les rôles d’agrégation et de cœur.

La sous-couche est constituée d’un assemblage L-ISIS, Prefix-SID et BGP-LU sans soudure au niveau des nœuds de bordure, comme illustré sur la Figure 4 :

• Les nœuds d’accès et les segments de pré-agrégation se trouvent dans le domaine ISIS de niveau 1.
• Le segment de pré-agrégation comprend les routeurs ISIS de couche 1/2.
• Les segments de pré-agrégation, d’agrégation et centraux résident dans un domaine ISIS de niveau 2.
• La redondance des nœuds TI-LFA est prise en charge au sein de chaque instanciation de domaine.
• La segmentation sous-jacente Flex-Algo permet de partitionner davantage le réseau SR-MPLS xHaul en chemins colorés à l’aide de deux définitions d’algorithmes flexibles (FAD), à savoir le rouge (128) et le bleu (129) à l’aide des mesures IGP et TE.

Bien que les solutions BGP-LU et Inter-AS puissent répondre aux exigences E2E transparentes, elles ne satisfont pas aux SLA d’ingénierie de trafic orientés services. BGP-CT assure le découpage du réseau et l’orientation dynamique du trafic en fonction des classes de transport, qui sont déterminées par les attributs de la cible de route.

Grâce à BGP-CT, les services de superposition sensibles aux couleurs sont mappés de bout en bout sur l’ensemble des domaines. Les classes de transport d’or et de bronze sont définies de manière à ce que l’or soit mappé à des chemins qui n’incluent que l’algo rouge (128) et que le bronze soit mappé à des chemins qui n’incluent que l’algo bleu (129). Dans le cas où les chemins gold ou bronze ne sont pas disponibles, le réseau est conçu pour se replier sur la sélection de chemin inet.3 (indépendant des couleurs).

La conception validée inclut les services de superposition suivants :

• Le VPN de couche 3 comprend des points de terminaison sur tous les nœuds d’accès, AG1.1/AG1.2, et SAG. L3VPN prend en charge le mappage de couleurs BGP-CT par préfixe. Les routes reçues avec protocol direct ou OSPF sont mappées à la classe de transport gold et traversent la tranche flex-algo indiquée en rouge (128), tandis que les routes apprises par BGP correspondant à des attributs spécifiques sont mappées à la classe de transport bronze et à l’algo bleu (129).
• Le VPN de couche 2 comprend des points de terminaison sur tous les nœuds d’accès, AG1.1/AG1.2, et SAG. MP-BGP L2VPN prend en charge la cartographie colorimétrique BGP-CT. Toutes les routes client exportées par l’instance L2VPN sont mappées à des classes de transport Gold ou Bronze et traversent uniquement la tranche flex-algo correspondante.
• Le circuit de couche 2 comprend des points de terminaison sur AN3, AG1.1/AG1.2 et SAG. L2Circuit prend en charge BGP-CT en tant qu’affectation de mappage communautaire. Les L2Circuits se voient attribuer une classe de trafic or ou bronze et ne traversent que l’algo correspondant.
• BGP-VPLS inclut des points de terminaison sur AN1, AN3, AG1.1/AG1.2 et SAG. Le VPLS est déployé pour traverser la topologie en tant que services indépendants des couleurs, ce qui démontre la coexistence avec le mappage de services sensibles aux couleurs. BGP-VPLS prend en charge le transport avec classe BGP avec mappage de service à partir de Junos OS version 21.4R1 et versions ultérieures.