The primary goal of the switch is to complete a call, but it must also collect information about that call, record it and pass it along in the billing stream so that a provider can collect revenue for services rendered.
In general, the industry standard for revenue leakage reaches 3-15 percent annually (see "Wireless Revenue Assurance," Billing World, November 2000). A lot can slip out during the collections process or get lost in accounting, but much of this leakage begins at the network from the time the call is placed. "While one by one, records off the switch may only be worth pennies," says Glenn Ross, director of Proactive AMA Test (PAT) system development at The Board Room Inc., "en masse, they are extremely valuable."
"The CDR is what drives revenue," says Scott D. Kamenick, manager of technology risk consulting at Arthur Andersen. A company may save millions by checking records at the switch-well worth a CFO's time. Likewise, network operators can learn the importance of testing automatic message accounting (AMA) records, thus realizing that a switch is more than just a means for routing a call.
Taking the Switch Seriously
"If you took somebody from the banking world, and showed them how the telecom operators work-where you've got electronic information in the form of call detail records [CDRs] flowing through a whole series of disparate IT systems, which is effectively money that's moving through those systems-the amount of checks and balances compared to the banking industry is frankly nil," says Grenville Smith, sales manager at Rotadata, a U.K.-based switch verification tool vendor. "So is it any surprise that a lot of these guys are losing money, when they don't actually treat that data that's flying through the system as real cash?"
Most companies are dependent on how the switch writes the record to determine how to bill it. The billing system will determine how to bill from the call code. If the switch is set up incorrectly and it's writing the wrong call codes for the type of call, the call may be completed but not billed properly. In addition, an error may cause the switch not to write a record for a particular call. If a switch is not writing a record, then the billing system has no clue to bill for it.
"If I had a switch, I would rather not complete the call if I'm not writing the record," Ross states. "If I'm not completing the call, somebody is going to complain and inform me that I have a problem, in which case I'll fix both problems-I'll complete the call and I'll write the record." He says that network operators often feel like their job is done if they complete the call-writing the record is regarded as secondary, and in some cases companies don't even test for it.
In the past, the switch was considered the exclusive domain of the network. But in reality the switch serves two purposes: completing calls and recording the detail records as transactions. Even though revenue assurance teams do not work directly on the network, they must understand it and assume responsibility for the switch writing the correct records. That responsibility is often fuzzy, because they don't have the power to make changes to the network. Revenue assurance can only record that something is wrong and see that those changes are made. "The switch is not the exclusive responsibility of the network, although they have exclusive responsibility for maintaining it," Ross points out.
How It Works
Regardless of the tool used during switch verification, the general premise is the same. Test calls are typically used to check the switch's performance. The first step is creating a test call script. While many providers still may determine their test call patterns manually, some tools do this automatically. Others may decide to simulate calls to avoid the expense of actually running test calls.
When a provider uses test calls to check a switch, call scripts are aimed at testing a provider's total functionality. They must encompass all services and challenge the system's ability to rate effectively by targeting all possible rate plans. This might include hitting peak and off-peak hours, as well as positive and negative testing to determine which calls should or should not pass through the switch. While a company wants to hit all possible scenarios, it shouldn't perform too many frivolous calls.
According to Arthur Andersen, creating an effective test script includes understanding the dialing area, tariff structures and translation table structure for applicable switches. Analyzing the tables to determine the translation flow includes determining the different classes of service and the paths the services follow. As well, it includes determining the rate centers, whether rate centers share table entries, whether they are unique and how the call types are routed. This is important in determining the expected result. If there are major upgrades to the switch, or if equipment changes or new services are added, the test call scripts may need to be updated and modified accordingly. Test calls should be performed in a controlled environment; capturing call origination and termination information, call date and actual call time.
Verifying the CDRs is a matter of the provider asking itself what it wants out of the AMA record. First, the provider must match the actual test call to the AMA record. This is done by matching the originating and terminating numbers and the time of the call. Then, the provider must make sure the test call result matches the AMA record produced. This must be done at the switch, in mediation and at the billing system to check the integrity of the records at all points in the billing stream.
Necessary Functionality
According to PriceWaterhouseCoopers' (PWC's) Luke Sayers, partner and leader of PWC's Revenue Maximizer Services for the Americas, a tool must be able to plug into a switch or POTS line. The product must include the capability to make calls based on a test call script; software that can pluck those calls out of mediation when they come through and compare them back to the original test call; and the ability to report on differences between the test call and the expected results.
Ideally, reports must be able to show a summary analysis down to a detailed analysis, to aid both revenue assurance officials as well as network operators who must pinpoint problems at the switch. These reports must be able to display the results in terms that financial executives can also understand. Without reports that can quantify results in a number of ways to pinpoint problems, switch tests carry little value.
A tool with an automated audio capability eases the provider's task of checking such calls as operator-assisted calls or voice mail services. The ability to convert text messages into audio during tests and to save the audio to analyze it later or to automate that analysis is a vital tool. For example, in the case of an operator-assisted call, a product should be able to dial 411, tell the operator that it is a test call, ask to be connected to a particular number and then check to see if that connection worked.
Perhaps most importantly, a switch verification tool must understand the business rules that apply to AMA formats and therefore the kind of records that should be generated, says Andy Engel, president of Engel Consulting. For example, when a call is completed, the verification tool must know whether the call should be recorded as local, local toll or long-distance toll. Each of those calls will have different structure codes.
It must be able to bring in information from the national Local Exchange Routing Guide (LERG) database, maintained by Telcordia, that keeps all information about end offices. As rules change from LATA to LATA, the tool must know whether it must dial 7, 10 or 11 digits, or whether the call should be blocked.
When To Test
Companies should be testing daily, testing experts agree. While operators will not run the gamut of tests on all equipment every day, they should be performing some tests on a part of its network each day. As well, when there are major upgrades or equipment changes, a provider must consider this and fit this into its testing schedule as soon as possible.
"A company should be testing all the time," PWC's Sayers states. "They should have a rigorous monthly test call program whereby they generate test calls over a number of days throughout that month, then take it all the way through the bill, and then look at a number of bill cycles or a dedicated bill cycle for those test calls."
Switch Setups
What most CLECs will do when they first start out, according to Ross at The Board Room, is to put in a single switch that handles multiple rate centers. "There's one CLEC I know of that when they first put a switch in, they had 75 rate centers in a single switch," Ross notes. "In the case of an RBOC, they would have 75 different switches, generally," he says. The setup might consist of "some main switches with remotes acting in the other rate centers, but the model generally is that they would have a separate switch for each rate center."
A CLEC "will have multiple rate centers in the switch, because their customer base may go across multiple rate centers," Ross says. "But they may not have enough volume-enough originating lines for each rate center-to warrant more than a single switch."
"If I'm a CLEC offering service in an area like Chicago," Engel says, "I may literally have dozens of rate centers that I have to emulate. What I need to then be able to do is to go in and test the calls being made-first to provision lines for each of those rate centers, and then I have to generate the test from those lines. Then I have to build tables so that I can look at the anticipated results to make sure that the switch is doing all of the rate center translations correctly."
Ross says that as most such CLECs grow and add more volume, they may put another switch in and divide up the traffic. But initially this makes testing complicated.
Wireless Versus Wireline
Testing for both wireless and wireline networks has its challenges. With wireless, the tests deal with mobility, thus making the call matrix more complicated. In addition, connectivity to landline as well as mobile phones must be tested. An additional variable is whether the calling party pays or both parties pay. Different slices of the spectrum and different types of technology are involved, especially as companies move toward next-generation technologies.
In wireless there is no fixed location, so a line cannot be provisioned to the switch per se, Engel says. "Instead you've got to be able to go to different locations and make wireless calls. Then what you're really doing is ensuring that calls that are being made from different locations are actually getting to the switch and being generated properly."
Dave Adams, director of wireless technology for the air interface group at Acterna, recalls one customer that had performed extensive testing on two separate switches in different cities. The company didn't test the typical occurrence where a call originates in the switch for one city and then moves to another city. It was "just too much trouble," Adams says. "They didn't have the time or the manpower."
Later, the company did employ a portable testing capability to check this scenario, the company looked at its records and made a sobering discovery: for a year, any time somebody had been driving between these two cities and made a call that started in one switch and ended in the other, the system had lost the record and did not bill for it.
"There are certain types of things that you just cannot test in wireless unless you're moving," Adams says.
Wireless service also has a lot more standard features than wireline. "At home I don't buy three-way calling, and most people probably don't," Adams says, "but with wireless ... it's almost an expectation. I conference regularly on my wireless phone, so it's much more important to the wireless provider that that works."
In wireline, the number of different calls a provider tests is generally more extensive than in wireless. While the call matrix on the mobile side may be more challenging, actually launching the process on the landline side might be more difficult, some testers suggest.
Customer Care Benefits
Poor network connectivity can cause an influx of customer complaints, so a provider knows it should test switches if a high level of complaints come into the call center. "There is starting to be a lot of interest, for people who do first- or second-level support for customer care and network operating systems, to have something like this," Adams says. "It wouldn't be the more scheduled, routine running, but it might be more of an interactive, one-time test."
An interactive mode would allow a provider to pick one or more remote boxes and tell one to call the other or to test particular services, or talk to an operator to test the network's functionality.
Too Complex to Ignore
In revenue assurance, Rotadata's Smith says, "clearly test calls are not a universal panacea." There are many other measures, including basic accounting and auditing measures, that need to be implemented later in the process.
But while test calling is not the only means to revenue assurance, it can produce a tremendous cost savings in the end through proving network functionality.
Arthur Andersen's Kamenick says, "The whole industry is just too complex to run perfectly." Because of this, providers must continuously be checking their network's capability. The network people must be able to complete calls, while finance and revenue assurance departments must truly understand the business and revenue implications of the network.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article