3.1 Introduction

3.2 Modifying the Sample Configuration Files

3.2.1 The TDM Configuration File

3.2.2 The MTP 3 Configuration File

3.3 Starting the txalarm Utility

3.4 Downloading the Boards With ss7load

3.5 Monitoring Link Status Through txalarm

3.6 Troubleshooting Link Problems Through txalarm

3.1 Introduction

The sample configuration files shipped with each of the SS7 software packages are set up to illustrate a simple SS7 configuration between two TX boards in a single PC chassis, connected by a single SS7 link, as illustrated in Figure 1:

Figure 1. Sample SS7 Test Setup

Note: You cannot run the SS7 link test described in this section by looping back two ports on a single TX board. A minimum of two TX boards, or one board and a separate piece of SS7 test equipment capable of emulating an SS7 node up through MTP layer 3, are required.

Depending on the physical hardware configuration of your TX boards, the physical SS7 link interface between the boards may be one of the following interface types:

• A single timeslot on one of the T1/E1 ports (requires TX Dual-T1 or Dual- E1 daughterboard or rear I/O transition board)

• A single timeslot on the MVIP/H.100/H.110 bus

• A V.35 serial link (requires TX V.35 serial daughterboard or rear I/O transition board)

The sample configuration files shipped on the installation media assume a single SS7 link running in timeslot zero on T1 port A. If you use E1 rather than T1, or the MVIP/H.100/H.110 bus or V.35 serial links, you will have to make changes to the sample configuration files.

Once the appropriate physical connections are completed, the following steps are used to bring the link into service:

1. Make any necessary changes to the TDM and MTP3 configuration files.

2. Start the txalarm utility on your host PC to monitor the status of the links.

3. Download both boards using the ss7load download script.

4. Check the txalarm output to see that the link comes into service on both boards.

5. Troubleshoot any problems indicated in the txalarm output.

These steps are described in the following sections.

3.2 Modifying the Sample Configuration Files

If your hardware configuration does not match the configuration assumed by the sample configuration files, you'll have to modify the samples to get the SS7 link up and running.

All sample configuration files are found in the \nms\tx\config\ directory for Windows NT/Windows 2000 and in the /opt/nmstx/etc directory on UNIX systems.

3.2.1 The TDM Configuration File

The sample TDM configuration files under Windows NT/Windows 2000 are named tdmcp1.txt and tdmcp2.txt (or tdmcp1.cfg and tmdcp2.cfg under UNIX). The sample TDM configuration file for board one is shown here:

     CLOCK            NETA
     SEC8K            NONE
     # T1    Framing   Encoding   Buildout   Robbed Bit   Loop Master
     # --    -------   --------   --------   ----------   -----------
       T1A     ESF       B8ZS         0        FALSE         FALSE
       T1B     ESF       B8ZS         0        FALSE         FALSE
     #
     #    Port         Stream          Channel      Count   Direction
     # -----------   -----------    -------------   -----   ---------
         Port1           T1A           Channel0     Count1   Standard
     
     

The sample TDM configuration file presents a simple example of the most common type of TX board use. When a single TX board is present in a chassis, the tdmcp1.txt file can be used to configure a board with a Dual T1 daughterboard or rear I/O transition board. This configuration specifies CLOCK NETA, indicating the clock recovered from T1A should be presented onto the MVIP/H.100/H.110 bus. When two TX boards are present in a chassis, tdmcp2.txt can be used to configure board two. Board two is configured with the T1s set as Loop Master. This causes board two to use its internal oscillator as the clock source for both T1s. This board is also configured with CLOCK BUS, indicating the TDM clock should be taken from the MVIP/H.100/H.110 bus. These configuration files will require various changes to be made when the boards are being loaded for purposes other than initial testing.

The following list provides some common TDM configuration changes required for different hardware configurations. For more details on the content of the TDM configuration file, and how to compile it for use by the TX board kernel, see Chapter 4.

• If you use the V.35 serial interface rather than TDM ports, you do not need to modify the TDM configuration, as it won't be used. You do, however, need to change the SS7 link definition in the MTP 3 configuration file. See Section 3.2.2, The MTP 3 Configuration File for more information.

• The sample TDM configuration assumes T1 ports. If you are using the E1 interface instead, you must change the T1 parameters line to reflect proper E1 parameters and you must change the channel timeslot number assigned as Port1 to a timeslot other than zero (timeslot zero is used solely for framing on E1 ports and cannot be used to transport data such as SS7).

• The sample configuration files contain commented out sections that define other types of TDM connections. Examples of connections over E1, MVIP, and H.100/H.110 are included.

• Clocking control may also need to be modified base on the specific environment. The example for CP #1 assumes to be receiving clock from T1A. This implies that T1A is connected to another T1 device that is acting as Loop Master. The example for CP #2 causes that CP to act as the Loop Master for both T1 interfaces. If this is not the desired clocking configuration then the CLOCK and/or Loop Master fields should be modified.

Once the TDM configuration file has been modified, it must be compiled into a binary image with the tdmcfg utility before downloading the board. See Section 4.3, Configuration Binary File Generation for details.

3.2.2 The MTP 3 Configuration File

The sample MTP 3 configuration files are named mtp3cp1.cfg (for board one) and mtp3cp2.cfg (for board two). The MTP 3 configuration file is a longer file, containing definitions of many of the attributes of the SS7 MTP layers: general attributes, link definitions, link set definitions, and route definitions. The MTP 3 configuration is described in detail in Section 5.2, The MTP Configuration.

The link one definition from the sample MTP3 configuration for board one is shown below:

#Link Parameters
#---------------
LINK              T1     # T<n> for T1/E1/MVIP, S<n> for serial (V.35)
LINK_SET          1
ADJACENT_DPC      1.1.2  # Board 2
LINK_SLC          0
MAX_CREDIT        127
MESSAGE_SIZE      272
#
# Level 2 parameters
#
LSSU_LEN          2
END

For this test, the only change that should be necessary to the MTP 3 configuration is if you use V.35 serial links rather TDM links. In this case you must change the link one definition from port T1 to port S1. Also you must specify one side of the link (board one) as the DCE and the other side of the link (board two) as the DTE. Make sure that the link configured as the DCE also has its V.35 POD port strapped for DCE operation. Likewise, the link configured as the DTE must have its V.35 pod port strapped for DTE operation. See the appropriate hardware manual for details on configuring the V.35 pod.

3.3 Starting the txalarm Utility

The txalarm utility captures alarm messages from the boards, displays them on the screen, and optionally saves them to a disk file. It is the primary tool for monitoring what is happening on the link as you download the board and try to bring the link up.

The txalarm utility is best run from a separate window ("DOS window" in Windows NT/Windows 2000, or a "command window" when using a UNIX desktop-style user interface. It is run with the command:

txalarm [-f filename]

where the -f option, if present, specifies the file to which alarms are copied (in addition to displaying them).

The output from txalarm looks similar to this:

<01/07/1998 16:17:04>	mtp	1	18180	MTP3 Link 1 Down
Timestamp	Task	Board Number	Alarm Number	Alarm Text

3.4 Downloading the Boards With ss7load

Once the configuration files are set and the txalarm utility is running, the TX boards can be downloaded with the software and configuration. The ss7load download script file is included to perform this action.

The ss7load script contains all the commands required to download the necessary software and configuration files to the TX boards. This script is resides in the following locations:

Operating System	Directory Location
Windows NT and Windows 2000	\nms\tx\bin\ss7load.bat
UNIX	//opt/nmstx/bin/ss7load

At installation time, the ss7load script contains commands to download and configure all the SS7 layers. Only the MTP layer is activated, however; the others are "commented out". To enable any optional SS7 layers you have installed you must edit ss7load and remove the comment symbols from the desired layers.

Note: Superuser permissions are required to edit the ss7load file on UNIX systems.

ss7load expects a single parameter on the command line: the board number. For the two-board test described here, the sequence would look something like this (user input is shown in bold type):

prompt> ss7load 1
CPMODEL V1.0: Copyright 1998, NMS Communicationss
Board #1 is a TX2000
Loading:  E.0 TX2000 Kernel (c)1996-1997 NMS Communicationss, Inc. 2/10/97
Loading: diag2000    Version C.1.0 12/10/97
Loading:            
Loading: inf         Version C.4.0 12/10/97
Loading: mvip        Version A.1.0 12/10/97
Loading: t1e1mgr     Version A.1.0 12/10/97
Loading: mtp         Version B.3.0 01/14/98
mtp2cfg: sample MTP2 configuration application version B.1.0 Jan 14 1998
mtp3cfg: sample MTP3 configuration application version B.3.0 Jan 14 1998
prompt> ss7load 2

The following is output from txalarm when ss7load is executed for board one. An equivalent set of alarms is received from board two when it is downloaded.

<12/05/1997 15:51:58> mtp 1   1 Registering MTP Layer 2
<12/05/1997 15:51:58> mtp 1   1 Registering MTP Layer 3
<12/05/1997 15:51:58> mtp 1   1 Configuring MTP Layer 1
<12/05/1997 15:51:58> mtp 1   1 MTP1 Initializing.
<12/05/1997 15:51:58> mtp 1   1 MTP1 General Configuration
<12/05/1997 15:51:58> mtp 1   1 MTP1 Configuring link 0: TDM, External
<12/05/1997 15:51:58> mtp 1   1 MTP1 Configuring link 1: TDM, External
<12/05/1997 15:51:58> mtp 1   1 MTP1 Configuring link 2: TDM, External
<12/05/1997 15:51:58> mtp 1   1 MTP1 Configuring link 3: TDM, External
<12/05/1997 15:51:58> mtp 1   1 MTP1 Configuration Done
<12/05/1997 15:51:58> mtp 1   1 Configuring MTP Layer 2
<12/05/1997 15:51:58> mtp 1   1 MTP2: General Configuration
<12/05/1997 15:51:58> mtp 1   1 MTP2: Link 0 Configuration
<12/05/1997 15:51:58> mtp 1   1 MTP2: Link 1 Configuration
<12/05/1997 15:51:58> mtp 1   1 MTP2: Link 2 Configuration
<12/05/1997 15:51:58> mtp 1   1 MTP2: Link 3 Configuration
<12/05/1997 15:51:58> mtp 1   1 MTP3: Ready

3.5 Monitoring Link Status Through txalarm

Once the boards have been downloaded, they will repeatedly attempt to align the links (bring up through layer 2). Once link alignment has been achieved by MTP layer 2, MTP layer 3 will attempt to bring the links into service through an exchange of signaling link test messages (SLTMs) with its peer MTP 3 on the other board. Once this signaling link test is successfully completed, an alarm is generated from each board indicating that the link is up (in service). A typical alarm sequence for successful link startup looks like this:

<01/09/1998 09:54:21> mtp  1  1 Flushing Buffers (OPC=0) 
<01/09/1998 09:54:21> mtp  1  1 Starting Alignment
<01/09/1998 09:54:21> mtp  1  1 IAC Rx SIO
<01/09/1998 09:54:21> mtp  1  1 IAC Rx SIO
<01/09/1998 09:54:21> mtp  1  1 Rx SIE (9)
<01/09/1998 09:54:22> mtp  1  1 ALIGN TIMER 4 EXPIRED (Link Aligned)
<01/09/1998 09:54:22> mtp  1  1 Setting link 0 ACTIVE in SigLinkAvail
<01/09/1998 09:54:22> mtp  1  1 DPC 0.1.2 is now ACCESSABLE (LinkSet 1)
<01/09/1998 09:54:22> mtp  1  1 Setting link 0 ACTIVE in TrafLinkAvail
<01/09/1998 09:54:22> mtp  1  1 Setting link 0 ACTIVE from SLTA
<01/09/1998 09:54:22> mtp  1  1 8179 MTP3 Link 0 Up
<01/09/1998 09:54:21> mtp  2  1 Flushing Buffers (OPC=0) 
<01/09/1998 09:54:21> mtp  2  1 Starting Alignment
<01/09/1998 09:54:21> mtp  2  1 IAC Rx SIO
<01/09/1998 09:54:21> mtp  2  1 IAC Rx SIO
<01/09/1998 09:54:21> mtp  2  1 Rx SIE (9)
<01/09/1998 09:54:22> mtp  2  1 ALIGN TIMER 4 EXPIRED (Link Aligned)
<01/09/1998 09:54:22> mtp  2  1 Setting link 0 ACTIVE in SigLinkAvail
<01/09/1998 09:54:22> mtp  2  1 DPC 0.1.2 is now ACCESSABLE (LinkSet 1)
<01/09/1998 09:54:22> mtp  2  1 Setting link 0 ACTIVE in TrafLinkAvail
<01/09/1998 09:54:22> mtp  2  1 Setting link 0 ACTIVE from SLTA
<01/09/1998 09:54:22> mtp  2  1 8179 MTP3 Link 0 Up

3.6 Troubleshooting Link Problems Through txalarm

If the link does not come into service shortly after being downloaded, the cause of the problem may frequently be determined from the txalarm output. The primary cause of link initialization failures are physical connection problems. Physical connection problems are usually indicated by a repeated sequence of alarms indicating that Align Timer 2 Expired and Alignment not possible as shown in the following example:

<01/09/1998 09:49:58> mtp  2  1 Starting Alignment
<01/09/1998 09:49:58> mtp  2  1 Layer 1: AERM Threshold Reached
<01/09/1998 09:49:58> mtp  2  1 Alignment Aborting
<01/09/1998 09:50:10> mtp  2  1 ALIGN TIMER 2 EXPIRED, QLen=0 iacSt=8
<01/09/1998 09:50:10> mtp  2  1 LinkFailure : Alignment Not Possible
<01/09/1998 09:50:10> mtp  2  1 Flushing Buffers (OPC=0)
<01/09/1998 09:50:11> mtp  2  1 8180 MTP3 Link 0 Down

There are many possible causes of physical link connection problems. The following list illustrates a few of the possible causes.

• Missing or loose cable connections between the T1/E1 ports.

• Missing bus cable when one board is deriving clocking from the MVIP/H.100/H.110 bus.

• Incorrect clocking configuration between the two boards (both boards driving MVIP/H.100/H.110 bus clocks, neither driving MVIP/H.100/H.110 bus clocks, clocking not synchronized to T1/E1 port).

• Mismatched channel timeslot assignments between the two boards.

• Missing or loose cable connections between the boards and V.35 pods or between the two V.35 pods.

• Incorrect V.35 DCE/DTE configuration: both boards configured as DTE (the default), DCE side of link plugged into V.35 pod strapped for DTE operation or vice versa.

The link may also align successfully at layer 2 but fail the signaling link test at layer 3. This results in an alarm indicating that Align Timer 4 Expired (Link Aligned) followed by an MTP alarm indicating that the link is down, as shown in the following example:

<01/09/1998 09:54:21> mtp  1  1 Starting Alignment
<01/09/1998 09:54:21> mtp  1  1 IAC Rx SIO
<01/09/1998 09:54:21> mtp  1  1 IAC Rx SIO
<01/09/1998 09:54:21> mtp  1  1 Rx SIE (9)
<01/09/1998 09:54:22> mtp  1  1 ALIGN TIMER 4 EXPIRED (Link Aligned)
<01/09/1998 09:54:22> mtp  1  1 8180 MTP3 Link 0 Down

This failure is almost always caused by one of two configuration errors.

• The point codes assigned to each of the boards in the MTP 3 configuration file do not properly refer to each other.

• The link select code assigned to the link in the MTP 3 configuration file (LINK_SLC) of one board does not exactly match the link select code assigned to the same link in the MTP 3 configuration file of the second board.