TL1 Tutorial

In telecommunication industry, TL1 is the most popular Command Line Interface (CLI) and the de facto
standard management protocol. This tutorial covers the history and evolution of TL1, message
structure and syntax of TL1 commands, and the TL1 features.

Page 1 of 43
Table of Contents
TL1 Tutorial ......................................................................................................... 1
1.0 History and Evolution of TL1.......................................................................... 4
2.0 TL1 – The Telecom Management Protocol...................................................... 5
2.1 TL1 and SNMP: A comparison.......................................................................... 5
3.0 TL1 Language ................................................................................................ 8
3.1 TL1 Message Types ........................................................................................ 9
3.2 TL1 Input Message ...................................................................................... 10
3.2.1 Command Code .........................................................................................10
3.2.2 Staging Block ............................................................................................10
3.2.3 Payload Block ............................................................................................12
3.2.4 Examples for TL1 input commands: .............................................................12
3.3 TL1 Acknowledgment .................................................................................. 13
3.3.1 Acknowledgment code ................................................................................13
3.3.2 CTAG .......................................................................................................13
3.3.3 Terminator................................................................................................13
3.4 TL1 Response Message ................................................................................ 14
3.4.1 Response Header .......................................................................................14
3.4.2 Response ID..............................................................................................14
3.4.3 Response Block .........................................................................................15
3.4.4 Terminators ..............................................................................................15
3.4.5 Examples for TL1 response messages: .........................................................16
3.5 TL1 Autonomous Message ........................................................................... 17
3.5.1 Header .....................................................................................................17
3.5.2 Auto ID ...................................................................................................17
3.5.3 Text Block.................................................................................................18
3.5.4 Terminators ..............................................................................................18
3.5.5 Examples for TL1 input commands: .............................................................19
3.6 Verb List ..................................................................................................... 20
3.7 TL1 Parameters ........................................................................................... 21
3.7.1 Position-Defined Parameters .......................................................................21
3.7.2 Name-Defined Parameters ..........................................................................21
4.0 TL1 Provisioning Messages .......................................................................... 22
4.1 Equipment Provisioning Messages...................................................................22
4.2 Facilities Provisioning Messages ......................................................................22
4.3 Cross-connect Provisioning ............................................................................22
4.4 Facility Protection Group (FFP) Provisioning .....................................................23
4.5 Gateway NE Map Provisioning ........................................................................23
5.0 TL1 Protection Switching Messages............................................................. 24
5.1 Switching Messages ......................................................................................24
5.2 SONET Protection Switching Messages ...........................................................24
5.3 Non-SONET Line Protection Switching Messages ...............................................24
6.0 Telcordia GRs .............................................................................................. 27
7.0 Gateway NE ................................................................................................. 28
7.1 TL1 Deployment Scenario ..............................................................................28
7.2 Need for Gateway NE ....................................................................................28
7.3 How GNE Works ...........................................................................................30
7.4 Building TL1 Agent for GNE ............................................................................30
8.0 Delayed Activation....................................................................................... 31
8.1 Need for Delayed Activation ...........................................................................31
8.2 How delayed activation works ........................................................................31

Page 2 of 43
 8.3 Delayed activation parameters .......................................................................31
8.4 How to set the delayed activation parameters in a TL1 command .......................32
8.5 How to retrieve pending commands ................................................................32
8.6 How to activate pending commands ................................................................32
8.7 How to cancel pending commands ..................................................................33
9.0 Security ....................................................................................................... 34
9.1 Telcordia's view on security ...........................................................................34
9.2 Implementing Security in TL1.........................................................................35
9.3 Building TL1 Agent from Security point of view.................................................38
10.0 TL1 and OSMINE certification .................................................................... 39
10.1 Key Benefits of OSMINE...............................................................................39
10.2 Preparing Yourself for OSMINE Certification....................................................39
10.3 How easy is it? ...........................................................................................39
11.0 Glossary .................................................................................................... 41

Page 3 of 43
1.0 History and Evolution of TL1
During the mid-80s, Bellcore embarked on specifying a standard man-machine language
to manage network elements (NEs.) It was to be based on Z.300 series Man Machine
Language (MML) standards. It was designated Transaction Language 1 or simply TL1.

This effort encompassed specifying a language as well as message set(s) for managing a
variety of Telecom equipments from different domains. During that time, Bellcore was
also developing a fault management OSS (Operations Support System) called Network
Monitoring and Analysis (NMA) for the Regional Holding Companies (RHCs). Incidentally,
TL1 was chosen as NMA’s element management protocol. Consequently, for NEs to be
NMA manageable, TL1 support became mandatory.

TL1 made its foray into carrier networks well over a decade ago and during the
subsequent years; TL1 deployments became widespread in the RHC space. Circuit
switches were the only ones that did not embrace TL1 and continued to operate their
proprietary interfaces. Today TL1 is a management protocol of choice for majority of
SONET and access infrastructure in North America.

Page 4 of 43
2.0 TL1 – The Telecom Management Protocol
TL1 excels as the de facto standard telecom management protocol with the following
advantages over other protocols.

Standard Command Line Interface: Being ASCII, human operators can compose input
message and directly interpret responses and events. Unlike many other CLIs, TL1 is not
free form, with the syntax of one command differing from the next. As a result, element
managers use the same TL1 interface.

Man-Machine Language: TL1 messages are in plain ASCII text, so operators and
developers alike can always read them. As messages are easily readable, TL1 does not
require sophisticated debuggers or protocol analyzers - what you see is what you get.

Delayed Activation: Delay Activation is a function whereby an input message (request)

can be stored in a Message Pending buffer at the NE, for final execution later, either
automatically or by a subsequent message from the OS.

Autonomous Message Tracking: ATAG (Autonomous Message Tag) in autonomous

message allows an OS to determine if it has failed to receive any spontaneous outputs by
checking for omissions in the sequence of messages received.

Acknowledgment: An acknowledgment is a brief output message generated in response

to an input command message. As per the standards, an acknowledgment should be used
if an output response message to the command cannot be transmitted within 2 seconds of
its receipt.

2.1 TL1 and SNMP: A comparison

The purpose of this comparison is to give you a clear understanding of TL1 by comparing
it with SNMP. This is not aimed at projecting any protocol better than the other.

SL
Functions & Features
No
Operations:
Operations are the actions
1.
initiated by manager to manage
the managed objects.
Notification:
A notification is one generated by
2. the NE to report some unusual
occurrence. It can be either
periodic or spontaneous.
Management Information
Model:
3.
Abstract representation of
managed object.
TL1 SNMP
Input Messages. It
GET, SET, GET-NEXT, and
may operate on
GET-BULK
some data or it may
Here, all requests will
initiate some action
operate on data.
in NE.
Autonomous Trap, Notification, and
Message Inform
The Internet Structure of
There is no such
Management Information
information
(SMI) defines the rules for
model used in TL1.
how management
Here every thing is
information is described and
action to be taken
stored. Here, it is called as
at NE.
MIB (Management

Page 5 of 43

Encoding:
Transforming the messages that
4.
are sent over communication
channel.
Notification Tracking:
Provision in notification
that allows an OS to determine if
it has failed to receive any
5.
spontaneous outputs by checking
for omissions in
the sequence of messages
received
Acknowledgment:
An acknowledgment is a short
reply from the NE indicating that
6.
an input command message is
being acted upon or has
been immediately rejected.
Delay Activation:
Delay Activation is a function
whereby an input message
(request) may be stored in a
7. Message Pending buffer at the
NE for final execution later,
either automatically or by a
subsequent message from the
OS.
Man-Machine Language:
Operators can compose request
8.
message and directly interpret
responses and events.
Security:
Security is concerned
9. with protecting managed
resources from
unauthorized access.
Information Model).
There is no
encoding here. TL1
ASN.1 encoding is used here.
messages are in
plain ASCII text.
ATAG in
autonomous
Inform can be used by agent.
message allows an
Inform is nothing but
OS to determine if
Confirmed Notification. After
it has failed to
an Inform message is sent
receive any
out, the agent will get back
spontaneous
with a response message for
outputs by checking
the transmitted Inform
for omissions in
message.
the sequence of
messages received.
Yes No
Yes No
Yes.
TL1 is man -
machine and
machine - Machine-Machine Language.
machine language. It requires manager
Therefore, it can be application.
managed from both
the craft terminal
and OSS.
It can be
implemented by
SNMPv3 uses USM (User
using system
Security Model) and VACM
and resource access
(View based Access
control mechanism.
Control Mechanism) security
System access
model. Here, authentication
control needs
is done per message.
persistent
So connection between OSS
connection between
and NE may be
OSS and NE for
persistent or not.
authentication
(System access
Page 6 of 43
control).

Page 7 of 43
3.0 TL1 Language
A TL1 resource is one, which uses TL1 protocol for communication. To perform functions
on these resources and to manage them, TL1 messages are used. TL1 messages comprise
two sets:

Input messages - these are the messages sent to a TL1 resource with an intention
of operating, maintaining, or provisioning the TL1 resource.

Responses and Autonomous messages - these are messages emitted by the NEs
when they are in receipt of an input message (response) or when they notify about
an event or an alarm condition in the NE (autonomous message)

Telcordia standardized these messages by specifying rules for syntax, structure, and
semantics of TL1 messages (GR-831). Any TL1 message should adhere to these
specifications so that they all speak a common TL1 language.

Page 8 of 43
3.1 TL1 Message Types
There are four types of TL1 messages, namely input message, response,
acknowledgment, and autonomous message.

TL1 Input Messages

These messages are also called as commands. They are used to operate on the NEs.
Input messages can be sent either by the OSS via a GUI or by an operator via a
command line interface.

TL1 Response Messages

These are messages sent by the NEs as a token of receipt for the input message. When
the input messages are sent, you can specify whether a response is required or not. If a
response is required then the NE sends an immediate message. On receipt of the input
message indicating that, the message has been received.

TL1 Acknowledgment Messages

These are brief messages from the NE to OSS acknowledging the receipt of a TL1
command. It updates the user on the status of a given command. Acknowledgment is
issued if the normal response to a message will be delayed by more than two seconds.

TL1 Autonomous Messages

These are messages sent by the NEs, on their own without being requested by the OSS,
on occurrence of an event or an alarmed condition of the NE. Autonomous messages also
report the periodic data collected.

Page 9 of 43
3.2 TL1 Input Message
TL1 input messages are also called TL1 commands. They are used to operate specific
tasks on the NEs. They can be sent either by the OSS via a GUI or by an operator via a
command line interface. TL1 input message or the TL1 command takes the following
format

command_code:staging_block:payload_blocks;

3.2.1 Command Code

The command code part of the input message defines the nature of the task that is to be
executed on the NE. It is also called the VMM (verb-modifier-modifier). A command code
has the following format

verb-modifier1-modifier2

Verb: Refers to the type of action to be taken on the NE (in case of input message)
or the type of event that has occurred in the NE (in case of autonomous message).
Refer to the table of verbs to know the list of verbs that are used in messaging.
Modifiers: These are optional qualifiers for the input message. Depending on the
complexity of the message, one can use modifiers. Modifier 1 and modifier 2 are
used to identify and describe the object in the NE, which has to be acted upon by
the message, respectively.

3.2.2 Staging Block

The staging block part of the input message helps in identifying the exact resource in the
NE, which has to be acted upon by the command. The staging block has the following
format
:TID:AID:CTAG:generalblock:

Target Identifier (TID)

Every TL1 network element is assigned with a Target Identifier (TID), which uniquely
identifies the NE. TID is used for identifying the end NE when commands from OSSs are

Page 10 of 43
routed through a gateway network element.

TID can be of maximum 20 ASCII characters limited to letters, digits, and

hypens.
In direct routing, where commands are sent to an NE directly from the OSS,
the TID value will be null.
In indirect routing, where commands are sent to NEs via an intermediate GNE,
a valid TID value is essential.
TID should be equal to the system identification code (SID) that is returned in
a response message from the NE.

Access Identifier (AID)

The access identifier contains one or more simple or compound parameters that uniquely
identify the entity, within or associated with the target NE, to be acted upon by the input
message. Typical examples of entities addressed by the AID parameter value are as
follows:

circuits and common equipment modules having hierarchical relationships,

record entities within the context of an administrative view of the NE database,
test session and Test Access Point aliases.

Correlation tag (CTAG)

CTAG is used to correlate a response or acknowledgment with the originating input

message. It is an OSS-generated integer that helps in correlating the input command with
the feedback got from the NE. Without a CTAG, you will not be sure of which response
correlates to which command.

General Block
The general block holds the information that mandates how the command will be handled
by the NE.

General block is mandatory in commands that have payload.

General block can be used to specify the delayed-activation parameters.
If delayed-activation is not supported then general block may be null
(represented by two semi-colons ::).

General block has the following format

:[[<delayed activation parameters>],[<contingency flag>],[<indirect
data retrieval identifier>]]:

Delayed Activation Parameters - There are three parameters involved in delayed

activation. 1)ORDER NO, 2) DATE, 3) TIME.
Contingency Flag - This parameter can specify whether or not a message can
have partial success when more than one AID is specified.
Indirect Data Retrieval - Indirect data retrieval is used in a RTRV message and
instructs the NE to return data for linked administrative views. The parameter
here is RTRVIND=<linked_admin_view>[-<linked_admin_view>].

Page 11 of 43
3.2.3 Payload Block

Any additional information that is required to carryout the command is specified in this
payload block.

Payload block consists of zero or more datablocks. Each datablock is separated

by colons.
Every datablock may contain multiple datacomponents, separated by commas.
Datacomponents may be either position-defined or name-defined parameters.

Payload block has the following format

payload_block::=data_block_list;data_block_list::=data_block |
data_block_list:data_block

3.2.4 Examples for TL1 input commands:

Message definition Example command

ACT-USER::USER
NAME:<Ctag>::PASSWORD;
ENT-USER-SECU ::<UID>:<CTag>:
PID,CID,UAP :
PCND,PCNN,POINT,UOUT,LSTOILIST;
ENT-
TCPRE:<TID>::<ctag>:<GB>:<ENE>,<IP
address>,<port number>;
ALW-EX:::<C
TAG>:ON,DATE,TIME,CF,RTRVIND:;
ENT-CRS-STS1:<TID>:<from
channel>,<to channel>:<ctag>::;
ED-PID:<TID>:<UID>:<CTAG>::<OLD
PID>,<NEW PID>;
ACT-USER::root:4::public;
ENT-USER-
SECU::user1:13::user1,TCP,2:56,8,4,10,87,file;
ENT-
TCPRE:GNE1::4::NE3,192.168.1.1,9090;
ALW-EX: : : 2 : 1,01-03-17 , 11-22-40, : ;
ENT-CRS-STS1:GATE:STS-4-2,STS-7-3:43::;
ED-
PID:POUND:private:123::public,hareens12;

Page 12 of 43
3.3 TL1 Acknowledgment
An acknowledgment is a brief TL1 output message from the NE to an OSS acknowledging
the receipt of a request. It updates the user on the status of a given command.
Acknowledgment should be issued if the normal response to a message will be delayed
longer than two seconds.

TL1 acknowledgment can take the following format

acknowledgment_code ctag terminator

An example for acknowledgment message is

OK 12345
>
where, OK - acknowledgment code, 12345 - ctag, greater than symbol > - terminator

3.3.1 Acknowledgment code

Standard TL1 acknowledgment codes are

IP: In Progress
PF: Printout follows (identical to IP)
OK: All right
NA: No acknowledgment
NG: No Good
RL: Repeat Later system busy

3.3.2 CTAG

Refers to the correlation tag of the input message to which this acknowledgment is made.

3.3.3 Terminator

TL1 acknowledgments always end with greater than symbol > terminator.

Page 13 of 43
3.4 TL1 Response Message
TL1 response message, its structure, and syntax are discussed in detail here.

Response is an output message sent by the NE to OSS on completion of the task

requested by the TL1 input message. It may be preceded by an acknowledgment
message. A simple response message confirms the outcome of the requested task or
operation. It says whether the requested task was completed successfully or not. A
complex response message, in addition to giving the status of the task, includes data in
the message.

TL1 response message takes the following format

header response_id [response_block] terminator

3.4.1 Response Header

Response message’s header block take the following form:

^^^sid^year-month-day^hour:min:sec

Here, SID is the source identifier, year-month-day and hour:min:sec represent the date
and time of the message.

SID
Source identifier represents the name of the NE used for identifying the NE emitting the
message. SID is similar to the target identifier.

3.4.2 Response ID

Response ID identifies the type of output message - whether it is a response or an

autonomous message. Response Id takes the following format
M^^ctag^completion_code

M - used to differentiate between response and autonomous message

ctag - indicates the correlation tag assigned with the input message.
completion code - indicates the status of the task - whether it is completed
successfully or not.

Page 14 of 43
Completion
Parameters
code Type
COMPLD - indicates successful completion of the requested operation.
Success
DELAY - indicates successful delayed activation of the requested
response code
operation.
DENY - indicates failure of the TL1 command and provides an error
message with the reason for the failure.
PRTL - indicates partially successful response. That is, the requested
Other response
action can be completed for some of the specified AIDs, but not all.
code
RTRV - indicates that the response is successful, but it is lengthy and
is being returned in multiple parts. Final response has a COMPLD
response code.

Error Categories
Whenever a TL1 command fails, the response message contains the failure code.
Following are the failure codes

EXXX - Equipage errors

FXXX - Fault errors
IXXX - Input errors
PXXX - Privilege errors
RXXX - Resource errors
SXXX - Status errors

3.4.3 Response Block

TL1 output messages contain text blocks. These text blocks hold the main body of the
output message and the payload. In response messages, these text blocks are called
response blocks. Response block have quoted lines, unquoted lines, and comments.

An unquoted line is made up of a list of parameters (either name defined or

position defined) separated by mandatory white spaces or optional commas.
A quoted line consists of a double quoted (") line of machine parsable text.
A comment allows free form text messages to be generated by the NE for
presentation to the OS. The comment must begin with /* and end with */.

3.4.4 Terminators

Syntax of terminators : <cr><lf>( ; | > )

The semicolon (;)indicates the termination of output messages and greater than (>)
character indicates more output associated with this response will follow under another
header. The size of the output message should not exceed 4096 bytes. If it exceeds the
specified size, then the output response is split into multiple responses with the same
CTAG.

Page 15 of 43
3.4.5 Examples for TL1 response messages:

TL1 Input Message Corresponding Response Message

RTRV-USER-SECU::root:12::; <CR>
<LF><LF> Source 02-01-09 20:25:02<CR>
<LF>M 12 RTRV<CR>
<LF>
"UID=root:CID=TCP&CRAFT,UAP=1:PAGE=60,
PCND=7,
PCNN=3,POINT=180,UOUT=90,
LSTOI=1"<CR>
<LF>;
ENT-TCPRE:GNE1::4::NE3, <CR>
192.168.1.1,9090; <LF><LF> System 02-01-11 19:30:43<CR>
<LF>M 4 COMPLD<CR>
<LF>;
ACT-USER::root:4::public; <CR>
<LF><LF> Source 02-05-06 14:26:12<CR>
<LF>M 4 COMPLD<CR>
<LF> "UID=root:LASTLOGIN=Mon May 6
14:25:13
2002,UNSUCCESSATTEMPTS=0"<CR>
<LF>;
ENT-CRS-STS1::STS-4-3, STS- Error Message
2-1:43:; <CR>
<LF><LF> Source 02-05-06 14:30:42<CR>
<LF>M 4 DENY<CR>
<LF> EANS<CR>
<LF> "ACCESS NOT SUPPORTED"<CR>
<LF>;

Page 16 of 43
3.5 TL1 Autonomous Message
Autonomous messages are output messages sent by the NEs to report alarms,
performance data, configuration changes, or condition changes. Messages relating to
alarm conditions are spontaneously triggered by the NE without intervention. Messages
relating to periodic reporting of performance data values are scheduled by the operator.

Autonomous message has the following format

header auto_id [text_block] terminator

3.5.1 Header

Autonomous message’s header block take the following form:

^^^sid^year-month-day^hour:min:sec

Here, SID is the source identifier, year-month-day and hour:min:sec represent the date
and time of the message.

SID
Source identifier represents the name of the NE used for identifying the NE emitting the
message. SID is similar to the target identifier.

3.5.2 Auto ID

Autonomous identifier block has the following format

alarm_code^atag^verb [-modifier1[-modifier2]]

Alarm Code

Alarm code indicates the severity of the alarm. One of the four severity levels, given
below in the table, is assigned to every event condition.

Alarm Code Corresponding notification code

Description
(almcde) (ntfcncde)
*C Critical alarm condition CR
** Major alarm condition MJ
*^ Minor alarm condition MN
Non-alarmed autonomous
A^ CL, NA
message

Page 17 of 43
If multiple alarms are reported, the alarm code will correspond to the alarm with the
highest severity. Non-alarmed code is used when the NE reports non-alarmed
autonomous messages such as those reporting performance data measurements.

ATAG

Every TL1 autonomous message, that the NE generates autonomously, contains a unique
identifier called the Autonomous TAG (ATAG). It is an integer value (e.g., 198)
incremented by one for each message. These ATAGs can be used for alarm correlation.
The OSS can look for the continuity of the ATAG values and verify that no message is lost.
If the OSS senses an ATAG out of sequence, it can request the missing data to be sent
again from the NE.

Fractional ATAG : Sometimes ATAG may be associated with a second decimal,

component. It helps in correlating multiple events with a single source (e.g.,
198.7).

ATAG character length GR-833 specifies the character length of ATAG to be

maximum of 10 characters including the fractional component.

VMM

VMM represents the verb-modifier1-modifier2 format or the command code. The verb
indicates the action to be taken on the NE, as requested by the TL1 command, or the type
of autonomous event that is fired by the NE. The modifiers further qualify the command
as to which object is acted upon by the command and give additional description about
the object.

3.5.3 Text Block

Text blocks hold the main body of the output message and the payload. Text blocks have
quoted lines, unquoted lines, and comments

An unquoted line is made up of a list of parameters (either name defined or

position defined) separated by mandatory white spaces or optional commas.
A quoted line consists of a double quoted (") line of machine parsable text.
A comment allows free form text messages to be generated by the NE for
presentation to the OS. The comment must begin with /* and end with */.

3.5.4 Terminators

Syntax of terminators: <cr><lf>( ; | > )

The semicolon (;)indicates the termination of output messages and greater than (>)
character indicates more output associated with this autonomous message will follow
under another header. The size of the autonomous message should not exceed 4096
bytes. If it exceeds the specified size, then the autonomous message is split into multiple
responses with the same CTAG.

Page 18 of 43
3.5.5 Examples for TL1 input commands:

Autonomous Message definition Description

<CR> This autonomous message will be sent
<LF><LF> Source 02-01-15 14:28:09 when the security log file is completely full.
<CR>
<LF>** 1 REPT ALM SECU <CR>
<LF>"SECURITY
LOG:CR,LOGBUFROVFL-
SECULOG"<CR>
<LF>;
<CR> This autonomous message will be sent
<LF><LF> Source 02-05-06 when a user logs in.
13:23:03<CR>
<LF>A 1 REPT EVT SESSION<CR>
<LF> "root:NO,"<CR>
<LF> /*NOTICE: This is a private
computer system.<LF> Unauthorized
access or use may lead to
prosecution.*/<CR>
<LF>;

Page 19 of 43
3.6 Verb List
The table contains a list of generic TL 1 command verbs.

S.No Verb Definition

1 ABT Abort
2 ACPT Accept
3 ACT Activate
4 ALW Allow
5 AUD Audit
6 CANC Cancel
7 CHG Change
8 CMPR Compare
9 CONN Connect
10 COPY Copy
11 CPY Copy
12 CRPT Corrupt
13 CRTE Create
14 DGN Diagnose
15 DISC Disconnect
16 DLT Delete
17 ED Edit
18 ENCAP Encapsulation
19 ENT Enter
20 EX Exercise
21 EXIT Exit
22 FLTLOC FaultLocate
23 INH Inhibit
24 INIT Initialize
25 MEAS Measure
26 MON Monitor
27 OPR Operate
28 RD Read
29 REC Recover
30 RECNFGR Reconfigure
31 REPT Report
32 RLS Release
33 RMV Remove
34 RST Restore
35 RTRV Retrieve
36 SCHED Schedule
37 SET Set
38 SND Send
39 STA Start
40 STP Stop
41 TEST Test
42 TRACE Trace
43 WRT Write

Page 20 of 43
3.7 TL1 Parameters
The parameters used in TL1 message can be broadly classified into two : Position-defined
parameters and Name-defined parameters.

3.7.1 Position-Defined Parameters

Position-defined parameters take the following form

ValueA, ValueB, .... (comma separated values)

They appear in the same block in any TL1 message. It is necessary to retain delimiters for
position-defined parameters. Meaning, if a position defined parameter takes a null value,
then empty commas exist to represent the null value.

Example : ValueA,,, ValueB, (here the two commas represented in red indicate the
presence of two null values valueA and valueC). Good example for position defined
parameters is the CTAG

3.7.2 Name-Defined Parameters

Name-defined parameters take the following form

Name1=Value1, name2=value2, ….

The parameter names are case sensitive, whereas the value are not case-sensitive. You
need not retain delimiters to mention the null value of the values.

Example: name1=value1, name3=value3…..(though the parameter 2 is missing here, you

need not have an empty comma)

NOTE : In a TL1 message you can't mix name-defined and position-defined parameters
inside a single block. The type of parameter used inside a single block (separated by
colon) should be of only one type either name-defined or position-defined. However, you
can have multiple blocks inside the payload block each of different type.

For example, in the cross connect command given below

ED-CRS-STS1:TID:FROM_AID,
TO_AID:CTAG::common_block:specific_block:state_block; the common
block and the state block are position defined, whereas the specific block is name defined.

Page 21 of 43
4.0 TL1 Provisioning Messages
The following are the types of provisioning messages used by TL1 operators.

4.1 Equipment Provisioning Messages

The equipment provisioning messages defined in GR-199 are provided in the table
below. These messages are used to implement equipment provisioning.

DLT-EQPT Delete equipment

ED-EQPT Edit equipment/ Usually used to re-provision an existing entity

ENT-EQPT Edit equipment/ Usually used to provision a new entity

RTRV-EQPT Retrieve a list of equipment

4.2 Facilities Provisioning Messages

TL1 supports configuration and provisioning of facilities. The table below gives you the
facilities provisioning messages defined in GR-199.

DLT-mod1 Delete the attributes of a given entity

ED-mod1 Edit the attributes of an existing entity

ENT-mod1 Edit the attributes of a new entity

RMV-mod1 Remove entity from service

RST-mod1 Restore entity to service

RTRV-mod1 Retrieve the attributes of a given entity

4.3 Cross-connect Provisioning

The cross connect provisioning messages are provided in the table below.

DLT-CRS-mod2 Delete a crossconnect

ED-CRS-mod2 Edit information about crossconnected transmission entities.

ENT-CRS-mod2 Enter information about crossconnected transmission entities.

RTRV-CRS Retrieve crossconnected channels

RTRV-CRS-mod2 Retrieve information about crossconnected transmission entities.

Page 22 of 43
4.4 Facility Protection Group (FFP) Provisioning

TL1 provides messages to support facility protection provisioning. Facility protection

groups associate a protecting (alternate) facility with a protected (preferred) facility.

Delete members of a facility protection group or the entire facility

DLT-FFP-mod2
protection group

Edit information about members of a facility protection group or the

ED-FFP-mod2
entire facility protection group

Create a facility protection group and enter attributes about that

ENT-FFP-mod2
group

Retrieve information about a facility protection for the given access

RTRV-FFP-mod2
identifier(s)

4.5 Gateway NE Map Provisioning

It is possible for you to configure gateway NEs to manage table entries. There are two
types of tables, facilitating message routing: OSACMAP correlates specific OSs to OSI
application associations. Each entry maps the OS's X.25 SNPA to an OSI application
context ID. TADRMAP correlates the TIDs of the subtending NEs to their network
addresses.

Delete an entry in gateway NE's OS application context mapping

DLT-OSACMAP
table.

ED-OSACMAP Edit an entry in gateway NE's OS application context mapping table.

Create an entry in gateway NE's OS application context mapping

ED-OSACMAP
table.

RTRV-OSACMAP Retrieve the gateway NE's OS application context mapping table.

DLT-TADRMAP Delete an entry in gateway NE's TID to NSAP mapping table.

Edit an entry in gateway NE's TID to network address mapping

ED-TADRMAP
table.

Create an entry in gateway NE's TID to network address mapping

ENT-TADRMAP
table.

RTRV-TADRMAP Retrieve the gateway NE's TID to network address mapping table.

Page 23 of 43
5.0 TL1 Protection Switching Messages
The following are the TL1 protection switching messages used by TL1 operators.

TL1 protection switching messages help switching capability between working,

protection, and backup entities. You have messages to control the backup capabilities of
redundant equipment units and facilities.

5.1 Switching Messages

NEs provide protection switching upon detecting trouble in the line. You can implement
the functions using the switching messages shown below. These messages are defined
in GR-833[1].

EX-SW This command instructs an NE to exercise the algorithm for switching from a an
equipment or facility entity from working to protection.

REPT-SW Generated by the NE after it has autonomously switched an active unit of a duplex
equipment pair to standby and switched its mate to active.

SONET Protection switching messages for SONET NEs.

Non-SONET Protection switching messages for non-SONET NEs.

5.2 SONET Protection Switching Messages

SONET provides automatic protection switching upon detecting trouble in the line. You
can implement the functions using the switching messages shown below. These
messages are defined in GR-833[1].

OPR- Instructs a SONET NE to initiate a SONET line or path protection switch request. User
PROTNSW switch requests initiated with this command (i.e., forced switch, lockout, and manual
switch) remain active until they are released via the RLS PROTNSW command or
overridden by a higher priority protection switch request. To initiate protection switch
exercise, use EX SW.

RLS- Instructs a SONET NE to release a SONET line or path protection switch.

PROTNSW

5.3 Non-SONET Line Protection Switching Messages

The following commands instruct NEs to allow or inhibit automatic / manual switching
to protection or working. DO NOT USE THESE COMMANDS FOR SONET LINE
PROTECTION SWITCHING.

ALW-SWDX Thi di t t th NE t ll t ti l it hi t

Page 24 of 43
 protection for a managed inventory or facility entity on a duplex system.

To inhibit from switching to protection, use INH-SWDX.

ALW- This command instructs the NE to allow automatic or manual switching to

SWTOPROTN-xx protection for a managed inventory or facility entity. This function is sometimes
called "release lockon" or "release lockout."

The AID in this command identifies either the equipment unit or facility for
which switching to protection is being allowed. The entity may be the working
unit or the protection unit.

• For a working unit, this command allows the unit to access any
protection unit, and the state of the working unit changes from IS-NR-
ACT-LOCK to IS-NR-ACT.
• For a protection unit, this command allows the protection unit to be
accessed by any working unit, and its state changes from IS-NR-STBY-
LOCK to IS-NR-STBY.

To inhibit from switching to protection, use INH-SWTOPROTN.

ALW-SWTOWKG- This command instructs the NE to allow automatic or manual switching to

xx working for a managed inventory or facility entity that has been switched to
protection. The ALW-SWTOWKG function is sometimes called "release lockon a
protection unit" or "release lockout a working unit."

To inhibit from switching back to working, use INH-SWTOWKG.

INH-SWDX-xx This command instructs the NE to inhibit automatic or manual switching to

protection for a managed inventory or facility entity on a duplex system.

Any NE for which switching to protection is inhibited with the INH-SWDX

command should include the appropriate condition type information in response
to a RTRV-COND request.

INH- This command instructs the NE to inhibit automatic or manual switching to

SWTOPROTN-xx protection for a managed inventory or facility entity.

Any NE for which switching to protection is inhibited with the INH-SWTOPROTN

command should include the appropriate condition type information in response
to a RTRV-COND request.

INH-SWTOWKG- This command instructs the NE to inhibit automatic or manual switching to

xx working for a managed inventory or facility entity that has been switched to
protection.

Any NE for which switching to working is inhibited with the INH-SWTOWKG

command should include the appropriate condition type information in response
to a RTRV-COND request.

Page 25 of 43
SW-DX-xx This command instructs an NE to switch an equipment unit or facility with the
mate unit within the NE.

SW-TOPROTN-xx Perform a protection switch

SW-TOWKG-xx Release a unit from protection

Page 26 of 43
6.0 Telcordia GRs
Tellcordia specifies standards for TL1 by publishing GRs .Generic Requirements (GR)
provide Tellcordia's view of proposed generic criteria for telecommunications equipment,
systems, or services.

The table below gives a partial list of the Telcordia GRs.

GR831 - Operations Application Messages - Language for Operations Application

Messages It provides implementation level requirements for TL1.This document mainly
focuses on the syntax and semantics of TL1 messages(input, output, acknowledgment
and autonomous).

GR199 -This document provides the messages and data dictionary information required
for the memory administration functions for SONET and switching NEs. It also provides
provisioning messages for common NE and message related to Gateway NE.

GR833 - NE and Transport Surveillance Messages. This documents describes message

structures for network maintenance and surveillance functions.

GR 815 - proposes the Telcordia view of the generic requirements for Network Elements
(NEs) and Network Systems (NSs) security, i.e., the generic security features required of
a total NE/NS environment. These requirements are generic and are not specific to any
particular NE/NS. GR 815 defines the baseline security requirements ie. a minimum level
of security. Additional security may be needed for specific applications.

TR 835 - describes Bellcore's view of message structures and data elements for
Network Element and Network System Security administration.

SR-NWT-002723 -provides applicable TL1 Messages for SONET Network Elements.

Where to get GRs?.

Visit the following URL to get more information about GRs.

http://telecom-info.telcordia.com/

Page 27 of 43
7.0 Gateway NE
Gateway NE has the capability to route input messages from the EMS to the NEs.
And it also routes the autonomous messages from the NEs to the EMS. This article
speaks more about this GNE in detail.

7.1 TL1 Deployment Scenario

In TL1, there are two major types of NE deployment. One is the deployment in a
ring or bus topology and the other is deployment in a linear topology. Systems
such as SONET, SDH, etc., are examples of deployment in a ring topology. A
system such as IDLC is an example for deployment in linear or non-ring topology.

SONET systems interconnect the devices in a ring manner. Any command to the
NEs should pass through this ring. IDLC system interconnects the devices in a
linear manner. A manager, which communicates with the devices, requires a
TCP/IP connection.

7.2 Need for Gateway NE

In SONET systems, a command can reach an NE after passing the intermittent

NEs. A device as such cannot pass on the command. Hence, at least one of the
devices should be a gateway element so that it passes the command to the
intended device.

Figure 1.0

In SONET systems, apart from the normal operations channel, there is another
channel called Data Communication Channel (DCC). Used only for administrative
and management operations. A command, sent through DCC travels through all
NEs in the path before reaching the target NE. NEs present in between the GNE
and the ENDNE (target NE) are called Intermediate NEs (INEs).

Page 28 of 43
 Figure 2.0

IDLC systems require a dedicated TCP/IP connections between NEs and the
manager. Holding a dedicated TCP/IP connection for every NE is not a scalable
solution. Hence, at least one of the NEs should be gateway element to enable
routing of messages between OSS and the NEs.

Figure 3.0

For security reasons, some NEs have restrictions on the number of "simultaneous
user sessions". While managing such elements, the management applications and
the craft operators face a "resource constraint problem" accentuated by the user
session restrictions. Installing a GNE and routing the messages from multiple
operators via the GNE solve this problem. Refer to figure 3.0.

Page 29 of 43
Note :You can correlate GNE with the proxy feature of other management
protocols. Without GNE, the management of TL1 networked devices will become
difficult.

7.3 How GNE Works

A gateway network element has the ability to route information between NEs and
the OSSs. It holds a persistent connection with the manager to enable message
routing. The TIDs in the input command help GNE to identify the target NE. GNE
maintains the list of TIDs of the NEs connected to it. Whenever GNE receives a TL1
input message, it routes the message to the appropriate NE by referring the TID.
The GNE will also route the autonomous messages from the NEs to the OSS.

If the device is IP based, then the GNE opens up a TCP/IP connection, sends the
command, and then closes the TCP/IP connection. In a SONET system, there is a
dedicated channel called Embedded Operations Channel (EOC). GNE uses separate
EOC commands such as ENT-EOCRE, ED-EOCRE, DLT-EOCRE, RTRV-EOCRE (refer
to GR199) to add, delete, edit, and retrieve EOC entries in the GNE table.

Some networks use multiple communication channels, such as TCP/IP and X2.5.
The routing entries for such channels will be different. Hence, for every protocol,
you have to implement TL1 commands, similar to those of EOC commands. This
enables the GNE to route messages in these channels over the specified protocol.

7.4 Building TL1 Agent for GNE

For an NE to act as a gateway NE, its agent should support the following.

• It should maintain a routing table (TID, subtended NE details(e.g. IP

address and portnumber).
• It should also implement TL1 Messages for manipulating routing table.

The differentiation between NE and GNE lies in the agent that is

installed in it. GNE’s agent should have the capability to interpret
the commands and identify the target NE. It should then send
the command to the target NE, by opening a session. If the
command is intended for the GNE itself, it executes the
command on itself.

Page 30 of 43
8.0 Delayed Activation
Delayed activation is an intrinsic feature of TL1 that helps you to execute commands
automatically at predefined date/time. This article speaks about this feature in detail.

8.1 Need for Delayed Activation

For service maintenance and performance analysis, operators run huge tasks in the NE,
during lean hours. Provisioning thousand subscribers at a time is a good example for such
tasks. The delayed activation feature comes handy in such situations. It allows operators
to specify the date & time of execution in the command. Hence, operators need not sit
back for long hours and send all those commands. Instead, they can send commands for
automatic execution by specifying the date & time. And the NE executes the commands at
the specified date/time without requiring a human operator.

8.2 How delayed activation works

NEs store the TL1 commands (only those with delayed activation) in a message pending
buffer. The agent executes these commands at the specified date/time (date/time is
specified in each command). It also sends a response message on completion of the
operation.

8.3 Delayed activation parameters

[ON=] - ON represents the ORDER NUMBER. It is a numeric value assigned by you. The
NE to internally identify the delayed input message uses this number.
[DATE=] - DATE represents the exact date at which the delayed activation should occur.
It takes the following format <yy>- <mm > - <dd>
[TIME=] - TIME represents the exact time at which the delayed activation should occur. It
takes the following format: <hh> - <mm> - <ss>

Page 31 of 43
8.4 How to set the delayed activation parameters in a TL1
command

You have to specify the three delayed activation parameters in the general block.

Syntax of TL1 command:

<command code>: <TID>: <AID>:< CTAG>: <general block>:<payload
block>;

Delayed activation parameters can be specified in the general block as shown below:
Generalblock ::= <ON>,<DATE>,<TIME>,<CF>,<INDRTRV>

Example:

The following command ENT-CRS-STS1:TID:STS-3-2,STS-4-3:44:1, ,, : ; creates a

cross connect between two channels, STS-3-2 and STS-4-3. To set the delayed activation
parameters for this command, refer the table below

Delayed Activation
Command
at
23:00 hrs ENT-CRS-STS1:TID:STS-3-2,STS-4-3:44:210198, , 23-00-00, :
same day ;
ENT-CRS-STS1:TID:STS-3-2,STS-4-3:44:210198,02-12-06 , , :
on dec 06, 2002
;
23:00 hrs ENT-CRS-STS1:TID:STS-3-2,STS-4-3:44:210198,02-12-06,23-
on dec06th2002 00-00, : ;

where, 210198 indicates ORDER NUMBER, 23:00:00 indicates time, 02-12-06 indicates
date.

8.5 How to retrieve pending commands

To retrieve the TL1 commands with delayed activation , which are stored in the NE, the
following command can be used RTRV-DA::[ALL|ORDNUM]:<ctag>::TTYPE
,TTIMEGE, TTIMELE;
The NE will retrieve all the pending delayed activation commands if you specify ALL in the
retrieve message. To retrieve specific commands from the NE specify the ORDER NUMBER
of those commands in the retrieve message. After retrieval of the commands, you can
make necessary changes in that command and re-send if necessary.

8.6 How to activate pending commands

You can activate a pending command manually by sending a TL1 command. The
command for activating the pending messages takes the following format. ACT-
DA::[ALL|ORDNUM]:<ctag>::;
By specifying ALL you activate all the pending commands. To activate specific pending
commands, specify the exact ORDER NUMBER of the commands.

Page 32 of 43
8.7 How to cancel pending commands

You can delete a pending command using the following command

CANC-DA::[ALL|ORDNUM]:<ctag>::; By specifying ALL you delete all the pending
commands. To delete specific commands, specify the ORDER NUMBER of the commands

Page 33 of 43
9.0 Security

In networked environments, the chances for security breaches are always high.
Successful security breaches can affect the network’s performance and degrade the
quality of service. In high quality telecommunication networks, poor performance would
result in a dissatisfied user. This is not acceptable in today’s competitive world. Customer
retention is key to business success. Some of the bad effects of intended security
breaches include service thefts, disclosure of confidential information, collapse of the
entire system etc. These are the worst nightmares for service providers. An immaculate
security system becomes indispensable for anybody offering service over his networks.

9.1 Telcordia's view on security

GR 815 proposes the generic security features required of a total Network Element -
Network System (NE/NS) environment. It defines the baseline security requirements and
is not specific to any particular NE/NS.

TR 835 proposes the message structures and data elements for NE/NS security
administration. It specifies five types of security views for implementing system
access control and resource access control. It also defines set of commands for
manipulating all the security view data.

5 security views specified in TR 835

User security view: Contains system access control parameters such as

user name, password, password aging, privilege, etc. NE uses this data to
authenticate a user when he tries to establish a session with the NE.

Channel security view: Contains channel related security parameters such

as channel name, privilege, time-out interval, etc.

Command security view: Contains command access control parameters

such as command name and privilege associated with all operation related
commands.

Operations parameter related security view: Contains restrictions on the

accessibility of records (rows) and fields (column) of an operations-related
database.

Resource-related security view: Contains the resource access control

parameters such as resource name and privilege associated with all
operations-related resources such as executable programs that may not
provide database type "view".

Page 34 of 43
9.2 Implementing Security in TL1

The following are the key challenges faced in TL1 security administration.

1. User Authentication.
2. Restricting the authenticated users from using privileged commands.
3. Restricting the authenticated users from accessing specific resources in the NE.
4. Restricting the authenticated users from accessing privileged data from the data
tables.
5. Implementing security over the various channels through which the session is
established.
6. Keeping track of all the security-related events that happen in the network.

TL1 agent plays a major role in security. It receives all the TL1 commands and serves as
the single point of communication. You have to configure the agent for implementing
security in the device. Sending proper commands to the agent and thereby storing right
information in the NE can easily deal with all the above-mentioned key challenges. The
agent validates the commands with the help of data stored in the NE. It can execute or
reject the commands based on the validation output.

9.2.1 Authenticating the Users

You can configure the agent and store authorized usernames and passwords in the NE
[refer user security view in TR-835]. When users login with their username-password, the
system access control (authentication mechanism) authorizes the establishment of
session. NE uses the data stored in the user security view for validating the user name-
password.

The input message for entering new user details into the user security view takes the
following format.
ENT-USER-SECU ::<UID>:<CTag>: PID,CID,UAP :
PCND,PCNN,POINT,UOUT,LSTOILIST;
where, PID,CID, and UAP are position defined and their values have to be entered in that
order. The next list is name defined and can be entered in any sequence provided the
right values are assigned to the appropriate parameters.

Example : The following command creates a new user "user1" with user security
parameter values shown in it.
ENT-USER-SECU::user1:13::user1,TCP,2:56,8,4,10,87,file;

Other commands related to user security view

ED-USER-SECU: For editing existing user details.
DLT-USER-SECU :For deleting an user. (session will not be established for
this user)
INH-USER-SECU: For inhibiting or disabling an existing user without deleting
the user account.
ALW-USER-SECU : For allowing a user ID which has been inhibited earlier.
CANC-USER-SECU: For terminating a user session.

Page 35 of 43
9.2.2 Restricting Users from Using Privileged Commands

You can configure the agent to store authorized commands for every user in the NE [refer
command security view in TR-835]. When users send commands, the command access
control mechanism authorizes the commands. NE uses the data stored in the command
security view for this purpose. The command is either executed or rejected based on the
output of the validation.

The input message for entering security parameters associated with a command takes the
following format.
ENT-CMD-SECU:<TID>:<AID>:<CTag>: <GB> :CAP;

Example

The following command enters the security parameters for the command get-sm-msgda
in the command security view. ENT-CMD-SECU::get-sm-msgda:11::1&2;

Other commands related to command security view

ED-CMD-SECU: For editing the security parameter values of a command.
DEL-CMD-SECU: For deleting the security parameters associated with a
command.
RTRV-CMD-SECU: For retrieving the details of any command.

9.2.3. Restricting Users from Accessing Privileged Resources

A device may comprise of many entities such as ports, database tables etc. Access to
certain entities should be restricted for security reasons. You can configure the agent to
store a list of authorized resources for every user in the NE [refer resource related
security view in TR-835]. When the agent receives a command, it compares the
equipment ID of the command with the data stored in the table. The command is either
executed or rejected based on the output of the validation.

The input command for storing security parameters associated with the resources takes
the following format.
ENT-RSC-SECU:<TID>:<AID>: <CTag>:<GB>:RAP;

Example
ENT-RSC-SECU::device1:23::2;

Other commands related to resource-related security view

ED-RSC-SECU: For editing the security parameters associated with resources
in the NE.
DLT-RSC-SECU: For deleting the security parameters associated with
resources in the NE.
RTRV-RSC-SECU: For retrieving the details of any resource available in the
resource-related security view.

Page 36 of 43
9.2.4 Restricting Users from Accessing Data from Tables

NE stores all the information in data tables. To prevent users from accessing high
privileged data, you have to configure the agent and enable it to store the permissible
data for every user. [refer operations parameter related security view in TR-835]. When
the agent receives a command, it validates the requested data against the data stored in
the operations parameter related security view. The NE executes the command based on
the output of the validation.

The input command for storing security parameters in the operations parameter related
security view takes the following format.
ENT-SECU:<TID>:<AID>: <CTag>:<GB>:a,RCI:FAP ;
where, "a" is the position-defined parameter that specifies the view. RCI is a position-
defined list of Record Control Identifier(s) authorized to access the AID. FAP is a
keyword-defined parameter block that may contain any keyword that specifies any field
(i.e., column) of the view specified by the parameter "a".

Example
ENT-SECU::1:6::adiskTable,TCP:adiskCapacity=2;

Other commands related to operations parameter related security view

ED-SECU: For editing the security parameters associated with the fields of a
record(s) in a user implemented view (e.g., Line View, Trunk View).
DLT-SECU: For deleting any security parameters associated with the fields of
a record(s) in a user implemented view (e.g., Line View, Trunk View).

9.2.5 Channel Level Security

It is true that a session is required to communicate with an NE. Channel refers to the
session or the transmission line. A channel may be of any protocol such as such as
TCP/IP, EOC, RS232, and X2.5. You can configure NEs for the following, with respect to
channel security. 1) How many incorrect login attempts can be tolerated, 2) How long
should the channel be locked out if the incorrect login attempt exceeds the limit, 3) What
should be the time-out period for a channel. (Meaning, if the channel is idle beyond the
time-out period, then the channel is closed.)

The input command for storing channel-related security parameters in the channel
security view takes the following format.
ENT-CID-SECU : <TID> : <CID>: <CTag>:<GB>:CHAP:DURAL,MXINV,TMOUT;
where, CHAP is a position defined parameter. DURAL, MXINV, TMOUT are name defined
and can be entered in any sequence provided the right values are assigned to the
appropriate parameters.

Example
The following command adds a new channel "craft " to the channel security view.
ENT-CID-SECU::craft:10::2:5,00-13-23,26;

Other commands related to operations parameter related security view

Page 37 of 43
ED-CID-SECU: For editing security parameters values associated with a
channel identifier in the channel security view.
DLT-CID-SECU: For deleting security parameter values of any channel
identifier.
CANC-CID-SECU: For terminating a session which is ongoing with the NE over
a channel ID.
RTRV-CID-SECU: For retrieving values of security parameters associated with
a channel identifier.

9.2.6 Logging the Security Events:

Logging refers to keeping track of the events that happen in the network. The security
system should record security-related events such as invalid login attempts, unauthorized
attempts to access resources, etc., in the security log. Security log is a tool for security
audit. Network administrators can infer more from the security logs and security audit.
Security logging system should be capable of sending event notification to the system
administrator.

9.3 Building TL1 Agent from Security point of view

If you are an equipment vendor aspiring to build the right TL1 agent for your NE, please
check out whether the tool, which you use to build your agent, supports the requirements
as specified in the Telcordia's TR 835. Building an agent confirming to the standards will
help you implement a more reliable security implementation. If you wish to sell your
equipment to the ILECs, the conformance to Telcordia's requirements become an added
advantage for your devices and have more probability of getting through the integration
process successfully

Page 38 of 43
10.0 TL1 and OSMINE certification
Equipment vendors aspiring to sell their equipments to ILECs should be aware that
supporting TL1 in itself is not a panacea. An important milestone they have to pass is
OSMINE compliance to ensure that their equipment can reliably interoperate with existing
Telcordia OSSs in the targeted service provider network(s). OSMINE is a service offered
by Telcordia and can cost NE vendors well over a Million dollars and take over a year to
complete.

OSMINE comes as an unwelcome surprise for some, especially for those who come from
the IP (data) domain. Considering the fact that successful completion of OSMINE is just a
stepping-stone to getting access to the golden ring of ILEC market, the associated
opportunity cost is pretty high. During the CLEC heyday, it was not uncommon for NE
vendors to forego the OSMINE efforts (it is worthwhile mentioning some were not even
aware of such a process) in lieu of pursuing the growing CLEC market. However, since the
collapse of the CLECs, OSMINE is becoming a requirement to survive.

During 2001, established NE vendors such as Cisco, Ciena, Fujitsu, Lucent, Tellabs, and
Nortel made significant investments on the OSMINE front. The total investment from
these companies alone was over a 100M. Startups such as Metro-optix, Coriolis Networks,
Astral Point (now a part of Alcatel) have embarked on OSMINE as well. Many others are in
the process.

10.1 Key Benefits of OSMINE

• OSMINE ensures multivendor interoperability and easy integration of provisioning

and other OSS in use at local exchange carriers.
• It enables the NE to meet the flow-through requirements specified by service
providers.
• Integration of NE with embedded OSSs becomes much easier when the product is
deployed.
• NEs have greater marketability and salability in the ILEC market.

10.2 Preparing Yourself for OSMINE Certification

Being an equipment vendor, you have to submit a few things along with your NE or EMS
for OSMINE certification. The three major steps involved before submitting your NE are
given below

10.2.1. Choosing the Telcordia's OSS for which integration of NE is required.

You need to decide on which OSS you NE should be interoperable. This depends on the
application of your equipment. Telcordia has the following OSSs for management.

SERVICE PROVISIONING AND ACTIVATION SUITE

Telcordia TIRKS®
Telcordia Network Configuration Manager (NCON)
Telcordia Transport Element Activation Manager (TEMS)

Page 39 of 43
 Telcordia LFACS
Telcordia SWITCH®
Telcordia Customer Network Manager (FLEXCOM)

SERVICE ASSURANCE SUITE

Fault Management
Telcordia NMA® System (NMA)
Telcordia Surveillance Manager (SM)

PERFORMANCE MANAGEMENT
Telcordia Network Performance Monitor (NPM)
Telcordia Service Level Manager (SLM)
Telcordia Network Capacity Manager (NCM)

10.2.2 Providing complete description of NE

You need to provide extensive documentation on the NE. It will be more like a user
manual of the device.

10.2.3. Filling out NEIR form.

You have to fill the NEIR form ( Network Element Information Request) and submit along
with the NE. This document will give a complete understanding of the NE to the people in
Telcordia. The NEIR document requires the following information

• Physical layout
• Hardware configuration
• Network topology
• Protection scheme
• AID modeling
• CLEI code
• Supported input messages and autonomous messages.

10.3 How easy is it?

Though OSMINE process is expensive and time intensive, proper planning and
implementation of TL1 interface makes OSMINE process much easier. For more details
refer SR-683, Process Description of Operations Systems Modifications for the Integration
of Network Elements (OSMINE) and also visit www.telcordia.com

Page 40 of 43
11.0 Glossary
Acknowledgment
An acknowledgment is a short reply from the NE indicating that an input command
message is being acted upon or has been immediately rejected. The essential purpose of
an acknowledgment is to assure a user that a command that takes a long time to execute
has been received by the NE.

AID - Access Identifier

AID is one of the blocks in the Staging Parameter Block of an input message .The Access
IDentifier (AID) block normally consists of one or more parameters that uniquely identify
the entity, within the target NE, to be acted upon by the input message.

ATAG - Autonomous Tag

ATAG is one of parameter in an autonomous message . It is assigned by the NE, must be
sequential, and must be included in all autonomously generated messages. It allows an
OS to correlate spontaneous outputs triggered by a common problem and also to identify
whether the OS has failed to receive any output.

Autonomous message
An autonomous message is an unsolicited message from the NE to the appropriate OS for
reporting any event occurred in an NE.

Circuit
A circuit is a connection between two points used to provide a service to the customer.

CLEC - Competitive Local Exchange Carrier

A business authorized by the Telecommunications Act of 1996 that can deliver alternative
dial-tone and other services using an incumbent carrier's equipment.

CLEI - Common Language Equipment Identifier.

Common Language Equipment Identifier, unique code assigned by Bellcore for label on
each telecom device.

CTAG - Correlation Tag

CTAG is one of the blocks in the Staging Parameter Block of an input message .It
contains one position defined parameter to serve as a means of correlating an input
command with its associated output response.

Delayed Activation
Delay Activation is one of the features available in TL1. Delay Activation is a function
whereby an input message may be stored in a Message
Pending buffer at the NE for final execution at some later time, either automatically or by
a subsequent message from the OS.

Digital Cross Connect(DCS)

Digital cross connect or DCS is a device that switches channel between two or more
transmission facilities.The types of network cross connections managed by a DCS can
range from STSx to DSx.

DS-N
Digital signal-N is a term for the series of standard digital transmission rate. DS-

Page 41 of 43
0=64kbps, DS-1=T-1=1.544 mpbs.

Facility
A facility is a transmission line or path. For example, STS1 is a facility.

GNE - Gateway NE
It is the NE that routes the input message from the manager to the appropriate NE.

ILEC - Incumbent Local Exchange Carrier

The companies that were in business before the CLECs. The highest-visibility ILECs are
the regional Bell operating companies, or RBOCs.

Input message
An input command message is a message from an OS or other source to an NE. The
message requests the NE to perform some operations-related action.

NE - Network Element
It is an equipment(node) in the network. For example, ADM (Add Drop Multiplexer ) is an
NE.

OC-N
Optical Carrier, Level-N in SONET. OC-1 = 51.84 mpbs.

OSMINE - Operations System Modifications for the Integration of Network

Element.
OSMINE Services is the integration process, which makes Telcordia OSSs and equipment
providers Network Elements (NEs) compatible. The services provide NEs supported in
various Telcordia OSSs, which are operational in service provider's networks .

OSS - Operations Support System

Operations Support System is a network management system used by telecom service
provider o to provision, monitor, and maintain facilities.

Output response
An output response message is a detailed reply (or set of replies) to an input command
message. It contains information indicating whether the
command was executed successfully and any data needs to be returned to the OS/user.

RBOC - Regional Bell Operating Company

The regional telephone companies that resulted from the break-up of AT&T. Eighty
percent of North American service providers are RBOC.

SONET - Synchronous Optical Network

A set of standards for optical transport.

STS -N
Synchronous Transport Signal, level N; electrical equivalent of OC-N. STS-1= 51.84
mbps.

TID - Target Identifier

TID is one of component in input message. It identifies the NE to which message to be
routed. Gateway NE will make use of TID to route TL1 messages.

Page 42 of 43
TL1 – Transaction Language -1
Transaction Language 1 (TL1) is an ASCII or man-machine management protocol used
for managing Telecommunication networks. It is defined by Telcordia (previously known
as Bellcore).

T-N
The T-carrier system is digital, using pulse code modulation and time-division multiplexing
introduced by Bell Systems.
T-1 = 1.544 mpbs , T-3=44.736 mpbs.

Page 43 of 43