It might seem somewhat paradoxical, but the better your LTE coverage gets, the harder it becomes to test something like SRVCC. Verizon, for instance, has about 93% LTE coverage in the United States (according to a recent OpenSignal report),
which means that at most there’s only 7% of the country where a handover from LTE to a 2G/3G circuit switched call bearer network would be appropriate. In all likelihood, that limited geographical area is going to be nowhere near the offices ofany of Verizon’s testing teams.
Which means that testing these handovers manually will require testers to potentially drive for hundreds of miles in search of areas that aren’t covered by their existing VoLTE service.Of course, when you’ve got something like 93% LTE coverage, you might think that your subscribers won’t really care about effective handovers. On some level, of course, you’re right.
The better your LTE service, the less impact poor legacy integration will have on the overall quality of service (QoS) that your subscribers experience on a day to day basis. At the same time, though, it’s the network operators that go above and beyond QoS-wise who have the lowest subscriber churn.
Most subscribers don’t care about SRVCC per se, but they certainly notice and care when their calls get dropped—and they’ll only tolerate a certain number of dropped calls before going elsewhere.
What Is SRVCC?
Okay, let’s back up a step. What, exactly is SRVCC, and how does it play out on your network? Essentially, SRVCC (or Single Radio Voice Call Continuity) is a function within a given network that facilitates a mid-call fallback from a packet-switched voice call to a circuit switched system in order to prevent the user’s call from dropping as he or she moves away from your area of LTE coverage.
Once a user is already in a call, the circuit switched system gets notified by an SRVCC handover indication if the user is, in fact, moving away from the LTE network coverage, makes the decision about whether or not to hand the call over, sets up a radio bearer while the IP call is ongoing, and then performs the handover.
On a protocol level, this functionality is fairly similar to a normal handover, but because it’s a specific function it needs to be tested separately under different conditions.
According to the 3GPP’s guidelines, this process should succeed without letting the call drop 99% of the time, with only .3 seconds of voice interruption.
According to the 3GPP’s guidelines, this process should succeed without letting the call drop 99% of the time, with only .3 seconds of voice interruption.
This obviously presents a real challenge for testers, since small variations in end-user devices, network elements, and other factors can potentially impede smooth functionality.
Thus, regression tests will be required each time you make a change to your core network. Likewise, any time a new mobile device comes onto the market, you’ll need to re-verify this functionality. Given the rate of device fragmentation in the Android market in particular, this can lead to a problematically high test volume.
SRVCC Testing Challenges
Like we pointed out above, increasing device fragmentation and the need for regression tests make this an area that’s prone to high test volumes—but that’s not the primary challenge that testers face when trying to verify SRVCC functionality by hand.
On the contrary, the most difficult part of this test flow is actually finding the areas where the handovers are supposed to occur. As we alluded to in the first section of this post, the more extensive your LTE coverage, the smaller the potential area where the SRVCC function should be activated.
This means that testers in, say, New Jersey, might find themselves driving for hours and hours to escape strong LTE coverage, and then laboriously seeking out the exact spot where the LTE signal is faint enough to force a switch to circuit-switched service.
Only once you’ve found the right location do things like device fragmentation really come into play—because only then can you work through each of the relevant devices that require verification. Then, for each round of regression testing, it’s necessary to take the whole drive once again to re-verify.
At SEGRON, we’ve found that the typical telco engineer can run through about 6-10 test cases per day by hand—but when you add in lengthy drives to and from the testing site on either end of the test case, that number drops off precipitously.
How Test Automation Can Help
Because of the extremely time-consuming nature of manual tests for this use case, the need for automation is more apparent here than almost anywhere else in the telecom domain.
And yet, it also presents a challenge for testing automation solutions: how do you automate verification for a service that only kicks in when a subscriber is on the move? Doing so involves two things first and foremost:
- The ability to automate new devices as soon as they come on the market.
- The ability to simulate a waning LTE signal without leaving the test lab.
The former is important for fighting the tide of device fragmentation. The latter enables you to avoid lengthy drive tests—but how do you make it a reality? One solution is to give your automation solution control of an RF switch matrix. In this way, you can remotely adjust the strength of the signal the device under test is receiving.
Thus, in a keyword-based framework, you would simply call up the relevant keywords for testing SRVCC, and the telecom test automation solution would handle the rest.
It would control a caller and recipient, initiate a VoLTE call, use the attenuator to simulate a waning LTE signal, and then verify that the circuit switched system received an SRVCC handover request, started up a circuit-switched call, and performed the handover as needed.
The whole test should only take a matter of minutes, meaning that performing a round of SRVCC verification for each new device that enters the market becomes a quick and straightforward task.
Likewise, SRVCC can finally be incorporated into your standard suite of network regression tests. The end result is that test engineers have more time to devote to other tests and root cause analysis when tests fail.
