This article is the second part of our series on the state of private mobile networks. You can read the first part of our series discussing potential misconceptions on wireless spectrum, technology maturity, and cost consideration here.
Our first article touched on several misconceptions about private mobile networks (PMNs). This second article address private wireless deployment and integration issues and separates truths from untruths.
Enterprises can’t deploy private 5G on their own
This half-truth is like the misconception in the previous article about mobile operators needing to be involved in PMN deployment. Some enterprises believe private 5G is hard for them to deploy and manage and always requires an integrator or expert assistance. The veracity of this statement, however, is dependent on the nature of the deployment. More complicated use cases and environments may require detailed radio frequency (RF) planning or integration with vertical applications. In these situations, an integrator or expert might be necessary.
Regardless, with vendors gaining experience across diverse deployment and codifying learnings into product features and blueprints, there are now more use cases and setups that no longer require third-party experts. Enterprises can purchase managed solutions for PMNs that they can deploy or rapidly set up with limited vendor assistance. The situation will improve as we gain more collective knowledge around best practices for many more use cases.
Private 5G doesn’t play well with others
PMNs have been accused of failing to integrate well into enterprise IT stacks. WiFi APs and controllers plug right into the enterprise LAN, with traffic dropping straight into their networks. Enterprise ITs know how to manage WiFi traffic, set VLANs and SSID-VLAN mapping, tweak access control lists (ACLs) and install cross-segment firewalls for security. PMNs, whether 4G or 5G, have separate RAN and core components, and traffic needs to be carried from the RAN into the core before it exits via the SGi (4G LTE) on the P-GW or N6 interface (5G) on the 5GC UPF. This setup can break enterprise IT LAN plans if not well managed or planned.
Further, enterprise IT is used to keeping the identities of devices and users in their directories (Active Directory, Azure AD). And WiFi uses 802.1X/RADIUS to authenticate enterprise users and devices. However, with PMNs, enterprise IT needs to work out SIM identity management and correlate across multiple devices and user identities that may access the network both using WiFi and private wireless.
PMN vendors understand these complexities and are working towards more distributed architectures, with 5GC UPFs deployed at different egress points closer to the radio units and where workloads live. Likewise, enterprise-friendly solutions for managing unified identity and policies are emerging as PMN deployment becomes more pervasive.
Private 5G doesn’t play well alone
There’s a misconception that private 5G can never work in a disconnected environment. PMNs that run on licensed frequencies (either from the government or mobile operators) don’t have an issue running disconnected from the internet. Similarly, using global unlicensed bands like 5 GHz doesn’t require permission (e.g., MulteFire, a 4G LTE solution that operates standalone in unlicensed and shared spectrum).
However, in the US, CBRS requires the CBRS Device (CBSD) to conduct periodic heartbeat checks against the spectrum allocation service (SAS) directly or via a domain proxy. If a CBSD does not establish a successful heartbeat for a few minutes, it must stop transmitting. In this situation, a fully disconnected deployment might not be possible. While CBRS vendors work towards solutions resilient to backhaul connectivity issues, some private 5G deployments are using satellite as backhaul. With more low earth orbit offerings like Starlink, pure disconnected operations might be less of an issue.
The requisite 5G network slicing discussion
Almost any 5G discussion is incomplete without touching on network slicing. Some think private 5G adds little value until network slicing is available. This misconception involves a more detailed discussion around private 5G deployment architecture.
The typical architectural deployment for private 5G or 4G LTE is a standalone network – known in 3GPP definitions as a Standalone Non-Public Network (SNPN). This is a separate network from the macro public network. Sometimes, these NPNs may be attached to a macro public network and allow mobility of user equipment between the two via various standard techniques, including the use of a multi-operator core network (MOCN) gateway. These are called public network integrated NPN (PNI-NPN).
There is yet a third and confusing version of what is termed a private network. In this version, the “private network” refers to a network slice of a public 5G macro network dedicated to an enterprise as a private 5G network. This is sometimes compared to what we call private access point name (private APNs) in the 4G world. Only a mobile network operator can provide this, and this is a less typical implementation of private networks today.
In the context of the more common SNPN, network slicing is less necessary since these SNPNs are dedicated to an enterprise, and the performance characteristics for a specific workload are managed without the complication and overhead of network slicing. So, for the typical PMNs deployment today, network slicing is less relevant and unnecessary for operations.
That wraps up both our articles where we covered the top confusing items encountered in our engagements and conversations with enterprises. For the third article in our series, we’ll discuss successful enterprise strategies for private 5G deployment.
