HomePrivate NetworksChallenges in planning, testing and assuring private networks

Challenges in planning, testing and assuring private networks

The process of deploying a private cellular network is different than enterprise Wi-Fi, but it’s one that companies who wish to explore 4G or 5G private networks should be familiar with.

In a session at the recent Private Networks European Forum, that topic was tackled with firsthand knowledge by Jim Neuens, VP and GM of wireless field instruments at Viavi Solutions and Stefan Richter, head of the department of local and private networks for Germany-based system integrator Mugler SE.

Richter said that enterprises seeking private networks are usually doing so for one of three common reasons:

Reducing cabling costs. In a manufacturing environment particularly, there are many instances where cables are currently being used, Richter said, and companies are seeking to both reduce costs and improve mobility on the shop floor. “Connecting with a private 5G system could reduce, overall, the cabling costs,” he said.

Supporting new applications. As Industry 4.0 concepts are increasingly applied, there are opportunities to improve logistical processes and automate them, according to Richter. This may include the use of Automated Guided Vehicles (AGVs), which require the high-performance, secure network infrastructure that can be provided by a private network, he added.

Replacing existing wireless technology. Richter said that customers are coming to Mugler for help to either replace or supplement existing wireless technology, including Wi-Fi, with private networks, particularly for support of critical applications.

So those are the most common reasons for enterprise and industrial customers to seek out private networks. What, then, are the challenges that they face in deployment and testing of those networks?

Neuens said that regression testing is a major one, and in a multi-vendor environment, managing release schedules between multiple vendors and dealing with the related regression and integration testing that must happen in a live, loaded environment. That also includes testing of fronthaul and backhaul. A major challenge, he added, is “really getting a handle on how you’re going to deploy new software in a live network without disrupting. [It’s] kind of like flying an airplane at 35,000 feet and trying to change out the oil or changing the engine.” The other challenging aspect, Neuens said, is assuring that the networks live up to, and continuously to live up to, the expected performance requirements. That’s really a new concept in enterprise wireless.

“This is the first time that we’ve had wireless networks that actually have service-level agreements (SLAs) driven around them. How do we manage that, how do we test and and how do we—more importantly—assure that? Not only the SLA validation, but quality of experience,” he said. “Wi-Fi in an enterprise environment was probably a little bit stronger than best-effort. It wasn’t mission-critical in many cases, and here we see the wireless technology transitioning into mission-critical aspects of the business.”

In order to plan and build such networks, Richter explained that the process starts around determining the purpose of the network and the needs of the use cases, including key performance indicators and SLAs of related services. For the network itself, Mugler then moves to checking frequency bands for restrictions for constraints as well as localized spectrum clearing and searching for potential sources of interference, as well as possible locations for cabling and mounting. The network planning itself is software-based and aimed at placing sites where required to get the coverage and capacity to meet the estalished KPIs. Then comes acceptance testing, including functional testing, handover testing and verification of the network performance that can be achieved in real-world use, such as throughput and latency. This is quite a bit more involved process than is typical of enterprise Wi-Fi, he noted—but it results in a network that has higher-quality coverage, predictability and performance to meet specific customer requirements.

Neuens classifies private network testing in several general categories:

Spectrum co-existence and interference mitigation. This covers the type of testing and checking of the spectrum environment that Richter described, to ensure that the RF environment is prepared for network deployment and RF issues are addressed.

Testing of coverage and performance, including SLA validation on the radio frequency environment. “Those aspects are very, very important and must be done,” he added. A private network, he continued, “is an engineered network. It’s designed to work at load. This isn’t a network that, when it gets loaded, everybody’s service is reduced. That’s not the way this works. This is designed to work at load, and it needs to be validated at load.”

Testing of the Wide Area Network (WAN) connection. For a private network that is connected to other private networks, the WAN connection is particularly important. It can impacts the ability to meet performance SLAs for a specific private network, he pointed out, and is often an overlooked aspect that is critical and must be tested.

The full panel discussion and more content from Private Networks European Forum is available for on-demand viewing here.


Previous post
Public LoRaWAN arrives in the Great Lakes – for regional IoT water management
virtual reality
Next post
China unveils 5-year plan to boost virtual reality