Litespan-1540

FR3.2
SYSTEM DESCRIPTION

TECHNICAL MANUAL
EDITION 01

3EC 41919 0001 TQZZA Edition 01

SYSTEM DESCRIPTION

Status Released
Change Note

Short Title SAD–SYSTEM.DESC.R3.2

All rights reserved. Passing on and copying of this
document, use and communication of its contents
not permitted without written authorization from Alcatel.

2 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Contents

About this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 OVERVIEW OF PRODUCT CONFIGURATIONS AND APPLICATIONS . . . . . 15
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Definition of Network Elements and Applications . . . . . . . . . . . . . . . . . . . 16
1.2.1 EU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.2 RU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.3 GE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.4 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Network Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1 Naming of Network Elements in Litespan–1540 . . . . . . . . . . 17
1.3.2 Reference Network without GE configurations . . . . . . . . . . . . 18
1.3.3 Reference Network for GE configurations . . . . . . . . . . . . . . . . 20
1.3.4 SDH Access Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.5 Star Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.6 Network Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4.1 Transport of the Management Information (DCN) . . . . . . . . . 23
1.5 Overview of Product Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5.1 General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5.2 Litespan–1540 Node Architecture . . . . . . . . . . . . . . . . . . . . . . 34
1.5.3 Internal Architecture of each Configuration . . . . . . . . . . . . . . . 36
1.5.4 Litespan–1540 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.6 Product Configurations and Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.6.1 MLS Subrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.6.2 MLS Subrack Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.6.3 Outdoor Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.6.4 Indoor Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.6.5 Board Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2 SYSTEM ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.1 Transport Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.1.1 1.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2 Control Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.2.1 Control Communication Links inside the MLS . . . . . . . . . . . . . 59
2.2.2 Control Communication Links inside the Litespan–1540 . . . 62
2.2.3 Communication between GEB3 and LIM cards in GE . . . . . . 63
2.2.4 Communication between DLC and CPNT . . . . . . . . . . . . . . . . 64
2.3 CPNT Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.3.1 POTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.3.2 ISDN NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3EC 41919 0001 TQZZA Edition 01 3 / 185

SYSTEM DESCRIPTION

2.3.3 SHDSL CPNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.3.4 ADSL NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.4 Access Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.4.1 Narrowband with V5 Signalling on the V Interface . . . . . . . . 68
2.4.2 V5 Hubbing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.4.3 VoIP Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.4.4 IP Hubbing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.4.5 Gigabit Ethernet Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.4.6 GEB3 and EFL3 Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.4.7 GE interworking function to ATM network with ANIT–A . . . . 76
2.4.8 Litespan SIP Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.4.9 SOS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.4.10 Dual Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.5 Communication with the Management Entities (OS, CRAFT Terminal) . . 84
2.5.1 OS/CT OSI Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.5.2 OS/CT IP Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.5.3 IP networking at EU / RU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.5.4 IP networking Installation Data . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.5.5 IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.5.6 VoIP server Hot Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
2.5.7 Echo Cancellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.5.8 Fax over IP (T.38) Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.5.9 GE OS Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.5.10 VoIP Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.5.11 Outband NB/GE Management . . . . . . . . . . . . . . . . . . . . . . . . . 105
2.5.12 Outband NB/GE Implementation . . . . . . . . . . . . . . . . . . . . . . . 107
2.5.13 Gigabit Ethernet management . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.6 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
2.6.1 Synchronization in VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
2.7 Internal Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
2.7.1 Architecture of Fault Management . . . . . . . . . . . . . . . . . . . . . . 113
2.7.2 Flooding Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
2.7.3 Detection Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
2.7.4 Localization Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
2.7.5 Defence Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
2.7.6 Exercising of Redundant Equipment . . . . . . . . . . . . . . . . . . . . . 122
2.8 Subscriber Line Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
2.8.1 Line Test Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
2.8.2 Elements Outside the NE Involved in Line Testing . . . . . . . . . 123
2.8.3 Management of Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
2.8.4 Scheduled Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
2.8.5 Test Threshold Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
2.8.6 Test Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
2.8.7 ADSL Line Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.8.8 VoIP Line Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

4 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.9 GE Configuration Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

3 HARDWARE ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.1 Access Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.1.1 Optical STM–1/STM–4/STM–16 . . . . . . . . . . . . . . . . . . . . . . 139
3.1.2 Electrical PDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.1.3 Ethernet interface (VoIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.1.4 Ethernet Interface (GEB3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.2 GE Line Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.2.1 ADSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.2.2 ADSL2 and ADSL2+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
3.3 Narrowband Line Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.3.1 Baseband Data LL Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.3.2 E1 Interface to Leased Line Data CPNT . . . . . . . . . . . . . . . . . . 142
3.3.3 ISDN_U Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.3.4 POTS Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.3.5 SHDSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.4 Internal Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
3.4.1 NLC Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
3.4.2 Inventory Access Bus (IAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
3.4.3 Hardware Management Wires (HMW) . . . . . . . . . . . . . . . . . . . 148
3.4.4 Server Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.4.5 HCL Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.5 MLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.5.1 General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.5.2 MLS–3F/MLS–3F4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
3.5.3 Shelf Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
3.6 Housing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3.6.1 Indoor ETSI Rack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3.6.2 Outdoor Cabinets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3.7 Printed Board Assemblies for MLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.8 HW Qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.8.1 Housing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.8.2 Subrack Common Requirements . . . . . . . . . . . . . . . . . . . . . . . . 168
3.8.3 Boards Common Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 168
3.8.4 Board Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
3.8.5 Specific SHDSL CPNT Housing Requirements . . . . . . . . . . . . . 169
4 Litespan Card and MLS Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.1 Card Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.1.1 SW Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.2 MLS Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5 LIST OF ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
6 GLOSSARY / TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

3EC 41919 0001 TQZZA Edition 01 5 / 185

 SYSTEM DESCRIPTION

Figures
Figure 1 Network Configuration Overview (excluding GE configurations) . . . . . . . 19
Figure 2 Litespan 1540 Gigabit Ethernet Network Reference . . . . . . . . . . . . . . . . . . 20
Figure 3 Ring Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 4 Star Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 5 Main MLS General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 6 Extension MLS General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 7 Litespan SIP GW in the IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 8 Litespan–1540 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 9 SDH Ring Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 10 Litespan–1540 PDH EU and RUs Configuration . . . . . . . . . . . . . . . . . . . . 37
Figure 11 Detail of the V5 Hub Reference Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 12 VoIP in Litespan 1540 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 13 Litespan 1540 GE Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figure 14 Ring Network with SNCP Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 15 Connection between LINA and NB controller . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 16 Redundancy of the NLC bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 17 Active / Standby Data Flows in NB Chains A and B . . . . . . . . . . . . . . . . . . 48
Figure 18 ADM Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 19 EMAN Gateway Mode (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 20 EMAN Gateway Mode (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 21 Gateway Ring Interconnect Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 22 Dual Node ring interconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 23 TMN Access Message Relaying between EU and RU . . . . . . . . . . . . . . . . . 63
Figure 24 Litespan 1540 GE General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 25 V5 Hubbing in Litespan–1540 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 26 Voice over IP: signalling path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 27 VoIP System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 28 Media Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 29 Signalling Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 30 Litespan 1540 GE with IWF to ATM networks . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 31 Litespan SIP Gateway System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 32 Litespan SIP Gateway VoIP server SW Architecture . . . . . . . . . . . . . . . . . . . 79
Figure 33 Communication with the Management Entities (OS, CT) . . . . . . . . . . . . . . 85
Figure 34 NE and Local CT Connected by Serial Link . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 35 NE and Remote CT Connected by a PSTN Line and a Modem . . . . . . . . . 86
Figure 36 EU Based on Litespan 1540 SDH Management from Remote OS . . . . . . 86
Figure 37 Management from Remote OS. Routing in Litespan 1540 PDH EU towards
the RU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 38 Q3 Networking Connected to Ethernet LAN Network . . . . . . . . . . . . . . . . 87
Figure 39 IP networking/routing EU–RUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 40 NB OS over IP network. NB–Hub or NB–Stand–alone. Non–SDH Ethernet
networking. Architectural Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 41 NB Q3 over IP network. IEEE802.3 networking at Hub, LL networking at RU.
Architectural Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Figure 42 NB Q3 over IP network. Hub/Remote Overhead internal networking.

Architectural Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 43 NB Q3 over IP network. V5 networking. Architectural Diagram . . . . . . . . 94
Figure 44 NB Q3 over IP network. V5–Hub networking(consolidated V5). Architectural
Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 45 NB Q3 over IP network. LL networking. Architectural Diagram. . . . . . . . . 96
Figure 46 NB Q3 over IP network. Consolidated LL networking. Hub/Remote External
Transport. Architectural Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 47 System Architecture (Ethernet Transport) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 48 GE management through NB controller: SDH case . . . . . . . . . . . . . . . . . . 103
Figure 49 GE management through NB controller: PDH case . . . . . . . . . . . . . . . . . . 104
Figure 50 LS1540 Network Management (A1353DN/A1355DN, AMS) overview . 104
Figure 51 Management model for voice in LS–1540 VoIP . . . . . . . . . . . . . . . . . . . . . 105
Figure 52 Outband OAM Ethernet Reference Network . . . . . . . . . . . . . . . . . . . . . . . . 106
Figure 53 Communication between Element Managers and NE . . . . . . . . . . . . . . . . 108
Figure 54 MLS–3F/3F4 synchronism with LIOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 55 MLS–3F/3F4 synchronism with GIO3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figure 56 Litepan System Synchronization with a NTP server . . . . . . . . . . . . . . . . . . . 112
Figure 57 Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Figure 58 Redundancy of 51.84 Mbit/s Extension Link (NSEC–C) . . . . . . . . . . . . . . 117
Figure 59 Redundancy of the NLC Bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure 60 Distributed Flip–Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 61 SLT3 card and CPNTs network positions and tests . . . . . . . . . . . . . . . . . . . . 123
Figure 62 GEB3 and EFL3 Subsystems and Data Paths . . . . . . . . . . . . . . . . . . . . . . . . 137
Figure 63 MLS–3F and MLS–3F4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Figure 64 MLS–3F/MLS–3F4 backplane connectivity . . . . . . . . . . . . . . . . . . . . . . . . . 158
Figure 65 Physical Layout Indoor Racks for 4 MLSs (Example) . . . . . . . . . . . . . . . . . . 161
Figure 66 Physical Layout 1 MLS Outdoor Cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Figure 67 Physical Layout 2 MLS Outdoor Cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

3EC 41919 0001 TQZZA Edition 01 7 / 185

 SYSTEM DESCRIPTION

Tables
Table 1 Litespan–1540 Customer Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 2 Product Configurations (Outdoor Cabinet) . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table 3 Product Configurations (Indoor Rack for 4 MLSs) . . . . . . . . . . . . . . . . . . . . 51
Table 4 Product Configurations (Boards) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Table 5 IP networking possibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 6 Addressing and Interface Changes after HSO . . . . . . . . . . . . . . . . . . . . . . . 101
Table 7 Test support in Litespan 1540 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Table 8 Test outcomes in Litespan 1540 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

8 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3EC 41919 0001 TQZZA Edition 01 9 / 185

 SYSTEM DESCRIPTION

About this Document

Customer Document This Manual describes Litespan–1540 product configurations.
Scope This document scope is limited to those product configurations that
make use of Multiservice Line Shelf (MLS) technology.

Customer Document This Customer Document is organized as follows:

Organization " Title Page.
It contains the Product name, the current Family Release, the
Customer Document name, the kind of Manual (Technical,
Installation, Administrator, User) and the current Edition.
" Contents.
It contains the list of headings for:
D Chapters
D Sections
D Figures
D Tables
" Preface (This part).
It contains information about the organization of this
Customer Document, general information about all Customer
Documentation of Litespan–1540, besides the editions
published until now and the Copyright.

10 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" Chapters.
The chapters content is described in Section 1.1.
" Abbreviations.
It includes a list of abbreviations used in this Manual.
" Glossary.
It is a list of the terms used in this Manual.

3EC 41919 0001 TQZZA Edition 01 11 / 185

SYSTEM DESCRIPTION

Customer Document This Manual (Publication Item: 3EC 41919 0001), can be
Delivery delivered in CD–ROM.
It includes a collection of all the Litespan-1540 Manuals to
browse the documentation in a Personal Computers running
Windows or in a Workstations running UNIX Operation System
(HP and SUN).
Codes: See Section Litespan-1540 Customer Documentation
in this Preface.

Litespan-1540 The Customer Documentation for Litespan–1540 Equipment

Customer consists of the Manuals included in Table 1.
Documentation These Manuals can be delivered in CD–ROM:
" Code: 3EC 41917 AAAA
1 CD–ROM with the following:
D Litespan–1540 R3.2.
" Code: 3EC 41924 AAAA
5 CD–ROM with the following:
D Litespan–1540 R3.2.
D Alcatel–L ucent 1353 DN R5.0, Alcatel–Lucent 1350
OMS–EML R.9.1, Alcatel–Lucent 1353 PSM &
Alcatel–L ucent 1353 DN OSS–GW R9.1.
D Alcatel–L ucent 1355 DN R9.0 & Alcatel–Lucent 1355
DN OSS–GW R9.0.
D Alcatel–L ucent 5523 AWS 7.2 & Alcatel–Lucent
5523 AWS TL1 HW R7.2.
D Alcatel–L ucent 5520 AMS R8.4.1

12 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Table 1 Litespan–1540 Customer Documentation

CODE NAME
3EC 41919 0001 System Description (Technical Manual) This Manual
3EC 41920 0001 Units Detailed Description (Technical Manual)
3EC 20059 0002 Indoor Rack (Installation Manual)
3EC 20060 0001 Outdoor Cabinet (Installation Manual)
3EC 41921 0001 NB–CT . Operation & Graphical Interface Description (User Manual)
3EC 41922 0001 NB–Craft Terminal SW Application (Installation Manual)
3EC 41923 0001 Alarms List (User Manual)

3EC 41919 0001 TQZZA Edition 01 13 / 185

SYSTEM DESCRIPTION

Editions List This Manual have been published with the following editions:

EDITION DATE MODIFICATIONS

01 2009/06/24 First Edition FR3.2

When used for intended purposes, the units which form the
Litespan–1540 system comply with the standards listed in the
Statement of Conformity.

E Copyright ALCATEL–L UCENT ESPAÑA, S.A. – 2009

This document is the property of Alcatel–Lucent España, S.A. Its
contents are subjected to change without previous notice. It does
not represent any compromise by Alcatel–Lucent España, S.A.
All rights reserved. No part of this publication may be reproduced
or transmitted in any form or by any means, electronic or
mechanical, including translation, using of drawings or planes,
microfilming or any information storage and retrieval system now
known or to be invented, without permission in writing from
Alcatel–L ucent España, S.A.

14 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3EC 41919 0001 TQZZA Edition 01 15 / 185

 SYSTEM DESCRIPTION

1 OVERVIEW OF PRODUCT CONFIGURATIONS

AND APPLICATIONS

1.1 Introduction
This Manual establishes the global system overview of
Litespan–1540 product configurations. All product configurations
in the scope of this document make use of Multiservice Line Shelf
(MLS) technology. The MLS is the container for Litespan–1540
configurations.
The Manual has the following structure:
" Chapter 1: Gives an overview of the different product
configurations belonging to Litespan–1540, their network
positioning and their features
" Chapter 2: Gives a detailed description of the system–level
architecture inside the product configurations, covering
internal communications, control, TMN interfacing,
synchronization and internal maintenance
" Chapter 3: Focuses on hardware aspects, such as external
and internal interfaces, as well as board architecture
" Chapter 4: Shows Litespan card and MLS compatibility
" Chapter 5: Abbreviations used in this document
" Chapter 6: Explanation of the terminology found in this
document

16 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

1.2 Definition of Network Elements and Applications

The following sections gather the Network Elements defined,
according to their implementation.

1.2.1 EU
The Exchange Units are access node systems installed in the CO
(LE) able to terminate the transmission links coming from remote
access nodes (RU) to the Service Node(s) for traffic (V reference); it
also provides the management (Q) and synchronization interfaces
to the AN. The normal application of the EU is to “parent” PDH
DLC equipments. There are several types of EU functionality:
" Transparent (NM routing): EU providing only transmission
termination and management channels extraction and routing
to the OS. This EU has no bearer traffic handling capabilities.
" EU with LL grooming providing transmission termination and
separation of LL traffic (Towards the LL network) from Switched
traffic (Towards the LE). It provides RU’s Management
Channels extraction and routing to the OS as well.

1.2.2 RU
Remote Units are access node systems installed in remote
locations and connected to Service Nodes by means of an EU. RUs
are linked to EUs by dedicated PDH transport. Each RU is
considered as a separate NE in TMN concept.

1.2.3 GE
The GE are Gigabit Ethernet applications. Network interfaces are
based on Ethernet. They can be optical (SFP GE port) or electrical
(10/100/1000BASE–T RJ45 ports).

1.2.4 SIP
Litespan SIP Gateway (LSG) will provide PSTN/ISDN simulation
services in IMS according to TISPAN specifications.
From the point of view of IMS, LSG will act as a User Equipment
(UE).

1.3 Network Reference

This section describes the network architecture.

3EC 41919 0001 TQZZA Edition 01 17 / 185

 SYSTEM DESCRIPTION

1.3.1 Naming of Network Elements in Litespan-1540

Depending on the point of view, the Litespan–1540 node can
receive different names:
From the point of view of Transport:
" Litespan–1540 SDH: For SDH Transport.
" Litespan–1540 PDH: For PDH Transport. The following PDH
transport are possible: Electrical G703, SHDSL.
" Litespna–1540 GE: For GE Transport.
From the point of view of the Q3 management routing, the
following configurations are distinguished:
" Exchange Unit EU: It makes grooming of Q3 channels
coming from remote Litespan–1540 nodes.
" Remote Unit RU: It hangs from a Litespan–1540 Exchange
Unit. Its Q3 channel is conveyed through the EU.
" Stand alone: A DLC which is neither EU nor RU. Its Q3
channel is conveyed through the DCN or through the LE
(V5TS).
It is important to know that the EU functionality can be
activated by provisioning. In this way, an stand alone node
can become a EU by an operator action.
From the V5 HUB service point of view two kinds of roles are
distinguished: V5EU and V5RU.
" V5EU – V5 Exchange Unit (Hub Node).
A Litespan–1540 Node that connects one or several Remote
Nodes to a Local Exchange performing a concentration of V5
interfaces. This is also the default value in case of a
stand–alone node.
" V5RU – V5 Remote Unit (Remote Node).
A Litespan–1540 Node that is not connected directly to the
Local Exchange but through another Litespan–1540 node
that performs a concentration of V5 interfaces.
From the Access Gateway service point of view, two kinds of
accesses are distinguished: SCN and NGN.
" SCN: It is done through PDH or SDH network interfaces, as in
any classical network element (V5.x...).

18 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" NGN: It is done through the Decentralized Access Gateway

via Ethernet 100BaseT.
Any Hub or Remote Node DLC can be upgraded to Litespan
Access Gateway by adding VoIP server card(s). Up to 2 VoIP
server units can be plugged in a Litespan–1540 node.

1.3.2 Reference Network without GE configurations

This sections describe the access network with Ring and Star
configurations. Figure 1 shows a whole view of a possible network
without GE configurations. Each topology is depicted in detail
afterwards.

3EC 41919 0001 TQZZA Edition 01 19 / 185

 SYSTEM DESCRIPTION

ÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄ
Other networks
SDH Core Ring Internet, Leased lines

ADM C. Office ÄÄÄÄÄÄÄÄÄÄ Residential Residential

LE V5 EU V5 RU
V5 RU

V5 RU
EU Residential
Residential Residential
V5 RU
Residential
V5 EU
ADM

STM–1/4 Access Ring SD+AGW

PD
RU V5 RU
SD
Residential Residential /
Residential Business area
Residential

Router PD+AGW
PD+AGW
1353DN OS
1353PMS
Residential IP Network
AMS Residential /
Business area
DCN Router

SD Litespan 1540 SDH DLC Soft Switch

Call Server
PD Litespan 1540 PDH DLC MGC

Network I/F Transport: Services at subscriber side :

Litespan 1540 SDH +
SD+AGW PSTN V5
Access Gateway STM–1 ISDN BA V5
PD+AGW Litespan 1540 PDH + STM–4 ISDN PRA V3
Access Gateway n x 64 LL
PDH E1 SHDSL
EU Litespan 1540 PDH EU ADSL
Subtending Transport :
ADSL2/2+
RU Litespan 1540 Remote Unit SHDSL PSTN over IP
parented by EU
ISDN BA/PRA over IP
External G.703
V5 EU Litespan 1540 V5 HUB Node Fax over IP (T.38)
(V5 EU) PSTN SIP

V5 RU parented 1540
Litespan Remote Node (V5 RU)
by a V5 EU Node

ADM

Figure 1 Network Configuration Overview (excluding GE configurations)

20 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

1.3.3 Reference Network for GE configurations

Figure 2 shows the Gigabit Ethernet Reference Network

Litespan AN

ADSL Litespan AN Ethernet

Switch
STM–1
nGE Ethernet
ADSL/2/2+ Switch IP Edge
Router
Network Service Provider
EMAN
Litespan AN FE/GE IP backbone
ADSL/2/2+ Ethernet
FE/GE Switch
Ethernet
FE/GE Switch

Litespan AN IP Edge
Router
ADSL/2/2+ mGE Network Service Provider
IP backbone
FE/GE

ADSL/2/2+
GE
POTS STM-1
ATM Network
ISDN–BA E1
E3 SDH
FE/GE
IWF
ANIT–A

Figure 2 Litespan 1540 Gigabit Ethernet Network Reference

3EC 41919 0001 TQZZA Edition 01 21 / 185

 SYSTEM DESCRIPTION

1.3.4 SDH Access Ring

Figure 3 illustrates the ring configuration.

LE

SD
Central Office
ADM
STM-1/STM-4/STM-16
PD Access Ring SD

SD

Figure 3 Ring Configuration

1.3.5 Star Configuration

The Star configuration can use proprietary PDH transport as well
as External transport. It is the only considered as EU–RU
configuration (See Figure 4).

PD PD

SD PD
PD PD

PD PD

Figure 4 Star Configuration

1.3.6 Network Dimensioning

The network configurations described above are limited in the
number of nodes that builds the Litespan–1540 network due to
performance and implementation reasons.

22 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

The access network composed of several Litespan–1540 nodes, is

headed by a node acting as Exchange Unit (EU) which subtends
several Litespan–1540 nodes which themselves behave as
Remote Units (RU). The EU has the interfaces with the Service
Node (LE, or LL).
The way to transport the Q3 management messages for every
Litespan–1540 node is by using a bearer (64 Kbps), this can be
in the payload or in the Overhead transport links (Without
consuming payload) of the SLT3 or PRC3 links.
The use of one bearer for transporting the management of several
Litespan–1540 nodes introduces the dimensioning restrictions
due to this BW limitation.
Note In the Litespan–1540 network there is an entry point
for the NM of all the nodes, which is the EU. Then in
order to cope with the above target, the BW allocated
for the management in the EU must be higher or equal
to 64 Kbps.
The Litespan–1540 nodes routing performance when dispatching
the NM info to the rest of Litespan–1540 can also be restricted by
the intrinsic Litespan–1540 load activity due to the
traffic/signalling/OAM services each node is providing.
The target number of nodes that builds up a Litespan–1540
Access network is 16. The ”star network” are limited to have one
root EU with up to 15 branches RUs.
This is a target value which could be reachable in case of the
Litespan–1540 nodes are LL service oriented and then the nodes
are relieved from the signalling process load. In case of low NM
performance because of the high load in the Litespan–1540
nodes this number could be lower. The range goes from 1 node
(The EU itself) to n<=16 (Including the EU). Also, the
dimensioning limits of the GE controllers at the EU are an
additional restrictions to the maximum limit stated above.

3EC 41919 0001 TQZZA Edition 01 23 / 185

 SYSTEM DESCRIPTION

1.4 Network Management

From the point of view of Management, 3 separate NEs coexist in
the MLS (Access, Transport, GE). They are managed by 4 different
management systems:
" Alcatel–L ucent 1353 DN for the Litespan–1540 NB Access
part EML level. CMISE and CAMINA model are used at the
application layer.
" Alcatel–L ucent 1355 DN for the Litespan–1540 NB Access
part SML level. CMISE and CAMINA model are used at the
application layer.
" Alcatel–L ucent 1353 PMS for the SDH transport part EML
level. SNMP is used at application layer.
" Alcatel–L ucent 5523 AMS for the GE part (Modified to show
the MLS physical view). SNMP is used.
Although the four management systems are different applications,
depending on the specific Litespan–1540 Family Release and
Drop different levels of integration between them are featured:
" Alcatel–L ucent 5523 AMS and Alcatel–Lucent 1353 DN
screen level integration.
" Alcatel–L ucent 1353 PMS and Alcatel–Lucent 1353 DN
running in the same OS machine.
There are also three different Craft terminals that may be
connected locally to the 3 separate NEs (Access, Transport and
GE).

1.4.1 Transport of the Management Information (DCN)

The management information transport mean depends on the NE
type in the MLS:
" For the SDH Transport NE, TMN information is always routed
through the Qecc embedded channel in the SDH ring.
" For the NB Access NE, the following TMN communications are
supported:
D In EU or Stand Alone Nodes. OSI transport:
h Ethernet.
h V5 embedded TS
h LL G.704 embedded TS

24 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

h For SDH nodes the Qecc transported between the

LINA and the NB controller by internal DCC
D In EU or Stand Alone Nodes. IP transport:
h Ethernet
h V5 embedded TS
h LL G.704 embedded TS
h For SDH nodes the Qecc transported between the
LINA and the NB controller by internal DCC
D Between EU and RU:
h V5 embedded TS transparent. This NM transport
scenario is only applicable in the configuration in
which the transport card between EU and RU is
NEHC–C in both sides. V5 hubbing assume that in
case of Q3 transported over an V5 Timeslot to the
V5RU, the V5EU does not provide the hubbing of Q3
h LL G704 embedded TS. This NM transport scenario
is only applicable in the configurations in which the
transport cards between EU and RU is NEHC–C in
RU side (NT) and NEHC–C or PRC3 in EU side (LT)
h SHDSL overhead channel.
h V5 embedded TS with hubbing functionality. This NM
transport scenario is only.applicable in the
configurations in which the transport cards between
EU and RU is NEHC–C in RU side (NT) and
NEHC–C or PRC3 in EU side (LT).
According to this, when V5 embedded TS is used between
LE and EU, and NEHC–C is not used as transport card in
RU, the NM hubbing functionality is carried out by the EU
by doing the routing of the TMN communication coming
from the RUs extracting it from the SLT3 ports overhead
channel. In case of external transport (NEHC–C as
transport card in RU), the NM hubbing functionality can
only be supported by embedding the TMN
communication between EU and RU in a LL G.704 TS or
V5 TS.
" For the GE NE, the TMN information is always routed through
the Ethernet network.
The internal communication between GEB3 and its LIMs is
Ethernet based. An internal OAM VLAN is reserved for the internal
communication.

3EC 41919 0001 TQZZA Edition 01 25 / 185

 SYSTEM DESCRIPTION

With the adition of ANIT–A card IWF also TMN information can
be routed from GEB3 through an ATM network.

1.5 Overview of Product Architecture

1.5.1 General Architecture

The Litespan–1540 product configurations are built around a
Multiservice Line Shelf (MLS). The MLS contains the line circuits
that feed the copper pairs. One MLS cascade is named MLSA
(MLS Assembly).
The MLSs constituents of a MLSA can be cascaded up to four levels
for pure NB services (One main MLS and up to three extension
MLSs can be connected).
Litespan–1540 can provide the following NB services:
" V5 POTS. Hot standby functionality preserving stable calls
introduced in this release
" V5 ISDN BA. Hot standby functionality preserving stable calls
introduced in this release
" Leased lines N x 64
" Leased lines transparent at 2 Mbit/s
" V3 PRA
" LL grooming
" Performance monitoring for V5.2 traffic
" Performance monitoring for ISDN BA Q.821/Q.822
" V5 Hubbing for POTS and ISDN BA
" SHDSL
" V5 Semipermanent Leased Lines
" Voice over IP. Hot standby functionality preserving stable calls
" ISDN over IP. Hot standby functionality preserving stable calls
" FAX over IP Hot standby functionality preserving stable calls
When the Litespan–1540 node is behaving as a EU, it provides
the following NB services towards the subtended Litespan–1540
network:
" Management channels extraction either by performing IS/IS
or by implementing a totally transparent connection to the
subtended network.

26 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" Transparent Traffic: No processing in the EU. This is applied

for V5 services of full E1 links that do not need any further
processing before entering into the service network.
" Traffic Grooming: Rearrangement at DS0 level of the Leased
Lines traffic coming from Litespan–1540 Remote Units before
entering the LL network.
Litespan–1540 can provide xDSL services:
" ADSL
D Gigabit Ethernet (GEB3)
h Gigabit Ethernet (GEB3–A) to STM–1 using IWF is
possible, and with ANIT–A card IWF also E1, E3 and
STM–1, both IMA and not IMA, are also possible
" ADSL2 / ADSL2+
D Gigabit Ethernet (GEB3)
h Gigabit Ethernet (GEB3–A) to STM–1 using IWF is
possible, and with ANIT–A card IWF also E1, E3 and
STM–1, both IMA and not IMA, are also possible
" FE / GE
D On top of the HCL links provided by GEB3 to connect the
EFL3s, GEB3 also allows some Ethernet ports that can be
used for different purposes. In particular there are two
Litespan–1540 specific uses:
h To connect VIS3, thus allowing aggregation of VoIP
traffic
h To connect NEHC–C management, thus allowing
aggregation of NB external management
Conceptually, the MLS is defined by the pin–out and board size,
as well as by the restrictions imposed to the cards to be plugged in
it. This means that, although there are many MLS variants, cards
are in most cases compatible and pluggable in all of them. MLSs
are described in detail in Chapter 3.
MLSs are structured around several buses:
" NLC bus has downstream, as well as upstream, a BW of
51 Mbit/s, subdivided into 64 Kbit/s channels.
" The HCL point point bus has a downstream bandwidth and
an upstream bandwidth of 17 x 155 Mbps.
These buses are generated by the shelf controllers. Shelf
controllers for the main MLS are NEHC–C or NBCB, for all NB
applications, and GEB3 for GE applications.

3EC 41919 0001 TQZZA Edition 01 27 / 185

SYSTEM DESCRIPTION

The central controllers in the Main shelf are able of controlling the
complete MLSA, i.e., main + extensions for each kind of service:
NB and GE. The extension MLSs are connected in cascade to the
main shelf controller. The extension shelves have the shelf
extension cards as a common card. The extension performs
physical relaying of the traffic signalling and control interfaces. A
type of extension exist:
" NSEC–C : Narrowband only shelf extension, only capable of
extending the NB bus (NLC)
HCL links are generated by GEB3 and they can not be extended,
then for GE services only main MLS with GEB3 is used.
The Litespan 1540 architecture is open to accept several types of
Server functions such as VoIP Server. Servers functions are
extending the basic functionality of Litespan 1540 without
affecting the rest of the hardware and with limited impact on
software. Most likely different servers will be identified during the
lifecycle of the Litespan 1540 product configurations.
The MLS main general architecture is shown in Figure 5. HCL links
are not represented.

28 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Network MLS User

NLC
POTS
NB LIM
ISDN–BA
PEIC
NB controller
or POW3
G.703 (not SHDSL
Transport / LL
in POW3) G.703
LINA Server bus
STM–1/4/16 (4 x 8 Mb)

VoIP server NB LIM

Ethernet (VoIP)
POTS
Ethernet ISDN–BA

LIOC
Ethernet NM CT
or GIO3
Synch (not
in GIO3)
or ISDN–BA
Ethernet +
STM–1 ADSL
E3 ANIT–A POTS
HCL
E1
Alternative GE LIM
Ethernet or
GEB3 16x ADSL
Ethernet (VoIP) + NM

STM–1 ATM GE LIM

(GEB3–A IWF, not in GEB3–B) Alternative
HCL
NTIO links
Ethernet

Downwards
Extension

Figure 5 Main MLS General Architecture

Note When NBCB card is considered both NB controller and

VoIP functions are provided by this card

3EC 41919 0001 TQZZA Edition 01 29 / 185

 SYSTEM DESCRIPTION

The MLS extension general architecture is shown in Figure 6.

Upwards Extension NLC

NSEC-C (M) NB LIM

(S)

Downwards Extension

Figure 6 Extension MLS General Architecture

All cards in Litespan–1540 have on–board DC/DC converters,

so that cards requiring different voltages can be flexibly combined
in the same MLS.
The main functions of the architecture building blocks are listed
below.
" NEHC–C
D NE controller (i.e. containing the Q3 agent)
D NB processing handling the service layer with services of
the NB part like V5, Nx64 kbps grooming, line testing,
etc.
D Controls NB LIMs, transport terminals (note that in this
case the high speed transport terminal LINA can not be
controlled), and Servers
D Interfacing of 16 x E1 G.703 links with the NLC bus
inside the MLS and with the subtending MLS interfaces.
These interfaces are supported onboard
D Master of the NLC bus
D TMN Front End on the management stream received
directly via Ethernet or from a transport card via NLC bus
D Optionally redundant. Redundancy is 1+1 with a full
duplex 100M Ethernet communication interface between
both NEHC–C cards
D Links to extension MLSs NSEC–C boards
D External alarm/commands interface
D CT logical interface via serial port
" NBCB

30 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

D NE controller (i.e. containing the Q3 agent)

D NB processing handling the service layer with services of
the NB part like V5, Nx64 kbps grooming, line testing,
etc.
D Controls NB LIMs and transport terminals (note that in
this case the high speed transport terminal LINA can not
be controlled)
D Master of the NLC bus
D TMN Front End on the management stream received
directly via Ethernet or from a transport card via NLC bus
D Optionally redundant. Redundancy is 1+1 with a full
duplex 100M Ethernet communication interface between
both NEHC–C cards
D Links to extension MLSs NSEC–C boards
D External alarm/commands interface
D CT logical interface via serial port
D Voice over IP server board providing voice, voiceband
data, ISDN over IP and Fax over IP (T.38) services
D Ethernet interface
D Megaco/H.248 Media Gateway
D Sigtran Signalling Gateway
D SIP Gateway
" NSEC–C
D NLC extension card for NB extensions
D This card is only pluggable in Extension MLSs
" VIS3
D Voice over IP server board providing voice, voiceband
data, ISDN over IP and Fax over IP (T.38) services
D Connected to NLC bus
D Connected to the NB controller by two point–to–point 8
Mb/s buses (server bus)
D 1+1 (active–standby) redundancy
D Ethernet interface
D Megaco/H.248 Media Gateway
D Sigtran Signalling Gateway
D SIP Gateway

3EC 41919 0001 TQZZA Edition 01 31 / 185

SYSTEM DESCRIPTION

" LINA
D High speed transport terminal (SDH transport controller
containing the SNMP agent)
D Supports STM–1, STM–4 and STM–16 interfaces
D Connected to NB processor
D Terminates SDH type network interfaces
D Can be configured for different SDH network topologies:
h Point to point
h Add–Drop Multiplexer in linear or ring topologies
D Optionally redundant
D It is plugged into the Main shelf
" PRC3
D Terminates PDH type of network interfaces (LT side)
D 8 G.703 interfaces
D Leased line LT
D V3 PRA LT
D NT
D Low speed transport terminal
D This card is pluggable in both Main and Extension MLSs

" SLT3
D Low speed transport terminal
D Terminates PDH type of network interfaces (LT and NT
side, configurable per port)
D 8 SHDSL interfaces; up to 8 E1s can be connected to the
NLC bus and up to 4 of them to G.703 or to the NLC bus
in an individual manner, when configured as one pair of
wires working mode
D Leased line LT (with SHDSL CPNT as NT)
D V3 PRA LT
D 2w/4w are supported. No mix of 1 pair, 2 pairs is
supported
D This card is pluggable in both Main and Extension MLSs

" NB LIM
D User interfaces termination

32 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

D Typically, there is one type of LIM for each type of user

interface
D Slave on the NLC bus
D They are plugged in both Main and Extension MLSs
" GEB3
D Gigabit Ethernet Controller
D It is the master of HCL links
D LANx module
D Optionally redundant
D 1+1 Equipment redundancy available in HW, not in SW
D It is plugged in the Main shelf
" GE LIM
D Translation and mapping of ADSL lines into GE linls
towards GE controller cards (GEB3)
D Use of HCL links
D Supports ADSL / ADSL2 / ADSL2+ interfaces
D Versions with and without splitter for POTS or ISDN–BA
services
D These cards are pluggable only in in the same MLS that
GEB3 controller is plugged
" ANIT–A
D Ethernet to ATM converter
D Backplane HCL connection or external fiber connection to
GEB3 (depending on position in the MLS)
D STM–1, 2xE3 or 8xE1 ATM interfaces selected by internal
microswiches
D ANIT–AE1 cost reduction version equipped only with E1
ATM interfaces
" NTIO
D Decouples upling protection from GEB3 equipment
protection
D Provides additional uplinks to the 2 provided by GEB3
" PEIC
D Power and E1 interface card
D 16xE1 external interfaces from/to both NB–CCs

3EC 41919 0001 TQZZA Edition 01 33 / 185

SYSTEM DESCRIPTION

D Power feeding interface, A and B branches

D NLC buses termination
D Configurable straps for MLS numbering
" POW3
D Power and GE interfaces card
D Power feeding interface, A and B branches
D Allow macanical compatibility with GIO3 for GE
interfaces connection
D NLC buses termination
D Configurable straps for MLS numbering
" LIOC
D Local Input/Output card
D Outband O&M Ethernet interface
D Craft Terminal interface
D G.703 synchronization interface
D External alarm collection and commands
" GIO3
D Local Input/Output card. This is a variant of LIOC
D Outband O&M Ethernet interface
D Craft Terminal interface
D GE interfaces connection
Litespan, as a Megaco Media Gateway, has a clear role in the IMS
architecture, acting as an IMS–MGW as shown in Figure 7.
However, Litespan proposal for a SIP GW does not correspond to
a defined gateway role in IMS; instead, it should be considered as
a set of SIP UE’s.

34 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

HSS Application Server

CSCF

I–CSCF

S–CSCF

P–CSCF

MRF MGCF
Network SIP
management
element
MegacoH.248

IP network

SIP GW
(IMS–UE) Megaco MG
(IMS–MGW)
SIP phone
(IMS–UE)

Figure 7 Litespan SIP GW in the IMS

It is assumed that Litespan can work either as Megaco GW or as

SIP GW, but not both at the same time

1.5.2 Litespan-1540 Node Architecture

Figures 8 shows Litespan–1540 Node Architecture .
LINA board is only used in SDH configurations. In PDH
configurations, 16 E1 links are directly accessed by NEHC–C.
The following transport card (TT) combinations in the EU and the
Remote nodes are possible for the subtending of Remote nodes in
Star configuration:
" NEHC–C (EU) – NEHC–C (RU)
This can require the use of G.703 External Transport facilities.
NB and GE services can be provided by Litespan–1540 SDH and
PDH configurations.

3EC 41919 0001 TQZZA Edition 01 35 / 185

 SYSTEM DESCRIPTION

External MAIN MLS–3F/3F4

4xE1

LINA to NB controller
STM–1/4/16
STM1
2xE3 Alternative ANIT–A
8xE1

FE/GE HCL
NTIO
Alternative
STM1 GEB3
(GEB3–A Ethernet
IWF, not in VoIP server 16 HCL links
GEB3–B)
Server bus
NLC
PEIC/
NB controller POW3
G.703
LIOC/ NB NB NB GE GE TT or (not in
GIO3 Line Line Line Line Line LL POW3)
Card Card Card Card Card Cards

MLS links Ethernet

Payload+NM CT POTS POTS or ISDN–BA SHDSL
ISDN–BA ADSL
+ADSL

External EXTENSION MLS–3F/3F4

4xE1

STM1
2xE3 Alternative ANIT–A
8xE1
FE/GE HCL
GEB3
STM1
(GEB3–A IWF, 16 HCL links
not in
GEB3–B) NLC PEIC/
NSEC–C POW3
NB NB NB GE GE TT or
Line Line Line Line Line LL
Card Card Card Card Card Cards

MLS links
POTS ISDN–BA POTS or ISDN–BA SHDSL
ADSL
+ADSL

To the next Extension

Figure 8 Litespan–1540 Architecture

Note When NBCB card is considered both NB controller and
VoIP functions are provided by this card

36 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

1.5.3 Internal Architecture of each Configuration

(1) Litespan-1540 SDH Ring Configuration
Figure 9 shows the SDH ring configuration.

1355 DN
1353 DN
1353 PMS
AMS OS V5 Litespan 1540 Litespan 1540
( Q3 on LL TS/EOC) PDH (RU#1) PDH (RU#15)

V5
LE DCN ( Q3 on LL TS / EOC)
Litespan 1540
SDH EU
Litespan 1540
TDM
V5 SDH
LL E1 LL
ADM LINA
STM–1 / STM–4 Access Ring NB controller NBLIM

Server NLC
Bus
VoIP server

GELIM
HCL
Ethernet GEB3 to NB controller

E–MAN

Figure 9 SDH Ring Configuration

Note When NBCB card is considered both NB controller and

VoIP functions are provided by this card

(2) Litespan V5 Hubbing and LL Grooming

The star configuration using SHDSL and G.703 PRC3 is shown in
Figure 10.

3EC 41919 0001 TQZZA Edition 01 37 / 185

 SYSTEM DESCRIPTION

OS

LL network
Q3hub + Q3#1 + Q3#2 + Q3#3 + .Q3#4...

DCN

LL groomed
HUB (V5EU) Remote Units (RU)
(from #1, ..., #n)
(Q3)RU#1
V5 local+ HUB NB controller
LE
LE (Q3#1 on LLTS/V5TS) PRC3 NB controller

Remote
V5 from #1 LIM
PRC3 Users
(Q3)RU#2
V5 from #2 (Q3#2 on EOC)
SLT3–A O
SLT3–A NB control-
ler

Remote
NLC bus

LIM LIM
Local Users Users

V5 from #3

SLT3–A

(Q3#3 on LLTS/V5TS)
PRC3

V5 from #4 V5RU#3
LIM
NB
(Q3#4 on LLTS/V5TS) SLT3–A NB controller
STM1
E1 INIT–A
E3 Remote
External
LIM
HCL Users
Local Users
STM1 EFL3 Transp.
NB+GE V5RU#4
ATM (not in GEB3
GEB3–B)
HCL links NB controller

Local Users
Ethernet NTIO EFL3 Remote
LIM
GE Users
E–MAN

Figure 10 Litespan–1540 PDH EU and RUs Configuration

38 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(3) Reference Network for V5 HUB

Figure 11 shows the V5 Hub reference network.

Hub Node Remote Nodes

V5.2 V5H V5.2 POTS
HUB ISDN
LE V5H V5RU
Nx64 LL
SHDSL
PRA V3
V5.2 V5.2
POTS
ISDN POTS
V5EU ISDN
Nx64 LL V5RU
SHDSL Nx64 LL
PRA V3 SHDSL
PRA V3
V5 transparent
OS V5.2
POTS
ISDN
V5RU
DCN Nx64 LL
SHDSL
PRA V3
V5 Hubbing function (V5EU /V5RU) is independent from Q3 hubbing function (EU /RU)
V5 Hubbing is independent from the transport means between V5EU and V5RU

Figure 11 Detail of the V5 Hub Reference Network

3EC 41919 0001 TQZZA Edition 01 39 / 185

 SYSTEM DESCRIPTION

(4) Reference Network for VoIP

Media Gateway
MEGACO/UDP/IP Controller
(MGC) OS
or
Q.931/IUA/SCTP/IP
DCN
CT
IP access
network IP or POTS / ISDN
PSTN/ISDN TGW IP/PPP/L2TP
RTP/UDP/IP
T38/UDP/IP ATM or Ethernet LS–1540
PPP/L2TP (AGWs)
(UDP/IP)tunnel
(IAPs)
IP backbone modem
PPP
ISP(s)

Internet access

Figure 12 VoIP in Litespan 1540

40 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(5) Reference Network for Gigabit Ethernet

Litespan GE RU

ADSL Litespan GE EU

STM–1 Ethernet
nGE Switch IP Edge Router the
ADSL /2/2+ Network Service
POTS Provider IP backbone
ISDN–BA Ethernet
Switch
Litespan GE EU FE/GE
ADSL /2/2+ EMAN
POTS
ISDN–BA FE/GE
FE/GE
Ethernet Ethernet
Switch Switch
Litespan GE RU
ADSL /2/2+
POTS
FE/GE
ISDN–BA
FE/GE

Litespan GE standalone IP Edge

ADSL /2/2+ Router
POTS mGE
ISDN–BA Network Service
Provider IP backbone
FE/GE

Figure 13 Litespan 1540 GE Architecture

Also the connection of a Litespan GE AN to an ATM network is

possible using the IWF perfromed by ANIT–A card connected to
GEB3.

3EC 41919 0001 TQZZA Edition 01 41 / 185

 SYSTEM DESCRIPTION

1.5.4 Litespan-1540 Redundancy

(1) Transport and Access Equipment Protection
Failure in the Transport part (TT) active LINA board provokes a
switch–over to the standby LINA board. Some failures in the
upstream link LINA / NB controller may provoke the switchover of
one NB controller to the other commanded by the LINA by means
of the RTS HW signal.
Failure in the Access Equipment Chain (AEC) active NB controller
or NSEC–Cs will provoke as well a switch–over to the standby
NB controller and NSEC–Cs. As result of the failure, a SW or a
HW requests of switchover is triggered. If the request is honored
(No failure in the standby chain) the resulting states will indicate to
the NB controller the new standby status Active/Standby.

(2) Transport Protection - LINA

There are two types of protection:
" Equipment protection (EPS).
" Network protection (SNCP/I).
EPS protection means that for each type of failure on the LINA
main board (Matrix, CRU, software controller failure) a switch is
performed to the spare card.
Note The optical/electrical port and the EC function are not
EPS protected.
SNCP/I protection is used on ring, linear and mesh network
topology. Switching occurs on the path selecting (Rx side) the
signal transmitted to both Tx A and Tx B sides, where A and B are
two different directions.

EPS Hardware Failure LINA

Types is an integrated implementation in a unique unit of those
functionalities distributed in several units of the previous ADMs
(E.g., ADM 1640), already used by the client. Neither in those
ADMs, nor in LINA, the protection is supported on the controller
unit (SMEC), which is in charge of the transport connections
control and management, as well as of the communication with
the operator terminals.
The units in charge of the transport (Conmutation matrix,
tributaries and optical aggregates) do have the possibility of
redundancy.

42 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

The controller function has been concentrated in one of the LINA,

which is in the slot 5 of the Main subrack of the Litespan–1540
SDH. The functionality inserted in slot 6 is the redundant one for
the transport functions only. While the control part of the LINA in
slot 5 is running, the functions of the management interfaces keep
on working, although the optical transport is performed in slot 6.
The causes or HW problems that may provoke the automatic
conmutation of one unit to the redundant one and, more
specifically, the conmutation from slot 5 to slot 6, are:
" Power failures, unit extraction and any other failure that, in
general, may affect to the control part and, consequently, may
interrupt the management function.
" Failures affecting the traffic (Synchronization loss, problems in
the optical modules, problems in the electrical interfaces,...).
These failures do not affect to the control part, thereby they do
not interrupt the management functions.
" Failures affecting the management buses, although they do
not affect the traffic.
There are other minor alarms that do not provoke an immediate
conmutation. When occurring or because of maintenance
necessities, there is one option, a SW command which allows the
operator to ask for the conmutation from the Operations System
(NM), which does not suppose a definitive loss of the system
management.

SNCP/I Network
Protection Sub–Network Connection Protection is a dedicated protection
mechanism that can be used to protect a full end–to–end path or
a portion where two separate path segments are available.
The operating mode can be revertive or not revertive. In revertive
operation the wait time to restore is fixed at 5 minutes.
As stated in the example shown in Figure 14, two nodes are ring
connected on a looped path. Each node is bi–directional
connected (Side A and Side B). One of the two directions
represents the main path (Clockwise). The opposite direction will
utilize a second fiber line for the spare traffic (Counter clockwise).
The automatic protection occurs upon detecting a path failure.
Each transmitting signal node is permanently connected (Bridge)
in the main traffic direction (Clockwise) and in the protected traffic
direction (Counter clockwise). The Tx signal reaches destination
through two different paths thus enabling the node receiving it to
select the best one (Switch).

3EC 41919 0001 TQZZA Edition 01 43 / 185

 SYSTEM DESCRIPTION

When the path is no longer available, an AIS signal is transmitted

on the same path to activate protection. In this manner SNCP can
protect the paths following cable breakdown or failures along the
fiber and nodes.
The switching decision can be taken at the NE level (Automatic
switch) or at the 1354RM OS level (Management switch).

Side A Side B
BRIDGE
T2
T1 CLOCKWISE
COUNTER
CLOCKWISE

SWITCH
Side B Side A

Figure 14 Ring Network with SNCP Protection

(3) Redundant Access Equipment

The NB controller active and standby shall keep a communication
channel for the OTRP platform to perform alignment to the
standby board (Where the platform and part of SW management,
Equipment and Services are running).
The standby NB controller shall be supervised in order to detect
possible failures, and to prevent unwanted switch–overs to faulty
NB controller.

Central Controller Redundancy is that characteristic that allows to increase the system
Boards Protection availability time, protecting it against a single element failure by
duplication of the functionality provided by this element.

44 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

The central controller provides automatic switchover in case of

fault of the active board, and OS/CT controlled switch–over.
" The Central Controller is normally configured in 1+1
redundant configuration. At initialization time (Or at board
insertion) there is a negotiation between the two boards to
determine their role as Active (Or providing service), or hot
Standby. This status is changed by a switch–over
autonomously. There are dedicated HW means to inform the
peer board the status (Operational) of the own board, to be
able to perform a take over in case of SW or HW failure.
Additionally there is a serial link to update redundant data in
in the hot Standby board (By means of the OTRP SW
platform).
" When there is a failure in one of the boards of the Central
Controller the other board is informed by HW means.
The alignment of configuration data is performed autonomously
between the active and the standby Central Controller boards.
The defence actions (Switch over, restart) will be notified to the
Operator status attribute value change (AVC).
The Access Equipment Chain (ACC) is composed of:
" MLS Chain A, composed of the first NB controller and first set
of NSEC–Cs
" MLS Chain B, composed of the second NB controller and
second set of NSEC–Cs
Failure of the active chain provokes a switchover to the standby
chain if the later is working.
The NB controller can be as well installed in non redundant
configuration by equipping only chain A. Failure of simplex
(System with one controller board) active chain A makes the
equipment to work in a degraded mode, performing only the part
of the functions not affected by the failure.
Equipment faults are reported to transmission layer and service
layer to take necessary actions on ports (Disable by dependency)
and to perform recovery of affected connections.

(4) Boards Protections

The detection of the failure shall be in the last stage done by the
active NB controller which will have the complete view of the
system status.
When the LINA suffers from a failure it shall be activated a
bit–codified condition indicating to the active NB controller which

3EC 41919 0001 TQZZA Edition 01 45 / 185

 SYSTEM DESCRIPTION

is the operative LINA card. No further detection is carried out

because the LINA behaves autonomously with respect the rest of
the Litespan–1540 system.
When the NB controller A suffers from a failure, it shall rise this
condition to the peer NB controller B in order to undertake a
switch over if allowed. After the switchover from A to B it shall be
the B that will detect that the A is in failure. The Active NB
controller will report by HW to the LINA boards the Non card fail
(NCF), while the standby NB controller or a faulty one will report
by HW to the LINA boards the Card fail (CF) indication.

(5) Links between LINA and NB controller Protection

The detection of any failure of these links is totally managed by
the LINA card which have total and exclusive control on the HW
involved in these links at both sides (LINA and NB controller).
A full crossover connection is maintained between both sides, so
the switchover of the transport terminal does not affect the access
part, and vice versa (See Figure 15).
The upstream link frames contains a bit that reflects which is the
active NB controller and which is the failed or standby NB
controller. This bit is autonomously managed by the HW of the NB
controller.
The downstream link frames contains bits that indicates to the NB
controller pair which LINA is active for the two roles: EC and SC.
These bits and the NB controller respond in order to tune towards
the operative LINA is carried out entirely by the NB controller HW
in an autonomous way.

46 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

LINA NB controller
NLC_A
East

Control busses SWO flip flop and peer link

LINA NB controller
NLC_B
West

Figure 15 Connection between LINA and NB controller

(6) NB Extension Chain Protection

The status of the two NB extension chains is monitored by the NB
controller. Each NB controller directly monitors its own NB
extension chain. (See Figure 16).
Once a failure occurs in one of the NB extension chains the failure
is first detected by one of the controllers along the chain
(NSEC–C,NB controller). If it is the active NB controller that
detects some faulty condition that affects the chain then it shall
provoke switchover to the other chain if allowed. If it is one of the
NSEC–Cs that detect the faulty condition in the chain then it
notifies to the resp NB controller what is the detected failure. Once
the NB controller detects that the chain is faulty it shall provoke the
switch over if allowed and in case of being active, or it
communicate to the active NB controller the faulty condition via
the peer link.

3EC 41919 0001 TQZZA Edition 01 47 / 185

 SYSTEM DESCRIPTION

(7) NLC Bus Protection

This is the MLS bus carrying the NB traffic and is doubled for
redundancy reasons both for Upstream and for Downstream
direction with the structure depicted in Figure 16: A failure in this
bus is indirectly detected when the communication with the Line
Cards is broken. This communication is the Data Link for the LIMs
with micro and a periodical polling for the LIMs without micro. The
failure in the NLC bus can take place in the Downstream–active,
Downstream–standby , Upstream–active and Upstream–standby
and /or a combination of them, e.g. a failure affecting both
Upstream and Downstream. Break means VA Data Link lost (In the
Line Cards with micro) and VA* Data Links lost (For the LIMs
without micro) and/or when they behave differently depending on
the Downstream and Upstream buses:
" A failure only in the active-Downstream direction: A
failure in the active–Downstream bus is detected in first
instance by the Line Cards.
" A failure affecting to the standby-Downstream direction:
Same mechanism as in the active NLC bus.
" A failure affecting to the active-Upstream direction: A
failure in the active–Upstream bus is detected by the NB
controller in case of losing the communication with all the
LIMs.

NLC A downstream
NLC A upstream
NLC B downstream
NLC B upstream

NB controller NB controller NB–LIMx NB–LIMy

Figure 16 Redundancy of the NLC bus

48 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(8) Faults Provoking NB controller+NSEC-Cs Active Chain

Switch-Over
The NB controller/NSEC–C critical and major persistent alarms,
will provoke the switch–over of the active chain to the standby
chain (When the NB controller and NSEC–Cs in the standby
chain are in operational state enabled). If the standby chain is
with failures, no switchover is possible (See Figure 17).

NB controller A NB controller B

NLC A

LIMs LIMs
NLC B

NLC A
NSEC-C A NSEC-C B
LIMs LIMs
NLC B

NLC A
NSEC-C A NSEC-C B
LIMs LIMs
NLC B

NLC A
NSEC-C A NSEC-C B
LIMs LIMs
NLC B

DATA Path
peer link

Figure 17 Active / Standby Data Flows in NB Chains A and B

3EC 41919 0001 TQZZA Edition 01 49 / 185

 SYSTEM DESCRIPTION

(9) GE controller redundancy

In a configuration with two redundant GEB3s, each of these
boards will keep its own MAC address.
When the switchover happens, the new master board will send a
gratiutous ARP to let the network know the new association of
addresses: IP–MAC. This mechanism produces the side effect of
longer recovery times. The different services must be tested in such
circumstances to guarantee that their degradation is still
acceptable.
Following cases are possible:
" GEB3+GEB3: In a subrack, there are two GEB3 boards, one
is master and the other one is slave.
We can control which one (slot 1 or slot 3) is master in two
ways:
D The software can control which one is master by the
register.
D When slot 1 and slot 3 power is on at the same time, the
slot 1 is master, otherwise the first one to be powered on
is master.
The two GEB3 boards are in redundant configuration: when
the master becomes wrong, the slave one will act as master.
And the two GEB3 boards communicate each other by the
HIPC.
The EFL3 will communicate with the master; it can judge
which one is master by the signal AB_POS.
The GEB3 polls all the Line Cards; when the GEB3 finds a
BBLC (EFL3 is considered as BB Line Card), the GEB3 will
communicate with the BBLC by the HCL bus (GE interface). If
the communnication is ok, the GEB3 will consider the BBLC is
EFL3. If the communication is not ok, the GEB3 will consider
the BBLC is not EFL3.
Note A wrong EFL3 may cause the misunderstanding of
GEB3 if the communication on HCL does not success.
This behaviour is accepted in order to keep board
detection simple and as much as possible backward
compatible.
The HMW (power on/off reset) of GEB3 occupies the
HCL bus.

50 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

1.6 Product Configurations and Packaging

1.6.1 MLS Subrack
" The MLS backplane consists of a set of connectors (For Line
Cards, Special Functions, Servers and Controllers), a
well–defined set of connections among them and a set of
external interfaces. This definition can then be implemented in
several physically different backplanes to fit the requirements
of different application environments.
" The backplane can be specialized due to different width and
different service features. The aims of this specialization are
mainly the optimization of the service offered and the
component cost.
" Several Line Card positions may accept special function
boards, depending on the MLS application.
" The right side of the backplane features terminations for the
NLC bus. The termination board has a serial EEPROM to store
backplane related information introduced both by factory
(e.g., the shelf type) and by the customer (e.g., the shelf name
in the plant) and also internal SW information that can be
used in system restarts.
" All shelves are fully EMC shielded. This implies that all boards
have front covers with EMC shields and that empty positions
have dummy covers.
" All MLS cabling is done through a Front Access Area. For this
purpose, the MLS is extended at the bottom with a connection
area where the connections (EMC shielded) are performed.
Electrical cabling (Inter–MLS, line cabling) is done via the
connection area. Optical cabling is done on the front panel of
the board itself.

1.6.2 MLS Subrack Configurations

MLS–3F and MLS–3F4 are described in Chapter 3.

1.6.3 Outdoor Configurations

The Outdoor Cabinet contains the following items:
" MLS (1 or 2).
" Power Converter (From mains to –48V).
" Batteries for Emergency Feeding.

3EC 41919 0001 TQZZA Edition 01 51 / 185

 SYSTEM DESCRIPTION

" The traditional ’double’ MDF: The connector area of the MLSs
is connected via cabling to a ’primary’ MDF, while the external
cabling is connected to a secondary MDF. The subscriber
connection is then made by connecting the primary and the
secondary MDF.
" Forced cooling with heat exchange: The Cabinet is inside,
sealed from outside.
Other cabinet items:
" The cabinet has no EMC shielding: This property is achieved
at MLS level.
" The basic material of the cabinet is aluminium.
" Separate access is provided to the MLS area, Mains access
and MDF area.
Table 2 shows the products configurations for Outdoor Cabinet

Table 2 Product Configurations (Outdoor Cabinet)

Products Hardware Items NB GE NOTES
Cabinet for 1 MLS X X
Cabinet for 2 MLS X X

1.6.4 Indoor Configurations

The generic indoor housing can contain up to 4 MLS, the top rack
unit (TRU), and fans.
The maximum NB MLSA (MLS assembly for Narrowband
configurations) consists of 4 MLSs (1 Main and 3 Extenders). In GE
configurations, the MLSA can be extended up to 12 MLSs (1 Main
and 11 Extenders). In mixed NB/GE configurations, the MLSA
consists then of up to 4 MLSs (1 Main and 3 Extenders) dedicated
to pure NB or mixed NB/GE services, and additional Extender
MLSs dedicated to pure GE services up to a maximum of 11
Extenders in the MLSA.
Table 3 shows the Product Configuration with Indoor Rack for 4
MLSs.

Table 3 Product Configurations (Indoor Rack for 4 MLSs)

Products Hardware Items NB GE NOTES

Indoor ETSI rack X X

52 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

1.6.5 Board Configurations

Table 4 summarizes the possible board configurations of
Litespan–1540 product configurations.
It explains which transport cards, controllers and line cards are
supported in the different product configurations.

Table 4 Product Configurations (Boards)

Products Hardware Items PDH SDH GE NOTES

NEHC–C (NB controller) x
NBCB (NB controller+ VoIP server) x x
NSEC–C (NB shelf extension) x For MLS–3F or MLS–3F4 when used as
extensions of NB services

VIS3 (VoIP server) x x

LINA (SDH NT) x
PRC3 (4x2Mbit/s, G.703 NT) x G.703 Transport from LE

PRC3 (4x2Mbit/s, G.703 LT) x LL, V3 PRA & G.703 Transport to RU

SLT3 (SHDSL NT/LT) x SHDSL Transport

ATLC–F x Variants:
ATL3–G ATLC–F : 48 subscriber, long haul, 48V
open loop, integrated ringing and line
testing
ATL3–G : 48 subscriber, long haul, 48V
open loop, integrated ringing and line
testing. Vinetic 4S version with limited test

BAL3 x Variants :
BAL3–G : 16, 2B1Q, Voltage feed, inte-
grated line testing (from FR3.1)
BAL3–H: 16, 4B3T, Voltage feed, inte-
grated line testing (from FR3.1)

GEB3–A (GE Controller) x This controller can be connected to a ATM

network via STM–1

GEB3–B (GE Controller) x This controller has not the STM–1. GE

connections both optical and electrical
through front panel

3EC 41919 0001 TQZZA Edition 01 53 / 185

 SYSTEM DESCRIPTION

Products Hardware Items PDH SDH GE NOTES

EFL3 x x Only supported by GE controller, which
means that this LIM only can be equipped
in the same MLS of its controller
Variants :
EFL3–A = for POTS with splitter
EFL3–B = for POTS without splitter
EFL3–I = for ISDN–BA with splitter
EFL3–H = for ISDN–BA without splitter

ANIT–A (Ethernet to ATM IWF) x STM–1, or 2xE3 or 8xE1 ATM interfaces,

both IMA or not IMA.
There is a cost reduction variant ANIT–
AE1 only equipped with the 8xE1 inter-
faces

NTIO x
PEIC (Power and E1 interface card) x x
POW3 (Power and FE/GE interface card) x x Compatible with GIO3 card

LIOC (Local Input/output card) x x

GIO3 (Giga–Ethernet Local Input/output x x
card)

54 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3EC 41919 0001 TQZZA Edition 01 55 / 185

 SYSTEM DESCRIPTION

2 SYSTEM ARCHITECTURE

2.1 Transport Architecture

Each LINA card provides the following external (front–plate)
interfaces:
" Aggregate Interfaces
D Two SFP E/O modules providing STM–16 or STM–4 or
STM–1
" Tributary Interfaces
D Two 10/100/1000BT electrical Ethernet interfaces (2x GE)
(generic purpose tributaries to be used instead of
backplane tributaries)
D One SFP E/O module providing STM–1
The following internal (backplane) interfaces are supported in the
card:
" Tributary Interfaces
D Four GE Serdes electrical interfaces – 2x (2 GE tributaries
from each GE controller)
D 16 E1 ports for local TDM traffic – 16x (2Mbps)

2.1.1 1.1 Modes of Operation

LINA card can be used in the following modes.

1.1.1 ADM
The card can be deployed as a pure ADM, with traffic to / from
the NB and GE controllers forming the local tributaries. In this

56 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

mode, the Gateway could be NG–ADM itself or a 3rd party

Gateway.

Figure 18 ADM Mode

1.1.2 Gateway to the EMAN

The card can be used in the Gateway mode, where in it connects
to the EMAN through the Front Plate Ethernet interfaces and to the
TDM network via an STM–1 interface. In this mode, no backplane
Ethernet tributaries are expected, although it is possible to have
the E1 tributaries from the narrowband controller in the system.

Figure 19 EMAN Gateway Mode (I)

3EC 41919 0001 TQZZA Edition 01 57 / 185

 SYSTEM DESCRIPTION

Figure 20 EMAN Gateway Mode (II)

1.1.3 Gateway - Ring interconnect

In the ring interconnect Gateway mode, the LINA card
interconnects an STM–4/1 lower ring to an STM–16/4 upper
ring. It supports single node interconnect or dual node
interconnect modes, which are differentiated by the number of
nodes used to interconnect the two rings.

Figure 21 Gateway Ring Interconnect Mode

The following figure shows the required dual node ring

interconnect mode.

58 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Figure 22 Dual Node ring interconnect

3EC 41919 0001 TQZZA Edition 01 59 / 185

 SYSTEM DESCRIPTION

2.2 Control Architecture

2.2.1 Control Communication Links inside the MLS

The main protocol between the Central controller and the LIM
cards is the VA. It is based on the protocols used in V5.
VA refers to the protocol stack which is Litespan–1540 specific
and is used as much as possible.
The other protocol stack are:
" VA* protocol stack for the communication between the NB
controller and the OBC–less NB–LIMs
" VAIP is the internal control protocol used in VoIP for the
communication between VoIP server and NB controller
The lower layers will be:
" STM based, i.e., a number of concatenated timeslots on NLC
bus.
Data link layer can be divided into a number of sublayers:
" The ‘frame sublayer’ is in charge of frame delineation (e.g.,
flag handling in case of bit oriented communication) and CRC
calculation/check. It is a HDLC 2.1 sublayer (Bit oriented and
STM based)
" The LAPVA–EF sublayer is responsible for the address
recognition and insertion (Four bytes)
" Layer LAPVA–DL is in charge of frame retransmission in case
of a transmission error and offers a connection–oriented,
reliable, end–to–end connection
The VA contains, as well, a data broadcasting protocol,
connection less using unacknowledged messages to download SW
files to Litespan–1540 boards from the Central controller.
A VA CC (Communication Channel) is composed of 1 to 32
timeslots on the NLC bus. The following channels can be present
for VA communication:

60 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" VA1CC: The first communication medium between the NB

controller and the NB–LIMs with OBC. It carries the
communication related to the BCC, OAM, PSTN signalling
and control. Each VA1CC has a bandwidth of 64 Kbit/s.
According to whether contention is managed for the MLS
Assembly as a whole, one VA1CC can be present for the
complete MLS Assembly (This is not the case in current
implementation). Alternatively, different VA1CC channels can
be set for each shelf composing the MLSA. The contention in
this case is performed among the boards plugged into the
single shelf
" VA2CC: The DS and the p/f–type traffic flow is assigned to a
VA2CC communication channel. If the contention is managed
on a MLS basis, LIMs that share the same VA2CC must be
located in the same MLS
Current implementation does not support flexible dimensioning
based on the penetration of the ISDN p/d/f traffic, being assigned
one ISDN board to one VA2CC.
" VADL: The VADLs are transparent unidirectional bearer
channels (N x 64 Kbit/s, n = 1 to 32) dedicated to software
downloading into the NB–LIMs. Since this communication
channel is not used from the LIMs to the NB controller,
contention cannot occur. Only one VADL channel with a
bandwidth of 2,048 Kbit/s is used. (Note: LIMs using the LCIA
as NLC interface are, however, limited to about 500 Kbit/s)
In comparison with the VA protocol used to communicate
NB–LIMs with OBC, the VA* protocol used to communicate with
OBC–less NB–LIMs differs in the following respects:
" Separate communication channels (i.e., VA*CC). The
following channels can be present for VA* communication:
D VA*CC: The first communication medium between the
NB controller and the NB–LIMs without OBC. Each
VA*CC has a bandwidth of 64 Kbit/s. In principle, it
carries all communication. If necessary, however,
additional VA* channels may be used. According to
whether contention is managed for the MLS Assembly as
a whole, one VA* CC is present for the complete MLS
Assembly. Alternatively, as for the VA1CC, different
VA*CC channels can be set for each shelf composing the
MLS assembly, thus reducing the contention among the
boards plugged into the shelf

3EC 41919 0001 TQZZA Edition 01 61 / 185

SYSTEM DESCRIPTION

D Additional VA* channels: When the VA* traffic is too

high to stay on the VA*CC, it may be assigned to
additional VA* communication channels. Each additional
VA* channel has a bandwidth of 128 Kbit/s, and up to
four additional VA* channels may be assigned per MLS. If
the contention is managed on a MLS basis, the
OBC–less LIMs that share the same additional VA*CC
must be located in the same MLS
" Address field of only 2 bytes (LAPVA–EF*), instead of an
address field of 4 bytes (LAPVA–EF). Bit 0 indicates the least
significant bit of a number. Notice that the (MLS ID, Slot ID)
combination can be replaced in the downstream direction by
a multicast address
" The upper data link layer uses a simplified protocol that only
uses UI frames (LAPVA–DL* instead of LAPVA–DL)
" Above the data link layer, the VA* protocol is used. This
protocol uses CIEs (Command Indication Elements) that can
be processed/generated by a hardware command sequenced
on the LIM
There are other physical links inside the MLS:
" One synchronous link at 2 Mbit/s between redundant peer
boards (VoIP server, NB controllers) active and stand–by, in
order to keep aligned all redundant data
" In NB controller a full duplex 100 Mb Ethernet interface in
the communication with peer NB controller for redundancy is
supported. This interface uses the same four wires used for
the 2 Mbit link in previous NB controller
Additionally, some embedded control links exist inside MLS:
" External access to VA links embedded into the 51.84 Mbit/s
electrical link with the extension MLSs
" VA and VA* links embedded into NLC bus
For VoIP, there is a third protocol: VAIP. It is an internal control
protocol introduced in Litespan–1540 for VoIP provessing. Its goal
is the transport of signalling information between VoIP server and
NB controller.
The main characteristics of VAIP are:
" Only three VAIP protocols are defined: VAIP–PSTN ,
VAIP–portcontrol and VAIP–BCC
" VAIP–PSTN , VAIP–portcontrol and VAIP–BCC share the
VA1CC channel with the rest of VA protocols (VA OAM,
VA–portControl, VA PSTN, VA BCC)

62 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" In order to share the VA1CC channel 3 new values for the VA
L3 function field are defined:
D VAIP PSTN
D VAIP UserPortControl
D VAIP BCC.
" The UserPortidentification field for VAIP messages will contain
the L3 address of V5/Megaco (15 bits) as in V5. This is
different from the rest of VA protocols where the local
identification inside of the line card is provided
" Sequence number field has a fixed value (zero)
" The original V5 message Types and InformationElements are
kept in VAIP
For ISDN over Ip, there is reserved 64 kbps channel between NB
controller and VoIP server which contains all D–channels
signalling of the ports controlled by a VoIP server. In this
communicatin channel, NB controller uses LAPV5–EF
encapsulation as in ISDN in V.5.
VA is used for the transmission of D–channel signalling between
ISDN LIM’s (BAL3 cards) and NB controller. BAL3 cards multiplex
all D–channels corresponding to their 16 ISDN ports in a VA2CC
channel.
NB controller transmits D–channel information to VoIP server by a
64 kbps channel (one per VoIP server) using LAPV5–EF
encapsulation. The NLC bus slot allocated for this channel is fixed
by the slot in which the VoIP server is inserted.
Not all ports of a BAL3 are necessarily controlled by the same VoIP
server. For this reason, NB controller is able to deliver to different
VoIP server, different D–channels received by one VA2CC.

2.2.2 Control Communication Links inside the

Litespan-1540

3EC 41919 0001 TQZZA Edition 01 63 / 185

 SYSTEM DESCRIPTION

(1) Communication between EU and the remote units (RUs) within

the access network
The following case has to be considered:
Messages coming from OS are relayed by NB controller–EU on
one NLC–EU Time–Slot (One NLC–EU Time–Slot per each RU),
overhead part of electrical link between SLT3–EU and SLT3–RU ;
and one NLC–RU Time–Slot. No protocol translation is
performed in this case by NB controller–EU. OSI protocol has to
be terminated in the NB controller–RU controller.

NLC NLC
TT card TT card
EU RU
Electrical
TMN Access Link Litespan 1540

Ethernet

Figure 23 TMN Access Message Relaying between EU and RU

(2) Communication between NB controller and MLS Cards

In order to transport a VA or VA* connection between the NB
controller and the NB–LIM, one or more DS0 embedded in the
NLC bus and related extension connections to subtending MLSs
are used. Also one DS0 channel in the NLC bus is used in VAIP for
the communication between NB controller and the VoIP server.

(3) Communication between 1+1 Redundant Peers (Controllers)

Peer NB controller boards communicate with each other via a full
duplex 100 Mb Ethernet interface:
" To carry the context updating information in the Standby board to
be able to perform a take– over as fast as traffic requires
" To carry an OAM link between active and Standby
Peer SLT3 cards communicate with each other via one 64 kbps
HDLC point–to–point link.
Peer VoIP servers communicate with each other via one 2 Mbps
HDLC point–to–point link.

2.2.3 Communication between GEB3 and LIM cards in GE

The internal communication between NT function at GEB3 and its
GE–LIMs is Ethernet based (see Figure 24) .

64 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

An internal VLAN is reserved for internal communication. This

VLAN (Internal communication VLAN or Internal OAM VLAN) is
fixed–coded in the system, being VLAN 4094.
The internal OAM VLAN is not exclusive for internal
communication and may also be used by control protocols (e.g.
VBAS, ...).
Data forwarding for EFL3 (Data Plane): LANx, EFL3 will take the
main responsibility for the data forwarding, NT also take the
management responsibility for it.
Three data forwarding mode will be supported:
" Residential bridging mode
" VLAN cross–connect mode
" IP forwarding mode

GEB3
GE EFL3

GE/FE LT IWF Transport ADSL

LANx

GE VLC
FE STM–1
(ATM–Eth
IWF)
NT (not in GEB3–B)

Figure 24 Litespan 1540 GE General Architecture

2.2.4 Communication between DLC and CPNT

Communicating to an CPNT depends strongly on the CPNT used.
For instance, communicating to the ISDN CPNT for basic access is
standardized.
LAPD used includes a minimum set of messages to avoid
complexity at NT level. For instance, the window size is 1, the
Reject is not supported, etc. When applicable, unnumbered
frames are preferred.

3EC 41919 0001 TQZZA Edition 01 65 / 185

 SYSTEM DESCRIPTION

2.3 CPNT Equipment

This section describes the following CPNT equipment:
" POTS: Analog Telephone Set.
" ISDN NT: ISDN Network Termination (NT1).
" DCE–3: Primary rate Channel Terminal (DCE–3).
" SHDSL CPNT: LL SHDSL Network Termination
" ADSL NT: ADSL Network Terminal.

2.3.1 POTS
Analog Telephone Set: Analog termination for ATLC–F/A TL3
boards at a maximum span of 3.5 Km (0.4 mm diameter).
Line Interface: Analog 2–wire, twisted pair, according to ETS 300
001.
Customer Interface: Analog 2–wire, 8 pin ISO 8877 connector.
Customer speed: 300–3400 Hz voice band, 12/16 kHz metering
frequency.
Note Customer and Line interfaces differ when a SALT device
is installed in the customer premises. When no SALT is
equipped, customer and line interfaces are identical.

2.3.2 ISDN NT
NT1 Network Termination for ISDN boards at a maximum span of
3.5 km (0.4 mm diameter).
Line Interface: U–interface 2–wire, twisted pair, ITU–T Rec.
G.961, data scrambled, remote power supply.
" 2B1Q code, 80 KBaud line speed, 135 ohm, for BALC–B
and BALC–D cards.
" 4B3T code, 120 KBaud line speed, 135 ohm, for BALC–C
cards.
Customer Interface:
" S–interface 4–wire, ITU–T Rec. I.430, AMI 192 Kbit/s, 8 pin
ISO 8877 connector.
Power supply:
" 5W from AC mains (220 V) or separate AC mains adaptor.

66 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" From line interface: Normal (Active 500 mW, Standby 120
mW), Emergency (Active 1.1 W, Standby 180 mW).
Customer speed: 2B+D (2x64+16 Kbit/s).
Diagnosis: Power–on self test, loop 2b (From the line), loop 3c
(From DTE).

2.3.3 SHDSL CPNT

NT Network Termination for SLT3 boards.
The SLT3 card supports one pair for each SHDSL interface.
Line transmission rate is adaptative (192 kbit/s to 2312 kbit/s in
increments of 8 kbit/s) depending on the payload when 1 pair
interfacing. The length is dependability of the speed according to
the standard G991.2.
TC_PAM line code and the echo cancellation methods are used to
ensure high transmission quality.
Adaptive filters shall be foreseen to adjust the system to the
transmission lines automatically.
Supported services:
" 2 Mbit/s structured G.704(75/120 Ohms)
" Nx64 kbit/s
" ISDN PRA –T(75/120 Ohms)
" Unstructured
The different subscriber interface covered are:
" G.703(75/120 Ohms): Connector coaxial female (1.6/5.6) /
RJ45.
Customer speed: 2 Mbit/s
Power Supply:
" External Power (AC mains (220 V)).
" Draw wetting current from the remote feeding circuit when it
is being powered locally.
Diagnosis:
" Power–on self test.
" Loop 2b (from the line)
" Loop 2b called on the remote DCE (manual or from DTE)
" Loop 3c (manual or from DTE)

3EC 41919 0001 TQZZA Edition 01 67 / 185

 SYSTEM DESCRIPTION

" Customer interface status

" DCE actual configuration
" Alarm status
" Bit error rate on CRC4.
" OAM functions through LCD display, keyboard, optical
indicators, functional menus.
Configuration:
" Customer interface type
" Remote
" TS Mapping
Features:
" SW downloading from SLT3. Service availability must not be
degraded during this operation.
" Remote Inventory from SLT3.
" Management from SLT3 though EOC channel of SHDSL
frame.
Environment:
" Temperature range from 0ºC to 45ºC.
" EMC compliance according to EN50081–1 (1992) for
emission and EN50082–1 for immunity.

2.3.4 ADSL NT
Line Interface: Asymmetric Digital Subscriber Line (ADSL)
0.5–6 Mbit/s.
Typical Customer Interfaces:
" 25.6 Mbit/s ATM Forum.
" 10BaseT Ethernet.
Customer speed: Up to 6 Mbit/s aggregate ATM bandwidth.
Other services:
" ATM–Ethernet bridging.
Different ADSL–NT variants are included:
" ADSL POTS NT.
" ADSL ISDN (4B3T/2B1Q) NT, including CPE Splitter
Switchable POTS/ISDN4B3T Passive Version.
" ADSL PC–NIC.

68 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.4 Access Signalling

2.4.1 Narrowband with V5 Signalling on the V Interface

In case Litespan–1540 is connected to a LE through a V5
interface, the access and mapping functions in the NB controller
are responsible for relaying the frames to the NB–LIMs. This
functions is performed in the hardware part.
For ISDN BA users, the ISDN BA D–channel data (Signalling and
P/F data) is relayed transparently by Litespan–1540 between the
LE and the customer equipment.

2.4.2 V5 Hubbing
A schema of the V5 hubbing function is shown in the Figure 25.

Terminal
Switched
LE V5.2 Litespan-1540 V5.2 Litespan-1540
Network V5EU V5RU

Transport Transport

Figure 25 V5 Hubbing in Litespan–1540

Each V5 protocol has a specific way of being handled in V5

hubbing:
" Link control, Protection control and Common control protocols
have a strictly local scope in each V5.2 interface
" PSTN, BCC and Port control of remote subscribers have global
scope. The V5EU performs a kind of special frame relay with
more or less additional functions depending on each protocol.
PSTN is quite simple, BCC and port control are more complex
" For ISDN the V5EU performs a pure layer 2 frame relay
function

3EC 41919 0001 TQZZA Edition 01 69 / 185

 SYSTEM DESCRIPTION

2.4.3 VoIP Signalling

(1) POTS
The mechanism to transport subscriber signaling from a POTS LIM
to the Call Server in the IP network is shown in Figure 26.

Call NB NB
IP VoIP server
Server Controller LIM
Network

Megaco/UDP/IP Megaco/UDP/IP VAIP VA* Line

events
Ethernet NLC bus NLC bus
Z interface

1) Ethernet / 803.2 transport

Call ANIT–A NB NB
IP VoIP server Controller LIM
Server
Network

Megaco/UDP/IP Megaco or SIP/UDP/IP VAIP VA* Line events

ATM/STM1 Ethernet NLC bus NLC bus Z interface

Figure 26 Voice over IP: signalling path

VoIP server is able to use 802.1Q tags to carry Megaco

communications.

70 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(2) ISDN over IP (D-channel)

In ISDN over IP, D–channel signalling (Q.931) is transmitted
between the CPE and the Call Server without interpretation or
modification by Litespan. Layer two D–channel protocol (Q.921),
on the other hand is terminated in VoIP server.
Regarding the internal transport, BAL3 cards (ISDN LIM), after
removing flags and stuffing bits, encapsulate Q.921 frames into
LAPVA–EF frames. All D–channels of an ISDN–LIM are
multiplexed in a V2CC channel in their way to the NB controller.
There, D–channel signalling is delivered to the corresponding
VoIP server replacing LAPVA–EF by LAPVA–EF (just like in V5
ISDN). For this, a single 64 kbps channel is used between NB
controller and VoIP server. VoIP server terminates layer 2
connection, extracting Q.931 information which is delivered to the
Call Server using SIGTRAN protocols (IUA/SCTP).

2.4.4 IP Hubbing
(1) VoIP Hub architecture
Litespan 1540 V5 Hubbing in NGN (IP Hubbing function), has to
concentrate several V5.2 standard interfaces coming from remote
Access Nodes (RUs), into a VoIP MEGACO interface. In this way
this feature allows to migrate already installed V5.2 Access Nodes
to NGN (VoIP) technologies, without impacts in these nodes (see
RUs in Figure 27)
The following assumptions have been taken in the development of
this feature:
" Pure V5 Hubbing and V5 Hubbing in NGN (IP Hubbing) are
compatible in the same EU, and in the different RUs. But in
the same RU, IP Hubbing will require a different V5 interface,
than the interface required for pure V5 Hubbing with the EU
" The service to subscribers in RUs can be performed from a V5
LE or from an IP Network, but one subscriber only can be
declared in one of these services (it is served from VoIP
Network, or from a V5 LE)
" All the RUs work with the same PSTN V5 National protocol.
The RUs can be from different manufacturers but they should
have the same V5 PSTN National protocol
" The included services are POTS and ISDN–BA (although p&f
ISDN–BA signalling is not supported)

3EC 41919 0001 TQZZA Edition 01 71 / 185

 SYSTEM DESCRIPTION

" Hot Switch Over feature is not required for the moment,
although it can be added in the future to this feature.
Furthermore the use of this feature, for the moment, provokes
that NB controller and VoIP server HSO are not available for
any service
" There are two constraints to the maximum capabilities of the
system. These are: the maximum number of RUs is 16, and
the maximum number of V5.2 declared interfaces is 16
" There is also a restriction in the EU–RU V5 interface, because
Protection Group 2 is not used in this interface

Figure 27 VoIP System Architecture

EU Role Exchange Units (EU) are Access Node systems able to terminate
the transmission links coming from Remote Access Nodes (RUs),
and perform the interconnection functionality to the V5 LE or to
the NGN for traffic. It also provides management and
synchronization interfaces to RUs. In this case the interconnection
will include the Hubbing functionality of standard V5.2 interfaces
into the NGN, providing VoIP services to the subscribers of the
RUs.

72 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

The EU can also optionally behave as EU for the Q3. But clearly
EU–RU pairs for VoIP Hubbing and EU–RU pairs for Q3 routing
should be distinguished. A VoIP Hubbing RU node can be a
stand–alone node from the Q3 point of view; and a VoIP
Hubbing EU node can act only as Hub node for VoIP services, and
not for Q3 or V5.
In order to support the routing of Q3 towards a RU via embedded
TS a special behaviour has been developed.

RU role Remote Units (RUs) are Access Node systems installed in remote
locations and connected to V5 LEs or to a NGN by means of an
EU. RUs are linked to EU by dedicated transport, either PDH or
SDH (in the case of NB controller equipped in RUs, only PDH
tarnasport is possible).

Communication EU EU – RU communication can be performed via dedicated

<->RU transport either PDH or SDH, both optical or electrical (in the case
of NB controller equipped in RUs, only PDH tarnasport is
possible). Over the transport there are declared standard V5.2
interfaces.

VoIP Hubbing Both EU and RU are managed by Litespan CT and OS (1353 DN)
Management when they are Alcatel–Lucent. Litespan OS (1355 DN) provides
an additional service management level by handling the creation
of both physical and virtual PSTN and ISDN–BA user ports.
When RU is non Litespan only the EU is managed by both
Litespan CT and OS (1353 DN) taking into account that the
management of EU must be consistent with that of RU. Litespan
OS (1355 DN) just handles the virtual PSTN user ports in the EU
then.
In order to support the routing of Q3 towards a RU via embebed
TS a special behaviour has been developed.

(2) Protocols

Media Flows Figure show the voice and ISDN–BA flows from ports in RU’s and
from ports of the EU.

3EC 41919 0001 TQZZA Edition 01 73 / 185

 SYSTEM DESCRIPTION

Litespan (EU)
V5 AN
TA Server
NLC bus
TDM Transp.
RU card NEHC VISC VoIP IP network
Ethernet or ATM

POTS and ISND–BA

terminals ATLC

POTS terminals (analogue

phones, modems, G3 faxes, ...)
BALC
POTS terminals are
connected via terminal
adapters (TA)
TA

ISDN–BA terminals

Figure 28 Media Path

Voice
There is no change in the voice (either due to POTS lines or to
analogue devices connected to a digital line by means of a TA)
protocol stacks for ports connected to EU.
Voice is transported from the RU to EU’s transport card in a TDM
channel. The transport card switches this channel to a time–slot in
the NLC bus which is cross–connected by NB controller to a
time–slot in the server bus so voice info gets to VoIP server. There,
the voice signal is processed and may be transcoded, and is
packetized and encapsulated in RTP packets transported on
UDP/IP datagrams over Ethernet.
Regarding ISDN–BA, POTS traffic (connected to NT through a
terminal adaptor [TA]) is transmitted in B–channels. The
corresponding stack is similar to the one for voice in POTS cards.

Signalling V5 and Megaco

EU translates V5 signalling to Megaco, the VoIP control protocol
used in Litespan. Internally, the relevant protocols used in Litespan
for VoIP hubbing are:

74 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" VA–IP : it’s a pseudo–V5 protocol used between NB controller

and VoIP server
" VA*: used between NB controller and cards without host
processor
" V5.2: coming from RU and switched by TT’s to NB controller

V5 AN
(NLC) (NLC) IP
NB controller VoIP server
RU TT Network
V5 V5 VAIP

LIM VA*

MGC

Figure 29 Signalling Path

RU is a V5.2 access node that is controlled by the NB controller

that takes the role of Local Exchange. In–between theses cards,
there may be a transport card (in the case RU is connected to such
a card) is not involved in signalling and simply relays the V5.2
messages exchanged between the RU and the EU. NB controller
terminates V5.2 protocol, behaving as a Local Exchange. NB
controller, when needed, translates V5.2 into VAIP messages that
are delivered to VoIP server. This card terminates this protocol and
translates VAIP into Megaco which is the signalling protocol used
in its communication with the MGC.
There is no change in the signalling protocol stack for local ports
in EU with respect to the description in VoIP DS.
From the point of view of RU, the signalling interface is standard
V5.2 and it’s CDE dependent to comply with the country’s V5.2
specifications. The NB controller in EU exchanges V5.2 messages
with RU and VA–IP with VoIP server. Since VA–IP is the same for
all countries, NB controller does a translation to V5.2 that is
adapted to the country profile in order to keep country’s standard
V5.2.
SIGTRAN

3EC 41919 0001 TQZZA Edition 01 75 / 185

 SYSTEM DESCRIPTION

In VoIP hubbing, the NB controller in the exchange unit behaves

like a local exchange, in its communication with the remote units
for the Layer 1 activation and L2 data link procedure, while the
Q.931 signalling is terminated in the Call Server.
In principle, there is no impact on VoIP server as its interface with
NB controller is not changed. D–channel signalling (Q.931) is
transported transparently over SIGTRAN (for this kind of signalling
SIGTRAN consists on IUA [10] and SCTP (Stream Transmission
Protocols [RFC 2960]) between VoIP server and the ASP
(Application Server Process) in the MGC.
There is no change for ports connected to EU.

OAM Flow In case of an Alcatel–Lucent RU, signalling may be embedded in

a V5 time–slot or through a leased line.
If RU is a non–Alcatel one, these options are also possible,
although the OS would be non–Alcatel, and depending on the
RU architecture, RU could be connected to its controlling OS
through a dedicated interface, so OAM would not pass through
EU.
Note that the EU–RU role for Hubbing is independent of the
EU–RU role for Q3. This is the case for non–Litespan RUs, and
for other configurations, for example, all EU and RU nodes in a
SDH ring. A RU node can be a stand–alone node from the Q3
point of view; and a EU node can act only as hub node for VoIP
services, and not for Q3 or V5.

2.4.5 Gigabit Ethernet Aggregation

GEB3 board can be used as a Gigabit Ethernet aggregator. GEB3
provides 6 GE links to be used for different purposes, according to
the needs. Thus, these 6 links may be used as network,
subtending, user or aggregation links. In particular these links can
be used to aggregate VoIP traffic, thus providing this traffic to the
network in a GE link. In the same way, NB OAM traffic can also
be aggregated by using these ports, which also allows to present
this traffic to the network through a GE link.

76 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.4.6 GEB3 and EFL3 Subsystem

The system provides a multiplexer function making use of a NT
board (GEB3) optionally 1+1 redundant, and LT cards (EFL3)
connected through the HCLs working at 1GE.
The NT is build from a LANX subsystem and a control subsystem.
The LANX subsystem is an Ethernet switch based on a 3rd party
Ethernet switching SW platform running on a highly integrated GE
switch ASIC. The LANX subsystem also includes a dedicated
controller taking care of control and management plane of the
LANX component. The LANX also implements the network
interfaces.
The control subsystem is based on a powerful general purpose
processor. The control system implements the management plane
of the system and part of the control plane, the part related to
subscriber management which is typically not found in an Ethernet
switch product.
EFL3 line cards are build from an interworking function and a
transport subsystem.
There are two variants of EFL3 line cards: with and without
splitters.

2.4.7 GE interworking function to ATM network with

ANIT-A
The scope of ANIT–A IWF is to convert Ethernet to ATM, either
IMA or not, and in future releases the inverse function could be
performed (ATM nodes connected to Ethernet networks).

3EC 41919 0001 TQZZA Edition 01 77 / 185

 SYSTEM DESCRIPTION

GE NE
STM1
E3
E1

ANIT–A
CP
SERDES EFL3x ADSL
ADSLtraffic NT

GEB3 CP
Redundancy EFL3x ADSL
ADSLtraffic
NT

EFL3x
ADSLtraffic
GEB3
To subscribers
FE / GE
HCL links Opt. / elect.
FE / GE

To GE RUs
Opt. / elect.
FE / GE

Figure 30 Litespan 1540 GE with IWF to ATM networks

ANIT–A is internally connected to GEB3. The card provides the

following interfaces:
" (2) GE and (2) FE electrical
" STM–1 optical fibre interface using SPF module
" (8) E1 and (2) E3
With the last related interfaces, it is possible the redundancy based
on link protection of the GE controllers. Any one pair of GE
interface is allowed as interface source. One link will be active
and other will be standby based on a Selection signal. The data
from the active GE link will be translated to/from one of the ATM
possible interfaces (STM–1 or E3 or E1). The selected ATM
interface is selected by micro–switches in the board, although
there is a cost reduction variant of the board (ANIT–AE1) only
equipped with the 8 E1 interfaces.
The four FE interfaces and the active GE interface are attached to
the IWF, along with the ATM interfaces. This facilitates routing of
traffic coming from any of the Ethernet interfaces to the ATM
interfaces.
The management of ANIT–A card is performed by a SNMP agent
using several MIBs.

78 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.4.8 Litespan SIP Gateway

Litespan SIP Gateway will use as basis the VoIP Server Card.
Litespan SIP Gateway follows the general VoIP architecture of
Litespan.
Figure 31 illustrates the system architecture for Litespan SIP
Gateway. Signalling and voice paths within Litespan SIP Gateway
are shown; the protocols stacks for both communication paths are
described afterwards.

LITESPAN–1540
NLC BUS
NB controller LIM

LIM
SERVER BUS
P–CSCF VoIP server
COMCERTO

IP TSP 3 HOST

EDGE ROUTER

SIGNALLING PATH
VOICE PATH

Figure 31 Litespan SIP Gateway System architecture

Litespan SIP Gateway will make use of a commercial SIP stack. In

the first Litespan SIP Gateway application we will use the SIP User
Agent Toolkit from Flextronics Software Systems.
Litespan SIP Gateway supports UDP transport.
Due to the memory limitations in VoIP server, it is assumed that we
will have two SW packages for VoIP server, one to act as a
Megaco GW, and one to act as a SIP GW.
It is assumed that Litespan can work either as Megaco GW or as
SIP GW, but not both at the same time.

3EC 41919 0001 TQZZA Edition 01 79 / 185

 SYSTEM DESCRIPTION

IP version 6 is not required. NAPT is not required.

P–CSCF IP address is manually configured.
At least three registration options are available: No registration,
Implicit registration and Explicit registration.
The VoIP server Litespan SIP Gateway GW architecture is reflected
in Figure 32.

VA–O AM VA–IP
SIP GW
SERVICE
CONTROL
FSM
SIP FSS
GCSL SIP USER AGENT
APPLICATION TOOLKIT

CALL
FSM

MTDR MTDR

Figure 32 Litespan SIP Gateway VoIP server SW Architecture

(1) Litespan SIP Gateway Transport

Litespan SIP Gateway supports UDP transport.
In the first release it is not expected the use of requests or
responses higher than 1300 bytes; however, in further releases
Litespan SIP Gateway must provide the ability to switch to TCP
when an originated message be higher than 1300 bytes.
Additionally, in further releases Litespan SIP Gateway shall be able
to receive TCP traffic.

(2) Litespan SIP Gateway Dimensioning

The port density supported allows a maximum number of
simultaneous calls is 508.
Litespan SIP Gateway supports capacity for IP service
performance, dimensioning requirements. Thus, the maximum
number of subscribers is 4000.

80 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(3) Litespan SIP Gateway Configuration Data

Following data are configured in Litespan SIP Gateway to support
the SIP GW function:

1 IP address of Litespan SIP Gateway.

2 Litespan SIP Gateway subnet mask.

3 Litespan SIP Gateway Default Gateway IP address.

4 Litespan SIP Gateway transport: udp, tcp; default=udp.

5 Default Home Domain name.

6 IP address of primary P–CSCF.

7 IP address of secondary P–CSCF.

8 Port of primary P–CSCF.

9 Port of secondary P–CSCF.

10 Litespan SIP Gateway Maximum Number of Subscribers:

integer, default=4000.
Litespan SIP Gateway Maximum Number of Subscribers Fixed
to 4000 in first release

11 Registration option: enabled/disabled; default=enabled.

12 Registration type: “explicit” / “implicit” ; default=explicit.

13 Implicit Registration Group Maximum Size : 0..Litespan SIP

Gateway_Maximum_Number_of_Subscribers, default=0
(Corresponding to default Registration type = explicit).

14 Subscribe to registration event option: enabled/disabled;

default=disabled.

15 Digitmaps (rules and timers) (Not in first release)

16 International prefix.

17 National prefix.

18 Percentage of reserved DSPs: 0..100; default=5. Applicable

to emergency calls.
Percentage of reserved DSPs not configurable in first release.

3EC 41919 0001 TQZZA Edition 01 81 / 185

 SYSTEM DESCRIPTION

19 INVITE Request–URI format.

20 INVITE From format.

21 INVITE To format.

22 INVITE Request–URI sip User format.

23 INVITE Request–URI sip Host format.

24 INVITE From sip User format.

25 INVITE From sip Host format.

26 INVITE To sip User format.

27 INVITE To sip Host format.

28 REGISTER From/To sip User format.

29 REGISTER From/To sip Host format.

30 E.164 of each subscriber.

31 MWI subscription per subscriber (expiration–time, message

account id).

32 ECT type: Not_available, ECT_Blind, ECT_Consultative.

Default: ECT_Blind.

2.4.9 SOS Mode

Internal SOS functionality consists in allowing local calls among
the user ports of a single NE when the Soft Switch is not
reachable. When the communication with the Soft Switch is lost,
the NE will pass autonomously to SOS mode.
SOS application is acting as an additional Soft Switch. VoIP
controller will send periodical Service Change (Forced) messages
to the Soft Switch, and at ACK reception will drop all established
calls and reconnect with it.
During isolation, any subscriber connected to a Litespan 1540
node can call any other subscriber connected to the same node by
using the provisioned DN. Calls to Emergency Services during
SOS mode will be treated as the rest of local calls.
BHCA figure in SOS mode is foreseen to be substantially lower
than in normal operation. In any case, the NE will have protection
mechanisms against high BHCA situations.

82 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

It is foreseen to assign the directory number when user ports are

associated to a media gateway interface from the A1353 DN
and/or from the CT. This DN is used exclusively for SOS service. In
normal operation, this internal SOS mode DN will not be used at
all, just the subscriber termination identifier (L3address field).
There will be a command from OS/CT to activate/deactivate SOS
mode on a per node basis.

2.4.10 Dual Gateway

A single Litespan NE is able to support two different signalling
interfaces: two H.248, one SIP & one H.248, or two SIP. Since VoIP
server is limited to a single signalling interface, it is required to
allow deployment of two independent VoIP servers per node.
These two VoIP servers share the server bus and the bus capacity
assigned to each one is configurable. Therefore the first signalling
interface will take 100 (no dual gateway), 75, 50 or 25% and the
second interface will take the rest. In order to allow migration
from no dual gateway to dual gateway, it is possible to modify the
bus capacity assigned to the first interface from 100% to a lower
share. Once the bus is distributed among two interfaces, further
share modifications are not allowed on–line; that is, modifications
will only be allowed when a single interface is defined and
therefore one interface will have to be deleted loosing service until
the modification is completed.
The features Dual Gateway, SIP and H.248 are ON/OFF. All
configurations are valid, that is, if SIP and H.248 are both OFF,
the node will be V5 only and no VoIP interfaces are possible.
The equipment will always show four potential slots for VoIP server,
even in the case of dual gateway is OFF. In that case, it is
recommended to use the first two slots as in versions previous to
this feature.
This feature includes NB controller redundancy and VoIP server
WSO in the SIP case. This implies that when either a switchover of
NB controller or VoIP server takes place, SIP established calls will
be lost and subscriber re–registration will have to be done. SIP
HSO is currently not supported.
HSO ON in a dual gateway system must be understood as V5 and
H.248 established calls are maintained but SIP ones are lost. That
is SIP WSO is provided independently of HSO ON/OFF.

(1) Alarms Handling

3EC 41919 0001 TQZZA Edition 01 83 / 185

SYSTEM DESCRIPTION

Former Litespan 1540 SIP version was designed to cover only

SIMPLEX configuration for both NB controller and VoIP server and
did not considered Ethernet alarm as a critical one (but as a
warning alarm) and therefore did not set neither SIP UA nor User
Ports in OOS state.
During Ethernet lost state, User Ports were able to get dial tone
although no call progresses.
Former Litespan 1540 H.248 version handled VoIP server Ethernet
alarm as a critical one which also launches VoIP server switchover
(hot or n+1 warm redundancy) when possible.
Current implementation covers SIMPLEX SIP configuration
behaviour but for any other configuration (SIP redundancy or
H.248 or dual gateway configurations) treats Ethernet alarm as a
critical one and launches VoIP server switchover when possible.

84 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.5 Communication with the Management Entities

(OS, CRAFT Terminal)

2.5.1 OS/CT OSI Networking

General principles and definitions:
" The internal interface used between the different management
interfaces (Q3, CRAFT terminal, Qecc, etc.) and the central
controller is the AMI (Alcatel–Lucent Management Interface)
interface. The AMI is introduced to isolate the central
controller of diverse management interfaces and to stop the
OS syntactical application layer complexity (CMISE for Q3)
allowing most part of the SW running in the central controller
board to be simpler and more efficient. A functionality must
manage the messages coming from the OS (For instance,
CMISE messages in Q3) doing the scooping and filtering in
each message and call to the different interface functions
(AMI) of the Core SW.
" The Q Adaptor Function (QAF) performs conversion between
the internal interface AMI and the standard Q3 interface
(CMISE, ROSE–ACSE). This QAF is performed by a building
block called Camina Front–End (CAFE). Therefore, the
central controller offers a full Q3 interface.
" The RAMI interface is also used to connect to the CT.
" Figure 33 shows communication between the Management
Entities (OS, CT)and the Litespan–1540 NE.
In this drawing, REM refers to a stack of protocols that implements
the processing oriented functions and the communication oriented
functions, thus layer 1 to layer 6 protocols. The REM function is to
solve those levels in one end point and, logically, it depends on
the network type (Layer 1 to layer 3) and end–to–end protocols
(Layer 4 to layer7). The next drawing describes some examples of
the protocol stacks used.

3EC 41919 0001 TQZZA Edition 01 85 / 185

 SYSTEM DESCRIPTION

ÊÊÊÊÊÊ CT
ÊÊÊÊÊÊ
OS
CTF

ÊÊÊÊÊÊ
OSF

ÊÊÊÊÊÊ RAMI

DCN REM

Other
Q3 RAMI

REM REM
Other CAFE CCFE
Adaptor (QAF)

AMI

NE NEF

Figure 33 Communication with the Management Entities (OS, CT)

(1) Communication with Local NB CT

Figure 34 shows NE and local CT connected by serial link.

NB controller
Serial Link
Local CT NE

Figure 34 NE and Local CT Connected by Serial Link

86 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(2) Communication with Remote NB CT via Modem

A NB Litespan–1540 CT can be connected remotely to a
Litespan–1540 NE using a POTS line and a basic modem. This
configuration is not very reliable and is not recommended at all.
However, it can be useful for demo purposes (See Figure 35).

NE

NB controller
Remote CT switched network

modem (V.25 bis) modem (V.25)

V.24 V.24
telephonic line

V.24
V.24

Figure 35 NE and Remote CT Connected by a PSTN Line and a Modem

(3) Communication of Litespan 1540 with the Remote NB OS

Figure 36 illustrates the SDH case. Communication between SDH
and the remote OS is made using the internal DCC for providing
the interface between the LINA and the NB controller. In case of
PDH, the Ethernet provides the interface between the NB controller
and the ADM controller when SDH transport is used. This
configuration is not possible with NB controller.

SDH Qecc*
OS ADM LINA NB controller

Ethernet
LAN

Figure 36 EU Based on Litespan 1540 SDH Management from Remote OS

Figure 37 shows the PDH case based on Litespan 1540 PDH

management from remote OS (connectet to an external SDH
ring). Routing in EU towards the RU. If we assume electrical
transport for the EU/RU interface, the TMN information is
transported in the EOC service channel, connected to the NB
controller by a NLC payload channel.
It is also possible to use LL networking between EU and RU.

3EC 41919 0001 TQZZA Edition 01 87 / 185

 SYSTEM DESCRIPTION

OS ADM ADM
SDH Qecc*
Ethernet
LAN

Ethernet
LAN

EU RUx

NB controller TT card TT card NB controller

NLC NLC

Figure 37 Management from Remote OS. Routing in Litespan 1540 PDH EU towards the
RU

(4) Communication of Litespan 1540 EU/RU and Ethernet NB OS

Connection

NLC NLC

OS NB controller TT card TT card NB controller

EU-NE RU-NE

Ethernet
LAN

Figure 38 Q3 Networking Connected to Ethernet LAN Network

(5) V5-hubbing embedded timeslot

In this point is described the solution of networking when the
networking among RU and EU is by mean of Remote V5 links
bearers, and these V5 link bearers are consolidated on V5 link
bearers of EU’s . The EU V5 link bearer must be in agreement
with the semipermanent leased line for V5 as is specified in the

88 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Annex E, sub–point E.3 of ETS 300 324–1 (V5.1 interface

specification) document.
Note In the case of the operator did no supply the V5
semipermanent leased line service on LE, other external
networking described for Q3/CLNP would be used for
the consolidation
The following topics must be considered:
" LAPB layer 2 will be used on the point–to–point subnetwork
among the EU–NE and the border CLNP router (and
therefore on the V5 link bearer point–to–point among the
EU–NE and the Local Exchange(LE) as part of that
point–to–point subnetwork)
" LAPD(AITS) layer 2 will be used on the point–to–point
subnetwork among EU–NE and Remote–NE (and therefore
on the point–to–point V5 link bearer among the EU–NE
and the Remote–NE)

2.5.2 OS/CT IP Networking

In this point are described the OS(CT)/NB–NEs networking
solutions when IP based data network is used. The solutions are
applicable to Litespan 1540. In the document are described the
protocol stacks and the network architectures.
The following cases of IP networking are applicable to
Litespan–1540.

1 IEEE802.3 networking.

2 V5 embedded timeslot.
3 Leased line embedded timeslot.
4 PD(SD)–Hub/PD–Remote SLT3 overhead networking:
applicable to cases 1, 2 and 3. [The SD–Hub/PD–Remote
configuration is not possible with NB controller in EU]
5 IP over OSI tunneling: IP based OAM can be tunneled over
OSI in SDh configurations. [Not possible with NB controller]
For the OS/NB–NEs networking every networking solution is
detailed.
The following general technical requirements must be
accomplished in the OS and NE:
" TCP/IP must be used for network and transport layers.
" At layer 2, PPP must be used also in the following
Hub–Remote networking interfaces:

3EC 41919 0001 TQZZA Edition 01 89 / 185

 SYSTEM DESCRIPTION

D Overhead channel SLT3

D V5 networking.
D LL networking.
" Routing protocol, e.g. OSPF, is not used for building the
routing tables on the NB NE playing the IP router role (NB
controller hub). The manual construction of routing table on
NB controller hub is considered acceptable.
" The upper–layer protocols from layer 5 between NB OS and
NB NE must remain as CMISE/X.226/X.225 (OSI protocols).
RFC 1006 must be used for adaptation between X.225(ISO
world) and TCP (IP world).
Table 5 summarizes the different possibilities for IP networking
with OS that are available in this Release.
By NB controller(NG) is meant the interconnection NB
controller(hub)–NB controller(remote) with the ’not groomed’ or
transparent solution. The use of PRC3 is just a transport
alternative; its networking is identical to the case of NB
controller(NG).

Table 5 IP networking possibilities

DCN-EU EU NB EU-RU NB networking

Local IP OVH NB controller(NG) NB controller(NG) IMA VC
SHDSL PRC3 LL–TS PRC3 V5–TS
802.3 YES YES YES NA NA
LL YES YES YES NA NA
V5 YES YES NA YES NA

Note Underlined options indicate first priority configuration.

90 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.5.3 IP networking at EU / RU
IP information at EU/RU will be provided by means of Installation
data. As routing protocols are not used, dynamic updating of IP
data is not foreseen. IP networking data cannot be updated from
OS.
Interfaces can be either, numbered or unnumbered.
" Interface between EU and DCN is always numbered
" Interfaces between EU and RUs are always unnumbered
From IP networking point of view EUs have to be considered as
single routers; the interconnection capabilities are determined by
Litespan–1540 interfaces, namely
" 802.3 interface
" E1 (V5TS or LLTS or OVHTS mutually exclusive) interface
" EU–RU interfaces
In case of hubbing, EU discovers the RU IP address by means of
IPCP, by using the ’IP–address’ configuration option.
IPCP is responsible of configuring IP over a PPP link; thus, when
PPP gets the Network Layer Protocol phase, IPCP(with option IP
address) allows to request to the other PPP end its IP address.
As EU–RU interfaces are unnumbered, the IP addresses of EU and
RU do not follow any constraint with regard to subnetting
schemes.
Remark that the external router must be manually configured to
route packets towards EU and RU IP addresses.
To take into account:
" 802.3 interface is always numbered
" each node, by installation, starts with one IP address: its own
IP address in case of numbered default interface, or inherited,
in case of unnumbered default interface.
Figure 39 shows the EU–RUs IP configuration. The figure
illustrates the following elements:
" A router that provides access to the OS DCN to the EUs. Each
interface has the corresponding IP address.
" An EU1 that has all unnumbered interfaces towards RUs, and
a numbered interface towards DCN:
The corresponding RUs (RU10, RU11, ...) have unnumbered
interfaces with the EU; they inherit the RU IP address.

3EC 41919 0001 TQZZA Edition 01 91 / 185

 SYSTEM DESCRIPTION

serial itf RU10

OS DCN
unnumbered itf serial itf
Router EU1 IP10

numbered itf
IP0 IP2 IP1 IP11 serial itf
unnumbered itf
RU11

Figure 39 IP networking/routing EU–RUs

2.5.4 IP networking Installation Data

By Installation Data each NE starts with the IP information to link
the NE to the DCN:
" the default interface: e.g., 802.3
" the interface mask: e.g. IP802.3MASK
" the NE IP address
" the default IP address to be used as gateway: IPGW
Thus, we are able to go into the NE from DCN by means of its
IP802.3 , and also to go out by means of IPGW.

2.5.5 IP addressing
(1) IEEE802.3 networking
For every case of IEEE802.3 networking, ARP protocol must be
used for getting the corresponding ARP table (i.e. for getting the
hardware addresses of hosts/routers from the IP addresses).

Non SDH Ethernet In this point is described the SD–Hub/Stand–alone or

networking PD–Hub/Stand–alone networking IEEE802.3 when not SDH.
Figure 40 displays the architectural model [NB controller can’t be
used in the SD–Hub/Stand–alone configuration].

92 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Non–SDH Ethernet networking (ARCHITECTURAL DIAGRAM)

NB-Hub/
NB-Stand-alone

NB OS
(IP host) NB controller
(IP host role)
IP INTRANET IP
router Subnetworks router
IEEE 802.3
IEEE 802.3

INTRANET INTRANET INTRANET

Subnetwork network Subnetwork

Figure 40 NB OS over IP network. NB–Hub or NB–Stand–alone. Non–SDH Ethernet

networking. Architectural Diagram

IEEE802.3 networking This case considers IEEE802.3 networking (either SDH or non
at Hub / Leased Line SDH) to reach the Hub NE and a leased line timeslot in the
Timeslot networking networking between Hub and Remote Unit.
between Hub and RUs In Figure 41 is described the architectural model.

NE-Hub

OS ROUTER 1 NB controller

IEEE 802.3 SDH or non SDH

IEEE 802.3

NE-Remote

NB controller

LL
Network

Figure 41 NB Q3 over IP network. IEEE802.3 networking at Hub, LL networking at RU.

Architectural Diagram

3EC 41919 0001 TQZZA Edition 01 93 / 185

 SYSTEM DESCRIPTION

(2) Hub/Remote SLT3 overhead networking

In this point is described the Hub/Remote networking when SLT3 is
used as transmission boards among Hub–NE and Remote–NE.
In this case the overhead networking among the transmission
boards is used as part of the point–to–point subnetwork among
Hub–NE and Remote–NE.
PPP layer 2 must be used on the point–to–point subnetwork
among Hub–NE and Remote–NE.
PPP layer 2 will be used on the point–to–point subnetwork
among Hub–NE and Remote–NE.
In Figure 42 is described the architectural model.

PD(SD)–HUB/PD–REMO TE SLT3/HLTC/EOTC OVERHEAD NETWORKING

Hub

IP SLT3
NB OS Router network NB controller

NLC
IEEE 802.3

PD-Remote
Electrical
(overhead channel)-NB OS

SLT3 NB controller

NLC

Figure 42 NB Q3 over IP network. Hub/Remote Overhead internal networking.

Architectural Diagram

94 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(3) V5 embedded Timeslot

V5 embedded Timeslot In this point is described the Hub/Stand_alone networking when a

bearer of a V5 link is used as part of the point–to–point
subnetwork among the NE and the border IP router. The used V5
link bearer must be in agreement with the semi–permanent
leased line for V5 as is specified in the Annex E, sub–point E.3 of
ETS 300 324–1 (V5.1 interface specification) document. This
solution would be able to be applicable too to
SD–Hub/SD–Stand_alone, in this case using the SDH transport
bearers corresponding to the V5 link bearers.
PPP(UITS) layer 2 must be used on the point–to–point subnetwork
among the NE and the border IP router (and therefore on the
point–to–point V5 link bearer among the NE and the Local
Exchange(LE) as part of that point–to–point subnetwork).
In Figure 43 is described the architectural model. In that figure is
described the case accesing, from LE, by means of Telefonica’s
solution . For other operators different access solutions should be
considered, but in any case a global point–to–point subnetwork
will be used.

NB controller
(Hub or Stand-alone node)

IP
OS ROUTER 1 Network ROUTER 2 LE NE
PRA bearer channel
(semipermanent leased line)
Ethernet V5 E1 bearer channel
(semipermanent leased line)

Figure 43 NB Q3 over IP network. V5 networking. Architectural Diagram

V5-Hubbing In this point is described the solution of networking when the

embedded Timeslot networking among Remote and Hub is by mean of Remots V5
links bearers, and these V5 link bearers are consolidated on V5
link bearers of Hubs. The Hub V5 link bearer must be in
agreement with the semipermanent leased line for V5 as is
specified in the Annex E, sub–point E.3 of ETS 300 324–1 (V5.1
interface specification) document.
Note In the case of the operator does no supply the V5
semipermanent leased line service on LE, other external
networking described for this Q3/IP would be used for
the consolidation.

3EC 41919 0001 TQZZA Edition 01 95 / 185

 SYSTEM DESCRIPTION

PPP(UITS) layer 2 must be used on the point–to–point subnetwork

among the Hub–NE and the border IP router (and therefore on
the V5 link bearer point–to–point among the Hub–NE and the
Local Exchange (LE) as part of that point–to–point subnetwork) in
the same as is described in previous point.
PPP layer 2 must be used on the point–to–point subnetwork
among Hub–NE and Remote–NE (and therefore on the
point–to–point V5 link bearer among the Hub–NE and the
Remote–NE).
In Figure 44 is described the architectural model. In that figure is
described the case accesing, from LE, by mean of Telefonica’s
solution . For other operators different access solutions would be
able to have to be considered, but in any case a global
point–to–point subnetwork will be used.

Consolidated V5 E1 bearer channel

(semipermanent leased line)
IP
Network NB controller TT card
OS ROUTER 1 ROUTER 2 LE

Ethernet PRA bearer channel

(semipermanent leased line)
NLC
(V5 E1 bearer channel)
(semipermanent leased line)

NB controller

(V5 E1 bearer channel)

Remote node

NB controller

Figure 44 NB Q3 over IP network. V5–Hub networking(consolidated V5). Architectural

Diagram

This case is only applicable when the transmission among

Hub–NE and Remote–NE is NB controller Transmission. In the
case using SLT3, the overhead channel networking, described in
Point (2) in the Section 2.5.5 is applicable.

V5-Hubbing This case is a combination of previous one (see point

embedded Timeslot V5–Hubbing embedded Timeslot) and overhead networking as
networking at Hub / decribed in Point (2) in the Section 2.5.5.
Overhead networking
between Hub and RUs

96 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(4) Leased Line embedded timeslot

LL embedded Timeslot In this point is described the Hub/Stand_alone networking when a

LL TS is used as a point–to–point subnetwork among the NE and
the border IP router.
PPP(UITS) layer 2 must be used on the LL TS point–to–point
subnetwork among the NE and the border IP router.
In Figure 45 is described the architectural model.

NE-Stand-alone
IP LL
Network Network
OS ROUTER 1 ROUTER 2 NB controller

Ethernet

Figure 45 NB Q3 over IP network. LL networking. Architectural Diagram.

Consolidated LL In this point is described the solution of networking when the

embedded Timeslot
networking among Remote and Hub is by mean of Remote LL TS,
and these LL TSs are consolidated on LL TSs of Hubs.
Note In the case of not existing LL network access from Hub,
other external networking described for this Q3/IP
would be used for the consolidation
PPP(UITS) layer 2 must be used on the point–to–point subnetwork
among the Hub–NE and the border IP router.
PPP layer 2 must be used on the LL TS point–to–point subnetwork
among Hub–NE and Remote–NE.
In Figure 46 are described the architecture and protocol stacks.

3EC 41919 0001 TQZZA Edition 01 97 / 185

 SYSTEM DESCRIPTION

NE-Hub
IP LL
Network Network NB controller
OS ROUTER 1 ROUTER 2

Ethernet

LL
NE-Remote Network

NB controller

Figure 46 NB Q3 over IP network. Consolidated LL networking. Hub/Remote External

Transport. Architectural Diagram

This case is only applicable when the transmission among

Hub–NE and Remote–NE is NB controller Transmission based.

LL embedded Timeslot This case is a combination of previous one (see point Consolidated
networking at Hub / LL embedded Timeslot) using SLT3, the overhead channel
Overhead networking networking, described in Point (2) in the Section 2.5.5.
between Hub and RUs

2.5.6 VoIP server Hot Switchover

(1) Overview
The Hot Switchover (HSO) functionality allows the maintenance of
VoIP service without call interruption in case of a malfunction or
extraction of an active VoIP server. This is a clear improvement
over the existin N+1 redundancy.
The main characteristics of VoIP server HSO are:
" Established voice calls are not lost. Voice flows are briefly
interrupted although the user does not perceive this disruption
beyond one second.
" On–going ISDN–BA connections are lost
" Calls being established during HSO process may be lost.
" Incoming calls may be ignored during a time not longer than
10 seconds after the HSO start.

98 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" Only 1+1 (one standby card for one active card)
configuration is supported. The four available slots per
Network Element (NE) are grouped in couples so two 1+1
associations per NE are supported.
" Media Gateway IP address is kept after HSO.
" Supported for Ethernet:
D Ethernet: MACs are different in standby and active card.
" Calls releases initiated during the HSO process can be
delayed a time not longer than 10 seconds after HSO start.
" Litespan HSO functionality is activated by configuration
involving both NB controller and VoIP server HSO. It is not
possible to activate HSO for one of these cards only.

(2) Architecture

System Architecture The following figure depicts the system architecture applicable to
HSO for Ethernet transport.
" Alignment
" Fast detection of a failure in the peer card: standby board can
detect a failure in active board, but active board can not
detect a failure in standby board by means of distributed
flip–flop mechanism.

3EC 41919 0001 TQZZA Edition 01 99 / 185

 SYSTEM DESCRIPTION

VoIP server
MII
PHY
slow bus
OBC
NLC bus (MPC866)
block
NB LIM
Server bus DSP Ethernet
block daughterboard Switch
PCI bus
TDM bus DSP
daughterboard
NB controller IQ bus
block
SAR

VoIP server
slow bus MII
PHY
OBC
NLC bus (MPC866)
block

Server bus
block DSP
daughterboard
PCI bus
TDM bus DSP
IQ bus daughterboard
block
SAR

Ethernet
Litespan 1540

Figure 47 System Architecture (Ethernet Transport)

Addressing IP address does not change

IP address must be kept after the switchover because there is no
way to inform remote MGs of a change neither with a direct
communication or via the MGC (Megaco does not provide means
for notifying an IP address change in an on–going call).
Internal (HSO) IP addresses
Each VoIP server needs an IP address for the communication with
its peer card. These addresses have to be chosen so to avoid
duplications with any IP address used by VoIP server.
One possibility is using IP addresses in the range 169.254.0.0 –
169.254.255.255 reserved for ”link local” (”This is the ”link local”
block. It is allocated for communication between hosts on a single
link. Hosts obtain these addresses by auto–configuration, such as
when a DHCP server may not be found”, RFC 3330).

100 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

An IP address for peer–to–peer communication is chosen based

on the slot where VoIP server is inserted. This relation is
hard–coded so VoIP server is able to know its address as well as
the peer card’s address once the slot is known.
MAC address changes (bridged Ethernet)
Media Gateway MAC address could be changed or not after the
switchover. But, in any case, the uniqueness of MAC addresses in
the network must be guaranteed. There are two ways of doing it:
" Using a MAC address associated to the NE:
D ADVANTAGE: There is no requirement on the network
since, from the point–of–view of the network, there is no
change in voice or signalling packets addresses.
D DRAWBACK: MACs addresses have to be configured
somehow and permanently stored in the NE. MAC
distribution has to be done in a centralized way.
" Using card’s factory MAC address:
D ADVANTAGE: No impact on configuration.
D DRAWBACK: HSO performance relies on network
element behaviour. The change of MAC involves the
transmission of a gratuitous ARP to inform the Ethernet.
Most of elements should update their ARP tables after
receiving this ARP in a very short time and routers should
allow the reception of packets with the same IP address
and different MAC address. However, there is a possibility
that some routers or switches are programmed in a way
that blocks packets after switchover.
Due to the complexity of handling MAC addresses associated to
NEs, option 2 is the proposed solution.
Note Another discussed possibility was that the factory MAC
address was passed from the active card to the standby
card. However, this procedure leads to MAC address
duplications if a card fails and gives its MAC to the
standby card and the failed card is repaired and
inserted somewhere else in the network.

Ethernet Transport Table 6 summarizes the changes on addressing and interfaces

after HSO based on the type of network interface transport.

3EC 41919 0001 TQZZA Edition 01 101 / 185

 SYSTEM DESCRIPTION

Table 6 Addressing and Interface Changes after HSO

Transport type IP address MAC address Network interface

Ethernet No change Changed Changed

The way to handle changes on MAC and interface is commented

later on this document.

(3) HSO Process Description

There are several conditions for the HSO to work:
" Initially, relevant port and call state information is transferred
to the standby card in a short time (seconds).
" This information is continuously updated.
" TDM signal gets to the standby card (DSP board takes the
clock from this signal): standby card ‘listens’ to the server bus
slots of the active board.
" Network elements in Litespan’s Ethernet discover the change
in MG’s MAC.
" After HSO, line cards are audited to align real port state with
stored state in the becoming–active VoIP server.
" Becoming–active VoIP server must be prepared to react to
possible misalignments with the MGC.

VoIP server States OS/craft activates HSO by setting the switchoverMode attribute to
‘hot’. This is a NE’s attribute.
The following HSO states are defined for a Megaco interface:
" SINGLE: HSO functionality is not set.
" SIMPLEX: HSO is set but there is only one VoIP server.
" DUPLEX: HSO is set and active and standby VoIP server
communicate.
In relation to these Megaco interface states, several card modes or
states can be defined for VoIP server:
" SINGLE: Active card when HSO functionality is not set.
" STANDBY N+1: Standby card when HSO is not set
" ACTIVE SIMPLEX: Active card when HSO is set and there is not
an inserted standby.
" ACTIVE DUPLEX: Active card when HSO is set and the standby
card is inserted.

102 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" STANDBY: Standby card when HSO is set and there is

communication with the active card.

(4) Network Management

The HSO feature is enabled for the NE as a whole. It is not
possible to activate it for VoIP server or NB controller
independently. The switchoverMode attribute, included in NE’s
restartController class, indicates the type of supported switchover,
either HSO or ‘warm switchover’.
hotSwitchoverStatus is a new attribute of the MGInterface class
with ‘active’ and ‘inactive’ as possible values. This attribute
indicates the availability of the HSO functionality in VoIP.
VoIP server HSO is not available when:
" Standby card is not inserted
" Active and standby cards are inserted but it is not possible to
establish communication between active and standby.
hotSwitchoverStatus value is shown in the icon representing the
MGI. AVC of this attribute will be managed in order to update it.
The operator can declare VoIP servers in any of the four available
slots. However, if HSO feature is active, these slots are grouped in
couples (1st–2 nd slots and 3rd–4 th slots) so only one MGInterface
can be associated to each couple. Once an MGInterface is
associated to a slot, the peer slot is reserved for HSO standby and
is not shown to the operator as a valid option for additional
MGInterfaces.
It is strongly recommended to check the configuration before
doing a migration from a version not supporting VoIP server Hot
Switchover. For instance, if the NE is in HSO mode and there are
two Megaco interfaces associated to the two slots of a VoIP server
couple, the migration should not be carried out unless one of the
Megaco interfaces is moved to another slot or deleted.
In any case, some action could be taken if such inconsistency
occurs. One possibility is to detect bad configurations at the
beginning of NE restart and change the switchoverMode to
‘warm’.

2.5.7 Echo Cancellation

Echo cancellation compliant with recomendation G.168 is
available in the VoIP server. Echo tail for G.711 and G.729A is up
to 32 ms; echo tail for G.723.1 is up to16 ms.

3EC 41919 0001 TQZZA Edition 01 103 / 185

 SYSTEM DESCRIPTION

2.5.8 Fax over IP (T.38) Path

T.38 calls are started as voice calls. Based on signals notifications,
MGC can trigger the switch to T.38. In this mode, fax transmission
is not longer sent as audio RTP packets, but T.38 is used instead.
For this, VoIP server de–modulates fax signal, extracts the relevant
information and transmits it according to T.38 using, in the case of
VoIP server, UDP as transport protocol.

2.5.9 GE OS Networking
(1) GE Management through NB controller
It is possible to carry GE management through NB controller. This
solution only apply to standalone nodes. There are two
architectures where this networking is available, namely

SDH Standalone Node In this case GE OAM flow is tunneled over OSI; the tunnel is
started in the ADM and finalized in NB controller. NB controller
performs IP routing (see Figure 48).

AMS
IP
router
IEEE 802.3
IP SDH ring
Network

1650 NB controller GEB3

IP ADM
router node

IEEE 802.3

Figure 48 GE management through NB controller: SDH case

PDH Standalone Node In this case GE OAM flow is inserted in the NB controller
ethernet; NB controller performs IP routing (see Figure 49).

104 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

AMS

IEEE 802.3

NB controller GEB3

Figure 49 GE management through NB controller: PDH case

2.5.10 VoIP Management

The Litespan VoIP Access Node will be fully managed from the
Alcatel–L ucent 1353 DN. VoIP OS Service Management will be
provided by Alcatel–Lucent 1355 DN. Alcatel–Lucent 1353 DN is
integrated in A1300 CMC, so Litespan can be managed from this
equipment. Pictures 50 and 51 provide a full view of the
reference model for the VoIP management.

OSS Gateway
Operator A1355 DN Operator

CMS
A1300 CMC/
A1360 SMC
Operator

A1353 DN AMS
MGC
(A5020, S12–MGC,
E10–MGC)

S12/E10 IP
LS1540 VoIP LS1540 VoIP
Network

Figure 50 LS1540 Network Management (A1353DN/A1355DN, AMS) overview

3EC 41919 0001 TQZZA Edition 01 105 / 185

 SYSTEM DESCRIPTION

LS1540–NE (MGs)
V5.2 pstnUP
LE v5TTP
v5TTP ....
alcv5Itf
CLS(MGC)
pstnUP
megaco
IP IP:UDP MGI pstnUP
Network Router
IP:UDP MGI
rtp ....

LS1540 NE

Figure 51 Management model for voice in LS–1540 VoIP

2.5.11 Outband NB/GE Management

(1) Outband Ethernet OAM
Outband Ethernet OAM is meant an Ethernet interface not used to
transport traffic, but only Management information. In Litespan
this concept has been adopted in a broader sense; thus, in
addition to previous definition, we also consider as Outband
Ethernet Management the consolidation of all Litespan
Management (i.e. NB and GE) over the same DCN interface

(2) Reference Network

Figure 52 shows the Outband OAM Reference Network

106 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

NODE C

Local 802.3 LAN

Transport Network
SDH

NODE A
1353 LMS
(DN,SH) DCN
NODE B
AMS

Local 802.3 LAN

Ethernet

Figure 52 Outband OAM Ethernet Reference Network

The Reference Network shows two important aspects:

1 The Element Managers, either AMS or 1353, are connected

to the DCN irrespective of the NE position in the network.

2 From NE point of view there are two cases:

D OAM communication is received in the Local NB
controller 802.3 interface (case Node B and C)
D OAM communication is received in a SDH flow (case
Node A)
Configurations with Remote Units are not supported.

(3) Networking Dimensioning

Configurations with Remote Units do not support Outband OAM
Ethernet. The reason for this limitation is the routing capability
through NB controller and the lack of flow control in GE network
management.

(4) Outband Ethernet OAM Description

NM information of the Litespan NB+GE is transported via
outband mechanisms.

3EC 41919 0001 TQZZA Edition 01 107 / 185

 SYSTEM DESCRIPTION

It is required that both the GE NM info (SNMP/UDP/IP) and the

NB NM info (CMIP/TCP/IP) are transported in the same bearer.
This bearer will be different depending on the Litespan
configurations (SDH, PDH), namely
" PDH: The Litespan must allow NB+GE NM info in a single
local 10/100 BaseT interface.This interface is the NB
controller LAN port . This case is represented as Node B in
Outband OAM Ethernet Reference Network. Main aspect is
the fact that NB controller receives both NB and GE
management flows, therefore NB controller must route (IP) GE
management flow.
" SDH:
D External ADM: from Litespan perspective, identical to PDH
configuration. This case is represented as Node C in
Outband OAM Ethernet Reference Network. In this
configuration both ADMs establish an IP over OSI tunnel
that carries both NB and GE management flows.
D Litespan with LINA: The NB+GE NM info must reach the
Litespan in a IP over OSI tunnel. This tunnel shall be
started at the ADM gateway and ended at NB controller
in the NE. LINA will be fully transparent. This case is
represented as Node A in Outband OAM Ethernet
Reference Network. Main aspects in this configuration
are: NB controller must end an IP over OSI tunnel and
route (IP) GE management flow.
EU– RU configurations are not allowed, therefore NB controller must
perform IP routing of GE management flow only over own NE GE
Controller.

2.5.12 Outband NB/GE Implementation

(1) SDH Configurations
The requirement can be reformulated by saying that we have to
establish IP communications over a mixed network: partially IP
Ethernet, partially OSI SDH.
Additionally, once we solve the NE connectivity, we have to be able
to receive both, NB and GE flows and route them internally over
the appropiate controller board.
Communication with NE; it consists of two parts:
" Between OS and ADM (A1650): IP over ethernet

108 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" Between ADM(A1650) and NE: IP over OSI tunnel. The tunnel
is initiated at ADM and terminated at NB controller.

(2) PDH Configurations

Figure 53 illustrates the communication from Elements managers
to Network Elements.

AWS

NEHC
1353 LMS

BB
(DN/SH)
ICB

LAN

DN: Q3/IP
DCN
AWS: SNMP/IP

Figure 53 Communication between Element Managers and NE

(3) Backup & Restore and SW Download

Scheduled NB/GE data backups must be programmed by letting
a sufficient window between the NB/GE requests over the same
node.
Normally a data backup lasts in the order of minutes and requests
the maximum bandwidth; therefore, special care should be paid
to avoid that two (NB and GE) data backups be running
simmultaneously through the same NB controller.
Same reasoning must be applied to manually required data
backups.
Same reasoning must be applied to scheduler or manual SW
download operations.

2.5.13 Gigabit Ethernet management

For Gigabit Ethernet a full CLI (Command Line Interface)
integration is targeted. A CLI agent will be implemented on the
NT, and all the TL1 commands in NT will be ported to CLI. The
existing TL1 commands can still be used in the new
implementation. If needed these TL1 commands shall even be
updated, e.g. as a consequence of introducing new feature.
The CLI command tree will contain command trees of LANX as
subtrees. The CLI agent on the NT will have to support parsing for

3EC 41919 0001 TQZZA Edition 01 109 / 185

SYSTEM DESCRIPTION

the complete CLI interface so that it can support auto–completion

and the help function for the complete CLI functionality. The CLI
agent will parse the complete command line with
auto–completion; once the line has been completed, the agent
will either execute the command itself or dispatch it to the LANx.
Therefore the dispatcher will have to know the complete command
tree of the LANx.
GEB3 also offers a SNMP management intreface towards AMS.
Cards managed by GEB3 are EFLC–A/B/I/H. Therefore, AMS
must consider these Line Cards as manageable from GEB3.

110 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.6 Synchronization
Synchronism can be obtained from the following sources:
" Extracted from the E1 (V5) interfaces
" One external T3 clock input (G.703), placed in the LIOC
front–plate. This clock input is lost in the case of GIO3 use
" Additional T3 clock input is ready from the integrated
LINA/NTIO (or any LIM card in such positions) or from the GE
controller provided such cards can extract a reference.
Observe that clock from LINA/NTIO and the one from GE
controller should not be sourced simultaneously to this T3 line;
this has to be avoided by configuration or installation
" Free run
In the case of LIOC use, both external T3 sources are available to
the NB controller positions via backplane. The reference selection
is decided there (based on provisioned priorities) in the NB
controller and then distributed to the whole system via the NLC
synchronization signals (each NLC bus provides a 8.64 MHz and
a frame/multiframe signal of 8 KHz); additional T4 clock output
(G.703) is distributed to the LIOC and made available in its
front–plate.
In the case of GIO3 use, both external T3A source, and T4
synchronism output are lost.
Besides, a unique 8 KHz synchronism, CKSYN2 signal, is
distributed from the active NB controller to the standby NB
controller and NTIO and GE controller positions.

NB controller T3B
LIOC
CKSYN2
E1 NTIOLINA
T3A

NLC
T4

GEB3 LIM

Figure 54 MLS–3F/3F4 synchronism with LIOC

3EC 41919 0001 TQZZA Edition 01 111 / 185

 SYSTEM DESCRIPTION

NB controller T3B
GIO3
CKSYN2
E1 NTIO/LINA

NLC

GEB3 LIM

Figure 55 MLS–3F/3F4 synchronism with GIO3

2.6.1 Synchronization in VoIP

In VoIP, network synchronization is implemented by means of a
NTP (Network Time Protocol) client in the OS and a proprietary
OS–NE synchronization. In general, NTP provides accuracies of
1–50ms, depending on the synchronization source and the
network.
In the VoIP servers, there is an additional error contribution due to
the time passed from the time transmission from the OS to the NB
controller and from there to the VoIP server. Moreover, the time
drift due to oscillator accuracy must be taken into account since
the time will be synchronised once a day. Considering all this, 1
second seems to be a good time accuracy objective for the VoIP
server time (see Figure 56).

112 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Litespan network
1353DN
NM
NTP Server ALMA Litespan
Version 1, 2, or 3 NTP client

NTP protocol

CMIP Time management operations

DCN

Litespan
1540
Litespan
1540

Supported RFCs : 1059, 1119 and 1305

Figure 56 Litepan System Synchronization with a NTP server

3EC 41919 0001 TQZZA Edition 01 113 / 185

 SYSTEM DESCRIPTION

2.7 Internal Maintenance

In all this chapter the boundary goes from the Central controller
board down to the Line Cards for NB traffic and from the Central
controller board to LINA board.
The following sections describe the four functional fault
management phases that can be identified:

1 Detection phase.

2 Localization phase.

3 Defence phase.

4 Notification phase.
Several layers are considered for each of the aforementioned phases:

1 Equipment layer.

2 Transport layer.

3 Service and Connection layers.

4 Management layer.

2.7.1 Architecture of Fault Management

The internal maintenance involves, basically, the following parts
regarding Equipment, Transport, Connection and Service Layers
(See Figure 57):

1 The failure/fault/alarm detection includes on–line & off–line

test results, read/write ASICs, and the supervision functions in
all boards/cards of the system.

2 The filtering function eliminates spurious and transient

failures. Filtering is performed as close as possible to the
detection function (In the boards/cards), so the notifications
sent by those to Central controller are restricted to the bare
minimum.
3 The alarm flooding prevention mechanism is incorporated
in transport functions.
4 The Central controller performs fault localization based on
those filtered notifications from the boards/cards.
5 The defence action is then performed by the Central

114 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

controller (The operational state of the objects is updated,

once identified to be faulty). The supported functions that are
impacted by defence actions are informed (i.e., in case of
board failure the transport/service layer is informed to disable
board ports).
6 The protection switching management incorporates
mechanisms to determine the standby status of the protected
items (Active/Standby boards). It is possible to perform a
switch–over commanded by the Equipment layer.
7 The CPL is updated taking into account that only root alarms
are registered and that dependent alarms in the alarm
hierarchy are masked.
8 The corresponding root alarms are logged in the event LOG,
and are notified to the OS/CT Operator. Note that, for the
remote DCE equipment in LL, ’all’ equipment alarms may be
reported in a single notification.
9 The operator (OS or CT) can set/get the Administrative state,
and the Active/Standby state of an object. When the object
(Board) is locked, the dependent objects (Ports) are put in the
disabled state dependently and the alarms of the object are
cleared/inhibited at card level (Drivers).

3EC 41919 0001 TQZZA Edition 01 115 / 185

 SYSTEM DESCRIPTION

Q3/CT itf.

NB CONTROLLER

MANAGEMENT LAYER
8+9

SERVICE LAYER
4+5+6
VA

BOARD/CARD
CONNECTION L
.
4+5+6 SERVICE
TRANSPORT L SPECIFIC
4+5+6 2+3

COMMONPART

2
EQUIPMENT LAYER
SW PLATFORM
CPL DRIVERS
7 4+5+6
1+2

DRIVERS VACS
1+2 1+2

SW PLATFORM
1+2

HW PLATFORM

Figure 57 Fault Management

116 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.7.2 Flooding Prevention

To avoid an avalanche of alarms caused by a root defect, only the
root alarm is reported to the OS/CT, where certain rules define an
alarms hierarchy, whose dependent alarms are masked by the
appearance of a given root alarm. When a root alarm is detected,
all dependent alarms are masked and not reported.
To prevent the reporting of floating alarms on/off, there is a
mechanism (Mainly at the transport layer) that distinguishes
permanent alarms from floating alarms. In case of a floating
alarm situation, only one notification is sent to the OS/CT after
being done the persistence of alarm on, and also only one
notification is sent to the OS/CT after the persistence is off.

2.7.3 Detection Phase

" Equipment layer faults:
D Boards:
When a board declares itself faulty, it must try to
communicate with the Central controller (Directly or via its
redundant peer). If communication is impossible, it
squelches its outputs. This allows the Central controller to
detect the board failure indirectly and allows it to decide
on protection switching.
Each board has its own specific alarm collection
function as described in Section 2.7.4.
One quite common mechanism used in the alarm
collection function by each board is the Write/Read
Check on all the addressable board devices (e.g., ASICs)
by means of the board controller.
D NB Extender links:
Once a failure is detected in the extension chain (i.e., on
any extender or extension link) the whole extension chain
switches over, including the Central controller. The failure
of NB Extender links is indicated by a set of alarms on the
receiving stages (Inside NSEC–C/Central controller) (See
Figure 58).

3EC 41919 0001 TQZZA Edition 01 117 / 185

 SYSTEM DESCRIPTION

NB Controller 1 NSEC–C Active 1

Peer Links
Peer Alarm 51.84 Mbit/s
SDH/PDH links Information links 51.84 Mbit/s links
Exchange

NSEC–C Standby 2
NB Controller 2

Figure 58 Redundancy of 51.84 Mbit/s Extension Link (NSEC–C)

D NLC bus:
This is the MLS bus carrying the NB traffic and is doubled for
redundancy reasons, both for Upstream and for Downstream
direction, with the structure depicted in Figure 59. A failure
in Downstream direction is detected inside the Line Cards
by an NLC FAW embedded in the frame, while a failure
in the Upstream direction is detected on the Central
controller by the LCPs (Line Card Patterns) that each Line
Card write on a reserved upstream bit in the frame.
However, not all the cards send the LCPs and no board
emit them when inserted in a extension MLS, so, a
procedure will be designed (future releases) to check the
upstream direction of both NLC buses; this mechanism
consists basically of making a loop of several TSs at some
line cards, inserting a pattern through them and verifying
the correctness of the data received back at the NB
controllers.

118 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

NLC 1 downstream
NLC2 upstream

NLC2 downstream
NLC 2 upstream

NB controller 1 NB controller 2 NB–LIMx NB–LIMy

Figure 59 Redundancy of the NLC Bus.

2.7.4 Localization Phase

" Equipment layer faults:
There are three main mechanisms to localize the Equipment
Layer faults by the Central controller:
1. Reporting of the fault item.
2. Correlation of errors.
3. Loopback.
D Boards:
Three main sets of boards can be considered for this
issue:
h Main MLS Shelf Controller (Central controller): The
way of localizing a Central controller failure is
Reporting or by means of a Correlation process of
the 51.84 Mbit/s link alarms.

3EC 41919 0001 TQZZA Edition 01 119 / 185

SYSTEM DESCRIPTION

h Line Cards: The assumption is that Central controller

knows that one Line Card failed: the question is to
find what it is in the shorter possible time. The loss of
the DL between the NB controller and the board is
also used, but takes longer time.
The localization of a faulty Line Card by the Central
controller is performed by Reporting through the
proper VA channel (If the failure allows it).
If the Line Card Fault is such that one Upstream NLC
bus is damaged (No VA can get through), the LCP
bits on it inform directly the Central controller that the
bus has a problem and, in case it is not a
stuck–to–zero of the whole bus, can also give
information about which Line Card failed.
In case the failure causes a stuck–to–zero of the
Upstream bus, a complete disabling of all the cards,
followed by a sequential (One–by–one)
re–enabling allows the detection of the card causing
the failure.
If the Line Card failure is such that the NLC buses are
not damaged but the card cannot report the fault
condition through the VA Channel, then Loopback
procedures on proper channels can cover the
significant remaining cases.
In fact, not all the cards can send the LCP bits, so, a
special NLC upstream bus failure detection process
will be designed (future releases) consisting of some
line cards making the loop of 3 TSs of both NLC
buses, inserting periodically a pattern through them
and verifying the correctness of the data received
back at the NB controllers; however, this procedure
does not inform us about the card in fail.
D NB Extender links:
Referring to Figure 58, one or more alarms on one
51.84 Mbit/s extension link indicates an eventually failure
of that link: The alarms are localized by the Central
controller through the proper VA channel.
D NLC bus:
A corrupted bus is detected using the procedures
described to localize faulty Line Cards.

120 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" Connection layer faults:

The same three main mechanisms as for Equipment Layer can
be used to localize Connection Layer faults by means of the
Central controller. However, the write/read check mechanism
on connection tables allows to trace continuously persistent
faulty HW, which could cause a Connection Layer fault. Such
a mechanism is part of Equipment level (Board) maintenance
mechanisms too.
D DS0 Level Path Monitoring Test:
This feature allows, together with Loopback procedures
at MLS level, to identify the connection section where the
fault is located.

2.7.5 Defence Action

The protection group is switched to a redundant protection board,
if any. Otherwise, the board is isolated from the operation.
" Equipment layer faults:
D Boards:
The Central controller and LINA can be configured in a
redundant way: Peers implement a distributed flip–flop to
communicate their state to each other and to manage the
relationship between their states (i.e., to ensure that only
one of them is active), as shown in Figure 60. If one of
these boards has been recognized as failing, the
switch–over process is executed
If the failing board is the LINA, the previously active
Central controller, the NLC bus and the Extension Chain
group are not changed: The switch–over process involves
only LINA boards.
If the failing board is the Central controller or an
Extension shelf controller, then the LINA remains the
previous one, while the Central controller, the NLC bus
and the Extension Chain group switch all over to the peer
group.

3EC 41919 0001 TQZZA Edition 01 121 / 185

 SYSTEM DESCRIPTION

DIS_1 not ACT_1

Peer 1

Peer 2

DIS_2 not ACT_2

Figure 60 Distributed Flip–Flop

Line Cards are not in a redundant configuration. Thus,
the isolation of the faulty Line Card can be only
performed by means of the Management Wires.
D 51.84 Mbit/s internal links:
A fault on the Central controller internal 51.84 Mbit/s
link would cause the swap to the other Central controller
board and on the peer NLC Bus and Subtending Chain
Redundant Group: Line Cards must change the operating
NLC bus. The same happens for one upstream link fault.
D NB Extender links:
A fault on one (Active, downstream) 51.84 Mbit/s
subtending link would cause the swap on the peer
downstream 51.84 Mbit/s link as described in the
previous point, maintaining the connection with the same
LINA. Line Cards must change the operating NLC bus.
The same happens for one upstream subtending link
fault.
D NLC bus:
A fault on one active NLC bus would cause the swap on
the other Central controller, NLC Bus and Subtending
Chain Redundant Group. Line Cards must change the
operating NLC bus.
" Connection Layer:
D DS0 Level Path Monitoring Test:
A new connection is performed (If available) and the
system avoids using the faulty connection any more.
A board with faulty connections level resources (One
threshold must be set) should be put out of service
(Switch–over or isolation, depending whether or not it is
redundant) as it is considered a faulty board.

122 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

2.7.6 Exercising of Redundant Equipment

The standby board is initialized and set in service updating the
redundant data received from the active board.

2.8 Subscriber Line Testing

2.8.1 Line Test Configuration
Tests described here are intended to test the equipment, lines and
line circuits directly connected to subscribers.
In the Litespan 1540, it is necessary to give access to each line and
to each equipment on a line card for tests. The line tests (outward
tests) or equipment tests (inward tests) can be done by an external
equipment set.
For all MLS–3F/3F4 line cards, testing features are integrated in
the own card therefore no test card is required as in previous
Litespan releases.

3EC 41919 0001 TQZZA Edition 01 123 / 185

 SYSTEM DESCRIPTION

(1) SLT3 tests

Figure 61 shows the SLT3 Leased Line test.

Exchange Unit Remote Unit Customer Premises

G.703

NLC bus NT
LT NLC bus

LT NT
SLT3 SLT3 G.703

G.703
or X/V

L2 (1) L1
L3 (Loop2b)
Loop3c
SLT3
CPNT

NB controller

Figure 61 SLT3 card and CPNTs network positions and tests

2.8.2 Elements Outside the NE Involved in Line Testing

There are some elements outside the Litespan–1540 system that
may play an important role in the line test function, either because
they need to be tested (Most of them) or because they influence in
the measurements (Need to be deactivated or special precautions
must be taken, etc.).

(1) Subscriber Analog Terminal

The telephone set is the end element and has to be tested as well
(In subscriber assisted tests such as Pulse/DTMF dialling, Register
Recall, etc.).

(2) Network Termination

This is the termination for digital ISDN BA lines and xDSL lines. For
ISDN, it allows the ”loopback 2” test. When the electrical
characteristics of the line have to be determined, a special
procedure has to be followed to decouple it temporarily from the
line (Depending on the different markets) or take its effects into
account. The same applies for Network Terminations and Remote
DCEs.

124 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(3) External Line Test Equipment

Optionally, line tests can be performed with external line test
equipment. The operator has to provide the right test environment
and a galvanic access (’Metallic test access’) between the line
circuit or the subscriber access and the external measurement
device.
2.8.3 Management of Tests
For what concerns line testing, this part is in accordance with ETS
300 378–1, which establishes the requirements and specification
of parameters for V5 User Port tests, and with X.745, which
establishes the Testing procedure. The proposal is to use the same
test procedure for connection tests, for other user port type tests
and for equipment (Line circuits) tests.
To avoid conflicts between intrusive testing and normal working of
the resources, the Line Testing functionality makes use of blocking
mechanisms: It is based on Test Conditions parameter specified
in the test request from OS/CT.
When the Test conditions parameter from OS specifies to reject the
test (Reject if busy), a blocking procedure is started and the LE
may decide to accept or to refuse the block.
Q3 interfaces provide the functionality to control test scheduling in
the Access Network. The results are also reported through the Q
or F interface.

2.8.4 Scheduled Testing

The Scheduling functionality at the Q3 interface is supported for
the releases scope of this document. The scheduling functionality is
provided at system level by means of the OS which will allow the
operator to specify the start time and periodicity of the tests, and
then will deliver the requests to the NE on the right times, most
usually during the night. CT is not required to support scheduling.
Support of OS for scheduling is limited to 1355 DN.
All tests that do not require customer assistance are suitable for
scheduled tests, e.g.:
" Foreign voltage and current measurement;
" Capacitance measurement;
" Insulation resistance measurement;
" All line circuit tests;
" Dial tone test;

3EC 41919 0001 TQZZA Edition 01 125 / 185

 SYSTEM DESCRIPTION

" Loopback test;

" Activation and deactivation of the line;
" Looptest with pattern (Analog L.lines).
The following requirements are valid for scheduling:
" Routine tests shall have lower priority than on–demand tests
and normal traffic;
" The test result shall indicate those ports which have not been
tested due to any reason;
" It shall be possible to specify the start time and the stop time
of the whole test sequence;
" It shall be possible to specify the number of times a test
attempt is to be repeated in case the first attempt failed due to
any reason;
" It shall be possible to add new User Ports to a routine test and
to delete User Ports from a routine test;
" It shall be possible to specify the test interval between the start
of consecutive test sequences (e.g. daily, weekly, seconds
between repeated tests) or the number of times a test is to be
repeated.

2.8.5 Test Threshold Management

When a passed/not passed result is requested, a predefined
CDE AN threshold value is used, unless the test request contains
threshold values which override the predefined thresholds. After
the termination of that test the predefined thresholds shall be
restored. The requests that can contain threshold values are those
for the outward tests of Electrical Measurement type and for the
inward tests: Feeding Voltage and Feeding Current.

2.8.6 Test Support

Table 7 shows the test coverage for the line cards in MLS–3F/3F4.
Information about leg combinations is also provided. The
following points should be noted:
" Column named S/A indicates whether or not the test requires
subscriber assistance
" When the measure is between a wire and earth the second
wire always remains floating
" Threshold values per test are defined in each specific CDE
document

126 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" No threshold is applied when capacitance and the insulation

resistance measures are referred to Leased Lines cards: PRC3,
SLT3 as the measurement can differ as result of the card
being or not connected to the NT

Table 7 Test support in Litespan 1540

A A B P S
T T A R L
L L L C T
C 3 3 3 3
– – –
F G G
/
H

TEST DETAILS UP/LC/UPCC S/A C C C C C

T T T T T
/ / / / /
O O O O O
S S S S S

ELECTRICAL MEASUREMENTS
FOREIGN VOLTAGE
Voltage AC a/b UP No X X X X X
Voltage AC a/E UP No X X X X X
Voltage AC b/E UP No X X X X X
Voltage AC c/d UP No X
Voltage AC c/E UP No X
Voltage AC d/E UP No X
Voltage DC a/b UP No X X X X X
Voltage DC a/E UP No X X X X X
Voltage DC b/E UP No X X X X X
Voltage DC c/d UP No X
Voltage DC c/E UP No X
Voltage DC d/E UP No X

FOREIGN CURRENT
Current AC a/b UP No X X
Current AC a/E UP No X X
Current AC b/E UP No X X
Current DC a/b UP No X X
Current DC a/E UP No X X
Current DC b/E UP No X X

CAPACITANCE
a/b UP No X X X X X
a/E UP No X X X X X
b/E UP No X X X X X
c/d UP No X

3EC 41919 0001 TQZZA Edition 01 127 / 185

 SYSTEM DESCRIPTION

A A B P S
T T A R L
L L L C T
C 3 3 3 3
– – –
F G G
/
H

TEST DETAILS UP/LC/UPCC S/A C C C C C

T T T T T
/ / / / /
O O O O O
S S S S S

c/E UP No X
d/E UP No X

INSULATION RESISTANCE
a/b UP No X X X X X
a/E UP No X X X X X
b/E UP No X X X X X
a/Battery UP No X X
b/Battery UP No X X
b/a UP No X X X X X
E/a UP No X X X X
E/b UP No X X X X
c/d UP No X
c/E UP No X
d/E UP No X
d/c UP No X

LOOP RESISTANCE
a/b UP Yes X X

TERMINATION
UP No X X X

FEEDING VOLTAGE
a/b LC No X X X

FEEDING CURRENT
a/b LC No X X X

NOISE LEVEL
a/b UP No X X

BLOCK READING TEST

UP No X X X

CONTINUOUS READING TEST

UP No X X X

TEST TO LINE CIRCUIT

FEEDING VOLTAGE

128 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

A A B P S
T T A R L
L L L C T
C 3 3 3 3
– – –
F G G
/
H

TEST DETAILS UP/LC/UPCC S/A C C C C C

T T T T T
/ / / / /
O O O O O
S S S S S

a/b LC No X X X
b/a LC No X X

FEEDING CURRENT
a/b LC No X X X
b/a LC No X X

LOOP AND RINGTRIP DETECTION

a/b LC No X X

RINGING CURRENT
Voltage AC a/b LC No X X
Voltage DC a/b LC No X X
Frequency a/b LC No

PRIVATE METER PULSES

Level a/b LC No
Duration a/b LC No X X

CODEC TESTING
TX Gain a/b LC No X X
RX Gain a/b LC No X X

RING TRANSMIT DISCONNECTION FUNCTION

a/b LC No X X

DRY LOOP
a/b UP No X X X

CABLE PAIR IDENTIFICATION TONE

a/b UP No X X X X X

DIAL TONE
a/b UPCC No X

VOICE ACCESS
a/b UPCC Yes X X

DIALLED DIGIT
DIAL PULSE
Digit recognition a/b UPCC Yes X X

3EC 41919 0001 TQZZA Edition 01 129 / 185

 SYSTEM DESCRIPTION

A A B P S
T T A R L
L L L C T
C 3 3 3 3
– – –
F G G
/
H

TEST DETAILS UP/LC/UPCC S/A C C C C C

T T T T T
/ / / / /
O O O O O
S S S S S

Average make duration/digit a/b UPCC Yes X X

Average break duration/digit a/b UPCC Yes X X

DTMF DIALLING
Digit recognition a/b UPCC Yes X
Tone level high a/b UPCC Yes
Tone level low a/b UPCC Yes
Tone frequency high a/b UPCC Yes
Tone frequency low a/b UPCC Yes
Pulse length a/b UPCC Yes

REGISTER RECALL BUTTON

Digit recognition a/b UPCC Yes X X
Pulse break duration a/b UPCC Yes X X

SUBSCRIBER PRIVATE METER PULSES

a/b (1 pulse) UPCC Yes X X

RINGING
a/b UPCC Yes X X

REVERTIVE CALL
REVERTIVE CALL SETUP
UP No X

MONITOR BUSY LINE

UP Yes X

RING AND SPEAK TO CUSTOMER

UP Yes

REVERTIVE CALL LINE CONFIGURATION

UP No X

REVERTIVE CALL LINE GET

UP No X

LOOP BACK
LOOP BACK TEST WITH PATTERN
Loop in LT (loop 1) ltNetwork UP No X

130 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

A A B P S
T T A R L
L L L C T
C 3 3 3 3
– – –
F G G
/
H

TEST DETAILS UP/LC/UPCC S/A C C C C C

T T T T T
/ / / / /
O O O O O
S S S S S

Loop in NT (loop 2) ntlNetwork UP No X

LOOP BACK TEST WITHOUT PATTERN

Loop in LT (loop 1) ltNetwork UP No X

Loop in NT (loop 2) ntlNetwork UP No X

Loop in line side llNetwork UP No X

Loop in LE side (loop 2b) llLocalExchange UP No X

ISDN QUICK
LAYER 1 ACTIVATION
UP No X

LOOP BACK TEST

UP No X

POWER FEEDING TEST

UP No X

FUNCTION TEST
UP No X

NT1 RESET
UP No X

CORRUPT CRC LT TO NT ONE MINUTE TEST

UP No X

CORRUPT CRC NT TO LT ONE MINUTE TEST

UP No X

LEASED LINES
HDSL/SHDSL PORTS WITH PATTERN
Loop 2b in NT (loop 3) remoteDigital/networkSide UP No X

HDSL/SHDSL PORTS WITHOUT PATTERN

Loop in LT (loop 1) local2/lineSide UP No X

Loop 3b in LT (loop 2) digital/networkSide UP No X

Loop 2b in NT (loop 3) remoteDigital/networkSide UP No X

BATTERY
NA No

3EC 41919 0001 TQZZA Edition 01 131 / 185

SYSTEM DESCRIPTION

The following restrictions apply to the previous table:

" Insulation resistance: When performed on BAL3–G/H ports
only reverse polarity between a wire and earth (E/a, E/b) is
allowed as the card does not support positive voltage; it was
agreed to show the test request and result as direct polarity
(a/E, b/E) at management system level as it seems more
intuitive for the operator
" Termination: This test shows a diagnosis of the line performed
in LTSL therefore the card firmware only have to return the
results of voltage DC, capacitance and insulation resistance
and LTSL will interpret those results characterising the line
then. Allowed statuses are the following ones:
D Normal: To be in either one of the following condition:
h Resistance value between a/b > 490 KOhm, and
Capacitance value between a/b: 0.3 uF< C < 0.8uF
h Resistance value between a/b > 30KOhm, and
Capacitance value between a/b > 0.8uF
D Open: To be in the following condition:
h Capacitance value between a/b is less than 0.3uF,
and Insulation resistance between a/b, a/E and b/E
is > 100 KOhm
D Short: To be in either one of the following condition:
h Capacity value between a/b is same or less than
0.3uF
h Resistance value between a/b is less than 490KOhm,
and the Capacity value between a/b is more than
0.3uF and less than 0.8uF
h Resistance value between a/b is less than 30KOhm,
and Capacity value between a/b is more than 0.8uF
h Resistance value between a/E is < 200KOhm
h Resistance value between b/E is < 200KOhm
D Cross: To be in the following condition:
h The voltage between a/b is > +5V, or the voltage
between a/E is> +5V, or the voltage between b/E is
> +5V
D No Termination: This status will be reported if there is a
fail during the test process
" Noise level:

132 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

D No thresholds are defined for this test and the OS does

not allow to select thresholds when this test is to be
requested
" Loop and ringtrip detection: When performed on ATLC–F
and ATL3–G ports only loop detection is performed
Table 8 shows the test outcomes applicable to each specific test in
Litespan 1540. Order in the table is showing priority (from
maximum to minimum). A hint on how to produce each test
outcome is also provided.

Table 8 Test outcomes in Litespan 1540

Test Outcome Meaning Testing Info Test

Configurable time Configurable timer (cur- Configure the time out period with a time All
out period ex- rently fixed in OS but set- lower than the test can take and check
pired table in CT) expired that this outcome is returned

Out of memory Lack of memory in control- Check that when the agent is run out of All
ler card memory this outcome is returned

Invalid parame- Any parameter present in Launch an electrical measurement test in All
ters the test request is not valid legs cTod on a PRC3 configured as one
pair and check that this outcome is re-
turned

Invalid user port Current user port does not Launch a loop test in a PSTN user port All
type support this test and check that this outcome is returned

Invalid number of Test requested on a num- Launch a block test on two ports and All
ports ber of ports higher than check that this outcome is returned
maximum

Permanent test Permanent test already Launch an electrical measurement test All
running running (previous cancel- after a dry loop test and check that this
ling required) outcome is returned

Mandatory pre- Mandatory test not pre- Launch a ringing test without previously EM/DD/
vious test missing viously launched executing a voice access test and check
SPMP/R/RC
that this outcome is returned

No access card or Required card not pre-
extension control- viously declared
ler detected
Launch an electrical measurement test EM/TTLC/
when the line card is declared in an ex-
DL/CPIT/
tension subrack and the correspondent
NSEC–C is not been declared and check DT/DD/RC
that this outcome is returned

3EC 41919 0001 TQZZA Edition 01 133 / 185

 SYSTEM DESCRIPTION

Invalid access Required card in an invalid Launch a dry loop test on a port declared EM/TTLC/
card or extension state such as blocked or in the extension subrack; reset the
DL/CPIT/
controller state disabled NSEC–C card previously to start the test
and check that this outcome is returned DT/DD/RC

Access card or ex- Required card does not Check that when the LIOC/GIO3 does EM/TTLC/
tension controller answer to an OAM mes- not answer to an OAM message this out-
DL/CPIT/
communications sage come is returned
time out DT/DD/RC

No line card de- Line card not previously Launch the test without previously declar- All except B
tected declared ing the line card and check that this out-
come is returned

Invalid line card Line card in an invalid Launch the test while the line card is All except B
state state such as locked or dis- loading and check that this outcome is
abled returned

No revertive line Revertive line card not pre- Launch the test without previously declar- RC
card detected viously declared ing the revertive line card and check that
this outcome is returned

Revertive line Revertive line card can not Check that when the revertive line card RC
card error measure or rejects the gives to LTSL an OAM code different than
LTSL command that one LTSL requested this outcome is
returned

Invalid revertive Revertive line card in an Launch the test while the revertive line RC
line card state invalid state such as locked card is loading and check that this out-
or disabled come is returned

Invalid line card Current line card does not Launch a monitor busy line test over a RC
type support this test line card and check that this outcome is
returned

Port not available Port blocking rejected by Launch a dry loop test on an off–hook EM/TTLC/
the LE user port and check that this outcome is
DL/CPIT/
returned
RC/LB/
IQ/LL

Measurement not Any measure present in Launch a feeding current test on an PRC3 EM
supported the test request not sup- port and check that this outcome is re-
ported or requested test turned
not in the supported ones

Line card com- Line card does not answer Check that when the line card does not All except B
munications time to an OAM message answer to an OAM message this out-
out come is returned

Line card error or Line card can not measure

communication or rejects the LTSL com-
error mand

134 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Conventions in previous table:

" EM: Electrical Measurements
" TTLC: Test To Line Circuit
" DL: Dry Loop
" CPIT: Cable Pair Identification Tone
" DT: Dial Tone
" VA: Voice Access
" DD: Dialled Digit
" SPMP: Subscriber Private Metering Pulses
" R: Ringing
" RC: Revertive Call
" LB: Loop Back
" IQ: ISDN Quick
" LL: Leased Lines
" B: Battery
The following restrictions apply to previous table:
" Timed out: Only supported by tests with pattern for leased
lines and loop back tests
" Invalid event detected: Only supported by tests with pattern
for leased lines and loop back tests
Cancelling of a running permanent test can return the following
test outcomes:
" pass, when the test is cancelled
" mandatory previous test missing, when there is no permanent
test running in the NE
" fail, when the line card does not cancel the test
" invalid line card state, when the line card is locked, disabled
or not present

3EC 41919 0001 TQZZA Edition 01 135 / 185

 SYSTEM DESCRIPTION

2.8.7 ADSL Line Testing

ADSL in Litespan–1540 uses the same hardware to perform the
POTS line tests as the POTS cards. Therefore, section 2.8 in this
document is also applicable for ADSL in Litespan–1540.
Additional functions are required to allow the POTS line tests to be
performed on the ADSL lines. The differences are described
below.
As ADSL lines share the physical copper pair as an existing POTS
service, line testing is supported only via the existing POTS line
test. ADSL line testing same line tests performed on narrowband
lines.
Most of ADSL line tests are performed without bypassing, and so is
the in the path of the line under test. This method is simple and
means that the test system and the ADSL management does not
need to synchronize.
The GE controller notifies the line test system that the test can
proceed. Once the test is complete a procedure is followed to
reset the relays and resume normal connection of the ADSL lines.
The GE controller notifies the line test system that the test can
proceed. Once the test has been completed, a similar procedure
is followed to reset the relays and resume the ADSL lines normal
connections.

2.8.8 VoIP Line Testing

The objective is minimum or zero impact in Line Testing
functionality caused by VoIP feature introduction in Litespan.
Impact can be interpreted in two ways:
– Minimum or zero differences between Line Tests of a V5
subscriber vs a VoIP POTS subscriber: tests supported, operator
interfaces, test parameters ,etc
– Minimum or zero impact in Litespan SWBB’s or HW modules
The only difference so far identified in Line Testing for VoIP
subscribers is regarding the User Port Block/Unblock. While V5
subscribers are requested by the AN to be blocked, in VoIP a
Megaco ServiceChange message is sent to the MGC.

2.9 GE Configuration Architecture

The system provides a BB multiplexer function making use of a
controller board (GEB3) optionally 1+1 redundant, and line cards
(EFL3) connected through the HCLs working at 1 GE.

136 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

GE controller is built from a LANX subsystem and a control

subsystem.
The LANX subsystem is an Ethernet switch based on a 3rd party
Ethernet switching SW platform running on a highly integrated GE
switch ASIC. The LANX subsystem also includes a dedicated
controller taking care of control and management plane of the
LANX component. The LANX also implements the network
interfaces.
The control subsystem is based on a powerful general purpose
provessor. The control system implements the management plane
of the system and part of the control plane, the part related to
subscriber management which is typically not found in an Ethernet
switch product.
EFL3 line cards are built from an interworking function and a
transport subsystem.
The IWF consists of a packet processor implementing the fast path
and a control processor for the slow path, control plane and
internal OAM applications. The packet processor has to be
capable of handling frames at L2 and L3, including sophisticated
filtering and traffic management, all at DSL line rate.
There are two variants of EFL3 line cards; with (EFL3–A) and
without (EFL3–B) splitters. EFL3 with splitters occupies two slots,
whereas the splitterless variant only one. Both, A and B variants,
are applicable to POTS underlying service.
There are two variants of EFL3 line cards: with (EFL3–I) and
without (EFL3–H) splitter; H and I variants are applicable to both
POTS and ISDN underlying service.
Figure 62 illustrates the main subsystems in both boards, their
links and the different data paths.
Remark that the birdge STM1–Ethernet data path goes through
the PQIII OBC.

3EC 41919 0001 TQZZA Edition 01 137 / 185

 SYSTEM DESCRIPTION

NT
LIM
LANX IWF Utopia L2
or
Trans-
OBC IWF OBC POS PHY port
FE/GE or
GE SPI3

SWITCH

GE FE

VLC: ATM–ETH
PQIII

S Fast Path
T
M Slow Path
1
Bridge STM1–Eth Path

Figure 62 GEB3 and EFL3 Subsystems and Data Paths

138 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3EC 41919 0001 TQZZA Edition 01 139 / 185

 SYSTEM DESCRIPTION

3 HARDWARE ARCHITECTURE

3.1 Access Network Interfaces

3.1.1 Optical STM-1/STM-4/STM-16

These signals are handled by Optical modules that convert G.957
optical signals into electrical ones on the aggregate side.
The SDH frame format complies with ITU–T G.707 Rec.
It is also performed ALS (Automatic Laser Shutdown) procedure
with three available algorithms following the G.958.
G.783 RSOH and MSOH handling is performed on converted
electrical signals to extract the High and Low Order Virtual
Containers.
Additionally LINA card includes an Optical STM–1 interface on
tributary side.

3.1.2 Electrical PDH

Both NEHC–C and PRC3 cards support 2 Mbit/s electrical PDH
interfaces. The PDH interface complies with ITU–T G.703 Rec.

3.1.3 Ethernet interface (VoIP)

VoIP server only provides Ethernet interface. Ethernet interface
consists on a MII microprocessor interface in VoIP server and a
double PHY device dedicated to implement cabling failure
redundancy.

140 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

GIO3 aggregates traffic coming from VoIP servers with node

management traffic from NB controller.

3.1.4 Ethernet Interface (GEB3)

One GEB3 shall provide the following network interfaces on the
front panel:
" Two optical SFP GE port
" Four electrical 10/100/1000BASE–T RJ45 ports
" One STM1 optical ports (not provided by GEB3–B)
" One RS232 UART port
A standard configured rack is equipped with two GEB3 boards.
Since these interfaces can be used for local accessing, sublinking
and so on, the number of network access interfaces is
configurable.

3.2 GE Line Interfaces

3.2.1 ADSL
Summary of the key ADSL features:
" Point–to–point connection, between the ADSL LT and the
ADSL NT.
" Use of DMT (Discrete Multi–Tone) modulation to transport
high bitrates over an Unshielded Twisted Pair drop line (UTP
line). The UTP or the UTP part carrying the DMT signals must
be limited to 3 km.
" Protection of data sent on the UTP line by means of Reed
Solomon coding. Interleaving offers optionally an even better
protection against burst errors, but it has also a disadvantage:
Increased transfer delay.
" Use of a frequency division multiplexing technique to overlay
DMT signals (28.875 Khz –1100 kHz) over POTS signals
(0–4 kHz) or DMT signals (138–1,100 kHz) over ISDN
signals (0–120 kHz) for joint transport over the UTP line.
" Typical downstream line bitrate: 6–10 Mbit/s (Only POTS
variant), 4–8 Mbit/s (Switchable POTS/ISDN variant, which
works with ISDN frequency spectrum filtering).
" Typical upstream line bitrate: 640 Kbit/s.

3EC 41919 0001 TQZZA Edition 01 141 / 185

 SYSTEM DESCRIPTION

" Given a minimal required quality of service (i.e., BER of

10–7 ), the usable bitrate depends on the drop line quality
and length. The ADSL modems on the NT and on the LT side
determine automatically the maximum transport capacity.
" OAM:
D Detection of loss of signal.
D Detection of loss of frame.
D RS decoder: Counting of correctable bit errors and
uncorrectable bit errors.

3.2.2 ADSL2 and ADSL2+

ADSL2 (ITU G.992.3 and G.992.4) adds new features and
functionality in order to improve ADSL performance and
interoperability. It allows new applications, services, and
deployment scenarios. Among the changes are improvements in
data rate and reach performance, rate adaptation, loop
diagnostics, power management, improved initialization...
ADSL2+ is a delta specification to G.992.3 and mainly increases
the downstream data rates by doubling the ADSL frequency range
up to 2.2 Mhz. Besides this, it also provides means to allow
ADSL2+ deployment from the cabinet while still remaining
spectrally compatible with ADSL from the central office.

142 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3.3 Narrowband Line Interfaces

3.3.1 Baseband Data LL Interface

This interface connects to a CPNT suitable for medium–low speed
data connections, supporting local interfaces type X.21–bis/V .28
or V.35. Its main characteristics are:
" Point–to–point connection over two twisted pairs (One per
direction) to a remote NT. The maximum distance using a 0.6
mm TP exceeds 10 km.
" Line speed: 72 Kbit/s, carrying a payload of 64 Kbit/s
maximum, optionally sub–multiplexed according to the
ITU–T Rec. X.50.
" Line code is AMI, data are scrambled to help clock extraction
on the remote side.
" Octet framing bit containing a 2.67 Kbit/s house–keeping
channel (Bit H) in its multiframe.
" Full remote control of the CPNT via a byte–oriented protocol
on the house–keeping channel.
" OAM capability:
D Detection of loss of signal.
D Detection of loss of frame.
D Measurement of Signal Quality on the framing bit.
D Detection of Remote Alarm Indication coming from the
CPNT.
D Detection of the absence of handshake on the
house–keeping channel.
D Detection of ’dying gasp’ issued by CPNT (Message on
the H bit) when powered off.
D Loop capability by an in–band indication (Both in case of
subrate X.50 and full 64 Kbit/s payload; the latter
conforming to ITU–T Rec. V.54). Note that the loop can
be called only from the remote end of the line (i.e., is not
under OAM control on the LT).

3.3.2 E1 Interface to Leased Line Data CPNT

This interface connects to a CPNT suitable for data connections,
supporting local interfaces X.21/V.11, V.36 or 2 Mbit/s G.703. Its
main characteristics are:

3EC 41919 0001 TQZZA Edition 01 143 / 185

SYSTEM DESCRIPTION

" A point–to–point connection over two twisted pairs (One per

direction) to a remote NT. The maximum distance using a 0.6
mm TP is about 2 km. It is possible to extend the line up to 6
km by means of line regenerators.
" A line speed of 2,048 Mbit/s, carrying a payload of
Nx64 Kbit/s with N variable between 1 and 32. In case of N
= 32, the connection is unstructured (No frame).
" The line code is HDB3, and the electrical interface conforms
to the G.703 with an extended input attenuation tolerance of
up to 40 dB.
" In case of a structured interface, a 4 Kbit/s house–keeping
channel is available, using a spare bit (Bit 7 typically, but any
bit can be provisioned) of the Frame Alignment Word.
" Full remote CPNT control via a LAP–D protocol on the
house–keeping channel.
" Power feeding from the LT (Optional), current–fed at 48 mA,
0V to 105V with the voltage limited to 110V.
" OAM capability:
D Detection of loss of signal.
D Detection of loss of frame (Structured interface).
D Detection of AIS on the whole stream (Structured
interface).
D Detection of AIS on the Nx64 payload according to
ITU–T Rec. V.38.
D Measurement of Signal Quality by means of CRC–4
(Structured interface).
D Measurement of the bit error rate (Based on the number
of code violations) on every regenerator by means of an
out–of–band modulated tone (1 kHz).
D Detection of Remote Alarm Indications coming from the
CPNT (Structured interface).
D Detection of ’dying gasp’ issued by CPNT on spare bit 6,
when powered off and not power fed from the LT
(Structured interface).
D Detection of the position where the line cable is cut by
counting how many regenerators are still visible (Count
done by reversing power feeding polarity).

144 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

D Loop capability on the CPNT by means of a specific OAM

message on the house–keeping channel (Structured
interface).
D Detection of unbalanced power feeding.

3.3.3 ISDN_U Interface

This interface connects to an ISDN Basic Access NT. It complies to
the ITU–T Rec. G.961.
The following main functions are provided:
" Remote power feeding for NT, repeater and TE via subscriber
line.
D Feeding voltage at 70 V or 96 V, on provisioning.
D Feeding current up to 35 and 40 mA, depending on the
card.
" 2B1Q or 4B3T line code.
" Up to 8 km of line with a 0.6 mm twisted pair (Without
repeater).
" Idle line and power down support.
" One 16 Kbit/s D–channel.
" Two 64 Kbit/s B–channels.
" OAM capability:
D Embedded operation channel, allowing the following
operations:
h Bit error rate, including repeater sections.
h Loop management.
D Detection of line errors (No startup upon activation, loss
of frame, etc..).
D Overcurrent in the power feeding system.
" Line test support.

3EC 41919 0001 TQZZA Edition 01 145 / 185

 SYSTEM DESCRIPTION

3.3.4 POTS Interface

This interface connects to a telephone set. It is an analog interface,
whose parameters strongly depend on local specification. This
type of interface normally requires CDE implementations. The
main common features are the following:
" Line feeding (Max. feeding current is programmable).
" Loop length up to 8.3 km with 0.4 mm copper pair @ 18 mA
feeding current.

Note The line length strongly depends on the characteristics

of the telephone equipment located at CP. Telephones
requiring high current, or causing voltage drops,
reduce the maximum line length.

" Automatic reduction of line current during restricted power

operation (Backup batteries).
" Ring voltage insertion.
" Metering tone insertion.
" Polarity reversal.
" Programmable line impedance with echo cancellation.
" Programmable Central Office impedance.
" Programmable gain level.
" Line test facility via test relay to an external test equipment.
" Overvoltage protection and overcurrent detection.

3.3.5 SHDSL
SHDSL (Single pair High speed Digital Subscriber Line) is used in
Litespan–1540 to connect 2 Mbit/s or nx 64 Kbit/s services to the
user, or to connect Litespan–1540 remote entities to the central
office using twisted pair cable.
Summary of SHDSL features:
" Transmission: Duplex operation over mixed gauge two–wire
twisted netallic pairs. Litespan–1540 does not support the
standardised four–wire operation for extended reach
applications.
" Line rate: Symmetric user data rates in the range of 192
kbit/s to 2312 kbit/s using a Trellis Coded Pulse Amplitude
Modulation (TC–P AM) line code.

146 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" Payload: 2048 Kbit/s (Unstructured, structured or n x 64

services).
" Line code: Trellis Coded Pulse Amplitude Modulation
(TC–P AM).
" Echo cancelling between upstream and downstream.
" Optional power feeding of regenerator or remote NT (Not
both).

Note Power feeding is not currently available but it is

foreseen (HW ready) for future releases.

" Optional wetting current from 200 μA up to 3 mA to the

regenerator or remote NT (Not both) when it is supplying
locally.
" The digital section (LT+NT) is managed by means of a service
channel to perform OAM:
D Failure detection.
D Pair identification.
D CRC error detection.
D Loopbacks.
" Additionally, the LT and NT feature a 64 Kbit/s bearer to
transport one User channel for OAM on the RU.

3EC 41919 0001 TQZZA Edition 01 147 / 185

 SYSTEM DESCRIPTION

3.4 Internal Interfaces

The interfaces described in this section are all proprietary
interfaces connecting different boards in the Litespan–1540
equipment. These are:
" NLC Bus
" Inventory Access Bus (IAB)
" Hardware Management Wires (HMW)
" Server Bus
" HCL Connection

3.4.1 NLC Bus

The Narrowband Line Card bus is a time division, scaleable bus
with shared packet channel capability (HDLC based) on one
portion of the total payload.
The bus is located between the shelf controller/extender card and
all the NB line cards in the shelf. The NLC bus can be extended to
up to four cascaded shelves.
The total bandwidth is 51 Mbit/s, 2 Mbit/s of which can be
devoted to shared packet traffic. O&M, Control and signalling
channels are within this last portion.
The signals can be grouped in three families: Transport,
Synchronization and Arbitration. The signals in the Transport
family carry all the data (Payload and auxiliary information)
flowing through the NLC bus, the Synchronization family
distributes the clocks and frame markers to lock on the data and
the Arbitration family allows to the same synchronous channel
(Time slot) among any number of boards in a shelf. Apart from
these families, a signal is used in redundant configurations to
select the set of lines to be considered as active. Additionally, one
downstream line (Called DREF) with a reference DC signal is used.
The transport signals, both upstream and downstream, are
grouped in pairs, each one carrying an equivalent capacity of
17 Mbit/s. It is possible to use up to three pairs per direction, thus
allowing a maximum capacity of 51 Mbit/s.
The synchronization signals are a bit clock 8.64 MHz and a
frame/multiframe pulse (8 KHz for frame / 500 or 100 Hz
programmable for multiframe). The difference between a frame
and a multiframe pulse is the pulse width.

148 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

The arbitration signals are composed of two lines, one per

direction, implementing a bus with CSMA/CR (Carrier Sense
Multiple Access/Collision Resolution) capability for a capacity of up
to 2 Mbit/s.
The protection on NLC bus is achieved by means of the complete
duplication of signal lines. Transmitters must transmit the same
data on both sets of lines, while receivers must check the validity
of the set of lines they are assuming as active. Upon detection of
an error condition (Absence of the proper pattern in the input
stream, absence of clock or sync signal, no transitions on the
contention line) a switch–over is performed automatically, and the
action is notified.
Under normal operating conditions, a selection line status
indicates the set of redundant lines to be considered as active.

3.4.2 Inventory Access Bus (IAB)

The Inventory access bus (IAB) is used in the equipment:
" To retrieve inventory information stored in non–intelligent
boards.
Although on intelligent boards the remote inventory information is
accessible by communicating with the On–Board Controller, an
interface compliant to this bus is internally provided to allow
factory inventory operation (By means of a special tool) when the
unit is not powered or the control part is faulty.
These lines do not have redundancy protection.
Since these signals are indoor and bounded to be shorter than
3 meters, they do not need protection against neither electrostatic
surges nor fast transients.

3.4.3 Hardware Management Wires (HMW)

All Litespan–1540 boards can be disabled and externally reset or
powered off by direct actions on the proper wires. These wires are
controlled by a single agent for the whole shelf (Named shelf

3EC 41919 0001 TQZZA Edition 01 149 / 185

 SYSTEM DESCRIPTION

controller, in redundant configuration if redundancy is applied to

the shelf), and are connected to every board.
Note Permanent disabling of cards by the HMW is not
supported.This avoids NB/GE collision problems in
detection of NB and GE cards presence. The peer
NB/GE controller has to suspend all functions on the
disable line if the peer link is checked, otherwise a
disable could erroneously appear as GE LIM presence
detection. A contention mechanism uses a general
disabled line shared by the NB and GE controllers
before accessing to HMW.

3.4.4 Server Bus

This bus in the MLS exchanges the payload between the NB
controller and VoIP server. It is a TDM bus, with a capacity of
32 Mbit/s per direction (downstream, upstream).
The signals are composed of 4 payload lines per direction, one
clock and one frame start. Each payload line carries one fourth of
the total bandwidth of the bus. One additional payload line per
direction (the fifth) is available for protection reasons.

The clock and synchronization are protected by duplication. Each

controller outputs its frame synchronization and clock. The signals
transmitted from the two controllers are in phase, so that it is
possible to switch from one line to the other without introducing
errors in the communication.
If one line fails, the other is selected. If both lines are operational,
the lines selected are those transmitted by the active controller.
Payload lines are protected by adding a fifth, spare line to the four
actually carrying the payload. Once a line becomes unavailable
for one or more servers (error detected on the toggling bits), the
payload carried by the line is moved to the spare, and the labels
are adjusted. The protecting line receives the label formerly
carried by the failed line, and the failed line is labelled to 7.
Upstream and downstream lines are always associated, so a
protection action always refers to both upstream and downstream
physical lines.

150 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3.4.5 HCL Connection

These links exist on Litespan MLS shelves as a means of providing
high bandwidth services. HCL (High Capacity Link) point to point
interface is also available for GE services.
Each GE controller has a single 1 Gbit/s high speed HCL
connection to each GE LIM. This type of connection allows
redundant 2x1 Gb/s access from EFL3s to the switch fabric in
GEB3.
HCL links support the 16 GE link connections from GEB3 to each
one of the LIM cards. LIM cards using HCL links towards GEB3 are
available.

3.5 MLS Versions

An MLS is defined as a set of standard interconnections between
Controller Cards, Line Cards and Server Cards.
Cards can be assembled in different combinations, offering
different services and overall capacities. All these combinations
are considered as MLS versions. They are characterized by the fact
that they all host the same cards for the same services, i.e., a
controller fitting one version can be plugged in any controller slot
of any other version supporting the same services (or a superset of
them).
This section describes the general characteristics of the MLS
depending on the various versions currently defined.

3.5.1 General Description

New shelves target an important cost reduction for the Litespan
product as well as readiness for future evolutions of the product.
Front Access Area Section is included in Card Section, it means
that the external connections are made available in the own card.
Card Section can be further divided into a NB controller and
Network Interface section, located in the leftmost part of the shelf;
GE controller and Transport section, located in the middle part of
the shelf; and a Line Card section, occupying the rest of the shelf.
The Line Card section hosts also the server cards.
The most general characteristics of new Litespan shelves are the
following:
" Shelves can act as main or extension fitting up to 20 NB LIM
cards and ready up to 18 GE LIM cards

3EC 41919 0001 TQZZA Edition 01 151 / 185

 SYSTEM DESCRIPTION

" Versions of 2 or 4 slots equipped with server bus connections

" Slot 1 provides power connector, NLC bus termination,
different kinds of network connectinos and common functions
(CT, O&M, alarms, external synch input and output and
Ethernet connectivity among controllers, etc)
" Two slots for NB controller
" Two slots for GE controller cards also compatible as NB LIM
slots
" Two slots compatible for Integrated ADM, GE uplink interfaces
and universal LIM slot

3.5.2 MLS-3F/MLS-3F4
MLS–3F and MLS–3F4 are foreseen to be used as Main for NLC
and HCL links, as Extender shelf only for NLC. One MLS–3F or
MLS–3F4 used as Extender for NLC can be used at the same time
as Main for HCL links.
MLS–3F and MLS–3F4 are composed of 23 slots. It can hold NB
and GE controllers, Aggregates, NB and GE LIMs, and I/O
interfaces. In these MLSs Front Access Area Section has been
gathered into Card Section, it means that the external connections
are made available in the own cards and plugs are not used. The
difference betwen MLS–3F and MLS–3F4 is only in the number
of slots available for server cards equipment. In MLS–3F there are
2 slots available for servers, and in MLS–3F4 there are up to 4
slots. There are also some restrictions for TT/LL cards in slots 4
and 5 of the MLS–3F version.
The MLS–3F and MLS–3F4 shelves are shown in the next figure:

152 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

30 mm

20 mm

20 mm
SLOT : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
POW3 – PEIC

LINA – TT – LIM – ANIT–A – NTIO

LINA – TT – LIM – ANIT–A – NTIO

NEHC–C – NBCB – NSEC–C

NEHC–C – NBCB – NSEC–C

VIS3 – TT – LIM – ANIT–A

VIS3 – TT – LIM – ANIT–A

VIS3 – TT – LIM – ANIT–A

VIS3 – TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A

TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A
TT – LIM – ANIT–A
GEB3 – TT – LIM

GEB3 – TT – LIM

Board Section
GIO3 – LIOC

A B

Figure 63 MLS–3F and MLS–3F4

The following rules are used in the configurations of the MLS–3F

and MLS–3F4:
" Slot 1
D These slots have a pitch of 30 mm.
D Slot with two cards for powering, network interfaces, NLC
bus termination, straps for MLS numbering, craft, O&M,
alarms, external synchronism I/O and Ethernet conectivity
among controllers.
D Following combinations are possible in this slot:
h PEIC / LIOC with 16xE1 network interface
h POW3 / GIO3 GE network interface (with
synchronism I/O restrictions)
h POW3 / LIOC with 16xE1 network interface (it could
need mechannical adaptations)
" Slots 2 and 3

3EC 41919 0001 TQZZA Edition 01 153 / 185

SYSTEM DESCRIPTION

D These slots have a pitch of 20 mm.

D Slots for NB controller in Main MLSs, or NB extender
when the MLS is used as Extension
D NB controller redundancy is supported. In single
controller configurations, the only controller can be
plugged into slot 2 or into slot 3
" Slots 4 and 5 (MLS-3F) and 4 to 7 (MLS-3F4)
D These slots have a pitch of 20 mm.
D Besides LIM cards, VoIP server, TT and ATM to Ethernet
cards can be located in this area
D VoIP server is VIS3 card
D TT card is PRC3 or SLT3, but by mechannical restrictions
SLT3 can not be equipped in the slots 4 and 5 of the
MLS–3F version
D ATM to Ethernet card is ANIT–A card, if it is equipped in
these slots it should be externally connected to GE
controller. Only one ANIT–A is necessary for the IWF for
both cases of GEB3 in single or redundant configuration
" Slots 6 to 11 (MLS-3F) and 8 to 11 (MLS-3F4)
D These slots have a pitch of 20 mm.
D Besides LIM cards, TT and ATM to Ethernet cards can be
located in this area.
" Slots 12 and 14
D These slots have a pitch of 20 mm.
D Besides NB LIM cards, GE controller and TT cards can be
located in this area
D GE controller is GEB3 card
D If TT card is SLT3, it should be placed in these positions
when clock extraction (usually in RU) is required
" Slots 13 and 15
D These slots have a pitch of 20 mm.
D Besides LIM cards, integrated ADM, TT, ATM to Ethernet
and GE uplink cards can be located in this area
D Integrated ADM is LINA card
D If TT card is SLT3, it should be placed in these positions
when clock extraction (usually in RU) is required

154 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

D These are the prefered slots for ANIT–A card location,

because if it is equipped in these slots it is internally
connected to GE controller positions
D GE uplink is NTIO card
" Slots 16 to 23:
D These slots have a pitch of 20 mm.
D Besides LIM cards, TT and ATM to Ethernet cards can be
located in this area.

3.5.3 Shelf Architecture

(1) Data Connectivity
The following paragraphs show the data connectivity of Litespan
MLSs. The following naming is used in the figures:
" NLC bus: NLC bus A is connected from one of the duplicated
NB controller position to all the line card position and so do
NLC bus B starting from the other NB controller position; both
of them are looped in the backplane and terminated in the
left side (PEIC/POW3 position); GE controller slots are
connected to the NLC buses as well since such positions are
NB LIM compatible
" Server Lines: The Server Bus is connected in parallel from the
controllers to some of the line card positions. Two server cards
can be allocated on the bus in MLS–3F and up to four in
MLS–3F4. The master of the Server Bus is always the NB
controller. Server bus is not available in the GE controller slot
positions
" NB Extender Interface: 51.84 Mbps links to the Lower
Extender MLS, extending the NLC bus. This connection starts
from the controller (or extender) front–plate card and is
terminated on the extender front–plate card of the
subtending shelf
" GE External Interface: A link for the external access of the
GE signals, foreseen on the GE controller slots. External
Network/Subtending interfaces are available in GE controller
front–plate, and are made available via backplane in NTIO
position
" Subscriber lines: subscriber lines are not tracked in the
backplane; the line connectors are directly available in the
front–plate of each line card

3EC 41919 0001 TQZZA Edition 01 155 / 185

SYSTEM DESCRIPTION

" Transport Card Slots: Special transport cards require special

slot positions
Fully new interfaces:
" 4 x HCL from/to each GE controller and each LINA/NTIO
positions; the 4 HCLs can be used as XAUI interface for 10GE
in the future
" Aditional 4xHCL links from each GE controller and its peer
LINA/NTIO position
Note Notice that this gives a total of 8xHCL from GE
controller to its peer NTIO and 4xHCL from GE
controller to the opposite NTIO
" 16 x E1 from/to PEIC to both LINA positions
" 16 x E1 external interfaces from/to NEHC–C positions are
made available in the PEIC. 16 x E1 available to LINA slots,
therefore a PEIC variant is needed routing them to the card
rear end towards the backplane to the NTIO/LINA positions
" HCL Lines: HCL Lines A are connected from one of the
duplicated GE controller positions, to each line card position
and so does HCL Lines B starting from the other GE controller
position. Each line is terminated on the Controllers and on the
related LIM of the MLS. The objective in HCL is to make these
lines compatible with up to 3.2Gbps. Also there are the
following HCL lines:
D 1 HCL interface from/to each NB controller and GE
controller slots. This is intended for data–plane
communication (for instance VoIP uplink when VoIP server
is integrated in the NB controller; nevertheless it could be
also used for control–plane communication if needed
D 4 x HCL (XAUI compatible) data–plane communication
between GE controllers slots. Additionally 8 differential
pairs are routed between both GE controller slots, but
their characteristics could be not fully compliant for HCL
GE
" HCL Extender Interface: Link to the Lower and Upper
Extender MLS’s, extending the HCL links. This connection,
when needed, is performed from the GE controllers (or
extender) front–plates (not available for the moment)

156 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

(2) Control Connectivity

" Diferential pairs: differential pairs (HCL type) in back–plane
from each controller position to an Ethernet switch in
LIOC/GIO3 position. The initial purpose is to use this hub for
distribution of O&M when received by one only external O&M
interface or via the O&M channel in SDH). This can be used
for any internal control plane communication among such
controllers in the future
" IAB bus: IAB bus is from NB controller and the IO cards
positions (LIOC/GIO3 and NTIO)
D IO interfaces for the GE subsystem are foreseen as well;
two interfaces are available between GE controller and
the NTIO positions: MDIO to support Ethernet PHYs and
I2C for SFP RI. SPI is available between GE controller and
LIOC/GIO3 positions; this is for future GE configuration
data or control of alarms
" NB/GE Peer Links: They are links foreseen for redundancy
operations between Active and Standby controllers.
D NB peer links: For NB controllers communication the
back–plane interface in MLS–3F/MLS–3F4 is AUI type
instead of differential pairs; NB controller uses FE
D GE: peer links are kept in MLS–3F/MLS–3F4; FE
communication for the A–B master selection indication
" RS 485 CT Interface: It is a bus that connects NB/GE
controllers, Server Cards for the internal transport of Craft
Terminal messages.
D Craft terminal port is located in LIOC/GIO3 cards and RS
485 interface is available between LIOC/GIO3 and NB
controller positions
D GEB3 has a local–craft only accessible via front–plate
D There exist the possibility (if requested in the future) to
implement a LIOC/GIO3 variant using one of the switch
ports as craft interface common to all controller elements
" SPI: SPI is foreseen between GE controller slots and
LIOC/GIO3 slot for future communication of alarms, RI and
installation data

(3) Other buses and interfaces

" External O&M Ethernet i/f: the Ethernet port is located in
LIOC/GIO3 position and connected to a switch there;
differential tx/rx pairs traced to NB controller instead of AUI.

3EC 41919 0001 TQZZA Edition 01 157 / 185

 SYSTEM DESCRIPTION

" G.703 External clock reference

" Rack and subrack number and types:
D The ”Broadband Subrack type”, the BB System/Rack type”
and the ”Broadband Rack number” tracks in the
backplane have been removed in MLS–3F/MLS–3F4.
They are not used in the NB subsystem, but they are used
in the GE subsystem
D In order to minimize impacts regarding the current
strategy/practice, such info is ”simulated” for the GEB3
card with default values. If new configurations are
possible in the future the information can be read from a
RI in LIOC/GIO3 via an SPI interface
D The ”Rack number” in the EFL3 card is internally
hardcoded
D Other straps: ”Subrack position” is made of SUB_POS0,
SUB_POS1 and SUB_POS2. The first two are kept as
they are common for both NB and GE subsystems and
currently used. SUB_POS2 is removed (never used
before). SUB–POS strapping is provided by PEIC/GIO3
card in MLS–3F/MLS–3F4
D For the future, if new subrack and rack types are
developed, it is foreseen to provide such info via an
EEPROM in the LIOC/GIO3 card and accessible to the
GE–CC via SPI interface
D On the other hand there is no way to distinguish the
MLS–3F from MLS–3F4. The new MLSs type (3F or 3F4)
should be declared by installation data

(4) MLS-3F/MLS-3F4 backplane connectivity

The following figure shows the MLS–3F/MLS–3F4 backplane
(data and control) conectivity. In red colour are represented the
diferences of MLS–3F4 with regard to MLS–3F.

158 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Figure 64 MLS–3F/MLS–3F4 backplane connectivity

(5) Mechanical Details

Shelf Dimensions a) MLS-3F/MLS-3F4:

D Height: 300 mm board area (it includes connection area
that are in the own cards)
D Width: 480 mm inside width – 515 mm between
mounting holes
D Depth: 250 mm
Both shelves are fully EMC shielded. This implies that all boards
have front covers with EMC shields and that empty positions have
dummy covers.

Backpanel " The backpanel is multilayer with controlled impedance; the

Characteristics external layers must have only the connector access and the
rest of the area must be filled with a ground plane (Safety
ground). This plane is done by a cross–hatching as dense as
required by the specific signals contained

3EC 41919 0001 TQZZA Edition 01 159 / 185

 SYSTEM DESCRIPTION

" The backpanel is protected using a rear cover

" The connectors to plug–in boards are metral, all male
press-fit. Connectors are 6x4 and 6x5 rows and, for high
speed signals, Metral 4000 connectors are foreseen. Some
6x4 metral connectors (sub–equipped to 12 pins) are
foreseen as well in slots #4 and #5
" No electrical components or devices are soldered onto the
backpanel.
" The thickness of the backpanel could be up to 2.7 +/–0.2
mm.
" Cabling access to the different interfaces are offered by the
boards themselves and not through the backpannel

PBA/Printed Board
" The PBA is obtained from a 1.6 mm thick multi–layer printed
Assembly board (PB), plugged into the BP by a metral, female, 4 or 5
row connector with pre–mating in the ground and power
pins to allow hot insertion/extraction with no impact
" The front plate is fitted with contact springs for screening
purposes; plastic frontcovers are used
" The solder side is located on the left when plugged, optionally
covered by a metallic plate. This plate is mounted only in case
of disturbances with neighboring boards. In such a case, a
cover for components side could also be provided
" In exceptional cases, only (Optical fibre, radio frequency
signals and unavoidable others) front cabling at the PBA front
plate is used. Caution should be taken in the design to allow
the doors of the rack/cabinet to be closed
PBA dimensions:
" 265 (H) x 213 (D) mm.

(6) Power Distribution

Powering of the MLSs is guaranteed for battery voltages of
nominal –48 V to –60 V.
The cards designed for all the MLSs derive the internal low or high
voltage(s) they need directly from battery voltage by means of an
on–board power converter. All cards feature power converters
with an input range of –38 V to –72 V and most of them feature
power converters with an extended input range of –20 V to –72
V that allow them to work in 24V battery powered systems.

160 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3.6 Housing

3.6.1 Indoor ETSI Rack

The maximum NB MLSA (MLS assembly for NB configurations)
consists of 4 MLSs (1 Main and 3 Extenders) dedicated to pure NB
or mixed NB/GE services.
The Indoor ETSI rack fulfills the following requirements:
" The mechanic design is according to ETSI standard ETS 300
119.
" External Dimensions:
D 2200 mm (Height) x 600 mm (Width) x 300 mm (Depth).
" This rack uses the PD1.x TRU as generic solution.
" Indoor ETSI rack must fit:
D The MLS Main and up to two Extenders or up to three
extenders.
D The Top Rack Unit (TRU). This unit, in the 4 MLSs rack
version is narrower.
D A Fiber Tray for up to 16 fibers.
D Fan units (If required).
" EMC at rack level is not required since the compatibility is
obtained at MLS level.
" Compliant to climatic normative/standard ETS 300 019, class
3.2.
The Indoor ETSI rack for four MLSs is depicted in Figure 65.

3EC 41919 0001 TQZZA Edition 01 161 / 185

SYSTEM DESCRIPTION

INDOOR CONFIGURATION
Battery_A
TRU Battery for signalling
Battery_B

Extenders and LIMs

MLS Extension
FANS

Extenders and LIMs

MLS Extension

Extenders and LIMs

MLS Extension
FANS

Controllers and LIMs TARCB

By default:
MLS Main
TARCB: 1 in MLS main

Figure 65 Physical Layout Indoor Racks for 4 MLSs (Example)

162 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3.6.2 Outdoor Cabinets

The outdoor cabinet structures for Litespan–1540 products are
depicted in Figure 66 and Figure 67:

OUTDOOR CONFIGURATION

FANS

BHCP3

TARCB
Controllers and LIMs

MDF
BREAKERS MLS Main
Power

BCBP HEATERS

By default: BATTERY PACK CABLE

TARCB: 1 equipped INPUT
BHCP3: 1 per MLS
220Vac
Emergency

Figure 66 Physical Layout 1 MLS Outdoor Cabinet

OUTDOOR CONFIGURATION
FANS
BHCP3
BHCP3

TARCB

Controllers and LIMs

MLS Main
BREAKERS
MDF
BCBP

Extenders and LIMs

MLS Extension

Power HEATERS

By default: BATTERY PACK CABLE

TARCB: 1 equipped INPUT
BHCP3: 1 per MLS
220Vac
Emergency

Figure 67 Physical Layout 2 MLS Outdoor Cabinet

3EC 41919 0001 TQZZA Edition 01 163 / 185

SYSTEM DESCRIPTION

The cabinets are divided into three different areas:

" Electronic area.
" Batteries area.
" Main Distribution Frame (MDF) area.
The electronic area hosts the MLSs, the Power Supply and the Fans.
The Power Supply unit features the Mains entry, the breakers, the
AC/DC converters and the Battery Controller device.
The MDF area hosts the MDF connectors, the cables entry and
also the Optical Distribution Frame (ODF).
The cabinet dimensions are given below. Nevertheless, they can
change according to customer specifications for the MDF type of
connectors that may impact in the MDF room size for all the
supported lines:
1 MLS cabinet: 1200 (W) x 1200 (H) x 500 (D).
Primary MDF for 450 pairs and 1.3:1 ratio
for the secondary MDF.
2 MLSs cabinet: 1350 (W) x 1500 (H) x 500 (D).
Primary MDF for 990 pairs and 1.3:1 ratio
for the secondary MDF.
The cabinets are compliant to the following Normatives /
Standards:
" EN 60950, EN 41003 – SAFETY.
" ETSI 300 386 –1 –EMC. Note EMC is also fulfilled at
subrack level.
" IEC 144/63 (Protection Level IP55 in the Electronic area).
" IEC 144/63 (Protection Level IP45 in MDF and Cable entry).
" IEC 144/63 (Protection Level IP33 in the battery box).
" ETS 300 019 class 4.1.E and class 3.3.
The following main features are supported:
" Heaters to start–up at low temperatures and to maintain the
batteries efficiency.
" Water protection from the base of the cabinet (300mm).
" Electronic, batteries and MDF rooms with front access.

164 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" Each area (Electronic, batteries and MDF) is locked

independently.
" Open doors detection alarm.
" Anti–vandalism protection.

3EC 41919 0001 TQZZA Edition 01 165 / 185

 SYSTEM DESCRIPTION

3.7 Printed Board Assemblies for MLS

Refer to 3EC 41920 0001 TQZZA.

3.8 HW Qualification
The purpose of HW Qualification is to test the equipment for
compliance with the normative of international standards and so
to assure its fully compatibility with EMI/EMC, Climatic,
Mechanical, Safety and Overvoltage/overcurrent protection.

3.8.1 Housing Requirements

(1) General Features (Standards)
" Regulative Environmental (ETS 300.019). The classes for
operational used are identified in this section.
" CE labelling at Subrack level.
" Regulative Safety (EN 60950). IEC 529.
" Generic transport environmental conditions: ETS
300.019–2–2 Class 2.3: Careful transportation.
" Generic storage environmental conditions: ETS
300.019–2–1 Class 1.1: Weather protected, no
temperature–controlled storage locations.

(2) Installation Environment

The installation environment for the Equipment Under Test (EUT) is
normally the ’telecommunication center’.
Locations ’other than the telecommunication center’ are applied
where the EUT must be operated outside a telecommunication
center, e.g., within offices, customers premises or streets.
Equipment which meets the requirements (More severe) for ’other
than telecommunications centers’ may be operated in any
location.
The Installation Environment can be:
" TELECOMMUNICATION CENTER.
" INDOOR OTHER THAN TELECOMMUNICATION CENTER.
" OUTDOOR OTHER THAN TELECOMMUNICATION CENTER.
Each one from the protective point of view depends on:

166 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

" ENCLOSURE PORT:

The physical boundary of the Equipment Under Test (EUT)
through which electromagnetic fields may emanate or on
which they may impinge.
" SIGNAL LINE PORT
This port is an OUTDOOR SIGNAL LINES PORT.
" POWER PORT:
A power source to which telecommunication equipment is
intended to be connected. These port may be AC POWER
PORT and DC POWER PORT.

(3) Telecommunication Centers

Protection levels:
" ENCLOSURE PORT.
" OUTDOOR SIGNAL PORTS.
" DC POWER PORT.
The Normatives to be applied are:
" CE labelling at Subrack level.
CLIMATIC AND MECHANICAL PROTECTIONS
" ETS 300.019 – 2 –3: Class 3.2: Temperature– controlled
locations (–5ºC to +45ºC).
This specification is applied to enclosed locations having
neither temperature nor humidity control, but where heating
may be used to avoid low temperatures.
" IEC 529: All mechanical housing areas must comply with the
Protection Level IP32.
SAFETY REQUIREMENT
" EN 60950 modified with Amendments 4: Safety of
information technology equipment, including electrical
business equipment.

(4) Indoor other than Telecommunication Center

Protection levels:
" ENCLOSURE PORT.
" OUTDOOR SIGNAL PORTS.
" AC POWER PORT.
The Normatives to be applied are:
" CE labelling at Subrack level.

3EC 41919 0001 TQZZA Edition 01 167 / 185

 SYSTEM DESCRIPTION

CLIMATIC AND MECHANICAL PROTECTIONS

" ETS 300.019 – 2 –3: Class 3.3 + solar load: Not
temperature– controlled locations (–25ºC to +55ºC, but
with solar load until +70ºC).
This specification is applied to weather protected or partially
weatherprotected locations having neither temperature nor
humidity control.
" IEC 529: All the mechanical areas in the housing must comply
with the Protection Level IP32.
SAFETY REQUIREMENT
" EN 60950 modified with Amendments 4: Safety of
information technology equipment, including electrical
business equipment.

(5) Outdoor other than Telecommunication Center

Protection levels:
" ENCLOSURE PORT.
" OUTDOOR SIGNAL PORTS.
" AC POWER PORT.
The Normatives to be applied are:
" CE labelling at Subrack level.
CLIMATIC AND MECHANICAL PROTECTIONS
" ETS 300.019 – 2 –4: Class 4.1 E: Not– weatherprotected
locations extended (–45ºC to +45ºC).
This specification is applied in many ETSI countries.
SAFETY REQUIREMENTS
" EN 60950 modified with Amendments 4.: Safety of
information technology equipment, including electrical
business equipment.
" IEC 529: The protection levels to comply are:
D Electronic area: IP55
D MDF area: IP45
D Battery area: IP33
D Global protection to mark the cabinet is IP54.

168 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3.8.2 Subrack Common Requirements

" EMI/EMC: (CE labelling + Resistibility).
EN 300.386 – 2 V1.1.3 (1997).
The Resistibility is the ability of a telecommunication
equipment or a network to withstand the effects of certain
electrical, magnetic and electromagnetic phenomena up to a
certain, specified extent, and in accordance with a specified
criterion, e.g., the ability of a telecommunication device to
withstand a surge voltage of 2 KV on its 230 V AC power port
without being damaged.
With respect to the resistibility for the ENCLOSURE PORT, the
EN 61000–4–2 is applied for Electrostatic Discharge
(Surges). For the SIGNAL PORT S is K.20. For the DC POWER
PORT is NA. For the AC POWER PORT is 61000–4–5.
" CE Compliance at Subrack level. (Resistibility:
EN61000–4–2)
" Safety at Subrack level EN 60950 modified with
Amendments 4.
" CO/RU equipments to meet ETS 300–019–2–4
Class 4.1 E.

3.8.3 Boards Common Requirements

" Safety at Subrack level EN 60950 modified with
Amendments 4.
" Industrial temperature range (–25ºC to +80ºC).
" Hot insertion. The insertion / extraction of the board will not
cause any power disturbances in any other board.

3.8.4 Board Specific Requirements

The requirements applicable for SHDSL CPNT housings are :
" Security: EN60950
" EMI/EMC: ETS 300 386 V1.2.1 (2000–03) (Other than
telecom centers)
" Protection/Resistibility: K.45 Enhanced– For SHDSL port.

3EC 41919 0001 TQZZA Edition 01 169 / 185

 SYSTEM DESCRIPTION

" Environmental: ETS 300 019 Class 4.1E and 3.3 (–25 to 80
ºC forced convection)

Note The environmental requirement is defined at equipment

level

3.8.5 Specific SHDSL CPNT Housing Requirements

The requirements applicable for SHDSL CPNT housings are:
" Security: EN60950
" EMI/EMC: ETS 300 386 V1.2.1 (2000–03) (Other than
telecom centers)
" Protection/Resistibility: K.45 Enhanced– For DSL port
" Environmental: ETS 300 019 Class 3.2
" Degree of protection: IEC 529 (IP32) (note: current UTR
design supports only IP30.

170 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3EC 41919 0001 TQZZA Edition 01 171 / 185

 SYSTEM DESCRIPTION

4 Litespan Card and MLS Compatibility

4.1 Card Compatibility

Line Card compatibility between consecutive Litespan–1540
families is required. Thus, some cards of a given family are
compatible with those from the previous one and some others are
compatible with those from the next one. Specifically, any
Litespan–1540 family has:
" Cards A: The card set is specific to the family, so they are not
used in the previous family
" Cards B: The card set is developed from those used in the
previous family, in which they can also work without
restrictions. Eventually, these B variants could replace, in a
progressive way, the former cards from the previous family.
" Cards C1: The card set is developed for the family, but can
also work in the previous one.
" Cards C2: The same set as C1, but different variants are
specific to the family preparing the decoupling with the
previous family and allowing compatibility with the next one.

4.1.1 SW Compatibility
The SW delivered for a given family is required to work without
restrictions (except the services not supported) in the previous
family.

172 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

4.2 MLS Compatibility

MLSs are designed to support the following compatibilities:
" MLS uses the same board size and connector type as the
shelves used in the previous release
" MLS uses the same pinning as the shelves used in the previous
release for all narrowband signals, so that all NB line cards
designed for the previous release can be reused

3EC 41919 0001 TQZZA Edition 01 173 / 185

 SYSTEM DESCRIPTION

5 LIST OF ABBREVIATIONS
ADM Add/Drop Multiplexer
ADSL Asymmetric Digital Subscriber Line
AIS Alarm Indication Signal
A 1353 DNLitespan–1540 NB element manager
AMI Alcatel Management Interface
AMS Alcatel Management System (BB element manager)
AN Access Network
ANd Access Node
AP Access Point
ATL3 Analog Telephone Line Card
ATLC Analog Telephone Line Card
BA Basic Access
BAL3 Basic Access Line Card
BB BroadBand
BB-NM Broad Band Network Management.
BCC Bearer Channel Connection [protocol]
BER Bit error Rate
BER Basic Encoding Rules (ASN.1)
BW BandWidth
CAFE CAMINA Front End
CAMINA Common Alcatel Management Interface for Nodes in
the Access Network
CC Communication Channel

174 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

CCEL Central Controller Equipment Layer

CCFE Craft terminal Central controller Front End
CDE Customer Design Engineering
CHDLC HDLC multichannel Controller
CLNP Connection Less Network Protocol
CMISE Common Management Information Services Element
CNCL Central controller Narrowband Connection Layer
CNTL Central controller Narrowband Transmission Layer
CO Central Office
CP Connection Point
CPE Customer Premises Equipment
CPNT Customer Premises Network Termination
CRC Cyclic Redundancy Check
CT Craft Terminal
CTP Connection Termination Point
DCC Data Communication Channel
DCN Data Communications Network
DECT Digital European Cordless Telecommunication
DLC Digital Loop Carrier
DN Directory Number
DSL Digital Subscriber Line
DSP Digital Signal Processor
DTMF Dual Tone Multiple Frequency
EFL3 Ethernet First–mile Line Card
EM Element Manager
EMC Electro–Magnetic Compatibility
EML Element Manager Layer
EOC Embedded Operations Channel
ETSI European Telecommunication Standards Institute
EU Exchange Unit
FE Fast Ethernet
FPGA Field Programmable Gate Array
FW FirmWare

3EC 41919 0001 TQZZA Edition 01 175 / 185

SYSTEM DESCRIPTION

GDMO Guidelines for the Definition of Managed Objects

GE Giga Ethernet
GEB3 Giga Ethernet Controller Card
GIO3 Giga Ethernet Input Output Card
GND GrouND
GW GateWay
HSO Hot SwitchOver
HTTP HyperText Transfer Protocol
HW HardWare
I/F InterFace
I/O Input/Output
IAB Inventory Access Bus
IEEE Institute of Electrical and Electronical Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
ISDN Integrated Services Digital Network
ISO International Standards Organization
ISP Internet Service Provider
ITU International Telecommunication Union
LAN Local Area Network
LAP Link Access Protocol
LAPB Link Access Protocol – Balanced
LAPD Link Access Protocol for ISDN D–channel
LAPV5 Link Access Protocol for V5 interface
LAPVA Link Access Protocol for VA interface
LC Line Card
LE Local Exchange
LED Light Emitting Diode
LIM Line Interface Module
LIOC Local Input Output Card
LL Leased Lines
LOF Loss Of Frame
LOS Loss Of Signal

176 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

LT Line Termination
MAC Medium Access Control [sublayer]
MDF Main Distribution Frame
MG Media Gateway
MGC Media Gateway Controller
MIB Management Information Base
MLS Multiservice Line Shelf
MLSA MLS Assembly (stack)
NB NarrowBand
NB-NM Narrow Band Network Management.
NBCB NarrowBand Controller Board
NE Network Element
NEHC-C Narrowband Element Handler Card
NGN Next Generation Network
NLC Narrowband Line Card
NM Network Management
NNI Network–Node Interface
NSEC-C NB Extender Card
NT Network Termination
NTIO Network Termination Input Output Card
OAM Operations, Administration and Maintenance
OBC On–Board Controller
OS Operations System
OSF Operations System Function
OSI Open Systems Interconnection
OTRP Object–oriented Transaction, Redundancy and
Persistency
PEIC Plug and E1 Interface Card
PBA Printed–Board Assembly
PCB Printed Circuit Board
PDH Plesiochronous Digital Hierarchy
PDU Protocol Data Unit
PM Performance Monitoring

3EC 41919 0001 TQZZA Edition 01 177 / 185

SYSTEM DESCRIPTION

PNNI Private Network Node Interface

POTS Plain Old Telephone Service
POW3 Plug compatible with GIO3 Card
PPP Point–to–P oint Protocol
PRA Primary Rate Access
PRC3 Primary Rate Channel Card
PSTN Public Switched Telephone Network
PTSL PSTN Service Layer
PWR PoWeR
QA Q Adaptor
QAF Q Adaptor Function
QoS Quality of Service
RAI Remote Alarm Indication
RAM Random Access Memory
RAMI Remote Alcatel Management Interface
RDI Remote Defect Indicator
RI Remote Inventory
ROSE Remote Operation Service Element
RPC Remote Procedure Call
RU Remote Unit
RX Receive
SDH Synchronous Digital Hierarchy
SHDSL Single–pair High–speed Digital Subscriber Line
SIP Session Initiation Protocol
SLT3 SHDSL Line Termination Card
SN Service Node
SNCP SubNetwork Connection Protection
SNI Subscriber Network Interface
SNMP Simple Network Management Protocol
SOS Standalone Operation Mode
STM Synchronous Transfer Mode
SWBB SoftWare Building Block
SW SoftWare

178 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

TCP Transmission Control Protocol

TFTP Trivial File Transfer Protocol
TL1 Transaction Language 1
TMN Telecommunication Management Network
TRU Top Rack Unit
TS Time Slot
TT Transport Termination
TTP Trail Termination Point
TX Transmit
UDP User Datagram Protocol
UNI User–Network Interface
VA V Alcatel [interface] (Alcatel proprietary protocol based
on V5 ETSI standard)
VADL VA DownLoad [protocol]
VIS3 Voice over IP Server Card
VoIP Voice over Internet Protocol
WSO Warm SwitchOver

3EC 41919 0001 TQZZA Edition 01 179 / 185

SYSTEM DESCRIPTION

6 GLOSSARY / TERMINOLOGY
Administrative state:
The administrative state attribute indicates permission or
prohibition to use the resource imposed by the system
management (Operator).
The administrative state represents the state of a managed object
as imposed by the management. It is independent from the
operational state and cannot be changed autonomously by the
managed object under normal conditions.
The administration of a resource is described by the administrative
state attribute, which has two possible values:
" Locked: The resource is administratively prohibited from
performing services for its user(s).
" Unlocked: The resource is administratively permitted to
perform services for its user(s). It is independent of its inherent
operability.
Alarm:
Notification sent to the management system OS/CT, and signalled
in the equipment (Rack, board) LED indicating a failure or
anomaly requiring a maintenance action. The clearance of the
alarm condition has to be signalled as well.
The alarm information contains many parameters such as Alarm
type or category, probable cause, perceived severity,...

180 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Alarm hierarchy:
Category of alarms regarding their priority in its reporting to the
OS. Root alarm has high priority, while dependent alarms have
less priority. When several alarms are raised within a persistency
timing period, only the highest priority alarm is reported in the
notification to the OS.
Anomaly:
Discrepancy between the actual and desired characteristics of an
item.
Current alarm summary control (CASC):
It provides the criteria to generate current alarm summary reports
of the higher (In the hierarchy) active alarms related to an object.
Current problem list (CPL):
List of the higher (In the hierarchy) active alarms related to an
object.
Defect:
When the density of anomalies has reached a level in which the
ability to perform the required function has been interrupted. They
manifest in errors.
Equipment protection:
This is the protection against internal equipment failures, usually
board failures. The equipment protection is applied to increase the
equipment availability. In case of failure, the protection action
circumvents the problem area and restore the service
consequently. The service interruption is thus restricted to the time
it takes to complete the protection action, and becomes
independent of the ’ time to repair’. Within the Litespan–1540
context, the equipment protection focuses on protecting the
Central controller and FR server boards.
Error:
Deviation of a system from normal operation.
Failure:
Fault cause that has persisted long enough to consider the item as
unable to perform its function.
Fault:
Physical or algorithmic cause of a malfunction resulting in the
inability of a function to perform a required action. They manifest
in errors.

3EC 41919 0001 TQZZA Edition 01 181 / 185

SYSTEM DESCRIPTION

Functional area:
It is a set of requirements related to a function that can be
implemented in one or several subsystems.
Homes passed:
This is the basic dimensioning unit used by Litespan–1540. The
number of homes passed in an access network reflects the
number of connections that are within reach of the access network
or network component.
Layer:
An end– to– end system wide collection of software (i.e., over multiple
boards). Some layers have been further divided in sublayers. As SW is
organized along SWBBs, a (Sub) layer is a set of SWBB.
Subsystem = sublayer
Log:
It provides the storage of events and notifications in the NE. It is
useful for the OS to re–synchronize with the NE status after a
period of interrupted communication between them.
Naming conventions :
" 4 letter names are used to refer to a building block.
" A fifth letter (A,B, ..) after a dash is used to differentiate
among different versions of the same device.
" All PBAs in the MLS end on a ”C” (Mnemonic for ”Card”).
" All drivers end on ”DR”.
" Building blocks in the service layer end on ”SL”.
" Building blocks in the connection layer end on ”CL”.
" Building blocks in the transmission layer end on ”TL”.
" Building blocks in the equipment layer end on ”EL”.
" Building blocks in the Management Front end layer end on
”FE”.
Network component:
It refers to an equipment with a complete network function, that
cannot be splitted in minor units, positioned in a geographically
identified part of the network. Some examples of network
components are Access Nodes (Compact DLC, Exchange Unit, or
Remote Unit) or a CPNT.

182 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

Network protection:
This is a protection against network failures, such as cable cuts.
Within the Litespan–1540 context, the network protection focuses
on protecting the interface to the service network, and internal
interfaces within access network components.
Number of lines:
The number of individual physical connections bearing a service
towards subscribers that one Litespan–1540 component is
designed for. For the POTS service, for instance, it is the number of
twisted pairs, while for the 2 Mbit/s G.703 service is the number
of couples of twisted pairs.
Operational state:
The operational state attribute indicates whether or not the
resource is physically installed and working.
It is the natural operation of the resource that causes operational
state transitions to occur, and therefore, management cannot
request a managed object to change from one operational state
to another. Management can only gather information about the
operational state of a managed object by the events notified by it
(Or requested by means of the operation ’get’ from
management).
The operability of a resource is described by the operational state
attribute, which has two possible values:
" Disabled: The resource is totally inoperative and unable to
provide service to the user(s).
" Enabled: The resource is partially or fully operational and
available for use.
Service Node:
A unit, located in a central position in the network, delivering a
service to the access part of the network.
Service penetration:
For each service, the operator deploying Litespan–1540
determines which penetration is supported. The service
penetration is expressed in percentage of the homes passed. For
operators in a monopolistic situation, for instance, the POTS
service penetration can be as high as 120% with 5% broadband
penetration, while for second access operators, the POTS
penetration might be only 20%, while broadband penetration
goes up to 40%.

3EC 41919 0001 TQZZA Edition 01 183 / 185

SYSTEM DESCRIPTION

Software building block (SWBB):

The smallest SW unit under configuration control and with
attached documentation. An instance of a software building block
is constrained to run on a single PBA and, in most cases, on a
single processor.
Confusion between functional area and subsystem could possibly
arise since, for each subsystem, there is also a functional area with
the same name. However, it is very important to note that,
although most of the requirements of a certain functional area are
implemented in the subsystem with the same name, it is very
possible that these requirements are partially implemented by
other subsystems.
Terminology related to OAM :
The terminology is used according to ETS 300 417–1–1, and X.
731.

184 / 185 3EC 41919 0001 TQZZA Edition 01

 SYSTEM DESCRIPTION

3EC 41919 0001 TQZZA Edition 01 185 / 185