December 1998

"House Call" Convenience In Testing ISDN Applications

BY JIM GARRETT

Testing ISDN telephones, routers, terminal adapters, and other ISDN applications on site is a tricky proposition. The problem is that traditional testing solutions - null modem cables, inexpensive RS-232 testers, hooking up units back to back - do not work because they are designed for analog communications, not digital. If you have to plug a series of telephones or routers into the office ISDN line sequentially, for example, the phone company may assume it's a bad line and disconnect you. If you are unsure of the required provisioning, such as display text and caller-ID, you have to call the phone company to get a work order and pay for each change of provisioning until you get it right.

The task is even trickier for telecommuters or branch office locations. Remote users are unlikely to know important information about their lines: how to configure the ISDN adapter with the phone numbers, Service Provider IDs (SPIDs), or the type of switching system the local telephone company uses. You need a means of testing and configuring the systems before deploying them in the field.

CENTRAL OFFICE ISDN EMULATORS
The answer is a central office ISDN emulator - essentially a standalone box with two ISDN connections that mimic the telephone company's central office switch. Plug both sides of your equipment into the emulator, and you have an end-to-end connection that replicates live conditions. You avoid going through the telephone switch, your PBX, or a PC-based development system, and you eliminate the variables and problems inherent in testing over telephone lines.

ISDN is built upon a seven-layer model protocol stack, and Layers 1 through 3 are involved in completing a connection with other ISDN equipment. Layer 1 is the physical layer defined by International Telecommunication Union (ITU) I.430. Layer 2 is the data link defined by ITU Q.921. Layer 3 is the network layer, ITU Q.931. Each layer depends on the previous layer(s) to be complete and working. Therefore, the testing process must address all three layers, and this is what a central office emulator allows you to do.

In addition, a central office emulator can speed up installations. Equipment can be pre-installed before the ISDN lines are present, allowing failing or misplaced lines to be identified quickly. Point-of-sale terminals or other equipment destined for large multi-site installations can be pre-tested and pre-set, reducing travel time. Finally, central site maintenance can be performed on ISDN equipment, testing it in all switch protocols before returning it to service.

WHAT YOU'RE TESTING
Testing ISDN falls into two categories: testing the physical line from the telephone company, which is best left to your local carrier; and testing the customer premise equipment, which is what we are concerned about here. Here is a basic guide to installing and testing ISDN equipment with a central office emulator:

1) Obtain the switch type (AT&T, DMS100, or NI-1), directory number (DN), and SPID from the telephone company for the line(s) you are going to use. Enter these settings into the emulator, along with the line provisioning that you have ordered (EKTS, Display Text, caller-ID, etc.). You now have the equivalent of the line from the central office.

2) Enter the DN and SPID for the other line in the emulator. If you haven't already done so, enter the corresponding information into the ISDN equipment.

3) Connect the ISDN equipment to the emulator. Remember that there are two types of interfaces for ISDN equipment: the two-wire U interface, and the four-wire S/T interface. Be sure you are using the interface required by your equipment.

4) As soon as you plug the equipment in, the emulator should give you a green light or a LINE SYNC message indicating a physical layer connection to the telco. This is Layer 1. Since this layer is not affected by mismatched settings between the central office and the ISDN equipment, you can't actually test it. It's either a "go" or a "no go," as indicated by the LED. If the green light doesn't come on, check your connections. If those are okay, the ISDN equipment or the cabling is at fault.

5) If your switch type, DN, and SPIDs have been entered properly, the DN should appear in the emulator's display indicating that both units are now connected to the emulator as if it were the public switched network. This is Layer 2. If the DN appears, it indicates that your DN and SPIDs match, your equipment has been recognized, and each piece of equipment has been assigned a TEI (terminal endpoint identifier). If the DN does not appear, this indicates mismatched settings or an equipment problem.

6) Once any problems with the DN have been resolved, test Layer 3 by having one piece of ISDN equipment call the other. If you complete a successful call, your testing of these units is finished.

If your call is not successful, the protocol trace on your central office emulator will display ITU-T Q.931 Layer 3 Information Elements (IE). These IEs will give a cause code for the termination of the call. If the test involves a call programmed not to connect - a voice call to a data device, for example - the mismatch of bearer capabilities will give a disconnect before any ringing occurs. This can be observed on the protocol trace because a central office emulator with protocol analysis displays both sides of the activity.

Depending on your emulator, decoding will be required to define the problem, or a direct translation from the Hex code to English text will be provided. Then follow the typical call control sequence in your manual or a copy of a good trace that should be included in your emulator software to identify the point of failure in the sequence and make appropriate adjustments to the equipment settings.

IN-LINE PROTOCOL ANALYZERS
There is one final area to be mentioned, and that is the use of a central office ISDN emulator to determine the reason for failure between your ISDN equipment and telephone company lines. You can do this if your emulator is equipped with an in-line protocol analyzer.

Standalone in-line protocol analyzers also perform this function, but they can only show the trace from the ISDN equipment and the telephone company on the side you are using. The other half of the connection is not traceable. This is good for troubleshooting a local loop problem, but not for end-to-end troubleshooting. A central office emulator with an in-line protocol analyzer will allow you to do both.

CONCLUSIONS
Central office ISDN emulators allow you both to determine if your ISDN equipment is defective and if there are faulty connections. In both cases, the key is the availability of trace capabilities that can zero in on whatever problem may be causing a faulty deployment. By testing ISDN applications before going live, you can avoid problems after the fact, eliminating many headaches and freeing yourself to focus on other tasks.

Jim Garrett is the director of engineering of Merge Technologies Group, Inc., a Napa, CA-based developer and manufacturer of ISDN testing, development, and demonstration equipment. For more information, contact the company at 707-252-6686, or visit their Web site at www.mergetech.com.