Backward compatibility is a noble goal for any communication system. For telecom networks in particular, it’s an important part of providing seamless coverage across legacy platforms, which means you can keep customers happy without forcing them to upgrade their service constantly.
By placing an emphasis on service in this way, you can help protect revenue over time. That said, ensuring legacy integration can often provide challenges for operators. In 1998, for instance, the CCITT set their standards for ISDN (Integrated Services Digital Network), an early set of protocols for transporting voice and data over classic, circuit-switched telephone networks.
The standard, which improved upon existing voice quality norms by sending digital signals over copper telephone wires, made things like video conferencing seem less farfetched than previously, and offered something of a precursor to modern voice and data networks.
That said, it was not embraced universally. In the US it was supplanted by widespread broadband adoption before it ever really gained traction, leading people to joke that ISDN stood for “It Still Does Nothing.”
While reception in the US was lukewarm, ISDN service was a huge hit in Germany. Nearly a third of subscriber lines in Germany were ISDN lines, accounting for about a fifth of all the ISDN lines worldwide.
Naturally, with the rise of VoIP and SIP these lines have become less popular, with most service providers in the region working to phase them out within the next few years—but plenty of them are still in operation as of 2019.
What does this mean for European telco operators? For the time being, you still need to provide interworking with ISDN and other forms of legacy telephony, or else risk stoking customers’ ire when they can’t connect to the services they’re paying for.
Why Interworking Verification Matters
Naturally, ISDN is just one example of a legacy system that requires interworking even in modern telco environments. More frequently, you’re likely to encounter POTS (plain old telephone service) supported by PSTN (public switched telephone network).
But the end result of the lingering presence of these systems is the same: you need to verify that the devices on your network can connect to these other systems as needed.
If a mobile user is trying to exchange data with a business that relies on legacy telephony, they’re not going to give their network operator a free pass when their voice or video service cuts out.
From an operational perspective, the burden for ensuring this kind of service essentially falls to testers. If you’re performing service verification tests following a network migration, you need to know that devices connected to your network are stable capable of being handed over to a legacy system when exchanging data with other devices as needed.
By the same token, any time you roll out a new service offering, it has to be compatible with everything still in use that has come before, which means scripting up test cases that involve interworking between your network and legacy networks and incorporating those test cases into your standard testing suite.
As 5G is rolled out, interoperability with earlier technology will have a crucial impact on its adoption rates. By integrating legacy technology with 5G, operators can gain a real technical advantage, all while managing system upgrades and technology transitions more easily and effectively.
How to Ensure Proper Handovers
Okay, at this point you might be thinking, “That’s all well and good, but how do I actually verify that my service is being properly converted to legacy protocols as needed?”
For starters, with an analog modem, you can simulate POTS, fax, and other services to create the necessary test conditions to cover all of the various potential protocol combinations. (For ISDN in particular you may need some additional test equipment, like a DSL router and network terminals with BP/PR interfaces).
If you’re automating your tests, you should be able to control these devices remotely, pulling in the appropriate test cases from your test library in order to achieve a high level of test coverage as quickly and efficiently as possible.
In an ideal situation, you’re also identifying speech paths between the different endpoints in order to be even more certain of a high quality of service (QoS) for your end users.
How Often Do You Need to Test Interworking?
You may have noticed in the paragraph above that we casually alluded to the possibility of automating your interworking tests. But the schema we sketched out above for legacy service verification doesn’t seem to add much complexity on top of the usual set of service verification tasks.
So why would telco operators make automation a priority? The answer to this (entirely reasonable) question is related to the answer to another question: how often should you verify service for this use case?
The answer is: as often as possible. Why? Because small changes in network parameters—the kinds of small changes that happen all the time because of normal network usage—can have a big impact. For instance:
- Buffers getting full and fragmented but not released in a correct order
- IP and signaling being rerouted
- Router parameters changing due to changes in capacity needs
- Adding new interfaces
- Increasing mobility
- Adding new IoT equipment into networks
- New MVNO agreements being made
- Introducing new technology like 5G
Any of these might impact your ability to interwork with legacy systems. And, needless to say, these kinds of small changes occur regularly enough that legacy interworking really needs to be performed on an ongoing basis, with frequent regression tests.
Unfortunately, this potentially means a tremendous test volume—much more than a lone engineer could be expected to handle manually. Rather than throw your hands up and resign yourself and your network to a life of poor QoS, you can automate testing and instantly increase the number of tests that can be run each day by a factor of 10.
LEARN MORE ABOUT TEST AUTOMATION
Are you looking for a solution to automate your service verification that includes both true end-to-end testing and full access to the systems under test?