Raise your hand if a subscriber has ever complained to your company because she wasn’t getting the Quality of Service (QoS) she was paying for. We’re guessing that a lot of readers will have raised their hands. Sometimes, complaints like this arise because of forces beyond the control of the backend offices that actually handle QoS (if the subscriber lives on the border of your LTE coverage, for instance, and simply can’t get a strong enough signal to achieve the level of service she’s paying for), but there are certainly times when these issues arise because of an error in the provisioning process.
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 of any 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.
Often, when we talk about quality of service (QoS) we tend to focus on things like latency, jitter, and packet loss, i.e. the network conditions that users experience in their day-to-day mobile device usage. But back-office processes like provisioning and invoicing can often have just as much of an impact on subscriber happiness in the long term—both because subscribers sometimes have to interact with billing systems and because smoother functioning in the back office often helps network operators to improve service elsewhere. For this reason, savvy telco operations tend to think long and hard about storage and access to subscriber information.
Way back in the day, if you were on the go and needed to make a phone call, you kept your eyes peeled for the nearest payphone. You would drop in your coins and the operator would connect you to your desired call recipient. After the time you paid for had run out, a live operator would butt in and let you know that in order to extend your call you needed to add more money. Today, the idea of something like this happening during a VoLTE call seems a little bit absurd—but in point of fact it represents a need that all telco operators still grapple with: real-time provisioning of services based on what the user has actually paid for.
In the US right now, Verizon and T-Mobile are battling it out for who can provide the most extensive LTE coverage. And as of OpenSignal’s 2018 report, the two were in a statistical tie—each was able to provide an LTE signal 93.7% of the time. These are historic highs for the companies, and objectively impressive numbers, but that still means that they’re failing to provide an LTE signal fully one-twentieth of the time. As such, SRVCC (Single Radio Voice Call Continuity) would still be critical to providing high quality of service (QoS). Why? Because right now it’s the standard solution for ensuring mid-call handovers from all-IP LTE networks to circuit-switched call bearer 2G/3G networks.
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.
We’ve talked a little bit already at this blog about how automated testing is becoming a virtual necessity for telco operators. As increasing device fragmentation and the proliferation of different protocols continue to inflate the number of use cases that require testing, human testers are struggling to keep up. But, if you’re reading this, you probably know all that. More than that, you’re probably almost ready to take the plunge and seriously consider an automated testing solution for your business. The question at this point is, how do you choose the right tool?
In June of last year, The 3rd Generation Partnership Project set the official standards for standalone 5G, effectively paving the way for the era of true 5G functionality. It might be a little bit of an exaggeration to say that we’re now experiencing a race to create usable 5G networks and devices among the wireless carriers and device manufacturers of the world (Apple, for instance, has been forthright about its decision to wait until 2020 to roll out its first 5G-enabled smartphone), but the floodgates are certainly beginning to open—and carriers like Verizon and AT&T are already performing a limited rollout of 5G home and mobile networks. In Europe, a leading operator in the 5G space has already announced its support for the OPPO Reno 5G.
In 2012, an OpenSignal study found that there were about 4,000 different Android device models on the market. Within a couple of years, that number had risen to 12,000, and it’s likely only gone up since then. As a device tester, you already know that there’s considerable diversity among your customers, and that their needs are going to vary on a case-by-case basis—but who knew there was so much diversity just in the devices themselves?