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 ou 5G privé basé sur Azure Private 5G Core (AP5GC). L’objectif de l’article est de décrire comment sont construits ces réseaux et les décisions que vous devez prendre quand vous planifiez votre réseau.

Azure Private MEC et Azure Private 5G Core

Le calcul de périphérie multi-accès (MEC) privé Azure est une solution qui combine les services de calcul, de réseau et d’application Microsoft dans un déploiement dans les locaux de l’entreprise (la périphérie). Ces déploiements à la 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 du calcul de périphérie multi-accès (MEC) privé Azure qui fournit les fonctions de réseau principal 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 capacité de calcul locale fournie par le calcul MEC privé Azure pour traiter des flux de données à très faible latence, le tout sous le contrôle de l’entreprise.

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 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 Packet Core connectée au RAN et à un réseau en 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 une stratégie aux flux de données résultants en direction et en provenance des UE, 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 l’instance Packet Core doit avoir une connexion haut débit continue à 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 pour préparer le déploiement du réseau.

Topologie

La conception et l’implémentation de votre réseau local sont une partie fondamentale de votre déploiement AP5GC. Vous devez prendre des décisions de conception réseau pour prendre en charge votre instance Packet Core AP5GC et toutes les autres charges de travail périphériques. Cette section décrit certaines décisions que vous devez prendre quand vous concevez votre réseau et fournit des exemples de topologies de réseau. Le diagramme suivant montre une topologie de réseau de base.

Considérations sur la conception

Quand il est déployé sur Azure Stack Edge Pro GPU (ASE), AP5GC utilise le port physique 5 pour signaler l’accès et pour les 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 de base (points de référence 5G N6/4G SGi).

Pour les déploiements haute disponibilité, vous devez utiliser la jonction VLAN, où les réseaux de données sont séparés par des VLAN. Dans cette configuration, toutes les données principales utilisent le port 6. Si vous n’utilisez pas la jonction VLAN et que plus de six réseaux de données sont configurés, le port 5 est utilisé pour les données de base pour les réseaux de données restants.

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 le matériel supplémentaire sur des sites périphériques plus petits.

• Il est possible de connecter directement le port ASE 5 aux nœuds RAN (dos-à-dos) ou via un commutateur de couche 2. Quand 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. Quand vous utilisez cette topologie, vous devez configurer une application ou une adresse arbitraire sur le sous-réseau comme passerelle côté ASE.
• Vous pouvez aussi combiner ces approches. Par exemple, vous pouvez utiliser un routeur sur le port ASE 6 avec un réseau de couche 2 plat 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.

Quand il est déployé sur Azure Stack Edge Pro 2 (ASE 2), AP5GC utilise le port physique 3 pour signaler l’accès et pour les 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 de base (points de référence 5G N6/4G SGi).

Pour les déploiements haute disponibilité, vous devez utiliser la jonction VLAN, où les réseaux de données sont séparés par des VLAN. Dans cette configuration, toutes les données principales utilisent le port 6. Si vous n’utilisez pas la jonction VLAN et que plus de six réseaux de données sont configurés, le port 3 est utilisé pour les données de base pour les réseaux de données restants.

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 le matériel supplémentaire sur des sites périphériques plus petits.

• Il est possible de connecter directement le port ASE 3 aux nœuds RAN (dos-à-dos) ou via un commutateur de couche 2. Quand 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. Quand vous utilisez cette topologie, vous devez configurer une application ou une adresse arbitraire sur le sous-réseau comme passerelle côté ASE.
• Vous pouvez aussi combiner ces approches. Par exemple, vous pouvez utiliser un routeur sur le port ASE 4 avec un réseau de couche 2 plat 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.

À moins que votre instance Packet Core ait la traduction d’adresses réseau (NAT) activée, un appareil réseau de couche 3 local doit être configuré avec des routes statiques vers les pools IP des UE via l’adresse IP N6 appropriée pour le réseau de données attaché correspondant.

Exemples de topologies de réseau

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

• Réseau de couche 3 avec traduction d’adresses réseau (NAT) N6
  Cette topologie de réseau connecte votre ASE à un appareil de couche 2 qui fournit une connectivité aux passerelles principale et d’accès du réseau mobile (routeurs connectant votre ASE à vos réseaux de données et 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.
  

• 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 des UE doivent être configurées comme des routes 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.

• Réseau de couche 2 plat
  L’instance Packet Core ne nécessite pas de routeurs de couche 3 ni de fonctionnalités de type routeur. Une autre topologie peut éviter l’utilisation des routeurs de passerelle de couche 3 et construire à la place un réseau de couche 2 dans lequel l’ASE se trouve dans le même sous-réseau que les réseaux de données et d’accès. Cette topologie de réseau peut être une alternative moins coûteuse quand vous n’avez pas besoin d’un routage de couche 3. Pour cela, la traduction de port d’adresse réseau (NAPT) doit être activée sur l’instance Packet Core.
  

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

  • La configuration recommandée pour les déploiements avec plusieurs réseaux de données consiste à utiliser la jonction VLAN. Dans cette configuration, AP5GC peut prendre en charge jusqu’à dix réseaux de données attachés, chacun avec sa propre configuration pour le DNS (Domain Name System), les pools d’adresses IP d’UE, la configuration IP N6 et NAT. Vous pouvez provisionner des UE selon son abonnement dans un ou plusieurs réseaux de données, et appliquer une stratégie et une configuration de qualité de service (QoS) propres au réseau de données. La jonction VLAN est requise pour les déploiements haute disponibilité.
  • Dans cette topologie, il existe un seul réseau virtuel N6 sur l’ASE sans aucune information IP. Toutes les configurations VLAN et IP sont effectuées lors de la configuration de chaque réseau de données attaché.

• Réseau de couche 3 avec plusieurs réseaux de données sans séparation VLAN.

  • AP5GC peut prendre en charge jusqu’à dix réseaux de données attachés, chacun avec sa propre configuration pour le DNS (Domain Name System), les pools d’adresses IP d’UE, la configuration IP N6 et NAT. Vous pouvez provisionner des UE selon son abonnement dans un ou plusieurs réseaux de données, et appliquer une stratégie et une configuration de qualité de service (QoS) propres au réseau de données.
  • 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 du réseau de données ou des plages d’adresses IP des UE.
    

• Réseau de couche 3 avec séparation par VLAN et physique des réseaux principal et d’accès (accès VLAN)

  • Vous pouvez également séparer le trafic ASE dans des VLAN, que vous choisissiez ou non d’ajouter des passerelles de couche 3 à votre réseau. Il y a plusieurs avantages à la segmentation du trafic en réseaux VLAN distincts, notamment une gestion du réseau plus flexible et une sécurité renforcée.
  • Par exemple, vous pouvez configurer des VLAN distincts pour la gestion, l’accès et le trafic de données, ou un VLAN distinct pour chaque réseau de données attaché.
  • Les VLAN doivent être configurés sur l’équipement réseau de couche 2 ou de couche 3 local. Comme plusieurs VLAN sont transférés sur une seule liaison à partir du port ASE 5 (réseau d’accès) et/ou 6 (réseau principal), vous devez configurer chacune de ces liaisons comme une jonction VLAN.

• Réseau de couche 3 avec 7-10 réseaux de données sans jonction VLAN.

  • Avec la jonction VLAN, tous les noms de domaine sont acheminés via le port 6. La jonction VLAN est requise pour les déploiements haute disponibilité.
  • Sans jonction VLAN, si vous voulez déployer plus de six réseaux de données séparés par des 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 le trafic principal et le trafic d’accès. Les étiquettes VLAN peuvent être attribuées selon les besoins aux réseaux de données N2, N3 et chacun des réseaux de données N6.
  • Pas plus de six réseaux de données 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 lourde doivent être configurés sur le port 6.

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

• Réseau de couche 3 avec traduction d’adresses réseau (NAT) N6
  Cette topologie de réseau connecte votre ASE à un appareil de couche 2 qui fournit une connectivité aux passerelles principale et d’accès du réseau mobile (routeurs connectant votre ASE à vos réseaux de données et 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.
  

• 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 des UE doivent être configurées comme des routes 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.

• Réseau de couche 2 plat
  L’instance Packet Core ne nécessite pas de routeurs de couche 3 ni de fonctionnalités de type routeur. Une autre topologie peut éviter l’utilisation des routeurs de passerelle de couche 3 et construire à la place un réseau de couche 2 dans lequel l’ASE se trouve dans le même sous-réseau que les réseaux de données et d’accès. Cette topologie de réseau peut être une alternative moins coûteuse quand vous n’avez pas besoin d’un routage de couche 3. Pour cela, la traduction de port d’adresse réseau (NAPT) doit être activée sur l’instance Packet Core.
  

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

  • La configuration recommandée pour les déploiements avec plusieurs réseaux de données consiste à utiliser la jonction VLAN. Dans cette configuration, AP5GC peut prendre en charge jusqu’à dix réseaux de données attachés, chacun avec sa propre configuration pour le DNS (Domain Name System), les pools d’adresses IP d’UE, la configuration IP N6 et NAT. Vous pouvez provisionner des UE selon son abonnement dans un ou plusieurs réseaux de données, et appliquer une stratégie et une configuration de qualité de service (QoS) propres au réseau de données. La jonction VLAN est requise pour les déploiements haute disponibilité.
  • Dans cette topologie, il existe un seul réseau virtuel N6 sur l’ASE sans aucune information IP. Toutes les configurations VLAN et IP sont effectuées lors de la configuration de chaque réseau de données attaché.

• Réseau de couche 3 avec plusieurs réseaux de données sans séparation VLAN.

  • AP5GC peut prendre en charge jusqu’à dix réseaux de données attachés, chacun avec sa propre configuration pour le DNS (Domain Name System), les pools d’adresses IP d’UE, la configuration IP N6 et NAT. Vous pouvez provisionner des UE selon son abonnement dans un ou plusieurs réseaux de données, et appliquer une stratégie et une configuration de qualité de service (QoS) propres au réseau de données.
  • 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 du réseau de données ou des plages d’adresses IP des UE.

  

• Réseau de couche 3 avec séparation par VLAN et physique des réseaux principal et d’accès (accès VLAN)

  • Vous pouvez également séparer le trafic ASE dans des VLAN, que vous choisissiez ou non d’ajouter des passerelles de couche 3 à votre réseau. Il y a plusieurs avantages à la segmentation du trafic en réseaux VLAN distincts, notamment une gestion du réseau plus flexible et une sécurité renforcée.
  • Par exemple, vous pouvez configurer des VLAN distincts pour la gestion, l’accès et le trafic de données, ou un VLAN distinct pour chaque réseau de données attaché.
  • Les VLAN doivent être configurés sur l’équipement réseau de couche 2 ou de couche 3 local. Comme plusieurs VLAN sont transférés sur une seule liaison à partir du port ASE 3 (réseau d’accès) et/ou 4 (réseau principal), vous devez configurer chacune de ces liaisons comme une jonction VLAN.

  

• Réseau de couche 3 avec 7-10 réseaux de données sans jonction VLAN.

  • Sans jonction VLAN, si vous voulez déployer plus de six réseaux de données séparés par des VLAN, 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 le trafic principal et le trafic d’accès. Les étiquettes VLAN peuvent être attribuées selon les besoins aux réseaux de données N2, N3 et chacun des réseaux de données N6. La jonction VLAN est requise pour les déploiements haute disponibilité.
  • Pas plus de six réseaux de données 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 lourde doivent être configurés sur le port 4.

  

Sous-réseaux et adresses IP

Vous pouvez avoir des réseaux IP existants sur le site de l’entreprise que le réseau cellulaire privé doit 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éparation du nouveau réseau via des routeurs IP ou utilisation de l’espace d’adressage RFC 1918 privé pour les sous-réseaux.
• Attribution d’un pool d’adresses IP à utiliser spécifiquement par les UE quand ils s’attachent au réseau.
• Utilisation de la traduction d’adresses réseau et de port (NAPT), sur l’instance Packet Core elle-même ou sur un appareil réseau en amont, comme un routeur frontière.
• 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 utilisés pour le déploiement et convenir des adresses IP à utiliser pour chaque élément de la solution, ainsi que des adresses IP allouées aux UE lors de leur attachement. Vous devez déployer (ou configurer s’ils existent) des routeurs et des pare-feu sur le site de l’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é.

Haute disponibilité (HA)

Vous pouvez également déployer Azure Private 5G Core comme service hautement disponible (HA) sur une paire d’appareils Azure Stack Edge (ASE). Cela nécessite un routeur de passerelle (précisément, un appareil compatible avec la couche 3, c’est-à-dire un routeur ou un commutateur L3 (routeur/commutateur hybride)) entre le cluster ASE et :

• L’équipement RAN dans le réseau d’accès.
• Le ou les réseaux de données.

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 devez peut-être organiser l’accès à distance au réseau afin de résoudre les problèmes sans visite sur place. Vous devez également réfléchir à la façon dont le site de l’entreprise doit être connecté aux réseaux en amont comme Azure pour la gestion et/ou pour l’accès à d’autres ressources et applications en dehors du site de l’entreprise.

Vous devez convenir avec l’équipe de l’entreprise des sous-réseaux et adresses IP 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 de commutateur pour attribuer des ports connectés à des VLAN spécifiques (par exemple, pour placer le port Azure Stack Edge utilisé pour l’accès RAN dans le même VLAN 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’une liaison 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 de l’entreprise doit être conforme aux 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 être utilisées sur une certaine bande de fréquences dans un pays/une 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 quels sont les pays et les bandes de fréquences 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, l’UE et l’instance Packet Core communiquent tous sur des protocoles standard, nous vous recommandons d’effectuer des tests d’interopérabilité pour le protocole 4G Long-Term Evolution (LTE) ou 5G autonome (SA) spécifique entre Azure Private 5G Core, les UE et le RAN avant tout déploiement dans une entreprise cliente.

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 de l’organisme de réglementation 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 la bande 48, vous devez peut-être collaborer avec votre partenaire RAN pour déployer un proxy de domaine SAS (Spectrum Access System) sur le site de l’entreprise afin que le RAN puisse vérifier en permanence qu’il est autorisé à 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 causés par la fragmentation IPv4, une instance Packet Core 4G ou 5G indique aux UE la MTU à utiliser. Toutefois, les UE ne respectent pas toujours la MTU signalée par l’instance Packet Core.

Les paquets IP des UE sont tunnelisés à partir du RAN, ce qui ajoute une surcharge liée à l’encapsulation. La valeur MTU de l’UE doit donc être inférieure à la valeur MTU utilisée entre le RAN et l’instance Packet Core pour éviter les problèmes de transmission.

Les RAN sont généralement préconfigurés avec un MTU de 1500. La MTU d’UE par défaut de l’instance Packet Core est de 1440 octets pour supporter la surcharge d’encapsulation. Ces valeurs optimisent l’interopérabilité du RAN, mais certains UE risquent de ne pas observer la MTU par défaut et de générer des paquets plus grands qui nécessitent une fragmentation IPv4 pouvant être abandonnée par le réseau. Si vous êtes affecté par ce problème, nous vous recommandons vivement de configurer le RAN pour utiliser une MTU de 1560 ou plus, ce qui autorise une surcharge suffisante pour l’encapsulation et évite la fragmentation pour un UE utilisant une MTU standard de 1500.

Vous pouvez également changer la MTU d’UE signalée par l’instance Packet Core. Nous vous recommandons de définir la MTU sur une valeur dans la plage prise en charge par vos UE, et sur 60 octets en dessous de la MTU signalée par le RAN. Notez les points suivants :

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

Pour modifier l’UE MTU signalé par le cœur de paquet, consultez Modifier une instancede 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), il doit prendre en charge S1 (4G) et N2 (5G) pour la mobilité des 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 ainsi qu’au format logiciel uniquement (eSIM). Les données encodées sur la SIM doivent correspondre à la configuration du RAN et des données d’identité provisionné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 eSIM, vous devez déployer la configuration eSIM et l’infrastructure de provisionnement nécessaires afin que les UE puissent se configurer eux-mêmes avant de s’attacher 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. Comme les données SIM doivent être conservées en sécurité, les clés de chiffrement utilisées pour provisionner les SIM ne sont pas lisibles une fois définies. Vous devez donc réfléchir à leur stockage si vous devez reprovisionner les données dans Azure Private 5G Core.

Automatisation et intégration

La création de réseaux d’entreprise en utilisant 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 offrent également un chemin de récupération en cas de défaillance d’un site nécessitant la reconstruction du réseau.

Nous vous recommandons d’adopter une approche programmatique d’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 déterminer comment intégrer d’autres produits et services Azure au réseau d’entreprise privé. Ces produits sont notamment Microsoft Entra ID et le contrôle d’accès en fonction du rôle (RBAC), où vous devez déterminer comment les locataires, les abonnements et les autorisations de ressource doivent s’aligner sur le modèle d’entreprise existant entre vous et l’entreprise, ainsi que sur 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

• En savoir plus sur les composants clés d’un réseau mobile privé
• En savoir plus sur les conditions préalables pour le déploiement d’un réseau mobile privé