Operation

Base Station Controller

OMN:BSC
A30808-X3247-L210-3-7619

OMN:BSC

Operation
Base Station Controller

Important Notice on Product Safety

DANGER - RISK OF ELECTRICAL SHOCK OR DEATH - FOLLOW ALL INSTALLATION
INSTRUCTIONS.
The system complies with the standard EN 60950 / IEC 60950. All equipment connected to the
system must comply with the applicable safety standards.
Hazardous voltages are present at the AC power supply lines in this electrical equipment. Some
components may also have high operating temperatures.
Failure to observe and follow all installation and safety instructions can result in serious
personal injury or property damage.
Therefore, only trained and qualified personnel may install and maintain the system.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit
LEBENSGEFAHR - BEACHTEN SIE ALLE INSTALLATIONSHINWEISE.
Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Alle an das System angeschlossenen Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.
In diesen Anlagen stehen die Netzversorgungsleitungen unter gefhrlicher Spannung. Einige
Komponenten knnen auch eine hohe Betriebstemperatur aufweisen.
Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Krperverletzungen oder Sachschden fhren.
Deshalb darf nur geschultes und qualifiziertes Personal das System installieren und warten.

Caution:
This equipment has been tested and found to comply with EN 301489. Its class of conformity is
defined in table A30808-X3247-X910-*-7618, which is shipped with each product. This class also
corresponds to the limits for a Class A digital device, pursuant to part 15 of the FCC Rules.
These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment.
This equipment generates, uses and can radiate radio frequency energy and, if not installed and used
in accordance with the relevant standards referenced in the manual Guide to Documentation, may
cause harmful interference to radio communications.
For system installations it is strictly required to choose all installation sites according to national and
local requirements concerning construction rules and static load capacities of buildings and roofs.
For all sites, in particular in residential areas it is mandatory to observe all respectively applicable
electromagnetic field / force (EMF) limits. Otherwise harmful personal interference is possible.

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

Copyright (C) Siemens AG 2003.

Issued by the Information and Communication Mobile Group
Hofmannstrae 51
D-81359 Mnchen
Technical modifications possible.
Technical specifications and features are binding only insofar as
they are specifically and expressly agreed upon in a written contract.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Issues
Change indications (Ind.):
N = new;
G = modified;
Document

0 = deleted;

Title

Page(s)

OMN:BSC. . . . . . . . . . . .

1...738

Issue/Ind.
3

This document consists of a total of 738 Pages

Reason for Update

Chapter/Section
All

Reason for Update

New Release BR7.0
Revised Chapter

Issue History
Issue
Number

Date of Issue

Reason for Update

07/2003

First Edition for New Release BR7.0.

Prelim. 10/2003

Common Edition for BR7.0 and TD2.0.

12/2003

Second Edition for BR7.0 .

A30808-X3247-L210-3-7619

OMN:BSC

Operation
Base Station Controller

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Contents
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Purpose of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input Handler Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supported BSC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notes on Configuration Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support of different HW generations of network entities. . . . . . . . . . . . . . .
Management of Symbolic names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attribute Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tasklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10

Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
BSS Addressing Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
BSS Date-Time Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
BSC "Bring-Up" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
MPCC loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Download of a SW Load Header File on BSC Disk . . . . . . . . . . . . . . . . . . 74
Download of a database file on BSC disk. . . . . . . . . . . . . . . . . . . . . . . . . . 77
Download of a Single Executable File on BSC Disk . . . . . . . . . . . . . . . . . . 79
Download of a Single Patch File on BSC Disk . . . . . . . . . . . . . . . . . . . . . . 81
Deletion of Files from BSC Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Getting the attributes of RSUSWLH, RSUDB, RSUEXE and RSUPCH objects.
87
Getting the attributes of BSCESUSW, BSCESUDB, and NEYESUSW objects.
89
Update of the Software Load within the BR7.0 Release. . . . . . . . . . . . . . . 92
Hardware/Software Upgrade from BR5.5 to BR7.0 Release . . . . . . . . . . 103
Hardware/Software Upgrade from BR6.0 to BR7.0 release . . . . . . . . . . . 117
BSC Reload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Upload of a Database File from BSC Disk . . . . . . . . . . . . . . . . . . . . . . . . 137
Changing the User Label for SW load header/database files . . . . . . . . . . 138
Loading Patch Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Enabling a patch file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Unloading Patch Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Get Information about SW Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Setting a Generic SW Load as Backup, Fallback, or New SW Load . 149
Loading a Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Setting a Generic Database as Backup, Fallback, or New Database 152
Saving Database Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Download and Activate BTSE, BTSEC and TRAU SW Loads . . . . . . . . . 155
BSC Initialization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Upload of BSC Log File from LMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Upload of a TRAU Log File from LMT. . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Upload of a BTSE Log File from LMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Decoding Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31

A30808-X3247-L210-3-7619

15
15
15
16
19
34
39
48
52
58

OMN:BSC

Operation
Base Station Controller

3.32
3.33
3.34
3.35
3.36
3.37
3.38
3.39
3.40
3.41
3.42
3.43
3.44
3.45
3.46
3.47
3.48
3.49
3.50
3.51
3.52
3.53
3.54
3.55
3.56
3.57
3.58
3.59
3.60
3.61
3.62
3.63
3.64
3.65
3.66
3.67
3.68
3.69
3.70
3.71
3.72
3.73
3.74
3.75
3.76
3.77
3.78

System Disk Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

System Disk File and Directory Management . . . . . . . . . . . . . . . . . . . . . . 169
Object State Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Object Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Peripheral processors failure during Bring-Up. . . . . . . . . . . . . . . . . . . . . 178
Signalling Link Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Addition of a PCMB Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Addition of a New Site Manager and of related LAPD links . . . . . . . . . . . . 190
Configuration of the Abis Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Addition of a BTS (Cell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Addition of a FHSY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Addition of a Frequency to FHSY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Deletion of a Frequency from FHSY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Addition of a Network Service Virtual Connection . . . . . . . . . . . . . . . . . . . 241
Deletion of a Network Service Virtual Connection . . . . . . . . . . . . . . . . . . . 242
Addition of a Point-to-Point Packet Function (GPRS/EGPRS) . . . . . . . . . 243
Deletion of a Point-to-Point Packet Function . . . . . . . . . . . . . . . . . . . . . . . 248
Addition of a Frame Relay Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Deletion of a Frame Relay Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Addition of a Packet Control Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Deletion of a Packet Control Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Addition of a PCM line in G interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Deletion of a PCM line in G interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Disabling Frequency Hopping for a BTS . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Enabling Frequency Hopping for a BTS. . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Addition of a TRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Enabling/Disabling GPRS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Enabling/Disabling EGPRS service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Enabling/Disabling GPRS CS3-CS4 Coding Schemes . . . . . . . . . . . . . . . 289
Enabling Link Adaptation for GPRS and EGPRS . . . . . . . . . . . . . . . . . . . 296
Deletion of a TRX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Setting a TRX in Emergency Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Addition of a Radio Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Smooth Channel Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Addition of a New GSM/GPRS/EGPRS Adjacent Cell. . . . . . . . . . . . . . . . 320
Addition of a New GSM/GPRS/EGPRS External Cell . . . . . . . . . . . . . . . . 325
Addition of a UMTS Adjacent Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Configuring separate BA Lists for Idle and Active State . . . . . . . . . . . . . . 331
Addition of a PCM Line A-sub interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Addition of a TRAU to the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Addition of a PCM Line A Interface and SS7 Link . . . . . . . . . . . . . . . . . . . 344
Management of Links towards Radio Commander/Cell Broadcast Centre 347
Addition of a PPLD (only for standard BSC) and of a LICD Board . . . . . . 355
Definition of the Signalling Point Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Setting the External/Free Run Synchronization . . . . . . . . . . . . . . . . . . . . . 359
Deletion of a BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Handover Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

3.79
3.80
3.81
3.82
3.83
3.84
3.85
3.86
3.87
3.88
3.89
3.90
3.91
3.92
3.93
3.94
3.95
3.96
3.97
3.98
3.99
3.100
3.101
3.102
3.103
3.104
3.105
3.106
3.107
3.108
3.109
3.110
3.111
3.112
3.113
3.114
3.115
3.116
3.117
3.118
3.119
3.120
3.121
3.122
3.123

A30808-X3247-L210-3-7619

Management of Handover for Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Enabling Handover with Level HO Margin parameter . . . . . . . . . . . . . . 380
Management of Fast Uplink Handover . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Enabling handover from UMTS to GSM . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Enabling GSM-UMTS cell Re-selection . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Enabling Handover from GSM to UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . 397
Management of the Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Enabling/Disabling of the Emergency Calls . . . . . . . . . . . . . . . . . . . . . . . 421
Barring the Access to a Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Hierarchical Cell Structure Management . . . . . . . . . . . . . . . . . . . . . . . . . 423
Definition and Activation of Environmental Alarms . . . . . . . . . . . . . . . . . . 425
Deletion of an External Alarm for a BSC. . . . . . . . . . . . . . . . . . . . . . . . . . 428
BSC Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Directed Retry Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Concentric Cell Structure Management . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Sleeping Cell Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Circuit Pool Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Enabling CTM Circuit Pool Solution for Text Telephone Calls . . . . . . . . . 450
HSCSD Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Queueing, Preemption and Directed Retry for TCH . . . . . . . . . . . . . . . . . 457
Voice Group Call Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Voice Broadcast Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Enabling enhancements in ASCII services . . . . . . . . . . . . . . . . . . . . . . . . 465
Enabling Cell load dependent activation of HR channels . . . . . . . . . . . . . 470
Enabling Enhanced pairing for TCH/H channels . . . . . . . . . . . . . . . . . . . 475
Management of Radio Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Creation and Handling of Inventory File . . . . . . . . . . . . . . . . . . . . . . . . . . 494
VAD/DTX and Comfort Noise for Half Rate Speech . . . . . . . . . . . . . . . . . 500
BTS Multidrop - Star Cross Connect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
NUC within TRAU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
NUC within BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Management of Adaptive Multirate Codec (AMR) . . . . . . . . . . . . . . . . . . 508
Support of Satellite Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
14.4 kbit/s Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Enabling Location Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Enabling Antenna Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Management of Transmission Diversity with Time Delay . . . . . . . . . . . . . 544
Management of Four Branch Receive Diversity/Switched Beam Functionality
552
Enabling the Emergency Setup 2 message for emergency calls in GSM-R . .
569
Enabling/Disabling GPRS Traffic Control Management . . . . . . . . . . . . . . 570
Addition/Deletion of a TD-SCDMA Control Unit . . . . . . . . . . . . . . . . . . . . 576
Addition of a New TD-SCDMA Site Manager and of Related LAPD Links 579
Addition/Deletion of a TD-SCDMA Cell (BTSTD) . . . . . . . . . . . . . . . . . . . 583
Addition/Deletion of a TD-SCDMA Transceiver (TRXTD) . . . . . . . . . . . . 589
Addition/Deletion of a TD-SCDMA Air Timeslot . . . . . . . . . . . . . . . . . . . . 593

OMN:BSC

Operation
Base Station Controller

3.124
3.125
3.126

3.142
3.143
3.144
3.145
3.146
3.147
3.148
3.149
3.150
3.151
3.152
3.153

Enabling Dynamic Channel Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . 596

Addition/Deletion of a Packet Control Unit for TD-SCDMA . . . . . . . . . . . . 607
Addition/Deletion of a Point-to-Point Packet Function (GPRS) for TD-SCDMA
609
Addition of a New Adjacent Cell for TD-SCDMA . . . . . . . . . . . . . . . . . . . . 613
Addition of a New TD-SCDMA/GSM External Cell . . . . . . . . . . . . . . . . . . 619
TD-SCDMA Handover Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Management of the TD-SCDMA Power Control . . . . . . . . . . . . . . . . . . . . 625
TD-SCDMA Directed Retry Management . . . . . . . . . . . . . . . . . . . . . . . . . 627
HSCSD Service in TD-SCDMA System. . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Usage of tools for database management (DBAEM and CONVFILE tools) . .
632
Different release Data Base Conversions . . . . . . . . . . . . . . . . . . . . . . . . . 644
Creation of a Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Creation of a SCANAIRTSTD object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Requesting the Current Measurement Values of a Scanner Job. . . . . . . . 665
Upload of the Measurement Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Changing Attributes of a Measurement Campaign . . . . . . . . . . . . . . . . . . 668
Get Info Report Scan Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Enabling Performance Measurements Based on Enhanced Measurement
Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Management of Trace Measurement Reports . . . . . . . . . . . . . . . . . . . . . . 688
Get Info TRACE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Activation and Deactivation of a Cell Traffic Recording . . . . . . . . . . . . . . . 692
Enabling/Disabling Measurements to Get Smart Carrier Allocation. . . . . . 696
Upload of Smart Carrier Allocation Measurements . . . . . . . . . . . . . . . . . . 705
Management of Online RF Loop Back. . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Creation or Deletion of a Remote Object . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Modification of Some Attributes of a Remote Object . . . . . . . . . . . . . . . . . 718
Obtaining the Attributes of a Remote Object . . . . . . . . . . . . . . . . . . . . . . . 721
Object State Check for Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Stop Transmission of BTS Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Test Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

4
4.1

Tables, lists and figures (TAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734

Suspect frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736

Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737

3.127
3.128
3.129
3.130
3.131
3.132
3.133
3.134
3.135
3.136
3.137
3.138
3.139
3.140
3.141

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Figures
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.

1.3.1
1.3.2
1.4.3
1.4.4
1.4.5
1.4.6
1.4.7
1.5.8
1.5.9
1.6.10
1.11
1.12
1.13
1.14
1.15
1.16
1.6.17
1.6.18
1.6.19
1.7.20
1.7.21
1.7.22
1.7.23
1.8.24
1.8.25
1.8.26
1.9.27
1.9.28
3.1

Fig. 3.2
Fig. 3.3
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.

A30808-X3247-L210-3-7619

3.57.1
3.57.2
3.65.3
3.65.4
3.66.5
3.70.6
3.73.7
3.73.8
3.73.9

Input Handler main window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Command window for the BTS object . . . . . . . . . . . . . . . . . . . . . . . . . . 18
View of the standard BSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
View of the High capacity BSC with the traditional rack. . . . . . . . . . . . 22
High capacity BSC with the new rack . . . . . . . . . . . . . . . . . . . . . . . . . . 27
High Capacity BSc with New Rack (Frontal View). . . . . . . . . . . . . . . . . 31
Example of BSC Rack supporting TD-SCDMA . . . . . . . . . . . . . . . . . . . 32
Creation Tree without TD-SCDMA Objects . . . . . . . . . . . . . . . . . . . . . . 35
Creation Tree for TD-SCDMA related objects . . . . . . . . . . . . . . . . . . . . 36
BTSEs and TRAU hardware objects on the LMT . . . . . . . . . . . . . . . . . 40
BTSE containment tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
BTSEP containment tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
BTSEPICO containment tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
BTSEEM containment tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
BTSEXS containment tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
BTSEC containment tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
TRAUE containment tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Main Control Task appearance.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
NE selection Interworking mode dialog window. . . . . . . . . . . . . . . . . . . 47
Adjacent Cell Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
LMT Control Center window (the LMT is Logged) . . . . . . . . . . . . . . . . . 50
LMT Control Center (the LMT is Unlogged). . . . . . . . . . . . . . . . . . . . . . 51
Browse Symbolic name panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Relation among BSC software objects . . . . . . . . . . . . . . . . . . . . . . . . . 56
Relation among BSC database objects . . . . . . . . . . . . . . . . . . . . . . . . 57
Relation among BTSM/TRAU software objects . . . . . . . . . . . . . . . . . . 58
Input Handler - Panel related to CREATE BTS command . . . . . . . . . 60
Input Handler - Panel related to CREATE BTSM command. . . . . . . . 61
High Capacity BSC: Relationship between PCU Frames and Abis Allocation according to the BTSE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Standard BSC: Relationship between PCU Frames and Abis Allocation
according to the BTSE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
BSC handling of BTS Equipment with Software Releases not supporting
the Abis Dynamic Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
SDCCH Allocation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
SDCCH Release Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Management of adjacent cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Example of BSC-TRAU connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Example of BSC-RC/CBC connection through a LAN . . . . . . . . . . . . . 349
Example of BSC-RC/CBC connection: Y cable like. . . . . . . . . . . . . . . 350
Example of BSC-RC/CBC connection by two links . . . . . . . . . . . . . . . 350

OMN:BSC

Operation
Base Station Controller

Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.

10

3.79.10 Handover for Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

3.79.11 BSC procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
3.79.12 BSC Handover execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
3.80.13 Handover in good coverage area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
3.80.14 Handover in poor coverage area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
3.82.15 UMTS/GSM network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
3.84.16 UMTS/GSM network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
3.85.17 Adaptive Power Control Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
3.93.18 Concentric Cell Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
3.96.19 Association of a CTM adapter with the transcoder in the access network.
450
3.102.20 Cell load dependent activation of HR algorithm . . . . . . . . . . . . . . . . . 472
3.104.21 Processes related to Service dependent channel allocation . . . . . . . 478
3.104.22 Management of incoming calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
3.104.23 Handling of GPRS/EGPRS requests . . . . . . . . . . . . . . . . . . . . . . . . . 483
3.104.24 Waiting queue handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
3.105.25Overview of the IDFs flow in the system . . . . . . . . . . . . . . . . . . . . . . . 495
3.107.26 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
3.110.27 Multirate Configuration Information Element . . . . . . . . . . . . . . . . . . . 509
3.28
Parameters for multirate speech with one codec mode . . . . . . . . . . . . 510
3.29
Parameters for multirate speech with two codec modes . . . . . . . . . . . 510
3.30
Parameters for multirate speech with three codec modes . . . . . . . . . . 511
3.31
Parameters for multirate speech with four codec modes . . . . . . . . . . . 511
3.110.32 Thresholds and Hysteresis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
3.113.33 LCS network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
3.113.34 NSS centric architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
3.113.35 BSS centric architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
3.36
Connection between BSC and MSC. . . . . . . . . . . . . . . . . . . . . . . . . . . 529
3.37
Connection among BSC, MSC and SMLC (the MSC acts as a STP). . 531
3.38
Connection among BSC, MSC and SMLC (NUC across the MSC).. . . 531
3.114.39 Antenna hopping with 5 CUs and 2 antennas . . . . . . . . . . . . . . . . . . 538
3.115.40Example of transmission diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
3.41
ECU4R Block Diagram (Four branch receive diversity mode) . . . . . . . 552
3.42
Example of Configuration Using the Four Branch Receive Diversity Mode
553
3.116.43BS240 Configuration for Smart Antenna Operation . . . . . . . . . . . . . . 556
3.44
Carrier Unit Extensions for Smart Antenna Operation . . . . . . . . . . . . . 558
3.116.45Switched Beam Control inside ECU4R . . . . . . . . . . . . . . . . . . . . . . . . 559
3.116.46Switched Beam Control Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
3.116.47Configuration with a Switched Beam Cell . . . . . . . . . . . . . . . . . . . . . . 563
3.123.1 TD-SCDMA principle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
3.124.2 Flow diagram of Channel Selection algorithm - Step 1 . . . . . . . . . . . . 602
3.124.3 Flow diagram of Channel Selection algorithm - Step 2 . . . . . . . . . . . . 603
3.127.1 Management of adjacent cells for TD-SCDMA . . . . . . . . . . . . . . . . . . 614

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig.
Fig.
Fig.
Fig.
Fig.
Fig.

A30808-X3247-L210-3-7619

3.129.2
3.133.3
3.133.4
3.133.5
3.133.6
3.147.7

Handover Typologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
create_cmd modality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
create_db modality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
modify_db modality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
get_info modality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RF Online Loop Back database structure. . . . . . . . . . . . . . . . . . . . . .

623
634
635
636
637
710

11

OMN:BSC

Operation
Base Station Controller

Tables
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.

12

1.4.1 Features of the standard BSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.4.2 Features of the High capacity BSC with Old Rack. . . . . . . . . . . . . . . . 22
1.4.3 Correspondence between the boards of the two types of BSC . . . . . . . 24
1.4.4 Features of the High capacity BSC with New Rack.. . . . . . . . . . . . . . . 26
1.5
Possible hardware configurations of the BSC. . . . . . . . . . . . . . . . . . . . . 28
1.4.6 Maximum instances/values for TD-SCDMA . . . . . . . . . . . . . . . . . . . . . . 33
1.8.7 Object classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1
Mapping of Services onto Abis Resources . . . . . . . . . . . . . . . . . . . . . . 197
3.59.1 Combinations of TRXMD and TRX CAPABILITY Values . . . . . . . . . . . 278
3.61.2 EGPRS Coding Schemes and Families . . . . . . . . . . . . . . . . . . . . . . . . 296
3.3
Thresholds to be used if Family A plus MCS1 is chosen . . . . . . . . . . . 302
3.4
Thresholds to be used if Family B plus MCS1 is chosen . . . . . . . . . . . 302
3.65.5 POOL types and related radio timeslots . . . . . . . . . . . . . . . . . . . . . . . . 313
3.73.6 Causes that Activate Tests on IP Links . . . . . . . . . . . . . . . . . . . . . . . . 352
3.78.7 Service Groups for Handover Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 366
3.78.8 Example of Service Independent Parameters . . . . . . . . . . . . . . . . . . . 369
3.78.9 Example of Service Independent Parameters . . . . . . . . . . . . . . . . . . . 369
3.79.10 BSC object parameter used to manage Traffic Handover. . . . . . . . . . 373
3.79.11 HAND object parameters used to manage Traffic Handover . . . . . . . 373
3.79.12ADJC object parameters used to manage Traffic Handover . . . . . . . . 374
3.81.13Handover criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
3.81.14 HAND object parameters used to manage Traffic Handover . . . . . . . 387
3.81.15ADJC object parameters used to manage Traffic Handover . . . . . . . . 387
3.84.16Speed Sensitive Handover Parameters in Case of Power Budget
Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
3.84.17Speed Sensitive Handover Parameters in Case of Sufficient UMTS
Coverage Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
3.85.18Service Groups for Power Control Purpose . . . . . . . . . . . . . . . . . . . . . 417
3.85.19Example of Service Independent Parameters . . . . . . . . . . . . . . . . . . . 418
3.85.20Example of Service Independent Parameters . . . . . . . . . . . . . . . . . . . 419
3.95.21Circuit Pool Coding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
3.104.22Number of Abis/PDT Resources Assigned to each PDCH, according to
the Selected Coding Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
3.110.23Source codec bit rates defined for AMR. . . . . . . . . . . . . . . . . . . . . . . 508
3.110.24Supported codecs by BTS1 and BTSplus . . . . . . . . . . . . . . . . . . . . . 519
3.114.25Available combinations due to BSS hardware . . . . . . . . . . . . . . . . . . 537
3.114.26 BTS object parameters used to manage Antenna Hopping . . . . . . . 541
3.135.1Scanner managed object classes for GSM . . . . . . . . . . . . . . . . . . . . . 651
3.135.2Scanner managed object classes for TD-SCDMA . . . . . . . . . . . . . . . . 652
3.135.3MOCs supporting or not Automatic Adaptation . . . . . . . . . . . . . . . . . . 655
3.142.4BSC parameters used to manage Trace measurement reports. . . . . . 688
3.147.5Parameters related to BSPOWER calculation . . . . . . . . . . . . . . . . . . . 708
3.148.6BTSE objects that can be created/deleted . . . . . . . . . . . . . . . . . . . . . . 714

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Tab.
Tab.
Tab.
Tab.
Tab.
Tab.
Tab.

A30808-X3247-L210-3-7619

3.148.7TRAUE objects that can be created/deleted . . . . . . . . . . . . . . . . . . . .

3.149.8BTSE objects whose attributes can be changed. . . . . . . . . . . . . . . . .
3.149.9TRAUE objects whose attributes can be changed . . . . . . . . . . . . . . .
3.150.10BTSE objects whose attributes can be displayed . . . . . . . . . . . . . . .
3.150.11TRAUE objects whose attributes can be displayed. . . . . . . . . . . . . .
3.153.12BTSE Hardware Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.153.13TRAUE Hardware Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

715
718
719
721
723
731
732

13

OMN:BSC

14

Operation
Base Station Controller

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

1 Introduction
1.1

Purpose of the Document

The purpose of this document (OMN:BSC) is to provide all necessary information for the
LMT operator to interface with the Base Station System.
This manual gathers in a single document the operating procedures, as described from
the user point of view, and all the related information.
A procedure may include either a single command or a series of commands. In the latter
case, the order to be followed during the command execution is reported. The detailed
description of single commands is given in the "Command Manual of BSC" (CML:BSC).

1.2

Structure of the Document

This document has a standard structure. After the introduction chapter that describes
some features of the LMT and some general concepts about managed objects, the
described procedures are grouped according to their functional area as follows:

General use includes some procedures of general use regarding the whole BSS,
such as the date and time management.
Software Management refers to the management of the system. This includes the
"Bring-Up", i.e. the initialization of the system during which the system load all the
files. The system upgrading procedures are also described. These start from the
loading of the necessary files up to the re-initialization of the system.
System Disk Management describes the system disk management: how to delete,
move or copy files, directories, formatting the system disk etc.
Fault Management describes the State and Status management procedures,
together with the operations to be performed to activate the diagnostics. Each object
is characterized by two parameters, called "state" and "status", which define its
logical status. Looking at these properties, the user can detect the causes of any
faults in the behavior of the system. Moreover, this section describes the signalling
link management procedures and the automatic procedure for control channel
reconfiguration.
Configuration Management provides a collection of the system configuration procedures. As mentioned before, the user can find the procedure to add or delete some
objects to the BSS, or to modify some attributes, in order to change the characteristics of an object.
Log Files Management collects procedures related to the management of event log
files.
Measurements Management describes the management of performance measurements.
Interworking Management (Configuration Interworking Procedures, Fault & State
Interworking Procedures, Test Interworking Procedures) is the description of the
interworking commands / procedures, used to manage the other NE: (i.e. BTS
equipment and TRAUs.)

The procedure structure includes the sections described below:

A30808-X3247-L210-3-7619

Introduction: it contains a short description of the procedure and its purpose;

15

OMN:BSC

Operation
Base Station Controller

1.3

Pre-Requisites: it contains any action or condition that must be taken or met before
starting the procedure;
Procedure Description: it contains a description of the procedure listing the
commands to be activated and their order. It can define one or more procedure
steps. Each procedure step is described from the operator point of view. Actions to
be performed from the LMT are described as a sequence of selections.on the Input
Handler graphical interface (see 1.3).

Input Handler Application

Input Handler is the graphical user interface, activated under the control of the Dashboard, which performs the command interaction with the network element.
By using the Input Handler the user can:

acquire commands, actions or scripts;

send and receive messages containing commands or responses to/from the
network element;
have script/commands translation services;
store issued commands and retrieve responses coming from the network element.

After the connection to the Input Handler Application (please refer to Operator Guidelines OGL:LMT), the window shown in the Fig. 1.3.1 is displayed. The Input Handler
main window can be subdivided in two areas:

the left panel contains the Object Containment Tree and can be navigated by the
user; each tree leaf can be a node, in which case it can be opened (expanded) or
closed;
the right panel contains the command strings, composed by the user using the
command panel and sent to the command interpreter, together with the possible
command interpreter diagnostics.

The Object Containment Tree is subdivided in different logical areas:

BSS-EQUIPMENT: which contains all the Hardware Objects of a BSC;

BSS-FUNCTIONAL: which contains all the Functional Objects related to the BSS
system;
SOFTWARE-MANAGEMENT: which contains objects used to manage the BSS
software (see "1.8 Software Management");
LMT-INTERNAL: used to manage some internal feature of the LMT Input Handler
MEL: used to manage the BSS addressing from the RC point of view, and some
other BSS features (see PROC: BSS Addressing Management).

Making a double-click on one of the objects in the tree, the relevant commands associated to that object are shown (see Fig. 1.3.2).

16

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

menu bar
tool bar

object containment tree

Fig. 1.3.1

status bar

outgoing messages

Input Handler main window

A30808-X3247-L210-3-7619

17

OMN:BSC

Operation
Base Station Controller

Fig. 1.3.2

Command window for the BTS object

Besides, to manage the introduction of new BTSE generations, and to distinguish the
different behavior of different BTSE types, there is a specific Object for each BTSE
family. The different BTSE objects, each representing a BTSE family, are the following:

BTSE; it represents the BTS1 family, i.e. the following BTS types:

18

BS20;
BS21E;
BS22;
BS60;
BS61E;

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

BTSEP; it represents the BTSplus family, i.e. the following BTS types:

BS240;
BS240SR;
BS240XS;
BS240XL;
BS241;
BS241SR;
BS40;
BS41.

BTSEPICO; it represents the picoBTS, i.e. the BS242 BTS type;

BTSEEM; it represents the enhanced microBTS, i.e. the BS82 BTS type.

BTSEXS; it represents a basic version of the BTSplus family (i.e. the BS240XS BTS
type); it is a low cost BTS with a maximum configuration of 2/2/2 TRX.

BTSEC: it represents the BTSE equipment supporting TD-SCDMA functionality.

There is also a specific object, called TRAUE, used to manage the hardware related to
the Transcoding and Rate Adaption Unit (TRAU). Detailed information about these
objects are given in "1.6 Support of different HW generations of network entities".
For the command trees of Phase 1 and Phase 2 please refer to Command Manual
CML:BSC.

1.4

Supported BSC Types

Different types of BSCs are supported in the current release; they are:
1. the BSC equipped with the SN16 switching matrix and with older peripheral processors (here called standard BSC);
2. the High capacity BSC based on the same rack of the standard one, but equipped
with the SNAP switching matrix (here called High capacity BSC with the old rack);
this BSC provides better performances in terms of:
connectivity (i.e. number of PCM lines);
packet data handling capability;
LAPD signalling.
3. the High capacity BSC based on a new rack (here called High capacity BSC with
the new rack), that provides, better the capability with respect to the High capacity
BSC with the old rack, thanks also to new LICD cards.
In the following the main characteristics of these types of BSC are described, in order to
put in evidence their differences.

1.4.1

It is important to underline that among different BSC types, only the High capacity BSC
based on the new rack is able to support the TD-SCDMA service (see "1.4.3.1 High
Capacity BSC supporting TD-SCDMA Services").

Standard BSC
The rack of the standard BSC (as it appears with and without PPCU boards) is shown
in Fig. 1.4.3.

A30808-X3247-L210-3-7619

19

OMN:BSC

Operation
Base Station Controller

Besides, Tab. 1.4.1 illustrates the capability of this BSC.

Fig. 1.4.3

View of the standard BSC.

Functionality

Capability

Controlled TRXs

250

Controlled cells

150

Controlled BTSE

100

Controlled TRAUs

20

PCM lines (Abis + Asub)

46

LAPD (Abis + Asub)

48 - 112 (*)

SS7L

GPRS channels

128

Processing Capacity Erlang

2000

Switching Capacity Erlang

2000

(*) depending on GPRS channels

Tab. 1.4.1 Features of the standard BSC.

20

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The most meaningful numbers characterizing this BSC are now described, considering
two kinds of configurations (it is implicitly assumed the usage of QTLP V2 boards; this
type of LICD indeed allows the maximum flexibility in the availability of PCM ports):
1.

configuration not supporting GPRS; the main features are:

the 72 PCM ports are split into PCMB and PCMS, according to the following
formula

n. PCMS + 2xn. PCMB = 72

the total bandwidth towards PPXX is 4 x 2 Mbit/s; in other words, 128 time slots
at 64 Kbit/sec are available for signalling purposes. 8 time slots are reserved for
CCSS#7 (4 per each PPCC board) and 112 (8 per each PPLD board) for handling
the signalling towards BTSEs and TRAUEs. The remaining 8 time slots are kept
free for LAPD back up, and are connected to a spare PPLD. It is important to
notice, here, that each time slot can accommodate one physical link regardless of
the bandwidth; in other words if a LAPD at 16 Kbit/sec is assigned to one time
slot, the remaining 48 Kbit/sec are wasted.
2. maximum configuration supporting GPRS (with 4 PPCU boards); the main
features are:
the 72 PCM ports are split into PCMB, PCMS and PCMG, according to the
following formula

n. PCMS + n. PCMG + 2xn. PCMB = 72

2 PCMG are enough to handle all the 32 Frame Relay Links (FRLs) that can be
equipped on the 2 PCUs. This makes possible a PCM fault redundancy on Gb
interface, by distributing properly the FRL of the 2 PCUs over the 2 PCMG lines.
the time slots available for LAPD signalling are reduced to 48 (instead of 112),
because 4 PPCUs replace 8 PPLDs. The number of 8 SS7L remains unchanged;
PDTCH channels configurable on 4 PPCUs (2 PPCUs in service and 2 spare
cards) are 128. The available 64 Kb/s time slots for Gb interface (FRL) are 32.

1.4.2

High Capacity BSC with Old Rack

Using the same rack of the previous releases, it is possible to get a BSC with an higher
capacity by changing some boards; this High capacity BSC (with its new boards) is
shown in Fig. 1.4.4, while Tab. 1.4.1 illustrates its extended capability.

A30808-X3247-L210-3-7619

21

OMN:BSC

Operation
Base Station Controller

Fig. 1.4.4

View of the High capacity BSC with the traditional rack.

Functionality

Capability

Controlled TRXs

500

Controlled cells

250

Controlled BTSE

200

Controlled TRAUs

32

PCM lines (Abis + Asub)

72

LAPD (Abis + Asub)

240

SS7L

16

GPRS/EGPRS channels

1280 guaranteed
1536 at most

Processing Capacity Erlang

3200

Switching Capacity Erlang

3500

Tab. 1.4.2 Features of the High capacity BSC with Old Rack.

22

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

In order to meet the requirements described in the previous table, new boards are used:

i
1.4.2.1

a new switching matrix board, called SNAP;

new peripheral processor boards, called PPXL and PPXU.

The easiest way to upgrade the database after the change of SN16 board with the new
SNAP board is by invoking the convfile tool using as option -snap (see CONVFILE).

Switching Matrix (SNAP)

In comparison with the SN16 (i.e. the switching matrix of the standard BSC), this card
allows interfacing 48 lines at 8 Mb/sec coming from LICD and PPXX (double bandwidth
in comparison with the SN16, which can interface 24 lines).
This increased number of lines increases independently (i.e. without trade-off) both
GPRS/EGPRS and LAPD channels.
The new switching matrix is introduced in the system through the handling of the
NTWCARD attribute; this attribute can assume the values:

1.4.2.2

NTWSN16, when SN16 switching matrix is used (standard BSC);

NTWSNAP, when the SNAP switching matrix is used (high capacity BSC with the
old rack).

When the NTWCARD is set to NTWSN16, the BSC must work with PPCC, PPLD and
PPCU boards.
When the attribute value is NTWSNAP, only the SNAP and the new PPXU and PPXL
boards are allowed.
Mixed configurations are not possible.

PPXX Peripheral Processors

New PPXX peripheral processors are designed replacing PPCC, PPLD and PPCU
boards of the standard BSC. The new boards are able to handle LAPD/SS7 links and
GPRS/EGPRS applications.
The maximum number of PPXXs that can be used in the BSC is 8:

2 for LAPD/SS7L signalling (called PPXL);

6 for GPRS (called PPXU).

The position in the rack, which is suggested by spacing and heating aspects, is depicted
in Fig. 1.4.4. The PPXL boards are all in the base module, and do not depend on the
EPWR. The PPXU are all in the extended rack (as it is for the PPCU); new PWRD is
required for PPXU boards.
The software that is loaded on the PPXX determines the different role that the board
performs (GPRS or LAPD/SS7L application). Two dedicated executable files are loaded
on PPXL and PPXU depending on the application that they have to implement.
Tab. 1.4.3 shows the correspondence between the boards of the standard BSC and
those of the high capacity BSC.

A30808-X3247-L210-3-7619

23

OMN:BSC

Operation
Base Station Controller

Standard BSC (no

GPRS)

Standard BSC (full

GPRS configuration

High capacity
BSC

Base module PPCC-0

PPCC-0

PPCC-1

PPCC-1

PPLD-0

PPLD-0

PPLD-1

PPLD-1

PPLD-2

PPLD-2

PPLD-3

PPLD-3

PPLD-4

PPLD-4

PPLD-5

PPLD-5

PPLD-6

PPLD-6

PPXU-1

PPLD-8

PPCU-2

PPXU-2

PPLD-9

PPCU-3

PPXU-3

Extension
rack

PPXL-1

PPXL-0

PPXU-0

PPLD-7

PPLD-10
PPLD-11
PPLD-12

PPXU-4
PPCU-1

PPLD-13

PPXU-5

PPLD-14
PPCU-0
Tab. 1.4.3 Correspondence between the boards of the two types of BSC

PPXX managing LAPD and SS7L: PPXL

In the standard BSC each PPLD board handles 8 physical LAPD links (allowing, since
maximum 14 PPLD boards can be installed, a total number of 14*8 = 112 links), while 2
PPCC boards are implicitly created in the BSC allowing the handling of 4*2 SS7 links.
The redundancy schema in the former case (i.e. LAPD) is N+M (where M normally is
equal to 1) while in the latter is load sharing. The association between the circuit of the
board and the related link is handled in a different way depending on the type of link.
The operator decides the association between a SS7 link and a PPCC circuit; the software decides the relation between LAPD links and PPLD circuits during LAPD creation.
In the interface between SN16 and PPLD boards, a bandwidth of 64 Kbit/sec is assigned
to each physical circuit, no matter about the real bandwidth of the single LAPD channel
(16 or 64) in the Abis/Asub interface.
In the high capacity BSC a unique board (the PPXL one) is able to handle simultaneously both LAPD and SS7 links. One board manages up to 256 physical links; this
means that one board is able to satisfy the following requirements:
1. 240 LAPD channels;

24

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

2. 16 SS7 links.
BSC fault tolerance philosophy requires the introduction of a second PPXL board for
redundancy purpose. To avoid complication in the backward compatibility, and to avoid
to charge the operator with a useless additional work when configuring the BSC or
converting off-line the database, the two PPXL boards will be automatically created or
deleted, as well as the PPCC of the standard BSC, depending on the value of the
NTWCARD attribute.
The two PPXL boards will be both in service, and the signalling links (LAPD and SS7)
will be automatically spread on both boards. With this solution each board normally
works in relax because it uses only half of the performance it is designed for. Both HW
and SW should so have benefit from this choice.

i
i

The PPXL cards are automatically created when the NTWCARD attribute is set
NTWSNAP.
With the standard BSC, the operator decides how to spread SS7 links over the PPCCs
while the system decides for LAPDs; with high capacity BSC, this is no longer valid. To
avoid unnecessary complication in handling HW fault, system takes care of both signalling links.

PPXX managing GPRS/EGPRS: PPXU

With the standard BSC, two boards are deputed to manage GPRS/EGPRS service: they
are named PPCU. For safety reasons both boards have a spare copy. No dynamic data
is present on the spare board so the redundancy schema can be defined, in BSC terminology, as cold standby.
The creation of one PCU object implies the consequent creation of the two related
PPCU boards (active and standby):

the creation of the PCU:0 involves the creation of both the PPCU:0 and the PPCU:1;
the creation of the PCU:1 involves the creation of both the PPCU:2 and the PPCU:3.

Each PCU (and as a consequence each PPCU board), is able to handle 64 GPRS channels, and it is dynamically assigned to a pool of GPRS cells by the system.
When the active PPCU board fails, the stand-by one will replace the damaged one; if a
couple of PPCU boards fail, all the GPRS traffic will be managed by the other couple of
PPCU boards (i.e. by the other PCU) according to the load balancing criteria (see
below).
In the high capacity BSC, to reach the goal of handling 1280 GPRS/EGPRS channels it
is necessary to increase the number of boards assigned to packet switched functionality. This is allowed by the new switching matrix (SNAP), which provides 8 lines at 8
Mbit/sec towards PPXX. Two lines are used for handling LAPD and SS7 level 2 signalling protocols with the new PPXL boards; so 6 lines remain for PPXU boards.
Each PPXU board can handle up to 256 GPRS/EGPRS channels; so to reach 1280
channels, 5 boards (i.e. 1280/256 boards) have to be considered in service simultaneously; this means that 1+1 redundancy is no longer possible and a different redundancy schema is provided.

A30808-X3247-L210-3-7619

25

OMN:BSC

Operation
Base Station Controller

The used redundancy schema is called load balancing: with this schema all the 6
boards are simultaneously in service and the GPRS/EGPRS traffic is distributed among
all the six boards; this implies that each board will normally work in relax (the required
real time traffic can be spread over 6 boards instead of 5).

1.4.3

A PPXU card is automatically created when the PCU object with the same instance is
created, if NTWCARD= NTWSNAP.
Otherwise (if NTWCARD=NTWSN16), a couple of PPCU is created (PPCU 0,1 for
PCU-0; PPCU 2,3 for PCU-1).

High Capacity BSC with New Rack

A new BSC rack is foreseen to get a new BSC with higher capacity.
Fig. 1.4.5 shows the high capacity BSC with the new rack.
How it can be seen, the new rack contains the SNAP matrix and new PPXX boards,
(used as PPXUs and PPXLs) already present in the high capacity BSC with the old rack;
these boards have the same characteristics already described in "1.4.2 High Capacity
BSC with Old Rack".
With respect to the old rack, the new BSC rack provides the following innovations, that
allow the BSC to extend its capability how shown in Tab. 1.4.4:

support to the new line interface card, the STLP, which is used in place of the QTLP
in the new rack; this includes the increase from 9 to 10 of the LICD number, and from
4 to 6 of the circuit number of LICD on which a PCM line can be created;

support of 12 PCUs and PPXUs;

new rack configuration and back plane: this will allow doubling the number of used
PPXU (PPXX supporting GPRS/EGPRS) from 6 to 12; it will also allow housing
10+2 STLP, i.e. one more card than the QTLP in the old rack.

new fan box for heat dissipation.

Functionality

Capability

Controlled TRXs

900

Controlled cells

400

Controlled BTSE

200

Controlled TRAUs

48

PCM lines (Abis + Asub)

120

LAPD (Abis + Asub)

240

SS7L

16

GPRS/EGPRS channels

2816 guaranteed
3072 at most

Processing Capacity Erlang

4800

Switching Capacity Erlang

5200

Tab. 1.4.4 Features of the High capacity BSC with New Rack.

26

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig. 1.4.5

High capacity BSC with the new rack

In order to achieve these goals, the following additional changes are introduced:

the 2 EPWR (power supply devices in the expansion module) are removed to make
room for PPXU and STLP. For this reason, the PPXX and the STLP are provided with
an internal power supply, directly fed by the 48 V;

on the top of the BSC a box containing 6 fans has been introduced, powered by the
48 V, to cope the increased heat generated by the BSC;

sense points in the new board CPEX for monitoring the fan alarms have been introduced.

A30808-X3247-L210-3-7619

27

OMN:BSC

Operation
Base Station Controller

As it has been previously described (see "1.4.1 Standard BSC" and "1.4.2 High
Capacity BSC with Old Rack"), the NTWCARD attribute allows to specify the BSC type.
In fact if NTWCARD is set to NTWSN16, the BSC is made by the old rack and it works
with SN16, PPCC, PPLD and PPCU boards; if the attribute value is NTWSNAP, then
the old rack is still used but in this case only the SNAP matrix and the new PPXU and
PPXL boards are allowed.
If the user wants to use the new BSC rack, with new STLP boards (and obviously also
with SNAP and PPXU/PPXL boards), he must set the NTWCARD attribute equal to the
NTWSNAP_STLP value.
To summarize, Tab. 1.5 shows the hardware configurations that the software of the
BSC supports in BR7.0.
NTWCARD value

Switching
matrix

Peripheral
Card for
SS7L

Peripheral
Card for
LAPD

Peripheral
Card for
GPRS

Line Card

BSC
Rack
type

NTWSN16

SN16

PPCC

PPLD

PPCU

QTLP

old

NTWSNAP

SNAP

PPXL

PPXL

PPXU

QTLP

old

NTWSNAP_STLP

SNAP

PPXL

PPXL

PPXU

STLP

new

Tab. 1.5

Possible hardware configurations of the BSC

The maximum instance number of a lot of object classes depends on which BSC rack
is used (to allow the board to be physically allocated) and from the processor board that
should have enough memory to store the objects. The consistency of the type and
number of objects with the hardware configuration is controlled by means of the attribute
NTWCARD, of the BSC object.

The easiest way to upgrade the database after the change from a BSC with the old
rack to a BSC with a new one is by invoking the convfile tool using the -snap_stlp
option (see CONVFILE).
STLP Line Interface Cards
The super trunk line peripheral card (STLP) connects twelve PCM lines, which can be
configured as T1 (1544 kHz, for American networks) or E1 (2048 kHz) lines.
Like for the QTLP, the PCM lines can be grouped into couples and used as redounded
PCMS or PCMB, connecting the TRAU or the BTS in loop configuration.
The main change for the object modelling of the line cards and of the PCM lines is in the
number of these objects. The line card object, known by LMT, is still the LICD, either it
is implemented with a QTLP or a STLP; but the maximum number of LICD that can be
created is increased from 8 to 9. The PCMB/PCMS/PCMG that can be created on a
single LICD (when no line redundancy is used) is no longer 8, but 12.
Another main feature of the STLP is the capability of the STLP to get the power supply
directly from the 48 V that is available in the back-plane. Since also the PPXX have this
capability, the EPWR object will be no longer necessary in the new BSC rack, and so
they will be not equipped in this configuration. There will be a change in the hierarchical
relationship of the LICD objects, which in the new rack are no longer dependent on the
EPWR object.

28

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

From any other point of view the LICD and the PCM lines dont change their behavior.
The criteria that are used in the usage of the line and card redundancy, the hierarchical
dependency among the objects NTW, LICD and PCMB/PCMS/PCMGG are the same
as the previous release.
CPEX board
In BR7.0 sixteen additional environmental alarms have been introduced. Since there are
only five pins for connecting directly to MPCC these sense points, it has been necessary
to introduce the CPEX board, that is connected to the additional external alarms. In this
way, the new sense points can be reported into the address space of MPCC, via MPCC
bus.
In the new rack, the disk of the DK40 will be no longer necessary, and so two slots are
free to insert CPEX boards. These boards are redounded 1+1, and they are inserted, in
the enhanced BSC rack, in the slots where the DK40 was placed in the old BSC. Of
course, the CPEX has to maintain the remainder of the features handled by the DK40,
that is the management of the LEDs of the alarm panel.
Additionally, the CPEX has to report to MPCC the alarms of the fan box, which has been
introduced in the new rack in order to cope the increased heat generation of the new
BSC.
The CPEX, under a point of view of state management, will have behavior similar to the
DK40, except for the fact that the CPEX is redounded 1+1. Each copy is subordinated
of its PWRD; it will be possible to lock/unlock it and perform the test.
FAN box
Due to the increased heat production, caused by the STLP and above all by the fourteen
PPXX boards, some fans are necessary in the new BSC rack.
The fan box is placed in the top of the new BSC rack, and it contains six fans. When the
speed of rotation becomes too slow for three or fewer fans, an alarm rises in a sense
point of the CPEX. If the problem affects more than three fans, another alarm rises. A
third sense point is available to reveal the absence of the whole fan box.
The fan alarms (both the faults and the absence of the fan box) are an essential information that must be reported to LMT, so the FAN object has been introduced. The FAN
object represents the complex of six fans contained in the box placed on the top of the
BSC.
The FAN object is not redounded (only copy 0 exists), and it is present in the new rack,
and only on it. So the FAN object is implicitly equipped when the NTWCARD is set
NTWSNAP_STLP, and is never present in all other cases.
In order to describe the behavior of the FAN from the point of view of the object
modeling, some technical aspects must be considered:

when the fan alarms are active, this does not automatically mean that the BSC
working is compromised. The effects of the fault depend on how many fans are
faulted, how many cards are physically present in the BSC, and other thermodynamic aspects that is not possible to predict. In general, it cannot be said that the
alarm presence means that the fan functionality is entirely lost;

when MPCC detects the fan alarms, for what is said in the previous point, it is not
advisable to try some recovery action, for example switching off some cards, with
the aim of avoiding or reducing the problems. The BSC is protected against excessive temperature by sensors placed on the top on the BSC, which cause the auto-

A30808-X3247-L210-3-7619

29

OMN:BSC

Operation
Base Station Controller

matic switch-off of the BSC in case of necessity. This guarantees that no damage
can occur for the HW of the BSC, without need of any intervention of the software.

If both CPEX are unavailable or faulted, the fan alarms cannot be observed, and the
operator cannot be informed about the fault.

The system reactions to face the failure cases are the following:
a) alarm rises on the CPEX for 3 or fewer fans: the FAN object remains in enabled, and
a failure event report with minor severity is generated to LMT. This alarm is queued
for the FAN object. The alarm is automatically cleared as soon as the alarm disappears on the CPEX;
b) alarm rises on the CPEX for more than 3 fans: the FAN object is set into
disabled/failed state, and a failure event report with a critical default severity is
generated to LMT. This alarm is queued for the FAN object. The alarm is automatically cleared as soon as the alarm disappears on the CPEX;
c) the CPEX reveals that the fan box is missing: the FAN object is set disabled/failed,
and a critical alarm, with a different error string from the previous ones, is generated.
Also in this case the Alarm State and the operational state are automatically
restored when the problem disappears.
d) Both CPEX are disabled and/or locked: the CPEX is set into degraded state,
because its alarms cannot be observed. A critical alarm shall be issued to notify the
loss of CPEX functionality. The states and the active alarms of the FAN are frozen,
and they remain as they were in the moment when the CPEXs have been lost, and
cannot be updated, as long as both CPEX remain unavailable.
Since it is not possible for the BSC to survive without the functionality of fans, it is not
possible to lock the FAN object, and so this object does not own the administrative
state. Also the perform test has no sense for the FAN object, because a diagnostic on
the fan is not possible, and this command is not be managed for the FAN.
New MPCC and TDPC processor boards
In BR7.0 release new versions for both MPCC and TDPC processors exist; they are
MPCCV8 and TDPCV7 respectively.
The important thing to be underlined is that with BR7.0 load it is not necessary to replace
MPCC and TDPC processors boards all over the sites; the replacement of these boards
in the BSC becomes necessary only in two specific cases:
1. when the BSC must support TD-SCDMA service (see "1.4.3.1 High Capacity BSC
supporting TD-SCDMA Services");
2. when the IP based O-link must be configured (see "3.73 Management of Links
towards Radio Commander/Cell Broadcast Centre").
In previous cases MPCCV7 and TDPCV6 processors cannot provide the memory to
store the objects and the processing capacity to support the traffic.
As it has been said, new processor boards are the last ones to be considered when it
comes to upgrade with the BR7.0 load a BSC with the new rack . When it comes to
manage new switching matrix and STLP line cards, MPCCV7 and TDPCV6 boards are
still suitable.

30

A30808-X3247-L210-3-7619

Operation
Base Station Controller

1.4.3.1

OMN:BSC

New processor boards can be used in the old rack too. This is required when the O
link is IP based (see "3.73 Management of Links towards Radio Commander/Cell
Broadcast Centre"). However, in this latter case only the MPCCV8 is mandatory: there
are no architectural reasons to enhance both processors at the same time but a mixed
configuration is not simple and it could be prone to error for the operator. So the better
thing is to change both the processors at the same time (to know how to change both
the processors with the minimum system interruption please refer to
"3.14 Hardware/Software Upgrade from BR6.0 to BR7.0 release").

High Capacity BSC supporting TD-SCDMA Services

When the high capacity BSC with new rack is used (see Fig. 1.4.6), and if it is equipped
with both MPCCV8 and TDPCV7 processor boards (see " New MPCC and TDPC
processor boards"), TD-SCDMA services can be configured.

Fig. 1.4.6

High Capacity BSc with New Rack (Frontal View)

TD-SCDMA services regard both TD-SCDMA circuit switched service and TD-SCDMA
packet switched service.

A30808-X3247-L210-3-7619

31

OMN:BSC

Operation
Base Station Controller

For the provision of the TD-SCDMA circuit switched service, PPXX general purpose
Peripheral Processor cards, with an appropriate SW load, are used; in fact the same
card but with a different SW load is used to provide the TD-SCDMA services, taking the
following names:

PPXT stands for PPXX when the card is loaded with TD-SCDMA circuit switched
software; PPXT cards is handled with a N+1 redundancy mode, thereby allowing
high TD-SCDMA capacity together with a certain degree of service availability;

PPXP stands for PPXX when the card is loaded with TD-SCDMA packet switched
software; PPXP is totally equal to PPXU boards (no HW changes) and their redundancy follows the same criteria of PPXU boards: all PPXP instances are used in
Load Balancing, then all PPXP instances will share TD-SCDMA packet traffic. It
must be noted that, as for GPRS with PPXU cards, it is possible to configure only
one PPXP card, giving up the redundancy effectiveness.

The collocation of PPXT and PPXP cards in the rack is flexible so that they can in principle be placed in any free position amongst the 12 possible ones allowed by the expansion frame. Fig. 1.4.7 shows an example of the new rack equipped with PPXT and
PPXP boards.

It is important to underline that peripheral boards related to TD-SCDMA (i.e PPXTs and
PPXPs) can be equipped also maintaining in the BSC some PPXU boards, e.g. to
provide also GPRS/EGPRS services using traditional GSM technology.

Fig. 1.4.7

32

Example of BSC Rack supporting TD-SCDMA

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Regarding the configuration of TD-SCDMA, the following considerations can be drawn:

PPXT cards are present and equipped with a N+1 cold redundancy scheme. The
value of N for the PPXT (NT) shall be in accordance with the following rule:
1 <= NT <= 5
This means that in order to provide TD-SCDMA service, PPXT cards must be at
least 2, in a 1+1 cold redundancy scheme;

PPXP cards can be absent (e.g. because no packet service is required) or, if
present, shall be equipped with a load balancing redundancy scheme. The number
NP of equipped/operating PPXP cards depends from the NT value described above
and shall be in accordance with the following rule:
0 <= NP <= 11 - NT
The operator can configure a single PPXP card (i.e. NP = 1) but in such a case the
load balancing redundancy scheme is not exploited;

the maximum number of TRXTD transceivers per BSC is 364. As a consequence

the maximum number of BTSTD cells (sectors) and the maximum number of
BTSMTD sites per BSC is also 364;

the maximum number of BTSMTD sites per PPXT card is 122;

the total bandwidth for LAPD Abis channels per PPXT card is equal or less than 4
Mbps; this means that at most 64 LAPD Abis channels at 64kbps can be configured
and in that case the maximum number of BTMTD sites per PPXT card is 64. In case
of Multiple LAPD feature, up to 256 LAPD Abis channels at 16kbps are then
supported.

From the requirement of 122 BTSMTD sites per PPXT card, it comes out that the PPXT
configuration, with the maximum number of sites exploiting the maximum available Abis
bandwidth, is 121 as follows:
45 LAPD Abis channels at 64Kbps + 76 LAPD Abis channels at16Kbps
Besides, in order to handle the N+1 redundancy of PPXTs, the TDCU (TD-SCDMA
Control Unit) functional object is introduced: it represents the TD-SCDMA functionality
supported by a single PPXT. Unlikely than the PCU and PCUTD, which due to the load
sharing redundancy are statically associated with the PPXU/PPXP with the same
instance, the N+1 redundancy requires a dynamic association between PPXT and
TDCU. This, besides the fact that the number of equipped PPXT is always different from
the TDCU number, makes convenient to introduce the explicit creation of the PPXT, and
not only of the TDCU.
Tab. 1.4.6 summarizes the maximum figures to be managed by the BSC for TDSCDMA concerning the most significant objects and parameters. The table must not be
seen as an example of allowed configuration because it lists the maximum
instances/values that every object/parameter can assume overall without any relation
each other.
Object/Parameter

Maximum
instances/values

TRXTDs per BSC

364

BTSTDs per BSC

364

BTSMTDs per BSC

364

Tab. 1.4.6 Maximum instances/values for TD-SCDMA

A30808-X3247-L210-3-7619

33

OMN:BSC

Operation
Base Station Controller

Object/Parameter

Maximum
instances/values

BTSMTDs per PPXT card

122

PPXT cards per BSC

TDCUs per BSC

PPXP cards per BSc

10

PCUTDs per BSC

10

LAPD Abis channels per BSC (at 16 Kbps)

1280

LAPD Abis channels per PPXT (at 16 Kbps)

256

Tab. 1.4.6 Maximum instances/values for TD-SCDMA

1.5

Notes on Configuration Procedures

Four groups of commands are necessary for the configuration and modification of
system objects.
The command types, described in the next paragraphs, are the following:

CREATE
DELETE
SET
GET

The user can modify the configuration of the BSS by using configuration commands. It
is possible to add and delete objects, or to modify their attributes according to operators
needs.

1.5.1

Notes on the CREATE commands

The CREATE command is used to add new objects to the system.
There is a hierarchy that the user must follow to create a complete SBS system.
Fig. 1.5.8 shows the creation tree regarding the configuration of the system, when TDSCDMA functionality have not to be configured, whereas Fig. 1.5.9 shows the creation
tree regarding the configuration of objects involved with TD-SCDMA feature.

Remember that TD-SCDMA features can be configured only when the high capacity
BSC with new rack is used, and when both MPCCV8 and TDPCV7 boards are
equipped (see "1.4.3 High Capacity BSC with New Rack").
In both cases, the following configuration rules are valid:

34

objects must be created starting from the root, down to the leaves of the tree;

object deletion must be performed in the opposite order;

the objects on the same line can be created without preconditions.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

EPWR

PPCC

PPXL

PPLD

LICD/LICDS

PCMB

PPCU

PCMS

PCMG

PPXU

PCU

SUBTSLB
TRAU

BTSM

LPDLS

SYNC

NSVC

PCMA
LPDLM

FRL

BTS
SS7L

ADJC

TRX

X25A

OMAL

CBCL

ADJC3G
4

LPDLR

SCA
FHSY

PTPPKF

3
RFLOOP
CHAN
SWIBEAM

1 IN CASE OF DEDL LINK TYPE

2 IN CASE OF AINT LINK TYPE
3 IN CASE OF BBHOPP
4 IN CASE OF SYNHOPP

HIGH CAPACITY BSC

1

CBCL

Fig. 1.5.8

X25D

OMAL

The EPWR does not exist when

the NEW RACK is used, and
STLP, PPXU and PPXL boards
do not depend on EPWR.

Creation Tree without TD-SCDMA Objects

A30808-X3247-L210-3-7619

35

OMN:BSC

Operation
Base Station Controller

PPXL

PPXT

LICD/LICDS

PPXP

TDCU
PCMB

PCMS
PCMG

SUBTSLB

PCUTD

TRAU

BTSMTD

LPDLS

SYNC

NSVC

PCMA
LPDLMTD

FRL

BTSTD
SS7L

ADJCTD

X25A

OMAL

CBCL

TRXTD

LPDLRTD

PTPPKFTD

AIRTSTD

1 IN CASE OF DEDL LINK TYPE

2 IN CASE OF AINT LINK TYPE

CBCL

Fig. 1.5.9

36

X25D

OMAL

Creation Tree for TD-SCDMA related objects

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

After the creation, some objects must be unlocked to put them in service, because they
are created with their administrative state set to LOCK. Other objects are directly
created with the administrative state set to UNLOCK. The following BSC objects are
locked after their creation.
BTS
BTSM
CHAN
TRX
PCMB
SYNE
PTPPKF
SCA
PCMG

PCU
PCMS
SS7L
PCMA
SYNC
NSVC
FRL
RFLOOP
TRAU

BTSTD (*)
BTSMTD (*)
AIRTSTD (*)
TRXTD (*)
PTPPKFTD (*)
PCUTD (*)

(*) Specific TD-SCDMA objects

The objects that must be unlocked after their creation, can be set to UNLOCK even after
the creation of their sons, which will have their operative state set to DISABLE/DEPENDENCY until the father is set to UNLOCK.

1.5.2

Notes on the DELETE Commands

The DELETE command is used to cancel an object, either because it is no longer used
or because it is necessary to change the value of some of its attributes (for some objects
it is impossible to change their parameters using a SET command, but it is necessary to
delete them and to create them again with new attribute values).
Some objects must be locked before entering the DELETE command, other ones are
directly deletable; the following BSC objects have to be locked before deleting them:
BTS
BTSM
CHAN
TRX
PCMB
SYNE
PTPPKF
SCA
PCMG
SCANBTSOHOS
BTSTD (*)
BTSMTD (*)
SCANBTSABISTD
(*)
SCANAIRTSTD (*)

PCU
PCMS
SS7L
PCMA
SYNC
NSVC
FRL
RFLOOP
TRAU
TRACE
PCUTD (*)
PPXT (*)
SCANBTSTDIHDO
(*)
SCANGPRSTD (*)

PPLD
EPWR
CBCL
CTRSCHED
ENVA
LICD
LICDS
SCANBSC
SCANBTS
X25A
AIRTSTD (*)
SCANBTSMTD (*)
SCANBTSTDOHDOI
(*)
SCANTRXTD (*)

SCANBTSE
SCANBTSM
SCANBTSHOI
SCANBTSOHON
SCANCHAN
SCANCTRX
SCANGPRS
SCANSS7L
SCANTRX
SCANFBTSM
TRXTD (*)
SCANBTSTD (*)
SCANBTSTDOHDON
(*)
SCANTRXABISTD (*)

(*) Specific TD-SCDMA objects

A30808-X3247-L210-3-7619

37

OMN:BSC

Operation
Base Station Controller

An object can be deleted only if it is a leaf. So, before deleting an object, the user must
delete all the objects under that node in the creation tree (see Fig. 1.5.8) to make the
object a leaf. There are some exceptions, which may be seen as "implicit deletions. E.g.
the deletion of a BTS object, implicitly delete the corresponding HAND and PWRC
instances, and the deletion of a PCMA object, will delete also all the related TSLA.

1.5.3

Notes on the SET Commands

The SET command is used to modify the attribute values of an object.
Some objects can be modified directly by using this command, others must be deleted
and created again with new settings, in order to change their attributes (for these objects
the SET command do not exist). The following BSC objects can not be set:
PCMA
LPDLM
SYNC
LPDLS
LPDLR

CBCL
SS7L
LPDLMTD (*)
LPDLRTD (*)

(*) Specific TD-SCDMA objects

Some attributes can be modified only if the administrative state of the related object is
set to LOCKED. In this case the user must lock the object to be modified before setting
the value and then unlock the object.
If the user wants to change only a subset of the attributes of an object, he can find out
the value of the attributes which will be left unchanged, displaying them with the GET
command (see 1.5.4). This way the user can create the object again, entering the old
value for the attributes he does not want to modify.
The suggested procedure to be followed, in order to change the setting of an object is:

1.5.4

GET: < Object >

DELETE: < Object >
CREATE: < Object >

Notes on the GET Commands

The GET command displays the attribute values of the specified object.
To obtain the attribute values of an object, the user must identify it, specifying its number
and, if necessary, the number of the objects it is connected to.

38

In general, using of GET commands is suggested to display the current settings of the
data base configuration, before starting the configuration procedures. The same
commands can be used at the end of these procedures in order to verify that the
changes made on the data base have been accepted and correctly set.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The GET command can be used in functional areas other than the configuration (i.e.
areas such as fault and state management, software management etc.) to provide information about the current state/status and, if required, the reached state/status after
some action or procedure performed in that functional area.

1.6

Support of different HW generations of network entities

In general a BTSE equipment is physically composed by several racks of different size;
each rack may be equipped with specific HW boards (LRUs - Least Replaceable Units);
a LRU in turn may consist of several independently configurable circuits (LCUs - Least
Configurable Units).
The modeling approach used to manage these different characteristics is defined
multiple BTSE single rack containment model. It is based on the following assumptions:

a specific BTSE Hardware Managed Object models a BTSE family;

a specific BPORT Hardware Managed Object, available only in some BTSE families,
models the PCM line (see PROC: Addition of a PCMB Line);

a specific XCONNECT Hardware Managed Object, available only in some BTSE

families, models the cross connections (see PROC: BTS Multidrop - Star Cross
Connect);

a specific RACK Hardware Managed Object models the rack of a BTSE family;

a set of specific Hardware Managed Objects model the specific boards and circuits
of a BTSE;

a specific ENVABTSE Hardware Managed Object models the environmental alarms

of a BTSE family;

a specific TEST Hardware Managed Object models a HW test on the boards of a

BTSE family;

a specific LPDLE Hardware Managed Object, available only in some BTSE families,
models multiple LAPD TSs at the BTSE side.

The new presentation of BTSE HW related objects (and TRAU HW object too) at LMT
(when connected to the BSC) is arranged as shown in Fig. 1.6.10.

In BR7.0 release, the BSC can manage BTSE equipment belonging to both BR6.0 and
BR7.0 releases. So when the user is connected to the BSC, and he chooses to work
with a specific BTSE equipment (interworking modality), he has to select, beside the
kind of the equipment, the release it belongs to. The only exception regards the BTSEC
equipment (i.e. the BTSE used for TD-SCDMA functionality) that supports only the
BR7.0 software.

A30808-X3247-L210-3-7619

39

OMN:BSC

Operation
Base Station Controller

Fig. 1.6.10 BTSEs and TRAU hardware objects on the LMT

The different supported BTSE family are the following:
1. BTSE: Siemens 1st generation BTS, i.e. BS20 / BS21E / BS22 / BS60 /BS61E;
exploding the main BTSE object, it is possible to see all the managed objects related
to this equipment (see Fig. 1.11);

Fig. 1.11

40

BTSE containment tree

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

2. BTSEP: BTSplus (Siemens 2nd generation), i.e. BS240 / BS240SR / BS241 /

BS241SR / BS40 / BS41/BS240XS); exploding the main BTSEP object, it is possible
to see all the managed objects related to this equipment (see Fig. 1.12);

Fig. 1.12

A30808-X3247-L210-3-7619

BTSEP containment tree

41

OMN:BSC

Operation
Base Station Controller

3. BTSEPICO: Siemens 2nd generation BS242 (picoBTS); exploding the main

BTSEPICO object, it is possible to see all the managed objects related to this equipment (see Fig. 1.13);

Fig. 1.13

42

BTSEPICO containment tree

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

4. BTSEEM: Siemens 2nd generation BS82 (enhanced micro BTS); exploding the
main BTSEEM object, it is possible to see all the managed objects related to this
equipment (see Fig. 1.14).

Fig. 1.14

A30808-X3247-L210-3-7619

BTSEEM containment tree

43

OMN:BSC

Operation
Base Station Controller

5. BTSEXS: it is the Siemens 2nd generation BS240XS and represents a basic version
of the BTSplus family; exploding the main BTSEXS object, it is possible to see all
the managed objects related to this equipment (see Fig. 1.15).

Fig. 1.15

44

BTSEXS containment tree

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

6. BTSEC: it is the BTSE equipment that supports TD-SCDMA carrier units; by

exploding the main BTSEC object, it is possible to see all the managed objects
related to this equipment (see Fig. 1.16).

Fig. 1.16

BTSEC containment tree

On the LMT panel, there is also the TRAUE object, which allows the user to manage the
hardware and the alarms related to TRAU equipment. Exploding the TRAUE object (by
a double-click on the object), it is possible to see all the managed objects related to this
equipment (see Fig. 1.6.17).

A30808-X3247-L210-3-7619

45

OMN:BSC

Operation
Base Station Controller

Fig. 1.6.17 TRAUE containment tree

When connected to the BSC, the LMT provides two different ways to compose the
commands from its graphical user interface:
1. Default Interworking mode.
2. Network Element selection Interworking mode.
These two different ways are explained in the following.

46

A30808-X3247-L210-3-7619

Operation
Base Station Controller

1.6.1

OMN:BSC

Default Interworking Mode

This is the normal situation: the user connected to BSC is supposed to know in advance
the BTSE type. The user performs an interworking command selecting (by a double
click) either the BTSE type object (BTSE, BTSEP, BTSEPICO and so on) or the TRAUE
object from Input Handler (see Fig. 1.6.10). In this particular case the Input Handler will
load the BTSXX related tree or the TRAUE Tree. The user, therefore, will operate on the
Input Handler as in local connection way to BTS or TRAU. In this situation the resources
available for the Network Elements (BTSE, BTSplus...) will be chosen automatically
from the LMT. Obviously this operation mode could cause wrong commands composition because the resource set loaded from LMT could be not aligned to the actual
Network Element SW version to which the command will be sent.

1.6.2

Network Element selection Interworking mode

With this Interworking mode, the user declares in advance the Network Element
instance where the interworking operations will be performed (e.g. BTSE 5) without
knowing its type. The LMT, from Main Control task (see Fig. 1.6.18), will provide an
automatic mechanism to select a correct LMT Resource Set for the Network Element,
where the Interworking operation will be executed.

Interworking button
Fig. 1.6.18 Main Control Task appearance.
The operator will require to open an "Interworking Section" on a selected Network
Element by clicking on the InterW button (see Fig. 1.6.18); then the NE Selection
Interworking mode window is displayed (see Fig. 1.6.19).

Fig. 1.6.19 NE selection Interworking mode dialog window

A30808-X3247-L210-3-7619

47

OMN:BSC

Operation
Base Station Controller

The Main Control task will get from the selected Network Element (e.g. BTSE: 5) the
Network Element Sw Version. Using this information the correct set of LMT resources
could be loaded, if them are present on the LMT disk. This mechanism will be very useful
when the operator does not known witch Network Element type (e.g. BTSPlus, BTSE,
etc.) is related to a particular instance on BSC. In particular the Dashboard will execute
a GET BTSM for the selected BTS Equipment instance. Using the Expected SW Version
attribute, contained in GET BTSM ACK, the exact SW version, of the BTS, will be found.
This information will be used to select the correct set of resources for the LMT. At this
point the Input Handler task will be automatically forced to work with the new resources.

1.7

Management of Symbolic names

The general target of the Symbolic Names feature is to provide a more comfortable user
interface at LMT by giving the possibility to identify the more significant objects, using
customized mnemonics. These names can be used instead of the complete RDN of the
maintained objects either in command generation and in notification messages. Furthermore, symbolic names can be used not only in the pathname for the concerned objects,
but also in fields of the attribute part in which these objects are addressed.
Symbolic names are unique in all PLMN. This uniqueness is guaranteed within the RC
domain by the RC itself, and across RC domains by the network planning tools.
Symbolic names are used at all user interfaces, i.e. GUI and CLI at RC/LMT, but it is
possible to CREATE or MODIFY them only at RC by an authorized user. Additionally,
they can be logged and used in exported data (e.g. Performance Measurement).
The following services are provided by LMT:

Switch ON/OFF for symbolic names. An internal command is provided in order to

give the operator the possibility to use or not symbolic names in the system;

GET of symbolic name giving as input object class and object instance;

GET of object class and object instance giving as input a symbolic name.

The use of symbolic names at LMT is guaranteed by the system, and no off-line support
is needed. All the previous services provided by LMT are referred to a logged LMT. The
symbolic names data is uploaded from BSC as a part of the LMT logon procedure (only
if the symbolic name file is present in the right directory of the BSC). Once logged-off,
the LMT discards all the symbolic names data related to the previous sessions. Therefore, when the LMT is just plugged-in, but not logged-in (i.e. no operator commands
available but all notifications displayed on the Message Browser) symbolic names
cannot be used or displayed.

1.7.1

Adjacent Cells Identification with Symbolic names

The adjacent cell object (ADJC) represents a particular case regarding Symbolic Names
handling. The ADJC object addressing is composed of two elements: bts# and adjc#.
The bts# represents the cell in which the adjacency is defined. The adjc# represents the
identification number of the ADJC, and by itself does not identify the specific cell onto
which the adjacency is defined.

48

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The ADJC object class contains handover related parameters representing the relation
between one cell and one of its adjacent cells. For these reason, ADJC objects cannot
by themselves have a symbolic name. The CREATE ADJC command doesnt contain
the specific parameters (BSIC, CELLGLID, BCCHFREQ, MSTXPMAXCL) of the target
cell, but the reference to the target cell is set through the targetCell attribute (TGTCELL),
which specifies the RDN (pathname) of the cell onto which the adjacency is being
defined (see PROC: Addition of a New GSM/GPRS/EGPRS Adjacent Cell). This RDN
can be the address of a real cell present in the BSC domain, or the address of a reference (TGTBTS object) to a cell existing outside the BSS domain. The symbolic name
of the ADJC object is therefore that of the TGTCELL attribute.
In the following an example of ADJC object identification with Symbolic Names is given.
Supposing a network configuration like the one shown in Fig. 1.7.20, and an LMT
connected within BSS 1.

Fig. 1.7.20 Adjacent Cell Layout

The CREATE ADJC commands could be the following:
CREATE ADJC:NAME=BTS:MI_CENTRO/ADJC:0, ... ,TGTCELL=BTS:MI_SUD;
CREATE ADJC:NAME=BTS:MI_CENTRO/ADJC:1, ... ,TGTCELL=BTS:MI_EST;
CREATE ADJC:NAME=BTS:MI_EST/ADJC:0, ... ,TGTCELL=BTS:MI_SUD;
CREATE ADJC:NAME=BTS:MI_EST/ADJC:1, ... ,TGTCELL=BTS:MI_CENTRO;

A30808-X3247-L210-3-7619

49

OMN:BSC

Operation
Base Station Controller

CREATE ADJC:NAME=BTS:MI_SUD/ADJC:0, ... ,TGTCELL=BTS:MI_CENTRO;

CREATE ADJC:NAME=BTS:MI_SUD/ADJC:1,...,TGTCELL=BTS:EXT_MI_OVEST
where for instance:
MI_CENTRO=BSS:1/BTSM:0/BTS:0
MI_EST=BSS:1/BTSM:0/BTS:1
MI_SUD=BSS:1/BTSM:0/BTS:2
EXT_MI_OVEST=BSS:1/TGTBTS:0

1.7.2

In order to comply with the uniqueness of symbolic names over the whole PLMN, the
names of TGTBTS objects cannot be the same as those of the referred BTS objects
belonging to another BSS domain.

LMT handling of Symbolic Names

Symbolic names are uploaded by LMT automatically as soon as the following conditions
are both true:
1. a successful logon has been accomplished with the BSC (see Fig. 1.7.21);
2. the Symbolic Names switch (button on the LMT Dashboard) is turned on (i.e. turned
to Sym On, see Fig. 1.7.21).

LMT is logged to the BSC

SavSym button

Symbolic Names switch button

Fig. 1.7.21 LMT Control Center window (the LMT is Logged)

The upload of symbolic names is performed through the GET BSC SYM command. This
command is not a CLI (i.e. MML) one, and it is submitted internally by the LMT Dashboard. The destination task on BSC is a dedicated task, the BSC Symbolic Names
Handler, which, triggered by the above GET message, reads the symbolic names file on
the BSC disk and issues a response message (GETACK BSC SYM message)
containing the compressed symbolic names file in the data part.

50

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The (compressed) symbolic names files are downloaded from the RC to the BSC; a
directory called SYMBNAME is created for this purpose under the root of the BSC disk.
The symbolic names file is called NAMES.SZ. Upon reception of the LMT request, the
BSC Symbolic Names Handler checks for the presence of the file. If the file is not
present on the BSC disk, a GETNACK BSC SYM response is issued towards the local
terminal, and symbolic names are not used during the current session.The presence
and update of the symbolic names file on the BSC disk are under control of RC (master
role). It is worth noting that both BSC and LMT are passive entities (slave role) as far as
these operations are concerned.
During an LMT session, only the symbolic names uploaded from the BSC can be used,
and these cannot be modified in any way by the operator. Besides, symbolic names can
be saved in user-defined files through the SavSym button (see Fig. 1.7.21). This files
are saved in ASCII (i.e. uncompressed) format; they have extension .SIM.
User-defined symbolic names files can be loaded through the SetSym button only on an
unlogged LMT (see Fig. 1.7.22). The files are then used in order to perform off-line
activities, such as the development of scripts.
LMT is off-line

SetSym button

SYM button

Fig. 1.7.22 LMT Control Center (the LMT is Unlogged)

When symbolic names are used, both in the logged-on and off-line modes, the SYM
button on the Dashboard (see Fig. 1.7.21 and Fig. 1.7.22) starts the Symbolic Names
Browser, which allows the following queries on the symbolic names data base (see
Fig. 1.7.23):
Get Instance from Symbol
Get Symbol from Instance
Get Symbol from Path
Get Path Name from Symbol
Get Symbol List from Class

A30808-X3247-L210-3-7619

Returns a pair <class, instance> given a symbolic

name.
Returns a symbolic name given a pair <class,
instance>
Returns a symbolic name given a pathname.
Returns a pathname given a symbolic name.
Returns the list of symbolic names of all the objects
of a given class

51

OMN:BSC

Operation
Base Station Controller

Fig. 1.7.23 Browse Symbolic name panel

1.8

Software Management
The SW-management area is based on the GSM specifications, so that every procedure
involving SW entities (i.e. download of files on BSC disk, change software version, BSC
bring-up or initialization, etc.) can be carried on by: creating/deleting object instances,
setting/getting their attributes, triggering the actions they provide.
To reach this scope, three main classes have been identified:

operatingSoftwareUnit (OSU);

executableSoftwareUnit (ESU);

replaceableSoftwareUnit (RSU).

The objects defined for SBS system are obtained by inheritance from the previous ones.
Tab. 1.8.7 shows the SBS managed objects, which are derived for each class.
OSU

ESU

RSU

BSCOSUSW

BSCESUSW

RSUSWLH

BSCOSUDB

BSCESUDB

RSUEXE

BTSMOSUSW

NEYESUSW

RSUDB

TRAUOSUSW

RSUPCH

BTSMTDOSUSW (only for

TD-SCDMA base stations)
Tab. 1.8.7 Object classes
In the following, these classes are described bottom-up, that is starting from the smallest
elements. Then the hierarchical relation between classes is described.

52

A30808-X3247-L210-3-7619

Operation
Base Station Controller

1.8.1

OMN:BSC

Replaceable Software Unit Class (RSU)

An instance of this managed object class is used to represent a unit of software that
needs to be separately identifiable and/or replaceable on the system. An RSU is the
smallest element in a SW-related entity, with a one-to-one relation to a disk file. Thus,
RSUs identify a SW Load Header file, a single executable file, a VAM file, a single patch
or a database file.
The relatedFiles (RELF) attribute of this object class contains the complete path, on the
BSC disk, of the physical file that is in one to one correspondence to this unit.
As shown in Tab. 1.8.7, specific classes, derived from the main one, are used for
different set of files:

1.8.2

RSUSWLH for SW Load Headers;

RSUEXE for executable files and VAM files;
RSUPCH for patch files;
RSUDB for database files.

Executable Software Unit Class (ESU)

An instance of this managed object class is used to represent a complete set of RSUs
that can be used in SW handling operations. The ESUs can be seen as a rough equivalent of the disk directories where the SW loads were stored.
Anyway, SW files and database files are no more kept together. In fact, three different
types of ESUs are provided:

BSCESUSW for BSC SW loads;

BSCESUDB for BSC databases;
NEYESUSW for SW loads related to BTSE/BTSEC/TRAU equipment.

The relation ESU--->RSU is maintained using the relatedRSU attribute (RELRSU), that
shows:

the object identifier of the related RSUSWLH, in case of both BSCESUSW and
NEYESUSW;

the object identifier of the related RSUDB; in case of BSCESUDB.

The OperationalState of an ESU instance is used to indicate if the SW entity it represents is usable or not in loading procedures. In particular, a BSCESUDB is enabled if
the related RSUDB is enabled. A BSCESUSW or a NEYESUSW is enabled if the
related RSUSWLH and all the RSUs that it must contain, in order to be complete, are
present and enabled.

1.8.3

Operating Software Unit Class (OSU)

An instance of this managed object class is used to represent the operating software
resource for an instance of equipment or functionality and is associated with the related
equipment or functional unit through containment. OSU objects are used to identify
which ESUs are operational, that is in some way (maybe only potentially) involved in SW
operations.

A30808-X3247-L210-3-7619

53

OMN:BSC

Operation
Base Station Controller

A BSC contains two OSU instances, one for the SW (BSCOSUSW) and one for the
database (BSCOSUDB). The attributes runningESU, backupESU, newESU and fallbackESU indicate the BSCESUSW/BSCBESUDB that, respectively:

are currently running (runningESU);

will be loaded at the next BSC reload (backupESU);

will be used in the next change version procedure (newESU);

will be used for restoring the backup BSCESUSW/BSCESUDB instance (fallbackESU).

Every BTSM, BTSMTD or TRAU equipped object contains a OSU object too, i.e.:

TRAUOSUSW in case of TRAU equipment;

BTSMOSUSW in case of GSM base stations;
BTSMTDOSUSW in case of TD-SCDMA base stations (i.e. BTSECs).

The attributes newESU and fallbackESU are not used for BTSMOSUSW/
BTSMTDOSUSW and TRAUOSUSW objects. The attributes runningESU and
backupESU of these OSUs indicate the NEYESUSW running and the expected one for
that NEy.
A more detailed explanation of OSU attributes is given in the following, for each one of
the object class.

1.8.3.1

BSCOSUSW
The BSCOSUSW instance is related to the BSC SW loads present on BSC disk. This
object class is characterized by the following attributes:
1. runningESU (RUNESU): indicates which BSCESUSW is currently running,
2. backupESU (BCKUPESU): indicates which BSCESUSW will be loaded at next
system restart
3. newESU (NEWESU): indicates which BSCESUSW will be used in the next change
version operation.
4. fallbackESU (FALLBESU): it is used for restoring the backup BSCESUSW.
5. LoadUsageState: it is used to identify the current loading phase. It can assume the
following values:
idle

loadBackupESUsw

loadNewESUsw

waitForAcceptNewESUsw

54

this is the default value for the system and the BSC application is waiting for a user command; all the commands are
allowed with the exception of end of change version or rollback
the BSC application is executing a backup sbsBscESUsw
loading procedure due to a load system, a rollback or a
sysinit (BRING-UP level) procedure.
he BSC application is executing a system loading of all
processors due to a change version procedure with MPCC
processor involved in the loading procedure or a change
version procedure without MPCC processor involved in the
loading procedure.
the change version procedure is ended and the BSC application is waiting for another user command; only end of
change version or rollback commands are admitted

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

acceptNewESUsw
oadBackupESUdb
loadNewESUdb
systemInit
saveDbInProgress:

1.8.3.2

he BSC application is executing an end of change version

procedure
the BSC application is executing a database loading of backupESU
the BSC application is executing a database loading of
newESU
the BSC application is executing a system initialisation of level
FULL, TASK_PRIME or TASK_SPARE
the BSC application is executing a database saving

BSCOSUDB
The BSCOSUDB instance is related to the database present on BSC disk. This object
class is characterized by the following attributes:
1. runningESU (RUNESU): indicates which BSCESUDB is currently running,
2. backupESU (BCKUPESU): indicates which BSCESUDB will be loaded at next
system restart
3. newESU (NEWESU): indicates which BSCESUDB will be used in the next change
version operation.
4. fallbackESU (FALLBESU): it is used for restoring the backup BSCESUDB.

1.8.3.3

BTSMOSUSW - TRAUOSUSW - BTSMTDOSUSW

The BTSMOSUSW/BTSMTDOSUSW/TRAUOSUSW instances are related to the
BTSE/BTSMTD/TRAU SW loads present on BSC disk and loaded on
BTSE/BTSMTD/TRAU network entities.

BTSMTDOSUSW regards the software load used for TD-SCDMA base stations, that
are called BTSEC (BTSE for China).
This object class is characterized by the following attributes:
1. runningESU (RUNESU): indicates which NEYESUSW is currently running,
2. backupESU (BCKUPESU): indicates which NEYESUSW will be loaded at next
system restart,
3. Phase (PH): it is used to identify the current loading phase. It can assume the
following values:
idle
downloadNE
activateNE
alignNE

1.8.4

this is the default value for the system

the BSC application is downloading a BTSE/BTSMTD/TRAU
SW load to one or more network entities;
the BSC application is activating a particular
BTSE/BTSMTD/TRAU SW load
the BSC application is aligning a particular
BTSE/BTSMTD/TRAU SW load

Hierarchical Structure
In the following figures, the different relations among the defined objects are shown,
together with a brief explanation of their peculiarities.

A30808-X3247-L210-3-7619

55

OMN:BSC

Operation
Base Station Controller

A very important thing to notice is the difference between black and white arrows: the
former ones represent pointing relations between objects by means of attributes,
whereas the latter ones represent inclusion relations. In other words, the black arrows
are the logical links among the objects, and the white arrows represent the logical
addresses within the BSC object. Thus, the various addressing levels can be seen.
Fig. 1.8.24 shows the relation among BSC software objects

Fig. 1.8.24 Relation among BSC software objects

The four black arrows originating from the BSCOSUSW object represent the four OSU
attributes runningESU, backupESU, fallbackESU and newESU pointing to one ESU
object each. Their names clearly indicate the functional role of the pointed ESU object.
The black arrow originating from the BSCESUSW indicates the Related RSU attribute
pointing to the related RSUSWLH
Besides, it can be noted that:

the OSU instance is directly contained in the BSC object;

the ESU instances are directly contained in the BSC object;

regarding RSU instances, it can be noted that:

RSUSWLH instances are contained in the BSC object (first-level addressing
inside the BSC)

56

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

RSUEXE instances are contained in the corresponding RSUSWLH object

(second-level addressing inside the BSC);
RSUPCH are directly contained in the corresponding RSUEXE object (third-level
addressing inside the BSC);
Similarly, Fig. 1.8.25 shows the scheme for database objects.

Fig. 1.8.25 Relation among BSC database objects

Please notice that neither RSUEXE nor RSUPCH exist, meaning that all objects own
only one level of addressing (i.e. they need just one white arrow to be reached from the
BSC object). No difference with the previous case exists as regards the black arrows
(pointing relations).
The case for the generic network element is depicted in Fig. 1.8.26 (the Btsmtd object,
used for TD-SCDMA, follows the same rule of the analogous Btsm object). As Btsm and
Trau are functional entities of the BSC object, the containing relation is explicitly shown.
This leads to a different position of the Btsm/TrauOSUSW objects, whereas nothing
changes for ESU and RSU objects, in order to preserve the previously described way of
addressing, as well as to keep their scope unchanged within the BSC. Another important
difference with the first case described regards the OSU attributes: they are now two
instead of four, being fallbackESU and newESU missing.
Please notice that the relatedESU attribute always appears with the same functional
meaning, that is, it represents the set of RSU objects (physical files) that constitute the
load associated with a particular Executable Software Unit (directory).

A30808-X3247-L210-3-7619

57

OMN:BSC

Operation
Base Station Controller

Fig. 1.8.26 Relation among BTSM/TRAU software objects

1.9

Attribute Groups
Attribute groups are introduced on the GUI panels at LMT.
The effect of attribute groups on the GUI panels is to collect attributes of large objects
into different folders, whose meaning is already known by the user since previous
releases. The names used for attribute groups are aligned as much as possible to the
names of old object packages, to avoid discontinuities from the customer point of view.
Attribute groups are defined and used for the GET, SET and CREATE commands, and
for the related responses; this groups permits to gather attributes of the previous objects
into sections.
The definition of attribute groups relies on the following rules:
1. attribute groups can be defined in different contexts (i.e. different messages / object
classes) using the same name. For instance, attribute group TIMER collects either
the BSC or the BTS timer attributes. On the other hand, an attribute used by different
messages of the same object class must always be defined in the same attribute
group;
2. for the listed objects, the following groups are defined:

58

Object

Groups

BSC

BASICS, CONTROL, ALARMSEV, TIMER

BSCE

BASICS, REMINV

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

BTS

BASICS, CCCH, INTERF, OPTIONS, TIMER

HAND

BASICS, DATA

OPC

BASICS, MTL2, MTL3

SCA

BASICS, NMDL, EICM

BTSTD

BASICS, CCCH, OPTIONS, TIMER

TRAU

BASICS, TIMER

PCMA

BASICS, PCM30, PCM24

PCMB

BASICS, PCM30, PCM24

PCMG

BASICS, PCM30, PCM24

PCMS

BASICS, PCM30, PCM24

3. in all cases not explicitly specified above, all object classes will provide a single
BASICS attribute group as a default.
The common MML syntax for GET commands will be the one sketched by the following
examples (BTS object):

GET BTS : NAME = BTS:0, REQATTL = MSTXPMAX & HOPP;

In this command, only the MSTXPMAX and HOPP attributes are requested to the
BTS (using the requested attribute list - REQATTL- parameter, and therefore have
to be shown in the response. Note that the chosen attributes are belonging to two
different attribute groups.

GET BTS : NAME = BTS:0;

In this command, the absence of attributes means that all BTS attributes are
requested and therefore have to be reported in the response.

GET BTS BASICS : NAME = BTS:0;

In this command, all the attributes belonging to the BASICS attribute group are
requested to the BTS. This command does not allow to specify more than one
attribute group. This case is handled by defining a hidden (i.e. not visible to the operator) REQATTL attribute, having as default value the list of attributes belonging to
the BASICS attribute group.

The T-interface GET command does not specify a list of required attributes, and the
GET response always reports all attributes of a given object. Therefore, the handling of
REQATTL attribute has to be performed internally at LMT. In particular, REQATTL
attribute provides a filter for the message response, so that only the requested attributes
are shown to the user. Thus, the list of selected attributes must be stored within the local
terminal until the response is received (or until the job expires) and a link must be kept
between the GET request and the GET response (e.g. at job level).
Moreover, as it was described, for all object classes containing more than one attribute
group, in addition to the general GET <OBJECT> command, further distinct GET
<OBJECT> <GROUP> commands are defined (one per attribute group). Each of them
will include a hidden REQATTL attribute, specifying the list of attributes belonging to the
related attribute group. This information is used by the application to perform a filtering
in the response as in the general case.

A30808-X3247-L210-3-7619

59

OMN:BSC

Operation
Base Station Controller

To summarize, for managed objects containing more than one attribute group (i.e. BSC,
BSCE, BTS, HAND, etc), the following consideration can be done:
1. when the user creates a new instance of objects, he finds the attributes grouped
according to their attribute groups (see previous table). For example, Fig. 1.9.27
shows the LMT panel related to the CREATE BTS command. The attributes are
grouped into five groups: BASICS, CCCH, INTERF, OPTIONS, TIMER.
2. when the user wants to retrieve the attribute values, he can choose:
to use the GET <OBJECT> command, (e.g. GET BTS command); in this case
the user, making use of the REQATTL parameter, can get values of attributes
belonging to different groups;
to use the GET <OBJECT> <GROUP> command; in this cae the user gets all
the attribute values belonging to a specific group; for example, for the BTS object
the following commands are allowed:
GET BTS BASICS
GET BTS CCCH
GET BTS INTERF
GET BTS OPTIONS
GET BTS TIMER

Fig. 1.9.27 Input Handler - Panel related to CREATE BTS command

Instead, for managed objects not involved in the attribute groups feature, the following
considerations can be done:
1. when the user creates an instance of these objects, he finds the BASICS group only,
and all the attributes are contained in this group. For example Fig. 1.9.28 shows the
LMT panel related to the CREATE BTSM command (the BTSM is not involved in
the attribute groups feature).
2. when the user wants to retrieve the attribute values, he can choose:

60

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

to use the GET <OBJECT> command, (e.g. GET BTSM command); in this
case the user can exploit the REQATTL parameter to get a narrow number of
values;
to use the GET <OBJECT> <BASICS> command; in this case all the attribute
values are retrieved.

Fig. 1.9.28 Input Handler - Panel related to CREATE BTSM command.

A30808-X3247-L210-3-7619

61

OMN:BSC

Operation
Base Station Controller

2 Tasklist

i
2.1
1
2

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

2.3
1
2

2.4
1
2
3
4

62

For the description and validity range of all input parameters, please refer to BSC
Command Manual.

General Use
BSS Addressing Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.1
Date-Time Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.2

Software Management
BSC "Bring-Up" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MPCC Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSC Reload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSC Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Download of a SW Load Header File on BSC Disk . . . . . . . . . . . . . . . . . . . . . . . . . .
Download of a database file on BSC disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Download of a Single Executable File on BSC Disk . . . . . . . . . . . . . . . . . . . . . . . . .
Download of a Patch File on BSC Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deletion of Files from BSC Disk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting the attributes of RSUSWLH, RSUDB, RSUEXE and RSUPCH objects . . . .
Getting the attributes of BSCESUSW, BSCESUDB, and NEYESUSW objects . . . .
Changing the User Label for SW load header/database files . . . . . . . . . . . . . . . . . .
Loading Patch Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling a Patch File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unloading Patch Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Information about SW Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting a Generic SW Load as Backup, Fallback or New SW Load . . . . . . . . . .
Loading a Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting a Generic Database as Backup, Fallback or New Database . . . . . . . . .
Saving Database Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Download and Activate BTSE, BTSEC and TRAU SW Loads . . . . . . . . . . . . . . . . .
Update of the Software Load within the BR7.0 Release . . . . . . . . . . . . . . . . . . . . . .
Hardware/Software Upgrade from BR5.5 to BR7.0 Release . . . . . . . . . . . . . . . . . . .
Hardware/Software Upgrade from BR6.0 to BR7.0 release . . . . . . . . . . . . . . . . . . .
Upload of a Database File from BSC Disk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PROC: 3.3
PROC: 3.4
PROC: 3.15
PROC: 3.27
PROC: 3.5
PROC: 3.6
PROC: 3.7
PROC: 3.8
PROC: 3.9
PROC: 3.10
PROC: 3.11
PROC: 3.17
PROC: 3.18
PROC: 3.19
PROC: 3.20
PROC: 3.21
PROC: 3.22
PROC: 3.23
PROC: 3.24
PROC: 3.25
PROC: 3.26
PROC: 3.12
PROC: 3.13
PROC: 3.14
PROC: 3.16

System Disk Management

System Disk Formatting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.32
System Disk File and Directory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.33

Fault Management
Object State Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Object Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Peripheral Processors Failure during Bring-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signalling Link Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PROC: 3.34
PROC: 3.35
PROC: 3.36
PROC: 3.37

A30808-X3247-L210-3-7619

Operation
Base Station Controller

2.5

Configuration Management

2.5.1

GSM Specific Procedures

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

Addition of a New Site Manager and of related LAPD links . . . . . . . . . . . . . . . . . . . .

Addition of a BTS (Cell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a FHSY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a Frequency to FHSY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deletion of a Frequency from FHSY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a Point-to-Point Packet Function (GPRS/EGPRS) . . . . . . . . . . . . . . . . . .
Deletion of a Point-to-Point Packet Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a Packet Control Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deletion of a Packet Control Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disabling Frequency Hopping for a BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Frequency Hopping for a BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a TRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling/Disabling GPRS service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling/Disabling EGPRS service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling/Disabling GPRS CS3-CS4 coding schemes . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Link Adaptation for GPRS and EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deletion of a TRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting a TRX in Emergency Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a Radio Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Smooth Channel Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a New GSM/GPRS/EGPRS Adjacent Cell . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a New GSM/GPRS/EGPRS External Cell . . . . . . . . . . . . . . . . . . . . . . . .
Definition of the Signalling Point Code (only for standard BSC) . . . . . . . . . . . . . . . . .
Deletion of a BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handover Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of Handover for Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of Handover with Level Handover Margin parameter . . . . . . . . . . . . .
Management of Fast Uplink Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of the Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hierarchical Cell Structure Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Directed Retry Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concentric Cell Structure Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HSCSD Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voice Group Call Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voice Broadcast Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling enhancements in ASCII services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Cell Load Dependent Activation of HR Channels . . . . . . . . . . . . . . . . . . . .
Enabling Enhanced pairing for TCH/H channels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of Radio Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VAD/DTX and Comfort Noise for Half Rate Speech . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of Adaptive Multirate Codec (AMR) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Location Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a New UMTS Adjacent Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring separate BA lists for Idle and Active state . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Handover from UMTS to GSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling GSM-UMTS cell Selection/Re-selection . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Handover from GSM to UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling CTM Circuit Pool Solution for Text Telephone Calls . . . . . . . . . . . . . . . . . .
Queueing, Preemption and Directed Retry for TCH . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Antenna Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of Transmission Diversity with Time Delay . . . . . . . . . . . . . . . . . . . . . .

A30808-X3247-L210-3-7619

OMN:BSC

PROC: 3.39
PROC: 3.41
PROC: 3.42
PROC: 3.43
PROC: 3.44
PROC: 3.47
PROC: 3.48
PROC: 3.51
PROC: 3.52
PROC: 3.55
PROC: 3.56
PROC: 3.57
PROC: 3.58
PROC: 3.59
PROC: 3.60
PROC: 3.61
PROC: 3.62
PROC: 3.63
PROC: 3.64
PROC: 3.65
PROC: 3.66
PROC: 3.67
PROC: 3.75
PROC: 3.77
PROC: 3.78
PROC: 3.79
PROC: 3.80
PROC: 3.81
PROC: 3.85
PROC: 3.88
PROC: 3.92
PROC: 3.93
PROC: 3.97
PROC: 3.99
PROC: 3.100
PROC: 3.101
PROC: 3.102
PROC: 3.103
PROC: 3.104
PROC: 3.106
PROC: 3.110
PROC: 3.113
PROC: 3.68
PROC: 3.69
PROC: 3.82
PROC: 3.83
PROC: 3.84
PROC: 3.96
PROC: 3.98
PROC: 3.114
PROC: 3.115

63

OMN:BSC

52
53
54

2.5.2
1
2
3
4
5
6
7
8
9
10
11
12
13
14

2.5.3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

2.6
1
2

64

Operation
Base Station Controller

Management of Four Branch Receive Diversity/Switched Beam Functionality . . . . . PROC: 3.116

Enabling the Emergency Setup 2 message for emergency calls in GSM-R . . . . . . . PROC: 3.117
Enabling/Disabling GPRS Traffic Control Management . . . . . . . . . . . . . . . . . . . . . . PROC: 3.118

TD-SCDMA Specific Procedures

Addition/Deletion of a TD-SCDMA Control Unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a TD-SCDMA New Site Manager and of Related LAPD Links . . . . . . . .
Addition/Deletion of a TD-SCDMA Cell (BTSTD) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition/Deletion of a TD-SCDMA Transceiver (TRXTD) . . . . . . . . . . . . . . . . . . . . .
Addition/Deletion of a TD-SCDMA Air Timeslot. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Dynamic Channel Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition/Deletion of a Packet Control Unit for TD-SCDMA . . . . . . . . . . . . . . . . . . . .
Addition/Deletion of a Point-to-Point Packet Function (GPRS) for TD-SCDMA . . . .
Addition of a New Adjacent Cell for TD-SCDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a New TD-SCDMA/GSM External Cell . . . . . . . . . . . . . . . . . . . . . . . . . .
TD-SCDMA Handover Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of the TD-SCDMA Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TD-SCDMA Directed Retry Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HSCSD Service in TD-SCDMA System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PROC: 3.119
PROC: 3.120
PROC: 3.121
PROC: 3.122
PROC: 3.123
PROC: 3.124
PROC: 3.125
PROC: 3.126
PROC: 3.127
PROC: 3.128
PROC: 3.129
PROC: 3.130
PROC: 3.131
PROC: 3.132

GSM and TD-SCDMA Common Procedures

Addition of a PPLD (only for standard BSC) and a LICD Board . . . . . . . . . . . . . . . .
Addition of a PCMB Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration of the Abis interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a Network Service Virtual Connection . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deletion of a Network Service Virtual Connection . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a Frame Relay Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deletion of a Frame Relay Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a PCM line in G interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deletion of a PCM line in G interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a PCM Line A-sub interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a TRAU to the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addition of a PCM Line A Interface and SS7 Link . . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of Links toward Radio Commander/Cell Broadcast Centre . . . . . . . . .
Setting the External/Free Run Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling/Disabling of the Emergency Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Barring the Access to a Cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definition and Activation of Environmental Alarms . . . . . . . . . . . . . . . . . . . . . . . . . .
Deletion of an External Alarm for a BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSC Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sleeping Cell Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circuit Pool Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creation and Handling of Inventory File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BTS Multidrop - Star Cross Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NUC within TRAU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NUC within BSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support of Satellite Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.4 kbit/s Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PROC: 3.74
PROC: 3.38
PROC: 3.40
PROC: 3.45
PROC: 3.46
PROC: 3.49
PROC: 3.50
PROC: 3.53
PROC: 3.54
PROC: 3.70
PROC: 3.71
PROC: 3.72
PROC: 3.73
PROC: 3.76
PROC: 3.86
PROC: 3.87
PROC: 3.89
PROC: 3.90
PROC: 3.91
PROC: 3.94
PROC: 3.95
PROC: 3.105
PROC: 3.107
PROC: 3.108
PROC: 3.109
PROC: 3.111
PROC: 3.112

Data Base Management

Usage of tools for database management (DBAEM and CONVFILE tools) . . . . . . . PROC: 3.133
Different Release Data Base Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.134

A30808-X3247-L210-3-7619

Operation
Base Station Controller

2.7
1
2
3
4

2.8
1
2
3
4
5
6
7
8
9
10
11
12
13

2.9
1
2
3

2.10
1
2

2.11
1

OMN:BSC

Log files management

Upload of BSC Log File from LMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Upload of a TRAU Log File from LMT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Upload of a BTSE Log File from LMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Decoding Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PROC: 3.28
PROC: 3.29
PROC: 3.30
PROC: 3.31

Measurements Management
Creation of a Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creation of a SCANAIRTSTD object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requesting the Current Measurement Values of a Scanner Job . . . . . . . . . . . . . . . .
Upload of the Measurement Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing Attributes of a Measurement Campaign . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Info Report Scan Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Performance Measurements Based on Enhanced Measurement Reports .
Management of Trace Measurement Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Info TRACE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Activation and Deactivation of a Cell Traffic Recording . . . . . . . . . . . . . . . . . . . . . . .
Enabling/Disabling Measurements to Get Smart Carrier Allocation . . . . . . . . . . . . . .
Upload of Smart Carrier Allocation Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . .
Management of Online RF Loop Back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PROC: 3.135
PROC: 3.136
PROC: 3.137
PROC: 3.138
PROC: 3.139
PROC: 3.140
PROC: 3.141
PROC: 3.142
PROC: 3.143
PROC: 3.144
PROC: 3.145
PROC: 3.146
PROC: 3.147

Configuration Interworking Procedures

Creation or Deletion of a Remote Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.148
Modification of Some Attributes of a Remote Object . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.149
Obtaining the Attributes of a Remote Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.150

Fault & State Interworking Procedures

Object State Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.151
Stop Transmission of BTS Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.152

Test Interworking Procedures

Test Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC: 3.153

A30808-X3247-L210-3-7619

65

OMN:BSC

Operation
Base Station Controller

3 Procedures
The following pages describe the procedures.

66

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.1

OMN:BSC

BSS Addressing Management

Introduction
This procedure allows to manage the BSS addressing.
On the O-Interface, the addressing is in the global form. The global containment tree
is very simple; it includes:

the global root;

and, as subordinate object, the sbsManagedElement Managed Object Class. This
class represents the entry point of addressing of the BSS.

So, on the LMT input handler, an object class is introduced to manage BSS addresses,
and it is called MEL (i.e. Managed Element).
The MEL object class manages the following attributes:
1. managedElementId (MELID): it is used for naming and identify the BSS number. Up
to 48 elements (range 0...47) can be managed by an OMC;
2. version (VER): identifies the Information Model version; the version attribute is an inmemory attribute directly handled by system, and the stored information becomes
invalid when the system detects a new information model version value;
3. externalTime (ETIME): indicates the Time&Date of the whole BSS.
The unique instance (instance number 0) of the MEL object class is inherently created
during every MPCC data base loading (in particular at Bring Up time). The instance
number is created according to the configuration data stored in the database file. In case
the database file is not present, it is created with managedElementId equal to 0 (this
value may be changed only by LMT at Bring Up time).
The user is able to make two types of operations regarding the MEL object instance:

to set its attributes;

to get its attributes.

When setting the attributes the user can change:

!
!

the BSS number, i.e. the MELID attribute;

the time and date of the BSS using the ETIME attribute.

The user in not allowed to change both the attributes at the same time.
After having changed the MELID parameter, it is necessary to save and load the BSC
database, to activate correct modify for Radio Commander alignment. The database
loading may be done during the BSC Bring Up or using the related command.
When getting the attributes the user can see:

the actual BSS number;

the time and date of the BSS;
the Information Model version (in fact it is a read only parameter).

The Date&time management is described in "3.2 BSS Date-Time Management".

Prerequisites
The user must have the visibility level set to number "2".
The Network Element must be in phase "2".

A30808-X3247-L210-3-7619

67

OMN:BSC

Operation
Base Station Controller

Preliminary Consideration

h ... 2
h ... 3

Do you want to set the BSS address?

Do you want to display the BSS address?

Set the BSS address

To set the BSS address, the user must enter the SET MEL command following
the next sequence of selections:

MANAGED-ELEMENT ---> MEL ---> SET MEL

Then he must fill in the MELID attribute.

h ... END

Result: the BSS address is set.

Display the BSS address

To get the BSS address, the user must enter the GET MEL command following
the next sequence of selections:

MANAGED-ELEMENT ---> MEL ---> GET MEL

Result: the BSS address is shown.

END

68

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.2

OMN:BSC

BSS Date-Time Management

Introduction
These procedures allow to manage date and time of the BSC. Using this commands the
LMT manages the calendar (time and date) of the system.
The BSS time & date is provided to the TRAU by the BSC via the Asub interface. Since
the TRAU does not calculate date and time in its hardware, the feature is managed
entirely by the software.
When the TRAU is connected to the BSC, its time & date is kept synchronized with the
time & date of the BSC. If the link is disconnected, the TRAU autonomously continues
to manage the time & date until the link is re-established; at that moment, the time is
synchronized again.
The BSS Date and Time management is performed using the MEL object, introduced to
manage the BSS addressing (see "3.1 BSS Addressing Management"). The user is able
to set or to display the BSS Time&Date across the ETIME (externalTime) attribute.

Using the LMT dashboard, when the PC time is modified, the NE time is also modified,
and, when submitting the GET MEL command, the NE time is set back to the original
MEL time.
This is the only way that the NE time is reset correctly.
Besides, the LMT date range is narrower than BSC range: the LMT restriction on the
date is due to the win32 API that cannot support dates greater than 01/19/2038. So if
you set a date after 01/19/2038 (using the SET MEL command) and then you retrieve it
(using the GET MEL command) the two dates will be different.
Prerequisites
The user must have the visibility level set to number "2".
The Network Element must be in phase "2".

Preliminary Consideration
Do you want to set BSS Date&Time?
Do you want to display BSS Date&Time?

h ... 2
h ... 3

Set the BSS calendar

To set the BSS Date&Time, the user must enter the SET MEL command
following the next sequence of selections:

MANAGED-ELEMENT ---> MEL ---> SET MEL

Then he must fill in the ETIME attribute.

Result: the BSS Time or Date changes.

A30808-X3247-L210-3-7619

h ... END

69

OMN:BSC

Operation
Base Station Controller

Display the BSS calendar

To get the BSS address, the user must enter the GET MEL command following
the next sequence of selections:

MANAGED-ELEMENT ---> MEL ---> GET MEL

Then using the REQATTL parameter, he must select the ETIME attribute.
Result: the internal BSS Time and Date are shown.

END

70

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.3

OMN:BSC

BSC "Bring-Up"
Introduction
The "Bring-Up" performs system initialization. The system is set to the proper initial
state, to correctly run under the Operating System. During this phase, all the system
processors are loaded with the required Software Version.
The procedure is fully automatic and, once activated, it can only be interrupted by
another Bring-up request.
It provides the load of both the executable software and database; the main source for
loading is from the disk placed on the MPCC board; during the first BSC installation (i.e.
when the disk is empty), the MPCC load can be done from LMT.
Prerequisites
The BSC Bring Up process takes place in dedicated mode and the system cannot do
any other function except for loading.

Automatic Bring-Up procedure

The user should not perform any procedures until the "Bring-Up" is ended.

END

A30808-X3247-L210-3-7619

71

OMN:BSC

Operation
Base Station Controller

3.4

MPCC loading
Introduction
The MPCC executable loading is automatically performed during the first installation
and during "Bring-Up" initialization. This is the initial operation at "power up". The
successful execution of this phase, is a basic condition for the execution of the following
phases.
At "power up" a logic configuration, implemented in the configuration EPROM, will determine which MPCC copy is active, the other one will be in hot-standby mode. When the
active processor is powered up, it is reset and, since it has not been loaded, the load
check fails and the processor goes into a loading state. In this state, the MPCC firmware
looks for a valid load in the system disk and, if successful, the MPCC process starts
sending the message:
*** INFORMATION ***
Loading From Disk:
name = FW_RESERVED:0
diskCopy = COPY0
sourceDirectory = SYS_BACKUP
fileSoftwareVersion = ZZ-ZZ-ZZ-ZZ-ZZ-ZZ_ZZ-ZZ-ZZ
neSoftwareVersion = WW-WW-WW-WW-WW-WW_WW-WW-WW
If the system cannot load the MPCC, the "Bring-Up" stops and displays an UNSUCCESSFUL LOAD message:
*** INFORMATION ***
UNSUCCESSFUL LOAD FROM DISK:
Load not Found Anywhere
In this case, since the MPCC firmware is not able to load MPCC software, it is necessary
to reload the MPCC software from LMT, by entering the LOAD MPCC command from
LMT. The "Bring-Up" process restarts automatically after this command, as described
below. The command is available on LMT menu only during the "Bring-Up" (phase 1).
When MPCC jump from firmware to software, only a minimum set of object instances
are created (see "1.8 Software Management"), that are:

72

the BSCOSUSW instance;

the BSCOSUDB instance;
a single BSCESUSW that is related to BSCOSUSW by the attribute runningESU
and the attribute backupESU (i.e. the software load pointed by BSCESUSW is the
running one and it is also the backup software load); the BSCESUSW is also related
to RSUSWLH by the attribute RELRSU (related resource software unit; see
"3.5 Download of a SW Load Header File on BSC Disk")
the RSUSWLH instance representing the SW load header file
the RSUEXE representing the MPCC executable file;
a single BSCESUDB related to the BSCOSUDB instance with the attribute
runningESU

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

the RSUDB representing the minimum database (at the first, automatic or user
requested, saving database operation, the attribute backupESU of the BSCOSUDB
points to the single BSCESUDB created, and the OperationalState of this BSCESUDB instance is set to ENABLED).

The OperationalState of BSCESUSW, BSCESUDB, RSUSWLH, RSUEXE and RSUDB

will be DISABLED.
Now the correct procedure foresees:
1. to download the SW load header file and all the executable files on BSC disk (see
"3.5 Download of a SW Load Header File on BSC Disk"). After that, OperationalState related to RSUPCH, RSUEXE, RSUSWLH and BSCESUSW is set to
ENABLED
2. then setting the attribute of the BSCOSUSW object from backupESU to runningESU
value (see "3.15 BSC Reload"). After this command the MPCC processor is loaded
again but the loss time is not significant.
Prerequisites
The LOADMPCC command can be entered only if the "Bring-Up" procedure was interrupted because the MPCC executable files were missing.
The user must have the visibility level number set to "3".
The BSC must be in phase 1.

Load the MPCC

To load the MPCC at the "Bring-Up" phase the user must enter the LOADMPCC
command following the next sequence of selections

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> LOADMPCC

Result: the MPCC is loaded. The loading process takes approximately 25

seconds

END

A30808-X3247-L210-3-7619

73

OMN:BSC

Operation
Base Station Controller

3.5

Download of a SW Load Header File on BSC Disk

Introduction
This procedure allows to perform the download of a SW load header file on BSC disk.

During the download of SWL files the BSC software checks every 2 minutes the
presence of the file on BSC disk. If the file is missing the related RSUEXE object goes
in disabled-failed.
If during a Software download a link interruption on the LMT-BSC connection happens,
the user has to wait until this timeout will be expired inside the BSC in order to download
again the software.
To execute the download, the operator must create an instance of the RSUSWLH object
(see before "1.8 Software Management"). The attributes that the BSC application
considers mandatory for executing this command are:

userLabel (ULAB): is a user-defined string that identifies the SW load to which the
software load header file is related;

SRCPATH: contains the path of the LMT directory that contains the SW load header
file; the user can use the Browse File Path button to select both the directory and
the SW load header file on the LMT disk;

DNLALLEXE: allows to specify if, besides the SW load header file, all the executable
file must be downloaded.

Maximum 60 instances of RSUSWLH object can be created;a RSUSWLH object can

not have the same version, and the same network element, of another RSUSWLH
object already created or RSUSWCH object can not have the same userLabel,and the
same network element, of another RSUSWLH object already created

This object class is characterized by the following main State/Status:

Operational State: this attribute describes the operability of a resource and has two
possible values.
DISABLED: the file may be not present or, if present, may be corrupted;
ENABLED: the file is present and correct on the BSC disk.

Procedural Status: this attribute describes the procedural phase of a resource and
it has four possible values.
NONE: the file is available;
INITIALIZATION REQUIRED: the file requires another file transfer procedure due
to unsuccessful previous file transfer or disk failure, like disk formatting or
corrupted file; the operational state is disabled;
NOT INITIALIZED: the file requires a file transfer before it can perform its normal
operation and this procedure has not been initiated; the operational state is
disabled;
INITIALIZING: the file requires a file transfer and this procedure has been initiated
but is not yet complete; the operational state is disabled;

74

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Availability Status: this attribute describes the availability of a resource and it has
three possible values.
OFF LINE: this is the creation value and the temporary fault value of this object
instance; the operational state is disabled;
NONE: this is the default value of this object instance;
FAILED: this value specifies if the file transfer procedure is ended unsuccessfully
or if a permanent file corruption has occurred; the operational state is disabled.

Alarm Status: this attribute describes the occurrence of an abnormal condition

relating to an object.

At the RSUSWLH object creation the Operational State value is DISABLED, the
ProceduralStatus value is NOT INITIALIZED and the AvailabilityStatus value is OFF
LINE.
At the start of the download procedure the Procedural Status value of the RSUSWLH is
set to INITIALIZING; when the download ends successfully the Operational State
value is set to ENABLED, the Procedural Status value is set to NONE and the AvailabilityStatus value is set to NONE.
After downloading, the relatedFiles (RELF) attribute of the RSUSWLH object contains
the complete path of the physical file stored on BSC disk.
If the download ends unsuccessfully then:

the Operational State value doesnt change (DISABLED value);

the Procedural Status value is set to NONE;

the Availability Status value is set to FAILED;

the Alarm Status value is set to DOWNLOAD FAILED (no automatic recovery operation is performed).

Besides, the RSUSWLH creation, causes the following events:

if the software load is related to a BSC, a BSCESUSW instance, related to the

RSUSWLH, is automatically created. The BSCESUSW object will be generated with
the following attributes:
relatedRSU
(RELRSU)

this attribute identifies the instance of the created RSUSWLH,

that has generated this BSCESUSW object instance.

userLabel (ULAB) this attribute assigns a user friendly name to the BSCESUSW
object, that is the same name of the related RSUSWLH
instance. This label identifies in a mnemonic way the BSC
directory on which the SW load is saved
version (VER)

A30808-X3247-L210-3-7619

is a string and identifies the version of the BSCESUSW,

matching the RSUSWLH one.

75

OMN:BSC

Operation
Base Station Controller

if the software load is related to BTSE, BTSEC or TRAU equipment, a NEYESUSW

instance, is automatically created. The NEYESUSW object will be generated with
the following attributes:
relatedRSU
(RELRSU)

this attribute identifies the instance of the created RSUSWLH,

that has generated this NEYESUSW object instance.

userLabel (ULAB) this attribute assigns a user friendly name to the NEYESUSW
object, that is the same name of the related RSUSWLH
instance.
version (VER)

is a string and identifies the version of the NEYESUSW,

matching the RSUSWLH one.

Network Element
Type (NTWEL)

identifies the type of the related Network element, i.e. BTSE in

case of GSM base stations, BTSEC in case of TD-SCDMA
base stations, or TRAU.

At the creation the ESUSW instance has the OperationalState value set to DISABLED
and the AvailabilityStatus value set to OFF LINE / OFF DUTY; when the SW Load is
complete (after the creation of a RSUEXE object) the OperationalState of the ESUSW
is ENABLED and the AvailabilityStatus is OFF DUTY
When downloading a SW load header file, the user has two possible choices:

download with this file all the related executable files; in this case he must set the
DNLALLEXE attribute to YES

download all the related executable files later (see "3.7 Download of a Single
Executable File on BSC Disk"); in this case he must set the DNLALLEXE attribute
to NO

Prerequisites
The RSUSWLH object to be created can not have the same version and the same
network element of another RSUSWLH object already created
The RSUSWCH object to be created
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Download of SW load header file on BSC disk

The user must enter the CREATE RSUSWLH command following the next
sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> CREATE RSUSWLH

Result: the chosen SW load header file will be download to the BSC and
according to the Network Element type a correspondent ESU instance is generated

END

76

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.6

OMN:BSC

Download of a database file on BSC disk

Introduction
This procedure allows to perform the download of a database file on BSC disk.
To execute the download, the operator must create an instance of the RSUDB object
(see "1.8 Software Management"). The attributes that the BSC Application considers
mandatory for executing this command are:

userLabel (ULAB): is a user-defined string that identifies the database file (max 30
characters);

SRCPATH: contains the path of the LMT directory that contains the database file; the
user can use the Browse File Path button to select both the directory and the database file on the LMT disk.

Maximum 20 instances of RSUDB object can be created.

This object class is characterized by the following main State/Status:

Operational State: this attribute describes the operability of a resource and has two
possible values.
DISABLED: the file may be not present or, if present, may be corrupted;
ENABLED: the file is present and correct on the BSC disk.

Procedural Status: this attribute describes the procedural phase of a resource and
it has four possible values.
NONE: the file is available;
INITIALIZATION REQUIRED: the file requires another file transfer procedure due
to unsuccessful previous file transfer or disk failure, like disk formatting or
corrupted file; the operational state is disabled;
NOT INITIALIZED: the file requires a file transfer before it can perform its normal
operation and this procedure has not been initiated; the operational state is
disabled;
INITIALIZING: the file requires a file transfer and this procedure has been initiated
but is not yet complete; the operational state is disabled;

Availability Status: this attribute describes the availability of a resource and it has
three possible values.
OFF LINE: this is the creation value and the temporary fault value of this object
instance; the operational state is disabled;
NONE: this is the default value of this object instance;
FAILED: this value specifies if the file transfer procedure is ended unsuccessfully
or if a permanent file corruption has occurred; the operational state is disabled.

Alarm Status: this attribute describes the occurrence of an abnormal condition

related to an object.

After the RSUDB object creation the OperationalState value is DISABLED, the ProceduralStatus value is NOT INITIALIZED and the AvailabilityStatus value is OFF LINE.

A30808-X3247-L210-3-7619

77

OMN:BSC

Operation
Base Station Controller

At the start of the download procedure the ProceduralStatus value of the RSUDB is set
to INITIALIZING; when the download successfully ends the OperationalState value is
set to ENABLED, the ProceduralStatus value is set to NONE and the AvailabilityStatus value is set to NONE.
After downloading, the relatedFiles (RELF) attribute of the RSUDB object contains the
complete path of the physical file stored on BSC disk.
If the download ends unsuccessfully, the OperationalState value doesnt change
(DISABLED value), the ProceduralStatus value is set to NONE and the AvailabilityStatus value is set to FAILED (no automatic recovery operation is performed).
Besides, the RSUDB creation, causes the automatic creation of a corresponding BSCESUDB instance. The BSCESUDB instance will be generated with the following main
attributes:
relatedRSU
(RELRSU)
userLabel (ULAB)

dBversion (DBVER)

this attribute identifies the instance of the created RSUDB,

that has generated this BSCESUDB object instance.
it is the same userLabel of the correspondent RSUDB. This
label identifies in a mnemonic way the BSC directory on which
the database is saved
it is a structured data that contains two fields:
- db_string_id (used to check database and software compatibility); the max number of characters is 24;
- db_date (contains the saving date of the database)

At the creation the BSCESUDB instance has the OperationalState value set to
DISABLED and the AvailabilityStatus value set to OFF LINE / OFF DUTY; after the
creation the OperationalState value is ENABLED and the AvailabilityStatus is OFF
DUTY
Prerequisites
The RSUDB object to be created can not have the same userLabelof another RSUDB
object already created
The user must have the visibility level number set to "2"
The Network Element must be in phase "2"

Download of database file on BSC disk

The user must enter the CREATE RSUDB command following the next
sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUDB

---> CREATE RSUDB

Result: the chosen database file will be download to the BSC and a correspondent BSCESUDB instance is generated

END

78

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.7

OMN:BSC

Download of a Single Executable File on BSC Disk

Introduction
This procedure allows to perform the download of a single executable or VAM file on
BSC disk.

During the download of SWL files the BSC software checks every 2 minutes the
presence of the file on BSC disk. If the file is missing the related RSUEXE object goes
in disabled-failed.
If during a Software download a link interruption on the LMT-BSC connection happens,
the user has to wait until this timeout will be expired inside the BSC in order to download
again the software.
To execute the download, the operator must create an instance of the RSUEXE object
(see "1.8 Software Management"). The attributes that the BSC Application considers
mandatory for executing this command are:

HEADER: it defines the software load header file; the user can either type the string
in the HEADER field or find the file by the Browse File button.

ULABSWLH: is the user-defined string that identifies the SW load to which the
executable file is related (i.e. it corresponds to the ULAB parameter of the related
RSUSWLH object, see "3.5 Download of a SW Load Header File on BSC Disk");

SRCPATH: contains the path of the LMT directory that contains the executable file;
the user can use the Browse File Path button to select both the directory and the
executable file on the LMT disk.

Maximum 250 instances of RSUEXE object can be created.

This object class is characterized by the following main State/Status:

OperationalState: this attribute describes the operability of a resource and has two
possible values.
DISABLED: the file may be not present or, if present, may be corrupted;
ENABLED: the file is present and correct on the BSC disk.

ProceduralStatus: this attribute describes the procedural phase of a resource and it

has four possible values.
NONE: the file is available;
INITIALIZATION REQUIRED: the file requires another file transfer procedure due
to unsuccessful previous file transfer or disk failure, like disk formatting or
corrupted file; the operational state is disabled;
NOT INITIALIZED: the file requires a file transfer before it can perform its normal
operation and this procedure has not been initiated; the operational state is
disabled;
INITIALIZING: the file requires a file transfer and this procedure has been initiated
but is not yet complete; the operational state is disabled;

AvailabilityStatus: this attribute describes the availability of a resource and it has

three possible values.
OFF LINE: this is the creation value and the temporary fault value of this object
instance; the operational state is disabled;

A30808-X3247-L210-3-7619

79

OMN:BSC

Operation
Base Station Controller

NONE: this is the default value of this object instance;

FAILED: this value specifies if the file transfer procedure is ended unsuccessfully
or if a permanent file corruption has occurred; the operational state is disabled.
At the RSUEXE object instance creation the OperationalState value is DISABLED, the
ProceduralStatus value is NOT INITIALIZED and the AvailabilityStatus value is OFF
LINE.
At the start of the download procedure the ProceduralStatus value of the RSUEXE is set
to INITIALIZING; when the download ends successfully the OperationalState value is
set to ENABLED, the ProceduralStatus value is set to NONE and the AvailabilityStatus value is set to NONE. The sbsRSUexe.relatedFiles now contains the complete
path of the physical file stored on BSC disk.
After downloading, the relatedFiles (RELF) attribute of the RSUEXE object contains the
complete path of the physical file stored on BSC disk.
When the download ends unsuccessfully, the Operational State value doesnt change
(DISABLED value), the Procedural Status value is set to NONE, the Availability
Status value is set to FAILED and the Alarm Status is set to DOWNLOAD FAILED.
Prerequisites
The RSUEXE instance can be created only after creating the related RSUSWLH
instance (i.e. before downloading an executable file, the related SW load header file
must be downloaded)
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Precondition
Has the related SW Load Header file been download yet?

Y h ... 2
N i...."3.5 Download
of a SW Load
Header File on
BSC Disk"

Download of an executable file on BSC disk

The user must enter the CREATE RSUEXE command following the next
sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> CREATE RSUEXE

Result: the chosen file will be download to the BSC.

END

80

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.8

OMN:BSC

Download of a Single Patch File on BSC Disk

Introduction
This procedure allows to perform the download of a single patch file on BSC disk.
Patch files (files of extension .PCH) are handled by the RSUPCH object, and to execute
the download, the operator must create an instance of the RSUPCH object (see
"1.8 Software Management").
The download of a patch is only one of the steps that regard patch handling; in fact after
having downloaded a patch file to the BSC disk, the operator can:

load the patch in the system: in fact after the download, patch files are on the system
disk, however they cannot be used if they are not loaded (see "3.18 Loading Patch
Files");
enable the patch: in fact if patch files are loaded and enabled, they are running on
the system, but, in case of a reload, only the enabled patches will be reloaded. To
become a definitive part of the system, patch files must be enabled (see
"3.19 Enabling a patch file"). In this case, when reloading the system, they will be
also reloaded;
remove the patch from the system, when the file is no more necessary. In case of
either MPCC or TDPC processor, it is important to remove the patch without
reloading the card, because the MPCC reloading (bring-up) or the TDPC reloading
(full init) implies a system downtime and as a consequence a loss of all current calls.
To remove a patch without any system downtime and the consequent loss of all
current calls, it is necessary to load another patch that modifies the processor code
returning to the original one. This particular patch is called unpatch (see
"3.20 Unloading Patch Files").
Unpatch files (like patch ones) are handled by the RSUPCH object; since each patch
can have a related unpatch, the total number of RSUPCH instances is 400 increased
from 200 to 400.

The unpatches have the same file_name of the related patches, with .BAK file extension (the patches always have .PCH file extension).
To execute the download of a patch file, the operator must create an instance of the
RSUPCH object. The attributes that the BSC Application considers mandatory for
executing this command are:

ULAB: is the user-defined string that identifies the patch file;

ULABSWLH: is the user-defined string that identifies the SW load to which the patch
file is related (i.e. it corresponds to the ULAB parameter of the related RSUSWLH
object instance, "3.5 Download of a SW Load Header File on BSC Disk");

PERM: can be TRUE (this corresponds to patch enabled) or FALSE (this corresponds to patch disabled). If it is set to TRUE, the patch is automatically reloaded
at every reload of the related SW load (see "3.15 BSC Reload"); otherwise the patch

A30808-X3247-L210-3-7619

81

OMN:BSC

Operation
Base Station Controller

will not be reloaded (see "3.19 Enabling a patch file" and "3.18 Loading Patch
Files");

PROCTYP: this attribute identifies the processor name (MPCC, TDPC or PPXX)
whose the patch is related;

SRCPATH: contains the path of the LMT directory that contains the patch file; the
user can use the Browse File Path button to select both the directory and the patch
file on the LMT disk;

PRIOSLOTN: this attribute stores an integer value (slot number); at bring up, the
loading sequence of patches is determined by sorting them in function of this
number.

Maximum 400 instances of the RSUPCH object can be created, in relation to patch
and unpatch files. Patch files must have .PCH file extension, Unpatch files must
have .BAK extension.

A patch can not have the same UserLabel as another patch in the same load or the
same UserLabel as the RSUSWLH which contains it.
This object class is characterized by the following main State/Status:

OperationalState: this attribute describes the operability of a resource and has two
possible values.
DISABLED: the file may be not present or, if present, may be corrupted;
ENABLED: the file is present and correct on the BSC disk.

ProceduralStatus: this attribute describes the procedural phase of a resource and it

has four possible values.
NONE: the file is available;
INITIALIZATION REQUIRED: the file requires another file transfer procedure due
to unsuccessful previous file transfer or disk failure, like disk formatting or
corrupted file; the operational state is disabled;
NOT INITIALIZED: the file requires a file transfer before it can perform its normal
operation and this procedure has not been initiated; the operational state is
disabled;
INITIALIZING: the file requires a file transfer and this procedure has been initiated
but is not yet complete; the operational state is disabled;

AvailabilityStatus: this attribute describes the availability of a resource and it has

four possible values.
OFF LINE: this is the creation value and the temporary fault value of this object
instance; the operational state is disabled;
NONE: the file is loaded on MPCC, TDPC or PPXX processor internal memory;
OFF DUTY: the file is available but not loaded on memory (this is the default
value);
FAILED: this value specifies if the file transfer procedure is ended unsuccessfully
or if a permanent file corruption has occurred; the operational state is disabled.

At the creation of the RSUPCH object instance, the Operational State value is
DISABLED, the Procedural Status value is NOT INITIALIZED, the Availability Status
value is OFF LINE/OFF DUTY.

82

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

At the start of the download procedure the Procedural Status value of the RSUPCH is
set to INITIALIZING; when the download ends successfully the Operational State
value is set to ENABLED, the Procedural Status value is set to NONE and the Availability Status value is set to OFF_DUTY. The relatedFiles attribute of the RSUPCH,
now contains the complete path of the physical file stored on BSC disk.
After downloading, the relatedFiles (RELF) attribute of the RSUPCH object contains the
complete path of the physical file stored on BSC disk.
When the download ends unsuccessfully, the OperationalState value doesnt change
(DISABLED value), the ProceduralStatus value is set to NONE and the AvailabilityStatus value is set to FAILED/OFF_DUTY
Prerequisites
The RSUPCH instance can be created only after creating the related RSUEXE instance
(i.e. before downloading a patch file, the related executable file must be downloaded).
The patch file extension must be PCH (for the patches) or BAK (for the unpatches).
The initial letter of the file name depends on the proc_type.
The unpatch instance can be created only after creating the related patch instance.
The unpatch instance must be created with permanent attribute FALSE and slot number
NULL or skipped.
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".

Precondition
Has the related executable file been downloaded yet?

Y h ... 2
N i ..."3.7 Download
of a Single
Executable File
on BSC Disk"

Download of a patch file on BSC disk

Enter the CREATE RSUPCH command following the next sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> RSUPCH ---> CREATE RSUPCH

Result: the chosen file will be download to the BSC.

END

A30808-X3247-L210-3-7619

83

OMN:BSC

Operation
Base Station Controller

3.9

Deletion of Files from BSC Disk

Introduction
This procedure allows to delete:

a software load header file (i.e. a RSUSWLH instance) or

a database file (i.e. a RSUDB instance) or
an executable file (i.e. a RSUEXE instance) or
a patch file (i.e. a RSUSPCH instance)

The deletion of a RSU object instance determines the deletion of all the RSU object
instances that are contained by it.
If a RSUSWLH instance is deleted, then the whole SW load (i.e. related RSUEXE and
RSUPCH instances) will be deleted from BSC disk; the related BSCESUSW (or NEYESUSW) object instance will be automatically deleted too. The order or deletion is the
following:

deletion of RSUPCH instances if present

deletion of RSUEXE instances,
deletion of RSUSWLH instance and
deletion of related ESUSW instance

If a RSUEXE (ProcType attribute equal to MPCC or TDPC or PPXX) has been deleted,
then the related RSUPCH instances will be deleted too, if any.
If the Network Element Type is equal to BTSE then deleting RSUEXE may correspond
to delete executable or VAM files.
If a RSUPCH pathc has been deleted then the related RSUPCH unpatch is automatically deleted.
If a RSUDB has been deleted then the related BSCESUDB is automatically deleted.
If a RSUEXE has been deleted the related BSCESUSW (or NEYESUSW) can be no
more complete; if the ESUSW is no more complete then:

84

the OperationalState of the related ESUSW is set to DISABLED

the AvailabilityStatus of the ESUSW is set to OFF LINE

It is important to note that the deletion of a RSUSWLH instance, related to a

BSCESUSW pointed by backupESU, runningESU, newESU or fallbackESU attributes
of the BSCOSUSW instance, is not allowed.

It is important to note that the deletion of a RSUEXE instance, related to a BSCESUSW

pointed by backupESU, runningESU, newESU or fallbackESU attributes of the
BSCOSUSW instance, is allowed only if it is in DISABLED-FAILED.

It is important to note that the deletion of a RSUSWLH instance, related to a

NEYESUSW instance, pointed by backupESU attribute of a BTSMOSUSW/
BTSMTDOSUSW/TRAUOSUSW instance is not allowed.

It is important to note that the deletion of a RSUEXE instance, related to a NEYESUSW

instance, pointed by backupESU attribute of a BTSMOSUSW/BTSMTDOSUSW/
TRAUOSUSW instance is NOT allowed.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

It is important to note that the deletion of a RSUDB instance, related to a BSCESUDB

instance, pointed by backupESU, runningESU, newESU or fallbackESU attribute of a
BSCOSUDB instance is not allowed.

It is important to note that the deletion of a RSUPCH instance, with PERMANENT

attribute set to TRUE value is not permitted: its necessary to set before the
PERMANENT attribute to FALSE value.

It is important to note that the deletion of a RSUPCH instance is allowed only if it is

OFF-DUTY.
In the previous cases, the right procedural sequence is the following:
1. replace the BSCESUSW (or BSCESUDB or NEYESUSW) linked to the runningESU
(or backupESU or newESU or fallbackESU) with a different object value.;
2. then perform the DELETE command that, in this case, it is always accepted.
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Situations
Would you like to delete a software load header file?
Would you like to delete a database file?
Would you like to delete an executable file?
Would you like to delete a patch file?

h ... 2
h ... 3
h ... 4
h ... 5

Delete SW load header file

To delete a SW load header file, the user must enter the DELETE RSUSWLH
command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> RSUSWLH --->

DELETE RSUSWLH

Result: The chosen SW load header file, and all the executable and patch files
contained by it are deleted
The related BSCESUSW instance is deleted too.

Delete a database file

To delete a database file, the user must enter the DELETE RSUDB command,
following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> RSUDB --->

DELETE RSUDB

Result: The chosen database file is deleted.

The related BSCESUDB instance is deleted too.

A30808-X3247-L210-3-7619

85

OMN:BSC

Operation
Base Station Controller

Delete an executable file

To delete an executable file, the user must enter the DELETE RSUEXE
command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> RSUSWLH --->

RSUEXE ---> DELETE RSUEXE

Result: The chosen executable file and all the patch files contained by it are
deleted.

Delete a patch file

To delete a patch file, the user must enter the DELETE RSUSWLH command,
following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> RSUPCH ---> DELETE RSUPCH

Result: the chosen patch file and the related unpatch file (if present) are
deleted.

END

86

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.10

OMN:BSC

Getting the attributes of RSUSWLH, RSUDB, RSUEXE and

RSUPCH objects.
Introduction
This command allows the user to get the value of the different attributes of the following
object classes: RSUSWLH, RSUDB, RSUEXE and RSUPCH.
For RSUSWLH object class the list of attributes is the following:

userLabel (ULAB): identifies the SW load to which the software load header file is
related(it is equal to the BSCESUSW or NEYESUSW userLabel)
version (VER): contains the version of the SW Load Header file
Network element type (NTWEL): identifies the type of the related Network Element:
BSC, BTSE (GSM base station), BTSEC (TD-SCDMA base station) or TRAU;
relatedFiles (RELF): contains the complete path of the physical file stored on BSC
disk

For RSUDB object class the list of attributes is the following:

userLabel (ULAB): identifies the BSCESUDB to which the database is related (it is
equal to the BSCESUDB userLabel)
dbVersion (DBVER): is a structured data that contains two fields: the first is used to
check the data base and software compatibility, and the second contains the saving
date of the database file.
relatedFiles (RELF): contains the complete path of the physical file stored on BSC
disk

For RSUEXE object class the list of attributes is the following:

version (VER): contains the version of the VAM or executable file

processor Type (PROCTYP): contains the processor name or VAM
relatedFiles (RELF): contains the complete path of the physical file stored on BSC
disk

For RSUPCH object class the list of attributes is the following:

userLabel (ULAB): identifies the patch in unambiguous way

processor Type (PROCTYP): is an enumerated type and contains the processor
name (MPCC, TDPC or PPXX) whose the patch is related.
sbsPermanent (PERM): can be TRUE (patch enabled) or FALSE (patch
disabled); if it is set to TRUE and the patch is related to backupESU then, for
example, during loadBackupESUsw procedure (the old Load System command)
this patch is automatically loaded
sbsPrioritySlot(PRIOSLOTN) is an integer value and it determines the order loading
of the patches at bring-up
relatedFiles (RELF): contains the complete path of the physical file stored on BSC
disk.

Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

A30808-X3247-L210-3-7619

87

OMN:BSC

Operation
Base Station Controller

Situations

h ... 2
h ... 3
h ... 4
h ... 5

Would you like to get the attributes of a SW load header file?

Would you like to get the attributes of a database file?
Would you like to get the attributes of an executable file?
Would you like to get the attributes of a patch file?

Display the value of the attributes of a SW load header file

To display the value of the attributes of a SW load header file, the user must
enter the GET RSUSWLH command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> RSUSWLH

---> GET RSUSWLH

h ... END

Result: Display the value of the attributes of a chosen SW load header file.

Display the value of the attributes of a database file

To display the value of the attributes of a database file, the user must enter the
GET RSUDB command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> RSUDB

---> GET RSUDB

h ... END

Result: Display the value of the attributes of a chosen database file.

Display the value of the attributes of an executable file

To display the value of the attributes of an executable file, the user must enter
the GET RSUEXE command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> GET RSUEXE

h ... END

Result: Display the value of the attributes of a chosen executable file.

Display the value of the attributes of a patch file

To display the value of the attributes of a patch file, the user must enter the GET
RSUPCH command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> RSUPCH ---> GET RSUPCH

Result: Display the value of the attributes of a chosen patch file.

END

88

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.11

OMN:BSC

Getting the attributes of BSCESUSW, BSCESUDB, and

NEYESUSW objects.
Introduction
BSCESUSW instances identify BSC SW loads present on BSC disk. A BSCESUSW
instance is automatically created after creating a RSUSWLH instance (see
"3.5 Download of a SW Load Header File on BSC Disk").
The BSCESUSW object class is characterized by the following attributes:
relatedRSU
(RELRSU)
userLabel (ULAB)

version (VER)

this attribute identifies the instance of the RSUSWLH object,

that has generated this BSCESUSW object instance.
this attribute assigns a user friendly name to the BSCESUSW
object, that is the same name of the related RSUSWLH
instance.
is a string and identifies the version of the BSCESUSW,
matching the RSUSWLH one.

The BSCESUSW object class is characterized by the following main State/Status:

OperationalState: this attribute describes the operability of a resource and has two
possible values.
DISABLED: the BSC SW load is totally inoperable and unable to provide service
to the user;
ENABLED: the BSC SW load is complete (all the files in the RSUSWLH and the
RSUSWLH itself are present and valid into BSC disk) and the existing RSUPCH
instances (with the PERM attribute set to TRUE) have the OperationalState set to
ENABLED

AvailabilityStatus: this attribute describes the availability of a resource and it has

three possible values.
OFF LINE: this is the creation value and the fault value of this object instance;
EMPTY: the SW load is the running one for the BSC network element;
OFF_DUTY: the SW load is not the running one for the BSC network element.

The BSCESUDB instance identify BSC database present on BSC disk. A BSCESUDB
instance is automatically created after creating a RSUDB instance (see PROC: Download of a database file on BSC disk).
The BSCESUDB object class is characterized by the following attributes:
relatedRSU
(RELRSU)
userLabel (ULAB)
dBversion (DBVER)

A30808-X3247-L210-3-7619

this attribute identifies the instance of the RSUDB object, that

has generated this BSCESUDB object instance.
it is the same userLabel of the correspondent RSUDB
it is a structured data that contains two fields:
- db_string_id (used to check database and software compatibility)
- db_date (contains the saving date of the database)

89

OMN:BSC

Operation
Base Station Controller

The BSCESUDB object class is characterized by the following main State/Status:

OperationalState: this attribute describes the operability of a resource and has two
possible values.
DISABLED: the BSC database is totally inoperable and unable to provide service
to the user;
ENABLED: if the database file is present and valid in BSC disk.

AvailabilityStatus: this attribute describes the availability of a resource and it has

three possible values.
OFF LINE: this is the creation value and the fault value of this object instance;
EMPTY: the database instance is the running one for the BSC network element;
OFF_DUTY: the database instance is not the running one for the BSC network
element.

NEYESUSW instances identify BTSE, BTSEC or TRAU SW loads present on BSC disk
and loaded on BTSE/BTSEC/TRAU network entities.

BTSEC is the BTS equipment supporting TD-SCDMA features (BTSE for China).
A NEYESUSW instance is automatically created after creating a RSUSWLH instance
(see PROC: Download of a SW Load Header File on BSC Disk).
The NEYESUSW object class is characterized by the following attributes:
relatedRSU
(RELRSU)
userLabel (ULAB)

this attribute identifies the instance of the RSUSWLH object,

that has generated this NEYESUSW object instance.
this attribute assigns a user friendly name to the NEYESUSW
object, that is the same name of the related RSUSWLH
instance.
version (VER)
is a string and identifies the version of the NEYESUSW,
matching the RSUSWLH one.
Network Element type identifies the type of the related Network Element: BTSE,
(NTWEL)
BTSEC or TRAU.
The NEYESUSW object class is characterized by the following main State/Status:

OperationalState: this attribute describes the operability of a resource and has two
possible values.
DISABLED: the BTSE/BTSEC/TRAU SW load is totally inoperable and unable to
provide service to the user;
ENABLED: the BTSE/BTSEC/TRAU SW load is complete (all the files in the
RSUSWLH and the RSUSWLH itself are present and valid into BSC disk)

AvailabilityStatus: this attribute describes the availability of a resource and it has

three possible values.
OFF LINE: this is the creation value and the fault value of this object instance;
EMPTY: the SW load is the running one for some BTSE/BTSEC/TRAU network
element;
OFF_DUTY: the SW load is not the running one for any BTSE/BTSEC/TRAU
network element.

90

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

With this procedure the operator is able to see the different attributes of the
BSCESUSW, BSCESUDB, NEYESUSW object classes, mentioned above.
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Situations
Would you like to get the attributes of BSCESUSW instance?
Would you like to get the attributes of BSCESUDB instance?
Would you like to get the attributes of NEYESUSW instance?

h ... 2
h ... 3
h ... 4

Get the attributes of a BSCESUSW instance

To display the value of the attributes of a BSCESUSW instance, the user must
enter the GET BSCESUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCESUSW

---> GET BSCESUSW

Result: Display the value of the attributes of a chosen BSCESUSW.

h ... END

Get the attributes of a BSCESUDB instance

To display the value of the attributes of a BSCESUDB instance, the user must
enter the GET BSCESUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCESUDB

---> GET BSCESUDB

Result: Display the value of the attributes of a chosen BSCESUDB.

h ... END

Get the attributes of a NEYESUSW instance

To display the value of the attributes of a NEYESUSW instance, the user must
enter the GET NEYESUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> NEYESUSW --->

GET NEYESUSW

Result: Display the value of the attributes of a chosen NEYESUSW.

END

A30808-X3247-L210-3-7619

91

OMN:BSC

Operation
Base Station Controller

3.12

Update of the Software Load within the BR7.0 Release

Introduction
This procedure describes how the user can change the SW version for BSC, BTSE,
BTSEC and TRAU equipment within one release.
To change the BSC software, there are two different methods:

the first one consists of the Load System procedure, that means load the new software and database to the disk, set new SW and new prepared database to backup
and perform the SETRUNBACK command (this procedure is described in
"3.15 BSC Reload"); in this case all processors will be new loaded, then a consistent
outage time is required, because all processors are involved;
the second one is described in the following paragraphs; with this procedure not all
the processors are always involved, so it requires a reduced outage time, depending
of the involved processors.

The procedure here described regards only software upgrade. If you need also to
change hardware equipment such as BSC rack, BSC switching matrix, or MPCC
version from MPCCV7 to MPCCV8 please refer to "3.14 Hardware/Software Upgrade
from BR6.0 to BR7.0 release" because a similar procedure is valid in case of hardware
upgrade within BR7.0 release.
In fact as it has been described in " New MPCC and TDPC processor boards", in
BR7.0 release new versions for both MPCC and TDPC processors exist; they are
MPCCV8 and TDPCV7 respectively. To change these boards the described procedure
reduces service interruption by exploiting the redundancy of the MPCC boards and the
ability of the active copy to access the disk located on the other MPCC copy
(see 3.14).
CHANGE VERSION
The Change Version command allows the user to load a new software load (only a
changed file or a complete SW load), whose files are present in the BSC disk. In the
BSC disk the new software release will be identified by a specific BSCESUSW instance
(see "3.5 Download of a SW Load Header File on BSC Disk").
It is possible to interrupt the change version in order to come back with the old software,
or to accept the new one, after testing it.
Before starting the change version procedure, the user must set the BSCESUSW
instance related to the new SW load, as the newESU BSCESUSW instance (i.e. this
generic SW load, must be marked as the new SW load; see "3.22 Setting a Generic
SW Load as Backup, Fallback, or New SW Load")
Then the change version is performed by a SETRUNNEW command on the BSCOSUSW object.
The new software to load must be complete (all the related objects must be created and
available), even if a single file has been changed. This means that the BSCESUSW
related to BSCOSUSW through newESU attribute is enabled (Operational State is
equal to ENABLED) and so the related RSUSWLH, all the RSUEXE contained by SW
load header instance, and RSUPCH (with PERM attribute equal to TRUE) are
ENABLED.
The processors involved in Change Version operation are:
a) those ones whose SoftwareVersion (SVR) is changed from backupESU to newESU;

92

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

b) those ones whose set of permanent patches related to backupESU is different from
the set of permanent patches related to newESU.
The Prerequisites for accepting this command are:

the system must be in normal exercise (no other operation is in progress);

the LoadUsageState attribute of BSCOSUSW must be IDLE;
the OperationalState attribute of BSCOSUSW.backupESU must be ENABLED;
the OperationalState attribute of BSCOSUSW.newESU must be ENABLED;
the BSCOSUSW.runningESU and BSCOSUSW.backupESU must be equal;
if also MPCC processor is involved in change version, then BSCOSUDB.newESU
attribute must be present and its OperationalState attribute must be ENABLED;
If also MPCC processor is involved in change version, then BSCOSUDB.newESU
attribute must point to a DB instance compatible with the network type present.
If also MPCC processor is involved in change version, then BSCSUDB.runningESU
and BSCOSUDB.backupESU must be equal
If also MPCC processor is involved in change version, then at least one copy for
each processor type must be providing service;
if also MPCC processor is involved in change version, then the number of MPCC
copy providing service must be equal to the number of the On-Board disk copy
providing service;
if IXLT, PPCC, PPCU, PPXL, PPXU, PPXP processors (see "1.4 Supported BSC
Types") are involved in change version, then they must be redundant, all the cards
must be UNLOCKED-ENABLED and at least one copy must be providing service;
if PPLD, PPXL, PPXT processors are involved in change version, then at least one
copy must be providing service;
No crosscopy disks operation is in progress;
The (possible) set of running patches must be equal to that one of permanent
patches. This precondition is verified for each type of processor which could have
patches.
The OperationalState attribute for all the RSUEXE objects related to the peripheral
processor types foreseen (equipped) and contained in the ESUSW pointed by
BSCOSUSW.newESU must be ENABLED

If MPCC processor is involved in change version procedure then all the processors are
reloaded.The BSC application forces the MPCC loading by MPCC firmware and sets the
partition (sys_new) where the firmware can find the MPCC executable file to load. When
the MPCC firmware ends the MPCC loading, it notifies to the Software the partition
(sys_new) and the device (dk40-0 or disk on board-0/disk on board-1) from which it has
loaded.
For MPCC processor the new executable file, only the new patches with the PERM
attribute set to TRUE (see "3.8 Download of a Single Patch File on BSC Disk") and the
new database (if its present) are loaded.
If MPCC processor is not involved in change version procedure then only the processors involved in change version are loaded. In this case the BSCOSUDB.newESU
attribute could be empty, since the backup database, if necessary, is used for all operations.

A30808-X3247-L210-3-7619

93

OMN:BSC

Operation
Base Station Controller

If IXLT, PPCC, PPCU processors (in case of standard BSC) or PPXL, PPXU, PPXP
processors (in case of high capacity BSC, see "1.4 Supported BSC Types") are in
duplex (i.e. all the cards are UNLOCKED - ENABLED) the change version procedure
is executed in time share modality and the loss of service is not significant; otherwise
the change version procedure is rejected.
In case of high capacity BSC, for all the PPXU/PPXP boards which are in UNLOCKED
- ENABLED state, the change version procedure is executed in time share modality,
and the loss of service is not significant. More in detail:

if the MPCC software has to be changed, a Bring Up procedure will start;

if the TDPC software has to be changed, both TDPC processor copies will be loaded
with the new software, losing the traffic service for about 2 minutes: at the end of
command one copy is enabled with the new software and crosscopy operation from
the TDPC active to the standby one is in progress;

if the IXLT software has to be changed:

if both the IXLT are enabled, only the card not providing service is loaded with the
new software, and the service is lost only for the switching time between the two
processor copies. At the end of the command the copy with the new software is
providing service, the other copy, with the old software, is disabled and it is automatically loaded when the end of change version command (SETBACKNEW
BSCOSUSW) is entered.
if one of the IXLT is not enabled, the command is not executed.

if the PPCC software has to be changed (standard BSC):

if both PPCC are enabled, only the copy provided by the Device Handler is loaded
with the new software, and the service is lost only for the switching time between
the two processor copies. At the end of the command the copy with the new software is enabled, the other copy, with the old software, is disabled and it is automatically loaded when the end of change version command (SETBACKNEW
BSCOSUSW) is entered.
if one of the PPCC is not enabled, the command is not executed.

if the PPCU software has to be changed (standard BSC):

if both PPCU are enabled, only the copy provided by the Device Handler is loaded
with the new software, and the service is lost only for the switching time between
the two processor copies. At the end of the command the copy with the new software is enabled, the other copy, with the old software, is disabled and it is automatically loaded when the end of change version command (SETBACKNEW
BSCOSUSW) is entered.
if one of the PPCU is not enabled, the command is not executed.

94

if the PPLD software has to be changed (standard BSC), all PPLD processor copies
will be loaded with the new software, losing the traffic service for about 2-3 minutes.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

At the end of the command all equipped PPLD are loaded with the new software and
enabled.

if the PPXL software has to be changed (high capacity BSCs):

if both PPXL are enabled, only the copy provided by the Device Handler is loaded
with the new software, and the service is lost only for the switching time between
the two processor copies. At the end of the command the copy with the new software is enabled, the other copy, with the old software, is disabled and it is automatically loaded when the end of change version command (SETBACKNEW
BSCOSUSW) is entered.
if one of the PPXL is not enabled, the command is not executed.

if the PPXU, PPXP software has to be changed (high capacity BSCs):

if at least two PPXU/PPXPs are enabled, only half of the processors provided by
the Device Handler are loaded with the new software, and the service is lost only
for the switching time between the two groups of processor copies. At the end of
the command the copies with the new software are enabled, the other copies with
the old software are disabled and they are automatically loaded when the end of
change version command (SETBACKNEW BSCOSUSW) is entered.
if only one PPXU/PPXP is enabled, the command is not executed.

if the PPXT software (for TD-SCDMA) has to be changed (high capacity BSC), all
PPXT processor copies will be loaded with the new software, losing the traffic
service for about 2-3 minutes. At the end of the command all equipped PPXTs are
loaded with the new software and enabled.

During change version procedure the LoadUsageState of the BSCOUSW object is set
to loadNewESUsw and, at the successful operation end, is set to waitForAcceptNewESUsw value. If the operation fails then an automatic interrupt of software change
version is executed (see below) and LoadUsageState is set to loadBackupESUsw: at
the end of this procedure it is reset to idle value.
Note that if zero PCU units are equipped, and the Change Version procedure involve
also this processor type, then the cards can't be loaded but the procedure must go on.
If a user create some PCU unit after the End of Change Version command (see below),
then the related PPCU/PPXU cards must be loaded with the new software version.
Note that if zero PCUTD units are equipped (for TD-SCDMA), and the Change Version
procedure involve also this processor type, then the cards can't be loaded but the procedure must go on. If a user creates some PCUTD units after the End of Change Version
command (see below), then the related PPXP cards must be loaded with the new software version.
If Change Version procedure involve only PPCU, or PPXU cards, but zero PCU are
equipped, then the only effect of this command is the changing of the BSCOSUSW.LoadUsageState attribute from idle to loadNewESUsw and finally to waitForAcceptNewESUsw; no processor load is made.
If Change Version procedure involves only PPXP cards, but zero PCUTD are equipped,
then the only effect of this command is the changing of the BSCOSUSW.LoadUsageState attribute from idle to loadNewESUsw and finally to waitForAcceptNewESUsw;
no processor load is made.

A30808-X3247-L210-3-7619

95

OMN:BSC

Operation
Base Station Controller

INTERRUPT OF SOFTWARE CHANGE VERSION

This procedure allows the user to abort the change version process, and to load the
processors with the old SW version again. Automatic interrupt of software change
version is also executed when change version procedure fails.
This operation is performed by a SETRUNBACK command on the BSCOSUSW object.
Using this command, the user makes three operations:
1. forces the system to abort the load in progress (only if the BSCOUSW.LoadUsageState attribute is equal to loadNewESUsw);
2. reload all the processors involved in the change version;
3. forces the system to use the BSCESUSW instance marked as backup, during the
reload procedure (i.e. the old software load associated to this BSCESUSW instance,
is loaded).

The Prerequisites for accepting this command are that the LoadUsageState attribute of
BSCOSUSW object must be equal to either loadNewESUsw or waitForAcceptNewESUsw.

The processors involved in rollback operation are:

a) those ones whose SoftwareVersion (SVR) is changed from backupESU to newESU;
b) those ones whose set of permanent patches related to backupESU is different from
the set of permanent patches related to newESU.
After this operation (i.e. the SETRUNBACK command) all the involved processor are
reloaded, and the BSCESUSW instance related to the old software release, will be the
running one. For each type of processor which could have patches, if are involved in the
rollback procedure, only the patch with the PERM attribute TRUE are reloaded.
If MPCC processor is involved in rollback procedure then all the processors are
reloaded even if not involved in rollback procedure, also the backup database are
loaded.
In this case the BSC application forces the MPCC loading by MPCC firmware and sets
the partition (sys_backup) where the firmware can find the MPCC executable file to load.
When the MPCC firmware ends the MPCC loading, it notifies to the Software the partition (sys_backup) and the device (dk40-0 or disk on board-0/disk on board-1) from
which it has loaded.
For any processors involved in the rollback procedure the backup executable file and
only the backup patches with the PERM attribute set to TRUE are reloaded.

END OF CHANGE VERSION

This procedure allows the user to accept the new SW version running on the system,
making it as the backup version.
This operation is performed by a SETBACKNEW command on the BSCOSUSW object.

96

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Using this command, the user marks the BSCESUSW instance related to the new SW
load a backup, so after this command the new software load will be the running one
and the backup one.
The BSC application sets the partition (sys_backup) where the firmware can find the
MPCC executable file to load.
The Prerequisites for accepting this command are:

the LoadUsageState attribute of the BSCOSUSW object must be waitForAcceptNewESUsw;

the OperationalState attribute of BSCOSUSW.newESU must be ENABLED;
if also MPCC was involved in change version, then BSCOSUDB.newESU must have
the OperationalState attribute ENABLED;
no crosscopy disks operation is in progress.

If the BSCESUSW instance passed to the command by LMT is not equal to that one
pointed by BSCOSUSW.newESU or the LoadUsageState attribute is different from
waitForAcceptNewESUsw, then the command performed is like an assign of a generic
SW load to newESU.

During this procedure the LoadUsageState attribute is set to acceptNewESUsw and,

at the end of the operation, it is reset to idle value.
Pre-Requisites
See above.

The procedure describes the software update considering BTSE equipment only, i.e.
considering only base stations for GSM; if TD-SCDMA base stations are involved in the
software update procedure, the procedure remains the same; the only difference is that
a right software load must be downloaded to TD-SCDMA base stations (BTSEC).

Import of the new software load in the LMT

This step is performed in order to import to the LMT disk the files to be downloaded in the BSC.

Upload the current database file from BSC to LMT

UPLOAD the current database file from BSC to LMT, following the next
sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT---> UPLFILE

Convert the Database

The database conversion is necessary only if there are meaningful changes

with respect to the previous load and it can be performed using the
DBAEM/CONVFILE tools.

A30808-X3247-L210-3-7619

i ..."3.133 Usage
of tools for
database
management
(DBAEM and
CONVFILE
tools)"

97

OMN:BSC

Operation
Base Station Controller

Find the current load version

The current load version is related to the MPCC SW version and can be
obtained through the following sequence of commands
- GET BSCOSUSW (asking for the RUNNING SW)
- GET BSCESUSW (to obtain RSU related to the RUNNING SW)
- GET RSUSWLH (to obtain the software version)
Alternately it can be obtained by executing a GETINFO MPCC command,
following the next sequence of selections:

b
5

MANAGED-ELEMENT ---> BSS-EQUIPMENT--> BSCE--> MPCC--> GETINFO

MPCC
Download the software to BSC, BTSE, BTSEC and TRAU

To start the Software download the user has to perform the CREATE
RSUSWLH command setting the related parameters. The user can verify,
through Browser, the presence of RsuSwlh:x and BSCEsusw:y (NEYEsusw:z)
instances, automatically defined by the system. The download is started
through the following sequence of selections:

b
6

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> CREATE RSUSWLH
Download the software to the TRAU

To download the SW load to the TRAU, the user must enter the NEDOWNLOAD
NEYESUSW command, with the NTWEL parameter set to TRAUE, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE_MANAGEMENT ---> NEYESUSW

---> NEDOWNLOAD NEYESUSW

Result: the TRAU SW download is started

Download the software to the BTSE

To download the SW load to the BTSE, the user must enter the NEDOWNLOAD
NEYESUSW command, with the NTWEL parameter set to BTSE, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE_MANAGEMENT ---> NEYESUSW

---> NEDOWNLOAD NEYESUSW

Result: the BTSE SW download is started

98

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Download the software to the BTSEC

To download the SW load to the BTSEC, the user must enter the
NEDOWNLOAD NEYESUSW command, with the NTWEL parameter set to
BTSEC, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE_MANAGEMENT ---> NEYESUSW

---> NEDOWNLOAD NEYESUSW

Result: the BTSEC SW download is started

DOWNLOAD the converted database

DOWNLOAD the converted database from LMT to BSC disk, following the next
sequence of selections:

b
10

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> RSUDB -->

CREATE RSUDB
Set the SW load as new one

To set a generic SW load as new one, the user must enter the SET BSCOSUSW command, following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

---> SET BSCOSUSW

Then the user must select the downloaded SW load, and set the ACTN attribute
as NEW_ESU

11

Set the DB as new one

To set a generic DB as new one, the user must enter the SET BSCOSUDB
command, following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUDB

---> SET BSCOSUDB

Then the user must select the downloaded DB, and set the ACTN attribute as
NEW_ESU

12

Execute the change version procedure

To change the software version the user must enter the SETRUNNEW
BSCOSUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

---> SETRUNNEW BSCOSUSW

The execution time of this command depends on which processors are involved
in change version procedure. After BSC initialization the Expected Sw Versions
for TRAU, BTSEC and/or BTSE will be checked and the alignment with the NE
will start.

A30808-X3247-L210-3-7619

99

OMN:BSC

13

Operation
Base Station Controller

Result

If the command is successfully executed the system is set in the "change

version wait for end" phase

Y h ... 14
N h ... 18

Do you accept the new version?

Note: it the Change Version procedure is not successfully executed, the system
performs an automatic Rollback to the previous software version.

14

Execute the end of change version procedure

To accept the new loaded version the user must enter the
SETBACKNEW BSCOSUSW command, following the next sequence of selections

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

--->SETBACKNEW BSCOSUSW

The execution time of this command depends on which processors are involved
in change version procedure.

15

Result

Y h ... 17
N h ... 16

Is the command SETBACKNEW BSCOSUSW unsuccessfully executed?

16

Change BTSE, BTSEC and TRAU software version

The user can change step by step the software version of BTSE, BTSEC and
TRAU equipment, grouping them in groups of N network elements. In this way
he can avoid the complete loss of service. For the chosen BTSE, BTSEC and
TRAU equipment he must enter the following the next sequence of selections

b
b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> SET TRAU
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD --->
SET BTSMTD
and then he must set the EXPSWV parameter.

The Expected Sw Versions for TRAU, BTSEC and/or BTSE will be checked and
the alignment with the NE will start.

17

Recovery action

It is up to the user the updating of the BSC disk contents using the system
commands; no Rollback is provided in this phase and the software version
running on the system is anyway the new one.

100

h ... END

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

18

OMN:BSC

Execute the interrupt software change version procedure

To interrupt the software change version and restore the previous version, the
user must enter the SETRUNBACK BSCOSUSW command, following the next
sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW --->

SETRUNBACK BSCOSUSW

h ... END

END

A30808-X3247-L210-3-7619

101

OMN:BSC

102

Operation
Base Station Controller

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.13

OMN:BSC

Hardware/Software Upgrade from BR5.5 to BR7.0 Release

Introduction
This procedure allows the operator to change the BSS software version from the BR5.5
release to the BR7.0 one.
Regarding the upgrade, since in BR7.0 release different hardware solutions are
provided (see "1.4 Supported BSC Types") different cases are discussed:
1. upgrade without hardware modifications: in this case the upgrade is executed
without changing any board on the BSC rack (i.e. the standard BSC is always used),
but only the firmware is changed from MPCCV6 to MPCCV7; so we have:
INITIAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU,
PPLD, DK40, MPCCV6;
FINAL CONFIGURATION: the same boards (no hardware changes) and FW for
MPCCV7.
2. upgrade with hardware modifications, where the SN16 matrix is changed with the
SNAP one:
INITIAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU,
PPLD, DK40, MPCCV6;
FINAL CONFIGURATION: high capacity BSC (old rack) with QTLP, SNAP, PPXL,
PPXU, EPWRV4, DK40 FW for MPCCV7.
3. upgrade with hardware modifications, changing MPCC boards from MPCCV6 to
MPCCV8;
INITIAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU,
PPLD, DK40, MPCCV6;
FINAL CONFIGURATION: standard BSC with same boards, but MPCCV8 and
TDPCV7.
4. upgrade with hardware modifications, where the SN16 matrix is changed with the
SNAP one and MPCC boards are changed from MPCCV6 to MPCCV8:
INITIAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU,
PPLD, DK40, MPCCV6;
FINAL CONFIGURATION: high capacity BSC (old rack) with QTLP, SNAP, PPXL,
PPXU, DK40 FW for MPCCV7, EPWRV4, MPCCV8/TDPCV7.
5. upgrade with hardware modifications, where the old BSC rack is replaced with the
new one.

As described in "1.6 Support of different HW generations of network entities", it is available in BR7.0 a new rack of BSC. Due to HW constraint it is not possible the direct
upgrade of the software from the old BSC rack to the new BSC rack (it does not equip
the DK40!). The only way is first to perform only a SW upgrade on the old BSC, and
then to install the new rack using the same MPCC boards of the old rack.
Since in BR7.0 the flexible abis allocation strategy is used (see "3.40 Configuration of
the Abis Interface"), the old Abis configuration, with 2 PCMB lines and only one
LPDLM, will be no longer supported. So, before executing a change version procedure
to BR7.0 starting from BR5.5 (or older) release, the operator must switch to a configuration with at least 1 LPDLM/LPDLMTD over each PCMB trunk.

A30808-X3247-L210-3-7619

103

OMN:BSC

Operation
Base Station Controller

Prerequisites

Both BR5.5 LMT and BR7.0 LMT have to be installed. It is possible to have two
different LMT versions on the PC but only one can be open/active.
DK40-0 must be operational (because DK40-1 card is not considered in BR7.0).
The user must have the visibility level set to number "3".

Situation

h ... 2
h ... 15

Would you like to perform an upgrade without HW modifications?

Would you like to perform an upgrade with HW modifications?

Upload the current database file from BSC to LMT

UPLOAD the current database file from BSC to BR5.5 LMT by executing the
following sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT---> UPLFILE

Convert the Database

The Database conversion from BR5.5 format to BR7.0 format can be performed
using DBAEM/CONVFILE tools.
During conversion the user has to change in the ASCII format database the
parameter ExpectedSwVersion for BTSE and TRAU (this information can be
obtained from the file Hs0100xx.swl for BTSE or HT0100yy.swl for TRAUE). It is
mandatory to do it in this step because after the initialisation of the BSC the
BTSE and TRAU have to come up with the new BR7.0 SW, because BSC in
BR7.0 is not compatible with BTSE or TRAU using BR5.5 software.

i...."3.134 Different
release Data
Base Conversions"

Store the BR7.0 software for BSC, BTSE and TRAU

Import in the BR5.5 LMT the BR7.0 software for BSC, BTSE and TRAU.

Download the BR7.0 software for BSC, BTSE and TRAU

DOWNLOAD the BR7.0 software for BSC, BTSE and TRAU from BR5.5 LMT to
DK40 disk by executing the following sequence of selections:

MANAGED-ELEMENT --> SOFTWARE MANAGEMENT ---> DNLALLEXE

Note: the download of the MPCC software must be executed into the SYS_NEW
directory.

104

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Download the software to the TRAU

To download the SW load to the TRAU, the user must enter the NEDNL SW
TRAU command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SW --->

NEDNL SW TRAU

Result: the TRAU SW download is started

Download the software to the BTSE

To download the SW load to the BTSE, the user must enter the NEDNL SW
BTSE command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SW --->

NEDNL SW BTSE

Result: the BTSE SW download is started

Download the converted database

DOWNLOAD the converted database from BR5.5 LMT to DK40 disk (directory
SYS_NEW) following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> DNLDBA

Download the MPCC FW image

DOWNLOAD the MPCC FW image from BR5.5 LMT to DK40 disk (directory
FIRMWARE) as a generic file, following the next sequence of operations:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> DNLDATA

10

Copy the old version BSC software

COPY the old version BSC software from SYS_BACKUP to SYS_FALLBACK

following the next sequence of selections:

b
11

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SW ---> COPY

SW
CHANGE VERSION for BSC

The Change Version procedure is started by executing the following sequence

of selections:
The command will cause a BSC reload, with a loss of service.

A30808-X3247-L210-3-7619

105

OMN:BSC

Operation
Base Station Controller

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SW ---> CHVER

SW

If one or more executable files are not downloaded on disk, the command is
anyway accepted, but it will fail when the BR7.0 SW tried to load missing
RSUEXEs; in this case automatic rollback occurs.
Apart from the automatic recovery, the command SETRUNBACK BSCOSUSW
can be used, through LMT of BR7.0 release, at any time to restart the old SW
load if the operator detects any incorrect behavior.
The FW loads the MPCC SW from DK40 disk and puts it running.
All executable files are copied from the SYS_NEW directory of the DK40 to the
MPCC disk; each involved file is referenced by a RSU related object
(RSUSWLH and RSUEXE).
An instance of BSCESUSW object is implicitly created and used as a new
source of load; the usual Bring up sequence is started and all processors are
loaded.
After this step, the BR7.0 LMT has to be used.

12

Finish the change version procedure (with BR7.0 LMT)

The Change Version procedure can be ended; the command SETBACKNEW

BSCOSUSW is used. The following sequence of selections has to be
performed:

MANAGED-ELEMENT --> SOFTWARE MANAGEMENT---> BSCOSUSW --->

SETBACKNEW BSCOSUSW

The new BSC BR7.0 SW and database automatically become the BACKUP
ones.

13

Update the MPCC FW on both processor copies.

This step consists in updating the MPCC FW on both processor copies; the
command TEST is performed (after having locked the card) through the
following sequence of selections:

MANAGED-ELEMENT --> BSS-EQUIPMENT ---> BSCE ---> MPCC--->

PERFTEST MPCC
After the MPCC FW update the PID and Label update is necessary.

14

Situation
Are you executing a change version procedure with hardware upgrade?

106

Y h ... 38
N h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

15

What kind of hardware upgrade do you want to execute?

Replace SN16, PPCC, PPCU, PPLD, MPCCV6 boards with SNAP, PPXL,
PPXU, MPCCV7 ones?
Maintain SN16, PPCC, PPCU, PPLD boards and changing from MPCCV6 to
MPCCV8/TDPCV7?
Replace SN16, PPCC, PPCU, PPLD, MPCCV6 with SNAP, PPXL, PPXU,
MPCCV8/TDPCV7?
Change the BSC rack into the new one (high capacity BSC with new rack)?

16

OMN:BSC

h ... 16
h ... 37
h ... 37
h ... 64

Check initial conditions

The normal procedure cannot be executed because the procedure requires

boards change on site.
Be sure that the content of the disks of both DK40 boards is aligned; the
complete BR5.5 software must be located in the SYS_BACKUP directory.

17

Upload the current database file from BSC to LMT

UPLOAD the current database file from BSC to BR5.5 LMT by executing the
following sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT---> UPLFILE

18

Convert the Database

The Database conversion from BR5.5 format to BR7.0 format can be performed
using DBAEM/CONVFILE tools.
During conversion the user has to change in the ASCII format database the
parameter ExpectedSwVersion for BTSE and TRAU (this information can be
obtained from the file Hs0100xx.swl for BTSE or HT0100yy.swl for TRAUE). It is
mandatory to do it in this step because after the initialisation of the BSC the
BTSE and TRAU have to come up with the new BR7.0 SW, because BSC in
BR7.0 is not compatible with BTSE or TRAU using BR5.5 software.

i ..."3.134 Different
release Data
Base Conversions"

NOTE: if necessary create the PCU (PPXL are implicitly equipped using the
SNAP matrix).

19

Store the BR7.0 software for BSC, BTSE and TRAU

Import in the BR5.5 LMT the BR7.0 software for BSC, BTSE and TRAU.

20

Lock DK40-1

LOCK the DK40:1 and extract the board from the backplane; it can be used later
in case a rollback to the old version is required. The command is executed by
following sequence of selections:

MANAGED-ELEMENT --> BSS-EQUIPMENT ---> BSCE ---> DK40--->

LOCK DK40:1

A30808-X3247-L210-3-7619

107

OMN:BSC

21

Operation
Base Station Controller

Download the BR7.0 software for BSC, BTSE and TRAU

DOWNLOAD the BR7.0 software for BSC from BR5.5 LMT to DK40:0 disk
(directory SYS_BACKUP) by executing the following sequence of selections:

MANAGED-ELEMENT --> SOFTWARE MANAGEMENT ---> DNLALLEXE

NOTE: to download PPXL and PPXU executable files, a MPCC SW version
greater than 02-05-05-01-30-0C_01-04-02 must be used.

22

Download the software to the TRAU

To download the SW load to the TRAU, the user must enter the NEDNL SW
TRAU command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SW --->

NEDNL SW TRAU

Result: the TRAU SW download is started

23

Download the software to the BTSE

To download the SW load to the BTSE, the user must enter the NEDNL SW
BTSE command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SW --->

NEDNL SW BTSE

Result: the BTSE SW download is started

24

Download the converted database

DOWNLOAD the converted database from BR5.5 LMT to DK40:0 disk (directory SYS_BACKUP) following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> DNLDBA

25

Download the MPCC FW image

DOWNLOAD the new MPCC FW image from BR5.5 LMT to DK40 disk (directory FIRMWARE) as a generic file (MPCC.FWI), following the next sequence of
operations:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> DNLDATA

The Firmware file is downloaded.

26

Lock the powers

Before turning off the powers, it is necessary to lock them, through the following
sequence of selections:

108

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> PWRD (EPWR) -->

LOCK PWRD (EPWR)

A30808-X3247-L210-3-7619

Operation
Base Station Controller

27

OMN:BSC

Turn off the powers

Turn off the powers of the BSC.

NOTE. BSC outage starts now.

28

Change the involved boards

Replace PPLD, PPCC, PPCU and SN16 boards with PPXL, PPXU and SNAP
ones.

29

Turn on the powers

The BSC starts the bring up procedure; MPCC executable file is loaded from
DK40:0 disk; the other executable files are first copied to the MPCC disk and
then loaded to in the processor memories.

30

Update the MPCC FW on both processor copies

Once the bring-up procedure is ended, replace the firmware on both processor
copies; the command TEST is performed (after having locked the card) through
the following sequence of selections:

MANAGED-ELEMENT --> BSS-EQUIPMENT ---> BSCE ---> MPCC--->

PERFTEST MPCC
NOTE: MPCCV6 differs from MPCCV7 only for the FW version; the former uses
the DK40 disk, while the latter uses the MPCC on board disk.
After the MPCC FW update the PID and Label update is necessary.

31

Result
Do you accept the new software version ?

32

h ... END

Y h ... END
N h ... 32

Consideration

No automatic roll-back is possible.

To roll-back, the old FW must be downloaded on the MPCC disk and replaced
on both the MPCC (Download the SFM1103 file on the directory FIRMWARE as
generic file, LOCK MPCC, PERFORM TEST MPCC)

33

Switch of the powers

Turn off both the powers of the BSC.

34

Replace boards

Replace the new boards with the old ones..

35

Change DK40 boards

Extract the DK40 (copy 0) and insert the DK40 (copy 1) which still contains the
BR5.5 SW in the SYS_BACKUP directory.

A30808-X3247-L210-3-7619

109

OMN:BSC

36

Operation
Base Station Controller

Switch on the powers

h ... END

The BR5.5 old SW bring-up takes place.

37

Situation

It is not possible to upgrade directly from BR5.5 to BR7.0 with

MPCCV8/TDPCV7 boards. In fact MPCCV8 can not access to the DK40 disk.
So you must before execute a change version to BR7.0 release.

38

h ... 2

Check the configuration

Make sure that active copies of the main boards/objects of the base rack are
under control of the same power board copy.
Note: for simplicity we consider the PWRD-0 power board, then MPCC, TDPC,
IXLT, MEMT, NTW shall be active on copy 0.

39

Lock DISK-1

To lock disk-1 enter the LOCK DISK command, following the next sequence of
selections

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

LOCK DISK
Then set, NAME=DISK:1

40

Lock MPCC-1

To lock the MPCC board, enter the LOCK MPCC command, following the next
sequence of selections

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> MPCC --->

LOCK MPCC
Then set, NAME=MPCC:1

41

Lock the power (PWRD:1)

Lock PWRD:1 power through the following sequence of selections:

b
42

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> PWRD -->

LOCK PWRD
Turn off BSC power (PWRD:1)

Turn off PWRD-1 power.

43

Disconnect MPCC cables

Disconnect the hardware hot links between both MPCC copies. Disconnect the
flat cable (IDE) from the standby MPCC (copy 1) too.

44

Extract MPCC-1 and TDPC-1 board

Extract MPCC-1 and TDPC-1 boards from the backplane.

110

A30808-X3247-L210-3-7619

Operation
Base Station Controller

45

OMN:BSC

Replace boards

Replace MPCC-1 and TDPC-1 boards with the new versions of boards
(MPCCV8 and TDPCV7).

46

Reconnect MPCC cable

Reconnect the flat cable to the standby MPCC-1.

NOTE: do not reconnect hot links, because they are not compatible.

47

Turn on BSC power

Turn on PWRD-1 power.

Note: the system will put in service all the power subordinates objects.
The attempt will fail with MPCC/TDPC because of hot link problems
(MPCC/TDPC processors will stay in DISABLED state)

48

Execute the diagnostic of DISK:1

To execute the diagnostic of DISK:1, enter the PERFTEST DISK command,

following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

PERFTEST DISK
Then set, NAME=DISK:1.

49

Unlock DISK:1

To unlock DISK:1, enter the UNLOCK DISK command, following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

UNLOCK DISK
Then set, NAME=DISK:1.
Note: cross-copy will start. Wait until the operation is finished; the disk will go in
ENABLED state.

50

Lock the active disk (DISK:0)

To lock DISK:0, enter the LOCK DISK command, following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

LOCK DISK
Then set, NAME=DISK:0.
Note: this allows to keep the old SW linked to the backupESU on the old MPCC
board; in this way if something goes wrong it is possible to Bring-up from the old
disk with the old SW.

A30808-X3247-L210-3-7619

111

OMN:BSC

51

Operation
Base Station Controller

Set the downloaded software load as the backup one

To set the SW load as the backup one, enter the SET BSCOSUSW command,
following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

---> SET BSCOSUSW

Then select the implicitly created BSCESUSW object instance, and set the
ACTN attribute as BACKUP_ESU

52

Set the downloaded database as the backup one

To set the database as the backup one, enter the SET BSCOSUDB command,
following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUDB

---> SET BSCOSUDB

Then select the implicitly created BSCESUDB object instance, and set the
ACTN attribute as BACKUP_ESU

53

Lock the power (PWRD:0)

Lock PWRD:0 power through the following sequence of selections:

b
54

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> PWRD -->

LOCK PWRD
Turn off BSC power (PWRD:0)

Turn off PWRD-0 power: BSC outage starts now.

55

Situation
Do you have to change SN16, PPCU, PPLD boards with SNAP, PPXL,PPXU
ones?

56

Y h ... 56
N h ... 57

Change the involved boards

Replace PPLD, PPCC, PPCU and SN16 boards with PPXL, PPXU and SNAP
ones.

57

Replace boards

Extract both MPCC-0 and TDPC-0 from the backplane and replace them with
new versions of boards (MPCCV8/TDPCV7).

58

Turn off both BSC powers

Switch down the whole rack.

59

Reconnect links to MPCC-0

Reconnect the flat cable (IDE) and hot links to the MPCC-0.

112

A30808-X3247-L210-3-7619

Operation
Base Station Controller

60

OMN:BSC

Reconnect links to TDPC-0

Reconnect hot links to the TDPC-0.

61

If required change O-link configuration

It required, change O-link configuration from X.25 to TCPIP.

i
62

To get more information refer to "3.73 Management of Links towards

Radio Commander/Cell Broadcast Centre"

Turn on BSC powers

Turn on BSC powers starting from the copy containing the new software (copy
1).
Note: MPCC firmware automatically starts with the bring up procedure,
retrieving the software and the database from the backup repository of disk copy
1.
Once the MPCC software starts, it detects that the content of the disks is not
aligned and initiates the crosscopy of DISK-0. At the end of the procedure both
disks are aligned.

63

Change BTSE and TRAU software version

This procedure is automatically executed: the Expected Sw Versions for TRAU

and/or BTSE will be checked and the alignment with the NE will start.

h ... END
64

Upgrade the new rack by Local Labs and install it in field

The first part of this upgrade can be performed by Local Labs.

The BSC with new rack must be delivered in field equipped as required, and
with the following features:
- PPXX issue >= 15
- usage of Adapter board for reusing existing PCM cables and PCM mapping
- BR7.0 BSC executable files (and patches) downloaded
- BR7.0 BTS and TRAU executable files downloaded
- the rack has been tested with an ad hoc DB
- the EEPROM of the board (PID) has been already programmed by the FTT
Then the rack must be installed in field.

65

Turn on new BSC rack powers

Turn on BSC powers.

Bring-up procedure starts, then the MPCC reached the providing service state.

A30808-X3247-L210-3-7619

113

OMN:BSC

66

Operation
Base Station Controller

Upload the database file from the old BSC rack to LMT

UPLOAD the current database file from BSC to BR5.5 LMT by executing the
following sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT---> UPLFILE

67

Convert the Database

The Database conversion from BR5.5 format to BR7.0 format can be performed
using DBAEM/CONVFILE tools.
During conversion the user has to change in the ASCII format database the
parameter ExpectedSwVersion for BTSE and TRAU (this information can be
obtained from the file Hs0100xx.swl for BTSE or HT0100yy.swl for TRAUE). It is
mandatory to do it in this step because after the initialisation of the BSC the
BTSE and TRAU have to come up with the new BR7.0 SW, because BSC in
BR7.0 is not compatible with BTSE or TRAU using BR5.5 software.

i...."3.134 Different
release Data
Base Conversions"

NOTE: do not forget to use the right value (NTWSNAP_STLP) of NTWCARD

attribute.

68

DOWNLOAD the converted database

DOWNLOAD the converted database from LMT to MPCCV8 disk, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> RSUDB -->

CREATE RSUDB
After that, LOAD the create DB.

69

Turn off the power of the old rack BSC

Turn off power: BSC outage starts now.

The outage lasts the time necessary to move the lines (using the cable adapter
this operation is fast) from the old rack to the new one and to align the NE.
The BSC gradually goes in service (the PCMS carrying the SS7 link should be
connected at first to allow to have the call available as soon as the BTS is
aligned).
For more details see the Service department procedures.

114

A30808-X3247-L210-3-7619

Operation
Base Station Controller

70

OMN:BSC

Change BTSE and TRAU software version

The user can change step by step the software version of BTSE and TRAU
equipment, grouping them in groups of N network elements. In this way he can
avoid the complete loss of service. For the chosen BTSE and TRAU equipment
he must enter the following the next sequence of selections

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> SET TRAU
and then he must set the EXPSWV parameter.

The Expected Sw Versions for TRAU and/or BTSE will be checked and the
alignment with the NE will start.

END

A30808-X3247-L210-3-7619

115

OMN:BSC

116

Operation
Base Station Controller

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.14

OMN:BSC

Hardware/Software Upgrade from BR6.0 to BR7.0 release

Introduction
This procedure allows the operator to change the BSS software version from the BR6.0
release to the BR7.0 one.
Regarding the upgrade, since in BR7.0 release different hardware solutions are
provided (see "1.4 Supported BSC Types") different cases are discussed:
1. upgrade without hardware modifications, with the BSC equipped with SN16
switching matrix; so we have:
INITIAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU,
PPLD, DK40, MPCCV7/TDPCV6;
FINAL CONFIGURATION: the same;
2. upgrade without hardware modifications, with the BSC equipped with SNAP
switching matrix; so we have:
INITIAL CONFIGURATION: high capacity BSC (old rack) with QTLP, SNAP,
PPXL, PPXU, EPWRV4, DK40, MPCCV7/TDPCV6;
FINAL CONFIGURATION: the same;
3. upgrade with hardware modifications, changing switching matrix;
INITIAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU,
PPLD, DK40, MPCCV7/TDPCV6;
FINAL CONFIGURATION: high capacity BSC (old rack) with QTLP, SNAP, PPXL,
PPXU, EPWRV4, DK40, MPCCV7/TDPCV6;
4. upgrade with hardware modifications, where MPCC boards are changed from
MPCCV7 to MPCCV8 and the SN16 matrix is changed with the SNAP one:
INITIAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU,
PPLD, DK40, MPCCV7;
FINAL CONFIGURATION: high capacity BSC (old rack) with QTLP, SNAP, PPXL,
PPXU, DK40, EPWRV4, MPCCV8/TDPCV7;
5. upgrade with hardware modifications, where MPCC boards are changed from
MPCCV7 to MPCCV8 and the switching matrix is not changed (it remains the SN16
one):
INITIAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU,
PPLD, DK40, MPCCV7;
FINAL CONFIGURATION: standard BSC with QTLP, SN16, PPCC, PPCU, PPLD,
DK40, MPCCV8/TDPCV7.
6. upgrade with hardware modifications, where MPCC boards are changed from
MPCCV7 to MPCCV8 and the switching matrix is not changed (it remains the SNAP
one):
INITIAL CONFIGURATION: high capacity BSC (old rack) with QTLP, SNAP,
PPXL, PPXU, DK40, EPWRV4, MPCCV7;
FINAL CONFIGURATION: high capacity BSC (old rack) with QTLP, SNAP, PPXL,
PPXU, DK40, EPWRV4, MPCCV8/TDPCV7.

A30808-X3247-L210-3-7619

117

OMN:BSC

Operation
Base Station Controller

7. upgrade with hardware modifications, where the old BSC rack is replaced with the
new one.

As described in "1.6 Support of different HW generations of network entities", it is available in BR7.0 a new rack of BSC. Due to HW constraint it is not possible the direct
upgrade of the software from the old BSC rack to the new BSC rack. The only way is
first to perform only a SW upgrade on the old BSC, and then to install the new rack
using the same MPCC boards of the old rack.
Prerequisites

Both BR6.0 LMT and BR7.0 LMT have to be installed. It is possible to have two
different LMT versions on the PC but only one can be open/active.
The user must have the visibility level set to number "3".

Situation

Would you like to perform an upgrade without HW modifications?

Would you like to perform an upgrade with HW modifications?

h ... 2
h ... 22

Import of the new software load in the LMT

This step is performed in order to import to the LMT disk the files to be downloaded in the BSC.

Upload the current database file from BSC to LMT

UPLOAD the current database file from BSC to LMT, following the next
sequence of selections:

118

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT---> RSUDB --->

UPLDFILE RSUDB

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Convert the Database

The Database conversion from BR6.0 format to BR7.0 format can be performed
using DBAEM/CONVFILE tools.
The expected SW versions of all the connected NEs should not be modified
during database conversion, so that the previous SW versions are activated.
Then it is possible to change the expected SW version of a limited number of
NEs, while the others are still operational, and so on till the whole NEs are
upgraded.
This procedure has the following advantages:

it reduces the BSS service unavailability (it is not needed to wait that all the
NE load together the new SW, while a good cell coverage strategy may allow
to provide the service in large areas);

it checks the BSC correctness before the BTSM/BTSMTD/TRAU upgrade;

it improves the control of the progress of the BTSM/BTSMTD/TRAU SW

activation.

i ..."3.134 Different
release Data
Base Conversions"

Store the BR7.0 software for BSC, BTSE, BTSEC and TRAU

Import in the BR6.0 LMT the BR7.0 software for BSC, BTSE, BTSEC and
TRAU.

Find the current load version

The current load version is related to the MPCC SW version and can be
obtained through the following sequence of commands
- GET BSCOSUSW (asking for the RUNNING SW)
- GET BSCESUSW (to obtain the RSUSWLH related to the RUNNING SW)
- GET RSUSWLH (to obtain the software version)
Alternately it can be obtained by executing a GETINFO MPCC command,
following the next sequence of selections:

b
7

MANAGED-ELEMENT ---> BSS-EQUIPMENT--> BSCE--> MPCC--> GETINFO

MPCC
Download BR7.0 executable files (BSC, BTSE, BTSEC, TRAU) to the BSC

To start the Software download the user has to perform the CREATE
RSUSWLH command setting the related parameters. The user can verify,
through Browser, the presence of RsuSwlh:x and BSCEsusw:y (NEYEsusw:z)
instances, automatically defined by the system. The download is started
through the following sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> CREATE RSUSWLH
The system implicitly creates a new BSCESUSW object instance.

A30808-X3247-L210-3-7619

119

OMN:BSC

Operation
Base Station Controller

Download the software to the TRAU

To download the SW load to the TRAU, the user must enter the NEDOWNLOAD
NEYESUSW command, with the NTWEL parameter set to TRAU, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the TRAU SW download is started

Download the software to the BTSE

To download the SW load to the BTSE, the user must enter the NEDOWNLOAD
NEYESUSW command, with the NTWEL parameter set to BTSE, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the BTSE SW download is started

10

Download the software to the BTSEC

To download the SW load to the BTSEC, the user must enter the
NEDOWNLOAD NEYESUSW command, with the NTWEL parameter set to
BTSEC, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the BTSEC SW download is started

11

DOWNLOAD the converted database

DOWNLOAD the converted database from LMT to MPCC disk, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> RSUDB -->

CREATE RSUDB
The system implicitly creates a new BSCESUDB object instance.

12

Prerequisite

The created BR7.0 BSCESUSW must be ENABLED for the current release
(BR6.0), the involved boards must be in providing service state.

120

A30808-X3247-L210-3-7619

Operation
Base Station Controller

13

OMN:BSC

Set the SW load as new one

To set a generic SW load as new one, the user must enter the SET BSCOSUSW command, following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

---> SET BSCOSUSW

Then the user must select the downloaded SW load, and set the ACTN attribute
as NEW_ESU

14

Set the DB as new one

To set a generic DB as new one, the user must enter the SET BSCOSUDB
command, following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUDB

---> SET BSCOSUDB

Then the user must select the downloaded DB, and set the ACTN attribute as
NEW_ESU

15

Execute the change version procedure

To change the software version the user must enter the

SETRUNNEW BSCOSUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

---> SETRUNNEW BSCOSUSW

The execution time of this command depends on which processors are involved
in change version procedure. After BSC initialization the Expected Sw Versions
for TRAU, BTSE and/or BTSEC will be checked and the alignment with the NE
will start.

A30808-X3247-L210-3-7619

121

OMN:BSC

16

Operation
Base Station Controller

Result

If the command is successfully executed the system is set in the "change

version wait for end" phase

Y h ... 17
N h ... 21

Do you accept the new version?

Note: it the Change Version procedure is not successfully executed, the system
performs an automatic Rollback to the previous software version.

17

Execute the end of change version procedure

To accept the new loaded version the user must enter the
SETBACKNEW BSCOSUSW command, following the next sequence of selections

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

--->SETBACKNEW BSCOSUSW

The execution time of this command depends on which processors are involved
in change version procedure.

18

Result

Y h ... 20
N h ... 19

Is the command SETBACKNEW BSCOSUSW unsuccessfully executed?

19

Change BTSE and TRAU software version

The user can change step by step the software version of BTSE and TRAU
equipment, grouping them in groups of N network elements. In this way he can
avoid the complete loss of service. For the chosen BTSE and TRAU equipment,
after having set the administrative state to LOCKED, he must enter the
following sequence of selections

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> SET TRAU
and then he must set the EXPSWV parameter.

When the user set again the administrative state to UNLOCKED, the Expected
Sw Versions for TRAU and/or BTSE will be checked and the alignment with the
NE will start automatically.

20

Recovery action

It is up to the user the updating of the BSC disk contents using the system
commands; no Rollback is provided in this phase and the software version
running on the system is anyway the new one.

122

h ... END

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

21

OMN:BSC

Execute the interrupt software change version procedure

To interrupt the software change version and restore the previous version, the
user must enter the SETRUNBACK BSCOSUSW command, following the next
sequence of selections:

b
22

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW --->

SETRUNBACK BSCOSUSW
What kind of hardware upgrade do you want to execute?

Replace SN16, PPCC, PPCU, PPLD, boards with SNAP, PPXL, PPXU and
changing from MPCCV7 to MPCCV8/TDPCV7 too?
Replace SN16, PPCC, PPCU, PPLD, boards with SNAP, PPXL, PPXU ones
maintaining MPCCV7 and changing from MPCCV7 to MPCCV8/TDPCV7 too?
Maintain SN16, PPCC, PPCU, PPLD boards and changing from MPCCV7 to
MPCCV8/TDPCV7?
Maintain SNAP, PPXL, PPXU boards and changing from MPCCV7 to
MPCCV8/TDPCV7?
Change the BSC rack into the new one (high capacity BSC with new rack)?

23

h ... END

h ... 23
h ... 39
h ... 39
h ... 39
h ... 74

Situation

The normal Change Version procedure cannot be used because the procedure
requires boards change on site.

24

Upload the current database file from BSC to LMT

UPLOAD the current database file from BSC to LMT, following the next
sequence of selections:

b
25

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT---> RSUDB --->

UPLDFILE RSUDB
Convert the Database

The Database conversion from BR6.0 format to BR7.0 format can be performed
using DBAEM/CONVFILE tools.
The expected SW versions of all the connected NEs should not modified during
database conversion, so that the previous SW versions are activated. Then it is
possible to change the expected SW version of a limited number of NEs, while
the others are still operational, and so on till the whole NEs are upgraded.
This procedure has the following advantages:

it reduces the BSS service unavailability (it is not needed to wait that all the
NE load together the new SW, while a good cell coverage strategy may allow
to provide the service in large areas);

it checks the BSC correctness before the BTSM/BTSMTD/TRAU upgrade;

it improves the control of the progress of the BTSM/BTSMTD/TRAU SW

activation.

A30808-X3247-L210-3-7619

i ..."3.134 Different
release Data
Base Conversions"

123

OMN:BSC

26

Operation
Base Station Controller

Store the BR7.0 software for BSC, BTSE, BTSEC and TRAU

Import in the BR6.0 LMT the BR7.0 software for BSC, BTSE, BTSEC and
TRAU.

27

Download BR7.0 executable files (BSC, BTSE, BTSEC, TRAU) to the BSC

To start the Software download the user has to perform the CREATE
RSUSWLH command setting the related parameters. The user can verify,
through Browser, the presence of RsuSwlh:x and BSCEsusw:y (NEYEsusw:z)
instances, automatically defined by the system. The download is started
through the following sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> CREATE RSUSWLH
The system implicitly creates a new BSCESUSW object instance.

28

Download the software to the TRAU

To download the SW load to the TRAU, the user must enter the NEDOWNLOAD
NEYESUSW command, with the NTWEL parameter set to TRAU, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the TRAU SW download is started

29

Download the software to the BTSE

To download the SW load to the BTSE, the user must enter the NEDOWNLOAD
NEYESUSW command, with the NTWEL parameter set to BTSE, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the BTSE SW download is started

124

A30808-X3247-L210-3-7619

Operation
Base Station Controller

30

OMN:BSC

Download the software to the BTSEC

To download the SW load to the BTSEC, the user must enter the
NEDOWNLOAD NEYESUSW command, with the NTWEL parameter set to
BTSEC, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the BTSEC SW download is started

31

DOWNLOAD the converted database

DOWNLOAD the converted database from LMT to BSC disk, following the next
sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> RSUDB -->

CREATE RSUDB
The system implicitly creates a new BSCESUDB object instance.

32

Set the SW load as backup one

To set a generic SW load as backup one, the user must enter the SET BSCOSUSW command, following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

---> SET BSCOSUSW

Then the user must select the downloaded SW load, and set the ACTN attribute
as BACKUP_ESU

33

Set the DB as backup one

To set a generic DB as backup one, the user must enter the SET BSCOSUDB
command, following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUDB

---> SET BSCOSUDB

Then the user must select the downloaded DB, and set the ACTN attribute as
BACKUP_ESU

34

Lock EPWR boards

Before turning off the powers, it is necessary to lock EPWR boards, through the
following sequence of selections:

b
35

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> PWRD (EPWR) -->

LOCK PWRD (EPWR)
Turn off the powers

Turn off the powers of the BSC: BSC outage starts now.

A30808-X3247-L210-3-7619

125

OMN:BSC

36

Operation
Base Station Controller

Change the involved boards

Replace PPLD, PPCC, PPCU and SN16 boards with PPXL, PPXU and SNAP
ones. Also the EPWR boards must be updated in the old rack with their new
versions (EPWR V4).

37

Turn on the powers

The BSC starts the bring up procedure loading the active MPCC from its on
board disk.

38

Change BTSE and TRAU software version

The user can change step by step the software version of BTSE and TRAU
equipment, grouping them in groups of N network elements. In this way he can
avoid the complete loss of service. For the chosen BTSE and TRAU equipment
after having set the administrative state to LOCKED, he must enter the
following the next sequence of selections

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> SET TRAU
and then he must set the EXPSWV parameter.

When the user set again the administrative state to UNLOCKED, the Expected
Sw Versions for TRAU and/or BTSE will be checked and the alignment with the
NE will start automatically.

39

h ... END

Situation

This upgrade can be performed from BR6.0, with PPXX release >= 15 or H6).

40

Check the configuration

Make sure that active copies of the main boards/objects of the base rack are
under control of the same power board copy.
Note: for simplicity we consider the PWRD-0 power board, then MPCC, TDPC,
IXLT, MEMT, NTW shall be active on copy 0.

41

Upload the current database file from BSC to LMT

UPLOAD the current database file from MPCCV7 (copy1) to LMT, following the
next sequence of selections:

126

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT---> RSUDB --->

UPLDFILE RSUDB

A30808-X3247-L210-3-7619

Operation
Base Station Controller

42

OMN:BSC

Convert the Database

The Database conversion from BR6.0 format to BR7.0 format can be performed
using DBAEM/CONVFILE tools.
The expected SW versions of all the connected NEs should not modified during
database conversion, so that the previous SW versions are activated. Then it is
possible to change the expected SW version of a limited number of NEs, while
the others are still operational, and so on till the whole NEs are upgraded.
This procedure has the following advantages:

43

it reduces the BSS service unavailability (it is not needed to wait that all the
NE load together the new SW, while a good cell coverage strategy may allow
to provide the service in large areas);

it checks the BSC correctness before the BTSM/BTSMTD/TRAU upgrade;

it improves the control of the progress of the BTSM/BTSMTD/TRAU SW

activation.

i ..."3.134 Different
release Data
Base Conversions"

Store the BR7.0 software for BSC, BTSE, BTSEC and TRAU

Import in the BR6.0 LMT the BR7.0 software for BSC, BTSE, BTSEC and
TRAU.

44

Download BR7.0 executable files (BSC, BTSE, BTSEC, TRAU) to the BSC

Download executable files into the MPCC disk (copy 0).

To start the Software download the user has to perform the CREATE
RSUSWLH command setting the related parameters. The user can verify,
through Browser, the presence of RsuSwlh:x and BSCEsusw:y (NEYEsusw:z)
instances, automatically defined by the system. The download is started
through the following sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> CREATE RSUSWLH
The system implicitly creates a new BSCESUSW object instance.

45

Download the software to the TRAU

To download the SW load to the TRAU, the user must enter the NEDOWNLOAD
NEYESUSW command, with the NTWEL parameter set to TRAU, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the TRAU SW download is started

A30808-X3247-L210-3-7619

127

OMN:BSC

46

Operation
Base Station Controller

Download the software to the BTSE

To download the SW load to the BTSE, the user must enter the NEDOWNLOAD
NEYESUSW command, with the NTWEL parameter set to BTSE, following the
next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the BTSE SW download is started

47

Download the software to the BTSEC

To download the SW load to the BTSEC, the user must enter the
NEDOWNLOAD NEYESUSW command, with the NTWEL parameter set to
BTSEC, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW
The system implicitly creates a new NEYESUSW object instance.

Result: the BTSEC SW download is started

48

DOWNLOAD the converted database

DOWNLOAD the converted database from LMT to MPCC disk (copy 0),
following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> RSUDB -->

CREATE RSUDB
The system implicitly creates a new BSCESUDB object instance.

49

Lock DISK-1

To lock disk-1 enter the LOCK DISK command, following the next sequence of
selections

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

LOCK DISK
Then set, NAME=DISK:1

50

Lock MPCC-1

To lock the MPCC board, enter the LOCK MPCC command, following the next
sequence of selections

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> MPCC --->

LOCK MPCC
Then set, NAME=MPCC:1

128

A30808-X3247-L210-3-7619

Operation
Base Station Controller

51

OMN:BSC

Lock the power (PWRD:1)

Lock PWRD:1 power through the following sequence of selections:

b
52

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> PWRD -->

LOCK PWRD
Turn off BSC power (PWRD:1)

Turn off PWRD-1 power.

53

Disconnect MPCC cables

Disconnect the hardware hot links between both MPCC copies. Disconnect the
flat cable (IDE) from the standby MPCC (copy 1) too.

54

Extract MPCC-1 and TDPC-1 board

Extract MPCC-1 and TDPC-1 boards from the backplane.

55

Replace boards

Replace MPCC-1 and TDPC-1 boards with the new versions of boards
(MPCCV8 and TDPCV7).

56

Reconnect MPCC cable

Reconnect the flat cable to the standby MPCC-1.

NOTE: do not reconnect hot links, because they are not compatible.

57

Turn on BSC power

Turn on PWRD-1 power.

Note: the system will put in service all the power subordinates objects.
The attempt will fail with MPCC/TDPC because of hot link problems
(MPCC/TDPC processors will stay in DISABLED state)

58

Execute the diagnostic of DISK:1

To execute the diagnostic of DISK:1, enter the PERFTEST DISK command,

following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

PERFTEST DISK
Then set, NAME=DISK:1.

A30808-X3247-L210-3-7619

129

OMN:BSC

59

Operation
Base Station Controller

Unlock DISK:1

To unlock DISK:1, enter the UNLOCK DISK command, following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

UNLOCK DISK
Then set, NAME=DISK:1.
Note: cross-copy will start. Wait until the operation is finished; the disk will go in
ENABLED state.

60

Lock the active disk (DISK:0)

To lock DISK:0, enter the LOCK DISK command, following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

LOCK DISK
Then set, NAME=DISK:0.
Note: this allows to keep the old SW linked to the backupESU on the old MPCC
board; in this way if something goes wrong it is possible to Bring-up from the old
disk with the old SW.

61

Set the downloaded software load as the backup one

To set the SW load as the backup one, enter the SET BSCOSUSW command,
following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

---> SET BSCOSUSW

Then select the implicitly created BSCESUSW object instance, and set the
ACTN attribute as BACKUP_ESU

62

Set the downloaded database as the backup one

To set the database as the backup one, enter the SET BSCOSUDB command,
following the sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUDB

---> SET BSCOSUDB

Then select the implicitly created BSCESUDB object instance, and set the
ACTN attribute as BACKUP_ESU

63

Lock the power (PWRD:0)

Lock PWRD:0 power through the following sequence of selections:

b
64

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> PWRD -->

LOCK PWRD
Turn off BSC power (PWRD:0)

Turn off PWRD-0 power: BSC outage starts now.

130

A30808-X3247-L210-3-7619

Operation
Base Station Controller

65

Situation
Do you have to change SN16, PPCU, PPLD boards with SNAP, PPXL,PPXU
ones?

66

OMN:BSC

Y h ... 66
N h ... 67

Change the involved boards

Replace PPLD, PPCC, PPCU and SN16 boards with PPXL, PPXU and SNAP
ones.

67

Replace boards

Extract both MPCC-0 and TDPC-0 from the backplane and replace them with
new versions of boards (MPCCV8/TDPCV7).

68

Turn off both BSC powers

Switch down the whole rack.

69

Reconnect links to MPCC-0

Reconnect the flat cable (IDE) and hot links to the MPCC-0.

70

Reconnect links to TDPC-0

Reconnect hot links to the TDPC-0.

71

If required change O-link configuration

It required, change O-link configuration from X.25 to TCPIP.

i
72

To get more information refer to "3.73 Management of Links towards

Radio Commander/Cell Broadcast Centre"

Turn on BSC powers

Turn on BSC powers starting from the copy containing the new software (copy
1).
Note: MPCC firmware automatically starts with the bring up procedure,
retrieving the software and the database from the backup repository of disk copy
1.
Once the MPCC software starts, it detects that the content of the disks is not
aligned and initiate the crosscopy of DISK-0. At the end of the procedure both
disks are aligned.

A30808-X3247-L210-3-7619

131

OMN:BSC

73

Operation
Base Station Controller

Change BTSE and TRAU software version

The user can change step by step the software version of BTSE and TRAU
equipment, grouping them in groups of N network elements. In this way he can
avoid the complete loss of service. For the chosen BTSE and TRAU equipment,
after having set the administrative state to LOCKED, he must enter the
following sequence of selections

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> SET TRAU
and then he must set the EXPSWV parameter.

When the user set again the administrative state to UNLOCKED, the Expected
Sw Versions for TRAU and/or BTSE will be checked and the alignment with the
NE will start.

74

h ... END

Upgrade the new rack by Local Labs and install it in field

The first part of this upgrade can be performed by Local Labs.

The BSC with new rack must be delivered in field equipped as required, and
with the following features:
- PPXX issue >= 15
- usage of Adapter board for reusing existing PCM cables and PCM mapping
- BR7.0 BSC executable files (and patches) downloaded
- BR7.0 BTS and TRAU executable files downloaded
- the rack has been tested with an ad hoc DB
- the EEPROM of the board (PID) has been already programmed by the FTT
- Durach releases/downloads the floppy containing the Nob.
Then the rack must be installed in field.

75

Turn on new BSC rack powers

Turn on BSC powers.

Bring-up procedure starts, then the MPCC reached the providing service state.

76

Upload the database file from the old BSC rack to LMT

UPLOAD the current database file from BSC to BR6.0 LMT by executing the
following sequence of selections:

132

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT---> UPLFILE

A30808-X3247-L210-3-7619

Operation
Base Station Controller

77

OMN:BSC

Convert the Database

The Database conversion from BR6.0 format to BR7.0 format can be performed
using DBAEM/CONVFILE tools.
The expected SW versions of all the connected NEs should not modified during
database conversion, so that the previous SW versions are activated. Then it is
possible to change the expected SW version of a limited number of NEs, while
the others are still operational, and so on till the whole NEs are upgraded.
This procedure has the following advantages:

it reduces the BSS service unavailability (it is not needed to wait that all the
NE load together the new SW, while a good cell coverage strategy may allow
to provide the service in large areas);

it checks the BSC correctness before the BTSM/BTSMTD/TRAU upgrade;

it improves the control of the progress of the BTSM/BTSMTD/TRAU SW

activation.
NOTE: do not forget to use the right value (NTWSNAP_STLP) of NTWCARD
attribute.

78

i ..."3.134 Different
release Data
Base Conversions"

DOWNLOAD the converted database

DOWNLOAD the converted database from LMT to BSC disk, following the next
sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE MANAGEMENT ---> RSUDB -->

CREATE RSUDB
The system implicitly creates a new BSCESUDB object insstance.

79

Turn off the power of the old rack BSC

Turn off power: BSC outage starts now.

The outage lasts the time necessary to move the lines (using the cable adapter
this operation is fast) from the old rack to the new one and to align the NE.
The BSC gradually goes in service (the PCMS carrying the SS7 link should be
connected at first to allow to have the call available as soon as the BTS is
aligned).
For more details see the Service department procedures.

A30808-X3247-L210-3-7619

133

OMN:BSC

80

Operation
Base Station Controller

Change BTSE and TRAU software version

The user can change step by step the software version of BTSE and TRAU
equipment, grouping them in groups of N network elements. In this way he can
avoid the complete loss of service. For the chosen BTSE and TRAU equipment,after having set the administrative state to LOCKED, he must enter the
following sequence of selections

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> SET TRAU
and then he must set the EXPSWV parameter.

When the user set again the administrative state to UNLOCKED, the Expected
Sw Versions for TRAU and/or BTSE will be checked and the alignment with the
NE will start.

END

134

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.15

OMN:BSC

BSC Reload
Introduction
It could be necessary to reload BSC because of faults or software upgrades.
There are three ways to cause a reload:
1. the first one consists in switching off and on the power supply;
2. the second one is MPCC cards hardware reset;
3. the third one is performed by a SETRUNBACK command on the BSCOSUSW
object, which allows to reload the system. Using this command, the user forces the
system to restart, and to use the BSCESUSW instance marked as backup during
the reload procedure (i.e. the software load associated to that BSCESUSW
instance, is loaded).
The last operation performs a forced "Bring-Up". (This corresponds to the old "load
system" LOAD SW SYS command). This command is used to avoid switching off and
on the power supply, or reset MPCC cards, to re initialize the system
It allows the operator to reload the whole BSC system, executable files and Data Base,
from the BSC disk. The SETRUNBACK command is also used to perform a correct
procedure after MPCC Loading (see "3.4 MPCC loading").
The BSC application forces the MPCC loading by MPCC firmware and sets the partition
(sys_backup) where the firmware can find the MPCC executable file to load. When the
MPCC firmware ends the MPCC loading, it notifies to the Software the partition
(BackupEsu) and the device (disk copy-0 / disk copy-1) from which it has been loaded.
Then, all the system processors are loaded from disk with a normal Bring-up procedure (see "3.3 BSC "Bring-Up"").
If backupESU attribute of BSCOSUDB is different from empty value, then also the
backup database is loaded together with the backup SW load; otherwise a DEFAULT
database instance is automatically created and linked to the backupESU attribute.
During this procedure the LoadUsageState of BSCOSUSW is set to loadBackupESUsw and, at the end of the operation, it is reset to idle.
The procedure can automatically stop because of faults, such as executable files not
present or corrupted on disk.
If the user wants to execute a software re-initialization of the system without loading, he
must enter the System Initialization command (see "3.27 BSC Initialization").
Prerequisites

The LoadUsageState attribute of BSCOSUSW object, must be equal to idle

The precondition for acceptance of this command is that:

the bring up procedure is already finished;

the presence of MPCC, TDPC, IXLT executable files in the BSC disk;

the presence of:

PPLD, PPCC and PPCU processor executable files in the BSC disk in case of
standard BSC (see "1.4.1 Standard BSC");
PPXL and PPXU processor executable files in the BSC disk, in case of high
capacity BSCs equipped for GSM only;

A30808-X3247-L210-3-7619

135

OMN:BSC

Operation
Base Station Controller

PPXL ,PPXT, PPXP (and also PPXU if needed) processor executable files in the
BSC disk, in case of high capacity BSCs equipped for TD-SCDMA (see
"1.4.3.1 High Capacity BSC supporting TD-SCDMA Services").
The user must have the visibility level number set to "3".

Load the system

To load the whole system the user must enter the SETRUNBACK BSCOSUSW
command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> BSCOSUSW

---> SETRUNBACK BSCOSUSW

Result: The BSC is reloaded.

END

136

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.16

OMN:BSC

Upload of a Database File from BSC Disk

Introduction
This procedure performs the upload of a database file from BSC disk.
The user must specify:

the identity of the RSUDB object (or its User's label);

the destination directory on the LMT.
The user can specify if the file can overwrite a file already present

Prerequisites
The user must have the visibility level number set to "2"
The Network Element must be in phase "2"

Upload of a database file from BSC disk

The user must enter the UPLDFILE RSUDB command following the next
sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUDB

---> UPLDFILE RSUDB

Result: the chosen database file will be upload from the BSC to the LMT.

END

A30808-X3247-L210-3-7619

137

OMN:BSC

Operation
Base Station Controller

3.17

Changing the User Label for SW load header/database

files
Introduction
This procedure performs the change of the userLabel value (ULAB attribute) in order to
more easily handle the entire SW load or the single database file. In fact this operation
allows the user to give a new mnemonic name to a SW load or to a database.
The user must select the SW load header file (related to a SW load or to a database file)
for which he want to change the User Label, and then he have to write the new User
Label name.
It causes for BSC network element the automatic update of:

the userLabel attribute of the BSCESUSW instance related to the chosen SW load
header file

the userLabel attribute of the BSCESUDB instance related to the chosen database
file

It causes for BTSE, BTSEC or TRAU network elements the automatic update of the
userLabel attribute of the NEYESUSW related to the chosen SW load header file

BTSEC is the BTS equipment supporting TD-SCDMA features (BTSE for China).

If the specified userLabel value is already present, the command is rejected..

This command is similar to the MOVE command from source_directory to

destination_directory (used until the BR5.5 release) where source and destination
directory are different from SYS_BACKUP, SYS_NEW and SYS_FALLBACK,
since the directory was freely chosen by the user to identify the load in a mnemonic way
Prerequisites
The user must have the visibility level number set to "2"
The Network Element must be in phase "2"

Situations
Would you like to change the User Label of a SW Load?
Would you like to to change the User Label of a database file?

138

h ... 2
h ... 3

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Change the User Label of a SW Load

To change the User Label of a software load, the user must enter the SET
RSUSWLH command following the next sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH --->

SET RSUSWLH

Result: the chosen UserLabel will be assigned to the software Load

h ... END

Change the User Label of a database file

To change the User Label of a database file, the user must enter the
SET RSUDB command following the next sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUDB

---> SET RSUDB

Result: the chosen UserLabel will be assigned to the database file.

END

A30808-X3247-L210-3-7619

139

OMN:BSC

Operation
Base Station Controller

3.18

Loading Patch Files

Introduction
This procedure allows to load patch files. Patch files are parts of executable files; a patch
file is associated to a RSUPCH instance.
Patch files can be downloaded, loaded and enabled. If they are only downloaded (see
"3.8 Download of a Single Patch File on BSC Disk"), they are on the system disk,
however they cannot be used. If they are loaded and not enabled, they are running on
the system, but, in the case of a reload, only the enabled Patches will be reloaded. To
become a definitive part of the system, the Patch files must be enabled (see
"3.19 Enabling a patch file"). In this case, when reloading the system, they will also be
reloaded.
The loading patch files procedure triggers the loading, of the related patch file, in the
memory of the appropriate processor (MPCC, TDPC or PPXX).
Only RSUPCH instance with OperationalState equal to ENABLED and that are related
to runningESU software may be loaded in internal processor memory. If the RSUPCH
is successfully loaded, then its AvailabilityStatus is set from OFF DUTY to EMPTY
value.
This command is applicable only to RSUPCH instances with file name extension PCH.
Prerequisites
The user must have the visibility level number set to "2"
The Network Element must be in phase "2"

Load a patch file

To load a patch file, the user must enter the LOADPATCH RSUPCH command
following the next sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> RSUPCH ---> LOADPATCH RSUPCH

Result: the chosen patch file is loaded.

END

140

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.19

OMN:BSC

Enabling a patch file

Introduction
This procedure allows the user to change the PERM attribute value of a patch file (i.e.
of a RSUPCH instance).

PERM attribute is a boolean one, and then it can assume only the TRUE or FALSE
value. If this attribute is set to TRUE, the patch file is automatically reloaded at each
load of the BSCESUSW that contains it. If the PERM attribute is set to FALSE, then at
the next BSCESUSW reload the patch is no more automatically loaded.
With the same command it is also possible to change the PRIOSLOTN attribute and so
the loading sequence of patches at bring up.
A RSUPCH object instance with PERM attribute equal to TRUE is a part of a BSC SW
load; then if the patch file is ENABLED and the other RSUs (RSUSWLH and all the
RSUEXE of the same SW load) are ENABLED too, the related BSCESUSW is
ENABLED (its OperationalState is equal to ENABLED).
If the RSUPCH object instance has some problem (like file corruption) then its OperationalState and AvailabilityStatus are put in DISABLED-FAILED. The ProceduralStatus
is set to INITIALIZATION REQUIRED. The OperationalState of the related BSCESUSW is set to DISABLED and its AvailabilityStatus is set to OFF LINE because this
entity is no more able to provide service. Then an automatic download is performed by
BSC application: if it is successful then the RSUPCH and the related BSCESUSW
instances are enabled again.
If the automatic download is unsuccessful, then only setting PERM attribute value of this
RSUPCH to FALSE determines that the BSCESUSW is able to provide service again
(because the corrupted patch is no more part of it) and its OperationalState is set to
ENABLED value while its ProceduralStatus is set to EMPTY or to OFF DUTY value,
depending on if it is pointed by runningESU attribute of BSCOSUSW or not.

To know how an enabled patch file, of either MPCC or TDPC processors, can be
disabled without system downtime, please refer to "3.20 Unloading Patch Files".
Prerequisites
For a specific RSUPCH instance, it is allowed to SET the PERM attribute to TRUE only
if the OperationalState is equal to ENABLED and if the PRIOSLOTN attribute is not
NULL.Setting the attribute to FALSE is always allowed.
This command is applicable only to RSUPCH instances with the file name extension
PCH.
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".

A30808-X3247-L210-3-7619

141

OMN:BSC

Operation
Base Station Controller

Enable a patch file

To enable the patch file, the user must enter the SET RSUPCH command
following the next sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> RSUPCH ---> SET RSUPCH

Result: the chosen patch file is enabled.

END

142

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.20

OMN:BSC

Unloading Patch Files

Introduction
This procedure allows to disable a single patch file in the system.
As it has been described in "3.8 Download of a Single Patch File on BSC Disk", patch
files are handled by the RSUPCH object.
When a patch file, that has been previously enabled (see "3.19 Enabling a patch file")
, is no more necessary, it must be disabled. In case of either MPCC or TDPC processor,
it is important to remove the patch without reloading the card, because the MPCC
reloading (bring-up) or the TDPC reloading (full init) implies a system downtime and so
a loss of all current calls
To remove a patch without any system downtime and the consequent loss of all current
calls, it is necessary to load another patch that modifies the processor code returning to
the original one. This particular patch is called unpatch. Unpatch files (like patch ones)
are handled by the RSUPCH object.

The unpatches have the same file_name of the related patches, with .BAK file extension (rember that patches files have always .PCH file extension); e.g. if the patch file is
called M2710S0063.PCH, the corressponding unpatch file is called M2710S0063.BAK.
To disable a patch, the following operations must be executed:
1. download of the unpatch file corresponding to the patch to be disabled; to download
the unpatch file the same command and attributes used for downloading patch file
is used (i.e. the CREATE RSUPCH one). The following conditions must be satisfied
when downloading an unpatch file:
the file_name extension must be .BAK;
the corresponding patch object must be present; the corresponding patch object
must have the same file_name and the extension .PCH;
the PERM attribute must be set to FALSE and the PRIOSLOTN must be NULL or
SKIPPED
The unpatch SW version must be compatible with the one of the RSUEXE
containing it.

If one of the first three conditions is not satisfied, the create command is
rejected.
If the fourth condition is not satisfied the Operational State of the related
RSUPCH object instance is marked as DISABLED, and its Availability
Status is put FAILED.
Maximum 200 instances of the RSUPCH object can be created, for what
concern unpatch files (the other 200 possible instances regard the corresponding patch files)

2. set the PERM attribute of the patch file to FALSE, and disable the patch by
executing the UNLOADPCH command.

A30808-X3247-L210-3-7619

It is important to underline that these actions are applied to the PATCH

previously loaded and not on the related unpatch file. This means that the
messages sent to the LMT are related to the RSUPCH object instance
related to the patch file (and not to the corresponding unpatch one).

143

OMN:BSC

Operation
Base Station Controller

If the RSUPCH is succesfully unloaded, then its AvailabilityStatus is set from EMPTY
to OFF_DUTY value.
Prerequisites
The RSUPCH instance (unpatch file) can be created only if the corresponding one (i.e.
the RSUPCH instance related to the corresponding patch fileto be disabled) has been
previously created.
To execute the UNLOADPCH command succesfully, the following conditons must be
verified:

the Availability Status attribute of the RSUPCH object instance, related to the patch
file to be disabled, must be NONE;
the Operational State attribute of the RSUPCH object instance, related to the patch
file to be disabled, must be ENABLE.
the related RSUPCH unpatch must be present and ENABLED
The RSUPCH patch must be related to runningESU software

The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Download the UNPATCH file on BSC disk

Enter the CREATE RSUPCH command following the next sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> RSUPCH ---> CREATE RSUPCH
then select the .BAK file with the same file_name of the the patch file to be
disabled.

Result: the chosen file will be download to the BSC.

Set the PERM attribute of the PATCH file to FALSE

Enter the SET RSUPCH command following the next sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> RSUPCH --->SET RSUPCH
then select the RSUPCH instance related to the PATCH file to be unloaded and
set the PERM parameter to FALSE.

144

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Unload the PATCH file

Enter the UNLOADPCH RSUPCH command following the next sequence of

selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> RSUSWLH

---> RSUEXE ---> RSUPCH ---> UNLOADPCH RSUPCH
then select the RSUPCH instance related to the PATCH file to be unloaded.

Result: the patch file is unloaded.

END

A30808-X3247-L210-3-7619

145

OMN:BSC

Operation
Base Station Controller

3.21

Get Information about SW Version

Introduction
This procedure allows the user to get information about a SW version. The operation
involves all the network elements: BSC, BTSE, BTSEC and TRAU

BTSEC is the BTS equipment supporting TD-SCDMA features (BTSE for China).

GET SW INFORMATION ABOUT A BSC

If the user wants to get information about a BSC, in order to display to the user the
requested information, the following set of internal operations are done for each
BSCESUSW instance present on the BSC disk:
analyse the relatedRSU attribute of BSCESUSW to obtain the RSUSWLH instance;
analyse the userLabel of RSUSWLH to know the user-defined string that identifies the
SW load header;
analyse the RSUSWLH version to know the numerical version of the SW load header;
analyse the RSUSWLH relatedFile to know the physical file name;
analyse the OperationalState of RSUSWLH to know if the RSUSWLH instance is
usable or not;
analyse the ProcType attribute of the RSUEXE instance contained by the RSUSWLH
to have a list of processors loaded;
analyse the RSUEXE version to know the numerical version of each executable file;
analyse the RSUEXE relatedFile to know the physical file name;
analyse the OperationalState of the RSUEXEto know if the RSUEXE instance is
usable or not;
analyse the RSUPCH ProcType to know if the patch is for MPCC, TDPC, PPCU,
PPXU, PPXL, PPXT or PPXP processors (PPXT and PPXP processors regard TDSCDMA only);
analyse the RSUPCH userLabel to know the user-friendly name of the patch;
analyse the PERM attribute of RSUPCH to know the enabled patches (TRUE value)
and the disabled ones (FALSE value);
analyse the RSUPCH relatedFile to know the physical file name;
analyse the RSUPCH OperationalState to know if the RSUPCH instance is usable or
not;
analyse RSUPCH AvailabilityStatus to know the loaded patches (EMPTY value) and
the not loaded ones (OFF DUTY value) (only for runningESU attribute);
display if this BSCESUSW is pointed by one (or more or none) of the backupESU,
runningESU, newESU or fallbackESU attribute of the BSCOSUSW (this is the
"used_as" field).
The output message shown, for each BSCESUSW instance, is the following:

146

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

RSUSWLH

instance, userLabel, version, relatedFiles, OperationalState

instance, ProcType, version, relatedFiles, OperationalState

RSUEXE (one for each

executable file present in
the SW load header)
RSUPCH (if any patch files instance, ProcType, userLabel, Permanent (PERM),
are present)
relatedFiles, OperationalState, AvailabilityStatus
used_as
runningESU/backupESU/newESU/fallbackESU/notUsed

GET SW INFORMATION ABOUT A BTSE/BTSEC/TRAU

If the user wants to get information about a BTSE/BTSEC/TRAU, in order to display to
the user the requested information, the following set of internal operations are done for
each NEYESUSW instance present on the BSC disk:
analyse the relatedRSU attribute of NEYESUSW to obtain the RSUSWLH instance;
analyse the RSUSWLH NEyType to know if the SW load is for BTSE, BTSEC or
TRAU network element;
analyse the userLabel of RSUSWLH to know the user-defined string that identifies the
SW load header;
analyse the RSUSWLH version to know the numerical version of the SW load header;
analyse the RSUSWLH relatedFile to know the physical file name;
analyse the OperationalState of RSUSWLH to know if the RSUSWLH instance is
usable or not;
analyse the ProcType attribute of the RSUEXE instance contained by the RSUSWLH
to have a list of processors loaded;
analyse the RSUEXE version to know the numerical version of each executable file;
analyse the RSUEXE relatedFile to know the physical file name;
analyse the OperationalState of the RSUEXEto know if the RSUEXE instance is
usable or not;
display if this NEYESUSW is pointed by one (or more or none) of the backupESU or
runningESU attribute of the BTSMOSUSW/BTSMTDOSUSW/TRAUOSUSW
instances. If this NEYESUSW is pointed by the backupESU attribute of a
BTSMOSUSW/BTSMTDOSUSW/TRAUOSUSW, then display the network element
list (BTSE, BTSEC or TRAU) for which this NEYESUSW instance is backupESU.
The output message shown, for each NEYESUSW instance, is the following:
RSUSWLH
RSUEXE (one for each
executable file present in
the SW load header)
listOfNE

A30808-X3247-L210-3-7619

instance, NEyType, userLabel, version, relatedFiles,

OperationalState
instance, ProcType, version, relatedFiles, OperationalState
display the network element list (BTSE, BTSEC or
TRAU) for which this NEYESUSW instance is
backupESU.

147

OMN:BSC

Operation
Base Station Controller

Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".

Situations
Would you like to get SW information about a BSC?
Would you like to get SW information about a BTSE/TRAU?

h ... 2
h ... 3

Get SW information about a BSC

To get SW information about a BSC, the user must enter the

GETINFO BSCESUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCESUSW

---> GETINFO BSCESUSW

Result: BSC SW Version is displayed

Get SW information about a BTSE/BTSEC/TRAU

To get SW information about a BTSE/BTSEC/TRAU, the user must enter the

GETINFO NEYESUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> NEYESUSW

---> GETINFO NEYESUSW

Result: BTSE/BTSEC/TRAU SW Version is displayed

END

148

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.22

OMN:BSC

Setting a Generic SW Load as Backup, Fallback, or

New SW Load
Introduction
This procedure allows the user to set a generic SW load as:

backup SW load, (this correspond to the old download of a complete software in

SYS_BACKUP directory) or
fallback SW load, (this correspond to the old download of a complete software in
SYS_FALLBACK directory) or
new SW load (this correspond to the old download of a complete software in
SYS_NEW directory).

The user identifies the generic SW load to be set, either by userLabel or by version
attribute (i.e. the user selects a BSCESUSW instance); then the selected SW load is
marked respectively as backupESU, fallbackESU or newESU.
When the user choose to set the SW load as backup one, the BSC application sets the
partition (sys_backup) where the firmware can find the MPCC executable file to load.
If the generic SW load is not compatible with the backup database instance, then the
backupESU attribute of the BSCOSUDB is set to null pointer.
When the user choose to set the SW load as fallback one, the BSC application sets
the partition (sys_fallback) where the firmware can find the MPCC executable file to
load.
If the generic SW load is not compatible with the fallback database instance, then the
fallbackESU attribute of the BSCOSUDB is set to null pointer.
When the user chooses to set the SW load as new one, the BSC application sets the
partition (sys_new) where the firmware can find the MPCC executable file to load.
If the generic SW load is not compatible with the new database instance then the
newESU attribute of the BSCOSUDB is set to null pointer.
Prerequisites
The BSC system must be in normal exercise.
The generic SW load must be enabled (its OperationalState must be equal to
ENABLED)
No crosscopy disk has to be in progress.
The system must be able, at that moment, to make actual this SW assignment also in
the specific FW partition (SYS_BACKUP, SYS_FALLBACK or SYS_NEW).
The user must have the visibility level number set to "2"
The Network Element must be in phase "2"

A30808-X3247-L210-3-7619

149

OMN:BSC

Operation
Base Station Controller

Situations

h ... 2
h ... 3
h ... 4

Would you like to set the generic SW load as backup one?

Would you like to set the generic SW load as fallback one?
Would you like to set the generic SW load as new one?

Set the SW load as backup one

To set a generic SW load as backup one, the user must enter the
SET BSCOSUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCOSUSW

---> SET BSCOSUSW

Then the user must choose a generic SW load, and set the ACTN attribute as
BACKUP_ESU

h ... END

Result: the SW load becomes the backup SW load

Set the SW load as fallback one

To set a generic SW load as fallback one, the user must enter the
SET BSCOSUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCOSUSW

---> SET BSCOSUSW

Then the user must choose a generic SW load, and set the ACTN attribute as
FALLBACK_ESU

h ... END

Result: the SW load becomes the fallback SW load

Set the SW load as new one

To set a generic SW load as new one, the user must enter the
SET BSCOSUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCOSUSW

---> SET BSCOSUSW

Then the user must choose a generic SW load, and set the ACTN attribute as
NEW_ESU
Result: the SW load becomes the new SW load

END

150

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.23

OMN:BSC

Loading a Database File

Introduction
To load a database file the user must set the BSCOSUDB object from newESU to
runningESU; in this way, the BSCESUDB instance that was marked as new, becomes
the running one.
From the BSC point of view, setting the attribute runningESU to newESU value corresponds to the Load database from SYS_NEW directory command, used until the
BR5.5 release. During this procedure LoadUsageState of the BSCOSUSW object is
set to loadNewESUdb (the BSC application is executing the database initialisation and
the database loading) and when the loading operation is terminated, the state is reset
to idle. Subsequently a setting of newESU to backupESU attribute is automatically
performed.
If the SET operation fails during loading phase, and backupESU attribute is different
from newESU value, then the BSC application automatically schedules a new Load
database from backup directory (like a recovery procedure). If also this loading fails then
a new BRING-UP initialisation is scheduled.
If backupESU attribute is already equal to newESU value then the BSC application automatically schedules a new BRING-UP initialisation like recovery procedure.
Prerequisites
The BSC system must be in normal exercise.
BSCESUDB instance must be ENABLED.
Both backupESU attributes of BSCOSUSW and BSCOSUDB objects must be present
(defferent from NULL value) and ENABLED.
BSCESUDB object must be compatible with the currently running BSCESUSW object.
BSCESUDB object must be compatible with the network type present.
runningESU and backupESU attributes of BSCOSUDB object must be aligned (i.e.:
equal).
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".

Load the database

To load the new database, the user must enter the SETRUNNEW BSCOSUDB
command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCOSUDB

---> SETRUNNEW BSCOSUDB

Result: the new database is loaded

END

A30808-X3247-L210-3-7619

151

OMN:BSC

Operation
Base Station Controller

3.24

Setting a Generic Database as Backup, Fallback, or

New Database
Introduction
This procedure allows the user to set a generic database as:

backup database (corresponds to the old download of a database file in

SYS_BACKUP directory) or
fallback database (corresponds to the old download of a database file in
SYS_FALLBACK directory), or
new database (corresponds to the old download of a database file in SYS_NEW
directory).

The user identifies the generic database to be set, either by userLaber or by

BSCESUDB object identifier (i.e. the user selects a BSCESUDB instance); then the
selected database is marked respectively as backupESU, fallbackESU or newESU.
When the user chose to set the database as backup one, if the generic database is not
compatible with the backup software instance (i.e. the BSCESUSW instance marked
as backup), then this operation is rejected
When the user chose to set the database as fallback one, if the generic database is
not compatible with the fallback software instance (i.e. the BSCESUSW instance
marked as fallback), then this operation is rejected
When the user chose to set the database as new one, if the generic database is not
compatible with the new software instance (i.e. the BSCESUSW instance marked as
new), then this operation is rejected.
Prerequisites
The BSC system must be in normal exercise.
The generic database (i.e. the generic BSCESUDB instance) must be enabled (its
OperationalState must be equal to ENABLED)
The generic database must be compatible with the related software instance.
The user must have the visibility level number set to "2"
The Network Element must be in phase "2"

Situations
Would you like to set the generic database as backup one?
Would you like to set the generic database as fallback one?
Would you like to set the generic database as new one?

152

h ... 2
h ... 3
h ... 4

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set the database as backup one

To set a generic database as backup one, the user must enter the
SET BSCOSUDB command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCOSUDB

---> SET BSCOSUDB

Then the user must chose a generic database, and set the ACTN attribute as
BACKUP_ESU
Result: the database becomes the backup database

h ... END

Set the database as fallback one

To set a generic database as fallback one, the user must enter the
SET BSCOSUDB command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCOSUDB

---> SET BSCOSUDB

Then the user must chose a generic database, and set the ACTN attribute as
FALLBACK_ESU
Result: the database becomes the fallback database

h ... END

Set the database as new one

To set a generic database as new one, the user must enter the
SET BSCOSUDB command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOTWARE-MANAGEMENT ---> BSCOSUDB

---> SET BSCOSUDB

Then the user must chose a generic database, and set the ACTN attribute as
NEW_ESU
Result: the database becomes the new database

END

A30808-X3247-L210-3-7619

153

OMN:BSC

Operation
Base Station Controller

3.25

Saving Database Configuration

Introduction
This procedure allows the user to save the running configuration commands, entered
after the last save operation, in the backup database instance.
This procedure determines:

the update of the version attribute (at least for the date part) of the RSUDB instance
associated to the running database;
the update of the related BSCESUDB.

Prerequisites
The BSC system must be in normal exercise (no other command has to be in progress).
The user must have the visibility level number set to "2"
The Network Element must be in phase "2"

Save database configuration

The user must enter the SAVEDB BSCOSUDB command following the next
sequence of selections:

MANAGED-ELEMENT ----> SOFTWARE-MANAGEMENT ---> BSCOSUDB

---> SAVEDB BSCOSUDB

Result: the database configuration is saved.

END

154

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.26

OMN:BSC

Download and Activate BTSE, BTSEC and TRAU SW

Loads
Introduction
To download a BTSE, BTSEC or a TRAU SW load, the user can use the NEDOWNLOAD NEYESUSW command, specifying if the concerned NE is a BTSE, a BTSEC or
a TRAUE, and the related instance.

BTSEC is the BTS equipment supporting TD-SCDMA features (BTSE for China).
Then, to activate the software load, the user performs respectively:

a SETRUNBACK command on the BTSMOSUSW object (the BTSMOSUSW object

instance related to a BTSM is automatically created after the creation of the BTSM
object instance, see "3.39 Addition of a New Site Manager and of related LAPD
links");
a SETRUNBACK command on the TRAUOSUSW object (the TRAUOSUSW object
instance related to a TRAU is automatically created after the creation of the TRAU
object instance, see "3.71 Addition of a TRAU to the System").
a SETRUNBACK command on the BTSMTDOSUSW object, in case of TD-SCDMA
base station equipment (the BTSMTDOSUSW object instance related to a BTSMTD
is automatically created after the creation of the BTSMTD object instance, see
"3.120 Addition of a New TD-SCDMA Site Manager and of Related LAPD Links");

The user must specify the number of BTSE, BTSEC or TRAUE instance to activate.
Using this commands, the user forces the system to activate the NEYESUSW instance
(related to BTSE, BTSEC or TRAUE) marked as backup (i.e. the software load associated to that NEYESUSW instance is activated, and it is marked as running too).
Each time a particular Network Element SW load must be activated, the database
expectedSwVersion variable must be set to it, because only the software specified by
the expectedSwVersion can be the running one.
Consequently this precondition determines that the backupESU attribute of the BTSMOSUSW/BTSMTDOSUSW/TRAUOSUSW object is automatically set to the NEYESUSW
instance whose version matches with the expectedSwVersion value.
This operation is automatically performed when the operator sets the "expected sw
version" attribute (EXPSWV), either during creation or setting of:

a TRAU object instance (see, "3.71 Addition of a TRAU to the System");

a BTSM object instance (see, "3.39 Addition of a New Site Manager and of related
LAPD links").

a BTSMTD object instance (see, "3.120 Addition of a New TD-SCDMA Site

Manager and of Related LAPD Links").

It follows that the NEYESUSW instance pointed by backupESU attribute, and the
"expected sw version" coincide. If this NEYESUSW object instance is not present on
BSC disk then it is automatically created, but its Operational State is DISABLED.

A30808-X3247-L210-3-7619

155

OMN:BSC

Operation
Base Station Controller

When the user sets the expected software version the specified SW load (i.e. NEYESUSW) must be enabled (its OperationalState must be equal to ENABLED). If the
previous precondition is not satisfied and/or if the dbVersion required is not stored on
BSC disk an ErrorCollector with esu not available or wrong sw version error is sent
to the LMT.
The BTSE, BTSEC or TRAUE activation allows to Bring-Up the NE with the specified
SW load. Then, due to link connection loss between BSC and the specific network
element, an automatic alignment is performed.
Regarding TRAU equipment three different software loads can be downloaded to DSPs
of TRAC boards:
a) the first executable - named S1xxxx.BIN - manages the following transcoders:

Full Rate (FR Speech Version 1);

Half Rate (HR Speech Version 1);
Enhanced Full Rate (FR Speech Version 2);
all circuit switched data services up to 14.5 kbit/s, including HSCSD.

b) the second executable - named S2xxxx.BIN - manages the Narrow Band Adaptive
Multi Rate (FR and HR Speech Version 3);
c) the third executable, named S3xxxx.BIN, has been introduced in BR7.0 release (the
previous two regard BR6.0 release) and it includes both S1xxxx.BIN and
S2xxxx.BIN functionalities.
Besides, four different TRAC boards are supported, with the following features:

TRACv1: it manages only S1xxxx.BIN executable;

TRACv3: it manages only S1xxxx.BIN executable;

TRACv5: it manages either S1xxxx.BIN executable or the S2xxxx.BIN one;

TRACv7: it manages all the executable types.

So, while TRACv1, TRACv3 and TRACv5 are not able to manage all the functionalities
of both S1xxxx.BIN and S2xxxx.BIN executable at the same time, the TRAv7 board is
able to manage them.
All the BR7.0 TRAU loads will be characterized by having the S3xxxx.BIN executable in
the software load. Then the following software loads will be available for TRAU equipment:

YY-YY-YY-01-XX-XX_yy_mm_dd; it is a BR6.0 software load containing S1xxxx.BIN

executable;
YY-YY-YY-02-XX-XX_yy_mm_dd, it is a BR6.0 software load containing S2xxxx.BIN
executable;
YY-YY-YY-03-XX-XX_yy_mm_dd; it is a BR7.0 software load containing S3xxxx.BIN
executable;

In fact when S3xxxx.BIN executable is loaded, and e.g. only TRACv3 is installed, only
the functionalities belonging to S1xxxx.BIN will be exploited, among those provided by
S3xxxx.BIN executable; in this case if a TSLA is erroneously configured as "AMR", the
TRACv1 goes disabled. as well as TRACv3.
So according to the board type, a subset of all S3xxxx.BIN functionalities can be
exploited, and only TRACv7 can manage all of them at the same time.

156

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The TRACv7 is also able to support the previous loads (S1xxxx.BIN and S2xxxx.BIN),
to allow to use these boards in TRAU equipment containing also TRAC boards
belonging to other versions (v1, v3 or v5).
Prerequisites
The database expectedSwVersion variable must equal to sw version to activate.
The user must have the visibility level number set to "2"
The Network Element must be in phase "2"
The software to be downloaded to the NE has previously been downloaded in BSC disk.

Situations
Would you like to download and activate a TRAU SW load?
Would you like to download and activate a BTSE SW load?
Would you like to download and activate a BTSEC SW load?

h ... 2
h ... 4
h ... 6

Download a TRAUE SW load

To download a TRAUE SW load, enter the NEDOWNLOAD NEYESUSW

command, with the parameter NTWEL set to TRAUE, following the next
sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

NEDOWNLOAD NEYESUSW

Result: the TRAU SW download is started

Activate a TRAUE SW load

To activate a TRAUE SW load, enter the SETRUNBACK TRAUOSUSW

command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU --->

TRAUOSUSW ---> SETRUNBACK TRAUOSUSW

Result: the TRAUE SW load is activated

h ... END

Download a BTSE SW load

To download a BTSE SW load, enter the NEDOWNLOAD NEYESUSW

command, with phe parameter NTWEL set to BTSE, following the next
sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

---> NEDOWNLOAD NEYESUSW

Result: the BTSE SW download is started

A30808-X3247-L210-3-7619

157

OMN:BSC

Operation
Base Station Controller

Activate a BTSE SW load

To activate a BTSE SW load, enter the SETRUNBACK BTSMOSUSW

command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTSMOSUSW --> SETRUNBACK BTSMOSUSW

h ... END

Result: the BTSE SW load is activated

Download a BTSEC SW load

To download a BTSEC SW load, enter the NEDOWNLOAD NEYESUSW

command, with the parameter NTWEL set at BTSEC, following the next
sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> NEYESUSW --->

---> NEDOWNLOAD NEYESUSW

Result: the BTSEC SW download is started

Activate a BTSEC SW load

To activate a BTSEC SW load, the user must enter the SETRUNBACK

BTSMTDOSUSW command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD --->

BTSMTDOSUSW ---> SETRUNBACK BTSMTDOSUSW

Result: the BTSEC SW load is activated

END

158

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.27

OMN:BSC

BSC Initialization
Introduction
This procedure allows the user to perform an initialisation on BSC system. This procedure allows the system to restart the software from a known state. There are three types
of initialization that the user can select:

"BU_ACTIVE" (BRING_UP) initialization, performed at the highest level (the

command execution takes at least 5 minutes( the actual command execution time
depends on the size of DB to be loaded). It starts a "Bring-Up" procedure (see
"3.4 MPCC loading"). The Load Usage State attribute of BSCOSUSW object
instance is set to loadBackupEsusw; at the end of initialization it is reset to IDLE.
FULL initialization involves reset of all dynamic areas of the memory and causes the
release of all connections in progress (see "3.3 BSC "Bring-Up""). It also closes all
open files. It is mainly used when a task does not end correctly.
TASK_PRIME causes the release of the connections which are currently in the setup
phase. This level can only be applied to the MPCC processor.

When the initialization level is equal to BRING_UP or FULL, the link between BSC and
NE fall down; when this link is restored an automatic NE alignment procedure is
performed.
Prerequisites
If the BSC application is executing the Bring_up or Change Version and, if MPCC is
involved, the FULL is upgraded to BU_ACTIVE.
TASK_PRIME init level is rejected if:

MPCC,TDPC or PPXX load patch are in progress;

the BSC application is executing a Change Version;
the BSC application is executing a Saving Database Configuration.

For all types of initialization the user must have the visibility level set to number "3" and
the Network Element must be in phase 2.

Initialize the system

To initialize the system the user must enter the SYSINIT SYSINIT command
following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT---> SYSINIT

---> SYSINIT SYSINIT

Result: Initialization of the system.

END

A30808-X3247-L210-3-7619

159

OMN:BSC

Operation
Base Station Controller

3.28

Upload of BSC Log File from LMT

Prerequisites
This procedure allows to get contents on the BSC event log-file (that is stored on BSC
disk directory LOG).
The event log-file is automatically created by the system and it is always available for
the transfer. When Users request to upload it, the BSC event log-files is frozen and its
data are transferred to the LMT.
The log file is a binary file, so its content cannot be read directly; to provide a clean and
well-formatted report, an offline tool is provided in the LMT (see "3.31 Decoding Log
files").
Events generated by the system during the UPLOAD command execution are stored in
other log-file instances; they will be available for the next UPLOAD request.

Upload the BSC logfile

The user must execute the UPLFILE command following the next sequence of
selections:

MANAGED-ELEMENTS ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> UPLPRLOG FILEHANDLER

The next series of fields must be mandatorily filled in:

DESTDIR: specifies the complete destination path of the log-file created on
LMT.
OVERWRITE: it allows to overwrite the already existing log-file (if identical
path names are used for DESTDIR).
LOGTYPE: it specifies the type of log. To get event log files, the user must
specify the EVTLOG value.
Result: the BSC event logfile is uploaded to the specified destination directory in
the LMT (refer to OGL LMT manual).

END

160

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.29

OMN:BSC

Upload of a TRAU Log File from LMT

Introduction
This procedure allows to get contents of the TRAU event log-file.
The number of TRAU on which the command has to be executed must be specified.
The log file is a binary file, so its content cannot be read directly; to provide a clean and
well-formatted report, an offline tool is provided in the LMT (see "3.31 Decoding Log
files").
The user must have the visibility level number set to "3".

Upload logfile from TRAU

The user must execute the UPLTRAULOG command following the next
sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> UPLTRAULOG

The next series of fields must mandatorily be filled in:

INSTANCE: specifies the instance of TRAU;
DESTDIR: specifies the complete destination path of the log-file created by
the UPLTRAULOG command;
FILE: name of the file to be stored in DESTDIR which contains the event log
information;
FILETYPE: its default value is EVENT LOG (already displayed in the choice
window);
OVERWRITE: it either allows to overwrite the already existing log-file (YES)
or save (append) the new updating information, only (NO).
Result: upload of a TRAU log file. For the explanation of the error messages that
can be generated, see the ITMN:TRAU manual.

END

A30808-X3247-L210-3-7619

161

OMN:BSC

Operation
Base Station Controller

3.30

Upload of a BTSE Log File from LMT

Introduction
This procedure allows to get contents of the BTSE event log-file.
The number of BTSEs on which the command has to be executed must be specified.
The log file is a binary file, so its content cannot be read directly; to provide a clean and
well-formatted report, an offline tool is provided in the LMT (see "3.31 Decoding Log
files").
The user must have the visibility level number set at "3".

Upload logfile from BTSE

The user must execute the UPLBTSLOG command following the next sequence
of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> UPLBTSLOG

The next series of fields must mandatorily be filled in:

INSTANCE: specifies the instance of the BTSE (i.e. the BTSE number);
DESTDIR: specifies the complete destination path of the log-file created by
the UPLTBTSLOG command;
FILE: name of the file to be stored in DESTDIR which contains the event log
information;
FILETYPE: its default value is ALARM_BUFFER (already displayed in the
choice window);
OVERWRITE: it either allows to overwrite the already existing log-file (YES
option), or to save (append) the new updating information (NO option).
Result: the BTSE event logfile is uploaded to the specified destination directory
in the LMT.

END

162

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.31

OMN:BSC

Decoding Log files

Introduction
The Logdec application has been created in order to decode binary information stored
within the log-file. Such an application runs in an off-line version.
Binary log files must be previously uploaded from the network elements into the LMT;
then they can be decoded using Logdec application. These binary files regards:

BSC event log files (see "3.28 Upload of BSC Log File from LMT");
TRAU event log files (see "3.29 Upload of a TRAU Log File from LMT");
BTSE event log files (see "3.30 Upload of a BTSE Log File from LMT");
Measurement log files (see "3.138 Upload of the Measurement Results").

The Decoding tool is integrated within the dashboard of LMT. By clicking on the DEC
button (highlighted by the cursor in the Fig. 3.6) the starting menu is activated.

A30808-X3247-L210-3-7619

163

OMN:BSC

Operation
Base Station Controller

Launch the Logdec application

To launch the Logdec application, the user must click the DEC button on the
LMT dashboard :

Result: the Logdec starting window is displayed (see below).

164

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Open the Compressor panel

To open the Compressor panel, the user must click the Compressor button on
the Logdec panel:

1. Select the source zip file that you want to uncompress.

2. Select the destination directory where you want to put the uncompressed file.
3. Press Uncompress button.
4. Select Close button.

i
3

Using Compressor it is possible to uncompress a zip file to one or more log files,
depending on the content of zip file.

Chose the log file type

Would you like to see measurement log files?
Would you like to see event log files?

h ... 4
h ... 5

Select measurement log file type

To select measurement log file type the user must click the <Measurement>
button in the Logdec starting window.

A30808-X3247-L210-3-7619

h ... 10

165

OMN:BSC

Operation
Base Station Controller

Select event log file type

To select event log file type the user must click the <Event Log> button in the
Logdec starting window.

Select the network element

Would you like to see BSC log files ?
Would you like to see TRAU log files ?
Would you like to see BTSE log files ?

Chose BSC log files

To select BSC log files the user must select the BSC item.

h ... 10

Chose BTSE log files

To select BTSE log files the user must select the BTSE item.

10

h ... 10

Chose TRAU log files

To select TRAU log files the user must select the TRAU item.

h ... 7
h ... 8
h ... 9

h ... 10

Open the log file

1. Display the Open window, clicking on the <File Open> button
2. Select the log file that you want to open

11

Decode the log file

To decode the selected file, click the <Decode button> .

Result: when decoding phase ends, a window will display the number of
decoded messages. The operator is asked (with the Message window)
whether he wants to read the decoding results.

12

Confirm the operation

To read the decoded file the user must click the <Yes> button. The file can be
read by means of Notepad or the WordPad (depending on log-file size).

END

166

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.32

OMN:BSC

System Disk Formatting

Introduction
To format the system disk the user must enter the FORMAT DISK command.
The copy (0 or 1) of the disk being formatted should be specified. It is possible to format
both system disks too. No matter what is the operational state of the disk (ENABLED or
DISABLED), the state will be changed to DISABLED as soon as the command is
submitted. At the end of the command execution, the disk having successfully formatted
will change to the ENABLED state.

The formatting of a disk causes the total loss of its content.

Prerequisites
If the user wants to format only one copy, this copy has to be in the LOCKED administrative state, otherwise the command is rejected (invalid administrative state). If the
format operation is successful, the disk administrative state must be reset to
UNLOCKED by the user.
Since this operation sets to DISABLED the disk operational state (the disk is not aligned
with respect to the other copy), the system automatically starts the cross-copying and,
if it is successful, puts the disk into service. The formatting of a single copy of a disk can
be selected only if both disks are present and in service.
If the user wants to format both copies, the administrative state of the two disks must
be LOCKED and their superordinate states must be UNLOCKED and ENABLED, no
matter the operating state of the disk. This operation causes the loss of data on both
disks.
The user must have the visibility level number set to "2".

Lock all the disks to be formatted

The user must lock all the disks he wants to format by entering the LOCK DISK
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

LOCK DISK

Result: the DISK object assumes the state: locked/enabled.

Format one or both of the system disks

To format one or both of the system disks the user must enter the FORMAT
DISK command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

FORMAT DISK

Result: one or both copies of the system disks are formatted. The command
execution takes about 15 seconds for each disk.

A30808-X3247-L210-3-7619

167

OMN:BSC

Operation
Base Station Controller

Unlock the disks

Tthe user must unlock the disks he has formatting by entering the UNLOCK
DISK command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> DISK --->

UNLOCK DISK

Result: unlocking of the formatted copies, when the last disk is unlocked, a disk
cross-copy procedure is started to place the disk into service (approximately the
cross-copy operation copies requires 5 Mbyte/minute).

END

168

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.33

OMN:BSC

System Disk File and Directory Management

Introduction
The system disk is used as a local bulk memory for storing the software load files.
Each system directory provides executable files for loading various BSS processors.
Besides executable files, disk directories contain database files, configuration information, and other files needed during the system's operation.
Reading and writing operations on the same file are not allowed by the file system.
File system management is split into two domains:
1. management of files;
2. management of directories.
The following operation are provided to manage files on the BSC disk:

delete a generic file;

copy a file;

move a file;

compression of files;

decompression of files.

The following operation are provided to manage directories on the BSC disk:

display of the files of a directory;

create a directory;

remove a directory.

Prerequisites
The user must have the visibility level number set to "3".

Preliminary Consideration

Do you want to manage

files on the system disk
directories of the system disk

h ... 2
h ... 3

Choose an option for the management of the files on the system disk:
delete a generic file
copy a file
move a file
file compression
file decompression

A30808-X3247-L210-3-7619

h ... 4
h ... 5
h ... 6
h ... 7
h ... 8

169

OMN:BSC

Operation
Base Station Controller

Choose an option for the management of the directories on the system

disk:

h ... 9
h ... 10
h ... 11

display the files of a directory

create a directory
delete a directory

Delete a generic file

To delete a generic file, the user must enter the DELETE FILEHANDLER
GENFILE command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> DELETE FILEHANDLER GENFILE

Then the user must insert the path of the file to be deleted, using the
PATHNAME attribute.

h ... END

Result: the selected file is deleted.

Copy a file

To copy a file, the user must enter the COPY FILEHANDLER command,
following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> COPY FILEHANDLER

Then the user must indicate:

- the path where the file is actually saved, using the SRCPATHNAME attribute;
- the path where the file has to be copied to, using the DSTPATHNAME attribute.

h ... END

Result: the selected file is copied.

Move a file

To move a generic file, the user must enter the MOVE FILEHANDLER
command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> MOVE FILEHANDLER

Then the user must indicate:

- the path where the file has to be taken from, using the SRCPATHNAME
attribute;
- the path where the file has to be copied to, using the DESTPATHNAME
attribute.
Result: the selected file is moved

170

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

File compression

To make a file compression, the user must enter the FILECOM FILEHANDLER
command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> FILECOM FILEHANDLER

Then the user must indicate:

- the directory where the compressed file has to be created, using the TARGDIR
attribute;
- the directory where the file to be compressed is actually saved, using the
SRCDIR attribute
- the name of the compressed file , using the TARGF attribute.
Result: the selected file is compressed

h ... END

File decompression

To make a file decompression, the user must enter the FILEDECOM FILEHANDLER command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> FILEDECOM FILEHANDLER

Then the user must indicate:

- the directory where the uncompressed file has to be created, using the
TARGDIR attribute;
- the name of the file to be uncompressed, using the SRCFILE attribute;
- the directory where the file to be uncompressed is actually saved, using the
SRCDIR attribute.
Result: the selected file is decompressed

h ... END

Display of files belongng to a directory

To display the files of a directory, the user must enter the DIR FILEHANDLER
command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> DIR FILEHANDLER

Then the user must indicate, using the DIRNAME directory, the directory whose
files have to be displayed.
Result: the list of files is shown

A30808-X3247-L210-3-7619

h ... END

171

OMN:BSC

10

Operation
Base Station Controller

Create a directory

To create a directory, the user must enter the CREATEDIR FILEHANDLER

command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> CREATEDIR FILEHANDLER

Then the user must indicate, using the DIRNAME directory, the directory to be
created.

h ... END

Result: the directory is created

11

Delete directory

To delete a generic file, the user must enter the REMOVEDIR FILEHANDLER
command, following the next sequence of selections:

MANAGED-ELEMENT ---> SOFTWARE-MANAGEMENT ---> FILEHANDLER

---> REMOVEDIR FILEHANDLER

Then the user must indicate, using the DIRNAME directory, the directory to be
deleted.
Result: the directory is deleted

END

172

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.34

OMN:BSC

Object State Check

Introduction
This procedure describes some commands the user can enter to check possible faults
within the system.
If the system does not work correctly, or if some warning lamps on the alarm panel are
switched on, the user can enter several commands to start a preliminary check.
It is possible to:

check the state and the status of the selected objects, by entering the GET <object>
STAT command;

view a list of faults, by entering the GETACTIVEALARMS BSCE command;

display the list of the whole locked objects in BSC (or to display the list of the subordinate objects of the faulty one), by entering the GETSUBO <object> command.

Indeed, many objects are related to others and some of them are dependent. If an object
is not working, all the objects depending on it are in a DISABLE DEPENDENCY state,
that is they cannot work until the faulty object is repaired.
The GETINFO command provides a lot of information about object attributes (see
CML:BSC manual for further details).
Prerequisites
These commands are not dependent on the visibility level.

Choose an option for the object state check:

Display a list of the faults
Display the administrative state, operational state, usage state and all the
status attributes of an object
Display the list of locked objects in BSC
Display the list of direct subordinate object
Display information about an object

h ... 2
h ... 3
h ... 4
h ... 5
h ... 6

Display a list of the faults

The command GETACTIVEALARMS BSCE allows to display a list of the faults

concerning the objects monitored by the specified object warning lamp.
To display the list of faults concerning the objects monitored by the specified
object alarm lamp, the user must enter the GETACTIVEALARMS BSCE
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE --->

GETACTIVEALARMS BSCE

Result: Display of a list of faults related to the objects monitored by the specified
object alarm lamp.

A30808-X3247-L210-3-7619

h ... END

173

OMN:BSC

Operation
Base Station Controller

Display the administrative state, operational state, and usage state

The command GET <object> STAT allows to display the administrative state
(Locked, Unlocked and Shuttingdown), operational state (Enabled and
Disabled), and usage state (Busy, Idle and Active) of a specified object. Detailed
descriptions about the state of an object are reported in the register "Introduction" of the User Manual (IN:BSC).
To enter the GET <object> STAT command, the object selected must be
created, otherwise the system will display a
UNSUCCESFUL_OBJECT_NOT_EQUIPPED message.
To display the state of an object, the user must enter the GET <object> STAT
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT/BSS-FUNCTIONAL --->

<object> ---> GET <object> STAT

h ... END

Result: Display of the state of an object.

Display the list of locked objects in BSC

The command GETLOCKED BSC allows to display the list of locked objects in
BSC.
To display a list of all locked objects in BSC, the user must enter the
GETLOCKED BSC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> GETLOCKED

BSC

h ... END

Result: Display of the list of all locked objects.

Display the list of direct subordinate objects

The command GETSUBO <object> allows to display the list of direct subordinate objects of a specified object. If an object is not working, all the subordinated objects will be in a DISABLED dependency state. This command allows
to display the objects that depend on the faulty one. .
To enter the GETSUBO <object> command, the object selected must be
created, otherwise the system will display a
UNSUCCESFUL_OBJECT_NOT_EQUIPPED message.
To display a list of direct subordinate objects of a specified object, the user must
enter the GETSUBO <object> command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT/BSS-FUNCTIONAL --->

<object> ---> GETSUBO <object>

Result: Display of a list of direct subordinate objects of a specified object.

174

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Display all the status attributes of an object

To display information of a specified object, the user must enter the GETINFO
<object> command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT/BSS-FUNCTIONAL --->

<object> ----> GETINFO <object>

Result: Display of all the status attributes of a selected objects.

END

A30808-X3247-L210-3-7619

175

OMN:BSC

Operation
Base Station Controller

3.35

Object Test
Introduction
The commands of this procedure are used to diagnose a hardware unit.
The unit to be diagnosed must be placed, through the LOCK command, in the LOCKED
state, if the diagnostic is intrusive. The object to be diagnosed must be already
equipped.
To start a test on an hardware unit, the PERFTEST BSCE command is used. The MORT
attribute allows to specify the hardware unit type and instance, over which the test shall
be performed. When a test starts on an hardware object, this one goes in LOCKED
DISABLE/Reserved for test state. Then:

if the test result is fail, the object goes in DISABLED failed state;
if the test result is pass, the object goes in ENABLED state;
if the test result is inconclusive, the object returns to the state previous to the test.

When starting a test, a TEST object instance is automatically created in the BSS system
to identify the test. Up to 254 TEST object instances can be created (i.e. up to 254 test
can be performed at the same time). The TEST object is created by the system as a
result of a request to start, and it is deleted when the test terminates.
To terminate a diagnostic previously started, the STOPTEST BSCE command is used.
The MORT attribute specifies the hardware unit for which the test shall be stopped; the
TO attribute is used to specify the instance of the TEST object to stop.
To retrieve the values of all the attributes belonging to a specific test the GET
BSCETEST command is used. The MORT attribute is used to identify the objects whose
data is retrieved.

Prerequisites
The user must have the visibility level set to number "1" to enter both the PERFTEST
BSCE and the STOPTEST BSCE commands. The GETBSCETEST command is not
dependent on the visibility level.

Activate the diagnostic test

The command PERFTEST BSCE is used to start an asynchronous test in the

SBS system. By means of this command, it is possible to activate a diagnostic
test on the hardware unit.
To activate a diagnostic test, the user must enter the PERFTEST BSCE
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSCE --->

PERFTEST BSCE

Result: Activation of a diagnosis on a hardware unit.

176

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Stop the diagnostic test

The command STOPTEST BSCE is used to terminate a previously started

diagnostic test. The associated test object will be deleted.
To terminate a diagnostic test that had been previously started, the user must
enter the STOPTEST BSCE command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSCE --->

STOPTEST BSCE

Result: Termination of a previously started diagnostic test.

Retrieve the values of all the attributes belonging to the test object

The command GETBSCETEST is used to retrieve the values of all the

attributes belonging to a specified test object. The test object is created by the
system as a result of the request to start an asynchronous test.
To retrieve the values of all the attributes belonging to a specified test object, the
user must enter the GETTEST command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCETEST ---> GET

BSCETEST

Result: Display of the values of all attributes belonging to a specific test object.

END

A30808-X3247-L210-3-7619

177

OMN:BSC

Operation
Base Station Controller

3.36

Peripheral processors failure during Bring-Up

Introduction
Peripheral processors (PPCC, PPLD and PPCU in case of standard BSC, or PPXL and
PPXU in case of high capacity BSC, see "1.4 Supported BSC Types") are generally
loaded during "Bring-Up".
If they are not loaded, because of a failure or missing, the "Bring-Up" phase does not
stop. The user can then load the PPxx processors at any time after the "Bring-Up"
phase.
Peripheral processors do not need any configuration. When the processor is reset, it
performs a self-test then it goes directly into Load Required state.
The reset of these processors is performed by MPCC through the UBEX, which is
connected with the MPCC interface on the PPxx.
The PPxx code loading is requested by the Device Handler when the operator provides
the start TEST command (using the PERFTEST command) and the board is disabled,
or when the alarm scan detects the corruption of a processor code.
When the PPxx code load request is received from the Device Handler, the code loading
sequence starts and a successful or unsuccessful response is sent to the Device
Handler, then the load process ends. In case of successful loading the Device Handler
automatically executes the processor initialization.
Prerequisites
The user must have the visibility level number set to "2".

Situations

h ... 2
h ... 4
h ... 6
h ... 8
h ... 10

Would you like to test PPLD processors?

Would you like to test PPCC processors?
Would you like to test PPCU processors?
Would you like to test PPXL processors?
Would you like to test PPXU processors?

Lock the PPLD board

Before starting the test, the user must lock the PPLD board entering the LOCK
PPLD command following the next sequence of selections:

178

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> PPLD --->

LOCK PPLD

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Start the diagnostic test on the PPLD processor

To start the diagnostic test on PPLD processor, the user must enter the
PERFTEST PPLD command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> PPLD --->

PERFTEST PPLD

Result: starting the diagnostic test on the PPLD processor.

h ... END

Lock the PPCC board

Before starting the test, the user must lock the PPCC board entering the LOCK
PPCC command following the next sequence of selections:

b
5

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> PPCC --->

LOCK PPCC
Start the diagnostic test on the PPCC processor

To start the diagnostic test on the PPCC processor, the user must enter the
PERFTEST PPCC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSCE ---> PPCC --->

PERFTEST PPCC

Result: starting the diagnostic test on the PPCC processor.

h ... END

Lock the PPCU board

Before starting the test, the user must lock the PPCU board entering the LOCK
PPCU command following the next sequence of selections:

b
7

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> PPCU --->

LOCK PPCU
Start the diagnostic test on the PPCU processor

To start the diagnostic test on the PPCU processor, the user must enter the
PERFTEST PPCU command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSCE ---> PPCU --->

PERFTEST PPCU

Result: starting the diagnostic test on PPCU processors.

h ... END

Lock the PPXL board

Before starting the test, the user must lock the PPXL board entering the LOCK
PPXL command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> PPXL --->

LOCK PPXL

A30808-X3247-L210-3-7619

179

OMN:BSC

Operation
Base Station Controller

Start the diagnostic test on the PPXL processor

To start the diagnostic test on the PPXL processor, the user must enter the
PERFTEST PPXL command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSCE ---> PPXL

PERFTEST PPXL

h ... END

Result: starting the diagnostic test on the PPXL processor.

10

Lock the PPXU board

Before starting the test, the user must lock the PPXU board entering the LOCK
PPXU command following the next sequence of selections:

b
11

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> PPXU --->

LOCK PPXU
Start the diagnostic test on the PPXU processor

To start the diagnostic test on the PPXU processor, the user must enter the
PERFTEST PPXU command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSCE ---> PPXU

PERFTEST PPXU

Result: starting the diagnostic test on the PPXU processor.

END

180

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.37

OMN:BSC

Signalling Link Management

Introduction
The BSS can support up to 8 Common Signal Channels (SS7L links). Regarding
common signalling management, the following commands are foreseen:
GET SS7L STAT: this command allows to display the states of the SS7L links and
message distributors between MTP and Radio Level 3. It displays the following items to
the user:

A30808-X3247-L210-3-7619

the status of the adjacent signaling point: This gives information on the accessibility of the signaling point, which is MTP inaccessible if all the signaling links are
in the unavailable or restoring state, or MTP accessible if at least one signaling link
is in the available state.
the congestion state of the adjacent signaling point: This gives information on
the congestion state of the signaling link which is MTP not congested if the
signaling links are not congested, or MTP congested if the signaling links are
congested.
the congestion level of the adjacent signaling point: This gives information on
the congestion level of the signaling links and can show the values 0, 1, 2, 3. Value
0 means that the links are not congested; this value must be found together with the
field congestion state of the adjacent sp "MTP Not Congested". Values 1, 2, 3 represent the congestion level (3 is the highest).
the state of the adjacent ss: This gives information on the state of the remote subsystem which is SCCP prohibited if the system is restarted, if the signaling links are
interrupted for a period longer than a fixed one, or at the reception of an SSP
message from MSC. It can present the value SCCP temp_prohibited as a consequence of a temporary interruption of the signaling links SS7L , or the value SCCP
allowed if the remote subsystem is not prohibited.
smg test in execution: This indicates whether a procedure of state request of the
remote subsystem is being executed. This is false if such procedure is not being
executed. It is true if the BSC has sent an SST message to the MSC requiring the
state of the remote subsystem. Such a message will be periodically repeated with a
"tsbs" period until reception of the SSA message from MSC, when the field "smg test
in execution" is reset.
state of the SPI: This gives information on the state of the message distributor
directly to SCCP. The possible values are 10, 20, 30, and 40. If the message distributor directed to SCCP is in normal working state, the value is 10; all the messages
received by SCCP are addressed to the appropriate process. If the destination
becomes inaccessible the value is 20; in this state the optional timing "TREL" starts,
any request of new connection is refused and any connection related message
received by BSSAP causes the release of the connection itself; the state is transient.
When the optional timing expires the value is set to 30; all the connection are
released and, once the operation is completed, if the connection is still not accessible the distributor passes to state 40 and with this value all the messages are
discarded. Otherwise, when the connection becomes accessible again, the value is
set to 10.
state of the LPD: This gives information on the state of the message distributor
coming from LAPD, and is 10 if the distributor is blocked. Only the RESET messages
pass. It can present the value 20 if the distributor is in idle state. All messages pass.

181

OMN:BSC

Operation
Base Station Controller

State of the SCD: This gives information concerning the state of the distributor of
the messages sent by SCCP to BSSAP and can be 10 if the distributors are blocked
and all the messages, except N_PCState_Ind, are discarded. It is the initial state at
the restart of the machine. It can present the value 20 when the distributor is in idle
state. All messages pass. It can be 30 when the distributor waits for the reception of
the ResetEnd message from MSC. It can present the value 40 if the distributor is
blocked and all messages, except N_PCState_Ind and N_Disc_Ind, are discarded.
The last value is 50 when the distributor waits for the RESETACK message from
MSC.
state of the OMD: This gives information concerning the state of the message
distributor sent by O&M to BSSAP and presents the value 20 when the distributor
normally works.

INHIBIT SS7L: This command allows the inhibition of a SS7 link.

TESTLINK SS7L: This command allows the diagnosis of a SS7 link to check the correct
exchange of messages between signaling points.
UNHINIBIT SS7L: This command allows to unhibit a SS7 link.
LOCK SS7L: This command allows to lock a SS7 link.
UNLOCK SS7L: This command allows to lunock a SS7 link.
SET OPC : This command allows to enable/disable the periodic test link
Prerequisites
The user must have the visibility level number set to "1".

Display the state of the SS7 links and message distributors

To display the state of the SS7 links and message distributors the user must
enter the GET SS7L STAT command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SS7L ---> GET SS7L STAT

Result: Display of the state of the SS7 links and message distributors.

Inhibit the signalling link

To inhibit the signaling link the user must enter the INIHIBIT SS7L command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SS7L --->INHIBIT SS7L

Result: Inhibition of the signaling link.

182

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Diagnose an SS7 link

To diagnose an SS7 link the user must enter the TESTLINK SS7L command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SS7L ---> TESTLINK SS7L

Result: Diagnosis of a SS7L to check for the correct exchange of messages

between signaling points.

Uninhibit the signaling link

To uninhibit the signaling link the user must enter the UNINHIBIT SS7L
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SS7L --->

UNINHIBIT SS7L

Result: Uninhibition of the signaling link.

Lock/Unlock the signaling link

To lock/unlockthe signaling link the user must enter the LOCK/UNLOCK SS7L
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SS7L --->

LOCK/UNLOCK SS7L

Result: LOCK/UNLOCK of the signaling link.

Enable/disable of Periodic Test Link

To enable/disable the Periodic Test Link the user must set the OPC periodic test
flag:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> OPC ---> SET OPC

Result: enabling/disabling of the periodic test.

END

A30808-X3247-L210-3-7619

183

OMN:BSC

Operation
Base Station Controller

3.38

Addition of a PCMB Line

Introduction
The addition of a PCM line A-bis Interface requires the creation of a PCMB object. If the
already created PCMB and PCMS lines occupy all the slots of the LICDs belonging to
the base module, the user must:

first create a new EPWR and then a new LICD in the extended rack, in case of standard BSC or in case of high capacity BSC with the old rack (see "1.4.1 Standard
BSC" and "1.4.2 High Capacity BSC with Old Rack");
create the LICD in the extended rack without previously creating the EPWR, in case
of high capacity BSC with the new rack (since the EPWR board is not used with the
new BSC rack, see "1.4.3 High Capacity BSC with New Rack").

The creation of the LICD board sets the threshold values of the system alarm for 2048
kbit/s for PCM30 line and for 1544 kbit/s for PCM24 line (see Command Manual for
details on alarm settings).
If the user has to create a new LICD, he must have firstly created the EPWR (if it was
necessary) and he must have correctly configured the NTWCARD attribute of the BSC
object.
The NTWCARD attribute can assume the following values (see "1.4 Supported BSC
Types"):

NTWCARD=NTWSN16, for the standard BSC;

NTWCARD=NTWSNAP, for the high capacity BSC with the old rack;
NTWCARD=NTWSNAP_STLP, for the high capacity BSC with the new rack (and
with new STLP boards);

The PCMB line is connected to a site managed (BTSM or BTSMTD), and the mapping
between radio channels and terrestrial time slot on the A-bis interface is based on the
flexible abis allocation strategy (see "3.40 Configuration of the Abis Interface").
Some particular network configurations require to connect the BTSE to the BSC through
a satellite link. The satellite in a geostationary orbit introduces an additional delay of
240ms. This delay has an impact to both speech/data and signalling exchange on the
Abis interface and/or Asub interface.
The creation of a PCMB adds on the A-bis Interface:

a 2048 kbit/s line (for PCM30)

a 1544 kbit/s line (for PCM24)

When creating a new PCMB line, the user must specify:

1. the LICD number to which the line is connected to (Licdn field of the PCML
attribute);
2. the LICD circuit number (Circn field of the PCML attribute); each circuit number is
composed by two trunks: trunk A and trunk B.

184

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

In case of standard BSC or in case of high capacity BSC with the old rack
(see "1.4.1 Standard BSC" and "1.4.2 High Capacity BSC with Old
Rack") the allowed ranges for Licdn and Circn fields is [0..8] and [0..3]
respectively.
If the new BSC rack is used, the STLP boards replace the QTLP ones, so
the Licdn field has the range [0..9] and the Circn one has the range
[0..5] (see "1.4.3 High Capacity BSC with New Rack").

3. the LREDUNEQ attribute; this attribute specifies how the PCMB line is connected to
the LICD circuit. It can assume the values:
SIMPLEXA, if the PCMB line is connected to the trunk A in a simplex way;
SIMPLEXB, if the PCMB line is connected to the trunk B in a simplex way;
DUPLEX if the loop configuration shall be used; i.e. both the trunks are used.
It is important to distinguish between the different types of BSC, because they allow
different configurations.
STANDARD BSC.
Using the standard BSC it is not possible to connect two PCMB lines (in simplex
mode) to the same LICD circuit; in other words the user cannot configure two PCMB
lines as SIMPLEXA (the first one) and SIMPLEX B (the second one), connecting
them to both the trunks of the same LICD circuit. When the user configures a PCMB
line as SIMPLEX (A or B), the other trunk of the LICD circuit shall remain free (the
simplex configuration is used, for example, when the BTSEs are connected to the
BSC, using either the STAR or the MULTIDROP configuration). In fact, in this case
the PCMB line keeps busy 2 trunks even if it is not duplicated.
On the contrary, if the user wants to create a LOOP configuration, he shall configure
the PCMB line as DUPLEX; in this case both the trunks will be used.
HIGH CAPACITY BSC (with old rack or new rack).
Using the high capacity BSC (using the old rack or the new one, see "1.4 Supported
BSC Types"), it is possible to connect two PCMB lines (in simplex mode) to the same
LICD circuit; the user can now configure two PCMB lines as SIMPLEXA (the first
one) and SIMPLEX B (the second one), connecting them to the same LICD circuit
(i.e. both the trunks).
In order to configure two PCMB lines in a single LICD circuit, their working mode
(WMOD attribute, which is meaningful only when the high capacity BSC is used)
must be set with the value SINGLE TRUNK, to distinguish them from the DOUBLE
TRUNK PCMB lines, for which the whole PCM couple (trunk A and B) is dedicated
to the BTSE link (LOOP configuration).The WMOD attribute has the same name,
range and meaning of the corresponding attribute of the PCMS object (see
"3.70 Addition of a PCM Line A-sub interface"). The difference from the PCMS is that
for the PCMB the working mode can assume the SINGLE TRUNK value only if the
NTWCARD attribute is set to NTWSNAP (high capacity BSC with the old rack), or
to NTWSNAP_STLP (high capacity BSC with the new rack).

A30808-X3247-L210-3-7619

When the standard BSC is used (NTWCARD set to NTWSN16 value),

the WMOD attribute, in the PCMB configuration, is meaningless, and the
only permitted configuration is double trunk.

185

OMN:BSC

Operation
Base Station Controller

Prerequisites
Set the PCM-TYPE parameter in the SET BSC command, if the value must be different
from PCM30 (default). The PCM-TYPE parameter is contained in the BASICS attribute
group of the BSC object (see "1.9 Attribute Groups").
EPWR (only when the old rack is used):
Before creating this object, the relevant hardware has to be plugged into the proper slot.
After the creation of the object the administrative state is set to UNLOCK. The UNLOCK
command is NOT required to place this object in service.
The creation of an EPWR adds an Extra Power Supply to the system. This is required
to support expansions to the Base Configuration.
The BSS can support 2 copies of EPWR.
LICD:
The creation of the LICD-0 must be preceded by the creation of a LICDS.
It is necessary to create the LICD object, if PCMB and PCMS occupy all the slots of the
preexisting LICD.
After the creation of the object the administrative state of this object is set to UNLOCK.
An UNLOCK command is NOT required to put this object in service.
The LICD with instance number lower than the one to be created must be EQUIPPED
before creating the new object.
PCMB:
The instance of the PCMB line must not be already created.
The relevant hardware has to be plugged in the proper slot before submitting the
command.
The attribute PCML has two fields: Licdn and circn. The instance Licdn of the object
LICD must be already created, while the circn number must not be already connected
to a PCM line.
All attributes without default are mandatory.
After the creation of the object the administrative state of this object is set to LOCK. An
UNLOCK command is required to put this object in service.
To create all these objects, the user must have the visibility level number set to "2".

Precondition
Are all the slots of the preexisting LICDs occupied by PCMBs and PCMSs?

Y h ..."3.74 Addition
of a PPLD (only
for standard
BSC) and of a
LICD Board"

N h ... 2

186

A30808-X3247-L210-3-7619

Operation
Base Station Controller

Choose the BSC type

Is the BSC a standard one (SN16 matrix)?
Is the BSC an high capacity one (SNAP matrix)?

OMN:BSC

h ... 3
h ... 5

Create a PCMB

Create a PCMB by entering the CREATE PCMB command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> CREATE PCMB

The user must specify at least the following attributes:
- PCML (that allows to configure both the LICD number and the LICD circuit
number);
- LREDUNEQ (remember that the working mode is always double trunk, apart
of that the line is created as SIMPLEX or DUPLEX).

Result: Creation of a PCMB

Unlock the PCMB

To place the PCMB in service, the user must unlock the object, by entering the
UNLOCK PCMB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> UNLOCK

PCMB

Result: Unlocking of the new created PCMB.

h ... END

Choose the PCMB configuration

Do you want to configure a single trunk PCMB line (used for STAR/MULTIDROP/CROSS_CONNECT configurations)?

h ... 6

Do you want to configure a double trunk PCMB line (used for LOOP configuration)?

h ... 8

A30808-X3247-L210-3-7619

187

OMN:BSC

Operation
Base Station Controller

Create a PCMB

Create a PCMB by entering the CREATE PCMB command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> CREATE PCMB

The user must specify at least the following attributes:
- PCML (that allows to configure both the LICD number and the the LICD circuit
number);
- LREDUNEQ = SIMPLEXA (or SIMPLEXB);
- WMOD = SINGLE_TRUNK.

Result: Creation of a PCMB. You can use the other trunk to connect another
SIMPLEX PCMB line.

Unlock the PCMB

To place the PCMB in service, the user must unlock the object, by entering the
UNLOCK PCMB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> UNLOCK

PCMB

h ... END

Result: Unlocking of the new created PCMB.

Create a PCMB

Create a PCMB by entering the CREATE PCMB command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> CREATE PCMB

The user must specify at least the following attributes:
- PCML (that allows to configure both the LICD number and the the LICD circuit
number);
- LREDUNEQ = DUPLEX;
- WMODE = DOUBLE_TRUNK.

Result: Creation of a PCMB.

188

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Unlock the PCMB

To place the PCMB in service, the user must unlock the object, by entering the
UNLOCK PCMB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> UNLOCK

PCMB

Result: Unlocking of the new created PCMB.

END

A30808-X3247-L210-3-7619

189

OMN:BSC

Operation
Base Station Controller

3.39

Addition of a New Site Manager and of related LAPD links

Introduction
The Site Manager is represented by the BTSM object. It contains a set of BTSs (i.e.
cells) and a set of TRXs.
The BTSM represents the O&M functionality related to a site and it is a logical grouping
of one or more BTSs with common management needs.
A single BSC can support up to:

100 BTS site manager in case of standard BSC;

200 BTS site manager in case of high capacity BSCs (see, "1.4 Supported BSC
Types").

When creating a new site manager, the user must specify:

1. the BTSM absolute number (btsmn) inside the BSC (see "1.5.1 Notes on the
CREATE commands"). This number is included in the range [0-199].
2. the Expected Software Version string (EXPSWV attribute) that has to match with the
version of the BTSE Sw load stored in the BSC disk.
3. the TEI parameter [0...63]: it contains the Terminal Endpoint Identifier used in the
layer2 addressing on the Abis-Interface for the logical O&M or Radio Signalling Link.
The BTSM needs a logical LAPD connection on a signalling link on A-bis Interface; this
logical link is identified by the LPDLM object. Then the user, after creating a BTSM, has
to create the LPDLM object instance.
.

When a standard BSC is used, if after the creation of the LPDLM, the system response
is:
Link not available
this means that the PPLD boards configured in the BSC are insufficient to manage the
new LPDLM. In this case, the only way to create a new LPDLM is to create a new
PPLD board first (see "3.74 Addition of a PPLD (only for standard BSC) and of a LICD
Board")
If a high capacity BSC is used, the problem does not exist, because a single PPXL
card can manage all the LAPD signalling of the BSC.
A BTSM can be connected to the BSC by means of a different number of PCMB lines
depending on the BTS type and on the customers needs. The number of PCMB lines
that can be connected from the BSC to the BTS at most, is described in the following:

190

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

for the BTSplus family (i.e. BS24X, BS4X) at most four PCM lines can be connected
from the BSC to the BTS (respectively in PORT_0, PORT_2; PORT_4 and PORT_6
of the BTS);

for the picoBTS at most four PCM lines can be connected from the BSC to the BTS;

for the BTSone family (i.e. BS6X and BS2X) at most two PMC lines can be
connected from the BSC to the BTS;

for the BS240Xs at most one PMC line can be connected from the BSC to the BTS;

for the e-Micro (i.e. BS24X, BS4X and Pico BTS) at most one PCM line can be
connected from the BSC to the BTS.

To connect the Site Manager to the BSC, the user must specify on which BTSE port the
PCMB line is connected to. To reach this purpose, four attributes are defined (they are
valid for both PCM30 and PCM24 lines):

PCMCON0: it indicates the first PCM connection;

PCMCON1: it indicates the second PCM connection;

PCMCON2: it indicates the third PCM connection;

PCMCON3: it indicates the fourth PCM connection.

These attributes are composed by two fields:

a) pcmbNumber: it indicates which is the PCMB line (i.e. a PCMB instance previously
created, see PROC: Addition of a PCMB Line) that is used for the connection;
b) portNumber: it indicates the value of the BTS port to which the PCMB line is
connected to; according to the different BTS types, it can assume one of the
following values:

PORT_0, PORT_2; PORT_4 and PORT_6 for the BTSplus family;

PORT_0, PORT_2; PORT_4 and PORT_6 for the picoBTS;
PORT_0 and PORT_2 for the BTSone family;
PORT_0 for the E-micro;
PORT_0 the BS240XS.

It is important to underline that for all the BTS types the PORT_0 must always be used
for the connection to the BSC only, i.e. it can not be used as a crossconnection port.
The remaining even ports can be used for either the connection to the BSC or the
crosconnnection to other BTSs. The odd ports can be used only for connections to other
BTSs.
For each BTSM instance it is possible to configure more than one LPDLM object
instance.
In the hierarchy tree, the BTSM object is father of LPDLM object (see "1.5.1 Notes on
the CREATE commands"). In this way it is easier to introduce in the LPDLM object the
BTSM to which it refers to, and to make all the controls related on the BTSE type, on the
SW version, etc.
Up to eight LPDLM links for each BTSM can be created on different PCMB lines that
connect the BTSM to the BSC. For the same BTSE the LAPD links are either all 64
Kb/sec or all 16 Kb/sec, and either all satellite or all no satellite. So on creating a new
LPDLM instance the user must specify:
1. the name of LPDLM instance, i.e. the complete address of the new LPDLM to be
created; the address is composed by:

A30808-X3247-L210-3-7619

191

OMN:BSC

Operation
Base Station Controller

the BTSM absolute number (range 0...199) to which the LPDLM belongs to;
the LPDLM relative number inside the BTSM domain (range 0...7)
2. the PCMB line and the timeslot number over which the LPDLM must be created
(ABISCH attribute)

Please remember that, for each configured LPDLM on the BSC side, you have to
configure the corresponding LPDLE object of the connected BTSE equipment; if you do
not execute this operation, the Abis Alignment will fail.
Even if it is possible to configure up to eight LAPD timeslots for each BTSM:

only one LPDLM link is active on one LAPD timeslot at each time (this LPDLM is in
Providing Service state);

the remaining LPDLM links on the other LAPD timeslots will be in StandBy state.

In case of failure of Providing Service LPDLM, the BSC will put this LAPD timeslot in
Fault state, and one of the other Standby LAPD timeslot is put in Providing Service
(To have more detailed information about LPDLM redundancy, and LPDLR management see "3.57 Addition of a TRX" procedure).
Using LAPD redundancy, the following considerations can be done:
1. if more than one PCMB lines is used to connect the BSC to the BTSM, there must
be at least one LPDLM for each connected PCMB line (at lest one LPDLM
timeslot for each PCMB line); when configuring LPDLM links, it is reasonable to
follow this general rule:

Number of LPDLM links >= Number of PCMB lines

2. if there is only one PCM line connected to the BTSM, it is possible to have 2 (or
more) LAPD timeslots on the same line, due to signalling load reasons.
3. If Loop Configuration (configuration of L1CTS: Layer1 Control TS) and LAPD fault
recovery are used for the same BTSM, it is acceptable to put the restriction that only
one kind of redundancy will be provided for the same BTSM. The L1CTS is no more
necessary for fault detection purposes.
4. the LPDLE hardware object of the BTSE tree is provided to storage more than one
LAPD timeslot for the start-up of the BTSE (for LPDLM). There will be a one to one
correspondence between the LPDLM instance and the LPDLE instance.

It is also possible to have up to 4 PCM lines connecting 2 BTSM each other (using e.g.
the multidrop configuration), if at least one LAPD timeslot for PCM line is configured for
the connected BTSM.

In previous releases there was the possibility to use two PCMB lines in the connection
between the BSC and the BTSM, but only one LPDLM link was available. In BR7.0, this
type of configuration is available only for backward compatibility.
The user is able to see detailed information about both BTSM and LPDLM configuration,
by using the following two commands:

GETINFO BTSM

GETINFO LPDLM

In this way the user has a complete overview about the signalling related to a Site
Manager.

192

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Prerequisites
The user must have the visibility level number set to "2".
The network element must be in phase "2".
BTSM:
To create a new site manager the existence of the PCMB is necessary.
The instance of the BTSM managed object must not be already created.
After the creation of the BTSM its administrative state is set to LOCK. An UNLOCK
command is required to put the object in service.
LPDLM:
The instance of the LPDLM must not be already created. Instead, the instance of PCMB
inserted in the ABISCH attribute must be previously created.
Before creating a LPDLM instance, the user must create the superordinate BTSM.
The Time slot or subslot used to create the LPDLM must not be allocated by other links.

Preliminary Consideration
Do you want to create a BTSM Site Manager?
Do you want to create a LAPD logical link?
Do you want to see information about BTSM configuration?
Do you want to see information about LPDLM configuration?

h ... 2
h ... 6
h ... 8
h ... 9

Precondition
Does the PCMB already exist?

Y h ... 3
N i ..."3.38 Addition
of a PCMB
Line"

Create the BTSM

To create a BTSM, the user must enter the CREATE BTSM command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> CREATE BTSM

Result: the BTSM is created in locked state.

Unlocking of the BTSM

To place the BTSM in service, the user must unlock the object by entering the
UNLOCK BTSM command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> UNLOCK BTSM

Result: the BTSM is unlocked.

A30808-X3247-L210-3-7619

193

OMN:BSC

Operation
Base Station Controller

Precondition

Y h ... 7
N h ... END

Do you want to create a LPDLM logical link?

Precondition

Y h ... 7
N h ... 3

Does the BTSM already exist?

Create the LPDLM

The user must create the LPDLM by entering the CREATE LPDLM command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> LPDLM --->

CREATE LPDLM

Result: Creation ACKNOWLEDGE.

h ... END

Get the BTSM configuration

To see the BTSM configuration, the user must enter the GETINFO BTSM
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

GETINFO BTSM

Result: the BTSM configuration is shown.

h ... END

Get LPDLM configuration

To see LPDLM configuration, the user must enter the GETINFO LPDLM
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> LPDLM --->

GETINFO LPDLM

Result: the configuration about LPDLMs is shown.

END

194

A30808-X3247-L210-3-7619

Operation
Base Station Controller

A30808-X3247-L210-3-7619

OMN:BSC

195

OMN:BSC

Operation
Base Station Controller

3.40

Configuration of the Abis Interface

Introduction
After having created both the necessary PCMB lines and the BTSM/LPDLM objects
(see "3.38 Addition of a PCMB Line" and "3.39 Addition of a New Site Manager and of
related LAPD links"), the user can configure the Abis interface (i.e. the distribution of
traffic channels on the PCMB lines) according to his needs.
The so called Flexible Abis allocation strategy is a general strategy used to handle the
Abis resources in a flexible way. A flexible Abis allocation strategy is necessary to
support GPRS CS3-CS4 coding schemes, EDGE, and TD-SCDMA, requiring more than
16 kbit/s Abis throughput for specific radio channels.
The dynamic Abis allocation applies both to packet services and circuit switched
services. The number of Abis subslots that can be associated to a radio timeslot
depends on the service type.
From the hardware platforms point of view, the following equipment support the flexible
Abis allocation strategy:

all the possible BSC configurations (standard BSC and high capacity BSCs, see
"1.4 Supported BSC Types");

the BTSplus mainline with GSM-CU and E-CU; picoBTS and enhanced micro BTS;
BTS1;

TD-SCDMA BTSC.

In fact, to support EDGE data services a EDGE Carrier Unit (E-CU) is inserted into the
BTSplus mainline, which can handle due to its 8PSK modulation capability up to about
60Kbit/s throughput per air interface timeslot. Similar units for E-MicroBTS and PicoBTS
are also derived from the mainline and slightly modified.
Furthermore GPRS CS3/CS4 coding schemes with up to about 20 kbit/s throughput per
air interface timeslot are available for both BTS+ (E-CU and GSM-CU) and BTS1
(equipped with BBSIG44). Furthermore TD-SCDMA as a broadband CDMA mobile
system based on GSM core architecture will be introduced. All this features have big
impacts also on existing Abis interface, which must be modified:

196

the Abis configuration of both TRAU frames (used for GSM voice) and standard PCU
frames (used for GPRS CS1/CS2 coding schemes), which is based on a single 16
Kbit/s slot, is not sufficient and does not manage the transport of high data rates per
air timeslot exploited by GPRS CS3/CS4 coding schemes and EGPRS.
The EGPRS data is submitted via "concatenated PCU frames", as well as the GPRS
data, in case the higher coding schemes (CS3/CS4) are enabled. Hence the flexible
Abis allocation strategy gives the opportunity to assign to each air interface timeslot,
from one to up to five 16 kbit/s Abis subslots (16 kbit/s each one) in a flexible way;

the capacity of each air interface timeslot can vary during runtime; for GPRS
CS3/CS4 or EGPRS, the flexible Abis allocation strategy adapts the Abis capacity
to the required air interface capacity (in case of Link Adaptation/new TBF
establishments/old TBF releases). Note that flexible Abis allocation strategy is a
slow process compared to GPRS/EGPRS Link Adaptation (see "3.61 Enabling Link

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

Adaptation for GPRS and EGPRS"), hence the two processes must be
synchronized;

the total Abis capacity per BTS (BTSC in case of TD-SCDMA technology) increases
with the introduction of higher data rates at Um (Uu in case of TD-SCDMA
technology) interface. Then, the flexible Abis allocation strategy must be coupled
with the management of up to 4 Abis PCM lines per BTS/BTSC (see "3.39 Addition
of a New Site Manager and of related LAPD links" and "3.120 Addition of a New TDSCDMA Site Manager and of Related LAPD Links").

Tab. 3.1 shows how services can be mapped in 8 Kbit/s, or N*16 Kbit/s Abis resources
(per radio timeslot).
8 Kbit/sec
CS speech: HR, AMR HR

16 Kbit/sec

N x 16 Kbit/sec

CS speech: FR, EFR,

AMR FR

EGPRS (up to 5x16 kbit/s)

CS data: HSCSD

GPRS channels supporting

CS3/CS4 (up to 2x16 kbit/s)

GPRS channels
supporting CS-1 and
CS2 only
Tab. 3.1

Mapping of Services onto Abis Resources

Besides, the flexible Abis allocation strategy coupled with the concept of concatenated
PCU frames gives the operator the following advantages:

the Abis interface handling is more efficient: a common pool of Abis timeslots is
associated to a BTSM; then these Abis resources will be shared between different
timeslots, carriers and even between different cells of the same base station site;
EGPRS and GPRS Link Adaptation can be performed during runtime without loss
of service;
unused capacity of an air interface timeslot can be released in the Abis interface and
exploited by other air interface timeslots;
it is possible to reach a data rate up to about 60 kbit/s per packet data channel
(PDCH) on the Abis interface.

Generally speaking, the flexible Abis allocation strategy is managed by two different
processes:
1. the first task is the configuration one: the operator can assign to every BTSM
(BTSMTD in case of TD-SCDMA technology) a pool of Abis timeslots. These
timeslots will be used to transfer information between the BTSM/BTSMTD and the
BSC;
2. the second task relies on the flexible allocation and release of resources taken from
the Abis pool. The Abis allocation algorithm is able to:
assign sufficient Abis bandwidth to an air interface timeslot during run time;

A30808-X3247-L210-7619

197

OMN:BSC

Operation
Base Station Controller

release bandwidth in case of congestion, according to service priorities and QoS

constraints.

The traditional Static Abis management is kept for backward compatibility with the
previous releases, harmonizing the O&M management of flexible and static BTSM.
Remember that Static Allocation is not foreseen in TD-SCDMA system.
It must be clear that:

flexible abis allocation means that the association between radio timeslots and
Abis timeslots is performed by radio signalling procedures. There is not a fixed
one-to-one (1 x 16 kbit/s) or one-to-two (2 x 16 kbit/s) association from air interface
timeslots to Abis subslots, in the BSC database;

static abis allocation means that the association between radio timeslots and Abis
timeslots is performed during O&M procedures, stored into BSC database and
signalled to BTSM by O&M signalling procedures. The association is fixed during
runtime and can only be changed via O&M reconfiguration.

To simplify the configuration procedures, the operator commands, used to configure

both flexible and static allocations for a BTSM, are the same. In case of static
BTSM, the static allocation between radio and Abis channels is performed by the system
(BSC) at configuration time.
In the following the different topics related to this feature are discussed, considering:

a brief discussion about concatenated PCU frames;

hardware supporting flexible Abis allocation and concatenated PCU frames;
configuration of the Abis interface;
algorithms regarding flexible Abis allocation.

Concatenated PCU Frames

The PCU frame is used to transmit packet data traffic on the Abis interface, whereas to
transmit voice traffic, the similar TRAU frames are used.
Concatenated PCU frames support both EGPRS (MCS-1,., MCS-9), GPRS Step II
(CS-3/CS-4 data rates) and GPRS Step I (CS-1/CS-2 data rates) on PDCHs.
They are composed by n*16 Kbit/s sub-frames (n = 1 up to 5 for EDGE). A PDCH with
multiplexed EDGE and GPRS TBFs requires an Abis allocation due to the highest used
coding scheme. Hence at the moment a PDCH with a MCS-9 TBF on it requires
16Kbit/s*5 = 80Kbit/s.
The Sub-Frame-Counter (SFC) indicates the sub-frame number (composed of 5 bits)
and provides the sequence order of the 16Kbit/s channels. It allows a maximum of
2^5=32 concatenated sub-frames, which could be useful for future uses (TD-SCDMA
applications, broadband carrier, etc.).
The n*16 Kbit/s subframes of an air interface timeslot shall be arbitrarily distributed over
PCM 24/30 Abis lines: they shall not necessarily allocate a block of subsequent Abis
subslots, which is of course possible. The subframes can be completely disordered on
the PCM lines of the BTSM as long as they are within the defined pool of the BTSM.
They do not have to guarantee any ordered sequence in ascending way due to
increasing SFC.
But it must be guaranteed that for a given PDCH all allocated TBFs use the same Abis
subslots for concatenated PCU frames with the same SFC.

198

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

MSs using different coding schemes can be multiplexed on the same timeslots (PDCH)
on the air interface.
Multiplexing of GPRS and EGPRS mobile stations is also possible if concatenated PCU
frames are used in both cases (i.e. on the same timeslot it is not possible to multiplex
users which are exploiting new concatenated PCU frames and others working with the
standard PCU frames).
Users multiplexed on the same PDCH can not use a different number of PCU subframes on Abis. Idle PCU subframes with filling patterns are used on the Abis subslots
not carrying data payload, in order to extend all the concatenated PCU frames to the
same MCS-j (j=1,..., 9) configuration. Let us consider an Abis channel that is allocated
for a maximum bandwidth for a MS using MCS-9; in this case MSs using MCSs lower
than MCS-9 have some idle PCU frames with a filling pattern, due to the requirement
that all TBFs on a particular PDCH occupy the same Abis capacity, whether they need
it or not.
Another case in which idle PCU-sub-frames are used to fill up the allocated Abis
capacity is when a Link Adaptation of a TBF to a lower data rates occurs (i.e. MCS9/MCS-6, because of the impossibility of the air interface to maintain MCS-9 with good
quality). The unused Abis capacity is filled with idle PCU sub-frames with filling pattern,
because to reduce signalling overhead, the release of allocated Abis capacity is not
executed immediately.

Standard PCU frames can be still used even combined with the flexible Abis allocation
strategy; in fact dynamic Abis allocation does not imply the usage of concatenated
PCU frames. Standard PCU frames are used whenever the BTS does not support
concatenated ones (see " Hardware supporting Flexible Abis Allocation and Concatenated PCU Frames").

Hardware supporting Flexible Abis Allocation and Concatenated PCU Frames

As it has been described in " Concatenated PCU Frames", dynamic Abis allocation does
not imply concatenated PCU frame usage in packet flows.
Fig. 3.1 and Fig. 3.2 show the relationship among standard/concatenated PCU frames
and flexible/static Abis allocation, depending on the BTSE type and on the BSC type (i.e.
standard or high capacity BSC).

A30808-X3247-L210-7619

199

OMN:BSC

Operation
Base Station Controller

High Capacity BSC

BTSplus, picoBTS, E-microBTS

- Standard/Concatenated PCU frames supported
- CS1...CS4 supported
- MCS1...MCS9 supported on EDGE carriers
-Dynamic Abis allocation supported

Concatenated PCU frames

Both standard and

concatenated PCU frames
are supported.

BTS1 with BBSIG44

- Standard/Concatenated PCU frames supported
- CS1...CS4 supported
- Dynamic Abis allocation supported

Concatenated PCU frames

Dynamic Abis
allocation

BTS1 without BBSIG44

- Only Standard PCU frames supported
- Only CS1 and CS2 supported
- Dynamic Abis allocation supported

Fig. 3.1

Standard PCU frames

High Capacity BSC: Relationship between PCU Frames and Abis Allocation according to the BTSE
Type

Standard BSC

BTSplus, picoBTS, E-microBTS

- Standard/Concatenated PCU frames supported
- CS1...CS4 supported
- MCS1...MCS9 supported on EDGE carriers
-Dynamic Abis allocation supported

Standard PCU frames

Only standard
PCU frames
are supported.

BTS1 with BBSIG44

- Standard/Concatenated PCU frames supported
- CS1...CS4 supported
- Dynamic Abis allocation supported

Standard PCU frames

Dynamic Abis
allocation

BTS1 without BBSIG44

- Only Standard PCU frames supported
- Only CS1 and CS2 supported
- Dynamic Abis allocation supported

Fig. 3.2

200

Standard PCU frames

Standard BSC: Relationship between PCU Frames and Abis Allocation according to the BTSE Type

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

The following considerations can be done:

standard PCU frames are used whenever GPRS CS3/CS4 and EDGE are not
supported;
concatenated PCU frames are used whenever EDGE and/or CS-3 and CS-4 (more
than 16 kbit/s per radio timeslot) are supported;
in all the previous cases, the mapping between radio timeslots and Abis timeslots is
dynamic (at channel activation);
GPRS CS3/CS4 and EGPRS are not supported on standard BSC, due to its low
GPRS capacity (max. 128 PDCHs, decreasing to 64 PDCHs in case of CS3/CS4);
in this case GPRS CS3/CS4 and EGPRS are not supported, and standard PCU
frames are always used.

The BSC software is backward compatible and it is able to handle BTSs running with old
software releases, supporting only static Abis allocation. Fig. 3.3 gives such an
example, when BTSs with old software releases are connected to a BSC with a release
supporting the flexible Abis allocation strategy. In this case only GPRS CS1/CS2 radio
channels are supported (GPRS CS3/CS4 or EGPRS capabilities cannot be configured).
There are not any problems to handle such kind of situations since:

static allocation and standard PCU frame format are implemented on BSC;
operator commands for a release supporting the flexible Abis allocation strategy
have a backward compatible meaning and management (Abis pool definition is
internally handled in a static way for old BTS software releases);
the BSC is able to reject operator commands not compatible with old BTS software
releases.
BSC Hardware

Software Release
supporting Dynamic
Allocation
Dynamic Abis
allocation

All BTS Hardware with

Static Abis Software Release
- Only Standard PCU frames supported
- Only CS1 and CS2 supported
- Only Static Abis allocation supported

Fig. 3.3

Standard PCU frames

Static Abis
allocation

BSC handling of BTS Equipment with Software Releases not supporting the Abis Dynamic Allocation

A30808-X3247-L210-7619

201

OMN:BSC

Operation
Base Station Controller

Configuration and Re-Configuration of the Abis Interface

As it has been described, the procedures used to configure both flexible and static
allocations for a BTSM, are the same. The only difference is that in case of static
BTSM, the static allocation between radio and Abis channels is performed by the system
(BSC) at configuration time. As a consequence, all the concepts explained below, are
valid, unless differently stated, for both flexible and static Abis allocations.
To manage the Abis allocations two concepts are introduced: the Abis Subpool and the
Abis Pool.
Referring to a specific BTSM/BTSMTD, the Abis Subpool is a set of 16 kbit/s Abis
subslots belonging to a single PCMB line, routed together with the LPDLM/LPDLMTD
instance (previously associated to the BTSM/BTSMTD) configured on the same PCMB
line.

Remember that a BTSM/BTSMTD can be connected to the BSC by, at most, four
PCMB lines, and each line must contain at least one LPDLM/LPDLMTD related to the
BTSM/BTSMTD (see "3.39 Addition of a New Site Manager and of related LAPD links"
and "3.120 Addition of a New TD-SCDMA Site Manager and of Related LAPD Links").
This is an operator constraint, valid for all kind of BSS configuration (star, loop, multidrop
with/without cross connections) and also for cross connectors external to the BSS
network elements. The subpool concept is necessary for O&M purpose, to manage a
correct fault propagation from LPDLM/LPDLMTD to Abis resources.
So, the user to connect the BSC to a specific BTSM/BTSMTD can create a certain
number of subpools that will contain a specific number of timeslots of the Abis interface.
To configure an Abis subpool the SUBTSLB object is used. The SUBTSLB object
indicates one subslot of a PCMB line; when creating a SUBTSLB instance the user must
specify the following attributes:

NAME: it indicates the subslots of a PCMB line, specifying the PCMB instance, the
slot [1..31] of the selected line, and the subslot number [0..3];
ASSLAPD (Associated Lapd): it indicates the LPDLM/LPDLMTD instance (and as
a consequence the BTSM/BTSMTD) that is related to this subslot.

When creating a SUBTSLB instance, to indicate the slot of the PCMB line that contains
this subslot, the TSLB object has been introduced; it is subordinate to the PCMB object
(and superordinate of the SUBTSLB one) in the containment tree; there are 31 TSLB
instances for each PCMB, automatically created at PCMB creation; TSLB object has no
states, status and attributes; it is defined for addressing the created SUBTSLB.
So, to create on a PCMB line a subpool for a specific BTSM, the user must create more
instances of the SUBTSLB object, linking them to the same LPDLM/LPDLMTD instance
(i.e. to the same BTSM/BTSMTD) by the ASSLAPD parameter.
Referring to a BTSM/BTSMTD, the Abis Pool is the amount of 16 kbit/s Abis subslots
reserved to the BTSM/BTSMTD for traffic services (i.e. it is the amount of SUBTSLB
instances, configured on different PCMB lines and associated, through the ASSLAPD,
to the LPDLM/LPDLMTDs related to the BTSM/BTSMTD).
No specific object class is required to model the Abis pool concept; the whole Abis pool
(and information about the subpools it is composed of) is available to operator, via
GETINFO BTSM/GETINFO BTSMTD command, whereas information about subpools
distribution on a PCMB are available via the GETINFO PCMB command.

202

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

One more time it must be noted that:

in case of BTS supporting dynamic Abis allocation (and BTSC), Abis subslots are
selected from the Abis pool and allocated to radio channels at channel activation. In
case of GPRS and EGPRS, changes of the Abis resources assigned to an air interface timeslot are possible during TBF-operation via the channel modification
command;
in case of static Abis allocation, Abis subslots are selected from the Abis Pool and
statically allocated to radio channels by O&M procedures; the relationship between
radio channels and Abis subslots is notified to BTS by O&M Abis signalling (at radio
channel creation). The number of Abis subslots to be statically associated to air
timeslot is always 1 for BTS running with old SW releases.

Abis pools and subpools have the following properties and features:

different Abis subpools, belonging to the same or different Abis pools, can be
defined on the same PCMB line;

subpools can be distributed over all connected PCMB lines of a BTSM/BTSMTD (at
least one subpool per line);

the Abis subslots allocated to a radio channel may be distributed over different
subpools, over different PCM lines and it is not necessary at all to guarantee that the
subslots are neighboring each other;

overlaps between different pools and subpools are forbidden.

So, the PCU subframes belonging to a specific PDCH (or air interface timeslot) can be
distributed via all available Abis subpools, even if the subpools are located on different
PCMB lines.
Moreover, the following checks must also be executed when the Abis interface is
configured:

a SUBTSLB cannot be created on a TSLB terrestrial channel used by other system

resources (e.g. L1CTS, LPDLM, LPDLMTD and NUC);

a PCMB subslot (terrestrial channel) used by a SUBTSLB, cannot be allocated to

other system resources (e.g. L1CTS, LPDLM, LPDLMTD and NUC);

the Associated Lapd channel and the SUBTSLB instance must be configured on the
same PCMB line;

Abis subslots arriving on the same BTSM/BTSMTD port (specified by

BTSM/BTSMTD attributes PCMCONN0, PCMCONN1, etc.) must have different
(unique) numbers, even if they are distributed over different PCMB lines (in case 2
PCMB lines are merged to one BTSE port via a cross connection); that is: if
PCMB:x/TSLB:a/SUBTSLB:c and PCMB:y/TSLB:a/SUBTSLB:c belong to the same
Abis pool, PCMB:x and PCMB:y must be mapped onto different BTSM/BTSMTD

A30808-X3247-L210-7619

203

OMN:BSC

Operation
Base Station Controller

ports; two SUBTSLBs are in the same Abis pool when their associated
LPDLM/LPDLMTDs are configured on the same BTSM/BTSMTD;

a LPDLM/LPDLMTD cannot be deleted if it is referenced by any SUBTSLB (by the

ASSLAPD parameter);

no special check is necessary to avoid overlapping subpools, since each SUBTSLB

has a unique associated Lapd.

The BSS system (BSC+BTSM/BTSMTD) cannot detect all the inconsistencies in configuration, since the BSC can guarantee only consistency among Abis pools and other
objects or attributes inside its own database, and BTSE can check only its own Abis pool
and its own XCONNECT consistency.
For example, the BSC cannot detect the case that a cross connected 64 kbit/s Abis
timeslot is shared among different BTSEs, and the cross connecting BTSE cannot
check the other BTSEs Abis pools.
In this case, the rule is that a cross connected TSLB cannot be shared among different
Abis pools, i.e. all its SUBTSLB instances must have the same associated
LPDLM/LPDLMTD instance.

When Abis pools have to be re-configured, the re-configuration should have the
minimum impact on going services.
To move a SUBTSLB from one site (BTSM/BTSMTD) to another one, or to change
the referred LPDLM, the SUBTSLB must be deleted and created again. That is, the
ASSLAPD attribute must be specified at SUBTSLB creation and cannot be set.
This is because, in case the SUBTSLB has to be moved from a BTSM/BTSMTD to
another one (or from one PPXT to another one in case of TD-SCDMA), inconsistency
with BTSE configuration can arise.
In particular, it should be guaranteed Abis subslots removed from the pool are not
currently in use and are not allocated as far as re-configuration is not completed. This
result is achieved shutting down or locking the SUBTSLB before deleting it. Besides,
remember that:

a LOCK SUBTSLB command immediately removes the affected resources from

service. For circuit switched services, this implies to drop the call. For packet
switched services, this implies a reduction of the TBF throughput. The throughput
can be restored by the Link Adaptation mechanism;
A SHUTDOWN SUBTSLB commands will try for 5 minutes the handover of circuit
switched services; the behavior for packet switched services is the same as in the
LOCK case.

Algorithms Regarding Flexible Abis Allocation

Dynamic Abis allocation consists of the selection, for each radio channel of a cell, of one
or more idle and in service Abis subslots, belonging to the pool associated to the
BTSM/BTSMTD that contains the cell.
Abis idle lists are built and updated according to the O&M operator commands issued
on the SUBTSLB object.

204

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

The pool is managed with a soft boundary policy, which guarantees a minimum
percentage of Abis subslots for each cell. All the cells belonging to the same BTSM
share the same Abis pool; each cell may pick up Abis resource from the pool as long as
the guaranteed minimum is left at the other cells disposal. The operator can set the
guaranteed minimum number of subslots per cell by the GUARMABIS parameter (BTS
object).

The GUARMABIS attribute is not included into the BTSTD object, since the attribute is
meaningful only for multicell sites.
Regarding the dynamic allocation of Abis subslots, two different cases must be
considered, circuit switched services and packet data services:

for circuit switched services the following distinctions can be drawn:

for full rate CS services always 1 Abis subslot per radio channel is allocated;
in case of multislot request and the total number of Abis subslots is not available,
the number of allocated radio timeslots is reduced accordingly. The Abis subslots
allocated to the multislot configuration (HSCSD) may be distributed over different
PCMB lines and it is not necessary at all to guarantee that the subslots are
adjacent each other. By the way, as far as possible the Abis subslots for the multislot configuration will be selected from the same PCMB;
in case of half rate, half Abis subslot is allocated. Abis subchannel 0 is associated
to radio subchannel 0, Abis subchannel 1 is associated to radio subchannel 1, as
in the previous release. When half Abis channel is allocated to half radio
channel, the whole Abis channel is removed from the Abis idle list, since the free
half Abis can be assigned only to the residual half radio channel.

in case of packet switched services, the request contains the number of Abis
subslots (PDT) to be allocated per PDCH. Up to 5 Abis subslots (and PDTs) per
PDCH can be required. The Abis subslots allocated to the same radio channel may
be distributed over different PCMB lines and it is not necessary at all to guarantee
that the subslots are adjacent each other. By the way, as far as possible the Abis
subslots for the same PDCH will be selected from the same PCMB. For each allocated Abis subslot one PDT will be allocated.

Besides, Abis pools occupation levels and congestion are managed, taking into
account:
a) Cell Load dependent activation of Half Rate (only for CS services);
b) Enhanced pairing activation (only for CS services);
c) Traffic Handover activation due to Abis high traffic.
Features b) and c) are not foreseen in TD-SCDMA system.
The three algorithms are described in the following.
In the cells where Cell Load dependent activation of Half Rate is enabled for the radio
interface (see "3.102 Enabling Cell load dependent activation of HR channels"), before
assigning a TCH, the percentage of Abis busy subslots is calculated too.

Note that in this context 16 kbit/s subslots are considered fully busy even when only a
subchannel (8 kbit/s) is busy, because on BTS side idle 8 kbit/s subchannels spread
over different Abis subslots cannot be combined in 16 kbit/s subslots, and used for full
rate.

A30808-X3247-L210-7619

205

OMN:BSC

Operation
Base Station Controller

Then the calculated percentage is compared to the AbisHalfRateActivationThreshold.

This threshold can be set by the ABISHRACTTHR parameter (BTSM/BTSMTD object).
If the threshold is overcome, a TCH/H is allocated whenever possible.
The half rate channels is allocated even if, in the cell, the HalfRateActivationThreshold,
related to the management of radio resources (see 3.102), is not overcome, since
there is a general benefit for the whole pool of Abis resources.

In the cells where the Enhanced Pairing for the Radio Interface is enabled (see
"3.103 Enabling Enhanced pairing for TCH/H channels"), the system, periodically,
calculates the percentage of Abis busy subslots too.
When this percentage is less than (100 - AbisHalfRateActivationThreshold), and there
are at least two TCH-Half not paired, the Intracell Handover procedure is started (even
if there is no problem with the number of TCH-Full free). The result will be the pairing on
Abis as well (since the two subchannels of a TCH are associated to the two subchannels
of the same Abis subslot).
As for the radio channels, the same threshold is used for both cell load dependent activation of half rate channels and enhanced pairing activation features (in case of Abis
resources the AbisHalfRateActivationThreshold is set by the ABISHRACTTHR
parameter.
The Traffic Handover activation due to Abis high traffic introduces same changes in the
algorithm that manages the Handover for Traffic for the Radio Interface (please refer to
"3.79 Management of Handover for Traffic").
So, when flexible Abis allocation is used, the features described in 3.79, are modified as
following:
1. the BSC starts the TRFCT timer;
2. when this timer (TRFCT) expires, if the feature is enabled in at least one cell of the
BTSM, the BSC calculates the Abis traffic level (in percentage);
3. if the calculated value is higher or equal to the threshold defined by ABISTRFHITHR
parameter (BTSM object), the BTSM is regarded as a High Abis traffic level BTSM,
otherwise the BTSM is regarded as a Low Abis traffic level BTSM.
If the percentage is higher than the threshold, then all the cells where the feature is
enabled are regarded as high Abis traffic level;
4. the radio traffic level in the cells where the feature is enabled is calculated as in the
implementation described in "3.79 Management of Handover for Traffic". So, a cell
can be in one of the following conditions regarding traffic level:

206

high radio traffic level;

high Abis traffic level;
high radio & Abis traffic level;
low traffic level.

The three conditions related to high traffic levels identifies the cell as a High traffic
level one.

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

5. if the cell is classified as a High traffic level cell and the last evaluation for that cell
defined it as Low traffic level one, the BSC sends a message to the BTS (through
O&M) to enable the handover for traffic reason;
6. if the cell is classified as a Low traffic level cell and the last evaluation for that cell
defined it as High traffic level one, the BSC sends a message to the BTS (through
O&M) to disable the handover for traffic reason;
7. when the BSC receives an handover request due to traffic, the kind of traffic level is
checked:
in case of high Abis traffic level or high radio & Abis traffic level, the handover is
performed toward a target cell belonging to another BTSM (if any);
in case of high Abis traffic level or high radio & Abis traffic level, if there are not
target cells external to the BTSM, the handover is not performed;
in case of high radio traffic level, the handover is performed following the same
procedure as explained in "3.79 Management of Handover for Traffic".

It has been said that in case of high Abis traffic level or high radio & Abis traffic level,
the handover is performed toward a target cell belonging to another BTSM; the
handover is executed only towards cells that belong to BTSMs with a low traffic level.
A BTSM is considered as low traffic level BTSM when the percentage of its busy Abis
subslots is lower than the threshold defined by the ABISTRFLTHR parameter.
When the user sets ABISTRFHITHR and ABISTRFLTHR values, the following
condition:
ABISTRFHITHR- ABISTRFLTHR>=20
must be satisfied.

Prerequisites
The user must have the visibility level number set at "2".

Situations about the configuration of the Abis interface

Would you like to follow an initial configuration?

h ... 2

Would you like to see how to re-configure the Abis Pool when a new BTSM is
added to an already created configuration?

h ... 28

Would you like to see how to re-configure Abis Pools when a subslot is
moved from a BTSM to another one?

h ... 50

A30808-X3247-L210-7619

207

OMN:BSC

Operation
Base Station Controller

Target

The following figure shows the configuration we have to create.

Create PCMB:0 and PCMB:1 lines

To get information about PCMB line creation, refer to the specific procedure.

i...."3.38 Addition
of a PCMB
Line"

Result: PCMB:0 and PCMB:1 lines are created.

Create BTSM:1

Create the BTSM:1 setting the following attribute values:

PCMCON0= PCMB_0-PORT_0
PCMCON1= PCMB_1-PORT_2
To get information about BTSM creation, refer to the specific procedure.

i...."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: BTSM:1 is created.

208

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

Create LPDLM:1 for BTSM:1

Create the LPDLM:1 on the PCMB:0 setting the following attribute value:
ABISCH= 0-1
To get information about LPDLM creation, refer to the specific procedure.

i ..."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: LPDLM:1 is created.

Create Abis Subpools related to BTSM:1/LPDLM:1

To create Abis Subpools related to BTSM:1/LPDLM:1 enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:0/TSLB:2&&16/SUBTSLB:*
ASSLAPD= BTSM:1/LPDLM:1
Result: all the four subslots of the Abis timeslots from the 2nd to the 16th are
associated to BTSM:1.

Unlock Abis Subpools related to BTSM:1/LPDLM:1

To unlock Abis Subpools related to BTSM:1/LPDLM:1 enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:0/TSLB:2&&16/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 2nd to the 16th are
unlocked.

A30808-X3247-L210-7619

209

OMN:BSC

Operation
Base Station Controller

Create LPDLM:3 for BTSM:1

Create the LPDLM:3 on the PCMB:1 setting the following attribute value:
ABISCH= 1- 31
To get information about LPDLM creation, refer to the specific procedure.

i...."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: LPDLM:3 is created.

Create Abis Subpools related to BTSM:1/LPDLM:3

To create Abis Subpools related to BTSM:1/LPDLM:3 enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:1/TSLB:17&&30/SUBTSLB:*
ASSLAPD= BTSM:1/LPDLM:3
Result: all the four subslots of the Abis timeslots from the 17th to the 30th are
associated to BTSM:1.

10

Unlock Abis Subpools related to BTSM:1/LPDLM:3

To unlock Abis Subpools related to BTSM:1/LPDLM:3 enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:17&&30/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 17th to the 30th are
unlocked.

210

A30808-X3247-L210-7619

Operation
Base Station Controller

11

OMN:BSC

Define a first crossconnection (XCONNECT:0) towards BTSM:2

To create the crossconnection towards BTSM:2, the user must enter the BTSE
Interworking tree related to the BTSM:1 equipment, and then enter the CREATE
XCONNECT command following the correct sequence of selections (example
regarding the BTSEP interworking tree):

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSEP ---> XCONNECT

---> CREATE XCONNECT

Then set the following attribute values:

NAME= <BTSE_type>:1/XCONNECT:0
MPTSL17=3-17
..
MPTSL31=3-31
Result: the XCONNECT:0 crossconnection is created.

12

Define a second crossconnection (XCONNECT:2) towards BTSM:2

To create the crossconnection towards BTSM:2, the user must enter the BTSE
Interworking tree related to the BTSM:1 equipment, and then enter the CREATE
XCONNECT command following the correct sequence of selections (example
regarding the BTSEP interworking tree):

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSEP equipment --->

XCONNECT ---> CREATE XCONNECT

Then set the following attribute values:

NAME= <BTSE_type>:1/XCONNECT:2
MPTSL01=3-1
..
MPTSL16=3-16
Result: the XCONNECT:2 crossconnection is created.

13

Get information about BTSM:1

To retrieve information about the BTSM:1 configuration, enter the GETINFO

BTSM command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

GETINFO BTSM

Result: BTSM:1 information is retrieved.

A30808-X3247-L210-7619

211

OMN:BSC

14

Operation
Base Station Controller

Unlock BTSM:1

To unlock BTSM:1 , enter the UNLOCK BTSM command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

UNLOCK BTSM

Result: BTSM:1 is unlocked.

15

Create BTSM:2

Create the BTSM:2 setting the following attribute values:

PCMCON0 = PCMB_0-PORT_0
PCMCON1= PCMB_1-PORT_0
To get information about BTSM creation, refer to the specific procedure.

i...."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: BTSM:2 is created.

16

Create LPDLM:2 for BTSM:2

Create the LPDLM:2 on the PCMB:0 setting the following attribute value:
ABISCH= 0-31
To get information about LPDLM creation, refer to the specific procedure.

i...."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: LPDLM:2 is created.

212

A30808-X3247-L210-7619

Operation
Base Station Controller

17

OMN:BSC

Create Abis Subpools related to BTSM:2/LPDLM:2

To create Abis Subpools related to BTSM:2/LPDLM:2 enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:0/TSLB:17&&30/SUBTSLB:*
ASSLAPD= BTSM:2/LPDLM:2
Result: all the four subslots of the Abis timeslots from the 17th to the 30th are
associated to BTSM:2.

18

Unlock Abis Subpools related to BTSM:2/LPDLM:2

To unlock Abis Subpools related to BTSM:2/LPDLM:2 enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:0/TSLB:17&&30/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 17th to the 30th are
unlocked.

19

Create LPDLM:4 for BTSM:2

Create the LPDLM:4 on the PCMB:1 setting the following attribute value:
ABISCH= 1- 31
To get information about LPDLM creation, refer to the specific procedure.

i ..."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: LPDLM:4 is created.

A30808-X3247-L210-7619

213

OMN:BSC

20

Operation
Base Station Controller

Create Abis Subpools related to BTSM:2/LPDLM:4

To create Abis Subpools related to BTSM:2/LPDLM:4 enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:1/TSLB:1&&7/SUBTSLB:*
ASSLAPD= BTSM:2/LPDLM:4
Result: all the four subslots of the Abis timeslots from the 1st to the 7th are
associated to BTSM:2.

21

Unlock Abis Subpools related to BTSM:2/LPDLM:4

To unlock Abis Subpools related to BTSM:2/LPDLM:4 enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:1&&7/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 1st to the 7th are
unlocked.

22

Create Abis Subpools related to BTSM:2/LPDLM:4

To create Abis Subpools related to BTSM:2/LPDLM:4 enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:1/TSLB:8/SUBTSLB:1&&3
ASSLAPD= BTSM:2/LPDLM:4
Result: three subslots of the Abis timeslots number 8 are associated to BTSM:2.

214

A30808-X3247-L210-7619

Operation
Base Station Controller

23

OMN:BSC

Unlock Abis Subpools related to BTSM:2/LPDLM:4

To unlock Abis Subpools related to BTSM:2/LPDLM:4 enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:8/SUBTSLB:1&&3

Result: the three subslots of the Abis timeslots number 8 are unlocked.

24

Create Abis Subpools related to BTSM:2/LPDLM:4

To create Abis Subpools related to BTSM:2/LPDLM:4 enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:1/TSLB:9&&16/SUBTSLB:*
ASSLAPD= BTSM:2/LPDLM:4
Result: all the four subslots of the Abis timeslots from the 9th to the 16th are
associated to BTSM:2.

25

Unlock Abis Subpools related to BTSM:2/LPDLM:4

To unlock Abis Subpools related to BTSM:2/LPDLM:4 enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:9&&16/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 9th to the 16th are
unlocked.

A30808-X3247-L210-7619

215

OMN:BSC

26

Operation
Base Station Controller

Get information about BTSM:2

To retrieve information about the BTSM:2 configuration, enter the GETINFO

BTSM command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

GETINFO BTSM

Result: BTSM:2 information is retrieved.

27

Unlock BTSM:2

To unlock BTSM:2, enter the UNLOCK BTSM command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

UNLOCK BTSM

Result: BTSM:2 is unlocked.

28

h ... END

Target

The following figure shows the configuration we have to create, starting from
the configuration shown in step 2

216

A30808-X3247-L210-7619

Operation
Base Station Controller

29

OMN:BSC

Create new PCMB:2 line

To get information about PCMB line creation, refer to the specific procedure.

i ..."3.38 Addition
of a PCMB
Line"

Result: PCMB:2 line is created.

30

Add the PCMB:2 line to BTSM:1

To add the line to BTSM:1, enter the SET BTSM command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

Then set the following attribute value:

PCMCON2= PCMB_2-PORT_4
Result: PCMB:2 is added to BTSM:1.

31

Create LPDLM:7 for BTSM:1

Create the LPDLM:7 on the PCMB:2 setting the following attribute value:
ABISCH= 2-1
To get information about LPDLM creation, refer to the specific procedure.

i ..."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: LPDLM:7 is created.

32

Create Abis Subpools related to BTSM:1/LPDLM:7

To create Abis Subpools related to BTSM:1/LPDLM:7, enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:2/TSLB:2&&16/SUBTSLB:*
ASSLAPD= BTSM:1/LPDLM:7
Result: all the four subslots of the Abis timeslots from the 2nd to the 16th are
associated to BTSM:1.

A30808-X3247-L210-7619

217

OMN:BSC

33

Operation
Base Station Controller

Unlock Abis Subpools related to BTSM:1/LPDLM:7

To unlock Abis Subpools related to BTSM:1/LPDLM:7, enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:2/TSLB:2&&16/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 2nd to the 16th are
unlocked.

34

Define a first crossconnection (XCONNECT:2) towards BTSM:3

To define the crossconnection towards BTSM:3, the user must enter the BTSE
Interworking tree related to the BTSM:1 equipment, and then enter the SET
XCONNECT command following the correct sequence of selections (example
regarding the BTSEP interworking tree):

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSEP ---> XCONNECT

---> SET XCONNECT

Then set the following attribute values:

NAME= <BTSE_type>:1/XCONNECT:2
MPTSL11=5-11
..
MPTSL16=5-17
Result: the XCONNECT:2 crossconnection is set.

35

Define a second crossconnection (XCONNECT:4) towards BTSM:3

To create the crossconnection towards BTSM:3, the user must enter the BTSE
Interworking tree related to the BTSM:1 equipment, and then enter the CREATE
XCONNECT command following the correct sequence of selections (example
regarding the BTSEP interworking tree):

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSEP ---> XCONNECT

---> CREATE XCONNECT

Then set the following attribute values:

NAME= <BTSE_type>:1/XCONNECT:4
MPTSL17=7-17
..
MPTSL31=7-31
Result: the XCONNECT:1 crossconnection is created.

218

A30808-X3247-L210-7619

Operation
Base Station Controller

36

OMN:BSC

Create BTSM:3

Create the BTSM:3 setting the following attribute values:

PCMCON0 = PCMB_1-PORT_0
PCMCON1= PCMB_2-PORT_0
To get information about BTSM creation, refer to the specific procedure.

i ..."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: BTSM:3 is created.

37

Get information about BTSM:2

To retrieve information about the BTSM:2 configuration, enter the GETINFO

BTSM command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

GETINFO BTSM

Result: BTSM:2 information is retrieved.

38

Lock Abis Subpools (related to BTSM:2/LPDLM:4) on PCMB:1

To lock Abis Subpools related to BTSM:2/LPDLM:4, enter the LOCK SUBTSLB

command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> LOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:11&&16/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 11th to the 16th are
locked.

A30808-X3247-L210-7619

219

OMN:BSC

39

Operation
Base Station Controller

Delete Abis Subpools related to TSLB:16 on PCMB:1

To delete Abis Subpools, enter the DELETE SUBTSLB command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> DELETE SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:16/SUBTSLB:*
Result: all the four subslots of the 16th Abis timeslot are deleted.

40

Create LPDLM:5 for BTSM:3

Create the LPDLM:5 on the PCMB:1 setting the following attribute value:
ABISCH= 1-16
To get information about LPDLM creation, refer to the specific procedure.

i...."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: LPDLM:5 is created on timeslot 16.

41

Delete Abis Subpools on PCMB:1

To delete Abis Subpools, enter the DELETE SUBTSLB command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> DELETE SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:11&&15/SUBTSLB:*
Result: all the four subslots of the Abis timeslots from the 11th to the 15th are
deleted.

220

A30808-X3247-L210-7619

Operation
Base Station Controller

42

OMN:BSC

Create Abis Subpools related to BTSM:3/LPDLM:5

To create Abis Subpools related to BTSM:3/LPDLM:5, enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:1/TSLB:11&&15/SUBTSLB:*
ASSLAPD= BTSM:3/LPDLM:5
Result: all the four subslots of the Abis timeslots from the 11th to the 15th are
associated to BTSM:3.

43

Unlock Abis Subpools related to BTSM:3/LPDLM:5

To unlock Abis Subpools related to BTSM:3/LPDLM:5, enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:11&&15/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 11th to the 15th are
unlocked.

44

Create LPDLM:6 for BTSM:3

Create the LPDLM:6 on the PCMB:2 setting the following attribute value:
ABISCH= 2-31
To get information about LPDLM creation, refer to the specific procedure.

i ..."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Result: LPDLM:6 is created on timeslot 31.

A30808-X3247-L210-7619

221

OMN:BSC

45

Operation
Base Station Controller

Create Abis Subpools related to BTSM:3/LPDLM:6

To create Abis Subpools related to BTSM:3/LPDLM:6, enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:2/TSLB:17&&30/SUBTSLB:*
ASSLAPD= BTSM:3/LPDLM:6
Result: all the four subslots of the Abis timeslots from the 17th to the 30th are
associated to BTSM:3.

46

Unlock Abis Subpools related to BTSM:3/LPDLM:6

To unlock Abis Subpools related to BTSM:3/LPDLM:6, enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:2/TSLB:17&&30/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 17th to the 30th are
unlocked.

47

Get information about BTSM:3

To retrieve information about the BTSM:3 configuration, enter the GETINFO

BTSM command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

GETINFO BTSM

Result: BTSM:3 information is retrieved.

48

Unlock BTSM:3

To unlock BTSM:3 , enter the UNLOCK BTSM command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

UNLOCK BTSM

Result: BTSM:3 is unlocked.

222

A30808-X3247-L210-7619

Operation
Base Station Controller

49

OMN:BSC

Get information about all the three PCMB lines

To retrieve information about the PCMB lines configuration, enter the GETINFO
PCMB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB --->

GETINFO PCMB

Then set the following attribute value:

NAME = PCMB:0&&2
Result: PCMB lines information are retrieved.

50

h ... END

Target

The following figure shows the configuration we have to create, starting from
the configuration shown in step 28.
Timeslots from the 11th to the 16th on PCMB:1 will be moved from BTSM3 to
BTSM:1.

51

Check current situation about BTSM:3

To retrieve information about the BTSM:3 configuration, enter the GETINFO

BTSM command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM --->

GETINFO BTSM

Result: BTSM:3 information is retrieved.

A30808-X3247-L210-7619

223

OMN:BSC

52

Operation
Base Station Controller

Lock Abis Subpools (related to BTSM:3) on PCMB:1

To lock Abis Subpools related to BTSM:3, enter the LOCK SUBTSLB command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> LOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:11&&16/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 11th to the 16th are
locked.

53

Delete Abis Subpools on PCMB:1

To delete Abis Subpools, enter the DELETE SUBTSLB command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> DELETE SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:11&&15/SUBTSLB:*
Result: all the four subslots of the Abis timeslots from the 11th to the 15th are
deleted.

54

Delete LPDLM:5 for BTSM:3

To delete the LPDLM:5 on the PCMB:1, enter the DELETE LPDLM command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> LPDLM --->

DELETE LPDLM

Result: LPDLM:5 is deleted on timeslot 16.

224

A30808-X3247-L210-7619

Operation
Base Station Controller

55

OMN:BSC

Create Abis Subpools related to BTSM:1/LPDLM:3

To create Abis Subpools related to BTSM:1/LPDLM:3, enter the CREATE

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> CREATE SUBTSLB

Then set the following attribute values:

NAME = PCMB:1/TSLB:11&&16/SUBTSLB:*
ASSLAPD= BTSM:1/LPDLM:3
Result: all the four subslots of the Abis timeslots from the 11th to the 16th are
associated to BTSM:1.

56

Unlock Abis Subpools related to BTSM:1/LPDLM:3

To unlock Abis Subpools related to BTSM:1/LPDLM:3, enter the UNLOCK

SUBTSLB command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> TSLB --->

SUBTSLB ---> UNLOCK SUBTSLB

Then set the following attribute value:

NAME = PCMB:1/TSLB:11&&16/SUBTSLB:*

Result: all the four subslots of the Abis timeslots from the 11th to the 16th are
unlocked.

57

Remove the crossconnection (XCONNECT:2) towards BTSM:3

To remove the crossconnection towards BTSM:3, the user must enter the BTSE
Interworking tree related to the BTSM:1 equipment, and then enter the SET
XCONNECT command following the correct sequence of selections (example
regarding the BTSEP interworking tree):

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSEP ---> XCONNECT

---> SET XCONNECT

Then set the following attribute values:

NAME= <BTSE_type>:1/XCONNECT:2
MPTSL11=0-0
..
MPTSL16=0-10
Result: the XCONNECT:2 crossconnection towards BTSM:2 is removed.

END

A30808-X3247-L210-7619

225

OMN:BSC

Operation
Base Station Controller

3.41

Addition of a BTS (Cell)

Introduction
The creation of a BTS (Cell) configures a cell with special global attributes. The management of the BTS object is split into five attribute groups (see "1.9 Attribute Groups"):

BASICS: the attributes within the BASICS group describe the basic properties of a
BTS;
CCCH: this group contains attributes related to common control channels configuration;
INTERF: attributes related to interference measurements;
OPTIONS: the attributes within the OPTIONS group allow to enable services or
features on the cell;
TIMER: it contains attributes related to timer setting.

When creating the BTS object, the user must define at least some mandatory values
belonging to the BASICS group. The mandatory values are:
1. NAME: the user must specify the BTSM absolute number (i.e. the site manager to
which the cell will belong) and the BTS relative number. The last is a number
belonging to the range [0 - 23], that identifies univocally the BTS inside a BTSM (see
"1.5.1 Notes on the CREATE commands").
2. CELLGLID (cell global identity): it contains the Cell Identification (CI) and the Location Area Id of the cell.
3. BSIC (base station identity code): it is composed by two fields, NCC (Network Color
Code) and BCC (base station color code);
4. CELLTYP: it specifies the type of the cell, i.e. standard (maximum MS distance: 35
Km) or extended (maximum MS distance:100 km).
5. SYSID: indicates the frequency band used by the cell. The possible values of the
SYSID attribute are:
SYSID value

Absolute Frequency Number

BB900 (GSM Standard

Band)

1 <= frequency <= 124

DCS1800

512 <= frequency <= 885

F2ONLY900 (GSM
Extended Band)

0 <= frequency <= 124 and 975 <= frequency <= 1023

EXT900 (GSM Mixed

Band)

0 <= frequency <= 124 and 975 <= frequency <= 1023

PCS1900

512 <= frequency <= 810

R-GSM (Railway GSM)

955 <= frequency <= 974

0 <= frequency <= 124 and 975 <= frequency <= 1023
GSMDCS (i.e. a Mixed
Cell using GSM and DCS (GSM extended band);
frequencies, see below) 512 <= frequency <= 885 (DCS1800 band).

226

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

SYSID value
GSM850

Absolute Frequency Number

128 <= frequency <= 251

GSM850PCS (i.e. a
128 <= frequency <= 251 and 512 <= frequency <=
Mixed Cell using GSM850 810
and PCS frequencies,
see below)
GSM850DCS (i.e. a
128 <= frequency <= 251 (GSM850 band) and
Mixed Cell using GSM850 512 <= frequency <= 885 (DCS1800 band).
and DCS frequencies,
see below)
Depending on the setting of the NETWTYPE attribute in the BSC object, only some
of the SYSID values can be selected. The table below shows the correspondence
between NETWTYPE values and the possible SYSID values.

NETWTYPE value

SYSID values

GSMDCS

BB900, DCS1800, F2ONLY900, EXT900, GSMDCS

GSMPCS

BB900, PCS1900

GSMR

R-GSM

GSM850PCS

GSM850, PCS1900, GSM850PCS

GSM850DCS

GSM850, DCS1800, GSM850DCS

GSMRAILPUB

R-GSM, EXT900.

6. BCCHFREQ: defines the absolute radio frequency channel number of the BCCH
channel. The absolute radio frequency channel number belongs to the range related
to the chosen SYSID value.
Besides defining the BCCH frequency, the user can also define up to 63 other frequencies on the selected cell. To configure these frequencies on the cell, the user has to fill
in the CALLF attributes. The BTS object contains 63 CALLF attributes, from CALLF01
to CALLF63; each CALLF attribute represents a frequency available in the cell (the
frequency is defined by the absolute radio frequency channel number, so the absolute
radio frequency channel number must belong to the range related to the chosen SYSID
value).
So, with the BCCHFREQ attribute, and the CALLF attributes, the user can configure on
each cell up to 64 frequencies. The possibility to have a larger number of frequencies
available in one cell can lead to an increase in network's traffic capacity. The number of
TRXs (transceivers) per cell is limited only by BTS equipment. As a consequence,
considering the different BTS (Base Transceiver Station) types, the maximum number
of TRX for each cell can be equal to 24 and it is possible to achieve it with BTS+
(BS240).
Mixed Cells
As previously described, it is possible to configure up to 24 TRXs in a cell; it is also
possible to configure TRXs of the same cell with frequencies belonging to different
bands (these cells are then called Mixed Cells).

A30808-X3247-L210-3-7619

227

OMN:BSC

Operation
Base Station Controller

Three types of Mixed Cells are available:

GSMDCS: this kind of cell uses GSM and DCS frequencies;

GSM850PCS: this kind of cell uses GSM850 and PCS frequencies;
GSM850DCS: this kind of cell uses GSM850 and DCS frequencies.

To configure a mixed cell the user must:

1. set the SYSID attribute to a Mixed Cell value (i.e. GSMDCS,GSMDCS or GSMPCS);
2. set the CALLF attributes to values belonging to both the bands.
After that he can configure some TRXs with frequencies belonging to one band, and
other TRXs with frequencies belonging to the other one (see, "3.57 Addition of a TRX").
The BCCH frequency can belong either to the lower band (one of BB900, f2ONLY900,
EXT900 in the case of GSMDCS, GSM850 in the case of GSMPCS and GSMDCS) or
to the upper band (DCS1800 or PCS1900).
Regarding mixed cells, the following consideration can be done:

MIXED CELLS AND CONCENTRIC CELLS: the only way to realize mixed cells (in
BR7.0) is to implement them as concentric. Therefore mixed cells have also to be
concentric. This means that if the SYSID is GSMDCS, GSMDCS or GSMPCS then
the CONCELL attribute must be set to TRUE, and all the conditions required for
concentric cells have to be fulfilled, e.g. the BCCH frequency must belong to the
complete area (see, "3.93 Concentric Cell Structure Management").

BCCH FREQUENCY: in mixed cells, the BCCH frequency can belong either to the
lower or to the upper band. Anyway, if the BCCH frequency belongs to the upper
band, the MS is required to be able to use this band to access the cell.

FREQUENCY HOPPING: the hopping system is not influenced from this feature. In
fact even if 24 carriers can be present in one cell belonging to different bands, it is
not possible to configure hopping system with frequencies belonging to different
bands. As a consequence in one cell will be possible having one hopping law with
GSM frequencies and one hopping law with DCS frequencies, but a mixed one is not
allowed. So in the hopping system (object FHSY) must be checked that only
frequency belonging to the same band and the same area can be configured in the
same hopping law.

Dual band operation between GSM 850 and PCS1900/DCS1800 are supported on
BTS Plus only (HW and SW features).
On BTS1 family, only those SW features that allow a BTS1, working in another
frequency band, to work with a BTS Plus in the GSM 850 frequency band are
supported (e.g. Handover from 1900MHz to 850MHz cell); but GSM850 itself (e.g.
DualBand cell) is not supported.
After creating a BTS, all the not specified attributes belonging both to the BASICS and
to the other groups will assume their default values. These values can be modified after
the BTS creation through the relevant SET BTS commands.

The creation of the BTS implicitly creates the subordinate PWRC and HAND Managed
Object Instances (these objects will assume their default values). The user can modify
the attributes of these objects with the relative SET commands (SET HAND or SET
PWRC)
The instance number of both HAND, and PWRC managed object is always equal to 0.
The BSS can support:

228

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

up to 150 cells, in case of standard BSC;

up to 250 cells, in case of high capacity BSCs with the old rack (see "1.4.2 High
Capacity BSC with Old Rack");
up to 400 cells, in case of high capacity BSCs with the new rack (see "1.4.3 High
Capacity BSC with New Rack");

Prerequisites
To enter this command the existence of the containing BTSM is necessary.
The Network Element must be in phase 2.
To create this object the user must have the visibility level number set to "2".

Precondition
Does the containing BTSM already exist?

Y h ... 2
N i ..."3.39 Addition
of a New Site
Manager and of
related LAPD
links"

Create a BTS

To create a BTS, the user must enter the CREATE BTS command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS

---> CREATE BTS

Result: Creation acknowledge in locked state.

Note: all the attributes related to the created BTS object, and to the subordinate
HAND and PWRC objects, assume their system-determined default values.
These settings can be modified using the relative SET Commands.

Unlocking of the BTS

To place the BTS in service, the user must unlock the object by entering the
UNLOCK BTS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS

---> UNLOCK BTS

Result: The BTS object assumes the unlocked BTS state.

END

A30808-X3247-L210-3-7619

229

OMN:BSC

Operation
Base Station Controller

3.42

Addition of a FHSY
Introduction
The Frequency Hopping System object class represents a set of radio frequency channels used in a specific frequency hopping sequence. An instance of Frequency Hopping
System may be (and often it is) shared by one or more channels.
When defining a new Frequency Hopping System instance, the user must specify how
many frequencies are involved, among those belonging to the superordinate cell (the
frequencies belonging to the cell are defined, when creating the cell, using BCCHFREQ
and CALLF attributes; see "3.41 Addition of a BTS (Cell)". To select the frequencies that
must belong to the Frequency Hopping, the MOBALLOC parameter is used.
During a Radio Channel Configuration a frequency hopping can be specified for the
channel transmission via the FHSYID attribute.
The default value of the parameter, (0), is used to indicate "no frequency hopping".
Otherwise, the selected frequencies will be those specified by the corresponding
frequency hopping instance.
If HOPMODE= BBHOP and CONCELL=TRUE, the TRXAREA parameters of the TRXs,
supporting the frequencies in the FHSY, must be equal.
If HOPMODE= SYNHOP the BCCH frequency can not be included in a FHSY instance.

If the involved cell is a Mixed Cell (i.e. SYSID =GSMDCS, GSM850PCS or

GSM850DCS, see "3.41 Addition of a BTS (Cell)"), it has to be checked that the mobile
allocation attribute (MOBALLOC) contains frequencies belonging to just one of the five
bands (BB900, GSM extension, DCS1800, GSM850 and PCS 1900).
As it has been described in "3.59 Enabling/Disabling EGPRS service", to implement
EGPRS, some GSM-CUs have to be replaced by EDGE-CUs at any arbitrary CU rack
position of BTSplus equipment. In case of Baseband frequency hopping all TRXs
involved in the same hopping law must be homogeneus, i.e. they must have the same
TRXMD value. If a TRX with TRXMD = EDGE gets TRX_CAPABLITY = GSM (e.g. due
to a reconfiguration) the hopping for the TRX related to this hopping law is stopped in
the cell, and the operator is informed.
Synthesizer frequency hopping is not affected.

Prerequisites
Before the creation of any FHSY, the frequency hopping instance (associated to a physical TRX) must not be already equipped. Radio frequencies used by FHSY are already
created if the HOPMODE parameter is equal to BBHOP, else, if HOPMODE is equal to
SYNHOP, the used frequencies must be contained in the Cell Allocation Attributes
(CALLF) of the BTS object instance (BASIC group). The instance 0 of the frequency
hopping system is not configurable: it is always available and means no hopping.

230

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Add a FHSY instance

The user must add a FHSY instance with the CREATE FHSY command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> FHSY

----> CREATE FHSY

Result: Creation of a new FHSY instance.

END

A30808-X3247-L210-3-7619

231

OMN:BSC

Operation
Base Station Controller

3.43

Addition of a Frequency to FHSY

Introduction
Adding a frequency to FHSY is a step to change a TRX definition in case of frequency
hopping.
When setting HOPP=false a Frequency Redefinition is performed. According to GSM
Rec. 04.08 Frequency Redefinition Procedure it is only allowed to change the following
parameters: Cell Channel Description, Mobile Allocation and MAIO (Mobile Allocation
Index Offset). It's not allowed to change: H-bit, HSN and TSC.
The BTS attribute HOPP can be used by the operator to switch via command from one
carrier hopping (HOPP=false) to n-carrier hopping (HOPP=true) and vice versa.
The CHANNEL attribute FHSYID is used for the H-Bit:
FHSYID=0 ==> H-Bit=0 and
FHSYID!=0 ==> H-Bit=1.
Some mobiles, which are not GSM conform, have problems when Baseband frequency
hopping (in any CHANNEL FHSYID!=0) and BS Power Control are enabled at the same
time (measurement results are wrong if BCCH is in hopping sequence). To avoid such
problems it is necessary to enable the "BS Power Control Correction" in the related
PWRC object. (This is only necessary in case of baseband FM).
Two different approaches can be followed to change the FHSY definition. The first one
is strongly recommended to avoid service loss. It requires to create a new FHSY object
including the required changes, then to delete the old one. The new created FHSY must
be associated to all the channels using the old FHSY and eventually to the new ones.
As a preliminary step, the hopping attribute must be set to false for the BTS which the
FHSY belongs to.
The procedure outline described above prevents from service loss, since it does not
require to lock active channels. It cannot be followed if the number of FHSY already
defined is 10, since the system does not allow to create more than 10 FHSY for the
same BTS. If this is the case, the second approach must be followed. This second
procedure outline consists in SETting directly the FHSY to be changed. This requires to
lock the channels using that FHSY; the consequence is a loss of service for the involved
channels.
Prerequisites
The instance of the BTS managed object must be existent.
The TRX corresponding to the new frequency must be already created if the HOPPMODE parameter is equal to BBHOP else, if HOPPMODE is equal to SYNHOP, the new
frequency has to be contained in the Cell Allocation (CALL) of the bts number object
instance.

232

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Precondition

Before any operation the user must set to false the hopping attribute of the
involved BTS.
Is HOPP=false?

Y h ... 2
N i ..."3.55 Disabling
Frequency
Hopping for a
BTS"

Get the FHSY actual settings

Since the FHSY actual settings are relevant for the next steps, it is safe to GET
them entering the GET FHSY command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS---> FHSY

---> GET FHSY

Result: Getting FHSY attributes.

Is the actual number of configured FHSY objects less than 10 ?

Y h ... 3
N h ... 7

Create a new FHSY object

A new FHSY object must be created, including all the frequencies of the old one
plus the new frequency to be added.
The specified HSN parameter must be equal to the old one. If HSN is changed,
all channels involved in the next step must be LOCKed before submit the SET
CHAN command, then UNLOCKED after that command. This will cause a
service loss for those channels!
Use the CREATE FHSY command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> FHSY

---> CREATE FHSY with <old frequencies> and <new frequency>

Result: Create a new FHSY

All the channels that have to use the new frequency must be moved to the new
FHSY. This operation is different for channels already set with a FHSY and
channels that are not actually associated with a FHSY.
FHSY ID different from 0
FHSY ID equal to 0

A30808-X3247-L210-3-7619

h ... 4
h ... 5

233

OMN:BSC

Operation
Base Station Controller

Assign the new FHSY to all the channels which are actually using it

For channels already set with a FHSY (FHSY ID <> 0), simply set the channel
FHSY attribute using the SET CHAN command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SET CHAN with FHSY ID = FHSYnew

Result: Assign the new FHSY to all the channels which are actually using it.
This step must be repeated for all the channels that are already set with a
FHSY (FHSY ID <> 0). Be aware that this is completely done. Deleting a
FHSY may result in an error if some channel is still using it.

h ... 6

Is the new FHSY assigned to all the channels?

Assign the new FHSY to all the channels which will use it

Channels with FHSY ID = 0 must be LOCKed before SETting them and

UNLOCKed after using the next commands:

b
b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS---> TRX

---> CHAN ---> LOCK CHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS---> TRX
---> CHAN ---> SET CHAN with FHSY ID = FHSYnew
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX
---> CHAN ---> LOCK CHAN

Result: Assign the new FHSY to all the channels which will use it.
This step must be repeated for all the channels to be associated with the
new FHSY, if their actual setting is FHSY ID = 0.

Delete the old FHSY version

In order to clean-up the environment, the old FHSY version should be deleted
using the DELETE FHSY command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> FHSY

--->DELETE FHSYold

Result: Delete the old FHSY.

234

h ... 10

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set the FHSY ID value to 0

For all the channels using the FHSY to be changed, set the FHSY ID value to 0
using the SET CHAN command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX --> CHAN --->SET CHAN with FHSY ID = 0

Result: For all the channels using the FHSY to be changed, set the corresponding FHSY ID to 0.

Change the FHSY attributes

The FHSY attributes can now be changed using the SET FHSY command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> FHSY

---> SET FHSY

Result: Change the FHSY attributes.

Use the same settings obtained from the GET command avoiding the
frequency to be deleted.

...... 2

Re-set the FHSY ID to the old value

For all the channels using that FHSY, re-set the FHSY ID to the old value. This
step requires to LOCK the channels, to SET them and finally to UNLOCK them
using the next commands:

b
b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX --> CHAN ---> LOCK CHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX --> CHAN ---> SET CHAN with FHSY ID = Old value
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX --> CHAN ---> UNLOCK CHAN

Result: Assign the same FHSY to all the channels which will use it.
This step must be repeated for all the channels to be associated with the
FHSY, both the ones already using it and the new ones.

A30808-X3247-L210-3-7619

235

OMN:BSC

10

Operation
Base Station Controller

Re-set the hopping attribute to true

Is HOPP=BBHOP?

Y h ..."3.56 Enabling
Frequency
Hopping for a
BTS"

N h ... 2
END

236

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.44

OMN:BSC

Deletion of a Frequency from FHSY

Introduction
Removing a frequency to FHSY is a preliminary step to change or delete a TRX definition in case of frequency hopping only if HOPMODE=BBHOP.
When setting HOPP=false a Frequency Redefinition can be implemented. According to
GSM Rec. 04.08 Frequency Redefinition Procedure it is only allowed to change the
following parameters: Cell Channel Description, Mobile Allocation and MAIO (Mobile
Allocation Index Offset). It's not allowed to change: H-Bit, HSN and TSC.
The BTS attribute HOPP can be used by the operator to switch via command from one
carrier hopping (HOPP=false) to n-carrier hopping (HOPP=true) and vice versa.
The CHANNEL attribute FHSYID is used for the H-Bit:
FHSYID=0 ==> H-Bit=0 and
FHSYID!=0 ==> H-Bit=1.
Some mobiles, which are not GSM conform, have problems when frequency hopping (in
any CHANNEL FHSYID!=0) and BS Power Control are enabled at the same time
(measurement results are wrong if BCCH is in hopping sequence). To avoid such problems it is necessary to enable the "BS Power Control Correction" in the related PWRC
object.
Two different approaches can be followed to change the FHSY definition. The first one
is strongly recommended to avoid service loss. This approach requires to create a new
FHSY object including the required changes, then to delete the old one. The new
created FHSY must be associated to all the channels using the old FHSY excluding
those that are actually using the frequency to be deleted (only in case of BBHOP). Channels that must be excluded from hopping have to be set with FHSY ID = 0. As a preliminary step, the hopping attribute must be set to false for the BTS which the FHSY
belongs to.
The procedure outline described above prevents from service loss, since it does not
require to lock active channels. It cannot be followed if the number of FHSY already
defined is 10, since the system does not allow to create more than 10 FHSY for the
same BTS. If this is the case, the second approach must be followed. This second
procedure outline consists in SETting directly the FHSY to be changed. This requires to
lock the channels using that FHSY; the consequence is a loss of service for the involved
channels.
Prerequisites
The instance of the BTS managed object must be existent.

A30808-X3247-L210-3-7619

237

OMN:BSC

Operation
Base Station Controller

Set the Enable Hopping attribute for the involved BTS to false

Before any operation, the user must set to false the hopping attribute of the
involved BTS.

Y h ... 2
N i...."3.55 Disabling

Is HOPP=false?

Frequency
Hopping for a
BTS"

Get the FHSY actual settings

Since the FHSY actual settings are relevant for the next steps, it is safe to GET
them entering the GET FHSY command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

FHSY ---> GET FHSY

Result: Getting FHSY attributes.

Y h ... 3
N h ... 7

Is the actual number of configured FHSY objects less than 10 ?

Create a new FHSY object

A new FHSY object must be created, excluding the frequency to be removed.

The FHSY object must have the HSN attribute equal to the old one. If HSN is
changed, all channels involved in the next step must be LOCKed before submit
the SET CHAN command, then UNLOCKED at the end. This will cause a
service loss for those channels!
Use the CREATE FHSY command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

FHSY --->CREATE FHSY

Result: Create a new FHSY

238

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Move all the channels that will continue to have a hopping law associated
to the new FHSY

All the channels that will continue to have a hopping law associated to (using
any frequency included in the new version of FHSY) must be moved to the new
FHSY using the SET CHAN command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SET CHAN with FHSY ID = FHSYnew

Result: Assign the new FHSY to all the channels which will continue to use it.
This step must be repeated for all the channels excluding those that must be
removed from the hopping law.
Is the new FHSY assigned to all the channels

h ... 6

Assign FHSY ID=0 to all the channels that must be excluded from the
hopping law

Channels that won't have a hopping law associated to must be set with FHSY
ID=0 and MAIO=0 using the SET CHAN command following the next sequence
of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN --->SET CHAN with FHSY ID=0 and MAIO=0, too

Result: Assign FHSY ID=0 to all the channels that must be excluded from the
hopping law.
This step must be repeated for all the channels that are already set with a
FHSY (FHSY ID <> 0) and must be set with FHSY ID=0.

Delete the old FHSY version

In order to clean-up the environment, the old FHSY version should be deleted
using the DELETE FHSY command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> FHSY

---> DELETE FHSYold

Result: Delete the old FHSY.

A30808-X3247-L210-3-7619

239

OMN:BSC

Operation
Base Station Controller

Set the FHSY ID value to 0

For all the channels using the FHSY to be changed, set the FHSY ID value to 0
using the SET CHAN command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX --> CHAN ---> SET CHAN with FHSY ID = 0

Result: For all the channels using the FHSY to be changed, set the corresponding FHSY ID to 0.

Change the FHSY attributes

The FHSY attributes can now be changed using the SET FHSY command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> FHSY

---> SET FHSY

Result: Change the FHSY attributes.

Use the same settings obtained from the GET command avoiding the
frequency to be deleted.

......2

Re-set the FHSY ID to the old value

For all the channels using that FHSY, re-set the FHSY ID to the old value. This
step requires to LOCK the channels, to SET them and finally to UNLOCK them
using the next commands:

b
b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> LOCK CHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX
---> CHAN ---> SET CHAN with FHSY ID = Old value
MANAGED-ELEMENT ---> BSS-FUNCTIONAL --->BTSM ---> BTS ---> TRX
---> CHAN ---> UNLOCK CHAN

Result: Assign the same FHSY to all the channels which will use it.

10

Verification of Hopmode attribute

If you are changing or deleting a TRX definition in case of frequency hopping (if
HOPMODE=BBHOP):
Is HOPMODE=BBHOP

Y h ..."3.56 Enabling
Frequency
Hopping for a
BTS"

N h ... END
END

240

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.45

OMN:BSC

Addition of a Network Service Virtual Connection

Introduction
The NSVC functional object represents the end-to-end communication between the
BSC and the SGSN. At the creation of a new NSVC, the system updates all necessary
relation between the NSVC and all PTPPKFs (PTPPKFTDs in case of TD-SCDMA technology) connected to the involved PCU (PCUTD in case of TD-SCDMA technology).
Prerequisites
To enter this command the existence of the FRL object is necessary.
The NSVC object must not be already created and it must be created.
To create this object the user must have the visibility level number set to "2".

Precondition
Does the FRL object instance already exist?

Y h ... 2
N i ..."3.49 Addition
of a Frame
Relay Link"

Create a NSVC

To create a NSVC, the user must enter the CREATE NSVC command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> NSVC ---> CREATE NSVC

Result: Creation of a NSVC.

Unlocking of the NSVC

To place the NSVC in service, the user must unlock the object by entering the
UNLOCK NSVC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> NSVC ---> UNLOCK NSVC

Result: Unlocking of the newly created NSVC.

END

A30808-X3247-L21037619

241

OMN:BSC

Operation
Base Station Controller

3.46

Deletion of a Network Service Virtual Connection

Introduction
Deleting a Network Service Virtual Connection signifies to remove the end-to-end
communication between the BSC and the SGSN.
Prerequisites
The NSVC object must be in locked state.
The last NSVC can be deleted only if there is not any PTPPKF (or PTPPKFTD in case
of TD-SCDMA technology) object equipped on the same PCU (PCUTD).

Precondition

Y h ... 3
N h ... 2

Is NSVC locked?

Lock the NSVC

In order to delete the NSVC, it must be locked entering the LOCK NSVC
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> NSVC ---> LOCK NSVC

Result: Locking NSVC.

Delete the NSVC

The NSVC can now be deleted entering the DELETE NSVC command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> NSVC ---> DELETE NSVC

Result: Delete the NSVC.

END

242

A30808-X3247-L21037619

Operation
Base Station Controller

3.47

OMN:BSC

Addition of a Point-to-Point Packet Function

(GPRS/EGPRS)
Introduction
The PTPPKF functional object represents the point to point packet data service in a cell.
Point to point data services regard:

GPRS service, i.e. packet switched data services using the traditional GMSK modulation;

EGPRS service: EGPRS introduces the 8-PSK modulation in the existing GSM
network to increase up to 384kbps the data rate for data services.

The evolution from GSM to EDGE is performed in order to support high data rates in all
of the GSM frequency bands established by GSM network providers and operators.
EDGE itself supports both Enhanced Circuit Switched Data (ECSD) and Enhanced
General Packet Radio Services (EGPRS).

In the present release, EDGE is applied only to packet services (i.e. only EGPRS is
supported). However, the generic term EDGE is used in O&M attributes that, in some
future release, could be used to define the support of EDGE circuit switched service.
The general goals of EGPRS are the following:

the 8PSK modulation principle enhances the air interface data rates of an existing
GSM carrier frequency. It uses eight symbols, each covering three bits and determining the phase shift applied within one entire wavelength;

8PSK modulation is applied to Packet Data Traffic Channels (PDTCH). Existing

logical air interface channels, as well as existing burst and radio block structures are
used;

message flow protocols adapted for EGPRS can connect an EDGE capable GSM
mobile station (MS) to the GPRS Support Nodes (GSN) and Packet Data Networks
(PDN);

the use of several modulation and coding schemes provides a seamless adaptation
to varying air interface conditions.

Main topics regarding GPRS and EGPRS are:

GPRS uses four coding schemes (CS1, CS2, CS3, CS4), whereas nine different
coding schemes have been specified for EDGE (MCS-1 to MCS-9);

EDGE lower coding schemes MCS-1 to MCS-4 use GSMK modulation

whereas higher coding schemes, MCS-5 to MCS-9, use the 8PSK one.

when higher coding schemes are used (e.g. MCS-9 for edge, or CS3 and CS4 for
GPRS, see "3.60 Enabling/Disabling GPRS CS3-CS4 Coding Schemes"), one
timeslot of the Um interface transfers more user data than one timeslot of the Abis
interface can accommodate. In order to accommodate this case, the Um interface
timeslot is associated to an adequate number of Abis interface timeslots (see
"3.40 Configuration of the Abis Interface").

GPRS and EGPRS use the same logical channels: PBCCH, PCCCH, PDTCH and
PACCH.

A30808-X3247-L210-7619

243

OMN:BSC

Operation
Base Station Controller

In the Containment tree, the PTPPKF object is hierarchically dependent by the BTS one
(see "1.5.1 Notes on the CREATE commands"). For each BTS instance (i.e. for each
configured cell) there is only one PTPPKF object instance subordinated to it. This
instance is always equal to 0.
So, the user can configure the GPRS/EGPRS services in a cell (i.e. the PTPPKF
instance number 0) only after having configured the cell (i.e. the related BTS instance).
This procedure creates the instance of the PTPPKF object related to a specific cell.
When creating the PTPPKF instance, the user must fill at least the following mandatory
attributes:
1. Routing Area Color (RACOL attribute);
2. Routing Area Code (RACODE attribute).
Besides, when configuring the GPRS/EGPRS services on a cell (i.e. when creating a
PTPPKF object instance), the user shall specify some other parameters (belonging to
the PTPPKF object) that allow him to configure the two services according to his needs.
Among the parameters of the PTPPKF object, two of them allow to make available or
not packet data services in the referred cell. In fact, when a PTPPKF object instance
is created, neither GPRS service nor EGPRS service are enabled as default. So the
user to enable GPRS and EGPRS has to manage two specific parameters; they are:
1. the EGPRS flag allows to make available or not not available the whole Packet Data
services in the cell, i.e. both GPRS (based on CS1, .., CS4), and EGPRS (based on
MCS1, .., MCS9). The EGPRS flag has the same functional behaviour as the
command lock/unlock on the PTPPKF object; the only difference is that, in case of
EGPRS=FALSE, the operational state of PTPPKF is disabled. In this way for the
operator is clear that the PTPPKF cannot provide service, even if it unlocked.
The default value of the EGPRS flag is FALSE; this means that when creating the
PTPPKF object instance, the cell is disabled to support, in general, both
(GPRS/EGPRS) packet data services. But it must be noted that:
before setting EGPRS=TRUE the user shall specify, for each cell, at least one
TRX that support the GPRS service; i.e. he can choose, among the total number
of TRXs configured for the cell, which of them will handle packet data services
(see "3.58 Enabling/Disabling GPRS Service").
to enable EGPRS services in the cell is not sufficient to set EGPRS=TRUE but
other parameter settings are required (see below); but setting EGPRS=TRUE is
the first step in the procedure that allows to configure the EGPRS service in the
cell (see "3.59 Enabling/Disabling EGPRS service").
2. the EEDGE flag allows to make available or not available the EGPRS service in the
cell, provided that the GPRS service is available and there are radio resources
configured to support EDGE. It is not allowed to make the EGPRS service available
(EEDGE=TRUE) if the GPRS service is not available (EGPRS=FALSE) or if no TRX
in the cell has been configured to support EDGE.Moreover, EEDGE cannot be set

244

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

to TRUE if CSCH3CSCH4SUP parameter is set to FALSE .

To make available the EGPRS service without activation of CS-3 /CS-4 coding
schemes, the operator shall set the bit25 of MNTBMASK parameter to TRUE,meaning
that the max coding scheme usable will be CS-2 independently from
CSCH3CSCH4SUP value set to TRUE.Other parameter settings are required to enable
EGPRS services in the cell(see "3.59 Enabling/Disabling EGPRS service").The default
value of the EEDGE flag is FALSE.
After having defined how many TRXs will support GPRS and EGPRS services (see
"3.58 Enabling/Disabling GPRS Service" and "3.59 Enabling/Disabling EGPRS
service"), the user shall indicate how the slots belonging to these TRXs shall be
managed; the following statements show how the user can configure the GPRS/EGPRS
service on the TRXs where GSUP=TRUE:
1. the user can reserve, on a channel basis, some slots to packet switched data
services only; these slots will be statically allocated to GPRS/EGPRS signalling
(PBCCH and PCCCH) and will not be used for circuit switched services. The user
can define these only GPRS/EGPRS slots on a channel basis, by setting the
GDCH attribute of the chosen CHAN object (see "3.64 Addition of a Radio
Channel");
2. then the user has the possibility to configure among the remaining timeslots, other
static timeslots for packet switched data services (i.e. not shared with CS services);
the user can indicate this number of static slots using the GMANPRES attribute of
the PTPPKF object.
The difference with respect to the configuration of static slots using the GDCH
attribute, is that with GDCH the configuration is made on a channel basis and
regards GPRS/EGPRS signalling channels only, whereas using GMANPRES the
configuration is made without indicating the channel, but only a number of channels and regards GPRS/EGPRS traffic channels only.
If for example, the user defines 4 static GPRS/EGPRS slots using GMANPRES,
then 4 slots will be reserved for packet switched data traffic on the TRXs where
GSUP=TRUE;
3. finally the user can choose among the remaining available slots (on TRXs where
GPRS is supported) the maximum number of dynamic GPRS/EGPRS channels;
these channels will be shared between GPRS/EGPRS and CS services, according
to the actual request of resources. To configure these number of shared slots the
user has to set the GPDPDTCHA attribute (PTPPKF object). It indicates a
percentage; this percentage is applied to the total number of available slots (i.e. the
number of slots on TRXs where packet switched data services are supported,
without considering both static GPRS/EGPRS slots and slots reserved for GSM
signalling) to find the maximum number of dynamic GPRS/EGPRS slots.
Example:
Lets suppose that in a cell more than one TRX is configured for GPRS/EGPRS and
that the maximum number of available slots for both GPRS/EGPRS and CS services
is 22.
If the user sets:
GPDPDTCHA= 50 (i.e. 50%);
GDCH= PBCCH for one CHAN object;

A30808-X3247-L210-7619

245

OMN:BSC

Operation
Base Station Controller

GMANPRES=1
then, the maximum number (N) of GPRS/EGPRS channels shared with CS services
is given by the following formula:

N= (Total number of available timeslots - Number of GPRS/EGPRS static slots) *

GPDPDTCHA/100 = ( 22 - 2 ) * 50/100 = 10

So, in this cell we will have 2 slots statically allocated for GPRS/EGPRS (one signalling slot defined on a channel basis using the GDCH attribute and the other one
defined on a cell basis using GMANPRES), 10 slots shared between GPRS/EGPRS
e CS services, and 10 slots reserved for CS services.
To define how many users can be multiplexed in a GPRS/EGPRS slot, the GMANMSAL
attribute (PTPPKF object) is used. It defines the maximum number of GPRS users that
can share the same timeslot (PDCH); it is composed by two fields: the first indicates the
maximum number of users in uplink direction, the second one specifies the maximum
number of users in downlink direction.

The procedure regarding the management of GPRS/EGPRS radio resources is

discussed in "3.104 Management of Radio Resources".

CONFIGURATION OF BCCH TRANSCEIVER

The EGPRS Packet Channel Request is only supported by an EDGE-CU. Therefore the
use of the EGPRS Packet Channel Request can be forced by configuring the BCCHTRX in EDGE mode, which implies the allocation of a E-CU to the TRX (see
"3.59 Enabling/Disabling EGPRS service").
By means of the EBCCHTRX attribute the operator can decide, whether the channels
of the BCCH-TRX are available for EDGE 8-PSK services or not.

EGPRS has bad behaviour with high power, so only if the power is acceptable EDGE
8PSK TBFs are possible on the BCCH TRX.
Even if the BCCH TRX is created in EDGE mode the two timeslots 0 and 7 are not
allowed to operate in EDGE-mode. This is necessary for compatibility with Mobiles
which do not support EDGE.
Prerequisites
To enter this command the existence of the related BTS object, of the PCU and at least
of a NSVC object on the same PCU is necessary.
The PTPPKF object must not be already created and it must be created.
To create this object the user must have the visibility level number set to "2".

246

A30808-X3247-L210-7619

Operation
Base Station Controller

Preliminary Consideration

a. If the BTS object exist go to next step b. otherwise see addition of a BTS
(Cell)
b. If the PCU object exist go to next step c. otherwise

c. If a NSVC object on the same PCU doesnt exist

OMN:BSC

i ..."3.41 Addition
of a BTS (Cell)"

i ..."3.51 Addition
of a Packet
Control Unit"
i ..."3.45 Addition
of a Network
Service Virtual
Connection"

Create a PTPPKF

To create a PTPPKF, the user must enter the CREATE PTPPKF command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> CREATE PTPPKF
Then he must set the following parameters:
RACODE
RACOL
and also he can set the following parameters (according to his needs):
GMANMSAL
GPDPDTCHA
GMANPRES

Result: creation of a PTPPKF.

Unlocking of the PTPPKF

To place the PTPPKF in service, the user must unlock the object by entering the
UNLOCK PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> UNLOCK PTPPKF

Result: Unlocking of the newly created PTPPKF.

Consideration

To really allow packet data services on the cell, you must configure the service
on a TRX basis, choosing the favorite TRXs.

i ..."3.58 Enabling/Dis
abling GPRS
Service"

END

A30808-X3247-L210-7619

247

OMN:BSC

Operation
Base Station Controller

3.48

Deletion of a Point-to-Point Packet Function

Introduction
Deleting a Point-to-Point Packet Function signifies the removing of a previously created
instance of the PTPPKF object class. The appropriate system information shall be sent
on Um interface to inform the mobile about availability of the service. Because of also
SGSN knows the BVCI connected to this object, appropriate actions to inform it about
new PTPPKF configurations, are taken by BSC.
Prerequisites
The PTPPKF object must be in locked state.

Precondition

Y h ... 3
N h ... 2

Is PTPPKF locked?

Lock the PTPPKF

In order to delete the PTPPKF, it must be LOCKed entering the LOCK PTPPKF
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> LOCK PTPPKF

Result: Locking PTPPKF.

Delete the PTPPKF

The NSVC can now be deleted entering the DELETE PTPPKF command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF --->DELETE PTPPKF

Result: Delete the PTPPKF.

END

248

A30808-X3247-L21037619

Operation
Base Station Controller

3.49

OMN:BSC

Addition of a Frame Relay Link

Introduction
The FRL functional object represents the physical link connection on Gb interface.
Creation of FRL link means to make a semi-permanent network connection between the
time slot on PCMA or PCMG and the corresponding time slot on internal 2 Mbit/s (standard BSC) or 8 Mbit/sec (high capacity BSC).
When the BSC have been aligned with the remote peer, the FRL object will be put in
Enabled state.
Prerequisites
To create a FRL object the existence of the PCU (or PCUTD in case of TD-SCDMA) and
PCMA/PCMG is necessary.
The FRL object must not be already created and it must be created.
To create this object, the user must have the visibility level number set to "2".

Preliminary Consideration
Do you want te create the frame relay link on a PCMA line?

Y h ... 2
N h ... 3

Locking of the TRAU

To create the FRL on a PCMA, lock the relative TRAU, by entering the LOCK
TRAU command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> LOCK TRAU

Result: Locking of the ralative TRAU.

Create a FRL

To create a FRL, enter the CREATE FRL command following the next sequence
of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> FRL ---> CREATE FRL

Result: Creation of a FRL.

A30808-X3247-L210-7619

249

OMN:BSC

Operation
Base Station Controller

Unlocking of the FRL

To place the FRL in service, unlock the object by entering the UNLOCK FRL
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCU ---> FRL --->

UNLOCK FRL

Result: Unlocking of the newly created FRL.

END

250

A30808-X3247-L210-7619

Operation
Base Station Controller

3.50

OMN:BSC

Deletion of a Frame Relay Link

Introduction
Deleting a Frame Relay Link signifies the removing of the physical link connection on
Gb interface.
Prerequisites
All NSVC attached to considered FRL must be deleted.
FRL object must be previously locked.

Preliminary Consideration

a. If all NSVC are deleted go to next step b. otherwise

i ..."3.46 Deletion
of a Network
Service Virtual
Connection"

b. If FRL object is in unlocked state

h ... 2

Lock the FRL

In order to delete the FRL, it must be LOCKed entering the LOCK FRL
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> FRL ---> LOCK FRL

Result: Locking FRL.

Delete the FRL

The FRL can now be deleted entering the DELETE FRL command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> FRL ---> DELETE FRL

Result: Delete the FRL.

END

A30808-X3247-L21037619

251

OMN:BSC

Operation
Base Station Controller

3.51

Addition of a Packet Control Unit

Introduction
The PCU functional object represents packet control unit designed to implement
GPRS/EGPRS service in SBS.
Regarding the PCU object, a distinction must be done according to the used BSC type,
i.e. standard BSC or high capacity BSC (see "1.4 Supported BSC Types"):
a) STANDARD BSC: only two PCU objects can be created (instances 0 and 1); the
creation of the PCU object implies the consequent creation of both PPCU cards
(active and standby) related to the created PCU object.
The creation of the PCU:0 involves the creation of both the PPCU:0 and the
PPCU:1, while the creation of the PCU:1 involves the creation of both the PPCU:2
and the PPCU:3.
The system firstly creates the two PPCU objects, and then the PCU object. When
the first card will be Providing Service, then the PCU will starts the configuration
alignment.
Because of the PPCUs are inserted in the BSC rack in substitution of some PPLDs,
when the user creates a PCU, some PPLDs shouldnt have been equipped, with the
following rule:
PCU: 0 --> PPLD: 11, 12, 13, 14
PCU: 1 --> PPLD: 7, 8, 9, 10
b) HIGH CAPACITY BSC with the OLD rack: up to six PCU object instances can be
created (range [0..5]); the creation of the PCU object implies the consequent
creation of the corresponding PPXU object (in fact, the PPXU object has the same
range [0...5] of the PCU object).
c) HIGH CAPACITY BSC with the NEW rack: up to twelve PCU object instances can
be created (range [0..11]); the creation of the PCU object implies the consequent
creation of the corresponding PPXU object (in fact, the PPXU object has the same
range [0...11] of the PCU object).
After having created PCU objects, the user can create the PTPPKF objects that represent the cell supporting GPRS/EGPRS. Since the association between PTPPKFs and
PCUs is not fixed, but it is decided run time by the BSC, all the attribute sbelonging to
PCU object, with the exception of the following ones:

NSEI;
TNSVCBLK;
NNSVCBLKR;
NNSVCUBLR;
TNSVCR;
NNSVCRR;
TNSVCTST;
TNSVCPTST;
NNSVCTSTR.

must be set to the same value for all the PCUs present in the system.

252

A30808-X3247-L21037619

Operation
Base Station Controller

OMN:BSC

Prerequisites
In case of standard BSCs or high capacity BSC with the old rack (see "1.4 Supported
BSC Types"), the superordinate of either PPCU or PPXU (i.e. the EPWR) must be
created.
To create all these objects, the user must have the visibility level number set to "2".

Choose the BSC type

Is the BSC a standard one or an high capacity BSC with the old rack?
Is the BSC an high capacity one with the new rack?

Precondition
Is EPWR already created?

h ... 2
h ... 4
Y h ... 4
N h ... 3

Create an EPWR

Create an EPWR by entering the CREATE EPWR command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> EPWR --->

CREATE EPWR

Result: Creation of an EPWR.

Create a PCU

Create a PCU by entering the CREATE PCU command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCU ---> CREATE PCU

Result: Creation of a PCU

Unlock the PCU

To place the PCU in service, the user must unlock the object, by entering the
UNLOCK PCU command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> PCU --->

UNLOCK PCU

Result: Unlocking of the created new PCU.

END

A30808-X3247-L21037619

253

OMN:BSC

Operation
Base Station Controller

3.52

Deletion of a Packet Control Unit

Introduction
Deleting a Packet Control Unit requires to delete all the related FRLs.
Either the two PPCU cards (in case of standard BSC) or the single PPXU card (in case
of high capacity BSCs) related to this PCU functionality will be implicitly deleted by the
system (see, "1.4 Supported BSC Types" and "3.51 Addition of a Packet Control Unit").
Prerequisites
All FRLs connected to PCU must be previously deleted.

Precondition

Are the related FRLs deleted?

Y h ... 2
N i...."3.50 Deletion
of a Frame
Relay Link"

Lock the PCU

The PCU is locked by entering the LOCK PCU command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCU ---> LOCK PCU

Result: Delete the PCU.

Delete the PCU

The PCU can now be deleted entering the DELETE PCU command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCU ---> DELETE PCU

Result: Delete the PCU.

END

254

A30808-X3247-L21037619

Operation
Base Station Controller

3.53

OMN:BSC

Addition of a PCM line in G interface

Introduction
The PCMG functional object represents the direct physical connection between the BSC
and the SGSN. This line carries 32 time slots of 64 kbit/s that can handle maximum of
31 FRL. Creation of PCMG line means to associate a specific LICD port to a Gb interface
connection.
Prerequisites
The PCMG object must not be already created and it must be created.
To create these objects, the user must have the visibility level number set to "2".
To create a PCMG object the existence of the LICD is necessary.

Precondition
Does the LICD exist?

Y h ... 2
N i ..."3.74 Addition
of a PPLD (only
for standard
BSC) and of a
LICD Board"

Create a PCMG

To create a PCMG, the user must enter the CREATE PCMG command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMG ---> CREATE

PCMG

Result: Creation of a FRL.

Unlock the PCMG

To place the PCMG in service, the user must unlock the object, by entering the
UNLOCK PCMG command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMG ---> UNLOCK

PCMG

Result: Unlocking of the newly created PCMG.

END

A30808-X3247-L21037619

255

OMN:BSC

Operation
Base Station Controller

3.54

Deletion of a PCM line in G interface

Introduction
Deleting a PCMG object requires to delete all FRLs attached. The deletion of this object
implies the removing of the direct physical connection between the BSC and the SGSN.
Prerequisites
All FRLs attached must be previously deleted.

Precondition
Has FRLs been deleted?

Y h ... 2
N i...."3.50 Deletion
of a Frame
Relay Link"

Delete the PCMG

The PCMG can now be deleted entering the DELETE PCMG command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMG --->

DELETE PCMG

Result: Delete the PCMG.

END

256

A30808-X3247-L210-7619

Operation
Base Station Controller

3.55
1

OMN:BSC

Disabling Frequency Hopping for a BTS

Set the Enable Hopping attribute for a BTS to false

Before any operation, the user must set to false the hopping attribute of the
involved BTS with the SET BTS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS with HOPP=false

Result: Setting the Enable Hopping attribute to false for the involved BTS.
Return to calling procedure

END

A30808-X3247-L210-3-7619

257

OMN:BSC

Operation
Base Station Controller

3.56
1

Enabling Frequency Hopping for a BTS

Re-set the hopping attribute to true

The hopping attribute must be re-set to true for the involved BTS using the SET
BTS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS with HOPP=true

Result: Setting the Enable Hopping attribute as true for the involved BTS.
Return to calling procedure

END

258

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.57

OMN:BSC

Addition of a TRX
Introduction
The creation of the TRX defines the global parameters of the Transceiver (TRX) dedicated to both traffic and BCCH functions.
The frequency used by TRX must be one of those included in the Cell Allocation (CALL)
of the containing BTS instance. This attribute belongs to the BASIC group of the BTS
object and it can be modified by using the SET BTS command. If the frequency is not
included, it has to be added to the CALL attribute before installing the TRX. The
frequency associated to this object has to be selected according to the real values
supported by the TRX (Quartz Filters Tuning).
When creating a new TRX instance the user must specify the following mandatory
attributes:
1. TRXFREQ: it specifies the frequency of the transceiver; this parameter can assume:
the BCCHFREQ value, if the TRX is the BCCH one;
one CALLF value, among those defined by the user, when creating the superordinate BTS.
2. LPDLMN: the TRX needs a logical LAPD link instance related to it to permit the
transmission, over the PCMB line, of its radio resource management signalling; this
logical link is identified by the LPDLR object; the LPDLMN attribute indicates the
physical link over which the LPDLR, related to the transceiver, is conveyed. It is the
same physical link over which a LPDLM logical link, related to the corresponding
BTSM, is allocated. The LPDLMN number has the range 0...7; in fact for each BTSM
up to eight LPDLM object instances can be created (see "3.39 Addition of a New Site
Manager and of related LAPD links")

If CONCELL=FALSE, the TRXAREA parameter must be set to NONE.

If CONCELL=TRUE, the TRXAREA parameter must be set either to COMPLETE or
INNER.
For the BCCH transceiver the TRXAREA parameter must be set to COMPLETE.
After creating a TRX, the corresponding LPDLR is automatically created too. As it has
described, the LPDLR is associated to one LPDLM logical link (among the eight LPDLM
links that can be created for each BTSM); in this way, the LPDLR is automatically associated to one time slot of the PCMB line, i.e. the time slot over which the LPDLM is allocated during its creation. This time slot is referred as the Primary position or Default
position of the LPDLR (i.e. the position that is defined inside the database)
After creating different LPDLM links instances for the same BTSM (see "3.39 Addition
of a New Site Manager and of related LAPD links"), the situation is the following:

one LPDLM object instance is in Providing Service state;

the other LPDLM instances will be in Standby state.

When a failure occurs on one LAPD timeslot, two different actions are done by the BSC
and by the BTSE.
1. the first action is done by the BSC; the active LPDLM link will be moved on one of
the other pre-configured LAPD timeslots, and this LPDLM link will be put in the
Providing Service state;

A30808-X3247-L210-3-7619

259

OMN:BSC

Operation
Base Station Controller

2. the second action is done by the BTSE: the LPDLRs links, belonging to the
damaged LAPD timeslot, are switched on the other LAPD timeslots. The BTSE has
to do the best distribution of such LPDLR links among all of the pre-configured
LPDLM, in order to avoid signalling overload on each LAPD timeslot.
When the fault has been repaired, the logical LPDLR links will be moved back on the
position which is pre-defined in the database as the primary or the default position.
So, three fundamental goals are provided:
1. signalling LAPD link redundancy; in case of fault condition the link redundancy
assures always the presence of another LAPD timeslot (if configured) capable to
support the O&M signalling link with BTSM, and the relevant radio signalling links
with TRX;
2. signalling LAPD links recovery; the links recovery assures always the possibility to
maintain enabled and to re-establish on the initial LAPD primary position the
LPDLR links before moved on redundant LAPD position;
3.

load sharing of the signalling traffic among the different LAPD timeslots (that is the
LPDLR links of a BTSE are shared among different physical timeslots); the signalling
load sharing assures a good distribution of the call processing signalling links
among different TS LAPD.

In fact, in case of LAPD fault of one active LAPD timeslot, while for the LPDLM link some
other pre-configured LAPD timeslot can carry the active LPDLM link, for the LPDLRs all
the remaining pre-configured LAPD timeslots have to share the signalling traffic in terms
of number of TRXs.
In case of fault of one LAPD timeslot, it is acceptable to loose a portion of traffic, i.e. all
the TCHs related to the LPDLRs established over this LAPD TS. In any case, the Cell
coverage is to be guaranteed providing the LPDLR recovery for TRX containing BCCH,
CBCH and SDCCH channels; also the TCHs of these TRXs are lost. When the LPDLM
instance, on which are configured the primary positions of some LPDLRs, are in
DISABLE state, all TCHs belonging to involved TRXs are put in DISABLE state too.
The change of LPDLR primary position is not allowed by the operator SET command,
but this change is allowed only through the deletion/creation actions sequence. These
actions are useful when it is necessary to delete a LPDLM link and, consequently, to
activate another LPDLM (i.e. LPDLM link deleting, LPDLR links reconfiguration, )
Therefore, the LPDLM object instance will have got three working logical conditions:

Providing Service, this state means that the link is active and on it the BSC (and
BTSE) can transmit and receive O&M signalling informations;
StandBy, this state means that the link is working (layer 2 on) but no layer 3
messages are exchanged on it. The BTSE discards all the layer 3 messages
received on the Standby link by BSC, unless the Stop Sending Event Report (for
Full Alignment starting) or the Restart Sending Event Report (for Fast Alignment
starting) message. These two messages mean that the BSC is changing the state
of the considered LPDLM link from Standby to Providing Service.
Fault, this state means that the link is in a failure condition.

ABIS Alignment Procedure

The following Abis Alignment Procedure is implemented:

260

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

At system start-up the BTSE will be listening on all configured LAPD timeslots (i.e.
all LPDLM instances);

Please remember that, for each configured LPDLM on the BSC side, you
have to configure the corresponding LPDLE object of the connected BTSE
equipment; if you dont execute this operation, the Abis Alignment will fail.

BSC autonomously decides which is the LAPD timeslot that will be used as O&M
link, sending on that timeslot the Stop Sending Event Report or Restart Sending
Event Report (Full/Fast Alignment). This LPDLM link will be in Providing Service,
while all the others will be in Standby;

Each LAPD timeslot associated to LPDLM in Standby state, supports all the
LPDLR links, having as primary position this LPDLM.

Congestion Control
When a fault occurs on a LAPD timeslot, the switch procedure allows to move the
LPDLM and LPDLRs links on new pre-configured LAPD timeslots: new LAPD timeslots
will support the O&M signalling related to whole BTSE and all LAPD timeslots will
support the radio signalling related to all TRXs belonging to that BTSE. For this reason,
when any fault occurs, its probable that the new LAPD timeslot goes in a congestion
state, because it must support too many call processing signalling informations.
To face this more probable congestion event, the links condition will be checked by the
BTSE and by the BSC (PPLD or TDPC) using news thresholds (set via LMT). These
thresholds specify the percentage of filling of the TX buffers (both for up-link BTSE side
and for down-link BSC side), for the timeslot that requires an Overload regulation action.
So, there are two possible situations:
1. Uplink signalling overload (BTSE TX buffer congestion state);
2. Downlink signalling overload (BSC TX buffer congestion state).
In case of Uplink Signalling Overload:

if the BTSE needs to send RX_LEV and RX_QUAL measurement reports, these
reports are not to be produced anymore by the BTSE; a notification to the operator
has to be sent when the measurements reports are stopped (when the TS LAPD
fault has been repaired, to notify to the operator that the measurement reports can
be sent). To manage this first check about signalling overload a new BTSM attribute
is introduced. This attribute (FirstLapdOverloadThreshold- FLAPDOVLTH) indicates
the threshold (in percentage) for sending measurement report; it is composed by two
fields:
FirstLevelUpperThreshold (when exceeded suspend sending measurement
report messages)
FirstLevelLowerThreshold (when fall below resume sending measurement report
messages)

A30808-X3247-L210-3-7619

if the measurements stopping isnt sufficient to solve the overload situation, the
BTSE will send to BSC, on LPDLM link, an appropriate message indicating which
are the TRXs in overload condition. This message will be addressed by BTSM and
it will reach the TDPC. Only now the TDPC will be able to start the reduction actions
of signalling traffic (discarding paging messages and/or barring access classes). To
manage this second check about signalling overload another new BTSM attribute is
introduced. This attribute (SecondLapdOverloadThreshold - SLAPDOVLTH) indi-

261

OMN:BSC

Operation
Base Station Controller

cates the threshold (in percentage) for sending LAPD overload report messages. It
consists of two fields:
SecondLevelUpperThreshold (when exceeded start periodic sending LAPD overload messages);
SecondLevelLowerThreshold (when fall below stop periodic sending LAPD overload messages).
The following restrictions must be checked:

FirstLevelUpperThreshold > FirstLevelLowerThreshold

SecondLevelUpperThreshold > SecondLevelLowerThreshold
SecondLevelLowerThreshold >= FirstLevelUpperThreshold
In case of Downlink Signalling Overload, Inter-Processor Communication Task (IPC)
checks possible overload of the radio signalling; if the IPC task detects a radio signalling
overflow, it sends an overload message to Level 3 task (TL3) originating the most part
of radio signalling traffic; when TL3 receives the overload message it starts the signalling traffic reduction actions.
This downlink overload check is enabled/disabled by an operator SET BSC command
including an appropriate attribute, related to this features. This attribute is called DownlinkLapdOverload (DLAPDVOL) and it can assume only the TRUE/FALSE values.
Examples
Two examples of application for a 24 TRX BTS Site in a 3x8 configuration are shown.
In both examples, the multiple LAPD link is a double LAPD link.
In the example 1 (see Fig. 3.57.1), there are 3 cells managed by three different BTSMs
(i.e. different COBA boards); each cell has 8 TRXs; two PCMB lines are used to connect
BTSMs to the BSC (see "3.39 Addition of a New Site Manager and of related LAPD
links").
3 LPDLMs (each one for a single BTSM or COBA in a different TS) are configured on
the second PCMB line. They are considered in Providing Service state, with the possibility to reconfigure them on the other PCM line in case of PCM or LAPD failure; the
corresponding LAPD TSs carry both O&M and radio signalling.
3 LPDLMs are configured on the first PCMB line. They are considered in Standby state;
the corresponding LAPD TSs carry only radio signalling.
Thus, on the first PCM line there are:

12 carriers:
4 TRXs(0..3) of the cell 1;
4 TRXs(0..3) of the cell 2;
4 TRXs(0..3) of the cell 3;

3 X 64 LAPD timeslots:
1 TS for the cell 1 carrying LPDLRs for TRXs(0..3);
1 TS for the cell 2 carrying LPDLRs for TRXs(0..3);
1 TS for the cell 3 carrying LPDLRs for TRXs(0..3);

On the second PCM line there are:

262

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

12 carriers:
the other 4 TRXs(4..7) of the cell 1;
the other 4 TRXs(4..7) of the cell 2;
the other 4 TRXs(4..7) of the cell 3.

3 X 64 LAPD timeslots:
1 TS for the cell 1 carrying both LPDLRs for TRXs(4..7) and O&M signalling;
1 TS for the cell 2 carrying both LPDLRs for TRXs(4..7) and O&M signalling;
1 TS for the cell 3 carrying both LPDLRs for TRXs(4..7) and O&M signalling.

Fig. 3.57.1 Example 1

In the example 2 (see Fig. 3.57.2), there are 3 cells managed by one single BTSM (i.e.
one single COBA board); each cell has 8 TRXs; two PCMB lines are used to connect
the BTSM to the BSC.
1 LPDLM (for the O&M of the extended BTSE site) is configured on the second PCM
line. It is considered in Providing Service state, with the possibility to reconfigure it on
the other PCM line in case of PCM or LAPD failure; the corresponding LAPD TS carries
both O&M and radio signalling.

A30808-X3247-L210-3-7619

263

OMN:BSC

Operation
Base Station Controller

1 LPDLM is configured on the first PCMB line. It is considered in Standby state; the
corresponding LAPD TS carries only radio signalling.
Thus, on the first PCM line there are:

12 carriers:
4 TRXs(0..3) of the cell 1;
4 TRXs(0..3) of the cell 2;
4 TRXs(0..3) of the cell 3;

1 X 64 LAPD timeslot for the three cells carrying LPDLRs for TRXs(0..3).

On the second PCM line there are:

12 carriers:
the other 4 TRXs(4..7) of the cell 1;
the other 4 TRXs(4..7) of the cell 2;
the other 4 TRXs(4..7) of the cell 3.

1 X 64 LAPD timeslot for the three cells carrying both LPDLRs for TRXs(4..7) and
O&M signalling.

Fig. 3.57.2 Example 2

264

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The user is able to see detailed information about the LPDLR configuration, by using the
following command:

GETINFO LPDLR

In this way the user has a complete overview about the allocation of the signalling
related to a Transceiver.

Prerequisites
To create a new TRX, the superordinate BTS must exist. Instead, the instance of the
TRX managed object must not be already equipped.
The carrier frequency (ARFCN) of the TRX has to be contained in the Cell Allocation
(CALL) (in case of BCCH TRX the frequency is specified in the BCCHFREQ attribute)
of the BTS object instance. This value must not be already assigned to another TRX
belonging to the same BTS.
After the creation of the TRX, the administrative state of this object is set to LOCK. An
UNLOCK command is required to put this object in service.
The relevant BTSE-HW is plugged into the appropriate slot and the wiring/wiring data in
the BTSE are set according to the desired BTSE configuration.
The user must have the visibility level number set to "2".

Preliminary Consideration
Do you want to create a TRX?
Do you want to see informations about LPDLR configuration?

h ... 2
h ... 4

Create a TRX

To create a TRX, the user must enter the CREATE TRX command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CREATE TRX

Result: the TRX is created in locked state.

Put the TRX in service

To put the TRX in service, the user must unlock the object by entering the
UNLOCK TRX command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> UNLOCK TRX

Result: the TRX is put in Unlocked state; the related LPDLR instance is created
too.

A30808-X3247-L210-3-7619

h ... END

265

OMN:BSC

Operation
Base Station Controller

Get LPDLR configuration

To see LPDLR configuration, the user must enter the GETINFO LPDLR
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> LPDLR ---> GETINFO LPDLR

Result: the configuration about LPDLRs is shown.

END

266

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.58

OMN:BSC

Enabling/Disabling GPRS Service

Introduction
As it has been described in "3.47 Addition of a Point-to-Point Packet Function
(GPRS/EGPRS)", when a PTPPKF object instance is created, the EGPRS parameter,
that allows to make available or not available the whole Packet Data service in a cell
(both GPRS and EGPRS), is set to FALSE as a default value.
Before setting the EGPRS parameter to true, the user must enable the GPRS service
on a TRX basis, i.e. the user must enable at least one TRX to support packet data
services. This procedure allows the user to enable the service on chosen TRXs among
those configured for the cell, and so allows him to effectively enable the GPRS on a cell.

The GPRS service will not be enabled in a cell, it the user does not enable it on at least
one TRX of the cell, after having created the PTPPKF object.
To enable, in general, packet data services (i.e. both GPRS and EGPRS) on a specific
TRX, the user must set to true the GSUP attribute belonging to the TRX object.
Setting GSUP = TRUE means that the TRX is enabled to support in general both packet
data services, i.e. it is enabled to support both GPRS and EGPRS.
In fact BTSplus equipments (see "3.59 Enabling/Disabling EGPRS service" for more
details) can be equipped with two different types of carrier units:
1. GSM-CUs, i.e. carrier units able to support GSM and GPRS services;
2. E-CUs (EDGE carrier units), i.e. carrier units able to support GSM, GPRS and
EGPRS services.
So, the user, beside enabling the TRX to support packet data services (with GSUP
parameter), can indicate if the TRX will be used for GSM/GPRS only, or if it will be used
for EGPRS too. To indicate how the TRX has to be exploited, the TRXMD parameter is
used; it can assume two values:

i
i

GSM: it is the default value that means that the TRX can be used for GSM, and also
for GPRS if GSUP=TRUE;
EDGE: it means that the TRX can be used for GSM, and also for both GPRS and
EGPRS if GSUP=TRUE.

Regarding the detailed procedure to enable EGPRS, please refer to

"3.59 Enabling/Disabling EGPRS service".
From the BTS equipment point of view, the TRXMD parameter is the criterion used to
allocate a carrier unit type (GSM-CU or E-CU) to the transceiver. The association
between a TRX and the boards (CU or E-CU) of a BTSplus is performed automatically
by the BTS equipment, taking into account suggestion from operator (i.e. the TRXMD
setting). To get more details about aspects of carrier configuration, refer to
"3.59 Enabling/Disabling EGPRS service".
After having enabled one or more TRXs to support GPRS, i.e. after having set for one
or more TRXs:

GSUP=TRUE
TRXMD=GSM

the user must set to TRUE the EGPRS parameter of the PTPPKF object, to definitely
enable the GPRS service in the cell.

A30808-X3247-L210-3-7619

267

OMN:BSC

Operation
Base Station Controller

It is possible to set GSUP=TRUE for whatever TRX of the cell, with the following exceptions:

in case of Concentric Cells, the TRX supporting packet switched data services must
always belong to the complete cell area;
in case GSMDCS (common BCCH) cells all the TRX that support packet switched
data services must belong to the same band of the BCCH TRX (and this coincides
with Complete Area). This is due to the fact that the two GSM and DCS bands have
different propagation factors, thus it could be that on cell borders only the frequency
of one band is received; one mobile that accessed the cell with one band could not
work with the other one;
in case of cells having SYSID=EXT900 only the TRX with TRXFREQ belonging to
BB900 band (that is, the same band of BCCH) can have GSUP = TRUE;
it is possible to set as first GPRS TRX whatever TRX of the cell, that is, it is not
mandatory to set this attribute to TRUE first on the BCCH TRX;
the setting of a TRX to GSUP = TRUE has to take into account the Multislot
constraints for TSC and Frequency Hopping parameters.
the setting of a TRX to GSUP=TRUE must be executed only when all the TRXs
channels are not available to the service (this situation can be reached by executing
a shutdown for all these TCH: this is suggested to avoid impacts on CS calls.

Beside the TRXs of a cell on which the user wants to configure packet switched data
services, it is suggested to configure GSUP=TRUE also for the BCCH TRX. In this way
the condition of no TRXs with GSUP=TRUE (condition that puts the PTPPKF object in
DISABLE state) happens when there is also a BCCH outage; in this case the whole BTS
from both circuit switched and packet switched services is put Out of Service.
If the BCCH TRX is enabled to support packet switched data services, the user can
configure on it, some static channels to be used for signalling, on a channel basis (i.e.
the user can reserve some signalling slots to packet switched data services only). This
can be achieved by setting the GDCH attribute of the CHAN object.
The GDCH attribute can assume the following values:

PBCCH: i.e. the related channel is reserved for packet switched data services and
it will support broadcast signalling (it will support also EGPRS signalling if the TRX
is enabled to support EDGE, see "3.59 Enabling/Disabling EGPRS service");
PCCCH: i.e. the related channel is reserved for packet switched data services and
it will support GPRS common signalling (it will support also EGPRS signalling if the
TRX is enabled to support EDGE, see "3.59 Enabling/Disabling EGPRS service").

To understand how GPRS service can be configured on a cell basis, please refer to
"3.47 Addition of a Point-to-Point Packet Function (GPRS/EGPRS)".

To see

To disable the packet data services on a specific TRXs, the user must set to false the
GSUP attribute belonging to the TRX object:

268

the setting of GSUP = FALSE for the BCCH TRX must be executed only when all
dedicated channels (PBCCH and PCCCH see "3.64 Addition of a Radio Channel")
have been removed from that TRX.
the setting of a TRX to GSUP= FALSE must be executed only when all the TRXs
channels are not available to the service (this situation can be reached by executing
a shutdown for all these TCH: this is suggested to avoid impacts on CS calls).

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Prerequisites
The user must have the visibility level number set to "2".
The BTS object instance, and the subordinate TRXs have been already created.

Preliminary Consideration
Do you want to enable a cell to support GPRS, enabling for the first time one
of its TRXs to support packet data services?

h ... 2

Do you want to enable a TRX to support GPRS, when in the cell other TRXs
are already supporting packet data services?

h ... 11

Do you want to disable a cell to support GPRS, disabling the last TRX
supporting it?

h ... 16

Do you want to disable a TRX to support GPRS, but leaving other TRXs
supporting it?

h ... 24

Precondition
Have you already created the PTPPKF object for the cell?

Y h ... 3
N i ..."3.47 Addition
of a Point-toPoint Packet
Function
(GPRS/EGPRS
)"

Note: when the PTPPKF object instance is created, the EGPRS attribute, which
enables packet data services in a cell, is set to FALSE as a default value

Shutdown all the channels of the TRX you want to enable

For each channel of the TRX, enter the SHUTDOWN CHAN command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SHUTDOWN CHAN.

Result: the channels are put in locked state.

A30808-X3247-L210-3-7619

269

OMN:BSC

Operation
Base Station Controller

Enable packet data services on the TRX

To enable packet data services, enter the SET TRX command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX
Then set the following value:
GSUP = TRUE

Note1: it is supposed that the TRXMD parameter of the TRX is already set to
GSM, since it is its default value.

Precondition

Y h ... 6
N h ... 7

Do you want to configure any static GPRS channel?

Create signalling static channels (only on the BCCH TRX)

For each static signalling channel you want to configure on the TRX, enter the
SET CHAN command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SET CHAN
Then set the GDCH attribute.

Result: the static signalling channels are created.

Unlock all the channels of the TRX

For each channel of the TRX, enter the UNLOCK CHAN command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> UNLOCK CHAN

b
Result: the channels are put in unlocked state.

270

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Lock the PTPPKF which the TRX belongs to

To lock the PTPPKF, enter the LOCK PTPPKF command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> LOCK PTPPKF

Result: the PTPPKF object instance is locked.

Enable packet data services on the cell

To enable packet data services on the cell, enter the SET PTPPKF command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF
Then set the following attribute value:
EGPRS=TRUE

10

Unlock the PTPPKF

To unlock the PTPPKF, enter the UNLOCK PTPPKF command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> UNLOCK PTPPKF

Result: the PTPPKF object instance is unlocked and the GPRS service is now
available in the cell and on the chosen TRX.

11

h ... END

Shutdown all the channels of the TRX you want to enable

For each channel of the TRX, enter the SHUTDOWN CHAN command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SHUTDOWN CHAN.

Result: the channels are put in locked state.

A30808-X3247-L210-3-7619

271

OMN:BSC

12

Operation
Base Station Controller

Enable packet data services on the TRX

To enable packet data services, enter the SET TRX command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX
Then set the following value:
GSUP = TRUE

Note: it is supposed that the TRXMD parameter of the TRX is already set to
GSM, since it is its default value.

13

Precondition

Y h ... 14
N h ... 15

Do you want to configure any static GPRS channel?

14

Create signalling static channels (only on the BCCH TRX)

For each static signalling channel you want to configure on the TRX, enter the
SET CHAN command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SET CHAN
Then set the GDCH attribute.

Result: the static signalling channels are created.

15

Unlock all the channels of the TRX

For each channel of the TRX, enter the UNLOCK CHAN command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> UNLOCK CHAN.

Result: the channels are put in unlocked state.

272

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

16

OMN:BSC

Shutdown all the channels of the TRX

For each channel of the TRX, enter the SHUTDOWN CHAN command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SHUTDOWN CHAN.

Result: the channels are put in locked state.

17

Precondition
Is any static GPRS channel configured on the involved TRX (only for BCCH
TRX)?

18

Y h ... 18
N h ... 19

Remove the signalling static channels

For each static signalling channel of the TRX, enter the SET CHAN command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SET CHAN
Then set GDCH= NULL

Result: the static channels are deleted.

19

Lock the PTPPKF which the TRX belong to

To lock the PTPPKF, enter the LOCK PTPPKF command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> LOCK PTPPKF

Result: the PTPPKF object instance is locked.

A30808-X3247-L210-3-7619

273

OMN:BSC

20

Operation
Base Station Controller

Disable packet data services on the cell

To disable packet data services on the cell, enter the SET PTPPKF command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF
Then set the following attribute value:
EGPRS =FALSE
NOTE: it has been assumed that the EEDGE parameter, that enables EDGE
sevices in the cell, was set to FALSE (see "3.59 Enabling/Disabling EGPRS
service"). Otherwise before disabling packet data services in the cell (by setting
EGPRS=FALSE), it is necessary to disable EDGE service first (by setting
EEDGE=FALSE).

21

Unlock the PTPPKF

To unlock the PTPPKF, enter the UNLOCK PTPPKF command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> UNLOCK PTPPKF

Result: the PTPPKF object instance is unlocked and packet data services are
no more available in the cell.

22

Disable packet data services on the last TRX

To disable packet data services, enter the SET TRX command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX
Then set GSUP = FALSE
NOTE: it has been assumed that the TRXMD parameter, that enables EDGE
sevices in the TRX, was set to FALSE (see "3.59 Enabling/Disabling EGPRS
service"). Otherwise before disabling packet data services in the TRX (by
setting GSUP=FALSE), it is necessary to disable EDGE service first (by setting
TRXMD=GSM).

274

A30808-X3247-L210-3-7619

Operation
Base Station Controller

23

OMN:BSC

Unlock all the channels of the TRX

For each channel of the TRX, enter the UNLOCK CHAN command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> UNLOCK CHAN.

Result: the channels are put in unlocked state and packet data services are no
more available on the chosen TRX and on the cell too.

24

h ... END

Shutdown all the channels of the TRX

For each channel of the TRX, enter the SHUTDOWN CHAN command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SHUTDOWN CHAN.

Result: the channels are put in locked state.

25

Precondition
Is any static signalling channel configured on the involved TRX (only for BCCH
TRX)?

26

Y h ... 26
N h ... 27

Remove the signalling static channels

For each static signalling channel of the TRX, enter the SET CHAN command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SET CHAN
Then set GDCH= NULL

Result: the static channels are deleted.

A30808-X3247-L210-3-7619

275

OMN:BSC

27

Operation
Base Station Controller

Disable packet data services on the TRX

To disable packet data services, enter the SET TRX command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX
Then set GSUP = FALSE
NOTE: it has been assumed that the TRXMD parameter, that enables EDGE
sevices in the TRX, was set to FALSE (see "3.59 Enabling/Disabling EGPRS
service"). Otherwise before disabling packet data services in the TRX (by
setting GSUP=FALSE), it is necessary to disable EDGE service first (by setting
TRXMD=GSM).

28

Unlock all the channels of the TRX

For each channel of the TRX, enter the UNLOCK CHAN command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> UNLOCK CHAN.

Result: the channels are put in unlocked state and packet data services are no
more available on the chosen TRX.

END

276

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.59

OMN:BSC

Enabling/Disabling EGPRS service

Introduction
As it has been described in "3.58 Enabling/Disabling GPRS Service", to enable packet
switched data services (both GPRS and EGPRS services)on cell and TRX basis the
user must set:

the GSUP parameter of the TRX object to TRUE (for each TRX he wants to enable
to support packet data services);
the EGPRS parameter of the PTPPKF obiect to TRUE;

After that if the user wants to enable EGPRS service in one or more cells of the BSC,
he must execute a series of operations to enable it.
EDGE introduces the 8-PSK modulation in the existing GSM network to increase data
rate for (multimedia) data services up to 384kbps, and it will coexist with the existing
GMSK modulation. EDGE support is limited to the BTSplus platform. Both picoBTS and
Emicro BTS and all the equipment of the BTS1 family do not support EDGE service.
To introduce EDGE into the network, existing BTSplus sites must be equipped with
EDGE capable carrier units (E-CU) featuring the new 8-PSK modulation technique. The
E-CU hardware is able to handle:

GSM and GPRS services;

Enhanced GPRS service (EGPRS).

To implement EGPRS service, some GSM-CUs can be replaced by E-CUs at any arbitrary CU rack position; mixed configurations with CUs and E-CUs as well as configurations with E-CUs only are possible, but, as it has been said, the upgrade is only
supported for BTSE types belonging to the BTSplus generation.
From the BSC point of view, only High capacity BSCs can support EGPRS. The ESUP
parameter of the BSC object allows to enable EGPRS services in the BSC. If the user
does not set to TRUE the ESUP parameter, EGPRS services will not be allowed in the
BSC. Since EGPRS can only be enabled on high capacity BSCs, the ESUP parameter
can not be set to true if the NTWTYPE parameter (BSC object) is not set to either SNAP
or SNAP_STLP.
When the user has to enable the EGPRS service on BSC basis, he has to enable it both
on TRX basis and on cell basis.
As it has be described in "3.58 Enabling/Disabling GPRS Service", to enable, in general,
packet data services on a specific TRX, the user must set to true the GSUP attribute
belonging to the TRX object.
Setting GSUP = TRUE means that the TRX is enabled to support in general both packet
data services, i.e. it is enabled to support both GPRS and EGPRS services .
To activate EGPRS service on a specific TRX, beside enabling the TRX to support
packet data services (with GSUP parameter), the user has to indicate that the TRX will
be used for EGPRS too. To indicate how the TRX has to be exploited, the TRXMD
parameter is used; it can assume two values:

A30808-X3247-L210-3-7619

GSM: it is the default value that means that the TRX can be used for GSM and also
for GPRS (if GSUP=TRUE);
EDGE: it means that the TRX can be used for GSM and also for both GPRS and
EGPRS (if GSUP=TRUE).

277

OMN:BSC

Operation
Base Station Controller

So the user to enable EGPRS service on a TRX must set the TRXMD parameter to
EDGE value.
After having enabled EGPRS on a TRX basis, i.e. after having enabled at least one
TRX to support EGPRS, the user can enable EGPRS on a cell basis by setting to TRUE
the EEDGE parameter (see "3.47 Addition of a Point-to-Point Packet Function
(GPRS/EGPRS)")

ASPECTS RELATED TO CARRIER CONFIGURATION

As described before, by means of the GSUP and TRXMD attributes, it is possible to
specify whether a TRX supports:

GSM services;
GPRS and/or EGPRS services

On the other hand, the capability of a Carrier Unit is modelled with a read only attribute
called TRX CAPABILTY. It reflects the real capabilities of the TRX independently of the
TRXMD parameter setting. The attribute is available for the operator by GETINFO TRX
and GETINFO BTS commands, and it can assume the following values:

GSM: the TRX is associated to a carrier Unit without EDGE capability;

EDGE: the TRX is associated to a carrier Unit with EDGE capability;
UNKNOWN: the BSC has no knowledge about the carrier Unit associated to TRX.

The following combinations of TRXMD and TRX CAPABILITY are possible

(see Tab. 3.59.1):
TRXMD

TRX CAPABILTITY

Meaning

GSM

GSM

The TRX is working with GSM functionality

GSM

EDGE

The TRX is working with GSM functionality

GSM

UNKNOWN

No CU is related

EDGE

GSM

The TRX is working with GSM functionality

since no E-CU is available

EDGE

EDGE

The TRX is working with EDGE functionality

EDGE

UNKNOWN

No CU is related

Tab. 3.59.1 Combinations of TRXMD and TRX CAPABILITY Values

The BTSE shall try to find an optimal allocation between the required TRX operation
modes and the available carrier unit types according to the following rules:
1. Try to allocate the BCCH TRX to the appropriate CU type;
2. Try to allocate all EDGE-TRX to E-CUs
3. Try to allocate all GSM-TRX to GSM-CUs
4. Try to allocate all remaining GSM-TRX to E-CUs
5. Try to allocate all remaining EDGE-TRX to GSM-CUs (the state of the TRX changes
to enabled-degraded).

278

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

When transceivers are reconfigurated the BTSE checks if the allocation among TRXs
and CUs is still optimal. If necessary an automatic reconfiguration according to the rules
shown above is performed.
A change of the functional configuration may be caused by:

creation/deletion of a TRX;
modification of the TRXMD attribute of a TRX;
breakdown of CU allocated to BCCH-TRX;
breakdown of CU allocated to complete area TRX in case of concentric cells;
commissioning of TRX after breakdown.

Please note that some changes of configuration may lead to a loss of traffic for one or
two TRX. It is an operators task to avoid the loss of traffic by taking the right measures.
Therefore the appropriate configuration procedures have to be followed.
In case of Baseband frequency hopping all TRXs involved in the same hopping law must
be homogeneus, i.e. they must have the same TRXMD value. If a TRX with TRXMD =
EDGE gets TRX_CAPABLITY = GSM (e.g. due to a reconfiguration) the hopping for the
TRX related to this hopping law is stopped in the cell, and the operator is informed.
Synthesizer frequency hopping is not affected.
Prerequisites
The user must have the visibility level number set to "2".
The BTS object instance, and the subordinate TRXs have been already created.
Packet data services have been already enabled in the cell (as described in
"3.58 Enabling/Disabling GPRS Service") with the following settings:

GSUP = TRUE for some TRXs of the cell

TRXMD = GSM for all the TRXs
the PTPPKF object has been created and EGPRS = TRUE

Preliminary Consideration
Do you want to enable a cell to support EGPRS, enabling for the first time
one of its TRXs to support EGPRS?

h ... 2

Do you want to enable a TRX to support EGPRS, shifting a TRX from GPRS
to EGPRS?

h ... 14

Do you want to disable a cell to support EGPRS, disabling the last TRX
supporting it, but leaving other TRXs supporting packet data services?

h ... 19

Do you want to disable a TRX to support EGPRS, but leaving other TRXs
supporting it?

h ... 26

A30808-X3247-L210-3-7619

279

OMN:BSC

Operation
Base Station Controller

Considerations

The following figure shows the starting configuration.

TRX 1
TRXMD=GSM

E-CU

TRX 2
TRXMD=GSM

GSM-CU

Now we want to add a new GSM-CU (see below) and to create the first EDGE
TRX (i.e. the TRX 3)

TRX 1
TRXMD=GSM

E-CU

TRX 2
TRXMD=GSM

GSM-CU

GSM-CU

Since the new GSM-CU can not support EDGE, an automatic reconfiguration is
executed (see figure below).

TRX 1
TRXMD=GSM

GSM-CU

TRX 2
TRXMD=GSM

GSM-CU

TRX 3
TRXMD=EDGE

E-CU

Reconfiguration

280

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Enable EGPRS service on the BSC

To enable EGPRS service on the BSC, enter the SET BSC command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then set the following value:
ESUP = TRUE

Note: remember that only high capacity BSCs can support EGPRS service.

Shutdown TRX:1

Enter the SHUTDOWN TRX command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

SHUTDOWN TRX
Then set the following value:
NAME = BTSM:X/BTS:Y/TRX:1

Result: channels on TRX:1 will be released and TRX:1 will be locked.

Create TRX:3 and enable both GPRS and EGPRS

To get information about TRX creation, refer to the specific procedure.

During creation set the following attribute values:

i ..."3.57 Addition
of a TRX"

GSUP = TRUE to enable packet data services on the TRX

TRXMD = EDGE to enable the EGPRS service
Result: TRX:3 is created and the automatic reconfiguration of TRX1 occur,
shifting it to the new GSM-CU, whereas TRX3 is associated to the EDGE-CU.

Unlock TRX:1

Enter the UNLOCK TRX command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

UNLOCK TRX
Then set the following value:
NAME = BTSM:X/BTS:Y/TRX:1

Result: TRX:1 is unlocked.

A30808-X3247-L210-3-7619

281

OMN:BSC

Operation
Base Station Controller

Lock the PTPPKF which the TRX belongs to

To lock the PTPPKF, enter the LOCK PTPPKF command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> LOCK PTPPKF

Result: the PTPPKF object instance is locked.

Consideration
Do you want to enable a cell to support EGPRS with CS-3 /CS-4 enabled

h ... 9

Do you want to enable a cell to support EGPRS without CS-3 /CS-4

enabled?

h ... 10

Enable the EGPRS service on the cell with CS-3/CS-4 enabled

To enable the EGPRS service on the cell with CS-3/CS-4 enabled ,enter the
SET BSC and SET PTPPKF commands, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then set the following value:
CSCH3CSCH4SUP = TRUE

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF
Then set the following attributes value:
CSCH3CSCH4SUP = TRUE
EEDGE=TRUE

Result: the EGPRS service is now available on the cell with CS-3/CS-4 enabled.

282

h ... 13

A30808-X3247-L210-3-7619

Operation
Base Station Controller

10

OMN:BSC

Enable the EGPRS service on the cell w/o CS-3/CS-4 enabled

To enable the EGPRS service on the cell without enabling CS-3/CS-4 ,enter the
SET BSC and the SET PTPPKF commands, following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then set the following value:
MNTBMASK(bit25) = TRUE
CSCH3CSCH4SUP = TRUE

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF
Then set the following attributes value:
CSCH3CSCH4SUP = TRUE
EEDGE=TRUE

Result: Enabling of EGPRS service on the cell without CS-3 /CS-4 enabled (the
max coding scheme usable is forced to CS-2 independently from
CSCH3CSCH4SUP value set to TRUE).

11

Lock the PCU involved

The PCU involved is locked by entering the LOCK PCU command for each PCU
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCU ---> LOCK PCU

Result: Lock the PCU involved.

12

Unlock the PCU involved

To disable the CS-3/CS-4 on the cell with EGPRS service enabled, the user
must unlock the PCU involved, by entering the UNLOCK PCU command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> PCU --->

UNLOCK PCU

Result: The PCU involved is unlocked and the CS-3/CS-4 are disabled on the
cell with EGPRS enabled

A30808-X3247-L210-3-7619

283

OMN:BSC

13

Operation
Base Station Controller

Unlock the PTPPKF

To unlock the PTPPKF, enter the UNLOCK PTPPKF command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> UNLOCK PTPPKF

Result: the PTPPKF object instance is unlocked and the EGPRS service is now
available in the cell and on the chosen TRX.

14

h ... END

Considerations

The following figure shows the starting configuration. Now we want to enable
one TRX to support EGPRS.

TRX 1
TRXMD=GSM

TRX 2
TRXMD=GSM

GSM-CU

E-CU

TRX 3
TRXMD=EDGE

E-CU

Note: in this case the best solution is to enable TRX2 to support EGPRS; in fact
it is already associated to an EDGE-CU, and no reconfiguration is necessary. If
TRX1 was enabled to support EDGE, then a reconfiguration would occur
between TRX1 and TRX2.

15

Shutdown all the channels of TRX:2

For each channel of the TRX, enter the SHUTDOWN CHAN command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SHUTDOWN CHAN.

Result: the channels are put in locked state.

284

A30808-X3247-L210-3-7619

Operation
Base Station Controller

16

OMN:BSC

If TRX:2 belongs to an hopping law, remove it from the law

To get information about TRX deletion from an hopping low refer to the specific
procedure.

i ..."3.44 Deletion
of a Frequency
from FHSY"

Result: the TRX is removed from the hopping law

17

Enable EGPRS on TRX:2

To enable EDGE, enter the SET TRX command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX
Then set the following value:
TRXMD = EDGE

Note: EGPRS is enabled on TRX:.

18

Unlock all the channels of the TRX

For each channel of the TRX, enter the UNLOCK CHAN command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> UNLOCK CHAN.

Result: the channels are put in unlocked state and the TRX is now available to
support EGPRS.

19

h ... END

Shutdown all the channels of the TRX

For each channel of the TRX, enter the SHUTDOWN CHAN command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SHUTDOWN CHAN.

Result: the channels are put in locked state.

A30808-X3247-L210-3-7619

285

OMN:BSC

20

Operation
Base Station Controller

Lock the PTPPKF which the TRX belongs to

To lock the PTPPKF, enter the LOCK PTPPKF command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> LOCK PTPPKF

Result: the PTPPKF object instance is locked.

21

Disable EGPRS on the cell

To disable EGPRS on the cell, enter the SET PTPPKF command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF
Then set the following attribute value:
EEDGE = FALSE
NOTE: it is assumed that the user wants to disable EGPRS service leaving
enabled GPRS services on the cell. To disable also GPRS services, refer to
"3.58 Enabling/Disabling GPRS Service".

22

Unlock the PTPPKF

To unlock the PTPPKF, enter the UNLOCK PTPPKF command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> UNLOCK PTPPKF

Result: the PTPPKF object instance is unlocked and EGPRS service is no more
available in the cell.

23

If the TRX belongs to an hopping law, remove it from the law

To get information about TRX deletion from an hopping low refer to the specific
procedure.

i...."3.44 Deletion
of a Frequency
from FHSY"

Result: the TRX is removed from the hopping law

286

A30808-X3247-L210-3-7619

Operation
Base Station Controller

24

OMN:BSC

Disable EGPRS on the last TRX supporting it

To disable EDGE, enter the SET TRX command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX
Then set TRXMD = GSM
NOTE: it has been assumed that the TRX where EGPRS has to be deleted is
not the BCCH one. Otherwise before disabling EDGE in the TRX (by setting
TRXMD=GSM), it is necessary to set the EBCCHTRX parameter of the
PTPPKF object to FALSE, if it was set to TRUE (see "3.47 Addition of a Pointto-Point Packet Function (GPRS/EGPRS)").

25

Unlock all the channels of the TRX

For each channel of the TRX, enter the UNLOCK CHAN command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> UNLOCK CHAN.

Result: the channels are put in unlocked state and the EDGE service is no more
available on the chosen TRX and on the cell too.

26

h ... END

Shutdown all the channels of the TRX

For each channel of the TRX, enter the SHUTDOWN CHAN command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SHUTDOWN CHAN.

Result: the channels are put in locked state.

27

If the TRX belongs to an hopping law, remove it from the law

To get information about TRX deletion from an hopping low refer to the specific
procedure.

i ..."3.44 Deletion
of a Frequency
from FHSY"

Result: the TRX is removed from the hopping law

A30808-X3247-L210-3-7619

287

OMN:BSC

28

Operation
Base Station Controller

Disable EGPRS service on the TRX

To disable EDGE, enter the SET TRX command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX
Then set TRXMD = GSM
NOTE: it has been assumed that the TRX where EGPRS has to be deleted is
not the BCCH one.Otherwise before disabling EGPRS in the TRX (by setting
TRXMD=GSM), it is necessary to set the EBCCHTRX parameter of the
PTPPKF object to FALSE, if it was set to TRUE (see "3.47 Addition of a Pointto-Point Packet Function (GPRS/EGPRS)").

29

Unlock all the channels of the TRX

For each channel of the TRX, enter the UNLOCK CHAN command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> UNLOCK CHAN.

Result: the channels are put in unlocked state and packet data services are no
more available on the chosen TRX.

END

288

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.60

OMN:BSC

Enabling/Disabling GPRS CS3-CS4 Coding Schemes

Introduction
With the introduction of GPRS in the SBS, it was required to introduce new coding
schemes.
In the first implementation of GPRS, CS-1 and CS-2 coding schemes have been introduced. Standard PCU frames were designed to carry the necessary signalling and data
information between the BSC and the BTS, and the GPRS capacity on the Abis was
limited to 16 kbps.
To support CS-3 and CS-4 coding schemes, concatenated PCU frames are introduced
in the sytsem, and the Abis throughput per radio channel is increased to n X 16 kbit/sec,
using the flexible Abis allocation strategy.

To get more information About concatenated PCU frames and the flexible Abis allocation strategy refer to "3.40 Configuration of the Abis Interface".
With CS-2 coding scheme it is possible to reach a maximum throughput for radio
channel of 13.4 kbit/sec. With CS-3 coding scheme up to 15,6 kbit/s can be reached,
whereas with CS-4 a throughput of 21,3 kbit/s is attainable with good radio conditions.
As default, CS-1 and CS-2 coding schemes are enabled in the BSS.
The BSC capability to support CS-3/CS-4 coding schemes shall be enabled/disabled by
the operator. The CSCH3CSCH4SUP parameter of the BSC object allow the user to
enable/disable CS-3/CS-4 coding schemes at BSC level.
Then the operator can enable/disable the support of CS-3 /CS-4 on cell basis, by the
CSCH3CSCH4SUP parameter of the PTPPKF object.

When enabling CS-3 /CS-4 coding schemes, make sure that the bit25 of MNTBMASK
parameter is set to FALSE, otherwise (bit25 of MNTBMASK=TRUE) the max coding
scheme usable is forced to CS-2 independently from CSCH3CSCH4SUP value set to
TRUE.
Besides, the user can also indicate, on a cell basis, which coding scheme has to be used
for data transmission when a TBF is established (signalling uses always CS-1). The
user can set the initial coding scheme using the INICSCH parameter (PTPPKF object).
Then the link adaptation, if enabled, can change the coding scheme of the TBF
according to radio conditions. If link adaptation is not enabled, the initial coding scheme
will be the only one used for data transmission in the cell.
In order to support GPRS TBFs with CS-3 or CS-4 coding schemes, hardware/software
requirements are the following:

only High Capacity BSCs support CS-3/CS-4 coding schemes (NTWCARD parameter set either to NTWSNAP or to NTWSNAP_STLP, see Supported BSC Types);

BTS+, e-microBTS, picoBTS, support GPRS CS-3/CS-4 coding schemes (also if a

mixed configuration of GPRS-CCU and EDGE-CCU boards is present);

BTS1 can not support GPRS CS-3/CS-4 coding schemes, if at least a board is an
old BBSIG one. There exists a flag in the BSC software which allows the BSC to
distinguish between a BTS1 which contains only BBSIG44 boards and a BTS1

A30808-X3247-L210-3-7619

289

OMN:BSC

Operation
Base Station Controller

which contains a mixture of BBSIG and BBSIG44 boards . This flag is called
PUREBBSIG44CONF (BTS object) and the setting is as follow:
BTS1 with mixed BBSIG-BBSIG44 boards: PUREBBSIG44CONF set to FALSE;
BTS1 with only BBSIG44 boards: PUREBBSIG44CONF set to TRUE.

It has to be remarked that it is up to operator to ensure the consistency between sofware

configuration and BTS hardware.
So, regarding the Abis interface, the information is sent using two kinds of PCU frames:
a) concatenated PCU frames, shall be used when support of CS-3/CS-4 is enabled
both at BSC and at BTS level;
b) Standard PCU frames shall be used when support of CS-3/CS-4 is disabled at BSC
or at BTS level.

Make reference to Configuration of the Abis Interface to get information about the
multiplexing of users, requiring different Abis capacity, on the same radio timeslot, and
about multiplexing of GPRS and EGPRS on the same radio timeslot.
Note that the PCU frame format (concatenated or standard) is chosen at the Initial
Time Alignment phase, and cannot be changed dynamically during data transfer.
Therefore, in order to be able to reach the higher coding schemes (CS-3/CS-4), when
CS-3/CS-4 are supported by O&M configuration, the selected PCU frame format shall
be Concatenated, even if the initial coding scheme could be supported by standard
PCU frames.
Prerequisites
The user must have the visibility level number set to "2".
The BSC must be an High Capacity one.

Situation
Would you like to enable CS-3/CS-4 coding schemes in the BSC and in its
GPRS cells?
Would you like to disable CS-3/CS-4 coding schemes for a BSC?

h ... 2
h ... 11

Enable CS-3/CS-4 coding schemes at BSC level

To enable CS-3/CS-4 coding schemes at BSC level, enter the SET BSC
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

then set the following attribute value:
CSCH3CSCH4SUP = TRUE

Result: CS-3/CS-4 coding schemes are enabled at BSC level.

290

A30808-X3247-L210-3-7619

Operation
Base Station Controller

Check the type of the subordinate BTS equiment

Does the BTS equipment belong to BTS1 family?
Does the BTS equipment belong to BTSplus, picoBTS, EmicroBTS families?

h ... 3
h ... 7

Precondition
Is the BTS equipment equipped with BBSIG44 boards only?

OMN:BSC

Y h ... 5
N h ... 6

Impossible to continue

The BTS equipment can not support CS-3/CS-4 coding schemes.

Result: CS-3/CS-4 coding schemes can not be enabled for this BTS.

h ... END

Predispose a cell of this BTS equipment to support CS-3/CS-4 coding

schemes (e.g. BTSM:0/BTS:5)

Enter the SET BTS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS
then set the following attribute value:
NAME = BTSM:0/BTS:5
PUREBBSIG44CONF = TRUE

Result: CS-3/CS-4 coding schemes can be enabled at cell level now.

Lock the GPRS cell

Enter the LOCK PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> LOCK PTPPKF
then set the following attribute value:
NAME = BTSM:0/BTS:5/PTPPKF:0

Result: the GPRS cell is locked.

A30808-X3247-L210-3-7619

291

OMN:BSC

Operation
Base Station Controller

Enable CS-3/CS-4 coding schemes at cell level

Enter the SET PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF
then set the following attribute value:
NAME = BTSM:0/BTS:5/PTPPKF:0
CSCH3CSCH4SUP = TRUE
INICSCH = one of the admitted values among: CS1, CS2, CS3, CS4.

Result: CS-3/CS-4 coding schemes are enabled at cell level.

Unlock the GPRS cell

Enter the UNLOCK PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> UNLOCK PTPPKF
then set the following attribute value:
NAME = BTSM:0/BTS:5/PTPPKF:0

Result: the GPRS cell is unlocked.

10

Consideration

Repeat steps from 3 to 9 for each GPRS cell where you want to enable CS-3
and CS-4 coding schemes.

h ... END
11

Disable CS-3 and CS-4 coding schemes for all GPRS cells of the BSC

Repeat steps from 12 to 17 for each GPRS cell of the BSC.

292

A30808-X3247-L210-3-7619

Operation
Base Station Controller

12

OMN:BSC

Lock the GPRS cell (e.g. BTSM:0/BTS:5/PTPPKF:0)

Enter the LOCK PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> LOCK PTPPKF
then set the following attribute value:
NAME = BTSM:0/BTS:5/PTPPKF:0

Result: the GPRS cell is locked.

13

Check the INICSCH parameter of the cell

Enter the GET PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> GET PTPPKF
then set the following attribute value:
NAME = BTSM:0/BTS:5/PTPPKF:0
REQATTL = INICSCH

Result: the value of the INICSCH parameter is retrieved.

14

Precondition
Is the INICSCH parameter set to either CS3 or CS4 value?

15

Y h ... 15
N h ... 16

Disable CS-3/CS-4 coding schemes at cell level

Enter the SET PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF
then set the following attribute value:
NAME = BTSM:0/BTS:5/PTPPKF:0
CSCH3CSCH4SUP = FALSE
INICSCH = one of the values among CS1 and CS2.

Result: CS-3/CS-4 coding schemes are disabled at cell level.

A30808-X3247-L210-3-7619

h ... 17

293

OMN:BSC

16

Operation
Base Station Controller

Disable CS-3/CS-4 coding schemes at cell level

Enter the SET PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF
then set the following attribute value:
NAME = BTSM:0/BTS:5/PTPPKF:0
CSCH3CSCH4SUP = FALSE

Result: CS-3/CS-4 coding schemes are disabled at cell level.

17

Unlock the GPRS cell

Enter the UNLOCK PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> UNLOCK PTPPKF
then set the following attribute value:
NAME = BTSM:0/BTS:5/PTPPKF:0

Result: the GPRS cell is unlocked.

18

Precondition
Have CS-3 and CS-4 coding schemes been disabled for ALL GPRS cells of the
BSC?

19

Y h ... 19
N h ... 11

Disable CS-3/CS-4 coding schemes at BSC level

To disable CS-3/CS-4 coding schemes at BSC level, enter the SET BSC
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

then set the following attribute value:
CSCH3CSCH4SUP = FALSE

Result: CS-3/CS-4 coding schemes are disabled at BSC level.

END

294

A30808-X3247-L210-3-7619

Operation
Base Station Controller

A30808-X3247-L210-3-7619

OMN:BSC

295

OMN:BSC

Operation
Base Station Controller

3.61

Enabling Link Adaptation for GPRS and EGPRS

Introduction
This procedure allows to enable both GPRS and EGPRS link adaptation processes.
GPRS offers four different coding schemes, from CS-1 to CS-4, with different data rates
(increasing from CS-1 (9.05 kbit/s) to CS-4 (21.4 kbit/s)) and robustness to fading and
interference (decreasing from CS-1 to CS-4).
Instead, for EGPRS nine different modulation and coding schemes, MCS-1 to MCS-9,
are defined.

Only BTSE equipment belonging to BTSplus family (i.e. BS240, BS241, BS40, BS41,
BS240XL, BS240XS) can support EDGE coding schemes.
Regarding EGPRS coding schemes, the following considerations can be done:

four EGPRS coding schemes use the traditional GMSK modulation:

MCS1 (with a maximum data rate of 8.8 kbit/s);

MCS2 (with a maximum data rate of 11.2 kbit/s);
MCS3 (with a maximum data rate of 14.8 kbit/s);
MCS4 (with a maximum data rate of 17.6 kbit/s);

the remaining coding schemes use the 8 PSK modulation:

MCS5 (with a maximum data rate of 22.4 kbit/s);

MCS6 (with a maximum data rate of 29.6 kbit/s);
MCS7 (with a maximum data rate of 44.8 kbit/s);
MCS8 (with a maximum data rate of 54.4 kbit/s);
MCS9 (with a maximum data rate of 59.2 kbit/s).

The MCSs are divided into different families: A, Apadding, B and C. Each family has a
different basic unit of payload: 37 (and 34), 28 and 22 octets respectively. Different code
rates within a family are achieved by transmitting a different number of payload units
within one Radio Block. For families A and B, one, two or four payload units are transmitted, for family C, only one or two payload units are transmitted.
Tab. 3.61.2 shows the correspondence between families and coding schemes.
FAMILY

CODING SCHEMES

MSC-3, MSC-6, MSC-9

A Padding

MSC-3, MSC-6, MSC-8

MSC-2, MSC-5, MSC-7

MSC-1, MSC-4

Tab. 3.61.2 EGPRS Coding Schemes and Families

In both cases (GPRS and EGPRS) lowest coding schemes (e.g. CS1 and MCS1
respectively) show a good performance in poor radio conditions; on the other hand, only
highest coding schemes (e.g. CS4 and MCS9 respectively) can provide high data
throughput in good radio environments.

296

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Therefore an algorithm is needed in order to dynamically select the coding scheme that
behaves better in a specific radio condition. The dynamic selection of the coding
scheme, to suit radio link quality, is referred to as Link Adaptation.

Using GPRS or EGPRS, data can be transmitted either in acknowledged mode or

unacknowledged mode.
The acknowledged mode is used for data applications where the payload content
needs to be preserved. It is the typical mode for Background class (background
delivery of e-mails, SMS, download of databases) and Interactive class applications
(web browsing).
Then the goal of Link Adaptation for RLC acknowledged mode is therefore the
throughput maximization.
In GPRS TBF mode, the transfer of RLC Data Blocks in the acknowledged RLC/MAC
mode can be controlled by a selective type I ARQ mechanism.
In EGPRS TBF mode, the transfer of RLC Data Blocks in the acknowledged RLC/MAC
mode can be controlled by a selective type I ARQ mechanism, or by type II hybrid ARQ
(Incremental Redundancy: IR) mechanism, coupled with the numbering of the RLC
Data Blocks within one Temporary Block Flow.
In the type I ARQ mode, decoding of an RLC Data Block is solely based on the
prevailing transmission (i.e. erroneous blocks are not stored). In the type II ARQ case,
erroneous blocks are stored by the receiver and a joint decoding with new transmissions is done. This procedure allows the receiver to operate either in type I or type II
hybrid ARQ mode.
In BR7.0 release, the Incremental Redundancy mechanism for EGPRS is only used in
downlink direction; in uplink direction only the selective type I ARQ mechanism is used.
The unacknowledged mode is used for delay sensitive services, such as Conversational class (voice, video conference) and Streaming class applications (one-way real
time audio and video). When working in RLC unacknowledged mode, badly received
blocks are not re-transmitted (ARQ functions are not used). BLER information could be
derived and the link adaptation algorithm could work in a similar way to the acknowledged mode case. But the unacknowledged mode is typically used to support real time
applications and in this case minimizing the data unit error ratio, i.e. the fraction of data
unit lost or detected as erroneous, is much more important than maximizing
throughput.
So, the basic idea is to dynamically select the coding scheme that allows the highest
throughput according to the present radio conditions. Then the problem is to find the
switching points that allow to change from one coding scheme to another one.
The triggering of the switch does not use separate measurements of channel quality but
it is executed by analyzing the number of blocks to be repeated (not acknowledged
blocks) versus the number of transmitted blocks in total (i.e. the sum of the acknowledged blocks and the not acknowledged one). So to fix the switching points the
NACK/(ACK+NACK) ratio is used; it is called Block Erasure Ratio (BLER) and link adaptation is then based on BLER measurements (indirect measures of the radio quality).
The switching points between two coding schemes are then defined in terms of BLER
thresholds.

A30808-X3247-L210-3-7619

297

OMN:BSC

Operation
Base Station Controller

In case of GPRS the following BLER thresholds are defined:

BLER(CS1 ---> CS2) = 17%
BLER(CS2 ---> CS3) = 14%
BLER(CS3 ---> CS4) = 2%

BLER(CS2 ---> CS1) = 43%

BLER(CS3 ---> CS2) = 26%
BLER(CS4 ---> CS3) = 17%

In case of EGPRS some examples of defined BLER thresholds are the following:
BLER(MCS1 ---> MCS3) = 61%
BLER(MCS3 ---> MCS6) = 38%
BLER(MCS6 ---> MCS9) = 24%

BLER(MCS3 ---> MCS1) = 77%

BLER(MCS6 ---> MCS3) = 69%
BLER(MCS9 ---> MCS6) = 62%

The throughput is then maximized changing the coding schemes according to these
threshold values. For example, in case of EGPRS, if BLER goes below 38%, while using
MCS3, then a change to MCS6 will be decided.
In real networks 'ideal' switching points will depend on the actual RF scenario and it is
impossible to calculate such optimal values for each particular scenario. Upgrade
switching points and downgrade switching points are then stored in pre-calculated
matrix tables, one for each possible RF environment (these matrix tables can not be set
by O&M). By O&M, it is then possible to select the suitable matrix table, containing all
the ideal switching points (downgrade/upgrade switching points from/to all coding
schemes) for the particular RF scenario, by selecting the right radio environment.
Link Adaptation can be enabled for both GPRS and EGPRS using the ELKADPT
parameter of the PTPPKF object. Link Adaptation is enabled in both uplink and downlink
directions.
The user can also set other parameters that are valid for both GPRS and EGPRS
services; they are:

BLERAVEUL: it specifies the filtering period for BLER calculation in GPRS and
EGPRS uplink Link Adaptation; the value is expressed in number of radio blocks;

BLERAVDL: it specifies the filtering period for BLER calculation in GPRS and
EGPRS downlink Link Adaptation; the value is expressed in number of radio blocks.

Another parameter that is common to both the services is the RAENV one; it allows the
operator to specify the radio environment. As it has been described before, according to
the chosen radio environment a certain matrix table is selected (one specific for GPRS
and one specific for EGPRS) to define the BLER thresholds of the switching points. The
parameter can assume two values:

LOWDIV (lowDiversity): it means that, for a MS, radio conditions can change slowly,
for example because Frequency Hopping is disabled and the cell is characterized by
low user mobility (e.g. because MS have a speed less than 50 Km/h or because the
cell is a small one);
HIGHDIV (highDiversity): it means that, for a MS, radio conditions can change fast,
for example because Frequency Hopping is enabled.

Even if there are some common parameters to manage link adaptation, some differences exist between GPRS and EGPRS handling. They are described in the following.

298

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

LINK ADAPTATION FOR GPRS

The link adaptation features are the following:
1. all the signalling is done with CS-1;
2. data transfer is started with the highest available CS;
3. basing on received blocks, the BSC can evaluate the BLER value;
4. if conditions worsen, a downgrade to the lower CS is performed as soon as possible,
i.e. after all NACK blocks have finally be sent successfully, using the same coding
scheme (i.e. before changing from coding scheme A to coding scheme B, it is necessary to retransmit all the not acknowledged blocks using coding scheme A);
5. if conditions improve, an upgrade to the higher CS is performed as soon as no more
blocks have to be resent (i.e. all NACK blocks were finally transmitted successfully).
6. in uplink case the BSC informs the MS to change the coding scheme; in downlink
direction the BSC starts sending blocks with the new coding scheme.
In case of GPRS two matrix tables exist: the first defines BLER thresholds in case of
lowDiversity environment, whereas the second defines BLER thresholds in case of highDiversity environment. The link adaptation algorithm uses the first table or the second
one according to the value of the RAENV parameter.
LINK ADAPTATION FOR EGPRS
As it has been previously described, in case of EGPRS, up to nine modulation and
coding schemes are defined, and they belong to a certain family (see Tab. 3.61.2).
In general, according to the link quality, an initial Modulation and Coding Scheme (MCS)
is selected for an RLC block. For retransmissions, the same or another MCS from the
same family of MCSs can be selected. E.g. if MCS-7 is selected for the first transmission
of an RLC block, any MCS of the family B can be used for the retransmission.
The operator must define which sets of coding schemes must be used in the cell, both
in uplink and downlink direction. When configuring these sets, the following constraints
are automatically considered by the system:
a) MCS1 is always included in the selection: this is needed for signalling and due to the
fact that MCS1 is the only MCS that requires only one Abis timeslot;
b) if MCSx is implemented, all the lower order MCSy (y<x) of the same family must be
implemented. This is needed because retransmissions may have to be performed
with a (lower order) MCS of the same family.

Link Adaptation is not restricted within a family. Only retransmissions must be

performed using a coding scheme in the same family of the original one (the one that
was used for the first transmission of the radio block).
For what concern the configuration parameters a distinction must be done between the
uplink and the downlink directions of transmission.

a) Uplink Direction
The operator can configure which families of coding schemes can be used in uplink
direction. At least two families of available MCSs must be enabled, one for 8PSK
transmit capable mobiles, and the other one for GMSK-only transmit capable mobiles.

A30808-X3247-L210-3-7619

299

OMN:BSC

Operation
Base Station Controller

To enable families of coding schemes, a parameter for each family is given. The parameters are (remember the in uplink direction, the Incremental Redundancy is not implemented in BR7.0 release):

EMFA1UNIR8PSK (enMcsFamAMcs1UplinkWoutIncrRed8Psk): it enables MCS

belonging to FamilyA and MCS1 to be used, if MS support 8PSK modulation in
Uplink;

EMFAP1UNIR8PSK
(enableMcsFamilyApMcs1UplinkWithoutIncrementalRedundancy8Psk): it enables
MCS belonging to FamilyA padding and MCS1 to be used, if MS support 8PSK
modulation in Uplink case;

EMFB1UNIR8PSK (enMcsFamBMcs1UplinkWoutIncRed8Psk) it enables MCS

belonging to Family B and MCS1 to be used, if MS support 8PSK modulation in
Uplink EGPRS TBF;

EMFCUNIR8PSK(enMcsFamCUplinkWoutIncRed8Psk): it enables MCS belonging

to Family C and MCS1 to be used, if MS support 8PSK modulation in Uplink case;

EMFGUNIR8PSK(enMcsFamGmskUplinkWoutIncRed8Psk): it enables MCS

belonging to Family Gmsk to be used, if MS supports 8PSK modulation in Uplink
case;

EMFCUNIRGMSK(enMcsFamCUplinkWoutIncrRedGmsk): it enables MCS

belonging to Family C to be used, if MS does not support 8PSK modulation in Uplink
case;

EMFGUNIRGMSK(enMcsFamGmskUplinkWoutIncrRedGmsk): it enables MCS

belonging to Family Gmsk to be used, if MS does not support 8PSK modulation in
Uplink case.

Family GMSK is constituted by MSCs that can be used from a mobile station supporting,
in uplink direction, the GMSK modulation only. The coding schemes belonging to Family
GMSK are: MCS-1, MCS-2, MCS-3, and MCS-4; in fact these coding schemes use the
GMSK modulation.
The operator can also define the initial MCS to be used as default in uplink direction; if
no information about a MS in a cell are available, the defined MCSs will be used.
In fact the PCU hold into memory, for each mobile station, the last MCSs used in Uplink
direction for TBFs associated to the MS. These values are refreshed at the end of each
TBF, and cleared from memory if either a timer defined by the STGTTLLIINF (storageTimeTLLIInfo) parameter expires or if a cell reselection is performed.
The IMCSULNIR8PSK attribute suggests the MCS to be used in uplink direction if the
MS supports the 8 PSK modulation in this direction; the IMCSULNIRGMSK attribute
suggests the MCS to be used in uplink direction if the MS supports only the GMSK
modulation in this direction.

b) Downlink Direction
The operator can configure which families of coding schemes can be used in downlink
direction. EGPRS mobiles will be able to receive 8PSK modulated signals, therefore at
least one family of available MCSs must be enabled (all the MSs are 8PSK receive
capable)

300

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

To enable families of coding schemes, a parameter for each family is given. The parameters are (remember the in downlink direction, the Incremental Redundancy is always
supported by MSs):

EMCSFAMA1DL(enMcsFamAMcs1Downlink): it enables MCS belonging to Family

A and MCS1 to be used, in Downlink case;

EMCSFAMAP1DL(enMcsFamAPaddingMcs1Downlink): it enables MCS belonging

to Family A padding and MCS1 to be used, in Downlink case;

EMCSFAMB1DL(enMcsFamBMcs1Downlink): it enables MCS belonging to Family

B and MCS1 to be used, in Downlink case;

EMCSFAMCDL(enMcsFamCDownlink): it enables MCS belonging to Family C to be

used, in Downlink case;

EMCSFAMGDL(enableMcsFamilyGmskDownlink): it enables MCS belonging to

Family GSMK to be used, in Downlink case.

The operator can also define the initial MCS to be used as default in downlink direction;
if no information about a MS in a cell are available the suggested MCSs will be used.
In fact the PCU hold into memory, for each mobile station, the last MCSs used in Downlink direction for TBFs associated to the MS. These values are refreshed at the end of
each TBF, and cleared from memory if either a timer defined by the STGTTLLIINF (storageTimeTLLIInfo) parameter expires or if a cell reselection is performed.
The INIMCSDL attribute suggests the MCS to be used in downlink direction.
As it has been described, according to the chosen families of coding schemes (in uplink
or downlink direction), different thresholds have to be considered, since different coding
schemes are selected. Tab. 3.3 shows which thresholds are considered if, for instance,
the user has enabled FamilyA plus MCS1. Instead Tab. 3.4 shows which thresholds are
considered if, for instance, the user has enabled FamilyB plus MCS1.
In the tables, coding schemes written in vertical direction represent the starting coding
schemes, whereas those written in horizontal represent the arrival ones. So, for
example, watching at Tab. 3.3, to go from MCS1 to MCS3 the BLER shall be less than
a XX% value; to go from MCS3 to MCS1 the BLER shall be greater than another XX%
value.

If more than one family is enabled, the possible switching points are those given by the
sum of the tables related to the single families.

A30808-X3247-L210-3-7619

301

OMN:BSC

Operation
Base Station Controller

Fam C

MCS1

Fam B

MCS2

Fam A + MCS3
Fam A
Padding
Fam C

MCS4

Fam B

MCS5

Fam C

Fam B

Fam A + Fam C
Fam A
Padding

Fam B

Fam A + Fam B
Fam A
Padding

Fam A
Fam A
Padding

MCS1

MCS2

MCS3

MCS5

MCS6

MCS8

MCS7

MCS9

<XX%

>XX%

<XX%

Fam A + MCS6
Fam A
Padding
Fam B

MCS4

>XX%

<XX%

MCS7

Fam A
MCS8
Padding
Fam A
Tab. 3.3

MCS9

>XX%

Thresholds to be used if Family A plus MCS1 is chosen

Fam C

MCS1

Fam B

MCS2

Fam C

Fam B

Fam A + Fam C
Fam A
Padding

Fam B

Fam A + Fam B
Fam A
Padding

Fam A
Fam A
Padding

MCS1

MCS2

MCS3

MCS5

MCS6

MCS8

MCS4

MCS7

MCS9

<XX%
>XX%

<XX%

Fam A + MCS3
Fam A
Padding
Fam C

MCS4

Fam B

MCS5

>XX%

<XX%

Fam A + MCS6
Fam A
Padding
Fam B

MCS7

>XX%

Fam A
MCS8
Padding
Fam A
Tab. 3.4

302

MCS9
Thresholds to be used if Family B plus MCS1 is chosen

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Precondition

Before enabling link adaptation on a cell, enter the LOCK PTPPKF command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM --->BTS --->

PTPPKF ---> LOCK PTPPKF

b
Result: the PTPPKF object related to the cell is locked.

Enable link adaptation for GPRS and EGPRS

To enable link adaptation, enter the SET PTPPKF command, following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF

b
Then set to TRUE the value of the ELKADPT parameter.
Result: link adaptation is enabled.

END

A30808-X3247-L210-3-7619

303

OMN:BSC

Operation
Base Station Controller

3.62

Deletion of a TRX
Introduction
The procedure allows to delete a TRX.
The deletion of a TRX implies the automatic deletion of the corresponding LPDLR
instance.
Prerequisites
Deleting a TRX requires to delete all the channels (if any) belonging to it.
The corresponding frequency must be previously removed from FHSY.
If either a RFLOOP or a SCA object is enabled on a cell which a TRX to be deleted
belongs to, it must be locked before deleting the TRX (see "3.147 Management of
Online RF Loop Back" and "3.145 Enabling/Disabling Measurements to Get Smart
Carrier Allocation" for information about these objects).

Preliminary Consideration

If HOPMODE=BBHOP the procedure requires to remove the TRX frequency

from the FHSY as a preliminary step. In this case all the procedure steps must
be executed with the hopping attribute set to false.
a. If HOPP=false go to next step b. otherwise

b. If HOPMODE=BBHOP

i...."3.55 Disabling
Frequency
Hopping for a
BTS"
i...."3.44 Deletion
of a Frequency
from FHSY"

except step 10

Lock the TRX

In order to delete the TRX, it must be LOCKed entering the LOCK TRX
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> LOCK TRX

Result: Lock state.

Precondition
Is the RFLOOP enabled on the cell which the TRX to be deleted belongs to?

304

Y h ... 4
N h ... 5

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Lock the RFLOOP

The RFLOOP instance can be LOCKed entering the LOCK RFLOOP command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

RFLOOP ---> LOCK RFLOOP

Result: Lock state for the RFLOOP instance.

Precondition
Is the SCA enabled on the cell which the TRX to be deleted belongs to?

Y h ... 6
N h ... 7

Lock the SCA

The SCA instance can be LOCKed entering the LOCK SCA command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SCA

---> LOCK SCA

Result: Lock state for the SCA instance.

Lock all the channels belonging to the TRX

All the channels belonging to the TRX must be deleted. As a preliminary step,
they must be LOCKed entering the LOCK CHAN command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> LOCK CHAN for all the channels of that TRX.

Result: Lock state for the channel.

Delete all the channels corresponding to that TRX

The above mentioned channels can now be deleted entering the DELETE
CHAN following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> DELETE CHAN for all the channels of that TRX.

Result: Delete all the channels corresponding to that TRX.

A30808-X3247-L210-3-7619

305

OMN:BSC

Operation
Base Station Controller

GET information about the frequency of the TRX

Before deleting the TRX the user should take note of its frequency, entering the
GET TRX command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

--> GET TRX
with reference to TRXFREQ attribute.

Result: The frequency of the TRX is shown to the user.

10

Delete the TRX

The TRX can now be deleted entering the DELETE TRX command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

--> DELETE TRX

Result: Delete the TRX.

11

Situation
Is the RFLOOP enabled on the cell which the deleted TRX belonged to?

12

Y h ... 12
N h ... 13

Unlock the RFLOOP

The RFLOOP instance can be UNLOCKed entering the UNLOCK RFLOOP

command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

RFLOOP ----> UNLOCK RFLOOP

Result: Unlock state for the RFLOOP instance.

13

Situation
Is the SCA enabled on the cell which the deleted TRX belonged to?

14

Y h ... 14
N h ... 15

Unlock the SCA

The SCA instance can be UNLOCKed entering the UNLOCK SCA command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> UNLOCK SCA

Result: Unlock state for the SCA instance.

306

A30808-X3247-L210-3-7619

Operation
Base Station Controller

15

OMN:BSC

Set the CALL attribute for the involved BTS

The frequency carried by the deleted TRX, if not the BCCH one, must be eliminated from the Cell Allocation for the BTS which that TRX was belonging to:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS with CALLF = all frequencies but the one corresponding to the deleted
TRX.

Note: if the deleted TRX is the BCCH one, a new BCCH TRX must be defined.
Result: Set the CALLF attribute for the involved BTS.
Is HOPMODE=BBHOP?

Y h ..."3.56 Enabling
Frequency
Hopping for a
BTS"

N h ... END
END

A30808-X3247-L210-3-7619

307

OMN:BSC

Operation
Base Station Controller

3.63

Setting a TRX in Emergency Condition

Introduction
To set a TRX in emergency condition the user must define the MOEC (Member of
Emergency Condition) parameter.
Emergency configuration is entered in case of failure of the external BTSE power
supply or if the temperature exceeds the allowed threshold. Its purpose is to keep only
the most important BTSE unit and TRXs alive and thus to save the power as long as the
BTSE is powered by the back-up battery. Setting MOEC to true for the TRX means that
the hardware associated to this TRX will be powered if emergency configuration is
entered.
Two timer define the operations in emergency condition:

EMT1 (Emergency Timer 1): this parameter defines the delay for transition to the
BTSE emergency configuration in case of breakdown of the BTSE primary power
supply if a battery back-up is available in the BTSE.
The timer EMT1 is started when the relevant alarm occurs. If it expiries the BTSE
enters in emergency configuration; this BTSE condition means that only the central
BTSE control modules and the hardware serving those TRXs which have been
explicitly declared a member of emergency configuration are powered.
EMT2 (Emergency Timer 2): this parameter defines the delay for transition to the
BTSE zero carrier configuration in case of breakdown of the BTSE primary power
supply if a battery back-up is available in the BTSE.
The timer EMT2 is started when the BTSE enters the BTSE emergency carrier
configuration and if it expiries the BTSE enters in zero carrier configuration; the
BTSE zero carrier configuration condition means that only the central BTSE
control modules are powered, all other modules are switched-off.
The purpose of the BTSE zero carrier configuration is to keep the central control
modules available if microwave equipment is used. If no microwave equipment is
used the zero carrier configuration should be disabled (EMT2 equal to 0).

The EMT1 and EMT2 parameters are not used in case of overtemperature emergency.
The TRXs in emergency configuration have to be configured in the following order to
keep the cell operable:
1. the BCCH TRX,
2. all complete area TRX in a concentric cell,
3. all other TRXs
Otherwise a TRX re-configuration could occur. This could lead to TRXs not member of
emergency configuration which are still in service
Prerequisites
The BTSM and the TRXs object to be set must be already created.
The user must have the visibility level number set to "2".

308

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set TRX

To set TRX as member of emergency configuration, define the MOEC

parameter by means of the SET TRX command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX

The user must set the MOEC parameter equal to TRUE.

Set emergency timers

To set the timers the user must use the SET BTSM command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

EMT1
This attribute indicates the delay for the transition to the emergency
configuration in case of breakdown of the BTSE primary voltage supply if a
battery backup is available in the BTSE itself.
EMT2
This attribute defines the delay for the transition to the zero carrier configuration
in case of breakdown of the BTSE primary voltage supply if a battery backup is
available in the BTSE itself.
Result: Setting of the emergency timers involved in the feature.
Note:
These setting operations can be also executed during the creation phases of the
objects (CREATE TRX and CREATE BTSM commands).

END

A30808-X3247-L210-3-7619

309

OMN:BSC

Operation
Base Station Controller

3.64

Addition of a Radio Channel

Introduction
The configuration of a Physical Radio Channel allows the mapping of Logical Channels
into a Physical Radio Channel, specifying its attributes. The mapping between a Physical Channel and a Time Slot on A-bis Interface is automatically done by the system.
The TRX can support up to 8 Time Slots.
When creating a new channel, the user must fill in the CHTYPE attribute. This attribute
defines the logical channel combination mapped onto the physical channel (timeslot).
The CHTYPE attribute can assume the following values:

TCHFULL: TCH/F + FACCH/F + SACCH/TF

SDCCH: SDCCH/8 + SACCH/C8

MAINBCCH: FCCH + SCH + BCCH + CCCH

MBCCHC: FCCH + SCH + BCCH + CCCH +SDCCH/4 (0..3) +SACCH/C4 (0..3)

CCCH: BCCH + CCCH

SCBCH: SDCCH/8(0..7) + SACCH/C8(0..7) + CBCH

BCBCH: FCCH + SCH + BCCH + CCCH + SDCCH/4 + SACCH/4 +CBCH

TCHF_HLF: TCH/H(0,1) + FACCH/H(0,1) + SACCH/TH(0,1) or TCH/F + FACCH/F

+ SACCH/TF

TCHSD: channels that can be used either as TCHF_HLF or SDCCH, see

"3.65 Smooth Channel Modification"

The first channel containing SDCCH (MBCCHC, BCBCH, SCBCH or SDCCH) must be
configured on the BCCH TRX.
If CONCELL=TRUE the SDCCH channels can be put only on the TRXs having the
TRXAREA=COMPLETE.
If CELLTYPE=EXTCELL it is possible to define channel in extended (on even timeslot)
or normal mode. All the control channels must be configured in extended mode.
When the cell supports also packet switched services (see "3.47 Addition of a Point-toPoint Packet Function (GPRS/EGPRS)"), the user can set the GDCH attribute too. This
attribute allows the user to reserve one or more channels for GPRS service only.
The GDCH attribute can assume the following values:

PBCCH: i.e. the related channel is reserved for GPRS/EGPRS and it will support
GPRS/EGPRS signalling and data;
PCCCH: i.e. the related channel is reserved for GPRS/EGPRS and it will support
GPRS/EGPRS common signalling and data.

The user can configure GPRS/EGPRS channels only over those TRXs that he has
enabled to support GPRS (see "3.58 Enabling/Disabling GPRS Service").

PBCCH and PCCCH channels must be created on the BCCH TRX only (after
having enabled it to support GPRS, see "3.58 Enabling/Disabling GPRS Service".
When the PBCCH is configured on a specific channel, the following rules should be used
to configure the signalling for GPRS/EGPRS service (i.e. system information, packet
paging requests, packet channel requests and packet access grant requests):

310

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

1. the value of BSPBBLK and BPAGCHR parameters (belonging to PTPPKF object

and regarding signalling in downlink direction) has to be set in such way to have at
least one block of any type: PBCCH, PPCH and PAGCH. For instance if BSPBBLK
is set to "1" the maximum value for BPAGCHR is "9".
2. to avoid problem, the parameter BPRACHR, of PTPPKF object, has to be set to a
value greater then zero. The default value avoids the problem.
Prerequisites
A Radio Channel should be added after the configuration of TRX equipment, otherwise
the command is rejected. The instance of the Channel managed object must not be
equipped.
The first channel, created in the BTS, must be MAINBCCH, MBCCHC or BCBCH. In this
case the rtsl# must be 0 and the TRX the channel belongs to must be the broadcast one.
When creating the CHAN: MAINBCCH, MBCCHC, BCBCH, CCH, SCBCH or SDCCH
(control channels), the attributes of the TSC must be equal to BCC (BS Color code) of
the cell (BTS) to which the CHAN belongs, otherwise the command is rejected.
If the attribute of TSC is Skipped, it assumes the value equal to BCC (BS Color code) of
the cell to which the CHAN belongs; furthermore the TSC value is automatically updated
every time the operator modifies the value of the BCC parameter.
After the creation of the channel, the administrative state of this object is set to LOCK.
An UNLOCK command is required to put this object in service.
The user must have the visibility level number set to "2".

Create a new channel

To create a new channel, the user must enter the CREATE CHAN command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX --> CHAN ---> CREATE CHAN

Result: Creation of a new channel.

Place the channel in service

To place the Radio Channel in service, the user must unlock the object by
entering the UNLOCK CHAN command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN --->UNLOCK CHAN

Result: Unlocking of the newly created channel.

END

A30808-X3247-L210-3-7619

311

OMN:BSC

Operation
Base Station Controller

3.65

Smooth Channel Modification

Introduction
This feature has the aim to change the channel type from TCH to SDCCH and vice
versa, without service interruption (i.e. without the BBSIG reset, that implies a loose of
service on the involved TRX).
In order to overcome this problem and to allow a more flexible usage of radio resources,
a new type of channel is introduced in the system. This new type of channel is called
TCH/SD; it is able to support TCH/F, TCH/H or SDCCH/8 configuration. Then the BSC,
on cell base, decides the usage mode of this channel, and informs the BTS using the
Channel Activation message for the involved time slot.
In this way, after the creation of a TCH/SD channel type, that causes a BBSIG reset, the
operator can use this new type of channel either as TCH or SDCCH, without service
interruption, according to traffic scenarios.
Each TCH/SD when is created must be assigned to a specific pool; the pool is chosen
by the user using a new specific attribute for object CHAN (CHPOOLTYP attribute). The
following pool shall be considered in the configuration phase:

SDCCHPOOL; if the TCH/SD channel is assigned to the SDCCHPOOL, it will

behave as a typical SDCCH/8 channel;

TCHPOOL; if the TCH/SD channel is assigned to the TCHPOOL, it will behave as a

typical TCH/FH channel;

TCHSDPOOL; if the TCH/SD channel is assigned to the TCHSDPOOL, it will

behave as a a TCH/FH or as SDCCH/8 according to the traffic scenario.

The big advantage of this feature is that the CHPOOLTYP attribute can be changed via
a SET CHAN command, without any notification to the BTS. In this way the usage mode
of TCH/SD channels can be changed, without causing a loose of service on the whole
TRX.
Besides, all the channels defined as SDCCH/4 or SDCCH/8 will be automatically
assigned (by the system) to the SDCCHPOOL, while all the channels defined as TCH/F
or TCH/HF will be automatically assigned to the TCHPOOL.
To summarize:
1. the SDCCHPOOL contains all the channels declared as:
SDCCH/4
SDCCH/8
TCH/SD that the user decides to use as configured SDCCH;
2. the TCHPOOL contains all channel declared as:
TCH full
TCH dual
TCH/SD that the user decides to use as configured TCH (full or dual);
3. the TCHSDPOOL contains all the channels created as TCH/SD, that the user
decides to share between SDCCH or TCH based on resources congestion.
The following restrictions are applied using TCH/SD channel type:

312

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

1. On BTS1, maximum 4 radio timeslots per carrier can be configured as SDCCH/8, or

TCH/SD with SDCCHPOOL, due to the memory availability.
2. In case of dual band cells (GSM900 / DCS1800) the SDCCH/8 and TCH/SD used
as SDCCH must be configured in the BCCH frequency band.
3. The changes of channel configuration from TCH to TCH/SD or vice versa (and from
SDCCH to TCH/SD or vice versa) implies a DELETE command of the channel and
its new creation (i.e. a BBSIG reset)
4. Both BTS902F and BS11 are not able to support TCH/SD channels.
5. Using Concentric (or Extended) Cells, the TCH/SD Channel type with Pool SDCCHPOOL or TCHSDPOOL is configurable only on Complete (or Far) Area.
6. In order to prevent Cell Barring, the operator must configure at least one SDCCH
channel type, or one TCH/SD channel type belonging to SDCCHPOOL.
Inside the system, not configurable by the user, an additional pool is created in order to
contain the TCH/SD sub-channels, belonging to the TCHSDPOOL that are temporary
used as SDCCH. This pool is called SDCCH_BACKUP_POOL
POOL Type

Type of Radio Timeslot associated

SDCCHPOOL

SDCCH/4, SDCCH/8, TCH/SD belonging to SDCCHPOOL

TCHPOOL

TCH/F, TCH/H, TCH/SD belonging to TCHPOOL

TCHSDPOOL

TCH/SD belonging to TCHSDPOOL

SDCCH_BACKUP_
POOL

TCH/SD belonging to TCHSDPOOL and currently used as

SDCCH

Tab. 3.65.5 POOL types and related radio timeslots

SDCCH ALLOCATION STRATEGY

When the BSC receives an SDCCH request, at first, if the Direct Assignment Procedure
is enabled, it tries to allocate a TCH channel if possible. Then, if Direct Assignment
Procedure is disabled or there are not available TCH, the BSC continues to search for
an SDCCH channel.
The search algorithm is the following:
1. The BSC compare the new BTS parameter sdcchCongestionThreshold (SDCCHCONGTH) with the sum of busy sub-channels from SDCCHPOOL and
SDCCH_BACKUP_POOL. In case the sum of busy sub-channels is upper than
threshold, BSC moves (if exists) one radio timeslot from TCHSDPOOL to
SDCCH_BACKUP_POOL, in order to go below the threshold. If there are some
TCH/SD, the best quality channel is chosen.
2. If there are some idle SDCCH sub-channels in SDCCHPOOL, the BSC gets an idle
sub-channel from this Pool, in order to serve the request.
3. Otherwise, if the SDCCHPOOL is empty the SDCCH_BACKUP_POOL is checked.
If there are some idle sub-channels, the BSC gets from this pool the sub-channel of
a radio timeslot with the highest number of sub-channels already used, in order to
avoid fragmentation.

A30808-X3247-L210-3-7619

313

OMN:BSC

Operation
Base Station Controller

4. If the SDCCH_BACKUP_POOL is empty, an Immediate Assignment Reject is sent

to BTS.
The allocation strategy is well shown in Fig. 3.65.3.

SDCCH Request

Calculate sum of busy sub-channels of

SDCCH from SDCCH_BACKUP_POOL
and SDCCHPOOL

Is the sum
upper than
SDCCHCONGTH?

TCHSDPOOL
empty?

N
Move a TCH/SD channel with best quality
from TCHSDPOOL to
SDCCH_BACKUP_POOL

SDCCHPOOL
empty?

Get a SDCCH from

SDCCHPOOL

SDCCH_BACKUP
POOL empty?

Get a SDCCH from

SDCCH_BACKUP_POOL

Y
SDCCH request
rejected

SDCCH request
satisfied

Fig. 3.65.3 SDCCH Allocation Strategy

314

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

SDCCH RELEASE STRATEGY

In case of SDCCH release the procedure is the following:
1. If the sub-channel to be released belongs to SDCCHPOOL, it is returned to that
pool.
2. If the sub-channel to be released belongs to SDCCH_BACKUP_POOL, it is
returned to that pool.
3. When all the sub-channels of a radio timeslot belonging to
SDCCH_BACKUP_POOL are idle, the BSC checks the new BSC attribute timerGuardTchsd (TGUARDTCHSD). If its value is 0, the timeslot is immediately moved
to TCHSDPOOL. Otherwise a timer (set to TGUARDTCHSD) is started; if the
timeslot is still idle on timer expiration, it will be moved to TCHSDPOOL.
The release strategy is well shown in Fig. 3.65.4.

A30808-X3247-L210-3-7619

315

OMN:BSC

Operation
Base Station Controller

SDCCH release

SDCCH
belongs to
SDCCH_BACKUP
POOL?

Return SDCCH
to SDCCHPOOL

Y
Return SDCCH
to SDCCH_BACKUP_POOL

Is the involved
TCH/SD idle?

Start TGUARDTCHSD
timer

Y
Move the involved TCH/SD
from SDCCH_BACKUP_POOL
to TCHSDPOOL

TGUARDTCHSD=0?

TGUARDTCHSD
expiration

The TCH/SD remains

in
SDCCH_BACKUP
POOL

Is the involved
TCH/SD idle?

Move the involved TCH/SD

from SDCCH_BACKUP_POOL
to TCHSDPOOL

Procedure
terminated

Fig. 3.65.4 SDCCH Release Strategy

316

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

TCH ALLOCATION STRATEGY

In case of TCH Request the procedure is the following:
1. The BSC checks if there is a suitable TCH in TCHPOOL (the search algorithm is the
currently implemented).
2. If the TCHPOOL is empty, the BSC shall try to get one TCH/SD from TCHSDPOOL.
3. In case the TCHSDPOOL is empty, the BSC shall try to get one TCH/SD from
SDCCH_BACKUP_POOL.
4. In case no TCH are found in TCHPOOL, TCHSDPOOL or in
SDCCH_BACKUP_POOL, and the TCH Request is for MOC/MTC (or External
incoming HO) the already existing Preemption / Directed Retry / Queuing Procedures are tried (see "3.98 Queueing, Preemption and Directed Retry for TCH").
TCH RELEASE STRATEGY
In case of TCH Release, the Channel is returned to the original Pool.

Prerequisites
For all the involved procedures:
- the user must have the visibility level number set to "2";
- the network element must be in phase "2".

Preliminary Consideration
Do you want to create a TCH/SD channel type?
Do you want to change the Pool Type of a TCH/SD channel already created?
Do you want to set the SdcchCongestionThreshold value (SDCCHCONGTH)?
Do you want to set the TimerGuardTchsd timer?

h ... 2
h ... 4
h ... 7
h ... 8

Create a new TCH/SD channel

To create a new TCH/SD channel, the user must enter the CREATE CHAN
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX --> CHAN ---> CREATE CHAN

Then the user must assign the TCH/SD value to the CHTYPE attribute. The
user must also choose the Pool Type of this TCH/SD channel using the
CHPOOLTYP attribute.
Result: Creation of a new channel in locked state.

A30808-X3247-L210-3-7619

317

OMN:BSC

Operation
Base Station Controller

Place the channel in service

To place the Radio Channel in service, the user must unlock the object by
entering the UNLOCK CHAN command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN --->UNLOCK CHAN

h ... END

Result: Unlocking of the created channel.

Shutdown the TCH/SD channel

To shutdown the TCH/SD channel, the user must enter the SHUTDOWN CHAN
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SHUTDOWN CHAN

Result: the channel will be put in locked state.

Change the TCH/SD Pool Type

To change the Pool Type of a TCH/SD channel, the user must enter the SET
CHAN command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> SET CHAN

The user must change the Pool Type of the selected TCH/SD channel, changing
the value of the CHPOOLTYP attribute.
Result: the Pool Type is changed. The BTS is unaware of this change.

Place the TCH/SD channel in service

To place the Radio Channel in service, the user must unlock the object by
entering the UNLOCK CHAN command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN --->UNLOCK CHAN

Result: the channel is unlocked.

318

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Change the value of the SdcchCongestionThreshold

To change the SdcchCongestionTimer, the user must enter the SET BTS
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS

Then, the user must change the value of the SDCCHCONGTH attribute (it
belongs to the BASICS group).
Result: the Pool timer value is changed.

h ... END

Change the value of the TimerGuardTchsd timer

To change this value, the user must enter the SET BSC command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then, the user must change the value of the TGUARDTCHSD attribute (it
belongs to the BASICS group).
Result: the Pool timer value is changed.

END

A30808-X3247-L210-3-7619

319

OMN:BSC

Operation
Base Station Controller

3.66

Addition of a New GSM/GPRS/EGPRS Adjacent Cell

Introduction
This procedure allows to create an adjacent cell either for GSM or GPRS/EGPRS
services. It allows to manage both internal adjacent cells (i.e. cells belonging to the
same BSC) and external adjacent cells (i.e. cells belonging to other BSCs).
The management of both internal and external adjacent cells is provided by using the
TGTCELL attribute; this attribute is a mandatory attribute.
In fact the following mandatory attributes have to be specified during adjacent cell
creation:
1. NAME: it represents the complete path related to the ADJC object instance; for each
BTS object instance a maximum of 32 ADJC object instances can be created;
2. TGTCELL: it specifies the path of the target cell instance (see the explanation
below).
The other attributes (e.g. RXLEVMIN, HOM, HOMSOFF, HOMDTIME, etc.) are not
mandatory, but they are useful to manage in a better way each adjacent relationship (i.e.
to manage handovers from the serving cell to the neighborhood one; see
"3.78 Handover Management").
On creating an adjacent cell relationship it shall be made a distinction between two
possible situations:

adjacency between cells supporting only GSM service (adjacency between BTSs);

adjacency between cells supporting GPRS/EGPRS service too (adjacency between

PTPPKFs).

ADJACENCY BETWEEN BTSs

In case of an adjacency to an internal BTS the TGTCELL attribute will contain a reference (i.e. the complete path) to the internal target BTS.
In case of external adjacency the TGTCELL attribute will contain a reference to a new
object, namely the TGTBTS object. A TGTBTS managed object instance contains a
copy of the attributes of an external BTS MOI, to which an adjacent relationship has to
be made up. Once a TGTBTS MOI is configured, it will be treated by the system, for the
management of the adjacencies, as the other internal target BTSs.
This means that, in the case in which the external target BTS is adjacent to more than
one internal serving BTS, it will no more be necessary to replicate all the attribute values
in every ADJC managed object instance, but it will be enough that the different ADJC
MOIs refer to the same TGTBTS MOI.
Fig. 3.66.5 shows the management of adjacent cells.

320

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig. 3.66.5 Management of adjacent cells

Referring to BTS:1, two adjacent relationships are built:

BTS:1/ADJC:1; internal adjacent relationship towards BTS:2 (belonging to BSC:1);

BTS:1/ADJC:2; external adjacent relationship towards BTS:5 (belonging to BSC:2).

When the user creates the ADJC1 instance he must specify only those attributes that
are not enclosed in BTS:2 (i.e. handover management attributes), while for the other
attributes (i.e. BCCH, BSIC, CELLGLID, etc.) the TGTCELL attribute provides the reference to BTS:2.
When the user creates the ADJC2 instance he must specify only those attributes that
are not enclosed in BTS:5 (i.e. handover management attributes). The TGTCELL
attribute will provide the reference to the TGTBTS:0 instance, that contains all the
attributes (i.e. BCCH, BSIC, CELLGLID, etc.) enclosed in BTS:5.
So, the user, before creating an external adjacent relationship, must create the TGTBTS
instance containing the attributes belonging to the external cell.

A30808-X3247-L210-3-7619

321

OMN:BSC

Operation
Base Station Controller

ADJACENCY BETWEEN PTPPKFs

The same considerations apply for the management of the adjacencies between
PTPPKFs. A new TGTPTPPKF object class is introduced. The TGTPTPPKF object
class is hierarchically dependent by the TGTBTS object class, in the containment tree.
A TGTPTPPKF managed object instance will contain a copy of the attributes, of an
external PTPPKF instance, involved in the management of the adjacency. Once a
TGTPTPPKF object instance is configured, it is treated by the system, for the management of the adjacencies, as the other internal target PTPPKFs.
Therefore:

in case of internal adjacency, the TGTCELL attribute identifies the target PTPPKF
instance, through the reference to the superordinate BTS instance;

in case of external adjacency, the TGTCELL will identify the TGTPTPPKF object
instance, through the reference to the superordinate TGTBTS object instance.

Order of creation of the new objects:

To explain the order in which the new objects have to be created we can distinguish two
possibilities.
1. If the packet switched services are not present in the cells, the order of creation of
the objects, involved in the adjacency management, is the following:
the target TGTBTS has no superordinate;
an ADJC instance, related to an external target BTS, has to be created only after
the creation of both the serving BTS and the related target TGTBTS.
2. If packet switched services are present in the cells, the order of creation of the
objects involved in the adjacency management is the following:
the target TGTBTS has no superordinate;
the serving PTPPKF has to be created only after the creation of the superordinate
serving BTS;
the target TGTPTPPKF has to be created only after the creation of the superordinate TGTBTS;
an ADJC, related to an external BTS target, has to be created only after the
creation of the superordinate serving BTS and the related serving PTPPKF, target
TGTBTS and target TGTPTPPKF.

A single BTS can support up to 32 neighbor cells. When the LOTRACH attribute of the
SET HAND command is set to FALSE, one of the 32 allowed ADJC is reserved by BSC
for LOTRACH handling. The operator can then configure only 31 ADJC cells.

Prerequisites
To enter this command, the host BTS must exist; the adjc# instance must not be
equipped.
To enter this command, the user must have the visibility level number set to "2".

322

A30808-X3247-L210-3-7619

Operation
Base Station Controller

Choose the type of adjacent relationship

Would you like to create a GSM adjacent relationship?
Would you like to create a GPRS/EGPRS adjacent relationship?

h ... 2
h ... 6

Situations about GSM target cell

Is the target cell an internal cell?
Is the target cell an external cell?

OMN:BSC

h ... 3
h ... 4

Create the internal adjacent relationship

To create a new internal adjacent cell, the user must enter the CREATE ADJC
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

---> CREATE ADJC

Then the user must set the TGTCELL attribute equal to the BTS instance
related to the target internal cell.
Result: The cell object is created with the entered attribute settings, all not
enabled optional attributes assume their default values.

h ... END

Situation
Has the TGTBTS object instance, related to the external cell, been create yet?

Y h ... 5
N i ..."3.67 Addition
of a New
GSM/GPRS/E
GPRS External
Cell"

Create the external adjacent relationship

To create a new external adjacent cell, the user must enter the CREATE ADJC
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

---> CREATE ADJC

Then the user must set the TGTCELL attribute equal to the TGTBTS instance
related to the target external cell.
Result: The cell object is created with the entered attribute settings, all not
enabled optional attributes assume their default values.

h ... END

Situations about GPRS/EGPRS target cell

Is the GPRS/EGPRS target cell an internal cell?
Is the GPRS/EGPRS target cell an external cell?

A30808-X3247-L210-3-7619

h ... 7
h ... 8
323

OMN:BSC

Operation
Base Station Controller

Create the internal GPRS adjacent relationship

To create a new internal GPRS/EGPRS adjacent cell, the user must enter the
CREATE ADJC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

---> CREATE ADJC

Then the user must set the TGTCELL attribute equal to the BTS instance that
univocally identify the subordinate target GPRS/EGPRS internal cell.
Result: The cell object is created with the entered attribute settings, all not
enabled optional attributes assume their default values.

h ... END

Situation
Has the TGTPTPPKF object instance, related to the GPRS/EGPRS external
cell, been create yet?

Y h ... 5
N i...."3.67 Addition
of a New
GSM/GPRS/E
GPRS External
Cell"

Create the external GPRS/EGPRS adjacent relationship

To create a new external GPRS/EGPRS adjacent cell, the user must enter the
CREATE ADJC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

---> CREATE ADJC

Then the user must set the TGTCELL attribute equal to the TGTBTS instance
that univocally represents the subordinate target GPRS/EGPRS external cell.
Result: The cell object is created with the entered attribute settings, all not
enabled optional attributes assume their default values.

END

324

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.67

OMN:BSC

Addition of a New GSM/GPRS/EGPRS External Cell

Introduction
This command is strictly related to the procedure that allows to add an adjacent cell to
the system (see "3.66 Addition of a New GSM/GPRS/EGPRS Adjacent Cell"). In fact,
when the user configures a new external adjacent cell, there are two possible situations:

if the external cell supports GSM service only, the user must create before a
TGTBTS object instance. This TGTBTS (Target BTS) managed object instance
contains a copy of the attributes of the external target BTS. Once a TGTBTS is
configured, it is treated by the system, for the management of the adjacencies, as
the other internal target BTS. This means that, in the case in which the external
target BTS is adjacent to more than one internal serving BTS, it is no more necessary to replicate all the attribute values in every ADJC managed object instance, but
it is enough that the different ADJCs refer to the same TGTBTS. The attributes of
the external target BTS that must be inserted, when creating the related TGTBTS
instance, are the following:
CELLGLID (cell global identity): it contains the Cell Identification (CI) and the
Location Area Id of the external target cell;
BSIC (base station identity code): it is composed by two fields, NCC (Network
Color Code) and BCC (base station color code);
SYSID: indicates the frequency band used by the external target cell;
BCCHFREQ: defines the absolute radio frequency channel number of the BCCH
channel.

if the external adjacent cell supports packet switched services too, the user must
create before a TGTPTPPKF instance. A TGTPTPPKF managed object instance
contains a copy of the attributes of the external target PTPPKF. Once a TGTPTPPKF is configured, it is treated by the system, for the management of the adjacencies, as the other internal target PTPPKF. Therefore, in case of internal adjacency,
the TGTCELL will identify the PTPPKF target through the reference to the superordinate BTS. In case of external adjacency, the TGTCELL will identify the target
TGTPTPPKF through the reference to the superordinate TGTBTS. The attributes of
the external target PTPPKF that must be inserted, when creating the related
TGTPTPPKF instance, are the following:
Routing Area Color (RACOL attribute) of external target PTPPKF;
Routing Area Code (RACODE attribute) of external target PTPPKF.

In the containment tree, the TGTPTPPKF (Target Point-To-Point Packet Function) is

hierarchically dependent by the TGTBTS.
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"
Before creating a TGTPTPPKF instance, the user must create the corresponding
TGTBTS one.

A30808-X3247-L210-3-7619

325

OMN:BSC

Operation
Base Station Controller

Choose the object instance to be created

h ... 2
h ... 4

Would you like to create a TGTBTS instance?

Would you like to create a TGTPTPPKF instance?

Create the TGTBTS

To create a TGTBTS instance, the user must enter the CREATE TGTBTS
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> TGTBTS ---> CREATE

TGTBTS

Result: The TGTBTS instance is created.

Situation

Y h ... 5
N h ... END

Would you like to create the TGTPTPPKF instance too?

Situation

Y h ... 5
N h ... 2

Have you created the superordinate TGTBTS instance yet?

Create the TGTPTPPKF

To create a TGTPTPPKF instance, the user must enter the CREATE TGTPTPPKF command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> TGTPTPPKF ---> CREATE

TGTPTPPKF

Result: The TGTPTPPKF instance is created.

END

326

A30808-X3247-L210-3-7619

Operation
Base Station Controller

A30808-X3247-L210-3-7619

OMN:BSC

327

OMN:BSC

Operation
Base Station Controller

3.68

Addition of a UMTS Adjacent Cell

Introduction
This procedure allows to add a UMTS adjacent cell to the system. Obviously, a UMTS
adjacent cell is always considered an external cell (i.e. a cell that does not belong to the
BSC).
To define a UMTS neighboring cell for a specific BTS object instance, the user must
create an instance of the ADJC3G object (subordinate to the BTS one).

For each BTS object instance, the user can define up to 32 neighboring GSM cells
(ADJC object) and up to 64 neighboring UMTS cells (ADJC3G object).
When creating an ADJC3G object instance (see also "3.66 Addition of a New
GSM/GPRS/EGPRS Adjacent Cell"), the user must define:
1. NAME: it represents the complete path related to the ADJC3G object instance;
2. TGTCELL: it specifies the path of the target cell instance; in case of neighboring
UMTS cells, the TGTCELL attribute contains a reference to one of the following two
objects:
TGTFDD: it contains all the parameters that allow to describe a neighboring
UMTS FDD cell;
TGTTDD: it contains all the parameters that allow to describe a neighboring
UMTS TDD cell.

Besides the previous parameter, in the ADJC3G object, the user can also define other
parameters that are used to manage the handover towards this UMTS cell.
So, before creating the ADJC3G object related to a UMTS neighboring cell of a specific
BTS, the user must have already created either the TGTFDD or the TGTTDD object
defining the UMTS cell.
In this way, different BTS objects, having as neighboring cell the same UMTS cell, will
indicate the same TGTFDD object instance (or the same TGTTDD object instance) in
the adjacent relationship defined by the subordinate ADJC3G object instance.
Example: if the TGTFDD:0 instance has been created to define in the BSC database a
UMTS cell, this UMTS cell can be defined as adjacent of both the BTS:1 and the BTS:5
cells in the following way:

if for example the ADJC3G:4 instance of the BTS:1 object, represents the neighboring relationship towards the UMTS cell defined by the TGTFDD:0 instance, the
user sets the TGTCELL attribute equal to TGTFDD:0;
if for example the ADJC3G:2 instance of the BTS:5 object, represents the neighboring relationship towards the UMTS cell defined by the TGTFDD:0 instance, the
user sets the TGTCELL attribute equal to TGTFDD:0.

As it has been described, to configure a UMTS cell two objects are provided according
to the cell type (FDD cell or TDD cell).
When defining a external UMTS FDD cell, the following main parameters have to be set:

328

CELLGLID (C-ID cell identifier): it identifies univocally the UMTS FDD cell in the
UMTS/GSM networks and it is composed by MCC (Mobile Country Code), MNC
(Mobile Network Code), LAC (Location Area Code) and CI (Cell Identifier);
FDDARFCN: it defines the frequency of the cell;

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

RNCID: it identifies the RNC;

FDDSCRMC: it defines the Primary Scrambling Code;
FDDDIV: it indicates if diversity is applied for the cell.

When defining a external UMTS TDD cell, the following main parameters have to be set:

CELLGLID (C-ID cell identifier): it identifies univocally the UMTS TDD cell in the
UMTS/GSM networks and it is composed by MCC (Mobile Country Code), MNC
(Mobile Network Code), LAC (Location Area Code) and CI (Cell Identifier);
RNCID: it identifies the RNC;
BNDWIDTDD: it defines the bandwidth used for TDD;
TDDARFCN: it defines the frequency of the cell;
TDDDIV: it indicates if diversity is applied for the cell.

Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Configure a FDD UMTS neighboring cell

Has the TGTFDD object instance, related to the UMTS cell, been create yet?

Y h ... 3
N h ... 2

Create the UMTS cell

To create a new UMTS cell, enter the CREATE TGTFDD command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TGTFDD ---> CREATE

TGTFDD

Then set the following attributes:

CELLGLID
FDDARFCN;
RNCID;
FDDSCRMC;
FDDDIV.
Result: the external UMTS cell is created in the BSC.

A30808-X3247-L210-3-7619

329

OMN:BSC

Operation
Base Station Controller

Create the external adjacent relationship

To create a new UMTS adjacent cell, enter the CREATE ADJC3G command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

ADJC3G ---> CREATE ADJC3G

Then set the TGTCELL attribute equal to the TGTFDD instance related to the
chosen UMTS cell.
Result: The adjacent relationship is created.

END

330

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.69

OMN:BSC

Configuring separate BA Lists for Idle and Active State

Introduction
This feature introduces the possibility to configure separate lists of adjacent cells to be
monitored for cell reselection (idle mode) and handover (dedicated mode).
A mobile needs to know which BCCH carriers have to be monitored for either cell reselection or handover purpose. The list of these carriers, called BA (BCCH Allocation) List,
is included in the IE Neighbor Cells Description, which is sent to the MS in the System
Information Messages.
If different layers (e.g. GSM900 and GSM1800) are connected to separate MSCs, i.e.
not all of the MSCs are provided by the same supplier, a huge amount of Location
Updates occurs between the layers, since it is not possible to define the same Location
Area within different MSCs. This leads to an excessive signalling load in the case of
Multiband Networks.
In order to overcome this problem an additional attribute has been introduced in the
ADJC MOC.
The name of the parameter is USG (USaGe); it can assume three different values:
Value
SI_2
SI_5
SI_2_5

Adjacent Cell State

relevant for idle mode
relevant for active mode
relevant for both

The default value is SI_2_5.

The parameter allows the customer to choose for each adjacent cell if it is relevant for
idle mode (SI_2 value), connected mode (SI_5 value) or both idle and connected modes
(SI_2_5 value).
The value indicates the type of System Information Message containing the Neighbor
Cell Description, which is System Information 2 (sent on BCCH) in the case of idle mode
and System Information 5 (sent on SACCH) in the case of dedicated mode.
If USG is set to SI_2 the adjacent cell is included in the BA List of idle mode only, i.e. it
is not considered as a candidate for a handover; if USG is set to SI_5 the adjacent cell
is included in the BA List of dedicated mode only, i.e. it is not considered as a candidate
for a cell reselection.
Using the remaining setting (SI_2_5) the adjacent cell is considered as a candidate for
both handover and reselection cases.
Example:
A dual band mobile, supporting GSM900 and GSM1800, is moving within an area
covered by both the bands. The GSM900 layer coverage is supplied by the MSC A,
whereas the GSM1800 layer coverage is supplied by the MSC B. Let us suppose that
the mobile uses GSM900 band at first.

A30808-X3247-L210-3-7619

without this feature, if the mobile performs a cell reselection to GSM1800, it is likely
that a subsequent Location Updating to the GSM1800 network shall occur, since it
is not possible to define the same Location Area within MSC A and MSC B. Then, if
the mobile leaves the GSM1800 coverage provided by MSC B, i.e. it enters an area
covered by GSM900 only, a second Location Updating (to the GSM900 network)
shall be probably needed.

331

OMN:BSC

Operation
Base Station Controller

if the feature is enabled, the adjacent cell (covered by both the bands), which is the
target of the cell reselection in the previous case, is now relevant for active mode
only, because the USG attribute of the relative ADJC MOC has been set to SI_5
value. As a consequence, no cell reselection is made and the mobile does not leave
the GSM900 network. The signalling load is reduced with respect to the previous
case, since no Location Updating is performed.

Prerequisites
The user must have the visibility level number set to "2".
The ADCJ object instance must be already created.

Situation

Y h ... 2
N i...."3.66 Addition

Has the ADJC object instance been created yet?

of a New
GSM/GPRS/E
GPRS Adjacent Cell"

Set the attributes of the adjacent cell

To modify the USG attribute of an adjacent cell, the user must enter the SET
ADJC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

---> SET ADJC

Result: The state of the adjacent cell is configured.

END

332

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.70

OMN:BSC

Addition of a PCM Line A-sub interface

Introduction
The addition of a PCM line A-sub Interface requires the creation of a PCMS object
instance.
The creation of a PCMS adds on the A-sub Interface:

a 2048 kbit/s line (for PCM30)

or a 1544 kbit/s line (for PCM24)

When creating a new PCMS line, the user must specify:

1. the LICD number to which the line is connected to (Licdn field of the PCML
attribute);
2. the LICD circuit number (Circn field of the PCML attribute);
3. the LREDUNEQ attribute; this attribute specifies how the PCMS line is connected to
the BSC. In fact, it is possible to create on the BSC, on a single couple of PCM ports
of a LICD, 2 different and independent PCMS lines, connected to different TRAUs.
One line can be connected on trunk A and one on trunk B. This allows to increase
the PCMS lines of the BSC, and consequently its switching capacity.
So:
for the PCMS line connected to the trunk A, the user must set the LREDUNEQ
equal to SIMPLEXA;
for the PCMS line connected to the trunk B, the user must set the LREDUNEQ
equal to SIMPLEXB;
if only one PCMS line is connected for a couple of PCM ports (using the redundancy), the user must set the LREDUNEQ equal to DUPLEX.
4. the WMOD attribute; in order to configure 2 PCMS lines towards two different
TRAUSs using a single trunk of the couple, their working mode (WMOD attribute)
must be set with the value single trunk. This is made to distinguish them from the
double trunk PCMS, for which the whole PCM couple (trunk A and B) is dedicated
to a single TRAU link
.

i
qtlp

A30808-X3247-L210-3-7619

As it has been described, the LICD boards allow two types of configuration
for a PCMS line:
- DOUBLE_TRUNK: the PCMS line keeps busy two trunks even if it is not
duplicated (this kind of working is also called SELECTION MODE);
- SINGLE_TRUNK: the PCMS line keeps busy only one trunk, and it can
be configured only in SIMPLEX (this kind of working is also called TRANSPARENT MODE).
If the user wants to use the TRANSPARENT MODE he must set to TRUE
the ASUNBECAP attribute of the BSC object. This attribute enables the
possibility of transparent mode on QTLPs, but only if they belong to the
QTLP V2 type.

333

OMN:BSC

Operation
Base Station Controller

334

Considering the standard BSC (see "1.4.1 Standard BSC") the Transparent mode cannot be used when QTLP V1 boards are mounted; so when
the ASUBENCAP attribute is set to TRUE, these boards are not allowed,
and, if present, they are put in disable state.
The high capacity BSC with the old rack (see "1.4.2 High Capacity BSC
with Old Rack") causes an important consequence on the management of
the LICDs, as far as the PCMS lines in single trunk mode are concerned. In
fact, when the SNAP matrix is used, the problem which prevents the
correct working of the QTLP V1 is removed, and the device handler does
not have to disable the QTLP V1. Indeed the problem is in the network
connections, because the SN16 requires a particular treatment of the bit of
the PCM lines that is not supported by the QTLP V1. This processing of the
bits is no longer necessary with the SNAP, thanks to the fact that this card
is able to switch separately the time slots at 8 Kbit/sec. In conclusion, using
the SNAP switching matrix, it is meaningless to inhibit the creation of the
PCMS in single trunk mode. Of course, this restriction will remain with
SN16.
The conclusion is that, when NTWCARD is set to NTWSNAP, the ASUNBECAP attribute must always be set to <NULL>.
If the high capacity BSC with the new rack is used (see "1.4.3 High
Capacity BSC with New Rack"), and as a consequence STLP boards are
used, the ASUNBECAP attribute must always be set to <NULL> (i.e. if
NTWCARD is set to NTWSNAP_STLP, the ASUNBECAP attribute must be
set to <NULL>).

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

When using single_trunk configuration, it is not compulsory that the PCMS connection
is symmetrically identical between BSC and TRAU (for example, it is possible to connect
the trunk A of the BSC to the trunk B of the TRAU and vice versa). It is only required the
consistency between the local redundancy attribute and the local cable connection.
Apart from this, any other combination is allowed: for example, the PCMS can be set in
DUPLEX on the TRAU, and in SIMPLEXA/B on the BSC, or vice versa. If this is verified,
it is possible that on the BSC/OMC there is some alarm active for the PCMS, whose
error string contains the reference to a PCM trunk that is configured on the TRAU, but
not on the BSC (for example: Notified Loss Of Signal On Link B, when the PCMS is in
simplex A on the BSC, and DUPLEX on the TRAU). However, the error strings used by
the BSC for the locally detected PCMS alarms are different and well distinct from the
ones that are used for the alarms detected on the RX of TRAU, and so no confusion is
possible.
Fig. 3.70.6 shows an example of connections between TRAUs and BSCs. Suppose that
it is desired to move the TRAU 2 from the BSC 2 to the BSC 1, connecting it to the free
trunk B of a PCM couple, when the trunk A of the same couple is already used for
another PCMS. It is not necessary that the operator goes on the place of the TRAU 2,
and moves the cable from A to B; it is only sufficient that on both the side (i.e. TRAU side
and BSC side), the configuration is single_trunk.
The operator can decide to leave unchanged, in the flash EPROM of the all the BSCIs,
the default DUPLEX value. In this way the BSCI software detects and uses the effectively connected trunk, in plug and play mode, independently on how the PCMS is
connected on the BSC. The only drawback is that, when the line is in duplex, but only
one trunk is really connected, a minor alarm (Loss Of Signal On Link A/B) will be active
for the PCMS object on the TRAU, and the alarm Notified Loss Of Signal On Link A/B
on the BSC, for the PCMS object.

Fig. 3.70.6 Example of BSC-TRAU connection

A30808-X3247-L210-3-7619

335

OMN:BSC

Operation
Base Station Controller

If the PCMB and PCMS already created occupy all the slots of the preexisting LICD, the
user must first create a new EPWR (but not in case of new BSC rack where EPWRs do
not exist) and then also a new LICD. The creation of the LICD board sets the threshold
values of the system alarm for 2048 kbit/s for PCM30 line and for 1544 kbit/s for PCM24
line (see Command Manual for details on alarm settings).
The Line Interface Board (LICD) corresponding to the referenced line will be automatically considered to be equipped within the system if it is the first equipped line on the
board. Otherwise, the user must create a new LICD.
The creation of the LICD-0 must be preceded by the creation of a LICDS.
Prerequisites
The object must be in NOT EQUIPPED state in order to submit the command, while the
Line Interface Board (LICD) corresponding to the referenced line must be in EQUIPPED
state to submit the command. The circuit number of the LICD board corresponding to
the referenced line must not be already connected to a PCM line.
After the creation of the PCMS the administrative state of this object is set to LOCKED.
An UNLOCK command is required to put this object in service.
To enter all the commands, the user must have the visibility level number set to "2".

Precondition
Are all the slots of the preexisting LICD occupied by PCMBs and PCMSs
already created?

Y h ..."3.74 Addition
of a PPLD (only
for standard
BSC) and of a
LICD Board"

N h ... 2
2

Choose the BSC type

Is the BSC a standard one (SN16 matrix)?
Is the BSC an high capacity one (SNAP matrix)?

Choose the QTLP type

Are the QTLP boards belonging to the QTLP V1 type?
Are the QTLP boards belonging to the QTLP V2 type?

336

h ... 3
h ... 10
h ... 4
h ... 7

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Disable TRANSPARENT MODE

To avoid to put in disable state the QTLP V1 boards, the user must enter the
SET BSC command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

and then he has to set (if the attribute is not already set to FALSE):
ASUBENCAP = FALSE.

Result: the TRANSPARENT MODE is disabled.

Create a PCMS

To create a PCMS, the user must enter the CREATE PCMS command:following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMS ---> CREATE PCMS

The user must specify at least the following attributes:
- PCML (that allows to configure both the LICD number and the the LICD circuit
number);
- LREDUNEQ (remember that the working mode is always double trunk (i.e.
selection mode), apart of that the line is created as SIMPLEX or DUPLEX

Result: Creation of a PCMS in locked state.

Place the PCMS in service

To place the PCMS in service, the user must unlock the object, by entering the
UNLOCK PCMS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMS --->UNLOCK PCMS

Result: Unlocking of the new created PCMS.

h ... END

Enable TRANSPARENT MODE

To allow transparent mode, the user must enter the SET BSC command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

and then he has to set (if the attribute is not already set to TRUE):
ASUBENCAP = TRUE.

Result: the TRANSPARENT MODE is enabled.

A30808-X3247-L210-3-7619

337

OMN:BSC

Operation
Base Station Controller

Create a PCMS (single_trunk, simplex)

To create a PCMS, the user must enter the CREATE PCMS command:following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMS ---> CREATE PCMS

The user must specify at least the following attributes:
- PCML (that allows to configure both the LICD number and the the LICD circuit
number);
- LREDUNEQ = SIMPLEXA (or SIMPLEXB);
- WMOD = SINGLE_TRUNK.

Result: Creation of a PCMS in locked state.

Place the PCMS in service

To place the PCMS in service, the user must unlock the object, by entering the
UNLOCK PCMS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMS ---> UNLOCK

PCMS

h ... END

Result: Unlocking of the new created PCMS.

10

Create a PCMS (single_trunk, simplex)

To create a PCMS, the user must enter the CREATE PCMS command:following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMS ---> CREATE PCMS

The user must specify at least the following attributes:
- PCML (that allows to configure both the LICD number and the the LICD circuit
number);
- LREDUNEQ = SIMPLEXA (or SIMPLEXB);
- WMOD = SINGLE_TRUNK.

Result: Creation of a PCMS in locked state.

338

A30808-X3247-L210-3-7619

Operation
Base Station Controller

11

OMN:BSC

Place the PCMS in service

To place the PCMS in service, the user must unlock the object, by entering the
UNLOCK PCMS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMS ---> UNLOCK

PCMS

Result: Unlocking of the new created PCMS.

END

A30808-X3247-L210-3-7619

339

OMN:BSC

Operation
Base Station Controller

3.71

Addition of a TRAU to the System

Introduction
This procedure provides the commands needed for a Transcoder and Rate Adapter Unit
(TRAU) addition.
The creation of the TRAU in the BSS requires to have previously created its dedicated
PCMS line.
When creating a new TRAU, the user must specify:
1. the TRAU absolute number (NAME attribute) inside the BSC (range [0...35]). The
BSS can support:
up to 20 TRAUs in case of standard BSC;
up to 32 TRAUs in case of high capacity BSCs with the old rack (see, "1.4.2 High
Capacity BSC with Old Rack").
up to 36 TRAUs in case of high capacity BSCs with the new rack (see, "1.4.3 High
Capacity BSC with New Rack").
2. the Expected Software Version string (EXPSWV attribute) that have to match with
the version of the TRAU SW load stored in the BSC disk;
3. the TEI parameter [0...63]: it contains the Terminal Endpoint Identifier used in the
layer2 addressing on the Abis-Interface for the logical O&M or Radio Signalling Link.
4. the PCMS line used to connect the TRAU equipment (PCMSN attribute); in fact, the
addition of a TRAU requires the PCMS to be previously created.
After creating a TRAU, the user can create the logical LAPD connection, used by the
TRAU, to communicate with the BSC for Operational & Maintenance purposes. This
LAPD logical connection is represented by the LPDLS object. In the hierarchy tree, the
TRAU object is father of LPDLS object (see "1.5.1 Notes on the CREATE
commands"). Only one LPDLS object instance can be created for each superordinate
TRAU.
So on creating a new LPDLS instance the user must specify:
1. the name of LPDLS instance, i.e. the complete address of the new LPDLS to be
created; the addressing of each LPDLS instance is composed of two parts:
the TRAU absolute number [0...35];
the LPDLS relative number [0];
2. the PCMS line and the time slot number over which the LPDLS must be created
(ASUBCH attribute).
If the clock synchronization signal is required by the system, the user can also create
the SYNC object.
The SYNC object represents a clock synchronization signal added to the system. The
synchronization signal is derived from the signal at 2048 kbit/s for PCM30 and 1544
kbit/s for PCM24 of the given PCMS line (PCM line on A-sub Interface).
It is possible to create one SYNC for each equipped TRAU (the SYNC instance can be
different from the TRAU instance where it is working). The number of the SYNC identifies also the priority. The value zero is associated to the highest priority.

340

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Before synchronizing the BSC, the frequency of the synchronization source deputed to
become active is automatically measured; if the relative frequency error exceeds a
threshold value (0.5 ppm), another source is selected.
In case of a free running BSC, the criteria for choosing the active source are the
following:
1. Among all the available SYNC and SYNE, it is chosen the one for which any
frequency measurement done since last bring up/full initialization has resulted within
acceptable range.
2. If for all the available sources the frequency measurement has failed at least once
after last bring up/full initialization, it is chosen the one for which most time has
passed after the bad measurement.
3. In case more than one available source has never had a bad frequency measurement, the SYNE has a higher priority than the SYNC.
4. In case more than one available source within the same class (SYNC or SYNE) has
never had a bad frequency measurement, the source with the lower instance has a
higher priority.
The feature Tandem Free Operation is allowed by enabling the flag ETFO of the TRAU
object.
Some particular network configurations require to connect the BSC to the TRAU through
a satellite link. By using this satellite connection, the terrestrial connections of A-sub
interface can be replaced. The signalling and the user data will be sent via satellite from
the BSC to the TRAU and vice-versa.
Prerequisites
TRAU:
The TRAU object must be in NOT EQUIPPED status in order to submit the command.
Each TRAU is connected to the BSC with one or two 2Mbit PCMS line for PCM30 and
1,544 Mbit for PCM24. The relevant PCMS managed object must be already equipped.
After the creation of the TRAU the administrative state of this object is set to LOCKED.
An UNLOCK command is required to put this object in service.
LPDLS:
The instance of the PCMS inserted in the ASUBCHAN attribute must be previously
created.
No further command is necessary for the LPDLS after its creation, because this object
does not have the administrative state.
SYNC:
Before creating the SYNC object, the relevant PCMS line must be previously
EQUIPPED.
The SYNC object must be in NOT EQUIPPED state in order to create the object. After
the creation of the SYNC the administrative state is set to LOCKED. The UNLOCK
command is required to put the object in service.
To enter all these commands, the user must have the visibility level number set to "2".

A30808-X3247-L210-3-7619

341

OMN:BSC

Operation
Base Station Controller

Preliminary Consideration

h ... 2
h ... 6
h ... 7

Do you want to create a TRAU?

Do you want to create a LPDLS logical link?
Do you want to create a SYNC instance?

Precondition

Y h ... 3
N i...."3.70 Addition

Does the PCMS already exist?

of a PCM Line
A-sub interface"

Create a TRAU

To create a TRAU, the user must enter the CREATE TRAU command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> CREATE TRAU

Result: Creation of a TRAU.

Place the TRAU in service

To place the TRAU in service, the user must unlock the object, by entering the
UNLOCK TRAU command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> UNLOCK TRAU

Result: Unlocking of the newly created TRAU.

Precondition
Do you want to create a LPDLS logical link?

342

Y h ... 6
N h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Create the LPDLS

To create the LPDLS, the user must enter the CREATE LPDLS command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> LPDLS --->

CREATE LPDLS

Result: Creation of an LPDLS.

In case of standard BSC, if ,after the creation of the LPDLS, the system
response is:
Link Not Available
this means that the PPLD boards configured in the BSC are insufficient to
manage this new LPDLS. In this case, the only way to create a new LPDLS is to
create a new PPLD board first.

i ..."3.74 Addition
of a PPLD (only
for standard
BSC) and of a
LICD Board"

Creation of a clock synchronization signal.

If a clock synchronization signal is required, the user can create the SYNC by
entering the CREATE SYNC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SYNC ---> CREATE SYNC

Result: Creation of a SYNC.

Place the SYNC in service

To place the SYNC in service, the user must unlock the object by entering the
UNLOCK SYNC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SYNC ---> UNLOCK SYNC

Result: Unlocking of the newly created SYNC.

END

A30808-X3247-L210-3-7619

343

OMN:BSC

Operation
Base Station Controller

3.72

Addition of a PCM Line A Interface and SS7 Link

Introduction
The following procedure allows to create PCM lines on the A Interface. The required
SS7 link control can be created as well.
Line interface board (MSCI, belonging to TRAU) corresponding to the referenced line
will be automatically considered to be equipped in the system, if it is the first equipped
line on the board.
The creation of the PCMA adds a 2048 kbit/s PCM line for PCM30 and 1544 kbit/s for
PCM24 in the A Interface (PCMA) specifying its attributes. It associates a PCMA to a
given PCMT identified by:

the Transcoder and Rate Adapter Unit number (traun);

the circuit number (circn).

The BSS can support:

up to 80 PCMA lines in case of standard BSC;

up to 144 PCMA lines in case of high capacity BSCs (see "1.4 Supported BSC
Types").

When adding a signalling link (SS7L) between the BSC and the MSC, the user must
specify:
1. the pcma number and the timeslot number, used for the SS7 link (TSLA attribute);
2. the linkset number (LKSET attribute);

If Location Services are not used, all the SS7 links must belong to the sane
linkset, i.e. the linkset number 0. After creating the first SS7L instance, the
SS7S object (that identifies the linkset) is automatically created too; after
deleting the last SS7L instance, the SS7S object is deleted too.
If Location Services are used, exploiting the BSS centric architecture, there is
the possibility to create a different kind of SS7L links to connect the BSC to
the SMLC (through the MSC). These links could belong to another linkset, i.e.
the linkset number 1; so after creating the first of these SS7L links, another
instance of the SS7S object is automatically created (for more details, see
"3.113 Enabling Location Services").

3. the signaling link code (SLC attribute) identifying unambiguously the link inside the
linkset.
In case of standard BSC, when creating a SS7L signalling link, the user must also
specify the PPCC board and the circuit number to which the link must be connected to
(using the LNKA attribute).
In case of high capacity BSCs (NTWCARD = NTWSNAP or NTWCARD =
NTWSNAP_STLP), the attribute LNKA, which defines the PPCC and the circuit number
where the SS7L works, must have a null value. In fact, in this case, the card (PPXL) and
circuit are decided by the internal software, and the LNKA remains only as internal
attribute.

The system can handle up to 8 signalling links in case of standard BSC, and up to 16
signalling links in case of high capacity BSCs.

344

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Some particular network configurations require to connect the TRAU to the MSC
through a satellite link. By using this satellite connection, the terrestrial connections of
the A interface can be replaced. The signalling and the user data will be sent via satellite
from the TRAU to the MSC and vice versa.
The satellite link on the A has impact on the following protocols:
- CCSS No.7, used on the A Interface,
- The application Layers supported by the above indicated protocols (e.g. BSSAP)
should take into account the delay introduced by the satellite and the transmission
quality of the link.
Only one link of the Abis, Asub or A-interface should be satellite at the same time. The
BSC will not perform any appropriate checks.
Prerequisites
PCMA:
The PCMA must be in NOT EQUIPPED status to create the object, while the TRAU must
necessarily exist.
The relevant hardware has to be plugged in the proper slot before creating the object.
No PCM line has to be connected to the circuit number (Circn) of the TRAU.
The A interface through the satellite must be enabled by proceeding as follow:
SET BSC:NAME=BSC:0,...,AISAT=sbsAInterfaceIsSatellited;
After the creation of the object the administrative state of this object is set to LOCK. An
UNLOCK command is required to put this object in service.
SS7L:
To create the SS7 Link the relevant PCMA line should already be EQUIPPED, the OPC
should be already created (see PROC: Definition of the Signalling Point Code), and the
SS7L object must be in NOT EQUIPPED state.
The Time Slot of all the pcma lines (or of the pcms line) connected to the TRAU do not
have to be already reserved in order to submit the command.
After the creation of the object the administrative state of this object is set to LOCK. An
UNLOCK command is required to put this object in service.

Preliminary Consideration
Do you want to create a PCMA line?
Do you want to create an SS7L link?

h ... 2
h ... 5

Create the PCMA line

To create a PCM line on the A interface, the user must enter the CREATE PCMA
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMA ---> CREATE PCMA

Result: Creation of a PCMA line.

A30808-X3247-L210-3-7619

345

OMN:BSC

Operation
Base Station Controller

Place the PCMA in service

To place the PCMA in service, the user must unlock the object, by entering the
UNLOCK PCMA command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMA ---> UNLOCK

PCMA

Result: Unlocking of the newly created PCMA line.

Situation

Y h ... 5
N h ... END

Do you want to create an SS7L logical link?

Precondition

Y h ... 6
N i...."3.75 Definition

Does the OPC object instance already exist?

of the Signalling
Point Code"

Create the SS7L link

To create the corresponding SS7L link, the user must enter the CREATE SS7L
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SS7L ---> CREATE SS7L

Result: Creation of an SS7L link.

Place the SS7L in service

To place the SS7L in service, the user must unlock the SS7L link by entering the
UNLOCK SS7L command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SS7L ---> UNLOCK SS7L

Result: Unlocking of the newly created SS7L link.

END

346

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.73

OMN:BSC

Management of Links towards Radio Commander/Cell

Broadcast Centre
Introduction
The BSC supports interfaces towards the following network elements:
a) the Radio Commander (RC), to handle O&M procedures and signalling;
b) the external Cell Broadcast Centre (CBC), to support all GSM specified cell broadcast service primitives.

Regarding the Cell Broadcast Centre, external means that the CBC Server application
is not located on the same machine that supports the Radio Commander one.
In order to manage the interfaces toward these network elements, two different level 3
protocols are supported by the BSC:

the X.25 protocol;

the IP protocol.

The BSC supports only one of the previous two protocols at a time; so the connections
to Radio Commander and CBC must be either X.25 based or IP based. Mixed X.25 and
IP connections are not supported at all.
Independently from the used level 3 protocol, the following application links shall be
created:

the link toward the Radio Commander application for O&M purposes; this link is
created through the OMAL object;

the link toward the Cell Broadcast Centre application; this link is created through the
CBCL object.

Connections using X.25 protocol

Regarding the physical link, when the X.25 protocol is used, two possibilities exist to
connect the BSC to the RC and the CBC:

a dedicated physical link (i.e. an ad hoc cable) connecting the BSC to a switched
packet data network (PSPDN), from which RC and CBC can be reached; this dedicated physical link is represented by the X25D object;
a link created via a PCM timeslot on A interface and so through the MSC; this physical link is represented by the X25A object.

The X.25 protocol is implemented in IXLT boards; from this point of view the two IXLT
boards can be configured either as active/standby or active/active.
In case of active/standby configuration, the link redundancy towards RC and CBC does
not exist (because only one link, managed by the active IXLT board, exists); in this case:

a special cable (named Y cable) is designed to exploit the board redundancy (i.e.
when the active IXLT board fails, the standby one can replace it), and the user must
create only one instance of the X.25 object, i.e.:
the X.25A:0 instance, if he wants to use a connection realized through the MSC
(in this case he must indicate, by the ACHAN parameter, on which pcma line and
timeslot he wants to configure the physical link);

A30808-X3247-L210-3-7619

347

OMN:BSC

Operation
Base Station Controller

the X.25D:0 instance, if he wants to use a direct connection.

The X.25 object instance (X.25A or X.25D) is automatically associated to

the active IXLT board.

only one link can be created to RC and CBC applications respectively, in particular:
the OMAL:0 to the Radio Commander;
the CBCL:0 to the Cell Broadcast Centre.

These two links must be associated, by the LINKTYPE parameter, to the

same X.25 object instance (X25A:0 or X25D:0) previously created. The
X121ADDR parameter of OMAL and CBCL object represents the X.25
address, and it must assume a different value for each link (OMAL and
CBCL).

In case of active/active configuration, the link redundancy towards RC and CBC exists
(because two links exists); in this case:

the user must create two instances of the X.25 object, i.e.:
X.25A:0 and X.25A:1 instances, if he wants to use connections realized through
the MSC (in this case he must indicate, by the ACHAN parameter, on which pcma
line and timeslot he wants to configure physical links);
the X.25D:0 and X.25D:1 instances, if he wants to use direct connections.

The two physical links must be of the same type (both of X25A type, or
both of X25D type); mixed configuration are not allowed.

The X.25 object instance 0 is automatically associated to IXLT:0, whereas

the X.25 object instance 1 is automatically associated to IXLT:1.

two links can be created to RC and CBC applications, in particular:

the OMAL:0 and the OMAL:1 to the Radio Commander application;
the CBCL:0 and the CBCL:1 to the Cell Broadcast Centre.

OMAL:0 and CBCL:0 are associated to instance 0 of the X.25 object previously created (X25A:0 or X.25D:0), whereas OMAL:1 and CBCL:1 are
associated to instance 1 of the X.25 object previously created (X25A:1 or
X.25D:1). The two links can work in load sharing, doubling the link capacity.

Connections using IP protocol

Between the BSC and RC/CBC also IP based links are supported. IP links can replace
the X.25 ones; they are based on Ethernet 10/100T dedicated links (i.e. for IP links the
connection through the A interface is not allowed).
As it has been described in " New MPCC and TDPC processor boards" the IP protocol
is supported by MPCCV8 boards only; so in order to create an IP link from/to the BSC,
MPCCV8 boards must be inserted.
When an IP link is used, IXLT boards do not support anymore the connection to RC and
CBC (because X.25 connections can not be used simultaneously with IP ones), but IXLT
boards are still useful, since they continue to support the LMT connection and to handle
power ON/OFF requests.

348

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

It must be noted that MPCC boards configuration is active/standby only: the

active/active configuration, which is possible for IXLT boards, is not possible for MPCC
ones.
The physical link between the BSC and the IP network (from which both RC and CBC
network elements can be reached) can be either single or duplicated, but one link only
at a time can be active (i.e. no load sharing is possible by the BSC and no load sharing
is required to the RC). When the link is duplicated one link is connected to the MPCC:0
board and the other one is connected to the MPCC:1 board.
Please note that because of the high link speed (100 Mb/s) the Y cable, as designed for
the IXLT, cannot be provided, but it is not indispensable since the port of each MPCC
can be connected to the intermediate communication equipment (hub, switch, router).
In the following, three examples of connections between the BSC and the RC/CBC are
reported:

Fig. 3.73.7 shows a configuration that can be used when the BSC is co-located with
RC/CBC equipment; in this case the connection is realized through a LAN;
Fig. 3.73.8 shows an Y cable-like connection;

Fig. 3.73.9 shows a connection using two links.

Fig. 3.73.7 Example of BSC-RC/CBC connection through a LAN

A30808-X3247-L210-3-7619

349

OMN:BSC

Operation
Base Station Controller

Fig. 3.73.8 Example of BSC-RC/CBC connection: Y cable like

Fig. 3.73.9 Example of BSC-RC/CBC connection by two links

One active IP address only is needed at BSC side to be reached by the RC and the
CBC. Anyway for testing purposes an additional IP address is needed. That is: two IP
addresses must be defined for each BSC. The active address is always associated to
the active MPCC copy port, while the additional one is always associated to the
standby one (i.e. there is a dynamic address-port association).
The IP link used for the communication between the BSC and external network
elements (RC and CBC) is managed by the IPLI object, with the following features:

only one instance of the IPLI object can be created;

no mixed configurations are allowed: it is possible to create either a X25A/D link or
the IPLI one.

When configuring the IPLI object instance, the following parameters have to be filled:

350

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

PrimaryIpAddr: it is the IP address that is assigned to the providing service MPCC

port. The RC and CBC will always use this address when calling the BSC. The
convention used for his value is the well-known dotted decimal format (e.g.
172.31.21.88);

NetMask: it is the NetMask that will be assigned to both the MPCC port copies. The
value must be assigned according to the local LAN configuration. The convention
used for his value is the well-known dotted decimal format (e.g. 255.255.255.0);

Gateway0: it is the IP address of the default gateway connected to the MPCC copy
0. It has to be filled if either the RC or the CBC (or both) does not belong to the same
IP sub-network of the BSC;

Gateway1: it is the IP address of the default gateway connected to the MPCC copy
1. It has to be filled if either the RC or the CBC (or both) does not belong to the same
IP sub-network of the BSC.

SecondaryIPaddr: it is the IP address that is assigned to the standby MPCC port.

The RC and CBC will never use this address when calling the BSC. It is used in order
to perform the periodical IP link test (see below).

After having created the IPLI object instance the user can configure the links to RC/CBC
applications, creating OMAL and CBCL object instances.
Since, as it has been described, the IP link is supported by the MPCC board that works
in active/standby mode, the link redundancy concept, as described in case of X.25 links,
is no more supported when the IP link is used. As a consequence the following rules
regard OMAL and CBCL configuration:

only one instance of the OMAL object can be equipped (i.e. OMAL:0) when the
TCP/IP link is used, since it is tied to the single IPLI object instance;

only one instance of the CBCL object can be equipped (i.e. CBCL:0) when the
TCP/IP link is used, since it is tied to the single IPLI object instance;

OMAL and CBCL links must be associated, by the LINKTYPE parameter, to the
IPLI:0 object instance previously created;

the X121ADDR parameter is meaningless, since it indicates the X.25 network

address, and it does not regard IP link configuration.

In order to allow the operator to test in an easy way the configuration of the BSC IP host,
the PING IPLI command is introduced. This command is especially useful during the
IPLI configuration phase when the operator is in charge of configuring the IPLI attributes
according to the LAN topology, the BSC belongs to. This command allows the operator
to ping, from the BSC (from either MPCC:0 or MPCC:1), a generic IP address, in order
to check the correctness of all the IPLI attribute values. It must be noted, however, that
the result of this test is only useful for the operator, but it will never draw to IPLI state
and status change.
Besides, with the introduction of the IP link between BSC and RC/CBC, it is necessary
to manage a new procedure to test this link on MPCC Active (Active IP Link) and on
MPCC StandBy (StandBy IP Link) and, for each link, addressing the test to two different
level: a test that checks the BSC network accessibility and a test that checks RC/CBC
accessibility.
There are different causes that induces the activation of the IP Link Test Procedure. In
the following table are presented the possible test activation causes for the two different
link (Active IP Link and StandBy IP Link), subdivided into system and operator causes.

A30808-X3247-L210-3-7619

351

OMN:BSC

Operation
Base Station Controller

Test on Standby IP link

Test on Active IP link

From
system

MPCC becomes Hot Standby

Periodically
Active IP Link Fault
MPCC Active goes Disable-Dependency

BSC Initialization
Release of OMAL/CBCL link

From
operator

Lock MPCC Active

Switch MPCC Active
Ping Command

Ping Command

Tab. 3.73.6 Causes that Activate Tests on IP Links

Prerequisites
Since for both X.25 and IP networks, the same physical port is used, it is necessary to
reconfigure the BSC back-plane cabling when the IP interface is needed. The following
procedure must be followed:

it must be decided which type of network will be used (IP or X.25);

the BSC cabling must be modified according to the chosen solution.

Preliminary Consideration

Do you want to

h ... 2
h ... 5

Create a X25 connection, and related OMAL and CBCL links?

Create an IP connection, and related OMAL and CBCL links?

Create the X25A connection

Select the CREATE X25A command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> X25A ---> CREATE X25A

Then set the ACHAN attribute filling the following fields:
PcmaNumber
TslNumber

Result: Creation of the X25A connection.

352

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Create the OMAL link

To create the OMAL object enter the CREATE OMAL command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> OMAL ---> CREATE OMAL

Then set the following attribute values:
NAME=OMAL:0
LINKTYPE=X25A
X121ADDR=address to be given to this X.25 connection

Result: the OMAL link is created.

Create the CBCL link

To create the CBCL object enter the CREATE CBCL command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> CBCL ---> CREATE CBCL

Then set the following attribute values:
NAME=CBCL:0
LINKTYPE=X25A
X121ADDR=address to be given to this X.25 connection (different from the
address given to the OMAL connection).

Result: the CBCL link is created.

h ... END

Create the IP connection

Select the CREATE IPLI command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> IPLI ---> CREATE IPLI

Then set the following attributes:
PRIMARYIPADDR
SECONDARYIPADDR
GATEWAY0
GATEWAY1
SUBNETMASK

Result: Creation of the IP connection.

A30808-X3247-L210-3-7619

353

OMN:BSC

Operation
Base Station Controller

Create the OMAL link

To create the OMAL object enter the CREATE OMAL command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> OMAL ---> CREATE OMAL

Then set the following attribute values:
NAME=OMAL:0
LINKTYPE=IPLI
X121ADDR=NULL

Result: the OMAL link is created.

Create the CBCL link

To create the CBCL object enter the CREATE CBCL command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> CBCL ---> CREATE CBCL

Then set the following attribute values:
NAME=CBCL:0
LINKTYPE=IPLI
X121ADDR=NULL.

Result: the CBCL link is created.

Check IP links

To check the created IP link settings, enter the PING IPLI command, following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> IPLI ---> PING IPLI

Then set the following attribute values:
NAME=IPLI:0
MPCCCOPY= MPCC_0 or MPCC_1 (according to which IP link address you
want to check)
IPADDR= known IP address of an external equipment that should be reached
by the BSC.

END

354

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.74

OMN:BSC

Addition of a PPLD (only for standard BSC) and of a LICD

Board
Introduction
PPLD board (only for standard BSC)
When using a standard BSC (see "1.4.1 Standard BSC") the addition of one or more
peripheral processor PPLD boards is necessary when configured TRXs exhaust the
capacity, in terms of "LAPD" channels, of the existing PPLD boards.

When using an high capacity BSC, two PPXL boards are used, and they are able to
support both LAPD and SS7 signalling of the BSC.
The PPLD-0 and PPLD-1 are automatically created by the system at the start-up. After
the start-up, the Logical PPLD-0 is available to the system (the other PPLD is used for
N+1 redundancy). It can be used for the subsequent creation of LAPD links.

To achieve (N+M) redundancy (M-1) PPLD must be created after all LAPD links.
LICD board
The creation of the LICD board sets the threshold values of the system alarm for 2048
kbit/s lines for PCM30 and 1544 kbit/s for PCM24.
The Line Interface Board (LICD), corresponding to the referenced line, will be automatically considered to be equipped within the system, if it is the first equipped line on the
board. Otherwise, the user must create a new LICD.
Prerequisites
If the object to be added will belong to the Expansion subrack, an EPWR (Extended
Power Supply) object must be configured in case ot standard BSC or high capacity BSC
with the old rack; if it is not, the user must create it.
PPLD
Before creating this object, the PPLD board has to be plugged in the corresponding slot
before submitting the CREATE command.
The object must be in NOT EQUIPPED state to submit the command.
If the base module is equipped for the maximum capacity, it is necessary to install the
expansion module (A or B).
LICD
It is necessary to create the LICD object, if PCMB and PCMS occupy all the slots of the
pre-existing LICD.
The LICD with instance number lower than the one to be created must be EQUIPPED
before creating the new object.
To create these two objects, the user must have the visibility level number set to "2".

A30808-X3247-L210-3-7619

355

OMN:BSC

Operation
Base Station Controller

Preliminary Consideration

h ... 3
h ... 4

Create a PPLD board

Create a LICD board

Create an EPWR

If necessary, the user can create an EPWR

This step is required only if EPWR is not already configured.
Create an EPWR by entering the CREATE EPWR command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> EPWR --->

CREATE EPWR

Result: Creation of an EPWR .

Create a PPLD board

i.... 2

Before creating the PPLD board, the user can create an EPWR if necessary:
To create a PPLD board, the user must enter the CREATE PPLD command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> PPLD --->

CREATE PPLD

Result: Creation of a PPLD.

After the creation of the PPLD the administrative state is set to UNLOCK. The
UNLOCK command is NOT required to place this object in service.

Create a LICD board

Before creating the LICD, the user must create an EPWR if it is necessary.
To create the LICD, the user must enter the CREATE LICD command following
the next sequence of selections:

i.... 2

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> LICD --->

CREATE LICD

Result: Creation of a LICD.

After the creation of the object the administrative state of this object is set to
UNLOCK. An UNLOCK command is NOT required to put this object in service.

END

356

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.75

OMN:BSC

Definition of the Signalling Point Code

Introduction
Regarding signalling exchanged between the MSC and the BSC, two standards are
supported: SS7 CCITT and SS7 ANSI. The user can choose one of the two standards
by means of the SS7MTPTYP attribute.
The Signalling Point Code (SPC) represents the binary code contained in the message
routing, and it is used to identify an SS7 signalling point. The user can specify two type
of SPC:
1. MSCSPC: to specify the MSC identity within the network. It consists of three fields:
NetworkClusterMember, NetworkCluster, NetworkIdentifier;
2. SMLCSPC: to specify (when location services are used) the SMLC identity within
the network. It consists of three fields: NetworkClusterMember, NetworkCluster,
NetworkIdentifier (see "3.113 Enabling Location Services").
The user must also define the Originating Point Code (OPC attribute) used in the
Common Channel Signalling System (SS7); it identifies the point code of the BSC.
The control of this object is split into the management of four attribute groups (see
"1.9 Attribute Groups") automatically created with the OPC object:

BASICS: it manages the values of the attributes used in the Common Channel
Signalling System (SS7). The user can enable the Periodic Test Link message
through the SET OPC command;
MTL2: it manages the timer values for MTP Level 2 Protocol of the Common
Channel Signal System (SS7), as well as the threshold values used in the PPCC
MTL3: it manages the values of the timers for MTP Level 3 Protocol of the Common
Channel Signalling System (SS7).
SCCP: it manages the values of timers for SCCP Protocol of the Common Channel
Signalling System (SS7).

The attributes of the first group are the only one the user can set when creating the
object, while the other three groups are created with their default values. If the user
wants to change their values, he has to use the related SET command.
After creating the OPC object, if necessary, the user can create the SS7 link.
No administrative state is associated with the object OPC.
Prerequisites
The OPC must be in NOT EQUIPPED state in order to create the object.
The user must have the visibility level number set to "2".

A30808-X3247-L210-3-7619

357

OMN:BSC

Operation
Base Station Controller

Create an OPC

To create an OPC the user must enter the CREATE OPC command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> OPC ---> CREATE OPC

Result: Creation of an OPC

END

358

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.76

OMN:BSC

Setting the External/Free Run Synchronization

Introduction
Upon creating a SYNE object, the user can add an external synchronization signal
source to the system. The signal is directly connected to one of the two external input
accesses of the PLLH board.
This synchronization source has a higher priority than the SYNC synchronization source
in case of a free running BSC. For further details regarding the criteria for selecting the
active source (see procedure "3.71 Addition of a TRAU to the System").
The PLLH board can support 2 SYNE objects.
Prerequisites
Before creating the object, the relevant hardware has to be plugged into the proper slot.
The object must be in NOT EQUIPPED state in order to submit the command.
After the creation of the SYNE object the administrative state is set to LOCKED. The
UNLOCK command is required to put the object in service.
The user must have the visibility level number set to "2".

Create a SYNE

To create a SYNE, the user must enter the CREATE SYNE command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SYNE ---> CREATE SYNE

Result: Creation of a SYNE.

Unlock the SYNE

After the creation of the SYNE object the user must UNLOCK it with the
UNLOCK SYNE command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SYNE ---> UNLOCK SYNE

Result: Unlocking of the previously created SYNE.

END

A30808-X3247-L210-3-7619

359

OMN:BSC

Operation
Base Station Controller

3.77

Deletion of a BTS
Introduction
A previously created BTS may be deleted by using the DELETE BTS command.
Prerequisites
The instance of the BTS managed object must be already created.
Before deleting the BTS, it is necessary to first delete all the objects created after the
BTS, which are the sons of this object in the creation tree (Fig. 1.5.8). The user must
start from the leaf and then delete the objects, one by one, in their order: all the CHAN,
the FHSY, the TRX, the ADJC belonging to the BTS to be deleted finally, the BTS itself.
If either a RFLOOP or a SCA object is enabled on the cell, it must be deleted before
deleting the BTS object instance (see "3.147 Management of Online RF Loop Back"
and "3.145 Enabling/Disabling Measurements to Get Smart Carrier Allocation" for information about these objects).
Every object can be deleted only if it is a leaf in the creation tree.
Before entering a DELETE command the administrative state of objects BTS, TRX and
CHAN must be set to LOCK using the LOCK command.
The user must have the visibility level number set to "2".

In order to report to NMC the deletion of a BTS, this action has to be done from OMP,
not from LMT.

Delete the PTPPKF Object

Delete the PTPPKF object (if exists), otherwise go to the next step

i...."3.48 Deletion
of a Point-toPoint Packet
Function"

Disable frequency hopping (if enabled)

If HOPP=TRUE:

360

Set in the SET BTS command the parameter HOPP=FALSE.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Locking the Radio Channel

The first object to be deleted is the Radio Channel. Before deleting the object,
the user must lock it by entering the LOCK CHAN command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> LOCK CHAN

Result: Locking of a Radio Channel.

Note: .This command is to be repeated for each Radio Channel of the TRX
belonging to the BTS which is to be deleted

Delete the Radio Channel

The user can now delete the Radio Channel by entering the DELETE CHAN
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> CHAN ---> DELETE CHAN

Result: Deletion of a Radio Channel.

Note: This command is to be used for every Radio Channel of the TRX of the
BTS to be deleted.
The two steps (locking and deleting) must be repeated for every Radio Channel
belonging to the TRX of the BTS to be deleted.
Is every Radio Channel deleted?

Y h ... 5
N h ... 3

Delete the FHSY

The user can now delete the FHSY by entering the DELETE FHSY command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> FHSY

---> DELETE FHSY

Result: Deletion af a FHSY.

A30808-X3247-L210-3-7619

361

OMN:BSC

Operation
Base Station Controller

Lock the TRX

Before deleting the TRX, the user must lock it by entering the LOCK TRX
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

TRX ---> LOCK TRX

Result: Locking of a TRX.

Note: This command must be repeated for every TRX belonging to the BTS to
be deleted.

Precondition

Y h ... 8
N h ... 10

Is the RFLOOP enabled on the cell?

Lock the RFLOOP

The RFLOOP instance can be LOCKed entering the LOCK RFLOOP command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

RFLOOP ---> LOCK RFLOOP

Result: Lock state for the RFLOOP instance.

Delete the RFLOOP

The RFLOOP instance can be deleted by entering the DELETE RFLOOP

command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

RFLOOP ---> DELETE RFLOOP

Result: the RFLOOP instance is deleted.

10

Precondition
Is the SCA enabled on the cell?

362

Y h ... 11
N h ... 13

A30808-X3247-L210-3-7619

Operation
Base Station Controller

11

OMN:BSC

Lock the SCA

The SCA instance can be LOCKed entering the LOCK SCA command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SCA

---> LOCK SCA

Result: Lock state for the SCA instance.

12

Delete the SCA

The SCA instance can be deleted entering the DELETE SCA command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SCA

---> DELETE SCA

Result: the SCA instance is deleted.

13

Delete the TRX

The user can now delete the TRX by entering the DELETE TRX command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> DELETE TRX

Result: Deletion of a TRX and of the related LPDLR logical link.

Note: This command must be repeated for every TRX belonging to the BTS to
be deleted.
Is every TRX belonging to the BTS to be deleted?

14

Y h ... 14
N h ... 6

Delete the adjacent cell

The user can now delete the adjacent cell by entering the DELETE ADJC
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

---> DELETE ADJC

Result: Deletion of an Adjacent Cell. This command must be repeated for every
Adjacent Cell belonging to the BTS to be deleted.
The previous step must be repeated for every ADJC belonging to the BTS to
delete.

A30808-X3247-L210-3-7619

363

OMN:BSC

15

Operation
Base Station Controller

Lock the BTS

Finally the user can delete the BTS. Before deleting the object, he must lock it
by entering the LOCK BTS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ----> BTS ---> LOCK

BTS

Result: Locking of the BTS to delete.

16

Delete the BTS

Finally, the user can delete the BTS by entering the DELETE BTS command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

DELETE BTS

Result: Deletion of the BTS.

END

364

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.78

OMN:BSC

Handover Management
Introduction
Handover occurs when thresholds that guarantee the good quality of the connection are
exceeded. Such thresholds are referred to the attributes of the reception signal strength
level and interference level.
The HAND object instance has a one to one correspondence to a BTS instance, and the
HAND instance number 0 is automatically created after the creation of the related BTS
(see "1.5.1 Notes on the CREATE commands").
The control of this object is split into the management of two attribute groups (see
"1.9 Attribute Groups"):

BASICS: it contains all the attributes used to enable/disable handover features;

DATA: it is used to manage the 14.4 Kbit/sec service.

After the automatic creation, all the attributes of the HAND object assume their default
values. After that the user can modify these values by means of SET HAND command.
Usually the SDCCH is seized for a short period and there is no need of Handover. Its
seizure for a longer period, due to features like Queuing, OACSU (Off Air Call Set Up),
SMS (Short Message Service point to point), makes necessary to consider the handover
from a SDCCH to another one. This may happen for two main reasons:
- MS mobility
- Bad radio conditions for the seized channel.
The measurement of radio parameters and the relevant processing are implemented
into BTS in order to handle the Power Control (both decision and execution) and to
determine the handover indication towards the BSC.
The handover may be required for one of several reasons, e.g. radio coverage, traffic
load, O&M activity (for traffic reasons) and equipment failure.
The BSC supports inter-cell and intra-cell handover. For inter-cell handover the BSC
and BTSE will be implemented the finely synchronized HO for cells belonging to the
same BTSM (intra BTSE). It shall be possible to enable/disable the synchronized HO for
BSC with the attribute HOSYNCH of the BSC object. The synchronized HO reduces the
muting period during the intercell HO.
BTS derives the handover indication from the threshold comparisons, which are applied
to the respective radio link measurement results.
If an inter-cell handover is to be initiated, the BTS generates a list of preferred target
cells by using the power budget criterion. This list is used for the final handover decision
to be made in the BSC (internal handover) or MSC (external handover).
For an external handover, when the final decision is taken from the MSC, an indication
that handover is required is signalled to the MSC. For an internal inter-cell handover, the
handover is initiated without the MSC being informed but it is autonomously executed
by the BSC. MSC is informed after the successful execution. Also for intra-cell handover
the execution occurs autonomously by the BSC and MSC is informed after the
successful execution.
The handover functions are enabled and disabled using O&M flags; then the user can
set different parameters according to the handover type. The following handover types
can be managed:

A30808-X3247-L210-3-7619

365

OMN:BSC

Operation
Base Station Controller

intracell handover for quality;

intercell handover for quality;
intercell handover for level;
intercell handover for distance;
power budget handover;
concentric cell handover (see 3.93);
extended cell handover;
handover for traffic (see 3.79);
AMR handover (see 3.110);
fast uplink handover (see 3.81);
forced handover (see 3.92).

In order to have a great flexibility in Handover algorithm definition, it is more efficient to

differentiate handover thresholds on service basis. So an optimal usage of all available
radio channels according to the operators service policy and market strategy can be
achieved.
In order to make possible this kind of flexibility for CS services, fourteen service groups
have been introduced to differentiate among different circuit switched services. These
service groups concern: Circuit-Switched services (CS) on Half Rate (HR), Full Rate
(FR), Enhanced Full Rate (EFR), Adaptive Multi-Rate (AMR), Advanced Speech Call
Items (ASCI), Voice Broadcast Services (VBS), Voice Group Call Services (VGCS), and
High Speed Circuit-Switched Data services (HSCSD).
Tab. 3.78.7 shows in detail the fourteen groups that have been defined: each group is
identified by a specific parameter that is composed by a number of fields that allow to
specify different thresholds according to the service type.
Group

Kind of CS Service

Attribute

SG-1

Signalling on hopping channel

SG1HOPAR

SG-2

Signalling on non hopping channel

SG2HOPAR

SG-3

CS speech FR-EFR-ASCI VBS-ASCI VGCS on

hopping channel

SG3HOPAR

SG-4

CS speech FR-EFR-ASCI VBS-ASCI VGCS on non

hopping channel

SG4HOPAR

SG-5

CS speech HR on hopping channel

SG5HOPAR

SG-6

CS speech HR on non hopping channel

SG6HOPAR

SG-7

CS data until 9,6kbit/s or HSCSD 9.6kbit/s on hopping

channel

SG7HOPAR

SG-8

CS data until 9,6kbit/s or HSCSD 9.6kbit/s on nonhopping channel

SG8HOPAR

SG-9

CS data until 14,4kbit/s or HSCSD 14,4kbit/s on

hopping channel

SG9HOPAR

SG-10

CS data until 14,4kbit/s or HSCSD 14,4kbit/s on nonhopping channel

SG10HOPAR

Tab. 3.78.7 Service Groups for Handover Purpose

366

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Group

Kind of CS Service

Attribute

SG-11

CS speech AMR FR on hopping channels

SG11HOPAR

SG-12

CS speech AMR FR on non hopping channels

SG12HOPAR

SG-13

CS speech AMR HR on hopping channels

SG13HOPAR

SG-14

CS speech AMR HR on non hopping channels

SG14HOPAR

Tab. 3.78.7 Service Groups for Handover Purpose

For each group from SG-1 to SG-6 the complete set of the following thresholds has been
introduced in the related SGXXHOPAR parameters:
Lower RXLEV HO threshold for DL (range: 0..63)
Lower RXLEV HO threshold for UL (range: 0..63)
DL RXLEV threshold for intra-cell HO due to bad level (range: 0..63)
UL RXLEV threshold for intra-cell HO due to bad level (range: 0..63)
DL RXLEV threshold for intra-cell handover from inner to complete area of a concentric cell (range:0..63)
DL RXLEV threshold for intra-cell handover from complete to inner area of a concentric cell (range:0..63)
Lower RXQUAL HO threshold for DL (range: 0..7)
Lower RXQUAL HO threshold for UL (range: 0..7)
For each group from SG-7 to SG-10 the complete set of the following thresholds has
been introduced in the related SGXXHOPAR parameters:
Lower RXLEV HO threshold for DL (range: 0..63)
Lower RXLEV HO threshold for UL (range: 0..63)
DL RXLEV threshold for intra-cell HO due to bad level (range: 0..63)
UL RXLEV threshold for intra-cell HO due to bad level (range: 0..63)
DL RXLEV threshold for intra-cell handover from inner to complete area of a concentric cell (range:0..63)
DL RXLEV threshold for intra-cell handover from complete to inner area of a concentric cell (range:0..63)
Lower RXQUAL HO threshold for DL (range: 0..7)
Lower RXQUAL HO threshold for UL (range: 0..7)
RXQUAL DL threshold for intra- and inter-cell HO (range: 2..7)
RXQUAL UL threshold for intra- and inter-cell HO (range: 2..7)
For SG-11 and SG-12 groups the complete set of the following thresholds has been
introduced in the related SG11HOPAR and SG12HOPAR parameters:
Lower RXLEV HO threshold for DL (range: 0..63)
Lower RXLEV HO threshold for UL (range: 0..63)
DL RXLEV threshold for intra-cell HO due to bad level (range: 0..63)
UL RXLEV threshold for intra-cell HO due to bad level (range: 0..63)
DL RXLEV threshold for intra-cell handover from inner to complete area of a concentric cell (range:0..63)

A30808-X3247-L210-3-7619

367

OMN:BSC

Operation
Base Station Controller

DL RXLEV threshold for intra-cell handover from complete to inner area of a concentric cell (range:0..63)
Lower C/I HO threshold for DL on AMR channels (range: 0..30)
Lower C/I HO threshold for UL on AMR channels (range: 0..30)
Threshold for compression DL. It is used for detecting an AMR handover FR->HR.
The handover is triggered if both the rounded integer values For UL- and DL-quality
exceed their thresholds (hoThresAMRComprUL and hoThresAMRComprDL) (range:
0..30).
Threshold for compression UL (see above).
For SG-13 and SG-14 groups the complete set of the following thresholds has been
introduced in the related SG13HOPAR and SG14HOPAR parameters:
Lower RXLEV HO threshold for DL (range: 0..63)
Lower RXLEV HO threshold for UL (range: 0..63)
DL RXLEV threshold for intra-cell HO due to bad level (range: 0..63)
UL RXLEV threshold for intra-cell HO due to bad level (range: 0..63)
DL RXLEV threshold for intra-cell handover from inner to complete area of a concentric cell (range:0..63)
DL RXLEV threshold for intra-cell handover from complete to inner area of a concentric cell (range:0..63)
Lower C/I HO threshold for DL on AMR channels (range: 0..30)
Lower C/I HO threshold for UL on AMR channels (range: 0..30)
Threshold for decompression DL. It is used for detecting an AMR handover HR->FR.
The handover is triggered if any of the rounded integer values for UL- and DL-quality
go below its thresholds (hoThresAMRDecomprUL and hoThresAMRDecomprDL)
(range: 0..30).
Threshold for decompression UL (see above).
So, the user, when setting handover parameters, can choose if he wants to use specific
settings for a service group (filling one of the SGXXHOPAR parameter), or if he wants
to use the thresholds present outside the service groups (i.e. the general parameters
that are valid for all the groups when the user does not specify the SGXXHOPAR parameter).
The general configuration rule is the following:
a) when the user does not set any SGXXHOPAR parameters, service independent
parameters (i.e. the general parameters valid for all service groups) regard ALL the
circuit switched services;
b) when the user set one SGXXHOPAR parameter related to a specific CS service, the
service dependent thresholds of this SGXXHOPAR parameter override, only for
this kind of CS service, the service independent attributes.
For instance, the following table shows eight service independent parameters of the
handover object that are valid for all the CS services, when no SGXXHOPAR parameters have been filled.

368

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Service independent parameters

Parameter

Meaning

HOLTHLVDL

HoLowerThresholdLevDL

HOLTHLVUL

HoLowerThresholdLevUL

HOTDLINT

HoThresholdLevDLintra

HOTULINT

HoThresholdLevULintra

HORXLVDLI

HoRxlevDLinner

HORXLVDLO

HoRxlevDLouter

HOLTHQUDL

HoLowerThresholdQualDL

HOLTHQUUL

HoLowerThresholdQualUL

Tab. 3.78.8 Example of Service Independent Parameters

Now, if the user sets the SG3HOPAR parameter, the parameters shown in Tab. 3.78.8
will be replaced by those shown in Tab. 3.78.9, only for CS speech calls (FR, EFR,
ASCI VBS, ASCI VGS) on hopping channels (because the SG3HOPAR parameter
regards this kind of calls).

The other CS services will continue to use the parameters defined in Tab. 3.78.8 (i.e.
the service independent ones).

Service dependent parameters (SG3HOPAR group)

SG3HOPAR.HoLowerThresholdLevDL
SG3HOPAR.HoLowerThresholdLevUL
SG3HOPAR.HoThresholdLevDLintra
SG3HOPAR.HoThresholdLevULintra
SG3HOPAR.HoRxlevDLinner
SG3HOPAR.HoRxlevDLouter
SG3HOPAR.HoLowerThresholdQualDL
SG3HOPAR.HoLowerThresholdQualUL
Tab. 3.78.9 Example of Service Independent Parameters

If the user does not want to use the SGXXHOPAR thresholds he has to set the new
attributes to NULL value, this value is considered the DEFAULT value for new attributes.
The customer is allowed to set the attributes also for not all SGXXHOPAR parameters,
but if one threshold belonging to one SGXXHOPAR parameter is set to a valid value,
the others ones belonging to the same SGXXHOPAR parameter shall be significant.
The BTS is informed about the parameter settings in a different way:

A30808-X3247-L210-3-7619

369

OMN:BSC

Operation
Base Station Controller

the service independent thresholds and flags are transferred to the BTS via O&M
alignment;

the thresholds belonging to SGXXHOPAR parameters are transferred to the BTS

via one specific optional information element (Service Group Ho Settings) added in
one of the following messages:
Channel Activation message;
Channel Mode modify message;
Channel Configuration Change message; this message is used to signal some
changes occurred in a set of parameters previously submitted with either the
Channel Activation message or the Channel Mode Modify one.

In case for one SGXXHOPAR there are no valid assigned parameters, the BSC avoids
to insert the new information element in the Channel Activation message, in the Mode
Modify message and in Channel Configuration Change message. In this case the BTS
shall apply for Handover algorithm the threshold received via O&M alignment.
For a more detailed description of the HO attributes and algorithms please refer to the
TED: BSS manual.
Prerequisites
To manage the HAND object the BTS must be already created, as this object is automatically created with the BTS.
To modify the attributes of the HAND object (SET HAND) the user must have the visibility level number set to "2", while the GET HAND command is not dependent on the
visibility level.

Set service independent thresholds (upper/lower) for intercell handovers

for both quality and level causes

To modify these service independent handover attributes enter the SET HAND
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> HAND

---> SET HAND
then set the following attributes values:
HOLTHQUDL
HOLTHQUUL
HOLTHLVDL
HOLTHLVUL

Result: Setting of service independent handover attributes.

370

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set handover attributes related to CS Half Rate calls on hopping channel

To set these service dependent handover attributes enter the SET HAND
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> HAND

---> SET HAND
then set the SG5HOPAR parameter, filling ALL of its fields:
SG5HOPAR.HoLowerThresholdLevDL
SG5HOPAR.HoLowerThresholdLevUL
SG5HOPAR.HoThresholdLevDLintra
SG5HOPAR.HoThresholdLevULintra
SG5HOPAR.HoRxlevDLinner
SG5HOPAR.HoRxlevDLouter
SG5HOPAR.HoLowerThresholdQualDL
SG5HOPAR.HoLowerThresholdQualUL

Result: Setting of HAND thresholds related to CS Half Rate calls on hopping

channel. The service independent parameters will be overridden by these
values for this kind of calls.

END

A30808-X3247-L210-3-7619

371

OMN:BSC

Operation
Base Station Controller

3.79

Management of Handover for Traffic

Introduction
The Handover traffic reason has been introduced in the BSS system, in order to steer
connections from cells with high levels of traffic towards cells with a lot of free radio
channels. This feature is necessary when the serving cell is congested or when a high
percentage of channels is busy and there is the possibility to move some connections
to an adjacent cell where there is a temporary waste of resources.
This feature, as directed retry one, has the scope of increasing the capacity of the
network. Whereas directed retry acts on new connections, moving them towards
feasible adjacent cells, Handover-traffic algorithm moves connected users towards
adjacent cells allowing in the old cells to set up new connections. It is important to underline that whilst a connection moved for directed retry could be very far from the ideal cell
border, the connections moved for traffic handover are chosen near to the ideal cell
border.
The priority of the Handover-traffic reason is the last cause of evaluation: PBGT (Power
Budget Handover) is evaluated before Handover due to traffic.
The network initiated Handover-traffic reason may be performed only between cells
belonging to the same BSC; this restriction is introduced because it is impossible for the
serving BSC to control the channel occupancy of an adjacent cell belonging to another
BSC and because on the A interface the cause traffic reason is not foreseen. Due to the
fact that the triggering of the feature is related to traffic and that only BSC is informed
about channel occupation in its area, a functional splitting between BSC and BTS is
foreseen as it is described in the following.
The main benefits of this feature are:

the redistribution of traffic during busy hours;

avoiding a waste of resources;
a greater number of subscribers served;
avoiding the planning of new resources into a cell;
avoiding channel reservation into a cell for high traffic situation.

A typical traffic distribution for which Handover for traffic becomes very useful is shown
in Fig. 3.79.10

372

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig. 3.79.10Handover for Traffic

To manage the Handover for traffic reason some parameters are added in the BSS
system. The following tables show these attributes according to this rule:

Tab. 3.79.10 shows the parameters added to BSC object;

Tab. 3.79.11 shows the parameters added to HAND object;
Tab. 3.79.12 shows the parameters added to ADJC object.
BSC parameter

TRFCT (trafficControlTimer)

Purpose
Timer used to establish the period of time to
wait before evaluating the traffic level for each
BTS

Tab. 3.79.10 BSC object parameter used to manage Traffic Handover

HAND parameter
TRFHOE (trafficHandoverEnable)

Purpose
Used to enable or disable the feature in the
BTS.

Tab. 3.79.11 HAND object parameters used to manage Traffic Handover

A30808-X3247-L210-3-7619

373

OMN:BSC

Operation
Base Station Controller

HAND parameter

Purpose

TRFHITH (trafficHighThreshold)

Used to define the high traffic level threshold in

order to establish if the Handover for traffic
reason has to be enabled/disabled.

TRFLTH (trafficLowThreshold),

Used to define the low traffic level threshold in

order to establish if a cell can be a candidate to
receive Handover for traffic reason.

TRFMS (trafficMarginStep),

Used to establish the minimum reduction for

TRFHOM.

TRFMMA (trafficMarginMaximum),

Used to establish the maximum reduction for

TRFHOM.

TRFKPRI (trafficKeepPriority)

It is effective only when HCS is enabled and

determines whether candidate cells have to be
of the same priority as the serving cell
(TRFKPRI =TRUE) or may be of the same or
higher priority (TRFKPRI =FALSE).

TRFHOT (trafficHandoverTimer)

Timer used to establish the period of time to

wait before updating the m value. The m value
is increased if the handover for traffic reason is
enabled and decreased if the handover for
traffic reason is disabled, m is updated until it
reaches value 0

Tab. 3.79.11 HAND object parameters used to manage Traffic Handover

ADJC parameter

Purpose

BHOFOT (backHoForbiddenTimer)

Timer used to establish the time for

which a back handover due to traffic
reason or PBGT has to be avoided.

TRFHOM (trafficHandoverMargin)

Used to define the nominal cell border

between cells.

TRFHORXLVMOFF (trafficHoRxLevMinOffset)

It defines a neighbour cell specific level

offset that is added to RXLREVMIN of
that particular neighbour cell, during the
target cell list generation for traffic
handover.

Tab. 3.79.12ADJC object parameters used to manage Traffic Handover

The Traffic Handover Algorithm is spitted in three different phases. In the following this
three phases are examined.

374

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

1) BSC PROCEDURE DESCRIPTION

If the Handover-traffic reason function is enabled into a cell (TRFHOE parameter set to
TRUE), the procedure goes on through the steps described in the following:
1. the BSC starts the TRFCT timer for that cell;
2. at the expiry of the above timer, the traffic level is evaluated for that cell by the BSC;
if the percentage of busy TCHs is higher or equal to TRFHITH, then the cell is
regarded as a high traffic level one, otherwise it is regarded as a low traffic level one;
3. if there is a transition in the traffic level in respect to the previous evaluation, the BSC
sends, through O&M command, to the BTSE the indication that the handover due to
traffic reason has to be started/ended in the specific cell. The BTS has to acknowledge the command;
4. the procedure starts again from step 1.
Fig. 3.79.11 shows this procedure.

Start TRFCT timer

Timer TRFCT elapsed?

YES
Traffic level
calculation

Taffic level >= TRFHITH?

(High traffic level cell)

NO
YES

Previous calculated traffic

level < TRFHITH?
(Low traffic level cell)

YES

Previous calculated traffic

level > TRFHITH?
(High traffic level cell)

YES

NO
Send message to BTS
to enable Handover
for traffic execution

NO
Send message to BTS
to disable Handover
for traffic execution

Fig. 3.79.11BSC procedure

A30808-X3247-L210-3-7619

375

OMN:BSC

Operation
Base Station Controller

2) BTS Algorithm Description

When in the cell the start of handover due to traffic reason is invoked by the BSC, the
following steps are performed:
1. the TRFHOT timer is started;
2. a neighboring cell is included in the candidate list if:
In case of HCS enabled:
{[PRIO_LAYER(n)=PRIO_LAYER if TRFKPRI=TRUE] OR
[PRIO_LAYER(n)>=PRIO_LAYER if TRFKPRI=FALSE]}
AND
[RXLEV_NCELL(n) > RXLEV_MIN(n) + TRFHORXLVMOFF(n)+ max(0, Pa)]
AND
[PBGT(n) - TRFHOM(n) + K>0]
AND
[the adjacent cell is an intra-BSC cell]
In case of HCS disabled:
[RXLEV_NCELL(n) > RXLEV_MIN(n) + TRFHORXLVMOFF(n) + max(0, Pa)]
AND
[PBGT(n) - TRFHOM(n) + K>0]
AND
[the adjacent cell is an intra-BSC cell];

K is a dB value such that:

TRFMS <= K <=TRFMMA, and
K = m * TRFMS with m = 1, ..., TRFMMA / TRFMS

TRFHORXLVMOFF parameter is foreseen in order to make sure that a traffic handover

is only attempted towards those target cells that provide sufficient service quality conditions.
3. the neighboring cells included in the candidate list are ranked according to the
formula
PBGT(n) - TRFHOM(n).
Every time TRFHOT expires, the following procedure is followed:

376

If the handover due to traffic is still enabled m is increased by one and the procedure
is started again from step 1, until the BSC disables the function. (increasing m by
one means to favour the handover in the next step);

If the handover due to traffic is disabled by the BSC m is decreased by one and the
procedure is started again from step 1 (decreasing m by one means to obstruct the
handover in the next step). When m reaches 0 the BTS skips the handover due to
traffic part of the HO algorithm;

If later the BSC activates the function, the procedure starts again from step 1 (m is
set to 1).

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

3) BSC Handover Execution

When the candidate list is ready (point 3 of the previous section) the BTS sends to the
BSC an Inter-cell Handover Condition Indication message that includes the preferred list
of candidates and a new cause (traffic) for the handover request.
When the BSC receives the request, the list is analysed and the cells with
Traffic > TRFLTH
are discarded because this candidate cells are not low traffic ones (this control is applied
only if the handover cause is traffic).

When the user sets TRFHITH and TRFLTH values, the following condition:
TRFHITH-TRFLTH>=15
must be satisfied.
Fig. 3.79.12 shows this procedure.

BSC
receives the list

Traffic level < TRFLTH

for at least one cell?

Perform
the handover

Dont perform
the handover

Fig. 3.79.12BSC Handover execution

A back handover has to be avoided; in the CHANNEL ACTIVATION message sent to

the target cell, the identifier of the abandoned cell is specified and a new cause (traffic)
is indicated. In the target cell a back Handover for both traffic and PBGT reasons is
inhibited for a BHOFOT duration time.

A30808-X3247-L210-3-7619

377

OMN:BSC

Operation
Base Station Controller

When the flexible abis allocation strategy is used, if the Handover for Traffic for the
Radio Interface is enabled, it is also enabled taking into account the Abis Interface
situation (please refer to "3.40 Configuration of the Abis Interface").
Prerequisites
The Intercell Handover must be Enabled (INTERCH=TRUE).
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Choose the operation you want to do

h ... 2
h ... 8
h ... 4

Would you like to enable the Traffic Handover on a cell?

Would you like to disable the Traffic Handover on a cell?
Would you like to set any Traffic Handover parameter?

Enable the handover for Traffic on a cell

To enable Traffic Handover in a cell, the user must enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

----> SET HAND

Then the user must set to TRUE the value of the TRFHOE parameter (it belongs
to the BASICS group).
Result: The Handover for Traffic is enabled on the selected cell.

Situation
Would you like to set any Traffic Handover parameter?

Choose the parameter you want to change

Would you like to set any of the following attributes: TRFHOT, TRFKPRI,
TRFHITH, TRFLTH, TRFFMA, TRFMS?
Would you like to set any of the following attributes: TRFHOM, BHOFOT?
Would you like to set the TRFCT attribute?

378

Y h ... 4
N h ... END

h ... 5
h ... 6
h ... 7

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Change parameters

To change the value of any parameter of the list, the user must enter the SET
HAND command (BASICS group), following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

----> SET HAND

Result: the values of chosen parameters are changed.

h ... END

Change parameters

To change the value of any parameter of the list, the user must enter the SET
ADJC command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> ADJC

----> SET ADJC

Result: the values of chosen parameters are changed.

h ... END

Change the parameter value

To change the value of the selected parameter, the user must enter the SET
BSC command (BASICS group), following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BSC----> SET BSC

Result: the value of chosen parameter is changed.

h ... END

Disable the handover for Traffic on a cell

To disable Traffic Handover in a cell, the user must enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

----> SET HAND

Then the user must set to FALSE the value of the TRFHOE parameter.
Result: The Handover for Traffic is disabled on the selected cell.

END

A30808-X3247-L210-3-7619

379

OMN:BSC

Operation
Base Station Controller

3.80

Enabling Handover with Level HO Margin parameter

Introduction
When the Handover detection algorithms evaluate a handover condition, a target cell list
(i.e. a list of all adjacent cells which are handover candidates) is built. The target cell list
is based on the neighbor cell measurements of the MS. The minimum condition for being
candidate of the target cell list is defined in GSM 05.08 as follows:
RXLEV_NCELL(n) > RXLEV_MIN(n) + max (0,Pa)
where:

Pa = (MTXPWAX - P)
MTXPWAX is the maximum power an MS is permitted to use on a traffic channel of
an adjacent cell
P is the maximum power capability of the MS.

A meaningful RXLEV_MIN(n) setting is given with the following formula:

RXLEV_MIN(n) = X + L_RXLEV_XX_H,
where
3dBm < X <=6 dBm
This formula is quite useful concerning level, but implies a bad setting for quality HO.
Even if quality handover is mainly a protection against interference, not necessarily
linked to the received level, a quality handover to a cell with a similar (or even lower)
level may save an interfered call.
With the described algorithm, any type of handover requires a target cell with a level >
(L_RXLEV_XX_H + X), thus reducing the chances of saving an interfered call in poorly
covered (interference sensitive) areas.
So, a different algorithm can be used to better establish the target cell in poor coverage
areas. In these cases, it is available for level HO requirements. The target cell list is
based on the neighbor cell measurement of MS, and it uses the following algorithm:
RXLEV_NCELL(n) > RXLEV_DL + LHOMARGIN
AND
RXLEV_NCELL(n) > RXLEV_MIN(n) + MAX (0, (MTXPWAX-P))
The Level Handover Margin -LHOMARGIN- parameter (LEVHOM) allows to compare
levels received from the serving and from the target cells.
Fig. 3.80.13 and Fig. 3.80.14 show, for both good and poor coverage areas, the difference between the traditional solution (i.e. without LEVHOM parameter) and the solution
with the LHOMARGIN attribute, from the handover execution point of view.

380

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig. 3.80.13Handover in good coverage area

A30808-X3247-L210-3-7619

381

OMN:BSC

Operation
Base Station Controller

Fig. 3.80.14Handover in poor coverage area

382

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The implementation of both conditions (RXLEV_NCELL(n) > RXLEV_DL +

LHOMARGIN and RXLEV_NCELL(n) > RXLEV_MIN(n) + max (0, Pa)) represents a
very flexible solution since the operator has the possibility to handle two parameters
(RXLEVMIN and LHOMARGIN), so as to take the different requirements for level HO
and quality HO into consideration.
To manage this new feature two new attributes are used
1. ELEVHOM: it is related to the HAND object and it allows to enable/disable the
Handover alghoritm which make use of the Level Handover Margin parameter. This
attribute will be managed in the SET HAND command, its value will also be returned
in the response to the GET HAND command. If the flag is set to false (default:
disable) the traditional solution (RXLEV_NCELL(n) > RXLEV_MIN(n) + max (0,Pa))
is chosen.
2. LEVHOM (Level Handover Margin): it is related to the ADJC object, and it identifies
a threshold to guarantee a Handover to a target cell with a higher level than the
serving cell, without altering the behavior of the other Handover types. This attribute
will be managed in the CREATE/SET ADJC command, its value will also be returned
in the response to the GET ADJC command. The default value is 6dB.

Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Choose the operation you want to do

Would you like to enable the Handover which makes use of Level Handover
Margin parameter?

h ... 2

Would you like to disable the Handover which makes use of Level Handover
Margin parameter?

h ... 5

Would you like to set the Level Handover Margin parameter for an adjacent
relationship?

h ... 4

Enable the handover on a cell

To enable this Handover type in a cell, the user must enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

----> SET HAND

Then the user must set to TRUE the value of the ELEVHOM parameter:
Result: The Handover is enabled on the selected cell.

Situation
Would you like to set Level Handover Margin parameter too?

A30808-X3247-L210-3-7619

Y h ... 4
N h ... END
383

OMN:BSC

Operation
Base Station Controller

Change the LEVHOM value

To change this value, the user must enter the SET ADJC command, following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> ADJC

----> SET ADJC

h ... END

Result: the value of LEVHOM parameter is changed.

Disable the handover on a cell

To disable this Handover type on a cell, the user must enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

----> SET HAND

Then the user must set to FALSE the value of the ELEVHOM parameter:
Result: The Handover for Traffic is disabled on the selected cell.

END

384

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.81

OMN:BSC

Management of Fast Uplink Handover

Introduction
The Fast Uplink Handover (FUHO) can be used to avoid rapid uplink level loss in special
places with drop call problems, and to save connections in areas with sudden high traffic
load. With the fast uplink handover parameters it is possible to do the local fine tuning
of this handover type.
This behavior is more likely for GSM1800 systems than for GSM900 ones because
when the 1800 MHz band is used the diffraction effects are strongly reduced compared
to GSM900.
The uplink level loss, between MS and BS, occurs in less than 3 seconds, whereas the
normal handover triggering, with averaging windows, uses more than 4 seconds; so the
normal handover is too slow to avoid an uplink level loss. A moving MS will be lost
(uplink and therefore downlink information) at cell boundary or in shadowed areas.
E.G.: A mobile used in a car, waiting at red traffic light, books on an indoor base station
with flat antenna due to better level. After accelerating the car uplink level to indoor
equipment will be lost in about 50 meters. By using constant acceleration a speed of 15
m/s is likely to be reached after 3 s, i.e. time of full level loss will be about 3 seconds.
With this new feature the following improvements will be introduced:

the connections can be saved by using a Fast Uplink HandOver (FUHO), with trigger
time less than 3 seconds, to a predefined target cell. In the upper case the
predefined target cell of the indoor BTS could be the outdoor BTS;
another possibility of using FUHO is to define fast moving MS areas, like railways or
highways. In this case the target cell of a MS is known by at least 50%.

The Fast Uplink Handover can be classified as an imperative level handover with the
lowest priority. Tab. 3.81.13 shows an overview about the evaluated handover criteria
on SDCCH and TCH channels.
Handover
Criterion

Handover
Type

Evaluated
on TCH

Evaluated
on SDCCH

Priority
TCH

Priority
SDCCH

Extended Cell

Intracell

yes

no

Concentric Cell

Intracell

yes

no

Quality Intercell

Intercell

yes

yes

Level

Intercell

yes

yes

Distance

Intercell

yes

yes

Power Budget

Intercell

yes

yes

Quality Intracell

Intracell

yes

yes

Fast Uplink

Intercell

yes

yes

Forced

Intercell

yes

yes

Tab. 3.81.13Handover criteria

A30808-X3247-L210-3-7619

385

OMN:BSC

Operation
Base Station Controller

Neighbor cell bookkeeping for FUHO

The BTSE maintains a FUHO specific bookkeeping list for each possible adjacent cell
(up to 32 cells) in which the neighbor cell measurements of the MS, the downlink RXLEV
(RXLEV of serving cell measured by MS) and the BTSE transmit power are compiled
and averaged. This bookkeeping list is the basis for generation and sorting of the target
cell list for FUHO.
MS neighbor cell measurements contain up to six RXLEV samples of monitored BCCH
carriers and these samples are identified by BSIC and relative frequency number and
inserted n-times (dependent on weighting) into the corresponding RXLEV_NCELL
window. The value RXLEV 0 is entered into the remaining neighbor cells averaging
windows.
Fast Uplink handover Detection
The FUHO is performed independently of the capabilities of power control have been
exhausted (i.e. if the current transmit power of MS/BS has reached or not the maximum
value); still, as the FUHO deals with cases in which the signal is fading very rapidly, the
HO command is sent in downlink direction with the full power, in order to ensure its
reception at the MS. Even the MS transmit power is set to maximum if the conditions for
the FUHO are fulfilled; so, if for any reason the FUHO can not be performed, there is the
possibility that the connection is saved, if the signal was just weakened but does not
fade completely.
Handover detection is performed for uplink path, and it is based on comparison of the
raw uplink measurement received level (RXLEV_UL) with a threshold, defined by the
THLEVFUHO parameter.
The following conditions must be fulfilled for a FUHO detection:
1. the INTERCH attribute is set to TRUE (this attribute is not specific to FUHO feature,
but it is the general parameter used to enable an intercell handover);
2. the Fast Uplink Handover is enabled; to enable this handover type, the Enable Fast
Uplink Handover attribute (EFULHO) must be set to true;
3. the average value of RXLEV_UL, coming from the specific FUHO averaging window,
is smaller than the THLEVFULHO threshold (The size of the averaging window is
determined by ALEVFULHO attribute.)
Generation of the target cell list
When the HO detection algorithms evaluates a Fast Uplink handover condition a target
cell list is built; this list contains all the adjacent cells which are handover candidates.
The target cell list is based on the neighbor cell measurements of MS. The minimum
condition for being candidate of the target cell list is defined in GSM 05.08 as follows:
RXLEV_NCELL(n) > RXLEVMIN(n) + max (0,Pa) + FUHOMARGIN
where the FUHOMARGIN parameter is used to select only target cell for FUHO (in the
BSS implementation this attribute is called FULRXLVMOFF)
The way the FUHO target cell list is generated is as follows:

386

only the target cells who fulfil the minimum criteria are taken into account.

two sublists are build: the first (higher priority) contains cells marked as predefined
cells, the second (lower priority) regards cells not defined as predefined cells. The

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

predefined selection is indicated with the adjacent cell parameter FULHOC; it can
assume the values:
TRUE, i.e. the target cell is a predefined one
FALSE, i.e. the target cell is not a predefined one

sorting within the sublist is done according to the Power Budget criteria

As it was described, to manage Fast Uplink Handover some parameters are added in
the BSS system. The following tables show these attributes according to this rule:

Tab. 3.81.14 shows the parameters added to HAND object;

Tab. 3.81.15 shows the parameters added to ADJC object;

HAND parameter

Purpose

EFUHLO (EnableFUHO)

It is a flag used to enable/disable the Fast

Uplink Handover, that is started when the
FUHO algorithm is activated by BTS.

THLEVFULHO (ThresholdLevFUHO)

It is a threshold level for the Fast Uplink

Handover. The FUHO can be started when the
average of the uplink reception level (RXLVUL)
is less than this threshold:

ALEVFULHO (AveragedLevFUHO), It defines two averaging parameters for FUHO

signal strength measurements, used for fast
uplink handover decision.
The first field aLevFuHo defines the averaging window size (that is smaller than the
normal window size), the second one wLevFuHo indicates the averaging weighting
factor.
Tab. 3.81.14 HAND object parameters used to manage Traffic Handover

ADJC parameter
FULHOC (FUHOCell)

Purpose
This attribute indicates whether the adjacent cell is a predefined "Fast Uplink
Handover cell. When searching a target
cell for a Fast Uplink Handover, cells that
have the attribute fastULHoCell set to
TRUE will be preferred to cells that have
this attribute set to FALSE

Tab. 3.81.15ADJC object parameters used to manage Traffic Handover

A30808-X3247-L210-3-7619

387

OMN:BSC

Operation
Base Station Controller

ADJC parameter
FULRXLVMOFF (FUHOMargin)

Purpose
The value of this attribute is used to
select a target cell for fast uplink
handover.

Tab. 3.81.15ADJC object parameters used to manage Traffic Handover

Prerequisites
The Intercell Handover must be Enabled (INTERCH=TRUE).
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Choose the operation you want to do

h ... 2
h ... 7
h ... 4

Would you like to enable the Fast Uplink Handover on a cell?

Would you like to disable the Fast Uplink Handover on a cell?
Would you like to set any Fast Uplink Handover parameter?

Enable Fast Uplink Handover on a cell

To enable Fast Uplink Handover on a cell, the user must enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

----> SET HAND

Then the user must set to TRUE the value of the EFULHO parameter:
Result: the Fast uplink handover is enabled on the selected cell. To make active
this handover type, the Intercell Handover must be enabled.

Situation

Y h ... 4
N h ... END

Would you like to set any Fast Uplink Handover parameter?

388

Choose the parameter you want to change

Would you like to set one of the following attributes: THLEVFULHO, ALEVFULHO?

h ... 5

Would you like to set one of the following attributes:FULHOC, FULRXLVMOFF?

h ... 6

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Change parameters

To change the value of any parameter of the list, the user must enter the SET
HAND command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

----> SET HAND

Result: the values of chosen parameters are changed.

h ... END

Change parameters

To change the value of any parameter of the list, the user must enter the SET
ADJC command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> ADJC

----> SET ADJC

Result: the values of chosen parameters are changed.

h ... END

Disable the Fast Uplink Handover on a cell

To disable Fast Uplink Handover on a cell, the user must enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

----> SET HAND

Then the user must set to FALSE the value of the EFULHO parameter:
Result: The Fast Uplink Handover is disabled on the selected cell.

END

A30808-X3247-L210-3-7619

389

OMN:BSC

Operation
Base Station Controller

3.82

Enabling handover from UMTS to GSM

Introduction
When a circuit switched call (voice and data) has been established by a user in the
UMTS network, the handover from UMTS to GSM must be handled to avoid call drops
when the user moves from the UMTS to the GSM system. In particular, this handover
feature is very important in the early UMTS introduction phase, when the UMTS system
covers relatively small areas only (so called "UMTS islands").
This procedure allows to enable the circuit switched handover from the UMTS network
to the GSM one.
From the BSC and the BTS point of view, the UMTS to GSM handover is mainly
performed as a normal MSC controlled handover of the GSM system; then only few new
BSC/BTS functionalities are required.

This procedure regards only handover from UMTS to GSM: handover in the opposite
direction is described in "3.84 Enabling Handover from GSM to UMTS".
The architecture of the UMTS/GSM network is shown in Fig. 3.82.15.

3G_MSC
MSC

U-MSC

A
BSC
Abis
BTS

MS/UE

Iu
RNC
Iub
NodeB

MS/UE

Fig. 3.82.15 UMTS/GSM network architecture

The 3G_MSC supports the Iu interface towards the RNC (UMTS) and the A interface
towards the BSC (GSM).
The following main steps are executed during the handover procedure:
1. when the UMTS equipment, currently supporting the MS/UE, determine that the MS
must be handed over to the GSM network, they send the handover request to the
3G_MSC; the request contains a single GSM cell over which the MS shall be redirected;

390

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

2. when the 3G_MSC receives the handover request, it begins the process of handing
over the UE/MS to the BSS; the 3G_MSC sends the A-HANDOVER REQUEST
message to the BSC;
3. the BSC then executes the necessary actions to allow the MS/UE to access the BSS
resources; in particular the BSC must check if the BTS equipment supports the 64
bits GSM ciphering key, which is used in the GSM system after an handover from
the UMTS network (see below);
4. when the BSS has allocated resources for the MS/UE, it returns the A-HANDOVER
REQUEST ACK message to the BSC; in this message the BSC includes the Cipher
Mode Setting IE, that informs the MS about the ciphering algorithm that it must use
in the GSM network (this algorithm is different from the algorithm used in the UMTS
network, see below);
5. the command to execute the handover is sent to the MS/UE that will access the GSM
network;
6. when the MS has accessed the GSM network, the resources on the UMTS network
are released.
The intersystem handover from UMTS to GSM implies a change of the ciphering algorithm from the UMTS UEA algorithm to the GSM A5 algorithm. Then, the 3G_MSC,
when receives the handover request from the UMTS network, converts the 128 bits
UMTS cipher key into the 64 bits GSM cipher key.
When the 3G_MSC sends the A-HANDOVER REQUEST message to the BSC, the
3G_MSC informs the BSC about the 64 bits GSM cipher key, which is the result of the
UMTS to GSM cipher key conversion.
64 bits cipher keys are not supported by the BTS1 Siemens Base Transceiver Station
equipped with BBSIG (Base Band and Signalling) boards; these boards only support
cipher keys with up to 54 bits and therefore dont support ciphering after UMTS to GSM
handover. The BTS successor model, i.e. BTS1 with the newer BBSIG44 board does
support 64 bits cipher keys.
The following BTS equipment:

BTS+;
picoBTS;
eMicroBTS

dont contain BBSIG boards, and they always support the 64 bits cipher key (and then
they always support the handover from UMTS to GSM).
There exists an attribute (flag) in the BSC software which allows the BSC to distinguish
between a BTS1 which contains only BBSIG44 and a BTS1 which contains a mixture of
BBSIG and BBSIG44. This flag is called PUREBBSIG44CONF (BTS object) and the
setting is as follow:

A30808-X3247-L210-3-7619

BTS1 with mixed BBSIG-BBSIG44 boards: PUREBBSIG44CONF set to FALSE;

BTS1 with only BBSIG44 boards: PUREBBSIG44CONF set to TRUE.

391

OMN:BSC

Operation
Base Station Controller

In BR5.5 this flag was already used and set by the operator in order to differentiate
between a BTS1 which supports 14.4 kbit/s and a BTS1 which does not support 14.4
kbit/s (because the BBSIG does not support data rates of 14.4 kbit/s whereas the
BBSIG44 supports 14.4 kbit/s); in BR5.5 it was called BTSSUPP145.
This flag is re-used for Handover from UMTS to GSM. Since in the context of 64 bit
ciphering the name BTSSUPP145 might be confusing for the operator, the name of the
flag is changed from BTSSUPP145 to PUREBBSIG44CONF as mentioned above.
When the BSC receives the A-HANDOVER REQUEST message from the 3G_MSC
(that contains the 64 bits GSM cipher key to be used), the BSC checks the length of the
cipher key. If the BSC cipher key length check results in "length = 8 bytes", then the BSC
checks the value of the PUREBBSIG44CONF attribute. Then:

if this flag is set to FALSE (i.e. BTS1 does not support 64 bit ciphering because it
contains a mixture of BBSIG44 and BBSIG), the BSC shall not send the message
A-HANDOVER REQUEST ACK message, but instead shall send the HANDOVER
FAILURE message with cause "ciphering algorithm not supported" to the 3G_MSC;

if this flag is set to TRUE (i.e. BTS1 supports 64 bit ciphering because it only
contains BBSIG44), the handover can be performed and the BSC shall send the
message A-HANDOVER REQUEST ACK message;

If the BSC cipher key length check results in "length = 7 bytes or smaller" (i.e. in case of
traditional GSM calls), the current BSC software behavior is not changed: the BSC
checks the PUREBBSIG44CONF flag only in case of 14.4 kbit/s data calls because they
are not supported by BBSIG; the BSC shall not check the PUREBBSIG44CONF flag for
other calls which are supported by BBSIG (e.g. 9.6 kbit/s data calls, speech calls) in
order not to block today GSM-system-internal handovers which use a cipher key length
of 54 bits (which is supported by BBSIG).
To summarize, if the user wants to enable BTS1 equipment to support handovers from
UMTS to GSM, first he must equip them with BBSIG44 boards only, then he has to set
the PUREBBSIG44CONF attribute to TRUE.
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Check the BTS equipment type

Does the BTS equipment belong to the BTS1 family?
Does the BTS equipment belong to the BTSplus family?

Preliminary consideration
Does the equipment contain BBSIG44 boards only?

392

h ... 2
h ... 5
Y h ... 3
N h ... 4

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Enable the handover

To enable Handover from UMTS to GSM, the user must enter the SET BTS
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

Then the user must set to TRUE the value of the PUREBBSIG44CONF parameter.
Result: the incoming handovers from the UMTS network are enabled for the
involved GSM cell.

h ... END

Set the PUREBBSIG44CONF attribute to FALSE

Since in this case handovers from UMTS are not possible, the user must enter
the SET BTS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

SET BTS

Then the user must set the PUREBBSIG44CONF attribute to FALSE.

h ... END

No setting is necessary

With BTSplus family, there arent any problems: using these equipments,
handovers from UMTS network are always allowed.

END

A30808-X3247-L210-3-7619

393

OMN:BSC

Operation
Base Station Controller

3.83

Enabling GSM-UMTS cell Re-selection

Introduction
With the introduction of the UMTS network, it becomes very important to allow a dual
mode mobile station to re-select an UMTS cell starting from a GSM one.
Without this feature, if once a dual mode GSM/UMTS terminal is camped on the GSM
network, it would stay there forever. To allow this feature, the UMTS adjacent cell information is sent on the broadcast carrier of the GSM network, to inform the UE/MS which
frequencies have to be monitored for re-selection purposes.
Two different algorithms to reselect an UMTS cell FDD or TDD) starting from the GSM
network are defined, according to the type of service the MS supports; so we can have:
1. re-selection of the UMTS cell in case of circuit switched modality;
2. re-selection of the UMTS cell in case of packed switched modality (GPRS/EGPRS).
In the following, the two cases are briefly discussed.
1) GSM-UMTS re-selection algorithm: circuit switched case.
The MS performs a cell reselection to an adjacent UMTS (FDD or TDD) cell if:
for the serving cell:
RSCP(UTRAN cell) >= RLA_C_s + XXX_Qoffset
for all of the suitable GSM neighboring cells
RSCP(UTRAN cell) >= RLA_C_n + XXX_Qoffset
and also (only for FDD cells):
Ec/No (UTRAN FDD cell) >= FDD_Qmin
where:

RSCP (Received Signal Code Power): it is the power level received from the UMTS
cell;
Ec/No: it is the signal/noise ratio;
RLA_C_s: it is the power level received from the serving cell;
RLA_C_n: it is the power level received from the neighboring cells;
XXX_Qoffset: offset for cell reselection for UMTS cells. The user sets this value by
the FDDQO parameter (BTS object) for FDD cells, or by the TDDQO parameter
(BTS object) for TDD cells;
FDD_Qmin: minimum threshold for Ec/No for UMTS FDD cell re-selection; the user
sets this value by the FDDQMI parameter of the BTS object;

There is also a threshold by which the network indicates whether the measurements for
the cell reselection of the UMTS cells should be performed or not; the threshold indicates if the signal level of the serving cell should be below or above it, in order to perform
UMTS cells measurements; the user sets this value by the QSRHI parameter of the BTS
object.
2) GSM-UMTS re-selection algorithm: packet switched case.
The MS performs a cell reselection to an adjacent UMTS cell if:

394

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

for the serving cell:

RSCP(UTRAN cell) >= RLA_P_s + XXX_GPRS_Qoffset
for all of the suitable GSM neighboring cells
RSCP(UTRAN cell) >= RLA_P_n + XXX_GPRS_Qoffset
and also (only for FDD cells):
Ec/No (UTRAN cell) >= FDD_Qmin
where:

RSCP (Received Signal Code Power): it is the power level received from the UMTS
cell;
Ec/No: it is the signal/noise ratio;
RLA_P_s: it is the power level received from the GPRS serving cell;
RLA_P_n: it is the power level received from the neighboring cells;
XXX_GPRS_Qoffset: offset for cell reselection for UMTS cells. The user sets this
value by the FDDGQO parameter (PTPPKF object) for FDD cells, or by the
TDDGQO parameter (PTPPKF object) for TDD cells;
FDD_Qmin: minimum threshold for Ec/No for UMTS FDD cell re-selection; the user
sets this value by the FDDQMI parameter of the BTS object.

There is also a threshold by which the network indicates whether the measurements for
the cell reselection of the UMTS cells should be performed or not; the threshold indicates if the signal level of the serving cell should be below or above it, in order to perform
UMTS cells measurements; the user sets this value by the QSRHPRI parameter of the
PTPPKF object.
Besides defining the re-selection criteria, the user must also define the UMTS neighboring cells to be re-selected. To define an UMTS neighboring cell for a specific BTS
object instance, the user create an instance of the ADJC3G object (subordinated to the
BTS one, see "3.68 Addition of a UMTS Adjacent Cell").
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Choose the operation you want to do

Would you like to set re-selection parameters (circuit switched case, FDD
cells)?

h ... 2

Would you like to set re-selection parameters (packet switched case, FDD
cells)?

h ... 4

A30808-X3247-L210-3-7619

395

OMN:BSC

Operation
Base Station Controller

Set re-selection parameters (circuit switched case)

The user must enter the SET BTS command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS

Then the user can set the following attributes:

QSRHI;
FDDQO;
TDDQO;
FDDQMI.
Result: Re-selection parameters are set.

Situation
Do you want to set re-selection parameters related to the packet switched case
too?

Y h ... 4
N h ... END

Set re-selection parameters (packet swithced case) in the PTPPKF object

The user must enter the SET PTPPKF command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF

Then the user can set the following attributes:

QSRHPRI;
TDDGQO;
FDDGQO.
Result: Re-selection parameters are set.

Set re-selection parameters (packet switched case) of the BTS object

The user must enter the SET BTS command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS

Then the user can set the FDDQMI attribute..

.
Result: Re-selection parameters are set.

END

396

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.84

OMN:BSC

Enabling Handover from GSM to UMTS

Introduction
This procedure allows to enable the circuit switched handover from the GSM network to
the UMTS one (both for FDD and TDD technologies).
The customer benefit of this feature is that a circuit switched (CS) call (voice and data)
which was started in the GSM system can be handed over to the UMTS system.
The following handover types from GSM to UMTS are considered:

Better Cell Handover (Power Budget Handover);

Sufficient UMTS Coverage;

Imperative Handovers (quality, level distance);

Mobile Speed Sensitive Handover;

Forced Handover (directed retry).

This procedure regards only handover from GSM to UMTS: handover in the opposite
direction is described in "3.82 Enabling handover from UMTS to GSM".
The architecture of the UMTS/GSM network is shown in Fig. 3.84.16.

3G_MSC
MSC

U-MSC

A
BSC
Abis
BTS

MS/UE

Iu
RNC
Iub
NodeB

MS/UE

Fig. 3.84.16 UMTS/GSM network architecture

The 3G_MSC supports the Iu interface towards the RNC (UMTS) and the A interface
towards the BSC (GSM).
The following main steps are executed during the handover procedure:
1. when the BSS equipment, currently supporting the MS/UE, determines that the MS
must be handed over to the UMTS network, it sends the A-HANDOVER REQUIRED
message to the 3G_MSC; the request contains a single UMTS cell over which the
UE/MS shall be re-directed;

A30808-X3247-L210-3-7619

397

OMN:BSC

Operation
Base Station Controller

2. when the 3G_MSC receives the A-HANDOVER REQUIRED message, it begins the
process of handing over the UE/MS to a new RNS; the 3G_MSC sends the IuRELOCATION REQUEST message to the selected RNS;
3. the RNS then executes necessary actions to allow the MS/UE to access its
resources; once the resource allocation has been completed by RNS-B, it returns
an Iu-RELOCATION-REQUEST-ACK to 3G_MSC;
4. when the Iu-RELOCATION-REQUEST-ACK is received by 3G_MSC, it begins the
process of instructing the UE to tune to a new dedicated radio resource. An AHANDOVER-COMMAND is sent by the 3G_MSC to the BSS;
5. on receipt of the A-HANDOVER-COMMAND message, the BSS sends the radio
interface message RI-HANDOVER-COMMAND. The UE will then access the new
radio resource;
6. after the UE/MS has performed an access to the UMTS target cell, on detection of
the UE/MS, the RNS sends an Iu-RELOCATION-DETECT to 3G_MSC;
7. when the UE is successfully communicating with the RNS, an RRC-HANDOVERCOMPLETE message is sent by the UE to RNS;
8. the RNS then sends an Iu-RELOCATION-COMPLETE message to 3G_MSC;
9. after 3G_MSC has received the Iu-RELOCATION-COMPLETE message from RNS,
it begins to release the resources allocated on BSS. The resource is released by
using the A CLEAR-COMMAND sequence; the 3G_MSC sends the "A-ClearCommand" message to the BSS as during a normal MSC-controlled GSM-systeminternal handover;
10. finally, the BSS sends the "A-CLEAR-COMPLETE" message to the 3G_MSC as
during a normal MSC-controlled GSM-system-internal handover.
The BTS initiates a handover from GSM to UMTS (inter-system handover) in the same
way as for GSM-internal handovers.
The first thing the operator has to do, is to enable (in general) handovers from GSM to
UMTS on a cell basis. To enable, for a GSM cell, handovers towards the UMTS network,
the EUHO (Enable UMTS handover) parameter (HAND object) must be set to TRUE.
After that the operator can enable different handover types according to his needs.
In the following it is described how the user can configure these handover types:
a) Better Cell Handover (Power Budget Handover);
b) Sufficient UMTS Coverage;
c) Imperative Handovers (quality, level distance);
d) Mobile Speed Sensitive Handover;
e) Forced Handover (directed retry).
A) BETTER CELL HANDOVER (Power-Budget HO)
The main objective of the "Better cell HO" (Power-Budget HO) is to minimize the RF
power needed for communication between the mobile station MS/UE and the network
(base station). Minimizing the RF power is very important both for reducing the radio
interference in the whole network and for increasing the battery life of the MS/UE.
Once the user has enabled handovers from GSM to UMTS using the EUHO parameter,
he can enable the power budget handover to UMTS by the EUBCHO parameter(Enable
UMTS Better Cell)

398

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The "better cell HO" algorithm which is already used for GSM-system-internal
handovers is re-used for the "better cell HO" from GSM to UMTS.
The Power Budget (PBGT), which compares the serving cell downlink received level
(RXLEV_DL) and the neighbor cell received level (RXLEV_NCELL), is defined as
follows:
PBGT :=

[ Min(MS_TXPWR_MAX(s), P(s)) - RXLEV_DL - PWR_C_D ]

- [ Min(MS_TXPWR_MAX(n), P(n)) - RXLEV_NCELL(n) ]

where:

RXLEV_NCELL(n) is the neighbour cell received level (GSM or UMTS neighbour

cell) measured by the MS/UE;
RXLEV_DL is the GSM serving cell received level (downlink) measured by the
MS/UE;
PWR_C_D is the difference between the maximum downlink RF power permitted in
the GSM serving cell, and the actual downlink power due to the downlink power
control;
RXLEVMIN(n) defines the minimum received level which is required to perform a
handover to the neighbour cell (GSM or UMTS neighbour cell). To define this value
for an adjacent UMTS cells, the user must configure the RXLEVMINC parameter of
the ADJC3G object;
MS_TXPWR_MAX(s) is the maximum RF TX power a MS/UE is permitted to use on
a traffic channel in the GSM serving cell; this value is the same as used for intraGSM power budget handovers and it can be defined, e.g. for a GSM900 cell, by the
MSTXPMAXGSM parameter of the BTS object;
MS_TXPWR_MAX(n) is the maximum RF TX power a MS/UE is permitted to use in
the neighbour cell (GSM or UMTS neighbour cell). To define this value for an adjacent UMTS cells, the user must configure the MSTXPMAXUMTS parameter of
either the TGTFDD object (if the neighboring cell is a UMTS FDD one) or the
TGTTDD object (if the neighboring cell is a UMTS TDD one);
P(s) is the maximum TX power capability of the MS/UE in the GSM serving cell;
P(n) is the maximum TX power capability of the MS/UE in the neighbour cell (GSM
or UMTS neighbour cell).

For a "Better cell HO"(Power-Budget HO), the BTS shall include an UMTS neighbour
cell into the target cell list if the following three conditions are met:
1. PRIO_PBGT > 0
with the definition PRIO_PBGT := PBGT - HOMARGIN - UMTS_ADJUST
2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max (0, Pa)
with the definition Pa := (MS_TXPWR_MAX(n) - P(n))
where:

A30808-X3247-L210-3-7619

HOMARGIN(n) is a threshold which can be used to prevent handover oscillations

between the serving GSM cell and neighbour cells (GSM or UMTS neighbour cell).
To define this value for an adjacent UMTS cells, the user must configure the HOM
parameter of the ADJC3G object;

399

OMN:BSC

Operation
Base Station Controller

UMTS_ADJUST(n) is a parameter which is introduced for GSM to UMTS handover

(and not used for GSM to GSM handover). It is an inter-system adjustment parameter in order to have the flexibility to adjust the RXLEV_NCELL(n) of the UMTS
neighbour cells (n) to the RXLEV_DL of the GSM serving cell. To define this value
the user must configure the UADJ parameter of the ADJC3G object.

For UMTS neighbouring cells (n), the UMTS measurement quantity RSCP is used for
RXLEV_NCELL(n).

The UMTS FDD measurement quantity Ec/No is not a suitable parameter for a
comparison with the GSM received level because the Ec/No is a quality parameter and
not a received level parameter.Therefore, Ec/No can not be used for the "Better cell
HO" (Power-Budget HO) from GSM to UMTS.
As consequence, the FDDREPQTY parameter (FDD_REP_QUANT), which tells the
MS/UE whether to report RSCP (FDD_REP_QUANT = 0) or Ec/No
(FDD_REP_QUANT = 1), must be set to RSCP if the "Better cell HO" (Power-Budget
HO) from GSM to UMTS shall be used.
If the FDDREPQTY parameter is set to 1=EC_NO by the operator, Power Budget
handover from GSM to UMTS is automatically disabled by BTS, and UMTS neighboring cells are not considered for the power budget handover.

In addition to conditions 1. and 2., if a Hierarchical Cell Structure (HCS) is enabled, the
following last condition must be fulfilled for a power budget handover:
3. PRIO_NCELL <= PL
where:

PL is the HCS priority value of the GSM serving cell; this value is the same as used
for intra-GSM power budget handovers and it can be defined by the PL parameter
of the BTS object;
PRIO_NCELL is the HCS priority value of the neighbour cell (GSM or UMTS neighbour cell). To define this value for an adjacent UMTS cells, the user must configure
the PLNC parameter of the ADJC3G object.

In order to perform the handover, the HCS priority of the neighbour cell must be equal
to or higher than the priority of the GSM serving cell; i.e. the priority value PRIO_NCELL
of the neighbour cell must be equal to or smaller than the priority value PL of the GSM
serving cell.
B) SUFFICIENT UMTS COVERAGE HANDOVER
The main objective of the GSM to UMTS "Sufficient UMTS coverage" handover is to
perform a handover to the UMTS system as soon as possible, i.e. as soon as the UMTS
measurement quantity (RSCP or Ec/No for FDD cells, RSCP for TDD cells) exceeds a
certain "sufficient" threshold. So, this handover type is used to direct as much traffic as
possible to areas which offer "sufficient" UMTS coverage.
Therefore, the execution of the "Sufficient UMTS coverage handover shall have a
higher priority than the Power-Budget handover; i.e. if the conditions of both handover
types are fulfilled simultaneously, the "Sufficient UMTS coverage" handover shall be
executed.

400

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Once the user has enabled handovers from GSM to UMTS using the EUHO parameter,
he can enable the Sufficient UMTS coverage handover to UMTS by the EUSCHO para
meter (Enable UMTS Sufficient Coverage Handover) .
For a "Sufficient UMTS coverage" HO from GSM to UMTS, the BTS compares the
RXLEV_NCELL(n) of the UMTS neighbour cell (n) with a "sufficient" threshold
UMTS_SUFFICIENT(n), then the BTS shall include an UMTS neighbour cell into TCL if
the following condition is met:
RXLEV_NCELL(n) > UMTS_SUFFICIENT(n) + Max (0, Pa)
with the definition Pa := (MS_TXPWR_MAX(n) - P(n))
The "sufficient" threshold UMTS_SUFFICIENT(n) depends on the UMTS measurement
quantity as described below:

for UMTS TDD cells, the UMTS measurement quantity RSCP is reported by the
MS/UE to the BTS;

for UMTS FDD cells, the FDDREPQTY parameter (FDD_REP_QUANT) tells the
MS/UE whether to report the RSCP value (FDDREPQTY=RSCP) or the Ec/No
(FDDREPQTY=EC_NO).
So, this parameter can be used by the operator in order to select whether the UMTS
FDD measurement quantity RSCP or the Ec/No shall be used for the "Sufficient
UMTS coverage" handover from GSM to UMTS.

Therefore regarding UMTS_SUFFICIENT(n) value, the following considerations can be

done:
a) TDD cell: if the neighboring cell is a TDD one, the user defines the
UMTS_SUFFICIENT(n) value using the USRSCP parameter of the ADJC3G object;
b) FDD cell: if the neighboring cell is a FDD one two cases exist:
if FDDREPQTY=RSCP, the user defines the UMTS_SUFFICIENT(n) value using
the USRSCP parameter of the ADJC3G object (as in case of TDD cells);
if FDDREPQTY=EC_NO, the user defines the UMTS_SUFFICIENT(n) value
using the USECNO parameter of the ADJC3G object.
Regarding the condition that triggers a Sufficient UMTS coverage handover, the
following considerations can also be done:

A30808-X3247-L210-3-7619

RXLEV_NCELL(n) contains the neighbour cell measurement quantity (received

level for GSM cells; RSCP or Ec/No for UMTS FDD cells; RSCP for UMTS TDD
cells);
MS_TXPWR_MAX(n) is the maximum RF TX power a MS/UE is permitted to use in
the neighbour cell. To define this value for UMTS adjacent cells, the user must
configure the MSTXPMAXUMTS parameter of either the TGTFDD object (if the
neighboring cell is a UMTS FDD one) or the TGTTDD object (if the neighboring cell
is a UMTS TDD one);
P(n) is the maximum TX power capability of the MS/UE in the neighbour cell.

401

OMN:BSC

Operation
Base Station Controller

C) IMPERATIVE HANDOVER
The "imperative" HO from GSM to UMTS is sometimes also called "emergency" HO
because it is necessary to maintain a call.An "imperative" HO is initiated e.g. because
for the GSM serving cell the received level is too low or the quality is too low or the MSBTS distance is too large. The initiation of "imperative" handovers is not changed with
the introduction of GSM to UMTS Handover, i.e. the BTS shall initiate "imperative"
handovers in the same way as for a GSM-internal handover.The following imperative
HO causes from GSM to UMTS are foreseen:

uplink quality (when the uplink quality of the serving GSM cell is low, this handover
condition is verified);
downlink quality (when the downlink quality of the serving GSM cell is low, this
handover condition is verified);
uplink strength (when the uplink received level of the serving GSM cell is low, this
handover condition is verified);
downlink strength (when the downlink received level of the serving GSM cell is low,
this handover condition is verified);
distance (when the distance from the MS/UE to the BTS is too much high, this
handover condition is verified).

When one of the previous causes is verified, the related imperative handover is triggered.
For an imperative handover, the BTS includes a UMTS neighbour cell into the target cell
list (i.e. in the list of the possible target cells of the handover) if the following condition
are met:
RXLEV_NCELL(n) > RXLEVMIN(n) + Max (0, Pa)
for both FDD cells (if FDDREPQTY=RSCP) and TDD cells:

RXLEV_NCELL(n) > UMTS_MIN_Ec/No(n) + Max (0, Pa)

for FDD cells (if FDDREPQTY=EC_NO):
NOTE: as it has been already described, Pa := (MS_TXPWR_MAX(n) - P(n))
Regarding the condition that is used to include UMTS neighbour cells into the target cell
list in case of imperative handovers, the following considerations can be done:

402

RXLEV_NCELL(n) contains the neighbour cell measurement quantity (received

level for GSM cells; RSCP or Ec/No for UMTS FDD cells; RSCP for UMTS TDD
cells);
MS_TXPWR_MAX(n) is the maximum RF TX power a MS/UE is permitted to use in
the neighbour cell (GSM or UMTS neighbour cell). To define this value for an adjacent UMTS cells, the user must configure the MSTXPMAXUMTS parameter of
either the TGTFDD object (if the neighboring cell is a UMTS FDD one) or the
TGTTDD object (if the neighboring cell is a UMTS TDD one);
P(n) is the maximum TX power capability of the MS/UE in the neighbour cell;

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

the UMTS_MIN_Ec/No parameter defines the minimum Ec/No threshold which is

required to include a UMTS FDD cell into the TCL in case of an "imperative" HO (this
parameter is only used for UMTS FDD cells and only in case of
FDDREPQTY=EC_NO). The operator can set its value using the UMECNO parameter of the ADJC3G object.

Once the user has enabled handovers from GSM to UMTS using the EUHO parameter,
he can enable imperative handovers to UMTS by the EUIMPHO (Enable UMTS Imperative Handover) parameter.
D) MOBILE SPEED SENSITIVE HANDOVER
The aim of the Mobile Speed Sensitive Handover is to perform a handover to small cells
(e.g. microcells or picocells) only for "slow moving" and not for "fast moving" mobile
stations.
Within the current concept of "Mobile Speed Sensitive HO", a timer of duration HOMDTIME is used to distinguish between "fast moving" and "slow moving" mobile stations.
The timer is started when the MS/UE crosses the border of the small neighbor cell.
If the MS/UE leaves the cell within HOMDTIME, the MS/UE is considered to be "fast
moving". If the MS/UE is still located within the cell after duration HOMDTIME, the
MS/UE is considered "slow moving".
So, Mobile Speed Sensitive Handover is a special kind of handover regarding:

Power budget handover;

Sufficient UMTS coverage handover.

In both cases,to enable the speed sensitive handover towards an UMTS cell (cell B),
starting from a GSM one (cell A), the user must set to true the MICROCELL parameter
in the ADJC3G object instance, that represents the neighboring relationship from cell A
to cell B.
In case of Power Budget handover, the HOMDTIME timer is started, when the conditions that trigger a Power Budget handover to a neighboring cell (see above) are met,
i.e. when:
1. PRIO_PBGT > 0
with the definition PRIO_PBGT := PBGT - HOMARGIN - UMTS_ADJUST
2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max (0, Pa)
with the definition Pa := (MS_TXPWR_MAX(n) - P(n))
The HOMDTIME timer is stopped when one of the two previous conditions is not met
any more (i.e. the "fast moving" MS/UE has left the cell).
Within the concept of "Mobile Speed Sensitive HO", the Power-Budget HO is penalized
for t < HOMDTIME by adding a penalization value HOMSOFF to the Power-Budget
equation and by substituting the HCS cell priority PRIO_NCELL to a low value defined
by PPLNC.
So, when the timer is running, the condition to execute a power budget handover
becomes:

A30808-X3247-L210-3-7619

403

OMN:BSC

Operation
Base Station Controller

1. PRIO_PBGT > 0
with the definition PRIO_PBGT := PBGT- (HOMARGIN + HOMSOFF
+UMTS_ADJUST)
2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max (0, Pa)
with the definition Pa := (MS_TXPWR_MAX(n) - P(n))
After timer expiry, i.e. for t >= HOMDTIME, the above Power Budget penalization is
compensated with HOMDOFF and the HCS cell priority of the neighboring cell
(PRIO_NCELL) is set back to the original value defined by PLNC (i.e. a handover is
possible for the "slow moving" MS/UE). So the condition to execute a power budget
handover becomes:
1. PRIO_PBGT > 0
with the definition PRIO_PBGT := PBGT - (HOMARGIN + HOMSOFF - HOMDOFF +
UMTS_ADJUST)
2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max (0, Pa)
with the definition Pa := (MS_TXPWR_MAX(n) - P(n))
To manage speed sensitive handover in case of power budget handover the parameter
shown in Tab. 3.84.16 have to be defined. All these parameters must be defined in the
ADJC3G object instance the identifies the neighboring relationship from the GSM cell
(departure cell) to the UMTS one (target cell); see "3.68 Addition of a UMTS Adjacent
Cell".
Parameter

Meaning

MICROCELL

Only if this parameter is set to true the speed sensitivity handover algorithm will be in effect for this
neighbour cell.

HOMDTIME

It specifies the time an immediate handover request

is delayed.

HOMSOFF

It specifies the static offset by which the handover

margin is increased as long as the timer HOMDTIME runs.

HOMDOFF

It specifies the dynamic offset by which the

handover margin is reduced after expiry of the
HOMDTIME timer.

PPLNC

It determines the temporary priority layer of the

adjacent UMTS cell, when the HOMDTIME timer is
running.

Tab. 3.84.16Speed Sensitive Handover Parameters in Case of Power Budget Handover

In case of "Sufficient UMTS coverage" handover,the HOMDTIME timer is started,
when the condition that triggers this kind of handover (see above) is met, i.e. when:

404

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

RXLEV_NCELL(n) > UMTS_SUFFICIENT(n) + Max (0, Pa)

with the definition Pa := (MS_TXPWR_MAX(n) - P(n))
The "Sufficient UMTS coverage" HO shall be performed for a "slow moving" MS/UE, i.e.
for a MS/UE for which the "Sufficient UMTS coverage" condition is still met for t >=
HOMDTIME.
The "Sufficient UMTS coverage" HO shall not be performed for a "fast moving" MS/UE,
i.e. for a MS/UE for which the "Sufficient UMTS coverage" condition is violated before
the timer HOMDTIME expires.
To manage speed sensitive handover in case of Sufficient UMTS coverage handover
the parameter shown in Tab. 3.84.17 have to be defined. All these parameters must be
defined in the ADJC3G object instance the identifies the neighboring relationships from
the GSM cell (departure cell) to the UMTS one (target cell).
Parameter

Meaning

MICROCELL

Only if this parameter is set is set to true the speed

sensitivity handover algorithm will be in effect for
this neighbour cell.

HOMDTIME

It specifies the time an immediate handover request

is delayed.

PPLNC

It determines the temporary priority layer of the

adjacent UMTS cell, when the HOMDTIME timer is
running.

Tab. 3.84.17Speed Sensitive Handover Parameters in Case of Sufficient UMTS

Coverage Handover

E) FORCED HANDOVER (DIRECTED RETRY)

If during the assignment phase, as represented by the A-ASSIGNMENT-REQUEST
message, a GSM to UMTS handover becomes necessary, due to either radio conditions
or congestion, then the UE/MS may be handed over from the SDCCH channel of the
GSM cell to a UMTS cell. This is called directed retry (the same intra-GSM procedure
already exist).
After having received the ASSIGNMENT REQUEST message, the BSC shall, if the
GSM serving cell is congested, initiate the Directed Retry by sending a "Forced HO
Request" message ("Imperative HO") to the BTS (as for GSM to GSM Directed Retry).
The BTS answers to the "Forced HO Request" with a "Inter-cell HO Condition Indication"
message (as for GSM to GSM Directed Retry) which contains the Target Cell List. If the
handover from GSM to UMTS is not enabled, this Target Cell List contains only GSM
cells.
In order to support the GSM to UMTS Directed Retry, the BTS shall include UMTS cells
into the Target Cell List (TLC) and sort the TCL as for an "Imperative HO" taking into
accout the setting of the IE "Service Handover"(see note below ).

A30808-X3247-L210-3-7619

405

OMN:BSC

Operation
Base Station Controller

It is possible to enable/disable the Directed Retry to UMTS, via the EUSDCHO parameter (Enable_SDCCH_HO_to_UMTS) for a whole BSC area, because some MSCs may
not support Directed Retry to UMTS.
If this parameter is set to FALSE, the BTS does not include UMTS cells into the Target
Cell List and does not initiate a handover to UMTS for a MS/UE which is on a SDCCH.
E.1) SERVICE BASED DIRECTED RETRY
In addition to radio conditions or congestion, the BSC shall also initiate the Directed
Retry from GSM to UMTS if the new IE "Service Handover" in the ASSIGNMENT
REQUEST message is set to "Handover to either UTRAN or cdma2000 should be
performed" (see note below).
This Service Based Directed Retry is required in order to achieve that the MS/UE is
handed over to UMTS already during the call assignment phase; i.e. during the early
phase in which the MS/UE is assigned to a GSM SDCCH, so that it can be avoided that
a GSM TCH is assigned to a MS/UE which should be handed over to UMTS as soon as
possible.
OTHER CONSIDERATIONS REGARDING THE CONFIGURATION OF HANDOVER
FROM GSM TO UMTS

406

The FDDMURREP (FDD_MULTIRAT_REPORTING) parameter and the

TDDMURREP (TDD_MULTIRAT_REPORTING) parameter define the number of
best valid UMTS neighbour cells (FDD and TDD) which shall be reported by the
MS/UE. The remaining positions in the measurement report shall be used for
reporting of GSM cells. If there are still remaining positions, these shall be used to
report the next best valid UMTS cells;

The MS/UE shall search for UMTS cells if signal level (from the serving GSM cell) is
below or above a certain threshold. The user can set this value by the QSRHC
parameter of the BTS object; instead the QSRHCINI (Qsearch_C_Initial) value has
to be used by the MS/UE before Qsearch_C is received from the network (i.e. before
the MS enters dedicated mode arriving from idle mode);

Prevention of Back Handover (GSM to UMTS) can not be supported.

BSCT3121 (bscTimer3121) parameter, belonging to BSC object, defines the timer

that is started by the sending of an INTER SYSTEM TO UTRAN HANDOVER
message and is normally stopped when the message HO COMPLETE is received.

ASCI is a GSM feature and not supported by the UMTS system.Therefore, if the
MS/UE is an ASCII talker, no HO from GSM to UMTS shall be performed, I.e. the
ASCI talker shall be kept within the GSM system.As consequence, BTS shall
generate a TCL without including UMTS target cells.

The new IE Service Handover, which is sent by the MSC to the BSC in the
HANDOVER/ASSIGNMENT REQUEST message, specifies whether a handover to
UMTS "should", "should not" or "shall not" be performed. If this IE is set to shall
not, the BTS shall generate a TCL without UMTS target cells for a "Better cell HO"
and also for an "imperative" handover, while the "Sufficient UMTS Coverage" HO
shall be disabled. If this IE is set should not, the BTS shall only include UMTS cells
in the target cell list (TCL) in case of an "imperative HO" I.e., in case of a "Better cell
HO" the BTS shall generate a TCL without UMTS target cells while the "Sufficient
UMTS Coverage" HO shall be disabled. If this IE is set to should, the BTS shall

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

generate a TCL with the GSM cells sorted after the UMTS cells, while the "Sufficient
UMTS Coverage" HO shall be inititiated even if the "Sufficient UMTS Coverage" HO
is generally disabled (i.e. the EUSCHO=FALSE) in order to allow the handover to
UMTS when the "sufficient threshold" condition is met.
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Enable handover from GSM to UMTS generally

To enable Handover from GSM to UMTS generally, enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

---> SET HAND

Then set to TRUE the value of the EUHO parameter.

Result: all the handovers from GSM to UMTS can now be enabled for the
involved GSM cell.

Which kind of handover to UMTS you want to enable?

Power Budget handover?
Sufficient UMTS coverage handover?
Imperative handover?
Directed Retry?

h ... 3
h ... 11
h ... 17
h ... 22

Enable Power Budget handover from GSM to UMTS

To enable Power Budget Handover from GSM to UMTS, enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

---> SET HAND

Then set to TRUE the value of the EUBCHO parameter.

Result: power budget handover from GSM to UMTS is enabled.

Situation (for UMTS FDD cells)

Has the TGTFDD object instance, related to the UMTS cell, been created yet?

Y h ... 5
N i ..."3.68 Addition
of a UMTS
Adjacent Cell"

A30808-X3247-L210-3-7619

407

OMN:BSC

Operation
Base Station Controller

Define the maximum power in the neighboring UMTS cell

To define the maximum power, enter the SET TGTFDD command (related to the
involved neighboring UMTS FDD cell), following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> TGTFDD ---> SET TGTFDD

Then set the value of the MSTXPMAXUMTS parameter.

Situation

Y h ... 7
N h ... 8

Is the Hierarchical Cell Structure enabled in the serving GSM cell?

Define parameters of the neighboring UMTS FDD cell with HCS enabled

To define these parameters, enter the CREATE ADJC3G command, following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

ADJC3G ---> CREATE ADJC3G

Then set the following values:

TGTCELL = the TGTFDD instance related to the external UMTS FDD cell
RXLEVMINC
HOM
UADJ
PLNC: to define the priority layer of the neighboring UMTS cell

h ... 10
8

Define parameters of the neighboring UMTS FDD cell without HCS enabled

To define these parameters, enter the CREATE ADJC3G command, following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

ADJC3G ---> CREATE ADJC3G

Then set the following values:

TGTCELL = the TGTFDD instance related to the external UMTS FDD cell
RXLEVMINC
HOM
UADJ

408

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Enable Speed Sensitive Power Budget HO

To enable Speed Sensitive Power Budget HO,enter the CREATE ADJC3G

command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

---> ADJC3G ---> CREATE ADJC3G

Then set to TRUE the value of the MICROCELL parameter and set the values of
the following parameters:
HOMDTIME
HOMSOFF
HOMDOFF
PPLNC
Result: The Speed Sensitive Power Budget HO is enabled

10

Define the reporting quantity

To define the reporting quantity, enter the SET BTS command, following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

Then set to RSCP the value of the FDDREPQTY parameter.

h ... END
11

Enable Sufficient UMTS coverage handover from GSM to UMTS

To enable Sufficient UMTS Coverage Handover from GSM to UMTS, enter the
SET HAND command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

---> SET HAND

Then set to TRUE the value of the EUSCHO parameter.

Result: Sufficient UMTS Coverage handover from GSM to UMTS is enabled.

12

Situation (for UMTS FDD cells)

Has the TGTFDD object instance, related to the UMTS cell, been created yet?

Y h ... 13
N i ..."3.68 Addition
of a UMTS
Adjacent Cell"

A30808-X3247-L210-3-7619

409

OMN:BSC

13

Operation
Base Station Controller

Define the reporting quantity

To define the reporting quantity, enter the SET BTS command, following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

Then set to RSCP the value of the FDDREPQTY parameter.

Note: if you set FDDREPQTY=EC_NO remember that power budget handover
to UMTS becomes automatically disabled in the BTS.

14

Define the maximum power in the neighboring UMTS cell

To define the maximum power, enter the SET TGTFDD command (related to the
involved neighboring UMTS FDD cell), following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> TGTFDD ---> SET TGTFDD

Then set the value of the MSTXPMAXUMTS parameter.

15

Enable Speed Sensitive Sufficient UMTS coverage HO

To enable Speed Sensitive Sufficient UMTS coverage HO,enter the CREATE

ADJC3G command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

---> ADJC3G ---> CREATE ADJC3G

Then set to TRUE the value of the MICROCELL parameter and set the values of
the following parameters:
HOMDTIME
PPLNC
Result: The Speed Sensitive Sufficient UMTS coverage HO is enabled

16

Define parameters of the neighboring UMTS FDD cell

To define these parameters, enter the CREATE ADJC3G command, following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

ADJC3G ---> CREATE ADJC3G

Then set the following values:

TGTCELL = the TGTFDD instance related to the external UMTS FDD cell
USRSCP
Note: since you have set FDDREPQTY=RSCP than you must set the USRSCP
parameter and not the USECNO one.

410

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

17

OMN:BSC

Enable imperative handover from GSM to UMTS

To enable imperative Handover from GSM to UMTS, enter the SET HAND
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> HAND

---> SET HAND

Then set to TRUE the value of the EUIMPHO parameter.

Result: imperative handover from GSM to UMTS is enabled.

18

Situation (for UMTS FDD cells)

Has the TGTFDD object instance, related to the UMTS cell, been created yet?

Y h ... 19
N i ..."3.68 Addition
of a UMTS
Adjacent Cell"

19

Define the reporting quantity

To define the reporting quantity, enter the SET BTS command, following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

Then set to RSCP the value of the FDDREPQTY parameter.

Note: if you set FDDREPQTY=EC_NO remember that power budget handover
to UMTS becomes automatically disabled in the BTS.

20

Define the maximum power in the neighboring UMTS cell

To define the maximum power, enter the SET TGTFDD command (related to the
involved neighboring UMTS FDD cell), following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> TGTFDD ---> SET TGTFDD

Then set the value of the MSTXPMAXUMTS parameter.

A30808-X3247-L210-3-7619

411

OMN:BSC

21

Operation
Base Station Controller

Define parameters of the neighboring UMTS FDD cell

To define these parameters, enter the CREATE ADJC3G command, following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

ADJC3G ---> CREATE ADJC3G

Then set the following values:

TGTCELL = the TGTFDD instance related to the external UMTS FDD cell
RXLEVMINC

h ... END
22

Enable directed retry from GSM to UMTS

To enable directed retry from GSM to UMTS, enter the SET HAND command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BSC ---> SET BSC

Then set to TRUE the value of the EUSDCHO parameter.

NOTE: it is important to check if the MSC supports this functionality, before
enabling it.

END

412

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.85

OMN:BSC

Management of the Power Control

Introduction
The objective of power control is to adapt the transmitting power of the MS as well as of
the BTS to the reception conditions.
There are two advantages using power control:
1. reduction of the average power consumption (especially in the MS);
2. reduction of the interference experienced by co-channel (or adjacent) channel
users.
The operator can enable the power control separately for the downlink or uplink direction; in fact:

the EBSPWRC parameter allows to enable the power control in downlink direction
(i.e. the power of the BTS is adjusted according to current level and quality experienced by the MS);

the EMSPWRC parameter allows to enable the power control in uplink direction (i.e.
the power of the MS is adjusted according to current level and quality experienced
by the MS).

Downlink power control is not applied for downlink bursts using the BCCH frequency.
The object the user has to manage is the PWRC. The PWRC object instance is automatically created after creating a BTS object instance; so there is only one PWRC
instance for every BTS (the PWRC object has only one instance, i.e. instance number
0, see "1.5.1 Notes on the CREATE commands"). The user can only display and modify
its attributes respectively with the GET and SET commands.
Power control uses both incremental and reductive steps to adjust the transmitted power
of the MS/BTS. Power control decisions are based on RXLEV and RXQUAL sample
values, which are obtained by uplink and downlink measurements. The samples are
shifted into the so-called averaging windows and an average value is calculated.
The averaging windows can be defined using these parameters:

PAVRQUAL: it defines the averaging window for RXQUAL values, used for power
control decisions;
PAVRLEV: it defines the averaging window for RXLEV values, used for power
control decisions.

Then according to the received average values, for each direction, it is possible to
execute two kinds of power control:
a) a power control due to bad/high received level;
b) a power control due to bad/high received quality.
In fact, the power control algorithm tries, in general, to maintain the received level and
quality between, respectively, two specific thresholds for level and for quality. Then, the
operator can set the following parameters:

for uplink direction:

LOWTLEVU: lower threshold of the level
UPTLEVU: upper threshold of the level
LOWTQUAU: lower threshold of the quality

A30808-X3247-L210-3-7619

413

OMN:BSC

Operation
Base Station Controller

UPTQUAU: upper threshold of the quality

for downlink direction:

LOWTLEVD: lower threshold of the level

UPTLEVD: upper threshold of the level
LOWTQUAD: lower threshold of the quality
UPTQUAD: upper threshold of the quality

Regarding used incremental/reductive steps of power, two different algorithms are

provided:
1. Classic Power Control: with this algorithm the incremental and reductive steps for
the power control have fixed size and are configurable by the operator in steps of 2,
4 and 6 dB, independently on the real need of the current radio conditions. In case
of rapid decrease of the received level e.g. at street corner, in outdoor movement or
at the cell border of micro cells, this power control algorithm might be too slow and
call drops may occur because a handover will not be triggered before the maximum
transmit power allowed in a cell is adjusted.
The operator can set:
the incremental step using the PWRINCSS parameter;
the reductive step using the PWREDSS parameter.
Having detected within the decision process that a change of the transmited power
should be carried out, the value for this change is fixed according to the previous
steps.

To be able to react fast enough on sudden drops of link quality one should have:
PWRINCSS>PWREDSS
When a change of the transmited power must be executed, a message is sent to
MS/BS requiring the MS/BS to adjust its transmit power level to the REQ_TXPWR
required value.
Having requested a transmit power REQ_TXPWR, the power control decision
process is suspended and it is waited for a confirmation that the transmit power of
the MS/BTS is adjusted to requested value, i.e.CONF_TXPWR = REQ_TXPWR.
lf such a confirmation is not received within an interval defined by the PWRCONF
parameter (in terms of SACCH multiframes), the power control decision process is
immediately resumed using the most recently reported confirmed value.
lf a confirmation is received, the power control decision process is suspended for a
certain number of SACCH multi-frames given by the PCONINT parameter.
The reason for this is to allow an observation of the effect of one power control decision before initialising the next one; by this means the power control process is stabilized.
2. Adaptive Power Control: this algorithm, introduces an improved power control for
circuit switched services, applying incremental steps, which are automatically
adapted to the system needs, according to the received signal quality (RXQUAL) or
to the received signal level (RXLEV).
The adaptation steps are dynamically calculated by the system according to current
radio conditions.

414

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

In addition to the optimal adaptation of the step size, the improved power control can
also minimize the time between two power control decisions. As intercell handovers
(for quality or level reasons) are triggered only as soon as the maximum transmit
power allowed in a cell has been reached, if the power control is quicker the
handover can be executed more rapidly.
The improved power control enables the system to react more quickly specially to
street corner effects. At the border of a cell, especially of a micro cell, the precondition for triggering the handover can be achieved much earlier by avoiding intermediate superfluous power control steps. Therefore, the call drop rate will be reduced.
With this algorithm, the PCONINT timer is no longer used to indicate the time the
sysetm wait to resume the power control decision.The time to suspend a subsequent decision after the output power has been changed due to QUALITY reason is
determined by the system itself and just depends on the RXQUAL window size
(defined by PAVRQUAL ). If the window size is n, the timer has to be n times 480ms
in case of TCHs and n times 470ms in case of SDCCHs.
When ordering to the MS a change of the uplink transmit power, the timer is started
after the ordered power level has been confirmed by the MS.
After setting a new output power for the uplink or the downlink, all samples in the
averaging window for the corresponding received level should be corrected by
adding the step size to each sample. And, in case of changing the uplink power, also
the following samples have to be corrected until the MS confirms the ordered power
level.
This leads to an average in the window as if the power had been adapted before and
therefore, the next power control decision:
does not need to be suspended, if the output power has been changed due to
LEVEL;
is suspended for a time depending on the RXQUAL window size, if the output
power has been changed due to QUALITY;
Regarding the power control adjust, the average uplink and downlink receive levels
and quality indicators are compared with the corresponding thresholds (the same
thresholds are used for both CLASSIC and ADAPTATION power controls).
A new power level will be ordered in situations, where the quality average values
and/or level average values or not within the optimum area as depicted in
Fig. 3.85.17. The power control keeps the mobile station within the thresholds
regarding signal quality and signal level.
In particular, when the adaptive algorithm is used, the step size is calculated as
follows:
fast (adaptive) power increase is applied, if the signal quality average is below RX
Lower Threshold and the signal level average is below Low Qual.
step A [dB]:=abs(RXLEV 0.5*(RX Upper Threshold + RX Lower Threshold))
fast (adaptive) power increase is applied, if the signal quality average is above
Low Qual and the signal level average is below RX Lower Threshold.
step B [dB]:=abs(RX Lower Threshold RXLEV))
classic power increase is applied, if the signal quality average is below Low Qual
and the signal level average is above RX Lower Threshold.
step C[dB]:= increment_step_size (dB);
where increment_step_size: configurable by the operator using the PWRINCSS
parameter;

A30808-X3247-L210-3-7619

415

OMN:BSC

Operation
Base Station Controller

standard power reduction is applied, if the signal quality average is above Up Qual
and the signal level average is above RX Upper Threshold.
step D[dB]:= decrement_step_size (dB)
decrement_step_size: configurable by the operator using the PWREDSS parameter;
within the Buffer, we have a very good quality and the signal level is close to RX
Lower Threshold, but it is within the specified signal level range. So there is
performed no PC action.

Fig. 3.85.17Adaptive Power Control Areas

The operator when enabling the power control in one of the two directions (using the
EBSPWRC attribute or the EMSPWRC one, according to the direction), can indicate
which kind of algorithm he wants to use, setting one of the following values:

CLASSIC;
ADAPTIVE

Besides, the PCMBSTXPRL parameter defines the absolute maximum base station
transmission power reduction level (in 2dB steps)
Regarding the Power Control feature, in order to have a great flexibility during algorithm
definition, it is more efficient to differentiate power control flags and thresholds on
service basis. So an optimal usage of all available radio channels according to the operators service policy can be achieved.
In order to make possible this kind of flexibility for CS services, fourteen service groups
have been introduced to differentiate among different circuit switched services. These
service groups concern: Circuit-Switched services (CS) on Half Rate (HR), Full Rate
(FR), Enhanced Full Rate (EFR), Adaptive Multi-Rate (AMR), Advanced Speech Call
Items (ASCI), Voice Broadcast Services (VBS), Voice Group Call Services (VGCS), and
High Speed Circuit-Switched Data services (HSCSD).
Tab. 3.85.18 shows in detail the fourteen groups that have been defined: each group is
identified by a specific parameter that is composed by a number of field that allow to
specify different flags and thresholds according to the service type.

416

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Group

Kind of CS Service

Attribute

SG-1

Signalling on hopping channel

SG1PCPAR

SG-2

Signalling on non hopping channel

SG2PCPAR

SG-3

CS speech FR-EFR-ASCI VBS-ASCI VGCS on

hopping channel

SG3PCPAR

SG-4

CS speech FR-EFR-ASCI VBS-ASCI VGCS on non

hopping channel

SG4PCPAR

SG-5

CS speech HR on hopping channel

SG5PCPAR

SG-6

CS speech HR on non hopping channel

SG6PCPAR

SG-7

CS data until 9,6kbit/s or HSCSD 9.6kbit/s on hopping

channel

SG7PCPAR

SG-8

CS data until 9,6kbit/s or HSCSD 9.6kbit/s on nonhopping channel

SG8PCPAR

SG-9

CS data until 14,4kbit/s or HSCSD 14,4kbit/s on

hopping channel

SG9PCPAR

SG-10

CS data until 14,4kbit/s or HSCSD 14,4kbit/s on nonhopping channel

SG10PCPAR

SG-11

CS speech AMR FR on hopping channels

SG11PCPAR

SG-12

CS speech AMR FR on non hopping channels

SG12PCPAR

SG-13

CS speech AMR HR on hopping channels

SG13PCPAR

SG-14

CS speech AMR HR on non hopping channels

SG14PCPAR

Tab. 3.85.18Service Groups for Power Control Purpose

For each group from SG-1 to SG-10 the complete set of the following flags and thresholds has been introduced in the related SGXXPCPAR parameters:
Enables the BS power control
Enables the MS power control
Enables Radio Link Failure power control.
Lower DL RXLEV threshold (range 0..63).
Lower UL RXLEV threshold (range 0..63).
Upper DL RXLEV threshold (range 0..63).
Upper UL RXLEV threshold (range 0..63).
Threshold for the radio link failure counter (range 0..64).
Lower DL quality threshold for standard calls in RXQUAL (range 0..7)
Lower UL quality threshold for standard calls in RXQUAL (range 0..7)
Upper DL quality threshold for standard calls in RXQUAL (range 0..7)
Upper UL quality threshold for standard calls in RXQUAL (range 0..7)
For each group from SG-11 to SG-14 the complete set of the following flags and thresholds has been introduced in the related SGXXPCPAR parameters:

A30808-X3247-L210-3-7619

417

OMN:BSC

Operation
Base Station Controller

Enables the BS power control

Enables the MS power control
Enables Radio Link Failure power control.
Lower DL RXLEV threshold (range 0..63).
Lower UL RXLEV threshold (range 0..63).
Upper DL RXLEV threshold (range 0..63).
Upper UL RXLEV threshold (range 0..63).
Threshold for the radio link failure counter (range 0..64).
Lower DL quality threshold for AMR calls in C/I (range 0..30)
Lower UL quality threshold for AMR calls in C/I (range 0..30)
Upper DL quality threshold for AMR calls in C/I (range 0..30)
Upper UL quality threshold for AMR calls in C/I (range 0..30)

So, the user, when setting handover parameters, can choose if he wants to use specific
settings for a service group (filling one of the SGXXPCPAR parameter), or if he wants
to use the thresholds present outside the service groups (i.e. the general parameters
that are valid for all the groups when the user does not specify the SGXXPCPAR parameter).
The general configuration rule is the following:
a) when the user does not set any SGXXPCPAR parameters, service independent
parameters (i.e. the general parameters valid for all service groups) regard ALL the
circuit switched services;
b) when the user set one SGXXPCPAR parameter related to a specific CS service, the
service dependent thresholds of this SGXXPCPAR parameter override, only for
this kind of CS service, the service independent attributes.
For instance, the following table shows twelve service independent parameters of the
power control object that are valid for all the CS services, when no SGXXPCPAR parameters have been filled.
Service independent parameters
Parameter

Meaning

EBSPWRC

EnableBSPowerControl

EMSPWRC

EnableMSPowerControl

EPWCRLFW

EnablePowerControlRLFW

LOWTLEVD

PcLowerThresholdLevDL

LOWTLEVU

PcLowerThresholdLevUL

UPTLEVD

PcUpperThresholdLevDL

UPTQUAU

PcUpperThresholdLevUL

PCRLFTH

PcRLFThreshold

LOWTQUAD

PcLowerThresholdQualDL

Tab. 3.85.19Example of Service Independent Parameters

418

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Service independent parameters

Parameter

Meaning

LOWTQUAU

PcLowerThresholdQualUL

UPTQUAD

PcUpperThresholdQualDL

UPTLEVU

PcUpperThresholdQualUL

Tab. 3.85.19Example of Service Independent Parameters

Now, if the user sets the SG3PCPAR parameter, the parameters shown in Tab. 3.85.19
will be replaced by those shown in Tab. 3.85.20, only for CS speech calls (FR, EFR,
ASCI VBS, ASCI VGS) on hopping channels (because the SG3PCPAR parameter
regards this kind of calls).

The other CS services will continue to use the parameters defined in Tab. 3.85.19 (i.e.
the service independent ones).

Service dependent parameters (SG3PCPAR group)

SG3PCPAR.EnableBSPowerControl
SG3PCPAR.EnableMSPowerControl
SG3PCPAR.EnablePowerControlRLFW
SG3PCPAR.PcLowerThresholdLevDL
SG3PCPAR.PcLowerThresholdLevUL
SG3PCPAR.PcUpperThresholdLevDL
SG3PCPAR.PcUpperThresholdLevUL
SG3PCPAR.PcRLFThreshold
SG3PCPAR.PcLowerThresholdQualDL
SG3PCPAR.PcLowerThresholdQualUL
SG3PCPAR.PcUpperThresholdQualDL
SG3PCPAR.PcUpperThresholdQualUL
Tab. 3.85.20Example of Service Independent Parameters

If the user does not want to use the SGXXPCPAR thresholds he has to set the new
attributes to NULL value, this value is considered the DEFAULT value for new attributes.
The customer is allowed to set the attributes also for not all SGXXPCPAR parameters,
but if one threshold belonging to one SGXXPCPAR parameter is set to a valid value, the
others ones belonging to the same SGXXPCPAR parameter shall be significant.
The BTS is informed about the parameter settings in a different way:

A30808-X3247-L210-3-7619

419

OMN:BSC

Operation
Base Station Controller

the service independent thresholds and flags are transferred to the BTS via O&M
alignment;

the thresholds belonging to SGXXPCPAR parameters are transferred to the BTS via
one specific optional information element (Service Group Pc Settings) added in one
of the following messages:
Channel Activation message;
Channel Mode modify message;
Channel Configuration Change message; this message is used to signal some
changes occurred in a set of parameters previously submitted with either the
Channel Activation message or the Channel Mode Modify one.

In case for one SGXXHOPAR there are no valid assigned parameters, the BSC avoids
to insert the new information element in the Channel Activation message, in the Mode
Modify message and in Channel Configuration Change message. In this case the BTS
shall apply for Handover algorithm the threshold received via O&M alignment.

Prerequisites
The bts# object instance must be already created, otherwise the PWRC does not exist.
The user must have the visibility level number set to "2".

Enabling Classic Power Control in uplink direction

To enable Classic Power Control in uplink direction, enter the SET PWRC
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> PWRC

---> SET PWRC
The set the following attribute value:
EMSPWRC=CLASSIC
and choose the values of the other parameters according to your needs.

Result: Setting of a PWRC.

END

420

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.86

OMN:BSC

Enabling/Disabling of the Emergency Calls

Introduction
The attribute that allows to enable or disable the Emergency Calls in a cell is included
in the OPTIONS group (see "1.9 Attribute Groups") of the BTS object (or BTSTD object
in case of TD-SCDMA technology).
The attribute is called EC (Emergency Calls) and it can assume the values
TRUE/FALSE. It is broadcast to the Mobile Station on the BCCH.
The OPTIONS group is automatically created when the BTS (BTSTD) is created, so the
user can only display and modify the attributes respectively with the GET and SET
commands.
Prerequisites
The instance of the BTS/BTSTD managed object must be already created.
The user must have the visibility level number set to "2".

Preliminary Consideration
Do you want to enable/disable emergency calls for a GSM cell?
Do you want to enable/disable emergency calls for a TD-SCDMA cell?

h ... 2
h ... 3

Set the emergency calls (GSM cell)

To enable or disable the emergency calls enter the SET BTS command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS

---> SET BTS
(setting EC= FALSE the emergency calls are allowed, otherwise EC= TRUE the
emergency calls are not allowed).

Result: Setting the emergency calls.

h ... END

Set the emergency calls (TD-SCDMA cell)

To enable or disable the emergency calls the user must enter the SET BTSTD
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD

---> SET BTSTD
(setting EC= FALSE the emergency calls are allowed, otherwise EC= TRUE the
emergency calls are not allowed).

Result: Setting the emergency calls.

END

A30808-X3247-L210-3-7619

421

OMN:BSC

Operation
Base Station Controller

3.87

Barring the Access to a Cell

Introduction
The attribute that does not allow access to a cell belongs to the OPTIONS group, which
is provided to control the various optional features of a either a BTS or a BTSTD (in case
of TD-SCDMA). This group is automatically created with the BTS (BTSTD), so the user
can only modify or display the values of its attributes, respectively through the SET and
GET commands.
The important attribute the user has to set is called CELLBARR. This attribute indicates
whether the Mobile Station may camp on the cell.
Prerequisites
The instance of the BTS/BTSTD managed object must be already created.
The user must have the visibility level number set to "2".

Preliminary Consideration

h ... 2
h ... 3

Do you want to bar the access to a GSM cell?

Do you want to bar the access to a TD-SCDMA cell?

Bar the access to a GSM cell

To bar the access to a cell, enter the SET BTS command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS
(if the CELLBARR= TRUE the CELL is BARRED).

h ... END

Result: Barring access to a cell.

Bar the access to a TD-SCDMA cell

To bar the access to a cell, enter the SET BTSTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

SET BTSTD
(if the CELLBARR= TRUE the CELL is BARRED).

Result: Barring access to a cell.

END

422

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.88

OMN:BSC

Hierarchical Cell Structure Management

Introduction
In a Hierarchical Cell Structure the traffic is distributed on multiple layers of cells. This
structure is useful to handle different kinds of traffic (Umbrella Cells, Normal Cells and
Micro Cells) and multiband systems (DCS1800 and GSM900).
A Network Operator can for example implement a three layer network having the biggest
cell on the Upper Layer (Umbrella Cells), used to guarantee the coverage when it is not
possible otherwise, the normal cell (typical range larger than 1km) on the Middle Layer,
and the microcells on the lower layer, to handle high traffic areas.
In a hierarchical structure the handover algorithms are imposed in order to have a
channel allocated in the appropriate cell, to avoid for example a congestion in the
Umbrella cells and to use as much as possible the microcells that are introduced to
enlarge the traffic capacity.
The handover may be due to imperative causes or to PBGTHO. In the first case, all the
cells in the target list are considered whatever are their hierarchical priority and how it is
considered the MS speeds according to the Speed Sensitive HO algorithm. In case of
PBGTHO, the HO is not intended to be mandatory so it is carried out only if a suitable
cell, that is a cell having a priority equal or higher than the serving one, is found.
The operator is free to choose the priority layer for each cell giving, for example, a
different priority to cells of the same layer.
It is then possible to apply the Speed Sensitive HO algorithm to evaluate the mobile
speed; if the mobile is classified as slow, the layer maintains its priority otherwise it is
penalized.
The operator has to define the penalized layer for the cell where the mobile is considered as an high speed MS.
In the case of PBGTHO only the cells having a value of PBGTHO(n) > HOM(n) are
inserted in the list.
For the Imperative HO two ranking possibilities are foreseen, according to the setting of
the HIERF parameter.
If the flag is set to Rank0, all the cells where rxlev_ncell>rxLevMinCell+max(0,PA) are
sorted in increasing order of priority where PBGTHO-HOM>0, followed by those cells
where PBGTHO-HOM<0 in increasing order of priority. Having the same priority the
cells are sorted by PBGTHO-HOM.
If the flag is set to Rank1, all the cells where rxlev_ncell>rxLevMinCell+max(0,PA) are
subdivided into two sub-lists:
1. The upper sub-list consists of all the cells with rxlev_ncell>rxLevMinCell+max(0,PA)+levelOffsetNCell
2. The lower sub-list consists of all the cells with rxlev_ncell<=rxLevMinCell+max(0,PA)+levelOffsetNCell.
Within each sub-list the cells are ordered according to their priority. Cells having the
same priority are ordered according to the value of PBGTHO-HOM.
For a more detailed description of the HCS attributes and algorithm, please refer to the
TED: BSS.

A30808-X3247-L210-3-7619

423

OMN:BSC

Operation
Base Station Controller

Prerequisites
The BTS must be already created.

Preliminary Consideration

The objects involved in the hierarchical cells handling are:

ADJC
HAND

Y h ... 3
N h ... 2

Does the ADJC object already exist?

Create ADJC

Select the command "CREATE ADJC" following the next sequence of selections:

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

---> CREATE ADJC
Enter the values for the attributes to be modified: PLNC, PPLNC, LEVONC.

Result: Creation of the ADJC object

Set values of ADJC attributes

Select the "SET ADJC" command following the next sequence of selections:

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

--->SET ADJC
Enter the new values for the attributes to be modified: PLNC, PPLNC, LEVONC.

Result: Modification of the involved parameters.

Set values of HAND attributes

Select the command "SET HAND PKGHANDB" following the next sequence of
selections.

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> HAND

---> SET HAND
Enter the new values for the attributes to be modified: HIERC, PL, HIERF

Note: for PL, PLNC and PPLNC the layer 0 has the highest priority and layer 15
the lowest one.

END

424

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.89

OMN:BSC

Definition and Activation of Environmental Alarms

Introduction
The environmental alarms are modeled with the ENVA object. The number of the
instance defined by the ENVA object corresponds to the number of the physical sense
point, that must analyse a specific environmental alarm. The creation of an ENVA object
defines and enables the scanning of the corresponding sense point once a second.
For the BSC, the MPCC board itself is able to manage 5 external alarms, that are
handled directly by the MPCC.
When either the standard BSC or the high capacity BSC with the old rack is used (see
"1.4 Supported BSC Types"), only five external alarms can be managed by the system,
according to limited number of the physical sense points handled by the MPCC. In this
case the ENVA object instances must belong to the range [0..4].
When the high capacity BSC with the new rack is used (see "1.4.3 High Capacity BSC
with New Rack"), 16 additional external alarms can be monitored. In fact, in this case,
CPEX boards handle these 16 alarms and the MPCC processor read the alarms through
the bus. In this case the ENVA object instances must belong to the range [0..20].
The 16 ENVAs handled by the CPEX have the same behavior as the ENVAs handled
by MPCC from the point of view of the operator, apart from the fact that when both CPEX
are unavailable, the additional 16 ENVAs are not available too. In this case they are
disabled for dependency.
The Failure Event Report (FER) associated to the chosen envaName is generated when
the alarm occurs a number of times equal to the number of seconds specified with the
threshold attribute in the "CREATE ENVA" command.
In case the alarm absence is detected for a number of consecutive times equal to the
triple of the threshold attribute specified in the "CREATE ENVA" command, the end
alarm condition is notified by means of a FER with CLEARED severity.
Beside the BSC, the operator can monitor external alarms for also BTS and TRAU
equipment. The configurability is realized setting specific attributes of the related objects
representing the environmental alarms, so called ENVABTSE and ENVTRAUE objects.
Prerequisites
From the sensor technical description read the Interface Logic (signal emitted from the
sensor when the alarm is active).

Choose the object

To define and activate an external alarm, the operator must select the object:
BSCE
BTSE
TRAUE

h ... 2
h ... 5
h ... 8

BSCE object preliminary consideration

Does the envaNum already exist?

A30808-X3247-L210-3-7619

Y h ... 4
N h ... 3
425

OMN:BSC

Operation
Base Station Controller

Create the ENVA object

To create the ENVA object select the command "CREATE ENVA" following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> ENVA --->

CREATE ENVA

Result: Creation of the ENVA object.

Modify of the ENVA object

Select the "SET ENVA" command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> ENVA ---> SET

ENVA

Result: Modification of the ENVA object.

Note: for resetting the alarm do the "SET ENVA" command specifying the same
envaName attribute.

BTSE object preliminary consideration

Y h ... 7
N h ... 6

Does the envaBTSENum already exist?

h ... END

Create the ENVABTSE object

To create the ENVABTSE object select (after chosing the correct BTSE Type
using the interworking mode) the "CREATE ENVABTSE" command, following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <BTSE Type> ---> RACK

---> ENVABTSE ---> CREATE ENVABTSE

Result: Creation of the ENVABTSE object.

Modify of the ENVABTSE object

Select the "SET ENVABTSE" command (after chosing the correct BTSE type
using the interworking mode) following the next sequence of selections :

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <BTSE Type> ---> RACK

ENVABTSE ---> SET ENVABTSE

Result: Modification of the ENVABTSE object.

Note: for resetting the alarm do the "SET ENVABTSE" command specifying the
same envaName attribute.

426

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

TRAUE object preliminary consideration

Does the envaTRAUENum already exist?

OMN:BSC

Y h ... 10
N h ... 9

Create the ENVTRAUE object

To create the ENVATRAUE object select (after chosing the TRAUE interworking
mode) the command "CREATE ENVATRAUE" following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUE---> ENVTRAUE

---> CREATE ENVATRAUE

Result: Creation of the ENVATRAUE object.

10

Modify of the ENVATRAUE object

Select the "SET ENVATRAUE" command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUE---> ENVTRAUE --->

SET ENVATRAUE

Result: Modification of the ENVATRAUE object.

Note: for resetting the alarm do the "SET ENVATRAUE" command specifying
the same envaName attribute.

END

A30808-X3247-L210-3-7619

427

OMN:BSC

Operation
Base Station Controller

3.90

Deletion of an External Alarm for a BSC

Introduction
Use this procedure to delete an alarm.
If the alarm is active the FER CEASED is emitted.
The sense point is not scanned anymore.
Prerequisites
The ENVA object must exist.

Lock the ENVA object

Select the "LOCK ENVA" command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> ENVA ---> LOCK

ENVA

Result: The ENVA object changes the administrative state from UNLOCKED to
LOCKED

Delete the ENVA object

Select the "DELETE ENVA" command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> ENVA --->

DELETE ENVA

Result: Deletion of the ENVA object.

END

428

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.91

OMN:BSC

BSC Overload Control

Introduction
This procedure explains the meaning of the "BSC Overload Control" spontaneous
message.
The aim of the Overload Control Mechanism is to preserve the traffic-handling capabilities of the mobile Base Station System (BSS) under adverse conditions.
With the term Overload we mean the part of the total load offered in excess of the traffic
processing capacity of the BSS.
Overload control mechanism implemented in the BSC consists of traffic detection mechanism and defensive action makers.
Traffic detection mechanism consists of "Overload Messages" coming either from the
various parts of the network (BTS and/or MSC) or from the BSC itself (Overload Detection).
Defensive actions aimed at reducing both mobile originating (MOC) and/or mobile terminating (MTC) calls (Overload Handler).
There are some different alarms when an overload is detected. They are listed below.
197
263
269

MSC overload detected

BTS overload detected
BSC overload detected

Note: for this procedure no actions are required by operator from OMC.

Prerequisites
None

The BSC Overload Control mechanism and its messages

We can basically have three sources of overload detection:

1. BTS
2. MSC
3. BSC
1. BTS Overload Detection:
The BTS sends a message to the BSC if AGCH or PCH channel is overloaded.
This overload is handled by BSC only if the BTSOVLH parameter of the SET BSC is set to TRUE.
This overload cause event is notified on LMT by this message:
"BSC OVERLOAD REGULATION STARTED: BTS-btsnumber"
2. MSC Overload Detection:
The MSC recognizes its own overload and sends an "overload indication" message to the BSC with
cause value indicating "Processor Overload".
This overload is handled by BSC only if the MSCOVLH parameter of the SET BSC is set to TRUE.
This overload cause is notified on LMT by the event:
"BSC OVERLOAD REGULATION STARTED: MSC"

A30808-X3247-L210-3-7619

429

OMN:BSC

Operation
Base Station Controller

3. BSC Overload Detection:

The BSC detects its own overload and it identifies its cause.
This overload is handled by BSC only if the BTSOVLH parameter of the SET BSC is set to TRUE.
There are three possible causes:
TDPC processor real time exceeds a threshold: the RTE operating system measures the TDPC
processor real time. A TDPC cyclic task checks whether the percentage of the real time is greater
than an upper threshold, the default value is 95%; if it is, it sends a message, indicating that the
machine is overloaded, to the Overload Handler process. The end of the overload condition is
detected by the same task by means of a message to the Overload Handler when the percentage of
the real time is lower than the bottom threshold, the default value is 85%.
The range of both thresholds is 7000-10000: 70%-100%. The upper threshold can be defined setting
the OVLSTTHR parameter of the SET BSC command to 9500. The bottom threshold can be defined
setting the OVLENTHR parameter of the SET BSC to 8500.
This overload cause is notified on LMT by the event:
"BSC OVERLOAD REGULATION STARTED: BSC-1"
SS7 links congestion: this means that TX buffers of the SS7 links are overloaded.
This overload cause is notified on LMT by the event:
"BSC OVERLOAD REGULATION STARTED: BSC-5"
call processing registers congestion: the registers in use have reached the
threshold of 90%.
This overload cause is notified on LMT by one of these events:
"BSC OVERLOAD REGULATION STARTED: BSC-2"
"BSC OVERLOAD REGULATION STARTED: BSC-3"
"BSC OVERLOAD REGULATION STARTED: BSC-4"
End of overload:
At the end of overload one of the following messages is printed:
"BSC OVERLOAD REGULATION ENDED: BTS-btsnumber"
"BSC OVERLOAD REGULATION ENDED: MSC"
"BSC OVERLOAD REGULATION ENDED: BSC"

END

430

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.92

OMN:BSC

Directed Retry Management

Introduction
Directed Retry is the transition (handover) from a SDCCH in one cell to a TCH in another
cell during call setup due to unavailability of an idle TCH within the first cell.
Directed Retry is a mean to avoid the control of the traffic distribution between cells and
to avoid a call rejection due of congestion in one cell.
Directed Retry is merely triggered by the BSC by sending a Forced HO Request
message to the BTS which has to respond with a "initiated" Intercell HO Cond. Indic.
Message.
The Directed Retry is never triggered by radio conditions.
If an Intercell HO Cond. Indic. Message is to be sent, the target cell list shall contain all
neighbour cells with:
RXLEV > RXLEV_MIN + MAX(0,Pa) + FHO_RXLEV_MIN OFFSET
in the order of decreasing values of PBGT - HO_MARGIN <=> 0.
FHO_RXLEV_MINOFSSET is a cell specified DB parameter to select only target cells
for forced HO which the MS can access without any problem.
A proper value of FHO_RXLEV_MIN_OFFSET could be 6 dB.
Prevention of "back-HO's"
A major general problem of Forced HO (Directed Retry) is the probability of HO due to
PBGT back to the old (congested) cell.
The channel activation message contains an optional information element "Cell Identifier List (no target)".
This information element contains the cell identifier (CI) of the cell from which a
handover request due to forced HO was received. If this information element exists in
the Channel Activation message, the BTS

shall not trigger a (TCH) HO due to PBGT for the time TBHO if the PBGT condition
is fulfilled for the indicated cell only and
shall not include the indicated cell identifier(s) in the target cell list in this case for
time TBHO (i.e. for the condition HO due QUAL/LEV/DIST the indicated cell identifier may be part of the target cell list)

The objects involved in the directed retry handling are:

1. BSCB
2. ADJC
For more detailed description of the associated attributes and algorithms please refer to
the TED: BSS.
Prerequisites
To enter the following commands, the BTS must exist.
To enter the following commands, the user must have the visibility level number set to
"2".
A pre-requisite for the "Prevention of back handover" feature in case of MSC controlled
handover is that the cell ID in the HANDOVER REQUEST message uses a cell ID
discriminator 0 (CGI). If not, the back handover cannot be inhibited.

A30808-X3247-L210-3-7619

431

OMN:BSC

Operation
Base Station Controller

Furthermore, the cause IE in the HANDOVER REQUEST message has to be sent by

MSC. If not, BSC fills in the cause "distance", i.e. that if the feature is active, every back
handover due to that reason is inhibited.

Set the BSCB object with the involved parameters.

Select the command "SET BSC PKGBSCB" following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

and enter the values for the attributes to be modified: ENFORCHO, EISDDCHHO.

ENFORCHO:
This attribute enables/disables the sending of Forced HO Request messages for
running SDCCH connections. It is used to enable/disable Directed Retry. It
should be set to "disable" if in a network the MSC which the BSS is connected
to or other adjacent BSSs do not support the prevention of "back-HO".
EISDDCHHO:
This attribute allows to enable/disable MSC-controlled SDCCH-HOs (Directed
Retry). It simply prevents the sending of HO RQD message for SDCCH connections to the MSC. If it is set to "disable", the BSC shall skip all cells identifiers of
the target cell list of the Intercell HO Cond. message which belong to another
BSC area. The flag should be set to "disable" if the MSC does not support
Directed Retry.
Result: Setting of the BSC with the involved parameters.

432

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set the ADJC object with the involved parameters.

Select the command "SET ADJC" following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC

---> SET ADJC
and enter the values for the attributes to be modified: TIMERFHO, FHORLMO.

TIMERFHO:
This attribute specifies the timer running in the BTS that controls the duration of
how long a former serving cell, from which forced handover was performed to
the new serving cell, may not be considered in the handover decision algorithm
for power budget handovers of the new serving cell and may not be contained in
the target cell list. It is started during the direct retry procedure at the reception
of a Channel Activation message containing a Cell Identifier (no target) IE in the
'directed retry target BTS'.
FHORLMO:
This attribute defines the 'forced handover RXLEV minimum offset' which is
used by the handover decision algorithm to determine whether a neighbour cell
is regarded as suitable target cell for forced handover or not.
Result: Setting of the ADJC object with the involved parameters.

END

A30808-X3247-L210-3-7619

433

OMN:BSC

Operation
Base Station Controller

3.93

Concentric Cell Structure Management

Introduction
Concentric cell means two logical cells within one GSM Standard cell:

Max. 35 Km.

inner area

complete area

Fig. 3.93.18Concentric Cell Structure

the complete area, whose TRX subset is characterized by a higher transmission

power level and extends its coverage to a larger area (max. 35 Km)
the inner area, whose TRX subset is characterized by a lower transmission power
level and extends its coverage to a smaller area.

When the operator configures a concentric cell, he/she has to define per TRX whether
it should belong to the inner or the complete area. The BCCH frequency and all other
frequencies with control channels (CCCH, SDCCH) must belong to the complete area.
Frequency hopping is only possible within the same area. The frequency hopping
groups must not have elements from both areas.
The objects involved in the directed retry handling are:
1. BTSB
2. TRX
3. HAND
For more detailed descriptions of attributes and algorithms, please refer to the TED:
BSS.
Prerequisites
To define a cell as a colocated one it must be already equipped.
The value TRUE for CONCELL parameter is not accepted if the CELL_TYPE parameter
is set as EXTENDED.

434

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

To enter the following commands, the user must have the visibility level number set to
"2".

Set the BTS object with the involved parameter

Select the command "SET BTS following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->SET

BTS
and enter the values for the attribute to be modified: CONCELL.

CONCELL:
Flag to define a cell as a concentric one. If the flag is set as TRUE, the cell is
concentric. If the cell is defined colocated to another cell of the BSC, it is not
possible to delete it and it is necessary to remove before the relationship.
Result: Setting of the BTS with the involved parameter.

Set the TRX object with the involved parameter

Select the command "SET TRX" following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> TRX

---> SET TRX
and enter the values for the attribute to be modified: TRXAREA.

TRXAREA:
Attribute to define the pertaining area of the TRX of a concentric cell.
Result: Creation/Setting of the TRX object with the involved parameter.

A30808-X3247-L210-3-7619

435

OMN:BSC

Operation
Base Station Controller

Set the HAND object with the involved parameters

Select the command "SET HAND" following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> HAND

---> SET HAND
and enter the values for the attributes to be modified: CCDIST, HORXLVDI,
HORXLVDO, HOCCDIST, ININHO and CCELL.

CCDIST:
Flag to define the conditions for intracell handover decision in a concentric cell.
If the flag is set as TRUE the handover decisions are based BOTH on the downlink average receive level and timing advance. If the flag is set as FALSE the
handover decisions are based ONLY on the downlink average receive level.
HORXLVDI:
The attribute represents the downlink average receive level limit for handover
decision from inner to complete area. If the downlink average receive level is
lower than this limit, the intracell handover is required.
HORXLVDO:
The attribute represents the downlink average receive level limit for handover
decision from complete to inner area. If the downlink average receive level is
higher than this limit, the intracell handover is required. Due to avoid handover
oscillation this value must be higher than the HORXLVDI value.
HOCCDIST:
Ms distance limit for handover from the inner to the complete area and viceversa.
ININHO:
Flag to enable/disable the intercell handover from inner to inner area in sectorized cells.
CCELL:
The attribute allows to define which cells are to be considered as colocated to
the serving one. For these cells, it is possible, if enabled, to apply the intercell
handover from inner to inner area.
Result: Setting of the HAND object with the involved parameters.

END

436

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.94

OMN:BSC

Sleeping Cell Management

Introduction
The procedure allows the operator to detect as soon as possible whether the cell is
currently working or not (sleeping).
A cell will be marked as sleeping when in a given (fixed) time period either faked
Channel Requests only or no Channel Requests at all are received (faked means that
they are not related to any MS (UE in case of TD-SCDMA technology), but they are
generated by the BTS (BTSTD in case of TD-SCDMA technology) because of spurious
RACHs).
On detection of sleeping cell condition an alarm with severity MINOR will be issued (the
number of cell alarm is 66, the number of TRX alarm is 70).
The alarm is reset within 10 minutes after the SDCCH seizure (signalling channel
seizure in case of TD-SCDMA technology).
The alarm is set after no activity (no SDCCH has been seized) for X minutes, where X
is a value that can be set via configuration command. The value of X is given by the
multiplication of the number inserted by the operator and the 10 minutes said above.
The operator can set two time frames within the 24 hours and two different observation
periods for each time frame.
No alarm is set if the cell is disabled/locked or there is no SDCCH in service.
The procedure is switched on/off per cell via configuration command.
Prerequisites
To enter the following commands, the BTS/BTSTD must exist.
To enter the following commands, the user must have the visibility level number set at
"2".

Preliminary Consideration
Do you want to enable/disable sleeping cell detection for a GSM cell?
Do you want to enable/disable sleeping cell detection for a TD-SCDMA cell?

A30808-X3247-L210-3-7619

h ... 2
h ... 3

437

OMN:BSC

Operation
Base Station Controller

Set the object BTS with the involved parameters.

Select the command "SET BTS " following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS
and enter the values for the attributes to be modified: ENANCD, NCDP1,
NCDP2.

ENANCD:
This flag enables or disables the procedure of detection of sleeping cell
condition.
NCDP1
This attribute allows to configure the first time-frame for the sleeping cell
detection procedure. StartTime1 represents the beginning of the time-frame and
TimerNoCall1 represents the observation period.
NCDP2
This attribute allows to configure the second time-frame for the sleeping cell
detection procedure. StartTime2 represents the beginning of the time-frame and
TimerNoCall2 represents the observation period.
Result: Setting of the BTS TIMER package with the involved parameters.

438

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set the object BTSTD with the involved parameters.

Select the command "SET BTSTD" following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

SET BTSTD
and enter the values for the attributes to be modified: ENANCD, NCDP1,
NCDP2.

ENANCD:
This flag enables or disables the procedure of detection of sleeping cell
condition.
NCDP1
This attribute allows to configure the first time-frame for the sleeping cell
detection procedure. StartTime1 represents the beginning of the time-frame and
TimerNoCall1 represents the observation period.
NCDP2
This attribute allows to configure the second time-frame for the sleeping cell
detection procedure. StartTime2 represents the beginning of the time-frame and
TimerNoCall2 represents the observation period.
Result: Setting of the BTSTD TIMER package with the involved parameters.

END

A30808-X3247-L210-3-7619

439

OMN:BSC

Operation
Base Station Controller

3.95

Circuit Pool Concept

Introduction
The Circuit Pool concept identifies a set of circuits (TSLA) on A interface supporting the
same channel types (such as FR speech or HSCSD).
When the pool type for each TSLA is defined, the BSS system is arranged to handle the
channel type specified in the Assignment and Handover Request coming from MSC;
that implies a better allocation of terrestrial resources.
The Circuit Pool feature is particularly important for the introduction of the HSCSD
service, whose aim is to provide access rates higher than 9.6 kbit/s using up to four radio
timeslots for the same call. For an efficient management of HSCSD service, TRAU
Hardware (TRAU DSPs) must be configured in such a way to be able to handle multiple
connections on the same A timeslot. Pools configuration enables the system to set up
the appropriate Asub-A Transcoder Matrix used to configure the TRAU Hardware.
Since it cannot be stated if the connected MSC supports the feature or not, the
msc_pooling flag must be added to BSC object. Mixed configurations are admitted (for
example: BSC supporting, MSC not supporting pool).
Each TSLA has a new attribute named pooltype, it is possible to set and get the attribute
both from RC and from LMT.
In order to enable the operator to put off the Circuit Pool feature, the ENPOOL
parameter (BSC object) is introduced. The flag can be set to FALSE only if the pool
types of all the equipped TSLAs are defined and single-slot. When the pooling is
enabled (ENPOOL=TRUE) all TSLAs of all PCMA lines equipped assume:

the POOL_23 value for TRAUs where the YY-YY-YY-02-XX-XX_yy_mm_dd

software load is running (see "3.26 Download and Activate BTSE, BTSEC and
TRAU SW Loads" to get information about TRAU software loads);

the POOL_07 value for other TRAUs.

When the flag is off, the operator is not allowed to configure the TSLA pool types and
the HSCSD feature is not supported.
Tab. 3.95.21 shows the circuit pool number (1 to 48) with the corresponding supported
channels and speech coding algorithms. For the pooling types 42-48 see "3.96 Enabling
CTM Circuit Pool Solution for Text Telephone Calls".

440

The BSC will reject any ESCD (EDGE circuit switched) call required by the MSC and
related to circuit pools 30, 32, 33, 34, 35. As a matter of fact, the ECSD calls are
included in these pools but they are not supported by the BSC (see "3.47 Addition of a
Point-to-Point Packet Function (GPRS/EGPRS)").

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Pool Number
(POOL_<n>)

Supported Channels and

Speech Coding Algorithms

Circuit pool n. 1

FR speech version 1
FR data (12, 6, 3.6 kbit/s)

Circuit pool n. 2

HR speech version 1
HR data (6, 3.6 kbit/s)

Circuit pool n. 3

FR speech version 1
FR data (12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)

Circuit pool n. 4

FR speech version 2
FR data (12, 6, 3.6 kbit/s)

Circuit pool n. 5

FR speech version 1
FR speech version 2
FR data (12, 6, 3.6 kbit/s)

Circuit pool n. 6

FR speech version 2
FR data (12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)

Circuit pool n. 7

FR speech version 1
FR speech version 2
FR data (12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)

Circuit pool n. 8

HSCSD max 2 x FR data (12, 6 kbit/s)

Circuit pool n. 9

FR data (12, 6, 3.6 kbit/s)

HR data (6, 3.6 kbit/s)
HSCSD max 2 x FR data (12, 6 kbit/s)

Circuit pool n. 10

FR speech version 1
FR speech version 2
FR data (12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)
HSCSD max 2 x FR data (12, 6 kbit/s)

Circuit pool n. 11

HSCSD max 4 x FR data (12, 6 kbit/s)

Circuit pool n. 12

FR data (12, 6, 3.6 kbit/s)

HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (12, 6 kbit/s)

Tab. 3.95.21Circuit Pool Coding

A30808-X3247-L210-3-7619

441

OMN:BSC

Operation
Base Station Controller

Pool Number
(POOL_<n>)

Supported Channels and

Speech Coding Algorithms

Circuit pool n. 13

FR speech version 1
FR speech version 2
FR data (12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (12, 6 kbit/s)

Circuit pool n. 14
(not used)

HSCSD max 6 x FR data (12, 6 kbit/s)

EDGE max 2 x FR data (32.0 kbit/s)

Circuit pool n. 15

FR data (14.5 kbit/s)

Circuit pool n. 16

HSCSD max 2 x FR data (14.5 kbit/s)

EDGE FR data (29.0 kbit/s)

Circuit pool n. 17

HSCSD max 4 x FR data (14.5 kbit/s)

EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)

Circuit pool n. 18

FR data (14.5, 12, 6, 3.6 kbit/s)

HR data (6, 3.6 kbit/s)
HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)
EDGE FR data (29.0 kbit/s)

Circuit pool n. 19

FR data (14.5, 12, 6, 3.6 kbit/s)

HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)

Circuit pool n. 20

FR speech version 1
FR speech version 2
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)

Circuit pool n. 21

FR speech version 1
FR speech version 2
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)
HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)
EDGE FR data (29.0 kbit/s)

Tab. 3.95.21Circuit Pool Coding

442

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Pool Number
(POOL_<n>)

Supported Channels and

Speech Coding Algorithms

Circuit pool n. 22

FR speech version 1
FR speech version 2
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)

Circuit pool n. 23

Speech version 3

Circuit pool n. 24

FR speech version 3
FR data (12, 6, 3.6 kbit/s)
HR speech version 3

Circuit pool n. 25

FR speech version 1
FR speech version 2
FR speech version 3
FR data (12, 6, 3.6 kbit/s)
HR speech version 3

Circuit pool n. 26

FR speech version 1
FR speech version 2
FR speech version 3
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 3

Circuit pool n. 27

FR speech version 1
FR speech version 2
FR speech version 3
FR data (12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)

Circuit pool n. 28

FR speech version 1
FR speech version 2
FR speech version 3
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)

Tab. 3.95.21Circuit Pool Coding

A30808-X3247-L210-3-7619

443

OMN:BSC

Operation
Base Station Controller

Pool Number
(POOL_<n>)

Supported Channels and

Speech Coding Algorithms

Circuit pool n. 29

FR speech version 1
FR speech version 2
FR speech version 3
FR data (12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)
HSCSD max 2 x FR data (12, 6 kbit/s)

Circuit pool n. 30

FR speech version 1
FR speech version 2
FR speech version 3
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)
HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)
EDGE FR data (29.0 kbit/s)

Circuit pool n. 31

FR speech version 1
FR speech version 2
FR speech version 3
FR data (12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (12, 6 kbit/s)

Circuit pool n. 32

FR speech version 1
FR speech version 2
FR speech version 3
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)

Circuit pool n. 33

FR data (14.5, 12, 6, 3.6 kbit/s)

HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)
EDGE max 2 x FR data (32.0 kbit/s)

Tab. 3.95.21Circuit Pool Coding

444

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Pool Number
(POOL_<n>)

Supported Channels and

Speech Coding Algorithms

Circuit pool n. 34

FR speech version 1
FR speech version 2
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)
EDGE max 2 x FR data (32.0 kbit/s)

Circuit pool n. 35

FR speech version 1
FR speech version 2
FR speech version 3
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)
EDGE max 2 x FR data (32.0 kbit/s)

Circuit pool n. 36

FR speech version 4
FR speech version 5

Circuit pool n. 37

FR speech version 3
FR speech version 4
FR speech version 5
HR speech version 3

Circuit pool n. 38

FR speech version 1
FR speech version 2
FR speech version 3
FR speech version 4
FR speech version 5
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 3

Circuit pool n. 39

FR speech version 1
FR speech version 2
FR speech version 3
FR speech version 4
FR speech version 5
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)
HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)
EDGE FR data (29.0 kbit/s)

Tab. 3.95.21Circuit Pool Coding

A30808-X3247-L210-3-7619

445

OMN:BSC

Operation
Base Station Controller

Pool Number
(POOL_<n>)

Supported Channels and

Speech Coding Algorithms

Circuit pool n. 40

FR speech version 1
FR speech version 2
FR speech version 3
FR speech version 4
FR speech version 5
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)

Circuit pool n. 41

FR speech version 1
FR speech version 2
FR speech version 3
FR speech version 4
FR speech version 5
FR data (14.5, 12, 6, 3.6 kbit/s)
HR speech version 1
HR speech version 3
HR data (6, 3.6 kbit/s)
HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
EDGE max 2 x FR data (29.0 kbit/s)
EDGE FR data (43.5 kbit/s)
EDGE max 2 x FR data (32.0 kbit/s)

Circuit pool n. 42

FR speech version 1 + CTM

Circuit pool n. 43

FR speech version 2 + CTM

Circuit pool n. 44

FR speech version 1 + CTM

FR speech version 2 + CTM

Circuit pool n. 45

FR speech version 1 + CTM

FR speech version 2 + CTM
HR speech version 1 + CTM

Circuit pool n. 46

FR speech version 3 + CTM

HR speech version 3 + CTM

Circuit pool n. 47

FR speech version 1 + CTM

FR speech version 2 + CTM
FR speech version 3 + CTM
HR speech version 3 + CTM

Circuit pool n. 48

FR speech version 1 + CTM

FR speech version 2 + CTM
FR speech version 3 + CTM
HR speech version 1 + CTM
HR speech version 3 + CTM

Tab. 3.95.21Circuit Pool Coding

446

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Prerequisites
As a general rule, the operator will have to specify, on the same TRAU, one
NOT_DEFINED TSLA for each TSLA supporting HSCSD-MAX-2-TS-per call and three
NOT_DEFINED TSLA for each TSLA supporting HSCSD-MAX-4-TS-per call.
Note that, in order to reduce the number of operator commands to be issued when
changing the signalling channels configuration (X25, SS7), the signalling channel
creation is accepted independently from the number of NOT_DEFINED TSLA in the
system.
The presence of a transparent channel makes unavailable 4 TCHs on Asub interface; if
their pool types are not set at a special value, they could seem available for the traffic
while they are unused.
To enter the following commands, the user must have the visibility level number set at
"2".

Preliminary Consideration

It is supposed that we get a working system, so to configure the HSDSC service

and support HR the user has to follow the steps below:
set BSC
shutdown TRAU
set TSLA
unlock TRAU

A30808-X3247-L210-3-7619

h ... 2
h ... 3
h ... 4
h ... 5

447

OMN:BSC

Operation
Base Station Controller

Set BSC

To set BSC use the SET BSC command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET

BSC(ENPOOL parameter)

ENPOOL
This parameter indicates whether the TSLA pooling feature is activated on the
BSC side (enabling flag).TSLA pooling has to be activated if HSCSD (see
parameter ENHSCSD) is used on this BSC. If the pooling feature is enabled the
available A-interface timeslots are classified by a pooling type. The different
values for the pooling type are predefined and represent a certain combination
of different supported coding types for speech and data (see table at
command CREATE PCMA and SET TSLA). Thus the BSC can separately
manage the available resources, e.g. for ordinary speech calls and for high
speed data connections.
MSCPOOL
This parameter specifies whether the connected MSC is able to manage the
pooling feature or not.
As the MSC is the one to select the A-interface channels for a specific call the
MSC has to manage the pooling types assigned to the A interface resources,
too.
The range is: TRUE, FALSE.
Default: FALSE
Result: Set BSC with the enable pooling set.

Shutdown TRAU

To shutdown TRAU use the SHUTDOWN command following the next

sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> SHUTDOWN

TRAU

Result: Shutdown TRAU.

Set TSLA

To set all the TSLAs as multislot, enter the SET TSLA command following the
next sequence of selections:

b
i

448

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMA ---> TSLA

--->SET TSLA
Time slots have to be equally configured from both sides (MSC and BSC).

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Result: In this way the user can set the TSLA multislot as required for the
current application.
Note:
These setting operations can be also executed during the creation phases of the
PCMA objects for all the TSLA objects.

Unlock TRAU

To unlock the TRAU, use the SET BSC command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> UNLOCK TRAU

Result: Unlock TRAU. So a POOLING service on a TSLA is enabled.

END

A30808-X3247-L210-3-7619

449

OMN:BSC

Operation
Base Station Controller

3.96

Enabling CTM Circuit Pool Solution for Text Telephone

Calls
Introduction
In the U.S.A. the Federal Communications Commission (FCC) has mandated that
persons with hearing and speech disabilities must be able to use text telephone (TTY)
devices to make 911 emergency calls over digital wireless systems.
For implementation of the Global Text Telephone feature in the U.S. it has been decided
to adopt a CTM Circuit pool solution in the BSS access network, which is based on the
circuit pool concept. The functionality is provided via external equipment, inserted on the
PCMA side and physically integrated in the Siemens SBS.
The acronym CTM stands for Cellular Text Telephone Mode and refers to the transmission of text via the speech channel of cellular phone systems or PSTN networks.
The CTM detection/conversion function is incorporated in a separate entity associated
with the Transcoder. The CTM adapter automatically detects the presence of CTM
encoding and provides the necessary conversion to the appropriate V.18 modem
encoding.
Note: this feature is based on TRAU1, with fixed association between a circuit in a given
PCMA and a circuit in the PCMS. There is no impact on BTS and TRAU.

Fig. 3.96.19 Association of a CTM adapter with the transcoder in the access network

450

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Functional description
A new channel type CTM and new values for circuit pool number must be handled,
according to the circuit pools concept: the timeslots on A-interface are divided in pools
according to the channel type (Full Rate, HSCSD, etc....) they can support.
This classification in POOL of TSLA is known both at BSC and MSC side. The BSC
provides the right association between the TSLA and the TSLS during the pool configuration session providing the switching matrix that is sent to the TRAU; in this configuration session the BSC also assures that the TSL POOL will be associated with the
TRAC that supports the relevant CODEC. In this case for each pool number indicating
a CTM capability, the matrix is configured to the equivalent CODECS.
The MSC, in case of incoming call or handover request, will choose the TSLA in the pool
supporting the channel type for the call in process; in the CTM case the main steps of
the process for a mobile originated call are:

Setup from terminal, including CTM indication.

MSC detects CTM indication and allocates a circuit with CTM capabilities.
The main steps of the process for a mobile terminated call are:

Setup from MSC.

Call Confirm from terminal including CTM indication.

Prerequisites
A prerequisite for GTT service is the availability of Circuit Pool concept on A interface.
To manage this feature the following values have been added to the POOLTYP attribute
of the TSLA object and the DEFPOOLTYP attribute of the PCMA object:

POOL-42

POOL-43

POOL-44

POOL-45

POOL-46

POOL-47

POOL-48

In order to have no impact on TRAU1, the BSC will map the CTM pool_type values, on
Asub interface, on the already existing ones supporting the same Speech Coding algorithms. In particular:

A30808-X3247-L210-3-7619

POOL_42 -> POOL_1

POOL_43 -> POOL_4
POOL_44 -> POOL_5
POOL_45 -> POOL_7
POOL_46 -> POOL_23
POOL_47 -> POOL_25
POOL_48 -> POOL_27

451

OMN:BSC

Operation
Base Station Controller

When the pooling is enabled by the operator (see "3.95 Circuit Pool Concept") the
POOL_23 is assigned automatically by the system to all TRAUs that support a software
load containing S2xxxx.BIN as DSPs executable (see "3.26 Download and Activate
BTSE, BTSEC and TRAU SW Loads"), i.e.POOL_23 is assigned automatically by the
system to all TRAUs supporting the YY-YY-YY-02-XX-XX_yy_mm_dd software version.

Preliminary Consideration

Y h ... 4
N h ... 3

Is the ENPOOL attribute set to FALSE?

Set BSC

To set BSC the user must use the SET BSC command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC (with

ENPOOL = TRUE)

Result: Set BSC with the enable pooling set.

Shutdown TRAU

To shutdown TRAU the user must use the SHUTDOWN command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> SHUTDOWN

TRAU

Result: Shutdown TRAU.

Set TSLA

To set all the TSLA as multislot user must follow the next sequence of selections.

b
i

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMA ---> TSLA

---> SET TSLA
Time slots have to be equally configured from both sides (MSC and BSC).

Result: In this way the user can set the TSLA multislot as required for the CTM
application.
Note:
These setting operations can be also executed during the creation phases of the
objects PCMA for all the TSLA.

452

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Unlock TRAU

To unlock TRAU the user must use the SET BSC command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> UNLOCK TRAU

Result: Unlock TRAU. So a POOLING service on a TSLA is enabled.

END

A30808-X3247-L210-3-7619

453

OMN:BSC

Operation
Base Station Controller

3.97

HSCSD Service
Introduction
HSCSD service allows MSs subscribing to the General Bearer Services to make use of
data rates higher than what possible up to now. HSCSD also defines mechanisms for a
flexible use of air interface resources which make feasible the efficient use of higher user
rates.
The air interface user rate, i.e. the transfer rate in radio interface for user data, in the
current data transmission is limited to 14,4 Kb/s. HSCSD is the faster solution to introduce in the network the capability to handle higher air interface user rate enabling the
co-allocation of multiple (up to 4) full rate traffic channel into a HSCSD configuration.
Even if HSCSD minimizes the changes at the air interface and in the existing infrastructure, this enhancement of the current system requires new additional signalling at Um,
Abis, A Interface (i.e. changed Assignment and Handover messages, methods to assign
additional timeslots to a running data call, etc.).
On the A interface, the use of resources is restricted to one 64 Kb/s circuit by multiplexing the data streams into one A interface circuit.
HSCSD Service has the following characteristics:
-

support of 14,4 Kb/s channel coding

introduction of BTS/MS originated upgrade/downgrade procedure correct
management of TCH single slot (signalling/speech) HSCSD data transition
a forced intracell handover procedure will be introduced for the HSCSD
Assignment case
introduction of non quality Intracell Handover for concentric cell
BTS measurement pre-processing carried out on every bi-directional
channel (BTS task)

Prerequisites
A prerequisite for HSCSD service is the availability of Circuit Pool concept on A interface.
For an efficient management of HSCSD service, TRAU Hardware (TRAC DSPs) must
be configured in such a way to be able to handle multiple connections on the same A
timeslot. Pools configuration enables the system to set up the appropriate Asub-A
Transcoder Matrix used to configure the TRAU Hardware.
The installation of HSCSD on SBS system requires first of all the planning of A Interface
pools: it must be decided which services will be supported by the various TSLA
managed by the TRAUs connected to the BSC. This task must be executed together
with MSC responsible, in order to ensure that the same TSLA is configured with the
same pool type on both BSC and MSC side.
The enabling of HSCSD forces the rules used to configure the CHAN objects.
The group of Radio Channels available for HS+CSD depends upon the hopping mode
used:

454

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

In case of Base Band Hopping, on a given TRX only timeslots from 1 to 7 can be
used, single traffic channels equipped on these timeslots have to have the same
FHSYID. If one or more CCCH channel is already equipped, channels on the
BCCH-TRX cannot hop
If synthesizer hopping is used, on a given TRX different from the BCCH one, all
single traffic channels have the same FHSYID and must have the same TSC
The Forced Intracell HO flag can be enabled to increase the successful allocation probability of HSCSD calls. If the HSCSD flag is set to false, either at BTS level or at BSC
level, its value is meaningless.
It has to be noticed that the Early Classmark sending must be enabled, setting the
attribute to TRUE, otherwise the Mobile Station doesnt send its multislot information to
the network.
The flag BTSHSCSD cannot be set to TRUE if the attribute EARCLM (of the BTS) is set
to FALSE.
In order to enable the HSCSD service the EARCLM flag must be previously set to
TRUE.
To enter the following commands, the user must have the visibility level number set to
"2".

Preliminary Consideration

To configure a system that provides an HSCSD service the user has to follow
the steps below:
set BSC
set BTS

h ... 2
h ... 3

Set BSC

To set BSC the user must use the SET BSC command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

ENHSCSD
This attribute indicates whether the HSCSD service is activated on the BSC site
or not.
ENFOIAHO
This attribute indicates whether the Forced Intracell Handover procedure is
activated or not.
Result: Set BSC. The ENHSCSD attribute has to be defined TRUE.

A30808-X3247-L210-3-7619

455

OMN:BSC

Operation
Base Station Controller

Set BTS

To set BTS the user must follow the next sequence of selections.

MANAGED-ELEMENT ---> BSS-FUNCTIONAL --> BTSM ---> BTS --->

SET BTS

EARCLM
This attribute specifies whether the EARCLM sending procedure is enabled.
BTSHSCSD
This attribute indicates whether the HSCSD service is activated in that cell or
not.
Result: Set the BTS option attribute group with the EARCLM and BTSHSCSD
parameters defined as TRUE.

END

456

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.98

OMN:BSC

Queueing, Preemption and Directed Retry for TCH

Introduction
This feature allows the assignment of a TCH when, due to the unavailability of the
resources, no empty channel can be found within the serving cell. Three main procedures are possible:
a) Preemption, which is a means of providing TCH resources for high priority TCH
request;
b) Directed Retry, which causes the handover from a SDCCH in one cell to a TCH in
another cell;
c) Queuing, which allows the queuing of TCH requests on a per cell and priority basis.
In case of unavailability of resources, two cases can be foreseen: Assignment Request
and Handover Request.
In case of Assignment Request, the preemption is tried first: BSC looks for a call in the
cell with a priority lower than the new TCH request and, then, moves the lower priority
call in another cell performing a Forced Handover (or a Forced Release if the HO fails)
in order to free the TCH and assigns it to the new request.

In case of Full Rate channel requests, the preemption is applied only to vulnerable calls
that are allocated on Full Rate channels. No preemption of Half Rate calls is performed.
This restriction is due to impossibility, with actual implementation, to be sure that after
the pre-emption procedure the other part of the channel is still available.
If the conditions dont allow this procedure, the Directed Retry is performed. In case no
TCH can take place, the queuing procedure is then carried out, storing the TCH requests
in the cell queue in base of their priority.
In case of handover Request, the preemption is tried first as previously described. If the
preemption fails, the Directed Retry procedure will be skipped and the queuing is carried
out.
If the Assignment request (or the Handover request) comes from the MSC while no free
TCHs are available in the cell, and GPRS/EGPRS calls are active in the cell, the
GPRS/EGPRS downgrade strategy is foreseen between Directed Retry and Queuing
procedures. The downgrade of PDCH channels (i.e. channel used for GPRS/EGPRS)
is started using the following strategy:

the BSC looks if there are channels in the cell used as PDCH for GPRS/EGPRS
service;
if there are some not-reserved GPRS/EGPRS channels, the downgrade of PDCH
channels is started in order to free resources to be used by CS services (see also
"3.104 Management of Radio Resources").

Prerequisites

A30808-X3247-L210-3-7619

Preemption and ASCII calls

During the research of the vulnerable TCH, BSC has not to take into account the
TCH engaged for ASCI or HSCSD calls. Besides, only for ASCI calls, BSC performs
the Preemption procedure also for Inter Cell Handover when within the target cell no
free TCH assigned to the calling subscriber or the subsequent talker in a ASCI call.
In case of Inter Cell Handover with regard to the ASCI calls, only the Preemption
procedure has to be performed by BSC.

457

OMN:BSC

Operation
Base Station Controller

Preemption and HSCSD calls

The Preemption is foreseen to handle single time slot, therefore this feature will be
applied, in case of HSCSD, only for the calls where a single TCH has been assigned.

Directed Retry
Directed Retry procedure is never performed for ASCI calls

Queuing
BSC queues only the TCH request relative to the Handover Request that are not
derived by Directed retry or Preemption procedure. To avoid to queue a TCH request
relative to an handover Request message due to a Directed Retry or a Preemption
procedure, BSC fills the cause IE with the Directed Retry or No Radio Resource
Available values, respectively.

The user must have the visibility level set to number 2.

Preliminary Consideration

To configure the feature the user has to follow the steps below:

h ... 2
h ... 4

set BSC
set BTS

Set BSC (BASICS group parameters)

To set BSC base package the user must use the SET BSC command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

EPREHSCSD
This attribute is used to enable or disable the preemption for the HSCSD
request.
Result: Setting the EPREHSCSD attribute.

Set BSC (TIMER group parameters)

To set BSC timer package the user must use the SET BSC command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

BSC11
This attribute is used to establish the maximum allowed queuing time.
BSCTQHO
This attribute is used to establish the maximum allowed queuing time for
handover.
Result: Setting the BSC timer package involved in the feature.

458

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set BTS

To set BTS the user must use the SET BTS command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS

EQ
This attribute is used to enable or disable the feature; if the value is disabled, no
TCH request is queued but all the requests already queued are considered.
QL
This attribute is used to establish the absolute queue length.

This parameter is evaluated according to the following formulas:

QUEU_LEN = Q*A=N*Q/T + threshold
T: average time per call
N: number of (occupied) channels per BTS
A: average number of released channels (A=N/T)
Q: queuing time
Example: T=120s; N=40; Q=30s; QUEU_LEN=40*30/120=10

EPRE
This attribute is used to enable or disable the preemption feature.
Result: Setting the BTS option package attributes involved in the feature.

END

A30808-X3247-L210-3-7619

459

OMN:BSC

Operation
Base Station Controller

3.99

Voice Group Call Service

Introduction
Todays GSM networks are designed for point-to-point connections. For professional
users, traditionally special networks called Private Mobile Radio (PMR) or Public Access
Mobile Radio (PAMR) are available. A key functionality of these networks is the special
function point-to-multipoint or Group Call. With this feature those users will get an alternative using GSM networks.
A VGCS is characterized by following key points:

A group call number combines all members of a dedicated group.

For each group call a service area composed out of a number of cells is assigned.
Dialling the group call number initializes the parallel set-up of connections into all
cells of the assigned service area. All members of this group being in the service
area will be paged to receive a notification of the ongoing group call.
Dependent on the call ID and priority members of the group call can decide to join
the call.
During the call the actual speaker can change.

Members of the group being in the group call area are connected only via downlink, that
means they can only listen to the call. If the actual speaker stops speaking, he has to
indicate that he releases the uplink. This indication is sent to the listeners. Those
listeners who want to become the next talker have to send a corresponding request,
while using the so called push-to-talk button. The next (succeeding) talker is selected on
first come first served base.
The sequence of change of talker is as follows:
1. release of the dedicated link by the actual speaker and change to the common
downlink of this cell
2. network indication to the listening subscribers that the uplink is free
3. the possible new talker sends an uplink request
4. the network either allocates a dedicated link or enables the use of the uplink of the
group call channel for the subsequent new talker
5. the new talker sends an uplink request confirmation
6. the other listening subscribers receive an uplink seized or uplink reject (if they issued
a request)
Prerequisites
To use the full functionality of this feature, the MSC and MS have to support Voice Group
Call Service.

Preliminary Consideration

To configure the feature the user has to follow the steps below:
set BSC
set BTS (CCCH attribute group)
set BTS (TIMER attribute group)

460

h ... 2
h ... 3
h ... 4
A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set BSC

The user must use the SET BSC command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

ASCIONECHMDL
This attribute is used to enable or disable the use of uplink of group call channel
by the subsequent new talker
To enable the use of uplink of group call channel by the new talkert the user
must set this parameter to TRUE..
To disable the use of uplink of group call channel by the new talkert the user
must set this parameter to FALSE.
Result: Enabling the use of uplink of group call channel by the subsequent new
talker for the whole BSS

Set BTS (CCCH attribute group)

The user must use the SET BTS command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS

ASCISER
This attribute is used to enable or disable the VGCS service in the cell.
To enable VGCS service the user must set this parameter to ASCI_ENABLED.
To disable VGCS service the user must set this parameter to ASCI_DISABLED.
NOCHFBLK
This attribute defines the first block to be used for NCH channel.
NOCHBLKN
This attribute defines the number of blocks to be used for NCH channel.
NBLKACGR
This attribute defines the number of TDMA frames reserved for the Access
Grant channel during a period of 51 TDMA frames (a multiframe).
To enable ASCISER, the NBLKACGR must be greater than NOCHBLKN.
Result: Setting the BTS control package attributes involved in the feature.

A30808-X3247-L210-3-7619

461

OMN:BSC

Operation
Base Station Controller

Set BTS (TIMER attribute group)

To set BTS timer package the user must use the SET BTS command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS

TGRANT
This attribute is used for the repetition of the VGCS_UPLINK.
NRPGRANT
This attribute defines the maximum number of repetition of
VGCS_UPLINK_GRANT message during an uplink access procedure.
VGRULF
This attribute defines the timer used for the repetition of UPLINK_FREE
message.
TNOCH
This attribute defines the timer used for the minimum period for NOTIFICATION
message.
Result: Setting the BTS timer package attributes involved in the feature.

END

462

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.100

OMN:BSC

Voice Broadcast Service

Introduction
Todays GSM networks are designed for point-to-point connections. For professional
users, traditionally special networks called Private Mobile Radio (PMR) or Public Access
Mobile Radio (PAMR) are available. A key functionality of these networks is the special
function point-to-multipoint calls, known as Broadcast Calls
A VBS is characterized by following key points:

A broadcast call number combines all members of a certain group.

For each broadcast call a service area composed out of a number of cells is
assigned.

Dialling the broadcast call number initializes the parallel set-up of connections into
all cells of the assigned service area. All members of this group being in the service
area will be paged to receive a notification of the ongoing voice broadcast call.

Dependent on the call ID and priority of a group call (e.g. emergency broadcast)
members of the group call can decide to join the call or not.

If a broadcast call number is dialled, the MSC recognizes that this number belongs to a
broadcast group. The MSC retrieves all the necessary information from the Group Call
Register (GCR). This GCR stores tables with

the group ID

the group call area ID

the group call references

the cell list corresponding to the group call area ID (max. 50 cells)

the dispatcher list corresponding to the group call references (up to 6 dispatchers)

per group call reference an information whether the call is active or not

an information about codecs

security information

In addition each member of a group has to have an HLR subscription for this teleservice.

The MSC connects the so called dispatchers with a duplex connection and initializes the
set-up of half-duplex connections to all the cells belonging to the group call area.
Members of the group being in the group call area are connected only via downlink, that
means they can only listen to the call.
Prerequisites
To use the full functionality of this feature, the BSS and MS have to support Voice Broadcast Service.

A30808-X3247-L210-3-7619

463

OMN:BSC

Operation
Base Station Controller

Preliminary Consideration

To configure the feature the user has to follow the steps below:

h ... 2
h ... 3

set BTS (CCCH attribute group)

set BTS (TIMER attribute group)

Set BTS (CCCH attribute group)

To set BTS control package the user must use the SET BTS command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS

ASCISER
This attribute is used to enable or disable the VBS service in the cell.
To enable VBS service the user must set this parameter to ASCI_ENABLED.
To disable VBS service the user must set this parameter to ASCI_DISABLED
NOCHFBLK
This attribute defines the first block to be used for NCH channel.
NOCHBLKN
This attribute defines the number of blocks to be used for NCH channel.
NBLKACGR
This attribute defines the number of TDMA frames reserved for the Access
Grant channel during a period of 51 TDMA frames (a multiframe).
To enable ASCISER, the NBLKACGR must be greater than NOCHBLKN.
Result: Setting the BTS control package attributes involved in the feature.

Set BTS (TIMER attribute group)

To set BTS timer package the user must use the SET BTS command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS

TNOCH
This attribute defines the timer used for the minimum period for NOTIFICATION
message.
Result: Setting the BTS timer package attributes involved in the feature.

END

464

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.101

OMN:BSC

Enabling enhancements in ASCII services

Introduction
This feature is an enhancement of the following ASCI services:

Voice Broadcast Service (VBS), see "3.100 Voice Broadcast Service";

Voice Group Call Service (VGCS), see "3.99 Voice Group Call Service".

It consists mainly of two new procedures, strictly related between them:

1. the uplink reply procedure;
2. the notification response procedure.
These procedures allow to avoid waste of radio resources: this is obtained by allocating
group/broadcast channels for the ASCI calls only in cells where at least one MS
subscriber is present.
Monitoring the presence of listener subscribers in the cell for a given call is a task of the
BTS:
1. the BTS uses the uplink reply procedure to investigate if in a cell there are any MS
subscribers, which make use of a call related to ASCII service;
2. when no MS subscribers are detected in a cell, the group/broadcast channel for that
call in the cell is released. In this case, Notification/NCH is still sent on air, but without
description of the group channel (because the group channel is no longer assigned
on that cell);
3. when a late entry occurs (i.e. a MS subscriber enters that cell), this MS has to start
the notification response procedure, to make its presence known at the BTS. As a
consequence, the network will reactivate the group/broadcast channel in the cell.
The new procedures related to these enhancements of ASCII services are described in
the following.
UPLINK REPLY procedure
The Uplink reply procedure is a periodic procedure, handled by the BTS. It can be
applied on every group/broadcast channel (i.e. traffic common channels used during
ASCI calls, both VGCS and VBS). Substantially, its purpose is to release a group/broadcast channel if no listening subscribers are present in that cell. The UPLINK FREE
message is used to perform the polling intended to monitor the presence of MS listeners.

This UPLINK FREE has not the same shape and meaning as the Uplink Free message
used during Talker Change procedure of VGCS calls. The MS understands this fact
reading the <Uplink Access Request> bit, which is set to a value indicating at the same
time:
1) that the MS has to perform the uplink reply procedure;
2) that the uplink is not free for the uplink access procedure: so a VGCS mobile will not
try to seize the uplink.
The polling works as follows.
When BSC activates a new group/broadcast channel, it decides if the uplink reply procedure has to be performed on this channel, according to:
1. the evaluation of the assignment requirement type sent by MSC (see below);

A30808-X3247-L210-3-7619

465

OMN:BSC

Operation
Base Station Controller

2. the database parameter that indicates if the uplink reply feature is enabled. To
enable the uplink reply feature (and consequently the notification response procedure) the ASCIULR (AsciiUplinkReply) parameter is used;
3. the BTS sw version.
If the polling has to be performed, the BSC has to include inside the CHANNEL ACTIVATION message sent to relevant BTS the new IE Channel Options, filled with the
value Bts shall perform polling. On the contrary, either if no Channel Options IE is
included, or if it is included with the value Bts shall not perform UL-Reply procedure,
relevant BTS knows that polling on that channel has not to be performed.
In case Uplink Reply procedure has to be carried out, the BTS, immediately after having
activated the group/broadcast channel, starts the TUPLREP timer; this timer defines the
frequency used by the BTS to send the UPLINK FREE messages, related to the Uplink
Reply procedure. When this timer expires, the BTS has to send on the channel an
UPLINK FREE message.
If a MS is listening on that channel, it must reply sending two UPLINK ACCESS
messages, in order to signal to the network its presence in the cell. These UPLINK
ACCESS must have Establishment cause field filled with value Reply on uplink
access request
Another timer, called Twupa (this timer is internal to BTS, and it is not visible to the operator) has to be started by the BTS immediately after having sent the UPLINK FREE
message, containing the uplink access request. When the two UPLINK ACCESS are
received, this timer is stopped. If no subscriber reply is received within the expiry of this
timer, the BTS sends on Abis the new proprietary message VBS/VGCS CHANNEL
RELEASE INDICATION.
Receiving this message, the BSC decides to release that group/broadcast channel,
decollating the radio resource. After having released the group/broadcast channel, the
BSC has to send a new NOTIFICATION COMMAND to the BTS that does not include
Group Channel Description IE (in fact when the BSC normally assigns a channel for
VBS/VGSC services, it sends to the BTS the NOTIFICATION COMMAND, including the
Group Channel Description IE).

In case of VGCS calls, the BSC will not deallocate the group/broadcast channel if the
VBS/VGCS CHANNEL RELEASE INDICATION refers to the same cell as the talkers
one. In this way, when the MS talker releases the uplink and joins the call as a listener,
it wont have to listen to NCH and perform Notification Response procedure, avoiding to
lose some speech.

NOTIFICATION RESPONSE procedure

When a MS ASCI subscriber enters a cell, it listens to NCH. If a Notification/NCH for its
group ID is being broadcasted without an included Group Channel Description, this
means that an ASCI call for that group ID is in progress, but no group/broadcast channel
is present in that cell.
As a reaction, the MS should follow the standard procedure to get an SDCCH, sending
a CHANNEL REQUIRED.

466

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

After the assignment of the signalling channel, the MS sends a NOTIFICATION

RESPONSE message (new message), indicating that it has received the notification
and it wants to enter the call as a listener.
BSC after having received this message re-activates the group/broadcast channel in the
cell, by means of standard Channel Activation procedure.
After the activation of the new channel, BSC sends to relevant BTS the NOTIFICATION
COMMAND message with Command Indicator set to REPLACE (see below) and
with the new Channel Description (the channel description is contained inside the
Group Channel Description IE)
Strictly related to the previous procedures, two arguments must be treated; they regard:
1. the Assignment Requirement type: when the MSC sends to the BSC the
message VBS/VGCS ASSIGNMENT REQUEST, in order to allocate group/broadcast channel in a cell, three different types of allocation can be required:
Immediate and the resources may further be de-allocated by the BSS: in this
case, the BSS will apply Uplink Reply procedure to that group/broadcast channel.
Immediate and the resources shall not be de-allocated until the end of the call: in
this case, the BSS cannot apply Uplink Reply procedure to that group/broadcast
channel; so, even if the feature is enabled (using the ASCIULR parameter), the
channel will never be deallocated: in other words, the situation is the same as in
ASCI Step 1.
Delay allowed: No group/broadcast channel is allocated by BSS. Notification/NCH is sent in the cell, without channel description.Only when a MS
subscriber will perform Notification Response procedure the radio resource will
be assigned.
2. the Notification Command: a proprietary value has to be defined in the Command
Indicator IE: besides START and STOP, also REPLACE has to be added. In
the following the new situations in which BSC has to send NOTIFICATION
COMMAND are described:
when a group/broadcast channel is deallocated as a result of uplink reply procedure, BSC sends to relevant BTS a NOTIFICATION COMMAND with Command
Indicator set to REPLACE and without Channel Description included: from
now on, BTS will send in air a new Notification/NCH Um message with no channel
description included;
In a similar way, when the group/broadcast channel is reallocated as a result of
notification response procedure, BSC sends to relevant BTS a NOTIFICATION
COMMAND with Command Indicator set to REPLACE and with the new
Channel Description included;
another new situation that requires sending of NOTIFICATION COMMAND is
when MSC requires delayed allocation in a cell: in this case, no group/broadcast
channel is allocated; nevertheless, BSC sends to relevant BTS a NOTIFICATION
COMMAND with Command Indicator set to START and without Channel
Description included. The channel will be allocated only if notification response
procedure will be performed by a MS subscriber, causing again BSC to send a
new NOTIFICATION COMMAND with Command Indicator set to REPLACE
and with the new Channel Description included, as previously described.

A30808-X3247-L210-3-7619

467

OMN:BSC

Operation
Base Station Controller

To summarize, the management of the described procedures related to ASCII services

is introduced in the BSS system, by two parameters:
1. ASCIULR (AsciiUplinkReply): it belong to the BTS object (BASICS attribute group);
it allows to enable/disable the uplink reply procedure for both VCS and VGCS
services. The possible values are:

ULRDISABLE; no Uplink Reply is enabled

VBS_ENABLE; VBS Uplink Reply is enabled
VGCS_ENABLE; VGCS Uplink Reply is enabled
VBS_VGCSENABLE; both VBS and VGCS Uplink Reply are enabled.

2. TUPLREP (TimerUplinkReply): it is related to the BTS object (BASICS attribute

group). The value of this timer is sent to the BTS that uses it for starting the uplink
reply procedure. The range of this timer is from 5 to 60 sec. The default value is
assumed to be 20 sec.

Prerequisites
To enable the Uplink reply procedure the following conditions must be satisfied:
1. if the user wants to enable the procedure for VBS service, the VBS service must be
enabled, see "3.100 Voice Broadcast Service";
2. if the user wants to enable the procedure for VGCS service, the VGCS service must
be enabled; see "3.99 Voice Group Call Service"
The user must have the visibility level number set to "2";
The network element must be in phase "2".

Choose the operation you want to do

h ... 2
h ... 3

Would you like to enable the Uplink Reply procedure?

Would you like to set the Uplink Reply Timer?

Enable the Uplink Reply procedure on a cell

To enable the Uplink Reply procedurein a cell, the user must enter the SET BTS
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

Then the user must set the value of the ASCIULR parameter (CONTROL group)
according to its needs.
Result: the uplink reply features is enabled in the cell.

468

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Change the Uplink reply Timer

To change the timer value, the user must enter the SET BTS command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

Then the user must set the value of the TUPLREP parameter (TIMER group)
according to its needs.
Result: the value of timer is changed.

END

A30808-X3247-L210-3-7619

469

OMN:BSC

Operation
Base Station Controller

3.102

Enabling Cell load dependent activation of HR channels

Introduction
The feature cell load dependent activation of Half Rate channels in one cell, has been
introduced to permit the allocation of HR channels only during high peak of traffic in the
cell, i.e. when additional capacity is needed.

Obviously, the half rate channels allocation modality must be enabled in the BSC.
The algorithm works changing the channel preference required by the MSC, in the
ASSIGNMENT REQUEST message, in FULL rate preferred or HALF rate preferred
according to the percentage of busy TCH (with respect to the number of configured
ones).
When the feature is enabled, every times the MSC sends an ASSIGNMENT REQUEST
command to the BSC, the BSC, before assigning a channel, calculates the percentage
of busy TCHs in the cell and than compares this value with a threshold set by the operator. Then the following decisions can be taken from the BSC:
1. if the threshold is equal to 0, the request is always changed, if the MS support it, in
HALF rate preferred;
2. if the percentage of busy TCH is greater than the threshold, the request is changed,
if the MS support it, in HALF rate preferred;
3. if the percentage of busy TCH is equal or less than the threshold, the request is
changed in FULL rate preferred.
The percentage of busy TCH is calculated in the following way:

Percentage_busy_TCH =Number_of _busy_TCH * 10000/Number_of_configured_TCH

where:

Number_of_busy_TCH = Number_out_of_service_TCH + Number_of_busy_full_TCH

+ Number_of_busy_half_TCH +
(Number_of_busy_full_and_half_TCH_used_as_full_TCH *2)
Number_out_of_service_TCH = Number_of_configured_TCH (Number_of_available_full_TCH + Number_of_available_full_and_half_TCH )
Number_of_configured_TCH = Number_of_full_TCH +
Number_of_full_and_half_TCH * 2) +( Number_of_TCHSD_mixed_pool * 2 )

470

The Number_of_TCHSD_mixed_pool represents the number of channels defined as

TCH/SD belonging to the TCHSDPOOL (see PROC: Smooth Channel Modification)

To avoid the point in the calculation of the Percentage_of_busy_TCH, the value of the
threshold is expressed in x10000 and not in x100; so the range is from 0 (it means
always HALF_RATE) to 10000 (it means that the mobile preference is respected).

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Then, some counters are defined to calculate the percentage of busy TCH in a cell;
these counters are internal to the system and they are not visible to the user. In particular, for every cell, there the following counters are defined:

a counter to indicate how many FULL_RATE channels are available;

a counter to indicate how many FULL_AND_HALF_RATE channels and TCH/SD
channels, with mixed pool or TCH pool, are available. The counter is updated for
each available sub-channel;
a counter to indicate how many FULL_RATE channels are busy;
a counter to indicate how many HALF_RATE channels are busy;
a counter to indicate how many FULL_AND_HALF_RATE channels and TCH/SD
channels, with mixed pool or TCH pool, are busy and used as FULL_RATE channels.

Note that also an out of service channel is considered busy. Every time a channel is
assigned, the counters of busy TCH must be increased; every time a channel is released
the counters of busy TCH must be decreased.
Before assigning a channel or enqueuing a request, the counters must be checked to
calculate the percentage of busy TCH in the cell. The value is compared with the
threshold defined by operator and if the number of busy TCH is above the threshold, a
TCH/H is assigned, only if the MS is able to support the HALF_RATE. This algorithm is
shown in Fig. 3.102.20, supposing that:
1. the HALF_RATE modality is enabled for the BSC;
2. MS support HALF_RATE;

A30808-X3247-L210-3-7619

471

OMN:BSC

Operation
Base Station Controller

ASSIGNMENT
REQUEST

Cell load dependent

activation of Half_Rate
is enabled?
Y

Allocation of Half_Rate
traffic channel

Threshold set by operator

is equal to 0?
N

Allocation of Half_Rate
traffic channel

The percentage of busy

TCH is > Threshold set by
operator?
N

Allocation of Required
traffic channel

Fig. 3.102.20 Cell load dependent activation of HR algorithm

To manage this feature the following parameters are foreseen inside the BSS system;
the parameters belong to the BTS object.
1. enableHrActivation parameter (EHRACT); this attribute allows to enable the feature
on a cell basis; it can assume the values TRUE/FALSE (the default value is FALSE,
that is feature not enabled);
2. the following two thresholds used to indicate the percentage of busy TCH in the cell:
the first threshold (hrActivationThreshold1 - HRACTT1) is used in case of Standard cell, Complete area of a Concentric cell and Far area of an Extended cell;
(the default value of this threshold is 6000, that means 60%)
the second threshold (hrActivationThreshold2 - HRACTT2) is used in case of
Inner area of a Concentric cell and Near area of an Extended cell; (the default
value of this threshold is 6000, that means 60%).
This feature can also be applied to Adaptive Multirate calls (see "3.110 Management of
Adaptive Multirate Codec (AMR)"); in this case the following parameters are foreseen
inside the BSS system to manage the functionality:
1. enableHrActivationAmr parameter (EHRACTAMR); this attribute (BSC object)
allows to enable the feature on a cell basis; it can assume the values TRUE/FALSE
(the default value is FALSE, that is feature not enabled);

472

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

2. the following two thresholds used to indicate the percentage of busy TCH in the cell
supporting AMR (parameters belong to BTS object):
the first threshold (hrActivationAmrThreshold1 - HRACTAMRT1) is used in case
of Standard cell, Complete area of a Concentric cell and Far area of an Extended
cell; (the default value of this threshold is 6000, that means 60%)
the second threshold (hrActivationAmrThreshold2 - HRACTAMRT2) is used in
case of Inner area of a Concentric cell and Near area of an Extended cell; (the
default value of this threshold is 6000, that means 60%).

In case of Concentric/Extended cells, when in the inner/near area a TCH/H is required

(from the algorithm explained above) and in the inner/near area there are no more available channels, a TCH/H of the complete/far area is allocated, without checking again
the percentage for this area. The same things is applied when a TCH/F has to be
assigned in the inner/near area and no resources are available.
Besides, pay attention when in a cell configured as Extended or Concentric, the cell load
dependent feature has been enabled. If in the inner/near area no dual rate traffic channels have been configured, it is assumed that the Half Rate service is not enabled in that
area, so the Full Rate preference is always set for new incoming request to be served
there; in this case if in the inner/near area no resources are available for a Full Rate call,
a Full Rate channel will be assigned in the complete/far area even if in this last one dual
rate channels have been configured.

To get more detail about the usage of this feature, see PROC: Management of Radio
Resources.

When the flexible abis allocation strategy is used, if the Cell load dependent activation
of Half Rate for the Radio Interface is enabled, it is also enabled taking into account
the Abis Interface congestion state (please refer to "3.40 Configuration of the Abis
Interface").
Prerequisites
The HALF_RATE modality must be enabled for the BSC.
The user must have the visibility level number set to "2".
The network element must be in phase "2".

Preliminary Consideration
Would you like to manage the feature in case of NOT AMR calls?
Would you like to manage the feature in case of AMR calls

A30808-X3247-L210-3-7619

h ... 2
h ... 3

473

OMN:BSC

Operation
Base Station Controller

Enable the Cell load dependent activation of Half Rate channels (NOT AMR
calls)

To enable this feature, the user must enter the SET BTS command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS

Then the user must set the EHRACT attribute to TRUE. The user can also
choose the threshold values through the HRACTT1 and HRACTT2 attributes (all
these attributes belong to the BASICS group).

h ... END

Result: Cell load dependent activation of Half Rate is enabled.

Enable the Cell load dependent activation of Half Rate channels for AMR
calls

To enable this feature, the user must enter the SET BSC command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then the user must set the EHRACTAMR attribute to TRUE.

Note: The user can also choose the threshold values through the
HRACTAMRT1 and HRACTAMRT2 attributes belonging to the BTS object).
Result: Cell load dependent activation of Half Rate, for AMR calls, is enabled.

END

474

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.103

OMN:BSC

Enabling Enhanced pairing for TCH/H channels

Introduction
The purpose of this feature is to increase the network efficiency, by the reorganization
of the TCH Half Rate channel pairing. In fact, in case of Dual Rate traffic channel configurations (i.e. when each channel could be used either as Full Rate or Half Rate) it can
happen that the radio resources are not exploited in an efficient way.
Supposing, for example, to have a TRX configuration with 8 timeslot configured as Dual
Rate (see figure below). In each Dual Rate timeslot, the subslots are discriminated with
0 and 1 values. Grey color indicates a busy channel, whereas blank color indicates a
free channel. After various assignment and release of channels the following situation
can occur:

Although there are three Half Rate channels free, there is not possibility to allocate a Full
Rate channel if required; this causes an inefficient management of radio resources.
To solve critical situations as the one above described, a procedure has to be performed
in order to pair the Half Rate channels, if it is possible. This procedure is executed only
if at least two Half Rate channels are available.
Referring to the described example the implementation of this feature moves a call from
a subslot to another one (i.e. an Intracell Handover is executed) in order to free full
timeslots; the result is shown below:

To enable the Enhanced pairing for TCH/H channels feature the user must set to
TRUE the EPA attribute (EnablePairing) belonging to the BSC object.

Regarding Enhanced pairing for TCH/H channels feature, the Enable Forced Intracell
Handover flag (ENFOIAHO) is meaningless.

A30808-X3247-L210-3-7619

475

OMN:BSC

Operation
Base Station Controller

The procedure that performs the Handover for TCH Half pairing reason is included in
the Resource reallocation function that is described in "3.104 Management of Radio
Resources". If the Enhanced Pairing is enabled by the operator, when the resource reallocation procedure is started, the number of TCH Full Rate is tested: if this number is
under a predefined threshold (defined by the operator), and there are at least two TCH
Half not paired, the Intracell Handover procedure is started.
The thresholds used to evaluate the number of busy TCH are (the parameters belong
to the BTS object):

the first threshold (EnhancedpairingThreshold1 - EPAT1) is used in case of Standard cell or Complete area of a Concentric cell;
the second threshold (EnhancedpairingThreshold2 - EPAT2) is used in case of Inner
area of a Concentric cell and Near area of an Extended cell.

In concentric cells case the Handover for TCH-Half pairing reason can be performed
only between channels belonging to the same area (inner or complete); it means that
Intracell Handover for TCH Half pairing reason can be forced only from complete to
complete area or inner to inner area.
In extended cells case the Handover for TCH-Half pairing reason can be performed only
between channels with single typology

When the flexible abis allocation strategy is used, if the Enhanced Pairing for the
Radio Interface is enabled, it is also enabled taking into account the Abis Interface
congestion state (please refer to "3.40 Configuration of the Abis Interface").

Prerequisites
The user must have the visibility level number set to "2";
The network element must be in phase "2".

Enable the Ehanced pairing for TCH/H channels

To enable this feature, the user must enter the SET BSC command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then the user must set the EPA attribute to TRUE (it belongs to BASICS group).
Result: Enhanced pairing for TCH/H channels is enabled.

END

476

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.104

OMN:BSC

Management of Radio Resources

Introduction
With the introduction of HSCSD and GPRS/EGPRS data calls, a new clear and flexible
strategy for channel allocation is required. Furthermore, the introduction of channel allocation strategies requires a mechanism to use/reuse the system resources, in order to
better comply with the operator choices. In this sense it is very important to optimize the
resource allocation in order to use each TRX in the best possible way, and to satisfy
each new request according to the customers setting (both for Data and for Speech
calls).

Regarding the management of different services, the operator has the possibility to
configure in the cell static GPRS/EGPRS timeslots, which can not be used both for
voice and circuit switched data.
To reserve static GPRS/EGPRS timeslots for signalling the GDCH attribute of the
CHAN object is used (see "3.64 Addition of a Radio Channel"). The user can reserve a
channel for GPRS/EGPRS signalling (on the BCCH TRX only); in this case he must
set, for the chosen channel, the GDCH attribute to the PBCCH or PCCCH value; in this
case the selected channel does not support voice and circuit switched data.
To reserve static GPRS/EGPRS timeslots for traffic, the user can set the GMANPRES
attribute (PTPPKF object); to understand how packet switched services can be configured on a cell, please refer to "3.47 Addition of a Point-to-Point Packet Function
(GPRS/EGPRS)".

The implementation of the Service dependent channel allocation feature is shared

between three main processes (see Fig. 3.104.21):
1. Resource Reallocator: it is responsible for a periodic reorganization of the
resources according to the operator preferences, in order to optimize the resource
usage;
2. Request Manager: it is responsible for the management of all the incoming
requests. In case of Non-Congestion situation, the aim of the task is to allocate the
requested resources according to the operator setting and to the Mobile Station preferences. If the request cannot be satisfied, the request is inserted in a waiting queue
(i.e. a Stand by queue), and will be served as soon as the proper actions have been
performed.
3. Waiting Queue Manager: it is responsible for the management of the
HSCSD/GPRS/EGPRS multislot requests assignment, and for the other requests
included in the waiting queue, when the same requests couldnt be satisfied immediately.

The Waiting queue is different from the queue related to Queuing feature

The

A30808-X3247-L210-3-7619

477

OMN:BSC

Operation
Base Station Controller

Channel Allocation
Strategy

Resource Reallocator

Request Manager

Waiting Queue Manager

Fig. 3.104.21 Processes related to Service dependent channel allocation

In the following these three processes are explained.
1) RESOURCE REALLOCATOR
The purpose of the Resource Reallocator process is to reorganize the radio resources
related to each specific cell. This kind of resource reworking is triggered each time an
internal timer expires; the setting value of the timer, is between 0.4 and 0.8 seconds (this
timer is not set by the user).
The resource reallocation process is executed on already active calls, and it includes
two types of reorganization:
a) Reorganization of the active calls on the proper TRXs, with respect to the operators
setting.
b) Enhanced Pairing for TCH/H channels in case of system congestion.
Lets see the two types of resource reallocation in a detailed manner:

a) Reorganization of the active calls on the proper TRXs, with respect to the operators
setting:
Both for voice and data calls, an highest flexibility for different operators strategy is
provided. The operator can define the proper allocation strategy both for data
(GPRS/EGPRS/ HSCSD) and speech calls.
To get this purpose a parameter is used to specify the allocation policy. This parameter
is called callPolicy (CPOLICY) and belongs to the BSC object. It can assume the
following three values:

478

0 which means Data Call on BCCH; choosing this value the BSC allocates as preference the incoming data calls on the BCCH TRX, while incoming speech calls are
allocated on the non BCCH TRX.
1 which means Speech Call on BCCH; choosing this value the BSC allocate as
preference the incoming speech calls on the BCCH TRX (the reason for this may be,
for example, to avoid the sending of dummy burst on BCCH carrier if it is not used
for traffic), while incoming data calls are allocated on the non BCCH TRX.
2 which means No Preference; in this case no specific action is taken from the BSC
to decide which TRX shall be used to serve the incoming speech and data calls.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Reorganization of the active calls on the proper TRXs, with respect to the operators
setting means that, when the internal timer expires, the BSC verifies the value of the
CPOLICY attribute. If the parameter indicates for example, Data Calls preferred on the
BCCH TRX, and for some reasons some Data Calls are active on a NON BCCH TRX,
the procedure evaluates the possibility to move such calls on the proper TRX (via
Forced HO); in the same way speech calls present on the BCCH TRX will be moved
toward a non BCCH one.
To move a speech or data call from one TRX to another, the Forced Intracell Handover
feature must be enabled, i.e. the ENFOIAHO attribute (Enable Forced Intracell
Handover) must be set to TRUE.

b) Enhanced Pairing for TCH/H channels in case of system congestion

The procedure shall evaluate the possibility to optimize the Half Rate usage when the
radio resources are not fully exploited as a consequence of the static pairing of the TCH
Half Rate channels. If the Enhanced Pairing is enabled by the operator, when the
resource reallocation procedure is started, the number of TCH Full Rate is tested: if this
number is under a predefined threshold (defined by the operator), and there are at least
two TCH-Half not paired, the Intracell Handover procedure is started.
To get more information about Enhanced Pairing for TCH/H channels feature, see
PROC: Enabling Enhanced pairing for TCH/H channels.
Even if to move an Half Rate channel from one position to another one, an Intracell
Handover is used, in this case the value of the Enable Forced Intracell Handover flag
(ENFOIAHO) is meaningless.
So, according to the two types of resource reallocation, the following actions can be
taken by the BSC when the timer expires:
1. Pairing of unpaired Half Rate channels (if EnhancePairing flag - EPA- is enabled).
2. Moving of data calls on Data_Preferred_TRX (if Enable Forced Intracell Handover)
is set to TRUE). HSCSD calls are not moved if the number of timeslots used by the
calls is greater than 1.
3. Moving of Speech calls on Speech_Preferred_ TRX (if Enable Forced Intracell
Handover is set to TRUE).

In case of Concentric and Dual Band cells the forced intracell handover is allowed only
in the same area inner or complete; moreover inside Extended cells it is allowed only
within the single area (near of far). For this kind of cells it is reccomended to set the
CPOLICY parameter to NO_PREFERENCE to avoid for example that an Assignment
Request for a mobile station in the Inner area is served on the Complete one to satisfy
the call policy, and later on is moved into an Inner area on BTS request.
Each time the procedure is completed, and the reallocation procedure has been
successfully executed, the resources that have been released are immediately used to:
1. serve requests pending in the queueing list (see PROC: Queueing, Preemption and
Directed Retry for TCH) or in the new waiting list (see WAITING QUEUE
MANAGER)

A30808-X3247-L210-3-7619

479

OMN:BSC

Operation
Base Station Controller

2. if no requests are pendent, the resources are used by the Request Manager process
(see REQUEST MANAGER) to serve new incoming requests

HSCSD and GPRS/EGPRS calls can be in waiting queue with a multislot request, only
if the BTS is not congested; otherwise the request, downgraded to 1 timeslot, is
enqueued (i.e. put in the waiting queue).

2) REQUEST MANAGER
The process is responsible for the first management of all the incoming new requests.
When a new resource is required by the network, the Request Manager first applies the
cell load dependent activation of Half Rate procedure (if the procedure is enabled by
the user). The user can choose to enable or not the cell load dependent activation of
Half Rate procedure using the right attribute (see "3.102 Enabling Cell load dependent
activation of HR channels"). Then, the Request Manager has to check the following situations (see Fig. 3.104.22).

480

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

New Request

Apply Cell load dependent

activation of HR procedure

NO

Preempt.

Is a
multislot
request?

YES

BTS
congested?

Succ.

NO

YES

Fail
Succ.

NO

Is call
downgrade
possible?

YES

Dir-Retry
Downgrade to 1
timeslot

Fail

Queuing
allowed

NO

YES

YES
Succ.

Queuing
result

Request is
satisfied and
queues are
empty?

NO

Fail
DROP request

Allocation

PUT in waiting
queue

Fig. 3.104.22 Management of incoming calls

A30808-X3247-L210-3-7619

481

OMN:BSC

Operation
Base Station Controller

When the required BTS is congested, there are two different cases to evaluate:
1. If the incoming request is for more than one timeslot (i.e. GPRS/EGPRS or HSCSD
requests), the first action to be performed is to verify if direct downgrade of the
incoming request is possible (both for HSCSD Not-transparent services and
GPRS/EGPRS services). In this case the downgrade procedure on the incoming
data call is started. After downgrading, if possible, the new request is served, otherwise it is put in the waiting queue. Furthermore in case of GPRS/EGPRS requests
the following considerations are taken: for the GPRS/EGPRS request, a check shall
be done on the incoming request from the PCU. It shall distinguish between upgrade
requests for GPRS/EGPRS and new requests for the GPRS/EGPRS (see
Fig. 3.104.23):
an upgrade request is detected each time the PCU requires for additional
timeslots for GPRS/EGPRS service. This means that some timeslots are
currently allocated for GPRS/EGPRS data transmission, and the request is for
additional resources. In this case, when the BTS is congested, the request from
the PCU will be rejected.
a different situation occurs when an incoming request from the PCU is for one or
more timeslots and no channel are currently allocated for the GPRS/EGPRS
service. In this case, when the BTS is congested, the behavior is similar to the
one implemented for the HSCSD request (explained above). The incoming multislot request is downgraded to a single timeslot request. At this time if the request
cannot be served immediately, it will be included in the waiting queue and the
already described iter for the resource allocation will be followed. This mechanism
is not applied to the timeslots reserved for exclusive use of the GPRS/EGPRS
service. So if the incoming request can be satisfied using the timeslots reserved
exclusively for the GPRS/EGPRS service (fixed by the operator using the new
operator attribute) no downgrade or reject is performed on the incoming request.
2. If the incoming request is a single slot request, the sequence of the already known
procedures for Preemption and Direct Retry shall be executed (see, PROC:
Queueing, Preemption and Directed Retry for TCH). In case the request is still
pending for the system after the previous procedures, the Queuing procedure is activated (if enabled, see PROC: Queueing, Preemption and Directed Retry for TCH).

Note, once more, that the resources that the Resource Reallocator process releases,
are used first by the Queueing process and only later on by the Waiting Queue Manager
process. So the classic Queueing already implemented has always priority respect to
the waiting queue management.
In case the BTS is not congested, the Request Manager process has to check if the
incoming request can be completely satisfied by the available system resources (for
example if no forced handover are required for a multislot request, or Data/Speech call
can be served on the preferred TRX. In this case if the request is completely satisfied
by the available resources it is served immediately (only if the Waiting queue is empty).
If the resources available at the moment cannot satisfy the new request, the same
request is included in the Waiting queue and the management is delegated to the
Waiting Queue Manager process.
So, when resources are available and the waiting queue is filled with some pending
request, the new request will not be served immediately, even if there is no congestion
from a BTS point of view. This is done in order to optimize the resources usage and it
can produce a short delay in serving the new requests.

482

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Incoming GPRS/EGPRS
request

Upgrade

Upgrade or
new GPRS/EGPRS
request?

YES

BTS
congested?

NO

YES

NO

New request

Reserved
timeslots
available?

Downgrade to 1
timeslot
Request is
satisfied and
queues are
empty?

YES

NO

PUT in waiting
queue

DROP request

Allocation

Fig. 3.104.23 Handling of GPRS/EGPRS requests

Considerations About the Assignment/Management of GPRS/EGPRS Resources

After having enabled GPRS/EGPRS services on a cell basis (see 3.47, 3.58 and 3.59),
the user can manage the allocation strategy, i.e. which algorithm is used, by the
resource manager, to fill in GPRS/EGPRS slots. Two types of algorithms are foreseen:

A30808-X3247-L210-3-7619

the VERTICAL ALLOCATION algorithm (VA): before assigning a new slot to

GPRS/EGPRS service, the already used slots must be filled as much as it is
possible, according to the chosen GMANMSAL value;
If, for example, 2 mobiles perform 3DL+1UL GPRS/EGPRS calls, the BSC will
assign to them the TS number 1, 2 and 3. In this way the TSs from 4 to 7 remain
free because the BSC multiplexes the 2 mobiles on those 3 TS.

483

OMN:BSC

Operation
Base Station Controller

the HORIZONTAL ALLOCATION algorithm (HA) is introduced in the system to allow

higher bit data rates, when the cell is not congested.
This strategy is intended to distribute the incoming GPRS/EGPRS calls on all the
available PDCHs. In this way not too much users are multiplexed on the same
PDCH, increasing the data transfer throughput for all the involved mobiles. When a
new request of PDCH channels arrives at the BSC and there are still radio channels
available for GPRS/EGPRS service, the BSC will assign new radio channels to the
GPRS/EGPRS mobiles instead of increasing the number of mobiles multiplexed on
the already busy channels.
If, for example, 2 mobiles perform 3DL+1UL GPRS/EGPRS calls, the BSC will
assign the TS number 1, 2 and 3 to the first call, then the TS number 4, 5 and 6 to
the second call. In this way each TS is used for a lower number of calls and the
throughput is better than that for the vertical allocation strategy.

The BSC switches autonomously from VA to HA (and vice versa) in relation to the traffic
load in the cell. The aim is to use the horizontal allocation when the cell is not loaded;
otherwise the adopted strategy will be the vertical one.
To avoid frequent changes between the HA and the VA strategies two thresholds are
defined. One threshold (ThresholdIdleChannelHV) represents the transaction from horizontal to vertical, the other one (ThresholdIdleChannelVH) represents the transaction
from vertical to horizontal. The thresholds used to activate horizontal/vertical allocation
are managed by the GASTRTH attribute (PTPPKF object).
The threshold, the causes the transaction from one allocation algorithm to the other one,
represents the percentage of idle slots in the cell. The percentage is calculated as the
number of idle channels in the cell with respect to the number of available channels in
the cell (TCHs or PDCHs; do not consider slots containing GSM signalling, such as
BCCH or SDCCHs slots and also slots statically reserved to GPRS/EGPRS). The
number of available channels in the cell is calculated as:

Available Channels = Total number of configured channels - Number of OUT OF

SERVICE channels - Number of GPRS/EGPRS static channels (defined by both GDCH
and GMANPRES) - Number of GSM signaling channels

It is important to highlight that the evaluated value, that represents the percentage of
idle channels in the cell, is truncated, so decimals are not taken into account in the
comparison with thresholds. E.g. if the internal evaluation estimates that the percentage
of idle channels in the cell is 10.9 %, then the real value that is compared to the thresholds is 10% and not 11%).
The difference between the two thresholds of the GASTRTH parameter should not be
too much high, but the thresholds have to be setted to reasonable values (also taking
into account the number of configured TCH in the cell). Otherwise it could happen that,
when the VERTICAL allocation is used, a return back to the HORIZONTAL one is
applied only when the cell is completely idle, and this is not a real hysteresis behaviour.

Besides, after the first allocation of radio resources, additional radio resources could
become necessary to sustain the peak throughput. Therefore a radio resource upgrade
strategy is necessary.

484

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

To enable the upgrade strategy a threshold based on idle radio channels is used. The
general behavior is the following: at the beginning, when all radio channels are idle, the
upgrade requests are enabled. As the percentage of idle radio timeslots decreases, the
upgrade requests can be performed, as long as horizontal allocation is in progress.
When vertical allocation is in progress, upgrade requests are not performed. Then, as
the percentage of idle channels increases, the upgrade requests are stopped, till an
administrable percentage is exceeded. To set this percentage, the ThresholdIdleChanEU field, of the GASTRTH attribute (PTPPKF object) is used. When ThresholdIdleChanEU < 100, the upgrade is enabled as long as horizontal allocation is in
progress. After the switch to vertical allocation, the upgrade is restored only when the
percentage of idle timeslots increases and the ThresholdIdleChanEU percentage is
overcome.
Regarding the allocation and the management of radio resources for GPRS and EGPRS
services, it is important to consider also the Flexible Abis Allocation Strategy (see
"3.40 Configuration of the Abis Interface") because it affects the behavior of the radio
interface too.
With the Flexible Abis Allocation Strategy, Abis resources are allocated dynamically at
CHANNEL ACTIVATION. For packet services, the initial set of Abis resources assigned
to a PDCH can be modified at run-time (according to radio conditions and the link adaptation process, see "3.61 Enabling Link Adaptation for GPRS and EGPRS") using
the MODIFY ABIS CHANNEL message.
In general, the aim of the Abis/PDT resource assignment process is to allocate a fair
number of Abis/PDT resources to new and already allocated PDCHs, in order to support
the initial coding scheme for an incoming TBF, or the coding scheme requested by Link
Adaptation for a TBF in progress. In case Abis/PDT resources are not enough to satisfy
completely the request, the number of Abis/PDT per PDCH is reduced accordingly.
Hence, in case of Abis/PDT resources scarcity, it is not guaranted that the initial coding
scheme or the coding scheme requested by Link Adaptation can be supported.
To simplify the resource assignment algorithm, the Abis/PDT scarcity does not affect the
radio resource assignment algorithm. The only mandatory check (on TDPC) concerns
the availability of one Abis/PDT per each new PDCH in the selected radio timeslot
configuration. No attempt is done to search radio resources minimising the number of
new allocated Abis/PDT resources. This choice has also the aim of saving real time. In
case of horizontal allocation without overlapping to already allocated PDCHs, new
PDCHs are request. The request contains the numer of enough Abis/PDTs resources
to support the initial coding scheme of the incoming TBF.
The number of PDTs is chosen according to the initial coding scheme, as shown in
Tab. 3.104.22:
Coding

Number Abis/PDT

CS1

CS2

CS3

CS4

Tab. 3.104.22Number of Abis/PDT Resources Assigned to each PDCH, according to

the Selected Coding Scheme.

A30808-X3247-L210-3-7619

485

OMN:BSC

Operation
Base Station Controller

Coding

Number Abis/PDT

MCS1

MCS2

MCS3

MCS4

MCS5

MCS6

MCS7

MCS8

MCS9

Tab. 3.104.22Number of Abis/PDT Resources Assigned to each PDCH, according to

the Selected Coding Scheme.
In the limits of the available Abis/PDT resources, TDPC will assign the requested
Abis/PDTs to new allocated PDCHs.
In case a new TBF has to be partially or totally assigned to already allocated PDCHs,
the search of radio resources does not take care of the current Abis allocation of the
already allocated PDCHs (in order to save real time and to simplify the research algorithm). In the limits of the available Abis/PDT resources, the system assigns the
requested Abis/PDTs to the new allocated PDCHs and upgrade up to the required
Abis/PDTs also the already allocated PDCH (specified in the request) in the selected
radio timeslot configuration.
In case a new TBF has to be totally assigned to already allocated PDCHs and no new
PDCH has to be allocated but the current PDT/Abis allocation is not enough, PCU will
request to TDPC additional Abis resources. So every time modifications in the initial set
of Abis resources are nedeed by PCU, they are requested to TDPC by
PDCH_AbisUpgrade/PDCH_AbisDowngrade messages
To manage the resource allocation process, a set of thresholds regarding Abis allocation usage is introduced too. The user can set these thresholds by the GASTRABISTH
parameter (gprsAllocationStrategyAbisThresholds) of the BTSM object.
GASTRABISTH is composed of four fields:

486

the first one (thresholdIdleAbisHV) defines the percentage of idle Abis subslots
(over the available Abis subslots) under which the Vertical allocation strategy for
Abis scarcity is activated on the radio interface. To activate the vertical allocation in
case of Abis scarcity is useful to re-use in multiplexing the already allocated Abis
subslots, slowing down the allocation of new Abis resources;

the second one (thresholdIdleAbisVH) defines the percentage of idle Abis subslots
(over the available Abis subslots) over which the Horizontal allocation can be activated again on the radio interface, if also the thresholds on radio resources (defined
by GASTRTH) allow that;

the third one (thresholdIdleAbisStopUpgrade) defines the percentage of idle Abis

subslots (over the available Abis subslots) under which the PCU must disable the
Abis upgrading requests to TDPC. When this threshold is overcome, the first allocation of Abis resources to a TBF is performed with the same criteria used under

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

normal conditions (looking at the candidate initial coding scheme), but further
upgrading of Abis resources is forbidden. Moreover, in case of runtime Abis release
(due to worsening of radio conditions, CS pre-emption or O&M commands), the
released Abis is not allowed to be allocated again to running TBFs. The main aim of
this threshold is avoiding useless signalling between PCU and TDPC in case of
nearly complete Abis congestion, therefore, the default value of the threshold is 0,
meaning that the Abis upgrading is disabled only in case of complete Abis congestion. The secondary aim of this threshold is to avoid the allocation of additional Abis
resources to running packet services in case of Abis scarcity, so that the residual
Abis resources in the pool can be by preference available to set up new CS services
(this will be the trend in case of vertical allocation) or even to new PS services (in
case horizontal allocation is still active). Note that moving this threshold from the
default value, a reduction in PS throughput is expected;

the fourth one (thresholdIdleAbisRestoreUpgrade ) defines the percentage of idle

Abis subslots (over the available Abis subslots) over which the Abis upgrade
requests to TDPC are restored.

Constraints on the Abis thresholds are:

thresholdIdleAbisStopUpgrade < thresholdIdleAbisRestoreUpgrade
thresholdIdleAbisHV < thresholdIdleAbisVH

Note that there is no constraint between the Abis threshold to switch to vertical allocation and the Abis threshold to disable the Abis upgrade requests; the operator is free
to set the one lowest than the other, and vice versa.
As a general configuration rule, in the BTSMs where the Abis resources/radio resources
ratio is quite high, in order to obtain the highest benefit from Link Adaptation, the Abis
upgrading should be disabled only in case of complete Abis congestion or at least after
the switch to vertical allocation.
Instead, in the BTSMs where the Abis resources/radio resources ratio is quite low, for
some operators it could be preferable to disable the Abis upgrading before the switch to
vertical allocation.
In any case the choice will depend from the relative preference given from the operator
to circuit switched calls versus packet switched TBFs, and to running TBFs versus
incoming TBFs.

In BR7.0 release the switching to vertical/horizontal allocation is also driven by the

availability/unavailability of PDTs on PCU (remember that with the high capacity BSC,
see "1.4 Supported BSC Types", the maximum number of GPRS channels manageable by the single PCU, i.e. the maximum number of PDT manageable by the single
PCU, is fixed to 256). When the percentage of busy PDTs on a PCU is 100%, vertical
allocation is applied. When the percentage of busy PDTs on a PCU is < 100%, horizontal allocation can applied (provided that GASTRTH and GASTRABISTH thresholds
do not lead to vertical allocation).
In summary, the following situations are possible during the allocation of radio
resources, according to different contexts:

A30808-X3247-L210-3-7619

Horizontal allocation (neither radio scarcity nor Abis scarcity nor PDT exhaustion);
Vertical allocation due to radio scarcity;

487

OMN:BSC

Operation
Base Station Controller

Vertical allocation due to Abis scarcity;

Vertical allocation due to PDT exhaustion;
Vertical allocation due to a combination of radio and/or Abis scarcity and/or PDT
exhaustion;
Abis upgrade requests enabled (both in horizontal and vertical allocation);
Abis upgrade requests disabled (both in horizontal and vertical allocation).

3) WAIT QUEUE MANAGER

The Waiting queue manager is responsible for the management of the HSCSD and
GPRS/EGPRS multislot requests assignment (for which one or more forced Handover
are required) and for the other requests included in the waiting queue when the same
requests couldnt be satisfied immediately (see Fig. 3.104.24). The task is activated by
a timer.
The first check that this process has to perform is the analysis of the queueing list. If the
queueing list contains some pending request, the Wait Queue Manager process shall
immediately apply the downgrade procedures in order to free resources for the
queueing list.
After this procedure, or if the queueing list is empty, the process shall analyse the
waiting queue. If one or more requests are waiting to be served, a check on the available
resources shall be done in the Idle List. This list contains the list of the free resources
and of the ones that have been released by the Resource Reallocator process (if any)
and that have not been used to serve the entries of the queueing list. Three types of
action can be performed by the process to serve pending request on the waiting queue:
1. Use the resources released by the Resource Allocator: in case the Resource
Allocator process had released any system resource, these have been included in
the Idle List structure. The Waiting queue manager process finds the released
resources which are available for the specific cell. If the resources are not enough
to serve all the entries present in the waiting queue, the following Downgrading
mechanisms are activated basing on the operator flag GPRS/HSCSD downgrade.
2. Downgrading of already active HSCSD multislot calls: as already described,
when the BTS is congested the incoming multislot requests are included in the
waiting queue, only after the downgrade of the calls to one timeslot (either for
HSCSD not transparent calls or Not upgrading GPRS/EGPRS calls).
On the contrary, the downgrade of already active multislot calls is performed in two
situations only:
to serve the pending requests in the waiting queue (i.e. the actual situation);
to serve incoming requests, if Preemption is enabled (see PROC: Queueing,
Preemption and Directed Retry for TCH).
3. Downgrading of already active GPRS/EGPRS multislot calls: the
GPRS/EGPRS downgrade process, consists in a decrease of the number of
timeslots assigned to the GPRS/EGPRS services. When the downgrade of
GPRS/EGPRS is performed one of the GPRS/EGPRS channels is preempted and
the channel is released. In the case in which a GPRS/EGPRS data transmission
uses only one timeslot, and the timeslot is preempted for downgrading, the transmission is interrupted (to avoid GPRS/EGPRS downgrading, the operator can use the
GMANPRES attribute as explained before). Like for HSCSD, the downgrade of
already active GPRS/EGPRS multislot calls is performed in two situations only:

488

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

to serve the pending requests in the waiting queue (i.e. the actual situation);
to serve incoming requests, if Preemption is enabled (see PROC: Queueing,
Preemption and Directed Retry for TCH).
Regarding the downgrading of already active GPRS/EGPRS and HSCSD multislot calls,
the user can select the downgrade strategy. The user can choose the preferred downgrade strategy through the DownGradeStrategy parameter (DGRSTRGY). This
attribute allows the user to choose among five different strategies:

Downgrade of HSCSD calls first

Downgrade of GPRS/EGPRS calls first
Downgrade of HSCSD calls only
Downgrade of GPRS/EGPRS calls only
No Downgrade

When downgrading of GPRS/EGPRS/HSCSD calls is performed, the following rules are

followed:

for HSCSD service the downgrade is executed only if the number of used timeslots
is greater than one (i.e. at least one timeslot must remain allocated for HSCSD calls)

for GPRS/EGPRS service there are two possibility:

if no channels of the cell are statically reserved to GPRS/EGPRS the downgrade
can reduce the number of used timeslot to zero;
if any channel is statically defined for GPRS/EGPRS, the downgrade can reduce
the number of used timeslot to the number of channel reserved to GPRS/EGPRS.

A30808-X3247-L210-3-7619

489

OMN:BSC

Operation
Base Station Controller

Get from queues

NO

Any
pending request?

YES

- Use new free resources

- HSCSD/GPRS/EGPRS: use forced
handover procedure
- Use downgrade possibility

YES

Is resource
request
satisfied?
NO

Allocation

DROP

Fig. 3.104.24 Waiting queue handling

Prerequisites
For all the involved procedures:
The user must have the visibility level number set to "2";
The network element must be in phase "2".

490

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Preliminary Consideration
Do you want to enable the Cell load dependent activation of Half Rate channels feature?

h ..."3.102 Enabling
Cell load
dependent activation of HR
channels"

Do you want to enable the Enhanced pairing of Half Rate channels?

h ..."3.103 Enabling
Enhanced
pairing for
TCH/H channels"

Do you want to manage the allocation/upgrade strategy for GPRS and

EGPRS calls?

Do you want to manage the call policy of speech and data calls?

h ... 6
h ... 2

Do you want to manage the downgrade policy of GPRS/EGPRS and HSCSD

calls?

h ... 5

Set the allocation strategy

To set the allocation strategy, enter the SET BSC command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then assign the chosen value to the CPOLICY attribute (it belongs to BASICS
group).
Result: the chosen allocation strategy is enabled. To use this allocation strategy
the Forced Intracell Handover must be enabled.

Consideration
Is the Forced Intracell Handover enabled?

Y h ... END
N h ... 4

Enable Forced Intracell Handover

To enable the Forced Intracell Handover, enter the SET BSC command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then set the ENFOIAHO attribute (BASICS group) to TRUE.

Result: the Forced Intracell Handover is Enabled.

A30808-X3247-L210-3-7619

h ... END

491

OMN:BSC

Operation
Base Station Controller

Set the downgrade policy

To set the downgrade policy, enter the SET BSC command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then assign the chosen value to the DGRSTRGY attribute (it belongs to
BASICS group).

h ... END

Result: the chosen downgrade policy is enabled.

Set the allocation strategy of the radio interface

To set the allocation strategy, enter the SET PTPPKF command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF

Then assign the chosen values to the following fields of the GASTRTH attribute:
ThresholdIdleChannelHV
ThresholdIdleChannelVH
Result: the chosen allocation strategy is enabled.

Set the upgrade strategy of the radio interface

To set the allocation strategy, enter the SET PTPPKF command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF

Then assign the chosen value to the ThresholdIdleChannelEU field of the

GASTRTH attribute.
Result: the chosen upgrade strategy is enabled.

492

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set the strategy to be used referring to the Abis interface

To set the strategy, enter the SET BTSM command following the next sequence
of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> SET BTSM

Then assign the chosen values to the following fields of the GASTRABISTH
attribute:
ThresholdIdleAbisHV
ThresholdIdleAbisVH
ThresholdIdleAbisSU (stop upgrade)
ThresholdIdleAbisRU (restore upgrade)

Result: the chosen upgrade strategy is enabled.

END

A30808-X3247-L210-3-7619

493

OMN:BSC

Operation
Base Station Controller

3.105

Creation and Handling of Inventory File

Introduction
The feature of Remote Inventory is introduced in the SBS system to allow the automatic
handling and collection of inventory data. All the Last Replaceable Units (LRU) that are
of interest for the inventory are called Remote Inventory Units (RIU).
A hardware module is identified by the Product Identification Data (PID) which consists
of at least an item number with issue and serial number, and can be supplemented by
manufacturer's code, product designation, repair data and modification data. The
complete inventory data of a hardware module includes: mounting location, origin
identifier, format version, PID, extension level.
Two types of hardware modules can be managed by the Remote Inventory feature:

hardware modules with an on-board memory where the PID is stored are called
on-board memory RIU (ob_RIU).
hardware modules without an on-board memory for the PID are called non-on-board
memory RIU (nob_RIU).

The ob_RIU data stored on board can be uploaded from the BSC, BTSE, BTSEC or
TRAU Network Element and handled by using the IDF Editor tool (see the OGL:LMT
manual) on the LMT.
The nob_RIU data are built off-line by using the IDF Editor tool. The nob_RIU data are
then downloaded by means of dedicated commands. In case a new nob_RIU board is
to be inserted or an old nob_RIU board is to be replaced against a new one, data can
be entered by means of a 2D code reader, too.
The user can create a Central IDF (Inventory Data File) by collecting the inventory data
from all the controlled Network Elements (NE). The BSCs collect the inventory data
(Central IDT) from the controlled NEys (local IDT files from all connected BTSEs,
BTSECs and TRAUs). This process is shown in Fig. 3.105.25.

Network
Element

NEys IDT
without header
and footer

Complete
NEys IDF
LMT

NEys IDT
without header
and footer
BSC.IDT
MPCC

BTSM0.IDT

........
Central/BSC IDF
without header
and footer

LMT

494

BSC
Disk

TRAUn.IDT

Complete
Central/BSC
IDF

RC/LMT

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig. 3.105.25Overview of the IDFs flow in the system

The Central IDF data are stored in the service centre in a special post-processing
system (AKUHW) and are available for statistics and upgrade procedures.
The creation and handling of inventory files activities are the following:

creation of the local IDTs inventory data;

collection of the local IDTs for the generation of a Central IDT within the BSC hard
disk;
export of the Central IDT in Central IDF format.

To operate with TRAU or BTSM/BTSMTD equipment, the user must before enter the
Interworking tree related to the chosen equipment (BTSE, BTSEEM, BTSEP,
BTSEPICO, BTSEXS, BTSEC or TRAUE; see "1.6 Support of different HW generations of network entities").
Prerequisites
The user must have the visibility level set at 1.

Creation of LOCAL inventory data

To generate the local inventory data of the NEs use the command UPLLIDF
following the next sequence of selections by using the local LMTs respectively
for BSC, BTS or TRAU:

i
b
b
b

Only for the BSC, the object REMINV has to be locked before upload
is possible.
MANAGED-ELEMENT ---> BSS-EQUIPMENT---> REMINV---> LOCK REMINV
MANAGED-ELEMENT ---> BSS-EQUIPMENT---> REMINV---> UPLLIDF
REMINV
MANAGED-ELEMENT ---> BSS-EQUIPMENT---> <BTSE equipment>--->
REMINV---> UPLLIDF REMINV
where <BTSE equipment> must be replaced by one of the following: BTSE,
BTSEP, BTSEXS, BTSEPICO, BTSEEM or BTSEC.

MANAGED-ELEMENT ---> BSS-EQUIPMENT---> TRAUE ---> REMINV--->

UPLLIDF REMINV

Result: The .IDT file is copied from the NE to the LMT hard disk. If not specified
the default directory is C:\LMT_ROOT\....\IDF\UPLOAD, the file names are
BSC.IDT or BTSM.IDT or BTSMTD.IDT or TRAU.IDT.

A30808-X3247-L210-3-7619

495

OMN:BSC

Operation
Base Station Controller

Handling of inventory data using IDF editor

OPEN IDF Editor

To start the IDF Editor the user must select the IDF button on LMT
Dashboard or the IDF icon from the LMT programs group.

OPEN IDT file

Open the previously uploaded data table by means of the related icon or by
using command present in the File menu.

ADD nob_RIUs
The records relevant to the nob_RIU are in bold characters. A new nob_RIU
is added by means of the following operation:
create a new nob_RIU by using the right mouse button on the N-record in
the upper pane;
select the module to be added;
set the SBS_Equipment_Position;
insert the inventory data.
In case of a nob_RIU is already present and its data are to be updated, edit
the inventory data by selecting the related I-record and clicking the right
mouse button. Inventory data can be entered both by means of a 2D code
reader and manually.

DELETE nob_RIUs
In case a nob_RIU is already present and is to be removed, delete the
inventory data by selecting the related S-record, clicking the right mouse
button and confirming the delete operation.

EXPORT of nob_RIU
Select NOB item from the Export menu, and save the file BSC_NRIU or
BTS_NRIU or TRAUNRIU on the LMT hard disk.

For more details about the previously described operations refer to LMT
Operation Guidelines (OGL:LMT manual).

DOWNLOAD of nob_RIU inventory data

To download the nob_RIU data use the command of the REMINV object
following the next sequence of selections:

b
b

MANAGED-ELEMENT ---> BSS-EQUIPMENT---> REMINV---> DNLIDFD

REMINV
MANAGED-ELEMENT ---> BSS-EQUIPMENT---> <BTSE equipment> --->
REMINV---> DNLIDFD REMINV
where <BTSE equipment> must be replaced by one of the following: BTSE,
BTSEC, BTSEP, BTSEPICO or BTSEEM.

MANAGED-ELEMENT ---> BSS-EQUIPMENT---> TRAUE ---> REMINV--->

DNLIDFD REMINV

Result: the nob_RIU inventory data are downloaded to the BSC hard disk or to
the FLASH EEPROM of the BTSE or TRAU.

496

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Lock the REMINV object

To lock the REMINV object use the LOCK REMINV command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> REMINV --->

LOCK REMINV

Result: The administrative state of REMINV object is changed to Locked.

Align the IDF file

After having locked the REMINV object (see step 4), to align the IDF file use the
command ALIGN REMINV following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> REMINV--->

ALIGN REMINV

Result: The Central IDT(.ZDT) on BSC is aligned with the inventory data of the
NE specified in input (TRAU, BTSEC or BTSE).

Unlock the REMINV object

To unlock the REMINV object use the UNLOCK REMINV command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> REMINV ---> UNLOCK

REMINV

Result: Setting the REMINV object in the administrative state Unlocked.

Lock the REMINV object

To lock the REMINV object use the LOCK REMINV command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> REMINV --->

LOCK REMINV

Result: The administrative state of REMINV object is changed to Locked.

A30808-X3247-L210-3-7619

497

OMN:BSC

Operation
Base Station Controller

UPLOAD the zipped data table (.ZDT) file

After having locked the REMINV object (see step 4), to upload the ZDT file from
the BSC hard disk to LMT hard disk, use the UPLCIDF command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> REMINV--->

UPLCIDF REMINV

DESTDIR
It specifies the complete destination path of the file on LMT. If not specified the
default directory is C:\LMT_ROOT\.....\IDF\UPLOAD.
FILE
It specifies the file name. If not specified the default name is BSC.ZDT.
OVERWRITE
It allows to overwrite the already existing file.
Result: The ZDT zipped file is uploaded from on the disk of the BSC to the
default directory or to the directory specified by the user.

Create the Central IDF files

START the IDF editor

To start the IDF editor the user must select the IDF button on LMT Dashboard
or the IDF icon from the LMT programs group.

OPEN the ZDT file

To open the IDF file the user must select the item Open of the File menu into
the IDF editor window, then he must select one file (for example: BSC.ZDT).

EXPORT the Central.IDF and central.TXT files

Command: Export of C_IDF: the file Central.idf is created in the directory:
C:\LMT.ROOT\....\IDF\UPLOAD
Command: Export of C_TXT: the file Central.idf is created in the directory:
C:\LMT.ROOT\....\IDF\UPLOAD

For the description of inventory file handling, refer to LMT Operator Guidelines
(OGL:LMT manual).
Result: The Central.IDF and Central.TXT files are exported from the .ZDT file.
Such data are stored in the service centre in a special post-processing system
(AKUHW) and available for statistics and upgrade procedures.

498

A30808-X3247-L210-3-7619

Operation
Base Station Controller

10

OMN:BSC

Unlock the REMINV object

To unlock the REMINV object use the UNLOCK REMINV command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> REMINV --->

UNLOCK REMINV

Result: Setting the REMINV object in the administrative state Unlocked.

END

A30808-X3247-L210-3-7619

499

OMN:BSC

Operation
Base Station Controller

3.106

VAD/DTX and Comfort Noise for Half Rate Speech

Introduction
The discontinuous Transmission (DTX) and its preliminary functions Voice Activity
Detection (VAD) and Comfort Noise Insertion (CNI) for Half Rate Channels are specified
with the purpose to minimize the power consumption of the MS and, at the same time,
to reduce the interference level in the air.
Interpolation of SID frames is used in order to generate pleasant comfort noise. DTX for
half rate speech in the BSS is controlled by an O&M command on a per cell basis in the
same way as full rate but with an additional attribute to allow its use independently from
the use of full rate DTX. The new attributes for full and half rate DTX replace the current
ones and are:
- dtxDownlinkFullRate
- dtxDownlinkHalfRate.
Prerequisites
Not applicable.

Execute a Downlink Full Rate command

Select the command "SET BTS and enter DTXDLFR" following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS

Result: execute Downlink Full Rate Command

Execute a Downlink Half Rate command.

Select the command "SET BTS and enter DTXDLHR" following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS

Result: execute Downlink Half Rate Command

END

500

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.107

OMN:BSC

BTS Multidrop - Star Cross Connect

Introduction
The Cross connection allows the operator to cross connect PCM timeslots with the
BTSE. Changes regarding these connections have to be made by operator command,
and CREATE, DELETE, GET, SET, LOCK and UNLOCK commands are applicable.
The main functions for the cross connector are:

The star-multidrop cross connection between up to 8 ports (only with BS-40/41,

BS-240/240XL/241/241XL/242 and BTSEC family) is possible. The flexible and non
blocking cross connection from any timeslot on any port to any other timeslot on any
other port is performed (64 kbps).

The automatic loop configuration is still provided.

The re-mapping (= special case of cross connection, available with BS-20/21,

BS-60/61, BS-40/41, BS82, BS-240/240XL/241/241XL/242 and BTSEC family) of
timeslots to the timeslots allocated at the PCM line emanating from the BSC is
provided.

The cascading of star- and multidrop-networks with the cross connection is possible

The following figure describes a cross connect configuration. BTSE1 is configured as a

cross connect and feeds BTSE4 and BTSE5. Timeslots of the ports p1, p3 and p5 are
mapped to timeslots of ports p7 and p8. In addition, BTSE1, BTSE2, BTSE3 and BTSE6
are configured in a loop-/multidrop-configuration.

p1
BSC

p2

p1

BTSE1

p2
BTSE2

p1
BTSE3

p3

p1

p1
secondary
links

BTSE4

BTSE5

p4
BTSE6
p2

p1

Fig. 3.107.26 Configurations

The cross connection features are:

A30808-X3247-L210-3-7619

The cross connection is in parallel to the star-, multidrop- or loop-line configuration.

501

OMN:BSC

Operation
Base Station Controller

Flexible port- and timeslot cross connect administration. In case of only one primary
connection (p1 of Fig. 3.107.26) the cross connections port p1 to ports p3 ... p8 are
possible. The connection p1 to p2 is used for star, multidrop or loop (during
operation the change line configuration is possible). In case of two or more primary
connections the following ports are reserved for the dedicated primary connections:
port p1 to port p2, port p3 to port p4. In such a case no cross connections between
p1, p2, p3 and p4 are possible. The algorithm is: pt > ps + 2 (the number of target
port pt is bigger than the sum of all source ports ps plus 2).

To operate with BTSE equipment, the user must before enter the Interworking tree
related to the chosen equipment (BTSE, BTSEEM, BTSEP, BTSEPICO or BTSEC;
see "1.6 Support of different HW generations of network entities").
Prerequisites
Not applicable.

Execute Create command

This command adds the XConnect instance together with its attributes Mapping
TSy to the BTSE data base. The user must enter the BTSE Interworking tree
related to the chosen equipment, and then enter the CREATE XCONNECT
command following the correct sequence of selections (example regarding
BTSE equipment):

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSE ---> XCONNECT --->

CREATE XCONNECT

Result: BTS1 becomes the cross connector for BTS4 and BTS5

Execute Delete command

This command deletes the XConnect instance from the BTSE database:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSE ---> XCONNECT --->

DELETE XCONNECT

Result: by deleting cross connection of BTS1, BTS4 and BTS5 are not
connected with BTS1

Execute GET command

This command gets a cross connection attribute:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSE ---> XCONNECT --->

GET XCONNECT

Result: the data relevant to the selected XCONNECT are shown on the LMT

502

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Execute SET command

This command sets a cross connection attribute:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSE ---> XCONNECT --->

SET XCONNECT

Result: the X connect functionality is moved to the specified value

END

A30808-X3247-L210-3-7619

503

OMN:BSC

Operation
Base Station Controller

3.108

NUC within TRAU

Introduction
The Nailed Up Connection allows the operator to choose and reserve within TRAU
special channels on the Asub interface and to connect them per operator command to
special channels on the A interface. These connections are permanent, the reserved
channels cannot be allocated automatically by the BSC anymore. The permanent
connections remain reserved even after a bring up of the TRAU. Changes regarding
these connections have to be made by operator command, and CREATE, SET and
DELETE commands will be applicable.
Prerequisites
Not applicable.

Execute GET-INFO command (pcms)

Select the GETINFO PCMS command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMS --->

GETINFO PCMS

Result: the GETINFO report related to the PCMS object is displayed.

Execute GET-INFO command (trau)

Select the GETINFO TRAU command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> GETINFO TRAU

Result: the GETINFO report related to the TRAU object is displayed.

Execute SHUTDOWN command (TSLA 1..4)

Select the SHUTDOWN TSLA command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMA ---> TSLA --->

SHUTDOWN TSLA

Result: the SHUTDOWN TSLA is displayed.

Execute CREATE command

Select the CREATE NUC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> NUC ---> CREATE NUC

Result: the permanent connection reserved for O&M purposes is created.

504

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Enable Cross Connect feature

Select the CREATE TRAU command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> CREATE TRAU

Result: by means of the ALLCRIT attribute set at COMPATIBLE_WITH_CROSS

CONNECT, the NUC is enabled.

END

A30808-X3247-L210-3-7619

505

OMN:BSC

Operation
Base Station Controller

3.109

NUC within BSC

Introduction
The Nailed Up Connection allows the operator to choose and reserve within BSC
special channels on the Abis interface and to connect them per operator command to
special channels on the Asub interface. These connections are permanent, the reserved
channels cannot be allocated automatically by the BSC anymore. The permanent
connections remain reserved even after a bring up of the BSC. Changes regarding
these connections have to be made by operator command, and CREATE, SET and
DELETE commands will be applicable.
Prerequisites
Not applicable.

Execute GETINFO command (pcmb)

Select the GETINFO PCMB command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMB ---> GETINFO

PCMB

Result: the GETINFO report related to the PCMB object is displayed.

Execute GETINFO command (pcms)

Select the GETINFO PCMS command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMS ---> GETINFO

PCMS

Result: the GETINFO report related to the PCMS object is displayed.

Execute SHUTDOWN command (TSLA 1..4)

Select the SHUTDOWN TSLA command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCMA ---> TSLA --->

SHUTDOWN TSLA

Result: the SHUTDOWN TSLA is displayed.

506

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Execute CREATE command

Select the CREATE NUC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> NUC ---> CREATE NUC

Result: the permanent connection reserved for O&M purposes is created.

Enable Cross Connect feature

Select the CREATE TRAU command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRAU ---> CREATE TRAU

Result: by means of the ALLCRIT attribute set at COMPATIBLE_WITH_CROSS

CONNECT, the NUC is enabled.

END

A30808-X3247-L210-3-7619

507

OMN:BSC

Operation
Base Station Controller

3.110

Management of Adaptive Multirate Codec (AMR)

Introduction
The Adaptive Multi-Rate speech codec (AMR) is constituted by a set of speech codec
modes at different bit rates; each codec mode provides a different level of protection
against radio transmission errors. This is obtained by varying the balance between the
source coding bit rate (i.e. the speech coding bit rate) and radio channel coding bit rate.
Advantages derive mainly by the fact that AMR is an adaptive feature, i.e. it permits to
change dynamically codec mode according to the following situations:
1. Adaptation to radio conditions of the physical channel: for good radio propagation, a
high source bit rate can be adopted to obtain optimum speech quality, while for bad
radio conditions an adequate rejection of transmission errors can be achieved by
adopting a high channel coding bit rate
2. Possibility of exchanging speech quality (in full rate mode), with increased system
capacity (in half rate mode) for the radio as well as for the terrestrial resources,
according to traffic conditions of the cell.
AMR principle is new respect to what the previous GSM speech codecs (FR, EFR, HR)
do; in fact, FR, HR and EFR codecs operate at constant source and channel coding bit
rate and at constant error protection level. With AMR the changes among codec rates
are done according to a codec adaptation algorithm. This algorithm is based on channel
quality measurements, performed in the BTS and in the MS. To measure channel
quality, a Quality Indicator is defined, as an equivalent carrier to interferer ratio. The
following table lists the source codec bit-rates (for both TCH Full Rate and TCH Half rate
channels) supported by AMR as defined by ETSI specifications:
Channel

Source codec bit-rate

12.2 Kbit/sec (*) (GSM Enhanced Full Rate)
10.2 Kbit/sec
7.95 Kbit/sec (*)

TCH/AFS (AMR Full Rate)

7.40 Kbit/sec
6.70 Kbit/sec
5.90 Kbit/sec (*)
5.15 Kbit/sec
4.75 Kbit/sec (*)
7.95 Kbit/sec
7.40 Kbit/sec

TCH/AHS (AMR Half Rate)

6.70 Kbit/sec (*)

5.90 Kbit/sec (*)
5.15 Kbit/sec (*)
4.75 Kbit/sec (*)

Tab. 3.110.23Source codec bit rates defined for AMR

508

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

AMR codec adaptation is done within a restricted set of these codec modes. This set is
called Active Codec Set (ACS) and can be composed by up to four codec modes. The
Active Codec Set to be used by the BSS and the MS is defined by the operator. The
operator specifies:
a) an Active Codec Set for AMR Full Rate channels; this Active Codec Set comprises
up to four codec modes taken from the TCH/AFS group (see Tab. 3.110.23)
b) an Active Codec Set for AMR Half Rate channels; this Active Codec Set comprises
up to four codec modes taken from the TCH/AHS group (see Tab. 3.110.23)
The adaptation algorithm uses some thresholds in order to decide when switching from
current codec mode to another codec mode (both codec mode must belong to the Active
Codec Set) has to be performed. For each pair of neighboring codec modes in the ACS,
threshold and hysteresis values have to be defined, in terms of carrier to interference
ratio. In Siemens implementation, codecs marked with (*) are chosen as default codecs
of the Active Codec Set. This choice is made on the basis of result of Characterization
Phase.
The BSC has to fill the new GSM 04.08 MultiRate Configuration IE; this IE, in case of
AMR calls, has to be included in the following messages built by BSC:

CHANNEL ACTIVATION (Abis);

MODE MODIFY REQUEST (Abis);
ASSIGNMENT COMMAND (Um);
HANDOVER COMMAND (Um).

This IE gives to the mobile station all the information regarding Active Codec Set in the
cell in terms of:

allowed codecs;

values of thresholds and hysteresis;

initial codec mode;

version of AMR algorithm.

Structure of this IE is the following:

Fig. 3.110.27 Multirate Configuration Information Element

A30808-X3247-L210-3-7619

509

OMN:BSC

Operation
Base Station Controller

1. MR Version: AMR Speech Version 1 (coded as 0 0 1)

2. ICMI - Initial Codec Mode Indicator: this field indicates to the MS the Initial Codec
Mode (i.e. the initial code) to start the speech coding operation (at call setup and
after handover). It can assume one of these two values:
the initial codec mode is defined by the implicit rule provided in GSM 05.09. The
specification states the following implicit rule (to be used when the initial codec
mode is not signalled by the network):
a) if in the Active Codec set only one codec is included, the initial codec mode is
the only allowed mode;
b) if in the Active Codec set two or three codecs are included, the initial codec
mode is the most robust mode of the set (i.e. the one with lowest bit rate);
c) if in the Active Codec set four codecs are included, the initial codec mode is the
second most robust mode of the set (i.e. the one with second lowest bit rate)
the initial codec mode is defined by the Start Mode field (see below)
3. Start Mode: it is meaningful only if ICMI field indicates that the initial codec mode is
defined by the Start Mode field. In this case the initial codec mode can assume one
of the following four values:
a) the lowest codec mode (lowest bit-rate) of the ACS;
b) the second lowest mode, if the ACS includes more than one mode;
c) the third lowest mode, if the ACS includes more than two modes;
d) the highest mode, if the ACS includes four modes.
4. Parameters for multirate speech: it is a variable number of fields, according to how
many Codec Modes belong to the Active Codec Set (see Fig. 3.28, Fig. 3.29,
Fig. 3.30 and Fig. 3.31).

510

Fig. 3.28

Parameters for multirate speech with one codec mode

Fig. 3.29

Parameters for multirate speech with two codec modes

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig. 3.30

Parameters for multirate speech with three codec modes

Fig. 3.31

Parameters for multirate speech with four codec modes

The field Set of AMR codec modes specifies the four codes that (at most) belong to
the Active code Set.
For each active codec mode, its associated THRESHOLD and HYSTERESIS values,
related to the other modes are provided. The THRESHOLD and HYSTERESIS values
trigger the change from one codec to another one. So, the following considerations can
be done:

if only one codec mode is used, no THRESHOLD and HYSTERESIS values must
be defined;

if two codec modes are used, one couple of THRESHOLD and HYSTERESIS
values must be defined to trigger the change from one code to the other one, and
vice versa;

if three codec modes are used, two couples of THRESHOLD and HYSTERESIS
values must be defined, to trigger the change from one code to the others;

if four codec modes are used, three couples of THRESHOLD and HYSTERESIS
values must be defined, to trigger the change from one code to the others.

A30808-X3247-L210-3-7619

511

OMN:BSC

Operation
Base Station Controller

Fig. 3.110.32 shows the meaning of threshold and hysteresis values. Supposing that
the Active Codec Set contains four codecs (CODEC_MODE_4 is the codec with the
higher source rate coding, while CODEC_MODE_1 is the codec with the lower source
rate coding), the procedure is the following:

the codec mode changes from CODEC_MODE_i to CODEC_MODE_(i+1)

(upgrading of the codec mode) when the C/I value reaches the THR_i + HYST_i
value; in this case the channel quality allows to use a less robust codec mode, which
provides a better speech quality;

the codec mode changes from CODEC_MODE_(i+1) to CODEC_MODE_i (downgrading of the codec mode) when the C/I value reaches the THR_i value; in this case
the channel quality forces to use a more robust codec mode, which provides a worse
speech quality.

Fig. 3.110.32 Thresholds and Hysteresis

From the O&M point of view the operator can specify:
1. the Active Code Set regarding AMR Full Rate; it is specified setting four parameters
that can assume a value taken from the TCH/AFS group of Tab. 3.110.23. The
parameters are:

AMRFRC1
AMRFRC2
AMRFRC3
AMRFRC4

2. the Full Rate codecs that must be sent at first during a call; it is specified by the
AMRFRIC attribute. This attribute can assume one the four specified codecs of the
ACS, otherwise if the operator doesnt specify any codec, the rule previously
described is followed.
3. the couple <Threshold-Hysteresis> related to the active codecs specified in the
AMRFRC1 and AMRFRC2 attributes, in case of Full Rate codec (AMRFRTH12).
4. the couple <Threshold-Hysteresis> related to the active codecs specified in the
AMRFRC2 and AMRFRC3 attributes, in case of Full Rate codec (AMRFRTH23).
5. the couple <Threshold-Hysteresis> related to the active codecs specified in the
AMRFRC3 and AMRFRC4 attributes, in case of Full Rate codec (AMRFRTH34).

512

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

6. the Active Code Set regarding AMR Half Rate; it is specified setting four parameters
that can assume a value taken from the TCH/AHS group of Tab. 3.110.23. The
parameters are:

AMRHRC1
AMRHRC2
AMRHRC3
AMRHRC4

7. the Half Rate codecs that must be sent at first during a call; it is specified by the
AMRHRIC attribute. This attribute can assume one the four specified codecs of the
ACS, otherwise if the operator doesnt specify any codec, the rule previously
described is followed.
8. the couple <Threshold-Hysteresis> related to the active codecs specified in the
AMRFRC1 and AMRFRC2 attributes, in case of Full Rate codec (AMRHRTH12).
9. the couple <Threshold-Hysteresis> related to the active codecs specified in the
AMRFRC2 and AMRFRC3 attributes, in case of Full Rate codec (AMRHRTH23).
10. the couple <Threshold-Hysteresis> related to the active codecs specified in the
AMRFRC3 and AMRFRC4 attributes, in case of Full Rate codec (AMRHRTH34).
The values of the described attributes depend on whether the channel is hopping or not:

if the channel isnt hopping the values must be defined in the BTS object only;

if the channel is hopping different values must be defined in the FHSY object,
according to different hopping laws.

AMR CHANNEL ALLOCATION STRATEGIES

At call establishment, the BSC has to define a strategy for deciding if AMR/FR or
AMR/HR channel has to be assigned (in case both of them are allowed in the request).
The choice is load dependent: if percentage of busy TCHs is greater than a threshold,
BSC allocates a TCH/H (whenever possible), otherwise it allocates a TCH/F. It has to
be noticed that this is only an additional check, put at the end of normal channel assignment procedure. For detailed description of this strategy please see "3.102 Enabling
Cell load dependent activation of HR channels".
Link Adaptation Phase
After having assigned an AMR channel the procedure of adapting the codec mode to
the current radio channel condition starts. This procedure is also called Link Adaptation.
Different codec modes can be applied for uplink and downlink. The BTS is always the
master in the link adaptation procedure and therefore it decides about the codec modes
that have to be applied. Codec adaptation is performed within the ACS (active codec
set). As the ACS consists of codecs of the same channel mode (FR or HR), the codec
modification is performed without notification to, or intervention by, the BSC.
Codec Mode Adaptation generally is done by choosing a Codec Mode adjacent to the
presently used from the AMR Active Codec Set. When the channel quality is good, the
BTS switches to the adjacent less robust AMR Codec Mode; when the channel quality
is poor, the BTS switches to the adjacent more robust AMR Codec Mode as this more
robust AMR Codec Mode provides better error correction by sacrificing some speech
quality.

A30808-X3247-L210-3-7619

513

OMN:BSC

Operation
Base Station Controller

In case the BTS still can find an adjacent more or less robust AMR Codec the Codec
Modification is performed without a handover; otherwise the AMR compression/decompression handover is performed. It can be performed in two cases:
AMR Compression/Decompression HANDOVER
In BR7.0, two different scenarios/algorithms for AMR Compression/Decompression HO
are possible:

Separate algorithms for AMR compression/decompression HO and AMR PC.

Linked algorithms for AMR Compression/Decompression HO and AMR PC.

Hereafter, the first scenario (separate algorithms) for AMR compression/decompression

HO is described :
1. when most robust codec of AMR HF is not robust enough for current channel conditions; in this case the call is moved from AMR HR to AMR FR channel, in order to
avoid bad speech quality (and consequent probable drop by one of the two involved
talkers). For the detection of this situation two attributes are provided; the handover
from HR to FR is triggered only if any of the two thresholds, defined by the two
attributes, is reached in terms of C/I value. The attributes are:
HOTHAMRDDL: it is used for detecting an AMR Handover "HR to FR" in order to
provide better speech quality (downlink direction).
HOTHAMRDUL: it is used for detecting an AMR Handover "HR to FR" in order to
provide better speech quality (uplink direction).
2. when least robust codec of AMR FR is used and quality indicator is indicating good
quality; in this case the call is moved to an AMR HR channel in order to save network
resources. For the detection of this situation two attributes are provided; the
handover from FR to HR is triggered only if both the two thresholds, defined by the
two attributes, are reached in terms of C/I values. The attributes are:
HOTHAMRCDL: it is used for detecting an AMR Handover "FR to HR", in order
to use the resources more efficiently (downlink direction)
HOTHAMRCUL: it is used for detecting an AMR Handover "FR to HR", in order
to use the resources more efficiently (uplink direction).
All the previous attributes belong to the HAND managed object.
The handover is decided inside BTS by means of quality measurements (C/I measurements either made by the BTS or reported by the MS).
To make the procedure more flexible, the following strategy is used, that takes into
account the considerations expressed above:
1. the AMR Handover from HR to FR is always enabled. Notice that in this case, checks
on cell load (see PROC: Enabling Cell load dependent activation of HR channels)
are skipped if there is at least one TCH/F free in the cell, handover is performed, no
matter whether the percentage of busy TCH/F is greater than a predefined
threshold;
2. the AMR Handover from FR to HR is enabled only when percentage of busy TCHs
overcomes a predefined threshold. As threshold values, the two database attributes
HRACTAMRT1 (standard cells/ Complete area of concentric cells/ Far area of
extended cells) and HRACTAMRT2 (Inner area of concentric cells/ Near area of
extended cells) are used; comparison between congestion level and threshold value
is performed every time timer TRFCT (database attribute) expires. When congestion
status of the cell changes, BSC sends to BTS an O&M message SET_ATTRIBUTE

514

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

in order to enable or disable AMR Handover from Full rate to Half rate in the cell. For
a detailed description of HRACTAMRT1 and HRACTAMRT2 attributes see
"3.102 Enabling Cell load dependent activation of HR channels". For a detailed
description of TRFCT attribute see"3.79 Management of Handover for Traffic")

For the AMR calls, the "Cell Load dependent activation for HR" is applied only at call
setup (AssReq, External incoming HO and Intercell HO), while for the intracell HO the
same channel rate will be maintained.
In fact if "Cell Load dependent activation for HR" feature was applied to intracell HO too,
the following situation would happen in a congested cell.
Let us suppose tha a new call must be established in the cell; due to the fact that load
is above the threshold an HR channel is activated. If the quality is poor a decompression
HO is triggered. Consequently the call continues in FR mode. If the quality on the new
FR channel continues to be bad the threshold for the RXQUAL based intracell HO is
crossed.
So, a new channel is assigned again in HR mode, due to the high load of the cell.
Consequently, to avoid this ping-pong situations, for a RXQUAL based intracell HO no
checks for the cell load is performed.
Compression & decompression handovers for AMR calls can be executed even if the
Link Adaptation phase is not completely exhauted.
Example: in case of HR 5.15 Kbit/s call, if the decompression HO threshold from HR to
FR is overcome, the HO is started and executed without Link Adaptation from rate 5.15
to 4,75 Kbit/s in order to immediately react to a rapid C/I change.
So, with the AMR implementation, an AMR HR call can be moved to an AMR FR
channel in order to avoid bad speech quality or an AMR FR call can be moved to an
AMR HR channel in order to save network ressources. The handover is decided inside
BTS by means of quality measurements. Besides, the AMR handover from HR to FR is
always enabled, whereas the handover from FR to HR is allowed when the congestion
in the cell overcomes a certain threshold . So if, in a cell, an AMR HR call experienced
a bad quality an handover from HR to FR is executed; but if the cell is congested a backhandover from FR to HR is executed. To avoid this ping-pong handovers, the number
of AMR FR/HR Intracell Handovers could be limited.
The adopted strategy is the following: when the maximun number of ping-pong
handovers has been reached (i.e. when the counter of ping-pong handovers reaches a
value defined by the operator) the next handover from FR to HR is not executed for a
defined period of time.

The counter is updated every ping-pong handover (i.e. every two handovers), where a
ping-pong handover is always considered starting from a FR call (i.e. FR --> HR and HR
---> FR). If a call starts as HR and then an HR to FR handover is executed, this first
handover is not considered in the counting.
The user can define both the maximum allowed number of ping-pong handovers and the
period of time for which a new FR--->HR handover is not executed after the maximum
number of ping-pong has been reached; these values can be configured using the same
parameters that are used to manage the limitation of intracell handover repetition
feature, i.e.:

A30808-X3247-L210-3-7619

the MAIRACHO parameter allows to configure the maximum number of ping-pong

handovers;

515

OMN:BSC

Operation
Base Station Controller

the TINOIERCHO parameter allows to define the period of time for which a new
FR--->HR handover is not executed.

So the same parameters assume a different meaning according to the type of the call
(i.e. if the call is an AMR one or not).
AMR INTERCELL QUALITY HANDOVER
For an AMR call, the already implemented quality handover is not based on averaged
RXQUAL, but on averaged C/I. Consequently, other thresholds have to be used. When
the averaged C/I goes below the operator defined thresholds:

HOLTHQAMRUL (hoLowerThresQualAMRUL) for uplink direction; the corresponding not AMR attribute is HOLTHQUUL

HOLTHQAMRDL (hoLowerThresQualAMRDL) for downlink direction; the corresponding not AMR attribute is HOLTHQUDL

an intercell handover for quality is triggered (these two attributes belong to the HAND
object).
Uplink measurements will be received in C/I, and summed up in interrupt context. The
average will be calculated at the reception of a SACCH report.
Downlink measurements will be received from the MS with the SACCH report and then
mapped to C/I-values. To gain a good granularity, a minimum averaging-window length
of four will be set.

Besides AMR handover parameters previously described, it is also possible to fit other
handover thresholds to AMR calls. E.g., for AMR calls it is possible to use specific
thresholds regarding concentric cell handovers or intracell handovers for quality. To
reach this target, four parameters (SG11HOPAR, SG12HOPAR, SG13HOPAR,
SG14HOPAR) have been introduced in the HAND object (see "3.78 Handover
Management" to get more information).

AMR POWER CONTROL FOR BTS AND MS

For an AMR-call, the already implemented procedures for Power Control will not be
based on RXQUAL but on averaged C/I. Consequently, other thresholds have to be
used.
For an AMR call, the limits of the 'target' window for the power control algorithm are:

516

LOWTQUAMRDL: the power control algorithm increases the present power if the
averaged and rounded integer value of the power level exceeds the threshold. In
order to achieve good granularity, a minimum averaging window size of 4 for the
averaging of C/I values (obtained from mapping RXQUAL values from the MS) is
used for AMR calls.
LOWTQUAMRUL: the power control algorithm increases the present power if the
averaged and rounded integer value of the power level exceeds the threshold.
UPTQUAMRDL: the power control algorithm reduces the present power if the averaged and rounded integer value of the power level exceeds the threshold. In order
to achieve good granularity, a minimum averaging window size of 4 for the averaging
of C/I values (obtained from mapping RXQUAL values from the MS) is used for AMR
calls.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

UPTQUAMRUL: the power control algorithm reduces the present power if the averaged and rounded integer value of the power level exceeds the threshold.

All these attributes belong to the PWRC managed object.

Besides AMR power control parameters described above, it is also possible to fit other
parameters to AMR calls. E.g. for AMR calls it is possible to define power control level
thresholds (upper and lower ones) different from those used for other kinds of calls. To
reach this target, four parameters (SG11PCPAR, SG12PCPAR, SG13PCPAR,
SG14PCPAR) have been introduced in the PWRC object (see "3.85 Management of
the Power Control" to get more information).

LINKING Between Compression/Decompression HO and POWER CONTROL for

AMR
As outlined before,the basic implementation of AMR compression/decompression HO
and PC for AMR are based on separate algorithms.More in details, the compression/decompression HO takes into account only the current C/I, regardless of the
already performed power reduction. This leads to the situation that best suited connections for compression handover might not be selected for handover.As a consequence,
the capacity gain achievable by dynamically switching to AMR HR codec modes cannot
be fully exploited.
In order to avoid the above bad situation, it shall be introduced a linking between the the
algorithms of power control and compression/de-compression handover for AMR: for
the decision on compression/decompression HO, the power reduction(PR) due to power
control shall be added to the current average C/I value.
The following additional attributes shall be introduced/added to HAND managed object:

EADVCMPDCMHO: its used as flag for activation/deactivation of the use of the new
primary conditions for compression/decompression handover.

HOTHCMPLVDL: its used as DL condition for triggering compression handover.

HOTHCMPLVUL: its used as UL condition for triggering compression handover.

HOTHDCMLVDL: its used as DL condition for triggering decompression handover.

HOTHDCMLVUL: its used as UL condition for triggering decompression handover.

MANAGEMENT OF TRAUs
In order to support AMR speech codec, dedicated circuit pools are implemented
(see 3.95) ; as a consequence new values has to be added to the range of the following
attributes:

DEFPOOLTYP (PCMA object)

POOLTYP (TSLA object)

As it as been described in "3.26 Download and Activate BTSE, BTSEC and TRAU SW
Loads" in BR7.0 release different software loads can be used for TRAU equipment (the
BR7.0 software load is the S3xxxx.BIN, whereas the other ones belong to BR6.0
release)

A30808-X3247-L210-3-7619

517

OMN:BSC

Operation
Base Station Controller

When TRAU equipment is loaded with a BR6.0 software load, two TRAC DSP loads are
available (S1xxxx.BIN and S2xxxx.BIN).
The first one can be used for TRACv1 and TRACv3 boards, whereas the second one is
specific for AMR, and it is available exclusively for TRAC V5 and TRACV7 boards.
This means that, if the TRAU dedicated to support AMR is equipped also by TRAC V3
and V1, these boards will be put in DISABLED state as soon as the TRAC Controller
software will answer to the TRAC_GET_ HW_VERSION command sent by the BSCI
board.
These two TRAC DSP load will be contained in two different TRAU SW loads.
The BSC will download only one of the two TRAU SW loads to the BSCI flash memory.
The TRAC DSP load specific for AMR will support also Enhanced Full Rate as backup
rate within SBS system. This fact has the following implication: if a handover has to be
performed on an AMR call in progress, and the target cell does not support AMR, the
speech algorithm will be switched from AMR to EFR (if EFR is included by MSC into the
allowed speech codec algorithms list).
This means that, when performing a handover to a target cell not supporting AMR,
speech algorithm cannot be switched to Full Rate speech version 1 or Half Rate speech
version 1, since they are not supported by AMR TRAU.
But this should not be a problem since, according to what we know, MSs supporting
AMR shall support EFR as backup rate. So this is not a drawback, since only AMR
mobiles will be connected to AMR TRAUs.
It has to be remarked that if later on MS performs a second handover, this time towards
a cell supporting AMR, the speech algorithm will be switched back to AMR.
Another consequent aspect to take into account regards the network efficiency: if we
assume that 1 or 2 TRAUs for each BSC support AMR, this means that they are "dedicated", i.e. as explained above they cannot manage FR or HR speech calls and Data
calls.
If TRAU equipment are loaded with the BR7.0 sofware load, it contains the S3xxxx.BIN
executable fot TRAC DSPs. In this case the following considerations can be drawn:

if the TRAU is equipped with TRAC boards from v1 to v5 versions, only a subset of
functionalities provided by S3xxxx.BIN will be managed (see 3.26);

TRACv7 boards will manage at the same time all functionalities provided by
S3xxxx.BIN executable;

if a small number of AMR channel is required, the customer is not obliged to waste
the whole TRAU (i.e. one Asub PCM line) for them.

MANAGEMENT OF BTSEs
It should be paid attention to the BTS HW version. Distinction has to be done between
BTSplus and BTS1 regarding Half Rate codec modes (no problems about Full Rate
codec modes). The following consideration can be done:
1. BTS plus supports five 8 Kbit/s submultiplexing half rate codec modes: 4.75, 5.15,
5.90, 6.70, 7.40 Kbit/s;

518

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

2. BTS1 supports only the three lowest bit rates (4.75, 5.15, 5.90 Kbit/s); 6.70 Kbit/sec
and 7.40 Kbit/sec Half Rate Codecs have not sufficient space in the proprietary
TRAU frame;
3. the 7.95 Kbit/s Half Rate Codec needs a 16 Kbit/s submultiplexing support and it will
not be supported neither by the BTS1 nor by the BTS Plus.
Tab. 3.110.24 summarizes the described situation.
AMR FR Codecs
supported by
BTSplus

AMR HR Codecs
supported by
BTSplus

AMR FR Codecs
supported by
BTS1

TCH/AFS 12.2

TCH/AFS 12.2

TCH/AFS 10.2

TCH/AFS 10.2

TCH/AFS 7.95

TCH/AFS 7.95

AMR HR Codecs
supported by
BTS1

TCH/AFS 7.40

TCH/AHS 7.40

TCH/AFS 7.40

TCH/AFS 6.70

TCH/AHS 6.70

TCH/AFS 6.70

TCH/AFS 5.90

TCH/AHS 5.90

TCH/AFS 5.90

TCH/AHS 5.90

TCH/AFS 5.15

TCH/AHS 5.15

TCH/AFS 5.15

TCH/AHS 5.15

TCH/AFS 4.75

TCH/AHS 4.75

TCH/AFS 4.75

TCH/AHS 4.75

Tab. 3.110.24Supported codecs by BTS1 and BTSplus

Prerequisites
The user must have the visibility level number set to "2";
The network element must be in phase "2".

Choose the operation you want to do

Would you like to set any specific AMR parameter?
Would you like to set the HRACTAMRT1 and HRACTAMRT2 thresholds?

h ... 2
h ..."3.102 Enabling
Cell load
dependent activation of HR
channels"

Would you like to set the TRFCT timer?

h ..."3.79 Manageme
nt of Handover
for Traffic"

Would you like to set the circuit pool equal to pool_23?

h ..."3.95 Circuit
Pool Concept"

A30808-X3247-L210-3-7619

519

OMN:BSC

Operation
Base Station Controller

Choose the parameter you want to change

Would you like to set attributes related to: Active Codec Set, Thresholds and
Hysteresis values between codecs?

Would you like to manage the number of ping-pong handovers?

h ... 3
h ... 6
h ... 8
h ... 7

Would you like to set parameters related to AMR compression/decompression HO: separate algorithm or linked algorithm?

h ... 9

Would you like to set AMR parameter related to Power Control?

Would you like to set AMR parameter related to Quality Intercell Handover ?

Consideration
Do you want to set the general attributes of a BTS?

h ... 4

Do you want to set the same attributes, but with values related to a specific
frequency hopping law?

h ... 5

Change the parameters for a cell

To change the value of these parameter, the user must enter the SET BTS
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

h ... END

Result: the values of chosen parameters are changed.

Change the parameters for a frequency hopping law

To change the value of these parameter according to a frequency hopping law,

the user must enter the SET FHSY command, following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> FHSY

---> SET FHSY

h ... END

Result: the values of chosen parameters are changed.

Change AMR parameters related to Power Control

To change the value of any AMR parameter related to Power Control , the user
must enter the SET PWRC command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> PWRC

----> SET PWRC

Result: the values of chosen parameters are changed.

520

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Manage the number of ping-pong handovers

To manage the limitation of ping pong handovers feature, the user must enter
the SET HAND command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL--->BTSM ---> BTS --->HAND

----> SET HAND
then the user can modify the parameters:
MAIRACHO
TINOIERCHO

Result: the value of chosen parameter is changed.

h ... END

Change AMR parameters related to Quality Intercell Handover

To change the value of any AMR parameter related to Quality Intercell

Handover, the user must enter the SET HAND command, following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL--->BTSM ---> BTS --->HAND

----> SET HAND

Result: the value of chosen parameter is changed.

10

Consideration
Do you want to enable the separate algorithm for AMR compression/decompression HO?

h ... 10

Do you want to enable the linked algorithm for AMR compression/decompression HO?

h ... 11

Set parameters related to separate algorithm for AMR compression/decompression HO

To set the value of parameters related to separate algorithm for AMR compression/decompression HO the user must enter the SET HAND command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL--->BTSM ---> BTS --->HAND

----> SET HAND
then the user can modify the parameters:
HOTHAMRDDL
HOTHAMRDUL
HOTHAMRCDL
HOTHAMRCUL

Result: the value of chosen parameters are set

A30808-X3247-L210-3-7619

521

OMN:BSC

11

Operation
Base Station Controller

Set parameters related to linked algorithm for AMR compression/decompression HO

To set the value of parameters related to linked algorithm for AMR compression/decompression HO the user must enter the SET HAND command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL--->BTSM ---> BTS --->HAND

----> SET HAND
then the user must set TRUE the EADVCMPDCMHO parameter/flag and set the
other parameters:
HOTHCMPLVDL
HOTHCMPLVUL
HOTHCMLVDL
HOTHCMLVUL

Result: the value of chosen parameters are set

END

522

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.111

OMN:BSC

Support of Satellite Link

Introduction
Some particular network configurations require to connect the BTSE to the BSC through
a satellite link.
The satellite in a geostationary orbit introduces an additional delay of 240ms; of course
this delay has impact both on the speech/data as well as on the signalling, exchanged
on the Abis, Asub and A interface.
Prerequisites
For the Abis interface see procedure "3.39 Addition of a New Site Manager and of
related LAPD links".
For the Abis interface in case of TD-SCDMA technology see procedure "3.120 Addition
of a New TD-SCDMA Site Manager and of Related LAPD Links".
For the Asub interface see procedure "3.71 Addition of a TRAU to the System".
For the A interface see procedure "3.72 Addition of a PCM Line A Interface and SS7
Link".

Preliminary Consideration
Do you want to enable/disable Support of Satellite Link for the GSM
system?

h ... 2

Do you want to enable/disable Support of Satellite Link for the TD-SCDMA

system?

h ... 3

Create LPDLM for Abis interface

Select the CREATE LPDLM command following the next sequence of

selections:

b
3

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> LPDLM --->

CREATE LPDLM

h ... 4

Create LPDLMTD for Abis interface

Select the CREATE LPDLMTD command following the next sequence of

selections:

b
4

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD --->

LPDLMTD ---> CREATE LPDLMTD
SET BSC for Asub or A Interface

Select the "SET BSC" command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

END

A30808-X3247-L210-3-7619

523

OMN:BSC

Operation
Base Station Controller

3.112

14.4 kbit/s Coding

Introduction
According to the GSM Phase 2 the mobile network foresees a maximum data speed on
a single time slot of 9.6 kbit/s; this is not sufficient to meet the demands of the modern
data applications. This procedure allows to overcome such a limit, in fact, a new channel
coding of 14.4 kbit/sec provides an enhancement in maximizing user data rate on a
single time slot. Moreover, this enhancement can also be used in combination with GSM
Phase 2+ multislot data services (i.e. HSCSD) to raise the data rate of a single user
channel.
14.4 kbit/sec coding is not supported by the BTS1 Siemens Base Transceiver Station
equipped with BBSIG (Base Band and Signalling) boards; the BTS successor model, i.e.
BTS1 with the newer BBSIG44 modul does support 14.4 kbit/sec coding.
The following BTS equipment:

BTS+
picoBTS
eMicroBTS
BTSC (BTS for TD-SCDMA)

dont contain BBSIG boards, and they always support 14.4 kbit/sec coding.
There exists an attribute (flag) in the BSC software which allows the BSC to distinguish
between a BTS1 which contains only BBSIG44 and a BTS1 which contains a mixture of
BBSIG and BBSIG44. This flag is called PUREBBSIG44CONF (BTS object) and the
setting is as follow:

BTS1 with mixed BBSIG-BBSIG44 moduls: PUREBBSIG44CONF set to FALSE;

BTS1 with only BBSIG44 moduls: PUREBBSIG44CONF set to TRUE.

To enable 14.4 kbit/sec coding, the user must first enable the feature at BSC level, by
setting to TRUE the SPEED145 attribute of the BSC object. If support of 14.4 is enabled
at BSC level, then:

14.4 data calls are always accepted on BTS+/pico/eMicro/BTSC;

14.4 data calls are accepted on BTS1 only if PUREBBSIG44CONF is set to TRUE.

Prerequisites
The attribute PUREBBSIG44CONF can be set to TRUE only if the BTS has been
created with BBSIG44 cards.

Enable 14.4 kbit/sec coding at BSC level

To enable 14.4 kbit/sec bit coding, the user must enter the SET BSC command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then the user must set at TRUE the value of the SPEED145 parameter.

524

A30808-X3247-L210-3-7619

Operation
Base Station Controller

Check the BTS equipment type

Does the BTS equipment belong to the BTS1 family?
Does the BTS equipment belong to either the BTSplus or the BTSC family?

h ... 3
h ... 6

Preliminary consideration
Does the equipment contain BBSIG44 boards only?

OMN:BSC

Y h ... 4
N h ... 5

Enable 14.4 kbit/sec coding at BTS level

To enable 14.4 kbit/sec bit coding, the user must enter the SET BTS command,
following the next sequence of selections::

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

b
b
Then the user must set to TRUE the value of the PUREBBSIG44CONF parameter.
Result: the 14.4 kbit/sec coding is enabled for the involved GSM cell.

h ... END

Set the PUREBBSIG44CONF attribute to FALSE

Since in this case the 14.4 kbit/sec coding is not possible, the user must enter
the SET BTS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> SET

BTS

Then the user must set the PUREBBSIG44CONF attribute to FALSE.

h ... END

No setting is necessary

With BTSplus and BTSC families, there are not any problems: using these
equipments, the 14.4 kbit/sec coding is always allowed.

END

A30808-X3247-L210-3-7619

525

OMN:BSC

Operation
Base Station Controller

3.113

Enabling Location Services

Introduction
Location Services (LCSs) are a network enhancing technology used by various location
applications, so-called LCS clients in the LCS architecture, which may be serviceprovider specific. LCSs enable the positioning of a mobile station (MS) in a GSM Public
Land Mobile Network (PLMN) to fulfill local regulatory requirements or for commercial
purposes.
The "Location Services" feature offers the following positioning methods:
a) Timing Advance: the TA positioning method positions the target MS within a circle
with the radius r and the BTS as its center. The resulting error margin amounts to
about 550 meters at most.
b) GPS: the GPS positioning method makes use of the Standard Positioning Service
(SPS), a grade of GPS service available for commercial applications, thus including
positioning of the target MS with a built in GPS receiver.
Two kinds of GPS positioning methods exist:
Mobile Assisted GPS: the network provides assistance data to the GPS equipped
MS to improve the measurement performance, e.g. a list of GPS satellites in view
for improved time-to-first-fix (TTFF) is a means of decreasing the acquisition time
for GPS positioning results. The MS performs GPS positioning and provides the
result to the network for correction, e.g. by means of correction data for Differential GPS (DGPS);
Mobile Based GPS: the MS performs both GPS positioning and corrections. The
network provides assistance data to the MS to both improve the measurement
performance and to correct the GPS positioning results. The assistance data is
provided to the MS via a dedicated link or the SMSCB.
c) Enhanced Timing Advance positioning method (E-TA): E-TA is a higher performance method than TA positioning, although remaining a low cost method, applied
to legacy mobiles, without other radio access network elements.
Generally speaking, the SBS behavior developed for E-TA method, is theoretically
similar to the very TA method, but the great amount of measurements (requested by
the SMLC, executed by the BTS in a more accurate way and by the MS, managed
from the BSC, transmitted to SMLC and then inserted into appropriate algorithm)
allows a better localization of the mobile than the standard TA method.

The LCS tries to locate the respective MS (target MS) in terms of universal coordinates
(latitude and longitude) and allows an LCS client to specify special Quality of Service
(QoS) parameters, e.g., accuracy or response time.

LCS feature is applicable to any target MS whether or not the MS supports it, but with a
restricted choice of the positioning method when individual positioning methods are not
supported by the MS.
LCS is implemented on the existing GSM structure through the addition of a new logical
node: the Serving Mobile Location Centre (SMLC).

526

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

In order to provide a more complete context for the system, the new entities and interfaces, introduced in the GSM network due to LCS, are described in the following. The
involved main entities are:

Mobile Station (MS): it makes the location measurements in case of Mobile Assisted
GPS and computes the location estimate in case of Mobile Based GPS;

BSS (BSC, BTS): the BSS is involved in the handling of the general network positioning procedures as well as in the handling of the various positioning methods (TA,
GPS, E-TA).

OMC-B/LMT: both the OMC-B and the LMT provide the necessary means for the
configuration of the Interface between the SMLC and the BSC;
Only the OMC-B handles the remote control of the SMLC.

Serving Mobile Location Center (SMLC): the SMLC manages the overall coordination and scheduling of resources required to perform positioning of the target MS.

The GMLC (Gateway Mobile Location Center): it is the first node an external LCS
client accesses in a GSM PLMN. The GMLC sends positioning requests to and
receives final location estimates from the SMLC (through the MSC). In one PLMN,
there may be more than one GMLC.

Lp

SMLC

SMLC

Um
BTS

BSC
Abis

MSC/VLR
A

GMLC
Lg

Le

External
LCS client

MS
Lc
GMLC

HLR

Other PLMN

Fig. 3.113.33 LCS network architecture

In general, the LCS positioning of a MS involves two main steps:
1. signal measurements within the selected positioning method;
2. location estimate computation based on the measured signals.

A30808-X3247-L210-3-7619

527

OMN:BSC

Operation
Base Station Controller

The BSS is involved in handling various positioning methods. As a generic handling

procedure supporting all positioning methods and as a fall-back procedure if there is no
LCS positioning method available, the BSS provides the serving cell ID and the TA of
the served MS to the Network and Switching System (NSS). This kind of architecture is
the so called NSS Centric Architecture; in this case the SMLC is NSS based, i.e.
there is an Ls Interface connecting it to the MSC. Using the NSS centric architecture
the SMLC is both physically and logically connected to the MSC (see Fig. 3.113.34).
On the other hand, we speak about BSS Centric Architecture, when the SMLC is
BSS based, i.e. there is an Lb Interface connecting it to the BSC. Using the BSS
centric architecture the SMLC is still physically connected to the MSC, but it is logically
connected to the BSC (see Fig. 3.113.35).

SMLC

Ls
Um
BTS

BSC
Abis

MSC/VLR
A

MS

Fig. 3.113.34 NSS centric architecture.

SMLC

Lb
Um
BTS

BSC
Abis

MSC/VLR

MS

Fig. 3.113.35 BSS centric architecture.

Regarding the connection among BSC, MSC and SMLC, three different cases are
discussed in the following, to display the differences from the configuration point of view;
they are:

528

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

1. Location Services are not configured (i.e. the SMLC is not provided): the MSC
and the BSC are directly interconnected by at most sixteen signalling links (SS7L);
the links are grouped in a unique linkset implementing the A interface and sharing
the traffic among them.

SS7L-0

MSC
SPC xyz

SS7S-0

SS7L-15

Fig. 3.36

SS7L-0

BSC
OPC xyz
SS7L-15

Connection between BSC and MSC.

The useful information to configure this network configuration is shared in two

objects: OPC and SS7L (see "3.72 Addition of a PCM Line A Interface and SS7 Link"
and "3.75 Definition of the Signalling Point Code"). The SS7S object is available to
the operator only for reading operations and alarm handling.
The SS7L objects represent the signalling links. Every BSC can have at most
sixteen (0..15) SS7L object instances.
The SS7S object represents the signalling linkset information. Every BSC has only
one SS7S object and it cant be configured.
All the MTP/SCCP functional parameters are given creating the OPC object (see
"3.75 Definition of the Signalling Point Code").
The user creates as many SS7L objects as the number of links he wants to equip in
the system, while the SS7S object is:
automatically created, when the first SS7L object is created;
automatically deleted, when the last SS7L object is deleted.
The OPC object describes the home point code (OPC of BSC), the adjacent point
code (SPC, in this case the MSC), the network type (NATIONAL/INTERNATIONAL),
the MTP type (CCITT/ANSI), the application part used (subsystem number of
BSSAP) and all the necessary timers for the interface with MSC (Level 2 timers,
Level 3 timers, SCCP timers).
2. NSS Centric Architecture (the SMLC network element is provided): using this
method, it is required the Service Mobile Location Centre (connected to the MSC
through the Ls interface, see Fig. 3.113.34); the SMLC coordinates the location
procedure and also calculates the final location estimate and accuracy. For the TA
positioning method in the NSS centric architecture it is not requested any change in
the network connection between MSC and BSC. The positioning is carried out using
the signalling links already available.
3. BSS Centric Architecture (the SMLC network element is provided): the Lb
logical interface, which is used for LCS signalling between the BSC and the SMLC,
is realized through a physical BSC-MSC-SMLC link (see Fig. 3.113.35). This
means that the SMLC is connected to the BSC via MSC as an intermediate entity.
For this purpose, the following options are implemented for the MSC, acting as a
relay point from the BSC point of view:

A30808-X3247-L210-3-7619

529

OMN:BSC

Operation
Base Station Controller

use of Signaling Transfer Point (STP) functionality in the MSC; i.e. the MSC reads
the incoming messages and according to the destination point code, it processes
the messages or it routes them to the SMLC;
set-up of a Nailed Up Connection (NUC) for one SS7 link in the MSC; i.e. all the
messages are routed to the destination entity.
The use of the STP functionality in the MSC is the preferred solution, because in this
case the already existing procedures for an SS7 link set on the A interface (e.g., for
load sharing and redundancy) can be used. Thus, all the different kinds of traffic are
shared between the established SS7 links.
With the set-up of a NUC in the MSC, the SS7 link used is exclusively allocated to
LCS traffic and therefore there might be a waste of link resources, if not extensively
used by the LSC.
The restrictions imposed in both the configurations, are that there is only one SMLC
in the BSS structure and it must be reached by one and only one linkset. The MSC
is always reached by linkset 0; the SMLC can be reached by linkset 0 with MSC
acting as STP, or by linkset 1 with a dedicated linkset (see Fig. 3.37 and Fig. 3.38).
To realize both the situations, a different split up of parameters between objects OPC
and SS7S is foreseen, and some attributes are introduced in the system.
The OPC object is single for every BSC, it contains all the not instanced informations. This is a list of the affected parameters:
MSCSPC: this attribute contains the MSC identity within the network. It consists
of three fields: NetworkClusterMember, NetworkCluster, NetworkIdentifier. It is a
mandatory attribute in the system.
SMLCSPC: this attribute contains the SMLC identity within the network. It
consists of three fields: NetworkClusterMember, NetworkCluster, NetworkIdentifier. The validity range for this attribute is the same as foreseen for MSCSPC
attribute, the only restriction is that it can assume only values different from
MSCSPC. Its default value shall be Unequipped.
APLESSNBSC: this attribute contains the new subsystem number (from SMLC
point of view) used in the Lb interface, it is a optional attribute in the system. The
range for this attribute is the same as provided for BSSAPSSN. Its default value
shall be 250.
APLESSNSMLC: this attribute contains the new subsystem number (from BSC
point of view) used in the Lb interface and it is a optional attribute in the system.
The range for this attribute is the same as provided for BSSAPSSN. Its default
value shall be 252.
MSCPERTFLAG: this attribute is a flag indicating if a periodic test flag is required
for the linkset connecting the MSC and the BSC. Its default value is TRUE.
SMLCPERTFLAG has the same function as MSCPERTFLAG but for the linkset
connecting the SMLC and the BSC. It is a optional attribute in the system. Its
default value is TRUE.

530

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

SMLC
SPC xyz

Lb Interface
SS7L-0

SS7L-0

A Interface

MSC
SPC xyz
(STP)

SS7S-0

SS7L-15

SS7L-15

Fig. 3.37

BSC
OPC xyz

Connection among BSC, MSC and SMLC (the MSC acts as a STP).

SMLC
SPC xyz

SS7S-1

Lb Interface

SS7L-0

MSC
SPC xyz
(STP)

A Interface
SS7S-0

BSC
OPC xyz
SS7L-15

Fig. 3.38

Connection among BSC, MSC and SMLC (NUC across the MSC).

There are up to two SS7S objects (ss7sn = 0-1) for every BSC, they represent the
communication linkset between MSC and BSC or BSC and SMLC. These linksets
are automatically created/deleted allocating or deallocating signalling links on them.
There are at most sixteen SS7L objects (0..15) for every BSC representing the SS7
links shared in up to two linksets. The creation of signalling links determines the
network configuration and the SMLC position within it (through the LINKSET
attribute):

A30808-X3247-L210-3-7619

531

OMN:BSC

Operation
Base Station Controller

if all the signalling links are created on linkset 0, it means that the SMLC (if the
SMLCSPC is configured) is reached from the BSC via MSC acting as STP);
if there are signalling links created on both linkset-0 and linkset-1, it means that
the SMLC (if the SMLCSPC is configured) is reached directly by BSC via the
signalling links belonging to the linkset-1.

Regarding the location procedures, the BSS centric architecture and the NSS centric
architecture differ in some aspects:
a) NSS Centric Architecture: the Cell Identification + Timing advance method (the
only one supported) is based on the existing timing advance (TA) parameter; the TA
value is known from the serving BTS as soon as a mobile sends a request to access
the network, due to a mobile originating call, or mobile terminating call.
When a MS must be localized, the following steps are performed:

the GMLC asks the MSC to locates the MS;

the MSC forwards the request to the SMLC (through the Ls interface);
the SMLC ask the MSC the MS data (e.g. the TA);
the MSC routes the request to the BSC: during the setup of the call (sending of
the Channel Request to the network), the TA value is calculated by the serving
BTS and it is autonomously transferred to the BSC on the Abis Interface (in the
Channel Required message); when the BSC requires in later call phases an
updated value of TA, this is demanded to the BTS via an already specified procedure (exchange of Physical Context Request/Confirm messages);
The TA value plus the Cell Id is transferred, via A Interface, from the BSC to the
MSC (a new procedure is specified for this purpose, see below), which is in
charge to forward these information to the SMLC on the Ls Interface;
the SMLC gives the answer to the GMLC.
b) BSS Centric Architecture: when a MS must be localized, the following steps are
performed:
the location request starts from the MSC, that forwards the request to the BSC;
the BSC interacts directly with the SMLC (through the Lb interface) exchanging
information about the location;
finally the BSC gives the location answer to the MSC.

It must be noted that: in case of BSS centric architecture the BSC is the master of the
location procedure, after having received the request from the MSC; in case of NSS
centric architecture the procedures are driven from the MSC and the BSC acts as slave.

From the configuration (O&M) point of view, the following parameters are also involved
with LCS feature:
1. LCSNSSC (BSC object): it allows to enable/disable the LCS feature, using the NSS
Centric Architecture; in order to configure the BSS Centric Architecture it must be
put to FALSE;
2. CITASUP (BSC object): this attribute allows (for both NSS and BSS Centric Architectures) to enable sending of Cell Identifier and Timing Advance, via the A interface,
from BSC to MSC; then this latter will send the information to the SMLC. The CITASUPP allows then to enable the new procedure to send CI and TA information

532

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

toward the MSC; the information will be put inside the BSSMAP Complete Layer 3
message.
Sending information related to the Cell Identifier and Timing Advance is very useful
when the location accuracy within the QoS can be satisfied by reporting this information only.
Notes about Enhanced TA positioning method
With TA positioning, based on the known cell-Id (CI) and applied TA value, the possible
MS position forms a circle or ring segment around the serving BTS, with a certain error
margin.
By exploiting several measurements done by both the MS and the BTS (e.g. RXLEV of
serving and neighboring cells), additional information can be retrieved, and then the
overall resulting error margin is considerable lower.
The necessary measurement data are provided by the BSS towards the (BSS based)
SMLC where the position calculation is carried out mainly by means of predictionmatching. This so-called Enhanced TA Positioning (E-TA), which is not standard
compliant, is provided from BSS and SMLC sides, in addition to the TA Positioning
(standard compliant).
The basic idea behind E-TA Positioning is prediction-matching, i.e. the position of a
mobile subscriber can be obtained by comparing the measured field strengths of serving
and neighboring cells at the MSs position against pre-calculated field strengths predictions. Thus, the mobile subscribers position is inferred from the best prediction match.
The E-TA positioning is always initiated by SMLC by means of the respective signalling:
1. the application of E-TA positioning is indicated by the SMLC by means of the
BSSLAP E-TA REQUEST message. This message contains a certain number of
measurements required for enhanced TA positioning, and the maximum time delays
to collect the measurement;
2. hence the BSC sends the LCS REQUEST message including these parameters
towards the BTS;
3. the BTS answers to BSC with the LCS RESPONSE message, when one of the
following constraints are satisfied:
the requested measurements are available or collected;
the accepted delay is elapsed: in this case the available measurement set is sent
back to BSC.
4. When the LCS RESPONSE message is received by the BSC, the BSC relays the
measurement data within the BSSLAP E-TA RESPONSE message to the SMLC.
In BR7.0 release, the BSC could be connected with different releases of BTS and
SMLC. Then several signalling scenarios are possible.
Only in case all involved entities (SMLC, BSC and BTSE) have BR7.0 software version
installed, E-TA Positioning can be applied, otherwise only TA, positioning method is
possible.
From the O&M point of view, the TAADJ parameter (timing advance adjust, BTS object)
is used to avoid that the delay introduced from the cables, between antenna and BTS,
could be of the same granularity of the timing advance measurement. In fact the better
accuracy of the E-TA method requires to take into account the signal delays due to the
wave propagation in the wires.

A30808-X3247-L210-3-7619

533

OMN:BSC

Operation
Base Station Controller

The BTS detects the burstshift with an enhanced accuracy (1/16 symbol period). As
consequence of this high resolution, the propagation delays created on the BTS internal
signal path have the same magnitude as the detected burstshift. Then the BTS will
correct the detected burstshift with the configured TAADJ value.

Prerequisites
The user must have the visibility level set to number "2".

Choose the LCS architecture to enable

Do you want to enable a NSS centric architecture?
Do you want to enable a BSS centric architecture?

h ... 2
h ... 3

Enable location services (NSS centric)

Enter the SET BSC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then choose the following parameter setting:
LCSNSSC=TRUE
CITASUP=TRUE

Result: the feature is enabled.

h ... END

Choose the connection type between BSC and SMLC

Do you want to use a NUC connection across the MSC?

h ... 4

Do you want to use the Signalling Transfer Point (STP) functionality in the
MSC?

h ... 7

Configure the OPC parameters

Enter the SET OPC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> OPC ---> SET OPC

Then set the following parameters according to your needs:
SMLCSPC
APLESSNBSC
APLESSNSMLC
SMLCPERTFLAG

534

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Create the SS7L link

Enter the CREATE SS7L command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SS7L ---> CREATE SS7L

Then set the LKSET attribute to 1.

Result: the instance 1 of the SS7S object is created too.

Set to FALSE the LCSNSSC attribute

Enter the SET BSC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC --->SET BSC

Then he must set:
LCSNSSC=FALSE.
You can also set the CITASUP parameter to TRUE if you want that Cell ID and
Timing Advance information are used in the positioning method.

Result: the location services (BSS centric) are enabled.

h ... END

Configure the OPC parameters

Enter the SET OPC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> OPC ---> SET OPC

Then set the following parameters according to your needs:
SMLCSPC
APLESSNBSC
APLESSNSMLC
SMLCPERTFLAG

Set to FALSE the LCSNSSC attribute

Enter the SET BSC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then set:
LCSNSSC=FALSE.
You can also set the CITASUP parameter to TRUE if you want that Cell ID and
Timing Advance information are used in the positioning method.

Result: the location services (BSS centric) are enabled.

END

A30808-X3247-L210-3-7619

535

OMN:BSC

Operation
Base Station Controller

3.114

Enabling Antenna Hopping

Introduction
This feature introduces a new type of hopping, the Antenna Hopping.
The introduction of Antenna Hopping offers a new hopping mechanism: the DL bursts
of a channel are transmitted on GSM frame basis (or every 2nd or 4th frame) over alternating antennas within a cell. Antenna Hopping allows to obtain in DL direction a performance improvement (diversity gain) of several dBs.
The hopping mechanism is the main difference between Antenna Hopping and the
already supported frequency hopping schemes, baseband and synthesizer hopping: TX
Antenna Hopping is performed on CU basis, not on timeslot basis, that is to say
always complete CUs, including all timeslots on them, perform Antenna Hopping. It is
not possible to generate Antenna Hopping sequences for each timeslot individually.
A combination of synthesizer frequency hopping and Antenna Hopping is possible,
whereas a combination with baseband frequency hopping is not allowed, because the
TX Diversity/Antenna Hopping feature itself is based on some baseband hopping mechanism.

If the HOPMODE attribute in the BTS object is set to baseband hopping no Antenna
Hopping can be activated, and a BTSE alarm with severity minor Baseband
Hopping/Antenna Hopping conflict is generated.
The feature is a complete SW feature, requiring no modifications in any HW.
Antenna Hopping is supported only by BTSplus mainline, BS240XS and e-Micro BTS.
Due to the limitations of the CClink PicoBTS is not able to do baseband frequency
hopping and therefore also no Antenna Hopping. Antenna Hopping is not specified for
BTSs belonging to BTSone family, such as BS60, BS20, BS11.
The Antenna Hopping feature is enabled on cell basis, by means of the O&M parameter
EANTHOP (see table Tab. 3.114.26). All types of BTS combiners are supported but
FICOMs. FICOMs are tuned via motor to a specific TRX frequency so that only baseband frequency hopping is possible, which is forbidden parallel to Antenna Hopping.
CUs connected to a FICOM are excluded automatically from Antenna Hopping.
Antenna Hopping has to deal with various types of CUs (e.g. GSM-CU, EDGE-CU and
SB-EDGE-CU for switched beams) and frequency bands (e.g. GSM900, DCS1800 and
PCS1900). For this a CU-POOL concept has been developed, restricting the Antenna
Hopping between CUs of the same POOL only and hence also between the antennas
to which the corresponding CUs of the POOL are connected. It is not possible to make
Antenna Hopping between CUs of different types and frequency bands.
For each pool a hopping sequence has to be calculated. The pool grouping and the
calculation of pool sequences are done in the BTS core (COBA) by a dedicated algorithm.

536

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

CU-POOLs
The algorithm running in the BTS analyses the CU types installed and the wiring data of
the CUs with the combiners/TX antennas, as soon as TX Diversity/Antenna Hopping is
enabled by means of O&M. CUs connected to a FICOM are not assigned to any CUPOOL.
For the BCCH-TRX there exists a separate parameter in O&M, which enables/disables
Antenna Hopping for the BCCH-TRX (see table Tab. 3.114.26). Antenna Hopping is
enabled for either all CUs including the BCCH-TRX one or for all CUs with the exception
of the BCCH-TRX one. If Antenna Hopping for the BCCH-TRX is excluded, the corresponding CU is not assigned to any CU-POOL.

The feature "not-ramping for BCCH" will be deactivated if Antenna Hopping with
ANTHOPMOD (AntennaHoppingMode)=ALLTRX is set.
The algorithm assigns the CUs not connected to a FICOM to appropriate CU-POOLs.
At the moment there are two CU types, GSM-CU and EDGE-CU. The grouping of CUs
together in the CU-POOLs depends on the connected combiner, therefore the Antenna
Hopping algorithm always looks at the CU type and the frequency band of the connected
combiner. The table below shows the available combinations due to SIEMENS BSS
HW.
Frequency
band

DUAMCO
capability

CU capability
GSM

CU capability
EDGE

E-GSM 900
DCS 1800

PCS 1900

E-GSM + GSMR 900

P-GSM 900

GSM-RE 900

X (only e-Micro) X

Tab. 3.114.25Available combinations due to BSS hardware

All CUs of the same frequency band and of the same HW type are always assigned to
the same CU-POOL. A CU-POOL consists at least of one single CU (one CU, however,
is not sufficient for any Antenna Hopping scheme). The maximum number of CUs in a
CU-POOL is limited by the number of CUs installed at the BTS. There are no restrictions
to the number of antennas that a CU can be connected to.
Note that a CU is physically connected to one antenna only. The connections to the
other antennas, for Antenna Hopping purpose, are merely virtual: the GSM data is
calculated and formatted, on frame basis, by the CU and than submitted to the BTS
core, which distributes it to the appropriate transmitting CUs.
The CUs hop always together with the CUs in the same CU-POOL. The algorithm guarantees that an EDGE-CU never hops together with a GSM-CU and a GSM 900 EDGECU never hops together with a DCS 1800 EDGE-CU.
Regarding the configurations rules of the Antenna Hopping feature, combining Equipment of the same type shall be used in a cell:

A30808-X3247-L210-3-7619

537

OMN:BSC

Operation
Base Station Controller

the Combining Equipment in a cell must support the same frequency range (PGSM,
ExtendedGSM or GSMR);
DUAMCO 2:2, 4:2 and DUAMCO 8:2, etc. have a different attenuation. A mixing
therefore would cause a small performance degrading. The recommendation should
be to use the same type of combiners in a cell.

Hopping sequence
After having grouped the CUs in pools, the BTS algorithm calculates the Antenna
Hopping sequence individually for each CU-POOL.
The operator, by means of the O&M parameter ANTHOPP (see table Tab. 3.114.26),
can set the hopping period, i.e. can decide how many frames are transmitted over each
antenna before the next one is used to send the frames. Antenna Hopping is performed
every one, two or four frames.
Additionally there is the mode 4-4-5, which means that each 3rd hopping step the period
is extended from 4 to 5 frames (suitable especially for GPRS/EGPRS).
The number of antenna changes depends on the number of used antennas and service
(4-4-5 used for EDGE).
The hopping period has to be set also with respect to the connection rate. In the case of
2 antennas with 2 connected CUs, for example, swapping TX antennas on a TDMA
frame base would lead to hardly any TX diversity for half rate connections, since HR
uses every 2nd burst only.
In the following example a CU-POOL consisting of 5 CUs is considered, together with
two different antennas A0 and A1. The antenna hopping sequence is shown for each
configurable hopping period.
Antenna
A1

Antenna
A0

CU_O

CU_3

CU_1

CU_4
hopping

CU_2

Fig. 3.114.39 Antenna hopping with 5 CUs and 2 antennas

Antenna hopping period = 0 -> every frame

538

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

CU_2
FN
FN + 1
FN + 2
FN + 3
FN + 4
FN + 5 (same like FN)

A_0
A_1
A_0
A_1
A_0
A_0

CU_4
A_1
A_0
A_1
A_0
A_0
A_1

CU_1
A_0
A_1
A_0
A_0
A_1
A_0

CU_3
A_1
A_0
A_0
A_1
A_0
A_1

CU_0
A_0
A_0
A_1
A_0
A_1
A_0

Antenna hopping period = 1 -> every second frame

CU_2
FN
FN + 1
FN + 2
FN + 3
FN + 4
FN + 5
FN + 6
FN + 7
FN + 8
FN + 9
FN + 10 (same like FN)

A_0
A_0
A_1
A_1
A_0
A_0
A_1
A_1
A_0
A_0
A_0

CU_4
A_1
A_1
A_0
A_0
A_1
A_1
A_0
A_0
A_0
A_0
A_1

CU_1
A_0
A_0
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_0

CU_3
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_0
A_0
A_1

CU_0
A_0
A_0
A_0
A_0
A_1
A_1
A_0
A_0
A_1
A_1
A_0

Antenna hopping period = 2 -> every fourth frame

CU_2
FN
FN + 1
FN + 2
FN + 3
FN + 4
FN + 5
FN + 6
FN + 7
FN + 8
FN + 9
FN + 10
FN + 11
FN + 12
FN + 13
FN + 14
FN + 15
FN + 16
FN + 17

A30808-X3247-L210-3-7619

A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0

CU_4
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0

CU_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1

CU_3
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0

CU_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1

539

OMN:BSC

Operation
Base Station Controller

CU_2
FN + 18
A_0
FN + 19
A_0
FN + 20 (same like FN) A_0

CU_4
A_0
A_0
A_1

CU_1
A_1
A_1
A_0

CU_3
A_0
A_0
A_1

CU_0
A_1
A_1
A_0

Antenna hopping period = 3 -> sequence 4-4-5 frames

CU_2
FN
FN + 1
FN + 2
FN + 3
FN + 4
FN + 5
FN + 6
FN + 7
FN + 8
FN + 9
FN + 10
FN + 11
FN + 12
FN + 13
FN + 14
FN + 15
FN + 16
FN + 17
FN + 18
FN + 19
FN + 20
FN + 21
FN + 22
FN + 23
FN + 24
FN + 25
FN + 26
FN + 27
FN + 28
FN + 29
FN + 30
FN + 31
FN + 32
FN + 33
FN + 34
FN + 35
FN + 36
FN + 37
FN + 38

540

A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_1

CU_4
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0

CU_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0

CU_3
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_1

CU_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_0
A_1
A_1
A_1
A_1
A_0
A_0
A_0
A_0
A_0

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

CU_2
...
...
...
FN + 65 (same like FN)

...
...
...
A_0

CU_4
...
...
...
A_1

CU_1
...
...
...
A_0

CU_3
...
...
...
A_1

CU_0
...
...
...
A_0

RF Loop Back might cause problems due to the collecting of measurement data. The
impacts of Antenna Hopping on RF Loop Back are similar to the existing behavior with
normal baseband frequency hopping. The reason is that abnormal abortions from calls
cannot be mapped to a specific HW chain consisting of antenna, combiner, CU.

If the operator wants to know reliable RF Loop Back information in a cell, the feature
Antenna Hopping must be switched off by the operator temporarily. After certain time
Antenna Hopping can be enabled again.
In order to manage Transmit Diversity/Antenna Hopping some parameters are added in
the BSS system to the BTS object. The following table shows these attributes:

Parameter

Purpose

EANTHOP (EnableAntennaHopping)

The attribute indicates whether Antenna

Hopping is enabled or disabled for the
BTS.

ANTHOPMOD (AntennaHoppingMode)

The attribute specifies whether the BCCH

transceiver has to be included in the
hopping sequence or not.

ANTHOPP (AntennaHoppingPeriod)

The attribute specifies how many frames

are transmitted over each antenna before
the next one is used to send the frames.

Tab. 3.114.26 BTS object parameters used to manage Antenna Hopping

In the case of locking a CU in a cell with enabled Antenna Hopping the concerned CU
will be blocked at once but Antenna Hopping in the cell will be disabled first after 9,6s.
During this time the quality is reduced. Therefore Antenna Hopping has to be disabled
before locking a CU in this cell.

Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".
The value of the HOPMODE attribute in the BTS object must be different from BBHOP
(baseband hopping).

A30808-X3247-L210-3-7619

541

OMN:BSC

Choose the operation you want to do

Would you like to enable the Antenna Hopping on a cell?
Would you like to disable the Antenna Hopping on a cell?
Would you like to set any Antenna Hopping parameter?

h ... 4
h ... 6
h ... 5

Preliminary Consideration
Is Frequency Hopping already enabled on the cell?

Operation
Base Station Controller

Y h ... 4
N h ... 3

Set the hopping attribute to true

The hopping attribute must be set to true for the involved BTS using the SET
BTS command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS with HOPP=true

Result: Setting the Enable Hopping attribute as true for the involved BTS.

Enable Antenna Hopping on a cell

To enable Antenna Hopping on a cell, the user must enter the SET BTS
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS with EANTHOP=true

Result: the Antenna Hopping is enabled on the selected cell.

h ... END

Change parameters

To change the value of the parameters, the user must enter the SET BTS
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS (parameters ANTHOPMOD and/or ANTHOPP)

Result: the values of the chosen parameters are changed.

542

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Disable the Antenna Hopping on a cell

To disable Antenna Hopping on a cell, the user must enter the SET BTS
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS with EANTHOP=false

Result: The Antenna Hopping is disabled on the selected cell.

END

A30808-X3247-L210-3-7619

543

OMN:BSC

Operation
Base Station Controller

3.115

Management of Transmission Diversity with Time Delay

Introduction
This feature allows to combine the output signals of two standard carrier units (fed with
the same baseband signal) to increase the available output power of the BTS.
To allow parallel CU operations, their transmitted signals must be de-correlated; in fact,
when a couple of de-correlated signals is used, it is established a downlink diversity
path, that significantly reduces the influence of signal fading (see below).

This feature regards the following BTS types only: BS40, BS41, BS240, BS241, and
BS240XS.
By combining pairs of Carrier Units (CU), cells can support high coverage due to the
applied downlink diversity (because the output power is increased). When a couple of
CUs is used to get transmission diversity, one of them is the master one and the
remaining one is called slave. When this CU combination is released, the capacity of
the cells becomes doubled, getting higher capacity.
The increasing in the number of CUs used for diversity operation is normally associated
with higher combining losses; but as it has been said, the main advantages of this kind
of CU allocation are:
1. green-field operator through roll-out can temporary use higher coverage mode to
cover as much area as it is possible;
2. when additional BTS sites have been added, the operator, with a simple software
switching to higher capacity mode, can increase the capacity of its network without
having to touch the installed BTS hardware.
Besides, when on-air combining is used, full diversity gain can be obtained since there
are not additional combining losses in diversity configuration.
The transmission diversity feature is an extension of transmission Antenna Hopping
(see "3.114 Enabling Antenna Hopping"). Transmission Diversity exploits the full advantage of Transmission Antenna Hopping while adding an extra downlink gain. The downlink budget of the BTS can be significantly improved by using transmission diversity,
which helps to balance the cell ranges of 850/900 MHz and 1800/1900 MHz in co-location scenarios. Rural coverage improvements lead to an increased turnover.
With antenna hopping, when it is used the traditional approach of 4 carriers in one
sector, by alternating the use of CUs from a set of 4 CUs, the improvements in downlink
budget are included in the range 0 - 2 dB. The channel-encoded data gets interleaved
over discrete bursts. When transmitting the bursts, the transmission antenna hopping
uses one antenna selected from the antenna set according to predefined patterns.
Limiting the bit error rate by interleaving information transferred is according to the
channel-coding scheme applied.
On the other side, when the conventional transmission diversity uses a couple of CUs,
that are fed with the same baseband signal input transmitted on the same carrier, the
improvement in downlink budget is included in the range 0 -3 dB. Moreover, additional
3 dB can be gained if the CU pair uses on-air combining.

544

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

As it has been described, transmission diversity uses the output signals of two CUs that
transmit on the same carrier and are fed with the same baseband signal input. When
using separate antennas for the two CUs to work in parallel in the same cell, their multipath propagation can cause downlink signal dropping.
As the two propagation paths interfere in a cell, they result in a pattern of signal strength
that is locally present and comparable to that of a multi-path propagation caused by
reflections. The two CUs transmit equal signal strength, and there is a high probability
of a complete signal dropping in case of interference.
In order to best prevent signal dropping, an additional signal processing is carried out
on the transmitting side. The feature applies de-correlation of the two signals by a
specific timing offset of the modulation signal. The performance considerations favor the
de-correlation method of transmission diversity time delay.
The method adds a distinct timing offset to the GSM bursts of one of the two CUs. The
method introduces an assigned GSM timer to control the CU timing for offset shift
purposes, and the GSM timer processes an offset control input. The GSM timer operates at a stable 52MHz clock signal, and the generated GSM burst signal can be
delayed by an appointed amount of 52MHz clocks. The operator is able to adjust the
delay value, which is proportionate to a step size of 0.25 symbols between minus 5 and
plus 5 symbols.
The CUs transmit the two signals, and the mobile station resolves them by using the
built-in equalizer. The equalizer performs pulse response computation for each transmitted burst, and handles the two signals according to multi-path propagation. In
contrast to the vector addition of the two transmitted signals, the equalizer performs the
signal addition using the bit energy value. The performance evaluation shows that the
transmission diversity time delay feature is dependent on the equalizer algorithm implemented in the mobile stations. Those different algorithms comply with applying the
transmission diversity time delay.
A parallel operation of two CUs required for the parallel transmission of de-correlated
signals is feasible and compatible with baseband hopping. The CU processes data similarly to baseband hopping. With difference to baseband hopping, not a single CU but a
pair of CUs is defined to transmit data. The CU pair operates at the same carrier
frequency. Both CUs of the pair are assigned to the same cell antenna sector, and the
CUs use separate antennas. A distance higher than ten lambdas preferably separates
the antennas when combining on-air transmissions.
The following example (see Fig. 3.115.40) may illustrate co-location in an extended
circular cell that enables satisfying customer requests for increased cell capacity, by
using different carrier frequency bands (e.g., 850/900 and 1800/1900 MHz).

A30808-X3247-L210-3-7619

545

OMN:BSC

Operation
Base Station Controller

Fig. 3.115.40Example of transmission diversity

Two CU pairs consisting of a master and a slave CUs, apply transmission diversity time
delay operation. One pair of CUs transmits on one frequency band, and the other pair
of CUs transmits on another frequency band.
For example, the BTS installation uses one rack for three sectors, and antenna 0 and
antenna 1 are configured to serve the same cell sector 0. A Duplexer Amplifier MultiCoupler Combiner (DUAMCO 4:2) enables the master CUs of the pairs to use the same
primary antenna 0, and the slave CUs to use the same secondary antenna 1. The CUs
0 to 3 are connected to these antennas via antenna combiner in a way that the even
CUs 0 and 2 are connected to the antenna 0, and the odd CUs 1 and 3 are connected
to the antenna 1. Then there are the CU pairs with one even and one odd number. CU
0 and CU 1 compose one CU pair, and the CU 2 and the CU 3 compose a next CU pair,
respectively. Each CU pair is suitable for transmission diversity time delay operation.
Both CUs of such a pair use the same carrier frequency, and both CUs of the same pair
transmit simultaneously. The even CU of a pair acts as a master, while the odd CU
serves as a slave. The slave CU does not read the transmitted data from its master CU,
but receives data from the system simultaneously to the master CU. The slave CU
performs the timing offset shift in order to delay the transmission signal.

546

The transmission diversity time delay feature raises an additional inaccuracy caused
by the actual timing deviation of the two transmitting CUs, due to the different length of
the feeding cables and the antenna positions. The transmission diversity time delay
operation can be disabled for certain burst types that are timing-sensitive, e.g., the
synchronization channel (SCH) for Location Services (LCS). The transmission of the
slave CU is disabled when such a burst type is going to be transmitted (so, in case of
LCS services, the SCH is not sent in the slave CU).
The operator is allowed to exclude time slots or logical channels from applying the
transmission diversity time delay.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The transmission diversity feature can be configured on a cell basis; it is assumed that
a switch between coverage mode (pair of CUs per TRX) and standard mode (single CU
per TRX) is performed very seldom. In this case it is acceptable that a mode switch
results in a traffic interruption of the cell.
To manage transmit diversity, the following attributes have been introduced in the
system:
a) the ETXDIVTS (enableTxDiversityTimeShift) attribute allows the operator to switch
from coverage mode (true) to standard mode (false) and vice versa. The coverage
mode has to be rejected by the BSC if:
antenna hopping or baseband hopping is enabled;
the related BTSE belongs to one of the following types: BTS1, BS82 or BS242;
the related BTSE software version does not support the feature;
b) the TXDIVTSECSPT (txDiversityExceptions) attribute allows the operator to
configure time slots or logical channels which are excluded from being sent via the
slave CU. The following attribute values are foreseen:

NONE (default value, diversity applied for all channels);

SCH: excludes synchronization channel (SCH);
BCCHTRXTS0: excludes time slot 0 of the BCCH TRX;
BCCHTRX: excludes all time slots of the BCCH TRX

Even if all time slots of the BCCH TRX are excluded from being sent from the slave CU,
this last CU must be equipped anyway. It is assumed that excluding all time slots of the
BCCH TRX is a very seldom scenario as the benefits of the feature are considerably
reduced.
c) the TXDIVTSPAR (txDiversityTimeShift) attribute is used to set the time shift
between the transmit signals of the master and the slave CUs. The time shift is specified on symbol base in the range between 5+5 symbols in steps of 0,25 symbols.

A modification of the attribute value would cause a traffic interruption on all TRX of the
BTS. In order to avoid a traffic interruption by mistake, the modification is rejected by
the BSC if the BTS object is not locked.

Besides, when a BTSE must be used in coverage mode, the following rules have to be
taken into account:

each cell must have an even number of CUs consisting of CU pairs;

a CU pair always consists of a CU:n and a CU:(n+1) with n that belongs to the
following set: {0,2,4,6,8,10}. CU:n is the master CU, while CU:(n+1) 2 is the slave
CU;

CU:n and CU:(n+1) shall be homogeneous, i.e. they must be of the same type
(GSM, EDGE, High Power CU) and must support the same frequency band and
same output power;

CU:n and CU:(n+1) should be wired to different antennas of the same cell otherwise
the combining loss would nullify the additional gain of the coverage mode;

if a BTSE is operated in coverage mode the RX inputs of the slave CUs have to be
wired too, even if they are not used in this mode. Otherwise a switch to standard
mode would not be possible without BTSE local intervention.

A30808-X3247-L210-3-7619

547

OMN:BSC

Operation
Base Station Controller

Another thing to be considered regards the Online RF loopback measurements (see

"3.147 Management of Online RF Loop Back"). In fact Online RF Loopback measurements are not suited for detecting a failure in the TX path, which affects a slave or
master CU as long as the related CU of the pair is still working. In coverage mode, the
gain of 2 or 3 dB is far below the minimal threshold of the Online RF Loopback failure
detection. Nevertheless the fix gain should be considered in the path loss calculation if
the coverage mode is enabled.

Online RF Loopback measurements are only performed in the master CU.

Prerequisites
Antenna hopping and baseband hopping, if enabled, must be disabled.
The involved BTSE must not belong to one of the following types: BTS1, BS82 or BS242.
The BTSE software version must support the feature.
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".

Choose the operation you want to execute

Would you like to enable the transmit diversity (switching from standard
mode to coverage mode)?

h ... 7

Would you like to disable the transmit diversity (switching from coverage
mode to standard mode)?

h ... 2

Lock the BTS

Lock the BTS using the LOCK BTS command, following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

LOCK BTS

Result: the involved BTS is locked.

Disable transmit diversity

Execute the SET BTS command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS
and set to FALSE the ETXDIVTS parameter.

Result: the transmit diversity is disabled.

548

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Unlock the BTS

Unlock the BTS using the UNLOCK BTS command, following the next sequence
of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

UNLOCK BTS

Result: the involved BTS is unlocked.

Create additional TRXs

i ..."3.57 Addition

Create additional transceivers according to the number of newly available CUs

of a TRX"

Result: the TRXs are created.

Create additional channels

i ..."3.64 Addition

Create additional channels according to the number of newly available TRXs

of a Radio
Channel"

h ... END

Result: the channels are created.

Lock the BTS

Lock the BTS using the LOCK BTS command, following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

LOCK BTS

Result: the involved BTS is locked.

Preliminary Consideration
Do you want to configure either the Diversity Exceptions parameter or the Diversity Time Shift one?
Y

h ... 9
N h ... 10

Set parameters

Execute the SET BTS command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS
and set either the TXDIVTSEXCPT parameter or the TXDIVTSPAR one
according to your needs.

Result: the value of parameters is changed.

A30808-X3247-L210-3-7619

549

OMN:BSC

10

Operation
Base Station Controller

Remove the TRXs

i...."3.62 Deletion

Delete transceivers that are no longer needed.

of a TRX"

Result: the TRXs are deleted.

11

Enable transmit diversity

Execute the SET BTS command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SET BTS
and set to TRUE the ETXDIVTS parameter.

Result: the transmit diversity is enabled.

12

Unlock the BTS

Unlock the BTS using the UNLOCK BTS command, following the next sequence
of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

UNLOCK BTS

Result: the involved BTS is unlocked.

END

550

A30808-X3247-L210-3-7619

Operation
Base Station Controller

A30808-X3247-L210-3-7619

OMN:BSC

551

OMN:BSC

Operation
Base Station Controller

3.116

Management of Four Branch Receive Diversity/Switched

Beam Functionality
Introduction
The Four Branch Receive Diversity EDGE Carrier Unit (ECU4R) is a EDGE carrier unit
with the full support of MCS-1 to MCS-9 modulation and coding schemes in both up-link
and down-link directions. The ECU4R is characterized by four receive inputs and four
separate receive branches.

ECU4R is only available for the BTSplus equipment (BS240/BS241 and BS240XL).
There are two independent application fields for the ECU4R carrier unit:
1. Four Branches Receive Diversity for enhanced BTS receiver sensitivity.
The receiver sensitivity can be increased by using four branches receive diversity.
To enhance the sensitivity for both static and fading channels, a true maximum ration
combining of all four receive branches is supported giving an additional diversity
gain of up to 2.5 dB, when compared with 2-branches receive diversity.
The ECU4R in this application is connected to the antenna combining equipment
(DUAMCO) either directly or via DIAMCO modules. All receive inputs RX-a to RX-d
are fed from separate antennas.
After the analogue processing in four separate receive branches, the four received
signals are further processed in the digital domain in the SIPRO unit. The digital
signal processing includes equalization of the four receive branches and their
maximum ration combining.
The demodulated signal of the receiver is transmitted to core unit (COBA) via serial
SELIC link. The block diagram of the ECU4R is shown in Fig. 3.41.

Fig. 3.41

ECU4R Block Diagram (Four branch receive diversity mode)

The transmitter path is identical with the E-CU module. The ECU4R is mechanically
compatible with existing single-carrier CUs. Also the BTSplus bus interface is electrically identical to that of the existing CUs.
The receiver RF interface includes 4 inputs, and their usage and labeling is shown
the following table.

552

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Physical Receiver CU Labelling Usage in 2-branch

Path
mode
RX-a

Rx A/N

Rx N

RX-b

Rx B/D

Rx DIV

RX-c

Rx C/N1

(Not Used)

RX-d

Rx D/D1

(Not Used)

The feature Four Branches Receive Diversity is simply added in the system by
replacing traditional Carrier Units with ECU4R ones; than the four branches of the
ECU4R will work exploiting the receive diversity of four antennas.
Fig. 3.42 shows an example of configuration, where four ECU4R are connected to
two DUAMCO 2:2; each carrier units receives four signals from the four antennas
(one signal from each antenna).

Fig. 3.42

Example of Configuration Using the Four Branch Receive Diversity

Mode

2. Switched Beam Smart Antenna for network capacity enhancement.

The SWITCHED BEAM/SMART ANTENNA functionality, is not provided in BR7.0

release, and it will be available with all of its features in subsequent releases.
Together with a smart antenna system, the ECU4R detects the angle of the best
received signal and controls the transmit angle.
A dedicated algorithm of finding and tracing the best available receive path is used.
When transmitting, the ECU4R controls the subsector beam direction using the
information gained during reception. Beam direction control is done via SDUAMCO
interface.

A30808-X3247-L210-3-7619

553

OMN:BSC

Operation
Base Station Controller

The feature switched beam smart antenna can be enabled and managed by the
operator by means of parameter settings (see below).

It must be clear that the RX processing is a basic ECU4R functionality and is independent whether the feature switched beam is switched on or off by means of O&M.
The switching on/off of the switched beam feature has only impacts on the new switched
beam control algorithm, which is described in the following.

HANDLING OF 4 RX INPUTS PER ECU4R

In this paragraph it is described the RX processing of ECU4R carrier units (as it has
been said, the RX processing of ECU4R is valid independently from the fact that the
switched beam algorithm has been enabled or not by the operator).
It is mandatory for a ECU4R to behave in the network nearly like every other conventional E-CU.
The ECU4R has 4 RX inputs instead of 2 RX inputs (for normal RX diversity) of traditional carrier units. All 4 RX inputs are led to the baseband processing of the SIPRO
(see Fig. 3.41).
The SIPRO calculates the following measurement data for all 4 RX paths (bursts) in
parallel:

Timing Advance in the range [-4 : +4];

RXLEV;
Signal-to-noise/interference level S/(N+I).

These values are also passed to the switched beam control algorithm, if enabled by the
operator (see below).
According to four branches receive diversity feature, a Maximum Ratio Combining Algorithm for all 4 receive directions is supported.
Additionally, the spatial interference reduction is supported: the bursts of the two best
directions (referring to S/(N+I)) are fed into the two existing paths of the current RX
diversity combining. This is the adopted solution for Switch Beam applications.
Then, since both algorithms are implemented in the ECU4R, the switch between the
spatial interference reduction and the maximum ratio combining is done autonomously
by the carrier unit.

For Power Control and Handover algorithms, the output of the RX diversity combining
is used depending on which of the above mentioned algorithms is currently activated or
supported.
Four branches receive diversity and switched beam algorithms do not introduce any
change in both Power Control and Handover features.
The following measurement values are taken, and they do not introduce changes in the
algorithms of the current SBS implementation:

RXLEV:
for normal bursts, RXLEV is the maximum value of the 2 selected data streams
with highest S/(N+I), which are fed into the decoder (the best 2 of 4). That corresponds to the final receive path;
for idle measurements, RXLEV is derived as (linear) mean value of all four available RX paths to simulate a full-sector reception of the whole cell;

554

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

for access bursts, RXLEV is derived from the two combined RX paths (sumsignals), where the burst was detected (either sum-signal A, C or sum-signal
B,D).

Timing Advance:
the TA value for normal bursts is taken from the RX path with best S/(N+I);
the TA value for access bursts is derived from the combined RX paths, where the
burst was detected (either sum-signal A, C or sum-signal B,D).

SWITCHED BEAMS/SMART ANTENNAS

The SWITCHED BEAM/SMART ANTENNA functionality, is not provided in BR7.0

release, and it will be available with all of its features in subsequent releases.
Switched Beams allow the partitioning of a cell (e.g. a cell of 120 degrees belonging to
a 3 sector BTS configuration) in subsectors (e.g. 4 subsectors of 30 degrees each one).
The BSS detects the direction of the incoming RX signals from the mobiles, e.g. the RX
subsector with the best receive signal, and chooses appropriate TX subsectors for
transmission.
An additional full-sector TX antenna (also called TX broadcast antenna) allows to
radiate the whole cell in case of unreliable uplink measurements, in case of broadcast
channels (whole BCCH Frequency, CCCHs, SDCCHs and all signalling channels
related to packet switched services, such as PBCCH, PCCCHs,) or of course as fall
back solution (e.g. if a TX subsector antenna breaks down).
Switched Beams/Smart Antennas decrease the overall interference level in the network
and thus improve the C/I conditions in the network, which will increase its capacity
without requiring more frequency bandwidth. Installing a Switched Beam Solution e.g.
in an urban heavily loaded cell, will allow the insertion of additional Carrier Units not only
in the switched beam cell but also in neighboring cells.
The following features regarding switched beam functionality are described:
a) hardware for switched beam;
b) switched beam algorithm;
c) configuration of switched beam.
a) Hardware for switched beam
The switched beam/smart antenna implementation in the BS240 rack (described as
BS240SWB) requires HW modifications in:

the antenna subsystem and antenna feeder cables;

BTS rack; its upgrade includes the Switched-DUAMCO antenna combiner
(SDUAMCO), the ECU4R Carrier Unit and the associated rack-internal cabling.

Fig. 3.116.43 gives an overview of modifications within the base station system.

A30808-X3247-L210-3-7619

555

OMN:BSC

Operation
Base Station Controller

Fig. 3.116.43BS240 Configuration for Smart Antenna Operation

The antenna subsystem is physically made by two antenna modules, which consist of a
cross polarized subsector antenna array (antenna diversity) and a full sector antenna.
The sector antenna covers the standard sector angle of 120. Subsector antennas
divide the standard sector angle into four subsectors. The subsector antenna beam
forming is achieved by a phase-controlled signal, fed via the 4x4 Butler Matrix. Adaptive
maximum ratio combining in the RX direction allows continuous antenna beam tracing
for signal reception.
The multi-beam antenna subsystem requires antenna cable upgrade. In addition to the
standard antenna cable pair (Sector and Sector Div), four additional antenna cable pairs
(A, A Div, ...., D, D Div) are required for subsector antennas.
All antenna feeder cables are terminated in the pair of SDUAMCO combiners of the
BS240 rack. The BS240 rack and the backplane do not need any modifications for smart
antenna operation. But besides smart antennas, to configure switched beam functionary, the following two hardware equipment must be installed in the BS240SWB rack
(one BS240SWB rack serves one cell):

556

SDUAMCO: two SDUAMCOs are required for the smart antenna operation in the BS
240SWB (see Fig. 3.116.43). The combiner pair performs a time variant switching

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

of subsector antennas in the transmit direction according to the estimated user position within the served cell. The antenna switching is controlled by Carrier Units via
dedicated control interface.
Though SDUAMCOs are physically identical, one has to be configured for delivering
the output signals A and C, while the other for delivering the output signals B and D.
For receive signal exchange SDUAMCOs are connected via diversity crosslinks.
As it has been said, the receive signal from subsector antennas is fed to SDUAMCOs. In the RX direction, the SDUAMCO performs periodical switching between
main antenna beams (A, B, C, D) and diversity antenna beams (Adiv, Bdiv, Cdiv,
Ddiv). The switching is executed after every N xTDMA slot period (N programmable
via O&M in steps 1, 2, 4, 8) to get the diversity gain for various user. The switching
is realized in the RX switches (RXSW) and is controlled with RX diversity switch
signal provided by the CUs.
The RX signal outputs at SDUAMCO are interleaved (A and C on the left
SDUAMCO, and B and D on the right one). A better cell coverage is reached on that
way in the case of failure of one SDUAMCO. The Rx signal output includes a signal
splitter (MUCO) to enable the connection of 8 CUs to a single SDUAMCO.
In the TX direction, the basic function of the SDUAMCO is the combining of the TX
signal from carrier units. The combining is a part of the functionality of the TX switch
block. Additionally to the simple combining, each transmit signal is switched either
to the Sector Antenna beam or to Subsector Antenna beams A...D. The switching is
TDMA slot-wise and is released in the TX switches (TXSW). Each Carrier Unit
controls the switching of its own TX via a dedicated control interface. The
SDUAMCO has 4 TX inputs.

A30808-X3247-L210-3-7619

ECU4R: the ECU4R carrier unit allows to implement smart antenna operation
(see Fig. 3.44).
The four receivers of the ECU4R process the signal of four antenna beams (A...D).
The two best signals are used for the maximum ratio combining with a weighting
factor proportional to their quality. The gained signal is further processed in the
SIPRO unit.
There are no modifications required in the signal transmit path for the smart antenna
operation.
The signal comparison of receivers 1-4 is used for the best antenna beam angle estimation for a given user. A direction information will be assigned to each received
user burst. The direction information is based on the mid-amble quality comparison
and the weighting factor. The value gained from each burst is weighted to suppress
effects like noise and multi-path propagation. Also longer signal loss (e.g. DTX)
leads to loss of direction information. If there is a valid direction information for a
given user, this information is added to transmit bursts of the given user, processed
by the corresponding CU. This information is broadcast, together with the burst to
be transmitted, via the SELIC link.
The CU, transmitting the user burst at its frequency, sends the antenna beam control
information via CU control link to the SDUAMCO.

557

OMN:BSC

Operation
Base Station Controller

Fig. 3.44

Carrier Unit Extensions for Smart Antenna Operation

b) Software for switched beam

The switched beam control algorithm can be enabled/disabled by means of O&M
commands on cell basis (see below about Configuration parameters).
As soon as the BTS receives a channel_activation command for bringing up a GSM
traffic channel (either fullrate or halfrate TCH) the algorithm for this air interface timeslot
starts. The algorithm for this air interface timeslot ends as soon as channel_release is
received.
The RX data per incoming burst for all 4 receive paths shall be transferred to the switch
beam control algorithm. The algorithm consists of two components (see Fig. 3.116.45):

558

a measurement preprocessing unit for averaging the incoming (one SACCH period
delayed) data;
a separate decision unit, which determines the appropriate TX subsector antenna or
the TX broadcast antenna.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig. 3.116.45Switched Beam Control inside ECU4R

The following TX directions are supported:

the Full-Sector (or Broadcast) antenna;

subsectors A, B, C and D.

For each RX path (RXi) the measurement preprocessing unit consists of 2 parts:
1. the first averaging unit calculates the mean RXLEV/RSSI and/or S/(N+I) values depending on which performs better in development trials - over full SACCH periods
(time interval 480ms). For each path an average value is get:
RXi-mean = sum( RX-levels of 104 bursts) / 100 with i = 1,...,4;

The 4 idle frames (bursts in case of FR used by the MS for neighboring cell
measurements) do not contribute to RXi-mean and could also be omitted,
thus achieving a division factor of 100 instead of 104.

2. the second averaging unit is a running average filter with forgetting factor "a" acting
on the RXi-mean values every 480ms; the result is given by:
RXi-run-avg-new = (1 - a) * RXi-run-avg old + a * RXi-mean with i = 1,...,4
For a => 0 the behavior of the filter is dominated by the already stored values and the
dynamics of RXi-run-avg-new gets rather slow.
For a => 1 RXi-run-avg-new will be dominated by the last few measurement values only.
The forgetting factor "a" can be set by the operator.
Halfrate channels have a double number of averaging units and measurement filters per
air interface timeslot (i = 1,...,8): the first 4 for HR0 and the second 4 for HR1. The
measurement preprocessing unit has to collect and distribute the incoming data for both
HR channels due to the frame numbers of the bursts, such that each averaging unit gets
only half of the data per SACCH period. As consequence also the division factor in the
RXi-mean formula above is reduced from 104/100 to 52.

A30808-X3247-L210-3-7619

559

OMN:BSC

Operation
Base Station Controller

Depending on timer constraints (i.e. Tstart, Tpenalty, etc., see below) and on the RXirun-avg value, for each receive path RXi, the decision unit decides, according to some
rules, the appropriate TX direction for downlink bursts of the channel. The decision is
done at the end of each SACCH period (1 period lasts 480ms) and is valid for the next
complete SACCH period.

The measurement preprocessing is independent from the decision unit. Hence if it is

mentioned in the following that the decision algorithm shall "wait" for a certain time
period, the measurement preprocessing shall still calculate the RX averaging values
during this time using the continuously incoming receive data. The decision unit then
always takes the latest values for the decision making process.
The calculated TX direction coming out of the decision unit is inserted together with
ARFCN and CU-identifier in the header of the CC-Link data frames, and then submitted
to the appropriate CU (or to another CU, if the feature Antenna Hopping is enabled, see
3.114). On the destination CU the TX direction information is routed to a connector at
the TX frontend of the CU, to control the TX antennas (subsector or broadcast) by
means of the Switched DUCOMs.
The ECU4R counts on SACCH time basis the utilization of subsector antennas, the
broadcast antenna and the total channel utilization (exclusive BCCH carrier). After each
decision step the algorithm also stores the current antenna decision for the SACCH
period for each call, which is an additional input parameter for the next decision step.
The last 20 decisions are stored (about 10 seconds).
The switched beam algorithm of the ECU4R is composed by the following rules:

RULE0: the broadcast antenna is used until a valid received signal is detected on
any of the four RX input ports. A valid received signal is detected for an input port
when:
RXi-mean > RXthreshold.
When this condition is reached, the START_TIMER is set to zero (T=0).

RULE1: the broadcast antenna is used until the START_TIMER reaches the Tstart
value.

RULE2:
If no valid uplink data is received for more than Tno-rec-signal seconds, because
of RXi-mean < RXthreshold at all 4 receiver paths, then the algorithm uses the
broadcast antenna for the next SACCH period and an additional
PENALTY_TIMER (with duration time = Tpenalty) is started to wait for the next
decision making. This is to avoid too many switches between broadcast and
subsector antennas.
The starting time of the NO_REC_SIGNAL timer still remains the same, such that
in the next loop the algorithm enters the complete PENALTY period again, if no
receive signal has been received in the meanwhile.
In case of a valid received signal on any of the four RX ports, NO_REC_SIGNAL
timer is reset.

560

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

RULE3: if one receive path is better than the 3 others by RX_MARGIN dB, then a
switch to the best TX subsector antenna for one SACCH period is executed. The
best antenna direction is stored.

RULE4:
If the best 2 receive paths are adjacent each other and the best of them is better
than the worst 2 receive paths by RX_MARGIN dB, and better than the 2nd best
direction by more or equal than RX_DELTA dB, then a switch to the best TX
subsector antenna for one SACCH period is executed. The best antenna direction
is stored.
If both adjacent best directions are nearly equal (difference < RX_DELTA dB) and
better than the worst 2 receive paths by RX_MARGIN dB, then both directions are
stored and the system starts toggling between both best directions on burst basis
from connection point of view (1 frame FR or 2 frames HR) for the next SACCH
period.

RULE5:
If the currently 2 best RX paths are not adjacent each other, but the best direction
is better than RX_MARGIN dB than the worst 2 directions and better than the 2nd
best direction by more or equal than RX_DELTA dB, and the currently best
subsector is among the selected subsectors of the last 5 SACCH periods then the
algorithm uses the present best direction and store this direction.
If both not adjacent best directions are nearly equal (difference < RX_DELTA dB)
and better than the worst 2 receive paths by RX_MARGIN dB and at least one of
the 2 best subsectors is among the selected subsectors of the last 5 SACCH
periods, then the system stores both directions and starts toggling between both
best directions on burst basis from connection point of view (1 frame FR or 2
frames HR) for the next SACCH period.

Default Rule: as a general rule, the stem uses the broadcast antenna on the next
SACCH period, and starts a PENALTY_TIMER with Tpenalty duration for waiting
additional time up to the next decision making. This is done to avoid too many
switches between broadcast and subsector antennas.

Fig. 3.116.46 shows the behavior of the switched beam algorithm.

A30808-X3247-L210-3-7619

561

OMN:BSC

Operation
Base Station Controller

Fig. 3.116.46Switched Beam Control Algorithm

c) Configuration of Switched beam
The feature Smart Antenna is provided for the BTSplus mainline family BS240, BS241
and BS240XL. Other types of BTSE equipment (eMicro, Pico, BS40/41, BS240XS,
BTS1 family) are definitely not supported.
Fig. 3.116.47 shows an example of configuration with a switched beam cell.

562

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Fig. 3.116.47Configuration with a Switched Beam Cell

The following configuration rules must be followed:

a mix of switched beam cells and not switched beam cells within one rack (base or
extension) is not allowed;

A cell working with switched beam equipment can not be combined with Tx Diversity
Time Shift feature (see "3.115 Management of Transmission Diversity with Time
Delay") or Extended Cell Configuration. This is not relevant for the customer
because switched beam is used in urban areas for enhancing network capacity
whereas the other features are intended for low populated areas in order to reach a
higher coverage;

a mix of switched beam capable carrier units (ECU4R) and other carrier unit types
within one switched beam rack is not allowed, i.e. a mix of SDUAMCOs and other
combining equipment (DUAMCO, FICOM) within one switched beam rack is not
possible. Only switched beam capable carrier units must be connected to a
SDUAMCO. Illegal carrier units will not be put into operation;

a BTSE serves maximal 3 switched beam cells (2 cells in case of only BS240XL
racks are used);

one switched beam cell requires 2 SDUAMCOs, each one connected to 4 carrier
units at most;

a mix of different frequency bands, within a rack serving a switched beam cell, is not
allowed;

a switched beam cell does not support TMAs. TMA related objects cannot be
created within a switched beam rack.

As it has been described to implement switched beam functionality, two kinds of boards
are needed:

A30808-X3247-L210-3-7619

563

OMN:BSC

Operation
Base Station Controller

a) SDUAMCO: for each cell a pair of SDUAMCOs (2 polarizations, normal/diversity

path) is necessary. Each SDUAMCO has 4 TX inputs and 2 * 8 RX outputs. The input
signals are combined and switched to the according subsector antenna and/or to the
sector antenna. The output signals are interleaved (subsector A and C on the first,
subsector B and D on the second SDUAMCO). In RX direction the SDUAMCO
performs a periodical switching between the normal and the diversity antennas by
means of a RX-switch. The switching period is controlled by the carrier units.
The SDUAMCO is a replaceable unit, which is represented by the following units:
SDUSEC (Switched DUAMCO SECtor Antenna) represents the sector antenna
as well as the antenna supervision unit ASU (VSWR detection); there is one
SDUSEC object for the sector antenna.
SDUSUBSEC (Switched DUAMCO SUBSECtor Antenna) represents one
subsector antenna as well as the antenna supervision unit (test loop/phase detection); there is one SDUSUBSEC object for each of the 4 subsector antennas.
SDULNA (Switched DUAMCO Low Noise Amplifier) represents one low noise
amplifier including the failure supervision; there is one object for each of the 4 RX
amplifiers.
SDUTXSW (Switched DUAMCO TX SWitch) represents one TX switch including
the supervision of the related control bus; there is one object for each of the
maximal 4 connected ECU4Rs.
b) ECU4R: a switched beam capable EDGE carrier unit requires 4 receive inputs in
order to detect the direction of the received signals. It generates additional output
signals to control the transmit direction and the RX-switch of the SDUAMCOs. These
requirements are met by the ECU4R, that is depicted by the CU object.
The switched beam functionality of the BTS is represented by the SWIBEAM Functional
Object in the BSC.
As it has been described, it is possible to switch off/on the complete Switched Beams/
Smart Antennas feature for circuit switched services by means of O&M command on cell
basis. To enable/disable the feature, the ENSWBCS parameter of the SWIBEAM object
is provided. The feature is enabled on a cell basis.
If the feature is disabled, the CU still takes advantage of the different receive subsector
antennas (according to Four Branches Receive Diversity functionality). In transmit direction, however, all bursts are submitted via the broadcast/full-sector antenna.
In case of switching on/off the Switch Beam feature during operation neither the CU
status nor the calls currently running on the CU are affected. The only impact is the
potential enabling/disabling of the subsector antennas A, B, C and D in downlink direction.
Besides, the following parameters can be set to manage the switched beam algorithm:

564

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Parameter

Meaning

RXSRS

(rxSwitchRequiredSetting). If set to periodical the RX-Switch is

toggled with the frequency defined by the attribute rxToggleFrequency.
Otherwise the RX-Switch in both SDUAMCOs is statically
switched to the required direction.The BTSE software has to
synchronize the setting between all ECU4Rs of a cell. The
SDUAMCO automatically selects the signal from the first
connected ECU4R. Therefore in case of a change of the
attribute, all ECU4Rs of the related cell must be informed about
the new value.
RXTO
(rxToggleFrequency) Determines whether the RX-Switch is
toggled after 1, 2, 4 or 8 TDMA frames. The attribute is only relevant if the attribute rxSwitchRequiredSetting is set to periodical.
RUNAVGFCTSUBS (runningAverageFactor): it is the a factor of the running
average filter.
RXTH
(RXthreshold) Only RX levels above this threshold are considered for calculating the TX direction.
RXMSUBS
(RXMargin) Quality threshold for best subsector selection.
RXDLTSUBS
(RXDelta) A switch to a different subsector antenna is only
performed if the receive level of the new subsector is at least
better than rxDelta.
STATSUBS
(startTimer) The subsector antennas are not used until this timer
elapses.
NORTSUBS
(noReceiveTimer) The timer is started and incremented if no
receive signal is detected. If the timer elapses the sector
antenna is used.
PTSUBS
(penaltyTimer) The timer is started and incremented after a
switch to the sector antenna. A switch back is not performed
before the timer elapses in order to avoid too many switches.
The Switched Beam Operating State is indicated via three attributes within the
GETINFO BTS report:

switchedBeamCapability: this attribute reflects the capability of the BTSE hardware

and software. The following values shall be foreseen:
unknown (initial value for BTS types which may support switched beams);
none (the BTSE hardware and/or software does not support switched beams).
4_beams (the BTSE hardware and software supports 4 switched beams).

switchedBeamServiceState: the attribute indicates the current state of the switched

beam functionality. The following values shall be foreseen:
NULL (Initial value if BTSE is not aligned, or default value if the BTS type does
not support switched beams).
outOfService (initial value; the switched beam functionality is disabled by the
operator, switched beams are not supported or the BTSE is not aligned).
inService (the switched beam functionality is in full operation).

A30808-X3247-L210-3-7619

565

OMN:BSC

Operation
Base Station Controller

degradedService (the switched beam functionality is degraded, e.g. because the

sector antenna has to be used partly instead of the subsector antenna(s) due to
failures).
disabledService (the switched beam functionality was disabled by the BTSE due
to failures. The subsector antennas are no longer used in Tx direction).

rxSwitchCurrentSetting: the attribute indicates the real state of the RX Switch. The
state may deviate from the required setting of the RX Switch (attribute rxSwitchRequiredSetting) due to failures. If the RX-Switch setting has to be changed by the
BTSE software due to failures, the BTSE has to synchronise the setting between all
ECU4Rs. Calls must not be affected. If the failure is repaired the original setting has
to be restored by the BTSE software. The following values shall be foreseen:
NULL (Initial value if BTSE is not aligned or default value if the BTS type does not
support switched beams).
periodical (The RX-Switch is toggled every N TDMA frames);
normal (Due to failures the BTSE has switched the RX-Switch to normal).
diversity (Due to failures the BTSE has switched the RX-Switch to diversity).

OTHER CONSIDERATIONS REGARDING THE SWITCHED BEAM FUNCTIONALITY

In BTS transmit direction, i.e. in the downlink, the switched beam algorithm switches
between "sub-sector antenna" and "full-sector antenna", and between the sub-sectors
of the same cell. This switching is not a handover.
The antenna gain of the sub-sector antenna is higher (e.g. 4 dB) than the gain of the fullsector antenna. The attenuation of the sub-sector antenna cable may be different from
the attenuation of the full-sector antenna cable (e.g. 1 dB, because of different cable
types/diameters/lengths).
In BTS transmit direction (downlink), the following additional BTS function, which has
the aim to approximately compensate the different antenna gains and the different cable
attenuations, is required:
a) During sub-sector antenna operation, the BTS uses the TX power
"TX_PWR_SUBSECTOR" which differs by an offset "TX_PWR_OFFSET" from the
"normal" TX power "TX_PWR_FULLSECTOR" which is used during full-sector
antenna operation;
b) During full-sector antenna operation, the BTS uses the "normal" TX power (named
"TX_PWR_FULLSECTOR" in the below formula ); i.e. the BTS uses the same TX
power as was used before enabling feature "Switched Beam".
So the following equation represents the power used when transmitting with the
subsector antenna, with respect to the power transmitted with the broadcast antenna:
TX_PWR_SUBSECTOR = TX_PWR_FULLSECTOR - TX_PWR_OFFSET
with the definition:
TX_PWR_OFFSET = txGainCompensation_i + (txLevAdjust - txLevAdjustSubsector)

For each subsector antenna a different TX_PWR_OFFSET value might be used.

where:

566

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

txGainCompensation_i: this parameter describes the difference in antenna gain

between each "sub-sector antenna" and the "full-sector antenna"; the operator can
set this value by the GCOMPSUBSEC parameter of the SDUSUBSEC object
(BTSEP containment tree);
txLevAdjust: this parameter is already implemented; before the introduction of the
feature "Switched Beam", this parameter was used to describe the TX path loss
(attenuation due to antenna cable and duplexer/combiner) between the "normal CU"
and the "normal antenna" which is named "full-sector antenna" . In case of a
switched beam cell, this parameter is still used for the "full-sector antenna"; i.e. it is
used to describe the TX path loss (attenuation due to antenna cable and
duplexer/combiner) between the "Switched Beam CU", called "E-CU 4R", and the
"full-sector antenna"; the operator can set this value by the TXLEVADJ parameter of
the CU object (BTSEP containment tree);
txLevAdjustSubsector: this parameter describes the TX path loss (attenuation due
to antenna cable and duplexer/combiner) between the "Switched Beam CU", called
"E-CU 4R", and the "sub-sector antenna"; the operator can set this value by the
TXLEVADJSUBS parameter of the CU object (BTSEP containment tree).

If the Online RF loopback feature is enabled (see 3.147), the path loss evaluation algorithm of the Online RF loopback feature considers the gainCompensationSubsec
attribute (see above) when using full sector, and the txLevAdjustSubsectors one when
using sub sector in TX direction at uplink/downlink path loss calulation.
The level correction factor for the uplink (attribute rxLevAdjustSubsectors of the CU
object) is already compensated by the BTS.
Prerequisites
The involved BTSE must belong to one of the following types: BS240, BS241 or
BS240XL.
To enable the switched beam functionality, the Tx Diversity Time Shift one (see 3.115)
must be disabled.
The BTSE software version must support the feature.
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".

Choose the operation you want to execute

Would you like to enable Four Branch Receive Diversity?
Would you like to enable Switched Beam functionality for a cell?

h ... 2
h ... 3

Insert ECU4R carrier units in the BTSE rack

To enable Four Branch Receive Diversity change traditional carrier units with
ECU4R ones.
Result: Four Branch Receive Diversity is enabled.

A30808-X3247-L210-3-7619

h ... END

567

OMN:BSC

Operation
Base Station Controller

Preliminary Consideration

Y h ... 4
N h ... 5

Is the cell an extendend one?

Impossible to activate switched beam feature

h ... END

The switched beam functionality can not be enabled for an extended cell.

Insert both ECU4R carrier units and SDUAMCOs in the BTSE rack

To prepare the system for the switched beam functionality insert both ECU4R
carrier units and SDUAMCOs in the BTSE rack.

Enable switched beam functionality

To enable the functionality for a cell, execute the CREATE SWIBEAM command,
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

SWIBEAM ---> CREATE SWIBEAM
and set to TRUE the ENSWBSC parameter.
You can also set the following parameters according to your needs:
RXSRS
RXTO
RUNAVGFCTSUBS
RXTH
RXMSUBS
RXDLTSUBS
STATSUBS
NORTSUBS
PTSUBS

Result: the switched beam functionality is enabled in the cell.

END

568

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.117

OMN:BSC

Enabling the Emergency Setup 2 message for emergency

calls in GSM-R
Introduction
For GSM-R a new setup message, called Immediate Set-up 2 message, has been
implemented for emergency calls.
On the switching site this high priority feature is implemented within SR 10.
In the GSM-R BSS in addition to the usual Immediate Set-up message, the new Immediate Set-up 2 message is introduced: this new message type allows the mobile station
to include an additional information element, called OTDI (Originator To Dispatcher
Information).
A mobile station is allowed to send this new message only if the MSCR bit (MSC
release), in the Control Channel Description IE within the System Information 3
message, is set to 1, indicating that the MSC release is R99 onwards.
If the MSC release is R98 or lower, this bit is of course set to 0.
In GSM-R BSS, enabling the setup of emergency calls in conjunction with the OTDI
(Originator To Dispatcher Information) is a mandatory feature; without the implementation of this feature the interworking between the MSC and the BSS will not operate.
Since this new procedure is allowed only with release 99 or onwards MSC, in order to
inform the MS about MSC release the BSC must broadcast in System information 3 the
information about MSC release.
This information is provided by the SIMSCREL99 (systeminfomscrelease99) attribute of
the BSC object.
By setting this parameter to TRUE the new Immediate Set-up 2 message can be used
by the mobile station (in fact in this case it is supposed that the MSC release is REL99
or upper).
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".

Enable sending the Immediate Set-up message 2

To enable this feature, the user must enter the SET BSC command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then the user must set the SIMSCREL99 attribute to TRUE (it belongs to
BASICS group).
Result: the feature is enabled.

END

A30808-X3247-L210-3-7619

569

OMN:BSC

Operation
Base Station Controller

3.118

Enabling/Disabling GPRS Traffic Control Management

Introduction
This procedure describes two features which have been introduced in BR7.0 release in
order to allow a better management of available network resources for packet services
(both GPRS and EGPRS). They are:

GPRS Network Controlled Cell Reselection

GPRS Traffic Control Strategy

In the previous GPRS release BSS allocates PDCHs as long as there are available
resources in a given cell. This might lead to congestion, although traffic capacity might
be available in neighbouring cells.
Network Controlled Cell Reselection allows the network to redistribute MSs among cells,
in order to satisfy the maximum number of service requests.
Even though no handover functionality is foreseen for the GPRS bearer service, the
functionality of the Network Controlled Cell Reselection has the same scope of the SBS
feature Handover due to traffic reason (see PROC: Management of Handover for
Traffic).
Besides, the GPRS Traffic Control Strategy feature, based on Network Controlled Cell
Reselection feature and on appropriate traffic thresholds set in each cell, makes
possible to control the traffic distribution among cells belonging to the same PCU.
Network Controlled Cell Reselection
To enable the Network Controlled Cell Reselection feature the user must set at ENABLE
the NCRESELFLAG (ncReselectionFlag) parameter, belonging to the BSC object.
When the feature is enabled, the network can ask the mobile to transmit the carrier level
of adjacent cells through Packet Measurement Report. The mobile is provided with
specific parameters for measurement reporting and Network Controlled Cell
Reselection by either Packet System Info PSI5 (if PBCCH is present in the cell) or
System Info SI2 quater (if PBCCH is not present in the cell).
The optional field NC Measurement Parameters is used to broadcast the following
parameters: Network_Control_Order, NTWCREPPTR, NTWCREPPIDL and
NTWCNDRXP.
The Network_Control_Order is a two bits parameter (not settable by the user) which
controls the cell reselection methods:

00 (NC0): MS controlled cell reselection, no measurement report

01 (NC1): MS controlled cell reselection, MS sends measurement report
10 (NC2): Network Controlled Cell Reselection, MS sends measurement report
11: reserved for future use, interpreted as NC0 by MS.

NC1 value is not used for Network Controlled Cell Reselection.

As far as Network Controlled Cell Reselection is concerned, GPRS mobiles in packet
idle mode work in NC0 mode, whereas GPRS mobiles in packet transfer mode work in
NC2 mode.

570

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The broadcasted value is NC0, so none of the mobiles in packet idle mode transmits
Packet Measurement Report to BSS; at the beginning of a TBF (uplink or downlink) the
network transmits a PACKET MEASUREMENT ORDER message to the involved
mobile, containing the NC Measurement Parameters field with Network_Control_Order
set at NC2, so the addressed mobile in packet transfer mode begins to transmit Packet
Measurement Report to BSS.
NTWCREPPTR (networkControlReportPeriodTransfer) and NTWCREPPIDL
(networkControlReportPeriodIdle) parameters, belonging to PTPPKF object, define the
time period for transmission of Packet Measurement Report when MS is in packet
transfer mode and packet idle mode, respectively.
NTWCNDRXP (networkControlNonDRXPeriod) parameter, belonging to PTPPKF
object, indicates the minimum time the MS stays in non-DRX mode after a Packet
Measurement Report has been sent.
If needed conditions are verified (see below the description of Network Controlled Cell
Reselection algorithm), BSS may transfer MS to another cell by a PACKET CELL
CHANGE ORDER; this message contains the characteristics of the new cell that are
necessary to identify it and the Network Controlled measurement parameters valid for
the MS in the new cell.
The network also specifies whether MS has to immediately abort any TBF in progress
in the old cell or not by IMMEDIATE_REL parameter.
At the end of the TBF the network transmits another PACKET MEASUREMENT
ORDER message with Network_Control_Order set at NC0, so the addressed mobile no
longer transmits Packet Measurement Report to BSS when it enters packet idle mode.
NETWORK CONTROLLED CELL RESELECTION ALGORITHM
The Network Controlled Cell Reselection algorithm is based on Cell Reselection path
loss calculation.
The Cell Reselection algorithm is based on GPRS Reselection and on parameters C1
and C32 (for more details on GPRS Reselection see GPRS User Manual).
In the following the latter case is described. For this case the user is provided with a set
of specific parameters, which allow to manage the feature in a more flexible way.
Every MS, in ready state, returns the Packet Measurement Report message to the
network, according to NTWCREPPTR parameter setting. The network calculates the
value of C1 and C32 for the serving cell and the non-serving cells every time the MS
returns the Received level average for Packet (RLA_P). The network then checks
whether the re-selection has to be performed, that is the following conditions are
satisfied:
1. The path loss criterion (C1) for current serving cell falls below a threshold, defined
by NCC1TH parameter; when a mobile has its C1 value under this threshold, it is
moved to an adjacent suitable cell. The NCC1TH parameter belongs to the PTPPKF
object.
2. A non-serving suitable cell is evaluated to be better than the serving cell. Suitable
cells are those cells for which C1 is above a threshold, defined by the user.
The NCC1THADJC (ncC1ThresholdAdjacent) parameter, belonging to ADJC
object, represents this threshold. The best cell is the cell with the highest value of
C32 and also C1 > NCC1THADJC. If hierarchical cells are present then C32 is the
highest value among those cells that have the highest Priority Class among those

A30808-X3247-L210-3-7619

571

OMN:BSC

Operation
Base Station Controller

cells that fulfil the criterion C31 >= 0, or all cells, if no cells fulfil the criterion
C31 >= 0. If there are no hierarchical cells, only C32 is used and the highest value
is taken.Moreover, when calculating C32,also these additional attributes of ADJC
object may be considered: NCGRESOFF (ncGprsReselectOffset), NCGTEMPOFF
(ncGprsTemporaryOffset), NCGPENTIME (ncGprsPenaltyTime).These parameters
allow to create a further ranking among adjacent cells.
3. When evaluating the best cell, if the NCSARA (ncSameRoutingArea) parameter,
belonging to the PTPPKF object, is set at TRUE then the adjacent cell is searched
before among the cells belonging to same routing area of serving cell. If NCSARA
is set at FALSE then the adjacent cells of the same routing area have no priority
compared to the adjacent cells of other routing areas.
When NCSARA is set at FALSE an hysteresis value is subtracted from the C32
value for the neighbour cells. The hysteresis value can be set by the user via the
NCRARESH (ncRaReselectHysteresis) parameter, belonging to the PTPPKF
object. NCRARESH must be set at DB00 (default value) when NCSARA is set at
TRUE.
Moreover, in order to prevent ping_pong effect due to questionable MS behaviour
during Network Controlled Cell Reselection, the TRFPSCTRL parameter in the
object PTPPKF is used to avoid too frequent cell reselection of the same adjacent
cell.To this end, BSC doesnt order to MS to move again into same adjacent target
cell where a NCCR failed,in spite of good radio link scenario ,until timer TRFPSCTRL is expired and the following condition is satisfyied:.
STGTTLLIINF > TRFPSCTRL

If the STGTTLLIINF parameter set to NULL, this means that no TBF temporary data is
stored and therefore the ping pong NCCR cannot be avoided.
Traffic Control Strategy
To enable the Traffic Control Strategy feature the user must set at TRUE the TRFPS
(trafficPs) parameter, belonging to the BSC object.
The feature can be enabled only if Network Controlled Cell Reselection feature is
already enabled.
When TRFPS is set at TRUE the traffic control algorithm is applied. The feature goal is
to spread the cell traffic on more than one cell, that is to move MSs inside an high traffic
cell towards available resources in neighbouring cells.

Traffic control algorithm is applied to cells belonging to the same PCU that are in Vertical
Allocation state.
Traffic control algorithm performs an evaluation of the radio resource occupation into
each cell, based on the number of channels configured and in service available for
GPRS and the type of strategy set by the operator (for more details see
PROC: Management of Radio Resources).
Every times a new GPRS/EGPRS packet switched data call is established it is checked
if the radio resource occupation has reached or exceeded a threshold, defined by the
CRESELTRHSOUT
(cellReselectionThresholdOutput) parameter, belonging to PTPPKF object.

572

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

In positive case, the algorithm looks for MSs candidates to be forced to a cell
reselection. The candidate MSs are the results of the Network Controlled Cell
Reselection algorithm. The number of MSs to be forced in reselection is determined
taking as many MSs as the radio resources that have to be released in order to put the
traffic load under the threshold defined by the NCTRFPSCTH parameter.
The network sends to each concerned MS a PACKET CELL CHANGE ORDER
message with the indication of the new cell where the MS has to perform the Cell
Reselection.
The algorithm also looks for a possible candidate cell to move a MS into. A cell can be
a candidate for this procedure only if it is adjacent to the origin cell (i.e. the relevant
ADJC object already exists), it is not barred, it supports the GPRS service and its
resource occupation is under a threshold. This threshold can be set by the user by
means of the CRESELTRSHINP (cellReselectionThresholdInput) parameter, belonging
to PTPPKF object.
Prerequisites
The user must have the visibility level number set at "2".
The network element must be in phase 2.

Preliminary Consideration
Do you want to enable the Network Controlled Cell Reselection feature?
Do you want to enable the Traffic Control Strategy feature?

h ... 2
h ... 5

Enable Network Controlled Cell Reselection

To enable the Network Controlled Cell Reselection, enter the SET BSC
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then set the NCRESELFLAG attribute (BASICS group) at TRUE.

Result: the Network Controlled Cell Reselection is Enabled.

Set ADJC

To set the parameters related to Network Controlled Cell Reselection, enter the
SET ADJC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS ---> ADJC--> SET ADJC

Then assign the chosen value to the attributes:

NCC1THADJC,NCGRESOFF,NCGTEMPOFF,NCGPENTIME
Result: the parameters related to Network Controlled Cell Reselection are set.

A30808-X3247-L210-3-7619

573

OMN:BSC

Operation
Base Station Controller

Set PTPPKF

To set the parameters related to Network Controlled Cell Reselection, enter the
SET PTPPKF command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF

Then assign the chosen value to the NTWCREPPTR, NTWCREPPIDL,

NTWCNDRXP, TRFPSCTRL attributes (they belong to BASICS group).
Result: the parameters related to Network Controlled Cell Reselection are set.

Consideration

Y h ... 6
N i.... 2

Is the Network Controlled Cell Reselection enabled?

h ... END

Enable Traffic Control Strategy

To enable the Traffic Control Strategy, enter the SET BSC command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

Then set the TRFPS attribute (BASICS group) at TRUE.

Result: the Traffic Control Strategy is Enabled.

Set PTPPKF

To set the parameters related to Traffic Control Strategy, enter the SET PTPPKF
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSM ---> BTS --->

PTPPKF ---> SET PTPPKF

and assign the chosen value to the CRESELTRSHINP, CRESELTRHSOUT and

NCTRFPSCTH attributes (they belong to BASICS group).
Result: the parameters related to Traffic Control Strategy are set.

h ... END

END

574

A30808-X3247-L210-3-7619

Operation
Base Station Controller

A30808-X3247-L210-3-7619

OMN:BSC

575

OMN:BSC

Operation
Base Station Controller

3.119

Addition/Deletion of a TD-SCDMA Control Unit

Introduction
The TDCU (TD-SCDMA Control Unit) is the functional object which provides the
TD-SCDMA circuit switched service in SBS.
The procedure of adding a TDCU in SBS is accomplished in two steps:
1. Creation of a PPXT functional object;
2. Creation of a TDCU functional object.

Remember that TD-SCDMA services can be configured only if the high capacity BSC
with new rack is used and if it is equipped with both MPCCV8 and TDPCV7 processor
boards.
The PPXT functional object represents the card that, loaded with appropriate SW, is
used for the provision of TD-SCDMA circuit switched service (see "1.4.3.1 High
Capacity BSC supporting TD-SCDMA Services"). PPXT is also responsible for
managing CCS7 channels and LAPD connections towards BTS equipments (BTSEC),
used to implement TD-SCDMA.
PPXT cards are equipped with N+1 cold redundancy mode. In order to handle the N+1
redundancy the TDCU functional object is introduced, which represents the TD-SCDMA
functionality supported by a single PPXT.
Unlike the PCUTD which, due to the load sharing redundancy, is statically associated to
the PPXP with the same instance (see "3.125 Addition/Deletion of a Packet Control Unit
for TD-SCDMA"), the N+1 cold redundancy requires a dynamic association between
PPXT and TDCU. Besides, the number of equipped PPXT is always different from the
TDCU number.
These two reasons make convenient to introduce the explicit creation of the PPXT also
and not only of the TDCU.
Since the minimum number of PPXT cards required to support TD-SCDMA circuit
switched service is 2, in a 1+1 cold redundancy scheme (see "1.4.3.1 High Capacity
BSC supporting TD-SCDMA Services"), it is not possible to create one TDCU until
at least 2 PPXTs are equipped.
Up to 6 PPXT object instances can be simultaneously created, among a set of 12
different instances. The physical number of PPXT changes between 0 and 11 and
defines indirectly the position of PPXT into the new rack.
The TDCU number represents the logical number of PPXT card that is active in that
moment and has a range between 0 and 4.
There is no static association between the physical number of PPXT and the TDCU
number: instance n of TDCU could depend hierarchically on instance m of PPXT with n
different from m.

576

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

For example, if the slots 2, 5 and 7 are free, it will be possible to create the PPXTs 2, 5
and 7 and the TDCUs 0 and 1. Similarly, it is possible that the TDCU 4 is associated with
PPXT 11 and then, after a fault of PPXT 11, with PPXT 9.

The creation of the instance x of PPXT is possible only if the slot x is free, and it blocks
the creation of the instance x of PCU or PCUTD (see also "3.125 Addition/Deletion of a
Packet Control Unit for TD-SCDMA" and "3.47 Addition of a Point-to-Point Packet
Function (GPRS/EGPRS)").
The creation of the instance x of PCU or PCUTD blocks the creation of the same
instance x of PPXT, but not of the instance x of TDCU, thanks to the dynamic
association PPXT-TDCU.
In order to delete a TDCU instance previously created, the user must first delete one of
the PPXT instances already equipped. Deleting a TDCU requires to delete all the
subordinate BTSMTD functional objects.
Prerequisites
The BSC must be an high capacity one (NTWCARD attribute of the BSC object set at
NTWSNAP_STLP).
The user must have the visibility level number set at "2".

Preliminary Consideration
Do you want to create a TDCU?
Do you want to delete a TDCU?

Precondition
Are there any free positions among the ones allowed by the expansion frame?

h ... 2
h ... 6
Y h ... 3
N h ... END

Create a PPXT

Create a PPXT by entering the CREATE PPXT command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BSCE ---> PPXT --->

CREATE PPXT

Result: Creation of a PPXT

After the creation of the PPXT, the administrative state is set at UNLOCK. The
UNLOCK command is NOT required to place this object in service.

Situation
Are there at least two PPXT instances already equipped?

A30808-X3247-L210-7619

Y h ... 5
N i ... 3

577

OMN:BSC

Operation
Base Station Controller

Create a TDCU

Create a TDCU by entering the CREATE TDCU command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TDCU ---> CREATE TDCU

Result: Creation of a TDCU

After the creation of the TDCU, the administrative state is set at UNLOCK. The
UNLOCK command is NOT required to place this object in service.

h ... END

Delete a PPXT

Before deleting a TDCU delete one of the already equipped PPXTs by entering
the DELETE PPXT command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> PPXT ---> DELETE PPXT

Result: Deletion of a PPXT

Precondition
Are all the related BTSTD instances deleted?

Y h ... 8
N i...."3.121 Addition/D
eletion of a TDSCDMA Cell
(BTSTD)"

Delete a TDCU

Delete a TDCU by entering the DELETE TDCU command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TDCU ---> DELETE TDCU

Result: Deletion of a TDCU

END

578

A30808-X3247-L210-7619

Operation
Base Station Controller

3.120

OMN:BSC

Addition of a New TD-SCDMA Site Manager and of Related

LAPD Links
Introduction
The TD-SCDMA Site Manager is represented by the BTSMTD object. It contains a
BTSTD (i.e. a TD-SCDMA cell) and a set of TRXTDs.
A single BSC can support up to 364 BTSMTD, whereas the maximum number of
BTSMTDs for PPXT card is 122.
When creating a new TD-SCDMA site manager, the user must specify:
1. the BTSMTD absolute number (btsmtdn) inside the BSC. This number is included in
the range [0-363].
2. the Expected Software Version string (EXPSWV attribute) that has to match with the
version of the BTSE Sw load stored in the BSC disk.
3. the TEI parameter [0...63]: it contains the Terminal Endpoint Identifier used in the
layer2 addressing on the Abis-Interface for the logical O&M or Radio Signalling Link.
The association of the BTSMTD to a certain TDCU (see "3.119 Addition/Deletion of a
TD-SCDMA Control Unit") is performed when a new BTSMTD is created, according to
the following rules:

the operator can specify, by the TDCUN parameter, the TDCU number to which
associate the BTSMTD under creation;

it the user does not specify any TDCU, the system associates the BTSMTD to one
of the TDCUs following a distribution strategy.

The BTSMTD needs a logical LAPD connection on a signalling link on A-bis

Interface; this logical link is identified by the LPDLMTD object. Then the user, after
creating a BTSMTD, has to create the LPDLMTD object instance.
A BTSMTD can be connected to the BSC by means of at most four PCMB lines.
To connect the Site Manager to the BSC, the user must specify on which BTSEC port
the PCMB line is connected to. To reach this purpose, four attributes are defined (they
are valid for both PCM30 and PCM24 lines):

PCMCON0: it indicates the first PCM connection;

PCMCON1: it indicates the second PCM connection;

PCMCON2: it indicates the third PCM connection;

PCMCON3: it indicates the fourth PCM connection.

These attributes are composed of two fields:

a) pcmbNumber: it indicates which is the PCMB line (i.e. a PCMB instance previously
created, see "3.38 Addition of a PCMB Line") that is used for the connection;
b) portNumber: it indicates the value of the BTSC port to which the PCMB line is
connected to.
It is important to underline that the PORT_0 must always be used for the connection to
the BSC only, i.e. it can not be used as a crossconnection port.
The remaining even ports can be used for either the connection to the BSC or the
crosconnnection to other BTSCs. The odd ports can be used only for connections to
other BTSCs.

A30808-X3247-L210-3-7619

579

OMN:BSC

Operation
Base Station Controller

For each BTSMTD instance it is possible to configure more than one LPDLMTD object
instance.
In the hierarchy tree, the BTSMTD object is father of LPDLMTD object (see
"1.5.1 Notes on the CREATE commands"). In this way it is easier to introduce in the
LPDLMTD object the BTSMTD to which it refers to, and to make all the controls related
on the BTSE type, on the SW version, etc.
Up to eight LPDLMTD links for each BTSMTD can be created on different PCMB lines
that connect the BTSMTD to the BSC. For the same BTSC the LAPD links are either all
64 kbit/s or all 16 kbit/s, and either all satellite or all no satellite. So on creating a new
LPDLMTD instance the user must specify:
1. the name of LPDLMTD instance, i.e. the complete address of the new LPDLMTD to
be created; the address is composed of:
the BTSMTD absolute number (range 0...363) which the LPDLMTD belongs to;
the LPDLMTD relative number inside the BTSMTD domain (range 0...7)
2. the PCMB line and the timeslot number over which the LPDLMTD must be created
(ABISCH attribute)

Please remember that, for each configured LPDLMTD on the BSC side, you have to
configure the corresponding LPDLE object of the connected BTSEC equipment; if you
do not execute this operation, the Abis Alignment will fail.
Even if it is possible to configure up to eight LAPD timeslots for each BTSMTD:

only one LPDLMTD link is active on one LAPD timeslot at each time (this LPDLMTD
is in Providing Service state);

the remaining LPDLMTD links on the other LAPD timeslots will be in StandBy
state.

In case of failure of Providing Service LPDLMTD, the BSC will put this LAPD timeslot
in Fault state, and one of the other Standby LAPD timeslots is put in Providing
Service (To have more detailed information about LPDLMTD redundancy and
LPDLRTD management see "3.57 Addition of a TRX" procedure).
Using LAPD redundancy, the following considerations can be done:
1. if more than one PCMB line is used to connect the BSC to the BTSM, there must
be at least one LPDLMTD for each connected PCMB line (at lest one LPDLMTD
timeslot for each PCMB line); when configuring LPDLMTD links, it is reasonable
to follow this general rule:

Number of LPDLMTD links >= Number of PCMB lines

2. if there is only one PCM line connected to the BTSMTD, it is possible to have 2 (or
more) LAPD timeslots on the same line, due to signalling load reasons.
3. If Loop Configuration (configuration of L1CTS: Layer1 Control TS) and LAPD fault
recovery are used for the same BTSMTD, it is acceptable to put the restriction that
only one kind of redundancy will be provided for the same BTSMTD. The L1CTS is
no more necessary for fault detection purposes.
4. the LPDLE hardware object of the BTSC tree is provided to storage more than one
LAPD timeslot for the start-up of the BTSC (for LPDLMTD). There will be a one to
one correspondence between the LPDLMTD instance and the LPDLE instance.

580

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The user is able to see detailed information about both BTSMTD and LPDLMTD
configurations, by using the following two commands:

GETINFO BTSMTD

GETINFO LPDLMTD

In this way the user has a complete overview about the signalling related to a Site
Manager.
Prerequisites
The user must have the visibility level number set at "2".
The network element must be in phase "2".
BTSMTD:
To create a new site manager the existence of the PCMB is necessary.
After the creation of the BTSMTD its administrative state is set at LOCK. An UNLOCK
command is required to put the object in service.
LPDLMTD:
The instance of the LPDLMTD must not be already created. Instead, the instance of
PCMB inserted in the ABISCH attribute must be previously created.
Before creating a LPDLMTD instance, the user must create the superordinate BTSMTD.
The Time slot or subslot used to create the LPDLMTD must not be allocated by other
links.

Preliminary Consideration
Do you want to create a BTSMTD Site Manager?
Do you want to create a LAPD logical link?
Do you want to see information about BTSMTD configuration?
Do you want to see information about LPDLMTD configuration?

h ... 2
h ... 6
h ... 8
h ... 9

Precondition
Does the PCMB already exist?

Y h ... 3
N i ..."3.38 Addition
of a PCMB
Line"

Create the BTSMTD

To create a BTSMTD, enter the CREATE BTSMTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD --->

CREATE BTSMTD

Result: the BTSMTD is created in locked state.

A30808-X3247-L210-3-7619

581

OMN:BSC

Operation
Base Station Controller

Unlock the BTSMTD

To place the BTSMTD in service, unlock the object by entering the UNLOCK
BTSMTD command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> UNLOCK

BTSMTD

Result: the BTSMTD is unlocked.

Situation

Y h ... 7
N h ... END

Do you want to create a LPDLMTD logical link?

Precondition

Y h ... 7
N h ... 3

Does the BTSMTD already exist?

Create the LPDLMTD

Create the LPDLMTD by entering the CREATE LPDLMTD command following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> LPDLMTD

---> CREATE LPDLMTD

Result: the LPDLMTD is created.

h ... END

Get the BTSMTD configuration

To see the BTSMTD configuration, enter the GETINFO BTSMTD command

following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD --->

GETINFO BTSMTD

Result: the BTSMTD configuration is shown.

h ... END

Get the LPDLMTD configuration

To see LPDLMTD configuration, enter the GETINFO LPDLMTD command

following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> LPDLMTD

---> GETINFO LPDLMTD

Result: the configuration about LPDLMTD is shown.

END

582

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.121

OMN:BSC

Addition/Deletion of a TD-SCDMA Cell (BTSTD)

Introduction
The creation of a BTSTD configures a TD-SCDMA cell with special global attributes.
The management of the BTSTD object is split into four packages:

BASICS: the attributes within the BASICS group describe the basic properties of a
BTSTD;
CCCH: this group contains attributes related to common control channels
configuration;
OPTIONS: the attributes within the OPTIONS group allow to enable services or
features on the cell;
TIMER: it contains attributes related to timer setting.

The BSS can support up to 364 TD-SCDMA cells (i.e. one BTSTD for each BTSMTD
equipped).
When creating the BTSTD object, the user must define at least some mandatory values
belonging to the BASICS package. The mandatory values are:

NAME: the user must specify the BTSMTD absolute number (i.e. the site manager
to which the cell will belong). The BTSTD is univocally identified inside the BTSMTD.

BCCHFREQTD (bCCHFrequencyTD): defines the radio frequency channel number

of the BCCH channel. (see also "3.122 Addition/Deletion of a TD-SCDMA Transceiver (TRXTD)").

BSIDC (bsIdentityCodeTD): is composed of two fields, NCC (Network Color Code)

and BCC (Base station Color Code).

CELLGLID (cellGlobalIdentity): it contains the Cell Identification (CI) and the

Location Area Identification (LAI) of the cell.

PRIDLFG (priorityDLForget): specifies the forgetting factor, which is used in the

recursive averaging algorithm for updating the priority values of the DL timeslots.

INTTHDL (interferenceThresDL): describes the threshold, which is used to compare

the interference measurements reported by the UEs to it.

INTTHUL (interferenceThresUL): describes the threshold, which is used to compare

the interference measurements of the BTSC to it.

INTULAVP (interferenceULAvePer): specifies the averaging period for UL

interference measurements.

INTDLAVP (interferenceDLAvePer): specifies the averaging period for DL

interference measurements.

A30808-X3247-L210-3-7619

583

OMN:BSC

Operation
Base Station Controller

PRIUDPUL, PRIUDPDL (priorityUpdatePeriodUL, priorityUpdatePeriodDL):

specify the sending rate of the message RF_TS_PRIORITY_UPDATE_IND to the
BSC.

PRACHDESC (pRACHDESC): describes each configured P-RACH in term of

assigned RUs and associated AGCH;

PFACHDESC (pFACHDESC): describes each configured P-FACH in term of

assigned RUs and associated P-RACH.

TDNCCPERMI (tdnccPermitted): indicates the allowed Network Colour Codes, with

respect to the frequency band, for which measurements are allowed to be reported
by the UE in the cell.

MASONLYC (maxSignallingonlyCodes): specifies the maximum percentage of

SF16 codes (both in UL and DL direction) that can be allocated to signalling only
services.

MATXDLTSX (maxTXDLTSX): defines the maximal transmit power in each timeslot

except the timeslot in which PCCPCH is located..

HREFRLDTH (hREFRLoadThreshold): specifies the percentage threshold of busy

RUs and is used for assignment policy of HR/EFR radio resources.

PRIULFG (priorityULForget): specifies the forgetting factor, which is used in the

recursive averaging algorithm for updating the priority values of the UL timeslots.

MARINTDL (marIntDL): is an absolute logarithmic value needed only in BSC to

calculate the initial power level.

PCCPCHDESC (pCCPCHDesc): defines the number of blocks per multiframe on

P-CCPCH reserved for BCCH, AGCH, CBCH, other uses.

PATHLSLOPE (pathLossSlope): defines the path loss slope.

Moreover, the creation of the BTSTD implicitly creates the HANDTD and the PWRCTD
Managed Objects with their default values. The user can modify these attributes with the
relative SET commands.
In order to consider accessible a TD-SCDMA cell, it must be guaranteed the presence
of the following logical channels: BCCH, AGCH, PCH, FACH, RACH. To reach this
target, it is necessary to create PFACH, PRACH and P_CCPCH physical channels.
Besides, if the AGCH channel is not configured on P_CCPCH channel, we must have
S_CCPCH channel too.
The existence of P_CCPCH channel requires the creation of the AIRTSTD#0 object
(see "3.123 Addition/Deletion of a TD-SCDMA Air Timeslot").
The existence of PFACH, PRACH and S_CCPCH channels requires the creation of, at
least, further two AIRTSTD objects, one in downlink and one in uplink.
So, when creating a new TD-SCDMA cell the following steps must be executed:
1. the PRACHDESC, PFACHDESC, SCCPCHDESC, PCCPCHDESC attributes must
be filled in timely way (CREATE BTSTD);
2. to guarantee the cell accessibility the user must create for the new TD-SCDMA cell
(entering CREATE AIRTSTD command, see "3.123 Addition/Deletion of a TDSCDMA Air Timeslot"):
the AIRTSTD#0 object instance;
the AIRTSTD# instance, configured in BTSTD attributes as described in step 1.
A previously created BTSTD can be deleted by using the DELETE BTSTD command.

584

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The deletion of a BTSTD instance implies the automatic deletion of the corresponding
HANDTD and PWRCTD instances.
Prerequisites
In order to create a BTSTD object instance, the superordinate BTSMTD must be already
created.
In order to delete a BTSTD instance previously created, it is necessary to first delete all
the objects created after the BTSTD, which are the sons of this object in the creation
tree (see "Fig. 1.5.9 Creation Tree for TD-SCDMA related objects"). The user must start
from the leaf and then delete the objects, one by one, in their order.
Every object can be deleted only if it is a leaf in the creation tree.
The user must have the visibility level number set at "2".

Preliminary Consideration
Do you want to create a BTSTD?
Do you want to delete a BTSTD?

h ... 2
h ... 5

Precondition
Does the containing BTSMTD already exist?

Y h ... 3
N i ..."3.120 Addition
of a New TDSCDMA Site
Manager and of
Related LAPD
Links"

Create a BTSTD

To create a BTSTD, enter the CREATE BTSTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

CREATE BTSTD

Result: Creation of a BTSTD in locked state.

Unlock the BTSTD

To place the BTSTD in service, unlock the object by entering the UNLOCK
BTSTD command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

UNLOCK BTSTD

Result: The BTSTD object assumes the unlocked state.

A30808-X3247-L210-3-7619

h ... END

585

OMN:BSC

Operation
Base Station Controller

Preconditions

a. If all the related PTPPKFTD objects are deleted go to next step b. otherwise

eletion of a
Point-to-Point
Packet Function
(GPRS) for TDSCDMA"
i...."3.123 Addition/D
eletion of a TDSCDMA Air
Timeslot"
i...."3.122 Addition/D
eletion of a TDSCDMA Transceiver
(TRXTD)"

b. If all the related AIRTSTD objects are deleted go to next step c. otherwise

c. If all the related TRXTD objects are deleted go to next step, otherwise

Precondition

Y h ... 8
N h ... 7

Are all the related ADJCTD objects deleted?

i...."3.126 Addition/D

Delete the adjacent cells

Delete the adjacent cell by entering the DELETE ADJCTD command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

ADJCTD ---> DELETE ADJCTD

Result: Deletion of an Adjacent Cell. This command must be repeated for every
Adjacent Cell belonging to the BTSTD to be deleted.

Lock the BTSTD

In order to delete a BTSTD, lock the object entering the LOCK BTSTD
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

LOCK BTSTD

Result: The BTSTD to be deleted is in locked state.

586

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Delete the BTSTD

Delete the BTSTD entering the DELETE BTSTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

DELETE BTSTD.

Result: Deletion of the BTSTD

END

A30808-X3247-L210-3-7619

587

OMN:BSC

588

Operation
Base Station Controller

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.122

OMN:BSC

Addition/Deletion of a TD-SCDMA Transceiver (TRXTD)

Introduction
The creation of the TRXTD object defines the attributes of the single Transceiver of a
TD-SCDMA cell. The Transceiver is a functional entity representing functions common
to seven TD-SCDMA air time slots on one carrier.
The maximum number of TRXTDs per BSS is 364, and each BTSTD (i.e. each
TD-SCDMA cell) supports up to 3 TRXTDs (range [0..2]).
When creating a new TRXTD object the user must specify the following mandatory
attributes:
1. the TRXTDFREQ attribute defines the carrier frequency of the Transceiver. This
attribute can assume:
the BCCHFREQTD value, if the TRXTD is the BCCH one;
one CALLFTD value, among those defined by the user when creating the
superordinate BTSTD attribute (see "3.121 Addition/Deletion of a TD-SCDMA
Cell (BTSTD)").
For the TD-SCDMA mobile system the carrier spacing is 1.6 MHz, while the carrier
raster is 200 kHz.
The frequency band number is fixed to 5; this value indicates the primary
TD-SCDMA band, which has the range 2010.8 - 2024.2 MHz.
Up to 68 radio frequency numbers can be chosen inside the frequency band, and
the carrier frequency is obtained using the following formula:
Carrier_Frequency(radioFreqNum) = 2010.8 + 0.2 * (radioFreqNum),
where 0 < = radioFreqNum < = 67
2. LPDLMTDN: the TRXTD needs a logical LAPDTD instance related to it to permit the
transmission, over the PCMB line, of its radio resource management signalling; the
logical link is identified by the LPDLRTD object. The LPDLMTDN attribute indicates
the physical link over which the LPDLRTD, related to the transceiver, is conveyed. It
is the same physical link over which a LPDLMTDN logical link, related to the
corresponding BTSMTD, is allocated. The LPDLMTDN number has the range 0..7;
in fact for each BTSMTD up to eight LPDLMTD object instances can be created (see
"3.120 Addition of a New TD-SCDMA Site Manager and of Related LAPD Links").
The creation of a TRXTD object implies the consequent creation of the corresponding
LPDLRTD object.
As it has been described, the LPDLRTD is associated to one LPDLMTD logical link
(among the eight LPDLMTD links that can be created for each BTSM); in this way, the
LPDLRTD is automatically associated to one time slot of the PCMB line, i.e. the time slot
over which the LPDLM is allocated during its creation. This time slot is referred to as the
Primary position or Default position of the LPDLRTD (i.e. the position that is defined
inside the database).
After creating different LPDLMTD links instances for the same BTSMTD (see
"3.120 Addition of a New TD-SCDMA Site Manager and of Related LAPD Links"), the
situation is the following:

A30808-X3247-L210-3-7619

one LPDLMTD object instance is in Providing Service state;

the other LPDLMTD instances will be in Standby state.

589

OMN:BSC

Operation
Base Station Controller

The user is able to see detailed information about the LPDLRTD configuration, by using
the
GETINFO LPDLRTD command; in this way the user has a complete overview about the
allocation of the signalling related to a Transceiver.
The deletion of a TRX implies the automatic deletion of the corresponding LPDLRTD
instance.
Prerequisites
In order to create a TRXTD object instance, the superordinate BTSTD must be already
created.
The TRXTDFREQ value must not be already assigned to another TRXTD belonging to
the same BTSTD.
In order to delete a TRXTD instance previously created, the user must first delete all the
subordinate AIRTSTD functional objects.
The user must have the visibility level number set at "2".

Preliminary Consideration

h ... 2
h ... 4
h ... 5

Do you want to create a TRXTD?

Do you want to see information about LPDLRTD configuration?
Do you want to delete a TRXTD?

Create a TRXTD

To create a TRXTD, enter the CREATE TRXTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> CREATE TRXTD

Result: Creation of a TRXTD in locked state.

Put the TRXTD in service

To put the TRXTD in service, unlock the object by entering the UNLOCK TRXTD
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> UNLOCK TRXTD

Result: Unlocked state.

590

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Get LPDLRTD configuration

To see LPDLRTD configuration, enter the GETINFO LPDLRTD command

following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> LPDLRTD ---> GETINFO LPDLRTD

Result: The configuration about LPDLRTD is shown.

h ... END

Lock the TRXTD

In order to delete a TRXTD, lock the object by entering the LOCK TRXTD
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> LOCK TRXTD

Result: Locked state.

Precondition
Are all the related AIRTSTD instances deleted?

Y h ... 7
N h ..."3.123 Addition/D
eletion of a TDSCDMA Air
Timeslot"

Delete the TRXTD

Delete the TRXTD by entering the DELETE TRXTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> DELETE TRXTD.

Result: Deletion of the TRXTD

END

A30808-X3247-L210-3-7619

591

OMN:BSC

592

Operation
Base Station Controller

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.123

OMN:BSC

Addition/Deletion of a TD-SCDMA Air Timeslot

Introduction
The AIRTSTD functional object models the manageable characteristics of a radio time
slot on the TD-SCDMA air interface. Seven instances of this functional object are
contained by one instance of the TRXTD functional object.
A TD-SCDMA air timeslot can carry several combinations of logical channels and it is
described with radio time slot attributes (e.g. Downlink/Uplink direction).
In GSM the radio resource is given by frequency and time slot, while in TD-SCDMA the
basic radio resource (resource unit - RU) is defined by:

one frequency
one air timeslot
one code (i.e. spreading code).

Fig. 3.123.1 shows the TD-SCDMA principle. The given example shows a narrowband
TD-SCDMA channel structure for 7 timeslots, 16 CDMA codes and 1.6 MHz bandwidth.
The frame has a duration of 5 ms and is subdivided into 7 main timeslots (TSs); each
timeslot has a duration of 675 microseconds. The frame starts with the last DL timeslot
(TS 0) containing the BCCH and consists of 4 DL and 3 UL timeslots.
The timeslots for the uplink and the downlink are separated by a switching point. The
time slots before the switching point are allocated for the uplink (except for TS0), while
those after the switching point (including TS0) are allocated for the downlink.

TS0 of not-BCCH carriers is not used at all (neither for traffic nor for signalling).

Fig. 3.123.1TD-SCDMA principle

A30808-X3247-L210-3-7619

593

OMN:BSC

Operation
Base Station Controller

Due to the different nature of the TD-SCDMA physical layer compared to the GSM one,
the concept of GSM Channel (and the related functional object) could not be adopted
without modifications. The fact that the characteristics of the TD-SCDMA resource
unit(s) within a time slot are extremely variable (e.g. different spreading factors within
one timeslot are allowed) suggests not to adopt the concept of Resource Unit as a
Functional Object to be handled.
For the Administrative state of this functional managed object the following is defined:

'Locked' state means that no traffic is allowed over the Resource Units belonging to
the specific TD-SCDMA time slot represented by the managed object. If a
connection uses RUs on more than one time slot then no traffic is allowed over the
Resource Units belonging to the locked time slot only and the connection is dropped.

'Shutting_down' state means that no new traffic is allowed over the Resource Units
belonging to the specific TD-SCDMA time slot represented by the managed object
while the ongoing traffic is still kept. If a connection uses RUs on more than one time
slot then no new traffic is allowed over those Resource Units belonging to time slot
which is subject to the shutting_down procedure and when the last RU is released
the state transition to 'Locked' is performed.

'Unlocked' state means that new traffic is allowed over the Resource Units belonging
to the specific TD-SCDMA time slot represented by the managed object.

When creating an AIRTSTD managed object instance, the user has to specify the
following attributes (of which the latter is a mandatory attribute):

PREFSF (preferredSF): specifies which SF has to be preferred in case an even

number of resource units is required and the selected TS is fully idle.
DEFPRI (defaultPriority): indicates timeslot priority when DCA (Dynamic Channel
Allocation, see "3.129 TD-SCDMA Handover Management") is disabled and
PREFPRIO attribute of BTSTD managed object is set at DEFAULT.

Prerequisites
In order to create an AIRTSTD object instance the superordinate TRXTD must be
already created.
The user must have the visibility level number set at "2".

Preliminary Consideration

h ... 2
h ... 4

Do you want to create an AIRTSTD?

Do you want to delete an AIRTSTD?

Create a new air timeslot

To create a new air timeslot, enter the CREATE AIRTSTD command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> AIRTSTD ---> CREATE AIRTSTD

Result: Creation of a new air timeslot.

594

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Place the air timeslot in service

To place the Air Timeslot in service, unlock the object by entering the UNLOCK
AIRTSTD command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> AIRTSTD ---> UNLOCK AIRTSTD

Result: Unlocking of the newly created air timeslot.

h ... END

Lock the AIRTSTD

In order to delete an AIRTSTD, lock the object by entering the LOCK AIRTSTD
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> AIRTSTD ---> LOCK AIRTSTD

Result: Locked state.

Delete the AIRTSTD

Delete the AIRTSTD by entering the DELETE AIRTSTD command following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

TRXTD ---> AIRTSTD ---> DELETE AIRTSTD.

Result: Deletion of the AIRTSTD

END

A30808-X3247-L210-3-7619

595

OMN:BSC

Operation
Base Station Controller

3.124

Enabling Dynamic Channel Assignment

Introduction
Dynamic Channel Assignment (DCA) on Uu interface is composed of three main parts,
which are performed in succession:
1. Channel Assignment to cells (Slow DCA);
2. Admission Control;
3. Channel Selection (Fast DCA).
Channel Assignment (Slow DCA)
The goal of Slow DCA algorithm is to determine a priority value Pi for each cell, timeslot
and carrier. Priority is equal to the probability that in a certain timeslot / frequency / cell
the interference generated by other cells or frequencies is below a given threshold.
Priority values are calculated and updated on the basis of interference measurements
performed by the network and the UE. The measured quantity is the ISCP (Interference
Signal Code Power).
Two different procedures are used by the network to get DL ISCP measurements for all
the DL timeslots of all the carriers equipped in the cell (see below):

Measurements on Demand
Extended Measurements.

For each cell, timeslots are ranked on the basis of their priority values and when a new
radio channel is required it is first searched in the highest priority timeslot. In that way
each cell tends to use the less interfered timeslots and mutually interfering cells tend to
divide the available resources proportionally to the offered traffic.
Priority update is done locally in the BTSC in order not to transmit all the UL and DL
interference measurements on Abis interface. In a given cell, for each UL (DL)
timeslot/frequency, a priority value Pi is continuously updated on the basis of UL (DL)
interference measurements. Pi is given by the following recursive formula:
Pi(k) = f*Pi(k-1) + (1-f)*Si(k)
where:

Si variable represents the interference situation and is called good quality

variable; it is given by comparing the measured interference with a threshold,
defined by means of O&M parameters INTTHDL/INTTHUL (see below).
f parameter describes the actual memory length of the system and thus is named
forgetting factor.

At cell start-up the value of each timeslot priority is equal to 1.

The user can set the value of the forgetting factor on a per direction basis by means of
the PRIDLFG/PRIULFG (priorityDLForget, priorityULForget) parameters of the BTSTD
object. The range of the parameter is from 0 to 100; the parameter value corresponds
to the forgetting factor value multiplied by 100.
UL interference measurements are periodically made by the BTSC on all UL channels
and used to update the corresponding priorities.
DL interference measurements are made by new mobiles at call set up and reported in
the RACH. Besides, during a circuit switched connection mobiles periodically measure
DL interference on all timeslots and report these values on SACCH.

596

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The updated priority values are periodically transmitted to the BSC via the
RF_TS_PRIORITY_UPDATE_INDICATION dedicated message. The update period is
determined on a per direction basis by the O&M parameters PRIUDPDL
(priorityUpdatePeriodDL) and PRIUDPUL (priorityUpdatePeriodUL).
BSC reports periodically to MSC the overall usage and interference status of the radio
resources via the GSM message RESOURCE_INDICATION on A interface. Priorities
are classified into five bands. The user can set the boundaries of the bands by means
of the O&M parameter TSPRILVBOUN (tSPriorityLevelBoundaries) of the BTSTD
object.
The Slow DCA feature can be enabled/disabled, independently for each direction and
each cell, via the O&M parameters DLDCAST (downlinkDCAStatus) and ULDCAST
(uplinkDCAStatus), belonging to the BTSTD object. If the feature is disabled, BTSC
does not send the RF_TS_PRIORITY_UPDATE_INDICATION message to the BSC for
the specified direction (DL or UL or both).
The user can also set the following O&M parameters related to the priority updating
algorithm (all of them belong to the BTSTD object):

INTTHDL (interferenceThresDL): describes the threshold which the interference

measurements, reported by the UEs, are compared to. The results of the
comparisons are averaged for a certain tunable period (see INTDLAVP parameter
below). The averaged value is used to update the priority values of the DL timeslots.

INTTHUL (interferenceThresUL): describes the threshold which the interference

measurements of the BTSC are compared to. The results of the comparisons
are averaged for a certain tunable period (see INTULAVP parameter below). The
averaged value is used to update the priority values of the UL timeslots.

INTDLAVP (interferenceDLAvePer): specifies the averaging period for DL

interference measurements. The averaged values are used at the end of the period
to update the priority values for all DL timeslots.

INTULAVP (interferenceULAvePer): specifies the averaging period for UL

interference measurements. The averaged values are used at the end of the period
to update the priority values for all UL timeslots.

MEASUREMENTS ON DEMAND
It is the default mechanism devoted to collect measurements.
From the beginning of the connection, in dedicated mode or in packet transfer mode,
BTSC starts by default to command to the UE to perform ISCP measurements on the
DL timeslots of all the carriers equipped in the cell, i.e. for all the DL timeslots available
in the cell.
For this purpose, the Measurements on Demand signalling procedure is used on
SACCH in case of circuit switched connections.
The ISCP measurements on DL timeslots are collected by BTSC together with other
measurements on demand ordered to the UE. Each 48 frames 1 measurement on
demand is requested by BTSC from the UE. The measurements on demand are shifted
according to a round robin policy.
A further round robin policy is applied by BTSC to the ISCP measurements, which are
commanded for one timeslot at time, scanning in a continuous way the DL timeslots
included in an ordered list provided by BSC.

A30808-X3247-L210-3-7619

597

OMN:BSC

Operation
Base Station Controller

BSC periodically provides BTSC, via the MoD_LIST_UPDATING_REQUEST message,

with a new ordered list of DL timeslots to adopt for ISCP Measurements on Demand.
The periodic reordering of the list performed by BSC tends to get measurements for
those DL timeslots that provide the highest probability of success in case of assignment
of new resources to a UE.
The MODLUPDMIPER (moDListUpdatingMinPeriodicity) attribute, belonging to the
BTSTD object, defines the minimum periodicity (i.e. the maximum frequency) allowed
on the sending of the MoD_LIST_UPDATING_REQUEST message from BSC to BTSC.
EXTENDED MEASUREMENTS
An Extended Measurement can be ordered to an UE in dedicated mode when new
resources have to be assigned to it. The need to use this kind of measurements follows
from the need to make available to the SIR Based Admission Control procedure (see
below):

Recent ISCP measurements;

ISCP measurements for a number of DL timeslots as high as possible, in order to
increase the probability of successful resource retrieval by Channel Selection part
of DCA on BSC (see below).

With this measurement the BSC forces the UE to collect in one shot (only one
command is used to trigger all the measurements) the ISCP measurements of all the
timeslots indicated in a proper set in order to get back the SIR Based Admission Control
results for those timeslots.
The EXTMEPROCCLER (extMeasProcController) attribute, belonging to the BTSTD
object, allows to enable/disable the ISCP Extended Measurements procedure for each
of the following signalling scenarios:

first Normal Assignment;

Normal Assignments following the first;
Intracell Handover.

When the procedure is enabled, the extended measurements can be ordered only to the
UEs that support it.
Admission Control
Two levels of Admission Control are foreseen: SIR and Priority Based Admission
Control.
1. SIR Based Admission Control
It is performed in the BTSC. It determines, for each channel (timeslot/frequency), if
that channel can be used for the new service allocation based on the current
interference level, the Rx (Tx) level from (to) active RUs and the allowed UL (DL) Tx
power.
The target of the admission control is to be sure that a reliable DL or UL channel
estimation can be performed in any timeslot used for allocation. In this way the
admission control guarantees that Power Control procedure can work correctly from
the beginning. Different procedures are used for UL and DL channels. SIR Based
Admission Control is not performed in the candidate cell in case of Handover.

598

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

SIR Based Admission Control can be enabled/disabled, independently for each

direction and each cell, via the O&M parameters DLSIRACST
(downlinkSIRACStatus) and ULSIRACST (uplinkSIRACStatus), belonging to the
BTSTD object. Disabling the feature for DL (UL) direction means that all DL (UL)
timeslots fulfil the DL (UL) SIR Based Admission Control.
Besides, the user can set the UETSCPMA parameter (belonging to the BTSTD
object), which indicates the maximum allowed UE initial Tx power on the dedicated
channel and is one of the input quantities used by BTSC for the SIR Based
Admission Control Algorithm (see above).
2. Priority Based Admission Control
It is implemented in the BSC. The BSC receives from the accessed BTSC the list of
UL and DL channels satisfying the SIR Based Admission Control. For all UL (DL)
channels in the list BSC checks, using its stored priority values, if priority is higher
than a priority threshold.
Priority thresholds MIULPRI (minULPriority) and MIDLPRI (minDLPriority) are cell
parameters defined by O&M (they both belong to the BTSTD object). Only those UL
and DL channels that fulfil both SIR Based and Priority Based Admission Control
can be used by BSC for service allocation to the user.
In case of Handover Priority Based Admission Control is performed in the candidate
cell with different thresholds MIULPRIHO (minULPriorityHO) and MIDLPRIHO
(minDLPriorityHO).
Some services like emergency calls should be served in any case; thus the BSC
contains a list of services for whom Priority Based Admission Control must not be
performed.
Priority Based Admission Control cannot be disabled by the operator via a specific
O&M parameter (it could be practically disabled by setting MIDLPRI, MIULPRI,
MIDLPRIHO and MIULPRIHO parameters at 0 value).
However, if the Slow DCA feature is disabled (see above), the user can decide
whether current or default priorities are to be considered in Priority Based Admission
Control by means of the O&M PREFPRIO (prefPriorities) attribute. PREFPRIO
attribute belongs to BTSTD object and has two possible values: DEFAULT and
CURRENT.
If CURRENT value is set current priorities are used.
If DEFAULT value is set default priorities are used, i.e. priority values which are
defined, on a per timeslot basis, by the DEFPRI (defaultPriority) attribute of the
AIRTSTD object (see also "3.123 Addition/Deletion of a TD-SCDMA Air Timeslot").
If Slow DCA is enabled the PREFPRIO attribute is meaningless.
Channel Selection (Fast DCA)
Channel Selection part of Uu DCA provides the selection of frequency, timeslots,
Spreading Factor and channelization codes to be used for service allocation. Only
timeslots that have passed both SIR Based Admission Control and Priority Admission
Control can be used for service allocation. Channel Selection has to take into account
the assembling capabilities of different multislot/multicode mobile classes.
Timeslots are dynamically assigned to codes with SF (Spreading Factor) 16 or codes
with SF 8 according to the offered traffic or to the PREFSF (preferredSF) attribute. This
attribute, belonging to the AIRTSTD object, indicates which SF is to be preferred for a
fully idle timeslot if an even number of Basic Resource Units (BRUs) shall be allocated
on it. A SF 16 or 8 in the selected UL (DL) timeslot is determined on the basis of this
parameter.

A30808-X3247-L210-3-7619

599

OMN:BSC

Operation
Base Station Controller

SIGNALLING SERVICES
A threshold has been introduced to assure that a proper number of idle duplex (one code
for transmission direction) BRUs are reserved for signalling purposes among all the idle
BRUs of the BCCH carrier that pass Priority Based Admission Control. This is done in
order to allow allocations on the not-BCCH carriers even if the BCCH carrier is
congested. The threshold represents the minimum percentage of resources that DCA
algorithm keeps in idle state on the BCCH carrier. It can be set by the user by means of
the BCIDLERESTH (bcchIdleResThr) attribute, belonging to the BTSTD object.
The check is performed figuring out for each direction of the BCCH carrier the ratio
between the number of BRUs currently available for traffic and the total number of BRUs
actually enabled to traffic. Whenever the check fails (i.e. the ratio is lower than
BCIDLERESTH value in at least one direction) DCA performs the TD-PRS preemption,
in order to take the number of idle duplex BRUs above the threshold.
To achieve this goal, DCA tries, in order of priority, the following actions:
1. to release the packet resources on the BCCH carrier not currently used by any user.
2. to release the packet resources on the BCCH carrier currently in use by some user.
Besides, the MASONLYC (maxSignallingonlyCodes) attribute, belonging to the BTSTD
object, indicates the maximum percentage of SF 16 codes (both in UL and DL direction)
that can be assigned to signalling only services (Location Updating, SMS, etc.). As DCA
tends to keep signalling only services on the BCCH carrier, the threshold is checked for
the BCCH carrier only.
SPEECH SERVICES
Before assigning a BRU the system checks, for both UL and DL directions, the
percentage of busy BRUs (i.e. the ratio between the total number of BRUs not available
for new call (i.e. locked, failed, in call) and the total number of configured BRUs within
the cell). This percentage is compared with the threshold defined by the HREFRLDTH
(hREFRLoadThreshold) attribute, belonging to the BTSTD object.
If the percentage of busy RUs is lower than or equal to the HREFRLDTH value for both
UL and DL directions a TCH/F is assigned, also in case of half rate preferred command
from MSC. If the ratio is above the threshold for at least one direction the DCA assigns
TCH/H whenever possible (i.e. for dual rate UEs, half rate or full rate preferred).
This attribute is applied only in case of resources assignment to speech services.
DCA ALGORITHM
Fig. 3.124.2 and Fig. 3.124.3 show the flow diagram of the whole Channel Selection
process.
The algorithm shown in the figures is applied independently to both UL channels and DL
channels.

600

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The following criteria are taken into account by the algorithm: it tries with priority to
allocate the UL (DL) channel in one UL (DL) timeslot only. In this phase all timeslots
which fulfil the Priority Based Admission Control are sorted on the basis of decreasing
priority in order to satisfy the service request with the highest priority timeslot; if this
attempt fails, DCA Radio tries to allocate the UL (DL) channel in more than one timeslot
in UL (DL) direction. In this phase criteria for Code Clustering on a per timeslot basis are
applied, i.e. the algorithm tends to cluster the codes assigned to the service over a
number of timeslots as low as possible. For this purpose, all timeslots in the list are
sorted on the basis of increasing priority.
In order to couple Code Clustering to the basic DCA requirement that forces Channel
Selection to always use the timeslots with the highest priority value, the following
trade-off solution has been adopted.
For a given configuration of timeslots selected as suitable for service allocation, starting
from the timeslot with the highest priority value and going on according to a priority
decreasing order until the complete allocation of all the resources requested by the
service, in each timeslot as many resources as allowed by the SIR Based Admission
Control and by the current usage state of that timeslot are allocated.
This criterion is referred to as Priority Based Timeslot Filling Criterion.
DCA algorithm might optionally take into account the so-called Carrier Partitioning
Criterion, depending on the setting of CPPFAC (carrierPartitioningByPassFactor)
attribute.
This criterion consists in splitting among adjacent cells whole carriers rather than single
timeslots.
The CPPFAC attribute, belonging to the BTSTD object, defines the configuration priority
(normalised to the maximum one retrieved in the cell) below which the Carrier
Partitioning Criterion is by-passed by Channel Selection algorithm.

A30808-X3247-L210-3-7619

601

OMN:BSC

Operation
Base Station Controller

BSC receives a list of channels that fulfil

admission control from the accessed BTSC

The required band is equal to an even

number of codes with SF 16?

yes

no

Both codes with SF 8 and codes

with SF 16 can be used

Only codes with SF16

can be used

All channels in the list are sorted

on the basis of decreasing priority

All channels in which at least one code with

SF 8 is used are discarded
from the list

i=1
TSi is the i-th channel in the
ordered list

i=i+1
yes

TSi exists?

yes

TSi is locked, shut

down or disabled?

no

no

no

Step 2 starts

TSi has the required

number of codes?
no
yes

Codes in TSi are selected in a proper

fashion among those available
TSi has the required number of
midambles (1 for UL, equal to the
number of codes in DL)?

SF in TSi is selected on the basis

of PREFSF parameter

no

yes

yes
no
TSi is fully idle and an even
number of RUs is required?

yes

TSi fulfils the priority

based admission
control?

Fig. 3.124.2 Flow diagram of Channel Selection algorithm - Step 1

602

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

All timeslots in the list are sorted on the basis

of increasing priority

From step 1

i=1
TSi is the i-th timeslot in the
ordered list

i=i+1
TSi is locked, shut
down or disabled?

yes

no

TSi is fully idle?

yes

TSi has at least one code and

one midamble available?

no

yes

no

yes

An even number of codes with

SF 16 is still required?
no

SF in TSi is selected on the

basis of PREFSF parameter

SF 16 in TSi is selected

Midamble selection

no

Codes selection:
codes in TSi are selected in a proper
fashion among those available

Other codes are required

to allocate the service?

yes

Fig. 3.124.3 Flow diagram of Channel Selection algorithm - Step 2

A30808-X3247-L210-3-7619

603

OMN:BSC

Operation
Base Station Controller

Some points have to be noted in the flow diagrams: timeslots with the same priority are
sorted in a random fashion; the SF 16 codes which must always be available both in UL
and DL direction for signalling purposes will be reserved in timeslots with the lowest
priority value fulfilling both SIR and Priority Based Admission Control requirements; a
proper set of channelisation codes shall be selected in each timeslot in order to fit the
Midamble Selection criteria; depending on the number of radio resources found by the
algorithm, DCA Radio activates these resources and asks to DCA Abis to reserve the
proper number of PCMB resources.
Channel Selection cannot be disabled. The user can additionally set the following
attributes related to the feature:

MANOUSRTS (maxNofUsersPerTS): indicates the maximum number of users per

(DL) timeslot, thus determining the (minimum) available length of the window which
is used to perform the channel impulse response estimation in the cell for all DL
timeslots assigned in the cell. It belongs to the BTSTD object.

EBEAMFTX (enableBeamformTX): is used to decide whether downlink

beamforming is switched on or not; also, DCA algorithms need to know if it is
enabled or not. It belongs to the BTSTD object.

Prerequisites
The BTSTD and AIRTSTD objects to be set must be already created.
The user must have the visibility level number set at "2".

Preliminary Consideration

h ... 2
h ... 4
h ... 6
h ... 7

Do you want to enable the Slow DCA feature?

Do you want to enable the SIR Based Admission Control feature?
Do you want to manage the Priority Based Admission Control feature?
Do you want to manage the Channel Assignment feature?

Enable Slow DCA

To enable the Slow DCA, enter the SET BTSTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

SET BTSTD

Then set the ULDCAST (DLDCAST) attribute (BASICS group) at TRUE, in

order to enable Slow DCA in UL (DL) direction.
Result: the Slow DCA is enabled.

604

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set Slow DCA

To set the Slow DCA, enter the SET BTSTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

SET BTSTD

Then set the chosen value for the following attributes (BASICS group):
INTDLAVP, INTULAVP, INTTHUL, INTTHDL, PRIDLFG, PRIULFG, PRIUDPUL,
PRIUDPDL, TSPRILVBOUN, EXTMEPROCCLER,
MODLUPDMIPER.
Result: the chosen values for the attributes are set.

h ... END

Enable SIR Based Admission Control

To enable the SlR Based Admission Control, enter the SET BTSTD command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

SET BTSTD

Then set the ULSIRACST (DLSIRACST) attribute (BASICS group) at TRUE, in

order to enable SlR Based Admission Control in UL (DL) direction.
Result: the SlR Based Admission Control is enabled.

Set SIR Based Admission Control

To set the SIR Based Admission Control, enter the SET BTSTD command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

SET BTSTD

Then set the chosen value for the following attribute (BASICS group):
UETSCPMA.
Result: the chosen value for the attribute is set.

A30808-X3247-L210-3-7619

h ... END

605

OMN:BSC

Operation
Base Station Controller

Set Priority Based Admission Control

To set the Priority Based Admission Control, enter the SET AIRTSTD command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

AIRTSTD ---> SET AIRTSTD

and set the chosen value for the following attribute:

DEFPRI.
Then enter the SET BTSTD command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

SET BTSTD

and set the chosen value for the following attributes (BASICS group):
MIULPRI, MIDLPRI, MIULPRIHO, MIDLPRIHO, PREFPRIO.

h ... END

Result: the chosen values for the attributes are set.

Set Channel Assignment

To set the Channel Assignment, enter the SET AIRTSTD command following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

AIRTSTD ---> SET AIRTSTD

and set the chosen value for the following attribute:

PREFSF.
Then enter the SET BTSTD command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

SET BTSTD

and set the chosen value for the following attributes (BASICS group):
EBEAMFTX, HREFRDLTH, MANOUSRTS, MASONLYC, BCIDLERESTH,
CPPFAC.
Result: the chosen values for the attributes are set.

h ... END

END

606

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.125

OMN:BSC

Addition/Deletion of a Packet Control Unit for TD-SCDMA

Introduction
The PCUTD functional object represents the packet control unit designed to implement
the TD-SCDMA packet switched (TD-PRS) service in SBS.

Remember that TD-SCDMA services can be configured only if the high capacity BSC
with new rack is used and if it is equipped with both MPCCV8 and TDPCV7 processor
boards.
PCUTD is implemented by means of the PPXP card.
Up to twelve PCUTD object instances can be created (range [0..11]). The creation of the
PCUTD object implies the consequent creation of the corresponding PPXP object (in
fact, the PPXP object has the same range [0...11] of the PCUTD object).
Anyway, since PPXP cards are located into the expansion frame of the new rack
together with PPXT and PPXU cards (see "1.4.3.1 High Capacity BSC supporting TDSCDMA Services"), the number NP of equipped/operating PPXP cards depends on the
number of equipped PPXT and PPXU cards according to the following rule:

0<=NP<=11-NT
PPXP cards are equipped with a load balancing redundancy scheme. This implies that
all PPXP instances share TD-PRS packet service. The operator is allowed to configure
a single PPXP card (i.e. NP=1), but in such a case the load balancing redundancy
scheme is not exploited.
Due to the load balancing redundancy scheme, PCUTD is statically associated to the
PPXP with the same instance: the creation of the instance x of PCUTD causes the
automatic creation of the instance x of the related PPXP board.

The creation of the instance x of PCUTD is possible only if the slot x is free and it
blocks the creation of the instance x of PPXT or PCU (see also
"3.119 Addition/Deletion of a TD-SCDMA Control Unit" and "3.47 Addition of a Pointto-Point Packet Function (GPRS/EGPRS)"), but not of the instance x of TDCU, thanks
to the dynamic association PPXT-TDCU.
The creation of the instance x of PPXT or PCU blocks the creation of the same instance
x of PCUTD.
When creating a PCUTD managed object instance, the user must specify the value of
NSEI attribute, which identifies the PCUTD inside the SGSN. Different PCU and PCUTD
instances must have different NSEI values.
In order to delete a PCUTD object instance previously created, the user must first delete
all the subordinate FRL objects.
Prerequisites
The BSC must be an high capacity one (NTWCARD attribute of the BSC object set at
NTWSNAP_STLP).
The user must have the visibility level number set at "2".

A30808-X3247-L210-7619

607

OMN:BSC

Preliminary Consideration
Do you want to create a PCUTD unit?
Do you want to delete a PCUTD unit?

h ... 2
h ... 4

Precondition
Are there any free positions among the ones allowed by the expansion frame?

Operation
Base Station Controller

Y h ... 3
N h ... END

Create a PCUTD

Create a PCUTD by entering the CREATE PCUTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCUTD --->

CREATE PCUTD

Result: Creation of a PCUTD

After the creation of the PCUTD, the administrative state is set at UNLOCK. The
UNLOCK command is NOT required to place this object in service.

h ... END

Precondition
Are there any subordinate FRL instances still equipped?

Y i...."3.50 Deletion
of a Frame
Relay Link"

N h ... 5
5

Delete a PCUTD

Delete a PCUTD by entering the DELETE PCUTD command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> PCUTD --->

DELETE PCUTD

Result: Deletion of a PCUTD

h ... END

END

608

A30808-X3247-L210-7619

Operation
Base Station Controller

3.126

OMN:BSC

Addition/Deletion of a Point-to-Point Packet Function

(GPRS) for TD-SCDMA
Introduction
The PTPPKFTD functional object represents the point to point packet data service
(GPRS) in a TD-SCDMA cell. GPRS is called TD-PRS within the TD-SCDMA system.

EDGE is not applied to the TD-SCDMA system.

The PTPPKFTD state can be affected by BTSTD state change, by PCU state change,
by NSVC state change or by specific command on the object.
In the Containment tree, the PTPPKFTD object is hierarchically dependent on the
BTSTD one (see "1.5.1 Notes on the CREATE commands"). For each BTSTD instance
(i.e. for each configured cell) there is only one PTPPKFTD object instance subordinate
to it. This instance is always equal to 0.
So, the user can configure the TD-PRS service in a cell (i.e. the PTPPKFTD instance
number 0) only after having configured the cell (i.e. the related BTSTD instance).
In TD-SCDMA system, for point to point packet data transfer, a cell is identified by a
BVCI, so there is a one to one relation between cell and BVCI.
The NSVC-BVCI hierarchy is not one to one but one PTPPKFTD can be reached from
different NSVCs connected to the same PCU.
The PTPPKFTDs are grouped in Routing Area Clusters. Each Routing Area shall be
less or equal to the Location Area used to identify the cell.
This procedure creates the instance of the PTPPKFTD object related to a specific cell.
When creating the PTPPKFTD instance, the user must fill at least the following
mandatory attributes:
1. RACODE (routingAreaCode): specifies the Routing Area Code, which allows to
univocally identify the Routing Area inside the Location Area.
2. RACOL (routingAreaColour): specifies the Routing Area Colour, which allows the
UE to distinguish between two Routing Areas that have the same Routing Area
Code but belong to two different Location Areas.
3. PKTNINCTD (packetNumberIncrementTD): defines the number of increments for
counter N3102 performed after receiving packet uplink ACK/NACK.
Besides, when configuring the TD-PRS service on a cell (i.e. when creating a
PTPPKFTD object instance), the user shall specify some other parameters (belonging
to the PTPPKFTD object) that allow him to configure the service according to his needs.
The deletion of a Point-to-Point Packet Function for TD-SCDMA requires the removing
of a previously created instance of the PTPPKFTD object class. The appropriate system
information shall be sent on Um interface to inform the mobile about availability of the
service. As SGSN also knows the BVCI connected to this object, appropriate actions to
inform it about new PTPPKFTD configurations are taken by BSC.
Prerequisites
To create a PTPPKFTD instance the existence of the related BTSTD and PCUTD
objects and at least of a NSVC object on the same PCUTD is necessary.
The user must have the visibility level number set at "2".

A30808-X3247-L210-7619

609

OMN:BSC

Preliminary Consideration
Do you want to create a PTPPKFTD?
Do you want to delete a PTPPKFTD?

h ... 2
h ... 5

Preconditions

a. If the superordinate BTSTD object exists go to next step b. otherwise

b. If the superordinate PCUTD object exists go to next step c. otherwise

c. If a NSVC object on the same PCUTD does not exist

Operation
Base Station Controller

i...."3.121 Addition/D
eletion of a TDSCDMA Cell
(BTSTD)"
i...."3.125 Addition/D
eletion of a
Packet Control
Unit for TDSCDMA"
i...."3.45 Addition
of a Network
Service Virtual
Connection"

Create a PTPPKFTD

To create a PTPPKFTD, enter the CREATE PTPPKFTD command following the

next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

PTPPKFTD ---> CREATE PTPPKFTD

Result: Creation of a PTPPKFTD in Locked state.

Unlock the PTPPKFTD

To place the PTPPKFTD in service, unlock the object by entering the UNLOCK
PTPPKFTD command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

PTPPKFTD ---> UNLOCK PTPPKFTD

Result: Unlocking of the newly created PTPPKFTD.

h ... END

Lock the PTPPKFTD

In order to delete the PTPPKFTD, lock the object by entering the LOCK
PTPPKFTD command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

PTPPKFTD ---> LOCK PTPPKFTD

Result: PTPPKFTD in Locked state.

610

A30808-X3247-L210-7619

Operation
Base Station Controller

OMN:BSC

Delete the PTPPKFTD

The PTPPKFTD can now be deleted entering the DELETE PTPPKFTD

command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

PTPPKFTD ---> DELETE PTPPKFTD

Result: Deletion of the PTPPKF object.

END

A30808-X3247-L210-7619

611

OMN:BSC

612

Operation
Base Station Controller

A30808-X3247-L210-7619

Operation
Base Station Controller

3.127

OMN:BSC

Addition of a New Adjacent Cell for TD-SCDMA

Introduction
This procedure allows to create an adjacent cell for either TD-SCDMA or GSM services.
It allows to manage both internal adjacent cells (i.e. cells belonging to the same BSC)
and external adjacent cells (i.e. cells belonging to other BSCs).
The management of both internal and external adjacent cells is provided by means of
the TGTCELL attribute, which is a mandatory attribute.
Actually the following mandatory attributes have to be specified during adjacent cell
creation:
1. NAME: represents the complete path related to the ADJCTD object instance; for
each BTSTD object instance a maximum of 32 ADJCTD object instances can be
created;
2. TGTCELL: specifies the path of the target cell instance (see the explanation below).
On creating an adjacent cell relationship a distinction between two possible situations
shall be made:

adjacency between cells supporting only TD-SCDMA service (adjacency between

BTSTDs);

adjacency towards cells supporting GSM service (adjacency towards TGTBTSs).

ADJACENCY BETWEEN BTSTDs

In case of an adjacency to an internal BTSTD the TGTCELL attribute will contain a
reference (i.e. the complete path) to the internal target BTSTD.
In case of an external adjacency the TGTCELL attribute will contain a reference to a new
object, namely the TGTBTSTD object. A TGTBTSTD managed object instance (MOI)
contains a copy of the attributes of an external BTSTD MOI, to which an adjacent
relationship has to be made up. Once a TGTBTSTD MOI is configured it will be treated
by the system, for the management of the adjacencies, as the other internal target
BTSTDs.
This means that, in case the external target BTSTD is adjacent to more than one internal
serving BTSTD, it will be no more necessary to replicate all the attribute values in every
ADJCTD MOI, but it will be enough that the different ADJCTD MOIs refer to the same
TGTBTSTD MOI.
Fig. 3.127.1 shows the management of adjacent cells for TD-SCDMA.

A30808-X3247-L210-3-7619

613

OMN:BSC

Operation
Base Station Controller

BSC:1
BTSTD:2

CELLGLID:1
BSIDC:1
... ...
BTSTD:1/
ADJCTD:1

BSC:2

BTSTD:1
CELLGLID:2
BSIDC:2
... ...

BTSTD:1/
ADJCTD:2
BTSTD:5

TGTBTSTD:0
CELLGLID:5
BSIDC:5
... ...

BTSTD:3/
ADJCTD:0
BTSTD:2
BTSTD:3

CELLGLID:5
BSIDC:5
... ...

CELLGLID:3
BSIDC:3
... ...

Fig. 3.127.1 Management of adjacent cells for TD-SCDMA

Referring to BTSTD:1, two adjacent relationships are built:

BTSTD:1/ADJCTD:1; internal adjacent relationship towards BTSTD:2 (belonging to

BSC:1).
BTSTD:1/ADJCTD:2; external adjacent relationship towards BTSTD:5 (belonging to
BSC:2).

When the user creates the ADJCTD:1 instance he must specify only those attributes
that are not enclosed in BTSTD:2 (i.e.handover management attributes), while for the
other attributes (i.e. BCCHFREQTD, BSIDC, CELLGLID, etc.) the TGTCELL attribute
provides the reference to BTSTD:2.
When the user creates the ADJCTD:2 instance he must specify only those attributes
that are not enclosed in BTSTD:5 (i.e.handover management attributes). The TGTCELL
attribute will provide the reference to the TGTBTSTD:0 instance, that contains all the
attributes (i.e. BCCHFREQTD, BSIDC, CELLGLID, etc.) enclosed in BTSTD:5.
So the user, before creating an external adjacent relationship, must create the
TGTBTSTD instance containing the attributes belonging to the external cell.

614

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

ADJACENCY TOWARDS TGTBTSs

The same considerations apply for the management of the adjacencies towards BTSs.
In case of an external adjacency the TGTCELL attribute will contain a reference to a new
object, namely the TGTBTS object. A TGTBTS managed object instance (MOI) contains
a copy of the attributes of an external BTS MOI, to which an adjacent relationship
has to be made up. Once a TGTBTS MOI is configured it will be treated by the system,
for the management of the adjacencies, as the other internal target BTSs.
This means that, in case the external target BTS is adjacent to more than one internal
serving BTSTD, it will be no more necessary to replicate all the attribute values in every
ADJCTD MOI, but it will be enough that the different ADJCTD MOIs refer to the same
TGTBTS MOI.
So the user, before creating an external adjacent relationship, must create the TGTBTS
instance containing the attributes belonging to the external cell.

Order of creation of the new objects:

To explain the order in which the new objects have to be created we can distinguish two
possibilities.
1. In case of an adjacency between BTSTDs the order of creation of the objects,
involved in the adjacency management, is the following:
the target TGTBTSTD has no superordinate;
an ADJCTD instance, related to an external target BTSTD, has to be created only
after the creation of both the serving BTSTD and the related target TGTBTSTD.
2. In case of an adjacency towards a BTS the order of creation of the objects, involved
in the adjacency management, is the following:
the target TGTBTS has no superordinate;
an ADJCTD instance, related to an external target BTS, has to be created only
after the creation of both the serving BTSTD and the related target TGTBTS.

A single BTSTD can support up to 32 neighbour cells. When the LOTRACH attribute of
the SET HANDTD command is set at FALSE, one of the allowed ADJCTDs is reserved
by BSC for LOTRACH handling. The operator can then configure only 31 ADJCTD cells.
Prerequisites
To create an ADJCTD the superordinate BTSTD must be already created.
The user must have the visibility level number set at "2".

Choose the type of adjacent relationship

Would you like to create a TD-SCDMA adjacent relationship?
Would you like to create a GSM adjacent relationship?

h ... 2
h ... 6

Situation about TD-SCDMA target cell

Is the target cell an internal cell?
Is the target cell an external cell?

A30808-X3247-L210-3-7619

h ... 3
h ... 4

615

OMN:BSC

Operation
Base Station Controller

Create the internal adjacent relationship

To create a new internal adjacent cell, enter the CREATE ADJCTD command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

ADJCTD ---> CREATE ADJCTD

Then set the TGTCELL attribute equal to the BTSTD instance related to the
target internal cell.

h ... END

Result: The cell object is created with the entered attribute settings.

Precondition
Has the TGTBTSTD object instance, related to the external cell, been already
created?

Y h ... 5
N i...."3.128 Addition
of a New TDSCDMA/GSM
External Cell"

Create the external adjacent relationship

To create a new external adjacent cell, enter the CREATE ADJCTD command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

ADJCTD ---> CREATE ADJCTD

Then set the TGTCELL attribute equal to the TGTBTSTD instance related to the
target external cell.
Result: The cell object is created with the entered attribute settings.

h ... END

Precondition
Has the TGTBTS object instance, related to the GSM external cell, been
already created?

Y h ... 7
N i...."3.128 Addition
of a New TDSCDMA/GSM
External Cell"

616

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Create the external GSM adjacent relationship

To create a new external GSM adjacent cell, enter the CREATE ADJCTD
command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

ADJCTD ---> CREATE ADJCTD

Then set the TGTCELL attribute equal to the TGTBTS instance that univocally
represents the target GSM external cell.
Result: The cell object is created with the entered attribute settings.

END

A30808-X3247-L210-3-7619

617

OMN:BSC

618

Operation
Base Station Controller

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.128

OMN:BSC

Addition of a New TD-SCDMA/GSM External Cell

Introduction
This command is strictly related to the procedure that allows to add an adjacent cell to
the system (see "3.127 Addition of a New Adjacent Cell for TD-SCDMA"). Actually,
when the user configures a new external adjacent cell, there are two possible situations:

if the external cell supports TD-SCDMA service, the user must create before a
TGTBTSTD object instance. This TGTBTSTD (Target BTSTD) managed object
instance contains a copy of the attributes of the external target BTSTD. Once a
TGTBTSTD is configured it is treated by the system, for the management of the
adjacencies, as the other internal target BTSTDs. This means that, in case the
external target BTSTD is adjacent to more than one internal serving BTSTD, it is no
more necessary to replicate all the attribute values in every ADJCTD managed
object instance, but it is enough that the different ADJCTDs refer to the same
TGTBTSTD. The attributes of the external target BTSTD that must be inserted,
when creating the related TGTBTSTD instance, are the following:
CELLGLID (cellGlobalIdentity): it contains the Cell Identification (CI) and the
Location Area Identification (LAI) of the external target cell;
BSIDC (bsIdentityCodeTD): it is composed of two fields, NCC (Network Color
Code) and BCC (base station color code);
BCCHFREQTD (bCCHFrequencyTD): defines the radio frequency channel
number of the BCCH channel (see "3.122 Addition/Deletion of a TD-SCDMA
Transceiver (TRXTD)").

if the external cell supports GSM service, the user must create before a
TGTBTS instance. A TGTBTS managed object instance contains a copy of the
attributes of the external target BTS. Once a TGTBTS is configured it is treated by
the system, for the management of the adjacencies, as the other internal target BTS.
Therefore, in case of internal adjacency, the TGTCELL will identify the target BTS
through the reference to the superordinate BTS. In case of external adjacency, the
TGTCELL will identify the target BTS through the reference to the superordinate
TGTBTS. The attributes of the external target BTS that must be inserted, when
creating the related TGTBTS instance, are the following:
CELLGLID (cell global identity): it contains the Cell Identification (CI) and the
Location Area Id of the external target cell;
BSIC (base station identity code): it is composed by two fields, NCC (Network
Color Code) and BCC (base station color code);
BCCHFREQ: defines the absolute radio frequency channel number of the BCCH
channel;
SYSID: indicates the frequency band used by the external target cell.

Prerequisites
The user must have the visibility level number set at "2".
The Network Element must be in phase "2".

A30808-X3247-L210-3-7619

619

OMN:BSC

Operation
Base Station Controller

Choose the object instance to be created

h ... 2
h ... 3

Would you like to create a TGTBTSTD instance?

Would you like to create a TGTBTS instance?

Create the TGTBTSTD

To create a TGTBTSTD instance, enter the CREATE TGTBTSTD command,

following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> TGTBTSTD --->

CREATE TGTBTSTD

h ... END

Result: The TGTBTSTD instance is created.

Create the TGTBTS

To create a TGTBTS instance, enter the CREATE TGTBTS command, following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> TGTBTS ---> CREATE

TGTBTS

Result: The TGTBTS instance is created.

END

620

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.129

OMN:BSC

TD-SCDMA Handover Management

Introduction
The HANDTD object models the specific SIEMENS handover algorithm used within a
TD-SCDMA BTS Equipment (BTSC). The attributes of this object are used to control the
handover algorithm itself.
The handover process is one of the fundamental principles in cellular mobile radio,
maintaining a call/data session in progress whilst the mobile subscriber is moving
through the network. After starting a connection in the initial cell, the mobile subscriber
may leave it. By handing over the connection to the new cell in which the mobile is
entering, no service interruption occurs. The optimal design of the handover process is
of great importance in any cellular system, because UEs communicating with the wrong
BTSC will not only suffer poor link quality, but also increase interference in the network.
Mobile subscribers should have their calls established to the base station with the best
communication link, which is usually the nearest one, having the lowest path loss.
As for GSM system, the TD-SCDMA handover decision mainly relies on radio criteria,
i.e. it is based on radio link measurements performed by the BTSC (uplink) and by the
UE (downlink). Recognising the necessity to request a handover, the BTSC sends a
message to the BSC containing the handover cause and the preferred list of target cells.
Depending on the location of the target cells and on the handover cause an Intra-cell
handover or an Intra-BSC handover will be initiated by the BSC decision algorithm. If the
target cell for handover belongs to another BSC an Intra-MSC or even an Inter-MSC
handover (handover to a cell in another MSC area) will be initiated. So, the same overall
situations considered for GSM system are valid for TD-SCDMA system, except for
extended, hierarchical and concentric cell, that are not foreseen in TD-SCDMA phase 2.
Nevertheless, in TD-SCDMA system, a new kind of inter-cell handover can occur:
inter-system handover, currently only from a serving TD-SCDMA cell to a target GSM
cell, is allowed. Inter-system handover is foreseen for a multi mode UE, and in this case
the neighbouring cell list includes (besides TD-SCDMA cells) GSM system cells too.
Inter-system handover allows to maintain the connection also when no good candidate
for handover in TD-SCDMA system is available.
To prepare an intra-system handover (from TD-SDCMA to TD-SCDMA) or an
inter-system handover (from TD-SCDMA to GSM) the following measurements should
be performed by the UE (downlink measurements) and BTSC (uplink measurements)
for the serving TD-SCDMA cell:

Timing Advance (measured for each time-slot in case of multi-slot connections)

Received power level (measured for each time-slot in case of multi-slot connections)
BER before channel decoding (measured for each time-slot in case of multi-slot
connections)
BLER (BLock Error Rate)

Besides, during the measurement process the UE shall find synchronization to the
neighbour cells to obtain the following information:

Received power level

Interference measurements

As a GSM BTS, BTSC is in charge of :

1. monitoring handover conditions due to different causes :

A30808-X3247-L210-3-7619

621

OMN:BSC

Operation
Base Station Controller

quality (e.g. too low bit error rate and too high block error rate); DL quality
measurements already contain a BER-value mapped to a quality range. The
sampled BER-values of UL measurements are mapped by BTSC. The quality
values contained in DL-measurements and the UL quality values are compiled
and averaged in averaging windows. Different windows are used for different
applications (Handover, Power Control etc.), the UL window size is adjusted via
O&M-parameters. The DL window size is fixed and equal to SACCH period. A
weighting procedure is adopted in the presence of DTX.
received level (too low); the signal level value of the serving cell contained in DL
or UL measurements is compiled and averaged in averaging windows. The UL
window size is adjusted via O&M-parameters according to the specific operation
conditions. The DL window size is fixed and equal to SACCH period. A weighting
procedure is adopted in the presence of DTX.
MS-BS distance (too high); an absolute distance value should be derived from
Timing Advance.
better cell/power budget (relative received level).
forced handover.
2. formatting a list of (max 6) target adjacent cells, in which the current call could be
served in a better way. BTSC maintains a bookkeeping list for each possible
adjacent cell (up to 32) in which the neighbour cell measurements of UE, the DL
received level of serving cell measured by UE and the BTSC transmit power are
compiled and averaged. This bookkeeping list is the basis for evaluation of Power
Budget criterion, generation and sorting of the target cell list. UE neighbour cell
measurements contain the data of up to 6 monitored cells, these data being
identified by the cell identifier parameter. Independent bookkeeping lists are
foreseen at the moment for different system (e.g. TD-SCDMA and GSM). Only one
measurement message will be provided including measurement reports on both
TD-SCDMA and GSM system.
3. sending to BSC the message HANDOVER CONDITION INDICATION, intra or inter
cells, containing the above list in the second case.
After receiving the HANDOVER CONDITION INDICATION message, the BSC:

looks for a suitable channel to be allocated in the current serving cell, if an

INTRACELL HANDOVER CONDITION INDICATION was received from BTSC;

looks for a suitable channel to be allocated in one among the adjacent cells' list, if
an INTERCELL HANDOVER CONDITION INDICATION was received from BTSC
and if the cell belongs to current BSC;

if allocation fails or adjacent cells do not belong to current BSC, it sends an

HANDOVER REQUIRED to MSC network element, then causing an external
handover scenario.

Fig. 3.129.2 shows TD-SCDMA handover typologies:

622

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Intra PPXT Intercell HO

Intracell
Intra BSC
TD-SCDMA

Intrasystem

Inter PPXT Intercell HO

Inter BSC

External Intrasystem HO

Intra BSC

Internal Intersystem HO

Inter BSC

External Intersystem HO

Intercell
Intersystem

Fig. 3.129.2 Handover Typologies

The inter-PPXT handover is the consequence of the hardware structure and
configuration of the BSC; it arises when the target and serving TD-SCDMA cells are
governed by different PPXTs on the same BSC. Besides, TD-SCDMA system will affect
Handover decisional steps in different ways.
1. The Dynamic Channel Allocation (DCA) policy. In the present GSM BSC SW
architecture the channel to be allocated is selected by the TCH manager process,
whose allocation policy is based on a series of lists, which group the idle channels
according to their characteristics and interference band. In TD-SCDMA system the
channel allocation policy for intra-system handover is based on Dynamic Channel
Allocation, that can be divided into: Slow DCA on BTSC and Fast DCA on both
BTSC and BSC. The goal of Slow DCA algorithms, on BTSC side, is to determine a
priority value for each timeslot in a carrier. Priority comes from threshold
considerations about interference levels on time-slot basis in a carrier: such priority
values are notified to BSC on carrier (TRXTD) basis by means of dedicate Abis
Radio Signalling message. On BSC side, the goal of Fast DCA is to select a channel
resources set (frequency/timeslot/codes) to be used by the service call in progress.
Then handover algorithm requests Dynamic Channel Allocation to perform a
Channel Selection, in order to provide the suitable channel set.
2. The introduction of the Inter-system Handover type. For a multi-mode UE,
inter-system Handover is allowed between different systems, e.g. between a
TD-SCDMA traffic channel and a GSM 900/TCH or GSM 1800/TCH. In phase 2 only
inter-system handover from a TD-SCDMA cell to a GSM one is supported. Due to
this fact a priority has to be introduced for the cells present in the target cell list and
belonging to different systems: there is no way to get back to TD-SCDMA system
after an inter-system handover, so intra TD-SCDMA system handovers should be
attempted before. This new handover type does not substantially differ from other
handover types: it is triggered by BTSC for the same reasons and both BTSC and
BSC know that the target cell belongs to a different system with respect to the
serving one. Then, inter-system handover does not require a modification on A
interface, but new SW entities and messages are involved in the scenario. It is important to stress that a single BSC can deal at the same time with cells of different
systems, so inter-system handover can be both intra-BSC (internal) or involving
different BSCs (external) (see Fig. 3.129.2).

A30808-X3247-L210-3-7619

623

OMN:BSC

Operation
Base Station Controller

As it has been described, network element BTSC implements algorithms to detect

handover situations, and network element BSC hosts decisional steps (cells' scanning
procedure) in order to determine the target cell UE has to be moved to.
Prerequisites
The related BTSTD object instance must be already created, otherwise the HANDTD
object instance does not exist.
The user must have the visibility level number set at "2".

Set the HANDTD attributes

To modify the handover attributes, enter the SET HANDTD

command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

HANDTD ---> SET HANDTD

Result: Setting of the HANDTD attributes.

Get the value of HANDTD attributes

To obtain the attributes of the object, enter the GET HANDTD command
following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

HANDTD ---> GET HANDTD

Result: Obtaining the value of HANDTD attributes.

END

624

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.130

OMN:BSC

Management of the TD-SCDMA Power Control

Introduction
The PWRCTD object models the specific SIEMENS Power Control algorithm used
within UE and BTSC. The attributes of this object are used to control the Power Control
algorithm itself.
In CDMA systems the signals of several users are received together and are interfering
each other. The Power Control aims to the situation where the BTSC receives all users
with the same power level. This is the optimum for executing the despreading operation
as well as getting the best detection. In order to do that the Power Control commands
are sent to UE to adjust its RF power.
There are two advantages using Power Control:
1. reduction of the average power consumption (especially in the UE);
2. reduction of the interference experienced by other users.
In TD-SCDMA system three procedures of Power Control are foreseen:

Open Loop Power Control

Inner Loop Power Control
Outer Loop Power Control

The Open Loop Power Control is always used when no feedback is required. It is
suitable during the connection setup when some information is lacking.This procedure
is performed by BSC with the BTSC aid.
The other two procedures are executed in BTSC only.
The outer loop power control is used to adjust the SIR target for the inner loop power
control algorithm according the upper and lower raw BER thresholds
The user can enable or disable Downlink Power Control by means of the EBSPWRCTD
parameter.
The Power Control object (PWRCTD) has just one instance for the whole BTSC.
This object is automatically created with the BTSTD, so there is one PWRCTD for every
BTSTD. The user can only display and modify its attributes with the GET and SET
commands respectively.
With the SET PWRCTD command, the user can set the attributes of the Power Control
object, which models the Power Control algorithm used within UE/BTSTD and contains
attributes that are generic to any Power Control algorithm.
No administrative state is associated with the PWRCTD object.
Prerequisites
The related BTSTD object instance must be already created, otherwise the PWRCTD
object instance does not exist.
The user must have the visibility level number set at "2".

A30808-X3247-L210-3-7619

625

OMN:BSC

Operation
Base Station Controller

Define the Power Control

To define the parameters used in the Power Control algorithm, enter the SET
PWRCTD command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

PWRCTD ---> SET PWRCTD
The set the following attribute value:
EBSPWRCTD=TRUE
and choose the values of the other parameters according to your needs

Result: Setting of a PWRCTD object instance.

END

626

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.131

OMN:BSC

TD-SCDMA Directed Retry Management

Introduction
Directed Retry is the transition (handover) from a signalling channel in one cell to a TCH
in another cell during call setup due to unavailability of an idle TCH within the first cell.

Remember that SDCCH channels are not foreseen in TD-SCDMA.

Directed Retry is a mean to avoid the control of the traffic distribution between cells and
to avoid a call rejection due to congestion in one cell.
Directed Retry is merely triggered by BSC by sending a Forced HO Request message
to the BTS which has to respond with a "initiated" Intercell HO Cond. Indic. Message.
The Directed Retry is never triggered by radio conditions.
Prevention of "back-HO"
A major general problem of Forced HO (Directed Retry) is the probability of HO due to
PBGT back to the old (congested) cell.
The channel activation message contains an optional information element "Cell
Identifier List (no target)".
This information element contains the cell identifier (CI) of the cell from which a
handover request due to forced HO was received. If this information element exists in
the Channel Activation message, the BTS

shall not trigger a (TCH) HO due to PBGT for the time TINHBAKHO (TINHBAKHO
attribute is included in the ADJCTD object) if the PBGT condition is fulfilled for the
indicated cell only and
shall not include the indicated cell identifier(s) in the target cell list in this case for
time TINHBAKHO (i.e. for the condition HO due QUAL/LEV/DIST the indicated cell
identifier may be part of the target cell list)

The objects involved in directed retry handling are:

1. BSC
2. ADJCTD
For more detailed description of the associated attributes and algorithms please refer to
FRS 3003.

The BSC attributes which are involved in this procedure apply to both GSM and
TD-SCDMA systems, even though their descriptions refer to SDCCH channels (see
below).
Prerequisites
The BTSTD object instance must be already created.
The user must have the visibility level number set at "2".
A pre-requisite for the "Prevention of back handover" feature in case of MSC controlled
handover is that the cell ID in the HANDOVER REQUEST message uses a cell ID
discriminator 0 (CGI). If not, the back handover cannot be inhibited.
Furthermore, the cause IE in the HANDOVER REQUEST message has to be sent by
MSC. If not, BSC fills in the cause "distance", i.e. if the feature is active, every back
handover due to that reason is inhibited.

A30808-X3247-L210-3-7619

627

OMN:BSC

Operation
Base Station Controller

Set the BSC object with the involved parameters.

Select the SET BSC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSCand

enter the values for the attributes to be modified: ENFORCHO,
EISDDCHHO.

ENFORCHO:
This attribute enables/disables the sending of Forced HO Request messages for
running SDCCH connections. It is used to enable/disable Directed Retry. It
should be set at DISABLED if in a network the MSC which the BSS is
connected to or other adjacent BSSs do not support the prevention of "backHO".
EISDDCHHO:
This attribute allows to enable/disable MSC-controlled SDCCH-HOs (Directed
Retry). It simply prevents the sending of HO RQD message for SDCCH
connections to the MSC. If it is set at DISABLED, the BSC shall skip all cells
identifiers of the target cell list of the Intercell HO Cond. message which belong
to another BSC area. The flag should be set at DISABLED if the MSC does not
support Directed Retry.
Result: Setting of the BSC BASICS package with the involved parameters.

Set the ADJCTD object with the involved parameters.

Select the command "SET ADJCTD" following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BTSMTD ---> BTSTD --->

ADJCTD ---> SET ADJCTD and enter the values for the attributes to be
modified: TIMERFHOTD, FHORLMO.

TIMERFHOTD:
This attribute specifies the timer running in the BTSTD that controls the duration
of how long a former serving cell, from which forced handover was performed to
the new serving cell, may not be considered in the handover decision algorithm
for power budget handovers of the new serving cell and may not be contained in
the target cell list. It is started during the directed retry procedure at the
reception of a Channel Activation message containing a Cell Identifier (no
target) IE in the 'directed retry target BTSTD'.
FHORLMO:
This attribute defines the 'forced handover RXLEV minimum offset' which is
used by the handover decision algorithm to determine whether a neighbour cell
is regarded as a suitable target cell for forced handover or not.
Result: Setting of the ADJCTD object with the involved parameters.

END

628

A30808-X3247-L210-3-7619

Operation
Base Station Controller

A30808-X3247-L210-3-7619

OMN:BSC

629

OMN:BSC

Operation
Base Station Controller

3.132

HSCSD Service in TD-SCDMA System

Introduction
HSCSD service allows MSs subscribing to the General Bearer Services to make use of
higher data rates than what possible up to now. HSCSD also defines mechanisms for a
flexible use of air interface resources which make feasible the efficient use of higher user
rates.
The air interface user rate, i.e. the transfer rate in radio interface for user data, is limited
to 14.4 kbit/s in the current data transmission. HSCSD is the faster solution to introduce
in the network the capability to handle higher air interface user rate enabling the
co-allocation of multiple (up to 4) full rate traffic channel into a HSCSD configuration.
Even if HSCSD minimises the changes at the air interface and in the existing
infrastructure, this enhancement of the current system requires new additional signalling
at Um, Abis, A Interface (i.e. changed Assignment and Handover messages, methods
to assign additional timeslots to a running data call, etc.).
On the A interface, the use of resources is restricted to one 64 kbit/s circuit by
multiplexing the data streams into one A interface circuit.
Prerequisites
A prerequisite to HSCSD service is the availability of Circuit Pool concept on A interface.
For an efficient management of HSCSD service, TRAU Hardware (TRAC DSPs) must
be configured in such a way to be able to handle multiple connections on the same A
timeslot. Pools configuration enables the system to set up the appropriate Asub-A
Transcoder Matrix used to configure the TRAU Hardware.
The installation of HSCSD on SBS system requires first of all the planning of A Interface
pools: it must be decided which services will be supported by the various TSLA
managed by the TRAUs connected to the BSC. This task must be executed together
with MSC responsible, in order to ensure that the same TSLA is configured with the
same pool type on both BSC and MSC side.
It has to be noted that the Early Classmark sending must be enabled, setting the
attribute at TRUE, otherwise the UE does not send its multislot information to the
network.
The flag BTSHSCSD cannot be set at TRUE if the attribute EARCLM (of the BTSTD
OPTIONS group) is set at FALSE.
In order to enable the HSCSD service the EARCLM flag must be previously set at
TRUE.
The user must have the visibility level number set at "2".

Preliminary Consideration

To configure a system that provides an HSCSD service the user has to follow
the steps below:
set BSC
set BTSTD

630

h ... 2
h ... 3

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Set BSC

Use the SET BSC command following the next sequence of

selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> SET BSC

ENHSCSD
This attribute indicates whether the HSCSD service is activated on the BSC site
or not.
ENFOIAHO
This attribute indicates whether the Forced Intracell Handover procedure is
activated or not.
Result: Setting the BSC. The ENHSCSD attribute has to be set at TRUE.

Set BTSTD

Use the SET BTSTD command following the next sequence of selections.

MANAGED-ELEMENT ---> BSS-FUNCTIONAL --> BTSMTD ---> BTSTD --->

SET BTSTD

EARCLM
This attribute specifies whether the EARCLM sending procedure is enabled.
BTSHSCSD
This attribute indicates whether the HSCSD service is activated in that cell or
not.
Result: Set the BTSTD. The EARCLM and BTSHSCSD attributes have to be set
at TRUE.

END

A30808-X3247-L210-3-7619

631

OMN:BSC

Operation
Base Station Controller

3.133

Usage of tools for database management (DBAEM and

CONVFILE tools)
Introduction
Two different tools allow to manage the BSC database. They are:

DBAEM: it is an off-line tool which emulates DBA capabilities;

CONVFILE: it is used to upgrade an ASCII command file from an old version to a

new one. It can be used inside the same sw version when new hardware is introduced and changes in the ASCII command file are requested. For instance convfile
is used to change in an easy way to the new SNAP board, which is necessary for
the high capacity BSC (HC BSC).

To see how to install DBAEM and CONVFILE tools, please refer to the OGL:LMT
manual.
After the installation the two executable files (dbaem.exe and convfile.exe) are put in a
directory, e.g. DBE27011, that we call current directory and that we will often refer to
as c.d. in the following. In the case of dbaem usage, the name of the c.d. is related to
the installed dbaem version.
In this section all the required DOS operations will be fully described. However some of
the data used during the procedure execution are variable and depend on the users
settings. Variable names are written inside brackets (< >), and their meaning is
described immediately after the corresponding reference. Remember that DOS is not
case sensitive; all the commands and parameters can be written in capital or lowercase.
Some of the command parameters are optional and they can be skipped by the operator. These will be written inside square brackets ([ ]).

In the description of the following features the user is supposed to have already moved
to the c.d..
If, for instance, the working directory is C:\OTHERDIR and the directory containing the
tool (i.e. the current directory) is C:\DBE27011, the user has to type the DOS command:
CD \DBE27011 <Return>
before executing the chosen modality.
DBAEM
DBAEM allows to manage the database files, used to configure the system; it provides
the following features:

632

create_db modality:
it generates a Data Base (binary format) processing the commands described in a
Command file (ASCII format);
create_cmd modality:
it generates a command file (ASCII format) processing the Data Base contents
(binary format);
modify_db modality:
it modifies a Data Base (binary format) processing the commands described in a
Command file (ASCII format);
get_info modality:
it gives the last time the Data Base was modified.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The general form of the command is:

$ dbaem <modality> [options]
E.g.: C:\DBE27011\dbaem create_db (if the current directory is C:\DBE27011).
N.B.: the command is always written in lower case.
Optional parameters are depending on the chosen modality and are listed below:

-cmd allows the user to specify a specific CMD file: this parameter prevents the use
of the default file cmdxxxyy.asc.
cmdxxxyy.asc is the default name for ASCII Command file, where xxx stands for
release number and yy for load number; if the release we refer to is BR7.0, xxx
assumes the value 271 and yy can assume, for instance, the value 19 (in case of
load 19);

-dbout allows the user to specify the directory of the OUTPUT database; this parameter prevents the use of the default directory (which is the one containing the executable file dbaem);

-dbin allows the user to specify the directory of the input DATABASE; this parameter
prevents the use of the default directory (which is the one containing the executable
file dbaem);

-sym allows the user to specify a symbolic_name file, where supported. The
symbolic_name file is needed only if symbolic_names are used inside the ASCII
command file;

-res allows the user to specify the directory of the resource files when it is different
from the default directory (which is the c.d.). N.B.: for resource files we refer to
bsc.tre, message.txt and all files of type MML;

-o allows the user to specify an output file for the command get_info; this parameter
prevents the use of the default standard output (video);

-z allows the user to suppress error reporting on standard output

dbfile.dba is the default name for the binary Data Base file.

USAGE OF DBAEM
DBAEM features are described in the following sections.
CREATE_CMD modality
This modality can be used to generate an ASCII configuration command file
(cmdxxxyy.asc) starting from a binary data base file. The created file contains
commands conforming to the syntax described in the Command Manual for the BSC.
First of all the user has to copy to the c.d. the binary data base file. If, for instance, the
data base file (it has to be renamed dba.file if its name is different) is provided on a
floppy disk, the user has to put the diskette into the drive A: and do the following:
COPY A:\dbfile.dba <Return>
Then he has to enter the command line:
dbaem create_cmd [options]

A30808-X3247-L210-3-7619

633

OMN:BSC

Operation
Base Station Controller

The database is then loaded and the GET commands sequence is sent to the DBA software. The DBA software sends the response commands that are transformed in the
configuration commands.
Two output files are so created in the c.d.:

The most important is the ASCII command file cmdxxxyy.asc.

The file rspxxxyy.asc, which contains the response from DBA software.

Fig. 3.133.3 shows the entire process.

cmdxxxyy.asc
dbaem create_cmd

dbfile.dba

rspxxxyy.asc

Fig. 3.133.3 create_cmd modality

Each dbfile.dba contains a release number and a load number. A dbfile.dba can be
processed only by the DBAEM with the same version of that dbfile.dba (same release
number and load number).

Options:

-dbin <dir_in_dba>

-sym <symbolic_name_file>

-cmd <ASCII_command_file>

-res <dir_res_file>

-z

Example:
If the user has put the binary data base file into the directory named exampledatabase,
he has to enter the command:
dbaem create_cmd -dbin exampledatabase/dbfile.dba
CREATE_DB modality
This modality can be used to generate the binary data base file corresponding to a given
ASCII configuration command file (cmdxxxyy.asc). The source file contains commands
conforming to the syntax described in the CML:BSC manual.
First of all the user has to copy to the current directory (c.d.) the ASCII command file. If,
for instance, the ASCII file (it has to be renamed cmdxxxyy.asc if its name is different)
is provided on a floppy disk, the user has to put the diskette into the drive A: and do the
following:
COPY A:\cmdxxxyy.asc <Return>
Then he has to enter the command line:
dbaem create_db [options]

634

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Each command line, after a syntax check, is transformed in a message sent to the DBA
software, which makes a semantic check and creates the structures of the database.
Two output files are generated:

The most important one is the binary database file dbfile.dba.

rspxxxyy.asc contains all the responses from the DBA. Its in this ASCII file that can
be found useful information on any eventual NACKCAUSE generated by DBA software, concerning some generic wrong commands. In this case the user has to refer
to the COMMAND manual to fix the problem.

Fig. 3.133.4 shows the entire process.

dbfile.dba
cmdxxxyy.asc

dbaem create_db

rspxxxyy.asc

Fig. 3.133.4 create_db modality

Each dbfile.dba contains a release number and a load number. A dbfile.dba can be
processed only by the DBAEM with the same version of that dbfile.dba (same release
number and load number).

Options:

-cmd <ASCII_command_file>

-sym <symbolic_name_file>

-dbout <dir_out_dba>

-res <dir_res_file>

-z

Example:
If the name of the ASCII command file is command.example, hence different from the
default name, the user has to enter the command:
dbaem create_db -cmd command.example
MODIFY_DB modality
This option can be used to create an updated data base file, starting from an old version
and from an ASCII command file (cmdxxxyy.asc) describing the changes to be done.
The command file contains commands conforming to the syntax described in the
CML:BSC manual.
First of all the user has to copy to the current directory (c.d.) the binary data base file to
modify and the ASCII file. If, for instance, the data base file (it has to be renamed dba.file
if its name is different) and the ASCII command file (it has to be renamed cmdxxxyy.asc
if its name is different) are provided on a floppy disk, the user has to put the diskette into
the drive A: and do the following:
COPY A:\dbfile.dba <Return>

A30808-X3247-L210-3-7619

635

OMN:BSC

Operation
Base Station Controller

COPY A:\cmdxxxyy.asc <Return>

Then he has to enter the command line:
dbaem modify_db [options]
The database is loaded. Each command read from cmdxxxyy.asc is transformed into a
message sent to DBA software, which modifies the database structures.
The modified binary database file modify.dba is created as output. Any eventual NACKCAUSE is reported in ASCII file rspxxxyy.asc, and in this case the user has to refer to
the COMMAND manual to fix the problem.
Fig. 3.133.5 shows the entire process.

dbfile.dba
dbfile.dba
cmdxxxyy.asc

dbaem modify_db

rspxxxyy.asc

Fig. 3.133.5 modify_db modality

Each dbfile.dba contains a release number and a load number. A dbfile.dba can be
processed only by the DBAEM with the same version of that dbfile.dba (same release
number and load number).

Options:

-dbin <dir_in_dba>

-cmd <ASCII_command_file>

-sym <symbolic_name_file>

-dbout <dir_out_dba>

-res <dir_res_file>

-z

Example:
If the name of the ASCII command file is command.example, hence different from the
default name, the user has to enter the command:
dbaem modify_db -cmd example.cmd
GET_INFO modality
This modality can be used to know the time a binary data base file was last modified.
In the previous description of the three modalities create_cmd, create_db and
modify_db, we highlighted that a dbfile.dba file can be processed only by the DBAEM
with the same version of that binary database file (same release number and load
number).

636

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

As each dbfile.dba contains the information related to its release number and load
number, the get_info option is the modality used to retrieve this information. For this
reason, each executable with this modality can be used independently from the version
of the binary database file received as input (note: we point out again that this is the only
exception).
To use the get_info modality, the user has to copy to the current directory (c.d.) the
binary data base file first. If, for instance, the data base file (it has to be renamed dba.file
if its name is different) is provided on a floppy disk, the user has to put the diskette into
the drive A: and do the following:
COPY A:\dbfile.dba <Return>
Then he has to enter the command line:
dbaem get_info [options]
In normal behaviour dbaem expects to find the binary database file dbfile.dba. As output
the user will receive a message like:
sbs-O-261-1-13-00
Thu Aug 06 15:18:45 1998
Fig. 3.133.6 shows the entire process.

dbfile.dba

dbaem get_info

Output to
Video

Fig. 3.133.6 get_info modality

Each executable with this modality can be used independently from the version of the
database file.

Options:

-dbin <dir_in_dba>

-o <output_file>

Example:
If the directory containing the binary data base file is the one named dbexample
(different from the default one), and the user wants to specify an output file (named
output.example) for the get_info command, instead of using the default standard
output (video), he has to enter the following command:
dbaem get_info -dbin dbexample -o output.example

A30808-X3247-L210-3-7619

637

OMN:BSC

Operation
Base Station Controller

CONVFILE
CONVFILE tool can be used to upgrade an ASCII command file to a new version of it,
in case of changes of command syntax and/or definition. Since CONVFILE does not
handle databases, but only text files, it can be used as any other DOS application.

The general form of the command is:

$ convfile <release-A> <release-B> -f | -p [-i fileA] [-o fileB] [-e error_file] [-snap] [snap_stlp]
N.B.: the command is always written in lower case.
Optional parameters are:

-f: to specify that the conversion is relative to a full database, where all the information needed for some automatic changes is available (this should always be
inserted);

-p: to specify that the conversion is relative to a partial database, where not all the
information needed for some automatic changes is available (this should always be
used);

<release-A>: a number able to identify unambiguously the release which has to be

considered the starting point;

<release-B>: a number able to identify unambiguously the release whose type will
be the output script;

638

The <release-B> value can be the same as the <release-A> one; e.g.:
convfile 27121 27121 -f snap

[-i fileA]: option which permits to specify a file different from the default-input-one,
determined on value <release-A>: cmdxxxyy.asc (where xxx is the number of
<release-A> and yy is the relative load number) in the working directory;

[-o fileB]: option which permits to specify a file different from the default-output-one,
determined on value <release-B>: cmdxxxyy.asc (where xxx is the number of
<release-B> and yy is the relative load number) in the working directory;

[-e error_file]: option which permits to specify a file where the tool can write information on the execution: successful or not. This option can be used when implementing the GUI manager;

[-snap]: option that has to be chosen in case of changing from a standard BSC
(SN16 matrix) to high capacity BSC maintaining the old rack (see High Capacity
BSC with Old Rack).

[-snap_stlp]: option that has to be chosen in case of changing from either a standard BSC (SN16 matrix) or a high capacity BSC with the old rack to a high capacity
BSC with the new rack (i.e. with a BSC equipped with STLP boards, see High
Capacity BSC with New Rack).

The number that identifies a release can be 3-digits-long up to 7-digits-long. For

instance, 271 implicitly means load 2710000 of BR70 (the same obtained with 2710,
27100, 271000 and 2710000 itself), while 2711401 matches only 2711401.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

i
!

OMN:BSC

The names of the involved files must be specified with their whole DOS path, unless
they reside on the same directory which CONVFILE tool lays on.
CONVFILE converts as much as possible automatically, but for some parameters
manual intervention is necessary. The PCM lines distribution over LICD boards will not
be modified by CONVFILE, but it is up to the operator to manually update the ASCII file
if required. In fact, since the PCM lines are distributed over the LICD as specified by the
operator, if the "--snap_stlp" option is specified, and the STLP boards replace the
QTLP/DTLP boards, it is not possible to establish a "rule" to be applied in re-distribution.

Examples:
If the involved releases are BR6.0 and BR7.0, a convfile command may be:
convfile 26114 27121 -f
If, with the same releases, the user wants to specify a file different from the default-inputone (but included in the same directory which the CONVFILE tool lays on), named
cmd_acl_omc.asc, he has to enter the command:
convfile -f 26114 27121 -i cmd_acl_omc.asc

USAGE OF CONVFILE
First of all the user has to move to the directory where the CONVFILE tool is installed.
For instance, if CONVFILE has been installed on the directory C.\DBE27009, the user
has to enter the following command:
CD \DBE27009 <Return>
Then he has to enter the command line:
convfile <release-A> <release-B> -f | -p [-i fileA] [-o fileB] [-e error_file] [snap][snap_stlp]
As a result the new command file, with name <cmdxxxyy.asc>, is created. During the
new file generation the CONVFILE utility may generate messages to the operator.
These messages are anyway reported on the same ASCII file. For each command,
which must be fixed someway, the relative line is commented (it means that it is started
by the pair of characters //, and marked as WRONG COMMAND->, followed by a
string, which specifies what is wrong, and which action must be performed to fix the
command).
Pre-Requisites
The DBAEM and the CONVFILE tools must be installed on the LMT (to see how to install
the tools, please refer to the OGL:LMT manual.

A30808-X3247-L210-3-7619

639

OMN:BSC

Operation
Base Station Controller

Choose the tool to use

h ... 2
h ... 12

Do you want to use the DBAEM tool?

Do you want to use the CONVFILE tool?

Selection of the current directory

Set the directory containing the executable tool (i.e. the current directory, c.d.)
as the active one. Use the standard DOS commands.
Example:
If the directory containing the executable tool is C:\DBE27008, do the following:

CD \DBE27008 <Return>

Select the operation you want to do

Do you want to generate a database file in ASCII format, starting from a
binary format one?

h ... 4

Do you want to generate a database file in binary format, starting from an

ASCII format one?

h ... 6

Do you want to modify a database (binary format) processing the commands

described in a command file (ASCII format)?
Do you want to see the last time the database was modified?

h ... 8
h ... 10

Copy the binary data base file

Copy to the c.d. the binary data base file.

Example:
If the data base file is named, e.g.,oldfile_name and is provided on a floppy
disk, put the diskette into the drive A: and do the following:

COPY A:\oldfile_name <Return>

If the name of the binary data base file is different from the default one
dbfile.dba, rename it with the DOS command:

RENAME oldfile_name dbfile.dba <Return>

Generation of ASCII configuration command file (CREATE_CMD modality)

Activate the create_cmd modality by entering the following command:

dbaem create_cmd [options] <Return>

Results:
The output result is cmdxxxyy.asc file with the generating commands. This file is
created on the c.d..

640

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Copy the ASCII command file

Copy the configuration file to the c.d..

Example:
If the ASCII configuration file is named, e.g., MILAN.TXT, and is provided on a
floppy disk, put the floppy disk into the drive A: and do the following:

COPY A:\MILAN.TXT <Return>

If the name of the ASCII command file is different from the default one
cmdxxxyy.asc, rename it with the DOS command:

RENAME MILAN.TXT cmdxxxyy.asc <Return>

Generation of the data base (CREATE_DB modality)

Activate the create_db modality by entering the following command:

dbaem create_db [options] <Return>

Results:
The output results are:
1) The dbfile.dba file in the c.d. if the response is different from NACK
2) A rspxxxyyy.asc file in the c.d., where are reported all the DBA responses to
each command. If the response is NACK please refer to the COMMAND
manual to fix the problem.

h ... END

Copy the input files

Copy the configuration file to the c.d..

Example:
If the ASCII configuration file is named, e.g., MILAN.TXT, and is provided on a
floppy disk, put the floppy disk into the drive A: and do the following:

COPY A:\MILAN.TXT <Return>

If the name of the ASCII command file is different from the default one
cmdxxxyy.asc, rename it with the DOS command:

RENAME MILAN.TXT cmdxxxyy.asc <Return>

Copy to the c.d. the binary data base file.

Example:
If the data base file is named, e.g., oldfile_name, and is provided on a floppy
disk, put the diskette into the drive A: and do the following:

COPY A:\oldfile_name <Return>

If the name of the binary data base file is different from the default one
dbfile.dba, rename it with the DOS command:

RENAME oldfile_name dbfile.dba <Return>

A30808-X3247-L210-3-7619

641

OMN:BSC

Operation
Base Station Controller

Updating the data base (MODIFY_DB modality)

Activate the MODIFY_DB modality by entering the following command:

dbaem modify_db [options] <Return>

Results:
The output results are:
1) The modify.dba file in the c.d.if the response is different from NACK
2) A rspxxxyy.asc file in the c.d. where are reported all the DBA responses to
each command. If the response is NACK please refer to the COMMAND
manual to fix the problem.

10

h ... END

Copy the old binary data base file

Copy on the current directory the binary data base file.

Example:
If the data base file is named, e.g., oldfile_name, and is provided on a floppy
disk, put the diskette into the drive A: and do the following:

COPY A:\oldfile_name <Return>

If the name of the old binary data base file is different from the default one
dbfile.dba, rename it with the DOS command:

RENAME oldfile_name dbfile.dba <Return>

11

Retrieving information about a database file (GET_INFO modality)

Activate the get_info modality by entering the following command:

dbaem get_info [options] <Return>

Results:
A message is shown as output to the Video.

12

h ... END

Selection of the current directory

Set the directory containing the executable tool (i.e. the current directory, c.d.)
as the active one. Use the standard DOS commands.
Example:
If the directory containing the executable tool is C:\DBE27008, do the following:

642

CD \DBE27008 <Return>

A30808-X3247-L210-3-7619

Operation
Base Station Controller

13

OMN:BSC

Copy the ASCII command file

Copy the configuration file to be upgraded to the c.d..

Example:
If the ASCII configuration file is named, e.g., MILAN.TXT, and is provided on a
floppy disk, put the floppy disk into the drive A: and do the following:

COPY A:\MILAN.TXT <Return>

If the name of the ASCII command file is different from the default one
cmdxxxyy.asc (where xxx is the number of the old release and yy is the relative load number), rename it with the DOS command:

RENAME MILAN.TXT cmdxxxyy.asc <Return>

14

CONVFILE execution

Activate the CONVFILE modality by entering the following command:

convfile <release-A> <release-B> -f

Result:
The new command file is created. Its default name is cmdxxxyy.asc, where xxx
is the number of the new release and yy is the relative load number.

END

A30808-X3247-L210-3-7619

643

OMN:BSC

Operation
Base Station Controller

3.134

Different release Data Base Conversions

This feature provides an example of the usage of DBAEM and CONVFILE tools in a
specific case, i.e. the conversion of a database from one release to another one.
All the required DOS operations will be fully described. Some of the data used during
the procedure execution are variable and depend on the users settings. Variable names
are written inside brackets (<>), and their meaning is described immediately after the
corresponding reference. Remember that DOS is not case sensitive; all the commands
and parameters can be written in capital or lowercase.
Some of the command parameters are optional and they can be skipped by the operator. These will be written inside square brackets ([ ]).
In the following we consider the example of a conversion from release BR5.5 to release
BR7.0. Lets suppose, for the sake of simplicity, that DBAEM and CONVFILE tools
related to the same release are installed on the same directory. The directories involved
in this example are:

C:\DBE25506 for the BR5.5 version. It contains the DBAEM and CONVFILE tools of
BR5.5;
C:\DBE27011 for the BR7.0 version. It contains the DBAEM and CONVFILE tools of
BR7.0.

For the details concerning the usage of DBAEM and CONVFILE tools, please refer to
"3.133 Usage of tools for database management (DBAEM and CONVFILE tools)".

The starting point is represented by a binary data base file of BR5.5. First of all the user
has to generate an ASCII configuration command file, using this data base file. As the
mentioned files are relative to BR5.5 release, please refer to the BR5.5 version of
OMN:BSC manual for the conversion (it makes use of the create_cmd modality of the
DBAEM tool of BR5.5).
Here we make the supposition of having obtained an ASCII command file called
cmd25506.asc (rename it in such a way if its name is different), located in the directory
C:\DBE25506\MILAN, as the output of the conversion.
Before executing any option, the user has to set the DBE27011 directory as the active
one, by means of the command:
CD \DBE27011 <Return>
The cmd25506.asc file has to be copied to the current directory, by entering the
following command:
COPY C:\DBE25506\MILAN\cmd25506.asc <Return>
At this point the user can launch the CONVFILE tool of BR7.0, in order to create the new
command file.
The DOS command is the following:
convfile cmd25506 cmd27011 -f.
The result is that the command file cmd27011.asc, with the generating commands, is
created in the DBE27011 directory.

644

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Last step consists in converting the ASCII file generated in the corresponding Data Base
of BR7.0, by using the create_db modality of the DBAEM tool of BR7.0.
The command is:
dbaem create_db <Return>
As the final result, two files are created in the DBE27011 directory: rsp27011.asc and
dbfile.dba, which is the binary file containing the Data Base of BR7.0 release.
Pre-Requisites
The DBAEM and CONVFILE tools must be installed on the LMT (to see how to install
the tools, please refer to the OGL:LMT manual).

A30808-X3247-L210-3-7619

645

OMN:BSC

Operation
Base Station Controller

Generation of ASCII configuration command file (CREATE_CMD modality)

in the old release

This option is used to generate an ASCII configuration command file

(CMDxxxxx.ASC) starting from a binary data base file. The created file contains
commands conforming to the syntax described in the Command Manual for the
BSC.
Set the DBINPUT directory corresponding to the site as the active one. Use the
standard DOS commands.
Example:
If the DBAEM tool has been installed on the directory C:\DBE25506 and the
Data Base corresponds to the site "MILAN" and the current directory is
C:\OTHERDIR, do the following:

CD \DBE25506\MILAN\DBINPUT <Return>

Copy to the current directory the binary data base file.

Example:
If the data base file (rename it DBFILE.DBA if its name is different) is provided
on a floppy disk, put the diskette into the drive A: and do the following:

COPY A:\DBFILE.DBA <Return>

Move to the main directory, in order to execute DBAEM. Enter the following
commands:
(This command has to be entered twice, since the main directory is the grandparent of DBINPUT)

CD..<Return>
CD..<Return>

Activate the CREATE_CMD option by entering the following command:

DBAEM CREATE_CMD <site name> [/CONF] [/DEF] [/GEN] [/LOG] [/SYM]

<Return>
The following parameters are optional:

646

CONF: allows the user to specify a specific SNX file; this parameter prevents the use of the default
file SNXxxxxx.ASC;

DEF: allows the user to specify a specific DEF file; this parameter prevents the use of the default
file DEFxxxxx.ASC;

GEN: allows the user to specify a specific CMD file; this parameter prevents the use of the default
file CMDxxxxx.ASC;

LOG: allows the user to specify an output directory for the LOG files; this parameter prevents the
use of the default directory (..\SITEx);

SYM: allows the user to specify a symbolic-name file (where supported: only from BR4.0).

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The data base present in "..\<site name>\DBINPUT" directory is loaded and the
GET commands sequence is sent to the DBA software. The DBA software
makes the response commands that are transformed in the related configuration commands.
Results:
The output result is CMDxxxxx.ASC file with the generating commands. This file
is created on the site directory.

Rename the configuration file

Rename the configuration file, in order to provide the convfile tool of the new
release with the default-input-name it expects to find. Assuming that xxx is the
number of the new release and yy is the relative load number, the DOS
command is:

RENAME CMDxxxxx.ASC cmdxxxyy.asc <Return>

Selection of the current directory in the new release

Set the directory containing the executable tools of the new release as the
active one. Use the standard DOS commands.
Example:
If the directory containing the executable tools of the new release is
C:\DBE27011, do the following:

CD \DBE27011 <Return>

CONVFILE execution

Copy to the current directory the configuration file.

Example:
If the configuration file is located into the directory C:\DBE25506\MILAN, do the
following:

COPY C:\DBE25506\MILAN\cmdxxxyy.asc <Return>

Activate the CONVFILE modality by entering the following command:

convfile <release-A> <release-B> -f

Result:
The new command file is created in the directory containing the tools of the new
release. The default name of the file is cmdxxxyy.asc, where xxx is the number
of the new release.

A30808-X3247-L210-3-7619

647

OMN:BSC

Operation
Base Station Controller

Generation of the Data Base binary file (CREATE_DB modality)

Activate the create_db option by entering the following command:

dbaem create_db [options] <Return>

Results:
The output results are:
1) The dbfile.dba file in the DBExxxyy directory.
2) A rspxxxyy.asc file in the DBExxxyy directory, where are reported all the DBA
responses to each command. If the response is NACK please refer to the
COMMAND manual to fix the problem.

END

648

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.135

OMN:BSC

Creation of a Scanner
Introduction
The purpose of any performance management activity is to collect data which can be
used to verify the physical and logical configuration of the PLMN, and to localize potential problems as early as possible.
The processes which accumulate data and assemble it for collection and inspection are
called measurement jobs (i.e. Scanners). The administration of measurement jobs
comprises some actions, e.g. creating, deleting, modifying a measurement job, or definition of the measurement jobs scheduling. Each job will collect data at a particular
frequency known as the granularity of the measurement. After the collection it will be
possible to upload performance data to see the results.
Creating a Scanner means to start a measurement campaign over the network.
The Siemens Base Station provides a set of performance measurements for network
surveillance, for both GSM and TD-SCDMA systems. These measurements are partly
compliant to GSM 12.04, partly Siemens proprietary.

If not otherwise specified, considerations in the following apply to both GSM and
TD-SCDMA systems. Possible differences between the two systems (i.e. measures
which regard only GSM or TD-SCDMA) are expressly indicated.
According to their nature, the different types of measurements can be subdivided into
different groups.Each of these groups represents a Scanner Function Type. In the BSS
system different separated MOCs (Managed Object Classes) are defined for the various
scanner function types. As a consequence the following scanners MOCs are defined.
1. Measurements related to the BSC (raw data collected by the BSC); these measurements allow to control the BSC mainly in terms of:

total Intra-BSC Handovers

total Intersystem Handovers from UMTS to GSM
message exchanged with other equipment
processor load

2. Measurements related to BTSs, with raw data collected by the BSC; these measurements substantially concern:

TCH connections (only for GSM)

SDCCH connections (only for GSM)
Resource Units (only for TD-SCDMA)
CCCH channels
Assignment procedures
Intracell Handovers
HSCSD connections
ASCII services (only for GSM)
Paging procedures (only for TD-SCDMA)
Access procedures (only for TD-SCDMA)

3. Measurements related to BTSs incoming handovers (raw data collected by the

BSC).

A30808-X3247-L210-3-7619

649

OMN:BSC

Operation
Base Station Controller

4. Measurements related to BTSs outgoing handovers to internal cells (i.e. cells

belonging to the same BSC), with raw data collected by the BSC.
5. Measurements related to BTSs outgoing handovers to neighbor cells (i.e. cells
belonging to another BSC), with raw data collected by the BSC.
6. Measurements related to BTSs, with raw data collected by the BTSE (i.e. the BTS
equipment); these measurements concerns both paging and access procedures
(only for GSM).
7. Measurements related to correlated DOA and TA measurements (only for
TD-SCDMA).
8. Measurements related to SS7 links (raw data collected by the BSC).
9. Measurements related to air interface channel; the raw data is collected by the BTS
equipment and regards Power and Quality measurements on traffic channels (both
uplink and downlink).
10. Measurements related to BTSMs; the raw data is collected by the BTS equipment
and regards the frames:
BTSE processor load
I-frame measurements over the Abis interface
11. Measurements related to TRXs; these measurements give information about the
TRXs situation in terms of availability and interference; the raw data is collected by
the BSC.
12. Measurements related to timeslot priority per carrier (only for TD-SCDMA).
13. Measurements related to packet switched(GPRS/EDGE) functionalities (raw data
collected by the BSC).
14. Measurements related to Intersystem Handovers from GSM to UMTS .
15. Correlated measurements for TRXs; these measurements regard TRXs data
collected by the BTS equipment, for GSM system only. Customers need
measurements to find network quality problems (interference, coverage,
transmission, power budget) on the air interface. Especially for radio network
optimization and radio network planning activities it is absolutely necessary to
measure the influence and effects on the network quality due to changes introduced
in the network (new parameters, new radio plan). These measurements provide
correlated RXLEV, RXQUAL, timing advance and frame erasure measurement data
per TRX, related to measurement reports (downlink measurements) and BTS
internal measurements (uplink measurements), to find out where quality problems
exist on the air interface. The following investigations are foreseen:

Correlated RXLEV to RXQUAL measurements uplink

Correlated RXLEV to RXQUAL measurements downlink
Correlated RXLEV to Timing Advance (TA) measurements uplink
Correlated RXLEV to Timing Advance (TA) measurements downlink
Correlated Frame Erasure Rate (FER) to RXQUAL measurements uplink

16. Measurements related to Flexible Abis usage with reference to specific EDGE
performances; these measurements regard the usage rate of the different used Abis
subchannels (SUBTSLB), single or concatenated Nx16Kbps timeslots, and the
supervision of the load, performance and availibity of the Abis pool.

650

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Managed Object

Collected data

SCANBSC

Performance Measurement data related to BSC, e.g.

including Intersystem HO from UMTS to GSM and the number
of activated PDCH per BSC. (raw data collected by BSC)

SCANBTS

Performance Measurement data related to BTSs (raw data

collected by BSC)

SCANBTSIHO

Performance Measurement data related to incoming

handovers (raw data collected by BSC)

SCANBTSOHOI

Performance Measurement data related to outgoing

handovers towards internal cells (raw data collected by BSC)

SCANBTSOHON

Performance Measurement data related to outgoing

handovers towards neighbor cells (raw data collected by
BSC)

SCANBTSE

Performance Measurement data related to BTS,e.g. including

some specific measurements related to PS traffic(raw data
collected by BTS)

SCANSS7L

Performance Measurement data related to SS7 links (raw

data collected by BSC)

SCANCHAN

Performance Measurement data related to radio channels

(raw data collected by BTS)

SCANBTSM

Performance Measurement data related to BTSMs (raw data

collected by BTS)

SCANTRX

Performance Measurement data related to transceivers (raw

data collected by BSC)

SCANGPRS

Performance Measurement data related to PS (GPRS/EDGE)

functionalities (raw data collected by BSC)

SCANCTRX

Performance Measurement data related to Correlated TRX

measurements (raw data collected by BTS).

SCANBTSOHOS

Performance Measurement data related to Intersystem HO

from GSM to UMTS (raw data collected by BSC).

SCANFBTSM

Performance Measurement data related to Flexible Abis

usage aimed to support specific EDGE perforamances (raw
data collected by BSC).

Tab. 3.135.1Scanner managed object classes for GSM

A30808-X3247-L210-3-7619

651

OMN:BSC

Operation
Base Station Controller

Managed Object

Collected data

SCANAIRTSTD (*)

Performance Measurement data related to radio channels

(raw data collected by BTSC)

SCANBTSABISTD

Performance Measurement data related to correlated DOA

and TA (raw data collected by BTSC)

SCANBTSTD

Performance Measurement data related to BTSCs (raw data

collected by BSC)

SCANBTSTDIHDO

Performance Measurement data related to incoming

handovers (raw data collected by BSC)

SCANBTSTDOHDOI

Performance Measurement data related to outgoing

handovers towards internal cells (raw data collected by BSC)

SCANBTSTDOHDON

Performance Measurement data related to outgoing

handovers towards neighbor cells (raw data collected by
BSC)

SCANGPRSTD

Performance Measurement data related to GPRS (raw data

collected by BSC)

SCANTRXABISTD

Performance Measurement data related to timeslot priority

per carrier (raw data collected by BTSC)

SCANTRXTD

Performance Measurement data related to transceivers (raw

data collected by BSC)

SCANBTSMTD

Performance Measurement data related to BTSMs (raw data

collected by BTS)

Tab. 3.135.2Scanner managed object classes for TD-SCDMA

(*)For the SCANAIRTSTD MOC please refer to PROC: Creation of a SCANAIRTSTD
object.
Every Scanner object instance (i.e. every measurement job) consists of one or more
measurement types for which it collects measurement data. The measurement type(s)
contained in a Scanner instance may apply to one or more network resources of the
same type, e.g. a measurement job may be related to one or several BTSs. A measurement job will only produce results for the measurement type(s) it contains.
The selected measurement types shall be identical throughout all network resources
observed by a measurement job. For scanner object more instances can be created
either to generate different scanners with different measurements, taken from the same
pool, or to generate different scanners for different network elements of the same type.

The total number of instances for all the scanner related MOCs (GSM ones +
TD-SCDMA ones) in a BSS is limited to 90.
On creating a new measurement scanner instance, the operator creates a new instance
of one MOC object among those previously described. After selecting one of them, the
operator must specify the following attributes:

652

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Attribute

NAME (mandatory)
Measurement List MEASLST (mandatory)

Object List - OBJLST

(mandatory)

granularityPeriod GRANP (optional)

reportType REPMETHD

duration START/STOP
(optional)

A30808-X3247-L210-3-7619

Description
Specifies the instance number of the Scanner (0..89)
Regarding the measurements, when creating a measurement
job the user can:
1) create at the moment a list of measurements (measList
value must be selected);
2) select all the measurements foreseen for this scanner
object (allMeas value must be selected);
Regarding the object list, when creating a scanner instance
the operator can select (without having to select each object
one by one):
1) a group of objects, choosing selectObjects;
2) Automatic Adaptation of Scanner, selecting SelfAdapting item. (see below)
In every listOfObjects attribute that addresses to BTSs, TRXs
or CHANs (AIRTSTDs in case of TD-SCDMA), a new
parameter is introduced. This parameter (btsmId for GSM,
BtsmtdId for TD-SCDMA) identifies the absolute number of
the BTSM involved; under such a BTSM there will be the
related BTSs (and the subordinated TRXs and CHANs or
AIRTSTDs); in fact a BTS is identified by a relative number
inside the BTSM domain, see "1.5.1 Notes on the CREATE
commands".
Defines the rate at which the measurement is collected from
monitored objects during scheduled periods. Supported granularity periods are 5, 15, 30, 60 minutes.
A Scanner can have a reporting "by event" or "by file".
According to the value of this attribute, the BSC will send
measurement data as soon as they are available (reporting by
event) to the RC by a spontaneous message, or will store
them in a log file (reporting by file) on the BSC disk.
There are only two scanner types that allow the reporting
method by event, they are:
- SCANSS7L;
- SCANBSC.
For the other scanner objects reporting by event is not
allowed (because this type of report increase the amount of
information over the O interface); for these objects the
REPMETHD attribute is not present, and the reporting method
will be only by file.
It is used to set the year, the month and the day of start and
end of measurement collection.

653

OMN:BSC

Operation
Base Station Controller

Attribute
scheduling - RECINT
(mandatory)

Description
A schedule determines the time frames during which a
scanner will be active. It is possible to select an alwaysActive,
daily or a weekly scheduling.
- AlwaysActive scheduling says that the scanner will be
always active along all the duration period (if specified, always
otherwise).
- A daily scheduling lets the user specify up to seven time
intervals per day during which the scanner will collect data.
Every day the same time interval will be considered.
- A weekly scheduling lets the user specify a time interval (if
any) for each day of the week.

The CREATE SCANAIRTSTD command includes further parameters. For more details
refer to PROC: Creation of a SCANAIRTSTD object.

Apart from the SCANGPRS and the SCANGPRSTD objects, which may have up to 5
instances (range 0...4), all the other Scanner objects may have up to 90 instances
(range 0...89). In any case, the global number of created scanner instances must not
exceed 90 instances.

AUTOMATIC ADAPTATION OF SCANNER

Scanners on BSC perform an automatic adaption mechanism for the list of monitored
objects. This capability improves the management of performance measurement
campaigns, making easier for an operator to activate measurement jobs (scanners) on
any object of a given kind. As soon as a new object of that kind is created or deleted,
the related measurement will be automatically included or excluded by the scanner.
When automatic adaptation is not used, the same result requires a set of commands
after the object creation/deletion:
1. lock the scanner;
2. change the list of monitored objects via SET (or ADD) command on the scanner;
3. unlock the scanner.
Otherwise, if this manual procedure is not executed, in case of object creation, the new
object is not included in the measurements.
As it is described above, when the operator creates a scanner, first he has to choose a
type of scanner (e.g. SCANBTS). After that he must define a list of objects (i.e. BTS) to
be monitored (using the OBJLST attribute), and a list of measurements (in this case
belonging to the SCANBTS measures pool) to be collected for that specific object (using
the MEASLST attribute). When defining the list of objects to be scanned, the operator
has three different possible choices:
1. select a restricted number of objects;
2. select Automatic Adaptation of Scanners (selfAdapting value).

654

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

When selecting Automatic Adaptation of Scanners, all the configured objects are
observed; besides, these rules will be followed:

on creation of a new object (e.g. on creation of a new BTS), the system will automatically adapt all the scanners which have to observe all objects of that kind (i.e. all the
configured BTS scanners). Additionally in case of creation of a new BTS, all scanners monitoring a BTS which have this BTS as an adjacent cell (ADJC) and which
are configured (with Automatic Adaptation) to monitor all ADJCs will be adapted
also;
automatic adaptation is only performed if all objects of one kind must be observed,
but not in case only a group or range of objects is specified. A group of object corresponding to the full set of objects will be handled as a group, thus will not be subject
to automatic adaptation;
when an object is deleted, the system will automatically adapt all scanners which
have to observe all objects of this kind. Additionally in case of BTS all scanners
monitoring a BTS which have this BTS as an adjacent cell (ADJC), and which are
configured to monitor all ADJCs, will be adapted also. Adaptation in this case
means it will no longer include those instances in the data collection process;
the adaptation may cause (in case of creation of a new object) all concerned scanners to produce partly incomplete scan reports at the end of the next granularity
period. During the adaptation process already running measurements are not
affected.

The automatic adaptation concept is applied only to some of the Managed Object
Classes defined in BSS system (for example it makes no sense in case of BSC
Scanners, being the monitored object just one). Tab. 3.135.3 shows for each Object
Class if self adapting is possible or not.
Object Class

Self Adapting

SCANBSC

NO

SCANBTS

YES

SCANBTSIHO

YES

SCANBTSOHOI

YES

SCANBTSOHON

YES

SCANBTSE

YES

SCANSS7L

YES

SCANCHAN

NO (*)

SCANBTSM

YES

SCANTRX

YES

SCANGPRS

YES

SCANCTRX

YES

SCANBTSOHOS

YES

SCANFBTSM

YES

SCANAIRTSTD

NO

Tab. 3.135.3MOCs supporting or not Automatic Adaptation

A30808-X3247-L210-3-7619

655

OMN:BSC

Operation
Base Station Controller

Object Class

Self Adapting

SCANBTSABISTD

YES

SCANBTSTD

YES

SCANBTSTDIHDO

YES

SCANBTSTDOHDOI

YES

SCANBTSTDOHDON

YES

SCANGPRSTD

YES

SCANTRXABISTD

YES

SCANTRXTD

YES

SCANBTSMTD

YES

Tab. 3.135.3MOCs supporting or not Automatic Adaptation

(*) for this measurement there is a restriction on the max number of measured objects
(CHANnels) per BSC (i.e. 80), hence the automatic adaptation concept is not applicable here: if the number of configured channels per BSC exceeds the threshold, it is
clear that all configured objects cannot be monitored.
SUSPENDING AND RESUMING A MEASUREMENT CAMPAIGN
Suspending a measurement campaign means to stop the data collection for a previously
created scanner. This can be done by means of a LOCK command on Scanner objects.
The resuming command is the UNLOCK command executed on the same Scanner
object for which the LOCK command has been previously executed.
To suspend a measurement campaign, the user must:
1. select a created scanner object instance;
2. execute a LOCK command.
The result of locking a scanner is that its state changes from UNLOCKED to LOCKED,
as for any other object. Moreover, its internal state will change from On-duty to Off-duty,
that means that the data collection is suspended.
To resume a measurement campaign, the user must:
1. select the scanner object instance previously suspended;
2. execute the UNLOCK command.
As soon as the UNLOCK command is sent, the scanner becomes UNLOCKED. The
internal state will remain Off-duty, until the first time mark is reached, then it will be set
at On-duty, starting again the data collection.
DELETION OF A MEASUREMENT CAMPAIGN
To delete a scanner object instance the user must:
1. select a previously created scanner object instance;
2. lock it;
3. execute a DELETE command.

656

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Prerequisites
All the objects which the Scanner refers to must be equipped.
To manage the CREATE command, the LMT must be in Phase 2.
The user must have the visibility level number set at "2".

A30808-X3247-L210-3-7619

657

OMN:BSC

Operation
Base Station Controller

Create a SCAN object instance

To create an instance of a scanner object, enter one of the following commands,

depending on the scanner type you want to create.

b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b

658

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBSC --->

CREATE SCANBSC
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTS --->
CREATE SCANBTS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSIHO --->
CREATE SCANBTSIHO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOI --->
CREATE SCANBTSOHOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHON --->
CREATE SCANBTSOHON
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSE --->
CREATE SCANBTSE
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANSS7L --->
CREATE SCANSS7L
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCHAN --->
CREATE SCANCHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSM --->
CREATE SCANBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRX --->
CREATE SCANTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRS --->
CREATE SCANGPRS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCTRX --->
CREATE SCANCTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOS --->
CREATE SCANBTSOHOS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANFBTSM --->
CREATE SCANFBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSABISTD --->
CREATE SCANBTSABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTD --->
CREATE SCANBTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDIHDO --->
CREATE SCANBTSTDIHDO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDOI --->
CREATE SCANBTSTDOHDOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDON --->
CREATE SCANBTSTDOHDON
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRSTD --->
CREATE SCANGPRSTD

A30808-X3247-L210-3-7619

Operation
Base Station Controller

b
b
b

OMN:BSC

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXABISTD --->

CREATE SCANTRXABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXTD --->
CREATE SCANTRXTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSMTD --->
CREATE SCANBTSMTD

Result: the created scanner object assumes the state unlocked/enabled,

off-duty. When the next 5-minutes interval is reached, the state changes to on
duty, which means that performance measurement data are collected.

END

A30808-X3247-L210-3-7619

659

OMN:BSC

660

Operation
Base Station Controller

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.136

OMN:BSC

Creation of a SCANAIRTSTD object

Introduction
This procedure allows to create a measurement campaign related to a TD-SCDMA Air
Interface Timeslot.

For general information regarding Scanner objects see PROC: Creation of a Scanner.

Measurements related to TD-SCDMA Air Interface Timeslot are Power and Quality
measurements performed on traffic channels (both uplink and downlink); the raw data is
collected by the BTS equipment.
This group of measurements represents a Scanner Function Type. In the BSS system
the SCANAIRTSTD MOC has been defined for this Scanner Function Type.
On creating a new measurement scanner instance, the operator creates a new instance
of the SCANAIRTSTD MOC object. The following attributes must be specified by the
operator:

Attribute

NAME (mandatory)
Measurement List MEASLST
(mandatory)
Object List - OBJLST
(mandatory)

granularityPeriod GRANP (optional)

duration START/STOP
(optional)
scheduling - RECINT
(mandatory)

A30808-X3247-L210-3-7619

Description
Specifies the instance number of the Scanner (0..89)
When creating a measurement job the user has to create at
the moment a list of measurements, selecting them among the
available ones;
Regarding the object list, when creating a scanner instance
the operator can select a group of objects (up to a maximum
of 10).
The parameter BtsmTdId identifies the absolute number of the
BTSM involved; under such a BTSM there will be the related
BTSs (and the subordinated TRXs and AIRTSTDs); in fact a
BTS is identified by a relative number inside the BTSM
domain, see "1.5.1 Notes on the CREATE commands".
Defines the rate at which the measurement is collected from
monitored objects during scheduled periods. Supported
granularity periods are 15, 30, 60 minutes.
It is used to set the year, the month and the day of start and
end of measurement collection.
A schedule determines the time frames during which a
scanner will be active. It is possible to select an alwaysActive,
daily or a weekly scheduling.
- AlwaysActive scheduling says that the scanner will be
always active along all the duration period (if specified, always
otherwise).
- A daily scheduling lets the user specify up to seven time
intervals per day during which the scanner will collect data.
Every day the same time interval will be considered.
- A weekly scheduling lets the user specify a time interval (if
any) for each day of the week.

661

OMN:BSC

Operation
Base Station Controller

Attribute

Description

UTRANRSCPR
(optional)
UERSCPR (optional)

This attribute specifies the ranges for counters for

UTRANRSCP measure.
This attribute specifies the ranges for counters for UE RSCP
measure.
UTRANTSISCPR
This attribute specifies the ranges for counters for UTRAN TS
(optional)
RSCP measure.
UETSISCPR
This attribute specifies the ranges for counters for UE TS
(optional)
RSCP measure.
RSSILVR (optional)
This attribute specifies the ranges for counters for RSSI
measure.
TCHBLERR (optional) This attribute specifies the ranges for counters for TCH BLER
Measure measure.
UTRANTXCPR
This attribute specifies the ranges for counters for UTRAN TX
(optional)
CODE POWER measure.
UTRANTXPR
This attribute specifies the ranges for counters for UTRAN TX
(optional)
measure.
UETXPR (optional)
This attribute specifies the ranges for counters for UE TX
POWER measure.
TCHBERR (optional) This attribute specifies the ranges for counters for TCH BER
measure.

The Automatic Adaptation of Scanner function is not foreseen for the SCANAIRTSTD
object.

SUSPENDING AND RESUMING A MEASUREMENT CAMPAIGN

Suspending a measurement campaign means to stop the data collection for a previously
created scanner. This can be done by means of a LOCK command on the
SCANAIRTSTD object. The resuming command is the UNLOCK command executed on
the same Scanner object for which the LOCK command has been previously executed.
To suspend a measurement campaign, the user must:
1. select a created scanner object instance;
2. execute a LOCK command.
The result of locking a scanner is that its state changes from UNLOCKED to LOCKED,
as for any other object. Moreover, its internal state will change from On-duty to Off-duty,
that means that the data collection is suspended.
To resume a measurement campaign, the user must:
1. select the scanner object instance previously suspended;
2. execute the UNLOCK command.
As soon as the UNLOCK command is sent, the scanner becomes UNLOCKED. The
internal state will remain Off-duty, until the first time mark is reached, then it will be set
at On-duty, starting again the data collection.

662

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

DELETION OF A MEASUREMENT CAMPAIGN

To delete a SCANAIRTSTD object instance the user must:
1. select a previously created SCANAIRTSTD object instance;
2. lock it;
3. execute a DELETE command.
Prerequisites
All the objects which the Scanner refers to must be equipped.
To manage the CREATE command, the LMT must be in Phase 2.
The user must have the visibility level number set at "2".

Choose the type of operation you are interested in

Would you like to create a measurement campaign?
Would you like to suspend a measurement campaign?
Would you like to resume a measurement campaign?
Would you like to delete a measurement campaign?

h ... 2
h ... 3
h ... 4
h ... 5

Create a SCANAIRTSTD object instance

To create an instance of the SCANAIRTSTD object, enter the CREATE

SCANAIRTSTD command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->

CREATE SCANAIRTSTD

Result: the created scanner object assumes the state unlocked/enabled,

off-duty. When the next 5-minutes interval is reached, the state changes to on
duty, which means that performance measurement data are collected.

Suspend a measurement campaign

To suspend a measurement campaign, enter the LOCK Command following the

next sequence of selections:

b
4

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->

LOCK SCANAIRTSTD

h ... END

Resume a measurement campaign

To resume a measurement campaign, enter the UNLOCK Command following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->

UNLOCK UNLOCK SCANAIRTSTD

A30808-X3247-L210-3-7619

h ... END

663

OMN:BSC

Operation
Base Station Controller

Delete a SCANAIRTSTD object

To delete a SCANAIRTSTD, enter the DELETE Command following the next

sequence of selections:

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->

LOCK SCANAIRTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->
DELETE SCANAIRTSTD

END

664

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.137

OMN:BSC

Requesting the Current Measurement Values of a Scanner

Job
Introduction
This procedure enables the operator to get the current measurement values of an active
scanner.
The ACTIVATE SCAN command is used to get the report of the actual values of the
measurements, that have been configured for a specific scanner object instance (see
PROC: Creation of a Scanner). The values reported to the user are those related to the
last period of evaluation (according to granularity period chosen when the scanner has
been created).
This procedure has no effects on the Scanner's setting, nor on its state.
The ACTIVATE command is allowed only for two scanner types, i.e.:

SCANSS7L
SCANBSC

For all the other scanner objects the command is not allowed, because it will increase
the amount of information exchanged on the system.

Please note that when the ACTIVATE SCANSS7L command is executed, objects
created after the end of the last completed 5 minutes period, and before the beginning
of the next 5 minutes period (i.e. object created during the current 5 minutes period) are
not reported.
This means that if the ACTIVATE SCANSS7L command is launched, objects created in
the 5 minutes that occurs from the end of the last 5 minutes period and the end of the
current one are not displayed.
Prerequisites
The LMT must be in Phase 2.
The ACTIVATE SCAN command cannot be activated if another ACTIVATE SCAN is still
active and the corresponding results have not yet completely sent to the operator.

Select the scanner object

Do you want to get current measurements about SCANBSC scanner?
Do you want to get current measurements about SCANSS7L scanner?

h ... 2
h ... 3

Get the current values about a SCANBSC scanner instance

To get the actual measurement values of this active scanner, enter the
ACTIVATE SCANBSC command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBSC --->

ACTIVATE SCANBSC

Result: the current counter values of the interrogated object are displayed on
the LMT. Please note that the counter values are only valid for the exact part of
time of the command execution.

A30808-X3247-L210-3-7619

h ... END

665

OMN:BSC

Operation
Base Station Controller

Get the current values about a SCANSS7L scanner instance

To get the actual measurement values of this active scanner, enter the
ACTIVATE SCANSS7L command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANSS7L --->

ACTIVATE SCANSS7L

Result: the current counter values of the interrogated object are displayed on
the LMT. Please note that the counter values are only valid for the exact part of
time of the command execution.

END

666

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.138

OMN:BSC

Upload of the Measurement Results

Introduction
When a scanner is activated by file, the corresponding measurement results are written
on a measurement file on the BSC disk. The size of this file cannot exceed 6 MBytes
(the maximum size of the log file can be set by the user, but the limit of 6 MBytes cannot
be exceeded).
This procedure allows the user to upload the measurement files from the BSC disk.
The measurement file is a binary file, so its content cannot be read directly; to provide a
clean and well-formatted measurement report, an offline tool is provided in the LMT (see
"3.31 Decoding Log files").
Prerequisites
Measurement files must exist on the disk of the corresponding BSC.
To upload measurement log files on the LMT local disk the LMT must be in Phase 2.

Upload the PM file

Execute the UPLMEAS SCANCO command following the next sequence of

selections:

MANAGED-ELEMENTS ---> BSS-FUNCTIONAL ---> SCANCO ---> UPLMEAS

SCANCO

The next series of fields must be mandatorily filled in:

DESTDIR: specifies the complete destination path of the scanner file created
on LMT
OVERWRITE: it allows to overwrite the already existing file (if identical path
names are used for DESTDIR).
Result: the scanner logfile is uploaded to the specified destination directory in
the LMT (refer to OGL:LMT manual).

END

A30808-X3247-L210-3-7619

667

OMN:BSC

Operation
Base Station Controller

3.139

Changing Attributes of a Measurement Campaign

Introduction
This procedure enables to set the configuration of a Scanner object.
To change the attributes of a measurement campaign, the user must:
1. select a created scanner object instance;
2. lock the object;
3. execute a SET command;
4. unlock the object.
When changing the attributes of a scanner object, the user first has to select the object
instance he wants to modify, using the NAME attribute (this attribute is mandatory).
Then he can choose to change any of the following attributes according to his needs (to
have a detailed explanation about the meaning of these attributes, see PROC: Creation
of a Scanner):

MEASOBJLST;

OBJLST;

GRANP;

REPMETHD (only for SCANBSC and SCANSS7L objects);

START/STOP;

RECINT;

TAREDLVR (only for SCANBTSABISTD object).

If the user wants only to modify the measurements list or the objects list, without
changing any other attribute, he can use the following commands:

ADD command, to add measurements or objects;

REMOVE command, to delete measurements or objects.

When using both of these two last commands, the user must specify, besides the
scanner object instance (NAME attribute), the list of measurements/objects to
add/remove. To specify this information the user must fill in the MEASOBJLST attribute;
this attribute allows him to indicate if he wants to add/remove measurements or objects.
The difference between ADD/REMOVE commands and the SET command is:

if, for example, a SET command is used to add measurements (or objects) to a
scanner instance, the generated command doesnt contain the added measurements (or objects) only, but it contains the complete list of measurements (i.e. the
old ones plus the new ones);

on the contrary using the ADD command, the old list is not overwritten, but it will
upgrade with the new measurements (or objects).

Prerequisites
The Scanner instance must be locked before setting its attributes.
To manage the SET, ADD and REMOVE commands, the NE must be in Phase 2.

668

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The user must have the visibility level number set at "2".

Select the operation you want to do on a scanner object instance

Do you want to change only the measurements list or the objects list?
Do you want to change any other attribute?

A30808-X3247-L210-3-7619

h ... 2
h ... 5

669

OMN:BSC

Operation
Base Station Controller

Lock the scanner object instance you want to change

To lock a scanner object instance, enter one of the following commands,

depending on which scanner type you want to modify.

b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b

670

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBSC --->

LOCK SCANBSC
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTS --->
LOCK SCANBTS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSIHO --->
LOCK SCANBTSIHO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOI --->
LOCK SCANBTSOHOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHON --->
LOCK SCANBTSOHON
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSE --->
LOCK SCANBTSE
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANSS7L --->
LOCK SCANSS7L
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCHAN --->
LOCK SCANCHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSM --->
LOCK SCANBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRX --->
LOCK SCANTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRS --->
LOCK SCANGPRS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCTRX --->
LOCK SCANCTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOS --->
LOCK SCANBTSOHOS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANFBTSM --->
LOCK SCANFBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->
LOCK SCANAIRTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSABISTD --->
LOCK SCANBTSABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTD --->
LOCK SCANBTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDIHDO --->
LOCK SCANBTSTDIHDO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDOI --->
LOCK SCANBTSTDOHDOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDON --->
LOCK SCANBTSTDOHDON

A30808-X3247-L210-3-7619

Operation
Base Station Controller

b
b
b
b

OMN:BSC

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRSTD --->

LOCK SCANGPRSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXABISTD --->
LOCK SCANTRXABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXTD --->
LOCK SCANTRXTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSMTD --->
LOCK SCANBTSMTD

Result: the chosen scanner object instance is locked.

A30808-X3247-L210-3-7619

671

OMN:BSC

Operation
Base Station Controller

Modify attributes (measurements list or objects list) of the selected

scanner object instance

To change the attributes of a scanner object instance, enter one of the following
commands, depending on which scanner type you want to modify.

b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b

672

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBSC --->

ADD SCANBSC
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTS --->
ADD SCANBTS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSIHO --->
ADD SCANBTSIHO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOI --->
ADD SCANBTSOHOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHON --->
ADD SCANBTSOHON
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSE --->
ADD SCANBTSE
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANSS7L --->
ADD SCANSS7L
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCHAN --->
ADD SCANCHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSM --->
ADD SCANBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRX --->
ADD SCANTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRS --->
ADD SCANGPRS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCTRX --->
ADD SCANCTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOS --->
ADD SCANBTSOHOS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANFBTSM --->
ADD SCANFBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->
ADD SCANAIRTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSABISTD --->
ADD SCANBTSABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTD --->
ADD SCANBTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDIHDO --->
ADD SCANBTSTDIHDO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDOI --->
ADD SCANBTSTDOHDOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDON --->

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

ADD SCANBTSTDOHDON

b
b
b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRSTD --->

ADD SCANGPRSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXABISTD --->
ADD SCANTRXABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXTD --->
ADD SCANTRXTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSMTD --->
ADD SCANBTSMTD

Result: the chosen scanner object instance has been modified.

A30808-X3247-L210-3-7619

673

OMN:BSC

Operation
Base Station Controller

Resume data collection for the scanner object instance

To resume data collection for the modified scanner object instance, enter one of
the following commands, depending on which scanner type you have changed.

b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b

674

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBSC --->

UNLOCK SCANBSC
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTS --->
UNLOCK SCANBTS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSIHO --->
UNLOCK SCANBTSIHO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOI --->
UNLOCK SCANBTSOHOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHON --->
UNLOCK SCANBTSOHON
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSE --->
UNLOCK SCANBTSE
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANSS7L --->
UNLOCK SCANSS7L
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCHAN --->
UNLOCK SCANCHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSM --->
UNLOCK SCANBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRX --->
UNLOCK SCANTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRS --->
UNLOCK SCANGPRS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCTRX --->
UNLOCK SCANCTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOS --->
UNLOCK SCANBTSOHOS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANFBTSM --->
UNLOCK SCANFBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->
UNLOCK SCANAIRTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSABISTD --->
UNLOCK SCANBTSABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTD --->
UNLOCK SCANBTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDIHDO --->
UNLOCK SCANBTSTDIHDO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDOI --->
UNLOCK SCANBTSTDOHDOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDON --->
UNLOCK SCANBTSTDOHDON

A30808-X3247-L210-3-7619

Operation
Base Station Controller

b
b
b
b

OMN:BSC

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRSTD --->

UNLOCK SCANGPRSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXABISTD --->
UNLOCK SCANTRXABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXTD --->
UNLOCK SCANTRXTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSMTD --->
UNLOCK SCANBTSMTD

Result: data collection is resumed for the specified scanner.

A30808-X3247-L210-3-7619

h ... END

675

OMN:BSC

Operation
Base Station Controller

Lock the scanner object instance you want to change

To lock a scanner object instance, enter one of the following commands,

depending on which scanner type you want to modify.

b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b

676

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBSC --->

LOCK SCANBSC
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTS --->
LOCK SCANBTS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSIHO --->
LOCK SCANBTSIHO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOI --->
LOCK SCANBTSOHOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHON --->
LOCK SCANBTSOHON
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSE --->
LOCK SCANBTSE
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANSS7L --->
LOCK SCANSS7L
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCHAN --->
LOCK SCANCHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSM --->
LOCK SCANBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRX --->
LOCK SCANTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRS --->
LOCK SCANGPRS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCTRX --->
LOCK SCANCTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOS --->
LOCK SCANBTSOHOS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANFBTSM --->
LOCK SCANFBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->
LOCK SCANAIRTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSABISTD --->
LOCK SCANBTSABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTD --->
LOCK SCANBTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDIHDO --->
LOCK SCANBTSTDIHDO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDOI --->
LOCK SCANBTSTDOHDOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDON --->
LOCK SCANBTSTDOHDON

A30808-X3247-L210-3-7619

Operation
Base Station Controller

b
b
b
b

OMN:BSC

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRSTD --->

LOCK SCANGPRSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXABISTD --->
LOCK SCANTRXABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXTD --->
LOCK SCANTRXTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSMTD --->
LOCK SCANBTSMTD

Result: the chosen scanner object instance is locked.

A30808-X3247-L210-3-7619

677

OMN:BSC

Operation
Base Station Controller

Modify attributes of the selected scanner object instance

To change the attributes of a scanner object instance, enter one of the following
commands, depending on which scanner type you want to modify.

b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b

678

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBSC --->

SET SCANBSC
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTS --->
SET SCANBTS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSIHO --->
SET SCANBTSIHO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOI --->
SET SCANBTSOHOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHON --->
SET SCANBTSOHON
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSE --->
SET SCANBTSE
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANSS7L --->
SET SCANSS7L
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCHAN --->
SET SCANCHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSM --->
SET SCANBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRX --->
SET SCANTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRS --->
SET SCANGPRS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCTRX --->
SET SCANCTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOS --->
SET SCANBTSOHOS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANFBTSM --->
SET SCANFBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->
SET SCANAIRTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSABISTD --->
SET SCANBTSABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTD --->
SET SCANBTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDIHDO --->
SET SCANBTSTDIHDO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDOI --->
SET SCANBTSTDOHDOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDON --->
SET SCANBTSTDOHDON

A30808-X3247-L210-3-7619

Operation
Base Station Controller

b
b
b
b

OMN:BSC

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRSTD --->

SET SCANGPRSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXABISTD --->
SET SCANTRXABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXTD --->
SET SCANTRXTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSMTD --->
SET SCANBTSMTD

Result: the chosen scanner object instance has been modified.

A30808-X3247-L210-3-7619

679

OMN:BSC

Operation
Base Station Controller

Resume data collection for the scanner object instance

To resume data collection for the modified scanner object instance, enter one of
the following commands, depending on which scanner type you have changed.

b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b

680

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBSC --->

UNLOCK SCANBSC
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTS --->
UNLOCK SCANBTS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSIHO --->
UNLOCK SCANBTSIHO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOI --->
UNLOCK SCANBTSOHOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHON --->
UNLOCK SCANBTSOHON
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSE --->
UNLOCK SCANBTSE
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANSS7L --->
UNLOCK SCANSS7L
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCHAN --->
UNLOCK SCANCHAN
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSM --->
UNLOCK SCANBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRX --->
UNLOCK SCANTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRS --->
UNLOCK SCANGPRS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCTRX --->
UNLOCK SCANCTRX
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSOHOS --->
UNLOCK SCANBTSOHOS
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANFBTSM --->
UNLOCK SCANFBTSM
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANAIRTSTD --->
UNLOCK SCANAIRTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSABISTD --->
UNLOCK SCANBTSABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTD --->
UNLOCK SCANBTSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDIHDO --->
UNLOCK SCANBTSTDIHDO
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDOI --->
UNLOCK SCANBTSTDOHDOI
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSTDOHDON --->
UNLOCK SCANBTSTDOHDON

A30808-X3247-L210-3-7619

Operation
Base Station Controller

b
b
b
b

OMN:BSC

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANGPRSTD --->

UNLOCK SCANGPRSTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXABISTD --->
UNLOCK SCANTRXABISTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANTRXTD --->
UNLOCK SCANTRXTD
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANBTSMTD --->
UNLOCK SCANBTSMTD

Result: data collection is resumed for the specified scanner

END

A30808-X3247-L210-3-7619

681

OMN:BSC

Operation
Base Station Controller

3.140

Get Info Report Scan Command

Introduction
Due to the fact that it is possible to define up to 90 SCAN objects (instances from 0 to
89), it is needed a way to present the situation of the defined scanners with a single
command.
The Get Info Report Scan Command enables the operator to get a list of the created
scanners and for each scanner the most important information are reported.
The information provided in the report are the following:

general information:

the number of configured scanners

the current Performance Measurement logfile size
the current Performance Measurement temporary logfile size
the maximum Performance Measurement logfile size
the esteem of a daily usage which depends on the number and the attributes of
already configured SCAN objects
the automatic adaptation enabling

information provided for each configured SCAN object:

scanner id
measure class
administrative state
availability state
reporting type
granularity

depending on the report type (by file or by messages):

a daily foreseen file size or a daily foreseen number of measurement reports

start date
stop date
periodicity
amount of objects defined
automatic adaptation activation

Due to the amount of information to be provided, it may be required to produce several

reports.

682

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Activate the report

To activate the Get-Info-Scan-Command, enter the command following the next

sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> SCANCO ---> GETINFO

SCANCO

Result: Activation of the report of the SCAN objects.

GETINFO SCANCO:NAME=SCANCO:0;
(* REPLAY OF THE BSC *)
BSC_CONTROLLER -> LMT_LOCAL
11:41:14 22/03/1999
*** RESPONSE TO JOB 1 ***
GETINFO REPORT ACK SCANCO:
NAME = SCANCO:0
SCANNER DATA VALUES:
NUMBER OF SCANNERS CONFIGURED:

CURRENT SIZE OF TMP FILE:

9 KBYTES

MAXIMUM SIZE OF LOG FILE:

42 KBYTES

SCANNER ATTRIBUTES LIST:

NAME:

BTSMEAS:

ADMINISTRATIVE STATE:

UNLOCKED

AVAILABILITY STATUS:

NONE

GRANULARITY PERIOD:

FIFTEEN_MIN

REPORT TYPE:

BY_EVENT

AUTOMATIC ADAPTION ACTIVATION:

YES

START DATE:

01-JAN-1995

STOP DATE:

31-DEC-2099

PERIOD TYPE:

ALWAYS_ACTIVE

NUMBER OF OBJECTS:

NUMBER OF MEASUREMENTS:

...............................
...............................
...............................
...............................
...............................
...............................
...............................

A30808-X3247-L210-3-7619

683

OMN:BSC

Operation
Base Station Controller

...................................
NAME:

BTSMEAS:

12

ADMINISTRATIVE STATE:

UNLOCKED

AVAILABILITY STATUS:

NONE

GRANULARITY PERIOD:

FIVE_MIN

REPORT TYPE:

BY_FILE

AUTOMATIC ADAPTION ACTIVATION:

YES

START DATE:

31-JAN-1995

STOP DATE:

6-DEC-2099

PERIOD TYPE:

ALWAYS_ACTIVE

NUMBER OF OBJECTS:

NUMBER OF MEASUREMENTS:

END OF REPORTS

END

684

A30808-X3247-L210-3-7619

Operation
Base Station Controller

A30808-X3247-L210-3-7619

OMN:BSC

685

OMN:BSC

Operation
Base Station Controller

3.141

Enabling Performance Measurements Based on Enhanced

Measurement Reports
Introduction
When a mobile station is in dedicated mode, the mobile station regularly sends
MEASUREMENT REPORT messages on the SACCH to the network. These messages
contain measurement results about reception characteristics from the current cell and
from neighbor cells.
To send measurement reports to the network, the mobile station can also use
ENHANCED MEASUREMENT REPORT messages instead of MEASUREMENT
REPORT messages, if that is indicated by the network.
Using ENHANCED MEASUREMENT REPORT messages is possible to achieve a
separate true uplink and downlink Frame Error Rate distribution for all MS using AMR,
based on enhanced measurements. This permits the customer to supervise, with higher
accuracy, the quality on the Air Interface. This fact is very important for the network operation, network planning, network optimization and customer care.
On a cell base, the operator can request the MS to report serving cell and neighbor cell
measurements, with ENHANCED MEASUREMENT REPORT messages, using the
REPTYPE (report type) parameter of the BTS object. This parameter is used to indicate
to the mobile station to use the ENHANCED MEASUREMENT REPORT or MEASUREMENT REPORT messages for reporting, and it can assume two values:

NORMAL: the MS uses the MEASUREMENT REPORT message for reporting;

ENHANCED: the MS uses the ENHANCED MEASUREMENT REPORT message
for reporting if at least one BSIC is allocated to each frequency of the BA list (see
3GPP TS 04.18). Otherwise, the MEASUREMENT REPORT message is used.

MS not capable of sending Enhanced Measurements sends the normal MEASUREMENT REPORT. MS capable of sending Enhanced Measurements shall send the
ENHANCED MEASUREMENT REPORT when it is requested by the network; otherwise
it sends the normal MEASUREMENT REPORT.
In the first step of the Enhanced Measurement Reporting introduction, no algorithmic
changes are necessary. This is achieved by a proper translation of the serving cell information reported in the ENHANCED MEASUREMENT REPORT message on to the
serving cell information, delivered by the normal MEASUREMENT REPORT message.
The translation is interpreted by all the algorithms and features (e.g. performance
management, tracing, power control, handover) that make use of measurement results.
Only from the AMR feature point of view, new measures and counters are available
thanks to the ENHANCED MEASUREMENT REPORT.
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

686

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Enable sending of ENHANCED MEASUREMENT REPORTS

To enable ENHANCED MEASUREMENT REPORTS, enter the SET BTS

command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

SET BTS

Then set to ENHANCED the value of the REPTYP parameter.

Result: ENHANCED MEASUREMENT REPORTS are enabled.

END

A30808-X3247-L210-3-7619

687

OMN:BSC

Operation
Base Station Controller

3.142

Management of Trace Measurement Reports

Introduction
From the operator point of view, in order to reduce the load on the A-bis interface, it is
possible to:
1. enable/disable trace measurement reports sent from the BTS;
2. modify the respective granularity period (i.e. choose as granularity a value equal to
480 msec or multiple of 480 ms).
In order to make use of this feature, its necessary to manage two proprietary attributes:

TRACEMR (traceMeasureReport);

TRACEMG (traceMeasureGranularity).

These two attributes belong to the BSC object; they are described in Tab. 3.142.4
BSC parameter

Purpose

TRACEMR

It is a flag used to enable/disable the

sending of traceMeasureReports from
the BTS. The default value is TRUE

TRACEMG

It identifies the granularity of the traceMeasureReport sent from BTS. The

default value is 1 (corresponding to 480
ms).

Tab. 3.142.4BSC parameters used to manage Trace measurement reports

When the MSC sends to the BSC an IMSI trace request (for a certain connection), specifying the BTS measurement report, then the measurements will be traced only if the
TRACEMR parameter has been enabled. The granularity value (TRACEMG) is included
in the START Trace message, sent from the BSC toward the BTS.

Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Choose the operation you want to do

Would you like to disable Trace Measurement Reports?
Would you like to set the granularity of Trace Measurement Reports?
Would you like to enable Trace Measurement Reports?

688

h ... 5
h ... 4
h ... 2

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Enable Trace Measurement Reports

To enable Trace measurement reports , enter the SET BSC command, following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BSC ---> SET BSC

Then the user must set to TRUE the value of the TRACEMR parameter.
Result: Trace measurement reports are enabled.

Situation
Would you like to set the granularity too?

Y h ... 4
N h ... END

Change the granularity

To change the value of the granularity, enter the SET BSC command, following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BSC ---> SET BSC

Then the user must set the value of the TRACEMG parameter.
Result: the granularity is changed.

h ... END

Disable Trace Measurement Reports

To disable Trace measurement reports, enter the SET BSC command, following
the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BSC ---> SET BSC

Then the user must set to FALSE the value of the TRACEMR parameter.
Result: Trace measurement reports are disabled.

END

A30808-X3247-L210-3-7619

689

OMN:BSC

Operation
Base Station Controller

3.143

Get Info TRACE Command

Introduction
IMSI tracing is defined as the tracing of subscriber's "activities when specific events
occur within the PLMN". Up to 7 IMSI can be put under tracing for a single BSC.
The tracecontrol object class is introduced. This object (see GSM 12.08) provides the
control of the trace collection for the generation of the trace records.
In order to provide the operator with the whole set of information regarding the trace
active in the system the GET_INFO_REPORT:TRACE command is available in the
system with the following information:
GET_INFO_REPORT : TRACE
Trace Control:
tracecontrolID
administrativeState
operationalState
usageState
recordCriteria
List of all active traces
For each trace the following information are given:
Trace Ref.

IMSI

Current File Size

Trace Type

Start Time

xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx

xxxx
xxxx
xxxx
xxxx

xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx

xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx

xxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxx

List of a maximum of the last 5 terminated traces.

Trace Ref.

IMSI

Trace Type

Start Time

Stop Time

xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx

xxxx
xxxx
xxxx
xxxx

xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx

xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx

xxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxx

List of files ready to be uploaded

File Name

File Size

XXXXXXXX.YYY
XXXXXXXX.YYY
XXXXXXXX.YYY

xxxxxxxx
xxxxxxxx
xxxxxxxx

Trace Type fields:

8
7
6
5
Priority
For future BSS Record Type
Indication expansion

690

4
3
MSC Record Type

2
1
Invoking Event

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Priority Indication No Priority means that the trace records shall be stored into a BSC
logfile and not sent immediately to the OMC-B.
SBS supports only No priority indication. Every indication of Priority sent by the MSC
will be converted (internally to the BSC) to No priority.
The SBS shall support the BSS Record Types Basic, Radio and No BSS Trace.
If the BSS Record Type is set toHandover the BSC shall consider this as the BSS
Record Type Radio.
If the record type No BSS Trace is specified the BSC shall stop the related trace.
MSC Record type is not analysed by the SBS.

Information is recorded like it is received into Trace file. For instance, if MSC sends the
information Priority, BSC translates it into No priority, because this condition is the
only one available, but in the file you find Priority.
To get more information about the procedure of IMSI tracing see Appendix D of manual
Operation of OMC-B.

Activate the TRACE report

To activate the Get-Info-Trace-Command, enter the GETINFO TRACE

command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> TRACE ---> GETINFO

TRACE

Result: Activation of the report of the TRACE object (see the CML:BSC manual
to get an example of the result of the command).

END

A30808-X3247-L210-3-7619

691

OMN:BSC

Operation
Base Station Controller

3.144

Activation and Deactivation of a Cell Traffic Recording

Introduction
The Cell traffic recording or Cell Trace (CTR) is introduced in addition to the IMSI Trace,
to better monitor the systems behaviour and the quality of service.
CTR traces a certain number of calls within a specified cell, so is, in contrast with IMSI
trace, resource cell related.
Furthermore CTR is local to the BSS, i.e. neither a trace invocation is received from the
MSC nor the MSC will be informed about any cell tracing activities.
From OMC/LMT the operator activates a cell trace by O & M command specifying the
cell in which the trace shall run. At a given start time the trace commences taking a specified number of calls under tracing. The trace data recorded are temporarily stored in the
BSC.
A new managed object class, always present on BSC, called CTR Control Object
(CTRCO) is introduced; it controls the CTR tracing activities within a BSS and is very
similar to the Trace Control MO of the feature IMSI-Trace -.
Another managed object class called CTRSCHED - very similar to a subset of the
SCAN object class of Performance Measurements - is introduced for scheduling CTR
activities.
The Maximum number of instances of CTRSCHED object is fixed to 32 and each
instance can be created. The maximum number of connections traceable (simultaneously) per BSS is limited to 16. This number includes cell traces as well as IMSI
traces. The maximum number of IMSI traces remains 7. If the maximum number of
active traces is reached and an IMSI trace is invoked from the MSC the IMSI trace has
always precedence over the cell trace.
On this object (CTRSCHED) the allowed data base configuration commands are
CREATE, SET, DELETE, and GET and the allowed administrative commands are
LOCK and UNLOCK.
A cell trace can be started if:
- its administrative state is UNLOCKED
- its operational state is ENABLED
- Cell Traffic Recording is enabled in the BSS (CTRCO is UNLOCKED and ENABLED)
- the scheduled time of the trace schedule is reached
- the target Cell must be Equipped, Unlocked and Enabled
Every object instance of CTRSCHED object class depends on CTRCO. When the
CTRCO object is locked the operational state of every CTRSCHED instance is put in
DISABLE DEPENDENCIES state. When the CTRCO changes its operational state then
also CTRSCHED changes its operational states in the same way.

692

It is not possible to have two kinds of traces for the same connection at the same time.
If - for example - a connection is traced by CTR and an IMSI trace is invoked for exactly
this connection, the cell trace on this connection will be stopped (or even not started).
This will be done even if the maximum number of traced connections is not yet
exceeded.

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

CHANGING ATTRIBUTES OF A CELL TRAFFIC RECORDING

The SET CTRSCHED command allows to set the configuration of the CTRSCHED. This
command is rejected if the maximum number of connections traceable in a BSS would
be exceeded (considering all the scheduled periods).
Before changing the attributes of a CTR it is necessary to lock the CTRSCHED object.
The LOCK CTRSCHED:ctr# command on a cell just under tracing will stop the trace
activities. These activities will restart according to the changed (if any) new scheduled
periods.
After the SET CTRSCHED command the behaviour of the ctr# instance is the same as
after the CREATE CTRSCHED command.
DEACTIVATING, RESUMING AND DELETING A CELL TRAFFIC RECORDING
Deactivating a CTRSCHED means to stop the data collection for a previously created
CTRSCHED. This can be done by means of a lock command.
The resuming command is UNLOCK on the same CTRSCHED.
To delete a CTRSCHED the user must enter a DELETE command.
Additionally a cell trace is automatically terminated in one of the following cases:
- expiry of the operator defined trace scheduling
- the operator enters the LOCK CTRSCHED command on ctr#
- tracing is disabled for the whole BSS (e.g. in case of an overload situation)
- a Bring up or Full initialisation occurs
- the operator enters the load data base command
- the operator locks the CTR Control Object
- occurrence of a system reset, hardware and/or software errors
In the first two cases only the trace of the concerned cell is terminated, in all other cases
(i.e. also in case of an overload situation) all traces within the SBS are terminated.
When a cell trace is stopped a Stop notification message is sent to OMC/LMT.
Prerequisites
All the objects which the CTRSCHED refers to must be equipped.
LMT must be in Phase 2.

Choose the type of operation you are interested in

Would you like to activate a Cell Trace?
Would you like to deactivate a Cell Trace?
Would you like to resume a Cell Trace?
Would you like to delete a Cell Trace?

A30808-X3247-L210-3-7619

h ... 2
h ... 3
h ... 4
h ... 5

693

OMN:BSC

Operation
Base Station Controller

Create a CTRSCHED

To create a CTRSCHED, enter the CREATE CTRSCHED command following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> CTRCO --->

CTRSCHED ---> CREATE CTRSCHED

Cell ID
The cell in which a trace shall be started. The user must indicate the BTSM
absolute number and the BTS relative number (the BTS number is relative to
the BTSM one).
Maximum number of connections traced
This gives the maximum number of connections traced in this particular cell (this
is not to be confused with the maximum number of traces allowed per BSC).
Range (1 .. 16).
Trace Start Date
It is the date of starting trace activities. (This attribute is optional and its default
value is 1-1-1992)
Trace Stop Date
It is the date of stopping trace activities. (This attribute is optional) If not specified the traced must be stopped with a operator command.
Trace Period Type
ALL the trace is always active between the start date and the stop date.
WEEKLY the activation depends from periods list. (this attribute is optional. Its
default value is ALL).
Trace Periods
Consisting of a list of periods, one for every day of the week. Every period has
start time (hour and minute) and trace duration. The trace duration is specified
in minutes..
Trace Record Type
Specifies the kind of data to be collected. Possible values are: message and all.
Note:
The CREATE CTRSCHED command is rejected if the maximum number of
connections traceable in a BSS, considering all the scheduled periods, would be
exceeded (UNSUCCESSFUL_TOO_MANY_TRACES).
A cell trace is started if:
- its administrative state is UNLOCKED
- its operational state is ENABLED.
- Cell Traffic Recording is enabled in the BSS (CTRCO is UNLOCKED and

694

A30808-X3247-L210-3-7619

Operation
Base Station Controller

ENABLED).
- the scheduled time of the trace schedule is reached.
- the target Cell must be equipped, Unlocked and Enabled.
When a cell trace is started a Start notification message is sent to OMC/LMT
and the next n calls coming in the specified cell will be put under tracing, where
n is the maximum number of connections to be traced in the specific cell as
given in the CTRSCHED object.

OMN:BSC

h ... END

Deactivate a CTRSCHED

To deactivate a CTRSCHED, enter the LOCK Command following the next

sequence of selections:

b
4

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> CTRCO --->

CTRSCHED ---> LOCK CTRSCHED

h ... END

Resume a CTRSCHED

To resume a CTRSCHED, enter the UNLOCK Command following the next

sequence of selections:

b
5

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> CTRCO--->

CTRSCHED ---> UNLOCK CTRSCHED

h ... END

Delete a CTRSCHED

To delete a CTRSCHED, enter the DELETE Command following the next

sequence of selections:

b
b

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> CTRCO --->

CTRSCHED ---> LOCK CTRSCHED
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> CTRCO --->
CTRSCHED ---> DELETE CTRSCHED

END

A30808-X3247-L210-3-7619

695

OMN:BSC

Operation
Base Station Controller

3.145

Enabling/Disabling Measurements to Get Smart Carrier

Allocation
Introduction
Today networks are getting more and more full of subscribers and, for capability
reasons, the operators are increasing the numbers of carriers inside each cell,
increasing the numbers of cells and shrinking the cells size. These actions mean an
increase of interference and difficulty of network planning, above all in case of introduction of microcells. The operators need tools to analyse the interference of their network
environments and to determine good frequencies to be used with less interference and
with fewer impacts on the existing frequencies plan.
The Smart Carrier Allocation is a very useful feature in the field of frequency survey and
planning. The purpose of the feature is to get histograms of measurements on frequency
basis and to elaborate them to determine in a ranked list of frequencies the best one to:

substitute an under-test frequency for a microcell; i.e. using a test frequency the user
can find which is the less interferred frequency to configure on the microcell;
change an existing frequency very disturbed by surrounding frequencies;
put in service a carrier that has been foreseen as hardware but it has no frequency
planning done.

To find the best frequency to be used in each one of the previous situations, three
different kinds of measurements can be performed:
1. Normal Measurements (Downlink direction);
2. Busy Cumulative Measurements;
3. Extended Idle Channels Measurements.
Normal Measurements input exploits types of measurements already available, that is,
mobile measurements reports sent to the BTS, including:

the RXLEV of the radio connection on the serving cell;

RXLEV values of the 6 strongest adjacent cell frequencies.

Busy Cumulative Measurements refer to well known measurements made on the busy
channel, such as:

uplink and downlink RXQUAL;

uplink and downlink RXLEV;
Timing Advance (TA).

These 5 measurements are thought in the feeling of cumulative measurements on all

the frequencies, so here are called busy cumulative measurements.
Extended Idle Channel Measurements (E-ICM) are measurements made on channels
in idle state. The measures regard not only frequencies that are normally allocated into
a cell but also other frequencies as required by the operator. The operator must insert
the list of frequencies for E-ICM to put under observation.

696

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

With E-ICM measurements, the frequencies put under observation are both frequencies
normally belonging and not belonging to the cell. The concept of normally belonging to
a cell means here frequency that Network Planning prepares as cell resource and the
concept of normally not belonging to a cell means here frequencies that cannot be
used as resource of a cell, but just used to listen to the radio spectrum around a cell.
To listen to frequencies that normally not belong to a cell, but that are provided by the
operator to the system, the following method is used: the user introduces a list of
frequencies different from those defined using CALL attributes (the frequencies
belonging to a cell are defined using the CALL attributes of the BTS object; there are 64
CALL attributes, from CALLF01 to CALLF64; each attribute defines a frequency on the
cell). The BTS creates itself a Testing Frequency Hopping law, and when E-ICM is
active, and there is at least one channel in idle mode, the BTS forces the Testing
Frequency Hopping law for the idle channels. It is required that the list of frequencies
does not hold adjacent frequencies, that is frequencies that have hardly 200 kHz of
distance.

Normal Measurements inputs for Smart Carrier Allocation

Normal measurements provides two different types of input for Smart Carrier Allocation:
a) RXLEV histogram;
b) C/I histogram

a) RXLEV histogram
The RXLEVs values are divided in 32 sets, i.e. the values are collected in ranges of 2
contiguous values, that is, [0,1], [2,3], .... [62, 63]..
For each frequency, required by the operator, a histogram is foreseen; each histogram
has a resolution of 32 slots or counters, where each one is associated just to one range.
When for a required frequency an RXLEV is reported by a mobile station, it is evaluated
in which range it falls so that the appropriate counter is increased of 1. If a not required
(by the operator) frequency is reported, the RXLEV is discarded.
If the BTS receives a Measurement Report with an RXLEV, related to an adjacent cell
with a BSIC different from the one sent by the BSC, that RXLEV will be discarded and
not used for increasing any histogram.
In case the number of events is very high, a counter overflow could happen: in this case,
any histogram, where a counter overflow is found, is no more evaluated, that is no one
of its counters will be increased anymore. Only the affected histogram(s) will be frozen:
the others will continue to be increased.
If the connection is not on a TCH belonging to the BCCH carrier, the Power Control function could be active. In this last case the RXLEV must be adjusted adding an offset in
dB as the TCH were on the BCCH carrier, without any Power Control applied, that is:
RXLEVadjusted = RXLEV + OFFSET_PWRCTRL
The foreseen size of each counter of the histogram is 2 bytes.

A30808-X3247-L210-3-7619

697

OMN:BSC

Operation
Base Station Controller

b) C/I histogram
The purpose of this calculation is to determine how much interference could be in case
the connection frequency were the adjacent received frequency (j).
For each adjacent frequency (j), the C/I calculation is made as follows:
C/I (j) = 10 log10 (Power connection signal/ Power interfering signal of frequency j)
that being express in logarithmic way that means:
C/I (j) = RXLEV connection_frequency - RXLEV frequency (j)
If the connection is not on a TCH belonging to the BCCH carrier, the Power Control function could be active. In this case the above formula must be corrected by an offset, as
follows:
C/I (j) = RXLEV connection_frequency + OFFSET_PWRCTRL - RXLEV frequency (j)
where OFFSET_PWRCTRL is in dB and it is the difference between BCCH carrier
power and the TCH carrier power that can be subject to Power Control procedure.
The C/I is calculated in dB. The C/I counters vary between 0 and 30 dB by steps of 1
dB, as follows:
C/I values <= 0 dB
0 dB < C/I values <=1 dB
1 dB < C/I values <= 2 dB
..............
29 dB < C/I values <= 30 dB
C/I values > 30dB
For each step there is a counter, that is, there are 32 counters for each interfering
frequency evaluated. For each C/I calculated, it is evaluated the right range where it falls
and the specific counter of the histogram related to the frequency used as I, is increased
of one unit.
If a not required (by the operator) frequency is reported, the RXLEV is discarded and the
related C/I is not calculated.
If the BTS receives a Measurement Report with an RXLEV, related to an adjacent cell
with a BSIC different from the one sent by the BSC, that RXLEV will be discarded and
not used for increasing any histogram.
In case the number of events is very high, a counter overflow could happen: in this case,
any histogram, where a counter overflow is found, is no more evaluated, that is no one
of its counters will be increased anymore. Only the affected histogram(s) will be frozen:
the others will continue. The foreseen size of each counter is 2 bytes.
For instance, if from a Measurement Report the following RXLEV are available:
RXLEV connection = -92 dBm
RXLEV f5 = -88 dBm
RXLEV f12 = -90 dBm
RXLEV f3 = -99 dBm
RXLEV f6 = -100 dBm
RXLEV f9 = -101 dBm
RXLEV f20 = -103 dBm

698

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

and the connection is on BCCH carrier, the C/I are as follows

C/I f5 = - 4dB
C/I f12 = - 2dB
C/I f3 = + 7dB
C/I f6 = + 8dB
C/I f9 = + 9dB
C/I f20 = +11dB.
In the C/I f5 histogram, the position <= 0 dB will be increased of 1.
In the C/I f12 histogram, the position <= 0 dB will be increased of 1.
In the C/I f3 histogram, the position 6 dB < and <= 7 dB will be increased of 1, and so on.
Basic Cumulative Measurements inputs for Smart Carrier Allocation
The operator can also choose to have a complete situation about all the frequencies that
are in use.
For each frequency, 5 busy cumulative histograms are created. The five histograms,
generated for each frequency, are:
1. RXLEV uplink histogram
2. RXLEV downlink histogram
3. RXQUAL uplink histogram
4. RXQUAL downlink histogram
5. Timing Advance (TA) uplink histogram
In this case it is required that for each frequency measured on Uplink by the BTS, the
busy cumulative RXLEV_UL, RXQUAL_UL and TA are updated, increasing the specific
slot where the measured value falls; furthermore measurements returned by the Mobile
Stations on Downlink, for any frequency, must increase the busy cumulative RXLEV_DL
and RXQUAL_DL in the same way.
The range of RXLEV values is [0,63] in step of 1.
The range of RXQUAL values is [0,7] in step of 1.
The range of TA values in [0,63] in step of 1.
The foreseen size for this counters is 4 bytes. The overflow case is treated as seen in
previous paragraphs.

In case of Overlay/Underlay cells, the busy cumulative measurements are separated:

that is one for Overlay cell and one for Underlay cell.

A30808-X3247-L210-3-7619

699

OMN:BSC

Operation
Base Station Controller

Extended Idle Channel Measurements inputs for Smart Carrier Allocation

With these measurements an RXLEV Uplink histogram is generated.
The BTS must measure the RXLEV received on Uplink on idle channels for the required
frequencies. RXLEV_UL are made on burst basis, and for each frequency required by
the operator, the BTS builds an RXLEV_UL histogram.
Every frequency histogram is made dividing the RXLEV values into 32 sets:
0: values < = - 109 dBm
1: -109 dBm < values < = -107 dBm
2: -107 dBm < values ? -105 dBm
........
30: -51 dBm < values < = - 49 dBm
31: values > - 49 dBm
Each one of this sets is associated just to one slot or counter; each counter has size of
4 bytes. When for a required frequency an RXLEV_UL is measured by the BTS, it evaluates in which range it falls, so that the appropriate counter is increased of 1.
In case the number of events is very high, a counter overflow could happen: in this case,
any histogram, where a counter overflow is found, is no more evaluated, that is no one
of its counters will be increased anymore. Only the affected histogram(s) will be frozen:
the others will continue.

CONFIGURATION
The Smart Carrier Allocation feature is introduced in the BSS system by the SCA object.
The related measurements are settable on cell basis; on the containment tree the SCA
object is subordinated to the BTS object.
When creating a new instance of the SCA object, i.e. when the user wants to start to
collect data to make some investigations, the following information must be inserted.
1. NAME attribute: indicates the BTS over which the data must be collected; only one
instance (instance number 0) of the SCA object can be created for each BTS.

It is possible to put under observation up to 250 cells for BSC

2. BAND attribute: it is the GSM band related to the frequencies put under observation;
i.e. when a GSM band is chosen, all the observed frequencies must belong to the
chosen band. The possible values are: P, E, DCS, GSM-R, GSM850 and PCS.
3. The type of input to enable among:
Normal Measurements (ENMDL attribute - Enable Normal Measurements in
Downlink direction); the user can activate this input, setting the ENMDL attribute
to TRUE. If the user chooses this type of input, he can define the list of frequencies to be monitored. He can define up to 32 frequencies, using the NMDLATT
attributes (NMDLATT1, NMDLATT2......NMDLATT32). Each NMDLATT represents a frequency to be monitored, and for each frequency the user must specify
both BCCH and BSIC parameters. Normal measurements are considered the
default input data.

700

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Busy Cumulative Measurements (EBUSYCUM attribute - Enable Busy Cumulative Measurements); the user can activate this input, setting the EBUSYCUM
attribute to TRUE. If the user chooses this type of input, he hasnt to define any
frequency, because all the frequencies that are in use are automatically put under
observation.
Extended Idle Channel Measurements (EEICM attribute - Enable Extended Idle
Channel Measurements); the user can activate this input, setting the EEICM
attribute to TRUE. If the user chooses this type of input, he can define the list of
frequencies to be monitored. He can define up to 32 frequencies, using the
EICFN attributes (EICFN1, EICFN2......EICFN32). Each EICFN represents a
frequency to be monitored, and for each frequency the user must specify the
absolute radio frequency number (ARFCN), in the range 0...1023.
4. The observation period; it is defined by START/STOP attributes. The duration of the
observation period is an operator choice and it might be daily, some days of the
week, weekly or monthly.
5. Scheduling inside the observation period; the activity of measurements collection is
not continuously inside the observation period, the activity works only during the
accumulation period, that is, range of time set by the operator between 6 oclock
a.m. to 12 oclock p.m. It is possible to have up to 4 accumulation times at day. The
user can manage these accumulation periods with ATIME1, ATIME2, ATIME3 and
ATIME4 attributes (each of them represents an accumulation period).
DATA STORAGE
When the feature is activated, following the set recording period, the measurements
begin to be stored.
Three different places are used to store data:

into the BTSs: rough data

into BSC: rough data, frequencies lists (and BSICs only for Normal Measurements)
into the OMCplus: rough data, outputs of elaborations, that is, statistics, the best
frequency or the best ones, the interference matrix.

The upload from BTSs is driven automatically by the BSC by default during the night (e.g
at 3 oclock a.m.) for all the cells under observation.
ELABORATION
All the elaboration is made on the OMCplus.

DISABLING ALL MEASUREMENTS RELATED TO SMART CARRIER ALLOCATION

If the user wants to disable all measurements related to a SCA object previously
created, he has to:
1. lock the SCA object by means of the LOCK SCA command;
2. delete the SCA object by means of the DELETE SCA command.
Prerequisites
The user must have the visibility level number set at "2".

A30808-X3247-L210-3-7619

701

OMN:BSC

Operation
Base Station Controller

The Network Element must be in phase "2".

Choose the type of operation you are interested in

h ... 2
h ... 4
h ... 6
h ... 8

Would you like to collect Normal measurement?

Would you like to collect Busy Cumulative measurement?
Would you like to collect Extended Idle Channel measurement?
Would you like to disable a collection of measurements?

Configure Normal measurements collection

To configure the collection of these measurements, enter the CREATE SCA

command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> CREATE SCA

Then the user must:

- set the ENMDL attribute to TRUE
- choose up to 32 frequencies using NMDLATT attributes.
Result: the SCA object instance is created in LOCKED state.

Start Normal measurements collection

To start measurements collection, enter the UNLOCK SCA command, following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> UNLOCK SCA

Result: the chosen measurements are collected when the scheduled time will
be reached.

h ... END

Configure Busy Cumulative measurements collection

To configure the collection of these measurements, enter the CREATE SCA

command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> CREATE SCA

Then the user must set the EBUSYCUM attribute to TRUE, without selecting
any frequency.

Result: the SCA object instance is created in LOCKED state.

702

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Start Busy Cumulative measurements collection

To start measurements collection, enter the UNLOCK SCA command, following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> UNLOCK SCA

Result: the chosen measurements are collected when the scheduled time will
be reached.

h ... END

Configure Extended Idle Channel measurements collection

To configure the collection of these measurements, enter the CREATE SCA

command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> CREATE SCA

Then the user must:

- set the EEICM attribute to TRUE
- choose up to 32 frequencies using EICFN attributes.
Result: the SCA object instance is created in LOCKED state.

Start Extended Idle Channel measurements collection

To start measurements collection, enter the UNLOCK SCA command, following

the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> UNLOCK SCA

Result: the chosen measurements are collected when the scheduled time will
be reached.

h ... END

Lock the SCA object instance

To lock the object, enter the LOCK SCA command, following the next sequence
of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> LOCK SCA

Result: the SCA object is locked.

A30808-X3247-L210-3-7619

703

OMN:BSC

Operation
Base Station Controller

Delete measurements collection

To delete the collection of measurements, enter the DELETE SCA command,

following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> DELETE SCA

Result: the measurements are not collected anymore.

END

704

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.146

OMN:BSC

Upload of Smart Carrier Allocation Measurements

Introduction
The procedure allows to upload measurements related to Smart Carrier Allocation (see
"3.145 Enabling/Disabling Measurements to Get Smart Carrier Allocation").
A new directory (called SCA_TMP) is introduced in the BSC disk in order to store the
measurements temporary files. When the files are closed, they assume .log extension;
they are now ready to be uploaded automatically by the OMC. Before uploading they
are moved to the UPL_READY directory.
The naming convention for the Smart Carrier Allocation log files is:
SCAmmbb
where: mm =<btsm> and nn =<bts>
The measurements files can also be uploaded manually from the LMT, using the
UPLOADREQ SCA command.
Using this command the user must indicate the following (mandatory) fields:
1. NAME: it is the SCA object instance to be uploaded;
2. DESTDIR: it allows to specify the LMT directory in which the measurement file must
be put;
3. FILE: it is the name of the file to be uploaded;
4. OVERWRITE: it allows or not to overwrite existing files.
Prerequisites
The user must have the visibility level number set to "2".
The Network Element must be in phase "2".

Upload Smart Carrier Allocation measurements

To upload measurements related to one SCA object instance, enter the UPLOADREQ SCA command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS ---> SCA

----> UPLOADREQ SCA

Result: measurements related to the selected SCA object instance are transferred to the LMT.

END

A30808-X3247-L210-3-7619

705

OMN:BSC

Operation
Base Station Controller

3.147

Management of Online RF Loop Back

Introduction
The feature "Online RF Loop Back" enables the operator to test the complete RF signal
path of a BTSE including the cabling and connectors. It allows to increase the test
coverage of the RF signal paths of a BTSE and to reliably detect any malfunction on
TRX/carrier level.
Malfunctions to be detected are:

any failures of HW components which constitute the RF-TX and RF-RX signal path
(e.g. reduced PA output power, decreased sensitivity of a RXMUCO/RXAMCO,
etc.);

interconnection/cabling failures between the RF components and the antenna.

This is achieved by utilizing standard measurements that are run by the BTSE and the
mobile subscriber, for the uplink and downlink paths, during user calls.The signal path
supervision can be activated on cell basis for all the TRXs configured on the selected
cell.
Whilst a call is in progress the BTSE gathers a series of measurements related to the
call. These measurements are currently used for various purposes including handover
decisions and power control. For "Online RF Loop Back" four of these measurements
are used:
1. the power generated by the BTS transmitter on the downlink channel (hereafter the
term BSPOWER is used);
2. the power generated by the MS transmitter on the uplink channels. It is reported in
the layer-1 header of a SACCH multiframe (hereafter the term MSPOWER is used);
3. the received signal strength detected by the BTS receiver on the uplink channels
(hereafter the term RXLEV_UL is used);
4. the signal strength, detected by the MS receiver on the downlink channel, reported
in the measurement report that is periodically sent with each SACCH multiframe
(hereafter the term RXLEV_DL is used).
Taken together, measurements 1 and 4 define the path loss on the downlink direction
while measurements 2 and 3 define the path loss on the uplink direction. In principle the
path loss on the uplink and the downlink directions should be the same, so a discrepancy between them can be taken to be indicative of a problem.
If a user defined alarm threshold is exceeded, immediately an alarm will be sent for the
affected carrier. The alarm message does not clearly report the precise failure cause,
but indicates in a general way that the RF-TX/RX signal path of the concerned carrier
shows a service degradation. In case of an alarm condition the operator has the possibility to upload the pre-processed (by the BTSE) data.
Measurement Report to RF-TX/RX Path Correlation
In order to be able to trace back the failure cause, there must be a one to one correlation
between the measurement report and the used RF-TX/RX paths. The measurement
report of the mobile is repeatedly sent (every SACCH frame= 480ms) for a user call in
progress.

706

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

For each user call a resource of a TRX is allocated. The TRX in turn is assigned to a
carrier unit of the BTSE: in case of BTS1 the carrier unit is formed by the module pairing
BBSIG, TPU and PA, while in case of the BTSplus family the carrier unit is formed by the
CU/CA module. Each carrier unit is now again connected to specific RF equipment.
Nevertheless a major aspect have to be considered. In principle a mapping of the
measured data to a RF-TX/RX pairing is obviously possible. However, two further
aspects have to be considered in this context:
1. frequency hopping;
2. receiver diversity
For frequency hopping two methods can be employed:

synthesizer frequency hopping: it is realized by means of non frequency selective

combining equipment (e.g. DUAMCO) and a broadband transceiver. This means
that the signal uses the same RF-TX/RX paths regardless whether frequency
hopping is switched on or off.

baseband frequency hopping: it is used in combination with narrowband RF equipment, and multiplexes the user signal between the frequency selective synthesizers
from timeslot to timeslot or from TDMA burst to TDMA burst respectively. The implementation of frequency baseband hopping shows the following difference regarding
the two BTSE generations, i.e. BTS1 and BTSplus:
in the BTS1 baseband hopping is realized by multiplexing different TPUs to one
BBSIG. The TX and RX paths are tied together by switching TX & RX at the same
time;
the BTSplus' implementation is different to the BTS1. Here baseband hopping is
exclusively used in downlink direction whereas in uplink direction always synthesizer hopping is applied. Downlink data is preprocessed in the TRX related CU,
but the burst data is then sent via the CU whose carrier frequency is equal to that
of the currently calculated burst. Thus, for a call, a single RX path is used with
multiple TX paths; so there are as many TX/RX pairings for the call as the number
of transmitters in use.

Since the mobile reports the measured RXLEV_DL values with a fixed period of 480ms
(= 104TDMA bursts), no mapping is possible on TDMA burst base for the DL measurements. Due to the averaging effect this means now that failures in the RF- TX signal path
which are located in carrier specific parts may not be reliably detected in case baseband
hopping is applied (both for BTS1 and BTSplus). In fact the MS will report an RXLEV_DL
value which is the average of levels received from different RF-TX equipment (and so
from different paths). On the other side, in uplink direction the BTSE knows which RX
path is used per received burst.
In case of receiver diversity the measured receive levels can not unambiguously be
mapped to a physical RX path (diversity= MAX function of RXLEV_regular and
RXLEV_diversity). However in this case the feature "RX alarm for diversity branch"
generates an alarm and helps to localize the failure.

Path Loss Calculation

In downlink direction the path loss is calculated as follows:

A30808-X3247-L210-3-7619

707

OMN:BSC

Operation
Base Station Controller

PLDL= BSPOWER RXLEV_DL

In uplink direction the path loss is calculated as follows:

PLUL= MSPOWER RXLEV_UL

To be able to calculate the path loss, the used data must be normalized to a common
base. The selected base shall be the antenna input/output on either side of the air interface.
MSPOWER and RXLEV_DL sent by the mobile station are already calibrated to the
base of the mobile's antenna; so no further calibration is necessary.
RXLEV_UL is the measured received signal level in the BTSE, corrected by the rxLevAdjust parameter. The rxLevAdjust parameter compensates the attenuation caused by
the RF cabling and by the TMA, if it is used. The parameter is set by the operator; after
that no further calibration is necessary.
BSPOWER must be calculated applying the following formula:

BSPOWER = typeOfPA txPwrMaxReduction bs_pl txLevAdjust (for BTS1);

BSPOWER = outputPower txPwrMaxReduction bs_pl txLevAdjust (for
eMICRO and picoBTS);
BSPOWER = maxOutputPowerPA txPwrMaxReduction bs_pl txLevAdjust (for
all the other BTSE types).

Tab. 3.147.5 shows the meaning of the previous parameters:

Parameter

Meaning

maxOutputPowerPA

specifies the power class of the PA and thus the

maximum output power of the used PA equipment

typeOfPA

PA type

txPwrMaxReduction

the static power control factor denotes the count of

2dB power reduction steps as defined in GSM
05.05

bs_pl

dynamic power control factor

txLevAdjust

pre-set parameter of the TX-path which compensates attenuation effects caused by combiner
equipment and RF cabling, and amplification
effects of optionally used booster equipment

Tab. 3.147.5Parameters related to BSPOWER calculation

The operator is requested to set a reasonable value for txLevAdjust. The value is calculated by the following formula:

txLevAdjust= Attenuation Factor of used Combiner + Attenuation Factor of RF Cable

Amplification Factor of the used Booster

708

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

It is in the responsibility of the operator to add the attenuation figure measured for the
RF cabling and to consider amplification effects of used OEM booster equipments.

If the switched beam/smart antenna feature is enabled (see 3.116), the path loss evaluation algorithm of the Online RF loopback feature considers the gainCompensationSubsec attribute when using full sector, and the txLevAdjustSubsectors one when
using sub sector in TX direction at uplink/downlink path loss calulation.
The level correction factor for the uplink (attribute rxLevAdjustSubsectors of the CU
object) is already compensated by the BTS.

Data Accumulation and Processing

Providing each calculation is made on the basis of at least 50 calls, during which at least
minimum 200 measurement samples must be accumulated. The assumption is that the
differences due to tolerances and due to fading effects in the mobile station cancel out.
Then a margin for safety shall be added, and the computed path loss difference must
exceed minimum 14 dB difference until an alarm is produced.
Each time a data set is obtained for a call in progress the data is used to obtain uplink
and downlink path loss figures.
When baseband frequency hopping is not applied this happen every 480ms, i.e. with
each received SACCH multiframe.
When baseband frequency hopping is applied, and the BTSE is a member of the BTS1
family, then the path loss calculation shall be triggered with every TDMA frame, to
monitor at least the uplink signal path on a burst base (with BTsplus this is not necessary
because in the uplink direction synthesizer frequency hopping is used, so the RX path
doesnt change every TDMA frame).
The system keeps the data in 48 data blocks, collecting the measurements with a
timespan of 30 min (in this way data of one day is collected). For each data block the
data is accumulated for each possible TX/RX paring in the BTS. The result is a 2 dimensional array with dimensions of data block number and TX/RX pairing
(see Fig. 3.147.7). Each entry contains 3 data items:

an accumulation of the path loss differences;

a count of the number of measurements recorded;
a count of the number of calls used in accumulating the data.

The BTS maintains two measurement files for the RF loop back feature. One for the
current day and one for the past day. If the 48th data block has been completed, the
system switches to the second file.

A30808-X3247-L210-3-7619

709

OMN:BSC

Operation
Base Station Controller

Fig. 3.147.7 RF Online Loop Back database structure.

A TX/RX pairing refers to a particular combination of transmitter and receiver hardware,
used to support a call. In case of baseband hopping it may be that a given call will use
more than one transmitter and receiver. Since in TX direction it is not possible to resolve
the used signal path (RXLEV_DL is sent each 480ms within a SACCH frame), actually
there is just a grouping according to the used RX signal path. Since BTSplus applies
if frequency hopping is enabled - always synthesizer hopping in uplink direction (i.e. the
RX path is always the same), the classification in TX/RX pairings is only useful for BTS1.
In case of BTSplus and in case baseband hopping is not applied there is just a single
TX/RX pairing.
The sequence of steps for each data set of a call is:
1. calculate uplink path loss from MSPOWER and RXLEV_UL;
2. calculate downlink path loss from BSPOWER and RXLEV_DL. For BSPOWER
consider the BTS transmitter normalization data;
3. calculate the path loss difference;
4. determine the appropriate array entry from the data block, the TX/RX pairing associated with the call whose frame data is being processed.
5. add the path loss difference to the accumulated path loss field of the selected array
entry.
6. increment the measurement count field of the selected array entry;
7. if this is the first time this array entry has been selected for the current call then increment the call count field.

710

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Before starting of a new data block, all array fields associated with the new data block
are reset to zero. Immediately after the start of a new data block the accumulated data
are processed. The data is processed for each combination of TX/RX pairing. For each
entry, the data is analysed back in time, until the accumulated call count, and the
measurement sample count over the entire range, exceed the defined pre-set values,
which are respectively:

RFLMinCallCount (i.e. minimum number of calls to be monitored);

RFLMinMeasCount (i.e. minimum number of samples to be collected).

The initial recommendation for the minimum call count is 50, for the minimum measurement count 200 and for the alarm threshold 30dB.
The average path loss difference over that range is then calculated (sum of selected
path loss fields/sum of measurement count fields). If the average path loss difference
exceeds the alarm threshold value an alarm is raised.
An alarm shall only be sent once, i.e. if the alarm threshold is repeatedly violated and
an alarm is already outstanding no further failure event report shall be generated.
The alarm is ceased:

if with the beginning of a new data block the alarm condition is not fulfilled anymore;

if RF loop back measurements are locked;

at the end of scheduling;

if the CU goes in disabled state (e.g. when the CU is locked or when either the
related DUVSWR or the DUVSWR transmitting the TRX0 is locked).

A hysteresis function is also provided to avoid oscillations. It is possible to define the

bandwidth of the hysteresis via a RLFbandwithOfHysteresis parameter.
A new directory (called RFLOOP_TMP) is introduced in the BSC disk in order to store
the RFLOOP temporary files. When the files are closed (.log extension) they are ready
to be uploaded automatically by the Radio Commander; before uploading they are
moved to the UPL_READY directory.
The naming convention for the RFLOOP log files is:

RFmmbb
where: mm =<btsm> and nn =<bts>

The user will be able to enable or disable automatic upload from the Radio Commander.
The periodical upload will be performed only if no other upload processes (like those for
Smart Carrier Allocation) are executed at the same time.
In case of manual upload from the LMT, the accumulated data since the last periodic
upload (by the Radio Commander) is transferred to the LMT; if periodical upload was
disabled, the data of the last 24 hours are taken.

A30808-X3247-L210-3-7619

711

OMN:BSC

Operation
Base Station Controller

Configuration
To enable online RF loop back measurements a new managed object is introduced: it
is called RFLOOP. It is subordinate to the BTS object; when creating an instance of this
object the user enables the measurements on all the TRX belonging to the cell.
On creating a new RFLOOP instance, the user specifies the following attributes (only
the NAME attribute is mandatory):
1. NAME: it indicates the cell on which measurements collection shall be activated;
2. START (StartDate): date when collection shall start;
3. STOP (StopDate): date when collection shall finish;
4. ALTH (RFLAlarmThreshold): specifies the alarm threshold;
5. MINCCNT (RFLMinCallCount): specifies the minimum required call count;
6. MECNT (RFLMinMeasCount): specifies the minimum required measurement
samples;
7. RXLV (RFLMinRXLEV): specifies above which level RXLEV values are taken into
account;
8. AUTOREP (RFLAutoReport): automatic file upload enabled/disabled;
9. BANDOFHYS (RFLbandwidthOfHysteresis): specifies the bandwidth of the hysteresis to avoid oscillating alarms. The following relationship must be respected:

RFLbandwidthOfHysteresis < RFLAlarmThreshold

Prerequisites
The instance of the RFLOOP object must not be already created
The superordinate BTSM and BTS must be already equipped
The user must have the visibility level number set to "2".
The Network Element must be in phase "2"

Choose the operation

Would you like to enable RF loop back measurement?
Would you like to disable RF loop back measurement?
Would you like to upload RF loop back measurement?

712

h ... 2
h ... 4
h ... 6

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Create an RFLOOP instance

To configure RF loop back measurements over one cell, enter the CREATE
RFLOOP command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

RFLOOP ----> CREATE RFLOOP

Result: measurements are configured on all the TRX belonging to the selected
cell. The RFLOOP object is in LOCKED state.

Start RFLOOP measurements

To start RF loop back measurements over the cell, enter the UNLOCK RFLOOP
command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

RFLOOP ----> UNLOCK RFLOOP

Result: measurements are enabled on all the TRX belonging to the selected
cell.

h ... END

Lock the RFLOOP instance

To lock the RF loop back measurements over one cell, enter the LOCK
RFLOOP command, following the next sequence of selections:

b
5

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

RFLOOP ----> LOCK RFLOOP
Delete the RFLOOP instance

To delete the RF loop back measurements over one cell, the user must enter the
DELETE RFLOOP command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

RFLOOP ----> DELETE RFLOOP

Result: measurements are no longer taken on all the TRX belonging to the
selected cell.

h ... END

Upload measurements

To upload RF loop back measurements, enter the UPLOADREQ RFLOOP

command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL---> BTSM ---> BTS --->

RFLOOP ----> UPLOADREQ RFLOOP

Result: measurements are transferred to the LMT.

END

A30808-X3247-L210-3-7619

713

OMN:BSC

Operation
Base Station Controller

3.148

Creation or Deletion of a Remote Object

Introduction
When using the Interworking mode (see "1.6 Support of different HW generations of
network entities"), it is possible to create or delete some remote objects belonging to:

BTSE equipment coming from the different BTSE families;

TRAU equipment.

The remote objects, belonging to BTSE equipment, that the user can create/delete from
BSC are shown in Tab. 3.148.6 (see "1.6 Support of different HW generations of
network entities" to know which objects are supported from the different BTSE equipment).
Object

Complete name of the Object

ACDC

AC/DC Converter

ACDCP

AC/DC modules

ACOM

Antenna combiner / transmit antenna module

ACT

Allarm Collector Terminal

ANTENNA

Antenna for TD-SCDMA

BATTERY

BTS Battery

BBSIG

Base Band and Signalling Unit

BPORT

BTS Bi-port

CA

Carrier Agent

CCINT

CC* link interface at server side

CCSLINK

CC* link

COBA

Core Base

COSA

Core Satellite

CU

Carrier Unit

DCREFE

DC/DC for CC* link interface at server side

DIDCTMA

CD Power Supply Module of TMA

DILNA

Low Noise Amplifier of a Diversity Multicoupler

DUCTMA

DC Power Supply Module of TMA

DULNA

Low Noise Amplifier of a Duplex Combiner

DUVSWR

VSWR of a Duplex Combiner

ENVABTSE

Environmental Alarms

FAN

Fan Unit

FANP

Fan Unit

FTNF

Tunable Narrow band Filter of a FICOM

Tab. 3.148.6BTSE objects that can be created/deleted

714

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Object

Complete name of the Object

FTNFP

Tunable Narrow band Filter of a FICOM

FVSWR

VSWR of a Fiter Combiner

FVSWR

VSWR of a Fiter Combiner

GPS

GPS Module

LMU

Location Measurement Unit

LPDLE

LAPD timeslot at BTSE side

MCPA

Multi Carrier Power Amplifier

PA

Power Amplifier

RACK

Rack corresponding to the BTSE

RFMAIN

RFTRXU main board

RFRXPATH

Single RX-Path of a RFDRXM (Dual Radio

Frequency Receiver) module

RFTXPATH

Single TX-Path of a RFDTXM (Dual Radio Frequency

Transmitter) module

RXAMOD

Receiver Antenna Module

RXMUCO

Receiver multicoupler

SDULNA

Switched Low Noise Amplifier of a Duplex Combiner

SDUSEC

Switched Duamco Sector Antenna

SDUSUBSEC

Switched Duamco Subsector Antenna

SDUTXSW

Switched Duamco TX Switch

SIPROC

Signal Processing Unit for TD-SCDMA

SWIPAMAIN

Main Switched Power Amplifier

SYNCBTSC

Synchronization status of a BTSC

TMA

Tower mounted amplifier

TPU

Transceiver and processor unit

XCONNECT

Cross Connector

Tab. 3.148.6BTSE objects that can be created/deleted

The objects belonging to the TRAU equipment that the user can create /delete from BSC
are shown in Tab. 3.148.7
Object

Complete name of the Object

ENVATRAUE

Environmental Alarms

TRAC

TRAU Card

Tab. 3.148.7TRAUE objects that can be created/deleted

A30808-X3247-L210-3-7619

715

OMN:BSC

Operation
Base Station Controller

Prerequisites
To create the object, the user must have the visibility level number set to "2".

Preliminary Consideration

Do you want to

h ... 2
h ... 3
h ... 4
h ... 5

create an object related to TRAU equipment?

delete an object related to TRAU equipment?
create an object related to BTSE equipment?
delete an object related to BTSE equipment?

Create an object related to TRAU equipment

To create the object, the user must enter the TRAU Interworking tree and then
enter the CREATE <TRAU object> command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUE ---> <TRAU object>

---> CREATE <TRAU object>

where <TRAU object> can be replaced by one of the TRAU objects shown
above.

h ... END

Result: Creation of a the object belonging to TRAU equipment.

Delete an object related to TRAU equipment

To delete the object, the user must enter the TRAU Interworking tree and then
enter the DELETE <TRAU object> command following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUE ---> <TRAU object>

---> DELETE <TRAU object>

where <TRAU object> can be replaced by one of the TRAU objects shown
above.
Result: Deletion of the object related to TRAU equipment.

716

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Create an object related to BTSE equipment

To create the object, the user must enter the BTSE Interworking tree related to
the chosen equipment, and then enter the CREATE <BTSE object> command
following the correct sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <BTSE equipment> --->

<BTSE object> ---> CREATE <BTSE object>

where <BTSE object> can be replaced by one of the BTSE objects shown
above.
Result: Creation of the object belonging to the chosen BTSE equipment.

h ... END

Delete a BTSE object

To delete the object, the user must enter the BTSE Interworking tree related to
the chosen equipment, and then enter the DELETE <BTSE object> command
following the correct sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <BTSE equipment> --->

<BTSE object> ---> DELETE <BTSE object>

where <BTSE object> can be replaced by one of the BTSE objects shown
above.
Result: Deletion of the object belonging to the chosen BTSE equipment.

END

A30808-X3247-L210-3-7619

717

OMN:BSC

Operation
Base Station Controller

3.149

Modification of Some Attributes of a Remote Object

Introduction
When using the Interworking mode (see "1.6 Support of different HW generations of
network entities"), it is possible to change the attributes of some remote objects
belonging to:

BTSE equipment coming from different BTSE families;

TRAU equipment.

The BTSE equipment objects for which the user can set the attributes are shown in
Tab. 3.149.8 (see "1.6 Support of different HW generations of network entities" to know
which objects are supported from the different BTSE equipment).
Object

Complete name of the Object

ACOM

Antenna combiner / transmit antenna module

ANTENNA

Antenna for TD-SCDMA

BBSIG

Base Band and Signalling Unit

BPORT

BTS Bi-port

BTSE

Siemens 1st generation Base Transceiver Station

BTSEC

Siemens BTSE for China

BTSEP

Siemens 2nd generation BTSplus

BTSEPICO

Siemens 2nd generation (picoBTS)

BTSEEM

Siemens 2nd generation (enhanced micro)

CA

Carrier Agent

CCSLINK

CC* link

COBA

Core Base

CU

Carrier Unit

DILNA

Low Noise Amplifier of a Diversity Multicoupler

DULNA

Low Noise Amplifier of a Duplex Combiner

DUVSWR

VSWR of a Duplex Combiner

GPS

GPS Module

LI

Line Interface for BTSE

PA

Power Amplifier

RACK

Rack corresponding to the BTSE

RXMUCO

Receiver multicoupler

SDUTXSW

Switched Duamco TX Switch

SYNCBTSC

Synchronization status of a BTSC

TPU

Transceiver and processor unit

Tab. 3.149.8BTSE objects whose attributes can be changed

718

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Object
XCONNECT

Complete name of the Object

Cross Connector

Tab. 3.149.8BTSE objects whose attributes can be changed

The TRAU equipment objects whose attributes can be changed are shown in
Tab. 3.149.9
Object

Complete name of the Object

ENVATRAUE

Environmental Alarms

TRAUE

TRAU Equipment

Tab. 3.149.9TRAUE objects whose attributes can be changed

Prerequisites
The related object must be already equipped.
To modify some attributes of these objects, the user must have the visibility level number
set to "2".

Preliminary Consideration

Do you want to
set the attributes of an object related to a TRAU equipment
set the attributes of an object related to a BTSE equipment

h ... 2
h ... 3

Set the attributes of an object related to a TRAU equipment.

To set the attributes, the user must enter the TRAU Interworking tree and then
enter the SET <TRAU object> command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUE ---> <TRAU object>

---> SET <TRAU object>

where <TRAU object> can be replaced by one of the TRAU objects shown
above.
Result: Setting the attributes of the chosen object.

A30808-X3247-L210-3-7619

h ... END

719

OMN:BSC

Operation
Base Station Controller

Set the attributes of an object related to a BTSE equipment.

To set the attributes, the user must enter the BTSE Interworking tree related to
the chosen equipment, and then enter the SET <BTSE object> command
following the correct sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <BTSE equipment> --->

<BTSE object> ---> SET <BTSE object>

where <BTSE object> can be replaced by one of the BTSE objects shown
above.
Result: Setting the attributes of the chosen object.

END

720

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.150

OMN:BSC

Obtaining the Attributes of a Remote Object

Introduction
When using the Interworking mode (see "1.6 Support of different HW generations of
network entities"), it is possible to display the attributes of some remote objects
belonging to:

BTSEs coming from different BTSE families;

remote TRAU equipment.

The BTSE remote objects from which the user can display the attributes are shown in
Tab. 3.150.10 (see "1.6 Support of different HW generations of network entities" to
know which objects are supported from the different BTSE equipment).
Object

Complete name of the Object

ACDC

AC/DC Converter

ACDCP

AC/DC modules

ACOM

Antenna combiner / transmit antenna module

ACT

Alarm Collector Terminal

ANTENNA

Antenna for TD-SCDMA

BATTERY

BTS Battery

BBSIG

Base Band and Signalling Unit

BPORT

BTS Bi-port

BTSE

Siemens 1st generation Base Transceiver Station

BTSEP

Siemens 2nd generation BTSplus

BTSEPICO

Siemens 2nd generation (picoBTS)

BTSEEM

Siemens 2nd generation (enhanced micro)

CA

Carrier Agent

CCINT

CC* link interface at server side

CCLK

Common clock for BTSE

CCSLINK

CC* link

CCTRL

Core Controller in BTSE

COBA

Core Base

COSA

Core Satellite

CU

Carrier Unit

DCREFE

DC/DC for CC* link interface at server side

DIDCTMA

CD Power Supply Module of TMA

DILNA

Low Noise Amplifier of a Diversity Multicoupler

DUCTMA

DC Power Supply Module of TMA

Tab. 3.150.10BTSE objects whose attributes can be displayed

A30808-X3247-L210-3-7619

721

OMN:BSC

Operation
Base Station Controller

Object

Complete name of the Object

DULNA

Low Noise Amplifier of a Duplex Combiner

DUVSWR

VSWR of a Duplex Combiner

ENVBTSE

Environmental Alarms

FAN

Fan Unit

FANP

Fan Unit

FTNF

Tunable Narrow band Filter of a FICOM

FTNFP

Tunable Narrow band Filter of a FICOM

FVSWR

VSWR of a Filter Combiner

FVSWRP

VSWR of a Filter Combiner

GPS

GPS Module

GPSU

Generic Power Supply unit for BTSE

LI

Line Interface for BTSE

LMU

Location Measurement Unit

LPDLE

LAPD timeslot at BTSE side

MCPA

Multi Carrier Power Amplifier

PA

Power Amplifier

RACK

Rack corresponding to the BTSE

RXAMOD

Receiver Antenna Module

RFMAIN

RFTRXU main board

RXMUCO

Receiver multicoupler

RFRXPATH

Single RX-Path of a RFDRXM (Dual Radio

Frequency Receiver) module

RFTXPATH

Single TX-Path of a RFDTXM (Dual Radio Frequency

Transmitter) module

SDULNA

Switched Low Noise Amplifier of a Duplex Combiner

SDUSEC

Switched Duamco Sector Antenna

SDUSUBSEC

Switched Duamco Subsector Antenna

SDUTXSW

Switched Duamco TX Switch

SIPROC

Signal Processing Unit for TD-SCDMA

SWIPAMAIN

Main Switched Power Amplifier

SYNCBTSC

Synchronization status of a BTSC

TMA

Tower mounted amplifier

TPU

Transceiver and processor unit

XCONNECT

Cross Connector

Tab. 3.150.10BTSE objects whose attributes can be displayed

722

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

The attributes of TRAU objects that the user can get from BSC are shown in
Tab. 3.150.11
Object

Complete name of the Object

ENVTRAUE

Environmental Alarms

TRAC

TRAU Card

BSMS
TPWR
Tab. 3.150.11TRAUE objects whose attributes can be displayed
Prerequisites
The requested objects must be created first.
This command is not dependent on the visibility level.

Preliminary Consideration

Do you want to
get the attributes of an object related to a TRAU equipment
get the attributes of an object related to a BTSE equipment

h ... 2
h ... 3

Get the attributes of an object related to a TRAU equipment

To get the attributes, the user must enter the TRAU Interworking tree and the
enter the GET <TRAU object> command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUE ---> <TRAU object>

---> GET <TRAU object>

where <TRAU object> can be replaced by one of the TRAU objects shown
above.
Result: Getting the attributes of the chosen object.

A30808-X3247-L210-3-7619

h ... END

723

OMN:BSC

Operation
Base Station Controller

Get the attributes of an object related to a BTSE equipment

To get the attributes, the user must enter the BTSE Interworking tree related to
the chosen equipment, and then enter the GET <BTSE object> command
following the correct sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <BTSE equipment> --->

<BTSE object> ---> GET <BTSE object>

where <BTSE object> can be replaced by one of the BTSE objects shown
above.
Result: Getting the attributes of the chosen object.

END

724

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.151

OMN:BSC

Object State Check for Interworking

Introduction
When using the Interworking mode (see "1.6 Support of different HW generations of
network entities"), it is possible to check possible faults related to the remote network
elements.
If the system does not work properly, or if there are some warning lamps switched on
the alarm panel, the user can enter several commands to start a preliminary check of
the BTS or of the TRAU from the BSC.
It is possible to check the state and the status of the selected objects (by entering the
GET <object> STAT command), or to change the administrative or the standby state of
some objects (by entering the LOCK or the UNLOCK commands).
The following useful commands are described in alphabetical order.
GET <object> STAT:

LOCK:

UNLOCK:
GETACTIVEALARMS TRAUE:
SWITCH:

GETSUBO <object>:

This command allows to display the administrative state (Lock, Unlock and Shutting-down),
operational state (Enabled and Disabled), usage
state (Busy, Idle and Active), the status attributes
of a specified object. The statuses are: ALR
(alarm), PRO (procedural), AVB (availability),
CNT (control), UNK (unknown), STB (standby),
SS7 (Ss7 control). This command allows to
display the Alarm Status whose values are:
cleared, Minor, Major and Critical.
This command allows the user to put an object in
the administrative state LOCKED. It can be
rejected due to a high critical state of the system,
so the force parameter allows the user to skip this
critical check.
This command allows the user to put an object in
the administrative state UNLOCKED.
This command allows the user to display active
alarms related to a specified network element.
This command allows for the standby status
exchange of the duplicated object from Providing
Service to Hot Standby and vice versa.
This command allows the user to display subordinate objects related to the following TRAU
objects: TRAC, BSMS, TPWR.

Prerequisites
To enter these commands the selected object must be created, otherwise the response
visualize a UNSUCCESFUL_OBJECT_NOT_EQUIPPED message string.

A30808-X3247-L210-3-7619

725

OMN:BSC

Operation
Base Station Controller

LOCK and UNLOCK:

SWITCH:

The object must be in unlock or lock state respectively,

otherwise the response will be UNSUCCESSFUL
INVALID STATUS.
The selected object must be in enabled- providing service
state and its duplicated copy must be in enable-cold/hot
standby state, otherwise the response message will be
UNSUCCESSFUL INVALID STATUS.

To enter the LOCK, UNLOCK and the SWITCH commands, the user must have the visibility level number set to "1", while the GET <object> STAT command is not dependent
on the visibility level.

Preliminary Consideration

Do you want to

h ... 2
h ... 3
h ... 4

display state, status attributes and Alarm Status of a specified object

change the administrative state from UNLOCKED to LOCKED
change the administrative state from LOCKED to UNLOCKED
display the list of faults concerning the objects monitored by the specified
object alarm lamp

h ... 5
h ... 6
h ... 7

change the standby status of the duplicated object

display a list of direct subordinate objects of a specified object

Display state and status of a specified object

To display state and status of a specified object, the user must enter the Interworking tree related to the chosen equipment (BTSE type or TRAUE) and then
enter the GET <object> STAT command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <equipment> --->

<object> ---> GET <object> STAT
where:
- <equipment> must be replaced by one of the following: TRAUE, BTSE,
BTSEP, BTSEPIC, BTSEEM, BTSEXS or BTSEC.
- <object> is an object of the chosen equipment.

Result: Display of the state and status of a selected objects.

726

h ... END

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Lock an object

To change the administrative state of the object, the user must enter the Interworking tree related to the chosen equipment (BTSE type or TRAUE) and then
enter the LOCK <object> command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <equipment> --->

<object> ---> LOCK < object >
where:
- <equipment> must be replaced by one of the following: TRAUE, BTSE,
BTSEP, BTSEPIC, BTSEEM, BTSEXS or BTSEC.
- <object> is an object of the chosen equipment.

Result: Changing the administrative state from UNLOCKED to LOCKED

h ... END

Unlock an object

To change the administrative state of the object, the user must enter the Interworking tree related to the chosen equipment (BTSE type or TRAUE) and then
enter the UNLOCK <object> command:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <equipment> --->

<object> ---> UNLOCK < object >
where:
- <equipment> must be replaced by one of the following:TRAUE, BTSE, BTSEP,
BTSEPIC, BTSEEM, BTSEXS or BTSEC.
- <object> is an object of the chosen equipment.

Result: Changing the administrative state from LOCKED to UNLOCKED.

h ... END

Display the list of faults concerning the objects monitored by the specified
object alarm lamp

To display the list of faults concerning the objects monitored by the specified
object alarm lamp, the user must enter the Interworking tree related to the
chosen equipment (BTSE type or TRAUE) and then enter the GETACTIVEALARMS <equipment> command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <equipment> --->

GETACTIVEALARMS <equipment>
where <equipment> must be replaced by one of the following:TRAUE, BTSE,
BTSEP, BTSEPIC, BTSEEM, BTSEXS or BTSEC.

Result: Display of a list of faults related to the objects monitored by the specified
object alarm lamp.

A30808-X3247-L210-3-7619

h ... END

727

OMN:BSC

Operation
Base Station Controller

Change the standby status of the duplicated object

To change the standby status of the duplicated object (e.g. BSMS), the user
must enter the Interworking tree related to the chosen equipment (BTSE type or
TRAUE) and then enter the SWITCH <object> command, following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <equipment> --->

<object> ---> SWITCH <object>
where:
- <equipment> must be replaced by one of the following: TRAUE, BTSE,
BTSEP, BTSEPIC, BTSEEM, BTSEXS or BTSEC.
- <object> is an object of the chosen equipment.

h ... END

Result: Changing standby status of the duplicated object.

Display a list of direct subordinate objects of a specified object

To display a list of direct subordinate objects of a specified object, the user must
enter the Interworking tree related to the chosen equipment (BTSE type or
TRAUE) and then enter the GETSUBO <object> command following the next
sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> <equipment> --->

<object> ---> GETSUBO <object>
where:
- <equipment> must be replaced by one of the following: TRAUE, BTSE,
BTSEP, BTSEPIC, BTSEEM, BTSEXS or BTSEC.
- <object> is an object of the chosen equipment.

Result: Display of a list of direct subordinate objects of a specified object.

END

728

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.152

OMN:BSC

Stop Transmission of BTS Frequencies

Introduction
The following paragraph describes some commands the user can enter to stop:
a) transmission of a complete BTS
b) transmission of a BCCH frequency
c) transmission of a TCH frequency.
Prerequisites
None

Preliminary Consideration

Do you want to
stop transmission of a complete BTS (BTS1 family)?
stop transmission of a BCCH frequency (BTS1 family)?
stop transmission of a TCH frequency (BTS1 family)?

h ... 2
h ... 3
h ... 5

Stop transmission of a complete BTS (in case of BTS1 family)

To stop transmission of a complete BTS the user must enter the BTSE Interworking mode; then he has to lock the corresponding Antenna Combiner, using
the LOCK ACOM command, following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSE ---> RACK ---> ACOM

---> LOCK ACOM

Result: Locking the Antenna Combiner

h ... END

Lock the BTS

The user must LOCK the BTS using the LOCK BTS command, following the
next sequence of selections:

MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> BSC ---> BTS ---> LOCK

BTS

Result: Locking BTS.

Stop transmission of a BCCH frequency

To stop transmission of a BCCH frequency the user must enter the BTSE Interworking mode; then he must lock the PA which carries BCCH frequency, using
the LOCK PA command following the next sequence of selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSE ---> RACK ---> PA

--->LOCK PA

Result: the frequency associated to the BCCH is no longer transmitted.

A30808-X3247-L210-3-7619

h ... END

729

OMN:BSC

Operation
Base Station Controller

Stop transmission of a TCH frequency

To stop transmission of a TCH frequency, the user must enter the BTSE Interworking mode; then he must lock the PA using the LOCK PA command following
the next sequence of selections.

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSE ---> RACK ---> PA

--->LOCK PA

Result: Locking PA.

END

730

A30808-X3247-L210-3-7619

Operation
Base Station Controller

3.153

OMN:BSC

Test Commands
Introduction
There follows a presentation of a set of commands used to diagnose a remote hardware
unit, belonging to the BTSM or TRAU.

You can get an exhaustive explanation of how performing a particular test on a particular hardware in the specific Maintenance manuals
These commands can be entered from the BSC.
PERFTEST <object>:

STOPTEST <object>:
GET BSCETEST:

This command is used to start an asynchronous test in

the SBS system. By means of this command, it is
possible to activate a diagnostic test on the hardware
unit. With the force attribute it is possible to request a
hardware object to be put in enable state, that is in
service, at the end of the test, even if the test had negative results.
This command is used to terminate a previously started
diagnostic test. The associated test object will be deleted.
This command is used to retrieve the values of all the
attributes belonging to a specified test object. The test
object is created by the system as a result of the request
to start an asynchronous test.

Test Type

Object

64

ALCO

65

BBSIG

66

CCTRL

67

CCLK

68

LI

70

PA

71

TPU

72

ACOM

73

FAN

74

GPSU

75

RXAMOD

76

RXMUCO

77

ACDC

78

FICOV

79

FICOT

Tab. 3.153.12BTSE Hardware Test

A30808-X3247-L210-3-7619

731

OMN:BSC

Operation
Base Station Controller

Test Type

Object

96

BSMS

97

TRAC

98

TPWR

Tab. 3.153.13TRAUE Hardware Test

Prerequisites
PERFTEST <object>: The object to be diagnosed must be already equipped.
The user must have the visibility level set to the number "1" to enter the PERFTEST and
the STOPTEST commands. The GET BSCETEST command is not dependent on the
visibility level.

Preliminary Consideration

Do you want to

h ... 2
h ... 3
h ... 4

activate a diagnostic test

terminate a diagnostic test
retrieve the values of a test object

Activate a diagnostic test

PERFTEST <object>: The unit to be diagnosed must be placed, through the

LOCK command, in the LOCKED state, that is out of service, if the diagnostic is
intrusive. The object to be diagnosed must be already equipped.
To activate a diagnostic test, the user, after choosing the network element
(TRAUE or one of the available BTSE types) using the Interworking functionality,
must enter the PERFTEST <object> command, following the next sequence of
selections:

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUE --->

PERFTEST TRAUE
(for TRAU equipment)
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> <BTSE Type> --->
PERFTEST <BTSE Type>
(for BTS equipment, where <BTSE Type> must be replaced by one of the
following:BTSE, BTSEP, BTSEPIC, BTSEEM, BTSEXS or BTSEC.)

Result: Activation of a diagnostic test on a hardware unit.

732

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Terminate a diagnostic test

To terminate a diagnostic test previously started, the user must enter the
STOPTEST <object> command following the next sequence of selections (interworking modality):

b
b

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUE ---> STOPTEST

TRAUE
(for TRAU equipment)
MANAGED-ELEMENT ---> BSS-FUNCTIONAL ---> <BTSE Type> --->
STOPTEST <BTSE Type>
(for BTS equipment, where <BTSE type> must be replaced by one of the
following: BTSE, BTSEP, BTSEPIC, BTSEEM, BTSEXS or BTSEC)

Result: Termination of a diagnostic test previously started.

Retrieve the values of a test object

To retrieve the values of all the attributes belonging to a specified test object, the
user must enter the GETTEST command following the next sequence of selections (interworking modality):

b
b

MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> TRAUETEST---> GET

TRAUETESTT
(for TRAU equipment)
MANAGED-ELEMENT ---> BSS-EQUIPMENT ---> BTSETEST --->
GET BTSETEST
(for BTS equipment)

END

A30808-X3247-L210-3-7619

733

OMN:BSC

Operation
Base Station Controller

4 Tables, lists and figures (TAB)

Not relevant for OMN:BSC.

734

A30808-X3247-L210-3-7619

Operation
Base Station Controller

4.1

OMN:BSC

Suspect frames
Not relevant for OMN:BSC.

A30808-X3247-L210-3-7619

735

OMN:BSC

Operation
Base Station Controller

5 Appendices

736

A30808-X3247-L210-3-7619

Operation
Base Station Controller

OMN:BSC

Abbreviations

AMR

Adaptive Multirate

BSC

Base Station Controller

BSCE

Base Station Controller Equipment

CTM

Cellular Text Telephone Mode

GSM

Global System for Mobile Communications

HAND

Handover Recognition

IDF

Inventory Data File

MOC

Managed Object Class

MOI

Managed Object Instance

MSC

Mobile Switching Center

NE

Network Element

PCMT

PCM Trau

PLLH

Phase Locked Loop Oscillator High Performance

PLMN

Public Land Mobile Network

PWRC

Power Control

RC

Radio Commander

SBS

Siemens Base Station

SS7

CCIT Common Channel Signalling n. 7

TRAU

Transcoder and Rate Adaption Unit

UBEX

Universal Bus Extender

UE

User equipment

A30808-X3247-L210-3-7619

737

OMN:BSC

738

Operation
Base Station Controller

A30808-X3247-L210-3-7619