Home | ARONTS | ARONTS Instruction Manual |

In a competitive environment, the Interexchange Carrier (IXC) is completely dependent upon the Local Exchange Carrier (LEC), or Telephone Company (Telco). All customers must originate their telephone calls through the Telco; it is the Telco's responsibility to pass the calls through to the proper IXC's network. If the call is blocked, the customer may simply select a different IXC; if the call is mistakenly sent to a competitor IXC, the customer probably does not even know this has occurred until the telephone bill arrives a month later. In either case, call revenue is lost. It is therefore important for the IXC to verify that the Telcos are in fact routing all appropriate traffic to his network.

In many situations, it is the Telco's tandem or end office switch which makes the decision as to how to route the outgoing call. For these cases, in order for the IXC to verify that all calls are being transferred properly, test calls need to be made from locations which traverse each decision point. This may require testing through every tandem switch, or in the worst case, every end office. Past experience has shown that even when a network tests correctly, it is not unlikely that in future weeks or months that the database is corrupted, causing known good points to become faulty. The distributed routing process becomes a moving target. A complete test plan for an IXC must regressively go back and test all decision points regularly to maintain an accurate observation as to the network's health.

First, a determination must be made as to how the Telco makes its decision to route calls to IXC's. Is there a regional controlling database? Are the tandems programmed individually? Do the end offices work autonomously? The answer informs as to how many origination points are necessary for a test plan to cover an area completely. For the purpose of discussion, assume that routing decisions are made at the tandem switch, and that there are 45 such tandem switches in the region of interest.

Test calls must be originated from end offices which are connected to each of the 45 tandems. An RTS-2 Remote Test Set is installed at convenient locations: either in the Central Office (CO) itself, should this be accessible; in IXC sales offices located in the area; or in a closet rented in any business in the proper location. Each of these RTS-2 units is connected to two standard Plain Old Telephone Service (POTS) 2-wire analog telephone lines provided by the Telco. These are exactly the same types of lines secured by the IXC's customers from the Telco. There is nothing different about these lines than any other customer line, and the programming in the Telco's switching system is one and the same as for any other customer lines in the CO's area.

One of the two phone lines on each RTS-2 is used to access the device; the other is used to make outgoing test calls. The two lines are connected via standard RJ-11 modular cords and jacks. The units are powered from the standard AC power receptacle. The RTS-2 may be wall-mounted on a standard plywood board, or be deskmounted on any flat surface. In this example, deploying 45 RTS-2's gives the IXC the capability to originate test calls through each of the Telco tandems, and therefore all routing decision points. It gives the IXC controllability and observability -- controllability, because the IXC then has the ability to force a test call through any point of the network whenever desired -- and observability, because the IXC then can observe the outcome of the test call.

In order to determine that test calls are not being placed by the Telco through an alternate IXC, the IXC must provide some test number or numbers which are handled differently by it than other IXC's. The simplest method is to route all calls terminating to a specific test number to an internal 1004 Hz milliwatt tone. If this terminating number is received by any other IXC, an intercept message, reorder signal, or other similar output results. With this method, only calls made to this test number through the IXC return a milliwatt tone.

It may be necessary to obtain one or more local numbers which terminate in equipment owned by the IXC to provide an actual line appearance for the test number. The terminating equipment is programmed to route calls to a DTMF splashback or SIT (Special Information Tone) recording. In this way, any calls to this test (terminating) number placed through other IXC's are processed normally, and do not return the milliwatt. However, calls handled through the IXC to this terminating number are rerouted to another number which does return the milliwatt.

One method is for the IXC to program its switch database so that any calls with an ANI (originating number) of RTS telephone line #2 are automatically routed to an internal milliwatt tone. If this is not directly possible, then those callse can be forwarded to a different terminating number. Additional RTS-2's can be used as terminating responders, and programmed as follows: calls arriving on line #2 answer with a milliwatt (successful) tone; and calls arriving on line #3 answer with a fixed DTMF sequence. The dialed (test) number would be that of line #3. Calls coming into the IXC network with that destination number (line #3) should be redirected to the number on line #2. This way, if the call is handled in the traditional manner (but not through the IXC), the call will terminate in a DTMF sequence which will be logged by ARONTS as a failed call, and it will be known that it was actually routed through some other network; if the call is properly routed through the IXC, it will be rerouted to line #2, receive a milliwatt, and be logged by ARONTS as a successful call; and if the network fails to deliver the call for any of a number of reasons, the call disposition will be logged by ARONTS accordingly (timeout, SIT, reorder, etc.).

With the above scenario in place, the IXC has the ability to place test calls to the special test number through each of the decision points of the various Telcos' networks. Calls properly transferred to the IXC respond with the milliwatt tone, and calls improperly transferred to another IXC, or not routed to any IXC, do not return the milliwatt signal. All that remains to be done is to regularly exercise the network by placing calls through each RTS-2 to the test number, and record the success or failure of each test.

Calls through a single RTS-2 are initiated in the following manner: the access number of the RTS-2 is dialed; the RTS-2 answers the incoming call on the first line, and provides a prompt tone; the secret RTS-2 test (authorization) code is DTMF dialed; the RTS-2 acknowledges the access with a prompt tone; a DTMF command sequence is sent which asks the RTS-2 to take the second (outgoing) line off-hook, wait for dialtone, and dial the IXC access code and test number (with either DTMF or rotary pulse signaling); and the RTS-2 does as ordered. The call is either routed through the IXC and returns a milliwatt, or is not and does not return a milliwatt. Upon completion, a DTMF exit code is sent to the RTS-2, which hangs up the outgoing line. Another test call may be placed if desired. When finished, a hangup DTMF code is sent to the RTS-2 and it hangs up the incoming line.

These test calls may be manually placed to test known problem areas, but a regular repetitive process is preferable. A centralized piece of equipment, the Automated Remote Origination Network Test System (ARONTS), is used to handle all test call processing automatically. It may be located anywhere with access to the telephone network. ARONTS is controlled by a standard personal computer (PC) with integrated menu-driven software. The access (incoming telephone line) numbers of each RTS-2 and their test codes are entered into ARONTS' database. Detailed instructions as to how to dial the test number from each RTS-2 location are programmed into the configuration. When commanded, ARONTS automatically: dials each RTS-2 unit; goes through the access process; commands the RTS-2 to dial the test number(s); listens for the call disposition; logs internally whether the call is a success or a failure; disconnects the outgoing test call; and disconnects from the RTS-2 device.

The built-in reports show the call failures, from which trouble reports are generated. When the Telco reports back to the IXC that the problem has been corrected, the test may immediately be remade (either manually or through ARONTS) to determine the accuracy of the claim.

The above test plan is geared towards detecting fixed programming, or translation and routing, errors. Two other types of problems may occur, and tests made for their detection: insufficient resources, i.e. trunk lines connecting the Telco and IXC switches; and switching times.

Insufficient Resources. The Telco's programming may be correct, but more customers in an area attempt to access the IXC's network at the same time than can be accommodated. Usually this results in a reorder tone, or an "all circuits busy" intercept message. This can be detected by sampling methods. With enough test calls placed during busy hour, a percentage of the test calls will not terminate properly. ARONTS can be programmed to place calls during busy hour; congested areas are detected by an unacceptably large percentage of blocked calls. This test is made exactly the same as the customer places calls, so it tests all aspects of the network. Such blocked calls should be searched in the IXC's call database to determine in fact if the call was blocked by the Telco or in the IXC network itself. In either case, it results in lost revenue and should be corrected. This type of problem is dynamic in that the number of resources required in an area changes as more customers choose the IXC.

Switching Times. The Telco should not show a preference between the various IXC's. It should deliver the call within an appropriate time no matter which one is selected. ARONTS measures the post dial delay, from the last digit dialed into the Telco's switch to when the milliwatt signal is first returned. This measurement is recorded in the test call detail, and summarized by site (RTS-2) and test (terminating) number with the average and standard deviation for successful calls in each category. As a check, ARONTS may be programmed to place calls to other milliwatt numbers through competitor IXC's, and the post dial delays for these carriers compared to the IXC's. These measurements consist of the total call delay: part is due to the Telco's switching time, and part is due to the IXC's own network delay. Competitive statistics may be determined in this way to check on the quality of service presented to the customer.

ARONTS is available in sizes from 2 through 48 ports. The programming is identical no matter what the port size. The number of ports only affects the overall amount of time required to complete a test run. Each port can be connected to one remote RTS-2, so that multiple tests are conducted simultaneously. For the case of 45 RTS-2 units, a 48-port ARONTS permits every remote unit to be accessed, and test calls placed, simultaneously. For the case of busy hour testing, assuming approximately 30 seconds for each test call, a 48-port ARONTS would permit about 120 test calls be placed in a single hour at each of the 45 RTS-2's, a total of 5400 tests. A smaller-sized ARONTS accesses the RTS-2's in chunks until all are accessed. With a 2-port ARONTS, for example, during busy hour each remote site could be programmed for 4 test calls. This would require about 2.5 minutes per site (including an additional 30 seconds for access and authorization); therefore, all 45 sites would complete testing in just less than one hour, providing a total of 180 tests.

Speed is less of an issue for detecting fixed routing problems. To place a single test call through each RTS-2 takes approximately a minute, for access and authorization plus the test call and RTS-2 release. A 2-port ARONTS can then test two sites per minute, resulting in all 45 sites being covered in about 23 minutes. Of course, a 48-port ARONTS could do the same thing in one minute. All of these figures assume properly functioning telephone lines and switching. Test call failures generally add time to the test process.

The IXC chooses ARONTS port size according to its expected uses and requirements. If a large size is selected, a smaller unit may also be desired. This one is typically used to troubleshoot specific problems which arise, and work out test plans before turning them over to the production high-volume unit. It may also be used as a backup for the main ARONTS.

Once the RTS-2 units are deployed, programmed, tested, and ARONTS is programmed for the regular tests desired, little time is required to operate the equipment. The system can be programmed to automatically run different test jobs based on time-of-day and day-of-week. To initiate a test manually, a few keystrokes are all that is required. It is necessary to analyze the reports generated, make trouble reports to the appropriate Telco, and follow up on the complaint. These activities typically take less than one full-time person. The initial setup requires time to supervise RTS-2 installation, programming, and testing, and ARONTS familiarity and test plan setup. However, the test plan for the IXC scenario is much simpler than for local Telcos, and is not difficult. The network programming to handle the milliwatt tones must be performed initially. Naturally, this is all dependent upon the quantity of Telco decision points and the size of the IXC's network.

If in fact it turns out that covering all routing decision points in the IXC's territory requires hundreds or thousands of RTS-2's, then most likely these should be deployed in stages which first cover the major population centers, until an acceptable coverage percentage is achieved.