411 9001 126.14.10_BSC TCU e3 Reference Manual

Wireless Service Provider Solutions

BSC/TCU e3 Reference ManualPE/DCL/DD/0126 14.10/EN Standard July 2004411--9001--126

< 126 > : BSC/TCU e3 Reference Manual

Wireless Service Provider Solutions

BSC/TCU e3 Reference ManualDocument number: PE/DCL/DD/0126

411--9001--126Document status: StandardDocument issue: 14.10/ENProduct release: GSM/BSS V14.3Date: July 2004

Copyright 2000--2004 Nortel Networks, All Rights Reserved

Originated in France

NORTEL NETWORKS CONFIDENTIAL:

The information contained in this document is the property of Nortel Networks. Except as specifically authorized inwriting by Nortel Networks, the holder of this document shall keep the information contained herein confidential andshall protect same in whole or in part from disclosure and dissemination to third parties and use for evaluation,operation and maintenance purposes only.

You may not reproduce, represent, or download through any means, the information contained herein in any way or inany form without prior written consent of Nortel Networks.

The following are trademarks of Nortel Networks: *NORTEL NETWORKS, the NORTEL NETWORKS corporate logo,the NORTEL Globemark. GSM is a trademark of France Telecom.

All other brand and product names are trademarks or registered trademarks of their respective holders.

Publication HistoryNortel Networks Confidential iii

BSC/TCU e3 Reference ManualCopyright E 2000--2004 Nortel Networks

PUBLICATION HISTORY

System release: GSM/BSS V14.3

July 2004

Issue 14.10/EN Standard

Final cleanup and publication activities

July 2004


Final cleanup and publication activities

June 2004

Issue 14.08/EN Preliminary

Updated according to the following feature:

24961: S12000 dual band 850/1900 E1

December 2003


Update according to CR Q00732635--04

Update according to CR Q00794268

November 2003


For CR Q00767318, added hot insertion note to Chapter 5 and hot extraction noteto Chapter 6.

Update Chapter 4 to resolve Q00767079.

April 2003


Minor editorial update

Publication History Nortel Networks Confidentialiv

PE/DCL/DD/0126411--9001--126

July 2004 Copyright E 2000--2004 Nortel NetworksStandard 14.10/EN

January 2003


The following features were integrated into this document for V14.3 Release:

SV713: AMR Full Rate

SV885: AMR Half Rate

SV1322: TTY support on BSC/TCU e3

AMR 850Mhz

The following changes were made in individual chapters in accordance with theinternal comments taken into account:

Chapter 1:

• removed the hubs outside the cabinets and the redundant Ethernet link ontoOMU module

• updated the LED display description of the BSC/TCU e3 cabinets

Chapter 4:

• modified the OAM and CallP architecture

• added the new upgrade type according to MIB content and BSC softwarechanges

• added the new ’Generic Access’ interface

Chapter 8:

• updated the software description with the delivery package list

New function (AMR, TTY) integrated in TMG, DSP functions and TRM module(Chapters 4 and 7)

Minor editorial update carried out in Chapters 1, 2 and 4

November 2002


Creation

The following features were integrated into this document for V14.3 Release:

AR1209--4b1: BSC/TCU e3 SW marking consultation from OMC--R

AR1209--11: Build on--line on BSC e3

AR1209--17: Plug and play on BSC e3

AR1209--30a2: TCU e3 upgrade

Publication HistoryNortel Networks Confidential v


PR439: TCU e3 product

PR440: BSC e3 product

PR440--8: BSC e3 Overload

PR440--13: BSC e3 Erlang capacity

PR440--20a: Support of two TCU e3 on one BSC e3

PR440--20b: Support of mix TCU 2G/e3 on one BSC e3

PR440--20c: Creation/deletion on--line on TCU e3

PR1062: Support of TCU 2G on BSC e3

UP1286--3b: BSC e3 upgrade

BSC e3 1000 TRX capacity

e--GSM support on BSC e3

Publication History Nortel Networks Confidentialvi

PE/DCL/DD/0126411--9001--126


System release: GSM/BSS V13

September 2002


Minor editorial update

June 2002


Updated the connection between the OMC--R and the BSC e3 via optional HUBs.

Added the new figure which describes an example of two 8--port optional HUBs.connected to the BSC/TCU e3.

Added Plug and Play modules.

March 2002


Updated according to SR NW12063.

Updated the description of the visual indicators on the front panel of the BSC e3cabinet (LED display).

Updated figure TMG functional organization with a PCUSN and a TCU e3.

Removed the information relating to Ethernet link redundancy between OMC--Rand BSC e3.

November 2001


Added the new handover in paragraph 4.3.2.4 section “TMG description”.

Added an introduction to OBS (Observations) in paragraph 4.3.2.4.

July 2001


Update after review

Publication HistoryNortel Networks Confidential vii


June 2001

Issue 13.03/EN Draft

Added GPRS features in chapters 1,2,3,4,6 and 8.

Added RPP and SPP features in chapter 4.

Added DTM and STCH features in chapter 4.

October 2000


Update after review

September 2000

Issue 13.01/EN Draft

Creation.

Table of contents Nortel Networks Confidentialviii

PE/DCL/DD/0126411--9001--126


About this document 0--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Applicability 0--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Audience 0--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Prerequisites 0--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Related Document 0--2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

How this document is organized 0--2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Regulatory information 0--3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 Hardware Description 1--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.1 Physical characteristics 1--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Electric power supply 1--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Mechanical structure 1--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.1 BSC e3 and TCU e3 frame overview 1--4. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.2 SAI frame overview 1--7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.3 HUBs overview 1--8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 BSC e3 and TCU e3 frame description 1--10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1 Dual--shelf assemblies 1--10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.2 Power supply and alarm systems 1--21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.3 Cooling system 1--30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5 SAI frame description 1--34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.1 CTU module description 1--34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6 BSC e3 and TCU e3 cabinet cabling 1--51. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6.1 BSC e3 cabinet 1--51. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6.2 TCU e3 cabinet 1--59. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Physical architecture 2--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.1 Hardware structure 2--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 BSC e3 2--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2 TCU e3 2--3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Hardware modules 2--5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1 Control Node 2--5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2 Interface Node 2--6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.3 Transcoder Node 2--7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Physical interfaces 2--8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.1 Interface within the Control Node 2--9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.2 Interfaces between the Control Node and the Interface Node 2--11. . . . . . . .

Table of contentsNortel Networks Confidential ix


2.3.3 Interface within the Interface Node 2--11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.4 Transcoder Node interfaces 2--13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Protocol Architecture 3--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.1 Protocol used for communication between the OMU modules and the

OMC--R 3--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1 Protocol used for communication between each node inside the BSC e3 andthe TCU e3 and between each BSS product 3--4. . . . . . . . . . . . . . . . . . . . . .

3.1.2 Protocol used for communication between each node inside the BSC e3 andthe PCUSN and between each BSS product 3--9. . . . . . . . . . . . . . . . . . . . . .

3.1.3 Overview and conclusion 3--13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Functional Architecture 4--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.1 BSC e3 functional design 4--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.1 Overview 4--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.2 BSC e3 functional characteristics 4--3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 TCU e3 functional design 4--6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.1 Overview 4--6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.2 TCU e3 functional characteristics 4--8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Architecture presentation 4--9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.1 OAM architecture 4--9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.2 CallP architecture 4--79. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 GSM BSC/TCU e3 Synchronization requirements 4--102. . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.1 Overview 4--102. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.2 Standards compliancy and detailed requirements 4--102. . . . . . . . . . . . . . . . . .

5 Control node description 5--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.1 OMU module 5--2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.1 External interfaces 5--4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.2 Electrical characteristics 5--4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.3 Functional description 5--5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.4 Hot swap removal request and action 5--11. . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 TMU module 5--12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




5.3 ATM--SW module 5--19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Table of contents Nortel Networks Confidentialx

PE/DCL/DD/0126411--9001--126




5.4 MMS modules 5--26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



5.4.3 Functional block description 5--28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4.4 Hot swap removal request and action 5--30. . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.5 SIM module 5--30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.6 FiIler module 5--30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Interface node description 6--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.1 CEM module 6--4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



6.1.3 Functional Blocks 6--6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 ATM--RM module 6--9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




6.3 8K--RM module 6--14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




6.4 LSA--RC module 6--18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.1 IEM module 6--23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.2 RCM 6--33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.3 TIM module 6--35. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.5 SIM module 6--39. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.6 FiIler module 6--39. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Transcoder node description 7--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7.1 CEM module 7--4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 TRM module 7--4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




Table of contentsNortel Networks Confidential xi


7.3 LSA--RC module 7--9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4 SIM module 7--9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.5 FiIler module 7--9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 Software Description 8--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8.1 Software architecture 8--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2 Layered architecture presentation 8--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3 Customer software package deliveries 8--5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3.1 Control Node 8--5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3.2 Interface Node 8--10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3.3 Transcoder Node 8--10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 Dimensioning 9--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of figures Nortel Networks Confidentialxii

PE/DCL/DD/0126411--9001--126


Figure 1--1 BSC e3 cabinet presentation 1--2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--2 TCU e3 cabinet presentation 1--3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--3 BSC e3 cabinet: component layout 1--5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--4 TCU e3 cabinet: component layout 1--6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--5 Example of two 8--port optional HUBs connection with BSC/TCU e3 cabinet 1--9

Figure 1--6 BSC e3 frame: front view 1--11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--7 TCU e3 frame: front view 1--12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--8 Control Node: common architecture inside each module 1--13. . . . . . . . . . . . . . . . .

Figure 1--9 Interface Node or Transcoder Node: common architecture inside each RM 1--15.

Figure 1--10 Generic module view 1--16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--11 Module front panel indicators 1--17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--12 FILLER module: hardware overview 1--20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--13 PCIU: hardware overview (BSC e3) 1--22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--14 PCIU: hardware overview (TCU e3) 1--23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--15 ALM module: functional blocks 1--25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--16 FMU module: functional blocks 1--26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--17 SIM module: hardware overview 1--28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--18 SIM module : functional blocks 1--29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--19 Cooling air flow diagram inside the BSC e3 or TCU e3 frame assembly 1--31. . . .

Figure 1--20 Cooling unit: hardware overview 1--32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--21 Fan unit: hardware overview 1--33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--22 SAI: hardware overview 1--35. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--23 CTU module: left side view with a CTB and CTMPs (PCM E1 120 ohms) 1--36. .

Figure 1--24 CTU module: right side view with a CTB and CTMDs (PCM T1 110 ohms) 1--37.

Figure 1--25 CTB physical representation 1--39. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--26 CTB component layout 1--40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--27 SUBD 62--pin connector on CTB 1--41. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--28 CTMP board: hardware overview 1--43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--29 CTMP board: components layout 1--44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--30 CTMP board: SUBD 25--pin connector 1--44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--31 CTMC board: hardware overview 1--46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--32 CTMC board: components layout 1--47. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--33 CTMC board: SUBD 8--coax connector 1--47. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--34 CTMD board: hardware overview 1--49. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--35 CTMD board: component layout 1--50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of figuresNortel Networks Confidential xiii


Figure 1--36 CTMD board: SUBD 25--pin connector 1--50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--37 BSC e3: optical fibers cabling 1--52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--38 BSC e3: optical fiber cabling 1--53. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--39 ATM--SW module: optical fibers plug--in 1--54. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--40 ATM--RM module: optical fibers plug--in 1--55. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--41 BSC e3: PCM internal and external cabling for maximal configuration 1--56. . . . .

Figure 1--42 BSC e3: -- 48 Vdc and alarms cabling 1--57. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--43 BSC e3: cabling to/from both optional HUBS 1--58. . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1--44 TCU e3: PCM internal and external cabling for maximal configuration 1--60. . . . .

Figure 1--45 TCU e3: -- 48 Vdc and alarms cabling 1--61. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 2--1 BSC e3 cabinet: physical architecture 2--2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 2--2 TCU e3 cabinet: physical architecture 2--4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 2--3 BSC e3 frame: alarms cabling 2--10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 2--4 Interface Node: S--Link distribution 2--12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 2--5 TCU e3 frame: alarms cabling 2--14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 3--1 Protocol architecture: between the OMC--R and the BSC e3 cabinet 3--2. . . . . .

Figure 3--2 Protocol architecture: between each node within a BSC e3 and a TCU e3 3--5. .

Figure 3--3 Protocol architecture between each BSS product within a BSC e3 and a TCUe3 3--6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 3--4 Protocol architecture: between each node within a BSC e3 and a PCUSN 3--10. .

Figure 3--5 Protocol architecture between each BSS product within a BSC e3 and aPCUSN 3--11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 3--6 Protocol architecture inside a BSS with a TCU e3: overview 3--14. . . . . . . . . . . . . .

Figure 3--7 Protocol architecture inside a BSS with a PCUSN: overview 3--15. . . . . . . . . . . . . .

Figure 4--1 BSC e3 and TCU e3: OAM architecture 4--10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 4--2 BSC e3 (Control Node): “OMC--Com” functional group 4--15. . . . . . . . . . . . . . . . . .

Figure 4--3 BSC e3 (Control Node): AOM services functional group 4--18. . . . . . . . . . . . . . . . .

Figure 4--4 BSC e3 (Control Node): supervision functional group 4--24. . . . . . . . . . . . . . . . . . . .

Figure 4--5 BSC e3 (Control Node): C--Node_OAM functional group organization 4--28. . . . .

Figure 4--6 Example of a SWACT operation with three TMU modules 4--30. . . . . . . . . . . . . . . .

Figure 4--7 Example of a cell group with three TMU modules 4--32. . . . . . . . . . . . . . . . . . . . . . .

Figure 4--8 BSC e3 (Interface node): functional group organization 4--43. . . . . . . . . . . . . . . . . .

Figure 4--9 TCU e3 (Transcoder Node): Functional group organization 4--61. . . . . . . . . . . . . . .

Figure 4--10 BSC e3, TCU e3 and PCUSN: OA&M hierarchical architecture 4--78. . . . . . . . . . .

Figure 4--11 BSC e3 and TCU e3: Call processing architecture 4--80. . . . . . . . . . . . . . . . . . . . . .

Figure 4--12 BSC e3 with PCUSN: Call processing architecture 4--81. . . . . . . . . . . . . . . . . . . . . .

List of figures Nortel Networks Confidentialxiv

PE/DCL/DD/0126411--9001--126


Figure 4--13 BSC e3 (Control Node): TMG functional organization with a TCU e3 4--84. . . . . .

Figure 4--14 BSC e3 (Control Node): TMG functional organization with a PCUSN 4--85. . . . . .

Figure 4--15 BSC e3 and TCU e3: CallP organization 4--97. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 4--16 Wander: MTIE Specifications 4--104. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 4--17 Wander: TDEV Specifications 4--105. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 4--18 Jitter: Maximum Interface Jitter Specifications 4--105. . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 4--19 Phase Transient Specifications 4--106. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--1 Control Node: physical architecture 5--1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--2 OMU module: hardware overview 5--3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--3 OMU module: functional blocks 5--6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--4 TMU module: hardware overview 5--13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--5 TMU module: functional blocks 5--16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--6 ATM--SW module: hardware overview with OC3 optical fibers plug--in 5--20. . . . .

Figure 5--7 ATM--SW module: hardware overview 5--21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--8 ATM--SW (CC--1) module: functional blocks 5--24. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--9 MMS module: hardware overview 5--27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--10 MMS module: functional blocks 5--28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5--11 SCSI bus transaction: OMU modules to/from MMS modules 5--29. . . . . . . . . . . . .

Figure 6--1 BSC e3 frame (Interface Node): physical architecture 6--1. . . . . . . . . . . . . . . . . . .

Figure 6--2 CEM module: hardware overview 6--5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--3 CEM module: functional blocks 6--7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--4 ATM--RM module: hardware overview 6--10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--5 ATM--RM module: optical fibers plug--in 6--11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--6 ATM--RM module: functional blocks 6--13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--7 8K--RM module: hardware overview 6--15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--8 8K--RM module: functional blocks 6--17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--9 LSA--RC/CTU module: electrical architecture 6--20. . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--10 LSA--RC module: hardware overview 6--21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--11 LSA--RC module: front view 6--22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--12 IEM module: functional blocks 6--32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--13 RCM: components layout 6--34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--14 TIM module layout 6--36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6--15 TIM module: 62--pin connector on 6--38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 7--1 TCU e3 (Transcoder Node): physical architecture 7--1. . . . . . . . . . . . . . . . . . . . . . .

Figure 7--2 TRM module: hardware overview 7--6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of figuresNortel Networks Confidential xv


Figure 7--3 TRM module: functional blocks 7--8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 8--1 Position of the core system in the layered Control Node softwarearchitecture 8--2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 8--2 Position of the core system in the layered Interface Node softwarearchitecture 8--3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 8--3 Position of the core system in the layered Transcoder Node softwarearchitecture 8--4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of tables Nortel Networks Confidentialxvi

PE/DCL/DD/0126411--9001--126


Table 1--1 Description of the visual indicators on the front panel of each module (except theMMS modules) in the BSC e3 and the TCU e3 1--18. . . . . . . . . . . . . . . . . . . . . . . . .

Table 1--2 Description of the visual indicators on the front panel of each MMS module inthe BSC e3 1--19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 4--1 Type of BSC e3 upgrade 4--36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 4--2 Interaction of BSC e3 upgrade 4--37. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 4--3 Type of TCU e3 upgrade 4--65. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 8--1 Presentation and description of the software packages inside the ControlNode 8--9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

About this documentNortel Networks Confidential 0--1


ABOUT THIS DOCUMENTThis document provides a complete reference for the BSC e3 and the TCU e3 usedin the GSM system.

Applicability

This document applies to the V14.3 BSS system release.

Audience

This document is for operations and maintenance personnel, and other users whowant more knowledge of the BSC e3 and the TCU e3.

Prerequisites

It is recommended that the readers also become familiar with the followingdocuments

< 00 > : BSS Product Documentation Overview

< 01 > : BSS Overview

< 07 > : BSS Operating Principles

< 117 > : GPRS Overview

Readers should also refer to:

< 16 > : TCU Reference Manual

< 39 > : BSS Maintenance Principles

< 91 > : PCUSN Reference Manual

< 101 > : Fault Number Description -- Volume 1 of 6: BSC and TCU

< 105 > : Fault Number Description -- Volume 5 of 6: Advanced MaintenanceProcedures

< 128 > : OMC--R User Manual -- Volume 1 of 3: Object and Fault menus

< 129 > : OMC--R User Manual -- Volume 2 of 3: Configuration, Performance,and Maintenance menus

< 130 > : OMC--R User Manual -- Volume 3 of 3: Security, Administration,SMS--CB, and Help menus

< 131 > : Fault Number Description: BSC/TCU e3

< 132 > : BSC/TCU e3 Maintenance Manual

About this document Nortel Networks Confidential0--2

PE/DCL/DD/0126411--9001--126


< 138 > : GSM BSS Engineering Rules

< 139 > : TML (BSC/TCUe3) User Manual

The glossary is presented in the NTP < 00 >.

Related Document

The NTPs listed in the above paragraph are quoted in the document.

How this document is organized

Chapter 1 provides a general overview of the BSC e3 and the TCU e3 producthardware. In addition, it describes the internal and external cabling for the BSC e3and the TCU e3. After reading this chapter you will understand the mechanicalstructure that make up the BSC e3 cabinet, the TCU e3 cabinet and the generalmechanical features of each assembly.

Chapter 2 deals with the hardware architecture of the BSC e3 cabinet and theTCU e3 cabinet. It shows a brief description of the modules and their interfaces,which helps readers understand the hardware architecture.

Chapter 3 briefly describes the protocol architecture in the BSC e3 cabinet and theTCU e3 cabinet.

Chapter 4 briefly describes the OAM and the CallP architecture in the BSC e3 andthe TCU e3.

Chapter 5 covers the control node, and themodules required for the operation in theBSC e3 cabinet. This section is for technical and maintenance personnel. It givesthe following for eachmodule: a physical description, a front panel description, anda functional description.

Chapter 6 covers the interface node, and the modules required for the operation intheBSCe3 cabinet. This section is for technical andmaintenancepersonnel. It givesthe following for eachmodule: a physical description, a front panel description, anda functional description.

Chapter 7 covers the transcoder node, and themodules required for operation in theTCU e3 cabinet. This section is for technical and maintenance personnel. It givesthe following for eachmodule: a physical description, a front panel description, anda functional description.

About this documentNortel Networks Confidential 0--3


Chapter 8 deals with the software entities that make up the BSC e3 cabinet and theTCU e3 cabinet. The services provided by each software entity are outlined withina strictly functional context. This section will be a reference for personnel who areinstalling new software versions.

Chapter 9 gives the number of the NTP that describes the factors governing thedimensioning of the BSC e3 cabinet and the TCU e3 cabinet.

Regulatory information

Refer to Manual < 01 >.

About this document Nortel Networks Confidential0--4

PE/DCL/DD/0126411--9001--126


PAGE INTENTIONALLY LEFT BLANK

Hardware DescriptionNortel Networks Confidential 1--1


1 HARDWARE DESCRIPTION

1.1 Physical characteristics

For the overall dimensions of the BSC e3 cabinet and the TCU e3 cabinet refer toNTP < 01 >.

1.2 Electric power supply

For information on the electric power supply to the BSC e3 cabinet and the TCU e3cabinet refer to NTP < 01 >.

1.3 Mechanical structure

The BSC e3 cabinet (see Figure 1--1) or the TCU e3 cabinet (see Figure 1--2) iscomposed of one frame assembly and one SAI (Service Area Interface) frameassembly. The BSC e3 frame and the TCU e3 frame are based on a PTE2000architecture. Each SAI frame is based on a PTE2000 altered architecture.

The basicmechanical elements of a BSC e3 frame or a TCUe3 frame consist of twodual--shelf assemblies which are based on a SPECTRUMarchitecture. The ControlNode can only accommodate up to twenty--eight removablemodules. Themodulesare electrically--shielded metal boxes that have identical dimensions, except theOMU and LSA--RC modules. Modules, cable connections, air--filter assemblies,and other maintenance items can be accessed from the front of the frame.Retractable doors and cable--trough covers protect the cable runs and cableconnections. The frame can be used with existing earthquake anchors and existingoverhead or underfloor cabling systems.

The SAI is installed in the left hand side of the frame. It is an auxiliary framewhichallows you to connect the PCM E1/T1 cables between:

the BSC e3 frame and the:

• BTSs

• TCU e3 or PCUSN

the TCU e3 frame and the:

• BSC e3

• MSC

The BSC e3 cabinet or the TCU e3 cabinet is designed for indoor applications andare EMCcompliant (no rack enclosure is necessary.) EMCcompliance isperformedon each dual--shelf assembly.

Hardware Description Nortel Networks Confidential1--2

PE/DCL/DD/0126411--9001--126


Control node

Interface node

SAIframe

BSC e3 frame

Figure 1--1 BSC e3 cabinet presentation



Transcoder node

Transcoder node

SAIframe

TCU e3 frame

Figure 1--2 TCU e3 cabinet presentation


PE/DCL/DD/0126411--9001--126


1.3.1 BSC e3 and TCU e3 frame overview

The frame of a BSC e3 cabinet (see Figure 1--3) or a TCU e3 cabinet(see Figure 1--4) houses the following:

two dual--shelf assemblies:

• for the BSC e3:

– one dual--shelf assembly is dedicated to the Control Node

– the other dual--shelf assembly is dedicated to the Interface Node

The Control Node is located above the Interface Node

• for the TCU e3:

– both dual--shelf assemblies are dedicated to the Transcoder Node

four retractable doors on each dual--shelf assembly

Each of them houses a transparent part, on the top, to showboth visual indicators(red and green LEDs) on each module

one PCIU (Power Cabling Interface Unit)

The PCIU is mounted on the top of the frame of the BSC e3 or the TCU e3cabinet. It accommodates the power cables from the operator boxes, the powerand alarm cables to each dual--shelf assembly. Different covers protect eachcable and each connector. A frame summary indicator and a fan failure lamp arelocated on the cover.

two air filter assemblies

The air filter assemblies filter the air supply for each dual--shelf. One filterassembly is located in the middle of the frame and the other at the bottom of theframe.

two grill assemblies

The upper grill assembly is located in the middle of the frame and the lower grillassembly at the bottom of the frame. They allow the air flow circulation.

two cooling units

One is located on the top and the other in the middle of the frame. Each of themhouses four fan units and provides mechanical ventilation for each dual-shelf.



CTMXCTMXCTMXCTMXCTMXCTMXCTMX






PCIU

Cooling unit(with four fan units)

Interface Node(Dual--shelf 00 --shelf 01)

Retractable doors(shown in the closedposition)

Interface Node(Dual--shelf 00 --shelf 00)

Air filter assemblyUpper grill assembly


Control Node(Dual--shelf 01 --shelf 01)

Modules in slots(30 slots per shelf)

Control Node(Dual--shelf 01 --shelf 00)

Air filter assembly

Lower grill assembly

Retractable doors(shown in the openposition)

SAI frame BSC e3 frame

CTU 0(to LSA 1)

CTU 1(to LSA 2)

CTU 2(to LSA 3)

CTU 3(to LSA 5)

CTU 4(to LSA 0)

CTU 5(to LSA 4)

Figure 1--3 BSC e3 cabinet: component layout


PE/DCL/DD/0126411--9001--126










PCIU


Transcoder Node(Dual--shelf 01 --shelf 01)

Retractable doors(shown in the closedposition)


Air filter assemblyUpper grill assembly



Modules in slots(30 slots per shelf)


Air filter assembly

Lower grill assembly

Retractable doors(shown in the openposition)

SAI frame TCU e3 frame

CTU 0(to LSA 1 up)

CTU 1(to LSA 2 up)

CTU 2(to LSA 3 up)

CTU 3(to LSA 0 up)

CTU 4(to LSA 1 down)




Figure 1--4 TCU e3 cabinet: component layout



1.3.2 SAI frame overview

The SAI frame in a BSC e3 cabinet (see Figure 1--3) or a TCU e3 cabinet(see Figure 1--4) encloses the electronic equipments used to interface:the frame of the BSC e3 with the external PCM (E1/T1) cables heading to the:

• TCU e3 on the Ater interface

• PCUSN on the Agprs interface

• BTSs on the Abis interface

the frame of TCU e3 cabinet with the external PCM (E1/T1) cables headingto the:

• BSC e3 on the Ater interface

• MSC on the A interface

The SAI frame houses the following:

for the BSC e3, up to six CTU (Cable Transition Unit) modules

They provide the physical interface for:

• up to 21 (120 or 75 Ω) PCM E1 links

• up to 28 (100 Ω) PCM T1 links

for the TCU e3, up to eight CTU modules

They provide the physical interface for:

• up to 21 PCM E1 links

• up to 28 PCM T1 links

Each CTU module of the SAI frame houses:

one backplane: CTB (Cable Transition Board)

up to seven boards: CTMx (Cable Transition Module)

Each of them is either:

a CTMC board for 75 Ω PCM E1 Coax

This board provides a connection for three PCM E1 links.

a CTMP board for 120 Ω PCM E1 twisted pair

This board provides a connection for three PCM E1 links.

a CTMD board for 100 Ω PCM T1 twisted pair

This board provides a connection for four PCM T1 links.


PE/DCL/DD/0126411--9001--126


1.3.3 HUBs overview

One or two HUBs are necessary for running the system.

They provide a physical interface between the OMC--R and both OMU modules,then they allow the supervision of the CEMs via the OMUs. The CEM connectionsare done in 10BASE--T (Ethernet) and the OMU connections are done in 10 or100BASE--T (Fast Ethernet).

These HUBs are installed outside the SAI frame. Their own installation is in chargeof the customer.

The Figure 1--5 gives an example of OMUs and CEMs connections inside theBSC/TCU e3 cabinet with two 8--port optional HUBs.



Hubport 810/100 Base T

BSC CONTROL NODE (C--NODE)

BSC INTERFACE NODE (I--NODE)

Hubport 810 Base T

RJ45

To TML e3

HUB1

MDIMDIX

5V DC 5V DC MDIMDIX

MDIMDIX

HUB2

To OMC--RNetworkSwitch

TCU TRANSCODER NODE (T--NODE)

TCU TRANSCODER NODE (T--NODE)

Note: Is used to put the optional Hub in cascade (cascade optional Hub)

Twister pair cable with RJ45 connectors

TMU

FILLE

R

OMU

ATM--SW

OMU

SIM

PrivateMMS

SharedMMS

SharedMMS

PrivateMMS

IEM

TIM IEM

IEM

TIM

IEM

IEM

TIM

ATM--R

M

FILLE

RSIM

LSA--RC LSA--RC LSA--RC1 2 3

IEM

TIM

IEM

IEM

TIM

IEM

IEM

TIM

IEM

LSA--RCLSA--RC LSA--RC

SIM

CEM

CEM

8K--R

M8K

--RM

5 0 4

TMU

TMU

ATM--SW

TMU

TMU

TMU

TMU

TMU

FILLE

R

SIM

TMU

TMU

TMU

TMU

TMU

TMU

IEM

ATM--R

M

IEM

TIM

IEM

LSA--RCTRM

SIM

TRM

TRM

TRM

CEM

CEM

TRM

TRM

TRM

TRM

TRM

0

IEM

TIM

IEM

LSA--RC

TRM

TRM

IEM

TIM

IEM

LSA--RC

IEM

TIM

IEM

LSA--RC

TRM

SIM

1 2 3

IEM

TIM

IEM

LSA--RC

FILLE

R

TRM

TRM

IEM

TIM

IEM

LSA--RC

FILLE

R

IEM

TIM

IEM

LSA--RC

TRM

SIM

1 2 3

IEM

TIM

IEM

LSA--RC

TRM

SIM

TRM

TRM

TRM

CEM

CEM

TRM

TRM

TRM

TRM

TRM

0

FILLE

R

FILLE

R

FILLE

R

FILLE

R

FILLE

R

FILLE

RFILLE

R

Figure 1--5 Example of two 8--port optional HUBs connection with BSC/TCU e3cabinet


PE/DCL/DD/0126411--9001--126


1.4 BSC e3 and TCU e3 frame descriptionThe frame of the BSC e3 cabinet or the TCU e3 cabinet is a one--frame equipment,which is split up as follows:two dual--shelf assembliesone power supply systemtwo cooling systems

1.4.1 Dual--shelf assemblies

1.4.1.1 BSC e3

The BSC e3 frame houses the following dual--shelf assemblies (see Figure 1--6):the Control Node which houses the following modules:• OMU: Operation and Maintenance Unit• TMU: Traffic Management Unit• MMS: Mass Memory Storage• ATM--SW: ATM SWitch, also named CC--1 (Communication Controller 1)• SIM: Shelf Interface Module• FILLER modulesthe Interface Node which houses the following modules:• CEM: Common Equipment Module• ATM--RM: ATM Resource Module• 8K--RM: 8K Resource Module or SRT--RM: SubRaTe Resource Module• LSA--RC: Low Speed Access Resource ComplexEach of them houses the following modules:– IEM: Interface Electronic Module– TIM: Termination Interface Module

• SIM: Shelf Interface Module• FILLER modules

1.4.1.2 TCU e3

TCU e3 frame houses the following dual--shelf assemblies (see Figure 1--7). Eachof them corresponds to the Transcoder Node which houses the following modules:

• CEM: Common Equipment Module• TRM: Transcoder Resource Module• LSA--RC: Low Speed Access Resource ComplexEach of them houses the following modules:– IEM: Interface Electronic Module– TIM: Termination Interface Module

• SIM: Shelf Interface Module• FILLER modules



TMU

FILLE

RTMU

TMU

OMU

ATM--SW

ATM--SW

OMU

TMU

TMU

TMU

TMU

SIM

TMU

FILLE

RTMU

TMU

TMU

TMU

TMU

TMU

SIM

PrivateMMS

SharedMMS

IEM

TIM

IEM

IEM

TIM

IEM

IEM

TIM

IEM

IEM

TIM

IEM

IEM

TIM

IEM

IEM

TIM

IEM

LSA--RC LSA--RC LSA--RC

FILLE

R

ATM--R

MATM--R

MFILLE

R

FILLE

RSIM

LSA--RCLSA--RC LSA--RC

SIM

CEM

FILLE

R

CEM

8K--R

M8K

--RM

PCIU assembly

Cooling unit

Air filter assembly

Cooling unit

Air filter assembly

Control node

Interface node1 2 3

5 0 4

FILLE

R(*)

FILLE

R(*)

(*) :Slots used duringthe replacementof a private MMSmodule.

SharedMMS

PrivateMMS

Figure 1--6 BSC e3 frame: front view


PE/DCL/DD/0126411--9001--126


IEM

TIM

IEM

LSA--RC

FILLE

R

TRM

TRM

IEM

TIM

IEM

LSA--RC

FILLE

R

IEM

TIM

IEM

LSA--RC

TRM

SIM

IEM

TIM

IEM

LSA--RC

TRM

SIM

TRM

TRM

TRM

CEM

CEM

TRM

TRM

TRM

TRM

TRM

IEM

TIM

IEM

LSA--RC

FILLE

R

TRM

TRM

IEM

TIM

IEM

LSA--RC

FILLE

R

IEM

TIM

IEM

LSA--RC

TRM

SIM

IEM

TIM

IEM

LSA--RC

TRM

SIM

TRM

TRM

TRM

CEM

CEM

TRM

TRM

TRM

TRM

TRM

PCIU assembly

Cooling unit

Air filter assembly

Cooling unit

Air filter assembly

Transcoder node

Transcoder node

1 2 3

0

1 2 3

0

Figure 1--7 TCU e3 frame: front view



1.4.1.3 Common module hardware architecture in the Control Node

Except for the SIM modules, each module contains a computer board or an SCSIdisk and an adapter board enclosed in a metallic housing which provides(see Figure 1--8):

• a single level of EMC shielding

• noise protection

• control of other environmental parameters

The processing boards are split up as follows:

• a SBC (Single Board Computer) board

• a PMC (PCI Mezanine Card) board

The adapter board executes the following operations:

• adapts the VME and SCBUS to the ATM network and provides backplanecommunication redundancy

• regenerates SCBUS clocks from the synchronising data flow

• provides live inserting capability to the module

• supplies on the front panel: visual indicators, Ethernet connector,optical--fiber connections, etc.

Frontpanel

LEDs

Module

ITMblock

Interface adapterboard

Backplane

Device(computer board,disk or ATM switch)

Figure 1--8 Control Node: common architecture inside each module


PE/DCL/DD/0126411--9001--126


1.4.1.4 Common module hardware architecture in the Interface Node and the Transcoder Node

Figure 1--9 shows how each 8K--RM, ATM--RM, TRM and IEM/LSA--RCmodule presents the same interface to the CEM module.

A common S--Link interface is responsible for the physical interface, and it:

recovers data from both CEM modules

monitors link health by means of a CRC check

extracts messaging channels from both CEM modules

selects PCM data from both CEM modules, based on the CEM activities

A small elastic store function is supplied to accommodate phase variationsbetween each CEM module

formats the selected data stream into a parallel bus for access by the resourcessupplied by:

• 8K--RM, ATM--RM or IEM/LSA--RC modules in the Interface Node

• TRM, IEM/LSA--RC modules in the Transcoder Node

broadcasts outgoing PCM data to both CEM modules

inserts outgoing messaging TS to each CEM module

inserts link CRCs

provides low level links, control and status facilities, including test and IDstorage

Each RM in the Interface Node or in the Transcoder Node:

has a local processor

This processor provides maintenance and low level processing related to thefunction

has a main device board

This board is enclosed in a metallic housing, providing a single level of EMCshielding, noise protection and other environmental parameters control

has a Test Bus Master functional block

This functional block consists of:

• ITM (Intelligent Test Master) ASIC

• module Information memory

• power--up reset logic



TheTest BusMaster functional block provides an interface to a system standard testand maintenance bus based on the proposed IEEE 1149.5 MTM (Module test andMaintenance) bus standard.

This provides consistent access to system test and maintenance resources such as:

MTM bus

module slot ID

storage and retrieval of fault logs

storage and retrieval of test and configuration data

status LEDs

access and control of the Test BusMaster functional block is performed throughthe CEM ITM block using the MTM bus

Frontpanel

LEDs

RM

ITMblock

Backplane

Local maintenanceprocessor

Serial link(S--link)interface

RM specific hardware and software

MTMbus

To/fromCEM 0

To/fromCEM 1

Figure 1--9 Interface Node or Transcoder Node: common architecture inside each RM


PE/DCL/DD/0126411--9001--126


1.4.1.5 Generic hardware architecture inside the BSC e3 and the TCU e3

Physical design description

Figure 1--10 shows a generic module.

Each module provides the following features and benefits:

a single level of EMC shielding

EMI containment across boards within a shelf (RFI, radiated/conducted)

defined control volume for noise environment

ESD protection for circuit packs

handling ruggedness

minimized EMC retest with new designs

PCB stiffener function

visual indicators on top of the front panel

EMC shield

Front panellatches

Figure 1--10 Generic module view



LED description

Each module inside each dual--shelf assembly houses two LEDs on the upper partof the front panel. This eases on--site maintenance and reduces the risk of humanerror.

The actual colors of these LEDs are:

red with a triangular shape

green with a rectangular shape

The red and green LEDs indicate the module status.

Figure 1--11 shows the position of each LED for each module.

XXX

Red LEDindicates module statusGreen LED

indicates module status

Figure 1--11 Module front panel indicators


PE/DCL/DD/0126411--9001--126


LED display

The table below gives the description, the combinations and the states of the redLED and the green LED for each module (except the MMS module) inside theBSC e3 cabinet and the TCU e3 cabinet. In addition it gives some scenarios:examples of LED states according to the actionon themodule (inserted, removed...)

steps Red LED Green LED Status

1 unlit LED unlit LEDThe module is not powered or theBIST terminated successfully

2 lit LED lit LEDThe BIST is running or terminatedunsuccessfully

3 unlit LED blinking LED The module is passive

4 unlit LED lit LEDThe module is active and unlocked(active OMU, both ATM--SW, allTMU)

5 lit LED unlit LED Alarm state

6 blinking LED unlit LED Path finding(the module can be removed)

7 blinking LED blinking LEDThe ATM--SW module waits OMUmaster activation (simultaneousblinking)

8 blinking LED blinking LED The ATM--SW module waits softwaredownloading (alternative blinking)

Table 1--1 Description of the visual indicators on the front panel of each module(except the MMS modules) in the BSC e3 and the TCU e3

The following scenarios are related to all the modules:

Scenario 1: When a module is inserted (general case), the LED behavior is:step1→ step2→ step3 for all modules, except TMU,OMU andATM--SW(see below).

When an OMU module is inserted, the LED behavior is:step 1→ step 2→ step 4→ step 3.

When a TMU module is inserted, the LED behavior is:step 1→ step 2→ step 4.

When an ATM--SW module is inserted, the LED behavior is:step 1→ step 2→ step 7→ step 8→ step 4.



Scenario 2: When a passive OMU module has to be removed, one must press the“Removal request pushbutton” (a TML command also exists), the LEDbehavior is :step 3→ step 1→ step 6

Scenario 3: When an active OMU module has to be removed, the behavior is :step 4→ step 3→ step 1→ step 6

The table below gives the description, the combinations and the states of the redLED and the green LED for the MMS module in the BSC e3 cabinet. In additionit gives some scenarios: examples of LED states according to the action on themodule (inserted, removed...)

steps Red LED Green LED Status

1 unlit LED unlit LED The MMS module is not powered

2 lit LED lit LEDThe MMS module is not managed ornot created

3 unlit LED blinking LEDThe MMS module is not operational(disk updating or stopping)

4 unlit LED lit LEDThe MMS module is active andunlocked

5 lit LED unlit LED Alarm state

6 blinking LED unlit LEDPath finding(the MMS module can be removed)

Table 1--2 Description of the visual indicators on the front panel of each MMSmodule in the BSC e3

The following scenarios are related to the MMS modules:

Scenario 1: When a MMS module is inserted (normal case: the administrate state isunlocked), the LED behavior is:step1→ step 2→ step 3 [updating ...] → step 4.

Scenario 2: When the administrative state is unlocked and when a MMS module isinserted, the LED behavior is :step 3 [updating ...] → step 4.

Scenario 3: When a MMS module has to be removed, one must press the ”Removalrequest pushbutton” (a TML command also exists), the LED behavior is :step 4→ step 3→ step 6.


PE/DCL/DD/0126411--9001--126


FILLER module description

A FILLER module (see Figure 1--12) is an empty module container which can beused inside:

the Control Node and the Interface Node of the BSC e3 cabinet

each of both Transcoder Nodes of the TCU e3 cabinetA FILLER module occupies any slot in each dual--shelf that does not contain amodule or an RM.Each unused slot on a powered shelf must be equipped with a FILLER module.FILLER modules maintain electromagnetic interference (EMI) integrity and theymaintain shelf airflow patterns to ensure proper cooling.If one (ormore) slot(s) remains empty (that is, they do not house a FILLERmodule)then the BSC e3 or the TCU e3 frame assembly can be damaged.

EMC shield

Front panel

Figure 1--12 FILLER module: hardware overview



1.4.2 Power supply and alarm systems

The power supply and the alarm systems of the BSC e3 or the TCU e3 frame arecomposed of:

a PCIU

This serves as a central distribution and gathering point for all power and alarmcabling used inside the BSC e3 or the TCU e3 frame

two SIM modules for each dual--shelf

They serve to transfer:

• the -- 48 Vdc supply to (from):

– the operator boxes via the PCIU

– each module

• each alarm from each module to the PCIU

1.4.2.1 PCIU

The PCIU is located in a frame power distribution tray and mounted:

on the top of the BSC e3 (see Figure 1--13)

on the top of the TCU e3 (see Figure 1--14)

The PCIU contains the following modules:

ALM: ALarm Module

FMU: Fan Management Units

In addition:

it serves as a central distribution unit

it provides a connection point for:

• power cables from the operator boxes

• power and alarm cables to:

– the SIM modules

– the fan units housed in the cooling units

When the frame summary indicator (amber lamp) located on the front cover is:

OFF: there is no active alarm in the BSC e3 or the TCU e3 frame

ON: there is an active alarm in the BSC e3 or the TCU e3 frame


PE/DCL/DD/0126411--9001--126


BSC e3

Open coverscrew

Open coverscrew

Fan failurelamp

Front view with cover

Frame summaryindicator lamp

(amber)

cover

Front view without cover

--48 V dcterminal block Test jacks

ABS (--)

FMUmodules

--48 V dc/alarmconnector tocooling unit

--48 V dc/alarmsconnector to theSIM modules

B2 (+) B2 (--)

A2 (+) A2 (--)

B1 (+) B1 (--)

A1 (+) A1 (--)

ALMmodule

Figure 1--13 PCIU: hardware overview (BSC e3)



TCU e3

Open coverscrew

Open coverscrew

Fan failurelamp

Front view with cover

Frame summaryindicator lamp

(amber)

cover

Front view without cover

--48 V dcterminal block Test jacks

ABS (--)

FMUmodules

--48 V dc/alarmconnector tocooling unit

--48 V dc/alarmsconnector to theSIM modules

B2 (+) B2 (--)

A2 (+) A2 (--)

B1 (+) B1 (--)

A1 (+) A1 (--)

ALMmodule

Figure 1--14 PCIU: hardware overview (TCU e3)


PE/DCL/DD/0126411--9001--126


The PCIU provides:

a connection for the -- 48Vdc (A andB feeds) between the PCIU and the operatorboxes

a connexion (via four cables) for the -- 48 Vdc (A and B feeds) and the alarmsbetween the PCIU and the four SIM modules

a connexion (via two cables) for the -- 48 Vdc (A and B feeds) and the alarmsbetween the PCIU and both cooling units

an ABS connexion in standalone mode for:

• telephone

• data jacks

• frame fail LED

provides front access to all connection for the I&C and maintenance procedures

ALM module

Functions

The ALM module performs the following main functions:

monitors the SIM modules, the cooling units and the fuse failures

provides control for each LED on the fan units

reports alarms on each dual--shelf

reports the PCIU fail function

Functional blocks

The ALM module houses the following functional blocks (see Figure 1--15):

PCIU fail function

It combines the PCIU fail signals with the fan units status input

The composite signal is applied to the office aisle alarm block for delivery to therow--end alarm display and to the office alarm device

fan units and cooling function status and LED drive

Eight fan units and two cooling unit status and alarms are combined by thisfunction and forwarded to the shelf and to the PCIU fail function for furtherprocessing

LED test

This test provides a signal to each dual--shelf to test all LEDs. The signal isactivated from the push button named “Test Lamp” located in themiddle of BSCe3 or the TCU e3 frame on the cooling unit front panel (see Figure 1--20)



LEDs

ALM module

Backplane

PCIU fail function

Fan cooling unitstatus and LED

drive

LED test

To/from othermodules

To/fromcooling units

Frontpanel

To/from theother LEDs

Figure 1--15 ALM module: functional blocks

FMU module

The FMU module provides over--current protection and conducted noise filtering.A soft--start circuit prevents high filter--capacitor inrush current.

Functions

The main functions of the FMU module are:

soft--start to limit capacitor inrush current

capacitor fault alarm

-- 48/--60 V at 30 A input capability

input transient protection alarm


PE/DCL/DD/0126411--9001--126


Functional blocks

The FMU module contains the following functional blocks (see Figure 1--16):

inductors

They limit the noise conducted from the fan units to the main power supply

soft--start

When power is applied, the charging circuit allows the capacitors to chargeslowly until they are fully charged. If the capacitor current is excessive, a fuseinterrupts the flow of current

Alarm

The alarm circuitry is triggered bya failure of the capacitor filter or a loss of inputpower

Capacitors

The capacitors are a part of the circuit that limits thenoise conducted from the fanunits to the main power bus

LEDs

FMU module

Frontpanel

Alarm

Backplane

Inductor

Inductor

Capacitors

Soft--start

To/from--48 V dc

To/from SIMmodules

To/fromcooling units

To/from SIMmodules

(+)(--)

Figure 1--16 FMU module: functional blocks



1.4.2.2 SIM module

The SIM modules (see Figure 1--17) are the dc power conditioner for eachdual--shelf. Each of them houses two SIM modules.

The dc part of the SIM module houses:a switcha soft start circuita -- 48 Vdc/alarms connectoran electromagnetic interference (EMI) conditioning element

The SIM module also provides the alarm interface between the PCIU module andeach dual--shelf.

Functions

The SIM module manages the following functions:current limiting during start--upthe alarms: filter fail, loss alarm, switch on/off and alarm interface between thePCIU and:• the OMU modules for the Control Node• the CEM modules for the Interface Node and the Transcoder Nodefiltered -- 48/-- 60 Vdc at 30 Apower conditioning

Functional Blocks

Figure 1--18 shows each functional block inside a SIM module.

Switch

The switch houses a 30--amp filter which is used to connect the EMI filter to the --48 Vdc.

Soft start circuitry

The soft start circuitry protects the power conditioning circuit from high--inrushstart--up conditions.

EMI filter

The EMI filter provides filtration of conducted interference to maintainCC/CSA--mandated standards.

Alarm block and LED drivers

They provide alarm logic and LED drivers for the following alarm functions:capacitor protection fuse or the circuit protection fusepower losspower switch open


PE/DCL/DD/0126411--9001--126


SIM

Visualindicators

Switch(On/Off)

Alarmindicators(red LEDs)

--48 V dc/alarmsconnector

Alarms

(--)

(+)

Figure 1--17 SIM module: hardware overview



Frontpanel

LEDs

SIM module

Blackplane

--48 V dcto/fromeachothermodule

Alarm block andLED drivers

Alarms

Alarm

red

LEDs

--48 V dcand

alarmsto/fromPCIU

SoftstartA

larms

Switch

ON/OFF

(--)

(+)

EMI filters

(--)

(+)

Filter

(--)

(+)

(--)

(+)

Figure 1--18 SIM module : functional blocks


PE/DCL/DD/0126411--9001--126


1.4.3 Cooling system

The air is forced through each part, and the frame is cooled by two cooling unit, asshown in Figure 1--19, housing four fan units (see Figure 1--20).

The filter assembly rests horizontally at the bottomof each dual--shelf. The foamair filter elements contained in the assembly are not reusable. Replace the filterperiodically, depending on the local dust conditions

The bottom dual--shelf assembly draws air through the lower grill assemblymounted at the bottom of the frame. The upper dual--shelf assembly drawscooling air through the upper grill assembly located between the dual--shelfassemblies

The grill assemblies protect the ambient air intakes that cool the dual--shelfassembly.

The fan units (see Figure 1--21):

draw air through the grills, into the air filter assemblies, and then into the actualshelves for cooling. The fans expel the air from the rear of the frame assembly

are individually replaceable fans that include mounting slides and connectors.The fan units are removed by turning the plastic screw clockwise (located on theextraction handle) and pulling the unit out of the cooling unit



Shelf 01

Shelf 00

Shelf 01

Shelf 00

Incoming air

Incoming air

Upper grill

Lower grill

Exhaustair

Exhaustair

Fan filter

Fan filter

Filterassembly

Filterassembly

Side view Front view

Dual--shelfassembly 01

Dual--shelfassembly 00

Figure 1--19 Cooling air flow diagram inside the BSC e3 or TCU e3 frame assembly


PE/DCL/DD/0126411--9001--126


Fan--unit assembly

Upper grillassembly

Air filterassembly Test lamp Data jacks

Telephonejacks

Extractionhandle

Lockingscrew

LED

Alarm

Front view of the cooling unit with grill assembly

Front view of the cooling unit with PCIU

Fan--unit assemblyExtractionhandle

Lockingscrew

LED

Alarm

Figure 1--20 Cooling unit: hardware overview



Label and LEDs Extraction handle

Alarm

Fan unit in the installed position

Fan unit in the extracted position

Figure 1--21 Fan unit: hardware overview


PE/DCL/DD/0126411--9001--126


1.5 SAI frame description

The SAI (see Figure 1--22) is an auxiliary frame that is installed in the left handside of the BSC e3 or TCU e3 frame.

It houses the CTU modules and provides space for cabling each high densityLSA--RC module to an external cross connect. The SAI frame is Earthquake Zone4 compliant.

It is a separate frame andwill be shipped to the field fully configured. Hardware forall lineup configurations will accompany the SAI. The SAI will be bolted to thefloor and to the left side of the frame (from a position facing the front of the frame)at the operator site.

1.5.1 CTU module description

The CTUmodule (see Figure 1--23 and Figure 1--24) is a frame assembly whichprovides the physical interface (PCM E1/T1 links) between the TIM module(housed inside the LSA--RC module) and the other BBS products.

It is split up as follows:

one backplane: CTB (Cable Transition Board)

TheCTB is a backplane that ismounted at theback of theCTUmodule. TheCTBprovides connection with each CTMx (either CTMP, CTMC, or CTMD)

up to seven boards: CTMx (Cable Transition Module). Each of them is either:

• a CTMP board for PCM E1 twisted pair

It provides a PCM loopback capability and secondary surge protection for the120 Ω impedance PCM E1 interface connection

• a CTMC board for PCM E1 Coax

It provides PCM loopback capability, secondary surge protection andimpedance matching. Impedance matching allows the 75Ω operator premisecoaxial cables to be connected to the TIMmodule with an internal impedanceof 120 Ω

• a CTMD board for PCM T1 twisted pair

It provides the PCM loopback capability and secondary surge protection forthe 100 Ω impedance PCM T1 interface connection

Each CTU module provides the following functions:

• terminates the cables that connect the TIM module to the CTB

• provides connectors for terminating the PCM links on the:

– Abis interface and the Ater interface or the Agprs interface for the BSC e3cabinet

– A interface and the Ater interface for the TCU e3 cabinet



SAI frame

CTMP board

CTU module

Note: This figure shows an SAI frame dedicatedto a BSCe3 cabinet with the CTMP board(for PCM E1 120 Ω).

Figure 1--22 SAI: hardware overview


PE/DCL/DD/0126411--9001--126


CTB

25--pin connectorfor external E1links (to/from

other products:OMC--R, BTS,

MSC, etc.)

CTU module

Loopbackpush buttons

Min port number

Max port number

CTMP board forPCMs E1 (120 Ω)

Figure 1--23 CTU module: left side view with a CTB and CTMPs (PCM E1 120 ohms)



CTB

CTUmodule

CTMD board forPCM T1 (100 Ω)Loopback

push buttons

Tx signals on62--pinconnector forinternal PCMs(from the TIMmodule via theTIM Tx cable)

Max portnumber

Min portnumber

Rx signals on62--pinconnector forinternal PCMs(to the TIMmodule via theTIM Rx cable)

Figure 1--24 CTU module: right side view with a CTB and CTMDs (PCM T1 110 ohms)


PE/DCL/DD/0126411--9001--126


1.5.1.1 CTB description

The CTB is a backplane that interfaces (see Figure 1--25):

the individual CTMx board which shall be either:

• a CTMP board for PCM E1 twisted pair

• a CTMC board for PCM E1 Coax

• a CTMD board for PCM T1 twisted pair

and the TIM module which is housed inside the LSA--RC module

The CTB houses:

up to seven CTMx to connect with the PCM (E1/T1) external links between theSAI and the other BSS products

two 62--pin connectors for the PCM (E1/T1) internal links between the SAI andthe LSA--RCs.

Figure 1--26 shows the CTB components layout.

Each PCM (E1/T1) transmit signal is routed to one of the 62--pin connectors (seeFigure 1--27) and each PCM (E1/T1) receive signal is routed to the other 62--pinconnectors. Each of them is connected to the corresponding TIMmodule inside theLSA--RC module.

In addition, the CTB houses seven 1SU connectors to connect each CTMx board.

The CTB provides the following features:

ease of installation for 21 PCM E1 links or 28 PCM T1 links

ease of troubleshooting for 21 PCM E1 links or 28 PCM T1 links

a controlled impedance design, with:

• 120 Ω +/-- 10% between tip and ring signals for PCM E1 links

• 75 Ω +/-- 10% between tip and ring signals for PCM E1 links

• 100 Ω +/-- 10% between tip and ring signals for PCM T1 links

current loop connection to detect cable presence



1SU molex connectorfor the CTMC, CTMD

or CTMP board

CTB

Tx signals on 62--pinconnector for internalPCMs (from the TIMmodule)

Rx signals on 62--pinconnector for internalPCMs (to the TIMmodule)

Figure 1--25 CTB physical representation


PE/DCL/DD/0126411--9001--126


CTMx (6)

CTMx (5)

CTMx (4)

CTMx (3)

CTMx (2)

CTMx (1)

CTMx (0)

CTU CTB

To TIMmodule

FromTIMmodule

21 PCME1 links

or 28PCM T1

linksto/fromoperatorboxes

3 PCM E1 links or4 PCM T1 links







Figure 1--26 CTB component layout



21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

2223242526272829303233343536373839 314042 41

6162 60 43444547484950515253545556575859 46

Note: The number in brackets indicates the number of the PCM (E1/T1) pin.(P3): Transmit PCM (E1/T1) links.(P4): Receive PCM (E1/T1) links.

(00) (03) (06) (09) (12) (15) (18) (21) (24) (27)

(P4)loop B

(02) (05) (08) (11) (14) (17) (20) (23) (26)

(01) (04) (07) (10) (13) (16) (19) (22) (25)

Ring

TipRing

(P3)loop A

GND

Figure 1--27 SUBD 62--pin connector on CTB


PE/DCL/DD/0126411--9001--126


1.5.1.2 CTMP description

The CTMP contains two basic sections (see Figure 1--28):

secondary protection for each PCM E1 twisted pair against over--current andover--voltage

loopback push buttons (see Figure 1--29) that can loop the transmit and receivePCME1 signals back towards the LSA--RCmodule and the customer equipment

The CTMP board houses two connectors:

25--pin connector

1SU Molex Omnigrid right angle connector

The 25--pin connector (see Figure 1--30) pinout is arranged such that the transmitand receive PCM (E1/T1) signals are separated as much as possible. In addition,ground pins are distributed throughout the connector for further isolation betweenspans.

The CTMP provides the following functions:

physical interface for three PCM E1 links to the LSA--RC module

loopback capability for each of the three PCM E1 links both on the local andremote sides

secondary protection against over--voltage and over--current for each PCM E1link

easy installation and troubleshooting for many PCM E1 links

secondary protection against over--voltage and over--current with the TrisilSMP75--8 by SGS--Thomson. Trisil is a low voltage surge arrestor designed toprotect T1/E1 trunks against lightning strikes and other transients

three loopback switches to loop each PCM E1 link back towards the LSA--RCmodule and towards the customer equipment. These switches aremounted on thePCB and protrude through the faceplate of the CTMP. In addition, a right--anglefaceplate has been designed to allow customer cable access




25--pin connector forexternal PCM links

Min portnumber

Max portnumber

Figure 1--28 CTMP board: hardware overview


PE/DCL/DD/0126411--9001--126


CTU module CTB

CTMP board

SecondaryProtection

Loopback

120 Ω balanced

To TIMmodule

From TIMmodule

To/fromoperatorboxes

Capability

Figure 1--29 CTMP board: components layout

12345678910111213

141516171819202122232425

Note: NC : Not connected.

NC GND TxR01 TxT01 GND TxR00 TxT00 GND RxR01 RxT01 GND RxR00 RxT00

NC NC NC GND TxR02 TxT02 NC NC NC GND RxR02 RxT02

Figure 1--30 CTMP board: SUBD 25--pin connector



1.5.1.3 CTMC board description

The CTMC board houses three basic sections (see Figure 1--31):

secondary protection for each PCM E1 coax against over--current andover--voltage

a balun for each PCME1 coax to match the 75Ω open--ended signal and convertto a 120 Ω differential pair

loopback push buttons (see Figure 1--32) that can loopback the transmit andreceive PCM E1 signals back towards the TIM module and the operator boxes

The CTMC board houses two connectors:

a 8--coax connector

1SU Molex OmniGrid right angle connector

On the 8--coax connector (see Figure 1--33), there are 3 pins associated with eachcoax cable connection; one pin for the signal and two pins for the shield. There aretwo different pin counting schemes. The8 coax connections are labelledA1 throughA8.

Ground separates the pairs of signals (tip and ring). However, certain shield pins areleft as no connects intentionally. This is to prevent a ground potential differencebetween the customer’s equipment and the CTMC because the cable is groundedat the customer transmit end.

The CTMC provides the following functions:

physical interface for three PCM E1 links to the LSA RC

loopback capability for each of the three PCM E1 links on the local and remotesides

secondary protection against over--voltage and over--current for each of threePCM E1 links

ease of installation and troubleshooting for many PCM E1 links

balun interface to convert 75 Ω single open--ended to 120 Ω differential pair


PE/DCL/DD/0126411--9001--126



8--coax connector forexternal PCM links

Min portnumber

Max portnumber

Figure 1--31 CTMC board: hardware overview



CTU module CTB

CTMC board

SecondaryProtection Balun

Loopback

75 Ωunbalanced 120 Ω balanced

To TIMmodule

From TIMmodule


Capability

Figure 1--32 CTMC board: components layout

A8 A7 A6 A5 A4 A3 A2 A1

Rx02 Tx02 NC Rx01 Tx01 NC Rx00 Tx00

Figure 1--33 CTMC board: SUBD 8--coax connector


PE/DCL/DD/0126411--9001--126


1.5.1.4 CTMD description

The CTMD (see Figure 1--34) contain two basic sections:

secondary protection for each PCM T1 twisted pair against over--current andover--voltage

loopback push buttons (see Figure 1--35) that can loop the transmit and receivePCMT1 signalsback towards theLSA--RCmodule and the customer equipment.These push buttons are mounted and they protrude through the faceplate of theCTMD

The CTMD houses two connectors:

25--pin connector

1SU Molex Omnigrid right angle connector

The 25--pin connector (see Figure 1--36) pinout is arranged such that the transmitand receive PCMT1 signals are separated as much as possible. In addition, groundpins are distributed throughout the connector for further isolation between eachPCM T1 link.

The CTMD provides the following functions:

physical interface for four twisted pair PCM T1 links to the TIM module

loopback capability for each of the four PCMT1 links on the local side and on theremote side

secondary protection against over voltage and over current for each of the 4PCMT1 links

secondary protection against over voltage and over current

loopback capability via 4--pole double throw loopback switches

loopback capability for both the customer line side and the equipment side. Foreach PCMT1 link, there is a 4--pole, double--throw switch to put the transmit andreceive paths in loopback mode.




25--pin connector forexternal PCM links

Min portnumber

Max portnumber

Figure 1--34 CTMD board: hardware overview


PE/DCL/DD/0126411--9001--126


CTU module CTB

CTMP board

SecondaryProtection

Loopback

100 Ω balanced

To TIMmodule

From TIMmodule


Capability

Figure 1--35 CTMD board: component layout

12345678910111213

141516171819202122232425

Note: NC : Not connected.

NC GND TxR01 TxT01 GND TxR00 TxT00 GND RxR01 RxT01 GND RxR00 RxT00

GND TxR03 TxT03 GND TxR02 TxT02 GND RxR03 RxT03 GND RxR02 RxT02

Figure 1--36 CTMD board: SUBD 25--pin connector



1.6 BSC e3 and TCU e3 cabinet cabling

1.6.1 BSC e3 cabinet

The BSC e3 cabinet is cabled inside the BSC e3 frame and the SAI frame viadifferent internal cable paths ensuring protection against electrical andelectromagnetic interference. The cables are routed from the BSC e3 cabinet to theother BSS products, by rails which are located in the upper part or via a false floor.

1.6.1.1 Internal cabling

The internal cabling of the BSCe3 cabinet is shown on the following figures:

Figure 1--37 and Figure 1--38 shows how to connect the OC--3 opticalmulti mode fibers

They are used to connect the ATM backplane in the Control Node via theATM_SW module to the S--link backplane in the Interface Node via theATM--RM module

Figure 1--39 shows how to connect the OC--3 optical multi mode fibers on theATM--SW module

Figure 1--40 shows how to connect the OC--3 optical multi mode fibers on theATM--RM module

Figure 1--41 shows how to connect the internal PCM (E1/T1) cables between:

• the TIM module in each LSA--RC module of the Interface Node

• and each CTU module of the SAI frame

Figure 1--42 shows how to connect the internal -- 48 Vdc and alarm cablesbetween:

• the PCIU

• and the four SIMmodules located on theControl Node and the InterfaceNode

The internal -- 48 Vdc and the alarm links are distributed (see Figure 2--3):

• for the Control Node: from the SIM modules to the OMU modules and theother modules via the ATM backplane

• for the Interface Node: from the SIM modules to the CEM module and theother modules via the S--link backplane

Figure 1--43 shows how to connect the OMU modules to the optional HUBs


PE/DCL/DD/0126411--9001--126


1.6.1.2 External cabling

The external cabling of the BSC e3 cabinet is shown on the following figures:

Figure 1--41 shows how to connect the external PCM (E1/T1) cable on eachCTU module of the SAI frame. Then, these cables are connected to the TCU e3cabinet or the PCUSN cabinets or the BTS cabinets

Figure 1--42 shows how to connect the external -- 48 Vdc cables to the PCIU.Then, these cables are connected to the other BSS products

Figure 1--43 shows how to connect the external the OMU modules to theOMC--R or to the TML

Note: Both optional HUBs can be installed outside the SAI frame.

ControlNode

InterfaceNode

Attenuator

ATM--RM

Tx

Rx

Tx

Rx

ATM--SW

OC--3 multi modeoptical fibers

Figure 1--37 BSC e3: optical fibers cabling



Tx1

Rx1

Tx0

Rx0

Tx1

Rx1

Tx0

Rx0

Opticalmultimodefibers

Figure 1--38 BSC e3: optical fiber cabling


PE/DCL/DD/0126411--9001--126


Note: (*) A connector extender is installed on all SC (Single Contact) connectors mating onthe inside of the faceplate to facilitate connector removal.

(**) Notch key faces up.

SC to SC fiberoptic adapter (*)

Guide slot

Guide pin

FerrulePlug retainer

Fiber cableconnector (**)

Tx connector

Rx connector

From Txconnector

on ATM--RM

To Rxconnector

on ATM--RM

Guide slot

Figure 1--39 ATM--SW module: optical fibers plug--in







Guide slot

Guide pin


Attenuator

Tx connector

Rx connector

From Txconnector

on ATM--SW

To Rxconnector

on ATM--SW

Guide slot

Figure 1--40 ATM--RM module: optical fibers plug--in


PE/DCL/DD/0126411--9001--126


Tx5

Rx5

Tx3

Rx3

Tx2

Rx2

Tx1

Rx1

Tx4

Rx4

Tx0

Rx0 TX0

Rx0

Tx1

Rx1

TX2

Rx2

TX3

Rx3

TX5

Rx5

TX4

Rx4

PCM (E1/T1) linksto/from TCU e3 (Ater

interface) or BTSs (Abisinterface) or PCUSN

(Agprs interface)

CTU 0 (to LSA 1)

CTU 1 (to LSA 2)

CTU 2 (to LSA 3)

CTU 3 (to LSA 5)

CTU 4 (to LSA 0)

CTU 5 (to LSA 4)

Note: Rx (CTU) is pluggedon Rx (TIM) andTx (CTU) is pluggedon Tx (TIM).

Figure 1--41 BSC e3: PCM internal and external cabling for maximal configuration



--48 V dccablesto/fromoperatorboxes

--48 V dccables tofan filters

--48 V dc/alarmscables

(+) (--) ABS (--)

Figure 1--42 BSC e3: -- 48 Vdc and alarms cabling


PE/DCL/DD/0126411--9001--126


TCP/IP on Ethernetto/from the OMC--R viathe optional HUBs (*)

Note: (*) The optionalHUBs can beinstalled outsidethe SAI.

Figure 1--43 BSC e3: cabling to/from both optional HUBS



1.6.2 TCU e3 cabinet

The TCU e3 cabinet is cabled inside the TCU e3 frame and the SAI frame viadifferent internal cable paths ensuring protection against electrical andelectromagnetic interference. The cables are routed from the TCU e3 cabinet to theother BSS products, by rails which are located in the upper part or via a false floor.

1.6.2.1 Internal cabling

The internal cabling of the TCU e3 cabinet is shown on the following figures:

Figure 1--44 shows how to connect the internal PCM (E1/T1) cables between:

• the TIM module in each LSA--RC module of the Transcoder Node

• and each CTU in the SAI frame

Figure 1--45 shows how to connect the internal -- 48 Vdc and alarm cablesbetween:

• the PCIU

• and the four SIM modules located on both Transcoder Nodes

The internal -- 48 Vdc and the alarm cables are distributed on each transcoderfrom the SIM modules to the CEM module and each RM via the S--linkbackplane (see Figure 2--5).

1.6.2.2 External cabling

The external cabling of the TCU e3 cabinet is shown on the following figures:

Figure 1--44 shows how to connect the external PCM (E1/T1) cable on eachCTUmodule of the SAI frame. Then, these cables are connected to theMSCor tothe BSC e3

Figure 1--45 shows how to connect the external -- 48 Vdc cables to the PCIU.Then, these cables are connected to the other BSS products by the operator


PE/DCL/DD/0126411--9001--126


Tx0

Rx0

TX0

Rx0

Tx3

Rx3

Tx2

Rx2

Tx1

Rx1

Tx0

Rx0

Tx3

Rx3

Tx2

Rx2

Tx1

Rx1

Tx1

Rx1

TX2

Rx2

TX3

Rx3

TX0

Rx0

Tx1

Rx1

TX2

Rx2

TX3

Rx3

PCM (E1/T1) linksto/from BSC e3 (Ater

interface) or MSC(A interface)

CTU 0 (to LSA 1 up)

CTU 1 (to LSA 2 up)

CTU 2 (to LSA 3 up)

CTU 3 (to LSA 0 up)

CTU 4 (to LSA 1 down)


Note: Rx (CTU) is plugged onRx (TIM module) andTx (CTU) is plugged onTx (TIM module).



Figure 1--44 TCU e3: PCM internal and external cabling for maximal configuration



Tx3

Rx3

TX0

Rx0

Tx2

Rx2

Tx1

Rx1

Tx0

Rx0

Tx3

Rx3

Tx2

Rx2

Tx1

Rx1

Tx0

Rx0

Tx1

Rx1

TX2

Rx2

TX3

Rx3

TX0

Rx0

Tx1

Rx1

TX2

Rx2

TX3

Rx3

--48 V dccablesto/fromoperatorboxes

--48 V dccables tofan filters

--48 V dc/alarmscables

(+) (--) ABS (--)

Figure 1--45 TCU e3: -- 48 Vdc and alarms cabling


PE/DCL/DD/0126411--9001--126



Physical architectureNortel Networks Confidential 2--1


2 PHYSICAL ARCHITECTURE

2.1 Hardware structure

2.1.1 BSC e3

The BSC e3 cabinet is split up as follows (see Figure 2--1):The SAI frame which is used to interface the BSC e3 frame with the BTSs (Abisinterface) and the TCU e3 (Ater interface) or the PCUSNs (Agprs interface)the Control Node which houses:• OMU modulesThese modules are provisioned in pairs to provide redundancy

• TMU modulesThese modules are provisioned in an N+P scheme:– N to provide the targeted performance– P to provide the redundancy

• ATM--SW modulesThese modules are provisioned in pairs to provide redundancy

• MMS modulesThese modules are provisioned in pairs to provide redundancy

• SIM modules (refer to paragraph 1.4.2.2)These modules are provisioned in pairs to provide redundancy

the Interface Node which houses:• CEM modulesThese modules are provisioned in pairs to provide redundancy

• ATM--RM modulesThese modules are provisioned in pairs to provide redundancy

• 8K--RM modulesThese modules are provisioned in pairs to provide redundancy

• LSA--RC modulesThese modules are provisioned to reach the required number of PCMs.Each of them houses:– IEM modulesThese modules are provisioned in pairs to provide redundancy

– TIM module• SIM modules (refer to paragraph 1.4.2.2)These modules are provisioned in pairs to provide redundancy

Physical architecture Nortel Networks Confidential2--2

PE/DCL/DD/0126411--9001--126


LSA--RC5

LSA--RC4

LSA--RC3

LSA--RC2

LSA--RC1

LSA--RC0

IMC

Tx0 Rx0 Tx1 Rx1 Tx2 Rx2 Tx3 Rx3 Tx4 Rx4 Tx5 Rx524681012

6 6 6 6 6 6 6 6 6 6 6 6

ATM--RM

S--links2(24X256 DS0)

3 9 9 3 3 9 9 3

TMU TMU TMU TMU

ATM_SW ATM_SW

SCSI--A

SCSI--BSCSI--PA SCSI--PB

ATM--RM

35

28

21

14

7

42

CTU0

CTU1

CTU2

CTU3

CTU4

CTU5Tx5

Rx5

Tx4

Rx4

Tx3

Rx3

Tx2

Rx2

Tx1

Rx1

Tx0

Rx0

10

8

6

4

2

12

Tx

Rx

Tx

Rx

Tx

Rx

Tx

Rx1

Tx

Rx

Tx

Rx

BSC e3 FRAME

INTERFACE NODE

SAI FRAMECONTROL NODE

CEM(active/passive)

CEM(active/passive)

Ethernet linkto TML

Ethernet linkto TML

8K--RM(active/passive)


ATM links (155 Mb/s)on optical fiber


Up to 12+2TMU modules

ATM links(14x25 Mb/s)

Transmission

Reception Transmission

Reception

OMU(active/passive)

Ethernet link(100 Mb/s)


Shared MMS Shared MMSPrivate MMS

(active/passive)Private MMS

(active/passive)

OMU(active/passive)

To/FromOMC--Ror TML

Abis/Ateror Agprslinks

(Tx/Rx)


Figure 2--1 BSC e3 cabinet: physical architecture



2.1.2 TCU e3

The TCU e3 cabinet (see Figure 2--2) is split up as follows:

The SAI frame interfaces the TCU e3 frame assembly with the BSC e3 (Aterinterface) and the MSC (A interface)

two Transcoder Nodes

Each of them houses:• CEM modulesThese modules are provisioned in pairs to provide redundancy

• TRM

These modules are provisioned in an N+P scheme:

– N to provide the targeted performance

– P to provide the redundancy

• LSA--RC modules

Thesemodules areprovisioned to reach the required quantity of PCM(E1/T1)links.

Each of them houses:

– IEM modules

These modules are provisioned in pairs to provide redundancy

– TIM module

• SIM modules

These modules are provisioned in pairs to provide redundancy


PE/DCL/DD/0126411--9001--126


TRANSCODER NODE

LSA--RC3

LSA--RC2

LSA--RC1

LSA--RC0

CEM(active/passive)

CEM(active/passive)

IMC

Tx0 Rx0 Tx1 Rx1 Tx2 Rx2 Tx3 Rx3246

Ethernet linkto TML

Ethernet linkto TML

6 6 6 6 6 6 6 6

TRMTRM

3 3 3 3

8

S-- links2(24x256 DS0)


TRM TRM

Up to 12 TRM

modules

3 33 3

TCU e3 FRAMESAI FRAME

TRANSCODER NODE

LSA--RC3

LSA--RC2

LSA--RC1

LSA--RC0

CEM(active/passive)

CEM(active/passive)

ICM


Ethernet linkto TML

Ethernet linkto TML

6 6 6 6 6 6 6 6

TRMTRM

3 3 3 3

88



CTU0

CTU1

CTU2

CTU3Tx3

Rx3

Tx2

Rx2

Tx1

Rx1

Tx0

Rx0

Tx

Rx

Tx

Rx

Tx

Rx

Tx

Rx

6

4

2

7

14

21

28

A/Ater links(Tx/Rx)

35

42

49

56

TRM TRM

Up to 12 TRM

modules

3 33 3

8

CTU0

CTU1

CTU2

CTU3Tx3

Rx3

Tx2

Rx2

Tx1

Rx1

Tx0

Rx0

Tx

Rx

Tx

Rx

Tx

Rx

Tx

Rx

6

4

2

Figure 2--2 TCU e3 cabinet: physical architecture



2.2 Hardware modules

2.2.1 Control Node

2.2.1.1 OMU module

The OMU module is front end OAM for the BSC e3.

It performs the following main operations:

manages each resource inside:

• the Control Node

• the Interface Node

• the Transcoder Node

supervises the BSC e3 and the TCU e3 cabinet

manages the interface with the OMC--R

manages the SCSI disks

provides system maintenance (by using the TML or the OMC--R)

2.2.1.2 TMU module

The TMU module manages the GSM protocols.

It performs the following main operations:

manages processing power for the GSM CallP

terminates the GSM protocols for A, Abis, Ater and Agprs interfaces

terminates the low level of the GSM protocols: LAPD and SS7

2.2.1.3 ATM--SW module

TheATM--SWmodule, also calledCC--1, ismainly anATMswitch that implementsthe ATM network used as the Control Node backplane. In addition, it provides theOC--3 connectivity on optical fibers towards the Interface Node.

2.2.1.4 MMS module

TheMMSmodules houses the data and software repositories. The RAID (RandomArray of InexpensiveDisks) architecture, an industry standard, ensures that the dataand the softwares are secured and still accessible in the event of a software orhardware failure.

2.2.1.5 SIM module

The SIM module provides the power and alarm interfaces for the Control Node. Itprovides shelf--originated alarm signals from the PCIU to the OMU modules.


PE/DCL/DD/0126411--9001--126


2.2.2 Interface Node

2.2.2.1 CEM module

The CEMmodule is in charge of controlling each LSA--RC module, each 8K--RMmodule and each ATM--RMmodule of the Interface Node and the traffic switchingfunctions.In addition, it provides:

clock synchronization and traffic switching

an access to the system maintenance using the TML

2.2.2.2 ATM--RM module

The ATM--RM module provides OC--3 connectivity on optical fibers towards theControl Node. Each ATM--RM module terminates one ATM port for both bearerchannels and signaling channels. In addition, it converts:

ATM/AAL--1 and ATM/AAL--5 cells into DS0 rate channels

ATM/AAL--5 packet into intra--node messaging

2.2.2.3 8K--RM module

The 8K--RM module is an application--specific circuit module which performs atimeswitch function on sub--DS0 rate channels, allowing for the efficient switchingof 8 and 16 kbps channels.

2.2.2.4 LSA--RC module

The LSA--RCmodule provides the PCM (E1/T1) link interfaces (the LSA is named“Complex” rather than a module since it made up of several modules).

Two versions of the LSA--RC module exist:

one for the international PCM E1 links

For this version, the LSA--RC provides 21 PCM E1 connections

the other for the North American PCM T1 links

For this version, the LSA--RC provides 28 PCM T1 connections



The LSA--RC module is a set of the following components:

a duplicated IEM module

The IEMmodule transmits and converts the PCM (E1/T1) line coded signals tothe CEM module across the S--link interface (within the backplane), handlesvarious other functions such as clock and frame recovery, alarm detection, linecoding, mapping the PCM information onto the S--link format and providing adiagnostic interface

a single TIM module

Each function inside the TIMmodule is implemented with passive componentswhich allows to the TIM to be non--redundant without impacting systemreliability

a RCM (Resource Complex Mini backplane)

The RCM performs the connection of the IEM module across the S--linkinterface (within the backplane) to the CEM module and the PCM (E1/T1) linecoded signals between the IEM module and the TIM module

2.2.3 Transcoder Node

2.2.3.1 CEM module

The active CEM is in charge of controlling each LSA--RC module and each TRMof each Transcoder Node and the traffic switching functions.In addition, it provides:

clock synchronization and traffic switching

an access to the system maintenance using the TML

2.2.3.2 TRM module

The TRMmanages the vocoding of speech channels. This task is accomplished byan array of general purpose, programmable DSPs. The flexibility andcomputational power of the TRM allow it to run any of the GSM codecs (full,enhanced full, and adaptive multi--rate) on multiple traffic channels.

2.2.3.3 LSA--RC module

For a functional description of the LSA--RC module, refer to paragraph 2.2.2.4.

For a description of the IEMand the TIMmodules, and the RCM, refer to paragraph2.2.2.4.


PE/DCL/DD/0126411--9001--126


2.3 Physical interfaces

The following internal BSC e3 equipment interfaces connect the component parts:

within the Control Node:

• ATM25 links (within the backplane) between CC--1modules, OMUmodulesand TMU modules

• Ethernet links:

– between the active and passive OMU modules

– to the TML and the OMC

• SCSI interface bus between the MMS modules and the OMU modules

between the Control Node and the Interface Node:

• OC--3c optical multi mode fiber (on ATM155) between the ATM--SWmodules in the Control Node and the ATM--RMmodule in the InterfaceNode

within the Interface Node:

• S--links

• IMC links between the active and passive CEM modules

• Ethernet links to connect the TML

within the Control Node and the Interface Node:

• MTM interface bus (within the backplane)

• alarm links via the SIM modules

The following internal TCU e3 equipment interfaces connect the component partswithin the Transcoder Node:

S--links

IMC links between the active and passive CEM modules

Ethernet links to connect the TML

MTM interface bus (within the backplane)

alarm links via the SIM modules



2.3.1 Interface within the Control Node

2.3.1.1 ATM 25 links

The physical Layer interface for the ATM25 is described in the documentationwiththe following reference: ATM Forum AF--PHY--0040.000.

2.3.1.2 Ethernet links

The physical Layer interface for Ethernet is described in the documentation withthe following reference: Ethernet 10/100 Base--T IEEE std 802.3u -- 1995.

2.3.1.3 SCSI interface buses

The physical Layer interface for SCSI interface buses is described in thedocumentation with the following reference: ANSI SCSI SPI--3.

2.3.1.4 Alarm links

Figure 2--3 shows for the frame assembly of the BSC e3 cabinet the internal andexternal alarm links.

2.3.1.5 MTM bus

The MTM bus transfers the information between each module via the backplane.

TheMTMbus is used to facilitate the communicationwith the test andmaintenancecommands. Only the activeOMUmodule is assigned as amastership of the bus, andcontrols theMTMbus transactions. The othermoduleswithin the system are slaves,but they can initiate communication with the OMUmodule through the MTM bus.

Except for the SIM modules, each module is connected to the MTM bus.

The MTM bus will give priority to the active OMU module over all othermodules for:

reset control

LED control override

module configuration data read--out

For more information about the MTM bus refer to the IEEE P1149.5 StandardModule Test and Maintenance (MTM) bus protocol. Mars 1992.

2.3.1.6 Ethernet link

The Ethernet link performs the connection between the BSC e3 or TCU e3 and theTML to the OMU module.

The physical layer interface for Ethernet is described in theEthernet 10/100Base--TIEEE std 802.3u -- 1995.


PE/DCL/DD/0126411--9001--126


Cooling unit

Control node

Interface node

Cooling unit

PCIU

BSC e3 frame

FMU module FMU module

CEMmodule

Fan unit

Fan unit

CEMmodule

TMUmodule

ATM_S

Wmodule

IEM

TIM

IEM

LSA--RC

ATM--R

Mmodule

8K--R

Mmodule

Fan unit Fan unit Fan unit


SIM

module

SIM

module

SIM

module

SIM

module

Up to12+2

MTM bus

Up to 6

MTM bus

module

Passive Active

Passive Active

Alarminterface unit

OMUmodule

OMUmodule

Notes:The bold lines show thealarm external routes.

The regular lines showthe alarm internal routeson the back panel.

MMSmodule

Up to4+2

Figure 2--3 BSC e3 frame: alarms cabling



2.3.2 Interfaces between the Control Node and the Interface Node

2.3.2.1 OC--3 links

The physical Layer interface for ATM155 over the OC3 optical fiber interface isdescribed in the “ATM User--Network Interface Specification” af--uni--0010.002.

2.3.2.2 Ethernet links

For a description of the Ethernet links, refer to paragraph 2.3.1.2.

2.3.3 Interface within the Interface Node

2.3.3.1 IMC links

The IMC links perform the connection between both CEM modules.

An IMC link has a bandwidth of 126DS0. It is a specific interface dedicated to bothCEM modules.

2.3.3.2 MTM bus

For a description of the MTM bus, refer to paragraph 2.3.1.5.

Only the active CEM module is assigned as a mastership of the MTM bus.

2.3.3.3 Alarm links

For a description of the Alarm links, refer to paragraph 2.3.1.4.

2.3.3.4 S--link interfaces

The modules are equipped within the Interface Node to provide the functionalityrequired for a particular application.

Figure 2--1 shows how the modules are connected to the CEMmodules by meansof S--Links (Serial Links). This results in a point--to--point architecture, which(when compared to bus architectures) provides superior fault containment andisolation properties.

In addition, to interfacing PCM (E1/T1) transport channels, the S--Link alsointerfaces transport messaging channels and overhead control and status bitsbetween the CEM modules and the ATM--RM, the 8K--RM and the LSA--RCmodules.

Each S--Link provides 256 TS. Some module slots have access to three S--Linkinterfaces (an S--Link cluster), or 768 TS.


PE/DCL/DD/0126411--9001--126


Twomodule slots (9 and 10 on shelf 0) are provided with six extra links (that is, twoclusters) each. Therefore, these slots are capable of terminating the full payloadbandwidth from an OC--3c. So each CEM module supplies a total of 96 S--Links(18x3 S--Links + 4x1 S--Links + 4x9 S--Links).

Figure 2--4 shows the S--Link distribution on themodule slots and the slot positionnumbers.

Shelf 1(1) (1)

1 2

(3) (3)

3 4

(3) (3)

5 6

(1) (1)

7 8

(3) (3)

9 10

(3) (3)

11 12

(3) (3)

13 14

SIM

B

15

Shelf 0(9) (9)

1 2

(3) (3)

3 4

(3) (3)

5 6 7 8

(9) (9)

9 10

(3) (3)

11 12

(3) (3)

13 14

SIM

A

15

(96) (96)

Note: The number in brackets indicates the quantity of S--link interfaces per slot.

Figure 2--4 Interface Node: S--Link distribution



2.3.4 Transcoder Node interfaces

2.3.4.1 Ethernet link

The Ethernet links provides the connection of the TML to the CEM module.

The physical layer interface for Ethernet is described in theEthernet 10/100Base--TIEEE std 802.3u -- 1995.

2.3.4.2 IMC links

For a description of the IMC links, refer to paragraph 2.3.3.1.

2.3.4.3 MTM bus

For a description of the MTM bus, refer to paragraph 2.3.1.5.

Only the active CEM module is assigned as a mastership of the MTM bus.

2.3.4.4 Alarm links

Figure 2--5 shows for the frame assembly of the TCU e3 cabinet the internal andexternal alarm links.

2.3.4.5 S--link interfaces

For a description of the S--Links interfaces, refer to paragraph 2.3.3.4.


PE/DCL/DD/0126411--9001--126


Cooling unit

Transcoder node

Transcoder node

Cooling unit

PCIU

TCU e3 frame

FMU module FMU module

CEMmodule

Fan unit

Fan unit

CEMmodule



SIM

module

SIM

module

SIM

module

SIM

module

MTM bus

Up to 14

MTM bus

Passive

Active

Passive Active

Notes:The bold lines show thealarm external routes.

The regular lines showthe alarm internal routeson the back panel.

Alarminterface unit

CEMmodule

CEMmodule

IEM

TIM

IEM

LSA--RCmodule

TRMmodule

TRMmodule

Up to 4

Up to 4Up to 14

IEM

TIM

IEM

LSA--RCmodule

Figure 2--5 TCU e3 frame: alarms cabling

Protocol ArchitectureNortel Networks Confidential 3--1


3 PROTOCOL ARCHITECTUREThe purpose of the following is to give a high--level presentation of the protocolarchitecture in a BSS network with a BSC e3 cabinet and a TCU e3 cabinet.

3.1 Protocol used for communication between the OMU modules andthe OMC--R

This paragraph describes the protocol used for communication between an OMUmodule inside the BSC e3 cabinet and the OMC--R (see Figure 3--1).

The BSC e3 cabinet and the OMC--R communicate via an OSI protocol stackwhichcovers the following needs:

physical connection capability

LAN/RFC1006 (TCP/IP): two Ethernet link from the BSC e3 side and oneEthernet link from the OMC--R side. The Ethernet link at up to 100 Mbps

association management capability

The associations manager is interfaced upon the Transport layer API

the FTAM (File transfer Acces Management)

The FTAM contains the following characteristics:

• only the responder capability is needed

• restart and recovery capabilities are used

• content list types needed: NBS9, FTAM--1 and FTAM--3

ASN1 compiler

This compiler is required to generate the data coding/decoding of thetransactions exchanged upon the BSC e3/OMC--R interface

The OSI protocol stack is compliant with the following recommendations:

General

• ISO 7498/ITU--T X.200

Basic Reference model of Open Systems Interconnection

• ITU--T Q.811

Lower layer Protocol Profiles for the Q3 Interface

• ITU--T Q.812

Upper Layer Protocol Profiles for the Q3 Interface

Protocol Architecture Nortel Networks Confidential3--2

PE/DCL/DD/0126411--9001--126


CONTROLNODE

BSC e3

TMU moduleTCP/IP Ethernet

FTAMPresentationSession

RFC 1006TCP/IPEthernet

8K--RMCEM module

Switch64K

Switch8K

ATM--RM

LSA--RC

INTERFACE NODE

TCU e3

TRANSCODER NODE

TRM

CEM module

LSA--RC

OMU module OMC

ATM_SW module(CC1)

BTS

MSC

APE

Figure 3--1 Protocol architecture: between the OMC--R and the BSC e3 cabinet



Application Layer

• ISO 8571

File Transfer, Access and Management Protocol

• ISO 8649/ITU--T X.217

Association Control Service Element Service

• ISO 8649/ITU--T X.227

Association Control Service Element Protocol

Presentation Layer

• ISO 8822/ITU--T X.216

Connection--Oriented Presentation Definition

• ISO 8823/ITU--T X.226

Connection--Oriented Presentation Protocol

• ISO 8825/ITU--T X.209

ASN 1, Basic Service Element Protocol

Session Layer

• ISO 8326/ITU--T X.215

Connection Oriented Session Service Definition

• ISO 8327/ITU--T X.225

Connection Oriented Session Protocol

Transport Layer

• ISO 8072/ITU--T X.214

Connection Oriented Transport Service

• ISO 8073/ITU--T X.224

Connection Oriented transport Protocol Class 4,2,0

• RFC 1006

OSI Transport Services on top of TCP

Network Layer

• ISO 8208/ITU--T X.25

Packet Level Protocol for DTE

• ISO 8348/ITU--T X.213

Network Service Definition


PE/DCL/DD/0126411--9001--126


3.1.1 Protocol used for communication between each node inside theBSC e3 and the TCU e3 and between each BSS product

This paragraph describes briefly the main protocol communication between:

each node inside (see Figure 3--2):

• the BSC e3 cabinet: Control Node and Interface Node

• the TCU e3 cabinet: both Transcoder Nodes

eachBSS product (see Figure 3--3): OMC--R, BSCe3, BTSs, TCUe3 andMSC

3.1.1.1 ATM interface distribution

The Control Node uses a duplex star connectivitywith the cell switching performedby bothATM--SWmodules at the center of the star and the OMUand TMUmodulesat the leaves.

This subsystem provides a reliable backplane modules interconnection with liveinsertion capabilities. It contains the following main components:

an ATM switch located inside each ATM--SW module

an ATM Adapter located inside each OMU module and each TMU module

The connections between each module inside the Control Node use a redundantATM25 point to point connection to the ATM switches.

The ATM interface uses the ATM25 standard as defined by the ATM Forum. Itcarries all internal signalling information, using AAL--1 and AAL--5 protocols.

3.1.1.2 ATM Adaptation Layer Protocols: AAL--1 and AAL--5

The communication exchanged between each module on the ATM subsystem isaccomplished over the Vc (Virtual circuits) using the AAL--1 and AAL--5 (ATMAdaptation Layer) protocols.

For example, a TMU module needs 82 Vcs:

64 Vcs for CallP signaling (LAPD), using AAL--1 protocol

18 Vcs for internal messaging, using AAL--5 protocol



CONTROLNODE

OAMTCP/IPAAL5ATM

CallP

BSC e3

TMU moduleLA

PD

DTAPLAPDISDN--BAAL1

OAM CallP

ATM

DTAPLAPDISDN--BDS0

OAM CallP

OAM_INUDP/IPAAL5

SPM messaging

CallP_IN

OAM_INSPM messaging

CallP_IN

8K--RMCEMmodule

Switch64K

Switch8K

Speech + data

ATM--RM

LSA--RC

INTERFACE NODE

TCU e3

TRANSCODERNODE

TRM

CEMmodule

LSA--RC

OMU module

Callp_TNSPM messaging

OAM_TN

OAMSPM messaging

LAPDISDN--BDS0

OAM_TN CallP_TN

OMC

ATM_SW module(CC1)

BTS

MSC

: Corresponds to a transparent transfer.

OAMmanagement

Final processing ofCallp and OA&M

Convert ProtocolAAL1 to DS0

Convert Protocol AAL5to SPM messaging

OAMmanagement

LAPD to SPMmessaging

Applicatif processingto Callp and OA&M

ATM

ATM

Figure 3--2 Protocol architecture: between each node within a BSC e3 and a TCU e3


PE/DCL/DD/0126411--9001--126


CONTROLNODE

BSC e3

TMU module

SS7

LAPD

DTAPLAPDISDN--BAAL1

OAM CallP

ATM

BSS MAPSCCP

MTP3, MTP2, MTP1AAL1

DTAP

ATM

DTAPLAPDISDN--BDS0

OAM CallPBSS MAPSCCP

MTP3, MTP2, MTP1DS0

DTAP

8K--RMCEMmodule

Switch64K

Switch8K

Speech + data

ATM--RM

LSA--RCLAPD

Speech + data

INTERFACE NODE

TCU e3

TRANSCODERNODE

TRM

CEMmodule

LSA--RC

OMU module OMC

ATM_SW module(CC1)

BTS

MSC



Speech and dataprocessing

Speech + data

SS7

Figure 3--3 Protocol architecture between each BSS product within a BSC e3 and aTCU e3



3.1.1.3 Internal Messaging: IP over AAL--5 protocol

The communication inside the BSC e3 is performed by an internal messaging,which conveys the OAM and CallP data flows. To secure the transfer, the internalmessaging uses the TCP/IP protocol.

The IP packets are carried in ATM AAL--5 type cells. Translation of IP address toATM (Vp,Vc) address is achieved via the address resolution protocol table builtduring system initialization.

AAL--5 traffic is a bursty traffic because it contains internal messaging:

inside the Control Node:

• from each OMU module to each TMU module and ATM--SW module

• from each ATM--SW module to each other module (OMU, TMU andATM--SW modules)

• from each TMU module to each ATM--SW module and the other TMUmodule


• from each OMU module to each CEM module

• from each TMU module to each CEM module

3.1.1.4 LAPD and SS7 Signaling: Circuit Emulation over AAL--1

LAPD and SS7 links carried on PCM TS (DS0) are translated over ATM using theATM AAL--1 protocol (Circuit mode Emulation).

The AAL--1 Vcs are used to transport LAPD links and SS7 links between theControl Node and the Interface Node.

TheAAL--1Vcs are converted in DS0 links by the ATM--RMmodule located insidethe Interface Node.

The DS0 are used to transport:

LAPD channels between:

• the Interface Node and the Transcoder Node

• the Interface Node and the BTSs

SS7 channels between the Interface Node and theMSC via the Transcoder Node


PE/DCL/DD/0126411--9001--126


3.1.1.5 AAL--1 and AAL--5 Multiplexing

The ATM connections currently used in the BSC e3 are:

for AAL--5:

• inside the Control Node:

– one Vc from each OMU module to each ATM--SW module

– one Vc from each TMU module to each ATM--SW module

– one Vc between each module (OMU, TMU and ATM--SW modules)

• between the Control Node and the Interface Node:

– one Vc from each OMU module to each CEM module

– one Vc from each TMU module to each CEM module

for AAL--1:


– up to 64 AAL--1 Vcs from each TMU module to the Interface Node

3.1.1.6 Switching LAPD and SS7 TS

LAPD and SS7 messages inside the Interface Node are received inside the AAL--1cells by both ATM--RM modules and distributed to both CEM modules via theS--link interfaces.

A Y connection connects the two identical TSs to the required LSA--RC module:

in the ATM to LSA way, only the TS of the active plane is switched

in the LSA to ATM way, the TS is broadcast to both S--links

S--links used for signaling are called Primary S--links.

3.1.1.7 Communication between the Control Node and the Interface Node

The communication between the Control Node and the Interface Node uses theTCP/IP and UDP/IP protocol stack over AAL--5.

FTP is used to download the software. The OAM--IN and CallP_IN (for InterfaceNode) data flows are conveyed over the UDP/IP protocol stack.



3.1.2 Protocol used for communication between each node inside theBSC e3 and the PCUSN and between each BSS product

This paragraph briefly describes the main protocol communication between:

each node inside (see Figure 3--4):

• the BSC e3 cabinet: Control Node and Interface Node

• the TCU e3 cabinet: both Transcoder Nodes

eachBSS product (see Figure 3--5): OMC--R, BSCe3, BTSs, TCUe3 andMSC

3.1.2.1 ATM interface distribution

The Control Node uses a duplex star connectivitywith the cell switching performedby bothATM--SWmodules at the center of the star and the OMUand TMUmodulesat the leaves.

This subsystem provides a reliable backplane module interconnection with liveinsertion capabilities. It contains the following main components:

an ATM switch located inside each ATM--SW module

an ATM Adapter located inside each OMU module and each TMU module

The connections between each module inside the Control Node use a redundantATM25 point--to--point connection to the ATM switches.

The ATM interface uses the ATM25 standard as defined by the ATM Forum. Itcarries all internal signalling information, using AAL--1 and AAL--5 protocols.

3.1.2.2 ATM Adaptation Layer Protocols: AAL--1 and AAL--5

The communication exchanged between each module on the ATM subsystem isaccomplished over the Vc (Virtual circuits) using the AAL--1 and AAL--5 (ATMAdaptation Layer) protocols.

For example, a TMU module needs 82 Vcs:

64 Vcs for CallP signaling (LAPD), using AAL--1 protocol

18 Vcs for internal messaging, using AAL--5 protocol


PE/DCL/DD/0126411--9001--126


CONTROLNODE

OAMTCP/IPAAL--5ATM

CallP

BSC e3

TMU module

LAPD

DTAPLAPDISDN--BAAL--1

OAM CallP

ATM

DTAPLAPDISDN--BDS0

OAM CallP

OAM_INUDP/IPAAL--5

SPM messaging

CallP_IN

OAM_INSPM messaging

CallP_IN

8K--RMCEMmodule

Switch64K

Switch8K

data

ATM--RM

LSA--RC

INTERFACE NODE

PCUSN

OMU module OMC

ATM--SW module(CC1)

BTS

SGSN


OAMmanagement


Convert ProtocolAAL--1 to DS0

Convert ProtocolAAL--5 to SPMmessaging

ATM

ATM

OAMmanagement

Figure 3--4 Protocol architecture: between each node within a BSC e3 and a PCUSN



PCUSN

CONTROLNODE

BSC e3

TMU module

LAPD

DTAPLAPDISDN--BAAL--1

OAM CallP

ATM

DTAPLAPDISDN--BDS0

OAM CallP

8K--RMCEMmodule

Switch64K

Switch8K

Data

ATM--RM

LSA--RCLAPD

Data

INTERFACE NODE

OMU module OMC

ATM--SW module(CC1)

BTS


Convert ProtocolAAL--1 to DS0

DataData processing

SGSN

Frame relay

Figure 3--5 Protocol architecture between each BSS product within a BSC e3 and aPCUSN


PE/DCL/DD/0126411--9001--126


3.1.2.3 Internal Messaging: IP over AAL--5 protocol

The communication inside the BSC e3 is performed by an internal messaging,which conveys the OAM and CallP data flows. To secure the transfer, the internalmessaging uses the TCP/IP protocol.

The IP packets are carried into ATM AAL--5 type cells. Translation of IP addressto ATM (Vp,Vc) address is achieved via the address resolution protocol table builtduring system initialization.

AAL--5 traffic is a bursty traffic because it contains internal messaging:

inside the Control Node:

• from each OMU module to each TMU module and ATM--SW module

• from each ATM--SW module to each other module (OMU, TMU andATM--SW modules)

• from each TMU module to each ATM--SW module and the other TMUmodule


• from each OMU module to each CEM module

• from each TMU module to each CEM module

3.1.2.4 LAPD Signaling: Circuit Emulation over AAL--1

LAPD links carried on PCM TS (DS0) are translated over ATM using the ATMAAL--1 protocol (Circuit mode Emulation).

The AAL--1 Vcs are used to transport LAPD links between the Control Node andthe Interface Node.

The AAL--1 Vcs are converted in DS0 links by the ATM--RM located inside theInterface Node.

The DS0 are used to transport LAPD channels between:

• the Interface Node and the Transcoder Node

• the Interface Node and the BTSs



3.1.2.5 AAL--1 and AAL--5 Multiplexing

The ATM connections currently used in the BSC e3 are:

for AAL--5:

• inside the Control Node:

– one Vc from each OMU module to each ATM--SW module

– one Vc from each TMU module to each ATM--SW module

– one Vc between each module (OMU, TMU and ATM--SW modules)


– one Vc from each OMU module to each CEM module.

– one Vc from each TMU module to each CEM module.

for AAL--1:


– up to 64 AAL--1 Vc from each TMU module to the Interface Node

3.1.2.6 Switching LAPDTS

LAPD messages inside the Interface Node are received inside the AAL--1 cells byboth ATM--RM and distributed to both CEM modules via the S--link interfaces.

An Y connection connects the two identical TSs to the required LSA--RC module:

in the ATM to LSA way, only the TS of the active plane is switched

in the LSA to ATM way, the TS is broadcast to both S--links

S--links used for signaling are called Primary S--links.

3.1.2.7 Communication between the Control Node and the Interface Node

The communication between the Control Node and the Interface Node uses theTCP/IP and UDP/IP protocol stack over AAL--5.

FTP is used to download the software. TheOAMandCallP data flows are conveyedover the UDP/IP protocol stack.

3.1.3 Overview and conclusion

Figure 3--6 shows an overview of the protocol communication architecture in aBSS network with a BSC e3 cabinet and a TCU e3 cabinet.

Figure 3--7 shows an overview of the protocol communication architecture in aBSS network with a BSC e3 cabinet and a PCUSN cabinet.


PE/DCL/DD/0126411--9001--126


CONTROLNODE

OAMTCP/IPAAL5ATM

CallP

BSC e3

TMU module

SS7

LAPD

LAPD

TCP/IP Ethernet

DTAPLAPDISDN--BAAL1

OAM CallP

ATM

BSS MAPSCCP

MTP3, MTP2, MTP1AAL1

DTAP

ATM

DTAPLAPDISDN--BDS0


MTP3, MTP2, MTP1DS0

DTAP

OAM_INProxy AAL5

SPM messaging

CallP_IN

OAM_INSPM messaging

CallP_IN

8K--RMCEMmodule

Switch64K

Switch8K

Speech + data

ATM--RM

LSA_RCLAPD

Speech + data

INTERFACE NODE

TCU e3

TRANSCODERNODE

TRM

CEMmodule

LSA--RC

OMU module

Callp_TNSPM messaging

OAM_TN

OAMSPM messaging

LAPDISDN--BDS0

OAM_TN CallP_TN

OMC

ATM_SW module(CC1)

BTS

MSC

OAMmanagement




OAMmanagement

Speech and dataprocessing

LAPD to SPMmessaging

Applicatif processingto Callp and OA&M

Speech + data

SS7

TCP/IP

TCP/IP


RFC 1006UDP/IPEthernet

APE


Figure 3--6 Protocol architecture inside a BSS with a TCU e3: overview



CONTROLNODE

OAMTCP/IPAAL5ATM

CallP

BSC e3

TMU moduleLA

PD

LAPD

TCP/IP Ethernet

DTAPLAPDISDN--BAAL1

OAM CallP

ATM

DTAPLAPDISDN--BDS0


MTP3, MTP2, MTP1DS0

DTAP

OAM_INProxy AAL5

SPM messaging

CallP_IN

OAM_INSPM messaging

CallP_IN

8K--RMCEMmodule

Switch64K

Switch8K

Data

ATM--RM

LSA_RCLAPD

Data

INTERFACE NODE

PCUSN

OMU module OMC

ATM_SW module(CC1)

BTS

SGSN

OAMmanagement




OAMmanagement

Data processingApplicatif processingto Callp and OA&M

Data

TCP/IP

TCP/IP


RFC 1006UDP/IPEthernet

APE


Figure 3--7 Protocol architecture inside a BSS with a PCUSN: overview


PE/DCL/DD/0126411--9001--126



Functional ArchitectureNortel Networks Confidential 4--1


4 FUNCTIONAL ARCHITECTURE

4.1 BSC e3 functional design

4.1.1 Overview

BSC e3 functional architecture is based on the following features:

ability to handle varying traffic loads

adaptability to different equipment structures

highly fault tolerant architecture

easy to operate:• all modules have the same look and visual indicators• network connections are concentrated in an unique and easy access cabletransition unit

• path finding is used to identify the faulty module

robust and scalable platform:• star architecture

It provides accurate and immediate fault detection• fault tolerance scheme

It provides fast fault recovery by reconfiguring software activity on activemodules without impacting the service

• the traffic model and BSC e3 capacity are independent• N+P redundancy (nominal capacity preserved with P failures)• load balancing

It allows the distribution of the processing over the modules for an optimalusage of the resources

• scalability

Possibility to plug a new processing module to increase the capacity of theBSC e3 cabinet

Functional Architecture Nortel Networks Confidential4--2

PE/DCL/DD/0126411--9001--126


reliable and high--performance of management:• the disk subsystem is protected against:

– a hardware or a software failure inside the OMU module

– an extraction of the MMS module• the OMU subsystem is protected against a hardware or software failure insidethe MMS module

plug and play modules:• easy hardware maintenance or extension by extracting or plugging themodules

• hot module insertion or extraction without service interruption• OMU module and private MMS module can not be managed like other plugand play modules, due to their logical hierarchical dependency

• a private MMS may be plugged in a shared MMS slot, but not the reverse

plug and play without snapshothardware management without the snapshot management.The snapshot gives a “picture” of the detected hardware

ATTENTION

Performing a hot extraction may interrupt service. Before performing any hotextraction, see appropriate sections in this manual and in the BSC/TCU e3MaintenanceManual (411--9001--132) to review the limitations and precautionsassociated with the component to be removed.



4.1.2 BSC e3 functional characteristics

The BSC e3 is fully redundant. It manages the main functions described below:

radio resource management:

• to process radio accesses

• to allocate radio channels (traffic and signaling)

• to monitor radio channel operating states

• to share radio channels between GPRS and GSM

call processing:

• to set up and release terrestrial and radio links

• to transfer messages between the mobile stations and the MSC (via the TCUe3s or TCU 2Gs and the BTSs)

• to switch the channels between the BTSs and the MSC (via the TCU e3 orTCU 2G)

call sustaining procedures:

• to process measurements from mobile stations and the BTSs

• to launch:

– the power control procedures

– the handover procedures

BTS management:

• to set physical channels, to control transceivers (TRX)

• to initialize the TRX and set the channels

• to supervise BTS operating states

• to provide BTS reconfiguration, if needed

• to update system parameters

TCU e3 management

BSC e3 defense:

• to detect and correct failures and operating anomalies

• to provide local defense by isolating faulty units, to avoid problem spreading

• to provide equipment unit reconfiguration using redundant units. Thesefunctions include for the BSC e3 the module switching and restartmechanisms


PE/DCL/DD/0126411--9001--126


BSS operation and maintenance:

• to manage the link with the radio operations and maintenance center(OMC--R)

• to process operations requested by the OMC--R

• to store all BSS configuration data and software, and distribute them amongthe various entities

The BSC e3 software architecture is based on a network model of processors calleda “core system”, which can be tailored to fit into different hardware structures. Thecore system is divided into logical process units. A set of modules which houseboards and processors provide each logical unit with the processing power theyneed.

The main types of processing unit are split up as follows:

for the Control Node:

• the OMU modules enable the following basic BSC e3 operating functions:

– MMS module management

– BSC e3 initialization sequences (loading the programs and data into thedifferent processors)

– monitoring correct processor operations

– OMC--R access and related function management

– Interface Node management

• the TMU modules enable:

– for the twelve TMU module, which are dedicated to the CallP:

centralized call processing functions

communication with the BTS (traffic management, radio environmentmonitoring, message broadcasting, traffic overload control, etc.)

TCU e3 management

– for the two TMU module, which are dedicated to SS7 management:

communication with the MSC

communication with the MSC (SS7 signaling channels)

• the ATM--SW modules enable:

– conversion of the ATM 25 to the SONET interfaces (ATM155)

– conversion of the LAPD and SS7 channels on each TMU module via theVP--VC on AAL--1



for the Interface Node:

• the ATM--RM modules enable:

– conversion of the AAL--1 to S--link interfaces

– conversion of the AAL--5 to Spectrum messaging interfaces

• the CEM modules enable:

– management of the ATM--RM, 8K--RM and LSA--RC modules

– management of the mixing order for the 64K and the 8K switching parts

• the 8K--RM modules enable:

– running of the mixing order to the 8K switching part

• the LSA--RC module enable:

– management of the PCM/defect monitoring

– conversion of the PCM to S--link interfaces


PE/DCL/DD/0126411--9001--126


4.2 TCU e3 functional design

4.2.1 Overview

The TCU e3 functional architecture is based on the following features:

the ability to handle different traffic loads

the adaptability to different equipment structures

the commitment to a functional approach

a highly fault tolerant architecture

an easy maintenance platform:• each module has the same looking and the same visual indicators• network connections are concentrated in an unique and easy access cabletransition unit

• path finding is used to identify the faulty module

simplified and opened network management

the communication with the BSC e3

a robust and scalable platform:• a star architecture which provides accurate and immediate fault detection• a traffic model which is independent of the equipment capacity.• scalability: the equipment capacity can be increased by simply plugging in anew processing module

plug and play modules:• easy hardware maintenance or extension by simply extracting or plugging inmodules

• hot module insertion or extraction without service interruption

plug and play without snapshothardware management without the snapshot management

ATTENTION

Performing a hot extraction may interrupt service. Before performing any hotextraction, see appropriate sections in this manual and in the BSC/TCU e3MaintenanceManual (411--9001--132) to review the limitations and precautionsassociated with the component to be removed.

the use of a 64 kbps Timeswitch for the BSC e3 connection with the MSC

This function is divided as follows:• switching matrix management• S--link monitoring



PCM link management

transcoder management

transcoding and rate adaptation

synchronization of the time base on the clock taken from three of the PCM linksconnected to the MSC or from an external reference clock

terminating the LAPD links, from the BSC e3, which carries:• permanent links for the CallP and the OAM functions• temporary links for the software downloading


PE/DCL/DD/0126411--9001--126


4.2.2 TCU e3 functional characteristics

The TCU e3 is fully redundant.

It performs the following main functions:

call processing, which does the following:

• switches the speech/data channels

• switches channels between BTS and MSC

defense, which does the following:

• detects and processes failures and operating anomalies

• provides local defense by isolating faulty units, thus avoiding problemspreading

• provides equipment unit reconfiguration using of redundant units. Thesefunctions include switching and restart mechanisms for the modules insidethe TCU e3

switching of the SS7 channels from the BSC e3 to the MSC

The main types of processing units inside each Transcoder Node are split up asfollows:

the TRM module is used to transcode A channel (64 Kbits) from (to) the MSCinto Ater channel (16 Kbits/8 Kbits) from (to) the BSC e3

the CEM module is used:

• to manage the TRMs and the LSA--RC modules

• to manage the switching order for the 64K switching part

the LSA--RC module enables:

• to manage the PCM/defect monitoring

• to convert the LAPD to Spectrum messaging interfaces

• to convert the PCM to the S--links interfaces



4.3 Architecture presentation

To facilitate presentation of the main functions of the BSC e3 cabinet and the TCUe3 cabinet, we have split up the functional architecture as follows:

an OAM (Operation And Maintenance) architecture

a CallP (Call Processing) architecture

4.3.1 OAM architecture

4.3.1.1 Overview

For the BSC e3 cabinet and the TCU e3 cabinet, Figure 4--1 shows the OAMarchitecture with the main functional groups and their main relationships.

Control Node

The Control Node houses the following main functional groups:

BSCe3/OMC--Com

This functional group is in charge of the relationship between the BSCe3 and theOMC--R in term of protocol (association, transport, transaction, file transfer,etc.)

OMC Services

This functional group provides to any software present in the Control Node, theability to interact with:

• the Fault Management function

• the Performance Management function

• the Configuration Management function

Supervision

This functional group gathers together all software entities to manage the nodesof the BSS network.

It is composed of the following functional groups:

• SUP_CN to supervise the Control Node in the BSC e3

• SUP_IN to supervise the Interface Node in the BSC e3

• SUP_TCU to supervise each TCU e3

• SPT to supervise each TCU 2G


PE/DCL/DD/0126411--9001--126


BSC e3

INTERFACE NODE

CONTROL NODE

BSCe3/OMC--Com

OMC Services

FaultManagement

PerformanceManagement

ConfigurationManagement

OSI

FTAMAPE

OSI/FTAM

Supervision

I--Node_OAM

ObjectManagement

Critical PathManagement

UpgradeManagement

Tests & DiagManagement

Base OS

HardwareManagement

TRANSCODER NODE

T--Node_OAM

ObjectManagement

Critical PathManagement

UpgradeManagement


Base OS

HardwareManagement

TCU e3

To the OMC--R via TCP/IP on Ethernet

TCU_OAMTCU 2Gs

PCUSN_OAMPCUSN

SPP SPRSUP_TCU SPT

BTS_OAMBTSs

SoftwareManagement

OverloadManagement

UpgradeManagement


Fault Tolerance

Load Balancing

HardwareManagement

C--Node_OAM

Administration

Data/FileAccess System

Global Services

Software Bus

Spy Capture Inject

Basic Services

Messaging

Base OS

SUP_IN SUP_CN

IN/IF ACCESSGeneric ACCESS

Figure 4--1 BSC e3 and TCU e3: OAM architecture



• SPP to supervise the PCUSN

• SPR to supervise the BTSs

C--Node_OAM

The C--Node_OAM functional group gathers together the different parts whichare briefly described below:

• a Software Management part

This part is in charge of the start--up of all none fault tolerant software entitiesin the Control Node. In addition, it ensures their synchronization during thestart--up phase and supervises their activities

• an Overload Management part

This part is in charge to detect overload condition and to generate internalsignals toward the different software entities inside the Control Node to adapttheir behavior to the congestion phase. These signals allow a reaction of eachsoftware when different thresholds are crossed (activation of a flow control,handling of emergency call, call restriction, etc.)

• an Upgrade Management part

This part is in charge tomanage the software upgrade of the Control Node. Inaddition, it ensures the relationship with the SUP_IN and the SUP_TCU toupgrade respectively the software of the Interface Node and the TranscoderNode

• a Test and Diagnostic Management part

This part is in charge of the maintenance aspect of the Control Node. Inaddition, it ensures the communication with the TML (Terminal LocalMaintenance):

– to run the tests

– to collect various information about the Interface Node components

– to provide advanced services for:

the I&C (Installation and Commissioning) procedures

the maintenance procedures

• a Fault Tolerance and Load Balancing part

This part is in charge of the distribution of the software entities over theavailable modules of the Control Node (it is the Load Balancing). To do this,the Load balancing function uses the Fault Tolerance function, whichinteractswith the software entities: to run, to switch or to delete their activities


PE/DCL/DD/0126411--9001--126


• a Hardware Management partThis part is in charge to provide the following functions:– to detect the plugged modules– to identify the plugged modules– etc.

Global services

Three functions manage the software entities of the Control Node:

• Administration function

• Data/File access system function

• Software bus function

Basic services

Various basic services are offered to all software entities of the Control Node.

• Messaging service

This service provides the capability to each software entity to communicatewithout knowing the location of the destination entity, even if this softwareentity, in case of module failure, migrates from one module to another one



Interface Node

The InterfaceNode houses the I--Node_OAMfunctional group and gathers togetherthe different parts which are briefly described below:

an Object Management part

This part is in charge of the following operations in the Interface Node:

• setting up each module via ATM network (AAL--1/AAL--5) and the externalinterfaces via the PCM links on the Abis interface and the Ater interface

• providing a local defense (i.e. the SWACT: SWitch of ACTivities)

• sending to the OMC each software or hardware fault that will appear insidethe component of the Interface Node

a Critical Path Management part

This part is in charge of the following operations at the start--up of the BSC e3cabinet:

• running some components inside the Interface Node

• setting up some components inside the Interface Node

• establishing the dialog with the Control Node

an Upgrade Management part

This part is in charge of handling the requests to upgrade the software of theInterface Node. The Control Node via the SUP_IN sends these requests

a Test and Diagnostic Management part

This part is in charge of the maintenance aspect of the Interface Node. Inaddition, it ensures the communication with the TML (Terminal LocalMaintenance) in order to do the following:

• to run the tests

• to collect various information about the Interface Node components

• to provide advanced services for:

– the I&C (Installation and Commissioning) procedures

– the maintenance procedures

a Hardware Management part

This part is in charge of supervising each procedure to test the modules via theMTM bus and the S--link interfaces located inside the back plane of the frameassembly


PE/DCL/DD/0126411--9001--126


Transcoder Node

The Transcoder Node houses the T--Node_ OAM functional group.

It gathers together the following main functions:

an Object Management part

This part is in charge of the following operations in the Transcoder Node:

• setting up each module via S--link interfaces

• providing a local defense (i.e. the SWACT: SWitch of ACTivity)

• sending to theOMC--R each software or hardware fault that will appear insidethe component of the Transcoder Node

a Critical Path Management part

This part is in charge of the following operations at the start--up of the TCU e3cabinet:

• running the components inside the Transcoder Node

• setting up the components inside the Transcoder Node

• establishing the dialog with the Control Node

an Upgrade Management part

This part is in charge of handling the requests to upgrade the software of theTranscoder Node. The Control Node via the SUP_TCU sends these requests

a Test and Diagnostic Management part

This part is in charge of the maintenance aspect of the Interface Node. Inaddition, it ensures the communication with the TML (Local MaintenanceTerminal):

• to run the tests

• to collect various information items about the Transcoder Node components

• to provide advanced services for:

– the I&C procedures

– the maintenance procedures

a Hardware Management part

This part is in charge of supervising each procedure to test the modules via theMTM bus and the S--link interfaces located inside the back plane of the frameassembly



4.3.1.2 Functional groups inside the Control Node

BSCe3/OMC--Com functional group

The BSCe3/OMC--Com functional group (see Figure 4--2) is located inside theOMU module.

The BSCe3/OMC--Com functional group is responsible for the following:enabling the communication with the OMC--Rhandling the links with the OMC--Rmanaging the different access protocols (FTAM and SEPE)ensuring:• the storage of the events when the OMC--R cannot be accessed• the relationships between the OMC--R and the OMC Services functionalgroup

The OAMC functional group is divided into the following functions:OAMC_APE association protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

OAMC_OSI OSI layer management. . . . . . . . . . . . . . . . . . . . . . . . . . . .

OAMC_FTAM file transfer management. . . . . . . . . . . . . . . . . . . . . . . . . .

BSC e3

CONTROL NODE

OAMC

OAM services

OSI

FTAMAPEOSI/FTAM

To the OMC--R via TCP/IP on Ethernet


(Common Agent)

FaultManagement

(Common Agent)


(Common Agent)

CM FM PM

OMU module

Figure 4--2 BSC e3 (Control Node): “OMC--Com” functional group


PE/DCL/DD/0126411--9001--126


OAMC_APE

The OAMC_APE provides the following services:application--oriented associations (logical data flows), which are split up asfollows:

• INIT to convey an event dedicated to the MIB state

• TRANSAC to convey operation orders requested by the OMC--Roperator and the associated answers sent back by the BSC

• FAULT to convey fault and alarm events

• UPDATE to convey orders relative to the MIB update

The association protocol is called: SEPE protocol. It is a secure protocoltransport connection management

This service is used to transport the application--oriented associations. Only onetransport connection is established by the OMC--R and it conveys all theassociations.Circular file management

This service is used by the SEPE protocol. It enables storing of all transactions(events, alarms, etc.) on the disk until the end of the downloading by theOMC--R

OAMC_OSl

The OAMC_OSI is a standard OSI protocol stack for the communication betweenthe OMC--R and the BSC e3 over the IP network.

OAMC_FTAM

The OAMC_FTAM handles the file transfer protocol and is used to:

upload the new software releases

download the result files (measures, call path tracing, debug, etc.) which are notsent directly to the OMC--R



OMC services functional group

The OMC services functional group of the BSC e3 is (see Figure 4--3):

in charge of:

• fault detection on the BSC e3 of the:

– software entities

– firmware entities

– hardware entities

• fault management of the BTSs

• fault management of the TCU e3

• precise diagnostic of the fault

• notification of the fault to the OMC--R, if needed

• action to be taken to correct the fault

• logging on disk of all faults for debug purpose

based on a hierarchical structure

The hierarchical and physical architectures contain for each function:

a CA (Common Agent)

This is themaster part of the functional entities and is locatedon theBSCboard inthe OMU module

an LA (Local Agent)

This is the slave part of the functional entities and is located on each board insideeach module (ATM--SW, OMU and TMU modules) of the Control Node.

This architecture is used to hide all software entities that interact with the OAMservices and the SWitching of the ACTivity between the passive and the activeOMUmodules. Only the software entities using the OMC services interact with theLA.

The OMC services functional group is divided into the following functions:CM Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .PM Performance Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .FM Fault Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


PE/DCL/DD/0126411--9001--126


“Supervision” functional group

CallP SS7 Other functionsLAPD

TMU module

BSC e3

CONTROL NODE

OMU module

BSCe3/OMC--Comfunctional group

APE

OMC services


(Common Agent)

FaultManagement

(Common Agent)


(Common Agent)

CM FM PM

ConfigurationManagement(Local Agent)

FaultManagement(Local Agent)

PerformanceManagement(Local Agent)

MIBShared MMSmodules

MIB

“OMC services” interfaces

SPR

SUP_IN

SUP_TCU SPPSPT

SUP_CN

Figure 4--3 BSC e3 (Control Node): AOM services functional group



CM (Configuration Management)

The CM function is located in the OMU module of the Control Node.

The CM function is in charge of the relationship with the OMC--R for theconfiguration aspects. It receives all TGEs (global operation transactions) sent bythe OMC--R (initiated or not by the operator), translates them into a Control Nodeinternal view (thismediation is performed by a dedicated module called ADM) andschedules theprocessing of these transactionsby the software present on theControlNode.

The translation discussed above is a translation of view. In fact, a logical view isused between the OMC--R and the BSC e3. Inside the BSC e3 a hardware orsoftware view is used. Each object is handled by the OMC--R via an OE (managedobject) and internally to the BSC e3 via an OA (application object). The softwarearchitecture can use several OAs for the same OE (i.e. a cell object is split intoseveral OAs one used by the CallP for the signaling management and the other forthe OAM aspect when SPR manages the site where the cell is hosted).

The OMC--R is in charge of BSC e3 operation. The operator creates a logical BSCe3 object at the OMC--R. When the communication is established between the BSCe3 and the OMC--R, the OMC--R can start to send the requests or the transactions.

A set of commands is provided to the OMC--R user:

to create a BSS network

to update a BSS network by creating new elements

to modify (lock/unlock) the existing elements

to delete the existing elements

to get all useful information about any elements in the BSS network managed bythe OMC--R (equipment and links between them)

to test a module on failure condition or diagnostic or defense action

to reset a module on failure condition or diagnostic or defense action


PE/DCL/DD/0126411--9001--126


The data related to application objects includes the following data:

static data

This data cannot be modified on line by the operator. It is stored inside a MIB(Managed Information Base) located on the shared mirrored disks

permanent data

This data can be initialized andmodified byOMC--R initiative. It can be either aparameter change on an existing MIB or the generation of a new MIB. Thisgeneration couldbe on--lineor off--line. It is archived inside a SCSI disk, which islocated in an MMS module

dynamic data

This data is directly managed by the software entities via set/get transactionscoming from OMC--R

The transactions between the OMC--R and the BSC e3 are conveyed by the SEPEprotocol data units called TGEs (global operation transactions). A TGE contains aset of TEE (elementary operation transactions). After being processed by the CMfunctions, TEE messages are translated into TEAs (application elementarytransactions) that apply to different application objects.

The permanent and static data are stored inside a data base called MIB (MAnagedInformation Base). This MIB is kept permanently synchronized with its OMC--Requivalence (BDE:OperationDataBase) via the SEPE protocol. The ”audit” actionallows the OMC--R to control this synchronization after a new connection. If not,theOMC--Rvia the SEPE protocol (build transactions) can build theMIBagain (thebuild action is the initialization of the permanent data with the same image asOMC--R.)



PM (Performance Management)

The PM function is located in the OMU module of the Control Node.

The GSM BSS observation counters (Recommendation GSM 12.04) are collectedand reported to the OMC--R.

The counters are split up into four permanent observation groups:

Real Time Observations (ORT)

This observation group corresponds to a small set of counters that can bedisplayed in real time (network supervision)

Diagnostic Observations (ODIAG)

This observation group allows observations of a small set of cells (twodiagnosticobservations per OMC--R, and four cells per BSC e3) with a large set of counters

Fast Statistic Observations (OFS)

This observation group allows statistics on a 15, 30, 60 minutes basis

General Statistic Observations (OGS)

This observation group allows statistics on a 1440 minutes (24 hours) basis (forexample specific equipment counters such as processor load)

The PM function is distributed over the OMU modules and the TMU modules ofthe Control Node. It collects measurement information provided by the softwareentities, processes them and forwards them to the OMC--R via theBSCe3/OMC--Com functional group.

The local agent parts available on each card are in charge of collecting themeasurement information. They are close to the source of information. The rate ofcollection is given by the central agent localized on the OMU module. The periodvalue is provided by the OMC--R inside the transaction that activates the collection.The consolidation of thedata (summarizationwith aBSS view) is doneat the centralagent level.

The operator can either start or stop collecting the counters.


PE/DCL/DD/0126411--9001--126


FM (Fault Management)

The FM function is located in the OMU module of the Control Node.

The FM function provides the following services:

reliable transport of the alarms or spontaneous events issued by theControl Nodesoftware entities

defense action in the case of critical Error ProcessingAlarm or overflow of ErrorProcessing Alarms

When the number of errors is over a threshold (static parameter of theMIB), the FMfunction proceeds to reset the faulty module. As the Control Node is a fault tolerantplatform, the activity is recovered either on the OMU modules, on the TMUmodules or on the ATM--SW modules.

The fault and alarm events generated by the remote BSS products are forwarded tothe FM function by the related function of the “Supervision” functional group:

SUP_CN for the Control Node in the BSC e3

SUP_IN for the Interface Node in the BSC e3

SUP_TCU for each TCU e3

SPT for each TCU 2G

SPP for the PCUSN

SPR for the BTSs

In addition, the FM function provides the ”log” files on shared mirrored disks. Innormal operation (OMC--R connected to the BSC), all events and alarms areforwarded to the OMC--R for update of the operator screen. Some log files arededicated to a local access via a TML (local maintenance terminal) and are codedin HTML format. They can be read on the TML by using any standard browser.

The fault and alarm events sent to the OMC--R contain all necessary informationfor the supervision and maintenance:

type of fault

severity

service impact

hardware impact

The hardware failure is notified directly on the related module, so that the OMC--Rcan display the faulty equipment precisely to the operator.



Supervision

The supervision functional group (see Figure 4--4) supplies the user functions(TMG, SS7, LAPD, Load Balancing etc.) with resources (mainly physical).

To perform this function, it must:

initialize resources (set up control links, load software and data as needed)

control operating resources (supervision, fault detection)

manage resource availability

In addition, it also stores on the disk the reference of the software that is downloadedin the flash memory.

Resource availability may depend on the operating status of other equipment items.Therefore, the supervision entities have to manage equipment/resource alliances.

The supervision functional group is divided into the following functions:

SUP_CN

This function supervises the Control Node resources in the OMU modules,ATM--SW modules, MMS modules and TMU modules

SUP_IN

This function supervises the Interface Node resources in the CEM, ATM--RM,8K--RM and IEM/LSA--RC modules

SUP_TCU

This function supervises the Transcoder Node resources in the CEM, TRM andIEM/LSA--RC modules of the TCU e3

SPT

This function supervises the Transcoder Node resources in the TCU 2G.

SPP

This function supervises the resources on the PCUSN.

SPR

This function supervises the resources on the BTSs.


PE/DCL/DD/0126411--9001--126


TMU module

APE

OMU moduleBSCe3/

OMC--Com

OMCservices

Basic services

SPR

SUP_IN

SupervisionSUP_CN

INTERFACE NODE

NODE_ACCESS

C--Node_OAM

CEM module

TCU e3

TRANSCODER NODE

CEM module

NODE_ACCESST--Node_OAM

BTSBTS_OAM

BTSBTS_OAM

CONTROL NODE

BSC e3

BTSBTS_OAM

TCU

SPP

PCUSN_OAM

PCUSN

SUP_TCU

TCU e3 group

(Refer to

NTP < 16 >)

TCU 2G

TCU 2G group

SPT

Figure 4--4 BSC e3 (Control Node): supervision functional group



SUP_CN

This function is installed in the OMU module and does the following:manages and supervises the other modules in the Control Node

generates event reportmessageswhen failures or state modifications occur in theBSC e3 (hardware fault detection, equipment status change, start/end of faultconditions). The SUP_CN sends these event reports to the OMC--R (via theBSCe3/OMC--Com functional group.)

provides the available resources (TMUmodules) to theLoad Balancing function

consolidates (in the plug and play procedure) the hardware view and the logicalview

SUP_IN

This function is installed inside the OMU module and handles the following:

access to the modules in the Interface Node using the dedicated LAPD links

downloading of the software of the Interface Node, in the case of upgrade, andthe forwarding of all events detected on the Interface Node

SUP_TCU

This function is installed inside the TMU module and handles the following:

access to the modules in the TCU e3 using the dedicated LAPD links

downloading of the software on TCU e3, in the case of upgrade, and theforwarding of all events detected on the Transcoder Node

SPT

This function is installed inside the TMU module and handles the following:

access to the modules in the TCU 2G using the dedicated LAPD links

downloading of the TCB software on TCU 2G, in the case of upgrade, and theforwarding of all events detected on the Transcoder Node

SPP

This function is installed inside the TMUmodule and manages the main followingfunctions:

etablishes the dialog with each PCUSN element via the Agprs interface

configures each PCUSN element via the Agprs interface

distributes the GPRS cells to each PCUSN element via the Agprs interface

configures a cell and its associated PCUSN element via the Agprs interface

attributes to the TMG the configurated cell


PE/DCL/DD/0126411--9001--126


SPR

This function is installed in the TMUmodules. It handles radio sites and individualcomponent radio parts. Each radio site is managed independently. One cell groupmanages the cells, which are associated with a collection of sites. The unit enablesthe same functions as SUP_BSC e3 (SUP_CN + SUP_IN) but focuses on the BTSsand BTS access interfaces:BTS start--up

Loading BCF and TRX radio transceiver software -- configuring data --initializing LAPD data links on the BTS and BSC e3TDMA frame priority managementradio entity management (site, TRX, cell, TDMA)resource management (supplies the TMG with radio channels)

recovering uncustomary events: informing the OMC--R of radio siteconfiguration changes or faults via the BSCe3/OMC--Com functional group(change of site/cell/TRX/TDMA status, faults detected by the BTSs andfeedback to the BSC on the Abis interface, faults detected by SUP_RDSmonitoring mechanisms)

conducting defense action: Abis interface defense by managing PCM linkredundancy and reorganizing signaling links, radio traffic defense by managingTRX redundancy

Only two TSs are necessary on an Abis PCM link to carry eight TDMA channels.The SPR handles dynamic allocation of two TSs on an Abis PCM link for a BTS.



Basic services

The basic services group houses the following functions (see Figure 4--5):

FT Fault Tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . .

LB Load Balancing. . . . . . . . . . . . . . . . . . . . . . . . . .

MESSAGING Service to exchange messages. . . . . . . . . . . . . . . . .

SM Software Management. . . . . . . . . . . . . . . . . . . . . . . . . .

UM Upgrade Management. . . . . . . . . . . . . . . . . . . . . . . . . .

T&D Test and Diagnostic Management. . . . . . . . . . . . . . . . . . . . . . . . .

OV OVerload. . . . . . . . . . . . . . . . . . . . . . . . . .

HM Hardware Management. . . . . . . . . . . . . . . . . . . . . . . . . .

Base OS Base Operating System. . . . . . . . . . . . . . . . . . . . . .


PE/DCL/DD/0126411--9001--126


CONTROL NODE

BSC e3

TMU module

SUP_CN

Supervision

Basic services

Fault Tolerance(Common Agent)

Overload(Common Agent)

SoftwareManagement

(Common Agent)

FT OV SM

FaultTolerance

(Local Agent)

Overload(Local Agent)

SoftwareManagement(Local Agent)

HM

HardwareManagement

UM

UpgradeManagement

T&D

Test andDiagnosticManagement

LB

LoadBalancing

FaultTolerance

(Local Agent)

OVerload(Local Agent)

SoftwareManagement(Local Agent)

MESSAGING

MESSAGING

Base OS

Base OS

OMU module

Figure 4--5 BSC e3 (Control Node): C--Node_OAM functional group organization



FT description

A fault tolerance application allows, in case of hardware failures:

an immediate reconfiguration of the software activities

a bearing of the service which is provided by the application

The GSM application are classified as follows:

Non FT application

In this case, the context is directly associated with a specific module. When afault appears, the application and the data are deleted.

This application is instantiated on eachmodule and dealswith the local processesand the central agent of the OMU

FT application

In this case, the application is composed of an active image and a passive image.The passive image can recover a hardware failure or a software failure, whichappears on the active image.

For theControl Node, this is doneby a single ”active instance” on a givenmodule(TMU, OMU ATM--SW modules) named ”active module” with one (or more)replicable instances named ”passive instance” which is (are) located on adifferent module named ”passive module”.

An active instance is used to perform the call processing procedures of theapplication.

A passive instance(s) is used to update the current context of the active instance.In addition the passive instance (in the case of hardware failure on the module,which houses the corresponding active instance) can take over and continue torun the application and to maintain the service provided by the application. Thispassive instancebecomes anew active instance. Thisprocess is named: SwitchofActivity or SWACT.

Figure 4--6 shows an example of a SWACToperationwith three TMUmodules.


PE/DCL/DD/0126411--9001--126


TMU 0

LWP1

LWP3

TMU 2

LWP3

(active)

LWP2

(passive)

TMU 1

LWP1

LWP2

(active)

(active)(active)

(passive)

TMU 0

LWP1

LWP3

TMU 2

LWP3

(active)

LWP2

(passive)

TMU 1

LWP1

LWP2

STEP 1: The software of the TMU modules runs without failures

STEP 2: The software of the first TMU module is down

Note: LWP = Light Weight Process.The LWP in grey indicates the new state of this one.

(active)

(passive)(active)

(passive)

LWP1

(passive)

LWP3

(passive)

Figure 4--6 Example of a SWACT operation with three TMU modules



In summary, an FT application in the Control Node contains the followingconcepts:

• an LWP (Light Weight Process)

This is the smallest entity (application instance) which can be SWACTed ormigrated. It owns memory context and communication endpoint

• an LWG (Light Weight Group)

This is a set of LWPs attached to the same cell group. The active LWP islocated on a module and the passive LWP on another module

• a CP (Core Process)

This is a set of dependent LWPs (For example: all members of a CP caninteract on a regular basis via messages).

A GSM CP (inside a TMU module) contains the following four GSMapplications (for their description refer hereafter to the CallP paragraph) inrelation with one cell group:

– TMG--CNX to enable the main TMG function

– TMG--MES to manage the SS7 connection needs

– TMG--RAD to execute radio resource procedures

– SPR to manage radio resource connections

• a cell group

For example, a cell group is composed of a software entities collection(TMG--CNX, TMG--MES, TMG--RAD and SPR) which are in charge of aradio cell area as a set of sites (or radio cells).

Each software instance is handled by an FT application instance as an LWP.

The cell group is mapped to a CP, which means that all LWPs inside a CPfollow simultaneously the same fault tolerant state: active or passive.

Figure 4--7 shows the cell group organization inside the TMU modules


PE/DCL/DD/0126411--9001--126


TMU 0 TMU 2TMU 1

Passive Active

PassiveActive

CellGroup 1

CellGroup 3

CellGroup 2

LWG(LightWeightGroup)

ActivePassive

LWPp

LWPp

LWPp

LWPp

LWPa

LWPa

LWPa

LWPa

TMG_MES

TMG_CN

TMG_RAD

SPR

ActiveCP

PassiveCP

CP (CoreProcess)

LWP(LightWeight

Process)

Cell Group 2 description

Figure 4--7 Example of a cell group with three TMU modules



LB (Load Balancing)

The LB function corresponds to the ability of the Control Node to:

evaluate the resource capacities of the Fault Tolerance application (CPU load,memory, Abis interface, Ater interface, timers) in relation to the number ofGSMobjects (TRX, PCMA, LAPD links, etc.) that will be managed

evaluate the capacity of each TMU module in relation with their hardwareversion

optimize the partitioning of the Fault Tolerance application instances on thedifferent TMUmodules in relation to the constraints which are described below

The LB function is used to:

minimize the overload problems by having the best resource distribution

distribute passive entities in order to have well balanced entities after a SWACT

The purpose of the LB function is to distribute processing in an optimal way overthe TMUmodules and to use the optimal resources inside the BSC e3. Distributingthe processing related to the different cell groups (i.e. sets of cells belonging to thesame process) ”equally” over the TMU modules. The whole processing relative toa cell group is executed on a single TMU module. The corresponding passive (orredundant) process is executed on another TMU module.

The cell groups are determined at boot time according to data associated with thecells. When a BTS is added to the BSC e3, it is added to an old or a new cell group.When a cell is added to a BTS, the corresponding cell group has more loads.

The distribution of the cell groups and the redundant processes is doneautomatically by the system at boot time as well. Each LB function allows aredistribution of the cell groups on the TMUmodules, without disturbing the calls.

The LB function is activated:

when a failure occurs on a TMU module

when a new unlocked TMU module is plugged in

when cell groups are modified (to add a BTS)

when the operator locks a TMU module

when an imbalance of the TMU CPU loads is detected by the BSC.

In this case, the load balancing can be done during non--busy hours.


PE/DCL/DD/0126411--9001--126


MESSAGING

Themessaging group provides a generic service to exchangemessages between thesoftware entities:

To take into account the migration of the software entities, the MESSAGINGapplication is closely linked with the FT application.

It performs the following functions:

translates FT address (Prefix, Occurrence, Status) into Non--FT address (Prefix,Occurrence, Rank), according to the routing table updated by FT

routes the Non--FT address to the right processor by associating thecorresponding IP address

delivers message to destination (using TCP/IP)

if there are several passive LWPs, a message is delivered to a passive LWP onlywhen this message was received by all the destination messaging entities

in the case of delivery failure, the following situations are possible:

• fault on the receiver module in the case of a recipient mailbox overflowIf the reception buffer of the LWP is full, the message is buffered into aTCP/IP stack. The overload is started

• fault on the transmitter module in the case of original overload activation(flow control)If the TCP/IP destination stack is full, the message is queued on the sendingmailbox. Emission towards other modules remains possible

SM (Software Management)

The SM function is in charge of:

launching all software entities present on the Control Node

ensuring correct sequence of start--up for the no Fault Tolerance software entities

supervising all modules in the Control Node launched by the SM

restarting a module in case of a failure



UM (Upgrade Management)

The UM group is responsible for upgrading the OMU, the TMU and the ATM--SWmodules inside the Control Node.

It interacts with the SUP_IN and the SUP_TCU to upgrade the modules inside theInterface Node or inside the Transcoder Node.

Note: For upgrading the software of eachmodule inside the Interface Node, referto paragraph 4.3.1.3 -- section UM.

Note: For upgrading the software of each module inside the Transcoder Node,refer to paragraph 4.3.1.4 -- section UM.

The various types of BSC e3 upgrades are introduced in the Table 4--1.

Modification of

BSC SW OBSCupgrade Object MIB

SWwith I/F Operator

actionsupgrade Object MIB with I/Fcompatibility actions

Structure Content Yes No

Build OffLine

MIB contentchange.

The BSC softwarerelease and theMIB prototype

remainsunchanged

X“reset off line”

“build”(automatic)

Build OnLine

MIB contentchange.

The BSC softwarerelease and theMIB prototype

remainsunchanged

X

“reset on line”(running)“build”

(automatic orcommanded)If commanded:“activate new

BDA”

UpgradeType 3

BSC softwarechange with newMIB structureand/or with interboard interface

evolution

X X

“download”“set version”“activate newversion““build“

(automatic)

UpgradeType 4

BSC softwarechange with sameMIB and no interboard interface

evolution

X

“download”“set version”“activate newversion”


PE/DCL/DD/0126411--9001--126


Modification of

BSC SW OBSCupgrade Object MIB

SWwith I/F Operator

actionsupgrade Object MIB with I/Fcompatibility actions

Structure Content Yes No

UpgradeType 5

BSC softwarechange with newMIB structure and

inter boardinterfaceevolution.MIB objects

remain the same(was called ”build

BDA N+1”)

X X

“download”“reset on line”

“build”(commanded)“set version”“activate newversion”

“validate newversion” or“cancel newversion”

UpgradeType 6

BSC softwarechange with newMIB structure and

inter boardinterfaceevolution.MIB objects

remain the same(was called ”build

BDA N+1”)

X X

“download”“reset on line”“set version”

“build”(commanded)“activate newversion”

UpgradeType 7

BSC softwarechange with thesame MIB andwith inter board

interface evolution

X

“download”“set version”“activate newversion”

Table 4--1 Type of BSC e3 upgrade



The impacts on the BSC type of upgrade on the other equipements are provided inTable 4--2.

BSC type of upgrade BSC e3Impact BTS Impact TCU e3

Impact PCUSN Impact

Build Off Line Loss of service

Build On Line Loss of service

Type 3 Loss of service

Type 4 No downtime*

Type 5** No downtime*



Note: Service means from a communications point of view.

* : means that for there is an impact only on the call setup communicationsor on the handovers, according to the time it needs for the BSC e3 to havethe new active Cell Group ready to handle the communications on a newTMU module (few seconds). There is no impact on the establishedcommunications not involved in a handover.

From a supervision point of view, for each type of BSC upgrade, theOMC--R loses the communication with the BSC e3 during few minutes(theminimum time is for theOMUSWACT and themaximum is for a resetof the Control Node), and hence is not able to handle or supervise the BSCe3.

** : not available for BSC e3

Table 4--2 Interaction of BSC e3 upgrade

WARNING: NO DSHELL COMMANDS CAN BE USED ON BSC E3 ANDTCU E3. POTENTIAL OUTAGE CAN OCCUR.

For the Control Node, all binary files, which compose a new software version, aredownloaded from the OMC--R to the MMS modules.

The OMU modules are used in dual mode and upgraded as follows:

passive OMU module is reset and updated with the new software version

when the passive OMU module is entirely recovered and correctly updated,OMU modules activity is enforced to SWACT


PE/DCL/DD/0126411--9001--126


the new active OMU module runs with the new version

Note: This version can interact with the old or the new software version of theTMU module.

the new passive OMU module is reset and updated with the new version

The TMUmodules are upgraded in real time with the N+P redundancy mode. Eachof them is upgraded one after the other as follows:

the TMUmodule is relieved of all its processes so that service (active processes)and redundancy (passive processes) are entirely supported by the other TMUmodules

when entirely isolated, the TMUmodule is reset and booted on the new softwareversion (the flash inside the TMU module is updated at this time)

once recovered, the TMU module joins the group to retrieve the applicativeprocesses it hosted previously to the upgrade

The ATM--SW modules are used in dual mode and upgraded as follows:

the active ATM--SWmodule is reset and booted on the new version. At this timeall ATM messaging is still routed by the passive ATM--SW module

once recovered the active ATM--SW module retrieves the AAL--1 dynamicconfiguration (from the passive ATM--SW module or the active OMUmodule)

the passive ATM--SW module may be upgraded on its turn

At TMU module level, AAL--1 reception is done from only one of the two ATMplanes.

T&D (Test and Diagnostic) management

The T&Dmanagement function is used to test and to diagnose each software entityinside the Control Node.

These operations are used by:

the various software entities of the Control Node to notify the operator of:

• the detection of failures in a module

• the faulty component in the module with the best accuracy

the I&C and maintenance procedures to check:

• the possible damage during the transportation of the Control Node to the site

• that the installation is running correctly

• that the Control Node is available for integration in the network



OV (OVerload)

The BSC e3 robustness in overload conditions is ensured by a centralized overloadcontrolmechanismwhich is based on the same principles as for the overload controlimplemented for the BSC 2G.

The OV function monitors:

the processor loads

the memory images

The TMU module is the main module subject to overload.

Note: the OMUmodule is not involved in the GSM traffic processing, so its loadis not impacted by the traffic level variations.For this module, the critical resources monitored are: CPU load, systemmemory occupancy, etc. These parameters are used to compute a syntheticload of the module.

Eachmodule reports its synthetic load to theOMU,which controls globally the loadstate of the BSC e3 and triggers the appropriate actions according to the boards thatare in overload (TMU module, ATM--SW module) and to the level of overload.

The TMUmodules are rather independent one with respect to the other in terms ofoverload handling. Since a TMU module manages the whole traffic of a group ofcells, so when a TMUmodule is in overload, it will filter partially the new comingtraffic requests related to the group of cells it manages.

Counters giving the processor synthetic loads and the number of filtered operationsby type are provided. Those counters give the operator a detailed viewof the filteredtraffic and processor loads during overload conditions, allowing him to plan theBSC e3 capacity evolution in his network.

The overload thresholds are a part of the BSC e3 parameters. One nominal valuewill be used for this parameter. To the value of this parameter are associated the setsof overload thresholds for each monitored processing modules. This nominal valueensures both the BSC e3 robustness and a nominal level of carried traffic.

The overload levels are defined in the BSC e3. Each level corresponds to the loadlevel or the defense level of the BSC e3 processors.


PE/DCL/DD/0126411--9001--126


overload levels:

According to the overload level, someamount of new traffic requests are filtered:

• overload level 1 (OV1):

It allows a traffic reduction by filtering 1 request out of 3 of the followingmessages:

– paging request

– channel request with cause different from “Emergency call”

– all First Layer 3 messages with cause different from “Emergency call”

– handover for traffic reason

– handover for OAM reason

– directed retry


It allows a traffic reduction by filtering 2 requests out of 3 of the abovemessages


No new traffic is accepted by filtering all previous and following messages:

– all First Layer 3 messages

– all Channel Requests (including cause for ”Emergency Call”)

– all Handover Indications

– all Handover Requests

• overload level 4 (OV4) and overload level 5 (OV5): Not used



HM (Hardware management)

The HM function is in charge of the interactions with the hardware components onthe modules for the plug and play features.

The Control Node offers “plug and play“ (or auto discovery) capability for theBSC e3 cabinet start--up and for the module hot insertion. This means that themodules are automatically:

detected

started

configured

Base OS

The base Operating System provides an abstract view of the OS for the upper layersoftwares and the basic software services that are necessary for running softwareon this system.

The Control Node hosts the following Operating Systems:

a UNIX Operating System (AIX)

It is located inside the OMU--SBC board which is in charge of the operations andthe maintenance.

It contains a high level standard communication service (TCP, UDP, IP, etc.)

a real--time Operating System (VxWorks)

It is located on all other Control Node processors, which are in charge of thetraffic management, the input functions and the output functions.

It contains:

• a disk storage management

• some standard communications facilities


PE/DCL/DD/0126411--9001--126


4.3.1.3 Functional groups inside the Interface Node

The Interface Node is the connectivity component of the BSC e3 and it is fullydriven by the Control Node.

It provides the following main functions:

manages the connections:

• between each module in the Interface Node

• between the Interface Node and:

– the BTSs (Abis interface)

– the TCU e3s (Ater interface)

– the PCUSN (Agprs interface)

manages each module inside the Interface Node

provides the ATM links via the ATM--RMmodule to connect the Interface Nodewith the Control Node

It houses the following functional groups:

inside each CEM module:• Interface NODE_ACCESS• I--Node_OAM• SAPI (Standalone API)• Base Maintenance

inside each ATM--RM module:

• RM_OAM_Generic

• ATM_OAM_Specific

inside each 8K--RM module:

• RM_OAM_Generic

• 8K_OAM_Specific

inside each LSA--RC module:

• RM_OAM_Generic

• LSA_OAM_Specific

Figure 4--8 shows each of the functional groups and their main functions inside theInterface Node without the redundancy modules.



CEM module

INTERFACE NODE

CONTROL NODE

Supervision

SUP_IN

IN_OAM

Critical pathmanagement

BSC e3

Interface

node

access

GSM PCMmanagement

GSM objectmanagementGSM object

managementGSM objectmanagement

Upgrademanagement

Tests & diagmanagement

Standalone API (SAPI)

SAPI PCMmanagement

SAPI objectmanagement

Base maintenance

Common carriermaintenance

Hardwaremanagement

SAPI objectmanagement Hardware

managementSAPI objectmanagement Hardware

management

Messaging

Base OS

Connectionmanagement

OMU

LSA_OAM_SPECIFICATM_OAM_SPECIFIC

Hardware management(Slink, CPU, TIM block)

Upgrade dowloading

Test actor

Fault actor

8K--RM ATM--RM LSA--RC


Upgrade dowloading

Test actor

Fault actor


Upgrade dowloading

Test actor

Fault actor

Base OSBase OS Base OS

8K_OAM_SPECIFIC

RM_O

AM_G

ENERIC

Test actor

Fault actor

Test actor

Fault actor

LSA carrier maintenance

Test actor

Fault actor

Figure 4--8 BSC e3 (Interface node): functional group organization


PE/DCL/DD/0126411--9001--126


Interface NODE_ACCESS

The Interface NODE_ACCESS interface is at the front of the Control Node.

It ensures the transfer ofCallP andOAMinformationbetween theControl Nodeandthe Interface Node via TCP/IP over the ATM networks (AAL--5).

Two types of message are transferred:

OAM messages

CallP messages

It manages the following main functions:

channel management

IP address identification

Critical path resolution at the start up of the Interface Node

I--Node--OAM

The I--Node--OAM functional group is used:

to configure and to supervise each:

• CEM module

• ATM--RM module

• 8K--RM module

• IEM module housed inside each LSA--RC module

• external PCM (E1/T1) link for the Abis interface and the Ater interface

to perform the following operations:

• report each software or hardware failure which appears on an RMor amodule

• manage the defense actions

• run the tests

to provide the Control Node with a logic view of each software entity in theInterface Node



GSM PCM description

TheGSMPCM functionmanages the PCM (E1/T1) links on theAbis interface side(between theBSCe3 and theBTSs) and thePCM(E1/T1) links on theAter interfaceside (between the BSC e3 and the TCU e3).

The PCM (E1/T1) links connecting the BSC e3 with the BTS and the BSC e3 withthe TCU e3 are considered as an object of the BSS and are designated: PCMobject.

Using the configuration and operation data provided by the BSC e3, the PCM linkmanagement configures and monitors the PCM link transmission supports for allthe associated external and internal PCM (E1/T1) links.

The PCM management generates PCM operational status indications for whichchanges are transmitted to the BSC e3. The external PCM links are operational assoon as the BSC e3 starts up.

The GSM PCM management function performs the following main operations:

create a PCM (E1/T1) link

delete a PCM (E1/T1) link

change the administrative status of a PCM (E1/T1) link

notifiy the fault and the alarm events


PE/DCL/DD/0126411--9001--126


GSM object

The GSM object management group is used to:

ensure:

• the supervision of each:

– CEM module

– 8K--RM module

– ATM--RM module

– IEM module housed inside a LSA--RC module

• object creation in accordance with object hierarchy

• the communication between an external element and the following functionalgroups:

– the SAPI (Standalone API)

– the node access

use the services of the SAPI objects to:

• manage themediation between the I--Node_OAMand the Spectrumplatform

• provide a mediation function between the Control Node and the InterfaceNode

It manages the following two types of GSM object:

physical objects

Each of them corresponds to a physical module

logical objects

Each of them represents a group of physical objects (group of CEM modules orgroup of RMs) which is named: protection group.

A protection group contains:

• aworking instance that corresponds to an activeCEMmodule or an activeRM

• a spare instance that corresponds to a passive CEM module or a passive RM

Critical path

The critical path management function is only used at the start up of the BSC e3.It acts as a substitute for the Control Node and handles the startup of the CEMmodules and the ATM--RM modules during the initialization step. Then, it allowsthe first dialog with the Control Node via the ATM--RM modules.




The UM function is responsible for upgrading the software of each module insidethe Interface Node. It enables the transition from a first working state to a new oneby changing the software version of the module(s).

Note: For upgrading the software of each module inside the Control Node, referto paragraph 4.3.1.2 -- section UM, Table 4--1, and Table 4--2.

Note: For upgrading the software of each module inside the Transcoder Node,refer to paragraph 4.3.1.4 -- section UM.

The software upgrade of a module is requested:

by the OMC--R via the OMU module located in the Control Node

or directly by the TML connected to:

• the OMU module located on the Control Node

• the optional HUB(s)

• or if failure is not detected, by theCEMmodule located on the InterfaceNode

The first phase of the software upgrade can be made a long time before the upgradeof amodule. It transfers the upgrading data to theMIB (Managed InformationBase)located in the ”private” disk located in the Control Node. This operation is donewhen the BSC e3 is working without any service disturbance (except the bandwidthreduction.)

Then, the Control Node sends upgrade orders to the CEMmodule which managesthe upgrade of the concerned module.

For the CEMmodules and the RMs, with the following redundancy factor: 1+1, theupgrading of this protection group is done as follows:

the loading of the software packages is running inside the passive RM or thepassive CEM module

a SWACT is running between:

• the passive CEM module and the active CEM module

• the active RM and the passive RM


PE/DCL/DD/0126411--9001--126



The T&D management group is used to test and to diagnose each software entityin the Interface Node. These operations are used by:

the various software entities of the Interface Node to notify the operator of:



the I&C (Installation and Commissioning) procedures to check:

• the possible damage during the transportation of the Interface Node to the site


• that the Interface Node is available for integration in the GSM network


SAPI

The main parts of the SAPI services are located inside the CEM modules.

The SAPi provides the OMC services independently of the platform and theapplication which are running on this platform.

It offers also an interface to manage links, physical and logical devices that areabstracted into objects.

It supplies a consistent, stable interface maintenance operations on the InterfaceNode.

SAPI PCM

TheSAPI PCMmanagesand supervisesPCM(E1/T1) links, which are located insidethe LSA--RC module. It provides a logical view of the PCM (E1/T1) links to lockor unlock each of them. Each PCM (E1/T1) instance of an Interface Node isincluded inside a Pool_PCM object. This object corresponds to all PCM (E1/T1)links on all IEM modules.

SAPI object

The SAPI object provides the following services:

gives the activity status (active or passive) for each CEM module

gives the list of the modules inside the Interface Node

gives the slot number of the active CEM module

gives the slot number of the passive CEM module

notifies the SWACT for the CEM modules

handles the CEM, the 8K--RM, the ATM--RM and the LSA--RC modules

ensures data synchronization between theCEMmodules in the case of a SWACT

gives a direct OAM interface with each RM



Base Maintenance

The base maintenance function is closely linked to the Spectrum hardware conceptand is located in both CEM modules.

It performs the following operations:

provides all themechanisms for eachmodule to perform the following functions:

• administration

• provisioning

• duplex mode

communicates with the RM_OAM_Generic functional group which is locatedinside each:

• ATM--RM module

• 8K--RM module

• LSA--RC module

Common carrier maintenance

This function is closely linked to the Spectrumhardware concept. It is located insideboth CEMmodules. It is in charge of provisionning, implementing and monitoringthe PCM (E1/T1) links inside the Interface Node.

It is used to:

support GSM--E1 and GSM--T1 carrier types

configure and supervise each of the PCM (E1/T1) links which are located insidethe LSA--RC module and dedicated to:

• the BTS(s) via the Abis interface

• the TCU e3 via the Ater interface

Carrier Maintenance, exclusively via the SAPI interface:

provides carrier related information

accepts the carrier

These interactions contain:

carrier provisioning (addition and deletion)

carrier state change (locked/unlocked, enabled/disabled)

carrier state change notification

carrier fault notification

carrier performance monitoring reports


PE/DCL/DD/0126411--9001--126


HM (Hardware management)

The modules inside the Interface Node are “hot insert/extract“. That means that ahardware module can be replaced (repaired) or added (capacity extension) in theequipmentwithout shutting down even partially the InterfaceNode andwithout anyservice impact.

Furthermore, the Interface Node offers “plug and play“ (or auto discovery)capability for the BSC e3 cabinet start--up and for the module hot insertion. Thismeans that the modules are automatically detected.

Messaging

Themessaging function is used to transmit various information items between eachsoftware entity of the different modules located inside the Interface Node via theS--link interfaces.

CM (Connection Management)

The CM function is used to connect the DS0 links via the 64K switch which islocated inside the CEM module.

Base OS (Base Operating System)

The Base OS provides:

an abstract view of the OS (Operating System) for the upper layer softwares

the basic software services that are necessary to run the software on this system

The Interface Node hosts the VRTX Operating Systems, which is in charge of:

OS resource management

• tasks

• queues

• semaphores

• etc.

memory management

debug shell management

logging management



RM_OAM_Generic

The RM_OAM_Generic functional group is located inside each RM. It superviseseach software entity inside each RM.

Note: An LSA logic object, which manages both physical objects, identifies theLSA--RC module. Each of both physical objects corresponds to each IEMmodule.

It is used to manage:

reset

S--link redundancy

the MTM bus

plug and play

the BIST (Built In Self Test)

Upgrade downloading

The upgrade downloading function is a local agent. It is used to run in the RM eachupgrade command sent by the UM (Upgrade Management) function located insidethe CEM module.

Test actor

The test actor is a local agent. It is used to run and to supervise the hardware testsinside each RM for the following components:

CPU

S--link redundancy

ITM block

These tests are punctual. They are carried out:

at start up

every 30 minutes

after an operator request from the TML or from the OMC--R


PE/DCL/DD/0126411--9001--126


Fault actor

The Fault actor is a local agent. It is used to run and to supervise the software faultsinside the RM for the following components:

CPU

S--link redundancy

ITM block

These faults are carried out when the module provides some services.

Base OS description

The Base OS (Base Operating System) provides:



The Interface Node hosts the VRTX Operating Systems, which is in charge of:

OS resources management

• tasks

• queues

• semaphores

• etc.

memory management

debug shell management

logging management



ATM_OAM_Specific

The ATM_OAM_Specific group is closely linked to the Spectrum hardwareconcept.

It is used to manage the specific parts of configuration messaging that aretransmitted to the ATM--RM modules.

Test actor

The test actor is also named: device dialog interface container.

A contained actor is a subclass and is also a container for the device diagnosticinterface container. Each contained actor is optional and is created during theinitialization steps.

The test actor for the 8K--RM module contains the following actors:

PROC/Module test actor

This actor is used as an interface with the HAL (Hardware Abstract Level)processor to invoke the tests on the RM host processor when the services arerunning or are out of order. This component is a part of the Spectrummaintenance framework

S--link test actor

This actor is used as an interface with the HAL S--link to invoke the tests on theS--link interfaces when the services are running or are out of order. Thiscomponent is a part of the Spectrum maintenance framework

ITM block test actor

This actor is used as an interface with the integrated HAL test manager to invokethe tests on the ITMblock in theATM--RMmodulewhen the services are runningor are out of order. This component is a part of the Spectrum maintenanceframework

ATM test actor

This actor is used as an interface with the ATM HAL to invoke the tests on thehardware responsible for the conversion from DS0 into ATM cells, and viceversa, when the services are running or are out of order. This component is a partof the Spectrum maintenance framework


PE/DCL/DD/0126411--9001--126


Fault actor

The fault actor is also named: device test interface container.

A contained actor is a subclass and is also a container for the device test interfacecontainer. Each contained actor is optional and is created during the initializationsteps.

It contains the following actors:

ITM fault actor

This actor is used as an interface with the ITM HAL to receive and process anyfaults that may be reported by the ITM HAL. This component is a part of theSpectrum maintenance framework

PROC/Module fault actor

This actor is used as an interface with the PROCHAL to receive and process anyfaults that may be reported by the PROC HAL. This component is a part of theSpectrum maintenance framework

S--link fault actor

This actor is used as an interface with the S--link HAL to receive and process anyfaults that may be reported by the S--link HAL. This component is a part of theSpectrum maintenance framework

ATM fault actor

This actor is used as an interface with the ATMHAL to receive and process anyfaults that may be reported by the ATMHAL. This actor needs to be created andthe following object model shows the datamembers andmethods that need to beoverwritten



8K_OAM_Specific

The 8K_OAM_Specific is closely linked to the Spectrum hardware concept.

Hardware management

The hardware management function controls the specific part of the configurationmessaging which are transmitted to the 8K--RM module.

Test actor


A contained actor is a subclass and is also a container for the device diagnosticinterface container. Each contained actor is optional and is created during theinitialization steps.

The test actor for the 8K--RM module contains the following actors:


This actor is used as an interface with the HAL processor to invoke the tests onthe RM host processor when the services are running or are out of order. Thiscomponent is a part of the Spectrum maintenance framework

S--Link test actor


ITM test actor

This actor is used as an interface with the integrated HAL test manager to invokethe tests on the ITM block in the 8K--RMmodule when the services are runningor are out of order. This component is a part of the Spectrum maintenanceframework

8K--RM Switching Matrix

This actor is used as an interface with the HAL Switching Matrix through thediagnostic layer to invoke the tests on the SRT hardware when the services arerunning or are out of order. This actor needs to be created and the followingobject model shows the data members and methods that need to be overwritten

8K--RM Channel Sequencer

This actor is used as an interface with HAL Channel Sequencer through thediagnostic layer to invoke the tests on the channel sequencer hardware theservices are running or are out of order. This actor needs to be created and thefollowing object model shows the data members and methods that need to beoverwritten


PE/DCL/DD/0126411--9001--126


Fault actor


A contained actor is a subclass and is also a container for the device test interfacecontainer. All the contained actors are optional and are created during theinitialization steps.


ITM fault actor

This actor is used to interfacewith the ITMHAL to receive andprocess any faultsthat may be reported by the ITMHAL. This component is a part of the Spectrummaintenance framework


This actor is used to interface with the PROC HAL to receive and process anyfaults that may be reported by the PROC HAL. This component is a part of theSpectrum maintenance framework

S--link fault actor

This actor is used to interface with the S--link HAL to receive and process anyfaults that may be reported by the S--link HAL.This component is a part of theSpectrum maintenance framework

Switching Matrix fault actor

This actor is used to interface with the Switching Matrix HAL IF to receive andprocess any faults that may be reported. This actor needs to be created and thefollowing object model shows the data members and methods that need to beoverwritten

Channel Sequencer fault actor

This actor is used to interfacewith theChannel SequencerHAL IF to receive andprocess any faults that may be reported. This actor needs to be created and thefollowing object model shows the data members and methods that need to beoverwritten



LSA_OAM_Specific

The LSA_OAM_Specific group is closely linked to the Spectrum hardwareconcept.

It is identified by an LSA object, which manages two objects. Each of themcorresponds to an IEM module.

LSA Carrier Maintenance

The LSA Carrier Maintenance function is located inside each IEM module. Itmanages the provisioning data and provides interfaces with the following services,for the PCM E1 links or the PCM T1 links:

configuration

supervision

reporting the software or hardware faults to the OMC--R

It will give also the service requests to:

change carrier states

change monitor defects

provide support for the SWicht of ACTivities of the CEM modules and the RMsparing

It must support software interfaces to several components.

These interfaces contain:

SAPI

The SAPI acts as the HMI interface in a stand--alone mode. Each PCM (E1/T1)configuration data and carrier state change request is received via the SAPIinterface. The detailed interface specifications will be captured in the CD(Component Description)

CARML

LSACarrier Maintenance reuses the base carrier maintenance framework in theCEM module and the IEM module located inside the LSA--RC module

HAL

The carrier maintenance is interfaced with the Hardware via the carrier deviceagent to:

• register the fault notifications

• notify the state changes

It is used to manage and to record the PCM faults which are described below


PE/DCL/DD/0126411--9001--126


The PCM fault priorities are listed below in descending order:

for the PCM E1 links:

• LOS Loss Of Signal. . . . . . . . . . . . . . . . . . . . . . .

• AIS Alarm Indication Signal. . . . . . . . . . . . . . . . . . . . . . . .

• LFA Loss of Frame Alignment. . . . . . . . . . . . . . . . . . . . . . .

• RAI Remote Alarm Indication. . . . . . . . . . . . . . . . . . . . . . . .

for the PCM T1 links:



• LOF Loss Of Frame alignment. . . . . . . . . . . . . . . . . . . . . . .


The PCM fault(s) (collection of contiguous faults) can result in a failure that has tobe reported to the GSM applications if they reach a threshold. This threshold iscalled the FBT (Fault Begin Time). On a fault notification, the number of faultyseconds based on the fault type needs to be reported. A second can be faulty for onefault only. If two faults occur in one second, the fault priority will be used todetermine which one to peg.

The quantity of faults reported in a message is equal to the FBT.

The provisional threshold that will determine the termination of a failure is namedFET (Fault EndTime). If there is no defect detected over a period of FET, then thereneeds to be a failure cleared notification sent to the GSM applications.

Test actor


A contained actor is a subclass and is also a container for the device diagnosticinterface container. All the contained actors are optional and are created during theinitialization steps.

The test actor for the LSA--RC module contains the following actors:



S--Link test actor




ITM test actor

This actor is used as an interface with the integrated HAL test manager to invokethe tests on the ITMblockwhen the services are running or are out of order. Thiscomponent is a part of the Spectrum maintenance framework

CARM test actor

This actor is used as an interface with HAL PCM through the diagnostic layer toinvoke the tests on the PCM links when the services are running or are out oforder. This component is a part of the Spectrum maintenance framework

HDLC test actor

This actor is used as an interfacewithHALHDLCthrough thediagnostic layer toinvoke the tests on the HDLC level when the services are running or are out oforder. This component is a part of the Spectrum maintenance framework

Fault actor


A contained actor is a subclass and is also a container for the device test interfacecontainer. All the contained actors are optional and are created during theinitialization steps.


ITM fault actor




S--link fault actor

This actor is used as an interfacewith the S--LinkHAL to receive and process anyfaults that may be reported by the S--Link HAL. This component is a part of theSpectrum maintenance framework

CARM fault actor

This actor is used as an interfacewith theCARMHAL to receive and process anyfaults that may be reported by the PCMHAL. This actor needs to be created andthe following object model shows the datamembers andmethods that need to beoverwritten


PE/DCL/DD/0126411--9001--126


4.3.1.4 Functional groups inside the Transcoder Node

The Transcoder Node is a connectivity component. It is fully driven by the ControlNode.

It provides the following main functions:

manages the connections:

• of each module in the Transcoder Node

• between the Transcoder Node and:

– the BSC e3 (Ater interface)

– the MSC (A interface)

manages each component inside the Transcoder Node

supervises the physical links (S--link interfaces)

It houses the following functional group:

inside each CEM module:• Transcoder NODE_ACCESS• T--Node_OAM• SAPI (Stand alone API)• Base Maintenance

inside the LSA--RC module:

• RM_OAM_Generic

• LSA_OAM_Specific

inside the TRM module:

• RM_OAM_Generic

• TRM_OAM_Specific

Figure 4--9 shows each functional group and their main components inside theTranscoder Node without the redundancy modules.



TCU e3

CEM module

TRANSCODER NODE

CONTROL NODE

TN_OAM

Critical pathmanagement

BSC e3

Transcodernode

access

GSM PCMmanagement

GSM objectmanagementGSM object

management

Upgrademanagement

Tests & diagmanagement

Standalone API (SAPI)

SAPI PCMmanagement

Base maintenance

Common carriermaintenance

SAPI objectmanagement Hardware

managementSAPI objectmanagement Hardware

management

Messaging

Base OS

Connectionmanagement

LSA_OAM_SPECIFIC

LSA--RC

Test actor

Fault actor

LSA carrier maintenance

TRM_OAM_SPECIFIC

TRM

Test actor

Fault actor


Upgrade dowloading

Test actor

Fault actor

Base OS

RM_O

AM_G

ENERIC


Upgrade dowloading

Test actor

Fault actor

Base OS

TMUSupervision

SUP_TCU

TCU e3 group

Figure 4--9 TCU e3 (Transcoder Node): Functional group organization


PE/DCL/DD/0126411--9001--126


Transcoder NODE_ACCESS

The Transcoder NODE_ACCESS interface is at the front of the Control Node.

It ensures the transfer of the CallP and the OAM information between the ControlNode and the Transcoder Node via the Interface Node and the LSA--RC modulelocated inside the Transcoder Node.

Both types of message are transferred:

OAM messages

CallP messages

The Transcoder Node performs the following main functions:

channel management

IP address identification

Critical path resolution at the start up of the Interface Node

T--Node_OAM functional group

The T--Node_OAM functional group is used to configure and supervise each:

CEM module

ATM--RM and TRM modules

IEM module housed inside each LSA--RC module

PCM (E1/T1) links on the A interface and the Ater interface

It performs the following functions:

report each software or hardware fault which appears on each RM and CEMmodule

manage the defense actions

run the tests

It provides the Control Node with a logical view of each software entity in theTranscoder Node



GSM PCM

This function manages the PCMA (E1/T1) links on the A interface side (betweenthe TCU e3 and the MSC), and the PCM (E1/T1) links on the Ater interface side(between the TCU e3 and the BSC e3).

The PCM (E1/T1) link connecting the TCU e3 and the MSC is considered as anobject of the BSS. It is called: PCMA object.

The PCM (E1/T1) link connecting the TCU e3 and the BSCe3 is considered as anobject of the BSS. It is called: PCM object.

Using the configuration and operational data provided by the BSC, the PCM linkmanagement function configures and monitors the PCM link transmission.

The PCMA management function generates PCMA operational status indicationsfor those changes which are transmitted to the BSC.

The external PCM links are operational as soon as the TCU e3 starts up.

The ”GSM PCM management” function manages the following main operations:

creates a PCM (E1/T1) link

deletes a PCM (E1/T1) link

changes the administrative status of a PCM (E1/T1) link

notifies the fault and the alarm events

notifies the faults


PE/DCL/DD/0126411--9001--126


GSM object

This GSM object management group ensures supervision of each:

CEM module

TRM module

IEM module housed inside an LSA--RC module

This group ensures object creation with the respect to the object hierarchy

This group ensures communication between an external element and the followingimported objects:

the SAPI (Standalone API)

the node access

This group uses the services of the SAPI objects to:

manage mediation between the T--Node_OAM and the Spectrum platform

provide a mediation function between the Control Node and the TranscoderNode

This group manages the following two types of GSM object:

physical objects

Each of them corresponds to a physical module

logical objects

They represent a group of physical objects (group of CEMmodules or group ofRMs) which is named: the protection group.

A protection group contains:

• a working instance which corresponds to an active CEMmodule or an activeRM

• a spare instancewhich corresponds to a passive CEMmodule or a passiveRM

For the TRM module, each of them is active. Also all RMs are inside the sameprotection group

Critical path management

The critical path management function is only used at the start--up of the TCU e3.It acts as a substitute for the Control Node. It handles the startup of the CEMmodules and the LSA--RC module during the initialization step. It runs the LAPDchannels on the specific PCMs for each LSA. Then, it allows the first dialog withthe Control Node (Ater interface) via the Interface Node and the LSA--RC modulelocated inside the Transcoder Node.




The UM function is responsible for upgrading the software of each module insidethe Transcoder Node. It allows transition from a first working state to a new one bychanging the software version of the modules.

Note: For upgrading the software of each module inside the Control Node, referto paragraph 4.3.1.2 -- section UM.

Note: For upgrading the software of eachmodule inside the Interface Node, referto paragraph 4.3.1.3 -- section UM.

The various types of TCU e3 upgrades are introduced in the Table 4--3.

UpgradeTCU Object

Modification ofSW

with I/Fcompatibility

Operatoractions Impacts

Yes No

Backgrounddownloading

The TCUsoftware releasewith interfacecompatibility

X“set version”“activate newversion”

No downtime*

Download atthe startup

The TCUsoftware releasewith no interfacecompatibility

X

“lock TCU”“set version”“activate newversion”

“unlock TCU”

Loss of TCUservice

Note: * : There is no downtimewith this kind of upgrade, but according to the softblocking feature, established communications may be lost when theassociated TRM module is reset.

Table 4--3 Type of TCU e3 upgrade

The software upgrade of a module is requested:

by the OMC--R via the OMU module located inside the Control Node

or directly by the TML connected to:

• the OMU module located on the Control Node

• the optional HUB(s)

• the CEM module located on the Interface Node if the failure is not detected


PE/DCL/DD/0126411--9001--126


The first phase of the software upgrade can be made a long time before the upgradeof amodule. It transfers the upgrading data to theMIB (Managed InformationBase)located in the ”private” disk of the Control Node. This operation is done when theBSC e3 is working without any service disturbance (except the bandwidthreduction.)

Then the Control Node sends upgrade orders to the CEM module which managesthe upgrade of the concerned module, without breakdown of the services which arerunning.

For the CEMmodules and the RMs, with the following redundancy factor: 1+1, theupgrading of this protection group is done as follows:

the load software packages are running in the passive RM or the passive CEMmodule

a SWACT is running between:

• the active RM and the passive RM

• or the passive CEM module and the active CEM module

For the TRM modules with the following redundancy factor: N+P, the upgradingof the protection group is done as follows:

a “soft blocking” is sent to the TRM concerned

the new communications are distributed to the another TRM

when the communications in progress inside the concerned TRM areaccomplished, then the software upgrading is done


The T&Dmanagement function is used to test and to diagnose each software entityin the Transcoder Node.

These operations are used by :

the various software entities of the Transcoder Node to notify the operator of:



the I&C (Installation and Commissioning) procedures to check:

• the possible damage during the transportation of the Transcoder Node to thesite


• that the Transcoder Node is available for integration in the network




SAPI description

All SAPI services are located inside the CEM modules, except for some serviceslike the “software upgrade” service, which are located on the CEM modules, andthe TRM module or the LSA--RC module.

The SAPI provides an OMC service independently of the platform and theapplication which is running on this platform.

In addition, the SAPI offers an interface to manage links, physical and logicaldevices that are abstracted into objects.

SAPI PCM

The SAPI PCMmanages and supervises each of the PCM (E1/T1) links, which arelocated inside the LSA--RC module. It provides a logic view of the PCM (E1/T1)links to lock/unlock each of them. Each PCM (E1/T1) instance of a TranscoderNode is included inside the Pool_PCMobject. This object corresponds to all PCMson all IEM modules.

SAPI object

The SAPI object provides the following services:

gives the activity status (active/passive)

gives the list of the modules inside the Interface Node

gives the slot number of the active CEM module

gives the slot number of the passive CEM module

notifies the SWACT

handles the CEM, TRM and the LSA--RC modules

ensures the data synchronization between theCEMmodules in case of a SWACT

gives a direct OAM interface with the each module


PE/DCL/DD/0126411--9001--126


Base maintenance

The basemaintenance group is closely linked to the Spectrumhardware concept andis located inside both CEM modules.

This group provides all the mechanisms for each module to do the following:

administration

provisioning

duplex features

This group communicates with the RM_OAM_Generic functional group which islocated inside each:

CEM module

TRM module

LSA--RC module

Common carrier maintenance

The common carrier maintenance function is closely linked to the Spectrumhardware concept. It is located inside both CEM modules. It is in charge ofprovisioning, implementing and monitoring the PCM (E1/T1) links inside theTranscoder Node.

It is used to:

support GSM--E1 and GSM--T1 carrier types

configure and supervise each of the PCM (E1/T1) links which are located insidethe LSA--RC module and are dedicated to:

• the MSC via the A interface

• the BSC e3 via the Ater interface

Carrier Maintenance via the SAPI interface provides carrier related information,and accepts carriers.

These interactions include:

carrier provisioning (addition and deletion)

carrier state change (locked/unlocked, enabled/disabled)

carrier state change notification

carrier fault notification

carrier performance monitoring reports



HM (Hardware Management)

The modules inside the Transcoder Node are “hot inserted/extracted“. This meansthat a hardware module can be replaced (repaired) or added (capacity extension) inthe equipment without shutting down even partially the Interface Node andwithoutany service impact.

Furthermore, the Transcoder Node offers “plug and play“ (or auto discovery)capability for the TCU e3 cabinet start--up and for the module hot insertion. Thismeans that the modules are automatically detected.

Messaging

The messaging function is used to transmit different information between eachsoftware entity of the different modules located inside the Transcoder Node via thethe S--link interfaces.

Connection management

It is used to connect the DS0s via the Switch 64K which is located inside the CEMmodule.

Base OS (Operating System)

The Base OS provides:



The Interface Node hosts the VTRX Operating Systems, which is in charge of:

the OS resources management

• tasks

• queues

• semaphores

• etc.

the memory management

the debug shell management

the logging management


PE/DCL/DD/0126411--9001--126


RM_OAM_Generic

The RM_OAM_Generic group is located in each RM. It supervises each softwareentity inside each RM.

Note: The LSA--RC module is identified by an LSA logic object which managesboth physical objects. Each of them corresponds to each IEM module.

It is used to manage:

reset

S--links redundancy

the MTM bus

plug and play

the BIST (Built In Self Test)

Upgrade downloading

The upgrade downloading function is a local agent. It enables each upgradecommand sent by the UM function which is located inside the CEMmodule to runinside the RM.

Test actor

The test actor is a local agent. It is used to run and to supervise the hardware testsinside each RM for the following components:

CPU

S--link redundancy

ITM block

These tests are punctual. They are carried out:

at start--up

every 30 minutes

after an operator request from the TML or from the OMC--R.



Fault actor

The fault actor is a local agent. It is used to run and to supervise the software faultsinside each RM for the following components:

CPU

S--link redundancy

ITM block

These faults are carried out when the module provides some services.

Base OS (Operating System)

The Base OS manages the hardware resources of the operating system to providethe necessary basic services to run the software resources on this operating system.

The Base OS is used to perform the following:

animation and synchronization of software in a real--time environment

operation and maintenance actions

communication between each node through standard interfaces

The Interface Node hosts the VRTX Operating System, which is in charge of:

• OS resource management (tasks, queues, semaphores, etc.)

• memory management

• debug shell management

• logging management


PE/DCL/DD/0126411--9001--126


LSA_OAM_Specific

The LSA_OAM_Specific group is closely linked to the Spectrum hardwareconcept.

It is identified by an LSA object, which manages two objects. Each of themcorresponds to an IEM module.

LSA Carrier Maintenance

The LSA Carrier Maintenance function is located inside each IEM module. Itmanages the provisioning data and provides, for the PCME1 or PCMT1 interfaces,the following services:

configuration

supervision

reporting the software or hardware faults to the OMC--R

It will also give the service requests to:

change carrier states

change monitor defects

provide support for CEM SWACT and RM sparing

It must support software interfaces to several components.

These interfaces contain:

SAPI

The SAPI acts as the HMI interface in a stand--alone mode. Each PCM (E1/T1)configuration data and carrier state change request is received via the SAPIinterface. The detailed interface specifications will be captured in the CD(Component Description)

CARML

LSACarrier Maintenance reuses the base carrier maintenance framework in theCEM module and the IEM module located in the LSA--RC module

HAL

Carrier Maintenance interfaces with the Hardware through the Carrier DeviceAgent to:

• register fault notifications

• notify state changes

It is used to manage and to record the PCM (E1/T1) faults which are describedbelow.



The PCM fault priorities are listed below in descending order:

for the PCM E1 links:



• LFA Loss of Frame Alignment. . . . . . . . . . . . . . . . . . . . . . .


for the PCM T1 links:



• LOF Loss Of Frame alignment. . . . . . . . . . . . . . . . . . . . . . .


The PCM fault(s) (collection of contiguous faults) can result in a failure that has tobe reported to the GSM applications if they reach a threshold. This threshold iscalled the FBT (Fault Begin Time). On a fault notification the number of faultyseconds based on the same fault type needs to be reported. A second can be faultyfor one fault only. If two faults occur in one second, the fault priority will be usedto determine which one to peg.

The quantity of faults reported in a message is equal to the FBT.

The provisional threshold that will determine the termination of a failure is namedFET (Fault EndTime). If there is no defect detected over a period of FET, then thereneeds to be a failure cleared notification sent to the GSM applications.

Test actor


An contained actor is a subclass and is also a container for the device diagnosticinterface container. All the contained actors are optional and are created during theinitialization steps.

The test actor for the LSA--RC module contains the following actors:



S--link test actor



PE/DCL/DD/0126411--9001--126


ITM test actor


CARM test actor

This actor is used as an interface with HAL PCM through the diagnostic layer toinvoke the tests on the PCM links when the services are running or are out oforder. This component is a part of the Spectrum maintenance framework

HDLC test actor

This actor is used as an interfacewithHALHDLCthrough thediagnostic layer toinvoke the tests on the HDLC level when the services are running or are out oforder. This component is a part of the Spectrum maintenance framework

Fault actor


An contained actor is a subclass and is also a container for the device test interfacecontainer. All the contained actors are optional and are created during theinitialization steps.


ITM fault actor




S--link fault actor

This actor is used as an interface with the S--link HAL to receive and process anyfaults that may be reported by the S--link HAL. This component is a part of theSpectrum maintenance framework

CARM fault actor

This actor is used as an interfacewith theCARMHAL to receive and process anyfaults that may be reported by the PCMHAL. This actor needs to be created andthe following object model shows the datamembers andmethods that need to beoverwritten



TRM_OAM_Specific

The TRM_OAM_Specific functional group is closely linked to the Spectrumhardware concept.

It is used to manage the specific part of the configuration messaging which aretransmitted to the TRM module.

Test actor


An contained actor is a subclass and is also a container for the device diagnosticinterface container. All the contained actors are optional and are created during theinitialization steps.

The test actor for the TRM module contains the following actors:



S--link test actor


ITM test actor


DSP test actor

This actor is used as an interface withDSP through the diagnostic layer to invokethe tests on the messaging when the services are running or are out of order. Thiscomponent is a part of the Spectrum maintenance framework


PE/DCL/DD/0126411--9001--126


Fault actor


An contained actor is a subclass and is also a container for the device test interfacecontainer. All the contained actors are optional and are created during theinitialization steps.


ITM fault actor

This actor is used as an interface with the ITM HAL to receive and process anyfaults that may be reported by the ITMHAL. This component is a part of theRMMaintenance Framework


This actor is used as an interface with the PROCHAL to receive and process anyfaults that may be reported by the PROC HAL.This component is a part of theRM Maintenance Framework

S--link fault actor

This actor is used as an interface with the S--link HAL to receive and process anyfaults that may be reported by the S--link HAL.This component is part of theRMMaintenance Framework

DSP fault actor

This actor is used as an interface with the vocoding to receive and process anyfaults that may be reported by the DSP. This actor needs to be created and thefollowing object model shows the data members and methods that need to beoverwritten



4.3.1.5 Overview and conclusion

Figure 4--10 shows how the OAM is distributed inside a BSC e3 and a TCU e3.

Each part of the OAM architecture has been described previously. We summarizein the following paragraphs the main function of the OAM architecture.

OAM is not only an OMC--R agent for the BSC e3. It decides and involves eachaction after orders or observations. The following spontaneous behavior can be run:

overload protection

the SWitch of the ACTivity after a hardware or a software failure in an activemodule

defense against applicative inconsistencies

etc.

At any level the OAM entity manages the following operations:

ensures coordination between each subtending entity

reports upper layer orders to lower layer orders

synthesizes and informs the upper layer entity about lower events

runs a corrective action if this remains local to the resource

controls each subtending entity (supervision role)


PE/DCL/DD/0126411--9001--126


CONTROL NODE

BSC e3

OMU module

ConfigurationmanagementSBC_OAM

BTS

BTS_OAM

IN_OAM

CN_OAM

OMU_OAM

SBC_OAM

1

SBC

TMTM_OAM

BTS_OAM

SBC_OAM

3

SBC

TMTM_OAM

TMU_OAM

TMU module

3

Mod_OAMATM--SW

INTERFACE NODE

CEM_OAMCEM module

IN_OAM

1

RM_OAMATM--RM

RM_OAMLSA--RM

RM_OAM8K--RM

TCU e3

TRANSCODER NODE

CEM_OAMCEM module

TN_OAM

2

RM_OAMTRM

RM_OAMLSA--RC

PCUSN

PCUSN_OAM

4

4

2

PCU_OAM

TN_OAM

SS7group

Figure 4--10 BSC e3, TCU e3 and PCUSN: OA&M hierarchical architecture



4.3.2 CallP architecture

Figure 4--11 shows theCallP (Call Processing) architecture for the BSCe3 and theTCU e3.

Figure 4--12 shows the CallP (Call Processing) architecture for the BSC e3 andthe PCUSN.

The CallP uses the TMG (Traffic ManaGement) installed inside BSC 2G and theTCU 2G with upgrade and adaptation for the BSC e3 and the TCU e3.

The CallP corresponds to each job, which is related to the management of the GSMcommunications.

It manages the main following main functions:

the traffic which corresponds to:

• the management of connections between an MS and the MSC

• the transfer of user information between an MS and the MSC[DTAP]

• the management of functions related to a whole cell (e.g. paging) or to thewhole BSC (for example: reset.)

• the AMR management (AMR vocoding; link, channel and frame [TRAU]adaptation)

network resources allocation, which corresponds to:

• the allocation of terrestrial circuits

• the allocation of radio resources

• the allocation and themanagement of AMRchannels (full rate, and especiallyhalf rate channels)

handover

radio measurements

power control

The active and the passive applications share the time switch. Each connectionrequest sent by the active application is directly seen by the passive application.

4.3.2.1 Control Node overview

The Control Node is mainly used to:

set up a call connection

delete a call connection

modify a call connection


PE/DCL/DD/0126411--9001--126


TCU 2G

CONTROLNODE

ATM_SW

INTERFACENODE

ATM--RM

CEM NODE_ACCESS CallP_IN Pool PCM CallP_SW64K

8K--RM CallP_SW8/16K

LSA--RC (Up to 6)

LSA--RC (Up to 4)

CEM NODE_ACCESS CallP_CONF Pool PCM CallP_SW64KCallP_CNX

TRM (Up to 9+1) DSP CallP_TMA

Pool 8K

LAPD_ACCESS

TCU 2G groupTMG_COM

TMG_S7A

ACCESSon

PMC board

LAPDon

PMC board

IN_ACCESS

OBS_OBC

OBS_COM

OBR_CNX

SPT

TMG_DBA

TMU (Up to 12)TCU e3 group

TMG_COM

OBS_COM SUP_TCU

MTP1/MTP2on PMC board

TMU (SBC for SS7)

TMG_S7A

TMG_DBA

OBS_OBCMTP1/MTP2on PMC board

TMG_RST

SCCPMTP3

on SBC board

SS7 group

SS7_ACCESS

OMUOBR group

OBR_FORMAT OBR_TRA ADMDTM STC

Cell group

TMG_MES

TMG_CNX

TMG_RAD

OBS_CNX

OBS_RAD

TMG_L1M

SPR

TCU e3

(Refer toNTP < 16 >)

Figure 4--11 BSC e3 and TCU e3: Call processing architecture



CONTROLNODE

ATM_SW

INTERFACENODE

ATM--RM

CEM NODE_ACCESS CallP_IN Pool PCM CallP_SW64K

8K--RM CallP_SW8/16K

LSA--RC (Up to 6)

PCUSN

Pool 8K

TCU 2G groupTMG_COM

TMG_S7A

OBS_OBC

OBS_COM

OBR_CNX

SPT

TMG_DBA

TCU e3 group

TMG_COM

OBS_COM SUP_TCU


TMU(SBCforSS7)

TMG_S7A

TMG_DBA

OBS_OBC MTP1/MTP2on PMC board

TMG_RST

SCCPMTP3

on SBC board

SS7 group

SS7_ACCESS

OMUOBR group

OBR_FORMAT OBR_TRA

ACCESSon

PMC board

LAPDon

PMC board

IN_ACCESS

TMU (Up to 12)

Cell group

TMG_MES

TMG_CNX

SPR

TMG_RAD

OBS_CNX

OBS_RAD

TMG_L1MTMG_RPP

ADM

SPP group

SPP

DTM STC

Figure 4--12 BSC e3 with PCUSN: Call processing architecture


PE/DCL/DD/0126411--9001--126


4.3.2.2 Interface Node overview

The Interface Node does the following:

provides network connectivity for the Abis and Ater interfaces

routes the Control Node connectivity for LAPD and SS7 signalling links

performs the following switching functions:

• 16 kbps for bearer voice/data between BTS and BSC e3 (Abis interface)

• 64 kbps for signaling links between the BSC e3 and the TCU e3 (Aterinterface)

4.3.2.3 Transcoder Node overview

The Transcoder Node performs the following:

managing the vocoding path between the MSC and the BSC

managing the bearer channels

managing the different types of vocoding algorithms

providing the network connectivity between the RMs and:

• the A interface

• the Ater interface

terminating the Ater interface

routing SS7 signaling links and the Control Node connectivity for SS7 signalinglinks

switching functions:

• 64 kbps for signaling links between the TCU e3 and the BSC e3 aftertranscoding (Ater interface)

• 64 kbps for signaling links between the TCU e3 and the MSC (A interface)



4.3.2.4 Control Node description

TMG overview

Figure 4--13 shows the TMG functional organization inside a BSC e3 with TCUe3.

Figure 4--14 shows the TMG functional organization inside a BSC e3 withPCUSN.

The TCU e3 group and the Cell group notions are introduced with the TMG. TheTCU 2G or TCU e3 group manages a group of PCM channels on the A interfaceand supervises the PCM channels on the A interface allocated by the TCU e3.

The Cell group manages the cells, which are associated with a collection of sites.

The creation of a collection of sites depends of the operator requests and theBSC e3system limits (maximal Erlang quantity will be processed by a cell group).

ATTENTION

The order to begin the communication between the Control Nodeand the PCUSN and the Interface Node are sent by theTMG_RPP.

Note: On a platform, each group is used as a core process by the fault tolerancefunction. The software architecture inside the BSC e3 is fault tolerant on ahardware or software breakdown inside the OMU module or the TMUmodule (each instance contains an active image and a passive image.Whenthe active image is broken down, the passive image is automatically run).

Themain part of the TMG is located in each TMUmodule. It establishes, modifies,and releases logical links between theMS (Mobile Subscribers) and theMSC. Eachlogical link supports:

a Radio Resource connection

an SS7 connection on the BSC--MSC interface

The TMG controls the physical connections between the BTS and theMSC via theTCU e3. The BSC e3 processing units used by the TMG contain a processor thatenables communication with the MSC, the TCU e3, and another processor thatenables communication with one or more BTS(s).

To enable these functions, the TMG uses the services provided by a radio resourceand some terrestrial circuit management units. When logical links are established,mobile subscribers can exchange “transparent” messages (DTAP messages) withthe MSC.


PE/DCL/DD/0126411--9001--126


CONTROLNODE

INTERFACENODE ATM--RM

CEM NODE_ACCESS

Note: For the description of the SS7 and the LAPD protocols inside the BSC e3 and the TCU e3refer to Figure 3--2 “Protocol architecture”.

(*)

TCU 2G

ATM_SW

OBR groupOMU

SPR

OBS_CNXOBS_RAD

TMG_DBA

OBS_OBC


(2 HDLC ports for SS7)

SUP_TCUTMU (SBC for SS7)

RSL

Link

OBS_OBC

MTP3_Routing

TMG_DBA

TMG_S7A

TMG_MES

OBS_COM

TMG_L1M

TMG_RAD

SPT

TMG_COM

TMG_COM

TMG_S7A

OBR_CNX

ADMOBR_FORMAT OBR_TRA STCDTM

--

TMG_RST

A_A

ccessSCCP

MTP3

SS7 group

SS7_ADM_C

A

TMU (Up to 12)

MTP1/MTP2 on PMC board(2 HDLC ports for SS7)

group

TCU e3 group

ACCESSon

PMCboard

LAPDon

PMCboard

Cell group

OBS_COM

TCU 2G

TMG_CNX

TCU e3LSA--RC

CEM NODE_ACCESS

(*)


21 21

21

2

1

2

(62HDLC

portsforSS7)

Figure 4--13 BSC e3 (Control Node): TMG functional organization with a TCU e3



CONTROLNODE


CEM NODE_ACCESS

Note: For the description of the LAPD protocols inside the BSC e3 and the PCUSNrefer to Figure 3--4 “Protocol architecture”.

(*)

PCUSN

PCUSN_ACCESS

ATM_SW

OBR groupOMU

SPR

OBS_CNXOBS_RAD

TMG_DBA

OBS_OBC

TMG--RPP

SUP_TCU

SPP

TMU (SBC for SS7)

2

RSL

Link

OBS_OBC

MTP3_Routing

1

1

2

TMG_DBA

TMG_S7A

TMG_MES

OBS_COM

TMG_L1M

TMG_RAD

SPT

TMG_COM

1

TMG_COM

TMG_S7A

OBR_CNX

ADMOBR_FORMAT OBR_TRA STCDTM

--

TMG_RST

A_A

ccessSCCP

MTP3

SS7 group

SS7_ADM_C

A

TMU (Up to 12)

MTP1/MTP2 on PMC board


group

2

TCU e3 group

ACCESSon

PMCboard

LAPDon

PMCboard

SPP group

Cell group

OBS_COM

TCU 2G

TMG_CNX

(*)

1

2

2

3

3

(62HDLC

portsforSS7)



Figure 4--14 BSC e3 (Control Node): TMG functional organization with a PCUSN


PE/DCL/DD/0126411--9001--126


ATCH channel allocation request queuing process is included in the radio resourceallocator. If no TCH is available, the request is put into a queue according to itspriority.When a radio resource becomes available, it will be assigned to the requestof the highest priority according to the BTS object parameter tables. Theseparameters are described into the Operating Manual User Guide. They allow usersto set internal versus external priorities, the number of TCHchannels, themaximumwaiting time for the requests, the maximum request number, and the priority levelaccording to the request cause.

Two lists of 32 frequencies will be defined at the OMC--R for each cell. The BSCe3 considers the first BCCH broadcast list (Frequencies of neighboring cells forreselection) as the data of the SYS INFO 2 and 2bis, and the second SACCHbroadcast list (Frequencies of neighboring cells for handover) as the data of theSYSINFO 5 and 5bis.

Note: The TMG has some dedicated mechanisms for managing the AMRchannel, especially:

• the allocation of aHR (half rate) or a FR(full rate) radio TSat the callsetup

• the allocation of a HR or a FR radio TS for an handover• handover for (to) FR radio TS to (from) HR radio TS in order toincrease the capacity or the voice quality

TMG description

The TMG does the following:

handles Radio Resource connection

handles BSC e3 transactions

handles MSC (and TCU e3) connections

allocates resources

manages global procedures (connectionless service)

transfers transparent messages

The TMG must be divided to cover varying traffic load handling needs. Thefollowing operations can increase traffic handling potential:

duplicating the TMG that enable communication between mobile subscribers(MS) and the BTSs

providing physical processors to back up other traffic



Note: In the BSC e3 architecture, due to the redundancy, in order to simplify thedefense during the SWACT of a cell, the communication of bothTMG_CNX and TMG_RAD will migrate during the inter--CG (inter--cellgroup) handover. This architecture establishes for AMRcalls theHandoverbetween each zone.

TMG_RST

The TMG_RST performs the main following functions:

manages the GSM reset downlink procedures

manages the GSM reset uplink procedures

updates the status of the MSC traffic

The reset downlink procedure is triggered when the TMG_RST receives amessage.

The reset uplink procedure is triggered when

The status of the MSC traffic, memorized by each TMG_RST, is:

CLOSED

• at start--up

• between a reset message and the following reset acknowledge message

OPEN

• between a reset acknowledge and the following reset message

The active TMG_RST is memorized inside the operating system as the master andthe passive TMG_RST as the slave.

TMG_MES

The TMG_MES does the following:interfaces with the SS7 functional unit (MSC connection handling) and SS7connection managementdistributes BSSMAP message to the appropriate TMG_CNXmanages transparent and non--transparent messages between mobile subscribers(MS) and the MSC (message queuing during radio channel handover, etc.)

TMG_COM

The TMG_COM does the following:allocates terrestrial circuits (resources)performs terrestrial circuit soft blockingmanages the connectionlessBSSMAPprocedures related to the terrestrial circuitin both directions (blocking and reset circuit)


PE/DCL/DD/0126411--9001--126


TMG_CNX

The TMG_CNX enables the main TMG functions. It manages all the MS--MSClogical link--dependent procedures and synchronizes the procedures handled by theother TMG functions to establish, update and release links, especially when a radiochannel change occurs (from SDCH to TCH, handover, mode modify). MS--MSClogical link contexts and some observation counters (handovermonitoring) are alsoinstalled in the TMG_CNX.

It interfaces with the following:TMG_MES for SS7 connection management needsTMG_COM to obtain a terrestrial circuitTMG_RAD to execute radio resource procedures

DTM (Download Token Manager)

The main principles of the DTM is to manage the maximum of BTS downloadingper BSC e3, per TMU module and per cell group.

STCH (STate CHange)

The main principles of the STCH are:

send toOMC--R at regular time intervals a global grouped notification indicatingall state changes of BTS objects since the last OMC--R update

secure end--to--end the message sending with an acknowledgement mechanism.The notification message sending is then under BSC e3 applicative control

eliminate all transitory state changes between two OMC--R updates

send state change notifications at the same speed as the OMC--R is processingthem

send grouped state change notifications to the MMI of the local manager



TMG_RPP

The TMG_RPP on each cell group enables the functions needed for:

SGSN--mobile subscriber communication

GPRS resources management

cell management

It contains each information item concerning the GPRS channel configuration, cellby cell, and the counters associated with transaction monitoring, and the GPRSchannels supervision: TCH/F.

The TMG_RPP does the following:

to open the GPRS services on the radio interface (between the MS and the BTS)

to close the GPRS services on the radio interface (between theMS and the BTS)

to allocate the dedicated TCH/F radio resources to the PCUSN

to remove the dedicated TCH/F radio resources to the PCUSN

to establish the connection between the Abis interface and Agprs interface

to give the radio parameters to the PCUSN

In addition the TMG_RPP is used to:

hide as far as possible the GPRS capability of the BSC e3 to the MS until theservice is not available. It means MS will be informed of the GPRS service

perform connection only when service is available in the cell

attribute a pool of Agprs circuits from the SPP. TMG is in charge to connecttheses circuitswith radio resources and to inform the PCUSNof the relationshipsbetween a radio resource and an Agprs circuit.


PE/DCL/DD/0126411--9001--126


TMG_RAD

The TMG_RAD on each cell group enables the functions needed for BTS--mobilesubscriber communication, radio resource, and cell management.

It contains all the information concerning the radio channel configuration, cell bycell, and the counters associated with radio observations, transaction monitoring,and SDCCH and TCH/F channel supervision.

It does the following:

allocates SDCCH and TCH/F radio channels (resources)

supervises the BTS--mobile subscriber communication protocol (RRconnection)

manages paging procedures

manages counters on behalf of the OBR functional unit

manages the Short Message Service

detects and resolves overload

periodically supervises TCH and SDCCH channels

TMG_DBA

The TMG_DBA centralizes the global data on PCMA (crossing table CIC/TCU 2Gor TCU e3 group), cells managed by the BSC e3 (crossing table cell/cell group) andglobal SCCP data (OPC, DPC).

TMG_S7A

TMG_S7A is the interface in the BSC e3 that allows messages to be routed fromthe SS7_ADM_CA to the right TMG in connectionless mode.

It is localized on each TMU module (one instance per TMU module). TheTMG_S7A contains no permanent data but it can access to the permanent datainside the TMG_DBA.

TMG_L1M

The TMG_L1M performs routing of the messages from the TMG part to the L1Mpart of the BTS.



OBR overview

TheBSCe3 radio observation functional unit (OBR) is in theOMUprocessing unit.It constructs a BSC e3 database containing radio measurements and call tracing toset algorithm parameters and check their accuracy.

The call tracing results collected through a new interface with the MSC that iscompliant with GSM Phase 2 08.08 Rec. include data such as handover attempts,radio resource unavailable, handover parameters, handover activity, supplementaryservices activity, short message service. Depending on the priority level for thesession, the data either is sent directly in event reports to theMSC (highest priority)or by way of files stored into the BSC e3 disk. This process is activated by theMSC.

OBR description

The OBR performs the following:

interfaces with the CM--CA functional unit used to activate and deactivateobservation session

interfaces with the TMG to start or stop radio channel observation

creates a file on the hard disk that contains the measurements and events for thedetection of handovers performed by the BTS L1M functional unit. Theinformation items are stamped in the chronological order of reception.

OBS

The purpose of the observation software is to gather information about the BSS andto send it to the OMC. The management of all observation requests for collectionand transfer of the observation results is issued from PM_CA

For more information about the PM_CA function refer to paragraph 4.3.1.2.

SPR

The SPR manages the Radio Resource connection. The main functions of the SPRinside the CallP architecture are described by the SPR function inside the OAMarchitecture.

For more information about the SPR function refer to paragraph 4.3.1.2.


PE/DCL/DD/0126411--9001--126


SPP

TheSPPmanages the PCUSNconnection. Themain functions of the SPP inside theCallP architecture are described by the SUP_PCUSN function inside the OAMarchitecture.

For more information about the SUP_PCUSN function refer to theParagraph 4.3.1.2.

SS7 overview

The entire SS7 protocol, which is mainly dedicated to the TCU e3 is located in twotypes of TMU module (one active + one passive).

Only one SS7 instance manages communications with the active TMG. It does thefollowing:

supports the following SS7 layered protocols:

• SCCP (Signaling Connection Control Part)

• MTP (Message Transfer Part)

sets up the initial SS7 configuration

distributes the signaling load over the links of the combined link set that connectsthe BSC e3 and MSC

distributes TMG functional unit messages

SS7 description

SSCP

The SCCP is used to:

provide a referencing mechanism to identify a particular transaction relating toan instance of a particular call

enhance the message routing for (for instance) operations and maintenanceinformation

provide both connectionless as well as connection--oriented network services.Only 2 SCCP protocol classes are provided:

• Class 0: basic connectionless class

• Class 2: basic connection--oriented class



No segmentation/reassembly are provided. SCCP performs the followingfunctions:

provides a SCCP Discrimination function by discarding any messages withwrong format or not intended for a registered SCCP User. Any time a message isdiscarded, an “SCCPWarning Indication”message is sent directly toAACCESS

maintains a number of connections established at the request of SCCP Users.SCCP manages active and stand--by connections at the same time

receives and transmitting on of User Data in a connectionless mode

routes again the incoming calls from one user instance to another one

performs SCMG functionality: controls of the availability of all configuredremote Subsystems by performing a periodic SubsystemStatus Test (SST) on allprohibited Subsystems responding to the SST from all remote subsystems

SCCP can be divided in the following parts:

SCCP Routing Control (common to all SCCP instances)

SCCP Connection Control: connection oriented services.This is the only part to be fault tolerant

SCCP Connectionless Control (common to all SCCP instances)

SCCP State Control: SCCP Management (SCMG)

MTP

MTP provides a mechanism giving reliable transfer of signaling messages.

MTP3, MTP2 and MTP1 correspond to the normalized SS7 layers.

The MTP3 is centralized on the dedicated TMU board (TMU--SBC).

TheMTP1 andMTP2 are shared on theTMU--PMCand handle up to two SS7 links.


PE/DCL/DD/0126411--9001--126


LAPD

The entire LAPD protocol management unit is located inside the TMUmodules ofthe BSC e3.


handles theLAPDprotocol (initializationmessage transfer, error detection, faultrecovery)

distributes incoming messages to user entities

enables the BTSs and TCU e3 link access procedures for BSC e3 applicationmessage sending needs

handles the LAPD configuration, which depends on the ADM and SUPfunctional services

Generic_Access

The Generic_Access is made up of three types of access interfaces:

IN_Access

Ater_Access

LAPD_Access

IN_ACCESS

The management of the LAPD links between the BSC e3 and the TCU 2G is doneby the IN_Access application. IN--Access allows SPT to have the same behavior inthe environment 2G or e3. The IN--Access is located on the OMU module and is aFT application.

The accesses to the TCU regarding the O&M dialogs are made up:

only one link LAPD on the single PCM Ater in the TCU 2G case

several LAPD links share the PCM Ater in the TCU e3 case.

the Ater LAPD links in BSC 2G are concentrated on the same LAPD port of aSICD board

inside the BSC e3, each LAPD link with a TCU 2G is connected to a differentLAPD port of a TMU module chosen by the IN--Access.

This difference induces different behaviors regarding the building of these links, thedefense and the dialogs management.

Ater_ACCESS

The Ater_Access is the access functionality to adopt for the SUP_TCU which isresponsible for the TCU e3 supervision. The SUP_TCU requests the access to openthe LAPD links towards the TCU e3 and to build the LAPD dialogs between theBSC e3 and the TCU e3.



LAPD links:

The build or delete LAPD links towards the TCU e3 is requested by theSUP_TCU via the Ater_Access, while building LAPD link SUP_TCU Accessgives information about the Ater_PCM. Then, the access chooses an unallocatedLAPD port on the TMU module.

All the links opened by the SUP_TCU are configured for three types ofcommunications OAM, RSL and FT

LAPD dialogs:

Once the SUP_TCU got the LAPD link establishment from access, it asks toconfigure theLAPDdialogs on this link. On the same LAPD link, the SUP_TCUcan ask to configure OAM, RSL and FT.

TheOAMdialog is used by the SUP_TCU to communicatewith theTCU e3 andthe A_Access. The RSL dialog is used by traffic management applicationTMG_COM for call processing. The FT dialog is used while upgrading TCUe3.

The Ater_Access is also responsible for the routing of CallP messages fromTMG_COM. The LAPD link on which the CallP message has to be routed isdecided by the Ater_Access.

TheAter_Access distributes theCallPmessages receivedon theopenedRSLLAPDdialogs, so that it reaches the TCU e3 which is specified in the message.

LAPD_ACCESS

The entire LAPD_ACCESS protocol management unit is located inside the TMUmodules of the BSC e3.


it enables the routing procedure as follows:

• sends the LAPD message to the correct LAPD_DL functional unit on theTRX--site base on behalf of SUP or on theTDMA--cell base onbehalf ofTMG

• sends a message to the L1M functional unit concerned on the cell--TDMAbase

it interfaces with CM_CA inside the ”OA&M services group” and the”Supervision group”. This interface allows obtaining the LAPD configurationfixed by:

• the permanent data managed by CM_CA

• dynamic data managed by the “Supervision group”

it handles the LAPD configuration

it recovers observation data counters distributed on each LAPD


PE/DCL/DD/0126411--9001--126


4.3.2.5 Interface Node

Figure 4--15 shows the CallP organization inside the Interface Node.

NODE_ACCESS

The NODE_ACCESS is used to manage the communication between the ControlNode and the Interface Node. Then, it dispatches the messages on the channelslocated inside the Interface Node.

CallP_IN

The CallP_IN is located in the CEM module and supervised by the Control Node.

The CallP_IN houses the “switch manager” function which allows to perform thetime switch connections with the bearer channels or the signaling channels.

When Callp sends a request to connect an Abis or an Ater circuit, the SwitchManager does the following actions:

if the connection is not yet established:

• it switches aTS of theAbis interface (E1/T1) to aTS of an S--linkvia theCEMmodule

• it switches aTS of theAter interface (E1/T1) to aTS of an S--link via theCEMmodule

at last, it establishes the circuit connection via the 8K--RMmodule between bothTS S--link which are coming respectively from a TS of the Abis interface and aTS of the Ater interface

In the case of handover, the Control Node sends a request to:

modify the connections

In this case, the switchmanager establishes the new links (this is done throughYconnections in the 8K--RM module to preserve the voice quality) and thenreleases the old ones.

release a connection

In this case, the switch manager only releases the time switch inside the 8K--RMmodule, the connection with the CEMmodule may be used by the other circuitsor could be used later

In addition, the commands, that are coming from theCallP_IN, are sent to the activeand passive CallP_SW8K. Therefore:

as said previously, it duplicates every switching and provisioning command toboth CallP_SW8Ks

at CallP_SW8K recovery time, it re--synchronizes them autonomously

all the data it uses for its own business, on the CEMmodule, must be duplicatedon the mate CEM module



ATM_SW

CONTROL NODE

TMU(Up to 12+2) TMG

Cell group

TMG_CNX

TCU e3 groupTMG_COM


8K--RM

CEM

CallP_SW8K

Pool 8K

Pool PCMCallP_IN

CallP_SW64K

NODE_ACCESS

LSA--RC (Up to 6)

TCU e3

CEM NODE_ACCESS

Pool PCMCallP_CNX

CallP_SW64K

TRM(Up to 14)

CallP_CONF

DSP CallP_TMA

LSA--RC(Up to 4)LAPD_ACCESS

To/from MSC To/from BTS

Switch64K

Switch8K

Switch64K

SUP_TCUTCU 2G group

TMG_COMSPT

Speech/data channel

TCU 2G


IN_ACCESS Ater_ACCESS

LAPD_ACCESSGeneric Access

Figure 4--15 BSC e3 and TCU e3: CallP organization


PE/DCL/DD/0126411--9001--126


CallP_SW64K

The CallP_SW64K manages each operation done by the CallP_64K located insidethe CEM module.

The CallP_SW64K uses the connection manager function to perform the 64Kconnections between:

the TS S--link of the LSA which carries the PCM (E1/T1) links on the Aterinterface or the PCM (E1/T1) links on the Abis interface

and the TS S--link of the 8K--RM module which performs 8K/16K switch

These operations requested by the CallP_SW8K manage the active and the passiveCEM modules and insures a complete synchronization between them.

The passive CEM module does not manage the links with the 8K--RM module, itonly processes the communication.

Pool PCM

ThePool PCMis used for TS allocating on the Ater interface and the Abis interface.For a given TS on a PCM (E1/T1) link, it provides a DS0 on the S--link to interfacethe active CEM module with an LSA--RC module.

The Pool PCMuses the PCM(E1/T1)mapping sub system. TheCallP_SW64Kwillreceive a “pathend” from the Pool_PCM.

CallP_SW8K

The CallP_SW8K provides a non--blocking sub--DS0 rate time switching functionon 8 kbps channels, i.e., both bit position and timeslot number are switched betweenthe incoming DS0 and outgoing DS0.

The CallP_SW8K does not do any maintenance actions on the 8K--RM module.This is the responsibility of the I--Node_OAM group.

Pool_SW8K

The Pool_SW8K is used to provide a free DS0 on the S--link which interfaces theactive CEM module with the active 8K--RMmodule. Through a specific function,Pool_SW8K provides the “pathend” and the corresponding DS0 identifier for the8K_proxy.

The provider of the Pool_SW8K informs it when no more DS0s are available onthe S--link interfaces. In this case, the garbage collector:

checks all unused connections

unblocks all unused connections

reallocates all unused connections



4.3.2.6 Transcoder Node description

Figure 4--15 shows the CallP organization inside the Transcoder Node.

NODE_ACCESS

The NODE_ACCESS is used to manage the communication between the ControlNode and the Transcoder Node. Then, it dispatches the messages on the channelslocated inside the Transcoder Node.

CallP_TN

This is a call processing function, which is in charge of switching and connectingthe following via the CallP_SW64K function:

the PCM (E1/T1) links on the A interface

the appropriate transcoding resource

the PCM (E1/T1) links on the the Ater interface

This function supports the management of each resource needed by the CallPresource to establish a connection between the BSCe3 and theMSC. It manages thepool of transcoding resources.

In addition, the Resource--Allocation has to manage the pool of Ater interfacecircuits according to the requested Channel coding.

Some treatments, such as observations, are not associated with a specific call. Sothis entity is in charge of collecting the counters and transmitting them to theBSC e3 by request.

This entity is in charge of tracing information associated with the calls or with thepools for maintenance purposes.


PE/DCL/DD/0126411--9001--126


CallP_SW64K

The CallP_SW64K function controls each operation performed inside the CEMmodule. This function is divided into the following main parts:

switching matrix 64K management

internal PCM (E1/T1) link monitoring

The CallP_SW64K uses the connection manager function to perform the 64 Kconnections between the TS of the S--link of the LSA and the TRM module whichcarries the PCM (E1/T1) links. The PCM (E1/T1) links come from:

the BSC e3 on the Ater interface

the MSC on the A interface

Pool_PCM

The Pool_PCM function is used to allocate the TS to the:

BSC e3 via the Ater interface

MSC via the A interface

For a TS on a given PCM (E1/T1), it provides a DS0 on the S--link which interfacesthe active CEM module with an LSA--RC module.

The Pool_PCM function manages the PCMA (E1/T1) links on the A interface side,and the PCM (E1/T1) links on the Ater interface side. The PCM (E1/T1) linkconnecting the TCU e3 and the MSC is considered as an object of the BSS, and isdesignated PCMA.Using the configuration and operation data providedby theBSCe3, the PCM (E1/T1) link management configures and monitors the PCM linktransmission supports for all the associated external and internal PCM links.

The PCMA management function generates PCMA operational status indicationsfor changes that are transmitted to the BSC e3. The external PCM (E1/T1) links areoperational as soon as the TCU e3 starts up.



CallP_CONF

It is used to configure and to supervise for a given vocoder an array ofcommunications named: archipelago.

The parameters of the vocoder are given by the system:

speech coding law A or law µ

law VAD

PCM type: E1/T1

etc.

DSP

The DSP function is used to:

process each speech/data channel

adapt the full rate (FR), enhanced full rate (EFR) and adaptivemulti--rate (AMR)FR or HR speech coding/decoding

In this case, switching from one vocoding type to another is controlled byinformation contained in the frames received on the BSC e3 interface.

handle calls in parallel

roam between the networks of different operators

transmit the speech and text alternately (VCO/HCO)

The DSP function is located between the 120 channels (16 kbit/s or 8 kbit/s) of theBSCe3 and 120 channels (64 kbit/s) of theMSC. Speech communication representsfull rate communication (containing 3 kbit/s signaling and 13 kbit/s coded speech)or half rate communication in the case ofAMR. Should loss of speech frames occur,substitution procedures are applied. Data channels carry FRdata with 9.6 kbit/s, 4.8kbit/s, or 2.4 kbit/s. Should loss of data frames occur, filling frames are generatedform the MSC or the BSC e3.

Note: When the AMR is used, channel rates are the following:10.2 kbit/s, 6.7 kbit/s, 5.9 kbit/s, or 4.75 kbit/s for FR rateand 6.7 kbit/s, 5.9 kbit/s, or 4.75 kbit/s for HR rate

Error messages are generated to the BSC e3 should loss of synchronization occuror should the transcoder be unable to process the transmitted frames.

The DSP are configured by the CEM module or self--synchronized by the trafficchannels.


PE/DCL/DD/0126411--9001--126


CallP_TMA

The CallP_TMA (TMA: TRMMaster Application) group allows to interface withthe DSP:

the CallP_CONF group

the “Fault actor” which is described inside the OAM architecture

4.4 GSM BSC/TCU e3 Synchronization requirements

4.4.1 Overview

Given the distributed nature of the e3 GSM nodes, and the potential for interveningnetwork nodes (DACS, MUXES, etc.), a set of requirements has been defined toattempt to ensure the best possible network performance for the system under allconditions. Strict adherence to these requirements is mandated to acheive therequisite network synchronization performance.

TheMSC itself must be timed from a PRS/PRC (Stratum 1 clock, either CesiumOscillator or GPS Receiver) driving a TSG/SSU (i.e. the BITS clock). Thisrequires an absolute frequency accuracy of 1e10--11 to ensure proper traceabilitydownward through the TCU and BSC--IN to the BSC--CN.

The stability of the clock leaving the MSC via its copper interfaces (which areintended for use by the TCU as timing carriers) are determined by its wanderperformance, jitter performance, and transient performance. In order toaccomodate the needs of the BSC--IN/BSC--CN SONET interworking,thesestabilitymetricsmust be consistentwith the requirementsof SONETnodes.Assuming these stability criteria are met, and no equipment in the timing pathis in a failed mode of operation 1 frequency accuracy and traceability to aStratum1 clockwill be ensured. The following represent aminimal subset of theSONET stability requirements.

4.4.2 Standards compliancy and detailed requirements

The BSC/TCUe3 clock synchronization requirements are compliant with therecommendations in Telecordia GR--253, GR--1244 and ITU--T G.812/G.813.

Wander performance at the MSC copper timing outputs to the TCU must meetrequirements R5--4 through R5--6 as defined in Telcordia GR--1244 (Issue 2,December 2000) and R5--119 as defined in Telcordia GR--253 (Issue 3,September 2000). See Figure 4--16,Wander: MTIE Specifications and Figure4--17,Wander: TDEV Specifications.

Jitter performance at the MSC copper timing outputs to the TCU must meetrequirement R5--7 as defined in Telcordia GR--1244 (Issue 2, December 2000.)



Note: 1 Normal operation is considered to be “locked” or “sync’ed” to a stratum1clock. Failed modes of operation are “internal” timing where the clock isself--timed rather than tracking a stratum clock. These failed modes ofoperation are known as “free--running” and “holdover”.

• See Figure 4--18 -- Jitter: Maximum Interface Jitter Specifications

• Transient performance at the MSC copper timing outputs to the TCU mustmeet R5--9 through R5--14 as defined in Telcordia GR--1244 (Issue 2December 2000). See Figure 4--19, Phase Transient Specifications .

The stability of the clock leaving the TCU via its copper interfaces (which areintended for use by the BSC--IN as timing carriers) are determined by itswander performance, jitter performance, and transient performance, as well asthe quality (i.e. stability) of the clock received from the MSC (or interveningnode). The output performance requirements are the same as those identified insecond large bullet above.


PE/DCL/DD/0126411--9001--126


The stability of the clock between the BSC--IN and the BSC--CNover the opticalconnection (ATM over SONET) is determined by the BSC--IN wanderperformance, jitter performance, and transient performance, as well as thequality (i.e. stability) of the clock received from theTCU (or interveningnode).The output performance requirements are the same as those identified in secondlarge bullet above.

Copper interfaces carried as payload across optical (SONET/SDH) transportfacilities are unsuitable for use for TCU or BSC--IN timing because of theexcessive wander and jitter introduced as a result of pointer justifications at theoptical transport layer. GR--1244 and GR--253 both strongly caution against theuse of any such copper interfaces for network synchronization purposes.

Figure 4--16 Wander: MTIE Specifications



Figure 4--17 Wander: TDEV Specifications

Figure 4--18 Jitter: Maximum Interface Jitter Specifications


PE/DCL/DD/0126411--9001--126


Figure 4--19 Phase Transient Specifications




Control node descriptionNortel Networks Confidential 5--1


5 CONTROL NODE DESCRIPTIONFigure 5--1 shows the physical architecture of the Control Node. It uses standardVME boards as processor boards in each OMU and TMU module.

The links for the Control Node are achieved:

between each module via redundant ATM25 point--to--point connections

with the Interface Node via a redundant ATM155 on OC--3 optical multi modefibers

with the OMC--R and the TML via TCP/IP on a Ethernet connection from eachOMU module

These links allow high fault--isolation, scalability, signal integrity and backplaneredundancy.

BSC e3 FRAME

INTERFACE NODE

CONTROL NODE

ATM--RM



TMUUp to 12+2

TMU modulesTMU TMU TMU


Transmission


Reception

OMU(active/passive)

Ethernet link(100 Mb/s)


SCSI--A

Shared MMS

SCSI--B

Shared MMSPrivate MMS

(active/passive)Private MMS

(active/passive)

SCSI--PA SCSI--PB

OMU(active/passive)

ATM--RM

To/FromOMC--R/TML

ATM--SW ATM--SW

Figure 5--1 Control Node: physical architecture

Control node description Nortel Networks Confidential5--2

PE/DCL/DD/0126411--9001--126


5.1 OMU module

Each OMU module is used (see Figure 5--2):

to manage each MMS module which houses a SCSI disk

to run and control:

• each ATM--SW module

• each TMU module

to supervise the Interface Node

to supervise each Transcoder Node

to supervise the BTSs

to manage the debug access via the RS232 connector or the RJ45 connectorwhich are located on the front panel

to manage an external Ethernet access to the OMC--R or the TML via the RJ45connector which is located on the front panel

A double slot is used to install each OMU module.

An OMU module houses:

the following VME boards:

• OMU--SBC board

• OMU--PMC board

an OMU--TM assembly

Each OMU module can have access to:

one private disk for its private data

two shared disks managed in a mirroring way

They are used to save the data in the event of an OMU module failure or a diskfailure



OMU

Visualindicators

Etherneton RJ45connector

AsynchronousRS232 on9--pinconnector

Unused

Removalrequestpush--button

Figure 5--2 OMU module: hardware overview


PE/DCL/DD/0126411--9001--126


5.1.1 External interfaces

The external interfaces of each OMU module are described below:

on the double front panel:

• two visual indicators (LEDs)

• one 9--pin connector for one asynchronous RS232 debug port

• one RJ45 connector for one 10/100Mbs Ethernet OMC port

• one removal request push--button to indicate a request to remove the OMUmodule

on the backplane:

• the redundant ATM links

• the redundant -- 48 Vdc links

• one Slot ID

• the SCSI buses to connect:

– one SCSI private disk located inside the MMS module

– two SCSI shared mirrored disks located inside both MMS modules

• the MTM bus connected to each module via the backplane

• an Ethernet 10/100 Mbps to link both OMU modules via the backplane

• an interface between the SIMmodules and the OMUmodules to connect andto control the -- 48 Vdc and the alarms to each of the other modules

5.1.2 Electrical characteristics

Each OMU module:

is powered by the -- 48 Vdc which comes from the operator boxes via the PCIUframe assembly and the SIM modules

houses:

• a DC/DC converter which provides power to each component

• a ground for each board

• a fixed fuse to protect each component



5.1.3 Functional description

Figure 5--3 shows each of the main functional blocks which are housed inside anOMU module.

5.1.3.1 OMU--SBC board

The OMU--SBC board houses:

two regular VME boards with high processing capability split up as follows:

• one processor memory board

• one base I/O board

one PMC board used to manage the SCSI/P bus

Processor memory on VME board

The processor memory board houses the following main components:

a CPU

an Ethernet interface for the communication between both OMU module

an SCSI/B interface routed via the SCSI block located inside the OMU--TMassembly. It is used to manage one mirrored shared disk located inside anMMSmodule.

a synchronous interface

PMC board

The PMC board houses an SCSI/P interface routed to the SCSI transceivers, whichis located inside the OMU--TM assembly.

The PMCboard is used tomanage one private disk, which is located inside anMMSmodule.


PE/DCL/DD/0126411--9001--126


VME boards

Frontpanel

LEDs

OMU module

ResetITMblock

OMU--SBC assembly

SCSI/P interfacePMC board

SCSI/A interface

Processor memory

Ethernet interface

Asynchronousinterface

Ethernet interface

SCSI/A bus SCSI/A bus

SCSItransceivers

OMU--TM assembly

SCSI/P bus SCSI/P bus

VME64


SCSI/Bbus SCSI/B bus

Debug access block

VME32

(Base I/O) CPU

Bus32 bits

SCSI/B interface

CPU

Synchronousinterface

dc/dcconverter

Backplane

DebugbusP

CIbus

AsynchronousRS232

on9--pinconnector

Ethernet

onRJ45connector

Tosharedmirorreddisks

Toprivatedisk

ATM25(A)

ATM25(B)

--48 V dc

MTM bus

Ethernetlink toOMUmodule

Rem

ovalrequest

push--button

ATM 25 block A

ATM 25 block B

Bus32 bits

Figure 5--3 OMU module: functional blocks



Base I/O on VME board

The base I/O board houses the following main components:

VME64 interface

This interface is used to convert a VME64 bus into a PCI bus.

Note: For more information about the VME64 bus, please refer to theAmerican National Standard for VME64 (ANSI/VITA 1--1994).

an asynchronous interface

This interface is routed to the asynchronous block located on the OMU--TMassembly, then it is redirected either:

• to the 9--pin connector located on the front panel

• to the debug access bus located on the backplane

• to the CPU located on the OMU--TM assembly

a synchronous interface

This interface is routed to the 25--pin connector on the OMUmodule front panelvia the SLS block located on the OMU--TM assembly

an Ethernet interface

This interface is used to perform the communication between both OMUmodule

an SCSI/A interface

This interface is used tomanage aMirrored Shared disk located inside theMMSmodules via the SCSI bus


PE/DCL/DD/0126411--9001--126


5.1.3.2 OMU--TM assembly

The OMU--TM assembly houses an adapter board.

It mainly provides:

a point--to--point ATM25 interface with each ATM--SW module

a VME interface with the OMU--SBC board

the power supply to the module via a DC/DC converter

live insertion capability for the TMU module

the SBC physical access to all interfaces

reset control of the SBC

ITM Block

The ITM block is mainly composed of the ITM ASIC.

The main functions of this block are to:

provide amaster access to the various resources of eachmodule via theMTMbus

read the backplane

read the slot ID

manage several types of information storage (board identity, configurationinformation, module test data and the fault log)

select and control each LED located on the front panel

interface the system with the removal request push--button



ATM25 Block

The AAL (ATM Adaptation Layer) and the SAR (Segmentation and Reassembly)processing is handled by the ATM--SARwhich receives all ATMcells to/from bothATM Interfaces.

Reassembled AAL--1 flow is routed toward a synchronous interface of theOMU--SBC board.

Reassembled AAL--5 flow is routed by the CPU toward the OMU--SBC board viathe VME bus.

The ATM25 block contains the following main components:

an ATM25 interface

• this interface converts each ATM25 link to an Utopia level one bus and viceversa

an ATM--SAR interface

• this interface carries the OAM information, SS7 and LAPD protocolsbetween the BSC and MSC

• this interface receives, transmits and processes the IP protocol over AAL--5

The IP/AAL--5 cells carry the traffic between each module which are locatedinside the Control Node and the Interface Node

• this interface receives, transmits and processes the AAL--1 protocol

The AAL--1 cells carry:

– OAM information for the entire BSS network

– SS7 and LAPD protocols between the Control Node and the InterfaceNode and the Transcoder Node

CPU

The main functions of this block are:

to transport the frames between the ATM--SAR interface

to select the ATM25 from the ATM--SAR interface

to provide a SWACT condition signal to the other OMU--TM functional blocks

VME32 Block

The VME32 block is used for transmitting and receiving AAL--5 traffic betweenthe OMU--SBC board and the OMU--TM assembly.

The VME64 interface transforms the VME64 bus of the Base I/O board into Bus32 bits of the CPU. It is used to transfer the AAL--5 traffic received by the CPU tothe VME32 interface and vice versa.


PE/DCL/DD/0126411--9001--126


Asynchronous interface

This interface is routed to the DB 9--pin connector on the OMU front panel via theAsynchronous interface located on the OMU--TM assembly.

The asynchronous communication contains some port selection logic. It is used toprovide:

the capability of tri--stating the backplane asynchronous port during reset andwhile the OMU module is a slave

a switchable transparent connection between the OMU--SBC processorasynchronous debug port 1 and backplane asynchronous port or OMU--TMprocessor asynchronous debug port

a switchable transparent connection between the backplane asynchronous debugport and OMU--TM processor asynchronous debug port (for the passive OMUmodule)

a transparent connection between the front panel asynchronous debug port andthe OMU--SBC processor asynchronous debug port 2

SCSI tranceivers

This block is used to connect:

the SCSI/A interface located on the base I/O board to the first shared mirroreddisk

the SCSI/B interface located on the processor memory board to the secondshared mirrored disk

the SCSI/P interface located on the PCM board to the private disk

Miscellaneous

In addition to the above, the OMU module contains support for test functionsprovided by the ITM block and routed via a debug bus located on the backplane.



5.1.4 Hot swap removal request and action

A push--button which is mounted on the front panel provides the facility forrequesting removal of theOMUmodule. Pushing thebutton sets a latchon theOMUmodule. The latch can only be reset by an OMU ITM action or by cycling theMMS- 48 Vdc power (hot removal and reinsertion).

Note: Hot insertion of the OMU and MMS respectively are supported.

On detection of the removal request, the system software signifiesacknowledgement and acceptance of the removal request by continually winkingthe triangular red LED,which is the only legal condition for hot removal of anOMUmodule.

The OMU module must be removed within 15 minutes of the acknowledgementotherwise the system software will cancel the acceptance. The acceptance andacknowledgement facility is only a function of the software.

If the OMU module is not in exposure (no passive OMU module is ready to takeover the services) then the active OMUmodule will not accept the removal request.


PE/DCL/DD/0126411--9001--126


5.2 TMU module

The TMU module (see Figure 5--4) is, from the traffic point of view, a mini BSCwith up to 300 Erlangs of capacity.

It is based on a standard VME CPU board offering the processing power and aspecific PMC (PCI Module Card) implementing the coupling function.

From2 to 12+2TMUmodules can take a place inside theControl Nodeas a functionfor the processing requirements.

The TMU module manages the GSM protocols in a large acceptance:

provide processing power for GSM CallP

terminate GSM protocols (A, Abis and Ater interfaces)

terminate low level GSM protocols (LAPD and SS7)

The VME board gives the GSM processing capability, while the I/O a PMC boardgives capability (LAPD and SS7). The VME board and the PMC board are SCSAcompliant.

Each TMU module handles 64 bi--directional HDLC channels:

2 CCS7 channels:

• two channels fully loaded (Message SignalUnit of 40 byteswith only one flagbetween each MSU) in both way (transmit and receive),

• MTP1, MTP2, MTP3 and upper layers are performed

62 LAPD channels: level 1, level 2 and upper layers are performed.

A single Spectrum slot is used to install each TMU module, which contains:

a TMU--SBC assembly which houses:

• a regular VME board with high processing capability split up as follows:

• a TMU--PMC board

These components are connected to the TMU--TM assembly

a TMU--TM assembly which houses an adapter board provides:

• a point--to--point ATM25 interface with each ATM--SW module

• a VME interface with the OMU--SBC board



TMU

Visualindicators

Figure 5--4 TMU module: hardware overview


PE/DCL/DD/0126411--9001--126



The external interfaces of each TMU module are described below:

on the single front panel:


on the Control Node backplane:

• redundant ATM links

• redundant -- 48 Vdc links

• one Slot ID

• MTM bus


Each TMU module:


houses:

• a dc/dc converter which provides power to each component

• a ground for each component





Figure 5--5 shows each of the main functional block, which are housed in a TMUmodule.

5.2.3.1 TMU--SBC assembly

The TMU--SBC assembly houses:

a regular VME board with high processing capability

one PMC board

VME board

The VME board houses the following main components:

a CPU

VME64 interface

TheVME64 interface provides the VME64 bus on the OMU--TMassembly. It isused to transfer the AAL--5 traffic received by the CPU to the OMU--TMassembly and vice versa.

Note: For more information about the VME64 bus, please refer to theAmerican National Standard for VME64 (ANSI/VITA 1--1994)

Asynchronous interface

This interface is used, with some multiplexing logic, to select which processorthe OMU--SBC board can talk with.

TMU--PMC board

The TMU--PMC board gives the I/O capability (LAPD, SS7) in compliance withthe SC bus (SCSA standard).

The TMU--PMC contains a master CPU that allows transferring the DS0 to ATMframes.


PE/DCL/DD/0126411--9001--126


VME board

Frontpanel

LEDs

TMU module

ResetITMblock

TMU--SBC assembly

TMU--PMCboard

TMU--TM assembly

VME64 VME32

CPU

Bus32 bits

ATM 25 block B

dc/dcconverter

Backplane

Debugaccess

ATM25(A)

ATM25(B)

--48 V dc

MTM bus

Bus32 bits

CPU

VME64bus

SC--bus

PCI bus


CPU

Debug access block

ATM 25 block A

Bus32 bits

Figure 5--5 TMU module: functional blocks



5.2.3.2 TMU--TM assembly

The TMU--TM assembly is mainly responsible for:

adapting the VME64 bus to the ATM

adapting the SC--BUS to constant bit rate ATM

providing back plane communication redundancy

providing to the SBC a VME64 slot 1 like electrical environment

providing live insertion capability to the TMU module

giving the SBC physical access to all interfaces

resetting control of the SBC

ATM25 Block

The AAL (ATM Adaptation Layer) and the SAR (Segmentation and Reassembly)processing is handled by the ATM--SARwhich receives all ATMcells to/from bothATM Interfaces.

Reassembled AAL--1 flow is routed toward the PMC by a SC--BUS

ReassembledAAL--5 flow is routed by theCPU toward the SBCboard via theVMEbus.

The ATM25 block contains the following main components:

an ATM25 interface

This interface converts each ATM25 link to an Utopia level one bus and viceversa

an ATM--SAR interface. This interface is used:

• to carry the OAM information, SS7 and LAPDprotocols between the BSCe3and the MSC

• to receive, transmit and process:

– the IP/AAL--5 protocol

The IP/AAL--5 cells carry the traffic between each module, which arelocated inside the Control Node and the Interface Node

– the AAL--1 protocol

The AAL--1 cells carry:

• OAM information for the entire BSS

• SS7 and LAPD protocols between the BSC and MSC


PE/DCL/DD/0126411--9001--126


CPU

The CPU block is used to:

provide an interface to the VME interface for AAL--5 traffic between theOMU--TM assembly and the OMU--SBC board

receive the AAL--5 cells from the ATM25 interface

transmit the AAL--5 cells to the ATM25 interface

select the ATM25 cells for AAL--1 reception

provide a SWACT condition signal to other OMU--TM functional blocks

ITM Block



ensure access to these resources by the OMU Master of the MTM bus

read the backplane

read Slot ID


select and control each LED

check the connections, which are run on the debug access bus

VME Block

The VME block is used to transmit and receive AAL--5 traffic between theOMU--SBC board and OMU--TM assembly.

Miscellaneous

In addition to the above, the TMU module contains support for test functionsprovided by the ITM block and routed via a debug bus located on the backplane.



5.3 ATM--SW module

From a hardware perspective, the ATM subsystem is a key factor for the platformrobustness and scalability. This subsystem provides a reliable backplane boardsinterconnection with live insertion capabilities.

The ATM--SW module (see Figure 5--6 and Figure 5--7) houses the followingmain components:

an ATM switch

an ATM25 interface

It performs the adaptation of the ATM25 links, which are located on the ControlNode backplane, are performed in a dual star architecture. These links are used toconnect both ATM--SW modules and each of them to:

• the TMU modules

• the OMU modules

an ATM155 interface

The ATM155 links are used to connect each ATM--SW module to eachATM--RMmodule, which are located inside the Interface Node, via the SONETOC--3c optical multimode fibers.

A single slot allows to install each ATM--SWmodule, which houses the followingboards:

an ATM--SW--SBC board

It houses the ATM Cell Switch.

an adapter board named: ATM--SW--TM

It allows interfacing the ATM--SW--SBC with the:

• ATM25 links

• ATM155 links

• LEDs


PE/DCL/DD/0126411--9001--126





Guide slot

Guide pin



Tx connector

Rx connector

From Txconnector

on ATM--RM

To Rxconnector

on ATM--RM

Guide slot

Figure 5--6 ATM--SW module: hardware overview with OC3 optical fibers plug--in



ATM_SW

Visualindicators

TXOC--3connector

RXOC--3connector

Figure 5--7 ATM--SW module: hardware overview


PE/DCL/DD/0126411--9001--126



The external interfaces of each ATM--SW module are described below:

on the front panel:


• one TX connector for the OC3 optical multimode fiber

• one RX connector for the OC3 optical multimode fiber

on the backplane:

• redundant ATM links

• redundant -- 48 Vdc links

• one Slot ID

• MTM bus


Each ATM--SW module:

is powered by the -- 48 Vdc which comes from the operator boxes via the PCIUassembly and the SIM modules

houses:


• a common ground for each board





Figure 5--8 shows each of the main functional blocks which are housed inside anATM--SW module.

5.3.3.1 ATM--SW--SBC

It has the following main functions:

manages the ATM25 switching

manages the ATM25 adapter

provides the ATM155 interface

supervises the passive ATM--SW module

ATM Switch

The ATM switching consists first of all in establishing for each communication avirtual circuit using Vc (Virtual channel) or Vp (Virtual path). These virtual circuitsare established statically according to engineering rules, they are PVCs (PermanentVirtual Circuits).

The main function of an ATM switch is to receive cells on a port and switch thosecells to the proper output port based on the Vp and Vc values of the cell.

This switching is controlled by a switching table that maps input ports to outputports based on the values of the Vp and Vc fields. While the cells are switchedthrough the switching fabric, their header values are also translated from theincoming value to the outgoing value.

Addressing tables converting between Vp, Vc and slot number are loaded fromATM--SW module at start--up time and stored in the flash EPROM of ATM part:

AAL--1 routing tables are dynamic

AAL--5 routing tables are static

ATM25 adapter

Each of the three ATM25 interfaces is used to convert six ATM25 links into anUtopia Level one bus.


PE/DCL/DD/0126411--9001--126


Frontpanel

LEDs

ATM--SW module

ResetITMblock

ATM--SW--SBC assembly

ATM switch

ATM--SW--TM assembly

ATM155interface

Utopia bus

Bus32 bits

Debug accessblock on

asynchronousinterface

CPU

dc/dcconverter

Backplane

RxOC--3

connector

--48 V dc

MTM bus

Debugbus

ATM25interface

OC--3optical interface

ATM25

ATM25(18)

(1)

TxOC--3

connector

To/fromATM--RM via

an OC--3optical multimode fiber

To/fromATM--RM via

an OC--3optical multimode fiber

Figure 5--8 ATM--SW (CC--1) module: functional blocks



5.3.3.2 ATM--SW--TM

The ATM--SW--TM manages the following functions:

interfaces the CC1--SBC to the Control Node backplane

provides the power supply to the CC1 module

provides the OC--3c optical multimode fibers

ITM block



ensure access to these resources by the OMU Master of the MTM bus

read the backplane

read Slot ID



control the connections, which are run on the debug access bus

ATM155 block

This block is used to convert the ATM155 links into SUNI/SDH frames.

OC--3c optical multimode fiber

This block is used to:

provide access to the TX OC--3c multimode optical fiber

provide access to the RX OC--3c multimode optical fiber

supervise the optical link (the errors, the clock Sync, etc.)

Miscellaneous

In addition to the above, the ATM--SW module contains support for test functionsprovided by the ITM block and routed via a debug bus located on the backplane.


PE/DCL/DD/0126411--9001--126


5.4 MMS modules

The Control Node houses four MMS modules (see Figure 5--9). Each of themcontains a SCSI hard disk. They are split up as follows:

two shared hard disks are managed in a mirroring way for both OMU modules

Each of them is used to save the data in the event of a softwareor hardware failureinside the OMU module or the MMS module

one private disk for the OMU--A module

It is used to save the private data for the OMU--A module

one private disk for the OMU--B module

It is used to save the private data for the OMU--B module

The MMS module provides circuitry and mechanical features. It is compliant withthe Control Node hardware architecture.


The external interfaces of each MMS module are described below:

on the front panel:


• one push button to request to remove the MMS module

on the backplane:

• SCSI bus

• one SCSI slot ID

• MTM bus


Each MMS module:


houses:


• a ground for each metallic board




MMS

Visualindicators

Removalrequestpush--button

Figure 5--9 MMS module: hardware overview


PE/DCL/DD/0126411--9001--126


5.4.3 Functional block description

Figure 5--10 shows each main functional block inside an MMS module.

ITM block

Its main functions are to:

read the backplane

read the Slot ID



interface the system with the removal request push button

Frontpanel

LEDs

MMS module

Reset

ITMblock

Ultra2 LVD SCSI disk

dc/dcconverter

--48 V dc

MTM bus

Removalrequestswitch

SCSI bus

Backplane

Figure 5--10 MMS module: functional blocks



SCSI Bus

SCSI terminators (see Figure 5--11) are placed on allMMSmodules to provide theability to terminate both ends of the SCSI bus and depending on thebackplane--derived signals the terminators are either enabled or disabled. Thebackplane signals are slot dependent to allow the MMS modules to automaticallyconfigure into its correct role.

Hard disk

TheHard disk uses the standard 3.5” disk form and ismounted on theMMSmodule.All electrical connections are available through the 80--pin SCA-2 connector andare connected into the MMS module using 80--way ribbon cable and insulationdisplacement connectors.

SCSI/B

SCSI/A

SCSI/PA SCSI/PBOMU--A OMU--B

Private disk Private disk

Mirrored shared disks

: Transaction available when OMU--A is active.: Transaction available when OMU--B is active.: Transaction always available.

MMS

MMS MMS

MMS

Figure 5--11 SCSI bus transaction: OMU modules to/from MMS modules


PE/DCL/DD/0126411--9001--126


5.4.4 Hot swap removal request and action

A pushbutton which is mounted on the front panel provides the facility forrequesting removal of theMMSmodule. Pushing thebutton sets a latchon theMMSmodule which stimulates the active OMU module.

Note: Hot insertion of the OMU and MMS respectively are supported.

The latch can only be reset by:

an ITM action on the OMU module

or by cycling the MMS - 48 Vdc power (hot removal and reinsertion).

On detection of the removal request, the system software signifiesacknowledgement and acceptance of the removal request by continually winkingthe triangular red LED,which is the only legal condition for hot removal of anMMSmodule.

TheMMSmodulemust be removedwithin fifteenminutesof the acknowledgementotherwise the system software will cancel the acceptance. The acceptance andacknowledgement facility is only a function of the software.

If the MMS module is not in exposure (no passive MMS module is ready to takeover the services) then the removal request will not be accepted by the OMUmodule.

5.5 SIM module

For a description of the SIM module refer to paragraph 1.4.1.5.

5.6 FiIler module

For a description of the FILLER module refer to paragraph 1.4.2.2.

Interface node descriptionNortel Networks Confidential 6--1


6 INTERFACE NODE DESCRIPTIONThe Interface Node performs the following functions (see Figure 6--1):

provides network connectivity with:

• the BTSs via the SAI on the Abis interface

• the TCU e3 via the SAI on the Ater interface

• the PCUSN via the SAI on the Agprs interface

communicates with the Control Node via the TCP/IP protocol over AAL--5

routes the AAL--1 cells over the ATM network for the LAPD and SS7 channels

converts the AAL--1 cells into DS0 links

provides the 16 or 8 kbps circuits in the I--Node for bearer speech/data channelsbetween the BTSs and the MSC via the TCU e3 or the SGSN via the PCUSN

BSC e3 FRAME

LSA--RC5

INTERFACE NODE

CONTROL NODE

LSA--RC4

LSA--RC3

LSA--RC2

LSA--RC1

LSA--RC0

CEM(active/passive)

CEM(active/passive)

IMC

Tx0 Rx0 Tx1 Rx1 Tx2 Rx2 Tx3 Rx3 Tx4 Rx4 Tx5 Rx524681012

Ethernet linkto TML

Ethernet linkto TML

6 6 6 6 6 6 6 6 6 6 6 6



ATM--RM


3 9 9 3 3 9 9 3

ATM links (155 Mb/s)on optical fiber ATM links (155 Mb/s)

on optical fiber

ATM_SW ATM_SWTransmission


Reception

ATM--RM

To/from SAI frame


Figure 6--1 BSC e3 frame (Interface Node): physical architecture

Interface node description Nortel Networks Confidential6--2

PE/DCL/DD/0126411--9001--126


The Interface Node hardware architecture for the BSC e3 is based on the generalSpectrum platform with the following features:

high speed telecom interfaces

twenty--eight general purpose slots for application and interface modules

two slots reserved for both SIMmoduleswhich provide to each other module the-- 48 Vdc and the alarm links

Note: The system does not support hot extraction of an active Interface NodeCEM. The system does, however, support hot extraction when the CEM ispassive. To ensure that the CEM is passive before performing a hotextraction, see “Replacement of a CEM” in the BSC/TCU e3MaintenanceManual (411--9001--132).

The fault tolerant architecture is based on duplicated CEM modules. One CEMmodule is active (that is, actually performing the call processing procedure) whilethe other is inactive, ready to take over if the active module fails.

Both CEM modules:

receive identical PCM (E1/T1) links from each resource

can communicate together via the IMC (Inter Module Communication) links, inorder to synchronize:

• call processing

• maintenance states

Each of the other RMs (ATM--RM, 8K--RM and LSA--RC modules) is connectedto the CEM modules via the S--Link interfaces. This results in a point--to--pointarchitecture, which (when compared to bus architecture) provides:

superior fault containment and isolation properties

fewer signal--integrity--related problems

easier backplane signal routing

In addition, to the speech data channel, the S--Link interfaces transport messagingchannels and overhead control and status bits between the CEMmodules and eachRM. Each S--Link interface provides 256 TS.

Each slot for each:

ATM--RMmodule has access to three S--Link interfaces, or 768DS0 channels toeach CEM module

IEM module located inside the LSA--RC module has access to three S--Linkinterfaces, or 768 DS0 channels to each CEM module

8K--RM module has access to nine S--Link interfaces, or 2304 DS0 channels toeach CEM module



Note: Nevertheless the 8K--RMmodule can be inserted in a generic slot. In theinitial product release, the 8K--RM module must be installed in a slotwith nine S--Link interfaces.


PE/DCL/DD/0126411--9001--126


6.1 CEM module

The CEMmodule (see Figure 6--2) provides the centralized resources required tosupport the Interface Node applications.

The CEM module manages the following functions:

64 K switching matrix

message processing of the Interface Node: OAM and CallP over AAL--5

control each of the other resource modules (8K--RM, ATM--RM and LSA--RCmodules)

clock subsystem

alarm processing


The external interfaces of each CEM module are described below:

on the front panel:


• an Ethernet link on the RJ45 connector to connect the TML

Note: You can connect the TML to the CEM module only after havingplugged the TML on the OMUmodule or on the optional HUB(s) tofind a hardware fault or a software fault inside the Interface Node.

on the backplane:

• S--link redundancy

• -- 48 Vdc links redundancy

• IMC link redundancy

• MTM bus

• one Slot ID


Each CEM module:


houses:






CEM

Visualindicators

Unused

RJ45connector(for Ethernet)

Figure 6--2 CEM module: hardware overview


PE/DCL/DD/0126411--9001--126


6.1.3 Functional Blocks

Figure 6--3 shows each of the main functional blocks, which are housed inside aCEM module.

6.1.3.1 S--Link interfaces

The S--Link interfaces are split up as follows:

a reception part

a transmission part

This block converts the parallel data format used on the CEM module and the 256DS0 serial links to interface with each ATM--RM, 8K--RM and IEM module. Inaddition, it distributes the system clock to the RM, and provides low level controland status by means of overhead bits embedded in the S--Link format.

Physically, this block is composed of 96 S--link interfaces.

6.1.3.2 Switching matrix 64 K

Bandwidth allocator

The bandwidth allocator contains two parts:

a selection part (BWA--S)

a distribution part (BWA--D)

This block is used to:

groomplatform overheadDS0 from the S--Link interfaces to the timeswitch, andvice--versa, allowing for variations in TS usageby eachRM(ATM--RM, 8K--RMand IEM modules)

selectively merge the DS0 stream with the S--Links

apply digital padding (selectable on a per--DS0 basis) to DS0 from thetimeswitch

extract and insert messaging channels from the DS0 stream, and present them tothe messaging block

provide a mechanism to make improvements to switch from an active RM to anpassive RM for the sparing operation

Timeswitch

The timeswitch provides the single DS0 rearrangement functions. It has 12KDS0,and is a double--buffered (N x DS0 capability) design, based on the ENETcomponents.



Switching matrix64K

Frontpanel

LEDs

CEM module

Reset ITMblock

CPU

dc/dcconverter

Backplane

--48 V dc

MTM bus

S--link(Tx)

S--link(Rx)

Messagingblock

BWA--distribution

Timeswitch

BWA--selection

S--link interface

S--link interface

IMC block

Ethernetinterface

EthernetonRJ45connector

To otherCEMmodule

Figure 6--3 CEM module: functional blocks


PE/DCL/DD/0126411--9001--126


6.1.3.3 ITM block

The ITM block provides and interfaces the MTM bus between the ATM--RMmodules and the other RMs. These functions can be also controlled and accessedby the CPU.

6.1.3.4 Messaging block

This block provides the protocolmessaging functionality. Up to 32messaging portscan be provisioned. Each port allows a bandwidth of: N x DS0.

The messaging ports are used for:

host messaging

RM messaging

IMC messaging

one spare port for diagnostics

6.1.3.5 CPU

The CPU is responsible for local initialization, configuration, and maintenance ofthe RMs, as well as communication with the CEM module via the S--Linkmessaging facility.

The CPU contains the main functions required to accommodate the various busformats used on theRM. In addition, it provides serial access for messaging throughthe S--link interfaces.

6.1.3.6 Ethernet interface

The CEM module provides a 10BaseT Ethernet interface for the attachment of aTML, as well as debug tools.

6.1.3.7 Clock subsystem

This clock subsystem is used to generate the Interface Node system clock. It cangenerate a clock phase locked (8 KHz) to phase information acquired from an RMslot. In addition, this block allows to determine the CEM module activity andcoordinates the SWitch of ACTivity between an active RM and a passive RM. Theclock is distributed to the RMs via the S--link interfaces.

6.1.3.8 IMC block

This block is used to connect both CEM modules via the IMC links.

An IMC link has a bandwidth of 126 DS0. It is a specific interface dedicated to themessaging between both CEM modules.



6.2 ATM--RM module

The ATM--RM module provides the centralized resources required to support theInterface Node applications.

The ATM--RM module provides (see Figure 6--4 and Figure 6--5):a SONET OC--3 physical interface that allows direct connection to the ATMnetwork located on the Control Node

interworking functionality between the cell based ATM network (ATM25interfaces) located on backplane of the Control Node and the switching network(S--link interfaces) located on backplane of the Interface Node

The main functions of the ATM--RM module are:

interface to an OC--3 optical multi--mode fiber

termination of ATM forum specified SONET transport and path overhead

termination of ATM OAM and CallP cells

map DS0 to ATM cells over AAL--1 for Nx64 connections and speech/datachannels


The external interfaces of each ATM--RM module are described below:

on the front panel:


• one TX connector for the OC--3 multi--mode optical fiber

• one RX connector for the OC--3 multi--mode optical fiber

on the backplane:



• one Slot ID


Each ATM--RM module:

is powered by the -- 48 Vdc which comes from the operator boxes via the PCIUframe assembly and the SIM moduleshouses:





PE/DCL/DD/0126411--9001--126


ATM--RM

Visualindicators

TXOC--3connector

RXOC--3connector

Figure 6--4 ATM--RM module: hardware overview







Guide slot

Guide pin


Attenuator

Tx connector

Rx connector

From Txconnector

on ATM--SW

To Rxconnector

on ATM--SW

Guide slot

Figure 6--5 ATM--RM module: optical fibers plug--in


PE/DCL/DD/0126411--9001--126



Figure 6--6 shows each of the main functional blocks, which are housed inside anATM--RM module.

6.2.3.1 ITM block

The ITM block provides and interfaces the MTM bus between the ATM--RMmodule and the other RMs. These functions can be also controlled and accessed bythe CPU.

6.2.3.2 CPU

The CPU contains themain functions to accommodate the various bus formats usedon the RM. In addition it provides serial access for messaging through the S--linkinterfaces.

6.2.3.3 S--link Interfaces

The S--Link interfaces allow to interface the ATM--RMmodule to the CEMmodulevia the backplane of the Interface Node. The S--Link interfaces provide: DS0connectivity and the SPMmessaging infrastructure. In total, the ATM--RMmodulecan access to nine S--Link interfaces, or 2304 DS0 channels. For the Interface Nodeit has access to only three S--Link interfaces, or 768 TS to each CEM module.

6.2.3.4 ATM/DS0 Adaptation

Themapping of theATMcells toDS0 channels is performed by theNortel networksstandard device designated the AAL--1 entity or AAE. A pair of AAE is used on theATM--RM module to map up 2048 ATM virtual circuits into a maximum to 2048DS0s.

This mapping has two general cases: Nx64 trunking, and single DS0 trunking(speech/single channel data traffic). Nx64 traffic aggregates multiple DS0s from asingle frame into a single data path.

6.2.3.5 OC--3 optical interface

The optical module is used to:

provide access to the Control Node via the:

• OC--3 multi--mode optical fiber for the transmission

• OC--3 multi--mode optical fiber for the reception

supervise the optical link (the errors, the clock Sync, etc.)

The current designwould require an external attenuator to limit the optical powerfor the multi--mode interfaces.



Frontpanel

LEDs

ATM--RM

Reset ITMblock

S--linkinterfaceCPU

dc/dcconverter

Backplane

RxOC--3Cconnector

--48 V dc

MTM bus

ATM/DS0adaptation

S--link(Tx)

S--link(Rx)

TxOC--3Cconnector

To/fromATM_SW (Rx)

via OC--3optical

multi mode fiber

To/fromATM_SW (Tx)

via OC--3optical

multi modefiber

OC3optical interface

Figure 6--6 ATM--RM module: functional blocks


PE/DCL/DD/0126411--9001--126


6.3 8K--RM module

The 8K--RM module is also named “SubRate Timeswitch” (see Figure 6--7). It isan application--specific circuit module which performs a timeswitch function onsub--DS0 rate channels, allowing for the efficient switching of 8 and 16 kbpschannels.

The role of the 8K--RMmodule is to add subrate switching capability to the cabinet,as the CEMmodule is only capable of switching at a DS0 level (64 kbps channels).It provides a secondary stage of switching individual bits within DS0s, supportingup to 16 kbps channels (contained in 2268 DS0s).

It manages the following main functions:

transmits and receives data to/from two (active and inactive) CEM modules vianine S--links

provides non--blocking sub--DS0 rate timeswitching on 8 kbps channels


The external interfaces of each 8K--RM module are described below:

on the front panel:


on the backplane:



• MTM bus

• Slot ID


Each 8K--RM module:


houses:






8K--RM

Visualindicators

Unused

Figure 6--7 8K--RM module: hardware overview


PE/DCL/DD/0126411--9001--126



Figure 6--8 shows each of main functional blocks, which are housed in a 8K--RMmodule.

6.3.3.1 ITM block


6.3.3.2 S--link interface

The S--Link interfaces allow to interface the 8K--RM module to the CEM modulevia the backplane of the Interface Node. The S--Link interfaces provide: DS0connectivity and the SPM messaging infrastructure. In total, the 8K--RM modulecan access to 9 S--Link interfaces, or 2304 DS0 channels.

6.3.3.3 Switching Matrix

The 8K--RM module switches 32,768 1--bit channels at an 8 kHz frame rate andoperates on 8 channels in parallel. Also, data coming into and going out of themodule is formatted as 8 channels per DS0. A separate connection memory isrequired for each speech memory. The complete matrix is composed of eightchannels in parallel, one for each bit of the outgoing DS0.

Incoming data samples are sequentially written into one half of the speechmemorywhile they are simultaneously being read out of the other half of the speechmemory.

6.3.3.4 CPU

The CPU contains themain functions to accommodate the various bus formats usedon the RM. In addition it provides serial access for messaging through the S--linkinterfaces.

6.3.3.5 Messaging block

This block provides the protocolmessaging functionality. Up to 32messaging portscan be provisioned. Each port allows a bandwidth of: N x DS0.

The messaging ports are used for:

host messaging

RM messaging

IMC messaging

one spare port for the diagnostics



Frontpanel

LEDs

8K--RM module

Reset ITMblock

S--linkinterface

CPU

dc/dcconverter

Backplane

--48 V dc

MTM bus

Siwtchingmatrix 8K

S--link(Tx)

S--link(Rx)S--link

interface

Messagingblock

Figure 6--8 8K--RM module: functional blocks


PE/DCL/DD/0126411--9001--126


6.4 LSA--RC module

The Low Speed Access for the Interface Node is defined as either PCM (E1/T1)interfaces and is achieved via:

a LSA--RC module housed inside the Interface Node shelf

a CTU module housed inside the SAI frame assembly

The LSA--RC module provides an electrical interface for the signals on the PCM(E1/T1) links. The CTU module provide:

copper management

manual loopback

lightning protection

impedance matching

Figure 6--9 shows the electrical architecture between a LSA--RC module in theBSC e3 frame and a CTU module in the SAI frame.

TheLSA--RCmodule provides access to 21 PCME1 links or 28 PCMT1 links. Thisquantity of PCM (E1/T1) links allows full utilization of the S--Link bandwidthavailable on the backplane.

It occupies three slots on the Interface Node shelf and consists of the followingmodules (see Figure 6--10 and Figure 6--11):

a duplicated pair of IEM modules

a single TIM module

an RCM (Resource Complex Mini backplane)

Due to the large quantity of PCM (E1/T1) links carried on a single LSA--RCmodule, the system has been designed to minimize the possibility that the failureof a single module will cause the failure of an entire LSA--RC module. This isaccomplished by duplicating the IEMmodules, which contain all of the electroniccircuitry. The IEM module that is receiving the PCM signals is considered as theactive IEM module while the other is considered as the passive IEM module.

This IEM module is used to:

provide PCM (E1/T1) interfaces with each BTS: Abis interface

provide PCM (E1/T1) interfaces with the TCU e3: Ater interface



convert the PCM (E1/T1) links in DS0 on the S--link interfaces. The DS0transport:

• SS7 channels

• LAPD channels

• speech/data channel

format the data in the proper high speed serial format necessary for processingbythe CEM module


PE/DCL/DD/0126411--9001--126


CTU

TIM

LSA--RC

RCM

CTMx

CTB

IEM 1IEM 0

To/from CEM modules21 E1/28 T1 external PCM links

to/from operator boxes

SAI frame BSC e3 frame

Internal RxPCM links

Internal Tx PCM links

Note: . the bold lines show the PCM external links. the regular line show the PCM internal links. CTMx corresponds to seven:

-- CTMD for 28 PCM T1 links TW pair-- CTMC for 21 PCM E1 links TW pair-- CTMP for 21 PCM E1 links coax

Figure 6--9 LSA--RC/CTU module: electrical architecture



TIMmodule

IEMmodules

RCM

Figure 6--10 LSA--RC module: hardware overview


PE/DCL/DD/0126411--9001--126


MultipleSpanAlarms

MultipleSpanAlarms

Visualindicators

SPAN# with faultcondition display

‘UP’ arrow button

‘LOW’ arrow button

Red LED blinks

Tx signals on62--pin connector

Rx signals on62--pin connector

IEM IEMTIM

Figure 6--11 LSA--RC module: front view



6.4.1 IEM module

Two versions of the IEM module (see Figure 6--11) are available:one interfaces:• twenty--one 120 Ω four--wire PCM E1• or twenty--one 75 Ω coax PCM E1the other interfaces twenty--eight 100 Ω four--wire PCM T1

The IEM module contains a PCM (E1/T1) adaptator to terminate each PCM link.

The speech/data channels from all of the PCM (E1/T1) links are multiplexed ontothe S--link interface via the PCM (E1/T1) adaptator and vice versa.

The LSA--RC module provides management for either 21 E1 or 28 T1 PCM links.Nevertheless, each PCM (E1/T1) is an individual network element that can connectto another piece of transmission equipment located at a great distance away.

During troubleshooting activities, it is desirable to quickly classify PCM (E1/T1)Faults. To this end, the LSA--RCmodule provides loopback switches for each PCM(E1/T1) via the CTMx boards which are housed inside the SAI frame.

It is very important in the troubleshooting and maintenance of transmissionequipment, that the loopback feature be operated only after the PCM (E1/T1) hasbeen prepared for maintenance. Failure to do so could cause the unexpectedtermination of multiple network connections.

After the BSC e3 cabinet is fully installed and all the cables are dressed within cablemanagement facilities, it will not be obvious to the operator which Loopback pushbuttton on the CTMx board is associated with the corresponding LSA--RCmodule.

The solution for this small dilemma is to know that (see Figure 1--23and Figure 1--24):the minimum port number of a PCM (E1/T1) is located on the bottom left of aCTU modulethemaximumport number of a PCM (E1/T1) is located on the top right of aCTUmodule

PROM resident inside the IEM modules enables functions that are directly relatedto the type of module that hosts them. However, their common purpose is to detectany changes in their physical environment (external alarm loops, PCM (E1/T1)connections.)

They do the following:initialize board software and hardware by configuring the data loaded by theBSC e3 to match the host board operating needsdetect and confirm physical changes in the BSC e3 environment (PCM alarms,alarm loops, etc.)report events to the BSC e3


PE/DCL/DD/0126411--9001--126


The frame alignment circuit raises the following alarm condition signals:

LOS -- Loss of Signal

• Fault Definition

The LOS defect is detected when the incoming signal has no transitions.

The LOS defect is cleared when the incoming signal has an average pulsedensity.

The presence of the LOS fault at any time during the previous one--secondinterval

• LED Requirement

LOS LED is turned:

– ON when LOS GSM fault is the highest ranking GSM fault

– OFF when LOS GSM fault is no longer the highest ranking GSM fault

AIS -- Alarm Indication Signal


On the T1 line, AIS is represented by an (unframed) all--ones signal.Internally, AIS is represented by all--ones in all timeslots.

An AIS defect is:

– detected when the incoming signal is an unframed signal with ONEsdensity present for a time equal to or greater thanT, whereT is3ms to75ms

– cleared within a time period T when the incoming signal does not meeteither the ONEs density or the unframed signal criteria, where T is 3ms to75ms

The presence of the AIS fault at any time during the previous one--secondinterval

• LED Requirement

AIS LED is turned:

– ON when AIS GSM fault is the highest ranking GSM fault

– OFF when AIS GSM fault is no longer the highest ranking GSM fault



LFA for E1-- Loss of signal Frame AlignmentorLOF for T1 -- Loss Of signal Frame alignment


Frame alignment is said to be lost when three consecutive errors of thealignment signals are received. It is also said to be lost when three errors of thebit 2 in TS0 in frames not containing alignment signals are received.

LFA or LOF should be detected within 12 ms. It must be confirmed overseveral frames to avoid the unnecessary initiation of the frame alignmentrecovery procedure due to the transmission bit errors. The frame alignmentrecovery procedure should begin immediately once a LFA or a LOF has beenconfirmed.

The maximum average reframe time should not exceed 15 ms (for ESF) and50 ms (for SF). The maximum average reframe time is the average time toreframe when the maximum number of bit positions must be examined tolocate the frame alignment signal.

The presence of the LOF fault at any time during the previous one--secondinterval

• LED Requirement

LFA LEDs or LOF LEDs are turned:

– ON when a frame alignment GSM fault is the highest ranking GSM fault

– OFF when a frame alignment GSM fault is no longer than the highestranking GSM fault

RAI -- Remote alarm Indicator


For SF framing, RAI should be detected by bit 2 in every channel time slotbeing set to 0.

For ESF framing, RAI should be detected by the frame alignment alarmsequence (FF00).

The presence of the RAI fault at any time during the previous one--secondinterval

• LED Requirement

RAI LED is turned:

– ON when the RAI GSM fault is the highest ranking GSM fault

– OFF when the RAI GSM fault is no longer the highest ranking GSM fault

The application manages LFA for E1 or LOF for T1, AIS, and RAI. Thecorresponding alarm LED lights for at least 200 ms upon each alarm occurrence.The LEDs on the front panel of the board display these alarms.


PE/DCL/DD/0126411--9001--126


6.4.1.1 External interfaces

IEM front panel

Figure 6--11 shows the front panel of both IEM modules.

The T1 version of the faceplate is virtually a subset of the E1 version and will notbe shown in Figure 6--11. The only difference will be that the acronym LFA willbe displayed as LOF. The behavior described within will apply in either case.

Visual indicators

The visual indicators which contain the red and green LEDs at the top of the frontpanel are “standard“ spectrum LEDs. They indicate the IEM module or the TIMmodule status.

For more information about these LEDs refer to their generic description inparagraph 1.4.1.5.

LSA Specific Requirements on the Interactive front panel

Primarily, the LEDson the front panel are used to display specific information aboutthe alarms on the PCM(E1/T1) links. The requirements to display alarms for aPCM(E1/T1) link are different, so a slightly different set of LEDs are required whichmeans that different faceplates are required.

The philosophy regarding the display of alarms will be to display NO informationwhen there are NO problems to report. As an exception to this rule, “OK“ will bedisplayed on the alpha--numeric LED of the active IEMmodule when there are noalarms to report. This has the effect of passively indicating to the operator whichIEM module is “active“ and which is “passive”.

The interactive portion of the front panel consists of the following elements:

multiple span failure indication LED

signal failure indication LEDs for an PCM E1 link: LOS, AIS, LFA, and RAI

signal failure indication LEDs for a PCM T1 link: LOS, AIS, LOF, and RAI

PCM (E1/T1) number failure indicator

increment/decrement controls to show alarms for multiple failed spans

Requirements will be presented here for each of these elements as they apply toGSM LSA E1 or T1.



Multiple PCM (E1/T1) failure LED

If there is a failure in zero or one PCM(E1/T1) link, themultiplePCM(E1/T1)LEDmust be off.

If one or more additional alarms are detected on other PCM (E1/T1) links withinthe same IEM module, then the multiple PCM (E1/T1) alarm will begin to blink,signalling to the operator that more information is available by pressing one of thearrow keys.

Pressing the arrow key will increment (“Up“ arrow key) or decrement (“Down“arrow key) the information displayed on the interactive front panel to the next Faultalarm. Like before the # of the troubled PCMwill be displayed along with the faultcondition LED.

The LSA--RCmodule providesmanagement for either 21 PCME1 links or 28 PCMT1 links, but in the outside plant, each PCM (E1/T1) is an individual networkelement that can connect to another piece of transmission equipment located a greatdistance away.

Signal failure indicator

The signal failure LEDs have a transparent text cover which indicates the type ofsignal failure detected in the receive signal of the IEM module. The followingrequirements describe how these LEDs must be used by an E1 or a T1 LSA:

no failure indicator LED will be lit if the span failure indicator shows “OK“,“XX” or blank

if a failure exists in one or more PCM (E1/T1) links, the signal failure displayedon the faceplate must reflect the PCM (E1/T1) number shown in the PCM(E1/T1) indicator

only the highest severity signal failure will be presented on the front panel for agiven PCM (E1/T1)

if a failure on an PCM (E1/T1) is cleared, the failure must be removed from thefaceplate at the same time the clear is reported inside defect monitoring


PE/DCL/DD/0126411--9001--126


PCM (E1/T1) failure indicator

The PCM (E1/T1) failure indicator is used in conjunction with the signal failureindicators to show the type of failures encountered on a given PCM (E1/T1). Thefollowing requirements describe how the PCM (E1/T1) failure indicator is used onthe interactive front panel of the IEM module:

it will be blank until the IEM module is brought into service

it will contain the text “OK“ on the active IEMmodulewhen all are provisioned :

• PCM E1 links have no signal failures: LOS, AIS, LFA, or RAI

• PCM T1 links have no signal failures: LOS, AIS, LOF, or RAI

it will contain blank (no text or symbol) on the inactive IEM module

it will contain the text “XX“ on the active IEMmodule when there is a problemwith the copper connection between the IEM module and the SAI frame. Thisindication will be shown regardless of whether carriers are in service

if a single PCM(E1/T1) failure occurs, the PCM(E1/T1) failure indicator will beupdated to show the affectedPCM(E1/T1) number. ThePCM(E1/T1) links are anumbered from 0 to 20 inclusive. The PCM(E1/T1) links are a numbered from0to 27 inclusive

for multiple PCM (E1/T1) failures, the PCM (E1/T1) failure indicator shows thelast, viewed PCM (E1/T1). The PCM (E1/T1) information is not changed as theconsequence of a new PCM (E1/T1) failure

PCM (span) failures must be sorted by a PCM (E1/T1) number. The PCM(E1/T1) links must not be listed by order of failure occurrence

if a failure is cleared on an PCM (E1/T1) link displayed on the front panel andthere are multiple PCM (E1/T1) links experiencing failures, the front panel willbe updated to show the failure on the next, lowest PCM (E1/T1). If the clearingevent is associated with the lowest numbered PCM(E1/T1), the next PCM(E1/T1) is shown

if a failure is cleared on an PCM(E1/T1) displayed on the faceplate and this is theonly PCM (E1/T1) failure present, the PCM (E1/T1) failure indicator must beupdated to show “OK” provided no cabling problems exist



Increment/decrement PCM (E1/T1) control

The increment/decrement PCM (E1/T1) control is used by the operator to check thestatus of multiple failed PCM (E1/T1) links.

The increment/decrement control has behavior when the multiple PCM (E1/T1)links LED indicates multiple failures. The increment/decrement controls donothingwhen there is a singlePCMfailureor the span indicator shows “OK“, “XX“,or blank.

If the increment control (up arrow) isusedwhenmultiple PCM(E1/T1) link failuresare present, the PCM (E1/T1) failure indicator must be updated to show the next,highest sorted PCM (E1/T1) link failure. If the last, selected span had the highestvalue for any failed span, the next span shownwill have the lowest failed spanvalue.

If the decrement control (down arrow) is used when multiple PCM (E1/T1) linkfailures are present, the PCM (E1/T1) failure indicator must be updated to show thenext, lowest sorted PCM (E1/T1) link failure. If the last, selected PCM (E1/T1)links had the lowest value for any failed PCM (E1/T1), the next PCM (E1/T1)shown will have the highest failed PCM (E1/T1) value.

IEM backplane

The backplane houses the following interfaces:



• MTM bus redundancy

• PCM link redundancy

• slot ID

6.4.1.2 Electrical characteristics

Each IEM module:


houses:

• a dc/dc converter which provides power to each component




PE/DCL/DD/0126411--9001--126


6.4.1.3 Functional Blocks

Figure 6--12 shows each of the main functional blocks, which are housed insidean IEM module.

ITM block


PCM adaptator

The PCM adaptator performs, on the 21 E1 or 28 T1 PCM links, the followingfunctions:

line driving

framing

receive path elastic store

(TX) and (RX) mapper

It is used to transfer the PCM (E1/T1) links between the channels on the S--Linkinterface and the respective channels of the PCM (E1/T1) adaptor. In addition, itallows to create the clock and the synchronization signals needed by the PCM(E1/T1) adaptor. There will also be a capability to provide a loopback of all thechannels received from the framers to their respective transmit data inputs.

The ReceiveMapper will receive serial data from each of the PCM (E1/T1) adaptorat the line rate (2048 Mbps for PCM E1 links or 1544 Mbps for PCM T1 links).These streams of data will be converted to parallel bytes and multiplexed for PCM(E1/T1) links.

The Transmit Mapper will do just the opposite as the Receive Mapper.

Clock Sync

Timing in the BSS must be synchronized with the BTS and the TCU e3, therefore,the IEMmodule must be able to provide phase and frequency error feedback to theBSC e3 system clock generator located in the CEM module. This is accomplishedwith a phase comparator located in the IEM module. One input to the phasecomparator is derived from the S--Link clock. The other input is derived from oneof the incoming PCM (E1/T1) links. The IEM module can select any of theincoming PCM (E1/T1) links to be the synchronous reference.

Note: The LSA--RC module has no dedicated input port for an externalsynchronization reference.



CPU

The CPU is used to:

configure the PCM (E1/T1) links (frame format, line coding, etc.)

control the front panel status indicators


PE/DCL/DD/0126411--9001--126


RCM

Frontpanel

LEDs

IEM module

Reset ITMblock

HDLC (*)

CPU

dc/dcconverter

Backplane

--48 V dc

MTM bus

S--link(Tx)

S--link(Rx)

S--linkinterface

PCMadaptator

PCMlinks

Clock sync

Sync.links

(Tx)mapper

(Rx)mapper

Messaging

alarmdisplay

1Note: Indicate that PCM links are directly connected to the TIM module.

(*) The HDLC is not used in the interface node.

1

Figure 6--12 IEM module: functional blocks



6.4.2 RCM

The RCM was initially designed to provide additional interface signals for bothIEM modules and the TIM module.

The RCM provides the following features:

interface for up to:

• 21 PCM E1 links

• 28 PCM T1 links

matched impedance for 120Ω or 75Ω± 10%between tip and ringoptimal for thePCM E1 links

matched impedance for 100Ω ± 10% between tip and ring optimal for the PCMT1 links

interface for additional status/control signals among LSA--RC module(IEM/TIM/IEM)

interface for existing signals with matched impedance of 60 Ω ± 10%

connection to Synchronization slots on the backplane of the Interface Node

RCM slot identification for the IEM modules

6.4.2.1 Components layout

Figure 6--13 shows each main link inside the RCM.

TheRCMprovides inter--connection for signals amongboth IEMmodules, theTIMmodule and the backplane. Signal connections between both IEMmodules and thebackplane contain:

S--link redundancy

synchronization

MTM bus

Signals between the both IEM modules and the TIM modules contain:

PCM (E1/T1) differential pairs

LED control


PE/DCL/DD/0126411--9001--126


RCM

To/fromCEMmodule

PCM(E1/T1)from/to

SAI

IEM module

TIM module

IEM module

PCMlinks

PCMlinks

PCMlinks

S--links

S--links

Bakcplane

Refer toFigure 6--15



Figure 6--13 RCM: components layout



6.4.3 TIM module

The TIM module (see Figure 6--10) provides access to the line signals from theIEM modules. Without rear access on the Interface Node, all external interfacesmust be located on the front of the circuit packs. The TIMmodule is used for PCMT1 links with compensation for impedance mismatch located in the CTMx boardhoused inside the SAI frame.

The TIM module provides the following functions:

interface for up to 28 PCM T1 links

interface for up to 21 PCM E1 links

matched impedance between tip and ring (optimal for the same for PCM(E1/T1)):

• for PCM E1 120 Ω ± 10%

• for PCM E1 75 Ω ± 10%

• for PCM T1 100 Ω ± 10%

version and presence info to the IEM modules

EMI filtering for all signals dedicated to/from the SAI frame

does not receive the -- 48 Vdc and therefore does not generate power on the TIMmodule

6.4.3.1 External interfaces

The external interfaces of the TIM module are described below:

on the front panel:

• two visual indicators (LEDs) which are controlled by the IEM module

• PCM (E1/T1) RX signals to the SAI frame

• PCM (E1/T1) TX signals to the SAI frame

on the backplane:

• PCM (E1/T1) links redundancy

6.4.3.2 Connector description

The TIM module is connected to the RCM backplane. In addition, it is connectedfrom both 62--pin connectors located on the front panel of the TIMmodule to both62--pin connectors on the located on the CTB inside the SAI assembly.

Figure 6--15 shows the description of one of these 62--pin connectors on the frontpanel of the TIM module.


PE/DCL/DD/0126411--9001--126


RCM

Frontpanel

LEDs

TIM module

Backplane

62--pinHDDsub

Note: Indicates that PCM links are directly connected to the IEM module.

62--pinHDDsub

Rx signals

Tx signals

1

1

EMIfilters

LED control

To/fromIEMmodules

Figure 6--14 TIM module layout



6.4.3.3 Functional Blocks

Figure 6--14 shows each main functional block which are housed inside a TIMmodule.

The TIMmodule basically provides a common interface to the line signals for bothIEM modules. It contains EMI filters for these line signals, provides version andpresence info to the IEM modules, and houses two LEDs which are controlled bythe IEM modules.

Cable detection circuitry

There are two signals in the cable detection circuit which are controlledby both IEMmodules. The TIM module simply carries these signals from the RCM backplaneto the cable interface on the front of the card. One signal (CTB_LOOPA) isconnected to the transmit cable, while the other signal (CTB_LOOPB) is connectedto the receive cable.

EMI Filtering

EMI filtering is provided for each PCM (E1/T1) link on the cable interfaces of theTIM module. This filtering is required since high--frequency noise can be coupledonto these signals on the IEM module and carried out of the IEM module canthrough the cable interface. Two 62--pin connectors (see Figure 6--15) are beingbuilt for this purpose.

Board Stack--up

Solder mask is required for this board since the 62--pin connectors are soldered tothe module (see Figure 6--15). Each signal layer is isolated from its neighboringsignal layer with a ground layer for signal integrity. The receive line signals aretracked on separate layers from the transmit line signals in order to provide isolationfor signal integrity.


PE/DCL/DD/0126411--9001--126


21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

2223242526272829303233343536373839 314042 41

6162 60 43444547484950515253545556575859 46

Note: The number in brackets indicates the number of the PCM (E1/T1) pin.(P3): Transmit PCM (E1/T1) links.(P4): Receive PCM (E1/T1) links.

(00) (03) (06) (09) (12) (15) (18) (21) (24) (27)

(P4)loop B

(02) (05) (08) (11) (14) (17) (20) (23) (26)

(01) (04) (07) (10) (13) (16) (19) (22) (25)

Ring

TipRing

(P3)loop A

GND

Figure 6--15 TIM module: 62--pin connector on



6.5 SIM module


6.6 FiIler module


Transcoder node descriptionNortel Networks Confidential 7--1


7 TRANSCODER NODE DESCRIPTION

The TCU e3 houses two Transcoder Nodes.

Each of them performs the following functions (see Figure 7--1):

provides network connectivity with:

• the BSC e3 via the Ater interface

• the MSC via the A interface

converts the LAPD channels in DS0 links

transports the SS7 signalling links via the DS0 links

allows the communication between the Transcoder Node and the Control Nodevia the LAPD channels over DS0 links and via the Interface Node

manages the GSM vocoding of the speech/data channels

TCU e3 FRAME

TRANSCODER NODE

LSA--RC3

LSA--RC2

LSA--RC1

LSA--RC0

CEM(active/passive)

CEM(active/passive)

ICM


Ethernet linkto TML

Ethernet linkto TML

6 6 6 6 6 6 6 6

TRMTRM

3 3 3 3

8



To/from SAIframe

TRM TRM

Up to 12+2

TRM modules

3 33 3

Figure 7--1 TCU e3 (Transcoder Node): physical architecture

Transcoder node description Nortel Networks Confidential7--2

PE/DCL/DD/0126411--9001--126


The Transcoder Node hardware architecture for the TCU e3 is based on the generalSpectrum platform with the following features:

high speed telecom interfaces

twenty--eight general purpose slots for application and interface modules

two slots reserved for both SIMmoduleswhich provide to each other module the-- 48 Vdc and the alarm links

Note: The system does not support hot extraction of an active Transcoder NodeCEM. The system does, however, support hot extraction when the CEM ispassive. To ensure that the CEM is passive before performing a hotextraction, see “Replacement of a CEM” in the BSC/TCU e3MaintenanceManual (411--9001--132).

The fault tolerant architecture is based on duplicated CEM modules. One CEMmodule is active (i.e. actually performing call processing functions) while the otheris inactive, ready to take over if the active unit fails.

Both CEM modules:

receive identical PCM (E1/T1) traffic from each resource

can communicate with each other via the IMC (Inter Module Communication)links, in order to synchronize:

• call processing

• maintenance states

Each RM (TRM and LSA--RC modules) is connected to the CEMmodules via theS--Link interfaces. This results in a point--to--point architecture, which (whencompared to bus architectures) provides:

superior fault containment and isolation properties

fewer signal integrity related problems

easier backplane signal routing

In addition to the speech data channel, the S--Link interfaces transport messagingchannels, overhead control and status bits between theCEMmodules and eachRM.Each S--Link provides 256 DS0.

Each slot for each:

TRMmodule has access to 3 S--Links, or 768DS0channels to eachCEMmodule



IEMmodule located inside the LSA--RCmodule has access to 3 S--Links, or 768DS0 channels to each CEM module


PE/DCL/DD/0126411--9001--126


7.1 CEM module

For a description of the CEM module, refer to paragraph 6.1.

7.2 TRM module

TheTRMmodule (see Figure 7--2) manages theGSMvocoding of the speech/datachannels.

CAUTION: HOT EXTRACTION OF A TRM BOARD IN THE TCUCAUSES THE CALLS PASSING THROUGH IT TO BE DROPPED.

The speech channels can process the CTM (cellular text telephone modem) fortransmission of a text telephone conversation.

This task is accomplished by an array of DSPs (Digital Signal Processor). Theflexibility and computational power of the TRM module allow it to run any of theGSM coding/decoding processes (full rate (FR), enhanced full rate (EFR), andadaptive multi--rate (AMR) FR or HR) on multiple traffic channels.

The number of TRM module required depends on the operator capacityrequirements.

The Transcoder Node houses up to twelve TRM modules.


The external interfaces of each TRM module are described below:

on the front panel:


on the backplane:

• S--links redundant

• -- 48 Vdc links redundant

• MTM bus


Each TRM module:


houses:







PE/DCL/DD/0126411--9001--126


TRM

Visualindicators

Figure 7--2 TRM module: hardware overview




Figure 7--3 shows each of the main functional blocks, which are housed inside aTRM module.

7.2.3.1 ITM block

The ITM block interfaces the MTM bus between the ATM--RM module and theother RMs. These functions can be also controlled and accessed by the CPU.

7.2.3.2 CPU

The CPU block is responsible for terminating SPM systemmessaging coming fromthe CEM module, and for configuring, loading and detecting faults on the DSPArchipelagoes.

7.2.3.3 S--Link block

The S--link functional block is used to interface to the three serial links (S--links)coming from the CEM module. These links carry speech/data, messaging andcontrol functions between the TRM module and both CEM modules.

Each speech/data channel is converted to 8 bits parallel format and carried on thePCM internal links to/from the DSP archipelagoes.

7.2.3.4 DSP Archipelago blocks

The DSP resources are grouped into three similar Archipelagoes.

Each Archipelago interfaces with the S--link block on the PCM parallel link usingthe DIA (DSP Interface Asic).

The DIA is able to read and to write up to 256 TSs on the S--link. The TS list toprocess is specified by the CPU.

TheMLB (MailboxDSP) is also connected as a slave to the CPU block. It managesboth the parallel voice transfers between theDIA and its three PPUs (Pre ProcessingUnit), and the parallel messaging transfers between the CPU block and its PPUs.

The PPU is connected as a slave to theMLB, and as themaster to four identical SPU(Signal Processing Units).

The PPU conveys messaging between the MLB and the four SPUs, and typicallymanages pre and post--processing on the voice transfers (frame synchronization,parameters formatting, handover handling, etc.)

The SPU manages pure vocoding, on request from the PPUs.

The DSPs have the same design, running at least 150 Mips with a 128k--word(24--bits) internal memory that enables no external RAM. They are connectedglueless together using their parallel CPU port and their serial busses configured inmultiprocessor mode.


PE/DCL/DD/0126411--9001--126


Frontpanel

LEDs

TRM module

Reset ITMblock

CPU

dc/dcconverter

Backplane

--48 V dc

MTM bus

S--link(Tx)

S--link(Rx)

Archipelago 3

S--linkinterface

Archipelago 2

Archipelago 1

SPU--DSP block

PPU--DSP block

MLB

DIA

CTM

Figure 7--3 TRM module: functional blocks



CAUTION: HOT EXTRACTION OF A TRM BOARD IN THE TCUCAUSES THE CALLS PASSING THROUGH IT TO BE DROPPED.

The CTM allows reliable transmission of a text telephone conversation alternatingwith a speech conversation through the existing speech communication paths.

If the PCM type is T1, the CTM process is initialized upon all the TRM module ofthe TCU e3 and the CTM is systematically activated on all the communicationswhatever the channel type required from the interface A messages.

7.3 LSA--RC module

For a functional description of the LSA--RC module, refer to paragraph 6.4.

The LSA--RC module occupies three slots on the Transcoder Node shelf andconsists of the following modules:

a duplicated pair of IEM modules

a single TIM module

an RCM

For a description of the IEM and theTIMmodules, and theRCM, refer respectivelyto paragraph 6.4.1, paragraph 6.4.3 and paragraph 6.4.2.

7.4 SIM module


7.5 FiIler module



PE/DCL/DD/0126411--9001--126



Software DescriptionNortel Networks Confidential 8--1


8 SOFTWARE DESCRIPTION

8.1 Software architecture

The software part (see Figure 8--1, Figure 8--2, and Figure 8--3) of the BSC e3cabinet and the TCU e3 cabinet, as described in the functional architecture (referto Chapter 4), is subdivided into the following areas:

the OAM application

This application manages:

• the platform in accordancewith requests provided by the OAMcenter and theupdated platform

• the global behavior of the platform

the CallP application

This application manages the network elements and signaling.

It can perform call processing itself and supervision of network elements, but itcan also be a transactional application

8.2 Layered architecture presentation

In the following paragraph, we describe the high--level software architecturepresented as a layered model for the BSC e3 cabinet and the TCU e3 cabinet.

Basically, we find the hardware layer, the hardware abstraction layer, the core layer(also called BaseOS), the common layer (also called Platform layer) and theapplication & services layer.

The Hardware Abstraction Layer is responsible for making the upper layersindependentwith respect to the hardware. It is composed of aBase Support Package(BSP), the OS Kernel and the drivers required to manage the hardware.

TheCore layer is composed of the standard and off--the--shelf software running onthe operating system.

The Common layer is responsible for the management of the platform (physicallinks, fault tolerance, etc.).

The Application and Services layer is a set of functional entities providing theBSC e3 and TCU e3 services as GSM Network components.

Software Description Nortel Networks Confidential8--2

PE/DCL/DD/0126411--9001--126


Application and services layer

TMG Abis Access Ater Access

SPR OBS/OBR

Platform layer

OAM LAPD LAPD access

OMC services C--Node_OAM SS7

SUP--IN

Core layer

Base OS and OS

Hardware abstraction layer

SUP--TCU SPP

PCU Access

Figure 8--1 Position of the core system in the layered Control Node softwarearchitecture




Node Access

Pool PCM Pool 8K

CallP_IN

Plate form layer

Standalone API

Core layer

Base OS and OS


OAM System tests

BASE plate form

Device Manager (DM)

Node Maintenance (NM)

Connection Manager (CM)

Message Transfer System (MTS)

Data Synchronization (DS) Resource Manager (RMAN)

Integrated Link Maintenance (ILM)

Figure 8--2 Position of the core system in the layered Interface Node softwarearchitecture


PE/DCL/DD/0126411--9001--126



Node Access

Pool PCM Pool HDLC

CallP_TN

Platform layer

Standalone API

Core layer

Base OS and OS


OAM System tests

BASE platform

Device Manager (DM)

Node Maintenance (NM)

Connection Manager (CM)

Message Transfer System (MTS)

Data Synchronization (DS) Resource Manager (RMAN)

Integrated Link Maintenance (ILM)

Figure 8--3 Position of the core system in the layered Transcoder Node softwarearchitecture



8.3 Customer software package deliveries

8.3.1 Control Node

The table overleaf presents the control software packages and their description.

Note: A software package for the Control Node corresponds to the softwaredelivery which is supplied to the customer on a delivery medium.

Software packages Description

Pre--installed packages (OMU):-- (P) cn.aix.blvm Shared mirorred disk management-- (P) cn.aix.custom Dynamic OS configuration-- (P) cn.aix.pckg Package management-- cn.containers.omu Containers-- cn.installTml.omu Install the TML package on the OMU module

ATM packages (OMU):-- (P) cn.atmOmuSel.omu (OMU) ATM selection for switch activities-- (S) cn.cc1.sbc.load (CC1) Load the nominal image of the CC1 board-- cn.omu.tm.flash.alt (OMU) Flash the alternate image of the OMU--TM board-- cn.omu.tm.flash.fact (OMU) Flash the factory image of the OMU--TM board-- cn.omu.tm.flash.norm (OMU) Flash the nominal image of the OMU--TM board-- cn.omu.tm.load (OMU) Load the nominal image of the OMU--TM board-- cn.tmu.tm.flash.alt (TMU) Flash the alternate image of the TMU--TM board-- cn.tmu.tm.flash.fact (TMU) Flash the factory image of the TMU--TM board-- cn.tmu.tm.flash.norm (TMU) Flash the nominal image of the TMU--TM board-- cn.tmu.tm.load (TMU) Load the nominal image of the TMU--TM board

Common constant and definitions (OMU):-- (P) cn.common.omu Constants and definition for Control Node archi-

tecture-- (P) cn.commonplatform.omu Constants and definition for platform architecture

Base OS (OMU):-- (P) cn.bos.omu.base Base OS for the OMUmodule on the Control Node-- cn.bos.omu.oam.labo Management labo services on the Base OS for

the OAM-- (P) cn.bos.omu.tools

-- cn.obs_bos.omu

Management tools on the Base OS for the OMUmodule (initialization process, start process, etc.)Observation on the Base OS for the OMUmodule


PE/DCL/DD/0126411--9001--126



Messaging (OMU):-- (P) cn.msg.omu Messaging management

FT / LB (OMU):-- cn.fm.omu Fault management-- cn.ftla.omu Fault tolerance local agent-- cn.ftlb.omu Tolerance central agent and Load Balancing

management-- (P) cn.ftlib.omu Fault tolerance management-- cn.fttools.omu Fault tolerance tools

OV (OMU):-- cn.ov.omu Overload management

SM (OMU):-- cn.sm.omu Software management-- cn.smConfig.omu Software configuration files for the GSM-- cn.smTools.omu Software management tools

SWB (OMU):-- cn.swb.omu Software bus management-- cn.swbTools.omu Software bus tools

T&D (OMU):-- cn.tstdiag.omu Test and Diagnostic management

OAM access (AOMC):-- (P) cn.osiam.omu Pile OSIAM/FTAM-- (P) cn.ape.omu Messaging system access

OMU access and supervision of the othernodes:-- (P) cn.inac.omu IN--Access management-- (P) cn.supin.omu SUP--IN management-- cn.version Control Node Version




Data base access (OMU):-- (P) cn.das.omu Data base access process, located on the pri-

vate disk, to give access to the data base, thelibraries and to the associated UNIX commands

-- (S) cn.das.omu.share Data base access process, located on theshared disk, to give access to the data base, thelibraries and to the associated UNIX commands

CM (OMU):-- (P) cn.cmca.omu CM CA process, located on the private disk, to

manage the MIB with ADM for the object modelmediation

-- (S) cn.cmca_hybrid.omu CM CA hybrid process, located on the shareddisk, to centralize the observation data which aresent to the OMC--R

-- (P) cn.cmla.omu CM LA process to give access to the dataconfiguration

PM (OMU):-- (P) cn.pmca.omu PM_CA process, located on the private disk, to

centralize the observation data which are sent tothe OMC--R

File Remote Access Service:-- (P) cn.fas.omu File access management

Service libraries (OMU):-- cn.adm.omu Shared libraries-- cn.apptemplateLib.omu Application template library-- cn.communicationLib.omu Communication library-- cn.debugLib.omu Debug library-- cn.errorLib.omu Error library-- cn.parserLib.omu Parser library-- cn.prngLib.omu PRNG library-- cn.sharedmemLib.omu Shared memory library-- (P) cn.sst.omu Single stream software to interface the software

and the platform-- cn.synchronizationLib.omu Synchronization library-- cn.threadLib.omu Thread library-- cn.timeLib.omu Time library-- cn.timerLib.omu Timer library


PE/DCL/DD/0126411--9001--126



OAM (OMU):-- (P) cn.actmngt.omu Activity Management-- cn.oamCa.omu OAM CA process-- (P) cn.oamcn.omu SUP--CN management-- cn.oamHm.omu OAM hardware management-- cn.oamLib.omu OMC services-- (S) cn.oam.omu.share OAM libraries and basic processes, located on

the shared disk-- (P) cn.upgradeCn.omu Upgrade package-- cn.upgradeServices.omu Upgrade services management-- cn.upgradelmt.omu Upgrade LMT package

Basic platform software(TMU--PMC and TMU--SBC):-- cn.tmu.pmc.flash.alt.H01 Alternate software of the flash memory on the

TMU--PMC-- cn.tmu.pmc.flash.fact.H01 Factory software of the flash memory on the

TMU--PMC-- (P) cn.tmu.pmc.flash.norm.H01 Software of the flash memory on the TMU--PMC-- (P) cn.tmu.pmc.load.H01 Download software of the TMU--PMC-- cn.tmu.sbc.flash.alt.H1 Alternate software of the flash memory on the

the TMU--SBC-- cn.tmu.sbc.flash.fact.H1 Factory software of the flash memory on the

TMU--SBC-- cn.tmu.sbc.flash.norm.H1 Software of the flash memory on the TMU--SBC

Base OS (TMU):-- cn.bos.tmu.sbc.load.H1 Stand--alone management on the base OS of the

TMU--SBC

Call Processing:-- gsm.obr.omu Observation functional unit for the OMU module

DTM (OMU):-- gsm.dtm.omu Download token manager

STC (OMU):-- gsm.stc.omu STC management




Monolithic load for the GSM (TMU--SBC):-- (P) gsm.tmu.sbc.load.H1A Download software of the TMU--SBC (contains:

TMG, SPR, platform)

MIB for the GSM:-- (P) gsm.mib Database (MIB)

OMU for the GSM:-- (P) gsm.omu.share OMU process

Note: (P): indicates the software package on the private disk(S): indicates the software package on the shared disk

Table 8--1 Presentation and description of the software packages inside the ControlNode


PE/DCL/DD/0126411--9001--126


8.3.2 Interface Node

For the Interface Node, each customer software contains a monolothic load on asoftware package which is split up as follows:

Load_CEM_IN

Load_ATM--RM_IN

Load_IEM_IN

Load_SRT_IN (for the 8K--RM also named SRT--RM)

Note: A software package for the Interface Node corresponds to the softwaredelivery which is supplied to the customer on a delivery medium.

8.3.3 Transcoder Node

For the Transcoder Node, each customer software contain a monolothic load on asoftware package which is split up as follows:

Load_CEM_TCUe3

Load_IEM_TCUe3

Load_TRM_TCUe3

Note: A software package for the Transcoder Node corresponds to the softwaredelivery which is supplied to the customer on a delivery medium.

DimensioningNortel Networks Confidential 9--1


9 DIMENSIONINGFor information on the dimensioningwithBSCe3 cabinet andTCU e3 cabinet referto NTP < 138 >.

Dimensioning Nortel Networks Confidential9--2

PE/DCL/DD/0126411--9001--126



Wireless Service Provider SolutionsBSC/TCU e3 Reference Manual

Copyright 2000--2004 Nortel Networks, All Rights Reserved

NORTEL NETWORKS CONFIDENTIAL:

The information contained in this document is the property of NortelNetworks. Except as specifically authorized in writing by NortelNetworks, the holder of this document shall keep the informationcontained herein confidential and shall protect same in whole or in partfrom disclosure and dissemination to third parties and use for evaluation,operation and maintenance purposes only.

You may not reproduce, represent, or download through any means, theinformation contained herein in any way or in any form without priorwritten consent of Nortel Networks.

The following are trademarks of Nortel Networks: *NORTELNETWORKS, the NORTEL NETWORKS corporate logo, the NORTELGlobemark. GSM is a trademark of France Telecom.All other brand and product names are trademarks or registeredtrademarks of their respective holders.

Publication ReferencePE/DCL/DD/0126 411--9001--12614.10/ENJuly 2004Originated in France

For more information, please contact:

For all countries, except USA:

Documentation DepartmentParc d’activité de Magny--ChateaufortCHATEAUFORT78928 YVELINES CEDEX 9FRANCEEmail : [email protected] : (33) (1) 39--44--50--29

In the USA:

2221 Lakeside BoulevardRichardson TX 75082USATel: 1--800--4 NORTEL1--800--466--7838 or (972) 684--5935

Internet Address:

http://www.nortelnetworks.com

Date post:	13-Apr-2015
Category:	Documents
Upload:	mgabio
View:	120 times
Download:	3 times

411 9001 126.14.10_BSC TCU e3 Reference Manual

Documents