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.
Like most back office processes, provisioning can have a big impact on your ability to send out correct invoices and receive the right payment. Unlike many back office processes, however, provisioning has directly customer-facing elements. This means that any errors that arise have the potential to cause issues for your users. As such, it’s critical that testers in the telecom domain verify proper provisioning any time they update their networks or their subscriber databases. More than that, it’s important for testers to tackle this use case in a time- and resource-efficient manner, so as to uncover errors and address root causes before they become problems. How can testers best accomplish this? We’re glad you asked!
First things first: how does provisioning play out in a typical telco context, and what does that mean for testers? Essentially, the Home Subscriber Server (HSS) combines HLR (Home Location Register) with AuC (Authentication Center) to act as a central database for subscriber information. This means that, in the HSS, each subscriber is paired with identification information (such as a mobile number or an International Mobile Subscriber Identity). The database listing should also include all the relevant data about each subscriber’s service plan, e.g. QoS tiers, maximum bit rates allowed, data caps, allowed traffic, barring etc. In this way, you’re able to keep a record of what any given subscriber can and can’t do on your network.
Based on the relevant QoS tiers and other information, you then provision the appropriate service and service limits to your subscribers. This is where things get tricky for testers. Why? Because you need to find an efficient way to ascertain whether or not the service that’s being provisioned to your subscribers matches the information in your database exactly. This means verifying HLR/VLR interworking, as well as implementing changes in settings in the database in order to test whether those changes are accurately reflected in QoS. If, for instance, you want to verify that you can implement call barring for a given user, you’ll need a mobile phone provisioned with a dummy account and access to the HLR/HSS core network; after making the necessary changes in the database, you’ll need to attempt a call and verify that it can’t be placed. As you can imagine, this kind of workflow quickly becomes time consuming when it’s extended to a large number of potential use cases.
Automated Tested for Provisioning
Though verification for provisioning is crucial for providing the right QoS tiers to your customers, it can be a difficult and time-consuming task when performed by hand. As such, this is an area where automation can add significant value for testers (chiefly in the form of saved time). In order to test this functionality in an automated environment, you’ll need a test automation solution that can control both end-user devices (i.e. out-of-the-box Android and iOS devices) as well as the HLR/HSS database itself via the SOAP (Simple Object Access Protocol) provisioning interface. From there, you can test numerous provisioning use cases with just a few keystrokes (assuming you’re operating in a keyword-based testing environment).
Once this level of automation is in place, it’s easy enough to include provisioning in your regular set of test suites and regression tests. As a result, you’ll be able to suss out issues much more quickly. If, for instance, you try to bar calls for a subscriber—only to find that the account is still able to place MO-calls—you can get the full rundown of what took place during the test in a matter of minutes. From there, you can start working to address the root cause—thereby ensuring that issues of this sort never reach your subscribers.
Protocol Trace Analysis
Naturally, the kind of test automation we described above can tell you a lot simply by providing pass/fail documentation in a timely manner. But what if you wanted to gain an even deeper understanding of what was happening within your provisioning workflows? Well, one of the potential next steps is to go beyond end-to-end and start examining signalling data produced by the transfer of information from the VLR or the IMS. This would, naturally, have to be integrated into your existing automation setup—but a worthwhile test automation solution should empower you to do just that, whether through Wireshark automation or another method.
By using a tool like Wireshark to collect signal traces from the system-under-test, you can begin to gain a deeper understanding of exactly what’s happening on a protocol level whenever you provision a subscriber. Thus, if something unexpected is occurring beneath the surface—even in tests that are technically passing—you’ll get an early warning of potential issues that may be starting to crop up. By contrast, if your tests aren’t passing, it’ll be that much easier to see why. In this way, you’re able to take much more effective control of an area of functionality that can directly impact your subscribers. Thus, you stand to reduce churn and improve overall customer satisfaction—without spending countless hours testing out this functionality by hand.
As a bonus, ensuring that every customer is being provisioned at the correct QoS tier can be a big help in revenue assurance. And since revenue assurance’s impact on a telco operator’s bottom line is fairly straightforward, you have an easy starting point for calculating the ROI potential for automated testing of subscriber provisioning.