Private 5G: Tips on how to implement it, from enterprises that already have

We hear a lot about private 5G, meaning 5G networks deployed and owned by individual enterprises. A lot online, anyway; of 177 enterprises I’ve talked with this year, only three said they even knew how to build a private 5G network, and these three learned by doing it. The three discovered an important, but usually unrecognized, question, which is, “What do I it run on?”

One reason private 5G gets a lot of attention is that vendors have to talk about something, and one choice is to say something exciting and, well, maybe less than factual. The other is to say something factual and utterly uninteresting. Guess which gets said? The three enterprises that built private 5G networks had to educate themselves with a material from a variety of sources, including the O-RAN alliance, and one of the three characterized this as learning another language, with a dozen or more boxes in the architecture, none of which relate to anything enterprises have seen before.

Enterprise planners aren’t writing standards, they’re trying to lay out how to buy products. When you can’t map what you see in an architecture to anything that you can buy it makes you a bit uneasy. If you ask what all these functional blocks run on, you probably hear that they can run on white-box switches or servers or whatever you like—and that doesn’t stem the unease.

The 5g control and user planes: Different from IP’s

5G standards divide into two stacks of two layers each. There are the 5G-radio-access network (RAN) and 5G-core stacks, and each contains what’s called the control plane and the user plane. “Hey, this looks a lot like IP,” you might think; it has a control plane and data plane after all. The problem is that the 5G user plane contains all of the IP control and data planes, not explicitly but by inference. You won’t see them on the 5G functional block diagrams, but they’re there. The 5G control plane is totally new, above all the IP stuff. The good news is that almost everyone will tell you that 5G control-plane functions in both RAN and core are hosted on servers.  (Finally, a product!) But the rest…well, we can at least establish some rules based on the experience of enterprises with white boxes and hosted network features.

Four rules to know about private 5G

The first rule is your private 5G is a user of your IP network, not an extension of it. Every location you expect to host private 5G cells and every site you expect will have some 5G features hosted will need to be on your corporate VPN, supported by the switches and routers you’d typically use. Since all three private-5G enterprises were using their 5G networks largely for IoT that was focused on some large facilities, that didn’t present a problem for them. It seems likely that most future private 5G adoption will fit the same model, so this rule should be easy to follow overall.

The second rule is that 5G control-plane functions will be hosted on servers. 5G RAN and O-RAN control-plane elements should be hosted close to your 5G cells, and 5G core features at points where it’s convenient to concentrate private 5G traffic. Try to use the same kind of server technology, the same middleware, and the same software source for all of this, and be sure you get high-availability features.

Rule three is that 5G user-plane functions associated with the RAN should be hosted on servers, located with the 5G RAN control-plane features. You can almost surely share servers with the control plane in IoT applications, because event-based traffic is typically modest. If your private 5G application will involve other traffic types with higher expected volumes, you’ll probably want to use white boxes to host your user-plane functions. In any case, your user-plane host will connect with your VPN.

The fourth rule is that 5G core user-plane functions should be hosted on white boxes, simply because there will be more traffic here, and you’ll want higher traffic capacity and devices designed for high availability and low-latency behavior. However, since many IoT applications don’t involve device mobility, it may be possible to use servers here too, if there are no other traffic sources.

Two of the three private 5G enterprises said they used white boxes for all their user-plane hosting, and both admitted that might have been unnecessary in IoT applications because traffic levels were very modest.  They did say that they would have felt most comfortable with servers if they used custom network adapters and server hardware features to accelerate traffic handling.

The question of where you get the servers and white box switches needs answering too. The private-5G enterprises agreed that it’s best to start with 5G software, which you’d select based on features and cost, and then if the software source doesn’t also provide hardware installation and support, get them to recommend an integrator who can. The integrator would then lay out the structure of the 5G deployment, noting cell sites, backhaul requirements, and the locations where white-box switches and servers would be installed. From that, they can map specific hardware to each site.

Open RAN is a must

Maybe our sample of three 5G literati seems too small to make general observations about best practices, but the fact is that it’s because there are so few 5G-literate enterprises that we need to do that. This is not a do-it-yourself project based on the low level of exposure and familiarity among enterprises overall. If you think it’s hard to hire qualified network engineers today, you can bet that getting engineers with 5G deployment experience will make the former look like casting for a movie crowd scene in comparison.

But don’t let sparse private 5G skills make you jump into the arms of a big 5G service-provider vendor either.  The one thing that the 177 enterprises agreed on regarding private 5G was that they did not want to be locked into a single supplier. That means selecting an open-model approach, which means O-RAN compliance. Even with that, though, be sure your vendor lets you pick your devices from a list of multiple candidates, rather than choosing a specific device for you.

Let’s face it, if you’re really looking at private 5G you already know (or should know) that you’re stepping well beyond the leading edge for enterprise networking. In fact, all three of the private 5G adopters said they believed that their applications could have been supported via Wi-Fi 6, and felt that would be true for virtually all IoT applications except those involving mobile sensors (transportation) that should be supported on public mobile networks anyway. Two of the three said that it would actually have been easier to use Wi-Fi 6.These two said that 5G-vendor influence on upper management pushed them in a 5G direction.

It is possible for enterprises to build private 5G using primarily, or even exclusively, server technology, but if you’re committed to that, it’s best to use software that can be run on both servers and white boxes to protect your path of evolution. But the best strategy of all is to start your IoT projects assuming Wi-Fi 6 is your advanced connection option, and move to private 5G only if that can’t be made to work. No-box trumps everything in private 5G.