(Page 1 of 1 in this chapter) Version

Chapter 3

Getting Started

3.1 Introduction
3.2 Modifying the Sample Configuration Files
3.2.1 The TDM Configuration File
3.2.2 The MTP3 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
This section describes the use of the sample configuration files and utilities to perform a simple link "turn up" test: configuring a SS7 link between two TX boards and bringing it up into the "in-service" state through MTP layer 3.

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:  The SS7 link "turn up" test described in this section cannot be run 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:




The sample configuration files shipped on the installation disks assume a single SS7 link running in timeslot 0 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 \tektx\config directory for Windows NT and in the /etc/txn directory on UnixWare and Solaris systems.






3.2.1	 The TDM Configuration File





The sample TDM configuration files under Windows NT are named tdmcp1.txt and tdmcp2.txt (or tdmcp1.cfg and tmdcp2.cfg under UNIX). The sample TDM configuration file for board 1 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 2. Board 2 is configured with the T1s set as Loop Master. This causes board 2 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.




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.2, Configuration Binary File Generation for details.






3.2.2	 The MTP3 Configuration File





The sample MTP3 configuration files are named mtp3cp1.cfg (for board 1) and mtp3cp2.cfg (for board 2). The MTP3 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 MTP3 configuration is described in detail in Section 5.2, The MTP Configuration.



The link 1 definition from the sample MTP3 configuration for board 1 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 MTP3 configuration is if you use V.35 serial links rather TDM links. In this case you must change the link 1 definition from port T1 to port S1. Also you must specify one side of the link (e.g. board 1) as the DCE and the other side of the link (e.g., board 2) 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 TX 2000/TX 3000 Installation 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, 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 copy alarms to (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. It is found in:




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, Natural MicroSystems
Board #1 is a TX2000
Loading:  E.0 TX2000 Kernel (c)1996-1997 Natural MicroSystems, 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 1. An equivalent set of alarms is received from board 2 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 (i.e., 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 MTP3 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 Layer1: 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.




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.












 
    (Page 1 of 1 in this chapter)  Version




 




tech_support@nmss.com



Copyright © 2000, Natural MicroSystems, Inc.   All rights
reserved.