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.
Up to this point, the most common use cases for the IoT have continued to be industrial: tracking pallets as they move through a warehouse, monitoring inventory levels, analyzing machine usage, etc. But with the advent of 5G, consumer applications for this technology are going to become much more prevalent—especially as the speed of over-the-air data transfers become comparable to sending the same information over a wire. To handle this inevitable influx, the 3GPP has been setting standards and protocols for NB-IoT, with a focus on Low Power Applications (LPWA) over licensed spectrum bands.
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.
For the best possible results, your test lab needs to make use of the absolute latest in cutting edge technology. Because this is the arena in which you test changes and additions to your network—including new connected devices like the internet of things (IoT)—you need to find a way to replicate existing network conditions as closely as possible. Otherwise, you might test out new service offerings or network adjustments in a lab setting only to find that your service doesn’t work correctly under real life conditions—which could result in costly delays, outages, and potential subscriber churn.
MVNOs (mobile virtual network operators) sometimes get a bad rap. This isn’t entirely without reason: A recent report found that MVNO download speeds across the U.S. are 23% worse than those of their host networks on average. While download speeds for MVNO often could reach the same heights as their host networks, they tended to offer those speeds less consistently, leading to lower “consistent quality scores” in terms of meeting minimum speeds and staying below allowable levels of jitter, latency, and packet loss.
Let’s say you’re migrating all of your subscribers to a highly redundant HSS database. You know it’s going to be a long process, but you want to set an ambitious deadline and perform the migration before your next quarterly all-hands meeting. As such, you put together a list of the things that are most likely to cause delays. And what should be at the top of that list? Depending on how your current test operations function, service verification could be your prime suspect.
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.
Let’s say you have a small system whose functionality you want to test, and you determine that there are five distinct use cases that require verification. As a technically-adept test engineer with a fair amount of programming skill, what do you do? In all likelihood, you simply script up each test case individually, so that for each use case there’s a unique piece of code that needs to run in order to make sure that everything is working smoothly. This makes sense, and as test automation has become more common (in some sectors, anyway), we've seen a lot more people doing just that. For a limited number of test cases, this is probably the smart thing to do. But what happens when it’s not half a dozen use cases that require scripting, but hundreds or thousands?
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.