As the number of unique mobile subscribers worldwide grows (that number is now above 5 billion, according to GSMA), the market for roaming services grows with it. On the one hand, increasing demand for roaming services can put you in a position to increase revenue on a per-subscriber basis. At the same time, this growing demand comes with growing expectations—subscribers are no longer content with a dip in quality outside their home network; instead, they expect seamless international voice calling, SMS, mobile broadband, email, and application usage. If you’re not providing this with your own network functionality and interworking with roaming partners, they may seek out a new mobile carrier.
Because the stakes for providing seamless service in this area are potentially pretty high, testing and service verification for roaming is more critical. At the same time, its distributed nature makes it a sophisticated use case to test. It’s simply not practical to send a tester across a national border to perform a suite of roaming regression tests every time you make a change to your network. And yet, without these tests, you run the risk of service outages and disgruntled customers. How are telco operators supposed to cope with a situation like this? The short answer: verify roaming virtually.
How Roaming Works
Okay, before we get into some of the nitty-gritty of what makes this use case challenging to test, let’s sketch out a few key elements about roaming service and how it works: At the simplest possible level, a subscriber outside the range of home network coverage tries to place a call (or use data, send an email, etc.); they connect to the visited operator, which verifies the phone’s registration and identifies its home network; from there, the visited network routes the call to an international transit network (or, in local breakout cases, through the local network), to be picked up by the destination network, which requests additional service information and ostensibly connects the call. At each stage, the appropriate IREG protocols have to be observed, which will vary somewhat depending on whether it’s CAMEL 1, CAMEL 2, or non-CAMEL roaming (i.e., whether or not it’s prepaid).
Naturally, this needs to be verified both inbound and outbound—that is, you need to make sure that your subscribers can access your roaming partners’ network, and vice-versa. This means not only testing functionality from a subscriber phone but also making sure your own HLR/HSS is receiving the right data and provisioning service in the right way when another network connects to yours (for outbound roaming). As mentioned above, to verify all of this functionality by hand, you would necessarily have to send testers out into other countries where your network doesn’t have coverage. In an era where more and more routine use cases are being automated, testers could raise questions about how a use case like this could be incorporated into a test automation solution.
Virtual Roaming Verification
Given the nature of roaming as a service, the most promising approach for incorporating it into an existing automation framework is to verify roaming functionality virtually. When we say “virtually,” we don’t mean that the devices themselves should be simulated within a virtual environment. On the contrary, the more exacting user expectations become—and the more layers of interworking become necessary to providing seamless service—the more critical it is to test on out-of-the-box Android and iOS devices that are identical to those your subscribers will be using. But if we don’t intend the devices to be virtualized, what exactly do we mean?
The roaming itself should be performed virtually, via two separate instances of your test framework or set up in two different countries. Usually, your automated tests would all be carried out via a server based in the confines of your home network. For roaming functionality, you can set up another server outside of that home network to force out-of-network devices to connect via a roaming partner’s network. Here, your home server still performs all of the actual tests, and the same machine generates the test results—but the remote instance enables you to recreate the conditions of a user trying to connect outside of your network. From there, you can test voice calls, SMS, apps, etc. Not only that, but you can do so on a regular basis without devoting inordinate amounts of time to it, since automated test suites should be able to run in a matter of hours at most.
How Roaming Tests Impact Revenue Assurance
Okay, let’s say you’ve incorporated roaming into your suite of automated regression tests. After every network update, you’re using a test flow spread across different instances in two different countries to ensure that users roaming internationally can talk, text, and use data. Mission accomplished, right? Not so fast—there’s one element of the roaming verification equation we haven’t touched on yet: revenue assurance.
We said above that there was more money to be made in the roaming domain than ever, and that’s in large part because subscribers typically pay extra for roaming service based on pre-agreed tariffs. In order to collect the fees associated with roaming (whether from your subscribers or your roaming partners), you have to be sure that you’re recording roaming usage accurately on a per-subscriber basis. For instance, calls and data are associated with the correct user, verified, transferred to the appropriate database in your BSS systems, and reflected on the invoice you send your user. If you underreport and miss network usage, you’ll miss out on revenue. Overreport, and you can expect a disgruntled phone call from your subscriber at the very least. Luckily, this functionality can also be incorporated into robust test automation workflows. The trick is to make sure you’re using a framework that can automate and control your CRM, BSS, HLR/HSS database, and other systems involved in the revenue assurance process. You can perform virtual roaming test calls and measure the results in your back-end systems based on the test parameters.