(Page 1 of 1 in this chapter) Version

Chapter 4

Verifying the Installation

: 4.1 Introduction
: 4.2 Status Indicator LEDs
: 4.3 Verifying That the Board is Installed Correctly
: 4.4 Verifying That the Board is Working Correctly
: 4.5 Demonstration Programs

4.1 Introduction

This chapter provides procedures to verify that the AG 4000C board is installed and configured correctly.
Before you begin, make sure you have created an AG configuration file (ag.cfg) for your installation, as described in Chapter 3.

4.2 Status Indicator LEDs

The AG 4000C board has three (red, yellow, green) indicators (LEDs) for each trunk on the end bracket of the board. Each indicator is repeated four times for each of the trunks for a total of 12 indicators (LEDs).
The location of the indicators are shown in Figure 20: LED Description Red Indicates loss of frame, loss of signal, or bit error rate. Yellow Indicates remote loss of frame, or remote loss of signaling multiframe. Green Indicates proper frame sync to the trunk: all required framing alignment has been found. This LED will be off if one or more of the following conditions exist: · All ones alarm (AIS) · Loss of frame · Loss of signaling multiframe · CRC errors (when the board is configured for ESF) Hot Swap LED (blue) Illuminated when it is safe to remove the AG 4000C board from the system. The LED illuminates under one of the following conditions: · If the board is fully inserted when the backplane is powered-up, the blue LED momentarily flashes. This is a normal part of the initialization process. · After opening the handles (during the extraction process), the LED illuminates to indicate that it is safe to remove the board. Do not remove the board until the LED illuminates. This occurs only if hot swap software is present. · If the LED remains illuminated during insertion of a board, the board failed to successfully perform its primary hardware initialization. While it is safe to remove the board, this condition indicates a problem. The hot swap operation is defined in the CompactPCI Hot Swap Specification PICMG 2.1 R1.0. Note: When the board is not configured, all trunk indicators are ON. Figure 20. AG 4000C LEDs

LED	Description
Red	Indicates loss of frame, loss of signal, or bit error rate.
Yellow	Indicates remote loss of frame, or remote loss of signaling multiframe.
Green	Indicates proper frame sync to the trunk: all required framing alignment has been found. This LED will be off if one or more of the following conditions exist: · All ones alarm (AIS) · Loss of frame · Loss of signaling multiframe · CRC errors (when the board is configured for ESF)
Hot Swap LED (blue)	Illuminated when it is safe to remove the AG 4000C board from the system. The LED illuminates under one of the following conditions: · If the board is fully inserted when the backplane is powered-up, the blue LED momentarily flashes. This is a normal part of the initialization process. · After opening the handles (during the extraction process), the LED illuminates to indicate that it is safe to remove the board. Do not remove the board until the LED illuminates. This occurs only if hot swap software is present. · If the LED remains illuminated during insertion of a board, the board failed to successfully perform its primary hardware initialization. While it is safe to remove the board, this condition indicates a problem. The hot swap operation is defined in the CompactPCI Hot Swap Specification PICMG 2.1 R1.0.

4.3 Verifying That the Board is Installed Correctly

Create a configuration file (ag.cfg) for your installation by copying an example file and editing it to match your specific configuration. Use the blocate utility to determine the bus and slot number. Refer to Chapter 3 for more information about the configuration file. Refer to Appendix C for more information about the blocate utility. Note: If you have installed the hot swap software, you must use the pciscan utility instead of blocate. For more information about pciscan, refer to the Hot Swap Developer's Manual.
To test the AG 4000C board in a standalone mode before connecting to a live network, set the ClockRef keyword to OSC and set the EnableMVIP keyword to No in the ag.cfg file. In this configuration, the AG 4000C board derives its timing reference from an on-board oscillator.
Use agmon to verify that your AG 4000C board is installed and configured correctly. agmon interprets your AG configuration file and loads the appropriate files to the AG 4000C boards.
For more information on agmon, refer to the AG Runtime Configuration and Developer's Manual.
To run agmon on Windows NT, open a command window and enter: agmon
To run agmon on UnixWare and Solaris: Log in as root (or become the super-user). In a graphical user interface, start a terminal session (shell prompt). Enter: agmon
agmon creates two files in the current directory, ag.rpt and agerror.log.
ag.rpt contains a summary of the board configuration, including names of files which were loaded, and any errors that occurred during loading. You can specify another configuration file using the -f switch.
Errors that occur are displayed in the agmon session and are appended to the error file, agerror.log.
agerror.log contains runtime errors that are not specific to any line or port. You can specify an alternate error file name and path with the -e option to agmon. Note: agmon should be left running at all times so errors will be captured.

4.4 Verifying That the Board is Working Correctly

To verify your board is working, run the digital trunk monitor utility, trunkmon. trunkmon monitors alarms and gathers performance statistics for T1 and E1 trunks. On a T1 trunk, an alarm state is entered upon the presence of Red, Yellow, or Blue alarm. On an E1 trunk, an alarm state is entered upon local or remote loss of frame, or excessive bit errors.
To run trunkmon, enter the following at the command prompt: trunkmon -b<board>
The following is an example trunkmon display: Digital Trunk Monitor Natural MicroSystems Ver 1.0 Sep 21 1998 (Press F3 or ESC to exit) BOARD # 0 ------------------------------------------------------------- Board start time: Wed Sep 21 14:02:46 1998 Trunk 0 Trunk 1 Trunk 2 Trunk 3 ------------------------------------------------------------- Alarm: NO_FRM NO_FRM NONE NONE Remote alarm: NONE NONE NONE NONE Errored seconds: 59 59 21 59 Failed seconds: 56 56 57 57 Code Violations: 0 0 2 7 Slips: 0 0 2 7 Frame sync: No Sgnl No Sgnl OK OK
If no T1/E1 trunk cables are connected to the AG 4000C board, trunkmon shows a loss of frame sync (Frame sync: No Frm) and an alarm state on all trunks. The red alarm LED on the front panel should be lit for all trunks.
If you have configured the board in standalone mode (ClockRef=OSC in the ag.cfg file), connect a cross-over cable between any two trunks of the AG 4000C board. The Frame Sync status should immediately change to OK and the green LEDs for those trunks will light. The remote alarm (yellow) LEDs will light to show that the trunk is indicating an alarm state to the other side. About 15 seconds (for T1 trunks, immediately for E1 trunks) after frame sync has been acquired, both trunks leave the alarm state. trunkmon indicates NONE for the alarm status and the red and yellow alarm LEDs go out. The frame sync (green) LEDs remain lit.
Refer to Appendix C for more information about trunkmon.

`Digital Trunk Monitor Natural MicroSystems Ver 1.0 Sep 21 1998` `(Press F3 or ESC to exit)`
`BOARD # 0 -------------------------------------------------------------` `Board start time: Wed Sep 21 14:02:46 1998`

	`Trunk 0`	`Trunk 1`	`Trunk 2`	`Trunk 3`
`-------------------------------------------------------------`
`Alarm:`	`NO_FRM`	`NO_FRM`	`NONE`	`NONE`
`Remote alarm:`	`NONE`	`NONE`	`NONE`	`NONE`
`Errored seconds:`	`59`	`59`	`21`	`59`
`Failed seconds:`	`56`	`56`	`57`	`57`
`Code Violations:`	`0`	`0`	`2`	`7`
`Slips:`	`0`	`0`	`2`	`7`
`Frame sync:`	`No Sgnl`	`No Sgnl`	`OK`	`OK`

4.5 Demonstration Programs

The following demonstration programs are provided with CT Access and may be used to verify that the AG 4000C board is operating correctly: Program Description ctatest Demonstrates CT Access functions. incta Demonstrates handling inbound calls. outcta Demonstrates establishing outbound calls. prt2prt Demonstrates call transfer from an incoming line to an outgoing line and uses the Switching service to make connections and to send patterns. vceplay Demonstrates using the Voice Message service to play messages in voice files. vcerec Records one or more messages to a voice file. Note: Executables for incta, outcta, and prt2prt are in the respective sub-directories under nms\ctaccess\demos.
Running these demonstration programs requires a connection to either a live T1/E1 trunk or a connection to T1/E1 test equipment which supports call generation and voice path testing. It is also possible to use the T1/E1 cross-over cable to loopback one trunk to another trunk. Calls placed on the first trunk can then be received on the other trunk.
To run these demonstration programs on the AG 4000C board, specify the MVIP-95 stream and slot number of the local DSP resource on which to run the program. If H.110 connectivity is disabled (EnableMVIP=NO), then default switching connections between the on-board DSP resources and T1/E1 trunks are initialized as described in Section 6.5, Default Connections for Standalone Board.
For example, on an AG 4000C T board with EnableMVIP=NO and the DigitalMode=CAS, the DSP resources on stream 16, timeslots 0..23 are connected to the first trunk. Timeslots 24..47 are connected to the second trunk, and so on. To run ctatest on the first channel of the first trunk, enter: ctatest -s0 To run ctatest on the first channel of the second T1 trunk, enter: ctatest -s24
If EnableMVIP=YES, then no default connections are made. Switching connections must be made between DSP resources and T1/E1 trunks using the CT Access Switching service or the swish utility.
Refer to the CT Access Developer's Reference Manual for details on CT Access demonstration programs.

Program	Description
`ctatest`	Demonstrates CT Access functions.
`incta`	Demonstrates handling inbound calls.
`outcta`	Demonstrates establishing outbound calls.
`prt2prt`	Demonstrates call transfer from an incoming line to an outgoing line and uses the Switching service to make connections and to send patterns.
`vceplay`	Demonstrates using the Voice Message service to play messages in voice files.
`vcerec`	Records one or more messages to a voice file.

(Page 1 of 1 in this chapter) Version

tech_support@nmss.com