Hardware Configuration Management

ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11

04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 1/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Site

VELIZY

GSM/WiMAX Business Division

Originators

S.MAINTROT

Hardware Configuration Management BSC, TC and ATER part

Release B11

System : ALCATEL-LUCENT GSM BSS Sub-system : SYS-TLA Document Category : PRODUCT DEFINITION

EXECUTIVE SUMMARY This document presents the specification of the Hardware Configuration Management functional block for BSC, TC and ATER part. This is a step 2 document of B11.

Approvals Name App.

Y. GORJUX DPM OSY

WU ANMIN DPM BSC

L.F. MUNTEAN DPM O&M

Name App.

A. COZMA DPM TC

DPM OMC

DPM BTS

REVIEW Ed. 01 Proposal 01 <08/03/25> Wireless/GSM/TD/OSY/SMA/208085 Ed. 01 Proposal 02 Ed. 01 Proposal 03

<08/04/18> <08/05/09>

Wireless/GSM/TD/OSY/SMA/208100 Wireless/GSM/TD/OSY/SMA/208107

HISTORY


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 2/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Ed.01 Proposal 01 07/11/23 Creation from B10 HCM 3BK 11204 0396 DSZZA Ed.2 Proposal 02 taking into account the B10 AMR-WB (From the SFD Adaptative Multi-rate Wideband speech codec (3BK 10204 0095 DTZZA) Edition 1 P04)

And updated in accordance with: • The review report Wireless/GSM/TD/OSY/SMA/207280

from B10 HCM 3BK 11204 0396 DSZZA Ed.2 Proposal 02

• The SFD Adaptative Multi-rate Wideband speech codec (3BK 10204 0095 DTZZA) Edition 1 RL

• The B11 SFD “A signalling over IP” And Addition of • B10 CR A20/219304: Impact of RFD206888-MX BSC

reduction to complete with Activation new configuration only BTS grouping is added

• B10 CR A20/219166: Replacement of HW-Resynch by TC-HW-Resynch (impact of AMR-WB SFD)

• B10 CR A20/220452 (Deferred from B9 A20/216511): HCM Atermux carrying Qmux, X25 or IP could not be set as dedicated (depends on 220453)

And additional Editorial correction • About support traffic of up 4500 erlangs with TPGSM

V3 for release B10 • All references to TPGSM V2 are removed. • § MT120 Adding/removal: adding the launching of

“Activate a new BSC/TC standard configuration” for better understanding

• During new MX BSC /TC standard configuration scenario, the “Prog-trans-Ater” is triggered by operator in TDM and IP mode (Mail Yves Gorjux subject FR3BKA36FBR225287 - 29/11/2007)

• Mail from Yves Gorjux - 29/11/2007 editorial correction in § 4.2.11.3 Set-up (respectively removal) of a dedicated GPRS Atermux Scenario and § 4.2.11.4 Modify a mixed Atermux into a dedicated GPRS Atermux scenario to take into account “there is no add/remove GSL in IP mode” and “M-Config-Sig-Atermux is sent only in TDM mode.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 3/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Ed.01 Proposal 02 Updated with the remarks from the review report Wireless/GSM/TD/OSY/SMA/208085 of the Ed1 proposal 1

And updated in accordance with B11 feature: • “Semi-permanent path in BSC Evolution” feature • “STM1 on BSC” feature And with the addition of: • B10 CR A20/228160: HCM B10 impact: Mx BSC shall

only use CS Atermux for clock synchro • B10 CR A20/231200: HCM B10 Impact of the CR

A20/216099: SFD Mx Capacity: TS15 & TS16 can be used for traffic and CR A20/222572: SFD Mx Capacity: 120 CIC on Legacy MT120 => when in HSL, TS16 cannot be used for traffic and CR A20/227262: SFD Mx Capacity: Atermux 59 and 60 could be used for HSL or packet

• B11 CR A20/217722: B11 STM1 BSC: Clarifications after BSC DN writing

And with: • The modification of the O&M action “discover a BSS”

new organisation for the audits and creation of an OMC use case HW/SW overall Audit

• The removing of the O&M Action “MSC Management”, the Create/delete/modify MSC scenario, the OMC use case create/delete/modify MSC and the BSC use case create/delete/modify MSC. All these O&M action, scenarios and uses cases are included in document LCM ref [A5]

Ed.01 Proposal 03 08/04/07 Updated with the remarks from the review report

Wireless/GSM/TD/OSY/SMA/208100 of the Ed1 proposal 2

And impact of • Memo Evolution to support Gb over IP dynamic

configuration in paragraph 5.1.1.26 BSS Transport Mode Switch case from TDM to IP

• Mail from L. Gabor B10 the 12th February 2008 “restriction on TCIF multi-OMC” impact in paragraph 5.1.1.20 OMC use case “TC Declaration” (Passphrases management)

And with the addition of: • B11 CR A20/222330: SFD STM1 impact on TC: Lack of

genericity between TC and BSC for STM1


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 4/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Ed.01 Released 08/05/09 Updated with the remark from the review report Wireless/GSM/TD/OSY/SMA/208107 of the Ed1 proposal 3

And editorial update • In § 2.2.3 BSC extension/reduction and 5.2.1.1 Activate

new BSC/TC standard configuration precision about BTS grouping

And updated with • In § 5.2.1.9 BSC-TC audit adding case: No answer of a

TC and incoherence “double declared MT120”, an event is raised in OMC.

• Appendix A2 and A3 are removed from HCM. The BSC/TC STM1 Configuration file format and the Alcatel default TC STM-1 configuration file are described in the document [A29] Transmission Terminations Points Configuration Export or Import file.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 5/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

TABLE OF CONTENTS TABLE OF CONTENTS......................................................................................................................... 5 INTERNAL REFERENCED DOCUMENTS......................................................................................... 10 REFERENCED DOCUMENTS ............................................................................................................ 10 RELATED DOCUMENTS .................................................................................................................... 10 PREFACE ............................................................................................................................................ 11 1 INTRODUCTION............................................................................................................................. 12

1.1 Scope .......................................................................................................................... 12 1.2 Methodology Overview ............................................................................................. 12 1.3 Document Structure .................................................................................................. 13

2 GENERAL PRINCIPLES ................................................................................................................ 14 2.1 Scope and Basic Principles...................................................................................... 14 2.2 Hardware configuration management Principles .................................................. 14

2.2.1 MX BSC configuration................................................................................................... 14 2.2.2 TC configuration............................................................................................................ 18 2.2.3 BSC extension/reduction............................................................................................... 19 2.2.4 Definition of initial build ................................................................................................. 21 2.2.4.1 Minimum configuration of a G2 BSC based BSS ........................................................ 21 2.2.4.2 Minimum configuration of a Mx BSC based BSS - TDM BSS transport mode ........... 21 2.2.4.3 Minimum configuration of a Mx BSC based BSS - IP BSS transport mode................ 22

2.2.5 STM1............................................................................................................................. 23 2.2.5.1 STM1 in TC G2.5 with TCIF (also named TC IP)........................................................ 23 2.2.5.2 STM1 in MX BSC......................................................................................................... 25

2.2.6 HSL support .................................................................................................................. 26 2.2.7 AMR_WB and TFO support .......................................................................................... 28 2.2.7.1 Overview...................................................................................................................... 28 2.2.7.2 O&M aspects ............................................................................................................... 29

2.2.8 A Signalling Over IP ...................................................................................................... 31 2.2.8.1 Overview...................................................................................................................... 31 2.2.8.2 O&M aspect ................................................................................................................. 33

2.2.9 A Channel Configuration ............................................................................................... 34 2.2.9.1 A Channel Configuration except TS 15 and TS 16 ..................................................... 34 2.2.9.2 TS15 and TS16 Configuration for traffic usage ........................................................... 34

2.3 Management of exclusion......................................................................................... 36 2.4 OMC “Post-it” Feature .............................................................................................. 37

3 OVERALL DESCRIPTION ............................................................................................................. 38 3.1 List of Actors.............................................................................................................. 38 3.2 List of Services .......................................................................................................... 38 3.3 Services/Subsystems Mapping................................................................................ 39

3.3.1 Services/Subsystems Mapping OMC-R, BSC Terminal, BSC, BTS............................. 39 3.3.2 Services/Subsystems Mapping OMC-R, TC-NEM, BSC, TC ....................................... 40

4 SUBSYSTEMS INTERACTIONS ................................................................................................... 42 4.1 Service S-HCM-ModifyHWConfig............................................................................. 42

4.1.1 O&M Action «Configure G2 BSC/TC » ......................................................................... 43 4.1.1.1 Activate new G2 BSC/TC standard configuration Scenario ........................................ 43

4.1.2 O&M Action «Configure MX BSC/TC »......................................................................... 45 4.1.2.1 Activate new MX BSC/TC standard configuration Scenario ....................................... 45 4.1.2.2 TC Discovery Phase Sub-scenario.............................................................................. 47

4.1.3 O&M Action «Discover a BSS»..................................................................................... 50 4.1.3.1 Discover a BSS Scenario ............................................................................................ 50

4.1.4 O&M Action «TC Management» ................................................................................... 56 4.1.4.1 TC declaration scenario............................................................................................... 56


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 6/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.4.2 TC removal scenario.................................................................................................... 57 4.1.4.3 Display TC data scenario ............................................................................................ 57 4.1.4.4 Update TC Information scenario.................................................................................. 58

4.1.5 O&M action «TC Supervision»...................................................................................... 59 4.1.5.1 Move TC supervision to another BSSIM scenario....................................................... 59 4.1.5.2 Update TC supervision scenario ................................................................................. 59

4.1.6 &M Action «TCSL endpoints resynchronisation» ......................................................... 60 4.1.6.1 Resynchronisation triggered with OMC scope scenario ............................................. 60 4.1.6.2 BSC-TC Audit Sub-scenario........................................................................................ 63

4.1.7 O&M Action « MT 120 Adding/Removal » .................................................................... 66 4.1.7.1 Activate new G2.5 TC standard configuration............................................................. 66 4.1.7.2 Activate new G2.5 TC with TCIF standard configuration ............................................ 66

4.1.8 O&M Action «BSC/GPU IP association» ...................................................................... 68 4.1.8.1 BSC/GPU IP association Sub-scenario....................................................................... 68

4.1.9 O&M Action «Change BSS Transport Mode on BSC side» ......................................... 69 4.1.9.1 Change BSS Transport Mode from TDM to IP on BSC side scenario ........................ 69 4.1.9.2 Change BSS Transport Mode from IP to TDM on BSC side scenario ........................ 72

4.1.10 O&M Action «STM1 interfaces (BSC/TC) Declaration/Undeclaration» ........................ 74 4.1.10.1 STM1 interfaces (BSC/TC) declaration/undeclaration scenario ......................... 74

4.1.11 O&M Action « BSC/TC Plug identification information » .............................................. 77 4.1.11.1 TC Plug identification information display scenario............................................. 77 4.1.11.2 BSC Plug identification information display scenario.......................................... 78

4.1.12 O&M Action « Change N°7 Mode from LSL to HSL or HSL to LSL»............................ 79 4.1.12.1 Change N°7 Mode from LSL to HSL or from HSL to LSL scenario .................... 80

4.1.13 O&M Action « Modify BSC SS7 Transport Mode »....................................................... 81 4.1.13.1 Modify BSC SS7 Transport Mode scenario ........................................................ 81

4.2 Service S-HCM-PCMConfig ...................................................................................... 82 4.2.1 O&M Action «AterMux configuration for GPRS» .......................................................... 82 4.2.1.1 Modify GPRS granularity Scenario.............................................................................. 86 4.2.1.2 Modify a dedicated GPRS AterMux into a mixed CS/GPRS AterMux Scenario ......... 88 4.2.1.3 Set-up (respectively unset) of a dedicated GPRS AterMux Scenario ......................... 90 4.2.1.4 Modify a mixed AterMux into a dedicated GPRS AterMux Scenario .......................... 91

4.2.2 O&M Action «Configure Ater»....................................................................................... 92 4.2.2.1 Modify Ater connection type Scenario ......................................................................... 92 4.2.2.2 Change CRC4 Scenario .............................................................................................. 93 4.2.2.3 Half-rate Setting Scenario ........................................................................................... 94 4.2.2.4 Loudness Setting Scenario.......................................................................................... 95

4.2.3 O&M Action «TC STM1 Configuration Management »................................................. 96 4.2.3.1 Getting current TC STM1 configuration scenario ........................................................ 96 4.2.3.2 Getting candidate TC STM1 configuration scenario.................................................... 98 4.2.3.3 Getting properties for current or candidate TC STM1 configuration ......................... 100 4.2.3.4 Checking a TC STM1 configuration scenario............................................................ 101 4.2.3.5 Comparing two TC STM1 configurations scenario.................................................... 101 4.2.3.6 Downloading a candidate TC STM1 configuration scenario ..................................... 102 4.2.3.7 Applying a candidate TC STM1 configuaration file scenario..................................... 103 4.2.3.8 Display of TC’s section and path traces scenario ..................................................... 104 4.2.3.9 Modification of TC’s transmitted section and path traces scenario........................... 105

4.2.4 O&M Action «BSC STM1 Configuration Management » ............................................ 107 4.2.4.1 Getting current or candidate BSC STM1 configuration scenario .............................. 107 4.2.4.2 Getting current or candidate BSC STM1 configuration properties scenario ............. 108 4.2.4.3 Editing a BSC STM1 configuration scenario ............................................................. 109 4.2.4.4 Create a new BSC STM1 configuration scenario...................................................... 109 4.2.4.5 Checking a BSC STM1 configuration scenario ......................................................... 110 4.2.4.6 Comparing two BSC STM1 configurations scenario ................................................. 110 4.2.4.7 Setting a candidate BSC STM1 configuration scenario ............................................ 111 4.2.4.8 Applying a candidate BSC STM1 configuration scenario.......................................... 112 4.2.4.9 Get BSC’s LIU/STM1 resource scenario................................................................... 113 4.2.4.10 Display of BSC’s section and path traces scenario .......................................... 114 4.2.4.11 Modification of BSC’s transmitted section and path traces scenario ................ 115

4.3 Subscenario for Programming of Ater Transmissions........................................ 116 4.3.1 Program Ater Transmission subscenario.................................................................... 116


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 7/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5 DETAILED DESCRIPTION........................................................................................................... 117 5.1 OMC-R Description.................................................................................................. 117

5.1.1 Use Case Description ................................................................................................. 117 5.1.1.1 Use Case «Add a BSS» ............................................................................................ 117 5.1.1.2 Use Case «Delete a BSS» ........................................................................................ 118 5.1.1.3 Use Case «Modify BSS identification»...................................................................... 119 5.1.1.4 Use Case «Complete BSS audit» ............................................................................. 120 5.1.1.5 Use Case «OMC/BSC synchronisation»................................................................... 121 5.1.1.6 Use Case «OMC/BSS synchronisation» ................................................................... 123 5.1.1.7 Use Case « HW/SW Overall Audit » ......................................................................... 123 5.1.1.8 Use Case «Display Rack Layout»............................................................................. 124 5.1.1.9 Use Case "Display VCE" ........................................................................................... 124 5.1.1.10 Use Case «Display BSS topology»................................................................... 126 5.1.1.11 Use Case «Display of the LIU and BSC STM1 resource occupancy» ............. 127 5.1.1.12 Use Case «Modify GPRS granularity».............................................................. 128 5.1.1.13 Use Case «Modify dedicated GPRS AterMux into a mixed GPRS/CS AterMux»

130 5.1.1.14 Use Case «Set-up (respectively unset) of a dedicated AterMux» .................... 133 5.1.1.15 Use Case «Modify mixed AterMux into a dedicated GPRS AterMux».............. 136 5.1.1.16 Use Case «Modify Ater connection type» ......................................................... 139 5.1.1.17 Use Case «Change CRC4» .............................................................................. 140 5.1.1.18 Use Case «Change Half-rate» .......................................................................... 141 5.1.1.19 Use Case «Change loudness» ......................................................................... 142 5.1.1.20 Use Case «TC Declaration».............................................................................. 143 5.1.1.21 Use Case « TC Removal»................................................................................. 145 5.1.1.22 Use case «Display TC Data» ............................................................................ 146 5.1.1.23 Use case «Update TC Information».................................................................. 147 5.1.1.24 Use case «TCSL Resynchronisation» .............................................................. 148 5.1.1.25 Use Case « BSC/GPU IP Association» ............................................................ 150 5.1.1.26 Use Case « BSS Transport Mode Switch » ...................................................... 151 5.1.1.27 Use Case « Move TC supervision to another BSSIM» ..................................... 153 5.1.1.28 Use Case «Update TC supervision»............................................................... 154 5.1.1.29 Use Case «BSC/TC STM1 Declaration/Undeclaration» ................................... 155 5.1.1.30 Use Case «Modify BSC SS7 Transport Mode» ................................................ 157 5.1.1.31 Enable/Disable Optional features...................................................................... 159 5.1.1.32 Limitation of some features ............................................................................... 161

5.1.2 Dimensioning Data...................................................................................................... 162 5.1.3 Object Model ............................................................................................................... 162

5.2 BSC Description ...................................................................................................... 163 5.2.1 Use Case Description ................................................................................................. 163 5.2.1.1 Use Case «Activate new BSC/TC standard configuration» ...................................... 165 5.2.1.2 Use Case «BSC hardware audit».............................................................................. 171 5.2.1.3 Use Case «TC hardware audit» ................................................................................ 173 5.2.1.4 Use Case «Modify AterMux GPRS».......................................................................... 175 5.2.1.5 Use Case "Ater Signalling Configuration".................................................................. 179 5.2.1.6 Use Case «Configure Ater»....................................................................................... 180 5.2.1.7 Use Case «Program Ater Transmission».................................................................. 182 5.2.1.8 Use Case «Change N°7 Mode from LSL to HSL or from HSL to LSL» .................... 183 5.2.1.9 Use Case «BSC-TC Audit» ....................................................................................... 187 5.2.1.10 Use Case «Modify TC characteristics» ............................................................. 189 5.2.1.11 Use Case « Modify MFS Characteristics» ........................................................ 191 5.2.1.12 Use Case «BSS Transport Mode Switch» ........................................................ 192 5.2.1.13 Use Case «Modify BSC SS7 Transport Mode» ................................................ 195 5.2.1.14 Use Case «BSC STM1 interface activation» .................................................... 197 5.2.1.15 Use Case «Getting current or candidate BSC STM1 configuration»................ 198 5.2.1.16 Use Case «Getting current or candidate BSC STM1 configuration Properties»200 5.2.1.17 Use Case «Setting a candidate BSC STM1 configuration».............................. 202 5.2.1.18 Use Case «Applying a candidate BSC STM1 configuration» ........................... 204 5.2.1.19 Use Case «Display of BSC’s section and path traces» .................................... 206 5.2.1.20 Use Case «Modification of BSC’s transmitted section and path traces».......... 207


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 8/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.21 Use Case «BSC plug identification information» .............................................. 209 5.2.2 Dimensioning Data...................................................................................................... 210 5.2.3 Object Model ............................................................................................................... 210

5.3 BSC Terminal Description ...................................................................................... 211 5.3.1 Use case description................................................................................................... 211 5.3.1.1 Use Case « Getting current or candidate BSC STM1 configuration » ...................... 211 5.3.1.2 Use Case « Getting current or candidate BSC STM1 configuration properties»...... 213 5.3.1.3 Use Case « Editing a BSC STM1 configuration » ..................................................... 214 5.3.1.4 Use Case « Create a new BSC STM1 configuration » ............................................. 215 5.3.1.5 Use Case « Checking a BSC STM1 configuration »................................................. 216 5.3.1.6 Use Case « Comparing two BSC STM1 configurations »......................................... 218 5.3.1.7 Use Case « Setting a candidate BSC STM1 configuration » .................................... 219 5.3.1.8 Use Case « Applying a candidate BSC STM1 configuration » ................................. 220 5.3.1.9 Use Case « Get BSC’s LIU/STM1 resources »......................................................... 220 5.3.1.10 Use Case « Display of BSC’s section and path traces » .................................. 221 5.3.1.11 Use Case « Modification of BSC’s transmitted section and path traces »........ 222 5.3.1.12 Use Case « BSC Plug identification information display »................................ 224

5.4 TC-NEM Description................................................................................................ 225 5.4.1 Use case description................................................................................................... 225 5.4.1.1 Use Case « Getting current or candidate TC STM1 configuration »......................... 225 5.4.1.2 Use Case « Getting properties for current or candidate TC STM1 configuration » .. 228 5.4.1.3 Use Case « Checking a TC STM1 configuration ».................................................... 230 5.4.1.4 Use Case « Comparing two TC STM1 configurations » ........................................... 232 5.4.1.5 Use Case « Downloading a candidate TC STM1 configuration »............................. 233 5.4.1.6 Use Case « Applying a candidate TC STM1 configuration » .................................... 235 5.4.1.7 Use Case « Display of TC’s section and path traces » ............................................. 236 5.4.1.8 Use Case « Modification of TC’s transmitted section and path traces »................... 237 5.4.1.9 Use Case « TC Plug identification information display » .......................................... 238


5.5 Transcoder description........................................................................................... 240 5.5.1 Use case description................................................................................................... 240 5.5.1.1 Use Case « Activate new G2.5 TC standard configuration ».................................... 240 5.5.1.2 Use Case « Activate new TC G2.5 with TCIF standard configuration » ................... 241 5.5.1.3 Use Case « TC Declaration ».................................................................................... 243 5.5.1.4 Use Case « TC STM1 interface Declaration/Undeclaration».................................... 244 5.5.1.5 Use Case «Getting current or candidate TC STM1 configuration»........................... 245 5.5.1.6 Use Case «Getting properties for current or candidate TC STM1 configuration» .... 246 5.5.1.7 Use Case «Downloading a candidate TC STM1 configuration»............................... 248 5.5.1.8 Use Case «Apply a candidate TC STM1 configuration»........................................... 249 5.5.1.9 Use Case «Display of TC’s section and path traces » .............................................. 251 5.5.1.10 Use Case «Modification of TC’s transmitted section and path traces» ............ 252 5.5.1.11 Use Case «TC Plug identification information»................................................. 253 5.5.1.12 Use Case «TCSL Endpoints Update»............................................................... 254 5.5.1.13 Use Case «TC AUDIT» ..................................................................................... 255 5.5.1.14 Use Case «TC Configuration Update».............................................................. 257


6 GLOSSARY .................................................................................................................................. 258 APPENDIX A. STM1 TC ........................................................................................................... 260

A.1 TC STM1 Configuration........................................................................................... 260 A.2 Section and path trace management..................................................................... 262

APPENDIX B. INDEX OF MESSAGES .................................................................................... 265


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 9/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

TABLE OF FIGURES

1 Figure 1 “MT120 board and their capabilities” ...................................................................................... 29 Figure 2 “A signalling is transferred in pure TDM mode (SS7 LSL)” .................................................... 31 Figure 3: “A signalling in mixed mode (Ater in IP mode and A signalling in TDM mode)” .................... 32 Figure 4 “A signalling Over IP mode” .................................................................................................... 33 Figure 5: “Activate new G2 BSC/TC standard configuration” scenario ................................................ 44 Figure 6: “Activate new MX BSC/TC standard configuration” scenario................................................ 46 Figure 7 “TC Discovery phase” sub-scenario ....................................................................................... 48 Figure 8 “TC hardware audit” sub-scenario .......................................................................................... 49 Figure 9: “Discover a BSS” scenario..................................................................................................... 51 Figure 10: “Hardware audit” sub-scenario ............................................................................................ 52 Figure 11: "BSC hardware audit" sub-scenario .................................................................................... 54 Figure 12 “TC Declaration” scenario..................................................................................................... 56 Figure 13 “TC Removal” scenario ......................................................................................................... 57 Figure 14 “Display TC Data” scenario................................................................................................... 57 Figure 15 “Update TC Information” scenario ........................................................................................ 58 Figure 16 “Move TC supervision to another BSSIM” scenario ............................................................. 59 Figure 17 “Update TC supervision” scenario ........................................................................................ 59 Figure 18 “Resynchronisation triggered with OMC scope” scenario .................................................... 62 Figure 19 “BSC-TC Audit ” sub-scenario .............................................................................................. 65 Figure 20 “Activate new G2.5 TC standard configuration ” scenario.................................................... 66 Figure 21 “Activate new G2.5 TC with TCIF standard configuration ” scenario ................................... 67 Figure 22 “BSC/GPU IP association” scenario ..................................................................................... 68 Figure 23 “BSC/GPU IP association” sub-scenario .............................................................................. 69 Figure 24 “Change BSS Transport Mode from TDM to IP on BSC side” scenario............................... 71 Figure 25 “Change BSS Transport Mode from IP to TDM on BSC side” scenario............................... 73 Figure 26 “STM1 interfaces (BSC/TC) Declaration/Undeclaration” scenario ....................................... 76 Figure 27 “TC Plug identification Information display” scenario ........................................................... 77 Figure 28 “BSC Plug identification Information display” scenario......................................................... 78 Figure 29: “Change N°7 Mode from LSL to HSL or from HSL to LSL” Scenario.................................. 80 Figure 30: “Modify SS7 Transport Mode” scenario ............................................................................... 81 Figure 31: “Modify GPRS granularity” scenario .................................................................................... 87 Figure 32: “Modify a dedicated GPRS AterMux into a mixed AterMux” scenario................................. 89 Figure 33: “Set-up (respectively unset) of a dedicated GPRS AterMux” scenario ............................... 90 Figure 34: “Modify a mixed AterMux into a dedicated GPRS AterMux” scenario................................. 91 Figure 35: “Modify Ater connection type” scenario ............................................................................... 92 Figure 36: Change CRC4 scenario ....................................................................................................... 93 Figure 37: Change Half-rate scenario................................................................................................... 94 Figure 38: Loudness setting scenario ................................................................................................... 95 Figure 39: “Getting current TC STM1 configuration” scenario.............................................................. 97 Figure 40 “Getting candidate TC STM1 configuration” scenario .......................................................... 99 Figure 41 “Getting properties for current or candidate STM1 configuration” scenario ....................... 100 Figure 42: “Checking a TC STM1 configuration” scenario.................................................................. 101 Figure 43: “Comparing two TC STM1 configurations” scenario.......................................................... 101 Figure 44: “Downloading a candidate TC STM1 configuration” scenario ........................................... 102 Figure 45: “Apply a candidate TC STM1 configuration” scenario ....................................................... 103 Figure 46: “Display of section and path traces” scenario.................................................................... 104 Figure 47: “Modification of transmitted section and path traces” scenario ......................................... 105 Figure 48: “Getting current or candidate BSC STM1 configuration” scenario .................................... 107 Figure 49: “Getting current or candidate BSC STM1 configuration properties” scenario ................... 108 Figure 50: “Editing a BSC STM1 configuration” scenario ................................................................... 109 Figure 51: “Create a new BSC STM1 configuration” scenario............................................................ 109 Figure 52: “Checking a BSC STM1 configuration” scenario ............................................................... 110 Figure 53: “Comparing two BSC STM1 configurations” scenario ....................................................... 110 Figure 54: “Setting a candidate BSC STM1 configuration” scenario .................................................. 111 Figure 55: “Applying a candidate BSC STM1 configuration” scenario................................................ 112 Figure 56: “Get BSC ‘s LIU/STM1 Resources” scenario .................................................................... 113 Figure 57: “Display of BSC’s section and path traces” scenario......................................................... 114 Figure 58: “Modification of BSC’s transmitted section and path traces” scenario .............................. 115


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 10/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Figure 59: Program Ater Transmission sub scenario ......................................................................... 116

INTERNAL REFERENCED DOCUMENTS

REFERENCED DOCUMENTS [1] 3BK 10013 0001 DTZZA System and Subsystem Specification strategy [2] 8BL 14206 0002 PTZZA FBS Standard Plan [3] 8BL 14206 0004 BGZZA OMT Method Application Guide for SAS

[4] 3BK 11203 0036 DSZZA System Functional Specification B6 [7] 3BK 11204 0298 DSZZA Abis signalling links statistical submultiplexing [8] 3BK 11204 0418 DSZZA Abis signalling links multiplexing improvement for Micro

BTS and BTS G3 [9] 3BK 11203 0331 DSZZA (E)GPRS/LCS O&M Functional Architecture [10] 3BK 10029 0001 DSZZA Inventory file specification [11] 3BK 11204 0396 DSZZA Hardware Configuration Management B10 [12] 3BK 11204 0478 DSZZA BSS O&M Parameters B11 [13] 3BK 11204 0623 DTZZA SFD Remote Inventory MFS at OMC-R [14] TBD Remote Inventory Export Interface [15] 3BK 11256 0011 DSZZA MX PLATFORM : DFS Hardware Management [16] 3BK 10204 0022 DTZZA SFD BTS with up to 24 TRE [17] 3BK 17040 1003 DSZZA Remote Inventory Interface File Specification (Standard

CSV file interface) [18] 3BK 10204 0095 DSZZA SFD Adaptative Multi-Rate Wideband Speech Codec

GMSK (AMR-WB) [19] 3BK 10204 0049 DTZZA SFD B11 O&M Impact of IP Transport, Ater area [20] 3BK 10204 0096 DTZZA SFD B11 TFO for AMR-NB and AMR-WB [21] 3GPP TS 26.103 Speech codec list for GSM and UMTS [22] 3BK 11204 0466 DSZZA BSC Alarm Dictionary

RELATED DOCUMENTS [A1] 3BK 11204 0454 DSZZA TSC-NE Communication Protocols Specification

Release B11 [A2] 3BK 11204 0395 DSZZA FBS SWM: Software Maintenance B10 [A3] 3BK 11204 0458 DSZZA FBS NSR: Network Supervision (BSC, TC and ATER

part B11 [A4] 3BK 11204 0462 DSZZA FBS IMO: Initialisation and Maintenance (BSC, TC

and ATER part B11 [A5] 3BK 11204 0471 DSZZA FBS LCM: Logical Configuration Management B11 [A6] 3BK 11204 0472 DSZZA FBS TAS: TMN Administration Services B11 [A7] 3BK 11203 0075 DSZZA Transmission architecture specification [A8] 3BK 11203 0057 DSZZA Transmission functional specification [A9] 3BK 11210 0065 DSZZA Coding of OMU-CPF [A10] 3BK 11204 0445 DSZZA OMC-BSS SW/HW File Format Specification B11 [A11] 3BK 11204 0475 DSZZA OMC/MFS Ater & Gb Domain B11


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 11/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

[A12] 3BK 11204 0477 DSZZA FB Performance Management release B11 [A13] 3BK 11204 0463 DSZZA OMC/BSC SBL Concept B11 [A14] 3BK 11204 0473 DSZZA OMC/MFS HW Domain B11 [A15] 3BK 11256 0016 DSZZA MXPF DFS: NE1 over Ethernet Services [A16] 3BK 11204 0456 DSZZA Network Supervision (General part) [A17] 3BK 11204 0473 DSZZA Initialisation & Maintenance (General part) [A18] [A19] 3BK 11204 0386 DSZZA O&M TPGSM Interactions B10 [A20] 3BK 10204 0073 DTZZA SFD GERAN TWIN TRA Introduction in B8 and B9 [A21] MND/TD/OSY/CGO/205405 Delta Note HCM B9 ed2 released/HCM B10 IP Abis part [A22] [A23] 3BK 11204 0376 DSZZA TC G2.5IP SNMP MIB interface specification Release B10 [A24] 3BK 10204 0067 DTZZA SFD STM-1 Impact for TC [A25] 3BK 11204 0480 DSZZA Network Modification Process and Performance (NMPP)

BSS configuration and ATER part Release B11 [A26] MND/TD/OSY/SMA/206026 Delta Note HCM B10 IP Ater Part (included delta in TMN

administration services) [A27] 3BK 11204 0468 DSZZA Hardware Configuration Management (BTS and ABIS part) [A28] [A29]

3BK 11204 0470 DSZZA 3BK 11204 0449 DSZZA

Remote Inventory Transmissions Termination Points Configuration Export or Import file

PREFACE This document specifies, for BSC, TC and ATER part, the distribution of the Hardware Configuration Management FBs services over the different subsystems.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 12/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

1 INTRODUCTION

1.1 Scope

The aim of this document is to specify the distribution of the various Functional Blocks services over the subsystems as well as their interactions. The intended audience is: • The Subsystem Development teams • The System Integration team • The System Validation team • The System Specification team This document applies to B11 release only. When facing with multi-release issues, the reader shall also refer to document [11] “Hardware Configuration Management B10” for older releases. A special notice is added in every scenario or use case impacted in releaseB11.

1.2 Methodology Overview

The FBS documents are the second step of specification as presented in the document ref. [1] and follow the standard plan defined in ref. [2]. This specification uses an object oriented approach that has been adapted to the specific task of system functional specifications [3]. The same concepts as the ones introduced in the SFS document are used here (Actor, Service, Object), thus for a proper definition of these concepts, please refer to the document ref. [4]. We recall the different type of object oriented diagrams used by this specification and briefly comment each of them. 1. Object interaction diagrams (also named subsystem interaction diagrams): these

diagrams are used to describe the nominal interaction scenarios between the different subsystems. They may be used within the dynamic model section of each subsystem to describe when needed interactions between object classes of that subsystem.

The following conventions are used throughout these diagrams: • Messages exchanged between the actors and the system are prefixed by “A-”. • Messages exchanged between the subsystems are prefixed by “M-” in the case of a

message or by a “E-” in the case of a logical event representing a procedure of the considered interface (e.g. FTAM file transfer). Messages exchanged onto the Abis interface have no prefix. Protocol acknowledgements are usually not represented unless used as an applicative acknowledgement.

• Calls to elementary scenarios are referenced by their formal name plus possibly associated parameters. The related FBS where this scenario is described is indicated in brackets where necessary as shown in the following figure:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 13/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• References to Qmux scenarios are given in the following form: “Qmux exchanges

(type)”, the type indicating the objective of the Qmux exchange (e.g. configuration, alarm retrieval...). The detailed description of these scenarios is provided in the related document [A1].

1. Static object models: A static object model is developed for each subsystem. This model

is common to all FB; an object class can be shared by multiple FB; this ensures the consistency between the different FB in which this subsystem is involved. However, when presenting the static object model of a given subsystem within a FB document like the present one, only the objects and associations that are pertinent for that FB will be shown.

2. Dynamic models: A dynamic model is associated to each object class of the static model

that is responsible for sending/receiving events and/or messages. This model consists of a state diagram specifying the conditions under these events and messages are received/sent by that object, the actions triggered upon reception of a given event or message.

These 2 later models won’t be systematically developed within each FB in the context of the present release. Naming Conventions: • terms joined without separator (like traceWaitTimer) are peculiar to classes/attributes/

operations of objects of the static model, or to parameters of messages; • terms in tiny separated by hyphens (like trace-nb-not-know) make reference to errors

(nackErrorCode or errorCause); • terms in capital separated by hyphens (like MAX-TRACE-FILE-SIZE) are mnemonics of

system parameters

1.3 Document Structure

The section 2 of this document presents the main principles and concepts used throughout this Functional Block. The section 3 recalls the actors and the services defined in the document ref. [4] and presents their distribution over the different subsystems. The section 4 describes the message scenarios of interaction between the different subsystems. The section 5 details the behaviour of each subsystem.

Scenario Name (Doc)

Initiating Subsystem


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 14/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2 GENERAL PRINCIPLES

2.1 Scope and Basic Principles

In order to make easier, speed up and secure the reconfiguration of the BSS hardware, “On-line extension management” was introduced, without DLS upload/steerfile generation cycle. This kind of Hardware configuration management for BSC is based on the introduction in the system of the following principles: • management of BSC generic configurations; • the “plug and play” capability allowing the self identification by the BTS of its own

hardware; • the automatic allocation of Abis time slots for TREs (in TDM only) when discovered by the

BSC; • the capability to configure remotely the BTS transmission using the OML. Delta B8-B9: • In B9 compared to B8, the following features have been added:Remote inventory MFS at

OMC-R • HCM Improvements B9 • Enhanced Remote Inventory Interface • Enhanced Transmission Resource Management • Remote Inventory for Mx BSC has been added. • BTS with up to 24 TRE Delta B10-B11: In B11 compared to B10, for BSC, TC and Ater part, the following features have been added: • The A signalling over IP feature • The AMR-WB feature

2.2 Hardware configuration management Principles

2.2.1 MX BSC configuration

In B11 MX system, five BSC configurations types are defined based on the number of active CCP board. In B11 with the introduction of STM1 in the BSC and IP in the BSS, the LIU shelf will not be used anymore and in the case of IP in the BSS, the TP board will not be used anymore either in case of IPoEthernet on Abis whence the RFD 218833-BSC configuration without LIU shelf and without TP. With this RFD each BSC Evolution configuration type (from 200TRX to 1400TRX) has 3 configuration sub-types: o With LIU Shelf and with TP


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 15/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

o Without LIU Shelf and with TP o Without LIU shelf and without TP

The configuration sub-type "With LIU Shelf and without TP" is not allowed. The table below gives the configuration data of each BSC configuration type for the configuration sub-type with LIU shelf and with TP:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 16/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Configuration Type

1 2 3 4 5

Capacity Nb TRX Nb Cell1 Nb BTS2

200 200 150

400 400 255

600 500 255

800 500 255

1000 500 255

Nb of E1 Abis Ater CS Ater PS

96 10 6

96 20 12

176 303 18

176 404 24

176 485 28

Nb of VCE On CCP

Nb TCU Nb DTC CS Nb DTC PS Nb DTC (BSSAP)

50 40 24 64

100 80 48 128

150 120 72 192

200 160 96 256

250 192 112 256

Nb of VCE On OMCP

Nb TCH-RM pairs6 SCPR pairs OCPR pairs Nb TSC pairs7

1 1 1 8

1 1 1 8

1 1 1 8

1 1 1 8

1 1 1 8

Nb boards ATCA

Nb CCP 1 2 3 4 5

Nb spare CCP 1 1 1 1 1 Nb OMCP 2 2 2 2 2 Nb SSW 2 2 2 2 2 Nb TP GSM 2 2 2 2 2 8 Nb boards SMM

Nb SMM 2 2 2 2 2

Nb boards LIU Nb MUX 2 2 2 2 2 Nb LIU 9 8 8 14 15 16 1 The maximum number of cells is equal to the number of TRX, limited to the maximum number of cells that MX BSC could manage in B10: 500. 2 The maximum number of BTS is equal to the number of TCU multiply by 3 (there are 3 OML per TCU) 3 If there is a TP GSM V1 installed in the BSC: 30 Atermux are defined at BSC side, but only MAX-ATERMUX-TPV1 Atermux could be defined at TC side. 4 If there is a TP GSM V1 installed in the BSC: 40 Atermux are defined at BSC side, but only MAX-ATERMUX-TPV1 Atermux could be defined at TC side. 5 If there is a TP GSM V1 installed in the BSC: 48 Atermux are defined at BSC side, but only MAX-ATERMUX-TPV1 Atermux could be defined at TC side. 6 In B10, there is only one TCH-RM pair to manage all cells of the BSC. 7 The number of TSC pairs is equal to: roundup (max (Abis / 32, Ater CS/6)) 8 The MX BSC boards (TPGSM V3 and 5 CCPs) support traffic of up to 4500 Erlangs available from B10 release level MR2 (4500 Erlangs for the TP GSM V3 board and 900 Erlangs per CCP). With TPGSM V1 traffic of 4000 Erlangs has been valided for B10 release level MR1 and traffic of 4500 Erlangs is valided from B10 release level MR2. 9 Due to supply chain optimization in configuration 3, 4 or 5 there are 16 LIU boards present in the LIU shelf but there are only 14 ETU SBL equipped in configuration 3 and 15 ETU SBL in configuration 4.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 17/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

For configuration sub-type without LIU shelf in the previous table no boards LIU. For configuration sub-type without LIU shelf and without TP boards in the previous table no boards LIU and no TPGSM boards. From B10, the Atermux numbers are in the following ranges:

• CS atermux: [1..30] and [59..76]. • PS atermux: [31..58].

Because there is no Qmux for Atermux 59 and 60, they can only be used for HSL or for packet traffic (i.e. Dedicated Atermux) towards the MFS.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 18/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.2 TC configuration From B10 release, the MT120-WB and MT120-NB boards can be installed in a TC G2 rack, and in a TC G2.5 (without TCIF) rack and in a TC G2.5 rack with TCIF (also named TC IP rack). There is no restriction. Remark: The MT120-NB was been created to replace the legacy MT120. Indeed factory will switch to the new MT120-NB in any case (for example in case of legacy MT120 failure). The following configurations for TC G2 are available:

• TC G2 with ASMC/ATBX boards • TC G2 with ASMC/ATBX boards and MT120 boards or MT120-NB boards or

MT120-WB boards only • TC G2 with ASMC/ATBX boards and any mix of MT120 /MT120-NB/MT120-WB

boards The following configurations for TC G2.5 without TCIF are available:

• TC G2.5 (without TCIF) with MT120 boards or MT120-NB boards or MT120-WB boards only

• TC G2.5 (without TCIF) with any mix of MT120/MT120-NB/MT120-WB boards The following configurations for TC G2.5 with TCIF are available:

• TC G2.5 with TCIF with MT120 boards or MT120-NB boards or MT120-WB boards only

• TC G2.5 with TCIF with any mix of MT120/MT120-NB and MT120-WB boards


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 19/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.3 BSC extension/reduction Since no self-identification is provided for BSC G2 hardware, an operation to extend or reduce the BSC must be provided. This principle has been kept for the MX BSC. This operation combines extension/reduction of the BSC with extension/reduction of the respective transcoder equipment. BSC extension and TC extension can be performed independently allowing for ‘asymmetric’ configurations. The minimum extension step for the BSC G2 corresponds to the hardware of half a rack. The MX BSC extension allows increasing from the existing configuration to another one. The minimum extension step for a transcoder corresponds to the hardware associated to one Ater-mux link (i.e. 8 transcoder boards + associated Adaptors or 1 MT120 board). Standard rack layouts are defined for TC G2 and BSC racks. Since B7, only multiplexing 4:1 can be used on Atermux. TC boards can be of several natures: - TC G2 boards (ASMC + 4 ATBX + 8 DT16) plugged in a TC G2 rack. - MT120 board plugged in a 9125 (TC G2.5 (with or without TCIF)) rack or in a TC G2

rack. - MT120-NB/MT120-WB board, from B10 MR2 release, plugged in a 9125 rack or in a TC

G2 rack. A 9125 rack with TCIF (TC G2.5 with TCIF) has also: - Two TCIFs boards. These TCIF boards always have a plugged STM1 daughter board to allow STM1 feature and it is possible to add them an IP daughter board to allow the IP transport mode. In case of TDM transport mode: OMC gets the SBLs TC_ADAPT and TC16 from the TC hardware Audit. The BSC goes up to the OMC the two SBLs only in case of G2 TC board, in the others cases these two SBLs stay internal to the BSC. From B10 MR2 BSC The TC discovery phase scenario is used by the BSC

• To differentiate the different types of boards (ASMC or ATBX or legacy MT120 boards or MT120-WB or MT120-NB boards)

• To get the rack type (G2 or G2.5) and its R/S/S location for any generation of MT120. In case of TC G2 boards (ASMC or ATBX) BSC copies the RSS information from the TC G2 CPF file.

• To get the MT120 capabilities: AMR-WB capability and TFO capability. All these information are reported to the OMC. Note that the SBLs corresponding to A-PCM-TP and Ater-Hway-TP declared (in the standard configuration) are all created OPR in the BSC database independently of the presence or absence of the corresponding hardware.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 20/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Note for Transmission Programming. (This topic is introduced in the document Hardware Configuration Management (BTS and Abis part) Ref [A27] paragraph ‘Main principles’ in paragraph “ Extension/reduction on the Abis interface”). For BSC extension/reduction, the Transmission Programming request is sent by the operator, on the BSC local terminal (and not by the OMC). In case of IP transport mode: A BSC/TC audit scenario is launched including the TC audit. The TC audit is used by BSC:

• To get the RIT type • To get its R/S/S location • To get the MT120 capabilities: AMR-WB capability and TFO capability in case of

MT120-NB board, MT120-WB board or legacy MT120 board. MX BSC Reduction: From B10 MX BSC reduction is offered. The MxBSC reduction is done by an operation in 3 steps: The first step consists for the operator to prepare the reduction. The second step consists to move BTS (or TRE) that are mapped onto TCU of a CP-LOG to be removed to TCU of CP-LOG that remains. This step is named "BTS grouping" (see HCM BSC, TC and ATER part § 5.2.1.1 BSC Use Case Activate new BSC/TC standard configuration the BTS grouping algorithm). The third step consists to remove all SBL that are not in the scope of the target configuration. This step is named "Activation of the new configuration". Remarks: o If the second step is applied and the operator wants to roll back to the initial

configuration, he could use the command: REMAP-BTS-ON-CCP. o If the third step is applied and the operator wants to roll back to initial configuration,

he could apply the usual BSC extension procedure. First step: Reduction preparation The number of supported Abis-Hway-Tp and Ater-Hway-TP depends on the BSC configuration:

200TRX 400TRX 600TRX 800TRX 1000TRX Abis-Hway-Tp 96 96 176 176 176 Ater-Hway-Tp 16 32 48 64 76

Before reducing the BSC configuration the operator has to check that Abis-Hway-Tp and Ater-Hway-Tp to be removed are not used. If Abis-Hway-Tp to be removed is used: o The operator has to move the Abis chain/ring or the BTS to Abis-Hway-Tp that

remains. If Ater-Hway-Tp to be removed is used: o For HSL, the operator has to change the HSL configuration. o For Atermux CS, the operator has to reduce the TC configuration o For Atermux PS, the operator has to move the Atermux PS to a remaining Ater-Hway-

Tp.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 21/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.4 Definition of initial build The initial build of a G2 BSC or MX BSC based BSS is a build corresponding to:

• one variant of the minimum configuration or, • a “first off” configuration prepared “off site” (see below).

All B9 BTS SW packages and OMU-CPFs must be present in the initial build. 2.2.4.1 Minimum configuration of a G2 BSC based BSS The minimum configuration of a G2 BSC based BSS is one half BSC rack (equipped) and one transcoder rack (partly equipped). No BTSs are connected to this minimum configuration. The BSC rack and the transcoder rack must be physically connected over at least 2 Ater mux PCMs (Atermux number 1 and 2). The transmission and transcoding equipment terminating these 2 Ater mux PCMs must be equipped and configured (transmission mapping tables). The Qmux bus must be connected over these two Ater mux PCMs (the second Atermux PCM is used as a standby link in case the primary link towards the first Atermux fails). The BSC must be physically and logically connected to the OMC-R over X.25. This minimum configuration has to be set up by help of a tool (e.g. POLO) and the required software and data needed for start-up has to be loaded from local terminal. Important : The configuration tool must populate the database according to the physical configuration (2 Ater mux). Several customisation variants of this minimum configuration can exist, depending on :

• physical X.25 path (over Ater-interface or direct) • point of extraction of X.25, if routed over A interface (at ATBX (or MT120) or at

MSC) • transcoder rack type (G2 or G2.5);

Note that there are also a number of customisation (CDE) parameters. They are populated by POLO in the initial DLS 2.2.4.2 Minimum configuration of a Mx BSC based BSS - TDM BSS transport mode The minimum configuration of a Mx-BSC based BSS is the 200 TRX configuration (2 CCP boards: 1 spare and 1 active) and one TC rack (partly equipped). No BTSs are connected to this minimum configuration. At least 2 Ater mux PCMs (Atermux number 1 and 2) must be defined between the Mx-BSC and the TC. The transmission and transcoding equipment terminating these 2 Ater mux PCMs must be equipped and configured (transmission mapping tables). The Qmux bus must be connected over these two Ater mux PCMs (the second Atermux PCM is used as a standby link in case the primary link towards the first Atermux fails). The Mx-BSC must be physically and logically connected to the OMC-R over IP. This minimum configuration has to be set up by help of a tool (e.g. POLO) and the required software and data needed for start-up has to be loaded from local terminal. Important : The configuration tool must populate the database according to the physical configuration (2 Ater mux). Several customisation variants of this minimum configuration can exist, depending on :

• physical IP path (over Ater-interface or direct)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 22/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• point of extraction of IP, if routed over Ater interface (at ATBX (or MT120) or at MSC)

• transcoder rack type (G2 or G2.5); Note that there are also a number of customisation (CDE) parameters. They must be in the initial DLS. 2.2.4.3 Minimum configuration of a Mx BSC based BSS - IP BSS transport mode The minimum configuration of a Mx-BSC based BSS is the 200 TRX configuration (2 CCP boards: 1 spare and 1 active) and one TC rack (partly equipped). No BTSs are connected to this minimum configuration. The Mx-BSC must be physically and logically connected to the OMC-R over IP. This minimum configuration has to be set up by help of a tool (e.g. POLO) and the required software and data needed for start-up has to be loaded from local terminal. Remark: The requirement of the 1st 2 Atermux connected on MX BSC will be only needed if TDM BTS(s) is/are connected to BSC. If only IpoE1 BTS or/and IpoEth BTS are connected on MX BSC the two Ater mux PCMs are not needed anyway.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 23/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.5 STM1 The STM-1 feature is optional from a commercial viewpoint. Operators buy the feature with a maximum number of STM1 Interfaces per OMC. This maximum number concerns STM1 Interface generally speaking, that means taking into account BSC STM1 interfaces but also TC ones. An interface represents a pair of protected STM1 links.

2.2.5.1 STM1 in TC G2.5 with TCIF (also named TC IP) STM1 is only available in a TC G2.5 with TCIF; the TCIF board has a STM1 daughter board connected on. From a product viewpoint this STM1 daughter board comes mandatory with the TCIF motherboard. STM1 is a 155Mbit/s interface. STM1 physical interface is defined as an optical interface, this offered is in mono-mode, short haul (short distance). A TC can be pure E1, pure STM1 or mixed. A STM1 link can contain up to 63 VC12 containers (also named VC12 tributary). Each E1 link is transported transparently in one VC12 container. The STM-1 configuration (logical E1 to VC12 mapping) is only performed from the TC NEM. The configuration granularity is the MT120. On MT120 the flexibility on Ater interface and A interface is supported, i.e the A/Ater interface independence is supported. The configuration of the STM1 feature is done in 3 steps. The first step is the declaration of the STM1 interface from the OMC. This first step is used for the optionality reasons; then allows to the operator the supervision of the newly declared STM1 interface before using it for telecom traffic. The second step is the STM1 configuration; this covers the mapping of the STM1/VC12. The configuration granularity is the MT120. On MT120 the flexibility on Ater interface and A interface is supported, i.e. the A/Ater interface independence is supported. This step is the preparation of the ‘working’ STM1 configuration then the download of the ‘working’ STM1 configuration from TC NEM as becomes the ‘candidate’ configuration as soon as it is successfully downloaded on the TC rack. The third step is when the ‘candidate’ configuration becomes the ‘current’ configuration as soon as it is successfully applied in the TC rack. The STM1 configuration lifecycle can be modelized as below:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 24/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Working

STM-1 configuration file

Candidate

STM-1 configuration

Current

STM-1 configuration

Set conf

Apply conf


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 25/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.5.2 STM1 in MX BSC The configuration of the STM1 feature is proposed in 3 steps. The first step is the Declaration of the STM1 interfaces from the OMC. This first step is used for the optionality reasons; then allows to the operator the supervision of the newly activated STM1 Interfaces before using them for telecom traffic. The second step is the transmission Termination Points configuration preparation. This step is the preparation and the setting of the transmission Termination Points configuration from the BSC terminal which becomes the ‘candidate’configuration. The third step is the application of the port configuration from the BSC terminal. At that time the ‘candidate’ configuration becomes the ‘current’ configuration. The Abis/Ater-HWAY-TP are then configured to be connected to an LIU-E1 port or to be connected to a STM1 VC12-E1. This configuration step is done in parallel with the physical required modifications in term of cabling or cross-connection of Abis and Ater. For example, if an Abis is configured as STM1 VC12-E1 instead of LIU-E1, the physical link, BTS side, must probably be connected to the required ADM. The configuration is allowed if the requested SBLs exist in the DLS.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 26/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.6 HSL support The MX BSC boards (TPGSM V3 and 5 CCPs) support traffic of up to 4500 Erlangs available from B10 release (4500 Erlangs for the V3 board and 900 Erlangs per CCP). With TPGSM V1 traffic of 4000 Erlangs is valided for B10 release level MR1 and traffic of 4500 Erlangs is valided from B10 release level MR2. Only E1 links are supported by the Alcatel BSS (T1 links are not supported). With a traffic of 4500 Erlangs, supported on MX BSC with TPGSM V1 from B10 release MR2 and supported on MX BSC with TPGSM V3, it becomes mandatory to extend the SS7 signalling capacity on the A interface to overcome this bandwidth limitation. The capacity can be extended either by using high speed links (HSL) as described in ITU-T Q.703 Annex A or by using two links set. The choice is to use HSL links (the HSL links shall use E1 framed mode -G.704- aggregating time slots 1 to 31, allowing a bandwidth of 1.984 Mbit/s). The use of HSL links requires that the transmission network between the BSC and the MSC ensure the frame integrity for time slots 1 to 31. For redundancy purpose, two HSL links will be used and therefore the link set will be done with these two 1.984 Mbit/s links. The load will be shared between these two HSL links. When one of the HSL link is out of service, the second HSL link shall be able to support all traffic without performances degradations. In this case the load of the HSL link shall not exceed 60%. The use of HSL is optional and may be used if this option is supported by the MSC. It is the choice of the operator to decide whether the HSL links are used. The HSL can be used on any MX BSC configuration type (whatever the number of Erlangs supported by the MX BSC). During installation of the network, the configuration of HSL is done with POLO. When the network is operational, the switching between the LSL and HSL mode or vice versa is done by an operator command at the BSC Terminal. MX BSC SS7 configurations: The selection of the mode of operation (HSL/LSL) is done by the operator For TDM modes: The MX BSC supports LSL and HSL terminations in the TP GSM in TDM mode The MX BSC supports two 1.984 Mbit/s channels for HSL termination The MX BSC supports sixteen 64 kbit/s channels for LSL termination Transcoder SS7 configurations for IP modes: The transcoder (TC G2.5 IP) supports LSL and HSL SS7 terminations The two 1.984 Mbit/s links used for the HSL channels of a MX BSC shall be terminated in two different

MT120 boards in TC. The sixteen 64 kbit/s links used for the LSL channels of a MX BSC shall be terminated at least in two

different MT120 boards. The LSL mapping is still the same as in TDM: 1 SS7/LSL per Atermux (hardcoded on first 16 Atermux) using TS16 of the 1st A-interface on each Atermux.

TDM synchronization with E1 links supporting HSL: The E1 links carrying the HSL can be used as any other link for TDM synchronization. When the E1 link(s) is/are “enabled” (Not OPR), the E1 link(s) carrying the HSL will be assigned the lowest clock priority among all the enabled Atermux links.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 27/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

When the E1 link(s) is/are disabled (OPR), the E1 link(s) carrying the HSL will be assigned a clock priority lower than any other enabled Atermux E1 links.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 28/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.7 AMR_WB and TFO support The AMR-WB feature is introduced from B10 release sub-release MR2. The AMR-WB feature is an optional feature. The TFO-NB feature is supported from B11 release.

2.2.7.1 Overview The Adaptive Multi-Rate Wideband Codec (AMR-WB) is a speech coder standard introduced by the 3rd Generation Partnership Project (3GPP R5) for compressing the toll quality speech (16000 samples/second). The AMR-WB Codec has been approved by the ITU-T standards body and is referred to as G.722.2.This speech coder is planned to be widely used for speech compression in the 3rd generation mobile telephony. It is needed in 2G for improved voice quality and service continuity. AMR-WB operates like AMR with various bit rates. The bit rates (GMSK and 8PSK) are the following: 6.60, 8.85, 12.65, 15.85, and 23.85 kbit/s. The lowest bit rate providing excellent speech quality in a clean environment is 12.65 kbit/s. Higher bit rates are useful in background noise conditions and in the case of music. Also lower bit rates of 6.60 and 8.85 provide reasonable quality especially if compared to narrow band codec. On Air interface AMR-WB can use GMSK over a FR TCH, 8-PSK over a FR TCH or 8-PSK over a HR TCH. TFO with AMR-WB: TFO is not necessary to use AMR-WB, but AMR-WB does not make sense without TFO. Without TFO, the compressed speech is decoded in G711 speech frame (narrow band) before the core network and then encoded to the previous compressed speech at the output of the core network. No matter the used speech codec, this decoding / encoding phase will degrade the voice quality. But this degradation will be more important with AMR-WB, voice quality being one of the main advantages of this speech codec. A full description of TFO with AMR-WB can be found in ref [20]. Only GMSK modulation is supported in BSS releases B11: so only the codec bit-rates in grey are available.

Codec bit-rate Full-rate Half-rate GMSK 8-PSK 23.85 kbit/s × × 15.85 kbit/s × ×

× × × × 12.65 kbit/s × × × × × × 8.85 kbit/s × × × × × × 6.60 kbit/s × ×

List of wideband codec modes


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 29/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.7.2 O&M aspects The AMR-WB feature is introduced from B10 release MR2 sub-release. This feature will be available for both TDM and IP configurations; nevertheless the IP configuration applies from B11 release. For the AMR-WB feature a new MT120-WB transcoder board is developed. The MT120-WB board supports the TFO Wideband. The new MT120-NB board is also developped to replace the legacy MT120 board. This board came from release B10 MR2. In B11 the SW of the MT120-WB/NB board and the legacy MT120 board will be upgraded to take into account the TFO-NB feature. BSC has to recognize the different types of MT120 boards for Telecom and O&M needs and also their capabilities.

MT120 SW capability MT120 boards Type AMR-NB AMR-WB TFO-NB TFO-WB

Release

Legacy MT120 Yes No Yes No B11 MT120-NB Yes No Yes No B11 MT120-WB Yes Yes Yes Yes B11

Figure 1 “MT120 board and their capabilities”

The MT120-WB and MT120-NB boards can be installed in a TC G2 rack or in a TC G2.5 rack (without TCIF) or in a TC G2.5 rack with TCIF (also named TC IP). There is no restriction. The MX BSC supports AMR-NB, AMR-WB, TFO-WB and TFO-NB from B11 release. The G2 BSC supports AMR-NB, AMR-WB and TFO-WB from release B10 MR2, but never TFO-NB.

BSC / capabilitiy AMR-NB TFO-NB AMR-WB TFO-WB BSC G2 Yes No Yes Yes

MX BSC Yes Yes Yes Yes

There is no restriction on the MT120 boards allocated to the BSC. Indeed a BSC can be linked to legacy MT120, MT120-WB and MT120-NB from the same or from different TCs. Remark: On QMUX interface, the MT120 master in the BSC cluster can now be a MT120, an MT120-NB or an MT120-WB as well. Remark: At O&M level only: The MT120-WB and the MT120-NB are taken into account from release B10 MR2. Channel configuration: Up to B10MR1 the number of CIC hosted per MT120 is restricted to 120. With this configuration, a first DSP failure does not result in loss of CIC.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 30/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The MT120-WB/NB does not support the DSP recovery. These boards can host 124 CIC from B10 release, - By reusing TS16 as TCH in IP/TDM mode once HSL or Asig/IP is used. - By reusing TS15 as TCH in TDM mode, since Alarm Octet is not supported by MT120 anyway. Note that TS15 is already used as TCH in IP mode. Remark: On LSL, the TS16 is still used for SS7. The legacy MT120 can only host 120 CIC. The BSC doesn’t use TS16 for traffic if the TC board is a legacy MT120 one. The first DSP failure recovery remains supported on the legacy MT120 board.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 31/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.8 A Signalling Over IP

2.2.8.1 Overview

The purpose of this feature is to transfer the SS7 signalling over the IP network between the BSC and NGN core network. As recommented by 3GPP TS 29.202, the M3UA protocol based on SCTP protocol is used to transfer SCCP signalling instead of the MTP. Until B11 release, the BSC supports only SS7 LSL and HSL in TDM i.e. the Pure TDM mode (See Figure 2 “A signalling is transferred in pure TDM mode (SS7 LSL)”). From B11 release,

• With IP BSS transport mode the mixed mode (See Figure 3 “A signalling in mixed mode (Ater in IP mode and A signalling in TDM mode) is supported.

• The A Signalling Over IP feature is introduced. The A Signalling Over IP feature is an optional feature (See LCM Ref [A5]). The A-signalling over TDM is still supported. TDM mode and IP mode are exclusive.

1. The Pure TDM mode: The SS7 mode is LSL and the N7 signalling is transferred in TDM mode, the TC is transparent for the N7 signalling transfer. (Remark: In TDM mode if the SS7 mode is HSL the N7 signalling is transferred directly between BSC

and MSC)

TC

BSC

BSSAP

SCCP

MTP3

MTP2

MTP1

MSC

BSSAP

SCCP

MTP3

MTP2

MTP1

N7 Links

Figure 2 “A signalling is transferred in pure TDM mode (SS7 LSL)”

2. The mixed mode: The SS7 mode is LSL.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 32/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The transcoder plays the role of signalling gateway: it forwards the N7 message (received from the BSC in IP mode) to the MSC (in TDM mode).

The O&M model is same as pure TDM mode, because there is still N7 link between the TC and MSC and the SCTP association between BSC and TC is transparent for the operator.

BSC

BSSAP

SCCP

MTP3

M2UA

SCTP

IP

TC

SCTP

IP

M2UA

MTP1

MTP2

NIF

IP Network

MSC

BSSAP

SCCP

MTP3

MTP2

MTP1 N7 Links

Figure 3: “A signalling in mixed mode (Ater in IP mode and A signalling in TDM mode)”

3. A Signalling over IP

From B11 release, the new “A signalling over IP” Feature is offered. The N7 signalling is transferred over IP by M3UA. The BSC is connected to MSC directly.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 33/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

M3UA

SCTP

IP

IPSP IP BSC M3UA

SCTP

IP

IPSP1

M3UA

SCTP

IP

IPSP2

MSC

Figure 4 “A signalling Over IP mode”

In BSC there is one IP Server Process (IPSP) per MSC. The IPSP is the physical entity managing the SCTP associations. The IPSP in BSC is located in the OMCP, working in active standby mode. BSC can be connected to more than one MSC and each MSC can have more than one IPSPs (MSC side). In BSC, for each MSC there is one separate IPSP, and all the IPSPs in BSC have the same IP address. Different port number distinguishes the different MSC.

2.2.8.2 O&M aspect “A signalling Over IP” feature is only implemented in the BSC evolution. The BSC and MSC server are in peer-to-peer mode, the MSC server will terminate the SS7 signalling instead of forwarding it to other SS7 signalling point. And there is no other SS7 signalling point between BSC and MSC server. One MSC server has only one signalling point code. The A Signalling over IP will not work with the other A signalling transfer modes at the same time. The A Signalling over IP can be used towards several MSC servers. Only the SS7 point code is used as the routing key for M3UA for both MSC and BSC. The routing key is configured statically instead of being configured by the routing key registration scenario. The MSC management is described in document LCM Ref [A5].


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 34/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.2.9 A Channel Configuration

2.2.9.1 A Channel Configuration except TS 15 and TS 16 The A channel except TS 15 and TS 16 configuration and usage depends on the configuration: Achannel number

TDM /LSL TDM /HSL IP/LSL IP/HSL TS 14 Qmux Qmux TCH TCH TS 31 X25 or TCH X25 or TCH TCH TCH Others Except TS 15 & TS16

TCH TCH TCH TCH

2.2.9.2 TS15 and TS16 Configuration for traffic usage

2.2.9.2.1 Description TS16 and TS15 can be used for traffic from the B10 MR2 release. There are two actions to do to be able to use the TS15 and TS16 for traffic: 1) For the BSC, to validate that the TC board is at a SW version level supporting the TS15 and TS16 configuration. 2) For the BSC to configure the TS15 for traffic as well as the TS16. 1) Check of the TC board SW version. In order for the BSC Evolution to identify a legacy MT120 not migrated at least in MR2 SW level, the BSC (at least in MR2 B10 release) audits the TC in following occurrences: - At BSC start time, - Periodically, every 30 minutes. This audit consists in sending an ‘Equipement-Id-Request’ Qmux message to the TC boards, with the TC returning as RIT value: - ‘SM2M’ if ASMC board. - ‘TRCU’ if ATBX board. - ‘MT120’ in case of legacy MT120 board in pre-B10 MR2 SW version, that is to say a SW version not supporting TS15/TS16 configuration. - ‘MT12’ in case of legacy MT120 board when in B10 MR2 or further version, that is to say when TS15/TS16 configuration is supported in the TC. - ‘MTWB’ for MT120-WB HW generation that is to say a board generation supporting TS15 and TS16 configuration. - ‘MTNB’ for MT120-NB HW generation that is to say a board generation supporting TS15 and TS16 configuration In other words: - If returned RIT is equal to ‘MT12’, ‘MTWB’ or ‘MTNB’, the BSC is allowed to configure the TS15. - If returned RIT is equal to ‘MTWB’ or ‘MTNB’, the BSC is allowed to configure the TS16. 2) Configuration of TS15 and TS16 for traffic On MT120 side (TC side), the standard behaviour is to consider the TS15 and TS16 as ready for traffic. There is no migration issue with that behaviour since it is the BSC that decides to open or not the timeslot for traffic toward the MSC. On BSC Evolution side:

Tran Tien Long

Cross-Out


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 35/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

- The BSC has at least the release B10 MR2. - The TC board shall be an MT120-WB or MT120-NB (minimum SW level is B10 MR2). This is the object of the previous section. This is a mandatory condition for both TS15 and TS16 (knowing TS16 not supported on legacy MT120). - The concerned TS16 does not carry SS7/LSL (or is not “not usable” due to Atermux multiplexing in TDM) HSL presence on the first 16 Atermux shall be tested by the BSC at MT120 SW level check time. The TS16 configuration for traffic has MT120 granularity. When the BSC configures the TS15 or TS16 for traffic, two actions are needed: - Configuration of cross-connected timeslots toward TC side (TS15 or TS16 is not given anymore) - Once TC side successfully configured, unblocking of TS15/TS16 toward MSC side. In case the TC

side is not successfully configured, the BSC automatically retries the configuration scenario at the next periodic TC check.

Remark: On TC side, on MT120 side, the standard behaviour is to consider the TS15 and TS16 as ready for traffic.

After the change N°7 mode from LSL to HSL or after a BSS transport mode switch from TDM to IP the ACH configuration of the TS16 and TS15 can be changed if not done during (See the above paragraph Check of the TC board SW version).

2.2.9.2.2 TS15 Configuration For G2 TC boards (older boards ASMC/ATBX) the A channel number 15 configuration is used as Alarm octet. (TDM/LSL only supported) For the MT120 board, the A channel number 15 configuration depends only on the sub-release: For legacy MT120 with SW level inferior to B10 MR2, the TS 15 in BSC is “not usable” (BSC blocks the TS15). For legacy MT120 with SW levels from B10 MR2, MT120-NB and MT120-WB the TS15 is TCH in TDM and IP transport mode, for LSL or HSL use.

2.2.9.2.3 TS16 Configuration

The configuration of TS16 depends on the MT120 board generation. The configuration of TS16 for MT120-NB or MT120-WB boards is the following, if A signalling over IP is disabled TDM /LSL TDM /HSL IP/LSL IP/HSL Atermux Number

1….16

17….30 + 61….76

1….30 + 61….76 (**)

1….16

17….30 + 61….76

1….30 + 61….76

TS 16 N7 (*)

TCH/GCH TCH / GCH

TCH

TCH

TCH

(*) N°7 on the first 16 Atermux except if it is a dedicated PS Atermux. (**) Except for Atermux carrying the HSL. If A signalling over IP is enabled, in the case TDM/LSL the Atermux 1 to 16 support traffic (TCH). The configuration of TS16 for TC boards older than MT120-xB is the following


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 36/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

TDM /LSL TDM /HSL IP/LSL IP/HSL Atermux Number

1….16

17….30 + 61….76

1….30 + 61….76 (**)

1….16

17….30 + 61….76

1….30 + 61….76 (**)

TS 16 N7 (*) Not used Not used

Not used

Not used

Not used

(*) N°7 on the first 16 Atermux except if it is a dedicated PS Atermux.

2.3 Management of exclusion

Exclusion between Logical Configuration Management and HW extension/reduction The OMC-R has to guarantee the consistency between the logical configuration and the HW equipment. To ensure consistent modifications (e.g. to prevent operators from trying to modify a cell and deleting the associated sector at the same time) a "mutual exclusion" is managed amongst logical configuration facilities and between logical configuration facilities and HW extension/reduction. So HW extension/reduction operations that may change HW characteristics or capabilities used for consistency checks are rejected by OMC if a logical configuration facility is in progress: • During the application of modifications from the SC • During the PRC activation in message mode • Between the PRC application in MLU mode and the MLU Accept/Close • During logical audit or force configuration In the opposite, a logical configuration facility is rejected by OMC during these HW extension/reduction operations (in case of PRC activation in message mode, the activation is accepted but stays in the activation queue until availability of the BSC).


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 37/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

2.4 OMC “Post-it” Feature

This OMC feature is available in BSSUSM for the BSS, TC and BSC. It allows the operator to store remarks. Every user that has access to BSSUSM main view is able to view them and also to modify the notes (memo). The maximum size of the text is 600 characters. In HW equipment view screen, memo is available. This part of the screen allows the operator to put remarks concerning an element selected in the HW equipment view. Every user that has access to the BSS equipment main view can modify the memo and save the modification.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 38/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

3 OVERALL DESCRIPTION

3.1 List of Actors

There are two external actors involved in this FB: � the O&M operator, � the Inventory operator, this operator is connected to the OMC-R via an ftp connection.

3.2 List of Services

This FB supports the S-HCM-ModifyHWConfig, S-HCM-PCMConfig and S-HCM-INVENTORY services defined in reference document [4].


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 39/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

3.3 Services/Subsystems Mapping

3.3.1 Services/Subsystems Mapping OMC-R, BSC Terminal, BSC, BTS Service Name

O&M Action OMC-R Use Case BSC Terminal Use Case

BSC Use Case BTS Use Case

S-HCM-ModifyHWConfig

Declare BSS Add a BSS


Undeclare BSS Delete a BSS


Modify a BSS Modify BSS Identification


Configure G2 BSC/TC(***) OMC/BSC synchronisation

Activate new G2 BSC/TC standard configuration

BSC hardware

audit


Configure Mx BSC/TC(***) OMC/BSC synchronisation

Activate new Mx BSC/TC standard configuration

BSC hardware

audit

TC hardware audit


Discover a BSS Complete BSS audit

BSC hardware audit

BTS hardware audit

(HCM BTS and AbiS part (Ref

[A27])

BTS hardware audit

(HCM BTS and AbiS part (Ref

[A27])


Display Rack Layout Display Rack Layout


Display VCE Display VCE


BSC/GPU IP Association BSC/GPU IP Association

Modify MFS Characteristics


Change BSS Transport Mode on BSC side

BSS Transport Mode Switch

BSS Transport Mode Switch


Modify BSC SS7 Transport Mode




Plug identification information BSC Plug identification

information display

S-HCM-PCMConfig Display BSS topology Display BSS topology

S-HCM-PCMConfig Suspend Automatic Transmission programming


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 40/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Service Name

O&M Action OMC-R Use Case BSC Terminal Use Case

BSC Use Case BTS Use Case

S-HCM-PCMConfig AterMux configuration for GPRS

Modify GPRS granularity

Modify dedicated GPRS AterMux into a mixed AterMux

Set-up

(respectively unset) dedicated GPRS AterMux

Modify mixed AterMux into a dedicated GPRS

AterMux

Modify AterMux GPRS

Ater Signalling Configuration

S-HCM-PCMConfig Configure Ater Change Ater connection type

Change CRC4

Loudness setting

Half-rate setting

Configure Ater

Program Ater Transmission

S-HCM-PCMConfig BSC STM1 Configuration Management

Getting current or candidate BSC

STM1 configuration


STM1 configuration properties

Checking a BSC STM1

configuration

Comparing two BSC STM1 configuration

Setting a candidate

BSC STM1 configuration

Applying a

candidate BSC STM1

configuration

Get BSC’s LIU/STM1 resource

Display of BSC’s section and path

traces

Modification of BSC’s transmitted section and path

traces


STM1 configuration


STM1 configuration Properties

Setting a candidate BSC STM1 configuration

Applying a

candidate BSC STM1

configuration

Display of BSC ‘s section and path

traces

Modification of BSC’s transmitted section and path

traces

(***) For these O&M actions, the programming of transmission is requested from the BSC LMT

3.3.2 Services/Subsystems Mapping OMC-R, TC-NEM, BSC, TC


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 41/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Service Name

O&M Action OMC-R Use Case

TC-NEM Use Case

BSC Use Case

TC Use Case


TC Management TC Declaration

TC Removal

Display TC Data

Update TC Information

TC Declaration


TC Supervision Move TC Supervision to another BSSIM

Update TC Supervision


M120 Adding/Removal

BSC-TC Audit

Activate new G2.5 TC standard configuration

Activate new TC G2.5 with TCIF standard

configuration


TCSL Endpoints resynchronisation

TCSL Resynchronisation

Modify TC Characteristics

BSC-TC Audit

TCSL Endpoint Update

TC Audit

TC Configuration

Update


STM1 Declaration/Undeclaration

STM1 Declaration/ Undeclaration

STM1

Declaration/ Undeclaration


Plug identification information

TC Plug identification

information display

S-HCM-PCMConfig TC STM1 Configuration Management

Getting current or candidate TC

STM1 configuration

Getting properties for current or candidate TC

STM1 configuration

Checking a TC STM1 configuration

Comparing two TC STM1 configuration

Downloading a candidate TC

STM1 configuration

Applying a candidate TC

STM1 configuration

Display of TC’s section and path

traces

Modification of TC’s transmitted section and path

traces

Getting current or candidate TC

STM1 configuration

Downloading a candidate TC

STM1 configuration

Applying a

candidate TC STM1

configuration

Display of TC’s section and path

traces

Modification of TC’s transmitted section and path

traces

S-HCM-inventory Automatic inventory Automatic inventory

Inventory TC

S-HCM-inventory On demand inventory On demand inventory

Inventory TC


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 42/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4 SUBSYSTEMS INTERACTIONS

This section presents how the services of the HCM FB are supported by the different subsystems (in our present case the OMC-R, the BSC, the BTS and the TC. The MFS is also in the scope of this document for inventory O&M actions only). The objective of this section is to present for each service: � the involved subsystem(s); � the interactions between the « system boundary » (i.e.: the external actors defined in

section 3.1 above) and these subsystems, and; � the interactions between the subsystems. We elaborate a scenario for each O&M actions when subsystems interactions exist. Each scenario is represented by vertical bars and directed arrows between those bars. The left-most vertical bar always represents the system boundary; a bar is introduced for each subsystem involved by a given scenario.

4.1 Service S-HCM-ModifyHWConfig

The O&M actions of this service supported by more than one subsystem are: • Configure G2 BSC/TC; • Configure MX BSC/TC; • Discover a BSS; • TC management • TC supervision • TCSL endpoints resynchronization • MT120 Adding/Removal • BSC/GPU IP association • Change BSS transport Mode on BSC side • STM1 Interfaces (BSC/TC) Declaration/Undeclaration • BSC/TC Plug Identification Information • Change N°7 mode from LSL to HSL or from HSL to LSL. • Modify BSC SS7 Transport Mode


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 43/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.1 O&M Action «Configure G2 BSC/TC » The aim of this O&M action allows the control of the hardware extension/reduction of the G2 BSC or TC composed pieces of equipment. 4.1.1.1 Activate new G2 BSC/TC standard configuration Scenario


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 44/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Description BSC-TE OMC BSC TC Operator requests to modify and activate a new standard configuration using G2 BSC local terminal

A-ACTIVATE-NEW-CONF ———————————————————————→

G2 BSC acknowledges the activation of the new configuration via local terminal

A-ACTIVATE-NEW-CONF-ACK ←———————————————————————

G2 BSC sends an alarm to the OMC-R (after the DLS was updated)

M-ALARM-REPORT (MX BSC, HW_Resynch, Event)

←————————————— OMC-R invokes automatically “BSC hardware audit”.

BSC hardware audit (HCM) ————————ο

Operator request a Program transmission using G2 BSC local terminal (it is a integrated part of the Activate-new-conf)

A-PROG-TRANS ———————————————————————→

G2 BSC acknowledges the Program transmission via local terminal

A-PROG-TRANS-ACK ←———————————————————————

After the Prog-Trans receipt from the G2 BSC local terminal, G2 BSC launches the TC discovery phase.

TC DISCOVERY PHASE (HCM BSC, TC and Ater part) ————————ο

Figure 5: “Activate new G2 BSC/TC standard configuration” scenario

OMC-R Use case BSC Use case 5.1.1.5 OMC/BSC synchronisation 5.2.1.1 Activate new BSC/TC standard configuration

5.2.1.2 BSC hardware audit


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 45/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.2 O&M Action «Configure MX BSC/TC » The aim of this O&M action allows the control of the hardware extension/reduction of the MX BSC or for a MX BSC in TDM Mode the control of TC composed pieces of equipment. The allowed TC racks combinations are

� TC G2 racks + TC G2 rack � TC G2 racks + TC G2.5 rack � TC G2.5 racks + TC G2.5 rack

4.1.2.1 Activate new MX BSC/TC standard configuration Scenario

Description BSC-TE OMC BSC TC BSC

Application MX

Platform

For MX BSC in TDM Mode or IP mode

To extend MX BSC configuration operator inserts new boards (CCP, LIU, …) into MX shelf (See § 2.2.2.2 MX BSC extension/reduction). The insertion of a board is detected by MX platform and notified to the application. In case of CCP board, the Mx Platform software is started and the board readiness is notified to the application. These two notifications are not taken into account by the BSC application.

MF-HW-Board-Insertion-removal-Notification ← MF-PMS-Board-Readiness ←

Operator requests to modify and activate a new standard configuration using MX BSC local terminal

A-ACTIVATE-NEW-CONF ————————————————→

On each board (i.e. on the 2 MUX boards and on two TP boards) the configuration of NE1oE routing must be realized (See Related Document [A15]).

Service Request(MF_NE1oE_CONFIGURE(NE1oE Routing Table)) → Service Request_Report ←

The HW state audit service of MX platform is requested to report the list of all equipped Field Replaceable Units (FRU) with their geographical address (rack, shelf and slot information), and their current state. For each additional board of the new MxBSC configuration, the BSC application checks if the board is present and if the RIT type is the one expected, in case of LIU board the two RIT types (LIU and LIU75) are accepted. If not, an alarm is generated. The boards of the old configuration are not checked. Boards which are inserted in slots that are not used for the new configuration are completely ignored whatever their RIT types.

HW-State-Audit (Any FRU) → HW-State-Audit-Report ←


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 46/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Description BSC-TE OMC BSC TC BSC

Application MX

Platform

For each additional CCP board of the new configuration, that is present in the state audit, the BSC application reset the board. After the reset, all application processes are launched on the board, and alarms and state are synchronised between BSC application and Mx platform.

HW_Board_reset (FRUId) → HW_Board_reset_report ←

Each CCP board that is not in the new configuration is powered off.

MX BSC acknowledges the activation of the new configuration via local terminal

A-ACTIVATE-NEW-CONF-ACK ←————————————————————

MX BSC sends an alarm to the OMC-R (after the DLS was updated)

M-ALARM-REPORT (MX BSC, HW_Resynch, Event)

←————————————— OMC-R invokes automatically “BSC hardware audit”.

BSC hardware audit (HCM)

————————ο Operator requests a Program transmission using MX BSC local terminal to configure the BSC side (it is a integrated part of the Activate-new-conf).

A-PROG-TRANS ————————————————————→

MX BSC acknowledges the Program transmission via local terminal

A-PROG-TRANS-ACK ←————————————————————

In case of Mx BSC reduction, operator can now remove the no more used CCP.

EndFOR If MX BSC is in TDM Mode After the Prog-Trans receipt from the MX BSC local terminal, MX BSC launches the TC discovery phase.

TC DISCOVERY PHASE (HCM BSC, TC and Ater part) ————————ο

EndIF

Remark: If a new MX BSC board does not succeed to reset, it is processed as a board failure. Remark: If MX BSC is in IP mode, the TC discovery is done via the BSC-TC audit triggered on the reception of the M-TC-Audit-Needed message from TC sent when applying TC Nem extension/reduction screen.

Figure 6: “Activate new MX BSC/TC standard configuration” scenario

OMC-R Use case BSC Use case 5.1.1.5 OMC/ BSC synchronisation 5.2.1.1 Activate new BSC/TC standard configuration

5.2.1.2 BSC hardware audit


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 47/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.2.2 TC Discovery Phase Sub-scenario This sub-scenario is only available with BSC in TDM mode. This sub-scenario is available for G2 BSC and MX BSC from (MR2) B10 release. The TC discovery phase is launched:

• After a program transmission requested by operator during an “Activate new (G2/MX) BSC/TC standard configuration” scenario

• During init SM-Adapt (see IMO) to discover the TC boards • Autonomously after a BSC Reset (See IMO BSC, TC and Ater part Ref [A4]), if there

are TC SBL to be configured.

Description BSC-TE OMC BSC TC While the TC boards are not all identified

BSC sends periodically a Equipment Identity request (using Qmux interface) to the TC to identify the RIT type.

Equipment Identity Request ————————————→

TC reports a string representing the RIT type and MX BSC transcodes the received string into the corresponding RIT type and BSC stores the RIT type.

Equipment Identity Report ←————————————

Then, BSC sends a functional Identity request (using Qmux interface) to the TC to retrieve the RSS information.

Functional Identity Request ————————————→

In case of MT120 the TC rack type (G2 or G2.5) is also reported from TC as its rack number, the shelf number and the slot number. In case of TC G2 boards (ASMC or ATBX) BSC copies the RSS information from the TC G2 CPF file. BSC stores the RSS.

Functional Identity Report Discovery Phase ←———————————————

IF the string in Equipment identity report identifies a MT120-NB or a MT120-WB or a legacy MT120 with B10 MR2 software at least:

BSC sends a capability request (using Qmux interface) to get the capabilities of the MT120 board.

Capabilities Request ————————————→

BSC updates the capabilities of the MT120 in DLS in accordance with the received capabilities.

Capabilities Report ←—————————————

ELSE No message sent to TC from BSC IF the string in Equipment identity report identifies a legacy MT120 with B10 MR1 software or B9 software:

The MX BSC sets the capabilities of the MT120 board to “0” in the DLS

Else IF the string in Equipment identity report identifies an ASMC board or an ATBX board: The BSC does not set the capabilities in the DLS.

ENDIF ENDIF ←

——

——

——

——

——

——

——

——

——

——

——

——

——

→Dis

cove

ry Ph

ase


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 48/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Description BSC-TE OMC BSC TC BSC translates RIT type in RIT value. (Note 1) If the timer is already running, BSC cancels the timer. BSC updates the DLS with following information:

- RIT and RSS - If MT120, the MT120 capabilities - CIC capability for Telecom usage

BSC transfers data configuration to TC to reconfigure the transmissions boards (using Qmux interface).

Data Configuration download procedure ←——————————————→

BSC triggers a timer (see note 1) at the first board identified or in other cases MX BSC restarts the timer and if one other board is to identify the BSC continues on the next board with the same actions as previously (New discovery phase).

EquipmentIdentity Request —————————————→ ————————————→ Functional Identity Request —————————————→ —————————————→ …….

At timer expiration, M-ALARM-REPORT (MX BSC, TC HW_Resynch, Event) ←

— —

—

Tim

er ela

psed

MX BSC sends a TC HW_Resynch alarm to the OMC-R for synchronisation

←—————————————

OMC-R invokes automatically “TC hardware audit”.

TC hardware audit (HCM) ————————ο

End while EndIF

Figure 7 “TC Discovery phase” sub-scenario

4.1.2.2.1 TC hardware audit sub-scenario This sub-scenario is only available for TDM mode. The “TC hardware Audit” scenario is triggered by OMC-R:

• At the reception of a “TC-HW-Resynch” event alarm from BSC, in order to align the OMC-R database to the BSC database if TC SBL data only are updated as during the TC discovery phase

• At the reception of the “TC-HW-Resynch” event alarm from BSC autonomously sent during the BSC/TC periodic audit if MT120 RIT/RSS/capability have been changed (See IMO Ater Ref [A4]).

The “TC hardware Audit” scenario requests the TC configuration file to the BSC then requests the alarm/state audits at BSC level.

Description OMC BSC

The OMC-R requests the TC configuration file to the BSC BSC generates the configuration file with the content of DLS.

M-CONFIG-DISPLAY (TC) ————————————————————→


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 49/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Description OMC BSC BSC returns a file identifier M-CONFIG-DISPLAY-REPORT

←———————————————————— If the BSC is a G2 BSC then OMC-R opens an FTAM association with the BSC and reads this configuration file

E-FTAM-FILE-READ ————————————————————→

The file is retrieved by the OMC-R through FTAM.

E-FTAM-FILE-READ-REPORT ←———————————————————

Else /* The BSC is a Mx BSC*/ The file is retrieved by the OMC-R through FTP. The file path is predefined and known by the OMC-R (See [A17] for details).

End

FTP-FILE-READ ————————————————————→

OMC-R indicates transfer’s completion and updates if needed its database BSC deletes file and acknowledges transfer's completion.

M-FILE-READ ————————————————————→ M-FILE-READ-REPORT ←————————————————————

EndFor

The OMC-R requests the alarm and resource audit and the state audits at level BSC

OMC-BSC Alarm and resource audit (NSR) ————————ο OMC-BSC State audit (NSR) ————————ο

Figure 8 “TC hardware audit” sub-scenario

OMC-R Use case BSC Use case 5.1.1.5 OMC/BSC synchronisation 5.2.1.3 TC hardware audit


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 50/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.3 O&M Action «Discover a BSS» The aim of this O&M action is to execute a complete BSS audit for a BSS already added (see §5.1.1.1), in order to align the OMC-R database to the BSC database.

Case OMC Discovers an Ethernet BTS: 1) If OMC data base is populated (discover triggered in order to synchronize an existing OMC database; e.g. after a migration), OMC checks for BTS IP identifier If there is a group in OMC local data,

if yes, OMC checks if DHCP is already configured for this BTS,

if yes nothing else to do [i.e. if (BTS IP identifier, BTS IP address) exist in DHCP, no update to perform], else an error is raised (case of a BTS IP identifier already existing with another BTS IP address in the same group) and the DHCP location of that BTS is set to “not local to the OMC”.

If there is no group in local data for the BTS IP identifier, it means that the OMC doesn’t manage this BTS and the DHCP location is set to “not local to the OMC”.

2) If OMC data base is empty (discover triggered in order to populate an empty BSSIM data base), as the OMC cannot prejudge of the DHCP location, the DHCP location is set to “not local to the OMC”.

Case OMC Discovers an IPoverE1 BTS, from Peer Entities audit which is part of discover

BSS, the OMC knows the base IP address and the E1 size; the OMC checks if the BTS IP address is in the range of the E1,

if yes check DHCP and update it if necessary; if no, change the IP address in DHCP and BSC.

If the OMC discovers 2 identical BTS IP identifier in the BSS an error is raised. If the OMC discovers 2 identical BTS IP identifier in the same E1, the OMC doesn’t perform the DHCP update for the E1 and an error is raised.

4.1.3.1 Discover a BSS Scenario From B11 release, with the introduction of the RFD 221347 (Migration BSS: restart PM jobs before audit end), the BSS discover mechanism is reordered

Description OMC BSC/BTS Operator requests to discover a BSS

A-DISCOVER-BSS ————————————————→

A complete BSS audit is requested to the BSC and BTS(s).

Peer Entities Audit (TAS) ————————ο HW/SW Overall Audit ————————ο PM audit (PM) ————————ο Trace audit (TRACE) ————————ο Software version audit (SWM) ————————ο Hardware audit (HCM) ————————ο Logical parameter audit (LCM) ————————ο Date & Time synchronisation (TAS) ————————ο


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 51/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The OMC-R acknowledges the operator request

A-DISCOVER-BSS-ACK ←————————————————

Figure 9: “Discover a BSS” scenario

OMC-R Use case 5.1.1.4 Complete BSS audit

Sub-Scenario 4.1.3.1.1 Hardware Audit

sub-scenario 4.1.3.1.3 HW SW Overall Audit

sub-scenario


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 52/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.3.1.1 Hardware audit sub-scenario

Description OMC BSC/BTS The scenario ”BSC hardware audit” is invoked to retrieve data related to the G2 BSC hardware or data related to the MX BSC hardware, TCSM hardware and Abis transmission

BSC Hardware audit (HCM) ————————ο

FOR each BTSs with BTS-O&M Status not OPR The scenario “BTS hardware audit” is invoked ENDFOR

BTS Hardware audit (HCM BTS and ABIS part (Ref [A27]) ————————ο

Figure 10: “Hardware audit” sub-scenario

OMC-R Use case 5.1.1.4 Complete BSS Audit

Scenario

4.1.3.1.2 BSC hardware audit Sub-scenario

BTS hardware audit scenario (See HCM BTS and Abis part

[A27])


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 53/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.3.1.2 BSC hardware audit sub-scenario

Description OMC BSC The OMC-R requests the Peer Entities audit only if BSC hardware audit is explicitly triggered by operator

Peer entities audit (TAS) ————————ο

The OMC-R requests the HW SW overall type Audit (except in case of discover)

HW/SW Overall Type Audit ————————ο

For each following parameter group: • Cic-Atrk-Type • No7-Netw-Addr-Type • GPRS-BSC-Type • Bts-Id-To-Cell-Id-Type

The OMC-R requests this parameter group to the BSC

M-LOGICAL-PARM-DISPLAY (Param Group) ————————————————————→ M-LOGICAL-PARM-DISPLAY-REPORT

←————————————————————

EndFor

For each following configuration file:

• BSC hardware • TC Hardware • A-bis chains/rings hardware for G2

BSC • A-bis hardware for Mx BSC

The OMC-R requests this configuration file to the BSC BSC generates the configuration file with the content of DLS.

M-CONFIG-DISPLAY (Configuration File) ————————————————————→

BSC returns a file identifier M-CONFIG-DISPLAY-REPORT ←————————————————————

If the BSC is a G2 BSC then OMC-R opens an FTAM association with the BSC and reads this configuration file

E-FTAM-FILE-READ ————————————————————→

The file is retrieved by the OMC-R through FTAM.

E-FTAM-FILE-READ-REPORT ←———————————————————

Else /* The BSC is a Mx BSC*/ The file is retrieved by the OMC-R through FTP. The file path is predefined and known by the OMC-R (See [A17] for details).

End

FTP-FILE-READ ————————————————————→

OMC-R indicates transfer’s completion and updates if needed its database BSC deletes file and acknowledges transfer's completion.

M-FILE-READ ————————————————————→ M-FILE-READ-REPORT ←————————————————————

If the configuration file is the BSC HW and if it is a MX BSC then OMC-R requests the redundancy status

M-LOGICAL-PARM-DISPLAY (HW_LOG_Mapping_Type)

————————————————→ M-LOGICAL-PARM-DISPLAY-REPORT

←————————————————

EndFor

If it is a MX BSC then OMC-R launches MX BSC inventory

inventory BSC (Remote Inventory Ref [A28]) ————————ο

The OMC-R requests the alarm and state audits at level BSC

OMC-BSC Alarm and resource audit (NSR) ————————ο OMC-BSC State audit (NSR)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 54/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

————————ο

Figure 11: "BSC hardware audit" sub-scenario

OMC-R Use case BSC Use case 5.1.1.4 Complete BSS Audit 5.2.1.2 BSC hardware audit


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 55/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.3.1.3 HW/SW Overall Audit Sub-scenario

Description OMC BSC The OMC-R requests the HW/SW overall Audit

M-LogicalParam-Display (HW-SW-Overall-Type) →

BSC reports the information of the HW-SW Overall Type Group

The OMC-R updates its database

M-LOGICAL-PARM-DISPLAY-REPORT

←————————————————————

OMC-R Use case BSC use case 5.1.1.7 HW/SW Overall Audit 5.2.1.2 BSC Hardware Audit


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 56/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.4 O&M Action «TC Management» The aim of this O&M action allows the management of TC G2.5 with TCIF (also called TC G2.5IP). The management of TC G2.5 with TCIF allows:

• The declaration of a new TC G2.5 with TCIF (also named TC IP) • The TC removal in the OMC-R • Display TC Data • Update TC Information

4.1.4.1 TC declaration scenario This scenario is useful to declare a new TC G2.5 with TCIF (TC IP) from OMC-R. Remark: The TC G2.5 with TCIF (also called TC G2.5IP) is a TC G2.5 with TCIF subrack and plugged TCIF boards. A base TCIF is a TCIF with the STM1 daughter board connected on (product viewpoint). Another daughter board can be connected on; it is the IP daughter board.

Description OMC-R TC Operator requests to declare a new TC rack, giving its IP address and its optional TC Rack Name. If the TC Rack Name is not given in the request it will be generated by OMC-R.

A-TC-DECLARE ————————————————————→

OMC-R (DCN) requests only the list of BSC identifiers (couple of BSC number (also named BSC Id) and OMC master host Id) known in the TC. On the response from TC OMC-R begins the supervising and polling for the TC rack. TCIF SBL is created for supervised TCIFs and RIT.

GET-SNMP (TC SNMP MIB INTERFACE) Ο

OMC-R acknowledges the operator request

A-TC-DECLARE-ACK ←——————————————————————

Figure 12 “TC Declaration” scenario

OMC Use case TC Use case 5.1.1.20 TC Declaration 5.5.1.3 TC Declaration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 57/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.4.2 TC removal scenario Scenario Available for IP Transport feature This is a pure OMC-R scenario. With this scenario, the TC is undeclared from the OMC independently from BSC/TC configurations (TCSL can be kept alive). This allows OMC reorganization independently from the network.

Description OMC-R TC Operator requests to remove a TC rack in the OMC-R.

A-TC-REMOVAL ———————————————————————→

The OMC-R stops the concerned TC supervision and removes the supervising BSSIM for this TC rack.

In the OMC-R database, for the concerned TC, the TC information (TCSL endpoints, …) is removed.

OMC-R acknowledges the operator request. A-TC-REMOVAL- ACK ←———————————————————————

Figure 13 “TC Removal” scenario

OMC-R Use case 5.1.1.21 TC Removal

4.1.4.3 Display TC data scenario Scenario Available for IP Transport feature The aim of this O&M action allows displaying the supervising BSC (if defined), the related BSC and the associated end points for a specified TC rack.

Description OMC-R TC Operator requests to display TC data for a specified TC rack.

A-DISPLAY-TC-DATA ———————————————————————→

OMC-R reports the TC Data to the operator A-DISPLAY-TC-DATA-REPORT

←———————————————————————

Figure 14 “Display TC Data” scenario

OMC-R Use case 5.1.1.22 Display TC Data


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 58/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.4.4 Update TC Information scenario Scenario Available for IP Transport feature The aim of this O&M action allows getting the list of BSC Identifiers known by TC. This O&M action is used:

• In case during the TC rack declaration, there was a communication problem with the TC

• To refresh OMC-R in case new BSC have been associated to the TC by requests coming from TC terminal.

Description OMC-R TC

Operator requests to update TC information

A-UPDATE-TC-INFORMATION ———————————————————————→

OMC-R (DCN) requests the list of BSC Identifiers.

GET-TC-CONF (TC SNMP MIB INTERFACE) Ο

OMC-R acknowledges the TC info updating to the operator

A-UPDATE-TC-INFORMATION-ACK ←———————————————————————

Figure 15 “Update TC Information” scenario

OMC-R Use case 5.1.1.23 Update TC information


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 59/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.5 O&M action «TC Supervision» New O&M action – Available for IP Transport feature

4.1.5.1 Move TC supervision to another BSSIM scenario Scenario Available for IP Transport feature The aim of this O&M action allows changing the BSSIM for the supervision of one TC rack.

Description OMC-R TC Operator requests to move TC supervision to another BSSIM.

A-MOVE-TC-SUPERVISION-TO-ANOTHER-BSSIM ———————————————————————→

OMC-R acknowledges the operator request.

A-MOVE-TC-SUPERVISION-TO-ANOTHER-BSSIM-

ACK ←———————————————————————

Figure 16 “Move TC supervision to another BSSIM” scenario

OMC-R Use case 5.1.1.27 Move TC supervision to another BSSIM

4.1.5.2 Update TC supervision scenario Scenario Available for IP Transport feature The aim of this O&M action allows to set-up the TC supervision in case in the last time the OMC-R had failed to activate a supervising BSSIM (None of the BSC was fitting the selection criteria; one of the BSSIM was not reachable at supervision activation (This last case is a very rare case)).

Description OMC-R TC Operator requests to set-up the TC supervision.

A-UPDATE-TC-SUPERVISION ———————————————————————→

OMC-R acknowledges the operator request. A- UPDATE-TC-SUPERVISION -ACK

←———————————————————————

Figure 17 “Update TC supervision” scenario

OMC-R Use case 5.1.1.28 Update TC supervision


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 60/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.6 &M Action «TCSL endpoints resynchronisation» Available for IP Transport feature The aim of this O&M action allows updating TCSL endpoints once the TC has already been declared on the OMC. It is useful for BSS preparation to the IP transport mode or Move BSS scenario or declare/remove a TC IP rack in the BSC. Starting state: the OMC knows:

• Endpoints on BSC side from the TC-Peer-Entities logical parameter retrieved when playing the OMC/BSC HW audit scenario

• Endpoints on TC side from the TC declaration scenario, with the retrieved data being refreshed during the resynchronisation scenario.

4.1.6.1 Resynchronisation triggered with OMC scope scenario Available for IP Transport feature The scenario is given here in case the resynchronization is triggered with OMC scope. It is just simpler in case it is triggered with TC or BSC scope:

� With TC scope, every TCSL of the selected TC (possibly several) is synchronized (multi-BSC case).

� With BSC scope, every TCSL of that BSC is synchronized (multi-TC case). TC is the reference for TCSL endpoints in TC side and BSC is the reference for the TCSL endpoints in BSC side.

Description

OMC TC (several)

BSC (several)

The OMC-R (DCN) operator triggers the TCSL resynchronization.

A-TCSL –Resynchronisation

—————————————→

FOR EACH TC:

OMC-R (DCN) requests the list of BSC Identifiers

GET-TC-CONFIG (TC SNMP MIB INTERFACE) Ο

END FOR

OMC-R (OAM/DCN) establishes, per BSC, the list of connected TC racks. Then each BSSIM is given the set of associated TC

racks.

FOR EACH BSSIM: FOR EACH BSSIM


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 61/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Checks between the set of associated TC racks and

the previous set of associated TC racks.

For each TC linked to BSSIM

BSSIM requests the TC

side TCSL endpoints in TC GET-TC-CONFIG (TC SNMP MIB

DESCRIPTION) Ο

END FOR

FOR EACH TC

REMOVED:

The BSC side TCSL endpoints in TC are cleared.

Set-TCSL-ENDPOINT (BSC side TCSL endpoint) →

M-SET-TCSL-ENDPOINT-RESPONSE ←

END FOR END FOR

FOR EACH NEW TC: FOR EACH NEW TC:

The BSC side TCSL endpoints are setting in TC



END FOR

FOR EACH TC KNOWN: TC side TCSL endpoint and BSC side TCSL endpoint are compared.

IF TCSL differences:

The BSC side TCSL endpoints are updated in TC.



END IF

END FOR


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 62/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

OMC-R sends a LogicalParam-Modify

message with parameter TC-Peer-entities-type to

the BSC

M-LOGICALPARAM-MODIFY (TC-PEER-ENTITIES-TYPE) →

On the reception of M-LogicalParam-Modify message ( Modify TC characteristics) in BSC:

• For each TC removed: The BSC deletes TCSL SBL and TC-OM SBL and unsetting the TC side TCSL endpoint in BSC. • For each TC known: If in IP mode, the BSC updates the TC side TCSL endpoint, and the BSC side TCSL endpoint. • For each new TC: If in IP mode, the BSC creates TCSL SBL and TC-OM SBL, the TC side TCSL endpoint, and associated the BSC side TCSL endpoint.

M- LOGICALPARAM-MODIFY-REPORT ←

END FOR If the BSC is in IP mode, if a TCSL is created or modified or deleted, the BSC triggers the BSC-TC audit scenario.

BSC-TC AUDIT scenario (HCM)

Ο

OMC-R acknowledges the operator request.

A-TCSL-Resynchronisation-ACK ←

Figure 18 “Resynchronisation triggered with OMC scope” scenario

OMC Use case BSC Use case TC Use case 5.1.1.24 TCSL resynchronisation 5.2.1.10 Modify TC characteristics 5.5.1.12 TCSL Endpoint Update

(SET)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 63/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.6.2 BSC-TC Audit Sub-scenario Available for IP Transport feature The possible triggers are:

o From OMC: � BSS Mode Change � TCSL endpoint creation due to new TC rack (LPM TC-Peer-Entities when the

BSC is in IP mode) � BSS SW Activate � Init TC-OM (TCSL goes to IT and TC-OM is not OPR, or TCSL IT and TC-OM

goes to IT) � BSC restart (IMO) � BSC reset (IMO BSC, TC and Ater part Ref [A4]) � Change Atermux from PS to CS � Program Ater transmission (HCM BSC, TC and ATER part) � On TC resynchronization, for every TC being not OPR � Modify TC characteristics (LPM TC-Peer-entities when the BSC is in IP mode), if

anything has changed o From BSC

� Periodical Audit o From TC:

� The reception of the M-TC-AUDIT-NEEDED message from the TC (sent when applying TC NEM extension/reduction screen).

Description

OMC

BSC TC

Trigger from OMC-R or TC launches the scenario.

Trigger from OMC Or from TC →

For each TC rack the BSC is associated to: BSC requests TC audit to discover TC IP endpoints and the installed TC hardware. At the same time BSC indicates to TC the expected MT120 SW version and the TCSL version. In TC even if the expected MT120 SW is not available, TC will try to download the MT120 SW, preload and activate it.

M-TC-AUDIT-REQ (TCSL version, MT120 SW version, code server) →

The TC persists the Qmux link necessary data to be able to react on possible future TC NEM trigger for going back to TDM mode. If MT120 SW version is available and not running, TCIF activates it on MT120.

The TC reports:

• TC-MUX Traffic Endpoint • TC-NONMUX Traffic endpoint. • Per configured MT120 board:

o The Atermux number o RIT Type o MT120 capabilities o Rack number/shelf

number/slot number o SW activation result

• TC Hardware Family (represents the TC rack generation)

M-TC-AUDIT-REP ←


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 64/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

EndFor BSC waits maximum Ns (in order to allow TC racks to be audited in // and have only one configuration message per TC rack. This comes from the fact that for a given BSC, every TC rack knows the boards of every other one). When all TC racks have been audited BSC processes the received data

IF no MT120 reported by any TC rack BSC stops.

TC-OM SBL and TCSL SBL remain IT. EndIF IF at least one MT120 reported by all TC rack BSC raises event alarm if needed (See 5.2.1.9)

For all the TC SBL corresponding to the MT120 reported, The BSC updates the TC SBL conf (SBL creation/deletion, RIT info) as well as the BSC one (for TC related SBL of the BSC model, such as CS-ATERMUX). Atermux pools are updated (one pool per TC rack that depends on MT120 and Atermux).

BSC triggers resource blocking/unblocking to MSC if necessary.

For Each TC the BSC is associated to: IF BSC gets at least one MT120 reported M- TC-CONF-REQ

→

The BSC sets: • The MT120 table, giving for every (BSC associated) MT120 of every TC:

- the NONMUX endpoint of its rack. • If “A signalling over IP” not activated, the SS7 parameter • The legacy TC parameters

If “A signalling over IP” is not already activated, the “SS7 Signalling Gateway (SG) endpoint” parameter is reported in the TC configuration report message.

M-TC-CONF-REP ←

BSC launches the TC-ALARM-AUDIT to request the actual active alarms for each MT120.

M-TC-ALARM-AUDIT (Network Supervision) Ο

When the configuration and alarm audit are finished, the BSC triggers the BTS to primary TC mapping algorithm (see HCM BTS and Abis part) and updates the BTS accordingly.

EndIF End for


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 65/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The OMC-R is informed of the TC-OM SBL state change.

M-SBL-State-Change-Report (TC-OM SBL) ←

If the BSC or TC SBL configuration has been updated then:

The BSC triggers an OMC/BSC HW audit – that includes TC ones.

M-ALARM-REPORT (BSC,HW-RESYNC,EVENT) ←

On reception of the M-ALARM-REPORT (BSC, HW_Resynch, event) from the BSC, the OMC-R request automatically the following audits:

• Peer entities Audit • BSC hardware audit

(Hardware + TC); • Alarm audit; • State audit.

(Included in OMC/BSC synchronization scenario (HCM BSC, TC and Ater part))

OMC/BSC synchronisation (HCM BSC, TC & ATER part) Ο

EndIF

Figure 19 “BSC-TC Audit ” sub-scenario

BSC Use case TC Use case 5.2.1.9 BSC-TC Audit 5.5.1.13 TC Audit

5.5.1.14 TC Configuration Update


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 66/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.7 O&M Action « MT 120 Adding/Removal » The aim of this O&M action allows the MT 120 adding or removal in TC. 4.1.7.1 Activate new G2.5 TC standard configuration This scenario is available with TC G2.5 and for all types of MT120 boards: Legacy MT120, MT120-NB or MT120-WB. This scenario is realised with a TC local terminal.

Description BSC Terminal

BSC TC TC Terminal

Operator adds or removes MT 120in TC rack (Not mandatory).

Operator from TC terminal requests to add or remove a MT120 in the TC G2.5

A-ACTIVATE-CONF-TC ←

Report about the outcome of the operation

→ Then the operator will launch the “activate new MX BSC/TC standard configuration” (HCM) from the BSC local terminal to take into account the new TC composed pieces of equipment in the BSC.

Activate new MX BSC/TC standard configuration (HCM Ater part) Ο

Figure 20 “Activate new G2.5 TC standard configuration ” scenario

TC Use case

5.5.1.1 Activate new G2.5 TC standard configuration

4.1.7.2 Activate new G2.5 TC with TCIF standard configuration This scenario is available with G2.5 TC with TCIF and for all types of MT120 boards: Legacy MT120, MT120-NB or MT120-WB. This scenario is realised with a TC NEM.

Description BSC Terminal

BSC TC TC NEM

Operator adds or removes MT 120 in TC rack (Not mandatory).

Operator from TC NEM requests to apply the updated MT120 configuration on the TC for one to n MT120 (new TC IP standard configuration)

A-ACTIVATE-CONF-TC (MT120 LIST) ←

TC finds the concerned MX BSC(s) (MX BSC where the MT120 is (are) connected).

For the MT120 associated to BSC in TDM mode:

For the MT120 associated to BSC in TDM mode


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 67/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Report about the outcome of the operation A-REPORT →

The operator must launch the “Activate new MX BSC/TC standard configuration” (HCM Ater part) from the BSC local terminal to take into account the new TC composed pieces of equipment in the MX BSC.

Activate new MX BSC/TC standard configuration (HCM Ater part) Ο

EndFor EndFor For the MT120 associated to BSC in IP mode

For the MT120 associated to BSC in IP mode

TC sends the message “M-TC-Audit-NEEDED” to request the “BSC-TC Audit”.

M-TC-AUDIT-NEEDED ←

On the reception of the TC_AUDIT-NEEDED fromTC, on each TC rack, which the MX BSC is associated to the BSC-TC AUDIT scenario, is launched.

BSC-TC AUDIT (HCM) 0

EndFor

EndFor

Figure 21 “Activate new G2.5 TC with TCIF standard configuration ” scenario

BSC Use case TC Use case 5.2.1.9 BSC-TC Audit 5.5.1.2 Activate new TC G2.5 with TCIF standard

configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 68/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.8 O&M Action «BSC/GPU IP association» New O&M Action – Available for IP transport feature The aim of this O&M action allows getting the IP-GSL Endpoints per GPU in BSC. This O&M action is applicable:

• For a TDM BSC in the scope preparation phase of the IP transport change mode • For a IP BSC, for instance when associating a new GPU to that BSC

This scenario is composed by:

• BSC/GPU IP association Sub-scenario • Alignment of the GSL configuration on MFS side Sub-scenario. Operator triggers this sub-scenario described in document OMC/MFS: Ater & Gb Domain [6].

START

BSC/GPU IP association Sub-scenario

Alignment of GSL configuration on MFS side

(OMC/MFS: Ater&Gb Domain [6])

END

Figure 22 “BSC/GPU IP association” scenario

4.1.8.1 BSC/GPU IP association Sub-scenario Available for IP transport feature It is possible to update the IP-GSL endpoints in TDM mode as a part of preparation phase of BSS transport mode change.

Description

OMC BSC MFS

The OMC-R operator triggers the downloading of The IP-GSL endpoints for all GPU of this MFS on all BSS associated to this MFS.

A-BSC/GPU IP Association

—————————————→

For each concerned BSC

M-LogicalParam-Modify (MFS-

Peer-Entities) →


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 69/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• If the BSC is in IP mode the BSC instantiates the GSL SBL or deletes the GSL SBL. • Else (BSC in TDM mode) the GSL SBL are registered in BSC DLS

M-LogicalParam-Modify-Report ←

End For OMC-R acknowledges the operator request.

A-BSC/GPU IP Association-Ack

←

Figure 23 “BSC/GPU IP association” sub-scenario

OMC Use case BSC Use case

5.1.1.25 BSC/GPU IP association 5.2.1.11 Modify MFS characteristics

4.1.9 O&M Action «Change BSS Transport Mode on BSC side» Available for IP Transport feature The aim of this O&M action allows changing the BSS Transport Mode on BSC side:

• From IP to TDM • From TDM to IP.

The following scenarios only describe the actions towards the BSC. The requested Transport Mode is also to apply on MFS side. The case is described in “OMC/MFS: Ater & Gb Domain” document [6].

4.1.9.1 Change BSS Transport Mode from TDM to IP on BSC side scenario Available for IP Transport feature Description

OMC BSC TC MFS

Change mode preparation : While the TDM mode the operator has to configure the Atermux either as pure CS Atermux either as dedicated GPRS atermux.

The OMC-R (BSSUSM) operator triggers “Transport mode switch activation” from TDM to IP for the selected BSC

A-BSS-TRANSPORT-MODE-SWITCH (IP Mode) —————————————→


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 70/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

OMC-R checks: • the BSC is Mx Generation • TCSL endpoints are configured for every TC the BSC is connected to • IP-GSL endpoints are configured for each GPU • No CS/PS mixed Atermux is allowed • BSS-TEL is disabled

After the successful checks the OMC-R sends the message M-BSS-Transport-Mode-Switch to BSC to change BSS transport mode from TDM to IP in BSC.

M-BSS-TRANSPORT-MODE-SWITCH (IP Mode) ———————→

In BSC

Transmission related changes: - Creation of N TCSL SBL (one SBL per associated TC rack): NEQ �

IT. - Creation of N TC-O&M SBL (one SBL per associated TC rack): NEQ

� IT. - Deletion of the obsolete TC side SBLs: SM_ADAPT[TC],

TC_ADAPT, TC16, SBLs: IT/FLT/OPR � NEQ. Signalling SS7 related changes:

- If “A signalling over IP” is not activated’, Re-configure N7 SBL configuration from TDM to IP mode (i.e. the N7 low speed or high speed are kept with their current configuration but the path is switched from [OMCP <–> TPGSM(V3)] to [OMCP <—> TC]). BSC side SS7 parameters required for IP mode are fixed in the DLS (timers, BSC TCP/SCTP port numbers, OMCP and CCP IP addresses). TC side parameters are audited from the TC later.

Signalling GSL related changes: - IP GSL SBL are instantiated. - TDM GSL SBL are removed.

A channels type change (TS14-TS15-TS16)

M-BSS-

TRANSPORT-MODE-SWITCH-REPORT ←—————


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 71/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

On the sending of the message M-BSS-TRANSPORT-MODE-SWITCH-REPORT to OMC: The BSC then autonomously resets (BSC reset includes the resynchronization with MSC-See IMO BSC, TC and Ater part Ref [A4]). At the end of the BSC reset (See IMO BSC, TC and Ater part Ref [A4]) BSC sends PM-Global-Stop-Report to OMC. On reception of this message OMC triggers the PM audit and PMs are restored.


A-BSS-TRANSPORT-MODE-SWITCH-ACK (IP mode)

←————————————

The complete BSC-BTS Audits are performed in parallel for all BTSs and – if needed – a BTS-HW-Resync alarm report is sent to the OMC-R after all audits are finished. In parallel with the BSC-BTS audits and due to the BSC reset, the BSC plays a telecom reset for blocking/unblocking of A channels.

BTS Hardware Audit (HCM) Ο

Establishment of the TCSL protocol layer.

In parallel (once the BSC has restarted) the operator triggers the change mode activation from TDM to IP on MFS side.

Change BSS Transport Mode, MFS side (OMC/MFS: Ater & Gb Domain [6]) 0

The BSC triggers the BSC-TC AUDIT scenario.

BSC-TC AUDIT (HCM BSC, TC AND ATER PART) 0

On TC, TDM switching on TCIF is now used for the MT120 of that BSC to allow AterMux pooling.

N7- ESTABLISHMENT (TELECOM DOC) 0

Figure 24 “Change BSS Transport Mode from TDM to IP on BSC side” scenario

OMC Use case BSC Use case 5.1.1.26 BSS Transport Mode Switch 5.2.1.12 BSS Transport Mode Switch


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 72/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.9.2 Change BSS Transport Mode from IP to TDM on BSC side scenario Available for IP Transport feature Description

OMC BSC TC MFS

The OMC-R (BSSUSM) operator triggers “Transport mode switch activation” from IP to TDM for the selected BSC

A-BSS-TRANSPORT-MODE-SWITCH (TDM Mode) —————————————→

OMC-R sends the message M-BSS-Transport-Mode-Switch to BSC to change BSS transport mode from IP to TDM in BSC.

M-BSS-TRANSPORT-MODE-SWITCH (TDM Mode) ———————→

In BSC

Transmission related changes: - Deletion of TCSL SBL (one SBL per associated TC rack): ->NEQ - Deletion of TC-OM SBL (one SBL per associated TC rack): ->NEQ - For the resources that were defined before previous TDM to IP

change, recreation of the TDM TC side SBL: SM_ADAPT[TC], TC_ADAPT, TC16 SBL: ->IT

Signalling SS7 related changes:

- If “A signalling over IP” is not activated, Re-configure N7 SBL configuration from IP to TDM mode (i.e. the N7 low speed or high speed are kept with their current configuration but the path is switched from [OMCP <–> TC] to [OMCP <—> TPGSM (V3)]).

Signalling GSL related changes:

- IP GSL SBL are removed. - TDM GSL SBL are instantiated back from DLS when compatible with

Atermux configuration.

Recovery of ACH channel type related to Qmux / Alarm Octet


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 73/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

On the sending of the message M-BSS-TRANSPORT-MODE-SWITCH-REPORT to OMC: The BSC then autonomously resets (BSC reset includes the resynchronization with MSC- See IMO BSC, TC and Ater part Ref[A4]). At the end of the BSC reset (See IMO BSC, TC and Ater part Ref [A4]) BSC sends PM-Global-Stop-Report message to OMC. On reception of this message OMC triggers the PM audit and PMs are restored. The complete BSC-BTS Audits are performed in parallel for all BTSs and – if needed – a BTS-HW-Resync alarm report is sent to the OMC-R after all audits are finished.

M-BSS-TRANSPORT-MODE-SWITCH-REPORT ←—————


A-BSS-TRANSPORT-MODE-SWITCH-ACK

←————————————

Establishment of BSC/TC-Qmux layers.

On TC, TDM switching on TCIF is no more used for the MT120 of that BSC.

IF “A SIGNALLING OVER IP” NOT ACTIVATED,

TDM-N7- ESTABLISHMENT (TELECOM) 0

Figure 25 “Change BSS Transport Mode from IP to TDM on BSC side” scenario

OMC Use case BSC Use case

5.1.1.26 BSS Transport Mode Switch 5.2.1.12 BSS Transport Mode Switch


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 74/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.10 O&M Action «STM1 interfaces (BSC/TC) Declaration/Undeclaration» The aim of this O&M action is the declaration or/and undeclaration of the STM1 interfaces.

4.1.10.1 STM1 interfaces (BSC/TC) declaration/undeclaration scenario The STM-1 feature is optional from a commercial viewpoint. Operators buy the feature with a maximum number of STM1 interfaces per OMC. This maximum number concerns STM1 interfaces generally speaking, that means taking into account STM1 links of all the declared TC but also BSC ones. An STM1 interface represents a pair of protected STM1 link. Optional feature data are stored in the OMC-R in an encoded configuration file.

Operator OMC-R TC/BSC − A_STM1DECLARE (List of

STM-1 interface per NE) →

OMC-R checks that:

• The number of STM-1 interface, taking that new declared and undeclared into account in all BSC and TC, is equal or smaller to what is allowed by the licence.

• The new undeclared STM1 interfaces are not ‘in use’. • If the NE type is BSC

• The BSC have both TPGSM with STM1 capability

• The OMC flags the interfaces to be removed

For each impacted NE IF the NE type is TC IF the NE type is

TC IF (the STM-1 declaration/undeclaration is allowed) − SET-SNMP (list of STM-1

interface) →

The TC compares the received

list to the current one to know the new declared interfaces and the one to be undeclared. For each new declared interface The TC creates the required STM1-ITF and associated STM1-TTP. EndFor For each new undeclared interface The TC removes the STM1_ITF and associated STM1-TTPs. EndFor

← SET -SNMP-RESP −


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 75/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Operator OMC-R TC/BSC IF the SET-SNMP-RESP is OK

GET-SNMP (STM1itf) → For the new declared STM-1 interfaces, SBL type STM1-ITF

has to be created in (unlocked, disable, dependency) state and SBL-TTP has to be created in (locked, ., .)’state. For the new undeclared STM-1 interfaces, OMC-R removes the required SBL STM1 Interfaces and associated SBL STM1-TTPS. Alarms on those STM1-TTPs are cleared. OMC-R builds the new Functional view.

ELSE (SET-SNMP-RESP is NOK) OMC keeps the current state of STM-1 Interfaces

(declared/undeclared). OMC keeps the current number of STM-1 Interfaces.

ENDIF ENDIF ENDIF ENDIF IF the NE type is BSC IF the NE type is

BSC IF (the STM-1 declaration is allowed) −

M_STM1ACTIVATE (list of STM-1 interface) →

The BSC compares the list to the current

one to know the new interfaces and the one to be removed. The required SBL STM1-ITF and STM1-TTPs are created or deleted depending on the case.

←

M_STM1ACTIVATE_REP (Status, list of added SBL) −

IF (the status is NOK) OMC-R triggers a BSC audit ELSE (the status is OK) OMC-R creates the added reported SBLs and removes the

flagged ones. Then builds the new HW equipment view and Functional view

ENDIF ENDIF ENDIF ENDIF


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 76/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Operator OMC-R TC/BSC ENDFOR ← A_STM1DECLARE_REP

(Status) −

End of the scenario

Figure 26 “STM1 interfaces (BSC/TC) Declaration/Undeclaration” scenario

OMC Use case BSC Use case TC Use case 5.1.1.29 STM1 interfaces (BSC/TC)

Declaration/Undeclaration 5.2.1.14 BSC STM1 interface

Activation 5.5.1.4 TC STM1interface Declaration/Undeclaration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 77/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.11 O&M Action « BSC/TC Plug identification information » The aim of this O&M action is the plug identification information display for the TC or for the BSC. The plug identification is useful for operator to know what plug is connected, the plug type.

4.1.11.1 TC Plug identification information display scenario Operator TC NEM TC

− A_PLUGIDENT () →

− GET-SNMP (For TCIF1

plugident1,plugident2,plugident3,plugident4 ; For TCIF2

plugident1,plugident2,plugident3,plugident4)

→

TC retrieves the plug(s) connected and

the associated motherboard TCIF, the plug identification for each connected plug.

←GET-SNMP_REP (Plug(s)

connected, associated motherboard TCIF, PlugIdentification for all SFP connected)

−

TC-NEM displays the plug identification information for all SFP

reported by TC

← A_PLUGIDENT_REP (Status) −

End of the scenario

Figure 27 “TC Plug identification Information display” scenario

TC-NEM Use case TC Use case 5.4.1.7 TC Plug identification information display 5.5.1.9 TC Plug identification information


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 78/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.11.2 BSC Plug identification information display scenario Operator BSC Terminal BSC

− A_PLUGIDENT () →

− A_PLUGIDENT () → BSC retrieves the plug identification for

all SFP connected. ←M_PLUGIDENT_REP

(PlugIdentification) −

BSC terminal displays the identification for all SFP reported by

BSC.

← A_PLUGIDENT_REP (Status) −

End of the scenario

Figure 28 “BSC Plug identification Information display” scenario

BSC Terminal Use case BSC Use case 5.3.1.12 BSC Plug identification information display 5.2.1.21 BSC Plug identification information


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 79/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.12 O&M Action « Change N°7 Mode from LSL to HSL or HSL to LSL» The aim of this O&M action allows to modify the N°7 mode. From B10, for MX BSC, N°7 links can be configured in two ways: - Either in LSL mode ‘Low speed Signalling Link’, which means usage of 64k channels on the first 16 Atermux, as it was supported till then - Or, in HSL mode ‘High speed Signalling Link’, which means usage of two full PCM links to convey N°7. Change between the two modes is done from BSC local terminal. Depending on the IP/TDM mode of the BSS, the connection of the N°7 links is different. HSL Connection in TDM Mode: In TDM mode there is no need to demultiplex or to transcode the HSL link. So to avoid wasting TC boards HSL is connected directly from BSC to MSC.

BSC MSC TC

HSL 2

HSL 1

ATERMUX Interface A

HSL Connection in IP Mode: In IP mode the MTP2 function is in the TC.

Ater A

MM

RR BSSMAP BSSMAP

BTSM

LapD M2UA

TID SCTP

IP [ML] PPP HDLC

E1/ethernet ethernet MTP1 / E1

MTP2 MTP2

SCTP M2UA

MSC MxBSC with TP-GSM->TPIP TC G2.5 IP (with TCIF)

MTP1 / E1

SCCP SCCP MTP3 MTP3

UDP IP

CC

DTAP DTAP

SM, SMS

IP

ethernet


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 80/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

This implies that in IP mode HSL link must be connected from TC to MSC. BSC MSC TC

HSL 2

HSL 1

ATERMUX Interface A

Ethernet

4.1.12.1 Change N°7 Mode from LSL to HSL or from HSL to LSL scenario

Description BSC MSC From BSC local terminal, operator triggers the N°7 mode change

A-CHANGE-N°7-MODE →

BSC updates accordingly the BSC data, applying the engineering rules corresponding to the target configuration.

BSC marks the impacted TC SBL BSC automatically resets to bring in force the configuration from BSC side, leading to a reset towards MSC. At the end of the BSC reset (See IMO BSC, TC and Ater part Ref [A4]) BSC sends PM-Global-Stop-Report message to OMC (See IMO BSC, TC and Ater part Ref [A4]). On reception of this message OMC triggers the PM audit and PMs are restored.

RESET MSC (TELECOM) Ο

After BSC reset (See IMO BSC, TC and Ater part Ref [A4]), BSC scans the DLS for all transmission SBL’s that need to be configured and handles them.

BSC acknowledges operator request.

A-CHANGE-N°7-MODE-ACK ←←←←

It is expected that operator triggers BSC HW audit to line-up OMC/MFS on the new configuration.

Figure 29: “Change N°7 Mode from LSL to HSL or from HSL to LSL” Scenario Remark: Besides this system scenario, there are some cablings to be installed and some actions to do on MSC side (refer to [A25] NMPP scenarios for more details).

BSC Use case 5.2.1.8 Change N°7 Mode


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 81/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.1.13 O&M Action « Modify BSC SS7 Transport Mode » The aim of this O&M action allows modifying BSC SS7 Transport Mode. When A signalling over IP is enable that allows activating the A signalling over IP transfer mode. The N7 signalling is transferred over IP by M3UA. The BSC is connected to MSC directly.

4.1.13.1 Modify BSC SS7 Transport Mode scenario

Description OMC BSC Operator requests to modify the SS7 Transport Mode.

A-MODIFY-SS7-TRANSPORT-MODE →

If A-signalling over IP is requested, OMC checks that A signalling over IP is licensed.

OMC sends the message M-LogicalParam-Modify to BSC

M-LOGICALPARAM-MODIFY (No7-NETw-Addr-TYPE) →

BSC checks the possibility to roll-back, if it is requested.

BSC change the DLS. BSC marks the impacted TC SBL as “to be reconfigured”

BSC reports to the OMC M-LOGICALPARAM-MODIFY-

REPORT ←

BSC automatically resets to bring in force the configuration from BSC side, leading to a reset towards MSC to perform the telecom resynchronization with MSC. At the end of the BSC reset (See IMO BSC, TC and Ater part Ref [A4]) BSC sends PM-Global-Stop-Report message to OMC (See IMO BSC, TC and Ater part Ref [A4]). On reception of this message OMC triggers the PM audit and PMs are restored.

RESET MSC (TELECOM) Ο

After BSC reset, BSC scans the DLS for all transmission SBL’s that need to be configured and handles them.

OMC acknowledges operator request. A-MODIFY-SS7-TRANSPORT-

MODE-Rep ←←←←

It is expected that operator triggers BSC HW audit to line-up OMC/MFS on the new configuration.

Figure 30: “Modify SS7 Transport Mode” scenario

OMC-R Use case BSC Use case

5.1.1.30 Modify BSC SS7 Transport Mode 5.2.1.13 Modify BSC SS7 Transport Mode


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 82/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2 Service S-HCM-PCMConfig

The O&M actions of this service supported by more than one subsystem are: • Ater / AterMux configuration for GPRS • Configure Ater • TC STM1 Configuration Management • BSC STM1 Configuration Management 4.2.1 O&M Action «AterMux configuration for GPRS»

The aim of the O&M action is to configure (create or suppress or modify) an AterMux supporting GPRS. The following table explains the two different kinds of configuration for Ater transmission:

SM-ADAPT SBL TRAU-CP SBL

Trans-port

Mode traffic signalling

BSC side (Only for G2

BSC) TC side

TC side

TDM CIC + GIC (granularity from 0% to 100%)

None/N7/ GSL/N7+GSL (*)

yes yes No Mixed CS/GPRS AterMux

IP CIC (granularity to 0% (CS))

None no no yes

TDM GIC only

None//GSL yes no No

Dedicated GPRS

AterMux IP GIC only (granularity to 100%)

None no no no

(*): N7 only for AterMux 1 to 16 And the following figure lists the possible Ater configuration changes:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 83/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Remark: transitions from Mixed to Dedicated 0% or from Dedicated 0% to Mixed are not foreseen by specifications. In case of G2 BSC they are not locked by OMC-R, but they are rejected by OMC-R in case of Mx BSC. From B10 CR A20-157555, the MFS can be clock synchronised from the Mx BSC. From B10 CR A20-224770, in order to avoid loop, the BSC uses exclusively pure CS Atermux as clock source. A pure CS Atermux is defined as: - AterMux-GPRS-Usage = 'Mixed-CS-GPRS' - Ach-GPRS-CS = 0 (CS) for each A-trunk channel. In order to have BSC transmission configuration internally maintained, the OMC systematically sends the M-CONFIG-SIG-ATERMUX message to the Mx BSC. Restriction: Two (pure) CS Atermux must be kept to connect to the TC per BSC to ensure the clock synchro source. So, it is recommended to the operator to not cable Atermux 1 and Atermux 2 to the MFS.

Scenario/Use case Description Scenario: 4.1.1.1Activate new G2 BSC/TC standard configuration scenario

With this scenario the operator extend or reduce the number of Atermux equipped at TC side.

Scenario: 4.1.2.1Activate new MX BSC/TC standard configuration scenario

With this scenario the operator extend or reduce the number of Atermux equipped at TC side.

Scenario: 4.2.1.1 Modify GPRS granularity

With this scenario the OMC operator realises in TDM transport mode the modification of the GPRS granularity from/to 0% 12.5%, 25%, 50%, 75%, 100% of GPRS with or without GSL on an already equipped AterMux (TC SBLs <> NEQ) and in IP transport mode the modification of the GPRS granularity from/to 0% 100% of GPRS.

Scenario: 4.2.1.3 Set-up (respectively unset) of a dedicated GPRS AterMux

With this scenario the OMC operator realises an installation (respectively a un-installation) of a dedicated GPRS AterMux when there is no equipped corresponding TC SBL.

Scenario: 4.2.1.4 Modify a Mixed AterMux into a dedicated GPRS AterMux

With this scenario the OMC operator transforms a pure CS Ater Mux or a mixed CS/GPRS AterMux (only in TDM transport mode) into an AterMux dedicated to GPRS

Scenario : 4.2.1.2 Modify a dedicated GPRS AterMux into a mixed CS/GPRS AterMux

Only available in TDM transport mode: With this scenario the OMC operator transforms a dedicated GPRS AterMux into a mixed CS/GPRS AterMux or into a pure CS Atermux with equipped TC SBL

Pure CS (Mixed 0%)

Mixed CS/GPRS (Mixed x% (x>0%))

GPRS Only (Dedicated 100%)

Not used (Dedicated 0%)

� TC Extension � TC Reduction � Modify GPRS granularity � Set-up dedicated GPRS link � Unset dedicated GPRS link � Modify Mixed into dedicated � Modify Dedicated into Mixed

� � � � �

� � �

�

� �

�ou� �


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 84/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Flag TC transparency The Flag TC transparency is only used in TDM Mode. If Flag TC transparency is set to true: timeslots can be used for other thing than CS (circuit) and must not be transcoded. If Flag TC transparency is set to false: all the TS except the signalling TS are transcoded. For mixed CS/GPRS Atermux there are two possibilities for the Gb routing:

If the Gb interface is routed through the TC, it is mandatory to disable the speech transcoding inside the TC for the timeslots that carries the Gb interface: the flag TC transparency must be set to TRUE for this Atermux. This point is not checked by the system, neither by BSC nor by OMC: it is up to the operator to guaranty this consistency. If the Gb interface is routed directly from MFS to the SGSN, some timeslots are not used and we do not care if they are transcoded or not.

CS/GPRS BSC TC MFS CS/unused

Gb SGS

BSC TC MFS CS/Gb

Gb

SGSN

2. Gb Interface through TC

1. Gb Interface direct to SGSN

MSC

CS/Gb MSC

CS/unused

CS/GPRS


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 85/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

If the Flag TC transparency is set to true, MT120 detects the AIS 512K if it finds the AIS pattern in all the usable TS. If the Flag TC transparency is set to false, MT120 considers all the TS for detect the AIS 512K alarm. Like useless timeslots are filled by MFS with idle pattern whatever the status of the Atrunk at DTC side. To allow the AIS 512K detection by the MT120, the TC transparency must be set to TRUE. The G2 TC board does not use AIS 512K but use the alarm octet. It does not care if useless timeslots are transcoded or not. So, it is advised to customer to set the TC transparency to TRUE any time. But to avoid useless G2 TC programming (around 10 minutes) the OMC allows the operator to set TC transparency to FALSE only for G2 TC. Remark: because the TC transparency set to FALSE was allowed for MT120 in B7, it is possible to have such configuration after the migration in B8. In that case, the TC transparency flag is forced to TRUE by the OMC as soon as the operator requests a change of granularity of this Atermux. Further actions towards the MFS The following scenarios only describe the actions towards the BSC. In all these cases, after having managed the BSC side, the operator has to trigger the further alignment of the MFS. The MFS becomes then aware of: • The new set of configured GIC • The new set of CIC that the MFS has to cross-connect towards the TC. For more details, refer to the use case "Configure Atermux" in the document OMC/MFS Ater & Gb Domain [A11].


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 86/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.1.1 Modify GPRS granularity Scenario

Description OMC BSC Operator defines a new GPRS/CS granularity (maybe with add or remove GSL only in TDM transport mode)

A-MODIFY-GPRS-GRANULARITY ————————————————→

IF in TDM Tranport Mode

IF GPRS granularity decreases

OMC disables the Ach which become CS. They must stay OPR as long as the MFS is not aligned)

ENDIF

ENDIF

—————ο N x Disable ACH (IMO)

OMC sends the sharing CS(CIC) /GPRS (GIC/GSL) M-LOGICAL-PARAM-MODIFY

(GPRS-BSC-Type) ————————————————————→

M-LOGICAL-PARAM-MODIFY-REPORT

←————————————————————

M-LOGICAL-PARAM-MODIFY (Cic-Atrk-Type) ————————————————————→

M-LOGICAL-PARAM-MODIFY-REPORT ←————————————————————

IF in TDM Transport Mode IF GSL Lapd modification(add or remove)

HW resynchronization is needed

OMC-R invokes automatically ‘BSC HW/Alarm/resources/state audits’ (1) ENDIF

ENDIF

M-ALARM-REPORT (BSC, HW-resynch,Event) ←———————————————————— ———ο BSC HW audit (HCM)

Then the transmission equipments have to be reconfigured:

IF the BSC is a G2 BSC Then

IF GSL Lapd modification (add or remove) Then Need to disable (if not already yet) the SM-ADAPT (BSC) and then init it to apply the transmission modifications EndIF

Else If the BSC is a MX BSC Then

IF Mx BSC in TDM Transport Mode The OMC-R requests the Signalling configuration

———ο Disable SM-ADAPT[BSC] (IMO) ———ο Init SM-ADAPT[BSC] (IMO) M-CONFIG-SIG-ATERMUX ———————————————————→ M- CONFIG-SIG-ATERMUX -REPORT ←———————————————————

IF (TC-transparency flag = TRUE or TC-Transparency flag was TRUE and being set


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 87/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

to FALSE by the operator) Need to disable (if not already yet) the SM-ADAPT (TC) and then init it to apply the transmission modifications

IF (TC-G2 boards) Need to disable (if not already yet) the TC-ADAPT and then init it to apply the transmission modifications

ENDIF ENDIF

———ο Disable SM-ADAPT[TC] (IMO) ———ο Init SM-ADAPT[TC] (IMO) ———ο 4 x Disable TC-ADAPT (IMO) ———ο 4 x Init TC-ADAPT (IMO)

EndIF ENDIF Operator gets back the answer to his GPRS/CS granularity reconfiguration request

A-MODIFY-GPRS-GRANULARITY-REPORT

←—————————————————

(1) alarm, resource and state audits can be performed in parallel with the rest of the scenario.

Figure 31: “Modify GPRS granularity” scenario

OMC-R Use case BSC Use case 5.1.1.11 Modify GPRS granularity 5.2.1.4 Modify AterMux GPRS

5.2.1.5 Ater Signalling Configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 88/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.1.2 Modify a dedicated GPRS AterMux into a mixed CS/GPRS AterMux Scenario This scenario is only available in TDM transport mode.

Description OMC BSC Operator installs a mixed GPRS/CS or a pure CS Ater mux instead of an existing dedicated Atermux for GPRS (maybe with add or remove GSL)

A-MODIFY-DEDICATED-INTO-MIXED-ATerMUX

—————————————————→

IF GPRS granularity requested implies that Ach will be supported for CS

OMC disables the Ach which become CS. They must stay OPR as long as the MFS is not aligned)

ENDIF

—————ο N x Disable ACH (IMO)

OMC sends to the BSC that the AterMux is no more dedicated (AterMux-GPRS-Usage=mixed-CS-PS) and also the sharing CS(CIC) /GPRS (GIC/GSL)

M-LOGICAL-PARAM-MODIFY (GPRS-BSC-Type) ————————————————————→


←————————————————————



A HW re-synchronisation is needed (N7 SBL created if Atermux1..16, SBL of TC created, maybe GSL add/delete) OMC-R invokes automatically ‘BSC HW/Alarm/resources/state audits’ (1)


Then the transmission equipments have to be reconfigured:

If the BSC is a G2 BSC then IF GSL Lapd modification (add or remove)

Need to disable (if not already yet) the SM-ADAPT (BSC) and then init it to apply the transmission modifications

ENDIF

———ο Disable SM-ADAPT[BSC] (IMO) ———ο Init SM-ADAPT[BSC] (IMO)

Else if the BSC is a Mx BSC then The OMC requests the Signalling Atermux configuration

M-CONFIG-SIG-ATERMUX ————————————————————→ M-CONFIG-SIG-ATERMUX-REPORT ←———————————————————

Endif Systematic configuration of the new SM_ADAPT modules on TC side. The “init SM-Adapt” scenario includes the sending by BSC of a TC-HW-RESYNCH alarm to OMC and the automatic TC hardware Audit scenario to resynchronise the OMC/BSC database in case of TC SBLs updates.

———ο Disable SM-ADAPT[TC] (IMO) ———ο Init SM-ADAPT[TC] (IMO)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 89/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

IF (TC-G2 boards) (conditional configuration of TC-ADAPT)

Need to disable (if not already yet) the TC-ADAPT and then init it to apply the transmission modifications

ENDIF

———ο 4 x Disable TC-ADAPT (IMO) ———ο 4 x Init TC-ADAPT (IMO)

Operator gets back the answer to his dedicated to mixed GPRS/CS Ater mux Modification

A- MODIFY-DEDICATED-INTO-MIXED-ATerMUX-REPORT

←—————————————————


Figure 32: “Modify a dedicated GPRS AterMux into a mixed AterMux” scenario

OMC-R Use case BSC Use case 5.1.1.13Modify dedicated GPRS AterMux into a mixed

CS/GPRS AterMux 5.2.1.4Modify AterMux GPRS



04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 90/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.1.3 Set-up (respectively unset) of a dedicated GPRS AterMux Scenario

Description OMC BSC Operator defines a new Atermux to be set as dedicated to GPRS (respectively remove the GPRS) - with or without a GSL LapD -

A-(UN)SET-DEDICATED-GPRS-ATERM

—————————————————→

OMC sends to the BSC that the AterMux is dedicated (respectively no more used for GPRS) to GPRS (AterMux-GPRS-Usage=dedicated-GPRS)



←————————————————————



A HW re-synchronisation is needed GSL maybe added (respectively suppressed) OMC-R invokes automatically ‘BSC HW/Alarm/resources/state audits’ (1)


If the BSC is a G2 BSC then If GSL Lapd modification (add or remove)



EndIF

Else if the BSC is a Mx BSC then IF Mx BSC in TDM Transport Mode The Ater signalling have to be reconfigured

M- CONFIG-SIG-ATERMUX

————————————————————→ M- CONFIG-SIG-ATERMUX -REPORT ←————————————————————

EndIF

Endif Operator gets back the answer to his request

A-(UN)SET-DEDICATED-GPRS-ATERM-REPORT

←—————————————————


Figure 33: “Set-up (respectively unset) of a dedicated GPRS AterMux” scenario

OMC-R Use case BSC Use case 5.1.1.14Set-up (respectively unset) of dedicated GPRS

AterMux 5.2.1.4 Modify AterMux GPRS



04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 91/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.1.4 Modify a mixed AterMux into a dedicated GPRS AterMux Scenario

Description OMC BSC Operator decides to modify a pure CS or mixed CS/GPRS Atermux into a dedicated GPRS Atermux (maybe with and add or remove of a GSL LapD -

A-MODIFY-ATERM-TO-DEDICATED-GPRS-ATERM

—————————————————→

OMC sends to the BSC that the AterMux is dedicated to GPRS (AterMux-GPRS-Usage=dedicated-GPRS)





A HW re-synchronisation is needed (N7 SBL, SBLs at TC side are suppressed (set NEQ), and the GSL SBL maybe added or removed). OMC-R invokes automatically ‘BSC HW/Alarm/resources/state audits’ (1)


If the BSC is a G2 BSC then If GSL Lapd modification(add or remove)



Endif

Else if the BSC is a Mx BSC then IF Mx BSC in TDM Transport Mode The Ater signalling have to be reconfigured

M- CONFIG-SIG-ATERMUX

————————————————————→ M- CONFIG- SIG-ATERMUX-REPORT ←————————————————————

EndIF Endif

Operator gets back the answer to his request

A-MODIFY-ATERM-TO-DEDICATED-GPRS-ATERM-REPORT

←—————————————————


Figure 34: “Modify a mixed AterMux into a dedicated GPRS AterMux” scenario

OMC-R Use case BSC Use case 5.1.1.15 Modify mixed AterMux to dedicated GPRS

AterMux 5.2.1.4 Modify AterMux GPRS



04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 92/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.2 O&M Action «Configure Ater» The aim of the O&M action is to configure various characteristics of Ater links: � Ater connection type � CRC4 � Half-rate presence � Loudness setting (down link & up link) Only one set of characteristics may be changed by the operator from the OMC-R at a time. 4.2.2.1 Modify Ater connection type Scenario This scenario is used to switch the Ater connection type from “terrestrial” to “via satellite” or from “via satellite” to “terrestrial”.

The operator gets back theanswer to its request

DESCRIPTION OMC-R

A-MODIFY-ATER-CONNECTION-TYPE

BSC

BSC Restart (IMO)

M-CONFIG-ATER (connectionType)

The operator modifies the Ater connectiontype

The OMC sends to the BSC the new Aterconnection type

A-MODIFY-ATER-CONNECTION-TYPE-REPORT

The OMC-R triggers configurationof transmission for Ater PROG-TRANS-ATER (HCM)

A-CONFIG-ATER-REPORT

A-BSC-RESTARTThe operator triggers a BSC Restart

Figure 35: “Modify Ater connection type” scenario

OMC-R Use case BSC Use case 5.1.1.16 Modify Ater connection type 5.2.1.6 Configure Ater

5.2.1.7 Program Ater Transmission


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 93/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.2.2 Change CRC4 Scenario The aim of this scenario is to change CRC4 parameter value to be applied to A interface.

Figure 36: Change CRC4 scenario Note: following this operation, the operator has to reinit the SBLs SM_ADAPT and TC_ADAPT locked by the BSC (see BSC use case). Remark: The CRC4 change is not useful with MT120 boards in a TC G2 or in a TC G2.5 because MT120 board has a CRC4 automatic mode i.e. MT120 board detects the MSC CRC4 mode and adapt its own mode on the MSC one.

OMC-R Use case BSC Use case 5.1.1.17 Change CRC4 5.2.1.6 Configure Ater


Operator changes CRC4 on/off

OMC-R sends the command tothe BSC

The BSC set all TC-ADAPT (forG2 TC) and SM-ADAPT SBLsto FOS and generates an alarm(local-reinitialisation-required)for each of them.

BSC acknowledges the OMC-Rrequest

OMC-R acknowledges theoperator request

DESCRIPTION OMC-R

A-CHANGE-CRC4

A-CHANGE-CRC4-REPORT

BSC

M-CONFIG-ATER (CRC4)

M-CONFIG-ATER-REPORT

PROG-TRANS-ATER (HCM)

M-ALARM-REPORT(LocalReinitRequired)…

M-ALARM-REPORT(LocalReinitRequired)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 94/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.2.3 Half-rate Setting Scenario The aim of this scenario is to modify the recovery process in the TC in order to stand to the load induced by the HR speech coding. In case of a processor failure in the TC, if HR_presence is set to "no", the traffic channels handled by the failed processor is reconfigured to the other processors. If HR_presence is set to "yes", the recovery is not possible and TC blocks the traffic channels handled by the failed processor. This modification from the OMC-R only applies to TC G2.5: settings are distributed to TC whatever its type, but for TC G2 settings are unchanged.

Figure 37: Change Half-rate scenario

OMC-R Use case BSC Use case 5.1.1.18 Change Half-rate 5.2.1.6 Configure Ater


Operator changes half-rateon/off




DESCRIPTION OMC-R

A-CHANGE-HALF-RATE

A-CHANGE-HALF-RATE-REPORT

BSC

M-CONFIG-ATER (HR-presence)




04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 95/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.2.4 Loudness Setting Scenario The aim of this scenario is to change the voice amplification on A interface. This modification from the OMC-R only applies to TC G2.5 with or without TCIF. The modification of loudness setting has to be done locally at TC site for TC G2.

Figure 38: Loudness setting scenario

OMC-R Use case BSC Use case 5.1.1.19 Change loudness 5.2.1.6 Configure Ater


Operator changes loudnessvalue




DESCRIPTION OMC-R

A-CHANGE-LOUDNESS

A-CHANGE-LOUDNESS-REPORT

BSC

M-CONFIG-ATER (TRAU-loudness-UL/DL)




04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 96/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.3 O&M Action «TC STM1 Configuration Management » The aim of this O&M action is the configuration of the STM1 in TC G2.5 with TCIF.

4.2.3.1 Getting current TC STM1 configuration scenario This action allows the export of the current configuration data stored in TC SNMP MIB on the TC NEM in a created file in the sub-directory current of the STM-1 directory. This created file is named in using the (current) properties stored in the TC SNMP MIB. The properties for a current STM-1 configuration are:

o The name of the applied file o The date of the apply (i.e. the date where the candidate configuration had been applied)

Operator TC NEM TC − A_GETCONF (Current) →

− GET-SNMP (Current) →

The TC retrieves current

configuration data and its properties (name and date) from TC SNMP MIB.

← GET-SNMP_REP (Status,

current data and properties) −

If the file name exists with same date

In the sub-directory ‘Current’ of the directory STM1

←

A_GETCONFCONFIRM (current ‘name, date‘) −

Display the current ‘name and date’ and requests if the present file in TC NEM must be kept or overwritten.

−

A_GETCONFCONFIRM (kept or overwritten) →

If file must be kept Existing file is kept. No new file is constituted. ←

A_GETCONFREP (Status) −

Warning displayed “No new file constituted by operator decision”


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 97/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Operator TC NEM TC

Else if the file must be overwritten or Else If the file name does not exist

Or Else if the file name exists but the date is different

In the sub-directory ‘Current’ of the directory STM1

Reported configuration data are stored in the sub-directory

‘Current’ in a file named from its properties.

← A_GETCONFREP (Status) −

End IF End of the scenario

Figure 39: “Getting current TC STM1 configuration” scenario

TC NEM Use case TC Use case 5.4.1.1 Getting current or candidate TC STM1

configuration 5.5.1.5 Getting current or candidate TC STM1

configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 98/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.3.2 Getting candidate TC STM1 configuration scenario This action allows the export of the candidate configuration data stored in TC SNMP MIB on the TC NEM in a created file in the sub-directory ‘Candidate’ of the STM-1 directory. This created file is named in using the (candidate) properties stored in the TC SNMP MIB. The properties for a candidate STM-1 configuration are:

o The name of the candidate STM1 configuration file downloaded o The date of the downloading of the candidate STM-1 configuration file

Operator TC NEM TC

− A_GETCONF (candidate) →

− GET-SNMP (Candidate) →

The TC retrieves candidate

configuration data and its properties (name and date) from TC SNMP MIB.


candidate configuration data and its properties)

−

If the file name exists and same date

In the sub-directory ‘candidate’ of the directory STM1

←

A_GETCONFCONFIRM (candidate ‘name, date‘) −

Display the candidate ‘name and date’ and requests if the present file in TC NEM must be kept or overwritten.

−

A_GETCONFCONFIRM (kept or overwritten) →

If file must be kept Existing file is kept. No new file is constituted. ←

A_GETCONFREP (Status) −

Warning displayed “No new file constituted by operator decision”

Else if the file must be overwritten or


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 99/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Operator TC NEM TC Else If the file name does not exist

or Else If the file name exists but different date

In the sub-directory ‘Candidate’ of the directory STM1

Reported configuration data are stored in the sub-directory

‘Candidate’ in a file named <name_date> with the file name and the date previously recovered from TC as properties.

← A_GETCONFREP (Status) −

End IF End of the scenario

Figure 40 “Getting candidate TC STM1 configuration” scenario

TC NEM Use case TC Use case 5.4.1.1 Getting current or candidate TC STM1

configuration 5.5.1.5 Getting current or candidate TC STM1

configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 100/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.3.3 Getting properties for current or candidate TC STM1 configuration This action allows the display at the TC NEM of the current properties of a current configuration or the display at the TC NEM of the candidate properties of a candidate configuration. The properties for a candidate STM-1 configuration are:


The properties for a current STM-1 configuration are: o The name of the applied file o The date of the apply (i.e. the date where the candidate configuration had been applied)

Operator TC NEM TC

− A_GETCONFPROPERTIES

(Current or candidate) →

− GET-SNMP (Current name and

current date or Candidate name and Candidate date)

→

The TC retrieves current

properties (current name and current date) or candidate properties (candidate name and candidate date) from TC SNMP MIB.


current properties (name and date) or candidate properties

(name and date))

−

←

A_GETCONFPROPERTIES_REP (current name and current date or candidate name, and candidate date)

−

Display the current properties (name and date) or candidate properties (name and date)

End of the scenario

Figure 41 “Getting properties for current or candidate STM1 configuration” scenario

TC NEM Use case TC Use case 5.4.1.2 Getting properties for current or candidate

TC STM1 configuration 5.5.1.5 Getting properties for current or candidate

TC STM1 configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 101/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.3.4 Checking a TC STM1 configuration scenario

Operator TC NEM TC − A_CHECKCONF (Directory,

Name) →

Only if the configuration file name is in the directory

<prefix>/<TC-Id>/STM-1/Configuration, TC NEM performs the checks of the configuration and generates an output file with a detailed report.

←A_CHECKCONF_REP (status) −

End of the scenario

Figure 42: “Checking a TC STM1 configuration” scenario

TC NEM Use case 5.4.1.2 Checking a TC STM1 configuration

4.2.3.5 Comparing two TC STM1 configurations scenario

Operator TC NEM TC − A_COMPCONF (Directory1,

Name1, Directory2, Name2) →

Only if Directory1 and Directory2 are STM1 sub-directories,

TC NEM performs the comparison between the two configurations and generates an output file with a detailed report.

← A_COMPCONF_REP (status) −

End of the scenario

Figure 43: “Comparing two TC STM1 configurations” scenario

TC NEM Use case 5.4.1.4 Comparing two TC STM1 configurations


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 102/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.3.6 Downloading a candidate TC STM1 configuration scenario Operator TC NEM TC

− A_SETCONF (Directory, Name) →

TC NEM checks first that the configuration file is available in the

<prefix>/<TC-Id>/STM-1/Configuration directory, and then TC NEM performs the checks of the configuration table coherency. TC NEM skips all the comment lines and generates an output file.

IF (there is no error detected) − SET-SNMP (Candidate data) →

Check that STM1-ITF(s) used is/are

declared and internal HSI interface is activated. If the check is OK the name file and the candidate configuration is stored in the active TCIF as the date available in TCIF. These three parameters (name, data and candidate data) are mirrored in the standby TCIF. If the check is NOK the candidate configuration is not stored in TCIF(s) and the status sent is NOK.

← SET-SNMP_REP (Status,date) −

If the SET SNMP is successful, the TC-NEM stores the configuration file in the candidate sub-directory under the name: <name>_<date> The date is the one reported by the TC.

ENDIF ← A_SETCONF_REP (Status) −

End of the scenario

Figure 44: “Downloading a candidate TC STM1 configuration” scenario

TC-NEM Use case TC Use case 5.4.1.5 Downloading a candidate TC STM1

configuration 5.5.1.7 Downloading a candidate TC STM1

configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 103/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.3.7 Applying a candidate TC STM1 configuaration file scenario Operator TC NEM TC OMC-R − A_APPLYCONF () →

− SET-SNMP_(APPLYCONF) →

Check that STM1-ITF(s) used is/are declared.

If the checks are OK TC copies the candidate name and the candidate configuration respectively to the current name and the current configuration. The current date is the date available in TCIF. All the ‘Current name’, ‘current date’ and ‘current STM-1 configuration’ must be mirrored on the two TCIF boards and applied.

TCIFs reconfigurations are made. TCIFs reconfigure the path trace.

The “counter of STM1 configuration change” is incremented. The concerned MT120 are configured in accordance with the ‘new’ ‘current STM1 configuration’.

Endif

← SET-SMP-REP (Status) −

←A_APPLYCONF_REP (Status) −

End of the scenario

Figure 45: “Apply a candidate TC STM1 configuration” scenario

TC-NEM Use case TC Use case 5.4.1.6 Applying a candidate TC STM1 configuration 5.5.1.8 Applying a candidate TC STM1 configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 104/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.3.8 Display of TC’s section and path traces scenario At TC-NEM it is possible to select one STM1-TTP and to request the display of section and path traces.

Operator TC NEM TC − A_GETSECTPATHTRACE

(STM1-TTP Nb) →

− GET-SNMP (STM1-TTP Nb) →

TC retrieves the section (J0) or path

traces (J1 & J2) available. ← M_GET-SNMP_REP (Status,

section (J0) or/and path traces (J1 or/and J2 )

−

← A_GETSECTPATHTRACE_REP (section (J0) or/and path traces

(J1 or/and J2) −

End of the scenario

Figure 46: “Display of section and path traces” scenario

TC-NEM Use case TC Use case

5.4.1.7 Display of TC’s section and path traces 5.5.1.9 Display of TC’s section and path traces


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 105/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.3.9 Modification of TC’s transmitted section and path traces scenario At TC NEM it is possible to modify the transmitted section trace of STM1-TTP, the transmitted High path trace (J1) and for each VC 12 of one STM1-TTP the transmitted low path traces (J2).

Operator TC NEM TC − A_SETSECTPATHTRACE(

STM1TTP Nb) →

TC NEM retrieves the current section and path traces values for

the requested STM1-TTP from the TC

− GET-SNMP (STM1-TTP Nb) →

The TC retrieves the section and path

traces available. ← GET-SNMP_REP (section (J0)

or/and path traces (J1 or/and J2) −

Operator can update:

The section trace (J0) value The high path trace (J1) value

One or several low path trace (J2) TC NEM checks the syntax of the new section/path traces

If no error detected TC NEM sends the new values to TC.

− SET-SNMP (STM1-TTP Nb, New

values) →

The TC updates the section or/and path

traces for the requested STM1-TTP. ← M_SETSECPATHTRACE_REP

(status, section or/and path traces (J1 or/and J2) updated)

−

←A_ SETSECTPATHTRACE_REP (section or/and path traces (J1

or/and J2) updated) −

Display the section or/and path traces (J1 or/and J2) updated

End of the scenario

Figure 47: “Modification of transmitted section and path traces” scenario

TC-NEM Use case TC Use case


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 106/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.1.8 Modification of TC’s transmitted section and path traces

5.5.1.10 Modification of TC’s transmitted section and path traces


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 107/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4 O&M Action «BSC STM1 Configuration Management » The aim of this O&M action is the configuration of the STM1 in MX BSC. 4.2.4.1 Getting current or candidate BSC STM1 configuration scenario This action allows the export of the current, or of the candidate, transmission Termination configuration as stored in the BSC on the BSC terminal. The transmission Termination configuration data are reported and the corresponding file is created in the sub-directory current or candidate, depending on the request.

Operator BSC Terminal BSC − A_GETCONF (Current or

candidate) →

− M_GETCONF (Current or

Candidate) →

The BSC retrieves current or

candidate data from DLS and their properties (name and date).

← M_GETCONF_REP (Status,

current or candidate data and properties)

−

Reported data are stored in a file under the name :

<name>_<date>

← A_GETCONF_REP (Status) −

End of the scenario

Figure 48: “Getting current or candidate BSC STM1 configuration” scenario

BSC Terminal Use case BSC Use case 5.3.1.1 Getting current or candidate BSC STM1

configuration 5.2.1.15 Getting current or candidate BSC STM1

configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 108/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4.2 Getting current or candidate BSC STM1 configuration properties scenario This action allows the display at BSC terminal of the current, or of the candidate, transmission Termination configuration properties. The transmission Termination configuration data are NOT reported through this use case.

Operator BSC Terminal BSC − A_GETCONF_prop (Current or

candidate) →

− M_GETCONF_prop (Current or

Candidate) →

The BSC retrieves current or

candidate data properties (name and date).

← M_GETCONF_prop_REP

(Status, current or candidate data properties)

−

Reported data are displayed ← A_GETCONF_prop_REP

(Status) −

End of the scenario

Figure 49: “Getting current or candidate BSC STM1 configuration properties” scenario

BSC Terminal Use case BSC Use case 5.3.1.2 Getting current or candidate BSC STM1

configuration properties 5.2.1.16 Getting current or candidate BSC STM1

configuration properties


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 109/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4.3 Editing a BSC STM1 configuration scenario

Operator BSC Terminal BSC − A_EDITCONF (File Name) →

BSC terminal performs the edition of the configuration specified

in the file in input.

← A_EDITCONF_REP (status) −

End of the scenario

Figure 50: “Editing a BSC STM1 configuration” scenario

BSC Terminal Use case 5.3.1.3 Editing a BSC STM1 Configuration

4.2.4.4 Create a new BSC STM1 configuration scenario

Operator BSC Terminal BSC − A_CREATCONF (File Name) →

BSC terminal creates a new configuration file with the file name

set by operator and it stores it in the Configuration sub-directory

←A_CREATCONF_REP (status) −

End of the scenario

Figure 51: “Create a new BSC STM1 configuration” scenario

BSC Terminal Use case 5.3.1.4 Create a new BSC STM1 Configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 110/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4.5 Checking a BSC STM1 configuration scenario

Operator TC NEM TC − A_CHECKCONF (Name) →

BSC terminal performs the checks of the configuration specified

in the file in input and generates an output file with a detailed report.

←A_CHECKCONF_REP (status) −

End of the scenario

Figure 52: “Checking a BSC STM1 configuration” scenario

BSC TERMINAL Use case 5.3.1.5 Checking a BSC STM1 configuration

4.2.4.6 Comparing two BSC STM1 configurations scenario

Operator TC NEM TC − A_COMPCONF (Name1,

Name2) →

BSC terminal performs the comparison between the two

configurations and generates an output file with a detailed report.

← A_COMPCONF_REP (status) −

End of the scenario

Figure 53: “Comparing two BSC STM1 configurations” scenario

BSC TERMINAL Use case 5.3.1.6 Comparing two BSC STM1 configurations


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 111/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4.7 Setting a candidate BSC STM1 configuration scenario This action allows setting a candidate BSC STM1 configuration.

Operator BSC Terminal BSC − A_SETCONF (Name) →

BSC terminal performs the checks of the configuration and

generate an output file with a detailed report.

IF (there is no error detected) − M_SETCONF (Candidate data,

name) →

BSC performs some checks on the new

configuration. If the checks are OK the BSC stores the candidate configuration in the DLS. The name of the configuration as the current date of the BSC are added to the set of configuration stored data

← M_SETCONF_REP (Status,date) −

If the setconf is successfully, the BTS terminal stores the

configuration file in the candidate sub-directory under the name: <name>_<date> The date being the one reported by the BSC.

ENDIF ← A_SETCONF_REP (Status) −

End of the scenario

Figure 54: “Setting a candidate BSC STM1 configuration” scenario

BSC Terminal Use case BSC Use case

5.3.1.7 Setting a candidate BSC STM1 configuration 5.2.1.17 Setting a candidate BSC STM1 configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 112/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4.8 Applying a candidate BSC STM1 configuration scenario This action allows applying a BSC STM1 candidate configuration. Operator BSC Terminal BSC OMC-R − A_APPLYCONF () →

− M_APPLYCONF () →

BSC performs some checks on the candidate

configuration. If the checks are OK

BSC moves the candidate configuration to the current configuration in the DLS. The date data in the candidate data is overwritten with the current date of the apply in the current data. The name of the configuration is copied in the current data. The new transmission configuration is taken into account by the BSC (the TPGSM is configured)

Endif

−

M_ALARM_REPORT (BSC, HW_resynch, Event) →

← M_APPLYCONF_REP

(Status) − OMC-R invokes automatically “BSC hardware audit” scenario

←A_APPLYCONF_REP (Status) −

End of the scenario

Figure 55: “Applying a candidate BSC STM1 configuration” scenario

BSC Terminal Use case BSC Use case 5.3.1.8 Applying a candidate BSC STM1 configuration 5.2.1.18 Applying a candidate BSC STM1

configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 113/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4.9 Get BSC’s LIU/STM1 resource scenario Through the transmission Termination Points configuration, the operator knows, for each Abis/Ater Hway TP, the transmission resource it is mapped on. The purpose of the service Get BSC’s LIU/STM1 resources is to provide to the operator the complementary view. Indeed, for each LIU port and STM1 VC12, the corresponding Abis/Ater-HWAY-TP mapped on it is given. If there is no, the LIU or STM1 VC12 is explicitly reported free.

Operator BSC Terminal BSC − A_GETRESOURCES () →

− M_GETCONF (Current) →

The BSC retrieves current data

from DLS. ← M_GETCONF_REP (Status,

current data, properties) −

Reported data are reworked in order to deduce the right

information. This computed resources information is stored in a file named with the name and date reported by the BSC.

← A_ GETRESOURCES _REP

(Status) −

End of the scenario

Figure 56: “Get BSC ‘s LIU/STM1 Resources” scenario

BSC Terminal Use case BSC Use case 5.3.1.9 Get BSC’s LIU/STM1 resources 5.2.1.15 Getting current or candidate BSC STM1

configuration


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 114/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4.10 Display of BSC’s section and path traces scenario At BSC NEM it is possible to select one STM1-TTP and to request the display of received and transmit section and path traces.

Operator BSC Terminal BSC − A_GETTRAC (STM1-TTP Nb) →

− M_GETTRAC (STM1-TTP Nb) →

The TPGSM carrying the STM1-TTP

retrieves the section (J0) and path traces (J1 and J2) available.

← M_GETTRAC_REP (Result) −

← A_GETTRAC_REP (result) −

End of the scenario

Figure 57: “Display of BSC’s section and path traces” scenario

BSC Terminal Use case BSC Use case 5.3.1.10 Display of BSC’s section and path traces 5.2.1.19 Display of BSC’s section and path traces


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 115/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.2.4.11 Modification of BSC’s transmitted section and path traces scenario At BSC NEM it is possible to modify the transmitted section trace of STM1-TTP, the transmitted High path trace and the transmitted low path trace.

Operator BSC Terminal BSC − A_SETSECTPATHTRACE(

STM1TTP Nb) →

BSC terminal retrieves the current section and path traces

values for the requested STM1-TTP from the BSC

− M_GETSECPATHTRACE (STM1-

TTP Nb) →

The BSC retrieves the section (J0) and

path traces (J1 and J2) available. ← M_GETSECPATHTRACE_REP

(Result) −

Operator can update :

the section trace (J0) value the high path trace (J1) value

one or several low path trace (J2) BSC terminal checks the syntax of the new section traces

If no error detected BSC terminal sends the new values to BSC.

− M_SETSECPATHTRACE (STM1-

TTP, Nb, New values) →

The BSC updates the section (J0) and

path traces (J1 and J2) for the requested STM1-TTP.

← M_SETSECPATHTRACE_REP

(Result) −

←A_ SETSECTPATHTRACE_REP (result) −

End of the scenario

Figure 58: “Modification of BSC’s transmitted section and path traces” scenario

BSC Terminal Use case BSC Use case 5.3.1.11 Modification of BSC’s transmitted section and

path traces 5.2.1.20 Modification of BSC’s transmitted section and

path traces


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 116/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

4.3 Subscenario for Programming of Ater Transmissions

This subscenario is used in most operations. They refer to the BSC use case “Program Ater Transmission” where the impacted NEs are given for each O&M operation.

4.3.1 Program Ater Transmission subscenario This subscenario refers to the BSC use case “Program Ater Transmission.

Description OMC BSC TC OMC-R solicits the programming of the transmissions

M-PROG-TRANS-ATER ————————————————→

IF the BSC is a G2 BSC IF ASMB are flagged BSC programs BSC transmission

ENDIF ELSE IF the BSC is a Mx-BSC The BSC generates the partial TP configuration (for the impacted ATER-HWAY-SBLs) and send it to the TP boards (see [A19] for details)

ENDIF

For G2 BSC or MX BSC in TDM transport mode

IF TC equipment are flagged

BSC programs TC equipment if they are in traffic using the Qmux interface.

Qmux exchange ————————————————→

ENDIF End For

For MX BSC in IP transport mode IF TC equipment are flagged

BSC programs TC equipment in using BSC-TC Audit scenario.

BSC-TC Audit (HCM BSC, TC and Ater part)

End For BSC acknowledges the programming of transmission

M-PROG-TRANS-ATER-REPORT ←————————————————

Figure 59: Program Ater Transmission sub scenario The scenario has several variants according to the O&M operation in which it appears. These variants are detailed in the Use case.

BSC Use case 5.2.1.7 Program Ater transmission


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 117/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5 DETAILED DESCRIPTION

5.1 OMC-R Description

5.1.1 Use Case Description

5.1.1.1 Use Case «Add a BSS» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-ADD-BSS event from the OMC-R operator. Pre Conditions: None. Post Conditions: A new BSS exists in the OMC-R. Inputs:

OPERATOR INPUTS Parameter name Purpose Optional/Mandatory Default value BSS name Identifier of the BSS Mandatory Host identifier Identifier of the OMC host

server Mandatory

BSS release Release of the BSS Mandatory BSC node identifier (*) Optional IPaddress IP address for Mx BSC Optional Primary X25 address X25 address for G2 BSC Optional Secondary X25 address X25 address for G2 BSC Optional OMC-BSS Synchronization

If true, the OMC will autonomously lauch a BSC discover at the end of the scenario

Optional

(*) BSC node identifier may be modified later (OMC internal) Outputs: A report about the outcome of the operation. Description: The Operator inputs are stored in the OMC-R database and used for future connection with the BSC. See FBS TAS [A6] for more details about the usage of the X25 and IP addresses. Exceptions: The BSS addition is refused if: • the BSS name is already used; • For a G2 BSC the primary X25 address is not defined • the primary or secondary X25 address is already used. • For a Mx BSC the IP address is not defined


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 118/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• The IP address is already used for another BSC

5.1.1.2 Use Case «Delete a BSS» Related BSS Service: This use case supports S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-REMOVE-BSS event from the OMC-R operator. Pre Conditions: No operation in progress for this BSS. Post Conditions: The BSS is removed from the OMC-R. Inputs:

OPERATOR INPUTS Parameter name Purpose Optional/Mandatory Default value BSS name Identifier of the BSS Mandatory Outputs: A report about the outcome of the operation. Description: All data related to the selected BSS are removed from the OMC-R database, except messages stored in the message log. If the BSSIM supervised one or more TC racks (TCIFs), those TC rack (TCIFs) will not be supervised anymore. Remark: From the operator view those TC rack will appear in a special manner as not being supervised. Exceptions: The BSS removal is refused if:

• Download software is in progress for the target BSS; • Logical configuration operation (modification via SC or PRC, audit, force config) is

in progress for the target BSC; • A MFS NE is attached to the target BSS.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 119/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.3 Use Case «Modify BSS identification» Related BSS Service: This use case supports S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-MODIFY-BSS event from the OMC-R operator. Pre Conditions: None. Post Conditions: New parameters are taken into account in the OMC-R. Inputs:

OPERATOR INPUTS Parameter name Purpose Optional/Mandatory Default value BSS name Identifier of the BSS Mandatory New BSS name New identifier of the BSS Optional New BSC node identifier New BSC node identifier Optional Outputs: A report about the outcome of the operation. Description: The new operator inputs are stored in the OMC-R database. Exceptions: The BSS modification is refused if:

• The new BSS name is already used.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 120/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.4 Use Case «Complete BSS audit» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-DISCOVER-BSS event from the OMC-R operator. Pre Conditions: BSS must be added to the OMC-R. Post Conditions: The OMC-R and BSS database are synchronised. Inputs:

OPERATOR INPUTS Parameter name Purpose Optional/

Mandatory Default value

BSS name Identifier of the BSS Mandatory Outputs: None. Description: On reception of the A-DISCOVER-BSS event from the operator, from B11 while minimizing loss of PM, the OMC-R requests the following audits: • Peer entities Audit; • HW/SW overall type Audit; • PM and Trace audit of the BSS; • Software version audit of the BSS; • Hardware audit of the whole BSS (See 4.1.3.1.1 Hardware Audit sub-scenario, including

BSC Hardware Audit sub-scenario and BTS Hardware Audit scenario (Ref [A27] HCM BTS and Abis part))

• Logical parameter audit of the BSS; • Date and Time synchronisation between OMC-R and BSS. If OMC-R detects that BSC reports incorrect TC side TCSL endpoints, OMC-R automatically performs the correction. If the BSC or the BTS is not able to return the information requested by the OMC-R for this BTS only the BTS hardware audit for this BTS is aborted Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 121/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.5 Use Case «OMC/BSC synchronisation» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of: • The M-ALARM-REPORT(BSC, HW_Resynch, Event) message from the BSC • The A-BSC-HW-AUDIT event from the OMC-R operator. • The A-DISCOVER –BSS event from the operator • The M-ALARM-REPORT(BSC, TC_HW_Resynch, Event) message from the BSC Pre Conditions: None. Post Conditions: The OMC-R and BSC database are synchronised. Inputs:



BSS name Identifier of the BSS Mandatory Outputs: None. Description: On reception of the M-ALARM-REPORT (BSC, HW_Resynch, event) from the BSC or the A-BSC-HW-AUDIT from the operator or A-DISCOVER-BSS from the operator, the OMC-R request automatically the following audits: • Peer entities Audit, only if BSC hardware audit is explicitly triggered by operator • HW-SW-Overall-Type Audit, except in case of discovery • Display of HW related parameters groups:

• Cic-Atrk-Type • No7-Netw-Addr-Type • GPRS-BSC-Type • Bts-Id-To-Cell-Id-Type

• BSC hardware files (BSC, TC, Abis); At Abis part time, OMC picks up only the fields, which are of interest for the current mode (IP, TDM)

• If the configuration file is the BSC Hardware and if it is a MX BSC then display of HW related parameters group HW_LOG_Mapping_Type

• If it is a Mx BSC, collect BSC inventory • Alarm audit; • State audit. When BSC hardware audit data are returned from the BSC (Content of the BSC hardware audit is described in document [A10]), the OMC-R compares these data with the data stored in its database (differential audit). The OMC-R database is updated as follows: • a SBL present in the audit report but not in the OMC-R database is added; • a SBL present in the OMC-R database but not in the audit report is removed; • a SBL characteristic value in the audit report different in the OMC-R database is updated.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 122/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The OMC-R, also, processes the semi-permanent path configuration reported in the A-bis HW configuration file (See HCM BTS and Abis part [A27] for more details about “the semi-permanent path configuration” feature). On every audit, the OMC-R reports to the operator the differences between the BSC and the OMC. If N_EXTRA_ABIS_TS is modified, and if there are cells mapped to this BTS, the alignment status of these cells at MFS side are set "misaligned" by the OMC. The operator must resynchronise the MFS at cell level to force the OMC to send the new value of N_EXTRA_ABIS_TS to the MFS. If there is no cell mapped to this sector, the value of N_EXTRA_ABIS_TS will be sent during the PRC activation that creates this cell. If the usage of TS pertaining to CS/PS Atermux is modified, the alignment status of the ‘BSC GPRS configuration’ is set to ‘misaligned’ by the OMC. The operator must resynchronise the MFS at BSC GPRS configuration level to force the OMC to send the new value of the TS usage to the MFS. On reception of the M-ALARM-REPORT (BSC, TC_HW_Resynch(*), event) from the BSC, the OMC-R request automatically the following audits:

• TC hardware audit • BSC Alarm and resource audit (Ref [A3] NSR) • BSC state audit (Ref [A3] NSR)

(*) Remark: The TC_HW_Resynch is only available in TDM BSS mode and is used in any case, in which only TC SBL data has changed. When TC hardware audit data are returned from the BSC (Content of the TC hardware file is described in document [A10]), the OMC-R compares these data with the data stored in its database (differential audit). The OMC-R database is updated only for TC SBL related data as follows: • A SBL present in the audit report but not in the OMC-R database is added; • A SBL present in the OMC-R database but not in the audit report is removed; • A SBL characteristic value in the audit report different in the OMC-R database is updated. The OMC-R reports to the operator the differences between the BSC and the OMC-R. Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 123/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.6 Use Case «OMC/BSS synchronisation» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by: • The reception of the A-BSS-HW-AUDIT event from the OMC-R operator. • The A-DISCOVER-BSS event from the OMC-R operator. Pre Conditions: None. Post Conditions: The OMC-R and BSC database are synchronised. Inputs:



BSS name Identifier of the BSS Mandatory Outputs: None. Description: On reception of the A-BSS-HW-AUDIT from the operator or A-DISCOVER-BSS from the operator, the OMC-R executes: • a Hardware audit for the BSC (see §5.1.1.5 Use Case «OMC/BSC synchronisation») • for all attached BTSs with BTS-O&M not in OPR state BTS hardware audit (See OMC

Use Case “OMC/BTS synchronisation” Ref [A27] HCM BTS and Abis part paragraph) in order to align the OMC-R database to the BSS-NE database.

Exceptions: None. 5.1.1.7 Use Case « HW/SW Overall Audit » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-DISCOVER-BSS event from the OMC-R operator. Pre Conditions: None. Post Conditions: None. Inputs:



HW-SW Overall Type The BSC parameter group HW-SW overall type

Mandatory

Outputs: A report about the outcome of the operation.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 124/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Description: The OMC sends the M_LogicalParam_Display message with parameter group “HW/SW_overall_Type” to the BSC to request the HW-SW overall parameters. On reception of the M_LogicalParam_Display_report message the OMC updates its database with the information returned by the BSC. Exceptions: None.

5.1.1.8 Use Case «Display Rack Layout» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-DISP-RACK-LAYOUT event from the OMC-R operator. Pre Conditions: None. Post Conditions: None. Inputs:



Composed equipment Identifier of the composed equipment: BSC, TC, BTS name

Mandatory Rack number Identifier of the rack Optional Outputs: Rack layout is displayed to the operator. Description: This use case provides a display of the rack layout (i.e. rack, shelf and slot of each board is provided) for the different composed pieces of equipment of the BSS: BSC, TC and BTS. Exceptions: None. 5.1.1.9 Use Case "Display VCE" Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-DISP-VCE event from the OMC-R operator. Pre Conditions: This use case is valid only for Mx-BSC. Post Conditions: None. Inputs:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 125/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt



BSS name Identifier of the BSS Mandatory Outputs: The list of VCE is displayed to the operator. Description: The OMC-R operator is able to request the display of the VCE list for the complete BSC. The information displayed for each VCE is:

• The CP-LOG name • The VCE name composed of:

o The SBL type (TCU, DTC, CPR or TSC) o The SBL number

• The Status of the VCE (administrative, control and alarm status) OMC-R allows filtering capabilities on CP-LOG name, SBL type or any status. OMC-R allows also triggering maintenance operations for a selected VCE. Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 126/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.10 Use Case «Display BSS topology» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-DISP-TOPOLOGY event from the OMC-R operator. Pre Conditions: None. Post Conditions: None. Inputs:



BSS name Identifier of the BSS Mandatory Outputs: BSS topology is displayed to the operator. Description: The transmission network topology of the Abis for one selected Abis chain/ring/group or for all the BSS is displayed to the operator. The information displayed for each Abis: • the Abis name; • the topology of the Abis; • the name of the BTSs connected; • the position of the BTS on the Abis chain/ring (TDM or IPoverE1 only); • if this is the primary Abis or the secondary Abis of the BTS • the number of TRE(s) and sector(s); • the frequency band of each TRE • the speech rate of each TRE Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 127/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.11 Use Case «Display of the LIU and BSC STM1 resource occupancy» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-DISP-OCCUPANCY event from the OMC-R operator. Pre Conditions: None. Post Conditions: None. Inputs: None Outputs: The LIU and STM1 resouce occupancy are displayed Description: This display allows visualizing the LIU and STM1 resource occupancy It is the complementary view of the Abis and Ater view. Indeed, in this new view, each LIU port and each STM1 VC12 is represented with the Abis/Ater Hway TP mapped on it. If the resource is free (no TP mapped on it), it shall be explicitly expressed. Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 128/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.12 Use Case «Modify GPRS granularity» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-MODIFY-GPRS-GRANULARITY event from the OMC-R operator. Pre Conditions: An AterMux is already defined (all BSC SBLs are created; SM_ADAPT SBL/TC_ADAPT are created if needed (case TC G2, G2 BSC and MX BSC in TDM transport mode) and ATER_HWAY_TP (TC side) is created). If the BSS is in IP transport mode, the operator should first dis-associate the MT120 (if any) from the BSC and trigger a BSC-TC Audit to remove the associated TC SBL (TRAU_CP, A_PCM_TP, ATER_HWAY_TP and CS_ATERMUX). Post Conditions: GPRS granularity within the AterMux is changed and the transmission equipments are updated if needed. Inputs:



BSS name Identifier of the BSS Mandatory AterMux number Identifier of the BSC AterMux Mandatory GPRS granularity Percentage of GPRS within the

AterMux : o In TDM mode granularities

0%, 12,5%, 25%, 50%, 75% or 100% are offered;

o In IP mode only granularities 0% and 100% are offered.

Mandatory

GSL LapD presence Only available in TDM mode: Indicate if a GSL LapD has to be set-up on the second tributary of the AterMux

Optional In TDM mode: When the parameter is not present, the previous choice (last granularity modification) is not changed10

TC Transparency (*) Only available in TDM mode: Flag indicating if the AterMux transmission at TC site shall support routing of Gb

Optional - TC Transparency==TRUE

(*) For MT120 boards the TC transparency is mandatory to allow the AIS 512K detection. So for MT120 boards, the OMC does not allow the value "false". Outputs: A report about the outcome of the operation to the OMC-R operator. Description: If the BSS is in IP transport mode only Granularities 0% and 100% are offered to the operator on OMC-R screen. If the BSS is in TDM transport mode granularities 0%, 12,5%, 25%, 50%, 75% and 100% are offered to the operator on OMC-R screen. 10 The default value to be taken for the first time for the AterMux is : NO GSL


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 129/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

If the BSS is in IP transport mode, OMC-R only allows changing an Atermux CS to a Dedicated PS Atermux if no TRAU_CP SBL exists on this atermux. On the reception of the A-MODIFY-GPRS-GRANULARITY event from the OMC-R operator: The OMC calculates which are the Ach of the AterMux tributaries that are going to be changed : - From CIC to GIC : GPRS granularity increasing, - From GIC to CIC : GPRS granularity decreasing. → See ref. [A8] for Ater/AterMux mapping detail related to GPRS granularity. After the calculation, if ACHs used for GPRS (GIC or GSL) are going to be used for circuit (CIC), the OMC automatically disable the corresponding ACHs. This disable is done in order to avoid that these AterTS are used for telecom traffic before the MFS is updated and the MSC-BSC connection is re-established. The GIC-Group-Base (or also GIC-Code-Atrk top 11 bits) identifier setting is the responsability of the OMC in order to avoid any naming conflict (the rule to be used is : GIC-Group-Base = ATR number = DTC number supporting the corresponding Ater PCM). If there is no GPRS configuration on Ater (i.e. all Ach-GPRS-CS 32 bits are equal to 0) then GIC-code-Atrk equals 0FFFF (all 32 bits are set to 1). In that case, GIC-Group-base differs from DTC number supporting the corresponding Ater PCM. Then the OMC sends the two following logical parameter groups (even if one of the group is not changed). The sequence of parameter groups has to be respected:

1- GPRS-BSC-Type (with the parameter atermuxgprs): it is modified if the TC Transparency flag is modified (only in case of TDM mode). 2- Cic-Atrk-Type : to precise the GIC number of the TS0 and to precise the Achs that are use for GPRS and those use for CS. Only in TDM mode the presence (respectively absence) of GSL LapD is also indicated.

Note: For G2 BSC even if only one AterMux is modified, all BSC AterMux that are not dedicated 0% GPRS have to be provided by the OMC-R to the BSC via these two groups. For Mx BSC, OMC-R provides in these two groups only modified Atermux that are not dedicated 0% GPRS. If there is no Atrunk modified as far as Cic-Atrk-Type is concerned, OMC-R has to provide at least one unmodified Atrunk because Cic-Atrk-Type must be sent and must contain at least one element. Only in TDM mode The OMC shall receive an “HW resync” event alarm from the BSC when the SBL GSL is either created or deleted by the BSC. The OMC-R has to configure the transmission equipment’s: • For G2 BSC when the SBL GSL has been either created or deleted by the BSC the OMC-

R disables and initializes the necessary SM-ADAPTs and TC-ADAPTs (only SM-ADAPTs in the case of the MT120 board).

• For Mx BSC in TDM mode the OMC-R requests the Ater Signalling Configuration per Atermux modified, disables and initialises the SM-ADAPT at TC side and TC-ADAPT if the transcoder does not contain a MT120 board.

See overall scenarios § 4.2.1.1. Lastly (in TDM mode and in IP mode), the response with status is given back to the operator.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 130/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Exceptions: OMC checks that Ater is able to support GPRS (Ater mux must already be ‘linked’ to the MFS). OMC checks that Ater is able to support circuit: the Atermux SBL number must be lower or equal to the maximum number of CS Atermux (see chapter 1.1.1.2: number of Ater CS). OMC checks that the flag TC-transparency is not being set to FALSE when the GPRS granularity is decreased. (No real reason identified for this check). If the BSS is in IP mode, OMC checks no TRAU_CP SBL exists associated to the Atermux to configure from CS to Dedicated PS. If the response from the BSC to one of the two logical modifications (via M-LOGICALPARAM-MODIFY-REPORTs see BSC use case: “Modify AterMux GPRS”) is unsuccessful then the use case is stopped (otherwise it continues). If the event alarm HW-Resync-Event event is not received from the BSC (when it should be received), then the operator shall be warned that the HW configuration shall be aligned manually. If SM-ADAPT (BSC or TC) or TC-ADAPT is already locked (OPR) before configuring it, then the OMC reverses the disable/init sequence in order to leave the administrative state of this object as it was before the AterMux configuration change. If some transmission equipment cannot be configured (Lock/Unlock SM-ADAPT or TC-ADAPT fails), then the operator must be warned (an alarm will be generated) in order to trigger manually this configuration. For this set of transmission equipment, the OMC configures them in a best effort mode.

5.1.1.13 Use Case «Modify dedicated GPRS AterMux into a mixed GPRS/CS AterMux» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-MODIFY-DEDICATED-INTO-MIXED-ATERM event from the OMC-R operator. Pre Conditions: An AterMux is already dedicated to GPRS (all BSC SBLs excepting N7 are created but the SBLs at TC side are NEQ). Post Conditions: A GPRS granularity within the AterMux set-up and the transmission equipments are created and updated. Inputs:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 131/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt



BSS name Identifier of the BSS Mandatory AterMux number Identifier of the BSC AterMux Mandatory GPRS granularity Percentage of GPRS within the

AterMux (0%, 12,5%, 25%, 50%, 75% or 100%)

Mandatory

GSL LapD presence Indicate if a GSL LapD has to be set-up on the second tributary of the AterMux

Optional When the parameter is not present, the previous choice (what was existing for the dedicated GPRS AterMux) is not changed

TC Transparency (*) Flag indicating if the AterMux transmission at TC site shall support routing of Gb.

Optional - TC Transparency==TRUE

(*) For MT120 boards the TC transparency is mandatory to allow the AIS 512K detection. So for MT120 boards, the OMC does not allow the value "false". Outputs: A report about the outcome of the operation to the OMC-R operator. Description: The OMC checks the concerned BSS is in TDM Mode. When the operator has defined the GPRS granularity he wants to set-up on the AterMux, the OMC calculates which are the Ach of the AterMux tributaries that are going to be changed : → See ref. [A8] for Ater/AterMux mapping detail related to GPRS granularity. After the calculation, if Ach used for GPRS (GIC or GSL) are going to be used for circuit (CIC), the OMC automatically disable the corresponding Ach. This disable is done in order to avoid that these AterTS are used for telecom traffic before the MFS is updated and the MSC-BSC connection is re-established. Then the OMC sends the two following logical parameter groups. The sequence of parameter groups has to be respected:

1- GPRS-BSC-Type (with the parameter atermuxgprs): it is modified to indicate that this AterMux is now mixed (GPRS/CS or pure CS) and the TC Transparency flag to apply (only in TDM mode). 2- Cic-Atrk-Type : to precise the GIC number of the TS0 and to precise the Achs that are use for GPRS and those use for CS. The presence (respectively absence) of GSL LapD is also indicated.

Note: For G2 BSC even if only one AterMux is modified, all BSC AterMux that are not dedicated 0% GPRS have to be provided by the OMC-R to the BSC via these two groups. For Mx BSC, OMC-R provides in these two groups only modified Atermux that are not dedicated 0% GPRS. If there is no Atrunk modified as far as Cic-Atrk-Type is concerned, OMC-R has to provide at least one unmodified Atrunk because Cic-Atrk-Type must be sent and must contain at least one element. The OMC shall receive an “HW resync” event alarm from the BSC when the N7 SBL, the SBLs at TC side are created and eventually the GSL SBL is created or deleted. The BSC HW audit automatically triggered by the OMC (at the reception of this event alarm) allows the OMC to know the SM-ADAPT and TC-ADAPT SBLs at TC side.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 132/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Then, the OMC-R has to configure the transmission equipment’s: • For G2 BSC when the N7 SBL, the SBLs at TC side are created and eventually the GSL

SBL is created or deleted the OMC-R disables and initialises the necessary SM-ADAPTs and TC-ADAPTs (only SM-ADAPTs for MT120 board).

• For Mx BSC the OMC-R requests the Ater signalling Configuration par Atermux modified, disables and initialises the SM-ADAPT at TC side and TC-ADAPT if the transcoder does not contain a MT120 board.

During “init SM-Adapt”(TC) scenario (see Ref [A4] IMO), BSC triggers a TC discovery phase (See in § 4.1.2.2.1TC discovery phase Sub-scenario). See overall scenario §4.2.1.2.

Lastly, the response with status is given back to the operator. Exceptions: OMC checks the Mode of the concerned BSS and if the concerned BSS is in IP Mode the operator request is rejected. OMC checks that Ater is able to support circuit: the Atermux SBL number must be lower or equal to the maximum number of CS Atermux (see chapter 1.1.1.2: number of Ater CS). In case of MxBSC the OMC rejects the command if the Atermux is initially dedicated 0%. OMC checks that the flag TC-transparency is not being set to FALSE (No real reason identified for this check). If the response from the BSC to one of the two logical modifications (via M-LOGICALPARAM-MODIFY-REPORTs see BSC Use case : “Modify AterMux GPRS”) is unsuccessful then the use case is stopped (otherwise it continues). If the event alarm HW-Resync-Event event is not received from the BSC, then the operator shall be warned that the HW configuration shall be aligned manually, and the disable/init of the SM-ADAPT and TC-ADAPT at TC side would have to be done manually. If SM-ADAPT (BSC or TC) or TC-ADAPT is already locked (OPR) before configuring it, then the OMC reverses the disable/init sequence in order to leave the administrative state of this object as it was before the AterMux configuration change. If some transmission equipment cannot be configured (Lock/Unlock SM-ADAPTor TC-ADAPT fails), then the operator must be warned in order to trigger manually this configuration. For this set of transmission equipment, the OMC configures them in a best effort mode.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 133/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.14 Use Case «Set-up (respectively unset) of a dedicated AterMux» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-(UN)SET-DEDICATED-GPRS-ATERM event from the OMC-R operator. Pre Conditions: No AterMux is defined (in the case a dedicated GPRS AterMux is already defined, this use case is triggered to add or remove the GSL within this AterMux or to remove the GPRS on the Ater-Mux (A-UNSET-DEDICATED-GPRS-ATERM). Post Conditions: A dedicated GPRS AterMux (with or without GSL) is declared into (respectively removed from) the BSS Inputs:



BSS name Identifier of the BSS Mandatory AterMux number Identifier of the BSC AterMux Mandatory Dedicated flag Indicates that the corresponding

AterMux is going to be dedicated for GPRS (respectively cleared from GPRS)

Mandatory

GSL LapD presence Only available in TDM transport mode Indicate if a GSL LapD has to be set-up on the second tributary of the AterMux

Optional No GSL

Outputs: A report about the outcome of the operation to the OMC-R operator. Description: OMC-R checks :

- AterMux is able to be set as dedicated GPRS (no Qmux, X25 or IP: see ref. [9]) (respectively it is already GPRS dedicated).

IF this use case is triggered to set-up a GSL LapD (or remove the GSL LapD), IF BSS in TDM Mode then:

- The OMC sends the two following logical parameter groups (even if one of the group is not changed). The BSC sends the M-ACTION-REPORTs after the reception of each logical parameters groups :

1- GPRS-BSC-Type (with the parameter atermuxgprs) : not modified. 2- Cic-Atrk-Type : To precise that the flag “GSL-On-Atrk” is modified.

Note: For G2 BSC even if only one AterMux is modified, all BSC AterMux that are not dedicated 0% GPRS have to be provided by the OMC-R to the BSC via these two groups. For Mx BSC, OMC-R provides in these two groups only modified Atermux that are not dedicated 0% GPRS. If there is no Atrunk modified as far as Cic-Atrk-


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 134/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Type is concerned, OMC-R has to provide at least one unmodified Atrunk because Cic-Atrk-Type must be sent and must contain at least one element.

Else Exception case

EndIF

ELSE-IF this use case is triggered to remove the GPRS from this GPRS dedicated AterMux, then :

- The OMC sends the two following logical parameter groups (even if one of the group is not changed). The M-ACTION-REPORTs will be provided by the BSC when both logical parameters will have been received :

1- GPRS-BSC-Type (with the parameter atermuxgprs) : not modified. Note: Because Atermux that are dedicated 0% are not provided to the BSC, the OMC-R does not provide the modified Atermux in case of G2 BSC and does not provide the parameter group in case of Mx BSC. 2- Cic-Atrk-Type : To precise that there is no more GPRS on any Ater (each tributary of the AterMux has its Ach-GPRS-CS’s bitmap set to 0 plus its flag “GSL-On-Atrk” set to FALSE)

Note: For G2 BSC even if only one AterMux is modified, all BSC AterMux that are not dedicated 0% GPRS have to be provided by the OMC-R to the BSC via these two groups. For Mx BSC, OMC-R provides in these two groups only modified Atermux that are not dedicated 0% GPRS. If there is no Atrunk modified as far as Cic-Atrk-Type is concerned, OMC-R has to provide at least one unmodified Atrunk because Cic-Atrk-Type must be sent and must contain at least one element.

ELSE this use case is triggered to set a GPRS dedicated Atermux::

-The OMC defines the list of Ach that are going to be used for GPRS (GIC or GSL) → See ref. [A8] for Ater/AterMux mapping detail related to dedicated GPRS AterMux.

- The GIC-Group-Base (or also GIC-Code-Atrk top 11 bits) identifier setting is the responsability of the OMC in order to avoid any naming conflict (the rule to be used is: GIC-Group-Base = ATR number = DTC number supporting the corresponding Ater PCM). If there is no GPRS configuration on Ater (i.e. all Ach-GPRS-CS 32 bits are equal to 0) then GIC-code-Atrk equals 0FFFF (all 32 bits are set to 1). In that case, GIC-Group-base differs from DTC number supporting the corresponding Ater PCM.

- Then the OMC sends the both following logical parameter groups (even if one of the group is not changed). The sequence of parameter groups has to be respected :

1- GPRS-BSC-Type (with the parameter atermuxgprs): not modified. 2- Cic-Atrk-Type : to precise the GIC number of the TS0 and to precise the Achs that are use for GPRS (GICs). The presence (respectively absence) of GSL LapD is also indicated.

Note: For G2 BSC even if only one AterMux is modified, all BSC AterMux that are not dedicated 0% GPRS have to be provided by the OMC-R to the BSC via these two groups. For Mx BSC, OMC-R provides in these two groups only modified Atermux that are not dedicated 0% GPRS. If there is no Atrunk modified as far as Cic-Atrk-Type is concerned, OMC-R has to provide at least one unmodified Atrunk because Cic-Atrk-Type must be sent and must contain at least one element.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 135/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

END IF. Only in TDM mode, The OMC shall receive an “HW resync” event alarm from the BSC when the GSL SBL is either created or deleted by the BSC. Then, in order to effectively configure the BSC transmission equipment:: • For G2 BSC, if the GSL LapD is either created or deleted, the OMC-R disables and

initialises the BSC SM-ADAPT • For Mx-BSC the OMC-R requests the Ater signalling configuration per Atermux modified. Note: There is no add/remove GSL in IP mode. Lastly, the response with status is given back to the operator. Exceptions: If the response from the BSC to one of the two logical modifications (via M-LOGICALPARAM-MODIFY-REPORTs see BSC use case : “Modify AterMux GPRS”) is unsuccessful then the use case is stopped (otherwise it continues). If the event alarm HW-Resync-Event event is not received from the BSC (when it should be received), then the operator shall be warned that the HW configuration shall be aligned manually. In case of G2 BSC, if SM-ADAPT (BSC) is already locked (OPR) before configuring it, then the OMC reverses the disable/init sequence in order to leave the administrative state of this object as it was before the AterMux configuration change. In case of G2 BSC, if the SM-ADAPT (BSC) cannot be configured (Lock/Unlock SM-ADAPT), then the operator must be warned in order to trigger manually this configuration. Atermux with Qmux cannot be dedicated PS. IF in IP mode and IF this use case is triggered to set-up a GSL LapD (or remove the GSL LapD) this operation is refused by the OMC-R.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 136/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.15 Use Case «Modify mixed AterMux into a dedicated GPRS AterMux» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-MODIFY-ATERM-TO-DEDICATED-GPRS-ATERM event from the OMC-R operator. Pre Conditions: An AterMux pure CS or mixed CS/GPRS (case of TDM transport mode) is already defined (all BSC SBLs and SM_ADAPT SBL/TC_ADAPT are created if needed (case TC G2, G2 BSC and MX BSC in TDM transport mode) and ATER_HWAY_TP (TC side) is created). If the BSS is in IP transport mode, the operator should first dis-associate the MT120 (if any) from the BSC and trigger a BSC-TC Audit to remove the associated TC SBL (TRAU_CP, A_PCM_TP, ATER_HWAY_TP and CS_ATERMUX). Post Conditions: A dedicated GPRS AterMux (with or without GSL) is declared into the BSS Inputs:



BSS name Identifier of the BSS Mandatory AterMux number Identifier of the BSC AterMux Mandatory Dedicated flag Indicates that the corresponding

AterMux is going to be dedicated for GPRS

Mandatory

GSL LapD presence Only available in TDM Mode Indicate if a GSL LapD has to be set-up on the second tributary of AterMux

Optional When not provided, the last choice is kept.11.

Outputs: A report about the outcome of the operation to the OMC-R operator. Description: OMC-R checks :

- AterMux is able to be set as dedicated (no Qmux, X25 or IP: see ref. [9]). - If the AterMux supports a N7, this one is locked (OPR) - If the BSS is in IP transport mode, no TRAU_CP SBL exists associated to the Atermux to modify to Dedicated PS.

The OMC defines the list of Ach that are going to be used for GPRS (GIC or GSL) → See ref. [A8] for Ater/AterMux mapping detail related to dedicated GPRS AterMux. If it is not yet defined, the GIC-Group-Base (or also GIC-Code-Atrk top 11 bits) identifier setting is the responsability of the OMC in order to avoid any naming conflict (the rule to be 11 The default value to be taken for the first time for the AterMux is : NO GSL


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 137/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

used is : GIC-Group-Base = ATR number = DTC number supporting the corresponding Ater PCM). In case of G2 BSC, if there is no GPRS configuration on Ater (i.e. all Ach-GPRS-CS 32 bits are equal to 0) then GIC-code-Atrk equals 0FFFF (all 32 bits are set to 1). In that case, GIC-Group-base differs from DTC number supporting the corresponding Ater PCM. Then the OMC sends the both following logical parameter groups. The sequence of parameter groups has to be respected:

1- GPRS-BSC-Type (with the parameter atermuxgprs): to precise that the AterMux is requested to be a dedicated GPRS AterMux. 2- Cic-Atrk-Type : to precise the GIC number of the TS0 and the Achs that are used for GPRS (GICs). The presence (respectively absence) of GSL LapD is also indicated only if BSS in TDM mode. .

Note: For G2 BSC even if only one AterMux is modified, all BSC AterMux that are not dedicated 0% GPRS have to be provided by the OMC-R to the BSC via these two groups. For Mx BSC, provides in these two groups only modified Atermux that are not dedicated 0% GPRS. If there is no Atrunk modified as far as Cic-Atrk-Type is concerned, OMC-R has to provide at least one unmodified Atrunk because Cic-Atrk-Type must be sent and must contain at least one element. The OMC shall receive an “HW resync” event alarm from the BSC when the N7 SBL, the SBLs at TC side are deleted and only if BSS is in TDM mode eventually if the GSL SBL is either created or deleted by the BSC. Then, in order to effectively configure the BSC transmission equipment:: • For G2 BSC, if the GSL LapD is either created or deleted, the OMC-R disables and

initialises the BSC SM-ADAPT in case of G2 BSC • For Mx BSC, only if Mx BSC is in TDM mode, the OMC-R requests the Ater signalling

Configuration per AterMux modified. Note: There is no add/remove GSL in IP mode. Lastly, the response with status is given back to the operator. Exceptions: If the BSS is in IP mode, OMC rejects the command if TRAU_CP SBL exists associated to the Atermux to configure to Dedicated PS. If the response from the BSC to one of the two logical modifications (via M-LOGICALPARAM-MODIFY-REPORTs see BSC use case : “Modify AterMux GPRS”) is unsuccessful then the use case is stopped (otherwise it continues). In case of MxBSC the OMC-R rejects the command if it requests the Atermux to be dedicated 0%. If the event alarm HW-Resync-Event event is not received from the BSC, then the operator shall be warned that the HW configuration shall be aligned manually.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 138/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

In case of G2 BSC, if SM-ADAPT (BSC) is already locked (OPR) before configuring it, then the OMC reverses the disable/init sequence in order to leave the administrative state of this object as it was before the AterMux configuration change. In case of G2 BSC, if the SM-ADAPT (BSC) cannot be configured (Lock/Unlock SM-ADAPT), then the operator must be warned in order to trigger manually this configuration.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 139/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.16 Use Case «Modify Ater connection type» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-MODIFY-ATER-CONNECTION-TYPE event from the OMC-R operator. Pre Conditions: Post Conditions: Inputs:



BSS name Identifier of the BSS Mandatory Connection type Indicates the new connection type,

either terrestrial or via satellite Optional Current value

Outputs: A report about the outcome of the operation to the OMC-R operator. Description: The OMC-R sends a CONFIG-ATER request to the BSC with the new Ater connection type, then a PROG-TRANS-ATER request. Exceptions: The operator’s request is rejected by the OMC-R if: � The new Ater connection type is via satellite while any Abis link attached to this BSC has

a connection type via satellite.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 140/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.17 Use Case «Change CRC4» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service. It is triggered by the reception of the A-CHANGE-CRC4 event from the OMC-R operator. Pre Conditions: None. Post Conditions: None Inputs:

OPERATOR INPUTS Parameter name Purpose Optional/Mandatory Default value BSS name Identifier of the BSS Mandatory Crc4 On/Off Mandatory Outputs: A report about the outcome of the operation. Description: The OMC-R sends a CONFIG-ATER request to the BSC, to set the flag CRC4 in the BSC, then a PROG-TRANS-ATER request. Alarms “LocalReinitRequired” will be received by the OMC-R from the BSC. The checks will be started/stopped on all links respectively to the parameter value (on/off) once the operator unlocks the affected boards. This command must be synchronized with the same operation on MSC side to be operational. Exceptions: The command is refused if: • the crc4 value requested is the same as on the field;


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 141/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.18 Use Case «Change Half-rate» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service. It is triggered by the reception of the A-CONFIG-ATER event from the OMC-R operator. Pre Conditions: None. Post Conditions: None Inputs:

OPERATOR INPUTS Parameter name Purpose Optional/Mandatory Default value BSS name Identifier of the BSS Mandatory HR-presence On/Off Mandatory Outputs: A report about the outcome of the operation. Description: The OMC-R sends a CONFIG-ATER request to the BSC, to set the flag HR-presence in the BSC, then a PROG-TRANS-ATER request. Exceptions: The command is refused if: • the HR-presence flag value requested is the same as on the field;


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 142/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.19 Use Case «Change loudness» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service. It is triggered by the reception of the A-CONFIG-ATER event from the OMC-R operator. Pre Conditions: None. Post Conditions: None Inputs:

OPERATOR INPUTS Parameter name Purpose Optional/Mandatory Default value BSS name Identifier of the BSS Optional TRAU-Loudness-UL -6 db to 6 db Optional 0 TRAU-Loudness-DL -6 db to 6 db Optional 0 Outputs: A report about the outcome of the operation. Description: The OMC-R sends a CONFIG-ATER request to the BSC, to set modify the loudness value in the BSC, then a PROG-TRANS-ATER request. Exceptions: The command is refused if: • the loudness value requested is the same as on the field;


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 143/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.20 Use Case «TC Declaration» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-TC-DECLARE event from the OMC-R operator. Pre Conditions:

• TC is a TC G2.5 with TCIF (also named TC G2.5IP) • If the TC is already declared in another OMC-R (named here first OMC-R), it is

needed to import the SNMP passphrases used on the fisrt OMC-R on the second OMC-R.

Post Conditions:

• The TC G2.5 with TCIF is declared in the OMC-R Inputs:



TC IP address IP Address of the TC rack Mandatory TC Rack Name (*) Identifier of the TC rack Optional (*) TC Rack Name can also called User Label or Friendly Name. The TC rack name is discriminating at Network level. Here TC Rack Name is local to OMC-R. Remark: It is the operator responsibility to insure unicity at network level. For that it is adviced that the operator uses the same name on the TC (TC Rack Name entered locally on the TC-NEM and visible on TC MIB) that on the OMC. Outputs: A report about the outcome of the operation to the operator. If the operation is unsuccessful the OMC adds the TC additional information in the report to the operator. Description: If the operator provides no TC Rack Name, an OMC local TC Rack Name is automatically generated by the OMC. OMC-R (OAM/DCN) sends message GET-SNMP to the BSC to get the full list of BSC Identifiers known in TC. The BSC identifier consists in a couple BSC Number (BSC identifier known in OMC also named BSC Id) and OMC Host ID (OMC master host identifier). The supervising BSSIM is autonomously selected. If the BSC Identifiers List does not refer any known BSC, TC supervision is not started. Supervising BSSIM selection: A (G2 or Mx) BSSIM is a possible candidate for the TC supervision if its release is at least a B10 release. The supervising BSSIM is choosen from the list of BSCs connected to that TC (The list reported by TC).


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 144/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

If more than one candidate, the one with the lowest ID is choosen. If, at the end, no supervising BSSIM is available or the supervision could not be started, the label “Unsupervised” is added to the TC Rack Name at OMC-R. Exceptions: An error message is displayed to operator:

• If TC IP address is already used • If TC Rack Name is already used • TC has no BSC Identifier • In case of connection problems, after a predefined number of retries in the follow-up

view.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 145/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.21 Use Case « TC Removal» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-TC-REMOVAL event from the OMC-R operator. Pre Conditions: The TC information is registered in OMC-R database. Post Conditions: The TC information for the concerned TC rack is removed on the OMC-R database. Inputs:



TC IP address IP Address of the TC rack Mandatory TC Rack Name (*) Identifier of the TC Optional (*) TC Rack Name can also called User Label or Friendly Name. The TC Rack Name is discriminating at Network Level. Here TC Rack Name is local to OMC-R. Outputs: A status report about the outcome of the operation to the OMC-R operator Description: The OMC-R operator requests that all the TC information stored in OMC-R database for this TC is removed.

o All the information about the TC rack is removed. o The OMC-R stops the TCIF supervision: the supervising BSSIM is removed for this

TC rack. Remark: The TC is removed from the OMC independently from BSC/TC configurations (TCSL endpoints can be kept alive in BSC or in TC). This allows OMC-R reorganization independently from the network. Exceptions: The TC removal is refused by OMC-R if:

� The TC Rack Name is unknown in the OMC-R � TC IP address is wrong � TC information for this TC is already removed

OMC-R warns the operator:

� If this TC is already removed � If a known BSC is associated with the TC


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 146/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.22 Use case «Display TC Data» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-DISPLAY-TC-DATA event from the OMC-R operator. Pre Conditions: OMC-R knows the concerned TC rack and the BSC(s) known by this TC rack Post Conditions: For the concerned TC rack TC data are displayed. Inputs:



TC IP address IP Address of the TC rack (identifier of the TC rack)

Mandatory

Outputs:

OPERATOR OUTPUTS Parameter name Purpose Optional/


Supervising BSC number Identifier of the supervising BSC Only present if supervising BSC is defined.

Optional

List of related BSC Identifier of all BSC known by the concerned TC rack

Mandatory TC side endpoints per BSC TC side TCSL endpoints per BSC Mandatory BSC side endpoints per BSC BSC side TCSL endpoints per BSC Mandatory Description: On the reception of the event A-DISPLAY-TC-DATA from operator the OMC-R displays the TC Data for the requested TC rack. Exceptions: If none TC Data are associated to the requested TC rack the operator will be informed.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 147/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.23 Use case «Update TC Information» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-UPDATE-TC-INFO event from the OMC-R operator. Pre Conditions: None Post Conditions: TC information is updated Inputs:



TC IP address IP Address of the TC rack (identifier of the TC rack)

Mandatory

Outputs: A report about the outcome of the operation to the OMC-R operator. If the operation is unsuccessful the OMC adds the TC additional information in the report to the operator. Description: On the reception of the event A-UPDATE-TC-INFORMATION from operator the OMC-R (DCN) requests by SNMP GET the list of BSC Identifiers on the concerned TC rack. The OMC-R updates the BSC association for this TC rack. Exceptions: The command is refused if:

• The TC is unreachable from the OMC-R


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 148/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.24 Use case «TCSL Resynchronisation» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-TCSL-Endpoints-Resynchronization event from the OMC-R operator. Pre Conditions:

• OMC-R is aligned with the BSC

Post Conditions:

• The TCSL endpoints are updated in OMC-R. • OMC-R, TC and BSC are aligned regarding the end points.

Inputs:



TC list List of TCs

Optional BSC List List of BSC (BSC must be MX BSC, at

least in maintenance release supporting IP)

Optional All declared BSC (at least in maintenance release supporting IP)

Outputs: A status report about the outcome of the operation to the OMC-R operator Description: The OMC-R operator requests the TCSL resynchronization. On the reception of the message A-TCSL-Endpoints-resynchronization, and whatever the operator answer (List of TCs, lists of BSCs), the execution is processed by the concerned BSSIM in OMC-R. Remark: The concerned BSSIM will be:

o All MX BSSIM at least in Maintenance release supporting IP in case of all declared BSCs (“whole OMC” case)

o The related BSSIM in case of list BSC (Not the default case). o All MX BSSIM at least in Maintenance release supporting IP associated to each TC

found TC list. For each TC OMC-R (DCN) requests by GET SNMP to TC the list of BSC (in fact list of BSC Identifiers). If the Get response is successful, OMC-R (OAM/DCN) establishes, per BSC, the list of connected TC racks. Be careful the OMC-R must not remove an unknown BSC (unknown


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 149/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

BSC Identifier) in OMC-R but known in TC because this BSC could be known in another OMC (Multi-OMC case). For each BSSIM the set of associated TC racks is formed. Then each BSSIM checks the set of associated TC racks with the previous set of associated TC racks and executes: o For each TC racks removed, BSSIM will perform a “detach”:

• Clearing the BSC side TCSL endpoint in TC in sending a SNMP set. Remark: If BSSIM was the supervising BSSIM for a removed TC racks OMC-R plays again the selection of the supervising BSSIM on the remaining BSSIM associated to this TC racks

o For each new TC rack, BSSIM will perform Full TCSL setup: • Requesting by SNMP Get the TC side TCSL endpoint. • Setting the BSC side TCSL endpoint in TC in sending a SNMP set.

o For each known TC racks, BSSIM compares the TC side TCSL endpoint (current and previous) and the BSC side TCSL endpoint and in case of differences

• BSC side TCSL endpoints in TC are updated • TC side TCSL endpoints in BSC are updated

Then OMC-R sends M_LogicalParam_Modify message to BSC and in BSC o For each TC racks removed: BSC unsets the TC side TCSL endpoints o For each new TC rack: BSC sets the TC side TCSL endpoint and the BSC side TCSL

endpoint o For each known TC racks: BSC updates BSC side TCSL endpoints and TC side TCSL

endpoints. OMC-R acknowledges the operator request. Remark: In case of resynchronization in the scope of OMC-R from all TCs or from all BSCs the results must be the same. Remark: TC is the reference for TCSL endpoints in TC side. BSC is the reference for the TCSL endpoints in BSC side. Exceptions: The command is refused if: • All TC racks are unreachable.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 150/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.25 Use Case « BSC/GPU IP Association» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-BSC/GPU IP Association event from the OMC-R operator. Pre Conditions: None. Post Conditions: None Inputs:



GPU Id Identity of the GPU Mandatory BSC Id Identity of the BSC Mandatory Outputs: A status report about the outcome of the operation to the OMC-R operator Description: The OMC-R operator requests the downloading of the GSL endpoints for all GPU of this MFS on all BSS associated to this MFS. Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 151/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.26 Use Case « BSS Transport Mode Switch » Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-BSS-TRANSPORT-MODE-SWITCH event from the OMC-R operator. Pre Conditions: For switch from TDM to IP:

• The Atermux are configured either as pure CS Atermux either as pure PS Atermux (No PS/CS mixed Atermux)

Post Conditions: The BSS Transport Mode is changed (from TDM mode to IP mode or from IP mode to TDM mode). Inputs:

OPERATOR INPUTS

Parameter name Purpose Optional/ Mandatory Default value

BSS Transport Mode Identifier of the requested BSS transport mode:

• IP Mode or

• TDM Mode

Mandatory

Outputs: A report about the outcome of the operation to the OMC-R operator. Description: The OMC-R operator requests the BSS transport Mode change from TDM Mode to IP Mode or from IP Mode to TDM Mode. On the reception of A-BSS-TRANSPORT-MODE-SWITCH, If the BSS transport Mode change is from TDM Mode to IP Mode, the OMC-R checks:

• The BSC is Mx Generation • TCSL endpoints are configured for every TC the BSC is connected to. • No CS/PS mixed Atermux is allowed: every Atermux linked to the MFS is

GPRS dedicated; every other Atermux is mixed 0%. • BSS-TEL is disabled • All the NSEs linked to that BSS and having children IP Endpoints have the

same configuration (GboIP-static configuration or GboIP-Dynamic configuration)

If the BSS transport Mode change is from IP Mode to TDM Mode, the OMC-R checks:

• BSS-TEL is disabled


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 152/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

In case of successful checks the OMC-R requests to BSC to change BSS transport mode in accordance with the requested BSS Transport Mode. After the reception of the M-BSS-Transport-Mode-Switch-Report from BSC, OMC-R receives the PM-Global-Stop-Report message sent by BSC at the end of the BSC reset (See IMO BSC, TC and ATER part Ref [A4]). On reception of this message OMC-R triggers the PM audit and PMs are restored. The OMC-R reports to the operator the status of the action. Remark: The current BSS mode is to be reported in the parameter group HW-SW-Overall-Type during a BSS discover for use and display by OMC-R. Exceptions: The BSS Transport Mode change request from TDM to IP is not accepted if:

• The BSC is G1/G2 Generation • One or more TCSL endpoints are not configured for every TC the BSC is

connected to • CS/PS mixed Atermux is present (only in case of BSS Transport mode

Change from TDM to IP) • BSS-TEL is not disabled • All the NSEs linked to that BSS and having children IP Endpoints have not the

same configuration (GboIP-Static configuration and GboIP-Dynamic configuration)

The BSS Transport Mode change request from IP to TDM is not accepted if:

• BSS-TEL is not disabled If the target mode (requested by operator) is in fact already the current mode in BSC:

• BSC sends an error to the OMC-R (BSC already in IP) and the OMC-R warns the operator. (Remark: To suppress the discrepancy between the 2 databases (OMC and BSC) the BSC audit will be required.)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 153/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.27 Use Case « Move TC supervision to another BSSIM» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-MOVE-TC-SUPERVISION-TO-ANOTHER-BSSIM event from the OMC-R operator. Pre Conditions:

o OMC-R is in maintenance release supporting IP. o A BSSIM supervises the TC rack.

Post Conditions: The target BSSIM supports TC supervision. Inputs:



Target BSSIM number Identifier of the target supervising BSSIM for the considered TC rack

Mandatory

Outputs: A report about the outcome of the operation to the OMC-R operator. If the operation is unsuccessful the OMC adds the TC additional information in the report to the operator. Description: An OMC-R view could propose a list of Target BSSIM (BSSIM of MX BSC known by the TC rack) to the operator. The operator selects a Target BSSIM. The OMC-R checks the criteria of supervising BSSIM for the target BSC: It is a MX BSC known in by the TC rack and at least in B10 release. The supervising BSSIM is moved from the current to the new target. Exceptions: The command is refused if:

• The target BSSIM does not fit the selection criteria • The target BSSIM does not know by the TC


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 154/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.28 Use Case «Update TC supervision» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-UPDATE-TC-SUPERVISION event from the OMC-R operator. Pre Conditions: A BSSIM is associated to each BSC known by this TC rack. Post Conditions: TC rack has a supervising BSSIM. Inputs:



Outputs: A report about the outcome of the operation to the OMC-R operator. If the operation is unsuccessful the OMC adds the TC additional information in the report to the operator. Description: On the reception of the event A-UPDATE-TC-SUPERVISION from operator the OMC-R selects a supervising BSSIM in respect of the criteria of supervising BSSIM selection. Exceptions: If none of the BSC fits the supervising criteria OMC-R is not able to associate a supervising BSSIM and from the operator view this TC will appear in a special manner as not being supervised.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 155/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.29 Use Case «BSC/TC STM1 Declaration/Undeclaration» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-STM1-DECLARE event from the OMC-R operator. Pre Conditions:

• TC is TC G2.5IP • BSC is MX BSC

Post Conditions:

• STM1 interfaces are declared or undeclared. Inputs:



STM1 Interface List per NE List of STM1 interfaces wanted by the operator for each concerned NE (BSC/TC)

Mandatory

Outputs: A report about the outcome of the operation to the operator. If the operation is unsuccessful the OMC adds the TC additional information in the report to the operator. Description: The STM-1 feature is optional from a commercial viewpoint. Operators buy the feature with a maximum number of STM1 interfaces per OMC. The operator is able to declare and to undeclare STM1 interfaces using OMC (DCN) screens. The operator can access to all NE’s at the same time. The OMC diplays for a NE (TC or BSC), the 4 STM1 interfaces with their current “declaration status” (ie declared or not). The operator can then mark not-declared interfaces or unmark declared ones. OMC first starts with the NEs that have a decreased number of STM-1 interfaces. A STM-1 interface cannot be undeclared while ‘in use’ ie STM1 VC12 connected on in case of TC. At the reception of the A-STM1-DECLARE event from the OMC operator the OMC has to check the total number of declared STM1 interfaces in all BSC and TC in front of the upper limit. When this number is close to the limit, the current threshold “WarnThreshold-Limited-Features” is used; and a warning is issued. Then if the NE type is BSC the OMC checks that the BSC have both TPGSM with STM1 capability and the OMC flags the interfaces to be removed. If the NE type is a TC The OMC sends a message SET-SNMP with the list of STM1 interfaces to TC.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 156/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

On the SET-SNMP-RESP message successful:

• The OMC sends a GET-SNMP message to get the list of the STM1 interfaces declared in TC.

• For the new declared STM1 interfaces, SBL STM1-ITF(s) is/are created in (unlocked, disable, dependency) state and SBL STM1-TTP are created in (locked,.,.) state. When SBL STM1-TPP is created, its “current” section trace is initialized to the default value

• For the new undeclared STM1 interfaces, OMC removes the required SBL STM1-ITF and associated SBL STM1-TTPs. Alarms on those STM1-TTPs are cleared.

• OMC builds the new functional view. • OMC supervises the STM1. At any time, OMC must know the state of the STM1_ITF

and the state of each STM1_TTP that must be seen on screen. On the SET-SNMP-RESP message unsuccessful:

• OMC keeps the current state of STM1 interfaces (declared/undeclared) • OMC keeps the current number of STM1 interfaces.

If the NE type is a BSC The OMC sends the “STM1 activation” message then receives the ”STM1 activation_Rep” message with the list of added SBL and the status. If the status is nok the OMC triggers a BSC audit. Else The OMC creates the added reported SBLs and removes the flagged ones. Then OMC builds the new hardware equipment view and the functional view. Exceptions: An error message is displayed to operator:

• If the total number of STM1 interfaces exceeds the limit allowed (rejected by OMC) If the NE type is a TC • If the declaration/undeclaration is rejected by the TC • If STM1 VC12 is configured on the STM1 interface to undeclared (rejected by OMC) If the NE type is BSC • If at least one TPGSM have not the STM1 capability • If HWAY-TP are configured on the interface to be removed • If the activation is rejected by the BSC

A warning is displayed to operator:

• When the total number of STM1 interfaces is close to the limit. • If the list required corresponds to the current list of delared STM1 interfaces.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 157/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.30 Use Case «Modify BSC SS7 Transport Mode» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-Modify-SS7-Transport-Mode event from the OMC-R operator. Pre Conditions: Case of activation of the “A signalling over IP”

• The BSC is Mx Generation • At least one ASL is configured

Case of deactivation of the “A signalling over IP” • None

Post Conditions:

• The SS7 transport mode is modified. Inputs:



A-SIGNALLING-OVER-IP The flag for the feature A signalling over IP. The values are:

• Enabled • Disabled

Mandatory

Outputs: A report about the outcome of the operation to the operator. Description: On the OMC-R screen it is allowed to enable/disable the A signalling over IP feature. If A-Signalling-over-IP flag is enabled, the OMC-R checks that A signalling over IP is compatible and licensed.

The OMC-R sends the M-LogicalParam-Modify message with parameter group “No7-Netw-Addr-Type” including the A signalling over IP parameter to the BSC. After the reception of the M-LogicalParam-Modify-Report from BSC, OMC-R receives the PM-Global-Stop-Report message sent by BSC at the end of the BSC reset. On reception of this last message OMC-R triggers the PM audit and PMs are restored. The OMC-R reports to the operator the status of the action. Exceptions: The command is rejected:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 158/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• If the A signalling over IP is requested and not licensed. • If the A signalling over IP is requested and not compatible.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 159/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.31 Enable/Disable Optional features Related BSS service: None Pre conditions: None. Post conditions: None Inputs: None. Outputs: None. Description: The OMC-R uses at starting time an encoded configuration file to grant access to optional features depending on what a particular customer has bought. The default value of the feature controlling parameters is FALSE. And it is set to TRUE for licensed features. If this encoded configuration file is not present or is modified, all optional features are locked. Unlocking an optional feature If a new feature is bought by an operator the feature controlling parameters can be changed to TRUE via the installation of a new encoded configuration file provided by Alcatel and a restart of the OMC software. Locking back a feature This is a rare operation. In general, setting back the feature controlling parameter will not automatically prevent the system from using it. It is agreed that setting back a feature controlling parameter will prevent further activation of the feature but will not necessarily prevent it from operating where already established. This operation is also performed via the installation of a new encoded configuration file provided by Alcatel. Activate/deactivate an optional feature For Hardware Configuration Management the optional features and the related parameters to activate/deactivate the feature in the BSC are listed in the table below. Feature Parameter Statistical Multiplexing At creation or modification of a BTS, selecting statistical multiplexing

(16kb/s or 64kb/s) for the multiplexing rule parameter does the activation of this feature. The statistical multiplexing choice is not possible if the feature is locked.

Remote Inventory For remote inventory on demand, the activation is done by a menu option. This menu option is not reachable if the feature is locked. For automatic remote inventory, setting the administrative state to unlock does the activation. The default value for the administrative state is "lock". The menu to change the state is not reachable if the feature is locked.

STM1 The STM-1 feature is optional from a commercial viewpoint. Operators buy the feature with a maximum number of STM1 interfaces per OMC. This maximum number concerns STM1 interfaces generally speaking, that


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 160/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

means taking into account STM1 links of all the declared TC but also BSC ones. An STM1 interface represents a pair of protected STM1 link. STM1 declaration from operator action does the activation of this feature.

For Hardware Configuration Management the optional features and the related parameters to activate/deactivate the feature in the TC are listed in the table below. Feature Parameter STM1 The STM-1 feature is optional from a commercial viewpoint.

Operators buy the feature with a maximum number of STM1 interfaces per OMC. This maximum number concerns STM1 interfaces generally speaking, that means taking into account STM1 links of all the declared TC but also BSC ones. An STM1 interface represents a pair of protected STM1 link. STM1 declaration from operator action does the activation of this feature.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 161/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.1.32 Limitation of some features Related BSS service: None Pre conditions: None. Post conditions: None Inputs: None. Outputs: None. Description: For some customers, some features are explicitly limited to a number of applications. The OMC-R uses an encoded configuration file to keep the maximum values allowed for a certain OMC. Each time operator activates this type of feature; OMC keeps updated the total number of applications of the feature and compares it to the allowed maximum. If the total number of applications is above ‘maximum * WarnThreshold-Limited-Features / 100’, OMC displays a message in the follow-up to inform the operator. If the total number of applications reaches the allowed maximum, any configurations (via SC or via PRC activation) will be refused by the OMC. Operator must absolutely go back below the maximum. If there is no limitation, the value stored in the configuration file is set to a high value in order that there is never any message or PRC blocking. OMC reads the file each PRC activation; therefore, evolution of the encoded configuration does not require any restart of any OMC process. The parameter WarnThreshold-Limited-Features is changeable by OMC operator. For Hardware Configuration Management, the controlled features are: Feature Parameter DR TRE Operator can configure some TRE as DR for a certain BTS/sector, thus

allowing the support of more traffic channels. Twin TxDiv Operator can configure Twin module either as two TRE, or with a TRE

working in TxDiv [Transmission Diversity] mode. BTS with more than 12 RSL

RSL can be configured from OMC or from BTS, through plug and play. Thanks to the Twin and the 'BTS with 24 TRE' feature, operator can install more TRE in one BTS cabinet. The parameter controls the number of RSL above 12 RSL in a BTS. (TRE modules plugged on site but not configured are not taken into account).

STM1 in TC STM1 in BSC

At the reception of the STM1DECLARE event (STM1 declaration scenario) from the OMC operator the OMC has to check the total number of declared STM1 interfaces in all BSC and TC in front of the upper limit. When this number is close to the limit, the current threshold “WarnThreshold-Limited-Features” is used; a warning is issued at declaration time. The general policy for limitation of optional features in OMC (check at RNIM) is also applying (useful in case of TC move) ie basic operation at OMC is blocked (like PRC blocked…).


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 162/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.1.2 Dimensioning Data

BTS inventory files: The formula for the calculation of the current inventar file is: 2KB + 120*number of RITs A G3 (12 TRE) has maximum 29 RIT. A G4 (18 TRE) has maximum 40 RIT=> the file size reach about 7 KB. The maximum size of a RI is estimated to 16 kbytes. The measured compression rate is about 5. It means that the maximum size for actual configuration of a transferred BTS inventory file is 3.2 KB.

5.1.3 Object Model This section is not relevant in the context of the B11.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 163/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2 BSC Description

ACID – Atomicity (all or none happens), Consistency, Isolation and Durability – property is guaranteed by the BSC for all the individual transactions except the prog-trans-abis command (not relevant for display commands such as get-TS-map). This is achieved by mean of the DUT table, wherein all the database updates are logged. This table is committed, respectively rolled back, before transmitting a successful, respectively unsuccessful, command report back to the OMC.

5.2.1 Use Case Description The table below gives the initial state values of the SBLs created during each BSC Use case:

Use case SBL State Activate new BSC standard configuration (Extension)

DTC, TCU, TSC, For G2 BSC:

SWITCH, BC-RACK → IT CLK-REP, CONV, BSC-ADAPT → IT SM-ADAPT (BSC-side) → IT

Else for Mx BSC: CP-HW, CP-LOG, → IT ETU → IT

Endif ATR → OPR ACH → SOS ATER-HWAY-TP (BSC side)→ OPR A-BIS-HWAY-TP → OPR N7s → OPR

Activate new TC standard configuration (Extension) TC-Adapt, TC16 → IT (****) SM-Adapt (TC-side) → IT (***) ATER-HWAY-TP (TC-side) → OPR A-PCM-TP → OPR

BSC Hardware Audit N/A TC Hardware Audit N/A Modify AterMux GPRS N7s → OPR

TC-Adapt, TC16 → IT (****) SM-Adapt (TC-side) → IT (***) ATER-HWAY-TP (TC-side) → OPR A-PCM-TP → OPR

Ater Signalling Configuration N/A Configure Ater N/A Program Ater Transmission N/A Change N°7 mode from LSL to HSL or from HSL to LSL

New N°7 SBL � IT state Case Change N7 mode from HSL to LSL

ATR � OPR ACH � SOS ATER-HWAY-TP (TC side) � OPR A-PCM-TP � OPR SM-ADAPT (TC side) � IT TC-ADAPT � IT


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 164/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

TC16 � IT BSC-TC Audit Per new MT120

TRAU-CP � IT A_PCM_TP � IT ATER_HWAY_TP (TC side) � IT ATER_HWAY_TP (BSC side) � IT

CS_ATERMUX � IT

Modify TC Characteristics For BSC in IP Mode, if a TCSL is added in BSC TCSL � IT TC-OM � IT

Modify MFS Characteristics For BSC in IP mode IP-GSL � Instantiated (IT)

BSS Transport Mode Switch From TDM to IP mode in BSC N_TCSL (one SBL per associated rack) � IT N_TC-O&M (one SBL per associated rack) � IT IP-GSL � Instantiated (IT)

From IP mode to TDM in BSC SM-ADAPT (TC side) � IT TC-ADAPT � IT TC16 � IT

Modify BSC SS7 Transport Mode STM1 Activation For each interface to be activated

STM1-ITF � OPR 2 associated STM1-TTPs � OPR

Getting current or candidate BSC STM1 Configuration

N/A

Getting current or candidate BSC STM1 Configuration properties

N/A

Setting a candidate BSC STM1 configuration N/A Applying a candidate BSC STM1 configuration

N/A

Display of section and path traces N/A Modification of transmitted section and path traces

N/A

BSC plug identification information N/A N/A=Not applicable (***) For the TC G2.5 or in case of an MT120 board in a TC G2 rack, this SBL represents all the functions of the MT120 board instead of the sub-multiplexer. (****) In the case of MT120 board, these SBL are created but not reported to the OMC.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 165/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.1 Use Case «Activate new BSC/TC standard configuration» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-ACTIVATE-NEW-CONF message followed by the reception of the A-PROG-TRANS message from the field operator. Pre Conditions: None. Post Conditions: New BSC/TC standard configuration is introduced and activated. Inputs:

OPERATOR INPUTS VIA BSC LOCAL TERMINAL A-ACTIVATE-NEW-CONF


BSC Target configuration Defines the new BSC target configuration (If it is a G2 BSC then value from 1 to 6; if it is a MX BSC then value from 11 to 15).).

Optional

TC Target configuration Defines the new TC target configuration (If it is a G2 BSC then Value from 2 to 18; if it is a MX BSC then value from 2 to 48)

Optional

WTC Period Wait for traffic clear period Mandatory in case of BSC reduction

OPERATOR INPUTS VIA BSC LOCAL TERMINAL

A-PROG-TRANS Parameter name Purpose Optional/

Mandatory Default value Outputs: For each operation: A report about the outcome of the operation to the BSC-TE operator Description: BSC must check that:

• current BSC or TC standard configuration is different from the new selected one; • BSC and TC target configuration selected are compatible, means the BSC

configuration, in terms of Ater-mux terminations, must have equal or more capacity than the TC configuration;

• Selected standard configuration is compatible with the BSC and TC hardware installed


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 166/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

For BSC extension: A BSC database population corresponding to the new standard configuration is made. It is important to note that the N7s are also created by the BSC according to the standard. If the BSC is a G2 BSC then the BSC performs a global test to check BSC hardware installed. If the global test is good then the BSC brings the new hardware into service and sends a BSC HW synchronisation request message (M-ALARM-REPORT(BSC,HW_Resynch,Event)) to the OMC-R. If the BSC is a MX BSC then auto-tests are performed on all boards at reset. If one or some boards are in fault, the normal case of failure treatment is applied. But, with or without failure boards, the BSC brings the new hardware into service and sends a BSC HW synchronisation request message (M-ALARM-REPORT(BSC,HW_Resynch,Event)) to the OMC-R.

For BSC reduction If the BSC is a G2 BSC the BSC must deny the whole reduction when there is at least one TCU candidates for removal for which an OML/RSL is equipped. The BSC autonomously disables SBLs to be removed (and remove them), using WTC period when relevant and a BSC HW synchronisation request message (M-ALARM-REPORT(BSC,HW_Resynch,Event)) is sent to the OMC-R. If the BSC is a MX BSC, the “BTS grouping” algorithm is running

If all CP-HW are “in traffic” (IT state) Find out all impacted CCPs, which include the CP-LOGs to be removed and the CP-HWs to be removed physically;

IF any of the CP-LOGs to be removed are not mapped on the CP-HWs to be removed, THEN

Remap the CP-LOG and CP-HW for all impacted CCPs, to make sure the last CP-LOG is mapped on the last CP-HW, and so on.

EndIF Check the CP-LOGs to be removed are empty (i.e. with no more signalling links (no RSL/OML) mapped on it) IF the configuration is changed from 5,4 or 3 to 2 or 1:

Check no BTS are connected to Abis-Hway-TP 97 to 176 EndIF Check no HSL on Atermux to be removed Check no TC connected to the CS Atermux to be removed Check Atermux to be removed are not Dedicated PS BSC removes the SBLs linked to the CCPs to be removed. BSC resets all impacted CCPs.

EndIF EndIF

For example: To reduce BSC configuration from 5 to 2. CCP configuration is: CP-HW: 3 4 5 6 7 8 CP-LOG: 4 5 6 7 3 CP-HW 8 is spare CCP. CP_LOG to be removed are 5, 6,and 7, the corresponding CP_HWs are 4, 5 and 6 CP_HW to be removed are 6, 7 and 8


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 167/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Then the impacted CCPs are 4, 5, 6, 7 and 8 After remapping, CCP configuration is: CP-HW: 3 4 5 6 7 8 CP-LOG: 4 3 5 6 7 Then the CP_HW and CP_LOG to be removed are totally matched, and can be easily removed.

For TC extension

A BSC data base population corresponding to the new transcoder configuration is performed by the BSC. All SBLs describing the added transcoder equipment and all termination point SBLs corresponding to them shall be created (for initial states see chapter 5.2.1).

The receipt of the A-PROG-TRANS message from BSC-TE triggers the TC discovery

phase. For MX BSC/G2 BSC: The TC discovery phase takes place to fill in the actual RIT type, to determine the actual R/S/S and in case of MT120 to fill in the MT120 capabilities. For each board to identify, In first BSC sends an Equipment-Identity-request message (Qmux message see Ref [A1] TSC-NE communication Protocols Specification) to TC and receives an Equipment-Identity-report message from TC, with inside a string representing the RIT Type. In this message:

• TC G2 board ASMC reports “SM2M ” • TC G2 board ATBX reports “ATBX ” • Legacy MT120 board with B10MR1 SW or with B9 SW reports “MT120 ” • Legacy MT120 board reports “MT12 ” • MT120-NB board reports “MTNB ” • MT120-WB board reports “MTWB ”

BSC transcodes the received string into the corresponding RIT Type then BSC stores the RIT type. Then BSC sends a functional-identity-request message (Qmux message see Ref [A1] TSC-NE communication Protocols Specification) and receives a functional-Identity-report message from TC. The board type “MT120” is sent from TC for any generation of MT120 (as today for the legacy one). In case of any generation of MT120 the TC rack type (G2 or G2.5) and the actual R/S/S is also sent from TC. In case of TC G2 Boards (ASMC or ATBX) BSC copies the RSS information from the TC G2 CPF file. BSC stores the RSS. Then IF the received string in Equipment Identity report identifies an MT120-NB or an MT120-WB or a legacy MT120 with B10MR2 software and more: BSC sends a capability request (Qmux message) to the TC to get the capabilities of the MT120. BSC updates the capabilities of the MT120 in DLS. Else IF the received string in Equipment Identity report identifies a legacy MT120 with B10 MR1 software or B9 software No message sent to TC from BSC


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 168/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

But the BSC sets the capabilitiesof the MT120to “0” in the DLS, which means AMR-NB capability. Else IF the received string in Equipment Identity report identifies an ASMC board or an ATBX board,No message sent to TC from BSC BSC does not set the capabilities in the DLS; BSC sets value “FF” in DLS for “not relevant”. Endif Endif BSC translates RIT type in RIT value. BSC updates the DLS with the following informations:

o RIT and RSS o CIC capability for telecom usage

BSC starts a (15’) timer before sending the TC-HW-RESYNCH. If the timer is already running, it is cancelled and restarted (see below note 1).

The BSC performs automatic configuration of the SM-Adapt and TC-Adapt at TC side as soon as the transmission equipment is reachable through the remote Q1 bus.

(Note 1) When the first TC board is identified BSC starts a timer (remark: this timer is set

to 15’ in BSC); in all the others cases where the timer is running the timer is restarted. The purpose is to avoid too many TC-HW-RESYNCH events to OMC in case of TC

extension by multiple boards. End for On the expiry of the timer, at any time, the BSC sends a TC HW synchronisation request

message (M-ALARM-REPORT(BSC,TC_HW_Resynch,Event)) to the OMC-R. Note: The BSC have to take care of the dedicated GPRS AterMux before creating the SBLs of the TC side : some holes into the BSC sequence may exist. Indeed, if the AterMuxi is a dedicated GPRS AterMux there is no corresponding SM ADAPTi(TC). See the following figure example: the SBLs at TC site corresponding to the 3rd AterMux are not equipped (as well as the SBLs corresponding to the potential 6th AterMux).


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 169/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Notes :

1- The difference within the BSC DB between AterMux n°3 and the potential AterMux n°6 is the Ach-GPRS-CS parameter values of its corresponding Aters (for AterMux n°3 the Ach-GPRS-CS bitmaps ≠ ‘0000’h). So, when an AterMux is unequipped (TC reduction from BSC terminal) its corresponding Ach_GPRS-CS bitmaps shall be set to ‘0000’h). 2- The AterMuxUsage value shall be set to “mixed” if it is set to “dedicated” without GPRS (i.e.: all tributaries have their Ach-GPRS-CS parameter set to ‘0000’h)

For TC reduction TC reduction is in the scope of MX B11 System. The respective SBLs are removed from the BSC database. (See note1 of TC extension)

Note: If the AterMuxUsage is not dedicated, the AterMuxUsage value shall be set to “dedicated” and the ACHs kept as GPRS shall be re-configured into CS.

Remark: The GSL link should not be present because the engineering rules shall have prevented its presence before TC reduction (see “TC reduction” within the table of chapter 4.2.7).

Notes: � The definition of the D-TC-CONF parameter used for TC extension/reduction is the

following: Position of the last mixed AterMux � The support of holes into the BSC configuration (dedicated AterMux with 0% GPRS)

between mixed AterMuxes. It can be the case when the AterMux3 in the previous example is set to dedicated 0% by the OMC.

Exceptions: In case of MX BSC reduction, a negative report is sent if:

BSC (Config2

TC MFS

AterMux 5

AterMux 4

AterMux 3

AterMux 2 AterMux 1


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 170/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• The configuration is changed from 5,4 or 3 to 2 or 1 and BTS are connected to Abis-

Hway-TP 97 to 176; • CP-LOG to be removed are not empty • CP-HW boards are not all in traffic • HSL on Atermux to be removed • TC connected to the CS Atermux to be removed • Atermux to be removed are Dedicated PS


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 171/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.2 Use Case «BSC hardware audit» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-LOGICALPARM-DISPLAY Messages from OMC R following by M-CONFIG-DISPLAY message from the OMC-R. Pre Conditions: If the BSC is a G2 BSC No BSC extension/reduction in progress. If the BSC is a MX BSC no BSC extension/reduction in progress. Post Conditions: If the BSC is a G2 BSC the hardware audit file is available for FTAM transfer.

If the BSC is a MX BSC the hardware audit file is available for FTP transfer.

Inputs:

Message M-LOGICALPARM-DISPLAY{XE "M-LOGICALPARM-DISPLAY"} FROM THE OMC-R Parameter name Purpose Optional/Mandatory BTS number Identifier of the BTS Mandatory Parameter group Identifier of the parameter group. Mandatory

Message M-CONFIG-DISPLAY{XE "M-CONFIG-DISPLAY"} FROM THE OMC-R Parameter name Purpose Optional/Mandatory Configuration area Type of the configuration display

desired (BSC / TC / ABIS LINKS for this use case)

Mandatory

Message M-FILE-READ{XE "M-FILE-READ"} FROM THE OMC-R

Parameter name Purpose Optional/Mandatory File identifier Identifier of the file which the OMC-R

has successfully read Mandatory

Outputs:

Message M-LOGICALPARM-DISPLAY-REPORT{XE "M-LOGICALPARM-DISPLAY-REPORT"} TO THE OMC-R

Parameter name Purpose Optional/Mandatory Usage of the BTS characteristics

Content of the parameter group Optional

Status Status about the outcome of the operation

Mandatory

Message M-CONFIG-DISPLAY-REPORT{XE "M-CONFIG-DISPLAY-REPORT"} TO THE OMC-R

Parameter name Purpose Optional/Mandatory File identifier Identifier of the file including audit data

for transfer Optional

File size size of the file Optional Status Status about the outcome of the

operation Mandatory


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 172/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Message M-FILE-READ-REPORT{XE "M-FILE-READ-REPORT"} TO THE OMC-R Parameter name Purpose Optional/Mandatory Status Status about the outcome of the

operation Mandatory

Description: On reception of the M-LOGICALPARM-DISPLAY Message for each following parameter group

• HW-SW-Overall-Type • Cic-Atrk-Type • No7-Netw-Add-Type • GPRS-BSC-Type • Bts-Id-To-Cell-Id-Type

BSC reports the content of the parameter group. On reception of the M-CONFIG-DISPLAY message the BSC creates an audit file including the current BSC hardware/ TC hardware /Abis links configuration and returns the file identifier to the OMC-R for FTAM transfer (in case of G2 BSC) or FTP transfer (in case of Mx BSC). The transfer’s completion is indicated to the BSC with the M-FILE-READ message from the OMC-R, then the BSC deletes audit file and acknowledges transfer’s completion. In the context on change mode, “Abis target mode” is added in audit data so that the OMC can detect that the Abis is switched. Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 173/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.3 Use Case «TC hardware audit» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-CONFIG-DISPLAY message from the OMC-R with TC as type of the configuration desired. Pre Conditions: If the BSC is a G2 BSC No BSC extension/reduction in progress. If the BSC is a MX BSC no BSC extension/reduction is in progress. Post Conditions: If the BSC is a G2 BSC the TC hardware audit file is available for FTAM transfer.

If the BSC is a MX BSC the TC hardware audit file is available for FTP transfer.

Inputs:

Message M-CONFIG-DISPLAY{XE "M-CONFIG-DISPLAY"} FROM THE OMC-R Parameter name Purpose Optional/Mandatory Configuration area Type of the configuration display

desired (TC for this use case) Mandatory

Message M-FILE-READ{XE "M-FILE-READ"} FROM THE OMC-R

Parameter name Purpose Optional/Mandatory File identifier Identifier of the file which the OMC-R

has successfully read Mandatory

Outputs: Message M-CONFIG-DISPLAY-REPORT{XE "M-CONFIG-DISPLAY-REPORT"} TO THE OMC-R

Parameter name Purpose Optional/Mandatory File identifier Identifier of the file including audit data

for transfer Optional

File size size of the file Optional Status Status about the outcome of the

operation Mandatory

Message M-FILE-READ-REPORT{XE "M-FILE-READ-REPORT"} TO THE OMC-R Parameter name Purpose Optional/Mandatory Status Status about the outcome of the

operation Mandatory

Description: On reception of the M-CONFIG-DISPLAY message with TC as type of the configuration desired the BSC creates an TC audit file including the current TC hardware configuration (The MT120 RIT type, the MT120 RSS and the MT120 capabilities) and returns the file


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 174/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

identifier to the OMC-R for FTAM transfer (in case of G2 BSC) or FTP transfer (in case of Mx BSC). The transfer’s completion is indicated to the BSC with the M-FILE-READ message from the OMC-R, then the BSC deletes audit file and acknowledges transfer’s completion. Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 175/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.4 Use Case «Modify AterMux GPRS» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-LOGICALPARAM-MODIFY(GPRS-BSC-Type group) event followed by the M-LOGICALPARAM-MODIFY(Cic-Atrk-Type group) event from the OMC-R. Pre Conditions: If BSS is in IP transport mode, no TC SBLs (TRAU_CP, Ater_HWAY_TP (TC side), A_PCM_TP and CS_Atermux) must exist when an Atermux is changed to Dedicated PS. Post Conditions: ACHs used for GPRS are blocked towards the MSC, “new” SBLs are created (respectively “old” are deleted (NEQ)). Inputs:

M-LOGICALPARAM-MODIFY(GPRS-BSC-Type group) FROM THE OMCR Parameter name Purpose Optional/


AterHwayTP number Identifier of the BSC AterMux Mandatory AterMuxGPRSUsage In TDM mode

Precise if the AterMux is dedicated or mixed GPRS/CS12 In IP mode The AterMux is only dedicated

Mandatory

TC Transparency Only available in TDM mode Flag indicating if the AterMux transmission at TC site shall be configured or not.

Optional Note : Not needed (not significant) for a dedicated GPRS AterMux. - TC Transparency ==TRUE

M-LOGICALPARAM-MODIFY(CIC-Atrk-Type group) FROM THE OMCR

Parameter name (repeated for all Ater PCM of the corresponding AterMux)

Purpose Optional/ Mandatory

Default value

AtrunkId With Atrksblnbr, it identifies the Ater PCM

Mandatory AtrkSblNbr With Atrunkid, it identifies the Ater

PCM Mandatory

GicCodeAtrk GPRS identity code of channel 0 Optional Note : Not used for an Ater PCM that is part of a mixed CS/GPRS AterMux but no GPRS ACH is defined (GPRS granularity == 0%) (see AchGprsCs parameter)

AchGprsCs Indicates for each Ater PCM TS whether it carries GPRS traffic (i.e. either GIC or GSL) or CS traffic (i.e. CIC, TS0, X25, IP, Qmux, N7, AlarmOctet or Idle)

Optional none

GslOnAtrk(*) Flag indicating if a GSL LapD has to be set-up on the Ater PCM (TS28 for 4:1 mapping)

Optional none

(*) This parameter is no more supported from B8 release and could be removed but it is kept to avoid a MIB modification. 12 mixed CS/GPRS means a granularity of 0%, 12,5%, 25%, 50%, 75% 100% GPRS among the AterMux


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 176/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Note: Available in TDM transport mode: When the AterMux is changed from dedicated to mixed CS/GPRS, the ciccodeatrk & slc will be set to a default value by the OMC: values are defined in accordance with the MSC administrator. The operator will have to initialise them before setting the Atr & the N7 into service: as it is done for an AterMux extension. Outputs: A report for each logical parameter group about the outcome of the operation to the OMC-R. Description: BSC processes each parameter group (GPRS-BSC-Type or CIC-Atrk-Type) independent of the other. In some cases (slc, ciccodatrk modifications for instance) only the CIC-Atrk-Type is provided by OMC-R. But if GPRS-BSC-Type group is necessary the OMC-R must ensure that GPRS-BSC-Type is sent before CIC-Atrk-Type to keep data consistency13. For G2 BSC the OMC-R provides to the BSC the parameter groups GPRS-BSC-Type and CIC-Atrk-Type for all Atermux that are not dedicated 0%. For MxBSC the OMC-R provides to the BSC the parameter groups GPRS-BSC-Type and CIC-Atrk-Type for Atermux that are not dedicated 0% and that have been changed. If an Atermux is set to dedicated 0%, only the parameter group CIC-Atrk-Type is provided by OMC-R. At the reception of the group GPRS-BSC-Type: FOR each AterMux

If its usage is changed from dedicated to mixed CS/GPRS (only available in TDM mode): • N7 SBL is created • TC SBL to create are: 1 SM-ADAPT(TC), 4 TC-ADAPT, 1 AterHway-TP(TC), 4 A-

PCM-TP and 8 TC1614 • See chapter 5.2.1 for initial state values of the created SBLs

Else if its usage is changed from mixed CS/GPRS to GPRS dedicated: • N7 SBL (if existing) is deleted. • If BSS is in TDM mode TC SBL to delete are: 1 SM-ADAPT(TC), 4 TC-ADAPT, 1

AterHway-TP(TC), 4 A-PCM-TP and 8 TC1615 • If BSS is in IP transport mode, BSC does not remove TC’s SBLs (TRAU_CP,

Ater_HWAY_TP (TC side), A_PCM_TP and CS_Atermux) (See Pre-Condition) Endif

END FOR Then a successful report message is returned to the OMC. At the reception of the group CIC-Atrk-Type: FOR each AterMux IF in TDM transport mode

Some preliminary checks are done such as :

13 When the OMC will change the networkopmode parameter, even though, both parameter groups will be provided by the OMC 14 Some TC-TS SBLs may also be created, but are not seen at the OMC-BSC interface. 15 Some TC-TS SBLs may also be deleted, but are not seen at the OMC-BSC interface.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 177/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• GSL can be set-up only on the second tributary of an AterMux • If the last GSL is going to be removed, it shall not be operational (i.e. GSL LapD

not under used by the BSC-MFS communication) IF a GSL LapD is requested (i.e. it didn’t exist in the previous configuration) on the second tributary:

The DTC is internally reconfigured (by DTC auto-reset) See chapter 5.2.1 for initial state value of the created SBL and chapter 5.3 for the HDLC channel number assignment. And as soon as the DTC and the ATR are ready, the BSC tries to establish the LapD towards the MFS. Note : the SAPI and the TEI for the GSL LapD are respectively equal to 0 and equal to the GSL number. The GSL number is equal to the DTC number (DTC supporting the GSL LapD) in G2 BSC and equal to the Ater-HWAY-TP number in MX BSC.

END IF IF a GSL LapD shall be removed (i.e. it existed in the previous configuration) on the second tributary:

The DTC is internally reconfigured (by DTC auto-reset) END IF END IF FOR all Ach that are requested to be used for GPRS :

- the BSC sends a blocking message towards the MSC, - for those whose state is OPR, the BSC will not prevent the GPRS usage. Note : For the Ach that are declared as being used for GPRS (GICs or GSL), the

BSC will filter the “BSC-CIC-UNKNOWN” event alarm. END FOR FOR all Ach that were used for GPRS and are set back for circuit (decreasing of GPRS

on the Ater/AterMux), the BSC will send an unblocking message to the MSC (if the Ach state is IT).

END FOR

END FOR IF at least a SBL has been created or has been removed by the BSC during the processing of the CIC-Atrk-Type parameter group or during the processing of the previous GPRS-BSC-Type parameter group: An “HW resync” event alarm is generated. END IF Then a successful report to the group Cic-Atrk-Type is sent to the OMC (in particular: the GSL SBL is created (resp. deleted) and the DTC reset when the M-LOGICAL-PARAM-MODIFY-REPORT is sent to the OMC) IF changed Atermux usage from dedicated to mixed CS/GPRS (only available in TDM mode) (see § 4.2.1.2 Modify a dedicated GPRS Atermux into a mixed CS/GPRS Atermux scenario): During “init SM-Adapt” scenario (see Ref [A4] IMO), BSC triggers a TC discovery phase (See § 4.1.2.2 TC discovery phase Sub-scenario), including a TC HW resynchronisation from BSC to inform the OMC-R about the type of TC board discovered and the automatic TC hardware audit, BSC Alarm audit (Ref [A3] NSR) and BSC state audit (Ref [A3] NSR) from OMC-R. END IF


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 178/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 179/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.5 Use Case "Ater Signalling Configuration" This use case is only valid for MX BSC in TDM mode. Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-CONFIG-SIG-ATERMUX event from the OMC-R. Pre Conditions: None. Post Conditions: The signalling is programmed on BSC for this Atermux. Inputs:

M- CONFIG-SIG-ATERMUX FROM THE OMCR Parameter name Purpose Optional/


AterHwayTP number Identifier of the BSC AterMux Mandatory Outputs: A report about the outcome of the operation to the OMC-R.

Description: Whatever the modification (GSL, N7 or the GPRS granularity change) the BSC configures the GSL and the N7 on the Ater-Hway-TP at BSC side, including the TP. The BSC knows if GSL has to be added or removed based on the previously received Cic-Atrk-Type parameter group for this Atermux (TS number is fixed to TS number 28 of second ATR of the Atermux). The BSC knows if N7 has to be added or removed based on the last Modify Atermux command. Exceptions: If the TPGSM cannot be configured, the command is accepted and an alarm is reported by the BSC and the Ater-Hway-TP is set into FOS state (except if it was in OPR state).


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 180/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.6 Use Case «Configure Ater» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-CONFIG-ATER message from the OMC-R. Pre Conditions: None Post Conditions: None. Inputs:

M-CONFIG-ATER { XE "M-CONFIG-ATER" }FROM THE OMCR Parameter name Purpose Optional/


Connection type Change the Ater connection type Optional Crc4 Set to on => the CRC4 is triggered

Set to off => the CRC4 is stopped Optional

HR-presence Set to on => the TC recovery is not possible Set to off => the TC recovery is possible The parameter is kept from B10 release even this parameter is useless (to avoid to modify the MIB)

Optional

TRAU-loudness-UL Change the amplification level on up link

Optional TRAU-loudness-DL Change the amplification level on down

link Optional

The following table indicates which group of parameters is sent depending on the O&M operation. Only one group parameter is sent at a time. O&M operation Parameters sent Change Ater connection type Connection type Change CRC4 Crc4 Half-rate setting HR-presence Loudness setting TRAU-loudness-UL

TRAU-loudness-DL Outputs: Message M-CONFIG-ATER-REPORT{ XE "M-CONFIG-ATER-REPORT" } TO THE OMC-R Parameter name Purpose Optional/Mandatory Status Status about the outcome of the

operation Mandatory

Description:

Change Ater connection type The BSC modifies the value of parameters relative to Ater transmission (Enable/Disable Preventive Cyclic Retransmission, MTP2 timer, Poll response - Aitf side, T_TFO) depending on the new connection type. See reference document [12] for a complete list of parameters depending on the connection type.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 181/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

An operator BSC restart is expected to force the correct distribution of the parameters to the processors concerned.

Change CRC4 (CRC4 applied to A interface) The BSC updates the DLS: it sets all TC-ADAPT (for G2 TC) and SM-ADAPT SBLs to be reprogrammed in the ‘FOS’ state and generates the alarm ‘Local reinit required’ for each of them. The operator will have to reinit these SBLs in coordination with the modification of the MSC. The parameter CRC4 is never sent by BSC to MT120 boards. (Remark: By default CRC4 is in automatic mode on MT120 boards. MT120 boards detect the MSC CRC4 mode and adapt its own mode on the MSC one).

Half-rate setting, loudness setting The BSC updates the DLS. Exceptions: The command is refused if:

Change CRC4, half-rate setting, loudness setting • the new value requested is the same as on the field;

Change Ater connection type • no exceptions.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 182/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.7 Use Case «Program Ater Transmission» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-PROG-TRANS-ATER message from the OMC-R. Pre Conditions: An Ater reconfiguration potentially impacting the transmission have been previously issued. Post Conditions: The transmissions are programmed on all transmission Nes - Ater side. Inputs:

Message M-PROG-TRANS-ATER{ XE "M-PROG-TRANS-ATER" } FROM THE OMC-R Parameter name Purpose Optional/Mandatory Outputs:

Message M-PROG-TRANS-ATER-REPORT{ XE "M-PROG-TRANS-ATER-REPORT" } TO THE OMC-R

Parameter name Purpose Optional/Mandatory nbrsuccess Number of Nes successfully configured Mandatory nbraccessfail Number of Nes with access failure Mandatory nbrdownloadfail Number of Nes with download failure Mandatory Description: This command triggers the sending of transmission settings to all “previously marked” ASMC and all “previously marked” MT120 modules on Ater, using Qmux interface in case of G2 BSC or MX BSC in TDM transport mode and using BSC-TC Audit scenario (HCM) in case of MX BSC in IP transport mode. Note: In case of TRAU_LOUDNESS_UL or TRAU_LOUDNESS_DL modification, the MT120 module must be reset. Due to the MT120 reset there is potential loss of all calls on that MT120. This induces a temporary degradation of speech quality.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 183/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.8 Use Case «Change N°7 Mode from LSL to HSL or from HSL to LSL» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-CHANGE-N°7-MODE message from BSC Terminal. Pre Conditions: It is a MX BSC (named also BSC Evolution) It is recommended to stop the telecom traffic smoothly and for that it is advised to use BSS-TEL lock command with a WTC before changing N°7 Mode from LSL to HSL (but this is not checked). Post Conditions: The BSC database is configured with the new type of N°7. Due to the embedded reset, the BSC itself is working with the new configuration and MSC is aligned for the A channels. Both in IP and TDM, the TC is automatically updated. Inputs:

Message M-CHANGE_N°7 MODE FROM BSC terminal Parameter name Purpose Optional/Mandatory

Target N°7 mode Specify the target N°7 mode: HSL or LSL.

Mandatory First Atermux When going to HSL, specifies the first

Atermux to be used (See Remark 2) Optional, Must be present when activating HSL

Second Atermux When going to HSL, specifies the second Atermux to be used (See Remark 2)

Optional, Must be present when activating HSL

MTP-Sequence-Number-Format (See Remark 1)

Selection of the format for the “signal units” frames. Two possible values:

• With extended sequence number format (extended MTP-Sequence-Number-Format)

• Without extended sequence number format (Normal MTP-Sequence-Number-Format)

Optional

Remark 1: Note that the extended value of MTP sequence number format can only be used in HSL mode. The parameter MTP-Sequence-Number-Format is to set at LSL to HSL transition time. If missed at LSL to HSL transition time, it remains possible for the operator, once in HSL, to come back to the LSL to HSL transition window of the BSC Terminal and only change the MTP sequence number format. Remark 2: When this command is used to come back from N7 HSL to LSL, first and second Atermux parameters have dummy value. Outputs:

Message M-CHANGE_N°7 MODE_REPORT TO BSC terminal Parameter name Purpose Optional/Mandatory

Status Status about the outcome of the operation with precise identification of the reason of the failure, if unsuccessful (see exception cases)

Mandatory

Description:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 184/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Any Atermux defined in the BSC configuration could be used to support HSL. But the BSC checks that these two Atermux:

• Do not carry Qmux • Do not carry IP over Ater (also named MLPPP over Ater) • Are configured for CS traffic only • Are on two different LIU boards.

HSL is always defined on the first Atrunk of the selected Atermux.

When the command is received by BSC, the traffic is stopped if it is not already done (see pre conditions) Then it consists of following steps: - update DLS, - autonomous reset, thus leading to BSC/BTS audits, BSC/TC audits if in IP - [Embedded in BSC reset (IMO BSC, TC and Ater part Ref [A4])],telecom reset with MSC to align the A channels configuration. DLS updates Modifications are done in 3 areas:

- N°7 SBL, - Atr SBLs - A channel configuration.

The impacted TC SBLs are marked for reconfiguration as “To be reconfigured”. N°7 SBL For HSL, there are always two N°7 SBL. In TDM, these N°7 are conveyed on Atermux X (SBL N°7 n°1), and Atermux Y (SBL N°7 n°2). In IP, these N°7 are conveyed on the first tributary of MT120 X and Y. X and Y being the values given by the operator. For LSL, BSC creates N°7 SBL on the first 16 PCM [10 PCM only if 200 TRX BSC configuration] except if the corresponding Atermux is a pure PS Atermux. Atr SBL For the concerned Atermux, the Atr configuration depends on the configuration: TDM /LSL TDM /HSL IP/LSL IP/HSL 4 Atr No Atr 4 Atr 3 Atr* * The one corresponding to the first tributary is not equipped. In case of Change N°7 mode from LSL to HSL, the BSC removes the following SBL, set to NEQ state:

TDM Mode IP Mode 8 ATR (4 per Atermux) 2 ATR (1 per Atermux) Remark: DTC SBL are kept for the HSL Atrunk. In case of Change N°7 mode from HSL to LSL, the BSC creates the following SBL with the state:

OPR for ATR, ATER-HWAY-TP (TC side), A-PCM-TP IT for SM-ADAPT (TC side), TC-ADAPT, TC16


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 185/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The BSC marks the impacted ATER SBLs as “To be reconfigured” (In TDM mode the programming will be done later during the programming Ater transmissions and in IP mode during the BSC-TC audit). A channels configuration At change N°7 state from LSL to HSL:

The BSC removes the following SBLs, set to NEQ state: TDM Mode IP Mode

8 x 32 ACH (32 per Atrunk) 2 x 32 ACH (32 per Atrunk)

At change N°7 state from HSL to LSL:

The BSC adds the following SBL with the state: SOS for ACH (because the parent SBL ATR is in OPR state)

To configure the A channel, the BSC applies the principles for A channel configuration defined in chapter 2.2.9. BSC marks the impacted TC SBL for which the configuration changes as “to be configured”. Autonomous reset: During the reset, BSC forces all processors to take into account the new configuration, and especially reprograms the TP boards. At the end of BSC reset (See IMO BSC, TC and Ater part Ref [A4]), BSC resumes BSC originated alarms and changes after audit of AIFL and sends PM-Global-Stop-Report to OMC-R, then OMC-R triggers the PM audit and PMs are restored. In IP mode, thanks to the audit BSC /TC, the TC gets the new configuration. In TDM, after the BSC reset (See IMO BSC, TC and Ater part Ref [A4]), BSC scans the DLS for all transmission SBL’s that need to be configured and handles then automatically. Embedded in the BSC reset (See IMO BSC, TC and Ater part Ref [A4]), BSC triggers the MSC telecom reset. During this procedure, BSC informs the MSC about the blocked A channels. Exceptions: The N°7 change mode is not accepted: � If the target mode is already the running one. � When going to HSL, � The specified Atermuxes to be used do not fulfill following conditions: � They correspond to Atermux not supporting Qmux (different from: 1, 2, 7, 8, 13,

14….),


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 186/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

� They belong to the CS Ater subset [1..48], � The specified Atermuxes are configured for CS traffic only, � The specified Ater muxes do not carry MLPPP, � They are connected on different LIU boards, � They are supported by the current BSC configuration (in some configurations, some

ports of present LIU boards are not usable) � If BSS in TDM � Both TP do not have the capability: ‘Support of HSL’ � One Ater_Hway_TP BSC side of the specified Atermuxes is not IT.

� If BSS in IP � TRAU_CP corresponding to the specified Atermuxes are not ‘In Traffic’.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 187/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.9 Use Case «BSC-TC Audit» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by:

o From OMC: � BSS Mode Change � TCSL endpoint creation due to new TC rack (LPM TC-Peer-Entities (TMN

Administration service Ref [A6]) when the BSC is in IP mode) � BSS SW Activate � Init TC-OM (TCSL goes to IT and TC-OM is not OPR, or TCSL IT and TC-

OM goes to IT) � BSC restart (IMO) � BSC reset (IMO BSC, TC and Ater part [A4]) � Change Atermux from PS to CS � Program Ater transmission (HCM) � Modify TC characteristics (LPM TC-Peer-Entities when the BSC is in IP

mode), if anything is changed in TC-Peer-Entities (For example in case of TCSL reduction).

o From BSC: � Periodical Audit

o From TC: � The reception of the M-TC-AUDIT-NEEDED message from the TC (sent

when applying TC NEM extension/reduction screen). Pre Conditions: None Post Conditions: BSC-TC AUDIT is executed. Inputs:

Message TC-AUDIT-NEEDED FROM THE TC Parameter name Purpose Optional/Mandatory Outputs: None Description: On the reception of the message M-TC-AUDIT-NEEDED the BSC triggers the BSC-TC AUDIT scenario (HCM BSC, TC and Ater part) for each TC rack, which the MX BSC is associated to. That is realized in parallel for all concerned TC racks. In BSC, when the message TC_Audit_Needed is received, if there is already a BSC-TC AUDIT scenario (HCM BSC, TC and Ater part) ongoing on one TC rack, the new BSC-TC AUDIT scenario will be deferred after the ongoing is finished. For each TC rack, which the MX BSC is associated to:

1. MX BSC sends the message TC-Audit-Request to TC.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 188/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

BSC indicates to TC the expected MT120 SW version, the TCSL version and the code server. 2. On the reception of the message TC-Audit-Report from TC,

o For all the TC SBL corresponding to the MT120 reported, the BSC updates the TC SBL conf (SBL creation/deletion, RIT info) as well as the BSC one (for TC related SBL of the BSC model, such as CS-ATERMUX).

o Possible received RIT type from TC identifies:

� A legacy MT120 board � A MT120-NB board � A MT120-WB board

EndFor The BSC waits maximum Ns (in order to allow TC racks to be audited in parallel and have only one configuration message per TC rack. This comes from the fact that for a given BSC, every TC rack knows the boards of every other one). When all TC racks have been audited the BSC processes the received data. IF there is no MT120 reported by any TC rack,

BSC stops after the TC-Audit-Rep reception the BSC-TC Audit. TC-OM SBL and TCSL SBL remain IT (if any in IT). The TC-Config-Req and TC-Alarm-Audit are not done.

EndIF IF there is at least one MT120 reported by TC, The BSC reports an event alarm to the OMC to alert on the TC configuration issue in the following cases:

1. MT120 reported on a Dedicated PS Atermux (i.e. their Atermux number is already used for GPRS). BSC ignores this MT120 board.

2. Multiple MT120 with same Atermux number. The MT120 data (RIT/RSS/Capabilities) are overwritten with the last one found, an event is raised in OMC.

3. An MT120 is discovered with an Atermux number, which is out of range for the BSC, an event is raised in OMC.

4. No answer of a TC and incoherence “double declared MT120”. The MT120 data (RIT/RSS/Capabilities) are overwritten with the last one found, an event is raised in OMC.

BSC updates the DLS:

• BSC updates the TC SBL conf (SBL creation/deletion, RIT info) as well as the BSC one (for TC related SBL of the BSC model, such as CS-ATERMUX).

• Atermux pools are updated (one pool per TC rack that depends on MT120 and Atermux).

• BSC stores the MT120 capabilities. • BSC updates also the CIC capablilites for telecom usage.

BSC triggers resource blocking/unblocking to MSC if necessary. Then For each TC rack, which the MX BSC is associated to:

o The BSC sets in TC (See 5.5.1.14 TC configuration update) 1. The MT120 table, giving for every (BSC associated) MT120 of every

TC: - the NONMUX endpoint of its rack. 2. If the “A signalling over IP” is not activated the SS7 parameter


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 189/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

3. The legacy TC parameters In case of “A signaling over IP”, BSC doesn’t give the MTP2 parameters in the message sent to TC.

o In the M-TC-Config-Rep message, if “A signaling over IP” is not yet activated, the BSC receives the “TC SS7 endpoint” parameter and stores it in the DLS.

o BSC evaluates CS-ATERMUX and ATR resources. o BSC launches the TC-ALARM-AUDIT to request the actual active alarms for

each MT120. (Network Supervision Ref [A3]). 1. When TC reports the current alarm in BSC, BSC compares the

received alarm with its own view (IMO Ref [A4]) o When the configuration and alarm audit are finished, the BSC triggers the

BTS to primary TC mapping algorithm (see Ref [A27] HCM BTS and Abis part in Annex part) and updates the BTS accordingly.

o The TC-OM SBL state is put to IT in the BSC and the BSC informs the OMC-R from this change.

o If the BSC or TC SBL configuration has been updated then: the BSC sends an alarm to OMC-R for resynchronization of the OMC-R and BSC database.

EndFor

EndIF Exceptions: In case a request for BSC-TC AUDIT comes when the BSC-TC AUDIT scenario is being played, the BSC memorizes the need for a new initialization scenario and plays it when the previous one is finished. If several audit triggers are received during the scenario, the scenario is replayed only once. If Atermux number is unknown for BSC the BSC ignores the TC configuration and sends an event to the OMC. If same Atermux is already known as PS (100% GPRS) in BSC and reported as CS from TC nothing is done in BSC (BSC stays the Atermux as PS) and an event Alarm (“Conflict between TC configuration and BSC/MFS links”) is raised in OMC-R. If there is multiple MT120 with same Atermux number, the MT120 data (RIT/RSS/Capabilities) are overwritten with the last one found, an event is raised in OMC. If no answer of a TC and incoherence “double declared MT120”, an event is raised in OMC. If BSC would have a timeout for a given TC Rack, then the TC data of that rack remain untouched. TC-OM will then be FLT and any change will be rectified once TC-OM becomes IT and a new audit is executed.

5.2.1.10 Use Case «Modify TC characteristics»


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 190/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-LOGICALPARM-MODIFY (TC-Peer-Entities-type) message from the OMC-R. Pre Conditions: None. Post Conditions: TC peer entities characteristics are registered or modified in the BSC. Inputs: Message M-LOGICALPARM-MODIFY (TC-Peer-Entities-type){ XE "M-LOGICALPARM-MODIFY

(Hardware-BTS-Type group)" } FROM THE OMC-R Parameter name Purpose Optional/Mandatory TC-peer-entities-type TC-peer-entities-Type Mandatory Outputs: Message M-LOGICALPARM-MODIFY-REPORT{XE "M-LOGICALPARM-MODIFY-REPORT"} TO

THE OMC-R Parameter name Purpose Optional/Mandatory Status Status about the outcome of the

operation with precise identification of the reason of the failure, if unsuccessful (see exception cases)

Mandatory

Description: The BSC records the new or modified TC peer entities characteristics or removes part of TC peer entities characteristics. For BSC in IP mode: If a TCSL is removed in BSC, the related SBLs TCSL and TC-OM are deleted (NEQ). If a TCSL is added in BSC, the related SBLs TCSL and TC-OM are created (IT). If the last TC rack is removed (case of TC-Peer-Entities without TCSL), BSC cleanes up the remaining TC SBL from the DLS. For BSC in TDM mode: If a TCSL is removed in BSC, or if a TCSL is created in BSC the information is kept in DLS. Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 191/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.11 Use Case « Modify MFS Characteristics» Scenario Available for IP Transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-LOGICALPARM-MODIFY (MFS-Peer-Entities-type) message from the OMC-R. Pre Conditions: None. Post Conditions: MFS peer entities characteristics are registered or modified in the BSC. Inputs:

Message M-LOGICALPARM-MODIFY (MFS-Peer-Entities){ XE "M-LOGICALPARM-MODIFY (Hardware-BTS-Type group)" } FROM THE OMC-R

Parameter name Purpose Optional/Mandatory MFS-peer-entities-Type Identifier of MFS-peer-entities Mandatory Outputs: Message M-LOGICALPARM-MODIFY-REPORT{XE "M-LOGICALPARM-MODIFY-REPORT"} TO

THE OMC-R Parameter name Purpose Optional/Mandatory Status Status about the outcome of the


Mandatory

Description: The BSC records the modified or new MFS peer entities characteristics. For the BSC is in IP mode the BSC instantiates the IP-GSL SBL or deletes the GSL SBL. For the BSC is in TDM mode the GSL SBL is only registered in BSC DLS. Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 192/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.12 Use Case «BSS Transport Mode Switch» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-BSS-TRANSPORT-MODE-SWITCH message from the OMC-R. Pre Conditions: For switch from TDM to IP:

• The Atermux are configured either as pure CS Atermux either as pure PS Atermux (No GPRS/CS mixed Atermux)

• No BSC/OMC O&M carried over Ater (ie no usage of the O&M in TS 31) For switch from IP to TDM:

• Note that it shall not be the first time the BSC is configured in TDM Mode. It is mandatory to have TDM related information in BSC DLS to support the mode change from IP to TDM.

Note: Hence an IP installed BSC cannot go to TDM from a change mode but has to be reinstalled in TDM. Post Conditions: The new Bss transport mode is valid. Inputs:

Message M-BSS-TRANSPORT-MODE-SWITCH{ XE "M-LOGICALPARM-MODIFY (Hardware-BTS-Type group)" } FROM THE OMC-R

Parameter name Purpose Optional/Mandatory BSS Transport Mode Identifier of the requested BSS

transport mode: • IP Mode

or • TDM Mode

Mandatory

Outputs:

Message M- BSS-TRANSPORT-MODE-SWITCH{ XE "M-LOGICALPARM-MODIFY (Hardware-BTS-Type group)" }-REPORT{XE "M-LOGICALPARM-MODIFY-REPORT"} TO THE OMC-R

Parameter name Purpose Optional/Mandatory Status Status about the outcome of the


Mandatory

Description: On the reception of M-BSS-TRANSPORT-MODE-SWITCH message: 1) In case of BSS transport change mode from TDM mode to IP mode in BSC BSC checks that the BSC is configured in 1 LAN topology o Then,


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 193/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

o The Transmission related changes are: • Creation of N_TCSL SBL (one SBL per associated rack): NEQ -> IT • Creation of N_TC-O&M SBL (one SBL per associated rack): NEQ -> IT • Deletion of the obsolete TC side SBLs: SM_ADAPT[TC], TC_ADAPT,

TC16 SBLs: IT/FLT/OPR -> NEQ o Signalling SS7 related changes are:

• If ‘A signalling over IP’ is not activated, Re-configure N7 SBL configuration from TDM to IP mode

� The N7 low speed (LSL mode (HSL mode not activated)) is kept with their current configuration, the number of ATR is kept: 4 ATR SBL but the path is switched from [OMCP <–> TPGSM V3] to [OMCP <—> TC]

� The N7 high speed (HSL mode activated) only 3 ATR SBL are added, the first one corresponding to the HSL is not equipped.

• BSC side SS7 parameters required for IP mode are fixed in the DLS (timers, BSC SCTP port numbers, OMCP and CCP IP addresses). TC side parameters are audited from the TC later.

o Signalling GSL related changes are:

• IP GSL SBL are instantiated. • TDM GSL SBL are removed.

o A channels types change in accordance with the principles described in chapter 2.2.9 A

Channel Configuration,

2°) In case of BSS transport change mode from IP mode to TDM mode in BSC o The Transmission related changes are:

• Deletion of N_TCSL SBL (one SBL per associated TC rack): -> NEQ • Deletion of N_TC-O&M SBL (one SBL per associated TC rack): -> NEQ • For the resources that we defined before previous TDM to IP change,

recreation of the TDM TC side SBL: SM_ADAPT[TC], TC_ADAPT, TC16 SBL: ->IT

o Signalling SS7 related changes are:

• If ‘A signalling over IP’ is not activated, Re-configure N7 SBL configuration from IP to TDM mode:

� The N7 low speed (LSL mode (HSL mode is not activated)) is kept with their current configuration, the number of ATR SBL is kept: 4 ATR SBL but the path is switched from [OMCP <–> TC] to [OMCP <—> TPGSM (V3)].

� The N7 high speed (HSL mode is activated) the ATR SBLs are removed (No ATR SBL in HSL mode in TDM mode) but the path is switched from [OMCP <–> TC] to [OMCP <—> TPGSM (V3)].

o Signalling GSL related changes are:

• IP GSL SBL are removed instantiated. • TDM GSL SBL are instantiated back from DLS when compatible with

Atermux configuration. o A channels types change in accordance with the principles described in chapter 2.2.9 A

Channel Configuration, principally: • Recovery of ACH channel type related to Qmux / Alarm octet • Recovery of 16 first TS to N7


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 194/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• TS 31 is not modified (kept TCH) The BSC marks the TC modules for which configuration change. On the sending of the M-BSS-TRANSPORT-MODE-SWITCH-REPORT message, The BSC then autonomously resets (See IMO BSC, TC and Ater part Ref [A4]). In TDM, the BSC reconfigures “marked” TC modules. At the end of BSC reset, BSC resumes sending BSC originated alarms and state changes after audit of AIFL and sends PM-Global-Stop-Report to OMC-R. Due to the BSC reset, automatically the BSC plays a telecom reset for blocking/unblocking of A channels. The complete BSC-BTS Audits are performed in parallel for all BTSs and – if needed – a BTS-HW-Resync alarm report is sent to the OMC-R after all audits are finished. TCSL are established (Low level Telecom scenario) If in IP mode, BSC-TC audit scenario (§ 4.1.6.2) is triggered. Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 195/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.13 Use Case «Modify BSC SS7 Transport Mode» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-LOGICALPARAM-MODIFY message with parameter group No7-Netw-Addr-Type from the OMC-R. Pre Conditions:

• The BSC is an Mx Generation • Telecom traffic is stopped (but this is not checked).

Post Conditions: The BSC Database is configured with the new SS7 Transport Mode. Inputs:

Message M-LOGICALPARAM-MODIFY (No7-Netw-Addr-Type) FROM THE OMC-R Parameter name Purpose Optional/Mandatory No7-Netw-Addr-Type The parameter group “No7-Netw-

Addr-Type” Mandatory

Outputs:

Message M- LOGICALPARAM-MODIFY-REPORT{XE "M-LOGICALPARM-MODIFY-REPORT"} TO THE OMC-R



Mandatory

Description: At the reception of the message M-LogicalParam-Modify with the parameter group “No7-Netw-Addr-Type, When the included parameters “A-signalling-over-IP” and “A-flex” are both disabled, the roll-back is requested and BSC checks the possibility to roll-back to the previous LSL or HSL configuration (N7 links). The BSC changes the DLS with A signalling over IP enabled or disabled in accordance with the value received. The BSC updates the DLS also with the correct ACH configuration, with SS7 SBL, and with ATR SBL. The BSC marks the impacted TC SBLs as “to be configured”. The BSC reports the success or unsuccess to OMC-R. After sending the report, the BSC performs autonomously a reset to apply the changes and to perform the telecom resynchronization with MSC (For BSC reset see IMO BSC, TC and Ater part Ref [A4]). At the end of Reset BSC (See IMO BSC, TC and Ater part Ref [A4]), BSC resumes sending BSC originated alarms and state changes after audit of AIFL and sends PM-Global-Stop-Report to OMC-R.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 196/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

After the reset BSC (See IMO BSC, TC and Ater part Ref [A4]), the BSC automatically reconfigures the TC SBL marked. Note: In the case change the mode from LSL to A Signalling Over IP, and the RIT of MT120 is equal to ‘MTWB’ or ‘MTNB’, the BSC is allowed to configure the previous TS16 used by N7 (the first 16 Atermux) for traffic. Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 197/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.14 Use Case «BSC STM1 interface activation» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-STM1-ACTIVATE message from the OMC. Pre Conditions:

• The BSC is an Mx Generation Post Conditions: None Inputs:

Message M-STM1-ACTIVATE Parameter name Purpose Optional/Mandatory List of STM1 Interface List of STM1 interface Mandatory Outputs:

Message M-STM1-ACTIVATE-REPORT Parameter name Purpose Optional/Mandatory Status Status about the outcome of the


Mandatory

List of added SBLs List of the SBLs created ie the STM1-ITF SBL and the 2 associated STM1-TTPs SBLs created

Mandatory

Description: At the reception of the STM1-ACTIVATE message from the OMC:

• For each interface to be activated the BSC creates the STM1-ITF SBL and the 2 associated STM1-TTPs SBLs. All these SBLs are created in the OPR state. When STM1-TTP is created, its section trace and high path trace are initialised to the default value.

• For each interface to be removed the BSC removes the STM1-ITF SBL and the 2 associated STM1-TTP SBLs.

BSC reports the STM1-ITF SBL and the 2 associated STM1-TTPs SBLs created. Exceptions: An error message is reported:

o If at least one TPGSM have not the STM-1 capability; o If HWAY-TP are configured on the interface to be removed


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 198/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.15 Use Case «Getting current or candidate BSC STM1 configuration» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-GETCONF message from the BSC Terminal. Pre Conditions:


Message M-GETCONF FROM THE BSC Terminal Parameter name Purpose Optional/Mandatory STM1 configuration type Current STM1 configuration

Or Candidate STM1 configuration

Mandatory

Outputs: Message M-GETCONF-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal



Mandatory

Configuration data Current or candidate transmission termination configuration data

Mandatory Properties of the requested STM1 configuration type

Properties of the current configuration Or Properties of the candidate configuration

Mandatory

Description: At the reception of the message M-GETCONF, the BSC retrieves current or candidate transmission termination configuration data as requested and their properties (name and date). The transmission termination configuration data is the configuration of all the equipped Abis/Ater-HWAY-TP. The properties of the current configuration are:

• The name of the original applied file. • The date of the application

The properties of the candidate configuration are: • The name of the original downloaded file. • The date of the download.

The BSC sends the output to the BSC Terminal. Remark: Before the first configuration application from BSC Terminal, the current configuration is the one populated at migration time (or created by Polo).


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 199/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Exceptions: The BSC reports that no candidate configuration is available,

• If the candidate configuration is requested and if it is dummy in the DLS.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 200/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.16 Use Case «Getting current or candidate BSC STM1 configuration Properties» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-GETCONF-PROP message from the BSC Terminal. Pre Conditions:


Message M-GETCONF-PROP FROM THE BSC Terminal Parameter name Purpose Optional/Mandatory Properties Type Current properties

Or Candidate properties

Mandatory

Outputs:

Message M-GETCONF-PROP-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal



Mandatory

Requested Data Properties Properties of the current BSC STM1 configuration Or Properties of the candidate BSC STM1 configuration

Mandatory

Description: At the reception of the message M-GETCONF-PROP, the BSC retrieves current or candidate data properties (name and date). The properties of the current configuration are:

• The name of the original applied file. • The date of the application

The properties of the candidate configuration are: • The name of the original downloaded file. • The date of the download.

The BSC sends the output to the BSC Terminal. Remark: The Transmission Termination configuration data are NOT reported through this use case. Exceptions:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 201/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The BSC reports that no candidate configuration is available, • If the candidate configuration is requested and if it is dummy in the DLS.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 202/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.17 Use Case «Setting a candidate BSC STM1 configuration» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-SETCONF message from the BSC Terminal. Pre Conditions:


Message M-SETCONF FROM THE BSC Terminal Parameter name Purpose Optional/Mandatory Candidate Data Candidate data are requested Mandatory Name The name of the configuration file used

as candidate Mandatory

Outputs: Message M-SETCONF-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal


operation Mandatory

Date BSC current date at the time of the setting

Mandatory

Description: At the reception of the message M-SETCONF, the BSC performs the following checks:

o If STM1 interfaces are used then associated SBL STM1-ITF and STM1-TTP must be created in the DLS (equipped);

o If LIU ports are used then LIU shelf must be equipped; o All Abis/Ater-HWAY-TP SBL equipped in the BSC must be specified in input o Abis/Ater-HWAY-TP SBL not equipped in the BSC shall not be specified in input

It is not intended to check the status of the plug before accepting the configuration. Missing plug or faulty plug will lead to alarms. The BSC alarm dictionary (ref [22]) will give details on the possible repair actions. If a candidate configuration was already set in the DLS, the new one overwrites it. The name of the configuration as the current date of the BSC are added to the set of configuration stored data in DLS. The BSC identifies and flags the traffic impacts due to configuration changes. This allows a clean impact on traffic at application time. The BSC reports its current date. The BSC reports the status about the outcome of the operation to the BSC terminal.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 203/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Remark: The Transmission Termination configuration data are NOT reported through this use case. Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 204/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.18 Use Case «Applying a candidate BSC STM1 configuration» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-APPLYCONF message from the BSC Terminal. Pre Conditions:

• The BSC is an Mx Generation Post Conditions: The candidate BSC STM1 configuration is applied in the BSC. Inputs: None. Outputs: Message M-SETCONF-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal



Mandatory

Description: At the reception of the message M-SETCONF, the BSC performs the following checks:

o If STM1 interface are used then associated SBL STM1-ITF and STM1-TTP must be created in the DLS (equipped);

o If LIU ports are used then LIU shelf must be created in the DLS (equipped); o The candidate configuration is not dummy o All Abis/Ater-HWAY-TP created (equipped) in the DLS shall have a configuration

different from dummy in the candidate configuration to be applied. If the checks are OK: The BSC moves the candidate configuration to the current configuration in the DLS. The candidate properties (name and date) are managed as follows: the name is copied in current data. The date is overwritten by the current BSC date (application date). The new transmission configuration is taken into account by the BSC: the TPGSM is configured. When the new transmission configuration is applied; calls are forced released by BSC application only on modified links (ATER-HWAY-TP or ABIS-HWAY-TP moved from LIU-E1 to VC12-E1 and vice versa) and on deleted links. Short disturbance may happen on not modified links due to possible internal resources mapping changes on the mappers of the TPGSM. More exactly for the LIU-E1 links which must be allocated a different framer due to conflict with a new VC12-E1 link using this framer. This can happen when creating a new VC12-E1 or moving an existing LIU-E1 to VC12-E1 on this framer position. The BSC sends a BSC Hardware synchronisation request message (M-Alarm-Report (BSC, HW resynch, Event)) to the OMC. The BSC reports the status about the outcome of the operation to the BSC terminal.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 205/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Exceptions:

• If the BSC STM1 configuration file check is not successful • If checks performed by BSC are not successful.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 206/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.19 Use Case «Display of BSC’s section and path traces» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-GETTRAC message from the BSC Terminal. Pre Conditions:


Message M-GETTRAC FROM THE BSC Terminal Parameter name Purpose Optional/Mandatory STM1-TTP number The requested STM1-TTP number Mandatory Outputs: Message M-SETCONF-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal

Parameter name Purpose Optional/Mandatory Result The section (J0) and path traces (J1

and J2) available for the requested STM1-TTP number

Mandatory

Description: At the reception of the message M-GETTRAC, the TPGSM carrying the requested STM1-TTP retrieves the section and path traces available:

• The transmitted section trace (J0) (according to the section trace type: 1 byte or 16 bytes framed)

• The received section trace (J0) (also according to the section trace type) • For each VC4 of this STM1:

o The transmitted High path trace (J1) o The received High path trace (J1)

• And for each VC-12 of this STM1-TTP: o The identification of the VC-12 o The transmitted Low path trace (J2) o The received Low path trace (J2) (if the STM1-TTP is the active one)

The BSC reports the result to the BSC Terminal. Exceptions: The corresponding STM1-TTP is not activated.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 207/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.20 Use Case «Modification of BSC’s transmitted section and path traces» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the M-GETSECPATHTRACE message following by the reception of the M-SETSECPATHTRACE message from the BSC Terminal. Pre Conditions:


Message M-GETSECPATHTRACE FROM THE BSC Terminal Parameter name Purpose Optional/Mandatory STM1-TTP number The requested STM1-TTP number Mandatory

Message M-SETSECPATHTRACE FROM THE BSC Terminal Parameter name Purpose Optional/Mandatory STM1-TTP number The requested STM1-TTP number Mandatory New Values Possible new values are:

• The section trace value (J0) • The high path trace value (J1) • One or several low path trace

(J2)

Mandatory

Outputs: Message M-GETSECPATHTRACE-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC

Terminal Parameter name Purpose Optional/Mandatory Result The section (J0) and path traces (J1


Mandatory

Message M-SETSECPATHTRACE-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC

Terminal Parameter name Purpose Optional/Mandatory Result The section (J0) and path traces (J1


Mandatory

Description: At the reception of the message M-GETSECPATHTRACE, the BSC checks that the corresponding STM1 interface is activated; then the TPGSM carrying the requested STM1-TTP retrieves the section and path traces available:



04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 208/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• The received section trace (J0) (also according to the section trace type: 1 byte or 16 bytes framed)

• For each VC4 of this STM1: o The transmitted High path trace (J1) o The received High path trace (J1)

• And for each VC-12 of this STM1-TTP: o The identification of the VC-12 o The transmitted Low path trace (J2) o The received Low path trace (J2) (if the STM1-TTP is the active one)

The BSC reports the result to the BSC Terminal. The BSC terminal sends for the requested STM1-TTP the new values:

• The section trace value (J0) • The high path trace value (J1) • One or several low path trace (J2)

to the BSC. The BSC updates the section and path traces for the requested STM1-TTP; then the BSC sends the result:


• For each VC4 of this STM1: o The transmitted High path trace (J1)

• And for each VC-12 of this STM1-TTP: o The identification of the VC-12 o The transmitted Low path trace (J2)

Exceptions: The corresponding STM1-TTP is not activated.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 209/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.1.21 Use Case «BSC plug identification information» Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-PLUGIDENT event from the field operator. Pre Conditions: None. Post Conditions: None. Inputs: None. Outputs: Message M-PLUGIDENT-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal Parameter name Purpose Optional/Mandatory List of Plug Identification For each SFP reported by BSC:

Plug identification contained in the EEPROM

Mandatory

Description: On the reception of the message M_PLUGIDENT from BSC Terminal BSC retrieves the plug identification for all SFP connected. Remark: The STM-1 optical/electrical converters (SFP modules named also plugs) have an own remote inventory EEPROM containing the plug identification. As these components are off-the-shelf products, these RI EEPROMs do not conform to the Alcatel format. The main board also provides presence detection for the SFP modules. Plugs do not influence the functional variant of the board. The Plug remote inventory EEPROM is never reported in the BSC remote inventory to OMC. Exceptions: An error is reported:

• If the BSC has no plug identification to report (No SFP connected)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 210/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.2.2 Dimensioning Data Not relevant.



04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 211/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.3 BSC Terminal Description

5.3.1 Use case description

5.3.1.1 Use Case « Getting current or candidate BSC STM1 configuration » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-GETCONF event from the field operator.

Pre Conditions: None. Post Conditions: Current or candidate STM1 configuration is stored in BSC Terminal. Inputs:

OPERATOR INPUTS VIA BSC TERMINAL


STM1 configuration type Current STM1 configuration or Candidate STM1 configuration

Mandatory

Outputs: A report about the outcome of the operation to the BSC terminal operator. . Description: The reported transmission Termination configuration data from BSC are stored in a file in the BSC terminal in the sub-directory BSC_STM1/current or BSC_STM1/candidate, depending on the request. The properties of the BSC stored configuration data are used to name the created file. The properties of the current configuration are:

• The name of the original applied file. This can be used by the operator for the management of configuration file version. Indeed, the version is then coded in the name of the file.

• The date of the application The properties of the candidate configuration are:

• The name of the original downloaded file. • The date of the download.

If the file exists already in the directory, a choice is offered to the operator:

• To cancel the operation or • To overwrite the existing file.

Before the first configuration application from BSC terminal, the current configuration is the one populated at migration time (or created by POLO).


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 212/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Exceptions: An error message is displayed to operator:

• If the file name already exists in the PC NEM; • If the BSC reports a not successful action. • If the candidate configuration is requested and if it is dummy in the DLS, the BSC

reports that no candidate configuration is available.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 213/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.3.1.2 Use Case « Getting current or candidate BSC STM1 configuration properties» Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-GETCONF_prop event from the field operator.

Pre Conditions: None. Post Conditions: Current or candidate STM1 configuration properties are displayed to the operator. Inputs:




Mandatory

Outputs: A report about the outcome of the operation to the BSC terminal operator. . Description: Current or candidate STM1 configuration properties are displayed to the operator. (No transmission Termination Configuration data are reported through this use case.) The properties of the current configuration are:

• The name of the original applied file. The operator for the management of configuration file version can use this. Indeed, the version is then coded in the name of the file.

• The date of the application The properties of the candidate configuration are:

• The name of the original downloaded file. • The date of the download.


• If the BSC reports a not successful action. • If the candidate configuration is requested and if it is dummy in the DLS, the BSC

reports that no candidate configuration is available.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 214/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.3.1.3 Use Case « Editing a BSC STM1 configuration » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-EDITCONF event from the field operator.

Pre Conditions: None. Post Conditions: None Inputs:



File Name The name of the BSC STM1 configuration file to edit

Mandatory

Outputs: A report about the outcome of the operation to the BSC terminal operator. . Description: A browser on the allowed directories is offered to the operator. On reception of the A_EDITCONF message the requested BSC STM1 configuration file is edited. Configuration file could be edited with text editor or with excel as it is also compatible with CSV format. Configuration files in the sub-directory Configuration are allowed in read and write mode. Configuration files in the following sub-directories are allowed in read mode only: • Template • Candidate • Current Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 215/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.3.1.4 Use Case « Create a new BSC STM1 configuration » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-CREATCONF event from the field operator.




File Name The name of the BSC STM1 configuration file created

Mandatory

Outputs: A report about the outcome of the operation to the BSC Terminal operator. . Description: The BSC Terminal creates a STM1 configuration file and stores the STM1 configuration file in BSC_STM1/Configuration; the file name is this set by operator in input. BSC Terminal provides two options for creating STM1 configuration file.

• A new configuration can be created from a template and is stored in the Configuration sub-directory. The file name is this set by operator in input.

• Or a new configuration can be created from an existing one. The new file name is this set by the operator in input. The resulting file is stored in the Configuration sub-directory.

Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 216/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.3.1.5 Use Case « Checking a BSC STM1 configuration » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-CHECKCONF event from the field operator.




Name of the configuration file Name of the configuration file to be checked The source directory is BSC_STM1/Configuration

Mandatory

Outputs: • The output file has the same name than the configuration file to be checked but with the

extension .CHK. It is stored in the Configuration sub-directory. • The output file contains all lines of the configuration file that are not checked successfully

and the error message. There is no .CHK file created if no error is found. A report about the outcome of the operation to the BSC terminal operator. Description: The BSC terminal for each line performs the following checks:

o The number of column is fixed and has to be checked; o LinkType is 1 or 2 o If LinkType is 1 (ABIS-HWAY-TP) LinkNumber is in the range 1 to 176 o If LinkType is 2 (ATER-HWAY-TP) LinkNumber is in the range 1 to 76 o The couple (LinkType, LinkNumber) is not defined in previous lines o Physical Transport is 0, 1 or 2 o LIUPortNumber is in the range 1 to 256 if physical transport is 1 and follows the

E1 Transmission Ports Mapping. o LIUPortNumber is 0 if physical transport is 0 or 2 o This LIUPortNumber value is not used in previous lines (except LIUPortNumber to

0); o STM1Interface is in the range 1 to 4 if physical transport is 2 o STM1Interface is 0 if physical transport is 0 or 1 o If STM1Interface is equal to 0 then

� STM1-K must be equal to 0 � STM1-L must be equal to 0 � STM1-M must be equal to 0

o Else STM1Interface is not equal to 0 then � STM1-K is in the range 1 to 3 � STM1-L is in the range 1 to 7 � STM1-M is in the range 1 to 3


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 217/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

� The quartet (STM1Interface, STM1-K, STM1-L, STM1-M) is not used in previous lines (except (0,0,0,0));

o Endif and generated the output file . Output file example:


• If the specified file is not found in the PC NEM

#2 1, 1, 1, 1, 0, 0, 0, Abis chain 1: LIU port 1 ***Error*** Missing parameter #3 1, 2, 1, 2, 0, 0, 0, 0, 0, Abis chain 2: LIU port 2 ***Error*** Too many parameters #5 1, 3, 1,113, 0, 0, 0, 0, Abis chain 113: LIU port 113 ***Error*** The link (1,3) is already used line #4 #8 1, 116, 2, 0, 1, 1, 8, 4, Abis chain 116: VC12 (1-1-1-3) ***Error*** STM1-L (8) is not in the range [1,7] ***Error*** STM1-M (4) is not in the range [1,3]


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 218/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.3.1.6 Use Case « Comparing two BSC STM1 configurations » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-COMPCONF event from the field operator.




Name1 Name of the first STM1configuration file to compare. This file must belong to the Configuration sub-directory.

Mandatory

Name2 Name of the second STM1configuration file to compare. This file must belong to the Configuration sub-directory.

Mandatory

Outputs: • The output file has the same name than the first configuration file to be checked but with

the extension .CMP. It is stored in the Configuration sub-directory • The output file contains all links with different port configuration. Comments are not taken

into account in the comparison. • If the two configurations are identical, there is no .CMP created. A report about the outcome of the operation to the BSC terminal operator. Description: The BSC terminal performs the comparison between the two configurations and generates an output file with a detailed report. Output file example:

**File Name1** #15 1, 21, 1, 21, 0, 0, 0, 0, Abis chain 21: LIU port 21 **File Name2** #15 1, 21, 2, 0, 1, 1, 1, 1, Abis chain 21: VC12 (1-1-1-1) ** **File Name1** #47 2, 2, 2, 0, 2, 1, 1, 1, Atermux CS 2: VC12 (2-1-1-1) **File Name2** #47 2, 2, 1,225, 0, 0, 0, 0, Atermux CS 2: LIU port 225 **


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 219/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt


• If one of the specified files are not found in the PC NEM

If the output file name already exists, it is offered to the operator to rename, to cancel or to enter a new name. 5.3.1.7 Use Case « Setting a candidate BSC STM1 configuration » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-SETCONF event from the field operator.




Name Name of the STM1 configuration file to use as candidate. This STM1 configuration file source must be mandatorily included in the BSC_STM1/Configuration directory

Mandatory

Outputs: A report about the outcome of the operation to the BSC terminal operator. Description: On the reception of A_SETCONF event from operator BSC terminal sends the M_SETCONF message to the BSC. If the result from BSC is successfully, the BSC Terminal copies the original STM1 configuration file in a file named from the file set by operator and the date reported from BSC <name>_<date> in the candidate sub-directory. Exceptions: An error message is displayed to operator:

• If the specified file is not found in the PC NEM; • If the specified file is not found in the Configuration sub-directory


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 220/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.3.1.8 Use Case « Applying a candidate BSC STM1 configuration » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-APPLYCONF event from the field operator.

Pre Conditions: Operator must stop traffic on impacted links manually before applying the candidate configuration file (by locking BTS-TEL for Abis and by locking Atrunks for Ater). Otherwise when the new transmission configuration is applied calls will be cut abruptly. Post Conditions: None Inputs: None Outputs: A report about the outcome of the operation to the BSC terminal operator. Description: On the reception of A_APPLYCONF event from operator BSC terminal sends the M_APPLYCONF message to the BSC. On the reception of M_APPLYCONF_REP message from BSC BSC Terminal reports the outcome of the operation to the operator. Exceptions: None 5.3.1.9 Use Case « Get BSC’s LIU/STM1 resources » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-GETRESOURCES event from the field operator.

Pre Conditions: None. Post Conditions: None Inputs: None Outputs: A report about the outcome of the operation to the BSC terminal operator. Description: On the reception of A_GETRESOURCES event from operator BSC terminal sends the M_GETCONF message to the BSC to retrieve current data from DLS in BSC.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 221/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

On the reception of M_ GETCONF REP message from BSC BSC Terminal reworks the reported data in order to deduce the right information. This computed resources information is stored in a file named with the name and date reported by the BSC as properties. BSC Terminal reports the outcome of the operation to the operator. Exceptions: None

5.3.1.10 Use Case « Display of BSC’s section and path traces » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-GETTRAC event from the field operator.

Pre Conditions: None. Post Conditions: None Inputs: None



STM1-TTP number Number of STM1-TTP Mandatory Outputs: A report about the outcome of the operation to the BSC terminal operator.

OUTPUT TO THE BSC TERMINAL Parameter name Purpose Optional/Mandatory Result The section and path traces available

for the requested STM1-TTP number Mandatory

Description: On the reception of A_GETTRAC event from operator BSC terminal sends the M_GETTRAC message to the BSC to retrieve the section and path traces available for the requested STM1-TTP number. On the reception of M_ GETTRAC REP message from BSC BSC Terminal displays in a user-friendly way:


• The received section trace (J0) (also according to the section trace type) • For each VC4 of this STM1:

o The transmitted High path trace (J1) o The received High path trace (J1)



04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 222/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

o The received Low path trace (J2) (if the STM1-TTP is the active one) The display of received section and path traces is useful to verify if the BSC is connected to the intended equipment. The display of transmit section and path traces is just a reminder. It is useful to have all information in the same window. Exceptions: None 5.3.1.11 Use Case « Modification of BSC’s transmitted section and path traces » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-SETSECPATHTRACE event from the field operator.




STM1-TTP number Number of STM1-TTP Mandatory Outputs:

OUTPUT TO THE BSC TERMINAL Parameter name Purpose Optional/Mandatory Result The section and path traces available


Description: At BSC terminal operator can modify the transmitted section trace of STM1-TTP, the transmitted high path trace and the transmitted low path traces. On the reception of A_SETSECTPATHTRACE event from field operator BSC terminal sends the M_GETSECPATHTRACE message to the BSC to retrieve the current section and path traces available for the requested STM1-TTP number. On the reception of M_ GETSECPATHTRACE REP message from BSC BSC Terminal allows to operator to update

• The section trace value (J0) • The high path trace value (J1) • One or several low path trace value (J2)

BSC terminal checks the syntax of the new section and new path traces


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 223/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

If no error is detected BSC terminal send the new value to BSC through the message M_SETSECPATHTRACE. On the reception of the message M_ SETSECPATHTRACE_REP from BSC the BSC terminal edits in a user-friendly way:


• For each VC4 of this STM1: o The transmitted High path trace (J1)


Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 224/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.3.1.12 Use Case « BSC Plug identification information display » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-PLUGIDENT event from the field operator.

Pre Conditions: None. Post Conditions: None Inputs: None Outputs: A report about the outcome of the operation to the BSC terminal operator. Description: On the reception of the A_PLUGIDENT event from the fiel operator the BSC terminal sends the message M_PLUGIDENT to retrieve the plug identification for all SFP connected. On the reception of the message M_PLUGIDENT_REP from BSC the BSC terminal displays for each SFP reported by the BSC:

o The TPGSM number on which the SFP is plugged; o The STM-1 interface (from 1 to 4) on which the SFP is plugged; o The plug identification contained in the EEPROM; only part of these fields has to

be displayed at BSC terminal: � The type of serial transceiver � The connector type � The optical compatibility � The link length supported � The vendor name � The part number � The serial number


• If the BSC does not report any plugidentification;


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 225/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4 TC-NEM Description

5.4.1 Use case description

5.4.1.1 Use Case « Getting current or candidate TC STM1 configuration » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-GETCONF-TC message from the field operator. Pre Conditions: None. Post Conditions: Current or candidate STM1 configuration is stored in TC-NEM. Inputs:

OPERATOR INPUTS VIA TC-NEM



Mandatory

Outputs: A report about the outcome of the operation to the TC-NEM operator. Description: In case of current STM1 configuration requested: On the receipt of the A-GETCONF-TC message with current STM1 configuration requested, TC-NEM sends a GET-SNMP with STM1 configuration type current STM1 configuration to TC. On receipt of the GET-SNMP-RESP with the STM1 configuration data and its properties (current file name and current date), TC-NEM checks if the file name is yet present in sub-directory ‘Current’ of the STM-1 directory. If the file name is yet present in the sub-directory ‘current’, the operator must decide if he wants to overwrite the present file or if he wants to keep the present one.

o Operator wants to keep the present file: Present file is kept. No new file is created. The TC NEM sends to the operator a successful result, but a warning is displayed to the operator “No new file constituted by operator decision”.

o Operator wants to overwrite the present file

Reported configuration data are stored in the sub-directory ‘Current’ in a file named <name_date> with the current file name and the current date previously recovered from TC as properties.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 226/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

If the file name is not present in the sub-directory ‘current’, If the file name is present but the date is different Reported configuration data are stored in the sub-directory ‘Current’ in a file named <name_date> with the current file name and the current date previously recovered from TC as properties. In case of candidate STM1 configuration requested: On the receipt of the A-GETCONF-TC message, TC-NEM sends a GET-SNMP with STM1 configuration type candidate STM1 configuration to TC. On receipt of the GET-SNMP-RESP with the candidate STM1 configuration data and its properties (name, date), TC-NEM checks if the file name is yet present in sub-directory ‘Candidate’. If the file name with same date is yet present in the sub-directory ‘Candidate’, the operator must decide if he wants to overwrite the present file in the sub-directory ‘Candidate’ or if he wants to keep the present one.

o Operator wants to keep the present file: Present file is kept. No new file is created. The TC NEM sends to the operator a successful result, but a warning is displayed to the operator “No new file constituted by operator decision”.

o Operator wants to overwrite the present file

Reported configuration data are stored in the sub-directory ‘Candidate’ in a file named <file name_date> with the name and the date previously recovered from TC as properties.

If the file name is not present in the sub-directory ‘candidate’, If the file name is present with a different date, Reported configuration data are stored in the sub-directory ‘Candidate’ in a file named < name_date> with the candidate file name and the date previously recovered from TC as properties. Remark:

1. Before the first downloading of the STM1 configuration the candidate name and the candidate date retrieved from TC SNMP MIB and used by TC NEM is respectively the default candidate name in TC SNMP MIB “NoSTM1Configuration” and the default date “1970-01-01” The candidate name and the default candidate name apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_”.

2. Before the first apply STM1 configuration the current name and the current date retrieved from TC SNMP MIB and used by TC NEM is respectively the default current name in TC SNMP MIB “NoSTM1Configuration” and the default date “1970-01-01”. The current name and the default current name apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_”.


• If the GET-SNMP is unsuccessful.

A warning message is displayed to operator:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 227/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• If a new file is not constituted by operator decision


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 228/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.1.2 Use Case « Getting properties for current or candidate TC STM1 configuration »

Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-GETCONFPROPERTIES message from the field operator. Pre Conditions: None. Post Conditions: The properties for candidate STM1 configuration or the properties for current STM1 configuratin are displayed to the operator. Inputs:



STM1 properties type Current Properties for the current properties of the STM1 configuration Or Candidate Properties for the Properties for the candidate properties of the STM1 configuration

Mandatory

Outputs: A report about the outcome of the operation to the TC-NEM operator. Description: In case of current STM1 configuration requested: On the receipt of the A-GETCONFPROPERTIES message with current properties requested, TC-NEM sends a GET-SNMP with current name and current date requested to TC. On receipt of the GET-SNMP-RESP with current properties i.e

o The current name i.e the name of the applied file o The current date i.e the date of the apply (i.e. the date where the candidate

configuration had been applied) The TC NEM displays the current properties (current name, current date) to the operator. In case of candidate STM1 configuration requested: On the receipt of the A-GETCONFPROPERTIES message with candidate properties requested, TC-NEM sends a GET-SNMP with candidate name and candidate date requested to TC. On receipt of the GET-SNMP-RESP with candidate properties i.e


The TC NEM displays the candidate properties (candidate name, candidate date) to the operator. Remark:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 229/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

1. Before the first downloading of the STM1 configuration the candidate name and the candidate date retrieved from TC SNMP MIB and displayed to the operator at TC NEM is respectively the default candidate name in TC SNMP MIB “NoSTM1Configuration” and the default date “1970-01-01” The candidate name and the default candidate name apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_”.

2. Before the first apply STM1 configuration the current name and the current date retrieved from TC SNMP MIB and displayed to the operator at TC NEM is respectively the default current name in TC SNMP MIB “NoSTM1Configuration” and the default date “1970-01-01”. The current name and the default current name apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_”.


o If the Get SNMP is unsuccessful. o No name or no date found or both


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 230/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.1.3 Use Case « Checking a TC STM1 configuration » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-CHECKCONF-TC message from the field operator. Pre Conditions: None. Post Conditions: None. Inputs:



Name Name of STM1 configuration file to

check Mandatory

Outputs: A report about the outcome of the operation to the TC-NEM operator. Description: On the receipt of the A-CHECKCONF-TC message, TC-NEM checks that the configuration file name is stored in the <prefix>/<TC-Id>/STM-1/Configuration directory, and then TC-NEM performs the checks on the requested STM1 configuration file:

• A MT120 interface appears only once as a VC12 • For one MT120, all these A tributary must be E1 type or STM1 type (No mixity

E1/STM1 is accepted on A interface for a given MT120) • If STM1Interface is equal to 0 (E1 case) then


• Else STM1Interface is not equal to 0 then

� STM1-K is in the range 1 to 3 � STM1-L is in the range 1 to 7 � STM1-M is in the range 1 to 3

• The quartet (STM1Interface, STM1-K, STM1-L, STM1-M) is not used in previous

lines (except (0,0,0,0)); The TC-NEM generates an output file with a detailed report. The output file has the same name than the STM1 configuration to be checked but with the extension .CHK. The output file is stored in the <prefix>/<TC-Id>/STM-1/Configuration directory. The output file contains all lines of the configuration file with an error message after lines that are not checked successfully. Exceptions: An error message is displayed to operator:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 231/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

o If the specified name file is not found in the <prefix>/<TC-Id>/STM-1/Configuration

directory . o If the used syntax is wrong.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 232/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.1.4 Use Case « Comparing two TC STM1 configurations » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-COMPCONF-TC message from the field operator. Pre Conditions: None. Post Conditions: None. Inputs:



Directory 1 STM1 Sub-Directory where the first STM1 configuration file to compare is stored.

Mandatory

Name 1 Name of the first STM1 configuration file to compare

Mandatory Directory 2 STM1 Sub-Directory where the second

STM1 configuration file to compare is stored.

Mandatory

Name 2 Name of second STM1 configuration file to compare

Mandatory

Outputs: A report about the outcome of the operation to the TC-NEM operator. Description: On the receipt of the A-COMPCONF-TC message, TC-NEM checks that the two directories are STM1 sub-directories, and then TC-NEM performs the comparison between the two configurations. The TC-NEM generates an output file with a detailed report. The output file has the same name than the first STM1 configuration to be checked but with the extension .CMP. This output file is stored in the sub-directory Configuration. The output file contains all links with different port configuration. Comments are not taken into account in the comparison. Exceptions: An error message is displayed to operator:

• If one of the specified directory is not one of STM1 sub-directories. • If one of the specified name file is not found in one of STM-1 sub-directories or the

both.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 233/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.1.5 Use Case « Downloading a candidate TC STM1 configuration » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-SETCONF message from the field operator. Pre Conditions: None. Post Conditions: None. Inputs:



Name Name of the STM1 configuration file to

use as candidate (*). Mandatory

(*) In a ‘candidate’ STM-1 configuration file, all MT120 (equipped or not equipped) are mentioned in the table and each MT120 interface is configured either STM-1 or E1. Outputs: A report about the outcome of the operation to the TC-NEM operator. Description: On the receipt of the A-SETCONF-TC message, the TC-NEM checks that the configuration file is available in the <prefix>/<TC-Id>/STM-1/Configuration directory, and then the TC-NEM performs the following checks:

• That a MT 120 interface appears only once as a VC12. • All the tributaries of A interface on the same MT120 are in STM-1. • If STM1Interface is equal to 0 (E1 case) then


• Else STM1Interface is not equal to 0 then

� STM1-K is in the range 1 to 3 � STM1-L is in the range 1 to 7 � STM1-M is in the range 1 to 3

• The quartet (STM1Interface, STM1-K, STM1-L, STM1-M) is not used in previous

lines (except (0,0,0,0)); TC-NEM skips all the comment lines present in the file then TC-NEM sends SET-SNMP with candidate data to TC. If SET-SNMP-REP is ok, the TC-NEM stores the configuration file in the candidate sub-directory under the name: <name>_<date> The date is the one reported by the TC.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 234/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

In SET-SNMP-REP: in case of status is NOK, additional parameters “the list of STM1-ITF not declared” or/and “HSI not activated” will be sent from TC. Exceptions: An error message is displayed to operator:

• . • If the specified name file is not found in the <prefix>/<TC-Id>/STM-1/Configuration

directory. • If the STM1 configuration file checks performed by TC NEM is not successful. • If STM1 interface used in the downloaded configuration is not an STM1-ITF

declared. • If TC is not correctly installed (ie TC internal HSI interface not activated). • If no date is find by TC-NEM


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 235/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.1.6 Use Case « Applying a candidate TC STM1 configuration » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-APPLYCONF message from the field operator. Pre Conditions: None. Post Conditions: None. Inputs: None. Outputs: A report about the outcome of the operation to the TC-NEM operator. Description: On the receipt of the A-APPLYCONF message, TC-NEM sends SET-SNMP with “applyconf”. Exceptions: An error message is displayed to operator:

• If STM1 interface used is not a STM1-ITF declared. • If TC is not correctly installed (ie TC internal HSI interface not activated).


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 236/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.1.7 Use Case « Display of TC’s section and path traces » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-GETSECTPATHTRACE event from the field operator.




STM1-TTP number Number of STM1-TTP Mandatory Outputs: A report about the outcome of the operation to the TC-NEM operator.

OUTPUT TO THE VIA TC-NEM Parameter name Purpose Optional/Mandatory Result The section and path traces available


Description: On the reception of A_GETSECTPATHTRACE event from operator TC-NEM sends a GET-SNMP message to the TC to retrieve the section (J0) and path traces (J1 and J2) available for the requested STM1-TTP number. On the reception of GET-SNMP response message from TC, TC-NEM displays:


• The received section trace (J0) (also according to the section trace type) • The transmitted High path trace (J1) (16 bytes framed) • The received High path trace (J1) (16 bytes framed) • And for each VC-12 of this STM1-TTP:

o The identification of the VC-12 o The transmitted Low path trace (J2) o The received Low path trace (J2) (string)

The display of received section and path traces is useful to verify if the TC is connected to the intended equipment. Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 237/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.1.8 Use Case « Modification of TC’s transmitted section and path traces » Related BSS Service: This use case supports the S-HCM-PCMConfig service; it is triggered by the reception of the A-SETSECTPATHTRACE event from the field operator.




STM1-TTP number Number of STM1-TTP Mandatory Outputs: A report about the outcome of the operation to the TC-NEM operator.

OUTPUT TO THE VIA TC-NEM Parameter name Purpose Optional/Mandatory Result The section and path traces updated for

the requested STM1-TTP number Mandatory

Description: On the reception of A_GETSECTPATHTRACE event from operator TC-NEM sends a GET-SNMP message to the TC to retrieve the current section (J0) and path traces values (J1 and J2) available for the requested STM1-TTP number from the TC. On the reception of GET-SNMP response message from TC, TC-NEM displays the following current values:


• For each VC4 of this STM1: o The transmitted High path trace (J1) (16 bytes framed)


At that time operator can update:

• The transmitted section trace value (J0) • And/or • The transmitted High path trace (J1) (16 bytes framed) • One or several transmitted low path trace (J2)

TC-NEM checks the syntax of the new section/path tracesand if no error is detected TC-NEM sends a SET-SNMP with the new values to TC. On receipt of the SET-SNMP response TC-NEM displays the section and/or path traces (J1 and J2) updated.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 238/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Exceptions: None

5.4.1.9 Use Case « TC Plug identification information display » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-PLUGIDENT event from the TC-NEM operator. Pre Conditions: None. Post Conditions: None. Inputs: None. Outputs: A report about the outcome of the operation to the operator. Description: For each plug (also named SFP) reported by the TC the TC-NEM displays:

• The STM-1 TTP (from 1 to 4) on which the SFP is plugged and associated motherboard TCIF

• The plug identification contained in the EEPROM (identifier of the SFP transceiver, type of transceiver, fiber length, SFP vendor name).

Remark: The STM-1 optical/electrical converters (SFP modules named also plugs) have an own remote inventory EEPROM containing the plug identification. As these components are off-the-shelf products, these RI EEPROMs do not conform to the Alcatel format. The main board also provides presence detection for the SFP modules. Plugs do not influence the functional variant of the board. Exceptions: An error message is displayed to operator:

• If the TC does not report any plug identification • If no plug connected


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 239/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.4.2 Dimensioning Data This section is not relevant in the context of the B11.



04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 240/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5 Transcoder description

5.5.1 Use case description 5.5.1.1 Use Case « Activate new G2.5 TC standard configuration » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-ACTIVATE-CONF-TC message from the field operator. Post Conditions: New TC standard configuration is introduced and activated. Inputs:

OPERATOR INPUTS VIA TC LOCAL TERMINAL


Qmux config Qmux TS and nibble in Atermux link Mandatory BSC identity BSC to which MT120 is connected. Mandatory Atermux number (See Remark) Atermux link to which MT120 is

connected. This information is used in TC G2.5 only, for cluster handling.

Mandatory

75/120 ohm 75/120 ohm selection (impedance of PCM links)

Mandatory rack number rack number for TC G2/G2.5 Mandatory Remark: If BSC is a G2 BSC: 1.. max_G2_BSC_rack_number * 6; if BSC is a MX BSC : 1….10 for configuration1, 1……20 for configuration 2, For MX BSC with board TPGSM V1

1…..MAX-ATERMUX-TPV1 for configuration 3, for configuration 4, for configuration 5 For MX BSC with board TPGSM V3

1…..30 for configuration 3, 1….40 for configuration 4, 1….48 for configuration 5. Outputs: A report about the outcome of the operation to the TC-TE operator. Description: TS0 usage is deduced from Qmux config parameter. BSC identity=couple of BSC number and BSC name (using an ASCII format which is used only for comment). From B10 release all the types of MT120 board (legacy MT120 board, MT120-NB or MT120-WB) can be added. Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 241/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.2 Use Case « Activate new TC G2.5 with TCIF standard configuration » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the A-ACTIVATE-NEW-CONF message from the field operator via TC NEM. Pre Conditions: None. Post Conditions: New TC G2.5 with TCIF (TC G2.5IP) standard configuration is introduced and activated. Pre Check: TC NEM checks: A TC can be associated to a maximum of 12 BSCs. Inputs:

OPERATOR INPUTS VIA TC NEM Parameter name Purpose Optional/


MT120 List List of MT120 (from 1 to 48). Mandatory For each MT120: MT120 state

For each MT 120: Added or removed

Optional Added

For each added MT120: Qmux config

For each added MT120: Qmux TS and nibble in Atermux link

Optional (Only informed if the MT120 is added)

For each added MT120: BSC identity

For each added MT120: BSC to which MT120 is connected.


For each added MT120: Atermux number (See remark 1)

For each added MT120: Atermux link number to which MT120 is connected. This information is used for cluster handling.


For each added MT120: 75/120 ohm

For each added MT120: 75/120 ohm selection (impedance of PCM links)


For each added MT120: Rack number

For each added MT120: Rack number for TC G2.5IP


Remark 1: If BSC is a G2 BSC: 1.. max_G2_BSC_rack_number * 6; if BSC is a MX BSC : 1….10 for configuration1, 1……20 for configuration 2, For MX BSC with board TPGSM V1 1…..MAX-ATERMUX-TPV1 for configuration 3, for configuration 4, for configuration 5 if MX BSC with board TPGSM V3 1…..30 for configuration 3, 1….40 for configuration 4, 1….48 for configuration 5. Outputs: A report about the outcome of the operation to the TC NEM operator. This report is sent to TC NEM operator:

1) Always if the MT120 is connected to a BSC configured in TDM mode 2) In case of exception cases if the connected BSC is in IP mode


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 242/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

Description: On the reception of A-ACTIVATE-NEW-CONF message the TC G2.5 with TCIF (TC G2.5IP) stores the removed or added MT120 (either legacy MT120 or MT120-NB or MT120-WB). For added MT120 the parameters Qmux config, BSC identity, Atermux number, impedance of PCM links and rack number must be informed. TS0 usage is deduced from Qmux config parameter for TDM mode usage. If the MT120 is connected to a BSC configured in IP mode TC sends the message M-TC-AUDIT-NEEDED to this concerned BSC. But if MT120 is connected to a BSC configured in TDM mode an output about the outcome of the operation is sent to the TC NEM operator. Exceptions: In case of TC does not receive the report In case of TC receives a report from BSC with status NACK


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 243/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.3 Use Case « TC Declaration » Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the GET SNMP request from the OMC-R to request the list of BSC Identifiers. Pre Conditions: TC G2.5 with TCIF (also named TC G2.5IP). Post Conditions: None. Inputs: GET_SNMP request Parameter: “list of BSC Identifiers” Outputs: SNMP GET-Response Description: TC sends its list of BSC Identifier to the OMC-R (DCN). Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 244/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.4 Use Case « TC STM1 interface Declaration/Undeclaration» Use case only available on TC G2.5 with TCIF. Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the SET SNMP request from the OMC-R. Pre Conditions: TC G2.5 with TCIF. Post Conditions: The list of STM1 interfaces has been updated. Inputs: SET_SNMP request with “list of STM1 interface” as parameter. Outputs: SET_SNMP response Description: On receipt of SET-SNMP with “list of STM1 Interface”, TC compares the received list to the current one to know the new declared STM1 interfaces and the new undeclared STM1 interfaces. For each new declared STM1 interface

The TC creates the required STM1-ITF and associated STM1-TTPs. EndFor For each new undeclared STM1 interface

The TC removes the STM1-ITF and associated STM1-TTPs EndFor Exceptions: None.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 245/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.5 Use Case «Getting current or candidate TC STM1 configuration» Use case only available on TC G2.5 with TCIF (also named TC G2.5IP). Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the GET SNMP request from the TC-NEM. Pre Conditions: TC G2.5 with TCIF. Post Conditions: The requested (current or candidate) configuration is stored in a file in TC-NEM. Inputs: GET_SNMP request with “current ” or with “candidate” as parameter. Outputs: GET_SNMP response Specific parameters:

• Current or candidate data Description: On receipt of GET-SNMP with “current” or with “candidate”, TC retrieves current or candidate configuration from TC SNMP MIB. TC sends back “current” or “candidate” data in GET-SNMP response. Remarks:

1. Before the first downloading of the STM1 configuration the candidate name and the candidate date retrieved from TC SNMP MIB is respectively the default candidate name in TC SNMP MIB “NoSTM1Configuration” and the default date “1970-01-01” The candidate name and the default candidate name apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_”.

2. Before the first apply STM1 configuration the current name and the current date retrieved from TC SNMP MIB is respectively the default current name in TC SNMP MIB “NoSTM1Configuration” and the default date “1970-01-01”. The current name and the default current name apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_”.


• If the specified file name already exists in the TC-NEM


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 246/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.6 Use Case «Getting properties for current or candidate TC STM1 configuration»

Use case only available on TC G2.5 with TCIF (also named TC G2.5IP). Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the GET SNMP request from the TC-NEM. Pre Conditions: TC G2.5 with TCIF (TC G2.5IP). Post Conditions: The requested (current or candidate) configuration is stored in a file in TC-NEM. Inputs: GET_SNMP request Parameters:

• “Current name” and “current date” Or • “Candidate name” and “candidate date”

Outputs: GET_SNMP response Specific parameters:

• Current properties (current name and current date) Or • Candidate properties (candidate name and candidate date)

Description: In case of current properties requested: On receipt of GET-SNMP with “current name, current date”, TC retrieves current properties (current name and current date) from TC SNMP MIB. TC sends back “current name and current date” in GET-SNMP response. Remark:

Before the first apply STM1 configuration the current name and the current date retrieved from TC SNMP MIB is respectively the default current name in TC SNMP MIB “NoSTM1Configuration” and the default date “1970-01-01”. The current name and the default current name apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_”.

In case of candidate properties requested: On receipt of GET-SNMP with “candidate name, candidate date”, TC retrieves candidate properties (candidate name and candidate date) from TC SNMP MIB. TC sends back “candidate name and candidate date” in GET-SNMP response. Remark:

Before the first downloading of the STM1 configuration the candidate name and the candidate date retrieved from TC SNMP MIB is respectively the default candidate name in TC SNMP MIB “NoSTM1Configuration” and the default date “1970-01-01”. The current name and the default current name apply the POSIX file name rules where


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 247/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The candidate name and the default candidate name apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_”.


o If the Get SNMP is unsuccessful. o No name or no date found or both


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 248/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.7 Use Case «Downloading a candidate TC STM1 configuration» Use case only available on TC G.5 with TCIF (TC G2.5IP). Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the SET SNMP request with “candidate data” as parameter from the TC-NEM. Pre Conditions: TC G2.5 with TCIF (TC IP). Post Conditions: Candidate data are stored in TC. Inputs: SET SNMP request as parameter “the name” of the configuration file to be used as candidate. Outputs: SET_SNMP response Description: The TC performs the following checks:

• The STM1 Interfaces used in candidate data are declared • The internal HSI interface is activated

If the check is OK the name file and the candidate configuration is stored in the active TCIF as the date available in TCIF. These three parameters (name, date and candidate data) are mirrored in the standby TCIF. If the check is NOK the candidate configuration is not stored in TCIF(s) and the status sent is NOK. The date (stored in TC) is sent in SET SNMP response. Remark: It is not intended to check the status of the plug before accepting the configuration. Missing plug or faulty plug will lead to alarms. The alarm dictionary will give details on the possible repair actions. Exceptions: An additional parameter is added in the SET-SNMP Response:

• If the internal HSI interface is not activated • If one or more STM1-ITF is not declared (additional parameter: the list of STM1-ITF

not declared)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 249/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.8 Use Case «Apply a candidate TC STM1 configuration» Use case only available on TC G2.5 with TCIF (TC G2.5IP). Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the SET SNMP request with “Applyconf” as parameter from the TC-NEM. Pre Conditions: TC G2.5 with TCIF (TC G2.5IP). Post Conditions: The candidate STM1 configuration is applied and run. Inputs: SET SNMP request with “Applyconf” as parameter. Outputs: SET_SNMP response Description: The TC performs the following checks:

• The STM1 Interfaces used in candidate data are declared • The internal HSI interface is activated

Then the TC applies the new STM1 configuration.

• The TCIF copies the candidate configuration as the current one. • The TCIF also copies the candidate name in the current name and the TCIF informs

the current date with the date available in TCIF. • The new “current name, date, and STM-1 configuration” must be mirrored on the two

TCIF boards.

• TCIF have to reconfigure its internal switches (E1/STM1) per the MT120, and then propagates the new configuration data to concerned MT120 boards via HSI. By reconfiguring the switch, all calls carried by the modified 2Mbits will be cut. If the operator has not disabled the concerned Atrunks, calls will be lost, and BTS will detect ‘Remote transcoder alarm’.

• TCIF has also to reconfigure the path trace as this information is coming with the configuration file. (Changing the path trace has no impact on the calls.)

• The “counter of STM1 configuration change” is incremented. This counter is used by OMC, which gets periodically this counter to see if a new STM1 configuration has been applied. If it is the case the OMC gets the new STM1 configuration. This “counter of STM1 configuration change” must be stored in the TC SNMP MIB.

Exceptions: An additional parameter is added in the SET-SNMP Response:

• If the internal HSI interface is not activated • If one or more STM1-ITF is not declared (additional parameter: the list of STM1-ITF

not declared) A partial successful is displayed to operator:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 250/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• If one or more target MT120 is/are off line (Remark: In this case the TCIF will reprogram the MT120 update as soon as the connectivity with the MT120 is reestablished.)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 251/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.9 Use Case «Display of TC’s section and path traces » Use case only available on TC G2.5 with TCIF. Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the GET SNMP request with “STM1-TTP number” as parameter from the TC-NEM. Pre Conditions: TC G2.5 with TCIF. Post Conditions: None. Inputs: GET SNMP request with parameter:

• STM1-TTP number Outputs: GET_SNMP response with parameters:

• Status • Section (J0) or/and path traces (J1 or/and J2)

Description: TC retrieves the section (J0) and/or path traces (J1 and J2) available for the requested STM1-TTP number. Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 252/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.10 Use Case «Modification of TC’s transmitted section and path traces» Use case only available on TC G2.5 with TCIF. Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the GET SNMP request with “STM1-TTP number” as parameter following by the reception of the SET SNMP request with “STM1-TTP number, New values” from the TC-NEM. Pre Conditions: TC G2.5 with TCIF. Post Conditions: None. Inputs: GET SNMP request with parameter:

• STM1-TTP number SET_SNMP request with parameter:

• STM1-TTP number • New values

Outputs: GET_SNMP response with parameters:

• Status • Section (J0) or/and path traces (J1 or/and J2)

SET_SNMP response with parameters:

• Status • Section (J0 bytes) or/and path traces (J1 or/and J2) updated

Description: On reception of the Get_SNMP TC retrieves the section (J0) and/or path traces (J1 and J2) available for the requested STM1-TTP number. On reception of the Set_SNMP TC updates the section (J0) and/or path traces (J1 and J2) for the requested STM1-TTP number with the values received. These new values are stored in TC. Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 253/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.11 Use Case «TC Plug identification information» Use case only available on TC G2.5 with TCIF. Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the GET SNMP request with “TCIF1, list of plug identity, TCIF2, list of plug identity” as parameters from the TC-NEM. Pre Conditions: TC G2.5 with TCIF. Post Conditions: None. Inputs: GET SNMP request with parameters:

• TCIF1 • PlugIdent1, PlugIdent2, PlugIdent3, PlugIdent4 • TCIF2 • PlugIdent1, PlugIdent2, PlugIdent3, PlugIdent4

Outputs: GET_SNMP response with parameters:

• Plug (s) connected and associated TCIF (TCIF1 or TCIF2) • Plug Indentification for each connected plug.

Description: TC retrieves the plug(s) connected and the associated motherboard TCIF, and also for each plug connected the plug identification. Remark: all plug identifications are mirrored on the 2 TCIFs (active and standbye). Exceptions: An error message is displayed to operator:

• If the TC does not report any plug identification • If no plug connected


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 254/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.12 Use Case «TCSL Endpoints Update» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-SET-TCSL-ENDPOINT message from the OMC-R. Post Conditions: New TC configuration is activated. Inputs:

Message M-SET-TCSL from OMC-R


TCSL Endpoint BSC side The list of BSC side TCSL Endpoint

Optional TCSL Endpoint TC side The list of TC side TCSL Endpoint Optional Outputs: A message M-SET-TCSL-ENDPOINT-RESPONSE is sent from TC about the outcome of the operation. Description: BSC side TCSL endpoints are updated in the TC. TC side TCSL endpoints are updated in the TC. Exceptions: The command is rejected if:

• Same value for two or more TCSL endpoints


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 255/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.13 Use Case «TC AUDIT» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-TC-AUDIT-REQ message from the BSC. Pre Conditions: None. Post Conditions: None Inputs:

Message M-TC-AUDIT-REQ from BSC Parameter name Purpose Optional/


TCSL version Identifier of the TCSL version Mandatory MT120 SW Version Identifier of the software version of the

MT120. Mandatory

Code server Identifier for software serveur giving FTPServerIPAddress, FTPPortNumber, user name, Password.

Mandatory

Outputs:

Message M-TC-AUDIT-REP from TC Parameter name Purpose Optional/


Status Status about the outcome of the operation

Mandatory TC-MUX Traffic Endpoint Identifies the endpoint where the

primary TC receives the multiplexed IP frames from the IP BTS. There is one TC-MUX endpoint per BSS.

Mandatory

TC-NONMUX Traffic Endpoint Identifies the endpoint where the secondary TC receives the un-multiplexed IP frames from the IP BTS. There is one TC-NONMUX endpoint per BSS.

Mandatory

TC Hardware family Represents the TC Rack Generation MT12O HW LIst List of MT120 (from 1 to N)

Per configured MT120 board (*): o Atermux link to which the MT

120 is connected o RIT Type (**) o MT120 capabilities o Rack number o Shelf number o Slot number o SW activation result

Mandatory

(*) From B10, different types of MT120 exits: the legacy MT120, the MT120-NB and the MT120-WB. (**) From B10 MR2, the RIT type depends on the type of MT120 boards The RIT type is a numerical value following Step 2 Label document, RIT type has 3 possible values for JBMTE2 (legacy MT120 board), JBMTE3WB (MT120-WB board) and JBMTE3NB (MT120-NB board). Description:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 256/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

The TC persists the Qmux link necessary data to be able to react on possible future TC NEM trigger for going back to TDM mode. If the MT120 are not in the expected MT120 software version:

• If the MT120 software is known in TCIF, TCIF activates it on the MT120. • If the MT120 software is not known in TCIF, TC will still try to download it from

whichever code server, preload and activate it.

The TC reports: • TC-MUX Traffic Endpoint • TC-NONMUX Traffic endpoint. • TC HW Family, represents the TC Rack Generation • Per configured MT120 board:

o The Atermux number to which the MT 120 is connected o RIT type (depends of the type of MT120 board: legacy MT120, MT120-NB,

MT120-WB) o MT120 capabilities o Rack number/shelf number/slot number o SW activation result.

From B10 release, for legacy MT120 or MT120-NB or MT120-WB the following table regroups the possible MT120 capabilities:

• The MT120 supports the TFO with AMR-NB codecs • The MT120 does not support the TFO with AMR-NB codecs • The MT120 supports the AMR-WB codecs and TFO • The MT120 does not support the AMR-WB codecs and TF0

Exceptions: The command is refused if:

• The expected MT120 software version cannot be found • The TCSL version is not correct for the TCIF software version


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 257/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.1.14 Use Case «TC Configuration Update» Available for IP transport feature Related BSS Service: This use case supports the S-HCM-ModifyHWConfig service; it is triggered by the reception of the M-TC-CONF-REQ message from the BSC. Pre Conditions: None. Post Conditions: TC configuration is updated. Inputs:

Message M- TC-CONF-REQ from BSC


MT 120 Table The MT 120 TABLE, gives for every (BSC associated) MT120 of every TC rack:

• The NONMUX endpoint of its rack

Mandatory

SS7 parameters (Only if “A signalling over IP” not activated”)

List of SS7 parameters Optional

Legacy parameters List of legacy TC parameters Optional Outputs:

Message M- TC-CONF-REP from BSC Parameter name Purpose Optional/Mandatory SS7 SG Endpoints (Only if “A signalling over IP” not already activated)

The SS7 endpoints having SS7 SG IP address and SS7 SG port number.

Optional

Description: In TC the received parameters are applied. Remark: Even if SS7 is “A signaling over IP”, BSC sends the M-TC-CONF-REQ message to the TC, it is indicated in MTP1 to TC (“no SS7”) so that TC knows there is no SS7 in the TC; in this case the MTP2 parameters are not sent to the TC. Exceptions: None


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 258/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

5.5.2 Dimensioning Data Not relevant. 5.5.3 Object Model This section is not relevant in the context of the B11.

6 GLOSSARY

AIFL Alarm In Force List AMR-WB Adaptive Multi-rate Wideband Speech Codec GMSK (AMR Wideband) AMR-NB AMR NarrowBand BIE Base station Interface Equipment BIU Base station Interface Unit BSC Base Station Controller BSC-TE BSC local TErminal BTS Base Transceiver Station BTS-O&M BTS O&M SBL BTS-TE BTS local TErminal BTS-TEL BTS Telecom SBL BSS Base Station Subsystem Bnumber BSS releases CIC Circuit Identity Code CMISE Common Management Information Service Elements CPF Configuration Parameter File DB DataBase DLS Data Load Segment DR Dual Rate DTC Digital Trunk Controller FB Functional Block FBS Functional Block Specification FR Full Rate FU Frame Unit HCM Hardware Configuration Management HO HandOver HR Half Rate HSL High speed Signalling Link HW HardWare IT In Traffic (SBL state) IMO Initialization & Maintenance Operations LCM Logical Configuration Management LMT Local Maintenance Terminal LSL Low speed Signalling Link MCB Multiplexed Channel Block MSC Mobile Switching Center MT120-NB MT120-NarrowBand (board)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 259/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

MT120-WB MT120-WideBand (board) MF Master File NSR Network SupeRvision N7 Number 7 signalling system O&M Operation and Maintenance OMC-R Operation and Maintenance Center - Radio part OML Operation and Maintenance Link OMU Operation and Maintenance Unit OMU-CPF Operation and Maintenance Unit Configuration Parameter File OPR OPerator out of seRvice (SBL state) OSSC Optimized Sectored Site Configuration PCM Pulse Code Modulation Qmux Transmission equipment supervision bus , also called "Q1" RC Ring Control RIT Replaceable ITem RSL Radio Signalling Link SBL Security Block SDH Synchronous digital hierarchy SFS System Functional Specification SLC Signalling Link Code SM A-Interface Sub-Multiplexer SPC Signalling Point Code (MSC/BSC address) STM Synchronous transport mode SUM BTS Station Unit Module SUMP BTS Station Unit Module PCM SUMA BTS Station Unit and Maintenance version A SW SoftWare SWM SoftWare Maintenance TAS TMN Administration Services TC TransCoder TC-TE TC terminal TC-NEM TC Terminal from B10, available with TC G2.5 with TCIF (TC IP) TC-SM2M Submultiplexor at transcoder site TCH Traffic CHannel TCU Terminal Control Unit TFO Tamdem Free Operation TRCU TRansCoder Unit TRE Transceiver Equipment (FU + CU) TS Time Slot TSC Transcoder Submultiplexer Controller USOD Usage State On Demand (in fact DTC USOD) VC Virtual Container WTC Wait Traffic Clear X25 X25 link


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 260/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

APPENDIX A. STM1 TC

A.1 TC STM1 Configuration

The STM-1 configuration (logical E1 to VC12 mapping) is only performed from the TC NEM. Configuration Granularity The configuration granularity is the MT120. On MT120 the flexibility on Ater interface and A interface is supported, i.e the A/Ater interface independence is supported. Configuration Preparation, Downloading and Application The operator prepares the configuration in a first operation, downloads it in the TC in a second step and applies this configuration later, in a third operation. During the preparation phase the TC NEM operator uses a ‘working’ STM-1 configuration file. The TC NEM operator can also check the correctness of the working file. In addition he has the possibility to get the impact of the working file configuration in case it would be applied through a ‘Compare’ command that produces a configuration impact file. This file contains all E1 links with a change:

• if the E1 link is changed from physical to SDH: the SDH tributary • if the E1 link is changed from SDH to physical • if the SDH tributary changes

SNMP messages are used between TC NEM and TCIF board. The TC NEM perfoms SNMP attributes � File translation and uses the file for display. The same principle applies to the OMC when displaying the current STM-1 configuration. Remark: No FTP server exits on TCIF. The following functionalities are requested on TC NEM:

• The display of the current STM-1 configuration file (‘get current conf’). • The display of the candidate STM-1 configuration file (‘get candidate conf’) • The download of a working STM-1 configuration file on TC (‘set conf’). Before the

effective download of the working STM-1 configuration file, checks are requested to verify some coherencies. One of those checks is that all the A interfaces of an MT120 are consistent in terms of STM-1 or physical E1 configuration (no mixity on A interface for a given MT120). Another check is that an MT120 interface appears only once as a VC12. Once downloaded, the STM-1 configuration is identified as the ‘candidate’ configuration. The TC rack only knows ‘current’ and ‘candidate’ STM-1 configurations. The TC NEM knows ‘current’, ‘candidate’ and ‘working’ (possibly several) configurations.

• The edition of the candidate STM-1 configuration file for direct configuration update (see next paragraph). The updated configuration file is called a working STM-1 configuration file as long as it is only local to the TC NEM and different from the candidate STM-1 configuration file present on the TC. It becomes a ‘candidate’ STM-1 configuration file again as soon as it is successfully downloaded on the TCIF. In a ‘candidate’ STM-1 configuration file, all MT120 (equipped or not equipped) are mentioned in the table and each MT120 interface is configured either STM-1 or E1.


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 261/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• The application of the candidate STM-1 configuration file on TCIF. Note that the candidate STM-1 configuration file is applied globally.

The TC NEM has a specific STM1 directory to manage the TC STM1 actions. The name of this directory is ‘<prefix>/<TC-Id>/STM-1 This STM1 directory has four subdirectories named:

o Template o Configuration o Candidate o Current

The subdirectory ‘Template’ contains Alcatel and customers default STM-1 configuration files. The subdirectory ‘Configuration’ contains all the working files. A new working STM-1 configuration file can be created from a default STM-1 configuration file (also named template), from a getting configuration, or by import of working STM1-configuration files. The name of a working file has to set by operator. To apply the POSIX file name rules where allowed characters are “A-Z,a-z,0-9,-,_” in TC NEM the name of the working file will verify at the loading in the subdirectory ‘Configuration’ and if spaces are present in the working name that will be skipped before this name is stored in the subdirectory ‘Configuration’. The subdirectory ‘Candidate’ contains the files resulting of a ‘getting a candidate configuration’ action. The subdirectory ‘current’ contains the files resulting of a ‘getting a current configuration’ action. The TC NEM is delivered with an Alcatel default STM-1 configuration for TC. This Alcatel default file is delivered as an example for building working configuration files. The name of the Alcatel default STM-1 configuration file is ‘stm1Alcatel’ and it is stored in the subdirectory ‘Template’. Of course nothing prevents the operator from saving on TC NEM (‘STM-1/Configuration’ directory) its own default-working file. There is no constraint on working file name; the name of a working file has to set by operator. Whatever the name, it is copied in ‘ <name.<date>.extension’ after successful download. For all these files the extension of the file can be csv or xls. The current STM-1 configuration and the candidate STM-1 configuration are stored in TC MIB, accessible through SNMP. At any time the operator can modify the STM-1 configuration even if the boards are running. The modification of the STM-1 configuration can be made: From physical E1 to STM-1 X, VC12 K/L/M From (STM-1 X, VC12 K/L/M) to (STM-1 Y, VC12 K’/L’/M’) (X different from Y, X=1 to 4, Y=1 to 4 and according G.707: (K,L,M) with K=1,2,3 L=1,…,7 ; M=1,…,3) From STM-1 X VC12 KLM to physical E1 The OMC only gets the current STM-1 configuration from the TC (Periodical polling from OMC of the STM-1 configuration) The OMC displays on demand the stored STM-1 configuration in OMC in a HTML view. The TC rack view displays the STM-1 � E1 mapping in both directions: per MT120 as native rack view structure, but also in a second part per STM-1, for operator comfort reasons. This


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 262/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

second part can be seen as nice to have and can be dropped in case of strong development schedule constraints. The import and the export of the TC STM1 configuration file is described in the document Transmissions Termination Points Configuration export or import file Ref [A29].

A.2 Section and path trace management

It is not requested to:

• Compare automatically the received section or path trace bytes (J0 & J1 & J2 bytes)

with a user programmable string, the expected value. In this case no configurable expected value is necessary. The manual checking avoids maintaining this user programmable string in case of transmission network evolution.

• Report an alarm if the received section or path trace bytes (J0 & J1 & J2 bytes) is

changed. Otherwise it would be possible to have alarm in case of normal transmission network evolution.

Be carefull, the section and path traces must not be changed during software replacement.

A) Transmitted section trace

Default value The default value for section trace is: "TCxxna" Where:

• xx is the TC rack number • n is the STM1-ITF identifier (from 1 to 4) • a indicates the board carrying the section (from 1 to 2)

Transmitted section trace configuration At TC NEM it is possible to select one STM1-TTP and to configure the section trace transmission. First the operator has to select the section trace type:

• One byte (for compatibility reason: see G707); Or

• 16 bytes framed. In case of one byte section trace, the operator has to enter the byte value (default is 1)


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 263/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

In case of 16 bytes framed section trace, the operator enters the string to be transmitted. The string has the following requirements:

• The string must have 15 characters at maximum; • Only alphanumeric characters ("A" to "Z", "a" to "z" and "0" to "9") are allowed; • Spaces are allowed at the end (for compatibility reason: see ITU-T G831); • If the string has less than 15 characters the padding character is "NUL"

If the string is empty the default value is taken into account. The three parameters, Section-Trace-Type and default Section-Trace-String and current Section-Trace-String, have to be stored into the TC SNMP MIB. Before an operator enters the string to be transmitted the current Section-Trace-String is equal to the default Section-Trace-String.

B) Transmitted High path trace (J1 byte)

This is the first byte in the virtual container (V-4). This byte is used to transmit repetitively a path access point identifier so that a path-receiving terminal can verify its continued connection to the intended transmitter. A 16-byte frame is defined for the transmission of an access point identifier. The first byte of the 16-byte frame is a header byte and includes the result of a CRC-7 calculation over the previous frame. The following 15 bytes are used for the transport of 15 characters required for the access point identifier. Default string value The default string value for path trace J1 is: "TCJ1xxan" Where:

• xx is the TC rack number • a indicates the board carrying the section (from 1 to 2) • n is the STM1-ITF identifier (from 1 to 4)

Transmitted High path trace configuration At TC NEM it is possible to select one STM1-TTP and to configure the high path trace transmission. The operator enters the string to be transmitted.

The string has the following requirements: o The string must have 15 characters at maximum; o Only alphanumeric characters ("A" to "Z", "a" to "z" and "0" to "9") are allowed; o Spaces are allowed at the end (for compatibility reason: see ITU-T G831); o If the string has less than 15 characters the padding character is "NUL"

If the string is empty the default value is taken into account.

The two parameters default Path-Trace-J1-String and current Path-Trace-J1-String, have to be stored into the TC SNMP MIB.

C) Transmitted Low path trace (J2 byte)

Byte J2 is used to transmit repetitively a low order path access point identifier so that a path-receiving terminal can verify its continued connection to the intended transmitter. Default value The default value for path trace is: "TCJ2xxmssddddy" Where:


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 264/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

• xx is the TC rack number • m is the shelf number of the MT120 carrying the link • ss is the slot number of the MT120 carrying the link • dddd indicates the type of interface:

o "ATER" for Ater interface o "AITF" for A interface

• y indicates the logical number of the interface (1 for A interface tributary 1, 2 for A interface tributary 2, 3 for A interface tributary 3, 4 for A interface tributary 4, 5 for Ater interface).

Remark for HSL:

• In case of IP mode: the path trace is the one from the A-PCM-TP that is carrying the HSL.

Transmitted Low path trace configuration In transmission ports configuration file one field is added, before the comment field:

• Name: Path Trace • Description: This column gives an identification of the TU12 to be transmitted into J2

bytes. • Coding rule:

o The string must have 15 characters at maximum; o Only alphanumeric characters ("A" to "Z", "a" to "z" and "0" to "9") are allowed; o Spaces are allowed at the end (for compatibility reason: see ITU-T G831); o If the string has less than 15 characters the padding character is "NUL" o If the string is empty, default value is used.

The two parameters default Path-Trace-String and current Path-Trace-String have to be stored into the TC SNMP MIB.

D) Section trace and Path trace display

See paragraph 5.4.1.7 Display of TC’s section and path traces


04/06/2008

0469_1RL.doc 3BK 11204 0469 DSZZA 265/265

All

Righ

ts Re

serve

d © A

lcatel

-Luce

nt

APPENDIX B. INDEX OF MESSAGES M-CONFIG-ATER ...................................................................................................................................... 184 M-CONFIG-ATER-REPORT........................................................... 184, 203, 205, 207, 209, 211, 212, 214 M-CONFIG-DISPLAY ........................................................................................................................... 175, 177 M-CONFIG-DISPLAY-REPORT ......................................................................................................... 175, 177 M-FILE-READ........................................................................................................................................ 175, 177 M-FILE-READ-REPORT ...................................................................................................................... 176, 177 M-LOGICALPARM-DISPLAY .................................................................................................................... 175 M-LOGICALPARM-DISPLAY-REPORT .................................................................................................. 175 M-LOGICALPARM-MODIFY (Hardware-BTS-Type group) .................................................. 194, 195, 196 M-LOGICALPARM-MODIFY-REPORT ................................................................... 194, 195, 196, 199, 200 M-PROG-TRANS-ATER ............................................................................................................................... 186 M-PROG-TRANS-ATER-REPORT ............................................................................................................. 186

END OF DOCUMENT

Documents

Hardware Configuration Management