Requisiti di progettazione della rete mobile privata

Questo articolo illustra come progettare e preparare l'implementazione di una rete 4G privata o 5G basata su Azure Private 5G Core (AP5GC). Mira a fornire una comprensione del modo in cui queste reti vengono costruite e le decisioni da prendere durante la pianificazione della rete.

MEC privato di Azure e 5G Core privato di Azure

MEC (Private Multi-Access Edge Compute) di Azure è una soluzione che combina i servizi di calcolo, rete e applicazione Microsoft in una distribuzione in locale (edge). Queste distribuzioni perimetrali vengono gestite centralmente dal cloud. Azure Private 5G Core è un servizio di Azure all'interno dell'ambiente di calcolo MEC (Private Multi-Access Edge Compute) di Azure che fornisce funzioni di rete di base 4G e 5G all'perimetro aziendale. Nel sito perimetrale aziendale, i dispositivi si connettono attraverso una rete di accesso radio cellulare (RAN) e sono connessi tramite il servizio 5G Core privato di Azure a reti upstream, applicazioni e risorse. Facoltativamente, i dispositivi possono usare la funzionalità di calcolo locale fornita da MEC privato di Azure per elaborare i flussi di dati a una latenza molto bassa, tutto sotto il controllo dell'azienda.

Requisiti per una rete mobile privata

Le funzionalità seguenti devono essere presenti per consentire alle apparecchiature utente (UES) di collegarsi a una rete cellulare privata:

• L'UE deve essere compatibile con il protocollo e la banda dello spettro wireless usata dalla rete di accesso radio (RAN).
• L'UE deve contenere un modulo di identità del sottoscrittore (SIM). La SIM è un elemento crittografico che archivia l'identità del dispositivo.
• Deve essere presente un rancore, l'invio e la ricezione del segnale cellulare, a tutte le parti del sito aziendale che contengono UES che necessitano di servizio.
• Deve essere presente un'istanza di base di pacchetti connessa all'istanza RAN e a una rete upstream. Il core del pacchetto è responsabile dell'autenticazione dei SIM dell'UE durante la connessione attraverso l'infrastruttura RAN e richiedere il servizio dalla rete. Applica i criteri ai flussi di dati risultanti da e verso gli UES; ad esempio per impostare una qualità del servizio.
• L'infrastruttura di rete RAN, packet core e upstream deve essere connessa tramite Ethernet in modo che possano passare il traffico IP l'uno all'altro.
• Il sito che ospita il core del pacchetto deve avere una connessione continua e ad alta velocità a Internet (minimo 100 Mbps) per consentire la gestione dei servizi, i dati di telemetria, la diagnostica e gli aggiornamenti.

Progettazione di una rete mobile privata

Le sezioni seguenti descrivono gli elementi della rete che è necessario prendere in considerazione e le decisioni di progettazione necessarie per la preparazione della distribuzione della rete.

Topologia

La progettazione e l'implementazione della rete locale sono una parte fondamentale della distribuzione AP5GC. È necessario prendere decisioni di progettazione della rete per supportare il core del pacchetto AP5GC e qualsiasi altro carico di lavoro perimetrale. Questa sezione descrive alcune decisioni da prendere in considerazione durante la progettazione della rete e fornisce alcune topologie di rete di esempio. Il diagramma seguente illustra una topologia di rete di base.

Considerazioni relative alla progettazione

Quando viene distribuito in Azure Stack Edge Pro GPU (A edizione Standard), AP5GC usa la porta fisica 5 per l'accesso ai segnali e ai dati (punti di riferimento 5G N2 e N3/4G S1 e S1-U) e la porta 6 per i dati core (punti di riferimento 5G N6/4G SGi). Se sono configurate più di sei reti dati, viene usata anche la porta 5 per i dati principali.

AP5GC supporta le distribuzioni con o senza router di livello 3 sulle porte 5 e 6. Ciò è utile per evitare hardware aggiuntivo in siti perimetrali più piccoli.

• È possibile connettere A edizione Standard porta 5 ai nodi RAN direttamente (back-to-back) o tramite un commutatore di livello 2. Quando si usa questa topologia, è necessario configurare l'indirizzo eNodeB/gNodeB come gateway predefinito nell'interfaccia di rete A edizione Standard.
• Analogamente, è possibile connettere A edizione Standard porta 6 alla rete principale tramite un commutatore di livello 2. Quando si usa questa topologia, è necessario configurare un'applicazione o un indirizzo arbitrario nella subnet come gateway sul lato A edizione Standard.
• In alternativa, è possibile combinare questi approcci. Ad esempio, è possibile usare un router sulla porta A edizione Standard 6 con una rete di livello 2 flat sulla porta A edizione Standard 5. Se nella rete locale è presente un router di livello 3, è necessario configurarlo in modo che corrisponda alla configurazione di A edizione Standard.

Quando viene distribuito in Azure Stack Edge 2 (A edizione Standard 2), AP5GC usa la porta fisica 3 per l'accesso ai segnali e ai dati (punti di riferimento 5G N2 e N3/4G S1 e S1-U) e la porta 4 per i dati core (punti di riferimento 5G N6/4G SGi). Se sono configurate più di sei reti dati, viene usata anche la porta 3 per i dati principali.

AP5GC supporta le distribuzioni con o senza router di livello 3 sulle porte 3 e 4. Ciò è utile per evitare hardware aggiuntivo in siti perimetrali più piccoli.

• È possibile connettere A edizione Standard porta 3 ai nodi RAN direttamente (back-to-back) o tramite un commutatore di livello 2. Quando si usa questa topologia, è necessario configurare l'indirizzo eNodeB/gNodeB come gateway predefinito nell'interfaccia di rete A edizione Standard.
• Analogamente, è possibile connettere A edizione Standard porta 4 alla rete principale tramite un commutatore di livello 2. Quando si usa questa topologia, è necessario configurare un'applicazione o un indirizzo arbitrario nella subnet come gateway sul lato A edizione Standard.
• In alternativa, è possibile combinare questi approcci. Ad esempio, è possibile usare un router sulla porta A edizione Standard 4 con una rete flat di livello 2 su A edizione Standard porta 3. Se nella rete locale è presente un router di livello 3, è necessario configurarlo in modo che corrisponda alla configurazione di A edizione Standard.

A meno che il core del pacchetto non abbia nat (Network Address Translation) abilitato, un dispositivo di rete di livello 3 locale deve essere configurato con route statiche ai pool IP UE tramite l'indirizzo IP N6 appropriato per la rete dati collegata corrispondente.

Topologie di rete di esempio

Esistono diversi modi per configurare la rete da usare con AP5GC. La configurazione esatta varia a seconda delle esigenze e dell'hardware. Questa sezione fornisce alcune topologie di rete di esempio nell'hardware A edizione Standard Pro GPU.

• Rete di livello 3 con NAT (Network Address Translation) N6
  Questa topologia di rete dispone dell'A edizione Standard connessa a un dispositivo di livello 2 che fornisce la connettività al core di rete mobile e ai gateway di accesso (router che connettono rispettivamente l'A edizione Standard ai dati e alle reti di accesso). Questa topologia supporta fino a sei reti dati. Questa soluzione viene comunemente usata perché semplifica il routing di livello 3.
  

• Rete di livello 3 senza NAT (Network Address Translation)
  Questa topologia di rete è una soluzione simile, ma gli intervalli di indirizzi IP UE devono essere configurati come route statiche nel router di rete dati con l'indirizzo IP NAT N6 come indirizzo hop successivo. Come per la soluzione precedente, questa topologia supporta fino a sei reti dati.

• Rete flat di livello 2
  Il core del pacchetto non richiede router di livello 3 o funzionalità simili a router. Una topologia alternativa potrebbe rinunciare completamente all'uso dei router gateway di livello 3 e costruire invece una rete di livello 2 in cui l'A edizione Standard si trova nella stessa subnet dei dati e delle reti di accesso. Questa topologia di rete può essere un'alternativa più economica quando non è necessario il routing di livello 3. Ciò richiede l'abilitazione di NapT (Network Address Port Translation) nel core del pacchetto.
  

• Rete di livello 3 con più reti dati

  • AP5GC può supportare fino a dieci reti dati collegate, ognuna con la propria configurazione per Domain Name System (DNS), pool di indirizzi IP UE, configurazione IP N6 e NAT. L'operatore può effettuare il provisioning di ENTITÀ come sottoscritte in una o più reti dati e applicare la configurazione QoS (Data Network Network Specific Policy and Quality of Service).
  • Questa topologia richiede che l'interfaccia N6 sia suddivisa in una subnet per ogni rete dati o una subnet per tutte le reti dati. Questa opzione richiede quindi un'attenta pianificazione e configurazione per evitare la sovrapposizione degli intervalli IP della rete dati o degli intervalli IP UE.
    

• Rete di livello 3 con VLAN e separazione fisica/core

  • È anche possibile separare il traffico A edizione Standard in VLAN, indipendentemente dal fatto che si scelga o meno di aggiungere gateway di livello 3 alla rete. Esistono diversi vantaggi per segmentare il traffico in VLAN separate, tra cui una gestione della rete più flessibile e una maggiore sicurezza.
  • Ad esempio, è possibile configurare VLAN separate per la gestione, l'accesso e il traffico dati o una VLAN separata per ogni rete dati collegata.
  • Le VLAN devono essere configurate nelle apparecchiature di rete di livello 2 o livello 3 locali. Più VLAN verranno eseguite su un singolo collegamento da A edizione Standard porta 5 (rete di accesso) e/o 6 (rete core), quindi è necessario configurare ognuno di questi collegamenti come trunk VLAN.

• Rete di livello 3 con reti dati da 7 a 10

  • Se si desidera distribuire più di sei reti dati separate da VLAN, le reti dati aggiuntive (fino a quattro) devono essere distribuite nella porta A edizione Standard porta 5. Questo richiede un commutatore condiviso o un router che trasporta sia l'accesso che il traffico principale. I tag VLAN possono essere assegnati in base alle esigenze di N2, N3 e ognuna delle reti dati N6.
  • Non è possibile configurare più di sei reti dati sulla stessa porta.
  • Per prestazioni ottimali, le reti dati con il carico previsto più elevato devono essere configurate sulla porta 6.

Esistono diversi modi per configurare la rete da usare con AP5GC. La configurazione esatta varia a seconda delle esigenze e dell'hardware. Questa sezione fornisce alcune topologie di rete di esempio nell'hardware A edizione Standard Pro 2.

• Rete di livello 3 con NAT (Network Address Translation) N6
  Questa topologia di rete dispone dell'A edizione Standard connessa a un dispositivo di livello 2 che fornisce la connettività al core di rete mobile e ai gateway di accesso (router che connettono rispettivamente l'A edizione Standard ai dati e alle reti di accesso). Questa topologia supporta fino a sei reti dati. Questa soluzione viene comunemente usata perché semplifica il routing di livello 3.
  

• Rete di livello 3 senza NAT (Network Address Translation)
  Questa topologia di rete è una soluzione simile, ma gli intervalli di indirizzi IP UE devono essere configurati come route statiche nel router di rete dati con l'indirizzo IP NAT N6 come indirizzo hop successivo. Come per la soluzione precedente, questa topologia supporta fino a sei reti dati.

• Rete flat di livello 2
  Il core del pacchetto non richiede router di livello 3 o funzionalità simili a router. Una topologia alternativa potrebbe rinunciare completamente all'uso dei router gateway di livello 3 e costruire invece una rete di livello 2 in cui l'A edizione Standard si trova nella stessa subnet dei dati e delle reti di accesso. Questa topologia di rete può essere un'alternativa più economica quando non è necessario il routing di livello 3. Ciò richiede l'abilitazione di NapT (Network Address Port Translation) nel core del pacchetto.
  

• Rete di livello 3 con più reti dati

  • AP5GC può supportare fino a dieci reti dati collegate, ognuna con la propria configurazione per Domain Name System (DNS), pool di indirizzi IP UE, configurazione IP N6 e NAT. L'operatore può effettuare il provisioning di ENTITÀ come sottoscritte in una o più reti dati e applicare la configurazione QoS (Data Network Network Specific Policy and Quality of Service).
  • Questa topologia richiede che l'interfaccia N6 sia suddivisa in una subnet per ogni rete dati o una subnet per tutte le reti dati. Questa opzione richiede quindi un'attenta pianificazione e configurazione per evitare la sovrapposizione degli intervalli IP della rete dati o degli intervalli IP UE.

  

• Rete di livello 3 con VLAN e separazione fisica/core

  • È anche possibile separare il traffico A edizione Standard in VLAN, indipendentemente dal fatto che si scelga o meno di aggiungere gateway di livello 3 alla rete. Esistono diversi vantaggi per segmentare il traffico in VLAN separate, tra cui una gestione della rete più flessibile e una maggiore sicurezza.
  • Ad esempio, è possibile configurare VLAN separate per la gestione, l'accesso e il traffico dati o una VLAN separata per ogni rete dati collegata.
  • Le VLAN devono essere configurate nelle apparecchiature di rete di livello 2 o livello 3 locali. Più VLAN verranno eseguite su un singolo collegamento dalla porta A edizione Standard porta 3 (rete di accesso) e/o 4 (rete core), quindi è necessario configurare ognuno di questi collegamenti come trunk VLAN.

  

• Rete di livello 3 con reti dati da 7 a 10

  • Se si desidera distribuire più di sei reti dati separate da VLAN, le reti dati aggiuntive (fino a quattro) devono essere distribuite sulla porta A edizione Standard porta 3. Questo richiede un commutatore condiviso o un router che trasporta sia l'accesso che il traffico principale. I tag VLAN possono essere assegnati in base alle esigenze di N2, N3 e ognuna delle reti dati N6.
  • Non è possibile configurare più di sei reti dati sulla stessa porta.
  • Per ottenere prestazioni ottimali, le reti dati con il carico previsto più elevato devono essere configurate sulla porta 4.

  

Subnet e indirizzi IP

Potrebbero essere presenti reti IP esistenti nel sito aziendale con cui dovrà integrarsi la rete cellulare privata. Questo può significare, ad esempio:

• Selezione di subnet IP e indirizzi IP per AP5GC corrispondenti a subnet esistenti senza conflitti di indirizzi.
• Segregazione della nuova rete tramite router IP o uso dello spazio di indirizzi RFC 1918 privato per le subnet.
• Assegnazione di un pool di indirizzi IP specificamente per l'uso da parte delle ENTITÀ quando si connettino alla rete.
• Uso di Network Address Port Translation (NAPT), sul core del pacchetto stesso o su un dispositivo di rete upstream, ad esempio un router di bordo.
• Ottimizzazione della rete per le prestazioni scegliendo un'unità di trasmissione massima (MTU) che riduce al minimo la frammentazione.

È necessario documentare le subnet IPv4 che verranno usate per la distribuzione e accettare gli indirizzi IP da usare per ogni elemento della soluzione e sugli indirizzi IP che verranno allocati alle entità utente quando si collegano. È necessario distribuire (o configurare router e firewall esistenti) nel sito aziendale per consentire il traffico. È inoltre necessario accettare come e dove nella rete sono necessarie modifiche NAPT o MTU e pianificare la configurazione del router/firewall associata. Per altre informazioni, vedere Completare le attività dei prerequisiti per la distribuzione di una rete mobile privata.

Accesso alla rete

La progettazione deve riflettere le regole dell'organizzazione sulle reti e gli asset che devono essere raggiungibili dall'entità utente e dall'entità utente nella rete 5G privata. Ad esempio, potrebbero essere autorizzati ad accedere al DNS (Domain Name System), al protocollo DHCP (Dynamic Host Configuration Protocol), a Internet o ad Azure, ma non a una rete locale (LAN) per le operazioni di fabbrica. Potrebbe essere necessario disporre per l'accesso remoto alla rete in modo da poter risolvere i problemi senza richiedere una visita al sito. È anche necessario considerare come il sito aziendale verrà connesso a reti upstream, ad esempio Azure per la gestione e/o per l'accesso ad altre risorse e applicazioni all'esterno del sito aziendale.

È necessario concordare con il team aziendale quali subnet IP e indirizzi saranno autorizzati a comunicare tra loro. Creare quindi una configurazione del piano di routing e/o dell'elenco di controllo di accesso (ACL) che implementa questo contratto nell'infrastruttura IP locale. È anche possibile usare reti VLAN (Virtual Local Area Networks) per partizionare gli elementi al livello 2, configurando l'infrastruttura del commutatore per assegnare porte connesse a VLAN specifiche(ad esempio, per inserire la porta di Azure Stack Edge usata per l'accesso RAN nella stessa VLAN delle unità RAN connesse al commutatore Ethernet). È anche necessario concordare con l'azienda di configurare un meccanismo di accesso, ad esempio una rete privata virtuale (VPN), che consente al personale di supporto di connettersi in remoto all'interfaccia di gestione di ogni elemento nella soluzione. È anche necessario un collegamento IP tra Azure Private 5G Core e Azure per la gestione e la telemetria.

Conformità RAN

L'istanza rana usata per trasmettere il segnale all'interno del sito aziendale deve essere conforme alle normative locali. Ad esempio, questo potrebbe significare:

• Le unità RAN hanno completato il processo di omologazione e ricevuto l'approvazione normativa per il loro utilizzo su una determinata banda di frequenza in un paese/area geografica.
• È stata ricevuta l'autorizzazione per la trasmissione della rete RAN usando lo spettro in una determinata posizione, ad esempio concedendole da un operatore di telecomunicazione, da un'autorità di regolamentazione o tramite una soluzione tecnologica, ad esempio una sas (Spectrum Access System).
• Le unità RAN in un sito hanno accesso a origini di temporizzazione ad alta precisione, ad esempio PTP (Precision Time Protocol) e servizi di posizione GPS.

È consigliabile chiedere al partner RAN di ottenere i paesi/aree geografiche e le bande di frequenza per cui l'rana è approvata.You should ask your RAN partner for the countries/regions and frequency band for the RAN is approved. Potrebbe essere necessario usare più partner RAN per coprire i paesi e le aree geografiche in cui si fornisce la soluzione. Anche se il core RAN, UE e packet comunicano tutti usando protocolli standard, è consigliabile eseguire test di interoperabilità per il protocollo 4G Long-Term Evolution (LTE) o 5G autonomo (SA) tra Azure Private 5G Core, UEs e RAN prima di qualsiasi distribuzione in un cliente aziendale.

L'operatore RAN trasmetterà un'identità di rete mobile pubblica (ID PLMN) a tutti gli UES sulla banda di frequenza configurata per l'uso. È necessario definire l'ID DEL SISTEMA DI GESTIONE dei dati e confermare l'accesso allo spettro. In alcuni paesi/regioni, lo spettro deve essere ottenuto dal regolamentazione nazionale/regionale o dall'operatore di telecomunicazioni in carica. Ad esempio, se si usa lo spettro CBRS (Band Broadband Radio Service) 48 Citizens, potrebbe essere necessario collaborare con il partner RAN per distribuire un proxy di dominio di Spectrum Access System (SAS) nel sito aziendale, in modo che l'accesso ran possa controllare continuamente che sia autorizzato a trasmettere.

Unità di trasmissione massime (MTU)

L'unità di trasmissione massima (MTU) è una proprietà di un collegamento IP e viene configurata nelle interfacce a ogni estremità del collegamento. I pacchetti che superano l'MTU configurato di un'interfaccia vengono suddivisi in pacchetti più piccoli tramite frammentazione IPv4 prima dell'invio e vengono quindi riassemblati nella destinazione. Tuttavia, se la MTU configurata di un'interfaccia è superiore a quella supportata dal collegamento, il pacchetto non verrà trasmesso correttamente.

Per evitare problemi di trasmissione causati dalla frammentazione IPv4, un core di pacchetti 4G o 5G indica agli UES quali MTU devono usare. Tuttavia, gli UES non rispettano sempre la MTU segnalata dal core del pacchetto.

I pacchetti IP delle ENTITÀ vengono sottoposti a tunneling da RAN, che comporta un sovraccarico dall'incapsulamento.IP packets from UEs are tunneled through from the RAN, which adds overhead from encapsulation. Il valore MTU per l'UE deve quindi essere inferiore al valore MTU usato tra ran e core del pacchetto per evitare problemi di trasmissione.

Le reti RAN in genere sono preconfigurato con una MTU di 1500. L'MTU UE predefinito del core di pacchetti è di 1440 byte per consentire l'overhead di incapsulamento. Questi valori ottimizzano l'interoperabilità RAN, ma rischiano di non osservare l'MTU predefinito e di generare pacchetti più grandi che richiedono frammentazione IPv4 e che potrebbero essere eliminati dalla rete. Se si è interessati da questo problema, è consigliabile configurare l'istanza ran-of-ran per l'uso di un MTU di 1560 o superiore, che consente un sovraccarico sufficiente per l'incapsulamento ed evita la frammentazione con un UE usando un MTU standard pari a 1500.

È anche possibile modificare l'MTU UE segnalato dal core del pacchetto. È consigliabile impostare MTU su un valore compreso nell'intervallo supportato dalle entità utente e da 60 byte al di sotto dell'MTU segnalato dall'esecuzione. Tenere presente quanto segue:

• La rete dati (N6) viene aggiornata automaticamente in modo che corrisponda all'UE MTU.
• La rete di accesso (N3) viene aggiornata automaticamente in modo che corrisponda a UE MTU più 60.
• È possibile configurare un valore compreso tra 1280 e 1930 byte.

Per modificare l'MTU UE segnalato dal core del pacchetto, vedere Modificare un'istanza di base del pacchetto.

Copertura del segnale

Gli UES devono essere in grado di comunicare con l'entità di esecuzione da qualsiasi posizione nel sito. Ciò significa che i segnali devono propagarsi in modo efficace nell'ambiente, inclusa la necessità di tenere conto delle ostruzioni e delle attrezzature, per supportare le ENTITÀ che si spostano intorno al sito (ad esempio, tra aree interne ed esterne).

È consigliabile eseguire un sondaggio sul sito con il partner RAN e l'azienda per assicurarsi che la copertura sia adeguata. Assicurarsi di comprendere le funzionalità delle unità RAN in ambienti diversi ed eventuali limiti, ad esempio per il numero di unità definite dall'utente associate che una singola unità può supportare. Se gli UES si spostano intorno al sito, è anche necessario verificare che l'interfaccia RAN supporti il passaggio X2 (4G) o Xn (5G), che consente all'UE di passare senza problemi tra la copertura fornita da due unità RAN. Se la rete RAN non supporta X2 (4G) o Xn (5G), RAN deve supportare S1 (4G) e N2 (5G) per la mobilità UE. Si noti che le UES non possono usare queste tecniche di trasferimento per spostarsi tra una rete aziendale privata e la rete cellulare pubblica offerta da un operatore di telecomunicazione.

SIM

Ogni UE deve presentare un'identità alla rete, codificata in un modulo di identità sottoscrittore (SIM). I SIM sono disponibili in diversi fattori di forma fisica e in formato di sola software (eSIM). I dati codificati nella SIM devono corrispondere alla configurazione della rete RAN e dei dati di identità di cui è stato effettuato il provisioning in Azure Private 5G Core.

Ottenere i SIM in fattori compatibili con gli IDE e programmati con l'ID e le chiavi DEL SISTEMA DI GESTIONE dei dati che si desidera usare per la distribuzione. I SIM fisici sono ampiamente disponibili sul mercato aperto a costi relativamente bassi. Se si preferisce usare eSIM, è necessario distribuire la configurazione e il provisioning di eSIM necessari in modo che gli utenti possano configurarsi prima di connettersi alla rete cellulare. È possibile usare i dati di provisioning ricevuti dal partner SIM per effettuare il provisioning di voci corrispondenti in Azure Private 5G Core. Poiché i dati SIM devono essere mantenuti sicuri, le chiavi crittografiche usate per effettuare il provisioning di SIM non sono leggibili una volta impostate, quindi è necessario considerare come archiviarle nel caso in cui sia mai necessario eseguire nuovamente il provisioning dei dati in Azure Private 5G Core.

Automazione e integrazione

La creazione di reti aziendali usando l'automazione e altre tecniche a livello di codice consente di risparmiare tempo, riduce gli errori e produce risultati migliori. Queste tecniche forniscono anche un percorso di ripristino in caso di errore del sito che richiede la ricompilazione della rete.

È consigliabile adottare un approccio programmatico e infrastruttura come codice alle distribuzioni. È possibile usare modelli o l'API REST di Azure per compilare la distribuzione usando parametri come input con valori raccolti durante la fase di progettazione del progetto. È consigliabile salvare le informazioni di provisioning, ad esempio dati SIM, configurazione switch/router e criteri di rete in formato leggibile dal computer in modo che, in caso di errore, è possibile riapplicare la configurazione nello stesso modo in cui è stato originariamente fatto. Un'altra procedura consigliata per il ripristino da un errore consiste nel distribuire un server Azure Stack Edge di riserva per ridurre al minimo il tempo di ripristino in caso di errore della prima unità; è quindi possibile usare i modelli e gli input salvati per ricreare rapidamente la distribuzione. Per altre informazioni sulla distribuzione di una rete con modelli, vedere Avvio rapido: Distribuire una rete mobile privata e un modello di Resource Manager.

È anche necessario considerare come integrare altri prodotti e servizi di Azure con la rete aziendale privata. Questi prodotti includono Microsoft Entra ID e il controllo degli accessi in base al ruolo, in cui è necessario considerare il modo in cui i tenant, le sottoscrizioni e le autorizzazioni delle risorse saranno allineati al modello di business esistente tra l'utente e l'azienda e come approccio personalizzato alla gestione del sistema dei clienti. Ad esempio, è possibile usare Azure Blueprints per configurare le sottoscrizioni e il modello di gruppo di risorse più adatti per l'organizzazione.

Passaggi successivi

• Altre informazioni sui componenti chiave di una rete mobile privata
• Altre informazioni sui prerequisiti per la distribuzione di una rete mobile privata