401

323-1061-401
SDH TRANSMISSION
Nortel TN-1X
Command Line User Interface Guide
Release 9 Standard July 2001

SDH TRANSMISSION
Nortel TN-1X
Document Number: 323-1061-401

Document Status: Standard
Product Release Number: 9
Date: July 2001
Copyright  1997 – 2001 Nortel Networks, All Rights Reserved.
Printed in England
The copyright of this document is the property of Nortel Networks. Without the written consent of Nortel Networks, given by contract
or otherwise, this document must not be copied, reprinted or reproduced in any material form, either wholly or in part, and the
contents of this document, or any methods or techniques available therefrom, must not be disclosed to any other person
whatsoever.
NORTEL NETWORKS CONFIDENTIAL: The information contained herein is the property of Nortel Networks and is strictly
confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein
confidential, shall disclose it only to its employees with a need to know, and shall protect it, in whole or in part, from disclosure and
dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than
reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information
contained herein.
So far as Nortel Networks is aware the contents of this document are correct. However, such contents have been obtained from a
variety of sources and Nortel Networks can give no warranty or undertaking and make no representation as to their accuracy. In
particular, Nortel Networks hereby expressly excludes liability for any form of consequential, indirect or special loss, and for loss of
data, loss of profits or loss of business opportunity, howsoever arising and whether sustained by the user of the information herein
or any third party arising out of the contents of this document.
*
NORTEL NETWORKS, the Nortel Networks logo, the Globemark and Unified Networks are trademarks of Nortel Networks.
Microsoft and Windows are trademarks of Microsoft Corporation. HyperTerminal is a trademark of Hilgraeve Inc.
IBM is a trademark of International Business Machine Inc. Hewlett-Packard is a trademark of Hewlett-Packard Company.
Nortel TN-1X Command Line User Interface Guide

iii
Publication history
July 2001
Release 9 Standard
November 1998
Release 8 Standard (Revision 2)
October 1998
Release 8 Standard (Revised)
September 1998
Release 8 Standard
April 1998
November 1997
October 1997
Release 7 Standard

v
Contents
About this document xv
Related documents xv
Technical support and information xvi
Introduction 1-1
The structure of the UI 1-1
Using this book 1-3
User interface 2-1

Menu structure 2-1
Command prompt 2-2
Command shortcuts 2-2
KLM payload numbering 2-3
Parameters 2-4
Parameter notation 2-4
PDH ports 2-4
SDH tributary payloads 2-5
SDH aggregate payloads 2-6
SDH high order payloads 2-7
SDH ports 2-8
Confirmation 2-9
Message types 2-9
Response (non-autonomous) messages 2-9
Autonomous messages 2-11
Getting started 3-1

Accessing the UI application software 3-1
Logging in 3-1
Logging out 3-4
Configuration menu 4-1

Config/Pps <C P> 4-2
Path protection switching 4-2
Command details 4-3
Parameters 4-4
Autonomous events 4-5
Reports 4-5
Config/cOmms_management <C O> 4-6
Communications management 4-6
Command details 4-7
Parameters 4-9

vi
Reports 4-10
Config/External_alarm <C E> 4-11
External alarms 4-11
Command details 4-11
Parameters 4-12
Reports 4-12
Config/Alarms/Thresholds <C A T> 4-14
Alarm thresholds 4-14
Parameters 4-15
Reports 4-16
Config/Alarms/Monitoring <C A M> 4-17
Alarm monitoring 4-17
Parameters 4-19
Reports 4-19
Config/Alarms/Rau_priority <C A R> 4-21
RAU priority 4-21
Parameters 4-27
Reports 4-28
Config/Alarms/misC <C A C> 4-31
Lamplocking 4-31
Parameters 4-31
Reports 4-32
Config/perF_mon <C F> 4-33
Performance monitoring 4-33
Parameters 4-45
Reports 4-47
Config/Sync_source <C S> 4-51
Synchronisation source protection 4-51
Parameters 4-58
Reports 4-59
Config/Cons_act <C C> 4-60
Consequent actions 4-60
Parameters 4-64
Reports 4-65
Config/Lp_path_Trace <C LT> 4-66
Low order path tracing 4-66
Parameters 4-68
Reports 4-68
323-1061-401 Release 9 Standard

vii
Config/Hp_path_trace <C H> 4-70

High order path tracing 4-70
Parameters 4-72
Reports 4-72
Config/Lp_paYload_label <C LY> 4-74
Low order payload labels 4-74
VC-3 payload labels 4-75
Parameters 4-76
Reports 4-76
Config/Hp_paYload_label <C HY> 4-78
High order payload labels 4-78
Parameters 4-80
Reports 4-80
Config/coNnections <C N> 4-82
Connection management 4-82
Dropped AU-4 selection 4-82
Connection types 4-82
Defragmenting the TN-1X internal bus 4-84
General rules for adding new connections 4-85
Adding connections 4-88
Disconnections 4-88
Bulk connections and disconnections 4-89
Testing connections 4-89
User labels 4-89
Parameters 4-93
Reports 4-94
Config/carDs <C D> 4-97
Equipping 4-97
Parameters 4-102
Reports 4-102
Config/Payman_Protect <C PP> 4-106
Payload Manager protection 4-106
Parameters 4-107
Reports 4-108
Config/Trib_Protect <C TP> 4-109
1:N tributary protection 4-109
Auto-reversion 4-110
Parameters 4-112
Reports 4-112
Config/poRts <C R> 4-113
Raising signal alarms 4-113

viii

Parameters 4-115
Reports 4-116
Config/MSp <C MS> 4-118
Multiplexer section protection 4-118
MSP configurations 4-119
Bidirectional and unidirectional operation 4-120
Switching conditions 4-122
MSP protocol 4-122
MSP alarms 4-125
MSP LAPD settings 4-126
Converting protected connection to unprotected connections 4-126
Parameters 4-129
Reports 4-130
Config/tn1x_Card_Switch <C CS> 4-132
Manual 1:1 tributary protection 4-132
Parameters 4-134
Reports 4-134
Config/PunchThrough <C PT> 4-135
Parameters 4-136
Reports 4-137
Config/oVerride <C V> 4-138
Overided 4-138
Parameters 4-138
Reports 4-139
Diagnostic menu 5-1

Diagnostic/Loopback <D L> 5-2
Loopbacks 5-2
Command details 5-4
Parameters 5-4
Reports 5-5
Maintenance menu 6-1

Maint <M> 6-2
Terminating performance monitoring prematurely 6-2
Reading and resetting the mux clock 6-2
Manually switching a protected path 6-2
Manually switching a 1:1 protected 34/45M tributary unit 6-2
Command details 6-3
Parameters 6-4
Reports 6-5

ix
View status menu 7-1

View_status <V> 7-2
Overview of status reports 7-2
Performance logs 7-3
Command details 7-6
Parameters 7-7
Reports 7-8
Session menu 8-1

Session <S> 8-2
Session characteristics 8-2
Command details 8-3
Parameters 8-5
Responses 8-5
Reports 8-5
Administration menu 9-1

Admin/Sw <A S> 9-2
Overview of application software 9-2
Software status 9-4
Downloading application software 9-4
Working with original and downloaded software 9-11
Committing to downloaded software 9-11
Parameters 9-14
Reports 9-15
Admin/Cnfg_tbl <A C> 9-16
Overview of configuration tables 9-16
Configuration table status 9-18
Restoring an archived configuration table 9-18
Working with original and restored configuration tables 9-22
Committing to a restored configuration table 9-22
Detached mode 9-22
Backing up the configuration table 9-24
Parameters 9-30
Reports 9-31
Admin/User <A U> 9-32
User management 9-32
Changing passwords 9-32
Parameters 9-33
Reports 9-34
Appendix A: Craft Access Terminal 10-1
Appendix B: TN-1X alarms 11-1
Appendix C: TN-1X Messages 12-1

x
Appendix D: KLM payload numbering 13-1
Index 14-1
Figures
Figure 3-1 Example login, NE status information and main user menu 3-3
Figure 4-1 Configuration command hierarchy 4-1
Figure 4-2 Config/Pps command hierarchy 4-3
Figure 4-3 Config/cOmms command hierarchy 4-7
Figure 4-4 Config/External_alarm command hierarchy 4-11
Figure 4-5 Config/Alarms/Thresholds command hierarchy 4-14
Figure 4-6 Config/Alarms/Monitoring command hierarchy 4-17
Figure 4-7 Config/Alarms/Rau_priority command hierarchy 4-22
Figure 4-8 Config/Alarms/misC command hierarchy 4-31
Figure 4-9 Config/perF_mon command hierarchy 4-38
Figure 4-10 SSM within an STM-N ring 4-54
Figure 4-11 Config/Sync_source command hierarchy 4-56
Figure 4-12 Config/Cons_act command hierarchy 4-62
Figure 4-13 Config/Lp_path_Trace command hierarchy 4-67
Figure 4-14 Config/Hp_path_trace command hierarchy 4-71
Figure 4-15 Config/Lp_paYload_label command hierarchy 4-75
Figure 4-16 Config/Hp_paYload_label command hierarchy 4-79
Figure 4-17 TN-1X connection types 4-83
Figure 4-18 Config/coNnections command hierarchy 4-90
Figure 4-19 Config/carDs command hierarchy 4-99
Figure 4-20 Config/Payman_Protect command hierarchy 4-107
Figure 4-21 Config/Trib_Protect 4-111
Figure 4-22 Config/poRts 4-114
Figure 4-23 MSP configurations 4-119
Figure 4-24 MSP protection between rings 4-119
Figure 4-25 Unidirectional operation 4-120
Figure 4-26 Bidirectional operation 4-121
Figure 4-27 Config/MSp command hierarchy 4-127
Figure 4-28 Config/tn1x_Card_Switch command hierarchy 4-133
Figure 4-29 Config/PunchThrough command hierarchy 4-135
Figure 4-30 Config/oVeride command hierarchy 4-138
Figure 5-1 Diagnostic menu structure 5-1
Figure 5-2 Overview of loopbacks 5-2
Figure 5-3 Diagnostic/Loopback menu structure 5-4
Figure 6-1 Maintenance menu structure 6-1
Figure 7-1 View_status menu structure 7-1
Figure 8-1 Session menu structure 8-1
Figure 9-1 Administration menu structure 9-1
Figure 9-2 An overview of the software download mechanism 9-3
Figure 9-3 Admin/Sw menu structure 9-12
Figure 9-4 An overview of restoring a configuration table 9-17
Figure 9-5 Admin/Cnfg_tbl menu structure 9-28
Figure 9-6 Admin/User menu structure 9-33
Tables
Table 2-1 PDH tributary units 2-4
Table 2-2 SDH tributary units 2-5
Table 2-3 SDH aggregate units 2-6
Table 2-4 SDH high order payloads 2-7

xi
Table 2-5 SDH ports 2-8

Table 2-6 Traffic types for the TN-1X 2-12
Table 3-1 Users and passwords 3-1
Table 4-1 Alarm triggers for path protection switching 4-2
Table 4-2 Config/Pps 4-3
Table 4-3 Config/Pps/pps_mode_Off 4-4
Table 4-4 Config/cOmms_management 4-7
Table 4-5 Config/cOmms_management/lapd_link_Service 4-8
Table 4-6 Config/cOmms_management/laN_service 4-8
Table 4-7 Config/cOmms_management/Area_address 4-9
Table 4-8 Config/External_alarm/Input 4-12
Table 4-9 Config/External_alarm/Input/RAU_priority 4-12
Table 4-10 Config/Alarms/Thresholds 4-15
Table 4-11 Config/Alarms/Thresholds/<MS_deg | HP_deg | Hp_rEi> 4-15
Table 4-12 Config/Alarms/Thresholds/<Lp_eXc | Ms_eXc> 4-15
Table 4-13 Config/Alarms/Monitoring/<PMP> 4-18
Table 4-14 Config/Alarms/Monitoring/MS/<MS_alarm> 4-18
Table 4-15 Config/Alarms/Monitoring/HP/<HP_alarm> 4-18
Table 4-16 Config/Alarms/Monitoring/<LP | PPI>/<PDH_alarm> 4-19
Table 4-17 Config/Alarms/Rau_priority/Os 4-22
Table 4-18 Config/Alarms/Rau_priority/Es 4-23
Table 4-19 Config/Alarms/Rau_priority/Rs 4-23
Table 4-20 Config/Alarms/Rau_priority/Ms 4-23
Table 4-21 Config/Alarms/Rau_priority/Au 4-24
Table 4-22 Config/Alarms/Rau_priority/Hp 4-24
Table 4-23 Config/Alarms/Rau_priority/Tu 4-24
Table 4-24 Config/Alarms/Rau_priority/Lp 4-25
Table 4-25 Config/Alarms/Rau_priority/Ppi 4-25
Table 4-26 Config/Alarms/Rau_priority/Sync 4-26
Table 4-27 Config/Alarms/Rau_priority/TM 4-26
Table 4-28 Config/Alarms/Rau_priority/misC 4-26
Table 4-29 Config/Alarms/Rau_priority/prOT 4-27
Table 4-30 Config/Alarms/Rau_priority/carD 4-27
Table 4-31 Config/Alarms/Rau_priority/<alarm group>/<alarm> 4-27
Table 4-32 Config/Alarms/misC 4-31
Table 4-33 Performance monitoring points (PMPs) and performance statistics
4-36
Table 4-34 Config/perF_mon 4-38
Table 4-35 Config/perF_mon/Ses_defines 4-39
Table 4-36 Config/perF_mon/<15M | 24H> 4-39
Table 4-37 Config/perF_mon/<15M | 24H>/<RS_ne | MS_ne> 4-40
Table 4-38 Config/perF_mon/<15M | 24H>/<HP_ne | Hp_Fe> 4-40
Table 4-39 Config/perF_mon/<15M | 24H>/<LP_ne | Lp_Fe | Ppi_Cv |
Ppi_cRc> 4-41
Table 4-40 Config/perF_mon/<15M | 24H>/Rs_Oof 4-41
Table 4-41 Config/perF_mon/<15M | 24H>/Au_pJe 4-42
Table 4-42 Config/perF_mon/<15M | 24H>/Tu_pJe> 4-42
Table 4-43 Config/perF_mon/Uat 4-42
Table 4-44 Config/perF_mon/Uat/<RS_ne | MS_ne> 4-43
Table 4-45 Config/perF_mon/Uat/<HP_ne | Hp_Fe> 4-43
Table 4-46 Config/perF_mon/<15M | 24H | Uat>/<LP_ne | Lp_Fe | Ppi_Cv>
4-44
Table 4-47 Config/perF_mon/Uat/Ppi_cRc/ 4-44
Table 4-48 Config/perF_mon/Start_24h 4-44
Table 4-49 Config/perF_mon/Basis 4-44

xii
Table 4-50 A typical synchronisation protection hierarchy 4-51

Table 4-51 SSM quality levels 4-54
Table 4-52 Config/Sync_source 4-57
Table 4-53 Config/Cons_act 4-63
Table 4-54 Config/Cons_act/ne_Hp_Tim 4-63
Table 4-55 Config/Cons_act/ne_Hp_Plm 4-63
Table 4-56 Config/Cons_act/ne_Ms_Deg 4-63
Table 4-57 Config/Cons_act/ne_Lp_Plm 4-63
Table 4-58 Config/Cons_act/ne_Lp_Exc 4-64
Table 4-59 Config/Cons_act/ne_Lp_Tim 4-64
Table 4-60 Config/Cons_act/ne_Ppi_Ais 4-64
Table 4-61 Config/Cons_act/individUal/Ppi_Ais 4-64
Table 4-62 Config/Lp_path_Trace 4-67
Table 4-63 Config/Hp_path_trace 4-71
Table 4-64 Low order VC-12 payload labels 4-74
Table 4-65 Low order VC-3 payload labels 4-75
Table 4-66 Config/Lp_paYload_label 4-76
Table 4-67 High order payload labels 4-78
Table 4-68 Config/Hp_paYload_label 4-79
Table 4-69 Config/coNnections 4-90
Table 4-70 Config/coNnections/deFrag 4-92
Table 4-71 Config/coNnections/View 4-92
Table 4-72 Cards and slots 4-98
Table 4-73 Config/carDs 4-99
Table 4-74 Config/carDs/Equip 4-99
Table 4-75 Config/carDs/Equip/Icc 4-100
Table 4-76 Config/carDs/Equip/stm_1_Trib 4-100
Table 4-77 Config/carDs/Equip/stm_1_Agg 4-100
Table 4-78 Config/carDs/Equip/stm_4_Agg 4-100
Table 4-79 Config/carDs/Equip/2M_trib 4-101
Table 4-80 Config/carDs/Equip/Payload_Man 4-101
Table 4-81 Config/carDs/Equip/16x2m 4-101
Table 4-82 Config/carDs/Equip/34_45M 4-101
Table 4-83 Card types for the TN-1X 4-102
Table 4-84 Config/Payman_Protect 4-107
Table 4-85 Config/Payman_Protect/pm_switch_Off 4-107
Table 4-86 Config/Trib_Protect 4-111
Table 4-87 Config/Trib_Protect/Mode 4-111
Table 4-88 Config/poRts 4-114
Table 4-89 Config/poRts/Bitrate 4-115
Table 4-90 Config/poRts/sIgnal_structure 4-115
Table 4-91 K1 byte (bits 1 to 4) usage 4-123
Table 4-92 K1 byte (bits 5 to 8) usage 4-124
Table 4-93 K2 byte usage 4-124
Table 4-94 Config/MSp 4-127
Table 4-95 Config/MSp/Mode 4-128
Table 4-96 Config/MSp/K_byte_override 4-128
Table 4-97 Config/MSp/Request 4-128
Table 4-98 Config/MSp/Lapd_monitoring 4-129
Table 4-99 Config/tn1x_Card_Switch 4-133
Table 4-100 Config/PunchThrough 4-135
Table 4-101 Config/oVeride 4-138
Table 5-1 Diagnostic/Loopback 5-4
Table 6-1 Maint/Operations/perF_mon/early_Termination 6-3
Table 6-2 Maint/Operations/Clock 6-3

xiii
Table 6-3 Maint/Operations/Pps 6-3

Table 6-4 Maint/Card_Switch 6-3
Table 7-1 Update log report status codes 7-4
Table 7-2 View_status 7-6
Table 7-3 View_status/Perf_Intermediate 7-7
Table 8-1 Session 8-3
Table 8-2 Session/Unsolicited 8-3
Table 8-3 Session/Mode 8-4
Table 8-4 Session/Auto_logout 8-4
Table 8-5 Session/misC 8-4
Table 8-6 Session/Punchthrough 8-5
Table 9-1 Admin/Sw 9-12
Table 9-2 Admin/Cnfg_tbl 9-29
Table 9-3 Admin/User 9-33
Table 10-1 Craft Access Terminal (CAT) platform 10-1
Table 10-2 CAT interface parameters 10-1
Table 11-1 TN-1X R9 alarms 11-1
Table 13-1 KLM numbering for VC-3 13-1
Table 13-2 KLM numbering for VC-12 13-1
Procedures
Procedure 3-1 Logging in to the TN-1X from the CAT 3-2
Procedure 3-2 Logging
3-2 in to the TN-1X from the Preside EC-1 Element Controller
Procedure 9-1 Preparing the application software on the CAT 9-5
Procedure 9-2 Downloading application software from the CAT 9-5
Procedure 9-3 Preparing the application software on the Preside EC-1 Element
Controller 9-8
Procedure 9-4 Downloading application software from the Preside EC-1 Element
Controller 9-8
Procedure 9-5 Restoring a configuration table from the CAT 9-19
Procedure 9-6 Restoring a configuration table from the EC-1 9-21
Procedure 9-7 Backing up a configuration table to the CAT 9-24
Procedure 9-8 Backing up a configuration table to the EC-1 9-27
Procedure 9-9 Changing passwords 9-32
Procedure 10-1 Setting up HyperTerminal 10-2
Procedure 10-2 Starting a CAT session on HyperTerminal 10-3

xv
About this document

The purpose of this document is to provide user information for the facilities
provided by the User Interface (UI) of the TN-1X at Release 9.
For an overview of the capabilities and applications of the TN-1X Add-Drop

Multiplexer (ADM) see the Nortel TN-1X System Description, Release 9
(NTP 323-1061-100).
User menus and graphical representations of the UI hierarchical menu

structure are shown throughout the document. Example system reports are
provided where appropriate for each menu item, the content of which may be
regarded as typical.
Indication of trademarks in this document

The asterisk after a name denotes a trademarked item. The title page and back
cover acknowledge all trademarked items.
Related documents
The following documents are referenced within this book:
1 Nortel TN-1X System Description, Release 9 (NTP 323-1061-100).
2 Nortel TN-1X Software Administration, Release 9 (NTP 323-1061-303).
3 Nortel TN-1X Browser User Interface Guide, Release 9
(NTP 323-1061-403).
4 Nortel TN-1X Alarm Clearing Procedures, Release 9
(NTP 323-1061-543).
5 Nortel TN-1X Module Replacement Procedures, Release 9
(NTP 323-1061-547).
6 Preside EC-1 Element Controller User Procedures, Release 14
(NTP 323-1091-402).

xvi
Technical support and information

As far as Nortel Networks knows, the information in this document is correct.
If, however, you discover any errors or have comments about the arrangement
of the content, send details by email to:
IONNTPS@nortelnetworks.com
Nortel Networks provides a full technical support service for its customers.
The Nortel Networks Service Desk can be called at any time on the following
numbers:
Within Europe: Freephone 00800 8008 9009
Outside of Europe: +44 20 8920 4618
Fax within the United Kingdom: 020 8945 3456
Fax outside of the United Kingdom: +44 20 8945 3456
As an option, you can contact technical support through the Nortel Networks
web site:
www.nortelnetworks.com
and by selecting Customer Support.
EMC/Safety conformance
This product/product family complies with the essential
protection requirements of the EMC Directive 89/336/EEC as
amended by 92/31/EEC, when it is properly installed and
maintained and when it is used for the purposes for which it is
intended.

1-1
Introduction 1-
The Nortel Networks TN-1X Command Line User Interface (UI) of the
TN-1X enables the user to access, configure and control the TN-1X add-drop
multiplexer (Network Element/NE). The command line user interface sits
between the user and the mux’s application software, and is accessed via:
• A Craft Access Terminal (CAT). This is an IBM* compatible Personal
Computer (PC) running Microsoft* Windows 3.1/Windows95 and
terminal emulation software. The PC communicates with the NE via an
RS232-C interface connected to the network element’s CAT interface.
• A Preside EC-1 Element Controller. This is a Hewlett-Packard* (HP)
workstation platform running the HP-UX 10.20 operating system and the
Preside EC-1 Element Controller management software. The Preside EC-1
Element Controller communicates with the NE via a Local Area Network
(LAN).
Note: A point-and-click interface to the mux’s application software is

available using the Browser User Interface. This software, which is
accessed via Netscape* Navigator on either of the above platforms, is
described in the TN-1X Browser User Interface Guide (see “Related
documents” on page xv).
The structure of the UI

The UI is text-based, and is structured as a hierarchical message set. The UI
provides access to the following functionality on the TN-1X NE:
• Viewing and reporting on all aspects of NE operations.
— Display of system messages, alarms and events in real time.
— Generation of alarm and event logs.
— Performance monitoring.
— Status of system settings.
• Diagnostics actions:
— Loopbacks.

1-2 Introduction
• Maintenance actions:
— Terminating performance monitoring.
— Setting the mux clock.
— Manual VC-12/VC-3 path protection switching.
— Manual VC-3 1:1 tributary protection switching.
• Configuring the NE:
— Card configuration.
— Connection management.
— Communications management.
— Path protection switching.
— Multiplexer section protection switching.
— Performance monitoring.
— Alarms management.
— External alarms.
— Synchronisation source protection.
— Consequent actions.
— Low-order path tracing.
— High-order path tracing.
— Low-order payload label definition.
— High-order payload label definition.
— Payload manager protection.
— 1:N Tributary protection.
— 1:1 manual tributary protection.
• User interface session management.
• Software and configuration table management.
• User administration.
The UI provides three different user classes, available from the CAT and the
Preside EC-1 Element Controller (see “Accessing the UI application
software” on page 3-1). Each user class has different access privileges.
The TN-1X maintains a configuration table in non-volatile memory to save

custom parameter settings in the event of a system crash. Further built-in
defaults enable system re-starts when the user defaults cannot be recovered
from the user configuration tables.

Introduction 1-3
Using this book

The structure of this NTP is as follows:
• Chapter 1, “Introduction” (this chapter) - introductory information.
• Chapter 2, “User interface” - overview information about the user
interface.
• Chapter 3, “Getting started” - logging into the NE.
• Chapter 4, “Configuration menu” - NE configuration commands.
• Chapter 5, “Diagnostic menu” - signal loopback commands.
• Chapter 6, “Maintenance menu” - manual operation commands.
• Chapter 7, “View status menu” - NE status enquiry commands.
• Chapter 8, “Session menu” - user interface session commands.
• Chapter 9, “Administration menu” - management of NE application
software management, configuration tables and user details.
• Appendix A: Craft Access Terminal - Platform and configuration details
for the Craft Access Terminal.
• Appendix B: TN-1X alarms - The equivalent alarm names that were used
up to TN-1X R6 are also listed.
• Appendix C: TN-1X Messages - the warning and error messages that are
produced by the TN-1X application software.
• Appendix D: KLM payload numbering - overview of KLM numbering,
and comparisons with Nortel Networks and ETSI numbering.
end of chapter

2-1
User interface 2-
Menu structure
The User Interface (UI) for the TN-1X has a text-based hierarchical menu tree.
After login, from either the CAT or the Preside EC-1 Element Controller, the
user is positioned at the top level of the menu tree. This is formatted as the
example below:
Config/, View_status/, Session/, Admin/, Maint/,
Diagnostic/, Logout
TN-1X /
>>
The first two lines show a list of menu options and the bottom line shows the
path (the user’s position in the menu tree) and command prompt. In this case,
at the root (the top level of the menu tree), the path is shown as a single ‘/’
character.
Menu items which have subordinate menu levels are suffixed with the ‘/’
character. Menu items without a suffix are commands in the current menu.
The user is able to move down the menu hierarchy or execute commands by
typing the desired menu item name, or a shorthand version of this name. The
UI is line oriented, and as such it requires a carriage return after each user
request. No processing takes place until a return has been pressed.
Note: The user interface is not case sensitive.
When the menu level changes, the new level of the menu structure is
displayed.
When commands are executed, additional parameters are often required. If

these are not entered by the user, an error message informs the user, and help
text is displayed.
An error message is displayed if the user input is not recognized. In this

instance, the menu is displayed again.
Two special characters can be used to move around the menu system:
• The asterisk character (*). This moves the user up one level in the
command hierarchy.

2-2 User interface
• The tilde character (~). This moves the user to the top (root) of the
command hierarchy.
Command prompt
The command prompt (>>) is printed beneath a block of information that
includes the current menu, and an indication of the user’s location in the menu
hierarchy. In almost all instances, the location always begins with “TN-1X”,
followed by menu names separated by slashes.
For example, when accessing the area address submenu, the following
information is displayed:
Set_1, Set_2, Set_3, Clear_1, Clear_2, Clear_3, View,
*=go back, ~=go to root
TN-1X /Config/cOmms_management/Area_address/
>>
If the TN-1X is in detached mode (see “Detached mode” on page 9-22), the
location is preceded by an indication of detached mode. That is:
TN-1X [DETACHED]/Config/cOmms_management/Area_address/
>>
Command shortcuts
There are three methods of entering commands:
• The user can type the entire command, such as ‘config’.
• The user can type three or more letters to uniquely identify the command.
These letters must be the first letters of the command name.
• The user can type a shortcut for the command. The letters included in the
shortcut are displayed in upper case in the command name, though the user
does not need to type these as upper case letters.
Note: Where numbers are included in the shortcut, the entire shortcut is
shown in square brackets after the command name.
It is possible to move through more than one menu level with a single entry.
This is achieved by typing a sequence of space-separated commands. For
example:
c e i v ↵
This is the equivalent of typing:

config ↵
external_alarm ↵
input ↵
view ↵
For all methods, when carriage return is pressed, the user input is checked to
see whether it matches a command shortcut. If it does not, and three or more
letters have been typed, the input characters are compared with the names of
menu items. If a single command can be identified uniquely by the partial

User interface 2-3
command entered, this command is selected. Where a command cannot be

identified, an error is returned.
For example, on the configuration menu, two of the commands are:

coNnections, and Cons_act
In accordance with the single letter shortcuts:

N ↵ is interpreted as ‘coNnections’
C ↵ is interpreted as ‘Cons_act’
However, if shortened words are used, then:

CO ↵ is rejected, as it is not a shortcut, and has less than three letters.
CON ↵ is rejected, as it does not uniquely identify either command.
CONN ↵ is required to uniquely identify ‘coNnections’.
CONS ↵ is required to uniquely identify ‘Cons_act’.
KLM payload numbering

All references to STM-1 payloads are represented by KLM numbering. KLM
numbering is detailed in Appendix D: KLM payload numbering.

2-4 User interface
Parameters
Many commands require parameters. These are always entered after the
command, each separated by a space, and a carriage return is used to
complete the entry. Throughout this document, where parameters are required
for commands, the parameter is detailed alongside the command. If more
detailed information is available, this is indicated.
Note: Commands received by the NE that have too many parameters

specified will be rejected by the NE.
Parameter notation
Parameters are listed in this book as follows:
• Parameter names are shown inside angle brackets for most purposes. An
example of this is the <SDH_port> parameter, which is used by several
commands. Where a parameter is listed in the parameter column of a
command table, however, these brackets are excluded.
• Text parameters are shown inside single quote marks. These indicate text
that must be typed literally. For example, many of the ‘View’ commands
have an ‘all’ text parameter that can be used to represent all possible
options.
Parameter choices are shown as follows:

• Alternative parameters are indicated by a pipe (|) character. For example,
the following parameter syntax indicates that either the <SDH_port> or
<PDH_port> parameter is required:
SDH_port | PDH_port
• Optional parameters are shown inside square brackets([]). For example, the
following parameter syntax indicates that the <SDH_AU4> parameter and
<HP_path_label> parameter are both required, but that the <CRC>
parameter is optional:
SDH_AU4 HP_path_label [CRC]
PDH ports
PDH ports provide access to non-SDH tributary traffic channels. Aggregate
traffic can be dropped from SDH aggregates to these ports. PDH ports are
available on the following tributary units:
Table 2-1
PDH tributary units
Tributary Unit Slot Number Port Numbers
2M Trib 2, 4, 9, 11 1-16
2M Trib (1:N protection) 3 1-16
34M Trib (16x2M) 2, 4, 9, 11 1-16
34/45M Trib (VC-3) 2, 4, 9, 11 1

User interface 2-5
The parameter syntax for the above ports is as follows:

S<slot>-<port>
Where:
• <slot> is the slot number within the multiplexer.
• <port> is the port number within the denoted slot.
For example, to specify port 3 on the PDH tributary unit in slot 2:

S2-3
SDH tributary payloads

SDH tributary payloads provide access to SDH tributary traffic channels.
Aggregate traffic can be dropped from SDH aggregates to these ports. These
payloads are available on the following tributary units:
Table 2-2
SDH tributary units
Trib Card Slot Number AU4 Number
STM-1 Optical (1”) 2, 4, 9, 11 1
STM-1 Optical (2”) 2, 9 1
STM-1 Electrical (1”) 2, 4, 9, 11 1
STM-1 Electrical (2”) 2, 9 1

S<slot>-<port>-J<AU4>-K<KLM>
Where:
• <port> is the physical port number within the denoted slot. For all current
hardware, this can only be equal to ‘1’. This element of the syntax can be
omitted. In this event, a default value of ‘1’ is assumed.
• <AU4> is the AU4 within the STM-1 signal. As the STM-1 contains just
one AU4, this can only be equal to ‘1’. This element of the syntax can be
omitted, as a default value of ‘1’ is assumed.
• <KLM> identifies a specific payload. See Appendix D: KLM payload
numbering for full details of this numbering system.
For example, to specify K261 on the first (and only) AU4 on an STM-1
tributary unit in slot 2:
S2-1-J1-K261

2-6 User interface
SDH aggregate payloads

SDH aggregate payloads provide access to SDH aggregate traffic channels.
Aggregate traffic can be dropped from SDH aggregates to both SDH and PDH
tributary units, or through connected. These payloads are available on the
following aggregate units:
Table 2-3
SDH aggregate units
Aggregate Card Slot Number AU4 Number
STM-4 Optical 6,7 1, 2, 3, 4
STM-1 Optical 6,7 1
STM-1 Electrical 6,7 1
Note: STM-4 Optical aggregate units are unavailable to order until further notice.

Where:
• <slot> is the slot number within the multiplexer. Aggregate A is positioned
in slot 6, while aggregate B is positioned in slot 7.
Note: It is possible to specify ‘A’ instead of the slot/port reference of
aggregate A (that is, ‘S6-1’), and to specify ‘B’ instead of the slot/port
reference of aggregate B (that is, ‘S7-1’).
omitted in almost all instances. If it is omitted, a default value of ‘1’ is
assumed.
• <AU4> is the AU4 within the STM-N signal.
— An STM-1 aggregate signal contains just one AU4, and can only be
equal to ‘1’. This element of the syntax can be omitted, as a default
value of ‘1’ is assumed.
— An STM-4 aggregate signal contains four AU4s, only one of which can
be accessed by the TN-1X. This element of the syntax can be omitted
if AU4 1 is in use, as a default value of ‘1’ is assumed.
• <KLM> identifies a specific payload. See Appendix D: KLM payload
numbering for full details of this numbering system.
For example, to specify a KLM reference of K261 on the third AU4 of STM-4
aggregate A (slot 6), use one of the following:
S6-1-J3-K261
A-J3-K261

User interface 2-7
SDH high order payloads

SDH high order payloads identify an AU4 on an STM-N aggregate unit, or an
STM-1 tributary unit. SDH payloads exist on the following units:
Table 2-4
SDH high order payloads
SDH Hardware Unit Slot Number AU4 Number
STM-4 Optical Aggregate 6, 7 1, 2, 3, 4
STM-1 Optical Aggregate 6, 7 1
STM-1 Electrical Aggregate 6, 7 1
STM-1 Optical (1”) Tributary 2, 4, 9, 11 1
STM-1 Optical (2”) Tributary 2, 9 1
STM-1 Electrical (1”) Tributary 2, 4, 9, 11 1
STM-1 Electrical (2”) Tributary 2, 9 1

S<slot>-<port>-J<AU4>
Where:
omitted, as a default value of ‘1’ is assumed.
• <AU4> is the AU4 within the STM-N signal. This element of the syntax
can be omitted if AU4 1 is in use, as a default value of ‘1’ is assumed.
For example, to specify the first (and only) AU4 on the STM-1 tributary unit
in slot 9:
S9-1-J1
For example, to specify the third AU4 on aggregate B (slot 7), use one of the
following:
S7-1-J3
B-J3

2-8 User interface
SDH ports
SDH ports identify physical connections to SDH signals. These connections
exist on both STM-N aggregates, and STM-1 tributaries. Currently, all SDH
hardware contains a single physical port. SDH ports exist on the following
units:
Table 2-5
SDH ports
SDH Hardware Unit Slot Number Port Number
STM-1 Electrical Aggregate 6, 7 1
STM-1 Optical (1”) Tributary 2, 4, 9, 11 1
STM-1 Optical (2”) Tributary 2, 9 1
STM-1 Electrical (1”) Tributary 2, 4, 9, 11 1
STM-1 Electrical (2”) Tributary 2, 9 1

S<slot>-<port>
Where:
• <port> is the physical port number within the denoted slot. As all SDH
equipment currently has a single port, this will always be set to ‘1’.
For example, to specify the (only) physical port on an SDH tributary unit in
slot 11:
S11-1
For example, to specify the (only) physical port on aggregate B (slot 7), use
one of the following:
S7-1
B

User interface 2-9
Confirmation
Commands that affect traffic or that delete important information require
additional confirmation. Confirmation messages are accompanied by an
audible warning. The user must enter a response followed by a carriage return.
Any response other than ‘y’ or ‘yes’ is taken to mean no.
Warning: <number> <warning_text>
Are you sure? [yes/no]
For example:
Warning: <3550> Traffic may be hit.
Are you sure? [yes/no]
Confirmation messages can be suppressed by two methods:

• Typing the character sequence <ctrl>a<ctrl>b after any command, before
the carriage return key is pressed. This suppresses confirmation messages
only, and must be typed for every command which is to be suppressed.
• Using the ‘Session/Mode’ commands (see Chapter 8, “Session menu”).
This command enables both confirmation messages and menus to be
suppressed, and applies to all typed commands that are issued
subsequently.
Message types
The TN-1X generates two message categories:
• Response (non-autonomous) messages.
• Autonomous messages.
These message categories are detailed in the sections below.
Response (non-autonomous) messages

These messages are a direct response to user commands. They are numbered,
and have a short explanatory message which may then be followed by optional
text. The format of message responses is as follows:
• The user’s command executed fully:
1, OK. (<message_number>) <information_text>
;
• The user’s command has failed to execute:

2, Invalid. (<message_number>) <information_text>
;
• The user’s command is being executed:

3, In progress. (<message_number>) <information_text>
;
Note: The <information_text> message elements for the above messages

are listed in Appendix C: TN-1X Messages.

2-10 User interface
• When the user’s command requires a long processing time, such as

software download, the command is executed in the background allowing
the user to continue working without interruption:
4, OK. Request is being processed in background.
;
Once the command finishes executing in the background, an autonomous

message is displayed.
• Command selection. This refers to the menu displayed before a command
can be entered. For example:
Set_1, Set_2, Set_3, Clear_1, Clear_2, Clear_3, View,
*=go back, ~=go to root
TN-1X /Config/cOmms_management/Area_address/
>>
• Reports, resulting from a user request:

28, OSI Address Configuration
282, Manual_area_address_1 = 490000
283, Manual_area_address_2 = 7C8001
;
• Responses to invalid actions. These are listed in Appendix C: TN-1X

Messages.
• Logout messages. There are two types:
— User invoked logout:
8, Bye;
— Automatic logout message:

8, Bye, Autologout;
• Automatic (idle-timeout) logout warning. This is accompanied by an

audible warning.
9, Attention! You will be logged out in 2 minutes!;

User interface 2-11
Autonomous messages
Autonomous messages are initiated in the NE and sent to all logged in users.
Users may enable or disable display of these messages on a per session basis
(see Chapter 8, “Session menu”). These messages are displayed by default.
There are two types of autonomous message:

• Alarm events. These notify the user of an alarm being raised or cleared.
The format is as follows:
911, <alarm>, <instance>, <alarm_status>,
<alarm_severity>, <alarm_category>,
<unique_number>, <traffic_type>, <user_label>,
<date>, <time>
Where:
— <alarm> is the alarm event.
— <instance> is the affected unit or traffic. These are identified by a slot,
port, or payload reference, and use the same syntax as the equivalent
command parameters (see “Parameters” on page 2-4).
Note 1: TAMs are identified by slot numbers. The TAMs for slot 2 are
identified by S16 and S17, the TAMs for slot 4 are S19 and S20, the TAMs
for slot 9 are S24 and S25, and the TAMs for slot 11 are S27 and S28.
Note 2: The three Multiplexer Section Protection (MSP) alarms are always
reported against the protection channel. MS and RS alarms that relate to
MSP channels are always reported against the affected channel. All other
alarms that relate to MSP channels are reported against the working
channel.
— <alarm_status> is Present or Cleared.
— <alarm_severity> is (C)ritical, (M)ajor, (m)inor, or Disconnect (X).
— <alarm_category> is (P)rompt, (D)eferred, (I)nstation, or (W)arning.
— <unique_number> is between 1 and 65535.
— <traffic_type> identifies the nature of the affected unit or traffic (see
Table 2-6 below).
Note: There are no card types for TAMs. Where TAM alarms are reported,
the card type for the unit they are associated with is used.
— <user_label> is the fifteen character user label.

— <date> is the date on which the alarm was generated.
— <time> is the timestamp for the alarm.

2-12 User interface
Table 2-6
Traffic types for the TN-1X
Traffic type Description
2M75 2 Mbit/s 75Ω (Tributary).
2M120 2 Mbit/s 120Ω (Tributary).

A-1o STM-1 optical (Aggregate A).
B-1o STM-1 optical (Aggregate B).

STM1o STM-1 optical (Tributary).
A-1e STM-1 electrical (Aggregate A).

B-1e STM-1 electrical (Aggregate B).
STM1e STM-1 electrical (Tributary).

A-4o STM-4 optical (Aggregate A).
B-4o STM-4 optical (Aggregate B).

34_45M 34/45 Mbit/s (VC-3) electrical tributary.
34M_TM 34 Mbit/s (16x2M) transmux electrical tributary.

EOW Engineering Order Wire/Interface Control Card (ICC).
Payld Payload Manager.

PSU Power Supply Unit.
Note: There are no card types for TAMs. Where TAM alarms are reported, the card type for
the unit they are associated with is used.
For example:
911, TU-AIS, S6-J1-K123, clear, M, I, 123, A-1o,
customer_1, 17/01/96, 19:05:02
In the above example, the TU-AIS alarm is now clear.
Note: A summary of all active alarms can be displayed using the

‘View_status/Active_Alarms’ command (see Chapter 7, “View status
menu”).
• Non-alarm events:
9**, <message>, <timestamp>
;
For example:
951, Cmd = c/r/t s1-2, User = oper2, 27/03/96, 23:52:29
;
Autonomous messages are displayed with a number (911 for an alarm and
9**, a three figure number starting with 9, for an event) and the date and time
that the message was entered in the appropriate log.
end of chapter

3-1
Getting started 3-
!
Accessing the UI application software
All users are required to login to the TN-1X using a user name and password.
There are three classes of user with different sets of access privileges. These
are shown in Table 3-1 below.
Table 3-1
Users and passwords
User class User names Password Access privileges
Status Manager viewr lookat Read only. Can perform all ‘view’ commands,
Configuration oper1, oper2 config All network traffic control, upgrades, restarts and
Manager connections,
System nortl teledbc All commands. Severely Errored Seconds (SES) thresholds,
Engineer password setting and comms management configuration,
Note: If the System Engineer’s password is forgotten, the Nortel Service Centre should be contacted.
Note: The above passwords are defaults. It is advised that these are
changed after installation, where this activity is supported.
The Configuration Manager and System Engineer classes have compulsory

automatic logout. This is initially set to the default setting of fifteen minutes,
but this can be changed using the session menu (see “Session characteristics”
on page 8-2). The Status Manager class is not affected by automatic logout.
Logging in
The TN-1X supports three user sessions from the Preside EC-1 Element
Controller, and one from the CAT. Only one system engineer login is
permitted. This can be from either Preside EC-1 Element Controller or CAT,
but not from both simultaneously. The configuration manager and status
manager classes can have more than one login.
CAUTION
Multiple configuration manager logins
If more than one user is logged in as a configuration manager,
care should be taken by each configuration manager to ensure
that any actions performed do not adversely affect the work of
other configuration managers.

3-2 Getting started
When login starts, the user is prompted for a user name and a password. An
identification entry is also requested to enable different users with the same
user name to be distinguished.
The user can attempt to login for three minutes. If a successful login is not
achieved in this period, the user is automatically disconnected. This event will
also occur if four consecutive unsuccessful login attempts are made in the
login period.
Procedure 3-1
Logging in to the TN-1X from the CAT
Step Action
1 Ensure that the CAT PC is switched off.

2 Plug the RS232 cable into the RS232 socket on the CAT PC.
3 Plug the other end of the RS232 cable into the CAT PC port on the TN-1X
network element.
4 Switch on the CAT PC and start Microsoft Windows.
5 Run the Microsoft Windows ‘Terminal’ application.
6 Open the file containing the TN-1X connection data, and press return. For
details on setting up this file, see Appendix A: Craft Access Terminal.
7 Type your user name after the ‘Login:’ prompt, and press Return.
8 Type your password after the ‘Password:’ prompt, and press Return.
9 Type an identification string (up to 11 characters) after the ‘Identification:’
prompt, and press Return.
10 You are now presented with the main menu.
—end—
Procedure 3-2
Logging in to the TN-1X from the Preside EC-1 Element Controller
Step Action
1 Select the ‘Network Element Access’ button from ‘Management Functions’ on

the main menu. The ‘Network Element Access’ window is displayed showing
a list of NEs under the span of control.
2 Select the required NE with the left mouse button.
3 Click the right hand mouse button, to display a popup menu. From this popup
menu, select the ‘Open NE Command Line’ option.
4 Then, the Preside EC-1 Element Controller automatically logs in to the NE
using your duty class, password and user ID.
5 You are now presented with the NE status, the main menu and the command
prompt.
—end—

Getting started 3-3
Once logged in, the user is informed of the NE status, and the main user menu
is displayed. The NE status contains the following information:
• Date and time.
• Inventory data.
• List of users currently logged in.
• TN-1X software and configuration table status.
• Loopback test status.
• List of active alarms. !
Figure 3-1
Example login, NE status information and main user menu
login:oper1
password:
identification:fred
59,NE Time
591,NE_date=09/05/1997,NE_time=09:57:39
53,Inventory
531,S0, Address=000075403a43
532,S0, NTPEC=00750GWV, Card_type=BP_R2.5
532,S1, NTPEC=NTKD13AA, Card_type=ICC-V2_NUI_13AA
532,S2, NTPEC=NTKD16AA, Card_type=34_45M-vc3_data_16AA
532,S5, NTPEC=NTKD10AA, Card_type=Payload_man-mp_10AA
532,S6, NTPEC=00750HWF, Card_type=STM_1_Agg-opt_HWF
532,S7, NTPEC=00750GSA, Card_type=STM_4_Agg-opt_GSA
532,S9, NTPEC=00750HVT, Card_type=2M_Trib-75ohm_HVT
532,S12, NTPEC= , Card_type=PSU
532,S14, NTPEC=00750GXD, Card_type=SRC
532,S17, NTPEC = NTKD17AA01, Card_type = 34/45M_TAM, Serial_no = ,
532,S20, NTPEC = NTKD17AB01, Card_type = 34/45M_TAM_PROT, Serial_no = ,
532,S24, NTPEC = NTKD14AA170, Card_type = V2_TAM-75ohm, Serial_no = ,
532,S25, NTPEC = , Card_type = Undefined, Serial_no = ,
52,Open Sessions
521,User=nortl,Ident=mark
57,Software and Config table status

571,Active_SW=X7.1A,Active_bank=A,Standby_SW=N/A
572,Active_CFG=7.0C, Standby_CFG=7.0C
573,SW_upgrade_status = Stable
574,Cnfg_upgrade_status = Stable
31,Loopback Configuration
51,Alarm Status
511,NE-Wrong_Card,S1,Present,C,P,0015,ICC2,
511,NE-Card_Out,S3,Present,C,P,0374,2M75,
511,NE-Wrong_Card,S11,Present,C,P,1468,STM1o,
511,SYNC-Src_Not_Primary,S14,Present,C,P,0009,SRC,
;
Config/, View_status/, Session/, Admin/, Maint/, /Diagnostic/, Logout
TN-1X/
>>

3-4 Getting started
Logging out
Logout can occur either manually or automatically:
• Manual logout. This is achieved using the Logout command, which is
available from the top-level (root) menu. No confirmation is required. The
command is shown below.
TN-1X/
>>l ↵
8 Bye;
• Automatic logout. This occurs after no activity has occurred for a

predetermined period. Automatic logout period can be adjusted using the
commands in the ‘Session’ menu (see Chapter 8, “Session menu”).
Note: The Status Manager class is not affected by automatic logout.
end of chapter

Configuration menu 4-
The configuration menu allows the user to access, view and edit Network
Element (NE) settings. The top-level structure of the configuration menu is
shown in Figure 4-1. Items that have a submenu are shown in bold (all items
in this menu). Shortcuts for individual menu items are shown in upper case
(see “Command shortcuts” on page 2-2).
Figure 4-1
Configuration command hierarchy
Config
Pps
"
cOmms_management
External_alarm
Alarms
Thresholds
Monitoring
Rau_priority
misC
perF_mon
Sync_source
Cons_act
Lp_path_Trace
Hp_path_trace
Lp_paYload_label
Hp_paYload_label
coNnections
carDs
Payman_Protect
Trib_Prot
poRts
MSp
tn1x_Card_Switch
PunchThrough
oVeride
Each of the configuration menus shown above is described later in this

chapter.

4-2 Configuration menu
Config/Pps <C P>

This command enables the user to configure the global path protection
switching options of the TN-1X.
Path protection switching

Path protection switching enables a VC-12 or VC-3 signal to be switched
between aggregates. This can be performed automatically, in response to
specific alarm conditions, or performed manually. The same channels are
used on the alternate aggregate when the switch is made.
Path protection switching can be applied to any of the TN-1X’s tributary

channels. The system defaults to automatic switching enabled, with aggregate
‘A’ active for all protected connections. For full details of connection
management, see “Connection management” on page 4-82.
Provided that the connection is protected and switching is enabled, the

following alarms triggers the switch automatically:
Table 4-1
Alarm triggers for path protection switching
Source of switch Alarms Direct/Indirect
Payload Manager INT-AU-AIS, INT-AU-LOP Direct

TU-AIS, TU-LOP
HP-LOM
2 Mbit/s tributary unit LP-EXC Direct
34 Mbit/s (16x2) tributary unit LP-EXC Direct
34/45 Mbit/s (VC3) tributary unit LP-EXC Direct
STM-1 aggregate unit RS-LOS, RS-LOP Indirect

MS-EXC, MS-AIS
AU-AIS
Consequent actions LP-PLM Indirect

HP-PLM
The status of protection switching for any tributary payload can be

established through the use of reporting commands.
Manual path protection switching is supported from the Maintenance menu

(see “Manually switching a protected path” on page 6-2).
Note 1: Manual path protection switching is not possible when the mux is
in detached mode (see “Detached mode” on page 9-22).
Note 2: Older STM-1 tributary units (25U JU00 750 GVA/GVB/JBK and
25U TM00 750 HWE/HWG) do not propagate TU-AIS. As a result, path
protection switching on channels flowing between STM-1 trib connected
rings will not work. Newer units support TU-AIS propagation.

Command details
The commands that access the path protection switching functionality of the
TN-1X are shown in Figure 4-2 below, and are detailed in the tables that
follow.
Figure 4-2
Config/Pps command hierarchy
Config
Pps
Enable_holdoff
Disable_holdoff
Holdoff_time
Pps_mode_on
pps_mode_Off
"
A
B
Current
View
Status_view
Table 4-2
Config/Pps
Menu item Shortcut Parameters Confirm Description
Enable_Holdoff CPE PDH_port TBD Enables holdoff on a per port

basis.
Disable_Holdoff CPD PDH_port TBD Disables holdoff on a per port

basis. (default)
Holdoff_time CPH tenths_of_seconds TBD TU-12/TU-3/AU-4 path failed

persistence time.
range: 0-200 tenths-sec
steps:1 tenths of a second
default: 0 tenths of a second
Pps_mode_on CPP PDH_port | Yes Enables automatic path

(default) SDH_trib_payload | protection switching for the
SDH_aggr_payload specified protected tributary
port/payload.
pps_mode_Off CPO See Table 4-3
View CPV PDH_port | No Displays PPS mode status

SDH_trib_payload report for the specified port(s)/
SDH_aggr_payload payload(s). Path protection
(see Note) switching does not need to be
active.
STatus_view CPST No Displays a VC path status

report.
Note: If this parameter is not provided, all possible information is displayed.

Table 4-3
Config/Pps/pps_mode_Off
Menu Shortcut Parameters Confirm Description

item
A CPOA PDH_port | Yes Disables path protection

SDH_trib_payload switching, and connects the
SDH_aggr_payload specified port/ payload to
aggregate ‘A’.
B CPOB Disables path protection

switching, and connects the
specified port/ payload to
aggregate ‘B’.
Current CPOC Disables path protection

switching, and retains the
current connection for the
specified tributary port/
payload.
Note: These menu options do not remove the protected connection. The automatic
protection switching mechanism is disabled, but the protected connection is retained.
Parameters
The following parameters are used by the commands described above:
• The <PDH_port> parameter identifies a PDH tributary port which is part
of an established protected connection. This takes the following syntax:
S<slot>-<port>
PDH ports are detailed in “PDH ports” on page 2-4.
• The <SDH_trib_payload> parameter identifies an SDH tributary payload

which is part of an established protected connection. This takes the
following syntax:
SDH tributary payloads are detailed in “SDH tributary

payloads” on page 2-5.
• The <SDH_aggr_payload> field identifies an SDH aggregate payload

following syntax:
SDH aggregate payloads are detailed in “SDH aggregate payloads” on

page 2-6.
• The <tenths_of_seconds> parameter has a range 0 to 200 milliseconds

Autonomous events
The autonomous events associated with the above functionality are:
• If any path sources are changed manually or automatically, one of the
following two events occurs.
981, <PDH_port>, New_path_src = <SDH_aggr_payload>,
Reason = <‘Forced’|‘Auto’>
981, <SDH_trib_payload>, New_path_src =
<SDH_aggr_payload>, Reason = <‘Forced’|‘Auto’>
Examples:
981, S2-1, New_path_src = S6-J1-K111, Reason = Forced
981, S4-1-J1-K123, New_path_src = S6-J1-K111,
Reason = Forced
Reports "
The reports generated by this command are detailed below.
Config/Pps/View
The report for the view command uses the following entries:
12, PPS Configuration
121, PPS_Oscillation_guard_time(seconds) = 30
122, PPS_Holdoff_time(tenths_of_seconds) =
<hold_off_time_value>
123, <PDH_port>, PPS_mode = <‘On’|‘Off_A’|‘Off_B’>
123, <SDH_trib_payload>, PPS_mode = <‘On’|‘Off_A’|‘Off_B’>
123, <epay_inst>, PPS_holdoff = <‘enabled’|‘disabled’>,
PPS_mode = <‘On’|‘Off_A’|‘Off_B’>
For example:
12, PPS Configuration
121, PPS_Oscillation_guard_time(seconds) = 30
122, PPS_Holdoff_time(tenths_of_seconds) = 200
123, S1-1, PPS_holdoff = Enabled, PPS_mode = On
123, S1-3, PPS_holdoff = Disabled, PPS_mode = On
123, S1-4, PPS_holdoff = Enabled, PPS_mode = Off_A
123, S1-6, PPS_holdoff = Enabled, PPS_mode = Off_A
123, S1-7, PPS_holdoff = Disabled, PPS_mode = On
123, S1-8, PPS_holdoff = Enabled, PPS_mode = Off_B
;
Config/Pps/STatus_view
This report duplicates a status report on the status view menu, and is
described in “View_status/VC_path_status” on page 7-12.

Config/cOmms_management <C O>

This command enables the user to configure the communications settings for
the TN-1X.
Communications management
The communications functionality of the TN-1X covers a number of areas.
• Link Access Procedure on the D channel:
The LAPD (Link Access Protocol for the D Channel) options
control the use of the D-bytes from the section overhead, both
for the current session and for the session after the next
restart.
Settings for the section overhead are defined for both

aggregates, and apply to any units that provide an STM
interface. The D-bytes are located as follows:
— D1-D3: Located in the regenerator section (RS) region of the section

overhead. These are generated/terminated at each multiplexer, and at
each regenerator.
— D4-D12: Located in the multiplex section (MS) region of the section
overhead. These are generated/terminated at each multiplexer, but pass
transparently through regenerators.
The TN-1X cannot use both the MS and RS D-bytes at the same
time. Either can be selected for use, and an automatic
selection mode can also be selected. This mode attempts to use
RS, but uses MS if this is not possible.
Note 1: If the D bytes within the RS and MS section overheads are not in
use (that is, they are both switched off), monitoring of the QECC alarm for
the affected STM-1 port is disabled.
Note 2: If LAPD is on for any MSP non-active section port, the monitoring
of this port is dependant on its MSP LAPD settings (see “Multiplexer
section protection” on page 4-118).
• LAN connection:
The user can set the TN-1X LAN connection to one of the
following modes:
— Active. In this mode, the LAN connection is fully functional. If the

LAN cannot be detected, an NE-Lan_Alarm is raised.
— Standby. In this mode, the LAN connection is active, but no LAN
traffic is expected. If traffic is encountered, an NE-Unexpected_Lan
alarm is raised.
— Off. In this mode, the LAN connection is disabled. All LAN activity is
ignored.

• Area addresses:
The user is able to set the initial domain segment of the each
of the three area addresses used by the TN-1X. At least one
area address must be defined at all times.
Command details
The commands that access the communications management functionality of
the TN-1X are shown in Figure 4-3, and are detailed in the tables that follow.
Figure 4-3
Config/cOmms command hierarchy
Config
cOmms_management
lapd_link_Service
"
oN_Rs
Off_Rs
oN_Ms
Off_Ms
oN_Auto
Off_Auto
View
laN_service
oN
Off
Standby
View
Area_address
Set_1
Set_2
Set_3
Clear_1
Clear_2
Clear_3
View
STatus_view
Table 4-4
Config/cOmms_management
lapd_link_Service COS See Table 4-5.
laN_service CON See Table 4-6.
Area_address COA See Table 4-7.
STatus_view C O ST N/A No Displays a report

showing LAPD statuses.

Table 4-5
Config/cOmms_management/lapd_link_Service
oN_Rs C O S NR SDH_port Yes Enables the RS LAPD

(default) functionality. (see Note 1 and 2)
Off_Rs C O S OR Disables the RS LAPD

functionality.
oN_Ms C O S NM Enables the MS LAPD

functionality. (see Note 1 and 2)
Off_Ms C O S OM Disables the MS LAPD

functionality.
oN_Auto C O S NA Enables the automatic selection

of LAPD functionality. This will
default to using the RS signal, but
will switch to MS if required. (see
Notes 1 and 2)
Off_Auto C O S OA Disables the Automatic selection

of LAPD functionality.
View COSV N/A No Displays a report showing the

current lapd_link_service status,
and the status to be applied after
the next restart.
Note 1: Only one of the RS, MS or Automatic settings can be set to ‘on’ at any time.
Note 2: If LAPD settings are enabled for an MSP port, the LAPD monitoring of this port
depends on the MSP LAPD settings.
Note 3: All of the above options (except View) are only available to the system engineer
user class.
Table 4-6
Config/cOmms_management/laN_service
Off CONO N/A No Disables the LAN connection.
oN CONN Yes Enables the LAN connection.
Standby CONS No Sets the LAN connection on

(default) standby.
View CONV N/A No Displays a report showing the

current LAN configuration (on/
off).
Note: All of the above options (except View) are only available to the system engineer user
class.

Table 4-7
Config/cOmms_management/Area_address
Set_1 C O A S1 address Yes Sets the specified OSI

(see note 1) programmable area address.
Set_2 C O A S2
Set_3 COAS
Clear_1 C O A C1 N/A Clears the specified OSI

programmable area address.
Clear_2 C O A C2
Clear_3 C O A C3
View COAV N/A No Displays a report of the OSI fixed

and programmable area
"
addresses.
Note 1: The default for the first area address is 490000.
Note 2: All of these commands (except View) are only available to the system engineer
user class.
Parameters
• The <SDH_port> parameter identifies the physical port on an STM-N
aggregate or STM-1 tributary. The format for this is:
S<slot>-<port>
SDH ports are detailed in “SDH ports” on page 2-8.
• The <address> parameter identifies an area address. This is a hexadecimal

string of up to 26 characters. For example:
490000
Autonomous events
There are no autonomous events associated with the above commands.

Reports
The reports generated by the comms management commands are detailed
below.
Config/cOmms_management/lapd_link_Service/View
The reports for this view command uses the following entries:
27, Lapd Link Configuration
272, <SDH_port>,Lapd_link_mode_RS=<‘Auto’|‘Network’|‘User’>
272, <SDH_port>,Lapd_link_mode_MS=<‘Auto’|‘Network’|‘User’>
273, <SDH_port>,Lapd_link_service_RS = <‘On’|‘Off’|‘Auto’>
273, <SDH_port>,Lapd_link_service_MS = <‘On’|‘Off’|‘Auto’>
273, <SDH_port>,No_card_carrying_DCC_traffic_in_this_slot
For example, if the mux has one STM-1 tributary unit and one aggregate in use:
27, Lapd Link Configuration
272, S4-1,Lapd_link_mode_RS=Auto
273, S4-1,Lapd_link_service_RS=Off
272, S6-1,Lapd_link_mode_RS=Auto
273, S6-1,Lapd_link_service_RS=Off
;
Config/cOmms_management/laN_service/View
The report for this view command uses the following entries:
29, LAN Configuration
291, LAN_service = <‘On’|‘Off’|’Standby’>
292, LAN_connection = <‘Present’|‘Not_Present’>
For example:
29, LAN Configuration
291, LAN_service = On
292, LAN_connection = Present
;
Config/cOmms_management/Area_address/View
The report for this view command uses the following entries:
28, OSI Manual Area Address Configuration
282, Manual_area_address_1 = <address>
For example:
28, OSI Address Configuration
282, Manual_area_address_1 = 490000
;
Config/cOmms_management/STatus_view
This report duplicates a status report on the Status View menu, and is
described in “View_status/Lapd_Link_status” on page 7-13.

Config/External_alarm <C E>

This command enables the user to configure the external alarms of the
TN-1X.
External alarms
External alarms allow the TN-1X to interact with its environment. Five input
alarms are supported, each of which may be triggered by an external event
such as a fire alarm, or a security door being left open. Trigger events can be
triggered by one of two conditions. External alarms can be associated with
short names to simplify identification.
Note: Changes to external alarm names are not reflected in alarms that
have already been raised. Subsequent instances of the affected alarm will
use the new alarm name.
"
Command details
The commands that access the external alarms functionality of the TN-1X are
shown in Figure 4-4 below, and are detailed in the tables that follow.
Figure 4-4
Config/External_alarm command hierarchy
Config
External_alarm
Input
Set_name
mode_Off
mode_Closed
mode_oPen
Filter_oN
Filter_Off
RAU_priority
Prompt_critical
Defered_major
In_station_minor
X_disconnect_warning
View

Table 4-8
Config/External_alarm/Input
Set_name CEIS alarm_ID No Sets the specified alarm to a

alarm_name string of up to fifteen
characters.
mode_Off CEIO alarm_ID Disables monitoring of this

alarm.
mode_Clos CEIC Enables monitoring of this

ed(default) alarm with the alarm being
triggered by a signal greater
than 1 MΩ.
mode_oPen CEIP Enables monitoring of this

alarm with the alarm being
triggered by a signal less than
200 Ω.
Filter_oN C E I FN Enables alarm filtering. When

active, transient alarms are
ignored.
Filter_Off C E I FO Disables alarm filtering.

(default)
View CEIV N/A No Displays the input alarm names.
Table 4-9
Config/External_alarm/Input/RAU_priority
Prompt_critical CEIRP alarm_ID No Set RAU alarm priorities
Deferred_major CEIRD
In_station_minor CEIRI
X_disconnect_ CEIRX
warning
Parameters
• The <alarm_ID> parameter identifies one of the five external input alarms.
These are called ‘E1’, ‘E2’, ‘E3’, ‘E4’ and ‘E5’.
• The <alarm_name> parameter is a string of up to fifteen characters. Alarm
names default to ‘Ext_inp1’, ‘Ext_inp2’, ‘Ext_inp3’, ‘Ext_inp4’,
‘Ext_inp5’.
Autonomous events
Reports
The reports generated by the commands described are listed below.

Config/External_alarm/Input/View
16, External Alarm Configuration
161, <alarm_ID>, Ext_input_name = <alarm_name>,
Ext_mode = <‘Off’|‘Mode_open’|‘Mode_closed’>,
Ext_filter = <‘On’|‘Off’>
Ext_rau = <‘Prompt_critical’|‘Deferred_major’|
‘In_station_minor’|‘X_disconnect_warning’ >
For example:
16, External Input Alarm Configuration
161, E1, Ext_input_name = Ext_inp1, Ext_mode = Mode_closed,
Ext_Filter = On, Ext_rau = Prompt_critical
"
;

Config/Alarms/Thresholds <C A T>

This command enables the user to set and view alarm thresholds of the TN-1X.
Alarm thresholds
Alarms associated with traffic error rates have error rate thresholds above
which alarms are raised. These Bit Error Rate (BER) threshold values can be
set by the user. Affected alarms are:
• Multiplexer Section Signal Degrade (MS-DEG).
• Multiplexer Section Excessive BER (MS-EXC).
• High-order Path Signal Degrade (HP-DEG).
• High-order Path Remote End Indicator (HP-REI).
• Low-order Excessive BER (LP-EXC).
Bit error rates are expressed using varying orders of magnitude. For example,
a threshold of ‘1E-4’ represents one error in 104=10000 bits. Available
thresholds vary between ‘1E-3’ (1 error in 1000) to ‘1E-7’ (1 error in
10,000,000), though not all of these are available for all alarm types.
Command details
The commands that access the alarm threshold functionality of the TN-1X are
Figure 4-5
Config/Alarms/Thresholds command hierarchy
Config
Alarms
Thresholds
MS_deg
1e-5
1e-6
1e-7
HP_deg
1e-5
1e-6
1e-7
Hp_rEi
1e-5
1e-6
1e-7
Lp_eXc
1e-3
1e-4
Ms_eXc
1e-3
1e-4
View

Note: None of the commands within this branch of the user interface
require parameters, as the settings are indicated through the use of
sub-commands.
Table 4-10
Config/Alarms/Thresholds

item
MS_deg C A T MS See Table 4-11. These commands have identical

subcommands. These are
HP_deg C A T HP described in the specified table.
Hp_rEi C A T HE
"
Lp_eXc C A T LX See Table 4-12. These commands have identical
subcommands. These are
Ms_eXc C A T MX described in the specified table.
View CATV N/A No Displays the alarm threshold

settings.
Table 4-11
Config/Alarms/Thresholds/<MS_deg | HP_deg | Hp_rEi>
1e-5 <Shortcut> N/A No Sets threshold to 1 error in

(default) 5 100,000.
1e-6 <Shortcut> Sets threshold to 1 error in

6 1,000,000.

7 10,000,000.
Note: This table details the threshold options for the MS_deg, HP_deg and Hp_rEi commands.
The <Shortcut> element of the shortcut refers to the shortcut for the relevant command.
Table 4-12
Config/Alarms/Thresholds/<Lp_eXc | Ms_eXc>

item
1e-3 <Shortcut> N/A No Sets threshold to 1 error in 1000.

(default) 3

4 10,000.
Note: This table details the threshold options for the Lp_eXc and Ms_eXc commands. The
<Shortcut> element of the shortcut refers to the shortcut for the relevant command.
Parameters
There are no parameters associated with the above commands.
Autonomous events

Reports
The reports generated by the commands described above are detailed below.
Config/Alarms/Thresholds/View
17, Alarms Thresholds
171, <alarm_name>_threshold = <threshold>
Where:
• <alarm_name> is the capitalised form of the alarm name. This report
shows all alarm thresholds for the multiplexer, not just those that can be
changed by the user.
• <threshold> is the threshold defined for the specified alarm.
For example:
17, Alarm Thresholds
171, MS_EXC_threshold = 1E-3
171, MS_DEG_threshold = 1E-6
171, HP_EXC_threshold = 1E-3
171, HP_DEG_threshold = 1E-7
171, HP_REI_threshold = 1E-5
171, LP_EXC_threshold = 1E-3
171, LP_DEG_threshold = 1E-4
171, LP_REI_threshold = 1E-5
171, PPI_EXC_threshold = 1E-3
171, PPI_DEG_threshold = 1E-5
;
Note: Several of the above thresholds cannot be configured using the

commands available on the TN-1X.

Config/Alarms/Monitoring <C A M>

This command accesses the alarm monitoring features of the TN-1X.
Alarm monitoring
Alarm monitoring is a process which takes as input the raw state of an alarm,
and outputs the monitored state of the alarm. Possible states for each alarm are:
• Monitoring is enabled. In this instance, the monitored state of the alarm is
defined to be the same as its raw state.
• Monitoring is disabled. In this instance, the monitored state is defined as
clear, whatever its raw state. That is, the effect of disabling the monitoring
of an alarm is to clear the alarm down permanently.
Alarm monitoring can be enabled/disabled for each port on a per-alarm basis.
Note 1: If monitoring of the MS-RDI, LP-RDI or HP-RDI alarms is

"
disabled, the equivalent REI alarm is also disabled.
Note 2: Alarm monitoring can also be enabled and disabled via the
performance monitoring functionality page 4-33. Monitoring of external
alarms is enabled and disabled as described on page 4-11.
Note 3: The disabling of alarm monitoring for an instance of an alarm also
disables all consequent actions on that instance. That is, disabling of
monitoring on an instance basis disables consequent actions on an NE
basis. This is done to ensure that a report is generated if AIS is inserted (see
“Consequent actions” on page 4-60).
Command details
The commands that access the alarm monitoring facilities of the TN-1X are
Figure 4-6
Config/Alarms/Monitoring command hierarchy
Config
Alarms
Monitoring
Ms
ms_Rdi
ms_Deg
Hp
hp_Deg
hp_Rdi
hp_Lom
Lp
lp_Deg
lp_Rdi
int_lp_Op_Buffer
Ppi
ppi_Ais
ppi_Tf
View

Table 4-13
Config/Alarms/Monitoring/<PMP>
Menu item Shortcut Parameters Description
Ms/ms_Rdi CAMMR The monitoring for all of these alarms can be

(see Note) enabled (‘On’) or disabled (‘Off’). See Table 4-14.
The default setting is ‘Off’.
Ms/ms_Deg CAMMD
Hp/hp_Deg CAMHD The monitoring for all of these alarms can be

enabled (‘On’) or disabled (‘Off’). See Table 4-15.
Hp/hp_Rdi CAMHR The default setting is ‘On’.
(see Note)
Hp/hp_Lom CAMHL
Lp/lp_Deg CAMLD The monitoring for all of these alarms can be

enabled (‘On’) or disabled (‘Off’). See Table 4-16.
Lp/lp_Rdi CAMLR Default settings for these alarms are:
(see Note) - lp_Deg defaults to ‘On’.
- lp_Rdi defaults to ‘Off’.
Lp/int_lp_Op_Buffer C A M L OB
- int_lp_Op_Buffer defaults to ‘On’.
Ppi/Ppi_Ais CAMPA - Ppi_Ais defaults to ‘On’.
- ppi_Tis defaults to ‘On’
Ppi/ppi_Tf CAMPT
View CAMV SDH_port | Displays a report detailing the

PDH_port | monitoring state for all of the
‘all’ above alarms.
Note: If monitoring of this RDI alarm is disabled, the equivalent REI alarm is also disabled.
Table 4-14
Config/Alarms/Monitoring/MS/<MS_alarm>
oN (default) <Shortcut> N SDH_port No Enables alarm monitoring.
Off <Shortcut> O Disables alarm

monitoring.
Note: This table details the enable/disable options that are available for the MS alarms
listed in Table 4-13. The <Shortcut> element of the shortcut refers to the shortcut for the
relevant alarm.
Table 4-15
Config/Alarms/Monitoring/HP/<HP_alarm>
oN (default) <Shortcut> N SDH_AU4 No Enables alarm monitoring.
Off <Shortcut> O Disables alarm monitoring.
Note: This table details the enable/disable options that are available for the HP alarms
listed in Table 4-13. The <Shortcut> element of the shortcut refers to the shortcut for the
relevant alarm.

Table 4-16
Config/Alarms/Monitoring/<LP | PPI>/<PDH_alarm>
oN (default) <Shortcut> PDH_port No Enables alarm monitoring.

N
Off <Shortcut> Disables alarm monitoring.

O
Note: This table details the enable/disable options that are available for the LP and PPI
alarms listed in Table 4-13. The <Shortcut> element of the shortcut refers to the shortcut
for the relevant alarm.
Parameters
The following parameters are used by the commands described above: "
S<slot>-<port>
• The <SDH_AU4> parameter identifies an AU4 high-order payload on an

STM-N aggregate or STM-1 tributary. The format for this is:
SDH high-order payloads are detailed in “SDH high order

• The <PDH_port> parameter identifies a PDH tributary port. This takes the
following syntax:
S<slot>-<port>
Autonomous events
Reports
The reports generated by the alarm monitoring commands are detailed below.
Config/Alarms/Monitoring/View
172, Alarm Monitoring
173, <SDH_port>, <alarm_name>_monitor = <‘On’|‘Off’>
173, <SDH_AU4>, <alarm_name>_monitor = <‘On’|‘Off’>
173, <PDH_port>, <alarm_name>_monitor = <‘On’|‘Off’>
Where:
• <alarm_name> is the capitalised form of the alarm name.

For example:
172, Alarm Monitoring
173, S6-1, MS_RDI_monitor = On
173, S6-1, MS_DEG_monitor = On
173, S6-1-J1, HP_DEG_monitor = On
173, S6-1-J1, HP_RDI_monitor = On
173, S6-1-J1, HP_DEG_monitor = On
173, S2-1, LP_DEG_monitor = On
173, S2-1, LP_RDI_monitor = On
173, S2-1, INT_LP_OP_BUFFER_monitor = On
173, S2-1, PPI_AIS_monitor = On
173, S2,I1, PPI_TF_monitor = On
;

Config/Alarms/Rau_priority <C A R>

This command enables the user to set the priority for alarms on the TN-1X.
RAU priority
Each alarm on the TN-1X is assigned a Rack Alarm Unit (RAU) priority,
which establishes the response of the local alarm indicators to the occurrence
of each alarm. This priority can be set by the user. The four alarm priorities are:
• Prompt_critical - an alarm that requires immediate attention at all times. It
is normally extended to a maintenance/control point when the station is
unattended.
• Deferred_major - an alarm that does not require immediate attention
outside normal hours. It is normally extended to a maintenance/control
•
point when the station is unattended.
Instation_minor - an alarm that does not require attention outside normal
"
hours. It is not normally extended.
• Disconnect_warning - an alarm that is indicated by the UI or EC, but no
unit, subrack, or rack alarm indications or extensions are provided.
Note: The above alarm priorities are a combination of alarm categories
(prompt, deferred, instation, and disconnect) with alarm severities (critical,
major, minor, warning). The TN-1X can only associate these in the
combinations indicated.
The alarms that are subject to RAU priorities fall into a number of groupings.
These are:
• Optical Section (OS) alarms.
• Electrical Section (ES) alarms.
• Regenerator Section (RS) alarms.
• Multiplex Section (MS) alarms.
• Administrative Unit (AU) alarms.
• Low-order Path VC-12 and VC-3 (LP) alarms.
• High-order Path (HP) alarms.
• Tributary Unit (TU) alarms.
• PDH Physical Interface (PPI) alarms.
• Synchronisation (SYNC) alarms.
• Network Element card (CARD) alarms.
• 34 Mbit/s PDH Transmux (TM) alarms.
• Multiplexer Section Protection (PROT) alarms.
• Miscellaneous (MISC) alarms.
Note: TN-1X Release 9 uses different alarm names to the releases of

TN-1X up to and including Release 6. The R9 alarm names are listed
alongside the R6 equivalents in Appendix B: TN-1X alarms.

Command details
The commands that access the RAU priority functionality of the TN-1X are
shown in Figure 4-7, and are detailed in the tables that follow.
Figure 4-7
Config/Alarms/Rau_priority command hierarchy
Config
Alarms
Rau_priority
Os
Es
Rs
Ms
Au
Hp
Tu
Lp
Ppi
TM
Sync
misC
prOT
Card
Note: None of the commands within this branch of the user interface
require parameters, as the settings are indicated through the use of
sub-commands.
Table 4-17
Config/Alarms/Rau_priority/Os
Menu item Shortcut Default Description
os_optical_Power_Ool C A R O PO In_station_minor The RAU priority for each

of these alarms can be set
os_Laser_Shutdown C A R O LS In_station_minor to ‘Prompt_critical’,
‘Deferred_major’,
os_Laser_Temp_hi_low C A R O LT Deferred_major
‘In_station_minor’, or
os_optical_Power_Low C A R O PL Deferred_major ‘Disconnect_warning’.
This is achieved using the
int_os_laser_TesT C A R O TT In_station_minor commands detailed in
Table 4-31.
View CAROV N/A Displays RAU priorities.
Note: The RAU priority for the OS-Optical_Power_High alarm is fixed as

‘Prompt_critical’. This alarm does not appear in the command structure,
and cannot be configured by the user.

Table 4-18
Config/Alarms/Rau_priority/Es
es_cmi_violatioN CAREN Prompt_critical The RAU priority for each of

these alarms can be set to
‘Prompt_critical’,
es_cmi_Output_Fail C A R E OF Prompt_critical ‘In_station_minor’, or
‘Disconnect_warning’. This
is achieved using the
commands detailed in
Table 4-31.
View CAREV N/A Displays RAU priorities.
Table 4-19
"
Config/Alarms/Rau_priority/Rs
rs_loS CARRS Prompt_critical The RAU priority for each of these

alarms can be set to
rs_loF CARRF Prompt_critical ‘Prompt_critical’, ‘Deferred_major’,
rs_realign_Phase CARRP Prompt_critical
‘Disconnect_warning’. This is
rs_qosv_24H CARRH In_station_minor achieved using the commands
detailed in Table 4-31.
rs_qosv_15M CARRM In_station_minor
View CARRV N/A Displays priorities for the above

alarms.
Table 4-20
Config/Alarms/Rau_priority/Ms
ms_Ais CARMA In_station_minor The RAU priority for each of these

ms_Rdi CARMR Deferred_major ‘Prompt_critical’, ‘Deferred_major’,
ms_eXc CARMX Prompt_critical
ms_Deg CARMD Deferred_major achieved using the commands
ms_qosv_24H CARMH In_station_minor
ms_qosv_15M CARMM In_station_minor
View CARMV N/A Displays priorities for the above

alarms.

Table 4-21
Config/Alarms/Rau_priority/Au
au_Ais CARAA In_station_minor The RAU priority for each of these
‘Prompt_critical’, ‘Deferred_major’,
Int_au_Ais C A R A IA In_station_minor
Int_au_loP C A R A IP Deferred_major achieved using the commands
View CARAV N/A Displays priorities for the above
alarms.
Table 4-22
Config/Alarms/Rau_priority/Hp
hp_eXc CARHX Prompt_critical The RAU priority for each of
hp_Deg CARHD Deferred_major
hp_Tim CARHT Deferred_major ‘Deferred_major’,
hp_Rdi CARHR Deferred_major ‘Disconnect_warning’. This is
hp_LoM C A R H LM Deferred_major achieved using the commands
hp_rEi CARHE Deferred_major
hp_Plm CARHP Deferred_major
Int_hp_inSert_buS C A R H IS Prompt_critical
Int_hp_Thru_bus C A R H IT Prompt_critical
Int_hp_ip_Buffer C A R H IB Deferred_major
hp_qosv_24H CARHH In_station_minor
hp_qosv_15M CARHM In_station_minor
hp_Fe_qosv_24H C A R H FH In_station_minor
hp_Fe_qosv_15M C A R H FM In_station_minor
View CARHV N/A Displays priorities for the above
alarms.
Table 4-23
Config/Alarms/Rau_priority/Tu
tu_Ais CARTA In_station_minor The RAU priority for each of these
tu_loP CARTP Deferred_major
‘Prompt_critical’, ‘Deferred_major’,
Int_tu_Ais C A R T IA In_station_minor ‘In_station_minor’, or
Int_tu_loP C A R T IP Deferred_major achieved using the commands
View CARTV N/A Displays priorities for the above
alarms.

Table 4-24
Config/Alarms/Rau_priority/Lp
lp_eXc CARLX Deferred_major The RAU priority for each of these

lp_Deg CARLD Deferred_major ‘Prompt_critical’,
lp_Plm CARLP Deferred_major
lp_Rdi CARLR Deferred_major ‘Disconnect_warning’. This is
achieved using the commands
lp_rEi CARLE Deferred_major detailed in Table 4-31.
lp_Tim CARLT Deferred_major
"
int_lp_Ip_Buffer C A R L IB Deferred_major
int_lp_Op_Buffer C A R L OB Deferred_major
lp_qosv_24H CARLH In_station_minor
lp_qosv_15M CARLM In_station_minor
lp_Fe_qosv_24H C A R L FH In_station_minor
lp_Fe_qosv_15M C A R L FM In_station_minor
View CARLV N/A Displays priorities for the above

alarms.
Table 4-25
Config/Alarms/Rau_priority/Ppi
ppi_Tf CARPT Deferred_major The RAU priority for each of

ppi_loS CARPS Deferred_major ‘Prompt_critical’,
ppi_Ais CARPA In_station_minor ‘Deferred_major’,
ppi_eXc CARPX Deferred_major ‘Disconnect_warning’. This is
ppi_Deg CARPD Deferred_major
ppi_Unexp_signal CARPU In_station_minor
ppi_loF CARPF Prompt_critical
ppi_LoM C A R P LM Prompt_critical
ppi_Rai CARPR Deferred_major

ppi_Crc_qosv_15M C A R P CM In_station_minor
ppi_Crc_qosv_24H C A R P CH In_station_minor
ppi_cv_qosv_15M CARPM In_station_minor
ppi_cv_qosv_24H CARPH In_station_minor

View CARPV N/A Displays priorities for the
above alarms.
Note: setting PPI_LOF RAU priority effect alarms on both VC3 and QUAD2M boards

Table 4-26
Config/Alarms/Rau_priority/Sync
sync_setg_Fail CARSF Deferred_major The RAU priority for each of

sync_src_Not_primary CARSN Prompt_critical ‘Prompt_critical’,
sync_ext_Sync_los CARSS Prompt_critical ‘In_station_minor’, or
Int_sync_Trib_line_Fail C A R S ITF Prompt_critical
Int_sync_Oscillator_Fail C A R S IOF Prompt_critical detailed in Table 4-31.
View CARSV N/A Displays priorities for the above

alarms.
Table 4-27
Config/Alarms/Rau_priority/TM
tm_Tf C A R TM T Deferred_major The RAU priority for each of

tm_Ais C A R TM A Instation_minor ‘In_station_minor’, or
View C A R TM V N/A Displays RAU priorities.
Table 4-28
Config/Alarms/Rau_priority/misC
Qecc_comms_Fail C A R C QF Prompt_critical The RAU priority for each of

Int_ne_Comms_Fail C A R C ICF Prompt_critical ‘Prompt_critical’,
ps_Power_Fail C A R C PF Prompt_critical
int_ne_Ram_Fail C A R C RF Prompt_critical
int_ne_Sw_Corrupt C A R C SC Prompt_critical detailed in Table 4-31.
int_ne_Config_Corrupt C A R C CC Prompt_critical
int_ne_Mfs_pulse_Fail C A R C MF Prompt_critical
ne_Lan_Alarm C A R C LA Prompt_critical
ne_np1_Switch_Alarm C A R C SA Deferred_major
ne_Unexpected_Lan C A R C UL Deferred_major
int_ne_config_Bp_Mismatch C A R C BM Prompt_critical
ne_Unit_Fail C A R C UF Prompt_critical
ne_LoopBack_Alarm C A R C LBA Prompt_critical
View CARCV N/A Displays priorities for the

above alarms.

Table 4-29
Config/Alarms/Rau_priority/prOT
msp_Prot_Scheme C A R OT PS Major_deferred The RAU priority for each of
_ these alarms can be set to
mismatch ‘Prompt_critical’,
msp_Channel_ C A R OT CM Major_deferred
Mismatch
msp_Invalid_K_byte C A R OT IK Major_deferred achieved using the
s commands detailed in
Table 4-31.
View C A R OT V N/A Displays priorities for the
"
above alarms.
Table 4-30
Config/Alarms/Rau_priority/carD
ne_Card_Out C A R D CO Prompt_critical The RAU priority for each of
ne_Unexpected_Card C A R D UC In_station_minor
ne_Card_Fail C A R D CF Prompt_critical ‘Deferred_major’,
ne_Card_faulT C A R D CT Prompt_critical ‘Disconnect_warning’. This is
ne_Wrong_Card C A R D WC Prompt_critical achieved using the
commands detailed in
Table 4-31.
View CARDV N/A Displays priorities for the
above alarms.
Table 4-31
Config/Alarms/Rau_priority/<alarm group>/<alarm>
Prompt_critical <Shortcut> P N/A no Sets priority to
‘Prompt_critical’.
Deferred_major <Shortcut> D N/A no Sets priority to
‘Deferred_major’.
In_station_minor <Shortcut> I N/A no Sets priority to
‘In_station_minor’.
X_disconnect_ <Shortcut> X N/A no Sets priority to
warning ‘Disconnect_warning’.
Note: This table details the enable/disable options that are available for all of the alarms
listed from Table 4-17 to Table 4-28. The <Shortcut> element of the shortcut refers to the
shortcut for the relevant alarm.
Parameters
None of the commands within this branch of the user interface hierarchy
require parameters. All settings are defined through the use of
sub-commands.

Autonomous events
Reports
The reports generated by the RAU priority commands are detailed below.
Config/Alarms/Rau_Priority/Os/View
Config/Alarms/Rau_Priority/Es/View
Config/Alarms/Rau_Priority/Rs/View
Config/Alarms/Rau_Priority/Ms/View
Config/Alarms/Rau_Priority/Au/View
Config/Alarms/Rau_Priority/Hp/View
Config/Alarms/Rau_Priority/Tu/View
Config/Alarms/Rau_Priority/Lp/View
Config/Alarms/Rau_Priority/Ppi/View
Config/Alarms/Rau_Priority/Sync/View
Config/Alarms/Rau_Priority/Card/View
Config/Alarms/Rau_Priority/prOT/View
Config/Alarms/Rau_Priority/Misc/View
The reports for all view commands within this branch of the user interface
make use of the following entries:
174, Alarm_rau_priority
175, <alarm_name>_rau = <‘Prompt_critical’|
‘Deferred_major’|‘In_station_minor’|
’X_disconnect_warning’>
Where:
• <alarm_name> is the capitalised form of the alarm name.
For example:
175, OS_OPTICAL_POWER_HIGH_rau = Prompt_critical
175, OS_OPTICAL_POWER_OOL_rau = Prompt_critical
175, INT_OS_LASER_TEST_rau = In_station_minor
175, OS_LASER_SHUTDOWN_rau = Prompt_critical
175, OS_LASER_TEMP_HI_LOW_rau = Deferred_major
175, OS_OPTICAL_POWER_LOW_rau = Deferred_major
;
175, ES-CMI_OUTPUT_FAIL_rau = Prompt_critical
175, ES-CMI_VIOLATION_rau = Prompt_critical
;
175, RS_LOS_rau = Prompt_critical
175, RS_LOF_rau = Prompt_critical
175, RS_REALIGN_PHASE_rau = Prompt_critical
175, RS_QOSV_24H_rau = Prompt_critical
175, RS_QOSV_15M_rau = Prompt_critical
;

175, MS_AIS_au = In_station_minor
175, MS_RDI_rau = Deferred_major
175, MS_EXC_rau = Prompt_critical
175, MS_DEG_rau = Deferred_major
175, MS_QOSV_24H_rau = Prompt_critical
175, MS_QOSV_15M_rau = Prompt_critical
;
175, AU_AIS_rau = In_station_minor
175, INT_AU_AIS_rau = In_station_minor
175, INT_AU_LOP_rau = Deferred_major
;
175,
175,
HP_EXC_rau = Prompt_critical
HP_DEG_rau = Deferred_major "
175, HP_TIM_rau = Deferred_major
175, HP_RDI_rau = Deferred_major
175, HP_LOM_rau = Deferred_major
175, HP_REI_rau = Deferred_major
175, HP_PLM_rau = Deferred_major
175, INT_HP_INSERT_BUS_rau = Prompt_critical
175, INT_HP_THRU_BUS_rau = Prompt_critical
175, INT_HP_IP_BUFFER = Deferred_major
175, HP_QOSV_24H_rau = Prompt_critical
175, HP_QOSV_15M_rau = Prompt_critical
175, HP_FE_QOSV_24H_rau = Prompt_critical
175, HP_FE_QOSV_15M_rau = Prompt_critical
;
175, TU_AIS_rau = In_station_minor
175, TU_LOP_rau = Deferred_major
175, INT_TU_AIS_rau = In_station_minor
175, INT_TU_LOP_rau = Deferred_major
;
175, LP_EXC_rau = Prompt_critical
175, LP_DEG_rau = Deferred_major
175, LP_PLM_rau = Deferred_major
175, LP_RDI_rau = Deferred_major
175, LP_REI_rau = Deferred_major
175, LP_TIM_rau = Deferred_major
175, INT_LP_IP_BUFFER_rau = Deferred_major
175, INT_LP_OP_BUFFER_rau = Deferred_major
175, LP_QOSV_24H_rau = Prompt_critical
175, LP_QOSV_15M_rau = Prompt_critical
175, LP_FE_QOSV_24H_rau = Prompt_critical
175, LP_FE_QOSV_15M_rau = Prompt_critical
;
174,Alarm_rau_priority
175,PPI_EXC_rau = Deferred_major
175,PPI_DEG_rau = Deferred_major
175,PPI_AIS_rau = Deferred_major
175,PPI_LOS_rau = Deferred_major
175,PPI_TF_rau = Deferred_major

175,PPI_LOF_rau = Deferred_major
175,PPI_RAI_rau = Deferred_major
175,PPI_CV_QOSV_15M_rau = In_station_minor
175,PPI_CV_QOSV_24H_rau = In_station_minor
175,PPI_Unexp_Signal_rau = Deferred_major
175,PPI_CRC_QOSV_15M_rau = In_station_minor
175,PPI_CRC_QOSV_24H_rau = In_station_minor
175,PPI_LOM_rau = Deferred_major
;
175, TM-AIS_rau = Prompt_critical
175, TM-TF_rau = Prompt_critical
;
175, SYNC_SETG_FAIL_rau = Prompt_critical
175, SYNC_SRC_NOT_PRIMARY_rau = Prompt_critical
175, SYNC_EXT_SYNC_LOS_rau = Prompt_critical
175, INT_SYNC_TRIB_LINE_FAIL_rau = Prompt_critical
175, INT_SYNC_OSCILLATOR_FAIL_rau = Prompt_critical
;
175, QECC_COMMS_FAIL_rau = Prompt_critical
175, INT_QECC_COMMS_FAIL_rau = Prompt_critical
175, EA_INPUT_rau = Prompt_critical
175, INT_NE_RAM_FAIL_rau = Prompt_critical
175, INT_NE_SW_CORRUPT_rau = Prompt_critical
175, INT_NE_CONFIG_CORRUPT_rau = Prompt_critical
175, INT_NE_MFS_PULSE_FAIL_rau = Prompt_critical
175, NE_LAN_ALARM_rau = Prompt_critical
175, INT_EC_ALARMS_BUFFERING = Prompt_critical
175, NE_NP1_SWITCH_ALARM_rau = Prompt_critical
175, NE_UNEXPECTED_LAN_rau = Prompt_critical
175, INT_NE-UNIT_FAIL_rau = Prompt_critical
175, PS_POWER_FAIL_rau = Prompt_critical
175, NE_LOOPBACK_ALARM_rau = Deferred_major
;
175, MSP_PROTECTION_SCHEME_MISMATCH_rau = Prompt_critical
175, MSP_CHANNEL_MISMATCH_rau = Prompt_critical
175, MSP_INVALID_K_BYTES_rau = Prompt_critical
;
175, NE_CARD_OUT_rau = Prompt_critical
175, NE_UNEXPECTED_CARD_rau = Prompt_critical
175, NE_CARD_FAIL_rau = Prompt_critical
175, NE_CARD_FAULT_rau = Prompt_critical
175, NE_WRONG_CARD_rau = Prompt_critical
;

Config/Alarms/misC <C A C>

This command enables the user to access the lamplocking functionality of the
TN-1X.
Lamplocking
The lamplock facility can be used to latch the subrack lamp state of alarms
that are raised, but quickly cleared. When lamplocking is active, the lamps
that are lit on the subrack will remain lit after the alarm has cleared. Operator
intervention is required to clear down the lit lamps.
Lamplocking is of value in an unmanaged network. However, it is not

necessary to use this facility in a managed network, as more sophisticated
mechanisms exist on the Element Controller.
Command details "

The commands that access the lamplocking functionality of the TN-1X are
shown in Figure 4-8 below, and are detailed in Table 4-32.
Figure 4-8
Config/Alarms/misC command hierarchy
Config
Alarms
misC
Lamplock_oN
Lamplock_Off
View
Table 4-32
Config/Alarms/misC
lamplock_oN C A C LN N/A No Enables lamplocking.
lamplock_Off C A C LO Disables lamplocking.
View CACV N/A No Views lamplocking settings.
Parameters
There are no parameters associated with the above commands.
Autonomous events

Reports
The reports generated by the commands described above are detailed below.
Config/Alarms/misC/View
144, Alarm Miscellaneous
145, RAU_Lamplock=<‘On’|‘Off’>
For example:
144, Alarm Miscellaneous
145, RAU_Lamplock=Off
;

Config/perF_mon <C F>

This command enables the user to control the performance monitoring
functionality of the TN-1X.
Performance monitoring
The performance monitoring functionality of the TN-1X enables the user to
monitor the occurrences of different types of errors at a number of
Performance Monitoring Points (PMPs) within the mux. The duration of the
performance monitoring period and the PMPs which are enabled can be
configured by the user. Threshold levels of errors, above which Quality Of
Service Violation (QOSV) alarms are raised, can also be set by the user for
many error types.
Performance monitoring results are stored by the TN-1X as performance logs.

These can be viewed by the user (see “Performance logs” on page 7-3). "
Note: By default, all performance monitoring functionality is disabled.
Error measurement methods

Errors are measured in a number of ways by the TN-1X. The error
measurement methods described below are used to create the performance
monitoring statistics detailed in “Performance statistics” on page 4-34.
• Frame-based error measurement relates to the occurrence of parity errors
within the STM-1 frame, and can be performed in one of two ways.
— Older Nortel SDH hardware uses a Block Interleaved Parity (BIP)
basis of measurement. This identifies the number of parity bit errors
within each STM-1 frame, and accumulates this count over a full
second. As 8000 frames are transmitted per second, and there are eight
parity bits in each frame, a total of 64000 parity errors can be
accumulated per second on a BIP basis.
— Newer Nortel SDH hardware typically uses a Block basis of
measurement. This identifies the number of STM-1 frames which
contain one or more parity bit errors during each second. As 8000
frames are transmitted per second, a total of 8000 parity errors can be
accumulated per second on a Block basis.
Frame-based error measurements contribute to the ES, SES, BBE and UAS
performance monitoring statistics (see “Performance statistics” on page
4-34).
Note 1: The NE can be set to measure frame-based errors on a BIP or

Block basis. BIP is supported by all Nortel SDH hardware, but Block is
not. Where a Block basis is selected, any hardware that does not support
this will use a BIP basis instead.
Note 2: Frame-based error measurement can also be referred to as
“block-based” error measurement. This should not be confused with the
Block basis of frame-based measurement described above.

• Count-based error measurement relates to the presence of specific error

conditions. There are two such conditions:
— A Pointer Justification Event (PJE). A PJE occurs when a positive or
negative movement of a payload pointer within an STM-1 frame is
detected.
— An Out Of Frame (OOF) error. An OOF error occurs when a
misalignment of the header bytes within the regenerator section
overhead of an STM-1 frame is detected.
A count of these two error conditions across the performance monitoring
period is recorded as the OOF and PJE performance statistics.
Performance statistics
There are a number of performance statistics that are accumulated by the
TN-1X when performance monitoring is active. These statistics are based on
the error measurement methods described in “Error measurement methods” on
page 4-33, and are accumulated for enabled PMPs across the performance
monitoring period.
• Errored Seconds (ES). An ES is a second in which one or more
frame-based errors occur, or an alarm relevant to the PMP occurs. The
number of errors within this second is not recorded.
• Severely Errored Seconds (SES). An SES is a second in which a threshold
level of frame-based errors occur, or an alarm relevant to the PMP occurs.
The total number of errors is not recorded. An SES is, by definition, an ES
also. The threshold number of frame-based errors which distinguish an ES
from an SES can be configured by the user, on both a BIP and block basis.
Note: It is advised that the default SES thresholds are maintained.
• Background Bit Errors (BBE). A BBE is recorded for each frame (not
included in a SES) in which there is an anomaly. An anomaly is an error or
a small discrepancy that does not interrupt the performance of a function.
The nature of anomalies will vary between different PMPs.
• Unavailable Seconds (UAS). A UAS is any second which forms part of a
period of Unavailable Time (UAT). A period of UAT starts with the onset
of ten consecutive SESs (included in UAT). The period of UAT ends when
there are ten consecutive non-SES seconds (not included in the UAT).
Note: During periods of unavailable time (UAT), the ES, SES and BBE
statistics are not recorded. The start of UAT is indicated by ten consecutive
SESs. Until this ten seconds is complete, however, it is unclear whether the
ES, SES and BBE figures accumulated will be recorded. As a result, there
is a ten second delay in all performance monitoring timestamps.
• Out Of Frame (OOF) seconds. An OOF second is a second during which

one or more OOF errors are recorded. An OOF error occurs when a
misalignment of the header bytes within the regenerator section overhead
of an STM-1 frame is detected.

• Pointer Justification Events (PJE). A PJE is recorded when a positive or

negative movement of a payload pointer within an STM-1 frame is
detected. The total number of negative PJEs is also recorded. The
difference between these two counts identifies the number of positive
pointer movements.
Note: An Administrative Unit PJE count (AU-PJE) is supported on the
25U PJ00 750 HZQ Payload Manager, and all subsequent releases of the
Payload Manager. A Tributary Unit PJE count (TU-PJE) is supported on
the 25U JU00 750 HVT/HVQ 2 Mbit/s Tributary Units, and on all
subsequent releases of the 2 Mbit/s Tributary Unit. This is also supported
on the NTKD16AA/NTKD16BA 34/45 Mbit/s Tributary Unit.
• Assessed Seconds (AS). The AS is the number of seconds during which the
performance monitoring statistics were accumulated. Typically, this is
equivalent to the length of the performance monitoring period. However, if "
the mux is rebooted, or the performance monitoring period is terminated
prematurely, or the mux clock changes, the AS total may be shorter or
longer than the performance period.
These performance monitoring results are stored by the NE as performance

logs, which can be viewed by the user (see “Performance logs” on page 7-3).
Threshold levels of ES, SES, BBE and UAS, above which Quality Of Service
Violation (QOSV) alarms are raised, can be set by the user for all PMPs that
measure frame-based errors. See “Quality of Service Violation (QOSV)
alarms” on page 4-37 for details.
Performance monitoring points

Performance Monitoring Points (PMPs) are points within the mux at which
performance data is collected. This data relates to the quality of the
transmission path passing through that point. Each PMP can be enabled and
disabled on a per instance basis.
Note 1: TN-1X hardware only provides monitoring at a traffic termination

path. No performance data relating to through traffic is collected.
Note 2: If monitoring is disabled for a PMP, performance statistics are not
reset. These are retained until monitoring is turned on again, at which point
they are cleared. Reporting on a PMP for which monitoring is disabled will
retrieve these static counts.
Note 3: If performance monitoring is enabled for a port where a physical
connector is not present, a QOSV alarm will be raised. Once rectified, this
will persist until the start of the next monitoring period.
Note 4: HP, HP-FE and AU-PJE performance monitoring points for pairs
of MSP channels will always be reported against the working channel.
Note 5: By default, all performance monitoring points are disabled.
Note 6: PPI-CRC (CRC4) only available on 2 Mbit/s tributary ports with
Quad2M version 5.

The PMPs within the TN-1X are listed in Table 4-33. The default state for
these PMPs is shown, and an indication of which performance statistics are
collected for the PMP is also given.
Table 4-33
Performance monitoring points (PMPs) and performance statistics
PMP Description Default Frame-based Count-based

State
ES SES BBE UAS OOF PJE
RS Regenerator Section Disabled Yes Yes Yes Yes - -
RS-OOF Regenerator Section Out Of Disabled - - - - Yes -

Frame
MS Multiplexer Section Disabled Yes Yes Yes Yes - -
HP High-order Path Disabled Yes Yes Yes Yes - -
HP-FE High-order Path Far End Disabled Yes Yes Yes Yes - -
AU-PJE Administrative Unit Pointer Disabled - - - - - Yes

Justification Events
LP Low-order Path Disabled Yes Yes Yes Yes - -
LP-FE Low-order Path Far End Disabled Yes Yes Yes Yes - -
TU-PJE Tributary Unit Pointer Disabled - - - - - Yes

Justification Events
PPI-CV PDH Physical Interface Code Disabled Yes Yes Yes Yes - -
Violations
PPI-CRC PDH Physical Interface Cyclic Disabled Yes Yes Yes Yes - -
Redundancy Check
Performance monitoring periods

Performance monitoring data is accumulated over a performance monitoring
period. There are two types of monitoring periods. These are:
• Twenty-four hour (24H) monitoring period. Performance monitoring
results can be calculated for any twenty four hour period. The starting hour
for such a period can be configured by the user, though the default start
time is midnight.
• Fifteen minute (15M) monitoring period. Performance monitoring results
are automatically calculated for each fifteen minute period of the day. The
start and end times for 15M monitoring periods are fixed on quarter-hour
boundaries.

CAUTION
15 minute performance monitoring
The wider range of performance monitoring options provides
greater flexibility when monitoring service quality. 24 hour
performance monitoring is used for normal performance
monitoring measurements. 15 minute performance monitoring
produces large quantities of data, and should only be used on a
manual basis for specific maintenance measurements. Do NOT
use it to collect performance monitoring data automatically.
At the end of a monitoring period, the monitoring results are stored as a

performance log (see “Performance logs” on page 4-37). The totals are then
reset, and a new monitoring period begins.
"
Both 15M and 24H monitoring periods can be terminated prematurely. In this
event (like scheduled termination), the performance log is stored, totals are
reset, and a new monitoring period begins immediately. The new period will
end, in most cases, when the terminated period was scheduled to end.
The exception to the above rule is when a terminated 15 minute period has
less than half of its scheduled fifteen minutes remaining. In this instance, the
new period will not end at the scheduled end of the current period, but will
continue to the end of the next 15 minute period. As a result, the duration of
the new period can be over twenty two minutes.
Note: The premature termination of a performance monitoring period is

performed from a different menu. See “Terminating performance
monitoring prematurely” on page 6-2.
Performance logs
Performance logs store the results of individual monitoring periods during
which monitoring was active. These logs are numbered from ‘1’, with the
latest logs having the highest log numbers. The most current log can also be
referred to by a log number of -1.
The number of performance logs that the TN-1X can store is variable.
Between sixteen and forty 15 minute performance logs can be stored,
depending on the number of PMPs that are enabled. A maximum of two
24 hour logs can be stored.
If it is not possible to store a new performance log, the oldest will be deleted.
To avoid loss of data, the Preside EC-1 Element Controller must upload
performance monitoring results frequently.
Note: The viewing of performance logs is performed from a different

menu. See “Performance logs” on page 7-3 for details.
Quality of Service Violation (QOSV) alarms

Quality Of Service Violation (QOSV) alarms are triggered by threshold levels
of the ES, SES, BBE and UAS performance counts. These alarms, which can

be enabled and disabled on a PMP basis, can only be raised if both monitoring
and alarm raising are enabled for the affected PMP. QOSV thresholds can be
defined by the user on both a BIP and Block basis.
Threshold levels of ES, SES, BBE and UAS can be set by the user only for
existing connections. If a connection is removed, the QOSV thresholds that
relate to it are defaulted.
Note 1: If alarm raising is disabled for a PMP, monitoring is unaffected.

Error counts will still be collated, and results will be stored. These results,
however, will not be used to trigger alarm events.
Note 2: If performance monitoring is enabled for a port where a physical
connector is not present, a QOSV alarm will be raised. Once rectified, this
will persist until the start of the next monitoring period.
Command details
The commands that access the performance monitoring functionality of the
follow.
Figure 4-9
Config/perF_mon command hierarchy
Config
perF_mon
Ses_defines
24H
15M
Uat
sTart_24h
Basis
Table 4-34
Config/perF_mon
Menu item Shortcut Description
Ses_defines CFS See Table 4-35.
24H CFH These items share a common set of sub-commands, each

of which represents a performance monitoring point (PMP).
15M CFM These are detailed in Table 4-36.
Uat CFU See Table 4-43.
sTart_24h CFT See Table 4-48.
Basis CFB See Table 4-49.

Table 4-35
Config/perF_mon/Ses_defines
Menu item Shortcut Parameters Range Confirm Description
Rs_ses CFSR BIP_threshold | 1-8000 No Sets the number

‘D’ | (block, of errors that
Ms_ses C F S MS ‘P’ def 2400) must occur
[block_threshold | before an ES
Hp_ses C F S HP ‘D’ | 1-64000 becomes a SES.
‘P’] (BIP, def
Hp_fe_ses C F S HF
2400) Default settings
are selected
LP_vc12_ses CFS 1-2000 using ‘D’.
LP712 (block,
def 600) Current settings
LP_vc3_ses C F S LP3 are preserved
"
1-2000 using ‘P’.
Lp_Fe_vc12_ses C F S LF12
(BIP,
def 600
Lp_Fe_vc3_ses C F S LF3
ppi_2mCrc_ses CFSC integer ‘D’ | ‘P’ 1-1000 No Sets the SES bit
[integer | D] (default and block
block = thresholds for
300, BIP PPI_CRC
= 300) performance
monitoring
View CFSV N/A N/A No Displays all SES

thresholds.
Note 1: Each SES setting applies to all instances of a performance monitoring point. For example, the
SES setting for the RS PMP applies to both aggregates, and any STM-1 tributary units.
Note 2: All of the above commands (except View) are only available to the system engineer user class
Table 4-36
Config/perF_mon/<15M | 24H>
Menu item Shortcut Parameters Description
RS_ne <shortcut> RS Each of these commands has a number of sub-commands.

See Table 4-37.
MS_ne <shortcut> MS
HP_ne <shortcut> HP Each of these commands has a number of sub-commands.

See Table 4-38.
Hp_Fe <shortcut> HF
LP_ne <shortcut> LP Each of these commands has a number of sub-commands.

See Table 4-39.
Lp_Fe <shortcut> LF
Ppi_Cv <shortcut> PC
Ppi_cRc <shortcut> PR
Rs_Oof <shortcut> RO This command has two subcommands. See Table 4-40.
Au_pJe <shortcut> AJ This command has two subcommands. See Table 4-41.
Tu_pJe <shortcut> TJ This command has two subcommands. See Table 4-42.
View <shortcut> V PMP Displays performance thresholds for the

(see Note 1) specified PMP.
Note 1: If this parameter is not provided, information for all PMPs is displayed.

Table 4-37
Config/perF_mon/<15M | 24H>/<RS_ne | MS_ne>
Es_threshold <Shortcut> E SDH_port | ‘all’ No Sets the threshold for QOSV

threshold | ‘D’ alarm raising.
Ses_threshold <Shortcut> S
Default settings are selected
Bbe_threshold <Shortcut> B using ‘D’.
Uas_threshold <Shortcut> U
Monitoring_On <Shortcut> M O SDH_port | ‘all’ No Enables/disables the

processing of results for one
Monitoring_oFf <Shortcut> M F or all SDH physical ports.
Alarm_On <Shortcut> A O Enables/disables alarm raising

from results for one or all SDH
Alarm_oFf <Shortcut> A F physical ports.
View <Shortcut> V SDH_port | No Displays QOSV thresholds.

SDH_slot |
‘all’
(See note 2)
Note 1: The <Shortcut> element of the shortcut is the relevant shortcut for the parent command. The
parent commands are listed in Table 4-36.
Note 2: If this parameter is not provided, all eligible information is displayed.
Table 4-38
Config/perF_mon/<15M | 24H>/<HP_ne | Hp_Fe>
Es_threshold <Shortcut> E SDH_AU4 | ‘all’ No Sets the threshold for QOSV

threshold | ‘D’ alarm raising.
Ses_threshold <Shortcut> S
Default settings are selected
Bbe_threshold <Shortcut> B using ‘D’.
Uas_threshold <Shortcut> U
Monitoring_On <Shortcut> MO SDH_AU4 | ‘all’ No Enables/disables the

Monitoring_oFf <Shortcut> MF or all AU4s.
Alarm_On <Shortcut> AO Enables/disables alarm raising

from results for one or all
Alarm_oFf <Shortcut> AF AU4s.
View <Shortcut> V SDH_AU4 | No Displays QOSV thresholds.

SDH_port |
SDH_slot |
‘all’
(See note 2)

Table 4-39
Config/perF_mon/<15M | 24H>/<LP_ne | Lp_Fe | Ppi_Cv | Ppi_cRc>
Es_threshold <Shortcut> E PDH_port | ‘all’ No Sets the threshold for

threshold | ‘D’ QOSV alarm raising.
(default =2)
Default settings are
15M range= 1-900 selected using ‘D’.
24H range= 1-65536
Ses_threshold <Shortcut> S PDH_port | ‘all’

threshold | ‘D’
(default =1)
15M range= 1-900
"
24H range= 1-65536
Bbe_threshold <Shortcut> B PDH_port | ‘all’

threshold | ‘D’
(default =2)
15M range= 1-900

24H range= 1-65536
Uas_threshold <Shortcut> U PDH_port | ‘all’

threshold | ‘D’
(default =10)
15M range= 1-900

24H range= 1-65536
Monitoring_On <Shortcut> MO PDH_port | ‘all’ No Enables/disables the

processing of results for
Monitoring_oFf <Shortcut> MF one or all PDH ports.
Alarm_oN <Shortcut> AN Enables/disables alarm

raising from results for one
Alarm_Off <Shortcut> AO or all PDH ports.
View <Shortcut> V PDH_port | No Displays QOSV

PDH_slot | thresholds.
‘all’
(see Note 2)
Table 4-40
Config/perF_mon/<15M | 24H>/Rs_Oof
Monitoring_On <Shortcut> MO SDH_port | ‘all’ No Enables/disables the

Monitoring_oFf <Shortcut> MF or all SDH physical points.

Table 4-40
Config/perF_mon/<15M | 24H>/Rs_Oof

SDH_slot | ‘all’
(See note 2)
Table 4-41
Config/perF_mon/<15M | 24H>/Au_pJe

Monitoring_oFf <Shortcut> MF one or all AU4s.

SDH_port |
SDH_slot | ‘all’
(See note 2)
Table 4-42
Config/perF_mon/<15M | 24H>/Tu_pJe>

Monitoring_oFf <Shortcut> MF one or all SDH aggregate
payloads.
View <Shortcut> V PDH_port | No Displays QOSV thresholds.

PDH_slot | ‘all’
(See note 2)
Table 4-43
Config/perF_mon/Uat
Item Shortcut Parameters Description
RS_ne C F U RS Each of these commands has a number of sub-commands.

See Table 4-44.
MS_ne C F U MS
HP_ne C F U HP Each of these commands has a number of sub-commands.

See Table 4-45.
Hp_Fe C F U HF

Table 4-43
Config/perF_mon/Uat
Item Shortcut Parameters Description
LP_ne C F U LP Each of these commands has a number of sub-commands.

See Table 4-46.
Lp_Fe C F U LF
Ppi_Cv C F U PC
Ppi_cRc C F U PR Each of these commands has a number of sub-commands.

See Table 4-47
View CFUV PMP Displays performance thresholds for the

(See note) specified PMP.
Note: If this parameter is not provided, information for all PMPs is displayed.
Table 4-44 "

Config/perF_mon/Uat/<RS_ne | MS_ne>
Monitoring_On <Shortcut> M O SDH_port | No Enables/disables the processing

‘all’ of results for one or all SDH
Monitoring_oFf <Shortcut> M F physical ports.

SDH_slot |
‘all’
(See note 2)
Table 4-45
Config/perF_mon/Uat/<HP_ne | Hp_Fe>

Monitoring_oFf <Shortcut> MF or all AU4s.

SDH_port |
SDH_slot |
‘all’
(See note 2)

Table 4-46
Config/perF_mon/<15M | 24H | Uat>/<LP_ne | Lp_Fe | Ppi_Cv>

Monitoring_oFf <Shortcut> MF or all PDH ports.
View <Shortcut> V PDH_port | No Displays QOSV thresholds.

PDH_slot |
‘all’
(See note 2)
Table 4-47
Config/perF_mon/Uat/Ppi_cRc/
Monitoring_oN <Shortcut> MN PDH_port | ‘all’ No Enables/disables Monitoring

for valid PPI_CRC monitoring
Monitoring_Off <Shortcut> MO points, both 24H and 15M
QOSV points are effected
View <Shortcut> V PDH_port | No Displays monitoring status of

PDH_slot | unavailable time for valid
‘all’ PPI_CRC monitoring points.
(See note 2)
Table 4-48
Config/perF_mon/Start_24h
Set CFSS hour No Set starting hour for 24H monitoring

(default 0, which is midnight).
View CFSV N/A No View starting hour setting.
Table 4-49
Config/perF_mon/Basis
biP_only CFBP N/A No Enables Bit Interleaved Parity

(default) (BIP) basis performance
monitoring for the entire NE.
blocK CFBK N/A No Enables Block basis

performance monitoring for the
entire NE, where supported. BIP
is used where Block is not
supported.
View CFBV N/A No View basis settings.

Parameters
• The <BIP_threshold> parameter defines the SES threshold for
frame-based performance monitoring on a BIP basis. This has a range of
1-8000, and a default of 2400.
• The <Block_threshold> parameter defines the SES threshold for
frame-based performance monitoring on a Block basis. This has a range of
1-64000, and a default of 2400.
• The <threshold> value defines a number of errors that are required to
trigger a QOSV alarm. This can be applied to ES, SES, BBE and UAS
statistics.
• The ‘D’ entry is used instead of a threshold value. It indicates that the
default setting should be applied to the relevant parameter. "
• The ‘P’ entry is used instead of a threshold value. It indicates that the
current setting for the threshold should be preserved. For example:
P 3130
The above example parameters indicate that a new Block-based

threshold of 3130 is to be established, and that the current
BIP-based threshold should be preserved.



S<slot>-<port>
• The <SDH_slot> parameter identifies all SDH ports and/or payloads for
the specified slot. The format for this is:
S<slot>
following syntax:
S<slot>-<port>
• The <integer> parameter defines the CRC4 threshold for selected event:
— 15M range= 1 to 900
— 24H range= 1 to 65536

• The <PDH_slot> parameter identifies all PDH ports for the specified slot.
The format for this is:
S<slot>
• The <PMP> parameter identifies a specific PMP. This can be set to one of
the following (see “Performance monitoring points” on page 4-35 for
details of these):
— RS
— RS-OOF
— MS
— HP
— HP-FE
— AU-PJE
— LP
— LP-FE
— TU-PJE
— PPI-CV
— PPI_CRC
• The <hour> parameter is a number between 0 and 23, representing the
starting hour for a 24 hour period of performance monitoring.
Autonomous events
There are no autonomous events generated by the above commands.

Reports
The reports generated by the above commands are detailed below.
Note: Performance monitoring log reports are accessible via the view
status menu (see “Performance logs” on page 7-3).
Config/perF_mon/Ses_defines/View
The view command will include a report for the SES definitions for the new
performance monitoring point.
This report displays the SES thresholds for the PMP for which this can be
defined. The report uses the following entries:
18, SES Thresholds
181, <PMP>_ses_threshold_block=<value>,
<PMP>_ses_threshold_bit=<value> "
Where:
• The <PMP> field is the capitalised form of the PMP name.
• The <value> field is the threshold value assigned to the PMP.
For example:
18,SES Thresholds
181,RS_SES_threshold_block=2400,RS_SES_threshold_bit=2400
181,MS_SES_threshold_block=2400,MS_SES_threshold_bit=2400
181,HP_SES_threshold_block=2400,HP_SES_threshold_bit=2400
181,HP_FE_SES_threshold_block=2400,
HP_FE_SES_threshold_bit=2400
181,LP_vc3_SES_threshold_block=600,
LP_vc3_SES_threshold_bit=600
181,LP_FE_vc3_SES_threshold_block=-1,
LP_FE_vc3_SES_threshold_bit=-1
181,LP_vc12_SES_threshold_block=600,
LP_vc12_SES_threshold_bit=600
181,LP_FE_vc12_SES_threshold_block=600,
LP_FE_vc12_SES_threshold_bit=600
181,PPI_CRC_vc12_SES_threshold_block=200,
PPI_CRC_vc12_SES_threshold_bit=100
;
Config/perF_mon/24H/View <port | slot | ALL>

The user can view all valid 24H Performance monitoring points for PPI_CRC
on a per port, per slot, or all basis.
For example:
182,Performance Monitoring Configuration
183,S2-1,PPI-CRC,24H,PM_monitoring=On
184,S2-1,PPI-CRC,24H,Alarm_enable=On,ES=2,SES=1,BBE=2,UAS=101
;

messages 183 and 184 are repeated for each valid 24 hour PPI_CRC
monitoring point that matches the user request argument.
If the view of PPI-CRC performance monitoring is for a slot containing an

HVT or HVQ which has nor yet reported its ASIC type the string -
Indeterminate will be added to the reports;
183,S2-1,PPI-CRC,24H,PM_monitoring=On - Indeterminate
- Indeterminate
If the view of PPI-CRC performance monitoring is for a slot containing a

23AA (equipped as HVT) or 23AB (equipped as HVQ) which has reported its
ASIC type as older than version 5 the string - Invalid Wrong ASIC will be
added to the reports;
183,S2-1,PPI-CRC,24H,PM_monitoring=On - Invalid Wrong ASIC
- Invalid Wrong ASIC
Config/perF_mon/<15H|24H>/<PMP>/View
This report displays the enabled/disabled settings for performance monitoring.
The report uses the following entries:
182, Performance Monitoring
183, <SDH_port|SDH_AU4|SDH_aggr_payload|PDH_port>,
<PMP>, <PM_period>, Monitoring = <‘On’|‘Off’>
184, <SDH_port|SDH_AU4|PDH_port>, <PMP>, <PM_period>,
Alarm_enable = <‘On’|‘Off’>, ES = <threshold>,
SES = <threshold>, BBE = <threshold>,
UAS = <threshold>
Where:
• <PMP> is the capitalised form of the PMP’s name.
• <PM_period> is the performance monitoring period, and is set to either
‘15M’ or ‘24H’.
• <threshold> is the number of errors of the specified type.
For example:
182, Performance Monitoring
183, S2-1, LP, 15M, Monitoring = On
184, S2-1, LP, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S2-1, LP-FE, 15M, Monitoring = On
184, S2-1, LP-FE, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S2-1, PPI-CV, 15M, Monitoring = On
184, S2-1, PPI-CV, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S2-2, LP, 15M, Monitoring = On
184, S2-2, LP, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S2-2, LP-FE, 15M, Monitoring = On
184, S2-2, LP-FE, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S2-2, PPI-CV, 15M, Monitoring = On
184, S2-2, PPI-CV, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200

183, S6-1, RS, 15M, Monitoring = On

184, S6-1, RS, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S6-1, RS-OOF, 15M, Monitoring = On
183, S6-1, MS, 15M, Monitoring = On
184, S6-1, MS, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S6-1-J1, HP, 15M, Monitoring = On
184, S6-1-J1, HP, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S6-1-J1, HP-FE, 15M, Monitoring = On
184, S6-1-J1, HP-FE, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S6-1-J1, AU-PJE, 15M, Monitoring = On
183, S7-1, RS, 15M, Monitoring = On
184, S7-1, RS, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S7-1, RS-OOF, 15M, Monitoring = On
183, S7-1, MS, 15M, Monitoring = On
184, S7-1, MS, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
"
183, S7-1-J1, HP, 15M, Monitoring = On
184, S7-1-J1, HP, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S7-1-J1, HP-FE, 15M, Monitoring = On
184, S7-1-J1, HP-FE, 15M, Alarm_enable = On, ES = 20, SES = 20, BBE = 20, UAS = 200
183, S7-1-J1, AU-PJE, 15M, Monitoring = On
;
Config/perF_mon/sTart_24h/View
This view command uses the following entries
186, Performance Monitoring Configuration
187, Start_24H = <0-23>
For example:
186, Performance Monitoring Configuration
187, Start_24H = 7
Config/perF_mon/Uat/View <port | slot | ALL>

The user shall be able to view, on a port, slot, or all basis, the Monitoring
status of unavailable time for valid PPI_CRC monitoring points.
Foe example:
183,S2-1,PPI-CRC,UAT,PM_monitoring=On
183,S2-2,PPI-CRC,UAT,PM_monitoring=Off
;
Message 183 is repeated for each valid performance monitoring point which
matches the user selection criteria <port | slot | all>.
If no performance monitoring points exists then a blank report shall be

generated.
;
Config/perF_mon/Basis/View
This view command uses the following entries
188, PM Basis
189, PM_Basis = <‘Bit’|‘Block’>

For example:
188, PM Basis
189, PM_Basis = Bit

Config/Sync_source <C S>

This command enables the user to configure the synchronisation source
protection functionality of the TN-1X.
Synchronisation source protection

The synchronisation source protection functionality of the TN-1X enables the
user to control the way in which synchronisation is sourced for the mux.
Synchronisation source selection is detailed in the sections that follow.
Synchronisation sources
Synchronisation can be derived from the signals received on a number of ports.
These are:
• Either of the incoming STM-4 or STM-1 aggregate signals.
• Any STM-1 tributary signal. "
• Any VC-12 PDH signal on a 2M or 34M (16x2) tributary unit.
• Any VC-3 PDH tributary signal.
• External 2.048 MHz interface, via the Star Card module (not TN-1X/S).
• Internal 16.384 MHz master oscillator in the Payload Manager.
Note 1: It is recommended that synchronisation is taken from non-PDH

sources in preference to PDH sources.
Note 2: It is possible to add an unused or unconfigured tributary/aggregate
port to the synchronisation source hierarchy. It is the user’s responsibility
to ensure that the synchronisation sources in the hierarchy are configured
and valid.
Note 3: PDH ports should not be used as synchronisation sources if
PPI-AIS consequent actions or port monitoring is disabled for the port.
The synchronisation source hierarchy

The basis for synchronisation source protection is the synchronisation source
hierarchy. This is formed from four sources identified by the user. The first
source has the highest priority for the user, with the fourth having the lowest.
A standby signal is also available, which is always the TN-1X’s internal
oscillator. Only sources listed within this hierarchy will be considered for use.
A typical synchronisation hierarchy is shown in Table 4-50 below.

Table 4-50
A typical synchronisation protection hierarchy
Level Priority Synchronisation Source Port
1 HIGHEST STM-1 Aggregate ‘A’. S6-1
2 ... STM-1 Aggregate ‘B’. S7-1
3 ... 2 Mbit/s channel. S2-1
4 ... External oscillator. EXT
Standby LOWEST Internal oscillator. INT

A synchronisation source is used until the source fails, or a decision to change

sources is taken (see “Synchronisation switching mechanisms” on page 4-53
for details).
A source is regarded as failed once it has been unavailable for a defined period,
called the “failure holdoff time”. A source is regarded as stable once it has been
available for a defined period, called the “wait to restore time”. The durations
of these periods are user definable.
Note 1: The first level of the hierarchy can be set to ‘NONE’ by the user.
In this instance, only the TN-1X internal oscillator is used as a source of
synchronisation.
Note 2: In a ring of NEs using STM-4 aggregates, synchronisation should
be taken from a single external source. Problems may be experienced on
NEs which use the internal synchronisation source.
Note 3: Either channel of an MSP protection pair can be used for
synchronisation purposes. These mechanisms operate independently.
Synchronisation software settings

The use of the synchronisation source hierarchy is controlled by four software
settings. These are described below:
• Reversion on. When a source fails, or a decision to change sources is made,
both higher and lower priority sources can be selected for use.
• Reversion off. When a source fails, or a decision to change sources is
made, only sources of a lower priority can be selected for use. While this
mode is selected, all unavailable sources are marked with a non-reversion
flag. These flags prevent sources from being reselected at a later stage, and
must be cleared manually by the user.
Note 1: Reversion settings are not used when a source is in forced use.
Note 2: Non-reversion flags on a failed sync source cannot be cleared
before a period of time equal to the wait-to-restore time has passed.
• Force on. Using this setting, one of the sources in the hierarchy, including
one that is currently invalid, is selected for use. The TN-1X is not able to
change to a different source while in this mode.
If a source becomes invalid while in this mode, or if an
invalid source is selected for use, the TN-1X begins a
‘holdover period’. During this period, the mux reproduces the
absent synchronisation signal internally. This situation is
resolved in either of the following ways:
— If the source becomes stable again during this time, the source is used
as if it had not been interrupted.
— If the force setting is changed to off, a switch in synchronisation
sources will occur.
Note: When a source is in forced use, reversion settings are ignored.

• Force off. Using this setting cancels any existing forced source usage, and
source selection comes under the control of reversion settings (see above).
Existing non-reversion flags are unaffected when this mode is selected.
Note: The circumstances under which a switch in synchronisation occurs
depends on the implementation mechanism used. These are detailed in
“Synchronisation switching mechanisms” on page 4-53.
Synchronisation switching mechanisms

The circumstances under which a switch in synchronisation occurs depends on
the implementation mechanism used. There are two mechanisms:
• A Synchronisation Status Messaging (SSM) mechanism. This uses
transmitted quality levels to determine the best source. See
“Synchronisation Status Messaging (SSM)” on page 4-53.
• A non-SSM system. This is similar to the synchronisation mechanism used "
by the TN-1X before Release 7. See “Non-SSM synchronisation sourcing”
on page 4-55.
Note: Both of these mechanisms make use of the software settings
described in “Synchronisation software settings” on page 4-52.
Synchronisation Status Messaging (SSM)

Synchronisation Status Messaging (SSM) is based on the transmission of
synchronisation quality messages between potential synchronisation sources.
Note: A full description of SSM can be found in the Nortel TN-1X System
Description handbook (see “Related documents” on page xv).
Using this system, the TN-1X is able to evaluate which synchronisation source
is the best for use. This evaluation is used under two circumstances:
• The best source will always be selected for use, subject to software settings
restrictions (see “Synchronisation software settings” on page 4-52). That
is, if a better quality source is identified (and no source is in forced use),
the current reversion settings will dictate whether this source can be
selected for use.
• In the event of a source failure, the best of the remaining sources will be
selected for use, subject to software settings restrictions (see
“Synchronisation software settings” on page 4-52). If no source is
available, the standby source is selected.
Note: The SSM mechanism can only select sources that are listed in the
synchronisation source hierarchy.
The Quality Level (QL) of a source is transmitted in the section overhead of

all STM-N signals as the S1 byte. QL has a possible range of 1 to 15, with 1
as the highest priority. In practice, a subset of these values is used by the mux.
This subset of QL values is defined in Table 4-51.
The TN-1X transmits its QL on all STM-N ports, except for the STM-N port
from which it receives its synchronisation source. The QL transmitted on this
port is 15, which indicates to the source of the synchronisation that the

TN-1X should not be used for synchronisation. This action prevents closed
synchronisation loops, where two muxes each attempt to synchronise from
the synchronisation signal of the other.
By default, each mux uses its internal clock, which has a QL of 11.
Table 4-51
SSM quality levels
QL Meaning Description
0 Synchronisation quality unknown. Included for backwards compatibility reasons. Will

always be interpreted by mux as QL = 15.
2 Traceable to Primary Reference The external timing source for the network.
Clock (PRC).
4 Traceable to Transit Clock. A clock provided for equipment which does not connect
with customer equipment. That is, it only connects to
other nodes.
8 Traceable to Local Clock. A clock provided for equipment which connects directly
with customer equipment.
11 Traceable to SDH Equipment The internal oscillator of the multiplexer.

Clock (SEC).
15 Do not use for synchronisation. This prevents the mux’s sync source from being used by
muxes that receive this value.
An example network is shown in Figure 4-10, below.

Figure 4-10
SSM within an STM-N ring
PRC (An EXTernal source)
QL = 2
2 2
TN-1X
QL = 2
15 2
TN-1X TN-1X
QL = 2
STM-N RING QL = 2
2 15
TN-1X
QL = 2
15 2

In the example in Figure 4-10, synchronisation is derived from the Primary

Reference Clock (PRC), an EXT source. Each mux is set to derive its
synchronisation from the counterclockwise mux, from which it sets its own
QL = 2. This value is transmitted on all STM-N ports for the mux, with the
exception of the return port of the sync source, on which QL = 15 (“do not use
for synchronisation”) is transmitted. This prevents closed synchronisation
loops.
Note: Before the PRC signal was introduced, all four TN-1Xs would have
used the default QL setting of 11, which indicates the use of an internal
oscillator (INT).
The user can configure the QL settings for both RX and TX purposes. These
"
manual settings override any QL values established by the TN-1X software.
Note 1: Older Nortel SDH hardware is unable to receive or transmit QL

values. The QL for these aggregates will default to 15 (“do not use for
sync”).
Note 2: A failure holdoff time of one second must be set if the
25U PJ00 750 GXF Payload Manager is used when SSM is enabled.
A more detailed description for the SSM mechanism can be found within the
TN-1X System Description NTP, 323-1061-100.
Non-SSM synchronisation sourcing

When the SSM system is not in use, changes to the selected synchronisation
source only occur when a source fails, or if a manual change is performed.
Changes due to source failure are subject to software settings restrictions (see
“Synchronisation software settings” on page 4-52).
Note: A source is regarded as failed once it has been unavailable for a

defined period, called the “failure holdoff time”. A source is regarded as
stable once it has been available for a defined period, called the “wait to
restore time”. The durations for these periods are user definable.
This mechanism is very similar to the synchronisation mechanism used by the

TN-1X before Release 7. The following software settings can be used to
operate the TN-1X in a similar way to that used before TN-1X Release 7.
• Reversion on, force off, SSM off. This is equivalent to the “reversion”
mode under TN-1X Release 6. That is, when a source fails, both higher and
lower priority sources in the hierarchy can be selected for use
automatically. A configurable reversion time is not supported.
• Reversion off, force off, SSM off. This is equivalent to the “fallback” mode
under TN-1X Release 6, and the standard operation of Release 5. That is,
when a source fails, only lower priority sources in the hierarchy can be
selected for use automatically.
• Force on, SSM off. This is equivalent to “manual” mode under TN-1X R6.
Reversion settings are ignored when this mode is in use. If this source fails,
the standby source (the internal oscillator) is used.

Command details
The commands that access the synchronisation functionality of the TN-1X
are shown in Figure 4-11, and are detailed in the tables that follow.
Figure 4-11
Config/Sync_source command hierarchy
Config
Sync_source
Hierarchy
Reversion_on
reversion_oFf
force_oN
forCe_off
Rx_Override
Tx_Override
Ssm_oN
Ssm_Off
clear_No_Revert_flag
failure_Holdoff_Time
Wait_to_restore_time
View
STatus_view

Table 4-52
Config/Sync_source
Hierarchy CSH ‘INT’ | ‘NONE’ Yes Specifies the synchronisation

source hierarchy.
sync_source
[sync_source]
[sync_source]
[sync_source]
Reversion_on CSR N/A Enables the automatic reversion

mechanism. This setting is
ignored if Force_on is in use.
reversion_oFf CSF N/A Disables the automatic reversion

(default) mechanism. This setting is
ignored if Force_on is in use. "
force_oN CSN sync_source | Selects the specified source for
‘INT’ use. Reversion settings are
ignored.
forCe_off CSC N/A Disables a manually selected

sync source. Reversion settings
are used as a result.
Rx_Override C S RO SDH_port | Defines a QL value for the

‘PDH’ | ‘EXT’ specified port, or all PDH ports, or
quality_level the external source.
SDH_port Disables any RX override value,

‘SSM’ and uses the actual RX QL value.
Tx_Override C S TO SDH_port Defines TX override QL value for

quality_level the specified port, or all PDH
ports, or the external source.
SDH_port Disables any TX override value,

‘SSM’ and uses the actual TX QL value.
Ssm_oN C S SN N/A Enables the SSM mechanism.
Ssm_Off C S SO N/A Disables the SSM mechanism.

(default)
clear_No_ C S NR sync_source Removes ‘no_revert’ flag from a

Revert_flag failed source. This command
cannot be used during the defined
wait-for-restore period for a failed
source.
failure_Holdoff_ CSHT failure_time Sets the failure holdoff time

Time (see note)
Wait_to_ CSW restore_time Sets the wait-to-restore time.

restore_time
View CSV N/A No Displays information regarding

the synchronisation source
hierarchy.
STatus_view C S ST N/A No Reports the synchronisation

source status.
Note: A failure holdoff time of one second must be set if the 25UPJ00750GXF Payload Manager is
used and SSM is enabled.

Parameters
• The <sync_source> parameter identifies a physical port that is a source of
synchronisation, including internal and external sources. This can be one
of the following:
— An SDH port. This is the physical port on either an STM-N aggregate
unit, or an STM-1 tributary unit. The format is:
S<slot>-<port>
SDH ports are detailed in “SDH ports” on page 2-8. The <port>
elements of this syntax MUST be specified (the default value
of ‘1’ is
not assumed in this instance).
— A PDH port. This port is on a 2M, 34M (16 x 2) or 34/45M (VC3)

tributary unit. The format is:
S<slot>-<port>
— An attached external oscillator. Only one of these can be attached to

each TN-1X. This is denoted as ‘EXT’.
• The <quality_level> parameter is a quality level (QL) between 1 and 15.
• The ‘SSM’ entry disables the RX or TX override, and enables the TN-1X
to use the actual QL value. This can only be used for SDH ports that have
the hardware capability to support SSM.
• The <failure_time> parameter defines the failure holdoff time for the mux.
This is expressed in seconds, and can be set between 0 and 60. The default
is 5 seconds.
• The <restore_time> parameter defines the wait-to-restore time for the
mux. This is expressed in seconds. For SDH optical ports, this can be set
between 2 and 600. For all other ports, this can be set between 0 and 600.
The default is 30 seconds for both SDH and PDH equipment.
Autonomous events
• If the current synchronisation source changes:
982, Ref_ss = <sync_source|‘EXT’|‘INT’>,
Old_SS = <sync_source|‘EXT’|‘INT’>
• If the internal QL value changes:

983, SS_QL = <quality_level>, SS_Old_QL =
<quality_level>, <date>, <time>

Reports
The reports are of the format shown below:
Config/Sync_source/View
This view command uses the following entries:
19,Sync Source Hierarchy Configuration
191, <sync_port|‘INT’|‘EXT’>, SSh_lvl =
<1|2|3|4>, SS_tx_override = <quality_level|‘SSM’>,
SS_rx_override = <quality_level|‘SSM’>,
SS_wtr_time = <restore_time>
192, Sync_src_reversion_mode = <‘Revertive’|
’Non-revertive’>
194, Sync_src_force = <‘Off’|sync_port>
195, SSM_Mode = <‘On’|‘Off’>
"
196, Sync_src_hierarchy = <‘INT’|’EXT’|SDH_port|PDH_port>
[’EXT’|SDH_port|PDH_port] [’EXT’|SDH_port|PDH_port]
[’EXT’|SDH_port|PDH_port]
197, SS_failure_holdoff_time = <failure_time>
For example:
19,Sync Source Configuration
191,PDH,SS_rx_override=11
191,INT,SS_hierarchy_level=1,SS_rx_override=11
191,EXT,SS_rx_override=11
191,S6-1,SS_tx_override=11,SS_rx_override=11,
SS_wait_to_restore_time=2
191,S7-1,SS_tx_override=11,SS_rx_override=11,
191,S11-1,SS_tx_override=11,SS_rx_override=11
192,Sync_src_reversion_mode=Revertive
194,Sync_src_force=Off
195,SSM_mode=Off
196,Sync_src_hierarchy=S6-1 S7-1
197,SS_failure_holdoff_time=5
;
Config/Sync_source/STatus_view
This report duplicates a status report on the Status View menu, and is detailed
in “View_status/Sync_Source_status” on page 7-11.

Config/Cons_act <C C>

This command enables the user to configure the consequent actions
Consequent actions
When alarms are raised on the TN-1X, it is often necessary for other actions
to be performed. Many of these consequent actions involve other alarms being
sent up or downstream to other multiplexers, while others result in hardware
or software switches being performed. These actions can be direct or indirect,
depending on the nature of the original alarm.
Consequent actions are only enabled if all of the following conditions are met:
• The feature to which the instance relates is enabled, either in its function
menu or in the alarm monitoring menu.
• Alarm monitoring is enabled on an individual basis.
• Consequent actions are enabled on an NE basis. For PPI-AIS, consequent
actions must be enabled both on an NE basis and on an individual basis.
Where consequent actions are enabled for an instance, this means that:
• AIS insertion is enabled (except for DEG alarms).
• PPS is enabled (unless it is disabled for an instance).
• RDI insertion is enabled (except for DEG alarms).
Full details of consequent actions can be found in the TN-1X Alarm Clearing
Procedures handbook (see “Related documents” on page xv).
Configuring consequent actions

Consequent actions for the following alarms can be enabled and disabled by
the user:
• Low-order Path Excessive Bit Error Rate error (LP-EXC). This alarm
invokes directly the following consequent actions:
— LP-RDI is sent upstream.
— PPI-AIS is injected downstream.
Note: Alarms for unconnected ports or channels are disabled by default.
These alarms should not be enabled when no traffic is connected.
• Low-order Path Signal Label (LP-PLM). This alarm invokes the following
consequent actions:
— On protected connections, with PPS enabled, there will be a path
protection switch for each affected TU-12.

• Low-order Path Trace (LP-TIM). This alarm invokes the following

consequent actions:
• Multiplex section signal degradation (MS-DEG). This alarm invokes the
following consequent actions:
— MS-RDI is sent upstream.
— AU-AIS is injected downstream.
— MSP Protection switch (if enabled).
This alarm also invokes indirectly the following consequent
actions:
— On protected connections, with PPS enabled, there will be a path

"
protection switch on all drop traffic currently using the affected
aggregate.
• High-order Path Trace (HP-TIM). This alarm invokes directly the
— HP-RDI is sent upstream.
— TU-AIS is injected downstream.
actions:

Note: The PPI-AIS and LP-RDI consequent actions for this alarm are
disabled by default.
• High-order Signal Label (HP-PLM). This alarm invokes directly the

— HP-RDI is sent upstream.
— TU-AIS is injected downstream.
actions:

— On protected connections, with PPS enabled, there will a path
protection switch for up to 63 TU-12s.
Note: The PPI-AIS and LP-RDI consequent actions for this alarm are
disabled by default.

• PDH Physical Interface Alarm Indication Signal (PPI-AIS). This alarm

invokes the following consequent actions:
— AIS is injected towards the payload manager.
Note: Consequent actions for PPI-AIS must be enabled both on an
individual port basis and an NE basis.
Command details
The commands that access the consequent action functionality of the TN-1X
are shown in Figure 4-12, and are detailed in the tables that follow.
Figure 4-12
Config/Cons_act command hierarchy
Config
Cons_act
ne_Hp_Tim
oN
Off
ne_Hp_Plm
oN
Off
ne_Ms_Deg
oN
Off
ne_Lp_Plm
oN
Off
ne_Lp_Exc
oN
Off
ne_Lp_Tim
oN
Off
ne_Ppi_Ais
oN
Off
individUal
Ppi-Ais
oN
Off
View
View

Table 4-53
Config/Cons_act
ne_Hp_Tim C C HT See Table 4-54.
ne_Hp_Plm C C HP See Table 4-55.
ne_Ms_Deg C C MD See Table 4-56
ne_Lp_Plm C C LP See Table 4-57.
ne_Lp_Exc C C LE See Table 4-58.
ne_Lp_Tim C C LT See Table 4-59.
ne_Ppi_Ais C C LT See Table 4-60.
individUal
View
CCU
CCV
See Table 4-61.
N/A No Displays the consequent actions

"
configuration.
Table 4-54
Config/Cons_act/ne_Hp_Tim
Menu Item Shortcut Parameters Confirm Description
oN C C HT N N/A Yes Enables HP-TIM (HP Path Trace)

consequent actions.
Off (default) C C HT O No Disables HP-TIM consequent actions.
Table 4-55
Config/Cons_act/ne_Hp_Plm
oN C C HP N N/A Yes Enables HP-PLM (HP Signal Label)

consequent actions.
Off (default) C C HP O No Disables HP-PLM consequent actions.
Table 4-56
Config/Cons_act/ne_Ms_Deg
Item Shortcut Parameters Confirm Description
On C C MD N N/A Yes Enables MS-DEG (MS Signal

Degradation) consequent actions.
Off (default) C C MD O No Disables MS-DEG (MS Signal

Degradation) consequent actions.
Table 4-57
Config/Cons_act/ne_Lp_Plm
oN C C LP N N/A Yes Enables LP-PLM (LP Signal Label)

consequent actions.
Off (default) C C LP O No Disables LP-PLM consequent actions.

Table 4-58
Config/Cons_act/ne_Lp_Exc
oN C C LE N N/A Yes Enables LP-EXC (LP Excessive BER)

consequent actions.
Off (default) C C LE O No Disables LP-EXC consequent actions.
Table 4-59
Config/Cons_act/ne_Lp_Tim
oN C C LT N N/A Yes Enables LP-TIM (LP Path Trace)

consequent actions.
Off (default) C C LT O No Disables LP-TIM consequent actions.
Table 4-60
Config/Cons_act/ne_Ppi_Ais
oN C C LT N N/A Yes Enables PPI-AIS consequent actions.
Off (default) C C LT O No Disables PPI-AIS consequent actions.
Table 4-61
Config/Cons_act/individUal/Ppi_Ais
oN (default) C C U PA N [PDH_port] Yes Enables PPI-AIS consequent actions for

the specified PDH port.
(see note)
Off C C U PA O No Disables PPI-AIS consequent actions for
Parameters
• The <PDH_port> parameter identifies a 2M, 34M (16x2) or 34/45M
(VC-3) tributary port. PDH ports are detailed in “PDH ports” on page 2-4.
Autonomous events

Reports
Config/Cons_act/View
The entries used by this command are listed below.
20, Alarm Consequent Action Configuration
208, CA_<alarm> = <‘On’|‘Off’>
For example:
208, CA_HP_TIM = On
208, CA_HP_PLM = Off
208, CA_LP_EXC = Off
208, CA_LP_PLM = On
208, CA_MS_DEG = On
208, CA_LP_TIM = Off "
208, CA_PPI_AIS = On
;
Config/Cons_act/individUal/Ppi_Ais/View
209, <PDH_port>, CA_<alarm> = <‘On’|‘Off’>
For example:
209, S2-1, CA_PPI_AIS = On
209, S4-1, CA_PPI_AIS = Off
;

Config/Lp_path_Trace <C LT>

This command enables the user to access the low order path trace
Low order path tracing

The low order path trace functionality of the TN-1X enables the user to
monitor the paths that carry VC-3 signals. This is achieved using sixteen byte
strings that are transmitted and received for each VC-3 payload.
Transmitted strings and expected values for received strings are defined on
each mux by the user. The user specifies only fifteen characters. This string is
appended to a one byte frame marker, which includes a Cyclic Redundancy
Checking (CRC) checksum. The resulting sixteen byte transmission string is
transmitted cyclically in the J1 byte of the VC-3 path overhead.
Note: If less than fifteen characters are specified by the user, this is padded
with underscore characters.
A comparison is made between each received string and its expected value.
CRC differences highlight transmission problems, while string differences
indicate an incorrect connection. In both instances, an LP-TIM alarm is
raised.
The user can enable and disable the low order path trace monitoring
mechanism. It is also possible to override the CRC with a hexadecimal value.
Note 1: If monitoring of path trace strings is disabled, the comparison

between received and expected strings is not performed. The transmission
and reception of path trace strings is unaffected.
Note 2: Path trace parameters associated with a connection are defaulted if
the connection is deleted.
J2 path trace byte

The J2 path trace byte is defined by ITU-T standard G.707 as part of the
VC-12 signal path overhead (POH). Sixteen J2 bytes taken together from
successive transmissions constitute one frame and this is used as a way of
attaching a low order path access point identifier to a VC-12 path.
The CLUI can be used to modify a user-defined ASCII text string that is
transmitted over the J2 byte for any given connection and also define the
string that should be received. The user may only enter a fifteen-character
string, the sixteenth byte being reserved as a checksum (however the user may
also manually edit this if so desired).
This transmitted string is extracted at the remote mux and compared to the
user-defined expected value. If the transmitted and expected strings do not
match then the connection is incorrect, while a CRC check highlights
transmission problems. Monitoring is supported at the Preside.

A low order path trail information mismatch (LP-TIM) alarm is raised at the
local mux if there is a mismatch in the expected and received strings.
Command details
The commands that access the low order path trace functionality of the
TN-1X are shown in Figure 4-13, and are detailed in Table 4-62.
Figure 4-13
Config/Lp_path_Trace command hierarchy
Config
Lp_path_Trace
"
Disable
Enable
Tx_set
eX_set
View
STatus_view
Table 4-62
Config/Lp_path_Trace
Disable C LT D PDH_port Yes Disables path tracing for specified

(see note 1) 34/45M PDH port. The received
pattern is ignored.
Enable C LT E Enables path tracing for specified

(default) 34/45M PDH port. Sends a low order
path trace string in the J1 byte (or J2
byte on 2 M connections).
Tx_set C LT T PDH_port No Sets the path trace transmission

LP_path_label string for the specified 34/45M PDH
[CRC] card. The CRC can be set,
overwriting any software calculations.
eX_set C LT X Sets the path trace expected string

for the specified 34/45M PDH port.
The CRC can be set, overwriting any
software calculations.
View C LT V PDH_port | ‘all’ No Displays a report showing the path

(see note 2) trace status, and the transmit and
expected path trace strings for all
low-order paths.
STatus_view C LT ST N/A No Displays status information relating to

low order path status settings.
Note 1: This command disables consequent actions for the disabled instance.
Note 2: If no parameter is specified, information for all low order paths is displayed.

Parameters
• The <PDH_port > parameter identifies a 34/45M PDH tributary port. PDH
ports are detailed in “PDH ports” on page 2-4.
• The <LP_path_label> parameter is a string of up to 15 characters. This
must use only printable characters, excluding comma, equals, colon,
semicolon and space. Default values for transmission and expected strings
are ‘TX_UNALLOCATED_’ and ‘RX_UNALLOCATED_’ respectively.
Autonomous events
Reports
The reports generated by the above commands are listed below:
Config/Lp_path_Trace/View
21, Path Trace Configuration
211, <PDH_port>, Path_trace_working_mode =
<‘Enabled’|‘Disabled’>
212, <PDH_port>, Path_trace_tx = <LP_path_label>,
Path_trace_ex = <LP_path_label>
213, <PDH_port>, Path_trace_tx_crc = <CRC>,
Path_trace_ex_crc = <CRC>
Where:
following syntax:
S<slot>-<port>
For example:
211, S2-1, Path_trace_working_mode = Enabled
212, S2-1, Path_trace_tx = TX_UNALLOCATED_,
Path_trace_ex = RX_UNALLOCATED_,
213, S2-1, Path_trace_tx_crc = 64H,
Path_trace_ex_crc = 3AH
;

Config/Lp_path_Trace/STatus_view
The entries used by this command are listed below:
58, Received Path Trace Status
581, <PDH_port>, Rx_state = <‘PT_OK’|‘Mismatch’|
‘Misaligned’>, Path_trace_rx = <trace_string>,
Rx_crc = <trace_CRC>
581, <PDH_port> Undetermined
Where:
• <PDH_port> is the PDH destination of a VC-3 drop connection.
• <trace_string> is the received path trace string.
• <trace_CRC> is the received cyclic redundancy check.
For example: "

581, S4-1, Rx_state = PT_OK, Path_trace_rx = From_C1,
Rx_crc = 64H
581, S11-1, Rx_state = PT_OK, Path_trace_rx = To_C1,
Rx_crc = 64H
;

Config/Hp_path_trace <C H>

This command enables the user to access the high order path trace
High order path tracing

The high order path trace functionality of the TN-1X enables the user to
monitor the paths between adjacent muxes. This is achieved using sixteen
byte strings that are transmitted and received for each VC-4 payload.
Transmitted strings and expected values for received strings are defined on
each mux by the user. The user specifies only fifteen characters. This string is
appended to a one byte frame marker, which includes a Cyclic Redundancy
Checking (CRC) checksum. The resulting sixteen byte transmission string is
transmitted cyclically in the J1 byte of the VC-4 path overhead.
Note: If less than fifteen characters are specified by the user, this is padded
with underscore characters.
A comparison is made between each received string and its expected value.
CRC differences highlight transmission problems, while string differences
indicate an incorrect connection. In both instances, an HP-TIM alarm is
raised.
The user can enable and disable the high order path trace monitoring
mechanism. It is also possible to override the CRC with a hexadecimal value.
Note 1: If monitoring of path trace strings is disabled, the comparison

between received and expected strings is not performed. The transmission
and reception of path trace strings is unaffected, however.
Note 2: Path trace parameters associated with a connection are defaulted if
the connection is deleted.
Note 3: High order path trace settings for MSP protection pairs can only
be made against the working section. Configuration of the protection
section is not supported. This will automatically mirror the settings of the
working section.

Command details
The commands that access the high order path trace functionality of the
Figure 4-14
Config/Hp_path_trace command hierarchy
Config
Hp_path_trace
Disable
Enable
Tx_set
eX_set
"
View
STatus_view
Table 4-63
Config/Hp_path_trace
Disable CHD SDH_port Yes Disables path tracing for specified

(see note 1) instance. Sends a constant zero
pattern in the HO path trace string in
the J1 byte. The received pattern is
ignored.
Enable CHE Enables path tracing for specified

(default) instance. Sends an HO path trace
string in the J1 byte.
Tx_set CHT SDH_port No Sets the path trace transmission

HP_path_label string for the specified instance. The
[CRC] CRC can be set, overwriting any
software calculations.
eX_set CHX Sets the path trace expected string

for the specified instance. The CRC
can be set, overwriting any software
calculations.
View CHV SDH_slot No Displays a report showing the path

(see note 2) trace status, and the transmit and
expected path trace strings for all
high-order paths.
STatus_view C H ST N/A No Displays status information relating to

HP path status settings.
Note 2: If this parameter is not specified, information for all high-order paths is displayed.

Parameters
S<slot>-<port>
S<slot>
• The <HP_path_label> parameter is a string of up to 15 characters. This

must use only printable characters, excluding comma, equals, colon,
semicolon and space. Default values for transmission and expected strings
are ‘TX_UNALLOCATED_’ and ‘RX_UNALLOCATED_’ respectively.
• The <CRC> parameter is a hexadecimal value between 00 and 7F.
Autonomous events
Reports
Config/Hp_path_trace/View
211, <SDH_AU4>, Path_trace_working_mode =
212, <SDH_AU4>, Path_trace_tx = <HP_path_label>,
Path_trace_ex = <HP_path_label>
213, <SDH_AU4>, Path_trace_tx_crc = <CRC>,
Path_trace_ex_crc = <CRC>
Where:


For example:
211, S2-1-J1, Path_trace_working_mode = Enabled
212, S2-1-J1, Path_trace_tx = TX_UNALLOCATED_,
213, S2-1-J1, Path_trace_tx_crc = 64H,
Path_trace_ex_crc = 3AH "
;
Config/Hp_path_trace/STatus_view
This report duplicates a status report on the Status View menu, as described in
“View_status/hp_Path_Trace_status” on page 7-12).

Config/Lp_paYload_label <C LY>

This command enables the user to access the low order payload label
Low order payload labels

The low order payload label functionality of the TN-1X enables the user to
monitor the composition of VC-12 and VC-3 payloads between adjacent NEs.
Each low order payload has a label defined for it. A comparison is made
between each received label and its expected value. Any difference indicates
transmission of connection problems, and raises an LP-PLM alarm.
The user can enable and disable the low order payload label monitoring
mechanism.
Note 1: If monitoring of payload labels is disabled, the comparison
between received and expected labels is not performed. The transmission
and reception of payload labels is unaffected.
Note 2: Payload label parameters associated with a connection are
defaulted if the connection is deleted.
VC-12 payload labels

Each VC-12 payload is represented by a number between 0 and 7. A non-zero
value represents an equipped VC-12 path.
Note: Under previous releases of the TN-1X, a zero value could be used to
represent standby connections. This functionality is now fully supported
(see “Raising signal alarms” on page 4-113).
Table 4-64
Low order VC-12 payload labels
Label Meaning
0 The VC-12 path is unequipped.
1 The VC-12 path is equipped with a nonspecific payload.
2 The VC-12 path is equipped with asynchronous mapping. This is the default for
current equipment.
3 The VC-12 path is equipped with bit synchronous mapping.
4 The VC-12 path is equipped with byte synchronous mapping.
5-7 These are reserved for future VC-12 mappings.
Transmitted VC-12 labels and expected label values are defined on each NE
by the user. The resulting three-bit label is transmitted within bits 5 to 7 of the
V5 byte in the VC-12 path overhead.

VC-3 payload labels

Each VC-3 payload is represented by a number between 0 and 255. A
non-zero value represents an equipped VC-3 path.
Table 4-65
Low order VC-3 payload labels
Label Meaning
4 The C3 container is asynchronously mapped.
5-255 These are reserved for future VC-3 mappings. "

Transmitted labels and expected label values are defined on each mux by the
user. The resulting one-byte label is transmitted as the C2 byte in the VC-3
path overhead.
Command details
The commands that access the low order payload label functionality of the
Figure 4-15
Config/Lp_paYload_label command hierarchy
Config
Lp_paYload_label
Disable
Enable
Tx_set
eX_set
View
STatus_view

Table 4-66
Config/Lp_paYload_label
Disable C LY D PDH_port No Disables payload label monitoring

(see note) for specified PDH port. The
received label is ignored.
Enable C LY E Enables payload label monitoring

(default) for specified PDH port.
Tx_set C LY T PDH_port Sets the transmission payload label

LP_payload_label for the specified PDH port.
eX_set C LY X Sets the expected payload label for

View C LY V N/A No Displays a report showing the

values of the TX and expected path
labels for all LP connections.
STatus_view C LY ST N/A No Displays status information relating

to LP payload labels.
Note: This command disables consequent actions for the disabled instance.
Parameters
following syntax:
S<slot>-<port>
• The <LP_payload_label> parameter is a number between 0 and 7 for

VC-12 ports, or 0 and 255 for VC-3 ports.
Autonomous events
Reports
Config/Lp_paYload_label/View
215, Payload Label Configuration
216, <PDH_port>, Payload_label_working_mode =
217, <PDH_port>, Payload_label_tx = <LP_payload_label>,
Payload_label_ex = <LP_payload_label>

For example:
216, S2-1, Payload_label_working_mode = Enabled
217, S2-1, Payload_label_tx = 2, Payload_label_ex = 2
216, S2-2, Payload_label_working_mode = Enabled
217, S2-2, Payload_label_tx = 2, Payload_label_ex = 2
;
Config/Lp_paYload_label/STatus_view
The report for this command uses the following entries:
56, VC Path status
561, <PDH_port>, Path_src = <SDH_aggr_payload>,
Rx_payload_label = <LP_payload_label>
Where: "
• The <SDH_aggr_payload> parameter identifies an SDH aggregate
payload. The format for this is:

page 2-6.
For example:
56, VC Path status
561, S2-1, Path_src = S6-1-J2-K121, Rx_payload_label = 7
;

Config/Hp_paYload_label <C HY>

This command enables the user to access the high order payload label
High order payload labels

The high order payload label functionality of the TN-1X enables the user to
monitor the composition of VC-4 payloads between adjacent muxes.
Different payloads are represented by a number between 0 and 255. A
non-zero value represents an equipped VC-4 path.
Table 4-67
High order payload labels
Label Meaning
2 The VC-4 path is equipped with a TUG structure.
Transmitted labels and expected label values are defined on each mux by the
user. The resulting one-byte label is transmitted as the C2 byte in the VC-4
path overhead.
A comparison is made between each received label and its expected value.
Any difference will indicate transmission or connection problems, and will
raise an HP-PLM alarm.
The user can enable and disable the high-order payload label monitoring
mechanism. This does not prevent payload labels from being transmitted or
received, but prevents the comparison of received and expected labels.
Note: High order payload label settings for MSP protection pairs can only
be made against the working section. Configuration of the protection
section is not supported. This will automatically mirror the settings of the
working section.

Command details
The commands that access the high order payload label functionality of the
Figure 4-16
Config/Hp_paYload_label command hierarchy
Config
Hp_paYload_label
Disable
Enable
Tx_set
eX_set
View
STatus_view "
Table 4-68
Config/Hp_paYload_label
Disable C HY D SDH_port No Disables payload label monitoring

(see note 1) for specified high-order path. The
received label is ignored.
Enable C HY E Enables payload label monitoring

(default) for specified high-order path. Sends
the defined label as the C2 byte in
the VC-4 path overhead.
Tx_set C HY T SDH_port No Sets the transmission payload label

HP_payload_label for the specified high-order path.
eX_set C HY X Sets the expected payload label for

the specified high-order path.
View C HY V SDH_slot No Displays a report showing the

(see note 2) values of the TX and expected path
labels for all HP connections.
STatus_view C HY ST N/A No Displays status information relating

to HP payload labels.
Note 2: If this parameter is not specified, information for all high-order paths is displayed.

Parameters
S<slot>-<port>
S<slot>
• The <HP_payload_label> parameter is a number between 0 and 255.

Default setting is ‘2’ for all equipped ports.
Autonomous events
Reports
Config/Hp_paYload_label/View
216, <SDH_AU4>, Payload_label_working_mode =
217, <SDH_AU4>, Payload_label_tx = <HP_payload_label>,
Payload_label_ex = <HP_payload_label>
Where:

For example:
216, S4-1-J1, Payload_label_working_mode = Enabled
217, S4-1-J1, Payload_label_tx = 2, Payload_label_ex = 2
;

Config/Hp_paYload_label/STatus_view
56, VC Path status
561, <SDH_AU4>,, Rx_payload_label = <label>
For example:
56, VC Path status
561, S6-1-J1,, Rx_payload_label = 255
;
Note: The above report is different from the report generated by the
“VC_path_status” command in the view status menu (see “View_status/
VC_path_status” on page 7-12).
"

Config/coNnections <C N>

This command accesses the connection functionality of the TN-1X.
Connection management
The connection functionality of the TN-1X relates to the management of
bidirectional VC-12 and VC-3 connections on the mux.
The TN-1X supports the following aggregate units:
• STM-1. The single AU-4 payload is accessible.
• STM-4. Only one of the four AU-4 payloads is accessible.
Note: STM-4 Optical aggregate units are unavailable to order until further
notice.
The TN-1X supports the following tributaries units:

• STM-1. Each of these can carry up to three VC-3 payloads, or 63 VC-12
payloads, or a combination of these two payload types.
• 2 Mbit/s. Each of these can carry up to 16 VC-12 payloads.
• 34 Mbit/s (16 x 2M). Each 2M channel can carry a single VC-12 payload.
• 34/45 Mbit/s (VC-3). Each 34/45M channel can carry a single VC-3
payload.
The total traffic capacity for the multiplexer is an AU-4 payload. The
containers within this payload (VC-3, VC-12) can be dropped from the
aggregates to any suitable tributary unit, or can be through connected.
Note: The number of available tributary ports can exceed the number of
aggregate ports, but the total bandwidth for the mux (63 x VC-12, 3 x VC-3
or a combination of these) cannot be exceeded.
Dropped AU-4 selection

The TN-1X supports the use of both STM-1 and STM-4 aggregates. The
STM-1 signal structure contains a single AU-4, while the STM-4 contains
four. The TN-1X is able to access just one AU-4, so where an STM-4
aggregate is used, the AU-4 to be dropped is selected by the user.
Connection types
Connections can be divided into a number of categories:
• Through connections. Each of these connects a payload on one aggregate
to the same payload on the other aggregate. For example, a through
connection can be made between the S6-J1-K111 and S7-J1-K111
aggregate payloads.
• Protected drop connection connects a VC-12 or VC-3 tributary signal to
the same payload channel on both aggregates. In the transmit direction, the
tributary signal is transmitted on both aggregates. In the receive direction,
the signal is received from both aggregates but only one of the signals is
dropped to the tributary. If a connection fails, the connection is switched to

the same ports on the alternative aggregate. For example, a protected

connection can be made using the S6-J1-K222 aggregate payload and the
S4-1 port, with S7-J1-K222 as the alternate aggregate payload.
• Unprotected drop connections. Each of these connects VC-12 or VC-3
traffic from a tributary to a single aggregate payload of the same type. If a
connection fails, an alternative routing via the other aggregate is NOT
available. For example, an unprotected connection can be made between
the S6-J1-K333 aggregate payload and the S2-1 port.
All possible connection types are shown in Figure 4-17.
Figure 4-17
TN-1X connection types
"
TN-1X
STM-1 STM-1
AGGR AGGR
34/45M TRIB
INTERNAL
STM-1 TRIB
2M TRIBS
BUS
...
VC-12 VC-3 STM-1

VC-12 PROTECT VC-3 PROTECT
Note 1: It is not possible to concurrently connect all the connections shown

in Figure 4-17, as the STM-1 bandwidth would be exceeded.
Note 2: All drop connections use the TN-1X’s internal bus (see
“Defragmenting the TN-1X internal bus” on page 4-84).

Note 3: VC-3 connections can only be successfully implemented on

hardware that supports VC-3 traffic.
Note 4: Trib-to-Trib connections are not supported at Release 9.
Defragmenting the TN-1X internal bus

Connections between aggregates and tributaries use the internal bus of the
TN-1X. The use of this bus is transparent to the user in most cases. The bus
has sixty three timeslots, each one of which is of an equivalent size to a
VC-12 container. That is, the bus bandwidth is equivalent to the single AU-4
payload required for an STM-1 signal.
When a new connection is added, a suitable number of consecutive slots in

the bus are allocated to the connection. For a VC-12 connection, one slot is
required. For a VC-3 connection, 21 consecutive slots are required.
As connections are made and unmade, the loading of the bus may become
fragmented. The user is able to defragment the bus. This maximises the
number of consecutive slots, enabling the addition of larger (VC-3) payloads.
Also, this action minimises the traffic hits that can occur when future VC-12
or VC-3 connections are made.
The physical connections for aggregate and tributary payloads are unchanged
by defragmentation, but the defragmentation of the internal bus will (in most
cases) result in temporary traffic hits while the internal bus is rearranged. You
will be made aware of traffic hits that will occur during the defragmentation.
Defragmentation of the internal bus can be performed in one of two ways:
• VC-3
A VC3 Defrag will rearrange the connections on a mux in order to
facilitate the addition of one or more VC3 connections. (This rearranging
of the existing traffic will cause these paths to experience traffic Hits). A
VC3 test defrag gives a pessimistic list of the hit risk connections that will
be effected. A VC3 Defrag will not cause a traffic hit to a VC3 connection
that is already present.
If there is less than 21 VC12 connections present then a VC3 Defrag will
provision the mux to accept two VC3 connections. When adding these two
connections directly after the defrag there will be no traffic disruption to
existing traffic.
If there is less than 42 VC12 connections present then a VC3 Defrag will
provision the mux to accept one VC3 connection. When adding this
connection directly after the defrag there will be no traffic disruption to
existing traffic.
A VC3 defrag will typically hit every VC12 connection on the mux. Each
channel will be hit for up to 20 seconds. The more connections on the mux,
the longer the mux is affected. For a full fill mux the total period is as
follows:
— Release 7 is 60 seconds

Release 9 is 60 seconds.
A VC3 Defrag should only be implement after, a VC3 test connect reports
connections will be hit.
• VC-12
A VC12 Defrag will rearrange the connections on a mux in order to
facilitate the addition of more VC12 connections with a reduced hit risk.
This rearranging of the existing traffic will cause these paths to experience
a traffic outage. A VC12 test defrag gives a pessimistic list of the hit risk
connections that will be effected.
A VC12 Defrag needs to be used after an upgrade from Release 8 and after
removing a VC3 but before replacing that VC 3 with VC12 connections. It
can also be used if a Mux has had its connections churned to an extent that
adding any new VC12 connections results in a significant Hit Risk
warning.
"
A VC12 defrag will typically hit every connection on the mux. Each
channel will be hit for up to 20 seconds. The more connections on the mux,
the longer the mux is affected. For a full fill mux the total period is as
follows:
— Release 9 is 60 seconds.
Before a VC12 Defrag is implemented a VC12 Test Defrag should be
applied to check the connections that may get hit.
CAUTION
Alarms during defragmentation
During a defragmentation, there is a possibility of
PPI-Unexp_Signal and QOSV alarms and traffic hits. This is
unavoidable, as the defragmentation causes connections to be
broken momentarily and then remade.
General rules for adding new connections

Because of the way that the TN-1X Release 9 software allocates backplane
timeslots, there is a preferred order in which to utilise the 2 Mbit/s tributary
ports. The guidelines given below apply all TN-1Xs no matter whether the
multiplexer is:
a. a current Release 9 multiplexer (i.e. it was shipped from the factory
with Release 9 software inside)
b. an existing multiplexer that has been upgraded from Release 7.n or
Release 8.n software to Release 9.

Adding a VC3 Connection

When adding a VC3 connection to a Release 9 NE consider the number of
VC12s used on the NE and the number of VC3 connections required:
• If there are no VC12 connections on the NE then no action is required and
the VC3 can be added normally.
• If there are 43 or more VC12 connections then a VC3 cannot be added as
there are not the required 21 timeslots available on the back-plane. The
user must delete VC12 connections until only 42 or less remain.
• If adding a single VC3 connection and there are less than 21 VC12
connections present then do a test connect and note the circuits that may be
hit, then apply the connection. This will result in a hit risk to some or all
VC12's present.
• If adding a single VC3 and there are more than 21 VC12 connections
present then apply a VC3 Test Defrag noting the circuits that will be hit,
apply the VC3 Defrag then add the VC3 connection. The VC3 Defrag will
result in a hit risk to some or all VC12's present.
• If adding two VC3 connections to a Mux without VC12 connections
present then the VC3 connections can be added with out a traffic hit.
• If Adding Two VC3 connections to a Mux with VC12 connections present
then a VC3 Defrag should be applied. The VC3's can now be applied
without a further traffic hit.
• If adding a VC3 to a mux with a VC3 and VC12's present, a VC3 Test
defrag must be applied and the circuits affected noted. A VC3 defrag can
then be applied and the second VC3 then added. The VC3 Defrag will only
hit VC12 connections that need to be reallocated to facilitate the addition
of the VC3.
Adding a combination of VC12 and VC3 connections

If the user requires to add a series of VC12 and VC3 connections to the one
Release9 NE, then the VC3 connection should be added (using ‘Adding a
VC3 Connection’ above) before any VC12 connections. By adding the VC3's
first the back-plane will be organized so as minimize potential traffic hits for
the new connections. The VC12 connections can then be added (following the
methods detailed below)
Adding VC12 connections only

A test connect should be carried out, if the test connect reports significant
traffic hits (greater than four VC12 connections) then consideration should be
given to performing a VC12 defrag before making the connection. A VC12
defrag will reduce the potential hits for future VC12 traffic, but may cause an
increased hit during the defrag operation.
• Adding VC12 connections to 2Meg Trib cards after an Upgrade

Where possible use a set of 4 ports that has no connections already on it.
For example, if slot 4, ports 5, 6, 7, 8 are all free use these up first. Relevant
sets of 4 are:
Ports 1, 2, 3, 4

Ports 5, 6, 7, 8
Ports 9, 10, 11, 12
Ports 13, 14, 15, 16
This is for any 2M card (or the 16x2 card)
• Method 1: 60 Connections without Hit Risk
60 VC12 connections can be added in any order, but it is recommended that
the VC12 Connections on 2Meg tribs should be added in incrementing
order, all the ports on slot 2 from 1 to 16 then all the ports on s4 1 to 16, all
the ports on slot 9 1 to 16 and then slot 11 1 to 12. The last three
connections (slot 11 ports 13, 14 and 15) will generate a hit risk with this
method.
• Method 2: 63 Connections without Hit Risk
The second method requires adding the last 3 available ports first, for
"
example, add slot 11 port 13, 14 and 15, The rest of the connections can be
added in any order but it is again recommended that they are added in
incrementing order from slot 2 port 1 up to slot 11 port 12 finally. All 63
VC12 connections can be added without a Hit Risk using this method.
• Churning 2Meg Trib Connections On a VC12 Only Mux
When Churning the connections added using the above methods the last
three connections, for example, Slot 11 port 13, 14 and 15 should not be
deleted if possible, this will prevent significant Hit Risk when adding
further connections.
• Deleting then adding new connections on 2Meg Trib Cards
After VC12 connections have been deleted and new connections are to be
added, these new connections can be added in any order to the ports that
are available.
• 2Meg Trib and STM1 Cards
The VC12 Connections on 2Meg tribs should be added first in
incrementing order, all the ports on slot 2 from 1 to 16 then all the ports on
s4 1 to 16 etc. The connections on the STM1 card can then be added. This
method will prevent Hit Risk.
• Deleting then adding connections on 2Meg and STM1 Trib Cards
The connections on both cards can be deleted in any order, but the VC12
connections on the 2Meg trib cards should be re-added first using the
methods detailed above. The connections on the STM1 card can then be
added. This method will reduce a Hit Risk to existing traffic.
• Adding VC12 connections on STM1 Trib Cards only
These connections can be added in any order up to the total number of 63.
A VC12 Defrag should never be used on a mux with only STM1 trib cards
present.
• Adding VC12 Connections with a VC3 Present
The VC12 connections can be added in incrementing order using the
methods detailed above.

It is good practice that the Test Connect function and the Test Defrag is used
before applying either a connection or a defrag on the connections that are
already present. If a test connect reports a similar number of circuits hit to a
test defrag and it's not covered in the above adding connections, it is therefore
recommended to apply the Defrag as this will result in a shorter hit to the
effected existing paths. Compared to just adding the connection.
Adding connections
If a through connection (of any type) is made between aggregates, a payload
on one aggregate must be paired to the same payload on the alternate
aggregate. For this to be possible, the alternate payload must be free of
connections. This process does not use the internal bus.
If a VC-12 drop connection is added, the following conditions must be met:

• There is an available port/payload on the tributary unit to which the
connection is to be made.
• There is an available ‘slot’ on the internal bus. The position of this slot is
not significant (see “Defragmenting the TN-1X internal bus” on page
4-84).
If a VC-3 drop connection is added, the following conditions must be met:

• The Payload Manager must support VC-3 drop connections.
• The KLM elements of the specified STM-1 payloads must be K100, K200
or K300 (see Appendix D: KLM payload numbering).
• The internal bus has 21 consecutive ‘slots’ available for use. If the loading
of the bus is fragmented, a defragmentation of the bus is required (see
“Defragmenting the TN-1X internal bus” on page 4-84).
Note 1: When connections are made to PDH ports, alarms may be raised if
traffic is not present. This can be prevented by use of the traffic monitoring
functionality (see “Raising signal alarms” on page 4-113).
Note 2: The internal bus of the TN-1X can be defragmented, but the
physical connections between aggregates and tributaries cannot. For a
VC-3 payload to be added, a suitable tributary payload must be available
for use (see above). This situation is made possible only by planned
network development.
Disconnections
Any connection that is established can be disconnected. When disconnected,
the traffic on the connection is lost. The payloads on either end of the
connection are available for reuse, along with the associated bandwidth on the
TN-1X buses.
Note: When connections to PDH ports are disconnected, alarms may be

raised if traffic is still present. This can be prevented by use of the traffic
monitoring functionality (see “Raising signal alarms” on page 4-113).

Bulk connections and disconnections

The TN-1X connection management functionality supports the following bulk
transactions:
• The user can establish through connections for all unused VC-12s.
• The user is able to disconnect all connections.
Testing connections
The user is able to identify traffic hits that will occur as the result of changes
to connectivity. This allows the implications of new connections to be assessed
before they are made.
• The user can identify traffic hits that will result from a new connection. If
existing connections conflict with the proposed connection, these will be
•
identified as being at risk.
The user can identify the traffic that will be affected by a defragmentation
"
of the TN-1X internal bus that is biased towards future VC-12 connections.
• The user can identify the traffic that will be affected by a defragmentation
of the TN-1X internal bus that is biased towards future VC-3 connections.
Note 1: The physical connections between aggregates and tributaries are

unchanged by defragmentation, but a traffic hit will occur if the bus slots
that enable this connection are reconfigured.
Note 2: It is recommended that the ‘test connection’ functionality is used
to plan future connections, rather than the ‘brief payloads’ functionality.
User labels
The TN-1X supports up to sixty three through and drop connections. A user
label, which can be used to provide additional information about the nature of
the connection, is associated with each of these connections. It is a string of
up to fifteen alphanumeric characters that may include dash (‘-’) and
underscore (‘_’) characters.
The user label is displayed on all alarms, events, and performance monitoring
logs involving the connection. The default user labels associated with
connections are detailed below.
• For drop connections to a PDH port, a PDH port reference is used. For
example, ‘S2-1’.
• For drop connections to a STM-1 tributary payload, an STM-1 tributary
payload reference is used. For example, ‘S4-1-J1-K111’.
• For through connections, the alternate aggregate payload reference is used.
For example, ‘S7-1-J1-K123’.

Command details
The commands that access the connection functionality of the TN-1X are
Figure 4-18
Config/coNnections command hierarchy
Config
coNnections
Au4_select
Connect
Test_connect
thRough_unused_VC12
Disconnect
aLl_disconnect
User_label
deFrag
vc12_opt
vc3_opt
vc12_Test_opt
vc3_Test_opt
coNvert_prot_to_unprot
View
Connected
BPayloads
Payloads
Au4_select
Table 4-69
Config/coNnections
Au4_select CNA ‘1‘ | ‘2’ | ’3‘ | ‘4’ No Selects the AU4 to be

dropped from the STM-N
aggregates.
Connect CNC SDH_aggr_payload Yes Defines a drop connection.

[&SDH_aggr_payload] (see This can be either a
SDH_trib_payload | Note) protected connection or
PDH_port unprotected connection.
SDH_aggr_payload Defines a bidirectional

SDH_aggr_payload through connection.
thRough_unused_ CNR N/A Yes Through connects all

vc12 unused VC-12 payloads.
aLl_disconnect CNL N/A Disconnects all connections

within the TN-1X.
—continued—

Table 4-69
Config/coNnections (continued)
Test_connect CNT SDH_aggr_payload No Lists the connections that

[&SDH_aggr_payload] would be hit if the specified
SDH_trib_payload | connection was established.
PDH_port
SDH_aggr_payload
SDH_aggr_payload
SDH_trib_payload
PDH_port
SDH_trib_payload
SDH_trib_payload
Disconnect CND SDH_aggr_payload |

[&SDH_aggr_payload]
Yes Disconnects the specified
drop connection.
"
SDH_trib_payload |
PDH_port
SDH_aggr_payload Disconnects the specified

SDH_aggr_payload through connection.
User_label CNU SDH_aggr_payload No Assigns a user label to the

[&SDH_aggr_payload] specified drop connection.
SDH_trib_payload |
PDH_port
user_label
SDH_aggr_payload Assigns a user label to the

SDH_aggr_payload specified through
user_label connection.
deFrag CNF See Table 4-70.
coNvert_prot_ CNN SDH_aggr_port Yes Converts all protected

to_unprot connections on specified
aggregate port to
unprotected. This is
performed in preparation for
the use of the aggregates
for multiplexer section
protection (MSP).
View CNV See Table 4-71.
Note - Confirmation is only required if there is a possibility of a traffic hit
—end—

Table 4-70
Config/coNnections/deFrag
vc12_opt C N F 12 N/A Yes Defragments the internal bus,

optimising for future VC-12
connections.
vc3_opt CNF3 Defragments the internal bus,

optimising for future VC-3
connections.
vc12_Test_opt C N F 12T No Lists any connections that

would be affected if a
defragmentation (optimised for
VC-12) command was issued.
vc3_Test_opt C N F 3T Lists any connections that

would be affected if a
defragmentation (optimised for
VC-3) command was issued.
Table 4-71
Config/coNnections/View
Connected CNVC [SDH_aggr_payload | No Displays a report of all

(see note 1) SDH_trib_payload] connections involving the specified
(see note2) payload. If no parameter is
specified, all connections are
listed.
Payloads CNVP SDH_aggr_payload | Displays payloads for the specified

(see note 1) SDH_trib_payload | port/payload. If no parameter is
SDH_port | specified, all payloads are listed.
PDH_port
BPayloads C N V BP N/A Displays all payloads in a concise

(see note 1) form.
Au4_select CNVA N/A Identifies which AU4 is in use on

the TN-1X’s STM-N aggregates.
Note 1: Where connections exist that are part on an multiplexer section Protection (MSP) configuration,
these are displayed for the working channel only, irrespective of whether the working channel or the
protection channel is currently in use.
Note 2: If this parameter is not specified, all relevant information is displayed.

Parameters
SDH aggregate payloads are detailed in “SDH aggregate


following syntax:

"
Note: If you do not specify the <KLM> term in the SDH_aggr_payload
and SDH_trib_payload parameters, the default (K111) is used. Ensure that
the correct TU is specified when adding or deleting connections.
• The <SDH_aggr_port> parameter identifies the physical port on an STM-1

aggregate. The format for this is:
S<slot>-<port>

S<slot>-<port>
following syntax:
S<slot>-<port>
• The ‘1’, ‘2’, ‘3’ and ‘4’ values represent the number of the AU-4 payload
to be dropped. For an STM-1 aggregate, this defaults to ‘1’.
• The <user_label> parameter is a string of up to fifteen characters that may
include dash (‘-’) and underscore (‘_’) characters.
Autonomous events

Reports
The reports for the above commands are detailed below.
Note: Where connections exist that are part on an Multiplexer Section
Protection (MSP) configuration, these are displayed for the working
channel only, irrespective of whether the working channel or the protection
channel is currently in use.
Config/coNnections/Test_connect
Config/coNnections/deFrag/vc12_test_opt
Config/coNnections/deFrag/vc3_test_opt
The entries used by these commands are listed below.
254, Potential Traffic hit connections
255, <SDH_aggr_payload>[&<SDH_aggr_payload>],
<SDH_trib_payload|PDH_port>, BI, Ulabel= <user_label>
For example:
254, Potential traffic hit connections
251, S6-1-J1-K111&S7-J1-K111, S2-1, BI, Ulabel= Customer_1
251, S6-1-J1-K113, S2-3, BI, Ulabel= Customer_1
251, S6-1-J1-K114, S7-J1-K114, BI, Ulabel= Customer_1
;
Note: It is recommended that the ‘Test_connect’ report is used to plan

future connections, rather than the ‘Bpayloads’ report.
Config/coNnections/View/Connected
25, Connections
251, <SDH_aggr_payload>[&<SDH_aggr_payload>] |
<SDH_trib_payload>|<PDH_trib_payload>,
<SDH_trib_payload|PDH_port>, BI, Ulabel=<user_label>
For example:
25,Connections
251,S6-1-J1-K152, S4-3, BI, Ulabel = S4-3
251,S6-1-J1-K161, S4-1, BI, Ulabel = S4-1
251,S7-1-J1-K151, S4-4, BI, Ulabel = S4-4
251,S7-1-J1-K153, S4-2, BI, Ulabel = S4-2
;
Config/coNnections/View/Au4_select
258, AU4 Select
259, AU4_select = <‘1’|‘2’|‘3’|‘4’>
For example:
258, AU4 Select
251, AU4_select = 1

Config/coNnections/View/Payloads
256, Payload Connectivity
257, <SDH_aggr_payload|SDH_trib_payload|PDH_port>,
con_s = <‘Free’|‘Connected’|‘Hit_risk’|‘Blocked’|
‘Blocked_internally’|‘Drop_free’|
‘MSP_blocked’ >, Ulabel = <user_label>
Where:
• ‘Free’ indicates that the payload is free, and using it will not hit traffic.
• ‘Hit_risk’ indicates that the payload is free, but using it will hit traffic
under some circumstances. The user should use one of the test connect
commands to establish the exact connections that will be hit.
• ‘Connected’ indicates that the payload is connected. "
• ‘Blocked’ indicates that the payload is not available because the bandwidth
is in use by an overlapping payload.
• ‘Blocked_Internally’ indicates that the payload is blocked due to the
internal architecture of the TN-1X.
• ‘Drop_Free’ indicates that the payload is available for drop connections
only.
• ‘MSP_blocked’ means that the payload is blocked due to MSP usage.
For example:
256, Payload Connectivity
257, S2-1, con_s = Connect, Ulabel = Customer_1
...
...
257, S4-16, con_s = Free, Ulabel = Customer_2
257, S6-J1-K111, con_s = Blocked, Ulabel = Customer_1
...
257, S6-J1-K373, con_s = Connect, Ulabel = Customer_1
257, S6-J1-K200, con_s = Free, Ulabel = Customer_1
...
257, S7-J1-K200, con_s = Free, Ulabel = Customer_1
...
...
257, S11-16, con_s = Free, Ulabel = Customer_2
;

Config/coNnections/View/BPayloads
260, Brief Payload Connectivity
261, <SDH_AU4>,, <SDH_payload_info>
261, <PDH_port>, 16, <PDH_port_info>
Where:
• The <SDH_payload_info> is a string of characters, each of which
represents the state of a VC-12 or VC-3 payload. The following characters
are used in this string:
— ‘F’ stands for ‘Free’.
— ‘C’ stands for ‘Connected’.
— ‘D’ stands for ‘Only drop connection possible’.
— ‘H’ stands for ‘Connection possible, but potential hit-risk’.
— ‘B’ stands for ‘Blocked’.
— ‘I’ stands for ‘Blocked due to fully utilised backplane’.
— ‘M’ stands for ‘Blocked due to MSP’.
Each of the above characters represents one of the payload states detailed
in “Config/coNnections/View/Payloads” on page 4-95.
• The <PDH_port_info> is a string of sixteen characters, each of which
represents the state of a single PDH port. The characters used to represent
each state are the same as for SDP payloads (see above).
For example:
260,Brief Payload Connectivity
261,S6-1-J1,,CCCFCCCCCFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFBBB
261,S7-1-J1,,FCCFCCFCCFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFBBB
262,S2,16,CCCCCCFCCFFFFFFF
262,S4,16,FFFFFFFFFFFFFFFF
261,S9-1-J1,,FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBBB
262,S11,16,FFFFFFFFFFFFFFFF
;
Note: It is recommended that the ‘Test_connect’ report is used to plan

future connections, rather than the ‘Bpayloads’ report.

Config/carDs <C D>

This command enables the user to access the card equipping functionality of
the TN-1X.
Equipping
The equipping functionality of the TN-1X enables the user to specify which
cards occupy which slots.
Unequipping a card
When a card is to be removed, connections to the card must first be deleted.
The card can then be unequipped by specifying the slot in which the card is
located. Finally, the card can then be removed from the mux.
If a card is still present when a slot is unequipped, or if a card is added while a

slot is unequipped, an ‘NE-Unexpected_Card’ alarm is raised. "
If a card is replaced by another card from the same card family, the
connections used on the original card can be preserved. To do this, do not
delete the connections or unequip the card before it is removed. When the
new card is inserted, re-equip the card to remake the original connections.
Each card family includes all variants of a card type.
Note: Cards that are part of an MSP protection pair cannot be unequipped.
However, these cards can replaced and re-equipped with cards from the
same card family without disrupting MSP settings.
Equipping a card
Once a card has been inserted into the mux, the slot can be equipped to
identify the inserted card. No confirmation is required to equip a slot.
If a card is absent when a slot is equipped, or if it is removed while the slot is

equipped, an ‘NE-Card_Out’ alarm is raised.
If an inserted card has replaced another card from the same card family, the
connections used on the original card can be preserved. To do this, do not
delete the connections on the original card, or unequip the original card
before it is removed. Once the new card is inserted, re-equip the card to
remake the original connections. Each card family includes all variants of a
card type. A confirmation is required when a slot is re-equipped.
Note 1: STM-4 aggregates and STM-1 optical aggregates are regarded as

a single card family, referred to as STM-N optical aggregates.
Note 2: The NTKD23AA variant of the 75 Ω 2 Mbit/s tributary unit must
be equipped as the 25U JU00 750 HVT unit.
Note 3: The NTKD23AB variant of the 120 Ω 2 Mbit/s tributary unit must
be equipped as the 25U JU00 750 HVQ unit.

Cards and slots

The cards that may be fitted into each slot are listed in Table 4-72 below.
Many of these cards have variants that are detailed later in this chapter.
Note: If 2-inch STM-1 tributary units are installed in slots 2, 4 and 11, then
this will prevent the installation of cards in slots 3, 5, and 12. That is, slot 3
cannot be installed with an 1:N protection tributary unit, slot 5 cannot be
installed with a Payload Manager, and slot 12 cannot be installed with a
power supply unit.
Table 4-72
Cards and slots
Slot Cards
1 Interface Control card (ICC).
2 Tributary (STM-1, 75/120 Ω 2 Mbit/s, 75 Ω 34 Mbit/s (16x2M) or 75 Ω 34/45 Mbit/s (VC3)).
3 1:N Protection Tributary (75ohm 2 Mbit/s or 120 ohm 2 Mbit/s).
5 Payload Manager.
6 Aggregate ‘A’ (STM-1 or STM-4).
7 Aggregate ‘B’ (STM-1 or STM-4).
8 Payload Manager.
10 Unused.
12 Power Supply Unit (PSU).
13 Power Supply Unit (PSU).
14 Subrack Controller (SRC).

Command details
The commands that access the equipping functionality of the TN-1X are
shown in Figure 4-19, and are detailed in the sections that follow.
Figure 4-19
Config/carDs command hierarchy
Config
carDs
Equip
Icc
stm_1_Trib
stm_1_Agg
stm_4_Agg
2M_trib
PSu
Payload_Man
"
16x2m
34_45M
Unequip
View
Ports_view
Table 4-73
Config/carDs
Equip CDE See Table 4-74.
Unequip CDU slot Yes Unequips the card in the specified

(default) slot
View CDV N/A No Displays a report of equipped cards.
Ports_view CDP N/A No Displays all ports that have been

equipped.
Table 4-74
Config/carDs/Equip
Icc CDEI See Table 4-75.
stm_1_Trib C D E 1T See Table 4-76.
stm_1_Agg C D E 1A See Table 4-77.
stm_4_Agg C D E 4A See Table 4-78.
2M_trib C D E 2M See Table 4-79.
PSu C D E PS slot No Equips the specified slot with a

power supply unit.
Payload_Man C D E PM See Table 4-80.
16x2m C D E 16 See Table 4-81.
34_45M C D E 34M See Table 4-82.

Table 4-75
Config/carDs/Equip/Icc
v1_eow_GVX C D E I GVX slot No Equips the selected ICC Unit

(see note) in the specified slot.
v2_nui_13aa C D E I 13
Note: A confirmation is required when re-equipping a slot with a card from the same card family.
Table 4-76
Config/carDs/Equip/stm_1_Trib
opt_GVA C D E 1T GVA slot No Equips the selected STM-1

(see note) Tributary Unit in the specified
elec_GVB C D E 1T GVB slot.
opt_HWE C D E 1T HWE
opt_HWG C D E 1T HWG
opt_mp_11aa C D E 1T 11
elec_JBK C D E 1T JBK
elec_mp_12aa C D E 1T 12
Table 4-77
Config/carDs/Equip/stm_1_Agg
elec_GWB C D E 1A GWB slot No Equips the selected STM-1

(see note) Aggregate Unit in the
opt_GWA C D E 1A GWA specified slot.
opt_HWF C D E 1A HWF
opt_HWH C D E 1A HWH
Table 4-78
Config/carDs/Equip/stm_4_Agg
opt_GSA C D E 4A GSA slot No Equips the selected STM-4

(see note) Aggregate Unit in the
is_GSC C D E 4A GSC specified slot.
1550_HVB C D E 4A HVB

Table 4-79
Config/carDs/Equip/2M_trib
75ohm_HVT C D E 2M HVT slot No Equips the selected 2M

(see note) Tributary Unit in the
120-ohm_HVQ C D E 2M HVQ specified slot.
75ohm_GXG C D E 2M GXG
120ohm_GXR C D E 2M GXR
Table 4-80
Config/carDs/Equip/Payload_Man
Menu Item Shortcut Parameters Confirm Description "
HZQ C D E PM HZQ slot No Equips the selected
(see note) Payload Manager unit in
GXF C D E PM GXF the specified slot.
mp_10aa C D E PM 10
Table 4-81
Config/carDs/Equip/16x2m
HJZ C D E 16 HJZ slot No Equips the specified slot

(see note) with a 34 Mbit/s (16 x 2M)
card.
Table 4-82
Config/carDs/Equip/34_45M
vc3_data_16AA C D E 34M 16AA slot No Equips the specified 34/45M

(see note) tributary unit in the specified
slot.
vc3_data_16BA C D E 34M 16BA slot No Equips the specified 34/45M

(see note) tributary unit in the specified
slot.

Parameters
• The <slot> parameter specifies a slot for a card to be equipped into, or
unequipped from. The syntax is:
S<slot_number>
Where <slot_number> is the slot number. For example:
S2
This represents slot 2.
Autonomous events
Reports
The reports for the above commands are detailed below.
Config/carDs/View
23, Cards
231, <slot>, Card = <card_type> | ‘UNEQUIPPED’
Where <card_type> is one of the following:

Table 4-83
Card types for the TN-1X
Card Description
Psu Power Supply Unit
ICC-V1_EOW_GVX Engineering Order Wire (EOW) unit and

Interface Control Card (ICC) unit
ICC-V2_NUI_13AA
STM_1_Trib-opt_GVA STM-1 Optical Tributary Unit
STM_1_Trib-opt_HWE
STM_1_Trib-opt_HWG
STM_1_Trib-opt_mp_11AA
STM_1_Trib-elec_GVB STM-1 Electrical Tributary Unit
STM_1_Trib-elec_JBK
STM_1_Trib-elec_mp_12AA
STM_1_Agg-elec_GWB STM-1 Electrical Aggregate Unit
STM_1_Agg-opt_GWA STM-1 Optical Aggregate Unit (see Note)
STM_1_Agg-opt_HWF
STM_1_Agg-opt_20AA
STM_1_Agg-opt_HWH
—continued—

Table 4-83
Card types for the TN-1X (continued)
Card Description
STM_4_Agg-opt_GSA STM-4 Aggregate Unit
STM_4_Agg-IS_GSC
STM_4_Agg-1550_HVB
2M_Trib-75ohm_GXG 2 Mbit/s tributary Unit (see Note)
2M_Trib-75ohm_HVT
2M_Trib-120ohm_GXR
2M_Trib-120ohm_HVQ
Payload_man-GXF
Payload_man-HZQ
Payload Manager
"
Payload_man-mp_10AA
Payload_man-TBD_10CA
16X2M-HJZ 34 Mbit/s (16x2) Tributary Unit
34_45M-vc3_data_16AA 34/45 Mbit/s (VC3) Tributary Unit, designed for data.
34_45M-vc3_data_16AB 34/45 Mbit/s (VC3) Tributary Unit, designed for data.

Supports 45 Mbit/s AIS.
Note: Although the NTKD21AA, NTKD23AA and the NTKD23AB variants are
not selectable from the CLUI menu, they should be equipped as follows:
The NTKD21AA is equipped as Opt_hwf
The NTKD23AA is equipped as 75ohm_hvt
The NTKD23AB is equipped as 120ohm_hvq
—end—
For example:
23, Cards
231, S1, Card=UNEQUIPPED
231, S2, Card=2M_Trib-75ohm_GXG
231, S5, Card=Payload_man-mp_10AA
231, S6, Card=STM_4_agg-opt_GSA
231, S7, Card=STM_4_agg-opt_GSA
231, S8, Card=Payload_man-mp_10AA
231, S10, Card=UNEQUIPPED
231, S12, Card=Psu
231, S13, Card=Psu
231, S14, Card=SRC
;

Config/carDs/Ports_view
536, Ports
537, <PDH_port | SDH_trib_payload | SDH_aggr_payload>,
Traffic = <Traffic_type, Ulabel = [<label>]
Where:
following syntax:
S<slot>-<port>
• The <SDH_trib_payload> parameter identifies an SDH tributary payload.

This takes the following syntax:



• The <traffic_type> parameter identifies the nature of the card traffic on the
card. Traffic types are listed in Table 2-6 on page 2-12.
For example:
536,Ports
537,S2-1, traffic=2M75, Ulabel=S2-1


537,S6-1, traffic=A-1o, Ulabel=
537,S7-1, traffic=B-1o, Ulabel=
537,S9-1, traffic=STM1e, Ulabel=
;
"

Config/Payman_Protect <C PP>

This command enables the user to access the Payload Manager protection
Payload Manager protection

The Payload Manager controls the drop-and-insert functionality of the TN-1X.
This unit processes the entire traffic capacity of the mux. The TN-1X subrack
contains slot positions for two Payload Manager units. These are used as
follows:
• When one Payload Manager is installed, this unit is used until it fails. On
failure, all traffic is lost until the unit is replaced.
• When two units are fitted, the units operate in a main/standby
configuration. That is, one unit is active, and the other is a backup unit. If
the main unit fails, the subrack controller will automatically switch to
using the backup unit. Until the switch occurs, there may be:
— temporary loss of traffic.
— path protection switches.
— MSP switches.
— temporary alarms raised.
The switching process can also be performed manually by the user.
Provided that two Payload Managers are installed, and Payload Manager
switching is enabled, the following alarms will cause a Payload Manager
switch when raised against the active Payload Manager.
• NE-Card_Fault.
• NE-Card_Fail.
• NE-Card_Out.
Note 1: Forced Payload Manager switching is not possible when the mux
is in detached mode (see “Detached mode” on page 9-22).
Note 2: Payload Manager protection cannot be enabled unless there are
two Payload Managers of the same type. This prevents incorrect operation
when VC-3 traffic is being carried. When upgrading from Release 6
(where this was supported), Payload Manager protection will be disabled.
Note 3: Payload Manager switches should not be performed more often
that every six minutes on a single NE.

Command details
The commands that access the Payload Manager protection functionality of
the TN-1X are shown in Figure 4-20 below, and are detailed in the tables that
follow.
Figure 4-20
Config/Payman_Protect command hierarchy
Config
Payman_Protect
pm_switch_mode_oN
pm_switch_mode_Off
S5
View
S8
Current "
STatus_view
Table 4-84
Config/Payman_Protect
pm_switch_oN C PP N N/A Yes Enables automatic protection

switching.
pm_switch_Off C PP O See Table 4-85.
View C PP V N/A No Displays the current switching mode.
STatus_view C PP ST N/A No Displays the active Payload Manager.
Table 4-85
Config/Payman_Protect/pm_switch_Off
S5 C PP O S5 N/A Yes Disables automatic Payload Manager

switching, and selects the unit in slot
five for use.
S8 C PP O S8 Disables automatic Payload Manager

switching, and selects the unit in slot
eight for use.
Current C PP O C Disables automatic Payload Manager

switching, and retains the current unit.
Parameters
The Payload Manager protection commands described above make no use of
parameters.

Autonomous events
• When a successful Payload Manager switch occurs:
963, Active_PM = <‘S5’|‘S8’>, Reason = <‘Forced’|‘Auto’>
• When an unsuccessful Payload Manager switch occurs:

963, Active_PM = <‘S5’|‘S8’>, Reason = <‘Forced’|‘Auto’>,
Switch_fail_to = <‘S5’|‘S8’>
Reports
The reports generated by the above commands are listed below.
Config/Payman_Protect/View
110, Payload Manager Switch Configuration
111, PM_switch_mode = <‘Off_S5’|‘Off_S8’|‘On’>
Where:
• ‘Off_S5’ identifies slot 5 as the active Payload Manager in manual mode.
• ‘Off_S8’ identifies slot 8 as the active Payload Manager in manual mode.
• ‘On’ indicates that automatic Payload Manager protection switching is on.
For example:
110, Payload Manager Switch Configuration
111, PM_switch_mode = Off_S8
Config/Payman_Protect/STatus_view
described in “View_status/Payman_Protect” on page 7-14.

Config/Trib_Protect <C TP>

This command enables the user to access the 1:N tributary protection
1:N tributary protection

The TN-1X has four tributary slots (S2, S4, S9, and S11) that can be equipped
with a variety of tributary units. The TN-1X supports 1:N tributary protection
for one or more 2 Mbit/s tributary units. When 1:N tributary protection is
used, the traffic connections and payloads for a single failed 2 Mbit/s tributary
unit can be switched to an alternative 2 Mbit/s tributary unit equipped in
slot 3.
There are two modes of 1:N protection switching:

• Automatic switching. There are two types: "
— Auto
When a 2 Mbit/s tributary unit fails, an automatic switch to the
alternative unit in slot 3 is made. Once any alarms on the failed unit
clear, protected traffic must be switched back to the original card
manually by the user.
— Revert_auto
Identical to Auto, but automatically reverts to working slot when the
fault and Wait-To-Restore (WTR) is cleared.
• Forced switching. Here, the user is able to manually switch the traffic from
a specific 2 Mbit/s tributary unit to the alternative unit in slot 3. Typically,
this is performed during scheduled maintenance. Once the affected
tributary unit is ready to receive traffic again, protected traffic must be
switched back to the original card manually by the user.
Note 1: There will be a temporary traffic hit whenever a manual or
automatic 1:N protection switch occurs.
Note 2: Forced tributary protection switching is not possible when the mux
is in detached mode (see “Detached mode” on page 9-22).
The 1:N protection switching modes described above can be enabled if all of
the following logical conditions are met:
• Slot 3 must be equipped as either of the following units:
— 2 Mbit/s 75 Ω Tributary Unit (NTKD23AA or 25U JU00 750 HVT
equipped as 25U JU00 750 HVT).
— 2 Mbit/s 120 Ω Tributary Unit (NTKD23AB or 25U JU00 750 HVQ
equipped as 25U JU00 750 HVQ).
• All 2 Mbit/s tributary units must be equipped as the same impedance type
as the card in slot 3 (see above).
• Slot 1 must be equipped as an ICC2 unit (NTKD13AA).
• The active Payload Manager must be either a 25U PJ00 750 HZQ or
NTKD10AA unit.

• There are no NE-Card_Out alarms raised against any slots on the mux.
CAUTION
1:N 2 Mbit/s tributary switching
If 1:N tributary protection is enabled, do not remove an active
2 Mbit/s Tributary Unit. Perform a manual 1:N protection
switch to the protection 2 Mbit/s Tributary Unit before
removing an active 2 Mbit/s Tributary Unit.
An 1:N protection switch can be performed if all of the following physical

conditions are met:
• The ICC2 card must be physically installed and equipped in Slot 1, and
must not have an ‘NE-Card_Fail’ alarm raised against it.
• The Payload Manager must have no alarms raised against it.
• The faulty 2 Mbit/s unit must have traffic connections.
• The 2 Mbit/s unit to be switched to must have no alarms raised against it.
• All 2 Mbit/s units to be protected must be supported by a pair of 1:N
switching TAMs of the appropriate impedance type (either NTKD14AA or
NTKD15AA).
Note 1: If a two-inch STM-1 electrical tributary unit is installed in slot 2,

the width of the unit will prevent the required tributary unit from being
installed in slot 3.
Note 2: No connections can be added to a tributary card from which traffic
has been switched.
Note 3: Cold restarting a mux with 1:N protection enabled and actively
protecting a slot will cause a loss of traffic for up to 12 minutes.
Auto-reversion
An auto-reversion feature is available, which enables traffic being carried on
the protection card to return automatically to the working card when the
condition causing the protection switch clears. This normally occurs a
specified time after the condition has cleared. This time interval is known as
the Wait-To-Restore (WTR) period. The user can enable/disable the
auto-reversion feature via the CLUI.
If the auto-reversion feature is enabled, a WTR period applies to the

protection card.
When the auto-revertive feature is disabled, if the working card recovers,

traffic remains on the protection card indefinitely, i.e. current functionality.
Note: The auto-reversion feature is not supported on the Preside.
Command details
The commands that access the 1:N tributary protection functionality of the
follow.

Figure 4-21
Config/Trib_Protect
Config
Trib_Protect
Mode
Auto
Manual
Disable
Revert_auto
force_From
Clear_protect
View
"
STatus_view
Table 4-86
Config/Trib_Protect
Mode C TP M See Table 4-87.
force_From C TP F ‘S2’ | ‘S4’ | Yes Switches traffic from the specified slot
(see note) ‘S9’ | ‘S11’ to the protection unit in slot 3.
Clear_protect C TP C N/A Switches back from slot 3 to the

(see note) protected card after a switch has
occurred (providing it is in a valid
state).
View C TP V N/A No Displays protection mode.
STatus_view C TP ST N/A No Displays protection status.
Note: This command can be used only if all required logical and physical conditions are met.
Table 4-87
Config/Trib_Protect/Mode
Auto C TP M A N/A Yes Automatically switches, but does not

(see note) automatically revert to working when
fault (and WTR) is cleared.
Manual C TP M M Enables manual switching.

(see note) (Sets the mode to ‘Force’)
Disable C TP M D Disables 1:N tributary protection

switching.
Revert_auto C TP M R Automatically switches, and

(see note) automatically reverts to working when
fault (and WTR) is cleared.
Note: This mode can be selected only if all required logical conditions are met.

Parameters
There are no parameters used by the above commands.
Autonomous events
• When a successful 1:N protection switch occurs:
964,trib_switch_from = <card_inst>,switch_to=<card_inst>,
Reason = <‘Force’ | ‘Auto’ |‘Revert_auto’ | ‘Clear_prot’>,
Fail_card = <card_inst>
• When an unsuccessful 1:N protection switch occurs:

Fail_card = <card_inst> indicates the card that failed to
successfully complete the 1:Nswitch.On the 1X, possible slot
candidates are :
S1 (ICC2 card)
S3 (Protection card)
S5 | S8 (Current active payload manager)
S2 | S4 | S9 | S11 (The Logical 2Meg Trib involved in the
protection switch).
Reports
The reports for the above commands are listed below.
Config/Trib_Protect/View
115, Trib Protection Configuration
116 <card_inst>,Trib_protect_mode=<‘Force’ | ‘Auto’ |
‘Revert_auto’ | ‘Disable’>,[Force_from = <‘Inactive’ |
‘card_inst’>]
For example:
116, S3, Trib_protect_mode = Force, Force_from = Inactive
;
or
116, S3, Trib_protect_mode = Disable
;
Config/Trib_Protect/STatus_view
described in “View_status/Trib_Protect” on page 7-13.

Config/poRts <C R>

This command enables the user to control the way in which the TN-1X raises
certain traffic alarms for PDH ports. It is also possible to configure the
operation of a 34/45M (VC-3) tributary unit between its two bit rates.
Raising signal alarms

Each PDH port can be set to be active or inactive using two traffic modes. The
PPI-LOS and PPI-Unexp_Signal alarms are raised in different ways depending
on which mode is selected. The two modes are:
• Traffic auto mode. Here, the PDH port is marked as active. The PPI-LOS
and PPI-Unexp_Signal traffic alarms for the port are raised in the usual
manner. That is:
— If a connection exists and there is no signal, a PPI-LOS alarm is raised.
— If a signal is encountered where there is no connection, a
"
PPI-Unexp_Signal alarm is raised.
• Traffic standby mode. This mode minimises the alarms that are raised
against a PDH port when a connection is established before traffic is
present. The PDH port is marked as inactive. Alarms are raised as follows:
— If a connection exists, and a signal is detected, a PPI-Unexp_Signal
alarm will be raised against the port.
— PPI-LOS and PPI-Unexp_Signal alarms will not be raised against this
port under any other circumstances.
Note: The traffic modes described above do not prevent the movement of
traffic. Ports that are physically connected will carry traffic, irrespective of
the selected traffic mode.
Command details
The commands that access the traffic functionality of the TN-1X are shown in
Figure 4-22, and are detailed in the tables that follow.

Figure 4-22
Config/poRts
Config
poRts
Traffic_auto
traffic_Standby
Bitrate
34m
45m_Short
45m_Long
View
View
sIgnal_structure
Un_framed
Framed
Framed_and_blocked
Crc
View
Table 4-88
Config/poRts
Traffic_auto CRT PDH_port No Selects auto mode for the specified

(default) PDH port.
traffic_Standby CRS PDH_port Selects standby mode for the

specified PDH port.
Bitrate CRB See Table 4-89.
View (see note) CRV PDH_port | No Displays port settings.

PDH_slot
sIgnal_structure CRI See Table 4-90
Note: If no parameter is specified for this command, all available port information is displayed.

Table 4-89
Config/poRts/Bitrate
34m C R B 34 PDH_slot No Configures the 34/45M (VC-3) card in

the specified slot for 34M operation.
45_Short C R B 45S Configures the 34/45M (VC-3) card in

(see note) the specified slot for 45M short haul
operation.
45_Long C R B 45L Configures the 34/45M (VC-3) card in

(see note) the specified slot for 45M long haul
operation.
View CRBV Displays 34/45M card bit rate

settings.
Note - If this command is applied to a 34/45M card that is involved in 1:1 VC-3 Manual Tributary
Protection while protection is disabled, a ‘PPI-Unexp’ alarm is raised. To clear this alarm, enable
"
protection and perform a protection switch.
Table 4-90
Config/poRts/sIgnal_structure
Un_framed CRIU PDH_port No Sets received signal structure of

quad2m_lo_trib port to unframed.
Framed CRIF PDH_port Sets received signal structure of

quad2m_lo_trib port to framed.
framed_and_ CRIB PDH_port Sets received signal structure of

Blocked quad2m_lo_trib port to
framed_and_blocked
Crc CRIC PDH_port Sets received signal structure of

quad2m_lo_trib port to Crc.
View CRIV PDH_port | Displays received signal structure for

PDH_slot | all quad2m_lo_trib ports on cards.
all
Parameters
following syntax:
S<slot>-<port>
• The <PDH_slot> parameter identifies a PDH slot. This takes the following
syntax:
S<slot>
Autonomous events
There are no autonomous events associated with the above functionality.

Reports
The reports for the above commands are listed below.
Config/poRts/View
32, Port Configuration
321, <PDH_port>, Traffic = <‘Auto’|‘Standby’>,
Connection_src = <SDH_aggr_payload>
[&<SDH_aggr_payload>], Ulabel = <label>
Where:

For example:
32, Port Configuration
321, S2-1, Traffic = Auto, Connection_src = S6-1-J1-K123,
Ulabel = Cust_1
Config/poRts/Bitrate/View
323, Bitrates
324, <PDH_port>, Port_bitrate= <bitrate>, Ulabel = <label>
Where:
• The <bitrate> parameter identifies the configured bit rate for the specified
port. This can be 2M, 34M, 45M_short or 45M_long.
For example:
323, Bitrates
324, S2-1, Port_bitrate = 34M, Ulabel = Cust_Office_01
;
Config/poRts/sIgnal_structure/View
The response is;
32,Port Signal Structure Configuration:
321,s2-1, Port_signal_structure = Unframed, Ulabel = s2-1
321,s2-2, Port_signal_structure = Framed, Ulabel = s2-3
321,s2-3, Port_signal_structure = Framed_and_Blocked,
Ulabel = s2-3
321,s2-4, Port_signal_structure = Crc, Ulabel = s2-4
;
(message 321 is repeated for all valid ports that match the input argument….)

For slots that contain HVT or HVQ boards with the wrong version of ASIC
signal structure reverts to unframed and the report is:
Wrong ASIC
For slots that have just been equipped as NTKD23AA (HVT) or NTKD23AB
(HVQ) boards and have not yet reported their ASIC type, the report is:
Undetermined
If an attempt is made to view the signal structure on a port from a slot

equipped as GXG or GXR then a report detailing the default signal structure,
"
unframed, will be given.
321, s2-1, Port_signal_structure = Unframed, Ulabel = s2-1
Wrong ASIC

Config/MSp <C MS>

This command enables the user to access the multiplexer section protection
Multiplexer section protection

Multiplexer section protection (MSP) is a mechanism that enables protection
switching for all traffic on an STM-1 channel. A 1+1 protection architecture
is supported, which uses a second STM-1 channel of the same type. This
protection channel carries the same traffic as the original working channel.
MSP controls which of these channels is used as the current channel.
MSP monitors both STM-1 channels for failures. The protection status of the
link is carried in the K1 and K2 bytes within the multiplexer section overhead
of the protection channel. The MSP mechanisms on the local mux and the
remote mux transmit protection status information using these bytes. This
enables the mechanisms to determine which of the channels should be used,
and to perform a protection switch as appropriate.
MSP will switch to the protection channel under a number of alarm and
non-alarm conditions. To revert to using the working channel, a manual
switch must be used. Automatic reversion is not supported. The MSP
mechanism can be locked to prevent the use of the protection section. It is
also possible to force the mechanism to use either the working channel or the
protection channel, and to test the working channel for errors.
When MSP is established, the protection channel must have no connections

present. There is a command that converts protected connections to
unprotected connections on aggregates that are to be used for MSP (see
Table 4-69).
Once MSP is established, the protection channel is inaccessible to the user,

but its configuration mirrors that of the working channel at all times. All
references in events, logs and reports to MSP channels refer to the working
channel, even after a protection switch.
Protected drop connections are supported when a pair of STM-1 tributary

channels are used for MSP. Protected drop connections are not supported
when both STM-1 aggregates are used for MSP.
MSP supports both unidirectional and bidirectional modes of operation.
Note 1: A synchronisation sync source switch does not necessarily occur

as a result of a MSP switch. These mechanisms operate independently.
Note 2: Manual MSP switching is not possible when the mux is in
detached mode (see “Detached mode” on page 9-22).

MSP configurations
On the TN-1X, MSP makes use of both aggregates or a pair of STM-1
tributaries. These are connected in a point-to-point configuration to a pair of
aggregates or tributaries on another SDH mux (such as TN-1X, TN-1C,
TN-1P, TN-4X, Optera Metro 4100, TN-16X, or another manufacturer’s SDH
equipment). Supported MSP configurations are shown in Figure 4-23.
Figure 4-23
MSP configurations
"
BETW EEN B E T W E E N A G G R E G AT E S BETW EEN

A G G R E G AT E S A N D T R IB U TA R IE S T R IB U TA R IE S
T N -1X M U X N O N -M S P A G G R /T R IB C H A N N E LS
SDH MUX M S P A G G R /T R IB C H A N N E LS
For example, a network that uses MSP protection between two rings is shown
in Figure 4-24. The two rings are connected via an STM-1 tributary channel
(Link X). A second tributary channel that carries identical traffic (Link Y)
provides 1+1 MSP protection. If Link X fails, an MSP switch occurs. The
protected and unprotected traffic that was received at either end of the
protected channel from Link X is received instead from Link Y.
Figure 4-24
MSP protection between rings
LIN K X
RING 1 RING 2
LIN K Y

Bidirectional and unidirectional operation

The MSP mechanism supports both unidirectional and bidirectional
operation. These are detailed in the sections that follow.
Unidirectional operation
In unidirectional mode, traffic moves in both directions, but the MSP
mechanisms operate independently. That is, switching is evaluated at the
receive end only. When a switch occurs, the failed direction is switched from
the working channel to the protection channel. Override values for the K1 and
K2 bytes can only be used for unidirectional operation.
Unidirectional operation is illustrated in Figure 4-25.
Note 1: Unidirectional operation is implemented in the same way for all

MSP configurations.
Note 2: Unidirectional operation when interworking with Nortel TN-16X
or SONET equipment may result in loss of communications.
Figure 4-25
Unidirectional operation
BEFO R E SW ITC H AFTER S W ITCH
FAILE D
C HA NN EL
TR AN SM ITTED CH AN N EL (IN U SE)
TR AN SM ITTED CH AN N EL (N O T IN U SE)

Bidirectional operation
This is the default setting. In bidirectional mode, traffic moves in both
directions, and the MSP mechanisms communicate and coordinate the
switching of both channels as a pair. When a switch occurs, both channels are
switched from the working channel to the protection channel. Switching of a
single direction is not supported in this mode. Override values for the K1 and
K2 bytes are not used during bidirectional operation.
Bidirectional operation is illustrated in Figure 4-25.

Note 1: For bidirectional mode to be active, both local and remote muxes
must be configured to use bidirectional mode. If only one is configured in
this way, MSP will not function correctly.
Note 2: Bidirectional operation is implemented in the same way for all
MSP configurations. "
Note 3: Bidirectional operation is the preferred method when interworking
with Nortel TN-16X and SONET equipment.
Figure 4-26
Bidirectional operation
B E F O R E S W IT C H A FTE R S W ITC H
FA ILE D
CHANNEL
T RA N S M ITT E D C H A N NE L (IN U S E )
T R A N S M IT TE D C H A N N E L (N O T IN U S E )

Switching conditions
TN-1X supports both manual and automatic MSP switching. It is not possible
to perform a manual switch while the mux is in detached mode. An automatic
MSP switch is initiated via the K bytes under the following conditions:
• Equipment failure. This is characterised by a Signal Failure (SF) condition,
specifically card fail, card fault or card out alarms.
• A ‘hard failure’ condition detected on the incoming STM-1 signal. This is
characterised by a signal failure (SF), specifically LOS, LOF, MS-AIS or
MS-EXC alarms.
Note: Receipt of LOS causes a laser shutdown in addition to the switch.
This causes an LOS on the remote mux, causing a switch. As a result, both
channels switch. This occurs irrespective of whether bidirectional or
unidirectional modes are active.
• A ‘soft failure’. This is characterised by a Signal Degrade (SD) condition,

specifically a signal degrade threshold being exceeded on the incoming
STM-1 signal. Disabling MS-DEG consequent actions will prevent this.
For unidirectional operation, a switch away from the failed channel is

initiated and executed by the receiving MSP. For bidirectional operation, the
local and remote MSP mechanisms communicate and co-ordinate the
switching of both channels.
MSP protocol
MSP operates using a bit-oriented protocol that is transmitted in the K bytes
(K1 and K2) of the multiplexer section overhead of the protection channel.
The K bytes indicate the protection status of both working and protection
channels, and are used by the MSP mechanisms on the local and remote mux
to determine any required switching actions.
The K1 byte
The K1 byte indicates a request from the mux that generated it:
• Bits 1 to 4 indicate the request type.
— A condition associated with a failure. For example, Signal Degradation
(SD) or Signal Failure (SF). This condition can be high or low priority
(high by default).
— A state of the MSP function. For example, Wait To Restore (WTR), Do
Not Revert (DNR), No Request (NR), Reverse Request (RR).
— An external request. For example, Lockout of Protection, Forced,
Manual or Exercise.
• Bits 5 to 8 indicate the channel for which the request is issued. This
indicates either the working or protection channel.
Note: There are a number of binary settings that are not generated by the
TN-1X. Other SDH equipment can generate these settings, however, and
the TN-1X recognises these.

The operational values for bits 1 to 4 of the K1 byte are shown in Table 4-91.
Table 4-91
K1 byte (bits 1 to 4) usage
Bits Value Request Type Description
1111 15 Lockout of Protection External Highest priority.
1110 14 Forced Switch External Force switch unless locked out.
1101 13 Signal Fail - high priority Condition Switch due to a signal fail (high
(see note) priority).
1100 12 Signal Fail - low priority Condition Switch due to a signal fail (low
priority). TN-1X does not generate
this.
1011 11 Signal Degrade - high priority Condition Switch due to BER conditions (high
priority). "
1010 10 Signal Degrade - low priority Condition Switch due to BER conditions (low
priority). TN-1X does not generate
this.
1001 9 Unused N/A N/A
1000 8 Manual Switch External Force switch unless alternative

channel degraded.
0110 6 Wait to Restore State Used in revertive schemes to delay

reversion. Typically 5 to 12
minutes, configurable in 1 minute
steps. TN-1X does not generate
this.
0100 4 Exercise External Used to check K byte operation.
0010 2 Reverse Request State Consequence of Far-End request.

Not used in Unidirectional mode.
0001 1 Do Not Revert State Used in Non-Revertive mode.
0000 0 No Request State Normal condition. Lowest priority.
Note - A signal fail on the protection section will take priority over any forced request which would
cause an MSP switch from the working section to the protection section.

The operational values for bits 5 to 8 of the K1 byte are shown in Table 4-92.
Table 4-92
K1 byte (bits 5 to 8) usage
Bits Value Description
0000 0 Protection channel used (high priority).
0001 1 Working channel used.
0010 - 1111 2 - 15 Other traffic channels. TN-1X does not generate this.
The K2 byte
The K2 byte carries status information:
• Bits 1 to 4 indicates the channel number being bridged. This is the number
of the channel being carried simultaneously on the protection channel.
• Bit 5 indicates whether 1+1 or 1:N architecture is in use.
Note: 1:N architecture is not currently supported by TN-1X.
• Bits 6-8 are mostly reserved for future use, though there are two values that
are used currently.
Note: There are a number of binary settings that are not generated by the
TN-1X. Other SDH equipment can generate these settings, however, and
the TN-1X recognises these.
The operational values for the K2 byte are shown in Table 4-93.
Table 4-93
K2 byte usage
Bits Bits Value Description
1 to 4 0000 0 Protection channel used (high priority).
0001 1 Working channel used.
1111 - 0010 2 - 15 Other traffic channels. TN-1X does not generate this.
5 0 0 1+1 protection architecture is in use.
1 1 1:N protection architecture is in use. TN-1X does not generate this.
6 to 8 000 - 101 0-5 Reserved for future use.
110 6 MS-RDI present.
111 7 MS-AIS present.

Evaluation of requests
Requests from the local and remote muxes are evaluated as follows:
• Bidirectional mode. The requests from the transmitted and received K1
bytes are compared to determine the highest priority request (see
Table 4-91). If a higher priority request is received, a reverse request is
transmitted to indicate this, and the request is implemented. An equal
priority with a lower channel number is handled in the same way.
• Unidirectional mode. The local and remote K1 bytes are not compared.
The local request is affected only by a change to the state of the local mux.
That is, a higher priority request occurs locally, or the current request
becomes invalid.
Selection of the current channel

Selection of the current channel is performed as follows: "
• Bidirectional mode. The remote channel number in the K2 byte is
compared with the channel number in the local K1 byte. If the channel
numbers are the same, this channel becomes/remains current. If the
channel numbers are different for longer than 50 ms, an alarm is raised.
• Unidirectional mode. Selection of the current channel is determined by the
highest priority local request.
MSP alarms
The following new alarms are supported by the TN-1X in bidirectional
operation. These alarms will be cleared once expected behaviour is restored:
• MSP_Prot_Scheme_Mismatch. This is raised after 50 ms if there is a
difference between bit 5 in the sent and received K2 byte. This indicates
that the remote and local MSP mechanisms are configured for different
MSP architectures.
• MSP_Invalid_K_Bytes. This is raised if there is an invalid channel number
or an invalid request indicated in either of the received K bytes for longer
than 50 ms. In this instance, if the protection channel is in use, a signal fail
condition on the protection section occurs. As a result, an MSP protection
switch from the protection channel to the working channel occurs.
• MSP_Channel_Mismatch. This is raised if the K1 transmitted and K2
received channel numbers are different for longer than 50 ms. In this
instance, if the protection channel is in use, a signal fail condition on the
protection section occurs. As a result, an MSP protection switch from the
protection channel to the working channel occurs. This alarm will not be
raised if there is a signal fail on the protection section.
Note: The ‘MSP_Invalid_K_Bytes’ and ‘MSP_Channel_Mismatch’
alarms can also be raised if there is a mismatch in MSP modes used by
interworking equipment.
The MSP alarms listed above are always reported against the protection
channel. MS and RS alarms that relate to multiplexer protection channels are
always reported against the affected channel. All other alarms that relate to
multiplexer protection channels are reported against the working channel.

For details of the structure and usage of the K1 and K2 bytes, see “MSP
protocol” on page 4-122.
MSP LAPD settings

The TN-1X supports the use of two LAPD channels for each MSP pair. When
interacting with equipment that supports one LAPD channel, it is possible to
disable the monitoring of the LAPD channel on the non-active section. When
MSP LAPD monitoring is disabled, a QECC alarm cannot be raised against
the non-active section. When an MSP switch occurs, monitoring of the LAPD
channel also switches, and LAPD monitoring on the new non-active channel
is disabled.
Note: The MSP LAPD settings on are ignored if LAPD is disabled for the
active port (see “Communications management” on page 4-6).
Converting protected connection to unprotected connections

When MSP is established, the protection channel must have no connections
present. To prepare a pair of aggregate channels for use with MSP, it is
possible to convert all protected connections to unprotected connections.
Note: This process should be performed on both the local and remote
multiplexers. Before this is performed, all protected traffic passing
between the multiplexers should be switched to one of the aggregate
channels.
Command details
The commands that access the multiplexer section protection functionality of
the TN-1X are shown in Figure 4-27, and are detailed in the tables that follow.

Figure 4-27
Config/MSp command hierarchy
Config
MSp
Assoc_with_prot
Disassoc_with_prot
Mode
Unidirectional
Bidirectional
K_byte_override
tx_K1_override
tx_K2_override
"
Request
Force_from
Manual_from
Lockout_p
Exercise
Release_all
Lapd_monitoring
Enable_non_active_sect
Disable_non_active_sect
View
STatus_view
Table 4-94
Config/MSp
Assoc_with_prot C MS A SDH_prot_port Yes Associates the pair of aggregate

SDH_work_port (or pair of tributary) ports for
[channel] MSP usage.
(see note 1)
Disassoc_with_prot C MS D Disassociates a pair of ports
used for MSP. Deletes all
connections on the protection
channel.
Mode C MS M See Table 4-95.
K_byte_override C MS K See Table 4-96.
Request C MS R See Table 4-97.
Lapd_monitoring C MS L See Table 4-98.
View C MS V [SDH_prot_port] No Displays MSP settings for the

(see note 2) specified port.
STatus_view C MS ST No Displays MSP status information

for the specified port.
Note 1 - The optional ‘channel’ field can only take a value of ‘1’. If this is not supplied, it defaults to ‘1’.
Note 2 - If this field is not supplied, settings for all MSP ports are displayed.

Table 4-95
Config/MSp/Mode
Unidirectional C MS M U SDH_prot_port Yes Configures the specified port (which is

already configured for MSP usage) for
unidirectional operation.
Bidirectional C MS M B Configures the specified port (which is

already configured for MSP usage) for
bidirectional operation.
Table 4-96
Config/MSp/K_byte_override
tx_K1_override C MS K K1 SDH_prot_port Yes Establishes a K1 byte transmission

override | override for the specified port. The
‘OFF’ ‘OFF’ setting disables a previous
override.
(see note 1)
tx_K2_override C MS K K2 (see note 2) Establishes a K2 byte transmission
override for the specified port.
Note 1 - The ‘OFF’ setting disables a previous override.
Note 2 - K byte overrides can be defined at any time, but are only used during unidirectional operation.
Table 4-97
Config/MSp/Request
Force_from C MS R F SDH_port Yes Performs a forced switch from the

specified channel to the other. Error
conditions are ignored.
Manual_from C MS R M Performs a manual switch from the

specified channel to the other.
Lockout_p C MS R L Prevents the use of the protection

channel on the specified port.
Exercise C MS R E Tests the working channel on the

specified port. Can only be used in
bidirectional mode.
Release_all C MS R R Clears all settings created using the

above commands for the specified
port.
Note - If the protection section is in a signal fail condition, forced switches from the protection section,
and lockouts of the protection section will be attempted for up to 2.5 seconds. If the signal fail condition
does not clear in this time, the operation will then fail.

Table 4-98
Config/MSp/Lapd_monitoring
Enable_non_active_sect C MS L E SDH_prot_port Yes Enables the QECC alarm on

the non-active section of the
specified MSP pair. This is
ignored if MS LAPD
functionality is disabled.
Disable_non_active_sect C MS L D Disables the QECC alarm on

the non-active section of the
specified MSP pair. This
overrides enabled MS LAPD
functionality.
Parameters "
• The <SDH_port> parameter always identifies the physical port on an
S<slot>-<port>
• The <SDH_prot_port> identifies the protection channel of an MSP pair.

This has the same format as the <SDH_port> parameter.
• The <SDH_work_port> identifies the working channel of an MSP pair.
This has the same format as the <SDH_port> parameter.
• The override parameter is a hexadecimal value between 0 and FF.
• The channel parameter can only equal 1.
Autonomous events
• When a successful MSP switch occurs:
975, <SDH_port>, MSP_switch_from=<SDH_port>,
MSP_switch_to=<SDH_port>
• When a local or remote request changes:

976, <SDH_port>, Act_Req=<‘K1_No_Request’|
‘K1_Do_Not_Revert’|’K1_Reverse_Req’|’K1_Exercise’|
‘K1_Wait_To_Restore’|’K1_Manual_Switch’|
‘K1_SD_Low’|’K1_SD_High’|’K1_SF_Low’|’K1_SF_High’|
’K1_Forced_Switch’|‘K1_Lockout’>,
AR_Port=<SDH_port>, AR_Orig= <‘Local’|‘Remote’>
Where:
— SDH_port always refer to the SDH port for the protection channel.
— Act_Req is a description of the request that resulted in the switch.
— AR_Port is the port to which the actual request applies.

— AR_Orig indicates whether the request was generated locally or

remotely.
• When an unsuccessful MSP switch occurs:
977, <SDH_port>, MSP_fail_from=<SDH_port>,
MSP_fail_to=<SDH_port>
• When an exercise of the working channel is complete:

978, <SDH_port>, Exercise_Completed_for=<SDH_port>
Reports
Config/MSp/View
24,Multiplexer Section Protection Configuration
241,<SDH_port>, MSP_arch = 1p1, MSP_mode = <‘Uni’|’Bi’>,
MSP_reversion_mode = ‘Revertive’|’Non_revertive’>
242,<SDH_port>, K1_Byte_Override = <value>,
K2_Byte_Override = <value>,
Lapd_Monitoring_of_Non_Active_Sect =
243,MSP Group Members
244,<SDH_port>, Ch_no = <number>,
Protection_Section = <SDH_port>

For example:
24,Multiplexer Section Protection Configuration
241,S7-1, MSP_arch = 1p1, MSP_mode = Uni,
MSP_reversion = Non_revertive
242,S7-1, K1_Byte_Override = F0H, K2_Byte_Override = E0H,
Lapd_Monitoring_of_Non_Active_Sect = Enabled
243,MSP Group Members
244,S6-1, Ch_no = 1, Protection_Section = S7-1
;
Config/MSp/STatus_view
This report duplicates a status report on the Status View menu, and is detailed
in “View_status/MSp” on page 7-14.
"

Config/tn1x_Card_Switch <C CS>

This command enables the user to access the Manual Tributary Protection
Manual 1:1 tributary protection

The TN-1X supports the protection of VC-3 traffic on up to two 34/45M
tributary units. This enables VC-3 traffic to be protected during the
replacement of a faulty 34/45M tributary unit, or during scheduled
maintenance. The manual tributary protection mechanism uses a 1:1
architecture. That is, each protected tributary unit requires a dedicated
protection tributary unit.
When a manual tributary protection switch is performed, a VC-3 connection

is made on the 34/45M protection unit, along with all configuration settings
for the protected unit. The VC-3 traffic is then moved to the protection card,
and the original connection is deleted. To revert to the protected card, the
protection switch must be cleared manually.
Note 1: For manual tributary protection to operate successfully, new 1:1

protection TAMs must be installed to support the protection units that are
installed in slots 4 and 11. Also, a new variant of the Star Card is required.
The use of these cards is detailed in the TN-1X Module Replacement
Procedures handbook (see “Related documents” on page xv).
Note 2: Once a manual protection switch is made, refresh the Preside EC-1
Element Controller connection interface, if it is in use.
Note 3: Manual tributary protection switching is not possible when the
mux is in detached mode (see “Detached mode” on page 9-22).
Note 4: Cold restarting a mux with manual tributary protection enabled
and actively protecting a slot will cause a loss of traffic for up to
12 minutes.
Note 5: When a manual VC-3 tributary protection switch is performed, any
LP-TIM or LP-PLM alarms that exist will be lost. The monitoring needs to
be re-enabled after switching.
A manual tributary protection switch can be made at any time, either to

restore traffic after the failure of a protected 34/45M tributary unit, or to
enable maintenance on the protected unit.
The following restrictions apply to manual tributary protection:

• Both slots in a protection pair must be equipped as 34/45M VC-3 tributary
units before the feature can be enabled for the pair.
• The NE can have no TAM or Star Card alarms present before the feature
can be enabled for the pair.
• The protection unit must be free of connections before the feature can be
enabled for the pair.
• Configuration of path trace, signal label, alarm monitoring and bit rate
settings is not permitted on the protection unit once the feature is enabled.

• It is not possible to unequip a card in a protection pair once the feature is

enabled.
• It is recommended that tributary units involved in protection pairs are not
used for synchronisation source purposes.
• Performance monitoring for a protected unit is disabled by a manual
switch. Performance monitoring settings must be configured manually for
a protection card after a manual switch.
Note: User interface commands that display connection and payload
information will report that there are no connections on the protection
tributary unit. However, these payloads are not available for connections.
It is not possible to make a VC-3 connection manually on a protection unit
once manual tributary protection for the pair is enabled.
To disable 1:1 tributary protection for a protection pair, the NE must not be "
using the tributary protection mechanism on the affected pair. If the protection
mechanism is in use, a manual switch back to either slot 2 or 9 is required
before the mechanism can be disabled.
Command details
The commands that access the manual tributary protection functionality of the
follow.
Figure 4-28
Config/tn1x_Card_Switch command hierarchy
Config
tn1x_Card_Switch
Enable
Disable
View
STatus_view
Table 4-99
Config/tn1x_Card_Switch
Enable C CS E slot No Enables manual tributary protection for

the pair identified by the protected slot.
Disable C CS O Disables manual tributary protection for

the pair identified by the protected slot.
View C CS V [slot] Displays the current manual tributary

(see note) protection settings.
STatus_view C CS ST Displays a status report for the manual

tributary protection feature.
Note: If this parameter is omitted, information for all instances is displayed.

Parameters
• The <slot> parameter has two possible values:
— ‘S2’. This identifies the protection pair comprised of slots 2 and 4.
Autonomous events
The autonomous events associated with manual tributary protection are listed
with the commands that perform the manual tributary protection switch (see
“Manually switching a 1:1 protected 34/45M tributary unit” on page 6-2).
Reports
Config/tn1x_Card_Switch/View
66, Card Switch
661, <slot>, Standby_trib=<slot>
For example:
66, Card Switch
661, S2, Standby_trib=S4
661, S9, Standby_trib=S11
;
Config/tn1x_Card_Switch/STatus_view
described in “View_status/tn1x_Card_Switch” on page 7-15.

Config/PunchThrough <C PT>

ATTENTION
The PunchThrough feature is for future use and is not a supported feature at
Release 9.
This command enables the user to configure and view the Punch-Through
parameters of the TN-1X.
Command details
The commands that configure the Punch-Through functionality of the TN-1X
are shown in Figure 4-29 below, and are detailed in the tables that follow.
Figure 4-29
Config/PunchThrough command hierarchy
"
Config
PunchThrough
Rate
Data_bits
Stop_bits
Parity
View
Table 4-100
Config/PunchThrough
Rate C PT R <<slot_inst> No Sets the punch through baud rate of the

| <port_inst> RS-232 port.
| external |
CAT>
<baud_rate>
Data_bits C PT D <<slot_inst> Sets the punch through data bits of the

| external |
CAT>
<data_bits>
Stop_bits C PT S <<slot_inst> Sets the punch through stop bits of the

| external |
CAT>
<stop_bits>

Table 4-100
Config/PunchThrough (continued)
Parity C PT P <<slot_inst> Sets the punch through parity of the

| external |
CAT>
<parity>
View C PT V <<slot_inst> Displays which user is currently using

| <port_inst> punch-through session.
| external |
CAT>
see Note
Note: Parameter options <slot_inst>, <port_inst>, external & CAT may be totally omitted on an NE that
contains only one RS-232 port.
Parameters
• The <slot_inst> parameter has two possible values:
• The <port_inst> parameter
• The external parameter
• The CAT parameter
• The <baud_rate> parameter:
— Range = 300 - 19200 (or higher if the product reliably supports it)
— Default = 9600
• The <data_bits> parameter:
— Values = 7 or 8
— Default = 8
• The <stop_bits> parameter:
— Values = 1, 1.5 or 2
— Default = 1
• The <parity> parameter:
— Values = None, Odd, Even, Mark or Space.
— Default = None
Autonomous events
When a punch through session is initiated the following autonomous event is
generated
912, NE_Event=External punch through initiated,
Uname=<user_name>, User=<user>, <date>, <time>
The reason for providing this autonomous event is so that the Preside EC-1
Element Controller event log will record the start of the punch-through

session. This will mean that a systems administrator can track who has used
the punchthrough facility, in other words it is a security feature.
Similarly, on termination of a punchthrough session, the following

autonomous event is generated.
912, NE_Event=External punch through terminated,
Uname=<user_name>, User=<user>, <date>, <time>
Reports
Config/PunchThrough/View
135, Punchthrough Configuration
1351, <<slot_inst>|<port_inst>|external|CAT>, Rate = <baud
"
rate>, Data bits = <data_bits>, Stop bits = <stop_bits>,
Parity = <parity>
;
For example:
135, Punchthrough Configuration
1351, CAT, Rate=9600, Data_bits=8, Stop_bits=1, Parity=None
;

Config/oVerride <C V>

This command enables the user to interoperate with Lucent equipment.
Overided
Lucent has implemented the use of the J2 byte in a way that is different than
Nortel Networks. Configuration of an override byte overcomes this problem.
Command details
The commands that access the override functionality of the TN-1X are shown
in Figure 4-30, and are detailed in Table 4-101.
Figure 4-30
Config/oVeride command hierarchy
Config
oVerride
J2
View
Table 4-101
Config/oVeride
J2 C V J2 hex_value | NULL No This function enables

[mask] interoperability with Lucent
equipment.
View CVV PDH_port No Displays the override status on the

port(s) specified in the single
parameter.
Parameters
• The <PDH_port > parameter identifies a 34/45M PDH tributary port. PDH
ports are detailed in “PDH ports” on page 2-4.
• The <hex_value> parameter is a hexadecimal value between 00 and FF.
• The optional [mask] value is used to mask out the bits of the override byte
which should not be overridden:
— ‘0’ bit in the mask means override
— ‘1’ bit in the mask means do not override
The [mask] value defaults to 0x00 if the mask parameter is omitted. A
‘NULL’ value turns off the overide and normal path trace functionality.

Autonomous events
Reports
Config/oVerride/View
This allows the user to view the override status on the port(s) specified in the
single parameter
An example output is listed below:
40, Overrides
401, S2-1, Override = OFF, Mask = 00H
"
401, S2-2, Override = 00H, Mask = 00H
401, S2-3, Override = A7H, Mask = 0AH
Each line contains the following information:

• The port number (PDH_port)
• The override value, 00 to 7F in hexadecimal with a H suffix or OFF if the
override is currently disabled (NULL entered as override)
• The current value of the mask also displayed in hexadecimal
The user can view this information about a specific port, slot and all ports that
currently have path trace capability.
end of chapter

5-1
Diagnostic menu 5-
The diagnostic menu enables the user to establish loopbacks on specific
tributary and aggregate ports, and to view loopback settings. The structure of
the configuration menu is shown in Figure 5-1.
Figure 5-1
Diagnostic menu structure
Diagnostic
Loopback #
set_Remote
set_Local
Clr
View
In the above figure, items that have a submenu are shown in bold. Shortcuts
for individual menu items are shown in upper case (see “Command shortcuts”
on page 2-2).

5-2 Diagnostic menu
Diagnostic/Loopback <D L>

This command enables the user to perform loopback tests on specific
tributary ports, clear all loopback tests and to view the results.
Loopbacks
Loopbacks are one method for identifying faulty tributary or aggregate plug
in units. A loopback enables a signal to be routed back towards its source,
either before or after it is processed by a particular plug in unit. By
implementing loopbacks at different places along a signal’s path, a faulty unit
may be identified.
An ‘NE-Loopback_Alarm’ is raised whenever one or more loopbacks are

enabled. The alarm report will not indicate which port the loopback is on. Use
the loopback view command to identify active loopbacks. This alarm clears
once all loopbacks have been disabled.
An overview of loopbacks is given in Figure 5-2 below.
Figure 5-2
Overview of loopbacks
STM-1 Signal
KEY
Remote loopback*
Aggr, Tx Aggr, Rx STM-1
Local loopback* Aggregate
Unit
SIRPIT Serial In Receive
Parallel in Transmit
Payload Manager
SIRPIT
SIRPIT
34/45M (VC-3) Tributary Unit
34M (16x2) Tributary Unit

2M Tributary Unit
STM-1 Tributary
Mux/Demux
Rx Tx 2 Mbit/s Ports 34/45 Mbit/s Port 34 Mbit/s Port
STM-1 Signal 2048 kbit/s Signals 34368 kbit/s Signals 34368 Kbit/s Signal
* Note: For previous releases of the TN-1X, remote loopback = ‘loop-to-line’, and local loopback = ‘loop-to-mux’.

Diagnostic menu 5-3
Loopbacks are supported on the following units:

• 2 Mbit/s (VC-12) and 34/45Mbit/s (VC-3) Tributary Units.
Note: When a local loopback is active on a 2 Mbit/s port, AIS is not
detected on this port.
— Local loopback. Tributary output data is routed to the tributary input.

Tributary output data is still applied to the line interface and the output
from the unit.
— Remote loopback. Tributary input data is routed to the tributary output.
Tributary input data is still processed by the unit.
• 34 Mbit/s (16 x 2M) Tributary Units. Loopbacks for this unit can be
assigned to each of the 2 Mbit/s channels that make up the 34 Mbit/s
signal. The type of loopback established determines the nature of the
loopback.
— Local loopback. Each of the sixteen 2 Mbit/s signals can be looped
back individually. These loopbacks function in the same way as local
loopbacks on the 2 Mbit/s Tributary Unit. #
— Remote loopback. If one or more of the sixteen 2 Mbit/s signals is
selected, the entire 34 Mbit/s signal is looped back.
• STM-1 Tributary/Aggregate Units.
— Local loopback. Parallel output data is routed to the parallel input data
on the external output SIRPIT (Serial In Receive, Parallel In Transmit).
The normal parallel input from the receiver is disabled. This loops back
parallel data to the STM-1 processor. The parallel output data is still
converted to serial data and applied to the transmitter.
— Remote loopback. Serial input data is routed to the serial output on the
external output SIRPIT. The normal serial output from the parallel/
serial conversion is disabled. This loops back data from the receiver to
the transmitter. The serial input data is still converted to parallel data.
Note: Establishing a remote loopback for a tributary with no input signal

will raise a Tributary Output Fail alarm.
CAUTION
Loss of synchronisation
Establishing a local loopback for a tributary that is the active
synchronisation source will result in a loss of synchronisation.
CAUTION
Disconnection of NE and Preside EC-1 Element Controller
Looping back an aggregate channel may disconnect the comms
path between the remote NE and the Preside EC-1 Element
Controller.

5-4 Diagnostic menu
Command details
The commands that access the loopback functionality of the TN-1X are shown
in Figure 5-3, and detailed in Table 5-1.
Figure 5-3
Diagnostic/Loopback menu structure
Diagnostic
Loopback
set_Remote
set_Local
Clr
View
Table 5-1
Diagnostic/Loopback
set_Remote DLR SDH_port | Yes Establishes a remote loopback.

PDH_port
set_Local DLL Establishes a local loopback.
Clr (default) DLC Cancels the loopback.
View DLV N/A no Displays the current test status.
Parameters
S<slot>-<port>

following syntax:
S<slot>-<port>
Autonomous events
The events generated by the described commands are:
• When the status of a loopback changes:
972, <SDH_port|PDH_port>, Loopback = <‘Local’|‘Remote’>,
Status = <‘active’|‘not_active’>, Ulabel = <label>,
date, time

Diagnostic menu 5-5
Reports
The reports generated by the diagnostic command are detailed below.
Diagnostic/Loopback/View
31, Loopback Configuration
311, <SDH_port|PDH_port>, Loopback = <‘Local’|‘Remote’>
For example:
311, S6-1, Loopback = Local
311, S2-1, Loopback = Remote
311, S9-1, Loopback = Local
;
end of chapter

6-1
Maintenance menu 6-
The maintenance menu allows the user to perform a number of manual
operations that affect the operation of the TN-1X.
Figure 6-1
Maintenance menu structure
Maint
Operations
perF_mon
early_Termination
15M
24H
Clock
Both
$
Read
Align
Pps
manual_switch_to_A
manual_switch_to_B
Card_Switch
Force_from
Clear_switch
Figure 6-1 shows the hierarchical structure of the menu tree. Each menu item
in bold has a submenu. The upper case letters are the shortcuts for individual
menu items.

6-2 Maintenance menu
Maint <M>
This command enables the user to terminate a performance monitoring period
prematurely, reset the mux clock, perform a manual path protection switch,
and perform a manual tributary protection switch.
Terminating performance monitoring prematurely

The performance monitoring functionality of the TN-1X enables the user to
record and report on a number of performance criteria. The results are
collected over fifteen minute and/or twenty four hour periods of time (see
“Performance monitoring” on page 4-33). Either or both of these performance
monitoring periods can be terminated prematurely.
When a performance monitoring period is terminated prematurely, the results

are stored by the mux, and a new monitoring period is started automatically. If
there is insufficient room to store the performance monitoring log, the oldest
log is deleted. The mux is able to store a maximum of two 24 hour logs, and a
minimum of sixteen 15 minute logs. As a result, if the premature termination
command is used frequently, it is possible that performance monitoring
results may be lost. To avoid this event, results should be retrieved regularly
from the Element Controller.
Reading and resetting the mux clock

The mux clock stores both the date and the time, and displays these during
login. Both date and time can be read or reset by the user at any time.
Note: Time alignment automatically occurs as part of the connection

establishment between Preside EC-1 Element Controller and NE. Further,
each managed NE, for which an association exists, will have a time
alignment request issued automatically by the Preside EC-1 Element
Controller once every 24 hours.
Manually switching a protected path

Manual path protection switching enables a protected VC-12 or VC-3
payload to be switched manually between aggregates. The same payload is
used on the alternate aggregate when the switch is made. Switching can be
performed to aggregate A, or to aggregate B.
For full details of connection management, see “Connection management” on

page 4-82.
Manually switching a 1:1 protected 34/45M tributary unit

Manual tributary switching enables the VC-3 traffic on a protected 34/45M
tributary unit to be swapped to a protection 34/45M tributary unit. This uses a
1:1 architecture. For full details of this facility, see “Manual 1:1 tributary
protection” on page 4-132.

Command details
The commands that access the TN-1X functionality described above are
detailed in the tables below.
Table 6-1
Maint/Operations/perF_mon/early_Termination
15M MOFTM N/A Yes Terminates the current 15M

performance monitoring period.
24H MOFTH Terminates the current 24H

performance monitoring period.
Both MOFTB Terminates both 15M and 24H

performance monitoring periods.
Table 6-2
Maint/Operations/Clock
Read MOCR N/A No Displays mux date and time.
Align MOCA date Yes Resets mux clock to specified time

time and date.
$
Table 6-3
Maint/Operations/Pps
manual_switch_to_A MOPA PDH_port | Yes Switches specified

SDH_trib_payload | payload to aggregate A.
SDH_aggr_payload
manual_switch_to_B MOPB Switches specified
payload to aggregate A.
Table 6-4
Maint/Card_Switch
Force_from M CS F slot Yes Switches traffic from the

specified slot to the other
tributary in the protection pair.
Clear_switch M CS C Switches traffic to the

specified slot from the other
tributary in the protection pair.

6-4 Maintenance menu
Parameters
• The <date> parameter represents the current date, and has a format of ‘DD/
MM/YYYY’. For example, 01/12/1996.
• The <time>parameter represents the current time, and has a format of
‘HH:MM:SS’. For example, 14:03:59.
• The <PDH_port> parameter identifies a PDH tributary port which is part
of an established protected connection. This takes the following syntax:
S<slot>-<port>

following syntax:
SDH tributary payloads are detailed in “SDH tributary payloads” on page

2-5.
• The <SDH_aggr_payload> field identifies an SDH aggregate payload

following syntax:

page 2-6.

Autonomous events
The autonomous events generated by the commands described are listed
below.
• If the clock time/date is changed:
952, Old_date = <old_date>, Old_time = <old_time>,
User = <user>, <new_date>, <new_time>
• If a premature termination of a 15M or 24H performance monitoring

period is performed:
953, Unscheduled Performance Monitoring Termination
Data Available

• If a manual tributary protection switch is completed successfully:

967, Card_Switch, Switch_from=<slot>, Switch_to=<slot>,
User = <user>, <date>, <time>
• If a manual tributary protection switch fails:

968, Card_Switch_Failure, Trib=<slot>,
Active_Trib=<slot|‘None’>, Reason=<‘Card_Out’|
‘Unexpected_Card’|‘Card_Fault’|’Card_Fail’|
‘INT_Comms_Fail’|‘Wrong_Card’|‘TAM_Out’|‘Wrong_TAM’|
‘Star_Card_Out’|‘Wrong_Star_Card’|
‘Card_Switch_Disabled’|‘ICC2_Not_Running’|
‘VC3_Not_Running’|‘Other_operations_in_progress’|
‘Card_in_SS_hierarchy’>, <date>, <time>
Reports
The reports for these commands are described below.
Maint/Operations/Clock/Read
59, NE time
591, NE_date = <date>, NE_time = <time>
For example:
59, NE time
$
591, NE_date = 31/05/96, NE_time = 13:24:27
;
end of chapter

7-1
View status menu 7-

The view status menu enables the user to display alarms, logs, and a number
of current TN–1X settings.
Figure 7-1
View_status menu structure
View_status
ACtion_log
Alarm_Log
Active_Alarms
PerF_log
Perf_Intermediate
RS_ne
Rs_Oof
MS_ne
Au_pJe
%
HP_ne
Hp_Fe
Tu_pJe
LP_ne
Lp_Fe
Ppi_Cv
Ppi_cRc
24H_PerF_log
Uat_PerF_log
Sync_Source_status
VC_path_status
hp_Path_Trace_status
Lapd_Link_status
Trib_Protect
Payman_Protect
MSp
tn1x_Card_Switch
shown in bold has a submenu. The uppercase letters are the shortcuts for
individual menu items.

7-2 View status menu
View_status <V>
This command enables the user to display reports for alarms, logs, and a
number of TN–1X settings.
Note: The status view menu draws on functionality described in detail

elsewhere in this book. References to the relevant chapters are provided.
Overview of status reports

The view status menu provides reports that relate to the following areas of
TN-1X functionality:
• Viewing the alarm log. A summary of alarms generated during the current
day can be requested by the user.
• Viewing the action log. A summary of non-alarm events generated during
the current day can be requested by the user.
• Viewing active alarms. A summary of all alarms that are active can be
requested by the user.
• Viewing performance logs. Performance logs are generated from the
results of the performance monitoring process (see “Performance
monitoring” on page 4-33). Performance logs can be requested by the user.
• Viewing synchronisation source settings. Synchronisation for the TN-1X
can be taken from a number of sources (see “Synchronisation source
protection” on page 4-51). A summary of the synchronisation settings can
be requested by the user.
• Viewing current paths for low-order protected connections. Each
low-order protected connection has a single aggregate path selected for use
at any time (see “Path protection switching” on page 4-2). A summary of
these can be displayed by the user as part of a VC path status report.
• Viewing high-order path trace status. Each STM-N payload has pair of
path trace strings associated with it (see “High order path tracing” on page
4-70). A summary of these strings can be requested by the user.
• Viewing LAPD link settings. LAPD (Link Access Procedure on the D
Channel) settings control the use of bytes within the section overhead of
STM-N payloads (see “Communications management” on page 4-6). A
summary of LAPD settings can be requested by the user.
• Viewing tributary protection settings. The TN-1X has a single 2 Mbit/s
tributary slot available to provide 1:N tributary protection for up to four
2 Mbit/s tributary units (see “1:N tributary protection” on page 4-109). A
report of the 1:N protection status can be requested by the user.
• Viewing payload manager protection settings. The TN-1X has two slots
reserved for payload manager units, though only one payload manager is
used at any time (see “Payload Manager protection” on page 4-106). A
report identifying the payload manager in use can be requested by the user.
• Viewing multiplexer section protection (MSP) settings. The TN-1X
supports MSP on pairs of either aggregate or tributary units (see
“Multiplexer section protection” on page 4-118). A report of MSP settings
can be requested by the user.

• Viewing manual tributary protection settings. The TN-1X supports 1:1

VC-3 protection on pairs of 34/45M tributary units (see “Manual 1:1
tributary protection” on page 4-132). A report of manual tributary
protection settings can be requested by the user.
Performance logs
Performance logs provide a summary of the errors that occur over a
performance monitoring period (see “Performance monitoring” on page
4-33). Logs are numbered sequentially from 1, though the latest log can
always be accessed with a log number of -1. When a performance log is
requested, the required data is retrieved from the performance results stored
on the NE. This data is then formatted and displayed as a performance log.
The number of performance logs that the TN-1X can store is variable, as it
depends upon the size of individual logs. When more performance
monitoring points are enabled, the resulting logs are larger.
Generating performance logs

Performance logs are generated and displayed by the following commands:
• perf_Log. This command displays performance information for a fifteen
minute monitoring period. A log number must be specified.
• 24h_PerF_log. This command displays performance information for a
twenty four hour monitoring period. A log number must be specified.
• perf_Intermediate. This command displays live performance counts from
the current period, for a specified PMP. This includes both fifteen minute
and twenty four hour periods. The displayed counts are NOT reset, and
processing of this period continues uninterrupted. %
• Uat_PerF_log. This command displays unavailable time information for
both fifteen minute and twenty four hour monitoring periods.
Performance log formatting

Like the responses received from ‘view’ commands, logs use a header line and
body line format. The header lines used are listed below:
44, Intermediate Performance Summary
47, Performance Monitoring Log
Body lines divide into a number of categories:

• The RS, MS, LP, LP-FE, HP, HP-FE and PPI-CV PMPs use the following
body lines:
431,Status,Log_type,Report,Duration,End_Date,End_Time,
Start_Date,Start_Time
432,<report_status>,<‘15M’|‘24H’|‘UAT’>,<report_no>,
<assessed_seconds>,<end_date>,<end_time>,
<start_date>,<start_time>
433,Instance,PMP,ES,SES,BBE,UAS,Basis,AS,Traffic,
User_label
434,<PDH_port|SDH_AU4|SDH_port>,<PMP>,<ES>,<SES>,
<BBE>,<UAS>,<PM_Basis>,<AS>,<traffic_type>,<label>

Where:
— <report_no> is the report number.
— <report_status> is a two letter status. These are listed in Table 7-1.
Table 7-1
Update log report status codes
Report status
Description
First Second
F <Second> First report since a mux reboot.
O <Second> Reports overwritten since the last collection.
N <Second> Normal report (that is, some values in report).
<First> C Early termination due to CLUI request.
<First> A Normal minute window.
<First> S Time remaining in window after early termination.
<First> R Time remaining in window after time change.
Most reports are denoted ‘NA’. The first report after a mux reboot is
‘FA’. A report delivered after an early termination is ‘NC’.
— <assessed_seconds> is the actual period of assessment.
— <ES> is the Errored Seconds count.
— <SES> is the Severely Errored Seconds count.
— <BBE> is the Background Bit Errors count.
— <UAS> is the Unavailable Seconds count.
— <PM_Basis> is either ‘P’ (BIP) or ‘B’ (Block).
— <AS> is the number of Assessed Seconds.
— <traffic_type> identifies the nature of the affected unit or traffic (see
Table 2-6 on page 2-12).
— <label> is the user label.
— The date and time parameters are the timestamping for the report.
Note: During periods of Unavailable Time (UAT), the ES, SES and BBE
statistics are not recorded. The start of UAT is indicated by ten consecutive
SESs. Until this ten seconds is complete, however, it is unclear whether the
ES, SES and BBE figures accumulated need to be recorded. As a result,
there is a ten second delay in all performance monitoring timestamps.

• The RS-OOF, AU-PJE and TU-PJE PMPs use the following body lines:
437,Instance,PMP,Total_count,-ve_count,AS,Traffic,
User_label
438,<PDH_port|SDH_AU4|SDH_port>,<PMP>,<total_count>,
<neg_count>,<assessed_seconds>,<traffic_type>,
<user_label>
Where:
— <report_status> is a two letter status. These are listed in Table 7-1.
— <total_count> is the number of pointer adjustments, both positive and
negative.
— <neg_count> is the number of negative pointer adjustments.
— <assessed_seconds> is the actual period of assessment.
— <traffic_type> is the hardware to which the log line applies (see
— <user_label> is the relevant user label.
• Unavailable time logs use the following body lines:

431,Status,Log_type
432,<report_status>,UAT
435,Instance,PMP,Type,Traffic,User_label,Date,Time
436,<PDH_port|SDH_AU4|SDH_port>,<PMP>,<‘Start’|‘End’>,
<traffic_type>,<user_label>,<date>,<time>
Where:
— <report_status> is a two letter status. These are listed in Table 7-1. %
— <traffic_type> is the hardware to which the log line applies (see
— <user_label> is the relevant user label.
Examples of performance logs are given in “Reports” on page 7-8.
Ordering of performance log lines

Within each performance log, lines are ordered in the following way:
• Lines are first ordered by instance. Instances are ordered as follows:
— Each instance is ordered by slot number, starting from 1.
— Each slot is sorted by port number, starting from 1.
— Each port is sorted by KLM number (K111 to K373, then K100, K200
and K300).
• Groupings of identical instances are then sorted by PMP alphabetically.

Command details
The commands that access the view status functionality of the TN-1X are
shown in the tables below.
Table 7-2
View_status
Alarm_Log V AL N/A No Reports all of today’s

alarm events.
ACtion_log V AC Reports all of today’s

non-alarm events.
Active_Alarms V AA Reports all alarms that

are active currently.
PerF_log V PF log_no | -1 Reports a specific 15

minute performance
monitoring log.
24H_PerF_log V HPF Reports a specific 24

hour performance
monitoring log.
Uat_PerF_log V UPF Reports a specific

unavailable time log.
Perf_Intermediate V PI See Table 7-3.
Sync_Source_status V SS N/A No. Reports the

synchronisation source
status.
VC_path_status V VC PDH_slot | Reports the virtual

PDH_port container path status for
PDH_aggr_payload a specified PDH port/slot.
(see note)
hp_Path_Trace_status V PT SDH_AU4 Reports the received path

(see note) trace status for a specific
high-order path.
Lapd_Link_status V LL N/A Reports the LAPD link

status.
Trib_Protect V TP Reports the 1:N trib

protection status.
Payman_Protect V PP Reports the payload

manager protection
status.
MSp V MS SDH_port Reports the multiplexer

(see note) section protection status.
tn1x_Card_Switch V CS slot Reports the manual

tributary protection
status.
Note: If this parameter is not provided, all possible information is displayed.

Table 7-3
View_status/Perf_Intermediate
RS_ne V PI RS SDH_port No Each of these commands displays

the current performance
Rs_Oof V PI RO monitoring counts for the specified
port or high-order path. This will
MS_ne V PI MS
reflect the PMP to which the
Au_pJe V PI AJ SDH_AU4 command relates.
HP_ne V PI HP
Hp_Fe V PI HF
Tu_pJe V PI TJ PDH_port
LP_ne V PI LP
Lp_Fe V PI LF
Ppi_Cv V PI PC
Ppi_cRc V PI PR
Parameters

page 2-6.
%
S<slot>-<port>

SDH high-order payloads are detailed in “SDH high order payloads” on

page 2-7.
following syntax:
S<slot>-<port>

• The <log_no> parameter identifies a set of performance monitoring

results. The oldest set of results will have a log number of one. The next set
will have a log number of two, and so on.
Note: The latest log number can also be referred to by a log number of -1.

— ‘S2’. This represents the protection pair comprised of slots 2 and 4.
— ‘S9’. This represents the protection pair comprised of slots 9 and 11.
Autonomous events
There are no autonomous events that relate to the view status functionality.
Reports
The reports generated by the commands described are listed below.
View_status/Alarm_Log
71, Alarm Log
7XX, <alarm>, <instance>, <alarm_status>, <alarm_severity>,
<alarm_category>, <unique_number>, <traffic_type>,
<user_label>, <date>, <time>
Where:
• <alarm> is the alarm event.
• <instance> is the affected unit or traffic. These are identified by a slot, port,
or payload reference, and use the same syntax as the equivalent command
parameters (see “Parameters” on page 2-4).
Note 1: TAMs are identified by slot numbers. The TAMs for slot 2 are
Note 2: The three Multiplexer Section Protection (MSP) alarms are always
reported against the protection channel. MS and RS alarms that relate to
MSP channels are always reported against the affected channel. All other
alarms related to MSP channels are reported against the working channel.
• <traffic_type> identifies the traffic type (see Table 2-6 on page 2-12).
• <alarm_status> is Present or Cleared.
• <alarm_severity> is (C)ritical, (M)ajor, (m)inor, or Disconnect (X).
• <alarm_category> is (P)rompt, (D)eferred, (I)nstation, or (W)arning.
• <unique_number> is between 1 and 65535.
• <user_label> is the fifteen character user label.
• <date> is the date on which the alarm was generated.
• <time> is the timestamp for the alarm.

For example:
70, Alarm Log
711,INT-NE-Config_bp_mismatch,S14,Present,C,P,0010,SRC,,
13/03/1997,08:30:46
711,INT-NE-Config_Corrupt,S14,Present,C,P,0011,SRC,,
13/03/1997,08:30:46
;
View_status/ACtion_Log
70, Action Log
7XX, <event>, <date>, <time>
Where:
• <event> is the non-alarm event.
For example:
70, Action Log
761,Event=Login, User=oper1, Ident=jfk, 13/03/1997,08:33:45
761,Event=Disconnect, User=oper1, Ident=jfk, 13/03/1997,
08:58:43
;
View_status/Active_Alarm
51, Alarm Status
511, <alarm>, <instance>, <alarm_status>, <alarm_severity>,
<user_label> %
Where:
• <event> is the alarm event.
Note: TAMs are identified by slot numbers. The TAMs for slot 2 are
• <traffic_type> identifies the nature of the affected unit or traffic (see

• <alarm_status> is (C)ritical, (M)ajor, (m)inor, or Disconnect (X).
• <alarm_severity> is (P)rompt, (D)eferred, (I)nstation, or (W)arning.

For example:
51, Alarm Status
511, HP-TIM, S7-1-J1, present, C, X, 178, A-1o, Cust_1
511, PPI-LOS, S2-1, present, C, X, 369, 2M75, Cust_1
511, PPI-LOS, S2-3, present, C, X, 371, 2M75, Cust_1
;
View_status/<performance log>
Performance logs use the entries described in “Performance logs” on page 7-3.
A typical 15 minute performance log is shown below:
47,Performance Monitoring Log
431,Status,Log_type,Report,Duration,End_Date,End_Time,Start_Date,Start_Time
432,NA,15M,9853,900,19/05/1997,08:30:00,19/05/1997,08:15:00
433,Instance,PMP,ES,SES,BBE,UAS,Basis,AS,Traffic,User_label
434,S2-1,LP,0,0,0,0,p,901,2M75,S2-1
434,S2-2,LP,0,0,0,0,p,901,2M75,S2-2
434,S2-3,LP,0,0,0,0,p,901,2M75,S2-3
434,S2-4,LP,0,0,0,0,p,901,2M75,S2-4
434,S6-1,RS,0,0,0,0,p,901,A-1o,S6-1
434,S6-1,MS,0,0,0,0,p,901,A-1o,S6-1
434,S6-1-J1,HP,0,0,0,0,p,901,A-1o,
434,S6-1-J1,HP-FE,0,0,0,0,p,901,A-1o,
434,S7-1,RS,0,0,0,0,p,901,B-1e,S7-1
434,S7-1,MS,0,0,0,0,p,901,B-1e,S7-1
434,S7-1-J1,HP,0,0,0,0,p,901,B-1e,
434,S7-1-J1,HP-FE,0,0,0,0,p,901,B-1e,
437,Instance,PMP,Total_count,-ve_count,AS,Traffic,User_label
438,S2-1,TU-PJE,31,0,901,2M75,S2-1
438,S2-2,TU-PJE,31,0,901,2M75,S2-2
438,S2-3,TU-PJE,31,0,901,2M75,S2-3
438,S2-4,TU-PJE,31,0,901,2M75,S2-4
438,S6-1,RS-OOF,0,0,901,A-1o,S6-1
438,S7-1,RS-OOF,0,0,901,B-1e,S7-1
;
A typical 24 hour performance log is shown below:

431,Status,Log_type,Report,Duration,End_Date,End_Time,Start_Date,Start_Time
432,NR,24H,790,86317,18/05/1997,14:00:00,17/05/1997,14:00:00
433,Instance,PMP,ES,SES,BBE,UAS,Basis,AS,Traffic,User_label
434,S2-1,LP,0,0,0,0,p,86398,2M75,S2-1
434,S2-2,LP,0,0,0,0,p,86398,2M75,S2-2
434,S2-3,LP,0,0,0,0,p,86398,2M75,S2-3
434,S2-4,LP,0,0,0,0,p,86398,2M75,S2-4
434,S6-1,RS,0,0,0,0,p,86397,A-1o,S6-1
434,S6-1,MS,0,0,0,0,p,86397,A-1o,S6-1
434,S6-1-J1,HP,0,0,0,0,p,86399,A-1o,
434,S6-1-J1,HP-FE,0,0,0,0,p,86399,A-1o,
434,S7-1,RS,0,0,0,0,p,86396,B-1e,S7-1
434,S7-1,MS,0,0,0,0,p,86396,B-1e,S7-1
434,S7-1-J1,HP,0,0,0,0,p,86399,B-1e,
434,S7-1-J1,HP-FE,0,0,0,0,p,86399,B-1e,
437,Instance,PMP,Total_count,-ve_count,AS,Traffic,User_label
438,S2-1,TU-PJE,3887,0,86398,2M75,S2-1
438,S2-2,TU-PJE,3887,0,86398,2M75,S2-2
438,S2-3,TU-PJE,3887,0,86398,2M75,S2-3
438,S2-4,TU-PJE,3887,0,86398,2M75,S2-4
438,S6-1,RS-OOF,0,0,86397,A-1o,S6-1
438,S7-1,RS-OOF,0,0,86396,B-1e,S7-1
;

A typical unavailable time log is shown below:

431,Status,Log_type
432,NA,UAT
435,Instance,PMP,Type,Traffic,User_label,Date,Time
436,S2-1,LP,Start,2M75,S2-1,19/05/1997,08:45:34
436,S2-1,LP-FE,End,2M75,S2-1,19/05/1997,08:46:20
436,S4-1,LP,Start,2M75,S4-1,19/05/1997,08:45:33
436,S4-1,LP-FE,End,2M75,S4-1,19/05/1997,08:46:20
436,S6-1,RS,Start,A-1o,S6-1,19/05/1997,08:45:04
436,S6-1,RS,End,A-1o,S6-1,19/05/1997,08:46:16
436,S6-1-J1,HP,Start,A-1o,,19/05/1997,08:45:03
436,S6-1-J1,HP,End,A-1o,,19/05/1997,08:46:16
436,S7-1,RS,Start,B-1e,S7-1,19/05/1997,08:45:33
436,S7-1,RS,End,B-1e,S7-1,19/05/1997,08:46:20
436,S9-1,LP,Start,2M75,S9-1,19/05/1997,08:45:34
436,S9-1,LP-FE,End,2M75,S9-1,19/05/1997,08:46:20
436,S11-1,LP,Start,2M75,S11-1,19/05/1997,08:45:34
436,S11-1,LP-FE,End,2M75,S11-1,19/05/1997,08:46:20
;
View_status/Sync_Source_status
55, Sync Source Status
551, <SDH_port|PDH_port|‘INT’|‘EXT’>,
Sync_src_hierarchy_level = <‘1’|‘2’|‘3’|‘4’>,
Sync_src_state = <‘Standby’|‘Failed’|‘Reference’>,
actual_ql = <QL_value>, derived_ql = <QL_value>,
no_revert_flag = ‘Off’
552, Fail_reason=<‘slot_not_active’|‘no_sync’|
‘trib_sync_line_fail’|‘ql_do_not_use’>
554, current_hierarchy_level = <‘1|‘2’|‘3’|‘4’|‘5’>,
current_sync_src = <SDH_port|PDH_port|’INT’|’EXT’>
Where:
•
•
<SDH_port> is an SDH port which is a source of synchronisation.
<PDH_port> is a PDH port which is a source of synchronisation.
%
• <QL_value> is a Quality Level value between 1 and 15.
For example:
55,Sync Source Status
551,INT,SS_hierarchy_level=4,SS_state=Standby
551,EXT,SS_hierarchy_level=3,SS_state=Standby
551,S6-1,SS_hierarchy_level=1,SS_state=Failed,
actual_ql=unknown
552,S6-1, fail_reason=slot_not_active
551,S7-1,SS_hierarchy_level=2,SS_state=Reference,
actual_ql=15551,S2-1, SS_hierarchy_level=4,
SS_state=Standby
554,Current_hierarchy_level=2,Current_sync_src=S7-1
;

View_status/VC_path_status
56, VC Path status
561, <PDH_port>, Path_src = <SDH_aggr_payload>
Where:
• <PDH_port> is the PDH destination of a drop connection.
• <SDH_aggr_payload> is the STM-N aggregate source of the connection.
For example:
56, VC Path status
561, S2-1, Path_src = S6-1-J2-K121
561, S2-2, Path_src = S6-1-J2-K122
561, S2-3, Path_src = S6-1-J2-K123
561, S2-4, Path_src = S6-1-J2-K131
561, S2-5, Path_src = S6-1-J2-K132
561, S2-6, Path_src = S6-1-J2-K133
;
View_status/hp_Path_Trace_status
The entries used by this command are listed below:
581, <SDH_AU4>, Rx_state = <‘PT_OK’|‘Mismatch’|
‘Misaligned’>,Path_trace_rx = <trace_string>,
Rx_crc = <trace_CRC>
581, <SDH_AU4> Undetermined
Where:
• <SDH_AU4> is the high-order payload with which the path trace value is
associated.
• <trace_string> is the received path trace string.
• <trace_CRC> is the received cyclic redundancy check.
For example:
581, S6-1-J1, Rx_state = PT_OK, Path_trace_rx = From_C1,
Rx_crc = 64H
581, S7-1-J1, Rx_state = PT_OK, Path_trace_rx = To_C1,
Rx_crc = 64H
;

View_status/Lapd_Link_status
62, LAPD Link Status
621, <SDH_port>, Lapd_link_state_RS =
<‘Connected’|‘Failed’|‘Off’>
621, <SDH_port>, Lapd_link_state_MS =
<‘Connected’|‘Failed’|‘Off’>
622, <SDH_port>, Lapd_link_current_auto_mode_RS =
<‘Network’|‘User’>
622, <SDH_port>, Lapd_link_current_auto_mode_MS =
<‘Network’|‘User’>
623, <SDH_port>, Lapd_link_service_RS = <‘On’|‘Off’|‘Auto’>
623, <SDH_port>, Lapd_link_service_RS = <‘On’|‘Off’|‘Auto’>
;
Where:
• <SDH_port> is the STM-N aggregate, or STM-1 tributary port to which
the LAPD settings apply.
For example:
62, LAPD Link Status
621, S6-1, Lapd_link_state_RS = Connected
622, S6-1, Lapd_link_current_auto_mode_RS = Network
623, S6-1, Lapd_link_service_RS = Auto
621, S7-1, Lapd_link_state_MS = Off
621, S9-1, Lapd_link_state_MS = Off
%
;
View_status/Trib_Protect
566, Trib Protection Status
567, <slot>, Protected_trib = <‘slot’|‘no_card_protected’> ,
Status = <‘Protecting’|‘WTR’>
;
Where:
• <slot> identifies the card whose traffic is being protected by the 1:N
protection trib in slot 3. This can be S2, S4, S9 or S11.
For example:
566, Trib Protection Switching Status
567, S3, Protected_trib = S2, Status = WTR
;

View_status/Payman_Protect
564, Payload Manager Switching Status
565, Active_PM = <slot>
Where:
• <slot> identifies the slot in which the active payload manager is located.
For example:
564, Payload Manager Switching Status
565, Active_PM = S5
View_status/MSp
64, Multiplexer Section Protection Status
641, <SDH_port>, MSP_switch_from = (<SDH_port>,
Ch_no=<value>) |’None’
642, <SDH_port>, Act_Req = <‘K1_No_Request’|
‘K1_Wait_To_Restore’|’K1_Manual_Switch’|’K1_SD_Low’|
‘K1_SD_High’|’K1_SF_Low’|’K1_SF_High’|
‘K1_Forced_Switch’|’K1_Lockout’>,
AR_Port = <port_inst>, AR_Orig = ‘Local’|’Remote’
643, <SDH_port>, Pend_Req = <‘K1_No_Request’|
‘K1_Wait_To_Restore’|’K1_Manual_Switch’|’K1_SD_Low’|
‘K1_SD_High’|’K1_SF_Low’|’K1_SF_High’|
‘K1_Forced_Switch’|’K1_Lockout’>,
PR_Port = <SDH_port>, PR_Orig = <‘Local’|’Remote’>
Where:
• <SDH_port> is the STM-N aggregate, or STM-1 tributary port to which
the LAPD settings apply.
For example:
64,Multiplexer Section Protection Status
641,S7-1, MSP_switch_from = S6-1, Ch_no = 1
642,S7-1, Act_Req = K1_Forced_Sw, AR_Port = S6-1,
AR_Orig = Local
643,S7-1, Pend_Req = K1_SD_High, PR_Port = S6-1,
PR_Orig = Local
;

View_status/tn1x_Card_Switch
67, Card Switch Status
671, <slot>, Card_Switch=<‘ENABLED’|‘DISABLED’>,
Active_Trib=<slot_inst|‘None’>
For example:
67, Card Switch Status
671, S2, Card_Switch=ENABLED, Active_Trib=S4
671, S9, Card_Switch=ENABLED, Active_Trib=S11
;
end of chapter

8-1
Session menu 8-
The session menu enables the user to view and configure many aspects of the
current User Interface (UI) session.
Note: Changes made within this menu exist for the current session only,
and revert to defaults for each new user.
The menu hierarchy for the session functionality of the TN-1X is shown in
Figure 8-1, and detailed in the sections that follow.
Figure 8-1
Session menu structure
Session
View_other_users
Inventory
Inv_Clevel
Get_mux_status
Unsolicited
oN
Off
display_Alarms_only
display_oThers_only
Mode
View
&
suppress_Menu_and_Warning
suppress_Warning
Full_dialogue
View
Auto_logout
Set
View
misC
Echo_oN
Echo_Off
View
Punchthrough
External
Kill_Ext
View
Each menu item in bold type has a submenu. The upper case letters shown are
the shortcuts for individual menu items.

8-2 Session menu
Session <S>
This command enables the user to view and configure settings for the current
UI session.
Note: Changes made within this menu exist for the current session only,
and revert to defaults for each new user.
Session characteristics
There are a number of aspects of the current UI session that can be viewed and
changed by the user. These are:
• Viewing other users on the mux. There are a four sessions that are available
for mux users to log into (see “Accessing the UI application software” on
page 3-1). The user can request a report to show who is currently logged
into these sessions.
• Viewing mux inventory information. The user can request a report that
identifies several hardware aspects of the plug-in units and TAMs of the
TN-1X.
• Viewing control level information. The user can request a report that lists
the control levels of a plug-in unit within the TN-1X.
• Viewing mux status information. The user can request a report that
identifies software aspects of the TN-1X. This includes information such
as the mux clock settings, software versions, loopbacks, and active alarms.
This information is always displayed when a user logs into the TN-1X (see
“Logging in” on page 3-1).
• Controlling autonomous (unsolicited) messages. Unsolicited messages are
generated by the TN-1X and sent to all logged in users. These messages
divide into alarms and events (see “Autonomous messages” on page 2-11).
The user can configure whether alarms and events are displayed.
• Controlling menus and confirmations. The user interface assists the
selection of options by displaying possible items as a menu. Once a
selection is made by the user, a number of options request confirmation
before they will execute. The user can configure whether menus and
confirmations are used.
• Controlling the automatic logout period. Inactive TN-1X user interface
sessions for some user classes will terminate automatically after fifteen
minutes (see “Accessing the UI application software” on page 3-1). This
default period can be adjusted to between one and sixty minutes by the
user. A value of zero inhibits automatic logout.
• Controlling the echoing of characters back to the local terminal port. Echo
off means that entered characters are not echoed back to the terminal, while
echo on (default) means that they are echoed.
• Controlling Punch-Through session.
Note: The Punch-Through feature is for future use and is not a supported
feature at Release 9.
The above operations are detailed in the sections that follow.

Session menu 8-3
Command details
The commands that access the session functionality of the TN-1X are shown
the tables below.
Table 8-1
Session
View_other_users SV N/A No Displays a list of all users currently

logged in.
Inventory SI Displays current mux data. This

includes PEC code, serial number,
card type, date of manufacture,
checksum for main and connector
(backplane) cards, extension card
and address information.
Inv_Clevel S IC slot Displays the control level information

for the plug-in unit in the specified
slot.
Get_mux_status SG N/A Displays NE time, inventory data,

logged in users, software and
configuration versions; any tests or
loopbacks in progress and any
active alarms
Unsolicited SU See Table 8-2.
Mode SM See Table 8-3.
Auto_logout SA See Table 8-4.
misC SC See Table 8-5.
Punchthrough SP See Table 8-6.
Table 8-2 &

Session/Unsolicited
oN SUN N/A No Enables unsolicited system

(default) messages for this user.
Off SUO Disables unsolicited system

messages for this user.
display_Alarms_only SUA Enables the display of alarm

messages (no other
messages).
display_oThers_only SUT Enables the display of all

messages (except alarms).
View SUV N/A No Displays unsolicited message

settings.

8-4 Session menu
Table 8-3
Session/Mode
suppress_Menu_and_ S M MW N/A No Disables menus, and “Are you

Warning sure?” confirmations.
suppress_Warning SMW Disables warning messages

only. Displays menus.
Full_dialogue SMF Enables menus and warnings.

(default)
View SMV N/A No Displays mode settings.
Table 8-4
Session/Auto_logout
Set SAS logout_time No Set the auto logout idle time for the
current user for this session, where:
Range: 0 to 60 minutes.
Step: 1 minute.
Default: 15 minutes.
0 inhibits auto logout.
View SAV N/A No Displays the auto logout settings.
Table 8-5
Session/misC
echo_oN SCN N/A No Enables echoing of characters back

to the local terminal port.
echo_Off SCO Disables echoing of characters back

to the local terminal port.
View SCV N/A No Displays mode settings.

Session menu 8-5
Table 8-6
Session/Punchthrough
External SPE <<slot_inst> | No Enables punch-through feature.

<port_inst> |
external |
CAT >
see Note
Kill_Ext S P KE N/A No Terminate punch-through session.
View SPV N/A No Displays current punch-through

sessions.
Note: Parameter options <slot_inst>, <port_inst>, external & CAT may be totally omitted on an NE
that contains only one RS-232 port.
Parameters
• The <logout_time> parameter is a number between 0 and 60. The
<logout_time> represents the number of minutes before automatic logout
will occur. A <logout_time> value of zero inhibits the auto logout feature.
Responses
There are no responses to invalid actions for the described commands.
Autonomous events
There are no autonomous events associated with the described commands.
Reports
&
Session/View_other_users
52, Open Sessions
521, Uname = <user_name>, User = <user>
Where:
• <user_name> is the login name of the user. This will be ‘viewr’, ‘oper1’,
‘oper2’ or ‘nortl’.
• <user> is the identification ID provided at login.
Note 1: For a full explanation of the above parameters, see “Getting

started” on page 3-1.
Note 2: When the TN-1X is managed by the Presdie EC-1 Element
Controller, additional users will be present. These cannot be affected by the
user. The ‘ec_vs’ user is the EC viewer, ‘ec_cm’ is the EC configurer,
‘ec_as’ is an internal EC user, and ‘ec_se’ is an EC system engineer.

8-6 Session menu
For example:
52, Open Sessions
521, Uname = oper1, User = mark
521, Uname = oper2, User = jim
;
Session/Inv_Clevel
534, Control Level
535, <slot>, cl_entry = <entry_no>, clevel = <control_level>
Where:
• <slot> the slot specified for the report.
• <entry_no> is the entry number for the plug in unit in the specified slot.
• <control_level> is a control level for the plug in unit in the specified slot.
For example:
534, Control Level
535, S2, cl_entry = 1, clevel = 1
;

Session menu 8-7
Session/Inventory
53, Inventory
531, S0, Address = <address>
532, <slot>, NTPEC = <code>, Card_type = <card_type>,
Serial_no = <serial_no>
533, <slot>, Manf_date = <manf_date>,
Chksum = <‘Valid’|‘Invalid’>
Where:
• <slot> identifies the slot a specific card is in. The backplane is nominally
regarded as being slot zero (S0).
• <address> is the address of the backplane.
• <code> is an order code for the plug-in unit or TAM. Typically, this is an
eight character code. Where thirteen character codes are used, the first five
characters are omitted. That is, 25UJU00750GVA becomes 00750GVA.
Newer cards will have the highest PCS level on the card appended to this
code as a two digit suffix. For example, the NTKD17AB TAM with a PCS
level of 1 has a code of ‘NTKD17AB01’.
• <card_type> identifies the type of the card.
• <serial_no> is the serial number of the card.
• <manf_date> is the date of manufacture for the card, format WWYY. For
example, ‘2398’.
• <checksum> indicates whether the card’s checksum is valid or invalid.
For example:
53,Inventory
531,S0, Address=000075403a43
&
532,S17, NTPEC = NTKD17AA01, Card_type = 34/45M_TAM,
Serial_no = ,
532,S20, NTPEC = NTKD17AB01, Card_type = 34/45M_TAM_PROT,
Serial_no = ,
532,S24, NTPEC = NTKD14AA170, Card_type = V2_TAM-75ohm,
Serial_no = ,

8-8 Session menu
Session/Get_mux_status
The entries used by this command (in order) are listed below.
59, NE Time
591, NE_date = <date>, NE_time = <time>
531, S0, Address = <address>

532, <slot>, NTPEC = <code>, Card_type = <card_type>,
Serial_no = <serial_no>
533, <slot>, Manf_date = <manf_date>,
Chksum = <‘Valid’|‘Invalid’>
52, Open Sessions

521, Uname = <user_name>, Ident = <user>
57, Software and Config Table Status

571, Active_SW = <version>, Active_bank = <‘A’|‘B’>,
Standby_SW = <version|‘N/A’>
572, Active_CFG = <version>, Standby_CFG = <version|‘N/A’>
573, SW_upgrade_status = <‘Stable’|‘Ready-to-activate’|
‘Ready-to-commit’|‘Download-in-progress’>
574, Cnfg_upgrade_status = <‘Stable’|‘Ready-to-activate’|
‘Ready-to-commit’>

311, <SDH_port|PDH_port>, Loopback = <‘Local’|‘Remote’>
51, Alarm Status

511, <alarm>, <instance>, <alarm_status>, <alarm_severity>,
<user_label>, <date>, <time>
Where:
• <SDH_port> is the SDH port to which a loopback applies.
• <PDH_port> is the PDH port to which a loopback applies.
• <version> is a software version number.
• <alarm> is the alarm event.
• <alarm_status> is Present or Cleared.
• <alarm_severity> is (C)ritical, (M)ajor, (m)inor, or Disconnect (X).
• <alarm_category> is (P)rompt, (D)eferred, (I)nstation, or (W)arning.
• <traffic_type> identifies the nature of the affected unit or traffic (see
• <date> is the date on which the alarm was generated.
• <time> is the timestamp for the alarm.

Session menu 8-9
For example:
59,NE Time
591,NE_date=09/05/1997,NE_time=09:57:39
53,Inventory
531,S0, Address=000075403a43
532,S17, NTPEC = NTKD17AA01, Card_type = 34/45M_TAM,
Serial_no = ,
532,S20, NTPEC = NTKD17AB01, Card_type = 34/45M_TAM_PROT,
Serial_no = ,
532,S24, NTPEC = NTKD14AA170, Card_type = V2_TAM-75ohm,
Serial_no = ,
52,Open Sessions
521,User=nortl,Ident=mark

571,Active_SW=X7.1A,Active_bank=A,Standby_SW=N/A
572,Active_CFG=7.0C, Standby_CFG=7.0C
31,Loopback Configuration &

51,Alarm Status
511,NE-Wrong_Card,S1,Present,C,P,0015,ICC2,
511,NE-Card_Out,S3,Present,C,P,0374,2M75,
511,NE-Wrong_Card,S11,Present,C,P,1468,STM1o,
511,SYNC-Src_Not_Primary,S14,Present,C,P,0009,SRC,
;

8-10 Session menu
Session/Unsolicited/View
35, Display Configuration for Current Session
351, Display_alarms = <‘On’|‘Off’>,
Display_others = <‘Off’|‘On’>
For example:
35, Display Configuration for Current Session
351, Display_alarms = On, Display_others = Off
;
Session/Mode/View
523, Dialogue Mode
524, Session_mode = <‘Full_dialogue’|‘Suppress_warnings’|
‘Suppress_menu_and_warning’>
For example:
523, Dialogue Mode
524, Session_mode = Full_dialogue
;
Session/Auto_logout/View
38, Auto Logout Time for Current Session
381, Auto_logout_time(minutes) = <minutes>
For example:
38, Auto Logout Time for Current Session
381, Auto_logout_time(minutes) = 20
;
Session/misC/View
523, Local Terminal Echo
524, Local_terminal_echo=<‘On’|‘Off’>
For example:
523, Local Terminal Echo
524, Local_terminal_echo=On
;
Session/Punchthrough/View
295, Punchthrough Sessions
2951,Uname=<user_name>,User=<user>,<External|Internal>,
Target=<<slot_inst>|<port_inst>|external|CAT>,
Start_date=<date>,Start_time=<time>
Where:
• <user_name> is the login name of the user.

Session menu 8-11
• <user> is the identification ID provided at login, and External or Internal.

• <slot_inst> is TBD
• <port_inst> is TBD
• <date> is the start date of the Punchthrough session.
• <time> is the start time of the Punchthrough session.
For example:
295, Punchthrough Sessions
2951, Uname=ec_se, User=Wu, External, Target=CAT,
Start_date=02/01/00, Start_time= 05:25:18
;
In the event that multiple punch-through sessions are active, line 2951 is
repeated as often as needed.
end of chapter
&

9-1
Administration menu 9-
The administration menu enables the user to perform a number of processes
relating to application software, the configuration table, and user
management. The menu is shown in Figure 9-1 below.
Figure 9-1
Administration menu structure
Admin
Sw
DoWnload
Abort_Download
Switch_to_Loaded
Switch_to_Original
Warm_Restart
Cold_Restart
CoMmit
BackOut
CoPy
View
Cnfg_tbl
BackUp
REstore
Switch_to_Original
Switch_to_Restored
CoMmit
BackOut
Impose_Config
DeFault
Force_Detached
'
View
User
change_Pswd
Bchange_pswd
Secure
shown in bold has a submenu. The upper case letters are the shortcuts for
individual menu items.
Each administration submenu is described in detail later in this chapter.

9-2 Administration menu
Admin/Sw <A S>

This command enables the user to access the TN-1X application software
management functionality.
Overview of application software

All TN-1X software is stored on the mux’s Subrack Controller (SRC). There
are two types of software:
• Foundation software. This includes the operating system, and the
hardware/software initialisation code. The software is installed on the SRC
as firmware when it is manufactured, and cannot be updated. This software
is run automatically when the TN-1X is powered up.
• Application software. This controls the operation of installed plug-in units.
The TN-1X stores two copies of the application software using a pair of
software banks in flash memory. The application software is started by the
foundation software when the TN-1X is powered up.
Note: If no application software is stored in the TN-1X, it must be loaded
before the mux can begin operation (see “Downloading application
software” on page 9-4).
The software bank containing the application software currently in use is

referred to as the ‘active’ bank. The other bank is referred to as the ‘inactive
bank’. These banks will contain the same version of software, except during
software upgrade.
New application software can be downloaded by the user. This is always

stored in the inactive software bank. Once software is downloaded
successfully, the user is able to test it before deciding whether to commit this
version to both banks, or to revert the inactive bank to its original state.
Note: A software download should not be requested while a software

download, NE configuration backup or NE configuration restoration is
already in progress. This operation should also not be requested during
periods when automatic NE backups might occur.
ATTENTION
The internal bus of the TN-1X is mapped differently at R9 than at earlier
releases. While this does not affect the operation of current connections,
future connections may not benefit from improved Release 9 performance
and may also generate traffic hits to existing connections as a result of adding
new connections. Customers should refer to Engineering Bulletin -
Connections Recommendations SDH_E155 for advice on how to proceed
after upgrade This will be dependant on the previous release level & traffic
configuration.
Refer to “Defragmenting the TN-1X internal bus” on page 4-84 for details of
this operation.
The software download process is shown in Figure 9-2.

Figure 9-2
An overview of the software download mechanism
Start Both configuration tables contain the original

software.
New software
available
The active bank contains the original

Download new
software, and the inactive bank now contains
software to
the new software.
inactive bank
The two versions of the software change

Switch to new places. While the new software is being
software tested, the original software is in the inactive
software bank.
Test new
software
Is new Yes
software During normal operation, it is important
OK? that both banks contain the same software.
If these are different, this can interfere with
No the operation of configuration functions.
If the new software is satisfactory, the user

Switch back to
can decide to commit to it. If the new
original software
software proves unsatisfactory, then the
user must back out, reverting to the original
software. In either case, the software in
Backout
Commit to new
software
both banks is the same version.
'
Old software in New software

both tables in both tables
Finish

Software status
There are five states associated with the software banks of the TN-1X:
• Stable. Both software banks contain the same version of software.
• Ready_to_activate. New software has been downloaded, and this is in the
inactive bank.
• Ready_to_commit. New software has been downloaded, and this is in the
active bank.
• Download_in_progress. Software is downloading to the inactive bank.
• Checksum_bank. The download was aborted, or a software bank has been
corrupted. New software must be downloaded, or the active software must
be copied to the inactive bank.
The current application software status is displayed by the ‘Admin/Sw/View’
command (see “Reports” on page 9-15).
Note: For a software download to be possible, the software status must be

‘stable’. That is, both banks must contain the same version of software.
Downloading application software

Software can be downloaded to the TN-1X either from the CAT, or from the
Preside EC-1 Element Controller. In both cases, the use of the User Interface
commands is required. The operation is processed in the background so that
the user can complete other tasks.
• From the CAT, the download takes up to 30 to 40 minutes to complete. See
Appendix A: Craft Access Terminal for details of CAT configuration.
• From the Preside EC-1 Element Controller, the download takes up to
fifteen minutes to complete. The user can continue other management
tasks while the software download takes place.
Note 1: Before any downloading is possible, the new application software
must be loaded, in an uncompressed form, to a place where it is accessible
using the required platform.
Note 2: This operation should not be requested while a software download,
NE configuration backup or NE configuration restoration is already in
progress. This operation should also not be requested during periods when
automatic NE backups might occur.

Downloading application software from the CAT

Downloading application software to the NE from the CAT requires two stages
to be performed. These are:
• The application software must be prepared for download. This involves
decompressing this software from a floppy disk, and storing it on the
CAT’s hard disk. This is described in Procedure 9-1.
• The application software must then be downloaded to the NE from the
CAT’s hard disk. This is described in Procedure 9-2.
Procedure 9-1
Preparing the application software on the CAT
Step Action
1 Switch the CAT, and wait for Windows95 to start.

2 Insert the application software disk into the floppy drive of the CAT.
3 From the ‘Start’ menu, open the ‘Programs’ menu and start the ‘Windows
Explorer’ application.
4 Create a directory in the root of the CAT’s hard drive called ‘TN-1X_R8’.
5 Copy the ‘tn1x8nn.exe’ file from the floppy disk to the ‘TN-1X_R8’ directory
(where ‘8nn’ represents the current R8 version number of the software).
6 Execute the ‘tn1x8nn.exe’ file by double clicking on it. The file will decompress
as a file called ‘tn1x8nn.b’ in the ‘TN-1X_R8’ directory.
7 Close the ‘Windows Explorer’ application. The application software is ready
for use.
—end—
Procedure 9-2
Downloading application software from the CAT
Step Action
1 Login to the TN-1X NE as described in Procedure 10-2.

2 Access the ‘Admin/Sw’ submenu by entering:
a s ↵
'
—continued—

Procedure 9-2
Downloading application software from the CAT (continued)
Step Action
3 Verify that the SW_upgrade_status and the Cnfg_upgrade_status are both

‘Stable’ by executing the ‘View’ command, enter:
v↵
The following report is displayed:
571,Active_SW_version=X9.01,Active_SW_bank=A,
Other_SW_version=X9.01
572,Active_cnfg_table_version=9.01,
Other_table_version=9.01
;
If line ‘573,SW_upgrade_status = Stable’, or line
‘574,Cnfg_upgrade_status = Stable’ do not appear in the report,
then the software banks do not contain the same software or configuration
version and the ‘DoWnload’ command is not available. The ‘DoWnload’
command is not available.
If the status is ‘Ready_to_activate’ then new software has been
downloaded but has not yet been activated. The ‘DoWnload’ command is not
available.
If the status is ‘Ready_to_commit’, the new software is already active.
The ‘DoWnload’ command is not available.
If the status is ‘Checksum_bank’, software in one bank is invalid. The
‘DoWnload’ command is not available.
4 Download the software using the ‘DoWnload’ command:
dw <filename> ↵
Where <filename> identifies the loadimage.
5 The UI responds with the following message:
4, OK, (4) request is being processed in background;
951,Cmd=a/s/dw <filename>,User=<user>,<date>,<time>;
6 The NE then takes about one minute to erase its inactive bank. The following
messages are displayed:
991,SW_oper=Download,Status=Started,<date>,<time>;
991,Download preparation in progress...,
<date>,<time>;
991,Flash erase confirmation (1) in progress...,
<date>,<time>;
<date>,<time>
991,Download preparation complete.,<date>,<time>;
—continued—

Procedure 9-2
Downloading application software from the CAT (continued)
Step Action
7 From the ‘Transfer’ menu of the HyperTerminal application, select the ‘Send
File’ option. The ‘Send File’ dialogue is displayed.
8 Select the ‘Xmodem’ option from the ‘Protocol’ pulldown menu.
9 Locate and select the new application software from the CAT’s file system.
10 Select the OK button. The ‘Xmodem file send’ dialogue is then displayed. This
dialogue contains a progress bar showing the filename, the progress of the
file transfer and a ‘Cancel’ button. The download may take between 30 to 40
minutes, depending on the loadimage size.
Note: It is not possible to issue any commands to the TN-1X while a software
download is in progress.
11 Once the download is complete, the new software is in the inactive software
bank.
ATTENTION
The first command processed via HyperTerminal after a software
download has completed will fail.
—end—
Once the new application software is loaded, the original application software
is in the active software bank, and the new software is in the inactive bank.
These versions can both be accessed until one of them is chosen for use. See
“Working with original and restored configuration tables” on page 9-22 for
details.
'

Downloading application software from the Preside EC-1 Element

Controller
Downloading application software to the NE from the Preside EC-1 Element
Controller requires two stages to be performed. These are:
• The application software must be prepared for download. This involves
decompressing this software from a DAT tape, and storing it on the Preside
EC-1 Element Controller’s hard disk. This is performed by a system
engineering class user at the UNIX prompt, as is described in Procedure
9-3.
• The application software must then be downloaded to the NE from the
Preside EC-1 Element Controller’s hard disk. This is described in
Procedure 9-4.
Procedure 9-3
Preparing the application software on the Preside EC-1 Element Controller
Step Action
1 Insert the application software DAT tape into the tape drive of the Preside
EC-1 Element Controller.
2 On the Preside EC-1 Element Controller, start a UNIX session.
3 Change directory to the NE_loads directory by entering:
cd ~/sdhms/data/NE_load/1X ↵
4 Copy the software file to this directory by entering:
tar xv ↵
5 The software file is placed in the following directory:
~/sdhms/data/NE_load/1X
—end—
Procedure 9-4
Downloading application software from the Preside EC-1 Element Controller
Step Action
1 Start a Command Line User Interface session on the TN-1X NE from the
Preside EC-1 Element Controller.
2 Access the ‘Admin/Sw’ submenu by entering:
a s ↵
—continued—

Procedure 9-4
Controller (continued)
Step Action
3 Verify that the SW_upgrade_status and the Cnfg_upgrade_status are both

‘Stable’ by executing the ‘View’ command, enter:
v↵
;
If line ‘573,SW_upgrade_status = Stable’, or line
‘574,Cnfg_upgrade_status = Stable’ do not appear in the report,
then the software banks do not contain the same software or configuration
version and the ‘DoWnload’ command is not available. The ‘DoWnload’
command is not available.
If the status is ‘Ready_to_activate’ then new software has been
downloaded but has not yet been activated. The ‘DoWnload’ command is not
available.
If the status is ‘Ready_to_commit’, the new software is already active.
The ‘DoWnload’ command is not available.
If the status is ‘Checksum_bank’, software in one bank is invalid. The
‘DoWnload’ command is not available.
4 Execute the ‘DoWnload’ command specifying the file name and local path of
the new software by entering the following command. No confirmation is
required.
dw <path>/<filename> ↵
Where <path> and <filename> identifies the loadimage. For example, for the
TN-1X ‘tn1x882a.b’ loadimage in the ‘/home/sdhmsusr’ directory, type the
following command:
dw /home/sdhmsusr/tn1x882a.b ↵
'
—continued—

Procedure 9-4
Controller (continued)
Step Action
5 The UI responds with the following message:

951,Cmd=a/s/dw <path>/<filename>,User=<user>,
<date>,<time>;
From this point onwards, the file transfer then takes place in the background.
The user may execute other UI commands, including logging out or closing
the NE’s window on the Preside EC-1 Element Controller. The download
process may take as long as 15 minutes, depending on the software version
size and communication delays between the Preside EC-1 and the TN-1X.
Note: Once the download is in progress, it can be cancelled using the
‘abort_download’ command. See “Command details” on page 9-28 for
details.
6 The NE then takes about one minute to erase its inactive bank. The following
messages are displayed:
991,SW_oper=Download,Status=Started,<date>,<time>;
991,Download preparation in progress...,
<date>,<time>;
<date>,<time>;
<date>,<time>
991,Download preparation complete.,<date>,<time>;
7 The NE then downloads the loadimage to the inactive bank. Progress
messages are displayed for every 12.5% progress made using the following
message:
991,Download operation <percent> complete...,
<date>,<time>;
8 Once download is complete, the following message is displayed:
991,SW_oper=Download,Status=Completed,<date>,<time>;
9 If the download is successful, the new software is in the inactive software
bank.
—end—
Once the new application software is loaded, the original application software
is in the active software bank, and the new software is in the inactive bank.
These versions can both be accessed until one of them is chosen for use. See
“Working with original and restored configuration tables” on page 9-22 for
details.

Working with original and downloaded software

When new application software has been downloaded, it is located in the
inactive software bank. The original software, which at this point is still in
use, is located in the active software bank.
Note: The location of downloaded software is indicated by the software

status (see “Software status” on page 9-4). That is, if the new software is
in the inactive bank, the status is ‘ready-to-activate’. If the new software is
in the active bank, the status is ‘ready-to-commit’.
The user is able to switch between these versions of the software. This
enables any testing or evaluation to be made before a decision is made
whether to commit to the new version or not. Switching between versions will
always result in a warm reboot.
CAUTION
Switching from Release 9 to Release 8 or Release 7
If the TN-1X is switched from Release 9 software to Release 8
or Release 7 software, the configuration will be lost, the TN-1X
will enter detached mode, and traffic will be hit.
Note: During a reboot, some transient alarms will occur. Alarms should be
ignored until ten minutes after the reboot, to allow for settling.
Committing to downloaded software

New application software can be evaluated by the user before any decision is
made whether to adopt it (see ‘Working with original and downloaded
software’, above). There are two possible outcomes to this issue:
• The user commits to using the new version of software. The software status
must be ‘Ready-to-commit’ for this action to be possible. The new
software is copied into the inactive bank, so that both of the software banks
contain this version.
• The user rejects the new software. The software status must be
‘Ready-to-activate’ for this action to be possible. The new software is
deleted from the inactive bank and replaced with the original version, so
that both banks contain this version. '
Note: For details on software status, see “Software status” on page 9-4.
Command details
The commands that access the application software management
functionality of the TN-1X are shown in Figure 9-3 below, and detailed in the
tables that follow.

Figure 9-3
Admin/Sw menu structure
Admin
Sw
DoWnload
Abort_Download
Switch_to_Loaded
Switch_to_Original
Warm_Restart
Cold_Restart
CoMmit
BackOut
CoPy
View
Table 9-1
Admin/Sw
DoWnload A S DW file_name No Downloads software.
Abort_Download A S AD N/A No Aborts any software download in

progress (only available from Preside
EC-1 Element Controller).
Switch_to A S SL N/A Yes Switches to the downloaded software

_Loaded version, and performs a warm restart.
Switch_to A S SO Switches to the original software

_Original version, and performs a warm restart.
Warm_Restart A S WR [other] Performs a warm restart on the

current (or other) software.
Cold_Restart A S CR N/A Performs a cold restart. Cancels

(see note) detached mode.
CoMmit A S CM Commits to the new software. The

remaining copy of the old software is
replaced by new software.
BackOut A S BO Reverts to the old software. The new

software is replaced by the remaining
copy of the old software.
CoPy A S CP Copies the (good) active flash bank

into the (corrupted) inactive bank.
View ASV N/A No Displays details of the current

software version, config table version,
and software/configuration status.
Note: A cold restart of a fully equipped TN-1X takes 12 minutes. No canges should be made to the
TN-1X until at least 12 minutes after a cold restart.

Note: When a download has been aborted, the software status will be
‘checksum_bank’. This will also occur if a software bank is corrupted. To
resolve this state, either new application software must be loaded, or the
original software must be copied into the inactive software bank.
'

Parameters
• The <filename> parameter identifies the path and filename for the TN-1X
software. The <filename> parameter may be up to 32 characters long, and
can be hierarchic. For example:
NE_loads/tn1x_sw
This represents a file called ‘tn1x_sw’ in the ‘NE_loads’ directory.
Autonomous events
The autonomous events generated by the above commands are listed below.
• Restart reason. This shows the reason for a restart.
984, Restart = <‘Cold’|‘Warm’>, Reason = <‘Power_up’|
‘User_request’|‘Bank_switch’|‘SW_error’|
‘Watch_dog’>, <date>, <time>
• Software operations. The following events are used:

991, SW_oper = <operation>, Status = <status>,
992, SW_oper = <operation>, Status = Fail,
Reason = <reason>, <date>, <time>
Where:
— <status> is ‘Started’, ‘Aborted’, ‘Completed’.

— <operation> is ‘Download’, ‘Commit’, ‘Backout’, ‘Copy’,
‘To_loaded’, ‘To_origin’, ‘Warm’, ‘Warm_other’, ‘Cold’.
— <reason> is ‘File_not_found’, ‘File_transfer’, ‘Err_write_flsh’,
‘Err_write_NVS’, ‘Bad_file’, ‘FT_cancelled’, ‘FT_timeout’,
‘TX_buf_empty’, ‘RX_buf_full’, ‘Comms_fatal’,
‘Too_many_NAKS’.

Reports
The reports for the described commands are shown below.
Admin/Sw/View
571, Active_SW_version=<version>,Active_SW_bank=<‘A’|‘B’>,
Other_SW_version=<version|‘N/A’>
572, Active_cnfg_table_version=<version>,
Other_table_version=<version|‘N/A’>
‘Ready-to-commit’|‘Download-in-progress’|
‘Checksum_bank’>
Where:
• <version> is a software/table version number.
• The software statuses are explained in “Software status” on page 9-4
• The config table statuses are explained in “Configuration table status” on
page 9-18.
For example:
Other_SW_version=N/A
;
Note: This report is identical to that produced by the ‘Admin/Cnfg_tbl/

View’ command (see page 9-31).
'

Admin/Cnfg_tbl <A C>

This command allows the user to backup the active configuration table, and to
restore a previously saved table with the option to revert or commit to either
version.
Overview of configuration tables

All configuration information for the TN-1X is stored in the Subrack
Controller (SRC) in a configuration table. Like the alternate banks that exist
for application software, there are two configuration tables:
• The active configuration table contains the live configuration of the
TN-1X. That is, changes to the configuration of the multiplexer will be
reflected in this table.
• The inactive configuration table will, under most circumstances, be the
same as the active table. Changes to configuration, which are included in
the active table, will also be reflected in this table. This table, however, also
provides a mechanism by which alternative configurations can be loaded
and implemented.
The active configuration table can be saved on either the CAT or the Preside
EC-1 Element Controller platform so that it can be restored at a later date (see
“Backing up the configuration table” on page 9-24). This allows
experimentation with new configurations, while retaining a secure copy of the
original configuration.
When a configuration table is restored, the data is loaded to the inactive table.
This does not affect the live configuration, which can be entirely different.
These alternative configurations can then be swapped over to enable the user
to test and evaluate them. When the user decides which configuration is
preferred, the restored configuration can be selected for use. The other
configuration is lost at this point.
Note: NE backup and restore operations should not be requested while a

software download, NE configuration backup or NE configuration
restoration is already in progress. These should also not be requested
during periods when automatic NE backups might occur.
The process of loading and activating an archived configuration is shown in

Figure 9-4 below. The restore functionality is only one part of this process.

Figure 9-4
An overview of restoring a configuration table
Both configuration tables contain the original

Start configuration information
Replacement The configuration information that is to be

config available restored is available for use.
Restore a The active table contains the original

configuration configuration, and the inactive table now
table to NE contains the loaded configuration.
Switch to loaded
configuration While the loaded configuration is being
tested, the original configuration is in the
inactive configuration table. You can switch
between the different configurations.
Test loaded
configuration
Is loaded Yes
configuration
OK?
No
Switch to original
During normal operation, it is important
configuration
that both tables contain the same
configuration information. If these are
different, this can interfere with the
Commit to loaded operation of configuration functions.
Backout
configuration
If the loaded configuration is satisfactory,
the user may decide to commit to it. If the
Loaded loaded configuration proves unsatisfactory,
Old configuration configuration then the user must back out, reverting to
in both tables in both tables the original configuration. In either case,
the NE is left with the same configuration in
both configuration tables. '
Finish

Configuration table status

There are three statuses associated with the configuration tables of the TN-1X:
• Stable. Both tables contain the same configuration information.
• Ready_to_activate. Configuration information has been downloaded, and
this is in the inactive table.
• Ready_to_commit. Configuration information has been downloaded, and
this is in the active table.
The current configuration table status is displayed by the ‘Admin/Sw/View’
command (see “Reports” on page 9-15).
Note: For a software download to be possible, the configuration table

status must be ‘stable’. That is, the tables must contain the same
configuration information.
Restoring an archived configuration table

Configuration table data that is stored on the CAT or the Preside EC-1
Element Controller can be restored onto the TN-1X NE.
Note 1: This process places the restored configuration into the inactive
configuration table only. Additional processes are required to put the
restored configuration into active use, and these are detailed later in this
chapter.
Note 3: Any attempt to restore a Release 8 configuration table onto a
Release 9 TN-1X will be rejected.
Restoring a configuration table from the CAT

Restoring a backup of the configuration table requires a combination of UI
commands and use of the HyperTerminal application. The recommended
Terminal application options are described in Appendix A: Craft Access
Terminal.
ATTENTION
It is recommended that the Preside EC-1 Element Controller’s ‘Restore NE’
function is used on managed NEs in preference to the functions available
from a User Interface session. This minimises the possibility of errors when
file names are specified.

Procedure 9-5
Restoring a configuration table from the CAT
Step Action

2 Access the ‘Admin/Cnfg_tbl’ submenu by entering:
a c↵
3 Ensure that the configuration status is ‘Stable’ by executing the ‘View’
command, enter:
v↵
;
If the line ‘574,Cnfg_upgrade_status = Stable’ does not appear in
the report, then the configuration tables are not identical.
If the status is ‘Ready-to-activate’ then a configuration table has
been restored but has not yet been activated. The ‘REstore’ command is not
available.
If the status is ‘Ready-to-commit’ then the restored table is
already active. The ‘REstore’ command is not available.
4 Execute the ‘REstore’ command by entering:
re <filename> ↵
Where <filename> identifies the configuration table.
5 The UI responds with the following messages:
951,Cmd=a/c/re <filename>,User=<user>,
<date>,<time>;
6 From the ‘Transfer’ menu of the HyperTerminal application, select the ‘Send
File’ option. The ‘Send File’ dialogue is displayed. '
8 Locate and select the configuration table from the CAT’s file system.
—continued—

Procedure 9-5
Restoring a configuration table from the CAT (continued)
Step Action
9 Select the OK button. The ‘Xmodem file send’ dialogue is then displayed. This
dialogue contains a progress bar showing the filename, the progress of the
file transfer and a ‘Cancel’ button.
Note: It is not possible to issue any commands to the TN-1X while a
configuration restore is in progress.
10 When the restore is complete, the restored configuration is in the inactive
configuration table.
ATTENTION
The first command processed via HyperTerminal after a restore
operation has completed will fail.
—end—
Restoring a configuration table from the Preside EC-1 Element

Controller
A configuration table stored on the Preside EC-1 Element Controller can be
restored to the TN-1X NE using Procedure 9-6. The Preside EC-1 Element
Controller is provided with an ‘NE_backup’ directory in which backed up
TN-1X configurations are stored. The Preside EC-1 Element Controller
permits filenames of up to 128 characters in length (less the length of the
command), giving the user flexibility in creating an informative archiving
scheme.
ATTENTION
It is recommended that the Preside EC-1 Element Controller’s ‘Backup NE’

Procedure 9-6
Restoring a configuration table from the EC-1
Step Action
1 Start a Command Line User Interface session on the TN-1X NE from the
Preside EC-1 Element Controller.
a c↵
command, enter:
v↵
;
available.
4 Execute the ‘REstore’ command and specify the filename and local (Preside
EC-1) path of the backup configuration by entering:
re <path>/<filename>↵
Where <path> is an absolute pathname (for example, ‘/users/syseng01/
backup’) or a pathname relative to ‘/home/sdhms/data/NE_backup’ (for
example, ‘1X/2.5/backup’).
951,Cmd=a/c/re <path>/<filename>,User=<user>,
'
<date>,<time>;
6 The specified backup file is then loaded into the inactive configuration table.
Once complete, the following message is displayed:
993,Cnfg_oper=Restore,Status=Completed,<date>,<time>
—end—

Working with original and restored configuration tables

When a new configuration table has been downloaded, it is located in the
inactive table. The original configuration, which at this point is still in use, is
located in the active table.
Note: The location of restored table is indicated by the configuration table

status (see “Configuration table status” on page 9-18). That is, if the
restored table is in the inactive bank, the status is ‘ready-to-activate’. If the
restored table is in the active bank, the status is ‘ready-to-commit’.
The user is able to switch between these versions of the mux configuration.
This enables any testing or evaluation to be made before a decision is made
whether to commit to the new table or not. Switching between versions will
always result in a warm reboot.
Note: During a reboot, some transient alarms will occur. Alarms should be
ignored until ten minutes after the reboot, to allow for settling.
Committing to a restored configuration table

A restored configuration can be evaluated by the user before any decision is
made whether to adopt it (see ‘Working with original and downloaded
configuration tables’, above). There are two possible outcomes to this issue:
• The user commits to using the restored configuration. The new table is
copied into the inactive bank, so that both the active and inactive
configuration tables contain this configuration. The configuration table
status must be ‘Ready-to-commit’ for this action to be possible.
• The user rejects the restored configuration. The new table is deleted from
the inactive table, and replaced with the original table, so that both
configuration tables contain the original configuration. The configuration
table status must be ‘Ready-to-activate’ for this action to be possible.
Configuration status is detailed in “Configuration table status” on page 9-18.
Detached mode
If the Subrack Controller (SRC) detects that there is a mismatch between the
configuration table and the current traffic configuration, the Subrack
Controller enters Detached mode. While this mode is active:
• The SRC does not control the traffic and the traffic is left running.
• Monitoring of the multiplexer is minimal and unreliable.
• An INT-NE-Config_Corrupt alarm is raised.
• The SRC can still communicate with the Element Controller or CAT.
• The configuration tables can be updated or restored, but the changes are not
imposed on the traffic cards (non-traffic affecting). When the configuration
tables have been updated or restored and are correct, the ‘Impose_Config’
command can be issued. This imposes the information in the active
configuration table on the traffic cards (possibly traffic affecting).

• It is not possible to perform manual path protection switches, manual 1:N

switches, manual Payload Manager switches, manual 1:1 tributary
protection switches, or manual MSP switches.
Note: While detached mode is active, ‘NE-Unexpected_Card’ and
‘PPI-Unexpected_Signal’ alarms can be raised. These alarms will clear
once the NE returns to its normal operating mode.
The Subrack Controller enters the Detached mode automatically under the
following circumstances:
• Both configuration tables are corrupt or unreadable and there are traffic
connections.
• The multiplexer is cyclically rebooting, and there are traffic connections.
• The SRC detects a difference between the configuration table and the
current traffic configuration.
• The user issues a ‘Default’ command via the user interface. The current
configuration table is overwritten with the default settings. The software
status and configuration table status must both be ‘Stable’ for this
command to be issued.
• The NE address on the backplane does not match the NE address held in
the configuration table on the SRC (that is, the SRC is in the wrong
subrack, or a new or replacement SRC has been inserted). In the situation,
an INT-NE-Config_Bp_Mismatch alarm is raised.
Manual entry to Detached Mode can be requested by the user using the
‘Force_Detached’ command. All current configuration table settings are
retained. This function should only be used under exceptional circumstances.
The software status and configuration table status must both be ‘Stable’ or
‘Ready to commit’ for this command to be issued.
To exit from the Detached mode, one of the following user actions is required:
• If the SRC is inserted in the wrong subrack, fit it into the correct subrack.
• If the SRC is a new or replacement unit, or is cyclically rebooting:
— Issue the ‘DeFault’ command via the user interface.
— Either Restore a previous configuration table, or manually update the
current configuration table via the user interface.
'
— Issue the ‘Impose_Config’ command. This clears any
INT-NE-Config_Corrupt and INT-NE-Config_Bp_Mismatch alarms.
• If the multiplexer is not carrying live traffic, perform a cold restart (issue a
cold restart command or power cycle off and on).
• If the mux has been placed in Detached mode manually, issue the
‘Impose_Config’ command to return it to normal operation. Any changes
that have been made to the active configuration while the mux was in this
mode will be applied.

Backing up the configuration table

The user may backup the current configuration table into a file on the CAT or
Preside EC-1, and restore this configuration at a later stage.
Note 2: When backing up a configuration table, ensure that a unique name
is used. No confirmation is requested when an existing name is used. It is
recommended that file names include the date, in order to minimise the
possibility of accidental overwrites.
Backing up a configuration table to the CAT

Storing a backup of the configuration table using the CAT requires a
combination of UI commands and use of the HyperTerminal application. The
recommended HyperTerminal application options are described in Appendix
A: Craft Access Terminal.
Note: The combined pathname and filename must be between four and 50
characters in length.
Procedure 9-7
Backing up a configuration table to the CAT
Step Action

a c↵
—continued—

Procedure 9-7
Backing up a configuration table to the CAT (continued)
Step Action

command, enter:
v↵
;
available.
4 Execute the ‘BackUp’ command by entering:
bu <filename> ↵
Where <filename> identifies the configuration table.
Note: This filename must be between four and 50 characters in length.
951,Cmd=a/c/bu <filename>,User=<user>,<date>,<time>;
6 From the ‘Transfer’ menu of the HyperTerminal application, select the
‘Receive File’ option. The ‘Receive File’ dialogue is displayed.
8 Specify the required destination folder and press the ‘Receive’ button. The
‘Receive file name’ dialogue is then displayed. '
9 Specify a filename for the backup.
10 Select the OK button. The ‘Xmodem file receive’ dialogue is then displayed.
This dialogue shows the filename, the volume of data transferred, and a
‘Cancel’ button.
Note: It is not possible to issue any commands to the TN-1X while a
configuration backup is in progress.
—continued—

Procedure 9-7
Backing up a configuration table to the CAT (continued)
Step Action
11 Once the ‘Xmodem file receive’ dialogue closes, the backup is complete.
ATTENTION
The first command processed via HyperTerminal after a restore
operation has completed will fail.
—end—
Note: Filenames detailed in this procedure are not case sensitive, and must
conform to standard DOS file naming conventions.
Backing up a configuration table to the Preside EC-1 Element

Controller
The Preside EC-1 Element Controller has a directory structure in which
TN-1X configurations can be stored. The user can specify either an absolute
or relative pathname for the archived configuration table. By default, the ‘/
home/sdhmsusr/data/NE_backup’ directory is used, but more specific
subdirectories can also be created and used.
ATTENTION
It is recommended that the Preside EC-1 Element Controller’s ‘Backup NE’
Note 1: The combined pathname and filename must be between four and
50 characters in length.
Note 2: The backup process can also be achieved from the Network
Element Access window inside the Preside EC-1 Element Controller. See
the Preside EC-1 Element Controller User Procedures handbook, NTP
323-1091-402 for details.

Procedure 9-8
Backing up a configuration table to the EC-1
Step Action
1 Start a User Interface session for the target TN-1X NE on the Preside EC-1
Element Controller platform.
a c↵
command, enter:
v↵
;
available.
4 Execute the ‘BackUp’ command and specify a path and filename. Filenames
must be unique and should conform to a naming scheme that allows the user
to identify the particular NE to which the table refers. Do this by entering:
bu <path>/<filename> ↵
Where <path> is an absolute pathname (for example, ‘/users/syseng01/
backup’) or a pathname relative to ‘/home/sdhms/data/NE_backup’ (for
example, ‘1X/2.5/backup’). It is recommended that the filename should
conform to a naming scheme that allows the user to identify the particular NE
to which it refers. The filename should be unique, as no confirmation of the '
filename is requested. It is recommended that the filename contains the date,
to minimise the possibility of accidental overwrites.
Note: The combined pathname and filename must be between four and 50
characters in length.
—continued—

Procedure 9-8
Backing up a configuration table to the EC-1 (continued)
Step Action

951,Cmd=a/c/bu <path>/<filename>,User=<user>,
<date>,<time>;
6 The backup file is stored in the specified directory. Once complete, the
following message is displayed:
993,Cnfg_oper=Backup,Status=Completed,<date>,<time>
—end—
Command details
The commands that access the configuration table management functionality
of the TN-1X are shown in Figure 9-5, and detailed in the tables that follow.
Figure 9-5
Admin/Cnfg_tbl menu structure
Admin
Cnfg_tbl
BackUp
REstore
Switch_to_Original
Switch_to_Restored
CoMmit
BackOut
Impose_Config
DeFault
Force_Detached
View

Table 9-2
Admin/Cnfg_tbl
BackUp A C BU file_name No Initiates backup of the user’s active

configuration to Preside EC-1
Element Controller. The file name
should be unique.
N/A Initiates backup of the user’s active

configuration to CAT.
REstore A C RE file_name No Initiates download of the backup

configuration from the Preside EC-1
Element Controller.
N/A Initiates download of the backup

configuration from the CAT.
Switch_to A C SO N/A Yes Switches to the NE’s original

_Original configuration.
Switch_to A C SR Switches to the restored

_Restored configuration.
CoMmit A C CM Commits to the restored

configuration. Overwrites the
remaining copy of the user’s
configuration.
BackOut A C BO Reverts to the original configuration.

Overwrites the restored
configuration.
Impose_Config A C IC Imposes active configuration onto

the traffic. This clears detached
mode. This command should be
used with care under exceptional
circumstances.
DeFault A C DF Sets the active configuration to

default settings. This starts detached
mode. This command should be
used with care under exceptional
circumstances.
Force_Detached
View
A C FD
ACV N/A No
Forces the mux into detached mode.
Shows details of the current

'
software version, config table
version and software/configuration
status.

Parameters
• The <file_name> parameter be up to 32 characters long, and can be
hierarchic if required. For example, on the Preside EC-1 Element
Controller platform:
NE_Backup/cnfg_12mar96
This represents a file called ‘cnfg_12mar96’ in the ‘NE_Backup’ directory.
Autonomous events
The autonomous events generated by the above commands are listed below.
• Restart reason. This shows the reason for a restart.
984, Restart = <‘Cold’|‘Warm’>, Reason = <‘Power_up’|
‘User_request’|‘Bank_switch’|’SW_error’|
’Watch_dog’>, <date>, <time>
• Configuration operations. The following events are used:

993, Cnfg_oper = <operation>, Status = Completed,
994, Cnfg_oper = <operation>, Status = Fail,
Reason = <reason>, <date>, <time>
995, Cnfg_oper = Checksum_error, Status = <cnfg_status>,
<date>, <time>
996, Crash configuration table was loaded, <date>,
<time>
Where:
— <operation> is ‘Commit’, ‘Backout’, ‘Restore’, ‘Backup’, ‘To_origin’,

‘To_restor’.
— <reason> is ‘File_not_found’, ‘File_transfer’,
‘Err_write_flsh’,‘Err_write_NVS’, ‘Bad_file’, ‘FT_cancelled’,
‘FT_timeout’, ‘TX_buf_empty’, ‘RX_buf_full’, ‘Comms_fatal’,
‘Too_many_NAKS’.
— <cnfg_status> is ‘Corrected’, ‘Not_corrected’.

Reports
The reports for the command described are shown below.
Admin/Cnfg_tbl/View
571, Active_SW_version=<version>,Active_SW_bank=<‘A’|‘B’>,
Other_SW_version=<version|‘N/A’>
572, Active_cnfg_table_version=<version>,
Other_table_version=<version|‘N/A’>
‘Ready-to-commit’|‘Download-in-progress’|
‘Checksum_bank’>
Where:
• <version> is a software/table version number.
• The software statuses are explained in “Software status” on page 9-4
• The config table statuses are explained in “Configuration table status” on
page 9-18.
For example:
Other_SW_version=N/A
;
Note: This report is identical to that produced by the ‘Admin/Sw/View’

command (see page 9-15).
'

Admin/User <A U>

This command enables the system administrator and system engineer class
users to access the user management functionality of the TN-1X.
User management
The user management functionality of the TN-1X enables you to change user
passwords and to put the TN-1X into Secure Mode.
Note: The Secure Mode command should be used by Nortel staff only.
Changing passwords
The Change_password command enables user passwords to be changed. The
user is prompted for the old password, the new password, and finally for a
re-keying of the new password.
Note 1: Passwords are not echoed to the screen when entered by the user.
Note 2: Passwords for a number of standard user names are fixed. That is,
they do not expire, and cannot be changed.
When a change password command is issued, the following process occurs:
Procedure 9-9
Changing passwords
Step Action
1 TN-1X issues the following request:

Originator password:
Enter the current password, and press Return.
2 The TN-1X then issues the following request:
New password:
Enter the new password, and press Return.
3 The TN-1X then requests a confirmation of this new password:
Repeat new password:
Repeat the new password, and press Return. The TN-1X will confirm that the
change has occurred.
—end—

Command details
The commands that access the user management functionality of the TN-1X
are shown in Figure 9-6 below, and detailed in the tables that follow.
Figure 9-6
Admin/User menu structure
Admin
User
change_Pswd
Bchange_pswd
Secure
Table 9-3
Admin/User
change_Pswd AUP [username] No Changes password for the

named user. The configuration
manager class can only change
their own passwords. The
system engineer class can
change the passwords of all
other users.
Bchange_pswd AUB username No One hit password change.

new_password Designed for use in batch files.
authority_password No interaction is required.
Secure AUS N/A No Puts TN-1X in Secure Mode.

This command should be used
by Nortel staff only.
Parameters
• The <username> parameter identifies a user, and is between six and eight
characters in length. If this is not specified, the password for the current
login is changed.
• The <new_password> parameter is the new password for the specified '
user.
• The <authority_password> is the password for the System Engineer.
Autonomous events
There are no autonomous events associated with user management.

Reports
There are no reports generated by the change passwords command. However,
the following actions are performed.
Admin/User/change_Pswd
When a password change is requested, the following dialogue takes place:
Originator password:
New password:
Repeat new password:
Note: Passwords are not echoed to the screen when entered by the user.
end of chapter

10-1
Appendix A: Craft Access Terminal 10-

Platform
The Craft Access Terminal (CAT) is an IBM* compatible laptop PC running
the Microsoft Windows95* HyperTerminal* application. This emulates a
TTY terminal.
Table 10-1
Craft Access Terminal (CAT) platform
Parameter Minimum Requirement
Processor 100 MHz Pentium (or higher).
RAM 16 Mbyte.
Hard disk 0.5 Gbyte.
Input 3.5” 1.44 Mbyte floppy disk drive.
Peripherals RS232 cable assembly.
Interface
The CAT interface employs a simple asynchronous start-stop protocol, carried
over RS232-C compliant signals. The CAT is defined as a Data Termination
Equipment (DTE) and the TN-1X is defined as a Data Communication
Equipment (DCE).
Table 10-2
CAT interface parameters
Parameter Data
Baud rate 19200 bit/s.
Protocol Asynchronous.
Start-stop.
Word structure 8 data bits.
No parity or hardware parity.
DO NOT USE XON/XOFF.
1 stop bit.
Flow control None.

10-2 Appendix A: Craft Access Terminal
Software
The recommended software package is the HyperTerminal application
software which is supplied with the Windows operating system. To configure
this application for use, perform Procedure 10-1. To run the application after
it is configured, perform Procedure 10-2.
Procedure 10-1
Setting up HyperTerminal
Step Action
1 From the ‘Start’ menu of Windows95, select the ‘Programs’ menu. Then,
select ‘Accessories’. Finally, select the ‘HyperTerminal’ folder shortcut. The
‘HyperTerminal’ folder is opened.
Note: If the ‘HyperTerminal’ folder shortcut is not in the default location
described above, search for ‘HyperTerminal’ using the ‘Find’ application on
the ‘Start’ menu. Once the folder is located, double-click on it to open it.
2 In the ‘HyperTerminal’ folder, double click on the ‘Hypertrm’ (or
‘hypertrm.exe’) application. The HyperTerminal application opens, and the
‘Connection Description’ dialogue is displayed.
3 Enter a name for the HyperTerminal connection (for example, “CAT”). Then,
select a suitable icon, using the scroll bars if required.
4 Press the ‘OK’ button. The ‘Phone Number’ dialogue is displayed.
5 Select the ‘Direct to COM1’ from the ‘Connect using’ pulldown list.
6 Press the ‘OK’ button. The ‘COM1 properties’ dialogue is displayed.
7 Select the ‘Port Settings’ tab within the ‘COM1 properties’ dialogue.
8 Select the ‘19200’ setting from the ‘Bits per second’ pulldown list.
9 Select the ‘8’ setting from the ‘Data bits’ pulldown list.
10 Select the ‘None’ setting from the ‘Parity’ pulldown list.
11 Select the ‘1’ setting from the ‘Stop bits’ pulldown list.
12 Select the ‘None’ setting from the ‘Flow control’ pulldown list.
13 Press the ‘Advanced’ button in the ‘Port Settings’ tab of the ‘COM1
Properties’ dialogue. The ‘Advanced Port Settings’ dialogue is displayed.
14 Press the ‘Defaults’ button within the ‘Advanced Port Settings’ dialogue.
15 Press the ‘OK’ button within the ‘Advanced Port Settings’ dialogue.
16 Press the ‘OK’ button within the ‘COM1 properties’ dialogue.
17 The CAT will attempt to communicate with a TN-1X NE over the serial port.
Abort this operation by selecting the ‘Disconnect’ option from the ‘Call’ menu.
18 Select the ‘Properties’ option from the ‘File’ menu of the ‘HyperTeminal’
application. A properties dialogue is displayed.
19 Select a setting of ‘500’ in the ‘Backscroll buffer’ lines field.
20 Select the ‘Settings’ tab within this properties dialogue.
21 Select the ‘Terminal keys’ radio button.
—continued—

Appendix A: Craft Access Terminal 10-3
Procedure 10-1
Setting up HyperTerminal (continued)
Step Action
22 Select the ‘Auto detect’ setting from the ‘Emulation’ pulldown list.
23 Press the ‘ASCII setup’ button. The ‘ASCII setup’ dialogue is displayed.
24 In the ‘ASCII sending’ section of the ‘ASCII setup’ dialogue, uncheck the
‘Send line ends with line feeds’ tickbox. Uncheck the ‘Echo types characters
locally’ tickbox. Enter zero in the ‘Line delay’ field. Enter zero in the ‘Character
delay’ field.
25 In the ‘ASCII receiving’ section of the ‘ASCII setup’ dialogue, check the ‘Wrap
lines that exceed terminal width’ tickbox. Uncheck the ‘Append line feed to
incoming line ends’ tickbox. Uncheck the ‘Force incoming data to 7-bit ASCII’
tickbox.
26 Press the ‘OK’ button within the ‘ASCII setup’ dialogue.
27 Press the ‘OK’ button within the properties dialogue.
28 Select the ‘Save’ option within the ‘File’ menu of the HyperTeminal
application. This saves the settings using the name specified in step 3. The
‘HyperTerminal’ folder is used as the default location for this file.
29 Close the HyperTeminal application.
—end—
Procedure 10-2
Starting a CAT session on HyperTerminal
Step Action
1 Connect the CAT to the TN-1X NE using an RS232 cable. This is connected
from the COM1 port on the CAT to the CATT port on the TN-1X.
2 From the ‘Start’ menu of Windows95, select the ‘Programs’ menu. Then,
select ‘Accessories’. Finally, select the ‘HyperTerminal folder’. The
‘HyperTerminal’ folder is opened.
Note: If the ‘HyperTerminal’ folder shortcut is not in the default location
described above, search for ‘HyperTerminal’ using the ‘Find’ application on
the ‘Start’ menu. Once the folder is located, double-click on it to open it.
3 Double click on the appropriate connection icon for the CAT-mux connection
(as established in Procedure 10-1).
4 The HyperTerminal application starts, and a connection is attempted. If no
login prompt appears, press Return.

5 Specify a login name, a password and a unique identification for the session.
6 The connection between the CAT and the TN-1X NE is then established.
—end—
end of chapter

11-1
Appendix B: TN-1X alarms 11-

This appendix lists the alarms used by TN-1X and TN-1X/S NEs, and the
severities associated with these alarms.
Table 11-1
TN-1X R9 alarms
TN-1X R9 Alarm Severity TN-1X R6 Alarm
AU-AIS Minor AU AIS
EA-Input Critical External Alarm
ES-CMI_Output_Fail Minor CMI Output Fail

ES-CMI_Violation Minor CMI Violation
HP-DEG Major HO Signal Degraded
HP-EXC Critical HO Excessive BER
HP-FE_QOSV_15M Minor N/A
HP-FE_QOSV_24H Minor N/A
HP-LOM Major HO TU Multiframe
HP-PLM Major HO Signal Label
HP-QOSV_15M Minor N/A
HP-QOSV_24H Minor N/A
HP-RDI Major HO FERF
HP-REI Major HO FEBE
HP-TIM Major HO Path Trace

INT-AU-AIS Minor INT AU AIS
INT-AU-LOP Major INT AU LOP
INT-HP-Insert_Bus Critical INT HO Insert Bus
INT-HP-IP_Buffer Major INT HO I/P Buffer
INT-HP-Thru_Bus Critical INT HO Thru Bus
INT-LP-IP_Buffer Major INT LO I/P Buffer

INT-LP-OP_Buffer Major INT LO O/P Buffer
INT-NE-Comms_Fail Critical INT Comms Fail
INT-NE-Config_bp_mismatch
INT-NE-Config_Corrupt
Critical
Critical
N/A
INT Config Corrupt

INT-NE-MFS_Pulse_Fail Critical INT MFS Pulse Fail
—continued—

11-2 Appendix B: TN-1X alarms
Table 11-1
TN-1X R9 alarms (continued)
INT-NE-RAM_Fail Critical INT RAM Fail
INT-NE-SW_Corrupt Critical INT S/W Corrupt
INT-NE-Unit_Fail Critical Unit Fail
INT-OS-Laser_Test Minor INT Laser Test
INT-SYNC-Oscillator_Fail Critical INT Sync Osc Fail
INT-SYNC-Trib_Line_Fail Critical Trib Sync Line Fail
INT-TU-AIS Minor INT TU AIS
INT-TU-LOP Major INT TU LOP
LP-DEG Major LO SignaI Degraded
LP-EXC Major LO Excessive BER
LP-FE_QOSV_15M Minor N/A
LP-FE_QOSV_24H Minor N/A
LP-PLM Major LO Signal Label
LP-QOSV_15M Minor N/A

LP-QOSV_24H Minor N/A
LP-RDI Major LO FERF
LP-REI Major LO FEBE

LP-TIM Major N/A
MS-AIS Minor MS AIS
MS-DEG Major MS Signal Degraded

MS-EXC Critical MS Excessive BER
MS-QOSV_15M Minor N/A
MS-QOSV_24H Minor N/A

MS-RDI Major MS FERF
MSP-Prot_Scheme_Mismatch Major N/A
MSP-Channel_Mismatch Major N/A
MSP-Invalid_K_Bytes Major N/A
NE-Card_Fail Critical Card Fail
NE-Card_Fault Critical Card Fault
NE-Card_Out Critical Card Out
NE-Lan_Alarm Critical LAN Alarm
NE-Loopback_Alarm Major N/A
NE-np1_Switch_Alarm Major N/A
NE-Unexpected_Card Minor Card Out Inverted
NE-Unexpected_LAN Major N/A

NE-Wrong_Card Critical Wrong Card
OS-Laser_Shutdown Minor Laser Shutdown
—continued—

Appendix B: TN-1X alarms 11-3
Table 11-1
TN-1X R9 alarms (continued)
OS-Laser_Temp_Hi_Low Major Laser Temp High/Low
OS-Optical_Power_High Critical Optical Power High
OS-Optical_Power_Low Major Optical Power Low
OS-Optical_Power_OOL Minor Optical Power OOL
PPI-AIS Minor 34M AIS/Trb AIS
PPI-CRC_QOSV_15M Minor N/A
PPI-CRC_QOSV_24H Minor N/A
PPI-CV_QOSV_15M Minor N/A
PPI-CV_QOSV_24H Minor N/A
PPI-DEG Major Trb Signal Degraded
PPI-EXC Major 34M Excessive BER

Trb Excessive BER
PPI-LOF (see Note) Critical 34M Loss of Frame
PPI-LOM Minor N/A
PPI-LOS Major 34M Loss of Signal

Trb Loss of Signal
PPI-RAI Major 34M Remote Alarm Indicator

PPI-TF Major Trb Output Fail
PPI-Unexp_Signal Major Trb Loss of Signal Inverted
PS-Power_Fail Critical Power Fail

Qecc-Comms_Fail Critical Qecc Comms Fail
RS-LOF Critical STM Loss of Frame
RS-LOS Critical STM Loss of Signal

RS-QOSV_15M Minor N/A
RS-QOSV_24H Minor N/A
RS-Realign_Phase Critical STM Realign Phase
SYNC-Ext_Sync_LOS Critical External Sync LOS
SYNC-SETG_Fail Major SETG Fail
SYNC-Src_Not_Primary Critical Sync Source Not Primary
TM-TF Minor N/A
TM-AIS Major N/A
TU-AIS Minor TU AIS
TU-LOP Major TU LOP
Note : PPI_LOF is also raised against a 2m card which has no R6 equivalent.
—end—
end of chapter

12-1
Appendix C: TN-1X Messages 12-

This appendix lists the messages that are output by the TN-1X User Interface.
Messages can be subdivided into error messages and warning messages.
Error Messages
The following error messages are output by the TN-1X User Interface.
0, "Non-Enumerated Error:"
1, "Invalid command:"
2, "Ambiguous command:"
19, "Command not implemented:"
20, "Invalid argument"
60, "SW manager is not in stable state"

61, "Configuration manager is not in stable state"
62, "SW manager is not in ready-to-active state"
63, "SW manager is not in ready-to-commit state"
64, "SW manager is not loading file"
65, "SW manager is not in CHECKSUM_BANK state"
66, "SW copy failed - error writing to flash"
67, "SW commit/backout failed - error writing to flash"
68, "SW download failed"
69, "Configuration manager is not in ready-to-active state"
70, "Configuration manager is not in ready-to-commit state"
71, "Configuration restore failed"
72, "Configuration backup failed"
73, "Configuration backout failed"
74, "Configuration commit failed"
75, "SW manager is in CHECKSUM_BANK state"
76, "SW manager is loading file"
110, "Timeout while trying to login"

111, "Number of retries exceeded"
112, "User is not allowed to login currently"
113, "Login incorrect"
114, "Maximum number of users already logged in"
140, "Expected argument:"
141, "Expected arguments:"
142, "Wrong argument:"
143, "Too few arguments"

12-2 Appendix C: TN-1X Messages
161, "Too many arguments"

162, "Subrack MON session already active"
163, "Traffic card reach through already active on slot"
164, "Remote reach through already active"
999, "Module needs updating with error numbers:"
2001, "Cannot change config during Switching"

2003, "Incorrect number of parameters entered"
2004, "Parameter type is incorrect"
2005, "Illegal data has been entered"
2006, "No card in the selected slot"
2007, "The alarm type is invalid for this slot"
2008, "Invalid Alarm Unique Number"
2009, "Invalid External Alarm Instance"
2010, "Invalid data has been entered"
2011, "Clui Alarms Command was Unsuccessful"
2012, "Invalid Card Type in slot"
2500, "Not a valid performance point"
2501, "No matching performance points"
2502, "Retrieve intermediate already in progress"
2503, "Too close to scheduled termination"
2504, "Slot not active"
2505, "Must be divisible by 60"
2506, "Termination already in progress"
2551, "No data recorded"
2552, "No unretrieved data"
2553, "Log does not exist"
3000, "Switching in progress"

3001, "Sync source not equipped:"
3002, "Duplicate entry:"
3003, "Not in hierarchy"
3004, "Source does not support SSM"
3005, "Source is failed"
3006, "Force on:"
3007, "Not valid for PDH source"
3008, "Illegal hierarchy"
3009, "Sync not aligned"
3010, "Minimum for on optical port is 2 seconds"
3501, "Failed to Parse Command."

3502, "End of Data Transaction - do not display this code."
3503, "Auto. Switch in Progress. Please Try Again."
3504, "Unable to Find Connection."
3505, "Cannot Connect to Same Card."
3506, "Bad Card Mix for Connection"
3507, "Payload Mismatch"
3508, "Bandwidth Mismatch"
3509, "Internal Coding Problem"
3510, "Already Connected"

3511, "Endpoint Blocked"

3512, "Need Mixed Payload Tributary"
3513, "Need Mixed Payload Manager"
3514, "Need STM4 Before AU4 can Change"
3515, "Q2M Trib. has only 16 ports."
3516, "Could Not Find Card"
3517, "Not Enough Backplane Bandwidth"
3518, "First Endpoint Blocked"
3519, "Second Endpoint Blocked"
3520, "Third Endpoint Blocked"
3521, "First Endpoint Already Connected"
3522, "Second Endpoint Already Connected"
3523, "Third Endpoint Already Connected"
3524, "All Endpoints Not From Same Connection"
3525, "Payload Label Does Not Exist"
3526, "Payload Label must be Low Order"
3527, "Payload Label must be High Order"
3528, "Need Connection before Signal Label is Available"
3529, "Port Outside Range for Card"
3530, "Cannot Change AU4 on MUX with Connections"
3531, "Path Trace Endpoint Does Not Exist"
3532, "The Trib is a Q2M: need a port"
3533, "First Slot is Unequipped"
3534, "First Slot Needs to be Agg Slot"
3535, "Second Slot Needs to be Agg Slot"
3536, "Second Slot is Unequipped"
3537, "Not Expecting Three Endpoints for This Connection"
3538, "Third Slot Needs to be Trib Slot"
3539, "Label Must Only Contain Letters, -, _ and Digits"
3540, "Cannot Delete: Trib Endpoint in Hync Hierarchy"
3541, "Second Slot Needs to be Agg or Trib Slot"
3544, "Need Connection before Pathtrace is Available,
3545, "Pathtrace does not exist’
3549, "Trib Not Capable of Trib to Trib Connections’
3550, "Protecting Trib has connections’
3551, "Third slot is not equipped’
3552, "Protecting Trib has connections"
4001, "Active payload manager is not running"

4002, "Payload Manager failed to switch"
4003, "Not a protected connection"
4004, "Currently switching on this protected connections"
4005, "PPS must be disabled on specified connection"
4006, "Manual mode denied"
4007, "CLUI message parse failed"
4008, "Failed to parse payload"
4009, "Alternate Configuration action current"

4201, "Illegal payload manager slot"

4202, "Standby payload manager not equipped"
4203, "Standby payload manager physically not present"
4204, "Standby payload manager in fail state"
4205, "Card fault present on standby payload manager"
4206, "Wrong card in standby payload manager slot"
4207, "SETG-fail present on standby payload manager"
4208, "NE-comms fail present on standby payload manager"
4209, "Unavailable bandwidth on standby payload manager"
4210, "Main and standby payload managers are different variants"
4211, "Payload manager switch in progress"
4212, "Alternate action in progress"
4213, "Standby Payload manager is not running"
4214, "Payload manager protection filtering in progress"
4251, "Request Not Understood"

4252, "Slot already equipped"
4253, "Slot already unequipped"
4254, "Request Incompatible with Protection"
4255, "Physical Limitation"
4256, "Bad Card Mix"
4257, "Card carrying Traffic"
4258, "Protection Switching"
4259, "Card in Sync Source Hierarchy"
4260, "Loopback does not Exist"
4261, "Card is Illegal for Slot"
4262, "Card Not Supported"
4263, "Payman Protection Enabled"
4264, "Cannot Unequip Active Payman"
4265, "Need to Reset 1:N Status"
4266, "Can only reequip within same card class"
4267, "VC3 connections exist: need mixed payload payman"
4268, "This Card is Already Equipped in this Slot"
4269, "Need Q2M V4.0 (75ohm_HVT or 120ohm_HVQ) for Trib. Prot."
4270, "Need to Equip Slot before Changing Loopback Status"
4271, "Card Equipped in this Slot Does Not Support Loopbacks"
4272, "Can only equip VC3 card if have a Rel 2.5 backplane’
4273, "Non-mix payload payman equipped; cannot equip this card’
4274, "Card does not support VC-3 connections’
4275, "Card does not support trib to trib connections’
4278, "Slot has to be a tributary slot’
4279, "There is no VC3 card in the slot’
4280, "Port does not exist’
4281, "Can only view for 2M, 34M, 34M/45M cards’
4283, "Cannot Unequip while MSP On for this card’
4301, "Illegal Switch Request"

4302, "Illegal Backplane"
4303, "Illegal SMX version"
4304, "Protection Trib is not Equipped in S3"
4305, "Switching TAM's not present"
4306, "Protection card currently active"

4307, "No ICC2 card in S1"
4308, "Active payload manager physically removed"
4309, "Card alarm present against active payload manager"
4310, "ICC card not running"
4311, "Active PayMan not running"
4312, "1:N not enabled"
4313, "1:N protection in automatic mode"
4314, "Payload manager switch in progress"
4315, "1:N switch in progress"
4316, "Destination card is physically not present"
4317, "Destination card is in a fail state"
4318, "Source card has no connections"
4319, "ICC2 card physically not present"
4320, "Card fail present against ICC"
4321, "Card fault present against ICC"
4322, "Wrong card present against destination card "
4323, "Alarm filtering in progress"
4324, "Destination card has no application"
4325, "Source slot is not equipped"
4326, "Source slot is not a 2Meg variant"
4327, "Illegal destination slot"
4328, "Illegal source slot"
4329, "Unrecognised Mode requested by user"
4330, "Illegal protection card in slot 3"
4331, "Impedance conflict against logical 2Meg Tribs"
4332, "Destination card is not equipped"
4333, "Destination card is not a 2Meg variant"
4334, "Connections current on destination card"
4335, "1:N reading configuration table"
4336, "S3 presently protecting a tributary card"
4337, "Cannot switch from a wrong card"
4338, "No Trib currently being protected"
4349, "Trib is Part of Trib Protection Pair"
4350, "Correct card is not equipped"
4351, "Protecting card is active"
4352, "Manual Trib Protection is enabled for this trib"
4353, "Manual Trib Protection already enabled"
4354, "Manual Trib Protection already enabled"
4401, "Port(s) part of current MSP Group"

4402, "Port(s) not part of MSP Group"
4403, "Port(s) do not indicate valid MSP Group"
4404, "Protection Section Port has connections"
4405, "Invalid Protection Section Port"
4406, "Invalid Working Section Port"
4407, "Incompatible (Mixed Payload) Protection Section Card"
4408, "Payload Manager Switch in Progress"
4409, "Active Payload Manager Unequipped"
4410, "Active Payload Manager Removed"

4411, "Card Fail against Active Payload Manager"

4412, "Card Fault against Active Payload Manager"
4413, "Active Payload Manager not running"
4414, "Working/Protection Section Card Unequipped"
4415, "Working/Protection Section Card Removed"
4416, "Card Fail against Working/Protection Section"
4417, "Card Fault against Working/Protection Section"
4418, "Working/Protection Section Card not running"
4419, "Failed to Set MSP Mode"
4420, "Failed to Set K1/K2 Byte Override"
4421, "Failed to Initiate Request"
4422, "Failed to Initiate MSP Switch on Active Payload Manager"
4423, "Failed to Disable/Enable Path Prot Switching for MSP Group"
4424, "Could not make Association for MSP Group"
4425, "Could not make Disassociation for MSP Group"
4426, "Could not make MSP Connections to Working/Protection Section(s)"
4427, "Could not break MSP Connections to Working/Protection Section(s)"
4428, "Exercise Denied - Higher Priority Req Active and/or Prot Section
in Use"
4429, "Exercise Denied - Bidirectional Mode must be selected"
4430, "Higher Priority or Equal Priority Request Active"
4431, "Must wait 5 Seconds after previous MSP Switch"
4432, "MSP Operation not performed"
4701, "LAN_Service already set to ON"

4702, "Unable to set LAN_service ON"
4703, "LAN_Service already set to OFF"
4704, "Unable to set LAN_service OFF"
4705, "LAN_Service already set to STANDBY"
4706, "Unable to set LAN_service STANDBY"
4707, "Unable to set LAN_service STANDBY"
4708, "There is no card in this slot"
4709, "The card in this slot does not carry DCC traffic"
4710, "This is an illegal port instance"
4711, "This is not a port instance"
4712, "Unable to clear LAPD Administrative State"
4713, "The port instance is not set to this Lapd_link_service"
4714, "MAA already assigned"
4715, "Unable to set MAA"
4716, "This MAA is unassigned"
4717, "Cannot unassign all MAAs"
4718, "Unable to clear MAA"
4751, "External punchthrough already in use"
4752, "External port already in use by <user_name>"
5401, "Slot is a PSU Slot - Cannot be Writen to: <slot>"

5402, "Slot does not contain active card:<slot>"
5403, "Slot already has inventory:<slot>"

8001, "SW not in STABLE or RTC state"

8002, "File transfer active"
8003, "Not Detached"
8004, "Config not in STABLE or RTC state"
8005, "Already Detached"
8006, "Software alignment in progress’
8011, "VC3 format converter fpga firmware corrupt - command failed’
8012, "Cannot find VC3 card image - command failed’
9000, "Not quick enough"

9001, "No such user id"
9002, "Invalid originator password"
9003, "New passwords don't match"
9004, "Password must be 6 to 8 characters"
9005, "Invalid authority password"
9006, "Not authorised to change this password"
9300, "Invalid date or time"

Warning Messages
The following warning messages are output by the TN-1X User Interface.
0, "Non-Enumerated Warning"
3550, "Traffic may be hit"

3551, "Traffic will be hit"
3542, "You have Chosen to Delete A Connection"
3543, "You have Chosen to Delete All Connections"
4001, "This will disable Auto PPS for specified channel"

4002, "This will disable Auto PPS for ALL protected channels"
4003, "This will disable Auto PPS for the specified channel and make
Aggregate A the active path"
4004, "This will disable Auto PPS for ALL protected channels and make
Aggregate A the active path"
4005, "This will disable Auto PPS for the specified channel and make
Aggregate B the active path"
4006, "This will disable Auto PPS for ALL protected channels and make
Aggregate B the active path"
4007, "This will enable Auto PPS on specified channel and may result in a
traffic hit"
4008, "This will enable Auto PPS on ALL protected channels and may result
in traffic hits"
4275, "Slot already equipped, this will re-equip slot"
4750, "This will enable comms traffic through this circuit"

4751, "This will disable comms traffic through this circuit"
4752, "This will enable comms traffic through the LAN port"
4753, "This will disable comms traffic through the LAN port"
4754, "This will change the routing area of the NE"
4755, "This will kill the session"
8050, "Traffic and/or important information may be lost!"

8051, "This action will switch software loads"
8052, "This action will overwrite standby software bank"
8053, "This action will switch configurations"
8054, "This action will overwrite standby configuration bank"
8055, "The mux will leave detached mode"
8056, "The configuration will be defaulted"
8057, "The mux will restart"
8058, "The mux will restart with default configuration"
8060, "Only active configuration table will be updated!"
8061, "This action will switch software loads and traffic will be hit’
8062, "The mux will restart using standby software bank and traffic
will be hit’
end of chapter

!
13-1
Appendix D: KLM payload numbering13-

KLM numbering for STM-1 payloads was introduced to the TN-1X at
Release 7. All references to STM-1 payloads are represented by KLM
numbering.
KLM numbering for VC-3 and VC-12 payloads are shown in Table 13-1 and
Table 13-2 below. These tables also show the equivalent ETSI and Nortel
numbering.
Note: Nortel and ETSI numbering are no longer supported by the TN-1X.
Table 13-1
KLM numbering for VC-3
KLM Number ITU-T (ETSI) Nortel Number
Number
TUG-3 (K) TUG-2 (L) TU-12 (M)
1 0 0 1-21 N/A
2 0 0 22-42 N/A
3 0 0 23-63 N/A
Table 13-2
KLM numbering for VC-12
KLM Number
TUG-3 (K) TUG-2 (L) TU-12 (M) ITU-T (ETSI) Nortel Number
Number
1 1 1 1 1
1 1 2 2 22
1 1 3 3 43
1 2 1 4 4
1 2 2 5 25
1 2 3 6 46
1 3 1 7 7
1 3 2 8 28
1 3 3 9 49
1 4 1 10 10
1 4 2 11 31
1 4 3 12 52
1 5 1 13 13
1 5 2 14 34
—continued—

13-2 Appendix D: KLM payload numbering
Table 13-2
KLM numbering for VC-12 (continued)
KLM Number
ITU-T (ETSI) Nortel Number
TUG-3 (K) TUG-2 (L) TU-12 (M)
Number
1 5 3 15 55
1 6 1 16 16
1 6 2 17 37
1 6 3 18 58
1 7 1 19 19
1 7 2 20 40
1 7 3 21 61
2 1 1 22 2
2 1 2 23 23
2 1 3 24 44
2 2 1 25 5
2 2 2 26 26
2 2 3 27 47
2 3 1 28 8
2 3 2 29 29
2 3 3 30 50
2 4 1 31 11
2 4 2 32 32
2 4 3 33 53
2 5 1 34 14
2 5 2 35 35
2 5 3 36 56
2 6 1 37 17
2 6 2 38 38
2 6 3 39 59
2 7 1 40 20
2 7 2 41 41
2 7 3 42 62
3 1 1 43 3
3 1 2 44 24
3 1 3 45 45
3 2 1 46 6
3 2 2 47 27
3 2 3 48 48
3 3 1 49 9
3 3 2 50 30
3 3 3 51 51
3 4 1 52 12
3 4 2 53 33
3 4 3 54 54
3 5 1 55 15
—continued—

Appendix D: KLM payload numbering 13-3
Table 13-2
KLM numbering for VC-12 (continued)
!
KLM Number
ITU-T (ETSI) Nortel Number
TUG-3 (K) TUG-2 (L) TU-12 (M)
Number
3 5 2 56 36
3 5 3 57 57
3 6 1 58 18
3 6 2 59 39
3 6 3 60 60
3 7 1 61 21
3 7 2 62 42
3 7 3 63 63
—end—
end of chapter

"
14-1
Index 14-
1:N tributary protection 4-98, 4-109 PROT alarms 4-21
status reports 7-2, 7-13 QOSV alarms 4-33, 4-37
R6/R7 names 11-1
A RAU priority 4-21
action logs 7-2, 7-9 RS alarms 4-21, 4-23
active alarms 7-2, 7-9 severities 4-21
active configuration table 9-16 signal alarms 4-113
active LAN connection 4-6 SYNC alarms 4-21, 4-26
active software bank 9-2 thresholds 4-14
adding connections 4-88 transmux alarms 4-21, 4-26
Admin/Cnfg_tbl 9-16 TU alarms 4-21, 4-24
Admin/Sw 9-2 application software 9-2
Admin/User 9-32 committing to version 9-11
administration menu 9-1 downloading 9-2, 9-4
administrative unit alarms 4-21, 4-24 software status 9-4
aggregate units 4-82, 4-98 switching between versions 9-11
alarm events, area addresses 4-7
see alarms AS statistic 4-35, 7-4
alarm logs 7-2, 7-8 assessed seconds 4-35, 7-4
alarms 2-11 AU alarms 4-21, 4-24
action logs 7-2, 7-9 AU4 selection 4-82
active alarms 7-2, 7-9 automatic logout 3-1, 3-4, 8-2
alarm logs 7-2, 7-8 settings 8-5, 8-10
AU alarms 4-21, 4-24 autonomous messages 2-11
card alarms 4-21, 4-27
categories 4-21 B
consequent actions 4-60 background bit errors 4-33, 4-34, 7-4
ES alarms 4-21, 4-23 backing up configuration tables 9-24
external alarms 4-11 basis of frame errors 4-33, 7-4
HP alarms 4-21, 4-24 BBE statistic 4-34, 7-4
lamplocking 4-31 bidirectional operation 4-120
LP alarms 4-21, 4-25 BIP errors 4-33, 7-4
MISC alarms 4-21, 4-26 block errors 4-33, 7-4
monitoring 4-17 brief payload description 4-96
MS alarms 4-21, 4-23 bulk connections 4-89
MSP alarms 4-125 bulk disconnections 4-89
OS alarms 4-21, 4-22
PPI alarms 4-21, 4-25 C
PPS triggers 4-2 card alarms 4-21, 4-27

14-2 Index
case sensitivity 2-1 see connections

CAT connections 4-82
RS232-C Interface 1-1 adding connections 4-88
settings 10-1 bulk connections 4-89
changing passwords 9-32 bulk disconnections 4-89
command prompt 2-1, 2-2 connection types 4-82
detached mode 2-2 defragmentation 4-84
commands dropped AU4s 4-82
confirming 2-9 KLM numbering 2-3, 13-1
entering 2-2 Nortel Networks/ETSI numbering 2-3
parameters 2-4 Nortel/ETSI numbering 13-1
shortcuts 2-2 protected drop connections 4-82
suppressing confirmation 2-9, 8-2, 8-10 removing connections 4-88
comms management 4-6 testing connections 4-89
Config/Alarms/misC 4-31 through connections 4-82
Config/Alarms/Monitoring 4-17 unprotected drop connections 4-83
Config/Alarms/Rau_priority 4-21 user labels 4-89
Config/Alarms/Thresholds 4-14 consequent actions 4-60
Config/carDs 4-97 triggers 4-60
Config/cOmms_management 4-6 control level information 8-2, 8-6
Config/coNnections 4-82 controlling menus 8-2
Config/Cons_act 4-60 controlling message display 8-2
Config/External_alarm 4-11 count-based errors 4-34
Config/Hp_path_trace 4-70 Craft Access Terminal
Config/Hp_paYload_label 4-78 platform 10-1
Config/Lp_path_trace 4-66 see CAT
Config/Lp_paYload_label 4-74 CRCs 4-66, 4-70
Config/MSp 4-118 current mux users 8-2
Config/Payman_Protect 4-106 cyclic redundancy checks 4-66, 4-70
Config/perF_mon 4-33
Config/poRts 4-2, 4-113 D
Config/Pps 4-2 D-Channel bytes 4-6
Config/PunchThrough 4-135 defragmentation 4-84
Config/Sync_source 4-51 detached mode 9-22
Config/tn1x_Card_Switch 4-132 command prompt 2-2
Config/Trib_Protect 4-109 diagnostic menu 5-1
configuration data, Diagnostic/Loopback 5-2
see configuration tables disabling
configuration menu 4-1 alarm monitoring 4-17
configuration tables 1-2, 9-16 LAN connection 4-6
backing up 9-24 PMPs 4-35
committing to version 9-22 RDI alarms 4-17
detached mode 9-22 disconnections 4-88
imposing configuration 9-23 downloading application software 9-2, 9-4
restoring 9-16, 9-18 drop connections 4-82
status of tables 9-18 dropped AU4s 4-82
switching between versions 9-22
confirming commands,
see commands E
connection management, echoing characters 8-2
electrical section alarms 4-21, 4-23

Index 14-3
Element Controller identifying faulty units 5-2

see Preside EC-1 imposing configuration 9-23
enabling inactive configuration table 9-16
alarm monitoring 4-17 inactive software bank 9-2
LAN connection 4-6
PMPs 4-35
installed units 4-98
interface control card 4-98 "
engineering order wire 4-98 intermediate performance logs 7-3
entering commands, inventory information 8-2, 8-7
see commands
EOW 4-98 K
equipping 4-97 K bytes 4-122
error measurement 4-33 KLM numbering 2-3, 13-1
error messages 12-1
error rate thresholds 4-14
errored seconds 4-33, 4-34, 7-4 L
ES alarms 4-21, 4-23 lamplocking 4-31
ES statistic 4-34, 7-4 LAN connection 4-6
ETSI numbering 2-3, 13-1 LAN service 4-7
events 2-11 LAPD settings 4-6, 4-126, 7-2, 7-13
expected path trace strings 4-66, 4-70 local terminal 10-1
expected payload labels 4-74, 4-75, 4-78 local terminal port 8-2, 8-10
external alarms 4-11 log numbers 4-37, 7-5
log report statuses 7-4
logging in 3-1
F logging out 3-1, 3-4
failure holdoff time 4-55 logs,
forced switch see action logs
1:N tributary protection 4-109 see alarm logs
manual tributary protection 4-132, 6-2 see performance logs
multiplexer section protection 4-118 loopbacks 5-2
PPS 4-2, 6-2 low-order path alarms 4-21, 4-25
sync source 4-52 low-order path trace 4-66
foundation software 9-2 low-order payload labels 4-74
frame-based errors 4-33 status reports 4-77
LP alarms 4-21, 4-25
G LP path trace 4-66
generating performance logs 7-3
M
H Maint/Card_Switch 6-2
high-order path alarms 4-21, 4-24 Maint/Operations 6-2
high-order path trace 4-70, 7-2, 7-12 maintenance menu 6-1
high-order payload labels 4-78 manual area addresses 4-7
status reports 4-81 manual logout 3-4
holdover 4-52 manual switch
HP alarms 4-21, 4-24 1:N tributary protection 4-109
HP path trace 4-70 manual tributary protection 4-132, 6-2
HyperTerminal 10-1 multiplexer section protection 4-118
PPS 4-2, 6-2
I sync source 4-52
ICC 4-98 manual tributary protection 4-132, 6-2

14-4 Index
status reports 7-3 O

menu hierarchy 2-1 OOF statistic 4-34, 7-5
menus optical section alarms 4-21, 4-22
administration 9-1 OS alarms 4-21, 4-22
configuration 4-1 out of frame errors 4-34, 7-5
diagnostic 5-1
maintenance 6-1
session 8-1 P
view status 7-1 parameters
messages PDH ports 2-4
autonomous 2-11 SDH aggregate payloads 2-6
controlling message display 8-2, 8-10 SDH high order payloads 2-7
error messages 12-1 SDH ports 2-8
non-autonomous 2-9 SDH tributary payloads 2-5
suppressing confirmation 8-2, 8-10 passwords 9-32
warning messages 12-8 path protection switching 4-2, 6-2, 7-2, 7-12
Microsoft HyperTerminal 10-1 path trace 4-66, 4-70
MISC alarms 4-21, 4-26 payload descriptions 4-95
miscellaneous alarms 4-21, 4-26 payload labels 4-74, 4-78
monitoring payload manager 4-98
alarms 4-17 payload manager protection 4-106
performance 4-33 status reports 7-2, 7-14
monitoring periods 4-33 triggers 4-106
MS alarms 4-21, 4-23 payload status 4-95, 4-96
MSP, payloads 13-1
see multiplexer section protection KLM numbering 2-3
multiplex section alarms 4-21, 4-23 PDH physical interface 4-21, 4-25
multiplexer section protection 4-118 PDH ports 2-4
status reports 7-2, 7-14 performance logs 4-37, 7-3
mux application software, 15 minute reports 7-3
see application software 24 hour reports 7-3
mux clock 6-2 format 7-3
mux configuration tables, generating 7-3
see configuration tables intermediate reports 7-3
mux status information 8-2, 8-8 numbering 7-5
mux users 8-2 report statuses 7-4
storage 4-37
UAT logs 7-3, 7-5
N viewing 4-35, 7-2, 7-10
navigation 2-1 performance monitoring 4-33
special characters 2-1 basis of frame errors 4-33
NE card alarms 4-21, 4-27 error measurement 4-33
NE state 3-3 performance logs 4-37
non-alarm events 2-12 performance monitoring periods 4-33
non-autonomous messages 2-9 performance statistics 4-34
non-reversion flags 4-52 premature termination 4-37, 6-2
non-SSM synchronisation mechanism, through traffic 4-35
see synchronisation performance monitoring points,
Nortel numbering 2-3, 13-1 see PMPs
performance statistics 4-34
PIUs 4-98

Index 14-5
PJE statistic 4-35, 7-5 external alarms 4-13

platform high-order path tracing 4-72
Craft Access Terminal 10-1 high-order payload labels 4-80
plug-in units 4-98 inventory 8-7
PMPs 4-35, 4-36
enabling/disabling 4-35
lamplocking 4-32
LAN service 4-10 "
error measurement 4-33 LAPD 4-10
performance monitoring 4-33 local terminal port 8-10
QOSV alarms 4-37 loopbacks 5-5
pointer justification events 4-34, 4-35, 7-5 low-order path tracing 4-68
power supply unit 4-98 low-order payload labels 4-76
PPI alarms 4-21, 4-25 message confirmation 8-10
PPS mechanism 4-2, 6-2 miscellaneous alarms 4-32
premature termination 6-2 MSP 4-130
15 minute monitoring period 4-37 mux clock 6-5
24 hour monitoring period 4-37 mux status 8-8
Preside EC-1 1-1 mux users 8-5
prompt, passwords 9-34
see command prompt path protection switching 4-5
PROT alarms 4-21 payload manager 4-108, 4-134, 4-137
protected drop connections 4-82 payloads 4-95
PSU 4-98 performance monitoring settings 4-47,
4-48
Q performance monitoring start time 4-49
QOSV alarms 4-33, 4-37 ports 4-103, 4-116
quality levels 4-53 selected AU4s 4-94
definitions 4-54 SES definitions 4-47
quality of service violations 4-33 status reports 7-1
synchronisation sources 4-59
testing connections 4-94
R unsolicited messages 8-10
raising signal alarms 4-113 response messages 2-9
RAU priority 4-21 restoring configuration tables 9-16, 9-18
reading mux clock 6-2 reversion synchronisation 4-52
regenerator section alarms 4-21, 4-23 RS alarms 4-21, 4-23
Release 6/7 alarm names 11-1
removing connections 4-88
reports S
1:N tributary protection 4-112 SDH aggregate payloads 2-6
alarm monitoring 4-19 SDH high order payloads 2-7
alarm settings 4-28 SDH ports 2-8
alarm thresholds 4-16 SDH tributary payloads 2-5
application software 9-15 section overhead 4-6
area addresses 4-10 selecting AU4s 4-82
automatic logout 8-10 SES statistic 4-34, 7-4
basis of frame errors 4-49 SES threshold definitions 4-34
brief payload descriptions 4-96 Session 8-2
cards 4-102 session characteristics 8-2
configuration tables 9-31 session menu 8-1
consequent actions 4-65 setting alarm priorities 4-21
control level 8-6 setting mux clock 6-2

14-6 Index
severely errored seconds 4-33, 4-34, 7-4 non-SSM mechanism 4-53, 4-55
signal alarms 4-113 quality levels 4-53
slot equipping 4-98 reversion 4-52
slots and cards 4-98 software settings 4-52
software banks 9-2 source failures 4-53
software status 9-4 source selection 4-53
special characters 2-1 SSM mechanism 4-53
SRC 4-98 switching sources 4-52
standby LAN connection 4-6 viewing status 7-2, 7-11
status reports wait to restore time 4-55
1:N tributary protection 7-2, 7-13
action logs 7-2, 7-9 T
active alarms 7-2, 7-9 table status 9-18
alarm logs 7-2, 7-8 terminal port 8-2, 8-10
high-order path trace 7-2, 7-12 testing connections 4-89
high-order payload labels 4-81 thresholds
LAPD settings 7-2, 7-13 alarms 4-14
low-order payload labels 4-77 error rates 4-14
manual tributary protection 7-3 through connections 4-82
multiplexer section protection 7-2, 7-14 TM alarms 4-21, 4-26
path protection switching 7-2, 7-12 traffic auto mode 4-113
payload manager protection 7-2, 7-14 traffic standby mode 4-113
performance logs 7-2, 7-3, 7-10 traffic types 7-4
sync source status 7-2, 7-11 transmitted path trace strings 4-66, 4-70
traffic types 7-4 transmitted payload labels 4-74, 4-75, 4-78
STM-1 aggregate units 4-82, 4-98 transmux alarms 4-21, 4-26
STM-1 payloads 2-3, 13-1 tributary protection 4-109
STM-4 aggregate units 4-82, 4-98 tributary unit alarms 4-21, 4-24
subrack controller 4-98 tributary units 4-98
suppressing confirmation, triggering
see commands external alarms 4-11
switching path protection switching 4-2
1:N tributary protection 4-109 payload manager switch 4-106
manual tributary protection 4-132, 6-2 TU alarms 4-21, 4-24
multiplexer section protection 4-118
payload managers 4-106
PPS 4-2, 6-2 U
sync sources 4-51 UAS statistic 4-34, 7-4
SYNC alarms 4-21, 4-26 UAT 4-34
sync source failure 4-53 UAT logs 7-3, 7-5
sync source selection 4-53 unavailable seconds 4-33, 4-34, 7-4
synchronisation unavailable time 4-34
alarms 4-21, 4-26 unequipping 4-97
available sources 4-51 unidirectional operation 4-120
equivalent R6 modes 4-55 unprotected drop connections 4-83
failure holdoff time 4-55 user
forced switch 4-52 classes 3-1
hierarchy 4-51 names 3-1
holdover 4-52 User Interface
non-reversion flags 4-52 case sensitivity 2-1
command prompt 2-1, 2-2

Index 14-7
command shortcuts 2-2

confirming commands 2-9
detached mode 2-2
entering commands 2-2
KLM numbering 2-3, 13-1
logging out 3-4 "
menu hierarchy 2-1
navigation 2-1
parameters 2-4
special characters 2-1
structure 1-1
user labels 4-89
users
classes 1-2
V
view status menu 7-1
View_status 7-2
W
wait to restore time 4-55
warning messages 12-8
warnings xvii
Windows HyperTerminal 10-1

International Optical Networks
Technical Documentation Group
Nortel Networks
Oakleigh Road South
London, N11 1HB
So far as Nortel Networks is aware the contents of this document
are correct. However, such contents have been obtained from a
variety of sources and Nortel Networks can give no warranty or
undertaking and make no representation as to their accuracy. In
particular, Nortel Networks hereby expressly excludes liability for
any form of consequential, indirect or special loss, and loss of
data, loss of profits or loss of business opportunity, howsoever
arising and whether sustained by the user of the information
herein or any third party arising out of the contents of this
document.
*
NORTEL NETWORKS, the Nortel Networks logo, the
Globemark and Unified Networks are trademarks of Nortel
Networks.
Microsoft and Windows are trademarks of Microsoft Corporation.

HyperTerminal is a trademark of Hilgraeve Inc.
IBM is a trademark of International Business Machine Inc.
SDH TRANSMISSION
Nortel TN-1X

Copyright  1997 – 2001 Nortel Networks, All Rights Reserved.
The copyright of this document is the property of Nortel Networks.

Without the written consent of Nortel Networks, given by contract
or otherwise, this document must not be copied, reprinted or
reproduced in any material form, either wholly or in part, and the
contents of this document, or any methods or techniques
available therefrom, must not be disclosed to any other person
whatsoever.
NORTEL NETWORKS CONFIDENTIAL: The information
contained herein is the property of Nortel Networks and is strictly
confidential. Except as expressly authorized in writing by Nortel
Networks, the holder shall keep all information contained herein
confidential, shall disclose it only to its employees with a need to
know, and shall protect it, in whole or in part, from disclosure and
dissemination to third parties with the same degree of care it uses
to protect its own confidential information, but with no less than
reasonable care. Except as expressly authorized in writing by
Nortel Networks, the holder is granted no rights to use the
information contained herein.
Document Number: 323-1061-401
Product Release Number: 9
Document Status: Standard
Date: July 2001
Printed in England

401

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

401

Hochgeladen von

Copyright:

Verfügbare Formate

323-1061-401

Release 9 Standard July 2001

Document Number: 323-1061-401

Copyright  1997 – 2001 Nortel Networks, All Rights Reserved.

Nortel TN-1X Command Line User Interface Guide

Nortel TN-1X Command Line User Interface Guide

User interface 2-1

Getting started 3-1

Configuration menu 4-1

Nortel TN-1X Command Line User Interface Guide

323-1061-401 Release 9 Standard

Config/Hp_path_trace <C H> 4-70

Nortel TN-1X Command Line User Interface Guide

Command details 4-113

Diagnostic menu 5-1

Maintenance menu 6-1

323-1061-401 Release 9 Standard

View status menu 7-1

Session menu 8-1

Administration menu 9-1

Appendix A: Craft Access Terminal 10-1

Appendix B: TN-1X alarms 11-1

Appendix C: TN-1X Messages 12-1

Nortel TN-1X Command Line User Interface Guide

Appendix D: KLM payload numbering 13-1

323-1061-401 Release 9 Standard

Table 2-5 SDH ports 2-8

Nortel TN-1X Command Line User Interface Guide

Table 4-50 A typical synchronisation protection hierarchy 4-51

323-1061-401 Release 9 Standard

Table 6-3 Maint/Operations/Pps 6-3

Nortel TN-1X Command Line User Interface Guide

About this document

For an overview of the capabilities and applications of the TN-1X Add-Drop

User menus and graphical representations of the UI hierarchical menu

Indication of trademarks in this document

Nortel TN-1X Command Line User Interface Guide

Technical support and information

Within Europe: Freephone 00800 8008 9009

Outside of Europe: +44 20 8920 4618

Fax within the United Kingdom: 020 8945 3456

Fax outside of the United Kingdom: +44 20 8945 3456

and by selecting Customer Support.

323-1061-401 Release 9 Standard

Note: A point-and-click interface to the mux’s application software is

The structure of the UI

Nortel TN-1X Command Line User Interface Guide

The TN-1X maintains a configuration table in non-volatile memory to save

323-1061-401 Release 9 Standard

Using this book 

Nortel TN-1X Command Line User Interface Guide

Note: The user interface is not case sensitive.

When commands are executed, additional parameters are often required. If

An error message is displayed if the user input is not recognized. In this

Nortel TN-1X Command Line User Interface Guide

This is the equivalent of typing:

323-1061-401 Release 9 Standard

command entered, this command is selected. Where a command cannot be

For example, on the configuration menu, two of the commands are:

In accordance with the single letter shortcuts:

However, if shortened words are used, then:

KLM payload numbering

Nortel TN-1X Command Line User Interface Guide

Using this book