br8 database description parameters)

7/31/2019 BR8 Database Description Parameters)

1/474

s

Siemens Base Station (SBS)

BSC Database Parameter DescriptionBR8.0 - DRAFT

Version 01.12.2005


2/474

SBS: BSC Database Parameter Description BR8.0 - DRAFT Version 01.12.05__________________________________________________________________________________________________________

2 / 475 Eckardt Bertermann, Technical Product Support BSS-SBS

made by:

Eckardt BertermannSIEMENS AG

COM MN PG SI RG2, Technical Product Support BSS-SBSTel.: +49 89 722 61361FAX: +49 89 722 28990e-mail: [email protected]

GPRS contributions by:

Wolfgang MalterSIEMENS AGCOM MN PG SI RG2, Technical Product Support BSS-SBSTel.: +49 89 722 54716FAX: +49 89 722 28990e-mail: [email protected]

Please consider the remarks on the next page!


3/474



IMPORTANT

This document is not officially released and is designed as quickreference document for SBS BSC database parameters.

This document is a working document and is continuously modified andenhanced with the latest information. Changes are not 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 commands- 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!

Any comments for corrections or suggestions for improvements are welcome!

The authors e-mail-address is only mentioned for feedback purposes!

If you find mistakes, please check the latest versions of the document inIMS or Siemens Extranet first, before you feed back.

Technical queries concerning specific parameters andfeatures shall be not be sent to the authors but to CIC,R-NCC or NCC as an official hotline query!!!(For queries to TPS-BSS, please use the well-known procedures e.g. via the URLhttps://ims.icn.siemens.de/livelink/livelink/Guest/Launch/308438668)

!


4/474



Contents:

1 DATABASE BR8.0 .........................................................................................................................................................7

1.1 BR8.0OBJECT TREE OF BSC DATABASE OBJECTS........................................................................................................71.2 BSCDATABASE COMMANDS AND PARAMETERS ....................................................................................................9

Setting the object entry point and time and date for the BSS:.................... ............. ............ ............. .............. ............ 9Setting the BSC control values for periodic measurement data file upload:.................... ............ ............ ............... .... 9Setting the timing values for BSSMAP control and BSC overload handling:.......... ............ ............. ............ ............. 12

Setting the global parameters of the BSC:....... ............. ............ ............. ............ ............. ............ .............. ............. .. 19Creating new database parameters without info model change:........... ............. ............ ............. ............ ............. .... 47Setting the alarm priorities of the BSS functional objects: ............. ............ ............. ............ ............. .............. .......... 48Setting the remote Inventory data of the BSC Equipment:............... ............ ............. ............ ............. .............. ........ 50Setting the alarm priorities of the BSCE objects: ............ ............ ............. ............ ............. ............ ............... ............ 51Creating the Power Supply: ............ ............ ............. ............. ............ ............. ............ ............. .............. ............. ...... 53Creating the spare PCM interface boards:........ ............ ............. ............ ............. ............ ............. ............. ............. .. 54Creating the PCM interface boards:............ ............ ............ ............. ............ ............. ............ ................ ............. ...... 54Creating the LAPD boards:.............. ............ ............. ............ ............ ............. ............ ............. .............. ............. ...... 55Creating the common attributes for all PCUs belonging to the entire BSC:............. ............. ............ ............. .......... 55Creating the PCU objects: .......................................................................................................................................62Creating the PCM links for the Abis interface: .............. ............ ............. ............ ............. ............ .............. ............. .. 67Creating the PCMS link: .......................................................................................................................................... 71Creating the TRAU: .................................................................................................................................................73

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

Creating the LPDLS links:...... ............ ............. ............ ............. ............ .............. ............ ............... ............ ............. .. 77Creating the PCMA link: .......................................................................................................................................... 78Setting the uplink and downlink volumes for specific PCMA timeslots:... ............. ............. ............ .............. ............. 84Creating the PCMG link:..........................................................................................................................................85Creating the physical link connection on the GPRS Gb interface (Frame Relay Link): ............. ............. ............ ..... 87Creating the end-to-end communication between BSS and SGSN: Network Service Virtual Connection (NSVC): . 88Creating the BTS Site Manager:.............. ............ ............. ............ ............. ............ ............ ............... ............. .......... 89Creating the LPDLM links: .....................................................................................................................................102Creating the terrestrial Abis timelots for flexible Abis allocation:.............. ............. ............ ............. ............. ........... 104Creating a cell with definition of global parameters:........ ............ ............. ............ ............. ............. .............. .......... 109Setting the cell specific parameters for Admission Control ............ ............ ............. ............ ............. .............. ........ 163Setting the cell attributes for the Interference Measurement of idle TCHs: ............. ............ ............. ............. ......... 174Setting the cell specific timer values: ............ ............ ............. ............ ............. ............. ........... ................ ............. .. 176Setting the cell specific optional features: ............. ............ ............. ............ ............ ............. .............. ............. ........ 185Defining the cell specific service layer lists for the feature Service dependent Channel Allocation (SDCA):.... .... 201Setting the cell specific attributes for Power Control:............. ............ ............. ............. ........... .............. ............. .... 210

Power Control Parameter Relations....... ............ .............. ........... .............. ............ ............. .............. ............. .... 223Creating the GPRS point to point packet transfer service in a cell:................ ............ ............. .............. ............. .... 224Creating the LPDLR links: .....................................................................................................................................250Creating the TRXs: ................................................................................................................................................251Enabling GPRS and EDGE in a cell: ........... ............. ............ ............. ............ ............ ............. .............. ............. .... 254Creating the Frequency Hopping systems: ........... ............ ............. ............ ............. ............ ............ ............... ........ 255Creating the BCCH for the cell:............ ............. ............ .............. ............ ............. ............ ............... ............ ........... 256Creating the SDCCHs for the cell: .........................................................................................................................257Creating the TCHs for the cell: .............................................................................................................................. 259Creating hybrid TCHs/SDCCHs (TCH/SD) for the cell:....... ............. ............. ............. ............. ............. .............. .... 261Setting the cell specific parameters and threshold values for voice call Handover: ........... ............. ............ ........... 265

Handover Parameter Relations.... ............ ............. ............. ............ ............. ............ ............. .............. ............. .. 310Setting the cell specific parameters and threshold values for 14,4kbit/s data call up- and downgrading and qualityinter-cell handover: ................................................................................................................................................ 312Setting the status of SMS-CB, Frequency Hopping and Call Release due to Excessive Distance: ............. .......... 314

Creating the Common BTS data of a BTM for Dynamic MAIO Allocation (DMA): ........... ............. ............. ............ 316Creating the hopping laws used for Dynamic MAIO Allocation: ............. .............. ............ ............. .............. ........... 317Creating the Target Cell Objects:........... ............. ............. ............ ............. ............. ............. .............. ............. ........ 318Creating the Target Point-to-point Packet Flow Objects: ........... ............. ............. ............. ............ ............... .......... 320Creating the Adjacent Cell Objects: ............ ............ ............. ............ .............. ............ ............. .............. ............. .... 322Creating the Target Cell Objects for handover from GSM to UMTS (FDD): ............ ............. ............ ............. ........ 334Creating the Adjacent Cell Objects for external UMTS FDD or UMTS TDD cells:. ............ ............. ............. .......... 335Creating the CCS7 level 3 addresses of BSC, MSC and SMLC and basic SCCP parameters for the SS7connection: ............................................................................................................................................................ 340Setting the timer values for CCS7 MTP level 2:..... ............. ............ ............. ............ ............. .............. ............. ...... 345Setting the timer values for CCS7 MTP level 3:..... ............. ............ ............. ............ ............. .............. ............. ...... 348Creating the CCS7 link: .........................................................................................................................................351Creating a Nailed-Up Connection through the BSC/TRAU: ............. ............. ............. ........... ............. .............. ...... 352


5/474



Creating an X25 connection via dedicated link: ............ .............. ............ ............. ............ ............. .............. ........... 353Creating an X25 connection via A-interface:....... ............. ............ ............ ............. ............ ............. ............. ........... 355Creating an IP Link connection:............ ............ .............. ............ ............. ............ ............. .............. ............. .......... 357Creating the O&M link for the RC connection: ............ ............ ............. ............ ............. ............ .............. ............. .. 358Creating the link for the external connection to the SMS-CB system:.... ............ ............ ............. ............ ............. .. 358Defining the BSC reference synchronization clock origin:............. ............. ............. ............ ............. .............. ........ 358Defining an external synchronization signal:............. .............. ............ ............. ............ ............. .............. ............. .. 359Creating the Quality of Service Alarm Objects:... ............. ............ ............. ............. ............. ............ .............. ......... 360Creating the Quality of Service Alarm threshold sets:.... ............ ............. ............. ............. ............ .............. ........... 361

Creating the Quality of Service Alarm Objects for the BSC object:............. ............. ............. ............ ............... ...... 363Creating the Quality of Service Alarm Objects for BTS objects: ........... ............. ............. ............ .............. ............. 364Creating the Quality of Service Alarm Objects for PTPPKF objects: ............ ............. ........... ............. ............ ........ 368Activating IMSI tracing in the BSC:............ ............. ............ ............ ............. ............ ............. .............. ............ ....... 370Creating a Cell Traffic Recording (CTR) job: ............ ............. ............ .............. ............ ............. .............. ............. .. 371Enabling the data recording for the feature History on Dropped Calls:........ ............. ........... .............. ............. ...... 373Defining the BSC environmental alarms: ........... ............. ............ ............. ............ ............. ............ .............. ........... 378Configuring the feature Online RF Loopback:....... ............. ............ ............ ............. ............ ............ ................. ...... 379Creating Smart Carrier Allocation: ............ ............ .............. ............ ............. ............ ............. .............. ............ ....... 383

2 APPENDIX...................................................................................................................................................................385

2.1 HANDOVER THRESHOLDS &ALGORITHMS .................................................................................................................3852.1.1 Functional Diagram Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality andpower budget)........................................................................................................................................................ 3852.1.2 Rules: Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and powerbudget), Power Control disabled............ ........... .............. ........... ............. ............. ............ ............... ............ ........... 386

2.1.2.1 Inter-cell/Inter-system Handover due to level ............ ............ ............. ............ ............ .............. ............. 3862.1.2.1.1 Handover Decision / Handover Trigger Conditions ............ ............. ............ ............. ............ ......... 3862.1.2.1.2 Target Cell List Generation .......................................................................................................... 387

2.1.2.2 Intra-cell handover (quality)......... .............. ............ ............ ............. ............ ............. .............. ............. .. 3892.1.2.3 Inter-cell/Inter-system Handover due to quality........... ............. ............ ............. ............ ............... ........ 391

2.1.2.3.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 3912.1.2.3.2 Target Cell List Generation .......................................................................................................... 392

2.1.2.4 Inter-cell/Inter-system Handover due to distance............ ............. ............ ............. ............ ............... .... 3932.1.2.4.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 3932.1.2.4.2 Target Cell List Generation .......................................................................................................... 393

2.1.2.5 Inter-cell/Inter-system Handover due to better cell (power budget handover) ........... .............. ............ . 3952.1.2.5.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 3952.1.2.5.2 Target Cell List Generation .......................................................................................................... 3972.1.2.5.1 Speed sensitive handover enabled ........... ............. ............ ............. ............ ............. .............. ...... 398

2.1.2.5 Inter-system Handover due to suifficient coverage .......... ............. ............ ............. ............. ............. .... 399

2.1.2.5.1 Handover Decision / Handover Trigger Conditions .............. .............. ........... ............. ............ ...... 3992.1.2.6 Forced Handover due to directed retry, preemption or O&M intervention ............. ............ ............ ....... 400

2.1.2.6.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... ............. ............ ........ 4002) The averaging of both RXLEV_DL values (2G neighbour cells) as well as RSCP values (3G neighbour cells)is done with an averaging window whose length is defined by parameter HOAVPWRB (SET HAND)2.1.2.7 FastUplink Handover (Intra-BSC only)... ............ ............. ............ ............. ............ ............. ............ .............. ............. 4002.1.2.7 Fast Uplink Handover (Intra-BSC only) ............. ............ ............. ............ ............. ............ ............... ...... 401

2.1.2.7.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... ............. ............ ........ 4012.1.2.7.2 Target Cell List Generation .......................................................................................................... 401

2.1.2.8 Inter-cell Handover due to BSS Resource Management Criteria (Traffic HO) ............ ............. ............ 4032.1.2.8.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... ............. ............ ........ 4032.1.2.8.2 Target Cell List Generation .......................................................................................................... 407

2.2 HIERARCHICAL CELL STRUCTURE.............................................................................................................................4092.2.1 Cell ranking for power budget handovers (non-imperative handover).......... ............. ............ ............ ........... 409

2.2.1.1 Speed sensitive handover enabled ............ ............. ............. ............ ............. ............ .............. ............. 4102.2.2 Cell ranking for imperative handovers (due to level, quality and distance) and forced handover (directed

retry) ...................................................................................................................................................................... 4112.2.2.1 Ranking method 0............ ............ ............. ............ ............. ............ ............ ............. .............. ............. .. 4112.2.2.2 Ranking method 1............ ............ ............. ............ ............. ............ ............ ............. .............. ............. .. 414

2.2.3 Target Cell Ranking for Traffic Handover with HCS..... ............. ............. ............. ............ ............. .............. .. 4162.3 POWER CONTROL THRESHOLDS &ALGORITHMS........................................................................................................ 417

2.3.1 Functional Diagram: Power Control Thresholds - Power Increase / Power Decrease (Classic Power Control).............................................................................................................................................................................. 417

2.3.2 Rules: Power Control Thresholds: Power Increase / Power Decrease ............ ............ ............. ............ ....... 4182.3.2.1 Power Increase .................................................................................................................................... 4182.3.2.2 Power Decrease............. ............. ............ ............ ............. ............ ............ ............. ................ ............. .. 419

2.3.3 Classic and Adaptive Power Control..... ............. ............. ............. ............ ............ ............. .............. ............. 4202.2.3.1 Introduction ........................................................................................................................................... 4202.3.3.2 Classic Power Control decision process ............. ............ ............. ............ ............. ............ ............... .... 420


6/474



2.3.3.3 Adaptive Power Control decision process............ ............ ............. ............. ............ ............. ............. .... 4212.3.3.4 Differences between CLASSIC and ADAPTIVE power control decision ............ ............. ............ ......... 4212.3.3.5 Functional sequence of a BS and MS power control procedure............... ............ ............. ............ ....... 423

2.3.3.5.1 BS power control procedure.............. ............ ............. ............ ............. ............ ............. .............. .. 4232.3.3.5.2 MS power control procedure ............ ............ ............ ............. ............. ........... ............. ................ .. 424

2.3.3.6 Comparison of timing behaviour of different Power Control types - MS Power Control, BS PowerControl, classic and adaptive ............................................................................................................................4252.3.3.7 Further differences between CLASSIC and ADAPTIVE Power Control ............ ............ ............. .......... 4272.3.3.8 Interaction of Power Control Measurement Preprocessing and Power Control Decision ............ ........ 428

2.4 INTERWORKING OF HANDOVER AND POWER CONTROL ............................................................................................... 4292.4.1 Functional Diagram: Inter-cell Handover and Intra-cell Handover, Power Increase and Power Decrease.... 4292.4.2 Rules ...........................................................................................................................................................430

2.5 SERVICE DEPENDENT HANDOVER AND POWER CONTROL ...........................................................................................4312.5.1 Introduction..................................................................................................................................................4312.5.2 SGxHOPAR and SGxPCPAR parameter values ............ ............ ............ ............. ............ ............. .............. .. 432

2.5.2.1 SGxHOPAR parameter values (Handover).... ............. ............ ............ ............. ............ ............. ............ 4322.5.2.2 SGxPCPAR parameter values (Power Control) ........... ............. ............ ............. ............. ............. ......... 4342.5.2.3 Effects on Call processing............ ............ .............. ............ ............. ............ ............. .............. ............. .. 435

2.6 REPORTING,DISPLAY AND BTS INTERNAL HANDLING OF RSCP VALUES FROM 3G NEIGHBOUR CELLS............................. 4362.7 MAPPING OF RXQUAL AND C/I VALUES ...................................................................................................................4382.8AMRLINKADAPTATION THRESHOLDS UPLINK........................................................................................................... 4392.9 BSC,MSC AND BTSOVERLOAD HANDLING............................................................................................................. 443

2.9.1 BSC Overload....... ............. ............ ............ ............. ............ ............. ............ ............ ................. ............ ....... 4432.9.1.1 BSC overload conditions..... ............. ............ ............ ............. ............ ............. ............ ............... ............ 4432.9.1.2 System reactions and overload regulation measures in case of BSC overload ............. ............. ......... 451

2.9.1.2 System reactions and overload regulation measures in case of BSC overload ............. ............. ......... 4512.9.1.2.1 Further important notes on BSC reactions ........... ............ ............. ............ ............. ............. ......... 452

2.9.1.3 Mechanisms for reduction of originating traffic and reduction of terminating traffic... .............. ............. 4532.9.1.3.1 Overload level management................. ............. ............. ............ ............. ............ ............... .......... 4532.9.1.3.2 Traffic reduction algorithms............ ............. ............ ............. ............. ............ .............. ............. .... 4542.9.1.3.3 Special overload supervision algorithm in case of BSC paging queue overflow...... ............. ........ 455

2.9.2 MSC Overload ............................................................................................................................................. 4552.9.2.1 System reactions and overload regulation measures in case of MSC overload........ ............. ............. .. 455

2.9.2.1.1 Special overload level escalation algorithm in case of MSC overload...... ............. ............. ........... 4552.9.3 BTS Overload .............................................................................................................................................. 457

2.9.3.1 BTS overload conditions ........... ............. ............. ............ ............. ............. ............ ............. ............. ...... 4572.9.3.2 Traffic reduction mechanisms in case of BTS overload ............ ............. ............ ............. ............ ......... 4632.9.3.3 System reactions and overload regulation measures in case of BTS overload..... ............ ............. ...... 464

2.9.4 Interaction of BTS Overload and BSC Overload..... ............. ............. ............. ............ ............. ............... ...... 4652.9.5 Effects on Performance Measurement Counters ............ ............. ............ ............. ............ .............. ............. 466

3 ALPHABETICAL COMMAND AND PARAMETER INDEX..... ............ .............. ............. ............ .............. ............. ...... 467


7/474



1 Database BR8.0

1.1 BR8.0 Object Tree of BSC database objects

Note: The objects BTSMOSUSW, TRAOSUSW, SCANCO, the scanner objects (SCANxxxx) as well as theobjects related to TD-SCDMA (objects subordinate to BTSMTD) are not considered in this document.


8/474



Notes:

1) The commands of this example database are basically presented in the sameorder as they are generated by DBAEM when generating an ASCII database froma database in binary format.

2) The parameters marked by grey background are new in BR8.0

(compared to BR7.0).

3) Changes of parameter values, value ranges and default values are indicated by

highlighted letters. Changes of parameter names are marked, too.

4) In BR6.0 the packages (e.g. PKGBTSB, PKGBSCT etc.) were removed so

that all parameters subordinate to one object (e.g. BTS) are included in oneand the same command (CREATE/SET BTS). The disadvantage is thatamong the huge number of parameters within one command it is hard to finda specific parameter quickly.I decided to use the following approach in this document:- For a better logical structure, the parameters are still grouped in thepseudo-packages (e.g. CREATE BTS [BASICS], SET BTS [CCCH] etc.) usedin the LMT GUI.- Within each package, an alphabetical order was used for the sequence ofparameters (as done by DBAEM) to facilitate the handling and overview.


9/474



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 ofthe addressing of the BSS. It simultaneously represents the objectwith 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 inthe BSS.

MELID=1;

object: MELrange: 1..47

Managed Element ID, this parameter defines the name resp. ID ofthe BSS in the Radio Commander (RC) area. The value entered for

MELID must match to the BSS_RDN in the RC database to ensurethe correct operation of the higher communication layers on the O&Mlink between BSC and RC.This parameter replaces the BSSNAME parameter which was usedin 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 commandparameters into packages anymore. Instead, all parameters of theprevious BSC packages were moved below the object BSC andappear in the DBAEM in the SET BSC command. The logical group[CONTROL] is normally only used on the LMT but was used here toallow 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 CellTraffic Recording logfile on the BSC disk. The feature Cell TrafficRecording or Cell Trace (CTR) is a feature used to record cellspecific call events for monitoring purposes in a similar way like IMSItracing (for details please see command CREATE CTRSCHED).The

parameter CFS specifies the maximum file size for the CTR tracelogfiles in the BSC directory. When a CTR tracing procedure is in

progress, the BSC writes the binary trace data to the open binarytrace file in the BSC directory TRACE_CTR. On call termination, atrace record is generated an written to the CTR trace logfile. The

parameter CFS specifies the maximum size of this CTR logfile. Whenthe trace logfile exceeds the size specified by CFS, it is closed andtransferred to the BSC directory READY_CTR. Form there it iscompressed to the directory DBFH_ZIP from where it is uploaded tothe RC at the next possible point of time (automatic upload takes

place every 5 minutes). A CTR logfile can also be automaticallyclosed and prepared for upload if the trace is still in progress. In thiscase a new open binary file is generated which records the nextevents of the call to be traced. In the RC, the uploaded files aredecompressed, merged and converted to ASCII for analysis by theDUIT application.


10/474



IMSIFSIZ=30,


unit: 1 Mbyte

range: 0..30

default: 30

IMSI file size, this parameter is associated to the feature 'IMSITracing' (see command CREATE TRACE) and specifies themaximum file size for the IMSI trace files in the BSC directory. Whenan IMSI tracing procedure is in progress, the BSC writes the binarytrace data to the open binary trace file in the BSC directoryTRACE_IMSI. The parameter IMSIFSIZ specifies the maximumallowed size of this binary trace file. When the tracing process isfinished the binary trace files are closed and compressed to the BSC

directory READY_IMSI. Form there they are compressed to thedirectory DBFH_ZIP from where they are uploaded to the RC at thenext possible point of time. When the maximum size has beenreached although the traced call is still in progress, the binary file isalso closed and compressed to the directory READY_IMSI for uploadand a new binary trace file is opened. In the RC, the uploaded filesare decompressed, reassembled and converted to ASCII for analysisby the DUIT application.

HDCFS=1,


unit: 1 Mbyte

range: 1-12

default: 1

HDC file size, this attribute indicates the maximum size of theHistory on Dropped Calls logfile on the BSC disk. The featureHistory on Dropped Calls (HDC or HDCTR, see also commandCREATe HDCTR and parameter EHDCTR in command CREATEBTS [BASICS]) is a feature used to record history data of droppedcalls (for details, please refer to the command CREATE HDCTR),

such as the last received MEASUREMENT REPORT messages aswell as layer 3 messages relevant for channel changes. The

parameter HDCFS specifies the maximum file size for the HDCTRtrace logfiles in the BSC directory. When a CTR tracing procedure isin progress, the BSC writes the binary trace data to the open binarytrace file in the BSC directory TRACE_HDCTR. When a call dropoccurs while the HDCTR feature is enabled, a HDCTR record isgenerated an written to the HDCTR logfile. The parameter CFSspecifies the maximum size of this HDCTR logfile. When the tracelogfile exceeds the size specified by HDCFS, it is closed andtransferred to the BSC directory READY_HDCTR. Form there it iscompressed to the directory DBFH_ZIP from where it is uploaded tothe 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 theapplication DUIT/RNA.

HDCFUPE=upPe0h,


range: upPe0h= no per. upl.

upPe1h = Upl. period 1h






upPe12h= Upl. period 12h

upPe24h= Upl. period 24h

default: upPe0h

HDC data file upload period, defines the time period between twouploads of logfiles for the feature History on Dropped Calls (fordetails, please refer to the command CREATE HDCTR). Setting this

parameter to upPe0h disables the periodic upload.


11/474



MASCLOGFS=3,


unit: 1 Mbyte

range: 1-6

default: 3

Maximum scanner logfile size, this attribute indicates the maximumsize of the scanner result file on the BSC disk. The file SCAN.TMP isthe scanner logfile on the BSC disk to which all scanner results ofscanners which were created BYFILE are written. This file isavailable in the BSC directory MEASURE_DIR. To upload thescanner results to the RC the file SCAN.TMP is closed, renamed toSCAN.LOG and transferred to the directory READY_MEAS. Form

there it is compressed to the directory DBFH_ZIP from where it isuploaded to the RC.The size threshold entered by MASCLOGFS determines themaximum allowed size of the file SCAN.TMP: when the entered sizeis reached for the file SCAN.TMP the SCAN.LOG is automaticallyuploaded to the RC. New measurement results are then written to anewly opened SCAN.TMP file.

MEDAFUPE=UPPE_0H,


range: UPPE_0h= no per. upl.

UPPE_1h = Upl. period 1h






UPPE_12h= Upl. period 12h

UPPE_24h= Upl. period 24h

default: UPPE_0h

Measurement data file upload period, defines the time periodbetween two uploads of measurement data files. Setting this

parameter to UPPE_0h disables the periodic upload.

MEDAFUST=0-0;


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 formeasurement data file upload.Parameter format: upload start hour - upload start minute.


12/474



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

SET BSC [TIMER]:

Attention: Since BR6.0 The DBAEM does not group the commandparameters into packages anymore. Instead, all parameters of theprevious BSC packages were moved below the object BSC andappear in the DBAEM in the SET BSC command. The logical group[TIMER] is normally only used on the LMT but was used here toallow 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 theBSSMAP message BLOCKING ACKNOWLEDGE. The MSCselects the terrestrial resources (A interface traffic channels) to beused 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 useddue to configuration of OMAL, LPDLS or SS7L etc.. The BSCinstructs the MSC to block resp. unblock single affected A-timeslotsby using the BSSMAP message BLOCKING/UNBLOCKING. As aresult, the MSC marks the affected timeslots as 'unavailable'. If agroup of A-interface timeslots is to be blocked simultaneously, theCIRCUIT GROUP BLOCKING/UNBLOCKING procedure is used

(see BSCT20).The timer T1 supervises the receipt of the BLOCKING/UNBLOCKING ACKNOWLEDGE message from the MSC. The valueof T1 must be higher than the MSC maximum reaction time and thetransmission time for the blocking/unblocking and the associatedacknowledge message. After a first T1 expiration the BSS repeatsthe BLOCKING/UNBLOCKING message. After a second expirationthe BSS marks the associated circuits as blocked without waiting forthe acknowledgement.

BSCT10=HLFSEC-10,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254default: HLFSEC-10

Reference: GSM 08.08 (04.08)

BSC timer T10, this timer determines the time to return theASSIGNMENT COMPLETEmessage in case of call setup andintra-cell handover. This timer is started on the sending of an

ASSIGNMENT COMMAND message and is normally stopped whenthe MS has correctly seized the new channels.

The value must be higher than the maximum transmission time of theASSIGNMENT COMMAND and the ASSIGNMENT COMPLETEmessage plus the maximum duration of an attempt to establish adata link multiframe mode.Note: Due to the SBS implementation T10 replaces the function ofthe 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 signaling failure (T8 andT10) is detected before transcoder failure (TTRAU)

T10purpose: 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 timein order to allow the MS to return to the old channel return to it if thehandover is not successful and to release the old channel if the MS islost during the handover procedure.

start: a) & b): sending of an ASSIGNMENT COMMAND by the BSCstop: a) & b): receipt of an ASSIGNMENT COMPLETE or an ASSIGNMENT

FAILURE from the MSexpiry action: a)Assignment procedure: Sending of an ASSIGNMENT FAILURE to

the MSC with cause 'radio interface message failure' followed by releaseof the call resources.b) Intra-cell handover: Sending of a CLEAR REQUEST to the MSC withcause 'radio interface message failure' followed by release of the callresources (CLEAR CMD received from MSC).


13/474



BSCT11=HLFSEC-16,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-16


BSC timer T11, this timer determines the maximum allowedqueuing time. This parameter is only relevant if the feature queuingis enabled (see parameter EQ in command SET BTS [OPTIONS]).When a TCH request for an assignment procedure (i.e. when theBSC receives an ASSIGNMENT REQUEST message from the MSC)is put into a queue due to TCH congestion, T11 determines themaximum time the TCH request may remain in the queue to wait fora 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 isreleased.

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 towait (possibly in vain) for the assignment of a TCH in a busy cell.Therefore it has to be carefully considered which waiting time can beregarded as acceptable from the subscriber's point of view. In otherwords: it makes no sense to set T11 to a too high value.- It is possible to accelerate the release of busy TCHs by anappropriate setting of the timer T3111 (see SET BTS [TIMER]). Thiscan decrease the queuing time considerably.- If the BSC receives an INTERCELL HANDOVER CONDITIONINDICATION from the BTS during the queuing time, the BSC directlysearches for an idle TCH in the target cell! In other words, during thequeuing time no SDCCH-SDCCH handover will ever be performed. If

no TCH can be found in the target cells, the TCH request isdiscarded from the queue.

BSCT11PUB=HLFSEC-16,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-16

BSC timer T11 public, this timer determines the maximum allowedqueuing time for TCH assignment requests 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 featurequeuing required by the U.S. market (see parameter EQ incommand SET BTS [OPTIONS]). This feature foresees a two queueconcept, one queue being used for ordinary subscribers (public) andone for priorized subscribers (WPS queue). The parameterBSCT11PUB defines the queing timer T11 (see parameter BSCT11which is used for ordinary queing) 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]).

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 allowedqueuing 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 parameterBSCT11WPS defines the queing timer T11 (see parameter BSCT11which is used for ordinary queing) for the WPS queue.

T11purpose: Limitation of the queuing time for an TCH request due to Assignmentstart: 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 radioresource available' followed by release of the call resources.


14/474



BSCT13=HLFSEC-50,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-50


BSC timer T13, this timer determines the RESET guard period atthe BSS.The timer T13 is a guard timer which is started after thereceipt of the BSSMAP message RESET (see also BSCT4). It

provides the time for the BSS to release all affected calls and toerase all affected references. After expiration of T13 the BSS sends aRESET ACKNOWLEDGE message to the MSC. The value of T13must 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 mustbe higher than the value of T13 plus the transmission time of theRESET and the RESET ACKNOWLEDGE message (it isrecommended to set the MSC-timer T16 to 35s). It is recommendedto 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 ignoretimer which is used only in case of MSC overload. BSCT17 is used inclose relation to the timer BSCT18 (see below).

For further details about the exact function of the timer BSCT18within the BSS overload regulation please refer to the section BSC,BTS and MSC overload Handlingin the appendix of thisdocument. As MSC, BSC and BTS overload handling are closelyinterwoven, the overload conditions and traffic reduction mechanismsare explained in an own chapter that comprises all possible scenariosof overload and overload handling as well as the references to therelevant parameters.

BSCT18=HLFSEC-60,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-60


BSC timer T18, this timer represents the overload observationtimer andit is used in all cases of BSS overload regulation:BSC overload regulation, MSC overload regulation and BTS overloadregulation (see parameters BSCOVLH, MSCOVLH and BTSOVLH incommand SET BSC [BASICS]).

For further details about the exact function of the timer BSCT18within the BSS overload regulation please refer to the section BSC,BTS and MSC overload Handlingin the appendix of thisdocument. As MSC, BSC and BTS overload handling are closely

interwoven, the overload conditions and traffic reduction mechanismsare explained in an own chapter that comprises all possible scenariosof overload and overload handling as well as the references to therelevant parameters.

BSCT19=HLFSEC-12,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-12


BSC timer T19, this timer determines the time to receive RESETCIRCUIT ACKNOWLEDGEat the BSC. The RESET CIRCUIT

procedure is started either by the BSC or the MSC if a single circuithas to be put into the idle state due to abnormal SCCP connectionrelease. If the RESET CIRCUIT procedure is initiated by the BSC itsends the BSSMAP message RESET CIRCUIT to the MSC whichclears all associated call transactions, puts the affected trafficchannel to the idle state and returns the message RESET CIRCUIT

ACKNOWLEDGE to the BSC. If T19 expires before the receipt of theRESET CIRCUIT ACKNOWLEDGE the BSC repeats the RESET

CIRCUIT PROCEDURE and restarts T19.


15/474



BSCT20=HLFSEC-12,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-12


BSC timer T20, this timer determines the time to receive CIRCUITGROUP BLOCKING ACKNOWLEDGE. The MSC selects theterrestrial resources (A interface traffic channels) to be used for acall. The MSC therefore needs to be informed about any A-interfacecircuits that are out of service in the BSC or cannot be used due toother reasons. If a group of A-interface channels cannot be used anymore (e.g. due to failure of a TRAU) the BSC instructs the MSC to

block the affected A-interface circuits by using the BSSMAPmessage CIRCUIT GROUP BLOCKING/UNBLOCKING. As a result,the MSC marks all affected timeslots as 'unavailable'. The timer T20supervises the receipt of the BLOCKING/ UNBLOCKING

ACKNOWLEDGE message from the MSC. The value of T20 must behigher than the MSC maximum reaction time and the transmissiontime for the blocking/unblocking and the associated acknowledgemessage. After a first T20 expiration the BSS repeats theBLOCKING/UNBLOCKING message. After a second expiration theBSS marks the associated circuits as blocked without waiting for theacknowledgement.

BSCT3=HLFSEC-50,

object: BSC [TIMER]

unit: HLFSEC=0,5sSEC5=5s

range: 0..254

default: HLFSEC-50


BSC timer T3, this timer determines the frequency of the BSSMAPmessage RESOURCE INDICATIONsending. The RESOURCEINDICATION message contains information about the number of

available TCHs per interference band for a specific cell and is sent byfrom the BSC to the MSC if the BSC has previously received theBSSMAP message RESOURCE REQUEST from the MSC. TheRESOURCE REQUEST message indicates a specific cell identifierand can trigger the transmission a single RESOURCE INDICATIONas well as the transmission of several RESOURCE INDICATIONs ina periodic manner. For the periodic transmission of RESOURCEINDICATION the timer T3 determines the period between twoconsecutive transmissions of the RESOURCE INDICATION.

BSCT3121=HLFSEC-50,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254default: HLFSEC-10

Reference:

BSC timer T3121, this parameter represents a timer which is used tosupervise the 2G-3G handover procedure towards an UTRAN-FDDcell. T3121 is the 2G-3G handover equivalent to the timer T8 (see

parameter BSCT8). In this case the BSC has sent a BSSMAPHANDOVER REQUIRED with a UMTS 3G neighbour cell (seecommand CREATE ADJC3G) in the target cell list to the 3G MSC.When the target RNC has provided the target channel data and andthe 3G-MSC has sent the associated HANDOVER COMMAND to theBSC, the BSC forwards this HANDOVER COMMAND to themultiRAT MS and simultaneously starts the timer T3121. The MS, onreceipt of the HO CMD, switches over to the target channel in theUMTS 3G neighbour cell and, in case of successful link setup, sendsthe RRC HANDOVER COMPLETE towards the target RNC which inturn sends an Iu RELOCATION COMPLETE message to the 3GMSC. The timer T3121 is stopped, when the BSC has received theCLEAR COMMAND with cause handover successful. When itexpires, the BSC sends a CLEAR REQUEST with cause radiointerface message failure to the 3G-MSC to indicate the drop of theconnection during the handover procedure. This event is counted as

a call drop by the PM counters NRFLTCH (subcounter 9) andNRCLRREQ (subcounter cause: radio interface message failure) andwill thus appear as a call drop event in the PM statistcs.

Note: T3121 has the same function for 2G-3G handover from GSM toa UTRAN-TDD neighbour cell (TD-SCDMA). It is started when theHANDOVER REQUIRED is sent and it is stopped, when the CLEARCOMMAND with cause handover successful is received.


16/474



BSCT4=HLFSEC-60,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-60


BSC timer T4, this BSSMAP timer determines the time to return aBSSMAP RESET ACKNOWLEDGE message. The BSC sends theBSSMAP message RESET to the MSC in the event of a failure whichleads to the loss of transaction reference information. The purpose ofthe RESET message is to initialize the BSSMAP relation betweenMSc and BSC and to put all affected circuits into the idle state. Whenthe 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 aRESET ACKNOWLEDGE message. The timer T4 is started when theBSC transmits the RESET message to the MSC and watches overthe receipt of a RESET ACKNOWLEDGE from the MSC. If noRESET ACKNOWLEDGE has been received before expiry of T4, theBSC 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 RESETACKNOWLEDGE 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 thiscase equivalent timers are used: The MSC timer T16 supervises the

receipt of the RESET ACKNOWLEDGE message (equivalent to theBSC timer T4) and the guard period in the BSC for the transmissionof 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


GSM 05.08

Default values changed in BR8.0!

BSC timer T7, this timer determines the waiting time for aHANDOVER COMMAND from the MSCafter transmission of aHONDOVER REQUIRED to the MSC. If the BTSE has sent aHANDOVER CONDITION INDICATION message and the handoveris to be executed by the MSC (if the first target cell is an external oneor if LOTERCH or LOTRACH (see SET HAND [BASICS]) are set toFALSE) or if the MSC has initiated a HANDOVER CANDIDATEENQUIRY procedure, the BSS sends a HANDOVER REQUIREDmessage 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 thistime 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. noHO CMD was received from the MSC), the BSC call processingterminates the 'waiting for HO CMD' state and the receipt of new HOCOND IND message directly leads to the transmission of an updatedHO RQD. All HO CMDs received after expiry of T7 are discarded bythe BSC.

Notes:1) Attention:Especially in case of Inter-MSC handovers or if thefeatures queuing or/and preemption are used for incoming MSCcontrolled handovers, the handover completion may take a long timedue to the additional handover of the preempted call in the target cell.This has to be considered by setting BSCT7 to a sufficiently highvalue in the originating BSC. If BSCT7 is too short, the HO CMDmight be received after T7 expiry. This leads to the discarding of theHO CMD and thus to a forced release of the call by the MSC as theMSC supervises the by an own timer (Trr7 in Siemens MSC) which isstarted when the HO CMD is transmitted and which waits for the

T7purpose: Waiting time for a HANDOVER COMMAND from the MSCstart: sending of HANDOVER REQUIRED by the BSCstop: - 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


17/474



handover successful indication from the target side or aHANDOVER FAILURE (DTAP) from the originating side. As theexperience has shown, during inter-MSC handover procedures it maytake more than 2suntil the HANDOVER COMMAND is received fromthe MSC (in case of inter-PLMN handover it may be even more), it isrecommended 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 thetarget cell) the time for the receipt of the HO CMD in the originatingBSC 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 timerT_HO_REJ. Recommended setting:

THORQST (HAND) > BSCT7 (BSC)

BSCT8=HLFSEC-10,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-10


BSC timer T8, this timer determines the time to receive theHANDOVER COMPLETEmessage. T8 is defined as the time thatBSC layer 3 will wait for a handover to complete before releasing thesource channel.

The value must be bigger than the sum of the time for all messagesto 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 signaling failure (T8 andT10) is detected before transcoder failure (TTRAU)

T8purpose: 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 notsuccessful and to release the old channel if the MS is lost.

start: transmission of a HANDOVER COMMAND from the BSC to the MSstop: a) intra-BSC handover: receipt of a HANDOVER COMPLETE or a

HANDOVER FAILURE from the MSb) inter-BSC handover: receipt of a CLEAR COMMAND from the MSCor HANDOVER FAILURE from the MS

expiry action: Sending of a CLEAR REQUEST to the MSC with cause 'radio interfacemessage failure' followed by release of the call resources (CLEAR CMDreceived from MSC).


18/474



BSCTQHO=HLFSEC-20,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-20


BSC timer for queuing of handover, this timer determines themaximum allowed queuing time for incoming handover. This

parameter is only relevant if the feature queuing is enabled (seeparameter EQ in command SET BTS [OPTIONS]). When a TCHrequest for an incoming MSC-controlled handover (i.e. when the BSCreceives a HANDOVER REQUEST message from the MSC) is putinto a queue due to TCH congestion, TQHO determines the

maximum time the TCH request may remain in the queue to wait fora busy TCH to become idle. If the TCH request for the incominghandover cannot be served within this time frame and TQHO expiresin case of incoming MSC-controlled HO, the TCH request is rejectedwith a HANDOVER FAILURE. As a result, if there is another targetcell available for the handover procedure, the MSC will attemptanother HO REQUEST procedure towards the next target BTS.#

Note:It is possible to accelerate the release of busy TCHs by anappropriate setting of the timer T3111 (see SET BTS [TIMER]). Thiscan 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 timerdetermines the maximum allowed queuing time for TCH requests dueto incoming handover in the public queue. This parameter is onlyrelevant if the feature Wireless Priority Service (WPS) is applied,which is a special enhancement of the feature queuing required bythe U.S. market (see parameter EQ in command SET BTS[OPTIONS]). This feature foresees a two queue concept, one queuebeing used for ordinary subscribers (public) and one for priorizedsubscribers (WPS queue). The parameter BSCTQHOPUB definesthe queing timer TTQHO (see parameter BSCTQHO which is usedfor 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 timerdetermines the maximum allowed queuing time for TCH requests dueto incoming handover in the public queue. This parameter is onlyrelevant if the feature Wireless Priority Service (WPS) is applied(see parameter BSCTQHOPUB). The parameter BSCTQHOWPS

defines the queing timer TQHO (see parameter BSCTQHO which isused for ordinary queing) for the WPS queue.

TQHOpurpose: Limitation of the queuing time for an TCH request due to incoming

MSC-controlled handoverstart: 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 resourceavailable' to the MSC followed by release of the call resources.


19/474



Setting the global parameters of the BSC:

SET BSC [BASICS] :

Attention: Since BR6.0 The DBAEM does not group the commandparameters into packages anymore. Instead, all parameters of theprevious BSC packages were moved below the object BSC andappear in the DBAEM in the SET BSC command. The logical group[BASICS] is normally only used on the LMT but was used here toallow 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, inpercentage (steps of 10 %, from 0% to 90%), the acceptabledegradation of packet service throughput (maximum sustainablethroughput), before an upgrading of radio resources (i.e. TCHresources on the Um) is attempted.

During a TBF lifetime, due to variations in radio conditions, either theBLER or the used CS/MCS coding scheme can change, leading to achange in the maximum sustainable throughput. The maximumsustainable throughput (MST) is defined as the maximum throughputthat would be achieved by a given TBF if it was alone on the multislotconfiguration, 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 isperformed periodically, with a periodicity defined by the parameterUPGRFREQ (see below). As a general rule, only a decrease of themaximum sustainable throughput is considered; an increase of theMST will not lead to any system reactions, as a downgrading ofradio resources due to MST criteria is not performed. Moreover,since the variations in the maximum sustainable throughput canhappen 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 maximumtolerable degradation of the peak throughput, the upgrading of radioresources is attempted. The upgrade is performed by adding oneadjacent timeslot timeslot to the currently used ones (i.e. the PCU willsend a PDCH_Upgrade_Request message to the TPDC), providedthat the conditions regarding horizontal allocation and the percentage

of idle timeslots are verified (see parameter GASTRTH in commandCREATE PTPPKF).

Note: As long as the one radio resource a time algorithm isimplemented it is suggested to set the ACCEPTGDEGR attribute to0 (no degradation allowed, radio resource upgrading alwaysattempted as soon as the upgrading condition is detected), in order toreach the required radio resource allocation in several steps.


20/474



AISAT=FALSE,


range: TRUE, FALSE

default: FALSE

A interface via satellite, this attribute indicates whether the Ainterface resp. SS7 link is realized via satellite link (TRUE) or not(FALSE). If the A interface link is configured as satellite link, thegenerally higher signal delay must be particularly considered bya) the higher layers on the CCS7 link (e.g. BSSAP) andb) 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 slowsdown all signaling transactions. It might be necessary to extendselected timers to higher values to avoid undesired effects.b) If the A interface is realized via satellite link the CCS7 errorcorrection method must be set to 'preventive cyclic retransmissionerror correction' (see CREATE SS7L, parameter ERRCORMTD).

Note: Also the Asub interface (parameter ASUBISAT, see below) andthe Abis interface (see parameter LPDLMSAT in commandCREATE/SET BTSM) can be configured as satellite link. However,only one of the mentioned interfaces should be configured as satellitelink at the same time, because multiple satellite links within a BSSmay cause an overall message and procedure delay that might leadto expiry of procedure supervision timers that are normally adapted to

the propagation delay of terrestrial signalling links or at least to onlyone satellite link in the path. Although multiple satellite links are notofficially tested and released, the BSC command interpreter andDBAEM do not perform any checks to avoid multiple satellite links - itis up to the operator to follow this rule.

AMONTH=ENABLED(30)-ENABLE(60)-ENABLED(90),


range: ENABLED(1..100),

DISABLED

default: ENABLE(30) (minor)

ENABLE(60) (major)

ENABLE(90) (critical)

A-interface TCH monitoring thresholds, determines the state andthe threshold values for the minor, major and critical QOS alarms forthe traffic channels on the A-interface. The entered threshold valuerepresents the percentage of unavailable traffic channels on the A-interface. If the number of unavailable A-interface traffic channelsexceeds the entered threshold, the alarm messages UNAVAILABLE

AINT TCH THRESHOLD MINOR, MAJOR or CRITICAL (error ID242, 243 and 244) are output. The threshold values can only beassigned if the previous attribute is set to ENABLE.


21/474



ASCIONECHMDL=FALSE,


range: TRUE, FALSE

default: FALSE

ASCI one channel model, this parameter is only relevant if thefeature ASCI is enabled (see parameter ASCISER in command SETBTS [CCCH]) and determines whether the ASCI one channel modelis enabled (TRUE) or disabled (FALSE) for ASCI VGCS goup calls.FALSE means that the standard 1,5 channel model is enabled.

When a VGCS voice group call is set up (one dispatcher and severalother called service subscribers in the group call area), for the called

service subscribers basically only one downlink channel (ASCIcommon TCH) is provided, i.e. they can only listen to the dispatcher.However, a service subscriber has the possibility to request an uplinkchannel to transmit speech to the other group call partners by

pressing the PTT (push to talk) button on the ASCI phone.In this situation, when ASCIONECHMDL is set to FALSE (1,5channel mode), the following happens: when the service subscriberrequests an uplink TCH by pressing the PTT button in order totransmit speech, the BSC assigns a completely new TCH to thesubscriber in addition to the alredy existing downlink TCH - thus theservice subscriber occupies one and a half TCHs (therefore called1,5 channel mode).

Setting ASCIONECHMDL to TRUE guarantees a more economicutilization of the radio TCH resources: when the service subscriber

requests an uplink TCH via the PTT button in order to transmitspeech, the BSC only assigns an uplink channel to the alreadyexisting downlink channel, so that in the end only one ordinary two-way TCH is occupied by the service subscriber (1 channel mode).

ASMONTH=ENABLED(30)-ENABLE(60)-ENABLED(90),


range: ENABLED(1..100),

DISABLED

default: ENABLE(30) (minor)

ENABLE(60) (major)

ENABLE(90) (critical)

A-interface signaling monitoring thresholds, determines the stateand the threshold values for the minor, major and critical QOS alarmsfor the SS7 signaling channels on the A-interface. The enteredthreshold value represents the percentage of unavailable SS7 linkson the A interface. If the number of unavailable SS7 links exceedsthe entered threshold, the alarm messages UNAVAILABLE SS7 LINKTHRESHOLD MINOR, MAJOR or CRITICAL (error ID 236, 238 and241) are output. The threshold values can only be assigned if the

previous attribute is set to ENABLE.

ASUBENCAP=FALSE,


range: TRUE, FALSE

default: FALSE

Asub enhanced capacity allowed, this attribute indicates whetherthe creation of PCMS objects in single trunk mode is allowed. Singletrunk mode (ASUBENCAP=TRUE) means that all physical ports (Aand B ports) of a QTLP can be used for the connection of one TRAU.For further details please refer to the explanation provided for the

parameter WMOD in the command CREATE PCMS.


22/474



ASUBISAT=FALSE,


range: TRUE, FALSE

default: FALSE

Asub LAPD channel via satellite, this attribute indicates whetherthe Asub resp. LPDLS is realized via satellite link (TRUE) or not(FALSE). If the Asub interface link is configured as satellite link, thegenerally higher signal delay must be particularly taken into accountby the LAPD layer 2 functions of the TRAU O&M link (LPDLS) andb) the higher layers on the CCS7 link (e.g. BSSAP) andc) the CCS7 layer 2 functions.

Setting ASUBISAT to TRUE has the following consequences:a) The LAPD timer T200 (waiting timers for LAPD acknowledgementframes) as well as the associated window sizes (the 'window size' issimply the number of I-frames that may be sent without anyacknowledgement from the opposite side) are automatically extendedaccording to the following table:

The extension of T200 ensures that the higher signal delay on the

link does not lead to unnecessary retransmission of LAPD layer 2frames, while the extension of the window size avoids further delaysdue to additional acknowledgement waiting times.b) BSSAP timers (e.g. BSCT7, BSCT8 etc., see SET BSC [BASICS])have to be carefully checked as the delay on the lower layers slowsdown all signaling transactions. It might be necessary to extendselected timers to higher values to avoid undesired effects.c) If the Asub interface is realized via satellite link the CCS7 errorcorrection method must be set to 'preventive cyclic retransmissionerror correction' (see CREATE SS7L, parameter ERRCORMTD).

Notes:- The satellite mode of the Asub link has to be activated in the TRAUas well. This is done by the parameter ASUBLPDLSAT in thecommand SET LPDLS TEITSL (at the TRAU LMT). The effect is the

same as described above - just for the opposite direction.- Also the A interface (parameter AISAT, see above) and the Abisinterface (see parameter LPDLMSAT in command CREATE/SETBTSM) can be configured as satellite link. However, only one of thementioned interfaces should be configured as satellite link at thesame time, because multiple satellite links within a BSS may causean overall message and procedure delay that might lead to expiry of

procedure supervision timers that are normally adapted to thepropagation delay of terrestrial signalling links or at least to only onesatellite link in the path. Although multiple satellite links are notofficially tested and released, the BSC command interpreter andDBAEM do not perform any checks to avoid multiple satellite links - itis up to the operator to follow this rule.

BSCOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

BSC overload handling, determines whether BSC overload

handling is enabled or not. For further details about the BSC overloadregulation please refer to the section BSC, BTS and MSC overloadHandlingin the appendix of this document. As MSC, BSC and BTSoverload handling are closely interwoven, the overload conditionsand traffic reduction mechanisms are explained in an own chapterthat comprises all possible scenarios of overload and overloadhandling as well as the references to the relevant parameters.

Further parameters relevant for BSC overload handling:- BSCT18 and BSCT17 (see command SET BSC [TIMER])- OVLSTTHR and OVLENTHR (SET BSC [BASICS], see below).


23/474



BTSOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

BTS overload handling, determines whether BTS overload handlingis enabled or not. For further details about the BTS overloadregulation please refer to the section BSC, BTS and MSC overloadHandlingin the appendix of this document. As MSC, BSC and BTSoverload handling are closely interwoven, the overload conditionsand traffic reduction mechanisms are explained in an own chapterthat comprises all possible scenarios of overload and overload

handling as well as the references to the relevant parameters.Further parameters relevant for BTS overload handling:BSCT18 and BSCT17 (see command SET BSC [TIMER])

CBCPH = PH1_CBC,


range: PH1_CBC, PH2_CBC

default: PH1_CBC

CBC phase, this parameter defines the type of Cell BroadcastCenter connected to the BSC. The setting of the CBCPH is related tothe parameter Channel Indicator, which identifies the channel onwhich the message has to be broadcast. The two possible settingsfor this parameter are BASIC (value = 0) or EXTENDED (value = 1).The support of the EXTENDED channel for the Mobile Stations isoptional.

From the BSC side, the old CBC interface (without Channel_Indicatorparameter) is still supported. In this sense the RC/LMT operator canset the database flag CBCPH to PH1_CBC to indicate that the

connected CBC uses the old interface (< BR6.0), or to PH2_CBC toindicate that the connected CBC supports the new Channel Indicatorparameter value.

Note: The support of the Channel Indicator has been implementedonly at CBC-BSC interface level, this means that on the A-bisinterface the EXTENDED channel is not implemented, as no mobilesupports this feature at the moment. So the customer can choose aCBC centre implementing the new interface (including thechannel_indicator parameter and setting theCBC phase = 2), but onlythe BASIC channel can be specified in the channel_indicator fieldfrom the CBC operator.

CCHANTFACT=FALSE,


range: TRUE, FALSEdefault: FALSE

Channel change notification active, this flag determines whetherChannel Change Notication (CCN) is enabled in the BSC (TRUE) ornot (FALSE).

CICFM=GSM,


range: GSM, NOTSTRUCT

default: GSM

CIC format, this parameter specifies the format of the circuitidentification code (CIC). This parameter has an influence on theallowed value range for the high CIC number (see parameter HCICN(CREATE PCMA)).

CITASUP=FALSE,


range: TRUE, FALSE

default: FALSE

Cell ID and Timing Advance Support, this parameter is relevant forthe feature Location Based Services and represents the flag toenable the transmission of the Timing Advance (TA) in theCOMPLETE LAYER3 INFO (which the BSC sends to the MSC duringany connection setup) in addition to the Cell Identifier (CI).

CPOLICY Parameter cancelled in BR8.0due to multi-layer service concept.


24/474



CSCH3CSCH4SUP=TRUE,


range: TRUE, FALSE

default: FALSE

reference: GSM 03.64

rcommended value: TRUE

CS3 and CS4 support, this parameter allows to enable or disablethe feature GPRS Coding Scheme 3 and Coding Scheme 4 generallyin the BSC. The same parameter is also available in the PTPPKFobject where it can be used to enable/disable CS3/CS4 individually

per BTS (see parameter CSCH3CSCH4SUP in command CREATEPTPPKF).

The coding schemes 3 and 4 allow a considerably higher GPRS data

throughput than the previously available coding schemes 1 and 2.

The following gross data rates according to the selected codingscheme can be achieved by the different coding schemes dependingon C/I.

GPRS Coding scheme maximum gross data rate

CS-1 9,05 kbit/s

CS-2 13.4 kbit/s

CS-3 15.6 kbit/s

CS-4 21.4 kbit/s

Similar to the AMR speech coding, where - depending on the currentradio conditions - a better speech quality is achieved by providing thesmallest possible channel coding portion and the biggest possiblespeech coding portion, the higher data throughput of CS-3 and CS-4

is achieved by a smaller channel coding portion within the radio TCH.The basic principle is: the better the radio interface quality (definedby C/I - Carrier/Interference), the higher the available bandwidth(bitrate) for the user data coding and the smaller the bandwidth(bitrate) for channel coding and vice versa (Channel Coding is theterm that represents the radio transmission error protectionoverhead, while Data Coding represents the coding of the user datato be transmitted).

To make sure that, depending on the current radio conditions(defined by C/I in dB), the best possible GPRS coding scheme isused, a GPRS coding scheme link adaptation is applied, whichfeatures the permanent supervision of the C/I radio conditions andthe adaptation of the GPRS coding scheme to these conditions toachieve the best possible throughput.

As the coding schemes CS-3 and CS-4 require two concatenatedPCU frames, two 16kbit/s TCHs on the Abis interface are necessaryfor each radio interface timeslot (PDCH). In detail, the relation ofcoding scheme and the required number of concatenated PCUframes is displayed in the following table:

GPRS coding scheme Radio Block Size in Bitsfor DL/UL

No. of Concatenated

PCU Frames

CS-1 181 1 (max. 216 payload bits)CS-2 268 2 (max. 488 payload bits)

CS-3 312 2 (max. 488 payload bits)

CS-4 428 2 (max. 488 payload bits)

Consequently, the GPRS coding scheme link adaptation, which canalso be regarded as coding scheme upgrade and coding schemedowngrade also might cause the seizure (for coding schemeupgrade) or/and release (for coding scheme downgrade) of anadditional Abis TCH.

Channel Coding Data Codinggood radio conditions

Channel Coding Data Codingpoor radio conditions


25/474



DGRSTRGY

Parameter moved to BTS object in

BR8.0!

moved to BTS object(see CREATE BTS [BASICS]).

DGRSTRGYBCNT=DISABLED,


range: ENABLED, DISABLEDdefault: DISABLED

Downgrade strategy busy counting, this flag enables/disables thefunctionality that considers the setting of the parameter DGRSTRGY(see command CREATE BTS [BASICS]) for the traffic loadcalculation.

If DGRSTRGYBCNT is set to ENABLED, the BSC considers thesetting of the DGRSTRGY parameter in the- radio TCH load calculation and- Abis TCH load calculationas follows:a) If DGRSTRGY indicates GPRS downgrade not allowed (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all(non-reserved) TCHs which are currently busy due to GPRS traffic(PDCH) are considered as busy like any other TCH which iscurrently seized by a CS call.b) If DGRSTRGY indicates GPRS downgrade allowed (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST orDOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs whichare currently busy due to GPRS traffic (PDCH) are considered as

idle.

If DGRSTRGYBCNT is set to DISABLED, the BSC considers all(non-reserved) TCHs which are currently busy due to GPRS traffic(PDCH) as busy (like any other TCH currently seized by a CS call)in any case, no matter what the setting of DGRSTRGY is.

Note: This functionality is available via patch in BR8.0 starting fromTDPC load 32 (please see release documentation for details).

DLAPDOVL=TRUE,


range: TRUE, FALSE

default: TRUE

Downlink LAPD Overload, this parameter allows to enable ordisable the procedure that detects the downlink LAPD overload. If theBTSE has detected an overload situation on the LAPD link based onthe LAPD load thresholds SLAPDOVLTH (see command CREATEBTSM), it sends the O&M message LAPD OVERLOAD towards theBSC. If DLAPDOVL=TRUE, the BSC starts traffic reduction

measures as described in the section BTS overload in the chapterBSC, MSC and BTS Overload handling in the appendix of thisdocument.

The parameters relevant for BTSE LAPD overload handling areFLAPDOVLTH, SLAPDOVLTH and LAP

br8 database description parameters)

Documents