Complete the prerequisite tasks for deploying a private mobile network

In this how-to guide, you'll carry out each of the tasks you need to complete before you can deploy a private mobile network using Azure Private 5G Core.

Tools and access

To deploy your private mobile network using Azure Private 5G Core, you need:

• A Windows PC with internet access
• A Windows Administrator account on that PC
• Azure CLI
• PowerShell
• kubectl

Get access to Azure Private 5G Core for your Azure subscription

Contact your trials engineer and ask them to register your Azure subscription for access to Azure Private 5G Core. If you don't already have a trials engineer and are interested in trialing Azure Private 5G Core, contact your Microsoft account team, or express your interest through the partner registration form.

Choose the core technology type (5G, 4G, or combined 4G and 5G)

Choose whether each site in the private mobile network should provide coverage for 5G, 4G, or combined 4G and 5G user equipment (UEs). If you're deploying multiple sites, they can each support different core technology types.

Choose a standard or Highly Available deployment

Azure Private 5G Core is deployed as an Azure Kubernetes Service (AKS) cluster. This cluster can run on a single Azure Stack Edge (ASE) device, or on a pair of ASE devices for a Highly Available (HA) service. An HA deployment allows the service to be maintained in the event of an ASE hardware failure.

For an HA deployment, you will need to deploy a gateway router (strictly, a Layer 3 capable device – either a router or an L3 switch (router/switch hybrid)) between the ASE cluster and:

• the RAN equipment in the access network.
• the data network(s).

The gateway router must support Bidirectional Forwarding Detection (BFD) and Mellanox-compatible SFPs (small form factor pluggable modules).

You must design your network to tolerate failure of a gateway router in the access network or in a data network. AP5GC only supports a single gateway router IP address per network. Therefore, only a network design where there is either a single gateway router per network or where the gateway routers are deployed in redundant pairs in an active / standby configuration with a floating gateway IP address is supported. The gateway routers in each redundant pair should monitor each other using VRRP (Virtual Router Redundancy Protocol) to provide detection of partner failure.

Cluster network topologies

AP5GC HA is built on a platform comprising a two node cluster of ASE devices. The ASEs are connected to a common L2 broadcast domain and IP subnet in the access network (or else two common L2 domains, one for N2 and one for N3, using VLANs) and in each of the core networks. They also share an L2 broadcast domain and IP subnet on the management network.

Cluster quorum and witness

A two node ASE cluster requires a cluster witness, so that if one of the ASE nodes fails, the cluster witness accounts for the third vote, and the cluster stays online. The cluster witness runs in the Azure cloud.

To configure an Azure cloud witness, see https://video2.skills-academy.com/windows-server/failover-clustering/deploy-cloud-witness. The Replication field must be set to locally redundant storage (LRS). Firewalls between the ASE cluster and the Azure storage account must allow outbound traffic to https://.core.windows.net/ on port 443 (HTTPS).

Allocate subnets and IP addresses

Azure Private 5G Core requires a management network, access network, and up to ten data networks. These networks can all be part of the same, larger network, or they can be separate. The approach you use depends on your traffic separation requirements.

For each of these networks, allocate a subnet and then identify the listed IP addresses. If you're deploying multiple sites, you need to collect this information for each site.

Depending on your networking requirements (for example, if a limited set of subnets is available), you might choose to allocate a single subnet for all of the Azure Stack Edge interfaces, marked with an asterisk (*) in the following list.

Management network

Access network

You will need an IP subnet for control plane traffic and an IP subnet for user plane traffic. If control plane and user plane are on the same VLAN (or are not VLAN-tagged) then you can use a single IP subnet for both.

Data networks

Allocate the following IP addresses for each data network in the site:

• Network address in CIDR notation.
• Default gateway.
• One IP address for the user plane interface.
  • For 5G, this is the N6 interface
  • For 4G, this is the SGi interface.
  • For combined 4G and 5G, this is the N6/SGi interface.

The following IP addresses must be used by all the data networks in the site:

Additional virtual IP addresses (HA only)

The following virtual IP addresses are required for an HA deployment. These IP addresses MUST NOT be in any of the control plane or user plane subnets - they are used as destinations of static routes in the access network gateway routers. That is, they can be any valid IP address that is not included in any of the subnets configured in the access network.

• One virtual address to use as a virtual N2 address. The RAN equipment is configured to use this address.
• One virtual address to use as a virtual tunnel endpoint on the N3 reference point.

VLANs

You can optionally configure your Azure Stack Edge Pro device with virtual local area network (VLAN) tags. You can use this configuration to enable layer 2 traffic separation on the N2, N3 and N6 interfaces, or their 4G equivalents. For example, the ASE device has a single port for N2 and N3 traffic and a single port for all data network traffic. You can use VLAN tags to separate N2 and N3 traffic, or separate traffic for each connected data network.

Allocate VLAN IDs for each network as required.

If you are using VLANs to separate traffic for each data network, a local subnet is required for the data network-facing ports covering the default VLAN (VLAN 0). For HA, you must assign the gateway router IP address within this subnet.

Allocate user equipment (UE) IP address pools

Azure Private 5G Core supports the following IP address allocation methods for UEs.

• Dynamic. Dynamic IP address allocation automatically assigns a new IP address to a UE each time it connects to the private mobile network.

• Static. Static IP address allocation ensures that a UE receives the same IP address every time it connects to the private mobile network. Static IP addresses are useful when you want Internet of Things (IoT) applications to be able to consistently connect to the same device. For example, you can configure a video analysis application with the IP addresses of the cameras providing video streams. If these cameras have static IP addresses, you won't need to reconfigure the video analysis application with new IP addresses each time the cameras restart. You'll allocate static IP addresses to a UE as part of provisioning its SIM.

You can choose to support one or both of these methods for each data network in your site.

For each data network you're deploying:

• Decide which IP address allocation methods you want to support.

• For each method you want to support, identify an IP address pool from which IP addresses can be allocated to UEs. You must provide each IP address pool in CIDR notation.

  If you decide to support both methods for a particular data network, ensure that the IP address pools are of the same size and don't overlap.

• Decide whether you want to enable Network Address and Port Translation (NAPT) for the data network. NAPT allows you to translate a large pool of private IP addresses for UEs to a small pool of public IP addresses. The translation is performed at the point where traffic enters the data network, maximizing the utility of a limited supply of public IP addresses.

Configure Domain Name System (DNS) servers

DNS allows the translation between human-readable domain names and their associated machine-readable IP addresses. Depending on your requirements, you have the following options for configuring a DNS server for your data network:

• If you need the UEs connected to this data network to resolve domain names, you must configure one or more DNS servers. You must use a private DNS server if you need DNS resolution of internal hostnames. If you're only providing internet access to public DNS names, you can use a public or private DNS server.
• If you don't need the UEs to perform DNS resolution, or if all UEs in the network will use their own locally configured DNS servers (instead of the DNS servers signaled to them by the packet core), you can omit this configuration.

Configure

Prepare your networks

For each site you're deploying:

• Ensure you have at least one network switch with at least three ports available. You'll connect each Azure Stack Edge Pro device to the switch(es) in the same site as part of the instructions in Order and set up your Azure Stack Edge Pro device(s).
• For every network where you decided not to enable NAPT (as described in Allocate user equipment (UE) IP address pools), configure the data network to route traffic destined for the UE IP address pools via the IP address you allocated to the packet core instance's user plane interface on the data network.

Configure ports for local access

Port requirements for Azure Stack Edge

Port requirements for IoT Edge

Port requirements for Kubernetes on Azure Stack Edge

Outbound firewall ports required

Review and apply the firewall recommendations for the following services:

The following table contains the URL patterns for Azure Private 5G Core's outbound traffic.

Register resource providers

To use Azure Private 5G Core, you need to register some additional resource providers with your Azure subscription.

1. Sign into the Azure CLI with a user account that is associated with the Azure tenant that you are deploying Azure Private 5G Core into:

   az login
   

   Tip

   See Sign in interactively for full instructions.

2. If your account has multiple subscriptions, make sure you are in the correct one:

   az account set --subscription <subscription_id>
   

3. Check the Azure CLI version:

   az version
   

   If the CLI version is below 2.37.0, you must upgrade your Azure CLI to a newer version. See How to update the Azure CLI.

4. Register the following resource providers:

   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
   

Retrieve the Object ID (OID)

You need to obtain the object ID (OID) of the custom location resource provider in your Azure tenant. You must provide this OID when you create the Kubernetes service. You can obtain the OID using the Azure CLI or the Azure Cloud Shell on the portal. You must be an owner of your Azure subscription.

1. Sign in to the Azure CLI or Azure Cloud Shell.

2. Retrieve the OID:

   az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv
   

This command queries the custom location and will output an OID string. Save this string for use later when you're commissioning the Azure Stack Edge device.

Order and set up your Azure Stack Edge Pro device(s)

Complete the following for each site you want to add to your private mobile network. Detailed instructions for how to carry out each step are included in the Detailed instructions column where applicable.

Next steps

You can now commission the Azure Kubernetes Service (AKS) cluster on your Azure Stack Edge Pro 2 or Azure Stack Edge Pro GPU device to get it ready to deploy Azure Private 5G Core.

• Commission an AKS cluster