hi g maintenance

7/22/2019 HI G maintenance

http://slidepdf.com/reader/full/hi-g-maintenance 1/174

Operation

SURPASS

UMN:SURPASS hiG 1600 V2 / DLU-IP

A30828-X1187-U125-3-7619



2 A30828-X1187-U125-3-7619

UMN:SURPASS hiG 1600 V2 / DLU-IP OperationSURPASS

f Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment. Some of theparts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in prop-erty damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to complywith the applicable safety standards.

The same text in German:Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Spannung. Einige Teilekönnen auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverletzungen undSachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertesPersonal die Anlagen installiert undwartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Gerätemüssen die zutreffenden Sicherheitsbestimmungen erfüllen.

Trademarks:

All designations used in this document can be trademarks, the use of which by third parties for theirown purposes could violate the rights of their owners.

Copyright (C) Siemens AG 2004-2005.

Issued by the Communications Group

Hofmannstraße 51

D-81359 München

Technical modifications possible.

Technical specifications and features are binding only insofar as

they are specifically and expressly agreed upon in a written contract.



A30828-X1187-U125-3-7619 3

OperationSURPASS


This document consists of a total of 174 pages. All pages are issue 3.

Contents

1 About this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1 Structure of the UMN:SURPASS hiG 1600/DLU-IP . . . . . . . . . . . . . . . . . . . 8

1.2 Editorial notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.2 Documentation overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.3 Conventions used in this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Functional units of hiG 1600 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 TDM clock for hiG 1600 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Processing of payload, OAM and control traffic in hiG 1600 . . . . . . . . . . . 18

2.4 Uplink interface configuration variants for hiG 1600 . . . . . . . . . . . . . . . . . . 212.4.1 Dedicated OAM interface and dedicated control interface . . . . . . . . . . . . . 21

2.4.2 Dedicated OAM interface and control traffic via payload interface . . . . . . . 22

2.4.3 Dedicated payload interface and control traffic via OAM interface . . . . . . . 23

2.4.4 OAM traffic via payload interface and dedicated control interface . . . . . . . 23

2.4.5 OAM and control traffic via payload interface . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.6 Default uplink configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.6.1 Separated OAM, control and payload traffic. . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.6.2 Embedded OAM, control and payload traffic via FE uplink. . . . . . . . . . . . . 26

2.4.6.3 Embedded OAM, control and payload traffic via GE uplink . . . . . . . . . . . . 27

2.5 Configuration guidelines for hiG 1600 and environment. . . . . . . . . . . . . . . 28

2.5.1 Configuration guidelines for hiG 1600’s IP addresses and subnets . . . . . . 28

2.5.1.1 Voice module’s IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5.1.2 PS-E’s IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5.1.3 STMI’s IP addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5.1.4 Summary of IP addresses and subnets for hiG 1600 . . . . . . . . . . . . . . . . . 30

2.5.1.5 Example configuration for IP addresses and subnets related to hiG 1600 . 32

2.5.2 L2 switch configuration guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.5.3 Router configuration guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.5.4 L3 switch configuration guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.6 hiG 1600 hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.6.1 Frames/shelves and racks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.6.2 hiG 1600 modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.6.2.1 Ethernet Switch Version B (ESB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.6.2.2 Packet Service Controller Card Type C . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.6.2.3 Voice Module Card (VMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.6.2.4 Voice Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.6.2.5 ESB Connector Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.6.2.6 Integrated SDH (STMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.6.2.7 Special equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.6.2.8 Alarm Distributor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.6.2.9 GBIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47



4 A30828-X1187-U125-3-7619


3 Operation and administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.1 Managing hiG 1600 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.1.1 Management concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1.2 Overview about manageable entities and management systems . . . . . . . . 533.1.3 General configuration rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.1.4 Starting hiG 1600-specific functions from Containment View . . . . . . . . . . . 57

3.2 NE group and NE administration for hiG 1600. . . . . . . . . . . . . . . . . . . . . . . 58

3.3 PS-E management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.3.2 Managing PS-E nodes using BCSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.3.2.1 Functions of BCSS plug-in for PS-E nodes . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.3.2.2 Overview about PS-E-specific node data. . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.3.2.3 PS-E-specific windows in BCSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.3.2.4 Creating/modifying/deleting PS-E nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.3.2.5 PS-E preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.3.2.6 SNMP access list for PS-E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.3.2.7 Operational PS-E node in BCSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.3.3 Monitoring PS-E using Containment View. . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.3.4 Configuration tasks via Workbench for PS-E. . . . . . . . . . . . . . . . . . . . . . . . 76

3.3.4.1 Manage PS-E’s VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.3.4.2 Manage PS-E’s ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.3.4.3 Manage PS-E’s TDM clock input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.3.4.4 Manage PS-E’s alarm inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.4 FPU-E management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.4.2 Managing FPU-E nodes using BCSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

3.4.2.1 Functions of the BCSS plug-in for FPU-E nodes. . . . . . . . . . . . . . . . . . . . . 81

3.4.2.2 Overview about FPU-E-specific node data . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.4.2.3 FPU-E-specific windows in BCSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.4.2.4 Creating/modifying/deleting FPU-E nodes with BCSS. . . . . . . . . . . . . . . . . 87

3.4.2.5 FPU-E preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.4.2.6 SNMP access list for FPU-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.4.2.7 Operational FPU-E node in BCSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3.4.3 Monitoring FPU-E using Containment View. . . . . . . . . . . . . . . . . . . . . . . . . 92

3.4.4 Configuration tasks for FPU’s Voice Module . . . . . . . . . . . . . . . . . . . . . . . . 98

3.4.4.1 Manage Voice Modules’s administrative port states . . . . . . . . . . . . . . . . . . 993.4.4.2 Manage Voice Module’s basic configuration . . . . . . . . . . . . . . . . . . . . . . . . 99

3.4.4.3 Manage Voice Module’s IP addresses for control and payload . . . . . . . . 100

3.4.4.4 Manage Voice Module’s message channel associations. . . . . . . . . . . . . . 100

3.4.4.5 Manage Voice Module’s test interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.4.4.6 Manage Voice Module’s Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.5 Security management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.5.1 Manage “white list” for hosts that may have access to FPU-E/PS-E . . . . . 103

3.5.2 Switch on/off IP/UPD check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3.6 Subscriber and trunk management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.6.1 V5.2 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.6.1.1 Prepare LTG and LTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104



A30828-X1187-U125-3-7619 5

OperationSURPASS


3.6.1.2 Create V5.2 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.6.1.3 Create V5.2 subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.6.2 Virtual trunking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.6.3 TDM Subscriber at hiG 1600 (via DLU) . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.6.4 Private Branch Exchange (PBX). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.6.5 Trunks at hiG 1600 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.6.6 Centrex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

3.7 Performance and Quality of Service management . . . . . . . . . . . . . . . . . . 106

3.7.1 Measurement of statistics data from a specific Voice Module . . . . . . . . . 106

3.7.2 Measurement of QoS statistics data at the Voice Module . . . . . . . . . . . . 107

3.8 Accounting management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3.9 Conference Server management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3.10 Clock management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

3.10.1 Manual switchover for PS-E clock unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

3.10.2 Clock source selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083.11 “Time of day” management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

3.12 Trap destination management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

3.12.1 Managing external trap destinations for PS-E via Workbench . . . . . . . . . 109

3.12.2 Managing external trap destinations for FPU-E via Workbench . . . . . . . . 110

4 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.1.1 Using NetManager and its applications for hiG 1600 maintenance . . . . . 111

4.1.2 Overview about hiG 1600 alarming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.1.3 Redundancy and failover functions for hiG 1600 . . . . . . . . . . . . . . . . . . . 115

4.2 Starting the fault clearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.2.1 Online fault clearance procedures via IDB . . . . . . . . . . . . . . . . . . . . . . . . 120

4.2.2 OS alarms from NetManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2.3 SNMP alarms from hiG 1600 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.3 SNMP messages from FPU-E (VM part). . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.3.2 Evaluating states and corresponding details for VM. . . . . . . . . . . . . . . . . 123

4.4 SNMP messages from PS-E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4.4.2 Status propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

4.4.3 Operational and alarm state combinations for PS-E ports . . . . . . . . . . . . 128

4.5 SW update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4.5.1 SW update on Voice Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

4.5.2 SW update on PS-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

4.6 Executing a brief function test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

4.6.1 HW diagnosis for Feature Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

4.6.2 HW diagnosis for PS-Es or Voice Modules. . . . . . . . . . . . . . . . . . . . . . . . 137

4.7 Replacing hiG 1600 modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

4.7.1 Replacing VMC (MP480 module) or PSC-C (FPP module) . . . . . . . . . . . 138

4.7.2 Replacing PS-E (ESB module) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

4.7.3 Replacing PS-E’s interface module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

4.8 Backup/restore hiG 1600 database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434.8.1 Backup and restore for the Voice Module. . . . . . . . . . . . . . . . . . . . . . . . . 144



6 A30828-X1187-U125-3-7619


4.8.2 Backup for the PS-E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

4.8.3 Backup and restore for Feature Processors . . . . . . . . . . . . . . . . . . . . . . . 149

4.9 Symptom saving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

4.9.1 Traps recorded by the Log Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504.9.1.1 Traps from PS-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

4.9.1.2 Module startup traps from VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

4.9.1.3 Command execution traps from VM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

4.9.2 Read Voice Module’s error notebooks or event log book . . . . . . . . . . . . . 152

4.9.3 Upload PS-E maintenance information to NetManager . . . . . . . . . . . . . . . 152

4.9.4 Port statistics and port mirroring data delivered by the PS-E. . . . . . . . . . . 153

4.10 Troubleshooting hints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

5 DLU-IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

5.1.1 DLU-IP abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

5.1.2 Clock synchronization in DLU-IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

5.1.3 Uplink interface configurations for DLU-IP. . . . . . . . . . . . . . . . . . . . . . . . . 160

5.1.3.1 Dedicated OAM traffic interface (FE0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.1.3.2 Common OAM, control and payload interface (FE2) . . . . . . . . . . . . . . . . . 162

5.1.4 Summary of IP addresses and subnets for DLU-IP . . . . . . . . . . . . . . . . . . 163

5.2 Operation and administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5.2.1 DLU-IP in hiE 9200 database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

5.2.2 FPU-E nodes in a DLU-IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

5.2.3 DLU-IP in Containment View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

5.3 Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

6 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

6.1 hiE 9200 database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

6.2 Interworking scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

6.2.1 Interworking between hiG 1600 units within the same domain . . . . . . . . . 170

6.2.2 Interworking between hiG 1600 units within different domains . . . . . . . . . 171

6.2.3 Interworking between hiG 1600 and hiG 1x00 trunking gateways. . . . . . . 172

6.3 SNMP background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172



A30828-X1187-U125-3-7619 7

OperationSURPASS


1 About this manualThis UMN:SURPASS hiG 1600/DLU-IP covers administration/operation and mainte-

nance of the SURPASS hiG 1600 V2 and SURPASS DLU-IP.

The UMN:SURPASS hiG 1600/DLU-IP predominantly describes the handling of mod-

ules that are managed via SNMP from NetManager.

For modules that are managed via MML and hiE 9200 (e.g. Feature Processors) or that

are managed from their specific management systems (e.g. optional STMI managed by

TMNS-C), this manual refers to other manuals.

This manual contains examples with descriptions of inputs for tasks and applications.

However, this manual doesnot

describe each individual task. For detailed information

on tasks and their input parameters, see the Task Manual (TML), or use the help texts

implemented in the tasks.

Who is addressed by this manual?

The UMN:SURPASS hiG 1600/DLU-IP is addressed to the operator/administrator of the

hiG 1600 equipment. This can be the Siemens service personnel or the customer’s per-

sonnel on site.

The manual is written for trained personnel. This means that the user of this manual

must be familiar with SURPASS, the NetManager, general network technology, VoIP

technology and network access server technology (e.g. TCP/IP, Ethernet, SNMP, Man-

agement Information Base, etc.).

Nevertheless, some basic information on the items above is provided in this manual

within the context of the hiG 1600.

What tasks are described in this manual?

Basically the handling of SURPASS equipment can be separated in two main phases.

1. Phases that are supported by Siemens

(not subject of UMN:SURPASS hiG 1600/DLU-IP)

– Planning

– Commissioning

– Upgrade, migration

2. Phases that can be covered by the carriers(subject of UMN:SURPASS hiG 1600/DLU-IP)

– In operation

– Maintenance and fault clearance

The UMN:hiG 1600/DLU-IP assumes that the hiG 1600 is installed and operational, thus

a commissioning procedure is not subject to this manual. However, configuration tasks

necessary for replacing modules are included.

iThe DLU-IP is treated as one hardware variant of the hiG 1600 for small applications.DLU-IP-specific items are collected in a separate chapter which also refers to sectionsin other chapters valid for hiG 1600 V2 and DLU-IP.



8 A30828-X1187-U125-3-7619


This manual describes the carrier’s tasks for hiG 1600 using the NetManager Base

System (including base applications) together with the hiG 1600-specific Task Data-

base Package.

Refer to the NetManager System Description for general information on NetMan-

ager’s base system.

1.1 Structure of the UMN:SURPASS hiG 1600/DLU-IP

This manual is structured as follows:

• Section 1.2 "Editorial notes"

(section in this chapter About this manual)

This section lists the conventions used in this manual and gives an overview of thedocumentation.

• Chapter 2 "Introduction"

This chapter provides an overview of the functional units and of the hardware. It de-

scribes clock and traffic processing in hiG 1600, the uplink interface configuration

variants and provides configuration guidelines for hiG 1600 and its environment.

A detailed description of hiG 1600 and its application variants within the SURPASS

environment can be found in SURPASS hiG 1600 V2 - Functions and Hardware

• Chapter 3 "Operation and administration"

This chapter describes how to operate/administrate the hiG 1600 hardware and soft-

ware. This also applies for adapting the hiG 1600’s original configuration to a modi-

fied network environment.• Chapter 4 "Maintenance"

This chapter deals with maintenance tasks (e.g. trouble shooting, module replace-

ment, SW update). A guideline how to clear alarms is also included.

• Chapter 5 "DLU-IP"

This chapter collects DLU-IP-specific information and refers to sections that valid for

hiG 1600 and DLU-IP.

• Chapter 6 "Appendix"

This chapter provides technical background information and generic descriptions.

1.2 Editorial notes

The product names are abbreviated in this manual (for example “SURPASS hiG 1600”

->”hiG1600”).

For simplification this manual uses the term “hiG 1600” for SURPASS hiG 1600 as well

as for SURPASS DLU-IP. The term “DLU-IP” is used to provide DLU-IP-specific infor-

mation.

The hiG 1600 equipment can be given a module name as printed on the board (e.g.

M:SLMI:ESB) or a functional name (e.g. M:SLMI:ESB = PS-E or Packet Switch Ether-

net). Whenever possible, this manual uses the functional names of the hiG 1600 equip-

ment.

i Applications that are not included in NetManager’s Base System (for example Perfor-mance Data Collector) are delivered with their own manuals and are not treated in this

manual.

i

Not all NetManager applications use the functional name. Thus there may be different

names for a module in a screenshot and in the corresponding text.

http://k160.pdf/

http://k160.pdf/



A30828-X1187-U125-3-7619 9

OperationSURPASS


1.2.1 Restrictions

Please note the following restrictions:

1. The information on the actual product version is included on the binder and the ac-

cessory package (supplied with the printed documentation) and on the CD ROMcover (supplied with the electronic documentation).

2. The hiG 1600 manuals describe what has been specified and developed. Some-

times not all features are released for use by customers for certain reasons, or are

only released on a project-specific basis. These unreleased features are specified

in the Release Notes that are delivered to you with your system. Furthermore, the

manuals describe the specified normal behavior of the system.

If there are deviations from this behavior that cannot be corrected immediately,

please refer to the Release Notes.

3. All information about other devices is to be understood as examples. Please refer to

the product-specific documentation for further details.

4. The SURPASS MML commands are exemplary and based on the English version.Please refer to the TML (Task Manual) of your actual SURPASS version for further

details.

1.2.2 Documentation overview

The following documentation plays a role in your work with the hiG 1600:

• SURPASS manuals

The SURPASS manuals consist of all handbooks describing the operation andmaintenance of a certain SURPASS version.

The following SURPASS documentation is necessary for operating the hiG 1600:

– UMN:SURPASS hiG 1600/DLU-IP (this manual)

This is the central document for hiG 1600 operation and maintenance and refers

to other manuals concerned.

– TML (Task Manual)

This contains detailed explanations of all basic operation, administration and

maintenance tasks for the hiG 1600. The TML explanations are also available as

task and/or parameter help text within NetManager’s Workbench.

– hiG 1600 description (including product data sheet)

This description covers the different features, hardware modules and product da-ta.

– General information

Using the hiG-specific documentation (introduction to operating documentation,

abbreviations, glossary, safety instructions, etc.)

– Construction Manual

Construction of hiG 1600 racks, frames and modules. This manual also provides

information on indicators, switches and mounting locations.

– Site-specific documentation (Cabling List, Configuration Documentation, Release

Notes, etc.)

For setting up data connections, you also need information on your data network

environment and any special agreements with an ISP (e.g. Quality of Service pa-

rameters).

iThe required configurations and the corresponding task groups depend on the released

functions of the hiG 1600. This means that not all tasks are possible and not all config-

urations are required.



10 A30828-X1187-U125-3-7619


– UMN:SURPASS hiE 9200

User manual for hiE 9200

– LTG manuals

– MMN:FP (LTG)

• NetManager base system documentation

For operation and maintenance of the hiG 1600, you need the NetManager together

with its applications. Therefore the UMN:hiG 1600/DLU-IP also refers to the Net-

Manager documentation.

The following NetManager applications - described in the NetManager Administra-

tion Manual (ADMN) and User Manual (UMN) - are especially relevant for the hiG

1600 operation and administration:

– NE Group Administration

Administrates network element groups

– NE Administration

Administrates network elements

– Basic Configuration and System Setup (BCSS)

Administrates SNMP nodes and configures connection to NetManager

– Workbench

Executes all types of commands (e.g. BOAM tasks)

– Containment View

Displays status of SNMP-managed network elements/nodes/interfaces

– Log Viewer

Filters and displays trap information and provides a task history

– Alarm Message Display

Shows all alarms (including alarms from NetManager) together with their history,

alarms can be cleared/confirmed

– Alarm ConsoleDisplays unsolicited MML-based messages

– Network Topology Map Editor/Viewer

Shows network elements with their corresponding alarms in a map

– Work Order Viewer

Provides information on measures that have been executed to clear an alarm

– Floor Plan Editor

Used to create a map showing the physical location of network elements and their

components

– SW Management

Software and firmware maintenance for SNMP-managed modules

• NetManager documentation for optional applications, for example:

– Autopatch

Patch tool

– Performance Data Collector

Collects performance measurement data

– FastNet

Tracks QoS issues by monitoring signaling information between media gateways

and their controllers

• STMI documentation (if appropriate)

– UMN:STMI

Covers administration/operation and maintenance for the STMI equipment.

– Information STMI

Overview about STMI features, interfaces, and functions



A30828-X1187-U125-3-7619 11

OperationSURPASS


– OMN:NE-UniGATE

Covers operation of gateway software NE-UniGATE

• OEM documentation (if appropriate)

The hiG 1600 may be connected to OEM products (e.g. ERX 700/1400). These de-

vices are delivered with their specific documentation. The SURPASSdocumentation

refers to these OEM manuals.

• Site-specific documentation for data network

For setting up connections to the packet-based network (PBN), you need informa-

tion on your data networkenvironment andany special agreements with an ISP (e.g.

Quality of Service parameters)

• Common standards and their documentation

The hiG 1600 is based on common standards and conventions published by the ap-

propriate organizations (e.g. ATM Forum, IETF, ITU, ISO). These standards can be

found on the Internet.

1.2.3 Conventions used in this manual

Graphical user interface text

Text from the graphical user interface (window titles, button descriptions, etc.) is placed

inside quotation marks.

Example of graphical user interface text:

In the “Alarm List” dialog box, select the alarms and click “Confirm”.

Commands

Commands and parameters are displayed in different color.

Clicking on a hiG 1600 command automatically starts its specific input window in the

workbench.

Examples of commands:

Start the task DISP MODSTAT

You can find the long name for a certain command in the Task Tree.

Variables

Placeholders for real names and values are represented additionally in italics and angle

brackets.

Example of variable:

Use the default start command <installation path>\APanel.exe.

Notes

Notes provide useful information about specific situations of which you should take note.Notes are represented in the text by information symbols.

iSince the UMN:SURPAS hiG 1600/DLU-IP and the other manuals do not specifically

cover the equipment on site, the site-specific documentation is also necessary to con-

figure the hiG 1600 equipment according to the customer’s needs.

iYou can only start commands belonging to your current hiG 1600 / hiE 9200 task data-

base package from this manual. Commands belonging to other task database packages

(e.g. hiG 1000) cannot be started from this manual.

http://cmlexch.pdf/

http://cmlexch.pdf/



12 A30828-X1187-U125-3-7619


Example of notes:

Warnings

Warnings give you important information that must be observed in order to avoid dam-

age (e.g. data loss). Warnings are represented in the text by warning symbols.

Example of warning:

iThe required configurations and the corresponding BOAM task groups depend on the

released functions of the hiG 1600. This means that not all tasks are possible and not

all configurations are required.

!If you have an optional application, you should use this instead of the BOAM tasks.

However, you should not set the same parameters for BOAM tasks and another appli-

cation, as this would lead to database inconsistencies.



A30828-X1187-U125-3-7619 13

OperationSURPASS


2 IntroductionThe hiG 1600 and its applications are described in SURPASS hiG 1600 V2 - Functions

and Hardware.

General background information on related topics can be found in chapter 6 "Appendix".

The chapter 5 "DLU-IP" collects DLU-IP-specific information and refers to sections in

this chapter relevant for the DLU-IP.

2.1 Functional units of hiG 1600

A hiG 1600 consists of one, or several Packet Service Controller(s) (PSC). Each PSC

provides IP uplinks that can be aggregated using external equipment.

The PSC’s main functions are:

– subscriber feature processing (same features as a TDM class 5 switch)

– VoIP conversion for payload

A PSC contains the following types of functional units:

• Feature Processor Unit Type Ethernet (FPU-E) that comes with two variants.

– Default variant with integrated Feature Processor:

Packet Service Controller Card (PSC-C) with optional special equipment (LTU:S)

– Variant for reuse of existing LTGs (Feature Processor connected via cable):

Voice Module Card (VMC) connected to LTG(s) (which are working as Feature

Processor)

• Packet switch type Ethernet (PS-E) or ESB connector card (ECON)

Depending on the hardware the PSC provides these physical (layer 1) TDM interfaces:

– E1 (PCM 30)

– LDI – Aggregation of E1 lines to STM-1 with the optional SDH multiplexer STMI

These are the PSC’s higher layer TDM interfaces:

• Interfaces to access equipment

– proprietary V93 interface to digital line unit (DLU)

– V5.2 interface to access equipment

– V5.1 interface to access equipment (via DLU)

• Subscriber interfaces

– E1 ISDN primary rate interface (e.g. to PBX)

– POTS/ISDN/xDSL (via DLU)*

• E1 ISUP/CAS/MF trunk interfaces (e.g. to PSTN switches)**

• Packet handler interface (PHI) for D channel packet data

Contents

2.1 "Functional units of hiG 1600"

2.2 "TDM clock for hiG 1600"

2.3 "Processing of payload, OAM and control traffic in hiG 1600" (also valid for DLU-IP)

2.4 "Uplink interface configuration variants for hiG 1600"

2.5 "Configuration guidelines for hiG 1600 and environment" (also valid for DLU-IP)

2.6 "hiG 1600 hardware" (includes PSC-C as part of hiG 1600 or DLU-IP)

iThe FPU-E can be distributed over several frames in the event that an external DLU is

employed as Feature Processor.

http://k160.pdf/

http://k160.pdf/

http://k160.pdf/

http://k160.pdf/



14 A30828-X1187-U125-3-7619


* ADMOSS MSB and Centrex MAC can be supported in project-specific releases.

** No5 trunks with echo suppression functionality or PCM24 interfaces can be supported

in project-specific releases.

The integrated redundant PS-Es provide Fast Ethernet (FE) or Gigabit Ethernet (GE)

uplink interfaces to the IP network supporting the address resolution protocol (ARP).

The uplink interfaces are connected to edge routers or layer 2/3 switches in the IP net-

work. For simplification this manual uses the term “edge router” (for topics that are valid

for edge routers and for switches).

These are the PSC’s IP uplink interfaces (via PS-E):

• 1x GE or 1x FE (redundant payload uplink)

• 1x FE (optional redundant OAM uplink)

• 1x FE (optional redundant control uplink)

Two ECON modules can be plugged instead of the PS-Es in an extension shelf to cas-

cade two shelves via one PS-E pair.

With optional special equipment on mounting location LTU:S specific services like

large conferencing, or packet-data via V5.2 can be made available.

External alarm sensors are connected via AD:RAL module.

In the smallest configuration (one shelf in frame PSC(D) occupied) the PSC consists of

1 to 5 Feature Processor Units Type Ethernet (FPU-E) and two Ethernet Packet

Switches (PS-E). Optionally STMI equipment can be plugged in the same shelf.

The FPU-E is a logical multi-module compound. From the functionality point of view it

provides – Feature Processor (FP) / Line Trunk Group (LTG) functions

(TDM connectivity, call processing)

– Voice Module (VM) functions

(voice processing, Codecs, IP connectivity)

FP/LTG functions are provided by the Packet Switch Controller Cards (PSC-C) or leg-

acy LTGs, mainly for special services.

Voice module functions are provided by the voice submodule on the PSC-C or by the

voice submodule on the Voice Module Card (VMC) which is used with associated LTGs.

The PSC “resources” (i.e. number of “feature processing functions” together with corre-

sponding voice channels) depend on the FPU-E variant.

2.2 TDM clock for hiG 1600

TDM clock synchronization variants

The hiG 1600 is able to synchronize its TDM interfaces to a reference clock. In the event

that the reference clock fails the hiG 1600 itself provides such a clock with an accuracy

that meets the requirements for local node clocks according to G.812 Type VI (world

market version) or Stratum 3 according GR-1244-CORE (US market version) respec-

tively.

iAny combinations of FPU-E (PSC-C or VMC+LTGx) and TDM interface variants arepossible within a PSC.

iI

In applications where these criteria are not sufficient (e.g. for trunk nodes) it is manda-

tory to install a clock device which fulfills the required standards (e.g. CCGE).



A30828-X1187-U125-3-7619 15

OperationSURPASS


The PS-Es within a hiG 1600 require an external clock (via cable) for synchronization.

These can be the clock sources:

1. External synchronization clock

– 2048 kHz for world market – 1544 kHz BITS signal for US market

2. Receive Line Clock (RCLK)

Derived from the first E1 line of the first Feature Processor function (LTG function)

of an FPU-E

This means one clock per FPU-E and requires a cable to the PS-E.

3. SDH clock of STM-1 interface (if appropriate)

This applies in the event that your hiG 1600 employs an STMI and requires an cable

to the PS-E.

Clock synchronization and daisy chaining with external reference clock

The clock units of the two PS-Es in one shelf act as redundant pair of clock distributors,synchronizing all PSCs in the shelf (or in a cascaded shelf) in parallel.

Each PS-E provides

– an external clock input for external synchronization clock

(see "TDM clock synchronization variants")

– clock outputs (8 kHz) to the PSC-Cs/VMCs

(in the shelf itself or in a cascaded shelf)

– a clock output (2048 kHz) to another PS-E (daisy-chain)

In the event that the external reference clock fails the PS-E sends a clock alarm to Net-

Manager and the standby clock unit takes over. If the standby clock unit is not available

or its reference clock failed too thePS-E provides a free running clock in holdover mode.

iThe external reference clock can be passed through from one PS-E to the other within

one rack and passed through to other racks in a daisy chain up to a maximum of

14 PS-Es.



16 A30828-X1187-U125-3-7619


Fig. 2.1 TDM clock paths in hiG 1600

FP = Feature Processor

VM = Voice Module

ESB = Ethernet Switch

Type B = PS-E



A30828-X1187-U125-3-7619 17

OperationSURPASS


Clock synchronization example for PSC-C in shelf PSC(D)

Fig. 2.2 Clock synchronization for PSC-C

The external reference clock is connected to the clock input of the PS-E which distrib-

utes a 8 kHz clock to the PSCs within the shelf.

The default clock interface at the PSC-C for this configuration is EXTCLK 0.



18 A30828-X1187-U125-3-7619


Clock synchronization example for VMC in shelf PSC(D)

Fig. 2.3 Clock synchronization for VMC

The external reference clock is connected to the clock input of the ESB which distributes

a 8 kHz clock to the Voice Module cards within the shelf.

The synchronization clock is sent from the VMC to the LTGx via SN interface.

The default clock interface at the VMC for this configuration is EXTCLK 0.

2.3 Processing of payload, OAM and control traffic in hiG 1600

Traffic types in hiG 1600 context

The hiG 1600 distinguishes these traffic types:• OAM traffic

– Traffic between NetManager and hiG 1600 (for example SNMP)

– Test traffic between hiG 1600 hosts (i.e. modules) and gateways that are assigned

to OAM traffic

• (VoIP) payload traffic

– Traffic between hiG 1600 and other network elements

(e.g. hiR 200, hiG 1600)

– Traffic between hiG 1600 and Internet clients

(e.g. H.323, SIP)

– CCS7 traffic via nailed-up connections between hiG 1600 and hiE 9200

– Test traffic between hiG 1600 hosts and gateways that are assigned to payload

traffic

iIn principle this section is also valid for DLU-IP. However, the DLU-IP does not have a

PS-E which results in different uplink interface configurations.



A30828-X1187-U125-3-7619 19

OperationSURPASS


– Traffic between hiG 1600 hosts located in the same subnet or in the same hiG

1600

• Control traffic

– Maintenance and control messages that are transported via the message chan-

nel (SCTP) between Feature Processor (FPP/LTGx) and CP

– Test traffic between hiG 1600 and edge routers that are assigned to control traffic

The following table shows which hiG 1600 hosts (i.e. modules) do generate which kind

of traffic.

Network interfaces and traffic aggregation

For DLU-IP-specific network interfaces, refer to 5.1.1 "DLU-IP abstract".

The hiG 1600’s network interfaces are provided by the PS-E. Usually these network in-

terfaces are redundant.

There are several virtual LANs (VLANs) on the PS-E, establishing a logical switch foreach traffic type:

– one VLAN for OAM traffic

– one VLAN for control traffic

– one VLAN for payload (VoIP)

These traffic types (VLANs) can be assigned to network interfaces in a flexible way, sup-

porting configurations with and without traffic separation.

The PS-E’s uplinks can be configured as follows:

– OAM separated uplink (untagged)

– OAM together with payload (OAM untagged, payload tagged)

– Control separated uplink (untagged)

– Control together with OAM (control tagged, OAM untagged) – Control together with payload (control tagged, payload untagged)

– OAM, control and payload together (OAM untagged, control/payload tagged)

For further details, refer to 2.4 "Uplink interface configuration variants for hiG 1600".

Traffic routing/forwarding

Edge routers (or L2/3 switches) apply for traffic routing between different hiG 1600 sites.

Redundant planes of switches and aggregation network avoid single points of failure.

These redundant planes are interconnected via crosslink.

Crosslink as well as uplink must be able to transport the whole traffic.

iPSC-C maintenance messages do occur as “OAM traffic” (for example SNMP traps to

NetManager) and as “control traffic” (for example LTG STAF messages to CP).

Host OAM traffic Control traffic Payload traffic

PS-E (ESB) X

Optional STMI X

FPU-E(VMC or PSC-C)

X X X

Tab. 2.1 Traffic types being generated by hiG 1600 hosts



20 A30828-X1187-U125-3-7619


At each gateway or router there are two alternative paths - a default route (lower cost

route) and an alternative route. If the default route fails the Voice Module switches over

to the alternative route, thus minimizing service impacts.

The crosslink is a prerequisite for failover functions, see 4.1.3 "Redundancy and failover

functions for hiG 1600".

Configuration hints for connected routers/switches in the event that tags are used:

– The routers/switches must be able to transport several VLANs (no port based VLAN)

– The VLAN identifications must be identical on all hiG 1600 components as well as

on connected routers/switches

– Spanning Tree Protocol (STP) must be switched off at connected routers/switches

Section 2.5 "Configuration guidelines for hiG 1600 and environment" provides neces-

sary details to configure hiG 1600 and connected devices.

VoIP payload

The hiE 9200 provides a call control function to translate switched network signaling to

IP domain signaling and configures the associated hiG 1600 to perform conversion and

forwarding of media streams.

All signaling messages related to voice over IP services or interworking between TDM

and data networks are received and evaluated by the hiE 9200. Based on this signaling

information the receiving hiE 9200 processes the service or feature, usually sending out

additional signaling messages to PSTN networks or other media gateway controllers, or

data clients.

VoIP payload traffic from the TDM to the IP network comes in directly or via STMI to aPSC. There it is coded and packetized into an RTP stream and transferred via FE con-

nections to the PS-E.

The PS-E aggregates all traffic via L2 switching to one either GE or FE interface and

forwards the payload to the IP network; i.e. to a router or switch.

The PSC’s Voice Module supports the following Codecs:

– G.711 (no compression)

– G.723

– G.726

– G.729A

The Voice Module provides an echo canceller according to G.168 (128 msecs echo tail).

The Voice Module supports the following Voice activity detection (VAD) and comfort

noise generation (CNG) configurations:

– VAD disabled (administrated via SNMP)

– VAD enabled using default scheme

Depending on the configured CODEC type the DTMF tones are either signaled outband

or transported inband. With the compressing CODEC G.723.1 or G.729 the DTMF tone

is signaled outband. With CODEC G.711 all DTMF tones are transmitted inband.

Internal traffic between subscribers connected to the same hiG 1600 unit is kept “local”

and is not forwarded to the IP core network interfaces.

! To avoid L2 loops the crosslink between two paths to the IP backbone must be locatedat the switch nearest to the edge router (between hiG 1600 and edge router).



22 A30828-X1187-U125-3-7619


Fig. 2.4 PSC(D) with dedicated OAM interface and dedicated control interface

Use this configuration for best separation of traffic, in particular when a dedicated OAM

network is required.

Since OAM and control share the same internal interface between PSC-C and PS-E, in-

ternal tagging of control traffic is mandatory to allow for separation inside PS-E.

Payload and control traffic could be tagged on external PS-E interfaces, but this is nor-

mally not required.

2.4.2 Dedicated OAM interface and control traffic via payload interface

Two physical uplink interfaces are used: – FE Up OAM (dedicated OAM traffic interface)

– GE (common interface for payload + control traffic)

Fig. 2.5 PSC(D) with dedicated OAM interface and control via payload interface

Use this configuration when two separate networks are deployed:

– one common network for payload and control

– a separate network for OAM



A30828-X1187-U125-3-7619 23

OperationSURPASS


Since OAM and control traffic share the same internal interface between PSC-C and

PS-E, internal tagging of control traffic is mandatory to allow for separation inside PS-E.

Control traffic should be tagged on the external PS-E GE interface, to avoid tagging of

payload traffic

2.4.3 Dedicated payload interface and control traffic via OAM interface

Two physical uplink interfaces are used:

– FE Up OAM (common interface for OAM + control traffic)

– GE (payload interface)

Fig. 2.6 PSC(D) with dedicated OAM interface and control via OAM interface

Use this configuration when a single common IP network is deployed for all traffic types.

This is the preferred configuration to avoid interference of control and OAM traffic with

bearer traffic.

Since OAM and control share the same internal interface between PSC-C and PS-E, in-

ternal tagging of control traffic is mandatory to allow for separation inside PS-E.

Since OAM and control also share the same external interface (FE Up OAM), tagging of

control traffic is mandatory to allow further separation.

2.4.4 OAM traffic via payload interface and dedicated control interface

Two physical uplink interfaces are used: – FE Up Ctrl (control traffic)

– GE (common interface for payload and OAM traffic)



24 A30828-X1187-U125-3-7619


Fig. 2.7 PSC(D) with OAM via payload interface and dedicated control interface

This configuration is not recommended.

Use only when a common IP network is deployed for payload and OAM, whereas a sep-

arate network is required for control traffic.

Since OAM and control share the same internal interface between PSC-C and PS-E,

tagging of control traffic is mandatory to allow for separation inside PS-E.

Since OAM and payload share the same external interface (GE), tagging of payload traf-

fic is mandatory to allow further separation. OAM cannot be tagged instead.

2.4.5 OAM and control traffic via payload interfaceA single physical interface (GE) is employed as common interface for all traffic types.

Fig. 2.8 PSC(D) with OAM and control traffic via payload interface

Use only when a single uplink interface is mandatory, for example because hiG 1600 is

remotely connected via dark fiber, or there is only an optical GE switch interface avail-

able, but no Fast Ethernet in addition.



26 A30828-X1187-U125-3-7619


Fig. 2.10 Default VLAN attributes for separated OAM, control and payload traffic

2.4.6.2 Embedded OAM, control and payload traffic via FE uplink

Fig. 2.11 Default port attributes for embedded OAM, control and payload via FE



A30828-X1187-U125-3-7619 27

OperationSURPASS


Fig. 2.12 Default VLAN attributes for embedded OAM, control and payload via FE

2.4.6.3 Embedded OAM, control and payload traffic via GE uplink

Fig. 2.13 Default port attributes for embedded OAM, control and payload via GE



28 A30828-X1187-U125-3-7619


Fig. 2.14 Default VLAN attributes for embedded OAM, control and payload via GE

2.5 Configuration guidelines for hiG 1600 and environment

2.5.1 Configuration guidelines for hiG 1600’s IP addresses and subnets

The following default configuration for internal traffic is assumed:

• OAM/control traffic is mapped to FE0/FE1 of PSC-C/VMC *

• Payload traffic is mapped to FE2/FE3 of PSC-C/VMC

* Control traffic may as well be mapped to the payload interfaces FE2/FE3 (refer to

3.4.4 "Configuration tasks for FPU’s Voice Module").

The PS-E assigns OAM traffic to the uplink where the DHCP request was successful.

2.5.1.1 Voice module’s IP addresses

The Voice Module (VM) is the media gateway subsystem of PSC-C and VMC and im-plements the IP endpoints within these boards. In general, the VM has a set of IP ad-

iIn principle this section is also valid for DLU-IP. However, the DLU-IP does not have a

PS-E which results in different uplink interface configurations.

Contents

2.5.1 "Configuration guidelines for hiG 1600’s IP addresses and subnets"

2.5.2 "L2 switch configuration guidelines"

2.5.3 "Router configuration guidelines"2.5.4 "L3 switch configuration guidelines"

Contents

2.5.1.1 "Voice module’s IP addresses"

2.5.1.2 "PS-E’s IP addresses"

2.5.1.3 "STMI’s IP addresses"(applies in the event that hiG 1600 is equipped with STMI)

2.5.1.4 "Summary of IP addresses and subnets for hiG 1600"

2.5.1.5 "Example configuration for IP addresses and subnets related to hiG 1600"



A30828-X1187-U125-3-7619 29

OperationSURPASS


dresses for each traffic type (OAM, payload, control). In some cases, several traffic

types can also share the same set of IP addresses as explained below.

• OAM

There is one IP address for OAM traffic per VM.

This IP address is provided by DHCP when the VM boots. DHCP also provides ad-

ditional parameters such as default gateways and subnet mask which are needed to

operate the OAM interface. The physical OAM interface is determined by the MAC

address configured in the DHCP server (BCSS). The VM attempts to send DHCP

requests over all interfaces, and uses the interface where the DHCP server was suc-

cessfully reached.

• Payload

Each VM must have one payload IP address that is used for bearer traffic termina-

tion.

This address is configured via NetManager’s Workbench, together with related data

such as subnet mask anddefault gateways (refer to 3.4.4.3 "ManageVoice Module’s

IP addresses for control and payload").• Control

A VM needs a different SCTP IP address for each of the four LTG functions it is serv-

ing. These IP addresses must be in a common subnet, and they share the same

subnet mask and default gateways.

The SCTP addresses are configured on the VM via NetManager’s Workbench (refer

to 3.4.4.4 "Manage Voice Module’s message channel associations").

These IP addresses are bound to the SCTP stack, they are not bound to physical

network interfaces.

• Link test IP addresses

The default router link test requires two test IP addresses per traffic type, i.e. a total

of six different link test IP addresses are needed. These test addresses are for localuse only and can be taken from a private address space (e.g. 10.0.x.x). Each test IP

address has its own subnet mask, and all test subnets must be non-overlapping.

Default router link test IP addresses are configured via “Modify Test IP Entry” (refer

to 3.4.4.5 "Manage Voice Module’s test interfaces"). All six test IP addresses must

be configured (non-zero) to enable the link test mechanism, even when some

interfaces are not in use, e.g. in a DLU-IP.

Even though all link test subnets must be different, it is possible to configure a single

test subnet per router interface by subdividing the router test subnet into two parts.

• Sharing IP addresses

In support of the Surpass security concept with logical network separation, it is rec-

ommended that disjoint IP addresses and subnets are used for OAM, payload and

control, together with traffic separation on layer 2. Thus, either subnet-based orVLAN-based filters and ACLs can be used.

It is possible to assign identical IP addresses to multiple traffic types, e.g. OAM and

payload. In this case, the subnet mask and default gateway configuration must be

identical. A minimalistic assignment would be one common IP address for OAM,

payload and control, plus 3 additional addresses for control only.

Restrictions for common IP addresses:

– Traffic types using common IP addresses can no longer be separated on layer 2

(VLANs) or layer 1 (interfaces).



30 A30828-X1187-U125-3-7619


– When OAM or control traffic share the payload IP address, they must also use the

payload network interface (one IP address is always bound to one network inter-

face.

Test IP addresses cannot be shared, i.e. 6 different test IP addresses/subnets

for the 3 traffic types are always needed, even if some traffic types share the

same transport IP address.

2.5.1.2 PS-E’s IP addresses

Each PS-E module has one IP address that is used for OAM. This address is assigned

through DHCP when the module starts up.

2.5.1.3 STMI’s IP addresses

The STMI worker module has one IP address that is used for OAM.

Initially, a serial connection has to be established to the STMI to configure its basic data(IP address, default gateway) via a local craft terminal (TNMS-CT/LCT). As soon as

there is an IP connection to NetM further configuration steps can be done from NetM.

2.5.1.4 Summary of IP addresses and subnets for hiG 1600

For information on IP addresses and subnets for DLU-IP, refer to 5.1.4 "Summary of IP

addresses and subnets for DLU-IP".

IP addresses and subnets for PSC(D) shelves

IP address plans assume dedicated IP addresses for OAM, control and payload.

Sharing of IP addresses is not considered and not recommended. Thus, the number ofIP addresses required is identical in all configurations.

Unit Subnet 1(payload)

Subnet 2(control)

Subnet 3(OAM)

PSC-C/VMC 1 1 4 1

PSC-C/VMC 2 1 4 1

PSC-C/VMC 3 1 4 1

PSC-C/VMC 4 1 4 1

PSC-C/VMC 5 1 4 1

STMI 1

PS-E 1 1

PS-E 2 1

L2 switch 1 1

L2 switch 2 1

Edge router 1 1 1 1

Edge router 2 1 1 1

Tab. 2.3 Externally visible IP addresses for PSC(D) shelves



A30828-X1187-U125-3-7619 31

OperationSURPASS


Sum 7 22 12

Unit Subnet 4(payload test)

Subnet 5(control test)

Subnet 6(OAM test)

PSC-C/VMC 1 2 2 2

PSC-C/VMC 2 2 2 2

PSC-C/VMC 3 2 2 2

PSC-C/VMC 4 2 2 2

PSC-C/VMC 5 2 2 2

STMI

PS-E 1

PS-E 2

L2 switch 1

L2 switch 2

Edge router 1 1 1 1

Edge router 2 1 1 1

Sum 12 12 12

Tab. 2.4 Local test IP addresses for PSC(D) shelves


Subnet 2(control)

Subnet 3(OAM)

Tab. 2.3 Externally visible IP addresses for PSC(D) shelves



32 A30828-X1187-U125-3-7619


2.5.1.5 Example configuration for IP addresses and subnets related to hiG

1600

Fig. 2.15 Example configuration of IP addresses and subnets related to hiG 1600

2.5.2 L2 switch configuration guidelines

This section provides basic rules concerning the connection of hiG 1600 to external

switches.

Ethernet port configuration

Ethernet ports typically support auto negotiation to automatically detect the capabilities

of the physical layer in terms of link speed, full-duplex support and flow control. All hiG

1600 Ethernet interfaces support auto negotiation and auto-adjust twisted-pair cable

cross-over. When they are connected to a switch or router that also supports auto ne-

gotiation, both will negotiate the capabilities correctly (i.e. to full duplex mode).

Special attention must be given to cases where auto negotiation is not supported by ex-

ternal equipment. In this case, the hiG 1600 interface would be set to full duplex mode,

assuming that external equipment is correctly configured also for full-duplex operation.

If that is not the case, the external port must be manually configured to full duplex mode.

In manual configuration mode there is no crossover auto-adjust. The correct cable type

(cross-over, straight-through) has to be used to get a valid link. The hiG1600 behaves

as a switch on its 100BaseT uplinks, not as a host. Thus, a crossover cable is needed

when connecting to other switches in manual mode.

Crosslink

In a cascaded layer 2 aggregation network, the layer 2 switches nearest to the edge

router must have a crosslink, that allows IP packets crossing the planes, so that hosts

having the active interface in plane 0 can talk to hosts having the active interface in

plane 1. The cross-link is also necessary in context with fail over scenarios. A crosslink

between the edge routers is also possible but not required. Such a crosslink may reduce



A30828-X1187-U125-3-7619 33

OperationSURPASS


failover times in some failure scenarios, but this depends heavily on the router imple-

mentation.

Fig. 2.16 Crosslinks between hiG 1600 and external switches

Crosslinks must be located at the switch nearest to the router (and only there) to avoid

L2 loops.

When a hiG 1600 is directly attached to a router, the crosslink must be between the two

PS-E switches inside the PSC shelf. This requires two additional GBICs to be installed.

Crosslink and router uplinks must be able to handle the whole traffic capacity entering

the IP backbone, plus some local traffic if internal load sharing is implemented.

Virtual LAN

All layer 2 switches must support the creation of virtual LANs (VLANs) to support traffic

separation. Port-based VLAN membership as well as tagged VLANs according to IEEE

802.1Q are required. Each tagged VLAN needs a unique VLAN id that is used on all its

member ports.

The PS-E inside the hiG1600 supports VLANs according to IEEE 802.1Q. These are

used to separate the different traffic types. On its uplink interfaces the hiG1600 supportsport based VLANs as well as IEEE 802.1Q VLAN tags.

• Port based VLANs:

Separate traffic using different physical uplinks. Only one traffic type per physical

link. No VLAN tags needed.

• IEEE802.1Q VLAN tags:

Separate traffic using several logical links, but only one physical link. Up to three traf-

fic types per physical link. VLAN tags are needed.

Using IEEE 802.1Q one of the traffic types can be sent untagged, since these frames

are assigned to the default VLAN according to IEEE 802.1Q. To simplify start-up pro-

cesses, OAM traffic is always sent untagged by hiG 1600. The corresponding layer 2

switch port must be a member of the OAM VLAN (untagged). Other VLANs assigned tothis port (if any) must be tagged.



34 A30828-X1187-U125-3-7619


OAM traffic internally uses the default VLAN (VID=1). It is not possible to use

VLAN tags with VID=1 on any interface for any non OAM traffic. Disable any dy-

namic VLAN protocols on connected switches (e.g. DISL, DTP).

The hiG1600 supports independent VLAN learning, i.e. identical MAC addresses can belearnt on more than one interface, if they are assigned to different VLANs. Therefore it

is allowed to connect L3 switches or routers with VLAN interfaces to the hiG1600.

MAC address table ageing

Layer 2 switches are self-learning bridges creating dynamic table entries for MAC ad-

dresses and their assignment to switch ports. These table entries are normally aged out

after some time to remove non-existing MAC address.

You should increase the ageing timer to fairly large values, e.g. 10 or 20 hours, to avoid

pre-mature aging. In any case, the timer should be larger than the ARP cache timeout

of routers and media gateways, i.e. larger than 6 hours. Note that this applies also to the

Ethernet switch integrated on PS-E.Correct ageing helps to prevent flooding in the L2 network, which might become a critical

issue in case of bearer data streams, which use UDP as transport layer.

Spanning Tree Protocol

Spanning Tree Protocol (STP) is normally used by L2 switches to allow redundancy in

the network and detect or prevent loop conditions, by dynamically disabling redundant

links.

The hiG 1600 uses a different method to provide redundancy, since convergence time

of STP is not fast enough. On the other hand STP may have some negative impacts.

• The startup time for any link which gets active is increased due to STP and adds a

delay of (default) 30 seconds.• Topology change mechanisms may reduce MAC address ageing time to very short

intervals (some seconds).

Therefore, any Spanning Tree Protocol variant should be disabled on those

VLANs where a hiG1600 is connected.

If that is not acceptable, alternative solutions such as Rapid Spanning Tree, Cisco Port

Fast or Extreme Networks EAPS could be used. In any case, the Spanning Tree Proto-

col must ensure that connectivity can be restored in less than 2 seconds.

If STP is disabled the aggregation network topology must be such that loops do

not occur. In particular, only connect one crosslink between the redundant L2 switch

planes, located in the switch nearest to the router

2.5.3 Router configuration guidelines

Subnet configuration

Assuming that traffic types are separated and connected to different logical (VLAN) or

physical router ports, each logical router interface has to be configured with two subnets:

one subnet for the actual traffic to be forwarded, and a secondary subnet for the link test

mechanism. In general, redundant router ports are connected by a layer 2 aggregation

network and must be in a single IP subnet (with exception of DLU-IP).



A30828-X1187-U125-3-7619 35

OperationSURPASS


Routing protocols should be configured in such a way that the local link test subnets are

not advertised to other routers. Thus, the same link test subnet addresses can be re-

used in multiple locations.

Route metric

At each gateway or router two alternative paths to a destination site will exist - a default

route and an alternative route. The default route is the lower cost route. Detecting a fail-

ure of the default route the edge router has to switch very fast to the alternate route in

order to minimize service impacts.

In order to support that fast switch over, the network operator has to administer the sub-

net interfaces at each edge router with appropriate "costs". The edge router will distrib-

ute information on the subnets and associated costs via routing protocols to the core

routers. In that way all routers within the network learn the lowest cost route to the hiG

1600.

The lower cost and higher cost route become relevant in case the crosslink between theL2 switches inside the hiG 1600 LAN fails. Then all hosts will switch over their Ethernet

interface to the LAN side, on which the primary default gateway (with the lower cost

route) is connected. This ensures, that all hosts can still receive and send IP packets

to/from the network. If they switch to the other LAN side then they will not receive IP da-

tagrams from the IP network.

Lower cost routers must be consistently connected to network plane 0, otherwise

some hosts may be disconnected from the network during a crosslink failure.

For each traffic type - more precise for each subnet - lower cost and higher cost

routes have to be defined.

Router crosslinkA crosslink between the redundant edge routers as shown in Fig. 2.17 "Router crosslink

- normal traffic" is recommended to ensure fast rerouting of traffic in case of router inter-

face failures. In general, such a crosslink must exist when each edge router only has a

single uplink into the core. It may also exist when each router has redundant uplinks.

The crosslink between routers should be designed to protect against a complete L2

switch failure, i.e. it should be able to handle the full traffic volume of all router ports con-

nected to one L2 switch.

Fig. 2.17 Router crosslink - normal traffic

In case of a failure of the connection between router and L2 switch, downstream packets

should be locally rerouted via the redundant router as shown in Fig. 2.18 "Router



36 A30828-X1187-U125-3-7619


crosslink - local rerouting". Depending on the router implementation, a local routing table

update is generated immediately or after the routing protocol has re-converged

Fig. 2.18 Router crosslink - local rerouting

To ensure a fast recovery of downstream traffic, it is recommended to configure static

routes in primary (lowest-cost) edge router ER0 pointing to the secondary router ER1 as

next hop for the directly attached media gateway subnets (assuming a direct cross-con-

nection does exist). These static routes will be used until the routing protocol has updat-

ed all routing tables. Tests have shown that some implementations (Black Diamond,

ERX) take up to 10 seconds to complete re-routing, in which case the static backup

route is strictly required.

The static backup route needs to have a cost that is higher than the route metric of the

secondary router, otherwise the IGP would not re-converge on the secondary router

(see Fig. 2.19 "Router crosslink - traffic redirection"). The backup route is needed only

on the primary router, as long as we can ensure that this router is always used in normal

operation. If that cannot be guaranteed, then a similar backup route is also needed on

the secondary router. If such a route is configured on the secondary router, its route met-

ric must also be high enough so that the lowest cost route remains via the primary router

(otherwise the crosslink would be used even in normal operation).

Fig. 2.19 Router crosslink - traffic redirection

Once the routing protocol has converged, traffic will be re-directed around the failed

router interface as shown in Fig. 2.19 "Router crosslink - traffic redirection". This is

again a stable situation until the connection between ER0 and L2 switch has been re-

stored

Note that a similar routing convergence problem may exist also in upstream direction

when the edge router has a single connection to the core. When the uplink to the core



38 A30828-X1187-U125-3-7619


IP subnet configuration

Subnet variants:

• One subnet per interface

Layer 3 switches can be used as a simple router replacement, in the sense that eachphysical network interface must have at least one IP subnet assigned. In this case,

different IP subnets must be provided for each hiG 1600 connected to the L3 switch.

In total, there will be three subnets per hiG 1600 (payload, control or OAM traffic),

plus one subnet for the backbone uplink and one subnet for the crosslink between

the redundant switches.

To optimize failover performance, each PSC frame should have an internal crosslink

between the PS-E boards 0 and 1.

Due to the large number of required IP subnets, this configuration is only recom-

mended when a small number of hiG 1600 frames is connected to the L3 switch.

• Single subnet for multiple PSC frames

A more efficient use of subnets is possible by connecting multiple PSC frames to a

single VLAN and IP subnet. Here, the internal aggregation is based on a L2 VLAN

that includes the payload interfaces of all hiG 1600 shelves (additional VLANs are

needed for control and OAM interfaces). The crosslink is both a layer 2 and a layer

3 interface. A layer 3 route must be provided as a backup path to the backbone via

the second switch, either by a static route or via a layer 3 routing adjacency. Due to

the L2 crosslink between the switches, additional crosslinks internal to the PSC

frame are not permitted here.

This configuration is recommended when more than two hiG 1600 frames are con-

nected to the L3 switches.

MAC address uniqueness

Although Ethernet interfaces of a layer 3 switch can be assigned different IP addresses,they share the same MAC address. Thus it is not possible to address the ports uniquely

by their MAC address alone.

As long as VLAN separation as described in this document is used consistently, the

MAC address issue is irrelevant because MAC addresses are applied on a per VLAN

basis. The same MAC address may be used on different ports as long as these ports

belong to different VLANs. Problems will only arise when the same MAC address ap-

pears on multiple ports belonging to the same VLAN.

2.6 hiG 1600 hardware

This section provides a brief overview about the hiG 1600 components and their func-tions on module level.

2.6.1 Frames/shelves and racks

Generally the hiG 1600 modules are plugged in frame F:PSC(D). This is an ETSI com-

pliant frame with front cabling.

Each F:PSC(D) has just one shelf that allows mixed operation of PSC-C and VMC.

iRefer to the Construction Manual and Product Data Sheets for further details and for

hardware configuration variants. Refer to your site-specific documentation for details on

your current configuration (e.g. capacity stages).



A30828-X1187-U125-3-7619 39

OperationSURPASS


One basic shelf comprises one “PSC unit” alternatively you can cascade basic and ex-

tension shelf via ECON to one PSC unit and aggregate the corresponding IP uplinks via

one PS-E pair.

The maximum capacity stage for one PSC(D) basic shelf is

• 5x FPU-E consisting either of

– 5x Packet Service controller Card (PSC-C)

plus optional special equipment (LTU:S)

– 5x Voice Module Card (VMC)

– mixed configuration employing PSC-C and VMC

• 2x Packet Switch Type Ethernet (PS-E)

• 1x STMI (optional), consisting of working and protecting part

The maximum capacity stage for one PSC(D) extension shelf is

• 5x FPU-E consisting either of

– 5x Packet Service controller Card (PSC-C)

plus optional special equipment (LTU:S)

– 5x Voice Module Card (VMC)

– mixed configuration employing PSC-C and VMC

• 2x Connector Board for Ethernet Switch (ECON)

• 1x STMI (optional), consisting of working and protecting part

Interfaces per PSC shelf/frame

One PSC shelf can have the following interfaces:

• TDM interfaces

– 80x E1or

– 63x E1 (optionally via STMI) + 16x E1 directly

or

– 40x LDI (8x per PSC-C)

or

– 40x SN interface (8x per VMC)

• Uplink interfaces to IP network (per PS-E)

– 1x GE (for payload traffic only or for payload and embedded OAM/control traffic)

– 1x FE (dedicated control interface, i.e. for separated control traffic)

– 1x FE (dedicated OAM interface, i.e. for separated OAM traffic)

– 1x FE (payload interface in configurations with low traffic volume)• Other interfaces in a PSC(D) shelf

– 1x GE for crosslink between PS-Es

– 2x power supply input

– 2x clock synchronization input (one input per PS-E)

– 2x clock synchronization outputs (one output per PS-E) for daisy chaining

– 5x recovered line clock output (one per PSC-C)

– Alarm interface (containing eight alarm inputs)

– Interface to cascading frame (containing FE and clock interfaces)

– optional: 2x T4 clock synchronization output from STMI

– optional: 1x T3 clock synchronization input for STMI

i The PSC shelf has a redundant power distribution system. You can switch between theredundant power supply feeders without interrupting payload.



40 A30828-X1187-U125-3-7619


Racks for hiG 1600

One hiG 1600 rack R:PSC(B) contains a maximum of four PSC(D) shelves (frames).

Each rack contains several fans for forced air convection.

For small configurations the PSC-Cs of the hiG 1600 can be plugged in frameF:DLUG(A) which itself is plugged in a DLU rack (R:DLUG). This configuration variant

is called DLU-IP, see 5 "DLU-IP".

2.6.2 hiG 1600 modules

A hiG 1600 can contain these modules:

• ESB (= functional unit PS-E)

Module labeling M:SLMI:ESB

Refer to 2.6.2.1 "Ethernet Switch Version B (ESB)"

• PSC-C (part of functional unit FPU-E)

Module labeling M:FPPxy

(Can be plugged in PSC(D) or in DLUG frame.)

Refer to 2.6.2.2 "Packet Service Controller Card Type C"

• VMC (part of functional unit FPU-E)

Module labeling M:MP480

Refer to 2.6.2.3 "Voice Module Card (VMC)"

• Special equipment plugged in “LTU:S” (optional part of functional unit FPU-E)

Module labeling depending on module variant

Refer to 2.6.2.7 "Special equipment"

• STMI (= functional unit STMI)

Module labeling M:STMIx

Refer to 2.6.2.6 "Integrated SDH (STMI)"

• ESB connector card (ECON)Module labeling M:ECON

Refer to 2.6.2.5 "ESB Connector Card"

• Alarm distributor AD:RAL

(Connectors and DIP switches)

Refer to 2.6.2.8 "Alarm Distributor"

• Interface module GBIC (for PS-E)

Module labeling M:GBICx

Refer to 2.6.2.9 "GBIC"

• Voice Module (VM)

(daughter board on PSC-C or VMC, this is no individual replacement unit)

Refer to 2.6.2.4 "Voice Module"

2.6.2.1 Ethernet Switch Version B (ESB)

The ESB is the hardware for the functional unit PS-E.

The ESB incorporates these functions:

• "ESB as Layer 2 Ethernet switch"

• "ESB as TDM clock synchronization/distribution unit"

• "ESB as alarm handler unit"

ESB as Layer 2 Ethernet switch

The ESB is a managed Layer 2 Ethernet switch that aggregates the VoIP payload, OAMand control traffic.



A30828-X1187-U125-3-7619 41

OperationSURPASS


The ESB can work in

– in non-redundant mode (one module)

or

– in redundant mode (two modules).

Main functions:

• Data traffic aggregation

Incoming data from PSC-C/VMC is aggregated into one Gigabit Ethernet or one

100bT Ethernet uplink to the packet-based network

• OAM traffic distributor/hub

VM, STMI, ESB are distinct units for NetManager

• OAM/control traffic separator

Optionally the ESB aggregates control traffic and/or OAM generated data traffic on

separate FE uplinks. This allows the separation of control and OAM traffic from the

VoIP data traffic for security reasons.

These frame formats are supported by ESB in any combination: – Ethernet V2

– 802.3 with LLC/SNAP

– VLAN tag

– IPv4

ESB as TDM clock synchronization/distribution unit

The ESB allows to synchronize TDM outputs to an external reference clock. In the event

that the external clock fails the ESB provides an internal free running clock.

To do this the ESB usually operates with 2048 kHz (or 1544 kHz BITS) input from an

external reference clock generator and offers various outputs with 2048 kHz towards

other ESBs (via daisy chaining) and with 8 kHz towards the PSC-Cs/VMCs.

ESB as alarm handler unit

External alarm sensors from inside and outside the rack can be connected to the ESB.

The external alarm sensors are connected to both ESBs in a PSC shelf via one cable

from the AD:RAL to the backplane. Due to the limitation of the AD:RAL a maximum of

eight external alarm sensors can be connected to the ESB.

Any status changes of the alarm inputs are sent by ESB to NetManager via SNMP.

The ESBs in one shelf of a rack are configured as alarm handler for this specific rack.

One ESB automatically becomes the actual alarm source (alarm master) towards Net-

Manager. The alarm handler on the other ESB stays in stand-by mode and takes over

in the event that the alarm master fails.

ESB hardware

Module HW no.S30813-

Remark

SLMI:ESB Q364-X Ethernet switch module type B

Tab. 2.5 ESB module variants



42 A30828-X1187-U125-3-7619


* Several physical GE interfaces are provided by pluggable GBIC modules. These mod-

ules are considered as part of the cabling, see 2.6.2.9 "GBIC".

All ESB interfaces support full duplex operation.

Alarm inputs via AD:RAL (mechanical switches, connected to system ground)

– an alarm is detected if the voltage on the inputs drops below a DC threshold of 0,7Vand an alarm is removed if the voltage on the inputs rises above a DC threshold of

Interfaces Remark:

1x Gigabit Ethernet (uplink inter-

face) *

uplink to edge router/switch

(for payload traffic only or in embedded configura-tions for payload and OAM and/or control traffic)

1x Fast Ethernet (uplink inter-face)

uplink to edge router/switch for OAM traffic(in configurations with dedicated OAM interface)


uplink to edge router/switch for control traffic(in configurations with dedicated control interface)


uplink to edge router/switch for payload traffic(in configurations with very low traffic volume, amaximum of 16 E1 interfaces can be connected toone PSC (D) frame)

Internal interfaces to other modules within the PSC(D) shelf, or to extension shelf:1x Gigabit Ethernet * cross channel to partner ESB

10x Fast Ethernet 2x Fast Ethernet per PSC-C/VMC via backplane(basic shelf)

10x Fast Ethernet 2x Fast Ethernet per PSC-C/VMC via ECON andcable (extension shelf)

5x Clock to PSC-Cs/VMCs (basic shelf)

5x Clock to PSC-Cs/VMCs (extension shelf)

1x Ethernet 10BaseT to the optional STMI via backplane (OAM traffic forSTMI)

11x External alarm interface to AD:RAL, eight external alarm inputs can be oc-cupied plus one cable supervision to AD:RAL

1x TDM clock reference input to external TDM clock source

1x TDM clock reference output can be used to establish a clock daisy chain withina rack, internal ESB clock

Tab. 2.6 Interfaces at ESB

Cable connector Remark

120 Ohms, symmetric cable G.703, world market

75 Ohms, coaxial cable G.703, world market

100 Ohms, symmetric cable GR-499-CORE, US market

Tab. 2.7 Reference clock inputs at ESB



A30828-X1187-U125-3-7619 43

OperationSURPASS


1,8 V

or

– vice versa.

2.6.2.2 Packet Service Controller Card Type C

The Packet Service Controller card (PSC-C) consists of a Feature Processor Type P

(FPP) together with an integrated voice “submodule” (refer to 2.6.2.4 "Voice Module").

The Feature Processor Type P works as controller and power supply for the Voice Mod-

ule. It provides interfaces and operates as group clock generator and multiplexer.

Furthermore the Feature Processor Type P is responsible for call processing, feature

handling and maintenance activities.

The PSC-C can be plugged in the DLUG shelf (DLU-IP) or in the PSC shelf (hiG 1600).

i You can configure at the ESB how to evaluate the alarm inputs (i.e to consider the con-tacts as “normally close” or as “normally open”.


TDM interfaces

M:FPPDH Q372-X 16x PCM30 (E1) interface (120 Ohms) for DLU-IP

M:FPPYH Q373-X 16x PCM30 (E1) interface (75 and 120 Ohms)

M:FPPSH Q375-X 16x pseudo PCM30 interface, compatible to M:STMI

M:FPPL Q374-X 8x LDI interface, 4 Mbit/s

Tab. 2.8 PSC-C module variants

Interfaces Remark:

2x 100bT Ethernet payload uplinks, one to each ESB

2x 100bT Ethernet OAM links, one to each ESB

2x Reference clock inputs Use one clock input per PS-E

1x Recovered Line Clock Output Use one recovered line clock output per PS-E(i.e. use a different PSC-C for each PS-E)

3x RS232 in one DB9 connector, only for TAC

TDM interfaces Refer to Tab. 2.8 "PSC-C module variants"

Interface to LTU:S Interface for optional service module(except on M:FPPD)

4x 2x 8 Mbit/s (internal interface) to VM

3x 100 bT (RMII, full duplex) to VM (2x payload, 1x OAM/control)

Tab. 2.9 Common interfaces at PSC-C



44 A30828-X1187-U125-3-7619


2.6.2.3 Voice Module Card (VMC)

The Voice Module Card includes the integrated voice “submodule” (Refer to

2.6.2.4 "Voice Module").

The Voice Module Card does not provide any feature processing functions. It suppliesan SN interface for the VM and allows an upgrade of existing EWSD sites to hiG 1600

by reusing the LTG equipment. The external LTGs take over the part of the Feature Pro-

cessor in this hardware variant of hiG 1600.

The Voice Module Cards in the PSC shelves are connected to the LTG shelves by new

cables replacing the SN cables.

Module HW no. S30813- Remark

M:MP480 Q370-x four redundant SN interfaces

Tab. 2.10 Voice Module Card

Interfaces Remark:

4x 2x8 Mbit/s (internal interface) to VM

4x 2x8 Mbit/s 8x SN interface to LTGx via front cabling

3x 100bT to VM

2x reference clock inputs Use one clock input per PS-E

2x 2x 100bT (FE) 2x FE per ESB

Tab. 2.11 Interfaces at Voice Module Card

VMC con-nected to

Connection variant to LTG

1x LTGP 1x quad SN cable on SN-IF0plus1x quad SN cable on SN-IF1

4x LTGN 1x quad SN cable or 4x single SN cable on SN-IF0plus

1x quad SN cable or 4x single SN cable on SN-IF14x LTGHor4x LTGD

4x single SN cable on SN-IF0plus4x single SN cable on SN-IF1

Tab. 2.12 Connection variants Voice Module Card to LTG



A30828-X1187-U125-3-7619 45

OperationSURPASS


2.6.2.4 Voice Module

The Voice Module (VM) is a submodule that can be located on the Packet Service Con-

troller Card (PSC-C, module labeling M:FP-P) or on the Voice Module Card (VMC, mod-

ule labeling M:MP480) and supports a maximum of four feature processing functions.

The main tasks of the VM are

– 8x physical 8 Mbit/s termination to FP-P or LTG-P, -N, -D

(4 x 8 Mbit/s used when connected to FP-P on PSC-C)

– VoIP Codec processing (including corresponding tasks) and forwarding of voice/fax

to the Ethernet switch (ESB).

– Conversion of HDLC-based ACP message channels from TDM side into SCTP-

based format on IP side

The VM provides 508 VoIP bearer channels plus eight ACP signalling channels and canoperate with voice CODECS G.723, G.729, G.711 or G.726.

The IP voice packets are provided via two redundant 100bT Ethernet interfaces towards

the Ethernet switch.

The VM exchanges control information from external devices via its Ethernet payload

interfaces or via dedicated OAM interface.

On the PSC-C the VM is connected to the Feature Processor Type P via high-speed

message channel to reduce SW download time. On the VMC the VM is connected to the

external Feature Processor(s) (LTGx) via standard message channel(s).

2.6.2.5 ESB Connector CardIn the extension PSC shelf instead of the ESB modules an ESB Connector card

(ECON) is plugged.

The ECON offers the possibility to cascade two PSC shelves via one pair of ESB mod-

ules. This kind of configuration allows optimized usage of GE uplink bandwidth.

The ECON routes the FE and clock signals between PSC-C/VMC modules and the ESB

in the PSC basic shelf. To do this the ECON carries short signal connections between

several backplane pins.

2.6.2.6 Integrated SDH (STMI)

The optional STMI is a SDH multiplexer/demultiplexer unit that aggregates E1 lines to

channelized STM-1 and vice versa.

iThe Voice Module cannot be unplugged from the PSC-C or VMC. In the event of a fail-

ure the respective PSC-C or VMC has to be replaced.

Module HW no. S30813- Remark

M:ECON Q394-X...

Tab. 2.13 ECON module

iThis manual provides just a brief overview about STMI. For further details, refer to the

UMN:STMI.



46 A30828-X1187-U125-3-7619


This STM-1 interface aggregates up to 63 TDM E1 interfaces towards the first 4 of

the possible 5 PSC-Cs in the same PSC shelf.

The STMI has its own redundancy concept, providing STM-1 interface redundancy. This

redundancy concept is independent and transparent for the rest of the hiG 1600 unit.

The STMI comprises these modules:

– A base module as working module or a protection module

– External STM-1 electrical interface module

– External STM-1 optical interface module

The base module is connected to the external uplink interfaces via SIPAC backplane

connector. The external interface modules (GBIC modules) are plugged in the connec-

tor area of the PSC frame (rear side of backplane). The corresponding STM-1 interface

to the TDM network is accessible from the front side of the shelf.The STMI OAM interface is a 10bT Ethernet interface, which is connected to the active

PS-E. In case of a switch over, i.e. the PS-E to which the STMI is connected becomes

the standby unit, the STMI will still be connected to the same unit. OAM traffic from NetM

to STMI will then flow through the active PS-E and via cross channel through the stand-

by PS-E and vice versa.

i

The hiG 1600V2 needs the “ISDH” variant of STMI which supports IP tunneling. The

standard SMA1K does not support IP tunneling.

iThe STMI is a separate entity towards network management that is managed from

TMNS-C.

Module HW no.

S30813-

Remark

M:STMI(W) Q380-x working unit

M:STMI(P) Q381-x protecting unit

M:STMI:E Q382-x electrical STM1 uplink interface module

M:STMI:OLX Q383-x optical STM1 uplink interface module (long haul)

M:STMI:OSX Q384-x optical STM1 uplink interface module (short haul)

Tab. 2.14 STMI module variants

Interfaces Remarks:

1x STM1 (2x STM1 in redundantmode)

Connect to circuit-switched network (e.g. EWSDswitch) for payload

63 x 2Mbit/s (internal interface,non-standard E1 interface)

Connect to PSC-C for payload

1x 10bT (working STMI) Connect to ESB (reachable by standby ESB viaESB cross connect channel) for OAM traffic relay

2x T4 clock output Driven by active STMI module, only

1x T3 clock input Routed to both modules in parallel

Tab. 2.15 Interfaces on STMI modules



A30828-X1187-U125-3-7619 47

OperationSURPASS


2.6.2.7 Special equipment

To provide additional services (for example hiG 1600 as large conference server) differ-

ent service modules can be plugged in the PSC(D) frame at mounting location LTU:S

next to each PSC-C.

Special equipment for hiG 1600:

• PHMC providing packet data handling via V5.2

(4x V5.2 interface for four Feature Processors)

• ATCO (= ATE + COUC)

test equipment and conference unit

For further information on special equipment, refer to the Construction Manual.

2.6.2.8 Alarm Distributor

The alarm inputs of the alarm distributor are connected to both PS-Es that are located

in one shelf. However, there is a single alarm distributor per shelf and only one shelf

within a hiG 1600 rack is connected to this alarm distributor via a cable.

The alarm input “EAL 10” is used to detect whether the cable to the alarm distributor is

plugged.

For further information on AD:RAL, refer to the Construction Manual.

2.6.2.9 GBIC

The following GBIC modules can be plugged in the hiG 1600:

V.24 at front panel for TAC, only

Interfaces Remarks:

Tab. 2.15 Interfaces on STMI modules


Remark

M:GBIC:LX U1682-X 1000Base-LX(optical, 1310nm, single mode fiber, dual SC)

M:GBIC:SX U1683-X 1000Base-SX

(optical, 850nm, multi mode fiber, dual SC)

M:GBIC:T U1963-X 1000Base-T(electrical, distant station must support 1000Base-Tauto negotiation)

Tab. 2.16 GBIC module variants



A30828-X1187-U125-3-7619 49

OperationSURPASS


3.1.1 Management concept

The hiG 1600 equipment is managed with the NetManager V5.1 and APS

NEM51ECR0984, or higher via IP network.*

– The Feature Processor (LTGx/FPP) and the LTU:S is addressed by NetManager via

the MML interface of hiE 9200 (using ACP over SCTP).

– The Voice Modules and Packet Switches Ethernet are directly addressed by Net-

Manager using SNMP.

*You can find NetManager’s APS version in NetM Information (“General” tab).

The NetManager comprises of

• NetManager base system

(extended with hiG 1600-specific task database package, see Tab. 3.2)• NetManager applications on network and service management level

(These come with their own documentation and are not subject of this manual.)

For further details on your current NetManager APS, refer to your Release Documenta-

tion.

Management tasks for hiG 1600

• Network management

(Preparing the OAM network)

– NE group administration

– NE administration

• Configuration management *

– Basic configuration and system setup for nodes (BCSS), including node-specificsecurity management (SNMP access list)

– Basic configuration tasks via Workbench

– Network containment and status monitoring via Containment View

• SW management via SW Management (see 4 "Maintenance")

– SW backup/restore

– SW update

– Reboot

• Fault management (see 4 "Maintenance")

– Alarm surveillance (e.g. AMD, NTM, Alarm Console)

– Symptom saving (e.g. Log Viewer, Error Notebooks)

– Fault clearance, trouble shooting (AMD, Work Order Viewer, Interactive Docu-ment Browser, Containment View)

* The tasks via the NE-specific management interface for the optional STMI equipment

are described in UMN:STMI

iThis manual assumes that NetManager is prepared to manage hiG 1600 NEs (e.g. hiE

9200 TP installed, appropriate applications configured correctly and assigned to users,

etc.). For further details, refer to the NetManager Administration Manual.

iCreating nodes with BCSS sets up the OAM connection to NetManager and is a prereq-

uisite for managing these nodes with NetManager’s Workbench.

http://u190.pdf/

http://u190.pdf/



A30828-X1187-U125-3-7619 51

OperationSURPASS


SNMP network structure for hiG 1600

For DLU-IP there are only network elements containing FPU-E nodes and virtual MML

network elements. Thus the SNMP network structure for DLU-IP differs from the struc-

ture for hiG 1600.

A hiE 9200 network element group (= hiE 9200 domain) contains

• hiE 9200 network element(s)

• PSC network element(s) and/or hiG 1600 network element group(s)

A hiG 1600 NE group comprises at least one PSC network element which is a logical

container for two types of nodes (PS-E, FPU-E).

A PSC network element comprises these items:

– Two (redundant) PS-E nodes (not relevant for DLU-IP)

– At least one FPU-E node – LTG identifiers (displaying associated LTGs)

– A “logical MML node” *

*The logical MML node stands for MML-managed components in hiG 1600; i.e. LTGx or

Feature Processors and special equipment in LTU:S.

Administrative tasks:

• Network elements have to be created and grouped with NE group administration

first before nodes can be created with BCSS, see 3.2 "NE group and NE adminis-

tration for hiG 1600".

• The PS-E/FPU-E nodes have to be created with BCSS first before they can be ad-

ministrated via Workbench, see 3.3.2 "Managing PS-E nodes using BCSS" and

3.4.2 "Managing FPU-E nodes using BCSS".• LTG identifiers and logical MML nodes are created automatically with NE/node cre-

ation.

Using NetManager’s Workbench for hiG 1600

PS-E/FPU-E nodes that have just been created with BCSS need further basic configu-

ration with the Workbench, see 3.3.4 "Configuration tasks via Workbench for PS-E" or

3.4.4 "Configuration tasks for FPU’s Voice Module".

You can start the Workbench within the context of a NE group and you can open indi-

vidual network elements or nodes (SNMP-managed as well as MML-managed) within

the selected NE group without restarting the workbench.

– For configuring a LTGx/FP-P or LTU:S of a hiG 1600 you have to select the corre-sponding hiE 9200 and to use the provided tasks (MML tasks) to create the compo-

nents in the database of the hiE 9200.

– For configuring a Voice Module you have to select the Voice Module and to use the

provided tasks (SNMP tasks).

– For configuring a PS-E you have to select the PS-E and to use the provided tasks

(SNMP tasks).

A detailed description for each task can be found in the Task Manual.

iPlease regard when planning your network that a suitable naming scheme is necessary

to recognize which entities belong to a specific hiG 1600 unit.



52 A30828-X1187-U125-3-7619


System status monitoring

The current states of all network elements or nodes belonging to your hiG 1600 can be

viewed with the Containment View application. This application shows the current node

state but not the trap history.

In general the Containment View displays states for the hiG 1600 as a result of certain

SNMP messages (traps), or as a result of the auto discovery procedure, i.e. the Con-

tainment View informs you whether and why a hiG 1600 component is down/up.

Additionally you are informed about any MML alarms (using the logical MML node).

You can group all PSCs at one location to one hiG 1600 NE group and assign all

hiG 1600 NE groups that are controlled by the same hiE 9200 to the corresponding

hiE 9200 NE group (domain).

The following figure shows how a hiG 1600 unit is displayed in Containment View.

Fig. 3.1 Example of hiG 1600 or PSC network element in Containment View

In the above example the network element (T08_hiG1600 V2_05) contains

– two PS-E nodes (ESB-...)

and – five FPU-E nodes (FPP-...).

This equals one fully equipped PSC(D) shelf.

Additionally there is one logical node per PSC showing an alarm summary of all MML-

based alarms for this PSC network element in the Containment View.

Example for logical MML node with alarm:

iDepending on your current NetManager APS the actual icons in the Containment View

may differ from the ones shown in this manual. Fordetailed information on current icons,

refer to NetManager’s online help.

iTo keep track on latest changes you should employ Containment View’s “Automatic Re-

fresh” function.



A30828-X1187-U125-3-7619 53

OperationSURPASS


Fig. 3.2 Example of logical MML node (with alarm)

This logical MML node is automatically created and gets the same name as the corre-

sponding network element itself. You can open the Alarm Message Display showing fil-

tered MML-based alarms for this location via context menu.

For further details refer to 3.4.3 "Monitoring FPU-E using Containment View" or

3.3.3 "Monitoring PS-E using Containment View" respectively

If you have optional STMI equipment then you also have to monitor an STMI network

element and a TMNS-C network. For further details refer to the UMN:STMI.

3.1.2 Overview about manageable entities and management systems

Depending on the configuration the hiG 1600 can contain the following manageable en-

tities:

• FPU-E*

There are two hardware variants for FPU-E:

– PSC-C plus optional special equipment in LTU:S

– VMC plus external LTGx (including optional special equipment)

• PS-E (two redundant units)

• STMI (working unit, protecting unit) **

* The FPU-E is a multi module compound that requires management via SNMP andMML. This manual treats the SNMP part mainly.

** The STMI is grouped below specific network elements and is treated in the

UMN:STMI.

For detailed information on individual modules, refer to 2.6 "hiG 1600 hardware".

Naming of hiG 1600 equipment in NetManager:

iThere is no alarm status mapping to the “LTG-IDs” that are displayed under the FPU-E

nodes. The LTG-IDs are just displaying the database correlations.

iYou can find trouble shooting information in 4 "Maintenance".

http://u190.pdf/

http://u190.pdf/

http://u190.pdf/

http://u190.pdf/



54 A30828-X1187-U125-3-7619


Functional unit Module(s) CV BCSS Remark

PS-E M:SLMI:ESB PS-E node:

“Equipment name”= <node

name entered via BCSS>

Type = ESB-V.C

ESB or ES The node nameentered

viaBCSS should contain

the physical location of

the module.

The node name is used

as parameter “EQN” in

corresponding BOAM

tasks.

PSC-C inFPU-E M:FFPxy FPU-E node:

Node name as entered via

BCSS

Type = FPU-E V1.0

Equipment name for VM:

FPU#-shelf#-slot#

Feature Processor associa-

tions:

LtgId_...Type = ltg

FPU From the functional point

of view there is no differ-

ence between VMC and

PSC-C.

In the CV the hardware

variants are not distin-

guished.

VMC in FPU-E M:MP480 FPU-E node:

Node name as entered via

BCSS

Type = FPU-E V1.0

Equipment name for VM:

FPU#-shelf#-slot#

Feature Processor associa-

tions:

LtgId_...

Type = ltg

FPU

STMI M:STMIx TNMS-C node:

Equipment name depends on

node name entered via BCSS

Generic

node

STMI comeswith itsown

Management system

(TNMS-C). For further

details, refer to

UMN:STMI.

MML-managed

modules

Feature Pro-

cessorand/or

special

equipment in

LTU:S

logical MML node

“Equipment name” =

<name of hiG 1600 network

element>

Type = MMLQ3SNMP

n.a. The logical MML node is

created automatically.

AD:RAL Not managed

ECON Not managed

Tab. 3.3 hiG 1600 equipment in NetManager

http://u190.pdf/

http://u190.pdf/



A30828-X1187-U125-3-7619 55

OperationSURPASS


Fig. 3.3 Functional units and modules of hiG 1600

Fig. 3.4 Management systems for hiG 1600



56 A30828-X1187-U125-3-7619


Fig. 3.5 hiG 1600 objects that are displayed in Containment View

3.1.3 General configuration rules

Any data for hiG 1600 that has been entered via Workbench should be saved with

a backup (see 4.8 "Backup/restore hiG 1600 database"). Otherwise these data will get

lost after a reboot.

Location data for Voice Module and Feature Processor

• Relation between Feature Processor and Voice Module stored in hiQ 9200 data-

base:

Create LTGx/FP-P in hiQ 9200 database with “CR LTG” and enter location data for

LTGx/FP-P and corresponding VM (e.g. room, rack position)

• Relation between Voice Module and Feature Processor stored on the VM and in

NetManager:

Create a FPU-E node with BCSS and enter location data (e.g. FPU-E#-shelf) andthe name of the corresponding LTGx/FP-P (CP-LTG=<ltgset-ltg>)

To get correct link alarms in NetM

– set not connected VM/PS-E ports to administrative state “down”

– deactivate not used E1 links on STMI via TNMS-C (60-63 and additionally 29-32 in

non-redundant or dial-in configurations)

– set not connected alarm sensors to “unconnected”

(if PS-E is employed as alarm handler unit)

– deactivate not connected alarm handler unit in BCSS

(if PS-E is not employed as alarm handler unit)

!There are no consistency checks between hiE 9200, Voice Module and NetM databas-

es. You have to take care that all data are consistent and that any changes are done in

all affected databases.



A30828-X1187-U125-3-7619 57

OperationSURPASS


The recommended numbering scheme for FPU-E number and shelf number is ac-

cording to the rack equipment order:

• Shelf number = number of mounting unit

• Start with the lowest mounting unit

• Start from left to right

• Continue with the next mounting unit, from left to right

• Numbering is consecutive, equipment gaps are not considered

Default polling time in the SNMP network

In BCSS there are default time values for polling the SNMP nodes from NetManager.

Decreasing these default polling time values leads to unnecessary load in the SNMP

network and should be avoided unless explicitly required.

Embedding of hiG 1600 in network environment

For further details on embedding in the network environment, refer to

2.5 "Configuration guidelines for hiG 1600 and environment".

3.1.4 Starting hiG 1600-specific functions from Containment View

The NetManager provides shortcuts to start operations for hiG 1600 via context menu

from Containment View.

This context menu offers

• default entries

(not treated in this manual, refer to NetManager documentation or online help)• product-specific entries for the hiG 1600

(PS-E or FPU-E)

Using the context menu on hiG 1600 NE level:

1. Right click on the NE

2. Select “Launch”

3. Select the application to be started with NE-specific presettings:

– Workbench

– NE Admin – Interactive Document Browser

– Alarm Message Display

– Containment View

4. Done

Using the context menu on hiG 1600 node level:

1. Right click on the PS-E or FPU-E node

2. Select “Launch”

3. Select the application and the function within the selected application (if applicable)

to be started with node-specific presettings:

– SW Management ->...

– BCSS ->...

!You have to regard several dependencies on the network environment when configur-

ing a hiG 1600 and connected devices (for example switches). Mismatching configura-tions might endanger the operation of the whole network.

iSome functions may be not available because your actual context menu depends on

your user rights.



58 A30828-X1187-U125-3-7619


– Workbench

– Telnet (applies for PS-E only)

4. Done

3.2 NE group and NE administration for hiG 1600

For hiG 1600 you have to integrate network elements as well as nodes in your SNMP

network.

First you have to create the appropriate network elements and network element groups

with the NE Administration before you can create nodes with the BCSS.

General rules for NE and NE group administration:

• The minimum size of one hiG 1600 is equal to one FPU-E (two FPU-Es for redun-

dant configurations).

• The hiE 9200 supports a limited number of feature processing functions. Thus the

maximum number of FPU-Es (each with 1-4x feature processing function) that are

controlled by one hiE 9200 is limited, too.

• The maximum size of one hiG 1600 (number of FPU-Es) depends on the resources

of the corresponding hiE 9200, only.

Please regard the dimensioning rules in your project-specific documentation.

For details on NE and NE group administration with NetManager V5.1, refer to the Net-

Manager Administration Manual, chapter “Setting up an SNMP node of an NE under di-

rect control”.Configuration sequence and product-specific parameters:

1. NE Administration of hiE 9200 network elements

2. NE administration of hiG 1600 network elements

iUsually new equipment is delivered together with the corresponding database by Sie-

mens. Thus manual configuration of NE groups/NEs/nodes is just necessary to modify

or extend existing networks.

Parameter Value Remark

NE type hie9200

Technology package TP923... Select appropriate TP according to yourproject-specific documentation, same TPmust be selected for hiG 1600 NE



A30828-X1187-U125-3-7619 59

OperationSURPASS


3.NE group administration of hiE 9200 NE group

4. Administrate users and access rights for the new NEs and NE groups

For further details, refer to the NetManager Administration Manual, chapter “Manag-

ing Users with NetManager Administration”

5. The new NEs and NE group(s) are available for NetManager users. PS-E and FPU-

E nodes can be created with BCSS now.

Done.

3.3 PS-E management

3.3.1 General

Both PS-E units in redundant systems are separate SNMP nodes (management type

“ESB-V.C”) with their individual IP address for OAM.

Date and time for PS-E nodes

The PS-E acts as the SNTP client and requests the current system time from an SNTP

server. Primary and (optional) secondary SNTP servers are assigned to the PS-E by

BCSS.


NE type hig1600

Associated with <hiE 9200 NE name > Enter the user-defined name of the corre-sponding hiE 9200 NE.

This name must be identical with thevalue entered during hiE 9200 NE cre-ation in step 1.

Located in <location parameterat hiE 9200>

Enter the location value for LTGs(FeatureProcessors) of the new hiG 1600 NE.

This location parameter must be iden-tical with the value entered via “CRLTG” command at hiE 9200.


NE group type hiE9200

Assignment rules:Select exactly one hiE 9200 network element

Select NEs from the amount of hiG 1600 NEs which are associated to this specifichiE 9200 NE type and assign the selected NEs to this hiE 9200 NE group

Contents

3.3.1 "General"

3.3.2 "Managing PS-E nodes using BCSS"3.3.3 "Monitoring PS-E using Containment View"

3.3.4 "Configuration tasks via Workbench for PS-E"



60 A30828-X1187-U125-3-7619


The PS-E requests the valid system time from the NetManager during startup and by

cyclical request. The response from the SNTP server is stored as universal time coordi-

nated (UTC).

For changing SNTP settings, refer to 3.11 "“Time of day” management".

Adding/replacing a PS-E

For replacing a PS-E module, refer to 4.7 "Replacing hiG 1600 modules".

For adding a new PS-E module, refer to "Create PS-E node"

SW Management for PS-E

The PS-E contains in its flash memory one boot image and two sets of runtime images.

Both can be updated through the network using SW Management.

The SW can be downloaded during normal operation. However, the new SW load is ac-

tivated after a reboot.

There are no product-specific menu functions in SW Management.

For further information on SW Management, refer to NetM documentation

For details on SW update, refer to 4.5 "SW update".

For details on backup/restore, refer to 4.8 "Backup/restore hiG 1600 database".

3.3.2 Managing PS-E nodes using BCSS

3.3.2.1 Functions of BCSS plug-in for PS-E nodes

The BCSS plug-in for PS-E extends the menus, context menus and toolbar of the ge-

neric BCSS with PS-E-specific items. It also provides dialogs for creating or editing PS-

E nodes.

These are the PS-E-specific menu extensions in BCSS:

•

Administration -> New Node -> Ethernet Switch Type C(Creating new PS-E node)

You also find a button in the toolbar for creating new PS-E nodes.

• Tasks -> Ethernet Switch Type C -> SNMP Access List

(“White list” for OAM access to PS-E node)

• Administration -> Preference Properties-> Ethernet Switch Type C Plugin

(Consistency checks for PS-E node)

• View -> Toolbar -> Ethernet Switch Type C

(PS-E-specific toolbar)

• Help -> Plugin Help Topics -> Ethernet Switch Type C Plugin

(Supporting help)

• Help -> About Plugins -> Ethernet Switch Type C Plugin

(“About” dialog box)

Contents

3.3.2.1 "Functions of BCSS plug-in for PS-E nodes"

3.3.2.4 "Creating/modifying/deleting PS-E nodes"3.3.2.5 "PS-E preferences"

3.3.2.6 "SNMP access list for PS-E"

3.3.2.7 "Operational PS-E node in BCSS"



A30828-X1187-U125-3-7619 61

OperationSURPASS


The PS-E-specific toolbar extension comprises these icons:

– Icon for the function “create a PS-E node”

– Icon for the function “open the SNMP access list”

The generic menu functions for editing/removing nodes and forced auto discovery areapplicable for the PS-E nodes as well.

3.3.2.2 Overview about PS-E-specific node data

The table below provides an overview about BCSS data for PS-E nodes. For a detailed

description, refer to 3.3.2.3 "PS-E-specific windows in BCSS" and to the NetManager’s

online help.

Parameter Remarks

General Properties tab

Node Name Enter a unique name for your PS-E node (= host name) inthe hiE 9200 domain.You have to describe the physical location of the PS-E inthe node name to find the corresponding module in theevent of a fault.The node name must not exceed 25 characters and mustnot contain the apostrophe character.

SNMP Version Select “SNMPv1” or “SNMPv2c”, default: “SNMPv2c”

Management Type “ESB-V.C.” is the default value

Polling Time “360” is the default value, can be changed

The polling time default value should not be reduced unlessit is required.(polling time range from 10 to 35000)

Primary TDS Name Select a communication server of NetManager as primarytrap destination server (corresponding IP address is updat-ed automatically)

Backup TDS Name Select a second communication server of NetManager asbackup trap destination server (corresponding IP address isupdated automatically)

LAN Specific Data tab

MAC Address Refer to label on your ESB module

Ethernet IP Enter the IP address of PS-E’s interface(This is the PS-E OAM IP address.)BCSS checks whether the entered address is unique.

Default Gateway IP Dependent on network environment

Subnetmask Dependent on network environment

Redundant Gateway IP Dependent on network environment (optional)(BCSS checks whether default and redundant gateway arewithin the same subnet.)Enter “0.0.0.0” if there is no redundant gateway

Tab. 3.4 Required inputs in BCSS to create a new PS-E node



62 A30828-X1187-U125-3-7619


3.3.2.3 PS-E-specific windows in BCSS

To manage the basic data of PS-E nodes start BCSS directly or via context menu for a

specific node from the Containment View.1. General Properties tab for PS-E

ESB Specific Data tab

ESB Mode

- ESB acts in ...- Alarm handler

Operation mode of ES and its network environment

- Redundancy yes/no- Alarm handler disabled/enabled

Password required ... Enter a password for your Telnet access to this PS-E mod-ule (minimum five, maximum 15 characters)

Server Data tab

SNTP Settings- Primary SNTP Server- Sec. SNTP Server- Time Offset

Enter- Primary SNTP server (mandatory)- Secondary SNTP server (optional)- Time offset from UTC in hours and minutes

(range from -12 to +12 hours)

External Trap Destina-tions- Available Entries- TDS List for Node

Add further trap destination servers, if appropriate. You canhave a maximum of four TDS (inclusive your primary andbackup TDS). This can be applied for a redundant NetM orfor a service center, etc.

Parameter Remarks

Tab. 3.4 Required inputs in BCSS to create a new PS-E node



A30828-X1187-U125-3-7619 63

OperationSURPASS


Fig. 3.6 General Properties tab for PS-E

Completion instructions for the General Properties tab:

– With the node name you should provide information where to find the PS-E mod-

ule. Thus it is recommended to include <rack#>-<shelf#>-<slot#> in the node

name (“slot#” is derived from the mounting location).

– When you select the primary and backup TDS the corresponding IP address is

set automatically (the IP address is “read-only”). You can assign further external

TDS (which are not communication servers of this NetManager) via the “Server

Data” tab. – A lower polling time decreases error detection time, but also increases load in

the SNMP network. For further details, refer to NetManager’s online help or to the

NetManager documentation.

2. LAN Specific Data tab for ESB

iThe maximum length of the PS-E node name must not exceed 25 characters. Changing

the node names requires a subsequent manual auto discovery (otherwise the corre-

sponding node will not be accessible from the Workbench).



64 A30828-X1187-U125-3-7619


Fig. 3.7 LAN Specific Data tab for PS-E

Completion instructions for the LAN Specific Data tab

– The MAC address is hardware dependent. Therefore the MAC address has to

be changed, when replacing an PS-E (ESB module). Usually you can find the

MAC address at the frontplate of the module.

– The Ethernet IP is the switch address which is used for OAM.

– Enter gateway IP addresses and subnetmask according to your network environ-

ment.

3. Ethernet Switch Type C-Specific Data tab



66 A30828-X1187-U125-3-7619


Fig. 3.9 PS-E Server Data tab

Completion instructions for SNTP data: – A primary SNTP server is mandatory.

– If you do not use a secondary SNTP server enter “0.0.0.0” in its IP address box.

– Enter the time offset from UTC (if appropriate).

“External Trap Destinations” area

External trap destinations are trap destinations that are not communication servers

within this NetM domain.

There are two kinds of lists:

– Available entries

(lists all external trap destinations assigned to any PS-E node)

– TDS List for Node(lists all external trap destinations assigned to this specific PS-E node)

Completion instructions for “External Trap Destinations”:

– A maximum of four TDS is possible for one PS-E node. That means if there is a

primary and a backup TDS you can add up to two external TDS. Three external

TDS can be added if there is only a primary TDS.

– With the “Add” button you can add an available TDS to the TDS list of this specific

PS-E node

– With the “Remove” button you can delete a TDS from the TDS list of this specific

PS-E node. If this deleted TDS is not used by any other PS-E node then it will be

deleted from the “Available Entries” list automatically.



A30828-X1187-U125-3-7619 67

OperationSURPASS


– With the “new” button you can add another TDS to the “TDS List for Node” list

After closing BCSS this entry is added to the “Available Entries” list.

The IP address of primary/backup TDS is set automatically with TDS selection.

Optionally further trap destinations can be created using the Workbench, see

3.12.1 "Managing external trap destinations for PS-E via Workbench"

3.3.2.4 Creating/modifying/deleting PS-E nodes

The same BCSS windows apply for creating or for modifying nodes (see 3.3.2.3 "PS-E-

specific windows in BCSS").

Nodes can be created/modified (edited) as well as deleted via the BCSS “Administra-

tion” menu.

Alternatively you can call the corresponding BCSS functions via context menu (“New

Node” from NE context menu or “Edit/Delete Node” from node context menu). For exist-

ing nodes you can also double-click on the node or select the “Edit”/”Delete” icon in the

BCSS toolbar.

Create PS-E node

To create a new PS-E node do the following:

1. Collect the required data,

see, 3.3.2.2 "Overview about PS-E-specific node data"

(You will need site-specific documentation for your network environment.)

2. Start BCSS and select an appropriate network element as container for the new

node

3. Select BCSS function “Administration” -> “New Node” -> “Ethernet Switch Type C”

4. Fill-in the PS-E-specific pages

(see, 3.3.2.3 "PS-E-specific windows in BCSS")

5. Save your entries (the new node appears in BCSS overview)

6. Plug the module and connect the OAM uplink at the PS-E

The plugged module boots automatically.

7. In the event that you are adding a new PS-E module:

– Check the SW/FW version with Software Management and update, if required,

see 4.5.2 "SW update on PS-E"

– Check whether your configuration requires other data than the default values and

enter the corresponding configuration data manually via Workbench, see

3.3.4 "Configuration tasks via Workbench for PS-E"

8. Connect the remaining uplinks at the PS-E

9. Make sure that the new node is displayed correctly in BCSS and in ContainmentView (see "Operational PS-E node in Containment View")

!Since BCSS writes the required startup information into the BOOTP file modifications

take effect only after the PS-E has been rebooted. This reboot has to be started manu-

ally. However, modified data for trap destination servers, SNMP access list or SNTP

servers are taken over immediately.

Guidelines

"Create PS-E node"

"Modify PS-E node" (also applies for reading basic configuration node data)

"Delete PS-E node"



68 A30828-X1187-U125-3-7619


10. If appropriate: Edit SNMP access list of new node (see 3.3.2.6 "SNMP access list

for PS-E")

11. Done

Modify PS-E node

To modify an existing PS-E node do the following:

1. Start BCSS

2. Select BCSS function “Administration” -> “Edit Node”

3. Enter your modifications

(see, 3.3.2.3 "PS-E-specific windows in BCSS")

Alternatively you can just read any entries and close the PS-E-specific windows with

“Cancel”.

4. Save your modifications and close BCSS

5. What entries did you change

– Only entries for trap destination servers, or SNTP servers or in SNMP access list

-> Done (your modifications are immediately taken over by the node)

– Entries for trap destination servers, or SNTP servers, or in SNMP access list

and/or other modifications

-> Continue with next step

6. Reboot the new PS-E node

– Start Software Management

– Call function “Tasks” -> “Reboot”

– Confirm this action with “Yes” when asked to do

– In the reboot dialog select option “force DHCP request”

– In the reboot dialog select whether you want to

- load runtime image 0 or runtime image 1

- force default VLAN/port configuration * – Start reboot (press button “OK” in the reboot dialog)

7. On reboot completion make sure that the modified node is displayed correctly in

BCSS (state “active”) and in Containment View (see "Operational PS-E node in

Containment View").

8. Done

* For information on the default configuration, refer to 2.4.6 "Default uplink configura-

tions". For entering a user-defined configuration, refer to 3.3.4 "Configuration tasks via

Workbench for PS-E".

Delete PS-E node

To delete an existing PS-E node do the following:

1. Start BCSS for the node in question

2. Select BCSS function “Administration” -> “Delete Node”

3. Confirm this action with “Yes” when asked to do

4. BCSS deletes the selected node and shows status of the deletion operation. On

completion the node disappears in BCSS.


6. Make sure the deleted node disappears from Containment View

7. Done



A30828-X1187-U125-3-7619 69

OperationSURPASS


3.3.2.5 PS-E preferences

The PS-E preferences are valid for all PS-E nodes in your NetManager domain. Usually

no changes are necessary in this window.

To open the PS-E preferences do the following:

1. Start BCSS

2. Select BCSS function “Administration” -> “Preferences...”

3. In the preferences window select the “Ethernet Switch Type C Plug-in” tab

4. View or modify (if appropriate) the preferences

You should always use the default settings (all consistency checks active),

see Fig. 3.10 "Preferences tab for PS-E"

5. If appropriate: Save your modifications

6. Close BCSS

7. Done

Example:

Fig. 3.10 Preferences tab for PS-E

You can select the kind of data to be checked by node consistency checks and you can

check the following types of node consistency checks:

– On startup

If this checkbox is enabled, then a consistency check for data between the node and

BCSS database is performed for all PS-E nodes after the BCSS Server is started.

The node data is corrected in case of differences

– On activation


BCSS database is performed for a PS-E node after its state goes to active. Thenode

data is corrected in case of differences.

Additionally you can select the following types of BOOTP consistency checks:

– On startup

A consistency check between DHCP data and NetM BCSS database is performed

for all PS-E nodes after the BCSS server is started. The DHCP data are corrected

in case of differences



70 A30828-X1187-U125-3-7619


– On activation


for all PS-E nodes always when the DHCP Server data has changed. The DHCP

data are corrected in case of differences

For further details, refer to the NetManager documentation or to NetManager’s online

help.

3.3.2.6 SNMP access list for PS-E

SNMP access list window for PS-E

To enhance security an authorization function is added to accept or reject SNMP re-

quests based on the originator's IP address. The PS-E maintains an SNMP access con-

trol list with network or host IP addresses and the associated access rights.

By default NetManager communication servers have access to PS-E nodes. Add further

hosts that may have granted access to this PS-E node, if appropriate. The SNMP ac-

cess list can contain a maximum of 49 entries.

Example:

Fig. 3.11 SNMP access list for PS-E

The SNMP access list window contains two panes.

• Available entries (left window pane)

Lists all hosts which have granted access to any PS-E node. All communication

servers of this NetM domain are automatically included.• Access List for Node (right window pane)

Lists all hosts which have granted access to this specific PS-E node. All communi-

cation servers of this NetM domain are automatically included.

Communication servers of the NetManager domain for this PS-E node are marked with

a “key” and can not be removed from the lists.

Guidelines

"Display PS-E’s SNMP access list"

"Add/remove “available” entry to/from PS-E’s SNMP access list"

"Add a “not available” entry in PS-E’s SNMP access list"



A30828-X1187-U125-3-7619 71

OperationSURPASS


Display PS-E’s SNMP access list

1. Select a PS-E node in BCSS

2. In the BCSS menu select the function

“Tasks” -> “Ethernet Switch Type C” -> “SNMP Access List”3. The current SNMP access list is displayed

(see Fig. 3.11 "SNMP access list for PS-E")

4. Close the access list

5. Done

Add/remove “available” entry to/from PS-E’s SNMP access list


A node must be in state “active” to change its SNMP access list. Otherwise the cor-

responding access list is “read-only”.


“Tasks” -> “Ethernet Switch Type C” -> “SNMP Access List”

3. The current SNMP access list is displayed


4. What do you want to do?

– Add an available entry to the PS-E’s access list:

-> Select the entry in the left window pane and press button “>>”

– Remove an entry from the PS-E’s access list

-> Select the entry in the right window pane and press button “<<“

5. Confirm your modifications with “OK”

6. Modifications are immediately taken over in NetManager’s DHCP servers and in the

node

7. Done

Add a “not available” entry in PS-E’s SNMP access list








4. Press button “New”

A “New Access List entry” window appears

– Fill in name and corresponding IP address – The subnet mask is disabled

– Only “read/write” (full access) is possible, thus the “Access Rights” selection list

is disabled.



72 A30828-X1187-U125-3-7619


Fig. 3.12 New access list entry for PS-E node

5. Confirm your modifications and with “OK”

The “New Access List entry” window is closed.

6. Close the SNMP access list with button “OK”


node

8. Done

3.3.2.7 Operational PS-E node in BCSS

An operational PS-E is visible in the BCSS main window with node state “active”.

Example:

Fig. 3.13 Operational PS-E in BCSS

3.3.3 Monitoring PS-E using Containment View

After auto discovery or manual discovery the PS-E’s containment together with its alarm

and operational states is updated in Containment View.

iFor nodes with node state “Error - AD timeout” you can try activation through a forced

auto discovery (“Tasks -> “Start Autodiscovery”).



A30828-X1187-U125-3-7619 73

OperationSURPASS


The PS-E nodes are presented in Containment View as follows:

– The node itself as root (indicated as class “Node”)

– A logical instance for clock sensors and a logical instance for external alarm sensors

(for grouping and propagation purposes, indicated as class “Container”)

– Uplink ports, gateway information, crosslink port

(indicated as class “Port”)

– External alarms sensors and clock alarm sensors (indicated as class “Sensor”)

– VLAN/port configuration information (indicated as class “Sensor”)

There is no module level, because a PS-E node contains only one module.

The Containment View monitors the following PS-E interfaces:

• Four uplink ports and one cross channel (ap25) to redundant PS-E

These ports have to be configured as “connected/not connected”

• Ten external alarm interfaces together with a supervisor interface

(have to be configured as “connected/not connected”, see remarks in Tab. 3.5 "PS-

E interfaces in Containment View")• Two clock interfaces

• TDM clock source interface (no alarming, just for convenience displaying the TDM

clock source EQN)

• Three gateway interfaces

The PS-E containment is displayed as follows in Containment View:

iThe Containment View informs you about the “VLAN/port configuration status” (in

Alarm/Operational State Details row respectively) showing whether the PS-E operates

with a default VLAN/port configuration or whether the PS-E operates with a user-defined

VLAN/port configuration.

Interface EQN Remarks

Uplink and crosslink interfaces

<PS-E node name>-ap21 Uplink port 100BaseT for OAM

<PS-E node name>-ap22 Uplink port 100BaseT for control

<PS-E node name>-ap23 Uplink port 100BaseT for payload (alternative toGE_Uplink for payload)

<PS-E node name>-ap24 Uplink port Gigabit Ethernet

<PS-E node name>-ap25 GE crosslink port between active and standby PS-E

Alarm sensors<PS-E node name>-ExtAlarmSensor_01...<PS-E node name>-ExtAlarmSensor_10

10 alarm interfaces(a maximum of eight external alarm sensors can be con-nected, alarm sensor 09 - 10 shall be unoccupied andconfigured appropriately)

<PS-E node name>-CableSupervisor

Supervisor for cable to AD:RAL(cable to external alarm interfaces)

Clock interface and clock sensors

Tab. 3.5 PS-E interfaces in Containment View



74 A30828-X1187-U125-3-7619


*The EQN of the TDM clock source must have been entered via Workbench. Otherwise

it is not displayed in Containment View.

Here are some examples for the PS-E in Containment View:

Operational PS-E node in Containment View

Example for operational PS-E (this PS-E is not working as alarm handler unit):

Fig. 3.14 Operational PS-E in Containment View

<PS-E node name>-Ref-erenceClockInput

External TDM reference clock input

<PS-E node name>-ClockUnit

TDM clock unit (PLL) of PS-E

<PS-E node name>-<EQN>*

Displays the EQN of the external TDM clock source (noalarms applicable)

Gateway supervision sensors

<PS-E node name>-De-faultGateway

Default gateway for this PS-E

<PS-E node name>-Re-dundantGateway

Redundant gateway for this PS-E

<PS-E node name>-Part-nerESBDefaultGateway

Default gateway at redundant PS-E (at partner ESB)

Interface EQN Remarks

Tab. 3.5 PS-E interfaces in Containment View

iTo evaluate detail information in Containment View for the PS-E, refer to 4.4 "SNMPmessages from PS-E".

"Operational PS-E node in Containment View""PS-E with alarm in Containment View"



A30828-X1187-U125-3-7619 75

OperationSURPASS


Example for PS-E working with user-defined VLAN/port configuration

(see bottom line in Fig. 3.15 "VLAN/port configuration variant in Containment View"):

Fig. 3.15 VLAN/port configuration variant in Containment View

An operational PS-E is indicated as follows:

• Uplink ports (ap21 - ap25)

– Alarm state = “normal”

– Alarm state reason = operational state reason = “-” (not available)

– Alarm state details = operational state details = “-” (not available)

• External alarm interfaces (if PS-E works as alarm handler unit)

(Reasons and details for alarm and operational states are provided)

– Interface is connected and alarm handler is in active mode:

alarm state = “normal” and operational state = “up”

– Interface is connected and alarm handler is in stand-by mode:

alarm state = “disabled” and operational state = “dormant”

– Interface is unconnected:

alarm state = “disabled” and operational state = “disabled”

• Clock interfaces(Reasons and details for alarm and operational states are provided with exception

of TDM clock source EQN)

– TDM clock unit is active:


– TDM clock unit is in stand-by mode:

alarm state = “normal” and operational state = “dormant”

• Gateway interfaces

– Redundant gateway accessible and in operation:


– No redundant gateway connected:

alarm state = “disabled” and operational state = “disabled”

PS-E with alarm in Containment View

Example PS-E with port alarm in Containment View:

iAppropriate interface configuration (administrative state of PS-E ports) is a prerequisite

for correct alarm display in Containment View.



76 A30828-X1187-U125-3-7619


Fig. 3.16 PS-E with port alarm in Containment View

PS-E alarms in Containment View:

– Any PS-E alarm is indicated by the corresponding icon in the Containment View.

– The alarm state of the PS-E node changes and its operational state shows “restrict-

ed”.

– The PS-E error is propagated from the lowest level to the node and further up to the

network element level. In the event that there are several errors the most severe

alarm state is propagated.

3.3.4 Configuration tasks via Workbench for PS-E

You have to configure the PS-E via Workbench additionally to the basic configuration of

a PS-E node via BCSS .

The data entered via Workbench for the PS-E is stored locally at the module itself.

You cannot load (restore) these data at another module with Software Management. A

new or replaced module has to be configured from the scratch.

iYou have to enter parameters in BCSS first, before you can configure a PS-E via Work-bench. All entries (except for mirror port command) done via Workbench can be savedto the PS-E’s FEPROM (board backup), see 4.8.2 "Backup for the PS-E". Otherwiseyour entries will get lost after a reboot.

Contents

Mandatory configuration (necessary for new PS-E nodes)*

3.3.4.1 "Manage PS-E’s VLANs"

3.3.4.2 "Manage PS-E’s ports"

Mandatory for PS-E working as clock unit

3.3.4.3 "Manage PS-E’s TDM clock input"

Mandatory for PS-E working as alarm unit

3.3.4.4 "Manage PS-E’s alarm inputs"

Optional configuration(additional external trap destinations to the ones entered via BCSS)

3.12.1 "Managing external trap destinations for PS-E via Workbench"



A30828-X1187-U125-3-7619 77

OperationSURPASS


* If you do not enter port and VLAN configuration via Workbench and there is neither a

valid user-defined configuration the PS-E will select appropriate default configurations

according to connected uplink interfaces, see 2.4.6 "Default uplink configurations".

3.3.4.1 Manage PS-E’s VLANs

The PS-E supports three VLANs, i.e. it can contain three logical switches as follows:

– One switch for OAM traffic (based on ports with fixed “VLAN ID = 1”)

– One switch for control traffic (via tags, VID administered)

– One switch for payload (via tags, VID administered)

On its uplinks the PS-E can provide either implicit tagging (no tags on Ethernet interfac-

es) or explicit tagging (priority and VLAN ID are part of the data packet) to carry separate

traffic types over the same uplink. However, OAM traffic is always sent without tags onany link.

Configuration data per VLAN:

• VLAN ID

– OAM VLAN ID = 1 (fixed assignment)

– VLAN ID = 0 = “not used” (no ports assigned to)

– other VLAN IDs are configurable

• VLAN member ports

– VLAN’s member ports (ports belonging to a specific VLAN, egress frames (like

broadcasts) will only reach the VLAN’s member ports)

– VLAN’s untagged ports (ports where frames are sent untagged)

– VLAN’s forbidden ports (port that are not member of a VLAN)You can

– set up VLANs for control and payload traffic and assign VLAN identifications to them

– assign ports to one, or several VLANs and define the type of assignment per port

Create VLANs as follows:

1. Start task CR VLANCONF once per PS-E and VLAN (Control/Payload)

2. Enter EQN of PS-E

3. Enter VLAN-specific parameters

– VLAN name = (Ctrl or Payl)

– VLAN ID

These are special VLAN IDs: VID = 1 (OAM VLAN), 0 (VLAN is not in use)

4. Enter port-specific parameters

– Select Port 0 - Port 25

– Per port select kind assignment to VLAN

(Tagged member/Untagged member/Not member)

5. Done

You can check the VLAN configuration for a PS-E with DISP VLANCONF.

You can modify or delete individual VLANs with MOD VLANCONF or DEL VLANCONF.

iThe VLAN and port configuration is dependent on the network environment. For furtherdetails, refer to 2 "Introduction".

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



78 A30828-X1187-U125-3-7619


3.3.4.2 Manage PS-E’s ports

PS-E port configuration includes these tasks:

– You have to configure which PS-E port is in use or not in use

(= administrative state of port).

– You have to enter the corresponding configuration parameters for each PS-E port.

Configure PS-E ports as follows:

1. Start task MOD PORTCONF once per PS-E port

2. Enter mandatory parameters: – EQN of PS-E

– Select Port number in drop down menu

(The port number is displayed in Containment View as “...apxx”)

3. For ports that are not connected

– Admin. state = Down

4. For ports that are connected enter the following parameters:

– Admin. state = Up

– Port speed = Autonegotiate or Full-100 (full-duplex, 100 Mbit/s)*

– Default VLAN ID

(This is the VLAN that is assigned to untagged ingress frames.)

5. Done

* These port speed variants are allowed:

• For GE ports only Autonegotiate is allowed.

• For FE ports you can choose the port speed variant.

If you select Full-100 instead of Autonegotiate for a PS-E that is connected to a DCE

(switch, hub,etc.) then you will have to use a cross cable. Because if autonegotiation

is switched off, this also switches off the automatic DTE/DCE adaptation.

You can check the configuration of one PS-E port or of all PS-E ports with DISP PORT-

CONF. This task also displays the default uplink port configurations (default VLAN).

3.3.4.3 Manage PS-E’s TDM clock input

The two PS-Es in a shelf compose a redundant pair of TDM clocks, i.e. one active clock

unit and one standby clock unit.

For the PS-E’s TDM clock you can

– display the current state of the TDM clock unit of this PS-E and partner PS-E

– select clock parameters

(EQN and PLL bandwidth of clock source, recommended PLL bandwidth is 1,1 Hz))

iYou have to enter the appropriate VLAN configuration first. Otherwise not consistent

port configurations are rejected by the SW (not consistent configuration means “select-

ed port is not member port of the entered VLAN”).

!If unconnected uplink ports are not configured to administrative state “down”, you will

not get the alarm state “normal” in Containment View for a fault-free PS-E node.

iPorts with administrative state “down” are displayed with operational state “down” in

Containment View. So, if in doubt, the administrative state of a port should be checked

via task.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 79

OperationSURPASS


– start a manual switchover (between active and standby PS-E clock unit),

(see 3.10.1)

Enter parameters for the PS-E’s TDM clock unit as follows:

1. Start task MOD TDMCLKCONF

2. Enter the following parameters:

– EQN of PS-E

– EQN of ref. source

– PLL bandwidth (if required)

3. Done

You can display the reference clock configuration with DISP TDMCLKCONF.

3.3.4.4 Manage PS-E’s alarm inputs

If you want to employ the PS-E as alarm handler unit you have to activate this function

in BCSS, see 3.3.2.4 "Creating/modifying/deleting PS-E nodes" (Edit “Ethernet Switch

Type C - Specific Data” tab). Additionally you have to configure unconnected alarm sen-

sors to “unconnected” via Workbench.

You can display/configure the behavior of the alarm sensors:

– Alarm reason

– Polarity

– Severity

Additionally you can display the status of the alarm unit.

As alarm reason you can assign a given text or just an alarm number from a list. These

entries have effect on the details and severity of any external alarms in Contain-

ment View and in AMD.

Configure each of the PS-E’s alarm sensors as follows:

1. Start task MOD ALINPCONF once per alarm sensor

2. Enter/select the following parameters:

– EQN of PS-E

– Alarm index (choose number of alarm input)

– Alarm reason (choose appropriate text or alarm number)

– Polarity (choose active state of alarm sensor)

– Alarm state (choose alarm severity)

3. Done

You can display your current alarm input configuration with DISP ALINPCONF.

!

You have to enter the EQN of the TDM reference clock source, otherwise the Contain-

ment View will not show the actual source of the clock.

iA valid external reference clock at the standby side is a prerequisite for a manual

switchover from the active side to the standby side.

iTwo PS-Es in a rack can be responsible for alarming. During start-up both PS-Es nego-

tiate which one becomes alarm master. The other PS-E switches to stand-by and ob-

serves the active one to take over, if necessary.

!Two redundant PS-Es must have exactly the same alarm configuration. You have to en-

ter identical data on both PS-Es.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



80 A30828-X1187-U125-3-7619


3.4 FPU-E management

3.4.1 General

Each FPU-E is a separate entity, i.e. node (management type “FPU-E V1.0”) with its in-

dividual IP address for OAM and sends its traps to NetManager. The management type

FPU-E V1.0 is independent from the FPU-E hardware variant (PSC-C or VMC).

From the operator’s view the FPU-E contains three separately managed parts:

1. VM

Managed via SNMP, sends its messages to NetManager, monitored with Contain-

ment View and NTM/AMD

2. FP-P or LTGx

Managed via MML (created in hiE 9200 database), sends its messages to hiE 9200,

monitored with NTM/AMD and Alarm Console, LTG-ID(s) is/are displayed in Con-

tainment View

3. Optional special equipment (LTU:S)

Managed via MML (created in hiE 9200 database), sends its messages to hiE 9200,monitored with NTM/AMD, not displayed in Containment View

This manual treats the SNMP-managed equipment of the FPU-E.

For details on FP-P/LTGx or LTU:S management, refer to the LTG manuals.

Date and time for FPU-E nodes

The FPU-E needs information about the current date and time in order to perform its sta-

tistical tasks and for error notebook and backup date and time entries.

The FPU-E’s Voice Module acts as the SNTP client and requests the current systemtime from an SNTP server at the NetManager. Primary and (optional) secondary SNTP

servers are assigned to the FPU-E by BCSS.

The Voice Module requests the valid system time from the NetManager during startup

and by cyclical request. The response from the SNTP server is stored as universal time

coordinated (UTC).

Date and time is managed using BCSS, see 3.11 "“Time of day” management".

Software management

The Voice Module’s flash file system contains SW/FW and semi-permanent configura-

tion data and is administrated with the Software Management application.

iYou can find the DLU-IP-specific items in 5.2 "Operation and administration".

Contents

3.4.1 "General"

3.4.2 "Managing FPU-E nodes using BCSS"

3.4.3 "Monitoring FPU-E using Containment View"

3.4.4 "Configuration tasks for FPU’s Voice Module"

iThe corresponding PS-E(s) must be booted first before a FPU-E (PSC-C/VMC) can

start to send DHCP requests.



A30828-X1187-U125-3-7619 81

OperationSURPASS


There are no product-specific menu functions in SW Management.

The FPU-E software can be downloaded during normal operation. The FPU-E is taken

out of service when switching over to the new software load.

For further information on SW Management, refer to NetM documentation

For details on SW update, refer to 4.5 "SW update"

For details on backup/restore, refer to 4.8 "Backup/restore hiG 1600 database"

Auto discovery mechanism for FPU-E node (Voice Module)

These are the product-specific auto discovery variants for the FPU-E node within the

hiG 1600:

• auto discovery on polling

quick check whether FPU-E node is accessible from NetManager (tests just OAMlink)

• auto discovery on trap

initiated after change of configuration/state, usually initiated after reboot of module

• manual auto discovery

manually initiated by user in BCSS or via context menu in Containment View

The auto discovery reads all existing interfaces and the respective operational and

alarm states in the FPU-E node. The resulting states are then visible in Containment

View.

Alarm state changes for modules during auto discovery are immediately forwarded to

Alarm Surveillance.

Adding/replacing an FPU-E module

For replacing a PSC-C, VMC or LTG, refer to 4.7 "Replacing hiG 1600 modules".

For adding a new PSC-C or VMC, refer to

1. 3.4.2.4 "Creating/modifying/deleting FPU-E nodes with BCSS"

2. 3.4.4 "Configuration tasks for FPU’s Voice Module"

3.4.2 Managing FPU-E nodes using BCSS

Go to the appropriate destination:

3.4.2.1 Functions of the BCSS plug-in for FPU-E nodes

These are the functions of the BCSS FPU-E plug-in:

– Administering FPU-E nodes

iPlease regard that any software management actions (except “display” actions) lead to

a Voice Module timeout of about two minutes.

Contents

3.4.2.1 "Functions of the BCSS plug-in for FPU-E nodes"

3.4.2.4 "Creating/modifying/deleting FPU-E nodes with BCSS"

3.4.2.5 "FPU-E preferences"

3.4.2.6 "SNMP access list for FPU-E"

3.4.2.7 "Operational FPU-E node in BCSS"



82 A30828-X1187-U125-3-7619


– Sending the administrated parameters as startup information to a FPU-E’s Voice

Module that is going to reboot

– Managing the SNMP access list for FPU-E nodes

– Ensuring data consistency between BCSS and FPU-E (FPU-E preferences)

The FPU-E-specific BCSS plug-in extends the menus, context menus, and toolbar of the

generic BCSS with FPU-E- specific items.

These are the menu extensions in BCSS:

• Administration -> New Node -> Feature Processor Unit

(Creating new FPU node)

• Administration -> Preference Properties-> FPU-E Plugin tab

(Consistency checks for FPU node)

• View -> Toolbar -> Feature Processor Unit

(FPU-specific toolbar)

• Tasks -> Feature Processor Unit -> SNMP Access List

(FPU-specific SNMP access list, i.e. “white list” for OAM access)• Help -> Plugin Help Topics -> FPU Plugin

(Supporting help)

• Help -> About Plugins -> FPU Plugin

(“About” dialog box)

The FPU-E-specific toolbar extension comprises these icons:

– Icon for the function “create a FPU-E node”

– Icon for the function “open the SNMP access list”

The generic menu functions for editing/removing nodes and forced auto discovery are

applicable for the FPU-E nodes, too.

3.4.2.2 Overview about FPU-E-specific node data

The table below provides an overview about BCSS data for PS-E nodes.

For a detailed description, refer to 3.4.2.3 "FPU-E-specific windows in BCSS" and to

NetManager’s online help.

Parameter Remarks

General Properties tab

Node Name Enter the name of this specific SNMP node.This name is displayed in Containment View for the con-

tainer.SNMP Version Select SNMPv1 or SNMPv2c

(default: SNMPv2c)

Management Type “FPU-E V1.0”, default value

Polling Time “360”, default value, can be changedThe polling time default value should notbe reduced unlessit is required.(Polling time range from 10 to 35000)

Tab. 3.6 Required inputs in BCSS to create a FPU node



A30828-X1187-U125-3-7619 83

OperationSURPASS


Primary TDS Name Select a communication server of NetManager as primarytrap destination server (corresponding IP address is updat-ed automatically)

Backup TDS Name Select a second communication server of NetManager asbackup trap destination server (corresponding IP addressis updated automatically)

LAN Specific Data tab

Radio button:“Separated OAM trafficinterfaces” (default)or“Payload and embed-ded OAM traffic inter-faces”

Select whether OAM traffic is routed via separated (dedicat-ed) interface or via common interface together with payloadtraffic.FE0, FE1 can be used for OAM/control, but not for payloadFE2, FE3 can be used for payload and for OAM/control

(In BCSS only payload and OAM traffic is considered. Usethe NetM Workbench to map control traffic to uplink inter-faces.)

MAC Address 1 Enter all four (unique) MAC addresses for the VM’s uplinkinterfaces (there is a label on the VM with the first two MACaddresses)

MAC Address 2

MAC Address 3

MAC Address 4

Ethernet IP Enter IP address of FPU’s OAM interfaceThis is a common logical IP address for all four physical

Ethernet interfaces.Subnetmask dependent on network environment

Default Gateway IP dependent on network environment

Secondary Gateway IP optional parameter, dependent on network environment(BCSS checks whether default and redundant gateway arewithin the same subnet.)

FPU Specific Data tab

General- FPU number- Shelf

- Frame Type

- unique FPU number (0-65535) within this PSC- shelf number (0-11)

- currently only type “A”

FPU EQN = <FPU#>-<Shelf#>-<Module#>(<Module#> is determined by the FPU-E from the PSC-C/VMC mounting location, i.e. slot position)

In a DLU-IP the module number is always “12”.

Parameter Remarks




84 A30828-X1187-U125-3-7619


3.4.2.3 FPU-E-specific windows in BCSS

1. General Properties tab

Fig. 3.17 General Properties tab for FPU

Completion instructions for the General Properties tab:

LTG Identifier- LGT Set- LTG

Enter 1-4x LTG EQN(depending on FPU-E type, LTG Set 0-31,LTG Number 1-63)

The item number stands for the FPU-E interface the LTG isconnected to.LTG EQN = <LTG Set>-<LTG>

Server Data tab

SNTP Settings- Primary SNTP Server- Sec. SNTP Server- Time Offset

Enter primary SNTP server (mandatory)Enter secondary SNTP server (optional)Enter time offset from UTC in full hours(range from -12 to +12)

Parameter Remarks


iThe maximum length of the FPU-E node name must not exceed 50 characters.



A30828-X1187-U125-3-7619 85

OperationSURPASS


– When you select the primary and backup TDS the corresponding IP address is

set automatically (the IP address is “read-only”).

– A lower polling time decreases error detection time, but also increases load in

the SNMP network. For further details, refer to NetManager’s online help or to the

NetManager documentation.

Additional external trap destinations (which are not communication servers of this

NetManager) can be entered via Workbench. These are independent from the pri-

mary/secondary TDS entered in BCSS, i.e. BCSS does not care about any TDS en-

tered via Workbench. For further details, see 3.12.2 "Managing external trap

destinations for FPU-E via Workbench".

2. LAN Specific Data tab

Fig. 3.18 LAN Specific Data tab for FPU

Completion instructions for the LAN Specific Data tab

– The LAN-specific data for the FPU-E must match to the PS-E configuration. For

further details on PS-E port configuration, refer to 3.3 "PS-E management".

– The Voice Module possesses four MAC addresses. These MAC addresses have

to be changed, when replacing an FPU-E module.

– The DNS list is not yet supported.

– The IP address, gateways and the subnetmask correspond to the FPU-E’s OAM

interface. This means these values are valid for OAM traffic. Use the workbench

to assign IP addresses, gateways and subnetmask for payload and control traffic.

Refer to 3.4.4.3 "Manage Voice Module’s IP addresses for control and payload"

– If the FPU-E is not connected to a secondary gateway enter “0.0.0.0” as IP ad-

dress for the secondary gateway.



86 A30828-X1187-U125-3-7619


– Select mapping for OAM and payload traffic

(see below description of radio buttons) .

In a DLU-IP only two of the PSC-C’s uplinks are used (usually FE1, FE2).

Control traffic can be mapped independently to FE0/FE1 or FE2/FE3. Refer to

3.4.4.2 "Manage Voice Module’s basic configuration".

For traffic mapping you can either check one of the following radio buttons:

– Radio button “Separated OAM traffic interfaces” (factory default)

This means OAM is mapped to uplink port FE0/FE1 (= VM port “21”/”22”) and

payload traffic is mapped to uplink port FE2/FE3 (= VM port “23”/”24”).

– Radio button “Payload and embedded OAM traffic interfaces”

This means payload together with OAM traffic is mapped to common interfaces

FE2/FE3 (= VM port “23”/”24”).

You should use the default setting, i.e. separate OAM/control and payload traf-

fic internally by using different network interfaces for the FPU-E.

3. FPU Specific Data tab

Fig. 3.19 FPU Specific Data tab

i You can find the first one of the Voice Module’s MAC addresses on a label at the VoiceModule (do not confuse with the other label at the front plate of the PSC-C). Take the

next MAC address (<first address> +1) as the second MAC address and so on.

!If you change the Voice Module’s IP address for OAM in BCSS you will have to reboot

the Voice Module manually using the switch at its frontplate.



A30828-X1187-U125-3-7619 87

OperationSURPASS


Completion instructions for “General” area

The FPU-E EQN consists of: <FPU#><Shelf#><Module#>

– The “FPU number” is a number of a FPU-E node that has to be unique within the

network element this FPU-E is assigned to. You have to specify FPU-E number

and shelf number (= position of shelf in the rack).

– The module number is automatically determined by the FPU-E from the mounting

location (i.e. slot position) of the PSC-C/VMC.

– The parameter “Frame Type” is not yet evaluated.

Completion instructions for “LTG Identifier” area

– You need 1 or 4 LTG identifiers. This depends on the type of Feature Processor

(FPP or LTGx) in your FPU-E

– The values for the LTG identifier must match the ones entered in the hiE 9200 da-

tabase with CR LTG. There is no plausibility check.

Completion instructions for “SNTP Settings” area

– Enter primary SNTP server and secondary SNTP server (if appropriate)

– If you do not use a secondary SNTP server enter “0.0.0.0” in its IP address box

– Enter time offset from UTC (full hours only)

3.4.2.4 Creating/modifying/deleting FPU-E nodes with BCSS

The same windows apply for creating nodes or for modifying existing nodes (see

3.4.2.3 "FPU-E-specific windows in BCSS").

Nodes can be created/modified (edited) as well as deleted via the BCSS “Administra-

tion” menu.

Alternatively you can call the corresponding BCSS functions via context menu (“New

Node” from NE context menu or “Edit/Delete Node” from node context menu). For exist-

ing nodes you can also double-click on the node or select the “Edit”/”Delete” icon in from

the BCSS toolbar.

Create FPU-E node

To create a FPU-E node do the following:

1. Collect the required data,

see, 3.4.2.2 "Overview about FPU-E-specific node data"

(You will need site-specific documentation for your network environment.)

2. Start BCSS and select an appropriate network element as container for the new

node

3. Select BCSS function “Administration” -> “New Node” -> “Feature Processor Unit”

iIn the DLU-IP the module number is always “12”.

iAfter first creation the LTG identifications are immediately displayed in CV. But after

modifying an existing LTG identification with BCSS you have to initiate an auto discov-

ery in CV first before the new value is displayed in CV.

Guidelines

"Create FPU-E node""Modify FPU-E node" (also applies for reading basic configuration node data)

"Delete FPU-E node"



88 A30828-X1187-U125-3-7619


4. Fill-in the FPU-E-specific pages

(see, 3.4.2.3 "FPU-E-specific windows in BCSS")

5. Save your entries (the new node appears in BCSS overview) and close BCSS

6. Plug in the PSC-C or VMC module and/switch on module

The module boots automatically.

7. In the event that you are adding a new PSC-C/VMC module:

– Check the Voice Module’s SW/FW version with Software Management and up-

date, if required, see 4.5.1 "SW update on Voice Module"

– Enter configuration data manually via Workbench, see 3.4.4 "Configuration tasks

for FPU’s Voice Module"

or

Load the Voice Module’s configuration data file, see 4.8.1 "Backup and restore for

the Voice Module"

8. Make sure that the new node is displayed correctly in BCSS and in Containment

View (see "Operational FPU-E node in Containment View")

9. If appropriate: Edit SNMP access list of new node (see 3.4.2.6 "SNMP access listfor FPU-E")

10. Done

Modify FPU-E node

To modify an existing FPU-E node do the following:

1. Start BCSS for the node in question

2. Select BCSS function “Administration” -> “Edit Node”

3. Enter your modifications

(see 3.3.2.3 "PS-E-specific windows in BCSS")

Alternatively you can just read any entries and close the PS-E-specific window with

“Cancel”.4. Save your modifications and close BCSS

5. Reboot the new node

– Start SW Management

– Call function “Tasks” -> Reboot

6. Makesure that the modified node is displayed correctly in BCSS and in Containment

View (see "Operational FPU-E node in Containment View")

7. Done

Delete FPU-E node

To delete an existing FPU-E node do the following:

1. Start BCSS for the node in question2. Select BCSS function “Administration” -> “Delete Node”

3. Confirm this action with “Yes” when asked to or press “Cancel” to abort

4. BCSS deletes the selected node and shows the status of the deletion operation. On

completion the node disappears in BCSS.


6. Make sure the deleted node disappears from Containment View

7. Done

3.4.2.5 FPU-E preferences

The FPU-E preferences are valid for all FPU-E nodes in your NetManager domain.



A30828-X1187-U125-3-7619 89

OperationSURPASS


To edit FPU-E preferences do the following:

1. Start BCSS

2. Select BCSS function “Administration” -> “Preferences...”

3. In the preferences window select the “FPU Plugin” tab4. View or modify (if appropriate) the preferences

You should always use the default settings, see Fig. 3.20 "Preferences tab for

FPU-E"

5. If appropriate: Save your modifications

6. Close BCSS

7. Done

Example:

Fig. 3.20 Preferences tab for FPU-E

You can select the kind of data to be checked by node consistency checks and you can

check the following types of node consistency checks:

– On startup


BCSS database is performed for all FPU-E nodes after the BCSS server is started.

The node data is corrected in case of differences

– On activation

If this checkbox is enabled, then a consistency check for data between the node andBCSS database is performed for a FPU-E node after its state goes to active. The

node data is corrected in case of differences.

Additionally you can select the following types of BOOTP consistency checks:

– On startup


for all FPU-E nodes after the BCSS server is started. The DHCP data are corrected

in case of differences

– On activation


for all FPU-E nodes always when the DHCP Server data has changed. The DHCP

data are corrected in case of differences

For further details on the controls in the window, refer to NetManager’s online help



90 A30828-X1187-U125-3-7619


3.4.2.6 SNMP access list for FPU-E

SNMP access list window for FPU-E

To enhance security an authorization function is added to accept or reject SNMP re-quests based on the originator's IP address. The FPU-E maintains an access control list

with network or host IP addresses and the associated access rights

Fig. 3.21 SNMP access list for FPU-E

There are two window panes:

• Available Entries (left window pane)

Lists all hosts which have granted access to any FPU-E node. All communication

servers of this NetM domain are automatically included.

• Access List for Node (right window pane)Lists all hosts which have granted access to this specific FPU-E node. All communi-

cation servers of this NetM domain are automatically included.

All communication servers of the NetManager domain for this FPU-E node are marked

with a “key” and cannot be removed from the lists.

Display FPU-E’s SNMP access list1. Select a FPU-E node in BCSS




(see Fig. 3.21 "SNMP access list for FPU-E")

4. Done

Add/remove an “available” entry to/from FPU-E’s SNMP access list

1. Select a FPU-E node in BCSS



Guidelines

"Display FPU-E’s SNMP access list"

"Add/remove an “available” entry to/from FPU-E’s SNMP access list"

"Add a “not available” entry in FPU-E’s SNMP access list"



A30828-X1187-U125-3-7619 91

OperationSURPASS


2. In the BCSS menu select the function “Tasks” -> “FeatureProcessorUnit” -> “SNMP

Access List”




– Add an available entry to the FPU-E’s access list:

Select the entry in the left window pane and press button “>>”

– Remove an entry from the PS-E’s access list

Select the entry in the right window pane and press button “<<“



node

7. Done

Add a “not available” entry in FPU-E’s SNMP access list

1. Select a node in BCSSA node must be in state “active” to change its SNMP access list. Otherwise the cor-


2. In the BCSS menu select the function “Tasks” -> “Feature ProcessorUnit” -> “SNMP

Access List”



4. Press button “New”

A “New Access List entry” window appears

– Fill in name, corresponding IP address and subnet mask

If an IPAddress is entered with subnet mask 255.255.255.255, then only the par-

ticular host will be given SNMP access. If the subnet is entered along with startingIP address, then the set of hosts, which resides in the subnet, will be given SNMP

access.

– Select access rights

You have to assign “read/write” access rights when adding nodes/networks to the

“Acces List for Node”, otherwise the specific node will notbe accessible from these

nodes/networks.

Fig. 3.22 New access list entry window for FPU-E


The “New Access List entry” window is closed.6. Press “OK” to close the SNMP access list



92 A30828-X1187-U125-3-7619



node

8. Done

3.4.2.7 Operational FPU-E node in BCSS

An operational FPU-E is visible in the BCSS main window with node state “active”.

Example:

Fig. 3.23 Operational FPU-E in BCSS

3.4.3 Monitoring FPU-E using Containment View

After auto discovery or manual discovery the FPU’s containment together with its alarm

and operational states is updated in Containment View.

A FPU-E node itself is indicated as class “Chassis” and has the following containment:• An EQN representing the VM on module level (indicated as class “Module”) contain-

ing the VM’s interfaces (indicated as class “Port”).

• An EQN (indicated as class “Container”) containing the assigned Feature Proces-

sor(s) (indicated as class “Port”)

The FPU-E components are displayed as follows in Containment View:

i

For nodes with node state “Error - AD timeout” you can try activation through a forced

autodiscovery (“Tasks -> “Start Autodiscovery”).

iNot occupied interfaces at the Voice Module have to be deactivated to prevent unnec-essary alarms in the Containment View, see 3.4.4.1 "Manage Voice Modules’s admin-istrative port states" and 3.4.4.4 "Manage Voice Module’s message channelassociations".

iAny alarm for the FPU-E’s Feature Processor is indicated using the logical MML node(see Fig. 3.2 "Example of logical MML node (with alarm)"). The “Ltg_Id” under the FPU-E node displays the assigned LTG set number and LTG number only (does not indicateoperational conditions).



94 A30828-X1187-U125-3-7619


* In a DLU-IP these ports are not connected to the PS-E but to an external L2 switch or

at L3 equipment.

Names and EQNs for the FPU-E in Containment View:

• Node name:

<FPU-E node name> is entered using BCSS

• VM EQN:

<FPU-E>-<shelf#>-<module#>

– <FPU-E#>-<shelf#> is entered using BCSS

– <module#> (= slot#) is derived from the PSC-C/VMC mounting location (MOLOC)

in the PSC(D) shelf, see "Relation between PSC-C/VMC mounting location in

PSC(D) shelf and module number in CV"

(Module#=”12” for PSC-C module in DLU-IP)

• VM ports:

Ports are automatically recognized and corresponding port names are displayed in

CV

<FPU#>-<shelf#>-<module#>-24* ethernet-csmacd

Port Internal payload inter-face between VM andPS-E 1 (FE3 in BCSS,ETH3 in Workbench)

<FPU#>-<shelf#>-<module#>-81 referenceclock

Port Port 81 represents a vir-tual “clock interface” for8 MHz clock betweenVoice Module and Fea-ture Processor (FP-P/LTGx)

<FPU#>-<shelf#>-<module#>-91 qos Port Port 91 represents a vir-tual “QoS alarm inter-face”

AssociatedLtgs

LtgId_1:<LTG Set>-<LTG> ltg Module Feature processing re-source 1




Module/Port EQN Type Class Remarks

Tab. 3.7 FPU-E modules/ports in Containment View

iDepending on your configuration, control traffic can be routed via VM’s OAM interfaces

(port -21, -22) or via VM’s payload interfaces (port -23, -24).

iTo evaluate detail information in Containment View for the FPU-E, refer to 4.3 "SNMPmessages from FPU-E (VM part)."



A30828-X1187-U125-3-7619 95

OperationSURPASS


Relation between PSC-C/VMC mounting location in PSC(D) shelf and module

number in CV

The following table shows where to find a VM (on PSC-C or VMC) in the PSC(D) shelf.

Module Position (MOLOC)of PSC-C/VMC

Module# in CV(= Slot#)

C127 2

C153 4

C179 6

C207 8

C233 10

Tab. 3.8Relation between MOLOC and module number in CV for PSC(D)



96 A30828-X1187-U125-3-7619


Operational FPU-E node in Containment View

Fig. 3.24 Operational FPU node in Containment View

iYou can find a DLU-IP-specific example in 5.2.2 "FPU-E nodes in a DLU-IP".



A30828-X1187-U125-3-7619 97

OperationSURPASS


An operational Voice Module in a FPU node (Class “module”) is indicated as follows:

– Alarm state = “normal”

– Operational state = “up”

– Alarm state reason = operational state reason = “normal”

– Alarm state details = operational state details = “not applicable”

Operational ports on a Voice Module (class “port) are indicated as follows:

– Connected ports have alarm state = “normal” and operational state = “up”

– Unconnected ports have alarm state = “normal” and operational state “disabled” (as-

suming they are in administrative state “down”).

FPU node with alarm in Containment View

Any FPU alarm is just indicated by the corresponding icon in the Containment View.

The FPU error is propagated from port level to the node and further up to the network

element level. If there are several errors the most severe error is propagated.

An FPU-E’s Voice Module with alarm is indicated as follows:

– Alarm/operational state reason = “not available”

change to Alarm/operational state reason = “normal”

– Alarm/operational state details = “0”

change to alarm/operational state details = “not applicable”

The ports on a Voice Module with alarm are indicated as follows:

– Unconnected uplink ports stay in alarm state = “normal”

(If the alarm state is not “normal”, the administrative state of the unconnected ports

has to be set to “down”.)

– For connected ports the alarm state contains the alarm priority, the operational state

goes to “down”

The ports for QoS and clock show a different behavior. For details refer to

4.3 "SNMP messages from FPU-E (VM part)."

The following figure provides an example showing the indication of FPU alarms.

iYou can find a DLU-IP-specific example in 5.2.2 "FPU-E nodes in a DLU-IP".



98 A30828-X1187-U125-3-7619


Fig. 3.25 FPU-E with alarm in Containment View

In the above example a port error at the payload uplink port between FPU-E and default

PS-E is indicated and propagated up to the FPU-E node and further up to the PSC NE

(T08_HIG1600V2_04).

3.4.4 Configuration tasks for FPU’s Voice ModuleAdditionally to the FPU-E node configuration via BCSS you have to configure the FPU-

E’s Voice Module via Workbench.

As an alternative to manual configuration via Workbench you can load an existing data-

base with SW Management.

iYou have to enter parameters in BCSS first, before you can configure a VM via Work-bench. All entries done via Workbench have to be saved with SW Management (VMmust be up to execute a backup), see 4.8.1 "Backup and restore for the Voice Module".

Contents

Mandatory configuration(necessary data for a new FPU-E without backup file)

3.4.4.1 "Manage Voice Modules’s administrative port states"

3.4.4.2 "Manage Voice Module’s basic configuration"

3.4.4.3 "Manage Voice Module’s IP addresses for control and payload"

3.4.4.4 "Manage Voice Module’s message channel associations"

3.4.4.5 "Manage Voice Module’s test interfaces"

Optional configuration(FPU-E is operational with default settings)

3.4.4.6 "Manage Voice Module’s Codecs"

Optional configuration

(FPU is operational with primary/secondary trap destination)3.12.2 "Managing external trap destinations for FPU-E via Workbench"



A30828-X1187-U125-3-7619 99

OperationSURPASS


3.4.4.1 Manage Voice Modules’s administrative port states

You can set an administrative state individually per Voice Module interface (port).This

applies for Ethernet interfaces as well as for SN interfaces (connecting to message

channels).

To deactivate an unused port at the Voice Module do the following:

1. Start task MOD AIFATT

2. Enter EQN (of port)

3. Select AdminStatus = down

The Containment View displays ports that are configured to “down” with operational

state “disabled”.

You can request the administrative status of each of Voice Module’s ports with DISP

AIFATT.

3.4.4.2 Manage Voice Module’s basic configuration

For each Voice Module there are project-specific settings (for example tone generator)

that are defined by a “project ID”. The project ID can be found in your site-specific doc-

umentation.

Additionally you have to select whether there is control traffic via OAM interface

(FE0/FE1) or via payload interface (FE2/FE3).

The project ID and the control interface is configured for each Voice Module as follows:

1. Take the project ID from the site-specific documentation

2. Start task MOD BCONF

3. Enter parameters

– Enter EQN of Voice Module

– Select the configuration variant for the SCTP interface (control traffic) – Enter your Project ID (without leading “X”)

– Enter other optional parameters, if required

iYou have to configure ports that are not connected to “down”. This prevents unwanted

alarms in Containment View, Network Topology Viewer or AMD for these unconnected

ports.

iThe project ID must not be “0” or empty. Without a valid project ID the VM will not get

up and you will get an error message . Changing a project ID for a Voice Module that is

already up requires a reboot.

iIt is recommended to send control traffic via the OAM interface. However, you have tomake sure that the mapping for the control traffic matches the PS-E configuration.

iSelectable TOG data are loaded at the VM itself and at the PSC-C’s Feature Processor

(FPP). The TOG values for the LTGs that are connected to a VMC are set in the factory

and cannot be changed in this way.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



100 A30828-X1187-U125-3-7619


3.4.4.3 Manage Voice Module’s IP addresses for control and payload

You have to configure one IP address for each payload and control interface of the Voice

Module.

Enter the IP configuration for payload and control traffic as follows:

1. Start BOAM task MOD IPCONF once per VM and VM interface type (SCTP or pay-

load)


– EQN of Voice Module

– Select Payload traffic:

Fill in all input boxes for payload traffic

– Select SCTP (control) traffic:

Fill in the corresponding input boxes for the default/standby gateway.But do not enter IP address and corresponding netmask.

To enter these values, refer to 3.4.4.4 "Manage Voice Module’s message channel

associations".

You can check the IP configuration with DISP IPCONF.

Additionally there are six IP addresses for testing, see 3.4.4.5 "Manage Voice Module’s

test interfaces".

3.4.4.4 Manage Voice Module’s message channel associations

You have to configure a message channel association once per SCTP interface at the

Voice Module.Message channels that are not connected have to be configured to administrative state

“down”. This also applies for the corresponding ports (SN interfaces) at the Voice

Module.

Configure the SCTP interfaces as follows:1. Start task MOD MCHE once per Voice Module and SCTP interface

2. Enter the following parameters for connected SCTP interfaces:

– EQN of VM

– Interface name (SCTP0 - SCTP3)

– IP address (individual address per message channel)

– Netmask (of redundant association pair)

– Select Admin. status = Up (= connected message channel)

3. Enter the following parameters for unconnected SCTP interfaces: *

– EQN of VM

– Interface name (SCTP0 - SCTP3)

– IP address = “0.0.0.0”

– Netmask = “0.0.0.0”

iWithout IP addresses for payload/control traffic the VM will not get up and you will getan error message. The VLAN configuration must match the PS-E configuration.

iThe Voice Module will not transfer any payload without appropriately configured SCTP

interfaces.

iThe IP address for the SCTP association entered at the hiG 1600 must match the ones

entered at the hiE 9200 with “CRLTG”. The port numbers for local/remote ports must

not be changed.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 101

OperationSURPASS


– Select Admin. status = Down (= not connected message channel)

– Configure corresponding VM ports to administrative state “down”, if appropriate

(see, 3.4.4.1 "Manage Voice Modules’s administrative port states")

* Depending on the type of connected LTG there may be unoccupied message channelson a VM belonging to a VMC. The VM expects entries for all message channels, other-

wise it will not come up (stays in status “restricted”).

3.4.4.5 Manage Voice Module’s test interfaces

There is an individual test IP address at the Voice Module for each traffic type and inter-

face. That means you have to configure six test IP addresses per Voice Module.

Test IP addresses are necessary to monitor the connection to routers or switches. The

test addresses are private addresses between Voice Module and router. These test

mechanisms ensure that the Voice Modules are informed about PS-E uplink failures.

Configure the test IP addresses as follows:

1. Start task MOD TESTIPE once per Voice Module and traffic type



– Test interface (payload/OAM/SCTP)

– Address

– Address redundant

– Netmask

– Netmask redundant

You can display the Voice Module’s test IP addresses with DISP TESTIPE.

3.4.4.6 Manage Voice Module’s Codecs

The default settings for Codecs should not be changed with exception of Codec prior-

ities for Codec negotiation. The Codec priorities can be changed according to your spe-

cific network environment.

These are the default settings for Codecs and the default priorities for Codec negotia-

tion:

i The testing mechanism requires that all six test IP addresses are entered.

iThe Voice Module gets up with default settings for its Codecs and negotiates with the

distant station which Codec is to be used.

iIn the event that the distant station does not support codec negotiation you have to

make sure that the codec at the distant station matches the codec with priority “1” at hiG

1600.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



102 A30828-X1187-U125-3-7619


Fig. 3.26 Default settings for Codecs

If necessary, you can change Codec priorities individually per Voice Module as follows:

1. Display the current Codec negotiation table (DISP CODNEGTAB)

2. Set all priorities to be changed to priority = “0”

– Start command MOD CODNEGTAB once per Codec to be changed


– Select Codec Type from the list of Codecs

– Enter the Priority = “0” for the selected Codec

3. Enter wanted priorities – Start command MOD CODNEGTAB once per Codec to be changed


– Select Codec Type from the list of Codecs

– Enter the wanted Priority for the selected Codec

3.5 Security management

The SURPASS security concept for a VoIP network is based on physical and logical net-

work separation.

A “SURPASS network” (region) for VoIP usually consists of a hiE 9200 with its associ-

ated gateways.

According to the security concept there are distinct networks within a SURPASS net-

work which collect hosts with similar security requirements or security tasks.

The hiG 1600 is part of the media network.

This media network may contain several IP subnets (separated by means of VLAN)

transferring different type of IP traffic.

The SURPASS network together with its subnetworks is planned with the SECANT tool.

Additionally to the above VoIP network security concept the hiG 1600 offers these se-

curity functions:

• The hiG 1600 itself is protected from unauthorized access by means of authentica-

tion and access restrictions (white lists) *

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 103

OperationSURPASS


• The hiG 1600 can perform IP/UDP checks

* The management of Windows users, NetManager user groups and assignment to Net-

Manager applications is described in the NetManager Administration Manual

Security tasks at hiG 1600:

3.5.1 Manage “white list” for hosts that may have access to FPU-E/PS-E

You can check or modify the SNMP access lists as follows:

1. For the FPU-E’s SNMP access list follow the instructions in

3.4.2.6 "SNMP access list for FPU-E"

2. For the PS-E’s SNMP access list follow the instructions in

3.3.2.6 "SNMP access list for PS-E"3. Done

3.5.2 Switch on/off IP/UPD check

The IP/UDP check improves the robustness of hiG 1600 against malicious attacks (by

injecting false packets into a connection) and other cases of wrongly inserted packets

which could interfere with active calls.

Per default the IP/UDP check is switched on.

The hiG 1600 checks for received packets the

– source IP address of the packets with its “receive IP address” for the connected

gateway – source UDP port of the packets with its “receive UDP port” for the connected gate-

way

Non-matching packets are discarded.

Switch on IP and/or UDP check for FPU-E

The IP and/or UDP check is switched on for each FPU-E (i.e. for each Voice Module) as

follows:

1. Start task MOD VMODSEC

2. Enter the following parameters

– EQN of FPU-E

– Select the options for parameter Check IP address = Check all channels

or Check NUC channels

– Select the options for parameter Check UDP port = Check all channels or Check

NUC channels

3. Done

3.5.1 "Manage “white list” for hosts that may have access to FPU-E/PS-E"

3.5.2 "Switch on/off IP/UPD check"

iIf your gateway uses another IP send address and/or UPD send port as configured at

the hiG 1600 you have to switch off the corresponding check.

Guidelines

"Switch on IP and/or UDP check for FPU-E"

"Switch off IP and/or UDP check for FPU-E"

http://cmlexch.pdf/

http://cmlexch.pdf/



104 A30828-X1187-U125-3-7619


Switch off IP and/or UDP check for FPU-E

The IP and/or UDP check is switched off for each FPU-E (i.e. for each Voice Module) as

follows:

1. Start task MOD VMODSEC2. Enter the following parameters

– EQN of FPU-E

– Select the options for parameter Check IP address = No check

– Select the options for parameter Check UDP port = No check

3. Done

3.6 Subscriber and trunk management

The optional application Service Provisioner applies for the creation of any kind of sub-

scriber.

Service Provisioner treats hiG 1600 NEs like “regions” which allows to assign port andDN resources to a hiG 1600. In a “region” the Service Provisioner shows exactly the re-

lationship hiG 1600 to controlling hiE 9200 as it has been set up with the NE Adminis-

tration. For further details, refer to the Service Provisioner documentation.

However, this manual provides a brief overview about the tasks for subscribers and

trunks.

The following overview is valid for the DLU-IP, too. Not occupied E1 interfaces of the

DLU-IP can be used for trunks or for V.52 connections.

3.6.1 V5.2 interface

These are the steps to create V5.2 lines:

3.6.1.1 Prepare LTG and LTU

Prepare LTG and LTU as follows:

1. Create LTG (CR LTG)

2. Create signal LTU (CR LTU)

3. Create LTU (CR LTU)

4. Enter PDC characteristics (ENTR PDCCHR)

For detailed information refer to UMN:SURPASS hiE 9200, “VoDSL Administration”

Contents (line variants)

3.6.1 "V5.2 interface"

3.6.2 "Virtual trunking"

3.6.3 "TDM Subscriber at hiG 1600 (via DLU)"

3.6.4 "Private Branch Exchange (PBX)"

3.6.5 "Trunks at hiG 1600"

3.6.6 "Centrex"

3.6.1.1 "Prepare LTG and LTU"

3.6.1.2 "Create V5.2 interface"3.6.1.3 "Create V5.2 subscriber"

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://u100.pdf/

http://u100.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 105

OperationSURPASS


3.6.1.2 Create V5.2 interface

A V5.2 interface is created as follows:

1. Create a V5.2 interface 7100 (CR V5IF)

2. Create V5 link (CR V5LINK)3. Modify V5 timeslots (MOD V5TS)

4. Create V5 communication channel (CR V5CMCHAN)

5. Create V5 communication path (CR V5CMPATH)

For detailed information, refer to OMN:EXCH-SU, CRV5IF

3.6.1.3 Create V5.2 subscriber

A PSTN or ISDN subscriber connected to a virtual V5.2 interface is created with CRSUB.

For further information, refer to OMN:EXCH-SU, TL-Subscriber

For assigning subscriber features, see OMN:EXCH-SU, TL-Subscriber Features

3.6.2 Virtual trunking

The “Operator’s Guide IP Trunking” provides background information on virtual trunking

as well as information on configuration tasks for virtual trunking and its specific features.

For detailed information, refer to Operator’s Guide IP Trunking

3.6.3 TDM Subscriber at hiG 1600 (via DLU)

POTS or ISDN subscribers are connected to hiG 1600 via V93 interface and DLU only.

Thus subscriber management is identical to the set up on a TDM-based LTG/DLU.

A subscriber is created with CR SUB.

Prerequisites for TDM subscriber:

– LTG and DLU equipment are created

– LAC and DN are defined as valid numbers

For further information, refer to OMN:EXCH-SU, TL-Subscriber


3.6.4 Private Branch Exchange (PBX)

Prerequisites for PBX:

– LTG and DLU equipment are created

– LAC and DN are defined as valid numbers

For detailed information on PBX and PBX line administration, refer to OMN-EXCH-SU,

TL-PBX


3.6.5 Trunks at hiG 1600

Trunk management is identical to the set up on a TDM-based LTG.

iAs a prerequisite LAC and DN must be defined as valid numbers.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://q100.pdf/

http://q100.pdf/

http://q100.pdf/

http://a900.pdf/

http://q100.pdf/

http://q100.pdf/

http://q100.pdf/

http://q100.pdf/

http://q100.pdf/

http://q100.pdf/

http://q100.pdf/

http://q100.pdf/

http://a900.pdf/

http://q100.pdf/

http://q100.pdf/

http://q100.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



106 A30828-X1187-U125-3-7619


For further details, refer to OMN:EXCH-RO/NT, OMN_TGRP

3.6.6 Centrex

Refer to OMN:EXCH-CTX, TL

3.7 Performance and Quality of Service management

The Voice Module delivers the following data:

• Statistics data (interface statistics and RTP/RCTP info statistics)

• QoS statistics data for voice/facsimile/modem over IP

The statistics and QoS statistics data are written to a local file at the hiG 1600. The Per-

formance Data Collector application (PDC) collects these data and transfers these

data to the NetManager’s File Server. These data are post processed by specific appli-

cations.

This manual describes the tasks at hiG 1600 that are a prerequisite for collecting the

results with the PDC. For further details on the PDC itself, refer to the PDC manual.

3.7.1 Measurement of statistics data from a specific Voice Module

To collect statistics data with the PDC you first have to set or modify the following pa-

rameters using the task MOD PDCCONFTAB:

– EQN of Voice Module which shall deliver the required data

– PDC collect interval *

(this is the upload frequency for statistics data from hiG 1600 to NetManager)

– Enable PDC = start or stop (start/stop measurement activities)**

– select kind of statistics to be collected (... = “yes” or “no”)

* The “PDC collect interval” depends on the number of measurements that are enabled.For the first measurement you can choose 5 or 15 minutes as PDC collect interval. If

more than one measurement is active then you should choose 15 minutes as PCD col-

lect interval.

** To prevent unnecessary network load do switch off measurement activities as soon

as they are not needed any more.

iThe PDC must be configured appropriately and the corresponding services at the PDC

must be active.

iEach Voice Module has to be prepared for statistics and QoS statistics measurement

individually.

Guidelines

3.7.1 "Measurement of statistics data from a specific Voice Module"

3.7.2 "Measurement of QoS statistics data at the Voice Module"

http://q200.pdf/

http://q120.pdf/

http://cmlexch.pdf/

http://q120.pdf/

http://q200.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 107

OperationSURPASS


3.7.2 Measurement of QoS statistics data at the Voice Module

To collect QoS statistics data with the PDC you first have to execute these steps:

1. "Set thresholds and select service types"

2. "Start/stop measurement and set metering time"

Set thresholds and select service types

At the hiG 1600 you can set the following parameters for QoS statistics data using the

task MOD QOSTHR:

– EQN of the Voice Module which shall deliver the required data

– select thresholds

(if one of these thresholds is crossed then QoS statistics data will be prepared. AQoS trap will be send to NetManager and upon this trap the PDC will fetch the QoS

statistics data immediately)

– select Service type to be monitored using thresholds

Start/stop measurement and set metering time

At the hiG 1600 you can set the following parameters for QoS statistics data using the

task MOD QOSBCONF:

– EQN of the Voice Module which shall deliver the required data

– start/stop QoS measuring state (= ON or OFF)

– set QoS metering time

(this is the time interval between possible QoS traps, i.e. the minimum time between

any QoS traps)

3.8 Accounting management

Accounting data is collected with the optional Accounting Data Collector (ADC). Only

hiE 9200 and Radius server offer tickets.

At the hiG 1600 there are no tasks that are relevant accounting data.

For further information, refer to the ADC user manual.

3.9 Conference Server management

The hiG 1600 can apply as “Conference Server” for large conferences.

This requires specific hardware, see 2.6.2.7 "Special equipment" .

To configure the hiG 1600 as Conference Server, refer to OMN:EXHC-SU, CONFL.

iIn contrast to statistics data, QoS data statistics are only prepared in the event that

thresholds are crossed. A QoS trap informs PDC that data is ready to be fetched and

also initiates a QoS alarm in AMD.

iA QoS alarm is displayed in the AMD in the event that the RTP stream is interrupted orthat any QoS threshold is crossed, see 4.1.2 "Overview about hiG 1600 alarming".

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



108 A30828-X1187-U125-3-7619


3.10 Clock management

3.10.1 Manual switchover for PS-E clock unit

The clock units of the two PS-Es in one shelf form a redundant pair.

At the PS-E start-up it is automatically decided which clock unit becomes the active one

and which clock unit becomes the stand-by one. These clock units monitor each other

and in the event of an failure the stand-by clock unit automatically takes over and be-

comes the active clock unit.

You can manually switch over between active and stand-by clock unit. If switch-over is

not possible, this request is denied by the PS-E.

Switch over steps:

1. Initiate switch over at one of both clock units as follows:

– Press switch-over button module

or

– Initiate switch-over with MOD TDMCLKCONF

2. Is switchover executed?

– Yes: The stand-by clock unit took over.

Done

– No: Try switchover at the other clock unit,

continue with next step

3. Is switchover executed?

– Yes: Done – No: Only the master clock unit is supplied with external reference clock. Switcho-

ver is not possible in this situation (see Tab. 3.9 "Manual switchover initiation").

Done

You can look up the state and the details for a specific clock unit with DISP TDMCLK-

CONF.

3.10.2 Clock source selection

The external reference clock source for hiG 1600 is selected at the PS-E via cabling.

For further details, refer to the Construction Manual and to your project-specific docu-

mentation.

Contents

3.10.1 "Manual switchover for PS-E clock unit"3.10.2 "Clock source selection"

External reference clock Initiate switchover at

neither at master nor at standby clock unit standby clock unit

master clock unit and standby clock unit master clock unit

at master only none (switchover is denied)

Tab. 3.9 Manual switchover initiation

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 109

OperationSURPASS


Additionally you have to enter the appropriate parameters for the external reference

clock source via NetManager’s Workbench, refer to 3.3.4.3 "Manage PS-E’s TDM clock

input".

You can look up the state and the details for a specific clock unit with DISP TDMCLK-CONF.

3.11 “Time of day” management

To log events all manageable entities in hiG 1600 need an exact time of day.

Time of day synchronization (ToD) for hiG 1600 modules is done in different ways.

• ToD is distributed by hiE 9200 to all Feature Processors via ACP

(in intervals of about one hour)

• ToD is distributed by a SNTP server (NetManager) to PS-Es and VMs.

– The VM gets ToD in intervals of about 24 hours.

– The PS-E gets ToD in intervals of about 15 minutes (not relevant for DLU-IP)The SNTP server is entered via BCSS.

– You can find SNTP data for a Voice Module in the “FPU Specific Data” tab. To

change the corresponding entries, refer to "Modify FPU-E node"

– You can find SNTP data for a PS-E in the “Server Data” tab. To change the corre-

sponding entries, refer to "Modify PS-E node" (not relevant for DLU-IP)

3.12 Trap destination management

For SNMP traps from hiG 1600 there are two kinds of trap destinations:

– Trap destination servers belonging to NetManager

– External trap destination serversThere are several ways to enter trap destinations for hiG 1600.

• Trap destinations for PS-E

– Primary and secondary trap destination server belonging to NetManager are en-

tered via BCSS, see 3.3.2.4 "Creating/modifying/deleting PS-E nodes"

– A Maximum of three external trap destination servers (if there is no secondary

TDS belonging to NetManager) can be entered via BCSS, see

3.3.2.4 "Creating/modifying/deleting PS-E nodes"

– Alternatively external trap destination servers can be entered via Workbench,

see 3.12.1 "Managing external trap destinations for PS-E via Workbench".

• Trap destinations for FPU-E

– Primary and secondary trap destination server belonging to NetManager are en-

tered via BCSS, see 3.3.2.4 "Creating/modifying/deleting PS-E nodes"

– External trap destination servers can be entered via Workbench, see

3.12.2 "Managing external trap destinations for FPU-E via Workbench".

3.12.1 Managing external trap destinations for PS-E via Workbench

After reboot with DHCP or during BCSS consistency checks the Trap Destination Server

list on PS-E is changed back according to the entries listed in the PS-E-specific “Server

Data” property page of BCSS for this PS-E node.

iThis task shall only be used for service purpose. It is recommended to manage all kinds

of trap destinations using BCSS.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



110 A30828-X1187-U125-3-7619


Like any other configuration via Workbench, the temporary trap destinations entered via

Workbench can be made permanent with a board backup using Software Management.

Nevertheless, the consistency check or a reboot with DHCP might replace entries made

via Workbench.

The PS-E accepts a maximum of four trap destination servers. If you have already en-

tered all four trap destinations using BCSS then you cannot enter any additional trap

destinations via Workbench. You first have to delete any of the existing entries.

You can enter a temporary trap destination server for a PS-E as follows:

1. Start CR TDSE


– EQN of PS-E

– Target address

You can display all trap destinations with DISP TDSE.

3.12.2 Managing external trap destinations for FPU-E via Workbench

In principle external trap destinations entered via Workbench for FPU-E are temporary

and are lost after reboot. However, they can be made permanent by a backup using

Software Management.

You can enter an external trap destination server for a FPU-E as follows:

1. Start CR TRAPDESTE


– EQN of PS-E

– Trap Community

– Trap Ip Address

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 111

OperationSURPASS


4 MaintenanceThe chapter 5 "DLU-IP" collects DLU-IP-specific items and refers to other sections in

this chapter relevant for the DLU-IP.

4.1 General

4.1.1 Using NetManager and its applications for hiG 1600 maintenance

Maintenance context

This manual covers just a part of the whole network, i.e. the hiG 1600 functional units

FPU-E, PS-E. Thus network components beyond the hiG 1600 interfaces are not con-

sidered.

This maintenance chapter assumes that the hiG 1600 hardware and software is usually

remotely administrated, i.e. administration from a central NetManager. Please refer to

the Construction Manual to evaluate any LED indicators on the modules on site.

The HW/SW alarms from the hiG 1600 can be accompanied by hiE 9200 HW/SW

alarms. You can find an overview about all alarms that play a role for the hiG 1600 in

4.1.2 "Overview about hiG 1600 alarming".

Alarming surveillance for hiG 1600

NetManager’s alarm surveillance applications provide an overview of the alarm status

of the whole network, a detailed list of all actually open alarms and an alarm history. Fur-

thermore you are assisted clearing the alarms.

Section Contents

4.1 "General" General information concerning hiG 1600 mainte-nance and maintenance applications, fault clear-ance methods and overview about all alarms andalarm dependencies, switchover mechanisms

4.2 "Starting the fault clearance" Fault clearance guideline

4.3 "SNMP messages from FPU-E(VM part)."

SNMP-based maintenance for the FPU-E’s VoiceModule

4.4 "SNMP messages from PS-E" SNMP-based maintenance for the PS-E

4.5 "SW update" Load new SW (Firmware) onto hiG 1600 modules

4.6 "Executing a brief function test" Test some basic functions of hiG 1600

4.7 "Replacing hiG 1600 modules" Replace a hiG 1600 module during operation

4.8 "Backup/restore hiG 1600 data-base"

Handling the hiG 1600 database

4.9 "Symptom saving" Read/save fault symptoms for special fault clear-ance (for example on request of TAC)

4.10 "Troubleshooting hints" Treat problems that might not be not visible in Net-Manager’s surveillance applications

Contents

4.1.1 "Using NetManager and its applications for hiG 1600 maintenance"

4.1.2 "Overview about hiG 1600 alarming"

4.1.3 "Redundancy and failover functions for hiG 1600"



112 A30828-X1187-U125-3-7619


These alarm surveillance applications play a role for the hiG 1600:

• Topology Map Viewer

Shows alarm information in maps and provides an alarm summary for NEs. The To-

pology Map viewer applies for monitoring large networks and provides a relation be-

tween alarm and location.

(You can start the AMD from the Topology Map Viewer.)

• AMD (Alarm Message Display)

Shows all kind of alarms and messages from hiG 1600 and alarms from NetMan-

ager (OS alarms). You can confirm and/or clear alarms in the AMD.

(You can star t the Containment View from the AMD.)

• Alarm Console

Displays all MML-based unsolicited messages and automatically is logging incom-

ing messages

Additionally status information for hiG 1600 is delivered by the Containment View. The

Containment View displays the actual alarm state of the SNMP nodes and their con-

tained equipment. By propagation the Containment View shows the relation between

alarms and network elements.

Using the LogViewer you can display all SNMP traps, except SLMI alarm state traps.

However, only SLMI traps cause an SNMP-based alarm that is visible in AMD.

Alarms and messages caused by Feature Processors (LTGx/FP-P) or special equip-

ment (LTU:S) of a hiG 1600 will be generated by the corresponding hiE 9200 and sent

via MML interface to the NetManager as hiE 9200 alarms.

Fault clearance concept

There are different ways to start with fault clearance for hiG 1600.

1. Fault clearance with Interactive Document Browser started via AMD

For alarms with a MMN key (except OS alarms and SNMP alarms which might pro-

vide details in the online help or in AMD’s “additional text” area respectively) you can

jump to the required maintenance procedure in an online manual from the AMD.

You are guided through trouble shooting in a step by step procedure.

You should first confirm the alarm to keep track on alarms that are processed al-

ready. Then, after eliminating the fault, you should clear the corresponding alarm (if

not cleared automatically by AMD). *

There are no online maintenance procedures for the STMI equipment. This has to

be treated with TMNS-C.

2. Fault clearance with online help started via AMD

OS alarms from NetManager also have an MMN key, but are cleared using the Net-

Manager online help.

3. Fault clearance with Work Order Viewer *

A work order can be send together with an alarm providing details whether the alarm

has been treated already.

You have to open the Work Order Viewer to read any work orders.

You should confirm the alarm to keep track on alarms that are processed already.

Then, after eliminating the fault, you should clear the corresponding alarm (if not

cleared automatically by AMD).

iThere might be simultaneous alarms in several applications, for example if a Voice Mod-

ule is not accessible, this is indicated in the AMD and Topology Map Viewer as well as

by an error state in the Containment View.



A30828-X1187-U125-3-7619 113

OperationSURPASS


4. Fault clearance by “manually” evaluating the information (details, reasons) delivered

by AMD or Containment View.

For alarms based on SNMP messagesyou can look up the meaning of the displayed

status with its details in this manual and clear the error according to the information

provided from this manual.

5. Fault clearance with TMNS-C

(Covers STMI-specific part, only in the event that hiG 1600 is equipped with STMI)

For evaluating messages from STMI, refer to UMN:STMI.

6. Trouble shooting hints and FAQ

Clear functional problems according to “trouble shooting hints”

* MML messages of type “CALL IDENTIFICATION” can neither be confirmed/cleared in

AMD nor processed in a work order.

Executing commands for fault clearance

• In principle all types of commands are started via NetManager’s Workbench.

•

For STMI maintenance you additionally need TMNS-C (screen-level integrated onNetManager).

Evaluating SNMP messages using Containment View and Log Viewer

The Containment View displays the propagated states for the hiG 1600 equipment to-

gether with the corresponding EQN of the module/port in question, whereas the Log

Viewer displays any traps for IP addresses.

With the “properties” context menu in Containment View or with the BCSS you can look

for the corresponding IP address of the specific node EQN.

To analyze any alarms in Containment View, proceed as follows:

– Evaluate information from the Containment View and Log Viewer for the VM, see

4.3 "SNMP messages from FPU-E (VM part).".

– Evaluate information from the Containment View and Log Viewer for the PS-E, see

4.4 "SNMP messages from PS-E".

Alarm forwarding of hiG 1600 alarms

NetManager has a complete built-in alarm handling concept. In case alarms need to be

forwarded to other operating systems (OS), an additional X.733 interface is provided.

iIn the event that a fault cannot be cleared with any of the methods above, contact TACand refer to 4.9 "Symptom saving"

iFor further information on PS-E or PSC-C/VMC in Containment View, refer to3.3.3 "Monitoring PS-E using Containment View" or 3.4.3 "Monitoring FPU-E usingContainment View".

iIn addition to the alarm/operational state displayed by the Containment View you mighthave to consider the administrative state of a module/port.

The administrative state of a Voice Module can be requested with the task DISPMOD-STATE. The administrative state of an individual Voice Module interface can be re-quested with the task DISP AIFATT.

There is no administrative state for the PS-E on module layer. However, the administra-

tive state of all interfaces belonging to a certain PS-E can be requested with DISPPORTCONF.

http://u190.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://u190.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



114 A30828-X1187-U125-3-7619


Alarms from hiG 1600 are converted by NetM into a standardized alarm report (conform

to X.733 standard).

These X.733 alarm reports are passed to the alarm data service (ADS) which forwards

them to a higher OS via an SNMP proxy agent.The following requests can be handled by ADS:

– Setting of "sendAllAlarms" for sending spontaneous alarms for all open alarms with

detailed data on the individual alarms

– Setting of "setPeriod" for periodic Summary alarms

For more details about alarm forwarding, refer to the NetManager documentation.

4.1.2 Overview about hiG 1600 alarming

(*) OS alarm - NetManager alarms a connection problem for its SNMP access to a hiG

1600 unit.

(***) Alarm severity “critical” for module results from alarm propagation of PS-E port(s).

If a port gets state “critical”, this is propagated up to the corresponding PS-E module

External alarms: are sent from PS-E which is alarm handler and also alarm master for a

rack..

Alarm

initiator

Alarmed in-

stance

Alarmed

class

Alarm

severity

Alarm detail NetM’s

alarm

support

hiE 9200

corre-

spondingalarm

VM EQN of Ether-

net port

port major CV, ADS PCM R.A.

VM EQN of VM module major CV, ADS PCM R.A.

QoS EQN of VM port

Clock port

SN IF port

NetM EQN of VM module major CV, ADS* PCM R.A.

NetM EQN of PS-E module critical

(***)

n.a. CV, ADS*

PS-E EQN of PS-E

uplink

port critical n.a. CV, ADS

PS-E External alarm sensor config-

urable

details are dis-

played

CV, ADS

PS-E Clock alarm

(clock unit +

reference

clock input)

port/sensor ma-

jor/critical

details are dis-

played

CV, ADS

PS-E GW supervi-

sion alarm

sensor major or

critical

details are dis-

played

CV, ADS

Tab. 4.1 Overview about hiG 1600 alarms

iAll SNMP traps are stored in the Log Viewer. These traps can be exported for symptomsaving or evaluated for special fault clearance (see 4.9 "Symptom saving").



A30828-X1187-U125-3-7619 115

OperationSURPASS


4.1.3 Redundancy and failover functions for hiG 1600

Central hardware components (and interfaces) of hiG 1600 are redundant. Appropriate

failover mechanisms ensure that there is no permanent loss of bearer or control connec-

tions due to a single failure.

Key features for redundancy:

– Redundant interfaces at hiG 1600 hosts (e.g. Voice Module)

– Redundant internal LAN (i.e. redundant L2 switches)

– Redundant edge router (or redundant router supporting VRRP)

– Connection of each edge router to at least two core router

– Redundant reference clock

hiG 1600’s failover mechanism comprises these stages:

– Failure detection

– Fail over executing

Term Description

ADS NetManager’s Alarm Data Service immediately forwards the alarm either as a new

one or as an old one. Its IP address and its NE name in the trap that has been sent

by ADS identify the hiG 1600 unit.

ADS* NetManager’s Alarm Data Service forwards the alarm due to NetM’s internal resyn-

chronizationmechanisms that maycausesome delay.Its IP address andits NE name

in the trap that has been sent by ADS identify the hiG 1600 unit.

ADS** NetManager’s Alarm Data Service immediately forwards the alarm either as a new

one or as an old one. The MG domain name in the trap that has been sent by ADS

identifies the hiG 1600 unit.

Alarm initiator Instance that discovers a problem and initiates an alarm.

The NetM supervises the OAM connection to PS-E and VM

(NetM polls PS-E or VM, if polling is not successful -> OS alarm)

The hiE 9200 supervises the hiG 1600 unit with its TDM ports.

AS NetManager’s Alarm Surveillance displays the hiE 9200 alarms

Correlated alarms

in hiE 9200

An hiG 1600 alarm may correlate to an alarm of hiE 9200.

The hiE 9200 alarms the outage of a hiG 1600 unit (LTG alarm), the outage of the con-

nection between hiE 9200 and hiG 1600

The hiG 1600 informs the hiE 9200 about PCM system outages. On reception of such

a message hiE 9200 initiates a PCM R.A.

Note that the outage detection period via hiE 9200 alarms is shorter than via SNMP.

CV The C ontainment View displays s tatus information o f the h iG 1600 e quipment in a hi-

erarchical order with status details.

CV* The Containment View r emoves the hiG 1600 node from the hierarchy tree and status

browser and replaces it by the icon “Not available”.

PCM R.A. The PCM R.A. is a hiE 9200 alarm without alarm severity and thus it can not be for-

warded by ADS.

Tab. 4.2 Descriptions to alarm overview

!Exception: The STMI is connected to one PS-E only. A failure of this PS-E interrupts the

OAM connection to the connected STMI, until the failure has been cleared.

iAs a prerequisite for failover functions test IP addresses must have been entered foreach Voice Module, see 3.4.4.5 "Manage Voice Module’s test interfaces"



116 A30828-X1187-U125-3-7619


– Switch back to original configuration (optionally), as soon as the failure disappears

* STMI owns only one Ethernet interface, thus failover is not possible.

The “failover on demand function” applies for upgrade or repair scenarios (e.g. module

replacement).

VMC/PSC-C: interface failover

Interface failover is ensured for VM in PSC-C as well as for VM in VMC.

The VM owns four Ethernet interfaces including associated MAC addresses.

Interface failover means that the VM moves the IP addresses for payload/control/OAM

traffic (that are affected by an error) from one Ethernet interface to the redundant one.

iNone of these failover types in table Tab. 4.3 "Failover with hiG 1600" will interrupt anypayload (except fax connections). Message or packet loss however cannot be avoided.

Unit Failover type Failovertriggered

by

Automaticswitch back

Demand failover sup-ported

VM/PSC Interfacefailover

VM No Yes(via Workbench with SETIFSWITCH)

Gatewayfailover

VM Yes Yes(via Workbench with SETRSWITCH)

Interface andgatewayfailover

VM Switch back todefaultgateway,but interface iskept

No (but can be done in twosteps):1. interface switchoverwith SET IFSWITCH2. gateway switchover withSET RSWITCH

Clock failover VM Yes No

PS-E Clock failover(master/slave)

PS-E No Yes(via switch on PS-E mod-ule or via Workbench,refer to 3.10.1 "Manual

switchover for PS-E clockunit")

PS-E Gatewayfailover (OAMonly)

PS-E Yes No

STMI Gatewayfailover *

n.a. No No

MBD Messagechannelfailover

hiE 9200(CP)

Yes Yes (via MBD configura-tion command,refer to hiE 9200 docu-mentation)

Tab. 4.3 Failover with hiG 1600

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 117

OperationSURPASS


VMC/PSC-C/PS-E: gateway failover

Usually there are routes configured via default gateway and via redundant gateway for

hiG 1600. For each traffic type there might be separate gateway sets.

In the event that there is an error in the connection to a default gateway for a specifictraffic type, a switchover to the redundant gateway is executed. That means hiG 1600

hosts (VMC, PSC-C, PS-E) send the corresponding traffic type to the redundant gate-

way.

Gateways for other traffic types are not affected.

The hiG 1600 switches back to the default gateway as soon as this gateway becomes

active again.

VMC/PSC-C: link test to gateway

Interruption of physical paths between hiG 1600 hosts VMC/PSC-C and corresponding

gateways is detected by link tests. The VMC or PSC-C sends a test message to the rout-

er with its own address as destination address.

PS-E: link test to gateway

Interruption of physical paths between hiG 1600 hosts PS-E and corresponding gate-

ways is detected by link tests.

The PS-E periodically sends an ARP broadcast message to look for the MAC address

of the default gateway. If there is no response from the default gateway, a switchover to

the redundant gateway is executed.The availability of the redundant gateway (if appropriate) is also tested periodically using

ARP. In the event that there is an error an alarm trap is sent.

VMC/PSC-C: clock failover

By default the VM at VMC/PSC-C gets its reference clock from PS-E_0. If this clock is

lost, the VM switches over to the clock signal from PS-E_1.

On recovery of the clock signal from PS-E_0, the VM automatically switches back to this

clock signal.

PS-E: clock (master/slave) failover

Each PS-E gets a reference clock from the redundant PS-E and from an “upper layer”

PS-E in the same plane (daisy chain). The “main” PS-E on top of this chain gets an ex-

ternal clock (e.g. “central reference clock”).

A redundant pair of PS-Es negotiate which one is master and which one is slave. The

master provides the clock signal to the slave.

If the clock from the master is lost the slave switches over to the alternate reference

clock input from the “upper layer” PS-E.

iLink tests from VMC/PSC-C would evoke ICMP redirect messages from the addressed

edge router. Therefore you have to switch off ICMP redirects at the edge routers that

are connected to hiG 1600.

iPS-E and STMI only generate OAM interfaces. Thus switchover is not as critical as for

payload or control traffic.



118 A30828-X1187-U125-3-7619


All PS-Es in the daisy chain get the same clock from the same clock source. This holds

true for normal operation as well as in failure situations. A failure does not propagate

through the whole chain.

Fig. 4.1 Clock daisy chain

Fig. 4.2 Clock redundancy

If a redundant pair of PS-E fails the remaining PS-Es in the chain will run at a free run-ning clock of one PS-E. However this is a double failure scenario.

MBD: message channel failover

The hiE 9200 executes a message channel switchover in the event that the active mes-

sage channel fails.

Router / L3 switch: fast route failover

At each router or gateway there are two alternative paths to a subnet. A crosslink be-

tween gateways ensures fast failover to an alternate route.



A30828-X1187-U125-3-7619 119

OperationSURPASS


The information on accessible hiG 1600 subnets and associated costs is distributed to

other routers. This way all routers in the network know the lowest cost route to the hiG

1600 via a dedicated gateway.

The gateway or core router recognizes the physical outage of a (direct) interface veryfast and forwards all traffic via an alternate route. Thus negative impacts on existing con-

nections (call interruption/loss) are avoided.

The router switches back to the original path as soon as the failed interface is active

again.

Router / L3 switch: traffic rebalancing

The gateways and routers monitor availability of physical paths to a destination site via

routing protocols. Interface failures are reported to other network elements which adapt

their routing tables accordingly. Thus traffic in the network is rebalanced.

As soon as the failed network path is active again the routers will switch back to this path

again and update their routing tables.

4.2 Starting the fault clearance

This section provides a brief-guideline how to begin with fault clearance.

In principle the kind of alarm determines the consecutive steps.

Fault clearance assumes the following:

• Correct SW version is loaded at the module

(for further details, refer to 4.5 "SW update")• The HW is prepared correctly

– The module in question is plugged in correctly

– All cables to the module in question are plugged in correctly

(to check this, refer to the Construction Manual and to your project-specific docu-

mentation)

• The module/port in question is not manually disabled (i.e. not in administrative state

“down” or “mbl”)

Alarms in AMD (example):

iSaving calls is mainly ensured by the fast route failover mechanism instead of the slow

traffic rebalancing mechanism.

iUsually the AMD is the tool to monitor any alarms for your hiG 1600 (see "Fault clear-ance concept"). However, you can monitor large networks with the Topology Map View-er and call the AMD for a specific alarm via context menu from the Topology Map

Viewer.



120 A30828-X1187-U125-3-7619


Fig. 4.3 Main tab in AMD showing alarms

For fault clearance proceed as follows:

1. Do you have an alarm in the Topology Map Viewer or in AMD?

– No: There is a problem without any specific alarm.

Continue with 4.10 "Troubleshooting hints"

– Yes: Continue with next step

2. Confirm the alarm in the AMD

3. Select the “Main” tab in the AMD’s right window pane

What is the “Alarm type”? (see Fig. 4.3 "Main tab in AMD showing alarms")

– “OS”: go to 4.2.2 "OS alarms from NetManager"

– “MML” or “Q3”: go to 4.2.1 "Online fault clearance procedures via IDB"

– “SNMP”: go to 4.2.3 "SNMP alarms from hiG 1600"

4.2.1 Online fault clearance procedures via IDB

The hiE 9200, the Feature Processor and the LTU:S might send an MML or Q3 alarm.

MML/Q3 alarms are cleared using the online maintenance manuals. Using the MMN key

the appropriate MMN procedure is called.

Clearing an MML/Q3 alarm

To clear alarms using the online manuals proceed as follows:

1. In the AMD call the function “Action” -> “Maintenance Manual”

2. Clear error according to the instructions of the maintenance manual

iIn the event that you cannot clear the alarm inform the responsible TAC and continuewith 4.9 "Symptom saving".

iIn the event that there is an alarm from a Feature Processor (FPP/LTGx) you can re-quest the type of Feature Processor with the task DISPBCONF.(“Configuration type = fpp...” stands for PSC-C, “Configuration type = mp480...” standsfor VMC connected to external LTG via cable)



A30828-X1187-U125-3-7619 121

OperationSURPASS


3. Done

4.2.2 OS alarms from NetManager

Whenever periodical polling to a SNMP node fails an OS alarm is sent, indicating that

the NetManager cannot access this specific SNMP node. As soon as the SNMP node

is available again, the alarm will be cleared automatically.

For the hiG 1600 this means a FPU-E or a PS-E is not accessible from NetManager.

In this case a Communication Alarm according to X.733 standard is generated with a

specific MMN key (TEAG1_IAM_0001) and can be forwarded to higher management

systems.

Communication alarms are critical alarms and thus immediate action is necessary.

Possible errors:

• Fault in the NetManager OS

• Fault in the connection between NetManager and hiG 1600• Fault in hiG 1600 itself

In the Containment View the corresponding node (or NE) is indicated as “unmanaged”.

OS alarms are cleared using the online help. Using the MMN key the appropriate help

topic is called.

Clearing an hiG 1600 OS alarm

1. Open the corresponding help topic

2. Clear error according to the instructions in the online help

3. Done

4.2.3 SNMP alarms from hiG 1600

Brief guideline for clearing SNMP alarms:

1. The “Main” tab in AMD’s right window pane tab tells you the NE (NE Name) and the

module, port or sensor (Managed Object Instance) where the error occurred.

2. Select the “Original Alarm” tab in the AMD’s right window pane.

This delivers the “Alarm Reason” and the “Alarm Details” of the specific alarm. Fur-

ther information (for example “Operational state Reasons/Details”) can be found in

Containment View.

3. Open the Containment View

– select the NE in question

– select the module or port/sensor that sent the alarm

4. Find the matching table row in this manual and clear the error according to the infor-

mation assigned to this row.

– For clearing SNMP alarms from FPU-E, refer to 4.3.2 "Evaluating states and cor-

responding details for VM"

– For clearing SNMP alarms from PS-E, refer to 4.4 "SNMP messages from PS-E"

5. Could you solve the problem?

(Alarm vanishes from AMD and Containment View)

– Yes: Done

– No: Start “discovery” in BCSS

(Containment View is refreshed automatically.)

6. Could you solve the problem?(Alarm vanishes from AMD and Containment View)



122 A30828-X1187-U125-3-7619


– Yes: Done

– No: Continue with next step

7. Try this: 4.10 "Troubleshooting hints"

8. Could you solve the problem?

(Alarm vanishes from AMD and Containment View)

– Yes: Done

– No: Contact the responsible TAC, and save error symptoms, see 4.9 "Symptom

saving"

4.3 SNMP messages from FPU-E (VM part).

4.3.1 General

Basically, the FPU-E’s VM sends messages (traps) to the NetM if a state changes.

These traps can be generated from the modules or from the corresponding ports andthere are separate traps for alarm state and operational state.

However, there are some exceptions: an operational state change does not always

cause an alarm state trap (e.g. if a module has been configured manually to administra-

tive state "down").

The following traps refer to the physical layer and lead to the Combined States (com-

bination of alarm state and operational state) that are displayed by icons in the Contain-

ment View:

– slmiAlarmStateTrap --> Alarm State in Containment View, Alarm in NTM/AMD

– slmiOpStateTrap --> Operational State in Containment View

After recovery an entConfigChange trap is sent, an autodiscovery procedure is started

and the structure (containment) of the network element is read.

The autodiscovery refreshes the display of the Containment View, so that there can be

an indirect effect on the displayed combined states of your hiG 1600.

Further additional protocol- or service-specific traps may be sent (for example packet

loss and jitter). For these measurements, thresholds can be defined. In case of violation

of these values, traps are sent to the NetManager, see 3.7 "Performance and Quality of

Service management".

The Containment View displays the following combined states (alarm state and opera-

tional state combinations) for the VM:

• Module-based

(In Containment View displayed as “Module” in the “Class” column) – States and alarms for the VM itself

iThis section treats the VM part of the PSC-C or VMC. That means only SNMP messag-es from the VM are considered. MML/Q3 messages from the Feature Processor or spe-cial equipment (LTU:S) are treated by online procedures, see 4.2.1 "Online faultclearance procedures via IDB"

iTo find the mounting location of a PSC-C/VMC, refer to Tab. 3.8 "Relation betweenMOLOC and module number in CV for PSC(D)".

Contents

4.3.1 "General"

4.3.2 "Evaluating states and corresponding details for VM"



A30828-X1187-U125-3-7619 123

OperationSURPASS


• Port-based

(In Containment View displayed as “Port” in the “Class” column)

– States and alarms for the SN interface

– States and alarms for the Ethernet interface

– Quality of Service alarms

– Clock alarms

4.3.2 Evaluating states and corresponding details for VM

Proceed as follows:

1. Find the status display in the corresponding table.

– Module status for VM (Class=”Module”), go to Tab. 4.4 "VM’s module states"

– Port status for VM (Class=”Port”), go to Tab. 4.5 "VM’s port states"

2. Look up meaning and necessary actions in Tab. 4.6 "Evaluation table for VM mod-

ule/port states".

Type Class Alarm

State

Operational

State

Operational/Alarm

State Reason

Operational/Alarm

State Details

Row# in

Evaluation

table

VM Module Normal Up Normal Not applicable 1

Major Restricted Missing configuration

data

SNMP: awaiting

Ethernet configuration

data

2

Major Restricted Configuration error/

TOG: no download

done

Configuration error/

TOG: no download

done

3

Minor Restricted Configuration error/

Normal

Not applicable/

No backup data avail-able

4

Minor Restricted Normal/

Start up

Not applicable 5

Minor Testing Admin state MoPC board configu-

ration

6

Major Down HW error <Different reasons

possible>

7

Minor Normal warmStart/

Normal

SW fallback/

Not applicable

8

Tab. 4.4 VM’s module states

Type Class Alarm

State

Operational

State

Operational/Alarm

State Reason

Operational/Alarm

State Details

For Evalua-

tion go to

Other Port Normal Up Normal Not applicable 9

Major Down Link error/

Normal

Not applicable 10

Normal Down Normal Not applicable 11

Tab. 4.5 VM’s port states



124 A30828-X1187-U125-3-7619


Meaning of module/port states and resulting operator actions:

Ether-

netcs-

macd

Port Normal Up Normal Not applicable/

<Different possibili-

ties>

12

Major Down Link error/

Normal

Not applicable 13

Normal Testing Normal Not applicable 14

Normal Down Normal Not applicable 15

Refer-

ence

clock

Port Normal Up Normal Not applicable 16

Normal Up Link error/

Normal

Not applicable 17

QoS Port Normal Up Normal Not applicable 18

Minor Up QoS alarm Not applicable 19

Row# Meaning Repair Action

1 The VM is up and running and is able to transferpayload (callprocessing is possible)

A backup file is available at the module.

No fault(no operator action re-quired)

2 The VM is not completely up because of missing

data for callprocessing.

The VM is not able to transfer payload.

Check/enter IP addresses

at VM, refer to3.4.4 "Configuration tasksfor FPU’s Voice Module"

3 The VM cannot load TOG on Feature Processor Read SW Error Notebook(task DISPNB),

Boot again (if appropriate)

Inform TAC if error cannotbe cleared(Maybe module must be re-placed)

For module replacementrefer to 4.7.1 "ReplacingVMC (MP480 module) orPSC-C (FPP module)"

Tab. 4.6 Evaluation table for VM module/port states

Type Class Alarm

State

Operational

State

Operational/Alarm

State Reason

Operational/Alarm

State Details

For Evalua-

tion go to

Tab. 4.5 VM’s port states



A30828-X1187-U125-3-7619 125

OperationSURPASS


4 The VM is up and running and is able to transferpayload (call processing is possible).

However a backup file is not available at themodule.All configuration data entered via Workbenchwill be lost after the next reboot!

Create backup file, see4.8.1 "Backup and restorefor the Voice Module"

5 The VM is not up yet. Thus call p rocessing isnotpossible.

Wait until VM is completelyup

6 The VM is in state “MBL”. No fault(if required, configure to ad-ministrative state “up”, see3.4.4 "Configuration tasks

for FPU’s Voice Module")

7 HW error at VM

Call processing is not possible!

Replace VM, see4.7.1 "Replacing VMC(MP480 module) or PSC-C(FPP module)"

8 The Voice Module executed a fallback to “Gold-en Code”.

The current SW is damaged, or lost.

Load new SW, see4.5.1 "SW update on VoiceModule"

9 The SN interface to FPP/LTG is active.

The message channel is operational.

No fault(no operator action re-

quired)

10 The SN interface to FPP/LTG is not active.

The FPP/LTG cannot be reached via this mes-sage channel

PSC-C -> Replace moduleVMC-> Check cabling betweenVMC and LTGIf error cannot be cleared,refer to MMN:LTG

11 The SN interface is configured to administrativestate “down”.

UnconnectedSN interfaceshave to be configured tostate “down” to prevent un-

wanted alarms.

No action required if SN in-terface is unconnected

12 The Ethernet interface is active. The “Operation-al State Details” inform about the kind of trafficvia this interface:- OAM- OAM and Control- Payload- Control and Payload- OAM, Control and Payload

No fault





126 A30828-X1187-U125-3-7619


4.4 SNMP messages from PS-E

4.4.1 General

The PS-E sends these kinds of SNMP traps:

• coldStart (autodiscovery of PS-E node)

• link up/down traps (from configured uplink ports and cross channel))

The PS-E sends a link trap if the link status changes. This link trap contains opera-

tional state (actual state) and administrative state (rated value). NetManager com-

bines these states to a link alarm status. This status can be monitored with

Containment View.

13 Link to PS-E interrupted or PS-E not pluggedorRouter not available via this interface(assuming that test IP addresses are config-ured)

DLU-IP-> Check network environ-menthiG 1600-> Check connection be-tween VM and PS-E

14 Stand by interfaceNo active IP traffic except test messages

No fault

15 The Ethernet interface is configured to “down”.To prevent unnecessary alarms this should bedone for port *-*-*-21 and *-*-*-22 if OAM, con-trol and payload traffic are transferred via thetwo other interfaces.

No fault

16 VM is supplied with clock No fault

17 VM lost clock Check reference clock andcabling to reference clock

18 No QoS alarm No fault

19 Thresholds for QoS are crossed. A QoS file iscreated and is fetched by PDC (if activated).

Evaluate QoS data usingPDC (if appropriate)

To check or modify thresh-olds for QoS monitoring, re-fer to 3.7.2 "Measurement

of QoSstatistics data at theVoice Module"

Check network environ-ment



Contents

4.4.1 "General"4.4.2 "Status propagation"

4.4.3 "Operational and alarm state combinations for PS-E ports"



A30828-X1187-U125-3-7619 127

OperationSURPASS


• SlmiAlarm trap (from external alarm interfaces, clock interfaces, gateway informa-

tion interfaces)

The PS-E sends a SlmiAlarmState trap if the SLMI status changes. This SlmiAlarm-

State trap contains operational state (actual state) and alarm state. The operational

state and the alarm state can be monitored with Containment View.

Additionally there are slmiOpState and slmiAlarmState traps indicating whether the PS-

E works with a default VLAN/port configuration or whether the PS-E works with a user-

defined configuration. In the event that a user-defined configuration is not valid any more

and the PS-E changes automatically to a default configuration this is indicated by a

AlarmState “warning”.

Alarm states are propagated up the PS-E node level and further up to the NE and net-

work level.

The NetManager does not evaluate all PS-E traps (e.g. traps for interfaces to Voice

Modules are not evaluated). Nevertheless, in Log Viewer coldStart, linkup, linkdown, ad-

minState and operationalState traps are registered. But LogViewer does not registerany alarmState traps.

These conditions cause an alarm for PS-E in NetManager:

• whenever NetManager can not reach PS-E (after polling) -> OS alarm

• whenever an PS-E uplink or cross channel fails -> port alarm

(exception: manual configuration from “up” to “down” by operator)

• external alarm, clock alarm, gateway alarm -> SLMI alarm

•

PS-E startup without valid backup file -> SLMI alarm

4.4.2 Status propagation

Alarm status propagation up to the external alarm sensors “module”:

• Alarm state = Propagated Alarm state

• Alarm state = “Normal” if at least one sensor has status “Normal” and no sensor has

status “minor” , or worse

• Alarm state = “Disabled” if all sensors have alarm status “Disabled”

• The alarm state ot the clock sensors module is set to the most critical alarm state of

all its sensors for all other cases

Alarm status propagation up to the clock sensors “module”:


• The alarm state ot the clock sensors module is set to the most critical alarm state of

all its sensors

Alarm status propagation up to the PS-E node:


• The alarm state of the node is set to the most critical alarm state of all its interfaces

or sensors (modules that are disabled or in “stand-by” are disregarded).

Operational status propagation up to the PS-E node:

• All configured ports are up -> Operational state of node is “UP”

• No port has state “UP” -> Operational state of node is “DOWN”

•

At least one port is not in state “UP” -> Operational state of node is “RESTRICTED”

!To get the correct state evaluation in NetManager, it is important that PS-E operation

mode (redundancy) is correctly set in BCSS and that PS-E’s connected uplink ports are

correctly configured.



128 A30828-X1187-U125-3-7619


4.4.3 Operational and alarm state combinations for PS-E ports

The following table is valid for cross channel and uplink ports.

Port states Node states Remark

Opera-

tional

states

Alarm

states

Operational

state

Alarm state

UP,

DOWN

NOR-

MAL

UP NORMAL No fault

nominal port states = actual port

states

All connected interfaces (Admin

state = up) are in operational state

“UP”, all unconnected interfaces

(Admin state = down) are in opera-

tional state “DOWN”

UP;

DOWN

NOR-

MAL;

CRITI-

CAL

RESTRICTED CRITICAL Nota ll connected interfaces (Admin

state = up) are in operational state

“UP”

UP;TEST-

ING

NOR-MAL,

MINOR

RESTRICTED MINOR At least one port is in operationalstate “TESTING”

UP,

TEST-

ING,

DOWN

NOR-

MAL,

MINOR,

CRITI-

CAL

RESTRICTED CRITICAL Some interfaces are in operational

state “TESTING” or in alarm state

“CRITICAL”

TEST-

ING,

DOWN

MINOR,

CRITI-

CAL

RESTRICTED CRITICAL Some interfaces are in operational

state “TESTING” and others are in

operational state ”DOWN”

DOWN CRITI-

CAL

DOWN CRITICAL Failure

Operational state of PS-E node

“DOWN” because all interfaces arein operational state “DOWN”

Tab. 4.7 Port and node state combinations for PS-E (examples)

Operationalstate

Alarm state Remark

UP NORMAL Admin state = upconnected interface in normal operation

TESTING MINOR intermediate condition during test sequence

DOWN CRITICAL Admin state = upfailure in connected interfaceRemote station is not accessibleCheck the remote interface or the link (cable,etc.)

DOWN NORMAL Admin state = downunconnected interface

Tab. 4.8 Operational states and alarm states of PS-E uplink/crosslink ports



A30828-X1187-U125-3-7619 129

OperationSURPASS


The following SLMI messages indicate a condition or a cleared alarm (no operator ac-

tion necessary).

slmiAlarmStateDetails Repair Action

External alarms

Alarm 1 ... Alarm 10 External alarmNo specific text assignedClear alarm according to site-specific docu-mentation

Cable to AD:RAL disconnected Check connection to AD:RAL

Power failure alarm Clear external alarm according to its “slmi-AlarmStateDetails”

Battery discharge alarm

Fuse/breaker alarm

Air condition alarm

Fire alarm

Fan/fan tray alarm

Temperature high alarm

Transmission alarm

Entry (door/window) alarm

Clock alarms

TDM clock unit entered mode “Fail-ure”

Check physical connection between referenceclock and PS-E (cable, etc.)Check reference clock unit

TDM reference clock input - signallost

Gateway alarms

Default gateway not reachable Check physical connection between PS-E andgateway/routerCheck gateway/router in question

Redundant gateway not reachable

Partner PS-E lost default gateway ac-cess

Startup alarm

User defined VLAN/port configurationis invalid

Unwanted fallback to default configuration be-cause of missing valid backup file.

Configure VLANs and ports via Workbenchand then start a board backup via SoftwareManagement (This will also clear the alarm inAMD and CV).

Tab. 4.9 PS-E SLMI alarms



A30828-X1187-U125-3-7619 131

OperationSURPASS


4.5 SW update

Besides the SW update you can incorporate patches for Voice Module of for Feature

Processors using the AutoPatch application (at least version V3.1.51). In contrast to a

SW update patches can be incorporated without interrupting the payload.

For further information on AutoPatch refer to the following documentation:

• SYD:AuP-Innovation

(AutoPatch functions and user interfaces)• IMN:AuP-Innovation

(installing AutoPatch)

• UMN:AuP-Innovation

(using AutoPatch)

General notes on SW update:

• The new SW must be available at NetManager before an update is started.

• A SW update requires a reboot, thus interrupting call processing. It is recommended

to update the SW during the night when the traffic is on a low level.

• There are individual and independent update sequences for hiG 1600 equipment

TDM clock unit in mode “Active inhold-over”

Lost lock with the own reference input

TDM clock unit in mode “Stand-bysynchronized”

Synchronized with the reference clock of thepartner PS-E

TDM clock unit failure Error, refer to Tab. 4.9 "PS-E SLMI alarms"

Normal

Redundant GW known

Redundant GW not provided

System includes PS-E redundancy

System without PS-E redundancy

PS-E uses user-defined configuration During reboot user-defined configuration datahave been read from backup file

PS-E uses default configuration No error:User-intended fallback to default configurationorError:Unwanted fallback to default configuration, re-fer to Tab. 4.9 "PS-E SLMI alarms"

slmiOpStateDetails Remark

Tab. 4.11 PS-E SLMI operational states

iThis manual does not treat HW update because the HW version of the hiG 1600 or of

individual modules is not updated/replaced by the operator but by the Service.



132 A30828-X1187-U125-3-7619


4.5.1 SW update on Voice Module

The Voice Module software can be updated independently from the Feature Processor

(FPP or LTGx) SW. In fact the VM’s firmware is updated.

You can check the current HW, SW or patch version for a specific Voice Module with

SW Management’s “Display Versions” function.

During a Voice Module’s reboot the connected Feature Processor(s) is(are) not avail-

able from the hiE 9200. It is recommended to block the corresponding Feature Proces-

sors (FPP/LTGx) for administration and patching activities before Voice Module SW is

updated. The update should take place when there is low payload traffic.

The SW update with the Software Management application is done in two steps:

• Import SW to NetM

This manual assumes that the SW is available at NetManager before the download

is started. Please refer to the NetManager Administration manual for further detailson importing SW.

• Download and activate SW for a set of Voice Module(s)

(repeat this action until all voice modules are working with the new SW)

Guideline for updating Voice Module SW with SW Management:

1. Configure Feature Processors or LTGs connected to the VMs to be updated to “CBL”

2. Wait about five minutes

(most connections via these Feature Processors or LTGs should be finished, now)

3. Configure Feature Processors or LTGs to “MBL”4. In the Software Management application select a hiG 1600 NE

5. In the right window pane select all VMs to be updated

6. In the “Tasks” menu choose “SW download”

(The SW download window opens)

7. In the SW download window

– Select a set of VMs to be updated

– Select the SW version to be loaded

– Check the “reboot immediately” option (this would activate their new SW)

8. Configure LTG(s) to “ACT

9. Done

Further details, see NetM administration documentation (SW Management)

SW update tasks

4.5.1 "SW update on Voice Module"

4.5.2 "SW update on PS-E" (not valid for DLU-IP)

!SW download does not have any service impacts. But SW update requires a reboot,

thus interrupting the Voice Module’s payload for about 30-60 seconds. Triggering the

activation of new software on all voice modules of a hiG 1600 unit would lead to an out-

age of the whole gateway.

iModules with the same HW type and HW version can be updated simultaneously.

!In the event that your SW Release Note contains update orders you have to execute the

SW update according to the orders in your Release Note.



A30828-X1187-U125-3-7619 133

OperationSURPASS


4.5.2 SW update on PS-E

The PS-E SW is updated using SW Management and loaded via TFTP.

You can update these parts of the PS-E software:

• Boot code image

• Runtime images (two different versions)

You can check the current boot code/runtime image version for a specific PS-E with SW

Management’s “Display Versions” function.

The SW download does not have any service impacts. However, the PS-E reboot to ac-

tivate the new SW takes about one minute.

Guideline for SW update (example):

Assumptions for the example below:

– Let PS-E0 in a selected gateway to be updated first, then let PS-E1 to be updated.

– PS-E0 is connected via Voice Modules’ interfaces ETH0 and ETH2. PS-E1 is con-

nected via Voice Modules’ interfaces ETH1 and ETH3 (see Tab. 3.7).

The update procedure depends on your network configuration. In principle there are two

variants:

a) You do not employ L2 switches

– Your PS-Es are connected to each other via cross link.

– The PS-Es’ uplinks are connected to edge routers for OAM/payload/control.

Fig. 4.4 PS-Es directly connected to edge routers

b) You do employ L2 switches

– Your L2 switches are connected to each other via cross link.

– The PS-Es’ uplinks are connected to L2 switches which are connected to edge

routers.

iIn redundant configurations the PS-E SW can be updated without interrupting the ser-

vice (payload, OAM and control traffic) of the corresponding hiG 1600 shelf (shelves).

!In the event that your SW Release Note contains update orders you have to execute the

SW update according to the orders in your Release Note.

PS-E0

Router

Router

Router

PS-E1

Router

Router

Router

Crosslink



134 A30828-X1187-U125-3-7619


Fig. 4.5 PS-Es connected to edge routers via L2 switches

According to the upper assumptions the SW update is done in these steps:

1. Trigger interface switchover for each Voice Module belonging to the selected hiG

1600 to interfaces leading to PS-E1.

(Each Ethernet interface is switched individually.)

Start task SET IFSWITCH once per Voice Module

– enter EQN of Voice Module

– select Interface = ETH1

Start task SET IFSWITCH once per Voice Module


– Select Interface = ETH3

2. What is your network configuration variant?

– PS-E connected to edge routers (see a))

continue with step 3.

– PS-E connected to edge router via L2 switch (see b))


3. Trigger router switchover for all Voice Modules.

(Each traffic type has to be switched individually.)

Start task SET RSWITCH once per Voice Module and traffic type (or router).


– Select Router type = OAM / RTP / SCTP

4. In the SW Management select a hiG 1600 NE

5. In the right window pane select the PS-E to be updated.

(In this example select PS-E0.)

6. In the “Tasks” menu choose “SW download”

(The SW download window opens.)


Router

Router

Router

L2 switch

Router

Router

Router

Crosslink

PS-E0

PS-E1

L2 switch

iYou can check your network variant in Containment View. For a PS-E connected toedge routers and with cross link to another PS-E (see Fig. 4.4 "PS-Es directly connect-ed to edge routers") the port “ap25” must be in operational state “up”.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 135

OperationSURPASS


– Update just one SW component (either boot code image or runtime image),


– Update both SW components (boot code and runtime image),



– Select the PS-E to be updated

– Select the “Device image type” (boot code image or runtime image)

– check the “reboot immediately” option

(This will activate the new SW.)

– Select the SW version of boot code image or runtime image to be loaded

– Confirm your entries with button “OK”

Fig. 4.6 SW download window for PS-E (reboot option selected)

The selected SW component is downloaded now.

Continue with step 11.


– Select the PS-E to be updated – Select the boot code image as “Device image type”

– Uncheck the “reboot immediately” option

(Reboot will be done after second SW component is downloaded)

– Select the SW version of boot code/image to be loaded




136 A30828-X1187-U125-3-7619


Fig. 4.7 SW download window for PS-E (reboot option not selected)

The boot code/image SW is downloaded to the PS-E now.


– Select the PS-E to be updated

– Select the runtime image as “Device image type”

– Check the “reboot immediately” option

(This will immediately activate all downloaded SW.)

– Select the SW version of runtime image to be loaded


The runtime image SW is downloaded to the PS-E now.

11. A “ESB Reboot” window opens.

Choose the reboot options:

– Select the number of the active runtime image after reboot

– Uncheck “Force default VLAN/Port” to keep any user-defined configuration

– Check or uncheck “Force DHCP request” checkbox depending on whether you

want to load new BCSS data or not

Confirm this window with button “OK”



A30828-X1187-U125-3-7619 137

OperationSURPASS


Fig. 4.8 “ESB Reboot” window for PS-E

12. After the reboot the new SW is active on PS-E0.

13. Execute the SW update (step 1. - step 12.) for PS-E1.

This requires interface switchover for all Voice Modules to ETH0 and ETH2.14. On completion of SW update:

For load sharing you should switch back one half of the Voice Modules within this

hiG 1600 NE to ETH1 and ETH3.

15. Done

4.6 Executing a brief function test

A brief function check of hiG 1600 can be made with the following steps:

• Check whether VM modules are working.

– Perform a "display version" with the Software Management for your VM(s). The

task should be completed successfully for each selected module. This indicatesthat the VM in question is up and running.

• Check whether the Feature Processors are active and whether the corresponding

MBD-E connections are active with command DISP MCHE

• Ensure that there are no alarms in CV, AMD, Topology Map Viewer, Alarm Console

• Start autodiscovery in BCSS for VMs and PS-Es

(The hiG 1600 nodes must be “active” after autodiscovery in BCSS)

• Use diagnosis functions

– 4.6.1 "HW diagnosis for Feature Processors"

– 4.6.2 "HW diagnosis for PS-Es or Voice Modules"

4.6.1 HW diagnosis for Feature Processors

Using task DIAG LTG you can perform a diagnosis of a Feature Processor.

The diagnosis can last up to 60 minutes!

For further details, refer to NM:FP.

4.6.2 HW diagnosis for PS-Es or Voice Modules

During module startup a HW selftest is executed automatically. The module will not be-

come active if an error is detected.

!Subscriber traffic via the Feature Processor in question is interrupted during the diag-

nosis.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://n222.pdf/

http://n222.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



138 A30828-X1187-U125-3-7619


A trap is sent to NetManager (if possible) in the event that there is an HW error during

operation. Other kinds of errors usually lead to reboot or total failure of the module.

For the Voice Module the diagnosis can be started manually with DIAG MODULE.How-

ever, this requires that the Voice Module is in state “MBL”.For the PS-E diagnosis cannot be started manually.

4.7 Replacing hiG 1600 modules

In the MMN:LTG you can find replacement procedures for equipment managed via

MML.

In the UMN:STMI you can find replacement procedures for STMI equipment.

4.7.1 Replacing VMC (MP480 module) or PSC-C (FPP module)

This sections applies for replacing or upgrading a VMC/PSC-C to a higher version.

It does not make any difference whether you plug in a new module or one that has al-

ready been used. A VMC/PSC-C that is reused in another slot (i.e. it is assigned a dif-

ferent EQN) automatically returns to factory defaults. Thus new and used modules are

treated in the same way.

Save configuration data for the Voice Module on the VMC/PSC-C to be replaced

This step applies if the corresponding Voice Module is accessible from NetManager.

However, this step can be left out if there is a valid backup for VM.

Using the SW Management, proceed as follows:

• Start a Board Backup for the Voice Module in question (if necessary).

• Start an External Backup for the Voice Module in question.

iPlease refer to the Construction manual for information on mounting locations, fans, fus-

es or power supply. The Construction manual also applies for evaluating any LED indi-

cators.

Contents

4.7.1 "Replacing VMC (MP480 module) or PSC-C (FPP module)"

4.7.2 "Replacing PS-E (ESB module)"

4.7.3 "Replacing PS-E’s interface module"

iYou can determine the module type (PSC-C or VMC) with the task DISP BCONF

iTo find the mounting location of a PSC-C/VMC, refer to Tab. 3.8 "Relation betweenMOLOC and module number in CV for PSC(D)". For a PSC-C in a DLU-IP the modulenumber is “12” and you have to retrieve the mounting location via the FPU-E number.

iYou have to delete any “old” backup files manually via SW Management if modules are

to be reused without changing their EQN.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 139

OperationSURPASS


Stop call processing at hiE 9200 for the VMC/PSC-C to be replaced

This prevents unwanted alarms at the hiE 9200 and prevents new calls being set up via

the Voice Module that would be interrupted by VMC/PSC-C replacement.

Proceed as follows:

1. Interrogate the operating state of Feature Processor(s) connected to this VMC/PSC-

C with STAT LTG: LTG = <ltgset-X>;

2. What is the status of the Feature Processor?

– The Feature Processor is in state “ACT” -> continue with step 3.

– The Feature Processor is in state “CBL” or “UNA” -> continue with step 4.

3. To configure a Feature Processor to “CBL” proceed as follows:

– Configure Feature Processor with CONF LTG to state CBL – Continue with next step after five minutes, or after the “CBL” acknowledgement if

this occurs within five minutes.

(No new calls can be set up via this VMC/PSC-C.)

4. Configure Feature Processor with CONF LTG to state MBL

(This will interrupt any active connections via this Feature Processor.)

5. Repeat steps 2. - 4. for each other Feature Processor connected to this VMC/PSC-

C.

Done

Take VMC’s/PSC-C’s Voice Module out of service

Start the task MOD MODSTATE on the Workbench and select administrative state mbl

for the Voice Module on the VMC/PSC-C to be replaced.

Pull out VMC/PSC-C

Switch off power supply on the module’s faceplate (push PWR switch to top position)

and then pull out the module.

Change MAC addresses of Voice Module in BCSS

Each Voice Module has four individual MAC addresses, thus the MAC addresses for the

new module must be entered using BCSS before a new module is plugged in.

Do the following:

1. Start BCSS (for example via context menu from Containment View)2. Edit the FPU-E node in question

3. Select the "LAN specific data" tab

4. Replace the MAC addresses of the Voice Module you pulled out with the MAC ad-

dresses of the Voice Module you want to plug in


For details refer to 3.4.2.4 "Creating/modifying/deleting FPU-E nodes with BCSS".

Plug in VMC/PSC-C and activate Voice Module

Plug in the new Voice Module.

Switch on power supply (push PWR switch on front plate in middle position).

iYou have to configure four Feature Processors (LTGs) for a PSC-C. For a VMC youhave to configure one or four Feature Processors, depending on the type of LTG con-

nected.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



140 A30828-X1187-U125-3-7619


The plugged-in module boots automatically with factory settings (defaults) and after

about 90 seconds all LEDs on the frontplate are green with red blips.

After successful autodiscovery (and consecutive refresh) the new module appears in the

Containment View. However, this may take several minutes.Due to missing configuration data the VM is in operational state “restricted” and does

not yet transfer any payload.

In the event that the VM does not reach the operational state “restricted” configure the

Voice Module with MOD MODSTATE to administrative state act.

Check/download SW/FW version of new Voice Module

Before entering your site-specific configuration, check the SW/FW versions of the new

module with the SW Management application.

– With the "Display Versions" function, read out the loaded SW/FW versions.

– With the "SW Download" function, load the appropriate SW/FW version, if neces-

sary.

Is there a valid backup file for the new Voice Module?

• Yes: Load backup file "Restore backed up configuration data for new Voice Module".

• No: Enter site-specific values "Enter site-specific values for new Voice Module"

Restore backed up configuration data for new Voice Module

Using SW Administration load the backup file for the new VM from the backup server.

The Voice Module is ready to transfer any payload now.

Continue with "Release blocked call processing resources at hiE 9200"

Enter site-specific values for new Voice Module

If there is no valid backup file this means you have to enter all site-specific values in the

Voice Module’s database.

For further information, refer to the relevant sections in 3 "Operation and administra-

tion".

Release blocked call processing resources at hiE 9200

Configure the corresponding Feature Processor(s) with CONF LTG to state ACT.

End of replacement procedure.

4.7.2 Replacing PS-E (ESB module)

This section describes how to replace a PS-E. This can be applied for replacing a de-

fective module or replacing an PS-E module with a newer version.

iAll unconnected ports at the Voice Module have to be configured to “down”.

iIn the event of PSC-C replacement:

Consider that the Feature Processor needs about 90 seconds after it has been plugged

before it can be configured to “ACT”.

iIn the event of PSC-C replacement:

It can take up to 30 minutes until the hiE 9200 recognizes a new Feature Processor.

Payload will be transferred via the PSC-C only after this recognition.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 141

OperationSURPASS


Required input values

– EQN of clock source

– PS-E MAC address

– PS-E’s network configuration parameters

– External alarm configuration parameters (if appropriate)

What is your configuration variant?

– PS-E in redundant configuration: Pull out PS-E

– PS-E in non-redundant configuration: Stop call processing at hiE 9200 for the hiG

1600 shelf/shelves

Stop call processing at hiE 9200 for the hiG 1600 shelf/shelves

At the hiE9200, stop call processing for the hiG 1600 shelf/shelves in question.

This prevents alarms at the hiE 9200 and prevents new calls being set up via this/these

hiG 1600 shelf/shelves that would be interrupted by PS-E replacement.

Proceed as follows:

1. Interrogate the operating state of Feature Processors connected to this PS-E

with STAT LTG: LTG = <ltgset-X>;




3. To configure each Feature Processor to “CBL” proceed as follows:

– Configure Feature Processor with CONF LTG to state CBL – Continue with next step after five minutes, or after the “CBL” acknowledgement if


(No new calls can be set up via this Feature Processor.)

4. Configure each Feature Processor with CONF LTG to state MBL


5. Repeat steps 2. - 4. for each other Feature Processor connected to this PS-E

Pull out PS-E

Unplug all uplinks at the PS-E with exception of the OAM uplink

Pull out the module.

Change MAC address in BCSS

Each PS-E module has its individual MAC address, thus the MAC address for the new

module must be entered using BCSS before a new module is plugged in.

Do the following:

1. Start BCSS (for example via context menu from Containment View)

2. Edit the PS-E node in question

3. Select the "LAN Specific Data" tab

!Without redundancy all subscriber traffic via the corresponding hiG 1600 shelf/shelves

will be interrupted as soon as an active PS-E is pulled out. Depending on your configu-

ration this might concern one basic shelf, or one basic and one extension shelf.

!If you plug in a PS-E with another configuration than the former one this might cause L2

loops disturbing the complete network and causing failures. Therefore all uplinks (ex-

cept OAM uplink) have to be unplugged first.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



142 A30828-X1187-U125-3-7619


4. Replace the MAC addresses of the PS-E module you pulled out with the MAC ad-

dresses of the PS-E module you want to plug in


For further details, refer to 3.3.2.4 "Creating/modifying/deleting PS-E nodes".

Plug in and activate PS-E module

Plug in the PS-E module

The plugged-in module boots automatically and becomes active. The autodiscovery

mechanism also sets the status in NetManager to active. This may take severalminutes.

After autodiscovery has finished, the new PS-E is displayed in Containment View after

(automatic) refresh with the state "active".

Check/download SW/FW version of new PS-E

Before entering your site-specific configuration, check/update the SW versions of the

new module with the SW Management application (see 4.5.2 "SW update on PS-E"). – With the "Display Versions" function, read out the loaded SW versions.

(boot code image version and runtime image version)

– With the "SW Download" function, load the appropriate SW version, if necessary.

Configure and then connect new PS-E module

A new or replaced PS-E needs further configuration data. These configuration data can-

not be loaded from an external backup file.

Refer to 3.3.4 "Configuration tasks via Workbench for PS-E"

Connect the uplinks for payload and control traffic at the PS-E

Do you have a redundant configuration? – yes: End of replacement procedure for PS-E

– no: Continue with Start call processing at hiE 9200 for hiG 1600 shelf

Start call processing at hiE 9200 for hiG 1600 shelf

At the hiE 9200, the call processing that was stopped for the hiG 1600 shelf/shelves in

question must be started again.

With CONF LTG configure all corresponding Feature Processors to state ACT

Afterwards new calls can be set up via this hiG 1600 shelf again.

End of replacement procedure for PS-E

4.7.3 Replacing PS-E’s interface module

Do you have a redundant configuration?

– yes:

Pull out the interface module and plug in the new module

End of replacement procedure

(A defective interface module can be replaced without any configuration task. The

redundant PS-E should have taken over already.)

– no: go to "Stop call processing for the hiG 1600 shelf/shelves"

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 143

OperationSURPASS


Stop call processing for the hiG 1600 shelf/shelves

At the hiE9200, stop call processing for the hiG 1600 shelf/shelves in question.

This prevents alarms at the hiE 9200 and prevents new calls being set up via this/these

hiG 1600 shelf/shelves that would be interrupted by interface mudule replacement.

Proceed as follows:

1. Interrogate the operating state of Feature Processors connected to this PS-E

with STAT LTG: LTG = <ltgset-X>;



– The Feature Processor is in state “CBL” or “UNA” -> continue with step 4.3. To configure each Feature Processor to “CBL” proceed as follows:

– Configure Feature Processor with CONF LTG to state CBL

– Continue with next step after five minutes, or after the “CBL” acknowledgement if



4. Configure each Feature Processor with CONF LTG to state MBL


5. Repeat steps 2. - 4. for each other Feature Processor connected to this PS-E

Done

Exchange interface module

Pull out the interface module to be replaced and plug in the new one.

Start call processing for the hiG 1600 shelf/shelves

At the hiE 9200, the call processing that was stopped for the hiG 1600 shelf/shelves in

question must be started again.

Configure the corresponding Feature Processors with CONF LTG to state ACT

Afterwards new calls can be set up via this hiG 1600 shelf/shelves.

End of replacement procedure for GE interface modules.

4.8 Backup/restore hiG 1600 databaseHandling NE data at NetManager

The backups of the NE data are stored on NetManager’s file server and will be backed

up within the NetM file system backup. The whole amount of backed up NE data stored

on NetM FS and the amount of backed up NE data per interval (e.g. per day) has to be

checked during the projecting of the NetM. It is recommended from NEs, to minimize the

amount of backed up data on NetM FS. The backup of the NE data on the NetM FS has

to be scheduled before the NetM file system backup is performed.

For the restore of the NE data from backup media, first the NE data have to be restored

to the FS file system and then from the FS file system to the NE.

!Without redundancy all subscriber traffic via the corresponding hiG 1600 shelf/shelves

will be interrupted as soon as the PS-E’s interface module is pulled out. Depending on

your configuration this might concern one basic shelf, or one basic and one extensionshelf.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



144 A30828-X1187-U125-3-7619


The NetManager Backup, Restore and Archiving Manual describes the corresponding

processes for the OS administrator.

Backup and restore for hiG 1600 data:

The functionality of the Backup function is to store the configuration data in the hiG 1600.

Analog to this, in case of replacing a module, the restore function is needed to get the

data back and not to create all new again. This action is performed by the operator.

The hiG 1600 configuration data is distributed as follows:

• Configuration data for Voice Modules and PS-Es is manually saved at the NetMan-

ager via NetManager’s Software Management application.

• The configuration data for Feature Processors and special equipment (LTU:S) is au-

tomatically saved in the hiE 9200 database.

• Theoptional STMI equipment possesses its specific database which is managedvia

TNMS-C (refer to STMI documentation).

Go to the appropriate section:*

* All the distinct databases have to be saved individually.

4.8.1 Backup and restore for the Voice Module

This has to be observed for the VM:1. The first time it is required to perform a backup on a VM is when the IP address (to-

gether with the Net Mask and Default Gateway) is assigned to the module. If the

module is reset the inputs are gone.

2. The IP configuration is lost in the event that

– a VM changes its position in the shelf

– a VM is replaced by another VM (in this case the backup file must be restored in

the replacing module)

3. Once the VM is in operation a backup is always required to save any modifications

entered using BOAM tasks.

4. There is no automatic backup for the database of Voice Modules.

There are two types of backup:• External backup

The external backup creates a backup file only on the file server of the NetM.

• Board backup

The board backup creates a backup file only inside the VM.

With the option ‚both' in the SW Management application it is possible to create board

and external backup in the same time.

Voice Module’s Golden Code:

i The hiG 1600 database and the hiE 9200 database have to be kept consistent.

4.8.1 "Backup and restore for the Voice Module"

4.8.2 "Backup for the PS-E" (not relevant for DLU-IP)

4.8.3 "Backup and restore for Feature Processors"

iIt is not possible to restore the backup file without affecting the call processing (the mod-

ule has to be rebooted in order that the restored backup becomes actual).



A30828-X1187-U125-3-7619 145

OperationSURPASS


In order to have a FW backup of the VM there is the “Replace golden Code” functionality.

With this you can set the actual FW version also to be a default one. The first default

version is set up in the factory.

Additionally there is basic configuration data which is sent from BCSS to the Voice Mod-ule and which is kept on NetManager. This also means that a new/replaced PS-E will

get data from BCSS automatically.

Brief guideline for saving the database of Voice Modules

You can save the Voice Modules’ database per NE. The following steps apply for board

and external backup for all Voice Modules in a selected hiG 1600 NE.

1. Start Software Management

2. Select the NE in question in the left window pane

3. Select all Voice Modules within the selected NE in the right window pane

Fig. 4.9 Voice Module backup - module selection

4. Call menu item “Tasks” -> “Backup” for the selected Voice Modules

Guidelines

"Brief guideline for saving the database of Voice Modules"

"Brief guideline for restoring the database of Voice Modules"

iThe Voice Module must be up to execute a backup, otherwise the backup fails with the

comment “operation unable to run on this device”.



146 A30828-X1187-U125-3-7619


Fig. 4.10 Voice Module backup - module selection

5. Select type of backup “Both”

6. Enter a name for the backup file

7. Start the backup with “OK”

8. First a board backup and then an external backup is executed.

9. You can check the result with Software Management’s “Display Versions” function.

10. Done

For further details, refer to the NetManager Administration manual.

Brief guideline for restoring the database of Voice Modules

First you have to stop call processing at hiE 9200 for the Voice Module(s) in question.

This prevents unwanted alarms at the hiE 9200 and prevents new calls being set up via

the Voice Module(s) that would be interrupted by reboot.

Proceed as follows to stop call processing at hiE 9200:

1. Interrogate the operating state of Feature Processor(s) connected to the selected

Voice Module(s) with STAT LTG: LTG = <ltgset-X>;




3. To configure a Feature Processor to “CBL” proceed as follows:

– Configure Feature Processor with CONF LTG to state CBL

– Continue with next step after five minutes, or after the “CBL” acknowledgement if



4. Configure Feature Processor with CONF LTG to state MBL


iYou have to configure four Feature Processors (LTGs) for a PSC-C. For a VMC you

have to configure one or four Feature Processors, depending on the type of LTG con-

nected.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 147

OperationSURPASS


5. Repeat steps 2. - 4. for each other connected Feature Processor connected to this

VMC/PSC-C.

Done

You can restore the Voice Modules’ database per NE. The following steps apply for one

or several Voice Modules in an NE.



3. Select Voice Module(s) within the selected NE in the right window pane

4. Call menu item “Tasks” -> “Restore” for the selected Voice Module(s)

The “Restore window” opens.

Fig. 4.11 Restoring a backup file for the Voice Module

5. In the “Restore window”

– Select the appropriate backup file to be restored

– If the backup shall be activated yet check the “Reboot immediately” option.(This manual assumes that call processing at corresponding Feature Processors

has been stopped already.)

6. Start the restore with “OK”

7. Start call processing at hiE 9200:

Configure the corresponding Feature Processors with CONF LTG to state ACT

8. Done


i The Voice Module must be up to restore its database, otherwise the restore fails withthe comment “operation unable to run on this device”.

http://cmlexch.pdf/

http://cmlexch.pdf/



148 A30828-X1187-U125-3-7619


4.8.2 Backup for the PS-E

There are two kinds of data for a PS-E

• Basic configuration data entered via BCSS

Changes done via BCSS are taken over and are saved on the board after forced PS-E reboot with the option “Force DHCP request” or after automatic reboot on “power

on reset”. This also means that a new/replaced PS-E will get data from BCSS auto-

matically.

• Configuration data entered via Workbench

Configuration data entered via Workbench can be stored locally on the board’s

FEPROM. After a board backup using Software Management the locally stored data

is “boot resistent” and is not lost if the PS-E is rebooted or pulled out, but you have

to enter all configuration data manually if you replace a PS-E module by another PS-

E module (see 3.3.4 "Configuration tasks via Workbench for PS-E").

Brief guideline for saving the database of PS-Es

You can save the PS-E database per NE. The following example applies for all PS-Es

in a selected hiG 1600 NE.



3. Select all PS-Es within the selected NE in the right window pane

Fig. 4.12 PS-E board backup - module selection

4. Call menu item “Tasks” -> “Backup” for the selected PS-Es

(There is board backup possible only)

i

Since configuration data is kept locally on the PS-E only, there is no “restore” function

in Software Management for the PS-E.

iThe PS-E must be up to execute a backup, otherwise the backup fails with the comment

“operation unable to run on this device”.



A30828-X1187-U125-3-7619 149

OperationSURPASS


Fig. 4.13 PS-E board backup - start backup

5. Start the backup with “OK”

6. Done


Additionally you can upload PS-E configuration data to a FTP server for analysis or

symptom saving, see 4.9.3 "Upload PS-E maintenance information to NetManager".

4.8.3 Backup and restore for Feature Processors

The database of the Feature Processors is kept at the hiE 9200. There are automatic

saving mechanisms.

For further details, refer to the SURPASS Backup and Restore manual.

4.9 Symptom saving

This section applies in the case of special fault clearance at the request of the Siemens

Technical Assistance Center (TAC).

If required, the TAC 3 provides additional support using the Remote Diagnostic Center

(RDC).

To save fault symptoms, you can do the following

• With NetM Information collect version information etc. concerning NetManager.

• With Software Management’s “Display Versions” function collect version informa-

tion etc. concerning PS-E or Voice Module.

iThere is no restore function in SW Management for the PS-E because there is no ex-ternal backup file. The board backup file is automatically read during PS-E reboot.



150 A30828-X1187-U125-3-7619


• Use the print function in the Log Viewer to print trap details and/or Log Viewer’s ex-

port function.

By default the Log Viewer displays only those traps that do not appear as alarms

in the Alarm Message Display, i.e. SLMI alarm traps are not included!

Refer to 4.9.1 "Traps recorded by the Log Viewer"

• Read/Save the alarm history in AMD

(because Log Viewer does not contain any SLMI alarm state traps)

For further details, refer to the NetManager documentation.

• Read/Save the contents of the Voice Module’s error or log files

4.9.2 "Read Voice Module’s error notebooks or event log book"

• Upload PS-E maintenance data to NetManager

4.9.3 "Upload PS-E maintenance information to NetManager"

• Read PS-E statistics and port mirroring data

4.9.4 "Port statistics and port mirroring data delivered by the PS-E"

Additionally tracers can apply for symptom saving. These tracers might be useful:

– Ethereal trace

– Sign trace

– Port trace

4.9.1 Traps recorded by the Log Viewer

This section treats the traps that are visible in Log Viewer only.

For symptom saving, trap details may be printed from the Log Viewer with "File -> Print",

and/or exported to Excel with “Edit -> Export to Excel” or “Edit -> Export Details”.

For further information on handling the Log Viewer, refer to the NetManager documen-

tation.

4.9.1.1 Traps from PS-E

The PS-E sends these kinds of traps

1. SLMIAdminState trap

Possible values:

– “4” = active

– “7” = not accessible

2. SLMIOpState trap

This kind of trap is sent from interfaces (ports) only.

Possible values indicating the SLMIOpState: – “1” = up

– “2” = down

– “5” = dormant

– “6” = restricted

– “7” = disabled

Possible values indicating the SLMIOpStateReason:

– “5” = configurationError

– “6” = hwError

– “7” = switchOver

– “13” = normal

– “14” = adminState – “7” = disabled



A30828-X1187-U125-3-7619 151

OperationSURPASS


4.9.1.2 Module startup traps from VM

Every change of one of the variables "state", "reason" or "details" generates a "slmiOp-

StateTrap".

After DHCP is executed an “entConfigChangeTrap” is sent. This trap triggers auto-dis-

covery.

4.9.1.3 Command execution traps from VM

The slmiCommandResultTrap can be evaluated with the Log Viewer.

State Reason Details Description Action

restricted missingCon-figurationData

noBackupData Set after finished startupwithout finding backupdata if EQN has notchanged.

Full config-urationmust bedone byNetM, orbackup filemust beloaded.


factDefErr Set after finished startup;loading of default datanot successful and there-fore backup data notloaded if EQN has notchanged.

Full config-urationmust be

done byNetM, orbackup filemust beloaded.


backupError Set after finished startup;error during backup dataloading.

Full config-urationmust bedone byNetM, orbackup filemust be

loaded.

Tab. 4.12 Module startup

Name Result Info Description Action

slmiComman-dResultTrap

none noError Default values; sentafter ’noCommand’ ifnothing to abort.

No action


notSup-ported

noError Sent if set command isnot supported.

No action


success noError Sent if set commandfinished successfully.

No action

Tab. 4.13 Command execution



152 A30828-X1187-U125-3-7619


4.9.2 Read Voice Module’s error notebooks or event log book

The Voice Module provides this kind of error or event information:

– SW Error Notebook

– HW Error Notebook

– Event Log Book

Proceed as follows to read Voice Module’s error or event log files:1. Start DISP NB

2. Enter parameters


– Select type of notebook or log book

3. If appropriate, save output to file and send to TAC for evaluation

4. Done

4.9.3 Upload PS-E maintenance information to NetManager

For the the PS-E you can upload maintenance information like

– Error note book “errorNoteBook” – DHCP data files “flash:/dhcp.dat”


failed error Sent if set commandfailed: general error.

Depends oncommand


failed fileForma-tError

Sent if data transfer(down) failed: wrongheader format.

File damaged,replace file


failed checksum-Error

Sent if data transfer(down) failed: wrongchecksum.

File damaged,replace file


failed timeout Sent if data transfer(down) failed: TFTPerror.

Check TFTPconfiguration

slmiComman-

dResultTrap

in-

Progress

PendingFi-

leTransfer

Sent at start of TFTP

transfer (up anddown).

No action


in-Progress

Pending-FlashPro-gramming

Sentatstartof copyingdownloaded file toFFS.

No action


unable-ToStop

noError Sent if command can-not be aborted with’noCommand’ or’forceAbort’.

No action


aborted noError Sent if command isaborted successfully

with ’noCommand’ or’forceAbort’.

No action

Name Result Info Description Action

Tab. 4.13 Command execution

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 153

OperationSURPASS


– Configuration data file: “flash:/backup.dat”

After uploading the above files to NetManager you can send them to TAC for evaluation

Proceed as follows to upload data to NetManager:

1. Start ULOAD FILETFTPS

2. Enter parameters

– EQN of PS-E

– Local path of file to be uploaded (e.g. flash:/dhcp.dat)

– Destination path

3. The uploaded data can be sent to the Siemens service or TAC now.

4. Done

4.9.4 Port statistics and port mirroring data delivered by the PS-E

The PS-E provides these functions

• You can read PS-E port statistics

(for example for debugging purposes)

• You can monitor the traffic inside the PS-E

(a test port monitors the traffic at another port)

Read PS-E port statistics

To read port statistics proceed as follows:

1. Start DISP PORTSTAT

2. Enter EQN of PS-E

3. Select port: Port number = <number of port>

4. For the selected port operational state, speed and several port-specific statistics

data are displayed

5. Done

Mirror PS-E ports

Mirrored packets are displayed with a VLAN tag at the mirror port (= test port) even if the

packet is received without tag at the mirrored port.

Since the port “ap23” (FE.Up.Payl) is usually not occupied you should use this port as

test port.

Possible traffic types to be mirrored for ports “00” to “25”:

– Ingress traffic

– Egress traffic

– Both traffic types

– None (means “this port is not mirrored”)

i

Alternatively the PS-E error notebook can be read by the Siemens TAC at the device

itself. However, this needs a direct connection to the PS-E via V.24 interface.

Guidelines

"Read PS-E port statistics"

"Mirror PS-E ports"

iYour mirror port entries are not saved in a board backup and thus they are not boot-

resistant.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



154 A30828-X1187-U125-3-7619


Possible test ports:

– ap19

– ap21-ap25

Use the mirror function as follows:1. Start MOD MIRRPORT

2. Enter parameters:

– EQN of PS-E

– Select Test port = <apxx>

– For each port to be monitored select Mirrored traff. type

3. Evaluate mirrored data

4. You can stop mirroring function for a specific port by selecting Mirrored traff. type =

None for this specific port

5. To stop the mirroring function select Test port = None

6. Done

With DISP MIRRPORT you can look up whether the mirror port function is switchedon/off.

– Mirror port function switched on: “OUTPUT VALUES: Test port = None”

– Mirror port function switched off: “OUTPUT VALUES: Test port = apxx”

4.10 Troubleshooting hints

This section treats mistakes that might occur without individual alarms at the NetMan-

ager.

New Voice Module does not become active in BCSS

Possible reason:

MAC address wrong or interface assignment wrong

Remedy:

Compare the module’s MAC address (see label on module) and correct entry in BCSS

and/or check assignment of uplink interfaces

In the event that the error cannot be corrected that way (requires tracer, like Ethereal):

Check MAC address that is used in DHCP discovery (for example with Ethereal at PS-

E mirror port)

If MAC address is not identical with MAC address on Label (MAC1) send module back

to factory

Insufficient speech quality

Possible reason:

VLAN configuration on VM, PS-E and L3 equipment not matching

Example:

Let PS-E send tagged payload but let Voice Module expect untagged payload traffic.

This results in no speech connection or in a speech connection that is just one-way even

if all VoIP packets reach their destination.

iAfter failures of network components non-matching ARP tables may cause interface

problems and disturbed speech transmission. In these cases you should check whether

the ARP tables are up to date.

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/

http://cmlexch.pdf/



A30828-X1187-U125-3-7619 155

OperationSURPASS


Remedy:

Check Port and VLAN configuration at PS-E, see 3.3.4.1 "Manage PS-E’s VLANs", and

3.3.4.2 "Manage PS-E’s ports"

Certain traffic types do not work

You can use the PS-E statistics and/or mirror port functions to analyze the problem, see

4.9.4 "Port statistics and port mirroring data delivered by the PS-E"

Only OAM traffic is transferred

Possible reason:

PS-E configuration is not matching

(Maybe a PS-E has been replaced and the “new” module runs with non-matching con-

figuration)

Remedy:

Check PS-E configuration, see 3.3.4 "Configuration tasks via Workbench for PS-E"



156 A30828-X1187-U125-3-7619




A30828-X1187-U125-3-7619 157

OperationSURPASS


5 DLU-IPThis chapter collects information relevant for DLU-IP.

5.1 Introduction

These sections are relevant for hiG 1600 as well as for DLU-IP (with restrictions):

These are DLU-IP-specific sections:

5.1.1 DLU-IP abstract

For small gateway applications a maximum of two PSC-Cs (instead of two line cards)

can be plugged in frame F:DLUG(A) which itself is plugged in a DLU rack (R:DLUG).

This configuration of a Digital Line Unit (DLU) with IP interface is called DLU-IP.

The PSC-C is the hardware of the functional unit FPU-E which is a logical multi-module

compound. From the functionality point of view it provides

– Feature Processor (FP) / Line Trunk Group (LTG) functions

(TDM connectivity, call processing)

– Voice Module (VM) functions

(voice processing, Codecs, IP connectivity)

For further details on the PSC-C, refer to 2.6.2.2 "Packet Service Controller Card TypeC".

Each PSC-C provides two IP uplinks for the DLU-IP (the other two uplinks per PSC-C

are not connected in a DLU-IP). Redundancy is provided by installing two PSC-C mod-

ules which have independent network connections.

The DLU-IP supports the standard DLUG line interfaces (POTS, ISDN-BRI, V5.1) but

also provides additional interfaces via unoccupied PSC-C interfaces.

Contents

5.1 "Introduction"

5.2 "Operation and administration"

5.3 "Maintenance"

Section

2.3 "Processing of payload, OAM and control traffic in hiG 1600"

2.5 "Configuration guidelines for hiG 1600 and environment"

Modules: 2.6.2.2 "Packet Service Controller Card Type C"

Section

5.1.1 "DLU-IP abstract"

5.1.2 "Clock synchronization in DLU-IP"

5.1.3 "Uplink interface configurations for DLU-IP"

5.1.4 "Summary of IP addresses and subnets for DLU-IP"

!Only certain mounting locations are allowed for the PSC-C in the DLU shelf and one

PSC-C occupies two Line Card slots. For further details on hardware configuration vari-

ants, refer to the Construction Manual.



158 A30828-X1187-U125-3-7619


Each PSC-C is connected to one DLU controller via eight E1 interfaces. The remaining

eight E1 interfaces of the PSC-C are available to connect PRI, V5.2 (without packet da-

ta) or trunk interfaces and to connect a second DLUG shelf.

The DLUC and the PSC-C communicate via V93, only and the DLU controller is un-aware of the PSC-C physical location.

Main characteristics:

– External reference clock is provided by DLU controller (via V93 interface)

– Two 100BaseT uplinks per PSC-C are available for payload (and embedded OAM

and control, if appropriate)

– Two 100BaseT interfaces per PSC-C can be used as dedicated OAM/control inter-

face

– The PSC-C uplinks may be connected to a router directly, or via intermediate L2

switch or network. In case of direct connection to a router one Ethernet interface

connects the primary gateway, while the other connects the secondary gateway.

5.1.2 Clock synchronization in DLU-IP

Depending on the DLU configuration several clock synchronization scenarios are pos-

sible within a DLU-IP.

• "Clock synchronization variant 1"

• "Clock synchronization variant 2"

Clock synchronization variant 1

An external synchronization reference clock (2048 kHz) is connected to each of both

DLU controllers and the clock funtionality of the DLU controller is used.

All PCM interfaces of the DLU-IP are synchronized with the clock signal delivered from

the DLU controller via V93.

The recovered line clock (RCLK) of a PCM link is used as clock source for the Voice

Module. As default the link PCM0 is selected as clock source.

Fig. 5.1 DLU-IP with external reference clock



A30828-X1187-U125-3-7619 159

OperationSURPASS


The DLU controllers are directly assigned to the corresponding PSC-Cs.

– PSC-C#1 is assigned to DLU controller 0

– PSC-C#2 is assigned to DLU controller 1

There is no cross connection via V93 but there is clock crossover between both DLUcontrollers for clock synchronization.

One DLU controller acts as clock master and the other one as clock slave. If the clock

master fails the clock slave takes over and becomes clock master.

If the external clock fails the DLU controller (and thus the DLU-IP) operates in a “clock

free” running mode with a accuracy of 4,6 ppm. In this case the DLU-IP behaves like a

not synchronized gateway on the remote side.

Clock synchronization variant 2

In this configuration variant two DLU controllers from independent DLUGs are connect-

ed to one PSC-C pair and both DLUGs are not synchronized individually by one central

clock source.

This configuration variant needs backplane modules called M:NC2 together with special

cabling. For further details on M:NC2, refer to the Construction Manual.

Fig. 5.2 DLU-IP without external reference clock

In DLU-IP configurations where besides V93 connections additional trunk lines are con-

nected to the PSC-C the free running mode is not sufficient and it is mandatory to syn-

chronize the PSC-C to a reference clock.

This can be done with an external reference clock as described in Fig. 5.2 "DLU-IP with-

out external reference clock".

Alternatively you can use a recovered line clock from the connected trunks. In thiscase the clock configuration of the DLUC has to be set to internal ("INT") . Within the



160 A30828-X1187-U125-3-7619


PSC-C the synchronization clock has to be taken from the first ( trunk ) E1 line of any of

the four Feature Processor functions ( LTG functions ), i.e. you can select PCM interface

0, 4, 8 or 12 as synchronization source.

5.1.3 Uplink interface configurations for DLU-IP

In contrast to PSC(D) shelves DLU-IP configurations have a different redundancy struc-

ture resulting from load sharing of traffic to both PSC-C boards. Therefore, it is sufficient

to connect each PSC-C to a single router.

The IP subnet configuration depends on the layer 2 topology, specifically on the pres-

ence of a L2 crosslink between the router ports. In case of a strict separation of the rout-

ers (no crosslink present), different IP subnets must be configured for each PSC-C.When a crosslink is present, both router ports and the PSC-C must be in a common IP

subnet.

All network configurations show L2 switches for traffic aggregation between DLU-IP and

IP router. Of course, direct connection of DLU-IP to routers is always possible as well.

This manual assumes that each PSC-C board is connected to a single switch or

router plane, using the uplinks FE1 and FE2, respectively. Thus the DLU-IP pro-

vides a maximum of four uplink ports (two ports per PSC-C board).

Which uplinks are actually in use depends on the mapping of the different traffic types.

All configuration variants (see Tab. 5.1 "Uplink interface configurations for DLU-IP") are

based on redundant configurations. A single (non-redundant) PSC-C module per DLU-IP may be used for very small applications. In this case the DLU-C module must be also

non-redundant.

Summary of configuration variants:

5.1.3.1 Dedicated OAM traffic interface (FE0)

Characteristics:

1. 2x FE0 (one per PSC-C) as dedicated OAM traffic uplink interfaces

2. 2x FE2 (one per PSC-C) as common uplink interface for payload and control traffic

Use this configuration when a separate OAM network must be supported, with a direct

local connection of the network element to the OAM network.

i You have to take precautions for possible clock failures (caused by outage of the select-ed trunk) by appropriate trunk assignment and by appropriate priority selection for clock

sources.

OAM Traffic Control Traffic Section

via OAM interface(FE1)

via payload interface(FE2)

5.1.3.1 "Dedicated OAM traffic inter-face (FE0)"

viapayload interface(FE2)

via payload interface(FE2)

5.1.3.2 "Common OAM, control andpayload interface (FE2)"

Tab. 5.1 Uplink interface configurations for DLU-IP

iFE0 is the default OAM traffic interface.



A30828-X1187-U125-3-7619 161

OperationSURPASS


Since payload and control share the same Fast Ethernet uplink, tagging of control traffic

is recommended, while payload traffic should be untagged to minimize bandwidth con-

sumption.

Deployment with 5ms packet size is not allowed in this configuration because this doesnot leave sufficient bandwidth for control traffic in a fully equipped system with all PSC-

C ports used.

There are two alternatives for this uplink configuration variant

• "Dedicated OAM traffic interface without crosslink"

• "Dedicated OAM traffic interface with crosslink"

Dedicated OAM traffic interface without crosslink

Without crosslink between the switch planes the payload and control traffic must use the

same links between DLU-IP and edge router. This means a common router for payload

traffic and for control traffic is mandatory.

A common path for payload/control traffic ensures that a payload path failure cannot oc-cur without a control path failure.

Fig. 5.3 DLU-IP with dedicated OAM interface (without crosslink)

Dedicated OAM traffic interface with crosslink

Due to the crosslink between switches payload traffic and control traffic can be separat-

ed onto different router interfaces.



162 A30828-X1187-U125-3-7619


Fig. 5.4 DLU-IP with dedicated OAM interface (with crosslink)

5.1.3.2 Common OAM, control and payload interface (FE2)

Characteristics:

2x FE2 are employed as common uplink interfaces for OAM, control and payload traffic

(a single FE2 interface per PSC-C).

Use this configuration for remote DLU applications, where the number of uplinks must

be kept to a minimum.

Deployment with 5ms packet size is not allowed in this configuration because this doesnot leave sufficient bandwidth for control and OAM traffic in a fully equipped system with

all PSC-C ports used.

Since OAM, control and payload share the same external interface (FE2), tagging of

control and payload traffic is mandatory to allow further separation. However, OAM traf-

fic cannot be tagged.

There are two alternatives for this uplink configuration variant

• "Common OAM/control/payload interface without crosslink between L2 switches"

• "Common OAM/control/payload interface with crosslink between L2 switches"

Common OAM/control/payload interface without crosslink between L2 switches

Without crosslink between the switch planes the payload and control traffic must use the

same links between DLU-IP and edge router. This means a common router for payload

traffic and for control traffic is mandatory.

A common path for payload/control traffic ensures that a payload path failure cannot oc-

cur without a control path failure.



A30828-X1187-U125-3-7619 163

OperationSURPASS


Fig. 5.5 DLU-IP with common OAM/control/payload interface but without crosslink

Common OAM/control/payload interface with crosslink between L2 switches

Due to the crosslink between switches payload traffic and control traffic can be separat-

ed onto different router interfaces.

Fig. 5.6 DLU-IP with common OAM/control/payload interface (with crosslink)

5.1.4 Summary of IP addresses and subnets for DLU-IP

IP address plans assume dedicated IP addresses for OAM, control and payload.

Sharing of IP addresses is not considered and not recommended. Thus, the number of

IP addresses required is identical in all configurations.

Different IP subnets must be configured for the PSC-C in different switch planes when

there is no crosslink between the switches. A common IP subnet is only possible for

PSC-C modules that are in the same broadcast domain (i.e. VLAN).



164 A30828-X1187-U125-3-7619


* One IP address per feature processor function (LTG function), i.e. a maximum or four

IP addresses is required.

5.2 Operation and administration



Subnet 2(control)

Subnet 3(OAM)

PSC-C 1 1 4 * 1

PSC-C 2 1 4 * 1

L2 switch 1 1

L2 switch 2 1

Edge router 1 1 1 1

Edge router 2 1 1 1

Sum 4 10 6

Tab. 5.2 Externally visible IP addresses for DLU-IP

Unit Subnet 4(payload test)

Subnet 5(control test)

Subnet 6(OAM test)

PSC-C/VMC 1 2 2 2

PSC-C/VMC 2 2 2 2

L2 switch 1

L2 switch 2

Edge router 1 1 1 1

Edge router 2 1 1 1

Sum 6 6 6

Tab. 5.3 Local test IP addresses for DLU-IP

Section

3.1 "Managing hiG 1600"

3.2 "NE group and NE administration for hiG 1600"

3.4 "FPU-E management"

3.5 "Security management"

3.6 "Subscriber and trunk management"

Performance, QoS: 3.7.2 "Measurement of QoS statistics data at the Voice Module"

3.8 "Accounting management"



A30828-X1187-U125-3-7619 165

OperationSURPASS


These are DLU-IP-specific sections:

5.2.1 DLU-IP in hiE 9200 database

There is no active control net (CN) interface between DLUC and PSC-C (FPP+VM).

Thus the DLUC has no knowledge about routing of V93 to the PSC-C or the type of mod-

ules that are plugged at the depicted positions.

You have to block the positions where PSC-Cs are plugged for DLU-specific operations

at hiE 9200.

5.2.2 FPU-E nodes in a DLU-IP

In principle the FPU-E nodes in the DLU-IP are handled in the same way as FPU-E

nodes in a PSC(D) shelf with the following exceptions:

– Because there is no uplink aggregation via PS-E in a DLU-IP the dependencies on

PS-E can be ignored

– Because there is no VMC in a DLU-IP the hints on VMC can be ignored

– There is a fixed slot number (“12”) for the PSC-C in the Containment View. You have

to identify a specific module via the FPU-E number.

For node management, refer to 3.4 "FPU-E management" (DLU-IP specifics are also

mentioned in that section)

5.2.3 DLU-IP in Containment View

The DLU-IP network element contains these types of nodes:

• FPU-E nodes

(Voice Modules and LTG associations)

• One logical MML node

(is automatically created and represents MML alarms for this specific DLU-IP NE)

Figure Fig. 5.7 shows an DLU-IP NE without error in the Containment View.

3.9 "Conference Server management"

3.11 "“Time of day” management"

3.12 "Trap destination management"

Section

5.2.1 "DLU-IP in hiE 9200 database"

5.2.2 "FPU-E nodes in a DLU-IP"

5.2.3 "DLU-IP in Containment View"

Section

iThe PSC-C in the DLU-IP is represented by the same management type (FPU-E V1.0)

as the PSC-C in a PSC(D) frame.

iThe assignment of PSC-C to its physical location has to be made via FPU-E numberand shelf number in BCSS, see 3.1.3 "General configuration rules".



166 A30828-X1187-U125-3-7619


In the example the PSC-C port “23” is employed as uplink port for all kinds of traffic.

Fig. 5.7 DLU-IP node in Containment View

You can request details (properties of DLU-IP node) or start corresponding applications

via context menu.

In contrast to a PSC(D) shelf the DLU-IP’s uplink ports are connected to an external L2

switch or to L3 equipment instead to a PS-E.

The module number (slot) for the PSC-C is always “12” in a DLU-IP.For further details, please refer to Tab. 3.7 "FPU-E modules/ports in Containment

View".

The below figure shows a DLU-IP node with a port error. This port error is propagated

from the port level towards the higher levels in the Containment View.

Fig. 5.8 DLU-IP node with link error in Containment View

iTested and released configurations are described in 5.1.3 "Uplink interface configura-tions for DLU-IP".



A30828-X1187-U125-3-7619 167

OperationSURPASS


5.3 Maintenance


Section4.1 "General"

4.2 "Starting the fault clearance"

4.3 "SNMP messages from FPU-E (VM part)."

4.5 "SW update"

4.6 "Executing a brief function test"

Replacing modules:4.7.1 "Replacing VMC (MP480 module) or PSC-C (FPP module)"

4.8 "Backup/restore hiG 1600 database"

4.9 "Symptom saving"

4.10 "Troubleshooting hints"



168 A30828-X1187-U125-3-7619




A30828-X1187-U125-3-7619 169

OperationSURPASS


6 AppendixThis chapter provides technical background information and generic descriptions.

Go to the appropriate section:

6.1 hiE 9200 database

The Feature Processors of hiG 1600 are connected via an IP interface (MBDE) to hiE

9200’s message buffer type D.

Each MBDE provides two Fast Ethernet interfaces for the connection to the IP back-

bone. Up to seven MBDE pairs can be deployed in the MBDE to connect Feature Pro-

cessors.

Prerequisites on hiE 9200 side to control hiG 1600

• MBIE must be active and stable

• Corresponding LTGs with mode “FP” must be active and stable

If DLUs are connected to hiG 1600, all LTGs to which a DLU is connected must have

the same mode. Thus DLUs are exclusively connected to LTGs working as Feature Pro-

cessors.

Administrative tasks to connect a hiG 1600 to hiQ 9200

• The MBIE application is set to “COPL” by default and must be manually changed.

• Administration of MBIE application and administration of two MBIE links (per MB

side)

MOD MBIE (two links per MBIE )

– APPLIC=LTG

– IP address of Ethernet link

– Gateway IP address (gateway router for Ethernet link)

– Subnet mask for Ethernet link

• Administration of LTG as Feature Processors

CR LTG

– MODE=FP

– IP address of VM that is connected to this LTG

– LOCATION parameter (not mandatory, but recommended)

IP addresses used at hiE 9200 for hiG 1600

Each MBDE knows these IP addresses:

– two public IP addresses for the two links to hiG 1600 (control traffic)

– one public IP address of the gateway that is assigned to control traffic

– one IP address per Feature Processor (FPP/LTGx)

Section Contents

6.1 "hiE 9200 database" Database entries for hiG 1600 in hiE 9200

6.2 "Interworking scenarios" Interworking across domain borders and/or with oth-er gateway types

6.3 "SNMP background" Background information concerning SNMP



170 A30828-X1187-U125-3-7619


Fig. 6.1 hiG 1600-specific database entries at hiE 9200

Creating LTG, MBIE and MBIE links with the example values in figure Fig. 6.1:

• Create LTG

CR LTG: LTG=21-17, TYPE=LTGC, LDPARP=65, MODE=FP, IPAD-

DR=192.20.59.4, LOCATION=”Munich”;

• Create MBIE and corresponding links at MBIE

– MOD MBIE: MBIE=3, APPLIC=LTG;

– MOD MBIE: MB=0, MBIE=3, MBIELINK=0, IPADDR=192.20.59.11, GWIPAD-

DR=192.20.59.1, SUBNETMASK=255.255.255.0;

– MOD MBIE: MB=0, MBIE=3, MBIELINK=2, IPADDR=192.20.59.12, GWIPAD-

DR=192.20.59.1, SUBNETMASK=255.255.255.0;

For further details, refer to hiE 9200 documentation.

6.2 Interworking scenarios

These are the network scenarios for interworking of hiG 1600 with other media gate-

ways:

– 6.2.1 "Interworking between hiG 1600 units within the same domain"

– 6.2.2 "Interworking between hiG 1600 units within different domains"

– 6.2.3 "Interworking between hiG 1600 and hiG 1x00 trunking gateways"

6.2.1 Interworking between hiG 1600 units within the same domain

The figure below shows a network scenario with two hiG 1600 units within the same hiE

9200 domain.

All hiG 1600 units in one hiE 9200 domain are controled by one hiE 9200, i.e. all control

flows run via the controling hiE 9200 (including ACP messages between the hiG 1600

units).

MBIELINK 0

192.20.59.11

MBIELINK 2

192.20.59.12

Gateway,

Router

192.20.59.1 PS-EFP-P

21-17

FPU-E

VM480

192.20.59.4

MBIE 3

IP network



A30828-X1187-U125-3-7619 171

OperationSURPASS


Fig. 6.2 Interworking between hiG 1600 units within the same hiE 9200 domain

6.2.2 Interworking between hiG 1600 units within different domains

The figure below shows a network scenario with two hiG 1600 units in separate hiE 9200

domains.

The corresponding hiE 9200 units are interworking, i.e. the ACP control messages be-

tween A side and B side media gateway are exchanged via the two hiE 9200 units. The

hiE 9200 units exchange these control messages via ISUP+ or SIP-T protocol.

Fig. 6.3 Interworking between hiG 1600 units within different hiE 9200 domains



172 A30828-X1187-U125-3-7619


6.2.3 Interworking between hiG 1600 and hiG 1x00 trunking gateways

The hiG 1600 can work in parallel in one network with the trunk media gateways hiG

1000 V2.2T, hiG 1000 V3 and hiG 1100/1200. In case of interworking between different

gateway types only features supported by both gateways involved in a call are support-ed.

The figure below shows a network scenario with hiG 1600 and a trunk media gateway

within the same hiE 9200 domain.

All hiG 1x00 units in one hiE 9200 domain are controled by one hiE 9200, i.e. all control

flows run via the controling hiE 9200

All control flows run via the controling hiE 9200. The hiE 9200 performs an ACP/MGCP

protocol interworking between the hiG 1600 and the trunk media gateway.

Fig. 6.4 Interworking between hiG 1600 and hiG 1x00 trunking gateways

6.3 SNMP background

The SNMP (Simple Network Management Protocol) is an application layer protocol de-

signed to facilitate management information between network devices.

The SNMP is an Internet protocol and part of the Internet Management Model. The

SNMP uses the UDP/IP protocol for management communication between the network

devices.

The following list provides some main definitions and interprets them within the context

of SURPASS.

According to the Internet Management Model, the network management system com-

prises:

• Network elements (NE)

In the normal SNMP terminology network elements are the hardware devices (e.g.

computers, routers) connected to a network that is to be managed. Each network

element is assigned an individual IP address.

The SURPASS network is not only IP based. There are also network elements with

X.25 or Q3 protocols. Therefore, in the SURPASS context, a distinction is made be-

tween network elements and network nodes. Network nodes are SNMP-managed



A30828-X1187-U125-3-7619 173

OperationSURPASS


devices and are created with the BCSS. Network elements are created with the Net-

work Administration. A network element in the Containment View can just be a

container for a logical group of nodes.

So a network element can combine multiple nodes with identical Task Database

Packages. This is useful for updating theTP and ensures a clear numbering scheme

for the HW (modules, ports).

In the Containment View there are different structure levels for network elements

and network nodes. A network element is located at a higher level.

• Agents

These are SW modules residing in network elements that run the management SW.

They collect and store management information (e.g. number of received error pack-

ets) and inform the Network Management Station about certain events.

• Managed objects

Everything that can be managed on a network node (e.g. a list of currently active

TCP circuits in a host). Managed objects differ from variables (object instances);

managed objects can be scalar (defining a single object instance) or tabular (defin-ing multiple, related instances)

• Managed information database (MIB)

The MIB is a collection of managed objects. The MIB defines the variables main-

tained by the agent, i.e. everything that can be set is defined in the MIB. Collections

of related managed objects are defined in specific MIB modules. Each MIB variable

is identified by the corresponding object identification in a hierarchical naming

scheme.

• Network management stations (NMS)

These are the devices that execute management applications. The NetM is the NMS

for the hiG 1600.

Interaction between the NMS and the managed devices: – Read: For monitoring devices, the NMS reads variables maintained by the devices

using the "get request" or "get next request" operation.

– Write: For controlling devices, the NMS writes variables stored within these devices

using the "set request" operation. The "Write" interaction is also used for creating

new instances.

– Traversal operation

The NMS uses this action for gathering information from variable tables in the devic-

es using the "get next request" with the "get response" operation.

– Trap

The managed devices use traps to asynchronously report certain events to the

NMS.

In addition to the interactions listed above, the agent sends an error status to the NMS

to indicate an error.

hi g maintenance

Documents