3FE-23235-4223-DFZZA-01P01-CRAFT Language For Application Messages

GENERIC REQUIREMENTS
GR–831–CORE
ISSUE 1, NOVEMBER 1996
OTGR SECTION 12.1
Comments Requested
(See Preface)
Operations Application
Messages - Language for
Messages
(A Module of OTGR, FR-439)
GR–831–CORE
ISSUE 1, NOVEMBER 1996
Comments Requested
(See Preface)
Messages - Language for
Messages
(A Module of OTGR, FR-439)
Language for Operations Application Messages GR–831–CORE
Copyright Page Issue 1, November 1996
All trademarks and other marks are the property of their respective companies.
This document, GR–831–CORE, Issue 1, November 1996 replaces:
TR-NWT-000831, Issue 3 and Revision 1.
For ordering information, see the References section of this document.
This document may not be reproduced without the express written permission of Bellcore
and any reproduction without written authorization is an infringement of Bellcore’s
copyright.
Copyright  1996 Bellcore.

All rights reserved.
Project funding year: 1996.
ii
GR–831–CORE Language for Operations Application Messages
Issue 1, November 1996 Notice of Disclaimer
NOTICE OF DISCLAIMER
This Generic Requirements document is published by Bell Communications Research, Inc.

(Bellcore) to inform the industry of Bellcore's preliminary view of proposed generic
requirements for Operations Application Messages - Language for Operations Application
Messages, and to solicit industry comment thereon. These Generic Requirements are
subject to review and change, and superseding Generic Requirements regarding this subject
matter may differ extensively in content and format.
Bellcore reserves the right to revise this document for any reason, including but not limited
to, conformity with standards promulgated by various agencies, utilization of advances in
the state of the technical arts, or the reflection of changes in the design of any equipment,
techniques, or procedures described or referred to herein.
LOCAL CONDITIONS MAY RESULT IN A NEED FOR ADDITIONAL
PROFESSIONAL INVESTIGATIONS, MODIFICATIONS, OR SAFEGUARDS TO
MEET SITE, EQUIPMENT, ENVIRONMENTAL SAFETY OR REGION-SPECIFIC
REQUIREMENTS. IN NO EVENT IS THIS INFORMATION INTENDED TO
REPLACE FEDERAL, STATE, LOCAL, OR OTHER APPLICABLE CODES, LAWS,
OR REGULATIONS. SPECIFIC APPLICATIONS WILL CONTAIN VARIABLES
UNKNOWN TO OR BEYOND THE CONTROL OF BELLCORE. AS A RESULT,
BELLCORE CANNOT WARRANT THAT THE APPLICATION OF THIS
INFORMATION WILL PRODUCE THE TECHNICAL RESULT OR SAFETY
ORIGINALLY INTENDED.
BELLCORE MAKES NO REPRESENTATION OR WARRANTY, EXPRESS OR
IMPLIED, WITH RESPECT TO THE SUFFICIENCY, ACCURACY, OR UTILITY OF
ANY INFORMATION OR OPINION CONTAINED HEREIN. BELLCORE
EXPRESSLY ADVISES THAT ANY USE OF OR RELIANCE UPON SAID
INFORMATION OR OPINION IS AT THE RISK OF THE USER AND THAT
BELLCORE SHALL NOT BE LIABLE FOR ANY DAMAGE OR INJURY INCURRED
BY ANY PERSON ARISING OUT OF THE SUFFICIENCY, ACCURACY, OR
UTILITY OF ANY INFORMATION OR OPINION CONTAINED HEREIN.
This document is not to be construed as a suggestion to any manufacturer to modify or
change any of its products, nor does this document represent any commitment by Bellcore
or any Bellcore Client Company (BCC)1 to purchase any product, whether or not it
provides the described characteristics.
1. Bellcore Client Company (BCC), as used in this document, means any divested Bell Operating
Company, or its successor, or any regional affiliate thereof.
iii
Notice of Disclaimer Issue 1, November 1996
Readers are specifically advised that each BCC may have requirements or specifications
different from the generic descriptions herein. Therefore, any vendors or manufacturers of
products should communicate directly with a BCC to ascertain that company’s needs,
specifications and actual requirements.
Nothing contained herein shall be construed as conferring by implication, estoppel or
otherwise any license or right under any patent, whether or not the use of any information
herein necessarily employs an invention of any existing or later issued patent.
Bellcore does not recommend products and nothing contained herein is intended as a
recommendation of any product to anyone.
If further information regarding technical content is required, please contact:
Thomas F. Brantle
Network Management Foundation and Integration
Bellcore
331 Newman Springs Road, Room 3B-200
Red Bank, NJ 07701-5699
(908) 758-5562
For general information about this or any other Bellcore documents, please contact:
Bellcore Customer Service
8 Corporate Place
Piscataway, New Jersey 08854-4156
1-800-521-CORE (2673) (USA and Canada)
(908) 699-5800 (all others)
(908) 336-2559 (FAX)
iv
Issue 1, November 1996 OTGR Contents and Ordering Information
OTGR Contents and Ordering Information
OTGR Contents
FR-439, 1996 Edition (Sheet 1 of 4)
Document Document Issue/ Publication
Vol. Subset Sec. Number Title Rev. Date
[No Subset] 1.0 GR-471-CORE Introduction Issue 2 January 1995
FR-472 2.1 GR-472-CORE Network Element Issue 2 November 1996
Configuration
Network Element
Management
(NE) Memory
1
Administration 2.3 TR-NWT-000815 Network Element Issue 2 December 1992
Operations Security
2.4 GR-2934-CORE High-Speed Access for Issue 1 September 1996
Switch Network Element
Operations: Software
Management
FR-473 3.0 TR-TSY-000473 Network Maintenance: Issue 3 November 1989
Common
Network
Maintenance: 3.1 TR-TSY-000816 ISDN Basic Rate Access Issue 1 November 1989
Common Portable Test Set
2
[No Subset] 4.0 TR-NWT-000474 Network Maintenance: Issue 4 December 1993
Alarm and Control Network
Element
FR-475 5.1 GR-820-CORE Generic Digital Issue 1 November 1994
Transmission Surveillance
Network
Maintenance: 5.2 TR-TSY-000821 Additional Transport and Issue 1 June 1990
3
Transport Transport-Based Rev. 1 December 1991
Surveillance Surveillance Rev. 2 August 1993
Rev. 3 September 1994
v
OTGR Contents and Ordering Information Issue 1, November 1996
OTGR Contents
6.1 GR-818-CORE Generic Test Architecture Issue 1 December 1995
6.2 GR-819-CORE Special Services (SS) and Issue 1 December 1995
SS-Like Networks
6.3 GR-822-CORE Switched Circuits and Issue 1 December 1995
Public Packet Switched
Network (PPSN)
6.4 GR-823-CORE Integrated Services Digital Issue 1 December 1995
Network (ISDN)
FR-476
6.5 GR-1465-CORE Automatic Board-to-Board Issue 1 December 1995
3 Network Testing and DLC Cutover
Maintenance: Testing
Access
and 6.6 GR-1309-CORE TSC/RTU and OTAU Issue 1 June 1995
Testing Requirements for Remote
Optical Fiber Testing
6.7 GR-844-CORE TSC/RTU Generic Issue 2 November 1995
Requirements for Metallic
Loop Testing
6.8 GR-1402-CORE DS3 HCDS TSC/RTU and Issue 1 December 1995
DTAU Functional
Requirements
7.0 GR-477-CORE Network Traffic Issue 2 December 1995
Management
4 8.0 GR-478-CORE Measurements and Data Issue 2 December 1995
[No Subset]
Generation
9.0 Section reserved for future use.
FR-480 10.1 TR-TSY-000824 User System Access Issue 2 February 1988
User System 10.A TR-TSY-000825 User System Language Issue 2 February 1988
Interface (USL)
10.2 GR-826-CORE User Interface Generic Issue 1 June 1994
Requirements
11.0 TR-TSY-000481 Generic Operations Issue 4 June 1990
5 Interface: Overview Rev. 1 March 1991
FR-481 11.1 TR-TSY-000827 Non-OSI Communications Issue 1 November 1988
Architecture
Generic Operations
Interface 11.2 GR-828-CORE OSI Communication Issue 1 September 1994
Architecture Rev. 2 October 1996
11.3 TR-TSY-000829 Embedded Operations Issue 1 November 1989
Channels Rev. 1 September 1996
11.4 TR-TSY-000830 Operations Interworking Issue 1 June 1990
vi
OTGR Contents
12.0 GR-811-CORE TL1 Messages Index Issue 2 February 1996
6 12.1 GR-831-CORE Language for Operations Issue 1 November 1996
Application Messages
7 12.2 GR-199-CORE Memory Administration Issue 2 November 1996
Messages
8 12.3 GR-833-CORE Network Maintenance: Issue 2 November 1996
Network Element and
Transport Surveillance
FR-482
Messages
Operations
9 12.4 GR-834-CORE Network Maintenance: Issue 2 November 1996
Application Access and Testing
Messages Messages
12.5 TR-NWT-000835 Network Element Security Issue 3 January 1993
Parameter Administration
Messages
10
12.6 GR-202-CORE Network Maintenance: Issue 2 November 1995
Loop Testing Messages
and the OS/TSC Interface
[No Subset] 13.0 TR-TSY-000483 Embedded Operations Issue 2 February 1988
Interfaces
FR-484 14.1 TR-TSY-000454 Supplier Documentation Issue 1 July 1988
11
for Network Elements Sup. 1 January 1994
Documentation,
Training, and 14.2 GR-839-CORE Supplier-Provided Training Issue 1 July 1996
Supplier Support Generic Requirements
14.3 TR-NWT-000840 Supplier Support Generic Issue 1 December 1991
Requirements (SSGR)
vii
OTGR Contents
15.1 Section reserved for future use.
GR-836-CORE Information Model Issue 2 September 1996
Overview: Transport
Configuration and
Surveillance for Network
12 Elements
15.2 GR-836-IMD Information Model Details: Issue 2 September 1996
Transport Configuration
FR-801 and Surveillance for
Generic Operations Network Elements
Interfaces Using
OSI Tools
13 15.3 GR-376-CORE Network Data Collection Issue 2 September 1996
(NDC)
15.4 GR-495-CORE Network Traffic Issue 2 September 1996
Management
15.5 GR-1469-CORE Generic Requirements on Issue 1 September 1994
Security for OSI-Based
14
Telecommunications
Management Network
Interfaces
15.6 GR-1031-CORE Test Access Management Issue 1 February 1996
Note:
This document is a module of the Operations Technology Generic Requirements (OTGR),
FR-439. The OTGR can be ordered as a complete set, as sections, or as individual modules.
• If the entire set is ordered, select FR-439, and all 15 sections with their subordinate
modules will be delivered.
• If a specific section is required, e.g., Section 12, Operations Application Messages,
select FR-482, and all seven modules of this section will be delivered.
• If one module is requested, e.g., Section 12.1, Language for Operations Application
Messages, select GR-831-CORE, and this single module will be delivered.
viii
Ordering Information
To order modules, sections, or the entire OTGR:
• Public should contact:
8 Corporate Place, Room 3A-184
1-800-521-CORE (2673) (USA and Canada)
(908) 699-5800 (all others)
(908) 336-2559 (FAX)
• BCC personnel should contact their company document coordinator
• Bellcore employees should call the Bellcore Document Hotline: (908) 699-5802.
Any Questions?
If you have any questions concerning the technical content or structure of the OTGR, please
call the OTGR Hotline at (908) 758-2232.
ix
x
Issue 1, November 1996 Contents
Operations Application Messages - Language for

Operations Application Messages
Contents Contents
Preface ...................................................................................................................Preface–1
1. Introduction ...............................................................................................................1–1
1.1 Transaction Language 1 (TL1)........................................................................1–1
1.2 Organization of Document ..............................................................................1–2
1.3 TL1 Historical Perspective..............................................................................1–3
1.4 Requirements Terminology.............................................................................1–5
1.5 Requirement Labeling Conventions................................................................1–5
1.6 Requirements Statement..................................................................................1–5
2. TL1 Message Specification.......................................................................................2–1
2.1 TL1 General Message Syntax .........................................................................2–1
2.1.1 Input versus Output ............................................................................2–2
2.2 Characters and Information Units ...................................................................2–3
2.2.1 Identifiers ...........................................................................................2–3
2.2.2 Symbolic Names ................................................................................2–3
2.2.3 Decimal Numbers...............................................................................2–3
2.2.4 Nondecimal Numbers.........................................................................2–4
2.2.5 Text Strings ........................................................................................2–4
2.2.6 Arithmetic Expressions ......................................................................2–4
2.2.7 Keyed Numbers..................................................................................2–4
2.2.8 Numeric String ...................................................................................2–5
2.2.9 Integer ................................................................................................2–5
2.2.10 Inner String.........................................................................................2–5
2.3 Parameter Block Syntax ..................................................................................2–5
2.3.1 Position-Defined Parameters..............................................................2–5
2.3.2 Name-Defined Parameters .................................................................2–6
2.3.3 Name/Position Syntax Conflicts ........................................................2–6
2.4 Boolean Flag Parameters.................................................................................2–7
2.5 Defining a Parameter Block ............................................................................2–7
2.5.1 Parameter Specification .....................................................................2–7
2.5.2 Block Type Selection .........................................................................2–8
2.6 Defining Parameter Values .............................................................................2–8
2.6.1 Compound Arguments .......................................................................2–9
2.6.2 Grouping of Arguments .....................................................................2–9
2.7 Implementation Issues...................................................................................2–10
2.7.1 Correction Characters and Comments .............................................2–10
2.7.2 Restrictions on Nondecimal Numbers and Arithmetic Expressions 2–10
xi
Contents Issue 1, November 1996
2.7.3 Case Sensitivity................................................................................2–11

2.7.3.1 Command Codes and Parameter Names..........................2–11
2.7.3.2 Parameter Values .............................................................2–11
2.7.4 Resolving the Increment Ambiguity ................................................2–12
3. Input Command Message Structure ..........................................................................3–1
3.1 General Format................................................................................................3–1
3.2 Command Code...............................................................................................3–1
3.2.1 Verb....................................................................................................3–1
3.2.2 Modifiers ............................................................................................3–1
3.3 Staging Parameter Blocks ...............................................................................3–2
3.3.1 Target Identifier (TID) Block.............................................................3–3
3.3.2 Access Identifier (AID) Block ...........................................................3–4
3.3.2.1 Circuit and Equipment Access...........................................3–4
3.3.2.2 Administrative View Access .............................................3–5
3.3.2.3 Access by Alias Values......................................................3–6
3.3.2.4 Object Identifier Context Switching ..................................3–7
3.3.3 Correlation Tag (CTAG) Block .........................................................3–7
3.3.4 General Block (GB) ...........................................................................3–8
3.3.4.1 Delay Activation ................................................................3–8
3.3.4.2 Contingency Flag...............................................................3–9
3.3.4.3 Indirect Data Retrieval Indicator .....................................3–10
3.4 Message Payload ...........................................................................................3–12
3.4.1 IntraBlock Type Procedure ..............................................................3–12
4. Acknowledgments.....................................................................................................4–1
4.1 General Format................................................................................................4–1
4.2 In Progress (IP) and Printout Follows (PF).....................................................4–1
4.3 All Right (OK) ................................................................................................4–2
4.4 No Acknowledgment (NA) .............................................................................4–2
4.5 No Good (NG).................................................................................................4–2
4.6 Repeat Later (RL)............................................................................................4–3
5. Output Response Message Structure.........................................................................5–1
5.1 General Format................................................................................................5–1
5.2 Header .............................................................................................................5–1
5.3 Response Identification ...................................................................................5–2
5.4 Text Block .......................................................................................................5–3
5.5 Terminator.......................................................................................................5–4
5.6 Examples of Output Response Message .........................................................5–5
6. Autonomous Messages .............................................................................................6–1
6.1 General Format................................................................................................6–1
6.2 Header (<header>) ..........................................................................................6–2
6.3 Identification of Output (<auto id>)................................................................6–2
6.3.1 Alarm Code (<almcde>) ....................................................................6–2
xii
Issue 1, November 1996 Contents
6.3.2 Autonomously Generated Correlation Tag (<atag>) .........................6–3

6.3.3 <verb>[^<modifier>[^<modifier>]] ..................................................6–4
6.4 Text Block ( [<text block>] ) ..........................................................................6–4
6.5 Terminator.......................................................................................................6–4
6.6 Examples of Autonomous Messages...............................................................6–5
7. Implementation Guidelines .......................................................................................7–1
7.1 Input ................................................................................................................7–1
7.2 Output..............................................................................................................7–1
7.3 Target Identifier (TID) and Source Identifier (SID) .......................................7–2
Appendix A: TL1 Grammar .......................................................................... Appendix A–1
A.1 Introduction ................................................................................... Appendix A–1
A.2 Contents......................................................................................... Appendix A–1
A.3 Character Set/Classes .................................................................... Appendix A–1
A.4 Information Units .......................................................................... Appendix A–3
A.5 Parameter Value Complexes ......................................................... Appendix A–4
A.6 Input Messages.............................................................................. Appendix A–5
A.6.1 Command Code................................................................ Appendix A–5
A.6.2 Target Identifier ............................................................... Appendix A–5
A.6.3 Access Identifier............................................................... Appendix A–6
A.6.4 Correlation Tag ................................................................ Appendix A–6
A.6.5 General Block................................................................... Appendix A–6
A.6.6 Payload Block .................................................................. Appendix A–7
A.7 Output Messages ........................................................................... Appendix A–7
A.7.1 Acknowledgments............................................................ Appendix A–8
A.7.2 Output Response and Autonomous Messages ................. Appendix A–8
A.7.3 Response Identifier........................................................... Appendix A–8
A.7.4 Autonomous Messages..................................................... Appendix A–9
A.7.5 Text Blocks ...................................................................... Appendix A–9
A.8 Strings, Quotes, and Escape Sequences ...................................... Appendix A–11
Appendix B: TL1 Style Guide....................................................................... Appendix B–1
Appendix C: TL1 Message Verbs ................................................................. Appendix C–1
Appendix D: TL1 Error Codes ...................................................................... Appendix D–1
References ....................................................................................................... References–1
Glossary ...............................................................................................................Glossary–1
xiii
List of Figures Issue 1, November 1996
List of Figures Figures
Figure 1-1. TL1 Message Taxonomy/Classification ...................................................1–2
xiv
Issue 1, November 1996 List of Tables
List of Tables Tables
Table 2-1. Syntax Definitions ....................................................................................2–2

Table 3-1. Delayed Activation Truth Table ...............................................................3–9
Table A-1. Legal ASCII Character Set ..................................................... Appendix A–2
Table C-1. Command Verbs ..................................................................... Appendix C–1
Table D-1. General TL1 Error Codes ....................................................... Appendix D–1
xv
List of Tables Issue 1, November 1996
xvi
Issue 1, November 1996 Preface
Preface Preface
The following text describes the Bellcore generic requirements process in effect as of
February 7, 1996, that is applicable to this document. Process changes for certain future
generic requirements reflecting the procedures under the Telecommunications Act of 1996
are expected to be announced by Bellcore in its DIGEST of Technical Information as they
evolve.
Bellcore’s Interactive GR Process
Generic Requirements (GRs) provide Bellcore’s view of proposed generic criteria for
telecommunications equipment, systems, or services. GRs are available through a
subscription ordering process from Bellcore. A one-time subscription fee entitles the
subscriber to receive the baseline GR (GR–CORE) along with the Issues List Report (GR–
ILR) and revisions released until the entire package is reissued. Each baseline GR outlines
Bellcore's intended release plans. Bellcore is making the transition to the new GRs from the
former Framework Advisories (FAs), Technical Advisories (TAs), and Technical
References (TRs). Bellcore will identify the stage or phase of any particular release and the
level or expectation of any industry or subscriber interaction.
FA-TA-TR to GR
Bellcore GRs represent a change from the former generic requirements document releases
known as FAs, TAs, and TRs, which reflected a relative maturity level of the proposed
requirements. The new GR integrates those three versions into a single entity. When
appropriate, industry members will be invited to participate in the early development stage
of these requirements. Depending on the extent of early interactions, the first release of a
new GR may have fewer issues to be resolved than the “traditional TA or TR” because
many of the issues that normally would have surfaced during the Open Comment Period
would have been addressed, and possibly resolved, before release of the GR. Maturity level
and completeness of the individual requirements enumerated in the GR and the full GR
itself will be identified in the document's Preface, the Introduction, and throughout the
document as necessary. Terms such as early development, preliminary, or relatively mature
will communicate maturity level to the subscriber.
Comments and Issues List Report Mechanism
Bellcore encourages and welcomes nonproprietary comments on the content and

presentation of GR material and will accept subscribers' comments throughout the life of
the GR. Bellcore will review and respond directly to subscribers, and as appropriate, may
periodically compile issues derived from such comments or from technology changes,
Preface–1
Preface Issue 1, November 1996
along with status or proposed resolutions, and publish them in the form of a GR Issues List
Report (ILR). Bellcore will respond to all comments, whether directly to the submitter or
through the ILR.
In Bellcore’s view, not all comments submitted need become issues requiring subscriber/
industry review, nor may they be germane or suitable to Bellcore's proposed generic
requirements. The ILR is not intended to specifically identify comment submitters by name
or company. It reflects a distillation and compilation of all appropriate comments that
address specific technical issues having an impact on the requirements as originally
presented in the GR, and, that in Bellcore's view, need further subscriber/industry review.
The ILR may also contain suggested editorial or clarification changes or corrections.
The ILR will automatically be provided to all subscribers of this GR. It is intended to be
the means to convey information about the status of the technical requirements and to open
dialog on any proposed changes before such changes are finalized. Subscribers are
encouraged to comment after reviewing the ILR. When appropriate, significant changes or
additional material may also be released as revisions to the GR-CORE. The initial or
baseline GR-CORE, the most current ILR, and any published revisions constitute the most
up-to-date version of these proposed generic requirements. As necessary, the entire
package may be reissued to incorporate all changes. Notification will be released in the
Bellcore DIGEST announcing ILRs, revisions, or planned complete reissues.
GR–831–CORE Relative Maturity Level, Status, and Plans
The contents of this GR are in the mature development stage. Earlier editions of GR-831-
CORE have been published previously in TA/TR form (e.g., TR-NWT-000831, Issue 3,
July 1993, Revision 1, December 1993). GR-831-ILRs are potentially planned during
1997. These reports will contain ongoing issues resulting from supplier comments on this
GR.
Formatting Comments
To facilitate review of and response to your comments, Bellcore would appreciate your use
of the following format:
A. Identify the GR #, Issue #, and Date.
B. Identify comments by citing the corresponding section, paragraph, requirement, or
Issue ID number(s) used in the GR or in the ILR, and group comments within these
headers:
1. General/Overall Comments
2. Major Business Issues/Concerns
Preface–2
Issue 1, November 1996 Preface
3. Specific Technical Comments

4. Implementation Queries/Concerns
5. Administrative/Editorial Comments
6. Miscellaneous Comments.
C. Provide a contact person in your company for comment clarification.
Where and When to Submit Comments
While comments are welcome at any time, release of ILRs or revisions may depend on
either the extent and complexity of comments submitted and/or Bellcore’s planned
schedule for such releases. Bellcore plans to update this GR over the next year. To meet
this schedule, send your comments in writing by March 31, 1997.
Please send to:
Bellcore — GR–831–CORE
Thomas F. Brantle
331 Newman Springs Road, Room 3B-200
Red Bank, NJ 07701-5699
(908) 758-5562
Preface–3
Preface Issue 1, November 1996
Preface–4
Issue 1, November 1996 Introduction
1. Introduction
GR-831-CORE, OTGR Section 12.1: Operations Application Messages - Language for
Operations Application Messages, provides implementation level requirements for
Transaction Language 1 (TL1). TL1 is used in the input and output messages that pass
between Operations Systems (OSs) and Network Elements (NEs). Operations domains
such as surveillance, memory administration, and access and testing define and use TL1
messages to accomplish specific functions between the OS and the NE.
The remainder of this section includes
• An overview of TL1 (Section 1.1)
• The organization of this document (Section 1.2)
• A TL1 historical perspective (Section 1.3)
• Requirements terminology (Section 1.4)
• Requirements labeling conventions (Section 1.5)
• The GR-831-CORE requirements statement (Section 1.6).
1.1 Transaction Language 1 (TL1)
Transaction Language 1 (TL1) is defined for OS/NE (machine-to-machine) interfaces. TL1

corresponds to the User System Language (USL), which is the language for human-to-
machine interactions. USL is described in TR-TSY-000825. Use of closely related
languages for both the human and the OS interface should result in economy of design for
the NEs. Forming a link between the user interface and the OS interface is an important step
in ensuring similarity of function and messages in local and central operations.
Operations functions such as surveillance, memory administration, and access and testing
use short messages to cause specific actions at the NE. Transactions are the initiation,
communication, and execution of these actions. Many, but not all, of these transactions
require two-way interactive exchange of related messages. TL1 is defined by restricting the
features used in the message definitions and the form transmitted by each side of the OS/
NE interface. Specification of all aspects of messages used in such transactions, in
sufficient detail to ensure compatible connection of network equipment meeting the
specifications, is the purpose of TL1 and this GR. The scope of this document includes the
specification of a general syntax and commonly applied semantics for the TL1 OS/NE
interface.
These specifications impose rules of syntax, semantics, information structure, intermessage
context, and pragmatics to ensure uniform construction of TL1 messages. The TL1 generic
specification is an important step toward using the same message for the same function for
different types and suppliers of network equipment. Each TL1 message is expressed in
1–1
Introduction Issue 1, November 1996
American Standard Code for Information Interchange (ASCII) characters. Appropriate

information is also provided to help ensure that there are no gaps or inconsistencies with
the protocol specification.
Transaction Language 1 (TL1) specifies four types of operations application messages (see
Figure 1-1), as follows:
• Input Command Messages (Section 3)
• Acknowledgments (Section 4)
• Output Response Messages (Section 5)
• Autonomous Messages (Section 6).
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. 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 human user that a command that takes a long time to execute has been received by the
NE. 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 that needs to be returned to the OS/user. An autonomous message
is one generated by the NE either on a periodic timed basis or to report some unusual
occurrence.
MESSAGE
INPUT OUTPUT
COMMAND ACKNOWLEDGEMENT RESPONSE AUTONOMOUS

(Section 3) (Section 4) (Section 5) (Section 6)
Figure 1-1. TL1 Message Taxonomy/Classification
1.2 Organization of Document
This GR is organized as follows:

• Section 1, Introduction, provides introduction, definitions, overview, document
organization, and requirements statement.
1–2
• Section 2, TL1 Message Specification, defines the language structures, specification

characters, and information units (syntax and semantics) used in the input and output
messages that pass between an OS and NE.
• Section 3, Input Command Message Structure, describes the structure of a TL1 input
message and the functionality of its component parts.
• Section 4, Acknowledgments, describes the brief output message generated in response
to an input command.
• Section 5, Output Response Message Structure, describes the structure of a TL1 output
response message and the functionality of its component parts.
• Section 6, Autonomous Messages, describes messages that are sent from the NE to the
appropriate OS without having an explicit input message associated with it.
• Section 7, Implementation Guidelines, reviews a number of issues that a TL1
implementor must face in addition to syntax and semantics.
• Appendix A, TL1 Grammar, provides a rigorous definition of TL1 using Backus-Naur
Form (BNF).
• Appendix B, TL1 Style Guide, offers a framework for the presentation of TL1 message
format, but does not impose or alter in any way the semantics or syntax of messages.
• Appendix C, TL1 Message Verbs, summarizes operations command verbs that are
expected to meet all application needs.
• Appendix D, TL1 Error Codes, consolidates all valid operations error codes that are
used in the output response DENY message.
• References lists TL1 related references.
• Glossary lists TL1 related acronyms.
1.3 TL1 Historical Perspective
In 1984, following the divestiture of the Bell Operating Companies from the American
Telephone and Telegraph (AT&T) company, it was realized that, in order to provide an
environment in which products from many suppliers could interact within the
telecommunications network, a single operations interface must be defined to which all
suppliers could conform. That is, with a common operations interface, the proprietary
aspects of the many varieties of NEs making up the telecommunications network would be
hidden from the OSs deployed to manage the network. It was noted that the majority of the
operations functions use short message constructs, or Transactions, to initiate,
communicate, and cause execution of specific actions at some remote NE site. Many, but
not all, of these transactions require two-way interactive exchange of related messages.
1–3
Specification of all aspects of messages used in such transactions, in sufficient detail to

ensure compatible connection of equipment meeting the specifications, is called a
language. A language imposes rules of syntax, semantics, information structure,
intermessage context, and pragmatics to ensure uniform construction of messages. Since
standardization is an important step toward using the same message for the same function
for different types and suppliers of equipment, it was decided to adapt sections of the
CCITT* Recommendation Z.300 for use in a machine-to-machine environment. This
adaptation is called Transaction Language 1 (TL1) and syntactically corresponds to the
User System Language (USL), which is the language for human interactions described in
TR-TSY-000825. TL1/Z.300, thereby, conforms to the conventions that have been
formally defined by CCITT as the standard human-to-machine language structure for
telephone operations. It is currently in use by several manufacturers of NEs, both for
human-machine and machine-machine applications. Use of closely related languages for
both the human and the OS/NE interface should result in economy of design for the NEs.
The CCITT Z.300 Recommendations, because of their original intent for use in a human to
machine environment, prescribe a completely different syntax for input messages and
output responses. The syntax of the input messages is a string of ASCII characters in which
a subset of characters (i.e., punctuation characters) is reserved for exclusive and specific
use as delimiters within the messages. For example, data blocks within a message are
delimited by a colon (:); commas (,) delimit data elements within a data block; hyphens (-)
are used to delimit the parts of a compound data element; and a message is terminated
whenever a semicolon (;) appears in the message string.
The output response syntax, on the other hand, provides a display template for presentation
of the output information on the CRT screen of a human-user terminal. Hence, a space
character is the delimiter for fields on a CRT screen; a carriage return (<cr>) and line feed
(<lf>) character sequence delimit a display line; and the semicolon (;) determines the end
of the display. Except for the terminating function of the semicolon, the syntax of the input
and output messages can be completely different.
This non-symmetric characteristic between input and output messages was retained in TL1
to ensure maximum compatibility with USL, which shares the same syntax. Certain
extensions have been made to the output response syntax of TL1 to accommodate the
machine-to-machine environment, while maintaining compatibility with USL.
* CCITT has been changed to the International Telecommunication Union - Telecommunications

Standardization Sector (ITU-T).
1–4
1.4 Requirements Terminology
The following requirements terminology is used throughout this document:

• Requirement — Feature or function that, in Bellcore's view, is necessary to satisfy the
needs of a typical BCC. Failure to meet a requirement may cause application
restrictions, result in improper functioning of the product, or hinder operations. A
Requirement contains the words shall or must and is flagged by the letter “R.”
1.5 Requirement Labeling Conventions
This section describes the labeling conventions of proposed requirements and objectives,
as part of Bellcore's new GR process.
Each Requirement, Objective, Condition, Conditional Requirement, and Conditional
Objective object is identified by both a local and an absolute number. The local number
consists of the object's document section number and its sequence number in the section
(e.g., R3-1 is the first Requirement in Section 3). The local number appears in the margin
to the left of the Requirement. A Requirement object's local number may change in
subsequent issues of a document if other Requirements are added to the section or deleted.
The absolute number is a permanently assigned number that will remain for the life of the
Requirement; it will not change with new issues of the document. The absolute number is
presented in brackets (e.g., [2]) at the beginning of the requirement text.
Neither the local nor the absolute number of a Conditional Requirement or Conditional
Objective depends on the number of the related Condition(s). If there is any ambiguity
about which Conditions apply, the specific Condition(s) will be referred to by number in
the text of the Conditional Requirement or Conditional Objective.
References to Requirements, Objectives, or Conditions published in other Generic
Requirements documents will include both the document number and the Requirement
object’s absolute number. For example, R2345-12 refers to Requirement [12] in GR–2345.
1.6 Requirements Statement
The following Requirement is operative throughout this document, GR-831-CORE,

Issue 2.
R1-1 [1]The syntactic and semantic rules for TL1 as described in this document
shall be supported by the NEs and OSs, although each application-specific
message may employ only a subset of these rules.
1–5
1–6
Issue 1, November 1996 TL1 Message Specification
2. TL1 Message Specification

This section defines the language structures used in the input and output messages that
pass between an OS and NE. It also specifies syntax conventions and sufficient information
to help ensure consistency in the interface protocol specifications.
2.1 TL1 General Message Syntax
The term language, as applied here, is intended to cover all the rules and prior agreements
necessary for a message to carry meaning from one application program to another or from
a person to an application program. The specification of a language can be structured in
layers, in direct analogy to the protocol layers. A suitable set of layers is as follows:
• Syntax is the set of rules that relates the individual tokens (words) within a message to
each other. The TL1 syntax is divided into four basic areas:
— Input command messages from an OS toward an NE
— Acknowledgments from an NE toward an OS
— Output response messages from an NE toward an OS
— Autonomous messages from an NE toward an OS.
• Semantics is the meaning of the individual words.
• Information Structure refers to the names and associated meanings of groups of such
words, syntactically related.
• Intermessage Context deals with the relationship between messages (e.g., the
association of a response with a preceding command).
• Pragmatics defines the activity to be carried out by the receiving application program,
including access to a database and the appropriate generation of error messages.
Pragmatics include the actual specification of commands and their associated
responses.
This document focuses on the syntax and semantics of TL1.
2–1
TL1 Message Specification Issue 1, November 1996
The following specification characters (see Table 2-1), akin to the Backus-Naur Form
(BNF), are used throughout this document as a vehicle for defining the syntax:
Table 2-1. Syntax Definitions
< > Encloses a symbol specifier

(e.g., <int-num> may specify any integer number).
[ ] Encloses an optional symbol or information unit
(e.g., a[b]c represents abc or ac since b is optional).
’’ Encloses a literal character
(e.g., 'a' really means literal character a, as opposed to a
symbol representing a value).
( ) Encloses a group of symbols for the following operators:
* Post-fix operator meaning the preceding symbol or group of
symbols may occur zero or more times
(e.g., a(bc)* represents a or abc or abcbc or ...).
^ Space
(i.e., the literal blank character, used only in examples of
messages).
+ Post-fix operator meaning preceding symbol or group of
symbols may occur one or more times
(e.g., a(bc)+ represents abc or abcbc or ...).
| Infix operator meaning alternative, either the preceding
or succeeding symbol may occur, but not both in succession
(e.g., a|b|c represents a or b or c).
::= Separates the left and right sides of a grammar rule
(e.g., <digit> ::= (0|1|...|9) is a grammar rule representing
the symbol <digit> is 0 or 1 or ... or 9).
2.1.1 Input versus Output
The syntax for input messages and output messages is considerably different. Among the
fundamental differences are the application of format effectors, particularly spaces,
linefeeds, and carriage returns. As defined later, format effectors are meaningless when
present in input messages and may or may not be ignored in output messages.
Input messages group parameters into blocks separated by colons and, within parameter
blocks, separated by commas; parameters may be further modified with compounding,
ranging, and incrementing operators.
2–2
2.2 Characters and Information Units
Appendix A gives the character set specified by TL1. Some of the characters are
unspecified and reserved for implementation-dependent use. The basic elements of the
language are built from these characters. These basic elements represent units of
information and punctuation.
When defining new messages, it is important to realize that the words selected for use must
belong to one of the categories called information units. Only these information units,
punctuation characters, and the ancillary facilities of Appendix A can appear in commands.
Within input messages format effectors1 (i.e., spaces, tabs, carriage returns, etc.) are
completely ignored, except within text strings, and thus do not terminate information units.
For example, within a command, COMMAND CODE and COMMANDCODE are treated
in exactly the same way. Within output messages, format effectors may or may not be
ignored (see Sections 4, 5, and 6). The backslash (\) character will be used for escape syntax
within text strings (see Appendix A), i.e., causes the character following to be literally
interpreted.
Appendix A specifies the fourteen types of TL1 information units. This section gives an
informal description with examples.
2.2.1 Identifiers
An identifier starts with a letter and is followed by any number of letters or digits. For
example, A, abc, and xy50 are valid identifiers.2
2.2.2 Symbolic Names
A symbolic name must contain at least one letter, plus-sign (+), pound-sign (#), or percent-
sign (%) and optionally any digits. For instance, #7SWS, 1A0, 10%, and abc are all valid
symbolic names.
2.2.3 Decimal Numbers
A decimal number is a string of decimal digits with an optional non-trailing period (.). It
does not permit a leading plus-sign (+) or hyphen (-), or have any provision for exponential
1. Format effectors are the six ASCII characters of horizontal tab, vertical tab, space, form feed, line feed,
and carriage return.
2. Note although lowercase is allowed, uppercase is the norm for most implementations. See Section
2.7.3, Case Sensitivity, for further information.
2–3
notation. Some examples are 88, .005, and 004.100, but 12. is not valid because of the
trailing period (.). Leading zeros are optional except for values constrained to a fixed
format (e.g., date and time).
The optional leading D' (D apostrophe), indicating a decimal number, shall be permitted
only in a particular parameter if it is so stated in the semantics of the command involving
that parameter.
2.2.4 Nondecimal Numbers
The nondecimal number types, hexadecimal, octal, binary, and keyed, as defined in
Appendix A, will be permitted in TL1 only in a particular parameter if it is so stated in the
semantics of the command involving that parameter.
2.2.5 Text Strings
A text string is any string of ASCII (alphanumeric and/or punctuation) characters (see
Section A.3, Table A-1) enclosed in double-quotes ("). This allows a great deal of
flexibility in defining values because the limitations of identifiers and symbolic names are
overcome at the small cost of quoting the characters for message entry. To enter a double-
quote (") character within a text string, an escaped double-quote (\") is used.
2.2.6 Arithmetic Expressions
In TL1, arithmetic expressions are used to represent explicitly signed, positive or negative
decimal numbers. The syntax is an optional plus (+) or minus-sign (-), followed by a string
of decimal digits with an optional non-trailing period. The entire expression is contained
in parentheses to prevent parsing ambiguities. Examples of legal arithmetic expressions are
(12), (-15), (+137.038), and (67.23).
2.2.7 Keyed Numbers
Keyed numbers are used to express values that can be entered on an extended (4X4)
telephone keypad. The format is an optional K' (K apostrophe) followed by a string of
decimal digits, the uppercase letters A through D, the asterisk (*), or the pound-sign (#).
2–4
2.2.8 Numeric String
A numeric string is a subtype of decimal numbers consisting of only decimal digits. Each
digit in the string is an ASCII representation of a numeric digit.
2.2.9 Integer
An integer is either a numeric string or an arithmetic expression not containing a period

(decimal point).
2.2.10 Inner String
An inner string is similar to a text string but is used only within quoted lines of output
messages (see Sections 5 and 6). Because the double-quote character (") has already been
used to enclose the line, another symbol is needed to bracket text containing punctuation or
other special characters. The symbol used is the escaped double-quote (\"). Within an inner
string, a literal double-quote (") is represented by double double-quote (""), and a literal
backslash (\) by double backslash (\\).
For example
"<startTextString>\"<startInnerString>""<and>
\\<endInnerString>\" <endTextString>"
2.3 Parameter Block Syntax
A parameter block always follows a colon and contains a (possibly empty) list of
parameters, separated by commas. In TL1, trailing colon (:) block separators may be
omitted if there are no parameters entered in those last blocks. The parameter syntax, in
general, consists of an optional parameter name, equal-sign (=), and a parameter value.
However, the precise use of these options depends on the type of parameters entered in that
block. A block shall only contain all position-defined parameters or all name-defined
parameters. These two formats are characterized in the following subsections.
2.3.1 Position-Defined Parameters
In a block of position-defined parameters, the individual parameters must be entered in a

specific order without names unless specifically allowed by the message description. A
parameter entry may be omitted provided the associated comma separator is retained to
indicate the position of the parameter omitted. The parameter names are implicit and not
2–5
necessary in a positional block, where it is the order of parameter entries that associates
each value with the corresponding parameter. Some examples of valid position-defined
parameter blocks are given in the following:
: 5, 6, Yes:
: , 6:
TL1 permits omission of commas following the last non-null parameter in a block.
2.3.2 Name-Defined Parameters
For a block of name-defined parameters, every parameter entry must have a parameter
name and value, with successive entries made in arbitrary order. Parameter names are
always transmitted with name-defined parameters (and order is not significant nor
required).
The use of void parameters, indicated by adjacent separators, is valid only for positional
entry and not for name-defined entry. Parameter defaulting is done by omitting a parameter
entry. Three equivalent examples of a block of name-defined parameters are shown in the
following (assuming the default values are as in the first example):
: P1=1.0, P2=2.0, P3=off:
-or-
: P3=off, P1=1.0:
-or-
: P2=2.0:
2.3.3 Name/Position Syntax Conflicts
The syntax of an entered block of parameters must be consistent with either a name-defined
or a position-defined syntax. The following rules characterize resolution of potential syntax
conflicts:
In TL1, a parameter block must be position-defined if:
• Any parameter values appear without parameter names (i.e., without NAME=)
• Any void parameters (indicated by adjacent separators) appear.
Otherwise, the parameter block has valid syntax for both a position-defined and a
name-defined block.
In the case of position-defined parameters, entered parameter names must match the
defined parameter positions. If more parameters are entered than are defined, the block is
in error. But if fewer are entered, defaults are applied to the trailing parameter positions.
2–6
When names are attached to all parameter entries, the association of the entry with the
parameter definition is clear. If a parameter name appears more than once, an error will be
generated. If a parameter does not appear at all, the parameter defaults to the specific
default action defined for that particular parameter of that particular command.
2.4 Boolean Flag Parameters
In some messages, Boolean parameters (e.g., on/off, yes/no) might be needed. A possible
implementation is to represent one state by the presence of a symbol and the other by its
absence. To minimize the introduction of new symbols, the parameter value symbol chosen
may be the parameter name. While this mechanism is perfectly legal under TL1, it should
be emphasized that the parameter actually has two values: the parameter name value
represents one state, while a null symbol represents the (default) other state. This
representation, whenever used, should be clearly explained in the parameter description.
2.5 Defining a Parameter Block
The parameter block syntax described previously defines the general form of entry for
parameters in an arbitrary block. The syntax is a message-independent format that can be
verified without any knowledge of the block semantics, such as parameter names and
positions. In this section (2.5) and the next (2.6), the focus is on the syntax-related
semantics that apply universally to all parameter blocks.
2.5.1 Parameter Specification
To check the block semantics, it is necessary to have a block definition that specifies all
valid parameter names and positions for each block of each specified command. This
requires an appropriately ordered list of uppercase TL1 identifiers, each unique to the
block, to serve as parameter names. When describing the syntax for any TL1 message, each
parameter, regardless of whether it is intended for position or name defined entry, must be
represented by a unique name (i.e., <aid> or AID =). Along with parameter names, the valid
parameter values and their functional interpretations need to be specified.
Furthermore, the block type must be specified for each block, as position-defined or name-
defined. Each parameter block must be transmitted in the format corresponding to its block
type. It is also required that the parameter names be transmitted in their uppercase form.
2–7
2.5.2 Block Type Selection
Positional entry is useful when most of the defined parameters are entered. Efficiency is
increased because the parameter names are not transmitted and only commas and values
are sent. Since trailing commas may be suppressed, positional entry can also be an efficient
way to enter leading parameters with trailing commas omitted. The use of positional
parameter entry also reduces the time needed for parameter name searching.
One disadvantage of positional entry occurs when a block has many defined parameters
with only a few entered on a particular message request. In this case, all leading commas
must be transmitted, making it somewhat less efficient when only a small number of
parameters are being transmitted. Another advantage of name-defined parameters comes in
providing more flexibility to add parameters in the future without regard for previously
established parameter order, and still retaining compatibility with the previous version of
the message.
2.6 Defining Parameter Values
A parameter value consists of one or more TL1 information units that may be compounded
and/or grouped together as described in the following subsections. When a parameter is
defined for a particular command, the valid range of parameter values must be defined,
along with its interpretation. This includes the implicit set of units associated with any
numeric values.
Although there are exceptions, usually parameter values are interpreted as character strings
that must match exactly or as numeric values that must satisfy a given range. When numeric
values are specified, they must have a default base associated with them. This will normally
be the decimal base, but it may be binary or any other semantic interpretation desired for
that parameter. For TL1, the use of non-decimal numbers is not supported in general. If it
is necessary to allow a parameter to be entered in bases other than its default base, it must
be specifically stated in that parameter's description.
For non-numeric parameter values, typically a list of character strings will specify their
valid values. The parameter values, unlike parameter names, are case sensitive,1 e.g., the
identifiers A1 and a1 do not match.
A particular parameter may have a valid range that includes both numeric and character
values. For example, a parameter SETTING may take on values of 0 to 15, the identifier
NONE or the text string "N/A". Note that the slash (/) in "N/A" requires that it be entered as
a text string.
1. Refer to Section 2.7.3, Case Sensitivity, for further information.
2–8
A parameter value containing a single information unit is called a simple parameter

argument. The compound arguments and argument grouping are described in the next two
subsections.
2.6.1 Compound Arguments
Closely related information can be compounded into one parameter value by joining the
information units with the hyphen character (-). For example, it may be desirable to use one
parameter, LOCATION, to represent two map components, one given by a letter and the
other by a number. LOCATION = A-21 can be used for this purpose.
Compounding is equivalent to two separate positional parameters combined into one, but
compound fields cannot be omitted the way positional parameters can [e.g., A--C is invalid
syntax but A-null-C (where null is a literal parameter value meaning the parameter is
missing) or A-""-C could be specified for use in a particular command]. It is also
permissible to specify both simple and compound values for the same parameter.
2.6.2 Grouping of Arguments
Both simple and compound arguments may be grouped together so one parameter may
actually convey several arguments. This is done by using the connectors ampersand (&)
and double-ampersand (&&).
The ampersand (&) character is most useful when a parameter takes on any combination
of arguments in a specified set. If there are three OPTIONS (e.g., x, y, and z) that can be
selected in any combination, some possible entries could be OPTIONS = x&z or OPTIONS
= x&y&z.
The use of double-ampersand (&&) is reserved for expressing ranges of values. An
example of this usage is RANGE = 1&&10 to enter the values 1,2,3,...,10. Compound
parameters may be also grouped, but note that double-ampersand (&&) can only be used
to range over the last field of the compound parameter (e.g., 2-5-1 && -10 means 2-5-1 &
2-5-2 & ... & 2-5-10).
In TL1, the use of double-ampersand (&&) for ranges shall not be used for a particular
parameter unless it is specifically stated in the semantics of the parameter. In such cases,
the ordering of parameter values must be defined. Unless otherwise stated, it will be
assumed that numeric values have the usual ordering.
It is possible to use increments with && ranges. For example, in RANGE = 2 && 10 .++.
2, the increment value 2 following .++. indicator is used to represent even integers from 2
to 10. TL1 uses the characters .++. instead of ++ to avoid an ambiguity that is described
in the following subsection.
2–9
2.7 Implementation Issues
This section specifies implementation-related decisions and options. Most options are
related to restrictions on the form of the input commands, which allow an NE to implement
a TL1 command interpreter that is simpler and more efficient than the one needed for the
full human-to-NE capabilities. Some implementations may choose to take advantage of the
TL1 command restrictions to conserve real-time, while others may prefer the extra
reusability of the User System Interface software. Section 2.7.4 discusses these and other
issues.
2.7.1 Correction Characters and Comments
Any correction characters that may be used on the User System Interface (e.g., delete last
character and delete last line) will have no special meaning in TL1, but will be interpreted
literally. This implies that all corrections must be performed before the command is
transmitted; otherwise, the character will most likely produce invalid syntax. The only
correction that can be used is the delete command, which is conveyed by the ASCII {CAN}
character (cancel). It cancels all present input after the last command, that is, everything
since the last semicolon character.
Because comments do not convey any syntactic or semantic information to the NE, an OS
will not transmit them in input commands.
2.7.2 Restrictions on Nondecimal Numbers and Arithmetic Expressions
Nondecimal numbers and arithmetic expressions are not used in TL1 in a general way.
They may not be entered arbitrarily into any numeric parameters, but only in those
particular parameters for which it is specifically allowed by the specification of that
parameter's semantics. Because explicit nondecimal numbers (i.e., those using H', O', and
B') are rarely required, most NEs will not need to recognize and process them. Only those
NEs that support commands requiring explicit nondecimal numbers will need to implement
this feature.
Because every parameter that takes on numeric values has a default (or implied) base
associated with it, the use of H', O', B', and D' are only necessary to indicate that the
following value is not in its default base. Because a requester will send the values in the
default base, and because hexadecimal, octal, and binary numbers can all be represented as
decimal numbers, identifiers, or symbolic names (e.g., 10, A2, 1C, respectively), there is
no need to support the extra nondecimal information units.
Arithmetic expressions are not supported in general, but because decimal numbers are
unsigned, a restricted form of arithmetic expressions is necessary in some commands to
2–10
represent negative numbers. In these commands, arithmetic expressions may be restricted

to signed number arithmetic expressions,
( [<sign>] <Decimal Number> )
where the specifier <sign> can take on the characters plus-sign (+), hyphen (-) or be
omitted. For example, valid arithmetic expressions include (5.0), (-.001), and (+5.0). If the
<sign> is omitted, default is plus-sign (+) and the parentheses could be omitted.
2.7.3 Case Sensitivity
This section discusses issues of character case and, for emphasis, is presented in two parts.
• Command Codes and Parameter Names
• Parameter Values.
2.7.3.1 Command Codes and Parameter Names
Historically, for Command Codes and Parameter Names, TL1 was meant to be case
insensitive even though all Command Codes and Parameter Names were specified as
uppercase characters. To ease the restriction on users entering Input Messages directly to a
NE, lowercase characters were allowed on the interface and the NE was obligated to
translate lowercase character to uppercase before processing the message.
Output Message descriptions have always been documented using uppercase constructions
with no expectation that translation need occur at either a NE or an OS.
In other words, a NE should expect and be prepared to handle Command Codes and/or
Parameter Names in uppercase, lowercase, or mixed case (combinations of uppercase and
lowercase within an Input Message, a Command Code or a Parameter Name).
2.7.3.2 Parameter Values
There are no case restrictions placed on Parameter Values for TL1 Input or Output
Messages. Parameter Values may be either uppercase or lowercase exclusively or in any
combination to accommodate the NE's internal implementation.
In particular, TL1 rules do not suggest or infer that any character mapping of Parameter
Values be done, by either the NE or the OS, with respect to character case. As always, OS
implementations may require that a particular convention be adopted for consistency of
data as represented in master record keeping systems.
2–11
2.7.4 Resolving the Increment Ambiguity
There was a potential ambiguity to the TL1 command syntax. Consider the following
invalid TL1 expression.
<simple arg> && <simple arg> ++ <decimal number>
The use of double plus-sign (++) as a separator and also as an element in symbolic names
causes a problem, as illustrated in the following example. The parameter value
first&&last++2 can be lexically analyzed as (first) && (last) ++ (2) or as (first) &&
(last++2), because last++2 is a valid symbolic name.
In almost any other context, last++2 would be treated as a symbolic name, but here it is
probably intended to be last ++ 2. Rather than forcing the interpretation to be sensitive to
the context, it is more sensible to change the increment separator. TL1 will use the four
characters period double plus-sign period (.++.) instead of double plus-sign (++) to
resolve this potential ambiguity.
Therefore, the above invalid TL1 expression should be corrected as:
<simple arg> && <simple arg> .++. <decimal number>
2–12
Issue 1, November 1996 Input Command Message Structure
3. Input Command Message Structure

This section discusses the structure of a TL1 input command message and the functionality
of its component parts.
3.1 General Format
The general structure of a TL1 input message is of the form:

<command_code>:<staging_parameter_blocks>:<message_payload_
block(s)>;
The command code determines the action (i.e., pragmatics) to be taken at the NE as a result
of receiving the input message.
The staging parameter blocks determine the target NE and the identity of the object to be
acted upon by the input message.
The message payload block(s) is the subject matter relating to the action to be performed
by the input message.
The semi-colon character (;) terminates a TL1 input message.
3.2 Command Code
Each command must begin with a command code consisting of a mandatory verb followed
by up to two other optional modifiers, each separated by a hyphen.
<command code> ::= <verb>[-<modifier>[-<modifier>]]
3.2.1 Verb
The semantics of the verb are to identify the action to be taken at the NE as a result of
receiving a TL1 message from an OS. The semantic values of the verb are defined within
the context of the functional application in which the message is intended to be used (e.g.,
ENT, ED, RTRV). A list of TL1 verbs is in Appendix C.
3.2.2 Modifiers
The command code modifiers are optional depending upon the specific command and the
application domain. In normal TL1 command usage, the first modifier identifies the object
of the verb where the action is to be applied in the NE. The second modifier further
3–1
Input Command Message Structure Issue 1, November 1996
modifies the object of the verb and is interpreted differently for different operations
domains.
For example, a <verb>-EQPT can be used to indicate that an action, specified by the value
of the verb, is to be taken on an equipment object; a <verb>-T0 indicates an action is being
taken on a DS0 circuit (where T0 indicates transmission hierarchy level 0).
As another example, for switching NEs, the command <verb>-<administrative view>
indicates an action is to be taken on an object entity within the specified administrative view
of the switching NE database.1
The second modifier may be used to further define the identity of the object upon which the
action is to be taken. For example, the command DLT-CRS-T0 will disconnect (DLT) one
or more cross-connected (CRS) DS0 object entities (T0). That is, the modifier CRS is
further defined to identify T0 object entities.
Where suitable, verbs and parameter names have been selected from COMMON
LANGUAGE® documentation.2
3.3 Staging Parameter Blocks
The TL1 input message structure is designed to be independent of underlying protocols.

That is, such services as network routing which are typically provided by a protocol system
(e.g., CCITT Recommendation X.25) are embedded in the message structure. The staging
parameter blocks are a series of four data blocks following the command code that provide
information necessary to establish (i.e., stage) and uniquely identify an object entity within
an NE to be managed by a remote OS and to specify certain options as to how the input
command is to be executed in the NE. The structure of the staging parameter blocks
consists of the following series:
:[<target identifier>]:[<access identifier(s)>]:
<correlation tag>:[general block]:
Each block contains one or more specifically defined parameters, which are described in
the following subsections. The parameters within each staging block may either be
position-defined or name-defined. Normally a block with a simple parameter will include
1. The information groupings within a switching NE are called administrative views, in which individual
data elements are represented in the form of flat tables or matrices. Each row of an administrative view
represents an object entity; each column represents an attribute (parameter) shared by all of the object
entities in the view. An administrative view is similar in concept to relations in relational database
theory.
COMMON LANGUAGE is a registered trademark and CLEI, CLLI, CLFI, and CLCI are trademarks
of Bellcore.
2. See BR-751-000-101, ST-STS-000122, ANSI T1.201-1987, and ANSI T1.205-1988.
3–2
a position-defined parameter. Blocks with more than one parameter (e.g., the general
block) may use the name-defined construct for the parameters in the block.
3.3.1 Target Identifier (TID) Block
An input message associated with the management of a particular object may be directly
addressed to an NE, or it may be routed to, or through, one or more intermediate NEs or
other devices (which may perform mediation functions). The Target Identification (TID)
code parameter block provides the capability within the TL1 message format to perform
network routing tasks that are normally handled using features at lower layers of a
communications protocol.3 The presence of the TID in all input commands is a
requirement, but its value may be null (i.e., the TID is represented by two successive
colons).
When used, the TID block contains a single position-defined parameter that identifies the
end-target NE to which the input command is directed. An example of TID usage is for
indirect addressing of NEs by transferring subnetwork or gateway path information to
reach the target NE. The value of TID may be any valid simple or compound TL1 identifier
or text string, but it is limited to 20 characters.4 TIDs are configurable items that can be
defined using TL1 provisioning-driven messages. Where appropriate, the TID may assume
a default value equal to the System Identification (SID) code returned in a response
message from an NE. These two identifiers are otherwise independent of each other.
The following guidelines shall be applied in the assignment and application-specific use of
TIDs.
A. A single TID should be assigned to a system meeting a TL1 interface; criteria such as
the following should be used to determine when a single TID is appropriate:
1. Operations functions treat the system components collectively as a single entity.
2. TL1 commands that affect several components in the same way are issued as a
single message.
B. The assignment of multiple TIDs to a system that meets a TL1 interface is not
precluded. For example, if there are multiple subsystems for which no common
operations functions are required or supported, then multiple TIDs may be used. The
following guidelines should be observed in such cases:
1. Use of multiple TIDs at a TL1 interface shall only be done on an exceptional basis.
3. Normally, TL1 messages are sent above the CCITT X.25 protocols as described in TR-TSY-000827.
When used in this way, routing services are provided by the underlying protocols.
4. Important: Note that if either the TID or System Identifier (SID) contains any non-identified
characters (not made up of only letters and digits) such as spaces, the text string form must be used
(i.e., enclosed in double quotes).
3–3
2. Bilateral concurrence on the use of TIDs in these cases shall be required across all
anticipated applications.
C. A single NE, and thus a single TID, should be associated with the CLLI code of the
physical port associated with the entity meeting the standard TL1 operations interface.
3.3.2 Access Identifier (AID) Block
The Access Identification (AID) block normally contains one (or more) simple or
compound parameter(s) that uniquely identifies the entity within the target NE to be acted
upon by the input message to the NE. 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.
3.3.2.1 Circuit and Equipment Access
Cross connecting two channels calls for two access parameters — one representing the
FROM channel and the other the TO channel. The AID values for this case are of the form:
:[FROM=]<channel no.>,[TO=]<channel no.>:
where the keywords FROM and TO are implicit and need not be included in the AID
character string (i.e., the two parameter values are position-defined).
Another circuit example is the representation of digital facilities that have an inherent
hierarchical structure. Typically, the hierarchy is based on the nesting of lower
transmission rates within higher ones. For example, a DS3 facility (44.736 Mb/s) has 28
DS1 channels (1.544 Mb/s) nested within it. Thus, a single DS1 in such an NE could be
addressed with a compound AID value as follows:
:<ds3>-<ds1>:
That is:
:3-24:
specifies the 24th DS1 within the third DS3. The facility addressing capabilities will vary
among NEs, but this example illustrates the concept of entity addressing within a facility
hierarchy.
3–4
Similarly, some equipment has an inherent hierarchical structure that can be used when
addressing such entities. In this case, the hierarchy is based on the physical arrangement of
the equipment units. For example, a plug-in may be located in a slot on a shelf within a
frame. Thus a single plug-in, in such an NE, could be addressed with a compound AID
value as follows:
:<frame>-<shelf>-<slot>:
That is:
:1-3-6:
specifies the sixth slot in the third shelf within the first frame. Equipment addressing
capabilities will vary among NEs, but this example illustrates the concept of equipment
hierarchical addressing.
3.3.2.2 Administrative View Access
In some OS-to-NE environments, such as switching NEs, the entity to be addressed is a

database record. For example, if the target specified in the command code modifier is an
NE administrative view, the AID value identifies the primary key data item of a record in
that view. If more than one record is to be accessed within the view by a single command,
the AID value is an ordered list of the primary keys of each record desired. Each key item
within the list is separated by an ampersand (&) delimiter. Therefore, for a nonsequential
series of simple primary key parameters, the AID value will be of the form
:<key1>&<key2>&<key3>. . . .&<keyN>:
where each item is an element of a list and separated by an ampersand.

For a sequential series (or range) of simple primary keys, the first and last parameter values
of the range are separated by two sequential ampersands and the AID value will be of the
form
:<first_key>&&<last_key>:
A database object entity may require a combination of parameter values for unique
identification. For example, an AID value of the form
:<group>-<group_member>:
is a compound value by which a target object entity is identified uniquely as part of a group
(e.g., trunks within a trunk group).
3–5
A nonsequential group member within a group is separated by an ampersand followed by

a hyphen, as follows:
:<grp>-<mbr1_key>&-<mbr2_key>&-<mbr3_key>...&-<mbrN_key>:
Similarly, for sequential compound key parameters, the first and last group members are
separated by two ampersands followed by a hyphen, as follows:
:<grp>-<first_mbr_key>&&-<last_mbr_key>:
3.3.2.3 Access by Alias Values
OS-to-NE testing operations illustrate the use of an AID parameter value that is a substitute
(i.e., alias) representing the identity of the objects under test.
One such example is the use of a Test Session Number (TSN) as an alias value. An OS may
establish a testing session with an NE or and intermediate Test System Controller/Remote
Test Unit (TSC/RTU), and assign a unique number to that session. That is, a test
initialization message may be sent from the OS of the form:
CONN-TACC:<tid>:<aid>:<ctag>:<tsn>:<parameters>;
where the <aid> is the identity of the object to be tested and the <tsn> value is the TSN
(Test Session Number) assigned by the OS.5 That session number may then be
subsequently used as an alias AID value representing the object(s) being tested in that
session. That is, subsequent testing commands within that session may be aliased in the
AID parameter block with input messages of the form:
MON-DDS::<tsn>:<ctag>:<parameters>;
where the TID block value is NULL and the value of the AID block is <tsn>. All
subsequent input messages within that session may then identify a specific circuit or unit
of equipment initially identified when the session was established, with the session number,
(TSN), as a substitute (alias) for that circuit level or equipment level address.
Another example is the establishment of a connection between a Test Access Path (TAP)
and a circuit. Once the TAP connection is established, the TAP number may be used as an
alias AID value as long as the connection is maintained between the TAP and the circuit.
5. For historical reasons, the General Block (GB) as Section 3.3.4 describes, has not been implemented
for TL1 messages originating at a Testing Operations System. The TSN parameter is a single position-
defined parameter in place of the GB in test initialization messages. Subsequent testing operation
messages do not have a GB block.
3–6
3.3.2.4 Object Identifier Context Switching
When the first modifier of an input message command code identifies an administrative
view of a database within an NE, the content and format of the AID block of the message
depend on the access method specified by the semantics of the command code modifier.
For example, consider a case where the administrative view represents the subscriber lines
in a switching NE (i.e., LINE). Normally the AID content in the message will be the value
of the primary access key attribute identifying a particular object entity in the LINE
administrative view. The context of the primary access key attribute for a subscriber line is
its Directory Number (DN). A normal input message to make data value changes (i.e.,
EDIT-LINE) in an object entity identified by DN would be of the form:
ED-LI:<tid>:<dn>:...
where the AID value <dn> would be a particular DN identifying the subscriber line to be
changed.
If, however, it is desired to access this same entity by its secondary access key attribute [i.e.,
the corresponding Office Equipment (OE) value] for the object entity, the first command
code modifier will identify a context switch of the AID value by including the pound-sign
(#) as a context switch delimiter within the first modifier value string. The form of the input
message to effect this context switch would be of the form:
ED-LI#OE:<tid>:<oe>:...
where the context of the AID value <oe> would be the OE corresponding to a particular
DN of the subscriber line to be changed.
3.3.3 Correlation Tag (CTAG) Block
The third required parameter block of the staging parameter blocks is called the Correlation
Tag (CTAG) block for the message. It contains one position-defined parameter to serve as
a means of correlating an input command with its associated output response(s). The OS
assigns an arbitrary non-zero CTAG value6 for inclusion in the input message and it is the
responsibility of the NE to copy this value into the appropriate field of the output
response(s) associated with that input command. The CTAGs for a given NE received in
commands from multiple OSs need not be unique. The value of CTAG must either be a TL1
identifier or a non-zero decimal number, consisting of no more than six characters.
6. Arbitrary is used in the sense that the value has no significance other than the correlationship function.
3–7
3.3.4 General Block (GB)
The fourth and final staging parameter block is the GB, which includes support parameters
whose values affect the way in which the input command is to be executed in the NE.7 The
presence of the GB in all input commands is a requirement8 but its value may be null (i.e.,
the GB is represented by two successive colons).
The following GB functions are currently defined and are of the general form:
:[[<delay activation parameters>],[<contingency flag>],
[<indirect data retrieval identifier>]]:
The parameters may be either position-defined in the order specified below, or name-
defined in which only the keywords having non-default values need be specified in the
input message.
3.3.4.1 Delay Activation
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. The Delay Activation function is provided by a set of
parameters within the GB of the form:
[ON=]<order no.>,[DATE=]<date>,[TIME=]<time>
where the ON parameter value is an activation order number assigned by the OS. This
number is used by the NE to internally identify the delayed input message. After execution
of the message, the NE uses it to identify the message completion record created in a
Delayed Activation Completion log within the NE. A subsequent retrieval request from the
OS (RTRV-DA) will return the existing Delayed Activation Completion log records to the
OS where each will be identified by the ON identifier.9 The Delayed Activation Completion
log is automatically cleared by the NE following the record retrievals by the OS.
The DATE parameter value is the date when the delayed activation is scheduled to occur
and is of the form
7. The basic concept of the GB is to provide an expansion joint where common support functions may be
incorporated in the input messages as needed.
8. Earlier requirements specified the GB to be an optional block such that operations domains not having
domain-specific features were not required to include the GB in the input messages for that domain.
The mandatory requirement of this issue does not apply to existing deployed products nor need it be
retrofitted into existing products not yet deployed. However, future TL1 products shall comply with this
requirement.
9. The Delayed Activation Order Number parameter is similar in concept to the CTAG parameter.
3–8
<yy>-<mm>-<dd>
where <yy> is the last two characters of the year, <mm> is a value in the range from 01 to
12 identifying the month, and <dd> is the day of the month in the range from 01 to 31.
The TIME parameter value is the time within the specified date when the delayed activation
is scheduled to occur and is of the form
<hh>-<mm>-<ss>
where <hh> is a value from 00 to 23 identifying the hour, <mm> is a value in the range
from 00 to 59 identifying the minute within the specified hour, and <ss> is a value in the
range from 00 to 59 identifying the second within the specified minute.
There are three ways in which the input command can specify its action to be executed at
the NE.
1. An input command can be specified to be immediately executed following parsing and
interpretation of the message. This is considered to be the default situation.
2. It can be specified to be held in a pending buffer at the NE and executed at some later
date and time. This is called TIMED DELAY ACTIVATION.
3. It can be specified to be held in a pending buffer in the NE until another input command
is received to execute the command. This is called DELAYED MANUAL
ACTIVATION.
Table 3-1 illustrates the combination definitions for the first three parameters in the GB.
Table 3-1. Delayed Activation Truth Table
Order No. Date Time Activation Definition

NULL NULL NULL Immediate activation
DATA NULL NULL Delayed manual activation (only order number required)
DATA NULL DATA Activate at the next occurrence of the specified time
DATA DATA NULL Activate at the current time on the specified date
DATA DATA DATA Activate at the specified date and time
3.3.4.2 Contingency Flag
In some cases dependent relationships exist between the records within the same
administrative view; i.e., a relationship may exist between the database records specified
in a multi-entity AID data block such that if all the specified records are not successfully
and completely entered or edited in the database, some degree of overall data integrity is
lost. (An example would be the relationships between the telephone lines making up a
3–9
Series Completion chain.) The Contingency Flag (CF) parameter is a Boolean data type
within the GB that indicates, when set true (i.e., CF=1), a dependent relationship among
the several records specified in the AID data block of a multi-unit command. The flag value
will thus instruct the NE software that all the specified records must be successfully added
to, modified, or deleted from the designated database view or the entire operation must be
aborted. If the CF is false (i.e., CF=0), partial installation of the records (i.e., best effort) in
a multi-unit message may be completed with a report returned to the OS listing the records
that were not successfully installed in the database. The default value of CF is false and
need not be specified in the GB.
3.3.4.3 Indirect Data Retrieval Indicator
Indirect Data Retrieval is a functional capability by which information may be retrieved

from more than one linked administrative view by a single RTRV command. The
mechanism for this function is provided by a special support parameter located within the
GB of the staging block of the input command. The form of this indirect retrieval function
is as follows:
RTRV-<admin_view>:[<tid>]:<aid>:<ctag>:
RTRVIND=(<linked_admin_view>[-<linked_admin_view>]*)*;
where RTRVIND is a support parameter keyword within the GB whose value(s),

<linked_admin_view>, identifies one or more administrative views having a linking
relationship to the administrative view specified by <admin_view>. The
<linked_admin_view> pointer(s) must exist as an attribute keyword in the <admin_view>;
pointer keywords not so included shall be flagged as an error and the message rejected. The
view names will normally be the conventional names established for the administrative
views. The value(s) of the <linked_admin_view> pointer(s) will link to one or more object
entities (instances) in those views. The effect of the input command will thereby be to
retrieve all of the specified object entities from the linked administrative views indicated
by the RTRVIND support keyword value(s).
For example, if the linked administrative view related to the Subscriber Line (LINE)
administrative view is the Trigger Item (TI) view of an Advanced Intelligent Network
(AIN) switching system, the <linked_admin_view> attribute would have the name TI. The
value(s) of TI pointers will link to one (or more) object entity(ies) within the TI
administrative view. The form of an RTRV message directed to the primary LINE view,
with an indirect pointer to the TI view, is of the form
RTRV-LINE::5551234:123:RTRVIND=TI;
which is a command (with CTAG=123) to retrieve the data from AID=5551234, a DN

identifying an object entity of administrative view LINE. The RTRVIND keyword indicates
3–10
that data is also to be retrieved from the TI administrative view linked to the LINE
administrative view by the presence of the linked_admin_view attribute in the LINE view.
The existing value(s) of the TI pointer(s) determine which object entities of the view are to
be retrieved.10
A second order of indirection is also possible in which a first order linked administrative
view may be successively linked to another administrative view, with data being retrieved
only from the second order view and data from the first order view being omitted from the
retrieval. Extending the former example, suppose the TI administrative view contains a
linkage to the Service Logic Host Route (SLHR) administrative view. The command would
then be of the form:
RTRV-LI::5551234:123:RTRVIND=TI-SLHR;
where TI, the first order linked view, contains a pointer to SLHR, whose value(s) identify
the object entity(ies) to be indirectly retrieved from the SLHR administrative view. In this
example, RTRVIND has a compound value (TI-SLHR) specifying that data is to be retrieved
indirectly from administrative view SLHR. Data is not to be retrieved from administrative
view TI, the TI view only serving as a relay function to identify the second order view.
Similarly, data could be retrieved from object entities of all three administrative views if
the form of the message were:
RTRV-LI::5551234:123:RTRVIND=TI-SLHR&TI;
where TI-SLHR&TI is a multi-unit compound value specifying that data is to be retrieved

from both the second order linked administrative view (TI-SHLR) and the first order linked
administrative view (TI).
In all cases, the information returned to the source of the RTRV message will be a
concatenation of the information obtained from each of the foreign administrative views
and the initial administrative view specified in the modifier field of the RTRV message.
That is,
<primary view data>,<foreign view data>
It is permissible to cascade the indirect retrieval capability by including the RTRVIND

parameter within the field of object entity parameters of a foreign administrative view. The
information returned in such cases would be a concatenation of data fields as follows:
10. The value(s) of the linked_admin_view attributes are normally set at system set-up time or are
subsequently altered by TL1 Edit (ED) commands to the administrative view in which the
linked_admin_view attributes are contained.
3–11
<primary view data>,<first foreign view data>,

<second foreign view data>, ...
Section 5.6 shows a specific output response example.
3.4 Message Payload
The remaining part of any TL1 input command is the payload or subject matter of the
message. This section of the message may consist of zero11 or more data blocks in the
following general form:
(:<px>(,<px>)*)*;
where px represents a parameter (i.e., data item). Each data block is delimited by colons (:)
and the last is terminated by a semi-colon (;). Each data block may have an unlimited
number of data items, each delimited by commas (,). For example, a payload consisting of
three parameter blocks, each containing three parameters would be of the form
...:<p1>,<p2>,<p3>:<p4>,<p5>,<p6>:<p7>,<p8>,<p9>;
The data items within a data block may either be name-defined (of the form
<key_word>=<value>) or position-defined where the values are specified and the
keyword is implied by its position in the data block. All of the data items must be of the
same type within a given data block. The semantics of the data items are operation domain-
specific and vary according to the operation to be performed as a result of the input
message.
3.4.1 IntraBlock Type Procedure
Whenever an equal sign (=) is detected within a data block, the data block type is defined
to be a name-defined data block. This implies the data block to be of the form:
...:Keyword1=<value>, Keyword2=<value>,... KeywordN=<value>:...
If a position defined parameter (i.e., a value with no keyword =), an error will be generated
indicating a data block error. That is according to the rule that data types cannot be
intermixed in the same data block.
11. Some input messages, such as data retrievals, may have no explicit payload.
3–12
Issue 1, November 1996 Acknowledgments
4. Acknowledgments
There are three types of TL1 output messages: acknowledgments, output response
messages, and autonomous messages. This section deals with Acknowledgments, Section 5
describes output response messages, and Section 6 describes autonomous messages.
4.1 General Format
An acknowledgment is a brief output message generated in response to an input command

message. An NE may optionally have the ability to turn on or off acknowledgments via a
standard input command, custom command, or message from a local (craft) terminal. In
general, an acknowledgment is later followed by an output response message to the
command. However, in some circumstances, an acknowledgment is the only output
message triggered by a command.
Each of these acknowledgments follows the 2-second rule, which states that an
acknowledgment should be used if an output response message to the command cannot be
transmitted within 2 seconds of its receipt.
The format of an acknowledgment is as follows:
<acknowledgment code> ^ <ctag> <cr> <lf>
<
The acknowledgment code identifies the reason for the acknowledgment. The CTAG
identifies the associated input command. The less than (<) character is the
acknowledgment terminator.1 The valid values for acknowledgment codes and their
meanings are given in the following subsections.
4.2 In Progress (IP) and Printout Follows (PF)
IP In Progress The request has been initiated. These

PF Printout Follows acknowledgments should produce subsequent output
messages that give a termination report alone or a
termination report and results of the command.
These acknowledgments imply that the command is being executed. They are used often
for test and access messages requiring a long execution time, e.g., a 1-minute noise test.
These acknowledgments may be followed by either completed or denied output response
messages.
1. Previously referred to as the Ready Indicator and only associated with acknowledgments.
4–1
Acknowledgments Issue 1, November 1996
Note that very subtle distinctions made between IP and PF in previous documents have
been eliminated in this document.
4.3 All Right (OK)
OK All Right The command was received and the requested action
was initiated and completed.
Specific uses for the OK acknowledgment are defined in message set criteria documents
(e.g., GR-199-CORE, GR-833-CORE, and GR-834-CORE). In addition, OK is used in
response to a command that has been canceled by inclusion of the CAN (cancel) character.
4.4 No Acknowledgment (NA)
NA No Acknowledgment Under abnormal conditions, NA should be sent when

a command has been accepted but control of the
processing has been lost, making correct
acknowledgment impossible. Initiation or execution
of the requested command is uncertain.
This acknowledgment should be used only in dire circumstances since the state of
execution status is unknown.
This acknowledgment can also be used to respond to a command that is garbled during
transmission. If the CTAG value of the command could not be determined, then the single
character zero (0) should be used as the acknowledgment CTAG value.
4.5 No Good (NG)
NG No Good The command is valid, but the requested action

conflicts with current system or equipment status
(e.g., an attempt to restore an in-service unit). For
inadequate system resources, use RL instead of NG.
This acknowledgment is seldom used because specific error codes in output response
messages can be employed to signify the same information. However, it can be used if
desired.
4–2
Issue 1, November 1996 Acknowledgments
4.6 Repeat Later (RL)
RL Repeat Later The requested action cannot be executed due to

unavailable system resources caused by system
overload, excessive queue lengths, busy programs,
etc. The command may be entered again later.
4–3
Acknowledgments Issue 1, November 1996
4–4
Issue 1, November 1996 Output Response Message Structure
5. Output Response Message Structure

This section describes the structure of a TL1 output response message and the functionality
of its component parts. A TL1 output response message is the response to a TL1 input
command message.
5.1 General Format
The general structure of a TL1 output response message is of the form

<header> <response identification> [<text block>] <terminator>
which consists of two required entries called header and response identification, an
optional text block, and a required terminator.
The header represents information common to all output response messages; i.e., it is
independent of the type of output response.
The response identification identifies the type of output response message. Five types of
output response messages are defined in this document.
The text block represents information specific to the particular output response message.
This component is optional.
The terminator indicates the termination or continuation of the output response message.
The following sections further describe the structure of the above component constructs.
5.2 Header
The form of the header is

<cr><lf><lf>^^^<sid>^<year>-<month>-<day>^<hour>:<minute>:<second>
and is composed of a source identifier (<sid>) and date and time stamps. The <sid> is
restricted to 20 characters maximum and identifies the NE generating the message. The
syntax of <sid> is any TL1 identifier (simple or compound) or text string. It is suggested
that the NE's CLLI1 code (and possible extension) be used for the source identifier. The
<sid> value is checked by the NE against the <tid> parameter of the input command to
verify that the NE's <sid> matches the command's intended target (i.e., <tid>).
1. Important: if either the TID or SID contains any non-identified characters (not made up of only letters
and digits) such as spaces, the text string form must be used (i.e., enclosed in double quotes).
5–1
Output Response Message Structure Issue 1, November 1996
The <year>-<month>-<day> construct generally represents the day on which the

command is executed (see Section 7.2, “Output”, for detailed guidelines). This construct
consists of three components separated by hyphens (-). These components represent the
year, the month of the year, and the day of the month, respectively. Each component is
specified by exactly two digits. For example 82-08-02 represents the second day of August
in 1982.
The <hour>:<minute>:<second> construct generally represents the time when the
command is executed (see Section 7.2, “Output”, for detailed guidelines). This construct
consists of three components separated by colons (:). These components represent the hour,
the minute of the hour, and the second of the minute, respectively. Each component is
specified by exactly two digits. For example, 15:05:00 represents the time of exactly 3:05
in the afternoon (p.m.).
An example of the header block is
<cr><lf><lf>^^^HOLMNJCRK01^85-10-09^22:05:12
5.3 Response Identification
The form of the response identification is

<cr><lf>M^^<ctag>^<completion code>
This construct consists of three components, namely, the character M, a correlation tag
(<ctag>), and a completion code. The character M signifies that the message is the
response to an input command message. The output response message shall have the same
<ctag> value as the corresponding input command message for enabling the OS to
associate the received output response message with a previously sent command.
The completion codes are COMPLD, DENY, PRTL, DELAY, and RTRV. Message
designers may further restrict the use of some of these codes. The semantics of the
completion codes are:
COMPLD represents total successful execution of the input command.

DENY represents total denial of the input command.
PRTL represents partial successful execution of the input command. This response code
shall be returned for output response to input commands specifying multiple AIDs
of which only a subset (but not an empty subset) have been successfully executed.
If all AIDs have failed to be executed, the response code shall be DENY. This
response code is valid when the contingency flag in the general block is false (i.e.,
best effort).
DELAY represents successful queuing of the input command submitted for delayed
activation.
5–2
RTRVa represents output response of an input retrieve command (i.e., with command verb
RTRV) that retrieves extensive amount of information from the NE and thus causes
lengthy processing in the NE for gathering all the requested information. For
effective operation, the NE may start returning available information to the OS even
before all the requested information is gathered. In this case, the RTRV completion
code may be used. Multiple responses with RTRV completion codes are permitted
for the same RTRV command, but the final response must have a COMPLD
completion code.
a. The use of this completion code depends on the application domain.
When the <ctag> of an input command cannot be identified (e.g., during dial-up
asynchronous connections with noise and errors prevalent), either the 2-letter
acknowledgment NA may be returned or the DENY response containing the appropriate
error message with the <ctag> set to the single character zero (0) may be returned.
5.4 Text Block
The optional text block is used to represent information specific to the particular output
response. The form of the response text is
((<cr><lf>^^^<unquoted line>)|(<cr><lf>^^^<quoted line>)|
(<cr><lf>^^^<comment>))*
It consists of three possible types of components, namely, <unquoted line>, <quoted

line>, and <comment>. Both <unquoted line> and <quoted line> are machine parsable,
while <comment> is not. Each type of component may appear zero or more times within
the text block and interleave with other component types in any order.
The <unquoted line> consists of name- or position-defined parameters separated by
required whitespace (<ws>) and optional commas. A whitespace is a space character, a
horizontal tab, a vertical tab, or a form feed. The most popular usage of the unquoted line
component is for representing error codes in some response messages, e.g., in a denial
response (i.e., when the response code is DENY). The error code is specified by four
characters that may contain numerals after the first character, if appropriate (e.g., SN4W
for Status error, Not equipped 4-Wire circuit). Appendix D shows a list of existing error
codes. These error codes have been used in various TL1 message documents.
The <quoted line> consists of parsable text and shall always be preceded and followed by
the double-quote character (''). The syntax of the parsable text is equivalent to that of an
input command message, i.e., a series of colon-delimited parameter blocks. Parameters
within each block are separated by required commas and optional format effectors. Format
effectors are space, horizontal tab, vertical tab, form feed, carriage return, and line feed.
5–3
The comment component is used to allow free format (i.e., human readable, not machine
parsable) text. The free form text shall always be preceded by the pair of characters slash
asterisk (/*) and followed by the pair of characters asterisk slash (*/).
Note that either the semicolon (;) or the greater than (>) character shall not terminate the
output response message, when they are present as part of a quoted line or within a text
string.
5.5 Terminator
The form of the terminator is

<cr><lf>(;|>)
The terminator is represented by either the semicolon (;) character or the greater than (>)
character. The semicolon (;) character is used to indicate the termination of the output
response message. The greater than (>) character is used to indicate that more output
associated with this response will follow under another header.
It is a requirement that the size of an output message shall not exceed 4096 bytes. If the size
of an output response message exceeds 4096 bytes, the output information shall be
partitioned into multiple output response messages. A continuation message (i.e.,
subsequent message) needs to have another header and response identification with the
same <ctag>, along with an additional <text block>. Each message shall be terminated by
the greater than (>) character, except the last message, which shall be terminated by the
semicolon (;) character for indicating the completion of the response. The (>) terminator is
also used for intermediate responses in a timed measurement series.
5–4
5.6 Examples of Output Response Message
Some examples of output response message are shown below.2

A. Assuming that the input command,
UPDATE : RDBKNJNVK01 : 5-7 : 1204 ;
was issued, a typical NE output response message with COMPLD response code might
look like the following:
<cr> <lf> <lf>
^^^RDBKNJNVK01^93-06-15^09:12:11 <cr> <lf>
M^^1204^COMPLD <cr> <lf>
^^^"5-7:32,NONE" <cr> <lf>
;
B. Assuming that the input command,

UPDATE : RDBKNJNVK01 : 5-16 : 9904 ;
was issued and the argument 16 was out of range, the following output response
message (with a DENY response code) might appear:
<cr> <lf> <lf>
^^^RDBKNJNVK01^93-06-15^09:12:11 <cr> <lf>
M^^9904^DENY <cr> <lf>
^^^RRNG <cr> <lf>
^^^"5-16:aid2=16:min=0,max=15" <cr> <lf>
^^^/* Numeric values in the Access Block must be <cr> <lf>
^^^ between 0 and 15. */ <cr> <lf>
;
Also, regarding the previous example illustrating the use of the TL1 comment facility of:
has been construed that the portion treated as free format text must be conventionally
formatted to conform to other Output Message syntax rules. The example imposes no
restriction on the TL1 comment facility and is intended only to demonstrate the versatility
that an implementation might choose to present information intended for a display device.
Thus, it is noted that within free format text, the construct
2. The response codes DELAY and RTRV are used in GR-199-CORE for messages for switching NEs.
See GR-199-CORE for examples.
5–5
... <cr> < lf>

^^^ ...
is not required. However, it may be included (as in the above example) to demonstrate
formatting for human readability.
C. Assuming that the input command,

UPDATE : RDBKNJNVK01 : 5-7&16&3 : 9954 ;
was issued and the argument 16 was out of range, the following output response
message (with a PRTL response code) might appear:
<cr> <lf> <lf>
^^^RDBKNJNVK01^93-06-15^09:12:11 <cr> <lf>
M^^9954^PRTL <cr> <lf>
^^^"5-7:32,None" <cr> <lf>
^^^RRNG <cr> <lf>
^^^"5-16:aid2=16:min=0,max=15" <cr> <lf>
^^^"5-3:24,None" <cr> <lf>
;
D. An example of a RETRIEVE command using the indirect data retrieval identifier

is:
Input Command message:
RTRV-LI::9087582000:123:RTRVIND=TI;
The Output Response message could look like this (the example does not show all
applicable administrative view keywords):
<cr> <lf> <lf>

^^^RDBKNJNVK01^93-07-09^09:15:42 <cr> <lf>
M^^123^COMPLD <cr> <lf>
^^^"9087582000, LI: DN=9087582000, TIALIST=3-400A-ON"
<cr> <lf>
^^^"3-400A, TI: TRIGTYP=OHD, SLHRID=H2UP" <cr> <lf>
;
5–6
Issue 1, November 1996 Autonomous Messages
6. Autonomous Messages
An autonomous message is a message that is sent from the NE to the appropriate OS
without having an explicit input message associated with it (such as the normal Input
Command / Output Response message pair). Typical scenarios where autonomous
messages are used include
• Reporting of alarmed and/or non-alarmed trouble events
• Reporting of scheduled diagnostic tests in the NE
• Reporting of Performance Monitoring Data
• Reporting of a change in the NE's database
• Periodic reporting of selected NE conditions.
Aside from alarm and event reporting, most other autonomous messages are related to
functions that were set up with another Input Command/Output Response message pair.
For example, an OS can schedule periodic reporting of selected NE conditions by sending
the appropriate Input Command to the NE. If the NE is capable of performing the requested
function, it will send a successful Output Response message back to the OS. Subsequent
periodic reporting of the selected conditions would then be accomplished by sending the
report in the form of an appropriate autonomous message. This could also apply to
scheduling diagnostic tests and various audits within an NE. Throughout this section,
spontaneous and autonomous are used interchangeably.
6.1 General Format
The general structure of a TL1 autonomous message is

<header> <auto id> [<text block>] <terminator>
which consists of two required entries called header and auto id, an optional text block, and
a required terminator. The general structure of an autonomous message is identical to that
for an Output Response message (Section 5) except for the auto id block (described later).
The header represents information common to all output response (Section 5.2) and
autonomous messages.
The auto id identifies the severity and the nature of the autonomous message. The severity
is indicated through the use of an alarm code, which will be discussed in further detail.
The text block represents information specific to the particular autonomous message. This
entry is optional and is discussed further in Section 5.4.
The terminator indicates the completion or continuation of the autonomous message. This
entry is required in all types of TL1 messages (see Section 5.5).
6–1
Autonomous Messages Issue 1, November 1996
6.2 Header (<header>)
The <header> is the standard response header that is defined in Section 5 (Output
Response Message Structure). It contains system identifier <sid>, and date and time
stamps. The header is a required entry in all TL1 output response and autonomous
messages. For a more detailed explanation of its parameters and syntax see Section 5.2.
6.3 Identification of Output (<auto id>)
The <auto id> entry for an autonomous message is of the following form
<cr> <lf> <almcde>^<atag>^<verb>[^<modifier>[^<modifier>]]
6.3.1 Alarm Code (<almcde>)
<almcde> is the alarm code. The alarm code indicates the severity of the autonomous
message. Valid values for <almcde> in decreasing order of severity are as follows:
<almcde> Description
*C Critical alarm
** Major alarm
*^ Minor alarm
A^ Non-alarm message
Critical, Major, and Minor correspond to the reporting of alarmed events. The Non-alarm
message designation is used when the NE is reporting non-alarmed events, periodic
measurements, or results of previously scheduled diagnostics or audits.
If multiple alarms are reported in the same message, the alarm code is the highest severity
of those being reported.
6–2
6.3.2 Autonomously Generated Correlation Tag (<atag>)
The <atag> parameter is the Autonomously Generated Correlation Tag (ATAG). It is a

decimal number made up of an integer part and an optional fractional component (e.g.,
123.456).1 It is assigned by the NE, must be sequential, and must be included in all
autonomous messages. The ATAG serves two purposes.
• It allows an OS to determine if it has failed to receive any spontaneous outputs by
checking for omissions in the sequence of messages received.
• It allows an OS to correlate spontaneous outputs triggered by a common problem. (To
accomplish this, the NE involved must be capable of recognizing and categorizing
common problems.)
The former objective is achieved by using the integer part of the decimal numeral; the latter
is achieved by using the optional fractional part.
Correlating autonomous messages requires the NE to be intelligent enough to ascertain
whether events that cause autonomous messages to be generated are the result of a common
problem. Without this ability, there is no use for the fractional part of the ATAG. An NE
must be able to recognize when events occurring are emanating as the result of a common
problem. It may base its judgment on several factors – location of event, timing of events,
type of events, etc.
If an NE determines that a second event occurred and is related to an event that occurred
earlier and was reported with an autonomous message, the NE may then issue the second
event with the appropriate integer part for the ATAG (the integer value plays no role in
correlating common problems) and attach a "reference tag" as the fractional part.
One possible way to implement this would be to correlate ALL subsequent events with
fractional ATAG values that are the same as the first correlated message. Thus, if the
twelfth, thirteenth, and fourteenth events detected by an NE are correlated with the second
event, the resulting ATAG values would be 12.2, 13.2, and 14.2. The whole number part
(sequence number) is required on an autonomous message; the fractional part (trouble
correlation) is optional.
A message clearing a particular alarm or condition would be correlated to the original
message that reported the alarm or condition in a similar manner. The autonomous message
with the indication that the condition or alarm has cleared will contain an ATAG with the
corresponding whole number part of the original message as the fractional part of its
ATAG. For example, if the original message had an ATAG of 14.2, then a message that
indicates the clearing of that condition might have an ATAG of 22.14.
1. Although TL1 imposes no restrictions on the length of an Autonomously Generated Correlation Tag,
individual application domains might (e.g., GR-833-CORE restricts the ATAG to a maximum of 10
characters including the decimal point if used).
6–3
An example showing the use of the ATAG to correlate events is included in Section 6.6
(Examples of Autonomous Messages).
6.3.3 <verb>[^<modifier>[^<modifier>]]
The <verb>[^<modifier>[^<modifier>]] entry identifies the nature of the spontaneous

output and allows for quick identification of the semantics of the information in the text
block. It consists of up to three valid TL1 identifiers separated by the space character
[represented by a caret (^)].1 The first identifier (<verb>) is the autonomous message verb
and is a required entry. In most cases, the verb in an autonomous message will be REPT
(Report). The autonomous message verb can have up to two optional modifiers; thus, valid
forms are <verb>, <verb>^<modifier>, and <verb>^<modifier>^<modifier>. The first
identifier following the verb is used to modify the verb. The second identifier is used to
specify the object generating the message. Certain modifiers mean that the <aid>
parameter (if it exists) is addressing a particular type of entity in the NE. For a more detailed
description of TL1 verbs and modifiers, see Section 3 (Input Command Message
Structure).
6.4 Text Block ( [<text block>] )
The optional [<text block>] is used to represent information specific to the particular
autonomous message. The format of the text block is as follows:
((<cr><lf>^^^<unquoted line>)|(<cr><lf>^^^<quoted line>)|
(<cr><lf>^^^<comment>))+
It consists of three components, namely <unquoted line>, <quoted line>, and <comment>.
Both <unquoted line> and <quoted line> consist of text that is parsable, while
<comment> is not. Each component may appear zero or more times within the text block
and interleave with other component types in any order. A more complete description of
the individual components is in Section 5.4.
6.5 Terminator
The terminator block has the form

<cr> <lf> ( ; | > )
and is required as the termination block for all TL1 message types. For more information
regarding message size, completion, and continuation designations, see Section 5.5.
1. This is different from the separator character used in Input Command Messages described in Section 2.
6–4
6.6 Examples of Autonomous Messages
This section contains two examples of actual TL1 autonomous messages taken from the
Network Maintenance and Surveillance application domain (GR-833-CORE). Both
examples illustrate typical <verb> and <modifier> combinations, and the second one
shows event correlation via the use of the ATAG.
Assume that periodic performance monitoring information is being sent to a Surveillance
OS. A typical NE might generate the following autonomous output:
<cr> <lf> <lf>

^^^BOCAFLMA015^93-06-02^12:00:00 <cr> <lf>
A^^789^REPT^PM^T1 <cr> <lf>
^^^"AID-T1-1:CVL,50" <cr> <lf>
^^^"AID-T1-2:CVL,10" <cr> <lf>
. . .
. . .
. . .
^^^"AID-T1-n:CVL,22" <cr> <lf>
;
As an illustration of event correlation using the ATAG, assume that a carrier group alarm
has occurred. A typical NE might generate the following autonomous output:
<cr> <lf> <lf>
^^^BOCAFLMA010^93-06-02^01:10:12 <cr> <lf>
*^^456.123^REPT^ALM^T1 <cr> <lf>
^^^"T1AID-16:MN,CGA,NSA" <cr> <lf>
^^^"T1AID-32: <cr> <lf> MN,CGA,NSA" <cr> <lf>
;
Note that the asterisk caret (*^) indicates that it is a minor alarm and the ATAG, 456.123,
indicates that this spontaneous output message was generated as the result of a common
problem. Other messages associated with the same problem would have an ATAG with the
same fractional part (i.e., .123).
Also note the use of embedded format effectors (e.g., <cr> and <lf>) in the
<quoted line>. This is a valid construct and should be handled the same way that it is in the
Input Command message (format effectors are ignored in these instances).
6–5
6–6
Issue 1, November 1996 Implementation Guidelines
7. Implementation Guidelines
There are a number of issues that a TL1 implementor must face aside from just syntax and
semantics. The intermessage context and pragmatics must also be handled. The purpose of
this section is to give some guidelines that any implementation must follow for proper
working of a TL1 interface.
7.1 Input
There are a number of considerations that must be made when a command is received by
an NE. These are as follows, in no fixed order:
• Check whether a CAN character has been entered. If so, transmit an OK
acknowledgment.
• Filter non-TL1 characters from the command.
• Check whether processing resources are available for the command. If it is not,
transmit an RL acknowledgment.
• Check whether the command is garbled. If it is, transmit an NA acknowledgment or an
appropriate output error response message. Set the CTAG value to zero (0).
• Transmit an IP or PF acknowledgment if appropriate.
• Check whether this command has higher priority than other commands that may
already be buffered or executing. High priority commands are those that control
execution of other commands. Examples are as follows:
— ABT-CMD - Abort Command
— DISC-MEAS - Disconnect Measurement.
7.2 Output
Once a command has begun execution and its response is being generated, the following
guidelines apply:
• Split long responses and autonomous messages into segments of no more than 4096
characters. This is the current TL1 size limit taken from TR-TSY-000827. Use the
greater than (>) termination character for intermediate segments. All segments of a
long response should be assigned the same CTAG value.
• Use the greater than (>) termination character for intermediate responses to commands
generating periodic outputs, e.g., MEAS-VG (measure voltage) from GR-834-CORE.
7–1
Implementation Guidelines Issue 1, November 1996
• Generate message header time/date stamps using the general rule that the time/date
should reflect a time of occurrence rather than the time of transmission. The occurrence
time is clear in some cases and less clear in others. Use the following guidelines to
clarify such scenarios:
— A quickly executing command - the time of execution
— A measurement occurring over time - the time the measurement finished
— An alarm or event - the time when the alarm/event condition occurred or was
detected.
• Assign transmission priorities to output segments as follows:
— Critical alarms (highest)
— Major alarms
— Minor alarms
— Command responses and non-alarm autonomous messages (lowest).
This implies that output of a long response or autonomous message might have to be
interrupted by higher priority messages. To maintain proper message structures, this
interruption should be done only between output message segments.
• If correct processing of a command is lost, terminate execution and transmit an NA
acknowledgment.
• There are five generic command response completion codes - COMPLD, DENY,
PRTL, DELAY, and RTRV. While COMPLD and DENY are always applicable, the
other completion codes can be used if this is specifically stated in the message set
document describing the command.
7.3 Target Identifier (TID) and Source Identifier (SID)
In Section 3.3.1, “Target Identifier Block (TID),” and Section 5.2, “Header,” regarding
SID, both describe the TID or SID Parameter Block, in part, as being any TL1 Identifier,
either Simple or Compound. Previous documentation emphasized in the narrative the
meaning and implications of compounding parameters through the use of the TL1 hyphen
operator (-). Parsers conforming to formal TL1 Language descriptions that find a hyphen
in this parameter (or any other parameters) block will NOT treat the hyphen as data, but as
a separator of two closely associated units of data or information. One example observed
is a TID/SID constructed with concatenated CLLI Codes and Relay Rack nomenclature,
that is, only:
<clliCode>-<relayRackLocation>
7–2
Issue 1, November 1996 Implementation Guidelines
which may or may NOT be a legal compounding of information depending on the initial
character value of
<relayRackLocation>
7–3
Implementation Guidelines Issue 1, November 1996
7–4
Issue 1, November 1996 TL1 Grammar
Appendix A: TL1 Grammar
A.1 Introduction
This appendix provides a rigorous definition of TL1 using Backus-Naur Form (BNF). This
is included so that any subtle questions arising from reading the main body of GR-831-
CORE can be resolved. However, it is assumed that the reader already has some familiarity
with TL1 from a reading of the main text of this document.
This appendix uses the BNF notation introduced in Section 2 - the symbols <...>, [...], *.
+, etc. In addition, the following character symbols have been reserved: <sp>, <cr>, <lf>,
<ht>, <vt>, <ff>, and <can>. These are defined in Section A.3. All other characters have
literal meanings. To prevent confusion, single quotes (') are used to surround a literal
character, and double quotation marks (") are considered literal characters.
A.2 Contents
The formal grammar description follows a bottom-up approach. First, the legal character
set and three character classes are defined. Next, the rules for forming characters into
words called information units are given. Next, a BNF function is defined for a common
structure called a parameter value complex. Then grammar rules are given for the top level
input and output messages in terms of information units, punctuation characters, etc. The
final section is a discussion of the various sorts of text string entities that exist within TL1.
A.3 Character Set/Classes
The legal character set consists of the subset of ASCII characters shown in the standard
matrix presentation (see Table A-1). Each column of the matrix is labeled by the most
significant hexadecimal digit of the character code, and each row by the least significant
hexadecimal digit.
A–1
TL1 Grammar Issue 1, November 1996
Table A-1. Legal ASCII Character Set

0 1 2 3 4 5 6 7
0 <sp> 0 @ P ` p
1 ! 1 A Q a q
2 " 2 B R b r
3 # 3 C S c s
4 $ 4 D T d t
5 % 5 E U e u
6 & 6 F V f v
7 ' 7 G W g w
8 <can> ( 8 H X h x
9 <ht> ) 9 I Y i y
A <lf> * : J Z j z
B <vt> + ; K [ k {
C <ff> , < L \ l |
D <cr> - = M ] m }
E . > N ^ n ~
F / ? O _ o
Here <ht> = Horizontal Tab, <lf> = Line Feed, <vt> = Vertical Tab, <ff> = Form Feed,
<cr> = Carriage Return, <can> = Cancel, and <sp> = Space.
The cancel character <can> is legal for input messages (commands) only.
The characters not used by TL1 (hex 00-08, 0E-17, 19-1F, and 7F) are reserved for
implementation-dependent use by lower layers of the communications protocol: PAD
control, XON/XOFF stream control, etc. These special characters should be removed from
each message before or during parsing. The injunction against use of the special characters
in TL1 messages cannot be bypassed by trying to hide them in escape sequences (using \'s;
see Section A.8). Escape sequences are not recognized by lower layers that treat TL1
messages as transparent octet streams. If it is essential to allow any possible character in a
message, e.g., in a memory dump, then hexadecimal or some other encoding must be
employed.
Three useful character classes (letters, decimal digits, and format effectors) are as follows:
<let> ::= A | B | ... | Z | a | b | ... | z
<dig> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<fe> ::= <sp> | <cr> | <lf> | <ht> | <vt> | <ff>
A–2
A.4 Information Units
TL1 messages are built from basic entities called information units (analogous to English
words) combined and delimited by punctuation characters. The types of information units
are defined as follows:
<nil> ::=
<ident> ::= <let> (<let> | <dig>)*
<sym name> ::= <dig>* ((<let> | '+' | # | %) <dig>*)+
<alphanum> ::= (<let> | <dig>)+
<dec num> ::= [D'] <dig>* [.] <dig>+
<arith exp> ::= '(' ['+' | -] <dig>* [.] <dig>+ ')'
<hex num> ::= [H'] (<dig> | A | B | C | D | E | F)+
<oct num> ::= [O'] (0 | 1 | 2 | 3 | 4 | 5 | 6 | 7)+
<bin num> ::= [B'] (0 | 1)+
<keyed num> ::= [K'] (<dig> | A | B | C | D | '*' | #)+
<num str> ::= <dig>+
<integer> ::= <num str>
| '(' ['+' | -] <dig>+ ')'
<text str> ::= " (\" | \\ | <any character except " or \>)* "
<inner str> ::= \" ("" | \\ | <any character except " or \>)* \"
The <nil> unit symbolizes the absence of any other unit.

The next three types - <ident> (identifier), <sym name> (symbolic name), and
<alphanum> (alphanumeric) are used for names or other non-numeric information.
The numeric types are <dec num> (decimal number), <arith exp> (arithmetic expression),
<hex num> (hexadecimal number), <oct num> (octal number), <bin num> (binary
number), <keyed num> (keyed number), <num str> (numeric string), and <integer>.
Unless otherwise specified, numeric values are assumed to be decimal numbers. If a non-
decimal number is allowed for a parameter value, this must be explicitly stated in the
description of the message containing the parameter. The only purpose for the <arith exp>
is for encoding negative decimal numbers. Without inclusion of the bounding parentheses,
a parsing ambiguity is possible since the minus sign/hyphen is used also for forming
compound values. Because of the <dig>+ in the definitions of <dec num> and <arith
exp>, decimal numbers cannot end in a decimal point.
The text string (<text str>) and inner string (<inner str> units are used to construct more
complex parameter values that cannot be built from the other information units and
punctuation characters. Section A.8 further describes the string unit constructions.
A–3
A.5 Parameter Value Complexes
Information units can be combined using punctuation characters to form more complicated
parameter values expressing compound values, groups of values, ranges of values, etc. The
most general form allowing all possible combinations is called a parameter value complex.
Parameter value complexes appear in TL1 in three types. All three types use exactly the
same rules for forming complexes from information units. The differences among the types
are due only to the classes of allowed information units from which the complexes are
formed.
Repeating the BNF for complex formation three times is lengthy and confusing since each
repetition must use different variables to distinguish the information class allowed. Instead,
immediately below is defined a BNF function called param value complex. It has as an
argument the free variable info unit class. This function is invoked several times in sections
below.
<param value complex(<info unit class>)> ::=
<seq chain> (& <seq chain>)*
<seq chain> ::= <simple seq>

| <cmp chain>
<simple seq> ::= <info unit class>

| <from unit> && <to unit>
| <from unit> && <to unit> .++. <inc>
<from unit> ::= <info unit class>
<to unit> ::= <info unit class>
<inc> ::= <dec num>
<cmp chain> ::= <cmp seq> (&- <linked seq>)*
<cmp seq> ::= <cmp arg>

| <cmp arg> &&- <to unit>
| <cmp arg> &&- <to unit> .++. <inc>
<cmp arg> ::= <info unit class> (- <info unit class>)+
A–4
<linked seq> ::= <info unit class>

| <from unit> &&- <to unit>
| <from unit> &&- <to unit> .++. <inc>
The connector punctuation characters &, &-, &&, &&-, and .++. are used to express
multiple values from a set and ranges of values. Although not explicitly expressed in the
BNF, the information units used for range limits must be numerical values. For example,
1 && 4 is legal TL1 while A && D is not.
A.6 Input Messages
Each input message (command) has a uniform structure consisting of a series of colon-
delimited blocks. The command code, target identifier, access identifier, correlation tag,
and general blocks have fixed internal formats. The remaining blocks have message-
dependent formats.
<input message> ::= <cmd code> : [<tid>] : [<aid>] : <ctag>
:[<general block>] (: <payload block>)* ;
A.6.1 Command Code
<cmd code> ::= <ident>

| <ident> - <ident>
| <ident> - <ident> - <ident>
| <ident> - <ident> # <ident>
The pound-sign (#) is used only in the command code to indicate object identifier context
switching where the first modifying <ident> value is an administrative view.
A.6.2 Target Identifier
<tid> ::= <ident> ( - <ident>)*

| <text str>
A–5
A.6.3 Access Identifier
<aid> ::= <aid unit> (, <aid unit>)*

<aid unit> ::= [<aid name> =] <param value>
<aid name> ::= <ident>
A.6.4 Correlation Tag
<ctag> ::= <ident>

| <dec num>
A.6.5 General Block
The <general block> can be empty, position-defined, or name-defined. It can contain

delayed activation order number, date, and time, plus contingency flag, and indirect data
retrieval indicator.
<general block> ::= <nil>
| <pos def gen blk>
| <name def gen blk>
<pos def gen blk> ::= [<order nr>], [<gb_date>], [<gb_time>],

[cont_flag] [,<idr_ind>]
<name def gen blk> ::= [ON = <order nr>], [DATE = <gb_date>],
[TIME = <gb_time>], [CF = cont_flag]
[,RTRVIND = <idr_ind>]
<order nr> ::= <dec num>
<gb_date> ::= <dig> <dig> - <dig> <dig> - <dig> <dig>
<gb_time> ::= <dig> <dig> - <dig> <dig> - <dig> <dig>
<cont_flag> ::= 0 | 1
<idr_ind> ::= <ident> (- <ident>)*
A–6
A.6.6 Payload Block
<payload block> ::= <pos def param> (, <pos def param>)*

| <name def param> (, <name def param>)*
<pos def param> ::= <nil>
| [<param name> =] <param value>
<name def param> ::= <param name> = <param value>
<param name> ::= <ident>
<param value> ::= <param value complex(<cmd info unit class>)>
<cmd info unit class> ::= <ident>
| <sym name>
| <alphanum>
| <dec num>
| <arith exp>
| <hex num>
| <oct num>
| <bin num>
| <keyed num>
| <num str>
| <integer>
| <text str>
If an input message contains a <can> (hex 18) character, the effect is to erase all previous
characters of the message.
Format effectors within an input message are ignored unless they occur within text strings,
in which case they are treated as literal characters.
A.7 Output Messages
Output messages are split into three basic classes, command acknowledgments, command
responses, and autonomous messages.
<output message> ::= <acknowledgment>
| <response>
| <autonomous>
A–7
A.7.1 Acknowledgments
Acknowledgments are simple two-letter codes with correlation tags used primarily to
report the status of command execution.
<acknowledgment> ::= <ack code> <sp> <ctag> <cr> <lf> <
<ack code> ::= IP | OK | PF | NA | NG | RL
A.7.2 Output Response and Autonomous Messages
Responses and autonomous messages are similar in structure and consist of two required
entries called the header and identification, an optional text block, and a terminator symbol.
The header line is composed of a source identifier, date stamp, and time stamp.
<response> ::= <header> <response id> [<text block>] <terminator>
<autonomous> ::= <header> <auto id> [<text block>] <terminator>
<header> ::= <cr> <lf> <lf> <sp> <sp> <sp> <sid> <sp> <date> <sp>
<time>
<sid> ::= <tid>
<date> ::= <dig> <dig> - <dig> <dig> - <dig> <dig>
<time> ::= <dig> <dig> : <dig> <dig> : <dig> <dig>
A response is a response to a specific previous command. The response identification of

output consists of an M to declare the type, the correlation tag of the command initiating
the response, and a completion code to report the general status.
A.7.3 Response Identifier
<response id> ::= <cr> <lf> M <sp> <sp> <ctag> <sp>

<completion code>
<completion code> ::= COMPLD | DENY | PRTL | DELAY | RTRV
A–8
A.7.4 Autonomous Messages
Autonomous messages are normally triggered by alarm conditions and are not in response
to any input message (command). The autonomous identification of output consists of an
alarm severity level code, an autonomously generated correlation tag, and an output code
reporting the general event causing the message.
<auto id> ::= <cr> <lf> <alarm code> <sp> <atag> <sp> <output code>
<alarm code> ::= '*'C | '*' '*' | '*' <sp> | A <sp>
<atag> ::= <dec num>
<output code> ::= <ident>

| <ident> <sp> <ident>
| <ident> <sp> <ident> <sp> <ident>
A.7.5 Text Blocks
Both responses and autonomous messages may contain optional text blocks. A text block
consists of a series of lines, each started by a carriage return/line feed sequence. A line can
contain either free text in the form of a comment, or parsable data, but not a mixture of the
two. A parsable data line can take one of two forms called an unquoted line or a quoted line.
The term <line> below refers to logical structure, not physical structure. A single <line>
might have carriage returns and line feeds inside it, thus printing as several physical lines.
<text block> ::= (<cr> <lf> <sp> <sp> <sp> <line>)+
<line> ::= <comment>

| <unquoted line>
| <quoted line>
<comment> ::= /'*' <any character sequence except */> '*'/
An unquoted line consists of name- or position-defined parameters separated by required

whitespace (<ws>) and optional commas. The unquoted line information unit class used
for building parameter value complexes does not contain any sort of text string unit.
<unquoted line> ::= <output unit> ([,] <ws>+ <output unit>)*
<ws> ::= <sp> | <ht> | <vt> | <ff>
A–9
<output unit> ::= [<unquoted param name> =] <unquoted param value>
<unquoted param name> ::= <ident>
<unquoted param value> ::=

<param value complex(<unquoted info unit class>)>
<unquoted info unit class> ::= <ident>

| <sym name>
| <alphanum>
| <dec num>
| <arith exp>
| <hex num>
| <oct num>
| <bin num>
| <keyed num>
| <num str>
| <integer>
A quoted line is a special string type the body of which holds inner level parameters. The
inner level is reached by inclusion in quotation marks. The syntax of the inner level is
equivalent to that of a command, i.e, a series of colon-delimited blocks (here called
<block>s). Parameters within each <block> are separated by required commas and
optional format effectors (<fe>s).
Format effectors within a quoted line are ignored unless they occur within inner strings, in
which case they are treated as literal characters.
<quoted line> ::= " <block> (: <block>)* "
<block> ::= <pos def quoted param> (, <fe>* <pos def quoted param>)*
| <name def quoted param> (, <fe>* <name def quoted param>)*
<pos def quoted param> ::= <nil>

| [<quoted param name> =] <quoted param value>
<name def quoted param> ::= <quoted param name> = <quoted param value>
<quoted param name> ::= <ident>
<quoted param value> ::= <param value complex((<quoted info unit class>)>
<quoted info unit class> ::= <ident>

| <sym name>
| <alphanum>
A–10
| <dec num>
| <arith exp>
| <hex num>
| <oct num>
| <bin num>
| <keyed num>
| <num str>
| <integer>
| <inner str>
A response or autonomous message is ended by a <terminator>, which is a carriage return/

line feed sequence followed by either a greater than (>) or a semicolon (;) as follows:
<terminator> ::= <cr> <lf> (> | ;)
A.8 Strings, Quotes, and Escape Sequences
The purpose of this section is to clarify the BNF definitions for the various text string type
entities given above and explain the reasons for the definition details. Relevant BNF lines
are repeated here for easy reference.
<text str> ::= " (\" | \\ | <any character except " or \>)* "
<quoted line> ::= " <block> (: <block>)* "
<inner str> ::= \" ("" | \\ | <any character except " or \>)* \"
In input messages (commands), it may be necessary to encode a value not derivable from
the rigid information units or complexes of them. It was for this purpose that the <text str>
unit was defined. A text string is an arbitrary sequence of legal TL1 characters surrounded
by quotation marks. Note that here, the term quotation mark always refers to the double
mark symbol (''). Within the body of a text string, a literal quotation mark itself is encoded
by an escaped double-quote - (\"). The escape character - backslash (\) - is represented by
a double backslash - (\\). Literal quotation marks within the body of a text string do not have
to be balanced (paired).
Example: Assume that a command parameter P has the literal value
alarm\event class "fatal"
This would be encoded as a name-defined command parameter text string as

P = "alarm\\event class \"fatal\""
A–11
Text strings handle all needs for exotic parameter values within input messages. They also
handle the same needs for the parameter values within the header and identification of
output lines for output messages. However, for output message text blocks new
complications arise. Here, quotation marks are used to distinguish an unquoted line from a
quoted line At the inner level of a quoted line, a new construction is needed to encode
arbitrary strings of characters. This construction is the <inner str>. An inner string is an
arbitrary sequence of legal TL1 characters surrounded by escaped quotes (\"). Within the
body of the inner string, a literal quotation mark is indicated by a double double-quote ("");
a literal backslash is indicated by a double backslash (\\).
Example: To return the parameter P (introduced in the example above) as a name-defined
parameter P in a response or autonomous text block quoted line, the form
"P=\"alarm\\event class ""fatal""\",Q= ..."
This value could not be included in a text block unquoted line since the allowed information
units for an unquoted line do not include any type of general string.
A–12
Issue 1, November 1996 TL1 Style Guide
Appendix B: TL1 Style Guide

This appendix offers a framework for the presentation of TL1 message format but does not
impose or alter in any way the semantics or syntax of a message.
For the most part, these are conventions for future use that foster a more uniform
presentation of messages within a domain or particular document, and more importantly,
across the several domains.
Previous TL1 documentation used lowercase letters as positional parameter values in the
presentation of the message syntax. These lowercase letters, were somewhat arbitrary
variable references that were, in turn, references to variable values accompanying the
meaning of the variable references. Although the use of lowercase alpha characters was
intended to aid the presentation of the message, it introduced an unneeded level of
indirection.
A new convention allows for parameters to be mentioned in the syntax with a meaningful
parameter mnemonic that usually makes clear on observation the use or meaning of a
parameter.
To overcome problems of long message descriptions fitting on a page-text-line, the
presentation is allowed to be broken at a parameter boundary and suitably indented on
subsequent page-text-lines to show that the continuing logical description is an extension
of the previous physical description. Breaking the presentation for Input command
messages is usually not a problem because it is well accepted that a input command
message begins with a verb, followed by optional modifiers and parameters, and completed
with an ASCII semicolon symbol (;). It is also well known that input command messages
do not in any way rely on, in particular, the format effectors of carriage return or linefeed
to structure the parameters. Indeed, in the strictest sense of TL1 rules for input command
messages, format effectors may occur and are to be ignored at the destination, that is, the
NE.
So, the presentation on paper, for example, of a long input command message may look like
VERB-MOD1-MOD2:<tid>:<aid>:<ctag>:<tsn>:
<parm1>,<parm2>,<parm3>,<parm4>,<parm5>;
Output messages rely on certain format effectors to structure the parameters, principally for
human readability, and therefore their presentation relies on the symbolic use of the printed
caret symbol (^) to represent an ASCII space (or blank) character as parameter separators.
Formal description of the TL1 language uses only <sp> and the caret as a symbolic
replacement only occurs with specific input message or output message descriptions and
presentations.
Also, ASCII carriage return characters and linefeed characters are presented as <cr> and
<lf> to show the end of, or the beginning of, a logical block of information as a physical
line on display devices.
B–1
TL1 Style Guide Issue 1, November 1996
On occasion, a special effort was attempted to physically associate the <cr> and <lf>
parameter effector with the textual presentation. For simple response output messages, this
has not been a problem. However, for complex messages, with optional text block lines, the
presentation placement of <cr> and <lf> may lead to a more difficult human interpretation
or construction.
As an illustration, a simple normal response output message may contain one optional text
block line and could be presented as
<cr><lf><lf>
^^^<sid>^<date>^<time><cr>><lf>
M^^<ctag>^COMPLD<cr><lf>
[<optional-text-block-line><cr><lf>];
Or, a frequent alternative is

<cr><lf><lf>
^^^<sid>^<date>^<time><cr><lf>
M^^<ctag>^COMPLD
[<cr><lf><optional-text-block-line>]<cr><lf>;
For consistency in presentation style, new and revised documentation will usually adopt the
following:
<cr><lf><lf>^^^<sid>^<date>^<time>
<cr><lf>M^^<ctag>^COMPLD
[<cr><lf><optional-text-block-line>]
<cr><lf>;
Also, because all but the <optional-text-block-line> is controlled by general convention, a

normal response could easily be presented as
<header>[<sl><optional-text-block-line>]<terminator>
Here, <header> and <terminator> (the ASCII character triad of carriage return, linefeed,
and semicolon) are already defined message components and symbolically <sl> (start of
line) is made up of <cr> <lf> <sp> <sp> <sp> that causes the start of a new line on
display devices. Longer normal response output messages may be presented in a more
readable way as
B–2
Issue 1, November 1996 TL1 Style Guide
<header>
<sl><text-block-line-one>
<sl><text-block-line-two>
<sl><text-block-line-etc>
<terminator>
In any case, the <sl> <text-block-line> separators are, for presentation purposes,
consistently attached to the beginning of the lines. Now, with this presentation convention,
long descriptions that may need more than one page-text-line can be split without possible
ambiguity. For example
<header>
<sl><parameter1a>,^<parameter1b>,^<parameter1c>,^
<parameter1d>,^<parameter1e>
<sl><parameter2a>,^<parameter2b>,^<parameter2c>,^
<parameter2d>,^<parameter2e>
<terminator>
The representation of optional parameters between pairs of left and right brackets ([]) along
with parameter position holders may lead to a convoluted and correspondingly difficult
understanding of a message. Consider the following partial input command message as an
example:
:<parameter1>:[<parameter2>]:[<parameter3>];
The obvious meaning is that <parameter1> is required and <parameter2> and

<parameter3> are independently optional. According to TL1 custom, trailing null optional
parameters blocks need not have the parameter separators transmitted so an implemented
message may correspond as follows, if either or both <parameter2> and <parameter3>
were present or not:
: VALUE1 ;
: VALUE1 : VALUE2 ;
: VALUE1 : VALUE2 : VALUE3 ;
: VALUE1 : : VALUE3 ;
To properly protect the position of <parameter3> in the absence of <parameter2>, the

position holder for <parameter2> must be in the message. However, the formal notation
for the description would have been
:<parameter1>[:[<parameter2>]:[<parameter3>]];
B–3
TL1 Style Guide Issue 1, November 1996
The simpler notation, which uses the principle that trailing parameter separators are
unneeded but are permissible, have proved to be more usable.
B–4
Issue 1, November 1996 TL1 Message Verbs
Appendix C: TL1 Message Verbs

The TL1 operations messages at the OS/NE generic interface specified in GR-199-CORE,
GR-833-CORE, and GR-834-CORE define a set of command verbs that are expected to
meet all anticipated operations needs. Table C-1 summarizes these command verbs.
Table C-1. Command Verbs

Verb Definition Verb Definition
ABT Abort INIT Initialize
ACPT Accept MEAS Measure
ACT Activate MON Monitor
ALW Allow OPR Operate
AUD Audit RD Read
CANC Cancel REC Recover
CHG Change RECNFGR Reconfigure
CMPR Compare REPT Report
CONN Connect RLS Release
COPY Copy RMV Remove
CPY Copy RST Restore
CRPT Corrupt RTRV Retrieve
CRTE Create SCHED Schedule
DGN Diagnose SET Set
DISC Disconnect SND Send
DLT Delete STA Start
ED Edit STP Stop
ENCAP Encapsulation SW Switch
ENT Enter TEST Test
EX Exercise TRACE Trace
EXIT Exit TST Test
FLTLOC FaultLocate WRT Write
INH Inhibit
C–1
TL1 Message Verbs Issue 1, November 1996
C–2
Issue 1, November 1996 TL1 Error Codes
Appendix D: TL1 Error Codes

When an input command or an action request by an input command is denied, the output
response shows the error condition that triggered the denial. This type of output response
is called an error response.
General error codes and their corresponding descriptions of the error conditions are
presented in Table D-1. Each error response message should include the error code that
most accurately describes the particular error condition.
Table D-1. General TL1 Error Codes (Sheet 1 of 6)

Error
Code Category Description
EANS EQUIPAGE ACCESS NOT SUPPORTED
EATN EQUIPAGE NOT VALID FOR ACCESS TYPE
EFON EQUIPAGE FEATURE OPTION NOT PROVIDED
EN2T EQUIPAGE NOT 2-WIRE TERMINATE AND LEAVE
ENAC EQUIPAGE NOT EQUIPPED WITH ALARM CUTOFF
ENAD EQUIPAGE NOT EQUIPPED WITH AUDIT CAPABILITY
ENAR EQUIPAGE NOT EQUIPPED WITH AUTOMATIC RECONFIGURATION
ENAT EQUIPAGE REQUEST NOT VALID FOR ACCESS TYPE
ENDG EQUIPAGE NOT EQUIPPED WITH DIAGNOSTIC CAPABILITY
ENDS EQUIPAGE NOT EQUIPPED WITH DUPLEX SWITCHING
ENEA EQUIPAGE NOT EQUIPPED WITH ERROR ANALYSIS CAPABILITY
ENEQ EQUIPAGE NOT EQUIPPED
ENEX EQUIPAGE NOT EQUIPPED WITH EXERCISE CAPABILITY
ENFE EQUIPAGE FEATURE NOT PROVIDED
ENFL EQUIPAGE NOT EQUIPPED FOR FAULT LOCATING
ENHN EQUIPAGE NOT HYBRID NETWORK
ENMB EQUIPAGE NOT MULTIPOINT BRIDGE
ENMD EQUIPAGE NOT EQUIPPED WITH MEMORY DEVICE
ENPM EQUIPAGE NOT EQUIPPED FOR PERFORMANCE MONITORING
ENPS EQUIPAGE NOT EQUIPPED WITH PROTECTION SWITCHING
ENRE EQUIPAGE NOT RECOGNIZED EQUIPAGE
ENRI EQUIPAGE NOT EQUIPPED FOR RETRIEVING SPECIFIED INFORMATION
ENRS EQUIPAGE NOT EQUIPPED FOR RESTORATION
D–1
TL1 Error Codes Issue 1, November 1996

Error
ENSA EQUIPAGE NOT EQUIPPED FOR SCHEDULING AUDIT
ENSG EQUIPAGE NOT SOFTWARE GENERIC
ENSI EQUIPAGE NOT EQUIPPED FOR SETTING SPECIFIED INFORMATION
ENSS EQUIPAGE NOT EQUIPPED WITH SYNCHRONIZATION SWITCHING
ENTL EQUIPAGE NOT TERMINATE AND LEAVE
ERLC EQUIPAGE RED-LINED CIRCUIT
ERNS EQUIPAGE RTU DOES NOT SUPPORT COMMAND
ESPG EQUIPAGE SOFTWARE PROGRAM
ETNS EQUIPAGE TSC DOES NOT SUPPORT COMMAND
FNCR FAULT NE FAIL.-CIRCUIT RESTORED TO LAST COND.-MON-TERMa
FNDT FAULT NO DIAL TONE DETECTED
FNEC FAULT NTE HAS LOST 8-KHZ BYTE CLOCK
FNSC FAULT NTE HAS LOST 64-KHZ BIT CLOCK
FRCE FAULT RTU COMPONENT OR CONFIGURATION ERROR
FRDA FAULT RTU DOES NOT ANSWER THE CALL
FREC FAULT RTU EIGHT KHZ BYTE CLOCK LOST
FRNR FAULT RTU DOES NOT REPLY
IBEX INPUT BLOCK, EXTRA
IBMS INPUT BLOCK, MISSING
IBNC INPUT BLOCK, NOT CONSISTENT
ICNV INPUT COMMAND NOT VALIDb
IDMS INPUT DATA MISSING
IDNC INPUT DATA NOT CONSISTENT
IDNV INPUT DATA NOT VALID
IDRG INPUT DATA RANGE ERROR
IEAE INPUT ENTITY TO BE CREATED ALREADY EXISTS
IENE INPUT SPECIFIED OBJECT ENTITY DOES NOT EXIST
IIAC INPUT INVALID ACCESS IDENTIFIER (AID)
IICM INPUT INVALID COMMANDb
IICT INPUT INVALID CORRELATION TAG
IIDT INPUT INVALID DATA PARAMETER
D–2

Error
IIFM INPUT INVALID DATA FORMAT
IIPG INPUT INVALID PARAMETER GROUPING
IISP INPUT INVALID SYNTAX OR PUNCTUATION
IITA INPUT INVALID TARGET IDENTIFIER
INAC INPUT ACCESS NUMBER NOT CORRECT
INUP INPUT NON-NULL UNIMPLEMENTED PARAMETER
IPEX INPUT PARAMETER EXTRA
IPMS INPUT PARAMETER, MISSING
IPNC INPUT PARAMETER NOT CONSISTENT
IPNV INPUT PARAMETER NOT VALID
ISCH INPUT SYNTAX INVALID CHARACTER
ISPC INPUT SYNTAX PUNCTUATION
ITSN INPUT INVALID/INACTIVE TEST SESSION NUMBER
PICC PRIVILEGE ILLEGAL COMMAND CODE
PIMA PRIVILEGE INVALID MEMORY ADDRESS
PIMF PRIVILEGE INVALID MEMORY FILE
PIUC PRIVILEGE STATED USER PRIVILEGE CODE IS ILLEGAL
PLNA PRIVILEGE LOGIN NOT ACTIVE
RABY RESOURCE ALL TAPS BUSY
RALB RESOURCE ALL UNITS OF REQUESTED TYPE ARE BUSY
RANB RESOURCE ACCESS NETWORK BUSY
RCBY RESOURCE CIRCUIT BUSY
RCIN RESOURCE REQUESTED CIRCUIT ID DOES NOT EXIST
RNAN RESOURCE REQUESTED NE ACCESS NUMBER DOES NOT EXIST
RNAU RESOURCE REQUESTED NE ACCESS NUMBER UNASSIGNED
RNBY RESOURCE NE IS BUSY
RRCB RESOURCE UNIT SPECIFIED BY ROUTING CODE BUSY
RRNG RESOURCE REQUESTED CHANGE EXCEEDS RANGE
RTBY RESOURCE REQUESTED TAP BUSY
RTEN RESOURCE REQUESTED TAP DOES NOT EXIST
RTUB RESOURCE TEST UNIT BUSY
D–3

Error
SAAL STATUS ALREADY ALLOWED
SAAS STATUS ALREADY ASSIGNED
SABT STATUS ABORTED
SACS STATUS ACCESS UNIT CAN'T SYNC ON FACILITY SIGNAL
SADC STATUS ALREADY DISCONNECTED
SADS STATUS ACCESS UNIT IN DIAGNOSTIC STATE
SAIN STATUS ALREADY INHIBITED
SAIS STATUS ALREADY IN-SERVICE
SAMS STATUS ALREADY IN MAINTENANCE STATE
SAOP STATUS ALREADY OPERATED
SAOS STATUS ALREADY OUT-OF-SERVICE
SAPF STATUS ACCESS PATH CONTINUITY CHECK FAILED
SAPR STATUS ALREADY IN PROTECTION STATE
SARB STATUS ALL RESOURCES BUSY
SATF STATUS AUTOMATIC TEST FAILED
SCAT STATUS CIRCUIT IS ALREADY CONNECTED TO ANOTHER TAP
SCBS STATUS CHANNEL BUSY
SCIS STATUS CIRCUIT IN SPLIT CONDITION
SCNA STATUS COMMAND NOT ABLE TO BE ABORTED
SCNF STATUS COMMAND NOT FOUND
SCNS STATUS CIRCUIT NOT IN SPLIT CONDITION
SCOS STATUS CHANNEL OUT-OF-SERVICE
SCSD STATUS CAN'T SPLIT DS0B CIRCUIT
SCSN STATUS INVALID COMMAND SEQUENCE
SDAS STATUS DIAGNOSIS ALREADY STARTED
SDBE STATUS INTERNAL DATA BASE ERROR
SDFA STATUS DUPLEX UNIT FAILED
SDLD STATUS DUPLEX UNIT LOCKED
SDNA STATUS DUPLEX UNIT NOT AVAILABLE
SDNC STATUS INPUT DATA IS NOT CONSISTENT WITH NE DATA
SDNR STATUS DATA NOT READY
D–4

Error
SDNS STATUS DIAGNOSIS NOT STARTED YET
SEOS STATUS NTE IS OUT-OF-SERVICE
SFAS STATUS FAULT LOCATING ALREADY STARTED
SFNS STATUS FAULT LOCATING NOT STARTED YET
SFYA STATUS FACILITY REPORTS YELLOW ALARM
SLNS STATUS LOG NOT STARTED YET
SLOS STATUS TSC TO RTU LINK OUT OF SERVICE
SNCC STATUS NOT CROSS-CONNECTED
SNCN STATUS NTE UNABLE TO EXECUTE COMMAND
SNDS STATUS NTE IS IN A DIAGNOSTIC STATE
SNIM STATUS NTE ACCESS COMPLETE, CIRCUIT WAS INMONITOR STATE
SNIS STATUS NOT IN SERVICE
SNML STATUS NO MONITOR LINE ESTABLISHED
SNNB STATUS NTE COULD NOT SYNC ON DS0B SIGNAL
SNNS STATUS NTE COULD NOT SYNC ON DS1 SIGNAL
SNOS STATUS NTE IS OUT-OF-SERVICEc
SNPR STATUS NOT IN PROTECTION STATE
SNRM STATUS SYSTEM NOT IN RESTORATION MODE
SNRS STATUS NOT RESERVED
SNSR STATUS NO SWITCH REQUEST OUTSTANDING
SNVS STATUS NOT IN VALID STATE
SNYA STATUS NTE HAS DETECTED A YELLOW ALARM
SOSE STATUS OPERATING SYSTEM ERROR
SOST STATUS OUT-OF-SERVICE, TESTING
SPFA STATUS PROTECTION UNIT FAILED
SPLD STATUS PROTECTION UNIT LOCKED
SPNA STATUS PROCESS NOT ABLE TO BE ABORTED
SPNF STATUS PROCESS NOT FOUND
SRAC STATUS REQUESTED ACCESS CONFIGURATION IS INVALID
SRAN STATUS UNABLE TO RELEASE ACCESS SYSTEM
SRCI STATUS REQUESTED COMMAND(S) INHIBITED
D–5

Error
SRCN STATUS REQUESTED CONDITION ALREADY EXISTS
SROF STATUS REQUESTED OPERATION FAILED
SROS STATUS REQUIRED RTU OUT OF SERVICE
SRQN STATUS INVALID REQUEST
SRTN STATUS UNABLE TO RELEASE TAP
SRTO STATUS REPLY TIMEOUT OCCURRED
SSCE STATUS SYSTEMIC (SNIDER) COMMUNICATIONS ERROR
SSNG STATUS SUBRATE SELECTED IS INCORRECT
SSNP STATUS TEST SIGNAL NOT PSEUDO-RANDOM
SSNQ STATUS TEST SIGNAL NOT QRS
SSPN STATUS SPEED SELECTED IS INCORRECT
SSRD STATUS SWITCH REQUEST DENIED
SSRE STATUS SYSTEM RESOURCES EXCEEDED
SSTP STATUS EXECUTION STOPPED DUE TO HARDWARE OR SOFTWARE
PROBLEM
STAB STATUS TEST ABORTED
STLC STATUS TAP UNABLE TO LOCATE CHANNEL
STNO STATUS TSC/RTU TO TAU LINK OUT OF SERVICE
STOS STATUS TEST ACCESS UNIT OUT OF SERVICE
STTI STATUS TAP IDLE
SWFA STATUS WORKING UNIT FAILED
SWLD STATUS WORKING UNIT LOCKED
a. Network Element Failure - Circuit Restored to Last Condition - Monitor - (or) Terminate (and Leave).
b. For historical reasons, ICNV and IICM have been left in as valid error codes even though from
inspection they are not unique (descriptions for both say Invalid Command). ICNV and IICM are not
the preferred error codes for invalid, that is, unsupported commands by a Test System Controller
(TSC) or NE. Where possible, specific DENY messages associated with a particular command should
be used. However, when used, the ICNV is appropriate for responses originating from a TSC, and
IICM is the choice for an NE.
c. An identical error code found in GR-833-CORE (SNOS STATUS, NOT CURRENTLY OUT OF
SERVICE) is omitted here and will be removed from the list of valid error codes in a subsequent issue
of GR-833-CORE.
D–6
Issue 1, November 1996 References
References References
Bellcore Documents
• BR-751-000-101, COMMON LANGUAGE® Codes And Abbreviations - Summary Of
Published Practices, Bellcore [Available Under License], Issue 9 (Bellcore,
July 1994).
• ST-STS-000122, Place Code Description, Bellcore, Science and Technology, Issue 2
(Bellcore, June 1990).
• FR-439, Operations Technology Generic Requirements (OTGR), (Bellcore, 1996
Edition).
• GR-199-CORE, OTGR Section 12.2: Operations Application Messages - Memory
Administration Messages (a module of OTGR, FR-439), Issue 2 (Bellcore,
November 1996).
• TR-TSY-000825, OTGR Section 10.A: User System Interface — User System
Language (USL) (a module of OTGR, FR-439), Issue 2 (Bellcore, February 1988).
• TR-TSY-000827, OTGR Section 11.1: Generic Operations Interfaces — Non-OSI
Communications Architecture (a module of OTGR, FR-439), Issue 1 (Bellcore,
November 1988).
• TR-NWT-000831, OTGR Section 12.1: Operations Application Messages - Language
for Operations Application Messages (a module of OTGR, FR-439), Issue 3 (Bellcore,
July 1993), plus Revision 1, December 1993. [Replaced by this GR.]
• GR-833-CORE, OTGR Section 12.3: Operations Application Messages — Network
Maintenance: Network Element and Transport Surveillance Messages (a module of
OTGR, FR-439), Issue 2 (Bellcore, November 1996).
• GR-834-CORE, OTGR Section 12.4: Operations Application Messages —Network
Maintenance: Access and Testing Messages (a module of OTGR, FR-439), Issue 2
(Bellcore, November 1996).
Non-Bellcore Documents
• ANSI T1.201-1987, American National Standard For Telecommunications -
Information Interchange - Structure For The Identification Of Location Entities For
The North American Telecommunications System, 1987, New York, American
National Standards Institute.
• ANSI T1.205-1988, American National Standard For Telecommunications -
Information Interchange - Representation Of Places, States Of The United States,
Provinces And Territories Of Canada, Countries Of The World And Other Unique
References–1
References Issue 1, November 1996
Areas For The North American Telecommunications System, 1988, New York,
American National Standards Institute.
• CCITT X.25, CCITT Recommendation X.25, Interface Between Data Terminal
Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals
Operating in the Packet Mode and Connected to Public Data Networks by Dedicated
Circuit, International Telephone and Telegraph Consultative Committee, International
Telecommunications Union, 1988.
• CCITT Z.300, CCITT Recommendations Z.311 - Z.318 and Recommendation Z.341,
International Telephone and Telegraph Consultative Committee, International
Telecommunications Union, November 1984.
NOTE:
All Bellcore documents are subject to change, and their citation in this document reflects
the most current information available at the time of this printing. Readers are advised to
check current status and availability of all documents.
To obtain Bellcore documents, contact:

8 Corporate Place, Room 3A-184
1-800-521-CORE (2673) (USA & Canada)
(908) 699-5800 (all others)
(908) 336-2559 (FAX)
BCC personnel should contact their company document coordinator, and Bellcore
personnel should call (908) 699–5802 to obtain documents.
To obtain ITU-T (formerly CCITT) documents, contact:

U.S. Department of Commerce
National Technical Information Service
5285 Port Royal Road
Springfield, VA 22161
(703) 487-4650
References–2
Issue 1, November 1996 Glossary
Glossary Glossary
AID — Access Identifier
AIN — Advanced Intelligent Network
ASCII — American Standard Code for Information Interchange
AT&T — American Telephone and Telegraph
ATAG — Autonomously Generated Correlation Tag
BNF — Backus-Naur Form
CCITT — International Telegraph and Telephone Consultative Committee
CF — Contingency Flag
CGA — Carrier Group Alarm
CTAG — Correlation Tag
DN — Directory Number
DS0 — Digital Signal 0
DS0B — Digital Signal 0B
GB — General Block
IP — In Progress
ITU-T — International Telecommunication Union - Telecommunications Standardization
Sector (successor to CCITT)
LAPB — Link Access Procedure, Balanced
NA — No Acknowledgment
NE — Network Element
NG — No Good
NTE — Network Transport Element
MML — Human-Machine Language (formerly Man-Machine Language)
OE — Office Equipment
OK — OK or All Right
ON — Order Number
Glossary–1
Glossary Issue 1, November 1996
OS — Operations System
OSI — Open Systems Interconnection
OTGR — Operations Technology Generic Requirements
PAD — Packet Assembler/Disassembler
PF — Printout Follows
QRS — Quasi-Random Signal
RL — Repeat Later
RTU — Remote Test Unit
SID — System Identifier
SLHR — Service Logic Host Route
TAP — Test Access Point
TAU — Test Access Unit
TI — Trigger Item
TID — Target Identifier
TL1 — Transaction Language 1
TSC — Test System Controller
TSN — Test Session Number
USL — User System Language
Glossary–2

3FE-23235-4223-DFZZA-01P01-CRAFT Language For Application Messages

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3FE-23235-4223-DFZZA-01P01-CRAFT Language For Application Messages

Uploaded by

Copyright:

Available Formats

GENERIC REQUIREMENTS

This document, GR–831–CORE, Issue 1, November 1996 replaces:

TR-NWT-000831, Issue 3 and Revision 1.

For ordering information, see the References section of this document.

Copyright  1996 Bellcore.

Project funding year: 1996.

This Generic Requirements document is published by Bell Communications Research, Inc.

OTGR Contents and Ordering Information

Operations Application Messages - Language for

2.7.3 Case Sensitivity................................................................................2–11

6.3.2 Autonomously Generated Correlation Tag (<atag>) .........................6–3

List of Figures Figures

Figure 1-1. TL1 Message Taxonomy/Classification ...................................................1–2

List of Tables Tables

Table 2-1. Syntax Definitions ....................................................................................2–2

Bellcore’s Interactive GR Process

Comments and Issues List Report Mechanism

Bellcore encourages and welcomes nonproprietary comments on the content and

GR–831–CORE Relative Maturity Level, Status, and Plans

3. Specific Technical Comments

Where and When to Submit Comments

1.1 Transaction Language 1 (TL1)

Transaction Language 1 (TL1) is defined for OS/NE (machine-to-machine) interfaces. TL1

American Standard Code for Information Interchange (ASCII) characters. Appropriate

COMMAND ACKNOWLEDGEMENT RESPONSE AUTONOMOUS

Figure 1-1. TL1 Message Taxonomy/Classification

1.2 Organization of Document

This GR is organized as follows:

• Section 2, TL1 Message Specification, defines the language structures, specification

1.3 TL1 Historical Perspective

Specification of all aspects of messages used in such transactions, in sufficient detail to

* CCITT has been changed to the International Telecommunication Union - Telecommunications

1.4 Requirements Terminology

The following requirements terminology is used throughout this document:

1.5 Requirement Labeling Conventions

1.6 Requirements Statement

The following Requirement is operative throughout this document, GR-831-CORE,

2. TL1 Message Specification

2.1 TL1 General Message Syntax

Table 2-1. Syntax Definitions

< > Encloses a symbol specifier

2.1.1 Input versus Output

2.2 Characters and Information Units

2.2.2 Symbolic Names

2.2.3 Decimal Numbers

2.2.4 Nondecimal Numbers

2.2.5 Text Strings

2.2.6 Arithmetic Expressions

2.2.7 Keyed Numbers

2.2.8 Numeric String

An integer is either a numeric string or an arithmetic expression not containing a period

2.2.10 Inner String

2.3 Parameter Block Syntax

2.3.1 Position-Defined Parameters

In a block of position-defined parameters, the individual parameters must be entered in a

2.3.2 Name-Defined Parameters

2.3.3 Name/Position Syntax Conflicts

2.4 Boolean Flag Parameters

2.5 Defining a Parameter Block

2.5.1 Parameter Specification

2.5.2 Block Type Selection

2.6 Defining Parameter Values