Hardware Configuration Management

Site
All Rights Reserved Alcatel-Lucent
VELIZY Originators S.MAINTROT
GSM/WiMAX Business Division Hardware Configuration Management BSC, TC and ATER part Release B11
System Sub-system Document Category EXECUTIVE SUMMARY
: : :
ALCATEL-LUCENT GSM BSS SYS-TLA PRODUCT DEFINITION
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.
Name App. Name App. Y. GORJUX DPM OSY A. COZMA DPM TC Approvals WU ANMIN DPM BSC DPM OMC L.F. MUNTEAN DPM O&M DPM BTS
Ed. 01 Proposal 01 Ed. 01 Proposal 02 Ed. 01 Proposal 03
REVIEW
<08/03/25> <08/04/18> <08/05/09>
Wireless/GSM/TD/OSY/SMA/208085 Wireless/GSM/TD/OSY/SMA/208100 Wireless/GSM/TD/OSY/SMA/208107
HISTORY
ED 01 RELEASED
Hardware Configuration Management BSC, TC and ATER part B11

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
1/265
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-SigAtermux is sent only in TDM mode.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
2/265
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] 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
Ed.01 Proposal 03
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
3/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
4/265
TABLE OF CONTENTS
TABLE OF CONTENTS......................................................................................................................... 5
INTERNAL REFERENCED DOCUMENTS ......................................................................................... 10 REFERENCED DOCUMENTS ............................................................................................................ 10 PREFACE ............................................................................................................................................ 11 RELATED DOCUMENTS .................................................................................................................... 10
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 ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
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
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
1 INTRODUCTION............................................................................................................................. 12 1.1 Scope .......................................................................................................................... 12 1.2 Methodology Overview ............................................................................................. 12 1.3 Document Structure .................................................................................................. 13
3BK 11204 0469 DSZZA
5/265
ED 01 RELEASED
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 N7 Mode from LSL to HSL or HSL to LSL............................ 79 4.1.12.1 Change N7 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 TCs section and path traces scenario ..................................................... 104 4.2.3.9 Modification of TCs 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 BSCs LIU/STM1 resource scenario................................................................... 113 4.2.4.10 Display of BSCs section and path traces scenario .......................................... 114 4.2.4.11 Modification of BSCs transmitted section and path traces scenario ................ 115 4.3 Subscenario for Programming of Ater Transmissions........................................ 116 4.3.1 Program Ater Transmission subscenario.................................................................... 116 Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
6/265
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 N7 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 Properties200 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 BSCs section and path traces .................................... 206 5.2.1.20 Use Case Modification of BSCs transmitted section and path traces.......... 207 ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
7/265
6 GLOSSARY .................................................................................................................................. 258
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 BSCs LIU/STM1 resources ......................................................... 220 5.3.1.10 Use Case Display of BSCs section and path traces .................................. 221 5.3.1.11 Use Case Modification of BSCs 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 TCs section and path traces ............................................. 236 5.4.1.8 Use Case Modification of TCs transmitted section and path traces ................... 237 5.4.1.9 Use Case TC Plug identification information display .......................................... 238 5.4.2 Dimensioning Data ...................................................................................................... 239 5.4.3 Object Model ............................................................................................................... 239 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 TCs section and path traces .............................................. 251 5.5.1.10 Use Case Modification of TCs 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 5.5.2 Dimensioning Data ...................................................................................................... 258 5.5.3 Object Model ............................................................................................................... 258
APPENDIX B.
APPENDIX A. STM1 TC ........................................................................................................... 260 A.1 TC STM1 Configuration........................................................................................... 260 A.2 Section and path trace management..................................................................... 262 INDEX OF MESSAGES .................................................................................... 265
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
8/265
TABLE OF FIGURES
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 N7 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 BSCs section and path traces scenario......................................................... 114 Figure 58: Modification of BSCs transmitted section and path traces scenario .............................. 115
1
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
9/265
Figure 59: Program Ater Transmission sub scenario ......................................................................... 116
INTERNAL REFERENCED DOCUMENTS
REFERENCED DOCUMENTS
[1] [2] [3] [4] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] 3BK 10013 0001 DTZZA 8BL 14206 0002 PTZZA 8BL 14206 0004 BGZZA 3BK 11203 0036 DSZZA 3BK 11204 0298 DSZZA 3BK 11204 0418 DSZZA 3BK 11203 0331 DSZZA 3BK 10029 0001 DSZZA 3BK 11204 0396 DSZZA 3BK 11204 0478 DSZZA 3BK 11204 0623 DTZZA TBD System and Subsystem Specification strategy FBS Standard Plan OMT Method Application Guide for SAS System Functional Specification B6 Abis signalling links statistical submultiplexing Abis signalling links multiplexing improvement for Micro BTS and BTS G3 (E)GPRS/LCS O&M Functional Architecture Inventory file specification Hardware Configuration Management B10 BSS O&M Parameters B11 SFD Remote Inventory MFS at OMC-R Remote Inventory Export Interface Remote Inventory Interface File Specification (Standard CSV file interface) SFD Adaptative Multi-Rate Wideband Speech Codec GMSK (AMR-WB) SFD B11 O&M Impact of IP Transport, Ater area SFD B11 TFO for AMR-NB and AMR-WB Speech codec list for GSM and UMTS BSC Alarm Dictionary
3BK 11256 0011 DSZZA 3BK 10204 0022 DTZZA 3BK 17040 1003 DSZZA
MX PLATFORM : DFS Hardware Management SFD BTS with up to 24 TRE
3BK 10204 0095 DSZZA 3BK 10204 0049 DTZZA 3BK 10204 0096 DTZZA 3GPP TS 26.103 3BK 11204 0466 DSZZA
RELATED DOCUMENTS
[A1] [A2] [A3] [A4] [A5] [A6] [A7] [A8] [A9] [A10] [A11] 3BK 11204 0454 DSZZA 3BK 11204 0395 DSZZA 3BK 11204 0458 DSZZA 3BK 11204 0462 DSZZA 3BK 11204 0471 DSZZA 3BK 11204 0472 DSZZA 3BK 11203 0075 DSZZA 3BK 11203 0057 DSZZA 3BK 11210 0065 DSZZA 3BK 11204 0445 DSZZA 3BK 11204 0475 DSZZA TSC-NE Communication Protocols Specification Release B11 FBS SWM: Software Maintenance B10 FBS NSR: Network Supervision (BSC, TC and ATER part B11 FBS IMO: Initialisation and Maintenance (BSC, TC and ATER part B11 FBS LCM: Logical Configuration Management B11 FBS TAS: TMN Administration Services B11 Transmission architecture specification Transmission functional specification Coding of OMU-CPF OMC-BSS SW/HW File Format Specification B11 OMC/MFS Ater & Gb Domain B11
04/06/2008
ED 01 RELEASED

0469_1RL.doc
3BK 11204 0469 DSZZA
10/265
[A12] [A13] [A14] [A15] [A16] [A17] [A18] [A19] [A20] [A21] [A22] [A23] [A24] [A25] [A26] [A27] [A28] [A29]
3BK 11204 0477 DSZZA 3BK 11204 0463 DSZZA 3BK 11204 0473 DSZZA 3BK 11256 0016 DSZZA 3BK 11204 0456 DSZZA 3BK 11204 0473 DSZZA
3BK 11204 0386 DSZZA 3BK 10204 0073 DTZZA MND/TD/OSY/CGO/205405 3BK 11204 0376 DSZZA 3BK 10204 0067 DTZZA 3BK 11204 0480 DSZZA MND/TD/OSY/SMA/206026 3BK 11204 0468 DSZZA 3BK 11204 0470 DSZZA 3BK 11204 0449 DSZZA
FB Performance Management release B11 OMC/BSC SBL Concept B11 OMC/MFS HW Domain B11 MXPF DFS: NE1 over Ethernet Services Network Supervision (General part) Initialisation & Maintenance (General part)
SFD GERAN TWIN TRA Introduction in B8 and B9 Delta Note HCM B9 ed2 released/HCM B10 IP Abis part TC G2.5IP SNMP MIB interface specification Release B10 SFD STM-1 Impact for TC Network Modification Process and Performance (NMPP) BSS configuration and ATER part Release B11 Delta Note HCM B10 IP Ater Part (included delta in TMN administration services) Hardware Configuration Management (BTS and ABIS part) Remote Inventory Transmissions Termination Points Configuration Export or Import file
O&M TPGSM Interactions B10
This document specifies, for BSC, TC and ATER part, the distribution of the Hardware Configuration Management FBs services over the different subsystems.
PREFACE
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
11/265
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:
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
12/265
Initiating Subsystem
Scenario Name (Doc)
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 wont 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
13/265
GENERAL PRINCIPLES
2.1
Scope and Basic Principles
In order to make easier, speed up and secure the reconfiguration of the BSS hardware, Online 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
ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
14/265
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:
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
15/265
Configuration Type Capacity
1 Nb TRX Nb Cell1 Nb BTS2 200 200 150 96 10 6 50 40 24 64 1 1 1 8
2 400 400 255 96 20 12
3 600 500 255 176 303 18
4 800 500 255
5 1000 500 255 176 485 28
Nb of E1
Nb of VCE On CCP
Abis Ater CS Ater PS
Nb TCU Nb DTC CS Nb DTC PS Nb DTC (BSSAP)
100 80 48 128 1 1 1 8 1 2 2 2
150 120 72 192 1 1 1 8
176 404 24 200 160 96 256 1 1 1 8
250 192 112 256 1 1 1 8
Nb of VCE On Nb TCH-RM pairs6 OMCP SCPR pairs OCPR pairs Nb TSC pairs7 Nb boards Nb CCP ATCA Nb spare CCP Nb OMCP Nb SSW Nb TP GSM Nb SMM boards Nb SMM Nb boards LIU Nb MUX Nb LIU 9
3 1 2 2 2
4 1 2 2 2
1 2 2 2
1 2 2 28 2 2 16
2 8
2 8
2 14
2 15
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 MAXATERMUX-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 MAXATERMUX-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 MAXATERMUX-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.
1
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
16/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
17/265
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
18/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
19/265
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:
Abis-Hway-Tp Ater-Hway-Tp 200TRX 96 16 400TRX 96 32 600TRX 176 48 800TRX 176 64 1000TRX 176 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-HwayTp.
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
20/265
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
21/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
22/265
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:
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
23/265
Working STM-1 configuration file

Set conf
Candidate STM-1 configuration Apply conf
Current STM-1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
24/265
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 candidateconfiguration. 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 VC12E1. 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
25/265
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. ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
26/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
27/265
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 23.85 kbit/s 15.85 kbit/s 12.65 kbit/s 8.85 kbit/s 6.60 kbit/s Full-rate Half-rate GMSK 8-PSK
List of wideband codec modes
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
28/265
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 boards Type MT120 SW capability AMR-WB TFO-NB No No Yes Yes Yes Yes Release B11 B11 B11
Legacy MT120 MT120-NB MT120-WB
AMR-NB Yes Yes Yes
TFO-WB No No Yes
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 BSC G2 MX BSC AMR-NB
Yes Yes
TFO-NB
No
AMR-WB
Yes
TFO-WB
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 MT120NB 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. ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
29/265
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 doesnt 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
30/265
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)
BSC BSSAP SCCP MTP3 MTP2 MTP1 N7 Links TC
MSC BSSAP SCCP MTP3 MTP2 MTP1
Figure 2 A signalling is transferred in pure TDM mode (SS7 LSL) 2. The mixed mode: The SS7 mode is LSL. ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
31/265
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 IP Network TC NIF M2UA SCTP IP MTP2 MTP1 N7 Links
MSC
BSSAP SCCP MTP3 MTP2 MTP1
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
32/265
MSC
IPSP1
M3UA SCTP IP
BSC
IPSP
M3UA SCTP IP
IP
IPSP2
M3UA SCTP IP
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].
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
33/265
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 TS 14 TS 31 Others Except TS 15 & TS16 TDM /LSL Qmux X25 or TCH TCH TDM /HSL Qmux X25 or TCH TCH IP/LSL TCH TCH TCH IP/HSL 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: ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
34/265
- 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 N7 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
Atermux Number TS 16 1.16 N7 (*) TDM /LSL 17.30 + 61.76 TDM /HSL 1.30 + 61.76 (**) 1.16 IP/LSL 17.30 + 61.76 TCH TCH IP/HSL 1.30 + 61.76 TCH
TCH/GCH
TCH / GCH
(*) N7 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
35/265
Atermux Number TS 16
TDM /LSL 1.16 17.30 + 61.76 N7 (*) Not used
TDM /HSL 1.30 + 61.76 (**) Not used
IP/LSL 1.16 17.30 + 61.76 Not Not used used
IP/HSL 1.30 + 61.76 (**) Not used
(*) N7 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).
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
36/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
37/265
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 and S-HCM-
This FB supports the S-HCM-ModifyHWConfig, S-HCM-PCMConfig INVENTORY services defined in reference document [4].
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
38/265
3.3
Services/Subsystems Mapping
3.3.1
Services/Subsystems Mapping OMC-R, BSC Terminal, BSC, BTS

Service Name O&M Action Declare BSS Undeclare BSS Modify a BSS Configure G2 BSC/TC(***) OMC-R Use Case Add a BSS Delete a BSS Modify BSS Identification OMC/BSC synchronisation BSC Terminal Use Case BSC Use Case BTS Use Case
S-HCMModifyHWConfig S-HCMModifyHWConfig S-HCMModifyHWConfig S-HCMModifyHWConfig
Activate new G2 BSC/TC standard configuration BSC hardware audit Activate new Mx BSC/TC standard configuration BSC hardware audit
S-HCMModifyHWConfig
Configure Mx BSC/TC(***)
OMC/BSC synchronisation
S-HCMModifyHWConfig
Discover a BSS
Complete BSS audit
TC hardware audit BSC hardware audit BTS hardware audit (HCM BTS and AbiS part (Ref [A27])
BTS hardware audit (HCM BTS and AbiS part (Ref [A27])
S-HCMModifyHWConfig S-HCMModifyHWConfig
Display Rack Layout Display VCE
Display Rack Layout Display VCE
S-HCMModifyHWConfig
BSC/GPU IP Association
BSC/GPU IP Association
Modify MFS Characteristics
S-HCMModifyHWConfig S-HCMModifyHWConfig S-HCMModifyHWConfig
Change BSS Transport Mode on BSC side Modify BSC SS7 Transport Mode Plug identification information
BSS Transport Mode Switch Modify BSC SS7 Transport Mode BSC Plug identification information display Display BSS topology
BSS Transport Mode Switch Modify BSC SS7 Transport Mode
S-HCM-PCMConfig S-HCM-PCMConfig
Display BSS topology Suspend Automatic Transmission programming
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
39/265
Service Name S-HCM-PCMConfig
O&M Action AterMux configuration for GPRS
OMC-R Use Case 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 Change Ater connection type Change CRC4 Loudness setting
BSC Terminal Use Case
BSC Use Case
BTS Use Case
Modify AterMux GPRS Ater Signalling Configuration
S-HCM-PCMConfig
Configure Ater
Configure Ater Program Ater Transmission Getting current or candidate BSC STM1 configuration Getting current or candidate BSC 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 BSCs LIU/STM1 resource Display of BSCs section and path traces Modification of BSCs transmitted section and path traces Setting a candidate BSC STM1 configuration Applying a candidate BSC STM1 configuration Getting current or candidate BSC STM1 configuration Getting current or candidate BSC STM1 configuration Properties
S-HCM-PCMConfig
BSC STM1 Management
Configuration
Half-rate setting
Display of BSC s section and path traces Modification of BSCs 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
40/265
S-HCMModifyHWConfig
Service Name
O&M Action TC Management
OMC-R Use Case TC Declaration TC Removal Display TC Data Update TC Information
TC-NEM Use Case
BSC Use Case
TC Use Case TC Declaration
S-HCMModifyHWConfig
TC Supervision
Move TC Supervision to another BSSIM Update TC Supervision
S-HCMModifyHWConfig
M120 Adding/Removal
Activate new G2.5 TC standard configuration BSC-TC Audit Activate new TC G2.5 with TCIF standard configuration TCSL Endpoint Update TC Audit TC Configuration Update
S-HCMModifyHWConfig
TCSL Endpoints resynchronisation
TCSL Resynchronisation
Modify TC Characteristics BSC-TC Audit
S-HCMModifyHWConfig S-HCMModifyHWConfig S-HCM-PCMConfig
STM1 Declaration/Undeclaration Plug information identification
STM1 Declaration/ Undeclaration TC Plug identification information display 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 TCs section and path traces Modification of TCs transmitted section and path traces
STM1 Declaration/ Undeclaration
TC STM1 Configuration Management
Getting current or candidate TC STM1 configuration
Downloading a candidate TC STM1 configuration Applying a candidate TC STM1 configuration
Display of TCs section and path traces Modification of TCs transmitted section and path traces Inventory TC Inventory TC
S-HCM-inventory S-HCM-inventory
Automatic inventory On demand inventory
Automatic inventory On demand inventory
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
41/265
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 N7 mode from LSL to HSL or from HSL to LSL. Modify BSC SS7 Transport Mode
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
42/265
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
43/265
Description
BSC-TE
OMC
BSC
TC
Operator requests to modify and activate a new standard configuration using G2 BSC local terminal G2 BSC acknowledges the activation of the new configuration via local terminal G2 BSC sends an alarm to the OMC-R (after the DLS was updated)
A-ACTIVATE-NEW-CONF
A-ACTIVATE-NEW-CONF-ACK M-ALARM-REPORT (MX BSC, HW_Resynch, Event)
OMC-R invokes automatically BSC hardware audit.
BSC hardware audit (HCM) A-PROG-TRANS
Operator request a Program transmission using G2 BSC local terminal (it is a integrated part of the Activate-new-conf) G2 BSC acknowledges the Program transmission via local terminal After the Prog-Trans receipt from the G2 BSC local terminal, G2 BSC launches the TC discovery phase.
A-PROG-TRANS-ACK TC DISCOVERY PHASE BSC, TC and Ater part) (HCM
Figure 5: Activate new G2 BSC/TC standard configuration scenario

OMC-R Use case 5.1.1.5 OMC/BSC synchronisation BSC Use case 5.2.1.1 Activate new BSC/TC standard configuration 5.2.1.2 BSC hardware audit
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
44/265
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
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. Operator requests to modify and activate a new standard configuration using MX BSC local terminal 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]).
BSC-TE
OMC
BSC BSC Application
MX Platform
TC
MF-HW-Board-Insertionremoval-Notification
MF-PMS-BoardReadiness
A-ACTIVATE-NEW-CONF
Service Request(MF_NE1oE_CO NFIGURE(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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
45/265
Description
BSC-TE
OMC
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. 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
BSC BSC Application
HW_Board_reset (FRUId) HW_Board_reset_report
MX Platform
TC
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). MX BSC acknowledges the Program transmission via local terminal In case of Mx BSC reduction, operator can now remove the no more used CCP. EndFOR
A-PROG-TRANS
A-PROG-TRANS-ACK
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. EndIF
TC DISCOVERY PHASE (HCM BSC, TC and Ater part)
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 5.1.1.5 OMC/ BSC synchronisation BSC Use case 5.2.1.1 Activate new BSC/TC standard configuration 5.2.1.2 BSC hardware audit
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
46/265
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
While the TC boards are not all identified
BSC-TE
OMC
BSC
TC
Discovery Phase
BSC sends periodically a Equipment Identity request (using Qmux interface) to the TC to identify the RIT type. 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. Then, BSC sends a functional Identity request (using Qmux interface) to the TC to retrieve the RSS information. 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. 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. BSC updates the capabilities of the MT120 in DLS in accordance with the received capabilities. 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
Equipment Identity Request Equipment Identity Report
Functional Identity Request Functional Identity Report Discovery Phase
Capabilities Request Capabilities Report
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
47/265
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
Description
BSC-TE
OMC
BSC
TC
BSC transfers data configuration to TC to reconfigure the transmissions boards (using Qmux interface). 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).
Data Configuration download procedure
Timer elapsed
EquipmentIdentity Request Functional Identity Request .
At timer expiration, MX BSC sends a TC HW_Resynch alarm to the OMC-R for synchronisation
M-ALARM-REPORT (MX BSC, TC HW_Resynch, Event)
OMC-R invokes automatically TC hardware audit. End while EndIF
TC hardware audit (HCM)
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
The OMC-R requests the TC configuration file to the BSC BSC generates the configuration file with the content of DLS.
OMC
BSC
M-CONFIG-DISPLAY (TC)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
48/265
BSC returns a file identifier If the BSC is a G2 BSC then OMC-R opens an FTAM association with the BSC and reads this configuration file The file is retrieved by the OMC-R through FTAM. 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 OMC-R indicates transfers completion and updates if needed its database BSC deletes file and acknowledges transfer's completion. EndFor The OMC-R requests the alarm and resource audit and the state audits at level BSC
Description
OMC
M-CONFIG-DISPLAY-REPORT E-FTAM-FILE-READ
BSC
E-FTAM-FILE-READ-REPORT
FTP-FILE-READ
M-FILE-READ M-FILE-READ-REPORT
OMC-BSC Alarm and resource audit (NSR) OMC-BSC State audit (NSR)
Figure 8 TC hardware audit sub-scenario

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

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
49/265
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 doesnt 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 doesnt 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
Operator requests to discover a BSS A complete BSS audit is requested to the BSC and BTS(s).
OMC
A-DISCOVER-BSS 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)
BSC/BTS
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
50/265
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.3 HW SW Overall Audit sub-scenario
4.1.3.1.1 Hardware Audit sub-scenario
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
51/265
4.1.3.1.1 Hardware audit sub-scenario

Description
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 FOR each BTSs with BTS-O&M Status not OPR The scenario BTS hardware audit is invoked ENDFOR
OMC
BSC Hardware audit (HCM)
BSC/BTS
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 BTS hardware audit scenario Sub-scenario (See HCM BTS and Abis part [A27])
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
52/265
4.1.3.1.2 BSC hardware audit sub-scenario

Description
The OMC-R requests the Peer Entities audit only if BSC hardware audit is explicitly triggered by operator The OMC-R requests the HW SW overall type Audit (except in case of discover) For each following parameter group: Cic-Atrk-Type No7-Netw-Addr-Type GPRS-BSC-Type Bts-Id-To-Cell-Id-Type
OMC
Peer entities audit (TAS) HW/SW Overall Type Audit
BSC
The OMC-R requests this parameter group to the BSC 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. BSC returns a file identifier If the BSC is a G2 BSC then OMC-R opens an FTAM association with the BSC and reads this configuration file The file is retrieved by the OMC-R through FTAM. 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 OMC-R indicates transfers completion and updates if needed its database BSC deletes file and acknowledges transfer's completion. If the configuration file is the BSC HW and if it is a MX BSC then OMC-R requests the redundancy status EndFor If it is a MX BSC then OMC-R launches MX BSC inventory
M-LOGICAL-PARM-DISPLAY (Param Group) M-LOGICAL-PARM-DISPLAY-REPORT
M-CONFIG-DISPLAY (Configuration File)
M-CONFIG-DISPLAY-REPORT E-FTAM-FILE-READ
E-FTAM-FILE-READ-REPORT
FTP-FILE-READ
M-FILE-READ M-FILE-READ-REPORT M-LOGICAL-PARM-DISPLAY (HW_LOG_Mapping_Type) M-LOGICAL-PARM-DISPLAY-REPORT
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)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
53/265
Figure 11: "BSC hardware audit" sub-scenario

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

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
54/265
4.1.3.1.3 HW/SW Overall Audit Sub-scenario

Description
The OMC-R requests the HW/SW overall Audit BSC reports the information of the HW-SW Overall Type Group The OMC-R updates its database
OMC
BSC
M-LogicalParam-Display (HW-SW-Overall-Type)
M-LOGICAL-PARM-DISPLAY-REPORT
OMC-R Use case 5.1.1.7 HW/SW Overall Audit
BSC use case 5.2.1.2 BSC Hardware Audit
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
55/265
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
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. 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. OMC-R acknowledges the operator request
OMC-R
A-TC-DECLARE
TC
GET-SNMP (TC SNMP MIB INTERFACE)
A-TC-DECLARE-ACK
Figure 12 TC Declaration scenario

OMC Use case 5.1.1.20 TC Declaration TC Use case 5.5.1.3 TC Declaration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
56/265
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
Operator requests to remove a TC rack in the OMC-R. 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.
OMC-R
TC
A-TC-REMOVAL
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
Operator requests to display TC data for a specified TC rack. OMC-R reports the TC Data to the operator
OMC-R
TC
A-DISPLAY-TC-DATA A-DISPLAY-TC-DATA-REPORT
Figure 14 Display TC Data scenario

OMC-R Use case 5.1.1.22 Display TC Data
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
57/265
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
Operator requests to update TC information OMC-R (DCN) requests the list of BSC Identifiers.
OMC-R
TC
A-UPDATE-TC-INFORMATION
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
58/265
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

The aim of this O&M action allows changing the BSSIM for the supervision of one TC rack.
Description
Operator requests to move TC supervision to another BSSIM. OMC-R acknowledges the operator request.
OMC-R
TC
A-MOVE-TC-SUPERVISION-TO-ANOTHER-BSSIM A-MOVE-TC-SUPERVISION-TO-ANOTHER-BSSIMACK
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

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
Operator requests to set-up the TC supervision. OMC-R acknowledges the operator request.
OMC-R
TC
A-UPDATE-TC-SUPERVISION A- UPDATE-TC-SUPERVISION -ACK
Figure 17 Update TC supervision scenario

OMC-R Use case 5.1.1.28 Update TC supervision
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
59/265
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 The OMC-R (DCN) operator triggers the TCSL resynchronization.
OMC-R (DCN) requests the list of BSC Identifiers A-TCSL Resynchronisation
OMC
TC (several)
BSC (several)
FOR EACH TC:
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
60/265
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 END FOR
GET-TC-CONFIG (TC SNMP MIB DESCRIPTION)
FOR EACH TC REMOVED: The BSC side TCSL endpoints in TC are cleared.
Set-TCSL-ENDPOINT (BSC side TCSL endpoint) M-SET-TCSL-ENDPOINTRESPONSE
END FOR FOR EACH NEW TC:
END FOR 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
61/265
OMC-R sends a LogicalParam-Modify message with parameter TC-Peer-entities-type to the BSC On the reception of MLogicalParam-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 TCOM SBL, the TC side TCSL endpoint, and associated the BSC side TCSL endpoint.
M-LOGICALPARAM-MODIFY (TC-PEER-ENTITIES-TYPE)
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. OMC-R acknowledges the operator request.
BSC-TC AUDIT scenario (HCM)
A-TCSLResynchronisation-ACK
Figure 18 Resynchronisation triggered with OMC scope scenario

OMC Use case 5.1.1.24 TCSL resynchronisation BSC Use case 5.2.1.10 Modify TC characteristics TC Use case 5.5.1.12 TCSL Endpoint Update (SET)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
62/265
4.1.6.2 BSC-TC Audit Sub-scenario Available for IP Transport feature

The possible triggers are:

o
o 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 From BSC Periodical Audit From TC: The reception of the M-TC-AUDIT-NEEDED message from the TC (sent when applying TC NEM extension/reduction screen).
BSC TC
Description Trigger from OMC-R or TC launches the scenario. 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.
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)
OMC
Trigger from OMC Or from TC
M-TC-AUDIT-REQ (TCSL version, MT120 SW version, code server)
M-TC-AUDIT-REP
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
63/265
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
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 M- TC-CONF-REQ
If A signalling over IP is not already activated, the SS7 Signalling Gateway (SG) endpoint parameter is reported in the TC configuration report message. BSC launches the TC-ALARM-AUDIT to request the actual active alarms for each MT120.
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.
M-TC-CONF-REP
M-TC-ALARM-AUDIT (Network Supervision)
EndIF
End for
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
64/265
The OMC-R is informed of the TC-OM SBL state change. If the BSC or TC SBL configuration has been updated then: The BSC triggers an OMC/BSC HW audit that includes TC ones. 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))
M-SBL-State-ChangeReport (TC-OM SBL)
M-ALARM-REPORT (BSC,HW-RESYNC,EVENT) OMC/BSC synchronisation (HCM BSC, TC & ATER part)
EndIF
Figure 19 BSC-TC Audit sub-scenario

BSC Use case 5.2.1.9 BSC-TC Audit TC Use case 5.5.1.13 TC Audit 5.5.1.14 TC Configuration Update
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
65/265
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 Termin al
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 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)
A-ACTIVATE-CONF-TC
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
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) 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
BSC Terminal
BSC
TC
TC NEM
A-ACTIVATE-CONF-TC (MT120 LIST)
ED 01 RELEASED

0469_1RL.doc
3BK 11204 0469 DSZZA
66/265
Report about the outcome of the operation 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. EndFor For the MT120 associated to BSC in IP mode TC sends the message M-TC-AuditNEEDED to request the BSC-TC Audit. 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. EndFor Activate new MX BSC/TC standard configuration (HCM Ater part)
A-REPORT
EndFor For the MT120 associated to BSC in IP mode

M-TC-AUDIT-NEEDED BSC-TC AUDIT (HCM) 0
EndFor
Figure 21 Activate new G2.5 TC with TCIF standard configuration scenario

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

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
67/265
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 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. For each concerned BSC
M-LogicalParam-Modify Peer-Entities) (MFSA-BSC/GPU Association
OMC
IP
BSC
MFS
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
68/265
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 5.1.1.25 BSC/GPU IP association BSC Use case 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 A-BSS-TRANSPORT-MODEmode switch activation SWITCH (IP Mode) from TDM to IP for the selected BSC
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
69/265
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-BSSTransport-Mode-Switch to BSC to change BSS transport mode from TDM to IP in BSC.
M-BSSTRANSPORTMODE-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-BSSTRANSPORTMODE-SWITCHREPORT
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
70/265
On the sending of the message M-BSSTRANSPORT-MODESWITCH-REPORT to OMC: The BSC then autonomously
resets (BSC reset includes the resynchronization with MSCSee 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-StopReport to OMC. On reception of this message OMC triggers the PM audit and PMs are restored. OMC-R acknowledges the operator request 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. A-BSS-TRANSPORT-MODESWITCH-ACK (IP mode)
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. The BSC triggers the BSCTC AUDIT scenario.
Change BSS Transport Mode, MFS side (OMC/MFS: Ater & Gb Domain [6]) 0
On TC, TDM switching on TCIF is now used for the MT120 of that BSC to allow AterMux pooling.
BSC-TC AUDIT (HCM BSC, TC AND ATER PART) 0
N7ESTABLISHMEN T (TELECOM DOC) 0
Figure 24 Change BSS Transport Mode from TDM to IP on BSC side scenario
OMC Use case 5.1.1.26 BSS Transport Mode Switch BSC Use case 5.2.1.12 BSS Transport Mode Switch
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
71/265
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 A-BSS-TRANSPORT-MODEmode switch activation SWITCH (TDM Mode) from IP to TDM for the selected BSC OMC-R sends the message M-BSSTransport-Mode-Switch to BSC to change BSS transport mode from IP to TDM in BSC.
M-BSSTRANSPORTMODE-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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
72/265
On the sending of the message M-BSSTRANSPORT-MODESWITCH-REPORT to OMC: The BSC then
M-BSSTRANSPORTMODE-SWITCHREPORT
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, BSC sends PM-GlobalStop-Report message to OMC. On reception of this message OMC triggers the PM audit and PMs are restored.
TC and Ater part Ref [A4])
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. OMC-R acknowledges the operator request A-BSS-TRANSPORT-MODESWITCH-ACK
Establishment of BSC/TCQmux 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-N7ESTABLISHMEN T (TELECOM) 0
Figure 25 Change BSS Transport Mode from IP to TDM on BSC side scenario
OMC Use case 5.1.1.26 BSS Transport Mode Switch BSC Use case 5.2.1.12 BSS Transport Mode Switch
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
73/265
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
A_STM1DECLARE (List of STM-1 interface per NE)
TC/BSC
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 STM-1 declaration/undeclaration is allowed) IF the NE type is TC
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
74/265
Operator
OMC-R IF the SET-SNMP-RESP is OK
TC/BSC
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 IF the NE type is BSC IF (the STM-1 declaration is allowed) ENDIF IF the NE type is BSC
M_STM1ACTIVATE (list of STM-1 interface)
IF (the status is NOK) ELSE (the status is OK)
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 STM1TTPs are created or deleted depending on the case.
M_STM1ACTIVATE_ REP (Status, list of added SBL)
OMC-R triggers a BSC audit
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
75/265
Operator
A_STM1DECLARE_REP (Status)
OMC-R ENDFOR
TC/BSC
End of the scenario
Figure 26 STM1 interfaces (BSC/TC) Declaration/Undeclaration scenario

OMC Use case 5.1.1.29 STM1 interfaces (BSC/TC) Declaration/Undeclaration BSC Use case 5.2.1.14 BSC STM1 interface Activation TC Use case 5.5.1.4 TC STM1interface Declaration/Undeclaration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
76/265
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
A_PLUGIDENT ()
TC

GET-SNMP (For TCIF1 plugident1,plugident2,plugident 3,plugident4 ; For TCIF2 plugident1,plugident2,plugident 3,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 5.4.1.7 TC Plug identification information display TC Use case 5.5.1.9 TC Plug identification information
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
77/265
4.1.11.2 BSC Plug identification information display scenario

Operator
BSC Terminal
A_PLUGIDENT ()
BSC

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 5.3.1.12 BSC Plug identification information display BSC Use case 5.2.1.21 BSC Plug identification information
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
78/265
4.1.12 O&M Action Change N7 Mode from LSL to HSL or HSL to LSL
The aim of this O&M action allows to modify the N7 mode. From B10, for MX BSC, N7 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 N7. Change between the two modes is done from BSC local terminal. Depending on the IP/TDM mode of the BSS, the connection of the N7 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
ATERMUX
TC
Interface A
MSC
HSL 1 HSL 2
HSL Connection in IP Mode: In IP mode the MTP2 function is in the TC.

Ater A SM, SMS CC MM DTAP BSSMAP SCCP MTP3
RR BTSM LapD TID UDP IP E1/ethernet

[ML] PPP HDLC
DTAP BSSMAP SCCP MTP3 M2UA SCTP IP ethernet
M2UA SCTP IP MTP2
MTP2
ethernet MTP1 / E1
MTP1 / E1 MSC
MxBSC with TP-GSM->TPIP
TC G2.5 IP (with TCIF)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
79/265
This implies that in IP mode HSL link must be connected from TC to MSC.
BSC
ATERMUX
TC
Interface A
MSC
HSL 1 Ethernet HSL 2
4.1.12.1 Change N7 Mode from LSL to HSL or from HSL to LSL scenario
Description BSC MSC
From BSC local terminal, operator triggers the N7 mode change 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-StopReport message to OMC (See IMO BSC, TC and Ater part Ref [A4]). On reception of
A-CHANGE-N7-MODE
RESET MSC (TELECOM)
this message OMC triggers the PM audit and PMs are restored.
After BSC reset (See IMO BSC, TC and Ater part Ref [A4]), BSC scans the DLS for all transmission SBLs that need to be configured and handles them. BSC acknowledges operator request. It is expected that operator triggers BSC HW audit to line-up OMC/MFS on the new configuration.
A-CHANGE-N7-MODE-ACK
Figure 29: Change N7 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 N7 Mode
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
80/265
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. If A-signalling over IP is requested, OMC checks that A signalling over IP is licensed. OMC sends the message M-LogicalParamModify to BSC 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 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-StopReport 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. After BSC reset, BSC scans the DLS for all transmission SBLs that need to be configured and handles them. OMC acknowledges operator request. It is expected that operator triggers BSC HW audit to line-up OMC/MFS on the new configuration.
A-MODIFY-SS7-TRANSPORT-MODE
M-LOGICALPARAM-MODIFY (No7-NETw-Addr-TYPE)
M-LOGICALPARAM-MODIFYREPORT
RESET MSC (TELECOM)
A-MODIFY-SS7-TRANSPORTMODE-Rep
Figure 30: Modify SS7 Transport Mode scenario

OMC-R Use case 5.1.1.30 Modify BSC SS7 Transport Mode BSC Use case 5.2.1.13 Modify BSC SS7 Transport Mode
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
81/265
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:
Transport Mode Mixed CS/GPRS AterMux TDM traffic signalling SM-ADAPT SBL BSC side (Only for G2 BSC) yes TC side yes TRAU-CP SBL TC side No
IP Dedicated GPRS AterMux TDM IP
CIC + GIC (granularity from 0% to 100%) CIC (granularity to 0% (CS)) GIC only GIC only (granularity to 100%)
None/N7/ GSL/N7+GSL (*) None None//GSL None
no yes no
no no no
yes No no
(*): N7 only for AterMux 1 to 16
And the following figure lists the possible Ater configuration changes:
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
82/265
ou
Not used
(Dedicated 0%)
GPRS Only
(Dedicated 100%)
Pure CS
(Mixed 0%)
Mixed CS/GPRS
(Mixed x% (x>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
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 Scenario: 4.1.1.1Activate new G2 BSC/TC standard configuration scenario Scenario: 4.1.2.1Activate new MX BSC/TC standard configuration scenario Scenario: 4.2.1.1 Modify GPRS granularity Description With this scenario the operator extend or reduce the number of Atermux equipped at TC side. With this scenario the operator extend or reduce the number of Atermux equipped at TC side. 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. 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. 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 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
Scenario: 4.2.1.3 Set-up (respectively unset) of a dedicated GPRS AterMux Scenario: 4.2.1.4 Modify a Mixed AterMux into a dedicated GPRS AterMux Scenario : 4.2.1.2 Modify a dedicated GPRS AterMux into a mixed CS/GPRS AterMux
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
83/265
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:
1. Gb Interface direct to SGSN
BSC
CS/GPRS
MFS
CS/unused
TC
CS/unused
MSC
Gb
SGS
2. Gb Interface through TC
BSC
CS/GPRS
MFS
CS/Gb
TC
CS/Gb
MSC
Gb
SGSN
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
84/265
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].
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
85/265
4.2.1.1 Modify GPRS granularity Scenario

Description
Operator defines a new GPRS/CS granularity (maybe with add or remove GSL only in TDM transport mode) 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 OMC sends the sharing CS(CIC) /GPRS (GIC/GSL)
OMC
A-MODIFY-GPRS-GRANULARITY
BSC
N x Disable ACH (IMO)
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 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
M-ALARM-REPORT (BSC, HW-resynch,Event)
BSC HW audit (HCM)
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 TCTransparency flag was TRUE and being set
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
86/265
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 All Rights Reserved Alcatel-Lucent 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 EndIF ENDIF Operator gets back the answer to his GPRS/CS granularity reconfiguration request
A-MODIFY-GPRS-GRANULARITYREPORT Disable SM-ADAPT[TC] (IMO) Init SM-ADAPT[TC] (IMO)
4 x Disable TC-ADAPT (IMO) 4 x Init TC-ADAPT (IMO)
(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 5.1.1.11 Modify GPRS granularity BSC Use case 5.2.1.4 Modify AterMux GPRS 5.2.1.5 Ater Signalling Configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
87/265
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
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) 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 OMC sends to the BSC that the AterMux is no more dedicated (AterMux-GPRSUsage=mixed-CS-PS) and also 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 M-ALARM-REPORT (BSC, HW-resynch,Event) BSC HW audit (HCM) N x Disable ACH (IMO)
OMC
A-MODIFY-DEDICATED-INTO-MIXEDATerMUX
BSC
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 Else if the BSC is a Mx BSC then The OMC requests the Signalling Atermux configuration 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.
M-CONFIG-SIG-ATERMUX M-CONFIG-SIG-ATERMUX-REPORT
Disable SM-ADAPT[TC] (IMO) Init SM-ADAPT[TC] (IMO)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
88/265
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 Operator gets back the answer to his dedicated to mixed GPRS/CS Ater mux Modification
AMODIFY-DEDICATED-INTOMIXED-ATerMUX-REPORT
4 x Disable TC-ADAPT (IMO) 4 x Init TC-ADAPT (IMO)
(1) alarm, resource and state audits can be performed in parallel with the rest of the scenario. Figure 32: Modify a dedicated GPRS AterMux into a mixed AterMux scenario
OMC-R Use case 5.1.1.13Modify dedicated GPRS AterMux into a mixed CS/GPRS AterMux BSC Use case 5.2.1.4Modify AterMux GPRS 5.2.1.5 Ater Signalling Configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
89/265
4.2.1.3 Set-up (respectively unset) of a dedicated GPRS AterMux Scenario

Description
Operator defines a new Atermux to be set as dedicated to GPRS (respectively remove the GPRS) - with or without a GSL LapD OMC sends to the BSC that the AterMux is dedicated (respectively no more used for GPRS) to GPRS (AterMux-GPRSUsage=dedicated-GPRS)
OMC
A-(UN)SET-DEDICATED-GPRSATERM
BSC
M-LOGICAL-PARAM-MODIFY (GPRS-BSC-Type) M-LOGICAL-PARAM-MODIFY-REPORT M-LOGICAL-PARAM-MODIFY (Cic-Atrk-Type) M-LOGICAL-PARAM-MODIFY-REPORT M-ALARM-REPORT (BSC, HW-resynch,Event) BSC HW audit (HCM)
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)
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 Ater signalling have to be reconfigured EndIF Endif Operator gets back the answer to his request
A-(UN)SET-DEDICATED-GPRSATERM-REPORT
M- CONFIG-SIG-ATERMUX M- CONFIG-SIG-ATERMUX -REPORT
(1) alarm, resource and state audits can be performed in parallel with the rest of the scenario. Figure 33: Set-up (respectively unset) of a dedicated GPRS AterMux scenario
OMC-R Use case 5.1.1.14Set-up (respectively unset) of dedicated GPRS AterMux BSC Use case 5.2.1.4 Modify AterMux GPRS 5.2.1.5 Ater Signalling Configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
90/265
4.2.1.4 Modify a mixed AterMux into a dedicated GPRS AterMux Scenario

Description
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 OMC sends to the BSC that the AterMux is dedicated to GPRS (AterMux-GPRSUsage=dedicated-GPRS)
OMC
A-MODIFY-ATERM-TO-DEDICATEDGPRS-ATERM
BSC
M-LOGICAL-PARAM-MODIFY (GPRS-BSC-Type) M-LOGICAL-PARAM-MODIFY-REPORT M-LOGICAL-PARAM-MODIFY (Cic-Atrk-Type) M-LOGICAL-PARAM-MODIFY-REPORT M-ALARM-REPORT (BSC, HW-resynch,Event)
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)
BSC HW audit (HCM)
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 Else if the BSC is a Mx BSC then IF Mx BSC in TDM Transport Mode The Ater signalling have to be reconfigured Endif EndIF
A-MODIFY-ATERM-TO-DEDICATEDGPRS-ATERM-REPORT Disable SM-ADAPT[BSC] (IMO) Init SM-ADAPT[BSC] (IMO)
M- CONFIG-SIG-ATERMUX M- CONFIG- SIG-ATERMUX-REPORT
Operator gets back the answer to his request
(1) alarm, resource and state audits can be performed in parallel with the rest of the scenario. Figure 34: Modify a mixed AterMux into a dedicated GPRS AterMux scenario
OMC-R Use case 5.1.1.15 Modify mixed AterMux to dedicated GPRS AterMux BSC Use case 5.2.1.4 Modify AterMux GPRS 5.2.1.5 Ater Signalling Configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
91/265
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.
D ES C R IPT IO N T he operator m odifies the A ter connection ty pe
O M C -R A -M O DIF Y -A T E R -CO N N E C TIO N -T Y PE
BSC
T he O M C sends to the B S C the new A ter connection type
M -C O N FIG -A T E R (connectionT ype) A -C O N FIG -A T E R -RE P O RT A -M O DIF Y -A T E R -CO N N E C TIO N -T Y PE -R E PO R T P R O G -T R A N S -A T E R (H C M ) A -B S C -R E ST A R T
T he operator gets back the answer to its request T he O M C-R triggers configuration of transm ission for Ater
T he operator triggers a B S C R estart
B S C R estart (IM O )
Figure 35: Modify Ater connection type scenario

OMC-R Use case 5.1.1.16 Modify Ater connection type BSC Use case 5.2.1.6 Configure Ater 5.2.1.7 Program Ater Transmission
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
92/265
4.2.2.2 Change CRC4 Scenario The aim of this scenario is to change CRC4 parameter value to be applied to A interface.
DESCRIPTION Operator changes CRC4 on/off OMC-R sends the command to the BSC The BSC set all TC-ADAPT (for G2 TC) and SM-ADAPT SBLs to FOS and generates an alarm (local-reinitialisation-required) for each of them. BSC acknowledges the OMC-R request OMC-R acknowledges the operator request A-CHANGE-CRC4-REPORT PROG-TRANS-ATER (HCM) A-CHANGE-CRC4 M-CONFIG-ATER (CRC4) M-ALARM-REPORT(LocalReinitRequired) M-ALARM-REPORT(LocalReinitRequired) OMC-R BSC
M-CONFIG-ATER-REPORT
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 5.1.1.17 Change CRC4 BSC Use case 5.2.1.6 Configure Ater 5.2.1.7 Program Ater Transmission
Figure 36: Change CRC4 scenario
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
93/265
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.
DESCRIPTION Operator changes half-rate on/off OMC-R sends the command to the BSC BSC acknowledges the OMC-R request OMC-R acknowledges the operator request A-CHANGE-HALF-RATE-REPORT PROG-TRANS-ATER (HCM) A-CHANGE-HALF-RATE M-CONFIG-ATER (HR-presence) OMC-R BSC
Figure 37: Change Half-rate scenario

OMC-R Use case 5.1.1.18 Change Half-rate BSC Use case 5.2.1.6 Configure Ater 5.2.1.7 Program Ater Transmission
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
94/265
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.
DESCRIPTION Operator changes loudness value OMC-R sends the command to the BSC BSC acknowledges the OMC-R request OMC-R acknowledges the operator request A-CHANGE-LOUDNESS-REPORT PROG-TRANS-ATER (HCM) A-CHANGE-LOUDNESS M-CONFIG-ATER (TRAU-loudness-UL/DL) OMC-R BSC
Figure 38: Loudness setting scenario

OMC-R Use case 5.1.1.19 Change loudness BSC Use case 5.2.1.6 Configure Ater 5.2.1.7 Program Ater Transmission
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
95/265
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
A_GETCONF (Current)
TC
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
96/265
Operator
TC NEM 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
TC
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 5.4.1.1 Getting current or candidate TC STM1 configuration TC Use case 5.5.1.5 Getting current or candidate TC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
97/265
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
A_GETCONF (candidate)
TC
GET-SNMP (Candidate)
The TC retrieves candidate configuration data and its properties (name and date) from TC SNMP MIB.
GET-SNMP_REP (Status, 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
Else if the file must be overwritten or
3BK 11204 0469 DSZZA
98/265
Operator
TC NEM 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
TC
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 5.4.1.1 Getting current or candidate TC STM1 configuration TC Use case 5.5.1.5 Getting current or candidate TC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
99/265
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: o The name of the candidate STM1 configuration file downloaded o The date of the downloading of the candidate STM-1 configuration file 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
A_GETCONFPROPERTIES (Current or candidate)
TC

GET-SNMP (Current name and current date or Candidate name and Candidate date)

A_GETCONFPROPERTIES_ REP (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.
GET-SNMP_REP (Status, current properties (name and date) or candidate properties (name and 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 5.4.1.2 Getting properties for current or candidate TC STM1 configuration TC Use case 5.5.1.5 Getting properties for current or candidate TC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
100/265
4.2.3.4 Checking a TC STM1 configuration scenario

Operator TC NEM
A_CHECKCONF (Directory, Name)
TC
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
A_COMPCONF (Directory1, Name1, Directory2, Name2)
TC
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
101/265
4.2.3.6 Downloading a candidate TC STM1 configuration scenario

Operator
TC NEM
A_SETCONF (Directory, Name)
TC
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)
If the SET SNMP is successful, the TC-NEM stores the configuration file in the candidate subdirectory under the name: <name>_<date>
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)
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 5.4.1.5 Downloading a candidate TC STM1 configuration TC Use case 5.5.1.7 Downloading a candidate TC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
102/265
4.2.3.7 Applying a candidate TC STM1 configuaration file scenario

Operator
TC NEM
A_APPLYCONF ()
TC
OMC-R
SETSNMP_(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
A_APPLYCONF_RE P (Status)
SET-SMP-REP (Status)
End of the scenario
Figure 45: Apply a candidate TC STM1 configuration scenario

TC-NEM Use case 5.4.1.6 Applying a candidate TC STM1 configuration TC Use case 5.5.1.8 Applying a candidate TC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
103/265
4.2.3.8 Display of TCs 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
A_GETSECTPATHTRACE (STM1-TTP Nb)
TC
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 5.4.1.7 Display of TCs section and path traces TC Use case 5.5.1.9 Display of TCs section and path traces
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
104/265
4.2.3.9 Modification of TCs 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
A_SETSECTPATHTRACE( STM1TTP Nb)
TC

GET-SNMP (STM1-TTP Nb)
TC NEM retrieves the current section and path traces values for the requested STM1-TTP from the TC
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)
Display the section or/and path traces (J1 or/and J2) updated
A_ SETSECTPATHTRACE_REP (section or/and path traces (J1 or/and J2) updated)
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)
End of the scenario
Figure 47: Modification of transmitted section and path traces scenario
ED 01 RELEASED
TC-NEM Use case

04/06/2008 0469_1RL.doc
TC Use case
3BK 11204 0469 DSZZA
105/265
5.4.1.8 Modification of TCs transmitted section and path traces
5.5.1.10 Modification of TCs transmitted section and path traces
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
106/265
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
A_GETCONF (Current or candidate)
BSC

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 5.3.1.1 Getting current or candidate BSC STM1 configuration BSC Use case 5.2.1.15 Getting current or candidate BSC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
107/265
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.
A_GETCONF_prop (Current or candidate)
BSC

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 5.3.1.2 Getting current or candidate BSC STM1 configuration properties BSC Use case 5.2.1.16 Getting current or candidate BSC STM1 configuration properties
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
108/265
4.2.4.3 Editing a BSC STM1 configuration scenario

A_EDITCONF (File Name)
BSC
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

A_CREATCONF (File Name)
BSC
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
109/265
4.2.4.5 Checking a BSC STM1 configuration scenario

Operator
TC NEM
A_CHECKCONF (Name)
TC
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
A_COMPCONF (Name1, Name2)
TC
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
110/265
4.2.4.7 Setting a candidate BSC STM1 configuration scenario

This action allows setting a candidate BSC STM1 configuration.

A_SETCONF (Name)
BSC
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 5.3.1.7 Setting a candidate BSC STM1 configuration BSC Use case 5.2.1.17 Setting a candidate BSC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
111/265
4.2.4.8 Applying a candidate BSC STM1 configuration scenario

This action allows applying a BSC STM1 candidate configuration.

A_APPLYCONF ()
BSC
OMC-R
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

A_APPLYCONF_RE P (Status) M_APPLYCONF_REP (Status)
M_ALARM_REPORT (BSC, HW_resynch, Event)
OMC-R invokes automatically BSC hardware audit scenario
End of the scenario
Figure 55: Applying a candidate BSC STM1 configuration scenario

BSC Terminal Use case 5.3.1.8 Applying a candidate BSC STM1 configuration BSC Use case 5.2.1.18 Applying a candidate BSC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
112/265
4.2.4.9 Get BSCs 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 BSCs LIU/STM1 resources is to provide to the operator the complementary view. Indeed, for each LIU port and STM1 VC12, the corresponding Abis/Ater-HWAYTP mapped on it is given. If there is no, the LIU or STM1 VC12 is explicitly reported free.
A_GETRESOURCES ()
BSC
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 5.3.1.9 Get BSCs LIU/STM1 resources BSC Use case 5.2.1.15 Getting current or candidate BSC STM1 configuration
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
113/265
4.2.4.10 Display of BSCs 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.
A_GETTRAC (STM1-TTP Nb)
BSC
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 BSCs section and path traces scenario

BSC Terminal Use case 5.3.1.10 Display of BSCs section and path traces BSC Use case 5.2.1.19 Display of BSCs section and path traces
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
114/265
4.2.4.11 Modification of BSCs 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.
A_SETSECTPATHTRACE( STM1TTP Nb)
BSC

M_GETSECPATHTRACE (STM1TTP Nb)
BSC terminal retrieves the current section and path traces values for the requested STM1-TTP from the BSC
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 (STM1TTP, Nb, New values)
A_ SETSECTPATHTRACE_REP (result)
The BSC updates the section (J0) and path traces (J1 and J2) for the requested STM1-TTP.
M_SETSECPATHTRACE_REP (Result)
End of the scenario
Figure 58: Modification of BSCs transmitted section and path traces scenario
BSC Terminal Use case 5.3.1.11 Modification of BSCs transmitted section and path traces BSC Use case 5.2.1.20 Modification of BSCs transmitted section and path traces
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
115/265
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-R solicits the programming of the transmissions 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 ATERHWAY-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. ENDIF End For
OMC
BSC
TC
M-PROG-TRANS-ATER
Qmux exchange
For MX BSC in IP transport mode IF TC equipment are flagged BSC programs TC equipment in using BSC-TC Audit scenario. End For BSC acknowledges the programming of transmission
M-PROG-TRANS-ATER-REPORT
BSC-TC Audit (HCM BSC, TC and Ater part)
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
116/265
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 BSS name Host identifier BSS release BSC node identifier IPaddress Primary X25 address Secondary X25 address OMC-BSS Synchronization
(*) 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:
Purpose Identifier of the BSS Identifier of the OMC host server Release of the BSS (*) IP address for Mx BSC X25 address for G2 BSC X25 address for G2 BSC If true, the OMC will autonomously lauch a BSC discover at the end of the scenario
Optional/Mandatory Mandatory Mandatory
Default value
Mandatory Optional Optional Optional Optional Optional
ED 01 RELEASED
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
117/265
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 BSS name
Purpose Identifier of the BSS
Optional/Mandatory Mandatory
Default value
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
118/265
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 BSS name New BSS name New BSC node identifier
Purpose Identifier of the BSS New identifier of the BSS New BSC node identifier
Optional/Mandatory Mandatory Optional Optional
Default value
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
119/265
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
Purpose
Identifier of the BSS
Optional/ Mandatory Mandatory
Default value
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
120/265
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:
OPERATOR INPUTS
Purpose
Default value
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
121/265
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 semipermanent 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
122/265
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:
Purpose
OPERATOR INPUTS
Default value
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:
OPERATOR INPUTS
Parameter name HW-SW Overall Type
Purpose
The BSC parameter group HW-SW overall type
Default value
Outputs: A report about the outcome of the operation.

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
123/265
Description: The OMC sends the M_LogicalParam_Display message with parameter HW/SW_overall_Type to the BSC to request the HW-SW overall parameters. group
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:
Parameter name Composed equipment Rack number
Purpose
OPERATOR INPUTS
Identifier of the composed equipment: BSC, TC, BTS name Identifier of the rack
Optional/ Mandatory Mandatory Optional
Default value
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:
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
124/265
Parameter name
Purpose
OPERATOR INPUTS
BSS name
Default value
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
125/265
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:
OPERATOR INPUTS
Purpose
Default value
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
126/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
127/265
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: OPERATOR INPUTS
Parameter name BSS name AterMux number GPRS granularity
Purpose
GSL LapD presence
Identifier of the BSS Identifier of the BSC AterMux 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. Only available in TDM mode: Indicate if a GSL LapD has to be set-up on the second tributary of the AterMux
Optional/ Mandatory Mandatory Mandatory Mandatory
Default value
Optional
In TDM mode: When the parameter is not present, the previous choice (last granularity modification) is not changed - TC Transparency==TRUE
10
Only available in TDM mode: Optional Flag indicating if the AterMux transmission at TC site shall support routing of Gb (*) 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". TC Transparency (*)
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
ED 01 RELEASED
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
128/265
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 : GICGroup-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 equipments: For G2 BSC when the SBL GSL has been either created or deleted by the BSC the OMCR 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
129/265
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 MLOGICALPARAM-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 TCADAPT 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 OMCR 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:
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
130/265
Parameter name
Purpose
OPERATOR INPUTS
BSS name AterMux number GPRS granularity GSL LapD presence
Identifier of the BSS Identifier of the BSC AterMux Percentage of GPRS within the AterMux (0%, 12,5%, 25%, 50%, 75% or 100%) Indicate if a GSL LapD has to be set-up on the second tributary of the AterMux
Optional/ Mandatory Mandatory Mandatory Mandatory Optional
Default value
Flag indicating if the AterMux Optional transmission at TC site shall support routing of Gb. (*) 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". TC Transparency (*)
When the parameter is not present, the previous choice (what was existing for the dedicated GPRS AterMux) is not changed - TC Transparency==TRUE
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 MSCBSC 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
131/265
Then, the OMC-R has to configure the transmission equipments: 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 MLOGICALPARAM-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 TCADAPT 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
132/265
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: OPERATOR INPUTS
Parameter name BSS name AterMux number Dedicated flag
Purpose
GSL LapD presence
Identifier of the BSS Identifier of the BSC AterMux Indicates that the corresponding AterMux is going to be dedicated for GPRS (respectively cleared from GPRS) Only available in TDM transport mode Indicate if a GSL LapD has to be set-up on the second tributary of the AterMux
Default value
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-AtrkHardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
ED 01 RELEASED
3BK 11204 0469 DSZZA
133/265
Else
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.
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-CSs 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-AtrkType 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, GICGroup-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-AtrkType 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
134/265
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 MLOGICALPARAM-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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
135/265
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: OPERATOR INPUTS
Parameter name BSS name AterMux number Dedicated flag GSL LapD presence
Purpose
Identifier of the BSS Identifier of the BSC AterMux Indicates that the corresponding AterMux is going to be dedicated for GPRS Only available in TDM Mode Indicate if a GSL LapD has to be set-up on the second tributary of AterMux
Optional/ Mandatory Mandatory Mandatory Mandatory Optional
Default value
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
136/265
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, GICGroup-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 MLOGICALPARAM-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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
137/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
138/265
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: OPERATOR INPUTS
Parameter name BSS name Connection type
Purpose
Identifier of the BSS Indicates the new connection type, either terrestrial or via satellite
Optional/ Mandatory Mandatory Optional
Default value 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 operators 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
139/265
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 BSS name Crc4
Purpose Identifier of the BSS On/Off
Default value
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;
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
140/265
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 BSS name HR-presence
Purpose Identifier of the BSS On/Off
Default value
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;
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
141/265
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 BSS name TRAU-Loudness-UL TRAU-Loudness-DL
Purpose Identifier of the BSS -6 db to 6 db -6 db to 6 db
Optional/Mandatory Optional Optional Optional
Default value 0 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;
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
142/265
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:
OPERATOR INPUTS
Parameter name
Purpose
IP Address of the TC rack TC IP address Mandatory Identifier of the TC rack Optional TC Rack Name (*) (*) 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.
Optional/ Mandatory
Default value
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
143/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
144/265
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:
OPERATOR INPUTS
Parameter name
Optional/ Default value Mandatory IP Address of the TC rack Mandatory TC IP address Identifier of the TC Optional TC Rack Name (*) (*) 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.
Purpose
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 o All the information about the TC rack is removed. 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
145/265
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:
OPERATOR INPUTS
Parameter name TC IP address
Purpose
IP Address of the TC rack (identifier of the TC rack)
Optional/ Mandatory
Default value
Mandatory
Outputs:
OPERATOR OUTPUTS
Parameter name Supervising BSC number List of related BSC TC side endpoints per BSC BSC side endpoints per BSC
Purpose
Identifier of the supervising BSC Only present if supervising BSC is defined. Identifier of all BSC known by the concerned TC rack TC side TCSL endpoints per BSC BSC side TCSL endpoints per BSC
Optional/ Mandatory
Default value
Optional
Mandatory Mandatory 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
146/265
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:
OPERATOR INPUTS
Parameter name TC IP address
Purpose
IP Address of the TC rack (identifier of the TC rack)
Optional/ Mandatory
Default value
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
147/265
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 OMCR 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:
OPERATOR INPUTS
Parameter name TC list BSC List
Purpose
List of TCs List of BSC (BSC must be MX BSC, at least in maintenance release supporting IP)
Optional/ Mandatory Optional Optional
Default value
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
148/265
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. o Setting the BSC side TCSL endpoint in TC in sending a SNMP set. 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
149/265
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:
OPERATOR INPUTS
Parameter name GPU Id BSC Id
Purpose
Identity of the GPU Identity of the BSC
Optional/ Mandatory Mandatory Mandatory
Default value
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
150/265
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 OMCR 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
BSS Transport Mode
Parameter name
Identifier of the requested BSS transport mode: IP Mode or TDM Mode
Purpose
Mandatory
Optional/ Mandatory
Default value
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
151/265
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-OverallType 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.)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
152/265
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:
OPERATOR INPUTS
Parameter name Target BSSIM number
Purpose
Identifier of the target supervising BSSIM for the considered TC rack
Default value
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
153/265
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:
OPERATOR INPUTS
Parameter name
Purpose
Optional/ Mandatory
Default value
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
154/265
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:
OPERATOR INPUTS
Parameter name STM1 Interface List per NE
Purpose
List of STM1 interfaces wanted by the operator for each concerned NE (BSC/TC)
Default value
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 NEs 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-LimitedFeatures 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
155/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
156/265
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:
OPERATOR INPUTS
Parameter name A-SIGNALLING-OVER-IP
Purpose
The flag for the feature A signalling over IP. The values are: Enabled Disabled
Default value
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-NetwAddr-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
157/265

If the A signalling over IP is requested and not licensed. If the A signalling over IP is requested and not compatible.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
158/265
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
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. 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. 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 Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
Parameter
Remote Inventory
STM1
ED 01 RELEASED
3BK 11204 0469 DSZZA
159/265
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
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.
Parameter
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
160/265
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-LimitedFeatures is changeable by OMC operator. For Hardware Configuration Management, the controlled features are:
DR TRE
Feature
Twin TxDiv BTS with more than 12 RSL
STM1 in TC STM1 in BSC
Operator can configure some TRE as DR for a certain BTS/sector, thus allowing the support of more traffic channels. Operator can configure Twin module either as two TRE, or with a TRE working in TxDiv [Transmission Diversity] mode. 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). 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). Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
Parameter
ED 01 RELEASED
3BK 11204 0469 DSZZA
161/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
162/265
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
Activate new (Extension) BSC standard configuration
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
SBL State
Activate new TC standard configuration (Extension)
BSC Hardware Audit TC Hardware Audit Modify AterMux GPRS
Ater Signalling Configuration Configure Ater Program Ater Transmission Change N7 mode from LSL to HSL or from HSL to LSL
ED 01 RELEASED

04/06/2008 0469_1RL.doc
TC-Adapt, TC16 IT (****) SM-Adapt (TC-side) IT (***) ATER-HWAY-TP (TC-side) OPR A-PCM-TP OPR N/A N/A N7s OPR TC-Adapt, TC16 IT (****) SM-Adapt (TC-side) IT (***) ATER-HWAY-TP (TC-side) OPR A-PCM-TP OPR N/A N/A N/A New N7 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
3BK 11204 0469 DSZZA
163/265
BSC-TC Audit
TC16 IT 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 For BSC in IP Mode, if a TCSL is added in BSC TCSL IT TC-OM IT For BSC in IP mode IP-GSL Instantiated (IT) 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 For each interface to be activated STM1-ITF OPR 2 associated STM1-TTPs OPR N/A N/A N/A N/A N/A N/A N/A
Modify TC Characteristics Modify MFS Characteristics BSS Transport Mode Switch
Modify BSC SS7 Transport Mode STM1 Activation Getting current or candidate BSC STM1 Configuration Getting current or candidate BSC STM1 Configuration properties Setting a candidate BSC STM1 configuration Applying a candidate BSC STM1 configuration Display of section and path traces Modification of transmitted section and path traces BSC plug identification information
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
164/265
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 Parameter name
BSC Target configuration TC Target configuration WTC Period
Purpose
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).). 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) Wait for traffic clear period
Optional/ Mandatory
Optional Optional Mandatory in case of BSC reduction
Default value
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
165/265
For BSC extension:
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-ALARMREPORT(BSC,HW_Resynch,Event)) to the OMC-R.
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 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-ALARMREPORT(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 ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
166/265
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 EquipmentIdentity-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-Identityreport 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
167/265
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).
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
168/265
AterMux 1 AterMux 2
BSC (Config2
AterMux 3 AterMux 4 AterMux 5
MFS
TC
Notes : 1- The difference within the BSC DB between AterMux n3 and the potential AterMux n6 is the Ach-GPRS-CS parameter values of its corresponding Aters (for AterMux n3 the Ach-GPRS-CS bitmaps 0000h). So, when an AterMux is unequipped (TC reduction from BSC terminal) its corresponding Ach_GPRS-CS bitmaps shall be set to 0000h). 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 0000h) 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:

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
169/265

The configuration is changed from 5,4 or 3 to 2 or 1 and BTS are connected to AbisHway-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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
170/265
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
Purpose Identifier of the BTS Identifier of the parameter group. Optional/Mandatory Mandatory Mandatory
Parameter name BTS number Parameter group
Parameter name Configuration area
Message M-CONFIG-DISPLAY{XE "M-CONFIG-DISPLAY"} FROM THE OMC-R

Purpose Type of the configuration display desired (BSC / TC / ABIS LINKS for this use case) Optional/Mandatory Mandatory
Parameter name File identifier
Message M-FILE-READ{XE "M-FILE-READ"} FROM THE OMC-R

Purpose Identifier of the file which the OMC-R has successfully read
Outputs:
Message M-LOGICALPARM-DISPLAY-REPORT{XE "M-LOGICALPARM-DISPLAY-REPORT"} TO THE OMC-R
BTS Purpose Content of the parameter group Optional/Mandatory Optional Mandatory
Parameter name Usage of the characteristics Status
Status about the outcome of the operation
Parameter name File identifier File size Status
Message M-CONFIG-DISPLAY-REPORT{XE "M-CONFIG-DISPLAY-REPORT"} TO THE OMC-R

Purpose Identifier of the file including audit data for transfer size of the file Status about the outcome of the operation Optional/Mandatory Optional
Optional Mandatory
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
171/265
Parameter name Status
Message M-FILE-READ-REPORT{XE "M-FILE-READ-REPORT"} TO THE OMC-R

Purpose Status about the outcome of the operation Optional/Mandatory 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 transfers completion is indicated to the BSC with the M-FILE-READ message from the OMC-R, then the BSC deletes audit file and acknowledges transfers 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
172/265
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
Purpose Type of the configuration desired (TC for this use case) display Optional/Mandatory Mandatory
Parameter name Configuration area
Parameter name File identifier
Message M-FILE-READ{XE "M-FILE-READ"} FROM THE OMC-R

Purpose Identifier of the file which the OMC-R has successfully read
Outputs:
Message M-CONFIG-DISPLAY-REPORT{XE "M-CONFIG-DISPLAY-REPORT"} TO THE OMC-R
Purpose Identifier of the file including audit data for transfer size of the file Status about the outcome of the operation Optional/Mandatory Optional
Parameter name File identifier File size Status
Optional Mandatory
Message M-FILE-READ-REPORT{XE "M-FILE-READ-REPORT"} TO THE OMC-R

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
173/265
identifier to the OMC-R for FTAM transfer (in case of G2 BSC) or FTP transfer (in case of Mx BSC).
The transfers completion is indicated to the BSC with the M-FILE-READ message from the OMC-R, then the BSC deletes audit file and acknowledges transfers completion. Exceptions: None.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
174/265
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:
Parameter name
M-LOGICALPARAM-MODIFY(GPRS-BSC-Type group) FROM THE OMCR

Purpose Identifier of the BSC AterMux In TDM mode Precise if the AterMux is dedicated 12 or mixed GPRS/CS In IP mode The AterMux is only dedicated Only available in TDM mode Flag indicating if the AterMux transmission at TC site shall be configured or not. Optional/ Mandatory Mandatory Mandatory Default value
AterHwayTP number AterMuxGPRSUsage
TC Transparency
Optional
Note : Not needed (not significant) for a dedicated GPRS AterMux. - TC Transparency ==TRUE
Parameter name (repeated for

all Ater PCM of the corresponding AterMux)
M-LOGICALPARAM-MODIFY(CIC-Atrk-Type group) FROM THE OMCR

Purpose Optional/ Mandatory Mandatory Mandatory Optional
Default value
AtrunkId
AtrkSblNbr GicCodeAtrk
With Atrksblnbr, it identifies the Ater PCM With Atrunkid, it identifies the Ater PCM GPRS identity code of channel 0
AchGprsCs
GslOnAtrk(*)
(*) This parameter is no more supported from B8 release and could be removed but it is kept to avoid a MIB modification.
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) Flag indicating if a GSL LapD has to be set-up on the Ater PCM (TS28 for 4:1 mapping)
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) none
Optional
none
12
ED 01 RELEASED
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
175/265
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 APCM-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 TCs 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 :
When the OMC will change the networkopmode parameter, even though, both parameter groups will be provided by the OMC 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.
14 13
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
176/265

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 didnt 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-BSCType 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-PARAMMODIFY-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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
177/265
Exceptions: None.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
178/265
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
Purpose Identifier of the BSC AterMux Optional/ Mandatory Mandatory
Parameter name AterHwayTP number
Default value
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 CicAtrk-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).
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
179/265
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
Purpose Change the Ater connection type Set to on => the CRC4 is triggered Set to off => the CRC4 is stopped 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) Change the amplification level on up link Change the amplification level on down link Optional/ Mandatory Optional Optional Optional
Parameter name
Default value
Connection type Crc4 HR-presence
TRAU-loudness-UL TRAU-loudness-DL
Optional 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 Change Ater connection type Change CRC4 Half-rate setting Loudness setting Outputs:
Connection type Crc4 HR-presence TRAU-loudness-UL TRAU-loudness-DL
Parameters sent
Message M-CONFIG-ATER-REPORT{ XE "M-CONFIG-ATER-REPORT" } TO THE OMC-R

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. ED 01 RELEASED Hardware Configuration Management BSC, TC and ATER part B11
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
180/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
181/265
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
Purpose Optional/Mandatory
Parameter name
Outputs:
Message M-PROG-TRANS-ATER-REPORT{ XE "M-PROG-TRANS-ATER-REPORT" } TO THE OMC-R
Purpose Number of Nes successfully configured Number of Nes with access failure Number of Nes with download failure Optional/Mandatory Mandatory Mandatory Mandatory
Parameter name nbrsuccess nbraccessfail nbrdownloadfail
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
182/265
5.2.1.8 Use Case Change N7 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-N7-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 BSSTEL lock command with a WTC before changing N7 Mode from LSL to HSL (but this is not checked). Post Conditions: The BSC database is configured with the new type of N7. 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_N7 MODE FROM BSC terminal
Specify the target N7 mode: HSL or LSL. When going to HSL, specifies the first Atermux to be used (See Remark 2) When going to HSL, specifies the second Atermux to be used (See Remark 2) Selection of the format for the signal units frames. Two possible values: With extended sequence number format (extended MTP-Sequence-NumberFormat) Without extended sequence number format (Normal MTPSequence-Number-Format)
Target N7 mode First Atermux Second Atermux
Parameter name
Purpose
Mandatory
Optional/Mandatory
MTP-Sequence-NumberFormat (See Remark 1)
Optional, Must be present when activating HSL Optional, Must be present when activating HSL 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_N7 MODE_REPORT TO BSC terminal

Status about the outcome of the operation with precise identification of the reason of the failure, if unsuccessful (see exception cases)
Status
Parameter name
Purpose
Mandatory
Optional/Mandatory
Description:
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
183/265
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: - N7 SBL, - Atr SBLs - A channel configuration. The impacted TC SBLs are marked for reconfiguration as To be reconfigured. N7 SBL For HSL, there are always two N7 SBL. In TDM, these N7 are conveyed on Atermux X (SBL N7 n1), and Atermux Y (SBL N7 n2). In IP, these N7 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 N7 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 N7 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 N7 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
184/265
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 N7 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 N7 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 SBLs 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 N7 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
185/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
186/265
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 TCOM 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
Purpose
Parameter name
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
187/265
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
188/265
o o o
3. The legacy TC parameters In case of A signaling over IP, BSC doesnt give the MTP2 parameters in the message sent to TC. 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. BSC evaluates CS-ATERMUX and ATR resources. 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]) 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. The TC-OM SBL state is put to IT in the BSC and the BSC informs the OMCR from this change. 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.
o o 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
189/265
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
Purpose TC-peer-entities-Type Optional/Mandatory Mandatory
Parameter name TC-peer-entities-type
Outputs:
Message M-LOGICALPARM-MODIFY-REPORT{XE "M-LOGICALPARM-MODIFY-REPORT"} TO THE OMC-R
Purpose Status about the outcome of the operation with precise identification of the reason of the failure, if unsuccessful (see exception cases) Optional/Mandatory 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
190/265
5.2.1.11 Use Case Modify MFS Characteristics

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
Purpose Identifier of MFS-peer-entities Optional/Mandatory Mandatory
Parameter name MFS-peer-entities-Type
Outputs:
Message M-LOGICALPARM-MODIFY-REPORT{XE "M-LOGICALPARM-MODIFY-REPORT"} TO THE OMC-R
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
191/265
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 (HardwareBTS-Type group)" } FROM THE OMC-R
Purpose Identifier of the transport mode: or requested IP Mode TDM Mode BSS Optional/Mandatory Mandatory
Parameter name BSS Transport Mode
Outputs:
Message M- BSS-TRANSPORT-MODE-SWITCH{ XE "M-LOGICALPARM-MODIFY (HardwareBTS-Type group)" }-REPORT{XE "M-LOGICALPARM-MODIFY-REPORT"} TO THE OMC-R
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,
ED 01 RELEASED
04/06/2008

0469_1RL.doc
3BK 11204 0469 DSZZA
192/265
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 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. Signalling GSL related changes are: IP GSL SBL are instantiated. TDM GSL SBL are removed. 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)]. Signalling GSL related changes are: IP GSL SBL are removed instantiated. TDM GSL SBL are instantiated back from DLS when compatible with Atermux configuration. 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
193/265
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-StopReport 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
194/265
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 No7Netw-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
Purpose
Parameter name No7-Netw-Addr-Type
The parameter group No7-NetwAddr-Type
Outputs:
Message M- LOGICALPARAM-MODIFY-REPORT{XE "M-LOGICALPARM-MODIFY-REPORT"} TO THE OMC-R
Description: At the reception of the message M-LogicalParam-Modify with the parameter group No7Netw-Addr-Type, When the included parameters A-signalling-over-IP and A-flex are both disabled, the rollback 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
195/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
196/265
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 List of STM1 Interface
Purpose List of STM1 interface
Outputs: Message M-STM1-ACTIVATE-REPORT

Purpose Status about the outcome of the operation with precise identification of the reason of the failure, if unsuccessful (see exception cases) List of the SBLs created ie the STM1ITF SBL and the 2 associated STM1TTPs SBLs created
List of added SBLs
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
197/265
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: The BSC is an Mx Generation Post Conditions: None Inputs: Message M-GETCONF FROM THE BSC Terminal
Purpose Current STM1 configuration Or Candidate STM1 configuration
Parameter name STM1 configuration type
Outputs: Message M-GETCONF-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal

Purpose Status about the outcome of the operation with precise identification of the reason of the failure, if unsuccessful (see exception cases) Current or candidate transmission termination configuration data Properties of the current configuration Or Properties of the candidate configuration Optional/Mandatory Mandatory
Configuration data Properties of the requested STM1 configuration type
Mandatory 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
198/265
Exceptions:
The BSC reports that no candidate configuration is available, If the candidate configuration is requested and if it is dummy in the DLS.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
199/265
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: The BSC is an Mx Generation Post Conditions: None Inputs: Message M-GETCONF-PROP FROM THE BSC Terminal
Purpose Current properties Or Candidate properties
Parameter name Properties Type
Outputs: Message M-GETCONF-PROP-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal

Purpose Status about the outcome of the operation with precise identification of the reason of the failure, if unsuccessful (see exception cases) Properties of the current BSC STM1 configuration Or Properties of the candidate BSC STM1 configuration Optional/Mandatory Mandatory
Requested Data Properties
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
200/265
The BSC reports that no candidate configuration is available, If the candidate configuration is requested and if it is dummy in the DLS.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
201/265
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: The BSC is an Mx Generation Post Conditions: None Inputs: Message M-SETCONF FROM THE BSC Terminal
Purpose Candidate data are requested The name of the configuration file used as candidate
Parameter name Candidate Data Name
Outputs: Message M-SETCONF-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal

Purpose Status about the outcome of the operation BSC current date at the time of the setting Optional/Mandatory Mandatory Mandatory
Parameter name Status Date
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
202/265
Remark: The Transmission Termination configuration data are NOT reported through this use case.
Exceptions: None.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
203/265
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
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
204/265
Exceptions: If the BSC STM1 configuration file check is not successful If checks performed by BSC are not successful.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
205/265
5.2.1.19 Use Case Display of BSCs 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: The BSC is an Mx Generation Post Conditions: None Inputs: Message M-GETTRAC FROM THE BSC Terminal
Purpose The requested STM1-TTP number
Parameter name STM1-TTP number
Outputs: Message M-SETCONF-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal

Purpose The section (J0) and path traces (J1 and J2) available for the requested STM1-TTP number Optional/Mandatory Mandatory
Parameter name Result
Description: At the reception of the message M-GETTRAC, the TPGSM carrying the requested STM1TTP 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
206/265
5.2.1.20 Use Case Modification of BSCs 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: The BSC is an Mx Generation Post Conditions: None Inputs: Message M-GETSECPATHTRACE FROM THE BSC Terminal
Purpose The requested STM1-TTP number
Parameter name STM1-TTP number
Parameter name STM1-TTP number New Values
Message M-SETSECPATHTRACE FROM THE BSC Terminal

Purpose The requested STM1-TTP number Possible new values are: The section trace value (J0) The high path trace value (J1) One or several low path trace (J2)
Outputs: Message M-GETSECPATHTRACE-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal

Message M-SETSECPATHTRACE-REP{ XE "M-CONFIG-ATER-REPORT" } TO THE BSC Terminal

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 STM1TTP retrieves the section and path traces available: The transmitted section trace (J0) (according to the section trace type: 1 byte or 16 bytes framed)
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
207/265

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: The transmitted section trace (J0) (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) 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
208/265
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
Purpose For each SFP reported by BSC: Plug identification contained in the EEPROM Optional/Mandatory Mandatory
Parameter name List of Plug Identification
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 offthe-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)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
209/265
5.2.2
Dimensioning Data
Not relevant. 5.2.3 Object Model
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
210/265
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 Parameter name
STM1 configuration type
Purpose
Current STM1 configuration or Candidate STM1 configuration
Optional/ Mandatory
Mandatory
Default value
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
211/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
212/265
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:
Purpose
Optional/ Mandatory
Mandatory
Default value
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. Exceptions: An error message is displayed to operator: 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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
213/265
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
Purpose
The name of the configuration file to edit
BSC
STM1
Optional/ Mandatory
Mandatory
Default value
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
214/265
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. Pre Conditions: None. Post Conditions: None Inputs:
File Name
Purpose
The name of the BSC configuration file created
STM1
Optional/ Mandatory
Mandatory
Default value
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 subdirectory. Exceptions: None
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
215/265
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. Pre Conditions: None. Post Conditions: None Inputs:
Name of the configuration file
Purpose
Name of the configuration file to be checked The source directory is BSC_STM1/Configuration
Optional/ Mandatory
Mandatory
Default value
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
216/265
o
Endif
The quartet (STM1Interface, STM1-K, STM1-L, STM1-M) is not used in previous lines (except (0,0,0,0));
and generated the output file .

Output file example:
#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]
Exceptions: An error message is displayed to operator: If the specified file is not found in the PC NEM
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
217/265
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. Pre Conditions: None. Post Conditions: None Inputs:
Name1
Purpose
Name2
Name of the first STM1configuration file to compare. This file must belong to the Configuration sub-directory. Name of the second STM1configuration file to compare. This file must belong to the Configuration sub-directory.
Optional/ Mandatory
Mandatory
Default value
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 **File Name2** #47 2, 2, 1,225, 0, 0, 0, 0, Atermux CS ** 2: VC12 (2-1-1-1) 2: LIU port 225
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
218/265
Exceptions:
An error message is displayed to operator: 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. Pre Conditions: None. Post Conditions: None Inputs:
Name
Purpose
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
Optional/ Mandatory
Mandatory
Default value
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
219/265
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 BSCs 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
220/265
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 BSCs 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
Purpose
Number of STM1-TTP
Mandatory
Optional/ Mandatory
Default value
Outputs: A report about the outcome of the operation to the BSC terminal operator.
Parameter name Result Purpose The section and path traces available for the requested STM1-TTP number
OUTPUT TO THE BSC TERMINAL
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 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)
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
221/265
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 BSCs 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. Pre Conditions: None. Post Conditions: None Inputs:
STM1-TTP number
Purpose
Number of STM1-TTP
Mandatory
Optional/ Mandatory
Default value
Outputs:
OUTPUT TO THE BSC TERMINAL
Purpose The section and path traces available for the requested STM1-TTP number
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
222/265
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: The transmitted section trace (J0) (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) And for each VC-12 of this STM1-TTP: o The identification of the VC-12 o The transmitted Low path trace (J2) Exceptions: None
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
223/265
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 Exceptions: An error message is displayed to operator: If the BSC does not report any plugidentification;
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
224/265
5.4 5.4.1
TC-NEM Description 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 Parameter name
Purpose
Optional/ Mandatory
Mandatory
Default value
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 subdirectory 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. 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
ED 01 RELEASED
3BK 11204 0469 DSZZA
225/265
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. 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,-,_. Exceptions: An error message is displayed to operator: If the GET-SNMP is unsuccessful.
A warning message is displayed to operator:

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
226/265
If a new file is not constituted by operator decision
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
227/265
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
Purpose
Current Properties for the current properties of the STM1 configuration Or Candidate Properties for the Properties for the candidate properties of the STM1 configuration
Optional/ Mandatory
Mandatory
Default value
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 o The name of the candidate STM1 configuration file downloaded o The date of the downloading of the candidate STM-1 configuration file 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
228/265
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,-,_. Exceptions: An error message is displayed to operator: o o If the Get SNMP is unsuccessful. No name or no date found or both
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
229/265
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
Purpose
Name of STM1 configuration file to check
Optional/ Mandatory
Mandatory
Default value
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 STM1-K must be equal to 0 STM1-L must be equal to 0 STM1-M must be equal to 0 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
230/265
o
If the specified name file is not found in the <prefix>/<TC-Id>/STM-1/Configuration directory . If the used syntax is wrong.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
231/265
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 Name 1 Directory 2 Name 2 STM1 Sub-Directory where the first STM1 configuration file to compare is stored. Name of the first STM1 configuration file to compare STM1 Sub-Directory where the second STM1 configuration file to compare is stored. Name of second STM1 configuration file to compare
Purpose
Optional/ Mandatory
Mandatory Mandatory Mandatory Mandatory
Default value
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
232/265
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
Purpose
Name of the STM1 configuration file to use as candidate (*).
Optional/ Mandatory
Mandatory
Default value
(*) 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 STM1-K must be equal to 0 STM1-L must be equal to 0 STM1-M must be equal to 0 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 subdirectory under the name: <name>_<date> The date is the one reported by the TC.
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
233/265
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
234/265
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).
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
235/265
5.4.1.7 Use Case Display of TCs 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. Pre Conditions: None. Post Conditions: None Inputs: None
STM1-TTP number
Purpose
Number of STM1-TTP
Mandatory
Optional/ Mandatory
Default value
Outputs: A report about the outcome of the operation to the TC-NEM operator.
OUTPUT TO THE VIA TC-NEM
Purpose The section and path traces available for the requested STM1-TTP number
Description: On the reception of A_GETSECTPATHTRACE event from operator TC-NEM sends a GETSNMP 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 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) 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
236/265
5.4.1.8 Use Case Modification of TCs 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. Pre Conditions: None. Post Conditions: None Inputs: None
STM1-TTP number
Purpose
Number of STM1-TTP
Mandatory
Optional/ Mandatory
Default value
Outputs: A report about the outcome of the operation to the TC-NEM operator.
OUTPUT TO THE VIA TC-NEM
Purpose The section and path traces updated for the requested STM1-TTP number
Description: On the reception of A_GETSECTPATHTRACE event from operator TC-NEM sends a GETSNMP 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: The transmitted section trace (J0) (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) (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) 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
237/265
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 offthe-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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
238/265
5.4.2
Dimensioning Data
This section is not relevant in the context of the B11. 5.4.3 Object Model
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
239/265
5.5 5.5.1
Transcoder description Use case description
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 Parameter name
Qmux config BSC identity Atermux number (See Remark) 75/120 ohm rack number Qmux TS and nibble in Atermux link BSC to which MT120 is connected. Atermux link to which MT120 is connected. This information is used in TC G2.5 only, for cluster handling. 75/120 ohm selection (impedance of PCM links) rack number for TC G2/G2.5
5.5.1.1 Use Case Activate new G2.5 TC standard configuration
Purpose
Mandatory Mandatory Mandatory Mandatory Mandatory
Optional/ Mandatory
Default value
Remark: If BSC is a G2 BSC: 1.. max_G2_BSC_rack_number * 6; if BSC is a MX BSC : 1.10 for configuration1, 120 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 MT120WB) can be added. Exceptions: None.
04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
240/265
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:
Parameter name MT120 List For each MT120: MT120 state For each added MT120: Qmux config For each added MT120: BSC identity For each added MT120: Atermux number (See remark 1) For each added MT120: 75/120 ohm For each added MT120: Rack number Purpose
OPERATOR INPUTS VIA TC NEM
List of MT120 (from 1 to 48). For each MT 120: Added or removed For each added MT120: Qmux TS and nibble in Atermux link For each added MT120: BSC to which MT120 is connected. 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 selection (impedance of PCM links) For each added MT120: Rack number for TC G2.5IP
Optional/ Mandatory Mandatory Optional Optional (Only informed if the MT120 is added) Optional (Only informed if the MT120 is added) Optional (Only informed if the MT120 is added) Optional (Only informed if the MT120 is added) Optional (Only informed if the MT120 is added)
Default value Added
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, 120 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
241/265
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-TCAUDIT-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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
242/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
243/265
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.
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
244/265
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 TCNEM. 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,-,_. Exceptions: An error message is displayed to operator: If the specified file name already exists in the TC-NEM
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
245/265
5.5.1.6 Use Case Getting configuration
properties
for
current
or
candidate
TC
STM1
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 TCNEM. 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
246/265
The candidate name and the default candidate name apply the POSIX file name rules where allowed characters are A-Z,a-z,0-9,-,_.
Exceptions: An error message is displayed to operator: o If the Get SNMP is unsuccessful. o No name or no date found or both
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
247/265
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)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
248/265
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
249/265
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.)
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
250/265
5.5.1.9 Use Case Display of TCs section and path traces

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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
251/265
5.5.1.10 Use Case Modification of TCs transmitted section and path traces
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
252/265
5.5.1.11 Use Case TC Plug identification information

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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
253/265
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 Parameter name
TCSL Endpoint BSC side TCSL Endpoint TC side
Purpose
The list of BSC side TCSL Endpoint
Optional/ Mandatory
Optional Optional
Default value
The list of TC side TCSL Endpoint
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
254/265
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
Purpose Identifier of the TCSL version Identifier of the software version of the MT120. Identifier for software serveur giving FTPServerIPAddress, FTPPortNumber, user name, Password.
Parameter name
TCSL version MT120 SW Version Code server
Default value
Outputs:
Message M-TC-AUDIT-REP from TC
Purpose Status about the outcome of the operation Identifies the endpoint where the primary TC receives the multiplexed IP frames from the IP BTS. There is one TC-MUX endpoint per BSS. Identifies the endpoint where the secondary TC receives the unmultiplexed IP frames from the IP BTS. There is one TC-NONMUX endpoint per BSS. Represents the TC Rack Generation 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
Parameter name Status TC-MUX Traffic Endpoint
Optional/ Mandatory Mandatory Mandatory
Default value
TC-NONMUX Traffic Endpoint
Mandatory
TC Hardware family MT12O HW LIst
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
255/265
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
256/265
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 Parameter name
MT 120 Table The MT 120 TABLE, gives for every (BSC associated) MT120 of every TC rack: The NONMUX endpoint of its rack List of SS7 parameters List of legacy TC parameters
Purpose
Optional/ Mandatory
Mandatory
Default value
SS7 parameters (Only if A signalling over IP not activated) Legacy parameters
Optional Optional
Outputs:
Message M- TC-CONF-REP from BSC
Purpose The SS7 endpoints having SS7 SG IP address and SS7 SG port number.
Parameter name SS7 SG Endpoints (Only if A signalling over IP not already activated)
Optional/Mandatory 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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
257/265
5.5.2
Dimensioning Data
Not relevant.
5.5.3
Object Model
GLOSSARY
Alarm In Force List Adaptive Multi-rate Wideband Speech Codec GMSK (AMR Wideband) AMR NarrowBand Base station Interface Equipment Base station Interface Unit Base Station Controller BSC local TErminal Base Transceiver Station BTS O&M SBL BTS local TErminal BTS Telecom SBL Base Station Subsystem BSS releases Circuit Identity Code Common Management Information Service Elements Configuration Parameter File DataBase Data Load Segment Dual Rate Digital Trunk Controller Functional Block Functional Block Specification Full Rate Frame Unit Hardware Configuration Management HandOver Half Rate High speed Signalling Link HardWare In Traffic (SBL state) Initialization & Maintenance Operations Logical Configuration Management Local Maintenance Terminal Low speed Signalling Link Multiplexed Channel Block Mobile Switching Center MT120-NarrowBand (board)
04/06/2008 0469_1RL.doc
AIFL AMR-WB AMR-NB BIE BIU BSC BSC-TE BTS BTS-O&M BTS-TE BTS-TEL BSS Bnumber CIC CMISE CPF DB DLS DR DTC FB FBS FR FU HCM HO HR HSL HW IT IMO LCM LMT LSL MCB MSC MT120-NB
ED 01 RELEASED
3BK 11204 0469 DSZZA
258/265
MT120-WB MF NSR N7 O&M OMC-R OML OMU OMU-CPF OPR OSSC PCM Qmux RC RIT RSL SBL SDH SFS SLC SM SPC STM SUM SUMP SUMA SW SWM TAS TC TC-TE TC-NEM TC-SM2M TCH TCU TFO TRCU TRE TS TSC USOD VC WTC X25
MT120-WideBand (board) Master File Network SupeRvision Number 7 signalling system Operation and Maintenance Operation and Maintenance Center - Radio part Operation and Maintenance Link Operation and Maintenance Unit Operation and Maintenance Unit Configuration Parameter File OPerator out of seRvice (SBL state) Optimized Sectored Site Configuration Pulse Code Modulation Transmission equipment supervision bus , also called "Q1" Ring Control Replaceable ITem Radio Signalling Link Security Block Synchronous digital hierarchy System Functional Specification Signalling Link Code A-Interface Sub-Multiplexer Signalling Point Code (MSC/BSC address) Synchronous transport mode BTS Station Unit Module BTS Station Unit Module PCM BTS Station Unit and Maintenance version A SoftWare SoftWare Maintenance TMN Administration Services TransCoder TC terminal TC Terminal from B10, available with TC G2.5 with TCIF (TC IP) Submultiplexor at transcoder site Traffic CHannel Terminal Control Unit Tamdem Free Operation TRansCoder Unit Transceiver Equipment (FU + CU) Time Slot Transcoder Submultiplexer Controller Usage State On Demand (in fact DTC USOD) Virtual Container Wait Traffic Clear X25 link
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
259/265
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 STM1 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
260/265
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
261/265
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
262/265
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 SectionTrace-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 pathreceiving terminal can verify its continued connection to the intended transmitter. Default value The default value for path trace is: "TCJ2xxmssddddy" Where:
ED 01 RELEASED
04/06/2008

0469_1RL.doc
3BK 11204 0469 DSZZA
263/265
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 TCs section and path traces
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
264/265
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
ED 01 RELEASED

04/06/2008 0469_1RL.doc
3BK 11204 0469 DSZZA
265/265

Hardware Configuration Management

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Hardware Configuration Management

Hochgeladen von

Copyright:

Verfügbare Formate

Site

All Rights Reserved Alcatel-Lucent

VELIZY Originators S.MAINTROT

System Sub-system Document Category EXECUTIVE SUMMARY

ALCATEL-LUCENT GSM BSS SYS-TLA PRODUCT DEFINITION

Ed. 01 Proposal 01 Ed. 01 Proposal 02 Ed. 01 Proposal 03

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

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