Ausführen der erforderlichen Aufgaben für die Bereitstellung eines privaten Mobilfunknetzes
In dieser Schrittanleitung werden alle Aufgaben ausgeführt, die erforderlich sind, um ein privates Mobilfunknetz mit Azure Private 5G Core bereitstellen zu können.
Tipp
Unter Entwurfsanforderungen für private mobile Netzwerke finden Sie die vollständigen Netzwerkentwurfsanforderungen für ein angepasstes Netzwerk.
Tools und Zugriff
Für die Bereitstellung eines privaten Mobilfunknetzes mit Azure Private 5G Core benötigen Sie Folgendes:
- Einen Windows-PC mit Internetzugriff
- Ein Windows-Administratorkonto auf diesem PC
- Azure-Befehlszeilenschnittstelle
- PowerShell
- kubectl
Erhalten von Zugriff auf Azure Private 5G Core für Ihr Azure-Abonnement
Bitten Sie den für Sie zuständigen Techniker für Testversionen, Ihr Azure-Abonnement für den Zugriff auf Azure Private 5G Core zu registrieren. Wenn Sie noch keinen Testingenieur haben und daran interessiert sind, Azure Private 5G Core zu testen, wenden Sie sich an Ihr Microsoft-Kontoteam, oder bekunden Sie Ihr Interesse über das Partnerregistrierungsformular.
Auswählen der Art der Kerntechnologie (5G, 4G oder eine Kombination aus 4G und 5G)
Wählen Sie aus, ob die Standorte in dem privaten Mobilfunknetz Abdeckung für 5G-Benutzergeräte, für 4G-Benutzergeräte oder für eine Kombination aus 4G- und 5G-Benutzergeräten bieten soll. Wenn Sie mehrere Standorte bereitstellen, können diese jeweils unterschiedliche Kerntechnologietypen unterstützen.
Auswählen einer Standardbereitstellung oder einer Hochverfügbarkeitsbereitstellung
Azure Private 5G Core wird als AKS-Cluster (Azure Kubernetes Service) bereitgestellt. Dieser Cluster kann auf einem einzelnen ASE-Gerät (Azure Stack Edge) ausgeführt werden oder auf einem ASE-Gerätepaar, um einen hochverfügbaren Dienst zu erhalten. Bei einer Hochverfügbarkeitsbereitstellung kann die Verfügbarkeit des Diensts im Falle eines ASE-Hardwarefehlers aufrechterhalten werden.
Für eine Hochverfügbarkeitsbereitstellung müssen Sie einen Gatewayrouter (streng genommen ein Layer 3-fähiges Gerät – also entweder einen Router oder einen L3-Switch (Router/Switch-Hybridgerät)) zwischen dem ASE-Cluster und Folgendem bereitstellen:
- der RAN-Ausrüstung im Zugriffsnetzwerk
- Datennetzwerk(e)
Der Gatewayrouter muss bidirektionale Weiterleitungserkennung (Bidirectional Forwarding Detection, BFD) und mit Mellanox kompatible SFP-Module (Small Form-factor Pluggable) unterstützen.
Ihr Netzwerk muss so gestaltet sein, dass es den Ausfall eines Gatewayrouters im Zugriffsnetzwerk oder in einem Datennetzwerk tolerieren kann. AP5GC unterstützt nur eine einzelne Gatewayrouter-IP-Adresse pro Netzwerk. Daher wird nur ein Netzwerkentwurf unterstützt, bei dem entweder ein einzelner Gatewayrouter pro Netzwerk vorhanden ist oder bei dem die Gatewayrouter in redundanten Paaren in einer Aktiv/Standby-Konfiguration mit einer Floating IP-Adresse für das Gateway bereitgestellt werden. Die Gatewayrouter in den redundanten Paaren müssen sich gegenseitig per VRRP (Virtual Router Redundancy-Protokoll) überwachen, um die Erkennung von Partnerausfällen zu ermöglichen.
Clusternetzwerktopologien
Die Hochverfügbarkeit von AP5GC basiert auf einer Plattform, die einen ASE-Gerätecluster mit zwei Knoten umfasst. Die ASE-Geräte sind mit einer gemeinsamen L2-Broadcastdomäne und einem gemeinsamen IP-Subnetz im Zugriffsnetzwerk (oder mit zwei gemeinsamen L2-Domänen – eine für N2 und eine für N3 – unter Verwendung von VLANs) und in jedem der Kernnetzwerke verbunden. Außerdem teilen sie sich eine L2-Broadcastdomäne und ein IP-Subnetz im Verwaltungsnetzwerk.
Weitere Informationen finden Sie unter Unterstützte Netzwerktopologien. Wir empfehlen die Verwendung von Option 1. Bei dieser Option befinden sich Port 1 und Port 2 in verschiedenen Subnetzen. Es werden separate virtuelle Switches erstellt. Port 3 und Port 4 stellen eine Verbindung mit einem externen virtuellen Switch her.
Weitere Informationen finden Sie unter Unterstützte Netzwerktopologien. Wir empfehlen die Verwendung von Option 2 (Verwendung von Switches und NIC-Teaming), um bestmöglich vor Ausfällen geschützt zu sein. Es ist auch möglich, nur einen einzelnen Switch zu verwenden (Option 3). Dies erhöht jedoch die Gefahr von Downtime im Falle eines Switchausfalls. Die Verwendung einer Topologie ohne Switch (Option 1) ist zwar möglich, wird jedoch aufgrund des noch höheren Downtimerisikos nicht empfohlen. Bei Option 3 erstellt jedes ASE-Gerät automatisch einen virtuellen Hyper-V-Switch (vSwitch) und fügt ihm die Ports hinzu.
Clusterquorum und -zeuge
Für einen ASE-Cluster mit zwei Knoten wird ein Clusterzeuge benötigt, der im Falle eines ausgefallenen ASE-Knotens als dritte Stimme fungieren kann, damit der Cluster online bleibt. Der Clusterzeuge wird in der Azure-Cloud ausgeführt.
Informationen zum Konfigurieren eines Azure-Cloudzeugen finden Sie unter https://learn.microsoft.com/windows-server/failover-clustering/deploy-cloud-witness. Das Feld „Replikation“ muss auf lokal redundanten Speicher (LRS) festgelegt werden. Firewalls zwischen dem ASE-Cluster und dem Azure-Speicherkonto müssen ausgehenden Datenverkehr für „https://.core.windows.net/“ am Port 443 (HTTPS) zulassen.
Zuordnen von Subnetzen und IP-Adressen
Azure Private 5G Core erfordert ein Verwaltungsnetzwerk, ein Zugriffsnetzwerk und bis zu zehn Datennetzwerke. Diese Netzwerke können alle Teil desselben, größeren Netzwerks sein, sie können aber auch getrennt sein. Welchen Ansatz Sie verwenden, hängt von Ihren Anforderungen an die Trennung des Datenverkehrs ab.
Ordnen Sie für jedes dieser Netzwerke ein Subnetz zu, und identifizieren Sie dann die aufgeführten IP-Adressen. Wenn Sie mehrere Standorte bereitstellen, müssen diese Informationen für jeden Standort gesammelt werden.
Abhängig von Ihren Netzwerkanforderungen (z. B., wenn nur eine begrenzte Gruppe von Subnetzen verfügbar ist) können Sie ein einzelnes Subnetz für alle Azure Stack Edge-Schnittstellen zuordnen (in der folgenden Liste mit einem Sternchen (*) gekennzeichnet).
Hinweis
Zusätzliche Anforderungen für eine Hochverfügbarkeitsbereitstellung sind inline aufgeführt.
Verwaltungsnetzwerk
- Netzwerkadresse in CIDR-Notation (Classless Inter-Domain Routing, klassenloses domänenübergreifendes Routing).
- Standardgateway.
- Eine einzelne IP-Adresse für den Verwaltungsport (Port 2) des Azure Stack Edge Pro 2-Geräts
- Hochverfügbarkeit: Vier IP-Adressen (jeweils zwei pro Azure Stack Edge-Gerät)
- Sechs aufeinanderfolgende IP-Adressen für die AKS-HCI-Clusterknoten (Azure Kubernetes Service in Azure Stack HCI).
- Hochverfügbarkeit: Sieben sequenzielle IP-Adressen
- Eine einzelne Dienst-IP-Adresse für den Zugriff auf lokale Überwachungstools für die Packet Core-Instanz
Zusätzliche IP-Adressen für den Azure Stack Edge-Cluster mit zwei Knoten in einer Hochverfügbarkeitsbereitstellung:
- Eine einzelne virtuelle IP-Adresse für ACS (Azure Consistency Services)
- Eine einzelne virtuelle IP-Adresse für NFS (Network File Services)
- Netzwerkadresse in CIDR-Notation (Classless Inter-Domain Routing, klassenloses domänenübergreifendes Routing).
- Standardgateway.
- Eine einzelne IP-Adresse für den Verwaltungsport
- Wählen Sie im Rahmen der Einrichtung Ihres Azure Stack Edge Pro-Geräts einen Port zwischen 2 und 4 als Verwaltungsport des Azure Stack Edge Pro-GPU-Geräts aus.*
- Hochverfügbarkeit: Zwei IP-Adressen (jeweils eine pro Azure Stack Edge-Gerät)
- Sechs aufeinanderfolgende IP-Adressen für die AKS-HCI-Clusterknoten (Azure Kubernetes Service in Azure Stack HCI).
- Hochverfügbarkeit: Sieben sequenzielle IP-Adressen
- Eine einzelne Dienst-IP-Adresse für den Zugriff auf lokale Überwachungstools für die Packet Core-Instanz
Zusätzliche IP-Adressen für den Azure Stack Edge-Cluster mit zwei Knoten in einer Hochverfügbarkeitsbereitstellung:
- Eine einzelne virtuelle IP-Adresse für ACS (Azure Consistency Services)
- Eine einzelne virtuelle IP-Adresse für NFS (Network File Services)
Zugriffsnetzwerk
Sie benötigen ein IP-Subnetz für den Datenverkehr der Steuerungsebene und ein IP-Subnetz für den Datenverkehr der Benutzerebene. Wenn sich Steuerungsebene und Benutzerebene im gleichen VLAN befinden (oder über kein VLAN-Tag verfügen), können Sie für beide ein einzelnes IP-Subnetz verwenden.
- Netzwerkadresse in CIDR-Notation.
- Standardgateway.
- Eine IP-Adresse für die Schnittstelle der Steuerungsebene.
- Bei 5G ist dies die N2-Schnittstelle.
- Bei 4G ist dies die S1-MME-Schnittstelle.
- Bei einer Kombination aus 4G und 5G ist dies die N2/S1-MME-Schnittstelle.
- Eine IP-Adresse für die Schnittstelle der Benutzerebene.
- Bei 5G ist dies die N3-Schnittstelle.
- Bei 4G ist dies die S1-U-Schnittstelle.
- Bei einer Kombination aus 4G und 5G ist dies die N3/S1-U-Schnittstelle.
- Eine einzelne IP-Adresse für Port 3 auf dem Azure Stack Edge Pro 2-Gerät
- Steuerungsebene bei Hochverfügbarkeit:
- IP-Adresse des Gatewayrouters
- Zwei IP-Adressen (jeweils eine pro ASE) für die Verwendung als vNIC-Adressen für die AMFs
- Benutzerebene bei Hochverfügbarkeit:
- IP-Adresse des Gatewayrouters
- Zwei IP-Adressen (jeweils eine pro ASE) für die Verwendung als vNIC-Adressen für die UPF-Schnittstellen für das lokale Zugriffsnetzwerk
- Netzwerkadresse in CIDR-Notation.
- Standardgateway.
- Eine IP-Adresse für die Schnittstelle der Steuerungsebene.
- Bei 5G ist dies die N2-Schnittstelle.
- Bei 4G ist dies die S1-MME-Schnittstelle.
- Bei einer Kombination aus 4G und 5G ist dies die N2/S1-MME-Schnittstelle.
- Eine IP-Adresse für die Schnittstelle der Benutzerebene.
- Bei 5G ist dies die N3-Schnittstelle.
- Bei 4G ist dies die S1-U-Schnittstelle.
- Bei einer Kombination aus 4G und 5G ist dies die N3/S1-U-Schnittstelle.
- Eine einzelne IP-Adresse für Port 5 auf dem Azure Stack Edge Pro-GPU-Gerät
- Steuerungsebene bei Hochverfügbarkeit:
- IP-Adresse des Gatewayrouters
- Zwei IP-Adressen (jeweils eine pro ASE) für die Verwendung als vNIC-Adressen für die AMFs
- Benutzerebene bei Hochverfügbarkeit:
- IP-Adresse des Gatewayrouters
- Zwei IP-Adressen (jeweils eine pro ASE) für die Verwendung als vNIC-Adressen für die UPF-Schnittstellen für das lokale Zugriffsnetzwerk
Datennetzwerke
Weisen Sie die folgenden IP-Adressen für jedes Datennetzwerk am Standort zu:
- Netzwerkadresse in CIDR-Notation.
- Standardgateway.
- Eine IP-Adresse für die Schnittstelle der Benutzerebene.
- Bei 5G ist dies die N6-Schnittstelle.
- Bei 4G ist dies die SGi-Schnittstelle.
- Bei einer Kombination aus 4G und 5G ist dies die N6/SGi-Schnittstelle.
Die folgenden IP-Adressen müssen von allen Datennetzwerken am Standort gemeinsam verwendet werden:
- Eine einzelne IP-Adresse für alle Datennetzwerke am Port 3 auf dem Azure Stack Edge Pro 2-Gerät
- Eine einzelne IP-Adresse für alle Datennetzwerke am Port 4 auf dem Azure Stack Edge Pro 2-Gerät
- Hochverfügbarkeit: IP-Adresse des Gatewayrouters
- Hochverfügbarkeit: Zwei IP-Adressen (jeweils eine pro ASE) für die Verwendung als vNIC-Adressen für die UPF-Schnittstellen für das Datennetzwerk
- Eine einzelne IP-Adresse für alle Datennetzwerke am Port 5 auf dem Azure Stack Edge Pro-GPU-Gerät
- Eine einzelne IP-Adresse für alle Datennetzwerke am Port 6 auf dem Azure Stack Edge Pro-GPU-Gerät
- Hochverfügbarkeit: IP-Adresse des Gatewayrouters
- Hochverfügbarkeit: Zwei IP-Adressen (jeweils eine pro ASE) für die Verwendung als vNIC-Adressen für die UPF-Schnittstellen für das Datennetzwerk
Zusätzliche virtuelle IP-Adressen (nur bei Hochverfügbarkeit)
Die folgenden virtuellen IP-Adressen sind für eine Hochverfügbarkeitsbereitstellung erforderlich. Diese IP-Adressen DÜRFEN SICH NICHT in einem der Subnetze der Steuerungs- oder Benutzerebene befinden. Sie werden als Ziele statischer Routen in den Zugriffsnetzwerk-Gatewayroutern verwendet. Es kann sich bei ihnen also um beliebige gültige IP-Adressen handeln, die nicht in einem der im Zugriffsnetzwerk konfigurierten Subnetze enthalten sind.
- Eine einzelne virtuelle Adresse für die Verwendung als virtuelle N2-Adresse. Die RAN-Ausrüstung ist für die Verwendung dieser Adresse konfiguriert.
- Eine einzelne virtuelle Adresse für die Verwendung als virtueller Tunnelendpunkt für den N3-Referenzpunkt
VLANs
Optional können Sie Ihr Azure Stack Edge Pro-Gerät mit VLAN-Tags (Virtual Local Area Network) konfigurieren. Sie können diese Konfiguration verwenden, um die Trennung des Datenverkehrs der Ebene 2 für die N2-, N3- und N6-Schnittstellen oder deren 4G-Entsprechungen zu aktivieren. Beispiel: Das ASE-Gerät verfügt über einen einzelnen Port für N2- und N3-Datenverkehr und über einen einzelnen Port für den gesamten Datennetzwerk-Datenverkehr. Sie können VLAN-Tags verwenden, um N2- und N3-Datenverkehr oder Datenverkehr für jedes verbundene Datennetzwerk zu trennen.
Weisen Sie VLAN-IDs nach Bedarf für die einzelnen Netzwerke zu.
Wenn Sie VLANs verwenden, um Datenverkehr für die einzelnen Datennetzwerke zu trennen, ist ein lokales Subnetz für die mit dem Datennetzwerk verbundenen Ports erforderlich, die das Standard-VLAN (VLAN 0) abdecken. Für Hochverfügbarkeit muss die IP-Adresse des Gatewayrouters innerhalb dieses Subnetzes zugewiesen werden.
Zuordnen von IP-Adresspools für Benutzergeräte (User Equipment, UE)
Azure Private 5G Core unterstützt die folgenden Methoden zur Zuordnung von IP-Adressen für Benutzergeräte.
Dynamisch: Die dynamische Zuordnung von IP-Adressen weist einem Endgerät jedes Mal, wenn es sich mit dem privaten Mobilfunknetz verbindet, automatisch eine neue IP-Adresse zu.
Statisch. Die statische Zuordnung von IP-Adressen stellt sicher, dass ein Benutzergerät jedes Mal, wenn es sich mit dem privaten Mobilfunknetz verbindet, die gleiche IP-Adresse erhält. Statische IP-Adressen sind nützlich, wenn Sie möchten, dass IoT-Anwendungen (Internet of Things; Internet der Dinge) immer wieder eine Verbindung mit dem gleichen Gerät herstellen können. Sie können z. B. eine Anwendung zur Videoanalyse mit den IP-Adressen der Kameras konfigurieren, die Videodatenströme bereitstellen. Wenn diese Kameras statische IP-Adressen haben, müssen Sie die Videoanalyseanwendung nicht bei jedem Neustart der Kameras mit neuen IP-Adressen neu konfigurieren. Sie weisen einem Benutzergerät im Rahmen der Bereitstellung seiner SIM statische IP-Adressen zu.
Sie können für jedes Datennetzwerk an Ihrem Standort wählen, ob Sie eine oder beide Methoden unterstützen möchten.
Für jedes Datennetzwerk, das Sie bereitstellen, gilt:
Entscheiden Sie, welche IP-Adresszuordnungsmethoden Sie unterstützen möchten.
Identifizieren Sie für jede Methode, die Sie unterstützen möchten, einen IP-Adresspool, aus dem IP-Adressen zu Benutzergeräten zugeordnet werden können. Sie müssen jeden IP-Adresspool in CIDR-Notation angeben.
Wenn Sie sich entscheiden, für ein bestimmtes Datennetzwerk beide Methoden zu unterstützen, achten Sie darauf, dass die IP-Adresspools dieselbe Größe haben und sich nicht überschneiden.
Entscheiden Sie, ob Sie NAPT (Network Address and Port Translation) für das Datennetzwerk aktivieren möchten. Mit NAPT können Sie einen großen Pool privater IP-Adressen für Benutzergeräte in einen kleinen Pool öffentlicher IP-Adressen übersetzen. Die Übersetzung erfolgt an dem Punkt, an dem Datenverkehr in das Datennetzwerk gelangt, wodurch der Nutzen einer begrenzten Menge öffentlicher IP-Adressen maximiert wird.
Konfigurieren von DNS-Servern (Domain Name System)
Wichtig
Wenn Sie keine DNS-Server für ein Datennetzwerk konfigurieren, können Benutzergeräte, die dieses Netzwerk verwenden, keine Domänennamen auflösen.
DNS ermöglicht die Übersetzung zwischen von Menschen lesbaren Domänennamen und den ihnen zugeordneten computerlesbaren IP-Adressen. Je nach Anforderungen stehen Ihnen die folgenden Optionen zum Konfigurieren eines DNS-Servers für Ihr Datennetzwerk zur Verfügung:
- Wenn die mit diesem Datennetzwerk verbundenen Benutzergeräte Domänennamen auflösen müssen, müssen Sie mindestens einen DNS-Server konfigurieren. Sie müssen einen privaten DNS-Server verwenden, wenn die DNS-Auflösung interner Hostnamen erforderlich ist. Wenn Sie nur Internetzugriff auf öffentliche DNS-Namen bereitstellen, können Sie einen öffentlichen oder privaten DNS-Server verwenden.
- Wenn die Benutzergeräte keine DNS-Auflösung durchführen müssen oder alle Benutzergeräte im Netzwerk eigene lokale konfigurierte DNS-Server verwenden (anstatt der ihnen vom Paketkern signalisierten DNS-Server), ist diese Konfiguration nicht erforderlich.
Konfigurieren
Vorbereiten Ihrer Netzwerke
Für jeden Standort, den Sie bereitstellen, gilt:
- Stellen Sie sicher, dass Sie mindestens über einen Netzwerkswitch mit mindestens drei Ports verfügen. Sie verbinden jedes Azure Stack Edge Pro-Gerät mit dem/den Switch(es) am selben Standort, wie unter Bestellen und Einrichten Ihrer Azure Stack Edge Pro-Geräte beschrieben.
- Konfigurieren Sie für jedes Netzwerk, für das Sie NAPT nicht (wie in Zuordnen von IP-Adresspools für Benutzergeräte (User Equipment, UE) beschrieben) aktivieren möchten, das Datennetzwerk so, dass der für die IP-Adresspools für Benutzergeräte bestimmte Datenverkehr über die IP-Adresse geleitet wird, die Sie der Benutzerschnittstelle der Paketkerninstanz im Datennetzwerk zugewiesen haben.
Konfigurieren von Ports für lokalen Zugriff
Die folgenden Tabellen enthalten die Ports, die für lokalen Azure Private 5G Core-Zugriff geöffnet werden müssen. Dazu gehören der lokale Verwaltungszugriff und die Signalisierung der Steuerungsebene.
Diese müssen zusätzlich zu den für Azure Stack Edge (ASE) erforderlichen Ports eingerichtet werden.
Azure Private 5G Core
| Port | ASE-Schnittstelle | BESCHREIBUNG |
|---|---|---|
| TCP 443 Eingehend | Verwaltung (LAN) | Zugriff auf lokale Überwachungstools (Paketkern-Dashboards und verteilte Ablaufverfolgung). |
| 5671 ein-/ausgehend | Verwaltung (LAN) | Kommunikation mit Azure Event Hubs, AMQP-Protokoll |
| 5672 ein-/ausgehend | Verwaltung (LAN) | Kommunikation mit Azure Event Hubs, AMQP-Protokoll |
| UDP 1812 Ein-/Ausgehend | Verwaltung (LAN) | Authentifizierung mit einem RADIUS AAA-Server. Nur erforderlich, wenn RADIUS verwendet wird. |
| SCTP 38412 Eingehend | Port 3 (Zugriffsnetzwerk) | Zugriffssignalisierung der Steuerungsebene (N2-Schnittstelle). Nur für 5G-Bereitstellungen erforderlich. |
| SCTP 36412 Eingehend | Port 3 (Zugriffsnetzwerk) | Zugriffssignalisierung der Steuerungsebene (S1-MME-Schnittstelle). Nur für 4G-Bereitstellungen erforderlich. |
| UDP 2152 Ein-/Ausgehend | Port 3 (Zugriffsnetzwerk) | Benutzerebenendaten des Zugriffsnetzwerks (N3-Schnittstelle für 5G, S1-U-Schnittstelle für 4G oder N3/S1-U-Schnittstelle für Kombination aus 4G und 5G) |
| Der gesamte IP-Verkehr | Ports 3 und 4 (Datennetzwerke) | Benutzerebenendaten der Datennetzwerke (N6-Schnittstelle für 5G, SGi-Schnittstelle für 4G oder N6/SGi-Schnittstelle für Kombination aus 4G und 5G) Nur für Port 3 erforderlich, wenn Datennetzwerke für diesen Port konfiguriert sind |
Die folgenden Tabellen enthalten die Ports, die für lokalen Azure Private 5G Core-Zugriff geöffnet werden müssen. Dazu gehören der lokale Verwaltungszugriff und die Signalisierung der Steuerungsebene.
Diese müssen zusätzlich zu den für Azure Stack Edge (ASE) erforderlichen Ports eingerichtet werden.
Azure Private 5G Core
| Port | ASE-Schnittstelle | BESCHREIBUNG |
|---|---|---|
| TCP 443 Eingehend | Verwaltung (LAN) | Zugriff auf lokale Überwachungstools (Paketkern-Dashboards und verteilte Ablaufverfolgung). |
| 5671 ein-/ausgehend | Verwaltung (LAN) | Kommunikation mit Azure Event Hubs, AMQP-Protokoll |
| 5672 ein-/ausgehend | Verwaltung (LAN) | Kommunikation mit Azure Event Hubs, AMQP-Protokoll |
| UDP 1812 Ein-/Ausgehend | Verwaltung (LAN) | Authentifizierung mit einem RADIUS AAA-Server. Nur erforderlich, wenn RADIUS verwendet wird. |
| SCTP 38412 Eingehend | Port 5 (Access-Netzwerk) | Zugriffssignalisierung der Steuerungsebene (N2-Schnittstelle). Nur für 5G-Bereitstellungen erforderlich. |
| SCTP 36412 Eingehend | Port 5 (Access-Netzwerk) | Zugriffssignalisierung der Steuerungsebene (S1-MME-Schnittstelle). Nur für 4G-Bereitstellungen erforderlich. |
| UDP 2152 Ein-/Ausgehend | Port 5 (Access-Netzwerk) | Benutzerebenendaten des Zugriffsnetzwerks (N3-Schnittstelle für 5G, S1-U-Schnittstelle für 4G oder N3/S1-U-Schnittstelle für Kombination aus 4G und 5G) |
| Der gesamte IP-Verkehr | Ports 5 und 6 (Datennetzwerke) | Benutzerebenendaten der Datennetzwerke (N6-Schnittstelle für 5G, SGi-Schnittstelle für 4G oder N6/SGi-Schnittstelle für Kombination aus 4G und 5G) Nur für Port 5 erforderlich, wenn Datennetzwerke für diesen Port konfiguriert sind |
Portanforderungen für Azure Stack Edge
| Portnr. | Ein/Aus | Portbereich | Erforderlich | Hinweise |
|---|---|---|---|---|
| UDP 123 (NTP) | aus | WAN | In einigen Fällen | Dieser Port ist nur erforderlich, wenn Sie einen lokalen NTP-Server oder einen internetbasierten Server für ASE verwenden. |
| UDP 53 (DNS) | aus | WAN | In einigen Fällen | Weitere Informationen finden Sie unter Konfigurieren von DNS-Servern (Domain Name System). |
| TCP 5985 (WinRM) | Aus/Ein | LAN | Ja | Erforderlich für WinRM, um ASE während der AP5GC-Bereitstellung über PowerShell zu verbinden. Weitere Informationen finden Sie unter Kommissionieren eines AKS-Clusters. |
| TCP 5986 (WinRM) | Aus/Ein | LAN | Ja | Erforderlich für WinRM, um ASE während der AP5GC-Bereitstellung über PowerShell zu verbinden. Weitere Informationen finden Sie unter Kommissionieren eines AKS-Clusters. |
| UDP 67 (DHCP) | aus | LAN | Ja | |
| TCP 445 (SMB) | In | LAN | No | Für ASE für AP5GC ist kein lokaler Dateiserver erforderlich. |
| TCP 2049 (NFS) | In | LAN | No | Für ASE für AP5GC ist kein lokaler Dateiserver erforderlich. |
Portanforderungen für IoT Edge
| Portnr. | Ein/Aus | Portbereich | Erforderlich | Hinweise |
|---|---|---|---|---|
| TCP 443 (HTTPS) | aus | WAN | No | Diese Konfiguration ist nur bei Verwendung manueller Skripts oder bei Verwendung des Azure IoT Device Provisioning-Diensts (Device Provisioning Service, DPS) erforderlich. |
Portanforderungen für Kubernetes für Azure Stack Edge
| Portnr. | Ein/Aus | Portbereich | Erforderlich | Hinweise |
|---|---|---|---|---|
| TCP 31000 (HTTPS) | In | LAN | Ja | Erforderlich, damit Ihr Gerät über das Kubernetes-Dashboard überwacht werden kann |
| TCP 6443 (HTTPS) | In | LAN | Ja | Erforderlich für kubectl-Zugriff |
Erforderliche Firewallports für ausgehenden Datenverkehr
Überprüfen Sie die Firewallempfehlungen für die folgenden Dienste, und wenden Sie sie an:
Die folgende Tabelle enthält die URL-Muster für ausgehenden Datenverkehr von Azure Private 5G Core:
| URL-Muster | Beschreibung |
|---|---|
https://*.azurecr.io |
Erforderlich zum Pullen von Containerimages für Azure Private 5G Core-Workloads |
https://*.microsoftmetrics.com https://*.hot.ingestion.msftcloudes.com |
Erforderlich für die Überwachung und Telemetrie für den Azure Private 5G Core-Dienst |
Registrieren von Ressourcenanbietern
Um Azure Private 5G Core verwenden zu können, müssen Sie einige zusätzliche Ressourcenanbieter bei Ihrem Azure-Abonnement registrieren.
Tipp
Sollte die Azure CLI bei Ihnen nicht installiert sein, finden Sie unter Installieren der Azure CLI eine Installationsanleitung. Alternativ können Sie Azure Cloud Shell im Portal verwenden.
Melden Sie sich bei der Azure CLI mit einem Benutzerkonto an, das dem Azure-Mandanten zugeordnet ist, unter dem Sie Azure Private 5G Core bereitstellen:
az loginTipp
Eine ausführliche Anleitung finden Sie im Artikel Authentifizieren bei Azure mit Azure CLI unter „Interaktives Anmelden“.
Falls Ihr Konto über mehrere Abonnements verfügt, vergewissern Sie sich, dass Sie sich im richtigen Abonnement befinden:
az account set --subscription <subscription_id>Überprüfen Sie die Version der Azure CLI:
az versionIst die CLI-Version niedriger als 2.37.0, müssen Sie Ihre Azure CLI auf eine neuere Version upgraden. Weitere Informationen finden Sie unter Gewusst wie: Aktualisieren der Azure CLI.
Registrieren Sie die folgenden Ressourcenanbieter:
az provider register --namespace Microsoft.MobileNetwork az provider register --namespace Microsoft.HybridNetwork az provider register --namespace Microsoft.ExtendedLocation az provider register --namespace Microsoft.Kubernetes az provider register --namespace Microsoft.KubernetesConfiguration
Abrufen der Objekt-ID (OID)
Sie müssen die Objekt-ID (OID) des Ressourcenanbieters für den benutzerdefinierten Standort in Ihrem Azure-Mandanten abrufen. Diese OID muss beim Erstellen des Kubernetes-Diensts angegeben werden. Sie können die OID über die Azure CLI oder über Azure Cloud Shell im Portal abrufen. Sie müssen ein Besitzer Ihres Azure-Abonnements sein.
Melden Sie sich bei der Azure CLI oder bei Azure Cloud Shell an.
Rufen Sie die OID ab:
az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv
Dieser Befehl fragt den benutzerdefinierten Standort ab und gibt eine OID-Zeichenfolge aus. Speichern Sie diese Zeichenfolge für die spätere Kommissionierung des Azure Stack Edge-Geräts.
Bestellen und Einrichten Ihrer Azure Stack Edge Pro-Geräte
Führen Sie die folgenden Schritte für jeden Standort aus, den Sie Ihrem privaten Mobilfunknetz hinzufügen möchten. Ausführliche Anweisungen für die einzelnen Schritte finden Sie in der Spalte Ausführliche Anleitungen (sofern vorhanden).
| Schrittnummer | BESCHREIBUNG | Ausführliche Anleitungen |
|---|---|---|
| 1. | Gehen Sie die Prüfliste für die Bereitstellung von Azure Stack Edge Pro 2 durch. | Bereitstellungsprüfliste für Ihr Azure Stack Edge Pro 2-Gerät |
| 2. | Bestellen Sie Ihr Azure Stack Edge Pro 2-Gerät, und bereiten Sie es vor. | Tutorial: Vorbereiten der Bereitstellung von Azure Stack Edge Pro 2 |
| 3. | Installieren Sie Ihr Azure Stack Edge Pro 2-Gerät in einem Rack, und verkabeln Sie es. Achten Sie hierbei unbedingt darauf, dass die Ports des Geräts wie folgt verbunden sind: - Port 2: Verwaltung - Port 3: Zugriffsnetzwerk (und optional Datennetzwerke) - Port 4: Datennetzwerke |
Tutorial: Installieren von Azure Stack Edge Pro 2 |
| 4. | Stellen Sie über die lokale Webbenutzeroberfläche eine Verbindung mit Ihrem Azure Stack Edge Pro 2-Gerät her. | Tutorial: Herstellen einer Verbindung mit Azure Stack Edge Pro 2 |
| 5. | Konfigurieren Sie das Netzwerk für Ihr Azure Stack Edge Pro 2-Gerät. Hinweis: Wenn ein ASE-Gerät in einem Azure Private 5G Core-Dienst verwendet wird, wird der Port 2 nicht für Daten, sondern für die Verwaltung verwendet. In dem verlinkten Tutorial wird von einem allgemeinen ASE-Gerät ausgegangen, das den Port 2 für Daten verwendet. Wenn sich RAN und Packet Core im gleichen Subnetz befinden, muss kein Gateway für Port 3 oder Port 4 konfiguriert werden. Außerdem können Sie optional Ihr Azure Stack Edge Pro-Gerät so konfigurieren, dass es hinter einem Webproxy ausgeführt wird. Vergewissern Sie sich, dass die ausgehenden Verbindungen zwischen dem Azure Stack Edge Pro-Gerät und den Azure Arc-Endpunkten geöffnet sind. Konfigurieren Sie keine virtuellen Switches, virtuellen Netzwerke oder IP-Adressen für Compute. |
Tutorial: Konfigurieren des Netzwerks für Azure Stack Edge Pro 2 (Optional) Konfigurieren des Webproxys für Azure Stack Edge Pro Netzwerkanforderungen für Azure Arc Netzwerkanforderungen für den Azure Arc-Agent |
| 6. | Konfigurieren Sie einen Namen, einen DNS-Namen und (optional) Zeiteinstellungen. Konfigurieren Sie kein Update. |
Tutorial: Konfigurieren der Geräteeinstellungen für Azure Stack Edge Pro 2 |
| 7. | Konfigurieren Sie Zertifikate und die Verschlüsselung ruhender Daten für Ihr Azure Stack Edge Pro 2-Gerät. Nach dem Ändern der Zertifikate müssen Sie die lokale Benutzeroberfläche ggf. in einem neuen Browserfenster öffnen, um zu verhindern, dass die alten zwischengespeicherten Zertifikate Probleme verursachen. | Tutorial: Konfigurieren von Zertifikaten für Ihr Azure Stack Edge Pro 2-Gerät |
| 8. | Aktivieren Sie Ihr Azure Stack Edge Pro 2-Gerät. Führen Sie nicht die Schritte im Abschnitt Bereitstellen von Workloads aus. |
Tutorial: Aktivieren von Azure Stack Edge Pro 2 |
| 9. | Aktivieren Sie die VM-Verwaltung über das Azure-Portal. Wenn diese Aktivierung unmittelbar nach der Aktivierung des Azure Stack Edge Pro 2-Geräts durchgeführt wird, tritt gelegentlich ein Fehler auf. Warten Sie eine Minute, und wiederholen Sie dann den Vorgang. |
Navigieren Sie im Azure-Portal zu der ASE-Ressource, wechseln Sie zu Edgedienste, wählen Sie Virtuelle Computer aus, und wählen Sie anschließend Aktivieren aus. |
| 10. | Führen Sie über die lokale Weboberfläche die Diagnosetests für das Azure Stack Edge Pro 2-Gerät aus, und vergewissern Sie sich, dass alle Tests erfolgreich sind. Unter Umständen wird eine Warnung mit einem Hinweis auf einen getrennten, nicht verwendeten Port angezeigt. Beheben Sie das Problem, wenn sich die Warnung auf einen der folgenden Ports bezieht: - Port 2: Verwaltung - Port 3: Zugriffsnetzwerk (und optional Datennetzwerke) - Port 4: Datennetzwerke Bei allen anderen Ports können Sie die Warnung ignorieren. Wenn es Fehler gibt, beheben Sie sie, bevor Sie mit den verbleibenden Schritten fortfahren. Dies schließt alle Fehler ein, die sich auf ungültige Gateways an nicht verwendeten Ports beziehen. Löschen Sie in diesem Fall entweder die Gateway-IP-Adresse, oder legen Sie sie auf ein gültiges Gateway für das Subnetz fest. |
Ausführen von Diagnosen und Sammeln von Protokollen zum Behandeln von Problemen bei Azure Stack Edge-Geräten |
Wichtig
Stellen Sie sicher, dass Ihr Azure Stack Edge Pro 2-Gerät mit der Azure Private 5G Core-Version kompatibel ist, die Sie installieren möchten. Weitere Informationen finden Sie unter Packet Core- und Azure Stack Edge (ASE)-Kompatibilität. Informationen zum Upgraden Ihres Azure Stack Edge Pro 2-Geräts finden Sie bei Bedarf unter Aktualisieren Ihrer Azure Stack Edge Pro-GPU.
| Schrittnummer | BESCHREIBUNG | Ausführliche Anleitungen |
|---|---|---|
| 1. | Gehen Sie die Prüfliste für die Bereitstellung von Azure Stack Edge Pro GPU durch. | Bereitstellungsprüfliste für Ihr Azure Stack Edge Pro-GPU-Gerät |
| 2. | Bestellen Sie Ihr Azure Stack Edge Pro GPU-Gerät, und bereiten Sie es vor. | Tutorial: Vorbereiten der Bereitstellung von Azure Stack Edge Pro-Geräten mit GPU |
| 3. | Installieren Sie Ihr Azure Stack Edge Pro GPU-Gerät in einem Rack, und verkabeln Sie es. Achten Sie hierbei unbedingt darauf, dass die Ports des Geräts wie folgt verbunden sind: - Port 5: Zugriffsnetzwerk (und optional Datennetzwerke) - Port 6: Datennetzwerke Außerdem muss ein Port mit Ihrem Verwaltungsnetzwerk verbunden sein. Sie können einen beliebigen Port zwischen 2 und 4 auswählen. |
Tutorial: Installieren von Azure Stack Edge Pro mit GPU |
| 4. | Stellen Sie über die lokale Webbenutzeroberfläche eine Verbindung mit Ihrem Azure Stack Edge Pro GPU-Gerät her. | Tutorial: Herstellen einer Verbindung mit Azure Stack Edge Pro mit GPU |
| 5. | Konfigurieren Sie das Netzwerk für Ihr Azure Stack Edge Pro GPU-Gerät. Befolgen Sie die Anweisungen für ein Gerät mit einem einzelnen Knoten (Standardbereitstellung) bzw. die Anweisungen für einen Cluster mit zwei Knoten (Hochverfügbarkeitsbereitstellung). Hinweis: Wenn ein ASE-Gerät in einem Azure Private 5G Core-Dienst verwendet wird, wird der Port 2 nicht für Daten, sondern für die Verwaltung verwendet. In dem verlinkten Tutorial wird von einem allgemeinen ASE-Gerät ausgegangen, das den Port 2 für Daten verwendet. Wenn sich RAN und Packet Core im gleichen Subnetz befinden, muss kein Gateway für Port 5 oder Port 6 konfiguriert werden. Außerdem können Sie optional Ihr Azure Stack Edge Pro GPU-Gerät so konfigurieren, dass es hinter einem Webproxy ausgeführt wird. Vergewissern Sie sich, dass die ausgehenden Verbindungen zwischen dem Azure Stack Edge Pro GPU-Gerät und den Azure Arc-Endpunkten geöffnet sind. Konfigurieren Sie keine virtuellen Switches, virtuellen Netzwerke oder IP-Adressen für Compute. |
Tutorial: Konfigurieren des Netzwerks für Azure Stack Edge Pro mit GPU (Optional) Konfigurieren des Webproxys für Azure Stack Edge Pro Netzwerkanforderungen für Azure Arc Netzwerkanforderungen für den Azure Arc-Agent |
| 6. | Konfigurieren Sie einen Namen, einen DNS-Namen und (optional) Zeiteinstellungen. Konfigurieren Sie kein Update. |
Tutorial: Konfigurieren der Geräteeinstellungen für Azure Stack Edge Pro-Geräte mit GPU |
| 7. | Konfigurieren Sie Zertifikate für Ihr Azure Stack Edge Pro GPU-Gerät. Nach dem Ändern der Zertifikate müssen Sie die lokale Benutzeroberfläche ggf. in einem neuen Browserfenster öffnen, um zu verhindern, dass die alten zwischengespeicherten Zertifikate Probleme verursachen. | Tutorial: Konfigurieren von Zertifikaten für Ihr Azure Stack Edge Pro-Gerät mit GPU |
| 8. | Aktivieren Sie Ihr Azure Stack Edge Pro GPU-Gerät. Führen Sie nicht die Schritte im Abschnitt Bereitstellen von Workloads aus. |
Tutorial: Aktivieren von Azure Stack Edge Pro mit GPU |
| 9. | Aktivieren Sie die VM-Verwaltung über das Azure-Portal. Wenn diese Aktivierung unmittelbar nach der Aktivierung des Azure Stack Edge Pro-Geräts durchgeführt wird, tritt gelegentlich ein Fehler auf. Warten Sie eine Minute, und wiederholen Sie dann den Vorgang. |
Navigieren Sie im Azure-Portal zu der ASE-Ressource, wechseln Sie zu Edgedienste, wählen Sie Virtuelle Computer aus, und wählen Sie anschließend Aktivieren aus. |
| 10. | Führen Sie über die lokale Weboberfläche die Diagnosetests für das Azure Stack Edge Pro GPU-Gerät aus, und vergewissern Sie sich, dass alle Tests erfolgreich sind. Unter Umständen wird eine Warnung mit einem Hinweis auf einen getrennten, nicht verwendeten Port angezeigt. Beheben Sie das Problem, wenn sich die Warnung auf einen der folgenden Ports bezieht: - Port 5. - Port 6. - Der Port, den Sie in Schritt 3 für die Verbindung mit dem Verwaltungsnetzwerk ausgewählt haben. Bei allen anderen Ports können Sie die Warnung ignorieren. Wenn es Fehler gibt, beheben Sie sie, bevor Sie mit den verbleibenden Schritten fortfahren. Dies schließt alle Fehler ein, die sich auf ungültige Gateways an nicht verwendeten Ports beziehen. Löschen Sie in diesem Fall entweder die Gateway-IP-Adresse, oder legen Sie sie auf ein gültiges Gateway für das Subnetz fest. |
Ausführen von Diagnosen und Sammeln von Protokollen zum Behandeln von Problemen bei Azure Stack Edge-Geräten |
Wichtig
Stellen Sie sicher, dass Ihr Azure Stack Edge Pro GPU-Gerät mit der Azure Private 5G Core-Version kompatibel ist, die Sie installieren möchten. Weitere Informationen finden Sie unter Packet Core- und Azure Stack Edge (ASE)-Kompatibilität. Informationen zum Upgraden Ihres Azure Stack Edge Pro GPU-Geräts finden Sie bei Bedarf unter Aktualisieren Ihrer Azure Stack Edge Pro-GPU.
Nächste Schritte
Nun können Sie den AKS-Cluster (Azure Kubernetes Service) auf Ihrem Azure Stack Edge Pro 2- oder Azure Stack Edge Pro GPU-Gerät kommissionieren, um es für die Bereitstellung von Azure Private 5G Core vorzubereiten.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für