Revenue Assurance, as an industry, has always been in a bit of a Catch-22: You’re only great if you find a lot of (otherwise) lost revenue, but your tools and processes aren’t worth much if you keep finding the same kinds of errors year after year. By definition, then, (and much to the chagrin of many an RA consultant) a good RA tool is one that finds less and less as time goes on.

At ATS, we’ve been fortunate to have implemented the most widely used RA tool in North America: SimCall. For 15 years, the tool’s been finding routing and charging errors for virtually all of the big NA carriers. If you’ve used a phone in the last 15 years, there’s a good chance SimCall has “pre-tested” your routing and charging even before you placed the call.

Now, for most of these 15 years, we’ve been asked a question that’s a variant of: “If SimCall is so smart as to know what’s wrong with the switch, how come it can’t correct it?” Granted, the people asking this were never the network engineers or translators. They had seen or read “2001”, and it chilled them to even contemplate a HAL 9000-like computer going into their network and making changes!

But, the notion that SimCall could probably – hopefully! – do more than just find errors after-the-fact persisted, and we’ve finally figured out what that is: Network planning and real-time low-volume, live testing.

First, a word about network planning. Given that SimCall has always had to know almost everything about a carrier’s network (how else to spot an actual/expected discrepancy?), it followed that SimCall might be able to predict what change “X” would have on the network in the future. A simple example, which we’re in the midst of implementing at a carrier right now, is forecasting what a new code opening’s impact will be on the wider network: Which switches will use direct-end-office routing to the new code? Which ones will use a Tandem? Which ones won’t care about the new code because they already route that code’s entire NPA upstream? Which switches will route the codes 6 digits, but will need to be segmented within the switch by Line Class Code or Rate Area? It turns out that our simulator is the right tool to model and forecast these changing conditions, and output the list of transactions that will need to be made on the network.

Having made these changes to the network, one could await the next SimCall run to catch any actual/expected discrepancies. But, we are working with carriers to speed up the feedback-loop that ensures the transactions were correctly implemented. That’s where our “just-in-time-live-check” is useful.

Rather than waiting for a test-call, or even a full SimCall run (overkill if only a few transactions are being checked), we are using carriers’ existing switch connectivity platforms to login and execute commands (traver, vfyofc, etc…) that will verify just the transactions of interest. The output is sent back to SimCall, which can then parse the output and give the transaction a green or red light.

The ‘feedback circuit’ is complete. We’ve moved SimCall out of the “testing arena” alone, and into the network modeling, work assignment and live troubleshooting arenas. It’s far from being HAL but, then again, our customers deserve to have the lights and oxygen left on.