utstarcom tn780 project/documents/docu… · utstarcom tn780 system description guide release 1.2...

UTStarcom TN780System Description Guide

Release 1.2Revision A

Product Order No. TN780-SDG-1.2-A

UTStarcom Inc.www.utstarcom.com

Copyright© 2004 UTStarcom Inc. All rights reserved.

This Manual is the property of UTStarcom Inc. and is confidential. No part of this Manual may be reproduced for any purposes or transmitted in any form to any third party without the express written consent of UTStarcom.

UTStarcom makes no warranties or representations, expressed or implied, of any kind relative to the information or any portion thereof contained in this Manual or its adaptation or use, and assumes no responsibility or liability of any kind, including, but not limited to, indirect, special, consequential or incidental damages, (1) for any errors or inaccuracies contained in the information or (2) arising from the adaptation or use of the information or any portion thereof including any application of software referenced or utilized in the Manual. The information in this Manual is subject to change without notice.

TrademarksUTStarcom® is a trademark of UTStarcom Inc.

GoAhead is a trademark of GoAhead Software, Inc.

All other trademarks in this Manual are the property of their respective owners.

UTStarcom TN780 and UTStarcom Optical Line Amplifier Regulatory ComplianceFCC Class A

This device complies with Part 15 of the FCC rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. Modifying the equipment without UTStarcom's written authorization may result in the equipment no longer complying with FCC requirements for Class A digital devices. In that event, your right to use the equipment may be limited by FCC regulations, and you may be required to correct any interference to radio or television communications at your own expense.

DOC Class A

This digital apparatus does not exceed the Class A limits for radio noise emissions from digital apparatus as set out in the interference-causing equipment standard titled “Digital Apparatus," ICES-003 of the Department of Communications.

Cet appareil numérique respecte les limites de bruits radioélectriques applicables aux appareils numériques de Classe A prescrites dans la norme sur le matériel brouilleur: "Appareils Numériques," NMB-003 édictée par le Ministère des Communications.

Warning

This is a class A product. In a domestic environment this product may cause radio interference in which case the user may be required to take adequate measures.

FDA

This product complies with the DHHS Rules 21 CFR Subchapter J, Section 1040.10, Applicable at date of manufacture.

Contents

About this DocumentObjective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Technical Assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Chapter 1 - IntroductionDigital Optical Network Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

UTStarcom TN780 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3UTStarcom Optical Line Amplifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

IQ Networking Operating System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

MPower Network Management Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7UTStarcom MPower Graphical Node Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8UTStarcom MPower Element Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Release 1.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

Chapter 2 - Network ApplicationsTN780 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Reconfigurable Digital Add/Drop Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Digital Repeater Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

TN780 System Description Release 1.2UTStarcom Inc.

Page ii Contents

Digital Terminal Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Junction Node Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Network Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Point-to-point Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Linear Add/Drop Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Hub and Spoke Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Ring Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Chapter 3 - Digital Optical Networking SystemsTN780 Hardware Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

DTC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2DTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Management Control Module (MCM-A, MCM-B). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7Tributary Optical Module-10G-SR1 (TOM-10G-SR1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7Tributary Optical Module-2.5G-SR1 (TOM-2.5G-SR1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Tributary Optical Module-2.5G-IR1 (TOM-2.5G-IR1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Tributary Optical Module-1G-LX (TOM-1G-LX1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Tributary Adapter Module-10G (TAM-10G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Tributary Adapter Module-2.5G (TAM-2.5G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Tributary Adapter Module-1G (TAM-1G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9Digital Line Module (DLM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

DMC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11

Optical Line Amplifier Hardware Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13OTC Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

OTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14Optical Management Module (OMM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16Optical Amplifier Module (OAM-CX-A, OAM-CX-B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16

System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17Operations Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17

Management Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17Transport Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18

Client/Trib Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18Line Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18

Input/Output Alarm Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19Office Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19Alarm Cutoff (ACO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19Parallel Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20

Datawire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20

System Data Plane Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21Digital Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21

Tributary Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22Digital Transport Frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23Digital Transport Network Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

UTStarcom Inc.TN780 System Description Release 1.2

Page iiiContents

DTF Section Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24DTF Line Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24DTF Path Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25Digital Transport Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25Digital Transport Frame Alignment Overhead (DTFA-OH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25DTF Section Overhead (DTS-OH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25DTF Line Overhead (DTL-OH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26DTF Path k Overhead (DTPk-OH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26Digital Transport Payload Envelope k (DTEk) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26FEC Overhead (FEC-OH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26Bandwidth Grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26Reconfigurable Add/Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27Digital Regeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28Digital Conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28Digital Transport Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28Digital Transport Maintenance Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29

Optical Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Optical Transport Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Optical Amplification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32Optical Conditioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32Optical Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33Optical Transport Maintenance Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33

Data Plane Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34

System Control Plane Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35Intra-chassis Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35Inter-chassis Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37Inter-node Control Plane (over OSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38

System Management Plane Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40

Digital Terminal Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41

Digital Add/Drop Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44

Digital Repeater Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49

Optical Line Amplifier Site Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

Chapter 4 - IQ Network Operating SystemFault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Alarm Surveillance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Defect Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Failure Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3Alarm Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3Alarm Masking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6Local Alarm Summary Indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6Alarm Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7Network Fault Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10


Page iv Contents

Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10Maintenance and Troubleshooting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11

Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12PRBS Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Hairpin Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13Trace Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

Equipment Management and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15Managed Object Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15System Discovery and Inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16

Circuit Pack Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17Optical Data Plane Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17

Circuit Pack Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19Circuit Pack Auto-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19Circuit Pack Pre-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19

State Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19Administrative State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20Operational State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21Service State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21

Service Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23Manual Cross-connect Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23Dynamically Signaled SNC Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26Service Pre-provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27

Protection Group Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28

Performance Monitoring and Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31PM Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

Real-time PM Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32Historical PM Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32PM Thresholding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33Suspect Interval Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33PM Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33PM Data Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34

Security and Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35User Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37Security Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39Security Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40

Software Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41Software Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41Software Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41Remote Hardware FPGA Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42


Page vContents

Database: Download/Backup/Restoration/Rebranding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43Database Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43Database Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43Database Restoration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44Database rebranding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46

IQ GMPLS Control Plane Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47OSPF-TE Routing Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47

Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-48Traffic Engineering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49Constrained Shortest Path Route Computation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51

GMPLS Signaling (RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51Handling Fault Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51Topology Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52

Control Link Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52GMPLS Link Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52

IQ Management Plane Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53DCN Communication Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53

DCN Link Failure Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54MCM-B/OMM Failure Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55

Management Application Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-58

Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-58Time-of-Day Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59

Chapter 5 - MPower Management SoftwareMPower Graphical Node Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4MPower GNM Features in Release 1.2: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5Inventory Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10

Network Topology Display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Software Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11

Fault Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12Equipment Configuration and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13Service Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14

MPower EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15Administrative Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15Release Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Network Topology Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17

Network Element Information File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18Dynamic Seed File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21Discovery Key Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21Topology Shallow Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22


Page vi Contents

Topology Deep Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Network Topology Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25

Network-level OAM&P Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26Network Level Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26Network Level Inventory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27End-to-end Circuit Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27Circuit Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30

MPower EMS Security and Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31User Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33Security Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33Security Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34

MPower EMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34MPower EMS Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35MPower EMS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35

MPower EMS Platform Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36MPower Server Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36MPower Client Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37

MPower Simple Network Management Protocol (SNMP) Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38MPower SNMP Trap Agent Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38Alarm Trap Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38MPower SNMP Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39MPower SNMP Configurable Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39Configurable Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39Configuring MPower SNMP Trap Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40

SNMP MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40Standard MIB Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40UTStarcom Enterprise MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40

Appendix A - TN780 PM DataOptical PM Parameters and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

DTF PM Parameters and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10

FEC PM Parameters and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15

Client Signal PM Parameters and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

OSC PM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20

Appendix B - Optical Channel PlanTN780 Optical Channel Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2

Appendix C - Acronyms


Figures

Figure 1-1 Digital Optical Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3Figure 1-2 UTStarcom MPower Network Management Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7Figure 1-3 Digital Optical Network and UTStarcom MPower Management Solution . . . . . . . . . . . . . . . . . . . 1-8Figure 2-1 TN780 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Figure 2-2 Point-to-point Network - Single Span. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Figure 2-3 Point-to-point Network - Multiple Spans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Figure 2-4 Linear Add/Drop Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Figure 2-5 Hub and Spoke Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Figure 2-6 Ring Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Figure 3-1 DTC Front View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Figure 3-2 DMC with Two Half-width DCMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12Figure 3-3 DMC with One Full-width DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12Figure 3-4 OTC Front View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14Figure 3-5 DTC Digital and Optical Transport Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22Figure 3-6 Digital Transport Network Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24Figure 3-7 Digital Transport Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25Figure 3-8 DTC Grooming Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27Figure 3-9 Optical Transport Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31Figure 3-10 Optical Signal Multiplexing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32Figure 3-11 Logical Illustration of Intra-chassis Control Plane in a DTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36Figure 3-12 Logical Illustration of Intra-chassis Control Plane in a OTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36Figure 3-13 Logical Illustration of Inter-chassis Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38Figure 3-14 DTC with Minimum Hardware for a Digital Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-41Figure 3-15 Hardware Chassis Configuration of a 400Gbps Digital Terminal. . . . . . . . . . . . . . . . . . . . . . . . . 3-42Figure 3-16 Hardware Logical Configuration of a 400Gbps Digital Terminal . . . . . . . . . . . . . . . . . . . . . . . . . 3-43Figure 3-17 DTC with Minimum Hardware of a Digital Add/Drop Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44


Page viii Figures

Figure 3-18 Hardware Physical Configuration of a 400Gbps Digital Add/Drop Node . . . . . . . . . . . . . . . . . . .3-46Figure 3-19 Hardware Logical Configuration of a 400Gpbs Digital Add/Drop Node . . . . . . . . . . . . . . . . . . . .3-47Figure 3-20 Hardware Physical Configuration of a 200Gbps Digital Add/Drop Node . . . . . . . . . . . . . . . . . . .3-48Figure 3-21 Hardware Physical Configuration of a 200Gbps Digital Repeater Node . . . . . . . . . . . . . . . . . . .3-49Figure 3-22 Hardware Logical Configuration of a 200Gpbs Digital Repeater Node . . . . . . . . . . . . . . . . . . . .3-50Figure 3-23 Hardware Physical Configuration of an Optical Line Amplifier Node . . . . . . . . . . . . . . . . . . . . . .3-51Figure 4-1 Alarm reporting behavior during ARC period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9Figure 4-2 Loopbacks supported by the TN780 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12Figure 4-3 PRBS Tests Supported by the TN780 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13Figure 4-4 Trace Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14Figure 4-5 Managed Object Entities and Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16Figure 4-6 Express Cross-connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24Figure 4-7 Add/Drop Cross-connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-25Figure 4-8 Hairpin Cross-connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26Figure 4-9 TribY-cable Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-30Figure 4-10 Physical Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-48Figure 4-11 Single Network with Topology Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-49Figure 4-12 Service Provisioning Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-49Figure 4-13 Illustration of Using Node Inclusion Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-50Figure 4-14 Redundant DCN Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-54Figure 4-15 DCN Link Failure Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-55Figure 4-16 MCM/OMM Failure Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-56Figure 4-17 Management Application Proxy Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-57Figure 4-18 Using Static Routing to Reach External Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-59Figure 4-19 NTP Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-60Figure 5-1 Digital Optical Network and UTStarcom MPower Management Solution . . . . . . . . . . . . . . . . . . .5-1Figure 5-2 MPower GNM Main View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5Figure 5-3 Multi-window display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6Figure 5-4 MCM Redundancy Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7Figure 5-5 10G Clear Channel Service Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8Figure 5-6 Protection Group Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9Figure 5-7 NCT ports on MPower GNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10Figure 5-8 MPower EMS Administrative Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16Figure 5-9 Network Information File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19Figure 5-10 Add Administrative Domain Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-20Figure 5-11 Network Topology Map View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-23Figure 5-12 Junction Site Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-24Figure 5-13 Circuit Layout Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-29Figure 5-14 Cross-Connect Circuit Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-30Figure 5-15 MPower EMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-35


Tables

Table 1-1 Release 1.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10Table 3-1 DTC Hardware Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Table 3-2 OTC Hardware Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13Table 4-1 Access Privilege Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37Table 5-2 MPower Server Platform Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37Table B-1 TN780 Optical Channel Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2Table C-1 List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1


Page x Tables


About this Document

This chapter provides an overview of this document. It includes:

“Objective” on page xi

“Audience” on page xi

“Document Organization” on page xii

“Related Documents” on page xiii

“Conventions” on page xiv

“Technical Assistance” on page xiv

ObjectiveThis guide provides an introduction and reference to Digital Optical Networking Systems which includes the UTStarcom® TN780 (referred to as the TN780) and UTStarcom Optical Line Amplifier (referred to as the Optical Line Amplifier) used to build Digital Optical Network®. This guide also includes UTStarcom IQ Network Operating System (referred to as the IQ) operating TN780 and Optical Line Amplifier network elements, and UTStarcom MPower Management Suite (referred to as the MPower) provided to manage UTStarcom products.

AudienceThe primary audience for this guide includes network planners, network operations personnel and system administrators who are responsible for deploying and administering the Digital Optical Network. This guide assumes that the reader is familiar with the following topics and products:

Basic internetworking terminology and concepts


About this DocumentPage xii

Dense Wavelength Division Multiplexing (DWDM) technology and concepts

Document OrganizationThe following table lists the chapters and its description covered in this manual.

Chapter Number: Title Description

CHAPTER 1:

“Introduction“

Provides an introduction to Digital Optical Network, TN780, Optical Line Amplifier, IQ and MPower products. This chapter also includes a list of Release 1.2 hardware and software features.

CHAPTER 2: “Network Appli-cations“

Describes various configurations and network topologies supported by the TN780 network element.

CHAPTER 3:

“Digital Optical Networking Systems“

Describes the TN780 and Optical Line Amplifier network elements’ hard-ware architecture. This chapter also includes a description of the data plane architecture, control plane architecture, the transport interfaces and the circuit packs.

CHAPTER 4:

“IQ Network Operating Sys-tem“

Describes the OAM&P functions provided by the IQ Network Operating System. This chapter also includes a description of various system fea-tures, such as Generalized Multiprotocol Label Switching (GMPLS) Con-trol Plane, and IP Addressing.

CHAPTER 5:

“MPower Management Soft-ware“

Provides an introduction to UTStarcom MPower Management Suite which includes MPower Element Management System (referred to as MPower EMS) and MPower Graphical Node Manager (referred to as MPower GNM) applications.

Appendix A:

“TN780 PM Data“

Describes the Performance Monitoring (PM) parameters reported by UTStarcom TN780 and Optical Line Amplifier network elements.

Appendix B:

“Optical Channel Plan“

Provides the optical channel plan supported by the TN780 and Optical Line Amplifier.

Appendix C:

“Acronyms“

Provides a list of acronyms and their definitions used in UTStarcom Technical Publications.

TN780 System Description Release 1.2 UTStarcom Inc.

Page xiiiRelated Documents

Related DocumentsThe reader can refer to the following documents to further understand the content of this manual.

Document NameDocument Order

Number Description

UTStarcom TN780 Hardware Description

TN780-HWG-1.2-A Provides the detailed description of the Digital Optical Net-work hardware modules. This manual covers the func-tional diagrams, status indicators and technical specifications for each module.

UTStarcom TN780 Maintenance and Trou-bleshooting Guide

DNT-MTG-1.2-A Provides the routine maintenance and alarm troubleshoot-ing procedures for UTStarcom TN780 and Optical Line Amplifier network elements. This guide includes the rou-tine hardware and software maintenance procedures and various troubleshooting tools. A comprehensive list of alarms and events, and alarm clearing procedures are also included.

UTStarcom TL1 User Guide

TN780-TL1G-1.2-A Describes the TL1 interface supported by UTStarcom TN780 and Optical Line Amplifier network elements. This guide includes the description of the supported TL1 com-mands and the procedures for the commonly performed OAM&P functions.

UTStarcom MPower GNM User Guide

MP-GNUG-1.2-A Describes UTStarcom MPower GNM interface used to manage UTStarcom TN780 and Optical Line Amplifier net-work elements. This guide also includes the procedures for the commonly performed OAM&P functions.

UTStarcom MPower EMS User Guide

MP-EUG-1.2-A Describes the UTStarcom MPower EMS interface used to manage the Digital Optical Network comprised of TN780 and Optical Line Amplifier network elements. This guide also includes the procedures for the commonly performed OAM&P functions.

UTStarcom MPower EMS Administrator Guide

MP-EAG-1.2-A Describes the MPower EMS server installation, adminis-tration, security management and routine maintenance procedures.


About this DocumentPage xiv

ConventionsThe following table lists the document conventions used within this manual.

Technical AssistanceCustomer support for UTStarcom products is available 24 hours a day, seven days a week. For information or assistance with any UTStarcom product, please contact an UTStarcom Customer Service and Technical Support resource using any of the methods listed below.

UTStarcom China

Telephone: 86-10-85205588

Fax: 86-10-85205599

UTStarcom USA

Telephone: 1-510-864-8800

Fax: 1-510-864-8802

UTStarcom corporate website: www.utstarcom.com

Convention Meaning Example

italic font Book or manual titles and important information.

Refer to the UTStarcom TL1 User Guide.

Note: Means reader must make note.

Note: The external timing syn-chronization is not supported in Release 1.2.

TN780 System Description Release 1.2 UTStarcom Inc.

CHAPTER 1

Introduction

This chapter provides an introduction to Digital Optical Network, UTStarcom Digital Optical Networking Systems, MPower Network Management, and Release 1.2 features in the following sections:

“Digital Optical Network Overview” on page 1-2

“IQ Networking Operating System Overview” on page 1-5

“MPower Network Management Overview” on page 1-7

“Release 1.2 Features” on page 1-10


Digital Optical Network OverviewPage 1-2

Digital Optical Network OverviewUTStarcom delivers the Digital Optical Network solution, referred to as Digital Optical Network. Digital Optical Network provides the ability to multiplex, transport, add, drop, groom, switch and protect SONET, SDH, Ethernet, and other services inexpensively, transparently, reliably, flexibly and quickly. Digital Optical Network allows the construction of a single unified optical transport network that scales from metro to long haul applications.

UTStarcom offers Digital Optical Networking Systems which help carriers build Digital Optical Networks. The UTStarcom TN780 is the first Digital Optical Networking System which provides digital add/drop and bandwidth management capabilities. In addition, UTStarcom Optical Line Amplifiers are provided to extend the optical reach between the TN780s.

Digital Optical Network, as shown in Figure 1-1 on page 1-3, is comprised of TN780s deployed anywhere client access is desired and Optical Line Amplifiers where client access is not anticipated. The links between the TN780s, referred to as the Digital Links, isolate analog engineering and impairments within that Digital Link. Customers can progressively deploy the transport network with TN780s at more points of presence, interconnected by Digital Links, when and where capacity is required, without re-engineering the network.


3Introduction

Figure 1-1 Digital Optical Network

UTStarcom TN780The UTStarcom TN780, referred to as the TN780, provides digital bandwidth management within a Digital Optical Network. The TN780 provides a means for direct access to client data at 10Gbps, and 2.5Gbps

Client

Client Client

Client

Digital Links

Client

Client Client

Client

Digital Links

UTStarcom TN780

UTStarcom Optical Line Amplifier


Digital Optical Network OverviewPage 1-4

wavelength granularity at a site, allowing flexible selection of whether to multiplex, add/drop, amplify, groom, or wavelength interchange individual channels. The TN780 can be equipped in a variety of network configurations using a common set of circuit packs. Refer to “TN780 Configurations” on page 2-2 for a detailed description of the various configurations supported by the TN780. The detailed description of the TN780 hardware is provided in CHAPTER 3.

UTStarcom Optical Line AmplifierThe UTStarcom Optical Line Amplifier, referred to as the Optical Line Amplifier is used to extend the optical reach between TN780s. The Optical Line Amplifier is deployed at locations where customer access is not anticipated. The detailed description of the Optical Line Amplifier hardware is provided in CHAPTER 3.


5Introduction

IQ Networking Operating System OverviewDigital Optical Network architecture includes an intelligent embedded control software called the IQ Network Operating System, referred to as the IQ. The IQ operating on TN780 and Optical Line Amplifier network elements provides reliable and intelligent interfaces for the Operation, Administration, Maintenance and Provisioning (OAM&P) tasks performed by the operating personnel and management systems. The IQ also includes an intelligent Generalized Multiprotocol Label Switching (GMPLS) control plane architecture which provides automated end-to-end service provisioning and a management plane architecture which provides reliable and redundant communication paths for the management traffic between the management systems and the network elements.

IQ supports the following features:

Operates on TN780 and Optical Line Amplifier network elements.

Standards based operations and information model (ITU-T, TMF 814, Telcordia).

Extensive fault management capabilities including current alarm reporting, alarm reporting inhibi-tion, hierarchical alarm correlation, configurable alarm severity assignment profile, and event log-ging.

Network diagnostics capability including digital path and digital section level loopbacks, circuit-level Pseudo Random Bit Sequence (PRBS) 31 and detection, and SONET/SDH J0 monitoring at the tributaries.

Automatic equipment configuration and equipment pre-configuration.

Fully automated network topology discovery including physical topology and service topology views.

Robust end-to-end automated circuit routing and provisioning utilizing GMPLS routing and signaling protocols including the ability to pre-configure circuits, optional selection of SNC path utilizing con-straint based routing, the option to specify the channel number within an OCG for a SNC, and the option to specify 10G or 2.5G sub-channel to specify an explicit route.

Flexible software and configuration database management including remote software upgrade/roll-back, configuration database backup and restore, and bulk File Transfer Protocol (FTP) transfers.

Analog performance monitoring at every node, digital performance monitoring at TN780s, native cli-ent signal performance monitoring at tributaries.

Supports Network Timing Protocol (NTP) to synchronize the timestamps on all alarms, events and Performance Monitoring (PM) data across the network.

GR-815-CORE based security administration.

Hitless software and FPGA upgrades.

Multi-chassis configurations utilizing the Nodal Control and Timing (NCT) ports located on the I/O panel of the TN780 and Optical Line Amplifier network elements.

Redundant control plane communication paths utilizing two Management Control Modules-B (MCM-B)/Optical Management Modules (OMM) which provide shelf management and node management functions.


IQ Networking Operating System OverviewPage 1-6

Redundant management plane communication paths utilizing Gateway Network Element and Man-agement Proxy services.

Telcordia compliant TL1 for OSS integration.

Open integration interfaces including TL1, XML, and flat files.

Refer to CHAPTER 4 for a detailed description of the features.


7Introduction

MPower Network Management OverviewMPower Network Management Suite, referred to as the MPower, is a scalable, robust, carrier class management software suite which simplifies Digital Optical Network operation and OSS integration. The MPower is comprised of both management applications as well as OSS integration servers for flow-through operations integration with other management systems. The MPower architecture, as shown in Figure 1-2 on page 1-7, addresses various elements of the NEL, EML, NML, and SML layers of the ITU-T TMN architecture by empowering and embedding much of the networking intelligence into the network elements.

Figure 1-2 UTStarcom MPower Network Management Suite

MPower management architecture employs a network-is-master model, allowing the network itself to asynchronously inform and update all registered management clients and mitigate any synchronization or accuracy issues. The network state and status is automatically discovered and reported to the management client. This network-is-master model enables each network element to be managed by multiple management applications, allowing for full management redundancy and allowing each management application to maintain synchrony with what is occurring within its purview.

In the current release, MPower includes the following applications:

UTStarcom MPower Graphical Node Manager

UTStarcom MPower Element Management System

OSS Integration Servers

MPower EMSMPower GNM

TL1 XML / TCP

Planning & Design

MoM NMS

OSS’s 3rdparty systems

Data Communications NetworkHTTP / XML

OSC / GMPLS Control Plane

OSS Integration Servers

MPower EMSMPower GNM

TL1 XML / TCP

Planning & Design

MoM NMS


Planning & Design

MoM NMS


Data Communications NetworkHTTP / XML

OSC / GMPLS Control PlaneOSC / GMPLS Control Plane


MPower Network Management OverviewPage 1-8

Figure 1-3 Digital Optical Network and UTStarcom MPower Management Solution

UTStarcom MPower Graphical Node ManagerUTStarcom MPower Graphical Node Manager, referred to as the MPower GNM, is a web-based application which provides on-site craft access to local or remote nodes. The MPower GNM provides users access to key management functional areas at the network element level, including:

Extensive fault management and performance monitoring

Automated end-to-end circuit provisioning

System and equipment configuration

Topology and inventory management

Maintenance and diagnostics

Security administration

Refer to CHAPTER 5 for a detailed description of the MPower GNM.


9Introduction

UTStarcom MPower Element Management SystemUTStarcom MPower Element Management System, referred to as the MPower EMS, is a real-time management software application for administering and managing the Digital Optical Network. The MPower EMS provides end-users in the Network Operations Center (NOC) with an integrated network-level and network-element-level view. The MPower EMS is comprised of distinct server applications and client applications. The MPower EMS employs distributed client-server technology to allow deployment of server components across multiple computing platforms. This distributed model enables the MPower EMS to scale and support thousands of network elements as well as hundreds of end-users of the web-based Graphical User Interface (GUI). The MPower EMS supports following features:

Network-wide real-time fault management and monitoring, including current alarm summary, histori-cal event logs, and threshold crossing alerts.

Multiple topological views, topology updates, auto-discovery and network synchronization.

Network equipment inventory reporting with comprehensive manufacturing information.

Point and click circuit provisioning application and circuit inventory views, with correlated alarm sta-tus.

Scheduled network element configuration backup and restoration.

Historical performance monitoring collection and archiving.

Network element software distribution and upgrade.

Network element and MPower EMS security administration.

Automated MPower EMS client installation.

MPower EMS Server redundancy.

Refer to CHAPTER 5 for a detailed description of the MPower EMS.


Release 1.2 FeaturesPage 1-10

Release 1.2 FeaturesRelease 1.2 features are summarized in Table 1-1 on page 1-10.

Table 1-1 Release 1.2 Features

Feature Description

Network Topologies Point-to-point, linear ADM, Hub and Spoke, and Ring topologies.

Multi-junction System Application

Allows engineers to deploy interconnected rings that will simplify network designs and provide flexible networking implementations.

UTStarcom TN780 Net-work Element

Digital Optical Networking System which provides digital add/drop and bandwidth management capabilities.

Multi-Chassis configuration Enables users to scale system capacity of deployed network equipment in new or existing systems allowing for multi-chassis/multi-BMM and expanded DLM config-urations.

UTStarcom Optical Line Amplifier Network Element

Optical line amplifier provided to extend the optical reach between the TN780s.

6x24dB Optical Reach Within a digital link between adjacent TN780s, up to six 24dB optical spans and up to five Optical Line Amplifiers are supported.

DTC (Digital Transport Chassis)

Supports Digital Optical Node functions; 400Gbps per fiber pair.

MCM-A (Management Control Module)

Performs management and control functions for the TN780 network element.

MCM-B Performs management and control functions for the TN780TN780 network ele-ment. Provides enhanced CPU frequency, FLASH memory for the persistence storage, and Physical memory (SDRAM).

MCM redundancy Allows for one MCM-B to be active and the other MCM-B to be stand-by. The active MCM-B terminates the management interfaces to the system and provides all of the control and monitoring functions for the system. The standby MCM-B maintains synchronization with its active partner so that it is capable of becoming active at any time, but is not actively involved in system control or monitoring.

BMM-C-4-A (Band Mux Module)

Performs optical multiplexing and demultiplexing of four Optical Carrier Groups (OCG). Each OCG contains ten 10Gbps DWDM channels. Three types of BMM-C-4-As are provided with various combinations of fixed gain, variable gain and mid-stage access for dispersion compensation fiber.

BMM-C-4-B Performs optical multiplexing and demultiplexing of four Optical Carrier Groups (OCG). Each OCG contains ten 10Gbps DWDM channels. Contains a new EDFA. Three types of BMM-C-4-Bs are provided with various combinations of fixed gain, variable gain and mid-stage access for dispersion compensation fiber.

BMM-C-8-A Performs optical multiplexing and demultiplexing of eight Optical Carrier Groups (OCG). Each OCG contains ten 10Gbps DWDM channels. Three types of BMM-C-8s are provided with various combinations of fixed gain, variable gain and mid-stage access for dispersion compensation fiber.


11Introduction

DLM (Digital Line Module) Performs add/drop or switching of ten 10Gbps optical channels. Performs For-ward Error Correction (FEC) encoding/decoding on each channel. There are 8 types of DLMs, one for each OCG. Each DLM can house up to five TAM-2-10G, TAM-4-2.5G and TAM-4-1G modules.

TAM-2-10G (Tributary Adapter Module)

Houses two 10G Tributary Optical Modules (TOM) and adapts client signals for transport over the Digital Optical Network. Up to two TOM-10G-SR-1, and/or TOM-10G-IR2 modules are supported within each TAM-2-10G.

TAM-4-2.5G (Tributary Adapter Module)

Houses four 2.5G Tributary Optical Modules and adapts client signals for trans-port over Digital Optical Network. Up to four TOM-2.5G-SR-1 and/or TOM-2.5G-IR1 modules are supported within each TAM-4-2.5G.

TAM-4-1G (Tributary Adapter Module)

Houses four 1GbE Tributary Optical Modules and adapts client signals for trans-port over Digital Optical Network. Up to four TOM-1G-LX modules are supported within each TAM-4-1G.

TOM-10G-SR1 (Tributary Optical Module)

Pluggable XFP optical module supporting client interface operating at 1550nm; 10km reach; LC connector; SONET OC-192, SDH STM-64, 10GbE LAN Phy, 10G Clear Channel and 10GbE WAN Phy client signals.

TOM-10G-IR2 (Tributary Optical Module)

Pluggable XFP optical module supporting client interface operating at 1550nm; 40km reach; LC connector; SONET OC-192, SDH STM-64, 10GbE LAN Phy, 10G Clear Channel and 10GbE WAN Phy client signals.

TOM-2.5G-SR1 (Tributary Optical Module)

Pluggable SFP optical module supporting client interface operating at 1310 nm; 2km reach; SONET OC-48 and SDH STM-16 client signals.

TOM-2.5G-IR1 (Tributary Optical Module)

Pluggable SFP optical module supporting client interface operating at 1310 nm; 15km reach; SONET OC-48 and SDH STM-16 client signals.

TOM-1G-LX (Tributary Optical Module)

Pluggable SFP optical module supporting client interface operating at 1310 nm; 5km reach; 1G Ethernet client signals.

OTC (Optical Transport Chassis)

Supports Optical Line Amplification function.

OAM (Optical Amplifier Module)

Performs uni-directional optical amplification. Up to two OAMs can be housed in one OTC. Three types of OAMs are provided with various combinations of fixed gain, variable gain and mid-stage access for dispersion compensation fiber.

OMM (Optical Manage-ment Module)

Performs management and control functions for the Optical Line Amplifier network element.

Office alarms Supports 20 external alarm inputs and 20 control outputs.

Datawire Two 10Mbps Ethernet AUX ports to carry customer management data.

Management interfaces Craft serial DCE (DB-9 female/RS232 interface) and craft Ethernet (10Mbps RJ45 interface) on MCM/OMM, and two 10/100Mbps DCN ports on the I/O panel of the DTC and OTC.

OSC (Optical Supervisory Channel)

100Mbps Optical Supervisory Channel for inter-node communication.


Feature Description



10G Clear Channel Ser-vice

Provides services and technologies transported at the 10G SONET/SDH line rate in unframed payloads.

Laser safety (ALS) Automatic Laser Shutdown (ALS) during fiber cut.

Automatic channel turn-up Automatically adjusts the power of the amplifiers across the entire link while turn-ing up new channels or deleting existing channels.

In-service upgrade to Add/Drop

The Digital Repeater sites can be upgraded to an Add/Drop configuration in-ser-vice by populating the tributary modules.

Eighty channel scalability The limited availability of eighty channel BMMs will allow deployment of equip-ment that will support eighty channels in the future.

Automatic end-to-end cir-cuit provisioning

The OSPF routing and GMPLS signaling protocols are implemented to support the network topology discovery and end-to-end service provisioning and manage-ment.

Y-cable Protection Enables 1+1 protection of diverse Sub Network Connection (SNC) paths through the Digital Optical Network for sub-50ms switching. Y-cable protection increases the overall reliability and service up-time of the optical path.

Enhanced digital transport path grooming

Enhanced inter-DLM cross-connecting allows more flexible and efficient use of bandwidth at add drop and multi-junction sites.

Export all alarms and events

A feature provided in MPower EMS and MPower GNM that gives the user the abil-ity to export all alarms and events.

Circuit Tracing An EMS feature that gives the user the ability to trace a circuit by displaying inter-mediate points in the circuit.

Equipment auto-configura-tion and pre-configuration

In auto-configuration the software can automatically detect the hardware and con-figure. In pre-configuration the users can pre-configure the hardware before it is installed.

Software upgrade protec-tion

Allows the system the ability to gracefully “fall-back” or “down-grade” to a prior release in the rare event that a failure is experienced during the upgrade process.

Remote Hardware FPGA Upgrade

The TN780 hardware modules that support the ability to be remotely upgraded include all types of TAMs, DLMs and BMMs. The ability to remotely upgrade hard-ware using a controlled process is integrated in Release 1.2.

Network Information File Editor

An EMS feature that allows for the addition of administrative domains and Node information updates while the EMS core server is running.

Optical PM, Digital PM, SONET/SDH PM

Optical PM data collection is supported on the Optical Line Amplifier and the TN780 network elements. Digital PM data collection is supported on the TN780 at the Terminal, Add/Drop and Digital Repeater sites. SONET/SDH PM data collec-tion is supported in the TN780 network element for the tributary interfaces at the Terminal and Add/Drop sites. Both, current and historical PM counters are sup-ported. The counters can be reset.

PM data upload Automatic and periodic transfer of PM data in Comma Separated Value (CSV) for-mat enabling customers to integrate with their management applications.


Feature Description


13Introduction

Gateway Network Ele-ment (GNE) and MAP (Management Application Proxy) functions

Minimizes the number of external DCN IP addresses and provides proxy services to management traffic to manage network elements that do not have direct DCN connectivity. Also supports redundant management access to all network ele-ments and automatic recovery from single failure in communications path.

Non-Modal Multi-Window display

Facilitates the ability to launch numerous windows with the GUI, creating ease of provisioning, alarm correlation, and troubleshooting.

MPower Graphical Node Manager (GNM) GUI

Supports web based Graphical User Interface (GUI) to manage a network ele-ment. MPower GNM GUI resides on the network element and has the same look and feel as the MPower EMS. MPower GNM supports log-in to remote network elements utilizing OSC.

- Event/Alarm management

- Topology navigation

- Inventory management

- Export inventory information in TSV and CSV format

- Automatic end-to-end circuit provisioning

- Manual cross-connect provisioning

- Historical and real-time performance monitoring

- Network element security management

- Software download

- Configuration database backup/restore

MPower Element Manage-ment System

Provides full fault management, configuration management, service provisioning, performance management, and security management (FCPS) support of TN780 and Optical Line Amplifier network elements and network-level end-to-end control and monitoring.

- Network/network element level event/alarm management

- Network/network element level topology management

- Network/network element level inventory management

- Network element PM archiving and scheduling

- Network element PM report generation

- Network element and MPower EMS security management

- Network element software download

- Network element configuration database backup/restore

MPower SNMP Trap agent - SNMPv2C agent with dynamic trap registration

- Automated generation of current standing alarms upon registration

- Architected for future robust trap implementation

TL1 Interface The Telcordia standards compliant TL1 interface provides full FCPS support of TN780 and Optical Line Amplifier network elements.


Feature Description


CHAPTER 2

Network Applications

This chapter describes the configurations and network topologies supported by the TN780 in the following sections:

“TN780 Configurations” on page 2-2

“Network Topologies” on page 2-4


TN780 ConfigurationsPage 2-2

TN780 ConfigurationsThe flexibility of the TN780 eliminates the need for distinct node types, as opposed to the traditional Wavelength Division Multiplexing (WDM) networks that contain distinct node types performing a specialized function, such as terminal, add/drop and amplification function. The TN780 provides all these functions using a common set of circuit packs by allowing the terminal, add/drop or amplification functions to be selected on a per channel (10Gbps and 2.5Gbps) basis. The TN780 eliminates the “node-type” concept and introduces dynamically re-configurable 0-100% digital add/drop, terminal and amplification functions in a single network element. In addition, the TN780 provides digital performance monitoring on a per channel basis at each digital site for fault isolation and troubleshooting.

Figure 2-1 TN780 Configurations

Reconfigurable Digital Add/Drop ConfigurationWhen two fibers are terminated at the TN780, it can be configured to add/drop or pass-through the line-side traffic on a per channel (10Gbps or 2.5Gbps) basis. The TN780 can be configured to add/drop 0% to 100% of the system capacity. Each TN780 can add/drop up to 200Gbps per chassis in each direction. In Release 1.2, the multi-chassis configuration may be utilized to increase the system capacity. The digital performance monitoring and fault monitoring is performed for each add/drop or pass-through channel.

Note: A terminal or a digital repeater site can be upgraded in-service to a re-configurable add/drop site by populating additional circuit packs. No network engineering is required to enable add/drop capacity at any digital site.The reconfigurabale add/drop capability does require a software license.

Digital Terminal Site

(DT)Optical LineAmplifier Site

Digital Repeater Site

(DR)

Digital Junction Site

(JN)


(DT)

Client

Digital Add/Drop Site

(AD)

Client Client ClientSpan

Digital Link


(DT)Optical LineAmplifier SiteOptical LineAmplifier Site


(DR)


(DR)

Digital Junction Site

(JN)


(DT)

Client


(AD)

Client


(AD)

Client Client ClientSpan

Digital Link


3Network Applications

Digital Repeater ConfigurationA TN780 in a digital repeater configuration can be initially equipped with 0% add/drop client-side capacity, providing a 3R regenerator function plus FEC re-coding, but offering the possibility of future upgrade into a digital add/drop configuration. The TN780 can perform digital amplification of up to 200Gbps per chassis in each direction. As with other configurations, the TN780 also provides intermediate digital performance monitoring data for each digitally amplified channel.

Digital Terminal ConfigurationA TN780 in digital terminal mode terminates the incoming line side traffic and hands off the traffic to the customer equipment. The TN780 can terminate up to 400Gbps per chassis in increments of 10Gbps, 2.5Gbps, or 1Gbps by populating the client side interfaces as and when needed. The optical transport capacity on the line side is deployed in 100Gbps increments. As with other configurations, the TN780 also provides intermediate digital performance monitoring data for each digitally amplified channel.

Junction Node ConfigurationThe TN780 can be used at a junction site where multiple fibers from different directions meet. The common locations are at the switching sites in a core backbone network or at transition points such as metro/core network boundaries. In such locations, the TN780 can terminate incoming traffic on the line side fibers or pass through the traffic after performing 3R functions to the appropriate outgoing line fibers. As with other configurations, the TN780 provides digital performance monitoring data on all channels.


Network TopologiesPage 2-4

Network TopologiesThe TN780 and Optical Line Amplifier network elements can be arranged to support a broad range of network topologies uniquely meeting the implementation needs of metro to long-haul applications. The flexibility of the TN780 and Optical Line Amplifier network elements supports a great number of possible network topologies the most typical of which are highlighted in the following sections.

Point-to-point NetworkIn its simplest form, an un-protected point-to-point network consists of two TN780 network elements, each configured as a Digital Terminal (referred as DT) node, connecting two sites in the network (See Figure 2-2 on page 2-4.).

Figure 2-2 Point-to-point Network - Single Span

Depending on the distance of the route, the fiber loss and the potential for customer access at intermediate sites along the route, an optimal selection of Optical Line Amplifiers (referred to as OA) and Digital Repeaters (referred to as DR) can be included in the route. (See Figure 2-3 on page 2-4). The Digital Repeater node can be upgraded in-service to a Digital Add/Drop (referred to as DA) node by simply adding the additional circuit packs, transforming the point-to-point network into a linear add/drop network.

Figure 2-3 Point-to-point Network - Multiple Spans

Note: Figure 2-3 on page 2-4 is for the purpose of feature illustration only. The actual number of Optical Line Amplifier and Digital Repeater sites required between Digital Terminal sites is dependent upon several factors, including fiber type and physical distance.

Note: In Release 1.2, within a digital link between adjacent TN780s, up to six 24dB optical spans and five Optical Line Amplifiers are supported.

To/From Customer

To/From Customer

DT DT

To/From Customer

To/From Customer

To/From Customer

To/From Customer

DT DT

To/From Customer

To/From Customer

DTDT DROA OA

To/From Customer

To/From Customer

DTDT DROA OA



Linear Add/Drop NetworkA linear add/drop network is a simple extension of the point-to-point network configuration where multiple point-to-point segments are concatenated and traffic is added, dropped or passed through at the intermediate sites. This network configuration is used when customer traffic is dropped at multiple sites. (See Figure 2-4 on page 2-5.) A point-to-point network can be upgraded, in-service, to a linear add/drop network by simply populating the appropriate interfaces at the Digital Repeater site or at the Digital Terminal site.

Figure 2-4 Linear Add/Drop Network

Hub and Spoke NetworkA hub and spoke network configuration is an extension of the linear add/drop network configuration where one or more linear add/drop spoke-routes junction through a single location, with traffic switched between the spoke-routes. (See Figure 2-5 on page 2-6.) Each add/drop spoke-route can be at an arbitrary distance, effectively extending the reach of the add/drop to the appropriate termination location. Thus, additional digital repeaters or optical amplifiers may be located between the add/drop location and the final termination location in spoke-route.

To/From Customer

To/From Customer

To/From Customer

To/From Customer

DT AD DTADOA OA

To/From Customer

To/From Customer

To/From Customer

To/From Customer

DT AD DTADOA OA



Figure 2-5 Hub and Spoke Network

A linear add/drop network can be upgraded in-service to a hub and spoke network configuration by adding a spoke-route at a Digital Junction site. Additionally, more spoke-routes can be added in-service to an existing Digital Junction site. Also, a spoke route can be extended in an in-service manner with the addition of Digital Add/Drop nodes.

Ring NetworkA ring network is a special case of linear add/drop network where two Digital Terminal nodes are replaced by a single Digital Add/Drop node. So, a digital optical ring network consists of TN780s configured to perform add/drop function and interconnected in a ring topology. (See Figure 2-6 on page 2-7.) As with all other network configurations, a linear add/drop network is in-service upgradeable to a ring network.The UTStarcom digital optical ring network eliminates the distance limitations on ring circumference. Removing the distance limitations on ring circumference allows the digital optical ring to be deployed in metro applications and core network applications.

Junction site

To/From Customer

To/From Customer

To/From Customer

To/From Customer

To/From Customer

To/From Customer

To/From Customer

Junction site

To/From Customer

To/From Customer

To/From Customer

To/From Customer

To/From Customer

To/From Customer

To/From Customer



Figure 2-6 Ring Network

To/From Customer To/From

Customer

To/From Customer

To/From Customer

To/From Customer To/From

Customer

To/From Customer

To/From Customer


CHAPTER 3

Digital Optical Networking Systems

As described in CHAPTER 1, UTStarcom offers Digital Optical Networking Systems which help carriers build Digital Optical Networks. The TN780 is the first Digital Optical Networking System offered by UTStarcom. The following section provides a brief overview of the hardware modules that make up the TN780.

“TN780 Hardware Overview” on page 3-2

UTStarcom also offers Optical Line Amplifiers optimized to extend the optical reach between two TN780s. The following section provides a brief overview of the hardware modules that make up the Optical Line Amplifier.

“Optical Line Amplifier Hardware Overview” on page 3-13

The TN780 and Optical Line Amplifier network elements provide similar system interfaces, data plane and control plane functions as described in the following sections. The difference in the functionality of the TN780 and Optical Line Amplifier network elements is called out as needed.

“System Interfaces” on page 3-17

“System Data Plane Functions” on page 3-21

“System Control Plane Functions” on page 3-35

“System Management Plane Functions” on page 3-40

As described in CHAPTER 2, the TN780 supports multiple configurations. The following sections provide signal flow within the TN780 for each supported configuration.

“Digital Terminal Site Operation” on page 3-41

“Digital Add/Drop Site Operation” on page 3-44

“Digital Repeater Site Operation” on page 3-49

The following section provides signal flow within an Optical Line Amplifier.

“Optical Line Amplifier Site Operation” on page 3-51


TN780 Hardware OverviewPage 3-2

TN780 Hardware OverviewThis section provides an overview of the hardware modules that are equipped in the TN780 network element. For the detailed description and technical specifications of the TN780 hardware, refer to the UTStarcom TN780 Hardware Description manual.

The TN780 is comprised of one or more DTCs and optionally one or more passive Dispersion Management Chassis (DMCs) for dispersion compensation depending on configuration, as described in the following sections.

“DTC Overview” on page 3-2

“DMC Overview” on page 3-11

DTC OverviewThe DTC is comprised of a DTC and field replaceable circuit packs. The DTC consists of several common equipment components. “DTC Hardware Equipment” on page 3-2 gives a list of the DTC components and field replaceable circuit packs. A front view of the DTC with the DTC components and circuit packs is shown in Figure 3-1 on page 3-4.

Table 3-1 DTC Hardware Equipment

Equipment Type Name

DTC

components

Rack mounting ears

Power Entry Modules (PEM)

I/O Panel

Timing and Alarm Panel (TAP)

Fan Trays

Air Filter

Circuit Packs Management Control Module-A (MCM-A)

Management Control Module-B (MCM-B)

Band Mux Module-4-CX-A (BMM-4-CX-A)

Band Mux Module-4-CX-B (BMM-4-CX-B)

Band Mux Module-8-CX-A (BMM-8-CX-A)

Digital Line Module (DLM)

Tributary Adaptor Module-10G (TAM-2-10G)

Tributary Optical Module-10G-SR1 (TOM-10G-SR1)

Tributary Optical Module-10G-IR2 (TOM-10G-IR2)

Tributary Adaptor Module-2.5G (TAM-4-2.5G)

Tributary Optical Module-2.5G-SR1 (TOM-2.5G-SR1)


3Digital Optical Networking Systems

Tributary Optical Module-2.5G-IR1 (TOM-2.5G-IR1)

Tributary Adaptor Module-1G (TAM-4-1G)

Tributary Optical Module-1G-LX (TOM-1G-LX)

Table 3-1 DTC Hardware Equipment

Equipment Type Name



Figure 3-1 DTC Front View

DTC The DTC houses the common equipment required for operations and circuit packs that transport and terminate optical signals. The DTC can function as a Main Chassis to control and manage all chassis within a TN780 network element and can also function as an Expansion Chassis in a multi-chassis configuration. The DTC is designed to support the multi-chassis configuration. Each DTC supports 400Gbps bidirectional capacity.

Managementfor IOP

Managementfor IOP

Fan Tray A

Fan Tray B

CableManagement

for TAP

Fiber GuideFiber Bend

Radius Control

Air InletPlenum

PEM A PEM B

IOP

BMMs

DLM Blanks

DLMs

MCM Blank

TAM Blanks

TAMs

Air Filter

MCM

TAP



The DTC includes the following common equipment that provides power, performs system supervision, and enables system-level communication:

Rack Mounting Ears (see “Rack Mounting Ears” on page 3-5)

Two Power Entry Modules (see “Power Entry Module” on page 3-5)

One I/O Panel (see “I/O Panel” on page 3-5)

One Timing and Alarm Panel (see “Timing and Alarm Panel (TAP)” on page 3-6)

Two Fan Trays (see “Fan Tray” on page 3-6)

One Air Filter (see “Air Filter” on page 3-6)

One Card cage (see “Card Cage” on page 3-6)

Rack Mounting EarsEach DTC includes integrated rack mount ears used to flush mount in a 600mmx600mm ETSI rack. Separate rack mounting ears are provided to mount the chassis in a 23” rack in flush-mount, and 1”, 2”, 5”, and 6” forward-mount positions.

Power Entry ModuleThe Power Entry Module, referred to as the PEM, is used in redundant pairs to manage the two independent input power supplies (redundant A and B power feeds) of the system. Each module provides the following functions:

Input voltage polarity inversion protection

Input over-voltage protection

Input under-voltage protection

Breaker for the over-current protection

Input voltage operating range is -60VDC to -40VDC

The PEM module outputs are paralleled together on the DTC to form a fully redundant and indepen-dent power supply

I/O PanelThe I/O Panel houses the management and operations interfaces as enumerated below:

Two 10/100Mb auto-negotiating Data Communication Network (DCN) RJ-45 interfaces

Two 10Mb Administrative Inter-LAN RJ-45 interfaces to support Datawire application labeled AUX

One Craft RS232 Modem port

Chassis level alarm LEDs (Power, Critical, Major, Minor)

Bay level alarm LEDs (Critical, Major, Minor)



Four inter-chassis interconnect RJ-45 interfaces referred to as Nodal Controller and Timing (NCT), for multi-chassis configuration

One Lamp Test button

One Alarm CutOff (ACO) button

One ACO LED

Timing and Alarm Panel (TAP)The TAP houses external timing synchronization interfaces and telemetry alarm contacts.

The TAP houses 20 alarm input contact sets, 16 of them are user customizable while the rest are reserved for bay LED and ACO inputs from an external chassis.

The TAP also houses 20 alarm output contact sets, 10 of them are user customizable while the rest are reserved for office alarms and Bay alarms.

Note: In Release 1.2, external timing synchronization is not supported.

Fan TrayEach DTC accommodates two fan trays, one at the top of the chassis and the other at the bottom. Each fan tray contains three individually controlled cooling fans. The two fan trays work concurrently to push/pull air through the system with air flow entering from the bottom front and sides, and exiting from the rear top and sides.

Air FilterEach DTC accommodates one replaceable air filter located below the bottom fan tray to filter out particles at the air intake of the DTC.

Card CageEach DTC has a card cage into which field replaceable circuit packs are installed. Each DTC card cage can accommodate:

Two MCMs (MCM-A and/or MCM-B) in slots 7A and 7B (this circuit pack is half the height of the ser-vice shelf)

Two BMMs (BMM-4-CX-A, BMM-4-CX-B, or BMM-8-CX-A) in slots 1 and 2

Future support for up to two OrderWire Modules (OWM)s, each pluggable into any BMM

Four DLMs in slots 3, 4, 5 and/or 6

Up to five 10G TAM (TAM-2-10G), 2.5G TAMs (TAM-4-2.5G), 1G TAM (TAM-4-1G) plugged into each DLM



Up to two 10G TOM-10G-SR1 and/or TOM-10G-IR2 plugged into each TAM-2-10G

Up to four 2.5G TOM-2.5G-SR1 and/or TOM-2.5G-IR1 plugged into each TAM-4-2.5G

Up to four 1G TOM-1G-LX plugged into each TAM-4-1G

Management Control Module (MCM-A, MCM-B)The Management Control Module, referred to as the MCM, is the shelf controller of all the modules resident within the DTC. The MCM collects circuit pack information (status, alarms, parameters, and actions) through the backplane control bus and passes this information to local terminal and network management systems. Each DTC must have at least one MCM.

There are two versions of the MCM that can be deployed in Release 1.2, the MCM-A and MCM-B

In Release 1.2 the MCM-A can only be deployed in a single-chassis system.The MCM-A is only supported in non-redundant configurations.

In Release 1.2 the MCM-B can be deployed in single and multi-chassis systems. For multi-chassis systems the MCM-B will also perform as an Expansion chassis controller.

The MCM-A and a MCM-B should not be located in the same chassis. For the procedure to upgrade from a MCM-A to a MCM-B refer to the UTStarcom TN780 Maintenance and Troubleshooting Guide.

In Release 1.2 the MCM-A and MCM-B support the “rebranding” or recommissioning feature. For the procedure to “rebrand” or recommissioning a MCM-A or a MCM-B refer to the UTStarcom TN780 Turn-up and Test Guide

Tributary Optical Module-10G-SR1 (TOM-10G-SR1)The TOM-10G-SR1, is a field-replaceable, pluggable XFP module. The TOM-10G-SR1 can be inserted into any of the two sub-slots in the TAM-2-10G.

The TOM-10G-SR1 supports SONET OC-192, SDH STM-64, 10G Clear Channel, 10GbE WAN Phy and 10GbE LAN Phy client signals. The optical interface complies with SONET Telcordia SR-1 specification for the SONET OC-192 client signal, ITU short reach specification for the SDH STM-64 signal, 10G BASE-LW for the 10 GbE LAN Phy client signal and 10G BASE-LR for the 10GbE WAN Phy client signal. The optical connector is a LC duplex connector.

Tributary Optical Module-10G-IR2 (TOM-10G-IR2)The TOM-10G-IR2, is a field-replaceable, pluggable XFP module. The TOM-10G-IR21 can be inserted into any of the two sub-slots in the TAM-2-10G.

The TOM-10G-IR2 supports SONET OC-192, SDH STM-64, 10G Clear Channel, 10GbE WAN Phy and 10GbE LAN Phy client signals. The optical interface complies with SONET Telcordia IR-2 specification for the SONET OC-192 client signal, ITU intermediate reach specification for the SDH STM-64 signal, 10G BASE-EW for the 10 GbE LAN Phy client signal and 10G BASE-ER for the 10GbE WAN Phy client signal. The optical connector is a LC duplex connector.



Tributary Optical Module-2.5G-SR1 (TOM-2.5G-SR1)The TOM-2.5G-SR1, is a field-replaceable, pluggable SFP module. The TOM-2.5G-SR1 can be inserted into any of the four sub-slots in the TAM-4-2.5G.

The TOM-2.5G-SR1 supports OC-48 and STM-16 client signals. The TOM-2.5G-SR1 optical interface complies with Telcordia OC-48 SR1, and ITU I-16 specifications. The optical connector is a LC duplex connector.

Tributary Optical Module-2.5G-IR1 (TOM-2.5G-IR1)The TOM-2.5G-IR1, is a field-replaceable, pluggable SFP module. The TOM-2.5G-IR1 can be inserted into any of the four sub-slots in the TAM-4-2.5G.

The TOM-2.5G-IR1 supports OC-48 and STM-16 client signals. The TOM-2.5G-IR1 optical interface complies with Telcordia IR1, and ITU S-16.1 specifications. The optical connector is a LC duplex connector.

Tributary Optical Module-1G-LX (TOM-1G-LX1)The TOM-1G-LX, is a field-replaceable, pluggable SFP module. The TOM-1G-LX can be inserted into any of the four sub-slots in the TAM-4-1G.

The TOM-1G-LX supports 1G GbE client signals. The TOM-1G-LX1 optical interface complies with IEEE 802.3z 1000Base LX specifications. The optical connector is a LC duplex connector.

Tributary Adapter Module-10G (TAM-10G)The TAM-10G, maps the client optical signals into digital signals for subsequent transmission through the DLM. The 10G TAMs can be arbitrarily equipped in any of the five sub-slots located on the DLM. The TAM-10G provides two sub-slots to enable insertion of 10G TOMs.

There is one type of TAM-10G available, TAM-2-10G, which supports SONET OC-192, SDH STM-64, 10G Clear Channel, 10GbE LAN Phy and 10GbE WAN Phy interfaces.

Tributary Adapter Module-2.5G (TAM-2.5G)The TAM-2.5G, maps the client optical signals into digital signals for subsequent transmission through the DLM. The 2.5G TAMs can be arbitrarily equipped in any of the five sub-slots located on the DLM. The TAM-2.5G provides four sub-slots to enable insertion of up to 4 TOMs.

There is one type of TAM-2.5G available, TAM-4-2.5G, which supports SONET OC-48 and SDH STM-16 interfaces.



Tributary Adapter Module-1G (TAM-1G)The TAM-1G, maps the client optical signals into digital signals for subsequent transmission through the DLM. The 1G TAM can be arbitrarily equipped in any of the five sub-slots located on the DLM. The TAM-1G provides four sub-slots to enable insertion of up to 4 TOMs.

The TAM-4-1G supports 1GbE interfaces.

Digital Line Module (DLM)The DLM performs transport and switching of ten 10Gbps DWDM signals, referred to as the Optical Carrier Group (OCG). The DLM performs the following functions:

Performs 4R function (retiming, reshaping, regeneration and recoding) on each optical channel. The Forward Error Correction (FEC) is applied for each channel that is transmitted/received to/from a BMM providing a coding gain of 8.7 dB at 10Gbps at a BER of 1e-15.

Converts the digital signals received from a TAM into ITU-compliant optical signals and then multi-plexes the ten 10Gbps optical channels into an OCG. The DLM performs the opposite function in the reverse direction.

Each DLM houses up to five TAMs terminating up to100Gbps of client traffic.

Supports grooming and switching of optical channels at 10Gbps, 2.5Gbps or 1Gbps granularity uti-lizing a cross-point switch and backplane connectivity to other DLMs. The DLM provides flexible selection of add-drop, as well as wavelength interchange for pass-through traffic. Refer to “Band-width Grooming” on page 3-26 for the description of backplane bandwidth and switching rules.

Optically connects to the BMM for the second stage multiplexing of multiple OCGs onto the line side fiber.

There are four DLM versions, one for each OCG. Refer to “TN780 Optical Channel Plan” on page B-2 for more details on OCGs. The DLM supports the installation of any combination of TAM-2-10G, TAM-4-2.5G and TAM-4-1G.

Band Mux Module-4-CX-A (BMM-4-CX-A)The BMM-4-CX-A perform the following functions:

Optically multiplexes four OCGs from the DLMs onto the line side facility

Optically de-multiplexes the line side signal into four OCGs and passes them to local DLMs

Provides optical insertion and extraction of the 1510nm Optical Supervisory Channel (OSC) using a 1510nm optical filter

Optically amplifies the multiplexed transmitted and received OCG signals using either an optical booster or a pre-amplifier

Provides a C/L-band splitter to support an in-service expansion of the system to enable optical transmission in the L-band



Provides optical access points for power monitors or optical spectrum analyzers. This includes two (2) receive access points and one (1) transmit access point

Provides sub-slot access for the OWM supported in future release

Accommodates mid-stage access to Dispersion Compensation Fiber (DCF)

There are three different BMM-4-CX-A types providing different EDFA gain and with/without mid-stage DCF access.

Band Mux Module-4-CX-B (BMM-4-CX-B)The BMM-4-CX-B performs the following functions:

Enhanced EDFA for increased reliability

Optically multiplexes eight OCGs from the DLMs onto the line side facility

Optically de-multiplexes the line side signal into eight OCGs and passes them to local DLMs



Provides a C/L-band splitter to support an in-service expansion of the system to enable optical trans-mission in the L-band




There are three different BMM-4-CX-B types providing different EDFA gain and with/without mid-stage DCF access.

Band Mux Module-8-CX-A (BMM-8-CX-A)The BMM-8-CX-A performs the following functions:

Enhanced EDFA for increased reliability

Optically multiplexes eight OCGs from the DLMs onto the line side facility

Optically de-multiplexes the line side signal into eight OCGs and passes them to local DLMs





Provides a C/L-band splitter to support an in-service expansion of the system to enable optical transmission in the L-band




There are three different BMM-8-CX-A types providing different EDFA gain and with/without mid-stage DCF access.

Note: In R1.2 the support for the BMM-8 is on a limited availability basis. Please contact your UTStarcom sales account team for more information.

DMC OverviewThis section provides an overview of the DMC. For the detailed description and technical specifications refer to the UTStarcom TN780 Hardware Description manual.

The DMC is a passive chassis and does not require management. Depending on the span characteristics, the DMC is optionally included in TN780 and Optical Line Amplifier network elements to provide dispersion compensation.

The DMC is comprised of a chassis and Dispersion Compensation Modules (DCMs).

The DMC is a 1RU chassis. As with the DTC, the DMC can be mounted in a 23” rack (flush-mount and 1”, 2”, 5” and 6” forward-mount) and 600mmx600mm ETSI rack (flush-mount). Each DMC can accommodate two half-width DCMs (see Figure 3-2 on page 3-12) or one full width DCM (see Figure 3-3 on page 3-12).

Multiple DCMs are available providing 100ps/nm to 1800ps/nm in 100ps/nm increments.



Figure 3-2 DMC with Two Half-width DCMs

Figure 3-3 DMC with One Full-width DCM



Optical Line Amplifier Hardware OverviewThis section provides an overview of the hardware modules that are equipped in the Optical Line Amplifier network element. For a detailed description and technical specifications refer to the UTStarcom TN780 Hardware Description manual.

The Optical Line Amplifier is comprised of an OTC and optionally a DMC for dispersion compensation depending on configuration, as described in the following sections.

“OTC Overview” on page 3-13

“DMC Overview” on page 3-11

OTC OverviewThe OTC is comprised of an OTC and field replaceable circuit packs. Table 3-2 on page 3-13 gives a list of OTC components and field replaceable circuit packs. A front view of the OTC with the OTC components and circuit packs is shown in Figure 3-4 on page 3-14.

Table 3-2 OTC Hardware Equipment

Equipment Type Name

OTC components Rack mounting ears

Power Entry Module

IO/Alarm Panel

Fan Tray

Air Filter

Circuit Packs Optical Management Module (OMM)

Optical Amplifier Module (OAM)


Optical Line Amplifier Hardware OverviewPage 3-14

Figure 3-4 OTC Front View

OTCThe OTC houses the common equipment required for operations and circuit packs that amplify optical signals. Each OTC supports bidirectional optical amplification function. The OTC includes the following common equipment that provides power, performs system supervision, and enables system-level communication:

Rack Mounting Ears (see “Rack Mounting Ears” on page 3-14)

Two Power Entry Modules (see “Power Entry Module” on page 3-15)

One IO/Alarm Panel (see “IO/Alarm Panel” on page 3-15)

Two Fan Trays (see “Fan Tray” on page 3-15)

One Air Filter (see “Air Filter” on page 3-15)

One Card cage (see “Card Cage” on page 3-15)

Rack Mounting EarsEach OTC includes integrated rack mount ears used to flush mount in a 600mmx600mm ETSI rack. Separate rack mounting ears are provided to mount the chassis in a 23” rack in flush-mount, and 5”, and 6” forward-mount positions.

Air Filter

Fiber Guide

Fan Tray A Fan Tray B

Air Inlet

PEM A

OWMCable Guide

PEM B

Managementfor IAP IAP

Managementfor IAP

OAMs

OMMs



Power Entry ModuleThe Power Entry Module, referred to as the PEM, is used in redundant pairs to manage the two independent input power supplies (redundant A and B power feeds) to the OTC. The PEM module outputs are paralleled together on the OTC to form a fully redundant and independent power supply.

Each PEM is designed to connect to the -60VDC or -48VDC external Power Distribution Units (PDU). The PEM supports the OTC operating voltage range of -72VDC to -40VDC and a worst case load current of 40A at -10V. The PEM does not provide chassis-level over current protection. The over current protection must be provided by the external PDU to which it is connected. The PEM provides the input over-voltage and under-voltage protection.

IO/Alarm PanelThe IO/Alarm Panel houses the management and operations interfaces as described below:

Two 10/100Mb auto-negotiating Data Communication Network (DCN) RJ-45 interfaces

Two 10Mb Administrative Inter-LAN RJ-45 interfaces to support datawire application

One Craft RS232 Modem port

Chassis level alarm LEDs (Critical, Major, Minor, Power)

Four inter-chassis interconnect RJ-45 interfaces referred to as Nodal Control and Timing, for multi-chassis configuration

One Lamp Test button

One ACO button

One ACO LED

The IO/Alarm Panel also houses telemetry alarm contacts. It provides 19 user customizable alarm input contact sets and 10 user customizable alarm contact outputs.

Fan TrayEach OTC accommodates two fan trays, one on the left side of the chassis and the other on the right side of the chassis. Each fan tray contains one cooling fan. The two fan trays work concurrently to push/pull air through the system with air flow entering from the front right and exiting on the left side.

Air FilterEach OTC accommodates one replaceable air filter located on the right side of the chassis to filter out particles at the air intake of the OTC.

Card CageEach OTC has a card cage into which field replaceable circuit packs are installed. Each OTC card cage can accommodate:


Optical Line Amplifier Hardware OverviewPage 3-16

Up to two Optical Management Modules (OMM) in slot 1A and 1B

Up to two Optical Amplifier Modules (OAM) in slots 2 and 3

Future support for one OWM to be plugged into an OAM

Optical Management Module (OMM)The OMM provides the same functions as the MCM (see “Management Control Module (MCM-A, MCM-B)” on page 3-7), but for the OTC. As with MCM-B, redundant OMMs are supported for high availability.

Optical Amplifier Module (OAM-CX-A, OAM-CX-B)The OAM performs uni-directional in-line optical amplification of the incoming signal, and terminates the OSC for processing control and in-band management traffic. Two OAMs are required in an OTC to perform bi-directional optical amplification.

As with the BMM, the OAM terminates the OSC. The OAM contains the OSC optical transmitter and receiver. However, since each OAM receives optical signals from one direction and transmits towards the opposite direction, a special consideration is given to ensure that the OSC transmitter and receiver for a given link are located on the same OAM. This is done by having the West OSC transmitter located on the W-E OAM and the East OSC transmitter located on the E-W OAM. The OSC transmit signal is crossed over using a front panel, duplex, optical patch cord. This is done so that the failure of a single OAM does not result in isolation of the network element for management traffic. Refer to “Optical Line Amplifier Site Operation” on page 3-51 for more details.

The OAM also includes a mid-stage DCF access port to enable optical dispersion compensation. The DMC as described in “DMC Overview” on page 3-11 is used to provide dispersion compensation.The OAM automatically detects the presence of the DCF during turn-up and adjusts its pump powers to achieve the correct gain with the DCF in place. As a precaution during initial system turn-up, an alarm is generated if the measured mid-stage loss is out-of-tolerance relative to the provisioned expected mid-stage loss.

There are six different OAM types providing different EDFA gain and with/without mid-stage access. Since the reach requirements may be different in the two directions, two different OAM types (with respect to gain, mid-stage access, or band) may be combined within an OTC.

The OAM-CX-B has an enhanced EDFA for greater reliability.



System InterfacesThe TN780 and Optical Line Amplifier network elements provide several external interfaces as described in the following sections:

“Operations Interfaces” on page 3-17

“Transport Interfaces” on page 3-18

“Input/Output Alarm Contacts” on page 3-19

“Datawire” on page 3-20

Operations InterfacesThe operations interfaces provide the management and administration of the network element. The TN780 and Optical Line Amplifier network elements provide two kinds of interfaces described below.

Management InterfacesThe network elements provide multiple craft interfaces for local user access to network management and Operations, Administration, Maintenance and Provisioning (OAM&P) functions and also DCN interfaces for remote access. Following is a list of external interfaces that can be used to facilitate the connection of management devices to the TN780 and Optical Line Amplifier network elements.

Craft Serial DCE - This is a DB-9 female/RS-232 DCE interface used to connect a dumb terminal. This serial port supports TL1 only (not EMS or Craft GUI). Maintenance personnel can use this inter-face for managing the local network element or any subtending network elements utilizing this net-work element as a Gateway. The craft serial interface is located on the MCM/OMM.

Craft Ethernet - This is a 10Mbps Ethernet RJ45 interface. This interface can be used to access the network element through the TL1 Interface or MPower GNM. Maintenance personnel can use this interface for managing the local network element or any subtending network elements utilizing this network element as a Gateway. The craft Ethernet interface is located on the MCM/OMM.

DCN - This is an auto-negotiating 10/100Mbps Ethernet RJ45 interface. There are two DCN inter-faces per network element supporting redundant inter-connectivity to the DCN. OSS personnel can use this interface to manage the network element remotely. OSS personnel can use any of UTStarcom Network Management Software applications, such as MPower EMS, MPower GNM or systems TL1 interface, to manage the local network element or any subtending network elements utilizing this network element as a Gateway. DCN interfaces are located on the IO Panel of the TN780 and IO/Alarm Panel of the Optical Line Amplifier.

Craft Serial DTE - This is a DB-9 Male/RS-232 DTE interface used to connect an external modem or a dumb terminal. This interface is located on the IO Panel of the TN780 and IO/Alarm Panel of the Optical Line Amplifier.


System InterfacesPage 3-18

Refer to UTStarcom TL1 User Guide, UTStarcom MPower GNM User Guide, and UTStarcom MPower EMS User Guide for more details on how to use these interfaces to access the corresponding network management applications.

Transport InterfacesThe transport interfaces carry the user data. Two types of transport interfaces are provided as described below.

Client/Trib InterfacesThe client/trib interfaces are the ingress/egress points of the customer signals into/out of the TN780. These signals can be added/removed at a terminal site, or an Add/Drop site. The following client/trib signals are supported:

SONET OC-192 with full SONET overhead transparency


SDH STM-64 with full SDH overhead transparency


10G clear channel

10GbE LAN Phy

10GbE WAN Phy

1GbE

Line InterfaceThe line side optical interface carries the aggregate signal coming into/out of the TN780 and Optical Line Amplifier network elements. The line side signal has the following characteristics:

40x10G channels with integrated OC-3c OSC

Enhanced FEC for 1E-15 end-to-end BER

Digital section layer & digital path level OAM (PM, tracing, alarms)

Traffic-agnostic transport for any 10Gbps/2.5Gbps/1Gbps signals

The line side interface supports multiple fiber types, such as SMF, TW-RS, and E-LEAF.

For more details on the optical characteristics of the line interfaces, refer to UTStarcom TN780 Hardware Description manual.



Input/Output Alarm ContactsThe network element provides several input and output alarm contacts for integration with existing telemetry systems. The network element also provides visual and audible indicators for office alarms. The alarm contacts are available on a front-accessible, wire-wrap connector located on the Timing/Alarm Panel.

Each network element provides 20 alarm input contacts and 20 alarm output contacts. Some of the contacts are reserved for pre-defined functions and the remaining are user-customizable, as described in the following sections.

Office AlarmsThe TN780 and Optical Line Amplifier network elements provide seven office dry alarm contact sets to connect to the Central Office alarm grid. Following are the office alarms provided:

Critical Audible

Critical Visual

Major Audible

Major Visible

Minor Audible

Minor Visible

Power failure

Each set consists of normally-closed (NC), normally-open (NO) and common contacts. When two or more chassis are installed in a single bay, the alarm outputs may be Ored by wiring the associated outputs in parallel (normally-open) or in series (normally-closed), as preferred by the customer.

Alarm Cutoff (ACO)The DTC and OTC provide ACO function so that customers can mute the audible alarms while other alarm indications persist. The ACO is implemented with a front panel push button and a front panel LED. When the front panel ACO push button is pressed all the current outstanding audible alarms (of all severities) are silenced and the ACO LED is illuminated. The illuminated ACO LED indicates that one or more audible alarms are present, but the audible indicators have been suppressed. The subsequent alarms will trigger the audible alarms. However, the ACO LED stays illuminated until all the silenced audible alarms are cleared. Note that the alarm acknowledgment does not change the ACO LED state.

The ACO can also be operated remotely through management applications.

Note: The ACO function is local to the chassis. It does not affect the audible alarm state in other chassis.


System InterfacesPage 3-20

Parallel TelemetryThe DTC provides sixteen user-customizable environmental alarm input contact sets and the OTC provides nineteen user-customizable alarm input contact sets through opto-isolators. Each alarm input contact set consists of a signal and return contact. The users can customize these alarm inputs, and, when activated, will result in the generation of a customized alarm. The status of all alarms is accessible through the management applications.

The DTC and OTC provide ten user-customizable parallel telemetry output contact sets using latching, form-c relays. The control relays are latching, meaning they maintain their relay position (open or closed) even during a power failure. Each output contact set consists of normally-closed, normally-open and common contacts. The alarm outputs are controlled by the MCM/OMM.

DatawireThe TN780 and Optical Line Amplifier network elements provide two physical 10Mbs Ethernet RJ45 interfaces to support redundant access to the 10Mbps Datawire channel over the OSC. The Datawire channel is used for interconnecting customer’s LAN segments at various sites along a route. For example, the Datawire channel can be used for applications such as backhauling customer’s network management traffic from the remote sites to a gateway network element site, or for serving as a network management access port for field personnel to gain management access to a remote network element.

The configured IP addresses and subnets of the Datawire LAN ports are advertised by the GMPLS routing protocol (see “IQ GMPLS Control Plane Overview” on page 4-47) therefore, the subnets become reachable from other Datawire ports.



System Data Plane Functions The DTC data plane consists of optical, optoelectronics, and electrical components located in multiple circuit packs performing adaptation, conversion, multiplexing/de-multiplexing, and switching of signals to provide digital transport and optical transport functions as described in the following sections. The following data plane functions are described below:

“Digital Transport” on page 3-21

“Optical Transport” on page 3-30

Digital TransportThe DTC and corresponding circuit packs provide the digital transport capability. Figure 3-5 on page 3-22 illustrates the interconnection between the circuit packs and major components along the data path. The sections that follow describe the data plane functions.

Note: Figure 3-5 on page 3-22 is for the illustration of the function feature. The inter connectivity between the circuit packs could vary based on the network element configuration and cus-tomer application.


System Data Plane FunctionsPage 3-22

Figure 3-5 DTC Digital and Optical Transport Architecture

Tributary AdaptationAs shown in Figure 3-5 on page 3-22 the DTC data plane performs tributary adaptation function where any variety of 10Gbps, 2.5Gbps and 1Gbps client signal is adapted to an ITU-compliant optical signal for transmitting on the line fiber. The tributary adaptation includes conversion of client’s optical signals into digital signals (performed in the TOM), encapsulation of 10Gbps, 2.5Gbps or 1Gbps payload into a Digital Transport Frame, referred to as the DTF, (performed in the TAM and DLM) and conversion of the digital signals into the ITU-compliant optical signals. The DTF architecture (refer to “Digital Transport Frame” on page 3-23) is designed to support transport for any variety of 10Gbps, 2.5Gbps and 1Gbps client signals through the network, irrespective of the actual payload format.

In Release 1.2, the TN780 supports the following client interfaces:


Line fiber(west)

BM M

OSC

DLM (in slot 3)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

DLM (in slot 4)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

DLM (in slot 5)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

DCM

Line fiber(east)

BM M

OSC

DCM

DLM (in slot 6)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

OChClientsignal(dig)

10GDigital

channel

2.5G Digital signalClientsignal(opt)

OTS(C-Band +L-Band + OSC)

OM So(OCG)

OM Sb(Band)

Line fiber(west)

BM M

OSC

DLM (in slot 3)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

DLM (in slot 4)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

DLM (in slot 5)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

DCM

Line fiber(east)

BM M

OSC

DCM

DLM (in slot 6)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOM

OChClientsignal(dig)

10GDigital

channel

2.5G Digital signalClientsignal(opt)

OTS(C-Band +L-Band + OSC)

OM So(OCG)

OM Sb(Band)






10G Clear Channel with full transparency

10GbE LAN Phy

10GbE WAN Phy

1GbE

The DTF is architected to accommodate a mix of 10Gbps, 2.5Gbps and 1Gbps payload formats, including:

SONET OC-192

SDH STM-64

SONET OC-48

SDH STM-16

GbE

Other emerging or future service types

Digital Transport FrameThe UTStarcom Digital Transport Frame, referred to as the DTF, is used within Digital Optical Network to transport client signals end-to-end. UTStarcom Digital Transport Architecture is modeled after ITU G.709 digital wrapper architecture, but has been simplified and extended to support the following features:

Transparent to the client signal format

Accommodates different types of 2.5Gbps signals asynchronously multiplexed into a common 10Gbps wavelength for wavelength efficiency

Provides performance and maintenance functions on a per-channel basis

Provides consistent transport management and monitoring capabilities irrespective of the specific client signal format

The DTF accommodates three network layers as described in the sections that follow. The DTF format provides asynchronous mapping of the client signals within the frame; that is it provides stuffing opportunities that may or may not contain real data. This allows the client signal frequency to be independent of the facility and system clock frequencies within an allowed range. The DTF framing is performed in the TAM and DLM.

Digital Transport Network LayersUTStarcom DTF format accommodates three Digital Transport Network Layers, analogous to the OTU/ODU/OPU layered architecture specified by G.709. The three Digital Transport Network layers are described below.



Figure 3-6 Digital Transport Network Layers

DTF Section Layer The DTF Section layer, referred to as the DTS, is terminated by each TN780 within the Digital Optical Network, and provides a dedicated layer of PM and maintenance functions for localized section monitoring and tracing. The DTS layer corresponds to the digital optical segments shown in Figure 3-6 on page 3-24.

DTF Line Layer The DTF Line layer, referred to as the DTL, is analogous to the SONET Line layer and SDH Multiplex Section layer. It provides line-level PM and maintenance functions between TN780 nodes that are configured to digital add/drop mode. The DTL also transports overhead bytes for APS protection functions at the optical channel level, transparent to the payload. The DTL provides multiplexing support for the DTF Path layer, and can transport one 10Gbps or four 2.5Gbps DTF Path signals.

DTF Path

DTF Section

DTF Line

DTS DTS DTSDTS

DTL DTL DTL

DTP DTP

DTP

DTP

10Gbps client signal(eg. OC192)

10Gbps client signal(eg. 10GbE)

10Gbps client signal (e.g. SDH STM-64)

2.5Gbps client signal (e.g. SONET OC48)

Native Client Services

DTF Path

DTF Section

DTF Line

DTS DTS DTSDTS

DTL DTL DTL

DTP DTP

DTP

DTP






DTSDTS DTSDTS DTSDTSDTSDTS

DTL DTL DTLDTL DTL DTL

DTP DTP

DTP

DTP

DTP DTP

DTP

DTP








DTF Path Layer The DTF Path layer, referred to as the DTP, is a generic 2.5Gbps or 10Gbps data channel which provides end-to-end encapsulation and delivery of the “digitally wrapped” client data. The UTStarcom DTF currently defines two DTP signals. One is a 2.5Gbps path signal referred to as the DTP1; the second is a 10Gbps path signal referred to as the DTP2. Each DTP signal contains dedicated overhead bytes for performance monitoring and maintenance functions, including path-level trace messaging, path-level PRBS generation, and maintenance alarms.

Note: Release 1.2 supports only DTP2 (10Gbps) signals, however the Digital Line Module is designed to multiplex DTP1 (2.5Gbps) signals. No hardware replacement will be needed in future releases to transport 2.5Gbps client signals.

Digital Transport Frame StructureThe DTF structure is based on the ITU-T G.709 OTU format (G.709 Appendix II, figure II.5) with several modifications. Figure 3-7 on page 3-25 shows the generalized DTF structure.

Figure 3-7 Digital Transport Frame Structure

The DTF overhead contains the characteristic information for the DTF Section, DTF Line, and DTF Path layers of the network. The DTF Overhead is segmented into seven groups: Digital Transport Frame Alignment Overhead, DTS Overhead, FEC Overhead, DTL Overhead, DTPk Overhead, DTEk Overhead and DTEk Payload. The function of the seven groups are:

Digital Transport Frame Alignment Overhead (DTFA-OH) The DTFA-OH provides frame and multi-frame alignment of the DTF.

DTF Section Overhead (DTS-OH) The DTS-OH supports DTF Section layer. This information corresponds to the G.709 OTUk and to the SONET Section Layer overhead and SDH Multiplex Section Layer overhead. It includes necessary overhead bytes to provide the performance monitoring and maintenance functions at the section layer.

DTL-OH and DTPk-OH

DTFA-OH DTS-OH

DTEk-Payload

DTEk-OH

RowColumn

1234

1 28 60 64

FEC-OHDTL-OH and DTPk-OH

DTFA-OH DTS-OH

DTEk-Payload

DTEk-OH

RowColumn

1234

1 28 60 64

FEC-OH



DTF Line Overhead (DTL-OH) The DTL-OH supports DTF Line layer. This information corresponds to the G.709 ODUk Tandem Connection (ODUkT) and to the SONET Line overhead. The G.709 supports six ODUkTs; UTStarcom Digital Frame Structure supports one DTL. It also includes necessary overhead bytes to provide performance monitoring, maintenance and APS functions at the line layer.

DTF Path k Overhead (DTPk-OH) The DTPk-OH is used to support a DTF DTPk. This information corresponds to the G.709 ODUk Path (ODUkP) and to the end-to-end portion of the SONET/SDH path overhead. The Digital Frame Structure supports 2.5Gbps and 10Gbps DTPks corresponding to k=2.5 and k=10 respectively. The DTPk-OH contains necessary overhead bytes to provide end-to-end performance monitoring and path level tracing.

Digital Transport Payload Envelope k (DTEk)The DTEk is the information structure used to adapt client information for transport over a DTF Path k. It comprises Digital Transport Payload Envelope k Payload (DTEk-Payload) together with any Digital Transport Payload Envelope k Overhead (DTEk-OH) needed to perform rate adaptation between the client signal rate and the DTEk-Payload rate, and other overhead supporting the client signal transport. This overhead is adaptation specific. The DTEk capacities for 2.5Gbps and 10Gbps are supported.

FEC Overhead (FEC-OH) The FEC-OH is used to support Forward Error Correction. This information corresponds to the G.709 OTUk FEC.

Bandwidth Grooming The TN780 system data plane supports10Gbps, and 2.5Gbps grooming and switching between DLMs utilizing a cross-point switch integrated within the DLM and backplane connector. (See Figure 3-5 on page 3-22.) As described in the earlier sections, each DLM can terminate 100Gbps line-side capacity and each DTC can accommodate 4 DLMs in slots 3, 4, 5, and 6.

In Release 1.2, grooming of up to 100Gbps capacity, referred to as the X-OCG grooming, is supported between adjacent DLM slots (between slots 3 & 4, and slots 5 & 6). (See Figure 3-8 on page 3-27.)



Figure 3-8 DTC Grooming Capacity

Note: Figure 3-8 on page 3-27 illustrates an example where the DLMs in the odd numbered slots are connected to one BMM towards west direction, DLMs in the even numbered slots are connected to the other BMM towards east direction. In this example configuration each DTC can support up to 400Gbps grooming capacity.

Reconfigurable Add/DropThe TN780 system data plane implements fully flexible 0% to 100% add/drop capabilities on a per- channel basis (10Gbps, and 2.5Gbps). The channels can be configured to pass-through or add/drop. A pass-through channel can be re-configured to an add/drop channel by:

Populating the client side circuit packs (TAM and TOM)

Provisioning end-to-end circuit through management applications

There are no restrictions as to how many channels or which channels are added/dropped at any given site. Whenever an add/drop channel is added or deleted, no network engineering is required. Furthermore, the add/drop channels are transparent to the client signal format and can carry many client signals.

Line W est

Line East

1 2 3 4 5 6 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

M

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

BM

M-4

-C1-

A

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

M

DLM

-7-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-5-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT D

LM-1

-C1-

A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

100Gbps 100Gbps

60Gbps

60Gbps

Line W est

Line East

Line W est

Line East

1 2 3 4 5 6 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

MLI

NK

D

ATA

LIN

K

DAT

A….

…..

….

…..

Ethernet

DCE

Ethernet

DCE

MC

MM

CM

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

OUT INOCG 1OCG 1

OCG 3OCG 3

OCG 5OCG 5

OCG 7OCG 7

LINEIN OUT

LINEIN OUT

BM

M-4

-C1-

A

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

BM

M-4

-C1-

A

LINEIN OUT

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

OUT INOCG 1OCG 1

OCG 3OCG 3

OCG 5OCG 5

OCG 7OCG 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

MLI

NK

D

ATA

LIN

K

DAT

A….

…..

….

…..

Ethernet

DCE

Ethernet

DCE

MC

MM

CM

DLM

-7-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-7-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-5-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-5-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT D

LM-1

-C1-

A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT D

LM-1

-C1-

A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

100Gbps 100Gbps

60Gbps

60Gbps

100Gbps100Gbps 100Gbps100Gbps

60Gbps60Gbps

60Gbps60Gbps



Digital RegenerationThe TN780 system data plane implements fully flexible 0% to 100% digital amplification capabilities on a per-channel basis (10Gbps, and 2.5Gpbs). It has the capability to digitally amplify the channels at 10Gbps, and 2.5Gbps. There are no restrictions as to how many channels or which channels are digitally amplified at any given site. Whenever a digital amp channel is added or deleted, no network engineering is required. Furthermore, the digital amp channels are transparent to the client signal format and can carry many client signals.

Digital ConditioningThe TN780 system data plane includes Forward Error Correction (FEC) encoder/decoder for every channel on the line side at every digital add/drop, digital terminal and digital repeater node to improve the overall BER.

UTStarcom implements an enhanced FEC algorithm which has a higher coding gain than the standard G.709 RS(255,239) algorithm. The Enhanced FEC algorithm provides a coding gain of 8.7 dB at 10Gbps at BER of 1e-15 with the same 7% overhead ratio as the standard G.709 FEC algorithm.

The Enhanced FEC function is implemented on the DLM.

Digital Transport Performance MonitoringAs described in “Digital Transport Frame” on page 3-23, client signals are encapsulated within a DTF to transport across the Digital Optical Network. The DTF architecture supports digital performance monitoring that is agnostic to the client signal payload. The DTF overhead bytes are designed to provide users performance monitoring capabilities at transport layers analogous to SONET/SDH layering. As illustrated in Figure 3-6 on page 3-24, the DTF architecture includes the DTF Section, DTF Line and DTF Path (DTP) layers. The digital performance monitoring is supported at each of these layers, as described in the following sections, for every channel (10Gbps,2.5Gbps and 1Gbps) at every digital site enhancing the troubleshooting and fault isolation in the transport domain.

Also, the DTF includes FEC overhead bytes providing FEC performance data for BER computation on each digital link and on each end-to-end digital channel.

DTF Section PMThe DTF Section layer includes a BIP-8 counter on each 10Gbps digital channel of a digital link, and it can be monitored at each digital site.

DTF Line PMThe DTF Line layer defines BIP-8 statistics across multiple consecutive digital links along a route, as defined by the customer.

This counter is not supported in Release 1.2.



DTF Path PMThe DTF Path layer includes a BIP-8 counter for both 2.5Gbps and 10Gbps client signals, and is associated with the end-to-end path of the signal. The path performance monitoring data is available at the DTP end points and also available at the intermediate digital sites where the DTF is regenerated, analogous to SONET/SDH intermediate path performance monitoring.

Native Client Signal Performance MonitoringThe performance monitoring data of the native client signal is collected at the end point prior to encapsulating the client signal in a DTF. The native client signal performance data is transported transparently across the Digital Optical Network. At the egress endpoint the parity errors on the encapsulated client signal are detected and appropriately included in the client signal overhead bytes prior to handing off the client signal to the customer equipment. The client signal performance monitoring data is collected for all the supported client signal types, including:

SONET OC-192

SONET OC-48

SDH STM-64

SDH STM 16

10GbE LAN Phy

10GbE WAN Phy

FEC PMAs described in “Digital Conditioning” on page 3-28 FEC encoding and decoding is performed on every digital channel. The FEC statistics are collected at every digital site on every channel, including:

Uncorrected bit error rate

Corrected bit error rate

Corrected number of zeros

Corrected number of ones

Uncorrected number of codewords

Total number of codewords

Raw total bit errors before applying FEC

Digital Transport Maintenance FunctionsThe DTF architecture supports the maintenance functions that are agnostic to the client signal payload format. The DTF overhead bytes are designed to provide users the maintenance and the troubleshooting capabilities at transport layers analogous to SONET/SDH layering. It includes:



The DTF defines several maintenance signals which are transmitted in-band to the upstream and downstream network elements using the overhead bytes. It includes:

DTF BDI-L and DTF BDI-P are Backward Defect Indication signals sent upstream as an indica-tion that a downstream defect has been detected

DTF AIS-L and AIS-P are Alarm Indication Signals sent downstream as an indication that an upstream defect has been detected

DTF OCI-L and DTF OCI-P are Open Connection Indication (OCI) signals sent downstream as an indication that the signal is not connected to a source in the upstream

DTF LCK-L and DTF LCK-P are Locked signals sent downstream as an indication that the con-nection is locked in the upstream node

Signal Degrade (SD) signal is sent downstream indicating the BER of the received signal is above set limits

Signal Fail (SF) signal is sent downstream indicating the BER of the received signal is above set limits

Trace message (TTI) at DTF Section layer providing continuity check along a digital link between consecutive Digital Optical Nodes

Trace message (TTI) at DTF Path layer providing end-to-end continuity check between the two end-points within the Digital Transport Network

Optical TransportThe TN780 and Optical Line Amplifier network elements include the optical transport functions which are described below.

Optical Transport LayersAs with digital transport layers, the TN780 and Optical Line Amplifier network elements define optical transport layers within the optical domain (see Figure 3-9 on page 3-31).



Figure 3-9 Optical Transport Layers

At the lowest layer, Optical Channel (OCh) is a 10Gbps channel within the C-band channel plan. Next layer is the Optical Multiplex Section (OMS) layer. UTStarcom defines two-stage multiplexing resulting in two OMS layers (OMSo and OMSb). The OMSo is a 100Gbps signal, an aggregate of ten Optical Channels (OChs). The (OMSo) is referred to as the Optical Carrier Group (OCG). The OMSb is a 400Gbps signal, an aggregate of four OCGs with the support for 800Gbps or 8 OCGs in future. The OMSb is commonly referred to as C-band and L-band. Release 1.2 supports only C-band channel plan with future support for L-band channel plan. The optical transport section (OTS) is an aggregate of OMSb (C-band), OMSb (L-band in future release) and OSC channel providing 1.2Tbps capacity per fiber in future.

Thus, an OTS signal may contain 0 to 80 C-band channels (1530.334nm to 1563.455nm), 0 to 80 L-band channels in future, plus OSC channel at 1510nm, outside of both bands. Each OCh may be arbitrarily added and dropped multiple times across a route. However, the individual channels are not managed, instead the OCGs are managed. The OCGs are the basic unit of optical granularity, not the channel; all the OChs in an active OCG are optically present on the fiber (barring single-channel failures).

OTSOTS OTS OTSOTS OTS OTSOTS OTS OTSOptical Transport Section

OCh OCh OChOChOptical Channel

OMSo OMSo OMSoOMSo

Optical MuxSection (band)

Optical MuxSection (OCG)

OMSbOMSbOMSb OMSbOMSbOMSb OMSbOMSbOMSbOMSb

OTSOTSOTSOTS OTSOTS OTSOTSOTSOTS OTSOTS OTSOTSOTSOTS OTSOTS OTSOTSOptical Transport Section

OChOCh OChOCh OChOChOChOChOptical Channel

OMSo OMSo OMSoOMSo

Optical MuxSection (band)

Optical MuxSection (OCG)

OMSbOMSbOMSb OMSbOMSbOMSb OMSbOMSbOMSbOMSb



Figure 3-10 Optical Signal Multiplexing

The TN780 network element implements OTS, Band, OCG and OCh layers, while the Optical Line Amplifier implements only the OTS and Band layers.

The multiplexing of ten optical channels into one Optical Carrier Group (OCG) is performed in the DLM. The multiplexing of multiple OCGs and the OSC are performed in the BMM. (See Figure 3-5 on page 3-22.)

The OAM supports multiplexing/demultiplexing of C-band and L-band signals.

Optical AmplificationThe amplification function amplifies an aggregate signal along each span of the link. The UTStarcom Optical Line Amplifier provides optical amplification and is used to extend the reach between the TN780 network elements.

Optical ConditioningOptical conditioning fine-tunes the optical signals along the link. The BMM includes a mid-stage access to the Dispersion Compensation Modules (DCMs) providing post-compensation for the dropped channels at the Digital Terminal and Digital Add/Drop site. The OAM includes a mid-stage access to the DCMs providing compensation for the amplified line signal.

TenOCh(10Gbps)signals 100Gbps

OCG


OCG


OCG


OCG

400GbpsC-band

400GbpsL-band in future

OSC(1510nm)

OTS(400Gbps in Rls. 1& up to 1.2Tbps in future)


OCG


OCG


OCG


OCG

400GbpsC-band

400GbpsL-band in future

OSC(1510nm)

OTS(400Gbps in Rls. 1& up to 1.2Tbps in future)



Optical Performance MonitoringThe TN780 and Optical Line Amplifier network elements support optical performance monitoring at OTS, Band, OCG and OCh layers. Refer to “Optical PM Parameters and Thresholds” on page A-2 for a detailed description of the supported optical PM parameters.

In addition, several OSA (optical spectrum analyzer) ports are provided in order to measure the optical spectrum without affecting the traffic. The BMM provides the following OSA ports:

OSA port for the aggregate line input

OSA port for the receive EDFA output

OSA port for the aggregate line output

The OAM provides the following OSA ports:

OSA port for the aggregate line output

OSA port for the aggregate line input

Optical Transport Maintenance FunctionsThe optical transport architecture supports the maintenance signals at the OTS and OCG layers. The maintenance signals are transmitted out-of-band over the OSC channel. The maintenance signals are transmitted to the upstream and downstream network elements indicating the isolation of faults. Following maintenance signals are supported:

BDI-OTS - The BDI-OTS (backward defect indication-optical transport section) signal is transmitted by the BMM and OAM to an upstream network element on detecting LOL-OTS on its receive link

FDI-OTS - The FDI-OTS (forward defect indication-optical transport section) signal is transmitted by the BMM and OAM to a downstream network element indicating that a failure has been detected in the upstream network

BDI-Band - The BDI-Band signal is transmitted by the BMM and OAM to an upstream network ele-ment on detecting LOL-Band on its receive link

FDI-Band - The FDI-Band signal is transmitted by the BMM and OAM to a downstream network ele-ment indicating that a failure has been detected in the upstream network at the Band layer

BDI-OCG - The BDI-OCG signal is transmitted by the BMM and OAM to an upstream network ele-ment on detecting LOL-OCG on its receive link

FDI-OCG - The FDI-OCG signal is transmitted by the BMM and OAMs to a downstream network element indicating that a failure has been detected in the upstream network at the OCG layer

BDI-OCh - The BDI-Channel signal is transmitted by the BMM and OAM to an upstream network element on detecting LOL-OCh on its receive link

FDI-OCh - The FDI-Channel signal is transmitted by the BMM and OAM to a downstream network element indicating that a failure has been detected in the upstream network at the OCh layer



Data Plane RedundancyThe data plane architecture in TN780 and Optical Line Amplifier network element is highly reliable, but not highly available. In Release 1.2, no data plane protection (protection switching feature) is provided. The end-to-end data plane must be protected by the external equipment. The Digital Optical Network system is designed to support the external equipment that provides SONET/SDH protection.



System Control Plane FunctionsThe TN780 and Optical Line Amplifier network elements include a fault tolerant and redundant control plane in order to support a reliable Digital Optical Network. The control plane provides:

Communication between circuits packs within the same chassis (refer to “Intra-chassis Control Plane” on page 3-35)

Communication between chassis within the network element with multiple chassis (refer to “Inter-chassis Control Plane” on page 3-37)

Communication between network elements within the Digital Optical Network (refer to “Inter-node Control Plane (over OSC)” on page 3-38)

The Intra-chassis and Inter-chassis control planes provide redundant control path to enhance the overall reliability of the network element. The following sections describe the redundancy provided at the hardware level. The IQ Network Operating System software utilizes the hardware features and enables the system level redundancy.

Intra-chassis Control PlaneThe intra-chassis control plane in TN780 and Optical Line Amplifier network elements provide a fault tolerant, high performance control path.

The intra-chassis control plane consists of a redundant point-to-point switched 100Mbps Ethernet control path. The backplane contains two 100Mbps Ethernet control bus for connecting the control circuit packs (MCMs in TN780, OMMs in Optical Line Amplifier, referred to as MCM/OMM) to the remaining circuit packs, referred to as line circuit packs.

To enable redundancy, each chassis must be populated with two control MCM-Bs/OMMs. Each MCM/OMM houses a 100Mbps Ethernet switch. The line circuit packs connect to two MCM/OMM, as logically depicted in Figure 3-12 on page 3-36 for TN780 and Figure 3-12 on page 3-36 for Optical Line Amplifier. At any given time, one MCM/OMM is active and the other one is in stand-by mode. The line circuit pack communicates with the Active MCM/OMM over the control path A (Primary control path); in the event of communication path failure, the line circuit packs will communicate through the control path B (Secondary control path). Layer 2 switching is used to transport the control traffic between the circuit packs and chassis within a network element.

Note: For the Multi-Chassis configuration, the MCM-B must be used due to the enhanced CPU frequency, persistence storage, and physical memory (SDRAM).


System Control Plane FunctionsPage 3-36

Figure 3-11 Logical Illustration of Intra-chassis Control Plane in a DTC

Figure 3-12 Logical Illustration of Intra-chassis Control Plane in a OTC

Line West Line East

MCM -A

CPU

Switch/Router

MCM - B

CPU

Switch/Router

DLM -1

CPU

DLM -2

CPU

DLM - 3

CPU

DLM -4

CPU

BMM -1

CPU

100Mb FESwitch

OSC

BMM - 2

CPU

100Mb FESwitch

OSC

Backplane

Craft

DCN

Craft

DCN

I/O Panel

Inter-ChassisNCT Ports


Control Path A(Primary control path)

Control Path B(Secondary control path)

Line West Line East

MCM -A

CPU

Switch/Router

MCM - B

CPU

Switch/Router

DLM -1

CPU

DLM -2

CPU

DLM - 3

CPU

DLM -4

CPU

BMM -1

CPU

100Mb FESwitch

OSC

BMM - 2

CPU

100Mb FESwitch

OSC

Backplane

Craft

DCN

Craft

DCN

I/O Panel





Line West Line East

OMM - A

CPU

Switch/Router

OMM - B

CPU

Switch/Router

OAM - 1

CPU

100Mb FESwitch

OSC

OAM - 2

CPU

100Mb FESwitch

OSC

Craft

DCN

Craft

DCN

I/O Panel





Backplane

Line West Line East

OMM - A

CPU

Switch/Router

OMM - B

CPU

Switch/Router

OAM - 1

CPU

100Mb FESwitch

OSC

OAM - 2

CPU

100Mb FESwitch

OSC

Craft

DCN

Craft

DCN

I/O Panel





Backplane



Inter-chassis Control PlaneAs with intra-chassis control plane, the inter-chassis control plane is also based on 100Mbps redundant Ethernet control path. Each MCM/OMM has two 100Mbps Ethernet ports, referred to as NCT-A and NCT-B, to connect to two chassis, one uplink chassis and one downlink chassis.

In a multi-chassis configuration, one of the chassis performs node control function and it is referred to as Main chassis and the remaining chassis are referred to as Expansion chassis. As shown in Figure 3-13 on page 3-38, the chassis with in a network element can be connected in a ring fashion. By deploying two MCMs in each chassis and therefore two control paths, protection against MCM failure, link failure, etc. is supported. Additionally, the ring configuration when combined with redundant paths allows for new chassis to be added to the network element without impacting the control or data planes.

The chassis can also be connected in a linear topology.

Note that the NCT-A and NCT-B interfaces are designed to distribute the timing information in subsequent releases.

Note: For the Multi-Chassis configuration, the MCM-B must be used due to the enhanced CPU frequency, persistence storage, and physical memory (SDRAM).

Note: The system is designed to allow up to six chassis in a multi-chassis configuration. In Release 1.2 only two chassis are supported for the multi-chassis configuration.

Note: In a Multi-Chassis configuration the DCN ports on the Main chassis are active. The DCN ports on the Expansion shelf are disabled.


System Control Plane FunctionsPage 3-38

Figure 3-13 Logical Illustration of Inter-chassis Control Plane

Inter-node Control Plane (over OSC)The TN780 and Optical Line Amplifier network elements support Optical Supervisory Channel (OSC) for out-of-band communication between adjacent network elements. The OSC is a SONET OC-3c (155.52 Mb/s) channel operated at 1510nm outside the EDFA band on each span. The OSC is terminated at every TN780 and Optical Line Amplifier node. The OSC provides 100Mbps throughput.

The OSC control path carries the following traffic between network elements:

Management Plane Traffic - includes traffic from the remote management systems to access net-work elements for the purpose of managing them

Control Plane Traffic - GMPLS routing and signaling control protocol traffic

Datawire Traffic - customer management traffic by interconnecting customer’s 10Mbps Ethernet LAN segments at various sites through Aux port interface

M aster C o n tro l C h ass is

N C T 2-A N C T 1-A N C T 2-B N C T 1-B

D T C C hass isIO P ane l

M C M -AC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r

E xp an sio n C h assis 1



M C M -A

C P U

S w itch /R ou te r

M C M -B

C P U

S w itch /R ou te r




M C M -AC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r




M C M -AC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r




M C M -AC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r



M C M -AC P U

S w itch /R ou te r

M C M -AC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r




M C M -A

C P U

S w itch /R ou te r

M C M -B

C P U

S w itch /R ou te r




M C M -A

C P U

S w itch /R ou te r

M C M -B

C P U

S w itch /R ou te r



M C M -A

C P U

S w itch /R ou te r

M C M -A

C P U

S w itch /R ou te r

M C M -B

C P U

S w itch /R ou te r

M C M -B

C P U

S w itch /R ou te r




M C M -AC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r




M C M -AC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r



M C M -AC P U

S w itch /R ou te r

M C M -AC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r

M C M -BC P U

S w itch /R ou te r



Orderwire Traffic - voice communication traffic between customer sites through the orderwire inter-faces which will be supported in a future release

The physical OSC interfaces are located on the BMM and OAM. The packets received on the OSC are switched to the MCM/OMM for processing. So, though the OSC is terminated on the BMM/OAM, the packets are processed in the MCM/OMM.


System Management Plane FunctionsPage 3-40

System Management Plane FunctionsThe management plane includes the communication between the network element and the external management stations. As described in “Management Interfaces” on page 3-17, Optical Line Amplifier and TN780 network elements provide several management interfaces for management stations to communicate with the network element. The supported interfaces include, Craft Ethernet and Craft Serial DCE ports for local personnel access, Serial DTE port for remote access through a Modem and redundant DCN ports for remote access. As shown in Figure 3-12 on page 3-36 and Figure 3-12 on page 3-36, each MCM/OMM includes a 10/100Mbps Ethernet DCN port to connect to the customer’s DCN network. The redundancy is provided by populating two MCM-B/OMM per chassis and also IQ Network Operating System software as described in “IQ Management Plane Overview” on page 4-53.

The management traffic is carried over the OSC control channel between adjacent network elements.

Note: In a Multi-Chassis configuration the DCN ports on the Main chassis are active. The DCN ports on the Expansion shelf are disabled.



Digital Terminal Site OperationCustomers can deploy the TN780 network element in Digital Terminal mode at a Terminal site. The TN780 network element may have one or more (up to six) DTC and optionally one or more passive DMC for dispersion compensation depending on the configuration.

Each DTC must have the following minimum hardware to provide Digital Terminal function (see Figure 3-14 on page 3-41):

One DTC

One MCM

One BMM

One DLM

One TAM

One TOM

Figure 3-14 DTC with Minimum Hardware for a Digital Terminal

Note: Figure 3-14 shows a DTC deployed with a BMM-4-CX-A. The DTC can also be deployed with a BMM-4-CX-B or a BMM-8-C-A.

Optical fiber connection

between circuit packs

TOM Blank

BMM

Line

West / East

1 2 3 4 5 6 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

M

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

BM

M-4

-C1-

A

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

M

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM Blank

MCM Blank

BMM Blank

DLM

MCM

TAM Blank

TOMTAM





TOM Blank

BMMBMM

Line

West / East

Line

West / East

1 2 3 4 5 6 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

MLI

NK

D

ATA

LIN

K

DAT

A….

…..….

…..

Ethernet

DCE

Ethernet

DCE

MC

MM

CM

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

OUT INOCG 1OCG 1

OCG 3OCG 3

OCG 5OCG 5

OCG 7OCG 7

LINEIN OUT

LINEIN OUT

BM

M-4

-C1-

A

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

BM

M-4

-C1-

A

LINEIN OUT

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

OUT INOCG 1OCG 1

OCG 3OCG 3

OCG 5OCG 5

OCG 7OCG 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

MLI

NK

D

ATA

LIN

K

DAT

A….

…..….

…..

Ethernet

DCE

Ethernet

DCE

MC

MM

CM

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM Blank

MCM Blank

BMM BlankBMM Blank

DLM

MCM

TAM Blank

TOMTAM


Digital Terminal Site OperationPage 3-42

A fully loaded DTC can terminate up to 400Gbps of traffic. A fully loaded DTC includes the following hardware (see Figure 3-15 on page 3-42):

One DTC

One MCM

One BMM

Four DLMs

Twenty TAMs

Up to 40 10G TOMs, up to eighty 2.5G TOMs, or up to eighty 1G TOMs (or any combination of both 10G, 2.5 G, and 1G TOM)

Figure 3-15 on page 3-42 illustrates an example of optical fiber connections between the modules. The line side port on the DLM is connected to the corresponding OCG port on the BMM. For example, the line port on DLM-1-C1 is connected to the OCG 1 port on the BMM. Note that actual connections depend on the installed configuration.

Figure 3-15 Hardware Chassis Configuration of a 400Gbps Digital Terminal

Note: Figure 3-15 shows a DTC deployed with a BMM-4-CX-A. The DTC can also be deployed with a BMM-4-CX-B or a BMM-8-CX-A.

Figure 3-16 on page 3-43 illustrates the logical configuration of a fully loaded DTC at a Digital Terminal site.

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

1 2 3 4 5 6 7

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-7-C

1-A

OCG 7IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-5-C

1-A

OCG 5IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCELI

NK

D

ATA

….

…..

MC

M

Ethernet

DCE

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

Line

West / East

Optical fiber connections


LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

1 2 3 4 5 6 71 2 3 4 5 6 7

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-7-C

1-A

OCG 7IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-7-C

1-A

OCG 7IN

OUT

OCG 7IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-5-C

1-A

OCG 5IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-5-C

1-A

OCG 5IN

OUT

OCG 5IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

OCG 1IN

OUT

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

Ethernet

DCE

Ethernet

DCELI

NK

D

ATA

….

…..

MC

M

Ethernet

DCELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

Ethernet

DCE

Ethernet

DCE

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

Line

West / East







Figure 3-16 Hardware Logical Configuration of a 400Gbps Digital Terminal

B M M L in eE a s t

O S C

D L M( S lo t 5 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 5

D L M( S lo t 6 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 7

D C M( O p t i o n a l )

D L M( S lo t 3 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 1

D L M( S lo t 4 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 3

C l ie n tB M M L in e

E a s t

O S C

B M M L in eE a s t

O S CO S C

D L M( S lo t 5 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 5

D L M( S lo t 5 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

D L M( S lo t 5 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 5O C G 5

D L M( S lo t 6 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 7

D L M( S lo t 6 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

D L M( S lo t 6 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 7O C G 7

D C M( O p t i o n a l ) D C M( O p t i o n a l )

D L M( S lo t 3 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 1

D L M( S lo t 3 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

D L M( S lo t 3 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 1O C G 1

D L M( S lo t 4 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 3

D L M( S lo t 4 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

D L M( S lo t 4 )

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

T A MT O MT O M

O C G 3O C G 3

C l ie n t


Digital Add/Drop Site OperationPage 3-44

Digital Add/Drop Site OperationEach network element may have one or more (up to 6) DTC and optionally one or more passive DMC for dispersion compensation depending on the configuration.

Each DTC must have the following minimum hardware to provide Digital Add/Drop function (see Figure 3-17 on page 3-44):

One DTC

One MCM

Two BMMs

Two DLMs

Two TAMs

Two TOMs

Figure 3-17 DTC with Minimum Hardware of a Digital Add/Drop Node

Note: Figure 3-17 shows a DTC deployed with a BMM-4-CX-A. The DTC can also be deployed with a BMM-4-CX-B or a BMM-8-CX-A.

Two DTCs are required to add/drop 400Gbps in each direction as shown in Figure 3-18 on page 3-46. Following hardware is required to add/drop 400Gbps in each direction:

Line West

Line East

1 2 3 4 5 6 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

M

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

BM

M-4

-C1-

A

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

M

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT



Line West

Line East

Line West

Line East

1 2 3 4 5 6 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

MLI

NK

D

ATA

LIN

K

DAT

A….

…..

….

…..

Ethernet

DCE

Ethernet

DCE

MC

MM

CM

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

BM

M-4

-C1-

A

OUT INOCG 1

OCG 3

OCG 5

OCG 7

OUT INOCG 1OCG 1

OCG 3OCG 3

OCG 5OCG 5

OCG 7OCG 7

LINEIN OUT

LINEIN OUT

BM

M-4

-C1-

A

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

BM

M-4

-C1-

A

LINEIN OUT

LINEIN OUT

OUT INOCG 1

OCG 3

OCG 5

OCG 7

OUT INOCG 1OCG 1

OCG 3OCG 3

OCG 5OCG 5

OCG 7OCG 7

LIN

K

DAT

A….

…..

Ethernet

DCE

MC

MLI

NK

D

ATA

LIN

K

DAT

A….

…..

….

…..

Ethernet

DCE

Ethernet

DCE

MC

MM

CM

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT







Two DTCs

Two MCM-Bs (One MCM for each DTC)

Two BMMs

Eight DLMs

Forty TAMs

Eighty 10G TOMs

Figure 3-18 on page 3-46 also illustrates the optical fiber interconnection between the modules. As shown, two BMMs and four DLMs are located in the Main chassis. The remaining DLMs are located in the Expansion chassis. The DLMs in the Expansion chassis are connected to the BMM in the Main chassis.



Figure 3-18 Hardware Physical Configuration of a 400Gbps Digital Add/Drop Node

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

1 2 3 4 5 6 7

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-3-C

1-A

O C G 3I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-3-C

1-A

O C G 3I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-1-C

1-A

O C G 1I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-1-C

1-A

O C G 1I N

O U T

LIN

K

DAT

A…

.…

..M

CM

E t h e r n e t

D C E

LIN

K

DAT

A…

.…

..M

CM

E t h e r n e t

D C E

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

1 2 3 4 5 6 7

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-7-C

1-A

O C G 7I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-7-C

1-A

O C G 7I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-5-C

1-A

O C G 5I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-5-C

1-A

O C G 5I N

O U T

LIN

K

DAT

A…

.…

..M

CM

E t h e r n e t

D C E

LIN

K

DAT

A…

.…

..M

CM

E t h e r n e t

D C E

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

L i n e W e s t

L i n e E a s t

O p t i c a l f i b e r c o n n e c t i o n s

b e t w e e n c i r c u i t p a c k s

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

1 2 3 4 5 6 7

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-3-C

1-A

O C G 3I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-3-C

1-A

O C G 3I N

O U T

O C G 3I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-3-C

1-A

O C G 3I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-3-C

1-A

O C G 3I N

O U T

O C G 3I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-1-C

1-A

O C G 1I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-1-C

1-A

O C G 1I N

O U T

O C G 1I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-1-C

1-A

O C G 1I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-1-C

1-A

O C G 1I N

O U T

O C G 1I N

O U T

LIN

K

DAT

A…

.…

..M

CM

E t h e r n e t

D C ELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

E t h e r n e t

D C E

E t h e r n e t

D C E

LIN

K

DAT

A…

.…

..M

CM

E t h e r n e t

D C ELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

E t h e r n e t

D C E

E t h e r n e t

D C E

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

1 2 3 4 5 6 7

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-7-C

1-A

O C G 7I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-7-C

1-A

O C G 7I N

O U T

O C G 7I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-7-C

1-A

O C G 7I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-7-C

1-A

O C G 7I N

O U T

O C G 7I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-5-C

1-A

O C G 5I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-5-C

1-A

O C G 5I N

O U T

O C G 5I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-5-C

1-A

O C G 5I N

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

TAM

-2-1

0G I N1

O U T

I N2

O U T

DLM

-5-C

1-A

O C G 5I N

O U T

O C G 5I N

O U T

LIN

K

DAT

A…

.…

..M

CM

E t h e r n e t

D C ELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

E t h e r n e t

D C E

E t h e r n e t

D C E

LIN

K

DAT

A…

.…

..M

CM

E t h e r n e t

D C ELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

E t h e r n e t

D C E

E t h e r n e t

D C E

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

L I N EI N O U T

O U T I N

BM

M-4

-C1-

A

O C G 1

O C G 3

O C G 5

O C G 7

L i n e W e s t

L i n e E a s t

L i n e W e s t

L i n e E a s t







Note: Figure 3-18 shows DTCs deployed with a BMM-4-CX-A. The DTCs can also be deployed with a BMM-4-CX-B or a BMM-8-CX-A.

Figure 3-16 on page 3-43 illustrates the logical configuration of a network element providing 400Gbps add/drop capacity.

Figure 3-19 Hardware Logical Configuration of a 400Gpbs Digital Add/Drop Node

Each DTC can support 200Gbps add/drop traffic in each direction. Figure 3-20 on page 3-48 illustrates the physical configuration of a network element providing 200Gbps add/drop capacity.

BMM East

OSC

100 Gbps Backplane connection

DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

Client Client


DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

West BMM

OSC

DTC

OCG 5

OCG 7

OCG 1

OCG 3

OCG 5

OCG 7

OCG 1

OCG 3


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

Client Client


DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

DTC

BMM East

OSC


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

Client Client


DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

West BMM

OSC

DTC

BMM East

OSCOSC


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

Client Client


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

Client Client


DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM


DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

West BMM

OSCOSC

DTC

OCG 5

OCG 7

OCG 1

OCG 3

OCG 5

OCG 7

OCG 1

OCG 3

OCG 5

OCG 7

OCG 1

OCG 3

OCG 5

OCG 7

OCG 1

OCG 3

OCG 5

OCG 7

OCG 1

OCG 3

OCG 5

OCG 7

OCG 1

OCG 3


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

Client Client


DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

DTC


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

Client Client


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM


DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 6)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

DLM(Slot 5)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

Client Client


DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM


DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 4)

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

TAM TOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

DLM(Slot 3)

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

TAMTOMTOM

DTC



Figure 3-20 Hardware Physical Configuration of a 200Gbps Digital Add/Drop Node

Note: Figure 3-20 shows a DTC deployed with a BMM-4-CX4-A. The DTC can also be deployed with a BMM-4-CX-B or a BMM-8-CX-A.

Figure 3-21 on page 3-49 illustrates the logical configuration of a network element providing 200Gbps add/drop capacity.

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

1 2 3 4 5 6 7

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCE

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCE

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

Line W est

Line East



LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

1 2 3 4 5 6 7

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCE

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCE

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

1 2 3 4 5 6 7

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

OCG 1IN

OUT

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

Ethernet

DCE

Ethernet

DCE

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

Ethernet

DCE

Ethernet

DCE

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

Line W est

Line East

Line W est

Line East







Digital Repeater Site OperationDigital Repeater configuration is a special case of Digital Add/Drop configuration where the client side equipment (TAM and TOM) modules are not populated; those slots are populated with blank circuit packs. As with Digital Add/Drop configuration, each DTC can support up to 200Gbps capacity in each direction.

As described in “Bandwidth Grooming” on page 3-26, in Release 1.2, 100Gbps grooming capacity is supported between all adjacent DLM slots (between slots 3 & 4, slots 5 & 6, slots 3 & 5 and slots 4 & 6). Figure 3-21 on page 3-49 illustrates an example configuration of a DTC providing 200Gbps per direction digital repeater function.

Figure 3-21 Hardware Physical Configuration of a 200Gbps Digital Repeater Node

Note: Figure 3-21 shows a DTC deployed with a BMM-4-CX-A. The DTC can also be deployed with a BMM-4-CX-B or a BMM-8-CX8-A.

Figure 3-22 on page 3-50 illustrates an example configuration of a Digital Repeater. As shown, the digitally repeated traffic is switched between the adjacent DLMs.

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

1 2 3 4 5 6 7

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCE

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCE

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

Line W est

Line East



LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

1 2 3 4 5 6 7

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCE

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCE

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

1 2 3 4 5 6 7

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-3-C

1-A

OCG 3IN

OUT

OCG 3IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT TA

M-2

-10G IN

1OUT

IN2

OUT

TAM

-2-1

0G IN1

OUT

IN2

OUT

DLM

-1-C

1-A

OCG 1IN

OUT

OCG 1IN

OUT

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

Ethernet

DCE

Ethernet

DCE

LIN

K

DAT

A….

…..

MC

M

Ethernet

DCELIN

K

DAT

ALI

NK

D

ATA

….

…..

….

…..

MC

M

Ethernet

DCE

Ethernet

DCE

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

LINEIN OUT

OUT IN

BM

M-4

-C1-

A

OCG 1

OCG 3

OCG 5

OCG 7

Line W est

Line East

Line W est

Line East






Digital Repeater Site OperationPage 3-50

Figure 3-22 Hardware Logical Configuration of a 200Gpbs Digital Repeater Node

BMM East

OSC

DCM(Optional) DCM (Optional)


DLM(Slot 6)

DLM(Slot 5)


DLM(Slot 4)

DLM(Slot 3)

OCG 1

OCG 3

OCG 1

OCG 3

West BMM

OSC

BMM East

OSC

BMM East

OSCOSC

DCM(Optional) DCM (Optional)


DLM(Slot 6)

DLM(Slot 5)


DLM(Slot 4)

DLM(Slot 3)

OCG 1OCG 1

OCG 3OCG 3

OCG 1OCG 1

OCG 3OCG 3

West BMM

OSC

West BMM

OSCOSC



Optical Line Amplifier Site OperationThe OTC (refer to “Optical Line Amplifier Hardware Overview” on page 3-13) provides the line amplifier function. The following hardware equipment is required to provide optical amplification in both directions (see Figure 3-23 on page 3-51).

One OTC

One OMM

Two OAMs

Figure 3-23 Hardware Physical Configuration of an Optical Line Amplifier Node

Figure 3-23 on page 3-51 also indicates the required optical fiber connections. As shown, to provide line amplification for signals going from West to East, the Line IN port on a given OAM is connected to the incoming fiber from one direction (e.g. West) while the Line OUT port on the same OAM is connected to the outgoing fiber in the opposite direction (e.g. East). As a result, the receiver on the OAM receives from one direction and the transmitter on the same OAM transmits towards the opposite direction. However, an OAM provides the option to ensure that the OSC Transmitter and OSC Receiver for a given direction are located in the same OAM so that when an OAM fails, it impacts the OSC in one direction only and the node will still be accessible. This is done by passing the OSC transmit signals between the OAMs using a front-panel duplex optical patch cord. The OSC OUT port on one OAM is connected to the OSC IN port on the other OAM as shown in Figure 3-23 on page 3-51.

OSC Optical patch cord

OMM10BaseT

LINK DATA

DCEλ λ

OMM10BaseT

LINK DATA

DCEλ λ

OAM-C1-A

LINEIN OUT

OSC

OUT

IN

To L-BAND

OUT

IN

To DCM

OUT

IN IN OUT OSA MONITOR

OAM-C1-A

LINEIN OUT

OSC

OUT

IN

To L-BAND

OUT

IN

To DCM

OUT


1A

1B

2

3

IN

Line West

OUT

OUT

Line East

IN

OSC Optical patch cord

OMM10BaseT

LINK DATA

DCEλ λ

OMM10BaseT

LINK DATA

DCEλ λ

OAM-C1-A

LINEIN OUT

OSC

OUT

IN

To L-BAND

OUT

IN

To DCM

OUT


OAM-C1-A

LINEIN OUT

OSC

OUT

IN

To L-BAND

OUT

IN

To DCM

OUT


1A

1B

2

3

OMM10BaseT

LINK DATA

DCEλ λ

OMM10BaseT

LINK DATA

10BaseT

LINK DATA

DCEλ λ DCEλ λ

OMM10BaseT

LINK DATA

DCEλ λ

OMM10BaseT

LINK DATA

10BaseT

LINK DATA

DCEλ λ DCEλ λ

OAM-C1-A

LINEIN OUT

OSC

OUT

IN

To L-BAND

OUT

IN

To DCM

OUT


OAM-C1-A

LINEIN OUT

OSC

OUT

IN

To L-BAND

OUT

IN

To DCM

OUT


OAM-C1-A

LINEIN OUT

OSC

OUT

IN

To L-BAND

OUT

IN

To DCM

OUT


OAM-C1-A

LINEIN OUT

OSC

OUT

IN

To L-BAND

OUT

IN

To DCM

OUT


1A

1B

2

3

IN

Line West

OUT

OUT

Line East

IN


Optical Line Amplifier Site OperationPage 3-52


CHAPTER 4

IQ Network Operating System

UTStarcom IQ Network Operating System, referred to as IQ, is intelligent software operated on all UTStarcom network elements providing significant usability and operational benefits for the Digital Optical Network solutions. This chapter describes the major functions provided by IQ.

IQ provides a robust and reliable Operations, Administration, Maintenance, and Provisioning (OAM&P) functions based on a number of industry standards. The OAM&P functions provided by IQ are described in the following sections:

“Fault Management” on page 4-2

“Equipment Management and Configuration” on page 4-15

“Service Provisioning” on page 4-23

“Performance Monitoring and Management” on page 4-31

“Security and Access Management” on page 4-35

“Software Configuration Management” on page 4-41

The OAM&P functions are accessible to both human and machine clients through a variety of management interfaces and applications, referred to as management applications in the rest of this chapter.

In addition to OAM&P functions, IQ provides intelligent control plane and management plane functions as described in the following sections:

“IQ GMPLS Control Plane Overview” on page 4-47

“IQ Management Plane Overview” on page 4-53


Fault ManagementPage 4-2

Fault ManagementIQ provides an extensive fault monitoring and management capability that are modeled after Telcordia and ITU standards. All these capabilities are agnostic to the client signal type and provides the ability to identify, correlate and correct faults based on actual digital performance indicators leading to quicker problem resolution. Additionally, IQ communicates all state and status information of the network element automatically and asynchronously to the other network elements within the Digital Optical Network and to all the registered management applications, thus maintaining synchrony with in the network.

IQ provides the following fault management capabilities to help users in managing and maintaining the network element.

The alarm surveillance functions to detect and report degraded conditions in the network element. Including:

Detection of defects in the TN780 and Optical Line Amplifier network elements and the incoming signals (See “Defect Detection” on page 4-2).

Declaration of defects as failures (See “Failure Declaration” on page 4-3).

Reporting failures as alarms to the management applications (See “Alarm Reporting” on page 4-3).

Masking low priority alarms in the presence of high priority alarms (See “Alarm Masking” on page 4-6).

Reporting alarms through local alarm indicators (See “Local Alarm Summary Indicators” on page 4-6).

Configuring alarm reporting (See “Alarm Configuration” on page 4-7).

Isolating network faults utilizing Automatic Laser Shutdown feature (See “Network Fault Isola-tion” on page 4-10).

The wrap-around historical event logging that tracks all changes that occur within the network ele-men. (See “Event Log” on page 4-10).

In-service and out-of-service maintenance and troubleshooting tools (See “Maintenance and Trou-bleshooting Tools” on page 4-11).

Alarm Surveillance

Defect DetectionIQ detects and terminates all hardware and software defects within the system. A defect is defined to be a limited interruption in the ability of an item to perform a required function. The detected defects are analyzed and localized to the specific network site, network element, facility (or incoming signal) and circuit pack. On detecting certain defects, for example defects in the incoming signal, IQ transmits maintenance signals to the upstream and downstream network elements indicating successful localization of the defect.


3IQ Network Operating System

On termination of defects, IQ stops transmitting maintenance signals. See “Network Fault Isolation” on page 4-10 for more details.

The detection of facility defects, such as LOL, AIS, FDI, etc., and transmission of maintenance signals to the upstream and downstream network elements is in compliance with Telcordia and ITU specifications.

Failure DeclarationAs specified in GR-253 specification, the defects associated with facilities/incoming signal are soaked for a pre-defined period before they are declared as failures. It prevents spurious failures being reported. So, when a defect is detected on a facility, it is soaked for a time interval of 2.5secs before the corresponding failure is declared. Similarly, when a facility defect terminates, it is soaked for 10secs before the corresponding failure is terminated. This eliminates pre-mature termination of the failure.

The defects associated with hardware equipment are not soaked. Failure condition is declared as soon as the defect is detected and similarly, the failure condition is cleared as soon as the defect is terminated.

Alarm ReportingIQ reports the hardware and software failures as alarms. Detection of a failure condition results in an alarm being raised which is asynchronously reported to all the registered management applications. The termination of a failure results in clearing the corresponding alarm, which is again reported asynchronously to all the registered management applications. IQ stores the alarm conditions locally and they are retrievable by the management applications. Thus, at any given time users see only the current standing alarm conditions.

Alarm generation is also dependent on the administrative state (see “Administrative State” on page 4-20) of the managed object instance and presence of other failure conditions and the user configuration, as described below:

Administrative State—Alarms are generated when the administrative state of a managed object instance and its ancestor objects is unlocked. When the administrative state of an object or any of it’s ancestor objects is locked or in maintenance, the alarms are not generated (except for the Loop-back related alarms).

Alarm Hierarchy—An alarm is generated only if no high priority alarms exist for the managed object instance. Thus, only the alarms corresponding to the root cause of the fault condition is reported. This capability prevents too many alarms being reported for a single fault condition. (See “Alarm Masking” on page 4-6).

User Configuration—IQ provides users the ability to selectively inhibit the alarm reporting utilizing alarm reporting control feature. (See “Alarm Reporting Control” on page 4-7).

IQ reports each alarm with sufficient information, as described below, so that the user can take appropriate corrective actions to clear the alarm. For detailed description of all the parameters of an alarm reported to the management applications, refer to the corresponding user guides.

Alarm Category—this information isolates the alarm to a functional area (See “Alarm Category” on page 4-5 for the list of supported alarm types).



Alarm Severity—this information indicates the level of degradation that the alarm causes to the ser-vice (See “Alarm Severity” on page 4-5 the list of supported severities).

This information is reported as NTFCNCDE parameter in the TL1 notifications.

Probable Cause—this information describes the probable cause of the alarm. This is a short descrip-tion of the cause of the alarm. More detailed description is provided as Probable Cause Description.

TL1 Condition Type—this field is analogous to the probable cause except that the condition type string is in accordance with the GR-833-CORE. It is reported as CONDTYPE parameter in the TL1 notifications.

Probable Cause Description—this information provides the detailed description of the alarm and iso-lates the alarm to a specific area. It is an elaboration of the Probable Cause. This is a string which provides more information on the cause of the alarm condition.

This information is reported as CONDDESCR parameter in TL1 notifications.

Service Affecting—this information indicates whether the given alarm condition interrupts the data plane services through the system or network. The two possibilities are: SA for service affecting and NSA for non-service affecting. An alarm is reported as service-affecting if the alarm condition affects a hardware or software entity in the data plane, and the affected hardware or software entity is administratively enabled.

This information is reported as SRVEFF parameter in the TL1 notifications.

Source Object—this information identifies the managed object instance on which the failure is detected.

This information is reported as AID in the TL1 notifications.

Location—this information identifies the location of the managed object as near end or far end, when applicable.

This information is reported as LOCN parameter in the TL1 notifications.

Direction—this information indicates whether the alarm has occurred in the receive direction or in the transmit direction, when applicable.

This information is reported as DIRN parameters in the TL1 notifications.

Time & Date of occurrence—this information provides the time at which the alarm was detected. It is derived from the system time. IQ provides users the ability to manually configure the system time or enable Network Timing Protocol (see “Time-of-Day Synchronization” on page 4-59) so that the accu-rate and synchronized time is reported for all alarms. It allows the root cause analysis of failures across network elements and networks.

This information is reported as OCRDAT parameter in the TL1 notifications.

Type—As described in “PM Thresholding” on page 4-33, IQ supports performance monitoring and thresholds, enabling early detection of degradation in system and network performance. The thresh-old crossing conditions are handled utilizing the same mechanism as alarms. The type field indicates whether the reported condition is an alarm or a threshold crossing condition.

IQ records all the current alarms with alarm details, as described above, in an alarm table. The alarms are persisted in the MCM/OMM across reboots. After a system reboot or MCM/OMM reboot, the alarms in the



persistent storage are validated to remove any cleared alarms and raise only the current outstanding alarms.

Refer to the UTStarcom TN780 Maintenance and Troubleshooting Guide for the detailed description of all the alarms generated by IQ and the corresponding clearing procedures.

Alarm CategoryIQ categorizes the alarms into the following types:

Facility Alarm—alarms of this type are associated with the line and tributary facilities, and incoming signal. For example: LOL, LOS, AIS, and FDI.

Equipment Alarm—alarms of this type are associated with hardware errors. For example: Equip-ment Failure, and Equipment Unreachable.

Communications Alarm—alarms of this type are associated with faults which impact the communi-cation between the modules within the network element and between network elements. For exam-ple: No Communication with OSC Neighbor, and LOL on OSC.

Software Processing Alarm—alarms of this type are associated with software processing errors. For example, Software Upgrade has Failed, and Persistence space less than 2%-critical.

Environmental Alarm—alarms of this type are caused by the change in the state of the environmen-tal alarm input contact.

Alarm SeverityEach alarm generated by IQ has one of four severity levels set by default. These levels are:

Critical—the Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action is required. This severity is reported, for example, when a managed object instance becomes totally out-of-service and its capability must be restored.

Major—the Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required. This severity is reported, for example, when there is a severe degradation in the capability of the managed object instance and its full capability must be restored.

Minor—the Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service affecting) fault. Such a severity is reported, for example, when the detected alarm condition is not currently degrading the capacity of the managed object instance.

Warning—the Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant effects have been felt. Action should be taken to further diag-nose (if necessary) and correct the problem in order to prevent it from becoming a more serious ser-vice affecting fault.

The alarm severity is referred to as the notification code in GR-833-CORE and it is reported as such in the TL1 notifications.

The user can customize the severity associated with an alarm through the management applications. (See “Alarm Severity Assignment Profile” on page 4-9.)



Alarm MaskingIQ masks (i.e., not autonomously report) a failure that is the result of the same root-cause problem or maintenance signal as another higher-priority failure reported simultaneously by that network element per the containment hierarchy, similar to those defined for SONET/SDH protocols. This prevents logs and management applications from being flooded with redundant information. For example, a circuit pack failure may cause a LOL alarm. Since the underlying fault is the circuit pack failure, suppressing LOL alarm prevents redundant information being reported.

The masked condition is neither reported to the management applications nor recorded in the alarm table. However, the masked condition does not have any effect on changes to the operational state of the managed object instance on which the condition exists.

Local Alarm Summary IndicatorsThe TN780 and Optical Line Amplifier network elements provide local visual and audio indicators to report the summary of current alarm conditions of a network element and chassis to the local personnel. For the detailed description of the indicators and their function refer to the UTStarcom TN780 Hardware Description document and the UTStarcom TN780 Maintenance and Troubleshooting Guide.

Following is a brief summary of the local indicators provided by the TN780 and Optical Line Amplifier network elements:

Bay Level Visual Alarm Indicators—These indicators provide the summary of the outstanding alarm conditions of all chassis within a bay. A bay level visual alarm indicator (LEDs) is lit if there is at least one corresponding outstanding alarm condition in any of the chassis within the bay. The following bay level LED indicators are provided:

Critical LED to indicate the presence of critical alarm within the bay.

Major LED to indicate the presence of major alarm within the bay.

Minor LED to indicate the presence of minor alarm within the bay.

For the bay-level indicators to operate correctly, the pre-defined alarm contacts must be wire wrapped and the software must be configured appropriately. Refer to UTStarcom TN780 Site Prepa-ration and Hardware Installation Guide document for a detailed description of cabling and configura-tion to provide bay-level alarm indication.

Note: The TN780 supports the bay-level alarm indicators. The Optical Line Amplifier does not support the bay-level alarm indicators. The bay-level indicators provided by the PDU is rec-ommended to be used whenever it is present in a bay.

Chassis Level Visual Alarm Indicators—These indicators provide the summary of the outstanding alarm conditions of the chassis. A chassis level visual alarm indicator is lit if there is at least one cor-responding outstanding alarm condition within the chassis. The following bay level LED indicators are provided:

Critical LED to indicate the presence of critical alarm within the chassis.



Major LED to indicate the presence of major alarm within the chassis.

Minor LED to indicate the presence of minor alarm within the chassis.

Power LED to indicate the status of power input to the chassis.

Chassis Level Office Alarm Indicators—As described in “Office Alarms” on page 3-19, the TN780 and Optical Line Amplifier network elements provide alarm output contacts to support chassis level visual and audio indication of critical, major and minor alarms. As described in “Alarm Cutoff (ACO)” on page 3-19, ACO buttons and ACO LEDs are also supported.

Card Level Visual Indicators—All circuit packs include LEDs to indicate the card status. In general, all circuit packs provide the following LEDs.

Power (PWR) LED to indicate the status of the power input to the circuit pack.

Active (ACT) LED to indicate administrative state and service state of the circuit pack.

Fault (FLT) LED to indicate the presence of the critical, major or minor alarm.

Port Level Indicators—These indicators are provided for each tributary port and line port. In general, the port level LEDs include:

Active (ACT) LED to indicate the administrative state and service state of the port.

LOS LED to indicate the incoming signal status.

Note: By default all critical, major, and minor alarms affect the corresponding chassis LED status. However, through the management applications users can disable the facility alarms not to affect the chassis LEDs. The equipment alarms always affect the chassis LEDs.

Alarm ConfigurationUsers can customize the alarms reported by IQ through the management applications and interfaces.

Alarm Reporting ControlThe Alarm Reporting Control (ARC) feature allows users to silence a managed object instance that is administratively unlocked, but which is being serviced or is awaiting valid signal flow. A typical example is a tributary port in AINS (administrative inservice state or administrative unlocked state) state that is awaiting interconnection to client equipment. In such cases, users would like the alarms inhibited on this resource, as it is not yet providing service to the clients. Although the managed object instance may be detecting alarms such as LOL, they are not transmitted to any client, or reported to the management applications.

The inhibited alarms do not change the status indicators, such as LEDs, audio and visual indicators. The inhibited alarms are logged in the event log and are retrievable through the management applications. Users can retrieve information about all alarms and find out if any alarm is an inhibited alarm. Each alarm has an attribute to indicate if it is an inhibited alarm or not.



The ARC is provisionable through the management applications. Users can enable the ARC per managed object instance basis. When ARC is applied to a managed object instance it is propagated to all the contained and supported managed objects also. For example, when alarm reporting is inhibited for the chassis object instance, alarm reporting is inhibited for all the circuit pack object instances within that chassis. See “Managed Object Entities” on page 4-15 for the description of the managed object entities and relationship between them.

The alarms are inhibited for the duration user has enabled the ARC. On disabling ARC, the standing alarm conditions, which were inhibited due to ARC, are reported to the management applications. Various scenarios shown in Figure 4-1 on page 4-9 captures how alarm reporting is handled for each situation.

As shown in Scenario #1, if there are any outstanding alarms prior to enabling the alarm inhibition, those alarms remain outstanding until the alarm condition is cleared. As shown, if the alarm condi-tion is cleared during ARC period, an alarm cleared event is reported to the management applica-tions.

As shown in Scenario #2, if there are any outstanding alarms prior to enabling the alarm inhibition, those alarms remain outstanding until the alarm condition is cleared. As shown, if the alarm condi-tion is cleared after the ARC period, an alarm cleared event is reported to the management applica-tions.

As shown in Scenario #3, if an alarm condition is raised and cleared during ARC, corresponding events are not reported to the management applications. However, those events are logged in the event log which are retrievable through the management applications.

As shown in Scenario #4, if an alarm condition is raised during ARC period, the corresponding alarm raised event is not reported to the management applications. If the ARC period ends prior to the alarm clearance, the alarm raised event is reported to the management applications with the actual time stamp at which the alarm was generated. Thus at the end of the ARC, the management appli-cations and the network element are in sync with regards to the standing alarm conditions.



Figure 4-1 Alarm reporting behavior during ARC period

Alarm Severity Assignment ProfileThe Alarm Severity Assignment Profile (ASAP) feature allows users to modify the default severity of an alarm type per managed object entity basis. Note that the severity can’t be modified per managed object instance basis. For example, when the severity of LOL of an OCG termination point is modified, the new severity is applied to LOL alarm reported by all instances of the OCG termination point. Users can modify the default severity according to their fault-handling strategies. Note that the user modifications of alarm severity takes effect for the newly generated alarm; if there is an alarm that is currently active, its severity is not changed by the user modification.

The ASAP is provisionable through the management applications.

Note: The severity of environmental alarms are assigned by the user when they are provisioned. The ASAP feature cannot be used to modify the provisioned severity of environmental alarms.

ARC Period

t1 t2

Scenario #1

Scenario #2

Scenario #3

Scenario #4

Alarm is cleared and reported to the management applications

Alarm is raised and reported to the management applications

Alarm is raised and logged, but NOT reported to the management applications

Alarm is cleared and logged, but NOT reported to the management applications

ARC duration (period during which ARC is enabled)

Alarm duration (period during which an alarm condition exists)

Legend:

ARC Period

t1 t2

Scenario #1

Scenario #2

Scenario #3

Scenario #4

Alarm is cleared and reported to the management applications

Alarm is raised and reported to the management applications





Legend:

Alarm is cleared and reported to the management applicationsAlarm is cleared and reported to the management applications

Alarm is raised and reported to the management applicationsAlarm is raised and reported to the management applications





Legend:



Network Fault IsolationThe TN780 and Optical Line Amplifier network elements implement Automatic Laser Shutdown feature to isolate the effects of a fault. The Automatic Laser Shutdown features include:

Automatically turn off the EDFAs transmitting at high powers toward the upstream and downstream network elements, in order to comply with stringent laser eye-safety requirements.

Transmit maintenance signals to alert downstream and upstream network elements that a fault has been isolated. The maintenance signals help distinguish between the defect that is local to this net-work element’s hardware, or on an adjacent facility vs. the defect in a remote network element or on a remote facility.

As described in “Digital Transport Maintenance Functions” on page 3-29, the DTF architecture supports maintenance signals which are modeled after the SONET/SDH layers. The maintenance signals are transmitted in-band to the upstream and downstream TN780s.

Similarly, the OTN architecture defines maintenance signals (see “Optical Transport Maintenance Functions” on page 3-33) which are transmitted out-of-band over the OSC.

The maintenance signals are transmitted immediately after the detection of a defect in the incoming signal or equipment failure and are removed after the termination of a defect or equipment failure.

Event LogIQ provides a wrap-around historical event log that tracks all changes that occur within the system. The events are recorded locally in the network element and are retrievable through the management applications. The event log enables users and management applications to retrieve all events (including alarms) that occurred during a communication failure between the management applications and the network element, and will maintain data synchrony between the network element and the management application.

IQ records the following types of events in the event log:

Alarm related events which include alarm raise and clear events.

PM data thresholding related events which include threshold crossing raise and clear events.

Threshold crossing alerts as described in “PM Thresholding” on page 4-33.

Managed object creation and deletion events triggered by the user actions.

Security administration related events triggered by the user actions.

Network administration events triggered by the user actions to software upgrade, software down-grade, database restore, etc.

Audit events triggered by the user actions to change attribute value(s) of a managed object.

State change events indicating the state changes of a managed object triggered by the user action and/or changes in the operation capability of the managed object.

The event logs are stored in the persistent storage on the network element, and therefore, the event logs will be available after restarts and reboots. Note that the attribute value change events are not stored in the



persistent storage. IQ stores up to 1000 attribute value change events which are not persisted and 3000 remaining events which are persisted over reboots. Users can export the event log information in TSV format using management applications.

Following are some of the important information stored for each event log record:

Managed object instance that generated the event.

The time at which IQ generated the event.

Event type indicating the event category, including:

Update Event which includes managed object create and delete events.

Report Event which includes security administration related event, network administration related event, audit events, and threshold crossing events (TCE).

Condition which includes alarm raise and clear event, non-alarmed conditions, and Threshold crossing condition events.

Refer to UTStarcom TN780 Maintenance and Troubleshooting Guide for a list of events logged in an event log on TN780 and Optical Line Amplifier network elements.

Maintenance and Troubleshooting ToolsIQ provides extensive maintenance and troubleshooting tools used for pre-service operations and troubleshooting problems to isolate the source of the problems. The troubleshooting tools help sectionalize the problems and accurately identify the troubled spot by running tests progressively at the network element, span, digital link and path level.

IQ provides both out-of-service troubleshooting tools which require the corresponding facilities (managed object entities) to be in administrative maintenance state and in-service troubleshooting tools which can be run while the corresponding facilities are in administrative unlocked state.

Out-of-service Troubleshooting Tools:

Loopbacks to test circuit paths through the network or logically isolate faults. (See “Loopbacks” on page 4-12)

PRBS generation and detection (“PRBS Test” on page 4-12)

Hairpin circuits (“Hairpin Circuits” on page 4-13)

In-service Troubleshooting Tools:

Trace messaging (See “Trace Messaging” on page 4-13)

The troubleshooting tools are accessible through the management applications by the users with TT (Turn-up and Test) access privilege.



LoopbacksLoopbacks are used to test newly created circuits before running live traffic or to logically locate the source of a network failure. Loopbacks provide a mechanism where the signal under test (either the user signal or the test pattern signal such as PRBS) is looped back at some location on the network element in order to test the integrity and validity of the signal being looped back. Since loopbacks affect the normal data traffic flow, they must be invoked only when the associated facility is in administrative maintenance state.

IQ provides access to the loopback capabilities in a TN780 network element. These loopbacks are agnostic to the client payload type. Following is a list of loopbacks supported to test each section of the network as shown in Figure 4-2 on page 4-12 and also various hardware components along the data path (see “DTC Digital and Optical Transport Architecture” on page 3-22). The loopbacks can be enabled or disabled remotely through the management applications.

Client Trib Facility Loopback—is performed on the TAM. The tributary port Rx is looped back to the Tx on the TAM. This loopback test verifies the operation of the tributary side optics in the TOM and TAM.

DTF Path Terminal Loopback—is performed on the DLM circuit. In this case the cross-point switch on the DLM loops back the received client signal towards the TAM. This loopback verifies the opera-tion of the tributary side optics as well as the adaptation of client signals into digital signals per-formed in the TOM and TAM and the cross-point switch on the DLM.

DTF Path Facility Loopback—is performed on the DLM. In this case the cross-point switch on the DLM loops back the received line side signal towards the line. This loopback verifies the line side connectivity and the DTF encapsulation performed in the DLM.

Client Trib Terminal Loopback—is performed on the TAM. In this case the digital signal received from the line is looped back to the line transmit side in the TAM. This loopback verifies the line side optics on the DLM, the DTF and FEC Mapper/demapper in the DLM and the cross-point switch.

Figure 4-2 Loopbacks supported by the TN780

PRBS TestThe Pseudo Random Bit Sequence (PRBS) is a test pattern that is used to diagnose and isolate the troubled spots in the network, without the requirement for valid data signal or customer traffic. This type of test signal is used during the system turn-up or in the absence of a valid data signal from the customer equipment. The test is primarily aimed to watch out and sectionalize the occurrence of bit errors in the data path. Since the PRBS test affects the normal data traffic flow, it must be invoked only when the associated facility is in administrative maintenance state.

Client TribFacility Loopback

DTF Path Terminal LoopbackDTF Path Facility Loopback

Client TribTerminal Loopback

Client TribFacility Loopback

DTF Path Terminal LoopbackDTF Path Facility Loopback

Client TribTerminal Loopback



IQ provides access to the PRBS generation and monitoring capabilities supported by the TN780 network element. The TN780 supports PRBS generation and monitoring for testing circuit quality at both the DTF Section and DTF Path layers as described below. The PRBS test can be enabled or disabled remotely through the management applications.

DTF Section-level PRBS Test—here the PRBS signal is generated by the near end DLM and it is monitored by the adjacent TN780 network elements. This test verifies the quality of the digital link between two adjacent TN780 network elements.

DTF Path-level PRBS Test—here the PRBS signal is generated by the near end TAM and it is mon-itored at the far end TAM where the digital path is terminated. This test verifies the quality of the end-to-end digital path.

Figure 4-3 PRBS Tests Supported by the TN780

Note: The PRBS tests can be coupled with loopback tests so that the pre-testing of the quality of the digital link or end-to-end digital path can be performed without the need for an external PRBS test set. While this is not meant as a replacement for customer-premise to cus-tomer-premise circuit quality testing, it does provide an early indicator of whether or not the transport portion of the full circuit is providing a clean signal.

Hairpin CircuitsA hairpin circuit refers to a special circuit where the source and destination tributary ports are located on the same network element and the same DLM. In other words, the client signal received by the DLM on one tributary port is looped back to another tributary port on the same DLM, without going through the line. The source and destination tributary ports could be on the same TAM or a different TAM, but they must be on the same DLM.

Trace MessagingIQ provides access to the trace messaging feature supported by the TN780 network element. The TN780 supports the following trace messaging functions:

Trace messaging at the DTF Section and DTF Path (see Figure 4-4 on page 4-14). The DTF Sec-tion trace messaging is utilized to detect any mis-connections between the TN780 network elements

DTF Section PRBS

DTF Path PRBS

Client Client

G M

M G

GPRBS Generator MPRBS Monitor

DTF Section PRBS

DTF Path PRBS

Client Client

GG MM

MM GG

GGPRBS Generator MMPRBS Monitor



within a Digital Link and DTF Path trace messaging is utilized to detect any mis-connections in the circuit path along the Digital Optical Network. The DTF trace messaging is agnostic to the client sig-nal type.

Figure 4-4 Trace Messaging

Trace messaging at the SONET/SDH J0 on the tributary ports. The TN780 provides the capability to passively monitor the J0 messages received from the client equipment. This capability enables the detection of mis-connections between the client equipment and the TN780. The TN780 can monitor 1, 16 and 64byte J0 trace messages.

Client Client

J0 Trace DTF Section Trace

DTF Path Trace

J0 Trace

DTF Section Trace

Client Client

J0 Trace DTF Section Trace

DTF Path Trace

J0 Trace

DTF Section Trace



Equipment Management and ConfigurationIQ provides extensive equipment inventory, management and configuration capabilities, modeled after telecommunications standards such as Telcordia GR-1089-CORE, TMF 814, and ITU-T M.3100, to manage the TN780 and Optical Line Amplifier network elements. IQ provides the following features:

Ability to manage the hardware equipment, physical port and logical termination points by software abstraction as managed entities (see “Managed Object Entities” on page 4-15)

Automatic equipment discovery and inventory (see “System Discovery and Inventory” on page 4-16) including:

Circuit pack auto-discovery

Optical data plane auto-discovery

Circuit pack configuration (see “Circuit Pack Configuration” on page 4-19) including:

Circuit pack pre-configuration

Circuit pack auto-configuration

GR-1089 and TMF-814 compliant state management (see “State Modeling” on page 4-19)

Managed Object EntitiesIQ defines software abstraction of all the hardware equipment, physical ports and logical termination points, referred to as the managed object entities which are administered through the management applications. The managed entities are modeled after the ITU-T and TMF general information modeling, which provides an intuitive and convenient means to reference the managed object entities.

Figure 4-5 on page 4-16 illustrates the most commonly used managed object entities, number of instances of each managed object entity (for example there are four instances of DLM managed object, referred to as the managed object instance, per chassis) and the hierarchical relationship between them. As shown, there are three major categories: hardware equipment which represents the hardware manageable by the user, physical ports and logical termination points which represent the termination of signals. Users can create and delete the equipment managed objects while the physical port and logical termination points are automatically created with default attributes when the parent equipment managed object entity is created. Users can modify the attributes of the auto-created managed object entities through the management applications.

The user operations, such as modifying the administrative state (see “Administrative State” on page 4-20) and modifying the alarm reporting state (see “Alarm Reporting Control” on page 4-7), of a given managed object instance impacts the behavior of the corresponding contained and supported/supporting managed object instances. For example, when a user modifies the administrative state of the BMM instance to locked, the service state of the contained and supported managed object instances, DCF, C-band, OCG, OSC, GMPLS link, etc., is changed to out-of-service. Similarly, when ARC is enabled on BMM instance, alarm reporting is inhibited for all the corresponding contained and supported managed object instances.


Equipment Management and ConfigurationPage 4-16

Figure 4-5 Managed Object Entities and Hierarchy

System Discovery and InventoryIQ automatically discovers the system resources and maintains an inventory which is retrievable by the management applications. IQ discovers the following automatically:

Multi-Chassis configuration:

Main-Chassis

Expansion Chassis

4321OCG

4321DLM

Chassis

21MCM

54321TAM

21TOM

21BMM

DCF

OW M

C-band L-band

Orderwire channel

OSC GMPLS Link

Trib port

10987654321Optical channel


OCG OCGSpan

Hardware / circuit packs

Physical ports

Logical termination

points

Client Trib(Sonet/SDH/

10GbE

Trib DTF path

10G X connect(line to line)

Network element

Chassis

4321Line DTF Path (2.5G)

1Line DTF Path (10G)


10G X connect(trib to line)Containment relationship

Supported/supporting relationship

4321OCG4321OCG

4321DLM4321DLM 1DLM

Chassis

21MCM21MCM

54321TAM

54321TAM

21TOM21TOM

21BMM21BMM

DCFDCF

OW MOW M

C-bandC-band L-bandL-band

Orderwire channel

Orderwire channel

OSCOSC GMPLS Link

GMPLS Link

Trib portTrib port



1Optical channel



1Optical channel

OCGOCG OCGOCGSpanSpan

Hardware / circuit packs

Physical ports

Logical termination

points


10GbE


10GbE

Trib DTF path

Trib DTF path



Network element

Chassis









10G X connect(trib to line)

10G X connect(trib to line)Containment relationship

Supported/supporting relationship



All circuit packs in the TN780 and Optical Line Amplifier network elements (see “Circuit Pack Dis-covery” on page 4-17)

The termination points, including physical ports and logical termination points in a TN780 and Opti-cal Line Amplifier network element

The Digital Optical Network topology including Physical Topology and Service Provisioning topology (see “Network Topology” on page 4-48)

The optical data plane connectivity which includes the connectivity between the DLM and BMM in a TN780 network element (see “Optical Data Plane Autodiscovery” on page 4-17)

IQ maintains the inventory of all the automatically discovered resources, as described above, and also the user provisioned services which includes:

Cross-connects provisioned using Manual Cross-connect Provisioning mode

Circuits provisioned using Dynamically Signaled SNC Provisioning mode

Cross-connects that are automatically created while creating circuits utilizing Dynamically Signaled SNC Provisioning mode

Protection groups that have been provisioned

Refer to “Service Provisioning” on page 4-23 for more details.

Circuit Pack DiscoveryIQ provides the ability to automatically detect circuit packs in the TN780 and Optical Line Amplifier. IQ also discovers the detailed manufacturing information including:

Hardware revision

Circuit pack type

Serial ID

CLEI code

Manufacturing date

Software version

Last reboot time

The manufacturing information is maintained in the inventory and it is retrievable by the management applications.

Optical Data Plane AutodiscoveryThe UTStarcom TN780 includes optical connections between DLMs and BMMs. The connectivity is facilitated through a front-accessible optical patch cord that is used to transport the 100Gbps OCG signal between the BMM and DLM.



IQ and UTStarcom TN780 network element support the auto-discovery of connectivity between the DLM and the BMM. The auto-discovery eliminates the mis-connection between the DLM and BMM, including:

Connecting a DLM to a wrong OCG on the BMM-4. For example, connecting a DLM with OCG3 out-put to a OCG5 port on the BMM-4.

Connecting a DLM to a BMM in conflict with the pre-provisioned association of the BMM and DLM. For example, OCG3 port on BMM is pre-provisioned to be associated with the DLM in slot 4, but the user incorrectly connects the fiber to the DLM in Slot 3 (though it is OCG3).

Note: If auto-provisioning is enabled, then the BMM and DLM check only for OCG compatibility.

On detecting the mis-connection, alarms are reported so that the user can correct the connectivity. Also, the DLM is prohibited from transmitting optical signals towards the BMM to prevent the mis-connection from interfering with the other operational DLMs. In addition, the operational state of the DLM is changed to disabled.

The optical data plane auto-discovery involves control message exchanges between the active MCM in the Main chassis and the BMMs and DLMs in addition to the control message exchange between the DLM and BMM over the optical data path. The optical data plane auto-discovery requires the control plane to be available. Following are some limitations imposed by the protocol which prevents from correctly detecting the BMM and DLM mis-connection:

When the auto-discovery is in progress, there is a 5 second window during which BMM will not dis-cover any re-cabling performed by the user. Therefore, the user should not perform re-cabling while the auto-discovery is in progress. Below is a list of events during which BMM and DLM automatically initiate the optical data plane auto-discovery.

If users inadvertently connect an incorrect high power signal to the OCG port on the BMM (for exam-ple connecting the line port output to the OCG input port on BMM), it could impact traffic on the other operational OCG ports on the BMM.

The auto-discovery procedure requires the connectivity between the BMM and DLM be bi-direc-tional, in other words, the transmit and receive pair of a given OCG port on the BMM must be con-nected to the transmit and receive pair of the same line port of the DLM. If this is not true, then it will impact the active traffic.

The BMM may not detect the mis-connection if the fiber is re-cabled under the following conditions during which the control messages pertaining to the auto-discovery could be lost:

BMM is rebooted

BMM is down

BMM is unplugged

DLM is down

No active MCM in the Main chassis

No active MCM in the Expansion chassis if the BMM and DLM are not in the same chassis

NCT cable is unplugged (inter-chassis connectivity) if BMM and DLM are not in the same chassis



The user must refrain from re-cabling during the above conditions.

In general, the user must perform re-cabling only when the MCM, BMM and DLM are completely operational. This will ensure that the optical data plane auto-discovery can positively identify all mis-connections.

The operational state of the DLM is enabled, if the auto-discovery is successful, else it is disabled.

Circuit Pack ConfigurationIQ supports two modes of circuit pack configuration as described below. In both cases, the termination points are automatically created after the circuit pack is configured.

Circuit Pack Auto-configurationAs described in “Circuit Pack Discovery” on page 4-17, IQ automatically discovers the circuit packs when installed in a chassis, enabling users to bring up a circuit pack without manual configuration. The auto-configuration is performed when a circuit pack is installed in a slot which is not configured, neither pre-configured (see below) nor auto-configured. IQ discovers the installed circuit pack and also creates and configures the corresponding circuit pack managed object entity using default configuration parameters. The default administrative state of an automatically created circuit pack is unlocked so the circuit pack can start operation without manual configuration. However, users can modify this default state through management applications.

Once a slot is populated and the circuit pack auto-configuration is completed, the slot is configured and any attempt to replace the circuit pack with a different circuit pack type will raise an alarm. To enable auto-configuration of a different circuit pack in the same slot, the circuit pack configuration for the slot must first be deleted through management applications.

Circuit Pack Pre-configurationIQ supports the circuit pack pre-configuration where users can configure the slots to house a specific circuit pack before physically installing it in the chassis. Such slots are displayed as pre-configured but unpopulated through the management applications.

When the circuit pack is installed in a pre-configured slot, the circuit pack becomes operational using pre-configured data.

Once a slot is pre-configured for a circuit pack type, insertion of a different circuit pack is not allowed.

State ModelingIQ implements a state modeling which meets the various needs of all the supported management applications and interfaces, and also communicates comprehensive state of the equipment and



termination points. IQ state modeling complies with TMF814, and GR-1093 to meet the TL1 management interfaces.

IQ defines a standard state model for all the managed entities which includes equipment as well as termination points as described in “Managed Object Entities” on page 4-15. IQ defines the following states:

Administrative State—represents the user’s operation on a managed object entity (See “Administra-tive State” on page 4-20).

Operational State—represents the ability of the managed object entity to provide service (See “Operational State” on page 4-21).

Service State—represents the current state of the managed object entity which is derived from the administrative state and operational state (See “Service State” on page 4-21).

Administrative StateThe administrative state allows the user to allow or prohibit the managed object entity from providing service. The administrative state of the managed object entity can be modified only by the user through the management applications. Also, change in administrative state of a managed object entity results in a operational state change of the contained and supported managed objects. However, the administrative state of the contained and supported managed objects is not changed.

IQ defines three administrative states as given below.

Locked State—the managed object entity is prohibited from providing services to its users. Service affecting provisioning, such as modifying attributes or deleting object, and diagnostics, such as loop-backs, are allowed. Users can change the administrative state of a managed object entity to locked state from either unlocked state or maintenance state through management applications. This action results in the following behavior:

The managed object does not provide services to users.

All outstanding alarms on the managed object is cleared. No new alarms are reported on this object.

The operational state and service state of this managed object are not changed. They are deter-mined autonomously by the fault conditions that might arise, or by administrative state changes of its ancestors.

The operational state and service state of all the contained and supported managed objects are modified; the operational state is changed to disabled and service state is changed to OOS (out-of-service) state.

The redundant equipment, if there is one (for example, MCM-B), becomes active.

Unlocked State—the managed object entity in unlocked state is allowed to provide services. Using management applications, users can change the state of a managed object entity to unlocked state from either locked state or maintenance state. This action results in the following behavior:

If there are any outstanding alarms on the managed object they are reported.



The managed object entity is available to provide services (provided its operational state is enabled). However, if there is a corresponding redundant managed object entity which is active, this managed object entity will be in stand-by mode (e.g. MCM-B).

Maintenance State—the managed object entity in this state enables the maintenance operation, like Trace Messaging, PRBS testing, etc., to be performed. Users can change the state of a managed object entity to maintenance state from either locked state or unlocked state through management applications. This action results in the following behavior:

Users can perform service-impacting maintenance operations, such as loopback test, PRBS test, etc., without having any alarms reported.

All outstanding alarms are cleared on that managed object entity and all new alarm reporting and alarm logging are suppressed until the managed object entity is administratively unlocked again.

The operational state and service state of this managed object entity are not changed.

The operational state and service state of all the contained and supported managed objects are modified; the operational state is changed to disabled and service state is changed to OOS-MT (out-of-service) state.

Note: When the Admin state of a module is set to Locked or Maintenance, that state is reflected in the Equipment Tree and the Equipment View of MPower GNM.

Operational StateThe operational state indicates the operational capability of a managed object entity to provide its services. It is determined by the state of the hardware and software; it is not configurable by the user. Two operational states are defined:

Enabled—The managed object entity is able to provide service. This typically indicates that the cor-responding hardware is installed and functional.

Disabled—The managed object entity can not provide all or some services. This typically indicates that the corresponding hardware has detected some faults or is not installed. For example, when a provisioned circuit pack is removed, the operational state of the corresponding managed object entity becomes disabled.

Service State The service state represents the current state of the managed object entity which is dependent on the operational state and the administrative state. The service state is not maintained by the IQ. It is derived by the MPower GNM and MPower EMS management applications based on the operational and administrative states of an object and its ancestors. The following states are defined:

In-service (IS)—indicates that the managed object entity is functional and providing services. Its operational state is enabled and its administrative state is unlocked.



Out-of-service (OOS)—indicates that the managed object entity is not providing normal end-user services either due to its operational state is disabled or the administrative state of its ancestor object is locked, or the operational state of its ancestor object is disabled.

Out-of-service Maintenance (OOS-MT)—indicates that the managed object entity is not providing normal end-user services, but it can be used for maintenance test purposes. Its operational state is enabled and its administrative state is maintenance.

Out-of-service Maintenance, Locked (OOS-MT, Locked)—indicates that the managed object entity is not providing normal end-user services, but it can be used for maintenance test purposes. Its operational state is enabled and its administrative state is locked.



Service ProvisioningIQ provides service provisioning capabilities which includes establishing data path connectivity between endpoints for delivery of end-to-end capacity. The services are originated and terminated in a TN780 network element. The services are provisioned at 2.5G and 10G granularity and are full-duplex, bidirectional services. IQ defines following types of endpoints:

DTF Path Endpoints—are the line-side endpoints which are DTF (refer to “Digital Transport” on page 3-21 for the description of DTF) encapsulated 10G or 2.5G channels. The line-side endpoints are sourced and terminated in a DLM. As described in “Digital Line Module (DLM)” on page 3-9, each DLM supports one OCG which includes ten 10G optical channels.

Trib-side Endpoints—are client payload specific and can be any of the payload type described in “Client/Trib Interfaces” on page 3-18.

IQ automatically creates the endpoints on configuring the circuit packs as described in “Circuit Pack Configuration” on page 4-19.

IQ supports two service provisioning modes to meet diverse customers needs as described in:

“Manual Cross-connect Provisioning” on page 4-23

“Dynamically Signaled SNC Provisioning” on page 4-26

“Protection Group Provisioning” on page 4-28

As with equipment configuration, services can also be pre-provisioned as described in “” on page 4-30.

Manual Cross-connect ProvisioningIQ supports manual cross-connect provisioning mode where the cross-connects are manually configured in each TN780 network element along the circuit’s route. This mode provides users full control over which network elements are traversed for a given circuit. The cross-connects created using this mode of provisioning is referred to as the static cross-connects. The static cross-connects can be assigned circuit ID to correlate multiple cross-connects in multiple TN780 network elements forming an end-to-end circuit.

Three types of cross-connects are supported by the TN780 network element:

Express Cross-connect—associates one line-side DTF endpoint to another line-side DTF endpoint by establishing connectivity between the optical channels of two different OCGs (DLMs) within a TN780 network element. As described in “Bandwidth Grooming” on page 3-26, in Release 1.2, the cross-connects can be established between adjacent DLMs within a DTC.

Between slots 3 and 4; and slots 5 and 6, one hundred Gbps of bandwidth can be cross-con-nected.

Between slots 3 and 5; and slots 4 and 6, sixty Gbps of bandwidth can be cross-connected.

This cross-connect is transparent to the payload type encapsulated in the DTF. A typical application for this cross-connect is to establish a data path through a Digital Repeater (see “Digital Repeater Configuration” on page 2-3) site.


Service ProvisioningPage 4-24

Figure 4-6 Express Cross-connect

Add/Drop Cross-connect—associates the trib-side endpoint to the line-side endpoint by establishing connectivity between the TOM tributary port to a line-side optical channel within a DLM. Any tributary port can be connected to any of the line-side optical channels. However, a given tributary port must be associated with a line-side optical channel of the same DLM. It cannot be associated with a line-side optical channel of the adjacent DLM (see Figure 4-7 on page 4-25).

This type of cross-connect is used to add/drop traffic at a Digital Add/Drop site or to source/terminate traffic at a Digital Terminal site.

L in e f ib e r( w e s t )

B M M

O S C

D L M ( in s lo t 3 )

M A P /F E C


M A P /F E C


M A P /F E C

L in e f ib e r( e a s t )

B M M

O S C


M A P /F E C

L in e f ib e r( w e s t )

B M M

O S C


M A P /F E C


M A P /F E C


M A P /F E C

L in e f ib e r( e a s t )

B M M

O S C


M A P /F E C



Figure 4-7 Add/Drop Cross-connect

Hairpin Cross-connect—are used to cross-connect two tributary ports within a TN780 network ele-ment. In Release 1.2, hairpinning is supported within a DLM between two tributary ports, in the same or different TAMs (see Figure 4-8 on page 4-26). Such hairpin cross-connects do not use the line-side optical channel resource.

The hairpin cross-connects are used in Metro applications for connecting two buildings within a short reach without laying new fibers.

Line fiber(west)

BMM

OSC

DLM (in slot 3)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

DLM (in slot 4)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

DLM (in slot 5)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

Line fiber(east)

BMM

OSC

DLM (in slot 6)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

Line fiber(west)

BMM

OSC

DLM (in slot 3)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

DLM (in slot 4)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

DLM (in slot 5)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

Line fiber(east)

BMM

OSC

DLM (in slot 6)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOM


Service ProvisioningPage 4-26

Figure 4-8 Hairpin Cross-connects

Dynamically Signaled SNC ProvisioningIQ supports dynamically signaled Sub-Network Connection (SNC) provisioning where an end-to-end transport service is automatically provisioned utilizing IQ GMPLS control protocol as described in “IQ GMPLS Control Plane Overview” on page 4-47. In this mode, user identifies the source and destination endpoints and IQ GMPLS control protocol computes the circuit route through the Digital Optical Network and also establishes the circuit, referred to as a SNC, by automatically configuring the cross-connects in each TN780 network element along the path. The cross-connects automatically configured by the GMPLS protocol are called Signaled Cross-connects and an inventory of signaled cross-connects are retrievable through the management applications.

IQ GMPLS control protocol enables:

Error-free, automatic end-to-end SNC provisioning resulting in automatic service turn-up.

The automatic retry mechanism allowing SNC setup to be tried periodically without manual interven-tion.

SNC monitoring and alarm reporting if a circuit experiences problems in the Digital Optical Network.

Line fiber(west)

BMM

OSC

DLM (in slot 3)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

DLM (in slot 4)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

DLM (in slot 5)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

Line fiber(east)

BMM

OSC

DLM (in slot 6)

MAP/FEC

TAMTOM

TOM

TAMTOM

TOM

Line fiber(west)

BMM

OSC

DLM (in slot 3)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

DLM (in slot 4)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

DLM (in slot 5)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOMTAMTOM

TOM

Line fiber(east)

BMM

OSC

DLM (in slot 6)

MAP/FEC

TAMTOM

TOMTAMTOM

TOM

TAMTOM

TOM



Automatic re-establishment of a SNC after network problems are corrected (note that SNCs are not automatically released on detecting network problems; the SNC must be released by the user at the source node where the SNC was originated).

User configured circuit identifiers for easy correlation of alarms and performance monitoring infor-mation to the end-to-end circuit aiding in service level monitoring.

Circuit tracking by storing and making available to the management the hop-by-hop circuit route along with the source endpoint of the SNC.

Refer to “IQ GMPLS Control Plane Overview” on page 4-47 for a detailed description of the GMPLS functions.

Service Pre-provisioningIQ supports pre-provisioning of circuits, enabling users to set up both manual cross-connects and SNCs in the absence of DLMs and TAMs. Pre-provisioning of data plane connections keeps the resources in a pending state until the DLM and/or TAM is inserted. IQ internally tracks resource utilization to ensure that resources are not overbooked. The pre-provisioning of circuits requires that the supporting circuit packs first be pre-configured.


Protection Group ProvisioningPage 4-28

Protection Group ProvisioningIQ supports the provisioning of protection groups, enabling users to establish TribY-cable protection on the TN780 client tributary ports. Utilizing protection groups increases the overall reliability and service up-time for the circuits while maintaining collection of digital PMs and path protection.

Utilizing the TribY-cable protection feature offered in R1.2 eliminates the need for expensive Add/Drop Multiplexers in the network, reducing overall network operation cost.

TribY-cable enables 1+1 equipment protection of diverse paths through the Digital Optical Network for sub-50ms switching. TribY-cable protection increases the overall reliability and service up-time of the optical path.

An additional license is required to utilize TribY-cable protection:

IQ Fast Protection Software RTU, a usage based software runtime license for enabling up to 5 Y-cable protec-tion pairs on the TN780.

For information on how to purchase IQFast Protection Software RTU license contact an UTStarcom Customer Service and Technical Support resource (see “Technical Assistance” on page xiv).

In order to provision TribY-cable protection, these rules are applied:

Two tributary ports are required to form a protection group

Trib ports must be on separate DLMs

Trib ports must be in the same chassis

Trib ports must be the same service type (for example, OC-192)

Trib ports cannot be associated with an existing SNC or cross-connect

Protection Groups supports the following operations:

Allows for the provisioning of the preferred working protection unit (PU) upon creation of the protec-tion group

Lockout of working

A user initiated switch that when invoked causes the traffic that was on the working line to be switched to the protect line.

Traffic cannot be moved back to the working until the Lockout of working has been cleared.

Note: If a failure occurs on the protect while there is a lockout of working, traffic cannot switch to the working until the lockout is cleared. This can result in a loss of traffic.

Lockout of protect

A user initiated switch that when invoked causes the traffic that was on the protect line to be switched to the working line.

Traffic cannot be moved back to the protect until the Lockout of protect has been cleared.



Note: If a failure occurs on the working while there is a lockout of protect, traffic cannot switch to the protect until the lockout is cleared. This can result in a loss of traffic.

Clear lockout of working

Clears the lockout of working, enabling the working to carry traffic

Traffic will remain on the protect unless a failure occurs, or a user initiated switch in invoked

Clear lockout of protect

Clears the lockout of protect, enabling the protect to carry traffic

Traffic will remain on the working unless a failure occurs, or a user initiated switch in invoked

Manual Switch

A user initiated switch that when invoked on the working, moves the customer traffic to the pro-tect

A user initiated switch that when invoked on the protect, moves the customer traffic to the work-ing

Note: If a higher priority switch is in effect, then the manual switch command will be denied.

Note: The invoking of a lockout of working, a lockout of protect, or an automatic switch will over-ride a manual switch.

Automatic switching <50ms

Automatic switching is invoked by the TN780 and is caused by the following triggers:

Loss of Frame (LOF)

Bit Error Rate based Signal fail (BER-based SF)

Alarm Indication Signal (AIS)

Loss of Signal (LOS)

Loss of Light (LOL)

Equipment failure

Note: All switches (lockout of working, lockout of protect, manual, and automatic) will result in a <50ms interruption in customer traffic.


Protection Group ProvisioningPage 4-30

Note: All switches are non-revertive. In a non-revertive switch the traffic is switched from working to protect, the traffic will stay on protect until there is a failure (resulting in an automatic switch), or a user initiated switch is invoked (manual switch, lockout of working, lockout of protect).

Creation of new protection groups

Deletion of protection groups

The provisioning of TribY-cable protection eliminates the need for traditional ADMs used for protection, which lowers overall network costs to UTStarcom customers.

Figure 4-9 TribY-cable Protection

Protect Line

WorkingLine

Y-Cable

Y-Cable



Performance Monitoring and ManagementIQ provides extensive performance monitoring to provide early detection of service degradation before a service outage occurs. The performance monitoring capabilities allow customers to pro-actively detect problems and correct them before end-user complaints are registered. Performance monitoring is also needed to ensure contractual Service Level Agreements between the customer and the end-user.

IQ provides performance monitoring functions in compliance with GR-820. The following features are supported:

Extensive performance data collection at every node, including,

Optical performance monitoring (PM) data within the optical domain (see “Optical PM Parame-ters and Thresholds” on page A-2)

Client signal agnostic DTF PM data at every TN780 network element (see “DTF PM Parameters and Thresholds” on page A-10)

FEC PM data enabling BER calculation (see “FEC PM Parameters and Thresholds” on page A-15)

Native client signal PM data at the tributary ports (see “Client Signal PM Parameters and Thresholds” on page A-16)

Optical supervisory channel performance monitoring data (see “OSC PM Parameters” on page A-20)

Comprehensive PM data collection functions, including,

Real-time PM data collection for real-time troubleshooting (see “Real-time PM Data Collection” on page 4-32)

Historical PM data collection for service quality trend analysis (see “Historical PM Data Collec-tion” on page 4-32)

Threshold crossing notifications for early detection of degradation in service quality (see “PM Thresholding” on page 4-33)

Invalid data flag indicator per managed object instance per period (see “Suspect Interval Mark-ing” on page 4-33)

Flexible PM data reporting and customizing options to meet diverse customers’ needs, including,

Automatic and periodic transfer of PM data in CSV format enabling customers to integrate with their management applications (“PM Data Transfer” on page 4-33)

Customization of PM data collection (see “PM Data Configuration” on page 4-34“)


Performance Monitoring and ManagementPage 4-32

PM Data CollectionIQ collects digital PM data and optical PM data.

IQ utilizes gauges to collect optical PM data. The gauge attribute type, as defined in ITU X.721 specification, indicates the current value of the PM parameter and is of type float. The gauge value may increase or decrease by arbitrary amount and it does not wrap around. It is a read-only attribute.

The counters are utilized to collect the digital PM data. The counter value is a non-negative integer. The value of the counter is reset to zero at the beginning of the PM period and it is counted in upward direction with an increment of 1. The counter size is selected in a such a way that the counter does not rollover within the collection period.

Real-time PM Data CollectionIQ supports real-time PM data retrieval which is useful for real-time troubleshooting. The real-time PM data represents the state at the time of its retrieval. The real-time data can be retrieved by the management applications at any time.

IQ provides the real-time PM data for some of the optical and digital PM parameters. The real-time optical PM data provides the state of the hardware (value of the PM parameter) at the time of its retrieval. The real-time digital PM data is essentially the value of the digital PM counter at the time of its retrieval.

Historical PM Data CollectionIn addition to the real-time PM data, IQ provides the historical PM data archived locally in the network element enabling service quality trend analysis. IQ collects the historical PM data at the following intervals:

15-minute

24-hour

IQ maintains the following historical counters/gauges:

Current 15-minute and ninety-six previous 15-minute counters/gauges

Current 24-hour and seven previous 24-hour counters/gauges

The historical PM data is not asynchronously reported to the management applications. It must be retrieved by the users through management applications.

Note that the historical counters/gauges are supported only for some PM parameters, but not for all.

The historical (current and previous) optical PM data is derived by taking several snapshots of the hardware status. In other words, the optical PM parameter value is read from the hardware every five seconds within a PM period, and minimum, maximum and average values are derived from all the readings. Thus the historical optical PM data is the minimum, maximum and average of the PM parameter values within a given period.

The historical digital PM data is essentially the value of the counter at the end of the given PM period.



PM ThresholdingThe PM thresholding provides an early detection of faults before significant effects are felt by the end users. Degradation of service can be detected by monitoring error rates. Threshold mechanisms on counters and gauges allow the detection of such trends and provide a warning to users when the error rate becomes high.

IQ supports thresholding for both optical PM gauges and digital PM counters. During the PM period, if the current value of a performance monitoring parameter reaches or exceeds corresponding configured threshold value, threshold crossing notifications are sent to the management applications.

Optical PM Thresholding—IQ performs thresholding on some optical PM parameters by utilizing high and low threshold values. Note that the thresholds are configurable for some PM parameters, for others, system utilizes pre-defined threshold values. An alarm is reported when the measured value of an optical PM parameter is outside of its threshold values. The alarms are automatically cleared by IQ when the recorded value of the optical PM parameter is within the acceptable range.

Digital PM Thresholding—IQ performs thresholding on some digital PM data utilizing high threshold values which are user configurable. The Threshold Crossing Alert (TCA) is reported when a PM counter, within a collection period, exceeds the corresponding threshold value. When a threshold is crossed, IQ continues to count the errors during that accumulation period. As with PM counters, TCAs are transient in nature and are reported as events which are logged in the event log buffers as described in “Event Log” on page 4-10. The TCAs do not have corresponding clearing events since the PM counter is reset at the beginning of each period.

Note that the PM thresholding is supported for some of the PM parameters, but not for all.

Suspect Interval MarkingIQ marks the PM data for a given managed object instance collected in 15-minute and 24-hour periods as suspect or invalid by maintaining an invalid data flag (IDF). The IDF is maintained per managed object instance per period basis. The IDF is retrievable by management applications and is used to communicate to the user the validity of the collected PM data. The PM data is marked invalid under the following conditions:

User resets the PM counter through management applications.

The period of PM data accumulation changes by +/-10secs (e.g., the network element’s time of day setting was changed during the period).

Loss of PM data due to system restart or hardware failure.

PM Data TransferIQ stores the entire PM data in flat files in CSV format. Users (customers) can use these flat files to integrate PM data analysis into their management applications or simply view the PM data through the spreadsheet applications.


Performance Monitoring and ManagementPage 4-34

Users can schedule the TOD (time of day) at which the network element automatically transfers the PM data to the user specified FTP server. Users can configure primary and secondary FTP server addresses. If the data transfer to the primary FTP server fails, the PM data is transferred to the secondary FTP server.

PM Data ConfigurationIQ allows users to customize the PM data collection. Users can configure the PM data collection through management applications. IQ supports the following configuration options:

Reset the current 15-minute and 24-hour counters at any time per managed object instance.

Change the default threshold values according to the customer’s error monitoring needs.

Enable or disable the PM threshold crossing alarm and TCA reporting per attribute per managed object instance.

Configure the frequency of PM flat file uploading to the FTP servers as configured.

User configures periodic uploading of PM data to the client machine



Security and Access ManagementIQ’s security and access management features comply with Telcordia GR-815-CORE standard. The supported features include:

User identification to indicate the logged in user or process (see “User Identification” on page 4-35).

User authentication to verify and validate the authenticity of the logged in user (see “Authentication” on page 4-36).

User access control to prevent intrusion (see “Access Control” on page 4-36).

Resource access control by defining multiple access privileges (see “” on page 4-36).

Security audit logs to monitor unauthorized activities (see “Security Audit Log” on page 4-39).

Security functions and parameters to implement site-specific security policies (see “Security Admin-istration” on page 4-40).

User IdentificationEach network element user is assigned a unique user ID. The user ID is case-sensitive and contains 4 to 10 alphanumeric characters. The user specifies this ID (referred to as user login ID) to log into the network element.

By default, IQ creates three user accounts with the following user login IDs:

secadmin with security administrator privilege enabled. The default password is Infinera1 and the user is required to change the password at first login. This user login ID is used for initial login to the network element.

netadmin with network administrator privilege enabled. The default password is Infinera1 and the user is required to change the password at first login. Additionally, this account is disabled by default. It must be enabled by the user with security administrator privilege through the TL1 Interface or MPower GNM. This account is used to turn-up the network element.

emsadmin with all privileges enabled. The default password is Infinera1. This account is disabled by default. It must be enabled by the user with security administrator privilege through the TL1 Interface or MPower GNM. MPower EMS Server communicates with the network element using this account, referred to as MPower EMS account when it is started without requiring additional configuration. Users can create additional MPower EMS accounts which MPower EMS Server can use to connect to the network element. These accounts must have the EMS access capability enabled during cre-ation.

A single user can open multiple sessions. IQ maintains a list of all current active sessions.

Note: IQ supports a maximum of 30 active user sessions at any given time. All login attempts beyond 30 sessions will be denied and a warning message is displayed.


Security and Access ManagementPage 4-36

AuthenticationIQ supports standards-based authentication features. These features ensure that only authorized users log into the network element through management interfaces.

Each time the user logs in, the user must enter a user ID and password. For the initial login, the user specifies the default password set by the security administrator. The user must then create a new password based on the following requirements.

The password must contain

Six to ten alphanumeric characters

At least one alphabetic and one numeric or one special character

The password may contain these special characters: @ # $ % ^ ( ) _ + | ~ { } [ ] ? -

The password must not contain:

The associated user ID

Blank spaces

The passwords are case-sensitive and must be entered exactly as specified.

The password is stored in the network element database in a one-way encrypted form.

The password rotation is implemented to prevent users from re-using the same password. The users are forced to use passwords different from the previously used passwords. The number of history passwords stored is configurable.

Access ControlIn addition to user login ID validation and password authentication, IQ supports access control features to ensure that the session requester is trusted, such as:

Detection of an unsuccessful user login and if the unsuccessful login exceeds the configured num-ber of attempts, the session is terminated and a security event is logged in the security audit log.

User session is automatically terminated when the cable connecting the user computer and the net-work element is physically removed. The user must follow the regular login procedure after the cable is reconnected.

The activity of each user session is monitored. If, for a configurable period of time, no data is exchanged between the user and the network element, the user session is timed-out and the ses-sion is automatically terminated.



AuthorizationMultiple access privileges are defined to restrict user access to resources. Each access privilege allows a specific set of actions to be performed. Assign one or more access privileges to each user account. For the description of the actions allowed for each access privilege, see Table 4-1 on page 4-37. For the description of the managed entities, see “Managed Object Entities” on page 4-15.

There are six levels of access privileges:

Monitoring Access (MA)—allows the user to monitor the network element; cannot modify anything on the network element (read-only privilege). The Monitoring Access is provided to all users by default.

Security Administrator (SA)—allows the user to perform network element server security manage-ment and administration related tasks.

Network Administrator (NA)—allows the user to monitor the network element, manage equipment, turn-up network element, provision services, administer various network-related functions, such as, auto-discovery and topology.

Network Engineer (NE)—allows the user to monitor the network element and manage equipment.

Provisioning (PR)—allows the user to monitor the network element, configure facility endpoints, and provision services.

Turn-up and Test (TT)—allows the user to monitor, turn-up, and troubleshoot the network element and fix network problems.

Table 4-1 Access Privilege Permissions

Managed Object Entity Operation SA NA NE PR TT MA

Equipment ManagementChassis Create, delete and

update No Yes Yes No No No

DLM Create, delete and update

No Yes Yes No No No

TAM Create, delete and update

No Yes Yes No No No

BMM Create, delete and update

No Yes Yes No No No

Alarm input and out-put contacts

Update No Yes Yes No No No

TOM Create, delete and update

No Yes Yes No No No

OAM Create, delete and update

No Yes Yes No No No

OMM Create, delete and update

No Yes Yes No No No



PEM Create, delete and update

No Yes Yes No No No

Termination Point (physical ports or logical ports) ManagementOTS Update No Yes No Yes Yes No

Band Update No Yes No Yes Yes No

OCG - BMM Update No Yes No Yes Yes No

OCG - DLM Update No Yes No Yes Yes No

Channel Update No Yes No Yes Yes No

DTF Path Update No Yes No Yes Yes No

Trib Update No Yes No Yes Yes No

Client Update No Yes No Yes Yes No

OSC Update No Yes No Yes Yes No

DCF Update No Yes No Yes Yes No

ServicesCross-connect Create, update and

DeleteNo Yes No Yes No No

SNC circuit Create, update and Delete

No Yes No Yes No No

Protection Group Create No Yes No Yes Yes No

System Administration and Software Maintenance FunctionsPeriodic PM data transfer

Update No Yes No Yes Yes No

System date and time

Update No Yes No No No No

Software download Update No Yes No No No No

Database download Update No Yes No No No No

Database upload Update No Yes No No No No

ASAP (Alarm Sever-ity Assignment Pro-file)

Update No Yes No No No No

Alarm acknowledg-ment

Update No Yes Yes Yes Yes No

Network Element Security Administration

Users Create, update and delete

Yes No No No No No





Security Audit LogIQ maintains an independent and persistent circular audit log that records all system configuration activities and security related events, such as unauthorized attempts and excessive authentication attempts. The audit log provides traceability of all system-impacting changes. The supported features include:

The audit logs include system configuration activities and security related activities performed by the user. These activities include:

Creating and deleting managed object entities

Updating an attribute of the managed object entity

Invalid login attempts

Unauthorized attempts to access resources due to restrictions imposed by the user access priv-ilege

Updates to the user's security parameters, such as the password, user access privilege, pass-word aging time, etc.

Updates to the network element security parameters such as maximum number of invalid login attempts, and inactivity time-out interval

The audit logs are maintained in a circular buffer and hence the oldest records are overwritten.

The audit logs are preserved when system reboots

Each audit log entry includes the following minimum set of information:

User login ID of the user who performed the action, along with terminal, port and network address information

Date and Time of the operation

Action performed

Instance of the managed object entity on which the action was performed

Result of the operation performed

Users cannot modify the audit logs

Security parameters Update Yes No No No No No






Users (with any access privilege) can view the audit logs through the management applications

Security AdministrationIQ defines a set of security administration functions and parameters that are used to implement site-specific policies. Security administration can be performed only by users with security administrator privilege. The supported features include:

View all users currently logged on

Disable and enable a user account (this operation is allowed only when the user is not logged on)

Modify user account parameters, including access privilege and password expiry time

Delete a user account and its attributes, including password

Reset any user password to system default password

Monitor security audit logs to detect unauthorized access

Monitor the security alarms and events raised by the network element and take appropriate actions

Configure system-wide security administration parameters:

Default password

Inactivity time-out period

Maximum number of invalid login attempts allowed

Number of history passwords

Advisory warning message displayed to the user after successful login to the network element



Software Configuration ManagementIQ provides the following capabilities to manage software and database images on the TN780 and Optical Line Amplifier network elements:

“Software Download” on page 4-41

“Software Upgrade” on page 4-41

“Database: Download/Backup/Restoration/Rebranding” on page 4-43

Software DownloadThe IQ, operating TN780 network element and Optical Line Amplifier network elements, is packaged into a single software image. The software image includes the software components required for all the circuit packs in the TN780 and Optical Line Amplifier network elements.

Users can remotely download the software image from a customer specified FTP server to the MCM of the TN780 and OMM of the Optical Line Amplifier network element. Once users download the software image to the MCM/OMM and initiate the software upgrade procedure, the software is automatically distributed to the remaining circuit packs within the chassis.

The network element can store up to three versions of the software image at the same time.

Software UpgradeThe network elements support in-service software upgrade. The software upgrade procedure lets users activate a different software version from the one currently active. The following software upgrade operations are supported:

Install Software—this operation lets users activate the new software image version with an empty database. The software image may be older or newer than the active version.

Upgrade Software—this operation lets users activate the new software image version with the previ-ously active database. The previously active database version must be compatible with the new software image version.

Activate Software and Database—this operation lets users activate a new software image version and a new database version. The database version must be compatible with the software image ver-sion. Before upgrading the software, the new database image must be downloaded to the network element.

Restart Software—this operation lets users activate the current software image with an empty data-base.

In-Service Rollback—allows the system the ability to gracefully “fall-back” or “down-grade” to a prior release in the rare event that a failure in experienced during the upgrade process.


Software Configuration ManagementPage 4-42

In general, upgrading the software does not affect existing service. However, if the new software image version includes a different Firmware/FPGA version than the one currently active, it could impact existing services. If this occurs, a warning message is displayed.

Users must upgrade the software on a node-by-node basis. Therefore, at any given time, the network elements within a network may be running at least two software image versions. These different images must be compatible. In the presence of multiple software versions, the network provides functions that are common to all the network elements.

The software upgrade procedure:

1. Verifies that the software and database versions are compatible. If they are not compatible, the upgrade procedure is not allowed.

2. Validates the uncompressed software image. If the software image is invalid, the upgrade proce-dure is not allowed.

3. Decompresses the software image. If there is not enough memory on the network element to store the decompressed image, the upgrade procedure is aborted and software image reverts to the pre-viously active software image version.

4. Reboots the network element so that the new software image becomes active. If the reboot fails, the upgrade procedure is aborted and software image reverts to the previously active software image version.

5. When the new software image is activated, the software upgrade procedure updates the format of the Event Log and Alarm table alarms, if necessary.

Note: When the software is upgraded, the PM historical data is not converted to the new format (if there is a change in the format) and it is not persisted. Therefore, before you upgrade the software, you must upload and save the PM data in your local servers.

In general, if the upgrade procedure is aborted, the software reverts to the previously active version. The procedure reports events and alarms indicating the cause of the failure.

The software upgrade is also supported when there is one MCM or OMM in the Node Controller chassis. During the upgrade process, the communication with the clients and also with other network elements within the network is interrupted.

Remote Hardware FPGA UpgradeThe TN780 hardware modules support the ability to be remotely upgraded including all types of:

TAMs

DLMs

BMMs.

The ability to remotely upgrade hardware using a controlled process is integrated in Software Release 1.2.



UTStarcom has implemented Foppish within many of the TN780 hardware modules to take advantage of the field-updatable features of the FPGA. These FPGAs support many different features and functions within the hardware and can be remotely upgraded within the field to add features or correct design inefficiencies without requiring replacement repair and return of the hardware modules.

Upgrade of the FPGAs is performed via updating the FPGA “image” – which is a list of programmable instructions that tell the FPGA how it should operate and what features it should provide. New FPGA images may (or may not) be provided within a new software release, and any enhancements to FPGA images will identified within the Software Release Notes describing the functional change to the hardware that the FPGA image provides.

Note: Although the hardware upgrade can be performed from a remote location, the hardware module will require a cold reboot.

Note: The FPGA image download may be service impacting to the targeted module.

Database: Download/Backup/Restoration/RebrandingTo ensure that the correct database is activated on a network element, the database image includes this information:

The database version. This is used to check its compatibility with the software image version. The database image version must be older or equal to the software image version.

The backplane ID of the network element on which the database was created.

The following database operations are supported:

“Database Download” on page 4-43

“Database Backup” on page 4-43

“Database Restoration” on page 4-44

Database DownloadUsers can download the previously backed up database file to the network element from a specified FTP server. Up to three database versions can be stored on the network element at a time. The downloaded database file does not change the current active database. It is simply stored in the persistent memory of the network element.

Database BackupThere are two database backup modes:



Manual Database Backup—Users can manually backup the current database image to the specified FTP server at any time.

Scheduled Database Backup—Users can schedule the database to be backed up automatically, at either daily or weekly intervals. Users can also specify a primary and secondary FTP server to store the backup. By default, the database is backed up to the primary server; however, if that server is not available, the database is backed up to the secondary server.

The database file that has been backed up contains:

Database file, which includes configuration information stored in the persistent memory on the net-work element.

Alarm table stored in the persistent memory of the network element.

Event Log stored in the persistent memory of the network element.

Database RestorationUsers can perform the restore operation to activate a new database image file with the current active software image version. The new database image file must be compatible with both the software image version and the network element. The restore operation restarts the network element and activates the new database image. Users can restore the database at system reboot time or at time any during normal operation.

If the restore operation fails, the software rolls back to the previously active database image and an alarm is raised indicating the failure of the restore operation. When the database is successfully restored, the alarm is cleared. Users can manually restore the database.

Depending on the differences between the two databases, the database restore operation could affect service. The database restoration procedure:

Restores the configuration data as per the restored database. The configuration data in the restored database may differ from the current hardware configuration. In such scenarios, in general, the con-figuration data takes precedence over the hardware.

Restores the alarms in the Alarm table by verifying the current alarm condition status. For example, if there is an alarm entry in the restored Alarm table but the condition is cleared, that alarm is cleared from the current Alarm table. On the other hand, if the alarm condition still exists, the corresponding alarm entry is stored in the current Alarm table with the original timestamp.

Note: The data in the Event Log is not restored.

The database image can be restored at system reboot time or at time any during normal operation.

Following is the description of some scenarios where the configuration data in the restored database differs from the current hardware configuration and how they are handled:

Scenario 1: The restored database contains a managed equipment entity but there is no corre-sponding hardware present in the chassis. In this scenario, the corresponding equipment is consid-ered to be pre-configured (refer to “Circuit Pack Pre-configuration” on page 4-19).



For example, consider the following sequence of operations:

Backup database

Remove a circuit pack from the chassis

Restore the previously backed up database.

After the database restoration, the removed circuit pack is pre-configured.

Scenario 2: If the restored database does not contain a managed equipment entity but the hard-ware is present in the network element, the managed equipment entity is created in the database as in equipment auto-configuration (refer to “Circuit Pack Auto-configuration” on page 4-19).


Backup database

Install a new circuit pack

Restore the previously backed up database.

In this case, after database restoration, the newly inserted circuit pack is auto-configured.

Scenario 3: If the managed equipment entity exists in the database and the corresponding hard-ware equipment is present in the network element, but there is a configuration mismatch, an equip-ment mismatch alarm is reported and the operational state of the equipment is changed to out-of-service (see “Operational State” on page 4-21).

Scenario 4: If the restored database contains a manual cross-connect configuration information but there is no cross-connect configured in the hardware, then IQ provisions the corresponding manual cross-connect (provided the required data path resources exist) according to the configuration infor-mation in the restored database.


Backup the database

Delete a manual cross-connect

Restore the database

In this case, the manual cross-connect was deleted after database backup is recreated.

Scenario 5: If the restored database does not contain a manual cross-connect configuration, but a manual cross-connect is provisioned in the hardware, then the manual cross-connects is torn down (deleted) as per the configuration information in the restored database.


Backup the database

Create a manual cross-connect

Restore the database

In this scenario the manual cross-connect, that was created after the database backup, is deleted.

Scenario 6: If the restored database does not contain SNC configuration information, but an SNC is provisioned in the hardware, then the SNC is torn down (released) by releasing the signaled cross-



connects (see “Dynamically Signaled SNC Provisioning” on page 4-26) along the SNC path. How-ever, it takes approximately 45mins to release the signaled cross-connects. Note that the SNC con-figuration information is stored on the source node only. The intermediate nodes contain only the signaled cross-connects.

For example, consider a SNC that spans 3 nodes: Node A, Node B and Node C and Node A is the source node. Consider the following sequence of operations:

Backup the database on Node A

Create an SNC from Node A to Node C passing through Node B which results in corresponding signaled cross-connects being created on Node B and Node C

Restore the database on Node A

In this case, the restored database on Node A does not contain the SNC configuration information. However, Node B and Node C have signaled cross-connects which are released after 45mins to match the restored database in the Node A.

Consider the following sequence of operation for the same network configuration as in the previous example,

Backup the database on Node B

Create an SNC from Node A to Node C passing through Node B which results in corresponding signaled cross-connects being created on Node B and Node C

Restore the database on Node B which results in signaled cross-connect corresponding to the SNC created after database backup being deleted.

In this scenario, since Node A contains the SNC configuration, the corresponding, deleted signaled cross-connect in Node B is recreated. However, it may take up to 15mins for the SNC to come back up.

Database rebranding The database from one network element can be restored into another network element by re-brand-

ing. When a MCM is inserted into a chassis there are two options; if the MCM was not commissioned previously, then the MCM will boot normally; if the MCM was commissioned previously but used in another network element, then the MCM should be re- branded. For more information on re-brand-ing refer to the UTStarcom TN780 Turn-up and Test Guide.



IQ GMPLS Control Plane OverviewIQ provides an intelligent GMPLS control plane architecture that enables automated end-to-end management of transport capacity across Digital Optical Network resulting in a rapid, error-free service turn-up and operational simplicity. With a simple “point-and-click” approach to provisioning, users need only identify the A and Z service endpoints, and the intelligent control plane automatically configures the intermediate network elements to route the transport capacity, without manual intervention.

The GMPLS control plane provides several benefits, including:

Rapid, real-time end-to-end service provisioning.

Traffic engineering/bandwidth management at optical layer.

Multi-service support.

Simplified service provisioning independent of network topology.

Automatic protection and restoration capabilities utilizing

The UTStarcom GMPLS control plane implementation is based on two key industry standard protocols: OSPF-TE, an IP routing protocol, and RSVP-TE, a GMPLS signaling protocol. The OSPF-TE performs network topology discovery and route computation. The RSVP-TE signaling protocol establishes a circuit along the route computed by the OSPF-TE. An end-to-end circuit setup by GMPLS control plane within a routing domain is referred to as a subnetwork connection (SNC).

The GMPLS control plane supports the following features:

Supports dynamically signaled SNC provisioning.

Supports 10G and 2.5G SNCs to be established. A 10G SNC is setup for the SONET OC-192, SDH STM-64, 10G Clear Channel, 10GbE LAN Phy, 10GbE WAN Phy services and 2.5G SNC is setup for the SONET OC-48, SDH STM-16 and 1GbE services.

Allows SNC to be provisioned between any two tributary ports of the same type.

Supports point-to-point, linear add/drop, junction site, and ring topologies.

Supports service pre-provisioning; pre-provisioned service becomes operational on installing the hardware equipment.

Traffic engineering control utilizing constraint-based source routing.

OSPF-TE Routing ProtocolIQ utilizes OSPF-TE routing protocol to discover the Digital Optical Network topology, and to perform route computation utilizing Constrained Shortest Path First (CSPF) algorithm. The OSPF-TE implementation is based on OSPF v2 (IETF RFC 2178 and RFC 3630).


IQ GMPLS Control Plane OverviewPage 4-48

Network TopologyIQ utilizes OSPF-TE to discover Digital Optical Network topology. It models the Digital Optical Network topology by defining the following elements:

A routing node which corresponds to a network element within the Digital Optical Network.

A control link which corresponds to OSC control between the adjacent routing nodes or network ele-ments. There is one control link for each fiber. So, in the case of a multi-chassis, multi-fiber sites, there will be multiple control links between adjacent network elements.

A GMPLS link which corresponds to transport capacity between the adjacent TN780s. There is one GMPLS control link for each fiber. So, in the case of a multi-chassis, multi-fiber sites, there will be multiple GMPLS links between adjacent network elements. Each GMPLS link supports up to 400Gbps transport capacity which maps to four OCGs or four Traffic Engineering (TE) links.

Within the Digital Optical Network, a routing node corresponds to a network element which could be a TN780 or an Optical Line Amplifier, a control link corresponds to OSC communication between the adjacent network elements (TN780 or Optical Line Amplifier) and GMPLS link corresponds to the digital link between adjacent TN780 network elements.

IQ defines two topology maps:

Physical Network Topology—The physical network topology is defined by the topology of the OSC, which provides the communication path for the routing and signaling protocols between network ele-ments. The physical network topology mirrors the physical fiber connectivity between the network elements, and thus the topology elements include all network elements, TN780 and Optical Line Amplifier, and control links which corresponds to the fiber connecting the network elements. (See Figure 4-10 on page 4-48.)

Figure 4-10 Physical Network Topology

However, independent of the physical fiber connectivity, customers can create topology partitions where each partition represents a continuous routing and signaling domain. The topology partitions are created by disabling the OSPF interface. In Figure 4-11 on page 4-49, Domain 1 and Domain 2 are two topology partitions created by disabling GMPLS between network element C and network element D. Note that in Release 1.2, SNC spanning two topology partitions are not supported and they are operated as two separate networks.

Fiber/ control link (OSC)Fiber/ control link (OSC)



Figure 4-11 Single Network with Topology Partition

Service Provisioning Topology—the service provisioning topology is a higher layer logical topology providing users a view of topological nodes where services can be terminated, groomed or ampli-fied, and the associated digital links between them. In a Digital Optical Network, the service provi-sioning topology consists of TN780 network elements and digital links between them. Thus, in a service provisioning topology, all Optical Line Amplifiers are eliminated. Figure 4-12 on page 4-49 illustrates the service provisioning topology of the physical topology shown in Figure 4-10 on page 4-48.

Figure 4-12 Service Provisioning Topology

Users can view the physical network topology, referred to as physical view, and service provisioning topology, referred to as provisioning view, through the management applications.

Thus, the physical topology represents the topology of the control plane traffic (e.g. OSPF-TE messages) and management plane traffic (messages exchanged between the network element and the management application, such as MPower EMS), whereas the service provisioning topology represents the data plane traffic (client traffic).

Traffic EngineeringIQ supports several traffic engineering parameters both at the link level and node level. The rich set of traffic engineering parameters enable users to create networks that are utilized most efficiently.

The node and equipment level traffic engineering parameters include:

Node Inclusion List—specifies an ordered list of nodes a SNC must pass through. The inclusion list is ordered and must flow from source to destination. This capability is used to constrain a SNC to traverse certain network elements in a particular order. For example, in the network shown in Figure

Node A

Domain 1 Domain 2

GMPLS is disabled

Node B Node C Node E Node F Node GNode DNode A

Domain 1 Domain 2

GMPLS is disabled

Node B Node C Node E Node F Node GNode D

TE Link TE LinkTE Link TE Link



on page 4-51, the constraint to include node D can be used to mandate a route with source as A, one of the intermediate nodes as B and destination as F. This allows the traffic to be dropped at site D in future. The inclusion list is configurable through the management applications.

Figure 4-13 Illustration of Using Node Inclusion Constraint

Node Exclusion List—Specifies a list of nodes SNC must not pass through. For example, the exclu-sion list can be used to avoid congested nodes. The exclusion list is not ordered and it is config-urable through the management applications.

Use installed equipment only—IQ enables the equipment pre-provisioning where equipment is pre-provisioned but not installed. This constraint enables a SNC to pass through installed equipment only. Users can specify this through the management applications.

Disable OCG Port—As described in “Optical Transport Layers” on page 3-30, the TN780 employs two-stage optical multiplexing where the transport capacity is added to the GMPLS link in increments of 100Gbps by adding OCGs (DLMs). Using this constraint users can disable the use of an OCG to set up dynamically signaled SNC circuits. However, the OCG can be used to setup manual cross-connects. For example, users may want to set aside some bandwidth for manual cross-connect pro-visioning. This constraint is configurable through the management applications.

Switching Capacity—This parameter considers the switching/grooming capacity of the TN780. As described in “Bandwidth Grooming” on page 3-26, in Release 1.2, the switching and grooming between non-adjacent DLMs is supported.

The GMPLS link level traffic engineering parameters include:

Link Cost—the cost of the GMPLS link can be provisioned through the management applications. A route with least cost is selected. Users can use this to control how the traffic is routed.

Link Inclusion List—specifies an ordered list of control links a SNC must pass through. This is similar to the node inclusion list described earlier.

Link Exclusion List—specifies a list of control links SNC must not pass through. This is similar to the node exclusion list described earlier.

Link Capacity—the link capacity is another parameter that is considered during route computation. IQ maintains the following information based on the hardware state and user configuration informa-tion, which is retrievable through the management applications:

Maximum capacity of the link based on the installed hardware

Node A

Domain 1 Domain 2

GMPLS is disabled

Node B Node C Node E Node F Node GNode DNode A

Domain 1 Domain 2

GMPLS is disabled

Node B Node C Node E Node F Node GNode D



Usable capacity of the link based on the hardware and software state

Available capacity of the link for the new service requests

Additionally, users can provision the admin weight or cost for the control link. The control link cost denotes the desirability of the link to route control traffic and management traffic. The lower (numerically) the cost, the more desirable the link is.

All the traffic engineering parameters described above are exchanged between the network element as part of the topology database updates.

Constrained Shortest Path Route ComputationThe OSPF-TE performs SNC route computation utilizing CSPF (constrained shortest path first) algorithm. The CSPF provides the following benefits:

Route SNCs around known bottlenecks or points of congestion in the network.

Provide precise control over how traffic is rerouted when the primary path is faced with single or multiple failures.

Provide more efficient use of available aggregate bandwidth and long-haul fiber by ensuring that subsets of the network do not become overutilized while other subsets of the network along potential alternate paths are under utilized.

The CSPF considers all the traffic engineering parameters described in “Traffic Engineering” on page 4-49 while performing SNC route computation. In the presence of multiple routes, the least cost (based on the cost of the GMPLS link configured by the user) route is selected.

GMPLS Signaling (RSVP-TE)The RSVP-TE signaling protocol is used to establish a SNC along the route computed by the OSPF-TE. The computed route is specified as explicit route object in the RSVP-TE signaling messages. The SNC is established when the RSVP-TE signaling messages are exchanged successfully between all nodes. If the SNC setup fails due to failures in the network, IQ reports appropriate error messages through the management applications and retries the SNC setup periodically until the setup is successful or user chooses to delete SNC. For every retry, a new route is computed and SNC is setup along the new route computed by the OSPF-TE.

Once the SNC is established, the SNC is not deleted unless the user explicitly requests the SNC to be deleted.

Handling Fault ConditionsThe GMPLS control plane monitors and detects fault conditions that impacts service availability and takes necessary precautions. Following are some faults that are detected by the GMPLS control plane:

Lower layer hardware or connectivity failures resulting in reduction in bandwidth availability: such fault conditions result in OSPF-TE protocol advertise the new available bandwidth. However, the



SNCs which are already established are neither deleted nor rerouted. When the fault condition is cleared, the SNCs resume their operation.

The faults, such as fiber cuts, resulting in topology partition: such fault conditions result in topology database updates. However, the SNCs that span partitioned topologies will not provide service. The SNC becomes operational after the fault condition is cleared.

Topology Configuration GuidelinesThe OSPF V2 (RFC 2178) does not specify any guidelines for the number of routers in an area or the best way to architect an OSPF network. Customers must design the OSPF networks based on their specific application and/or constraints. Every network element in the network adds routing control traffic to OSPF and increases the load on CSPF computation algorithm.

Note that all Control and GMPLS links, by default, are associated with area 0.0.0.0. The area ID is not configurable.

Control Link ConfigurationThe control link between adjacent network element is enabled by:

Provisioning the BMMs on each network element.

Provisioning the OSC IP address on either side of the control link. The OSC IP address has to be routable and unique within a routing and signaling domain. However, it can be an internal (unregis-tered) IP address. Also, the sub-network mask has to be identical on both ends of the control link. This ensures that both ends of the control link are on the same subnet.

Provisioning control link (OSPF) cost as per the desired network design. Note that the configuration of OSPF cost is optional. A default value of 100 is assigned for every control link.

Enabling OSPF interface on either side of the control link.

GMPLS Link ConfigurationThe GMPLS link includes the various configurable traffic engineering parameters as described in “Traffic Engineering” on page 4-49.



IQ Management Plane OverviewIQ provides a highly available, reliable and redundant management plane communications path which connects the network operations centers (NOCs) to the physical transport network and meets the diverse customers needs. The management plane includes:

Direct DCN (Data Communications Network) access where the NOC is connected to the network element through a DCN network which is typically an IP-based network. The DCN is designed in such a way that there is no single point of failure within the DCN network. (See “DCN Communica-tion Path” on page 4-53.)

In-band access through a Gateway Network Element (GNE) where a network element is accessed through another network element which acts as a gateway to transport the management traffic over the OSC control link between the network elements. (See “Management Application Proxy” on page 4-56)

Static routing to access external networks that are not within the DCN network. (See “Static Rout-ing” on page 4-58.)

Telemetry access utilizing a dial-up modem which provides users remote access through the serial port on the network element.

IQ management plane supports Network Timing Protocol (NTP) to provide accurate time stamping of alarms, events and reports from the network element. (See “Time-of-Day Synchronization” on page 4-59.)

DCN Communication PathAs described in “Management Interfaces” on page 3-17, the TN780 and Optical Line Amplifier network elements provide two redundant, auto-negotiating 10/100Mbps Ethernet RJ45 interface, referred to as the DCN ports.

In a redundant configuration the DCN-A port is controlled by the MCM-B in slot 7A of the DTC (referred to as the Primary MCM), or OMM in slot 1A of the OTC (referred to as the Primary OMM). Similarly, DCN-B is controlled by the MCM-B in slot 7B of the DTC (referred to as the Secondary MCM) or OMM in slot 1B of the OTC (referred to as the Secondary OMM).

As shown in Figure 4-14 on page 4-54, ethernet cables from each of the DCN ports must be connected to a single ethernet switch or hub. No other physical connectivity from the DCN port is supported at this time.

In the presence of both Primary and Secondary MCM-B or OMM, only one MCM-B or OMM will be active. The active MCM-B or OMM processes the management traffic received from the DCN. IQ supports only one DCN IP address to be specified. The management traffic is received either through the DCN-A port or DCN-B port. The DCN IP address maps to the MAC address of the Primary or Secondary MCM-B or OMM based on the active DCN port through which the management traffic is received. The DCN IP address is configurable through the CCLI application during network element turn-up.


IQ Management Plane OverviewPage 4-54

Figure 4-14 Redundant DCN Connectivity

DCN Link Failure RecoveryIn the example shown in Figure 4-14 on page 4-54, in the presence of the active MCM-B or OMM and stand-by MCM-B or OMM the active MCM-B or OMM will be processing the management traffic received through the DCN-A port. The DCN IP address is mapped to the MAC address of the active MCM-B or OMM.

When there is a failure in the link between the DCN-A port and the switch/hub, as shown in Figure 4-15 on page 4-55, the active MCM-B or OMM detects failure by monitoring DCA-A port link status. On detecting link failure, the active MCM-B or OMM disables it’s ethernet link to the DCN-A port and enables the ethernet link between itself and the stand-by MCM-B or OMM. Then the active MCM-B or OMM sends gratuitous ARP (i.e. an ARP request for the network element’s DCN IP address) request through the Stand-by MCM-B or OMM in order to refresh the ARP entry in the switch/hub so that the DCN IP address maps to the MAC address of the Stand-by MCM-B or OMM. At this point the active MCM-B or OMM is receiving the management traffic through the DCN-B port.

SD

MAGELLAN

R outer A R ou ter D

R outer B R oute r C

S w itch / H ub

F T P S erver M P o w er E M S

N ode AN ode B N ode C N ode D N ode E

C P U C P U

M C M M C MActive M C M o f

the M a in C hass is

S tand -b y M C M o f the M a in

C hass is

D C N -A D C N -B

D T N M a in C hass is

D C N -A D C N -B

SD

MAGELLAN

R outer A R ou ter D

R outer B R oute r C

S w itch / H ub

F T P S erver M P o w er E M S


C P U C P U



S tand -b y M C M o f the M a in

C hass is

D C N -A D C N -B


D C N -A D C N -B



Figure 4-15 DCN Link Failure Recovery

Note: The link failures between the switch/hub and the DCN routers is not detected by the net-work element nor will any redundant path be provided by the network element. It is assumed that the customer will deploy routers which provide the necessary redundancy to take care of such failures.

MCM-B/OMM Failure RecoveryAs described in “DCN Link Failure Recovery” on page 4-54, assume that the active MCM-B or OMM is receiving the management traffic through the DCN-A port. If the active MCM-B or OMM fails, as shown in Figure 4-16 on page 4-56, the Stand-by MCM-B or OMM becomes active, and sends gratuitous ARP (i.e. an ARP request for the network element’s DCN IP address) in order to refresh the ARP entry in the switch/hub so that the DCN IP address maps to the MAC address it. At this point the now “active” MCM-B or OMM is receiving the management traffic through the DCN-B port and is also processing the packets.

SD

MAGELLAN

R ou ter A R oute r D

R outer B R ou ter C

S w itch / H ub

F T P S erver M P ow er E M S


C P U C P U



S tand-b y M C M of the M a in

C hass is

D C N -A D C N -B


D C N -A D C N -B

L ink F a iled

SD

MAGELLAN

R ou ter A R oute r D

R outer B R ou ter C

S w itch / H ub

F T P S erver M P ow er E M S


C P U C P U



S tand-b y M C M of the M a in

C hass is

D C N -A D C N -B


D C N -A D C N -B

L ink F a iled



Figure 4-16 MCM/OMM Failure Recovery

Management Application ProxyIQ provides GNE capability, similar to the one defined in the GR-253 specification, in order to support in-band access to the network element as opposed to DCN access. In-band access is typically used where either DCN access is not available (e.g., intermediate huts where a Digital Repeater might be installed) or when DCN bandwidth needs to be conserved.

Additionally, IQ has enhanced the GNE capability in order to support a variety of management protocols. The enhanced GNE capability provided by IQ is called Management Application Proxy, often referred to as MAP. Hence, the MAP provides the ability to manage those network elements that are not directly DCN addressable through the network elements that are directly DCN addressable.

The MAP supports the following functions (also see Figure 4-17 on page 4-57):

GNE—the GNE is a network element that is directly IP addressable from the DCN. The GNE pro-vides management proxy services to any network element within the same routing domain as the

SD

MAGELLAN

Router A Router D

Router B Router C

Switch / Hub

FTP Server MPower EMS

Node ANode B Node C Node D Node E

CPU CPU

MCM MCMStand-by MCM

of the Main Chassis

Active MCM of the M ain Chassis

DCN-A DCN-B

DTN Main Chassis

DCN-A DCN-B

MCM Failed

SD

MAGELLAN

Router A Router D

Router B Router C

Switch / Hub

FTP Server MPower EMS

Node ANode B Node C Node D Node E

CPU CPU

MCM MCMStand-by MCM

of the Main Chassis

Active MCM of the M ain Chassis

DCN-A DCN-B

DTN Main Chassis

DCN-A DCN-B

MCM Failed



GNE. The GNE provides management proxy service to any management traffic received via its DCN, OSC or Craft interfaces.

Subtending Network Element (SNE)—this is a network element that does not have physical connec-tivity to the DCN and is not directly IP addressable from the DCN. The SNE is capable of providing management proxy support to any management traffic received through its Craft and OSC inter-faces.

Direct Network Element (DNE)—This is a network element that has physical connectivity to the DCN and is directly IP addressable from the DCN. The difference between a GNE and DNE is that the DNE does not provide any proxy management services. The MAP function is disabled by the user.

Figure 4-17 Management Application Proxy Function

The MAP provides proxy services to the following protocols and enables various accessibility options as described below:

HTTP Protocol—The MAP service on the GNE and SNE network elements relays the HTTP proto-col messages by listening to a dedicated HTTP Proxy port 10080. This capability enables the MPower EMS and MPower GNM applications to access all network elements within the purview of the GNE through the DCN ports. Also, it enables the MPower GNM to access all network elements within the purview of a network element through the Craft Ethernet and Craft Serial interfaces.

XML/TCP Protocol—The MAP service on the GNE and SNE network elements relays the XML/TCP protocol messages by listening to a dedicated XML/TCP Proxy port 15073. This capability enables the MPower EMS and MPower GNM applications to access all network elements within the purview of the GNE through the DCN ports. Also, it enables the MPower GNM to access all network ele-ments within the purview of a network element though the Craft Ethernet and Craft Serial interfaces.

Telnet Protocol—The MAP service on the GNE and SNE relays the Telnet protocol messages by listening to a dedicated Telnet Proxy port 10023. This capability enables the Telnet sessions to be launched from the MPower EMS and MPower GNM applications to access all network elements within the purview of the GNE through the DCN ports. Similarly, it enables the Telnet session to be

DCN

GNEGNE

Physical ConnectivityDCN IP Connectivity

MPower EMS

SNE

DNESNE

DCN

GNEGNE

Physical ConnectivityDCN IP Connectivity

MPower EMS

SNE

DNESNE



launched from the MPower GNM to access all network elements within the purview of a network ele-ment through the Craft Ethernet and Craft Serial interfaces.

FTP Protocol—The MAP service on GNE and SNE relays the FTP protocol messages by listening to a dedicated FTP Proxy port 10021. This capability enables the communication between the FTP cli-ent on the SNE and the EMS or external FTP Server through the GNE. The FTP client will be used to upload performance monitoring data, downloading software, etc.

Configuration SettingsIQ provides several configuration options so that the customers can design their DCN and management communication access to meet their needs. Following are the various configuration options provided:

MAP Enabled—users must set this option to enable MAP services on a network element.

Primary GNE IP Address—the Primary GNE IP Address is configured on SNEs that do not have a DCN IP address assigned. The Primary GNE IP Address is the Router ID (also known as the GMPLS Node ID) of the GNE in the same domain as this SNE. If more than one GNE exists in the same domain, it is recommended that the closest GNE, in terms of hops, from this SNE should be selected as the primary GNE. The primary GNEs main function is to upload the historical Perfor-mance Monitoring data.

Secondary GNE IP Address—as with Primary GNE IP Address parameter, the Secondary GNE IP Address is configured on SNEs. The Secondary GNE IP Address is the Router ID (also known as the GMPLS Node ID) of the GNE within the same domain as this SNE. The SNE accesses the Sec-ondary GNE if the Primary GNE is not available. It is recommended to choose the Secondary GNE as the GNE which:

Is the next closest network element in terms of number of hops from the SNE

Provides a completely separate path to the management station from the SNE. In other words the inability to reach the Primary GNE should never mean that the Secondary GNE is also unreachable and vice-versa.

Static RoutingIQ provides the static routing capability. One application of static routes is to enable the network elements to reach external networks that are not part of the DCN network. As shown in Figure 4-18 on page 4-59, the NTP Server may be located in external networks, outside of the DCN network. In this scenario, users can configure the static routes to external networks.



Figure 4-18 Using Static Routing to Reach External Networks

Time-of-Day SynchronizationIQ provides accurate and synchronized timestamps on events and alarms, ensuring proper ordering of alarms and events at both the network element and network levels. The synchronized timestamp eases the network-level debugging and eliminates the in-accuracies caused by the manual configuration of system time on each network element. Additionally, the timestamp complies with UTC format, found in ISO 8601, and includes granularity down to seconds.

IQ supports the Time-of-Day Synchronization by implementing NTP Client which ensures that IQ’s system time is synchronized with the specified NTP Server operating in the customer network and also synchronized to the Universal Coordinated Time (UTC). IQ also implements NTP Server, so that one network element may act as an NTP Server to the other network elements that do not have access to the external NTP Server. As shown in Figure 4-19 on page 4-60, typically a GNE (GNE-A node) is configured to synchronize to an external NTP Server in the customer network and the SNEs (SNE-A, SNE-B, and SNE-C nodes) are configured to synchronize to the GNE.

R o u te r A

R o u te r D

R o u te r B R o u te r C

S w itc h / H u b

N o d e AN o d e B N o d e C

G N EN o d e D N o d e E

R o u te r A

N T P S e rv e r

S ta t ic R o u te c o n f ig u re d :

D e s t . IP A d d re s s : 3 0 .3 0 .1 .2S u b n e t M a s k : 2 5 5 .2 5 5 .2 5 5 .2 5 5G a te w a y : 1 0 .1 0 .1 .2 5 4C o s t: 1

1 0 .1 0 .1 .2 5 4

2 0 .2 0 .1 .2 5 4

2 0 .2 0 .1 .13 0 .3 0 .1 .2

C u s to m e r N e tw o rk

3 0 .3 0 .1 .1

D C N IP A d d re s s :1 0 .1 0 .1 .1

R o u te r A

R o u te r D

R o u te r B R o u te r C

S w itc h / H u b

N o d e AN o d e B N o d e C

G N EN o d e D N o d e E

R o u te r A

N T P S e rv e r

S ta t ic R o u te c o n f ig u re d :

D e s t . IP A d d re s s : 3 0 .3 0 .1 .2S u b n e t M a s k : 2 5 5 .2 5 5 .2 5 5 .2 5 5G a te w a y : 1 0 .1 0 .1 .2 5 4C o s t: 1

1 0 .1 0 .1 .2 5 4

2 0 .2 0 .1 .2 5 4

2 0 .2 0 .1 .13 0 .3 0 .1 .2

C u s to m e r N e tw o rk

3 0 .3 0 .1 .1

D C N IP A d d re s s :1 0 .1 0 .1 .1



Figure 4-19 NTP Server Configuration

The TN780 and Optical Line Amplifier network elements also provide local clock with the accuracy of 23ppm or about a minute per month. If the GNE (with NTP enabled) fails to access the external NTP Server, IQ NTP (Client and Server) uses the local clock as a time reference. When the connectivity to the external NTP Server is restored, IQ NTP Client and Server on the GNE re-synchronizes with the external NTP Server, and the new synchronized time is propagated to all the network elements within the routing domain.

Following are some recommendations for configuring the NTP Server within a Digital Optical Network:

Configure one external NTP Server with Stratum Level 4 or higher for each routing domain of a Dig-ital Optical Network.

Configure the GNE and SNE network element to point to the external NTP Server. If required config-ure static routes on the GNE and SNE network elements to reach the external NTP Server through the DCN port.

Configure the SNEs to point to the GNE as the NTP Server.

SD

MAGELLAN

DCN

GNE SNESNE

SNE GNE

NTP Server

SNE uses the GNE NTP ServerGNE uses the external NTP Server

SD

MAGELLAN

DCN

GNE SNESNE

SNE GNE

NTP Server

SNE uses the GNE NTP ServerGNE uses the external NTP Server


CHAPTER 5

MPower Management Software

UTStarcom offers MPower Network Management Suite, referred to as MPower, a scalable, robust, carrier class management software suite which simplifies Digital Optical Network operation and OSS integration. As described in “MPower Network Management Overview” on page 1-7, MPower currently includes two management software applications: MPower GNM and MPower EMS.

Figure 5-1 Digital Optical Network and UTStarcom MPower Management Solution


2

This chapter provides a brief description of the supported features in the following sections:

“MPower Graphical Node Manager” on page 5-3

“MPower EMS” on page 5-15

Refer to UTStarcom MPower GNM User Guide, UTStarcom MPower EMS Administrator Guide and UTStarcom MPower EMS User Guide for a detailed description of the graphical user interface and detailed procedures to manage Digital Optical Network.


3MPower Management Software

MPower Graphical Node ManagerThe MPower Graphical Node Manager, referred to as the MPower GNM, provides web-based access to the target network element’s management capabilities. MPower GNM is a Java Web Start enabled application that is downloaded from the network element (TN780 or Optical Line Amplifier) to the client machine using an internet browser.

The MPower GNM includes:

MPower GNM Cache Manager

MPower GNM application

The MPower GNM Cache Manager, referred to as the Cache Manager, is used to download and cache the MPower GNM application based on build version. The cache is created under USER_HOME directory. Under this directory UTStarcom/cache/<buildversion> is created for each MPower GNM version. Each time a MPower GNM is started, it removes any stale cached MPower GNM applications. Stale is defined to be “unused for greater than 3 months”. Note that MPower GNM application is cached one per version, not specific to each network element.

When the MPower GNM is launched through a browser on the client machine, the Cache Manager is first downloaded from the network element to the client machine through the Java Web Start.

The Cache Manager then verifies that the client machine has MPower GNM version matching the version on the network element. If the client machine does not have the MPower GNM image, or if the installed version is older than the network element version, the Cache Manager downloads the MPower GNM software from the network element. The Cache Manager then starts the MPower GNM as a separate application.

Thus, a client machine contains one Cache Manager per network element and one MPower GNM application per build version irrespective of the number of network elements on which it is run.

The MPower GNM can be launched locally through the craft interface or remotely over the DCN or the in-band management channel carried by the OSC. The MPower GNM requires a JRE (Java Runtime Environment) to reside on the local client computer and automatically loads the correct JRE version if the version present on the computer is older than the JRE 1.4.2. However, if JRE does not exist on the client machine, a pointer to Sun Microsystems web site, from where JRE can be loaded, is provided.

The MPower GNM is certified to run on Microsoft Windows and Sun Solaris platforms. For optimal performance, the client platform must meet the following minimum requirements:

Processor speed: 1GHz

Memory: 384MB (Windows platform), 512MB (Solaris platform)

Operating systems: Microsoft Windows 2000, Microsoft Windows XP, Sun Solaris 5.9

Browser requirements: Microsoft Explorer 6.0 and above, Netscape Navigator 6.2 and above, and Mozilla 1.4 and above

JRE 1.4.2


MPower Graphical Node ManagerPage 5-4

The following sections provide highlights of the features supported by the MPower GNM. For a detailed description of how to use MPower GNM to manage the network element, refer to UTStarcom MPower GNM User Guide.

“Graphical User Interface” on page 5-4

“Inventory Manager” on page 5-10

“Network Topology Display” on page 5-11

“Software Configuration Management” on page 5-11

“Service Provisioning” on page 5-13

“Performance Management” on page 5-14

“Security Management” on page 5-14

Graphical User InterfaceThe MPower GNM provides an intuitive, easy-to-use Graphical User Interface (GUI). The Java-based implementation of MPower GNM provides a “native look-and-feel” on Windows and Solaris platforms.



Figure 5-2 MPower GNM Main View

MPower GNM Features in Release 1.2: The graphical user interface includes a graphical representation of the TN780 and Optical Line

Amplifier in the Equipment View window, drill-down tree view of the network element, chassis and circuit packs in Equipment Tree window, a quick view displaying the summary information of the hardware equipment selected in the Equipment Tree or Equipment View in the Quick View Browser, list of current outstanding alarms in the Alarm Manger window, etc.

The support for multi-window display for many of the features and functions. There are two types of windows:

Modal window: Once opened the action must be completed prior to opening another window

Non-modal windows: Allows the user to open other windows for viewing multiple objects. Non-modal windows are:

BMM properties

BMM span

Equipment Tree

Quick View Browser

Status Bar

Workspace Area

Equipment View

Alarm Manager

Main Menu



BMM Optical Carrier Group properties

DLM properties

DLM optical channels

DLM Optical Carrier Group properties

Circuit properties

Cross-connect properties

Figure 5-3 Multi-window display

The topology view of all the network elements that are in the same network neighborhood as the tar-get network element the MPower GNM is logged into.

Support for MCM redundancy. Redundancy state will be displayed on the card (act and stby). New pop-up menu items, Switchover and Make Stand by have been added. The quick view browser will indicate the redundancy of the MCM that is selected.



Figure 5-4 MCM Redundancy Support

Support for TAM-4-1G, allows for provisioning, and pre-provisioning.

Tributary support for 10G clear channel. When the provisioned service type of the tributary port set to 10G Clear Channel, the client termination point will carry transparent traffic and the termination point created on the TN780 is of GIGE type. When a user launches the client termination point prop-erties the dialog that will be launched is the same as 10GBE_LAN. The difference is the configured service type is 10G Clear Channel.

When MCM is selected it’s

redundancy statewill be shown in the quick view Panel

New pop-up items added to the MCM; Switchover and Make Standby

Redundancy state of the MCMs are shown on the card



Figure 5-5 10G Clear Channel Service Type

Protection Group Manager window. Allows for the creation, and deletion of protection groups. The protection manager features a right-click accessible menu options for individual protection groups.



Figure 5-6 Protection Group Manager

Support for 80 channel BMM. When selecting the BMM properties for an 80 channel BMM the BMM OCG Port field will number 1 through 8.

Support for Nodal Control and Timing (NCT) ports used in a multi-chassis configuration.



Figure 5-7 NCT ports on MPower GNM

Support for new TOMs:

TOM-10G-IR2

TOM-2.5G-IR1

TOM-1G-LX

User-friendly context sensitive application launching to perform actions with fewer mouse clicks.

Inventory ManagerThe MPower GNM includes Inventory Manager applications through which users can monitor and also manage various resources in the network element. The following inventory applications are provided:

Equipment Manager—to view and manage the equipment inventory including chassis and circuit packs.

NCT ports

NCT in Equipment Tree



Facility Manager—to view and manage the inventory of termination points including physical ports and logical ports.

Cross-connect Manager—to view and manage manual static cross-connects and signaled cross-connects which are described in “Service Provisioning” on page 4-23.

Circuit Manager—to view and manage dynamically signaled SNCs described in “Dynamically Sig-naled SNC Provisioning” on page 4-26.

Protection Group Manager-to view and manage the protection groups described in “Protection Group Provisioning” on page 4-28

The inventory information is displayed as a table from which users can perform context-sensitive launching of other applications.

Network Topology DisplayThe MPower GNM displays the physical topology of the Digital Network which includes TN780 and Optical Line Amplifier network elements that are in the same routing domain as the network element the MPower GNM is logged into.

Topology is displayed under the Network Neighborhood tree.

Linear, junction site and ring topologies are supported.

Topology is displayed as digital segments where each digital segment consists of two TN780 net-work elements and all Optical Line Amplifiers between the two TN780 network elements.

When the topology nodes are selected the corresponding network element summary information is displayed in the quick view window.

Users can right-click on the nodes in the topology view and launch MPower GNM for those network elements.

Software Configuration ManagementThe MPower GNM includes Software Configuration manager application supporting the following functions:

Upload/download software image. Up to three software versions can be stored on the network ele-ment.

Delete software image.

Compress software image.

Download database.

Configure periodic database backup by uploading to the user configured FTP server.

Compress database.

Fresh install a new software image.



Upgrade to a new software image which will use the currently active database.

Restart the currently running Software Image with a new empty database.

Activate new software image and new database in one click.

Back up the database locally on the network element.

In-service software rollback

Displays if a particular software image upgrade/downgrade is service affecting or non-service affect-ing. In general the software upgrade/downgrade is non-service affecting.

Fault ManagementThe MPower GNM supports Alarm Manager application to manage and view the alarms reported asynchronously by the network element, and Event Manager to monitor the Event Log maintained by the IQ, as described in “Event Log” on page 4-10. The MPower GNM also provides user interfaces and user access to all the fault management functions provided by the IQ as described in “Fault Management” on page 4-2. Additionally, the MPower GNM supports following features:

Alarm manager application to view and manage all outstanding alarms along with alarm details prob-able cause, severity, source, time of occurrence, etc.

Provides the ability to export:

All alarms to file

All events to file

Current view of alarms to file

Current view of events to file

Event log application to view the events logged by the network elements.

Real-time updates to the current alarms and events in the alarm manager and event log, respec-tively.

Context sensitive alarm summary display based on selected managed object entity. For example, users can right-click on the chassis and circuit packs, and select the 'Show Alarms' and 'Show Events' menu options. The Alarm Manager and Event Manager tables are updated to show the alarms or events, respectively, for the selected Equipment.

Color coded alarm display based on the alarm severity.

Several pre-defined display filters so that users can monitor a specific category of alarms.

Ability to acknowledge alarms. Alarms that have been acknowledged will have a check mark in the Ack field of the alarm.

Ability to navigate from an active alarm display in the alarm manager window to the source of the alarm.

Users can export the alarms and events in TSV file format.



Equipment Configuration and ManagementThe MPower GNM provides user interfaces to configure and manage network element equipment which includes chassis, circuit packs and termination points, as described in “Equipment Management and Configuration” on page 4-15. In addition, the MPower GNM supports the following functions:

Enables users to configure and view the physical chassis/rack deployment.

Template based equipment configuration to automate and simplify the equipment configuration pro-cedures.

Graceful handling of the scenarios where multiple users access and configure the same managed object instance. When a user tries to modify a managed object instance which is modified by another user at the same time, the network element warns the user of possible overwriting and it performs the action only if user accepts the overwriting.

Users can export the equipment inventory in TSV file format.

Service ProvisioningThe MPower GNM provides user interfaces to provision and manage services supported by the IQ as described in “Service Provisioning” on page 4-23. It includes Cross-connect Manager to provision and manage manual cross-connects, Circuit Manager to provision and manage Dynamically Signaled SNCs, and the Protection Group Manager to provision and manage protection groups. The following functions are supported to simplify the service provisioning and management procedures:

For the Cross-connect Manager:

The Cross-connect Manager can be launched from the Equipment Manager and the top level menu bar.

The available end points are displayed, allowing users to select end-points in order to create cross-connects.

Users can view PMs for a selected cross-connect.

Users can assign a circuit ID to each cross-connect for end-to-end management. The circuit ID is a logical name given to the cross-connect.

For the Circuit Manager

The Circuit Manager can be launched from the Equipment Manager and the top level menu bar.

The available termination points are displayed, allowing users to select end-points in order to create circuits.

Users can select to use pre-provisioned capacity, feature that allows a circuit to be provisioned with a minimum of pre-provisioned equipment.

User can select to use local DLM route only, feature that when enabled allows route computation to utilize equipped and unequipped DWDM capacity.



Users can view the current route of a circuit.

Users can assign a circuit ID to each cross-connect or SNC for end-to-end circuit management. The circuit ID is a logical name given to the circuit. Users can manage a circuit spanning multiple network domains (Digital Optical Network or any other network) by assigning circuit IDs.

For the Protection Group Manager, the following functions are supported:

The Protection Group Manager can be launched from the Equipment Manager and the top level menu bar.

The available termination points are displayed, allowing users to select end-points in order to create preferred working and standby end points.

Users can assign a name to each protection group. Users can manage a protection group easier by assigning unique names to each protection group.

Protection group validation. An EMS feature that allows the user to validate that the protection units selected for local and remote nodes are available.

Ease of troubleshooting with the ability to:

Launch context sensitive menus, such as alarms, facilities, and cross connects

Filter protection groups.

Note: Users can export the cross-connect, circuit and protection groups inventory in TSV file for-mat.

Performance ManagementThe MPower GNM provides a user interface to support performance management functions supported by IQ as described in “Performance Monitoring and Management” on page 4-31. In addition:

Users can reset PM counters locally and view the delta between the current value and last reset value.

Automatically refresh the PM data at configured intervals.

Users can monitor the PM data from the Circuit Manager.

Both real-time and historical PM data are displayed to the user.

Security ManagementThe MPower GNM provides a user interface to perform user access and security management procedures supported by the IQ as described in “Security and Access Management” on page 4-35.



MPower EMSThe MPower EMS is a robust, real-time management software used to administer and manage Digital Optical Networks. MPower EMS provides end-users in the NOC with an integrated network-level and network-element-level functions including, fault and performance management, circuit provisioning, configuration, topology and inventory management, testing and maintenance functions, and security management. The MPower EMS provides the following functions:

Ability to manage the network independent of physical network deployment.

Automated network topology discovery and drill-down topology displays with integrated real-time alarm status updates (see “Release Compatibility” on page 5-16).

Enhanced network-level OAM&P functions (see “Network-level OAM&P Functions” on page 5-26).

MPower server security and access management based on Telcordia GR-815-CORE standard (see “MPower EMS Security and Access Management” on page 5-31).

Scalable and reliable software architecture (see “MPower EMS Architecture” on page 5-34).

The MPower server is certified to be deployed on a Sun Microsystems Solaris server platform and the MPower client is certified to run on Microsoft Windows and Sun Microsystems Solaris platform (see “MPower EMS Platform Requirements” on page 5-36).

Administrative DomainsThe administrative domain enables a group of network elements to be managed as a single network entity independent of the underlying GMPLS routing domain (see “Network Topology” on page 4-48 for details).

For instance, in Figure 5-8 on page 5-16, at the network-element level, two separate networks are defined (GMPLS Routing Domain 1 and GMPLS Routing Domain 2). At the management level, three administrative domains: EastRoute Domain, NorthRoute Domain and WholeNet Domain are defined. Each administrative domain includes a subset of network elements from the GMPLS Routing Domain 1 and GMPLS Routing Domain 2 networks. Thus, the scope of the administrative domain is separated from the scope of the GMPLS routing domain. For example, one can define the administrative domains along the organizational boundaries, functional boundaries or geographic boundaries. In Figure 5-8 on page 5-16, the administrative domains are defined along the geographic boundaries.

Each user can be assigned to manage one or more administrative domains.

A given network element can be included in one or more administrative domains. For example, in Figure 5-8 on page 5-16, Node 15 is included in EastRoute Domain, NorthRoute Domain and WholeNet Domain.

The MPower EMS provides a user interface to create, modify and delete administrative domains (see “Network Element Information File Editor” on page 5-18).


MPower EMSPage 5-16

Figure 5-8 MPower EMS Administrative Domains

Release CompatibilityMPower EMS manages UTStarcom Digital Optical Networking systems, which include UTStarcom TN780 and UTStarcom Optical Line Amplifier. UTStarcom Digital Optical Networking systems are supported by

Node 16Node 14

Node 27

Node 26

EastRoute Dom ain

Node 16Node 14 Node 16Node 14

Node 27

Node 26

Node 27Node 27

Node 26

EastRoute Dom ain

Node 11 Node 12Node 10 Node 13 Node 14 Node 15

Node 21Node 22

Node 20

Node 25Node 23Node 24

Node 27

Node 26

WholeNetDomain


Node 21Node 22

Node 20


Node 27

Node 26


Node 21Node 22

Node 20Node 20


Node 27

Node 26

Node 27Node 27

Node 26

WholeNetDomain


Node 21Node 22

Node 20


Node 27

Node 26

GMPLS Routing Domain 1



Node 21Node 22

Node 20Node 20


Node 27

Node 26

Node 27Node 27

Node 26



Administrative Domain Views in MPower EMS

Administrative Domain Views in MPower EMS


Node 20 Node 27

NorthRouteDomain


Node 20 Node 27


Node 20Node 20 Node 27Node 27

NorthRouteDomain



the IQ Network Operating System (IQ NOS) software. Table 5-1 on page 5-17 specifies the compatibility between the IQ NOS and MPower EMS version.

Java Web Start manages the compatibility between MPower server and MPower client software versions.

Network Topology Discovery The MPower server automatically discovers the network elements and the topology in order to provide users the network view and the network-level management capabilities. The network topology discovery involves the following functions:

Configure the network element information using a stand-alone GUI application (see “Network Ele-ment Information File Editor” on page 5-18)

Configure the user account and password to be used by the MPower server to log into the network elements (see “Dynamic Seed File Editor” on page 5-21)

The MPower server discovers the network topology as a two-step process as described in the following sections:

Discovers the network elements, GMPLS links and control links (see “Topology Shallow Discovery” on page 5-22)

Discovers all the managed entities within the network element (see “Junction Site Topology” on page 5-23)

The MPower server monitors the changes that occurred in the network and automatically rediscovers the new topology as described in the following section:

“Topology Discovery” on page 5-24

The MPower server provides multiple network topology views and are dynamically updated to display the changes caused by the configuration updates and alarm state as described in the following section:

“Network Topology Views” on page 5-25

Table 5-1 MPower EMS and IQ NOS Version Compatibility

MPower EMS Version Compatible IQ NOS Version

1.1.1 • IQ NOS version 1.1.1

• IQ NOS version 1.1.2


1.2.1 • IQ NOS version 1.1.1





MPower EMSPage 5-18

Network Element Information File EditorThe Network Element Information File Editor is a stand-alone application provided for administrators to configure the DCN IP address and other information of all the network elements to be managed by the MPower server. This application is automatically installed when the MPower server is installed on the customer specified server machine (Solaris workstation). It can be run on the server platform when the MPower server is online and when not actively running by an administrator with SU access to the Solaris workstation.

Using this application, online users can:

Create, and modify administrative domains which are managed by the MPower server.

Create, modify network elements within the administrative domains. The network elements are specified by providing the DCN IP address.

Optionally enable the auto-discovery for the configured network element which enables the auto-matic discovery of all the network elements within that network element’s routing domain.

Using this application, offline users can:

Create, modify and delete administrative domains which are managed by the MPower server.

Create, modify, and delete network elements within the administrative domains. The network elements are specified by providing the DCN IP address.

Optionally enable the auto-discovery for the configured network element which enables the auto-matic discovery of all the network elements within that network element’s routing domain.

Note: If the file is edited offline, then the EMS server must be cold started.



Figure 5-9 Network Information File Editor


MPower EMSPage 5-20

Figure 5-10 Add Administrative Domain Menu

Consider an example network shown in Figure 5-8 on page 5-16. As shown, two networks (GMPLS Routing Domain 1 and GMPLS Routing Domain 2) are deployed and three administrative domains (EastRoute Domain, NorthRoute Domain and WholeNet Domain) are defined in the MPower EMS.

The user must configure the EastRoute domain by specifying the DCN IP address of all the nodes in that domain (Node 14, Node 15, Node 26 and Node 27) since only a partial GMPLS routing domain is included in the administrative domain.

The NorthRoute Domain can be defined by specifying the DCN IP address of Node 10, Node 20 and Node 27. In addition, the auto-discovery option can be enabled on Node 10 so that the remaining nodes in the corresponding GMPLS Routing domain are automatically discovered and included in the administrative domain.

The WholeNet Domain can be defined by specifying the DCN IP address of Node 10 and Node 20 with the auto-discovery option enabled so that all nodes in the corresponding GMPLS Routing domains are automatically discovered and included in the administrative domain.



Dynamic Seed File EditorIn the Tools menu of EMS client, the dynamic Seed File Editor allows the user to:

Addition of NodeInfo

Deletion of NodeInfo

Addition of a ManagementDomain

Deletion of ManagementDomain

Two or more users can simultaneously view the seed file but only one can save the changes made.

Note: Only a user with security administrator privilege can open the seed file editor from the menu item.

Discovery Key RingThe MPower server discovers the network elements and the topology by establishing connectivity to all the network elements within the purview of the administrative domains specified in the configuration database file. For example, for the WestRoute administrative domain shown in Figure 5-8 on page 5-16, the MPower server establishes connectivity to Node 14, Node 15, Node 26 and Node 27.

The MPower server requires that a user-ID and password be configured on the network element in order to establish connectivity. This user account, referred to as the MPower server account, is reserved for the MPower server to communicate with the network element. The user must ensure that at least one MPower server account is configured on each network element and it must meet the following requirements:

Enable all privileges

Disable the password change enforcement

Do not lock the account

Disable inactivity timer

Disable password expiration

Enable MPower server to access this account

Note: A default MPower server specific user account (with user-ID emsadmin and password Infinera1) is created in the network element. However, by default, the account is disabled. The user may enable this pre-defined account or create a new MPower server specific account using the management interfaces, such as MPower GNM or TL1.

The MPower server must be provided with a list of MPower server accounts created on the network elements to which it must establish connectivity. The MPower server provides a user interface so that an EMS User with Security Administrator privilege can configure this list of user-ID and password, referred to as the discovery key ring.


MPower EMSPage 5-22

The MPower server walks through the user-IDs configured in the discovery key ring to establish connectivity with the network elements. If none of the user-IDs (and password) configured in the key ring are accepted by the network element, then the network element is marked as unreachable and the MPower server retries continuously to establish connectivity until it is successful. The user must either fix the key ring configuration or the MPower server account in the network element that is unreachable.

Topology Shallow DiscoveryThe MPower server initiates the topology discovery when it is first launched. The MPower server first discovers the network elements, and the control and the GMPLS links within each administrative domain as specified in the configuration database file. If the auto-discovery option is enabled for any network element in the configuration database file, then the remaining network elements within the same routing domain are automatically discovered. The dynamically discovered network elements are maintained in the persistent database and MPower server establishes and maintains connectivity to all of them. A map view of the discovered network is displayed to the user as shown in Figure 5-11 on page 5-23.



Figure 5-11 Network Topology Map View

Junction Site TopologyRelease1.2 enables MPower EMS the ability to discover and display junction site topology. A junction site can have up to 12 control and the GMPLS links. Figure 5-12 on page 5-24 shows an example of a discovered junction site topology.


MPower EMSPage 5-24

Figure 5-12 Junction Site Topology

Topology Deep DiscoveryThe topology deep discovery refers to the discovery of all the managed entities, which includes chassis, circuit packs, physical ports and logical termination points, within each discovered network element. The network element information is displayed to the user in the equipment view. The MPower GNM and the MPower server provide the same GUI interface to manage the network element.

Topology DiscoveryThe MPower server initiates topology discovery when it detects events and alarms that cause changes to the network topology. Following are some examples of events and alarms that trigger the topology discovery:

Addition or deletion of a control link or GMPLS link

Addition or deletion of network elements



Alarms (raise and clear) reported on the control link or GMPLS link (e.g. alarms reported due to fiber cut)

Loss of connectivity between the MPower server and the network element

During topology re-discovery the MPower server discovers all the network elements specified in the configuration database and also the dynamically discovered network elements stored in the persistent database. If any of the network elements or links are not available, it dynamically updates the nework view displayed to the user along with a color coding providing visual indication of the network problems. When the nework problem is corrected, it performs network re-discovery to discovers the changes in the network and displays the updated network view to the user.

Network Topology ViewsThe MPower server provides several network views so that users can perform various management functions easily. The network views provide the following features:

Hierarchical (see “Hierarchical Network Topology View” on page 5-25) and functional view (see “Functional Network Topology View” on page 5-26) of the managed network.

Ability to launch context sensitive applications and tools such as alarm manager, equipment man-ager, performance management, etc., from various points in the topology view.

Real-time updates to the network topology based on the configuration changes and alarm status in the network, such as addition/deletion of network elements, addition/deletion of control/GMPLS links, change in the alarm severity on a network element and control/GMPLS link, etc.

User customizable background maps in the topology view

Hierarchical Network Topology ViewThe hierarchical view of the network enables users to perform operations and manage the network at different levels. The network hierarchy includes:

Entire network managed by the MPower server

Administrative domains within the network

The network elements within each administrative domain

The chassis within each network element

The circuit packs and other hardware equipment within each chassis

The MPower server provides a context sensitive user interface so that users can launch tools and applications at various levels. For example, when the alarm manager application is launched at the network level, users can view and manage the alarms for all the network elements managed by the MPower server. When the alarm manager application is launched at the circuit pack level, only the alarms reported by that circuit pack are displayed.


MPower EMSPage 5-26

Functional Network Topology ViewThe functional network view provides an intuitive interface to the users to perform OAM&P functions. The following two views are provided:

Physical View—displays the physical topology of the network which includes all network elements (both TN780 and Optical Line Amplifier) and the control links between them. The control link display in the physical view is color coded to indicate the current alarm state of the control link. The alarm state is determined by the alarms active on the OTS and OSC termination points in the network ele-ments associated with the link. In addition to the alarm state, the link color also conveys the reache-ability information which indicates ability of the MPower server to communicate with the network elements and the OSC status between the network elements.

Provisioning View— displays the TN780 network elements and the GMPLS links that participate in service provisioning. Each GMPLS link represents eight unidirectional (four in each direction) 100Gbps traffic engineering links on which services are provisioned. Users can view the various GMPLS link utilization information, such as maximum bandwidth, available bandwidth and used bandwidth. Also, the GMPLS links are color coded to indicate the alarm state. The alarm state is determined by the alarms active on the OTS, OSC and DLM OCG termination points in the network elements associated with the link. Release1.2 also gives the user the added option of saving the pro-visioning map view within MPower EMS.

Network-level OAM&P FunctionsThe MPower server provides OAM&P functions which can be performed at the network-level, in addition to all network element-level functions provided by the MPower GNM as described in “MPower Graphical Node Manager” on page 5-3. The network-level functions include:

Network wide real-time fault management and monitoring, including current alarm summary, histori-cal event logs, and threshold crossing alerts (see “Network Level Fault Management” on page 5-26)

Network wide inventory management, including equipment, facility, circuit layout inventory, and state information (see “Network Level Inventory Management” on page 5-27)

Point-and click end-to-end provisioning and circuit inventory views, with correlated alarm status (see “Network Level Fault Management” on page 5-26)

Web-accessible historical network performance reports (see “Cross-Connect Circuit Trace” on page 5-30

Network Level Fault ManagementThe MPower EMS server supports all the network element-level functions. Following are the additional network-level functions supported:

Ability to monitor network wide alarms and events which have synchronized time stamping using NTP protocol supported by the network elements.



Provides a visual display of the current alarm summary at the entire network-level (refers to the entire UTStarcom network managed by a given MPower server), administrative domain level or net-work element level.

Provides historical (up to 90 days by default) listing of alarms and events which can be optionally exported in TSV file format. Users can configure the event log size before starting the MPower server.

Ability to define custom filters which helps in analyzing the historical data and therefore, quick prob-lem resolution.

Integrated search and sorting.

Provides the ability to export:

All alarms to file

All events to file

Current view of alarms to file

Current view of events to file

Network Level Inventory ManagementMPower EMS provides users various inventory information:

Network-wide inventory reporting of all managed resources, including:

Equipment inventory

Termination point (facility) inventory

Circuit inventory

Cross-connect inventory

TE link inventory where each link refers to 100Gbps logical link within a digital link

Network element inventory

All inventory information can be exported in TSV flat file format.

Context sensitive launching of applications from the inventory window

Detailed physical-layer circuit tracing (display of all supporting TN780 cross-connects)

End-to-end Circuit ProvisioningMPower EMS provides a simple point-click interface to provision an end-to-end circuit between two network elements within the purview of the EMS. MPower EMS also displays a list of all network elements, list of possible destination network elements for a given source network element, list of possible destination endpoints for a given source endpoint.


MPower EMSPage 5-28

Circuit LayoutMPower EMS provides a circuit layout record for every end-to-end circuit. The circuit layout feature allows the user to view every object that comprises a circuit. MPower EMS supports the creation of signalled and manual cross-connect based circuits, allowing the circuit layout record to be launched with a circuit or a cross-connect as the context.

The circuit layout record displays state and alarm conditions of all the objects comprising the circuit drastically improving troubleshooting and fault isolation.

For a given end-to-end circuit the order of object display is from trib-port to trib-port. The following intermediate points will also be displayed:

Trib DTF Path

Cross-Connect

Line DTF Path

DLM Channel

DLM OCG Port

BMM OCG Port

BMM OTS Port (egress)

BMM OTS Port (ingress)

BMM OCG Port

DLM OCG Port

DLM Channel

Line DTF Path

Cross-Connect

Trib DTF Path



Figure 5-13 Circuit Layout Record


MPower EMSPage 5-30

Figure 5-14 Cross-Connect Circuit Trace

Performance ManagementThe MPower server supports all the network element-level functions described in “Performance Management” on page 5-14. Following are the additional network-level functions supported:

Provides historical (up to 90 days by default) archiving of all historical 15min and 24hr PM data for each network element which can be optionally exported in CSV file format.

Provides End-to-end Circuit PM view for viewing intermediate PM across a whole circuit.

Includes a network performance reporting tool for parsing all historical PM data in the database for generating web-based reports, including:

List of all SONET/SDH circuits based on the pre- and post- FEC BER from highest to lowest.

List of all SONET client circuits sorted based on the ES-S (errored seconds section) from highest to lowest. Only the ES encountered within the digital optical network is considered.

List of all SDH client circuits sorted based on RS-ES (regenerator section errored seconds) from highest to lowest. Only the ES encountered within the digital optical network is considered.



List of all SONET client circuits based SEFS-S (severely errored frame seconds section) from highest to lowest. Only the SEFS-S encountered within the digital optical network is considered.

List of all SONET client circuits based RS-LOSS (regenerator section LOSS) from highest to lowest. Only the LOSS encountered within the digital optical network is considered.

Ability to generate customized PM reports for each termination point.

MPower EMS Security and Access ManagementMPower server’s security and access management features comply with Telcordia GR-815-CORE standard. The MPower server security model is integrated with the UTStarcom Digital Optical Networking systems security model. The supported features include:

User identification to indicate the logged in user (see “User Identification” on page 5-31)

User authentication to verify and validate the authenticity of the logged in user (see “Authentication” on page 5-32)

User access control to prevent intrusion (see “Access Control” on page 5-32)

Resource access control by defining multiple access privileges (see “Authorization” on page 5-33)

Security audit logs to monitor unauthorized activities (see “Security Audit Log” on page 5-33)

Security functions and parameters to implement site-specific security policies (see “Security Admin-istration” on page 5-34)

User IdentificationEach MPower user is assigned a unique MPower user ID. The MPower user ID is case-sensitive and contains 6 to 10 alphanumeric characters. The user specifies this ID to log into MPower server.

Note that the MPower user ID is not passed to the target network element (network element managed by the user using MPower EMS). MPower server uses the network element user ID to log into the target network element (see “Dynamic Seed File Editor” on page 5-21) to log into the target network element.

MPower is equipped with a user account that allows for an initial login. The user ID is admin, the password is infinera1, and the account has the security administrator privilege enabled.

This default account differs from the typical user account in that:

It cannot be disabled or deleted

The Security Administrator privilege cannot be removed

Password expiration cannot be set (it is set to 0 by default which means, it never expires)

A user may open multiple active sessions. MPower server maintains a list of all current active users, but not active sessions.


MPower EMSPage 5-32

AuthenticationMPower server supports standards-based authentication features. These features ensure that only the authorized users can log into the MPower server through the MPower client interface.

Each time the MPower user logs in, the user must enter a user ID and password. For the initial login, the user specifies the default password. The user must then change the password based on the following requirements.

The password must contain

Six to ten alphanumeric characters

At least one alphabetic and one numeric or one special character

The password may contain these special characters: ! @ # $ % ^ ( ) _ + | ~ { } [ ] ? -

The password must not contain:

The associated user ID

Blank spaces

The passwords are case-sensitive and must be entered exactly as specified.

The password is stored in the MPower server database in a one-way encrypted form.

Password aging is enabled by default. When the password expires, the user must create a new one. The security administrator can configure the password aging interval -- the length of time the password is valid. Password aging can also be disabled by setting the aging interval to 0.

Access ControlIn addition to user-ID validation and password authentication, MPower server supports access control features to ensure that the session requester is trusted.

The activity of each user session is monitored. If, for a configurable period of time, no data is exchanged between the user (MPower client) and MPower server, the user session is declared inactive.The MPower server defines two system-wide inactivity timeout intervals:

Lockout Interval—When the user session is inactive for this interval, the user is locked out. To reac-tivate the session, the user must re-enter the password.

Idle Interval—When the user session is inactive for this interval, the session is terminated. The user must launch a new session.

User session activity monitoring is disabled by default. A user with security administrator privileges can enable monitoring and also configure the lockout period and the idle period based on the needs of the particular site.



AuthorizationMultiple access privileges are defined to restrict user access to resources. The access privileges defined in MPower server are in synchronization with the access privileges defined in Digital Optical Networking systems. Each MPower EMS access privilege is directly mapped to the access privilege defined at the network element level. In other words, a MPower User with a given access privilege can perform the actions allowed for that privilege on the target network element.

As described in, there are six levels of access privileges. The following description provides the actions allowed for each access privilege within MPower server.

Monitoring Access (MA)—provides read-only access to various MPower EMS logs and inventory screens.

Security Administrator (SA)—allows the user to perform MPower server security management and administration related tasks, to shut down MPower server, and to configure the Discovery Key Ring (see “Dynamic Seed File Editor” on page 5-21).

Network Administrator (NA)—there are no MPower EMS specific tasks defined for this privilege.

Network Engineer (NE)—there are no MPower EMS specific tasks defined for this privilege.

Provisioning (PR)—there are no MPower EMS specific tasks defined for this privilege.

Turn-up and Test (TT)—there are no MPower EMS specific tasks defined for this privilege.

Security Audit LogMPower server maintains an audit log that records all access and security administration related actions performed by the MPower user on MPower server. The audit log provides traceability of all system-impacting changes. Users can view the audit logs through the user interface. The supported features include:

The audit logs include system configuration activities and security related activities. These activities include:

Creating and deleting of MPower user accounts.

Updating the MPower user's security parameters, such as password, user access privileges, password aging time, and administrative domains assigned to the user.

Updating the system-wide security parameters such as inactivity time-out interval.

The audit logs are preserved during a MPower server warm restart. However, the logs are lost on a cold restart.

In addition, all actions performed on the network element are stored in the network element’s audit log. You can view the network element generated audit logs.


MPower EMSPage 5-34

Security AdministrationMPower server defines a set of security administration functions and parameters that are used to implement site-specific policies. Security administration can be performed only by the MPower user with security administration privilege. The supported features include:

View all users currently logged on

Disable and enable a MPower user account

Note: Disabling an MPower user account automatically terminates all active sessions correspond-ing to this account.

Modify user account parameters, including access privilege, password expiry time, and administra-tive domains.

Delete a MPower user account and all its attributes, including its password

Reset any user password to the

MPower server default password

Monitor security audit logs to detect unauthorized access to MPower server

Monitor the security alarms and events raised by MPower server and take appropriate actions

Configure the security administration parameters applicable to all MPower users

Default password

Inactivity time-out intervals

Advisory warning message displayed to the user after successful login to the network element

MPower EMS ArchitectureThe MPower EMS architecture is based on robust, distributed computing technologies that allow the MPower EMS to scale as the network size increases. The MPower EMS is comprised of distinct server applications and client applications (see Figure 5-15 on page 5-35).



Figure 5-15 MPower EMS Architecture

MPower EMS ClientThe MPower EMS client (referred to as MPower client) provides a web-based graphical user interface to remotely manage the Digital Optical Network. The MPower client communicates with the MPower server to provide the services to the user.

The MPower client application is Java Web Start enabled. When a user invokes the MPower client for the first time (on a given user computer), the Java Web Start automatically downloads the MPower client application from the MPower server. The Java Web Start then caches the MPower client application on the user’s computer for future launch through the browser link. The MPower client is automatically downloaded if the version present on the user’s computer is not compatible with the MPower server to which the connection is established.

MPower EMS ServerThe MPower EMS server (referred to as MPower server) communicates with the IQ NOS (Network Operating System) software operating UTStarcom Digital Optical Networking systems and serves the MPower clients to provide users the ability to manage the Digital Optical Network.

The MPower server architecture is highly scalable in terms of the number of network elements and MPower clients supported and also its performance. As shown in Figure 5-15 on page 5-35, the MPower server is comprised of multiple applications which are architected to run on separate hardware platforms.

DCNDCN

XML Mediator

MPower EMS Core Server

MPower PM Server

Oracle Database

Server

MPower UI Frontend Server

MPower Client

MPower Server

Customer DCN

Network

RMI / HTTP / XML

XML FTP

Infinera Digital Optical Network

DCNDCN

XML Mediator


XML Mediator


MPower PM Server

Oracle Database

Server

Oracle Database

Server

MPower UI Frontend Server

MPower Client

MPower Server

Customer DCN

Network

RMI / HTTP / XML

XML FTP

Infinera Digital Optical Network


MPower EMSPage 5-36

MPower Frontend Server—The MPower Frontend server processes the requests from the MPower clients and it interacts with the Oracle database server directly for all the read operations. However, if a user request requires a write operation to the database, it passes the request to the MPower Core server. Thus the database read-only operations are processed separate from the database read/write operations.

MPower Core Server—The MPower Core server manages and processes the information from the network elements and performs all the management tasks. It interacts with the Oracle database server in order to manage the information. The MPower Core server is architected to support multi-ple MPower Frontend servers each running on separate hardware platforms. This allows multiple MPower Frontend servers to be deployed depending on the number of MPower EMS Clients deployed.

MPower PM Server—The MPower PM server collects, processes and manages the performance monitoring data from the network elements. It provides a variety of pre-defined reports to the users so that the network problems can be quickly isolated. User customizable reports are also supported.

Note: In Release 1.2, by default, MPower Frontend server, MPower Core server, and MPower PM server are automatically installed on the same hardware platform. The Oracle database server must also be installed on the same hardware platform as the MPower server. Users must launch the MPower Core server, which also includes MPower Frontend server. Users can optionally launch MPower PM server.

MPower EMS Platform Requirements

MPower Server RequirementsAs shown in Figure 5-15 on page 5-35, MPower server is architected for a distributed environment where MPower Core server, MPower PM server, MPower Frontend server and Oracle database can be deployed on multiple hardware platforms to support large networks. However, in Release 1.2, all these components must be installed on a single server platform. The server platform must have two disk drives, one dedicated to the Oracle database and one for the MPower server.

In Release 1.2, the MPower server is certified to run on Sun Solaris 9 (SunOS 5.9) with Oracle 9i database, on a Sun SPARC-based server enumerated below:

Sun Fire V210

Sun Fire V240

Sun Fire V250

Sun Fire V440

Sun Fire V880

The MPower server performance depends on the hardware platform, and the size of the network and the usage patterns. Typical MPower server installation shall have a Sun Fire V210 server (for small networks),



or a Sun Fire V880 server (for large networks), configured as shown in Table 5-2 on page 5-37. It also shows the maximum number of network elements and MPower clients supported in each configuration for optimal performance.

MPower Client RequirementsThe web-based MPower client is certified to run on Microsoft Windows and Sun Microsystems Solaris platforms. For optimal performance, the client machine must meet the following requirements:

Windows clients:

Processor speed: 1GHz

Memory: 384MB

Hard disk: 250MB

Operating systems: Windows 2000 with Windows Service Pack 2

Browser requirements: Microsoft Explorer 6.0, Netscape Navigator 4.7

Java Runtime Environment 1.4.2

Solaris clients

Processor speed: 650-700 MHz (SunBlade or UltraSparc platform)

Memory: 1.2MB

Hard disk: 250MB

Operating systems: Solaris 9 (SunOS 5.9)

Browser requirements: Netscape Navigator 4.7

Java Runtime Environment 1.4.2

Table 5-2 MPower Server Platform Recommendations

Number of Network Elements

Number of MPower clients

Sun Server Platform Processors RAM in GB

Hard Disk (GB)

<100 <20 Sun Fire V210 2 2 2x36

<100 <20 Sun Fire V240 2 2 2x73

<100 <20 Sun Fire V250 2 2 2x73

<200 <50 Sun Fire V440 2 4 4x36

<500 <50 Sun Fire V440 4 8 4x36

<500 <100 Sun Fire V440 4 16 4x36

<100 <20 Sun Fire V210 2 2 2x36


MPower EMSPage 5-38

MPower Simple Network Management Protocol (SNMP) AgentUTStarcom MPower SNMP Agent provides a V2c standard SNMP protocol. The MPower SNMP Agent provides monitoring capabilities in the multi-vendor network environment enabling integration with 3rd party and tools developed in-house. UTStarcom MPower SNMP Manager Plugin enables the MPower EMS server to forward Network Element/EMS alarms as SNMP Traps to SNMP managers registered with the EMS. UTStarcom MPower SNMP Agent provides a standard mechanism for a network configuration management solution to receive traps for all raise and clear alarms on all monitored Network Elements.

MPower SNMP Trap Agent Features

UTStarcom MPower SNMP Agent consists of the following broad features and capabilities.

Alarm Trap Generation

UTStarcom MPower SNMP supports forwarding of traps from SNMP agent to SNMP Managers. UTStarcom MPower SNMP Agent generates traps for the SNMP mangers that have been registered to it.The Trap Generation is a feature supported in the MPower SNMP Trap Agent.

The following information are sent as a traps.

Perceived Severity

The current severity of the alarm.

Asserted Severity

The severity of the alarm when it was asserted earlier. for e.g. if there is an alarm that is raised as “CR” and if we raise a clear for that, the perceived severity of the current alarm shall be “Clear” and the asserted severity shall be “CR”.

Timestamp

There are two Time attributes.

neTime - The Network element time at which the trap (Alarm) is generated.

emsTime - The EMS time at which the trap is generated.

EMS Notification ID

A unique ID assigned to each alarm in the EMS. It is sent as EMS notification ID as part of a trap attribute.

Event/Trap description

The description of the alarm.



MPower SNMP LicensingA separate license is required for MPower SNMP Agent. To obtain the license, contact UTStarcom technical support (see “Technical Assistance” on page xiv).

Note: Prior to installing MPower SNMP Manager plugin, MPower EMS must be installed on your machine.

The EMS provides a single registration point for non-robust SNMP Trap notifications and support North-bound SNMP v2c trap notification. Only alarms reported by network elements are notified as SNMP traps.

SNMP Manager

A Software which resides on the machine which is managing the devices. It is the console through which an administrator performs management related functions.

SNMP Agent

A Software which resides on the device to be managed. In our case, it resides on the EMS Server. The device can be a bridge, router, Network Element (as in our case), hub etc.

Object

The objects in MIBs are identified by the object identifiers.

MPower SNMP Configurable Features

On successful installation of the SNMP Trap Agent Plug-in, EMS user’s having “Sec admin” privilege should configure MPower SNMP Trap Manager by choosing “Configure SNMP Trap Manager” menu item under “Security” main menu. Using this, EMS user can add a manager by providing:

SNMP Trap manager host information.

SNMP Trap Port - Listening for traps.

A boolean to specify whether he wants the outstanding alarms to be generated as traps or not.

EMS user can delete a manager.

EMS user can modify a manager information.

Configurable ParametersThe parameters below can be configured through InfineraSnmp.conf file which is located under

EMS_INSTALL_DIR/conf/Infinerasnmp directory. All these parameters will get affected only after

restarting (Cold/Warm) the EMS Server.


MPower EMSPage 5-40

EMSName can be set through this. EMSName is default to “MPower”, which get propagated in all the

traps that are generated by the system. If you want to change, you can do so using configurable

parameter.

IsCorrelationIDSupportNeeded

IsEmsTimeWhenReceived

GenerateOutstandingAlarm

Configuring MPower SNMP Trap Managers The Configure MPower SNMP Trap Managers feature allows the user to:

Create SNMP Trap Manager

SNMP Trap Manager function is used to create a new SNMP Trap Manager on UTStarcom EMS Server.

Modify SNMP Trap Manager Attributes

Modify SNMP Trap Manager function is used to modify an existing SNMP Trap Manager.

Delete SNMP Trap Manager

Delete SNMP Trap Manager function is used to delete an existing SNMP Trap Manager

SNMP MIBsMIB rules define the object ID and provide them a valid name. Typically, objects that can be managed by SNMP are defined in MIBs, which are ASCII text files in a structured format.

Standard MIB Files SNMPv2c-SMI,

SNMPv2c-TC

UTStarcom Enterprise MIBs

UTStarcom MPower SNMP Trap Agent supports the following two MIB files.

INFINERA-REG-MIB

INFINERA-TRAP-MIB


Appendix A

TN780 PM Data

UTStarcom TN780 and Optical Line Amplifier network elements collect extensive PM data, including

Optical performance monitoring (PM) data within the optical domain (see “Optical PM Parameters and Thresholds” on page A-2)

Client signal agnostic DTF PM data at every TN780 network element (see “DTF PM Parameters and Thresholds” on page A-10)

FEC PM data enabling BER calculation (see “FEC PM Parameters and Thresholds” on page A-15)

Native client signal PM data at the tributary ports (see “Client Signal PM Parameters and Thresh-olds” on page A-16)

Optical supervisory channel performance monitoring data (see “Client Signal PM Parameters and Thresholds” on page A-16)


Page A-2 Optical PM Parameters and ThresholdsPage A-2

Optical PM Parameters and ThresholdsThe network element collects extensive optical analog PM data at each optical transport layer, including OTS layer, OMS Band (OMSb) layer (referred to as C-band), OMS Optical Carrier Group (OMSo) layer (referred to as OCG) and Optical Channel (OCh) layer. The optical PM data is collected within the optical domain in the TN780 and Optical Line Amplifier network elements.

Within the TN780, OTS, C-band and OCG layer PM data is collected in the BMM (see Figure A-1 on page A-2) and OCh layer PM data is collected in the DLM.

Within the Optical Line Amplifier, OTS and C-band PM data is collected in the OAM.

The optical PM parameters are essentially gauges, snapshot of the current condition. The optical PM parameters, such as Optical Power Received (OPR) and Optical Power Transmitted (OPT), are the measures of the average optical power of the received and transmitted optical signals, respectively, in dBm.

Figure A-1 Optical PM Parameters Collected in the BMM

SC

SC

SC

SC

SC

SC

SCVOA

MUX

DE-MUX DE-

MUX

SC

OSA Monitor IN

OSA Monitor OUT

SC

IN OUTDCM

SC

OSA RX AMP OUT

Rx-EDFA

Tx-EDFA

OSC Tx

OSC Rx

OCG 1

OCG 3

OCG 5

OCG 7

INOUT

INOUT

INOUT

INOUT

Line OUT

L-band

Line IN

INOUT

DE-MUX

Optional

C-Band Total OPR

1.C-Band Rx EDFA LBC12.C-Band Rx EDFA OPT

SC

1.C-Band Total OPT,2.C-Band Tx EDFA LBC

C-Band Normalized OPT

1.C-Band Rx EDFA LBC22.C-Band Measured DCM Loss

1.C-Band Normalized OPR

Total OCG OPR

MUXMUX6

7

6

7

6

7

6

7

Total OCG OPT

OTS OPT

OTS OPR

SC

SC

SC

SC

SC

SC

SCVOA

MUX

DE-MUX DE-

MUX

SC

OSA Monitor IN

OSA Monitor OUT

SC

IN OUTDCM

SC

OSA RX AMP OUT

Rx-EDFA

Tx-EDFA

OSC Tx

OSC Rx

OCG 1

OCG 3

OCG 5

OCG 7

INOUT

INOUT

INOUT

INOUT

OCG 1

OCG 3

OCG 5

OCG 7

INOUT

INOUT

INOUT

INOUT

Line OUT

L-band

Line IN

INOUT

Line OUT

L-band

Line IN

INOUT

DE-MUX

Optional

C-Band Total OPR

1.C-Band Rx EDFA LBC12.C-Band Rx EDFA OPT

SC

1.C-Band Total OPT,2.C-Band Tx EDFA LBC

C-Band Normalized OPT

1.C-Band Rx EDFA LBC22.C-Band Measured DCM Loss

1.C-Band Normalized OPR

Total OCG OPR

MUXMUX6

7

6

7

6

7

6

7

6

7

6

7

6

7

6

7

Total OCG OPT

OTS OPT

OTS OPR

Measured Optical PM Data Points

Derived Optical PM Data Points

Measured Optical PM Data Points

Derived Optical PM Data Points


Page A-3TN780 PM Data

Table A-1 on page A-3 captures the optical PM parameters supported at each layer. The historical data is maintained for some PM parameters. For the rest, only the real-time data is maintained.

Table A-1 Optical PM Parameters Supported by the BMM, OAM and DLM

PM Parameter as displayed in GNM/

EMS

PM Parameter while exporting the file to

FTP server Description Unit

Real-time data

Current &

historical(15-min & 24-hour) data

OTS Layer Parameters (collected in BMM/OAM):

Optical Power Trans-mitted

Average optical output power transmitted onto the Line output. This is the sum of C-Band + L-Band (when L-Band supported) + OSC output power.

dBm Yes No

OPT to OSA Ratio Expected ratio of OTS Optical Power Transmitted and the power measured at the “OSA Monitor Out” port

dB Yes No

Optical Power Received

Average optical power received from the Line input. This is the sum of C-Band + L-Band (when L-Band supported) + OSC received power.

dBm Yes No

OPR to OSA Ratio Expected ratio of OTS Optical Power Received to the power expected at the “OSA Monitor In” port.

dB Yes No

Band Layer Parameters (collected in BMM/OAM)

C-Band Total Optical Power Received

C-Band Total Optical Power Received Min

C-Band Total Optical Power Received Avg

C-Band Total Optical Power Received Max

BandOprMin

BandOprAve

BandOprMax

Total C-Band optical power received from the OTS input.

dBm Yes No



C-Band Normalized Optical Power Received

Normalized per C-Band channel optical power received. Derived from the C-Band Optical Power Received and the number of active channels. Each sample within any given 15 minute is adjusted automatically according to the number of active receive channels.

dBm Yes Yes

C-Band Rx Number of Active Channels

Number of active C-Band receive channels.

int Yes No

C-Band Total Optical Power Transmitted

C-Band Total Optical Power Transmitted Min

C-Band Total Optical Power Transmitted Avg

C-Band Total Optical Power Transmitted Max

BandOptMin

BandOptAve

BandOptMax

Total C-Band optical power transmitted onto the OTS output.

dBm Yes No

C-Band Tx EDFA LBC Measured laser bias current of the EDFA’s optical transmitter towards the OTS output.

mA Yes No

C-Band Normalized Optical Power Trans-mitted

Normalized per C-Band channel optical power transmitted. Derived from the C-Band Optical Power Transmitted and the num-ber of active channels. Each sample within any given 15 minute is adjusted automatically according to the number of active transmit channels.

dBm Yes Yes

C-Band Tx Number of Active Channels

Number of active C-Band trans-mit channels.

int Yes No



EMS



Real-time data

Current &




C-Band Span Loss Measured per C-Band channel span loss between the adjacent nodes (approximate difference between C-Band Optical Power Transmitted and C-Band Optical Power Received between the adjacent network elements).

dB Yes Yes

C-Band Rx EDFA LBC1

(BMM only)

Measured laser bias current of the EDFAs optical transmitter towards the DLM.

mA Yes No

C-Band Rx EDFA LBC2

(BMM with DCM mid-stage access only)

Measured laser bias current of the EDFA’s optical transmitter towards the mid-stage DCM.

mA Yes No

C-Band Rx EDFA LBC1

(OAM only)

Measured laser bias current of the EDFA’s optical transmitter towards the Line output.

mA Yes No

C-Band Rx EDFA LBC2

(OAM with DCM mid-stage access only)

Measured laser bias current of the EDFA’s optical transmitter towards the mid-stage DCM.

mA Yes No

C-Band Rx EDFA Optical Power Trans-mitted

(BMM only)

Average C-Band power transmit-ted toward the DLMs.

dBm Yes No

C-Band Rx Expected OSA Ratio

(BMM only)

Expected ratio of C-Band Rx EDFA Optical Power Transmit-ted to the power measured at the “OSA RX AMP OUT” monitor port.

dB Yes No

C-Band Expected Dis-persion Compensa-tion

(BMM/OAM with DCM mid-stage access only)

Expected dispersion compensa-tion based on DCM model num-ber.

ps/nm

Yes No



EMS



Real-time data

Current &




C-Band Expected DCM Loss


Expected dispersion compensa-tion loss based on DCM model number.

db Yes No

C-Band Measured DCM Loss


Dispersion compensation loss as measured by the EDFA.

db Yes No

OCG Layer Parameters (collected in BMM)

OCG Total Optical Power Transmitted

OCG Total Optical Power Transmitted Min

OCG Total Optical Power Transmitted Avg

OCG Total Optical Power Transmitted Max

BMMOcgOptMin

BMMOcgOptAvg

BMMOcgOptMax

Total OCG optical power leaving the BMM towards its attached DLM. One attribute for each OCG.

dBm Yes Yes

OCG Total Optical Power Received

OCG Total Optical Power Received Min

OCG Total Optical Power Received Avg

OCG Total Optical Power Received Max

BMMOcgOprMin

BMMOcgOprMax

BMMOcgOprAve

Total OCG optical power arriv-ing at the BMM from the local DLM. One attribute for each OCG.

dBm Yes Yes



EMS



Real-time data

Current &




OCG Rx Number of Active Channels

N/A Number of active channels within the OCG in the receive direction from DLM to BMM. One attribute for each OCG.

int Yes No

OCG Rx Number of Active Channels Min

OCG Rx Number of Active Channels Max

OCG Rx Number of Active Channels Avg

N/A Min, max and average number of active channels within the OCG in the receive direction from DLM to BMM. One attribute for each OCG.

int No Yes

OCG Layer Parameters (collected in DLM)

OCG Total Optical Power Transmitted

Total OCG optical power trans-mitted by the DLM to the BMM.

dBm Yes Yes

OCG Total Optical Power Received

Total OCG optical power received by the DLM to the BMM (has reading inaccuracy of +2.5dB/-1.0dB).

dBm Yes Yes

OCh Layer Parameters (collected in DLM)

OCh Optical Power Received

Och Optical Power Received Min

Och Optical Power Received Avg

Och Optical Power Received Max

ChanOchOprMin

ChanOchOprAve

ChanOchOprMax

Average optical channel power received by the DLM. One mea-surement for each optical chan-nel.

dBm Yes Yes



EMS



Real-time data

Current &




OCh Optical Power Transmitted

Och Optical Power Transmitted Min

Och Optical Power Transmitted Avg

Och Optical Power Transmitted Max

ChanOchOptMin

ChanOchOptAve

ChanOchOptMax

Average optical channel power transmitted by the DLM. One measurement for each of the ten optical channels within an OCG. One measurement for each opti-cal channel.

dBm Yes Yes

OCh Laser Bias Cur-rent

Och Laser Bias Cur-rent Min

Och Laser Bias Cur-rent Avg

Och Laser Bias Cur-rent Max

ChanOchLBCMin

ChanOchLBCAve

ChanOchLBCMax

Measured laser bias current of the channel optical transmitter. One measurement for each opti-cal channel.

mA Yes Yes

OCh Measured Wave-length

Measured channel wavelength of the channel. One measure-ment for each optical channel.

Ghz Yes No

Q-Value The current Q-factor of the chan-nel. One measurement for each optical channel.

NA Yes No



EMS



Real-time data

Current &




Thresholding is supported for some of the optical PM parameters. Table A-2 on page A-9 lists those PM parameters, corresponding thresholds and alarms reported when thresholds are exceeded.

Table A-2 Optical PM Thresholds

PM Parameter

PM Parameter as displayed in file

exported to FTP server Ranges Alarms

Band PM Thresholds (BMM and OAM)

C-Band Expected Span Loss (ESL)

C-Band Expected Span Loss Threshold Low

OchSpanLossMin

Provisionable by the user., but recom-mended by UTStarcom based on the customer net-work’s characteris-tics.

Span Loss Out of Range - Low (SL-OORL)

C-Band Expected Span Loss Threshold High

OchSpanLossMax Span Loss Out of Range - High (SL-OORH)


Page A-10 DTF PM Parameters and ThresholdsPage A-10

DTF PM Parameters and ThresholdsUTStarcom TN780 supports extensive digital PM data collection at DTF Section layer and DTF Path layer. The digital PM data is analogous to the SONET/SDH PM data and it is collected in the DLM in the TN780.

Thresholding is supported for all system digital PM data. Since digital PM data is transient in nature, TCAs are reported when PM parameters exceed the provisioned threshold values within a collection period.

Figure A-2 on page A-11 gives a summary of the Digital PM and FEC PM parameters collected by the TN780.



Figure A-2 DTF PM Data Collected in the DLM and TAM

Table A-3 on page A-11 captures the PM parameters and corresponding thresholds defined for the DTF Section and DTF Path layers.

Table A-3 DTF PM Parameters and Thresholds Supported by the DLM

PM Parameter Description

Real-time data

15-min and 24-hr

data

TCA Reportin

g supporte

d?

Default Threshold Values

15-min 24-hour

DTF Section Layer Parameters

DTF CV-S Count of BIP errors detected at the DTF Sec-tion layer (i.e., using the B1 byte in the incoming sig-nal). Up to 8 BIP errors can be detected per frame, with each error incrementing the DTF CV-S current reg-ister.

Yes Yes Yes 1500 15000

FEC / DTF Mapper

FEC / DTF Mapper

Tx PIC

Cross point

VOA

O

(lisid

Facility clock ref

System clock ref

OUT

INRx PIC

DLM

DLM

Midplan

eCon

nector

PM Data collected by the Mapper:DTF CV-SDTF ES-SDTF SES-S

DTF CV-PDTF ES-PDTF SES-PDTF UAS-P

FEC Uncorrected BERFEC Corrected BERFEC Corrected BitsFEC Uncorrectable CodewordsFEC Total Codewords

DTF Section Level

DTF Path Level

FEC PM Data

NUT

NUT

DTF Mapper

TAM-2-10GClient Clock Gen

SerDes TOM

SerDes TOM

Client Clock Gen

System Clock ref

PM Data collected by the DTF Mapper:


FEC / DTF Mapper

FEC / DTF Mapper

FEC / DTF Mapper

FEC / DTF Mapper

Tx PIC

Cross point

VOA

O

(lisid

Facility clock ref

System clock ref

OUT

INRx PIC

DLM

DLM

Midplan

eCon

nector

PM Data collected by the Mapper:DTF CV-SDTF ES-SDTF SES-S


FEC Uncorrected BERFEC Corrected BERFEC Corrected BitsFEC Uncorrectable CodewordsFEC Total Codewords

DTF Section Level

DTF Path Level

FEC PM Data

NUT

NUT

DTF Mapper

TAM-2-10GClient Clock Gen

SerDes TOM

SerDes TOM

Client Clock Gen

System Clock ref

PM Data collected by the DTF Mapper:




DTF ES-S Count of the number of seconds during which (at any point during the sec-ond) at least one DTF Sec-tion layer BIP error was detected or an LOF or LOL defect was present.


DTF SES-S Count of the seconds dur-ing which K (=10000) or more DTF Section layer BIP errors were detected or an LOF or LOL defect was present.

Yes Yes Yes 3 7

Near-end DTF Path Layer Parameters Collected in DLMa

DTF CV-P Count of BIP errors detected at the DTF Path layer. Up to 8 path BIP errors can be detected per frame, with each error incrementing the DTF-DLM-CV-S current register.


DTF ES-P Count of the number of seconds during which (at any point during the sec-ond) at least one DTF Path layer BIP error was detected or an AIS-P, TIM-P, OCI-P, or BDI-P defect was present.


DTF SES-P Count of the seconds dur-ing which K (= 2,400 as specified in GR-253-CORE Issue 3 specification) or more DTF Path layer BIP errors were detected or an AIS-P, TIM-P, OCI-P, or BDI-P defect was present.

Yes Yes Yes 3 7



Real-time data

15-min and 24-hr

data

TCA Reportin

g supporte

d?


15-min 24-hour



DTF UAS-P Count of the seconds dur-ing which the DTF Path considered unavailable. A DTF Path becomes unavailable at the onset of 10 consecutive seconds that qualify as DTF-DLM-SES-P, and continues to be unavailable until the onset of 10 consecutive seconds that do not qualify as DTF-DLM-SES-P.

Yes Yes No NA NA

Near-end DTF Path Layer Parameters Collected in TAMDTF CV-P Count of BIP errors

detected at the DTF Path layer. Up to 8 path BIP errors can be detected per frame, with each error incrementing the DTF-DLM-CV-S current register.


DTF ES-P Count of the number of seconds during which (at any point during the sec-ond) at least one DTF Path layer BIP error was detected or an AIS-P, TIM-P, OCI-P, or BDI-P defect was present.




Real-time data

15-min and 24-hr

data

TCA Reportin

g supporte

d?


15-min 24-hour



DTF SES-P Count of the seconds dur-ing which K (= 2,400 as specified in GR-253-CORE Issue 3 specification) or more DTF Path layer BIP errors were detected or an AIS-P, TIM-P, OCI-P, or BDI-P defect was present.

Yes Yes Yes 3 7

DTF UAS-P Count of the seconds dur-ing which the DTF Path is considered unavailable. A DTF Path becomes unavailable at the onset of 10 consecutive seconds that qualify as DTF SES-P, and continues to be unavailable until the onset of 10 consecutive seconds that do not qualify as DTF SES-P.

Yes Yes No NA NA

a. Note that the DTF Path path PM data is available only when a circuit is provisioned. The DTF Path PM data collected in TAM is nearly identical to the ones collected in DLM. The difference is due to errors introduced on the backplane between the FEC chips in the DLM and BMM.



Real-time data

15-min and 24-hr

data

TCA Reportin

g supporte

d?


15-min 24-hour



FEC PM Parameters and ThresholdsThe TN780 network element performs FEC (Forward Error Correction) encoding/decoding function for every optical channel on the Line side. The TN780 network element supports FEC PM data collection to compute the effective BER on the channel along each digital link. The following table captures the FEC PM data collected for every channel in the DLM.

The thresholding is supported only for the pre-FEC BER. If the BER before error correction is equal to greater than the user configured value over an interval associated with the configured value, a ‘Pre-FEC BER-based Signal Degrade’ alarm is reported. The alarm is cleared when the pre-FEC BER is below the threshold.

Table A-4 FEC PM Parameters and Thresholds Supported by the DLM

FEC PM Parameter

FEC PM Parameter as displayed in the file

exported to FTP server Description

Real-time data

15-min and 24-hr data

Threshold Supported

FEC UnCorrected BER

FecUncorrectedRows Uncorrected bit error rate prior to FEC cor-rection.

Yes

(integrated over one second)

Yes Yes

Default Value = 10e-9

FEC Corrected BER Corrected bit error rate

Yes

(integrated over one second)

Yes No

FEC Corrected Bits FecCorrectedBits Corrected number of zeros and ones

Yes Yes No

FEC UnCorrectable Codewords

Uncorrected number of codewords

Yes Yes No

Total CodeWords FecTotalCodeWords Total number of codewords

Yes No No


Page A-16 Client Signal PM Parameters and ThresholdsPage A-16

Client Signal PM Parameters and ThresholdsThe TN780 network element supports SONET OC-192, SDH STM-64, 10GbE LAN Phy, 10GbE WAN Phy, SONET OC-48 and SDH STM-16 interfaces.

The TN780 network element supports PM data collection for the SONET OC-192/OC-48 and SDH STM-64/STM-16 trib/client interfaces as listed in Table A-5 on page A-17. The PM data collection for the 10GbE LAN Phy and 10GbE WAN Phy interfaces are not supported.

The PM data is collected for the client signals received at the ingress port (referred to as the Rx PM parameters) and also the client signals transmitted at the egress port (referred to as the Tx PM parameters). Rx and Tx PM data can be used to determine the number of errors occurred in the various segments of the network:

Between the client equipment and the ingress port

Within the Digital Optical Network

Between the egress port and the client equipment

Figure A-3 on page A-17 gives a summary of the SONET and SDH client signal PM data collected by the TN780 network element.



Figure A-3 Client Signal (SONET and SDH) PM Parameters

Table A-5 Client Signal PM Parameters Supported by the TAM

PM Parameter

PM Parameter as displayed in file to

export to FTP server Description

Real-time data


Default Threshold

Values15-min 24-hour

SONET Section Rx Parameters Collected in the TAM for SONET OC-192/OC-48 Trib Interfaces

Rx CV-S RxCV Count of BIP errors detected at the Section layer incoming in the incoming client’s SONET signal). Up to eight Section BIP errors can be detected per STS-N frame, with each error incre-menting the Sonet-Rx-CV-S cur-rent second register.

Yes Yes 1500 15000

I NO U T

I NO U T

R x C V - SR x E S - SR x S E S - SR x S E F S - S

S O N E T C l i e n t S i g n a l P M D a t a :

T x C V - ST x E S - ST x S E S - ST x S E F S - S

R x R S - B ER x R S - E SR x R S - S E SR x R S - O F SR X R S - L O S S

S D H C l i e n t S i g n a l P M D a t a :

T x R S - B ET x R S - E ST x R S - S E ST x R S - O F ST X R S - L O S S

D T F M a p p e r

T A M - 2 - 1 0 GC l i e n t C l o c k G e n

S e r D e s T O M

S e r D e s T O M

C l i e n t C l o c k G e n

S y s t e m C l o c k r e f

DLM

Mid

plan

eC

onne

ctor

I NO U T

I NO U T







D T F M a p p e r


S e r D e s T O M

S e r D e s T O M















D T F M a p p e r


S e r D e s T O M

S e r D e s T O M



DLM

Mid

plan

eC

onne

ctor


Page A-18 Client Signal PM Parameters and ThresholdsPage A-18

Rx ES-S RxES Count of the number of seconds during which (at any point during the second) at least one Section layer BIP error was detected or an LOS or SEF defect was present.

Yes Yes 120 1200

Rx SES-S RxSE Count of the seconds during which K (=10000) or more Sec-tion layer BIP errors were detected or an LOS or SEF defect was present.

Yes Yes 3 7

Rx SEFS-S

RxSEFS Count of the seconds during which (at any point during the second) an SEF defect was present.

Yes Yes 3 7

SONET Section Tx Parameters Collected in the TAM for SONET OC-192/OC-48 Trib Interfaces

Tx CV-S TxCV Count of BIP errors detected at the Section layer in the SONET signal received from the line/sys-tem side and to be transmitted to the receiving client. Up to eight Section BIP errors can be detected per STS-N frame, with each error incrementing the Sonet-Rx-CV-S current second register.

Yes Yes 1500 15000

Tx ES-S TxES Count of the number of seconds during which (at any point during the second) at least one SONET Tx BIP error was detected or an LOS or SEF defect was present.

Yes Yes 120 1200

Tx SES-S TxSES Count of the seconds during which K (=10000) or more SONET TX BIP errors were detected or an LOS or SEF defect was present.

Yes Yes 3 7

Tx SEFS-S

TxSEFS Count of the seconds during which (at any point during the second) an SEF defect was present.

Yes Yes 3 7


PM Parameter



Real-time data


Default Threshold




SDH Regenerator Section Rx Parameters Collected in the TAM for SDH STM-64/STM-16Trib Interfaces

Rx RS-BE RxBE Count of the number of errors within a block in the incoming cli-ent’s SDH signal.

Yes Yes 1500 15000

Rx RS-ES RxES Count of the number of seconds during which (at any point during the second) at least one RS block error was detected or an LOS or SEF defect was present.

Yes Yes 120 1200

Rx RS-SES

RxSES Count of the seconds during which30% or more RS block errors were detected or an LOS or SEF defect was present.

Yes Yes 3 7

Rx RS-OFS

RxOFS Yes Yes 3 7

Rx RS-LOSS

RxLOSS Yes Yes 3 7

SDH Regenerator Section Tx Parameters Collected in the TAM for SDH STM-64/STM-16 Trib Interfaces

Tx RS-BE TxBE Count of the number of errors within a block in the SDH signal received from the network and to be transmitted to the receiving client.

Yes Yes 1500 15000

Tx RS-ES TxES Count of the number of seconds during which (at any point during the second) at least one Tx RS block error was detected or an LOS or SEF defect was present.

Yes Yes 120 1200

Tx RS-SES

TxSES Count of the seconds during which30% or more Tx RS block errors were detected or an LOS or SEF defect was present.

Yes Yes 3 7

Tx RS-OFS

TxOFS Yes Yes 3 7

Tx RS-LOSS

Yes Yes 3 7


PM Parameter



Real-time data


Default Threshold



Page A-20 OSC PM ParametersPage A-20

OSC PM ParametersUTStarcom TN780 and Optical Line Amplifier network elements support OSC, a dedicated 1510nm optical channel, to carry traffic and management traffic between adjacent network elements. The OSC is terminated on the BMM on the TN780 and OAM on Optical Line Amplifier.

Table A-6 OSC PM Parameters Supported by the BMM and OAM

PM ParameterPM Parameter as displayed in file

exported to FTP server Description Unit

Real-time data

Current &

historical

(15-min & 24-

hr) data

OSC optical PM parameters

Laser Bias Current

Laser Bias Current Min

Laser Bias Current Avg

Laser Bias Current Max

OscLBCMin

OscLBCAve

OscLBCMax

Measured laser bias cur-rent of the OSC optical transmitter.

mA Yes Yes

Optical Power Transmitted

Optical Power Transmitted Min

Optical Power Transmitted Avg

Optical Power Transmitted Max

OscOPRMin

OscOPRAve

OscOPRMax

Average optical output power transmitted by the OSC optical transmitter.

dBm Yes No

Optical Power Received

Optical Power Received Min

Optical Power Received Avg

Optical Power Received Max

OscOprMin

OscOprAve

OcsOprMax

Average optical power received by the OSC optical receiver from the Line input.

dBm Yes Yes



OSC Ethernet packet PM data

Transmitted Bytes The number of bytes trans-mitted by this network ele-ment on the OSC channel.

Bytes Yes No

Transmitted Pack-ets

The number of Ethernet packets transmitted by this network element on the OSC channel.

Pack-ets

Yes No

Packets Dropped at Transmitter

The number of transmit Ethernet packets dropped by this network element.

Pack-ets

Yes No

Received Bytes The number of bytes received by this network element on the OSC chan-nel.

Bytes Yes No

Received Packets The number of Ethernet packets received by this network element on the OSC channel.

Pack-ets

Yes No

Packets Dropped at Receiver

The number of received Ethernet packets dropped by this network element.

Pack-ets

Yes No

Table A-6 OSC PM Parameters Supported by the BMM and OAM

PM ParameterPM Parameter as displayed in file

exported to FTP server Description Unit

Real-time data

Current &

historical

(15-min & 24-

hr) data


Page A-22 OSC PM ParametersPage A-22


Appendix B

Optical Channel Plan

This chapter describes the TN780 optical channel plan:

“TN780 Optical Channel Plan” on page B-2


Page B-2 TN780 Optical Channel PlanPage B-2

TN780 Optical Channel PlanTable B-1 on page B-2 lists the 40-channel C-band channel plan supported by the TN780.

Table B-1 TN780 Optical Channel Plan

OCG Number Channel Number Center Wavelength(nm)

Center Frequency(THz)

1 1 1563.455 191.75

1 2 1561.826 191.95

1 3 1560.200 192.15

1 4 1558.578 192.35

1 5 1556.959 192.55

1 6 1555.343 192.75

1 7 1553.731 192.95

1 8 1552.122 193.15

1 9 1550.517 193.35

1 10 1548.915 193.55

2 1 1563.047 191.80

2 2 1561.419 192.00

2 3 1559.794 192.20

2 4 1558.173 192.40

2 5 1556.555 192.60

2 6 1554.940 192.80

2 7 1553.329 193.00

2 8 1551.721 193.20

2 9 1550.116 193.40

2 10 1548.515 193.60

3 1 1562.640 191.85

3 2 1561.013 192.05

3 3 1559.389 192.25

3 4 1557.768 192.45

3 5 1556.151 192.65

3 6 1554.537 192.85

3 7 1552.926 193.05

3 8 1551.319 193.25

3 9 1549.715 193.45

3 10 1548.115 193.65


Page B-3Optical Channel Plan

4 1 1562.233 191.90

4 2 1560.606 192.10

4 3 1558.983 192.30

4 4 1557.363 192.50

4 5 1555.747 192.70

4 6 1554.134 192.90

4 7 1552.524 193.10

4 8 1550.918 193.30

4 9 1549.315 193.50

4 10 1547.715 193.70

5 1 1545.720 193.95

5 2 1544.128 194.15

5 3 1542.539 194.35

5 4 1540.953 194.55

5 5 1539.371 194.75

5 6 1537.792 194.95

5 7 1536.216 195.15

5 8 1534.643 195.35

5 9 1533.073 195.55

5 10 1531.507 195.75

6 1 1545.322 194.00

6 2 1543.730 194.20

6 3 1542.142 194.40

6 4 1540.557 194.60

6 5 1538.976 194.80

6 6 1537.397 195.00

6 7 1535.822 195.20

6 8 1534.250 195.40

6 9 1532.681 195.60

6 10 1531.116 195.80

7 1 1544.924 194.05

7 2 1543.333 194.25

7 3 1541.746 194.45

7 4 1540.162 194.65

7 5 1538.581 194.85





Page B-4 TN780 Optical Channel PlanPage B-4

7 6 1537.003 195.05

7 7 1535.429 195.25

7 8 1533.858 195.45

7 9 1532.290 195.65

7 10 1530.725 195.85

8 1 1544.526 194.10

8 2 1542.936 194.30

8 3 1541.349 194.50

8 4 1539.766 194.70

8 5 1538.186 194.90

8 6 1536.609 195.10

8 7 1535.036 195.30

8 8 1533.465 195.50

8 9 1531.898 195.70

8 10 1530.334 195.90





Appendix C

Acronyms

Table C-1 List of Acronyms

Abbreviation Description

AACLI application command line interface

ACO alarm cutoff

ACT active

AD add/drop

ADM add/drop multiplexer

ADPCM adaptive differential pulse code modulation

AGC automatic gain control

AID access identifier

AINS administrative inservice

AIS alarm indication signal

ALS automatic laser shutdown

AMP amplifier

ANSI American National Standards Institute

AO autonomous output

APD avalanche photo diode

API application programming interface

APS automatic protection switching

ARC alarm reporting control

ARP address resolution protocol


Page C-2 AcronymsPage C-2

ASAP alarm severity assignment profile

ASE amplified spontaneous emission

ASIC application-specific integrated circuit

ATM asynchronous transfer mode

AU administrative unit

AUX auxiliary port

AWG array waveguide gating

AWG american wire gauge

BBDFB battery distribution fuse bay

BDI backward defect indication

BDI backward defect indication

BEI backward error indication

BER bit error rate

BERT bit error rate testing

BGA ball grid array

BIP-8 bit interleaved parity

BITS building-integrated timing supply

BLSR bi-directional line switched ring

BMM-C Band Mux Module - C band

BNC Bayonet Niell-Concelman; British Naval Connector

BOL beginning of life

BOM bill of material

BOOTP bootstrap protocol

bps bits per second

BPV bipolar violations

CC Celsius

CCITT Consultative Committee on International Telegraph and Telephone

CCLI commissioning command line interface

CDE chromatic dispersion equalizer

CDR clock and data recovery

CDRH Center for Devices and Radiological Health




Page C-3Acronyms

CFR code for federal regulations

CH/Ch/ch channel

CID circuit identifier

CIT craft interface terminal

CLEI common language equipment identifier

CLI command line interface

CO central office

CODEC coder and decoder

COM communication

CORBA common object request broker architecture

CPC common processor complex

CPE customer premises equipment

CPLD complex programmable logic device

CPU central processing unit

CRC cyclic redundancy check

CSPF constraint-based shortest path first algorithm

CSV comma separated value

CTAG correlation tag

CTP client termination point

CTS clear to send

CV coding violation

CV-L coding violation-line

CV-P coding violation-path

CV-S coding violation-section

DDA digital amplifier

dB decibel

DB database

DCC data communications channel

DCE data communications equipment

DCF dispersion compensation fiber

DCM dispersion compensation module

DCN data communication network

DEMUX de-multiplexing





DFB distributed feedback

DFE decision feedback equalizer

DGE dynamic gain equalization

DHCP dynamic host configuration protocol

DLM digital line module

DMC dispersion management chassis

DR digital repeater

DSF dispersion shifted fiber

DT digital terminal

DTC digital transport chassis

DTE data terminal equipment

DTF digital transport frame

DTL digital transport line

DTMF dual tone multi frequency

DTP digital transport path

DTS digital transport section

DWDM dense wavelength division multiplexing

EEDFA erbium doped fiber amplifier

EEPROM electrically-erasable programmable read only memory

EMC electromagnetic compatibility

EMI electro-magnetic interference

EMS element management system

EOL end-of-life

ESD electrostatic discharge; electrostatic-sensitive device

ES-L line-errored seconds

ES-P path-errored seconds

ES-S section-errored seconds

ETS IEEE european test symposium

ETSI European Telecommunications Standards Institute

FF fahrenheit

FA frame alignment




Page C-5Acronyms

FAS frame alignment signal

FC fiber channel; failure count

FCAPS fault management, configuration management, accounting, performance monitor-ing, and security administration

FCC Federal Communications Commission (USA)

FDA Food and Drug Administration

FDI forward defect indication

FEC forward error correction

FIFO first-in-first-out

FIT failure in time

FLT fault

FPGA field programmable gate array

FRU field replaceable unit

FTP file transfer protocol

GGbE gigabit ethernet

Gbps gigabits per second

GCC general communication channel

GFP general framing protocol

GHz gigahertz

GMPLS generalized multi protocol label switching

GNE gateway network element

GNM graphical node manager

GUI graphical user interface

H/IHTML hypertext markup language

HTTP hypertext transfer protocol

IAP input, output and alarm panel

ID identification

IDF invalid data flag

IEC International Electrical Commission

I/O Input/Output

IOP input output panel

IP Internet protocol





IQ see IQ NOS

IQ NOS UTStarcom IQ network operating system

IR intermediate reach

IS in-service

ITU-T International Telecommunications Union - Telecommunications

J/K/LJDK Java Development Kit

JRE Java Runtime Environment

LAN local area network

LBC laser bias current

LC fiber optic cable connector type

LCK locked

LED light-emitting diode

Linear ADM linear add/drop multiplexer

LOF loss of frame

LOL loss of light

LOP loss of pointer

LOS loss of signal

LR long reach

LSB least significant bit

LTE line-terminating equipment

LVDS low voltage differential signaling

MMA monitoring access

MAC media access control

MB megabyte

Mb/s megabits per second

MIB management information base

MCM management and control module

MEMS micro electro mechanical systems

MFAS multi frame alignment signal

MIB management information base

MMF multimode fiber




Page C-7Acronyms

MS multiplex section

MSA multi source agreement

MSB most significant bit

MSOH multiplex section overhead

MTBF mean time between failure

MTU maximum transmission unit

MX multiplex, multiplexer, multiplexing

NNA network administrator

NAND flash type

NC normally closed; node controller

NCC node controller chassis

NCT nodal control and timing

NDSF non zero dispersion shifted fiber

NE network engineer

NEBS network equipment building system

NECG net electrical coding gain

NEPA national fire protection association

NJO negative justification opportunity

nm nanometer

NML network management layer

NMS network management system

NNI network-to-network interface

NO normally open

NSA non-service affecting

NTP network time protocol

NVRAM nonvolatile random access memory

OOAM optical amplification module

OAM&P operation, administration, maintenance and provisioning

OC-12 optical carrier signal at 622.08 mb/s

OC-192 optical carrier signal at 9.95328 gb/s

OC-3 optical carrier signal at 155.52 mb/s





OC-48 optical carrier signal at 2.48832 gb/s

OCG optical carrier group

Och Optical channel

OCI open connection indication

ODU optical channel data unit

OEO optical-electrical-optical conversion

OFC open fiber control

OH overhead

OIF optical internetworking forum

OLA optical line amplifier

OMM optical management module

OMS optical multiplex section

OOS out-of-service

OOS-MT out-of-service maintenance

OPR optical power received

OPT optical power transmitted

OPU optical channel payload unit

ORL optical return loss

OS operating system

OSA optical spectrum analyzer

OSC optical supervisory channel

OSNR optical signal-to-noise ratio

OSPF open shortest path first

OSS operations support system

OTC optical transport chassis

OTDR optical time domain reflectometer

OTN optical transport network

OTS optical transport section

OTU optical channel transport unit

OW orderwire

OWM orderwire module

P/QPC personal computer

PCPM per channel power monitoring




Page C-9Acronyms

PDU protocol data unit; power distribution unit

PEM power entry module

PF partial failure

PG protection group

PHY physical

PIC photonic integrated circuit

PID protocol identifier

PIN positive-intrinsic negative

PJO positive justification opportunity

PLD programmable logic device

PLL phase locked loop

PM performance monitoring

PMD polarization mode dispersion

POH path overhead

POP point-of-presence

PPM part per million

PPP point-to-point protocol

PR provisioning

PRBS pseudo random binary sequence

ps pico second (unit of measure for dispersion)

PSC protection switch completion; protection switch count

PSD protection switch duration

PSTN public switched telephone network

PT parallel telemetry

PTP physical termination point; point-to-point

PWR power

QOS quality of service

RRAM random access memory

RDI remote defect indication

REI-L remote error indication-line

REI-P remote error indication-path

RFI remote failure indication

ROM read-only memory





RS regenerator section; reed solomon

RSOH regenerator section overhead

RTC real time clock

RTN return lead

RTS ready to send

RU rack unit

Rx receiver; receive

Rx Q receiver quality

SSA service affecting; security administrator

SAPI source access point identifier

SC square shaped fiber optic cable connector

SD signal degrade

SDH synchronous digital hierarchy

SDRAM synchronized dynamic random access memory

SEF severely errored frame

SEFS severely errored frame second

SELV safety extra low voltage

SERDES serializer and deserializer

SES severely errored seconds

SF signal fail

SFP small form factor plug

SID source identifier; system identifier

SMF single-mode fiber

SML service management layer

SNC sub network connection

SNE subtending network element

SNMP simple network management protocol

SNR signal-to-noise ratio

SOH section overhead

SOL start of life

SONET synchronous optical network

SPE synchronous payload envelope

SQ signal quality




Page C-11Acronyms

SR short reach

SSL secure sockets layer

STE section terminating equipment

STM synchronous transfer mode

STM-1 SDH signal at 155.52 Mb/s

STM-16 SDH signal at 2.48832 Gb/s

STM-4 SDH signal at 622.08 Mb/s

STM-64 SDH signal at 10 Gb/s

STM-n synchronous transport module of level n (for example, STM-64, STM-16)

STS synchronous transport signal

STS-n synchronous transport signal of level n (for example, STS-12, STS-48)

SW software

T/U/VTAM tributary adapter module

TAP timing and alarm panel

TCA Threshold Crossing Alert

TCP transmission control protocol

TE traffic engineering

TEC thermo-electric cooler

TERM terminal

TFTP trivial file transfer protocol

TID target identifier

TIM trace identifier mismatch

TL1 transaction language 1

TMN telecommunications management network

TOM tributary optical module

TP termination point

TR transceiver

TT test and turn-up

TTI trail trace identifier

Tx Transmitter; Transmit

UA unavailable seconds

UART universal asynchronous receiver transmitter

UAS unavailable seconds





UAS-L unavailable seconds, near-end line

UAS-P unavailable seconds, near-end STS path

UDP user datagram protocol

UPSR unidirectional path switched ring

URL universal resource locator

UTC Coordinated Universal Time

V volt

VGA variable gain amplifier

VLAN virtual local area network

VOA variable optical attenuator

VPN virtual private network

VSR very short reach

W/X/Y/ZWAN wide area network

WDM wavelength division multiplexing

XC cross-connect

XFP name of a small form factor 10 Gbps optical transceiver

XML extensible markup language

MISC1R re-amplification

2R re-amplification, re-shape

3R re-amplification, re-shape, re-time

4R re-amplification, re-shape, re-time, re-code


