bsc database parameter planning

GERAN-S Database Parameter Planning & Engineering Manual BR9.0 Version 27.04.07 __________________________________________________________________________________________________________

1 / 575 Network Engineering GERAN

GERAN South Network Engineering

BSC Database Planning & Engineering Manual

BR9.0

April 2007

Author: Eckardt Bertermann, Nokia Siemens Networks COO RA RD SA NE



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.



Reason for Update Summary: Document Issue for Release BR9.0.

Details: Chapter/Section Reason for Update

1 (and subchapters) eBSC parameters added, minor corrections

2 (and subchapters) minor corrections

Issue history

Authors In addition to the author named on the cover page the following persons have collaborated on this document:

Name Department Marcin Grygiel COO RA RD SA NE Piotr Grzybowski COO RA RD SA NE Sebastian Lasek COO RA RD SA NE Sebastian ysiak COO RA RD SA NE Andrzej Macioek COO RA RD SA NE Krystian Majchrowicz COO RA RD SA NE Michal Szydeko COO RA RD SA NE

Issue Number

Date of Issue Reason for Update

IUS 1.0 February 2007 First Document Issue for Release BR9.0 after NE internal review (eBSC specific aspects not yet included).

IUS 2.0 April 2007 eBSC enhancements, minor corrections



IMPORTANT This document is not officially released to customers and is designed as

quick reference document for SBS BSC database parameters. This document is a working document and is continuously modified and

enhanced with the latest information. Changes may not be explicitly marked! The documents purpose is to

- describe and explain the meaning of the BSC database parameters - describe and explain the parameters association to related features - provide cross-references between parameters that logically belong together, but are possibly distributed over different objects - provide rules and hints that have to be considered during the decision for the parameter values to guarantee a useful application of the parameter.

The documents purpose is NOT - to provide binding recommendations for parameter value settings! - to be used as a reference database with respect to the parameter settings!! The used settings were not verified for a live netwok application!

NO GUARANTEES FOR CORRECTNESS OF THE CONTENTS! CONTENTS ARE NOT COMMERCIALLY BINDING! Any comments for corrections or suggestions for improvements are welcome!

!



Contents:

1 DATABASE BR9.0 ....................................................................................................................................... 9 1.1 BR9.0 OBJECT TREE OF FUNCTIONAL BSC DATABASE OBJECTS ................................................................. 9 1.2 BSC DATABASE COMMANDS AND PARAMETERS................................................................................. 11

Setting the object entry point and time and date for the BSS:................................................................ 11 Setting the BSC control values for periodic measurement data file upload: .......................................... 11 Setting the timing values for BSSMAP control and BSC overload handling: ......................................... 14 Setting the global parameters of the BSC: ............................................................................................. 25 Creating new database parameters without info model change: ........................................................... 64 Setting the alarm priorities of the BSS functional objects:...................................................................... 65 Setting the remote Inventory data of the BSC Equipment:..................................................................... 68 Setting the alarm priorities of the BSCE objects:.................................................................................... 68 Setting the alarm priorities of the EBSCE objects: ................................................................................. 70 Defining the eBSC configuration:............................................................................................................ 72 Creating the spare PCM interface boards: ............................................................................................. 73 Creating the PCM interface boards: ....................................................................................................... 73 Creating the common attributes for all PCUs belonging to the entire BSC:........................................... 74 Creating the PCU objects: ...................................................................................................................... 81 Creating the Network Service Entity (NSE): ........................................................................................... 82 Creating an SGSN Pool: ......................................................................................................................... 90 Creating the local NSE Virtual Link IP of an NS connection: ................................................................. 91 Creating the remote NSE Virtual Link IP: ............................................................................................... 91 Creating the PCM links for the Abis interface:........................................................................................ 92 Creating the PCMS link:.......................................................................................................................... 96 Creating the TRAU:................................................................................................................................. 98

Basic TRAU-mapping 1: NOT_COMPATIBLE_WITH_CROSSCONNECT (no pools created) ...................... 99 Basic TRAU-mapping 2: COMPATIBLE_WITH_CROSSCONNECT (no pools created) ............................... 99

Creating the LPDLS links:..................................................................................................................... 103 Creating the PCMA link:........................................................................................................................ 104 Setting the uplink and downlink volumes for specific PCMA timeslots:................................................ 110 Creating the PCMG link: ....................................................................................................................... 111 Creating the physical link connection on the GPRS Gb interface (Frame Relay Link): ...................... 113 Creating the end-to-end communication between BSS and SGSN: Network Service Virtual Connection (NSVC):................................................................................................................................................. 114 Creating the BTS Site Manager:........................................................................................................... 115 Creating the Common BTS data of a BTSM for Dynamic MAIO Allocation (DMA):............................. 132 Creating the hopping laws used for Dynamic MAIO Allocation: ........................................................... 137 Creating the LPDLM links: .................................................................................................................... 138 Creating the terrestrial Abis timeslots for flexible Abis allocation: ........................................................ 140 Creating a cell with definition of global parameters: ............................................................................. 145 Setting the cell specific parameters for DMA Admission Control ......................................................... 211 Setting the cell attributes for the Interference Measurement of idle TCHs:.......................................... 223 Setting the cell specific timer values:.................................................................................................... 225 Setting the cell specific optional features:............................................................................................. 235 Defining the cell specific service layer lists for the feature 'Service dependent Channel Allocation' (SDCA) via 'Multi Service Layer Support' (MSLS):............................................................................... 250 Setting the cell specific attributes for Power Control: ........................................................................... 261

Power Control Parameter Relations.................................................................................................................. 274 Creating the GPRS point to point packet transfer service in a cell:...................................................... 275 Creating the cell-specific Frequency Hopping systems for static MAIO Allocation (SMA):.................. 310 Creating the TRXs: ............................................................................................................................... 312 Enabling GPRS and EDGE in a cell: .................................................................................................... 317 Creating the BCCH for the cell: ............................................................................................................ 319 Creating the SDCCHs for the cell: ........................................................................................................ 320 Creating the TCHs for the cell: ............................................................................................................. 322 Creating hybrid TCHs/SDCCHs (TCH/SD) for the cell: ........................................................................ 325 Setting the cell specific parameters and threshold values for CS Handover: ...................................... 330

Handover Parameter Relations......................................................................................................................... 380 Setting the cell specific parameters and threshold values for 14,4kbit/s data call up- and downgrading and quality inter-cell handover:............................................................................................................. 382



Enabling features related to ASCI, SMS-CB, Frequency Hopping, HSCSD, Call Release due to Excessive Distance and Dynamic MAIO Allocation (DMA): ................................................................. 384 Creating the Target Cell Objects: ......................................................................................................... 389 Creating the Target Point-to-point Packet Flow Objects: ..................................................................... 392 Creating the Adjacent Cell Objects:...................................................................................................... 394 Creating the Target Cell Objects for handover from GSM to UMTS (FDD): ........................................ 410 Creating the Adjacent Cell Objects for external UMTS FDD or UMTS TDD cells:............................... 412 Creating the CCS7 level 3 address and basic SCCP parameters of the BSC..................................... 418 Creating the remote CCS7 transport point : ......................................................................................... 421 Creating the remote CCS7 Destination Points (DPCs of MSCs, SMLC etc.): ..................................... 421 Creating the CCS7 link set: .................................................................................................................. 427 Creating the CCS7 link: ........................................................................................................................ 433 Creating the PCMH link: ....................................................................................................................... 434 Creating a Nailed-Up Connection through the BSC/TRAU: ................................................................. 436 Creating an X25 connection via dedicated link:.................................................................................... 437 Creating an X25 connection via A-interface: ........................................................................................ 439 Creating an IP Link connection:............................................................................................................ 441 Creating the O&M link for the RC connection:...................................................................................... 442 Creating the link for the external connection to the SMS-CB system:.................................................. 442 Creating the SDH link for connectivity purposes: ................................................................................. 443 Defining the optical interface (INTF) configuration parameters:........................................................... 444 Creating the ATM Virtual Path (ATMVP): ............................................................................................. 445 Configuration of Bidirectional Continuity Monitors for ATM Virtual Path (BCMATMVP): ..................... 447 Creating the ATM Virtual Channel (ATMVC):....................................................................................... 448 Configuration of Bidirectional Continuity Monitors for ATM Virtual Channels (BCMATMVC): ............. 449 Defining the BSC reference synchronization clock origin:.................................................................... 450 Defining an external synchronization signal: ........................................................................................ 450 Creating the Quality of Service Alarm Objects: .................................................................................... 451 Creating the Quality of Service Alarm threshold sets: .......................................................................... 452 Creating the Quality of Service Alarm Objects for the BSC object:...................................................... 454 Creating the Quality of Service Alarm Objects for BTS objects: .......................................................... 455 Creating the Quality of Service Alarm Objects for PTPPKF objects: ................................................... 459 Activating IMSI tracing in the BSC:....................................................................................................... 461 Creating a Cell Traffic Recording (CTR) job:........................................................................................ 462 Enabling the data recording for the feature 'History on Dropped Calls': .............................................. 464 Defining the BSC environmental alarms:.............................................................................................. 469 Configuring the feature Online RF Loopback: ...................................................................................... 470 Creating Smart Carrier Allocation: ........................................................................................................ 474

2 APPENDIX ................................................................................................................................................. 476 2.1 HANDOVER THRESHOLDS & ALGORITHMS .............................................................................................. 476

2.1.1 Functional Diagram Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and power budget) .................................................................................................................... 476 2.1.2 Rules: Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and power budget), Power Control disabled ............................................................................................... 477

2.1.2.1 Inter-cell/Inter-system Handover due to level ........................................................................................ 477 2.1.2.1.1 Handover Decision / Handover Trigger Conditions ....................................................................... 477 2.1.2.1.2 Target Cell List Generation .......................................................................................................... 478 2.1.2.1.3 Target Cell Ranking (HCS disabled) ............................................................................................. 479 2.1.2.1.4 Target Cell Ranking with HCS....................................................................................................... 482 2.1.2.1.4.1 Ranking of 3G target cells within 3G sublist .............................................................................. 482 2.1.2.1.4.2 Ranking of 2G target cells within 2G sublist - Ranking Method 0 .............................................. 483 2.1.2.1.4.3 Ranking of 2G target cells within 2G sublist - Ranking Method 1 .............................................. 484 2.1.2.1.4. Resulting ranking of 2G and 3G target cells and sublists ............................................................ 485

2.1.2.2 Intra-cell handover (quality).................................................................................................................. 487 2.1.2.3 Inter-cell/Inter-system Handover due to quality .................................................................................... 489

2.1.2.3.1 Handover Decision / Handover Trigger Conditions ...................................................................... 489 2.1.2.3.2 Target Cell List Generation .......................................................................................................... 490 2.1.2.3.3 Target Cell Ranking (HCS disabled) ............................................................................................ 491 2.1.2.3.4 Target Cell Ranking with HCS...................................................................................................... 491

2.1.2.4 Inter-cell/Inter-system Handover due to distance ................................................................................. 492 2.1.2.4.1 Handover Decision / Handover Trigger Conditions ...................................................................... 492 2.1.2.4.2 Target Cell List Generation .......................................................................................................... 492 2.1.2.4.3 Target Cell Ranking (HCS disabled) ............................................................................................ 493



2.1.2.4.4 Target Cell Ranking with HCS...................................................................................................... 493 2.1.2.5 Inter-cell/Inter-system Handover due to better cell (power budget handover) ...................................... 494

2.1.2.5.1 Handover Decision / Handover Trigger Conditions ...................................................................... 494 2.1.2.5.1.1 Special Power Budget Calculation for calls in inner area of Concentric Cells............................ 495 2.1.2.5.2 Target Cell List Generation (HCS disabled) ................................................................................. 497 2.1.2.5.3 Target Cell Ranking (HCS disabled) ............................................................................................ 498 2.1.2.5.3.1 Speed sensitive handover enabled ........................................................................................... 499 2.1.2.5.4 Handover Initiation and Target Cell List Generation with HCS ..................................................... 500 2.1.2.5.5 Target Cell Ranking with HCS...................................................................................................... 501

2.1.2.5.6 Speed sensitive handover enabled ................................................................................................... 501 2.1.2.6 Inter-system Handover due to sufficient coverage ............................................................................... 502

2.1.2.6.1 Handover Decision / Handover Trigger Conditions & Target Cell List Generation ....................... 502 2.1.2.6.2 Target Cell Ranking (HCS disabled) ............................................................................................ 503 2.1.2.6.3 Speed sensitive handover enabled .............................................................................................. 503 2.1.2.6.4 Target Cell Ranking with HCS...................................................................................................... 504 2.1.2.6.5 Speed sensitive handover enabled (with HCS) ............................................................................ 504

2.1.2.7 Forced Handover due to directed retry, preemption or O&M intervention ............................................ 505 2.1.2.7.1 Handover Decision / Handover Trigger Conditions ...................................................................... 505 2.1.2.7.2 Target Cell List Generation .......................................................................................................... 505 2.1.2.7.3 Target Cell Ranking (HCS disabled) ............................................................................................ 506 2.1.2.7.4 Target Cell Ranking with HCS...................................................................................................... 506

2.1.2.8 Fast Uplink Handover (Intra-BSC only) ................................................................................................ 507 2.1.2.8.1 Handover Decision / Handover Trigger Conditions ...................................................................... 507 2.1.2.8.2 Target Cell List Generation .......................................................................................................... 507 2.1.2.8.3 Target Cell Ranking....................................................................................................................... 508

2.1.2.9 Inter-cell Handover due to BSS Resource Management Criteria (Traffic HO) ..................................... 509 2.1.2.9.1 Handover Decision / Handover Trigger Conditions ...................................................................... 509 2.1.2.9.2 Target Cell List Generation .......................................................................................................... 513 2.1.2.9.3 Target Cell Ranking (HCS disabled) ............................................................................................. 513 2.1.2.9.4 Target Cell Ranking with HCS...................................................................................................... 514

2.2 REPORTING, DISPLAY AND BTS INTERNAL HANDLING OF RSCP VALUES FROM 3G NEIGHBOUR CELLS....... 515 2.3 SEQUENCE OF HANDOVER TYPES WITHIN THE HANDOVER DECISION ALGORITHM IN THE BTS................... 517

2.4.1 Functional Diagram: Power Control Thresholds - Power Increase / Power Decrease (Classic Power Control) ...................................................................................................................................... 518 2.4.2 Rules: Power Control Thresholds: Power Increase / Power Decrease...................................... 519

2.4.2.1 Power Increase .................................................................................................................................... 519 2.4.2.2 Power Decrease................................................................................................................................... 519

2.4.3 Classic and Adaptive Power Control .......................................................................................... 521 2.4.3.1 Introduction ........................................................................................................................................... 521 2.4.3.2 Classic Power Control decision process .............................................................................................. 521 2.4.3.3 Adaptive Power Control decision process ............................................................................................ 522 2.4.3.4 Differences between CLASSIC and ADAPTIVE power control decision .............................................. 523 2.4.3.5 Functional sequence of a BS and MS power control procedure........................................................... 525

2.4.3.5.1 BS power control procedure ......................................................................................................... 525 2.4.3.5.2 MS power control procedure ........................................................................................................ 526

2.4.3.6 Comparison of timing behaviour of different Power Control types - MS Power Control, BS Power Control, classic and adaptive ............................................................................................................................ 527 2.4.3.7 Further differences between CLASSIC and ADAPTIVE Power Control ............................................... 529 2.4.3.8 Interaction of Power Control Measurement Preprocessing and Power Control Decision .................... 530

2.5 INTERWORKING OF HANDOVER AND POWER CONTROL............................................................................ 531 2.5.1 Functional Diagram: Inter-cell Handover and Intra-cell Handover, Power Increase and Power Decrease............................................................................................................................................... 531 2.5.2 Rules........................................................................................................................................... 532

2.6 SERVICE DEPENDENT HANDOVER AND POWER CONTROL ....................................................................... 533 2.6.1 Introduction ................................................................................................................................. 533 2.6.2 SGxxHOPAR and SGxxPCPAR parameter values ..................................................................... 534

2.6.2.1 SGxxHOPAR parameter values (Handover) ......................................................................................... 534 2.6.2.2 SGxxPCPAR parameter values (Power Control) .................................................................................. 536

2.7 MAPPING OF RXQUAL AND C/I VALUES................................................................................................. 538 2.8 AMR LINK ADAPTATION THRESHOLDS UPLINK........................................................................................ 539 2.9 BSC, MSC AND BTS OVERLOAD HANDLING .......................................................................................... 543

2.9.1 BSC Overload ............................................................................................................................. 543 2.9.1.1 BSC overload conditions....................................................................................................................... 543

2.9.1.1.1 SS7 Link Congestion..................................................................................................................... 543 2.9.1.1.2 Internal Message Congestion....................................................................................................... 543 2.9.1.1.3 PPXL Overload.............................................................................................................................. 543 2.9.1.1.4 BSC Paging Queue Overflow........................................................................................................ 544



2.9.1.2 System reactions and overload regulation measures in case of BSC overload ................................... 551 2.9.1.2 System reactions and overload regulation measures in case of BSC overload ................................... 551

2.9.1.2.1 Further important notes on BSC reactions ................................................................................... 552 2.9.1.3 Mechanisms for reduction of originating traffic and reduction of terminating traffic .............................. 553

2.9.1.3.1 Overload level management......................................................................................................... 553 2.9.1.3.2 Traffic reduction algorithms .......................................................................................................... 554 2.9.1.3.3 Special overload supervision algorithm in case of BSC paging queue overflow........................... 555

2.9.2 MSC Overload ............................................................................................................................ 556 2.9.2.1 System reactions and overload regulation measures in case of MSC overload.................................... 556

2.9.2.1.1 Special overload level escalation algorithm in case of MSC overload ........................................... 556 2.9.3 BTS Overload ............................................................................................................................. 557

2.9.3.1 BTS overload conditions ....................................................................................................................... 557 2.9.3.1.1 PCH messages discarded in BTS ................................................................................................. 557 2.3.9.1.2 AGCH messages discarded in BTS .............................................................................................. 557 2.3.9.1.3 Abis LAPD signalling overload UL................................................................................................. 562 2.3.9.1.4 RACH overload ............................................................................................................................. 562

2.9.3.2 Traffic reduction mechanisms in case of BTS overload ....................................................................... 562 2.9.3.3 System reactions and overload regulation measures in case of BTS overload.................................... 563

2.9.4 Interaction of BTS Overload and BSC Overload ........................................................................ 565 2.9.5 Effects on Performance Measurement Counters ....................................................................... 565

3 ALPHABETICAL COMMAND AND PARAMETER INDEX ..................................................................... 566



1 Database BR9.0 1.1 BR9.0 Object Tree of functional BSC database objects

The above diagram shows the architecture of the functional objects in the BSC database, HW objects are not considered.

Note: The objects BTSMOSUSW, TRAOSUSW, SCANCO, the scanner objects ('SCANxxxx') are not considered in this document.



Notes: 1) The parameters marked by grey background are new in BR9.0 (compared to BR8.0). 2) Changes of parameter values, value ranges and default values are indicated by

highlighted letters. Changes of parameter names are marked, too. 3) Notes on parameter grouping:

- For a better logical structure, the parameters are grouped in the 'pseudo-packages' (e.g. CREATE BTS [BASICS], SET BTS [CCCH] etc.) as used in the LMT GUI. - Within each package, parameters are sorted alphabetical order.



1.2 BSC Database Commands and Parameters Setting the object entry point and time and date for the BSS: < The MEL (Managed Element) object represents the entry point of

the addressing of the BSS. It simultaneously represents the object with which the network element time and date can be set. >

SET MEL: NAME=MEL:0, Object name. ETIME=12-00..00..1-1-2002, object: MEL format: hour minute-second- day-month-year range: hour 0..23 minute 0..59 second 0..59 day 1..31 month 1..12 year 1992..2099

External time, this parameter defines the network element time in the BSS.

MELID=1; object: MEL range: 0..83

Managed Element ID, this parameter defines the 'name' resp. ID of the BSS in the Radio Commander (RC) area. The value entered for MELID must match to the BSS_RDN in the RC database to ensure the correct operation of the higher communication layers on the O&M link between BSC and RC. This parameter replaces the BSSNAME parameter which was used in older releases up to BR5.5.

Setting the BSC control values for periodic measurement data file upload:

SET BSC [CONTROL]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into 'packages' anymore. Instead, all parameters of the previous 'BSC packages' were moved below the object BSC and appear in the DBAEM in the SET BSC command. The logical group '[CONTROL]' is normally only used on the LMT but was used here to allow a more useful grouping of the commands .

NAME=BSC:0, Object name. CFS=3, object: BSC [CONTROL] unit: 1 Mbyte range: 1-12 default: 1

CTR file size, this attribute indicates the maximum size of the 'Cell Traffic Recording' logfile on the BSC disk. The feature 'Cell Traffic Recording' or 'Cell Trace' (CTR) is a feature used to record cell specific call events for monitoring purposes in a similar way like IMSI tracing (for details please see command CREATE CTRSCHED).The parameter CFS specifies the maximum file size for the CTR trace logfiles in the BSC directory. When a CTR tracing procedure is in progress, the BSC writes the binary trace data to the open binary trace file in the BSC directory TRACE_CTR. On call termination, a trace record is generated an written to the CTR trace logfile. The parameter CFS specifies the maximum size of this CTR logfile. When the trace logfile exceeds the size specified by CFS, it is closed and transferred to the BSC directory READY_CTR. Form there it is compressed to the directory DBFH_ZIP from where it is uploaded to the RC at the next possible point of time (automatic upload takes place every 5 minutes). A CTR logfile can also be automatically closed and prepared for upload if the trace is still in progress. In this case a new open binary file is generated which records the next events of the call to be traced. In the RC, the uploaded files are decompressed, merged and converted to ASCII for analysis by the DUIT application.



IMSIFSIZ=30, object: BSC [CONTROL] unit: 1 Mbyte range: 0..60 default: 30

IMSI file size, this parameter is associated to the feature 'IMSI Tracing' (see command CREATE TRACE) and specifies the maximum file size for the IMSI trace files in the BSC directory. When an IMSI tracing procedure is in progress, the BSC writes the binary trace data to the open binary trace file in the BSC directory TRACE_IMSI. The parameter IMSIFSIZ specifies the maximum allowed size of this binary trace file. When the tracing process is finished the binary trace files are closed and compressed to the BSC directory READY_IMSI. Form there they are compressed to the directory DBFH_ZIP from where they are uploaded to the RC at the next possible point of time. When the maximum size has been reached although the traced call is still in progress, the binary file is also closed and compressed to the directory READY_IMSI for upload and a new binary trace file is opened. In the RC, the uploaded files are decompressed, reassembled and converted to ASCII for analysis by the DUIT application.

HDCFS=1, object: BSC [CONTROL] unit: 1 Mbyte range: 1..24 default: 1

HDC file size, this attribute indicates the maximum size of the 'History on Dropped Calls' logfile on the BSC disk. The feature 'History on Dropped Calls' (HDC or HDCTR, see also command CREATE HDCTR and parameter EHDCTR in command CREATE BTS [BASICS]) is a feature used to record history data of dropped calls (for details, please refer to the command CREATE HDCTR), such as the last received MEASUREMENT REPORT messages as well as layer 3 messages relevant for channel changes. The parameter HDCFS specifies the maximum file size for the HDCTR trace logfiles in the BSC directory. When a CTR tracing procedure is in progress, the BSC writes the binary trace data to the open binary trace file in the BSC directory TRACE_HDCTR. When a call drop occurs while the HDCTR feature is enabled, a HDCTR record is generated an written to the HDCTR logfile. The parameter CFS specifies the maximum size of this HDCTR logfile. When the trace logfile exceeds the size specified by HDCFS, it is closed and transferred to the BSC directory READY_HDCTR. Form there it is compressed to the directory DBFH_ZIP from where it is uploaded to the RC at the next possible point of time (automatic upload takes place every 5 minutes). In the RC, the uploaded files are decompressed, merged and converted to ASCII for analysis by the application DUIT/RNA.

HDCFUPE= upPe0h, object: BSC [CONTROL] range: upPe0h= no per. upl. upPe1h = Upl. period 1h upPe2h = Upl. period 2h upPe3h = Upl. period 3h upPe4h = Upl. period 4h upPe6h = Upl. period 6h upPe8h = Upl. period 8h upPe12h= Upl. period 12h upPe24h= Upl. period 24h default: upPe0h

HDC data file upload period, defines the time period between two uploads of logfiles for the feature 'History on Dropped Calls' (for details, please refer to the command CREATE HDCTR). Setting this parameter to 'upPe0h' disables the periodic upload.



MASCLOGFS=3, object: BSC [CONTROL] unit: 1 Mbyte range: 1..24 default: 3

Maximum scanner logfile size, this attribute indicates the maximum size of the scanner result file on the BSC disk. The file SCAN.TMP is the scanner logfile on the BSC disk to which all scanner results of scanners which were created 'BYFILE' are written. This file is available in the BSC directory MEASURE_DIR. To upload the scanner results to the RC the file SCAN.TMP is closed, renamed to SCAN.LOG and transferred to the directory READY_MEAS. Form there it is compressed to the directory DBFH_ZIP from where it is uploaded to the RC. The size threshold entered by MASCLOGFS determines the maximum allowed size of the file SCAN.TMP: when the entered size is reached for the file SCAN.TMP the SCAN.LOG is automatically uploaded to the RC. New measurement results are then written to a newly opened SCAN.TMP file.

MEDAFUPE=UPPE_0H, object: BSC [CONTROL] range: UPPE_0h= no per. upl.. UPPE_15m = Upl. prd. 15 min. UPPE_30m = Upl. prd. 30 min. UPPE_1h = Upl. period 1h UPPE_2h = Upl. period 2h UPPE_3h = Upl. period 3h UPPE_4h = Upl. period 4h UPPE_6h = Upl. period 6h UPPE_8h = Upl. period 8h UPPE_12h= Upl. period 12h UPPE_24h= Upl. period 24h default: UPPE_0h

Measurement data file upload period, defines the time period between two uploads of measurement data files. Setting this parameter to UPPE_0h disables the periodic upload.

MEDAFUST=0-0; object: BSC [CONTROL] range: upload start hour 0..23 upload start minute 0..59 default: upload start hour 0 upload start minute 0

Measurement data file upload start, defines the start time for measurement data file upload. Parameter format: upload start hour - upload start minute.



Setting the timing values for BSSMAP control and BSC overload handling:

SET BSC [TIMER]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into 'packages' anymore. Instead, all parameters of the previous 'BSC packages' were moved below the object BSC and appear in the DBAEM in the SET BSC command. The logical group '[TIMER]' is normally only used on the LMT but was used here to allow a more useful grouping of the commands .

NAME=BSC:0, Object path name. BSCT1=HLFSEC-12, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-12 Reference: GSM 08.08

BSC timer T1, this timer determines the time to receive the BSSMAP message BLOCKING ACKNOWLEDGE. The MSC selects the terrestrial resources (A interface traffic channels) to be used for a call. The MSC therefore needs to be informed about A-interface circuits that are out of service in the BSC or cannot be used due to configuration of OMAL, LPDLS or SS7L etc.. The BSC instructs the MSC to block resp. unblock single affected A-timeslots by using the BSSMAP message BLOCKING/UNBLOCKING. As a result, the MSC marks the affected timeslots as 'unavailable'. If a group of A-interface timeslots is to be blocked simultaneously, the CIRCUIT GROUP BLOCKING/UNBLOCKING procedure is used (see BSCT20). The timer T1 supervises the receipt of the BLOCKING/ UNBLOCKING ACKNOWLEDGE message from the MSC. The value of T1 must be higher than the MSC maximum reaction time and the transmission time for the blocking/unblocking and the associated acknowledge message. After a first T1 expiry the BSS repeats the BLOCKING/UNBLOCKING message. After a second expiry the BSS marks the associated circuits as blocked without waiting for the acknowledgement.

BSCT10=HLFSEC-10, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-10 Reference: GSM 08.08 (04.08)

BSC timer T10, this timer determines the time to return the ASSIGNMENT COMPLETE message in case of call setup and intra-cell handover. This timer is started on the sending of an ASSIGNMENT COMMAND message and is normally stopped when the MS has correctly seized the new channels. The value must be higher than the maximum transmission time of the ASSIGNMENT COMMAND and the ASSIGNMENT COMPLETE message plus the maximum duration of an attempt to establish a data link multiframe mode. Note: Due to the SBS implementation T10 replaces the function of the GSM timer T3107, i.e. T3107 is not used by the SBS. Rule: BSCT10 < TTRAU (for TTRAU see command SET BTS [TIMER]) This setting is necessary to ensure that a signalling failure (T8 and T10) is detected before transcoder failure (TTRAU)

T10 purpose: a) Assignment procedure: release of the associated resources if the MS is lost during the assignment procedure. b) Intra-cell handover: keep the old channels available for a sufficient time in order to allow the MS to return to the old channel return to it if the handover is not successful and to release the old channel if the MS is lost during the handover procedure. start: a) & b): sending of an ASSIGNMENT COMMAND by the BSC stop: a) & b): receipt of an ASSIGNMENT COMPLETE or an ASSIGNMENT FAILURE from the MS expiry action: a) Assignment procedure: Sending of an ASSIGNMENT FAILURE to the MSC with cause 'radio interface message failure' followed by release of the call resources. b) Intra-cell handover: Sending of a CLEAR REQUEST to the MSC with cause 'radio interface message failure' followed by release of the call resources (CLEAR CMD received from MSC).



BSCT11PUB=HLFSEC-16, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-16 Reference: GSM 08.08

BSC timer T11 public, this timer determines the maximum allowed queuing time for TCH assignment requests in the 'public queue'. The parameter BSCT11PUB replaces the parameter BSCT11 (used up to BR7.) and is only relevant if the feature 'queuing' / 'WPS queuing' is enabled (see parameter EQ in command SET BTS [OPTIONS] for a detailed description). When a TCH request for an assignment procedure (i.e. when the BSC receives an ASSIGNMENT REQUEST message from the MSC) is put into a queue due to TCH congestion, T11 determines the maximum time the TCH request may remain in the queue to wait for a busy TCH to become idle. If the TCH request for assignment procedure cannot be served within this time frame and T11 expires, the BSC sends a CLEAR REQUEST to the MSC and the context is released. In BR8.0, the original 'queuing' feature is replaced by the feature 'Wireless Priority Service (WPS)', which is a special enhancement of the feature 'queuing' required by the U.S. market (see parameter EQ in command SET BTS [OPTIONS]). This feature foresees a two queue concept, one queue being used for ordinary subscribers ('public') and one for priorized subscribers ('WPS queue'). The parameter BSCT11PUB defines the queuing timer T11 for the 'public' queue. Further parameters related to the WPS feature are BSCT11WPS, BSCTQHOPUB, BSCTQHOWPS (see below) and EQ, QLWPS, QLPUB, WPSPREF, LWWPSPRI (see command SET BTS [OPTIONS]). Notes: - Queuing a TCH request means a considerable extension of the SDCCH seizure duration! - It is important to consider that the feature 'queuing' stresses the patience of the subscribers as it extends the time a subscriber has to wait (possibly in vain) for the assignment of a TCH in a busy cell. Therefore it has to be carefully considered which waiting time can be regarded as acceptable from the subscriber's point of view. In other words: it makes no sense to set T11 to a too high value. - It is possible to accelerate the release of busy TCHs by an appropriate setting of the timer T3111 (see SET BTS [TIMER]). This may decrease the queuing time considerably. - If the BSC receives an INTERCELL HANDOVER CONDITION INDICATION from the BTS during the queuing time, the BSC directly searches for an idle TCH in the target cell! In other words, during the queuing time no SDCCH-SDCCH handover will ever be performed. If no TCH can be found in the target cells, the TCH request is discarded from the queue.

BSCT11WPS=HLFSEC-16, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-16

BSC timer T11 WPS, this timer determines the maximum allowed queuing time for TCH assignment requests in the 'WPS queue'. This parameter is only relevant if the feature 'Wireless Priority Service (WPS)' is applied (see parameter BSCT11PUB). The parameter BSCT11WPS defines the queing timer T11 for the 'WPS' queue.

T11 purpose: Limitation of the queuing time for an TCH request due to Assignment start: sending of the QUEUING INDICATION (BSC->MSC) stop: - successful allocation of a TCH to the queued TCH request - discarding of the TCH request from the TCH queue (all cases except T11 expiry) expiry action: Sending of a CLEAR REQUEST to the MSC with cause 'no radio resource available' followed by release of the call resources.



BSCT13=HLFSEC-50, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-50 Reference: GSM 08.08

BSC timer T13, this timer determines the RESET guard period at the BSS. The timer T13 is a guard timer which is started after the receipt of the BSSMAP message RESET (see also BSCT4). It provides the time for the BSS to release all affected calls and to erase all affected references. After expiry of T13 the BSS sends a RESET ACKNOWLEDGE message to the MSC. The value of T13 must be higher than the time needed by the BSS to release all affected calls and to erase all affected references. Rule: T16 (MSC) > BSCT13 (BSC) The value of the 'Wait for Acknowledge timer' T16 in the MSC must be higher than the value of T13 plus the transmission time of the RESET and the RESET ACKNOWLEDGE message (it is recommended to set the MSC-timer T16 to 35s). It is recommended to set both T13 in the BSC and T2 in the MSC to ca. 10s.

BSCT17=HLFSEC-20, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-20

BSC timer T17, this timer represents the overload message ignore timer which is used only in case of MSC overload. BSCT17 is used in close relation to the timer BSCT18 (see below). For further details about the exact function of the timer BSCT18 within the BSS overload regulation please refer to the section 'BSC, BTS and MSC overload Handling' in the appendix of this document. As MSC, BSC and BTS overload handling are closely interwoven, the overload conditions and traffic reduction mechanisms are explained in an own chapter that comprises all possible scenarios of overload and overload handling as well as the references to the relevant parameters.


BSC timer T18, this timer represents the overload observation timer and it is used in all cases of BSS overload regulation: BSC overload regulation, MSC overload regulation and BTS overload regulation (see parameters BSCOVLH, MSCOVLH and BTSOVLH in command SET BSC [BASICS]). For further details about the exact function of the timer BSCT18 within the BSS overload regulation please refer to the section 'BSC, BTS and MSC overload Handling' in the appendix of this document. As MSC, BSC and BTS overload handling are closely interwoven, the overload conditions and traffic reduction mechanisms are explained in an own chapter that comprises all possible scenarios of overload and overload handling as well as the references to the relevant parameters.


BSC timer T19, this timer determines the time to receive RESET CIRCUIT ACKNOWLEDGE at the BSC. The RESET CIRCUIT procedure is started either by the BSC or the MSC if a single circuit has to be put into the idle state due to abnormal SCCP connection release. If the RESET CIRCUIT procedure is initiated by the BSC it sends the BSSMAP message RESET CIRCUIT to the MSC which clears all associated call transactions, puts the affected traffic channel to the idle state and returns the message RESET CIRCUIT ACKNOWLEDGE to the BSC. If T19 expires before the receipt of the RESET CIRCUIT ACKNOWLEDGE the BSC repeats the RESET CIRCUIT PROCEDURE and restarts T19.




BSC timer T20, this timer determines the time to receive CIRCUIT GROUP BLOCKING ACKNOWLEDGE. The MSC selects the terrestrial resources (A interface traffic channels) to be used for a call. The MSC therefore needs to be informed about any A-interface circuits that are out of service in the BSC or cannot be used due to other reasons. If a group of A-interface channels cannot be used any more (e.g. due to failure of a TRAU) the BSC instructs the MSC to block the affected A-interface circuits by using the BSSMAP message CIRCUIT GROUP BLOCKING/UNBLOCKING. As a result, the MSC marks all affected timeslots as 'unavailable'. The timer T20 supervises the receipt of the BLOCKING/ UNBLOCKING ACKNOWLEDGE message from the MSC. The value of T20 must be higher than the MSC maximum reaction time and the transmission time for the blocking/unblocking and the associated acknowledge message. After a first T20 expiry the BSS repeats the BLOCKING/UNBLOCKING message. After a second expiry the BSS marks the associated circuits as blocked without waiting for the acknowledgement.


BSC timer T3, this timer determines the frequency of the BSSMAP message RESOURCE INDICATION sending. The RESOURCE INDICATION message contains information about the number of available TCHs per interference band for a specific cell and is sent by from the BSC to the MSC if the BSC has previously received the BSSMAP message RESOURCE REQUEST from the MSC. The RESOURCE REQUEST message indicates a specific cell identifier and can trigger the transmission a single RESOURCE INDICATION as well as the transmission of several RESOURCE INDICATIONs in a periodic manner. For the periodic transmission of RESOURCE INDICATION the timer T3 determines the period between two consecutive transmissions of the RESOURCE INDICATION.

BSCT3121=HLFSEC-10, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-10 Reference:

BSC timer T3121, this parameter represents a timer which is used to supervise the 2G-3G handover procedure towards an UTRAN-FDD cell. T3121 is the 2G-3G handover equivalent to the timer T8 (see parameter BSCT8). In this case the BSC has sent a BSSMAP HANDOVER REQUIRED with a UMTS 3G neighbour cell (see command CREATE ADJC3G) in the target cell list to the 3G MSC. When the target RNC has provided the target channel data and the 3G-MSC has sent the associated INTER SYSTEM TO UTRAN HANDOVER COMMAND to the BSC, the BSC forwards this ISHTURAN HANDOVER COMMAND to the multiRAT MS and simultaneously starts the timer T3121. The MS, on receipt of the HO CMD, switches over to the target channel in the UMTS 3G neighbour cell and, in case of successful link setup, sends the RRC HANDOVER COMPLETE towards the target RNC which in turn sends an Iu RELOCATION COMPLETE message to the 3G MSC. The timer T3121 is stopped a) when the BSC has received the CLEAR COMMAND with cause 'handover successful' or b) when the BSC has received a HANDOVER FAILURE message from the MS/UE. When T3121 expires, the BSC sends a CLEAR REQUEST with cause 'radio interface message failure' to the 3G-MSC to indicate the drop of the connection during the handover procedure. This event is counted as a call drop by the PM counters NRFLTCH (subcounter 9) and NRCLRREQ (subcounter cause: radio interface message failure) and will thus appear as a call drop event in the PM statistics. Note: T3121 has exactly the same meaning and function for 2G-3G handover from GSM to a UTRAN-TDD neighbour cell (TD-SCDMA).




BSC timer T4, this BSSMAP timer determines the time to return a BSSMAP RESET ACKNOWLEDGE message. The BSC sends the BSSMAP message RESET to the MSC in the event of a failure which leads to the loss of transaction reference information. The purpose of the RESET message is to initialize the BSSMAP relation between MSc and BSC and to put all affected circuits into the idle state. When the MSC has received the RESET message form the BSC it releases all affected connections and initializes the associated traffic channels. After the a guard period of T2 (MSC timer) the MSC responds with a RESET ACKNOWLEDGE message. The timer T4 is started when the BSC transmits the RESET message to the MSC and watches over the receipt of a RESET ACKNOWLEDGE from the MSC. If no RESET ACKNOWLEDGE has been received before expiry of T4, the BSC retransmits the RESET message and starts T4 again. Rule: BSCT4 (BSC) > T2 (MSC) The value of T4 must be higher than the value of the MSC timer T2 plus the transmission time of the RESET and the RESET ACKNOWLEDGE messages (It is recommended to set the MSC-timer T2 to ca. 10s). Note: The RESET procedure can also be initiated by the MSC. In this case equivalent timers are used: The MSC timer T16 supervises the receipt of the RESET ACKNOWLEDGE message (equivalent to the BSC timer T4) and the guard period in the BSC for the transmission of the RESET ACKNOWLEDGE is the timer T13 (see BSCT13).

BSCT7=HLFSEC-8, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-6 Reference: GSM 08.08 GSM 05.08 Default values changed in BR8.0!

BSC timer T7, this timer determines the waiting time for a HANDOVER COMMAND from the MSC after transmission of a HONDOVER REQUIRED to the MSC. If the BTSE has sent a HANDOVER CONDITION INDICATION message and the handover is to be executed by the MSC (if the first target cell is an external one or if LOTERCH or LOTRACH (see SET HAND [BASICS]) are set to FALSE) or if the MSC has initiated a HANDOVER CANDIDATE ENQUIRY procedure, the BSS sends a HANDOVER REQUIRED message to the MSC and starts T7. As long as T7 runs the BSC call processing code remains in a state 'waiting for HO CMD'. During this time the BSC ignores all new HO COND IND messages received from the BTS and no further HO RQDs are sent. If T7 expires (i.e. no HO CMD was received from the MSC), the BSC call processing terminates the 'waiting for HO CMD' state and the receipt of new HO COND IND message directly leads to the transmission of an updated HO RQD. All HO CMDs received after expiry of T7 are discarded by the BSC. Notes: 1) Attention: Especially in case of Inter-MSC handovers or if the features 'queuing' or/and 'preemption' are used for incoming MSC controlled handovers, the handover completion may take a long time due to the additional handover of the preempted call in the target cell. This has to be considered by setting BSCT7 to a sufficiently high value in the originating BSC. If BSCT7 is too short, the HO CMD might be received after T7 expiry. This leads to the discarding of the HO CMD and thus to a forced release of the call by the MSC as the MSC supervises the by an own timer (Trr7 in Siemens MSC) which is started when the HO CMD is transmitted and which waits for the

T7 purpose: Waiting time for a HANDOVER COMMAND from the MSC start: sending of HANDOVER REQUIRED by the BSC stop: - receipt of a HANDOVER COMMAND from the MSC - communication to MS is lost - transaction has ended, call cleared expiry action: - HO CMDs are ignored - new HO_RQD is sent if HO_COND_IND is received from the BTS



'handover successful' indication from the target side or a HANDOVER FAILURE (DTAP) from the originating side. As the experience has shown, during inter-MSC handover procedures it may take more than 2s until the HANDOVER COMMAND is received from the MSC (in case of inter-PLMN handover it may be even more), it is recommended to apply at least the setting BSCT7 HLFSEC-7 or longer. As the experience has shown, especially in case of Inter-MSC handover (with a possible GPRS preemption procedure in the target cell) the time for the receipt of the HO CMD in the originating BSC may even exceed 3 seconds. 2) This timer should be set with respect to the timer value THORQST (see command SET HAND) and the SIEMENS MSC internal timer T_HO_REJ. Recommended setting: THORQST (HAND) > BSCT7 (BSC)


BSC timer T8, this timer determines the time to receive the HANDOVER COMPLETE message. T8 is defined as the time that BSC layer 3 will wait for a handover to complete before releasing the source channel. The value must be bigger than the sum of the time for all messages to be sent to the MS plus the time to access a target and come back (if necessary). Note: Due to the SBS implementation T8 replaces the function of T3103 (see SET BTS [TIMER]). Rule: BSCT8 < TTRAU (for TTRAU see command SET BTS [TIMER]) This setting is necessary to ensure that a signalling failure (T8 and T10) is detected before transcoder failure (TTRAU)

T8 purpose: keep the old channels available for a sufficient time in order to allow the MS to return to the old channel return to it if the handover is not successful and to release the old channel if the MS is lost. start: transmission of a HANDOVER COMMAND from the BSC to the MS stop: a) intra-BSC handover: receipt of a HANDOVER COMPLETE or a HANDOVER FAILURE from the MS b) inter-BSC handover: receipt of a CLEAR COMMAND from the MSC or HANDOVER FAILURE from the MS expiry action: Sending of a CLEAR REQUEST to the MSC with cause 'radio interface message failure' followed by release of the call resources (CLEAR CMD received from MSC).



BSCTQHO=HLFSEC-20, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-20 Reference: GSM 08.08

BSC timer for queuing of handover, this timer determines the maximum allowed queuing time for incoming handover. This parameter is only relevant if the feature 'queuing' is enabled (see parameter EQ in command SET BTS [OPTIONS]). When a TCH request for an incoming MSC-controlled handover (i.e. when the BSC receives a HANDOVER REQUEST message from the MSC) is put into a queue due to TCH congestion, TQHO determines the maximum time the TCH request may remain in the queue to wait for a busy TCH to become idle. If the TCH request for the incoming handover cannot be served within this time frame and TQHO expires in case of incoming MSC-controlled HO, the TCH request is rejected with a HANDOVER FAILURE. As a result, if there is another target cell available for the handover procedure, the MSC will attempt another HO REQUEST procedure towards the next target BTS.# Note: It is possible to accelerate the release of busy TCHs by an appropriate setting of the timer T3111 (see SET BTS [TIMER]). This can decrease the queuing time considerably.

BSCTQHOPUB=HLFSEC-16, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-16

BSC timer for queuing of handover in public queue, this timer determines the maximum allowed queuing time for TCH requests due to incoming handover in the 'public queue'. This parameter is only relevant if the feature 'Wireless Priority Service (WPS)' is applied, which is a special enhancement of the feature 'queuing' required by the U.S. market (see parameter EQ in command SET BTS [OPTIONS]). This feature foresees a two queue concept, one queue being used for ordinary subscribers ('public') and one for priorized subscribers ('WPS queue'). The parameter BSCTQHOPUB defines the queing timer TTQHO (see parameter BSCTQHO which is used for ordinary queing) for the 'public' queue. Further parameters related to the WPS feature are BSCT11PUB, BSCT11WPS (see above), BSCTQHOWPS (see below) and EQ, QLWPS, QLPUB, WPSPREF, LWWPSPRI (see command SET BTS [OPTIONS]).

BSCTQHOWPS=HLFSEC-16, object: BSC [TIMER] unit: HLFSEC=0,5s SEC5=5s range: 0..254 default: HLFSEC-16

BSC timer for queuing of handover in WPS queue, this timer determines the maximum allowed queuing time for TCH requests due to incoming handover in the 'public queue'. This parameter is only relevant if the feature 'Wireless Priority Service (WPS)' is applied (see parameter BSCTQHOPUB). The parameter BSCTQHOWPS defines the queing timer TQHO (see parameter BSCTQHO which is used for ordinary queing) for the 'WPS' queue.

TQHO purpose: Limitation of the queuing time for an TCH request due to incoming MSC-controlled handover start: sending of the QUEUING INDICATION (BSC->MSC) stop: - successful allocation of a TCH to the queued TCH request - discarding of the TCH request from the TCH queue (all cases except TQHO expiry) expiry action: Sending of a HANDOVER FAILURE with cause 'no radio resource available' to the MSC followed by release of the call resources.



ENACCTREP=30, object: BSC [TIMER] unit: 1 min. range: 15..750 default: 30[min] FRS-No.: 86654, 90351 SF-No.: 10518, 10508

External NACC Timer for Repetitions, this parameter is related to the features 'External NACC' (see parameter ENACCE in command SET BSC [BASICS])' and 'RAN Information Management' (RIM). RIM comprises signaling procedures (RIMApp = RIM Applications) executed between two BSCs via the connected SGSN and which are employed whenever the 'controlling BSC' requests particular call processing information from the 'serving BSC'. ENACCTREP determines the time, after which the controlling BSC retries a particular RIM procedure (RIR, RI or RIAE - for further details, please refer to the descriptions of parameters ENACCTRI, ENACCTRIR and ENACCTRIAE (see below)), that were not successfully completed even after N repetitions (N depends on the type of message and is defined by the parameters ENACCTRICM (for RI), ENACCTRIAECM (for RIAE) )of the original message. T(REP) is started in the BSC when it starts the RI, RIR or RIAE procedures towards the remote peer BSC (via the SGSN) and is stopped when the corresponding procedure was successfully completed. When the corresponding procedures were not successfully completed after all attempts, i.e. no positive response or acknowledgement was received after as many message repetitions as defined by the repetition threshold parameters ENACCTRICM, ENACCTRIRCM or ENACCTRIAECM (see below) and T(REP) expires, the corresponding procedure (RI, RIR or RIAE) is attempted again until it is either successfully completed or until the abovementioned repetition thresholds are reached again. Notes: - A RIM_Failure_Indication does not stop the T(REP) timer inside the RIM Application (in BR9.0 the only RIM Application is External NACC); T(REP) will expire after the specified amount of time. - The T(REP) handling is a task of the RIM Application.

ENACCTRL=24, object: BSC [TIMER] unit: 1h range: 1..60 default: 24[h] FRS-No.: 86654, 90351 SF-No.: 10518, 10508

External NACC Timer for Repetition Long, this parameter is related to the features 'External NACC' (see parameter ENACCE in command SET BSC [BASICS])' and 'RAN Information Management' (RIM). RIM comprises signaling procedures executed between two BSCs via the connected SGSN and which are employed whenever the 'controlling BSC' requests particular call processing information from the 'serving BSC'. ENACCTRL represents the maximum value of the BSC timer T(REPL). When controlling BSC starts an RIR Procedure towards serving BSC (please see parameter ENACCTRIR for further details), it can happen that the serving BSC does not support the ENACC functionality (yet). In this case the controlling BSC will receive a RAN INFORMATION ERROR (RIE) with cause Unknown Application Id. The timer T(REPL) is started on reception of the aforementioned message. When T(REPL) has been started, the BSC tries to repeat the RIR procedure on every T(REPL) timer expiry. Thus T(REPL) timer takes care not to transmit too many RIR messages to BSCs that do not support the RIM functionalities.



ENACCTRI=2, object: BSC [TIMER] unit: 1s range: 2..8 default: 2[s] FRS-No.: 86654, 90351 SF-No.: 10518, 10508

External NACC timer RI, this parameter is related to the features 'External NACC' (see parameter ENACCE in command SET BSC [BASICS])' and 'RAN Information Management' (RIM). RIM comprises signaling procedures executed between two BSCs via the connected SGSN and which are employed whenever the 'controlling BSC' requests particular call processing information from the 'serving BSC'. ENACCTRI determines the value of the timer T(RI) which defines the maximum waiting time for RI acknowledgement for ENACC. RI is the abbreviation for 'RAN Information Send Procedure' which the 'serving' BSC starts to transfer the RIMApp information towards the 'controlling' BSC, that has previously requested this information via the 'RAN Information Request Procedure' (RIR). T(RI) is started in the serving BSC when it sends the RAN INFORMATION (RI) message towards the controlling BSC (via the SGSN) and is stopped when the RAN-INFORMATION ACK (RIA) message has been received from the controlling BSC. When T(RI) expires, the RI procedure is repeated again until the expected response is received or until the maximum number of repetitions (determined by parameter ENACCTRICM (see below)) is reached. Notes: - T(RI) is only started if an acknowledgement is required.

ENACCTRICM=3, object: BSC [TIMER] range: 1..12 default: 3 FRS-No.: 86654, 90351 SF-No.: 10518, 10508

External NACC timer RI Counter Max, this parameter determines a threshold that determines the maximum number of consecutive RI procedures. The RI procedure is repeated if it could not be successfully completed (i.e. no response / acknowledgement was received from the remote peer BSC) on the preceding attempt. For further details, please refer to parameter ENACCTRI (see above).

ENACCTRIAE=2, object: BSC [TIMER] unit: 1s range: 2..8 default: 2[s] FRS-No.: 86654, 90351 SF-No.: 10518, 10508

External NACC timer RIAE, this parameter is related to the features 'External NACC' (see parameter ENACCE in command SET BSC [BASICS])' and 'RAN Information Management' (RIM). RIM comprises signaling procedures executed between two BSCs via the connected SGSN and which are employed whenever the 'controlling BSC' requests particular call processing information from the 'serving BSC'. ENACCTRIAE determines the value of the timer T(RIAE) which defines the maximum waiting time for RIAE acknowledgement. RIAE is the abbreviation for 'RAN Information Application Error Procedure' which is started by the 'controlling' BSC upon detection of an error in a received RIMApp information container unit. T(RIAE) is started in the controlling BSC when it sends the RANINFORMATION-APPLICATION-ERROR (RIAE) message towards the serving BSC (via the SGSN) and is stopped when the RAN-INFORMATION ACK (RIA) message has been received from the serving BSC. When T(RIAE) expires, the RIAE procedure is repeated again until the expected response is received or until the maximum number of repetitions (determined by parameter ENACCTRIAECM (see below)) is reached.

ENACCTRIAECM=3, object: BSC [TIMER] range: 1..12 default: 3 FRS-No.: 86654, 90351 SF-No.: 10518, 10508

External NACC timer RIAE Counter Max, this parameter determines a threshold that determines the maximum number of consecutive RIAE procedures. The RIAE procedure is repeated if it could not be successfully completed (i.e. no response / acknowledgement was received from the remote peer BSC) on the preceding attempt. For further details, please refer to parameter ENACCTRIAE (see above).



ENACCTRIR=2, object: BSC [TIMER] unit: 1s range: 2..8 default: 2[s] FRS-No.: 86654, 90351 SF-No.: 10518, 10508

External NACC timer RIR, this parameter is related to the features 'External NACC' (see parameter ENACCE in command SET BSC [BASICS])' and 'RAN Information Management' (RIM). RIM comprises signaling procedures executed between two BSCs via the connected SGSN and which are employed whenever the 'controlling BSC' requests particular call processing information from the 'serving BSC'. ENACCTRIR determines the value of the timer T(RIR) which defines the maximum time the controlling BSC waits, after having sent the RIR, for the reception of the serving BSC's response (RI). RIR is the abbreviation for 'RAN Information Request Procedure' which the 'controlling' BSC starts to request the RIMApp information from the 'serving' BSC. In response, the 'serving' BSC starts the 'RAN Information Send Procedure' (RI). T(RIR) is started in the controlling BSC when it sends the RANINFORMATION REQUEST (RIR) message towards the serving BSC (via the SGSN) and is stopped when the RAN-INFORMATION (RI) message has been received. When T(RIR) expires, the RIR procedure is repeated again until the expected response is received or until the maximum number of repetitions (determined by parameter ENACCTRIRCM (see below)) is reached.

ENACCTRIRCM=3, object: BSC [TIMER] range: 1..12 default: 3 FRS-No.: 86654, 90351 SF-No.: 10518, 10508

External NACC timer RIR Counter Max, this parameter determines a threshold that determines the maximum number of consecutive RIR procedures. The RIR procedure is repeated if could not be successfully completed if it could not be completed (i.e. no response / acknowledgement was received from the remote peer BSC) on the preceding attempt. For further details, please refer to parameter ENACCTRIR (see above).

TEMLD=HLFSEC-12, object: BSC [TIMER] unit: MS100=100ms HLFSEC=0,5s SEC5=5s range: 0..255 default: HLFSEC-12

Timer Emergency Low Delay, this parameter determines the value of the T_RESP (Timer for Response) timer, which controls the duration of how long LCS (Location Services) response from SMLC to BSC on the Lb interface can be performed by the SMLC, for all LCS procedures with client type Emergency and QoS Low Delay. The default value of TEMLD timer is 6 seconds. TEMLD should be set at a value lower than TEMDTOL, TNEMLD and TNEMDTOL (see below). The TEMLD timer is independent of positioning method and runs in the BSC. This timer is introduced by feature Configurable T_RESP LCS Timer in BSC. The TEMLD timer is one of four timers (TEMLD, TEMDTOL, TNEMLD, TNEMDTOL, see below) which were introduced in BR9.0 as a solution solving problem of hard-coded (i.e. not configurable) value of T_RESP timer = 10 seconds. This value of T_RESP did not accommodate the U-TDOA positioning procedure (used by U.S. operators) which can take 30 seconds. If the T_RESP timer expires before response is received, BSC indicates a location failure to the requesting entity. Depending on requested client type (Emergency / Non-Emergency) and QoS response time requirement (Low Delay / Delay Tolerant) appropriate timer is chosen for T_RESP value:

Time requirement Low Delay Delay Tolerant Client type

Emergency call TEMLD TEMDTOL Non-Emergency call TNEMLD TNEMDTOL

For call type and QoS requirement values mapping, please refer to the feature description (Configurable T_RESP LCS Timer in BSC )



TEMDTOL=HLFSEC-60, object: BSC [TIMER] unit: MS100=100ms HLFSEC=0,5s SEC5=5s range: 0..255 default: HLFSEC-60

Timer Emergency Delay Tolerant, this parameter determines the value of the T_RESP (Timer for Response) timer, which controls the duration of how long LCS (Location Services) response from SMLC to BSC on the Lb interface can be performed by the SMLC, for all LCS procedures with client type Emergency and QoS Delay Tolerant. The default value of TEMDTOL timer is 30 seconds. TEMDTOL should be set at a value greater than TEMLD (see above) and lower than TNEMDTOL (see below). The TEMDTOL timer is independent of the positioning method and runs in the BSC. This timer is introduced by feature Configurable T_RESP LCS Timer in BSC. For more details about T_RESP timer settings, please refer to the description of the TEMLD timer (see above).

TNEMLD=HLFSEC-36, object: BSC [TIMER] unit: MS100=100ms HLFSEC=0,5s SEC5=5s range: 0..255 default: HLFSEC-36

Timer Non-Emergency Low Delay, this parameter determines the value of the T_RESP (Timer for Response) timer, which controls the duration of how long LCS (Location Services) response from SMLC to BSC on the Lb interface can be performed by the SMLC, for all LCS procedures with client type Emergency and QoS Low Delay. The default value of TNEMLD timer is 18 seconds. TNEMLD should be set at a value lower than TNEMDTOL (see below) and greater than TEMLD (see above). The TNEMLD timer is independent of positioning method and runs in the BSC. This timer is introduced by feature Configurable T_RESP LCS Timer in BSC. For more details about T_RESP timer settings, please refer to the description of the TEMLD timer (see above).

TNEMDTOL=HLFSEC-90, object: BSC [TIMER] unit: MS100=100ms HLFSEC=0,5s SEC5=5s range: 0..255 default: HLFSEC-90

Timer Non-Emergency Delay Tolerant, this parameter determines the value of the T_RESP (Timer for Response) timer, which controls the duration of how long LCS (Location Services) response from SMLC to BSC on the Lb interface can be performed by the SMLC, for all LCS procedures with client type Emergency and QoS Low Delay. The default values of TNEMDTOL timer is 45 seconds. The TNEMDTOL timer should be set at value greater than the TNEMLD and TEMDTOL timer (see above). The TNEMDTOL timer is independent of positioning method and runs in the BSC. This timer is introduced by feature Configurable T_RESP LCS Timer in BSC. For more details about T_RESP timer settings, please refer to the description of the TEMLD timer above.



Setting the global parameters of the BSC:

SET BSC [BASICS] :

Attention: Since BR6.0 The DBAEM does not group the command parameters into 'packages' anymore. Instead, all parameters of the previous 'BSC packages' were moved below the object BSC and appear in the DBAEM in the SET BSC command. The logical group '[BASICS]' is normally only used on the LMT but was used here to allow a more useful grouping of the commands .

NAME=BSC:0, Object path name. ACCEPTGDEGR=PER0; object: BSC [BASICS] range: PER0, PER10, PER20, PER30 ... PER90 default: PER0

Acceptable GPRS degradation, this parameter defines, in percentage (steps of 10 %, from 0% to 90%), the acceptable degradation of packet service throughput (maximum sustainable throughput), before an upgrading of radio resources (i.e. TCH resources on the Um) is attempted. During a TBF lifetime, due to variations in radio conditions, either the BLER or the used CS/MCS coding scheme can change, leading to a change in the 'maximum sustainable throughput'. The maximum sustainable throughput (MST) is defined as the maximum throughput that would be achieved by a given TBF if it was alone on the multislot configuration, that is:

Maximum sustainable throughput (MST) = T_A_CS (1-BLER) #TS where: T_A_CS = throughput of the Actual Coding Scheme BLER = actual BLER #TS = number of allocated timeslots to the TBF

A check on the current maximum sustainable throughput is performed periodically, with a periodicity defined by the parameter UPGRFREQ (see below). As a general rule, only a decrease of the maximum sustainable throughput is considered; an increase of the MST will not lead to any system reactions, as a 'downgrading' of radio resources due to MST criteria is not performed. Moreover, since the variations in the maximum sustainable throughput can happen very frequently, only the decrease of the MST below a particular threshold will lead to a system reaction (i.e. upgrading of radio resources). An extension to the number of allocated TSs is tried if:

T_A_CS (1-BLER) #TS < (1- ACCEPTGDEGR) PT where: T_A_CS = throughput of the Actual Coding Scheme BLER = actual BLER PT = peak throughput #TS = number of allocated timeslots to the TBF

This means that, when the MST becomes lower than the maximum tolerable degradation of the peak throughput, the upgrading of radio resources is attempted. The upgrade is performed by adding one adjacent timeslot to the currently used ones (i.e. the PCU will send a PDCH_Upgrade_Request message to the TPDC), provided that the conditions regarding horizontal allocation and the percentage of idle timeslots are verified (see parameter GASTRTH in command CREATE PTPPKF). Note: As long as the 'one radio resource a time' algorithm is implemented it is suggested to set the ACCEPTGDEGR attribute to '0' (no degradation allowed, radio resource upgrading always attempted as soon as the upgrading condition is detected), in order to reach the required radio resource allocation in several steps.



AISAT=FALSE, object: BSC [BASICS] range: TRUE, FALSE default: FALSE

A interface via satellite, this attribute indicates whether the A interface resp. SS7 link is realized via satellite link (TRUE) or not (FALSE). If the A interface link is configured as satellite link, the generally higher signal delay must be particularly considered by a) the higher layers on the CCS7 link (e.g. BSSAP) and b) the CCS7 layer 2 functions. Setting AISAT=TRUE has the following consequences: a) BSSAP timers (e.g. BSCT7, BSCT8 etc., see SET BSC [BASICS]) have to be carefully checked as the delay on the lower layers slows down all signalling transactions. It might be necessary to extend selected timers to higher values to avoid undesired effects. b) If the A interface is realized via satellite link the CCS7 error correction method must be set to 'preventive cyclic retransmission error correction' (see CREATE SS7L, parameter ERRCORMTD). Note: Also the Asub interface (parameter ASUBISAT, see below) and the Abis interface (see parameter LPDLMSAT in command CREATE/SET BTSM) can be configured as satellite link. However, only one of the mentioned interfaces should be configured as satellite link at the same time, because multiple satellite links within a BSS may cause an overall message and procedure delay that might lead to expiry of procedure supervision timers that are normally adapted to the propagation delay of terrestrial signalling links or at least to only one satellite link in the path. Although multiple satellite links are not officially tested and released, the BSC command interpreter and DBAEM do not perform any checks to avoid multiple satellite links - it is up to the operator to follow this rule.

AMONTH=ENABLED(30)-ENABLE(60)-ENABLED(90), object: BSC [BASICS] range: ENABLED(1..100), DISABLED default: ENABLE(30) (minor) ENABLE(60) (major) ENABLE(90) (critical)

A-interface TCH monitoring thresholds, determines the state and the threshold values for the minor, major and critical QOS alarms for the traffic channels on the A-interface. The entered threshold value represents the percentage of unavailable traffic channels on the A-interface. If the number of unavailable A-interface traffic channels exceeds the entered threshold, the alarm messages UNAVAILABLE AINT TCH THRESHOLD MINOR, MAJOR or CRITICAL (error ID 242, 243 and 244) are output. The threshold values can only be assigned if the previous attribute is set to ENABLE.

ASCIBROADP=FALSE, object: BSC [BASICS] range: TRUE, FALSE default: FALSE FRS-No.: 89901 SF-No.: 10515

ASCI Broadcast Point, this parameter is only relevant if the feature ASCI is enabled (see parameter ASCISER in command SET BTS [CCCH]) and determines whether the feature 'Group Call Broadcast Point' is enabled (TRUE) or disabled (FALSE) is enabled in the BSC for ASCI calls. The implementation of the ASCI Services requires for each cell of the ASCI service area of a call one common broadcast channel, where the listener users in the cell are able to receive the speech of the talker. As specified by the relevant standards, for each cell of the ASCI call there is an equivalent channel assigned between MSC and the BSC. With the increased number of cells using ASCI services a lot of resources on the A Interface and Asub Interface would be required. With ASCIBROADP=TRUE the voice broadcast in each cell of the BSS is now shifted to the BSC. This significantly saves channels on the A interface and therefore also on the Asub interface. Only one TCH channel on these interfaces is used to connect the MSC to each BSS which is controlling cells in the service area of that ASCI call. When the feature is enabled the time alignment in BTS for the relevant ASCI group channels will be switched off. Note: The feature was originally planned for BR9.0, but was finally postponed to BR10.0. Thus, in BR9.0 the parameter is available but has no effect.


27 / 575

bsc database parameter planning

Documents