TL1 Responder

Summary of Features

  • Permits T/MonXM and IAM's to respond TL1
  • Ideal for sending locally collected alarms to a main monitoring center
  • Commands based on TR-NWT-000833 Issue 4
  • Supports REPT-ALM and REPT-EVENT autonomous messages
  • Supports alarm retrieval commands such as RTRV-ALM
  • Permits TL1 controls to be issued to many of T/MonXM interrogator modules (ie: E2A, DCPF, TBOS, TRIP, DATALOK, DCM)
  • Multiple SID's per port
  • TL1/X.25 & TL1/RS232 support available

Overview

The TL1 responder software module gives either the T/MonXM WorkStation or IAM the ability to report alarms via TL1 (Transaction Language 1).

Report Alarms via TL1
Report Alarms via TL1: TLQ Responder Module Permits
T/MonXm and IAM's the Ability to Report Alarms via TL1.

TL1 is an ASCII based alarm protocol that can be used by either a person or a computer. Its popularity is growing as is evident by the number of network elements that support it. Consequently, new TL1 alarm masters are also popping up. Unfortunately, most of this new generation of TL1 masters only support TL1. This means that the "Legacy" equipment can not be directly monitored by these masters. This leaves you with several choices. You can split your network into old / new sections, which complicates administration. You can replace your old equipment, which is usually expensive and not always possible, or you can use a TL1 Mediation device.

The T/MonXM software with a TL1 responder module is such a device. This module was specifically designed for those users who want to use their existing TL1 master to monitor alarms from non TL1 elements. ANY data collection protocol on the T/MonXM platform can be easily converted to TL1.

TL1 responding comes in three flavors:

  1. Single port, which means that any one, previously unused hardware port, can be assigned TL1 functionality.

  2. Multiple port, same as one except that you can have multiple TL1 responders on your available ports. If you plan on needing more than one responding port, this is the way to go.

  3. TL1/X.25, in this scenario you can send your TL1 alarms out directly over X.25. This module will support either a single SVC or a single PVC. X.25 parameters such as data rate, frame/packet window sizes plus many more are definable.

TL1 sample autonomous output & command / response examples

*C 00013 REPT ALM OC3
      "LS-8A:CR,LOS,SA,,,NEND,AZ"
;
      FRESNO3 95-10-03 18:02:05
A   00014 REPT EVT OC48
      "LINE-1E:T-SEFS,SC,,,NEND,AZ:,,\"EVENT TRUE \"" ;

      FRESNO3 95-10-03 18:02:06
**  00015 REPT ALM EQPT
      "TG-2:MJ,IMPROPRMVL,SA,,,NEND,AZ"
      "REGULATOR:MJ,OFFLINE,SA,,,NEND,AZ"
;
RTRV-ALM:FRESNO3::305;
      FRESNO3 95-10-03 18:12:46
M   305 COMPLD
      "LINE-1E,OC48:NA,T-SEFS,NSA,,,NEND,AZ"
      "LS-8A,OC3:CR,LOS,SA,,,NEND,AZ"
      "TG-2,EQPT:MJ,IMPROPRMVL,SA,,,NEND,AZ"
      "REGULATOR,EQPT:MJ,OFFLINE,SA,,,NEND,AZ"
;
OPR-EXT-CONT:FRESNO3:SWITCH-TO:306::A-SIDE,MNTRY;
      FRESNO3 95-10-03 18:18:42
M   306 COMPLD
;

The responder module supports autonomous alarm messages so a TL1 message will be generated any time an alarm changes state. The responder also responds to various database and alarm status query commands. The TL1 module also accepts TL1 control commands and forwards them to the appropriate device. You do not have to worry about the format of the commands in their native protocol, since the responder will perform all of the necessary translations.

Since it is very likely that T/MonXM is collecting alarm information from multiple physical locations, you have the ability to assign multiple "TIDs" to the TL1 responder. This makes it appear to the TL1 manager as though it is directly talking to the NE. You can of course assign a TID for the XM alarms that originate at the XM site.

The databasing consists of two easy steps. The first is to assign the various TL1 attributes to each alarm point that you wish to monitor. These are physically defined on the "interrogator side" of the database. These attributes include: TID (SID), AID, EQUIPMENT, COND, LEV, DIR, SVC EFF, and ALM/ENV. Then you define a TL1 responder and assign which source displays you wish to make available on the responder port. The advantages of this are many. First of all it becomes possible to define the attributes only once per display and have the output sent to multiple ports. You also have the ability to limit the output of a TL1 responder to specific portions of the database.

The TID, AID and COND fields are dynamic, which means that you can add new entries "On the fly" as needed. The editor has several function keys which will display entire tables or select items sequentially. The TL1 attribute editor has many features to reduce input time including: Block Copy, Block Move, Range functions, Read display, point insertion and deletion. Of all of those features, "read display" is the most useful if you have standard alarm device types. This is because you can create a "template" and then read (copy) into each occurrence of that device type.

Since no TL1 master works exactly alike, a number of selectable options have been added to facilitate compatibility with your master. These include the ability to limit spontaneous output to 1 alarm per message, whether or not Null AIDs are allowed, and character echo.

Need a Quote?

Get it by: 4:15 PM Tuesday (tomorrow)

Now: 9:28 PM
Next Step:
Send Us Your Quote Request
8:00 AM Tuesday
We'll Start Work on Your Detailed Quote
4:15 PM Tuesday
Get Your Quote (Email PDF)

It's 9:28 PM on Monday at our Fresno, CA, USA headquarters. It's late in the day, but we promise to start on your quote first thing in the morning.

Get a Quote