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.
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.
Mobile banking is not just a fad. By 2020, the U.S. is expected to have more than 160 million mobile banking users, and in the UK mobile banking is already overtaking internet banking in popularity. This could be attributed to a number of factors, from simple convenience to the increasing primacy of mobile phones in general—but whatever the cause, the implication for banking and financial services businesses is pretty clear: you really need a robust mobile application that your subscribers can access on the go.
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.
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.
As the Internet of Things (IoT) grows and expands, the number of different elements that will have to consistently connect to any given network is expanding with it. Of course, some of these elements are more impactful than others. For instance, as of March of 2018, an EU directive requires that all new passenger cars be equipped with an EU eCall system. Because every second can be vital after a serious accident, it’s essential that in case of an accident the eCall device transmits emergency data to the nearest emergency center (PSAP, or “public safety answering point”) and/or trigger an emergency call. This means that in every EU country your network must automatically relay relevant information (e.g. vehicle type, direction, number of passengers, engine type, VIN, GPS coordinates, etc.) from the eCall modem to the correct emergency center in case the driver is too incapacitated to speak.
The pace of technological change has been speeding up at a seemingly unprecedented pace in the 21st century, and in few places is that more evident than in the telecom sector. Just a few short decades have taken us from what would now be considered legacy telephony through 4 generations of broadband cellular networks—with a fifth on the way. In the meantime, things like VoLTE and VoWiFi have become commonplace offerings in your typical telco operator’s portfolio. The race to provide new service offerings and update the functionality of existing ones is underway, and it’s already pretty heated.
Let’s talk about people for a second: by and large, they can’t and shouldn’t work 24 hours a day, seven days a week. They rightly prefer to stick to working hours, and when their jobs call for them to work outside of that time they’re usually provided extra compensation accordingly. On top of that, one human being can really only do one thing at a time (studies show that people are actually really bad at multi-tasking), which means, for instance, they can either be running tests or fixing bugs at any given time—but not both.
In an ideal world, service verification for voice, data, and mobile broadband usage would probably look a lot different than it does right now. Test cycles would be perfectly matched to the timelines for updates, testers would be able to complete tests for the entire range of use cases with time to spare, and any bugs uncovered could be addressed before new updates were rolled out. Unfortunately, that’s not really the world we live in. Instead, we’re stuck with update cycles that are often too short for thorough use case testing, and service verification begins to feel like an unwanted albatross around the neck of any given telco operator.