Over the years evolving from 2G to 3G to 4G technologies, much has changed in telecommunications networks. Through it all though, one constant remained: the communications service provider (CSP) was in full control of their entire end-to-end network. Now, as we move into 5G Standalone (5G SA) architectures, you can throw that out the window.
Historically, building a telecom infrastructure was largely a question of assembling the right hardware. To deploy a 4G core network, for example, you would pick a vendor and deploy some combination of their chassis, along with all the necessary functional components. Those components—IP Multimedia Subsystem (IMS), Serving Gateway (S-GW), and many others—were physical cards, in a physical appliance, deployed in a data center that you managed and controlled.
Fast forward to 5G SA, and things look very different. All of a sudden, the fundamental building blocks of the network—whether virtual device, virtual element, or virtual node or interface—run as pure software, hosted in data centers (plural), which a CSP may or may not choose to own. And by the way, this software can now come from multiple vendors, each updating at its own cadence.
If you’re a CSP, this means that instead of conducting a couple major upgrades per year in carefully planned maintenance windows, your network can now change literally by the hour. Your infrastructure becomes a living, breathing, always-on entity. Which means you need an always-on testing capability as well.
It’s a monumental change to the way CSPs run their networks. And building that capacity—to continually update infrastructure and continually verify that it’s behaving as it should—is no small task. Fortunately, operators are making significant strides in bringing telco networks into the cloud-native world.
Cloudifying Telecom Networks
5G brings a long list of changes for network operations teams, but none will have more far-reaching impact than the shift to virtualized, microservices-based architectures. Soon, every part of a telecom infrastructure will need to run as cloud-native software—malleable, extensible, and instantly portable from one location to another. This agility brings big advantages, enabling operators to continually create new kinds of services and bring them to market much more quickly. But it also creates a network that’s far more dynamic and complex.
Like any other piece of modern software, virtualized network components will receive ongoing vendor software updates (for bug fixes, security patches, new features) via Continuous Integration/Continuous Delivery (CI/CD) pipelines. By definition then, this ever-changing network will need nonstop, always-on testing capabilities to continually and proactively validate that those updates won’t break services or open new vulnerabilities.
The good news is that service providers already have many of the tools needed for continuous testing. The problem: today, most exist solely in certification labs. Traditionally, those labs would validate new vendor software (again, a few times per year for major upgrades), then release it to preproduction and production teams. Those teams sometimes test network software too—but they use their own totally separate live testing tools. (Google “telco lab tools” and “telco live testing,” and you’ll see completely different vendors.)
In a 5G SA world, where software can go from lab to live multiple times per week—if not per day—that separation won’t work. Operators will need to translate lab testing and certification capabilities to the production environment. And since that environment now constantly changes, they’ll need to be able to test and certify over and over again, 24 hours a day, seven days a week.
Building Continuous Testing
Most operators are still in early stages of implementing an autonomous CI/CD methodology that can follow telco networks across the lifecycle. But as they bring continuous testing to live networks, they’re clearing one of the biggest remaining hurdles. As they do, they’re learning some important lessons:
- Build for continuous testing from day-one design. In the past, production teams sometimes viewed testing as an afterthought. They’d test when troubleshooting problems, but it was never part of a formal, ongoing operational process that proactively identifies issues prior to deployment. In an always-on cloud-native world, always-on testing becomes as important as basic connectivity. (If the network software connecting your subscribers can change every day, you’d better make sure you can verify any changes won’t impact performance.) Continuous testing capabilities should therefore be embedded into the infrastructure, by default, from day one. If they’re not? You might find yourself adding months to deployment timelines trying to implement testing after the fact.
- Embrace the shift from deterministic lab environments to unknown production environments. Historically, lab testing was static and deterministic, by definition. A certification team might test a vendor’s new network function against, for example, 10,000 users and three application types. If the network function passed, the lab sent it on for deployment. With 5G, the network is now highly dynamic and the future unknown. A network element deployed today might initially support 3,000 users and two application types, but a year from now, it might need to support 100,000 users accessing a dozen different application types. If network behavior is no longer deterministic, testing can’t be either. Instead, certification labs should focus more on verifying that new elements are scalable and flexible enough to change with the network as it evolves.
- Use testing to hold partners accountable. Service providers partnering to deliver 5G services—from Tier-2 operators running over incumbent networks to Tier-1s leasing fiber from one another—will need to meet more stringent requirements, with hefty fees if they fail to live up to SLAs. Having always-on, deep insight into every part of the network can prove extremely useful in ensuring everyone lives up to their obligations. Some operators have even found that fees recouped from SLA violations paid for their continuous testing investment, and then some.
Operators still have work ahead to translate all lab functions to the live network—much less implement autonomous CI/CD pipelines across the infrastructure. But the steps they’re taking now lay the foundation for true cloud-native operations. Service providers may not be able to control every part of the network as they have in the past. But with continuous testing, they can worry less about how constant change might impact the network, and focus on harnessing that dynamism to fuel innovation.
