Conditions requises pour concevoir des réseaux mobiles privés

Cet article vous aide à concevoir et à préparer l’implémentation d’un réseau 4G privé ou 5G basé sur Azure Private 5G Core (AP5GC). Il vise à fournir une compréhension de la façon dont ces réseaux sont construits et les décisions que vous devez prendre au fur et à mesure que vous planifiez votre réseau.

Azure Private MEC et Azure Private 5G Core

Azure Private Multi-Access Edge Compute (MEC) est une solution qui combine les services de calcul, de mise en réseau et d’application Microsoft dans un déploiement en local d’entreprise (périphérie). Ces déploiements de périphérie sont gérés de manière centralisée à partir du cloud. Azure Private 5G Core est un service Azure au sein d’Azure Private Multi-access Edge Compute (MEC) qui fournit des fonctions réseau de base 4G et 5G à la périphérie de l’entreprise. Sur le site de périphérie de l’entreprise, les appareils s’attachent sur un réseau d’accès radio cellulaire (RAN) et sont connectés via le service Azure Private 5G Core aux réseaux, applications et ressources en amont. Si vous le souhaitez, les appareils peuvent utiliser la fonctionnalité de calcul locale fournie par Azure Private MEC pour traiter les flux de données à très faible latence, tous sous le contrôle de l’entreprise.

Diagram displaying the components of a private network solution. UEs, RANs and sites are at the edge, while Azure region management is in the cloud.

Conditions requises pour un réseau mobile privé

Les fonctionnalités suivantes doivent être présentes pour permettre à l’équipement utilisateur de s’attacher à un réseau cellulaire privé :

  • L’UE doit être compatible avec le protocole et la bande de spectre sans fil utilisés par le réseau d’accès radio (RAN).
  • L’UE doit contenir un module d’identité d’abonné (SIM). La carte SIM est un élément de chiffrement qui stocke l’identité de l’appareil.
  • Il doit y avoir un RAN, qui envoie et reçoit le signal cellulaire, à toutes les parties du site d’entreprise qui contiennent des UE nécessitant un service.
  • Il doit y avoir une instance de cœur de paquet connectée au runtime d’exécution et à un réseau amont. Le Packet Core est responsable de l’authentification des cartes SIM de l’UE à mesure qu’elles se connectent sur le RAN et demandent le service à partir du réseau. Il applique la stratégie aux flux de données résultants vers et depuis les UEs ; par exemple, pour définir une qualité de service.
  • Le RAN, le Packet Core et l’infrastructure réseau en amont doivent être connectés via Ethernet afin qu’ils puissent passer le trafic IP entre eux.
  • Le site hébergeant le cœur de paquets doit disposer d’une connexion continue et haute vitesse à Internet (100 Mbits/s minimum) pour permettre la gestion des services, la télémétrie, les diagnostics et les mises à niveau.

Conception d’un réseau mobile privé

Les sections suivantes décrivent les éléments du réseau que vous devez prendre en compte et les décisions de conception que vous devez prendre en vue du déploiement du réseau.

Topologie

La conception et l’implémentation de votre réseau local constituent une partie fondamentale de votre déploiement AP5GC. Vous devez prendre des décisions de conception réseau pour prendre en charge votre cœur de paquets AP5GC et toutes les autres charges de travail de périphérie. Cette section décrit certaines décisions que vous devez prendre en compte lors de la conception de votre réseau et fournit des exemples de topologies réseau. Le diagramme suivant illustre une topologie de réseau de base.

Diagram of a basic network topology.

Considérations sur la conception

Lorsqu’il est déployé sur azure Stack Edge Pro GPU (ASE), AP5GC utilise le port physique 5 pour l’accès aux signaux et données (points de référence 5G N2 et N3 points de référence/4G S1 et S1-U) et le port 6 pour les données principales (points de référence SGi 5G N6/4G). Si plus de six réseaux de données sont configurés, le port 5 est également utilisé pour les données de base.

AP5GC prend en charge les déploiements avec ou sans routeurs de couche 3 sur les ports 5 et 6. Cela est utile pour éviter un matériel supplémentaire sur des sites de périphérie plus petits.

  • Il est possible de connecter directement le port ASE 5 aux nœuds RAN (back-to-back) ou via un commutateur de couche 2. Lorsque vous utilisez cette topologie, vous devez configurer l’adresse eNodeB/gNodeB comme passerelle par défaut sur l’interface réseau ASE.
  • De même, il est possible de connecter le port ASE 6 à votre réseau principal via un commutateur de couche 2. Lorsque vous utilisez cette topologie, vous devez configurer une application ou une adresse arbitraire sur le sous-réseau en tant que passerelle côté ASE.
  • Vous pouvez également combiner ces approches. Par exemple, vous pouvez utiliser un routeur sur le port ASE 6 avec un réseau de couche 2 plate sur le port ASE 5. Si un routeur de couche 3 est présent dans le réseau local, vous devez le configurer pour qu’il corresponde à la configuration de l’ASE.

Lorsqu’il est déployé sur Azure Stack Edge 2 (ASE 2), AP5GC utilise le port physique 3 pour accéder aux signaux et données (points de référence 5G N2 et N3 points de référence/4G S1 et S1-U) et le port 4 pour les données principales (points de référence SGi 5G N6/4G). Si plus de six réseaux de données sont configurés, le port 3 est également utilisé pour les données principales.

AP5GC prend en charge les déploiements avec ou sans routeurs de couche 3 sur les ports 3 et 4. Cela est utile pour éviter un matériel supplémentaire sur des sites de périphérie plus petits.

  • Il est possible de connecter directement le port ASE 3 aux nœuds RAN (back-to-back) ou via un commutateur de couche 2. Lorsque vous utilisez cette topologie, vous devez configurer l’adresse eNodeB/gNodeB comme passerelle par défaut sur l’interface réseau ASE.
  • De même, il est possible de connecter le port ASE 4 à votre réseau principal via un commutateur de couche 2. Lorsque vous utilisez cette topologie, vous devez configurer une application ou une adresse arbitraire sur le sous-réseau en tant que passerelle côté ASE.
  • Vous pouvez également combiner ces approches. Par exemple, vous pouvez utiliser un routeur sur le port ASE 4 avec un réseau de couche 2 plate sur le port ASE 3. Si un routeur de couche 3 est présent dans le réseau local, vous devez le configurer pour qu’il corresponde à la configuration de l’ASE.

Sauf si votre cœur de paquets est activé, un périphérique réseau de couche 3 local doit être configuré avec des itinéraires statiques vers les pools IP UE via l’adresse IP N6 appropriée pour le réseau de données attaché correspondant.

Exemples de topologies réseau

Il existe plusieurs façons de configurer votre réseau pour une utilisation avec AP5GC. La configuration exacte varie en fonction de vos besoins et de votre matériel. Cette section fournit des exemples de topologies réseau sur du matériel GPU ASE Pro.

  • Réseau de couche 3 avec traduction d’adresses réseau N6 (NAT)
    Cette topologie de réseau a votre ASE connectée à un appareil de couche 2 qui fournit une connectivité aux passerelles de réseau mobile principal et d’accès (routeurs connectant votre ASE à vos données et réseaux d’accès respectivement). Cette topologie prend en charge jusqu’à six réseaux de données. Cette solution est couramment utilisée, car elle simplifie le routage de couche 3.
    Diagram of a layer 3 network with N6 Network Address Translation (N A T).

  • Réseau de couche 3 sans traduction d’adresses réseau (NAT)
    Cette topologie de réseau est une solution similaire, mais les plages d’adresses IP UE doivent être configurées en tant qu’itinéraires statiques dans le routeur de réseau de données avec l’adresse IP NAT N6 comme adresse de tronçon suivant. Comme avec la solution précédente, cette topologie prend en charge jusqu’à six réseaux de données. Diagram of a layer 3 network without Network Address Translation (N A T).

  • Réseau de couche plate 2
    Le cœur de paquet ne nécessite pas de routeurs de couche 3 ni de fonctionnalités similaires à un routeur. Une autre topologie pourrait entraîner l’utilisation complète des routeurs de passerelle de couche 3 et construire plutôt un réseau de couche 2 dans lequel l’ASE se trouve dans le même sous-réseau que les données et les réseaux d’accès. Cette topologie de réseau peut être une alternative moins coûteuse lorsque vous n’avez pas besoin d’un routage de couche 3. Cela nécessite que la traduction de port d’adresse réseau (NAPT) soit activée sur le cœur de paquet.
    Diagram of a layer 2 network.

  • Réseau de couche 3 avec plusieurs réseaux de données

    • AP5GC peut prendre en charge jusqu’à dix réseaux de données attachés, chacun avec sa propre configuration pour dns (Domain Name System), les pools d’adresses IP UE, la configuration IP N6 et NAT. L’opérateur peut provisionner des UEs comme abonnés dans un ou plusieurs réseaux de données et appliquer une stratégie spécifique au réseau de données et une configuration de qualité de service (QoS).
    • Cette topologie nécessite que l’interface N6 soit divisée en un sous-réseau pour chaque réseau de données ou un sous-réseau pour tous les réseaux de données. Cette option nécessite donc une planification et une configuration minutieuses pour empêcher le chevauchement des plages d’adresses IP réseau de données ou des plages d’adresses IP UE.
      Diagram of layer 3 network topology with multiple data networks.
  • Réseau de couche 3 avec réseau local virtuel et séparation physique de l’accès/du cœur

    • Vous pouvez également séparer le trafic ASE dans des réseaux locaux virtuels, que vous choisissiez ou non d’ajouter des passerelles de couche 3 à votre réseau. Il existe plusieurs avantages pour segmenter le trafic en réseaux locaux virtuels distincts, notamment la gestion du réseau plus flexible et une sécurité accrue.
    • Par exemple, vous pouvez configurer des réseaux locaux virtuels distincts pour la gestion, l’accès et le trafic de données, ou un réseau local virtuel distinct pour chaque réseau de données attaché.
    • Les réseaux locaux virtuels doivent être configurés sur l’équipement réseau de couche 2 ou de couche 3 local. Plusieurs réseaux locaux virtuels sont transférés sur un seul lien à partir du port ASE 5 (réseau d’accès) et/ou 6 (réseau principal), de sorte que vous devez configurer chacun de ces liens en tant que jonction VLAN. Diagram of layer 3 network topology with V L A N s.
  • Réseau de couche 3 avec 7 à 10 réseaux de données

    • Si vous souhaitez déployer plus de six réseaux de données séparés par VLAN, les réseaux de données supplémentaires (jusqu’à quatre) doivent être déployés sur le port ASE 5. Cela nécessite un commutateur partagé ou un routeur qui transporte à la fois l’accès et le trafic principal. Les balises VLAN peuvent être affectées selon les besoins de N2, N3 et chacun des réseaux de données N6.
    • Plus de six réseaux de données ne peuvent être configurés sur le même port.
    • Pour des performances optimales, les réseaux de données avec la charge attendue la plus élevée doivent être configurés sur le port 6. Diagram of layer 3 network topology with 10 data networks.

Il existe plusieurs façons de configurer votre réseau pour une utilisation avec AP5GC. La configuration exacte varie en fonction de vos besoins et de votre matériel. Cette section fournit des exemples de topologies réseau sur du matériel ASE Pro 2.

  • Réseau de couche 3 avec traduction d’adresses réseau N6 (NAT)
    Cette topologie de réseau a votre ASE connectée à un appareil de couche 2 qui fournit une connectivité aux passerelles de réseau mobile principal et d’accès (routeurs connectant votre ASE à vos données et réseaux d’accès respectivement). Cette topologie prend en charge jusqu’à six réseaux de données. Cette solution est couramment utilisée, car elle simplifie le routage de couche 3.
    Diagram of a layer 3 network with N6 Network Address Translation (N A T).

  • Réseau de couche 3 sans traduction d’adresses réseau (NAT)
    Cette topologie de réseau est une solution similaire, mais les plages d’adresses IP UE doivent être configurées en tant qu’itinéraires statiques dans le routeur de réseau de données avec l’adresse IP NAT N6 comme adresse de tronçon suivant. Comme avec la solution précédente, cette topologie prend en charge jusqu’à six réseaux de données. Diagram of a layer 3 network without Network Address Translation (N A T).

  • Réseau de couche plate 2
    Le cœur de paquet ne nécessite pas de routeurs de couche 3 ni de fonctionnalités similaires à un routeur. Une autre topologie pourrait entraîner l’utilisation complète des routeurs de passerelle de couche 3 et construire plutôt un réseau de couche 2 dans lequel l’ASE se trouve dans le même sous-réseau que les données et les réseaux d’accès. Cette topologie de réseau peut être une alternative moins coûteuse lorsque vous n’avez pas besoin d’un routage de couche 3. Cela nécessite que la traduction de port d’adresse réseau (NAPT) soit activée sur le cœur de paquet.
    Diagram of a layer 2 network.

  • Réseau de couche 3 avec plusieurs réseaux de données

    • AP5GC peut prendre en charge jusqu’à dix réseaux de données attachés, chacun avec sa propre configuration pour dns (Domain Name System), les pools d’adresses IP UE, la configuration IP N6 et NAT. L’opérateur peut provisionner des UEs comme abonnés dans un ou plusieurs réseaux de données et appliquer une stratégie spécifique au réseau de données et une configuration de qualité de service (QoS).
    • Cette topologie nécessite que l’interface N6 soit divisée en un sous-réseau pour chaque réseau de données ou un sous-réseau pour tous les réseaux de données. Cette option nécessite donc une planification et une configuration minutieuses pour empêcher le chevauchement des plages d’adresses IP réseau de données ou des plages d’adresses IP UE.

    Diagram of layer 3 network topology with multiple data networks.

  • Réseau de couche 3 avec réseau local virtuel et séparation physique de l’accès/du cœur

    • Vous pouvez également séparer le trafic ASE dans des réseaux locaux virtuels, que vous choisissiez ou non d’ajouter des passerelles de couche 3 à votre réseau. Il existe plusieurs avantages pour segmenter le trafic en réseaux locaux virtuels distincts, notamment la gestion du réseau plus flexible et une sécurité accrue.
    • Par exemple, vous pouvez configurer des réseaux locaux virtuels distincts pour la gestion, l’accès et le trafic de données, ou un réseau local virtuel distinct pour chaque réseau de données attaché.
    • Les réseaux locaux virtuels doivent être configurés sur l’équipement réseau de couche 2 ou de couche 3 local. Plusieurs réseaux locaux virtuels sont transférés sur un seul lien à partir du port ASE 3 (réseau d’accès) et/ou 4 (réseau principal), de sorte que vous devez configurer chacun de ces liens en tant que jonction VLAN.

    Diagram of layer 3 network topology with V L A N s.

  • Réseau de couche 3 avec 7 à 10 réseaux de données

    • Si vous souhaitez déployer plus de six réseaux de données séparés par un réseau local virtuel, les réseaux de données supplémentaires (jusqu’à quatre) doivent être déployés sur le port ASE 3. Cela nécessite un commutateur partagé ou un routeur qui transporte à la fois l’accès et le trafic principal. Les balises VLAN peuvent être affectées selon les besoins de N2, N3 et chacun des réseaux de données N6.
    • Plus de six réseaux de données ne peuvent être configurés sur le même port.
    • Pour des performances optimales, les réseaux de données avec la charge attendue la plus élevée doivent être configurés sur le port 4.

    Diagram of layer 3 network topology with 10 data networks.

Sous-réseaux et adresses IP

Vous pouvez avoir des réseaux IP existants sur le site d’entreprise avec lequel le réseau cellulaire privé devra s’intégrer. Cela peut signifier, par exemple :

  • Sélection de sous-réseaux IP et d’adresses IP pour AP5GC qui correspondent à des sous-réseaux existants sans conflit d’adresses.
  • Ségregating du nouveau réseau via des routeurs IP ou à l’aide de l’espace d’adressage RFC 1918 privé pour les sous-réseaux.
  • Affectation d’un pool d’adresses IP spécifiquement pour une utilisation par des UEs lorsqu’elles s’attachent au réseau.
  • À l’aide de la traduction de port d’adresse réseau (NAPT), sur le cœur de paquet lui-même ou sur un périphérique réseau amont tel qu’un routeur de bordure.
  • Optimisation du réseau pour les performances en choisissant une unité de transmission maximale (MTU) qui réduit la fragmentation.

Vous devez documenter les sous-réseaux IPv4 qui seront utilisés pour le déploiement et accepter les adresses IP à utiliser pour chaque élément de la solution, ainsi que sur les adresses IP qui seront allouées aux UE lors de leur attachement. Vous devez déployer (ou configurer des routeurs et des pare-feu existants) sur le site d’entreprise pour autoriser le trafic. Vous devez également convenir de la façon et de l’emplacement où des modifications de NAPT ou MTU sont requises dans le réseau, et planifier la configuration du routeur/pare-feu associée. Pour plus d’informations, consultez Effectuer les tâches préalables pour le déploiement d’un réseau mobile privé.

Accès réseau

Votre conception doit refléter les règles de l’entreprise sur les réseaux et les ressources qui doivent être accessibles par le RAN et les UE sur le réseau 5G privé. Par exemple, ils peuvent être autorisés à accéder au DNS (Domain Name System), au protocole DHCP (Dynamic Host Configuration Protocol), à Internet ou à Azure, mais pas à un réseau local (LAN) des opérations d’usine. Vous devrez peut-être organiser l’accès à distance au réseau afin de pouvoir résoudre les problèmes sans nécessiter de visite de site. Vous devez également prendre en compte la façon dont le site d’entreprise sera connecté à des réseaux amont tels qu’Azure pour la gestion et/ou pour accéder à d’autres ressources et applications en dehors du site d’entreprise.

Vous devez être d’accord avec l’équipe d’entreprise sur laquelle les sous-réseaux et adresses IP sont autorisés à communiquer entre eux. Ensuite, créez une configuration de plan de routage et/ou de liste de contrôle d’accès (ACL) qui implémente cet accord sur l’infrastructure IP locale. Vous pouvez également utiliser des réseaux locaux virtuels (VLAN) pour partitionner des éléments au niveau de la couche 2, en configurant votre infrastructure switch pour affecter des ports connectés à des réseaux locaux virtuels spécifiques (par exemple, pour placer le port Azure Stack Edge utilisé pour l’accès à l’exécution dans le même réseau local virtuel que les unités RAN connectées au commutateur Ethernet). Vous devez également convenir avec l’entreprise de configurer un mécanisme d’accès, comme un réseau privé virtuel (VPN), qui permet à votre personnel de support technique de se connecter à distance à l’interface de gestion de chaque élément de la solution. Vous avez également besoin d’un lien IP entre Azure Private 5G Core et Azure pour la gestion et la télémétrie.

Conformité du RAN

Le ran que vous utilisez pour diffuser le signal sur le site d’entreprise doit respecter les réglementations locales. Par exemple, cela peut signifier :

  • Les unités RAN ont terminé le processus d’homologation et ont reçu l’approbation réglementaire pour leur utilisation sur une bande de fréquences spécifique dans un pays/région.
  • Vous avez reçu l’autorisation pour le RAN de diffuser à l’aide du spectre à un certain emplacement, par exemple, par un opérateur de télécommunications, une autorité de réglementation ou par le biais d’une solution technologique comme un système d’accès au spectre (SAS).
  • Les unités de RAN d’un site ont accès à des sources de minutage de haute précision, comme le protocole PTP (Precision Time Protocol) et les services de localisation GPS.

Vous devez demander à votre partenaire RAN les pays/régions et les bandes de fréquence pour lesquels le RAN est approuvé. Vous pouvez constater que vous devez utiliser plusieurs partenaires RAN pour couvrir les pays et régions dans lesquels vous fournissez votre solution. Bien que le ran, UE et le cœur de paquet communiquent tous à l’aide de protocoles standard, nous vous recommandons d’effectuer des tests d’interopérabilité pour le protocole 4G Long-Term Evolution (LTE) spécifique ou 5G autonome (SA) entre Azure Private 5G Core, UEs et RAN avant tout déploiement sur un client d’entreprise.

Votre RAN transmet une identité de réseau mobile terrestre public (ID PLMN) à tous les UE de la bande de fréquences qu’il est configuré pour utiliser. Vous devez définir l’ID PLMN et confirmer votre accès au spectre. Dans certains pays/régions, le spectre doit être obtenu auprès du régulateur national/régional ou de l’opérateur de télécommunications titulaire. Par exemple, si vous utilisez le spectre CBRS (Citizens Broadband Radio Service) de bande 48, vous devrez peut-être travailler avec votre partenaire RAN pour déployer un proxy de domaine SAS (Spectrum Access System) sur le site d’entreprise afin que l’exécution puisse en permanence case activée qu’elle est autorisée à diffuser.

Unités de transmission maximales (MTU)

Les unités de transmission maximales (MTU) sont une propriété d’une liaison IP. Cette valeur est configurée sur les interfaces à chaque extrémité de la liaison. Les paquets qui dépassent le MTU configuré d’une interface sont divisés en paquets plus petits via la fragmentation IPv4 avant l’envoi et sont ensuite réassemblés à leur destination. Toutefois, si le MTU configuré d’une interface est supérieur au MTU pris en charge par la liaison, le paquet ne peut pas être transmis correctement.

Pour éviter les problèmes de transmission provoqués par la fragmentation IPv4, un cœur de paquet 4G ou 5G indique aux UEs ce qu’ils doivent utiliser. Toutefois, les UEs ne respectent pas toujours le MTU signalé par le cœur de paquet.

Les paquets IP d’UEs sont tunnelés à partir du ran, ce qui ajoute une surcharge à partir de l’encapsulation. La valeur MTU de l’UE doit donc être inférieure à la valeur MTU utilisée entre le runtime d’exécution et le cœur de paquet pour éviter les problèmes de transmission.

Les RAN sont généralement préconfigurés avec un MTU de 1500. Le MTU UE par défaut du cœur de paquet est de 1440 octets pour permettre la surcharge d’encapsulation. Ces valeurs optimisent l’interopérabilité RAN, mais risquent que certaines UEs n’observent pas le MTU par défaut et génèrent des paquets plus volumineux qui nécessitent une fragmentation IPv4 et qui peuvent être supprimés par le réseau. Si vous êtes affecté par ce problème, il est vivement recommandé de configurer le runtime d’exécution pour utiliser une MTU de 1560 ou une version ultérieure, ce qui permet une surcharge suffisante pour l’encapsulation et évite la fragmentation avec un ue à l’aide d’un MTU standard de 1500.

Vous pouvez également modifier l’ue MTU signalée par le cœur de paquet. Nous vous recommandons de définir le MTU sur une valeur dans la plage prise en charge par vos UEs et 60 octets sous le signal MTU signalé par le runtime d’exécution. Notez les points suivants :

  • Le réseau de données (N6) est automatiquement mis à jour pour correspondre au MTU UE.
  • Le réseau d’accès (N3) est automatiquement mis à jour pour correspondre à l’UE MTU plus 60.
  • Vous pouvez configurer une valeur comprise entre 1280 et 1930 octets.

Pour modifier l’UE MTU signalé par le cœur de paquet, consultez Modifier une instance de cœur de paquet.

Couverture du signal

Les UE doivent être en mesure de communiquer avec le RAN à partir de n’importe quel emplacement sur le site. Cela signifie que les signaux doivent se propager efficacement dans l’environnement, y compris en tenant compte des obstacles et de l’équipement, pour soutenir le déplacement des UE dans le site (par exemple, entre les zones intérieures et extérieures).

Vous devez effectuer une étude de site auprès de votre partenaire de RAN et de l’entreprise pour vous assurer que la couverture est adéquate. Assurez-vous de bien comprendre les fonctionnalités des unités de RAN dans différents environnements et toutes les limites (par exemple, sur le nombre d’UE attachés qu’une unité peut prendre en charge). Si vos UE se déplacent sur le site, vous devez également vérifier que le RAN prend en charge le transfert X2 (4G) ou Xn (5G), ce qui permet à l’UE de passer en toute transparence entre la couverture fournie par deux unités RAN. Si le ran ne prend pas en charge X2 (4G) ou Xn (5G), ran doit prendre en charge S1 (4G) et N2 (5G) pour la mobilité UE. Notez que les UE ne peuvent pas utiliser ces techniques de transfert pour se déplacer entre un réseau d’entreprise privé et le réseau cellulaire public offert par un opérateur de télécommunications.

SIM

Chaque UE doit présenter une identité au réseau, encodée dans un module d’identité d’abonné (SIM). Les SIM sont disponibles dans différents facteurs de forme physiques et au format logiciel uniquement (eSIM). Les données encodées sur la carte SIM doivent correspondre à la configuration du runtime d’exécution et des données d’identité approvisionnées dans Azure Private 5G Core.

Obtenez des cartes SIM dans des formats compatibles avec les UE et programmés avec l’ID PLMN et les clés que vous souhaitez utiliser pour le déploiement. Les cartes SIM physiques sont largement disponibles sur le marché libre à un coût relativement faible. Si vous préférez utiliser des ESIMs, vous devez déployer la configuration et l’infrastructure d’approvisionnement eSIM nécessaires afin que les UEs puissent se configurer avant qu’elles ne s’attachent au réseau cellulaire. Vous pouvez utiliser les données d’approvisionnement que vous recevez de votre partenaire SIM pour provisionner des entrées correspondantes dans Azure Private 5G Core. Étant donné que les données SIM doivent être sécurisées, les clés de chiffrement utilisées pour approvisionner des siMs ne sont pas lisibles une fois définies. Vous devez donc envisager la façon dont vous les stockez au cas où vous deviez reprovisionner les données dans Azure Private 5G Core.

Automatisation et intégration

La création de réseaux d’entreprise à l’aide de l’automatisation et d’autres techniques programmatiques permet de gagner du temps, de réduire les erreurs et de produire de meilleurs résultats. Ces techniques fournissent également un chemin de récupération en cas d’échec de site nécessitant la reconstruction du réseau.

Nous vous recommandons d’adopter une approche programmatique, infrastructure en tant que code pour vos déploiements. Vous pouvez utiliser des modèles ou l’API REST Azure pour générer votre déploiement à l’aide de paramètres comme entrées avec des valeurs que vous avez collectées pendant la phase de conception du projet. Vous devez enregistrer les informations d’approvisionnement, comme les données SIM, la configuration des commutateurs/routeurs et les stratégies réseau dans un format lisible par machine afin qu’en cas de défaillance, vous puissiez réappliquer la configuration de la même manière que vous l’avez fait à l’origine. Une autre bonne pratique pour récupérer en cas de défaillance consiste à déployer un serveur Azure Stack Edge de secours afin de réduire le temps de récupération en cas d’échec de la première unité ; vous pouvez ensuite utiliser vos modèles et entrées enregistrés pour recréer rapidement le déploiement. Pour plus d’informations sur le déploiement d’un réseau à l’aide de modèles, consultez Démarrage rapide : Déployer un réseau mobile privé et un site - Modèle ARM.

Vous devez également prendre en compte la façon dont vous intégrez d’autres produits et services Azure au réseau d’entreprise privé. Ces produits incluent l’ID Microsoft Entra et le contrôle d’accès en fonction du rôle (RBAC), où vous devez prendre en compte la façon dont les locataires, les abonnements et les autorisations de ressources s’alignent sur le modèle métier qui existe entre vous et l’entreprise, ainsi que votre propre approche de la gestion du système client. Par exemple, vous pouvez utiliser Azure Blueprints pour configurer les abonnements et le modèle de groupe de ressources qui convient le mieux à votre organisation.

Étapes suivantes