Since the introduction of LTE in 2009, most telco operators have had to maintain three networks in parallel—2G, 3G, and LTE—with smooth interworking between the three of them, sometimes even in the course of a single phone call.
Not only that, but operators need to offer their customers seamless connections with a host of other legacy systems, from ISDN to POTS. Each time the larger telco landscape gets more complex (which happens practically by the day), the presence of existing legacy systems amplifies that complexity—making life increasingly difficult for the testers tasked with verifying network functionality.And it’s not just the sheer number of possible services that makes testing legacy telephony difficult—it’s also the equipment required and the complexity of the use cases involved.
Below, you’ll find the top 5 challenges that testers face when dealing with legacy telephony in their networks, plus some thoughts on how to overcome those challenges.
1. Backward Compatibility with Legacy Services
This first bullet point might seem a little bit generalized, but in point of fact we mean something fairly specific by it: the ability to hand subscribers on your network over to ISDN and POTS services as needed.
This may seem simple, but small changes to your network can have an outsize impact on your ability to offer this functionality smoothly. For instance, buffers might suddenly be getting full and fragmented and released in the wrong order.
Or, IP and signalling might be getting routed incorrectly, and routing parameters might need changing based on capacity needs. Without some type of solution to simulate the necessary test conditions for POTS, fax, PSTN, etc. and a library of relevant test cases, you run a risk of service disruption each time you roll out a new service offering.
Now, let’s drill down a little deeper into some of the concerns we outlined above. Specifically, let’s talk about the SRVCC (Single Radio Voice Call Continuity) network function that allocates bandwidth for mid-call handovers from all-IP LTE networks to circuit-switched call bearer 2G/3G networks.
This is the mechanism by which your subscribers experience IRAT handovers and session transfers when they move to an area where they can’t get LTE coverage. When this happens, the challenge isn’t merely making sure that subscriber devices in your network can operate on older networks, but that they can fall back to those services without their calls being dropped.
This presents a particular challenge for testers because of the nature of this kind of mobility management. The fact that the SRVCC by definition only kicks in when a caller is on the move makes it tricky to test in a lab setting.
Once upon a time, this fact meant lengthy drive tests in which testers had to seek out the ill-defined borders of their LTE coverage. Now, it’s possible to simulate a loss of LTE service using an attenuator.
3. Automating Network Equipment
In the past couple of sections, you may have gotten a sense of the importance of this next challenge: choosing and automating the right equipment.
We’ll discuss the time pressures of modern telco testing a little more when we get to regression tests, but suffice it to say that the overall increase in complexity brought about by the inclusion of legacy systems into network architecture makes manual testing slower and less practical than ever.
When it comes to testing handsets and mobile devices, the possibility of automating verification via rooting or jailbreaking has been around for a while (though it has numerous pitfalls).
But as we can see above, a testing workflow that accounts for legacy telephony actually requires a lot of equipment and devices beyond the phones themselves. The challenge here is to incorporate that equipment seamlessly into your automation workflow.
Which means being able to control not just mobile phones and applications, but POTS/PSTN elements, analog modems (which can be used to simulate fax service, POTS, etc.), attenuators, and more.
Without doing so, any gains in efficiency you make from automating testcases will be partially undone by the requisite manual interventions.
4.Regression Tests for Legacy Systems
Regression tests are, of course, not a challenge that’s specific to legacy telephony. But, as we’ve noted above, legacy interworking is an area where regression tests are particularly crucial to providing high quality of service (QoS) for your subscribers.
Because there are so many layers in which it’s possible for something to go wrong, legacy telephony is often impacted by small network changes in outsize ways, which means that the entire end-to-end suite of legacy testcases needs to be performed each time a change is made.
The trouble here is that manual testing can be extremely time consuming—to say nothing of labor intensive—and when frequent, comprehensive regression tests increase total test loads, high test coverage begins to seem like a pipe dream.
We alluded briefly to the possibility of automation above, but this challenge is in some ways the strongest argument in favor of ditching manual test flows.
More than that, it’s a powerful argument in favor of test automation that’s comprehensive, connected, and readable enough to ensure that tests in different areas (legacy interworking vs. new 5G-readiness updates that might interfere with them, e.g.) are integrated and kept out of silos.
5. Going Beyond End-to-end
For the reasons we’ve discussed above, end-to-end verification flows for legacy telephony testing have historically been difficult to manage by hand. In an automated environment, in which testers don’t have to deal with such a high manual workload.
You can turn your attention to other ways to add value and improve network quality. To that end, some testers in this area are now going beyond end-to-end to incorporate CDRs (call data records) and signalling analyses into their testcases.
By digging deeper into what’s actually happening on a protocol level when a user device is handed over to ISDN, or when someone tries to send a fax on your network, you can improve your test quality noticeably. How?
By offering information that can help engineers find and address the root causes of any failed tests that much more quickly. That said, not all automated workflows are created equal; it’s crucial that testers seek out tools and frameworks that actually go beyond end-to-end in order to gain these benefits.