BSC Database Parameter Description BR8

7/30/2019 BSC Database Parameter Description BR8

http://slidepdf.com/reader/full/bsc-database-parameter-description-br8 1/498

s

Siemens Base Station (SBS)

BSC Database Parameter Description BR8.0 - DRAFT

Version 18.04.2006



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

2 / 499 Eckardt Bertermann, Network Engineering GERAN - COMMERCIALLY NOT BINDING

made by:

Eckardt BertermannSIEMENS AG

COM MN PG NT NE 1, Network Engineering GERANTel.: +49 89 636 47691FAX: +49 89 636 40109e-mail: [email protected]

GPRS contributions by:

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

Please consider the remarks on the next page!





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 document’s 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 document’s 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!

• 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 f i rs t , 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.)

!





Contents:

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

1.1 BR8.0 OBJECT TREE OF BSC DATABASE OBJECTS..................................................................................... 7 1.2 BSC D ATABASE COMMANDS AND P ARAMETERS................................................................................... 9

Setting the object entry point and time and date for the BSS:.................................................................. 9 Setting the BSC control values for periodic measurement data file upload: ............................................ 9 Setting the timing values for BSSMAP control and BSC overload handling: ......................................... 12 Setting the global parameters of the BSC: ............................................................................................. 19 Creating new database parameters without info model change: ........................................................... 49 Setting the alarm priorities of the BSS functional objects:...................................................................... 50 Setting the remote Inventory data of the BSC Equipment:..................................................................... 52 Setting the alarm priorities of the BSCE objects:.................................................................................... 53 Creating the Power Supply: .................................................................................................................... 55 Creating the spare PCM interface boards: ............................................................................................. 56 Creating the PCM interface boards: ....................................................................................................... 56 Creating the common attributes for all PCUs belonging to the entire BSC:........................................... 57 Creating the PCU objects: ...................................................................................................................... 64 Creating the PCM links for the Abis interface:........................................................................................ 69 Creating the PCMS link:.......................................................................................................................... 73 Creating the TRAU:................................................................................................................................. 75

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

Creating the LPDLS links:....................................................................................................................... 79 Creating the PCMA link:.......................................................................................................................... 80 Setting the uplink and downlink volumes for specific PCMA timeslots:.................................................. 86 Creating the PCMG link: ......................................................................................................................... 87 Creating the physical link connection on the GPRS Gb interface (Frame Relay Link): ........................ 89 Creating the end-to-end communication between BSS and SGSN: Network Service Virtual Connection(NSVC):................................................................................................................................................... 90 Creating the BTS Site Manager:............................................................................................................. 91 Creating the Common BTS data of a BTSM for Dynamic MAIO Allocation (DMA):............................. 108 Creating the hopping laws used for Dynamic MAIO Allocation:........................................................... 112 Creating the LPDLM links: .................................................................................................................... 114 Creating the terrestrial Abis timelots for flexible Abis allocation:.......................................................... 116 Creating a cell with definition of global parameters: ............................................................................. 121

Setting the cell specific parameters for DMA Admission Control ......................................................... 175 Setting the cell attributes for the Interference Measurement of idle TCHs:.......................................... 187 Setting the cell specific timer values:.................................................................................................... 189 Setting the cell specific optional features:............................................................................................. 198 Defining the cell specific service layer lists for the feature ‘Service dependent Channel Allocation’(SDCA) via ‘Multi Service Layer Support’ (MSLS):............................................................................... 214 Setting the cell specific attributes for Power Control: ........................................................................... 223

Power Control Parameter Relations....... ............ .............. ........... .............. ............ ............. .............. ............. .... 236 Creating the GPRS point to point packet transfer service in a cell:...................................................... 237 Creating the LPDLR links: .................................................................................................................... 264 Creating the cell-specific Frequency Hopping systems for static MAIO Allocation (SMA):.................. 265 Creating the TRXs: ............................................................................................................................... 267 Enabling GPRS and EDGE in a cell: .................................................................................................... 270 Creating the BCCH for the cell: ............................................................................................................ 273

Creating the SDCCHs for the cell:........................................................................................................ 274 Creating the TCHs for the cell: ............................................................................................................. 276 Creating hybrid TCHs/SDCCHs (TCH/SD) for the cell: ........................................................................ 279 Setting the cell specific parameters and threshold values for voice call Handover:............................. 284

Handover Parameter Relations.... ............ ............. ............. ............ ............. ............ ............. .............. ............. .. 332 Setting the cell specific parameters and threshold values for 14,4kbit/s data call up- and downgradingand quality inter-cell handover:............................................................................................................. 334 Enabling features related to ASCI, SMS-CB, Frequency Hopping, HSCSD, Call Release due toExcessive Distance and Dynamic MAIO Allocation (DMA): ................................................................. 336 Creating the Target Cell Objects: ......................................................................................................... 340 Creating the Target Point-to-point Packet Flow Objects: ..................................................................... 342 Creating the Adjacent Cell Objects:...................................................................................................... 344





Creating the Target Cell Objects for handover from GSM to UMTS (FDD): ........................................ 356 Creating the Adjacent Cell Objects for external UMTS FDD or UMTS TDD cells:............................... 357 Creating the CCS7 level 3 addresses of BSC, MSC and SMLC and basic SCCP parameters for theSS7 connection:.................................................................................................................................... 362 Setting the timer values for CCS7 MTP level 2: ................................................................................... 367 Setting the timer values for CCS7 MTP level 3: ................................................................................... 370 Creating the CCS7 link: ........................................................................................................................ 373 Creating a Nailed-Up Connection through the BSC/TRAU: ................................................................. 374

Creating an X25 connection via dedicated link:.................................................................................... 375 Creating an X25 connection via A-interface: ........................................................................................ 377 Creating an IP Link connection:............................................................................................................ 379 Creating the O&M link for the RC connection:...................................................................................... 380 Creating the link for the external connection to the SMS-CB system:.................................................. 380 Defining the BSC reference synchronization clock origin:.................................................................... 380 Defining an external synchronization signal: ........................................................................................ 381 Creating the Quality of Service Alarm Objects: .................................................................................... 382 Creating the Quality of Service Alarm threshold sets:.......................................................................... 383 Creating the Quality of Service Alarm Objects for the BSC object:...................................................... 385 Creating the Quality of Service Alarm Objects for BTS objects: .......................................................... 386 Creating the Quality of Service Alarm Objects for PTPPKF objects: ................................................... 390 Activating IMSI tracing in the BSC:....................................................................................................... 392 Creating a Cell Traffic Recording (CTR) job:........................................................................................ 393

Enabling the data recording for the feature ‘History on Dropped Calls’: .............................................. 395 Defining the BSC environmental alarms:.............................................................................................. 400 Configuring the feature Online RF Loopback: ...................................................................................... 401 Creating Smart Carrier Allocation:........................................................................................................ 405

2 APPENDIX ................................................................................................................................................. 407

2.1 H ANDOVER THRESHOLDS & ALGORITHMS .............................................................................................. 407 2.1.1 Functional Diagram Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level,quality and power budget) .................................................................................................................... 407 2.1.2 Rules: Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality andpower budget), Power Control disabled ............................................................................................... 408

2.1.2.1 Inter-cell/Inter-system Handover due to level.............. ............ ............. ............ ............ ............... .......... 408 2.1.2.1.1 Handover Decision / Handover Trigger Conditions ............ ............. ............ ............. ............ ......... 408 2.1.2.1.2 Target Cell List Generation .......................................................................................................... 409

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

2.1.2.3.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 413 2.1.2.3.2 Target Cell List Generation .......................................................................................................... 414

2.1.2.4 Inter-cell/Inter-system Handover due to distance............ ............. ............ ............. ............ ............... .... 416 2.1.2.4.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 416 2.1.2.4.2 Target Cell List Generation .......................................................................................................... 416

2.1.2.5 Inter-cell/Inter-system Handover due to better cell (power budget handover) ........... .............. ............ . 418 2.1.2.5.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 418 2.1.2.5.2 Target Cell List Generation .......................................................................................................... 420 2.1.2.5.1 Speed sensitive handover enabled ........... ............. ............ ............. ............ ............. .............. ...... 421

2.1.2.5 Inter-system Handover due to suifficient coverage .......... ............. ............ ............. ............. ............. .... 422 2.1.2.5.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 422

2.1.2.6 Forced Handover due to directed retry, preemption or O&M intervention ............. ............ ............ ....... 423 2.1.2.6.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 423

2) 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)... ............ ............. ............ ............. ............ ............. ............ .............. ............. 423 2.1.2.7 Fast Uplink Handover (Intra-BSC only) ............. ............. ............ ............. ............ ............. .............. ...... 424

2.1.2.7.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ........ 424 2.1.2.7.2 Target Cell List Generation .......................................................................................................... 424

2.1.2.8 Inter-cell Handover due to BSS Resource Management Criteria (Traffic HO) ............ ............. ............ 426 2.1.2.8.1 Handover Decision / Handover Trigger Conditions .............. ............. ............ ............ ............. ...... 426 2.1.2.8.2 Target Cell List Generation .......................................................................................................... 430

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

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





2.2.2.1 Ranking method 0............ ............ ............. ............ ............. ............ ............ ............. .............. ............. .. 434 2.2.2.2 Ranking method 1............ ............ ............. ............ ............. ............ ............ ............. .............. ............. .. 437

2.2.3 Target Cell Ranking for Traffic Handover with HCS................................................................... 439 2.3 SEQUENCE OF H ANDOVER TYPES WITHIN THE H ANDOVER DECISION ALGORITHM IN THE BTS................... 440

2.4.1 Functional Diagram: Power Control Thresholds - Power Increase / Power Decrease (ClassicPower Control) ...................................................................................................................................... 441 2.4.2 Rules: Power Control Thresholds: Power Increase / Power Decrease...................................... 442

2.4.2.1 Power Increase .................................................................................................................................... 442 2.4.2.2 Power Decrease.............. ............ ............. ............. ............ ............. ........... .............. .............. ............. .. 443

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

2.4.3.5.1 BS power control procedure.............. ............ ............. ............ ............. ............ ............. .............. .. 447 2.4.3.5.2 MS power control procedure ............. ............ ............. ............ ............ ............. ............ ............... .. 448

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

2.5 INTERWORKING OF H ANDOVER AND POWER CONTROL............................................................................ 453 2.5.1 Functional Diagram: Inter-cell Handover and Intra-cell Handover, Power Increase and Power Decrease............................................................................................................................................... 453 2.5.2 Rules........................................................................................................................................... 454

2.6 SERVICE DEPENDENT H ANDOVER AND POWER CONTROL ....................................................................... 455 2.6.1 Introduction ................................................................................................................................. 455 2.6.2 SGxHOPAR and SGxPCPAR parameter values......................................................................... 456

2.6.2.1 SGxHOPAR parameter values (Handover).... ............. ............ ............. ............ ............ .............. ........... 456 2.6.2.2 SGxPCPAR parameter values (Power Control) ............ ............ ............. ............ ............. ............. ......... 458 2.6.2.3 Effects on Call processing............ ............ .............. ............ ............. ............ ............. .............. ............. .. 459

2.7 REPORTING, DISPLAY AND BTS INTERNAL HANDLING OF RSCP VALUES FROM 3G NEIGHBOUR CELLS ....... 460 2.8 M APPING OF RXQUAL AND C/I VALUES ................................................................................................. 462 2.9 AMR LINK ADAPTATION THRESHOLDS UPLINK........................................................................................ 463 2.10 BSC, MSC AND BTS OVERLOAD H ANDLING ........................................................................................ 467

2.10.1 BSC Overload........................................................................................................................... 467 2.10.1.1 BSC overload conditions..... ............ ............. ............ ............. ............ ............. ............ .............. ........... 467 2.10.1.2 System reactions and overload regulation measures in case of BSC overload .............. ............ ....... 475

2.10.1.2 System reactions and overload regulation measures in case of BSC overload ............. ............. ....... 475 2.10.1.2.1 Further important notes on BSC reactions ........... ............. ............. ........... .............. ........... ........ 476 2.10.1.3 Mechanisms for reduction of originating traffic and reduction of terminating traffic.. ............. ............. 477

2.10.1.3.1 Overload level management................ ............. ............ ............ ............. ............ ............... .......... 477 2.10.1.3.2 Traffic reduction algorithms............ ............. ............ ............. ............. ............ .............. ............. .. 478 2.10.1.3.3 Special overload supervision algorithm in case of BSC paging queue overflow.......... ............. .. 479

2.10.2 MSC Overload .......................................................................................................................... 479 2.10.2.1 System reactions and overload regulation measures in case of MSC overload......... ............. ............ 479

2.10.2.1.1 Special overload level escalation algorithm in case of MSC overload....... ............. ............. ........ 479 2.10.3 BTS Overload ........................................................................................................................... 481

2.10.3.1 BTS overload conditions ........... ............. ............ ............. ............ ............. ............ .............. ............. .... 481 2.10.3.2 Traffic reduction mechanisms in case of BTS overload ........... ............. ............ ............ ............. ........ 487 2.10.3.3 System reactions and overload regulation measures in case of BTS overload........... ............ ........... 488

2.10.4 Interaction of BTS Overload and BSC Overload ...................................................................... 489 2.10.5 Effects on Performance Measurement Counters ..................................................................... 490

3 ALPHABETICAL COMMAND AND PARAMETER INDEX ..................................................................... 491





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.





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 ‘pack ages’ (e.g. PKGBTSB , PKGBSCT etc.) were removed s o

that al l parameters su bord inate to one o bject (e.g. BTS) are included in one and the same comm and (CREATE/SET BTS). The disadvantage is that

among the huge num ber of parameters wi th in one command i t is hard to f ind

a specif ic parameter quickly.

I decided to use the fol lowin g approach in this document:

- For a better logical structu re, the parameters are st i l l grouped in th e

‘pseudo -packages’ (e.g. CREATE BTS [BASICS], SET BTS [CCCH] etc.) used

in th e LMT GUI.

- Within each p ackage, an alphabetical order was used fo r the sequence of

parameters (as done by DBAEM) to faci l i tate the handl ing and overview.





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 t ime , this parameter defines the network element time inthe BSS.

MELID=1;

object: MELrange: 1..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 ensurethe 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 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 ‘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 tracelogfiles 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, 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 and transferred 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 automatically closed and prepared for upload if the trace is still in progress. In thiscase a new open binary file is generated which records the next events of the call to be traced. In the RC, the uploaded files aredecompressed, merged and converted to ASCII for analysis by theDUIT application.





IMSIFSIZ=30,


unit: 1 Mbyte

range: 0..30

default: 30

IMSI fi le size , this parameter is associated to the feature 'IMSI Tracing' (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 binary trace data to the open binary trace file in the BSC directory TRACE_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 upload and 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 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 aswell 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 isin progress, the BSC writes the binary trace data to the open binary trace 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 and transferred 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 fi le upload period , defines the time period between twouploads 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,


unit: 1 Mbyte

range: 1-6

default: 3

Maximum scanner logfi le 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 of scanners 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 automatically uploaded 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 fi le 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;


range: upload start hour 0..23

upload start minute 0..59

default: upload start hour 0

upload start minute 0

Measurement data fi le 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 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 t ime to receive the

BSSMAP message BLOCKING ACKNOWLEDGE . The MSC selects 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 used due to configuration of OMAL, LPDLS or SS7L etc.. The BSC instructs 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 associated acknowledge 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 for the 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 t ime 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 whenthe 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 adata 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 signaling failure (T8 and T10) 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).





BSCT11 Cancelled – parameter is replaced b y param eters BSCT11PUB

and BSCT11WPS in BR8.0.

BSCT11PUB=HLFSEC-16,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-16


BSC timer T11 publ ic , 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’ / ‘WPSqueuing’ is enabled (see parameter EQ in command SET BTS[OPTIONS] for a detailed description). When a TCH request for anassignment procedure (i.e. when the BSC receives an

ASSIGNMENT REQUEST message from the MSC) is put into aqueue due to TCH congestion, T11 determines the maximum timethe TCH request may remain in the queue to wait for a busy TCH tobecome idle. If the TCH request for assignment procedure cannot beserved within this time frame and T11 expires, the BSC sends aCLEAR 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 EQin command SET BTS [OPTIONS]). This feature foresees a twoqueue concept, one queue being used for ordinary subscribers(‘public’) and one for priorized subscribers (‘WPS queue’). The

parameter BSCT11PUB defines the queing 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 theSDCCH 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 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 anappropriate setting of the timer T3111 (see SET BTS [TIMER]). Thismay 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 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.

BSCT11WPS=HLFSEC-16,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-16

BSC tim er 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.

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.





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 p eriod at

the 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 must be 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 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 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 BSCT18 within the BSS overload regulation please refer to the section “BSC,

BTS and MSC overload Handl ing” in 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.

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 over load 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 incommand 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 Handl ing” in 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 t ime 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 connectionrelease. If the RESET CIRCUIT procedure is initiated by the BSC it sends the BSSMAP message RESET CIRCUIT to the MSC whichclears 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 theRESET CIRCUIT ACKNOWLEDGE the BSC repeats the RESET

CIRCUIT PROCEDURE and restarts T19.





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 t im e to receive CIRCUIT

GROUP 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 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 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 BSSMAP

mes sage 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 theBSSMAP message RESOURCE REQUEST from the MSC. TheRESOURCE 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 ina periodic manner. For the periodic transmission of RESOURCE INDICATION 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 tim er 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 BSSMAP HANDOVER 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 and the 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 it expires, 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) and NRCLRREQ (subcounter cause: radio interface message failure) and will 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 CLEAR COMMAND with cause ‘handover successful’ is received.





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 t ime to return a

BSSMAP 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 of the 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 over the 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 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 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 wait ing time for a

HANDOVER COMMAND from the MSC after transmission of aHONDOVER REQUIRED to the MSC. If the BTSE has sent aHANDOVER CONDITION INDICATION message and the handover is 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 CANDIDATE ENQUIRY 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 processing terminates the 'waiting for HO CMD' state and the receipt of new HOCOND 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 thefeatures “queuing” or/and ”preemption” are used for incoming MSC controlled 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





‘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 may take more than 2s until 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 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)

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 t ime 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 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 and T10) 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).





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 the maximum al lowed queu ing t ime for incom ing 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 expiresin 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 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 publ ic queue , this timer determines the maximum allowed queuing time for TCH requests dueto 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 queuebeing used for ordinary subscribers (‘public’) and one for priorized subscribers (‘WPS queue’). The parameter BSCTQHOPUB definesthe 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 hando ver in WPS queue , this timer determines the maximum allowed queuing time for TCH requests dueto 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 isused for ordinary queing) for the ‘WPS’ queue.

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





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 toallow a more useful grouping of the commands .


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 acceptabledegradation of packet service throughput (maximum sustainablethroughput), 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 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 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 themaximum sustainable throughput is considered; an increase of theMST 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 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 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 isimplemented it is suggested to set the ACCEPTGDEGR attribute to‘0’ (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.





AISAT=FALSE,


range: TRUE, FALSE

default: FALSE

A in terface via satel l i te , 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 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 slowsdown all signaling 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 retransmissionerror 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 satellitelink at the same time, because multiple satellite links within a BSSmay 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),


range: ENABLED(1..100),

DISABLED

default: ENABLE(30) (minor)

ENABLE(60) (major)

ENABLE(90) (critical)

A-interface TCH monitor ing thresho lds , 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 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.





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 SET BTS [CCCH]) and determines whether the ASCI ‘one channel model’ is 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 several other called service subscribers in the group call area), for the called

service subscribers basically only one downlink channel (ASCI common TCH) is provided, i.e. they can only listen to the dispatcher.However, a service subscriber has the possibility to request an uplink channel 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,5 channel mode), the following happens: when the service subscriber requests 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 called “1,5 channel mode”).

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

requests an uplink TCH via the PTT button in order to transmit speech, the BSC only assigns an uplink channel to the already existing 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),



DISABLED

default: ENABLE(30) (minor)

ENABLE(60) (major)


A-interface signal ing mon itor ing thresholds , determines the stateand the threshold values for the minor, major and critical QOS alarmsfor the SS7 signaling channels on the A-interface. The entered threshold 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 LINK THRESHOLD MINOR, MAJOR or CRITICAL (error ID 236, 238 and 241) 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 enhanc ed capaci ty al lowed , this attribute indicates whether the 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.





ASUBISAT=FALSE,


range: TRUE, FALSE

default: FALSE

Asub LAPD channel via satel l i te , this attribute indicates whether the 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 account by the LAPD layer 2 functions of the TRAU O&M link (LPDLS) and b) the higher layers on the CCS7 link (e.g. BSSAP) and c) the CCS7 layer 2 functions.

Setting ASUBISAT to TRUE has the following consequences:a) The LAPD timer T200 (waiting timers for LAPD acknowledgement frames) as well as the associated window sizes (the 'window size' issimply the number of I-frames that may be sent without any acknowledgement from the opposite side) are automatically extended according 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 2 frames, 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 extend selected timers to higher values to avoid undesired effects.c) If the Asub interface is realized via satellite link the CCS7 error correction 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 TRAU as 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/SET BTSM) 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 the propagation delay of terrestrial signalling links or at least to only onesatellite 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.

BSCOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

BSC overload handl ing , determines whether BSC overload

handling is enabled or not. For further details about the BSC overload regulation please refer to the section “BSC, BTS and MSC overload

Handl ing” in 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 chapter that comprises all possible scenarios of overload and overload handling 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).





BTSOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

BTS over load handl ing , determines whether BTS overload handling is enabled or not. For further details about the BTS overload regulation please refer to the section “BSC, BTS and MSC overload

Handl ing” in 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 chapter that 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 Broadcast Center 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_Indicator parameter) 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 Indicator parameter value.

Note: The support of the ‘Channel Indicator’ has been implemented only 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 only the BASIC channel can be specified in the channel_indicator field from the CBC operator.

CCHANTFACT=FALSE,


range: TRUE, FALSEdefault: FALSE

Channel change noti f icat ion active , this flag determines whether Channel Change Notication (CCN) is enabled in the BSC (TRUE) or not (FALSE).

CICFM=GSM,


range: GSM, NOTSTRUCT

default: GSM

CIC format , this parameter specifies the format of the circuit identification 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

Cel l ID and Timing Ad vance Support , this parameter is relevant for the 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 during any connection setup) in addition to the Cell Identifier (CI).

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





CSCH3CSCH4SUP=TRUE,


range: TRUE, FALSE

default: FALSE

reference: GSM 03.64

rcommended value: TRUE

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

per BTS (see parameter CSCH3CSCH4SUP in command CREATE PTPPKF).

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 coding scheme can be achieved by the different coding schemes depending on 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 current radio 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 (defined by 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 and the 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 concatenated PCU frames, two 16kbit/s TCHs on the Abis interface are necessary for each radio interface timeslot (PDCH). In detail, the relation of coding scheme and the required number of concatenated PCU frames is displayed in the following table:

GPRS coding scheme Radio Block Size in Bits

for 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





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 count ing , this flag enables/disables thefunctionality that considers the setting of the parameter DGRSTRGY (see command CREATE BTS [BASICS]) for the traffic load calculation.

If DGRSTRGYBCNT is set to ENABLED, the BSC considers thesetting of the DGRSTRGY parameter in theradio 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 or DOWNGRADE_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

Downl ink L APD Overload , this parameter allows to enable or disable 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 CREATE BTSM), 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 chapter ‘BSC, MSC and BTS Overload handling’ in the appendix of thisdocument.

The parameters relevant for BTSE LAPD overload handling areFLAPDOVLTH, SLAPDOVLTH and LAPDOVLT (see CREATE BTSM).

EENHDTMSUP=DISABLED,


range: ENABLED, DISABLED

default: DISABLED

Enable Enhanced DTM Suppor t , this flag enables/disables the“Enhanced DTM Establish” mode, as defined in 3GPP Release 6.





EFRSUPP=FALSE,


range: TRUE, FALSE

default: FALSE

Enhanced ful l rate supported , this parameter determines whether the assignment of enhanced full rate TCHs is generally allowed for the BSC or not.Notes:- The decision, which kind of TCH (EFR, FR or HR) is finally assigned to a TCH request is made by the BSC on the basis of a) the channel requirement provided by the MS in the SETUP

message,b) the MSCs capability to support the requested speech versions(which results in a corresponding contents of the ASSIGNMENT REQUEST /HANDOVER REQUEST message which the MSC sendsto the BSC) and c) the current occupation of TCH resources in the affected BTS and TCH allocation strategy used by the BSC.- As opposed to HRSPEECH, which enables/disables both standard half rate speech (HR version 1) and AMR half rate (HR version 3),the setting of EFRSUPP has no effect on AMR.

EHRACTAMR

Parameter was moved from BSC object

to BTS object in BR8.0!

Enable HR activat ion fo r AMR cal ls - moved to BTS object inBR8.0.

EISDCCHHO=ENABLE,


range: ENABLE, DISABLE

default: ENABLE

Inter SDCCH hando ver enabled, determines whether ‘Inter BSC SDCCH handover’ is enabled.‘Inter-BSC SDCCH handover’ consists of 1) Inter-BSC Directed Retry (see param. ENFORCHO) and 2) Inter-BSC SDCCH-SDCCH-Handover (see parameter IERCHOSDCCH in command SET HAND [BASICS]).

Setting EISDCCHHO to ‘disable’ has the following results:a) the BSC is prevented from sending HANDOVER REQUIREDmessages for ongoing SDCCH connections to the MSC and b) the BSC drops all target cells (received in the HCI) that do not belong to the own area.

ENCALSUP=NOENCR&GSMV1&GSMV2,

object: BSC [BASICS]default: encalg1=NOENCR

encalg2=GSMV1

encalg3..10=NOCONFIG

Supported encryp tion algor i thm s , this parameter determines thealgorithms for the radio interface ciphering supported by the BSC.NOENCR means ‘no ciphering’,

GSMV1 represents the ciphering algorithm A5/1,GSMV2 represents the ciphering algorithm A5/2.

When the BSC receives a CIPHER MODE COMMAND from theMSC, the BSC makes the decision for the cipher algorithm to be used by matching the list of allowed cipher algorithms as indicated in theCIPHER MODE COMMAND and the ones defined in the parameter ENCALSUP and selects the best (safest) algorithm (A5/1 is the‘stronger’ and safer algorithm and is therefore preferred against A5/2,if both are allowed) for the CIPHERING MODE COMMAND towardsthe BTS.

It is up to the operator to take care that the setting of ENCALSUP matches to the cipher algorithms that are supported by the used BTSSW loads (see BTS SW Release Documentation for details).





ENFOIAHO=TRUE,


range: TRUE, FALSE

default: TRUE

Default value changed in BR8.0!

Enable forced intra-cel l HO , this parameter enables the proceduresa) ‘ Forced Intracell Handover due to multislot calls’ and b) ‘Forced Handover due to preferred service layer’ .

This means that E N FOIAHO should be set to TRUE, if either a) GPRS or HSCSD is used in the BSC (see command CREATE PTPPKF (for (E)GPRS) and parameter ENHSCSD (see below)).If there are not enough adjacent radio TCHs available when a

request for multislot call (HSCSD or GPRS) is received a forced intracell handover is performed which re-orders the current timeslot seizure in such a way that a sufficient number of adjacent timeslots isavailable to satisfy the multislot call request to the best possibleextent.

b) Moreover, it must be set to TRUE if the feature ‘Multilayer ServiceSupport’ (see command SET BTS [SEVICE]) is applied.If a call is set up on a TRX that belongs to service layer different fromthe ‘preferred’ one, the BSC periodically tries to hand over theestablished call to a TRX of a layer with higher SLL priority. If an idleTCH is found during this check, the handover to the preferred layer is

performed.

Both kinds of handover (a and b) are triggered and executed exclusively by the BSC: when the described copnditions are fulfilled,the BSC just activates the target channels and sends the associated

ASSIGNMENT COMMANDs to the MSs. The BTS is not involved inthe handover initiation, i.e. no HANDOVER CONDITION INDICATION is sent from BTS to BSC.

Note: For case b) the maintenance bit 12 (MNTBMASK=BIT12, seebelow) must be set in addition.

ENFORCHO=ENABLE,


range: ENABLE, DISABLE

default: ENABLE

Forced handov er enabled , this parameter determines whether theBSC may send a FORCED HANDOVER REQUEST message for running SDCCH connections to the BTS. This message is used for either for ‘Directed Retry’ or for the procedure ‘Forced handover dueto Preemption’ (see parameter EPRE in command SET BTS[OPTIONS]). A ‘Directed Retry’ procedure is performed if a MOC or an MTC is attempted in a cell for which

a) no idle TCH is available due to radio TCH congestion or b) no Abis TCH is available in the Abis TCH pool associated to theserving BTSM.

A successful ‘Directed Retry’ results in the assignment of a TCH inthe best adjacent cell. During this procedure the BSC, having received the ASSREQ from the MSC, sends the ‘forced handover request’ message to the BTS, which in turn sends HANDOVER CONDITION INDICATION messages with the cause ‘forced’. TheHCI messages contain a list of target cells that the BTS hasdetermined by evaluating the measurement reports sent uplink by theMS during the SDCCH phase. (-> see also command CREATE

ADJC., parameters FHORLMO and TIMERFHO and section 2.1.2.6).In case of ‘Forced handover due to Preemption’, the BSC sends theFORCED HO REQ to the BTS for the call which is to be preempted.For the BTS, the process of the target cell list generation and thetarget cell ranking is exactly the same like for a directed retry – inboth cases the forced handover offset (FHORLMO) is applied.However, the resulting signalling transaction rather corresponds tothat of a normal handover procedure (with the appropriate causevalues) than that of a directed retry.

Notes:- If a CS call request is received in a congested cell, the BSC tries tosatisfy the TCH request in the following sequence:1) preemption of a low priority CS call; if not possible then2) directed retry ; if not possible then3) (WPS) queuing





4) downgrade of multislot calls (GPRS/HSCSD) may be periodically attempted in parallel and queued calls can be served when downgrade is successfully completed. Please refer to the parameters EPRE (for preemption) and EQ (for (WPS) queueing) in command SET BTS [OPTIONS] and to

parameter DGRSTRGY (for multislot call downgrade) in command SET BTS [BASICS].- Setting this parameter to ‘enable’ only activates the Directed Retry

controlled by the BSC, i.e. directed retry to target cells belonging tothe same BSC. If Inter-BSC Directed Retry shall be enabled the flag EISDCCHHO (see above) has to be set to 'enable' in addition.- The setting ENFORCHO=FALSE does not only prevent BSC-internal and outgoing Inter-BSC directed retries, it also preventsincoming Inter-BSC directed retries and incoming handovers due to

preemption: When the BSC receives a HANDOVER REQUEST message with the cause values ‘directed retry’ or ‘preemption’, it rejects the attempt by sending HANDOVER FAILURE with cause‘Protocol error between BSS and MSC’.- In hierarchical cell structures the ranking of the target cells in theHCI sent as a result of the ‘forced handover request’ is performed according to the setting of the parameter HIERF (see SET HAND).- If the feature ‘Preemption’ is enabled, the forced handoverm due to

preemption is only attempted, if ENFORCHO is set to ENABLE. If thisis not the case the preempted call is immediately released ! - If an MS tries to set up an HSCSD call in a cell where HSCSD isdisabled, the BSC also starts a directed retry procedure to satisfy - if

possible - the MS’s multichannel requirement in a neighbour cell. For further details pleas refer to the parameter BTSHSCSD (seecommand SET BTS [BASICS]).- Directed retry also works if direct TCH assignment (see parameter DIRTCHASS in command SET BTS [OPTIONS]) is enabled. If in thiscase no TCH is available for the IMMEDIATE ASSIGNMENT

procedure, the BSC allocates an SDCCH and the directed retry canbe performed.

Note for Forced handover due to O&M:Forced handover due to O&M (initiated by the SHUTDOWN

command is completely independent of any database flag.





ENHSCSD=FALSE,


range: TRUE, FALSE

default: FALSE

Enable HSCSD , this parameter specifies whether the feature ‘HighSpeed Circuit Switched Data (HSCSD)’ is enabled for the BSC or not.Notes:1) This parameter enables HSCSD for the BSC base only. Toactivate it, however, it must be explicitly enabled for each BTS (seeCREATE BTS [BASICS]: BTSHSCSD).2) As a mandatory precondition for HSCSD the features ‘early

classmark sending’ (see SET BTS [OPTIONS]:EARCLM) and ‘pooling’ (see parameter ENPOOL) must be enabled!

Principle: HSCSD is a feature which allows the ‘bunching’ of up to 4consecutive radio timeslots for data connections of up to38,4 (= 4 x 9,6) kbit/s (multislot connections). The data rate dependson the bearer capability requested by the MS and the negotiationresult between MS and MSC. Each HSCSD connection consists of 1main TCH which carries the main signalling (both FACCH and SACCH) and further 1..3 secondary TCHs . All radio timeslots used for one connection are FR timeslots located on the same TRX and use the same frequency hopping mode and the same TSC.Connection modes: There are 2 types of multislot connections:symmetric and asymmetric ones. In symmetric mode all secondary TCHs are bi-directional (UL and DL) and in asymmetric mode the

secondary channels are only uni-directional (DL) TCHs or can be amix of bi-directional and uni-directional TCHs (example: One"HSCSD 3+2" call consists of: one main TCH, one secondary bi-directional TCH and one secondary uni-directional TCH). Thedownlink based asymmetry allows the use of a receive rate higher than the transmission rate and is thus very typical for Internet applications. The asymmetric mode is only possible for non-transparent data connections.Resource allocation: The BSC is responsible for the flexible air resource allocation. It may alter the number of TCH/F as well as thechannel codings used for the connection. Reasons for the change of the resource allocation may be either the lack of radio resources,handover and/or the maintenance of the service quality. The changeof the air resource allocation is done by the BSC using ‘service level

upgrading and downgrading' procedures. For transparent HSCSDconnections the BSC is not allowed to change the user data rate, but it may alter the number of TCHs used by the connection (in this casethe data rate per TCH changes). For non-transparent calls the BSC isalso allowed to downgrade the user rate to a lower value. Handover: In symmetric mode individual signal level and quality reporting for each used channel is applied. For an asymmetric HSCSD configuration individual signal level and quality reporting isused for the main TCH. The quality measurements reported on themain channel are based on the worst quality measured on the mainand the unidirectional downlink timeslots used. In both symmetric and asymmetric HSCSD configuration the neighbour cell measurementsare reported on each uplink channel used. All TCHs used in anHSCSD connection are handed over simultaneously. The BSC may

alter the number of timeslots used for the connection and the channel codings when handing the connection over to the new channels. All kinds of inter-cell handovers are supported, intracell handover is

possible only with cause 'complete to inner' or 'inner to complete'.





EPA=FALSE,


range: TRUE, FALSE

default: TRUE


Enable enhanced pair ing of HR cal ls , this parameter enables thefeature ‘enhanced pairing of TCH/H’. “Enhanced Pairing” impliesautomatically triggered forced intracell handovers that fill up dual rateTCHs, that carry only one HR call, with another HR call. In other words: the feature transfers HR calls that currently occupy one HR subslot of a DR TCH (while the other subslot is still idle) in such away that as many HR calls as possible share one Dual Rate TCH

with another HR call. A DR TCH can assume the following usagestates:- a DR TCH is in usage state “idle” if none of the subslots is seized by a call,- the DR TCH is in usage state “active” if one of the two subslots(0 or 1) is occupied by a HR call,- the DR TCH is in usage state “busy” if both subslots are seized either by two HR calls or one FR call.The enhanced pairing intracell handover is controlled exclusively by the BSC and triggered by two different conditions:

a) Enhanced pair ing d ue to Um radio TCH load is triggered if the percentage of dual rate TCHs or full rate TCHs inthe BTS in usage state “idle” has dropped below a definablethreshold. This threshold is based on the parameters EPAT1 and

EPAT2 (see command CREATE BTS [BASICS]). Enhanced pairing intracell handovers are triggered if the following traffic load conditionis fulfilled (for further details about the meaning of single terms of thisformula, please refer to the description of parameter EPAT1).

Note: Interworking of ‘Service Dependent Channel Allocation’ withtraffic load calculationThe percentage calculation done for the Enhanced Pairing is donereferring only to the TRXs included in the SLLs for the AMR speechand non-AMR speech service types, separately for every subarea(primary/complementary). Please refer to the command SET BTS

[SERVICE] for further explanations.

b) Enhanced pair ing due to BTSM Abis TCH load is triggered if the percentage of dual rate TCHs or full rate TCHs in aBTSM Abis pool with usage state “idle” has dropped below adefinable threshold. This threshold is based on the parameter

ABISHRACTTHR (see command CREATE BTSM). Enhanced pairing intracell handovers are triggered if the following traffic load conditionis fulfilled (for further details about the meaning of single terms of thisformula, please refer to the description of parameter

ABISHRATTHR).

When the BSC detects TCHs in usage state “active” while at least one of the aforementioned condition is fulfilled, enhanced pairing intracell handovers are automatically performed by the BSC by simply activating the appropriate TCHs and by sending an

ASSIGNMENT COMMAND with the new HR TCH data to the MS. Aslong as the mentioned condition is not fulfilled the intracell handoversdue to enhanced pairing are not triggered.

For the detection of the aforementioned condition, the BSC uses acyclic process which is determined by the “Resource AllocationTimer“ (RR timer) which is fixed to 400ms: every 400 ms the BSC

< ∗ 100no. of Abis pool TCH in usage state ‚idle’

no. of TCH configured in the Abis pool100% - ABISHRACTTHR[%]

< ∗ 100no. of radio TCH in usage state ‚idle’

no. of configured radio TCHEPAT1[%]





checks if the TCH load condition for enhanced pairing is fulfilled and if there are some ongoing HR calls to be paired. This means that, if the TCH load condition is fulfilled, it takes at the maximum 400msuntil the unpaired HR calls are rearranged by enhanced pairing intracell handover.

EPOOL=TRUE,


range: TRUE, FALSE

default: FALSE

Enable pool ing , this parameter indicates whether the ‘TSLA pooling’ feature is activated on the BSC side (‘enabling flag’). ‘TSLA pooling’ must be activated if HSCSD (see parameter ENHSCSD) is used on

this BSC. If the pooling feature is enabled the available A-interfacetimeslots are classified by a ‘pooling type’. The different values for the

pooling type are predefined by GSM and represent a certaincombination of different ‘supported coding types’ for speech and data(see table at command CREATE PCMA and SET TSLA). Thus theBSC can separately manage the available resources e.g. for ordinary speech calls and for high speed data connections.

Attention: Pooling also affects the mapping of timeslots between the A- and Asub-! A TCH pool for multislot connections must map all Asub-timeslots used for a HSCSD-call to a single A-interfacetimeslot! Thus the previously rigid mapping pattern of A- and Asub-timeslots (represented by the parameter TRANMTX which was valid up to BR4.0) is now replaced by a semipermanent mapping pattern,which depends on the number and type of pools configured. Only the

basic mapping principle can be selected initially (see command CREATE TRAU, parameter ALLCRIT).

Moreover, the pooling type must be adapted to the version and capabilities of the used TRAC-HW in the TRAU, i.e. the pooling typesthat include the support of more advanced features must be assigned to TRAU shelves equipped with the appropriate TRAC versions(Mixing of TRAC versions within one TRAU shelf is only allowed inspecific configurations; for details, please refer the corresponding tables included in the HW-FW Crossreference List in the SBSRelease Documentation!). Thus it is possible to assign different speech and data coding types to different TRAU shelves.

EPREHSCSD=DISABLED,



default: DISABLED

Enable preemp tion for HSCSD requests , this attribute is only relevant if HSCSD is enabled (ENHSCSD=TRUE). If it is set to

TRUE, HSCSD calls may preempt other calls. HSCSD callsthemselves can never be preempted.

ERRACT=NOFILTER-NOFILTER-NOFILTER-NOFILTER-NOFILTER,


range: CRITICAL

MAJOR

MINOR

WARNING

NOFILTER

FERMAINT

default: NOFILTER

Error reactions , this parameter determines the output filters for different alarm event types. The five entered subattributes represent alarm messages in the alarm event types Communication-QualityOfService-Processing-Equipment-Environment. WhenERRACT is set to one alarm priority for a specific alarm event type all alarms of lower and equal priority are ignored for this event type.Notes:- Attention: the filter setting defined by ERRACT is not only relevant for spontaneous alarm output but also for the alarm output asreaction to the command GET ACTIVEALARMS BSC! - The value FERMAINT can be used only for Processing FailureEvents. Setting the PROC field to FERMAINT enables the output of

certain call processing alarm messages which are normally suppressed (e.g. AP ERROR INDICATION, MESSAGE OUT OF SEQUENCE etc.) in order to allow a closer look on the grade of service in the cell for maintenance purposes. Thus FERMAINT worksas a 'negative' filter.

ESUP=FALSE,


range: TRUE, FALSE

default: FALSE

EDGE supp ort , this parameter enables or disables the featureEDGE in the BSC. Setting this parameter is a precondition beforeEDGE services can finally be enabled on cell level (EEDGE in object PTPPKF).





EUSCNCRESEL=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS suff ic ient coverage network c ontrol led cel l

Reselect ion , this parameter enables or disables the Network Controlled Cell Reselection due to the 2G-3G criterion ‘sufficient coverage’ for GPRS connections.

Further relevant parameters are GMICROCU, USECNONCRESELand USRSCPNCRESEL (see command CREATE ADJC3G).

For further details about the criterion ‘sufficient coverage’ please refer to the corresponding handover parameter EUSCHO (command SET HAND).

EUSDCHO=FALSE,


range: TRUE, FALSE,

<NULL>

default: FALSE

Enable UMTS SDCCH handover , this parameter is only relevant if the parameter EUHO (see command SET HAND [BASICS]) is set toTRUE and enables or disables the handovers of calls that arecurrently on an SDCCH towards external UMTS FDD or TDDneighbour cells in the BSC. The status of this flag is also sent to theBTS during the database alignment procedure. With somerestrictions, EUSDCHO is a kind of equivalent to the parameter EISDCCHHO (see above).

This means that, only if EUSDCHO is enabled, the BSC forwards aHANDOVER REQUIRED message to the MSC, if an INTERCELLHANDOVER CONDITION INDICATION message that contains an

UMTS FDD target cell (see commands CREATE TGTFDD and CREATE ADJC3G) or an UMTS TDD target cell (command CREATE TGTTDD) was received from the BTS for an activated SDCCH.

An UMTS SDCCH HO can be1) Inter-System Directed Retry (see param. ENFORCHO), i.e. aforced handover was triggered and the resulting INTERCELLHANDOVER CONDITION INDICATION message contains an UMTSFDD target cell or 2) Service-Based Directed-Retry, i.e. a FORCED HANDOVER REQUEST message was triggered towards the BTS if the new IE ‘Service Handover Information’ in the ASSIGNMENT REQUEST message is set to "Handover to either UTRAN or cdma2000 should be performed" and the resulting INTERCELL HO CONDITION INDICATION message contains an UTRAN target cell.

Setting EUSDCCHHO to TRUE has the following results:a) the BSC is explicitly allows the BTS to include 3G target cellswithin the INTERCELL HANDOVER CONDITION INDICATION message. This is done by the optional IE ‘Service Handover Information’ which is included in the FORCED HANDOVER REQUEST message.b) the BTS is inserts, if available, the 3G target cells into the target cell list within the INTERCELL HANDOVER CONDITION INDICATION message (as also within the BTS the EUSDCCHHOflag is managed and checked)c) the BSC permits 3G neighbour cells as target cells to be sent tothe MSC within the HANDOVER REQUIRED message for ongoing SDCCH connections.





HOSYNC=NOSYNC,


range: NONSYNC, SYNC

default: NONSYNC


GSM 05.10

Handover synchron ic i ty , this parameter specifies whether thehandover is ‘synchronized’ or ‘non-synchronized’. Synchronized handover is possible between cells belonging to the same site(intercell handover from one sector to the neighbour sector). Thedifference between the both handover procedure is the following:

Asynchronous handover (cells not synchronized):In case of (normal) asynchronous HO the BSC activates the TCH in

the target cell by a CHANNEL ACTIVATION message with the IE ‘activation type: related to asynchronous handover’. In theHANDOVER COMMAND the BSC sets the ‘SynchronizationIndication’ IE to the value ‘non-synchronized’. When the MSaccesses the target cell after receipt of the HO CMD, it starts thetimer T3124 on transmission of the first HO_ACCESS message and repeats the transmission until it receives the PHYSICAL INFO. Thismessage contains the actual timing advance value which the new BTS derives from the delay of the HO_ACCESS messages received from the MS. When the PHYS INFO is received the MS stops T3124and establishes the layer-2 connection on the new FACCH by sending the SABM. The MS falls back to the old TCH when T3124expires or when the layer-2 connection setup fails.

Synchronous handover (cells finely synchronized):

In case of synchronous HO the BSC activates the TCH in the target cell by a CHANNEL ACTIVATION message with the IE ‘activationtype: related to synchronous handover’. The HANDOVER COMMAND sent by the BSC then contains the “ SynchronizationIndication: synchronized “. When the MS accesses the target cell after receipt of the HO CMD, it transmits 4 consecutive HO_ACCESSmessages and immediately establishes the layer-2 connection on thenew FACCH by sending the SABM after that. No PHYS INFO is sent to the MS. A fallback to the to the old TCH is only possible if the MSfails to set up the layer-2 connection.The synchronous handover is faster than the asynchronous one.Therefore it should be applied where possible as it speeds up thehandover procedure and thus reduces the ‘speech gap’ that canoccur during the handover procedure.

Note: The GSM calls the handover mode described above “ handover between finely synchronized cells ”. In addition to thismode, the GSM defines two additional handover modes:- Handover between pseudo-synchronized cells- Handover between pre-synchronized cellsBoth variants are not supported by the the Siemens BSS.

HRSPEECH=TRUE,


range: TRUE, FALSE

default: FALSE

Half rate speech , this parameter specifies whether the feature ‘Half Rate Speech’ is generally enabled for the BSC or not. The status of this flag determines whether the BSC allows the assignment of anHR TCH if the ASS REQ contains a corresponding ‘preferred channel type’. To assign a HR TCH, of course, the appropriate TCH types(see CREATE CHAN, parameter CHTYPE) have to be configured for the BTSs. For the general TCH allocation decision process of theBSC see note in parameter EFRSUPP.Notes:- The flag HRSPEECH enables/disables both standard half ratespeech (HR version 1) and AMR half rate (HR version 3), i.e. if HRSPEECH=FALSE, neither HR version 1 nor AMR HR will beassigned to any call or any other incoming TCH request (e.g.handover).- If HRSPEECH is set to FALSE, this also automatically disables thefeatures ‘AMR Compression Handover’ (see parameter EADVCMPDCMHO in command SET HAND).





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



DISABLED

default: ENABLE(30) (minor)ENABLE(60) (major)


LCS moni tor thresho lds , this parameter indicates the A-InterfaceMonitor Thresholds for SS7 channels. The threshold is the

percentage between ‚out of service’ SS7S on equipped SS7S; that is:LCSMONTH = (SS7S out of service/SS7S equipped)*100).The threshold values can be assigned only when the flag attribute isset to “enabled”.

LCSNSSC=FALSE,


range: TRUE, FALSE

default: FALSE

LCS NSS Centr ic s olut ion , this parameter allows to choose thelocation service type ( NSS centric / BSS centric ) supported by BSC.If this parameter is set to TRUE, the BSC supports the NSS centric solution and all the BSS requests are rejected, on the contrary if it isset to FALSE the BSC support the BSS centric request and the NSScentric are rejected.

Important: This parameter must be set to FALSE if LCS BSS centric solution is used!

MADGRLV=2,


range: 0..3default: 2

Maximum AIUR downg rade level for NT data cal ls , this attribute isonly relevant if HSCSD is enabled (ENHSCSD=TRUE) and determines the maximum AIUR downgrade level for non-transparent

data calls.

MAFIRACHO=2,


range: 1..3

default: 2

Maximum nu mber of forced intracel l handovers , this attribute isonly relevant if HSCSD and forced HSCSD forced intracell handover intracell handover is enabled (ENHSCSD=TRUE,ENFOIAHO=TRUE) and determines the maximum number of forced intracell handovers due to HSCSD calls (i.e. ongoing calls arehanded over to other TCHs within the cell to provide adjacent TCHsto an incoming HSCSD call request) .

MAXLAPDMN=5,


range: 5..12

default: 5

Maximum LAPDm number , this attribute controls the maximumnumber of LAPDm frames on which a layer 3 (GTTP) message canbe segmented into and be sent on the main DCCH.

MAXNCELL=6,


unit: 1

range: 1..16

default: 6


Maximum n umb er of target cel ls , this parameter indicates how many target cells may be included in the HANDOVER REQUIREDmessage sent to the MSC. The HO RQD message is sent, if the HOtarget does not belong to the own BSC area or if all handovers for acertain cell are to be performed by the MSC (see parametersLOTERCH and LOTRACH (SET HAND)).

MISTSTRSH=3,


range: 1.. 40

default: 3

Missing timeslot threshold , this attribute defines the alarming threshold for the feature ‘Detection of missing timeslots on Abis’.If the number of failed consecutive CHAN activations on one Abistimeslot (TSLB) exceeds this threshold, an alarm on all configured SUBTSLB objects (max 4) is emitted. The alarm(s) indicate(s) that the timeslot is missing (e.g. not put into service by the network

provider).

The configured threshold value is multiplied by 4, i.e. if the value isset to 1 the threshold value is 4 and so on.





MNTBMASK=<DEFAULT>,


unit: 1

range: BIT1.. BIT61

<DEFAULT>, Null

default: 1

parameter range extended in BR8.0!

Maintenance bit m ask , this parameter was originally intended to bereserved for internal use only. The idea was to set specific bits of this

parameter to enable manufacturer internal functions that require theinstallation of specific patches.

However, this parameter has also been repeatedly used to enableand control project-specific SW modifications or modifications that were introduced in BR6.02 as late features. For this reason it is

urgently recommended to use this parameter only, if the operator knows the exact impact of each of the bits that can be set.

The following functions can be controlled by the MNTBMASK Parameter (for guidelines for use please see below):

• MNTBMASK=BIT10 is used to enable/disable delayed TBF release during Mobility Management (MM) procedures. If BIT10 isnot set (default value) corresponds to “Delayed TBF Release” disabled during MM procedures; If MNTBMASK=BIT10 is set, thiscorresponds to “Delayed TBF Release” enabled during MM

procedures.

• MNTBMASK=BIT12 is used to enable/disable the forced intracell handover due to preferred service layer. Please refer to parameter ENFOIAHO (see above) for further details.

• MNTBMASK=BIT16 this setting suppresses the sending of theBSSMAP OVERLOAD message to the MSC in case of Abis LAPDoverload (the bit can be set starting from the BR8.0 ‘DTM load’,see release documentation for details). This change avoidsinterworking problems with Ericsson MSCs.

• If MNTBMASK=BIT17 , then the “Remote Transcoder Failure” event message (with originator 8100) is transmitted to the RadioCommander without respect to the settings of the ERRACT filter.Bit 17 set to 0: the “Remote Transcoder Failure” event message(with originator 8100) is transmitted to the Radio Commander withrespect to the settings of the ERRACT filter.

• MNTBMASK=BIT22 is used to suppress the use of variableformat in the SYSTEM INFO TYPEx messages which are sent on

the Um. It has been verified that, although compliant to Standards,the variable bitmap format included in some SYSINFO messagesis not correctly managed by several mobiles in the following scenario: mix of frequencies in the two ranges (0, 1...124) and (975..1023) in the same cell.

• If MNTBMASK=BIT23 , then in addition to SFC 0 also SFC 1 (if present) of an active PDCH is controlled, for EMPTY PDT purposes, by TEMPCH timer. If bit 23 is set to 0, then for EMPTY purposes, SFC=0 is controlled by TEMPCH timer, while SFC>=1is controlled by TEMPDT timer.

• Setting MNTBMASK=BIT25 disables the use of the GPRS coding schemes CS3 and CS4. This means that, if BIT25 is set, the BSC will only use the coding schemes CS1 and CS2 for GPRS. Somecustomers prefer to disable CS3/CS4 if EDGE is enabled, as withthe number of concatenated EDGE radio timeslots supported by the currently available mobile phones the performance of EDGE isnot far superior than the that of CS4. Thus the disabling of CS3/CS4 shall motivate the subscribers to subscribe to the EDGE services. However, setting MNTBMASK=BIT25 has the following side-effects: To enable CS3/CS4, it is mandatory to enable EDGE,as only in this mode the BSC can use concatenated TCH frameson the Abis - which is required for CS3 and CS4, as both coding schemes required two concatenated Abis TCHs. If, however,EDGE is enabled, two concatenated Abis TCHs will also be used for CS2 (If EDGE is disabled, CS1 and CS2 can be handled with a





single Abis TCH). This means: if EDGE is enabled, but CS3/CS4is disabled by BIT25, CS3 and CS4 will not be allocated but twoconcatenated Abis TCHs will be used for CS2 although this would not be necessary without EDGE. In other words, the customer hasto consider that in any case additional GPRS resources arerequired for GPRS, even if CS3 and CS4 are disabled by BIT25.

• Setting MNTBMASK=BIT30 and MNTBMASK=BIT31 are used inBR8.0 to control the paging delivery rate from BSC to BTS. The

paging delivery rate can be adjusted to values of 100%..130%.These percentage values represent the relative percentagecompared to the radio interface paging throughput which dependson the CCCH configuration (for further details please refer to thesection ‘BSC Overload Handling’ in the appendix of thisdocument). The two bits are used as representation of a two-digit binary value to control the setting:

BIT31 BIT30 Paging delivery rate (BSC->BTS)

0 0 130% of Um paging throughput




• Setting MNTBMASK=BIT30 and MNTBMASK=BIT31 are used in

BR8.0 to control the paging delivery rate from BSC to BTS. The paging delivery rate can be adjusted to values of 100%..130%.These percentage values represent the relative percentagecompared to the radio interface paging throughput which dependson the CCCH configuration (for further details please refer to thesection ‘BSC Overload Handling’ in the appendix of thisdocument). The two bits are used as representation of a two-digit binary value to control the setting:

• Setting MNTBMASK=BIT32 and MNTBMASK=BIT33 are used inBR8.0 to enable the change request CR2870 which is supposed toreduce the length of a HANDOVER COMMAND to the smallest

possible size in order to use as few layer 2 messages on the Uminterface as possible. This is done to reduce the probability of

decoding errors on the MS side for the HANDOVER COMMANDmessages: the shorter the message (and the less layer 2 messages are needed for delivery to the MS), the smaller the

probability that it is not correctly received by the MS. Messagesthat cannot be correctly decoded and assembled by the MS lead to call drops during handover. To achieve the smallest possiblemessag size, the CR allows an optimal decoding of the frequency list, e.g. by the usage of a variable bit map in case of handover toa hopping TCH using block wise frequency allocation (coding of upto 32 frequencies is feasible in one FACCH block). If aminimization is not possible then the present coding is used. Asthere are mobiles on the market which might not support thevariable bit length the functionality is administrable by theMNTBMASK bits 32 and 33

Two improvements are introduced:1) If MNTBMASK=BIT32 is set the DBA subsystem will calculatethe effective length of the frequency list encoded by the variablebit map, instead of using the currently fixed value ‘16’.

2) If MNTBMASK=BIT32 is set, the DBA subsystem will chose thebest encoding law, between ‘VariableBitMap’ and ‘Range128’, interms of used bytes. If the frequency list could be encoded withRange128 format (possible if less than 29 frequencies have to becoded), since the two improvements are controlled by two different bits of MNTBMASK, they could be used independently or together.





Important Hints for Use:- ‘Setting one bit’ of this parameter means: setting it to ‘1’ (i.e.MNTBMASK=BIT8 means: BIT8=1), for those bits that can be set by MNTBMASK the default value is ‘0’.- The command allows to set 30 bits (BIT0..BIT29), however, only some of them can be really modified by command. Several bits of themaintenance bit mask are fixed to '0' or '1' and cannot be changed.- Every command SET BSC:MNTBMASK=BITx;resets the maintenance bit mask to its default value und just changesthat bit which is included in the command. In other words, if BITy wasset before, the command SET BSC:MNTBMASK=BITx; resets BITy to '0' and sets BITx to '1'. This means that, if some of the bits arealready set, and another one is to be set in addition, it is required tore-enter the command with ALL required bits set.- To set several bits at the same time, the parameter values must belinked with a 'pipe' (e.g. MNTBMASK=BIT8|BIT9).- All bits can be reset to their original values using the setting MNTBMASK=Null or MNTBMASK=<DEFAULT>.

MSCOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

MSC overload handl ing , determines whether MSC overload handling is enabled or not. MSC overload is detected by the MSC itself. The BSC is informed by the BSSMAP message OVERLOADwith cause „ processor overload“ . The MSC reduces paging load by its own and therefore the BSC reduces only mobile originating traffic.

For further details about the BSC overload regulation please refer tothe section “BSC, BTS and MSC overload Handl ing” in theappendix 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.

Further parameters relevant for BTS overload handling:BSCT18 and BSCT17 (see command SET BSC [TIMER])

MSCPOOL=TRUE,



MSC pool ing , this parameter specifies whether the connected MSC is able to manage the ‘pooling’ feature or not. As the MSC is the oneto select the A-interface channels for a specific call the MSC has to

manage the pooling types assigned to the A interface resources, too.





MSCV=PHASE2CCEFR,


range: PHASE1

PHASE2

PHASE2CC

PHASE2EFR

PHASE2CCEFR

default: PHASE2CCEFR


MSC version , this parameter determines the protocol type to beused on the A-interface. This parameter has to be set incorrespondence with the GSM phase resp. the supported A-interface

protocol variants of the connected MSC. PHASE2CC indicates that MSC the supports the Information Element ‘Current Channel’ (‘CC’ inthe value of MSCV actually means that the BSC includes the IE ‘Current Channel’ in the HANDOVER REQUIRED message, the

receipt of this IE from the MSC is correctly handled anyway),PHASE2EFR indicates an MSC that supports the ‘Speech Version’ IEs, PHASE2CCEFR indicates that the MSC supports both the IE ‘Current Channel’ and the ‘Speech Version’ IEs.Note: If the feature 'ESVSIG' (extended speech version signaling) isenabled in the MSC the selected value must be PHASE2EFR,otherwise handover procedures may fail with 'protocol error betweenBSC and MSC’.

NACCNTWCOR=nc0,


range: nc0, nc1

default: nc0

NACC Network Control Order , this parameter defines the usage of Network Control Order during NACC when the MS is in packet transfer mode. When NACC is enabled, the value of this attribute is

put in the parameter Network Control Order inside Packet Measurement Order message.

NCRESELFLAG=ENABLE,


range: DISABLE, ENABLE

default: DISABLE

Enable network-contro l led GPRS cel l reselect ion , this parameter determines whether GPRS network controlled cell reselection(NCCR) is enabled or disabled.

The ‘normal’ GPRS cell reselection algorithm is executed by themobile station in case the parameter NTWCOR is set to NC0 (inBR70 always by default). Every GPRS MS in packet idle mode and in

packet transfer mode measures received signals from both theserving cell and neighbouring cells and performs cell reselectionautonomously on the basis of the cell selection criteria C1 (BCCH) or C31/C32 (in case a PBCCH is available in the cell).

The (Radio Link) Network Controlled Cell Reselection is a different cell reselection method: The network requests measurement reportsfrom the GPRS MSs and controls their cell reselection based on

these measurements and configurable network controlled cell selection parameters. Thus, if network-controlled cell reselection isenabled, the network instructs the GPRS mobile to transmit theRXLEV_DL values of both serving and adjacent cells in PACKET MEASUREMENT REPORT messages. Based on the reported measurement values and on the configured network controlled cell reselection parameters, the network may command a GPRS MS to aneighbour cell that provides better radio conditions. This algorithm iscalled Radio Link Network Controlled Cell Reselection.

In addition, the operator can enable Traffic Control Network Controlled Cell Reselection (parameter TRFPS, see below). With thisfeature, the network may redistribute MSs among cells to satisfy themaximum number of service requests. The Traffic Control network controlled cell reselection guarantees the optimum usage of

resources, i.e. a better GPRS/EGPRS traffic distribution among theavailable channels in all of the available cells. For further details

please refer to the parameter CRESELTRHSOUT in object PTPPKF.

Attention:- If the operator enables only the network controlled cell reselectionfeature (NCRESELFLAG=ENABLE), only the Radio Link Network Controlled Cell Reselection is enabled.- if the user wants to enable the Traffic Control Network Controlled Cell Reselection, the traffic control strategy must be enabled (TRFPS=TRUE) in addition to the network controlled cell reselection(NCRESELFLAG=ENABLE).





NECI=FALSE,


range: TRUE, FALSE

default: FALSE


New establ ishment cause indicat ion , this parameter controls thevalue of the NECI ( N ew E stablishment C ause I ndicator) bit, which isbroadcast in the SYSTEM INFORMATION TYPE 3 in the IE ‘CellSelection Parameters.’ and which determines which ‘establishment cause’ values in the CHANNEL REQUEST message the MSs in thecell are allowed to use when requesting a dedicated control channel via the RACH for call setup or other transactions.

The available ‘establishment cause’ bit strings in the CHANNEL

REQUEST message can be subdivided into two groups:

• GSM phase 1 establ ishment cause values All GSM phase 1 establishment cause values consist of 3 bit aresupported and are the only values which are supported by phase 1mobiles. The limited number of bits (3) does not allow the signaling of very specific setup requirements (e.g. the request for HR in caseof direct TCH assignment) in the random access procedure.

• GSM phase 2 establ ishment cause values GSM phase 2 introduced an additional set of establishment causevalues, which consist of 4, 5 or 6 bits, which allow a more specific signaling of channel requirements (e.g. request for a HR TCH incase of direct TCH assignment) during the random access

procedure via the RACH.

For more details about the possible establishment cause values please refer to the section dealing with the format of the CHANNELREQUEST message in GSM 04.08.

If the NECI bit is set to ‘0’ (NECI=TRUE), the MSs in the cell are only allowed to use only 3-bit establishment cause values, i.e. even if they support phase 2 establishment cause values, they are not allowed touse them. Thus all mobiles must behave like phase 1 mobiles during the random access procedure, no matter whether they are phase 1mobiles or not.

The reason for the introduction of the NECI parameter is to avoid problems that were experienced with specific mobile phones by NOKIA that refused to connect to the network when the NECI bit wasset to ‘1’ in the SYS INFO. In releases before BR7.0, the NECI bit was controlled by a TDPC patch (i.e. if the patch was loaded, the

NECI bit was changed from ‘0’ to ‘1’. To avoid the continuous patchmaintenance for this patch, the NECI parameter was introduced.

Attention:The NECI parameter has an impact on the performancemeasurement counters for immediate assignment procedures

ATIMASCA, SUIMASCA and NSUCCHPC. ATIMASCA counts theCHANNEL REQUEST messages that actually reach the BSC in theCHANNEL REQUIRED message, SUIMASCA counts thesubsequent IMMEDIATE ASSIGNMENT messages. Bothmeasurements distinguish the immediate assignment procedures by their establishment cause values and count them in separate cause-specific subcounters. As some of the subcounters of ATIMASCA and SUIMASCA represent specific phase 1 and phase 2 establishment causes, the changing of the NECI parameter will change the

distribution of the counts over the subcounters. Moreover, especially if NECI=TRUE, the cause distribution between

ATIMASCA/SUIMASCA on the one hand and NSUCCHPC on theother hand will deviate to a greater extent than with NECI=FALSE.

Note: The parameter NECI replaces the so-called ‘NECI patch ’that was provided for each load up to BR6.0. To achieve the same effect as in BR6.0, the parameter NECI must be used as follows:- BR6.0 NECI patch loaded = BR7.0 parameter NECI=TRUE - BR6.0 NECI patch not loaded = BR7.0 parameter NECI=FALSE





NETWTYPE=GSMDCS,


range: GSMDCS, GSMPCS,

GSMR, GSM850PCS,

GSM850DCS, GSMRAILPUB

GSMDCSTSM, GSMPCSTSM

default: GSMDCS

Network typ e , determines the type of network respectively frequency band.

The value GSMRAILPUB means that the frequency bands GSMR and GSM900 and DCS1800 can be configured in the cells but, nohandover from/to GSMR to one of the other frequency bands is

possible.

NOTFACCH=NOSUPP,


range: NOSUPP, ALWAYS,

EQA, HIGHEQB,

HIGHEQ0, HIGHEQ1,

HIGHEQ2, HIGHEQ3,

HIGHEQ4

default: NOSUPP

Noti f icat ion on FACCH , this parameter is relevant for ASCI only and and indicates for which mobile priorities the NOTIFICATION FACCH messages (BSC->MS) are sent on the FACCH belonging to the TCH seized by an ASCI subscriber. Two scenarios are possible:

1. MTC during and ong oing A SCI group cal l When a particular ASCI MS is currently involved in a VBS or VGCSgroup call, it may still receive and accept normal terminating CS calls(MTC). As the ASCI MS normally does not monitor to the paging channel (PCH) of the BCCH during an ongoing ASCI group call, theBSC can instruct the ASCI MSs (currently involved in a group call) tomonitor the PCH if a paging is to be transmitted. This is done with theDTAP message NOTIFICATION FACCH which is sent via theFACCH of the ASCI Common TCH (one DL TCH used by all ASCI

MSs in the cell) directly prior to the PAGING COMMAND itself (whichis sent via the PCH as usual) and which indicates ‘paging informationis included’. The BSC sends the NOTIFICATION FACCH message toall cells with an activated ASCI common TCH only - if the PAGING message from the MSC contains the optional IE ‘eMLPP priority’ and - if the priority level indicated in the ‘eMLPP priority’ IE is equal or higher than the priority level defined by the parameter NOTFACCH.Exception: if NOTFACCH is set to ALWAYS, the priority level is not checked and the NOT FACCH message is sent in any case.

Notes:- A ‘talking’ ASCI subscriber (i.e. a subscriber who has requested and received a separate dedicated uplink TCH in 1,5 channel model (see

parameter ASCIONECHMDL in command SET BSC [BASICS])) can

never receive a notification via the FACCH because in this casenotification is only sent via the ASCI Common TCH but not via thenewly activated uplink TCH. In other words, only ‘listening’ ASCI subscribers can receive a notification on FACCH with paging information included.

- During setup of an ASCI VBS or VGCS call, the BSSMAP messageVGCS/VBS ASSIGNMENT REQUEST also contains an IE ‘ callpriority’. The priority level indicated in this IE is independent of theone indicated in the (possibly subsequently sent) PAGING message.The standard forsees that the PAGING is only forwarded to the ASCI subscribers if its priority level is higher than the one of theVBS/VGCS call itself. However, it was decided not to use thisapproach in the SBS: In the Siemens BSS the called ASCI subscriber can accept the MTC in any case, no matter whether the priority level

indicated in the PAGING message is higher or lower than the priority level indicated in the VGCS/VBS ASSIGNMENT REQUEST message.

2. Incom ing ASCI group cal l dur ing o ngoing CS cal l (MOC, MTC)

When a particular ASCI MS is currently involved in a CS call (MOC or MTC), the ASCI subscriber may still receive a VBS/VGCS group call.In this case the BSC informs the busy ASCI subscriber about the new

ASCI group call via the NOTIFICATION FACCH message, which issent on the dedicated CS TCH and which indicates ‘goup call information is included’. However, the BSC sends theNOTIFICATION FACCH message to the busy ASCI subscriber only - if the VBS/VGCS ASSIGNMENT REQUEST message from the





MSC contains the IE ‘ call priority’ and - if the priority level indicated in the ‘ call priority’ IE is equal or higher than the priority level defined by the parameter NOTFACCH. Only exception: if NOTFACCH is set to ALWAYS, the priority level is not checked and the NOTIFICATION FACCH message is sent in any case.

Note: The order of the eMLPP priority values is A, B, 0, 1, 2, 3, 4.This means that ‘A’ is the highest priority, ‘4’ the lowest one.

The meaning of the values is the following:

ALWAYS (Notification/FACCH will always be sent)HIGHEQ4 (Notification/FACCH will always be sent for calls having priority

equal or higher than 4)HIGHEQ3 (Notification/FACCH will always be sent for calls having priority




equal or higher than 0)HIGHEQB (Notification/FACCH will always be sent for calls having priority

equal or higher than B)EQA (Notification/FACCH will always be sent for calls having priority

equal to A)

NTWCARD=NTWSNAP,


range: NTWSNAP

NTWSNAP_STLP

default: NTWSNAP

Network c ard type , up to BR7.0, this parameter used to determine the kind of switching network whether a switching network ( SN16 ,SNAP used in the BSC).

As, starting from BR8.0 only high capacity BSC (HC-BSC)configurations are supported, the only allowed values in BR8.0 areNTWSNAP and NTWSNAP_STLP.

The value NTWCARD=NTWSNAP_STLP is mandatory if , in addition to the SNAP board , STLP boards are used as PCM interface cards.

OVLSTTHR=9500,


unit: 1000=10%

range: 1000..10000

default: 9500

BSC overload start threshold , this parameter determines the TDPC load threshold for the start of overload handling. The TDPC load isspecified in %, where the value 1000 corresponds to 10% (see also

parameters OVLENTHR and BSCOVLH).

OVLENTHR=8500,


unit: 1000=10%

range: 7000..10000

default: 8500

BSC overload end threshold , this parameter determines the TDPC load threshold for the end of overload handling. The TDPC load isspecified in %, where the value 1000 corresponds to 10% (see also

parameters OVLSTTHR and BSCOVLH).

PAGCOORCLB=DISABLED,



default: DISABLED

Pagingcoordin ation class B , this flag to enable/disable Paging coordination for Class B mobiles.

PAGQOVLIND=DISABLED,



Paging queue over load indicat ion , this parameter defines a percentage threshold for the indication of the alarm ‘BSC PAGINGQUEUE OVERLOAD’ and the transmission of the BSSMAP message

OVERLOAD on the A-interface. The threshold is applied as follows: if the percentage of discarded pagings has exceeded the threshold defined by PAGQOVLIND in the last second, the alarm ‘BSC PAGING QUEUE OVERLOAD’ is raised and the BSSMAP OVERLOAD message is sent to the MSC.

PCMTYPE=PCM30,


range: PCM30, PCM24

default: PCM30

PCM type , specifies the type of PCM system used within thenetwork.





ROUIPADD0=<NULL>,


range: 15 character string, <NULL>

default: <NULL>

Router IP address 0 , this parameter indicates the Router IP addressassociated to all PCU port 0 (Ethernet port on the PPXU). It is used inorder to support High speed Gb Interface.

The convention used for this value is the dotted decimal format (e.g.“172.31.21.88”).

Note:The attributes ROUIPADD0, ROUIPADD1, SUBNETMASK0,SUBNETMASK1 are necessary only if SGSN is connected to BSC

via router. If the router is not present, these attributes must be set to<NULL>.

In case of co-located SGSN without a router between BSC and SGSN the following configuration rules apply:

- the operator sets to <NULL> both Router Ip Address 0 and 1(parameters ROUIPADD0, ROUIPADD1), so that each PPXU'srouting table contains no entry for default gateways

- all SGSN and PPXU IP Adresses must belong to same IP subnets(as identified by two respective subnet masks, parametersSUBNETMASK0, SUBNETMASK1).

ROUIPADD1=<NULL>,


range: 15 character string, <NULL>default: <NULL>

Router IP address 1 , this parameter indicates the Router IP addressassociated to all PCU port 1.

For further information please refer to parameter ROUIPADD0 (see

above)

SIMSCREL99=TRUE,


range: TRUE, FALSE

default: TRUE


System Inform ation MSC release 99 , this parameter determines thevalue of the “MSC Revision“ bit (the bit after the attach-detach flag)which is included in the IE ‘Control Channel Description’ in themessage SYSTEM INFORMATION TYPE 3.

Since BR6.1, the bit has been administrable by the parameter SIMSCREL99. If SIMSCREL99 is set to TRUE (and thus the ‘MSC Revision’ bit is set to ‘1’ in the SYSINFO 3), the MSs are allowed tosend Release-99-specific messages and information elements intheir signaling messages towards the network.

It is up to the network operator to set the value of this parameter incorrespondence with the real conditions (for the BSC, there is no way

to check the release compliance of the MSC) to avoid protocol errors.The reason for the introduction of this parameter was the necessity tosupport the message IMMEDIATE SETUP 2 in addition to the normal IMMEDIATE SETUP message. Both messages are used in the scopeof ASCI (Advanced Speech Call Items, mainly used for GSM-R). Thenew IMMEDIATE SETUP 2 message allows the mobile to include theadditional Information Element, OTDI (Originator To Dispatcher Information) into the IMMEDIATE SETUP message. This IE isrelevant for the setup of ASCI emergency calls.

An ASCI mobile is only allowed to send the IMMEDIATE SETUP 2 message if the MSC Release bit is set to ‘1’, which indicates that theMSC release is Release 99 or higher. This new procedure is allowed only with MSCs that are compliant to GSM release 99 or higher.

Also other applications might require the R99 compatibility of the

MSC.For the SIEMENS-MSC, this precondition is fulfilled starting withSR10 (CS 2.1).

Note: Please see also parameter SISGSNREL99 (see below).

SISGSNREL99 Moved to CPCU object in BR8.0.





SPEED145=FALSE,


range: TRUE, FALSE

default: FALSE

Speed 14.5 suppo rted , this enables the data service with 14.5 kbit/s(brutto data rate, i.e. including frame header) respectively 14.4 kbit/s(netto data rate, i.e. without frame header) speed. This type of channel coding increases the data throughput of a single GSM timeslot to 14.4 Kbit/s netto data rate and is based on a special transcoding algorithm which must be supported by the TRAU. The14.4 Kbit/s coding can be used in combination with HSCSD allowing

a data rate up to 57.6 Kbit/s (by combining 4 GSM time slots) for asingle connection. Both transparent and not-transparent connectionsare supported. The error correction mechanisms present in the Umcoding of 14.4kbits channels is less effective compared to the one of the 9.6kbit/s coding. As a result the effective data rate of the14.4kbit/s coding available to the user in non-transparent mode or when an external end-to-end error-control is applied may drop below the effective data rate achieved with the 9.6kbit/s coding. For thisreason, a channel mode modify procedure in case of non-transparent mode (upgrading & downgrading: 9.6 kbit/s 14.4 kbit/s and viceversa) is implemented to adapt the data rate appropriately to the C/I environment. The BTS indicates the in-call-modification to the BSC using the MODIFICATION CONDITION INDICATION message whichcontains the suggested new data rate. In correspondence with GSM,

the downgrading from 14.4 Kbit/s to 9.6 Kbit/s is not possible for atransparent call (both in case of established call or during handover).In transparent mode a 14.4 Kbit/s call handover to a cell that is not supporting 14.4 kbit/s coding will cause a drop.For further details related to the up- and downgrading of data calls

please refer to the explanations provided for the parameters included in the command SET HAND [DATA].

SPENLAW=A_LAW,


range: A_LAW

M_LAW

default: A_LAW

Speech enco ding law , specifies the used speech coding law used on the PCMA links. The PCM30 standard (normally used in all European and non-American countries) uses the A-law transcoding standard, while in countries PCM24 links (normally used in American

countries) makes use of the µ -law (‘ µ -law’ is indicated as ‘M_LAW’ inthe parameter value)

SUBNETMASK0=<NULL>,



default: <NULL>

Sub net mask 0 , this parameter is the NetMask for IP address of thethe PPXU-External router associated to all PCU port 0 (Ethernet port on the PPXU). It is used in order to support High speed Gb Interface.The value must be assigned according to the local LAN configuration.The convention used for this value is the dotted decimal format (e.g.“255.255.255.0”).

Note:The attributes ROUIPADD0, ROUIPADD1, SUBNETMASK0,SUBNETMASK1 are necessary only if SGSN is connected to BSC via router. If the router is not present, these attributes must be set to<NULL>.

In case of co-located SGSN without a router between BSC and SGSN the following configuration rules apply:

- the operator sets to <NULL> both Router Ip Address 0 and 1

(parameters ROUIPADD0, ROUIPADD1), so that each PPXU'srouting table contains no entry for default gateways

- all SGSN and PPXU IP Adresses must belong to same IP subnets(as identified by two respective subnet masks, parametersSUBNETMASK0, SUBNETMASK1).

SUBNETMASK1=<NULL>,



default: <NULL>

Sub net mask 1 , this parameter this parameter is the NetMask for IP address of the the PPXU-External router associated to all PCU port 1(Ethernet port on the PPXU).

For further details please refer to parameter SUBNETMASK0 (seeabove).





SYSPACKSYSSUP=FALSE,


range: TRUE, FALSE

default: FALSE

SYSINFO PACKET SYSNFO su ppo rt , this parameter indicates if thePACKET PSI STATUS and PACKET SI STATUS messages aresupported by the BSC or not. The mobiles are informed about theBSS support of these messages via the BCCH within the SYSTEM INFORMATION TYPE 13 and via the PBCCH within the PACKET SYSTEM INFORMATION TYPE 1.

T3122=5,


unit: 1s

range: 0..255

default: 5


Wait indicat ion time , defines the MS waiting time before the MS

allowed to attempt another RACH access by sending a CHANNELREQUEST, if the BSS response to the previous RACH access wasan IMMEDIATE ASSIGNMENT REJECT.The RACH access is used to request a dedicated control channel (mostly an SDCCH). In the successful case, the BSS responds to theCHANNEL REQUEST message by sending an IMMEDIATE

ASSIGNMENT COMMAND via the AGCH. However, if the BSC cannot find any idle SDCCH to satisfy the request, it rejects theaccess attempts by sending an IMMEDIATE ASSIGNMENT REJECT message via the AGCH. The timer T3122 defines the time the MSmust wait before it is allowed to send another CHANNEL REQUEST via the RACH in the same cell.This timer value is sent to the MS in the IE ‘Wait Indication’ within theIMMEDIATE ASSIGNMENT REJECT message.

Note: For the MS it does make a difference, whether it receives anIMMEDIATE ASSIGNMENT REJECT as response to a transmitted CHANNEL REQUEST or whether it does not receive any response at all. While in the latter case the MS will leave the cell (by cell reselection) after a defined number of RACH access attempts without (see parameters MAXRETR and NSLOTST in command SET BTS[CCCH]) without receipt of an IMMEDIATE ASSIGNMENT COMMAND or REJECT, in case of an AGCH response withIMMEDIATE ASSIGNMENT REJECT the MS just has to obey thewaiting time defined by T3122 before it may attempt the next RACH access attempt. In this case the MS will stay in the cell.

T3197=5,


unit: 1s ???

range: 3.. 5

default: 4

T3197 , this timer defines the maximum duration by which the BSC will delay the release of the RR connection.

TCBCSI=1,


unit: 1 minute

range: 0..1440

default: 1

Timer for CBC service interruption . The BSC transiently stores all Short Message Service Cell Broadcast (SMS-CB) messagesreceived from the Cell Broadcast Center (CBC) in the TDPC memory.The timer TCBCSI defines the time the BSC delays the deletion of the CBC messages from the TDPC memory. In other words: whenthe outage time of a BTS exceeds the time specified by TCBCSI, all SMS-CB messages for the affected BTS are deleted from thetransient TDPC memory. On recovery of the failed BTS the BSC sends a RESTART INDICATION to the CBC which initiates arealignment with the BSC which re-establishes the transient SMS-CBdata in the TDPC.

Value TCBCSI=0 means: The SMS-CB messages are not cleared from the TDPC memory - therefore the RESTART INDICATION towards the CBC is not necessary after BTS recovery..

TDTMWIND=5,


unit: 1s ???

range: 0..255

default: 5


Timer DTM wait indicator , this timer defines the waiting time, beforeMS may send a DTM-Request Indicator again after receipt of a DTM REJECT message. The value of this timer is sent to the MS in withinthe DTM REJECT message.





TGUARDTCHSD =SEC10,


range: SEC00, SEC10, SEC11,

SEC12, SEC13, SEC14,

SEC15

default: SEC10

default value changed in BR8.0 !

Guard Timer fo r TCH/SD, this parameter defines the time the BSC has to wait before a TCH/SD is moved from theSDCCH_BACKUP_POOL to the TCH/SD_POOL.When a TCH is created with CHTYPE=TCHSD and CHPOOLTYP=TCHSDPOOL (see associated parameters in command CREATE CHAN), it can be used as TCH or as an additional SDCCH/8,allowing a dynamic on-demand enhancement of the SDCCH

capacity. When a TCH/SD is created with TCHSDPOOL, it basically belongs to the TCH/SD_POOL, where it can be used as normal dual rate TCH. When the BSC receives an SDCCH request while the

percentage of busy SDCCH subslots has exceeded the threshold SDCCHCONGTH (see command CREATE BTS [BASICS]), the BSC moves the 8 SDCCH subchannels of one TCH/SD from theTCH/SD_POOL to the SDCCH_BACKUP_POOL to keep additional SDCCH resources for further incoming SDCCH requests.

During the SDCCH allocation the SDCCHs of the SDCCH_POOL arealways handled with priority, i.e. an SDCCH request will only besatisfied by a subslot from the SDCCH_BACKUP_POOL, if there isno subslot available in the SDCCH_POOL. This means that, whenthe SDCCH load decreases and the congestion in theSDCCH_POOL ends, no SDCCH will be allocated in the

SDCCH_BACKUP_POOL anymore.Whether a TCH/SD currently in the SDCCH_BACKUP_POOL can bemoved back to the TCH/SD_POOL is checked during every release

procedure for an SDCCH: during the SDCCH release the BSC checks the current SDCCH traffic load according to the following formula

Notes:* the calculation always considers the total amount of SDCCH subslots from both the

SDCCH_POOL and the SDCCH_BACKUP_POOL

** “no. of idle TCHSDs in BACKUP_POOL” means:1) all TCHSDs in the SDCCH_BACKUP_POOL in usage state “idle” and2) all TCHSDs in the SDCCH_BACKUP_POOL for which TGUARDTCHSD is runningThis means: If there is no TCHSD in the SDCCH_BACKUP_POOL then the term

8 ∗ (no. of idle TCHSDs in BACKUP_POOL) = 0.

The calculated SDCCH traffic load is compared to the threshold SDCCHCONGTH (see command SET BTS).

a) In case of SDCCH traff ic load ≥ SDCCHCONGTH the TCH/SD remains in the SDCCH_BACKUP_POOL and TGUARDTCHSD is not started.b) In case of SDCCH traffic lo ad < SDCCHCONGTH the timer TGUARDTCHSD is started for those TCH/SDs which are in‘idle’ mode (no SDCCH subslot in state ‘busy’). When it expires, theTCH/SD is moved back from the SDCCH_BACKUP_POOL to theTCH/SD_POOL. If TGUARDTCHSD=SEC00, idle TCH/SDs are

immediately moved back to the TCH/SD_POOL when theabovementioned SDCCH traffic load condition is detected. If during the run time of TGUARDTCHSD another SDCCH request establishesthat the move condition (SDCCH traffic load > SDCCHCONGTH) isfulfilled again, TGUARDTCHSD is stopped and the TCH/SD remainsin the SDCCH_BACKUP_POOL.

Notes:- If TGUARDTCHSD is running for particular TCH/SD and the BSC receives a TCH request while all other TCHs are busy, thenTGUARDTCHSD is immediately stopped, the TCH is returned to theTCH/SD_POOL and the TCH request is satisfied with this channel.- Attention: The calculation of the SDCCH load that is compared to

∗ 100SDCCH traffic load [%] =no. of busy SDCCH subslots *

no. of SDCCH subslots in unlocked/enabled – 8∗(no. of idle TCHSDs in BACKUP_POOL)**





the threshold SDCCHCONGTH that is performed during the SDCCH release procedure is different from the one that is performed in caseof SDCCH assignment! - The BTS does not know anything about the association of theTCH/SD channels to the ‘BSC channel pools’. Instead, for the BTS aTCH/SD is treated as a normal dual rate TCH if it is ‘idle’ or if it hasreceived a CHANNEL ACTIVATION for channel type ‘TCH’. If it hasreceived a CHANNEL ACTIVATION for channel type ‘SDCCH’, it is

treated as SDCCH.This means that, even if TGUARDTCHSD is still running for aspecific TCH/SD in the BSC (i.e. the TCH/SD is still in theSDCCH_BACKUP_POOL), from point of view of the BTS theTCH/SD is treated as an dual rate TCH again. This means that theBTS might send idle channel measurements (see parameter INTCLASS in command SET BTS [INTERF]) during this period, evenif the TCH/SD is still in the SDCCH_BACKUP_POOL.

TRACEMG=1,


(unit: 480ms)

range: 1..254

default: 1

Trace measurement granular i ty , this parameter determines thesending granularity for the TRACE MEASUREMENT RESULT messages. These TRACE MEASUREMENT RESULT messages aresent from BTS to BSC during calls for which the call trace featuresIMSI tracing (see command CREATE TRACE) or Cell Traffic recording (CTR, see command CREATE CTRSCHED) are enabled.

The BTS starts to send the TRACE MEASUREMENT RESULT messages to the BSC when it receives the START TRACE messagefrom the BSC (see also parameter TRACEMR). The sending isstopped when the BSC sends STOP TRACE message or when thecall is released. As from point of view of the BTS there is nodifference between IMSI tracing and CTR the sending granularity determined by TRACEMG is valid for both features.

TRACEMR=TRUE,


range: TRUE, FALSE

default: TRUE

Trace measurement reports enabled , this parameter determineswhether the TRACE MEASUREMENT RESULT messages shall besent by the BTS or not. If TRACEMR=FALSE the BSC does not send the START TRACE message to the BTS and no radio measurementscan be recorded in the IMSI trace record or CTR trace record.

TRANSPM=FALSE,

object: BSC [BASICS]range: TRUE, FALSE

default: FALSE

Transparent messages , this parameter is relevant for a new BR8.0 Performance Measurement Counter called ‘Mean number of busy

SDCCHs per signalling procedure (MBUSYSSP)’. The purpose of this counter is to allow a more detailed observation of the SDCCH traffic with respect to the traffic type that was processed via theallocated SDCCH. Different subcounters distinguish the meannumber of busy SDCCHs for

- Signalling for TCH connection (MOC, MTC)- Short Message Service (SMS-MO and SMS-MT)- SS Supplementary Service Management (SCI)- USSD Transactions- other signalling procedures (Location Update, IMSI Detach etc.)- abnormal SDCCH activations (e.g. no ESTABLISH INDICATION received for activated SDCCH).

One central requirement for the introduction of the counter MBUSYSSP was the possibility to count USSD procedures

(Unstructured Supplementary Service Data) separately. USSD procedures are non-standardized Supplementary Service procedures that may be defined operator specifically and which allow the subscribers to control particular network-specifc services by entering specific service codes as key combination on the mobile

phone. As the general signalling message sequence for USSDtransaction is exactly the same like for SCI procedures for standardized SS procedures, the distinction between both cases isonly possible if the BSC analyzes the contents of the FACILITY messages which are normally transparent for the BSS. This ‘in depth’ analysis of normally transparent messages, however,considerably increases the TDPC processor load. For this reason, the parameter





TRANSPM was introduced to allow the operator to avoid thedescribed TDPC performance impact if a separate counting of standardized SCI procedures and USSD transactions is not required:

a) If TRANSPM is set to TRUE and the measurement MBUSYSSP isactivated, then USSD transactions will be counted separately by thesubcounter for ‘USSD signalling’. The subcounter ‘SS Management’ will only count all other standardized SCI procedures. In this case theTDPC processor load is increased by the necessary additional

analysis efforts.b) If TRANSPM is set to FALSE and the measurement MBUSYSSP is activated, then USSD transactions will be counted together with all other standardized SCI procedures by the subcounter ‘SSManagement’. In this case the TDPC processor load is not affected.

TRFCT=20,


unit: 1 halfsecond

range: 10.. 200

default: 20 (=10 seconds)

Traff ic (handover) control t im er , this parameter determines thetime between two consecutive traffic load checks which are

performed by the BSC. TRFCT is initialized on every initialization or startup of the TDPCs and is automatically restarted on every expiry.When TRFCT expires, the BSC checks the traffic load in its cells and compares it to BTS specific thresholds associated to the following features:

a) Traffic handover (see parameter TRFHOE in command SET

HAND [BASICS]):When TRFCT expires, the BSC checks the traffic load in its cells and compares it to the traffic handover high threshold (see parameter TRFHITH in command SET HAND) set for the affected BTS. If thetraffic load in the cell is above the cell-specific threshold TRFHITH,the BSC enables the traffic handover in the affected BTS by sending an LAPD O&M message SET ATTRIBUTE with the indication ‚traffic handover enabled’ ‚to the BTSM. This O&M message is the trigger for the BTS to start the traffic handover decision algorithm (for moredetails please refer to the appendix ‚Handover Thresholds and

Algorithms’). If the traffic handover was already enabled for a specific BTS on the previous expiry of TRFCT and the traffic load in theaffected BTS is still above the threshold TRFHITH, no further message is sent to the BTS and the traffic handover remains enabled

in the affected BTS. If the traffic handover was enabled for a specific BTS on the previous expiry of TRFCT and the traffic load in theaffected BTS has decreased below the threshold TRFHITH, the BSC disables the traffic handover in the affected BTS by sending an LAPDO&M message SET ATTRIBUTE with the indication ‚traffic handover disabled’ to the BTS.

In the BTS, the timer TRFHOT (see SET HAND [BASICS]) is used tocyclically decrease the dynamic traffic handover margin, if the traffic handover remains enabled for a longer time period. A reasonablesetting of the BSC traffic control timer TRFCT and TRFHOT is

TRFHOT (HAND) > TRFCT (BSC)

This timer combination ensures that the traffic load situation ischecked by the BSC before the BTS initiates the next step of traffic handover margin reduction.

For further details please refer to the explanations provided for theremaining traffic handover parameters (see parameter TRFHOE incommand SET HAND).

b) C ompression-Decompression handover : On every expiry of TRFCT t he BSC checksa) the traffic load in its cells and compares it to the threshold HRACTAMRT1 / HRACTAMRT2 , HRACTT1/HRACTT2 (for compression handover) and FRACTTH1/FRACTTH2 and FRACTAMRTH1/FRACTAMRTH2 (for decompression handover, seecommand SET BTS [BASICS]) or/and b) the Abis pool TCH load towards a particular BTSM and compares





it to the threshold ABISHRACTTHR and ABISFRACTTHR.

If , based on the thresholds and the current TCH load the BSC detects the condition for compression or decompression handover ,the BSC enables the compression or decompression handover in theaffected BTS by sending an LAPD O&M message SET ATTRIBUTE with the appropriate indication to the BTS. This indication starts theC ompression /Decompression handover decision process in the BTS.For further details, please refer to the parameter EADVCMPDCMHO

(see command SET HAND [BASICS]. TRFPS=FALSE,


range: TRUE, FALSE

default: FALSE

Traff ic control packet switched , this parameter determines whether the feature ‘GPRS traffic control strategy’ is enabled for GPRSNetwork Controlled Cell Reselection in the BSC. This parameter isonly relevant if GPRS Network Controlled Cell Reselection wasenabled by setting the parameter NCRESELFLAG to ENABLE (seeabove).In case of traffic congestion within one cell, the Traffic Control Network Controlled Cell Reselection is applied for GPRS and EGPRS in order to spread the load by transferring some traffic towards the neighbour cells. Based on cell traffic thresholds, thetraffic is distributed among the cells belonging to the same PCU (Packet Control Unit) within the appropriate BSC. The BSS updatesthe internal references that indicate the location of the MS, and

related information is sent to the serving GPRS support nodesinvolved.

Network controlled cell reselection distributes MSs among cellsaccording to network criteria due to traffic conditions. Through thesenetwork criteria, the optimum use of re-sources is achieved, and abetter traffic distribution among the available channels is established in all the available cells of one BSC.

This feature is enabled per BSC, but the parameterization takes place on a per cell basis.

For further details please refer to the parametersCRESELTRHSOUT, CRESELTRHINP, NCTRFPSCTH,TRFPSCTRLT, NTWCREPPIDL, NTWCREPPTR, NTWCNDRXP,TDDGQO, GNMULBAC, GFDDREPQTY and GUMTSSRHPRI (see

command CREATE PTPPKF) and NCGRESOFF, NCGTEMPOFF,NCGPENTIME (see command CREATE ADJC).

TYPOFAMC=DK40,


range: DK40, CPEX, ES

Type of Alarm Module C , this parameter defines the type of theequipped alarm module card.

TYPOFETH=DK40,


range: ETHERNETII, IEEE802

default: ETHERNETII

Type of Ethernet , this parameter determines the type of Ethernet adopted for the internal LAN.

UPGRFREQ Moved to CPCU object in BR8.0.





Creating new database parameters without info model change:

BRIDGE BSC :

<The BRIDGE BSC command was introduced to avoid highdevelopment cost CR solutions that are introduced on customer

pressure within a life cycle of a release. BRIDGE BSC allows theintroduction/management of new configurable database parameters,required by change requests (CR) in the latest phases of a release,without any further InfoModel change. Nearly all CRs introducing new functionalities require an enabling/disabling mechanism, and most of them require also some specific attributes. In general the modelling of attributes is decided in accordance with R&D.

In the subsequent releaseses the management of these new database parameters, already known and used by customers, can bemoved into the specific command/object of the info model incorrespondence with the parameters’ association to a particular object. The databases are automatically converted correctly by DBAEM and CONVFILE tools.>


ATT1=<NULL>,

object: BSC

format: parameter name -

parameter value

range: parameter name:

“<15 characters string>” -

parameter value

<value as defined by R&D>

default: <NULL>

Attr ibute 1 , this parameter allows the definition of a new attributename and its attribute value. The association of this parameter to a

particular database command and object is defined by the parameters RELCMD and RELOBJ (see below).

The ATTx parameter value consists of two partsa) a parameter name, which consists of a symbolic name string (max.15 characters) and b) the associated parameter value as defined by R&D.

the following example may illustrate the application of the BRIDGE BSC command

BRIDGE BSC:BSC:0,RELCMD = SET,RELOBJ = BTSM:2/BTS:3, ATT1 = “PIPPO” - NULL(0), ATT2 = “PLUTO” - i(55), ATT3 = “CIP” - b(TRUE), ATT4 = “CIOP” - s(“OK”), ATT5 = “TAPPO” - p(BTSM:5/BTS:1);

The equivalent for this command in classic syntax would be:

SET BTS:NAME=BTSM:2/BTS:3,PIPPO = <NULL>,PLUTO = 55,CIP = TRUE,CIOP = “OK”,TAPPO = BTSM:5/BTS:1;

ATT2..ATT8=<NULL>,

object: BSC

format: parameter name - parameter value

range: parameter name:

“<15 characters string>” -

parameter value

<value as defined by R&D>

default: <NULL>

Attr ibute 2 .. Attr ibute 8 , these parameters allow the definition of additional parameters and valuese (see parameter ATT1).





RELCMD=<NULL>,

object: BSC

range: SET, GET

default: <NULL>

Related comm and , this parameter defines the association of thedefined attributes (ATT1..ATT5) to a particular database command.

RELOBJ=<NULL>,

object: BSCrange: <object path name>

default: <NULL>

Related o bject , this parameter defines the association of the defined attributes (ATT1..ATT5) to a particular database object.

Setting the alarm priorities of the BSS functional objects:

SET BSC [ALARMSEV]:

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“[ALARMSEV]” 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 .

ALRMSEVBTS=CRITICAL,

object: BSC [ALARMSEV]

range: Minor, Major, Critical

default: Critical

Alarm sever i ty BTS , determines the alarm severity of the BTSobject.

ALRMSEVBTSM=MAJOR,



default: Major

Alarm sever i ty BTSM , determines the alarm severity of the BTSM object.

ALRMSEVBTSMTD=MAJOR,



default: Major

Alarm sever i ty BTSMTD , determines the alarm severity of the

BTSMTD (BTSM for TD-SCDMA) object

ALRMSEVBTSTD=CRITICAL,



default: Critical

Alarm sever i ty BTSTD , determines the alarm severity of the BTSTD(BTS for TD-SCDMA) object.

ALRMSEVCBCL =MAJOR,



default: Major

Alarm sever i ty CBCL , determines the alarm severity of the CBCLobject.

ALRMSEVFRL=MINOR,



default: Minor

Alarm sever i ty FRL , determines the alarm severity of the FRLobject.

ALRMSEVIPLI=MAJOR,



default: Major

Alarm sever i ty IPLI , determines the alarm severity of the IPLI (IP link for connetion to RC/) object





ALRMSEVLPDLM=MAJOR,



default: Major

Alarm sever i ty LPDLM , determines the alarm severity of the LPDLM object.

ALRMSEVLPDLMTD=MAJOR,

object: BSC [ALARMSEV]range: Minor, Major, Critical

default: Major

Alarm sever i ty LPDLMTD , determines the alarm severity of theLPDLMTD object. (LPDLM for TD-SCDMA BTSM).

ALRMSEVLPDLR=MAJOR,



default: Major

Alarm sever i ty LPDLR , determines the alarm severity of the LPDLR object.

ALRMSEVLPDLRTD=MAJOR,



default: Major

Alarm sever i ty LPDLRTD , determines the alarm severity of theLPDLRTD object. (LPDLR for TD-SCDMA TRX).

ALRMSEVLPDLS=MAJOR,



default: Major

Alarm sever i ty LPDLS , determines the alarm severity of the LPDLSobject.

ALRMSEVNSVC=MINOR,



default: Minor

Alarm sever i ty NSVC , determines the alarm severity of the NSVC object.

ALRMSEVOMAL=MAJOR,



default: Major

Alarm sever i ty OMAL , determines the alarm severity of the OMALobject.

ALRMSEVPCMA=MAJOR,



default: Major

Alarm sever i ty PCMA , determines the alarm severity of the PCMAobject.

ALRMSEVPCMB=MAJOR,



default: Major

Alarm sever i ty PCMB , determines the alarm severity of the PCMBobject.

ALRMSEVPCMG=MAJOR;


range: Minor, Major, Criticaldefault: Major

Alarm sever i ty PCMG , determines the alarm severity of the PCMGobject.

ALRMSEVPCMS=MAJOR,



default: Major

Alarm sever i ty PCMS , determines the alarm severity of the PCMSobject.

ALRMSEVPCU=CRITICAL,



default: Critical

Alarm sever i ty PCU , determines the alarm severity of the PCU object.





ALRMSEVPCUTD=CRITICAL,



default: Critical

Alarm sever i ty PCUTD , determines the alarm severity of thePCUTD (PCU for TD-SCDMA packet switched services) object.

ALRMSEVPTPPKF=MAJOR,

object: BSC [ALARMSEV]range: Minor, Major, Critical

default: Major

Alarm sever i ty PTPPKF , determines the alarm severity of thePTPPKF object.

ALRMSEVTDCU=CRITICAL,



default: Critical

Alarm sever i ty TDCU , determines the alarm severity of the TDCU (TD-SCDMA control unit) object.

ALRMSEVTRAU=CRITICAL,



default: Critical

Alarm sever i ty TRAU , determines the alarm severity of the TRAU object.

ALRMSEVTRX=MAJOR,



default: Major

Alarm sever i ty TRX , determines the alarm severity of the TRX

object.

ALRMSEVTRXTD=MAJOR,



default: Major

Alarm s ever i ty TRXTD , determines the alarm severity of the TRXTDobject (TRX in TD-SCDMA BTS).

Setting the remote Inventory data of the BSC Equipment:

SET BSCE [REMINV] :

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BSCE packages’ were moved below the object BSCE and appear in the DBAEM in the SET BSCE command. The logical group“[REMINV]” is normally only used on the LMT but was used here toallow a more useful grouping of the commands .

NAME=BSCE:0, Object path name .

SALUNAME=”BSC1”,

object: BSC [REMINV]

range: alphanumeric string

(11 characters)

in quotation marks

default: NOT_DEFINED

Sales Uniqu e Name , this attribute defines the BSC Network Element by its unique symbolic name.

EQPOS=”010101”,

object: BSC [REMINV]


(6 characters)

in quotation marks

default: “010101”

Equipment posi t ion , this attribute defines the position of theNetwork Element.





EAUTOREC=ENABLED,

object: BSC[REMINV]


default: DISABLED

Enable auto recovery , this attribute enables the automatic recovery.

Setting the alarm priorities of the BSCE objects:

SET BSCE [ALARMSEV]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BSCE packages’ were moved below the object BSCE and appear in the DBAEM in the SET BSCE command. The logical group“[ALARMSEV]” is normally only used on the LMT but was used hereto allow a more useful grouping of the commands .

NAME=BSCE:0, Object path name .

ALRMSEVCPEX=CRITICAL,

object: BSCE [ALARMSEV]range: Minor, Major, Critical

default: Minor

Alarm sever i ty CPEX , determines the alarm severity of the CPEX object (the CPEX (Control Panel and External alarms device) is the

card which reports to MPCC 16 external alarms and the FAN alarmand controls the fuse and alarm panel.

ALRMSEVDISK=MAJOR,

object: BSCE [ALARMSEV]


default: Major

Alarm s ever i ty DISK , determines the alarm severity of the DISK object.

ALRMSEVDK40=MAJOR,



default: Major

Alarm sever i ty DK40 , determines the alarm severity of the DK40 object.

ALRMSEVEPWR=MAJOR,



default: Major

Alarm sever i ty EPWR , determines the alarm severity of the EPWR

object.

ALRMSEVIXLT=MAJOR,



default: Major

Alarm sever i ty IXLT , determines the alarm severity of the IXLT object.

ALRMSEVLICD=MINOR,



default: Minor

Alarm sever i ty LICD , determines the alarm severity of the LICDobject.

ALRMSEVLICDS=MINOR,



default: Minor

Alarm sever i ty L ICDS , determines the alarm severity of the LICDSobject.

ALRMSEVME2M=MAJOR,



default: Major

Alarm s ever i ty ME2M , determines the alarm severity of the ME2M object.





ALRMSEVMEMT=MAJOR,



default: Major

Alarm sever i ty MEMT , determines the alarm severity of the MEMT object.

ALRMSEVMPCC=MAJOR,



default: Major

Alarm sever i ty MPCC , determines the alarm severity of the MPCC object.

ALRMSEVNTW=MAJOR,



default: Major

Alarm sever i ty NTW , determines the alarm severity of the NTW object.

ALRMSEVPPCC Canceled in BR8.0

ALRMSEVPPCUFehler!Textmarke nicht definiert.

Canceled in BR8.0

ALRMSEVPPLD Canceled in BR8.0

ALRMSEVPPXL=MINOR,



default: Major

Alarm s ever i ty PPXL, determines the alarm severity of the PPXL

object.

ALRMSEVPPXP=MINOR,



default: Min or

Alarm s ever i ty PPXP , determines the alarm severity of the PPXP object.

ALRMSEVPPXT=MINOR,



default: Min or

Alarm s ever i ty PPXT , determines the alarm severity of the PPXT object.

ALRMSEVPPXU=MINOR,



default: Min or

Alarm s ever i ty PPXU , determines the alarm severity of the PPXT object.

ALRMSEVPWRD=MAJOR,



default: Major

Alarm sever i ty PWRD , determines the alarm severity of the PWRDobject.

ALRMSEVSYNC=MAJOR,



default: Major

Alarm sever i ty SYNC , determines the alarm severity of the SYNC object.

ALRMSEVSYNE=MAJOR,



default: Major

Alarm sever i ty SYNE , determines the alarm severity of the SYNE object.

ALRMSEVTDPC=MAJOR,



default: Major

Alarm sever i ty TDPC , determines the alarm severity of the TDPC object.

ALRMSEVX25A=MAJOR, Alarm s ever i ty X25A, determines the alarm severity of the X25A







default: Major

object.

ALRMSEVX25D=MAJOR;



default: Major

Alarm s ever i ty X25D , determines the alarm severity of the X25Dobject.

Creating the Power Supply:

CREATE EPWR:

NAME=EPWR:0; Object path name .





Creating the spare PCM interface boards:

CREATE LICDS:

NAME=LICDS:0, Object path name .

Creating the PCM interface boards:

CREATE LICD:

NAME=LICD:0, Object path name .

ALACOUNT=32,

object: LICD

unit: 1

range: 2-254

default: 32

PCM alarm c ounter , determines the threshold for errors that lead toa PCM alarm (see also previous parameter ALARMT3).

ALARMT1=20,

object: LICD

unit: 0,1s

range: 2-254

default: 200=20s

PCM alarm timer 1 determines the error-free time after which a

previously alarmed PCM line is put back to service, i.e. the linereturns to service after [ALARMT1∗ 0.1] error-free seconds.

ALARMT2=2,

object: LICD

unit: 0,1s

range: 2-254

default: 10=1s

PCM alarm timer 2 determines the time (1 unit = 0.1s) after which an

disturbed PCM line is put out of service, i.e. after [ALARMT2 ∗ 0.1] seconds of line alarm the line is disabled.Rules:1) ALARMT2 < (TGUARD - TSBS)(for TGUARD and TSBS see command CREATE OPC [BASICS]).This setting is only valid if the LICD is used for connection of aPCMS. It avoids A-interface reset (and thus call release) procedureseven if the link interruption is very short.2) ALARMT2 < TSYNC and ALARMT2 < TTRAU (for TSYNC and TTRAU see command SET BTS [TIMER])This setting is necessary in order to avoid call release before PCM alarm detection.

ALARMT3=5;

object: LICD

unit: 5 min

range: 1-254

default: 1

PCM alarm timer 3 , determines the timeframe for the counting of PCM line errors. A PCM line is set in ‘alarmed state’ if <ALACOUNT>

line errors are detected within [ ALARMT3∗ 5] minutes





CREATE PPLD Canceled - PPLD is no longer su pported in BR8.0!

Creating the common attributes for all PCUs belonging to the entire BSC:

< The CPCU object was introduced with BR8.0 to define attributescommon for several PCUs belonging to the BSC. Please note that

many parameters were moved from the PCU object to the CPCU object in BR8.0. >

CREATE CPCU:

NAME=CPCU:0, Object path name . Range for pcun = 0..11The supported values for pcun depend on the used HW:- pcun = 0,…,5 HC BSC 72 (PPXX; QTLP)- pcun = 0,…,11 HC BSC 120 (PPXX; STLP)

DNLBSSPFCRET=3,

object: CPCU

range: 1.. 5

default: 3

Down load BSS PFC Retr ies , this parameter guards theDOWNLOAD-BSS-PFC-RETRIES number.

DNLBSSPFCT=50,

object: CPCU

unit: 100ms

range: 2.. 99

default: 50

Downlo ad BSS PFC Timer , this parameter represents the timer T6

and guards the DOWNLOADBSS-PFC procedure.

FCRATE=100,

object: CPCU

range: 0.. 100

default: 100

Low pass fi l ter coeff ic ient leak rate , this parameter is the Low PassFilter Coefficient used to filter Leak_Rate oscillation. The filtering applied is the following: Rmax_eFC=alpha*Rmax(Tnow)+(1-alpha)*Rmax(Tnow-C).

MODBSSPFCRET=3,

object: CPCU

range: 1.. 5

default: 3

Modify BSS PFC Retr ies , this parameter guards the MODIFY-BSS-PFC-RETRIES number.

MODBSSPFCT=50,

object: PCU

unit: 100ms

range: 2.. 99

default: 50

Modify B SS PFC Timer , this parameter represents the timer T6 and guards the MODIFY-BSS-PFC procedure.

N3101=20,

object: CPCU

range: 9..255

default: 20


This parameter defines the threshold fo r non-val id-data error

coming from the m obi le stat ion after having sent USF.N3101 represents a counter on the network side:If the network receives a valid data block from the MS after setting the Uplink State Flag (USF), N3101 is reset.. The counter isincremented for each USF for which no valid data is received. If N3101 reaches the threshold value, the PCU considers the TBF lost,stops scheduling RLC/MAC blocks for this USF and starts timer T3169.

Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.





N3103=10,

object: CPCU

range: 1.. 255

default: 10

This parameter defines the threshold for n ot received PACKET

CONTROL ACK as response to PACKET UPLINK ACK/NACK messages.N3103 represents a counter on the network side:If the network receives PACKET CONTROL ACK from the MS asresponse to a final PACKET UPLINK ACK/NACK, N3103 is reset. If the network does not receive the PACKET CONTROL ACK in the

scheduled block, N3103 is incremented and the PACKET UPLINK ACK/NACK message is retransmitted.If N3103 reaches the threshold value, timer T3169 is started.


N3105=10,

object: CPCU

range: 1.. 255

default: 10

This parameter defines the threshold fo r not received RLC/MAC

contro l message as response to a polled RLC/MAC data block ..N3105 represents a counter on the network side:If the network receives a valid RLC/MAC control message from theTBF, N3105 is reset. The counter is incremented for each radio block allocated to that TBF with the RRBP field set, for which no RLC/MAC control message is received.If N3105 reaches the threshold value, the network regards thecommunication with the MS lost, stops transmitting RLC data blocksand starts T3195.


NBVCBR=3,

object: CPCU

range: 1.. 30

default: 3

Numb er of BVC Block Retr ies . This parameter is used within theBVCI block procedure. If a BVC-BLOCK PDU is not acknowledged within T1 seconds from the SGSN, the blocking procedure isrepeated at maximum NBVCBR times. After NBVCBR unsuccessful reattempts, the BVCI status remains blocked and an O&M alarm isgenerated.


NBVCRR=3,

object: CPCU

range: 1.. 30

default: 3

Numb er of BVC Reset Retr ies. This parameter is used within theBVCI reset procedure. If a BVC-RESET PDU is not acknowledged within T2 seconds from the SGSN, the reset procedure is repeated at maximum NBVCRR times. After NBVCRR unsuccessful reattempts,the BVC status shall be blocked and an O&M alarm is generated.


NBVCUR=3,

object: CPCU

range: 1.. 30

default: 3

Numb er of BVC Unblock Retr ies . This parameter is used within theBVCI unblock procedure. If a BVC-UNBLOCK PDU is not acknowledged within T1 seconds from the SGSN, the unblocking

procedure is repeated at maximum NBVCUR times. After NBVCUR unsuccessful reattempts, the BVCI status remains blocked and anO&M alarm is generated.


NRACPBLUPDRET=3,

object: CPCU

range: 1.. 30

default: 3

Numb er of RA capabi l i ty update retr ies , this parameter providesthe maximum number of retransmission of RA-Capability-Update toSGSN when BSC does not accept correspondent answer (RA-Capability-Update-Ack) from SGSN.





NRLCMAX=20,

object: CPCU

range: 20..64

default: 20

This parameter specifies the rate of PACKET UPLINK ACK/NACK

and PACKET DOWNLINK ACK/NACK messages being used during packet transfers in RLC/MAC acknowledged mode.During UL TBFs: After each reception of NRLCMAX UL data blocksthe PCU issues a PACKET UPLINK ACK/NACK message. Thisapplies under all circumstances for the currently supported MSmultislot classes 1-10 (max. 2 UL timeslots).

During DL TBFs: In average every NRLCMAX-th DL data block is polled (RRBP set) to request a PACKET DOWNLINK ACK/NACK from the mobile. This behaviour applies for DL transfers with 1 or 2 timeslots allocated.In case the DL TBF is allocated on 3 timeslots, the effective polling distance is defined by (NRLCMAX-5).In case the DL TBF TBF is allocated on 4 timeslots, the effective

polling distance is defined by (NRLCMAX-12).This reduced polling period (every 15

th /8

thblock) is required to

optimize the throughput under field conditions. Faster polling allowsthe quick retransmission of not acknowledged blocks and thereforehelps to avoid a stall condition on RLC/MAC layer (with only 64blocks window size in case of GPRS).

Note: This parameter was moved from the PCU object to the CPCU

object in BR8.0.

PREAT=20,

object: CPCU

unit: 100ms

range: 0.. 100

default: 20

Preal location timer , this parameter represents the timer guarding re-utilisation of preallocated resources for Real Time Packet Flow Context (RTPFC).

SISGSNREL99=TRUE,

object: CPCU

range: TRUE, FALSE

default: TRUE


System Information SGSN release 99 , this parameter determinesthe value of the ‘SGSN Release’ bit in the SYSTEM INFORMATION TYPE 13. This setting has a similar function like the parameter SIMSCREL99 (see above). It indicates that the Mobile Stations areallowed to use release-99-specific messages/information elements intheir signaling towards the network, which is a mandatory

precondition for specifc Rel. 99 procedures such as cell selection

between 2G and 3G. If SISGSNREL99 is set to TRUE (and thus the‘SGSN Revision’ bit is set to ‘1’ in the SYSINFO 13), the MSs areallowed to send Release-99-specific messages and informationelements in their signaling messages towards the network.

It is up to the network operator to set the value of this parameter incorrespondence with the real conditions (for the BSC, there is no way to check the release compliance of the SGSN) to avoid protocol errors.

The parameter SISGSNREL99 replaces the setting MNTBMASK=BIT9 which was used in BR6.0/BR6.1 to control the“SGSN Release“ bit in the SYSINFO 13.

Note: This parameter was moved from the BSC object to the CPCU object in BR8.0.

T1=10,

object: CPCU

unit: 1s

range: 2.. 29

default: 10

This timer defines the Wait ing time for BVCI block /unblock procedure . After the PCU has sent a BVCI block/unblock message,it waits maximum T1 seconds for the respective acknowledgement. Incase of timeout the procedure is repeated (refer to parametersNBVCBR and NBVCUR).






T2=10,

object: CPCU

unit: 1s

range: 2.. 119

default: 10

This timer defines the Wait ing time for BVCI reset procedure . After the PCU has sent a BVCI reset message, it waits T2 seconds for acknowledgement. In case of timeout the procedure is repeated (refer to parameter NBVCRR).


T3=50,

object: CPCU

unit: 0,1s

range: 1.. 100

default: 50 (= 5s)

T3 , this timer defines the waiting time for a response from the SGSN after sending a SUSPEND PDU.

T3141=5,

object: CPCU

unit: 1s

range: 1.. 30

default: 5

T3141 , this timer is started on the network side when a TBF isassigned with an IMMEDIATE ASSIGNMENT message during a

packet access procedure. It is stopped when the MS has correctly seized the TBF. If T3141 elapses before a successful contentionresolution procedure is completed, the newly allocated TBF isreleased.


T3169=5,

object: CPCU

unit: 1s

range: 1.. 30

default: 5


T3169 , this timer defines the waiting time to reuse the respective TFI and USF values after the thresholds N3101 and N3103 (see

parameters above) were reached.


T3172=5,

object: CPCU

unit: 1s

range: 0..255

default: 5

T3172 , is a timer running on the mobile side. It is included in thePACKET ACCESS REJECT message and indicates the time themobile station shall wait before attempting another packet channelrequest.


T3191=5,

object: CPCU

unit: 1s

range: 1-30

default: 5

T3191 , this timer defines the waiting time for reuse TFI after having

sent the last RLC block. It is started with the last DL data block sent in a TBF (Final Block Indicator=1) and stopped with the reception of the final PACKET DOWNLINK ACK/NACK (or PACKET CONTROL

ACK). On expiry the network releases the TFI allocated to that TBF.


T3193=4,

object: CPCU

unit: 100 ms

range: 1-42

default: 4

T3193 , this timer defines the time to wait for a reuse of the TFI after reception of the final Packet Downlink Ack/Nack from the mobilestation. On expiry the TFI resources are released.Rule: T3193 > T3192 (default = 500ms).

Note: Setting T3193 to the value 4 (=400ms) still fulfils the above ruledue to system-internal propagation times. Important is that T3193expires after T3192 surely elapsed (ensuring that the MS already abandoned this TFI).






T3195=5,

object: CPCU

unit: 1s

range: 0..255

default: 5


T3195 , this timer defines the time to wait for a reuse of the TFI after the threshold N3105 (see above parameter) was reached. Mainreasons for N3105 expiry are radio link failure or cell reselection.

T4=10,

object: CPCU

unit: 0,1s

range: 1.. 100

default: 10 (= 1s)

T4 , this timer defines the waiting time for a response from the SGSN after sending RESUME PDU.

T5=10,

object: CPCU

range: 2.. 29

default: 10

T5 , this timer is started from BSC when RA-Capability-Update isstransmitted to SGSN and stops it when RA-Capability-Update-Ack isreceived.

TEMPCH=30,

object: CPCU

unit: 1s

range: 1.. 254

default: 30


Timer Empty Channel , this timer specifies the delay time for therelease of an allocated PDCH if there are no TBF activities.

If GPRS/EGPRS calls are set up, the TDPC is responsible for 1. the assignment of the proper radio resources on the air interface(PDCHs) and 2. the assignment of the Abis interface subslots related to thesePDCHs.

The PPXU always knows the number of PDCHs (i.e. radio TCHsused as PDCH) in use in a particular cell at a given time. Theseallocated PDTCHs can assume two main states: either a) at least one TBF is currently assigned on the PDCH or b) the last TBF on the PDCH has been stopped.

The timer TEMPCH is started on the stop of the last TBF and keepsthe allocated TCH activated to serve possible new TBFs, i.e. whenthe last MS associated to a PDCH is released (no TBF is ongoing onthe PDCH anymore) the “virtual” assignment of the PDCH persists for

the duration of the timer TEMPCH. The purpose of this timer is toavoid continuous channel allocation requests from the PCU to theTDPC and the associated CHANNEL ACTIVATIONs and IMMEDIATE ASSIGNMENT procedures which would happen in

periods of high GPRS/EGPRS traffic if the allocated resources weredirectly released after the stop of the TBF activities on the allocated TCHs.

As long as TEMPCH is running, the allocated PDCH(s) for the“released” TBF are still regarded as allocated even if they are not used for the transfer of payload. However, if a TCH was activated asPDCH for GPRS traffic but the TEMPCH timer is running for it, (whichmeans that there is no ongoing TBF on the TCH), the TCH is alwaysregarded as ‘downgradable’ resp. ‘preemptable’ for CS calls, nomatter which value was set for the DGRSTRGY parameter (see

command CREATE BTS [BASICS]). In other words, in periods of TCH congestion the BSC immediately releases PDCHs (TCHsactivated for GPRS) with TEMPCH running if a CS TCH request isreceived and no other idle TCH is available for allocation. Thischange was implemented in BR7.0 in the scope of CR1150 (see also

parameters DGRSTRGY (in command CREATE BTS [BASICS].






TEMPPDT=1,

object: CPCU

unit: 1s

range: 1.. 30

default: 15

Timer for empty PDT , this parameter is the equivalent to the parameter TEMPCH (see above) for Packet Data Terminal (PDT)resources allocated on the PCU. TEMPPDT determines the delay time for the release of an allocated PDT with subframe counter > 0 if the related PDCH does not require this PDT anymore (e.g. due to adowngrade of the used coding scheme).The value of TEMPPDT must be smaller than TEMPCH.

If GPRS/EDGE calls are set up, the TDPC is responsible for 1. the assignment of the proper radio resources on the air interface(PDCHs) and 2. the assignment of the Abis interface subslots related to thesePDCHs.The timer TEMPPDT is used to avoid continuous requests for Abisresources from the PCU to the TDPC.Example situation:

An MCS9 DL TBF is allocated on 2 radio timeslots (PDCH). Each of the PDCHs has five 16kbit/s Abis subslots allocated – in total 10 PDTs are in use on PCU side. Let us assume a sudden downgradeof the coding scheme to MCS6 now (due to bad radio conditions). Assoon as the coding scheme MCS6 is applied from the PCU, only 3 of the previously 5 Abis subslots (and PDTs) are necessary to transport

the user data for each PDCH. TEMPPDT is started at that moment for the 2+2 affected PDTs (with subframe counter 3 and 4) – and if noupgrade to a higher coding scheme occurs within the runtime of TEMPPDT (or another MS using MCS9 is vertically allocated, etc.)these 4 Abis resources are released.


TEXTULTBF=15,

object: CPCU

unit: 1s

range: 0.. 49

default: 15

Time extended Upl ink TBF , this attribute is used to delay therelease of an UL Temporary Block Flow (TBF) in Extended UL TBF mode.

TF=6,

object: CPCU

range: 6.. 5999

default: ???

TF , when SGSN receives PFC FLOW CONTROL parameters, SGSN

starts TF Timer. When TF expires SGSN may use SGSN Bmax and R generated and not more last Bmax and R sent by BSC. TF isrestarted each time a PFC FLOW CONTROL parameters arereceived.

TF1=5,

object: CPCU

unit: 1s

range: 2.. 9

default: 5

GSM: 08.18


This timer defines the Time for capaci ty report ing per iod used inflow control algorithm. It corresponds to the C timer reported in theGSM 8.18 recommendation and specifies the minimum time period allowed between two consecutive FLOW-CONTROL PDUs.


TH=6,

object: CPCU

range: 6.. 5999

default: ???

TH , when SGSN receives MS FLOW CONTROL parameters, SGSN starts TH Timer. When TH expires SGSN may use SGSN Bmax and R generated and not more last Bmax and R sent by BSC. TH isrestarted each time a MS FLOW CONTROL parameters arereceived.





THPROXT=500..50..550,

object: CPCU

format: thproxt1-thproxt2-thproxt3

unit: thproxt1: 1ms

thproxt2: 1s

thproxt3: 1s

range: thproxt1: 10..999

thproxt2: 1..100thproxt3: 101..1000

default: 500..50..550

Threshold Proximity Timer , this parameter implements 3 thresholdsfor TH-proximity evaluation.Note: These timers were implemented based on older specificationswhich are no more valid now. Therefore they are not used by thesystem.

Caution: These three parameters were repeatedly “abused” for development and system test purposes in order to implement

additional test features – partly also customer relevant features. At the current stage of BR70 no official released functionalities arecontrolled by them, therefore we strongly recommend to set thedefault values unless otherwise officially specified!

THSULBAL=587,

object: CPCU

range: 0.. 2000

default: 587

Threshold switch up l ink balanced , this parameter indicates thethreshold that the field ‘RLC_Octet_Count’ (part of the Channel Request Description IE) has to exceed to activate an ‘uplink priority’ condition.If ‘RLC_Octet_Count’ exceeds the value of THSULBAL, the systemallocates two PDCHs in uplink direction instead of preferring thedownlink direction (while a concurrent DL TBF is active). Thisfunctionality is important for mobiles with multislot class 6 (3+2; total 4) and 10 (4+2; total 5). A class 6 mobile e.g can be used either in3+1 or in 2+2 configuration, so there is a trade-off between themaximum possible UL and DL speed. The network decides based onTHSULBAL and TSULBAL which configuration is preferred. Please see also parameter TSULBAL.Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

TIMEDTBFREL=15

object: CPCU

unit: 100ms

range: 0.. 49

default: 15

Time delay for TBF release , this timer is used to delay the releaseof an ongoing DL TBF.Dummy LLC-PDUs are inserted to keep a DL-TBF open for thespecified time interval. This allows a faster transfer of new DL dataarriving on the Gb-interface (DL TBF already open) and a faster setup of new UL TBFs (as concurrent TBFs).


TPFCBUFF=20

object: CPCU

unit: 1s

range: 5.. 30

default: 20

Timer PFC buffer , this timer is defined for each allocated PFC_Buffer. It is started when PFC_Buffer gets empty. It is stopped and cancelled if new LLC Frames are coming for that PFC_Buffer.When it expires, the relative PFC_Buffer is de-allocated and Downlink TBF Scheduling Weight Updating Algorithm is started.

TSULBAL=20,

object: CPCU

range: 0..100

default: 20

Timer switch upl ink b alanced , represents a timer to activate the‘uplink priority’ condition.If an UL TBF was originally opened with RLC_Octet_Count <=THSULBAL (assuming a small amount of data to be transferred), only a single timeslot was allocated in UL. If however the resulting UL TBF lasts longer than TSULBAL, the system activates the ‘uplink priority’ condition and upgrades the UL TBF resources if applicable.Please see also parameter THSULBAL.






UPGRFREQ=SEC1-SEC1,

object: CPCU

format: <uplink> - <downlink>

range: SEC1..SEC8 (both fields)

default: SEC1 (both fields)

Upgrade frequency for packet sw itched traff ic , this parameter controls the time to pass between two consecutive radio resourceupgrade attempts for packet services separately for the uplink (first field of parameter value) and the downlink (second field of parameter value) in steps of 1 second.

During a TBF lifetime, due to variations in radio conditions, either theBLER or the used CS/MCS coding scheme can change, leading to a

change in the ‘maximum sustainable throughput’. The BSC periodically performs a check of the current maximum sustainablethroughput (MST) and compares it to a particular threshold which isindividually calculated on the basis of the parameter

ACCEPTGDEGR. For details about the calculation and the upgradeof radio resources due to a drop of the MST please refer to the

parameter ACCEPTGDEGR (see above).

The minimum time between two consecutive packet resourceupgrade attempts is 1 second (value SEC1), the maximum time islimited to 8 seconds.

Note: The check also considers timeslot upgrades for mobiles that were initially allocated less timeslots than requested (lack of resources) or downgraded during TBF operation by higher priorized

CS connections.Note: This parameter was moved from the BSC object to the CPCU object in BR8.0.

Creating the PCU objects:

< The PCU functional object represents the packet control unit designed to implement GPRS/EDGE services in the SBS.The creation of a PCU implies the creation of a PPXU card (sameinstance number as the PCU) if NTWCARD = NTWSNAP or NTWSNAP_STLP.

CREATE PCU:

NAME=PCU:pcun, Object path name . Range for pcun = 0..11The supported values for pcun depend on the used HW:- pcun = 0,…,5 HC BSC 72 (PPXX; QTLP)- pcun = 0,…,11 HC BSC 120 (PPXX; STLP)

BCGRTODIFFSERV=0,

object: PCU

range: 0.. 63

default: 0

Backgro und to Different Service , this parameter represents themapping between background class and DSCP coding.

BEPFITODIFFSERV=0,

object: PCU

range: 0.. 63

default: 0

Best effort PFI to Different Service , this parameter represents themapping between predefined PFI best effort parameter and DSCP coding.

CPCUN=0,

object: PCU

range: 0..11

Common PCU number , this parameter represents the CPCU object number to which this PCU belongs.





DIFFSERVSUP=<NULL>,

object: PCU

range: DISABLED (0)

ENABLED (1)

<NULL>

default: see description

Different Service Suppo rt , the default of DIFFSERVSUP dependson the value of GBSNS attribute:

GBSNS (value) FRFIX IPV4

DIFFSERVSUP (default) NULL DISABLED

GBSNS=FRFIX,

object: PCU

range: FRFIX, FRVAR, PV4

default: FRFIX

Gb subnetwork serv ice , this parameter indicates the sub network service used for CPU.

INTRTRFH2TODIFFSERV=0,

object: PCU

range: 0.. 63

default: 0

Interact ive traff ic handl ing pr ior i ty 2 to Different Service , this parameter represents the mapping between interactive class withtraffic handling 2 and DSCP coding.


object: PCU

range: 0.. 63

default: 0



object: PCU

range: 0.. 63

default: 0


MTU=<NULL>,

object: PCU

range: 68 .. 1500

<NULL>


Maximum transmiss ion un i t , this parameter indicates the maximumtransmission unit, i.e. the size of the largest packet that can betransmitted on the Ethernet. The default value of this parameter depends on the value of GBSNSattribute:


MTU (default) NULL 1500

N3101 Moved to CPCU object in BR8.0



NBVCBR Moved to CPCU object in BR8.0

NBVCRR Moved to CPCU object in BR8.0

NBVCUR Moved to CPCU object in BR8.0





NMO=NMO_2,

object: PCU

range: NMO_1, NMO_2, NMO_3

default: NMO_2

Network mo de of operat ion , this parameter determines which typesof channels the MS has to monitor for paging messages.

In Network Mode of Operation I (NMO_1) the network sends circuit-switched pagings for GPRS attached mobiles either on the samechannel that is used for GPRS paging (i.e. CCCH or, if configured,PCCCH) or on a GPRS traffic channel. Therefore the MS only needsto monitor one this one and only paging channel and it receives

circuit-switched pagings even if it is in packet transfer mode (PDCH allocated). CS pagings for GPRS attached mobiles are routed via theSGSN and arrive on the Gb interface together with the packet

pagings. The Gs-interface must exist to allow paging coordinationbetween MSN and SGSN.

In Network Mode of Operation II (NMO_2) the network sends bothcircuit-switched as well as packet-switched pagings on the CCCH

paging channel. The MS therefore only needs to monitor this paging channel. As a consequence, circuit-switched pagings are ignored by the MS while it is in packet transfer mode. A PBCCH must not becreated in the cell when NMO_2 is used!

In Network Mod e of Operation III (NMO_3) the network sendscircuit-switched pagings on the CCCH paging channel and packet-switched pagings either on the CCCH paging channel or on thePCCCH paging channel (if a PBCCH is created in the cell).Therefore an MS that wants to receive pagings for both circuit-switched and packet-switched services shall monitor both paging channels if the packet paging channel is allocated in the cell.Similar to NMO_2 the mobiles are not CS reachable while they are in

packet transfer mode.

In NMO II and NMO III the circuit switched paging is sent from theMSC via SS7 link to the BSC and GPRS paging is sent from SGSN via Gb-interface to the BSC.

The following table summarizes the described modes:

Note: For proper operation the 'Network Mode of Operation' should be the same in each cell of a routing area. The NMO value isbroadcast in the system infos on the BCCH/PBCCH.

NNSVCBLKR Moved to CPCU object in BR8.0

NNSVCRR Moved to CPCU object in BR8.0

NBVCUR Moved to CPCU object in BR8.0 NNSVCTSTR=10,

object: PCU

range: 1.. 30

default: 10

This parameter specifies the Number of cons ecutive retr ies

performed for the NS test procedure (exchange of NS-ALIVE/NS- ALIVE-ACK PDUs) before the NSVC is marked dead and blocked, anO&M alarm is generated and a STATUS indication is sent to the NSuser entity.





NNSVCUBLR=3,

object: PCU

range: 1.. 254

default: 3

This parameter specifies the Maximum numb er of retr ies

performed in the NSVC unblock pr ocedure . If the SGSN does not answer to the unb lock procedure, the procedure is retried for NNSVCUBLR times.

NRLCMAX Moved to CPCU object in BR8.0

NSEI=10,

object: PCU

range: 0..65534

Network Service Element Identi f ier , this parameter represents the

PCU area identification and has end-to-end significance across theGb interface.It uniquely identifies a PCU which is connected to the SGSN (via theGb-interface) with one or more NSVCs (group of NSVCs).

The BSC distributes all cells with packet functionality (PTPPKF)depending on load considerations amongst the available PCUs(NSEIs). Afterwards the system establishes a permanent virtual connection (BVCI) for each of these cells on the respective group of NSVCs.

Note: This attribute can be set only if the object PCU is in 'locked' state.

PFCFCSUP=FALSE,

object: PCUrange: TRUE, FALSE

default: FALSE

Packet f low context f low contro l suppor t , this parameter is used to indicate whether the Enhanced Flow Control is enabled or not.

This value is TRUE if BSC supports the Enhanced Flow Control.

PFCSUP=DISABLED,

object: PCU


default: DISABLED

Packet f low c ontext suppor t , this parameter allows toenable/disable the Packet Flow Context procedure support.

PORT0=<NULL>,

object: PCU

range: string 7..15 chars

default: <NULL>

Port 0 , this parameter indicates the IP address for the PCU. Theconvention used for this value is the dotted decimal format (e.g.“255.255.255.0”).

PORT1=<NULL>,

object: PCUrange: string 7..15 chars

default: <NULL>

Port 1 , this parameter indicates the IP address for the PCU. Theconvention used for this value is the dotted decimal format (e.g.

“255.255.255.0”).

SMSPFITODIFFSERV=0,

object: PCU

range: 0.. 63

default: 0

SMS PFI to Different Serv ice , this parameter represents themapping between predefined PFI SMS parameter and DSCP coding.

SPFITODIFFSERV=0,

object: PCU

range: 0.. 63

default: 0

Signal ing PFI to Different Service , this parameter represents themapping between predefined PFI signalling parameter and DSCP coding.

SNSADDRET=<NULL>,

object: PCUrange: 0.. 16

<NULL>


Subnetwork servive address retr ies , the default value of this parameter depends on the value of GBSNS attribute:


SNSADDRET (default) NULL 3

SNSCHWEIRET=<NULL>,

object: PCU

range: 0.. 16

<NULL>


Subnetwork Service change weight retr ies , the default of this parameter depends on the value of GBSNS attribute:


SNSCHWEIRET (default) NULL 3





SNSCONFRET=<NULL>,

object: PCU

range: 0.. 16

<NULL>


Subnetwork Service config urat ion retr ies , the default of this parameter depends on the value of GBSNS attribute:


SNSCONFRET (default) NULL 3

SNSDELRET=<NULL>,

object: PCU

range: 0.. 16

<NULL>


Subnetwork Service delete retr ies , the default of this parameter

depends on the value of GBSNS attribute:GBSNS (value) FRFIX IPV4

SNSDELRET (default) NULL 3

SNSSIZERET=<NULL>,

object: PCU

range: 0.. 16

<NULL>


Subnetwork Service size retr ies , the default of this parameter depends on the value of GBSNS attribute:


SNSSIZERET (default) NULL 3

STPIPEP=<NULL>,

object: PCU

format: <ipAddress>-<udpPort>

range: ipAddress: string 7...15 chars

udpPort: 1024 ... 65535

default: <NULL>

Startup remote IP endpoint , this parameter indicates the startupremote IP endpoint.

STREAMSUP=DISABLED,

object: PCU


default: DISABLED

Streaming suppo rt , this parameter allows to enable/disable the real time streaming support.

STREAMTODIFFSERV=0,

object: PCU

range: 0.. 63

default: 0

Stream to Different Service , this parameter represents the mapping between streaming class and DSCP coding.

TSNPRO=<NULL>,

object: PCUrange: 0.. 16

<NULL>


Time Subnetworks procedure , the default of this parameter depends on the value of GBSNS attribute:

GBSNS (value) FRFIX IPV4TSNPRO (default) NULL 10

TYPOFNSVCCONF=<NULL>,

object: PCU

range: 0.. 16

<NULL>


Type of NSVC Configurat ion , this parameter indicates the method of configuration of the NS-VCs for the IP sub network service.

The default of this parameter depends on the value of GBSNSattribute:


TYPOFNSVCCONF (default) NULL STATIC

T1 Moved to CPCU object in BR8.0



T3169 Moved to CPCU object in BR8.0 T3172 Moved to CPCU object in BR8.0





TEMPCH Moved to CPCU object in BR8.0

TEMPPDT Moved to CPCU object in BR8.0

TF1 Moved to CPCU object in BR8.0





THPROXT=500..50..550,

object: PCU

format: thproxt1-thproxt2-thproxt3

unit: thproxt1: 1ms

thproxt2: 1s

thproxt3: 1s

range: thproxt1: 10..999

thproxt2: 1..100thproxt3: 101..1000

default: 500..50..550

Threshold Proximity Timer , this parameter implements 3 thresholdsfor TH-proximity evaluation.Note: These timers were implemented based on older specificationswhich are no more valid now. Therefore they are not used by thesystem.

Caution: These three parameters were repeatedly “abused” for development and system test purposes in order to implement

additional test features – partly also customer relevant features. At the current stage of BR70 no official released functionalities arecontrolled by them, therefore we strongly recommend to set thedefault values unless otherwise officially specified!

THSULBAL Moved to CPCU object in BR8.0

TIMEDTBFREL Moved to CPCU object in BR8.0

TNSVCBLK=3,

object: PCU

unit: 1s

range: 1.. 10

default: 3

This timer defines the Wait ing time for the NSVC block/unbloc k

procedure . After an NS-BLOCK or NS-UNBLOCK PDU has beensent by the PCU, it waits TNSVCBLK seconds for theacknowledgement. If no acknowledge arrives in time, the procedureis repeated (parameters NNSVCBLKR and NNSVCUBLR).

TNSVCPTST=3,

object: PCU

unit: 1s

range: 1.. 10

default: 3

This timer defines the Wait ing time for the NSVC test procedure .

After an NS-ALIVE PDU has been sent by the PCU, it waitsTNSVCPTST seconds for the acknowledgement. If no acknowledgearrives in time, the test procedure is repeated (parameter NNSVCTSTR).

TNSVCR=3,

object: PCU

unit: 1s

range: 1.. 10

default: 3

This timer defines the Wait ing time for the NSVC reset procedur e . After an NS-BLOCK PDU has been sent by the PCU, it waitsTNSVCR seconds for the acknowledgement. If no acknowledgearrives in time, the reset procedure is repeated (parameter NNSVCRR).

TNSVCTST=30,

object: PCU

unit: 1s

range: 1.. 60

default: 30

This timer defines the Periodici ty t imer for th e NSVC test

procedure . As soon as the NS reset procedure is completed, the periodic NS test procedure is performed on the Gb-interface fromboth sides (BSC and SGSN independently). For this purpose an NS-

ALIVE PDU is sent towards the SGSN every TNSVCTST seconds. If no acknowledge arrives in time (TNSCVPTST), the test procedure isrepeated (NNSVCTSTR).

TSULBAL Moved to CPCU object in BR8.0

Creating the PCM links for the Abis interface:

< PCM B is the PCM link on the Ab is interface. >

CREATE PCMB:

NAME=PCMB:0; Object path name , range: 0..117.

BAF=2,

object: PCMB

range: 0..255

default: 0

Bit al ignment frame . The decimal value entered for this parameter determines - converted to binary format - the bits of the PCM30 ‘Service Word’ (or ‘Non-frame alignment signal’ NFAS). The entered decimal value, converted to binary, determines the bit values inselected bits of the NFAS. Although the value range of 0..255 allowsto set all 8 bits only the last 5 bits (bits Sa4..Sa8) can be set by theBAF parameter as the first 3 bits (1..3) are reserved for other PCM link functions (bit 1 is the ‘Si’ bit and used for CRC, bit 2 has a fixed value of ‘1’ and bit 3 is the A-bit for urgent alarms). If CRC is not used, the value of BAF also determines the value of bit 1 (Si bit).





BER=E10_3,

object: PCMB

range: E10_3, E10_4, E10_5

default: E10_3

Bit error rate , defines the bit-error-rate threshold that must beexceeded in order to raise a PCM alarm.

CRC=TRUE,

object: PCMB

range: TRUE, FALSE

default: FALSE

CRC enabled , determines whether the cyclic redundancy check systems CRC4 (for PCM30 lines) respectively CRC6 (for PCM24

links) is enabled.

(L1CTS=31-3),

object: PCMB

range: timeslot: 0..31 (for PCM30)

timeslot: 0..24 (for PCM24)

subslot: 0..3

Layer 1 contro l t imeslot, defines the Abis timeslot to be used for layer 1 supervision of specific Abis line configurations (e.g. ‘31-3’ means: layer 1 supervision in timeslot 31, subslot 3).1) Loop configuration on Abis: in this case the layer 1 control timeslot is used to control the loop direction switch.Principle of loop configuration: All BTSEs in the loop and the BSC

permanently transmit a signal pattern via the layer-1 timeslot whichindicates 'idle' or 'failure'. This pattern is transmitted only in the'forward' direction. The layer-2 setup messages, however, aretransmitted by all BTSEs in the loop (as well as by the BSC) in bothdirections but received only from the currently 'active' direction (LI

port 1 or port 2). For this reason only in the 'active' direction the setupof the higher layers takes place and the traffic and signaling information is received only via the used LI port.

If on the L1CTS the 'idle' pattern disappears or a 'failure' pattern isreceived from the neighbour BTSE in the loop the BTSE immediately changes the 'receive' direction to the other LI port. Moreover, theBTSEs start to transmit 'failure' patterns via the L1CTS. If a link interruption occurs on a PCM-link between the BTSEs normally a fast alignment is sufficient to setup of the higher layers after the directionswitch as the direction switch causes only very short LAPDinterruptions; if a link interruption occurs on the PCM link directly connected to the BSC normally the direction switch is executed without an additional alignment.Note: For loop configurations this parameter is mandatory fromBR4.0 on as the possibility to use the SA7 bit has been removed.

2) Abis connection using 2 PCM links (BTS+)In this case the supervision of the link availability has to be done

either by layer 2 or layer 1 error detection functions. For those PCM links which carry a LAPD link the error detection is ensured by LAPDlayer 2 functions. For all other links the error detection has to beensured by configuration of an layer 1 control timeslot.E.g. in the example configuration below (BTS crossconnect functionis supported from BR5.5 on) the PCMB linksBSC <-> BTSM 1 and BSC <-> BTSM 3have to be supervised by configuration of an appropriate layer 1control timeslot.

BTSE

1

LIport

2

LIport

1

BTSE0

LIport

2

LIport

1

BTSEn

LIport

1

LI

port2

BSC

QTLP

portB

QTLPport A

= transmit direction layer-1 timeslot

= transmit direction traffic & signaling

= receive direction traffic & signaling





LOWBER=0,

object: PCMB

range: E10_3, E10_4, E10_5, E10_6,

E10_7, E10_8, E10_9,

default: E10_3

Low b it error rate .

LREDUNEQ=SIMPLEXA,

object: PCMB

range: SIMPLEXA, SIMPLEXB

DUPLEX

default: SIMPLEXA

L ink redundancy . Every logical LICD port consists of 2 physical

ports A and B. Here LREDUNEQ must be SIMPLEXA/B for STAR and MULTIDROP configuration and DUPLEX for LOOP configuration(where port B is used for the incoming end of the loop chain).

CODE=HDB3,

object: PCMB

range: HDB3, AMI

default: HDB3

Line code , determines the type of signal used on the PCMS. AMI (Alternate Mark Inversion) and HDB3 use 1-signals of alternating polarity (e.g. -1 and +1). HDB3 has additional functions to avoid longer ‘0’ periods by automatic insertion of so-called ‘violation’ bits if a longer ‘0’ period is detected.

NUA=FALSE,

object: PCMB

range: TRUE, FALSE

default: FALSE

‘Not Urgent Alarm’ enabled , determines whether or not ‘not urgent alarms’ can be signaled. 'Not urgent alarms' are signaled using the 4th bit (Sa4 bit) of the NFAS signal (“Service Word” intimeslot 0 of the PCM system).

PCML=0..0,

object: PCMB

range: licd-no. 0..8

port-no. 0..1 (DTLP)

port-no. 0..3 (QTLP)

PCM link : licd-no. - licd-port-no.

REMAL=CCITT,

object: PCMB

range: CCITT

BELLCORE

default: CCITT

Remo te alarm .





WMOD=DOUBLE_TRUNK;

object: PCMB

range: SINGLE_TRUNK,

DOUBLE_TRUNK

default: DOUBLE_TRUNK

Working mode, this attribute indicates whether the PCMB works insingle trunk mode or in double trunk mode. The SINGLE_TRUNK mode was introduced as part of the feature “High Capacity BSC” inBR6.0 and is used to extend the number of PCMBs that can beconnected to the available QTLP ports.The value DOUBLE_TRUNK mode represents the only connectionmodes that were possible in releases up to BR5.5:

a) One PCM link representing one PCMB can be connected to one port of the selected QTLP port only (REDUNEQ=SIMPLEXA or SIMPLEXB), in this case the remaining port remains unused.

b) One PCM link can be connected to port A and another PCM link can be connected to port B of the QTLP port (REDUNEQ=DUPLEX)for an Abis loop configuration (see parameter L1CTS). In this case,both ports A and B represent the same PCMB object!

The value SINGLE_TRUNK is represents a configuration in whichone PCMB can be connected to each QTLP subport (A and B). Inthis case the affected PCMBs can be configured as “star” or “multidrop”.

not used

PCMB 0 A

DOUBLE_TRUNK mode:QTLP

port

BTSE

B

PCMB 0 A

SINGLE_TRUNK mode:QTLP

port

BTSE

BBTSE

PCMB 1

BTSE

PCMB 0 A

DOUBLE_TRUNK mode:QTLP

port

BTSE

BBTSE

PCMB 0

BTSE





Creating the PCMS link:

< PCM S is the PCM link on the As ub interface. >

CREATE PCMS:

NAME=PCMS:0, Object path name . The range for the PCMS-no. is 0..47

BAF=0,

object: PCMS

range: 0..255

default: 0

Bit al ignment frame . The decimal value entered for this parameter determines - converted to binary format - the bits of the PCM30 ‘Service Word’ (or ‘Non-frame alignment signal’ NFAS). Although thevalue range of 0..255 allows to set all 8 bits only the last 5 bits (4..8)can be set by the BAF parameter as the first 3 bits (1..3) are reserved for fixed PCM link functions (CRC, D-bit etc.).

BER=E10_3,

object: PCMS

range: E10_3, E10_4, E10_5

default: E10_3


CODE=HDB3,

object: PCMS

range: HDB3, AMI

default: HDB3

Line code , determines the type of signal used on the PCMS. AMI (Alternate Mark Inversion) and HDB3 use 1-signals of alternating polarity (e.g. -1 and +1). HDB3 has additional functions to avoid

longer ‘0’ periods by automatic insertion of so-called ‘violation’ bits if a longer ‘0’ period is detected.

CRC=TRUE,

object: PCMS

range: TRUE, FALSE

default: FALSE

CRC enabled , determines whether the cyclic redundancy check systems CRC4 (for PCM30 lines) respectively CRC6 (for PCM24links) is enabled.

LREDUNEQ=SIMPLEXA,

object: PCMS

range: SIMPLEXA, SIMPLEXB

DUPLEX

default: SIMPLEXA

L ink redundancy . Every logical LICD port consists of 2 physical ports A and B, port B can be used in addition to port one for aredundant link. Here LREDUNEQ must be SIMPLEXA/B if a non-redundant PCM link is used and DUPLEX if port B is equipped with aredundant PCM link. A redundant PCMS link is an additional physical line which is 'hot standby' to take over the traffic and signaling if thecurrently active one fails.

Note: If the link redundancy is set to DUPLEX both traffic and signaling info is transmitted via both links while it is received only viathe active one. In case of failure of the active link the QTLP (BSC)and BSCI (TRAU) immediately change there receive direction.

LOWBER=0,

object: PCMS

range: E10_3, E10_4, E10_5, E10_6,

E10_7, E10_8, E10_9,

default: E10_3


NUA=FALSE,

object: PCMS

range: TRUE, FALSE

default: FALSE

'Not Urgent Alarm’ enabled , determines whether or not ‘not urgent alarms’ can be signaled. 'Not urgent alarms' are signaled using the 5th bit of the NFAS signal (Service Word in timeslot 0 of thePCM system).

PCML=1-1,

object: PCMS



port-no. 0..3 (QTLP)

PCM link : licd-no. - licd-port-no.





REMAL=CCITT,

object: PCMS

range: CCITT, BELLCORE

default: CCITT

Remo te alarm .

WMOD=DOUBLE_TRUNK;

object: PCMSrange: SINGLE_TRUNK,

DOUBLE_TRUNK

default: DOUBLE_TRUNK

Working mode, this attribute indicates whether the PCMS works insingle trunk mode or in double trunk mode.

The value DOUBLE_TRUNK mode represents the only connectionmode which was possible in releases up to BR5.0: One PCMS (i.e.one TRAU) can be connected to one port of the selected QTLP port only (REDUNEQ=SIMPLEXA or SIMPLEXB) or one PCMS can beconnected redundantly by using both ports (A and B) of the QTLP

port (REDUNEQ=DUPLEX).

The value SINGLE_TRUNK is only allowed if the parameter ASUBENCAP (see SET BSC [BASICS]) is set to TRUE. With thissetting it is possible to connect one PCMS to each physical QTLP

port

redundantlink

PCMS 0 A

B

T

R

A

U

DOUBLE_TRUNK m ode: QTLP

port

PCMS 1

PCMS 0 A

B

T

R

A

U

T

R

A

U

SINGLE_TRUNK mod e: QTLP

port





Creating the TRAU:

CREATE TRAU:

NAME=TRAU:0, Object path name .

ALLCRIT=NOT_COMPATIBLE_WITH_CROSSCONNECT,

object: TRAU

range: NOT_COMPATIBLE_

WITH_CROSSCONNECT,

COMPATIBLE_WITH_

CROSSCONNECT

default: NOT_COMPATIBLE_

WITH_CROSSCONNECT,

Allocation cr i ter ia , this attribute replaces the parameter TRANMTX which was used up to BR4.0 and defines which mapping system isused between the timeslots of the A- and Asub-interface. Since theintroduction of the feature ‘pooling’ (see SET BSC [BASICS],

parameter ENPOOL) the previously rigid mapping of timeslots isreplaced by a semipermanent mapping (i.e. a mapping modifiable by configuration commands) which depends on the types and number of TCH pools created on the A-interface.a) The value NOT_COMPATIBLE_WITH_CROSS_CONNECT valuecan be chosen when no cross-connectors between BSC and TRAU are used (corresponds to the previous ‘TRAU matrix type 1’). For thebasic mapping principle please refer to the diagram on the next page.b) COMPATIBLE_WITH_CROSS_CONNECT value has to bechosen when cross-connectors between BSC and TRAU are used (corresponds to the previous ‘TRAU matrix type 2’). For the basic mapping principle please refer to the diagram on the next page. The

advantage of this mapping system is that all subslots of the PCMStimeslots can be completely filled even if not all 4 PCMA-links areused between TRAU and MSC. This solution is of special interest if the network operator does not rent complete PCM-links for the PCMSbut only single timeslots.

Note: The mapping principle shown in the diagrams only illustrate thebasic mapping pattern which is in effect when no pools are created.If pools are created the whole mapping pattern changes depending on the type and number of TCH pools configured.





Basic TRAU-mapping 1: NOT_COMPATIBLE_WITH_CROSSCONNECT (no pools created)

PCMT-0 31 . . 7 6 5 4 3 2 1 0

PCMT-1 31 . . 7 6 5 4 3 2 1 0 T ts31 ts2 ts1 ts0

R 3 2 1 0 ... 3 2 1 0 3 2 1 0 X

PCMT-2 31 . . 7 6 5 4 3 2 1 0 A PCMS-0

U

PCMT-3 31 30 29 28 27 . . 3 2 1 0

Note:TRAU Matrix typ e 1: If a specific timeslot on PCMT-0 is used for CCS7 and OMAL the corresponding timeslots on all other PCMTsconnected to the same TRAU remain empty. If timeslot N on the PCMS is created as LPDLS then the corresponding timeslot N on all other PCMTs is empty as well. The following example may illustrate a useful solution:

Channel type Used timesloton Asub

Used timeslotson A interface

Not usable timeslotson A interface

CCS7 link PCMS, timeslot 16 PCMT-0, timeslot 16 timeslot 16 on PCMT-1, -2 and -3

OMAL PCMS, timeslot 30 PCMT-0, timeslot 30 timeslot 30 on PCMT-1, -2 and -3

LPDLS PCMS, timeslot 31 none timeslot 31 on PCMT-0, -1, -2 and -3

Basic TRAU-mapping 2: COMPATIBLE_WITH_CROSSCONNECT (no pools created)

PCMT-0 31 . . 7 6 5 4 3 2 1 0

PCMS-0

PCMT-1 31 . . 7 6 5 4 3 2 1 0 T ts 31

R 3 2 1 0 ... 3 2 1 0 3 2 1 x X

PCMT-2 31 . . 7 6 5 4 3 2 1 0 A ts 2 ts 1 ts 0

U

PCMT-3 31 . . 27 26 25 24 . . 2 1 0 subslot 0 remains empty

in timeslots 1, 9, 17 and 25 !

timeslots 28 .. 31are not usable !

Note:

TRAU Matrix typ e 2: If specific timeslots on the PCMS are used for CCS7, OMAL and LPDLS all PCMA-timeslots that are mapped tothe selected PCMS timeslot cannot be used and remain empty. The timeslot number used for CCS7 link and the OMAL on the A-interface corresponds to the one on the PCMS. In addition, the PCMS-subslot mapped to the used PCMT timeslot will remain empty.The following example configuration has the advantage that all ‘non-usable’ A-interface-timeslots are concentrated on one PCMT link

(here: PCMT-3).

Channel type Used timesloton Asub

Used timeslotson A interface

Not usable timeslotson A interface

CCS7 link PCMS, timeslot 25 * PCMT-0, timeslot 25 PCMT-3, timeslots (0),1,2,3

OMAL PCMS, timeslot 30 * PCMT-0, timeslot 30 PCMT-3, timeslots 20,21,22,23

LPDLS PCMS, timeslot 31 none PCMT-3, timeslots 24,25,26,27

* not usable timeslots on PCMS: timeslot 7, subslot 1 (CCS7 link); timeslot 8, subslot 2





AECST=DISABLED,

object: TRAU


default: DISABLED

Acoust ic Echo Contro l act iva t ion sta tus , this parameter determines whether the feature Acoustic Echo Control feature isenabled or not.

ALCST=DISABLED,

object: TRAU

range: DISABLED, EDDLONLY,

EDULONLY, EDULDL

default: DISABLED

Acou stic Level Control activat ion status , this parameter determines whether the feature Acoustic Level Control feature is

enabled and, if yes, whether it is enabled for uplink and downlink or only one direction.

ALCTGTLEV=m19dBM0,

object: TRAU

range: iTU, m23dBM0,

m22dBM0, m21dBM0,

m20dBM0, m19dBM0,

m18dBM0, m17dBM0,

m16dBM0, m15dBM0

default: m19dBM0

Aco ustic Level Control target level , this parameter indicates thetarget speech level for the Automatic Level Control. Target level isapplicable to both directions if both enabled. It is possible to choosebetween ITU-T G.169 compliant mode (value ITU) and SiemensEnhanced solution with customizable settings.

BULKDCONF=DELAY_160_ ms,

object: TRAU

step size:

range: DELAY_0_ms,

DELAY_10_ms,

DELAY_20_ms,

DELAY_30_ms, …

DELAY_740_ms,

DELAY_750_ms,

AUTOMATIC_LINK_DETEC-

TION

default: DELAY_160_ms

Bulk delay configurat ion , this parameter is used for the default configuration of the terrestrial link. The Automatic Link Detection

monitorizes two default windows, terrestrial (160-260 ms) and satellite window (650-750 ms), until one of two links is detected. Themanual configuration is a particular case of automatic link working where the two windows are adjacent and the operator can insert thelower limit of the first window (bulk delay).

ETFO=FALSE,

object: TRAU

range: TRUE, FALSE

default: FALSEReference: GSM 04.53

Enable Tandem Free Operation , this flag allows to enable or disable the TFO mode. TFO is a feature that improves the speechquality of mobile-to-mobile speech calls by avoiding a double

transcoding in both involved TRAUs.Background: Within the SSS, speech signals are transmitted in forma-law (or u-law) coded PCM signals while within the BSS speech istransmitted in form of TRAU frames based on a specific speechcoding algorithms such as Full Rate, Half Rate or Enhanced Full Rate. The main task of the TRAU (for speech calls) is the transcoding of the a-law (or u-law) signal to the GSM speech version (FR,HR,EFR) and vice versa. In case of a mobile-to-mobile call thistranscoding process unnecessarily takes place in both involved TRAUs - at the expense of the speech quality. If TFO is enabled and all preconditions are fulfilled the uplink TRAU frames are no longer decoded to 64kbits/s (a-law) PCM speech samples but aretransmitted in so-called TFO speech frames which are transported onthe A interface between two TRAUs.

Preconditions: TFO operation is used in all mobile to mobile speechcalls where both Mobiles/TRAUs use the same GSM transcoder (i.e.FR, HR or EFR). Moreover, both involved TRAUs must support theTFO feature (TRAC V3 or TRAC V5 required).

Principle: If TFO is enabled, each TFO capable TRAU checkswhether the peer TRAU is capable to support TFO and is using thesame codec. After verifying these conditions, each TRAU can start toinsert speech TFO frames into the call related PCM octet on the Ainterface. If at least one of these conditions stated above is not met,the speech call will be carried on in the traditional way. The TFOsignalling procedures do not depend on the any call set up

procedures, i.e. TFO does not involve the Call Control in the MSC





and in the BSC. No information is forwarded to the BSC in order tomodify the used codec. The TFO signalling exclusively takes place'in-band', i.e. within the used TCH.

TFO Phases:The transcoder unit implements the TFO operation in two phases:1) In the first phase, the 'TFO establ ishment m ode' , the TFOnegotiation messages are transferred in the Least Significant Bit of (a-law) PCM samples. The TFO message bit is transferred by

replacing the LSB in every 16 consecutive PCM samples. This will result in a 0.5 kbit/s signalling. The 0.5 kbits/s are regularly stolen of the64 kbits/s circuit and by this small amount of data the degradation onthe speech quality is inaudible.2) In the second phase, the 'TFO establ ished m ode' , when the FR,HR or EFR transcoder is used TFO speech frames, which are similar to the frames in 08.60, are carried by 16 kbit/s channel mapped ontothe two LSB bits of each PCM sample. For HR channels the TFOspeech frames, which are similar to the frames in 08.61, are carried by 8 kbit/s channel mapped onto the LSB bit of each PCM sample.The TFO speech frames have a fixed length of 160 bits (20msec) for 8 kbits/s traffic channels and 320 bits (20msec) for 16 kbits/s traffic channels.

TFO functions of the transcoder unit:- monitoring TFO negotiation messages and the TFO speech frames- converting the received TFO speech frames into DL TRAU frames- converting the received UL TRAU frames to TFO speech frames- inserting TFO negotiation messages and the TFO speech frames

EXPSWV="02-04-01-02-06-00

_98-07-30",

object: TRAU

Expected SW version , this SW version must be available and loaded in the TRAU. If it is not available the TRAU automatically requests a download of this SW version from the BSC.

INTCTMST=DISABLED,

object: TRAU

range: ENABLED, DISABLEDdefault: DISABLED

Integrated Cel lu lar Telephone Modem status , this parameter determines whether the feature ‘Integrated Cellular TelephoneModem’ is enabled or not.

NOIREDA=DISABLED,

object: TRAU

unit: dB

range: -18... -6 (dB)

default: -12

Noise reduct ion amount , this parameter is only relevant if the parameter NOIREDST (see below) is set to ENABLED. It determinesthe total amount of desired noise reduction (dB).

NOIREDST=DISABLED,

object: TRAU


default: DISABLED

Noise reductio n status , this parameter determines whether thefeature ‘Noise reduction’ is enabled or not.

PCMSN=0,

object: TRAU

range: 0..19

PCMS -no..





SALUNAME=”BSC1TRAU0”,

object: TRAU


(11 characters)

in quotation marks


Sales Uniqu e Name , this attribute defines every Network Element by its unique symbolic name. It can be optionally used for the network element identity verification during the alignment phase in addition tothe TEI (see CREATE LPDLS). In previous releases (up to BR4.5)the (LPDLS-)TEI was the only criteria used for the network element identity verification during the alignment procedure. The new approach using the Sales Unique Name in addition to an individually

configurable TEI allows a much higher flexibility in the allocation of the TRAUs to the BSCs without loss of safety.

TEI=0,

object: TRAU

range: 0...63

Terminal endpoint identi f ier of LPDLS , this attribute defines theTEI of the LPDLS resp. TRAU.In previous releases (up to BR4.5) the TEI had a fixed (i.e. not changeable) correspondence to the relative object number of theLPDLS resp. TRAU and was the only criteria used for the network element identity verification during the alignment procedure.From BR5.0 on the TEI can be explicitly set for every LPDLS by the

parameter TEI. As with this new approach one and the same TEI canbe used more than once within a BSC, another TRAU specific identity can optionally be used to unambiguously identify the TRAU during the alignment procedure: the Sales Unique Name (seecommand CREATE TRAU, parameter SALUNAME).

TSYNC=1000,

object: TRAU

unit: 10ms

range: 10..10000

default: 1000

TSYNC, this timer is used by the TRAU to supervise time-out of TRAU frame handling. The TRAU starts this timer if 3 uplink TRAU frames have not been correctly received from the BTSE and it isreset if a correct frame is received again (It is only used if a BTS-TRAU traffic connection is established). If it expires, the TRAU reports a transcoder failure warning to the BSC and the TRAU issuesthe warning DSP TSYNCEXPIRED.

VQEST=DISABLED,

object: TRAU


default: DISABLED

Voice qual i ty enhancement status , this parameter determineswhether the feature ‘Voice Quality Enhancement’ is enabled or not.

Creating the LPDLS links:

< The LPDLS link is the LAPD channel for O&M Information betweenBSC and TRAU. >

CREATE LPDLS:

NAME=TRAU:0/LPDLS:0, Object path name .

ASUBCH=0..31,

object: LPDLS

range: pcms-no. 0..19

timeslot-no. 1-31 (PCM30)


subslot-no. 0..3

Asub ch annel : pcms-no. - timeslot (- subslot).





LAPDPOOL=0,

object: LPDLS

range: 0..1

default: (LAPD pool is assigned

by the BSC automatically)

LAPD pool , up to BR7.0 this parameter used to define theLAPDPOOL the LPDLM should be assigned to. A “ LAPD Pool “ wasa logical instance which represent ed a group of LAPD channels(LPDLM, LPDLR, LPDLS) that c ould be managed by one PPLD. Since in BR8.0 the PPLD boards are no longer supported also thismeaning of the parameter does no longer exist.

For PPXL, the parameter LAPDPOOL assumes the meaning of

"primary PPXL" (i.e. the module no. of the PPXL where the LAPDmust work if both PPXL are in service).

For further details please refer to the parameter LAPDPOOL in thecommand CREATE LPDLM.

Creating the PCMA link:

< PCM A represents the PCM link on the A interface. >

CREATE PCMA:

NAME=PCMA:0, Object path name . The range for the PCMA-no. is 0..191.

BAF=0,

object: PCMA

range: 0..255

default: 0

Bit al ignment frame . The decimal value entered for this parameter determines - converted to binary format - the bits of the PCM30 ‘Service Word’ (or ‘Non-frame alignment signal’ NFAS). The entered decimal value, converted to binary, determines the bit values inselected bits of the NFAS. Although the value range of 0..255 allowsto set all 8 bits only the last 5 bits (bits Sa4..Sa8) can be set by theBAF parameter as the first 3 bits (1..3) are reserved for other PCM link functions (bit 1 is the ‘Si’ bit and used for CRC, bit 2 has a fixed value of ‘1’ and bit 3 is the A-bit for urgent alarms). If CRC is not used, the value of BAF also determines the value of bit 1 (Si bit).

BER=E10_3,

object: PCMArange: E10_3, E10_4, E10_5

default: E10_3


CODE=HDB3,

object: PCMA

range: HDB3, AMI

default: HDB3

L ine code , determines the type of signal used on the PCMA. AMI (Alternate Mark Inversion) and HDB3 use 1-signals of alternating polarity (e.g. -1 and +1). HDB3 has additional functions to avoid longer ‘0’ periods by automatic insertion of so-called ‘violation’ bits if a longer ‘0’ period is detected.

CRC=TRUE,

object: PCMA

range: TRUE, FALSE

default: FALSE

CRC enabled , determines whether the cyclic redundancy check systems CRC4 (for PCM30) respectively CRC6 (for PCM24) isenabled.

DEFPOOLTYP=

NOT_DEFINED,

object: PCMA

range: NOT_DEFINED

POOL_1..POOL_13,

POOL_15.. POOL_35

POOL_42...POOL_48


New pool types in BR7.0!

Defaul t pool type , this parameter is only relevant if the feature

‘pooling of A-interface TCH resources’ (see parameter EPOOL incommand SET BSC [BASICS]) and defines the default type of pool assigned to every TSLA of the given PCMA. The different values for the pooling type are predefined and represent a certain combinationof different ‘supported coding types’ for speech and data. For thedifferent pooling types defined by GSM please refer to the table onthe following pages.





Table of A-interface pool types

Coding Pool Supported channels and speech coding algorithms

0000 0001 Circuit pool number 1 FR speech version 1FR data (12, 6, 3.6 kbit/s)

0000 0010 Circuit pool number 2 HR speech version 1HR data (6, 3.6 kbit/s)


HR speech version 1HR data (6, 3.6 kbit/s)


0000 0101 Circuit pool number 5 FR speech version 1FR speech version 2FR data (12, 6, 3.6 kbit/s)

0000 0110 Circuit pool number 6 FR speech version 2FR data (12, 6, 3.6 kbit/s)HR speech version 1HR data (6, 3.6 kbit/s)

0000 0111 Circuit pool number 7 FR speech version 1FR speech version 2FR data (12, 6, 3.6 kbit/s)HR speech version 1HR data (6, 3.6 kbit/s)

0000 1000 Circuit pool number 8 HSCSD max 2 x FR data (12, 6 kbit/s)

0000 1001 Circuit pool number 9 FR data (12, 6, 3.6 kbit/s)HR data (6, 3.6 kbit/s)HSCSD max 2 x FR data (12, 6 kbit/s)

0000 1010 Circuit pool number 10 FR speech version 1FR speech version 2FR data (12, 6, 3.6 kbit/s)HR speech version 1HR data (6, 3.6 kbit/s)HSCSD max 2 x FR data (12, 6 kbit/s)

0000 1011 Circuit pool number 11 HSCSD max 4 x FR data (12, 6 kbit/s)

0000 1100 Circuit pool number 12 FR data (12, 6, 3.6 kbit/s)HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (12, 6 kbit/s)

0000 1101 Circuit pool number 13 FR speech version 1FR speech version 2FR data (12, 6, 3.6 kbit/s)HR speech version 1HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (12, 6 kbit/s)

0000 1110 Circuit pool number 14 HSCSD max 6 x FR data (12, 6 kbit/s)EDGE max 2 x FR data (32.0 kbit/s)

0000 1111 Circuit pool number 15 FR data (14.5 kbit/s)

0001 0000 Circuit pool number 16 HSCSD max 2 x FR data (14.5 kbit/s)EDGE FR data (29.0 kbit/s)

0001 0001 Circuit pool number 17 HSCSD max 4 x FR data (14.5 kbit/s)EDGE max 2 x FR data (29.0 kbit/s)EDGE FR data (43.5 kbit/s)

0001 0010 Circuit pool number 18 FR data (14.5, 12, 6, 3.6 kbit/s)HR data (6, 3.6 kbit/s)HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)EDGE FR data (29.0 kbit/s)

0001 0011 Circuit pool number 19 FR data (14.5, 12, 6, 3.6 kbit/s)HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)EDGE max 2 x FR data (29.0 kbit/s)

EDGE FR data (43.5 kbit/s)0001 0100 Circuit pool number 20 FR speech version 1

FR speech version 2FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR data (6, 3.6 kbit/s)






0001 0101 Circuit pool number 21 FR speech version 1FR speech version 2FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR data (6, 3.6 kbit/s)HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)EDGE FR data (29.0 kbit/s)

0001 0110 Circuit pool number 22 FR speech version 1FR speech version 2FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)EDGE max 2 x FR data (29.0 kbit/s)EDGE FR data (43.5 kbit/s)

0001 0111 Circuit pool number 23 FR speech version 3HR speech version 3

0001 1000 Circuit pool number 24 FR speech version 3FR data (12, 6, 3.6 kbit/s)HR speech version 3

0001 1001 Circuit pool number 25 FR speech version 1FR speech version 2FR speech version 3FR data (12, 6, 3.6 kbit/s)HR speech version 3

HR speech version 60001 1010 Circuit pool number 26 FR speech version 1

FR speech version 2FR speech version 3FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 3HR speech version 6

0001 1011 Circuit pool number 27 FR speech version 1FR speech version 2FR speech version 3FR data (12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 6HR data (6, 3.6 kbit/s)

0001 1100 Circuit pool number 28 FR speech version 1FR speech version 2FR speech version 3FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 6HR data (6, 3.6 kbit/s)

0001 1101 Circuit pool number 29 FR speech version 1FR speech version 2FR speech version 3FR data (12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 6HR data (6, 3.6 kbit/s)HSCSD max 2 x FR data (12, 6 kbit/s)

0001 1110 Circuit pool number 30 FR speech version 1FR speech version 2FR speech version 3

FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 6HR data (6, 3.6 kbit/s)HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)EDGE FR data (29.0 kbit/s)






0001 1111 Circuit pool number 31 FR speech version 1FR speech version 2FR speech version 3FR data (12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 6HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (12, 6 kbit/s)

0010 0000 Circuit pool number 32 FR speech version 1FR speech version 2FR speech version 3FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 6HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)EDGE max 2 x FR data (29.0 kbit/s)EDGE FR data (43.5 kbit/s)

0010 0001 Circuit pool number 33 FR data (14.5, 12, 6, 3.6 kbit/s)HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)EDGE max 2 x FR data (29.0 kbit/s)EDGE FR data (43.5 kbit/s)EDGE max 2 x FR data (32.0 kbit/s)

0010 0010 Circuit pool number 34 FR speech version 1FR speech version 2FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)EDGE max 2 x FR data (29.0 kbit/s)EDGE FR data (43.5 kbit/s)EDGE max 2 x FR data (32.0 kbit/s)

0010 0011 Circuit pool number 35 FR speech version 1FR speech version 2FR speech version 3FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 6HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)

EDGE max 2 x FR data (29.0 kbit/s)EDGE FR data (43.5 kbit/s)EDGE max 2 x FR data (32.0 kbit/s)

0010 0100 Circuit pool number 36 FR speech version 4FR speech version 5HR speech version 4

0010 0101 Circuit pool number 37 FR speech version 3FR speech version 4FR speech version 5HR speech version 3HR speech version 4HR speech version 6

0010 0110 Circuit pool number 38 FR speech version 1FR speech version 2FR speech version 3FR speech version 4FR speech version 5FR data (14.5, 12, 6, 3.6 kbit/s)

HR speech version 3HR speech version 4HR speech version 6






0010 0111 Circuit pool number 39 FR speech version 1FR speech version 2FR speech version 3FR speech version 4FR speech version 5FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3

HR speech version 4HR speech version 6HR data (6, 3.6 kbit/s)HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)EDGE FR data (29.0 kbit/s)

0010 1000 Circuit pool number 40 FR speech version 1FR speech version 2FR speech version 3FR speech version 4FR speech version 5FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 4HR speech version 6HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)

EDGE max 2 x FR data (29.0 kbit/s)EDGE FR data (43.5 kbit/s)

0010 1001 Circuit pool number 41 FR speech version 1FR speech version 2FR speech version 3FR speech version 4FR speech version 5FR data (14.5, 12, 6, 3.6 kbit/s)HR speech version 1HR speech version 3HR speech version 4HR speech version 6HR data (6, 3.6 kbit/s)HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)EDGE max 2 x FR data (29.0 kbit/s)EDGE FR data (43.5 kbit/s)EDGE max 2 x FR data (32.0 kbit/s)

0010 1010 Circuit pool number 42 FR speech version 1 + CTM

0010 1011 Circuit pool number 43 FR speech version 2 + CTM0010 1100 Circuit pool number 44 FR speech version 1 + CTM

FR speech version 2 + CTM

0010 1101 Circuit pool number 45 FR speech version 1 + CTMFR speech version 2 + CTMHR speech version 1 + CTM

0010 1110 Circuit pool number 46 FR speech version 3 + CTMHR speech version 3 + CTMHR speech version 6 + CTM

0010 1111 Circuit pool number 47 FR speech version 1 + CTMFR speech version 2 + CTMFR speech version 3 + CTMHR speech version 3 + CTMHR speech version 6 + CTM

0011 0000 Circuit pool number 48 FR speech version 1 + CTMFR speech version 2 + CTMFR speech version 3 + CTM

HR speech version 1 + CTMHR speech version 3 + CTMHR speech version 6 + CTM





HCICN=0,

object: PCMA

range: 0..2047 (if CICFM=GSM)

0..2730

(if CICFM=NOTSTRUCT)

default: pcma-no.

High part of the CIC . The CIC (circuit identification code) is a 16bit-string used to address the PCMA-timeslot used for a traffic connection. The last 5 bits identify the timeslot (0..31), the first 11 bitsare used to identify the PCM-link (0..2047). The HCICN determinesthe value of the first 11 bits.The range of the parameter values depends on the setting of the

parameter CICFM (see SET BSC [BASICS]).

NUA=FALSE,

object: PCMA

range: TRUE, FALSE

default: TRUE


LOWBER=0,

object: PCMA

range: E10_3, E10_4, E10_5, E10_6,

E10_7, E10_8, E10_9,

default: E10_3


PCMT=0..0,

object: PCMA

range: trau-no.: 0..9 pcm-link-no.: 0..3

PCM TRAU , parameter structure:trau-no. - no. of the PCM link between TRAU and MSC

REMAL=CCITT,

object: PCMA

range: CCITT

BELLCORE

default: CCITT

Remote alarm .





Setting the uplink and downlink volumes for specific PCMA timeslots:

SET TSLA:

NAME=pcma:0/tsla:1, Object path name .

POOLTYP=NOT_DEFINED,

object: TSLA

range: NOT_DEFINED

POOL_1..POOL_13,

POOL_15..POOL_35

POOL_42...POOL_48


New pool types in BR7.0!

Pool type , this parameter defines the type of pool assigned to the

TSLA (see also parameters DEFPOOLTYP (SET PCMA) and EPOOL (SET BSC [BASICS])). For the meaning of the different pooling types see the table in the command CREATE PCMA.

THROUGH=31,

object: TSLA

range: 1-31 (PCM30)

1-24 (PCM24)

Timeslot range , offers the possibility to set the attribute values for agroup of timeslots.Note: This parameter is not generated by the DBAEM. It is relevant if the command is entered from a user terminal.

VOLDL=12,

object: TSLA

step size: 1dB

range: 0..24

12 = normal link level

0 = 12dB attenuation

24 = 12dB amplification

default: 12

Volume downl ink , determines the value for the timeslot volume inthe downlink (MSC -> MS) direction.

VOLUL=15;

object: TSLA

step size: 1dB

range: 0..24

12 = normal link level

0 = 12dB attenuation

24 = 12dB amplification

default: 12

Volume upl ink , determines the value for the timeslot volume in theuplink (MS -> MSC) direction. The setting of VOLUL to 15 is used by some network operators because this setting was found the most suitable with respect to the subjective perception of test callers.Moreover, the volume adjustment has also been used to decreaseecho effects which are mainly caused by the feedback within thehousing of bag of the mobile phone.





Creating the PCMG link:

< The PCMG functional object represents the direct physical connection between BSC and SGSN (Gb interface). This line carries32 time slots of 64 kbit/s that can handle 31 Frame Relay Links at themaximum and it can be connected to one circuit of a LICD without any restrictions.Note: the physical connection between BSC and SGSN can berealized by a direct PCM link to the SGSN (PCMG) or via a PCMAlink which is looped to the SGSN via an MSC NUC. A PCMA link canalso be directly connected to an SGSN without passing the MSC – inthis case the bandwidth of the FRLs configured on the PCMA is not limited by the MSC´s capability of bit-synchronous switching. >

CREATE PCMG:

NAME=PCMG:0, Object path name . The range for the PCMG-no. is 0..31.

BAF=0,

object: PCMG

range: 0..255

default: 0

Bit al ignment frame . The decimal value entered for this parameter determines - converted to binary format - the bits of the PCM30 ‘Service Word’ (or ‘Non-frame alignment signal’ NFAS). The entered decimal value, converted to binary, determines the bit values inselected bits of the NFAS. Although the value range of 0..255 allowsto set all 8 bits only the last 5 bits (bits Sa4..Sa8) can be set by the

BAF parameter as the first 3 bits (1..3) are reserved for other PCM link functions (bit 1 is the ‘Si’ bit and used for CRC, bit 2 has a fixed value of ‘1’ and bit 3 is the A-bit for urgent alarms). If CRC is not used, the value of BAF also determines the value of bit 1 (Si bit).

BER=E10_3,

object: PCMG

range: E10_3, E10_4, E10_5

default: E10_3


CRC=TRUE,

object: PCMG

range: TRUE, FALSE

default: FALSE

CRC enabled , determines whether the cyclic redundancy check systems CRC4 (for PCM30) respectively CRC6 (for PCM24) isenabled.

CODE=HDB3,

object: PCMG

range: HDB3, AMI

default: HDB3

Line code , determines the type of signal used on the PCMG. AMI (Alternate Mark Inversion) and HDB3 use 1-signals of alternating polarity (e.g. -1 and +1). HDB3 has additional functions to avoid longer ‘0’ periods by automatic insertion of so-called ‘violation’ bits if a longer ‘0’ period is detected.

LOWBER=0,

object: PCMG

range: E10_3, E10_4, E10_5, E10_6,

E10_7, E10_8, E10_9,

default: E10_3


NUA=FALSE,

object: PCMGrange: TRUE, FALSE

default: FALSE






PCML=0-0-TRUNKA,

object: PCMG



0..3 (QTLP)

trunk TRUNKA, TRUNKB

PCM link : licd-no.- licd-port-no.- trunk

Remarks on the term ‚trunk’:The PCMG links cannot be redundant, because the PCM redundancy is a proprietary feature of the BSS, and so it is used only in theinterfaces Abis and Asub. In the A interface (PCMA) and in the Gbinterface (PCMG) the redundancy is not allowed because this featureneeds that it is handled on both peers, accordingly to specific rules.

There is no standard management of the PCM redundancy in thespecifications of the SGSN and of the MSC.Even though the PCMG cannot be redundant, nevertheless it can beconfigured in double trunk mode, although you cannot see this in theCREATE command. When a PCMG is created, the working mode isinternally and implicitly set, in a way that is transparent to theoperator, according to the value of the ASUBENCAP attribute of theBSC basic package. That is: if the ASUBENCAP is TRUE, thismeans that the single trunk mode is not inhibited, and so it is possibleto set the PCMS lines in single trunk.For the PCMS the working mode must be explicitly set by theoperator, because in some cases it is desired to configure a PCMS indouble trunk mode although it is not redundant, because in this way it will be possible to set the PCMS in duplex in the future, without

deleting/creating the line. For the PCMG instead, for which theredundancy does not exist, it would be useless and wasteful to set aPCMG in double trunk mode: the second trunk would be wasted without reason.

In conclusion: if ASUBENCAP is TRUE, any PCMG shall beautomatically configured in single trunk mode, and the second trunk (A or B) can be used for another PCMS or PCMG line. If

ASUBENCAP is FALSE, the PCMG is automatically set in doubletrunk mode, and the second trunk cannot be used for another line.

REMAL=CCITT;

object: PCMG

range: CCITT

BELLCORE

default: CCITT

Remo te alarm .





Creating the physical link connection on the GPRS Gb interface(Frame Relay Link):

< The FRL functional object represents the 'Frame Relay Link' whichis the physical link connection on the Gb interface. The Frame Relay Link connection can be realized via the A interface (PCMA) or directly to SGSN via a PCMG. In case of A interface connection the 64 kbit/s

time slot are reserved on the PCMS and handled as transparent channel in the TRAU. >

CREATE FRL:

NAME=FRL:0, Object path name , range for FRL: 0..755.

FRSTD=ITU,

object: FRL

range: ITU, ANSI, LMI

default: ITU

Frame Relay Standard , this attribute identifies the standard of theused frame relay protocol. The setting depends on the Frame Relay network used for the Gb connection (if any).

GLK=PCMG:0,

object: FRL

range: PCMA:0 - PCMA:191

PCMG:0 - PCMG:31

GPRS link , this attribute defines the type of line (PCMG or PCMA)and its object instance number used for the Gb-interface connectiontowards the SGSN. Mixed configurations are possible, meaning that a single PCU may be connected to the SGSN via both PCMA and PCMG links at the same time.

GTS=1&2,

object: FRL

range: 1-31

max. 31 values per FRL

linked with '&';

max. 64 timeslots per PCU

if PPXX is used,

GPRS timeslot , this parameter defines the 64 kbit/s time slotsreserved for this specific FRL either on the PCMA or the PCMG asspecified by the parameter GLK. A maximum of 31 timeslots can becreated per FRL (limited by PCMA/PCMG bandwidth), up to 64timeslots can be defined per PCU.

Note: If the FRL object is created via PCMA (see parameter GLK), it has to be considered that the timeslots entered for GTS are alsoreserved for GPRS on the Asub. This again leads to the blocking of the A-interface timeslots that are associated to the selected Asub-channels depending on the used TRAU mapping principle (see

parameter ALLCRIT in command CREATE TRAU). In the worst case,this means that 4 PCMA timeslots can no longer be used for CS

traffic when one timeslot is used for the FRL object on the PCMA! The more timeslots are required for the FRL object the less useful it is to create the FRL via the PCMA!

If Gb-links are routed via PCMA through the MSC (nailed-upconnections), please also ensure that the used MSC supports a bit-synchronized switching of these timeslots. Otherwise Frame Relay links comprising more than 1 timeslots may be corrupted due todifferent delays applied to the single timeslots. The Siemens MSC allows to route only single timeslot FRLs through its switching network!

N391=6,

object: FRL

range: 1-255

default: 6

N391 , this parameter represents the polling cycle. After N expiries of T391 a STATUS-ENQUIRY (STAE) message requesting a Full Status Report is sent to towards the SGSN.

N392=3,

object: FRL

range: 1-255

default: 3

N392 , this parameter represents the error threshold of the polling procedure (based on N391 counter) used to put the FRL in 'disabled' state.





N393=4,

object: FRL

range: 1-255

default: 4

N393 , this attribute represents the error observation window. If thethreshold N392 is reached within N393 * T391 time, the links are put in 'disabled' state. If the threshold is not reached the counters arerestarted.

PCUID=PCU:0,

object: FRL

format: path name of the PCU

range: PCU:0..PCU:11

Parameter name and format changed in

BR7.0 (name changed from PCUN to

PCUID)!

PCU Identifier , this attribute defines the instance number of the PCU object the FRL is connected to.

T391=10,

object: FRL

unit: 1s

range: 1-60

default: 10

T391 , this timer represents the link integrity verification repetition period.

Note: The value of the timer T391 set on the BSC side must be lower than the value of the timer T392 set either on the SGSN or thenetwork side of the Frame Relay link.

TCONG=10,

object: FRL

unit: 1s

range: 1-30

default: 10

Congestion Timer , this parameter specifies the observation window for the congestion detection. If the number of frames coming from

SGSN containing congestion is equal or greater than the number of frames indicating no congestion, the congestion state is notified tothe upper layers.

TCONOFF=20;

object: FRL

unit: 1s

range: 0, 10, 20, 30

0 = no hysteresis time used

default: 20

Congestion off Timer , this attribute specifies the window for congestion abatement. After a congestion notification, no other notifications are foreseen for the time configured in this parameter.This timer is needed to provide a hysteresis time in order to ensurethat the traffic reduction at the mobile station can be effective.

Creating the end-to-end communication between BSS and SGSN: NetworkService Virtual Connection (NSVC):

< The NSVC (Network Service Virtual Connection) functional object represent the end-to-end communication between BSS and SGSN.

At each side of Gb interface, there is one to one correspondencebetween NSVC and NSVL then the NSVL can be seen as anattribute of NSVC. >

CREATE NSVC:

NAME=nsvc:0, Object path name , range for NSVC: 0 – 755.

NSVCI=1110,

object: NSVC

range: 0..65535

Network Service Vir tual Connection Identi f ier , this parameter represents the common identification of the virtual connectionbetween SGSN and BSS.

NSVLI=0..110;

object: NSVC

range: FRLN: 0..755

DLCIN: 16-991

Network Service Vir tual Link Identi f ier , this parameter defines theassociation of the FR-DLCI (Data Link Connection Identifier) and theFRL (Frame Relay Link). It consists of two mandatory fields: FRLN and DLCIN.





Creating the BTS Site Manager:

< The BTS Site Manager represents the functionality that controlsone or more BTSs within one BTSE. It performs all the Operation &Maintenance functions common to all transceivers.>

CREATE BTSM:

NAME=BTSM:0, Object path name , the BTSM-no. corresponds to the BTSE no..

ABISFRACTTHR=30,

object: BTSM

unit: 1 %

range: 0..100

default: 30

BTSM Abis TCH load threshold fo r FR activat ion, this parameter this parameter is only relevant if the parameters EADVCMPDCMHOand EADVCMPHOAMR (for AMR calls) and EADVCMPHOSC (for non-AMR calls) are set to TRUE (for the parameters please see SET HAND [BASICS]). It defines the lower Abis pool TCH load threshold for load-dependent decompression handover. The task of thishandover type is to hand over as many calls that currently occupy aHR (or AMR-HR) TCH to an (E)FR (of AMR FR)TCH as possible to

provide the best possible QoS and speech quality in time periodswith an acceptably low TCH load and Abis pool TCH load.

On every expiry of the timer TRFCT (see SET BSC) the BSC checksthe current radio TCH load in its cells (see parameter FRACTTH1

and FRACTAMRTH1) and the current Abis TCH traffic load of itsBTSMs and compares it to the threshold ABISFRACTTHR. For Decompression handover the BSC calculates the BTSM Abis traffic load as follows

Attention:

- Generally a 16 kbit/s Abis TCH (SUBTSLB) is counted as 2, an 8 kbit/s HR subslot of

the SUBTSLB is counted as 1!

- (*) The “no. of Abis pool TCH not available for CS TCH allocation“ includes- SUBTSLBs in usage state „busy“ **- SUBTSLB in usage state „locked“ or „shutting down“

- (**) A SUBTSLB in usage state „busy“ (i.e. both HR subslots busy) is counted as 2

while a SUBTSLB in usage state „active“ (only one HR subslot busy) is counted as 1.

- The GPRS downgrade strategy (see parameter DGRSTRGY in the commandCREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]).- If the timers TEMPCH/TEMPPDT (see command CREATE PCU) are running for aparticular PDCH, the associated Abis subslots are regarded as ‘idle’ in any case, nomatter which values are set for the parameters DGRSTRGY and DGRSTRGYBCNT,as these subslots are in any case immediately preempted if a CS TCH request meets aTCH congestion situation.

If the Abis pool TCH load of the BTSM drops below the threshold ABISFRACTTHR, the BSC enables deompression handover in theBTSs subordinate to the affected BTSM by sending a SET

ATTRIBUTE message with the appropriate indications to the BTSs.This message triggers the start the load-dependent AMR decompression handover decision process in the BTS.

For further details, please refer to the parameter EADVCMPDCMHO(see command SET HAND [BASICS]).

BTSM Abis traffic load [%] = ∗ 100no. of Abis pool TCH in usage state ‘busy’*

no. of Abis pool TCH in state unlocked/enabled





ABISHRACTTHR=60,

object: BTSM

unit: 1 %

range: 0..100

default: 60

BTSM Abis TCH load threshold for HR activat ion, this parameter is the equivalent of the parameter HRACTT1 (see command CREATE BTS [BASICS]) and defines an Abis traffic load threshold which is used for the following features:

a) BTSM Abis Load Dependent Activation of Half Rateb) Enhanced Pairing of half rate TCHs due to Abis TCH load c) C ompression handover due to Abis TCH load

For all these features, the BSC calculates an Abis TCH traffic load for the Abis pool assigned to the BTSM. This ‘Abis pool’ is represented by all SUTSLB objects that are configured subordinate to the BTSM (for the exact definition of the term ‘Abis pool’ and the characteristicsof the SUBTSLB objects please see command CREATE SUBTSLB).

As the usage of the entered ABISHRACTTHR value depends on thefeature used, the application of this threshold is separately described for each of the involved features:

a) Abis Load Dependent Activation of HR For the feature ‚Abis Load Dependent Activation of HR’ (see

parameter EHRACT), ABISHRACTTHR defines a BTSM Abis traffic load threshold that is evaluated for the forced speech versionselection for incoming TCH seizures. For this, the BSC compares

ABISHRACTTHR to the percentage of busy Abis TCHs (related tothe available Abis TCHs) within the pool of available Abis TCHs for the BTSM. For the feature CLDAHR the BSC calculates the Abistraffic load as follows

Attention:



- * The “no. of Abis pool TCH not available for CS TCH allocation“ includes

- SUBTSLBs in usage state „busy“ **- SUBTSLB in usage state „locked“ or „shutting down“

- ** A SUBTSLB in usage state „busy“ (i.e. both HR subslots busy) is counted as 2


- The GPRS downgrade strategy (see parameter DGRSTRGY in the commandCREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]). a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all Abis subslots whichare currently busy due to GPRS traffic are considered as ‘busy’ like any other Abisresources currently seized by CS calls.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all Abis subslots which are currently busy due toGPRS traffic are considered as ‘idle’.- If the timers TEMPCH/TEMPPDT (see command CREATE PCU) are running for aparticular PDCH, the associated Abis subslots are regarded as ‘idle’ in any case, nomatter which values are set for the parameters DGRSTRGY and DGRSTRGYBCNT,as these subslots are in any case immediately preempted if a CS TCH request meets aTCH congestion situation.

If the calculated Abis TCH traffic load of the BTSM exceeds the percentage defined by ABISHRACTTHR, all incoming calls or incoming handovers to cells of the affected BTSM (for which HR isindicated as supported speech version) are forced to a HR TCH. Thishappens in all BTSs subordinate to the BTSM. If the Abis TCH traffic load of the BTSM is below the percentage defined by

ABISHRACTTHR, all incoming calls are forced to FR or EFR (depending of the capability and preference indicated in the

ASSIGNMENT REQUEST or HANDOVER REQUEST message). For further details please refer to the parameter EHRACT.

Note: if the parameter EHRACTAMR (see command SET BT S [BASICS] ) is set to TRUE, the HR activation also goes for AMR calls.

BTSM Abis traffic load [%] = ∗ 100no. of Abis pool TCH not available for CS allocation *

no. of configured Abis pool TCHs





b) Enhanced Pairing of half rate TCH due to Abis TCH load The feature “Enhanced Pairing of TCH/H” (see parameter EPA incommand SET BSC [BASICS]) transfers HR calls that currently occupy one HR subslot of a DR TCH (while the other subslot is still idle) in such a way that as many HR calls as possible share one Dual Rate TCH with another HR call. The enhanced pairing intracell handover is controlled exclusively by the BSC and is only triggered if either the percentage (within the pool of radio TCHs) of radio DR

TCHs or/and radio FR TCHs in usage state “idle” has dropped below a definable threshold (see parameter HRACTT1) or/and the

percentage (within the pool of Abis TCHs) of Abis DR TCHs or/and FR TCHs in usage state “idle” has dropped below a definablethreshold. For enhanced pairing due to Abis TCH load, this threshold is based on the parameter ABISHRACTTHR: intracell handovers dueto enhanced pairing are triggered if the following BTSM Abis pool traffic load condition is fulfilled:

Attention:

- (*) An Abis TCH (SUBTSLB) is only considered as ‚idle’, if both HR subslots are idle.

- (**) For the ‘number of TCH configured in Abis pool’ each SUBTSLB is counted as ‘1’!

- The GPRS downgrade strategy (see parameter DGRSTRGY in the commandCREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the timers TEMPCH/TEMPPDT (see command CREATE PCU) are running for aparticular PDCH, the associated Abis subslots are regarded as ‘idle’ in any case, nomatter which values are set for the parameters DGRSTRGY and DGRSTRGYBCNT,as these subslots are in any case immediately preempted if a CS TCH request meets aTCH congestion situation.

For further details please refer to the parameter EPA (in command SET BSC).

c) C ompression handover due to Abis TCH load The task of Compression handover is, in case of high TCH load, totransfer AMR-FR or (E)FR calls with suitably good radio link quality toan AMR-HR or HR TCH by an intracell handover in order to prevent

TCH blocking by providing additional TCH resources. Whether AMR calls or/and non AMR calls are considered for this type of handover,depends on the setting of the parameters EADVCMPHOAMR and EADVCMPHOSC (see command SET HAND[BASICS]).

On every expiry of the timer TRFCT (see SET BSC) the BSC checksthe current radio TCH load in its cells (see parameter HRACTAMRT1) and the current Abis TCH traffic load of its BTSMsand compares it to the threshold ABISHRACTTHR. For C ompressionhandover the BSC calculates the BTSM Abis traffic load as follows

Attention:

- Generally a 16 kbit/s Abis TCH (SUBTSLB) is counted as 2, an 8 kbit/s HR subslot of the SUBTSLB is counted as 1!




- The GPRS downgrade strategy (see parameter DGRSTRGY in the commandCREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the timers TEMPCH/TEMPPDT (see command CREATE PCU) are running for aparticular PDCH, the associated Abis subslots are regarded as ‘idle’ in any case, nomatter which values are set for the parameters DGRSTRGY and DGRSTRGYBCNT,

< ∗ 100no. of Abis pool TCH in usage state ‚idle’ *

no. of TCH configured in the Abis pool**100% - ABISHRACTTHR[%]







as these subslots are in any case immediately preempted if a CS TCH request meets aTCH congestion situation.

If the Abis pool TCH load of the BTSM exceeds the threshold ABISHRACTTHR, the BSC enables C ompression handover in theBTSs subordinate to the affected BTSM by sending a SET

ATTRIBUTE message with the appropriate indications to the BTSs.This message starts the C ompression handover decision process inthe BTS.

For further details, please refer to the parameter EADVCMPDCMHO(see command SET HAND [BASICS]).

ABISTRFHITHR=90,

object: BTSM

unit: 1%

range: 50..100

default: 90

Abis Traff ic handover high threshold , this parameter is theequivalent to the paremeters TRFHITH (see SET HAND) and specifies the BTSM Abis traffic load threshold for enabling of traffic handover in the BTSM. For this feature, the BSC calculates a current BTSM Abis TCH traffic load for the Abis TCH pool. This pool isrepresented by all SUTSLB objects that are configured subordinateto the BTSM (see command CREATE SUBTSLB).

The traffic load of a cell is calculated as follows:

Attention:- Generally a 16 kbit/s Abis TCH (SUBTSLB) is counted as 2, an 8 kbit/s HR subslot of






The BSC cyclically checks the BTSM Abis traffic load (controlled by the timer TRFCT, see SET BSC) in all BTSMs and compares it to thethreshold specified by ABISTRFHITHR. If the Abis traffic load in theBTSM is above the BTSM-specific threshold ABISTRFHITHRR, theBSC activates the traffic handover in the those BTSs (subordinate tothe BTSM) for which traffic handover is enabled in the database (see

parameter TRFHOE) by sending an LAPD O&M message SET ATTRIBUTE with the ‘traffic handover enabled’ indication to theBTSM. This O&M message is the trigger for the BTS to start thetraffic handover decision algorithm (for more details concerning thehandover decision please refer to the appendix ‚Handover Thresholds and Algorithms’).If the traffic handover was already enabled for a specific BTS on the

previous expiry of TRFCT (either due to radio TCH load or due to

Abis TCH load) and the radio traffic load in the affected BTS or/and the Abis traffic load of the BTSM are still above their threshold TRFHITH resp. ABISTRFHITHR, no further message is sent to theBTS and the traffic handover remains enabled in the affected BTSs. If the traffic handover was enabled for a specific BTS/BTSM on the

previous expiry of TRFCT and both the radio traffic load in theaffected BTS and Abis traffic load in the affected BTSM havedropped below the corresponding thresholds, the BSC disables thetraffic handover in the affected BTSs by sending another LAPD O&M message SET ATTRIBUTE with the ‘traffic handover disabled’ indication to the BTSM.







ABISTRFLTHR=70,

object: BTSM

unit: 1%

range: 0.. 85

default: 70

Abis Traff ic handover low threshold , this parameter specifies themaximum Abis traffic load a BTSM may have to accept incoming traffic handovers. The traffic load of a cell is calculated as follows:

Attention:







When the BSC has enabled the traffic handover in a specific BTS

(see parameters ABISTRFHITHR and TRFHITH) the BTS makes atraffic handover decision and – if a suitable target cell is found -sends an INTERCELL HANDOVER CONDITION INDICATION (HCI)with cause ‘traffic’ and a list of the determined target cells to the BSC.The BSC only activates a TCH in the target BTS, if the radio traffic load of this target BTS is below the threshold TRFLTH and if the Abistraffic load of the target BTSM is below the threshold ABISTRFLTHR.If the traffic load in the first target cell / target BTSM is above thethreshold, the BSC checks the next target cell in the list and so on. If none of the target cells has a suitable load situation (i.e. if the cell traffic load > TRFLTH and/or Abis TCH load > ABISTRFLTHR ) theHCI does not lead to any successful handover completion - the next handover attempt HCI is then sent after expiry of TRFHOT (see SET HAND), if the handover conditions are still present.

Note: The BSC does not allow an incoming traffic handover towardsa BTS from another BTS within the same BTSM, if the Abis TCH load of that BTSM has exceeded the threshold ABISTRFLTHR. Thismeans that it does not make any difference whether the originating cell of the traffic handover belongs to the same BTSM or not.

BTSM Abis traffic load [%] = ∗ 100no. of Abis TCH in usage state ‘busy’*

no. of Abis TCH in state unlocked/enabled





EINTSITSYN=FALSE,

object: BTSM

range: TRUE, FALSE, <NULL>

default: FALSE

Enable Inter-Si te Synchron izat ion , this parameter determineswhether the feature ‘Inter-Site Synchronization’ (ISS) is enabled or not. The feature ISS is mainly relevant for networks with a tight frequency reuse pattern (e.g. 1/1 or 1/3) and interferencemanagement based on MAIO planning for the (synthesizer) hopping frequencies. For other network types this feature is not really relevant.

Purpose and p rinciple of th e ISS feature

Usually the frequency planning in a GSM network is done in such away that co-channel interference and adjacent channel interferencebetween adjacent or colocated sites is avoided by an intelligent allocation of TRX frequencies and frequency subsets among the cellsto be covered. However, in some networks the frequency spectrumgranted to the operators is so small that the number of availablefrequencies does not allow a suitable frequency distribution,especially if the network must handle considerable traffic capacities.In these networks, the resource planning can therefore not be based on the frequencies only and a different approach must be used.Usually, in such networks, frequency planning is reduced to theBCCH-TRXs only. For the non-BCCH-TRXs the operator may decideto deploy e.g. a 1/1 frequency reuse pattern, which means that thenon-BCCH-TRXs TRXs use the same set of hopping frequencies. Insuch configurations the interference can be minimized by minimization of possible collisions of the hopping channels by anintelligent MAIO distribution (please see also explanations given for the feature DMA Admission Control in command SET BTS [ADM]),especially when the same hopping sequence (see parameter HSN incommand CREATE FHSY and CREATE CFHSY) is used in all cells.However, to achieve a controlled time de-coupling of the resourcesby an intelligent separation of MAIO values among the TRXs (and thus to optimally avoid co-channel interference and adjacent channel interference) the cells within a site and cells belonging to different sites must be, in a first step, time-aligned and synchronized. In asecond step, the hopping patterns of the different TRXs can then bede-coupled by a suitable timing-offset value to each TRX. This is

done with the appropriate database parameters.

The synchronicity within a site (i.e. within a BTSM) is guaranteed inany case, as all cells within a BTSM are controlled by a commonmaster clock. In fact, all cells of the same BTSM have, by default,even the same frame numbers, as all cells of a BTSM start their operation at exactly the same point of time.

BTSM cellA

cellB cellC

BTSM cellA

cellB cellC

CellA

CellB

CellC

TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7 TS0 TS1



Frame n Frame n + 1

CellA

CellB

CellC

TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7 TS0 TS1TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7 TS0 TS1



Frame n Frame n + 1

The synchronicity of cells belonging to different sites, however, canonly be achieved with the feature ‘Inter-Site Synchronization’ (ISS)which was introduced in BR8.0.

The sync hronic i ty of the cel ls is based on GPS (Global

Posi t ioning System) techno logy , i.e. GPS is used as time





reference.

The purpose of ISS is toa) synchronize the cells of different sites and b) to introduce and control a fixed timing-offset (frame number offset and burst number offset) between cells of different sites.

As explained below in section ‘Impact of ISS on neighbour cellsidentification and SACCH peformance’, a common frame numbering within a synchronized area is not desireable as this leads to

simultaneous transmission of SCH and SACCH slots and thusimpacts the BSIC and SACCH decoding.

TS0 TS7

BTSA

TS0 TS7

BTSB

TS0 TS7

BTSC

frame X+4 frame X+5 frame X+6

frame X-1

f rame X+14 frame X+15 frame X+16

frame X frame X+1

TS0 TS7

BTSA

TS0 TS7

BTSB

TS0 TS7

BTSC

frame X+4 frame X+5 frame X+6

frame X-1

f rame X+14 frame X+15 frame X+16

frame X frame X+1

The frame number offset can be administered by parameter FRANOFFS, the burst number offset is administered by parameter

BURNOFFS (both parameters see command SET BTS [BASICS]).In case of a 1/1 reuse pattern for the hopping TCH-TRXs, ISS thusallows the operator to allocate the available MAIOs (the number of which is determined by the number of frequencies used in thefrequency hopping system (Mobile Allocation MA) to cells that areadjacent but do not belong to the same BTSM.

Example: 1/1 reuse configuration

A) Without ISS: Only intra-site interference can be controlled by distributing MAIOs among the cells of the same site..

B) With ISS: Also inter-site interference can be controlled by distributing MAIOs among the cells of different sites..

As interference is always a capacity-limiting factor (considering thefact that usually every operator tries to achieve the highest possible





traffic volume against a defined minimum QoS requirement), ISS canthus be used to extend the network capacity by reducing the inter-siteinterference.

Impact of ISS on Training Sequence Code (TSC) planning

The training sequence code is transmitted in the center or each burst within a TDMA slot (please see also parameter TSC in command CREATE CHAN) and is used as an additional identification pattermin addition to the frequency itself.In synchronized networks, the TSCs may arrive at the MS receiver approximately at the same time.

TDMA slot n

Desired

burst

Interferer

burst

TSCEncrypted Bits EncryptedBits

TSCEncrypted Bits Encrypted Bits

t

TDMA slot n

Desired

burst

Interferer

burst

TSCEncrypted Bits EncryptedBits

TSCEncrypted Bits Encrypted Bits

t Some combinations of TSCs may degrade receiver performance

when the TSC values are not orthogonal (only four TSC pairs areorthogonal (0; 2), (0; 7), (1; 3) and (3; 4)). Thus, to avoid degradationin channel estimation process a proper TSC planning has to be

performed: cells operating on the same frequency should not use thesame TSC, but should use pairs of TSCs that have a vanishing cross-correlation.

Impact of ISS on neighbour c el ls identi f icat ion and SACCH

peformance

Chosing a common frame numbering for cells that belong tosynchronized cluster is not desirable, as this would meana) simultaneous transmission of Synchronization Channel (SCH)slots in all cells (this impacts the BSIC decoding in a negative way and results in a lower performance of BSIC decoding and thusleading to a lower effectiveness of the handover algorithm).

b) simultaneous transmission of SACCH slots in the synchronized area which would increase the impact of interfering signals on theSACCH message decoding in a negative way. Moreover, due to thefact that SACCH messages are always transmitted regardless of thevoice activity, the positive effect of DTX (see parameter DTXDL incommand SET BTS [OPTIONS]) on the SACCH decoding would beundone.

Therefore, the frame numbering of the synchronized cells should be





time de-coupled in a controlled way using the FRANOFFS parameter (see SET BTS [BASICS]): FRANOFFS should thus not be set to ‘0’ (means: no frame offset at all) or multiple values of 51 (length of aTDMA multiframe, similar effect like ‘0’) to really achieve a de-synchronization of SCH and SACCH slots.

Impact of ISS on Interference canc el lat ion features

The features UIC (Uplink Interference Cancellation) and SAIC (Single Antenna Interference Cancellation) provide the best performancewhen the interfering signal does not change its characteristicsthroughout the duration of the ‘desired’ signal’s burst in the serving cell. Thus, these features offer the best possible interferencereduction when ISS is activated.

Interact ion of ISS and Dyn amic MAIO Al loc ation (DMA)

If feature DMA is enabled (see command CREATE CBTS for detailsabout DMA), the ISS parameters must be set in such a way that all cells (BTSs) within the site (BTSM) have the same values for framenumber offset (FRANOFFS) and burst number offset (BURNOFFS).

Interact ion of ISS and ‘hando ver between finely syn chron ized

cel ls ’

If the feature ‘handover between finely synchronized cells’ is enabled (see parameter HOSYNC in command SET BSC [BASICS]),handover bwtween BTSs of the same BTSM can be performed without transmission of the PHYSICAL INFO message (which is used for timing advance alignment). In this case BTSs of the same BTSM must have been configured with the same burst number offset (BURNOFFS), the frame number offset may be different.

Notes:- Further the configuration of the GPS synchronization source theobject SYNCBTSE (available only in the BTSE via BTSE-LMT) must be used.- ISS is only supported by BTSEs of generation BTSplus.- Multidrop- and Loop-configurations (see parameter L1TS incommand CREATE BTSM) with mixture of Abis-synchronized BTSEsand GPS synchronized BTSEs is not allowed.

EMT1=10,

object: BTSM

unit: 1min

range: 0..360

default: 10

Emergency timer 1 , this parameter indicates the delay for thetransition to the 'BTSE emergency configuration' in case of breakdown of the BTSE primary power supply if a battery backup isavailable in the BTSE. The timer EMT1 is started when the alarm'ACDC MAINS BREAKDOWN' occurs. If it expires the BTSE entersthe 'BTSE emergency configuration'. 'BTSE emergency configuration' means that only the central BTSE control modules and the HW serving those TRXs which have been explicitly declared a 'Member of emergency configuration' (see parameter MOEC (CREATE TRX))are powered. All other modules are switched off. The purpose of the'BTSE emergency configuration' is to save energy as long as theBTSE is supplied by the battery backup and thus to delay the point of time when the battery runs out of current (BTSE power off).Note: BTSE emergency configuration can also be entered as a result of excessive shelter temperature in BS61 BTSEs (see explanation of

parameter MOEC (CREATE TRX)).





EMT2=0,

object: BTSM

unit: 1min

range: 0..360

0 = switch to 'zero carrier

configuration' disabled.

default: 0

Emergency timer 2 , this parameter indicates the delay for thetransition to 'BTSE zero carrier configuration' in case of breakdown of the BTSE primary power supply if a battery backup is available in theBTSE. The timer EMT2 is started when the BTSE enters the 'BTSE emergency carrier configuration'. If it expires the BTSE enters the'zero carrier configuration'. 'BTSE zero carrier configuration' meansthat only the central BTSE control modules are powered. All other

modules are switched off (call processing disabled). The purpose of the 'BTSE zero carrier configuration' is to keep the central control modules available if microwave-equipment is used. If no microwaveequipment is used the 'zero carrier configuration' should be disabled (EMT2=0).Note: All BTSE types also enter the 'zero carrier configuration' if thealarm 'RACK OVERTEMPERATURE' is raised. This behaviour is not administrable.

EXPSWV="01-01-08-00..07-00_98-7-21",

object: BTSM

Expected SW version , this parameter determines the SW versionwhich should be loaded and running in the BTSE from the BSC's

point of view. This SW load must be available and loaded in theBTSE. If during the alignment between BSC and BTS a different SW version than the expected one is detected, the expected SW load isimmediately activated if it is available on the BTSE flash EPROMs. If

it is not available an automatic download of this SW version from theBSC to the BTSE is initiated.

FLAPDOVLTH=80-70,

object: BTSM

format: firstLevelUpperThreshold -

firstLevelLowerThreshold unit: 1%

range: 10..100

default: firstLevelUpperThreshold: 80

firstLevelLowerThreshold: 70

First LAPD overload threshold , this parameter represents the first load level thresholds of the BTSE Radio Signalling links (LPDLRs). It consists of two fields: The fields of this attribute of type sequenceare:- firstLevelUpperThreshold if the signalling traffic exceeds this threshold the BTSE suspendssending MEASUREMENT RESULT (MEASUREMENT REPORT)messages on the Abis.- firstLevelLowerThreshold if the signalling traffic drops below this threshold the BTSE resumessending MEASUREMENT RESULT (MEASUREMENT REPORT)messages on the Abis.

The MEASUREMENT RESULT resp. MEASUREMENT REPORT messages are neither necessary for call processing nor for

performance measurements. The sending of these messages can beoptionally enabled using the parameter RADIOMR (see command CREATE/SET TRX) for test or monitoring purposes. If thesemessages are sent, they lead to a drastic increase of the uplink load on the LPDLR links. For this reason they are suspended in case of LAPD overload.

Note:- If IMSI Tracing (see command CREATE TRACE) or Cell Traffic Recording (CTR, see command CREATE CTRSCHED) is enabled,the BTS also sends MEASUREMENT REPORT messages. Thedifference is that in this case the MEASUREMENT REPORTs are not

embedded in the MEASUREMENT RESULT but in the TRACE MEASUREMENT RESULT messages. The sending of thesemessages is not suspended if the LAPD load exceedsFLAPDOVLTH.- Further parameters related to LAPD overload are SLAPDOVLTH,LAPDOVLT (CREATE BTSM) and DLAPDOVL (see command SET BSC [BASICS]).- The BTSE LAPD Overload thresholds are only used by BTSEs of the generation BTSplus.





GASTRABISTH=10..20..0..10,

object: BTSM

format: thresholdAbisHV -

thresholdAbisVH -

thresholdIdleAbisSU -

thresholdIdleAbisRU unit: 1%

range: 0..100default: thresholdAbisHV: 10

thresholdAbisVH: 20

thresholdIdleAbisSU: 0

thresholdIdleAbisRU: 10

GPRS al location strategy Abis threshold s , this parameter is the Abis equivalent to the parameter GASTRTH (see CREATE PTPPKF)used to control the switch from/to vertical/horizontal allocationstrategy and the stop/restore of PDCH upgrading due to Abisscarcity. It is composed of four fields.

The first field ( thresholdIdleAbisHV ) defines the percentage of idle Abis subslots (related to the available Abis subslots) under which thevertical allocation strategy due to Abis scarcity is activated. If vertical allocation is activated, new TBFs are preferably multiplexed onalready used PDCHs. This implies that the related Abis subslots arealso shared and results in saving Abis resources.

The second field ( thresholdIdleAbisVH ) defines the percentage of idle Abis subslots (related to the available Abis subslots) over whichthe horizontal allocation strategy is activated again (if also thethresholds for the radio resources allow that – see GASTRTH inobject PTPPKF).

The third field ( thresholdIdleAbisSU ) defines the percentage of idle Abis subslots (over the available Abis subslots) under which the PCU stops sending Abis upgrading requests towards the TDPC. When thisthreshold is reached, the first allocation of Abis resources to a TBF is

performed with the same criteria used under normal conditions(looking at the candidate’s initial coding scheme), but further upgrading of Abis resources is forbidden. The main purpose of this

parameter is to avoid oscillating allocation/preemption cycles in caseof Abis shortage, thus increasing the signaling load of the system dueto multiple reconfiguration activities.E.g.: If only very few Abis resources are available (1 or 2 subslots),these are better kept free for incoming CS traffic instead of first upgrading a running TBF and then pre-empting it again to serve theCS call. ThresholdIdleAbisSU=0 means that the upgrade of TBF resources is stopped only after no Abis resources were left at all –the resumption of upgrades is then triggered with the below

parameter.

The fourth field ( thresholdIdleAbisRU ) defines the percentage of

idle Abis subslots (over the available Abis subslots) over which the Abis upgrade requests towards the TDPC are allowed again.

Constraints on the Abis thresholds are:

thresholdIdleAbisSU <= thresholdIdleAbisRU;

thresholdIdleAbisHV <= thresholdIdleAbisVH.

Note that there is no constraint between the Abis threshold to switchto vertical allocation and the Abis threshold to disable the ‘Abisupgrade requests’; the operator is free to set the one lower than theother, and vice versa.





LAPDOVLT=10,

object: BTSM

unit: 1s

range: 1..60

default: 10

LAPD overload timer , this parameter defines the time to passbetween two consecutive LAPD OVERLOAD indication messages.These messages are sent on the LAPD O&M link (LPDLM) when theLAPD load threshold defined by the parameter SLAPDOVLTH (seebelow) is exceeded and indicate the LAPD overload per TRX.

The BTSE LAPD Overload handling and reporting based on thethresholds FLAPDOVLTH and SLAPDOVLTH are only used by

BTSEs of the generation BTSplus.

Please see also parameter DLAPDOVLH in command SET BSC [BASICS]).

LPDLMSAT=FALSE,

object: BTSM

range: TRUE, FALSE

default: FALSE

LPDLM via s atel li te , this attribute indicates whether the Abis resp.LPDLM is realized via satellite link (TRUE) or not (FALSE).If the Abis interface link is configured as satellite link, the generally higher signal delay must be particularly taken into account by the LAPD layer 2 functions of the BTS O&M link (LPDLM) and theBTS radio signalling links (LPDLR).Setting LPDLMSAT=TRUE has the following effects:The LAPD timers T200 and T201 (waiting timers for LAPDacknowledgement frames) as well as the associated window sizes(the 'window size' is simply the number of I-frames that may be sent

without any acknowledgement from the opposite side) areautomatically extended according to the following table:

These settings ensure that the higher signal delay on the link doesnot lead to unnecessary retransmission of LAPD layer 2 frames.Notes:- The satellite mode of the Abis link has to be activated in the BTSE as well. This is done by the parameter ABISLKSAT in the command SET BTSM (at the BTSE LMT). The effect is the same as described above - just for the opposite direction.- Since the implementation of CR2716 in BR7.0 the setting

LPDLMSAT=TRUE has an effect on call processing: To reduce thedelay between the CHANNEL REQUEST and the IMMEDIATE

ASSIGNMENT COMMAND messages, the BSC sends theIMMEDIATE ASSIGNMENT message immediately after sending theCHANNEL ACTIVATION message, without waiting for the CHAN

ACT ACK. Thie means that the BSC saves the time for thecompletion and acknowledgement of the (satellite-link-delayed) Abischannel activation procedure. As this procedure has an expected success rate of 100% (it is only unsuccessful if the BTS itself has aserious problem) it is not mandatory to wait for a positiveacknowledgement before the IMMEDIATE ASSIGNMENT messagecan be sent. This approach drastically reduces the RACH retransmissions due to delayed IMMEDIATE ASSIGNMENT and thusavoids unnecessary load on the SDCCHs.

- If an Abis is realized via satellite link (or has a considerably increased delay due to other transmission equipment) it is strongly recommended to set the parameter NSLOTST (see SET BTS[CCCH]) to ‚14’ to achieve the longest possible RACH retransmissioncycle. This avoids unnecessary retransmissions that lead tounnecessary SDCCH seizures and thus to a decrease of theImmediate Assignment Success Rate (or even SDCCH congestion).- When an Abis interface is configured via satellite, it is urgently recommended to configure multiple SDCCH channels on different TRXs. This is necessary because the Abis LAPD transmit queues inthe BTS are managed per TRX(TEI), i.e. each TRX (TEI) has an owntransmit queue. As the biggest percentage of all signalling activities

4





in a cell are processed via the SDCCHs, it is recommended, to avoid an excessive concentration of the SDCCH signalling within one TRX (and thus one LPAD transmit queue), to distribute multiple SDCCHsover different TRXs within the cell. Otherwise the probability of theBTSE alarm ‘LAPD TRANSMIT QUEUE OVERFLOW’ will considerably increase, although with a more even distribution of thesignalling load over the TEIs this could be avoided.- Also the Asub interface and the A interface (parameter ASUBISAT

in command SET BSC[BASICS]) 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 linkswithin a BSS may cause an overall message and procedure delay that might lead to expiry of procedure supervision timers that arenormally adapted to the propagation delay of terrestrial signalling links or at least to only one satellite link in the path. Although multiplesatellite links are not officially tested and released, the BSC command interpreter and DBAEM do not perform any checks toavoid multiple satellite links - it is up to the operator to follow this rule.

OMLAPDRT=17,

object: BTSM

unit: 1s

range: 3-300default: 30

recommended value: 17

O&M LA PD release timer , this parameter represents a BTSE timer which is started after the detection of a LAPD (i.e. layer 2)interruption on the Abis link. As long as this timer runs, the BTSE maintains the call processing activity (i.e. BCCH active) in the

subordinate cells. When the timer expires the BTSE call processing is blocked and functional related Managed Objects (BTS, TRX,CHAN, HAND, PWRC, ADJC, ADJC3G etc.) are deleted. In this caseno BCCH information is broadcast in the subordinate cells anymoreand this results in a cell reselection of the mobile stations that

previously camped in this cell. After recovery of the LAPD link a ‘full alignment’ is necessary to put the BTSE in service again, as this

procedure recreates and re-establishes the functional object database in the BTSE which were deleted by the expiry of OMLAPDRT before.Summary: On detection of an Abis LAPD link failure the BTSE startsthe timer OMLAPDRT and the BSC starts the timer SHLAPDIT. If theOMLAPDRT expires the BTSE blocks the call processing and deletesall functional objects. On link reestablishment the BTSE forces the

BSC to perform a full Abis alignment if one of the two timers hasexpired. If the Abis link (LAPD connection) is recovered before one of the two timers expires, the BSC performs a ‘Short Abis Alignment’ (also called ‘fast alignment’) after recovery of the Abis link. WhenSHLAPDIT expires, all ongoing calls in then affected cells (including

ASCI group calls VBS and VGCS) are released by the BSC.

Application: The timers SHLAPDIT and OMLAPDRT are relevant for a) LAPD interruption due to PPXL switchb) LAPD interruption to a certain BTSE within a multidrop chain. Hereit has to be considered that the failure of the PCMB object (i.e. PCM link error between BSC and the first BTSE in the chain) always leadsto a full alignment of all BTSEs in the chain after link recovery. If thePCM link error occurs between two BTSEs in the chain a full alignment is avoided if the link comes up before expiry of SHLAPDIT.

Notes:- OMLAPDRT should be greater than SHLAPDIT since a ‘fast alignment’ (SHLAPDIT not yet expired when the layer 2 comes up)only makes sense if call processing has not been blocked (and thefunctional objects have not been deleted in the BTSE) by the expiry of OMLAPDRT before! As, on the other hand, it does not make senseto keep a BTSE with a failed LAPD connection on air even after theexpiry of SHLAPDIT in the BSC (which leads to a full alignment after link recovery anyway) and as it is generally not useful to keep aBTSE with afailed LAPD connection on air for a too long time (and thus to prevent any originating call setup), the recommendation is touse the following setting





SHLAPDIT=15, OMLAPDRT=17.

Exception: In cells where ASCI features (VBS,VGCS) are enabled, it is recommended to set OMLAPDRT to a generally smaller value and,

particularly, to a smaller value than SHLAPDIT to speed up the cell reselection in case of a LAPD link interruption. This is necessary inorder to prevent the ASCI MSs from ‘listening’ to the NotificationChannel NCH (and attempting to ‘join’ the ASCI common channel) inthe cells where the ASCI common channel has already been

released after expiry of SHLAPDIT. In this case, it is recommended to apply the following settings:

SHLAPDIT=12, OMLAPDRT=10.- Please consider that normally, together with the LAPD link interruption, also the speech path (i.e. the used Abis TCH) isinterrupted, so that all ongoing calls will be released by aCONNECTION FAILURE INDICATION with cause ‘remotetranscoder failure’ after expiry of TSYNC or TSYNCDL (seecommand SET BTS [TIMER]).- For both timers some additional delay time for the detection of thelayer 2 failure (up to 10 s) has to be taken into account.

PCMCON0=PCMB_000-PORT_0,

object: BTSM

format: pcmbNumber0 -

portNumber0

value format: pcmbNumber0:

PCMB_nnn

portNumber0:

PORT_m

PCM connection 0 , this attribute indicates the main PCM connectionfor the BTSM, i.e. it indicates to which BTSM port it is connected.Depending on the LPDLM configuration two cases must bedistinguished:a) If only one LPDLM is configured for the BTSM, PCMCON0 indicates which PCMB carries the LPDLM.b) If more than one LPDLM is configured for the BTSM, PCMCON0 indicates which PCMB carries LPDLM:0.

Notes:- Port numbers specified in all PCMCONx (x = 1..4) attributes must be compatible with the BTS hardware version, as shown in the tablebelow:

The values PORT_2, PORT_4 or PORT_6 can be selected only if theobject COSA is installed; with object COBA installed only the valuePORT_0 can be selected. The hardware object PORT_<n>corresponds to the object BPORT:<n>. At the BTSE side, the BPORT object must be previously created by means of the CREATE BPORT command.

- Please see also command CREATE SUBTSLB.

PCMCON1=<NULL>,

object: BTSM

format: pcmbNumber1 - portNumber1


PCMB_nnn

portNumber1:

PORT_m

default: <NULL>

PCM connection 1 , this attribute indicates the first auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected. Depending on the LPDLM configuration two cases

must be distinguished:a) If only one LPDLM is configured for the BTSM, PCMCON1indicates which PCMB does no t carry the LPDLM.b) If more than one LPDLM is configured for the BTSM, PCMCON1indicates which PCMB does no t carry LPDLM:0.

The port numbers must be selected in correspondence with the HW of the BTSE (please refer to the ‘Notes’ in the description of PCMCON0, see above).





PCMCON2=<NULL>,

object: BTSM


portNumber2


PCMB_nnn

portNumber2:

PORT_mdefault: <NULL>

PCM connection 2 , this attribute indicates the second auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected.


PCMCON3=<NULL>,

object: BTSM


portNumber3


PCMB_nnn

portNumber3:

PORT_m

default: <NULL>

PCM connection 3 , this attribute indicates the third auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected.


PCMCON4=<NULL>,

object: BTSM


portNumber4


PCMB_nnn

portNumber4:

PORT_m

default: <NULL>

PCM connection 4 , this attribute indicates the fourth auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected.


PCMCON5=<NULL>,

object: BTSM


portNumber5


PCMB_nnn

portNumber5:

PORT_m

default: <NULL>

PCM connection 5 , this attribute indicates the fifth auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected.


PCMCON6=<NULL>,

object: BTSM


portNumber6


PCMB_nnn

portNumber6:

PORT_m

default: <NULL>

PCM connection 6 , this attribute indicates the sixth auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected.


PCMCON7=<NULL>,

object: BTSM


portNumber7

value format: pcmbNumber7:PCMB_nnn

portNumber7:

PORT_m

default: <NULL>

PCM connection 7 , this attribute indicates the seventh auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM

port it is connected.

The port numbers must be selected in correspondence with the HW

of the BTSE (please refer to the ‘Notes’ in the description of PCMCON0, see above).





SALUNAME=”BSC1BTSE0”,

object: BTSM


(11 characters)

in quotation marks


Sales Uniqu e Name , this attribute defines every Network Element by its unique symbolic name. It can be optionally used for the network element identity verification during the alignment phase in addition tothe TEI (see parameter TEI). In previous releases (up to BR4.5) the(LPDLM-)TEI was the only criteria used for the network element identity verification during the alignment procedure. The new approach using the Sales Unique Name in addition to an individually

configurable TEI allows a much higher flexibility in the allocation of the BTSEs to the BSCs (with minimization of efforts in case of BTSE swap) without loss of safety.

SHLAPDIT=15,

object: BTSM

unit: 1s

range: 3-20

default: 15

Short LAPD interruption timer , this parameter represents a BSC timer which is started after the detection of a LAPD interruption onthe Abis link. As long as this timer runs all active calls are maintained,i.e. kept alive. If the LAPD interruption exceeds the time defined by SHLAPDIT all calls in the affected BTSE are released and a ‘full alignment’ is performed after link recovery. When the LAPD link hasrecovered after expiry of SHLAPDIT, the BSC waits for another 30 seconds before it starts the ’full alignment’. If the LAPD link comes upagain before the timer expires only a ‘fast alignment’ procedure isstarted. ‘Fast alignment’ is a subset of the ‘full alignment’ and comprises only the state alignment and the alarm alignment, but not

the creation of functional objects. Please see also the explanation for OMLAPDRT.

This timer is also used for supervision of RSL. If an RSL fails for longer than this time limit (O&M link survives) only the channels of the affected TRX are released.

SLAPDOVLTH=90-80,

object: BTSM

format: secondLevelUpperThreshold -

secondLevelLowerThreshold unit: 1%

range: 10..100

default: secondLevelUpperThreshold: 90

secondLevelLowerThreshold: 80

Second LAPD overload threshold , this parameter defines thesecond load level thresholds (in percentage) of the BTSE RadioSignalling links (LPDLRs). It consists of two fields:- secondLevelUpperThreshold if the signalling traffic overcomes this threshold the BTSE starts the

periodic sending of LAPD OVERLOAD messages.- secondLevelLowerThreshold if the signalling traffic falls below this threshold the BTSE stops

periodic sending LAPD OVERLOAD messages.

These messages are sent on the LAPD O&M link (LPDLM) when theLAPD load threshold defined by SLAPDOVLTH is exceeded and indicate the LAPD overload per TRX. The time period between twoconsecutive LAPD OVERLOAD indication messages is determined by the parameter LAPDOVLT.

Notes:- Further parameters related to LAPD overload are FLAPDOVLTH,LAPDOVLT (CREATE BTSM) and DLAPOVL (see command SET BSC [BASICS]).- The BTSE LAPD Overload thresholds are only used by BTSEs of the generation BTSplus.- If the exceeding of SLAPDOVLTH triggers the sending of LAPDOVERLOAD messages towards the BSC and the parameter

DLAPDOVL (SET BSC [BASICS]) is set to TRUE, the BSC startstraffic reduction measures as described in the section ‘BTS overload’ in the chapter ‘BSC, MSC and BTS Overload handling’ in theappendix of this document.





TEI=0,

object: BTSM

range: 0...63

Terminal endpoint identi f ier of LPDLM , this attribute defines theTEI of the LPDLM resp. BTSM. The TEI is the basic criteria used for the network element identity verification during the alignment

procedure. In previous releases (up to BR4.5) the TEI had a fixed (i.e. not changeable) correspondence to the relative object number of the LPDLM resp. BTSM (i.e. BTSM/LPDLM-no.=TEI-no.). Thisapproach had the disadvantage that in case of BTSE swap the TEI

had to be manually changed in the BTSE to the new LPDLM-no. inthe new BSC. As a temporary solution, the parameter FIXTEI wasintroduced which allowed to set all TEIs of the BTSMs to ‘0’. The

parameter FIXTEI was removed in BR5.0 as from BR5.0 on the TEI can be explicitly set for every LPDLM by the parameter TEI. Thus incase of a swap of BTSE from one BSC to another, the TEI can beeasily set in the database of the new BSC by the SET BTSM command without any necessity to modify the BTSE data on site. Aswith this new approach one and the same TEI can be used morethan once within a BSC, another BTSE specific identity can optionally be used to unambiguously identify the BTSE during the alignment:the Sales Unique Name (see parameter SALUNAME).





Creating the Common BTS data of a BTSM for Dynamic MAIO Allocation(DMA):

< With this command the CBTS object is created which defines thedata common for all BTSs of the BTSM which are necessary for theconfiguration of the synthesizer frequency hopping mode with thefeature ‘Dynamic MAIO Allocation’ (DMA). The CBTS object defines

the common pool of TRX/hopping frequencies shared by all BTSsthat belong to the BTSM (for general information about frequency hopping please refer to the parameters HOPP and HOPMODE incommand SET BTS [OPTIONS]).

Purpose and princ iple of the DMA feature

Static MAIO AllocationUp to BR7.0 in the Siemens BSS only ‘Static MAIO Allocation’ (SMA)is was supported for Frequency Hopping. SMA means that thehopping characteristics of a TCH resource that participates in ahopping pattern is fixed defined by

- Mobi le Al location MA (list of frequencies included in the hopping pattern)- Hopping Sequence Numb er HSN (determines, together with thenumber of frequencies in the MA, the hopping algorithm or hopping sequence)- Mobi le Al location Index Offset MAIO (determines the position of that particular TCH within the hopping sequence).

In case of SMA, the MA and HSN may be defined

a) in the FHSY object (see command CREATE FHSY), in this casethe MAIO can be defined (together with the relevant FHSYID) in theCHAN object that represents the TCH (see command CREATE CHAN) or in the TRX object (see command CREATE TRX).

b) in the CFHSY object (see command CREATE CFHSY), in thiscase the MAIO can only be defined (together with the relevant FHSYID) in the TRX object (see command CREATE TRX).

The definition of FHSYID and MAIO in the TRX object was introduced

in BR8.0 as usually all TCHs of the same TRX are defined with thesame FHSY and MAIO combination (which means that the hopping

pattern is the same for all adjacent TCHs on a TRX).

Dynamic MAIO Allocation

DMA is is a feature designed for network configurations withSynthesizer Frequency Hopping and a 1/1 frequency reuse on thenon-BCCH TRXs.

Remarks on 1/1 frequency reuse:Usually the frequency planning in a GSM network is done in such away that co-channel interference and adjacent channel interferencebetween adjacent or colocated sites is avoided by an intelligent allocation of TRX frequencies and frequency subsets among the cellsto be covered. However, in some networks the frequency spectrum

granted to the operators is so small that the number of availablefrequencies does not allow a suitable frequency distribution,especially if the network must handle considerable traffic capacities.In these networks, the resource planning can therefore not be based on the frequencies only and a different approach must be used.Usually, in such networks, frequency planning is reduced to theBCCH-TRXs only. For the non-BCCH-TRXs the operator may decideto deploy e.g. a 1/1 frequency reuse pattern, which means that thenon-BCCH-TRXs TRXs use the same set of hopping frequencies. Insuch configurations the interference is minimized by minimization of

possible collisions of the hopping channels by an intelligent MAIOmanagement (please see also explanations given for the feature





DMA Admission Control in command SET BTS [ADM]).

In such networks, SMA can be applied if an intelligent MAIO planning is ensured: although the same MA frequencies are used in thehopping pattern of the cells (sectors) of the same site, interferencecan be avoided by splitting the set of MAIOs allocated to the site intothree subsets with different MAIOs for each cell (sector).

Precondition: all cells of the site must be frame-number-synchronized, i.e. all cells have the same frame numbering (please

see also parameter EINTSITSYN in command CREATE BTSM).

This configuration, however, only works fine as long as the number of hopping TRXs in the BTSM (site) does not exceed the number of frequencies available in the Mobile Allocation (the MA is the list of hopping frequencies, which is in this case the same for all cells of thesite). As the number of frequencies defined in the MA simultaneously determines the number of available MAIOs, MAIO re-use is anobligatory consequence if the number of hopping TRXs in the BTSM exceeds the number of frequencies in the common MA. MAIO reuse,however, in any case means a continuous intra-site co-channel interference.

As the distribution of traffic among the cells of a BTSM is usually not exactly balanced and may vary temporarily, it is reasonable not tosplit the available pool of MAIOs into fixed subsets (as done in case

of SMA) as this lacks the required flexibility. Instead, it is reasonableto apply DMA, which regards the complete pool of MAIOs defined by the commonly used Mobile Allocation as a common resource on sitelevel and which uses an intelligent and sophisticated algorithm whichassigns, during TCH allocation, those TCHs first whose combinationof timeslot and MAIO has the smallest possible impact on the overall interference. DMA increases the network capacity if the number of TRXs per site (BTSM) exceeds the number of available hopping frequencies and if the traffic is inhomogeneously distributed among the sectors of the site.

The Dynamic MA IO Al location (DMA) algor i thm

The DMA algorithm processes the following input data:

• a list of free time slots of the serving cell

• a list of MAIOs available for DMA• a table with the number of occurrences of dynamic MAIO values

within the site for each timeslot

• table with allocation state of dynamic MAIO values within theserving cell for each timeslot

For each incoming voice call the DMA algorithm:

• selects a channel on the basis of the current MAIO utilizationwithin the site

• operates on the entire timeslot x MAIO domain

• uses and reuses all MAIOs in all sectors of the site

TRX3MAIO = 16

TRX2MAIO = 10

TRX1MAIO = 4

TRX0BCCH

TRX3MAIO = 16

TRX2MAIO = 10

TRX1MAIO = 4

TRX0BCCH

TRX3MAIO = 14

TRX2MAIO = 8

TRX1MAIO = 2

TRX0BCCH

TRX3MAIO = 14

TRX2MAIO = 8

TRX1MAIO = 2

TRX0BCCH

TRX3MAIO = 12

TRX2MAIO = 6

TRX1MAIO = 0

TRX0BCCH

TRX3MAIO = 12

TRX2MAIO = 6

TRX1MAIO = 0

TRX0BCCHRandom Hopping (1, 2, 10, 7, . . . )

Time (TDMA frame)

MA





DMA algorithm channel selection principles:

The DMA channel allocation algorithm

• avoids MAIO repeti t ion in the serving cel l (thus avoiding intra-cell co-channel interference)

• minim izes the num ber of MAIO repeti t ions with in the si te (thus minimizing the number of channels affected by intra-site co-

channel interference)• contro ls the numb er of MAIO adjacencies in the serving cel l

(thus minimizing the number of channels affected by intra-cell adjacent channel interference)

• contro ls the numb er of MAIO adjacencies within the si te (thus minimizing the number of channels affected by intra-siteadjacent channel interference)

DMA feature precond it ions & requirements

• DMA applies to speech calls only (AMR, non-AMR)

• DMA only applies to Synthesizer Frequency Hopping only

• Within the site the same hopping system is used.This comm on frequency hopp ing system consists of - a Cel l Al location (l ist of used frequencies) comm on for al l

cel ls of the BTSM (site), which is defined by the parameter CCALLFxy (see command CREATE CBTS below)- a Mobi le Al location ( l ist of used frequenc ies) and Hop ping

Sequence Number (HSN) comm on for al l cel ls of the BTSM (see parameters CMOBALLOC and HSN in command CREATE CFHSY).

• all cells of the site must be air-interface-synchronized

• service layers not exclisively dedicated to speech services (e.g.service layers for data calls and (E)GPRS) must use Static MAIOallocation (SMA).

In case of DMA, the MA and HSN can only be defined be defined inthe CFHSY object (see command CREATE CFHSY) - the MAIO canonly be defined (together with the relevant FHSYID) in the TRX

object (see command CREATE TRX). The previously knownadministration of hopping parameters in the CHAN object is not possible for those TRXs where DMA is applied.

Interworking o f DMA, SMA and Mult i Layer Service Support

(MSLS) All TRXs belonging to service layers that support other services than‘CS speech only’ cannot use DMA - on these layers SMA has to beused (for further details about MSLS please see command CREATE CBTS).

Basically there are two main possibilities to configure SMA and DMAin parallel within a BTS:a) Separate frequency s ets used fo r DMA and SMA - The DMA layers use a Cell Allocation (list of cell frequencies) asdefined by the CCALL parameter (see command CREATE CBTS) the

and a Mobile Allocation (i.e. list of hopping frequencies) as defined by parameter CMOBALLOC (see command CREATE CFHSY).

Here the CFHSYID and MAIO data must be assigned in the TRX object.

- The SMA layers use a Cell Allocation (list of cell frequencies) asdefined by the CALL parameter (see command CREATE BTS) theand a Mobile Allocation (i.e. list of hopping frequencies) as defined ny

parameter MOBALLOC (see command CREATE FHSY).

Here the FHSYID and MAIO data can be either assigned in the TRX object or in the CHAN objects subordinate to the SMA TRX.

b) Commo n set of frequencies used for DMA and SMA





In this configuration the DMA layers and SMA layers use the sameCell Allocation (list of cell frequencies) as defined by the CCALL

parameter (see command CREATE CBTS) the and a Mobile Allocation (i.e. list of hopping frequencies) as defined by parameter CMOBALLOC (see command CREATE CFHSY).

Here the CFHSYID and MAIO dataof the DMA layer TRXs must be configured in the TRX object - of the SMA layer TRXs can be either configured in the TRX object

or in the CHAN objects subordinate to the SMA TRX.

The MAIO values assigned to the DMA layer TRXs are only in effect when DMA is still disabled (ENDMA=FALSE in BTS and CBTSobject). When DMA is enabled, the number of available MAIOs isautomatically determined by the number of hopping frequencies inthe Mobile Allocation. This pool of MAIOs is then used as a commonresource on BTSM (=site) level and allocated in correspondence withthe described above.Attention : When the SMA TRXs use the same CFHSY like the DMATRXs, the BSC excludes the MAIO values of the SMA TRXsautomatically from the pool of MAIOs that can be used and allocated for calls on the DMA layers.If for both the SMA and DMA TRXs the CFHSYID and MAIO data areassigned in the TRX object, there is no visible difference in the TRX creation data between the SMA from the DMA TRXs. The BSC candistinguish the SMA from the DMA TRXs by their service layer association: all TRX belonging to ‘CS speech only’ service layers areregarded as DMA TRXs, all others are considered for SMA.

DMA Admiss ion Contro l

To avoid the allocation of channels with unacceptable interferencefigures, the feature ‘DMA Admission Control’ is used. For this feature,

please refer to the description provided for the command SET BTS [ADM].

As mentioned above, another feature to be considered in networkswith 1/1 frequency reuse (together with SMA and DMA) is ‘Inter-SiteSynchronization’ (ISS). For further information about this feature,

please refer to parameter EINTSITSYN in command CREATE BTSM.>

CREATE CBTS:

NAME=BTSM:0/CBTS:0, Object path name .

CCALLF01=77,

object: CBTS

range: 0..1023 each field


GSM 05.02

GSM 12.20

Comm on cel l allocation frequency 1 , this parameter defines thefirst non-BCCH radio frequency allocated to all cells of the BTSM for Dynamic MAIO Allocation. Further frequencies used in the cell areset with the remaining parameters CCALLF02..CCALLF63.

Which frequency numbers are allowed, depends on the used frequency band:

SYSID=BB900: 1..124SYSID=F2ONLY900: 0..124, 975..1023SYSID=EXT900: 0..124, 975..1023

SYSID=DCS1800: 512..885 SYSID=GSM850: 128..251SYSID=GSM850PCS: 128..251, 512..885 SYSID=GSM850DCS: 128..251, 512..810 SYSID=GSMR: 955..974SYSID=PCS1900: 512..810

CCALLF02..CCALLF63

object: CBTS

range: 0..1023 each fiel

Comm on cel l al location frequencies 2 to 63 , these parametersdefine all the remaining non-BCCH radio frequencies allocated to all cells of the BTSM for Dynamic MAIO Allocation (see CCALLF01). For each frequency an own parameter is available - to save space, they were summarized here in one table line.





ENDMA=FALSE,

object: CBTS

range: TRUE, FALSE

default: FALSE

Enable Dynamic MAIO Al location , this parameter determineswhether the feature ‘Dynamic MAIO Allocation’ is enabled in theCBTS object.

Notes:- In the DBAEM, this parameter is listed within a SET CBTScommand behind the CREATE CHAN commands. In other words, theenabling of DMA is not possible together with the creation becausefor the DMA enabling both the DBAEM and the BSC command

interpreter check, prior to command execution, whether all associated objects (CFHSY, TRX, CHAN etc.) have beenconsistently and conclusively created in the database before.- To be in effect, DMA must be enabled both in the BTS and theCBTS object. In the DBAEM, DMA is enabled in the BTS object first (see parameter ENDMA in command CREATE BTS).

Creating the hopping laws used for Dynamic MAIO Allocation:

< With this command the hopping systems used for cells in whichDynamic MAIO Allocation is to be applied (CFHSY= CommonFrequency Hopping System). For further details about DMA please

refer to the command CREATE CBTS.

Starting from BR8.0 the definition of frequency hopping systems canbe done in two different ways:a) the frequency hopping system is defined per BTS (per cell) in theFHSY object (see command CREATE FHSY)which is subordinate tothe affected BTS (as done in releases before BR8.0).

b) the frequency hopping system is defined per BTSM (per site) inthe CFHSY object which is subordinate to the CBTS object.

Variant a) can be used for Static MAIO Allocation (SMA) only , whichmeans that the BTS-specifically defined hopping system (FHSY) isallocated to the CHAN object toghether with a fixed MAIO value (seecommand CREATE CHAN for TCH and SDCCH) which determinesthe position of that particular channel in the applied hopping

sequence. Starting from BR8.0, the allocation of a FHSY and MAIOcan alternatively be done in the TRX object (see command CREATE TRX).

Variant b) can be used for

- Static MAIO Allocation (see above), which means that the BTSM-specifically defined hopping system (CFHSY) is allocated to the TRX object toghether with a fixed MAIO value (see command CREATE TRX) which determines the position of the channels subordinate tothe TRX in the applied hopping sequence when Dynamic MAIO

Allocation (DMA) is not used by the service layer assigned to that TRX.- Dynamic MAIO Allocation (see above), which means that theBTSM-specifically defined hopping system (CFHSY) is allocated tothe TRX object toghether with a fixed MAIO value (see command

CREATE TRX) which determines the position of the channelssubordinate to the TRX in the hopping sequence when DMA is not enabled (see parameter ENDMA in commands CREATE CBTS and CREATE BTS [BASICS]). When DMA is enabled, the defined MAIOis no longer relevant as for the channels, MAIOs are dynamically assigned by a special algorithm.

The below listed command CREATE FHSY is thus only relevant for variant (b), i.e. if DMA is to be used. >

CREATE CFHSY:

NAME=BTSM:0/CBTS:0/CFHSY:0,

Object path name .





CMOBALLOC=CCALLF01&CCALLF02&...,

object: CFHSY

range: 0..1023 (each field)


GSM 04.08

Comm on Mobi le al location l ist , this parameter defines is a list of those common cell allocation frequencies (defined in the CBTSobject) which are used in the hopping sequence for the BTSM/CBTS.

HSN=10,

object: CFHSY

range: 0..63


GSM 04.08

Common Hopping sequence number , determines the hopping sequence number commonly used in the site that is configured for DMA.

SUBBAND=10,

object: CFHSY

range: GSM850, PCS1900,

DCS1800, BB900, EB900


GSM 04.08

Subordinate band , this parameter determines the frequency band towhich the CFHSY is applicable.





Creating the LPDLM links:

< The LPDLM link is the LAPD channel assigned to a BTS SiteManager for O&M Information between BSC and BTSE. >

CREATE LPDLM:

NAME=BTSM:0/LPDLM:0, Object path name .

ABISCH=0-1,

object: LPDLM

range: pcmb-no. 0..34



subslot-no. 0..3

Abis c hannel : pcmb-no. - timeslot (- subslot).

The Abis timeslot which is configured as LPDLM ais always used - as LPDLM for O&M signaling between BSC and BTSM and - as LPDLR for the call processing signalling communication (viaRadio Signaling (RSL) messages) between BSC and a particular TRX.

The distinction between LPDLM messages and LPDLR radiosignalling (RSL) messages is based on the LAPD layer 2 addressing scheme which uses the SAPI (Service Access Point Identifier) and TEI (Terminal Endpoint Identifier). LPDLM signalling is alwaysaddressed with SAPI=62, while Abis RSL messages are alwaysaddressed with SAPI=0. For further details, please refer to the

parameters TEI (in command CREATE BTSM) and LPDLMN (incommand CREATE TRX).

Configurat ions w ith mult ip le LPDLM per BTSM It is possible to create more than one LPDLM for a particular BTSM.These LPDLMs work in loadsharing mode, i.e. the messages to besent are distributed over all available LPDLMs. Every LPDLM created for a particular BTSM also carries the LPDLR signalling informationrelated to the TRXs subordinate to the BTSM and the associated BTSs. The loadsharing among the created LPDLMs is based on a‘preference’ which is defined per TRX/LPDLR, i.e. for each TRX the‘preferred’ LPDLM indicates via which LPDLM (and thus via which

physical Abis timelot) the associated LPDLR signalling messagesshall be exchanged (see parameter LPDLMN in command CREATE TRX).

LPDLM l ink select ion management for LPDLR messages in case

of fai lure of one LPDLM

When an LPDLM fails, the BTS performs a re-distribution of theLPDLRs over the LPDLM timeslots which are still available, i.e. theBTS determines which Radio Signalling Link (RSL) or LPDLR,respectively, is switched over which available LPDLM. The re-distribution is done in such a way that the available LPDLRs aredistributed over the available LPDLM links as evenly as possibly, i.e.the number of LPDLRs handled by each LPDLM is more or less thesame.When the failed LPDLM returns to service, the BTS switches thoseLPDLRs, for which the failed LPDLM was the “primary” one, back tothe original (primary) LPDLR/LPDLM allocation. However, to avoid frequent LPDLR switchovers, this happens at the earliest 30 secondsafter the failed LPDLM has returned to service.During the switchover RSL message can be lost. The associated

BTS call processing subsystems (for Radio Link Control and Channel Control) are not informed about the loss of single RSL messages.Moreover, for the switchover process there is no difference in thehandling between LPDLRs associated to a BCCH-TRX or non-BCCH TRX. The BSC just registers the layer 2 connection setup by the BTSE and routes the messages adressed to a particluar TRX to the associated LPDLM timeslot.

After a failure of all LPDLMs the BSC decides which of the configured LPDLMs is used for the Abis Alignment Procedure.

Note: For each LPDLM created in the BSC, the corresponding





counterpart has to be created in the BTSE using the command CREATE LAPDLE.

LAPDPOOL=0;

object: LPDLM

range: 0..1

default: (LAPD pool is assigned

by the BSC automatically)

LAPD pool , this parameter used to define the LAPDPOOL theLPDLM should be assigned to. A “ LAPD Pool “ was a logical instance which represent ed a group of LAPD channels (LPDLM,LPDLR, LPDLS) that c ould be managed by one PPLD. As, starting from BR8.0, the PPLD is no longer supported, the parameter is only relevant for PPXL

Meaning of LAPDPOOL for configurat ion w ith PPXL If PPXL boards are used (high capacity BSC HC-BSC,NTWCARD=NTWSNAP or NTWSNAP_STLP), the parameter LAPDPOOL can only assume the value 0 or 1. In a HC-BSC twoPPXL boards are available, both of them are in service and serve anumber of LAPD channels. If one of the PPXLs fails, the remaining PPXL board immediately takes over the LAPD channels of the failed one. This means that in case of HC-BSC the parameter LAPDPOOLassumes the meaning of "primary PPXL", i.e. the module no. of thePPXL which serves the LAPD channel by default (i.e. when bothPPXL are in service).





Creating the terrestrial Abis timelots for flexible Abis allocation:

< Dynamic/Flexible Abis Al location - Feature backgro und and

reason for introduc tion

The high data rates enabled by the 8-PSK modulation for EDGE respectively EGPRS and the introduction of the additional highcoding schemes (CS3 and CS4, see parameters CSCH3CSH4SUP in command SET BSC and CREATE BTS) for GPRS require theconcatenation of up to 5 Abis TCHs for only one used Um radio TCH.

The following table shows the relationship between the number of 16kbit/s subslots on Abis and the coding schemes:

Coding Scheme Number of 16kbit/s

subslots

CS-1 1

CS-2 2

CS-3 2

CS-4 2

MCS-1 1

MCS-2 2

MCS-3 2

MCS-4 2

MCS-5 2

MCS-6 3

MCS-7 4

MCS-8 5

MCS-9 5

As the table shows, it is required, depending on the coding schemes,to concatenate up to 5 16kbit/s Abis TCHs to one Um radio TCH.Considering this precondition, the fixed allocation of Um radio TCHsto Abis TCHs, which was used up to BR6.0, is no longer sufficient and efficient, as it would require an Abis configuration according tothe highest possible data rates. To avoid a waste of Abis TCH resources, BR7.0 provides a flexible and dynamic allocation of Abis

TCHs, which is applied to both GPRS and CS calls. Incorrespondence with the service type, the BSC dynamically allocatesthe appropriate number of Abis TCHs to a particular call. As thecapacity of each Um radio TCH can vary during runtime, the dynamic

Abis allocation adapts the Abis capacity to the required air interfacecapacity.

New object SUBTSLB Due to the introduction of the feature ‘flexible Abis allocation’ inBR7.0 the fixed association of Um radio TCHs to a particular terrestrial Abis timeslot (and thus the ‘terrestrial channel’ parameter (TERTCH) in the CREATE CHAN command) was removed. Todefine the terrestrial Abis timeslots, a new database object called SUBTSLB (sub-timeslot on Abis) was introduced, which represents a

physical terrestrial 16 kbit/s channel on one of the Abis links towards

a particular BTSM. From BR7.0 on each terrestrial Abis timeslot must be created by an own CREATE SUBTSLB command.

Allocation pr inc iples of Um radio TCHs and Abis radio TCHs With the feature ‘flexible Abis allocation’ respectively ‘dynamic Abisallocation’ the Um radio TCHs of any BTS within the BTSM can bedynamically interconnected to any of the SUBTSLB assigned to theBTSM on a per-call base. For this, the BTS provides a switching matrix functionality which allows an individual throughconnection of

Abis TCH resources towards Um radio TCH resources. The switching functionality, however, is restricted to interconnection or 16kbit/s Abistimeslots and full radio channels (full rate or dual rate), i.e. it is not

possible to interconnect any HR subslot on the Abis to any other HR





sublot on the radio interface. In other words, the two associated HR subslots a particular radio timeslot can only be interconnected to thetwo associated HR subslots of a particular Abis timeslot, i.e. a HR TCH pair on the Um is always connected to a HR TCH pair on the

Abis.

Both the Um radio TCH resources and the Abis TCH resources aremanaged and controlled by the BSC, i.e. the BSC keeps track on theavailability state (enabled, disabled) and usage state (idle, busy or

active) of each Um radio TCH and each Abis TCH, and determinesfor each TCH seizure request (call setup for CS and GPRS, incoming handovers etc.) which Um radio TCHs and Abis TCHs shall beinterconnected by the BTS. The BSC sends the associated resourcedata (i.e. channel type , timeslot number etc.) of the selected radioTCH(s) and Abis TCH(s) to the BTS in the CHANNEL ACTIVATION message which then performs the necessary throughconnection.

The amount of allocated 16 kbit/s Abis resources per radio timeslot depends on several factors, first of all the service type. The next tableshows how, depending on the service type, a single Um radio TCH must be interconnected to Abis TCH resources.

Required

Abis

capacity

1 x 16 kbit/s 1/2 x 16 kbit/s

(= 8 kbit/s)

n x 16 kbit/s

(n = 2..5)Service

type

- FR CS speech

- EFR CS speech

- AMR FR CSspeech

- CS data

- GPRS (CS1 andCS2 only)

- HR CS speech

- AMR HR CSspeech

- EGPRS(MCS1 to MCS9)

- GPRS(CS3 and CS4)

For GPRS and EGPRS several Abis TCHs resources may be used tocarry their (n) concatenated PCU frames. The number (n) of concatenated PCU frames depends on the coding scheme used for radio block transmission.

In case of a GPRS/EGPRS conn ection the BSC c an adjust the

Abis capaci ty accordin g to Link Adaptat ion, and it signals

mod if icat ions with resp ect to the ini t ia l radio / Abis asso ciat ion to the BTS. (which m essage???)

For example, in case one Temporary Block Flow (TBF) applies thecoding scheme MCS7, then 4 Abis resources get assigned. Thus the

Abis capacity is adapted, according to Link Adaptation. If during theTBF lifetime the Link Adaptation algorithm leads to a higher coding scheme, e.g. MCS9, an additional Abis resource is dynamically allocated. In contrast, if the Link Adaptation algorithm leads to a lower coding scheme, e.g. MCS6, superfluous Abis resources are released.In order to avoid continuous sequences of allocation and release, any release and allocation of Abis capacity is not immediately executed,but follows after distinct timeout.

Pool ing Concept of Ab is TCH resources Every 16kbit/s Abis timeslot is an object subordinate to an existing PCMB. The relation of SUBTSLB and PCMB is implicitly defined inthe object instance path name within the NAME attribute of theSUBTSLB object (see below), the relation of the SUBTSLB object tothe BTSM is indirectly defined by the parameter ASSLAPD (seebelow). The relation of a BTSM to the PCMBs is defined by the

parameters PCMCON0..PCMCON3 (see command CREATE BTSM).

All SUBTSLBs which are in this way created for (and thus assigned to) a particular BTSM make up the pool of Abis TCH resources that can be used to serve TCH requests (CS calls, GPRS calls, incoming handovers etc.) that are set up in the BTSs subordinate to the BTSM.In other words, the BTSs of the BTSM share the same Abis TCH





resources pool which is also called ‘Abis pool’.

In more detail, the pooling concept of the feature dynamic Abisallocation distinguishes so-called ‘Abis pools’ and ‘Abis subpools’.

An ‘Abis pool’ consists of one or more ‘Abis subpools’. While an ‘Abis pool’ is defined by its association to a specific BTSM only, an ‘Abissubpool’ is defined by its simultaneous association to- a specific BTSM - a specific PCMB and

- a specfic LPDLM.Each Abis subpool belongs to a single PCM line (PCMB) and isassociated to a specific LPDLM. This relation of Abis TCH resourcesto a specific LPDLM channel (which always also carries the LPDLR signaling) is not call processing oriented, i.e. there is no whichever relation between the LPDLR call processing signalling within theLPDLM channel and the Abis TCHs in the associated Abis subpool.Instead, the purpose of the associated LPDLM (also called ‘control LAPD’) is to guarantee a suitable O&M supervision of the availability of the Abis TCH resources belonging to the Abis subpool. In other words, whenever the ‘control LAPD’ is out of service (e.g. due tofailure of the PCMB link, the BSC considers the associated Abisresources (i.e. the complete Abis subpool) out of service, and theBSC immediately excludes them from the Abis pool and thus from the

dynamic Abis allocation. As soon as the ‘control LAPD’ is in serviceagain the associated Abis subpool is put in service again and theassociated abis TCH resources are available again for dynamic Abisallocation. The failure of PCM lines affects only Abis resources, whileradio channels may continue to be assigned to new incoming calls,as long as there is some available 16kbit/s Abis resource on theremaining PCMB lines. This is possible because the LPDLR radiosignalling for a particluar TRX/radio TCH can be performed via any of the remaing LPDLM timeslots, if the LPDLM which was defined asthe ‘preferred’ LPDLM for a particular TRX has changed its state to‘disabled’ (for further details please refer to the parameter LPDLMN in command CREATE TRX).

Summary:- An ‘Abis pool’ consists of all SUBTSLB objects that are assigned to

the same BTSM. The association of a particular SUBTSLB object to aBTSM is implicitly defined within the path name included in the

parameter ASSLAPD (see below).- An ‘Abis subpool’ consists of all SUBTSLB objects that are assigned to the same BTSM an d the same LPDLM. The association of a

particular SUBTSLB object to a BTSM and the LPDLM is implicitly defined within the path name included in the parameter ASSLAPD(see below). Typically the different Abis subpools that belong to thesame BTSM are created on different PCMB lines to achieve a better availabilty resp. failure safety of the Abis pool.

The following example configuration may illustrate a typical configuration:... (two BTSEs in multidrop, with different Abis subpoolsfor different BTSMs distributed over different PCMBs).





) General hint concerning the SYSTEM INFORMATION messages:

Some of the parameters in the following commands appear as information elements in the

SYSTEM_INFORMATION_TypeX messages. Please note that

SYSTEM_INFORMATION_Type1 to _Type4 are sent on the BCCH if the MS is in idle mode and

SYSTEM INFORMATION Type5 to _Type6 are sent on the SACCH if the MS is in busy mode.

Creating a cell with definition of global parameters:

< With this command all cell specific attributes not related toCommon Control Channels are set. >

CREATE BTS [BASICS]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BTS packages’ were moved below the object BTS and appear in the DBAEM in the CREATE BTS 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=BTSM:0/BTS:0, Object path name . Due to the new object architecture (the BTSobject is a subordinate object of the BTSM) the range for the BTSM-

no. was changed to 0..199 , the BTS-no.was changed to 0..23 .

AMRFRC1= RATE_01,

object: BTS [BASICS]

range: RATE_01, RATE_02,

RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08

default: RATE_01

AMR Ful l Rate Codec 1 , this parameter defines the first AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS)for AMR Full Rate in the BTS.

Adaptiv Mult i rate (AMR)

General background Adaptive Multi Rate (AMR) is a feature that introduces new speechversions in addition to the formerly used speech versions- Full Rate (GSM Full Rate Version 1)- Enhanced Full Rate (GSM Full Rate Version 2) and - Half Rate (GSM Half Rate Version 1).Since BR6.0 also GSM Speech Version 3 is introduced, whichconsists of the speech versions “AMR Full Rate” and “AMR Half

Rate”. The differences between AMR and the older GSM SpeechVersions (FR, EFR, HR) is that in case of AMR the used SpeechCodec is not statically set for each assigned TCH but permanently adapted to the current radio conditions. The basic principle is: thebetter the radio interface quality, the higher the available bandwidth(bitrate) for the speech coding and the smaller the bandwidth (bitrate)for channel coding and vice versa (‘Channel Coding’ is the term that represents the radio transmission error protection overhead, while‘Speech Coding’ represents the coding of the speech signal itself).

Active CODEC Set (ACS)Both the speech versions AMR FR and AMR HR consist of a so-called “Active CODEC Set (ACS)”, which is a set of up to 4 AMR speech CODECs resp. speech coding schemes, which are defined ineach BTS by the parameters AMRFRC1..AMRFRC4 (for AMR FR)and AMRHRC1..AMRHRC4 (for AMR HR). If the ACS for AMR FR shall consist of only 3 AMR CODECs, then AMRFRC4 must be set to<NULL>, if it shall consist of only 2 CODECs, then AMRFRC3 must be set to <NULL> and so on. For AMRFRC1 the value <NULL> is not allowed, as at least one CODEC must be defined within an ACS.

Channel Coding Speech Codinggood radio conditions

Channel Coding Speech Codingpoor radio conditions





For AMRFRC1..AMRFRC4 the following speech coding bit rates canbe set:

RATE_01: 4.75 kbit/s RATE_02: 5.15 kbit/sRATE_03: 5.90 kbit/s RATE_04: 6.70 kbit/s RATE_05: 7.40 kbit/s RATE_06: 7.95 kbit/sRATE_07: 10.2 kbit/s RATE_08: 12.2 kbit/s

For AMRHRC1..AMRHRC4 the following speech coding bit rates canbe set:

RATE_01: 4.75 kbit/s RATE_02: 5.15 kbit/sRATE_03: 5.90 kbit/s RATE_04: 6.70 kbit/sRATE_05: 7.40 kbit/s

(RATE_04 and RATE_05 only for BTSplus)

In any case, the following rule must be followed:

RATE AMRFRC4 > RATE AMRFRC3 > RATE AMRFRC2 > RATE AMRFRC1

AMR link AdaptationWhen an AMR call has been set up, both the BTS and the MScontinuously evaluate the radio interface quality: the MS measuresthe downlink quality in the same way as it does for the regular measurement reporting and the BTS derives quality values from theuplink BER measurements. Depending on the results of these quality measurements, the MS (for the downlink) and the BTS (for the uplink)intiate the selection of a suitable AMR CODEC from the ActiveCODEC Set (ACS). This dynamic change of the AMR CODEC modedepending on the radio interface quality is called “AMR Link

Adaptation” or “AMR CODEC Mode Adaptaion”.The AMR link adaptation downl ink is controlled by the MS and isbased on the C/I (Carrier to Interference) thresholds, which areadministrable by the parameters AMRFRTH12..AMRFRTH34 (for

AMR FR) and AMRHRTH12..AMRHRTH34 (for AMR HR).The BSC sends the AMR parameters that are to be used for a

particular AMR call (i.e. the parameters defining the AMR CODECsused within the ACS and the thresholds and hysteresis values for thedownlink AMR link adaptation)- to the BTS in the CHANNEL ACTIVATION message and - to the MS in the ASSIGNMENT COMMAND message.Of course, the same principle applies in case of inter-cell handover (where the MS receives the AMR parameters in the HANDOVER COMMAND).The AMR link adaptation upl ink is controlled by the BTS and isbased on C/I thresholds that are hardcoded and not administrable(please refer to the section “AMR Link Adaptation Thresholds Uplink” in the Appendix of this document) but which can be influenced by thetuning parameter AMRLKAT (see below).

Link adaptation Signalling The change of the CODEC is signalled in-band by 2 specific bitswithin the Um speech frames (allowing the adressing of 4 CODECsin the ACS). Moreover, as each AMR CODEC has its own TRAU frame format, each change of the AMR CODEC means a change of the type of TRAU frame that is to be used between the BTS and theTRAU. The change of the TRAU frame is also signaled ‘in-band’, i.e.within the AMR TRAU frames exchanged between the BTS and theTRAU.The signalling is based on the following message types:

CODEC MODE REQUEST (CMR) CMRs are exclusively sent from MS to BTS. The prupose of a CMR is to request a CODEC that shall be used for the downlink direction. If DTX is not used, the CMR is continuously sent from the MS to theBTS even if no change of the current CODEC is required. If the CMR request is correctly received by the BTS, the BTS requests thecorresponding downlink CODEC via a CMC from the TRAU.





CODEC MODE COMMAND (CMC) The CMC is sent from the BTS to the TRAU and the MS. Its purposeis to instruct the TRAU and MS to use a specifc CODEC. CMCs for the downl ink direction are sent from BTS to the TRAU within uplink TRAU frames to request the TRAU frame type in correspondencewith the CODEC required by the CMR from the AMR MS. The CMC is sent to the TRAU after an averaging process in the BTS (see

parameter AMRACMRDL in command SET HAND [BASICS]): The

size of the associated ‘averaging window’ for this process is defined in CODEC Mode Requests (CMRs), i.e. the BTS only instructs theTRAU to change the current downlink CODEC mode, if a sufficient number of corresponding CMRs received from the MS haveconfirmed the request to change the CODEC.CMCs for the upl ink direction are sent from BTS to the MS in thedownlink bursts in order to indicate which CODEC the MS shall usefor the uplink speech frames.

CODEC MODE INDICATION (CMI) The CMIs are sent by MS, TRAU and BTS. CMIs are sent within theTRAU frames as well as in the UL and DL speech frames. The

purpose of the CMI is to indicate which type of CODEC is currently used by the sending side, as the same CODEC must be used tocorrectly decode the received speech signal, or TRAU frame,

respectively. The BTS inserts CMIs into downlink bursts according tothe CODEC signaled from the TRAU and into uplink TRAU framesaccording to the CODEC signaled by the MS. The TRAU sets theCMI for the downlink TRAU frames as requested by the CMC fromthe BTS. The MS sets the CMI in the uplink speech frames asrequested by the CMC received from the BTS.

Summary: By the CMR the MS indicates which CODEC it desires, by the CMC the BTS commands which CODEC shall be used by TRAU and MS and by the CMI the MS, TRAU and BTS indicate whichCODEC they currently use to allow a correct decoding on the receiveside.

How is the initial AMR CODEC determined during call setup?

Whether an AMR FR or an AMR HR TCH is to be assigned during

call setup, basically depends on the mobile’s speech version preference, which is indicated in the ASSIGNMENT REQUEST message (and which was normally originally indicated by the MS inthe SETUP message (for MOC) or the CALL CONFIRMED message(for MTC)). Like for all non-AMR calls, the BSC can override the MS

preference due to the feature “Cell Load Dependent Activation of Half Rate” (see parameter EHRACTAMR in command SET BTS[BASICS]) or “Abis Load Dependent Activation of Half Rate” (see

parameter ABISHRACTTHR).When the decision for AMR FR or AMR HR was made, the

parameters AMRFRIC resp. AMRHRIC determine the initial AMR CODEC, i.e. the AMR CODEC that shall be used in the beginning of the call (this information is also included in the ASSIGNMENT COMMAND and CHANNEL ACTIVATION messages). Of course, theinitial CODEC is then immediately adapted by the MS and BTSdepending on the current radio conditions in the scope of the AMR link adaptation.

Interaction of AMR link adaptation and frequency hopping The parameters for the ACS AMRFRC1..AMRFRC4 and

AMRHRC1..AMRHRC4, the initial CODECs AMRFRIC and AMRHRIC as well as the link adaptation thresholds for the downlink AMRFRTH12..AMRFRTH34 and AMRHRTH12..AMRHRTH34 arevalid for all calls with ‘frequency hopping inactive’. Separate

parameters and thresholds are used for calls with ‘frequency hopping active’ . These parameters have exactly the same acronyms like the

parameters listed above, but their acronym is extended by the prefix





‘FH’. This means that, for example, the ‘frequency hopping active’ equivalent to parameter AMRFRC1 has the acronym FHAMRFRC1.The BTS uses these ‘FH’- AMR parameters for the downlink CODEC mode adaptation if frequency hopping is active for the call (for theuplink CODEC mode adaptation there is no difference betweenhopping active or deactivated). In this context it is not only relevant,whether frequency hopping is configured or not, as f requency hopping can be temporarily deactivated in the BTS (e.g. in case of

baseband hopping with TRX failure), even if the database flag for frequency hopping (see parameter HOPP in command) indicates that hopping is enabled. The FHSY parameters for AMR are only considered for a particular AMR call if hopping is currently active for a

particular call.

Handover and Power Control for AMR CallsThe Handover and Power Control Decision for AMR calls is basically the same as for any other speech call. Exception: The Handover decision algorithm as well as the Power Control Decision algorithmuses special C/I thresholds for the Handover or Power Control decision due to quality. For further details, please refer to the

parameters HOLTHQAMRDL (SET HAND [BASICS]) and LOWTQAMRDL (SET PWRC). Moreover, please consider that for

AMR calls special handover and power control thresholds may apply,

if they have been corresponsingly set in the handover and power control service group settings (see parameters SGxxHOPAR incommand SET HAND[BASICS] and SGxxPCPAR in command SET PWRC).

AMR Compression Handover / AMR Decompression Handover As mentioned before, the decision whether an AMR call is set up as AMR FR or AMR HR call is either based on the speech version preference indicated in the ASSIGNMENT REQUEST or on the BSC decision (Cell load dependent activation of HR). Special intracell handovers are implemented for AMR calls, that allow a switchover from an AMR HR TCH to an AMR FR TCH and vice versa based onquality and load criteria.

For further details about AMR compression and AMR decompressionhandover please refer to parameter EADVCMPDCMHO in command

SET HAND [BASICS].

Notes:- To support AMR, the involved TRAU must be equipped with TRAC V5 or TRAC V7. Neither TRAC V1 nor TRAC V3 support AMR.- In the MSC and the BSC, the associated A-interface resourcesmust be created with the appropriate channel pool type (see

parameters DEFPOOLTYP in command CREATE PCMA and POOLTYP in command SET TSLA).- During Inter-BSC handover, the originating BSC informs the target BSC about the currently used CODEC by the field element “MultiRateconfiguration Information”. This field element is included in theInformation Element “Old BSS to new BSS Information” which isincluded in the HANDOVER REQUIRED message and which theMSC transparently passes to the target BSC in the HANDOVER REQUEST message.





AMRFRC2= RATE_03,



RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08,

<NULL>

default: RATE_03

AMR Ful l Rate Codec 2 , this parameter defines the second AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS)for AMR Full Rate in the BTS.


If AMRFRC2 is set to <NULL>, the ACS for AMR FR consists of only one CODEC (defined by AMRFRC1).



Note: An equivalent parameter is available (see below, parameter with the same name but the prefix ‘FH’) which eclipses this one incase of active frequency hopping.

For further details please refer to the descriptions provided for the parameter AMRFRC1.

AMRFRC3= RATE_06,



RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08

<NULL>

default: RATE_06

AMR Ful l Rate Codec 3 , this parameter defines the third AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS)for AMR Full Rate in the BTS.


If AMRFRC3 is set to <NULL>, the ACS for AMR FR only consists of maximally two AMR CODECs (defined by AMRFRC1and AMRFC2).





AMRFRC4= RATE_08,



RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08

<NULL>

default: RATE_08

AMR Ful l Rate Codec 4 , this parameter defines the fourth AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS)for AMR Full Rate in the BTS.


If AMRFRC4 is set to <NULL>, the ACS for AMR FR only consists of maximally three AMR CODECs (defined by AMRFRC1..AMRFC3).



Note: An equivalent parameter is available (see below, parameter

with the same name but the prefix ‘FH’) which eclipses this one incase of active frequency hopping..






AMRFRTH23=12-4,


format: threshold-hysteresis

unit: threshold: 0.5dB

hysteresis: 0.5dB

range: threshold: 0..63 [0..31.5dB]

hysteresis: 0..15 [0..7.5dB]

default: threshold: 12 [6.0 dB]hysteresis: 4 [2.0 dB]

AMR Ful l Rate Thresholds 23 , this parameter defines the C/I threshold and the associated hysteresis for the AMR link adaptationtransition from AMRFRC2 to AMRFRC3 and vice versa.The entered values are applied as follows:

a) The upward transition from AMRFRC2 to AMRFRC3 is initiated when

C/I > threshold AMRFRTH23 + hysteresis AMRFRTH23 b) The downward transition from AMRFRC3 to AMRFRC2 is initiated when

C/I < threshold AMRFRTH23

Thus a) can be regarded as the ‘upper threshold’, while b) can beregarded as the ‘lower threshold’ for downlink AMR link adaptation(please see also the section “AMR Link Adaptation ThresholdsUplink” in the Appendix of this document).

In any case, the following rule must be fulfilled

threshold AMRFRTH12 + hysteresis AMRFRTH12

≤ threshold AMRFRTH23 + hysteresis AMRFRTH23


Notes:

- An equivalent parameter is available (see below, parameter with thesame name but the prefix ‘FH’) which eclipses this one in case of active frequency hopping.- Please be aware that this parameter only refers to the AMR downlink CODEC mode adaptation. The corresponding uplink thresholds are not administrable (see parameter AMRLKAT).

AMRFRTH34=23-4,




hysteresis: 0.5dB



default: threshold: 23 [12.5 dB]

hysteresis: 4 [2.0 dB]

AMR Ful l Rate Thresholds 34 , this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRFRC3 to AMRFRC4and vice versa. The entered values are applied as follows:

a) The upward transition from AMRFRC3 to AMRFRC4 is initiated when

C/I > threshold AMRFRTH34 + hysteresis AMRFRTH34

b) The downward transition from AMRFRC2 to AMRFRC1 is initiated when

C/I < threshold AMRFRTH34



threshold AMRFRTH12 + hysteresis AMRFRTH12



Notes:

- An equivalent parameter is available (see below, parameter with thesame name but the prefix ‘FH’) which eclipses this one in case of active frequency hopping.- Please be aware that this parameter only refers to the AMR downlink CODEC mode adaptation. The corresponding uplink thresholds are not administrable (see parameter AMRLKAT).





AMRHRC1= RATE_01,



RATE_03, RATE_04,

RATE_05

default: RATE_01

AMR Half Rate Codec 1 , this parameter defines the first AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS)for AMR Half Rate in the BTS.


(RATE_04 and RATE_05 only for BTSplus)If the ACS for AMR HR shall consist of only 3 AMR CODECs, then

AMRHRC4 must be set to <NULL>, if it shall consist of only 2 CODECs, then AMRHRC3 must be set to <NULL> and so on. For

AMRHRC1 the value <NULL> is not allowed, as at least one CODEC must be defined within an ACS.


RATE AMRHRC4 > RATE AMRHRC3 > RATE AMRHRC2 > RATE AMRHRC1


For further general details please refer to the descriptions provided for the parameter AMRFRC1.

AMRHRC2= RATE_02,



RATE_03, RATE_04

RATE_05, <NULL>

default: RATE_02

AMR Half Rate Codec 2 , this parameter defines the second AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS)for AMR Half Rate in the BTS.



If AMRHRC2 is set to <NULL>, the ACS for AMR HR only consists of only one CODEC (defined by AMRHRC1).





AMRHRC3= RATE_03,



RATE_03, RATE_04

RATE_05, <NULL>default:

RATE_03

AMR Half Rate Codec 3 , this parameter defines the third AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS)for AMR Half Rate in the BTS.



If AMRHRC3 is set to <NULL>, the ACS for AMR HR only consists of maximally two AMR CODECs (defined by AMRHRC1..AMRHRC2).

In any case, the following rule must be followed:RATE AMRHRC4 > RATE AMRHRC3 > RATE AMRHRC2 > RATE AMRHRC1







AMRHRC4= RATE_04,



RATE_03, RATE_04

RATE_05, <NULL>default:

RATE_04

AMR Half Rate Codec 4 , this parameter defines the fourth AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS)for AMR Half Rate in the BTS.


(RATE_04 and RATE_05 only for BTSplus)If AMRHRC4 is set to <NULL>, the ACS for AMR HR only consists of maximally three AMR CODECs (defined by AMRHRC1..AMRHRC3).





AMRHRIC=

START_MODE_HR,

object: BTS [BASICS]range: START_MODE_HR

CODEC_MODE_01

CODEC_MODE_02

CODEC_MODE_03

CODEC_MODE_04 default: START_MODE_HR

AMR Half Rate Initial Codec , this parameter defines which AMR HR CODEC of the created AMR HR ACS shall be used first after HR TCH assignment. The values CODEC_MODE_0x represent the

created AMR HR CODECs (AMRHRCx) of the ACS.Example: If AMRHRIC=CODEC_MODE_01, then the CODEC defined in AMRHRC1 will be used as initial AMR HR CODEC after

AMR HR TCH assignment.

If the value START_MODE_HR is entered, the initial CODEC isselected as defined by the GSM standard:- If the ACS consists of 1 CODEC, then this CODEC shall be used.- If the ACS consists of 2 or 3 CODECs, then the one with the most robust channel coding (i.e. the one with the lower speech coding bitrate) shall be used.- If the ACS consists of 4 CODECs, then the one with the second most robust channel coding shall be used.

Notes:

- An equivalent parameter is available (see below, parameter with thesame name but the prefix ‘FH’) which eclipses this one in case of active frequency hopping.

AMRHRTH12=19-4,




hysteresis: 0.5dB





AMR Half Rate Thresholds 12 , this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRHRC1 to AMRHRC2 and vice versa. The entered values are applied as follows:

a) The upward transition from AMRHRC1 to AMRHRC2 is initiated when

C/I > threshold AMRHRTH12 + hysteresis AMRHRTH12

b) The downward transition from AMRHRC2 to AMRHRC1 is initiated when

C/I < threshold AMRHRTH12



threshold AMRHRTH12 + hysteresis AMRHRTH12

≤ threshold AMRHRTH23 + hysteresis AMRHRTH23


Notes:- An equivalent parameter is available (see below, parameter with thesame name but the prefix ‘FH’) which eclipses this one in case of





active frequency hopping.- Please be aware that this parameter only refers to the AMR downlink CODEC mode adaptation. The corresponding uplink thresholds are not administrable (see parameter AMRLKAT).

AMRHRTH23=24-4,



unit: threshold: 0.5dBhysteresis: 0.5dB





AMR Half Rate Thresholds 23 , this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRHRC2 to AMRHRC3and vice versa. The entered values are applied as follows:

a) The upward transition from AMRHRC2 to AMRHRC3 is initiated when

C/I > threshold AMRHRTH23 + hysteresis AMRHRTH23

b) The downward transition from AMRHRC3 to AMRHRC2 is initiated when

C/I < threshold AMRHRTH23



threshold AMRHRTH12 + hysteresis AMRHRTH12

> threshold AMRHRTH23 + hysteresis AMRHRTH23


Notes:- An equivalent parameter is available (see below, parameter with the





BSIC=7-7,


range: NCC: 0..7

BCC: 0..7


GSM 03.08

GSM 04.08

GSM 05.02

Base Station Identi ty Code is sent downlink in theSCH. The format is NCC - BCC.NCC= Network Colour Code, BCC= Base Station Colour Code.From the NCC the MS determines which cells are allowed for handover (see also parameter PLMNP), i.e. only cells with a‘permitted’ NCC may be included in the MEASUREMENT REPORTS.The BCC must correspond to the Training Sequence Code (TSC)

assigned to the BCCH of that cell. The BCC is used by the MS tocorrectly decode the BCCH. In other words: From the BCC in theSCH the MS knows the TSC of the BCCH it has to select. The BCC is selected by default as TSC for the BCCH when it is created (seealso CREATE CHAN). Within one PLMN more than one NCC may beallowed. From the point of view of network planning, care needs to betaken to ensure that the same NCC is not used in adjacent PLMNswhich may use the same BCCH carrier frequencies in neighbouring areas.

BURNOFFS=<NULL>,


range: 0..7, <NULL>

Reference: <NULL>

Burst num ber of fse t , this parameter is relevant if the feature ‘inter Site Synchronization’ (ISS) is used and indicates, as an integer value, the burst number offset of the BTS. For further details about ISS and the meaning of this parameter please refer to parameter EINTSITSYN (see command CREATE BTSM).

CALLF01=60,


range: 0..1023 each field


GSM 05.02

GSM 12.20

Cel l al location frequency 1 , this parameter defines the first non-BCCH radio frequency allocated to the cell. Further frequencies used in the cell are set with the remaining parametersCALLF02..CALLF63. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 1) or/and on the main DCCH (contained e.g. inthe ASSIGNMENT COMMAND) in the IE ‘Cell Channel Description’.The ‘Cell Channel Description’ is a bit map (different formats are

possible), in which for every frequency of the used band (GSM,DCSetc.) an own bit position is provided. If the bit position is '1' then thefrequency represented by this bit position is included in the 'cell allocation'. If frequency hopping is enabled the ‘Cell ChannelDescription’ IE is needed by the MS to decode the info in the IE ‘Mobile Allocation’ which specifies the frequencies used in thefrequency hopping sequence.

Which frequency numbers are allowed, depends on the used frequency band:

SYSID=BB900: 1..124SYSID=F2ONLY900: 0..124, 975..1023SYSID=EXT900: 0..124, 975..1023SYSID=DCS1800: 512..885 SYSID=GSM850: 128..251SYSID=GSM850PCS: 128..251, 512..885 SYSID=GSM850DCS: 128..251, 512..810 SYSID=GSMR: 955..974SYSID=PCS1900: 512..810

Notes:- The SYSTEM INFORMATION TYPE 1 is only sent if frequency

hopping is used.CALLF02..CALLF63


Cel l allocation frequenc ies 2 to 63 , these parameters define all theremaining non-BCCH radio frequencies used in the cell (seeCALLF01). For each frequency an own parameter is available - tosave space, they were summarized here in one table line.





CBQ=0,


range: 0= normal priority

1=low priority

default: 0


GSM 03.22

Cel l bar qual i fy , is used to assign a priority to a cell which is to beconsidered by the MS during the cell selection decision. A suitablecell with low priority is only selected if no suitable cell of normal

priority can be found. This parameter (CELL_BAR_QUALIFY) is sent in the IE ‘SI 4 Rest Octets’ on the BCCH (SYSTEM INFORMATION TYPE 4). This parameter only has to be set if CRESPARI is set to ‘1’.

Attention: CBQ is on ly cons idered for ‘cell select ion’ , but not for

‘cel l reselect ion’ .

Cell Re selection means that the MS is camping on a cell and decides(on the basis of the level criterion C1 resp. C2) to select a different neighbour cell because this cell offers better DL RXLEV conditions.

As possible target cells, only neighbour cells are considered that areincluded in the 'Neighbour Cell Description' which is broadcast in theSYSTEM INFORMATION TYPE 2. In this case the cell priority defined by CBQ is NOT considered by the MS!

Cell selection means, that the MS is currently not or no longer booked in to a cells and starts a search for a suitable cell 'fromscratch'. This happens e.g. after switching on the MS or when the MShas lost the connection to the network (lossloss of coverage). Only inthis case the MS considers the cell priority defined by CBQ for the

selection of the cell.CELLGLID="262"-"02"-10-101,


range: MCC: "0..999"

MNC: "0..999" (PCS1900)

MNC: "0..99" (all others)

LAC: 0..65535

CI: 0..65535


GSM 04.08

Cell Global Identit y , this digit string unambiguously identifies a cell within the worldwide GSM system.The format is "MCC"-"MNC"-LAC-CI.MCC= Mobile Country Code (identifies the country)MNC= Mobile Network Code

(identifies the network within the country)LAC = Location Area Code

(identifies the location area within the network)CI = Cell Identity (identifies the cell within the location area)This parameter is sent downlink on the BCCH (SYSTEM INFORMATION TYPE 3 or 4) or on the SACCH (SYSTEM INFORMATION TYPE 6). Within these messagesMCC-MNC-LAC make up the IE ‘Location Area Identification’ and CI

corresponds to the IE ‘Cell Identity’. SYSTEM INFORMATION TYPE 4 does not contain the CI but only the LAI.





CELLRESH=2,


unit: 2dB

range: 0..7

default: 2


GSM 04.08

GSM 03.22GSM 12.20

Cel l reselect hysteresis , indicates the value of the receiver RF power level hysteresis required for cell reselection (MS in idle mode)on the basis of the path loss criterion C1.

C1 = (A - Max(B,0))

where A = <receive level average> - RXLEV_ACCESS_MIN= RLA_P - RXLEVAMI

B = MS_TXPWR_MAX_CCH - P= MSTXPMAXCH - P

P = Maximum RF output power of the MS (see table under parameter MSTXPMAXDCS in command SET BTS [BASICS]).

Max (B,0)= MSTXPMAXCH - P if MSTXPMAXCH > PMax (B,0)= 0 if MSTXPMAXCH < P

For RXLEVAMI see corresponding parameter in this command,MSTXPMAXCH see SET BTS [CCCH].

The term Max(B,0) is applied to ensure a sufficient uplink RXLEV even for MS with low transmit power level. The term Max(B,0), added to RXLEVAMI, ensures that the transmit power capability isconsidered in addition to the minimum receive level defined by RXLEVAMI: the lower the maximum transmit power of the MS, thehigher the minimum RXLEV for access must be.

The MS calculates the path loss criterion for the serving and the non-serving cell at least every 5 seconds (the MS derives the necessary calculation parameters from the BCCHs of the serving and theneighbour cells). The calculation result determines the priority of these cells within the list of the six strongest neighbour cells which isdynamically managed in the MS in idle mode. The path loss criterionis satisfied if C1 > 0 (If C1 has been < 0 for a period of 5 s the path tothe cell is regarded as lost). If C1 of the non-serving cell is higher than C1 of the serving cell for a period of 5 s then the MS performs acell reselection. Exception: If the current cell and the new cell belong to different location areas the new cell shall only be selected if the

path loss criterion C1 on the new cell exceeds C1 on the old serving cell by at least CELLRESH for a period of 5 seconds. Thismechanism is used to avoid unnecessary location update

procedures. The value of CELLRESH is sent on the BCCH (SYSTEM INFORMATION Type3 and Type 4) in the IE ‘Cell SelectionParameters’ and in the SET SYSTEM INFORMATION 10 in the IE ‘Differential Cell Parameters’.

Note: The C1 criterion can be replaced by the C2 criterion (see parameter CRESPARI) if the appropriate parameters are provided via the BCCH.





CELLTYPE=STDCELL,


range: STDCELL

EXTCELL

DBSTDCELL

default: STDCELL

Cel l type , this parameter determines which kind of cell is to bedefined.

a) The value STDCELL means ‘standard cel l ’ and represents anormal cell with a maximum cell radius (i.e. max. MS-BTS distance)of 35km (this value, of course, only goes for GSM900/GSM850, for DCS1800/PCS1900 the cells must be naturally smaller due to theradio propagation characteristis in the corresponding frequency

band). Standard cells use ordinary single timeslots for TCHs and donot distinguish different coverage areas within the cell.

b) The value EXTCELL means ‘extended cel l ’ and represents aspecial cell with a maximum cell radius (i.e. max. MS-BTS distance)of 100km (this is, of course, possible only for GSM900/GSM850).Within an extended cell, different TCH pools serve different coverageareas that are characterized by their distance from the antenna:-ordinary ‘single’ TCHs are used to provide TCH resources for thecoverage area up to the maximum possible MS-BTS distance of 35km. A ‘single’ TCH is an ordinary TCH as used in standard cellsand consists of one radio timeslot. The coverage area served by thistype of TCHs is also called ‘near area’.- special ‘extended’ or ‘double’ TCHs are used to provide channel resources for the coverage area up to the maximum possible MS-

BTS distance of 100km (please refer to the parameter EXTMODE inthe command CREATE CHAN). These ‘double’ TCH are nothing but a pair of directly adjacent radio timelots that are merged together,thus working as one radio timeslot with an extremely extended ‘guard

period’ and thus allow a much higher delay of the bursts received from the MS. The coverage area covered by this type of TCHs is alsocalled ‘far area’.

In an extended cell, all control channels (BCCH, CCCH, SDCCH,CBCH) must be configured as ‘double’ timeslots. As opposed toconcentric cells (parameter CONCELL, see below) there is no fixed relation between an ‘area’ (far or near) and TRX. Instead, the ‘area’ isdefined by the pool of ‘single’ or ‘double’ timeslots - independent of the timeslots’ association to a TRX.

Example configuration:

ts 0 ts 1 ts 2 ts 3 ts 4 ts 5 ts 6 ts 7

TRX:0 BCCH ext SDCCH ext TCH TCH TCH ext

TRX:1 TCH ext TCH ext TCH TCH TCH TCH

= near area = far area

Signaling of extended TA values As in an extended cell the normal coding range of the timing advance(TA, ranbge 0..63) is not sufficient to display distance values greater than 35km, a new IE called ‘timing offset’ is used in the Abis RSLsignalling which allows the representation of the corresponding extended MS delay values.

Call setup in an extended cell When an MS sets up a call in an extended cell, the BTS adds thecurrent ‘timing offset’ measured from the RACH access burst delay tothe CHANNEL REQUIRED message. Moreover, the BTS measuresthe current MS delay during the SDCCH phase (as mentioned, theSDCCH is always a ‘double’ timeslot) and provides it as acombination of TA and ‘timing offset’ value to the BSC within thePHYSICAL CONTEXT CONFIRM message which is sent prior to theCHANNEL ACTIVATION of the TCH. These values are used by theBSC to decide whether a ‘single’ or a ‘double’ TCH is to be assigned to the call. This decision is based on the value of the distancethreshold HOMSTAM (see command SET HAND [BASICS]). Whenthe BSC has selected a suitable TCH it forwards the TA and timing





offset values to the BTS in the CHAN ACT for the TCH so that theBTS can can instruct the MS to correctly adjust the timing advance tothe current MS-BTS distance.

Intracell handover due to distance (far-near, near -far) When a call has been established in an extended cell, it might benecessary to handover the call from a double to s single timeslot or vice versa, depending on the current chages of the MS-BTSdistance. This handover is enabled by the parameter EXTCHO and

the decision id based on the distance threshold HOMSTAM and thedistance margin HOMRGTA (all parameters see command SET HAND [BASICS]).

For futher details please refer to the mentioned parameter descriptions.

Note: The features 'Extended Cell' and 'Concentric Cell' (seeCONCELL) exclude each other.

c) The value DBSTDCELL means ‘Dual band standard cel l ’ and represents a new type of cell having frequencies in two different frequency bands and a BCCH in one of these bands. The dual band standard cell is also called ‘Common BCCH cell’ (Attention: Asopposed to BR7.0, the ‘Common BCCH’ cells in BR8.0 are no longer based on the feature ‘concentric cells’ (parameter CONCELL, seeabove), but only on the setting CELLTYPE=DBSTDCELL. In other words, the parameter CONCELL must be set to FALSE in thisconfiguration).

Cell characteristicsThe frequency bands to be supported are GSM850/PCS1900,GSM900/DCS1800 and GSM850/DCS1800. The Dual Band Standard Cell must be planned in such a way that the frequency bands have exactly the same coverage. This implies that at any location within a Dual Band Standard Cell, a service can be allocated on either of the frequency bands. The dualband standard cell has acell identity as any single band GSM cell. Both circuit switched, e.g.speech, and packet switched data e.g. GPRS/EGPRS, services canbe allocated in both frequency bands. If PBCCH is configured, it must be on the BCCH frequency band.

TCH allocation principlesThe radio resource allocation in a Dual band Standard Cell is performed in accordance with the feature ‘Service Dependent Channel Allocation’ but having a only one single Service Layer List (SLL), which is the Service Layer Primary Area (SLPA) like aStandard cell, with layers having TRXs of BCCH frequency band and TRXs of non-BCCH frequency band. In other words, the SLL iscommon to both the frequency bands. The service layer selected for search of the TCH resources is determined by the service typerequested by the mobile. For every layer, the favoured TCHs are theones with the lowest interference class (see parameter INTCLASS incommand SET BTS [INTERF] and compatible with the mobile’sservice capabilities.

A mobile requesting a TCH within a dual band standard cell isgranted TCH resources according to the SLL and its capabilities, i.e.dual band MSs are allocated on either of the frequency bands,whereas single band MSs shall be allocated only on BCCH frequencies.If the operator wants to preserve resources for single band mobiles,he must create service layers with unique band (layers withBCCH band separated by layers with non-BCCH band) and must define the layers of the non-BCCH band as last in the SLL.

If the value of parameter SYSID is GSMDCS and the operator wantsto preserve the resource for phase1-mobiles, he must distribute theTRXs with frequences in GSM baseband and the TRXs in GSM extended band over different service layers. Then he must define in





the service layer list first the layers for GSM extended band, and after that the layers for the GSM base band.

If a GPRS mobile accesses the cell, the mobile frequency bands of operation and relative power capabilities are sent to the network inthe PACKET RESOURCE REQUEST message during the two phaseaccess and within Additional MS Radio Access Capabilities messageduring one phase access. Hence the GPRS mobile is allocated resources within Dual Band Standard Cell depending on the operator

policy and according to the settings of the feature ‘ServiceDependent Channel Allocation’. Packet data service on the non-BCCH frequency band is allowed by associating EGPRS/GPRSservice with a service layer comprising TRXs of the non-BCCH frequency band and setting GEXTS parameter (see below) to theright value.

Evaluation of MS capabilities A multiband network uses 2-ter and 5-ter System Info messageswhich enable multiband mobiles to access the network and, at thesame time, to maintain compatibility with single band mobiles.

The BSS is informed about the frequency capabilities and associated power capabilities of the multiband MS on each frequency band by the Early Classmark Sending procedure (see parameter EARCLM incommand SET BTS [OPTIONS].

Interworking with feature ‘Service Dependent Channel Allocation’ If the operator wants to prioritize a particular frequency band for any given service, this can be achieved by:

- Definition of dedicated layers, with BCCH band frequencies only or,conversely, non-BCCH band frequencies only - Definition of mixed layers (composed of BCCH and non-BCCH frequencies) through a proper order of layers within the list associated to that service. If a layer contains TRXs of both frequency bands of the Dual Band Standard cell, resources are ordered in thislayer on the basis of the interference band they belong to and kept with regards both with this criteria and MS capability.

If e.g. a particular service supported both in the 900 MHz and in the1800 MHz band. In this case, the (for both bands) unique SLL may have, in the first positions, the 900 MHz layers (if e.g. the operator wants to prioritize the 900 MHz band) ordered according to a radioquality criterion and in the remaining positions the 1800 MHz layersstill ordered according to the same criterion.If a layer contains TRXs from both frequency bands of the Dual band Standard cell, resources are ordered on the basis of the interferenceband they belong to.

Interworking with frequency Hopping According to the GSM/3GPP standard, Frequency Hopping is not allowed across frequency bands.The only exception is between P900 and E900 bands specifying thefirst ones with the notation (301..424). Therefore frequencies onwhich to perform Dynamic MAIO Allocation (DMA) must belong to thesame frequency band and two frequency bands must be defined for DMA.





CONCELL=FALSE,


range: TRUE, FALSE

default: FALSE

Concentr ic cel l , this flag defines whether the cell is a concentric oneor not. A ‘concentric cell’ is a cell in which different TRX may havedifferent ranges. TRXs with the smaller range serve the so-called ‘inner area’, TRXs with the wider range serve the so-called ‘completearea’.

Whether a TRX serves the inner or the complete area is defined inthe TRX object (see parameter TRXAREA (CREATE TRX)). Thedifferent TRX coverage ranges are, for single-band concentric cells,determined by the values entered for the power reduction (see

parameter PWRRED (CREATE TRX)) and, for dualband concentric cells by the different TX ouput powers of the used TRX HW (CU/PA)and different propagation attenuations of the different used frequency bands.

In any case all control channels of the concentric cell (BCCH, CCCH,

SDCCH, CBCH) must belong to the complete area. As opposed toextended cells (parameter CELLTYPE, see above) there is a fixed relation of concentric cell areas and particular TRXs.

Example configuration:

ts 0 ts 1 ts 2 ts 3 ts 4 ts 5 ts 6 ts 7

TRX:0 BCCH SDCCH TCH TCH TCH TCH TCH TCH

TRX:1 TCH TCH TCH TCH TCH TCH TCH TCH

TRX:2 TCH TCH TCH TCH TCH TCH TCH TCH

= complete area = inner area

Within a concentric cell, specific intra-cell handovers from the inner tothe complete area and vice versa are possible. These handovers are

executed on level / distance conditions defined by appropriatethresholds in the handover package (see parameters CCDIST,HORXLVDLI, HORXLVDLO and HOCCDIST (SET HAND[BASICS])). Moreover, during the call setup procedure in a concentric cell the same values are also evaluated to determine whether the call is set up on a TCH belonging to an inner or complete area TRX.

The concentric cell configuration is also possible in cells with mixed frequency bands - in this case, in addition to CONCELL=TRUE, the

paremeter CELLTYP must be set to the value STDCELL (seeabove), the parameter SYSID (see below) must be set to GSMDCSresp. GSM850PCS and the parameters for maximum allowed transmission power must be set for both bands (parametersMSTXPMAXGSM and MSTXPMAXDCS, see below). In this case,frequencies of different frequency bands are assigned to the inner

and complete area of a concentric cell. Considering the frequency propagation characteristics and the band-specific maximum cell radius, the most useful configuration is to use GSM900 resp.GSM850 frequencies for the complete area (and thus for the BCCH and also the SDCCHs) and to assign DCS1800 resp. PCS1900 frequencies to the inner area. However, also the oppositeconfiguration is also technically possible.

Attention: Please be aware that the above configuration is to beregarded as a ‘dual band concentric cell’, with all known features of aconcentric cell but with different frequency bands in each area. Thisconfiguration is different from the so-called ‘dual band standard cell’ configuration (CELLTYP=DBSTDCELL, see above), which was

INNER area

COMPLETE area





CRESPARI=1,


range: 0=C2 parameters not present

1=C2 parameters present

default: 1


GSM 03.22

Cel l reselect ion parameter indicator , indicates the presence of C2 cell reselection parameters on the BCCH in the IE ‘SI 4 Rest Octets’ (SYSTEM INFORMATION TYPE 4) and the IE ‘SI 3 Rest Octets’ (SYSTEM INFORMATION TYPE 3); 0=not present, 1=present.The criterion C2 is an optional feature that can be enabled on a cell basis. It is an enhancement of the cell selection C1 (for C1 pleasesee parameter CELLRESH). C2, however, is useful for microcell-

configurations since it prevents fast moving MSs from performing unnecessary cell reselections.The MS calculates C2 (on the basis of C1) or C1 respectively (if theC2 cell reselection parameters are not broadcast in the affected cell)for the serving and all neighbour cells at least every 5 s. The result of this calculation determines the priority of these cells within the list of the six strongest neighbour cells which is dynamically managed inthe MS in idle mode. Depending on the availability of C2 cell reselection parameters in the BCCH info the MS considers C1 or C2 for the cell reselection process.

General Principle of the C2 algorithm: If the MS places a non-serving cell on the list of six strongest carriers it starts a timer the value of which has been broadcast on the BCCH (see parameter PENTIME).Equation A: C2 = C1 + CRESOFF - TEMPOFF

as long as the timer (PENTIME) runs and PENTIME < 31Equation B:C2 = C1 + CRESOFF

if the timer (PENTIME) has expired and PENTIME < 31Equation C:C2 = C1 - CRESOFF

if PENTIME = 31 Equation A: As long as the timer runs C2 is increased by a

permanent offset (see parameter CRESOFF) and decreased by atemporary offset (see parameter TEMPOFF). By this temporary offset the C2 of the non-serving cell is artificially made worse and the cell reselection is not executed.

Equation B: On expiry of the timer the temporary offset is disregarded and thus - if the C2 of a non-serving cell still exceeds the one of theserving cell for a period of 5 s the MS performs a cell reselection.Exception: If the current cell and the new cell belong to different

location areas the new cell shall only be selected if the C2 of the new cell exceeds C2 of the old serving cell by at least the cell reselect hysteresis (see parameter CELLRESH) for a period of 5 seconds.This mechanism is used to avoid unnecessary location update

procedures.

Equation C: If the penalty time is set to 31 (i.e. 260s) the permanent offset (CRESOFF) is not added to but subtracted, i.e. setting PENTIME to 31 results in a permanent decrease of priority. Thus inthis case it is possible to exclude particular cells from the cell re-selection permanently, i.e. without any time limitation.

If CRESPARI is set to ‘0’ the parameters CRESOFF, TEMPOFF,

C2

expiry of timer start of timer

C1

PENTIME

CRESOFF TEMPOFF

C1 + CRESOFF - TEMPOFF

C1 + CRESOFF

t





attempted in parallel and queued calls can be served when downgrade is successfully completed.

Please refer to the parameters EPRE (for preemption) and EQ (for (WPS) queueing) in command SET BTS [OPTIONS] and to

parameter ENFORCHO (for directed retry) in command SET BTS[BASICS].

- Interworking of the features ‘Downgrade strategy’ and (WPS)queuing

When a TCH request is queued, the BSC tries, when possible, toserve the queued TCH requests by a multislot call downgrade

procedure (e.g. (E)GPRS downgrade:Every call is put in the queue with its relevant data (channel request type, WPS/Public call info, Service List, running procedure, …). After the call is queued, the resource management process periodically starts the downgrade procedure (if correspondingly enabled via

parameter DGRSTRGY) on HSCSD data calls and/or (E)GPRS datacalls (if any) in order to get new resources for TCH allocation. Thecall that triggers the downgrade procedure is marked as “downgraderequested” in order to wait for the resources that will be availableafter successful completion of the downgrade procedure.If during the ongoing downgrade procedure other TCHs become ‘idle’ again, these resources cannot be assigned to the call marked as

“downgrade requested”. The call marked as “downgrade requested” must in any case wait for the resources achieved by the downgrade

procedure.

The downgrade procedure is requested for the multislot callsestablished on the shared layers with service layer associationmatching to the service type of the enqueued call, starting from the

preferred layer. On the other hand, in case of Abis congestion themultislot downgrade procedure will be requested on all layers of thiscell associated to the multislot service layer list and in the extremecase also on other cells of the same BTSM.

- For GPRS the downgrade is only possible for those TCHs that canbe dynamically shared between CS and GPRS traffic. For thesechannels, the following conditions must be fulfilled:- the TCH is created with GDCH=<NULL> (see CREATE CHAN)

- the TRX supports GPRS (this is the case if the TRX is defined asbelonging to a service layer which is included in the SLL for GPRSservices - please see command SET BTS [SERVICE] for further explanations).- The GPRS downgrade strategy has an influence on all TCH load dependent features such as Traffic Handover (see parameter TRFHOE in command SET HAND[BASICS]), Cell Load Dependent

Activation of Half Rate (see parameter EHRACT in command CREATE BTS [BASICS]), Enhanced Pairing (see parameter EPA incommand SET BSC [BASICS]) and AMR Compression Handover (see parameter EADVCMPDCMHO in command SET HAND[BASICS]).

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 or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs whichare currently busy due to GPRS traffic (PDCH) are considered as‘idle’.However, if a TCH was activated as PDCH for GPRS traffic but theTEMPCH timer (see parameter TEMPCH in command CREATE PCU) is running for it, (which means that there is no ongoing TBF onthe TCH), the TCH is always regarded as ‘downgradable’ resp.





‘preemptable’ for CS calls, no matter which value was set for theDGRSTRGY parameter. In other words, in periods of TCH congestion the BSC immediately releases PDCHs (TCHs activated for GPRS) with TEMPCH running if a CS TCH request is received and no other idle TCH is available for allocation. This change wasimplemented in BR7.0 in the scope of CR1150.

Note: Please see also parameter DGRSTRGYBCNT (command SET BSC [BASICS]).

EANTHOP = FALSE,


range: TRUE, FALSE

default: FALSE

Enable antenna hopp ing , this parameter enables or disables thefeature “antenna hopping”. Antenna Hopping offers a new hopping mechanism in addition to frequency hopping: the DL bursts of achannel are transmitted on GSM frame basis (or every 2nd or 4thframe) over alternating antennas within a cell. Antenna Hopping allows to obtain a performance improvement (diversity gain) of several dBs in DL direction.

The hopping mechanism is the main difference between AntennaHopping and the already supported frequency hopping schemes,baseband and synthesizer hopping: TX Antenna Hopping is

performed on CU basis, not on timeslot basis , in other words:complete CUs, including all timeslots on them, perform AntennaHopping. It is not possible to generate Antenna Hopping sequencesfor each timeslot individually.

A combination of synthesizer frequency hopping and AntennaHopping is possible, whereas a combination with baseband frequency hopping is not allowed, because the TX Diversity/AntennaHopping feature itself is based on some baseband hopping mechanism. The feature is a complete SW feature, requiring nomodifications in any HW.

Antenna Hopping is supported only by BTSplus mainl ine, BS240XS

and e-Micro BTS . Due to the limitations of the CClink PicoBTS is not able to do baseband frequency hopping and therefore also no

Antenna Hopping. Antenna Hopping is not specified for BTSsbelonging to BTSone family, such as BS60, BS20. All types of BTScombiners are supported but FICOMs. FICOMs are tuned via motor to a specific TRX frequency so that only baseband frequency hopping is possible, which is forbidden parallel to Antenna Hopping.CUs connected to a FICOM are excluded automatically from AntennaHopping.

Antenna Hopping has to deal with various types of CUs (e.g. GSM-CU, EDGE-CU and SB-EDGE-CU for switched beams) and frequency bands (e.g. GSM900, DCS1800 and PCS1900). For this aCU-POOL concept has been developed, restricting the AntennaHopping between CUs of the same POOL only and thus alsobetween the antennas to which the corresponding CUs of the POOLare connected. It is not possible to perform Antenna Hopping between CUs of different types and frequency bands.

All CUs of the same frequency band and of the same HW type arealways assigned to the same CU-POOL. For each pool a hopping sequence is calculated. The pool grouping and the calculation of pool

sequences are done in the BTS core (COBA) by a dedicated algorithm.

Antenna Hopping is enabled for either all CUs including the BCCH-TRX CU or for all CUs except for the BCCH-TRX CU. If AntennaHopping for the BCCH-TRX is excluded, the corresponding CU is not assigned to any CU-POOL.

Enabling/disabling Antenna Hopping for the BCCH-TRX is doneusing the parameter ANTHOPMOD (see below).

The feature "not-ramping for BCCH" will be deactivated if AntennaHopping with ANTHOPMOD (AntennaHoppingMode)=ALLTRX is set.

Further related parameters are ANTHOPMOD and ANTHOPP.





EEOTD=TRUE,


range: TRUE, FALSE

default: FALSE

Enable equal TSC to B CC , this parameter represents the flag toenable the setting of the TSC (Training Sequence Code) equal to theBCC (Base Station Color Code) for all channels belonging to theBCCH TRX.

EFCRESEL=FALSE,



Enable Fast Cell reselectio n , when this attribute is set to TRUE, theBSC inserts the BCCH frequency on the BA list sent on System Info2. The relevant BSIC inside to SYSTEM INFORMATION TYPE 2

quater will broadcast it for the specific cell.

EHDCTR=FALSE,


range: TRUE, FALSE

default: FALSE

Enable history on drop ped cal l tracing , this parameter determineswhether the feature ‘history on dropped calls’ (History on Dropped Call Tracing HDCTR) is enabled in the cell. This parameter is only relevant if the HDCTR feature is generally enabled for the BSC (seecommand CREATE HDTCR).

Further relevant parameters for the HDCTR file handling are HDCFSand HDCFUPE (see command SET BSC [CONTROL].





EHRACT=TRUE,


range: TRUE, FALSE

default: TRUE


Enable cel l load dependent activat ion of HR , this parameter enables the feature “Cell load dependent activation of half rate” for non-AMR calls in the cell (for AMR calls, a separate database flag EHRACTAMR (see below ). This feature allows the BSC to overridethe speech version preferences indicated in incoming TCH seizuresrequests and to force these incoming TCH seizure requests to FR or HR TCHs depending on the actual radio traffic load situation in the

cell (BTS) and the Abis traffic load situation in the BTSM. On thebasis of the radio TCH load thresholds HRACTT1 resp. HRACTT2

(see command CREATE BTS [ BASICS ] ) and the Abis TCH load threshold ABISHRACTTHR (see command CREATE BTSM) the BSC decides which kind of TCH type (resp. speech version) is to beassigned for a particular TCH seizure request.

Detailed functional description:The BSC can receive an incoming CS TCH seizure request in thefollowing ways:

1) Receipt of an ASSIGNMENT REQUEST (call setup)2) Receipt of a HANDOVER REQUEST

(incoming MSC-controlled handover).3) Receipt of an INTERCELL HANDOVER CONDITION INDICATION (incoming BSC-controlled intercell handover)4) Receipt of an INTRACELL HANDOVER CONDITION INDICATION (BSC-controlled intracell handover)

Cases 1) and 2) represent ‘original’ TCH requests, as they aretriggered by messages which indicated the speech versioncapabilities an preference allowed from the MS and MSC point of view. Both ASS REQ and the HO REQ contain Information Elementsindicating the supported speech versions and the speech version

preference. The BSC stores the capability and preference ‘profile’ of each call in one transaction register and considers this profile for all subsequent TCH seizure requests (cases 3 and 4). If EHRACT=FALSE, the decisive factor for the BSC in the TCH assignment decision is the signalled speech version preference(unless there is TCH congestion).

However, in situations with high traffic load it makes sense to ignorethis preference and to force incoming calls to HR TCHs if HR isindicated as supported speech version in the TCH seizure request.This is achieved by setting EHRACT=TRUE and by applying asuitable traffic load threshold value (HRACTT1/HRACTT2).

Before assigning a TCH after having received one of theabovementioned TCH seizure requests (1..4) the BSC calculatesa) the current cell traffic load (per BTS) and b) the current Abis traffic load (per BTSM)

Case A: HR activat ion du e to radio TCH load in the c el l Before assigning a TCH after having received one of theabovementioned TCH seizure requests (1..4) the BSC calculatesthe cell traffic load and compares it to the threshold HRACTT1 resp.HRACTT2 (for inner area in concentric cells or far area in extended

cell).The BSC calculates the cell traffic load according to the formula

For further details about the meaning of single terms of this formula, please refer to the description of parameter HRACTT1.

As long as the cell traffic load remains below the threshold defined by the parameters HRACTT1 and HRACTT2, the BSC forces theincoming TCH seizures to FR or EFR (depending on the preferenceindicated in the ASS REQ or HO REQ and the BSC/TRAU capability).

∗ 100Cell traffic load [%] =no. of radio TCH not available for CS TCH allocation

no. of configured radio TCH





handover), the features ‘Cell load dependent actvation of half rate’ and ‘Abis load dependent activation of half rate’ (see parameter

ABISHRACTTHR in command CREATE BTSM) are not considered if the BSC receives an INTRACELL HANDOVER CONDITION INDICATION due to quality reasons (cause values ‘uplink quality’ or ‘downlink quality’). This means that the BSC does not check thecurrent BTS TCH load and the BTSM Abis pool TCH load in case of an intracell handover due to quality. Instead, the BSC just maintains

the same channel type / speech codec as used before on the old channel.

EHRACTAMR=FALSE,


range: TRUE, FALSE

default: TRUE


Parameters moved from BSC object to

BTS object in BR8.0!

Enable cel l load dependent activat ion of hal f rate for AMR c al ls ,this parameter is the AMR equivalent to the parameter EHRACT (seecommand CREATE BTS [BASICS]) and allows to enable or disablethe feature ‘Cell load dependent activation of half rate’ for AMR callsfor all BTSs belonging to the BSC. This feature controls the allocationof AMR HR TCHs in such a way that AMR half rate TCHs are only assigned if the percentage of busy radio TCHs in the BTS or/and the

percentage of busy Abis TCHs in the BTSM Abis channel pool haveexceeded a configurable threshold.

For cell load dependent activation HR the radio TCH traffic load threshold is defined by the parameters HRACTAMRT1 and HRACTAMRT2 (see command CREATE BTS BASICS]).

For Abis load dependent activation HR the radio TCH traffic load threshold is defined by the parameter ABISHRACTTHR (seeCREATE BTSM).

For further details about the feature functionality and the exact calculation of the traffic load please refer to the parameters EHRACT,HRACTAMRT1 and HRACTT1 (see CREATE BTS [BASICS]) and

ABISHRACTTHR (see CREATE BTSM), as the basic concept and the traffic load calculation algorithm are exactly the same for callswith standard speech coding (FR version 1 and 2 and HR version 1)and calls with AMR speech coding. For further details about AMR

please refer to the parameter AMRFRC1 (see command CREATE BTS [BASICS]).

Note: The database flags EHRACTAMR and EHRACT are

independent of each other, i.e. for operation of the feature ‘Cell load dependent activation of half rate’ for AMR calls only the flag EHRACTAMR is relevant, the setting of the flag EHRACT does not have any influence.

ENPERNOTDE=FALSE,


range: TRUE, FALSE

default: FALSE

Enable per iodic noti f ic at ion on dedicated channel , this parameter enables/disables the periodical notification repetition on dedicated channels.





EPAT1=4000,


unit: 0,01 %

range: 0..10000

default: 4000


Enhanced Pair ing Threshold 1 , this parameter represents thethreshold that indicates, when the Enhanced Pairing for TCH/H channels feature is enabled (see parameter EPA in command SET BSC), the percentage of busy radio TCHs

- in the whole BTS (in case of standard cell)- in the complete area of a concentric cell (see parameter CONCELLin command CREATE BTS [BASICS])

- in the far area of an extended cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS])

The value 100 represents 1%.

Enhanced pairing intracell handovers are triggered if the following radio TCH traffic load condition is fulfilled (for further details about themeaning of single terms of this formula, please refer to thedescription of parameter EPAT1).

* Attention:

- Generally a TCH\F is counted as 2, a TCH\H is counted as 1!

- A dual rate TCH (TCHF_HLF) can assume the usage state “busy“ (i.e. both HRsubslots busy), ”active“ (i.e. only on HR subslot busy) or “idle”. A TCH_HLF in state

“active” is counted as 1, a TCH_HLF in state “idle” is counted as 2.

- The GPRS downgrade strategy (see parameter DGRSTRGY in command SET BTS[BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is setfor the DGRSTRGY parameter, as these TCHs are in any case immediately preemptedif a CS TCH request meets a TCH congestion situation.

- TCHs ’reserved for GPRS’ (see parameter GMANPRESPRM in the PTPPKF object)are not considered in the calculation, i.e. they are treated as if they were notconfigured! Thus the value above the fraction bar represents all TCHs in state ‘idle’(not considering the reserved GPRS TCHs in state ‘idle’) and the value below thefraction bar is the number of the actually created TCHs minus the TCHs reserved for GPRS.

- If a GPRS call utilizes more TCHs than configured as ‘reserved’ by GMANPRESPRM,the currently used but ‘not reserved’ TCHs (‘idle/shared’ TCHs) are considered incorrespondence with the setting of DGRSTRGY as indicated above.

Note: Interworking of ‘Service Dependent Channel Allocation’ withtraffic load calculationThe percentage calculation done for the Enhanced Pairing is donereferring only to the TRXs included in the SLLs for the AMR speechand non-AMR speech service types, separately for every subarea(primary/complementary). Please refer to the command SET BTS[SERVICE] for further explanations.

Note: This parameter only represents the traffic load threshold for thefeature ‘Enhanced pairing due to BTS radio TCH load’. Enhanced

pairing can also be triggered due to BTSM Abis pool TCH load. Inthis case the relevant Abis pool TCH load threshold is defined by the

parameter ABISHRACTTHR (see command CREATE BTSM).

EPAT2=4000,


unit: 0,01 %

range: 0..10000

default: 4000


Enhanced Pair ing Threshold 2 , this parameter represents thethreshold that indicates, when the Enhanced Pairing for TCH/H channels feature is enabled (see parameter EPA in command SET BSC), the percentage of busy TCHs

- in the inner area of a concentric cell (see parameter CONCELL incommand CREATE BTS [BASICS])- in the near area of an extended cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS]).

The value 100 represents 1%.

For further details please refer to parameter EPAT1 (see above).

< ∗ 100no. of radio TCH in usage state ‚idle’ *

no. of configured radio TCHEPAT1[%]





FHAMRFRTH34=23-4,

object: BTS[BASICS]



hysteresis: 0.5dB



default: threshold: 23 [12.5 dB]hysteresis: 4 [2.0 dB]

Parameter renamed from “<old

name>”to “FH<old name>” and moved

from FHSY object to BTS[BASICS]

object in BR8.0

AMR Ful l Rate Thresholds 34 for frequency ho pping , this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from

AMRFRC3 to AMRFRC4 and vice versa in case of active frequency hopping (see also parameter HOPP in command SET BTS[OPTIONS].

This parameter eclipses its equivalent AMRFRTH34 if frequency

hopping is currently active for an AMR call.

For further details about the parameter values and AMR parametersand thresholds please refer to the parameter AMRFRC1.

FHAMRHRC1=RATE_01,

object: BTS[BASICS]


RATE_03, RATE_04,

RATE_05, <NULL>

default: RATE_01




object in BR8.0

AMR Half Rate Codec 1 for frequency hopp ing , this parameter defines the first AMR (Adaptive Multi Rate) active CODEC of the

Active CODEC Set (ACS) for AMR Half Rate in case of activefrequency hopping (see also parameter HOPP in command SET BTS[OPTIONS]. This parameter eclipses its equivalent parameter

AMRHRC1 if frequency hopping is currently active for an AMR call.


FHAMRHRC2=RATE_02,

object: BTS[BASICS]


RATE_03, RATE_04,

RATE_05, <NULL>

default: RATE_02




object in BR8.0

AMR Half Rate Codec 2 for frequency hopp ing , this parameter defines the second AMR (Adaptive Multi Rate) active CODEC of the




FHAMRHRC3=RATE_03,

object: BTS[BASICS]


RATE_03, RATE_04,

RATE_05, <NULL>

default: RATE_03




object in BR8.0

AMR Half Rate Codec 3 for frequency hopp ing , this parameter defines the third AMR (Adaptive Multi Rate) active CODEC of the

Active CODEC Set (ACS) for AMR Half Rate in case of active

frequency hopping (see also parameter HOPP in command SET BTS[OPTIONS]. This parameter eclipses its equivalent parameter AMRHRC3 if frequency hopping is currently active for an AMR call.


FHAMRHRC4=RATE_04,

object: BTS[BASICS]


RATE_03, RATE_04,

RATE_05, <NULL>

default: RATE_04




object in BR8.0

AMR Half Rate Codec 4 for frequency hopp ing , this parameter defines the fourth AMR (Adaptive Multi Rate) active CODEC of the



For further details about the parameter values and AMR parameters

and thresholds please refer to the parameter AMRFRC1.





FHAMRHRIC=START_MODE _HR,

object: BTS[BASICS]

range: START_MODE_HR

CODEC_MODE_01

CODEC_MODE_02

CODEC_MODE_03

CODEC_MODE_04 default: START_MODE_HR




object in BR8.0

AMR Half Rate Ini t ial Codec for frequency hop ping , this parameter defines which AMR HR CODEC of the created AMR HR ACS shall be used first after HR TCH assignment in case of activefrequency hopping (see also parameter HOPP in command SET BTS[OPTIONS]. The values CODEC_MODE_0x represent the created

AMR HR CODECs (AMRHRCx) of the ACS. This parameter eclipsesits equivalent parameter AMRHRIC if frequency hopping is currently

active for an AMR call.For further details about the parameter values and AMR parametersand thresholds please refer to the parameter AMRFRC1.

FHAMRHRTH12=19-4,

object: BTS[BASICS]



hysteresis: 0.5dB








object in BR8.0

AMR Half Rate Thresholds 12 for frequency hopp ing , this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from

AMRHRC1 to AMRHRC2 and vice versa in case of active frequency hopping (see also parameter HOPP in command SET BTS[OPTIONS].

This parameter eclipses its equivalent parameter AMRHRTH12 if frequency hopping is currently active for an AMR call.


FHAMRHRTH23=24-4,

object: BTS[BASICS]



hysteresis: 0.5dB







from FHSY object to BTS[BASICS]object in BR8.0



This parameter eclipses its equivalent parameter AMRHRTH23 incommand CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call.

For further details about the parameter values and AMR parameters

and thresholds please refer to the parameter AMRFRC1.

FHAMRHRTH34=30-4,

object: BTS[BASICS]



hysteresis: 0.5dB



default: threshold: 30 [15.0 dB] (BTS+)

<NULL> (BTS1)





object in BR8.0



This parameter eclipses its equivalent parameter AMRHRTH34 if frequency hopping is currently active for an AMR call.






FRACTAMRTH1=3000,


range: 0.. 10000

default: 3000

Ful l Rate Activat ion AMR threshold , this parameter is only relevant if the parameters EADVCMPDCMHO and EADVCMPHOAMR are set to TRUE (see SET HAND [BASICS]). It is used fo r load-dependent AMR Decom pression Handover . The task of this handover type isto hand over as many AMR calls (that currently occupy a HR TCH toa FR TCH) as possible to provide the best possible QoS and speechquality in time periods with an acceptably low TCH load and Abis

pool TCH load.On every expiry of the timer TRFCT (see SET BSC) the BSC checksthe traffic load in its cells and compares it to the threshold FRACTAMRTH1.

For AMR compression handover the BSC calculates the traffic load as follows

Attention:


- (*) A dual rate TCH (TCHF_HLF) in usage state „busy“ (i.e. both HR subslots busy)

is counted as 2 while a dual rate TCH in usage state „active“ (i.e. only on HR subslot

busy) is counted as 1.

- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBTS [BASICS]) has an influence on the radio TCH traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]).a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all (non-reserved) TCHswhich are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like anyother TCH which is currently seized by a CS call.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currentlybusy due to GPRS traffic (PDCH) are considered as ‘idle’.- If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is setfor the DGRSTRGY parameter, as these TCHs are in any case immediately preemptedif a CS TCH request meets a TCH congestion situation.

- TCHs indicated as ‘reserved for GPRS’ (see parameter GMANPRESPRM in thePTPPKF object) are not considered in the calculation, i.e. they are treated as if theywere not configured! Thus, reserved GPRS TCHs in state ‘GPRS busy’ are notconsidered (value above the fraction bar) and the value below the fraction bar is thenumber of TCHs in ‘unlocked/enabled’ minus the TCHs reserved for GPRS in the samestate.


If the traffic load in the cell drops below the threshold FRACTAMRTH1, the BSC enables the load-dependent AMR decompression handover in the affected BTS by sending a SET

ATTRIBUTE message with the appropriate indications to the BTS.

This indication starts the load-dependent AMR decompressionhandover decision process in the BTS.

For further details, please refer to the parameter EADVCMPDCMHO

(see command SET HAND [BASICS]).Note: Interworking of ‘Service Dependent Channel Allocation’ withtraffic load calculationThe percentage calculation done for load dependent Compression/Decompression Handover is done referring only to theTRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea(primary/complementary). Please refer to the command SET BTS[SERVICE] for further explanations.

∗ 100Cell traffic load [%] =no. of TCH* in usage state ‘busy’**

no. of TCH in state unlocked/enabled





FRACTAMRTH2=3000,


range: 0.. 10000

default: 3000

Ful l Rate Activat ion Thresh old 2 for AMR cal ls , this parameter isonly relevant if the parameters EADVCMPDCMHO and EADVCMPHOAMR are set to TRUE (see SET HAND [BASICS]).FRACTAMRTH2 is the equivalent to the parameter FRACTTH2 (seebelow) for AMR calls and defines a traffic load threshold which isevaluated for load-dependent AMR decompressio n handover .

It has exactly the same function like the parameter FRACTAMRTH1

(see above) but affects different cell areas:

- in the inner area of a conc entr ic cell (see parameter CONCELL incommand CREATE BTS [BASICS])- in the near area of an extended cel l (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS]).

FRACTTH1=3000,


range: 0.. 10000

default: 3000

Ful l Rate Activat ion Thresho ld 1 , this parameter this parameter isonly relevant if the parameters EADVCMPDCMHO and EADVCMPHOAMR are set to TRUE (see SET HAND [BASICS]).

It is used for load-dependent non-AMR Decompression Handover.The task of this handover type is to hand over as many non-AMR calls (that currently occupy a HR TCH to a (E)FR TCH) as possible to

provide the best possible QoS and speech quality in time periodswith an acceptably low TCH load and Abis pool TCH load.

On every expiry of the timer TRFCT (see SET BSC) the BSC checksthe traffic load in its cells and compares it to the threshold FRACTTH1.


Attention:





- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SET

BTS [BASICS]) has an influence on the radio TCH traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]).a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all (non-reserved) TCHswhich are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like anyother TCH which is currently seized by a CS call.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currentlybusy due to GPRS traffic (PDCH) are considered as ‘idle’.- If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is setfor the DGRSTRGY parameter, as these TCHs are in any case immediately preemptedif a CS TCH request meets a TCH congestion situation.

- TCHs indicated as ‘reserved for GPRS’ (see parameter GMANPRESPRM in thePTPPKF object) are not considered in the calculation, i.e. they are treated as if theywere not configured! Thus, reserved GPRS TCHs in state ‘GPRS busy’ are not

considered (value above the fraction bar) and the value below the fraction bar is thenumber of TCHs in ‘unlocked/enabled’ minus the TCHs reserved for GPRS in the samestate.


If the traffic load in the cell drops below the threshold FRACTTH1, theBSC enables the load-dependent non-AMR decompression handover in the affected BTS by sending a SET ATTRIBUTE message with theappropriate indications to the BTS.

This indication starts the load-dependent non-AMR decompressionhandover decision process in the BTS.







HRACTAMRT1=6000,


unit: 0,01 %

range: 0..10000

default: 6000

Half Rate Activat ion AMR th reshold , this parameter is used for twodifferent features related to AMR calls

- Cell Load Dependent Activation of Half Rate for AMR Calls- load dependent AMR Compression Handover

As the functionality of these features is different in both cases, they are explained in separate points.

a) Cell Load Dependent Activation of Half Rate for AMR callsIn this case HRACTAMRT1 is only relevant if the parameter EHRACTAMR (see above ) is set to TRUE.

HRACTAMRT1 is the equivalent to the parameter HRACTT1 (seebelow) for AMR calls and defines a traffic load threshold which isevaluated for the forced speech version selection for incoming AMR TCH seizures. For this, the BSC compares HRACTAMRT1 to the

percentage of TCHs not available for CS allocation (in state busy,locked or shutting down) related to the number of TCHs configured in

- in the who le BTS (in case of standard cel l )- in the com plete area of a concentr ic cel l (see parameter CONCELL in command CREATE BTS [BASICS])- in the far area of an extended cel l (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS])

If the cell traffic load exceeds the percentage defined by

HRACTAMRT1, all incoming AMR calls or incoming AMR handovers,for which AMR HR is indicated as supported speech version, areforced to an AMR HR TCH. If the cell traffic load is below the

percentage defined by HRACTAMRT1, all incoming calls are forced to AMR FR. As the basic principle is exactly the same like for cell load dependent activation of HR for non-AMR calls please refer tothe parameters HRACTT1 (see below) and EHRACT (see above) for further details (e.g. concerning the traffic load calculation)).

b) Load dependent AMR compression handover On every expiry of the timer TRFCT (see SET BSC) the BSC checksthe traffic load in its cells and compares it to the threshold HRACTAMRT1.


Attention:





- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBTS [BASICS]) has an influence on the radio TCH traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]). a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all (non-reserved) TCHswhich are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like any

other TCH which is currently seized by a CS call.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currentlybusy due to GPRS traffic (PDCH) are considered as ‘idle’.- If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is setfor the DGRSTRGY parameter, as these TCHs are in any case immediately preemptedif a CS TCH request meets a TCH congestion situation.









If the traffic load in the cell exceeds the threshold HRACTAMRT1, theBSC enables the AMR compression handover in the affected BTS by sending a SET ATTRIBUTE message with the appropriateindications to the BTS. This indication starts the AMR compressionhandover decision process in the BTS.

Note: Interworking of ‘Service Dependent Channel Allocation’ withtraffic load calculationThe percentage calculation done for load dependent Compression/Decompression Handover is done referring only to theTRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea(primary/complementary). Please refer to the command SET BTS[SERVICE] for further explanations.

HRACTAMRT2=6000,


unit: 0,01 %

range: 0..10000

default: 6000

Half Rate Activat ion AMR th reshold , like the parameter HRACTAMRT1, this parameter is used for the features

- Cell Load Dependent Activation of Half Rate for AMR Calls- AMR Compression Handover

It has exactly the same function like the parameter HRACTAMRT1(see above) but affects different cell areas:

- in the inner area of a con centr ic cel l (see parameter CONCELL incommand CREATE BTS [BASICS])- in the near area of an extend ed cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS]).

HRACTAMRT2 is the equivalent to the parameter HRACTT2 (seebelow) for AMR calls and defines a traffic load threshold which isevaluated for the forced speech version selection for incoming AMR TCH seizures. For this, the BSC compares HRACTAMRT2 to the

percentage of TCHs not available for CS allocation (in state busy,locked or shutting down) related to the number of TCHs configured inthe cell areas mentioned above.

If the cell traffic load exceeds the percentage defined by HRACTAMRT2, all incoming AMR calls or incoming AMR handovers,

for which AMR HR is indicated as supported speech version, areforced to an AMR HR TCH. If the cell traffic load is below the

percentage defined by HRACTAMRT2, all incoming calls are forced to AMR FR. As the basic principle is exactly the same like for cell load dependent activation of HR for non-AMR calls please refer tothe parameters HRACTT1 (see below) and EHRACT (see above) for further details (e.g. concerning the traffic load calculation).

For AMR compression handover, the same principles apply asdescribed for parameter HRACTAMRT1.





HRACTT1=6000,


unit: 0,01 %

range: 0..10000

default: 6000

HR activat ion threshold 1 , this parameter defines a threshold whichis used by the following features a) Cell Load Dependent Activation of Half Rate and b) load-dependent AMR compression handover

a) Cell Load Dependent Activation of Half RateThis feature applies if the parameter EHRACT (see above) is set toTRUE. For this case HRACTT1 defines a traffic load threshold that is

evaluated for the forced speech version selection for incoming non- AMR TCH seizures. For this, the BSC compares HRACTT1 to the percentage of busy TCHs (related to the available TCHs) within- the cell (for standard cells)- the complete area (for concentric cells)- the far area (for extended cells).

For the feature CLDAHR the BSC calculates the traffic load asfollows

Attention:


- (*) The “no. of TCH not available for CS TCH allocation“ includes- TCHs in usage state „busy“ **- TCHs in usage state „locked“ or „shutting down“

- (**) A dual rate TCH (TCHF_HLF) in usage state „busy“ (i.e. both HR subslots busy)



- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBTS [BASICS]) has an influence on the radio TCH traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]). a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all (non-reserved) TCHswhich are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like anyother TCH which is currently seized by a CS call.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currentlybusy due to GPRS traffic (PDCH) are considered as ‘idle’.

- If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is setfor the DGRSTRGY parameter, as these TCHs are in any case immediately preemptedif a CS TCH request meets a TCH congestion situation.

- TCHs reserved for GPRS (see GMANPRES in CREATE PTPPKF) are totallyexcluded from the calculation, i.e. they are treated as if they were not configured. Thusneither the value above the fraction bar nor the one below the fraction bar includes the‘reserved’ TCHs for GPRS.


If the cell traffic load exceeds the percentage defined by HRACTT1,all incoming calls or incoming handovers, for which HR is indicated as supported speech version, are forced to a HR TCH. If the cell traffic load is below the percentage defined by HRACTT1, all incoming calls are forced to FR or EFR (depending on the capability and preference indicated in the ASSIGNMENT REQUEST or HANDOVER REQUEST message). For further details please refer tothe parameter EHRACT.

b) load dependent non-AMR compression handover The purpose of Compression handover is, in case of high TCH load,to transfer (E)FR calls with suitably good radio link quality to a HR TCH by an intracell handover in order to prevent TCH blocking by

providing additional TCH resources.

On every expiry of the timer TRFCT (see SET BSC) the BSC checksthe traffic load in its cells and compares it to the threshold HRACTAMRT1.

∗ 100Cell traffic load [%] =no. of TCH not available for CS TCH allocation*

no. of configured TCH






Attention:





- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBTS [BASICS]) has an influence on the radio TCH traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]).a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all (non-reserved) TCHswhich are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like anyother TCH which is currently seized by a CS call.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currentlybusy due to GPRS traffic (PDCH) are considered as ‘idle’.- If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is set

for the DGRSTRGY parameter, as these TCHs are in any case immediately preemptedif a CS TCH request meets a TCH congestion situation.



If the traffic load in the cell exceeds the threshold HRACTAMRT1, theBSC enables the AMR compression handover in the affected BTS by sending a SET ATTRIBUTE message with the appropriateindications to the BTS. This indication starts the AMR compressionhandover decision process in the BTS which has the task to hand

over all AMR calls currently occupying a FR TCH to a HR TCH if thequality (C/I) conditions of this call are good. The quality criteria for the

AMR compression handover are defined by the C/I thresholdsHOTHAMRCDL and HOTHAMRCUL (see SET HAND [BASICS]).

Note: Interworking of ‘Service Dependent Channel Allocation’ withtraffic load calculationThe percentage calculation done for load dependent Compression/Decompression Handover is done referring only to theTRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea(primary/complementary). Please refer to the command SET BTS[SERVICE] for further explanations.

HRACTT2=1000,


unit: 0,01 %

range: 0..10000

default: 6000

HR activat ion threshold 2 , this parameter is only relevant for concentric cells or extended cells and defines thresholds for thefeatures listed under HRACTT1 (see above) for non-AMR calls in

- the inner area (for concentric cells)- the near area (for extended cells).

The thresholds are used in exact correspondence with theexplanations provided for HRACTT1.







please refer to the GSM-tables on the following pages.- If the feature frequencies of two different frequency bands are used in the cell (dual band concentric cells, or dual band standard cells,refer to parameters CELLTYP and CONCELL, see above), both the

parameters MSTXPMAXGSM and MSTXPMAXDCS must be set, asboth bands are used within the cell. This information is evaluated during call setup and for the complete-to-inner intracell handover decision.

MSTXPMAXGSM=5,


unit: see tables below

range: 2..15

default: 5

Maximum tr ansmiss ion pow er for GSM 900 , this parameter defines the maximum transmission level a MS is allowed to use on adedicated channel (TCH and SDCCH) in the serving cell. This

parameter is relevant if the cell contains frequencies of the GSM900 band.

Value ranges:GSM900: 2..15, default: 2=39dBm (step size -2dBm)GSMR: 2..15, default: 2=39dBm (step size -2dBm)

For further information please refer to the explanation provided for the parameter MSTXPMAXDCS.

Note: If the feature frequencies of two different frequency bands areused in the cell (dual band concentric cells, or dual band standard cells, refer to parameters CELLTYP and CONCELL, see above), both

the parameters MSTXPMAXGSM and MSTXPMAXDCS must be set,as both bands are used within the cell. This information is evaluated during call setup and for the complete-to-inner intracell handover decision.

MSTXPMAXPCS=0,



range: 0..15, 30, 31

default: 0

Maximum tr ansmiss ion pow er for PCS 1900 , this parameter defines the maximum transmission level a MS is allowed to use on adedicated channel (TCH and SDCCH) in the serving cell. This

parameter is relevant if the cell contains frequencies of the PCS 1900 band.

Value range:PCS1900: 0..15,30,31(30=33dBm, 31=32dBm)

default: 0=30dBm (step size -2dBm),

For further information please refer to the explanation provided for

the parameter MSTXPMAXDCS.Note: - If the feature frequencies of two different frequency bands areused in the cell (dual band concentric cells, or dual band standard cells, refer to parameters CELLTYP and CONCELL, see above), boththe parameters MSTXPMAXGSM and MSTXPMAXPCS must be set,as both bands are used within the cell. This information is evaluated during call setup and for the complete-to-inner intracell handover decision.





Mobi le stat ion Pow er Classes

Power

class

GSM 400 & GSM 900 &

GSM 850

DCS 1800 PCS 1900

Nominal Maximum

output power

Nominal Maximum

output power

Nominal Maximum

output power

1 - - - - - - 1 W (30 dBm) 1 W (30 dBm)

2 8 W (39 dBm) 0,25 W (24 dBm) 0,25 W (24 dBm)

3 5 W (37 dBm) 4 W (36 dBm) 2 W (33 dBm)

4 2 W (33 dBm)

5 0,8 W (29 dBm)

from GSM 05.05, MS Power classes

Power Control Levels

GSM 400,GSM 900and GSM 850 DCS 1800 PCS 1900

Power

control

level

Nominal Output

power (dBm)

Power

control

level

Nominal Output

power (dBm)

Power

Control Level

Nominal Output

Power (dBm)

0..2 39 29 36 22-29 Reserved

3 37 30 34 30 33

4 35 31 32 31 32

5 33 0 30 0 30

6 31 1 28 1 28

7 29 2 26 2 26

8 27 3 24 3 24

9 25 4 22 4 22

10 23 5 20 5 20

11 21 6 18 6 18

12 19 7 16 7 16

13 17 8 14 8 14

14 15 9 12 9 12

15 13 10 10 10 10

16 11 11 8 11 8

17 9 12 6 12 6

18 7 13 4 13 4

19-31 5 14 2 14 2

15-28 0 15 0

16-21 Reserved

from GSM 05.05, MS Output power tables





NMULBAC=0,


range: 0..3

default: 0


Numb er of mult i band cel ls , this parameter is relevant for dualband configurations and specifies in which way the MS shall report theneighbour cells of the frequency bands used in the serving and neighbouring cells.Possible values:0 - Normal reporting of the six strongest cells, with known and

allowed NCC part of BSIC, irrespective of the band used.1 - The MS shall report the strongest cell, with known and allowed NCC part of BSIC, in each of the frequency bands in the BA list,excluding the frequency band of the serving cell. The remaining

positions in the measurement report shall be used for reporting of cells in the band of the serving cell. If there are still remaining

positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used.2 - The MS shall report the two strongest cells, with known and allowed NCC part of BSIC, in each of the frequency bands in the BAlist, excluding the frequency band of the serving cell. The remaining


positions, these shall be used to report the next strongest identified

cells in the other bands irrespective of the band used.3 - The MS shall report the three strongest cells, with known and allowed NCC part of BSIC, in each of the frequency bands in the BAlist, excluding the frequency band of the serving cell. The remaining


positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used.

PCCCHLDI=255,


unit: 1s

range: 0..255

default: 255

Period of CCCH load indicat ion , this value indicates the timedistance between two CCCH LOAD INDICATION messages sent tothe BSC (see also parameters RACHBT and RACHLAS). The CCCH LOAD INDICATION is only sent to the BSC if the CCCH load threshold TCCCHLDI (parameter description see below) is reached.The value PCCCHLDI=0 indicates that the CCCH LOAD

INDICATION is not repeated but sent only once.Note: In BR7.0 the parameter PCCCHLDI is additionally used toenable or disable a paging overload prevention functionality.If PCCCHLDI is not set to ‘0’, a BTS paging overload situation (i.e.the BTS has sent an OVERLOAD message to the BSC, thusindicating that one PAGING COMMAND could not be placed in a

paging queue and had to be discarded), triggers the following mechanism: as long as the PCH load is still above the threshold defined by the parameter TCCCHLDI (see below), the BTS discardsall PAGING COMMANDs that contain an IMSI. This is done becausean IMSI needs twice the space than a TMSI in the BTS paging queues and is thus an attempt to effectively prevent further overload situations by removing those messages that have the biggest impact on the load in the PCH queues.

Attention: if TMSI Reallocation is disabled in the network (i.e. paging is exclusively done with the IMSI), it is recommended to disable thisfunctionality by setting PCCCHLDI=0 (as this would lead to too many discarding of pagings) and to leave the PCH overload handling to theBSC (see parameter BTSOVLH in command SET BSC [BASICS]).





PENTIME=0,


unit: 20s

range: 0..31

31= TEMPOFF ignored

default: 0


GSM 03.22

Penalty t ime , sets the duration for which the temporary offset isapplied. This parameter, contained in the IE ‘SI 4 Rest Octets’ on theBCCH (SYSTEM INFORMATION TYPE 4), is one of the necessary input values for the calculation of C2. This parameter only has to beset if CRESPARI is set to ‘1’. For further details please refer to the

parameter CRESPARI.

Note: The effective penalty time value is (20s + PENTIME*20s)

PLMNP=255,


range: 0..255

default: 255


GSM 04.08

GSM 02.11

GSM 05.08

PLMN permitted , this parameter corresponds to the IE ‘NCCPermitted’. Only those neighbour cells whose NCC (please see also

parameter BSIC) is indicated as ‘permitted’ in the ‘NCC permitted’ IE may be included in the MEASUREMENT REPORTs in busy mode.Thus only to these cells a handover is actually possible! In other words, if a specific cell has two cells using the same BCCH frequency or a directly adjacent BCCH frequency (whose “side-ramp” the MS might misinterpret as the signal of the allowed BCCH frequency due to co-channel interference) in the geographical neighbourhood, the MS will only report the one with the correct NCC (unless the interference leads to an unsuccessful BSIC decoding, inthis case the MS cannot report anything).The decimal value entered for PLMNP is sent to the MS as a binary

8-bit string “ NCC permitted “ on the BCCH (SYSTEM INFORMATION TYPE 2, together with the list of the allowed neighbour cell BCCH frequencies) or on the SACCH (SYSTEM INFORMATION TYPE 6). The 8-bit string is used as a ‘bit-map’;every ‘1’ bit indicates that the NCC corresponding to the bit position isallowed.

Example: PLMNP=82 Dec corresponds to the to binary value 1010010.

“NCC permitted” 0 1 0 1 0 0 1 0

allowed NCCs 7 6 5 4 3 2 1 0

Thus PLMNP=82 means that the only neighbour cells with the NCCs6, 4 and 1 will be reported.

Note: PLMNP has no influence on cell reselection, i.e. the MS might

attempt a cell reselection to a cell with an NCC which is not included in “NCC Permitted”. “NCC Permitted” is included in the SYSINFO 2 only in order to inform the MS early enough which cells are allowed for measurement reporting when it switches to ‘busy’ mode.

PNOFACCH=5,


unit: 0.5 sec

range: 2..10

2=1.0 sec

3=1.5 sec

...

10=5.0 sec

<NULL>

default: 5= 2.5 sec

Period for Noti f icat ion on FACCH , this parameter specifies period (repetition rate) for the FACCH notification for a given ASCI call.

PUREBBSIG44CONF parameter cancel led in BR8.0





QSRHC=NEVER,


range: UMDB98 UMDB94

UMDB90 UMDB86

UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66OMDB62 OMDB58

OMDB54 NEVER

default: NEVER

qSearchC , this parameter defines a threshold condition whichenables the searching for 3G cells with regard to handover (MS inbusy mode); in other words, if the threshold condition defined by QSRHC is fulfilled for the serving (2G) cell, then 3G cell s shall beconsidered for handover neighbour cell reporting.

The parameter values have to be considered as follows:- The values OMDBxx (=o ver m inus xxdB ) define the threshold asfollows: When the level of the neighbour cell has exceeded the “xx dB” threshold value, the neighbour cell shall be considered for cell selection/reselection.- The values UMDBxx (=u nder m inus xxdB ) define the threshold asfollows: When the level of the neighbour cell has dropp ed below the“xx dB” threshold value, the neighbour cell shall be considered for cell selection/reselection.- The value ALWAYS means the Mobile shall always consider 3Gneighbours cells for cell selection/reselection.- The value NEVER means the Mobile shall not consider 3Gneighbours cells for cell selection/reselection at all.

QSRHCINI=QSEARCHI,


range: QSEARCHI, ALWAYS

default: QSEARCHI

qSearchCini t ia l , this parameter indicates the initial value to be used before the MS receives QSRHC (Qsearch_c) in the measurement

information message on the SACCH.If the value QSEARCHI is selected, the actual threshold is defined by the parameter QSRHI (see below).

QSRHI=NEVER,



UMDB90 UMDB86

UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66

OMDB62 OMDB58

OMDB54 NEVER

default: NEVER

qSearchI , this parameter defines a threshold condition whichenables the searching for 3G cells with regard to cell selection/reselection (in idle mode); in other words, if the threshold condition defined by QSRHI is fulfilled for the serving 2G cell, then3G cells shall be considered for cell selection/reselection. QSRHI defines the default value of the attribute QSRHCINI (see above).

The parameter values have to be considered as described for the parameter QSRHC (see above).

RACHBT=109,


unit: -1dBm

range: 0..127

default: 109

RACH busy thresho ld , defines a threshold for the signal level on theRACH. The general purpose of this parameter is to define a minimumlevel criterion a received RACH signal must fulfil to be regarded as areal RACH access. To understand the mechanism better, it isrequired to describe the functional sequence of RACH signal evaluation in alittle more detail:

Functional sequence of RACH signal evaluation:

The BTS evaluates the RACH signals in two main stages:1) The Um layer 1 SW subsystem of the BTS continuously observesthe signals received on the RACH slots. As even without any MSRACH access there are always at least some ‘noise’ signals on theRACH, the task of the layer 1 SW subsystem is to evaluate thereceived signal with respect to specific criteria, e.g. it measures thereceive level and checks if it exceeds a hardcoded minimum

threshold (RSSI level, not equal to RACHBT!), measures the signal-to-noise ratio (SNIR), evaluates a soft decision criterion (SOVA), triesto decode the training sequence, checks the Convolution Code,checks for block CRC errors and measures the delay of the RACH burst to determine the MS-BTS distance. Together with the decoded signal itself, the results of these checks are forwarded in form of a set of flags to the BTS call handling SW subsystem. These flags indicatethe results of the BTS layer 1 evaluation (the value ‘1’ indicates:criterion not fulfilled) and are the basis for the BTS call handling SW subsystem to determine whether the received signal can really beregarded as a successful RACH access or not. On the basis of theflags received, the BTS call handling subsystem classifies the





RDLNKTO=4,


range: 0..15

0 = counter value 4

15 = counter value 64

default: 4


GSM 04.08

Radio l ink timeout , the value entered for this parameter determinesthe value of the parameter RADIO_LINK_TIMEOUT which is sent onthe BCCH (SYSTEM INFORMATION TYPE 3) or on the SACCH (SYSTEM INFORMATION TYPE 6) in the IE ‘Cell Options’. It is used by the MS to calculate the maximum value of the radio link counter (‘S’ counter) in the MS which is needed to detect a radio link failure inthe downlink (a similar counter is realized in the BTS for the uplink,

see parameter RDLNKTBS (SET PWRC)). The maximum value S0 of the S-counter in the MS is calculated as follows:

S0 = 4 + 4∗ RDLNKTO

Its range is 4..64. The ‘radio link timeout’ value is the start point for the ‘S’ counter in the MS which is in effect if the mobile is in‘dedicated’ (or ‘busy’) mode. Unsuccessful decoding of SACCH messages by the transceiver lead to a decrease of the ‘S’ counter by 1, successful decoding to an increase by 2. If the ‘S’ counter reaches0, the MS regards the dedicated radio connection as failed and stopsany further transmission on the dedicated channel. In such asituation, of course, also the BTS cannot correctly decode any uplink SACCH frames anymore (because the MS has stopped transmitting them) and it is just a question of time when the radio link counter inthe BTS (see RDLNKTBS) reaches ‘0’. In this case a CONNECTION FAILURE INDICATION (BTS->BSC) is sent and indicates the loss of the dedicated connection (call drop).Notes:- Please note that, starting from BR8.0, this parameter can also beseparately managed for different service types using the parametersSGxxPCPAR (see command SET PWRC).- If ‘Call Re-Establishment’ (see parameter CREALL) is enabled a low value of radio link time-out increases the number of call reestablishments because a decrease of RDLNKTO may lead to anearlier declaration of radio link failures.

REPTYP=NORMAL,


range: NORMAL, ENHANCED

default: NORMAL

Report type , this parameter indicates to the mobile to use theENHANCED MEASUREMENT REPORT or MEASUREMENT REPORT messages for measurements reporting.

Enhanced measurement reporting is only supported by special mobiles.

Note: ENHANCED MEASUREMENT REPORT is not to be mixed upwith EXTENDED MEASUREMENT REPORT, although for both thesame abbreviation (EMR) is used.

RXLEVAMI=6,


unit: 1 dB

range: 0..63

0 = less than -110dBm

1 = -110dBm to -109dBm

2 = -109dBm to -108dBm

...

62 = -49dBm to -48dBm

63 = greater than -48dBm

default: 6


GSM 04.08

GSM 03.22

Minimum received level at the MS required for access to thenetwork on the RACH. It is used together with other parameters todefine the path loss criterion C1 for cell selection and reselection(see parameter CELLRESH). Setting RXLEVAMI to a high valuemeans that only those MSs attempt an access to the cell which are ina location with good coverage conditions. Thus the number of handover requests may be reduced. This parameter is sent on theBCCH (SYSTEM INFORMATION TYPE 3 and 4) in the IE ‘CellSelection Parameters’.

Note: If a PBCCH is configured (see parameter CREATE CHAN for TCH with GDCH=PBCCH), an equivalent parameter is broadcast onthe PBCCH for GPRS mobiles to allow a separate management of cell selection and cell reselection for GPRS- and non-GPRS-mobiles.This parameter is GRXLAMI (see command CREATE PTPPKF).





SDCCHCONGTH=70,


unit: 1 %

range: 70..100

default: 70

SDCCH cong estion threshold , this parameter is associated to thefeature “Smooth channel modification” (for further details please seecommand CREATE CHAN for TCH/SD) and defines the SDCCH load threshold which causes the move of a TCH/SD from theTCH/SD_POOL to the SDCCH_BACKUP_POOL and vice versa.SDCCHCONGTH determines the cell-specific trigger threshold for the percentage of busy SDCCHs which initiates the moving of a

TCH/SD from the TCH/SD_POOL (see parameter setting CHPOOLTYP=TCHSDPOOL in command CREATE CHAN) to theSDCCH_BACKUP_POOL.The percentage of busy SDCCHs is calculated as follows:

* Note: the calculation always considers the total amount of SDCCH subslots from both

the SDCCH_POOL and the SDCCH_BACKUP_POOL !

Whenever the BSC receives a seizure request for an SDCCH theBSC calculates the SDCCH traffic load and compares it to the to thethreshold SDCCHCONGTH. If the SDCCH traffic load exceeds

SDCCHCONGTH, the BSC moves the TCH/SD from theTCH/SD_POOL to the SDCCH_BACKUP_POOL and thus extendsthe SDCCH capacity by 8 additional SDCCH subslots. The TCH/SDwith the best quality (determined from the idle TCH measurements,see parameter INTCLASS in command SET BTS [INTERF]) ismoved first. The following flow diagram shows the exact process that is triggered by an SDCCH request:

∗ 100SDCCH traffic load [%] =no. of busy SDCCH subslots*

no. of SDCCH subslots in unlocked/enabled*





The parameter SDCCHCONGTH is also evaluated during SDCCH release in order to decide whether a TCH/SD currently in theSDCCH_BACKUP_POOL can be moved back to theTCH/SD_POOL. For this reason the BSC calculates the current SDCCH traffic load and compares it to SDCCHCONGTH.Attention: the calculation performed during the SDCCH release

procedure is different from the formula shown above! For further details please refer to the descriptions provided for the parameter

TGUARDTCHSD.Note: SDCCHCONGTH has no relevance for the SDCCH allocation

process itself, i.e. if the BSC receives an SDCCH request, it does not move a TCH/SD to the SDCCH_BACKUP_POOL to satisfy thisrequest! Instead, for all incoming SDCCH requests the BSC first triesto allocate an SDCCH subslot from the SDCCH_POOL (i.e. a subslot from the non-TCH/SD SDCCHs), no matter whether additional SDCCH subslots are available in the SDCCH_BACKUP_POOL or not.

SYSID=BB900,


range: BB900 (GSM baseband)

DCS1800

F2ONLY900 (GSM ext. bd.)EXT900 (GSM mixed band)

GSMR (railway GSM),

PCS1900

GSMDCS

GSM850

GSM850PCS


System Indicator , indicates the frequency band used by the traffic channels.If F2ONLY900 is selected only phase2 mobiles can be used, phase1mobiles are not supported.If EXT900 is selected the GSM base band is still usable for phase1mobiles, the extension band, however, can only be used for traffic

purposes by phase2 mobiles.

The values GSMDCS and GSM850PCS must be set if the cell is tobe configured with TRX frequencies of two different frequency bands(dual band concentric cells, or dual band standard cells, refer to

parameters CELLTYP and CONCELL, see above).

TAADJ=0,


unit: 100ns

range: 0..100, <NULL>

default: 0 (BTS SW ≥ BR7.0)

<NULL> (BTS SW < BR7.0)

Timing advance adjust , this parameter allows to enter a correctionterm for the BTSE internal timing advance measurements (similar tothe parameter RXLECADJ, see command CREATE RFLOOP). Theidea of this correction term is to consider the propagation delay onthe BTSE internal signal path for the determination of the real timing advance value. This is achieved by simply adding the TAADJ valueto the measured timing advance value – the resulting timing advance

value is then more accurate than just the measured one. To set this parameter correctly, the BTSE internal propagation delay must beknown, i.e. suitable measurements must have been made before. It isup to the operator to make sure that the parameter value is set incorrespondence with the real propagation delay conditions in theBTSE.





the description of this parameter.

TDDMURREP=0,


range: 0..3

default: 0

TDD mult iRAT report ing , this parameter indicates the number TDDcells that shall be included in the MEASUREMENT REPORT messages.

TDDQO =DB00,

object: BTS [BASICS]range: ALWAYS MDB28

MDB24 MDB20

MDB16 MDB12

MDB08 MDB04

DB00 DB04 DB08

DB12 DB16 DB20

DB24 DB28

default: DB00

TDD Q Offset , this parameter relates multiRAT mobiles; it indicatesan offset which is applied to the carrier level of the TDD serving cell.

TDDREPO =DB00,


range: DB00 DB06 DB12

DB18 DB24 DB30

DB36 DB42

default: DB00

TDD Report ing Offset , this parameter defines a fixed offset to beapplied to all reported TDD 3G neighbour cells.

The parameter values express a value in dBm

DBxx = xxdBm (e.g. DB10 = 10dBm)

TDDREPTH=RXLEV_00,


range: RXLEV_00, RXLEV_06,

RXLEV_12, RXLEV_18,

RXLEV_24, RXLEV_30,

RXLEV_36, NEVER

default: RXLEV_00

FDD Report ing Thresh old , this parameter defines threshold whichTDD 3G cell has to exceed in order to be reported in Enhanced Measurement Report.

The parameter values express an RXLEVvalue in dB

RXLEV_xx = xxdB (e.g. RXLEV_06 = -115 dBm + 6dB = -109dBm)??

TEMPOFF=1,


unit: 10dB

range: 0..7, 7=∞

default: 1


GSM 03.22

Temporary offset . This parameter, contained in the IE ‘SI 4 RestOctets’ on the BCCH (SYSTEM INFORMATION TYPE 4), is one of the necessary input values for the calculation of C2. It applies anegative offset to C2 for the duration of the penalty time. This

parameter only has to be set if CRESPARI is set to ‘1’. For further details please refer to the parameter CRESPARI.

TXDIVTSEXCPT=NONE,


range: NONE, SCH

BCCHTRXTS0,

BCCHTRX

default: NONE

TX diversi ty t ime shif t except , this parameter parameter allows toconfigure time slots or logical channels which are excluded from being sent in TX Diversity Time Shift mode.





While in releases < BR8.0, admission control was only based on‘hard blocking’ (which means that a TCH request is rejected only noTCH is available in the BTS), in releases starting from BR8.0 admission control (i.e. rejection of new TCH requests) can be alsobased on ‘soft blocking’ if the site configuration features DMA servicelayers.

The task of the feature DMA AC is to monitor both the current EFLand the current BQP in the cell and to consider these two factors

during the TCH allocation: if particular requirements for BQP and EFLare not fulfilled (e.g. if the BQP exceeds a configurable threshold for a particular EFL, see further details below), new call requests arerejected to keep the interference low enough to ensure an acceptablespeech quality for the already established calls. The rejection of anew call request based on the BQP criterion is called ‘soft blocking’.

Due to the fact that DMA is only applicable to ‘speech only’ servicelayers (AMR, non-AMR), also DMA Admission Ccontrol (DMA AC) isonly applicable to these service layers.

Remark: The evaluation of the ‘soft blocking’ criteria (and thus therejection of TCH requests in case these criteria are fulfilled) is only

performed for call setups in the serving cell. All types of incoming inter-cell handovers are served by idle TCHs (if available) even if theDMA layers of the cell are soft-blocked for call setup.

Detailed Functional Descr ipt ion o f DMA Admiss ion Control

1) DMA Admission Control Decision AlgorithmThe BTS continuously measures the FER of the ongoing calls and calculates the current EFL and BQP figures for each configured DMAlayer / CFHSY (see command CREATE CFHSY - one CFHSY can becreated per frequency band). As during the BTS alignment all

parameter values relevant for DMA AC are transmitted to the BTS,the BTS can (and actually does) check the DMA AC soft-blocking criterion using the AC decision algorithm.

The determine the value of the ‘soft blocking flag’, the AC decisionalgorithm in the BTS checks the EFL and BQP conditions in a way asindicated in the table below:

Explanation:- If the EFL is lower than or equal to the configurable maximum EFLthreshold ‘ min EFL_DMA ’ (see parameter ACMINEFLDMA ), the new call setup on the DMA layer is admitted in any case.- If the EFL is higher than the configurable maximum EFL threshold ‘ max EFL_DMA ’ (see parameter ACMAXEFLDMA ), the new call setup on the DMA layer is rejected in any case.





ACLNKTYP=UL_SAMPLES_ONLY,

object: BTS [ADM]

range: uLAndDLSamplesSeparately,

uLSamplesOnly,

uLAndDLSamplesCommonly,

<NULL>

default: ulSamplesOnly

Admiss ion Contro l l ink type , this parameter is only relevant if the parameter EAC is set to TRUE and it defines the type of samples tobe collected for the BQP determination and the way they are used for the estimation of BQP:

• acLinkType = 0 -> ACLNKTYP = uLAndDLSamplesSeparately UL and DL samples are collected and separately evaluated

• acLinkType = 1 -> ACLNKTYP = uLSamplesOnly only UL samples are collected and evaluated

• acLinkType = 2 -> ACLNKTYP = uLAndDLSamplesCommonly UL and DL samples shall be collected, merged and commonly evaluated

For further details please refer to the feature description above the parameter listing.

ACMAXEFLDMA=PER_50,

object: BTS [ADM]

range: PER_10, PER_15, PER_20,

PER_25, …

PER_95, PER_100

default: PER_50

Admiss ion Contro l maximum EFL on DMA , this parameter is only relevant if the parameter EAC is set to TRUE and it specifies, in

percent, the maximum EFL on the DMA layer of the cell.


ACMINEFLDMA=PER_10,

object: BTS [ADM]

range: PER_5, PER_10, PER_15,

…

PER_45, PER_50,

default: PER_10

Admiss ion Contro l min imum EFL on DMA, this parameter is only relevant if the parameter EAC is set to TRUE and it specifies, in

percent, the minimum EFL on the DMA layer of the cell.


ACPER=SACCH_120,

object: BTS [ADM]

range: SACCH_020, SACCH_024,

SACCH_028, SACCH_032,

SACCH_036, SACCH_040

... SACCH_400

default: SACCH_120

Admiss ion Contro l per iod , this parameter is only relevant if the parameter EAC is set to TRUE and it defines the sending period for the RADIO LINK ADMISSION CONTROL message (i.e. the timebetween two consecutive transmissions) in SACCH multiframes(1 SACCH multiframe = 480ms).


EAC=FALSE,

object: BTS [ADM]

range: TRUE, FALSE

default: FALSE

Enable admissio n control , this parameter determines whether thefeature ‘Admission Control’ for Dynamic MAIO Allocation (DMA) isenabled in the cell.

Notes:- This parameter can only be set to TRUE in a particular BTS if DMAwas enabled in the associated BTS and CBTS objects before.In the DBAEM, this parameter is listed within a SET BTS command behind the SET CBTS command that enables DMA (which itself canonly be enabled if all associated objects (CFHSY, TRX, CHAN etc.)have been consistently and conclusively created in the databasebefore.

Thus, if DMA and DMA AC are to be enabled, the DBAEM command sequence is the following (for a particular BTS):

CREATE CHAN......SET BTS:ENDMA=TRUE...SET CBTS:ENDMA=TRUE...SET BTS:EAC=TRUE





Setting the cell specific attributes for the CCCH:

< All attribute values set by this command (except for NY1) haveeffects on the SYSTEM INFORMATION messages on the BCCH. >

SET BTS [CCCH]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BTS packages’ were moved below the object BTS and

appear in the DBAEM in the CREATE BTS command. The logical group “[CCCH]” is normally only used on the LMT but was used here toallow a more useful grouping of the commands .

NAME=BTSM:0/BTS:0, Object path name .

MAXRETR=FOUR,

object: BTS [CCCH]

range: ONE, TWO, FOUR,

SEVEN

default: FOUR


GSM 05.08

Maximum number of re t ransmiss ions , this parameter defines themaximum number of retransmission attempts the MS can perform onthe RACH if the previous attempts have been unsuccessful. To request a dedicated control channel (normally an SDCCH) from the network,the MS performs a RACH access by sending a CHANNEL REQUEST message to the BSS via the RACH. In the successful case, the MSreceives an IMMEDIATE ASSIGNMENT COMMAND via the AGCH.The MS regards an access attempt unsuccessful when it has neither received an IMMEDIATE ASSIGNMENT COMMAND or - if no SDCCH is available in the cell - an IMMEDIATE ASSIGNMENT REJECT via

the AGCH before the time defined by the parameter NSLOTST (seebelow) has expired. The value of MAXRETR determines how often theMS may repeat its access attempt. If after MAXRETR retransmissionsthe MS still did not receive any IMMEDIATE ASSIGNMENT COMMAND or IMMEDIATE ASSIGNMENT REJECT, it starts cell reselection to a suitable neighbour cell. To avoid a ‘ping-pong’ cell reselection, the MS must obey a waiting time of 5 seconds before it can return to the original cell with a further cell reselection procedure, if it has previously left it due to unsuccessful RACH access attempts..

A RACH access without subsequent receipt of an IMMEDIATE ASSIGNMENT COMMAND or REJECT message can occur due to:- RACH collisions (this happens when several MS access the sameRACH at the same time - in this case the BTS cannot decode theCHANNEL REQUEST(s) and discards the messages)

- radio interface problems (loss of messages)- delayed IMMEDIATE ASSIGNMENT sending due to Abis via satellitelink (with the correspondingly high propagation delay on Abis)- overload handling (which features the discarding of CHANNELREQUIRED messages and thus the discarding of the embedded CHANNEL REQUEST, see associated section in the appendix)

The value of MAXRETR is sent on the BCCH (SYSTEM INFORMATION TYPE 1, 2, 3 and 4) in the IE ‘RACH ControlParameters’

Notes:- For the MS it does make a difference, whether it receives anIMMEDIATE ASSIGNMENT REJECT as response to a transmitted CHANNEL REQUEST or whether it does not receive any response at all. While in the latter case, as described above, the MS will leave thecell after MAXRETR access attempts without receipt of an MMEDIATE

ASSIGNMENT, in case of IMMEDIATE ASSIGNMENT REJECT theMS just has to obey a waiting time before it may attempt the next RACH access attempt (see parameter T3122 in command SET BSC [BASICS]) and will in any case stay in the cell.- The level of MAXRETR has an impact on the RACH load and thespeed of MS access to a cell. In case of RACH and AGCH overload adecrease of MAXRETR can be used to decreases the number of access attempts of the MSs and therefore the RACH overload without barring any access classes (see parameter NALLWACC in command SET BTS [OPTIONS]). A high value of MAXRETR will speed up the





access and thus increase the RACH and AGCH load, a low value will delay the access and may result in cell reselection and therefore in adelay or unsuccessful cell access if no other cell is available.

MSTXPMAXCH=5,

object: BTS [CCCH]

range: 0..31

default: 5

Reference: GSM 04.08GSM 05.08

MS maximum transmi t po wer for CCCH , indicates the maximumtransmit power level a MS is allowed to use when accessing a cell onthe ‘random access channel’ (RACH) and before receiving the first ‘Power Command’ (see parameter MSTXPMAXGSM (resp.MSTXPMAXDCS or MSTXPMAXPCS) in command

CREATE BTS [BASICS]) during a communication on a DCCH or TCH (after an IMMEDIATE ASSIGNMENT). This parameter is sent on theBCCH (SYSTEM INFORMATION TYPE 3 and Type4) in the IE ‘CellSelection Parameters’. This parameter is also used (together withother parameters) to define the path loss criterion C1 (see parameter CELLRESH in command CREATE BTS [BASICS]). The value of MSTXPMAXCH should be adapted to the size of the radio cell: thesmaller the cell the lower the allowed transmit power should be in order to minimize channel interference in adjacent cells and to save MSbattery. In a first step, MSTXPMAXCH may be set to the same valueas MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS)(CREATE BTS [BASICS]) to guarantee that a MS, which is accepted on the RACH, is able to communicate with the network also on thededicated channel.

Notes:- If a PBCCH is configured (see parameter CREATE CHAN for TCH with GDCH=PBCCH), an equivalent parameter is broadcast on thePBCCH for GPRS mobiles to allow a separate management of cell selection and cell reselection for GPRS- and non-GPRS-mobiles. This

parameter is MSTXPMAC (see command CREATE PTPPKF).- Increasing the entered value decreases the allowed transmit power on the RACH and thus the maximum allowed distance between MSand BTS for RACH access! (For details regarding the power classesand power control levels please refer to the parameter MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS)(CREATE BTS [BASICS])).

NBLKACGR=1,

object: BTS [CCCH]range: 0..7

default: 1


GSM 05.02


Number of b locks for access grant , specifies the number of CCCH blocks to be reserved in each configured CCCH timeslot for the Access

Grant Channel (AGCH) during a period of 51 TDMA frames, i.e. onemultiframe. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) in the IE ‘Control Channel Description’.

Paging Channel (PCH) and AGCH share the same TDMA framemapping when combined onto a basic physical channel. The channelsare shared on a block by block basis and the information within eachblock - when de-interleaved and decoded - allows a MS to determinewhether the CCCH block is used as PCH or AGCH. This means that the number of available CCCH blocks, which is determined by thecreated CCCH configuration (e.g. channel type MAINBCCH provides 9CCCH blocks, while MBCCHC provides only 3 CCCH blocks) isshared between PCHs and AGCHs. Up to BR7.0 in the BTS thetransmission of PAGING REQUESTs via the PCH was strictly priorized against the transmission of IMMEDIATE ASSIGNMENTs via the

AGCH, i.e. if there were pagings in the BTS paging queues the would use the available CCCH blocks for paging first . To guarantee a basic throughput of AGCH messages (no matter how high the paging load is), NBLKACGR can be set to a value > 0 to reserve a defined number of CCCHs exclusively for AGCH. These reserved CCCH blocks arenever used as PCH but exclusively as AGCH, thus guaranteeing abasic network access even in case of high paging traffic.

Starting from BR8.0 an improved CCCH management meachnism wasimplemented which features a priorization of AGCH messages over PCH messages in the ‘shared’ CCCH blocks under particular load conditions, i.e. the mechanism checks the filling state of the AGCH queue and the ‘age’ of the enqueued messages in order to determine





whether a CCCH block should be ‘preempted’ for AGCH. For further details, please refer to the section ‘BTS Overload Handling’ in theappendix of this document.

For each BCCH/CCCH timeslot the BTS provides 1 AGCH queue with16 places each (1 place for 1 IMMEDIATE ASSIGNMENT COMMANDor IMMEDIATE ASSIGNMENT REJECT). Setting NBLKACGR > 0 canincrease the guaranteed AGCH throughput and thus lead to a quicker emptying of the AGCH queue, but is also reduces the number of

CCCH blocks available for paging by the selected value and thus alsoreduces the number of paging groups (see also NFRAMEPG) and

paging queues in the BTS. In correspondence with the GSM specification, the blocks that are reserved for AGCH are located inadjacent CCCH blocks at a specific position within theBCCH/CCCHmultiframes (235ms). This means that NBLKACGR should not be set to a too high values, as this would - in periods of high

paging load - have the effect that, due to the resulting reduction of paging groups and the priority of paging in the non-reserved CCCH blocks, paging is performed mainly in the non-reserved CCCH blocks,while AGCH messages can only be transmitted on the reserved blocks. As these are grouped at adjacent positions within theBCCH/CCCHmultiframes (235ms), the burst-wise receipt of more than4 IMMEDIATE ASSIGNMENT messages within a very short time

period could result in an overflow of the BTS AGCH queue and thus to AGCH overload (see also the ‘Overload’ section in the appendix of thisdocument), as the AGCH queue can only be emptied every 235ms.

Notes:- According to a BR7.0 Operator Hint, NBLKACGR must be set to avalue >0 to avoid particular alarm messages from the BTSEs.In any case, the default value NBLKACGR=1 is a recommended setting to guarantee AGCH traffic also in hours of high PCH traffic.- NBLKACGR must be set as follows

a) NBLKACGR ≤ 2 if a BCBCH is created in the cell b) NBLKACGR > 0 if a SCBCH is created in the cell (see CREATE CHAN)- The setting of NBLKACGR refers to each CCCH timeslot created in acell. In other words, if in a cell two CCCHs are created (e.g. one

MAINBCCH on timeslot 0 and an additional CCCH on timeslot 2 of theBCCH TRX (with 9 CCCH blocks each), in both CCCHs the BTSreserves one block for AGCH. E.g. with a setting of NBLKACGR=2 inthis example, 2 blocks will be reserved for AGCH, while the 7 remaining ones remain ‘shared’ for PCH and AGCH in either CCCH.





NY1=30,

object: BTS [CCCH]

range: 1-254

default: 30



NY1 , indicates the maxim um num ber of repeti t ions of PHYSICAL

INFORMATION messages from the network to the MS during anasynchronous handover. After sending of the first HANDOVER

ACCESS burst the MS waits to receive the PHYSICAL INFORMATION message from the BTS. The PHYS INFO message contains the actual timing advance which the BTS derives from the time delay of thehandover access burst. After receipt of the PHYS INFO the MS

normally sets up the layer-2 connection on the new channel by transmitting an SABM message. If the BTS has not received the SABM from the MS after transmission of the last PHYS INFO message and expiry of timer T3105 (see T3105 in command SET BTS [TIMER]) theBTS sends a CONNECTION FAILURE indication with cause‘Handover access failure’ to the BSC and the new allocated channelsare released.Notes:- The MS can only receive the PHYSICAL INFO within a time framedetermined by the MS timer T3124 (time to receive the PHYS INFO)which is fixed to 320ms.- Any CONN FAIL is a trigger event for the TCH loss counter NRFLTCH. The following setting is necessary to avoid thetransmission of the CONN FAIL indication while the MS falls back to

the old channel due to unsuccessful access to the target cell and thusan unjustified registration of a ‘call drop’:NY1*T3105 >= 2 sec.- The combination of the values NY1=30 and T3105=MS10-10 hasturned out to improve the ‘handover speech gap’ in case of BSC-controlled intercell handover as it avoids the ‘bombardement’ of the MSwith unnecessary FACCH messages (that ‘steal’ the frames of thenormal speech channel).- Since the introduction of the BR70 CR 2335 the values set for NY1and T3105 are no longer applied for the PHYSICAL INFO procedure incase of SDCCH-SDCCH handover.

Please refer to the description of parameter T3105 (in command SET BTS [TIMER]) for further details!

PWROFS=0,

object: BTS [CCCH]

unit: 2dB

range: 0-3

0=feature disabled

default: 0


GSM 05.08

Power Offset , this parameter is relevant only for DCS 1800 cells. It

is used only by DCS1800 Class 3 Mobile Stations to add a power offset to the value of MS_TXPWR_MAX_CCH (see MSTXPMAXCH )used for its random access attempts. It is also used by the MS in itscalculation of C1 and C2 parameters:

C1 = (A - Max (B,0))

where A = <received level average> - RXLEVAMI Max (B,0)= MSTXPMAXCH + PWROFS - P Max (B,0)= 0 P = Maximum RF output power of the MS (see table below).(RXLEVAMI see CREATE BTS [BASICS], MSTXPMAXCH seeSET BTS [CCCH].)This info is sent on the BCCH (SYSTEM INFORMATION TYPE 4) inthe IE ‘SI 4 Rest Octets’.





Setting the cell attributes for the Interference Measurement of idle TCHs:

< The parameters set with this command are used for averaging and reporting interference levels in idle traffic channels. >

SET BTS [INTERF]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BTS packages’ were moved below the object BTS and

appear in the DBAEM in the CREATE BTS command. The logical group “[INTERF]” is normally only used on the LMT but was used here to allow a more useful grouping of the commands .


INTAVEPR=31- 2-6-12-22,

object: BTS [INTERF]

fomat: averaging period

- threshold boundary 1




unit: averaging period:

1 SACCH multiframe

threshold boundaries:-1dBr

range: 1-31 (averaging period)

0..62 (threshold boundaries)

default: 31 (averaging period)

2 (threshold boundary 1)





Averaging period fo r idle TCH measurements , defines the number of SACCH multiframes (480ms = 4 multiframes, the interleaving function distributes the SACCH info over 4 bursts) over which valuesare averaged (value 1..31) and Interference threshold bo undaries X (X= 1 to 5), these values set the limits of four interference bands for the idle time slots. Thethreshold values entered for INTAVEPR represent uplink RXLEV values that are measured and averaged by the BTS and thenmapped to the ‘interference bands’ in correspondence with thesetting of INTAVEPR.

Note: Like any other level measurements performed by the BTS, alsothe idle TCH measurements depend on a correct configuration of theuplink path and a suitable setting of the BTSE parameter RXLEVADJ (see command CREATE RFLOOP).

INTCLASS=TRUE,

object: BTS [INTERF]

range: TRUE, FALSE

default: TRUE

Interference c lassi f icat ion enabled , if this parameter is set toENABLED the BTS permanently performs interferencemeasurements on the idle traffic channels and idle TCH/SDs in theuplink and reports he measurement results in form of ‘RF resourceindication (RFRESIND)’ messages via the Abis to the BSC. In theRFRESIND messages the measured TCHs are assigned to so-called ‘interference classes’. An interference class is represented by aninterference band (limited by an upper and lower interference level)which is defined by the parameter INTAVEPR.The status of the INTCLASS flag has an influence on the channel allocation by the BSC: Basically the channel allocation resp. selectionof TCHs for incoming TCH requests is done cyclically, i.e. the BSC starts the TCH allocation by selecting the first TCH on TRX:0 (e.g.timeslot 2), the subsequent TCH request is served by the next TCH on TRX:0 (e.g. timeslot 3) and so on. If INTCLASS=TRUE, the BSC also evaluates the interference band of the idle TCHs for the TCH allocation, i.e. those TCHs with the best interference class areallocated first. Only if all TCHs with the best interference class arebusy, the BSC allocates those with a worse interference class to anincoming TCH request. The term ‘incoming TCH request’ represents

any kind of call as well as any kind of incoming handover (incl.intracell handover). For the BSC TCH allocation pattern there is nodifference between calls and handovers.Notes:- Only if INTCLASS is set to TRUE the PM counters for idle TCH interference measurements (MEITCHIB and ILUPLKIC) will deliver any results.- If frequency hopping is activated, the BTS measures theinterference considering all frequencies used in the hopping sequence assigned to the a TCH (see parameter FHSY in command CREATE CHANNEL)! - The idle TCH measurements are performed for normal TCHs as





Setting the cell specific timer values:

< This command sets the timers on layer 2 and 3 of Um interface. >

SET BTS [TIMER]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BTS packages’ were moved below the object BTS and appear in the DBAEM in the CREATE BTS command. The logical

group “[TIMER]” is normally only used on the LMT but was used hereto allow a more useful grouping of the commands .


ENANCD=ENABLED,

object: BTS [TIMER]

range: DISABLED, ENABLED

default: ENABLED


Enable 'No call in TRX/cell detectio n' , this flag enables resp.disables the features ‘sleeping cell detection’ and ‘sleeping TRX detection’ for the affected BTS. For both features two time zones(representing daytime and night time traffic) can be defined, in whichthe activity of the cell respectively the TRX is observed within timezone specific observation periods (see parameters NCDP1 and NCDP2). For both alarms the ceasing of the alarm can take place at the earliest at the end of the next observation period if in this period the alarm condition has ceased (successful activities).

1)The feature ‘sleeping cell detection’ supervises the SDCCH activations within the cell: If at the end of the observation period nosuccessful SDCCH assignment could be registered, the alarm ‘alarmwith error ID 66 - NO CALL IN CELL WITHIN A PREDEFINED TIME FRAME is output. For this, the BSC observes the number of ESTABLISH INDICATION messages for SDCCH received from theobserved BTS. Principle:

Note: The 'SLEEPING CELL' alarm will in any case be output if aBTS is 'barred' (see SET BTS [OPTIONS]: CELLBARR). In many networks this approach is commonly used for cells which areexclusively used as handover target. In this case these cells carry traffic but issue the alarm with error ID 66 - NO CALL IN CELLWITHIN A PREDEFINED TIME FRAME due to missing SDCCH activity.

2)The feature ‘sleeping TRX detection’ supervises the TCH activations on a specific TRX: If at the end of the observation period the TCH activation success rate is below a fixed threshold, the alarmwith error ID 70 - NO CALL IN TRX WITHIN A PREDEFINED TIME FRAME is output. For this, the BSC observes the number of

CHANNEL ACTIVATION ACKNOWLEDGE* messages for TCH and the number of ESTABLISH INDICATION messages for TCH. If for acertain TRX the difference between the number of CHAN ACT ACK messages and the number of EST IND messages is equal or greater than eight (8), the SLEEPING TRX alarm is triggered.

* Note: CHANNEL ACTIVATIONs are only considered in case of TCH activations for CS TCH requests. Channel activations due toGPRS traffic are not considered in the supervision mechanismtherefore the ‘sleeping TRX’ alarm can never be reaised for TRXswhich are exclusively used for GPRS traffic.

no successfulSDCCH ssignment

ime zone

TNC TNC TNC

SleepingCell Alarmactive

SleepingCell Alarmceased

= succ. SDCCH assignment(i.e. ESTIN for SDCCH received)





NCDP1=H1-6,

object: BTS [TIMER]

format: StartTime1-TimerNoCall 1

unit: StartTime1: Time in ‘1h’

TimerNoCall1:

Periods of 10min

range: StartTime1: H0..H23

TimerNoCall1: 1-432

default: H1-6


Timer 1 for 'No cal l in TRX/cel l detect ion' , this parameter allows toconfigure the first time-frame for the ‘sleeping TRX/cell detection’

procedure. StartTime1 represents the beginning of thetime-frame TimerNoCall1 represents the observation period.

The following condition must be fulfilled:

NCDP1TIMER ≤ 6x (NCDP1STARTTIME – NCDP2STARTTIME)

The change of the default value was implemented to avoid unnecessary ‘sleeping cell’ alarms during nighttime.

NCDP2=H6-1,

object: BTS [TIMER]

format: StartTime2-TimerNoCall2

unit: StartTime2: Time in ‘1h’

TimerNoCall2:

Periods of 10min

range: StartTime2: NOTUSED,

H0..H23

TimerNoCall2: 1-432

default: H6-1


Timer 2 for 'No c al l in TRX/cel l detect ion' , this parameter allows toconfigure the second time-frame for the ‘sleeping TRX/cell detection’

procedure. StartTime2 represents the beginning of the time-frame.TimerNoCall2 represents the observation period.Note: If NCDP2 is used the following rules must be applied:

1) NCDP2STARTTIME > NCDP1STARTTIME

2) NCDP2TIMER ≤ 6x (24 - (NCDP1STARTTIME – NCDP2STARTTIME))

The change of the default value was implemented to avoid unnecessary ‘sleeping cell’ alarms during nighttime.

NRPGRANT=20,

object: BTS [TIMER]range: 1-254

default: 20


Numb er of repeti t ions of VGCS UPLINK GRANT this parameter isonly relevant if the ASCI feature is enabled and only affects VGCS

calls (see parameter ASCISER in SET BTS [CCCH]). It correspondsto the parameter NY2 described in the GSM Standard. It determinesthe number of repetitions of the VGCS UPLINK GRANT messageduring a ‘Talker Change’ procedure. For further details please refer to

parameter TGRANT (see below).

T200=29-31-38-90-70-29-168,

object: BTS [TIMER]

unit: 5ms

(for sdcchSAPI0,

facchTCHF, facchTCHH,

sdcch SAPI3)

10ms

(for sacchTCHSAPI0,

sacchSDCCH,

sacchTCHSAPI3)range: 0..255

default: 29 (sdcchSAPI0)

31 (facchTCHF)

38 (facchTCHH)

90 (sacchTCHSAPI0)

70 (sacchSDCCH)

23 (sdcchSAPI3)

168 (sacchTCHSAPI3)



LapDm Tim er 200 , this timer is used on different control channel types and determines the waiting time for a layer 2 frameacknowledgement.

Parameter format: sdcchSAPI0 - facchTCHF - facchTCHH -sacchTCHSAPI0 - sacchSDCCH - sdcchSAPI3 -sacchTCHSAPI3.

General: During any dedicated connection the BTS and the MSexchange specific LAPDm signaling messages in the so-called in

“acknowledged mode”. This mode is started with an SABM and normally ends with the LAPDm DISCONNECT (not to be mixed upwith the DTAP DISCONNECT which is transmitted between MS and MSC). All messages within this “acknowledged mode” are checked by the LAPDm flow control mechanisms based on sequencenumbers that are assigned to each transmitted LAPD message. Only for those messages that are transmitted in acknowledged mode thetimer T200 is used as waiting time for the layer2 acknowledgement toa transmitted message. Messages in acknowledged mode areSABM, DISCONNECT and I-frames. Signalling messages that do not have to be acknowledged are transmitted in “unacknowledged mode” via UI-frames, e.g. in the downlink the SYSTEM INFORMATION

CHAN ACT ACK (TCH) -EST IND (TCH) < 8

TNC TNC

CHAN ACT ACK (TCH) -EST IND (TCH) >= 8

ime zone

Sleeping TRX Alarm active

Sleeping TRX Alarm ceased





TYPE5 and 6 etc. and in the uplink the MEASUREMENT REPORTS.Of course, the acknowledgement mechanism based on T200 is used by the MS in the same way.

Principle: When the BTS transmits a DL layer-2 frame on the air (e.g.an I-frame with an embedded layer 3 message) the BTS starts thetimer T200 and waits for the acknowledgement frame from the MS.The acknowledgement frame can be another I-frame sent by the MSin the UL (if the MS has to transmit a layer-3 DTAP message

anyway) as well as RECEIVE READY (RR) if there is nothing else tobe transmitted on layer 3. If the acknowledgement from the MS is not received within T200 the transmission of the layer 2 frame isrepeated and T200 restarted. The total number of repetitions isrestricted to N200, a fixed value for the BTS side specified by GSM which depends on the control channel types:N200(SDCCH)=23, N200(SACCH)=5,N200(FACCH/FR)=34, N200(FACCH/HR)=29

If T200 expires after the last layer 2 frame repetition the BTS sendsan ERROR INDICATION with cause ‘T200 expired N200+1 times’ (followed by a RELEASE INDICATION) message to the BSC, whichreleases the associated resources.

Recommended values:The different channel-type-specific values of the parameter T200

should be set in correspondence with the channel mapping and channel characteristics on the radio interface. To achieve anoptimum radio interface performance (from the subscriber’s point of view), the timer values for T200 should be set in such a way that - a Um layer 2 frame retransmission should take place at the earliest after a time period the MS needs for the transmission of anacknowledgement of a received layer 2 frame- a Um layer 2 frame retransmission should take place as early as

possible when the aforementioned time period has passed and noacknowledgement was received from the MS- unnecessary retransmissions are avoided.

On the basis of these considerations, the BTS development recommends the following setting of the parameter T200

T200=29-31-38-90-70-29-168

which has been implemented as default value starting from BR8.0.

Important: Please note that these values are the best settings fromthe technical point of view. The recommended values shown abovemight probably not be suitable to make a call drop rate (due toERROR INDICATION s with cause ‘T200 expired (N200+1) times’)look ‘nice’. In fact, with these settings, the call drop rate due to T200 expiries will deliver a realistic image of the actual radio interfacequality (rather than faking a good call drop rate in the performancemeasurement counters).

Notes:- The SAPI (service access point identifier) is used as address for different radio signaling applications by the LAPDm protocol.SAPI 3 is used for Short Message Service (point-to-point)

transmission only, while SAPI 0 is used for all other layer 3 radiosignalling procedures.- The LAPD mechanisms are only used for signaling messages.Speech frames are not transmitted via LAPD.- The T200 values for sacchTCHSAPI0 and sacchSDCCH can bechanged, but their value does not have any impact on the systembehaviour as on the SACCH associated to a TCH and the SACCH associated to an SDCCH the ‘acknowledged mode’ is not used at

present (i.e. T200 is never used on these channel types). Thementioned fields are available because - possibly for future purposes- the associated T200 values are foreseen in the GSM standard.- When the BTS sends a channel assignment message to the MS





as successful and the MS transmits the HANDOVER COMPLETE. If the MS does not receive the UA it retransmits the SABM. For anFACCH FR the time between two retransmissions (determined by thevalue of timer T200 for this channel type as implemented in the MS)is 34 TDMA frames and number of transmissions is restricted to 5.This means that for approx. 800ms the MS tries to set up the layer 2 connection on the target channel. If all these attempts fail, the MStries to return to the old channel.

- Any CONN FAIL is a trigger event for the TCH drop counter NRFLTCH and the SDCCH drop counter NRFLSDCC. For thisreason the parameters the time determined by (NY1*T3105) must belonger than the sum of the maximum time the MS might need toreturn to the old channel and the time necessary for the release of the new channel (RF CHANNEL RELEASE). If this rule is not considered, call drops would be counted even if there is no real call drop but just a reversion to old channel during handover. Asdescribed above, in case of unsuccessful access to the target channel it may (in the worst case) take more than 1 second (T3124(=320ms)+800ms) before the MS returns to the old channel.The signalling of the handover failure and the subsequent release of the target channel takes additional time (especially in case of MSC-controlled handover). Field experiences have shown that he following

setting is suitable to avoid the aforementioned drawbacks:NY1*T3105 ≥ 2 sec.

The combination of the values NY1=30 and T3105=MS10-10 hasturned out to improve the ‘handover speech gap’ in case of BSC-controlled intercell handover as it avoids the ‘bombardement’ of theMS with unnecessary FACCH messages (that ‘steal’ the frames of the normal speech channel).- Since the introduction of the BR70 CR 2335 the values set for NY1and T3105 are no longer applied for the PHYSICAL INFO procedurein case of non-synchronized SDCCH-SDCCH handover. This changewas introduced in order to optimize the T3105 and NY1 setting to thecharacteristic periodicity of the SDCCH channel (51 frames) in caseof SDCCH handover, and as a consequence, to avoid overflows of the BTSE alarm buffer due "UI buffer overflow" alarms from

subsystem U2. These alarms occur if the setting of T3105 and NY1are optimized for TCH handover and are used for both TCH and SDCCH handover: while a correct setting for TCH leads to theoverflow problem on the SDCCH, a correct setting for SDCCH leadsto a insecure and potentially slow handover procedure for TCH.Therefore the handling for TCH and SDCCH was decoupled using fixed and the technically only meaningful values for SDCCH. Thismeans that, in case of SDCCH handover, regardless the values of the two BTS attributes contained in the BSC database, the BTSapplies the values

T3105 = 235 msec and NY1 = 9





TGRANT=4,

object: BTS [TIMER]

unit: 10 ms

range: 1-254

default: 4

reference : GSM 04.18

Timer grant , this parameter is only relevant if the ASCI feature isenabled and only affects VGCS calls (see parameter ASCISER inSET BTS [CCCH]). It corresponds to the timer T3115 described inthe GSM Standard. When a VGCS call was set up in a cell and oneof the ASCI subscribers wants to talk, he starts the ‘Talker Change’

procedure by pressing the PTT button on the mobile phone torequest an uplink TCH. As a result, the MS sends an UPLINK

ACCESS message via the FACCH of the ASCI Common TCH and waits for the receipt of the VGCS UPLINK GRANT message. Whenthe BTS sends the VGCS UPLINK GRANT message, it starts thetimer TGRANT and waits for a correctly decoded message from theMS (normally SABM with TALKER INDICATION included). If nocorrectly decoded message is received from the MS before expiry of TGRANT, the BTS repeats the VGCS UPLINK GRANT message and restarts TGRANT. The number of VGCS UPLINK GRANT messagerepetitions is defined by parameter NRPGRANT (see above).

TNOCH=1,

object: BTS [TIMER]

unit: 1 SACCH multiframe

range: 1-254

default: 1


Timer for noti f icat ion channel , this parameter is only relevant if the ASCI feature is enabled (see parameter ASCISER in SET BTS[CCCH]) and determines minimum repetition period for messages onthe Notification Channel (NCH).

The NCH is located within those CCCH blocks that were reserved for AGCH (NBLKACGR) and is used to inform the ASCI MSs in the cell about the currently ongoing ASCI VBS/VGCS group calls and thecurrently activated ASCI Common TCH(s).

The value TNOCH=1 is recommended because test experienceshave shown that other values can cause mobile problems.

For further details about the NCH and its function, please refer todescription for parameter NOCHFBLK.

TSYNC=1000,

object: BTS [TIMER]

unit: 10ms

range: 10..10000

default: 1000

(recommended value >200)

TSYNC, this timer is used by the BTSE to supervise time-out of TRAU frame handling for standard speech calls (FR,HR and EFR)and data calls except 14,4kbit/s data calls. The BTSE starts this timer if 3 downlink TRAU frames have not been correctly received from theTRAU and it is reset if a correct frame is received again (It is only used if a BTS-TRAU traffic connection is established). If it expires,

the BTSE reports a CONNECTION FAILURE INDICATION withcause ‘remote transcoder failure’ to the BSC and the connection isreleased.Rules:- TSYNC > ALARMT2 (see CREATE LICD)This setting is necessary in order to avoid call release before PCM alarm detection.Note: For 14,4kbit/s data calls and AMR calls TSYNC is replaced by the timer TSYNCDL (see below).

TSYNCDL=1000,

object: BTS [TIMER]

unit: 10ms

range: 10..10000

default: 1000

TSYNC downl ink , this timer replaces the timer TSYNC in case of 14.4 kbit/s data calls and AMR calls. If three consecutive DL TRAU frames have not been correctly received in the BTS thesynchronization between TRAU and BTS (see explanation for TSYNCR) is considered as lost. If this is the case the BTS starts

TSYNCDL and waits for the receipt of correct downlink frames.TSYNCDL is stopped when the BTS has received the first correct DLTRAU frame. When TSYNCDL expires the BTS sends aCONNECTION FAILURE INDICATION with cause ‘RemoteTranscoder Failure’ to the BSC.

Rule: TSYNCR < TSYNCDL (Recommendation TSYNCDL=1000)

Note: According to GSM the timer TSYNCDL shall also be used for EFR calls. The current SBS implementation deviates from thisrecommendation as for EFR connections the timer TSYNC is used.





TSYNCR=400,

object: BTS [TIMER]

unit: 10ms

range: 10..10000

default: 400

TSYNC for resynch ronizat ion, this timer is used for 14.4 kbit/s datacalls. At the beginning of every 14.4. kbit/s data connection BTS and TRAU exchange standard TRAU frames for synchronization. Whenthis synchronization process is regarded as finished the BTS and TRAU switch over to the exchange of 'extended' TRAU frames. In thenormal case this synchronization process is not repeated. If,however, the BTS loses the synchronization for the 14.4 kbits/s

TRAU frames it starts timer TSYNCR and restarts thesynchronization process by transmitting standard TRAU framestowards the TRAU. When the connection is re-synchronized BTS and TRAU start to send extended TRAU frames again and TSYNCR isstopped. If the synchronization could not be reestablished beforeexpiry of TSYNCR, the resynchronization process is restarted again.

Rule: TSYNCR < TSYNCUL and TSYNCR < TSYNCDL

Note: According to GSM the timer TSYNCR shall also be used for EFR calls. The current SBS implementation deviates from thisrecommendation as EFR connections are handled in exactly thesame way as FR connections.

TSYNCUL=1000,

object: BTS [TIMER]unit: 10ms

range: 10..10000

default: 1000

TSYNC up l ink , this timer is used only in case of 14.4 kbit/s data callsand AMR calls. If three consecutive UL TRAU frames have not been

correctly received in the TRAU the synchronization between TRAU and BTS (see explanation for TSYNCR) is considered as lost. If thisis the case the TRAU sets the control bit 'uplink frame error ' (UFE) inthe downlink TRAU frames towards the BTS. When the BTS receivesthe first downlink TRAU frame with the control bit ‘uplink frame error’ set it starts TSYNCUL and waits for the UFE bit to disappear in thesubsequent frames. TSYNCUL is stopped when three correct DLTRAU frames without the UFE have been received. When TSYNCULexpires the BTS sends a CONNECTION FAILURE INDICATION withcause ‘Remote Transcoder Failure’ to the BSC.

Rule: TSYNCR < TSYNCUL (Recommendation TSYNCUL=1000)

Note: According to GSM the timer TSYNCUL shall also be used for EFR calls. The current SBS implementation deviates from thisrecommendation as for EFR connections the timer TSYNC is used.

TTRAU=1000,

object: BTS [TIMER]

unit: 10ms

range: 10..10000

default: 1000

(recommended value >150)

TTRAU , this timer is used by the BTS to supervise time-out of TRAU datalink (traffic) at connection establishment or handover. After receipt of the CHANNEL ACTIVATION message the BTSE starts thetimer TTRAU and starts sending uplink TRAU frames towards theTRAU. When the BTSE receives the first downlink TRAU frame fromthe TRAU it stops TTRAU again. If TTRAU expires, the BTSE reportsa CONNECTION FAILURE INDICATION with cause ‘remotetranscoder failure’ to the BSC and the connection is released.Rules:- TTRAU > ALARMT2 (see CREATE LICD)This setting is necessary in order to avoid call release before PCM alarm detection.- TTRAU > T8 and TTRAU > T10 (for T8 and T10 see command SET BSC SET BSC [TIMER])

This setting is necessary to ensure that a signaling failure (T8 and T10) is detected before transcoder failure (TSYNC and TTRAU)





TUPLREP=20,

object: BTS [TIMER]

unit: 1s

range: 5.. 60

default: 20

Timer for upl ink reply , this parameter is only relevant for ASCI (see parameter ASCISER in command SET BTS [CCCH]) and representsa timer which the BTS uses for the ASCI ‘Uplink Reply’ procedure(see parameter ASCIULR in command SET BTS [CCCH]), if enabled.During the ‘Uplink Reply’ procedure the BTS sends the UPLINK FREE message (with ‘Uplink access request’ included) via theFACCH of the ASCI Common TCH and repeats it periodically. The

time period between two consecutive transmissions of the UPLINK FREE message is determined by the parameter TUPLREP.

For further details about the functional sequence of the Uplink Reply procedure and the use of the timer defined by TUPLREP please refer to the descriptions provided for parameter ASCIULR (see command SET BTS [CCCH]).

VGRULF=1,

object: BTS [TIMER]

unit: 1

range: 1..100

default: 1


Voice group upl ink free , this parameter is only relevant if the ASCI feature is enabled (see parameter ASCISER in command SET BTS[CCCH]) and is used for the repetition of the UPLINK FREE messageduring the ‘Talker Change’ procedure within a VGCS call (ASCI service subscriber presses the PTT button on the ASCI phone, see

parameter ASCISER in command SET BTS [CCCH]).

During an ongoing VGCS call the BSC sends the UPLINK FREE

message to the BTS which periodically sends this message via the ASCI Common TCH in order to inform the ASCI MSs in the cell that the uplink is currently free, i.e. the UL is not used by any other ASCI MS in the cell and a ‘Talker Change’ procedure can be started, if required. The frequency of this UPLINK FREE message sending isdefined by the parameter VGRULF in the following way: The

parameter VGRULF plus an offset of 440 ms defines the repetitionrate of sending this message; the BTS limits the maximum repetitionrate to 1/1450ms.

UPLINK FREE repetition rate = MIN [(440ms+(VGRULF∗10ms)),1450ms]

The BTS stops the timer when the uplink is free again and also notalker is in the cell on a dedicated channel.

If an ASCI MS has started the ‘Talker Change’ procedure (i.e. the ASCI subscriber has pressed the PTT button, the ASCI MS has sent

the UPLINK ACCESS message via the ASCI Common TCH) and theUL TCH was successfully allocated, the BSC sends the UPLINK BUSY message via the DL of the ASCI Common TCH.

Recommended value: VGRULF=1.





CREALL=NOTALLOWED

object: BTS [OPTIONS]

range: ALLOWED,

NOTALLOWED

default: NOTALLOWED


Cal l re-establ ishment al lowed , indicates whether the MS may try tostart a Call re-establishment procedure. With a call re-establishment

procedure the MS tries to set up a new radio connection to the BSSdirectly after a call drop (which might have occurred e.g. due tosudden loss of a radio path in e.g. a tunnel). Depending on the radioconditions, the MS might set up the new call in a different BTS. For this, the MS sends a CM REESTABLISHMENT REQUEST (instead

of a CM SERVICE REQUEST) to the network. It is then a task of the'anchor' MSC (i.e. the MSC which served the dropped call) to quickly recognize the old call context and to interconnect the new radio pathto the existing connection before the call is terminated by the end users or by expiry of call supervision timers. Whether a call re-establishment can be attempted or not depends on the call control state, as described in GSM Rec. 04.08, section 5.5.4.Inhibiting call reestablishment is a possibility to reduce the traffic load in the cell since call reestablishment causes considerable signaling load on the network. A low value of radio link time-out (see parameter RDLNKTO in command CREATE BTS [BASICS]) increases thenumber of call reestablishments because a decrease of RDLNKTOleads to an earlier declaration of radio link failures.This parameter is sent on the BCCH (SYSTEM INFORMATION

TYPE 1,2,3 and 4) in the IE ‘RACH Control Parameters’. DIRTCHASS=FALSE,


range: FALSE, SDCCHMS

NOSDCCHMS

default: FALSE

Direct TCH assignment enabled , ‘Direct TCH Assignment’ means: assignment of a TCH without previous assignment of an SDCCH. If ‘Direct TCH Assignment’ is enabled the TCH is first of all assigned by an IMMEDIATE ASSIGNMENT (not by ASSIGNMENT COMMAND!)and the FACCH associated to the TCH is used as main DCCH for thecall setup control messages. When the setup phase of the call iscompleted the TCH is put into service by a CHANNEL MODE MODIFY message.Setting DIRTCHASS to SDCCHMS means that direct TCH assignment is enabled but disabled for the cause 'answer to paging -any channel' of the CHANNEL REQUIRED message (sinceSDCCHonly MS may be supported by the network).Setting DIRTCHASS to NOSDCCHMS means that direct TCH

assignment is enabled also for the cause 'answer to paging - any channel' of the CHANNEL REQUIRED message (since SDCCHonly MS is not supported by the network).Notes:- Interworking of ‘Service Dependent Channel Allocation’ and Direct TCH Assignment If Direct TCH Assignment is enabled the SLL associated to‘signalling’ is used for allocation (see command SET BTS [SERVICE] for details). This SLL should be defined by the operator in such a way that the TRXs with less SDCCH and more TCHs are listed at the top.For call setups with direct TCH assignment, the TCHs are first searched in in the SLL defined for signalling (see SLLPRM) and, if the allocated channel does not perfectly match to service typerequested in the ASSIGNMENT REQUEST message, the channel is

changed after receipt of this message (as it is done during normal change from SDCCH to TCH when direct assignment is not applied.)- There is no impact on directed retry (see parameter ENFORCHO incommand SET BSC [BASICS]) if direct TCH assignment is enabled.If in this case no TCH is available for the IMMEDIATE ASSIGNMENT

procedure, the BSC allocates an SDCCH and the directed retry canbe performed.- In case of Direct TCH Assignment the BSC has to decide about theTCH type (FR, HR) when it receives the CHANNEL REQUIREDmessage. The only information about the MSs speech versioncapability which is available at this point of time is included in the‘Establishment cause’ IE within the included CHANNEL REQUEST





message. This information is very restricted with respect to the gradeof detail and the MS capabilities and preference (see GSM04.08 for details). At this point of time the BSC does not check the current TCH load in the cell to decide about the allocation of FR or HR but assignsa TCH type in correspondence with the ‘establishment cause’ valuereceived in the CHANNEL REQUIRED message. For this reason Cell Load Dependent Activation of HR (see parameters EHRACT and EHRACTAMR in command CREATE BTS [BASICS] in command)

does not work when Direct TCH Asssignment is enabled.- Direct TCH Assignment also has other disadvantages: In somecases the ‘establishment cause’ values contained in the CHANNELREQUEST messages (especially if the parameter NECI (seecommand SET BSC BASICS])is set to TRUE) do not allow a clear distinction between calls (that require a TCH) and signaling

procedures (for which an SDCCH is sufficient). This can happen,depending on the type of MS, e.g. for an IMSI DETACH INDICATION (which is sometimes indicated with the same establishment causelike MOC) or for SMS-MT (the BSS cannot distinguish SMS-MT fromnormal MTCs as the very first signaling messages are exactly thesame for both procedures).In other words: it happens that that BSC assigns a TCH for signaling

procedures, although these procedures could be processed using an

SDCCH only .Moreover, several mobile types cause problems, when Direct TCH Assignment is enabled, especially when it is enabled for theestablishment cause ‘answer to paging’





DTXDLFR=FALSE,


range: TRUE, FALSE

default: FALSE


GSM 05.08

GSM 06.31

GSM 08.60

Discontinu ous transm ission dow nl ink for FR cal ls enabled ,specifies whether “discontinuous transmission downlink (DTX downlink)“ is enabled for FR calls in the BTS.

As a precondition for operation, DTX downlink must also be activated in the MSC, i.e. the MSC must declare DTX downlink ‘allowed’ in theDTX DL FLAG in the ASSIGNMENT REQUEST resp. HANDOVER REQUEST messages. The status of DTX downlink (applied/not

applied) can be seen from the IE ‘Channel Mode’ in the CHANNEL ACTIVATION message on the Abis.Note: DTXDL is not allowed on the BCCH TRX.

General remarks about DTX:DTX was originally developed for satellite systems. The goal is toreduce the interference in a cell and to reduce the MS power consumption (DTX uplink only). During a normal voice call, the

participants speak only 50% of time, thus each direction of transmission is occupied about 50% of time. DTX is a mode of operation where the transmitters are switched on only for thoseframes containing useful information. So-called VAD (Voice Activity Detection) algorithms are implemented in the MS as well as in theTRAU which are able to distinguish noisy speech from real noiseeven in a noisy environment. The VAD algorithms “isolate” the

background acoustic noise in order to transmit characteristic parameters of this noise to the receive side. From these parametersthe receive sides generates a similar noise called “ comfort noise “ during periods without radio transmission. This is done because ‘total silence’ is experienced as considerably irritating by the listener.DTX reduces the speech data rate from 13 kbit/s to 500 bit/s. Thislow rate is enough to encode the background noise. This meansinstead of one frame of 260 bits per 20 ms only one frame per 480 ms is sent. These so-called SID frames (Silence Description Frames)are sent at the start of every inactivity period and repeated every 480 ms, as long as the voice inactivity between BTS and MS lasts.Between TRAU and BTS the comfort noise frames are sent every 20 ms.

The following example might illustrate this time behaviour:

Impacts of DTX on Measurement Processing in the BTS and MS:When DTX is used, the MS (for DTX downlink) as well as the BTS(for DTX uplink) have to consider the utilization of DTX during theradio measurement process. Both the MS and the BTS indicate in theMEASUREMENT REPORT resp. RESULT messages whether in thecurrent measurement period DTX is active (speech transmitted) or not (silence). The BTS sets the DTX flag to ‘DTX employed’ if DTX was applied in at least one TDMA frame in the measurement period.

Both MS and BTS provide two different measurement values for RXLEV and RXQUAL: the so-called FULL and SUB values.

1) The FULL values represent the measurements that were made onthe TCH and the SACCH frames with a sample period of 20ms,assuming that every 20ms a decodable TDMA frame is received.This means that, if DTX was active in a specific measurement period (silence), the FULL values or RXLEV and RXQUAL may indicate bad

20ms

S S S C C C C C C C C C C C C C C C S S C C C C C C C S

480 ms 480 ms 480 ms 480 ms 480 ms

S S S S C C C C SSC C C S

TRAU <-> BTS

BTS <-> MS

S = speech frame

C = comfort noise frame





radio conditions due to missing speech frames, even if the radioconditions are excellent. The higher the number of TDMA frames withactive DTX, the worse the RXLEV/RXQUAL values will look.

2) The SUB values represent the measurements that were made onthe SACCH frames, which are repeated every 480 ms and whichcarry the SYSTEM INFORMATION TYPE 5 and 6 (downlink) and theMEASUREMENT REPORTs (uplink). As a general rule, the SUBvalues always mirror the real radio conditions, but have a lower

statistic reliability than the FULL values that were measured during speech periods. To increase the reliability of the SUB values for AMR calls, from BR8.0 onwards, the BTS does not only consider theSACCH frames but also the speech frames carrying reals speech (asthe BTS can recognize these frames from their contents).

Impacts of DTX on the Power Control and Handover Decision As the FULL values do not mirror the real radio conditions inmeasurement periods with active DTX (silence) the BTS has to usethe SUB values for these measurement periods for the Power Control and Handover Decision Process. In measurements periods without active DTX (speech frames transmitted) the BTS uses the FULLvalues for the PWRC and HO decision. Due to their higher statistic reliability it is possible to weight the FULL values in the Power Control and Handover averaging process higher than the SUB

values. This is done by the so-called ‘DTX-weighting factor’ included in the parameters PAVRLEV and PAVRQUAL (see SET PWRC) and HOAVLEV, HOAVQUAL and ALEVFULHO (see SET HAND[BASICS]).

If the MS indicates “DTX used“ in a specific MEASUREMENT REPORT, the BTS has to consider the SUB values of thesubsequent uplink MEASUREMENT RESULT (480 ms later) for thePower Control and Handover decision. On the other hand, if the BTSapplies DTX for a specific downlink measurement period, it uses theSUB values of the subsequent downlink MEASUREMENT REPORT.

Attention: To allow an easier analysis of Abis measurement messages, in the MEASUREMENT RESULT and TRACE MEASUREMENT RESULT messages that are (optionally) sent fromthe BTS to the BSC via the Abis (see parameters RADIOMG incommand CREATE TRX and TRACEMR in command SET BSC) ,this “cross-relation” has been removed by a BTS-internal “frame-matching” process which shifts the associated DTX flags and measurements results to one and the same MEASUREMENT RESULT message. This means that - the DTX DL flag is val id for the downl ink m easurement resul ts

included in the same message

- the DTX UL flag is val id for th e upl ink m easurement resul ts

included in the same message!

continuation see next page…





not contain the suitable 3G radio capability data in the ‘Old BSS tonew BSS Information’ IE, the BSC may autonomously request thesedata by an own CLASSMARK ENQUIRY procedure. The resulting CLASSMARK CHANGE message will in this case be forwarded tothe MSC in the CLASSMARK UPDATE message as usual.

Timing and interact ion of CLA SSMARK REQUEST and ‘Ear ly

Classmark Sending’ procedures

Experiences from real life Abis traces confirm that normally the

CLASSMARK CHANGE message due to 'Early Classmark Sending' is normally sent after the MSC has sent the CIPHER MODE COMMAND (or, if authentication is performed, after the

AUTHENTICATION REQUEST). When the MSC sends aCLASSMARK REQUEST message due to the cipher algorithmsettings, the CLASSMARK REQUEST procedure must have beencompleted prior to the transmission of the CIPHER MODE COMMAND.

The procedures 'Early Classmark Sending' and CLASSMARK ENQUIRY (Abis message that follows the A-interface messageCLASSMARK REQUEST) are independet from each other.- If the MS receives CLASSMARK ENQUIRY after having sent theCLASSMARK CHANGE message due to 'Early Classmark Sending',the MS will send the CLASSMARK CHANGE again.

On the other hand, it also happens that an MS sends a CLASSMARK CHANGE message to the network due to ‘Early Classmark Sending’,even if a CLASSMARK ENQUIRY hes been received and answered by another CLASSMARK CHANGE message before.

EC=FALSE,


range: TRUE, FALSE

default: FALSE


GSM 02.11

Emergency cal l restr icted , this parameter determines whether emergency calls are allowed to all MSs or restricted to MSsbelonging to access classes in the range 11 to 15 . The value 'TRUE' indicates that emergency calls are restricted. This parameter is sent on the (SYSTEM INFORMATION TYPE 1,2,3 and 4) in the IE ‘RACHControl Parameters’, parameter ‘Emergency Call allowed’.

Attention:EC=FALSE means 'emergency calls allowed' EC=TRUE means 'emergency calls not allowed'





Which priority levels are to be placed in which queue, is determined by the parameter LWWPSPRI, which defines the lowest priority level (PL) to be placed in the WPS queue. In other words: all incoming TCH requests with PL >= LWWPSPRI are enqueued in the ‘WPSqueue’, all others are enqueued in the ‘Public queue’.For both queues the length and characteristics are defined by separate parameters:WPS queue:

- the queue length is defined by parameter QLWPS (see below)- the queuing time for TCH requests due to TCH assignment isdeefined by parameter BSCT11WPS and - the queuing time for TCH requests due to incoming MSC-controlled handover is deefined by parameter BSCTQHOWPS(see command SET BSC [TIMER]).Public queue:- the queue length is defined by parameter QLWPUB (see below)- the queuing time for TCH requests due to TCH assignment isdeefined by parameter BSCT11PUB and - the queuing time for TCH requests due to incoming MSC-controlled handover is deefined by parameter BSCTQHOPUB(see command SET BSC [TIMER]).

Each queue consists of a set of queue places all having the same

characteristics. Technically each cell has 14 queues, one for each priority. These 14 queues are separated into two different queuegroups as defined by LWWPSPRI according to the priority levels, i.e.the queues with the higher priority levels make up the WPS queue(group), the ones with the lower priority levels make up the Public queue (group).

TCH requests are put into the WPS queue or the Public queuedepending on their PL and are placed into the relevant queue using afirst-in / first-out queuing discipline for each priority level.

If one queue (i.e. WPS or public) is full (i.e. the number of queued TCH requests has reached the threshold defined by the parametersQLWPS and QLPUB) and an incoming TCH request has a higher

priority than at least one of the queued requests, the TCH requests inthe queue are re-ordered in order to insert the new request and toremove the (youngest) lowest priority one from the respective queue

(resulting in a rejection of the TCH request with an ASSIGNMENT FAILURE or HANDOVER FAILURE with cause ‘no radio resourceavailable’). If the queue is full and the new TCH request is lower thanthe lowest queued one, the request is rejected in the same way asdescribed above.

When a previously ‘busy’ TCH becomes ‘idle’ again (i.e. when the previously active call on one TCH resource is released) while TCH requests are queued, the enqueued TCH requests are served according to the following mechanism:

Starting from the beginning, the first call to be served is a TCH request in the WPS queue (if any is available), then, in order to





realize e.g. a requested sharing between WPS and Pubilc calls of 25% (reflected by the parameter setting WPSPREF=4-1, parameter description see below) the subsequent 3 requests will be taken fromthe Public queue, when present. If they are not present or the queuebecomes empty again it will be served the WPS queue or if also thisqueue is empty the resource will be available for the other needs.

Queued TCH requests can be discarded from a queuea) if further TCH requests with a higher priority are received or

b) if (for the TCH assignment case) during the queuing time anSDCCH HO attempt fails.( In these cases an ASSIGNMENT FAILURE message (for assignment requests) resp. a HANDOVER FAILURE message (for inc. HO requests) with cause ‘no radio resource available’ is sent tothe MSC. )

c) if the queueing time expires for the queue TCH request As mentioned above, the queuing times are defined by separatedatabase parameters for the two different queues (BSCT11WPSetc.).

If BSCT11WPS or BSCT11PUB expires, the BSC sends a CLEAR REQUEST message with cause ‘no radio resource available’ to theMSC and the requesting connection is released.

If BSCTQHOWPS or BSCTQHOPUB expires in case of incoming MSC-controlled HO, the TCH request is rejected with a HANDOVER FAILURE message using the same cause ‘no radio resourceavailable’ .

Notes: - If a CS call request is received in a congested cell, the BSC tries tosatisfy the TCH request in the following sequence:1) preemption of a low priority CS call; if not possible then2) directed retry ; if not possible then3) (WPS) queuing 4) downgrade of multislot calls (GPRS/HSCSD) may be periodically attempted in parallel and queued calls can be served when downgrade is successfully completed.Please refer to the parameters EPRE (for preemption) in thiscommand, ENFORCHO (for directed retry) in command SET BSC [BASICS] and to parameter DGRSTRGY (for multislot call downgrade) in command SET BTS [BASICS].

- Interworking of the features ‘Downgrade strategy’ and (WPS)queuing When a TCH request is queued, the BSC tries, when possible, toserve the queued TCH requests by a multislot call downgrade

procedure (e.g. (E)GPRS downgrade:Every call is put in the queue with its relevant data (channel request type, WPS/Public call info, Service List, running procedure, …). After the call is queued, the resource management process periodically starts the downgrade procedure (if correspondingly enabled via

parameter DGRSTRGY) on HSCSD data calls and/or (E)GPRS datacalls (if any) in order to get new resources for TCH allocation. Thecall that triggers the downgrade procedure is marked as “downgraderequested” in order to wait for the resources that will be availableafter successful completion of the downgrade procedure.If during the ongoing downgrade procedure other TCHs become ‘idle’ again, these resources cannot be assigned to the call marked as“downgrade requested”. The call marked as “downgrade requested” must in any case wait for the resources achieved by the downgrade

procedure.

The downgrade procedure is requested for the multislot callsestablished on the shared layers with service layer associationmatching to the service type of the enqueued call, starting from the

preferred layer. On the other hand, in case of Abis congestion the





multislot downgrade procedure will be requested on all layers of thiscell associated to the multislot service layer list and in the extremecase also on other cells of the same BTSM.Other scenarios that allpow the serving of a queued TCh request arerelease requests of previously ‘busy’ TCHs or the ‘return to service’ of

previously ‘disabled’ TCHs. As soon as a TCH resource returns toservice or becomes ‘idle’, the TCH allocation process attempts toserve the enqueued TCH requests with the highest priority. Of

course, the new resource and the queued request must becompatible in terms of supported layer, requested band and so on.

- By setting the parameter QLWPS=0, the BSC queuing behaviour isexactly the same as in releases < BR8.0.

- In case of MSC-controlled HO the Siemens MSC first attempts theHO REQ procedure for all target cells (previously received in the HORQD message) with the ‘Queuing Allowed Indicator’ set to ‘not allowed’! Only if these attempts are not successful the MSC repeatsthe HO REQ procedure with the ‘Queuing Allowed Indicator’ set to‘allowed’! This means that only for this second cycle queuing can be

performed by the BSC.- 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 isdiscarded from the queue.

HOPMODE=BBHOP,


range: BBHOP, SYNHOP

default: BBHOP

Hopping Mode , this parameter indicates whether baseband hopping or synthesizer hopping is to be used in this cell.Basband Frequency Hopping features a continuous switching of theBBSIG responsible for a particular TRX to different TPUs. In other words, the hopping is executed by switching one and the sameBBSIG among different TPUs in correspondence with the configured hopping sequence (see command CREATE FHSY). The number of frequencies in the frequency hopping system (mobile allocation) isrestricted to the number of TRXs configured in the cell. If baseband frequency hopping is used, it is the hopping system (FHSY) may include also channels of the BCCH TRX.

Synthesizer Frequency Hopping features a continuous re-tuning of the TPU/CU in correspondence with the created in correspondencewith the configured hopping sequence. The advantage of synthesizer hopping is that it is possible to define frequency hopping systemswith more frequencies than TRXs are available in the BTS.Synthesizer FH requires specific HW (e.g. filter combiners are not allowed) and is not allowed on the BCCH-TRX.

Note: The implementation of frequency baseband hopping shows thefollowing difference regarding the two BTSE generations, i.e. BTS1and BTSplus:- in the BTS1 baseband hopping is realized by multiplexing different TPUs to one BBSIG. The TX and RX paths are tied together by switching TX & RX at the same time;

- the BTSplus ' implementation is different to the BTS1. Herebaseband hopping is exclusively used in downlink direction whereasin uplink direction always synthesizer hopping is applied. Downlink data is pre-processed in the TRX related CU, but the burst data isthen sent via the CU whose carrier frequency is equal to that of thecurrently calculated burst. Thus, for a call, a single RX path is used with multiple TX paths; so there are as many TX/RX pairings for thecall as the number of transmitters in use.

Since the mobile reports the measured RXLEV_DL values with afixed period of 480ms (= 104TDMA bursts), no mapping is possibleon TDMA burst base for the DL measurements. Due to the averaging effect this means that failures in the RF-TX signal path which are





located in carrier specific parts may not be reliably detected in casebaseband hopping is applied (both for BTS1 and BTSplus). For thisreason the feature “ Online Rf Loopback “ does not work if baseband frequency hopping is configured.

In fact the MS will report an RXLEV_DL value which is the average of levels received from different RF-TX equipment (and so from different

paths). On the other side, in uplink direction the BTSE knows whichRX path is used per received burst.

IMSIATDT=TRUE,


range: TRUE, FALSE

default: TRUE


IMSI attach/detac h enabled , This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) in the IE ‘Control ChannelDescription’, parameter ‘Attach/detach allowed’. If this parameter isset to TRUE the MSs are requested by the above mentioned BCCH

parameter to send an ‘IMSI Attach’ message when they are switched on respectively an ‘IMSI Detach’ message when they are switched off.If an ‘IMSI Attach’ message is sent to the MSC the mobile subscriber is marked as ‘attached’ in the VLR. This means that the mobilesubscriber is regarded as ‘reachable’ and paging is performed incase of an MTC. If an ‘IMSI Detach’ message is sent to the MSC themobile subscriber is marked as ‘detached’ in the VLR, i.e. the VLR regards the mobile subscriber as ‘not reachable’ and rejects the call completion in case of MTC; paging is not performed in this case.

The IMSI attach procedure is only used if the IMSI was deactivated while the MS was in ‘idle updated’ state before switch-off and thestored Location Area Identification is the same as the one which isactually broadcast on the BCCH of the current serving cell when it isswitched on again. In the case of difference between the stored LAI and the one received on the BCCH of the current serving cell, anormal location updating procedure is invoked independently of the‘attach’ flag indication. The ‘IMSI attach’ message is a LOCATION UPDATE REQUEST’ message with the parameter ‘Location UpdateType’ set to ‘IMSI Attach’. For the ‘IMSI Detach’ procedure themessage IMSI DETACH INDICATION is used.

LWWPSPRI=<NULL>,


range: 1.. 10, <NULL>

default: <NULL>

Low est WPS Prior i ty , 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 (please see parameter EQ (above) for further details).It specifies the lowest Priority level to be considered in the WPSqueue.

Further parameters related to the WPS feature are BSCT11PUB,BSCT11WPS, BSCTQHOPUB, BSCTQHOWPS (see command SET BSC [BASICS]) and QLWPS, QLPUB and WPSPREF (see below).

NALLWACC=ALLALLOWED,


range: NA0..NA9, NA11..NA15,

default: ALLALLOWED


GSM 02.11

Not-al lowed acc ess classes , with this parameter the accessclasses 1 to 15 (the access class is stored on the SIM-card: classes1-9 are ordinary subscribers, class 10 is a mobile emergency call,classes 11-15 are priorized subscribers) can be explicitly barred for access to the cell (except for class 10). The information stating whichclasses are barred is sent on the BCCH (SYSINFO Type 1, 2, 3 and 4) in the IE ‘RACH Control Parameters’. If the MS receives the

indication that its access class is barred it remains camping in the cell but it is not allowed not perform a RACH access anymore. On themobile phone, there is no special indication on the display if the SIM’saccess class is barred while the MS is already booked in, thesubscriber only notices an immediate call rejection when he tries toset up a call.

Notes:- The access class barring using NALLWACC is a semipermanent one, i.e. the access class barring remains active until the accessclasses are unbarred by a repeated entry of the command SET BTSusing the appropriate setting of NALLWACC. The manual barring of access classes using NALLWACC is completely independent of





automatic access class barring due to overload situations in the BSC,BTS or MSC (please see parameters BSCOVLH, BTSOVLH and MSCOVLH in command SET BSC).- For the MS there is a big difference between a barred cell (see

parameter CELLBARR) and a barred access class! When the MSreceives the “cell barred” indication in the SYSINFO, it immediately

performs a cell reselection. If the SYSINFO indicates that its accessclass is barred, the MS stays in the cell.

PWROUT=MDB10..MDB5-DB6,


outputPowerFaultThreshold range: M10DB, M8DB

default: M10DB

fixed value for BS10/BS11: -6dB

reducedOutputPowerThreshold

range: M10DB, M8DB, M6DB,

M4DB

default: MDB6

fixed value for BS10/BS11: -4dB

excessiveOutputPowerThreshold

range: DB3, DB5

default: DB5

fixed value for BS10/BS11: 3dB

Power output thresho lds , defines three power output thresholds:outputPowerFaultThreshold = defines the minimum output power level at the PA resp. CU which results in an alarm output to the BTSE core unit.reducedOutputPowerThreshold = defines the PA resp. CU output

power level to initiate output of a warning.excessiveOutputPowerThreshold = defines the power level when amajor alarm is generated due to too high output power.

The PA supervises its actual output power and compares it to thedesired value. The desired value, i.e. the reference for the entered thresholds is the maximum output power of the PA resp. CU (depending on the type of PA resp. CU) minus the power reduction(see parameter PWRRED (CREATE TRX)).

QL Queue length , removed in BR8.0, replaced by QLPUB and QLWPS.

QLPUB=50,



default: 50

Length of pub l ic 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 (parameter EQ, see above).It specifies the length of the ‘Public’ queue for the Wireless Priority Services (WPS) feature.

Further parameters related to the WPS feature are BSCT11PUB,BSCT11WPS, BSCTQHOPUB, BSCTQHOWPS (see command SET BSC [BASICS]) and QLWPS and WPSPREF (see below).

QLWPS=0,



default: 0 (=WPS queuing disabled)

Length of WPS queue , this parameter specifies the length of the‘’WPS’ queue for the Wireless Priority Services (WPS) feature.

Please refer also to parameter QLPUB (see above).

By setting the parameter to its default value QLWPS=0, the BSC queuing behaviour is exactly the same as in releases < BR8.0.

T3212=6,


unit: 1 decihour (6 min)

range: 0..255

0 means ‘infinite timeout’,

i.e. periodic loc. updating

is used in the cell..

default: 10 = 60 min.


T3212, t imer for p er iodic location u pdate . A recovery in the VLR normally leads to the loss of the subscriber data. Periodic locationupdate is used to ensure the continuous update of subscriber data inthe VLR even if the subscriber remains in the same location area.The procedure is controlled by the timer T3212 in the Mobile Station.This timer is reset to 0 and started when a signaling activity hastaken place on the radio path (e.g. Location update, MOC, IMSI

Attach). When the MS is powered down the current value of T3212 iskept in memory. When the MS is powered up the timer starts running from the value thus contained in memory. On expiry the MS initiatesa location updating. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) in the IE ‘Control Channel Description’.This timer must be set in consideration of the „Implicit Detach“ timer in the VLR (command in SIEMENS MSC: ENTR MOBTHR:IDETTIM=...) according to the following

Rule: T3212 < IDETTIM.

If the setting is vice versa, the MS may be set to ‘detached’ in theVLR even before it executes a Periodic Location Update.





WPSPREF=4-1,


format: <councerCycle>-

<numberWPS>

range: counterCycle: 2 .. 10

numberWPS: 1.. 3

default: 4-1

WPS preference , 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 (parameter EQ, see above).

The value of this parameter consists of two parts:1. The first part ’counter cycle’ defines the complete cycling period interms of: number of calls served and

2. the second part ‘number WPS’ defines, for each complete cycle period, how many WPS requests should be consecutively served.

Example: The default setting WPSPREF=4-1 has the following effect:When a previously busy TCH becomes ‘idle’ and TCH requests areenqueued in both the WPS queue and in the Public queue, theenqueued WPS calls are served by every 4

thTCH which becomes

‘idle’. When the ‘serving’ of a TCH request from the WPS call isscheduled, only 1 call is served at a time.

In other words: the setting WPSPREF=4-1 will have the effect that 1out 4 served TCH requests is a WPS call.

Further parameters related to the WPS feature are BSCT11PUB,BSCT11WPS, BSCTQHOPUB, BSCTQHOWPS (see command SET BSC [BASICS]), QLPUB and QLWPS (see above).

Note: Some parameters of the command SET BTS [OPTIONS] appear at a later position when generated by the DBAEM. The command reappears after the CREATE CHAN commands with the parametersSMSCBUSE and HOPP. This order is necessary to ensure that SMS Cell Broadcast and Frequency Hopping may already be enabled when the DB is loaded to the system. Frequency Hopping and SMS-CB,however, can only be enabled if the CHAN objects are created accordingly (parameters FHSYID for frequency hopping and CHTYPE for SMS-CB).





Defining the cell specific service layer lists for the feature ‘Service dependentChannel Allocation’ (SDCA) via ‘Multi Service Layer Support’ (MSLS):

< This part of the BTS object is associated to the feature ‘ServiceDependent Channel Allocation’ (SDCA) via ‘Multi Service Layer Support’ (MSLS) and defines Service Layer Lists (SLL) for eachservice type (AMR and non-AMR speech, CS data, (E)GPRS etc.).

Feature Backgrou nd ‘Service Dependent Channel Al location’ The idea of the feature ‘Service Dependent Channel Allocation’ (SDCA) via ‘Multi Service Layer Support’ (MSLS) was introduced inBR8.0 to allow a sophisticated TCH allocation strategy which selects,for different requested service types, a TCH from the most suitableTRX, depending on the (expected) radio interface quality of this TRX (depending of the frequency planning strategy applied by theoperator) and the robustness of the affected service against radioquality degradations.

In this context the term ‘layer’ defines a group of one or more TRXswith a common (expected) radio interface quality, whose associationto a particular layer number is defined by the parameter LAYERID (see command CREATE TRX). At this point, the layers do not yet have any service association but just a ‘layer number’, which is later

on used as a kind of ‘TCH pool address’ when the associated TRXsare checked for available TCH resources during TCH allocation.

Thus the defined layers can be regarded as a virtual TCH pool whichis accessed and checked by the BSC in a certain ‘preferred’ sequence when a particular service type is requested.

Service Layer List (SLL)

Which layer is accessed by the BSC channel allocation process and in which sequence the BSC searches for channel resources,depends on the requested service type, as for each service type a‘preferred sequence’, which is also called ‘Service Layer List’ (SLL) isdefined by an own parameter or parameter pair. In this SLL, theavailable service layers are sorted in descending order or priority resp. preference.

If the SLL is defined as a parameter pair,

a) the first parameter is always named <service name>LLPRM ( PRM = prim ary area)and identifies

Cell

Radioquality

TRX:1

Layers TRXs

TRX:2

TRX:3

TRX:4

TRX:5

LY_00

LY_01

LY_02

LY_02





- the one and only SLL for standard cells or - the SLL of the complete are of a concentric cell or - the SLL for the far area (double timeslots) of an extended cell

b) the second parameter is always named <service name>LLCOM ( COM = com plementary area)and identifies- the SLL of the inner are of a concentric cell or - the SLL of the near area (single timeslots) of an extended cell

On the whole, 9 different service types are defined - their SLLs aredefined by the parameters as listed in the table below.

Service Type parameters for SLL

of pr imary area

parameters for SLL of

complementary area

Signalling SLLPRM ---

CS speech (E)FR-HR CRTSWSPELLPRM CRTSWSPELLCOM

CS speech AMR FR AMRFRLLPRM AMRFRLLCOM

CS speech AMR HR AMRHRLLPRM AMRHRLLCOM

CS data CRTSWDLLPRM CRTSWDLLCOM

HSCSD HSCSDLLPRM HSCSDLLCOM

GPRS GLLPRM GLLCOM

EGPRS ELLPRM ELLCOM

ASCI ASCIPRM ---

Please note that GPRS and EGPRS are not supported in the inner area of a concentric cell and HSCSD is not supported in the far areaof an extended cell. Therefore GLLCOM and ELLCOM cannot bedefined in a concentric cell (CONCELL=TRUE, see CREATE BTS[BASICS]) and HSCSDPRM cannot be defined in an extended cell (CELLTYP=EXTCELL, see CREATE BTS [BASICS]).

Attention : The value <NULL> means that for the associated serviceno SLL is defined. If this is the case, the service is regarded as ‘not supported’ in the cell! If the service shall be supported in the cell as adefault configuration without a sophisticated configuration of thefeature ‘Service Dependent Channel Allocation’, it is at least necessary to assign to each TRX of the cell the LAYERID=LL_00 and

to define this layer as the only entry in the SLL of each configured service (i.e. CRTSWSPELLPRM=LY_00, AMRFRLLPRM=LY_00, AMRHRLLPRM=LY_00, GLLPRM=LY_00 etc.).

Channel al location pro cess w ith SDCA/MSLS When the BSC receives a channel request for a particular servicetype, it first checks if for the requested service an SLL is defined. If yes, it looks inside the SLL defined for the requested service typeand starts to search for an available resource in the service layer that has the highest priority within the SLL. If a resource can be found inthis preferred layer, the channel is allocated. If no channel can befound on the TRX(s) belonging to the preferred layer of the SLL, theBSC searches the next lower layer for resources and so on.

Example:BSC receives TCH request for service type EFR.

SLL definitionThe SLL for service type E(FR), HR is defined as

LY_01, LY_00, LY_02 by the parameter

CRTSWSPELLPRM=LY_01&LY00&LY02,

while the association of the layers to the TRXs is defined as

LY_00 -> TRX:0, LY_01 -> TRX:1&TRX:2, LY_02 -> TRX:3.

by the commandsCREATE TRX:NAME=TRX:0 ,...LAYERID=LL_00 ;CREATE TRX:NAME=TRX:1 ,...LAYERID=LL_01 ;CREATE TRX:NAME=TRX:2 ,...LAYERID=LL_01 ;





CREATE TRX:NAME=TRX:3 ,...LAYERID=LL_02 ;

The diagram below illustrates this configuration.

Resource allocationWhen the TCH request for service type EFR speech is received, thesystem searches for free resources in the layer LY_01 (TRX1 and TRX2) first. If no idle TCH resources can be found in layer LY_01,the BSC resource management task checks the next layer of theSLL, i.e. LY_00. If also in LY_00 (TRX:0) no free resources areavailable, the BSC resource management task checks the last layer of the valid SLL, i.e. LY_02.

SDCA/MSLS resource managent in case of TCH cong estion If no idle channel resources can be found in any of the service layers

defined for the requested service type, the BSC starts the known procedures to satisfy TCH requests in case of TCH congestion (if enabled):1. preemption (see parameter EPRE in command SET BTS[OPTIONS])2. directed retry (see parameter ENFORCHO in command SET BSC [BASICS])3. queuing (see parameter EQ in command SET BTS [OPTIONS])and, in parallel, also4. multislot call downgrade (see parameter DGRSTRGY in command SET BTS [BASICS]).

Intra-cel l handov er due to ‘preferred s ervice layer ’ When a TCH was allocated on a service layer different from the

preferred one, the BSC resource management task periodically

checks the preferred layer for idle resources and, if a TCH resourceis found, transfers the call by an intra-cell handover to a TRX that belongs to the layer with higher preference. This mechanism is only available for CS services.Moreover, for HSCSD multislot calls that did not receive therequested number of TCH resources, a periodic task tries to movethe CS call to a better Layer with a sufficient number of free channelsas soon as possible to satisfy the multislot requested originally.

Please note that these intracell handovers are only triggered by theBSC if the parameter ENFOIAHO is set to TRUE and MNTBMASK BIT12 is set (both parameters see command SET BSC [BASICS])!

Layers TRXs

Cell

TRX:1

TRX:2

TRX:3

TRX:4

TRX:5

LY_00

LY_01

LY_02

LY_03

TCH request(requestedservice t e =

SLL EFR

SLL (E)FR), HRdefined by

SET BTS [SERVICE]:CRTSWSPELLPRM=LY 01&LY00&LY02

2. layer

1. layer

3. layer





Interworking o f SDCA/MSLS with ‘Cel l Load Dependent

activat ion of Half Rate’ When for an incoming TCH request both (E)FR and HR (or/and

AMR-FR and AMR-HR) are indicated as allowed, the MS’s speechversion preference (indicated in the ASSIGNMENT REQUEST or HANDOVER REQUEST message) is first of all overwritten by theBSC’s speech version preference, which depends on- the activation state of the feature ‘Cell Load Dependent Activation of

Half Rate’ (CLDAHR, see parameters EHRACT and EHRACTAMR incommand SET BTS[BASICS] is enabled) and - the current TCH load in the cell.When the decision for FR or HR has been made, the corresponding SLL for FR is searched first.

If an MS supports all speech codecs and rates (AMR, non-AMR, FR and HR) and FR is preferred (e.g. due to EHRACT and current TCH load) the BSC searches in more than one SLL in the following order:1. SLL for CS AMR FR 2. SLL for CS AMR HR 3. SLL for CS (E)FR/HR Within each SLL, every layer is checked for resources before thesearch in the next SLL is started.

Interworking o f SDCA/MSLS with traff ic load calculat ion

The percentage calculation done for the features Enhanced Pairing and Compression/Decompression Handover (see parametersEPAT1, HRACTT1, HRACTAMRT1, FRACTTH1 and FRACTAMRTH1 in command CREATE BTS [BASICS]) is donereferring only to the TRXs included into the SLLs for relevant to CSspeech AMR service and CS speech services, separately for every subarea (primary / complementary).

SLL search in c ase of cel ls with two separate areas As described above, when a cell is configured as concentric cell or extended cell, two separate SLLs can be defined for each area, i.e. ina concentric cell one for the inner and one for the complete are and in an extended cell one for the near and one for the far area. Themain area’s SLL is called ‘primary’ SLL, the other is called ‘complementary’ SLL.Note: TRXs belonging to different areas (of a concentric or anextended cell) can belong to the same layer (LAYERID), but for eacharea an own separate SLL must be defined.

When a channel is requested in a cell, for every service (except for (E)GPRS services), the ‘complementary ’ SLL is checked first, if theMS is suitably positioned within the TRX’s coverage area and theradio conditions are correspondingly good. Only when no resourcecan be found in the complementary SLL, the primary SLL is searched and the channel request is served if a resource is available.

A downgrade of an incoming multislot call is only performed if noresource can be found in any of the relevant SLLs.

Interworking o f service layers and Idle Channel Supervision If the feature ‘Idle Channel Supervision’ (see parameter INTCLASS in

command SET BTS [INTERF]) is enabled, the resources within eachservice layer are sorted according to their interference class. Within aservice layer, the resource with the best interference class is alwaysallocated first.

Channel al location fo r sign al l ing channels (SDCCH, TCHSD) in

the service layers All the TRXs with channels of type SDCCH, TCHSD inSDCCH_POOL, TCHSD in TCHSD_POOL have to be included in aLayer associated at least to the Signalling SLL, otherwise thesechannels will never be used as singalling channel (TCHSDs inTCHSD Pool can be used also as traffic channels).





If several TCH/SDs are configured in different service layers, theBSC will first allocate a TCH from a less priorized service layer,before its starts to allocate a TCH/SD in TCHSD_POOL located onthe high-priorized service layer.

Service layers for EGPRS Generally for all service types all TRXs associated to a layer of theSLL are available for resource allocation. However, there is oneexception: for EGPRS only those TRXs within the layers of the SLL

can be used for EGPRS resource allocation, that have the parameter TRXMD (see command CREATE TRX) set to the value EDGE.

Interworking of SDCA/MSLS and Direct TCH Assignm ent If Direct TCH Assignment is enabled (see parameter DIRTCHASS incommand SET BTS [OPTIONS]), the SLL associated to ‘signalling’ isused for allocation. This SLL should be defined by the operator insuch a way that the TRXs with less SDCCH and more TCHs arelisted at the top. For call setups with direct TCH assignment, theTCHs are first (i.e. after receipt of the CHANNEL REQUEST message) searched in the SLL defined for signalling (see SLLPRM)and, if the allocated channel does not perfectly match to service typerequested in the ASSIGNMENT REQUEST message, the channel ischanged after receipt of this message (in a similar way as it is doneduring normal change from SDCCH to TCH when direct assignment

is not applied.)

Reservation of (E)GPRS resources in service layers For the management of reserved packet channels in service layersthat are shared between CS and packet services (this happens e.g.when the same service layer is simultaneously included in both theSLL of speech services and GPRS services) four parameters (seecommand CREATE PTPPKF) are used for the reservation:- GMANPRESPRM (old BR7.0 GMANPRES) is the number of reserved channels for GPRS service in the primary area- GMANPRESCOM is the number of reserved channels for GPRSservice in the complementary area (significant only if the cell is anextended cell)- EMANPRESPRM is the number of reserved channels for EGPRSservice in the primary area

- EMANPRESCOM is the number of reserved channels for EGPRSservice in the complementary area (significant only if the cell is anextended cell).The channels are reserved in the first service layer that is defined both in the SLLs for GPRS/EDGE and the SLLs for CS services inthe Primary/Complementary area.

Interworking o f SDCA/MSLS and Dynamic MA IO Al location

(DMA) The feature Dynamic MAIO Allocation (DMA) is only permitted onservice layers that have been configured for CS speech sevices only.In other words, the DMA service layer may only be included in theSLLs defined for CS speech AMR and non-AMR services. If the DMAservice layer is included in the SLL of any other service type(including signalling), the enabling of DMA is rejected by the DBAEM and the BSC command interpreter. >

SET BTS [SERVICE]:


AMRFRLLCOM= LL_00,

object: BTS [SERVICE]

range: 1..12 items max list, and for

each item: LL_00 .. LL_11

default: <NULL>

AMR Ful l Rate layer l ist complementary , this parameter definesthe service layer list (SLL) associated to speech call applying AMR FR codec in the inner/near area of dual area cell (extended,concentric, single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in adecreasing priority order, i.e. the entered sequence of layer-IDsdetermines the layer preference for the resource allocation for this





service.

Attention: The value <NULL> means that for the associated serviceno SLL is defined. If this is the case, the service is regarded as ‘not supported’ in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

AMRFRLLPRM= LL_00,




default: <NULL>

AMR Ful l Rate layer l ist pr im ary , this parameter defines the servicelayer list (SLL) associated to speech call applying AMR FR codec ina single band standard cell, or in the complete/far area of a dual areacell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDsdetermines the layer preference for the resource allocation for thisservice.


AMRHRLLCOM= LL_00,

object: BTS [SERVICE]range: 1..12 items max list, and for


default: <NULL>

AMR Half Rate layer l ist com plementary , this parameter definesthe service layer list (SLL) associated to speech call applying AMR

HR codec in the inner/near area of dual area cell (extended,concentric, single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in adecreasing priority order, i.e. the entered sequence of layer-IDsdetermines the layer preference for the resource allocation for thisservice.


AMRHRLLPRM= LL_00,


range: 1..12 items max list, and for each item: LL_00 .. LL_11

default: <NULL>

AMR Half Rate layer l ist pr imary , this parameter defines the servicelayer list (SLL) associated to speech call applying AMR HR codec ina single band standard cell, or in the complete/far area of a dual area

cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDsdetermines the layer preference for the resource allocation for thisservice.


ASCILLPRM= LL_00,



each item: LL_00 .. LL_11default: <NULL>

ASCI layer l ist p r imary , this parameter defines the service layer list (SLL) associated to ASCI VBS/VGCS services in a single band standard cell, or in the complete/far area of a dual area cell

(extended, concentric single/dual band), or in the BCCH band of adual band standard cell.The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer

preference for the resource allocation for this service.






ELLCOM= LL_00,




default: <NULL>

EDGE layer l ist com plementary , this parameter defines the servicelayer list (SLL) associated to EDGE service in the inner/near area of dual area cell (extended, concentric single/dual band), or in thecomplementary band of a dual band standard cell. The service layersof the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for theresource allocation for this service.


Note: Generally for all service types all TRXs associated to a layer of the SLL are available for resource allocation. However, there is oneexception: for EGPRS only those TRXs within the layers of the SLLcan be used for EGPRS resource allocation, that have the parameter TRXMD (see command CREATE TRX) set to the value EDGE.

ELLPRM= LL_00,




default: <NULL>

EDGE layer l ist pr im ary , this parameter defines list of TRX layersassigned to EDGE service in a single band standard cell, or in thecomplete/far area of a dual area cell (extended, concentric

single/dual band), or in the BCCH band of a dual band standard cell.The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer



Note: Generally for all service types all TRXs associated to a layer of the SLL are available for resource allocation. However, there is oneexception: for EGPRS only those TRXs within the layers of the SLLcan be used for EGPRS resource allocation, that have the parameter TRXMD (see command CREATE TRX) set to the value EDGE.

GLLCOM= LL_00,




default: <NULL>

GPRS layer l ist com plementary , this parameter defines the servicelayer list (SLL) associated to GPRS service in the inner/near area of dual area cell (extended, concentric single/dual band), or in thecomplementary band of a dual band standard cell. The service layersof the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for theresource allocation for this service.


GLLPRM= LL_00,




default: <NULL>

GPRS layer l ist pr im ary , this parameter defines list of TRX layers

assigned to GPRS service in a single band standard cell, or in thecomplete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell.The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer







HSCSDLLCOM= LL_00,




default: <NULL>

HSCSD layer l ist com plementary , this parameter defines theservice layer list (SLL) associated to HSCSD service in the inner/near area of dual area cell (extended, concentric single/dual band), or inthe complementary band of a dual band standard cell. The servicelayers of the SLL are defined in a decreasing priority order, i.e. theentered sequence of layer-IDs determines the layer preference for the resource allocation for this service.

Attention: The value <NULL> means that for the associated service

no SLL is defined. If this is the case, the service is regarded as ‘not supported’ in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

HSCSDLLPRM= LL_00,




default: <NULL>

HSCSD layer l ist pr imary , this parameter defines list of TRX layersassigned to HSCSD service in a single band standard cell, or in thecomplete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell.The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer



SLLPRM= LL_00,




default: <NULL>

Signal ing layer l ist pr imary , this parameter defines list of TRX layers assigned to services that require only a signalling channel in asingle band standard cell, or in the complete/far area of a dual areacell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDsdetermines the layer preference for the resource allocation for thisservice.

Attention: The value <NULL> means that for the associated serviceno SLL is defined. If this is the case, the service is regarded as ‘not supported’ in the cell. If the service shall be supported, at least LY_00

must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).





Setting the cell specific attributes for Power Control:

" For detailed information regarding the Power Control thresholdsplease refer to the chapter Appendix, section “Power ControlThresholds & Algorithms” and “Interworking of Handover andPower Control”!

SET PWRC:

NAME=BTSM:0/BTS:0/PWRC:0,

Object path name .

EBSPWCR=TRUE,

object: PWRC

range: TRUE, FALSE

default: TRUE

Enable BS power contro l cor rect ion , this parameter is necessary to ensure full handover functionality if BS power control is enabled while channels are created with frequency hopping system and thehopping system involves the BCCH TRX (baseband frequency hopping only, see parameter HOPMODE=BBHOP in command SET BTS BTS [OPTIONS]).Normally, if BS PWRC is enabled the MS is informed about this by aflag in the SYSTEM INFORMATION (see parameter EBSPWRC).This flag makes the MS suppress measurement reports derived fromthe BCCH carrier in order to avoid the measurements to be falsified by the ‘full power’ part of the BCCH (PWRC must not be used on theBCCH carrier).

If frequency hopping is configured for the TCHs (see parameter FHSY and MAIO in command CREATE CHAN) but disabled, whichcan happen either if hopping is manually disabled (SET BTS[OPTIONS]: HOPP=FALSE) or automatically disabled (e.g. due tofailure of a TRX involved in a baseband FH system) – a frequency redefinition procedure is started which instructs the MSs in a cell tochange the hopping system in such a way that hopping shall continuewith one frequency only (which is always that frequency which isassigned to the TRX by parameter TRXFREQ in command CREATE TRX). Calls that are served by a radio TCH which belongs to theBCCH TRX will in this case hop on the BCCH frequency only. In thiscase all measurement reports are suppressed (or declared ‘not valid’)by the MS - which means that neither handover nor power control is

possible for these calls.

Setting this parameter to TRUE has the following results:a) The BS PWRC flag is permanently set to ‘0’(=disabled) in theSYSTEM INFORMATION TYPE 6 even if the database parameter indicates the opposite (EBSPWRC=CLASSIC or EBSPWRC=ADAPTIVE).b) The MS thus provides valid measurement reports even for theBCCH carrier.c) The BTS takes care that the ‘full power’ part from the BCCH carrier is correctly subtracted from the DL RXLEV values reported in theMEASUREMENT REPORTs.

Note: the BS Power Control Correction is managed differently for AMR-calls and non-AMR calls (due to introduction of CR 1435) incorrespondence with the following table:

EBSPWRC EBSPWCR PWRC -Flag in SYSINFO-6 andMEASINFO to MS

for non-AMR calls for AMR calls

CLASSIC/ADAPTIVE TRUE 0 1

CLASSIC/ADAPTIVE FALSE 1 1

DISABLED TRUE 0 0

DISABLED FALSE 0 0





EBSPWRC=ADAPTIVE,

object: PWRC

range: CLASSIC, ADAPTIVE,

DISABLED

default: ADAPTIVE

(for BTSs in SW BR7.0)

CLASSIC

(for BTSs in SW < BR7.0)


GSM 04.08

GSM 05.05

GSM 12.20

Enable BS power cont rol , determines whether the BTS dynamically adjusts its sending power according to the current radio conditions(on non-BCCH carriers). Enabling BS Power Control results in aminimization of the downlink interference on the radio interface.Whether the sending power is to be increased or decreased isdetermined from the downlink measurement reports the MS sends tothe BTS. This parameter is sent on the BCCH (SYSTEM

INFORMATION TYPE 3) or on the SACCH (SYSTEM INFORMATION TYPE 6) in the IE ‘Cell Options’.

Two variants of BS power control can be selected: CLASSIC power control and ADAPTIVE power control. While ‘classic’ BS power control exclusively uses fixed power increase steps (see parameter PWRINCSS) and fixed power reduction steps (see parameter PWREDSS), the ‘adaptive’ BS power control uses power increaseand reduction step sizes that depend on the current radio conditionsdefined by RXLEV and REXQUAL values.

For further details about the power control decision process and classic and adaptive power control, please refer to the section ‘Power Control’ in the section “ Classic and Adaptive Power Control ” in theappendix of this document.

Note: Under specific conditions, the BS power control decisionalgorithm also checks the ‘missing SACCH’ counter (S-counter, initial value defined by RDLNKTBS): If no SACCH report was received in a

particular SACCH period, no PC decision will be made for the DL.Field experiences have shown that under specific circumstances it can happen that, e.g. due to excessive path inbalance, the MSreports very good RXLEV_DL values, but the BTS cannot correctly decode all received SACCH frames in the UL. As the BS power control decision is based on the measurement samples stored in theaveraging window (if an UL SACCH cannot be decoded, this just means that no new sample is inserted into the window), theRXLEV_DL average value could suggest a further DL power decrease. To avoid this behaviour, the following mechanism wasimplemented:If the S-counter is more than 2 below RDLNKTBS (i.e. either at least three SACCH reports in a row were missed or the current SACCH report is missing and additional SACCHs were missing before) then anormal BTS power increase will be commanded (if the interval timer is not running). Please consider that with the current default values(RDLNKTBS=20 and PCTHRLF=18) the abovementioned conditionsare met (RDLNKTBS minus 2 counts) and thus PWRC will increasethe power to the maximum instead of increasing the power by anormal power control step. If a power increase was executed thenormal power control interval timer (PCONINT in case of ‘classic’, or PAVRQUAL in case of ‘adaptive’ power control) is started, so that anew power increase due to missing SACCH reports may only betriggered once the interval timer has expired. This way it is ensured that during periods of (or single) missing SACCH reports the DL

power control does not further decrease the power but rather increases it in normal steps if the situation persists until the RLFW istriggered or the normal function resumes.





EMSPWRC= ADAPTIVE,

object: PWRC

range: CLASSIC, ADAPTIVE,

DISABLED

default: ADAPTIVE

(for BTSs in SW BR7.0)

CLASSIC

(for BTSs in SW < BR7.0)Reference: GSM 05.08

GSM 04.08

GSM 05.05

GSM 12.20

Enable MS power contro l , determines whether the BTS instructsthe MS to dynamically adjust its sending power according to thecurrent radio conditions. MS Power Control is used to save MSbattery capacity and to minimize the uplink interference on the radiointerface. If MS power control is disabled, the BTS instructs every MSin the concerned cell to use the maximum RF output power asdefined by the parameter MSTXPMAXGSM (resp. MSTXPMAXDCS

or MSTXPMAXPCS, see CREATE BTS [BASICS]) or by the MS power class - whichever is the lower. If MS power control is enabled the MS adjusts the power according to appropriate commandsreceived from the BTS. The BTS generates these commands after evaluation of uplink measurement results.

Two variants of MS power control can be selected: CLASSIC power control and ADAPTIVE power control. While ‘classic’ MS power control exclusively uses fixed power increase steps (see parameter PWRINCSS) and fixed power reduction steps (see parameter PWREDSS), the ‘adaptive’ MS power control uses power increaseand reduction step sizes that depend on the current radio conditionsdefined by RXLEV and REXQUAL values.

For further details about the power control decision process and classic and adaptive power control, please refer to the section ‘Power Control’ in the section “Classic and Adaptive Power Control” in theappendix of this document.

EPWCRLFW=TRUE,

object: PWRC

range: TRUE, FALSE

default: TRUE


MS and BS pow er control indicat ion du e to ‘radio l ink fai lure

warning' enabled , this parameter enables/disables the “BS and MS power control due to radio link failure warning”. This feature checksthe radio link counter (also called ‘S’ counter) in the BTS, whoseinitial value is determined by the parameter RDLNKTBS (see below)and which is decreased by ‘1’ if an UL SACCH frame could not becorrectly decoded. As a not successfully decoded UL SACCH frameis a clear indication for serious radio interface problems, the BTSincreases the MS and BS transmit power to the maximum when theradio link counter has reached the value set by the parameter

parameter PCRLFTH (see below).

LOWTLEVD=25,

object: PWRC

unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 25


Power control lower threshold level down l ink , defines the lower threshold of the received signal level on the downlink for power increase.The following rule has to be considered:HOLTHLVDL (SET HAND) < LOWTLEVD

< [LOWTLEVD (SET PWRC) + 2 ∗ PWREDSS (SET PWRC)] < UPTLEVD (SET PWRC)

LOWTLEVU=25,

object: PWRC

unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 25


Power control low er threshold level upl ink , defines the lower threshold of the received signal level on the uplink for power increase.The following rule has to be considered:HOLTHLVUL (SET HAND) < LOWTLEVU

< [LOWTLEVU (SET PWRC) + 2 ∗ PWREDSS (SET PWRC)] < UPTLEVU (SET PWRC)





LOWTQUAD=4,

object: PWRC

unit: 1 dB

range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%

2 = 0,4% to 0,8%

3 = 0,8% to 1,6%4 = 1,6% to 3,2%

5 = 3,2% to 6,4%

6 = 6,4% to 12,8%

7 = greater than 12,8%

default: 4


Power control lower threshold qual i ty dow nl ink , defines the lower threshold of the received signal quality on the downlink for power increase.The following rule has to be considered:HOLTHQUDL (SET HAND) > LOWTQUAD (SET PWRC)> UPTQUAD (SET PWRC)

LOWTQUAMRDL=10,

object: PWRC

unit: 1 dB

range: 0 .. 30

default: 10

Power control lower threshold qual i ty AMR downl ink , this parameter eclipses the threshold LOWTQUAD in case of an AMR (Adaptive Multi Rate) call: For AMR calls, the power control algorithmincreases the DL transmit power if the downlink quality drops below the threshold determined by LOWTQUAMRDL.

Attention: Unlike for the parameter LOWTQUAD, for which the quality values are entered in RXQUAL values (range 0..7), the values for LOWTQUAMRDL are entered in C/I values (carrier/interference in

[dB]). The BTSE-internal processing of these values is done in thefollowing way:- Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (range 0..7)in the MEASUREMENT REPORT messages.- From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter PAVRQUAL. The resulting average RXQUAL value iscalculated with a resolution of two places (digits) after the comma(this is achieved by multiplying the RXQUAL values with 100 beforeaveraging).- The resulting ‘high-precision’ RXQUAL value is then mapped to aninteger C/I value according to the following table:

RXQUAL C/I RXQUAL C/I6,88 ... 7 1 3,88 ... 4,12 12

6,63 ... 6,87 2 3,38 ... 3,87 13

6,38 ... 6,62 4 2,88 ... 3,37 14

6,13 ... 6,37 5 2,63 ... 2,87 15

5,88 ... 6,12 6 2,13 ... 2,62 16

5,63 ... 5,87 7 1,63 ... 2,12 17

5,13 ... 5,62 8 1,13 ... 1,62 18

4,88 ... 5,12 9 0,38 ... 1,12 19

4,63 ... 4,87 10 0 ... 0,37 20

4,13 ... 4,62 11

For a more detailed mapping table please refer to the section “Mapping of RXQUAL and C/I values for AMR calls” in the appendix of this document.

- The integer C/I value is then compared to the threshold determined by LOWTQUAMRDL. If it drops below the threshold, the BTSincreases the DL transmit power.

Notes:- Although the total value range of LOWTQUAMRDL is 0..30, themapping limits the maximum useful C/I value to 20dB (see mapping table above). C/I threshold values above 20dB therefore can never be reached and will not show any effect.- In order to achieve a suitable accuracy of the RXQUAL averagevalue for AMR calls, it is recommended to use a minimum RXQUALaveraging window size of 4 (see parameter PAVRQUAL).





LOWTQUAU=4,

object: PWRC

range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%

2 = 0,4% to 0,8%

3 = 0,8% to 1,6%

4 = 1,6% to 3,2%

5 = 3,2% to 6,4%6 = 6,4% to 12,8%


default: 4


Power control lower threshold qual i ty upl ink , defines the lower threshold of the received signal quality on the uplink for power increase.The following rule has to be considered:HOLTHQUUL (SET HAND) > LOWTQUAU (SET PWRC)> UPTQUAU (SET PWRC)

LOWTQUAMRUL=10,

object: PWRC

unit: 1 dB

range: 0..30

default: 10

Power control low er threshold qual i ty AMR upl ink , this parameter eclipses the threshold LOWTQUAU in case of an AMR (AdaptiveMulti Rate) call: For AMR calls, the power control algorithm increasesthe DL transmit power if the uplink quality drops below the threshold determined by LOWTQUAMRUL.

Attention: Unlike for the parameter LOWTQUAU, for which the quality values are entered in RXQUAL values (range 0..7), the values for LOWTQUAMRUL are entered in C/I values (carrier/interference in[dB]). The BTSE-internal processing of these values is done in the

following way:- As usual, the BTS measures the uplink quality in RXQUAL values(range 0..7).- From the measured RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter PAVRQUAL. The resulting average RXQUAL value iscalculated with a resolution of two places (digits) after the comma(this is achieved by multiplying the RXQUAL values with 100 beforeaveraging).- The resulting ‘high-precision’ RXQUAL value is then mapped to aninteger C/I value according to the table included in the parameter description of LOWTQUAMRDL (see above).- The integer C/I value is then compared to the threshold determined by LOWTQUAMRUL. If it drops below the threshold, the BTS

increases the UL transmit power. Notes:- Although the total value range of LOWTQUAMRDL is 0..30, themapping limits the maximum useful C/I value to 20dB (see mapping table for LOWTQAMRDL). C/I threshold values above 20dB thereforecan never be reached and will not show any effect.- In order to achieve a suitable accuracy of the RXQUAL averagevalue for AMR calls, it is recommended to use a minimum RXQUALaveraging window size of 4 (see parameter PAVRQUAL).





PAVRLEV=4-2,

object: PWRC

format: averaging period-

DTX weighting factor


=480ms

(averaging period)

range: 1-31 (averaging period)1-3 (DTX weighting factor)


2 (DTX weighting factor)


Power con trol averaging parameters level , defines the averaging parameters for the RXLEV measurements.

Parameter format: averaging period - DTX weighting factor

All measurements for Power Control pass an averaging algorithm.The algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate the

arithmetic average. The averaging window is called “gliding”, as thewindow works as a queue: when a new measurement is received, theoldest measurement is removed from the window.

The PAVRLEV “averaging period” defines the size of the gliding averaging window for the measured RXLEV values. The size of theaveraging window determines the number of measurement samples(a new measurement sample is received every 480 ms from theMEASUREMENT REPORTs from the BTS and the MS) over whichthe BTS calculates the arithmetic average. This calculated value isfinally used in the Power Control decision process.

The DTX weighting factor determines how much more the FULLvalues shall be weighted for radio measurement results measured over a period with voice activity (DTX not active).

Up to BR6.0, the higher weighting was implemented by the multiple

insertion of the FULL measurement sample into the gliding averaging window. In other words, if the DTX weighting factor was set to “2”,FULL measurement samples from measurement periods with inactiveDTX (speech transmitted) were inserted into the averaging window twice, while SUB measurement samples from measurement periodswith active DTX (silence) were inserted into the averaging window only once (for further details about DTX and the meaning of FULLand SUB values please refer to the explanations provided for the

parameter DTXDLFR).

Starting from BR7.0, this approach has been changed:FULL measurement samples values for non-DTX channels no longer entered n-times into the averaging window anymore but every valuewill be entered once. In addition, the current weighting factor is stored in parallel under the same offset as shown in the following picture:

Thus the time needed to fill the averaging window will always be thesame (i.e. only dependent on the ‘laveraging period’ portion of the

parameter PAVRLEV). The averaging window total is then calculated by adding up all sample values currently stored in the within theaveraging window while a single sample is added number of ‘weight’ times. Then the total is divided by the ‘weight’ total (i.e. all ‘weight’

values within the averaging window are added up).Note: In the SDCCH phase there are no TCH speech frames. For thisreason only the SUB values (determined from the SACCH frames)are considered for the handover decision which are – as usual –inserted into the averaging window as single values only.

0 4321 98765 3029

0 4321 00065 00sample

offset

length

max_av_win_size

1 2111 00012 00weight





PAVRQUAL=4-2,

object: PWRC

format: averaging period-

DTX weighting factor unit: 1 SACCH multiframe

=480ms

(averaging period)

range: 1-31 (averaging period)1-3 (DTX weighting factor)




Power contro l averaging p arameters qual i ty , defines theaveraging parameters for the RXLEV measurements.


All measurements for Power Control pass an averaging algorithm.The algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate the

arithmetic average. The averaging window is called “gliding”, as thewindow works as a queue: when a new measurement is received, theoldest measurement is removed from the window.

The PAVRLEV “averaging period” defines the size of the gliding averaging window for the measured RXQUAL values. The size of theaveraging window determines the number of measurement samples(a new measurement sample is received every 480 ms from theMEASUREMENT REPORTs from the BTS and the MS) over whichthe BTS calculates the arithmetic average. This calculated value isfinally used in the Power Control decision process.

The DTX weighting factor determines how much more the FULLvalues shall be weighted for radio measurement results measured over a period with voice activity (DTX not active). For further information about the management of the DTX weigthing factor

please refer to the explanations provided for the parameter PAVRLEV.

Notes:- In the SDCCH phase there are no TCH speech frames. For thisreason only the SUB values (determined from the SACCH frames)are considered for the handover decision which are – as usual –inserted into the averaging window as single values only.- If AMR is used, it is recommended to use a minimum RXQUALaveraging window size of 4 in order to achieve a suitable accuracy of the RXQUAL average value for AMR calls.





e.g. PAVRLEV/PAVRQUAL=4-x Æ PCONINT=2, wait 4 SACCH multiframes (since the granularity of PCONINT is 2 SACCH multiframes the value should be rounded to the next higher value incase the longest averaging window length has an odd value).

If the PWRC mode is set to 'adaptive' (see parameters EBSPWRC and EMSPWRC) this suspension timer will only be started if the

power level was changed due to a decision based on signal quality,since with the 'adaptive' mode the level samples will be automatically

corrected by the value of the power level change and thereforePWRC can resume immediately after a level based decision without having to wait for the collection of new level samples. Since thesuspension timer is now only started in case of quality based decisions and the level samples are automatically corrected, there isonly the need to wait for the collection of all new quality samples.Therefore the PWRC algorithm sets the timer length automatically tothe time needed to re-fill the quality averaging window, so that thevalue of PCONINT is not relevant in case of the 'adaptive' PWRC mode!

PCRLFTH=18,

object: PWRC

range: 0..64

default: 18Reference: GSM 05.08

Power control radio l ink fai lure threshold , this parameter is only relevant if the parameter EPWCRLFW (see above) is set to TRUE. It defines the threshold value for the radio link counter in the BTS for the ‘radio link failure warning’ detection. If the radio link counter in the

BTS reaches the value of PCRLFTH, the BTS immediately increasesthe BS and MS transmit power to the maximum.

Please see also parameter RDLNKTBS.

PWRCONF=2,

object: PWRC

unit: 2 SACCH multiframes

range: 1-31

default: 2


Power confi rmation interval , defines the maximum interval that theBTS will wait for the confirmation of a newly set RF power level by the MS in units of 2 SACCH multiframes. The timer administered withPWRCONF is started after a new MS power level was set. As long asthis timer is running the BTS compares the received MS power level with the requested power level. If the timer expires before the MSconfirmed the requested power level the power control decision

process is resumed.

PWRINCSS=DB6,

object: PWRCunit: 2dB

range: DB2, DB4, DB6

default: DB6


Power increase step size , defines the step size used whenincreasing the MS transmit power.

PWREDSS=DB2,

object: PWRC

unit: 2dB

range: DB2, DB4

default: DB2


Power reduction step size , defines the step size used whenreducing the MS transmit power.





RDLNKTBS=20,

object: PWRC

range: 4-64

step size: 4 (range 4, 8, 12, ... 60, 64)

default: 20


GSM 05.08

Radio l ink counter BS , indicates the maximum value of the radiolink counter needed to detect a radio link failure in the uplink. Theentered value is the start point for the ‘radio link counter’ (also called ‘missing SACCH’ counter or ‘Scounter’) in the BTS which is managed for every dedicated channel (TCH or SDCCH). Unsuccessful decoding of uplink SACCH messages (i.e. MEASUREMENT REPORTs) in the BTS lead to a decrease of the counter by 1,

successful decoding to an increase by 2 (a similar counter for theobservation of raio link problems is also used in the MS (see

parameter RDLNKTO in command CREATE BTS [BASICS]). If the parameter EPWCRLFW is set to TRUE and the BTS radio link counter counter reaches the value entered for the parameter PCRLFTH (see above) the BTS initiates the adjustment of the MStransmit power and BS transmit power to maximum transmit power. If the counter reaches the value 0 (‘radio link timeout’), the BTS sendesa CONNECTION FAILURE INDICATION with cause 'radio link failure' to the BSC which initiates the release of the whole dedicated connection. This scenario represents (together with the ERROR INDICATION with cause ‘T200 expired (N200+1) times’ (see

parameter T200 in command SET BTS [TIMER])) the most commonand ‘classic’ case of a call drop.

Rule: RDLNKTBS > PCRLFTH .Notes:- An expiry of the radio link counter in the MS (see RDLNKTO incommand CREATE BTS [BASICS]) also indirectly leads to the ‘radiolink timeout’ in the BTS, as in this case the MS stops any transmission activity on the dedicated channel. This leads tounsuccessful decoding of UL SACCH frames in the BTS (as the MSdoes not send any SACCH frames anymore) and thus to thecontinuous decrease of the BTS radio link counter.- The current value of the S-Counter in the BTS is also checked inthe scope of the BS power control (parameter EBSPWRC, seeabove) decision: If no SACCH report was received in a particular SACCH period, no PC decision will be made for the DL (BS Power Control). If the ‘missing SACCH’ counter (S-counter, initial value

defined by RDLNKTBS) is more than 2 below RDLNKTBS (i.e. either at least three SACCH reports in a row were missed or the current SACCH report is missing and additional SACCHs were missing before) then a normal BTS power increase will be commanded.

SG1PCPAR=<NULL>,

object: PWRC

range: <NULL>,

12 fields with ranges in

correspomdemce with the

PWRC parameters they

represent.

default: <NULL>

Service group 1 power contro l parameters , this parameter is thefirst of the 14 parameters which allows a service group-dependent setting of power control parameters and thresholds.

The setting <NULL> indicates that for this service group no specific parameter settings are applied and the power controld decision for this service group is based the ordinary PWRC parameter settings.

Fo further details please refer to the section “ Service dependent Handover and Power Control ” in the appendix of this document.

SG2PCPAR...SG14PCPAR=<

NULL>,

object: PWRC

range: <NULL>,

n fields with ranges in

correspondence with the


represent.

default: <NULL>

Service group 2..14 pow er contro l parameters , these parameters

represent the remaining 13 parameters which allow a service group-dependent setting of power control parameters and thresholds.

The setting <NULL> indicates that for the affected service group nospecific parameter settings are applied and the power controld decision for this service group is based the ordinary PWRC

parameter settings.

Fo further details please refer to the section “ Service dependent Handover and Power Control ” in the appendix of this document.





UPTLEVD=36,

object: PWRC

unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...62 = -48dBm


default: 36



Power control upper threshold level down l ink , defines the upper threshold of the received signal level on the downlink for power reduction.The following rule has to be considered:UPTLEVD (SET PWRC)

> [LOWTLEVD (SET PWRC) + 2 ∗ PWREDSS (SET PWRC)] > LOWTLEVD > HOLTHLVDL (SET HAND)

To guarantee a correct interworking of power control and intracell handover, the following rule must be fulfilled:

UPTLEVD > HOTDLINT

For further details please refer to the section ‘Handover Thresholdsand Algorithms’ in the appendix of this document.

UPTLEVU=36,

object: PWRC

unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...62 = -48dBm


range: 0..63

default: 36



Power control upp er threshold level upl ink , defines the upper threshold of the received signal level on the uplink for power reduction.The following rule has to be considered:UPTLEVU (SET PWRC)

> [LOWTLEVU (SET PWRC) + 2 ∗ PWREDSS (SET PWRC)] > LOWTLEVU > HOLTHLVUL (SET HAND)


UPTLEVU > HOTULINT


UPTQUAD=2,

object: PWRC

range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%

2 = 0,4% to 0,8%

3 = 0,8% to 1,6%

4 = 1,6% to 3,2%5 = 3,2% to 6,4%

6 = 6,4% to 12,8%


default: 2


Power contro l upper thresho ld qua l i ty downl ink , defines theupper threshold of the received signal quality on the downlink for

power reduction.The following rule has to be considered:UPTQUAD (SET PWRC) < LOWTQUAD (SET PWRC)< HOLTHQUDL (SET HAND)





UPTQUAMRDL=13,

object: PWRC

unit: 1 dB

range: 0..30

default: 13

Power control upper threshold qual i ty AMR downl ink , this parameter eclipses the threshold UPTQUAD in case of an AMR (Adaptive Multi Rate) call: For AMR calls, the power control algorithmreduces the DL transmit power if the downlink quality exceeds thethreshold determined by LOWTQUAMRDL.

Attention: Unlike for the parameter UPTQUAD, for which the quality values are entered in RXQUAL values (range 0..7), the values for

UPTQUAMRDL are entered in C/I values (carrier/interference in[dB]). The BTSE-internal processing of these values is done in thefollowing way:- Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (range 0..7)in the MEASUREMENT REPORT messages.- From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter PAVRQUAL. The resulting average RXQUAL value iscalculated with a resolution of two places (digits) after the comma(this is achieved by multiplying the RXQUAL values with 100 beforeaveraging).- The resulting ‘high-precision’ RXQUAL value is then mapped to aninteger C/I value according to the following table:

RXQUAL C/I RXQUAL C/I

6,88 ... 7 1 3,88 ... 4,12 12

6,63 ... 6,87 2 3,38 ... 3,87 13

6,38 ... 6,62 4 2,88 ... 3,37 14

6,13 ... 6,37 5 2,63 ... 2,87 15

5,88 ... 6,12 6 2,13 ... 2,62 16

5,63 ... 5,87 7 1,63 ... 2,12 17

5,13 ... 5,62 8 1,13 ... 1,62 18

4,88 ... 5,12 9 0,38 ... 1,12 19

4,63 ... 4,87 10 0 ... 0,37 20

4,13 ... 4,62 11


- The integer C/I value is then compared to the threshold determined by UPTQUAMRDL. If it exceeds the threshold, the BTS reduces theDL transmit power.

Notes:- Although the total value range of UPTQUAMRDL is 0..30, themapping limits the maximum useful C/I value to 20dB (see mapping table above). C/I threshold values above 20dB therefore can never be reached and will not show any effect.- In order to achieve a suitable accuracy of the RXQUAL averagevalue for AMR calls, it is recommended to use a minimum RXQUALaveraging window size of 4 (see parameter PAVRQUAL).

UPTQUAMRUL=13,

object: PWRC

unit: 1 dB

range: 0..30

default: 13

Power control upp er threshold qual i ty AMR upl ink , this parameter eclipses the threshold UPTQUAU in case of an AMR (Adaptive Multi Rate) call: For AMR calls, the power control algorithm reduces the ULtransmit power if the uplink quality exceeds the threshold determined by UPTQUAMRUL.

Attention: Unlike for the parameter UPTQUAU, for which the quality values are entered in RXQUAL values (range 0..7), the values for UPTQUAMRUL are entered in C/I values (carrier/interference in[dB]). The BTSE-internal processing of these values is done in thefollowing way:- As usual, the BTS measures the uplink quality in RXQUAL values





(range 0..7).- From the measured RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter PAVRQUAL. The resulting average RXQUAL value iscalculated with a resolution of two places (digits) after the comma(this is achieved by multiplying the RXQUAL values with 100 beforeaveraging).- The resulting ‘high-precision’ RXQUAL value is then mapped to an

integer C/I value according to the table included in the parameter description of UPTQUAMRDL (see above).- The integer C/I value is then compared to the threshold determined by UPTQUAMRUL. If it exceeds the threshold, the BTS reduces theUL transmit power.

Notes:- Although the total value range of LOWTQUAMRDL is 0..30, themapping limits the maximum useful C/I value to 20dB (see mapping table for UPTQUAMRDL). C/I threshold values above 20dB thereforecan never be reached and will not show any effect.- In order to achieve a suitable accuracy of the RXQUAL averagevalue for AMR calls, it is recommended to use a minimum RXQUALaveraging window size of 4 (see parameter PAVRQUAL).

UPTQUAU=2;

object: PWRC

range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%

2 = 0,4% to 0,8%

3 = 0,8% to 1,6%

4 = 1,6% to 3,2%

5 = 3,2% to 6,4%

6 = 6,4% to 12,8%


default: 2


Power control upper threshold qual i ty upl ink , defines the upper

threshold of the received signal quality on the uplink for power reduction.The following rule has to be considered:UPTQUAU (SET PWRC) < LOWTQUAU (SET PWRC)< HOLTHQUUL (SET HAND)





Power Control Parameter Relations

Power Contro l

Power Contro l Ind iact ion due to

l ink fa i lure warn ing

PWRC: EPWCRLFW

PCRLFTH

RDLNKTBS

BS Power Contro l

PWRC: EBSPWRC

LOWTLEVD

LOWTQUAD

(is for AMR replaced byLOWTQAMRDL)

UPTLEVD

UPTQUAD

(is for AMR replaced by

UPTQAMRDL)

EBSPWCR

PCMBSTXPRL

MS Power Contro l

PWRC: EMSPWRC

LOWTLEVU

LOWTQUAU

(is for AMR replaced byLOWTQAMRUL)

UPTLEVU

UPTQUAU

(is for AMR replaced by

UPTQAMRUL)

Parameters re levant for both MS and BS Power Contro l

PWRC: PWRINCSS

PWREDSS

PAVRLEV

PAVRQUAL

PCONINT

PWRCONF





Creating the GPRS point to point packet transfer service in a cell:

< The PTPPKF functional object represents the point to point servicein a cell. In GSM 08.18, for point to point packet transfer, it isspecified that a cell is identified by a BVCI so there is a relation oneto one from cell and BVCI. The BVCI is allocated by the system toeach PTPPKF according to the creation position in the database:BVCI=2 for the first PTPPKF, BVCI=3 for the second PTPPKF, etc. >

CREATE PTPPKF:

NAME=BTSM:0/BTS:0/PTPPKF:0,

Object path name , range for PTPPKF: 0..0.

ABUTYP=ACBU8BIT,

object: PTPPKF

range: ACBU8BIT, ACBU11BIT

default: ACBU8BIT


Access burst type , this parameter indicates the type of access burst used on uplink PDCH (PACCH or PRACH). The value ACBU8BIT means that the 8 bits access burst shall be used by the mobilestation and ACBU11BIT means that 11 bits access bursts shall beused by mobile station (see GSM 05.02).

Access Bursts are mainly used on the PRACH to access the systemor – currently more common – as blocks of four identical accessbursts coding a PACKET CONTROL ACK message.

This parameter corresponds to the GSM parameter

ACCESS_BURST_TYPE.

ALPHA=3,

object: PTPPKF

unit: 0.1

range: 0..10

0=0.0, 1=0.1, ... 10=1.0

default: 3


Alpha value , this parameter specifies the ALPHA value applied inthe UL power control algorithm used with GPRS/EDGE.The MS uses an UL power value according to GSM 05.08:Pch = min ( Γ 0 – Γ ch – α * (C + 48), Pmax)- Pch is the MS ouput power - Γ 0 is a constant value- Γ ch is given by the parameter GAM (object PTPPKF)- C is the normalized receive level at the MS- Pmax is the maximum MS output power Based on the above formula, the parameter ALPHA determines theinfluence of the MS receive level on the MS output power calculation.With Γ ch being a constant value in BR70 we get the 2 extremes:α =0: C has no influence on the MS power –> Pch = const.α >0: The MS power depends on the C-value -> open loop PC

Hint: BR70 does not provide a DL Power Control on GPRS timeslots.Each PDCH is transmitted with the maximum possible power.

BCGRWEI=1,

object: PTPPKF

range: 1...32

default: 1

Background weight , this parameter represents the weight for background class, (scheduling priority 4).

BEPFIDLWEI=1,

object: PTPPKF

range: 1...32

default: 1

Best effort PFIDL weight , this parameter represents the weight for predefined PFI best effort in DL.

BEPAVGP=5,

object: PTPPKF

range: 0..15

default: 5


Bit error probabi l i ty averaging period , this parameter is broadcast inside the (packet) system information messages PSI1, PSI13 or SI13. It is used in the mobile as filter constant for EGPRS channel quality measurements according to GSM 45.008 Chapter 10.2.3.2.1.The measurement results are reported to the network as EGPRSChannel Quality Report inside the EGPRS PACKET DOWNLINK

ACK/NACK messages.





BLERAVEDL=UNIT200,

object: PTPPKF

range: UNIT025, UNIT050

UNIT075, UNIT100

UNIT150, UNIT200

UNIT250, UNIT300

UNIT350, UNIT400

default: UNIT200


Block error rate averaging period do wnl ink , this parameter isrelevant for GPRS and EDGE and is used as averaging period for theBlock Error Rate (BLER) calculation for a downlink TBF. The BLER value is used as base for the link adaptation algorithm (dynamic switch of coding schemes). The BLERAVDL value is based on frame

periods of 20 ms, thus the unit for the entered value is 20ms. Theaveraging period for BLER calculation additionally depends on the

number of radio timeslots allocated to a TBF and is calculated according to the following formula:

TAVGBLER = BLERAVEDL ∗ 20ms / #TS

where

TAVGBLER = BLER averaging period

#TS = number of radio timeslots used for the TBF

As a coding scheme upgrade or downgrade is only possible when theBLER averaging window was completely filled, TAVGBLER alsodefines the minimum time to pass between two consecutiveupgrade/downgrade steps.

Examples:

a) Mobile SIEMENS S45 used (4 timeslots in DL; 1 timeslot in UL).If 4 timeslots are used in DL, the minimum time between two

consecutive coding scheme changes with BLERAVEDL=UNIT400 is

TAVGBLER = (400 frames ∗ 20ms) / 4 = 2s

This means that a switchover from CS1 to CS4 (i.e. three transitions)theoretically takes a minimum of 6 seconds.

b) If only 1 timeslot is used for a GPRS DL TBF, the minimum timebetween two consecutive changes with BLERAVEDL=UNIT400 is

TAVGBLER = (400 frames ∗ 20ms) / 1 = 8s

This means that in this case a switchover from CS1 to CS4 (i.e. threetransitions) theoretically takes a minimum of 24 seconds.

BLERAVEUL=UNIT100,

object: PTPPKF

range: UNIT025, UNIT050UNIT075, UNIT100

UNIT150, UNIT200

UNIT250, UNIT300

UNIT350, UNIT400

default: UNIT100


Block error rate averaging period upl ink , this parameter is relevant for GPRS and EDGE and is used as averaging period for the Block Error Rate (BLER) calculation for an uplink TBF. The value is

expressed in unit of 20 ms. The averaging period depends also onthe number of radio timeslots (#TS) allocated to a radio timeslots,according to the formula:

TAVGBLER = BLERAVEUL / #TS.

Please refer to the parameter BLERAVEDL for further details.

BPAGCHR=7,

object: PTPPKF

range: 0..12

default: 7


BS PAGCH blocks reserved , this parameter specifies the number of blocks reserved for PAGCH, PDTCH and PACCH for the 52 framesmultiframe case (see GSM 05.02). The parameter is coded according to the following table:

0 0 0 0 0 blocks reserved for PAGCH, PDTCH and PACCH0 0 0 1 1 blocks reserved for PAGCH, PDTCH and PACCH

… …1 1 0 0 12 blocks reserved for PAGCH, PDTCH and PACCH

This parameter corresponds to the GSM parameter BS_PAG_BLKS_RES.Note: The system does not refuse entering senseless values whichmay cause blocking of the PBCCH functionality itself (e.g. reserving 12 PAGCH blocks leaving no PPCH blocks!).





BPRACHR=4,

object: PTPPKF

range: 0..12

default: 4


BS PRACH blocks reserved , this parameter specifies the number of blocks reserved in a fixed way to the PRACH channel on any PDCH carrying PCCCH and PBCCH (see GSM 05.02). The parameter iscoded according to the following table:

coding blocks reserved for PRACH

0 0 0 0 none (default)

0 0 0 1 Block B00 0 1 0 Block B0, B60 0 1 1 Block B0, B6, B30 1 0 0 Block B0, B6, B3, B90 1 0 1 Block B0, B6, B3, B9, B10 1 1 0 Block B0, B6, B3, B9, B1, B70 1 1 1 Block B0, B6, B3, B9, B1, B7, B41 0 0 0 Block B0, B6, B3, B9, B1, B7, B4, B101 0 0 1 Block B0, B6, B3, B9, B1, B7, B4, B10, B21 0 1 0 Block B0, B6, B3, B9, B1, B7, B4, B10, B2, B81 0 1 1 Block B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B51 1 0 0 Block B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11

This parameter corresponds to the GSM parameter BS_PRACH_BLKS.

Note: Also for this parameter the system does not refuse entering senseless values which may cause blocking of the PBCCH functionality itself (e.g. reserving 0 PRACH blocks allows no more

packet accesses in the cell!).

BSCDVMA=10,

object: PTPPKF

range: 1-15

default: 10



Maximum BSC countdown va lue , this parameter is used during thecountdown procedure when terminating an UL TBF.The mobile includes the Countdown Value CV in each uplink datablock to indicate the last Block Sequence Number (BSN=0) that issent in the UL TBF. As soon as the MS transmits the first data block indicating a CV value different to 15 (starting with BSCDVMA), themobile will send exactly BSCDVMA more blocks until the UL TBF iscompleted.Example: Using BSCDVMA=10 will result in a CV sequence similar to: 15,15, … 15,10,9,8,7,6,5,4,3,2,1,0

Any UL data arriving from higher layers after the countdown procedure has started on RLC/MAC shall be sent within a future TBF.Thus using a smaller BSCDVMA value may allow (internally) ‘slow’ mobiles to continue the UL data transfer without opening a new TBF.

This parameter corresponds to the GSM parameter BS_CV_MAX. Itsvalue is broadcast to the mobiles within PSI1 and (P)SI13.

BSPBBLK=1,

object: PTPPKF

range: 0..3

default: 1


BS PBCCH blocks , this parameter specifies the number of blocksallocated to the PBCCH in the multiframe. The field is coded according to the following table:

0 0 Block B0 used for PBCCH0 1 Block B0, B6 used for PBCCH1 0 Block B0, B6, B3 used for PBCCH1 1 Block B0, B6, B3, B9 used for PBCCH

This parameter corresponds to the GSM parameter BS_PBCCH_BLKS.





BVCBHIPER=PER70,

object: PTPPKF


PER80, PER90

default: PER70

Reference:

BVC bucket high percentage . If BVC Bucket Level is greater thanBVCBHIPER * BVC Bucket Size PCU, the ‘Bucket Congestion’ stateis activated. As a consequence, the Flow Control Algorithm will reduce the reported leak rate ‘R’ inside the FLOW-CONTROL-BVC PDU, thus limiting the amount of data being sent from the SGSN towards the BSC. If the congestion state persists, the leak rate isfurther decreased.

Caution: It is strictly recommended to maintain the default value!

BVCBLPER=PER60,

object: PTPPKF


PER80, PER90

default: PER60

Reference:

BVC bucket low percentage . If ‘BVC Bucket Level’ is lower thanBVCBHIPER * BVC Bucket Size PCU, the ‘Bucket Congestion’ stateis ceased. As soon as the congestion state is cleared, the leak rate‘R’ inside the FLOW-CONTROL-BVC PDU is set to its original valueand the SGSN may increase the data rate sent towards the BSC.


BVCBMAPER=PER100,

object: PTPPKF


PER040, PER050, PER060


PER100, PER110, PER120,

PER130, PER140, PER150PER160, PER170, PER180

PER190 PER200

default: PER100

Reference: GSM08.18

BVC bucket max percentage defines the value of the BVC Bucket Size (Bmax) reported in the FLOW-CONTROL-BVC PDU towardsthe SGSN:

BVC Bucket Size = BVCBMAPER * (C + 1 sec.) * Rmax

- C corresponds to the parameter TF1 (object PCU)

- Rmax is the maximum rate assigned to that BVC: Number of timeslots that can be assigned to GPRS/EDGE in this cell multiplied by the respective maximum rate per TS..


BVCBSPPER=PER200,

object: PTPPKF




PER190 PER200

default: PER200

Reference:

BVC buck et size PCU percentage .This parameter specifies the‘BVC Bucket Size PCU’ value based on the ‘BVC Bucket Size’ valueBmax reported to the SGSN.

BVC Bucket Size PCU = BVCBSPPER * BVC Bucket Size

It represents the buffer space ‘reserved’ in the PCU for this BVC. TheBVC congestion thresholds (BVCBHIPER, BVCBLPER) are based on this value.Caution: It is strictly recommended to maintain the default value!

C31H=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE


GPRS C31 hy steresis , this attribute indicates if the GPRS reselect hysteresis (GCELLRESH) shall be applied to the C31 criterion (inready state if the new cell is in the same RA).This parameter corresponds to the GSM parameter C31_HYSTERESIS.

C32QUAL=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE


GPRS C32 qualifier . If C32_QUAL is set, positiveGPRS_RESELECT_OFFSET values are only applied to theneighbour cell with the highest RLA value of those cells for whichC32 is compared.

This parameter corresponds to the GSM parameter C32_QUALIFIER.





CACKTYP=0,

object: PTPPKF

range: 0..1

default: 0


Contro l acknowledgement typ e , this parameter indicates the format of the PACKET CONTROL ACKNOWLEDGEMENT message the MSshall transmit when polled. The meaning of the parameter values is:

0 PACKET CONTROL ACKNOWLEDGEMENT format is four access bursts

1 PACKET CONTROL ACKNOWLEDGEMENT format is

RLC/MAC control blockSince BR55/10 onwards this parameter is hardcoded to the value ‘0’ (four access bursts format)!

This parameter corresponds to the GSM parameter CONTROL_ACK_TYPE.

CPCUN=1,

object: PTPPKF

range: 0..11

CPCU num ber , this parameter is mandatory and represents theCommon PCU the PCU refers to.

CRESELTRHSOUT=85,

object: PTPPKF

range: 50..100

default: 85

Reference:

Cel l reselect ion threshold outp ut , this parameter specifies theminimum traffic load threshold above which mobiles in packet transfer mode may be moved out of the cell for load balancing

purpose.

The GPRS traffic control strategy is based on the feature Network Controlled Cell Reselection (NCCR). If NCCR is activated in the cell (NCRESELFLAG = TRUE), the traffic control feature may beadditionally enabled by setting TRFPS = TRUE.

If the GPRS load in the source cell exceeds a certain threshold (CRESELTRHSOUT), the BSC starts to move TBFs to neighbour cells. This is done as long as the load in the source cell remainsabove NCTRFPSCTH and the available target cells are loaded withless packet load than given with the parameter CRESELTRHINP.

Notes:- The traffic control strategy is only applicable between cellsbelonging to the same PCU. An example for calculating the ‘traffic

percentage values’ is available in the GPRS Global Description or inthe ATMN Testcase AC701683.

- CRESELTRHSOUT is a kind of equivalent to the parameter TRFHITH (see command SET HAND [BASICS]) for CS call ‘traffic handover’.

CRESELTHRINP=75,

object: PTPPKF

range: 0.. 85

default: 75

Reference:

Cel l reselect ion threshold in put , this parameter specifies themaximum traffic load threshold allowed in a cell to be considered as

potential target. Please refer to the parameter CRESELTRHSOUT for further details.

Note: CRESELTHRINP is a kind of equivalent to the parameter TRFLTH (see command SET HAND [BASICS]) for CS call ‘traffic handover’.

CSCH3CSCH4SUP=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

CS3 and CS4 supp ort , this parameter allows to enable or disablethe feature GPRS Coding Scheme 3 and Coding Scheme 4 in theBTS associated to the PTPPKF object. This flag may only be set if the same parameter available in the BSC object was set to TRUE

already (see parameter CSCH3CSCH4SUP in command SET BSC [BASICS]). Please refer to the aforementioned parameter in the BSC object for further details.





EGPLGPSEVENTS=16,

object: PTPPKF


default: 16

Reference:

EGPRS pol l ing p er iod seven time slots , this parameter specifiesthe polling period to be used if seven timeslots are assigned.

EGPLGPSIXTS=16,

object: PTPPKF


default: 16

Reference:

EGPRS pol l ing per iod s ix t ime slots , this parameter specifies the polling period to be used if six timeslots are assigned.

EGPLGPTHREETS=16,

object: PTPPKF


default: 8


EGPRS pol l ing p er iod three time slots , this parameter specifiesthe polling period to be used if three timeslots are assigned.

EGPLGPTWOTS=8,

object: PTPPKF


default: 8


EGPRS pol l ing per iod tw o time slots , this parameter specifies the polling period to be used if three timeslots are assigned.

EGWSEIGHTTS=WS192,

object: PTPPKF

range: WS64, WS96, WS128,

WS160, WS192, WS224,

WS256, WS288, WS320,

WS352, WS384, WS416,

WS448, WS480, WS512,

WS544, WS576, WS608,

WS640, WS672, WS704,

WS736, WS768, WS800,

WS832, WS864, WS896,

WS928, WS960, WS992,

WS1024

<NULL>

default: WS1024

Reference:

EGPRS windo w size eight t ime slots , this parameter specifies thewindow size to be used if eight timeslots are assigned.

The value is transferred to the MS within the PDAS, PUAS or PTR messages and is applied for both the UL and DL case.The biggest window size possible for each of the 8 following

parameters (1-8 timeslots) is used as respective default value.

For GPRS transfers a fixed window size of 64 blocks is applied.

EGWSFIVETS=WS128,

object: PTPPKF


WS160, WS192, WS224,

WS256, WS288, WS320,

WS352, WS384, WS416,

WS448, WS480, WS512,

WS544, WS576, WS608,

WS640

<NULL>

default: WS640

Reference:

EGPRS windo w size five time slots , this parameter specifies thewindow size to be used if five timeslots are assigned.

EGWSFOURTS=WS96,

object: PTPPKFrange: WS64, WS96, WS128,

WS160, WS192, WS224,

WS256, WS288, WS320,

WS352, WS384, WS416,

WS448, WS480, WS512,

<NULL>

default: WS512

Reference:

EGPRS wind ow size four t ime slots , this parameter specifies thewindow size to be used if four timeslots are assigned.





EGWSONETS=WS64,

object: PTPPKF


WS160, WS192,

<NULL>

default: WS192

Reference:

EGPRS windo w size one time slot , this parameter specifies thewindow size to be used if one timeslot is assigned.

EGWSSEVENTS=WS160,

object: PTPPKF


WS160, WS192, WS224,

WS256, WS288, WS320,

WS352, WS384, WS416,

WS448, WS480, WS512,

WS544, WS576, WS608,

WS640, WS672, WS704,

WS736, WS768, WS800,

WS832, WS864, WS896,

<NULL>

default: WS896

Reference:

EGPRS wind ow s ize seven time slots , this parameter specifies the

window size to be used if seven timeslots are assigned.

EGWSSIXTS=WS160,

object: PTPPKF


WS160, WS192, WS224,

WS256, WS288, WS320,

WS352, WS384, WS416,

WS448, WS480, WS512,

WS544, WS576, WS608,

WS640, WS672, WS704,

WS736, WS768,

<NULL>

default: WS768

Reference:

EGPRS wind ow size six t ime slots , this parameter specifies thewindow size to be used if six timeslots are assigned.

EGWSTHREETS=WS96,

object: PTPPKF


WS160, WS192, WS224,

WS256, WS288, WS320,WS352, WS384,

<NULL>

default: WS384

Reference:

EGPRS wind ow s ize three time slots , this parameter specifies thewindow size to be used if three timeslots are assigned.

EGWSTWOTS=WS64,

object: PTPPKF


WS160, WS192, WS224,

WS256,

<NULL>

default: WS256

Reference:

EGPRS wind ow size two slots , this parameter specifies the window size to be used if two timeslots are assigned.

ELKADPT=TRUE,

object: PTPPKF range: TRUE, FALSE

default: FALSE

Enable l ink adaptat ion , this parameter enables/disables theGPRS/EGPRS coding scheme Link Adaptation (LA).

This feature adapts the used coding scheme to the current radioconditions. The system continuously evaluates the Block ErasureRate (BLER) values during a packet transfer and switches, if required, to a lower or higher coding scheme. The decision is based on two internal tables. The use of the two different tables is controlled by the parameter RAENV (object PTPPKF, see below), the decisionaveraging speed for coding scheme changes is controlled by the

parameters BLERAVEUL and BLERAVEDL (object PTPPKF, seeabove).





EMANPRESCOM=0,

object: PTPPKF

range: 0..190

default: DISABLED

EGPRS maxim um Num ber of PDCH reserved Comp lementary ,this parameter defines the number of traffic channels reserved for EGPRS in the ‘Complementary Area’ which corresponds to the ‘near area’ (single timeslots) in an extended cell (CELLTYPE=EXTCELL,see command CREATE BTS [BASICS]). In case of non-extended cell, only the parameter EMANPRESPRM (see below) is relevant.

Please see also command SET BTS [SERVICE] for further explanations about the feature ‘Service Dependent Channel

Allocation. EMANPRESPRM=0,

object: PTPPKF

range: 0..190

default: DISABLED

EGPRS maxim um Number of PDCH reserved Primary , this parameter defines the number of traffic channels reserved for EGPRS in the ‘Primary Area’. For standard cells and dualband standard cells (CELLTYPE=STDCELL or DBSTDCELL, seecommand CREATE BTS [BASICS]) there is only one primary area,i.e. in this case EMANPRESPRM defines the overall number of TCHsreserved for EGPRS on the TRXs that are included in the SLLs of EGPRS services.

If the cell is configured as extended cell (CELLTYPE=EXTCELL, seecommand CREATE BTS [BASICS]), the primary area corresponds tothe ‘far area’ (double timeslots) of the extended cell.


Allocation. EMCSFAMA1DL=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE

Enable MCS family A MSC1 downl ink , this parameter enables all coding schemes belonging to Family A plus MCS1 to be used for downlink TBFs.Family A consists of: MCS3, MCS6, MCS9

EMCSFAMAP1DL=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family A padding MSC1 dow nl ink , this parameter all coding schemes belonging to Family A Padding plus MCS1 to beused for downlink TBFs.Family A Padding consists of: MCS3, MCS6, MCS8

EMCSFAMB1DL=FALSE,

object: PTPPKF range: TRUE, FALSE

default: FALSE

Enable MCS family B MSC1 downl ink , this parameter enables all coding schemes belonging to Family B plus MCS1 to be used for

downlink TBFs.Family B consists of: MCS2, MCS5, MCS7

EMCSFAMCDL=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family C dow nl ink , this parameter enables all coding schemes belonging to Family C to be used for downlink TBFs.

Family C consists of: MCS1, MCS4

EMCSFAMGDL=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family GMSK down l ink , this parameter enables all coding schemes with GMSK modulation to be used for downlink TBFs.

Coding schemes using GMSK are: MCS1, MCS2, MCS3, MCS4

EMFA1UNIR8PSK=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE

Enable MCS family A MCS1 upl ink with out inc remental redundancy 8PSK , this parameter enables all coding schemesbelonging to Family A plus MCS1 to be used for uplink TBFs.

Family A consists of: MCS3, MCS6, MCS9

Note: Incremental Redundancy (IR) in uplink direction is not supported in BR70. In downlink direction IR is applied by the BSC and all mobiles have to support it according to specifications.





EMFAP1UNIR8PSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family A p adding MCS1 upl ink withou t incremental

redundancy 8PSK , this parameter enables all coding schemesbelonging to Family A Padding plus MCS1 to be used for uplink TBFs.

Family A consists of: MCS3, MCS6; MCS8

Note: Incremental Redundancy (IR) in uplink direction is not

supported in BR70. In downlink direction IR is applied by the BSC and all mobiles have to support it according to specifications.

EMFB1UNIR8PSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family B MCS1 upl ink with out inc remental

redundancy 8PSK , this parameter enables all coding schemesbelonging to Family B plus MCS1 to be used for uplink TBFs.Family B consists of: MCS2, MCS5; MCS7

Note: Incremental Redundancy (IR) in uplink direction is not supported in BR70. In downlink direction IR is applied by the BSC and all mobiles have to support it according to specifications.

EMFCUNIR8PSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family C upl ink w ithout inc remental redund ancy

8PSK , this parameter enables all coding schemes belonging toFamily C to be used for uplink TBFs in case the MS supports 8PSK.

EMFCUNIRGMSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family C upl ink w ithout inc remental redund ancy GMSK , this parameter enables the GMSK coding schemes belonging to Family C to be used for uplink TBFs in case the MS does not support 8PSK.

EMFGUNIR8PSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family GMSK upl ink w ithout inc remental

redundancy 8PSK , this parameter enables all GMSK coding schemes (MCS1-MCS4) to be used for uplink TBFs in case the MSsupports 8PSK.

EMFGUNIRGMSK=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE

Enable MCS family GMSK upl ink w ithout inc remental

redundancy GMSK , this parameter enables all GMSK coding schemes (MCS1-MCS4) to be used for uplink TBFs in case the MSdoes not support 8PSK.

EUMSSNCRESEL=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable UMTS MSS network contro l led reselect ion , this parameter shall be used to enable the mobile speed sensitive network controlled GSM/GPRS to UMTS cell reselection algorithm.

Further relevant parameters are EUSCNCRESEL (see command SET BSC [BASICS]) and GMICROCU, USECNONCRESEL and USRSCPNCRESEL (see command CREATE ADJC3G).

FDDGQO=10..20,

object: PTPPKF

range: ALWAYS MDB28

MDB24 MDB20

MDB16 MDB12

MDB08 MDB04

DB00 DB04 DB08

DB12 DB16 DB20

DB24 DB28 default: DB0

FDD GPRS Q offs et , this parameter is related to multiRAT MSsconsidering a reselection towards an FDD cell; it indicates an offset which is applied to the RLA_P value of the serving cell.


MDBxx = - xxdBm (e.g. MDB20 = -20dBm)


The value ALWAYS indicates an infinite negative offset, so with thissetting a 3G Mobile will always change to the 3G network if any acceptable 3G cell is available (see parameter GFDDQMI).

This parameter corresponds to the GSM parameter FDD_GPRS_Qoffset.

FPER=per_15,

object: PTPPKF

range: per_05, per_10, per_15,

per_20, per_25, per_30,

per_35, per_40, per_45,

per_50

default: per_15

Flow percentage , this parameter is common to MS and PFC; it represents the shrinking value used in case of PDU life timeexpiration or in case of Bucket Ratio not supported in order to reduceR value sent to SGSN.





GAM=3,

object: PTPPKF

unit: 2dB

range: 0..31

0 = 0dB, 31 = 62dB

default: 3 = 6dB

Gamma , this parameter defines the “gamma” value applied in the power control algorithm. It is an MS and channel specific power control parameter and is sent to the MS within an RLC control message (e.g. PDAS, PUAS, PUAN, PPCTA, PTR, …).

The default value of 6dB means basically that the MS alwaystransmits with the maximum allowed output power (33/30 dBm)unless the normalized receive level at the MS side (C-value) exceeds(is better than) -48dBm.

The Gamma-ch value ( Γ ch ) is not dynamically updated within BR70,therefore the UL power control for GPRS cannot be operated asclosed loop power control.

GASTRTH=10-20,

object: PTPPKF

format: ThresholdIdleChanHV -

ThresholdIdleChanVH -

ThresholdIdleChanEU

range: ThresholdIdleChanHV:

0..100

ThresholdIdleChanVH:

0..100

ThresholdIdleChanEU:

0..100

default: ThresholdIdleChanHV: 10

ThresholdIdleChanVH: 20

ThresholdIdleChanEU: 20

GPRS al location strategy thresh olds , defines the thresholds for the system to switch between horizontal and vertical GPRS channel allocation (and back). It consists of three fields:

ThresholdIdleChanHV defines the point when the allocation strategy is switched from horizontal to vertical: If less than(ThresholdIdleChanHV) percent of CS-only and CS/PS-shared timeslots are idle, vertical allocation is enabled.

ThresholdIdleChanVH defines the point when the allocation strategy is switched back from vertical to horizontal: If more than(ThresholdIdleChanVH) percent of CS-only and CS/PS-shared

timeslots are idle, horizontal allocation is enabled again.ThresholdIdleChanEU defines the threshold above which theupgrading of radio resources is enabled (see parametersUPGRFREQ, GASTRABISTH).Remarks:- ThresholdIdleChanHV has to be lower than ThresholdIdleChanVH .- ThresholdIdleChanVH has to be lower than or equal toThresholdIdleChanEU .- PDCHs are reserved in a flexible way with the parameter GMANPRESPRM and GMANPRESCOM only on thoseTRXs that belong to service layers that are included in the SLLs defined for GPRS services (see command SET BTS [SERVICE] for further explanations). They are not considered at all within the above load calculations.

- ‘ Idle shared ’ timeslots are all available timeslots in the cell that canhandle both GPRS and CS services. This is the case for TCHs of TRXs that belong to service layers which are included in the SLLs for both GPRS and CS services.- Idle CS-only timeslots are all available TCHs of TRXs that belong toservice layers which are included in the SLLs for CS services.- The decisive total number of idle channels changes due to GPRSand CS load. Therefore vertical allocation may be activated by bothCS calls or PDCH allocations only. - The GASTRTH thresholds applied only on the TRXs shared between packet services and other services, i.e. it is applied only onTRXs that belong to service layers which are included in the SLLs for both GPRS and other services.

GCELLRESH=2,

object: PTPPKF

unit: 2dB

range: 0..7

0=0dB, 7=14dB

default: 2


GPRS cel l reselect hys teresis , this attribute indicates the hysteresis

to be subtracted from the C32 value of the neighbour cells if the MSis in ready state and the neighbour cell belongs to the same routing area. If C31H=TRUE, GCELLRESH is additionally substracted fromthe C31 values of the neighbour cells.

The value ranges from 0 dB to 14 dB (2 dB step size).

This parameter corresponds to the GSM parameter GPRS_CELL_RESELECT_HYSTERESIS.





GFDDMURREP=<NULL>,

object: PTPPKF

range: 0..3, <NULL>

default: <NULL>

GPRS FDD mult iRAT repo rt ing , this parameter indicates thenumber of FDD UTRAN cells to be included in the MEASUREMENT REPORTs sent by GPRS attached mobiles.

This parameter corresponds to the GSM parameter FDD_MULTIRAT_REPORTING.

Note: This parameter is not relevant in B R7.0

GFDDQMI =<NULL>,

object: PTPPKF

range: MDB20 MDB19

MDB18 MDB17

MDB16 MDB15

MDB14 MDB13

<NULL>

default: <NULL>

GPRS FDD_Q_Min , this parameter defines the minimum Ec/No(signal to noise ratio) the adjacent cell must provide to be considered as suitable neighbour.

This parameter corresponds to the GSM parameter FDD_Qmin..

GFDDQMIO =DB00,

object: PTPPKF

range: DB00 DB04 DB06

DB08 DB10 DB12

DB14

default: DB00

GPRS FDD_Q_Min_Offs et , this parameter is related to multiRAT mobiles; it is used by them to implement the cell re-selectionalgorithm from GSM to UTRAN.



GFDDREPQTY =<NULL>,

object: PTPPKF

range: RSCP, ECNO, <NULL>

default: <NULL>

GPRS FDD report ing q uanti ty , this parameter indicates thereporting quantity to be used for UMTS FDD cells.

Note: This p arameter is n ot relevant in B R7.0.

This parameter corresponds to the GSM parameter FDD_REP_QUANT.

GFDDRSCPMI=MDB101,

object: PTPPKF

range: MDB115, MDB113,

MDB111, MDB109,

MDB107, MDB105,

MDB103, MDB101,

MDB099, MDB097,

MDB095, MDB093,

MDB091, MDB089,MDB087, MDB085

default: MDB101

FDD RSCP Minimum , this parameter is related multiRAT mobiles - it is used to implement cell re-selection algorithm from GSM to UTRAN.


MDBxxx = - xxxdBm (e.g. MDB115 = -115dBm)

GHCSPC=3,

object: PTPPKF

range: 0..7

default: 3


GPRS hierarchical cel l structu re pr ior i ty class , this attributerepresents the Hierarchical Cell Structure priority for the cell reselection procedure.

This parameter corresponds to the GSM parameter PRIORITY_CLASS.

GHCSTH=10,

object: PTPPKF

unit: 2dB

range: 0..31

0=-110dB, 31=-48dB

default: 10


GPRS hierarchical cel l structu re threshold , this attribute indicatesthe signal strength threshold used in the HCS cell reselection

procedure (C31).

This parameter corresponds to the GSM parameter HCS_THR.

GMANMSAL=7-16,

object: PTPPKF

format: 2 fields:

< maxNoOfMS_UL >-

< maxNoOfMS_DL >-

range: 1-7 (maxNoOfMS_UL)

1-16 (maxNoOfMS_DL)

default: 7 (maxNoOfMS_UL)

16 (maxNoOfMS_DL)


GPRS maxim um n umb er of al located MSs , this parameter indicates the maximum number of MSs that can be multiplexed on aPDCH in the cell. It is composed of two fields: the first indicates themaximum number of MS that can be multiplexed on a PDCH in uplink direction, the second one indicates the maximum number of MS that can be multiplexed on a PDCH in downlink direction.

The total amount of TBFs multiplexed on a PDCH is limited





GMANPRES replaced by GMANPRESPRM in BR8.0

GMANPRESCOM=0,

object: PTPPKF

range: 0..190

default: DISABLED

GPRS maxim um Num ber of PDCH reserved Complem entary , this parameter defines the number of traffic channels reserved for GPRS in the ‘Complementary Area’ which corresponds to the ‘near area’ (single timeslots) in an extended cell (CELLTYPE=EXTCELL,see command CREATE BTS [BASICS]). In case of non-extended cell, only the parameter GMANPRESPRM (see below) is relevant.


Allocation.

GMANPRESPRM=0,

object: PTPPKF

range: 0..190

default: DISABLED

GPRS maximum Numb er of PDCH reserved Primary , this parameter defines the number of traffic channels reserved for GPRSin the ‘Primary Area’. For standard cells and dualband standard cells(CELLTYPE=STDCELL or DBSTDCELL, see command CREATE BTS [BASICS]) there is only one primary area, i.e. in this caseGMANPRESPRM defines the overall number of TCHs reserved for GPRS on the TRXs that are included in the SLLs of GPRS services.

If the cell is configured as extended cell (CELLTYPE=EXTCELL, seecommand CREATE BTS [BASICS]), the primary area corresponds tothe ‘far area’ (double timeslots) of the extended cell.


Allocation.

GMANRETS=2-2-2-2,

object: PTPPKF

format: 4 fields for each priority

level:

prio1-prio2-prio3-prio4

range: 0..3 (for each field)

default: 2-2-2-2


GPRS maximum number of re t ransmiss ions , this parameter indicates for each priority level 1 to 4 the maximum number of retransmission allowed on the PRACH. The parameter value consistsof 4 fields, each field indicates the maximum number of retransmissions allowed for the affected priority level. Priority 1represents the highest priority. For each Radio Priority x parameter the following table is applied:

0 0 1 retransmission allowed0 1 2 retransmissions allowed1 0 4 retransmissions allowed1 1 7 retransmissions allowed

This parameter corresponds to the GSM parameter MAX_RETRANS.

GMSTXPMAC=2,

object: PTPPKF

range: 0..31

default: 2


Maximum al lowed GPRS MS transmiss ion pow er on PBCCH/

PCCCH . GMSTXPMAC defines the maximum power level that may be used by the mobile to access the cell on the PRACH. The valid values and meanings are the same as defined for the parameter MSTXPMAXCH (see SET BTS [CCCH]).

Note: In case Network Controlled Cell Reselection (NCCR) isactivated in the cell (NCRESELFLAG=ENABLED), the PCU usesGRXLAMI as well as GMSTXPMAC to calculate the C1 values also incase no PBCCH is created in the cell.

This parameter corresponds to the GSM parameter GPRS_MS_TXPWR_MAX_CCH.

GNMULBAC=<NULL>,

object: PTPPKF

range: 0..3

default: <NULL>


GPRS Numb er of mult i band c el ls , this parameter is relevant for

GPRS network-controlled cell reselection in dualband configurations.It is the GPRS equivalent to the parameter NMULBAC (seecommand CREATE BTS [BASICS]) and used by GPRS attached mobiles in case a PBCCH is created in the cell. It specifies in whichway the MS shall monitor and report the neighbour cells of thefrequency bands used in the serving and neighbouring cells. Possiblevalues are:0 - Normal reporting of the six strongest cells, with known and allowed NCC part of BSIC, irrespective of the band used.1 - The MS shall report the strongest cell, with known and allowed NCC part of BSIC, in each of the frequency bands in the BA list,excluding the frequency band of the serving cell. The remaining






positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used.2 - The MS shall report the two strongest cells, with known and allowed NCC part of BSIC, in each of the frequency bands in the BAlist, excluding the frequency band of the serving cell. The remaining

positions in the measurement report shall be used for reporting of

cells in the band of the serving cell. If there are still remaining positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used.3 - The MS shall report the three strongest cells, with known and allowed NCC part of BSIC, in each of the frequency bands in the BAlist, excluding the frequency band of the serving cell. The remaining


positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used.

GPATH=PKAAP4,

object: PTPPKF

range: PKANA

PKAAP1 - PKAAP4default: PKAAP4


GPRS prior i ty access thr eshold , this parameter indicates whether or not a mobile station of a certain priority class is authorised to do arandom access in order to request for GPRS services. The field iscoded according to the following table:

PKANA 0 0 0 packet access is not allowed in the cellPKAAP1 0 1 1 packet access is allowed for Priority class 1PKAAP2 1 0 0 packet access is allowed for Priority class 1 to 2PKAAP3 1 0 1 packet access is allowed for Priority class 1 to 3PKAAP4 1 1 0 packet access is allowed for Priority class 1 to 4

During the PDP Context activation an MS is assigned a Radio Priority (only Prio 4 is allocated using a Siemens PO3.1 SGSN). If thenetwork indicates e.g. only Prio 1 accesses are allowed, all mobileshaving Prio 4 assigned do not perform a network access. GMM/SM

procedures are not affected.

This parameter corresponds to the GSM parameter PRIORITY_ACCESS_THR.

GPDPDTCHA=100,

object: PTPPKF

unit: 1% range: 0..100

default: 100


GPRS Percentage of dy namic PDTCH Avai lable , this parameter

indicates the percentage of available “shared” traffic channels that may be used for GPRS traffic. “Shared traffic channels” are thosechannels (TCHFULL, TCHF_HLF, TCHSD in TCHPOOL) for whichthe parameter GDCH is set to <NULL> (see CREATE CHAN for TCH) and for which the superordinate TRX is in service and availablefor GPRS service (this is the case if the TRX is defined as belonging to a service layer which is included in the SLL for GPRS services -

please see command SET BTS [SERVICE] for further explanations).

All TCHs created with these attributes represent 100%.

GPDPDTCHA determines the percentage of these TCHs that theBSC may use for GPRS traffic (the calculated value is rounded down). Whether these TCHs may be preempted respectively downgraded for circuit-switched calls, depends on the setting of the

parameter DGRSTRGY (see SET BT S [BASICS]).

Note: Modification of the GPDPDTCHA setting is only possible, if thePTPPKF object is in administrative state ‘locked’.





GRXLAMI=6,

object: PTPPKF

range: 0..63

default: 6


GPRS minimum receive level at the MS required to access thenetwork on the PRACH. In case a PBCCH is configured in the cell,GPRS mobiles use this parameter instead of the GSM equivalent RXLEVAMI (object BTS).

It is used together with other parameters to calculate the path losscriteria C1 and C32 for cell selection and reselection. Setting GRXLAMI to a high value means that only those GPRS mobiles

attempt to access the cell which are in a location with good coverageconditions. This parameter is sent for the serving as well as theindicated neighbour cells on the PBCCH (PSI3).

A GPRS MS measures the received signal level on the PBCCH carriers of the serving cell and the surrounding cells and calculatesthe mean received level (RLA_P) for each carrier, where:

– RLA_P(s) is the averaged level for the serving cell – RLA_P(n) are the averaged levels for neighboring cells

The cells to be monitored for cell reselection are defined by theBA(GPRS) list, which is broadcast in the PACKET SYSTEM INFORMATION TYPE 3 on the PBCCH and which is defined by the

ADJC cell objects with GSUP=TRUE (see command CREATE ADJC).

At least 5 received signal level measurement samples are required for a valid RLA_P:

RLA_P = 1/5 ∗ (GPRS_RXLEV1 + GPRS_RXLEV2 + .. .+ GPRS_RXLEV5)

The path loss criterion C1, the minimum signal level criterion for GPRS/EGPRS cell selection and cell re-selection, is calculated by the following formula:

C1 = (A - Max(B ,0))

where A = <receive level average> - GPRS_RXLEV_ACCESS_MIN= RLA_P – GRXLAMI

B = GPRS_MS_TXPWR_MAX_CCH - P= GMSTXPMAC - P

P = Maximum RF output power of the MS (see table under parameter MSTXPMAXDCS in command SET BTS [BASICS]).

Max (B,0)= GMSTXPMAC - P if GMSTXPMAC > P

Max (B,0)= 0 if GMSTXPMAC < PSubtracting Max(B,0) ensures that the transmit power capability isconsidered in addition to the minimum receive level defined by GRXLAMI: The lower the maximum transmit power of the MS is , thehigher must be the minimum RXLEV for access.

Notes:- In case Network Controlled Cell Reselection (NCCR) is activated inthe cell (NCRESELFLAG=ENABLED), the PCU uses GRXLAMI aswell as GMSTXPMAC to calculate the C1 values also in case noPBCCH is created in the cell.- If no PBCCH is configured in the cell, the C1 criterion is calculated in the same way as it is done for standard GSM (non-GPRS MS)onthe basis of the parameters RXLEVAMI and MSTXPMAXCH asdescribed in parameter CELLRESH (see command CREATE BTS

[BASICS]).- This parameter corresponds to the GSM parameter GPRS_RXLEV_ACCESS_MIN.





GS=8,

object: PTPPKF

range: 0..9

default: 8


GPRS num ber of slots between two PRACH accesses , this parameter is used for calculation of the number of slots between twosuccessive Channel request messages on PRACH channel. The field is coded according to the following table:

0 0 0 0 S = 12 0 0 0 1 S = 150 0 1 0 S = 20 0 0 1 1 S = 300 1 0 0 S = 41 0 1 0 1 S = 55

0 1 1 0 S = 76 0 1 1 1 S = 1091 0 0 0 S = 163 1 0 0 1 S = 217

S represents the number of slots between two consecutive accesses. All other values reserved.

GTDDMURREP=<NULL>,

object: PTPPKF

range: 0..3

default: <NULL>

Reference:

GPRS TDD mult iband report in g , this parameter indicates thenumber of TDD UTRAN cells to be included in the MEASUREMENT REPORTs sent by GPRS attached mobiles.

This parameter corresponds to the GSM parameter TDD_MULTIRAT_REPORTING.

Note: This parameter is not relevant in B R7.0

GTXINT=3,

object: PTPPKF



GPRS transmis sion interval , this parameter defines the number of slots to spread transmission of the random access on PRACH channel. The field is coded according to the following table:

0 0 0 0 3 slots 1 0 0 0 11 slots0 0 0 1 4 slots 1 0 0 1 12 slots0 0 1 0 5 slots 1 0 1 0 14 slots0 0 1 1 6 slots 1 0 1 1 16 slots0 1 0 0 7 slots 1 1 0 0 20 slots0 1 0 1 8 slots 1 1 0 1 25 slots0 1 1 0 9 slots 1 1 1 0 32 slots0 1 1 1 10 slots 1 1 1 1 50 slots used to spread transmission;

This parameter corresponds to the GSM parameter TX_INT.

GUMTSSRHPRI =<NULL>,

object: PTPPKF


default: <NULL>

GPRS UMTS search pr ior i ty , this parameter indicates if a ‘GPRSattached’ mobile can search 3G cells when BSIC decoding isrequired. If GUMTSSRHPRI=TRUE, the MS may use up to 25 searchframes per 13 seconds without considering the need for BSIC decoding or packet transfer mode interference measurements in

these frames.The MS continuously measures the received RF signal level on:- the BCCH carrier of the serving cell;- the BCCH carriers of neighbour cells as indicated in the BA(GPRS)list.

For each of the monitored cells it calculates the average received level (RLA_P). In addition the MS verifies the BSIC of the BCCH carriers. Only cells with allowed BSIC are considered for re-selection

purposes.

If a GPRS MS works in packet transfer mode it monitors continuously all BCCH carriers as indicated by the BA(GPRS) list and the PBCCH carrier of the serving cell. In every TDMA frame, a received signal level measurement sample is taken on at least one of the BCCH carriers, one after the another. RLA_P is an average value

determined using samples collected over a period of 5s, and ismaintained for each BCCH carrier. The samples allocated to eachcarrier shall as far as possible be uniformly distributed over theevaluation period. At least 5 received signal level measurement samples are required for a valid RLA_P value. The MS shall attempt to check the BSIC for each of the 6 strongest non-serving cell BCCH carriers as often as possible, and at least every 10 seconds.

A multi-RAT MS is allowed to extend this period to 13 seconds, if theneighbor cell list contains cells from other radio access technologies(RATs), e.g. 3g neighbour cells.This parameter corresponds to the GSM parameter





3G_SEARCH_PRIO.

INTRTRFH1WEI=8,

object: PTPPKF

range: 1...32

default: 8

Interact ive Traff ic Handl ing Prior i ty 1 Weight , this parameter theweight for class, traffic handling priority 1 (scheduling priority 1).

INTRTRFH2WEI=4,

object: PTPPKF

range: 1...32

default: 4


INTRTRFH3WEI=2,

object: PTPPKF

range: 1...32

default: 2


IMCSULNIR8PSK =MCS3,

object: PTPPKF

range: MCS1, MCS2, MCS3,

MCS4, MCS5, MCS6,

MCS7, MCS8, MCS9

<NULL>default: MCS3


In i t ial MCS upl ink Wo ut incr emental redundancy 8PSK , this parameter specifies the MCS to be used in an EDGE UL TBF if theMS supports 8PSK and no other information about that MS in that BVC is available (see parameter STGTTLLIINF). If the BSC isinformed about the EDGE capability (e.g. 2-phase access or EDGE

PACKET CHANNEL REQUEST was used) of this mobile, it uses thevalue of IMCSULNIR8PSK in order to calculate the best possibleresource allocation for the requested UL TBF.

IMCSULNIRGMSK =MCS3,

object: PTPPKF

range: MCS1, MCS2,

MCS3, MCS4,

<NULL>

default: MCS3

In i t ial MCS upl ink Wout in cremental redundancy GMSK , this parameter specifies the MCS to be used in an EDGE UL TBF if theMS supports GMSK only and no other information about that MS inthat BVC is available (see parameter STGTTLLIINF). If the BSC isinformed about the EDGE capability (e.g. 2-phase access or EDGE PACKET CHANNEL REQUEST was used) of this mobile, it uses thevalue of IMCSULNIR8PSK in order to calculate the best possibleresource allocation for the requested UL TBF.

INIBLER=PER10,

object: PTPPKF


PER80, PER90

default: PER10


In i t ial B LER , this parameter defines the initial BLER estimation in acell to be used. This value is used in radio resource management tocalculate the initial number of radio resources to be assigned to

packet services in case no ‘historical’ information about BLER isavailable (see parameter STGTTLLIINF).

INICSCH=CS2,

object: PTPPKF

range: CS1, CS2, CS3, CS4

default: CS2


In i t ial coding schem e , this parameter indicates the coding schemeto be allocated when the packet transfer starts. It is also used asinput parameter to calculate the amount of radio resources necessary to fulfil the QOS requirements (Peak Throughput Class).

The values CS3 and CS4 are available only in caseCSCH3CSCH4SUP=TRUE in the cell.

This parameter corresponds to the GSM parameter

INITIAL_CODING_SCHEME.INIMCSDL =MCS6,

object: PTPPKF

range: MCS1, MCS2, MCS3,

MCS4, MCS5, MCS6,

MCS7, MCS8, MCS9

<NULL>

default: MCS6


In i t ial MCS dow nl ink , this parameter specifies the MCS to be used in an EDGE DL TBF if the MS supports 8PSK and no other information about that MS in that BVC is available (see parameter STGTTLLIINF). The value of INIMCSDL is also used as input

parameter to calculate the amount of radio resources necessary tofulfil the QOS requirements (Peak Throughput Class).





MAFAILNCU=4,

object: PTPPKF

range: 1...100

default: 4

Maximum fai lures neighbour cel l UMTS , this parameter themaximum number of packet cell change order messages transmitted for the same UMTS Neighbour cell for a MS/UE, in case the ordered cell change fails.

MSBHIPER=PER70,

object: PTPPKF

range: PER50, PER60, PER70,PER80, PER90

default: PER70

Reference:

MS bucket high percentage . If the MS Bucket Level is greater thanMSBHIPER * MS Bucket Size PCU, the ‘Bucket Congestion’ state isactivated. As consequence the Flow Control Algorithm will reduce the

reported leak rate ‘R’ inside the FLOW-CONTROL-MS PDU, thuslimiting the amount of data being sent from the SGSN towards theBSC. If the congestion state persists, the leak rate is further decreased.


MSBLPER=PER60,

object: PTPPKF


PER40, PER50, PER60,

PER70, PER80,

default: PER60

Reference:

MS bucket low percentage . If the MS Bucket Level is lower thanMSBLPER * MS Bucket Size PCU, the ‘Bucket Congestion’ state isceased.

As soon as the congestion state is cleared, the leak rate ‘R’ inside theFLOW-CONTROL-MS PDU is set to its original value and the SGSN may increase the data rate sent towards the BSC.


MSBMAPER=PER100,

object: PTPPKF




PER100, PER110, PER120,



PER190 PER200

default: PER100

Reference: GSM08.18

MS bucket max percentage . defines the value of the ‘MS Bucket

Size’ (Bmax) reported in the FLOW-CONTROL-MS PDU towards theSGSN:

MS Bucket Size = MSBMAPER * (C + 1 sec.) * Rmax

- C corresponds to the parameter TF1 (object PCU)- Rmax is the maximum rate assigned to that MS: Number of timeslots assigned multiplied by the respective maximum rate per TSmultiplied by the usage percentage (100% if no other MS is sharing that TS).


MSBSPPER=PER200,

object: PTPPKF




PER190 PER200

default: PER200

Reference: GSM08.18

MS buck et size PCU percentage. This parameter specifies the ‘MSBucket Size PCU’ value based on the ‘MS Bucket Size’ value Bmax reported to the SGSN.

MS Bucket Size PCU = MSBSPPER * MS Bucket Size

It represents the buffer space ‘reserved’ in the PCU for this MS. TheMS congestion thresholds (MSBHIPER, MSBLPER) are based onthis value.


MSRMAXU=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Mobi le stat ion rate max used , if this parameter is TRUE, Rmax isused for Bmax and R computation, otherwise RGUA is used.

NAVGI=10,

object: PTPPKF



N averaging interference , this attribute represents an interfering signal strength filter constant for power control 2(k/2), k = 0, 1, … ,15.

This parameter corresponds to the GSM parameter N_AVG_I.

NCC1TH=DB03,

object: PTPPKF

range: DB00, DB01..DB62,DB63

default: DB03

Reference:

Network co ntrol led cel l reselect ion C1 threshold . This parameter establishes the threshold concerning the C1 value for network controlled cell reselection (NCCR) in steps of 1dB (DB01 = 1dB,DB02 = 2dB etc.): If the C1 value measured on the serving cell fallsbelow NCC1TH, a network controlled cell reselection is attempted.





NCRARESH=DB00,

object: PTPPKF

range: DB00, DB01..DB29,DB30

default: DB00

Reference:

Network c ontrol led cel l reselect ion routin g area reselect

hysteresis , this parameter specifies the additional hysteresis (insteps of 1dB, DB01 = 1dB, DB02 = 2dB etc.) to be subtracted fromC32 of an adjacent cell belonging to a different routing area than theserving cell.It has to be set to 0 in case the parameter NCSARA =TRUE.

Note: NCRARESH is used in case of NCCR only. The equivalent

parameter in case NCCR is disabled is RARESH.

NCSARA=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE

Reference:

Network co ntrol led cel l reselect ion s ame routing area , this parameter determines whether cells of the same routing area are tobe preferred during the network controlled cell reselection procedure.When NCSARA is set to TRUE, the BSC classifies the availableadjacent cells in two subgroups:

a) adjacent cells that belong to the same routing area as the serving cell and b) adjacent cells that do not belong to the same routing area as theserving cell.

If network controlled cell reselection is to be performed and NCSARAis set to TRUE, the BSC first of all searches an adjacent cell that belongs to the same routing area like the serving cell. If the BSC

finds a suitable adjacent cell in this subgroup, this cell will beselected for cell reselection.If NCSARA is set to FALSE, the adjacent cells of the same routing area have no priority compared to the adjacent cells of other routing areas and the BSC will select the best suitable cell for cell reselection, irrespective of its association to a routing area.

Note: When this attribute is set to TRUE , the parameter NCRARESH (see above) has to be set to DB00 (default value).

NCTRFPSCTH=75,

object: PTPPKF

range: 30..100

default: 75

Reference:

Network co ntrol led cel l reselect ion traff ic packet switched

contro l thresho ld , this parameter specifies the traffic load threshold in percent below which no more mobiles are moved out of a cell dueto traffic reasons. Please refer to the parameter CRESELTRHSOUT for further details.

NTWCNDRXP=MSEC0480,

object: PTPPKF

range: NODRX, MSEC240,

MSEC480, MSEC720,

MSEC960, MSEC1200,

MSEC1440, MSEC1920

default: MSEC0480

Reference:

Network co ntrol led cel l reselect ion report p er iod transfer , this parameter indicates the minimum time (in milliseconds, MSC0480 =480ms) the mobile station shall remain in non-DRX mode after aPACKET MEASUREMENT REPORT message had been sent.

NTWCOR=NC0,

object: PTPPKF

range: NC0, NC1

default: NC0


Network contro l order , this parameter reported in (P)SI 13, PSI 1and PSI 5, informs the mobile about the control of cell reselection.Values can be:

NC0: value 0 MS controlled cell reselection,no measurement reporting

NC1: value 1 MS controlled cell reselection,

MS sends measurement reportsNC2: value 12 NTW controlled cell reselection,MS sends measurement reports

In normal operation the network always broadcasts the value NC0.Only in case the feature Network Controlled Cell Reselection (NCCR)is activated (NCRESELFLAG=TRUE), the BSC sends a PACKET MEASUREMENT ORDER at the beginning of each TBF indicating NC2 for the respective mobile. Before the TBF is terminated, theNetwork Control Order is reset to NC0. NC1 is not used at all inwithin BR70.This parameter corresponds to the GSM parameter NETWORK_CONTROL_ORDER.





NTWCREPPIDL=MSEC61440,

object: PTPPKF

range: MSEC480 , MSEC960,

MSEC1920, ,MSEC3840,

MSEC7680,MSEC15360,

MSEC30720, MSEC61440

default: MSEC61440Reference:

Network con trol led cel l reselect ion report per iod idle , this parameter indicates the time period between two consecutivePACKET MEASUREMENT REPORT (PMO) messages while the MSis in packet idle mode.

Note: This parameter is not used in BR70 as the BSC does not set NC1/NC2 for mobiles in packet idle mode.This parameter corresponds to the GSM parameter

NC_REPORTING_PERIOD_I.

NTWCREPPTR=MSEC3840,

object: PTPPKF

range: MSEC480, MSEC960,

MSEC1920, ,MSEC3840,

MSEC7680,MSEC15360,

MSEC30720, MSEC61440

default: MSEC3840

Reference:

Network co ntrol led cel l reselect ion report p er iod transfer , this parameter indicates the time period between two consecutivePACKET MEASUREMENT REPORT (PMO) messages while the MSis in packet transfer mode.

This parameter corresponds to the GSM parameter NC_REPORTING_PERIOD_T.

PCMECH=MEABCCH,

object: PTPPKF

range: MEABCCH, MEAPDTCHdefault: MEABCCH


Power control measurement channel , this attribute indicates wherethe mobile station shall measure the received power level on thedownlink for the purpose of the uplink power control.

Setting PCMECH to MEABCCH means: downlink measurements for power control shall be performed on the BCCH.

Setting PCMECH to MEAPDTCH means: downlink measurements for power control shall be performed on the PDCH.

This parameter corresponds to the GSM parameter PC_MEAS_CHAN.

PERSTLVPRI1=5,

object: PTPPKF

range: 0..14, 16

default: 5


Persistence level pr ior i ty 1 , this parameter is broadcast in thePacket System Information Type 1 on the PBCCH. It specifies theaccess persistence on PRACH for TBFs with radio priority 1.For each access attempt the MS shall draw a random value R withuniform distribution in the range (0, …, 15). The MS is allowed totransmit an (EGPRS) PACKET CHANNEL REQUEST message only in case the value of PERSTLVPRI1 is less or equal to R.

Therefore a high value of PERSTLVPRI1 decreases the probability of a network access for a TBF with radio priority 1.

PERSTLVPRI2=5,

object: PTPPKF

range: 0.. 14, 16

default: 5


Persistence level pr ior i ty 2 , this parameter is broadcast in thePacket System Information Type 1 on the PBCCH. It specifies theaccess persistence on PRACH for TBFs with radio priority 2.For further details please refer to PERSTLVPRI1 above.

PERSTLVPRI3=5,

object: PTPPKF

range: 0.. 14, 16

default: 5



PERSTLVPRI4=5,

object: PTPPKF

range: 0.. 14, 16

default: 5







PFCBBHIPER=per_70,

object: PTPPKF


per_80, per_90

default: per_70

PFC backgro und buc ket high percentage , if PFC Bucket Level is greater than

PFCBackgroundBucketHighPercentage * BackgroundBucketMaxPCU

the Bucket Congestion is started.

PFCBBLPER=per_60,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80

default: per_60

PFC backgrou nd buck et low percentage , if

PFC Bucket Level is lower thanPFCBackgroundBucketHighPercentage * BackgroundBucketMaxPCU

the Bucket Congestion is stopped.

PFCBBMAPER=per_100,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80, per_90,

per_100, per_110, per_120,

per_130, per_140, per_150,

per_160, per_170, per_180,

per_190, per_200

default: per_100

PFC background bucket maximum percentage , this parameter reduces the value of Bmax automatically computed by the BSC.

BSC criteria is

BmaxPFC=PFCBBMAPER *Fn*(1sec+TF1)*Rgua, pfc)

and Rgua,pfc guaranteed flow rate out of the buffer in the PCU.

PFCBBMAPPER=per_200,

object: PTPPKF


per_130, per_140, per_150,

per_160, per_170, per_180,

per_190, per_200

default: per_200

PFC background bucket maximum percentage , this parameter assignes the value of Background Bucket Max PCU as percentage of Bmax.

PFCBRMAXU=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

PFC backgro und rate max used , if this parameter is TRUE, Rmax is used for Bmax and R computation, otherwise R GUA is used.

PFCBRPER=per_100,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80, per_90,

per_100, per_110, per_120,

per_130, per_140, per_150,

per_160, per_170, per_180,

per_190, per_200

default: per_100

PFC background rate percentage

PFCIBHIPER=per_70,

object: PTPPKF


per_80, per_90

default: per_70

PFC interact ive buck et high percentage , if PFC Bucket Level is greater than

PFCInteractiveBucketHighPercentage * InteractiveBucketMaxPCU


PFCIBLPER=per_60,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80

default: per_60

PFC interact ive buck et low percentage , if PFC Bucket Level is lower than

PFCInteractiveBucketLowPercentage * InteractiveBucketMaxPCU

the Bucket Congestion is finished.





PFCIBMAPER=per_100,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80, per_90,

per_100, per_110, per_120,

per_130, per_140, per_150,

per_160, per_170, per_180, per_190, per_200

default: per_100

PFC interact ive buck et high percentage , this parameter reducesthe value of Bmax automatically computed by the BSC.BSC criteria is

BmaxPFC=PFCIBMAPER *Fn*(1sec+TF1)*Rgua, pfc)


PFCIBMAPPER=per_200,

object: PTPPKF


per_130, per_140, per_150,

per_160, per_170, per_180,

per_190, per_200

default: per_200

PFC interact ive buc ket max PCU percentage , this parameter assignes the value of Intercative Bucket Max PCU as percentage of Bmax.

PFCIRMAXU=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

PFC interact ive rate max used , if this parameter is TRUE, Rmax isused for Bmax and R computation, otherwise R GUA is used.

PFCIRPER=per_100,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80, per_90,

per_100, per_110, per_120,

per_130, per_140, per_150,

per_160, per_170, per_180,

per_190, per_200

default: per_100

PFC interact ive rate percentage , this parameter defines ???

PFCSBHIPER=per_70,

object: PTPPKF

range: per_50, per_60, per_70, per_80, per_90

default: per_70

PFC streaming bu cket high percentage , if PFC Bucket Level is greater than

PFCStreamingBucketHighPercentage * StreamingBucketMaxPCU


PFCSBLPER=per_60,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80

default: per_60

PFC streaming bu cket low percentage , if PFC Bucket Level is lower than

PFCStreamingBucketHighPercentage * StreamingBucketMaxPCU

the Bucket Congestion is stopped.

PFCSBMAPER=per_100,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80, per_90,

per_100, per_110, per_120, per_130, per_140, per_150,

per_160, per_170, per_180,

per_190, per_200

default: per_100

PFC streaming b ucket max percentage , this parameter reducesthe value of Bmax automatically computed by the BSC.

BSC criteria is

maxPFC=PFCSBMAPER *Fn*(1sec+TF1)*Rgua, pfc)






PFCSBMAPPER=per_200,

object: PTPPKF


per_130, per_140, per_150,

per_160, per_170, per_180,

per_190, per_200

default: per_200

PFC streaming buck et max PCU percentage , this parameter assignes the value of Streaming Bucket Max PCU as percentage of Bmax.

PFCSRMAXU=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

PFC streaming rate max us ed , if this parameter is TRUE, Rmax isused for Bmax and R computation, otherwise R GUA is used.

PFCSRPER=per_100,

object: PTPPKF


per_40, per_50, per_60,

per_70, per_80, per_90,

per_100, per_110, per_120,

per_130, per_140, per_150,

per_160, per_170, per_180,

per_190, per_200

default: per_100

PFC streaming rate percentage

PKTMEASREPCNT=1,

object: PTPPKF

range: 0..10

default: 1

Reference:

Packet measurement report counter , this parameter indicates thenumber of consecutive serving cell’s BCCH carrier measurementsunder threshold NCC1TH required to order a cell change.

PKTNDEC=2,

object: PTPPKF

range: 0..7

default: 2


Packet number decrement , this parameter defines the stepsize todecrease counter N3102 in case T3182 expires without having received a PACKET UPLINK ACK/NACK message from the network.Refer also to parameters PKTNINC and PKTNMA.

This parameter corresponds to the GSM parameter PAN_DEC.

PKTNINC=2,

object: PTPPKF

range: 0..7

default: 2


Packet number increment , this parameter defines the stepsize to

increase counter N3102 in case a PACKET UPLINK ACK/NACK message was correctly received by the MS. N3102 cannot exceed the value set by PKTNMA. Refer also to parameters PKTNDEC and PKTNMA.

This parameter corresponds to the GSM parameter PAN_INC.

PKTNMA=4,

object: PTPPKF

range: 0..7

default: 4


Maximum packet number , this parameter defines the maximumvalue for the counter N3102 used on MS side. N3102 is set toPKTNMA at each cell reselection of the MS. In case N3102 reachesthe value 0 or below (see PKNDEC and PKNINC), the mobile stationshall perform an abnormal release with cell reselection.

This parameter corresponds to the GSM parameter PAN_MAX.

PRPBCCH=0,

object: PTPPKF

range: 0..15

default: 0


GSM 04.60

Power reduction on PBCCH , this attribute indicates the power reduction value used by the BTS on PBCCH blocks, relative to the

output power used on the BCCH. It is broadcast within the PACKET SYSTEM INFO TYPE 1 on the PBCCH and the stepsize is 2 dBm.

This parameter corresponds to the GSM parameter Pb.





QSRHPRI=NEVER,

object: PTPPKF


UMDB90 UMDB86

UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66OMDB62 OMDB58

OMDB54 NEVER

default: NEVER

Q Search p r ior i ty , this parameter is broadcast on the PBCCH and defines a threshold condition under which the Mobile shall monitor and report 3G neighbour cells.

The parameter values have to be considered as follows:- The values OMDBxx (=o ver m inus xxdB ) define the threshold asfollows: When the level of the neighbour cell has exceeded the “xx dB” threshold value, the neighbour cell shall be considered for reporting.- The values UMDBxx (=u nder m inus xxdB ) define the threshold asfollows: When the level of the neighbour cell has dropp ed below the“xx dB” threshold value, the neighbour cell shall be considered for reporting.- The value ALWAYS means the Mobile shall always consider 3Gneighbours for reporting.- The value NEVER means the Mobile shall not consider 3Gneighbours for reporting at all.

RAARET=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE


Random access retry , this parameter determines whether randomaccess retry is allowed or not. If RAARET=FALSE random accessretry to another cell is not allowed. If RAARET=TRUE random accessretry to other cell is allowed. Its value is broadcast on the PBCCH

within the PSI3 message.This parameter corresponds to the GSM parameter RANDOM_ACCESS_RETRY.

RACODE=10,

object: PTPPKF

range: 0..255

Routing area code , this attribute represents the identification of theRA to which this cell belongs.

A routing area may comprise at minimum a single cell and asmaximum a complete LAC area.

RACOL=7,

object: PTPPKF

range: 0..7

Routing area colour , this attribute is used by the mobile to identify the specific routing area. Due to the fact that the RACODE can besmaller than LA and its numbering is not unique in the network but it’sunique in the LA, this parameter is used to choose the right RA whenthe mobile is listening to different LA containing routing area with thesame code. The RA colour for the neighbour LA must be set different by network planning.

RAENV=HIGHDIV,

object: PTPPKF

range: HIGHDIV, LOWDIV

default: HIGHDIV

Radio environm ent , this parameter specifies the radio environment in the cell. It is an indicator of user mobility. Two values are possible:

- LOWDIV (lowDiversity): this value means that for an MS radioconditions can change slowly, because the cell is characterized by low user mobility (pico cells, indoor cells, or MSs have a speed lower than 50 km/h).- HIGHDIV (highDiversity): this value means that for a MS radioconditions can change fast, because MSs have a speed higher than50 km/h.This parameter determines which decision threshold table is applied for the Link Adaptation (LA) feature if EDGE is used. In case of HIGHDIV, coding scheme downgrades are started already at lower BLER values compared to the LOWDIV case (means earlier). Coding

scheme upgrades are also performed at lower BLER valuescompared to the LOWDIV case. This applies some safety margin incase of HIGHDIV environment with its fast changing radio conditions.

RARESH=2,

object: PTPPKF

unit: 2dB

range: 0..7

0=0dB, 7=14dB

default: 2


Routing area reselect hysteresis , this parameter specifies theadditional hysteresis (in steps of 2dB) to be subtracted from C32 of an adjacent cell belonging to a different routing area than the serving cell. The value is applied in both GMM standby and ready state of themobile.

This parameter corresponds to the GSM parameter RA_RESELECT_HYSTERESIS.





SCHWEIPRI1=8,

object: PTPPKF

range: 0..16

default: 8

Reference:

Schedul ing weight of pr ior i ty 1 , this parameter indicates thescheduling weight associated to scheduling priorities 1.If more than one MS is allocated on a PDCH (vertical allocation), therelative importance of each MS (TBF) compared to another one canbe influenced. For this purpose the system internally maps two of theavailable QOS parameters on the internal scheduling priority:

DL Precedence UL Radio Priority Internal Priority Weight (default)

1 1 1 8

2 2 2 4

3 3 3 2

4 4 1

The UL radio priority is present in the PACKET RESOURCE REQUEST (PRR) message in case of a two-phase access. In caseof one-phase access, the default is 4.The DL precedence is assigned during the PDP context activation as

part of the QOS negotiations and included in each DL-UNITDATAPDU.

Example: 2 MS sharing 4 timeslots; MS1 with Prio 1, MS2 with Prio 4If the mobiles use each 4 timeslots and the same coding scheme, thethroughput of a DL Transfer will be split according to:MS1: 8/9 * Throughput MAX

MS2: 1/9 * Throughput MAX SCHWEIPRI2=4,

object: PTPPKF

range: 0..16

default: 4

Reference:

Schedul ing weight of pr ior i ty 2 , this parameter indicates thescheduling weight associated to scheduling priorities 2.Please refer to SCHWEIPRI1 for further details.

SCHWEIPRI3=2,

object: PTPPKF

range: 0..16

default: 2

Reference:

Schedul ing weight of pr ior i ty 3 , this parameter indicates thescheduling weight associated to scheduling priorities 3.Please refer to SCHWEIPRI1 for further details.

SCHWEIPRI4=1,

object: PTPPKFrange: 0..16

default: 1

Reference:

Schedul ing weight of pr ior i ty 4 , this parameter indicates thescheduling weight associated to scheduling priorities 4.

Please refer to SCHWEIPRI1 for further details.

SMSINFO=1-160,

object: PTPPKF

format: pfiWeight - smsSDUSize

range: pfiWeight: 1...32

smsSDUSize: 160..1560 (bytes)

default: pfiWeight: 1

smsSDUSize: 160 bytes

PFI SMS info , this parameter represents the weight for the predefined PFI SMS. It consists of the two fields: pfiWeight and smsSDUsize.

SPFIWEI=16,

object: PTPPKF

range: 1...32

default: 16

Signal ing PFI weight , this parameter represents the weight for predefined PFI signaling.

STREAMWEI=32,

object: PTPPKF

range: 1...32

default: 32

Streaming w eight , this parameter represents the weight for streaming.





STGTTLLIINF=10,

object: PTPPKF

unit: 1s

range: 10..90

default: 10

Reference:

Storage time of TLLI info , this parameter indicates the time (inseconds) for which the BSC stores the information about the last used coding scheme and BLER of a certain TLLI (=mobile) after it terminated its last TBF (UL or DL).If a new TBF is setup towards this TLLI within STGTTLLIINF time, thesystem uses the previously applied BLER and coding scheme infoduring the resource allocation process. If STGTTLLIINF has expired,

the respective default values are considered (INIBLER, INIMCSDL,etc.).

T3168=2,

object: PTPPKF

range: 0..7

default: 2



T3168 , is a timer used on the mobile side. It defines when the MSstops waiting for a PACKET UPLINK ASSIGNMENT message after it had asked for new uplink resources (via PRR, (E)PDAN or PCA). Itsvalue plus one must be multiplied by 500 msec. to obtain the real value broadcast in (P)SI 1/13.

T3192=0,

object: PTPPKF

range: 0..7

default: 0


T3192 , this timer is used on the MS side when the mobile station hasreceived all of the RLC/MAC data blocks of a TBF. When T3192 expires, the mobile shall release the resources associated with theTBF (TFI, etc.) and begin to monitor its paging channel.

The timer is broadcast withing (P)SI 1/13 and coded as follows: 0 500 ms1 1000 ms2 1500 ms3 0 ms4 80 ms5 120 ms6 160 ms7 200 ms

Please also refer to T3193 (object PCU).

TAVGT=5,

object: PTPPKF

range: 0..25

default: 5


T average time , this attribute indicates the signal strength filter period for power control in packet transfer mode.

This parameter corresponds to the GSM parameter T_AVG_T.

TAVGW=15,

object: PTPPKF

range: 0..25

default: 15


T average weight , this attribute indicates the signal strength filter period for power control in packet idle mode.

This parameter corresponds to the GSM parameter T_AVG_W.

TBNCU=5,

object: PTPPKF

range: 1...100

default: 5

Timer back neighbo ur cel l UMTS , this parameter defines the timer which is started relatively to a MS/UE, when this mobile hasreselected a GSM/GPRS cell. Until its expiry, NC GSM/GPRS toUMTS cell reselection shall be inhibited for this MS/UE.





TDDGQO =DB00,

object: PTPPKF

range: ALWAYS, MDB28,

MDB24, MDB20, MDB16,

MDB12, MDB08, MDB04,

DB00, DB04, DB08,

DB12, DB16, DB20,

DB24, DB28,default: DB00

Reference:

TDD GPRS Q offs et . this parameter is related to multiRAT MSsconsidering a reselection towards a TDD cell; it indicates an offset which is applied to the RLA_P value of the serving cell.


MDBxx = - xxdBm (e.g. MDB20 = -20dBm)


The value ALWAYS indicates an infinite negative offset, so with thissetting a 3G Mobile will always change to the 3G network if any acceptable 3G cell is available).

This parameter corresponds to the GSM parameter TDD_GPRS_Qoffset.

TFAILNCU=5,

object: PTPPKF

range: 1...100

default: 5

Timer fai lures neighbour c el l UMTS , this parameter defines thetimer started from BSC when it has received a PACKET CELLCHANGE FAILURE message containing an UMTS cell descriptionfrom a MS/UE. Until expiry of this timer, this UMTS neighbour cell isexcluded from the UMTS Target Cell List

TRESEL=0,

object: PTPPKF

range: 0..7

default: 0


Timer for c el l reselect ion . This parameter is broadcast within thePSI3 message on the PBCCH. If the MS has performed an abnormal release with cell reselection towards a new cell (see parameter RAARET), the MS shall not reselect back to the original cell for T_RESEL seconds if another suitable cell is available. The field iscoded according to the following table:

000 5 seconds 100 30 seconds001 10 seconds 101 60 seconds010 15 seconds 110 120 seconds011 20 seconds 111 300 seconds

This parameter corresponds to the GSM parameter T_RESEL.

TRFPSCTRLT =5,

object: PTPPKF

unit: 1s

range: 1..100

default: 5Reference:

This parameter was originally supposed to define the minimum timebetween two consecutive NCCR procedures of an MS towards thesame adjacent cell (Traffic packet switched control timer).

However, the parameter was finally not implemented as intended but

was ‘abused’ for a different purpose in the scope of CR1850 (implemented in BR7.0) which deals with a particular mobile phone problem. The parameter can thus be described as Time between

two co nsecutive NCCR procedures on the same MS towards the

same adjacent cel l :

During Network Controlled Cell Reselection with particular mobiletypes (Ericsson, NOKIA) ‘ping-pong’ behaviour was experienced.These mobiles receive a PACKET CELL CHANGE ORDER towardsan adjacent target cell. After having accessed this target cell, mobile

performs location area update but it does not perform routing areaupdate. After that it goes back autonomously to the ‘old’ cell without transmitting PACKET CELL CHANGE FAILURE.

To handle this wrong mobile behaviour, the existing (but not used) parameter TRFPSCTRL is emplyed: as long as TRFPSCTRL runs,

the BSC des not to order the mobile to move again into this adjacent target cell, in spite of good radio link scenario.

This action trust in the fact that mobile’s TLLI used in the old serving cell and mobile’s TLLI used in the adjacent target cell may differ only for one bit (bit 30th,which distinguish between local / foreign TLLI),otherwise BSC may not track mobile in its cell change.

This procedure requires also that BSC stores information related tothe mobile after the end of each TBF at least for the timeSTGTTLLIINF (storage TLLI Info). Thefore the rule

STGTTLLIINF >=TRFPSCTRL

must be applied (settings violating this ruke are prevented by a





database command check).

Remarks:

- The Maximum number of stored cells (to which a NCCR happened)is fixed to 4.- Timer TRFPSCTRL is referred to the serving PTPPKF and isapplied to all the adjacent cell relations belonging to that PTPPKF;that is, it is not possible to have different timers for e.g PTP1->PTP2 and PTP1->PTP3 adjacencies.

- The CR covers also an anomalous behavior by a NOKIA MS: after a failed cell reselection on a target cell, the MS reselects the serving cell by accessing with a single block procedure, but instead of sending a PACKET CELL CHANGE FAILURE, it sends a PACKET RESOURCE REQUEST to open a new TBF. The PACKET CELLCHANGE FAILURE is sent only after the PACKET UPLINK

ASSIGNMENT sent by the BSC to open the new TBF.

Restrictions:- If a cell is used by the BSC for the reselection of a given MS at timeT=x, then this cell can be reused by the BSC for the reselection of thesame MS only after time

T’= x + TRFPSCTRL

that is, only after timer TRFPSCTRL is expired.- If a MS, after a failed network controlled cell reselection, does not send any packet PACKET CELL CHANGE FAILURE on the old serving cell, but it comes back by T< 15 sec starting from PACKET CELL CHANGE ORDER message, then the BSC will not choose asecond target cell until it will not receive a packet measurement report message.

- If a MS sends packet cell change failure message after contentionresolution the BSC will not chose a second target cell until it will not receive a packet measurement report message.

Creating the LPDLR links:

CREATE LPDLR This command w as deleted in BR6.0!

From BR6.0 on the LPDLR is autom atical ly created by the

command CREATE TRX, the phys ical assignment o f the created

LPDLR is determined by the parameter LPDLMN (in com mand

CREATE TRX).





Creating the cell-specific Frequency Hopping systems for static MAIOAllocation (SMA):

< Starting from BR8.0 the definition of frequency hopping systemscan be done in two different ways:a) the frequency hopping system is defined per BTS (per cell) in theFHSY object which is subordinate to the affected BTS (as done in

releases before BR8.0).b) the frequency hopping system is defined per BTSM (per site) inthe CFHSY object (see command CREATE CFHSY) which issubordinate to the CBTS object.

Variant a) can be used for Static MAIO Allocation (SMA) only , whichmeans that the BTS-specifically defined hopping system (FHSY) isallocated to the CHAN object toghether with a fixed MAIO value (seecommand CREATE CHAN for TCH and SDCCH) which determinesthe position of that particular channel in the applied hopping sequence. Starting from BR8.0, the allocation of a FHSY and MAIOcan alternatively be done in the TRX object (see command CREATE TRX).

Variant b) can be used for

- Static MAIO Allocation (see above), which means that the BTSM-

specifically defined hopping system (CFHSY) is allocated to the TRX object toghether with a fixed MAIO value (see command CREATE TRX) which determines the position of the channels subordinate tothe TRX in the applied hopping sequence when Dynamic MAIO

Allocation (DMA) is not used by the service layer assigned to that TRX.- Dynamic MAIO Allocation (see above), which means that theBTSM-specifically defined hopping system (CFHSY) is allocated tothe TRX object toghether with a fixed MAIO value (see command CREATE TRX) which determines the position of the channelssubordinate to the TRX in the hopping sequence when DMA is not enabled (see parameter ENDMA in commands CREATE CBTS and CREATE BTS [BASICS]). When DMA is enabled, the defined MAIOis no longer relevant as for the channels, MAIOs are dynamically

assigned by a special algorithm.The below listed command CREATE FHSY is thus only relevant for variant (a), i.e. DMA is not used at all.

In any case, starting with BR8.0, the DBAEM places the command CREATE FHSY before the CREATE TRX commands (in releases upto BR7.0 it was placed before the CREATE CHAN commands). >

CREATE FHSY:

NAME=BTSM:0/BTS:0/FHSY:0,

Object path name .

HSN=10,

object: FHSY

range: 0..63


Hopping sequence number , determines the hopping sequence’srespective algorithm. The value ‘0’ means cyclic hopping. This

parameter is sent in the main DCCH in the IE ‘Channel Description’ contained in the ASSIGNMENT COMMAND and in the HANDOVER

COMMAND if it was assigned to the used channel. If frequency hopping is enabled the parameter H is set to 1. In this case the IE also contains the HSN together with the MAIO.

MOBALLOC=CALLF01&CALLF02&...,

object: FHSY

range: 0..1023 (each field)


GSM 04.08

Mobi le al location l ist , this parameter defines is a list of those cell allocation frequencies used in the hopping sequence. This parameter is sent in the main DCCH in the IE ‘Mobile Allocation’, which iscontained in the ASSIGNMENT COMMAND and in the HANDOVER COMMAND. This IE ‘Mobile Allocation’ is a bit map in which e.g. for every frequency contained in the 'cell allocation frequency list' anown bit position is provided. The 'cell allocation frequency list' isderived from the set of frequencies defined by the reference 'Cell





Channel Description' IE (see also parameter CALL in CREATE BTS[BASICS]). If the bit position representing a frequency is ‘1’ then theassociated frequency is contained in the mobile allocation. In the cell allocation frequency list the absolute RF channel numbers are placed in increasing order of ARFCN, except that ARFCN 0, if included inthe set, is put in the last position in the list.Notes:- From BR6.0 on the radio frequencies assigned to the FHSY are no

longer represented by their absolute radio frequency number (ARFCN) but by their relative number CALLFxx which was assigned to the frequencies during creation of the BTS cell allocation (pleaserefer to the parameters CALLF01..CALLF63 and BCCHFREQ in thecommand CREATE BTS [BASICS]). If the TRX represents the BCCH carrier, the value of TRXFREQ must be BCCHFREQ.- If the FHSYID is created for a concentric cell (see CREATE BTS[BASICS]:CONCELL=TRUE) then hopping is only allowed within thecomplete and within the inner area. This means that two FHSYIDshave to be defined: one for the complete area (MOBALLOC may only consist of TRX frequencies of the complete area) and one for theinner area (MOBALLOC may only consist of TRX frequencies of thecomplete area.)





Creating the TRXs:

CREATE TRX:

NAME=BTSM:0/BTS:0/TRX:0,

Object path name .

GSUP cancel led in B R8.0

FHSYID=<NULL>,

object: TRX

range: CFHSY_0..CFHSY_1,

FHSY_0..FHSY_10,

<NULL>

default: <NULL>


GSM 04.08

GSM 12.20

Frequency hopping sy stem identi f ier , by the assignment of analready existing frequency hopping system (as defined by a FHSY or CFHSY object) this parameter determines the frequency hopping law that is applied to all CHAN objects that are subrodinate to the TRX.

Starting from BR8.0 the parameters FHSYID and MAIO (that inreleases up to BR7.0 had been available in the CHAN object only,see command CREATE CHAN) are also available in the TRX object.When these parameters in the TRX object are used this means that for all CHAN objects subordinate to the TRX the same hopping law (with Mobile Allocation (MA) and Hopping Sequence Number (HSN)as defined in the assigned FHSY) is used - which is the usual case,especially in case of synthesizer frequency hopping. If the hopping

parameters FHSYID and MAIO of the TRX object are filled, the

equivalent parameters in the CHAN object must be set to the<NULL> value in this case.

If the hopping system is to be defined by the CFHSY object (this ismandatory in case of Dynamic MAIO Allocation (DMA), the

parameters MAIO and FHSYID must be defined in the TRX object.

For further details about frequency hopping and the creation of hopping systems for Static MAIO Allocation (SMA) and Dynamic MAIO Allocation, please refer to the following commands and

parameter descriptions- command CREATE FHSY - parameters FHSYID and MAIO in command CREATE CHAN - parameters HOPP and HOPMODE in command SET BTS[OPTIONS].- commands CREATE CBTS and CREATE CFHSY

LAYERID=LY_00,

object: TRX

range: LY_00..LY11

default: LY_00

Service Layer ID , this parameter is used for the feature ‘ServiceDependent Channel Allocation’ and defines the service layer thisTRX belongs to. For further details, please refer to the command SET BTS [SERVICE].

LPDLMN=0,

object: TRX

range: 0..7

LPDLM number , this parameter defines the "primary" LPDLM object position (PCMB number and TS LAPD number) of the LPDLR links.

Background :Every TRX has an associated LPDLR channel, which is used for theradio signaling (i.e. signalling for call processing) of this particular TRX. In other words, any cell access, signaling transaction or call which invloves any radio channel (CHAN object) subordinate to thisTRX, is signaled via this LPDLR, no matter whether it is- a BCCH procedure (e.g. random access via the RACH (CHANNELREQUIRED sent by the BTS), paging via the PCH (PAGINGCOMMANDs sent the BSC) or an Immediate Assignment procedurevia the AGCH (IMMEDIATE ASSIGNMENT sent by the BSC))- an SDCCH transaction (e.g. Location Update, SMS in idle mode,IMSI detach etc.) or - a transaction signaled via an SACCH or FACCH (TCH assignment,handover, SMS in busy mode etc.)

Physically the LPDLR signalling messages are sent within the same Abis timeslot(s) which is (are) assigned to an existing LPDLM object(s) for the responsible BTSM. The distinction between theLPDLM messages (O&M messages between BSC and BTSM) and





the LPDLR messages (TRX-specific radio signaling communicationbetween BSC and BTS/TRX) is made on the basis of the LAPDaddressing identities SAPI (Service Access Point Identifier) and TEI (Terminal Endpoint Identifier) in the layer-2 header of the LAPDmessages: While LPDLM messages are always signaled withSAPI=62 and the TEI of the BTSM (as defined in the parameter TEI in command CREATE BTSM), the radio signalling messages related to a particular TRX are always signaled with SAPI=0 and the TEI no.

which is automatically assigned to the TRX during the BTSE alignment (the TEI assignment of a TRX can be interrogated by thecommand GET TRX).

The parameter LPDLMN identifies the LPDLM link (and thus the physical Abis timeslot) via which the LPDLR signalling of the TRX shall be performed. If only one LPDLM is created for a particular BTSM, of course, only this LPDLM number can be selected for LPDLMN. If, however, more than one LPDLM is created for a

particular BTSM, LPDLMN determines the LPDLM, via which theLPDLR signalling of a particular TRX shall be performed by default.Thus the LPDLMN definition defines the standard load sharing distribution for radio signalling communication among the available

physical Abis timeslots that were configured as LPDLMs. If anLPDLM fails (e.g. due to failure of the superordinate PCMB link), the

radio signalling messages of the affected TRX are automatically transmitted via one of the remaing LPDLMs in order to guarantee theavailability of all TRXs of the BTSM, even if one of the PCMBconnections has failed. The restrictions to be considered in this caseis the fact that the possible traffic volume will be limited due to theunavailability of a part of the Abis TCH resources and the limitation of the LAPD throughput capacity, which might lead to high LAPDtransmission.

Please see also the parameters TEI (in command CREATE BTSM), ABISCH (in command CREATE LPDLM) and the explanations provided for the command CREATE SUBTSLB.

MAIO=<NULL>,

object: TRX


default: <NULL>


GSM 04.08

Mobi le al location index offset , this parameter determines the position of all channels subordinate to this TRXwithin the frequency hopping algorithm defined by the parameter FHSYID (see above).

Starting from BR8.0 the parameters FHSYID and MAIO (that inreleases up to BR7.0 had been available in the CHAN object only,see command CREATE CHAN) are also available in the TRX object.When these parameters in the TRX object are used this means that for all CHAN objects subordinate to the TRX the same hopping law (with Mobile Allocation (MA) and Hopping Sequence Number (HSN)as defined in the assigned FHSY) is used - which is the usual case,especially in case of synthesizer frequency hopping. If the hopping

parameters FHSYID and MAIO of the TRX object are filled theequivalent parameters in the CHAN object must be set to the<NULL> value in this case.

If the hopping system is to be defined by the CFHSY object (this ismandatory in case of Dynamic MAIO Allocation (DMA), the

parameters MAIO and FHSYID must be defined in the TRX object.For further details about frequency hopping and the creation of hopping systems for Static MAIO Allocation (SMA) and Dynamic MAIO Allocation, please refer to the following commands and

parameter descriptions- command CREATE FHSY - parameters FHSYID and MAIO in command CREATE CHAN - parameters HOPP and HOPMODE in command SET BTS[OPTIONS] - commands CREATE CBTS and CREATE CFHSY

MOEC=TRUE, Member of emergency con figurat ion , this parameter determineswhether a TRX belongs to the 'Emergency Configuration' or not (see





object: TRX

range: TRUE, FALSE

default: TRUE

also parameters EMT1 and EMT2 in the command CREATE BTSM).'Emergency configuration' is entered in case of a failure of theexternal BTSE power supply (alarm 'ACDC MAINS BREAKDOWN')or if the shelter temperature exceeds the allowed threshold (alarm'SHELTER TEMPERATURE OUT OF TOLERANCE'). Its purpose isto keep only the most important BTSE units and TRXs alive and thusto save power as long as the BTSE is powered by the backupbattery. Setting MOEC to TRUE for a TRX means that the HW

associated to this TRX will be powered if emergency configuration isentered.

PWRRED=6,

object: TRX

unit: 2dB

range: 0..6 (0dB-12dB)

default: 6


Power reductio n , specifies the number of 2-dB-steps the Tx power should be reduced from the maximum transmit power. Since thesending power determines the actual cell size the PWRRED

parameter is used to adjust the sending power according to thedesired transmission range.Note for concentric cells: Since in concentric cells (see parameter CONCELL in command CREATE BTS [BASICS]) this parameter determines the different ranges of inner and complete area TRXs it must be set in accordance with the setting of the parameter TRXAREA (see below)!

If a cell is configured for two different frequency bands (dual band concentric cells, or dual band standard cells, refer to parameters

CELLTYP and CONCELL, see above) the use of the PWRRED might be necessary to control the coverage of the TRXs, considering thedifferences in the output power of the TRX HW (CU/PA) for different frequency bands and the propagation attenuation of the different used frequency.

Rules:For configuration rules concerning concentric cells and dualband concentric cells please refer to the description of parameter HORXLVDLO (see command SET HAND [BASICS]).

RADIOMG=254,

object: TRX


range: 1-254

default: 254

Radio measurement granular i ty for measurements on Abis , this parameter is only relevant if the parameter RADIOMR is set to ON (see below) and specifies the granularity periods for retrieval of themeasurement reports which are to be sent on the Abis interface in

case they are enabled. If the Abis has to be traced for radiodiagnostic of handover performance diagnostic reasons it isrecommended to set the radio measurement granularity to ‚1’ because only in this case all measurement reports from the MS and the BTS will be transmitted on the Abis. However, it has to beconsidered that the enabling of the Radio Measurements on the Abisinterface cause an additional load on the LPDLR links: the lower thevalue for RADIOMG, the higher the signalling load on the LPDLRs.

RADIOMR=OFF,

object: TRX

range: ON, OFF

default: OFF

Radio measurement reports , specifies whether radio measurement report transmission via the Abis interface is enabled. Since in theSBS the preevaluation of measurement reports for handover decisions is done in the BTS, normally no measurement reports aresent from BTS to BSC. In some cases, however, it is useful tomonitor the measurement reports on the Abis interface for test

purposes. Only in this case the feature should be activated since it results in additional load on the LPDLR links. The frequency of themeasurement reports to be sent via the Abis can be controlled by thefollowing parameter RADIOMG (see below).

Note: The MEASUREMENT RESULT messages on the Abis alsocontain a timing advance (TA) value. The timing advance value isdetermined by the BTS on the basis of the delay (within the guard

period) of the bursts received from the MS and this value is used toinstruct the MS to transmit its next bursts with a specific ‘timing advance’ in order to ensure that the BTS receives the burst within theguard period. This instruction from BTS to MS is called ‘timing advance order’ and is acknowledged by the MS in the ‘TA confirm’,





i.e. with the ‘TA confirm’ the MS confirms that it has transmitted itsbursts in correspondence with the previous ‘TA order’. TheMEASUREMENT RESULTs contain the ‘confirmed’ TA value of the

previous measurement period. This principle also goes for theTRACE MEASUREMENT RESULTs that are sent on the Abis whenCTR (see command CREATE CTRSCHED) or IMSI Tracing (seecommand CREATE TRACE) is enabled. In contrast, the SCAmeasurements (see command CREATE SCA) count the ‘TA order’

events.TRXMD=GSM,

object: TRX

range: GSM, EDGE

default: GSM

Reference:

TRX Mode , this parameter indicates the capability of the TRX tosupport EDGE. Thie parameter can only be set to the value EDGE, if the TRX-HW which is associated to the created TRX object an EDGE CU (ECU).

Only if TRXMD is set to EDGE for the BCCH TRX, it is possible to set the parameter EBCCHTRX (command SET PTPPKF, see next command) to TRUE.

TRXAREA=NONE,

object: TRX

range: NONE, INNER,

COMPLETE

default: NONE

TRX area , this parameter specifies whether a TRX belongs to aconcentric cell (see parameter CONCELL in command CREATE BTS[BASICS]) and, if yes, whether it serves the inner or the completearea.Notes:- this parameter must be set in conjunction with a sensible setting of PWRRED (see above)! - the BCCH frequency and all other frequencies with control channels(CCCH, SDCCH) must belong to the complete area (see command CREATE CHAN).

TRXFREQ=CALLF01,

object: TRX

range: BCCHFREQ,

CALLF01.. CALLF63

CCALLF01.. CCALLF63


GSM 05.08

TRX frequency , assigns a radio frequency to a transceiver. FromBR6.0 on the radio frequency assigned to the TRX is no longer represented by its absolute radio frequency number (ARFCN) but by its relative number CALLFxx which was assigned to the frequency during creation of the BTS cell allocation (please refer to the

parameters CALLF01..CALLF63 and BCCHFREQ in the command CREATE BTS [BASICS]). If the TRX represents the BCCH carrier,the value of TRXFREQ must be BCCHFREQ.

USFGRAN=DISABLED,

object: TRX


default: DISABLED

USF granular i ty , this parameter defines if USF granularity 1 is

supported or not.

Enabling GPRS and EDGE in a cell:

< The specific parameters related to the enabling of GPRS and EDGE can only be entered if TRX objects were created before withthe appropriate attributes. For this reason DBAEM places thecommand CREATE PTPPKF again after the creation commands for the TRXs with additional parameters. >

SET PTPPKF:

NAME=BTSM:0/BTS:0/PTPPKF:0,

Object path name , range for PTPPKF: 0..0.





EBCCHTRX=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Reference:

recommended value: TRUE

(if BCCH TRX is equipped with ECU)

EGPRS 8PSK on BCCH TRX , this parameter indicates if EDGE 8PSK modulation is supported on the BCCH TRX. The setting TRUE is only possible if the BCCH TRX is epuipped with EDGE CU (ECU)at least for the BCCH TRX.

Attention:

- Also the other TRXs of the same BTSE should be equipped withECU in this case, as in case of automatic BCCH reconfiguration, theBCCH TRX might be served by a different TRX-HW branch.

- The operator must consider that, due to the higher power density of 8PSK modulated signals, the CU cannot generate the samemaximum output power for 8PSK like for GMSK.

If the CU is operated with static power reduction (at least PWRRED=1(=2dB), better PWRRED=2, see TRX object), there is no

problem as the CU HW has enough reserves to support the 8PSK power requirement (in this case the deviations remain within thetolerances specified by the 3GPP standard). Thus, with PWRREDapplied, the BTS correctly equalizes the output power levels on both8PSK and GMSK timeslots.

If no PWRRED is applied, the maximum power values that can be provided on 8PSK timeslots in the downlink will always be by 2-3dBsmaller than the maximum power values on GMSK timeslots.

This may be a problem if EGPRS with 8PSK coding schemes is used on the BCCH TRX and PWRRED=0, as all BCCH TRX timeslotsmust transmit with equal maximum power to guarantee a stable DLlevel reference for neighbour cell measurements. If EGPRS with8PSK coding schemes is allowed on the BCCH TRX, this will lead,depending on the number of timeslots busy with 8PSK coding schemes, to a falsification of the BCCH transmit power, i.e. themeasured power will be lower than it really is (on the GMSK timeslots).

In this case the operator has 3 main possibilities:

1. The operator can change the PWRRED values. This, however, will reduce the coverage area and may contradict to the original coverage planning concept.

2. If the operator does not want to change the cell coverage planning

(which was based on PWRRED=0) he may accept the falsification of the BCCH level and adapt the relevant ADJC handover parametersaccordingly (e.g. reduce RXLEVMIN and HOM by 1dB, seecorresponding parameters in command CREATE ADJC) in thesurrounding cells.

3. The operator can make use of the feature Multi Service Layer Support (MSLS) to allocate EGPRS call only on non-BCCH TRXswith suitable quality figures. In this way the falsification of the BCCH signal is avoided and no further parameter adjustment is necessary.This may, however, be a problem in cells with a small number of TRXs (e.g. 2 TRX only). For further information about MSLS pleaserefer to command CREATE CBTS.





EEDGE=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Reference:


(if at least one TRX is equipped with

ECU)

Enable EDGE , this parameter parameter allows to enable/disableEGPRS (EDGE GPRS) on a per cell basis. As this paramter can only be set to TRUE, if at least one of the TRXs in the cell support EDGE (see parameter TRXMD in command CREATE TRX),

EGPRS=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Reference:


Enable GPRS , this parameter parameter allows to enable/disableGPRS on a per cell basis. As this paramter can only be set to TRUE,if at least one of the TRXs in the cell supports GPRS (this is the caseif the TRX is defined as belonging to a service layer which is included in the SLL for GPRS services - please see command SET BTS[SERVICE] for further explanations).





Creating the BCCH for the cell:

CREATE CHAN:

NAME=BTSM:0/BTS:0/TRX:0/CHAN:0,

Object path name .

CHTYPE=MAINBCCH,

object: CHAN

range: see parameter explanations

on the right


GSM 05.02

GSM 04.08

Channel type , possible values:

a) normal broadcast control channel including frequency correctionand synchronization cannel:MAINBCCH = FCCH + SCH + BCCH + CCCH* b) broadcast and common CCH only CCCH = BCCH + CCCH (CCCH = PCH + RACH + AGCH) c) Main BCCH with reduced CCCH capacity plus stand-alonededicated CCH/4MBCCHC = FCH + SCH + BCCH + CCCH* + SDCCH/C4 (0..3) +

SACCH/C4 (0..3)d) MBCCHC plus SMS cell broadcast channel BCBCH = FCCH + SCH + BCCH + CCCH* + SDCCH/C4 (0..3) +

SACCH/C4 (0..3) + CBCH Notes:- Only one FCCH/SCH is allowed per cell - on timeslot 0 of C0!

- Creation of additional BCCH+CCCH (CHTYPE=CCCH) is possiblebut only on the timeslots 2,4 and 6 of C0. The info about the used control channel configuration is sent in the Parameter ‘CCCH_CONF’, which is part of the IE ‘Control Channel description’ sent in the SYS_INFO3 on the BCCH. If more than one BCCH iscreated for a cell the MSs observe the BCCH on timeslot 0 first and -having detected that there are more than one (from theCCCH_CONF ) - select one BCCH/CCCH timeslot for all their CCCH activities on the basis of their “CCCH_GROUP”. The CCCH_GROUP is calculated from the last three digits if the IMSI and the CCCH configuration (which is derived from the parameters CCCH_CONF,NFRAMEPG and NBLKACGR - see GSM05.02 for details).- The CBCH replaces the 2nd SDCCH, i.e. there are only 3 SDCCH available if BCBCH is selected; only one CBCH is allowed per cell.

- A MBCCHC or a BCBCH can only be created if NBLKACGR ≤ 2 (see corresponding parameter in command SET BTS [CCCH])- In a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) all frequencies with common control channels (BCCH,CCCH) must belong to the complete area.

EXTMODE=FALSE,

object: CHAN

range: TRUE, FALSE

default: FALSE

Extended m ode , this parameter defines whether the channel is used in 'extended mode' for extended cells or not.Notes:- If the cell type is extended cell (i.e. CELLTYPE=EXTCELL(CREATE BTS [BASICS])) then all control channels must be set for 'extended mode'.- The radio timeslot of an 'extended' channel must have an evennumber (0,2,4... etc.).





FHSYID=0,

object: CHAN

range: FHYS_ 0..FHSY_ 10,

<NULL>

default: 0 = no hopping


GSM 04.08

GSM 12.20

Frequency hopping sy stem identi f ier , 0(=no hopping) ismandatory for the BCCH.

MAIO=0,

object: CHAN


default: 0


GSM 04.08

Mobi le al location index offset , not used here since FHSYID=0.

(TSC=),

object: CHAN

range: 0..7

default: BCC of BSIC

(CREATE BTS [BASICS])


GSM 04.08

Training Sequence Code , this optional parameter specifies theTraining Sequence Code of the radio channel. The TSC is part of the‘Normal Bursts’ which are used for all channel types except RACH,SCH and FCCH. The TSC for the BCCH must correspond to theBCC (part of the BSIC sent on the SCH, see CREATE BTS [BASICS]

parameter BSIC) so that the MS can derive the TSC of the BCCH

from the SCH. This is necessary for the correct selection and decoding of the BCCH bursts, especially if within a limited geographical area a frequency is used several times. If no value isentered for the parameter TSC the BCC is automatically selected.

Creating the SDCCHs for the cell:

< Note: All the TRXs with channels of type SDCCH have to be

included in a Layer associated at least to the Signalling SLL (see

command SET BTS [SERVICE] for further explanations), otherwise

these channels will never be used as singalling channel. >

CREATE CHAN:

NAME=BTSM:0/BTS:0/TRX:0/CHAN:1,

Object path name .

CHTYPE=SCBCH,

object: CHAN


on the right


GSM 05.02

GSM 04.08

Channel type , possible values:a) pure stand-alone dedicated CCH/8 incl. SACCH SDCCH = SDCCH/C8 (0..7) + SACCH/C8 (0..7)b) SDCCH/8 plus SMS cell broadcast channel SCBCH = SDCCH/C8 (0..7) + SACCH/C8 (0..7) + CBCH

Notes:- An SDCCH/8 can also be created as follows:CHTYP=TCHSD,CHPOOLTYP=TCHPOOL (see CREATE CHAN command for TCHSDs).- At least one SDCCH must be created on the BCCH TRX (due to theimplementation of BCCH recovery)

- The CBCH must be created on the BCCH TRX.- The SCBCH can only be created on the timeslots 0,1,2 and 3! - An SCBCH can only be created if NBLKACGR > 0 (seecorresponding parameter in command SET BTS [CCCH])- The CBCH replaces the 2nd SDCCH, i.e. there are only 7 SDCCH available; only one CBCH is allowed per cell.- In a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) all frequencies with SDCCHs must belong to the complete area.- In an extended cell (CELLTYPE=EXTCELL, see command CREATE BTS [BASICS]), all SDCCHs must be created as ‘double’ timeslots (EXTMODE=TRUE, see below).





- When an Abis interface is configured via satellite, it is urgently recommended to configure multiple SDCCH channels on different TRXs. This is necessary because the Abis LAPD transmit queues inthe BTS are managed per TRX(TEI), i.e. each TRX (TEI) has an owntransmit queue. As the biggest percentage of all signalling activitiesin a cell are processed via the SDCCHs, it is recommended, to avoid an excessive concentration of the SDCCH signalling within one TRX (and thus one LPAD transmit queue), to distribute multiple SDCCHs

over different TRXs within the cell. Otherwise the probability of theBTSE alarm ‘LAPD TRANSMIT QUEUE OVERFLOW’ will considerably increase, although with a more even distribution of thesignalling load over the TEIs this could be avoided.

EXTMODE=FALSE,

object: CHAN

range: TRUE, FALSE

default: FALSE

Extended m ode , this parameter defines whether the channel is used in 'extended mode' for extended cells or not.Notes:- If the cell type is extended cell (i.e. CELLTYPE=EXTCELL(CREATE BTS [BASICS])) then all control channels (BCCH, CCCH,CBCH and SDCCH) must be configured as ‘double’ timeslots(EXTMODE=TRUE).- The radio timeslot of an 'extended' channel must have an evennumber (0,2,4... etc.).

FHSYID=FHSYID_ 2,

object: CHAN

range: FHSY_ 0..FHSY_ 10,

<NULL>



GSM 04.08

GSM 12.20

Frequency hopping sy stem identi f ier , 0=no hopping, all other

values ‘X’ must have been created for this cell (BTS) before by CREATE FHSY:NAME=bsc:n/bts:n/fhsyid:x.Notes:- If synthesizer frequency hopping is used, hopping is not allowed for any CHAN object belonging to the BCCH TRX.- In concentric cells (CREATE BTS [BASICS]:CONCELL=TRUE)hopping is only allowed within the complete and within the inner area.This has to be taken into account when the FHSYIDs are assigned tothe CHAN objects.- If Interference Classification of idle TCHs is enabled (see parameter INTCLASS in command SET BTS) while frequency hopping is active,the BTS measures the interference considering all frequencies used in the hopping sequence assigned to the a TCH in the frequency hopping system!

- The frequency hopping system can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the<NULL> value in this case.

MAIO=0,

object: CHAN

range: 0..63, , <NULL>

default: 0


Mobi le al location index offset , start position of the channel in thefrequency hopping algorithm.

Note:- The MAIO can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA,for further details see command CREATE CBTS) is not used for theservice layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in theTRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.





(TSC=),

object: CHAN

range: 0..7




GSM 04.08

Training Sequence Code , this optional parameter specifies theTraining Sequence Code of the radio channel. The TSC is part of the‘Normal Bursts’ which are used for all channel types except RACH,SCH and FCCH. The TSC entered here is sent to the MS in the IE ‘Channel Description’ within the ASSIGNMENT COMMAND for theSDCCH. This is necessary for the correct decoding of the SDCCH.The TSC for any type of SDCCH must correspond to the BCC (part

of the BSIC sent on the SCH, see CREATE BTS [BASICS] parameter BSIC).If no value is entered for the parameter TSC the system automatically selects the BCC (see parameter BSIC (CREATE BTS [BASICS])) asTSC.

Creating the TCHs for the cell:

CREATE CHAN:

NAME=BTSM:0/BTS:0/

TRX:0/CHAN:3,

Object path name .

CHTYPE=TCHF_HLF,

object: CHAN


on the right


GSM 05.02

GSM 04.08

Channel type , possible values for TCH creation:

a) Full Rate channelsTCHFULL = TCH/F + FACCH/F + SACCH/TF

b) Dual rate (full and half) channels TCHF_HLF = TCH/H(0) + FACCH/H(0) + SACCH/H(0) + TCH/H(1)or

TCH/F + FACCH/F + SACCH/TF Notes:- A dual rate TCH can also be created as follows:CHTYP=TCHSD,CHPOOLTYP=TCHPOOL (see next CREATE CHAN command for TCH/SDs).- The FR portion of the TCH always implies speech versions FR,

EFR and AMR FR; the HR portion implies HR and AMR HR. Whichspeech version is used for TCH assignment depends on the MScapability and preference as well as on BSC database settings (see

parameters EFRSUPP and HRSPEECH in command SET BSC [BASICS] and EHRACT in command CREATE BTS [BASICS]).

EXTMODE=FALSE,

object: CHAN

range: TRUE, FALSE

default: FALSE

Extended m ode , this parameter defines whether the channel is used in 'extended mode' for extended cells or not.Notes:- If the cell type is extended cell (CREATE BTS[BASICS]:CELLTYPE=EXTCELL) then all control channels must beset for 'extended mode', while TCHs may be created as 'single' and 'extended' timeslots (see also parameters CELLTYPE in command CREATE BTS [BASICS] and EXTCHO in command SET HAND[BASICS]).

- The radio timeslot of an 'extended' channel must have an evennumber (0,2,4... etc.).- If an extended cell is the target of an inter-cell HO the handover will always take place to a 'double' timeslot first as the BTS can only determine the actual MS-BTS distance when the first MS messagesare received. If the MS-BTS distance turns out to be small enough for a 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled).





FHSYID=FHSY_ 1,

object: CHAN


<NULL>



GSM 04.08

GSM 12.20

Frequency hopping sy stem identi f ier , 0=no hopping, all other values Y must have been created before by CREATE FHSY:NAME=bsc:n/bts:n/fhsyid:y.Notes:- If synthesizer frequency hopping is used, hopping is not allowed for any CHAN object belonging to the BCCH TRX.- In concentric cells (see CREATE BTS [BASICS]:CONCELL=TRUE)

hopping is only allowed within the complete and within the inner area.This has to be taken into account when the FHSYIDs are assigned tothe CHAN objects.- If Interference Classification of idle TCHs is enabled (see parameter INTCLASS in command SET BTS [INTERF]) while frequency hopping is active, the BTS measures the interference considering all frequencies used in the hopping sequence assigned to the a TCH inthe frequency hopping system! - The frequency hopping system can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and

FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the<NULL> value in this case.

GDCH=<NULL>,

object: CHAN

range: <NULL>

PBCCH, PCCCH,

default: <NULL>

GPRS Dedicated Channel , this parameter determines the TCH configuration for GPRS usage. The following values are possible:a) PBCCH : The TCH is fixed defined as Packet BCCH.b) PCCCH : The TCH is fixed defined as Packet Common Control CHannel c) <NULL> identifies a “shared” TCH. Shared TCHs can be used for GPRS and circuit switched traffic. All TCHs (TCHFULL, TCHF_HLF and TCHSD with CHPOOLTYP=TCHPOOL) for which GDCH is set to <NULL> (and for which the superordinate TRX supports GPRS,which is the case if the TRX is defined as belonging to a service layer which is included in the SLL for GPRS services - please see

command SET BTS [SERVICE] for further explanations) belong tothe pool of TCHs that can be used for both circuit-switched calls and GPRS calls (so-called “Shared traffic channels”). The number of these TCHs that may be aligned as PDCHs simultaneously isdetermined by the parameter GPDPDTCHA (see CREATE PTPPKF).Whether the GPRS calls can be preempted by CS calls depends onthe setting of the downgrade strategy (see parameter DGRSTRGY incommand SET BT S [BASICS] ).

Notes:- If GDCH is set to PBCCH, the GPRS mobile will not listen to theGSM BCCH but instead read the packet system information on thePBCCH. By creating a PBCCH the signalling of circuit switched and

packet switched traffic can be separated to avoid impacts on thecircuit switched capacity in case of GPRS congestion and vice versa.

- GDCH can be set to PCCCH only if a PBCCH was created before. A packet CCCH basically extends the CCCH capacity of the already created PBCCH.- If no PBCCH is defined in the cell, the GPRS system information isbroadcast on the existing (GSM-)BCCH within the SYSTEM INFORMATION TYPE 13. GPRS access is then performed via thenormal (GSM-) RACHs and an initial TBF assignment (IMMEDIATE

ASSIGNMENT) is sent via the (GSM-)AGCH/PCH.





MAIO=0,

object: CHAN


default: 0


GSM 04.08

Mobi le al location index offset , determines start position of thechannel in the frequency hopping algorithm. This parameter is sent inthe main DCCH in the IE ‘Channel Description’ (contained e.g. in the

ASSIGNMENT COMMAND) if it was assigned to a used channel. If frequency hopping is enabled the parameter H is set to 1. In this casethe IE also contains the HSN together with the MAIO.

Note:

- The MAIO can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA,for further details see command CREATE CBTS) is not used for theservice layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in theTRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.

TERTCH=0..2-2,

object: CHAN

format: <PCMB-no.>-<timeslot no.>

range: PCMB: 0..34

timeslot-no.: 1-31 (PCM30)

1-24 (PCM24)subslot-no.: 0..3

Terrestrial chann el , this parameter defines the terrestrial channel, towhich the TCH is mapped. The mapping is fixed. T:

pcmb-no. - timeslot no. - subslot-no.

(TSC=),

object: CHAN

range: 0..7




GSM 04.08

Training Sequence Code , this optional parameter specifies theTraining Sequence Code of the radio channel. The TSC is part of the‘Normal Bursts’ which are used for all channel types except RACH,SCH and FCCH. The TSC entered here is sent to the MS in the IE ‘Channel Description’ within the ASSIGNMENT COMMAND for theTCH. This is necessary for the correct decoding of the TCH.If no value is entered for the parameter TSC the system automatically selects the BCC (see parameter BSIC (CREATE BTS [BASICS])) asTSC.





Creating hybrid TCHs/SDCCHs (TCH/SD) for the cell:

< The creation of hybrid TCHs/SDCCHs (TCH/SD) is an integral part of the feature “Set Command for Changes of Channel Combinations” and “Smooth Channel Modification” introduced in BR6.0.

a) The purpose of the feature “ Set Comm and for Changes of

Channel Comb inations ” is to allow a change of the channel type

from TCH to SDCCH and vice versa without any service impact. Tochange the channel type (CHTYPE) for a specific CHAN object, it isnecessary to delete and re-create it. However, whenever a channel on a TRX is deleted and created again, a reset of the BBSIGrespectively CU is triggered which causes the interruption of all callscurrently served by the affected TRX. With the new feature it is

possible to use the new channel type TCH/SD and to determine itsmode of operation (SDCCH or TCH) by the parameter CHPOOLTYP (for further details please see below). The mode of operation(SDCCH or TCH) can be changed using the CHPOOLTYP in a SET CHAN command. This SET CHAN command can be executed without any impact on the calls ongoing on the superordinate TRX.

b) The purpose of the feature “ Smooth Channel Modif icat ion ” is toallow a dynamic “on-demand” extension of the SDCCH capacity in

case of SDCCH congestion. The feature avoids blocking of theSDCCH in cases of unexpected high SDCCH loads generated by SMS traffic or in specific areas (e.g. airports, train stations etc.).Channels that shall be dynamically used both as SDCCH and TCH must be created with CHTYPE=TCHSD and parameter CHPOOLTYP=TCHSDPOOL (see below). When the SDCCH utilization resp. SDCCH traffic load exceeds the threshold SDCCHCONGTH (see command CREATE BTS [BASICS]) theswitchover from ‘Dual Rate TCH mode’ to ‘SDCCH/8 mode’ takes

place automatically.

For this feature, a pool-concept was introduced for the dedicated radio channel resources:

• The SDCCH_POOL contains all channels declared as SDCCH/4

(CHTYPE=MBCCHC and BCBCH), SDCCH/8 (CHTYPE=SDCCH and SCBCH) and TCH/SD that the operator decides to use as

configured SDCCHs (CHTYPE=TCHSD with POOLTYPE=

SDCCHPOOL).

• The TCH_POOL contains all channels declared as TCH full or

TCH dual (CHTYPE=TCHFULL or TCHF_HLF) and TCH/SD that

the operator decides to use as configured TCHs

(CHTYPE=TCHSD with POOLTYPE=TCHPOOL). These TCH

may be used for both CS and GPRS traffic.

• The TCH/SD_POOL contains all channels created as TCH/SD that

the operator decides to share between the TCH and SDCCH

resources depending on the SDCCH traffic load situation

(CHTYPE=TCHSD with POOLTYPE=TCHSDPOOL).

• The SDCCH_BACKUP_POOL is an additional system-internal (not configurable) pool that contains the TCH/SD sub-channels

that are temporarily used as SDCCH. If during the processing of an

SDCCH request the percentage of busy SDCCHs has exceeded

the threshold SDCCHCONGTH, the BSC moves 8 SDCCH sub-

channels from the TCH/SD_POOL to the

SDCCH_BACKUP_POOL A configurable timer (see parameter

TGUARD in the command SET BSC [BASICS]) avoids oscillation

between both pools.

Within each pool the ‘idle Interference band’ classifies the resources.

This classification is also valid for the TCH_SD used as SDCCH.





Note: All the TRXs with channels of type TCHSD in SDCCH_POOL,

TCHSD in TCHSD_POOL have to be included in a Layer associated

at least to the Signalling SLL (see command SET BTS [SERVICE] for

further explanations), otherwise these channels will never be used as

singalling channel (TCHSD with TCHSD Pool can be used also as

traffic channels). >

CREATE CHAN:NAME=BTSM:0/BTS:0/TRX:0/CHAN:4,

Object path name .

CHTYPE=TCHSD,

object: CHAN


on the right


GSM 05.02

GSM 04.08

Chann el type = TCHSD , this parameter was introduced in BR6.0 for the features ‘ Smooth Channel modification ’ and ‘ Set Command for Changes of Channel Combinations ‘.

TCHSD = SDCCH/8 + SACCH/8 + TCH/H(0,1) + FACCH/H(0,1) +SACCH/TH(0,1) or TCH/F + FACCH/F + SACCH/F

The above channel capability description means that the channel type TCHSD represents a channel, that can work a) as pure Dual Rate TCH,b) as pure SDCCH/8 or b) can dynamically change between both modes (DR-TCH or

SDCCH/8).Which of these operation modes is in effect, depends on the setting of the parameter CHPOOLTYP (see below). Please refer toCHPOOLTYP for further details about the mentioned features.

Note:

When an Abis interface is configured via satellite, it is urgently recommended to configure multiple SDCCH channels (and thus alsoall TCHSDs with CHPOOLTYP=SDCCHPOOL or TCHSD) ondifferent TRXs. This is necessary because the Abis LAPD transmit queues in the BTS are managed per TRX(TEI), i.e. each TRX (TEI)has an own transmit queue. As the biggest percentage of all signalling activities in a cell are processed via the SDCCHs, it isrecommended, to avoid an excessive concentration of the SDCCH signalling within one TRX (and thus one LPAD transmit queue), to

distribute multiple SDCCHs over different TRXs within the cell.Otherwise the probability of the BTSE alarm ‘LAPD TRANSMIT QUEUE OVERFLOW’ will considerably increase, although with amore even distribution of the signalling load over the TEIs this could be avoided.

CHPOOLTYP=TCHSDPOOL,

object: CHAN

range: TCHPOOL

SDCCHPOOL

TCHSDPOOL

<NULL>

default: <NULL>

Channel pool type , this parameter can only be set for those

channels that have been created with CHTYPE=TCHSD and defines

its application (pool type).

1) If CHPOOLTYP=TCHPOOL the TCHSD is fixed configured as

TCH and used exclusively as TCH, i.e. it is handled by the call

processing and channel allocation as a normal dual rate TCH. The

advantage of this configuration compared to the one with

CHTYPE=TCHF_HLF is that it is possible to change this channel to

‘SDCCH mode’ without service interruption of the TRX by entering the command SET TRX:CHPOOLTYP=SDCCHPOOL.

Channels of this type are part of the system-internal TCH_POOL.

2) If CHPOOLTYP=SDCCHPOOL the TCHSD is fixed configured as

SDCCH/8 and used exclusively as SDCCH/8, i.e. it is handled by the

call processing and channel allocation in the same way as if it was

created with CHTYPE=SDCCH. The advantage of this configuration

compared to a normal SDCCH is that it is possible to change this

channel to ‘Dual rate TCH mode’ without service interruption of the

TRX by entering the command SET TRX:CHPOOLTYP=TCHPOOL.

Channels of this type are part of the system-internal SDCCH_POOL.





3) If CHPOOLTYP=TCHSDPOOL the TCHSD can be used for

Smooth Channel Modification, i.e. its mode of operation (Dual Rate

TCH or SDCCH/8) can be dynamically changed depending on the

SDCCH traffic load in the cell (see parameter SDCCHCONGTH in

command CREATE BTS).

TCHSD mo de (Dual Rate TCH)

TCHSDs with CHPOOLTYP=TCHSDPOOL are initially part of the

system-internal TCH/SD_POOL . In this mode a TCH/SD works as

normal dual rate TCH, but is only selected by the TCH allocation

algorithm if no idle TCH from the TCH_POOL (CHTYPE=TCHFULL

or TCHF_HLF) can be found. Within the TCH_POOL and the

TCH/SD_POOL, the TCHs with the best interference class (see par.

INTCLASS in command SET BTS [INTERF]) are allocated first.

SDCCH mo de (SDCCH/8)

If the SDCCH traffic load has exceeded the SDCCH traffic load

threshold SDCCHCONGTH (see CREATE BTS [BASICS]) the BSC

moves 8 SDCCH subchannels from the TCH/SD_POOL to the

SDCCH_BACKUP_POOL. In this mode the channel works as a

normal SDCCH/8, but its SDCCH subslots are only selected by the

SDCCH allocation algorithm if no idle SDCCH from the

SDCCH_POOL (CHTYPE=SDCCH, SCBCH, MBCCHC or BCBCH))

can be found.

For the change of the mode of operation (SDCCH/8 or Dual Rate

TCH) no special signalling activity is required: instead, the channel

mode change is simply indicated by the channel type in the

CHANNEL ACTIVATION procedure, which the BSC performs before

it sends an ASSIGNMENT COMMAND (for TCH assignment)

respectively an IMMEDIATE ASSIGNMENT (for SDCCH

assignment).

Notes:

- Only TCH/SDs with CHPOOLTYP=TCHPOOL can be used for

GPRS traffic (“shared” TCH)!

- The BTS does not know anything about the association of the

TCH/SD channels to the ‘BSC channel pools’. Instead, for the BTS a

TCH/SD is treated as a normal dual rate TCH if it is ‘idle’ (i.e.in thiscase the idle TCH measurements are sent to the BSC) or if it has

received a CHAN ACT for channel type ‘TCH’. If it has received a

CHAN ACT for channel type ‘SDCCH’, it is treated as SDCCH/8.

EXTMODE=FALSE,

object: CHAN

range: TRUE, FALSE

default: FALSE

Extended mod e , this parameter defines whether the channel is used in 'extended mode' for extended cells or not.Notes:- If the cell type is extended cell (CREATE BTS[BASICS]:CELLTYPE=EXTCELL) then all control channels must beset for 'extended mode', while TCHs may be created as 'single' and 'extended' timeslots (see also parameter EXTCHO in command SET HAND [BASICS]).- The radio timeslot of an 'extended' channel must have an evennumber (0,2,4... etc.).- If an extended cell is the target of an inter-cell HO the handover will always take place to a 'double' timeslot first as the BTS can only determine the actual MS-BTS distance when the first MS messagesare received. If the MS-BTS distance turns out to be small enough for a 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled).





FHSYID=FHSY_ 1,

object: CHAN


<NULL>



GSM 04.08

GSM 12.20

Frequency hopping sy stem identi f ier , 0=no hopping, all other values Y must have been created before by CREATE FHSY:NAME=bsc:n/bts:n/fhsyid:y.Notes:- If synthesizer frequency hopping is used, hopping is not allowed for any CHAN object belonging to the BCCH TRX.- In concentric cells (see CREATE BTS [BASICS]:CONCELL=TRUE)

hopping is only allowed within the complete and within the inner area.This has to be taken into account when the FHSYIDs are assigned tothe CHAN objects.- If Interference Classification of idle TCHs is enabled (see parameter INTCLASS in command SET BTS [INTERF]) while frequency hopping is active, the BTS measures the interference considering all frequencies used in the hopping sequence assigned to the a TCH inthe frequency hopping system! - The frequency hopping system can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and

FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the<NULL> value in this case.

GDCH=<NULL>,

object: CHAN

range: <NULL>

default: <NULL>

GPRS Dedicated Channel , this parameter determines the TCH configuration for GPRS usage (for further details please see thesame parameter in the previous CREATE CHAN command for thecreation of Full Rate or Dual Rate TCHs). It is only relevant for the

parameter combination CHTYP=TCHSD,CHPOOLTYP=TCHPOOL(for parameter CHPOOLTYP please see above) which indicates that the TCHSD operates as a normal TCH. Only in this case the CHAN object belongs to the system-internal TCH_POOL. In thisconfiguration only the value <NULL> is allowed for GDCH – thisvalue indicates that the TCHSD works as “shared” TCH, i.e. theTCHSD can be used for CS as well as for GPRS traffic.

If the TCH is created with the parameter combinationCHTYP=TCHSD,CHPOOLTYP=TCHPOOLit can never be used for GPRS traffic. Of course, the same goes for the the parameter combinationCHTYP=TCHSD,CHPOOLTYP=TCHPOOL

MAIO=0,

object: CHAN


default: 0


GSM 04.08

Mobi le al location index offset , determines start position of thechannel in the frequency hopping algorithm. This parameter is sent inthe main DCCH in the IE ‘Channel Description’ (contained e.g. in the

ASSIGNMENT COMMAND) if it was assigned to a used channel. If frequency hopping is enabled the parameter H is set to 1. In this casethe IE also contains the HSN together with the MAIO.

Note:- The MAIO can only be defined in the CHAN object, if the hopping

system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA,for further details see command CREATE CBTS) is not used for theservice layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in theTRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.





(TSC=),

object: CHAN

range: 0..7




GSM 04.08

Training Sequence Code , this optional parameter specifies theTraining Sequence Code of the radio channel. The TSC is part of the‘Normal Bursts’ which are used for all channel types except RACH,SCH and FCCH. The TSC entered here is sent to the MS in the IE ‘Channel Description’ within the ASSIGNMENT COMMAND for theSDCCH. This is necessary for the correct decoding of the SDCCH.The TSC for any type of SDCCH and TCH/SD must correspond to

the BCC (part of the BSIC sent on the SCH, see CREATE BTS[BASICS] parameter BSIC).If no value is entered for the parameter TSC the system automatically selects the BCC (see parameter BSIC (CREATE BTS [BASICS])) asTSC.





Setting the cell specific parameters and threshold values for voice callHandover:

) For detailed information regarding Handover Thresholds please

refer to the chapter Handover Thresholds & Algorithms and Interworking of Handover and Power Control!

SET HAND [BASICS] :

Attention: Since BR6.0 The DBAEM does not group the command

parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘HAND packages’ were moved below the object HAND (now subordinate to the BTS object) and appear in the DBAEM in the SET HAND command. The logical group “[BASICS]” is normally only used on the LMT but was used here to allow a more useful grouping of thecommands .

NAME=BTSM:0/BTS:0/HAND:0,

Object path name .

ADVCMPHOOAMR =6,

object: HAND [BASICS]

unit: 1dB

range: -30.. 30 (dB)

default: 6 (dB)

Advanced compress ion handover of fse t AMR , this parameter isrelated to advanced compression decompression handover (parameter EADVCMPDCMHO, see below) may be used to give

preference to the selection of either AMR or non-AMR calls for acompression handover.

Normally of all calls fulfilling the advanced compression rules the onewith the highest sum of C/I and power reduction level (PL) is being selected (per SACCH multiframe). For an AMR call additionally thevalue of this attribute is being added, i.e. sum of

C/I + PL + ADVCMPHOOAMR

before being compared to the other calls suitable for compression.Therefore positive dB values of this attribute will give preference to

AMR calls (default), negative dB values to non-AMR calls and a 0dBvalue will rate both call types equally.

A change of the attribute becomes effective in the next SACCH multiframe.

ALEVFULHO=2-1,


unit: 1 SACCH multiframe(averaging period)


1-3 (DTX weight. factor)



Handover averaging parameters for fast upl ink hando ver

decision , this attribute defines two averaging parameters for themeasurement process that is used for the fast uplink handover

decision. The first field, aLevFuHo, defines the averaging window size (that is smaller than the normal window size), the second one,wLevFuho, indicates the DTX weighting factor. As the fast uplink handover should react quite quickly to UL level drops, the averaging window should be significantly smaller than that of other handover types (e.g. level handover). The default value of ‘2’ is thereforereasonable.To additionally speed up the fast uplink handover decision, the BTSuses a special algorithm for the UL measurement processing.In case of a normal uplink handover, the BTS cannot make ahandover decision directly after the end of the UL measurement

period, because it has to wait for the next MEASUREMENT REPORT from the MS which contains the ‘DTX used’ flag. This flag determineswhether the BTS must enter the FULL values (if DTX was not used in

the measurement) or the SUB values (if DTX was used in themeasurement period) into the averaging window for the handover decision (for further details about DTX and FULL and SUB values

please refer to the parameter DTXDL in command SET BTS[OPTIONS]).For fast uplink handover, a different approach is used: At the end of the UL measurement period, the BTS directly inserts the SUB valuesinto the averaging window (assuming that DTX was active in themeasurement period) thus allowing a preliminary decision. During

periods with speech transmission (i.e. DTX not used), the SUBvalues have a lower statistic reliability than the FULL values, but testshave shown that they reflect the real radio conditions well enough to





justify a preliminary decision. If the ‘DTX used’ flag, that is received inthe MEASUREMENT REPORT from the MS 480ms later, indicatesthat in the affected measurement period DTX was ‘not used’, the BTSremoves the SUB value from the averaging window and replaces it by the FULL value (the number of FULL values inserted depends onthe DTX weighting factor). This algorithm reduces the handover decision time by one measurement period (480ms) with a minimumimpact on the reliability of the averaged UL RXLEV values.

Also for the averaging of the neighbour cell downlink RXLEV measurements, the approach for fast uplink handover is different from the one of the other handover types: while for all other handover types the size of the averaging window for the neighbour cell downlink RXLEV measurements is determined by the parameter HOAVPWRB (see below), which generally defines a comparatively long averaging period, the averaging window for the neighbour cell measurements for fast uplink handover is

AveragingPeriod FULHO-NC = ALEVFULHO – 1 SACCH multiframe

This approach was chosen, as a very quick handover decision due tofast uplink requires the consideration of the neighbour cells that offer a sufficient DL RXLEV at that particular point of time. This meansthat, if the default value is used (ALEVFULHO=2-1), this means that the suitable neighbour cell for fast uplink handover is derived fromonly one Measurement Report.

AMRACMRDL=5,


unit: 1 CMR

range: 1..31

default: 5

Parameter value range adapted to real

range (1..31) in BR8.0!

Handover averaging parameters for AMR CODEC MODE

REQUESTs , this parameter defines the size of the averaging window for downlink CODEC MODE REQUESTs (CMR) received from theMS during an AMR (Adaptive MultiRate) call. The CMRs arecontinuously sent from the MS to the BTS, even if no change of thecurrent CODEC is required.

When a valid CMR is received, it is entered to the circular buffer (averaging window) for the AMR-CMRs whose size is defined by

AMRACMRDL. Then the average is calculated over the values present in the AMR-DL-averaging window and the average isrounded to the nearest integer value. The rounded average indicatesthe offset of the presently most appropriate CODEC within the ACS.

The purpose of this parameter is to avoid a too frequent changes of the downlink CODEC mode in case of instable or quickly varying radio conditions.

The Periodicity of the CMR sending depends on whether DTX uplink is currently used or not. If DTX uplink is not used, the CMR is sent every second TDMA speech frame (i.e. every 40 ms). If DTX uplink iscontinuously used, the CMR CMR is repeated every 8. TDMA speechframe (i.e. 160ms). If the usage of DTX changes in smaller steps,then the CMR sending period lies between 40ms and 160ms.

Notes:

- Despite the actual selectable value range of 1..63, the actual valuerange that is supported by the BTS is 1..31. In other words, it doesnot make sense to set this parameter to a value greater than 31.- If the BTS is connected to an Abis via satellite link of if the Asub iscreated via satellite link, this attribute should be set to its maximumvalue as a the CODEC mode adaptation process (which is - for thedownlink - executed by the TRAU) is considerably slowed down by the higher transmission delay on the satellite link. As mentioned inthe parameter AMRFRC1 (see CREATE BTS [BASICS]), if the BTSdetects (after averaging) that the MS requests a CODEC modechange in the downlink, the BTS sends a corresponding CODEC MODE COMMAND (CMC) to the TRAU to instruct the TRAU to

perform the switchover to the new mode. Due to the higher delay onthe satellite link, this CMC reaches the TRAU much later than in caseof a terrestrial link. This means that, in case of a small value of





AMRACMRDL and quickly changing radio conditions, the CODEC mode change could be executed at a point of time when the radioconditions, that triggered it, are no longer present. Thus, as theexecution of the CODEC mode change (via CMR and CMC) isslowed down, it also makes sense to slow down the CODEC modechange decision, to avoid a ‘too nervous’ link adaptation reaction incase of quickly changing radio quality conditions.- The averaging mechanism for the uplink AMR CODEC mode

adaptation is independent of AMRACMRDL as the associated averaging mechanisms are hardcoded.- although the parameter AMRACMRDL is included in the SET HANDcommand, it has no relevance for the handover decisions for AMR calls.

CCDIST=FALSE,


range: TRUE, FALSE

default: FALSE

Enable concentr ic cel l distance handover , this flag determineswhether in the concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) the distance should also be taken intoaccount for the intracell handover decision and for the channel assignment decision during call setup.

Attention: this distance criterion, however, is only considered, if the concentric cell is no ‘dualband concentric cell’ (i.e. no concentric cell with mixed frequency bands in the TRXs)!

Note: If CCDIST is set to TRUE then- new calls are set up in the complete area or a handover from inner to complete area is executed if the level conditions defined by the

parameters HORXLVDLO (for call setup) and HORXLVDLI (for handover) are fulfilled or if the MS-BTS distance exceeds thedistance limit according to the principles explained for the parameter HOCCDIST.

- new calls are set up in the inner area or a handover from completeto inner area is executed if the level conditions defined by the

parameter HORXLVDLO are fulfilled an d if the MS-BTS distance issmaller than the distance limit according to the principles explained for the parameter HOCCDIST.

For the parameters HORXLVDLI, HORXLVDLO and HOCCDIST, please see below.

CCELL1=<NULL>,


range: BTSM:<n>/BTS:<n>,

<NULL>

default: <NULL>

Colocated cel l 1 , this parameter is only relevant if the parameter ININHO (see below) is set to TRUE and defines the first of two

possible adjacent sectorized concentric cells (see parameter CONCELL in command CREATE BTS [BASICS]) to which anintercell handover from inner-to-inner area shall be possible, resp. for which the target area (inner or complete) shall be determined by thePREFERRED AREA REQUEST procedure during intercell handover.

The ‘Colocated Cell' (for meaning of the term ‘colocated cell’ pleaserefer to the parameter ININHO, see below) is represented by the pathname of the affected BTS object, e.g. “ BTSM:0/BTS:0”.

Note: The BSC only allows the ‘inner-to-inner’ handover if both theoriginating and target cell of a handover procedure are configured asconcentric cells (CONCELL=TRUE in command CREATE BTS

[BASICS]). This means that only in this case the BSC will start thePREFERRED AREA REQUEST procedure during intre-cell handover. This means that it is up to the operator to enter only object

path names of BTS instances that are really configured correspondingly.

CCELL2=NOT_DEFINED-NOT_DEFINED,


range: BTSM:<n>/BTS:<n>,

<NULL>

default: <NULL>

Colocated cel l 2 , this parameter defines the second of two possibleadjacent sectorized concentric cells suitable for inner-to-inner handover. For more details please see parameter CCELL1.





DISTHO=TRUE,


range: TRUE, FALSE

default: TRUE


Distance Handover enabled , determines whether handover due tolong distance between MS and BTS is enabled.Note: This flag only determines whether inter-cell handovers may beexecuted with cause ‘distance’. It is only relevant if intercell handover is enabled (INTERCH=TRUE, see below).

DPBGTHO=FALSE,


range: TRUE, FALSE

default: FALSE

Dynamic power bud get handover , this parameter determines

whether ‘dynamic power budget’ handover or ‘speed sensi t ive handover ’ is active. This flag is only relevant if power budget handover is enabled (PBGTHO=TRUE.) Speed sensitive handover ise.g. used for micro-/umbrella-cell configurations. An umbrella cell covers the same area as a number of microcells and is normally used as handover target cell in case of microcell congestion or for MSswhich move very fast. Speed sensitive handover shall allow power budget handovers to a microcell if an MS moves slow but shall

prohibit them if the MS moves fast in order to avoid unnecessary signaling load due to repeated handovers (if the MS moves fast it may have left the microcell already when the handover is actually executed). For this reason the power budget handover to a microcell is delayed by a special timer (the microcell is ‘penalized’ as long asthe timer runs). If the handover conditions are still present when the

timer expires the handover is executed. The timer is administered with the parameter HOMDTIME (CREATE ADJC). It is, however, only in effect for a certain neighbour cell if the parameter MICROCELL isalso set to TRUE in addition. The parameters relevant for theadministration of speed sensitive handover are: MICROCELL,HOMDTIME, HOMDOFF and HOMSOFF (see command CREATE

ADJC).





EADVCMPDCMHO=<NULL>,



default: <NULL>

Enable advanced compressio n decompression hando ver , this parameter is used to enable/disable the feature ‘advanced compression/decompression handover’ algorithm which wasintroduced in BR7.0. Originally, compression-decompressionhandover was available only for AMR calls. Moreover, whilecompression handover was triggered due to TCH load conditions inthe serving cell, decompression handover was only triggered due to

radio reasons, i.e. it was triggered to guarantee an acceptable QoSfor the ongoing call in case the radio conditions deteriorate. In BR7.0,the ‘advanced’ option of AMR compression/decompressionhandover, which could be enabled by EADVCMPDCMHO, only consisted of an improved handover decision algorithm that considered level citeria in addition to quality criteria.In BR8.0, the advanced compression / decompression handover wasadditionally enhanced:a) Compression/decompression handover is supported not only for

AMR but also for non-AMR calls (FR, EFR, HR)b) Decompression Handover is also triggered due to the current TCH load in the cell c) For compression and decompression handover that is triggered due to load conditions, a ‘best call selection’ mechanism is

implemented in the BTS which ensures that compression and decompression handover is executed in a one-by-one manner, with- the most suitable call being selected first and - a maximum handover trigger rate of one per 480ms period. In other words, only one handover is triggered at a time and the minimumtime between two consecutive handovers of the same type is 480ms.

These enhancements, however, only apply when, in addition toEADVCMPDCMHO, the parameters EADVCMPHOAMR (for AMR calls) and EADVCMPHOSC (for non-AMR calls) are set to TRUE.

Detailed Description

Compression handover

The purpose of C ompression handover is, in case of high TCH load,to transfer AMR-FR or (E)FR calls with suitably good radio link quality to an AMR -HR or HR TCH by an intracell handover in order to

prevent TCH blocking by providing additional TCH resources. Thecompression handover algorithm is not continuously enabled in theBTS, but is temporarily enabled / disabled by the BSC (by sending the Abis O&M message SET ATTRIBUTE (SATT) to the BTS)depending ona) the current radio TCH load of the cell (see parametersHRACTAMRT1 and HRACTT1 in command CREATE BTS [BASICS])or b) the current Abis pool TCH load of the BTSM (see parameter

ABISHRACTTHR in command CREATE BTSM). In other words: when the BSC detects during its cyclic TCH load check (see parameter TRFCT in command SET BSC[BASICS]) that

- the TCH load in the cell has exceeded the thresholdsHRACTT1(HRACTT2)/HRACTAMRT1(HRACTAMRT2) or/and - the Abis TCH load has exceeded the threshold ABISHRACTTHR,

the BSC enables compression handover for the affected type of calls(AMR/non-AMR) by sending the corresponding SATT message to theBTS.

If enabled by the abovementioned database flags, the BTS checksthe ‘best suitable call’ criteria for this type of compression handover (description see below).

Decompress ion handover Decompression can be triggered in two different scenarios:a) Decompression handover due to radio conditionsb) Decompression handover due to low TCH load in the cell.





a) Decompression handover due to radio conditionsWhen a HR or AMR-HR call suffers from poor radio conditions theBTS triggers a decompression handover from HR to E(FR) or from

AMR-HR AMR-FR in order to improve the speech quality and toguarantee an acceptable QoS.Important: This type of decompression handover is continuously enabled and is completely independent of the current BTS radio TCH load or Abis pool TCH load.

Moreover, the ‘best suitable call’ selection is not performed in thiscase, i.e. for each call for which the appropriate radio conditionsapply, the decompression handover is triggered immediately.

b) Decompression handover due to low TCH load in the cell The purpose of this type of decompression handover is, in case of sufficiently low TCH load, to transfer AMR-HR or HR to an AMR-FR or (E)FR TCH by an intracell handover in order to provide the best

possible speech quality and QoS.This type of decompression handover algorithm is not continuously enabled in the BTS, but is temporarily enabled / disabled by the BSC (by sending the Abis O&M message SET ATTRIBUTE to the BTS)depending ona) the current radio TCH load of the cell (see parametersFRACTAMRTH1 and FRACTTH1 in command CREATE BTS

[BASICS]) or b) the current Abis pool TCH load of the BTSM (see parameters

ABISHRACTAMR and ABISHRACTTHR in command CREATE BTSM).In other words: when the BSC detects that - the TCH load in the cell has dropped below the thresholdsFRACTTH1(FRACTTH2)/FRACTAMRTH1(FRACTAMRTH2) or/and - the Abis TCH load has dropped below the threshold

ABISHRACTTHR,the BSC enables decompression handover for the affected type of calls (AMR/non-AMR) by sending the corresponding SATT messageto the BTS.Only for this type of decompression handover the BTS checks the‘most suitable call’ criteria (description see below).

Please note that the basic compression/decompression handover cannot be disabled by database command (it is, however automatically disabled if HR is generally disabled in the BSC by setting the parameter HRSPEECH to FALSE (see command SET BSC [BASICS]). The parameter EADVCMPDCMHO just allows toswitch between different modes of AMR compression/decompressionhandover (standard or advanced).

Compression/decompress ion handover decis ion

Standard AMR Compression Handover ( EADVCMPDCMHO=FALSE )Setting the flag EADVCMPDCMHO to FALSE simply means that thecompression decompression handover is only triggered for AMR callsand that the AMR compression handover decision is done in the

same way as in BR6.0 , i.e. the AMR compression and decompression handover decision is solely based based on quality (C/I) criteria defined by the parameters HOTHAMRCDL,HOTHAMRCUL, HOTHAMRDDL and HOTHAMRDUL (see below).





Standard AMR Compression hando ver decision cr i ter ia

An AMR compression handover from AMR FR to AMR HR istriggered if for a particular AMR FR if a) the BTS has received the SATT message that enables this type of handover in the BTS and b) for an AMR call the following conditions are fulfilled:

(C/I_UL > HOTHAMRCUL)AND

(C/I_DL > HOTHAMRCDL)

Standard AMR Decomp ression handov er decision cr i ter ia

An AMR de-compression handover from AMR HR to AMR FR istriggered only due to radio conditions (without any enabling SATT message from the BSC) if for a particular AMR HR call the following conditions are fulfilled:

(C/I_UL < HOTHAMRDUL)OR

(C/I_DL < HOTHAMRDDL)

Advanced AMR Compression Handover The advanced compression-decompression handover algorithm isenabled for AMR calls if the database settings

EADVCMPDCMHO=TRUE and EADVCMPHOAMR=TRUE areapplied.

As mentioned above, this setting has several effects:a) it enhances the compression/decompression handover decisionalgorithm by additional consideration of radio level criteriab) it extends the compression/decompression handover with theenhanced decision algorithm also to non-AMR calls (FR, EFR, HR)c) it enables the load-dependent decompression handover decisiond) it enables the ‘best suitable call selection’ mechanism for compression and decompression handover.

a) Enhanced AMR compression/decompression handover decisionalgorithm by level criteria (since BR7.0)The advanced AMR compression/dedcompression handover algorithm additionally considers the current level conditions and the

current dynamic power reduction due to BS and MS power control.This is done by considering an additional level threshold and by comparing the C/I thresholds to a C/I value that was ‘corrected’ by the corrent power reduction.

In this context the new parameters HOTHCMPLVDL,HOTHCMPLVUL, HOTHDCMLVDL and HOTHDCMLVUL (seebelow) are considered.

The AMR compression handover decision is based on the rules listed below:

Adv anced AMR Comp ression handover decision cr i ter ia

An compression handover from AMR FR to AMR HR is triggered if a) the BTS has received the SATT message that enables this type of handover in the BTS and

b) for an AMR call the following conditions are fulfilled {[(RXLEV_UL > HOTHCMPLVUL) AND (C/I_UL >= C/Imax)]

OR (C/I_UL + MS_PWRRED > HOTHAMRCUL)}

AND

{[(RXLEV_DL > HOTHCMPLVDL) AND (C/I_DL >= C/Imax)]OR (C/I_DL + BS_PWRRED > HOTHAMRCDL)}





Adv anced AMR Decompress ion handover decision cr i ter ia A de-compression handover from AMR HR to AMR FR is triggered only due to radio conditions (without any enabling SATT messagefrom the BSC) if for a particular AMR HR call the following conditionsare fulfilled:

{[(RXLEV_UL < HOTHDCMLVUL) OR (C/I_UL < C/Imax)] AND (C/I_UL + MS_PWRRED < HOTHAMRDUL)}

OR

{[(RXLEV_DL < HOTHCMPLVDL) OR (C/I_DL < C/Imax)] AND (C/I_DL + BS_PWRRED < HOTHAMRDDL)}

whereMS_PWRRED = MS power reduction due to MS power control (in dB)BS_PWRRED = BS power reduction due to BS power control (in dB) C/Imax =20dB

Background in format ion on the advanced compress ion

handover con dit ion form ulas and C/Imax In practice the process for the continuous determination of C/I valuesis limited to a maximum hard-coded value C/Imax=20dB. Thislimitation is related to the determination of C/I via measurements of BER and mapping on corresponding C/I values. For high C/I values,the BER is very low and, for a reasonable averaging window length,the accuracy of the resulting C/I is limited. In case that no bit errorshave been measured during the measurement period no precise

prediction of the real C/I is possible at all.

A C/I limited to a maximum C/Imax may reduce the benefit of adding C/I to the current MS/BS_PWRRED (power reduction due to power control) in the transient phase of a call (the ‘transient phase’ is thestart phase of a call in good coverage conditions, when the BS/MS

power is still at the maximum or close to it but is continuously changing due to dynamic power reduction) in the following way:Reaching the compression threshold may be delayed whereas anunlimited C/I measurement would trigger compression immediately.Similarly, decompression threshold may be reached within thetransient phase causing an unjustified decompression handover whereas an unlimited C/I measurement would have prevented this.

To avoid unjust i f ied decompression handover in the transient phase, irrespective of whether C/I was considered in the primary condition or not, the following additional conditions for decompression are therefore taken into account:

1. C/I is smaller than a certain threshold, e.g. C/Imax, or alternatively, averaged RXQUAL is greater than a certainthreshold

2. RXLEV is smaller than a certain threshold.

To avoid delayed com pression handover in the transient phase,irrespective of whether C/I was considered in the primary condition or not, the following additional conditions for compression are taken intoaccount:

1. C/I is equal or greater than hard coded C/Imax, or, alternatively,averaged RXQUAL is equal or smaller than a certain threshold,

2. RXLEV is greater than a certain threshold As an example for a combination of these additional conditions with the primary conditions the following expression shall be used totrigger compression handover (must be fulfilled for both, xx = UL, DL;measurements C/I are different for both links but not marked as suchin the following for the sake of simplicity):

[(RXLEVxx > HOTHCMPLVxx) AND (C/I >= C/Imax)] OR (C/I + MS/BS_PWRRED > HOTHAMRCxx)

Decompression handover is triggered if the sum of C/I and MS/BS_PWRRED (power reduction due to power control) is lower than the decompression handover threshold (see second part of OR





relation).

To avoid unjustified decompression handover during the transient phase (e.g. immediately after compression handover) a further condition has to be fulfilled: C/I has to be lower than C/Imax. Thisavoids that in case of unproper setting of the decompressionhandover threshold, the decompression handover is triggered immediately after allocating the call on the HR channel (PR = 0 and HOTHAMRDxx > 20 dB). An alternative condition to

C/I < C/Imax is

RXLEV_xx < HOTHDCMLVxx

This will avoid that e.g. a MS close to the BTS will perform unjustified decompression handover.

b) Extension of the advanced decision algorithm also for non-AMR callsIn BR8.0, the advanced compression-decompression handover decision algorithm which was introduced in BR7.0 is also applied tonon-AMR calls. The advanced compression-decompressionhandover algorithm is enabled for non-AMR calls if the databasesettings EADVCMPDCMHO=TRUE and EADVCMPHOSC=TRUE are applied.

Adv anced non-AMR Comp ression handover decision cr i ter ia An compression handover from (E)FR to HR is triggered if a) the BTS has received the SATT message that enables this type of handover in the BTS and b) for a non-AMR call the following conditions are fulfilled:

{[(RXLEV_UL > HOTHCMPLVUL) AND (C/I_UL >= C/Imax)]OR (C/I_UL + MS_PWRRED > HOTH(E)FRCUL)}

AND

{[(RXLEV_DL > HOTHCMPLVDL) AND (C/I_DL >= C/Imax)]OR (C/I_DL + BS_PWRRED > HOTH(E)FRCDL)}

Adv anced non-AMR Decompr ession handover decision cr i ter ia A decompression handover from HR to (E)FR is triggered only due to

radio conditions (without any enabling SATT message from the BSC)if for a particular HR call the following conditions are fulfilled:

{[(RXLEV_UL < HOTHDCMLVUL) OR (C/I_UL < C/Imax)] AND (C/I_UL + MS_PWRRED < HOTHHRDUL)}

OR

{[(RXLEV_DL < HOTHCMPLVDL) OR (C/I_DL < C/Imax)] AND (C/I_DL + BS_PWRRED < HOTHHRDDL)}

whereMS_PWRRED = MS power reduction due to MS power control (in dB)BS_PWRRED = BS power reduction due to BS power control (in dB) C/Imax =20dB

c) Load dependent decompression handover

In BR8.0, the decompression handover can also be triggered due tocell load conditions. A compression handover from (E)FR to HR istriggered if a) the BTS has received the SATT message that enables this type of handover in the BTS and b) for a call the following conditions are fulfilled:

(C/I_ULavg + MS_PL – HOTHxxDUL) < HRDCMLIMTH

AND

(C/I_DLavg + BS_PL – HOTHxxDDL) < HRDCMLIMTH

xx = AMR-HR or HR

d) ‘Best suitable call’ selection mechanism

This mechanism is applied for both compression and decompression





handover, however, it is executed only, if the handover was triggered by the BSC due to load reasons.

If the global feature attribute EADVCMPDCMHO is set to TRUE thenout of all AMR and non-AMR calls within a cell that where selected for compression or decompression HO during the length of onemeasurement period (480ms) one call is selected which is best-suited for the respective HO. This happens according to the following rules:

Best cal l select ion for com pression HO

When a call fulfils the abovementioned advanced compressionchecks and if EADVCMPHOAMR is TRUE for an AMR call or EADVCMPHOAMR is TRUE for a non-AMR call then BTS-internally a ‘compression request’ message is sent from theTRX (CU) to the core controller (COBA) containing a combined quality indicator (QI) for UL and DL as follows:

QI = C/I_ULavg + MS_PL + C/I_DLavg + BS_PL (for non-AMR)

QI = C/I_ULavg + MS_PL + C/I_DLavg + BS_PL + ADVCMPHOOAMR (for AMR)

whereMS_PL = current MS Power LevelBS_PL = current BS Power Level

When this message is received in the core controller a timer is

started for the length of a measurement period (480ms). While thetimer is running the QI's of all further incoming compression request messages from other calls within the cell will be compared against that of the currently best-suited call (which at timer start is the first call requesting a compression HO). The call with the higher QI will become (or stay) the best-suited call for compression. If both QI's areidentical then the best-suited call remains unchanged.

When the timer expires a ‘compression ok’ message is sent to theTRX (CU) of the best-suited call which will then initiate an intracell HO request to the BSC. The TRX then performs another check of theabovementioned flags, initiates the sending of the suitableINTRACELL HANDOVER CONDITION INDICATION.This leads to a rate of at maximum 1 compression HO initiation per measurement period (480ms), where the initial compression request

of a call can be at most 480ms delayed (if it is the first call requesting compression and thus starting the 480ms timer on the core to collect all other possible compression requests).

Best cal l select ion for decom pression HO A ‘best call’ selection for decompression HO is only done if a call wasselected for decompression due to load conditions. A decompressionHO due to radio conditions is always triggered immediately!

When a call fulfils the above advanced decompression checks due toload conditions then a ‘decompression request’ message is sent fromthe TRX(CU) to the core controller (COBA) containing a selected quality indicator (QI) of UL or DL for AMR and non-AMR calls asfollows: IF

((C/I_ULavg + MS_PL) <= (C/I_DLavg + BS_PL))

THEN

QI = C/I_ULavg + MS_PL

ELSE QI = C/I_DLavg + BS_PL

In other words: the worst QI of UL or DL is selected.

When this message is received in the core controller a timer isstarted for the length of a measurement period (480ms). While thetimer is running the QI's of all further incoming decompressionrequest messages from other calls within the cell will be compared against that of the currently best-suited call (which at timer start is thefirst call requesting a decompression HO). The call with the lower QI will become (or stay) the best-suited call for decompression. If both





QI's are identical then the best-suited call remains unchanged.

When the timer expires a ‘decompression ok’ message is sent to theTRX (CU) of the best-suited call which will then initiate an intracell HO request to the BSC. The TRX then performs another check of theabovementioned flags, initiates the sending of the suitableINTRACELL HANDOVER CONDITION INDICATION.

This leads to a rate of at maximum 1 initiation of a decompressionHO due to load conditions per measurement period (480ms), wherethe initial decompression request of a call can be at most 480msdelayed (if it is the first call requesting decompression and thusstarting the 480ms timer on the core to collect all other possibledecompression requests).

Necessary decompression HO's of calls due to radio conditions aretriggered independently and asynchronously within the cell (decisionand trigger of these HO's take place solely within the CU).

Notes on averaging

With each new channel activation the channels averaging windowsare initialized and in case of the HO quality averaging windows(parameter HOAVQUAL, see below) they are initialized toRXQUAL=0 (i.e. C/I=20). The point of time of the first AMR compression/decompression handover decision depends on the type

(FR, HR) of activated TCH:1) If a FR TCH is activated the BTS starts checking for decompression only when the HO quality averaging windows for ULand DL are completely filled for the first time (i.e. (HOAVQUAL * 480ms (SACCH-period time) + 480ms (results of first SACCH-period are not entered in averaging windows)), so that in this case theinitialization value does not have any influence (otherwise it might lead to an unjustified compression HO right away).

2) If a HR TCH is activated the radio conditions are checked right away (after omitting the first SACCH-period results) since theaverage quality value is averaged down from perfect quality (RXQUAL=0) to match the real situation (so the initialization value

prevents an early unjustified decompression HO).

As described above, the compression-decompression handover decision algorithm considers the ‘MS power level’ (MS_PL) and BS

power level’ (BS_PL). To avoid unnecessary compression-decompression handovers, both MS_PL and BS_PL are averaged inthe same way as the C/I values, i.e. for the MS and BTS power values the BTS uses an averaging window with the same length likethe one defined for the quality handover averaging window (HOAVQUAL).

Note: To avoid a ping-pong handover from HR to FR and vice versa,which can occur due to subsequent execution of (AMR)decompression handover and intracell handover (parameter INTRACH, see below) due to quality (for a call whose quality is still

poor after decompression handover), the features ‘Cell load dependent actvation of half rate’ (see parameter EHRACT incommand CREATE BTS [BASICS]) and ‘Abis load dependent activation of half rate’ (see parameter ABISHRACTTHR in command CREATE BTSM) are not considered if the BSC receives anINTRACELL HANDOVER CONDITION INDICATION due to quality reasons (cause values ‘uplink quality’ or ‘downlink quality’). Thismeans that the BSC does not check the current BTS TCH load and the BTSM Abis pool TCH load in case of an intracell handover due toquality.





EADVCMPHOAMR=FALSE,


range: TRUE, FALSE

default: FALSE

Enable Advanc ed compressio n Handover for AMR , this parameter is used to enable/disable the selection of AMR calls ascandidates for the most suitable call for a compression handover. If enabled AMR calls that fulfil all (advanced algorithm) compressionconditions will be considered as candidates for an intracell

AFR Æ AHR compression HO. If disabled, no AMR call will beselected for compression handover.


Note: This parameter is only checked during the AMR compressionhandover decision in the BTS - it thus only controls AMR compression handover. AMR Decompression handover due toquality or due to load remains unaffected by this parameter, i.e. evenif EADVCMPHOAMR=FALSE, the BTS will still trigger decompression handovers for AMR calls will still be triggered if thecorresponding conditions are met.

EADVCMPHOSC=FALSE,


range: TRUE, FALSE

default: FALSE

Enable Advanc ed compressio n Handover for speech cal ls (non-

AMR) , this parameter is used to enable/disable the selection of non- AMR speech calls (using standard FR/EFR codecs) as candidates for the most suitable call for a compression handover. If enabled callsthat fulfil all (advanced algorithm) compression conditions will beconsidered as candidates for an intracell (E)FR Æ HR compressionHO. If disabled, no non-AMR speech call will be selected for compression handover.


Note: This parameter is only checked during the non-AMR compression handover decision in the BTS - it thus only controlscompression handover for non-AMR speech calls. Decompressionhandover due to quality or due to load for these calls remainsunaffected by this parameter, i.e. even if EADVCMPHOSC=FALSE,the BTS will still trigger decompression handovers for non-AMR callswill still be triggered if the corresponding conditions are met.

EFULHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable Fast Upl ink handover , this parameter enables the feature

‘Fast Uplink Handover’ (this parameter only relevant if intercell handover is enabled (INTERCH=TRUE, see below). Fast Uplink Handover was introduced in BR6.0 to as an additional fast handover mechanism that is able to prevent call drops that occur due to asudden and drastic drop of the UL receive level. Such level drops canoccur e.g. in urban areas with small cells and obstacles in the radio

path (e.g. buildings). If the level drops too quickly, the standard level handover mechanism is often too slow to ‘rescue’ the call as a thestandard level handover normally uses small but not very small averaging window sizes (normal is 4 SACCH multiframes ≈ 2 sec)and is only triggered after the PWRC control algorithm (if PWRC isenabled) has adjusted the transmit power to the maximum.For this reason the ‘fast uplink handover’ was introduced: Thishandover type uses own averaging windows (see parameter

ALEVFULHO), which should be set shorter than the ones of thestandard level handovers to allow a shorter reaction times, and ownhandover trigger thresholds (THLEVFULHO). Fast uplink handover iscompletely de-coupled from the PWRC algorithm, i.e. fast uplink handover is immediately triggered if the UL receive level drops below the fast uplink handover threshold THLEVFULHO, no matter whether the MS transmit power is already at the maximum or not.

To qualify an adjacent cell as a suitable target cell for fast uplink handover, an additional administrable level offset is considered during the handover decision (see parameter FULRXLVMOFF in the

ADJC object). Moreover, it is possible to priorize specific adjacent cells in the ranking of the target cells by a flag in the ADJC data (see





parameter FULHOC in the ADJC object).


Note: If the BTS transmits a HANDOVER COMMAND for a fast uplink handover to the MS via the Um, it simultaneously increasesthe BS and MS power. This mechanism was implemented to increasethe probability that the message is successfully transmitted and received/acknowledged from the MS side.

ELEVHOM=FALSE,


range: TRUE, FALSE

default: FALSE

Enable level handov er margin , this parameter enables the feature‘level handover margin’. This feature foresees the consideration of anadditional level handover margin for the determination of suitablelevel handover target cells.

For further details, please refer to the parameter LEVHOM (command CREATE/CREATE ADJC) and to the section “Handover Thresholdsand Algorithms” in the appendix of this document.

ELIMITCH=TRUE,


range: TRUE, FALSE

default: TRUE

Enable l imitat ion of int ra-cel l handov er repeti t ion , this flag determines whether the feature 'Limitation of Intracell handover repetition’ is enabled or not. It enables a mechanism that prevents anunlimited repetition of intra-cell handovers due to quality (parameter INTRACH , see below ) and c ompression /decompression (parameter EADVCMPDCMHO, see above ).

a) Limitation of Intracell Handover due to quality In the current implementation the following scenario might happenquite easily: if the flag ELIMITCH is set to FALSE, for consecutiverepeated intra-cell handovers due to quality (triggered for a particular call) the idle TCHs are assigned cyclically without ever triggering aninter-cell HO unless one of the intra-cell HOs is not successful. If IdleChannel Supervision is activated (see command SET BTS [INTERF])the BSC TCH allocation algorithm considers the interference levelsreported via the RF RESOURCE INDICATION messages in addition.

In cells with good level but high interference, however, an inter-cell handover is desired, if intra-cell handovers do not lead to better radioconditions, especially if frequency hopping is used. If the flag ELIMITCH is set to TRUE, a counter implemented in the BSC isincreased on every successful quality intracell HO completion. If thecounter reaches an administrable threshold (see parameter MAIRACHO), the next CHAN ACT message the BSC sends for anintra-cell quality handover contains the GSM08.08 cause 'handover successful'. This message leads to the start of an administrable timer (see parameter TINOIERCHO) in the BTS which suppresses thegeneration of further INTRACELL HANDOVER CONDITION INDICATION messages with cause ‘quality’ as long as the timer runs.If the quality handover conditions persist and another quality handover is to be triggered an inter-cell handover due to quality isattempted (if no suitable neighbour cell is available, the INTERCELLHANDOVER CONDITION INDICATION contains an empty target cell list).

b) Limitation of Intracell Handover due to Compression / Decompression T he same mechanism as described above is also used for c ompression /decompression Handover ( parameter EADVCMPDCMHO, see above). Tests have shown that, if the quality conditions are near to the quality thresholds for compression/decompression handover, a ping-pong betweencompression handover and decompression handover may occur. For the “Limitation Dompression /Decompression Handover Repetition” an own counter is implemented in the BSC, which is increased whenever the BSC executes a compression /decompression handover (i.e. sends a CHANNEL ACTIVATION after receipt of anappropriate INTRACELL HANDOVER CONDITION INDICATION). In





case of decompression HO to fullrate cause the internal counter isincreased for each couple of compression/decompression HOs, i.e.the counter is increased by '1' after one back-and-forth compression-decompression handover FR->HR->FR. If a call is set up on a HR channel, the first decompression handover (HR -> FR) is not takeninto account). If this counter reaches the threshold MAIRACHO (seebelow) due to repeated ping-pong between compression and decompression handover, the next CHAN ACT message the BSC

sends for an intracell decompression handover (activation causeextension ‘decompression’ included in the message) contains theGSM08.08 cause 'handover successful'. This message leads to thestart of the timer (see parameter TINOIERCHO) in the BTS whichsuppresses the generation of further INTRACELL HANDOVER CONDITION INDICATION messages with cause ‘compression’ aslong as the timer runs.

Handover suppression in BTSIn the BTS, the handover suppression mechanism is separately managed for both handover types. In other words, the BTS managestwo separate flags that indicate whether a particular type of intracell handover (quality or compression) is currently prohibited for theruntime of TINOIERCHO. However, only one of the flags can be set at a time. This is due to the fact that in the BTS no ‘call context’ is

known but just the context of the activated channel. When a CHAN ACT message for a particular TCH is received in the BTS whichcontains the cause ‘handover successful’, the BTS starts the timer TINOIERCHO and sets the handover suppression flag for that type of handover for which the CHAN ACTIVATION was received. If in themeantime, another intracell handover due to a cause different fromthe suppressed one was successfully completed, the ‘suppressioncontext’ is lost, as for the BTS a completely new channel context isopened. If e.g. after repeated intracell handovers due to quality theintracell quality handover was suppressed, but during the runtime of TINOIERCHO a decompression handover was executed, the new CHAN ACT for the decompression handover may contain (if the BSC counter for this handover type has reached the MAIRACHO threshold for compression handover) the cause ‘handover successful’ again -

but this time, the BTS will only set the supression flag for compression handovers and will thus prohibit only ‘compressionhandovers’ as long as TINOIERCHO runs. Intracell handovers due toquality are not suppressed in this case.

Note: For quality intracell handover, this feature only works if thequality intra-cell HO is controlled by the BSC (LOTRACH=TRUE).





ENAQUALEVHOM=FALSE,


range: TRUE, FALSE

default: FALSE

Enable level handover margin for qual i ty hando ver , this parameter enables the feature ‘level handover margin for quality handover’ which implies the evaluation of the level differencebetween the serving cell and the neighbour cell during handover dueto ‘UL quality’ or ‘DL quality’ and the comparison of this difference toa configurable handover margin (as known from power budget handover). The idea of the feature is to trigger a handover due to

level only to those cells whose downlink receive level exceeds that of the serving cell by a definable margin value. This means that - if thefeature is activated - in addition to the basic minimum criteria for handovers due to level (UL or DL)

RXLEV_NCELL(n) > RXLEVMIN(n) + max (0,Pa)

the additional requirement

RXLEV_NCELL(n) > RXLEV_DL + QUALLEVHOM(n)

is checked. Only those neighbour cells that fulfil both criteria areregarded as suitable target cells for the level handover and are thusinserted into the target cell list of the of the INTERCELL HANDOVER CONDITION INDICATION sent by the BTS.

For the parameter QUALLEVHOM please refer to the command CREATE ADJC.





EUBCHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS better cel l handover , this parameter represents thedatabase flag to enable or disable ‘better cell’ handover from GSM toUMTS (2G-3G handover). This parameter is only relevant if UMTShandover is generally enabled for this BTS (see parameter EUHO)and if ‘better cell’ handover (also called Power Budget Handover) isenabled in this BTS (see parameter PBGTHO).

Attention: 2G-3G handover from GSM to UMTS FDD due to ‘better

cell’ is only possible if the measurement reporting of the multiRAT mobiles is based on RSCP (level-oriented), i.e. the parameter FDDREPQTY (see command CREATE BTS [BASICS]) must be set to the value RSCP.

Setting this EUBCHO=TRUE simply means that, when ‘power budget handover’ is generally enabled (PBGTHO=TRUE), the BTS will alsoconsider UMTS FDD neighbour cells as possible target cells inaddition to the normal 2G (GSM, DCS, PCS) neighbour cells for

power budget handover decisions. If EUBCHO is set to FALSE, theBTS excludes these 3G cells from the target cell list during the power budget handover decision process, even if they have been created as neighbour cells in the BSC database (see commands CREATE TGTFDD and CREATE ADJC3G).

Of course, different minimum criteria and better cell criteria apply for UMTS FDD neighbour cells than for for GSM 2G neighbour cells:- While for GSM neighbour cells the minimum receive level for handovers is defined by the parameters RXLEVMIN (see command CREATE ADJC), the minimum radio requirements for UMTS FDDneighbour cells are defined by the parameter RXLEVMINC (seecommand CREATE ADJC3G)- While for GSM neighbour cells the better cell criterion for power budget handovers is defined by the parameter HOM (see command CREATE ADJC), the ‘better cell’ radio requirement for UMTS FDDneighbour cells is defined by the parameter HOM defined in object

ADJC3G (see command CREATE ADJC3G). For an accuratecomparison of the current RXLEV value of the serving 2G cell to theRSCP value of the UMTS FDD neighbour cell (see explanations

provided for parameter FDDREPQTY in command CREATE BTS

[BASICS]), the parameter UADJ (see command CREATE ADJC3G)is considered in addition.

UMTS handover due to ‘better cell’ and UMTS handover due to‘sufficient coverage’ (see parameter EUBCHO) cannot be enabled at the same time, i.e. it is up to the operator to decide which type of handover shall be used for a particular cell.

Note: Like for 2G-2G handover, the averaging of the reported RSCP values of the 3G neighbour cells is done on the basis of an averaging window whose length is defined by the parameter HOAVPWRB (seebelow).

EUHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS handover , this parameter represents the databaseflag to generally enable or disable handover from GSM to UMTS (2G-3G handover). Only if EUHO=TRUE the parameters EUBCH (see

above), EUIMPHO and EUSCHO (see below) are relevant.Note: It is important to consider that the BTS only sends theMEASUREMENT INFORMATION messages (that are sent on the DLSACCH and which are the 3G-equivalent to SYSTEM INFORMATION TYPE 5, 5bis and 5ter, as they indicate the 3Gneighbour cells to be monitored by the UE) to the UE only if the flag EUHO is set to TRUE. In other words, the UE can only report 3Gneighbour cells if EUHO was set to TRUE in the cell and the UE wasthus informed via the MEAS INFO messages about the 3Gneighbours to be monitored during an onging call.





EUIMPHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS imperative handover , this parameter represents thedatabase flag to enable or disable ‘imperative’ handover from GSM toUMTS (2G-3G handover). This parameter is only relevant if UMTShandover is generally enabled for this BTS (see parameter EUHO).The term ‘imperative handover’ represents handover types which aretriggered to ‘rescue’ ongoing calls that suffer from bad radioconditions, such as

- handover due to level (handover causes ‘uplink strength’ or ‘downlink strength’, see parameter RXLEVHO)- handover due to quality (handover causes ‘uplink quality’, ‘downlink quality’, see parameter RXQUALHO)- forced handover (handover cause ‘forced’) due to directed retry,

preemption and O&M intervention (see parameters ENFORCHO(SET BSC [BASICS]) and EPRE (SET BTS [OPTIONS])).- handover due to distance (handover cause ‘distance’, see

parameter DISTHO).

EUIMPHO is only relevant if at least one of the listed handover typesis enabled by the abovementioned parameters. Setting EUIMPHO toTRUE simply means that the BTS will also consider UMTS FDDneighbour cells as possible target cells in addition to the normal 2G(GSM, DCS, PCS) neighbour cells for imperative handover decisions.

Which type of imperative handover is considered, exclusively depends on the handover-type-specific settings of theabovementioned database flags resp. parameters. If EUIMPHO is set to FALSE, the BTS excludes these 3G cells from the target cell list during the imperative handover decision process, even if they havebeen created as neighbour cells in the BSC database (seecommands CREATE TGTFDD and CREATE ADJC3G).

Of course, different minimum criteria apply for UMTS FDD neighbour cells than for for GSM 2G neighbour cells.- While for GSM neighbour cells the minimum receive level for handovers is defined by the parameters RXLEVMIN (see command CREATE ADJC), the minimum radio requirements for UMTS FDDneighbour cells are defined by the parameter RXLEVMINC (if FDDREPQTY the (see command CREATE ADJC3G).

- As opposed to GSM 2G internal handovers, an additional minimumcriterion is evaluated for imperative handovers towards UMTS FDDneighbour cells: the minimum radio requirements for UMTS FDDneighbour cells for an imperative handover are defined by the

parameter UMECNO (see command CREATE ADJC3G).

Note: Handover from GSM to UMTS (2G-3G handover) is only supported starting from BR7.0 step2.





EUSCHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS suff ic ient c overage handover , this parameter represents the database flag to enable or disable ‘sufficient coverage’ handover from GSM to UMTS (2G-3G handover). This parameter isonly relevant if UMTS handover is generally enabled for this BTS(see parameter EUHO). As opposed to ‘ UMTS better cell’ handover (see parameter EUBCHO) and ‘UMTS imperative handover’ (see

parameter EUIMPHO), the sufficient coverage handover represents a

new handover type which does not exist for GSM internal handoversand which is only applied for 2G-3G neighbour cell relations. Thusthe parameter EUSCHO explicitly enables this handover type and applies it to all UMTS neighbour cells that were created in the BSC database (see commands CREATE TGTFDD and CREATE

ADJC3G).

‘Sufficient coverage’ handover is triggered, if the DL radio conditionsof a particular 3G UMTS neighbour cell have exceeded configurablethresholds. Which thresholds are relevant, depends on themeasurement reporting method defined by the parameter FDDREPQTY (see command SET BTS [BASICS]):- If FDDREPQTY is set to RSCP (level-oriented measurement reporting based on RSCP), the minimum target cell level requirement is defined by the the parameter USRSCP (see command CREATE

ADJC3G).- If FDDREPQTY is set to ECNO (quality-oriented measurement reporting based on Ec/No), the minimum target cell quality requirement is defined by the the parameter USECNO (seecommand CREATE ADJC3G).

(defined as RSCP – Received Signal Code Power from UMTS,Ec/No – quality related for UMTS cells) have exceeded the threshold defined by

UMTS handover due to ‘better cell’ (see parameter EUBCHO) and UMTS handover due to ‘sufficient coverage’ cannot be enabled at thesame time, i.e. it is up to the operator to decide which type of handover shall be used for a particular cell.

Note: Handover from GSM to UMTS (2G-3G handover) is only

supported starting from BR7.0 step2.EXTCHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable extended cel l handover , determines whether the featureExtended Cell Handover is enabled for this cell. 'Extended cell handover' means an intra-cell handover from near to far (singleTS-to-doubleTS) or from far to near (doubleTS-to-singleTS). This handover is performed on distance criteria determined on the basis of thethreshold HOSTAM and the margin HOMRGTA (see below).Notes:- If an extended cell (CREATE BTS[BASICS]:CELLTYPE=EXTCELL) is the target of an inter-cell HO thehandover will always take place to a 'double' timeslot first as the BTScan only determine the actual MS-BTS distance when the first MSmessages are received. If the MS-BTS distance turns out to be small enough for a 'single' timeslot an intra-cell handover from far to near

('double-to-single') is executed immediately (if enabled).- The intracell handover causes “near to far” (single to double)respectively “far to near” (double to single) do not exist for SDCCH-SDCCH handover as in an extended cell all SDCCHs are alwaysconfigured as double timeslots. In other words, as all SDCCHs areonly in the far area, an SDCCH-SDCCH handover to the near areacan never take place.





HIERC=FALSE,


range: TRUE, FALSE

default: FALSE

Hierarchical Cel l Handover , this flag enables the feature‘hierarchical cell structures’. If it is set to TRUE, this simply meansthat the target cell list generation process in the BTS considers the

priority levels of the serving cell (see parameter PL, only relevant incase of power budget handover and traffic handover) and theneighbour cells (see parameters PLNC and PPLNC in the ADJC object, relevant for all imperative handovers, except fast uplink

handover).HIERF=RANK0,


range: RANK0, RANK1

default: RANK0

Hierarchical c el l ranking f lag , this parameter is used to switchbetween two different ranking methods. This flag is only relevant if intercell handover is enabled (INTERCH=TRUE, see below).

The selectable ranking methods RANK0 and RANK1 are only relevant for imperative handovers (i.e. level, quality and distance)and forced handover (directed retry, see parameter ENFORCHO(SET BSC [BASICS]) ).Possible values:

Rank0 (Ranking Method 0): All adjc. cells where RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)are subdivided into two sublists:The upper sublist consists of all neighbour cells where

PBGT(n) - HO_MARGIN(n) > 0 ,the lower sublist consists of all neighbour cells where

PBGT(n) - HO_MARGIN(n) ≤ 0.Within each sublist the cells are sorted in increasing order of priority Neighbour cells with the same priority are sorted by PBGT(n) - HO_MARGIN(n).

Rank1 (Ranking Method 1): All adjc.cells where RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)are subdivided into two sublists:The upper sublist consists of all neighbour cells whereRXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + levelOffsetNcell,the lower sublist consists of all neighbour cells where

RXLEV_NCELL(n) ≤ RXLEVMIN(n) + Max(0,Pa) + levelOffsetNcell,Within each sublist the cells are sorted in increasing order of priority

Neighbour cells with the same priority are sorted by PBGT(n) - HO_MARGIN(n).

For further details please refer to the section ‘Handover Thresholds & Algorithms’. The term ‘levelOffsetNcell’ represents the parameter LEVONC (CREATE ADJC).

HOAVDIST=8,



=480ms

range: 1-31

default: 8

Handover averaging wind ow for distance handover , this parameter defines the size of the gliding averaging window for thetiming advance measurements used for distance handover. This flag is only relevant if intercell handover due to distance is enabled (DISTHO=TRUE, see above). The distance between BTS and MS isdetermined from the ‘timing advance value’ which is continously measured by the BTS from the propagation time on the radio path.

All measurements for handover pass an averaging algorithm. The

algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate thearithmetic average. The averaging window is called “gliding”, as thewindow works as a queue: when a new measurement is received, theoldest measurement is removed from the window.The parameter HOAVDIST defines the size of the gliding averaging window for the measured timing advance values. The size of theaveraging window determines the number of measurement samples(a new measurement sample is received every 480 ms from theMEASUREMENT REPORTs from the BTS and the MS) over whichthe BTS calculates the arithmetic average. This calculated value isfinally used in the distance handover decision process.





HOAVLEV=8-2,


format: averaging period -



=480ms

(averaging period)


1-3 (DTX weight. factor)default: 8 (averaging period)


Handover averaging parameters for level handover , this parameter defines the size of the gliding averaging window and theDTX weighting factor for the uplink and downlink RXLEV measurements for level handovers. It is only relevant if intercell handover due to level is enabled (RXLEVHO=TRUE, see below).


All measurements for handover pass an averaging algorithm. Thealgorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate thearithmetic average. The averaging window is called “gliding”, as thewindow works as a queue: when a new measurement is received, theoldest measurement is removed from the window.The HOAVLEV “averaging period” defines the size of the gliding averaging window for the measured RXLEV values. The size of theaveraging window determines the number of measurement samples(a new measurement sample is received every 480 ms from theMEASUREMENT REPORTs from the BTS and the MS) over whichthe BTS calculates the arithmetic average. This calculated value isfinally used in the handover decision process.

The DTX weighting factor determines how much more the FULLvalues shall be weighted for radio measurement results measured over a period with voice activity (DTX not active).

Up to BR6.0, the higher weighting was implemented by the multipleinsertion of the FULL measurement sample into the gliding averaging window. In other words, if the DTX weighting factor was set to “2”,FULL measurement samples from measurement periods with inactiveDTX (speech transmitted) were inserted into the averaging window twice, while SUB measurement samples from measurement periodswith active DTX (silence) were inserted into the averaging window only once (for further details about DTX and the meaning of FULLand SUB values please refer to the explanations provided for the

parameter DTXDLFR).

Starting from BR7.0, this approach has been changed:FULL measurement samples values for non-DTX channels no longer entered n-times into the averaging window anymore but every value

will be entered once. In addition, the current weighting factor is stored in parallel under the same offset as shown in the following picture:

Thus the time needed to fill the averaging window will always be thesame (i.e. only dependent on the ‘laveraging period’ portion of the

parameter HOAVLEV). The averaging window total is then calculated by adding up all sample values currently stored in the within theaveraging window while a single sample is added number of ‘weight’

times. Then the total is divided by the ‘weight’ total (i.e. all ‘weight’ values within the averaging window are added up).

Notes:- In the SDCCH phase there are no TCH speech frames. For thisreason only the SUB values (determined from the SACCH frames)are considered for the handover decision which are - as usual -inserted into the averaging window as single values only.- The size of the averaging window does not determine the minimumtime the BTS needs to trigger a level handover at the very beginning of a call, as the BTS can trigger a level handover even if theaveraging window is not yet completely filled with measurement

0 4321 98765 3029

0 4321 00065 00sample

offset

length

max_av_win_size

1 2111 00012 00weight





samples. For each setting of the averaging window size there is afixed defined minimum number of measurement samples that arenecessary for a handover decision.

Window size Minimum no. of Measurement samples0 01 12 23-12 313-20 4

21-31 5 Thus, if this minimum number of measurement samples was received and their averaged value indicates the handover condition withrespect to the configured handover thresholds, the level handover istriggered.- The averaging window size for the neighbour cell DL RXLEV measurements is determined by the parameter HOAVPWRB (seebelow).

HOAVPWRB=8,



=480ms

range: 1-31

default: 8


Handover averaging wind ow for pow er budg et handov er , definesthe size of the size of the averaging window for downlink RXLEV values of the serving cell (considering the current power reduction by the Power Control) for intercell handover due to Power Budget (PBGTHO=TRUE, see below) and intercell handover due to traffic (TRFHOE=TRUE, see below). Moreover, this averaging window is

used for all types of intercell handovers (except for Fast Uplink Handover), as it is used for the averaging of the downlink RXLEV values of the neighbour cells.

All measurements for handover pass an averaging algorithm. Thealgorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate thearithmetic average. The averaging window is called “gliding”, as thewindow works as a queue: when a new measurement is received, theoldest measurement is removed from the window.The parameter HOAVPWRB defines the size of the gliding averaging window for the measured RXLEV values. The size of the averaging window determines the number of measurement samples (a new measurement sample is received every 480 ms from theMEASUREMENT REPORTs from the BTS and the MS) over which

the BTS calculates the arithmetic average. This calculated value isfinally used in the handover decision process for handover due to

power budget and handover due to traffic.

Note: The BTS uses the same averaging window size determined by HOAVPWRB also for the averaging of the neighbour cell DL RXLEV measurements for all other handover types (except Fast Uplink Handover). It is important, however, to point out that for theneighbour cell DL RXLEV measurements HOAVPWRB just determined the maximum window size for averaging. Basically theBTS averages the received DL RXLEV measurement values of eachreported neighbour cell over as many samples as have beenreceived from the MS. If the number of measurement samples for a

particular neighbour cell have reached the value of HOAVPWRB, thefurther averaging is only done over as many samples as determined

by HOAVPWRB.





HOAVQUAL=6-2,


format: averaging period -



=480ms

(averaging period)

range: 1-31 (averaging period)1-3 (DTX weight. factor)



Handover averaging parameters for qual i ty handover , this parameter defines the averaging period and DTX weighting factor for the uplink and downlink RXQUAL measurements.


The settings entered for HOAVQUAL are used for the averaging and DTX weighting for all types of handover decisions that feature an

evaluation of the RXQUAL or C/I values (intercell and intracell handover due to quality, compression/decompression handoversetc.).

All measurements for handover pass an averaging algorithm. Thealgorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate thearithmetic average. The averaging window is called “gliding”, as thewindow works as a queue: when a new measurement is received, theoldest measurement is removed from the window.The HOAVQUAL “averaging period” defines the size of the gliding averaging window for the measured RXQUAL values. The size of theaveraging window determines the number of measurement samples(a new measurement sample is received every 480 ms from theMEASUREMENT REPORTs from the BTS and the MS) over whichthe BTS calculates the arithmetic average. This calculated value isfinally used in the quality handover decision process.

The DTX weighting factor determines how much more the FULLvalues shall be weighted for radio measurement results measured over a period with voice activity (DTX not active). For further information about the management of the DTX weigthing factor

please refer to the explanations provided for the parameter HOAVLEV.

Notes:- In the SDCCH phase there are no TCH speech frames. For thisreason only the SUB values (determined from the SACCH frames)are considered for the handover decision which are - as usual -inserted into the averaging window as single values only.- The size of the averaging window does not determine the minimum

time the BTS needs to trigger a handover at the very beginning of acall, as the BTS can trigger an imperative handover even if theaveraging window is not yet completely filled with measurement samples. For quality handovers, the averaging window is initialized with values RXQUAL=0. If the first samples have been inserted intothe window, the BTS can trigger a quality handover, if the RXQUALaverage exceeds the defined threshold, even if less samples havebeen received than places are foreseen in the averaging window.- The averaging window size for the neighbour cell DL RXLEV measurements is determined by the parameter HOAVPWRB (seebelow).





HOCCDIST=5,


unit: 1 km

range: 0..35

default: 5

Handover conc entr ic cel l distance l imit ; this parameter is only relevant if the parameter CCDIST is set to TRUE (see above) and if the concentric cell is no ‘dualband concentric cell’ (i.e. no concentric cell with mixed frequency bands in the TRXs)! It determines thedistance limit used for the 'distance' intracell handover decision withinthe concentric cell and for the channel assignment decision during call setup.

During the call setup procedure the BSC sends the PREFERRED AREA REQUEST message to the BTS to ask whether the TCH shall be assigned in the inner or complete area of the concentric cell. TheBTS responds with a PREFERRED AREA message stating whicharea is preferred. The decision is made on the basis of HORXLVDLI,HORXLVDLO and optionally also HOCCDIST (see above).

- If MS-BTS-distance < HOCCDIST then new calls will be set up inthe inner area or, if the MS is already served by a TRX of thecomplete area, the call will be handed over to the inner area.

- If MS-BTS-distance > HOCCDIST+1 then new calls will be set up inthe complete area or, if the MS is already served by a TRX of theinner area, the call will be handed over to the complete area.The hysteresis '+1' is automatically applied to avoid handover oscillation if the MS moves very close to the defined distance limit.

Please pay attention to the explanations for CCDIST (see above)!

HOLTHLVDL=10,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 10


Handover lower threshold level downl ink , defines the receivesignal level threshold on the downlink for inter-cell level handover decision. This parameter is only relevant if intercell handover due tolevel is enabled (RXLEVHO=TRUE, see below).

The actual threshold value in [dBm] is calculated as follows:Handover Threshold (dBm) = -110dBm + HOLTHLVDL .The following rule has to be considered:HOLTHLVDL (SET HAND) < LOWTLEVD

< [LOWTLEVD (SET PWRC) + 2 ∗ PWREDSS (SET PWRC)] < UPTLEVD (SET PWRC)


HOLTHLVUL=8,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 8


Handover lower threshold level upl ink , defines the receive signal level threshold on the uplink for inter-cell level handover decision.This parameter is only relevant if intercell handover due to level isenabled (RXLEVHO=TRUE, see below).

The actual threshold value in [dBm] is calculated as follows:Handover Threshold (dBm) = -110dBm + HOLTHLVUL .The following rule has to be considered:HOLTHLVUL (SET HAND) < LOWTLEVU

< [LOWTLEVU (SET PWRC) + 2 ∗ PWREDSS (SET PWRC)] < UPTLEVU (SET PWRC)






HOLTHQAMRDL=8,


unit: 1 dB

range: 0...20

default: 8

Handover lower threshold qual i ty AMR downl ink , this parameter eclipses the threshold HOLTHQUDL in case of an AMR (AdaptiveMulti Rate) call: For AMR calls, an intercell handover due to quality downlink is triggered if the downlink quality drops below the threshold determined by HOLTHQAMRDL. This parameter is only relevant if intercell handover due to quality is enabled (RXQUALHO=TRUE, seebelow).

Attention: Unlike for the parameter HOLTHQUDL, for which thequality values are entered in RXQUAL values (range 0..7), the valuesfor HOLTHQAMRDL are entered in C/I values (carrier/interference in[dB]). The BTSE-internal processing of these values is done in thefollowing way:- Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (0..7) in theMEASUREMENT REPORT messages.- From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter HOAVQUAL. The resulting average RXQUAL value iscalculated with a resolution of two places (digits) after the comma(this is achieved by multiplying the RXQUAL values with 100 beforeaveraging).

- The resulting ‘high-precision’ RXQUAL value is then mapped to aninteger C/I value according to the following table:

RXQUAL C/I RXQUAL C/I

6,88 ... 7 1 3,88 ... 4,12 12

6,63 ... 6,87 2 3,38 ... 3,87 13

6,38 ... 6,62 4 2,88 ... 3,37 14

6,13 ... 6,37 5 2,63 ... 2,87 15

5,88 ... 6,12 6 2,13 ... 2,62 16

5,63 ... 5,87 7 1,63 ... 2,12 17

5,13 ... 5,62 8 1,13 ... 1,62 18

4,88 ... 5,12 9 0,38 ... 1,12 19

4,63 ... 4,87 10 0 ... 0,37 20

4,13 ... 4,62 11


- The integer C/I value is then compared to the threshold determined by HOLTHQUAMRDL. If it drops below the threshold, the BTStriggers an intercell handover due to “downlink quality”.

Notes: In order to achieve a suitable accuracy of the RXQUALaverage value for AMR calls, it is recommended to use a minimumRXQUAL averaging window size of 4 (see parameter HOAVQUAL).





HOLTHQAMRUL=8,


unit: 1 dB

range: 0...20

default: 8

Handover lower threshold qual i ty AMR upl ink , this parameter eclipses the threshold HOLTHQUUL in case of an AMR (AdaptiveMulti Rate) call: For AMR calls, an intercell handover due to quality istriggered if the quality drops below the threshold determined by HOLTHQAMRDL. This parameter is only relevant if intercell handover due to quality is enabled (RXQUALHO=TRUE, see below).

Attention: Unlike for the parameter HOLTHQUDL, for which thequality values are entered in RXQUAL values (range 0..7), the valuesfor HOLTHQAMRDL are entered in C/I values (carrier/interference in[dB]). The BTSE-internal processing of these values is done in thefollowing way:- Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (0..7) in theMEASUREMENT REPORT messages.- From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter HOAVQUAL. The resulting average RXQUAL value iscalculated with a resolution of two places (digits) after the comma(this is achieved by multiplying the RXQUAL values with 100 beforeaveraging).- The resulting ‘high-precision’ RXQUAL value is then mapped to aninteger C/I value according to the mapping table included in the

parameter description of HOLTHQAMRDL (see above).- The integer C/I value is then compared to the threshold determined by HOLTHQUAMRUL. If it drops below the threshold, the BTStriggers an intercell handover due to “uplink quality”.

Note: In order to achieve a suitable accuracy of the RXQUALaverage value for AMR calls, it is recommended to use a minimumRXQUAL averaging window size of 4 (see parameter HOAVQUAL).

HOLTHQUDL=5,


range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%2 = 0,4% to 0,8%

3 = 0,8% to 1,6%

4 = 1,6% to 3,2%

5 = 3,2% to 6,4%

6 = 6,4% to 12,8%


default: 5


Handover lower threshold qual i ty downl ink , defines the receivesignal quality threshold on the downlink for inter-cell quality handover decision. This parameter is only relevant if intercell handover due toquality is enabled (RXQUALHO=TRUE, see below).

The following rule has to be considered:

HOLTHQUDL (SET HAND) > LOWTQUAD (SET PWRC)> UPTQUAD (SET PWRC)






HOLTHQUUL=5,


range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%

2 = 0,4% to 0,8%

3 = 0,8% to 1,6%

4 = 1,6% to 3,2%5 = 3,2% to 6,4%

6 = 6,4% to 12,8%


default: 5


Handover lower threshold qual i ty upl ink , defines the receivesignal quality threshold on the uplink for inter-cell quality handover decision. This parameter is only relevant if intercell handover due toquality is enabled (RXQUALHO=TRUE, see below).

The following rule has to be considered:HOLTHQUUL (SET HAND) > LOWTQUAU (SET PWRC)> UPTQUAU (SET PWRC)


HOMRGTA=4,


unit: 1km

range: 0..34

default: 4

Handover margin for t iming advance , this parameter specifies thetiming advance margin for the extended cell handover (see

parameter EXTCHO). It is applied to the MS-BTS distance threshold for the maximum MS distance (see parameter HOMSTAM) in thefollowing way:

- An extended cell handover from near to far (singleTS-to-doubleTS)is executed if MS-BTS distance = HOMSTAM

- An extended cell handover from far to near (doubleTS-to-singleTS)

is executed if MS-BTS distance = HOMSTAM-HOMRGTAHOMSTAM=32,


unit: 1km

range: 0..34

default: 32

Thresho ld for the m aximum MS distance , this parameter is only relevant for extended cells (see parameter CELLTYPE in command CREATE/SET BTS [BASICS]). It specifies the maximum allowed MS-BTS distance for the use of a 'not extended' radio channel (i.e. a‘single’ TCH, see parameter EXTMODE (CREATE CHAN)). If theMS-BTS distance determined during call setup is below this threshold the call is set up on a 'single' timeslot - if it is above the threshold thecall is set up on a 'extended' TCH (also called ‘double’ timeslot).

The threshold HOMSTAM is also used for intracell handover decisions for extended cell handovers (see parameter EXTCHO incommand SET HAND [BASICS]) between the areas (far-to-near or near-to-far handovers). To avoid ping-pong handovers an additional margin (parameter HOMRGTA, see above) is applied to this

threshold.Rule: HOMSTAM < HOTMSRME (HAND) < EXCDIST (BTS[options])

HORXLVDLI=22,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 26

RXLEV threshold dow nl ink inner , this parameter defines thedownlink receive level threshold in the inner area of a concentric cell (see parameter CCELL in command CREATE BTS [BASICS]). Itstransition causes an in tracel l handover from the inner area the

com plete area .

Intracell Handover: If the MS is served by the TRX of the inner area,the MS will be handed over to the complete area TRX if the condition

RXLEV_DL < HORXLVDLI

is fulfilled. Optionally, the handover decision can also be based onthe distance criteria defined by the parameter HOCCDIST (see

parameters CCDIST and HOCCDIST).

Rules:for configuration rules for concentric cells and dualband concentric cells please refer to the parameter description of HORXLVDLO (seebelow).





HORXLVDLO=42,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...62 = -48dBm


default: 32

RXLEV threshold dow nl ink outer , this parameter defines thedownlink receive level threshold in the complete area of a concentric cell (see parameter CCELL in command CREATE BTS [BASICS]). Itstransition causes a cal l setup in th e inner area or an in tracel l

handover from the com plete area to the inner area .

Call Setup: During the call setup procedure the BSC sends thePREFERRED AREA REQUEST message to the BTS to ask whether the TCH shall be assigned in the inner or complete area of theconcentric cell. The BTS responds with a PREFERRED AREAmessage stating which area is preferred. The decision is made onthe basis of HORXLVDLO and HOCCDIST (see parameter CCDIST).

If RXLEV_DL > HORXLVDLO the call is set up in the inner area.

If RXLEV_DL < HORXLVDLO the call is set up in the complete area.

Intracell Handover: If the MS is served by the TRX of the completearea, the MS will be handed over to the inner area TRX if thecondition

RXLEV_DL > HORXLVDLO

is fulfilled. Optionally, the handover decision can also be based onthe distance criteria defined by the parameter HOCCDIST (see

parameters CCDIST and HOCCDIST).Special Case: If in the cell the feature “ dualband concentric cell “ withGSM 900/1800 or 850/1900 Dual Band Operation is configured , thecall setup and intracell handover decision considers the difference inthe maximum allowed transmission power (derived from the

parameters MSTXPMAXGSM, MSTXPMAXDCS and MSTXPMAXPCS, see CREATE BTS [BASICS]) and the MS power capability in the band used for the inner area.

This means that a call is set up in the inner area, if the condition

RXLEV_DL > HORXLVDLO + Max[0, (MS_TXPWR_MAXINN - PINN)]

is fulfilled. The decision for an complete-to-inner intracell handover isbased on exactly the same calculation, i.e. a complete-to-innet handover is triggered if the condition

RXLEV_DLCOMPL > HORXLVDLO + Max[0, (MS_TXPWR_MAXINN - PINN)]

is fulfilled.

Rules:- To avoid 'ping pong' handovers between inner and complete areathe following rule should be followed:

HORXLVDLO - HORXLVDLI > (PWRREDinner - PWRREDcomplete) + HOM [dB]

where

HOM = margin to avoid ping-pong HO due to fading,suggested value = default value of parameter HOM (ADJC object)

This rule is relevant for single-band concentric cells, as in suchconfigurations the coverage difference between inner and completearea is controlled by the PWRRED parameter (see command CREATE TRX). The additional margin must be applied as a kind of

‘hysteresis’ which avoids ping-pong handovers due to fading effects,i.e. handovers that might occur due to normal level variations evenwhen the subscriber remains in a stationary position on the border between inner and complete area. It is not necessary to use thedefault value of HOM (power budget handover margin, see command SET ADJC) for this calculation, but it makes sense to assume theHOM default value as a suitable default setting.

- If a cell is configured for two different frequency bands as ‘dual band concentric cells’ (refer to parameters CELLTYP and CONCELL,see above) the coverage difference is rather determined by thedifferent transmission power values of the used CU PA modules and the different propagation attenuation in different frequency bands





than by different values of static power reduction of the TRXs. In thiscase the rule should be expressed as follows:

HORXLVDLO - HORXLVDLI > BS_TXPWR_MAXCOMPL - BS_TXPWR_MAXINN

+ HOM + PLD [dB]

where

BS_TXPWR_MAXCOMPL = Maximum BS transmission power of complete areaTRX at the antenna output

BS_TXPWR_MAXINN = Maximum BS transmission power of inner area

TRX at the antenna output

HOM = margin to avoid ping-pong HO due to fading,suggested value = default value of parameter HOM (ADJC object)

PLD = Path Loss Difference

The additional margin must be applied as a kind of ‘hysteresis’ whichavoids ping-pong handovers due to fading effects, i.e. handovers that might occur due to normal level variations even when the subscriber remains in a stationary position on the border between inner and complete area. It is not necessary to use the default value of HOM (power budget handover margin, see command SET ADJC) for thiscalculation, but it makes sense to assume the HOM default value asa suitable default setting.The Path Loss Difference (PLD) is the difference in the radio

propagation attenuation between the different used frequency bands(e.g. GSM900 and DCS1800). This value must be known to theoperator from live network measurements.

For dualband cells, the rule of thumb

HORXLVDLO - HORXLVDLI >= 20dB

has turned out to work fine without any ping-pong effects betweeninner and complete area.

Notes:- HORXLVDLO is also evaluated during also evaluated during inter-cell handover between colocated concentric cells. For further details,

please refer to the explanations provided for parameter ININHO (seebelow).- The intracell handover causes “complete to inner” and “inner tocomplete” do not exist for SDCCH-SDCCH handover as in a

Concentric Cell all SDCCHs are always configured in the completearea. In other words, as all SDCCHs are only in the complete area,an SDCCH-SDCCH handover to the inner area can never take place.

HOTDLINT=35,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 35


Handover threshold level downl ink intra , this parameter definesthe receive signal level threshold in the downlink for the quality intra-cell handover decision. It is only relevant if intracell handover due toquality is enabled (INTRACH=TRUE, see below).The actual threshold value in [dBm] is calculated as follows:Handover Threshold [dBm] = -110dBm + HOTDLINT .


UPTLEVD > HOTDLINT

For further details please refer to the section ‘Handover Thresholds

and Algorithms’ in the appendix of this document.





HOTHAMRCDL=18,


unit: 1 dB

range: 0... 20

default: 18

Value range and Default value changed

in BR8.0!

Handover thresho ld AMR com press ion downl ink , this parameter represents the downlink quality threshold used to trigger an intracell

AMR Compression Handover "fullrate to halfrate”.

From BR7.0 on the AMR compression and decompression handover decision can be based on both quality and level conditions. The exact conditions for the initiation of an AMR compression and decompression handover as well as references to the quality related

parameters are contained in the description for the parameter EADVCMPDCMHO (see above).

Important: In contrast to the AMR de compression handover (see parameter HOTHAMRDDL), the AMR compression handover (AMR fullrate to AMR halfrate) is triggered only if both the thresholds for ULquality an d DL quality (HOTHAMRCDL and HOTHAMRCUL, seebelow) are exceeded.

Attention: Like for other AMR quality handover parameters (such asHOLTHQAMRDL), the values for HOLTHQAMRDL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way:- Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (0..7) in the

MEASUREMENT REPORT messages.- From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter HOAVQUAL. The resulting average RXQUAL value iscalculated with a resolution of two places (digits) after the comma(this is achieved by multiplying the RXQUAL values with 100 beforeaveraging).- The resulting ‘high-precision’ RXQUAL value is then mapped to aninteger C/I value according to the table included in the parameter description of HOLTHQAMRDL (see above).- The integer C/I value is then compared to the threshold determined by HOTHAMRCDL. If it exceeds the threshold (and HOTHAMRCULis exceeded, too!), the BTS triggers an intracell handover due to

AMR compression.

Notes: In order to achieve a suitable accuracy of the RXQUALaverage value for AMR calls, it is recommended to use a minimumRXQUAL averaging window size of 4 (see parameter HOAVQUAL).





HOTHAMRCUL=18,


unit: 1 dB

range: 0...20

default: 18

Value range and Default value changedin BR8.0!

Handover thresho ld AMR c ompress ion up l ink , this parameter represents the uplink quality threshold used to trigger an intracell

AMR Compression Handover "fullrate to halfrate”.



Important: In contrast to the AMR de compression handover (see parameter HOTHAMRDDL), the AMR compression handover (AMR fullrate to AMR halfrate) is triggered only if both the thresholds for ULquality an d DL quality (HOTHAMRCDL and HOTHAMRCUL) areexceeded.

For further important details please refer to the description of HOTHAMRCUL (see above)!

HOTHAMRDDL=13,


unit: 1 dB

range: 0...20default: 13


in BR8.0!

Handover thresho ld AMR d ecompress ion downl ink , this parameter represents the downlink quality threshold (as C/I value indB) used to trigger an intracell AMR Decompression Handover "halfrate to fullrate".



Important: In contrast to the intracell AMR compression handover (see parameter HOTHAMRCDL), the Intracell AMR decompressionhandover "halfrate to fullrate" is triggered if either the UL quality drops below the threshold HOTHAMRDDL or the DL quality dropsbelow the threshold HOTHAMRDUL.

Attention: Like for other AMR quality handover parameters (such asHOLTHQAMRDL), the values for HOLTHQAMRDL are entered in C/I

values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way:- Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (0..7) in theMEASUREMENT REPORT messages.- From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter HOAVQUAL. The resulting average RXQUAL value iscalculated with a resolution of two places (digits) after the comma(this is achieved by multiplying the RXQUAL values with 100 beforeaveraging).- The resulting ‘high-precision’ RXQUAL value is then mapped to aninteger C/I value according to the table included in the parameter description of HOLTHQAMRDL (see above).- The integer C/I value is then compared to the threshold determined by HOTHAMRDDL. If it drops below the threshold HOTHAMRDDL,the BTS triggers an intracell handover due to AMR decompression.

Notes:- Although the total value range of HOTHAMRCDL is 0..30, themapping limits the maximum useful C/I value to 20dB (see mapping table shown for HOLTHQAMRDL). C/I threshold values above 20dBtherefore can never be reached and will not show any effect.- In order to achieve a suitable accuracy of the RXQUAL averagevalue for AMR calls, it is recommended to use a minimum RXQUALaveraging window size of 4 (see parameter HOAVQUAL).





HOTHAMRDUL=13,


unit: 1 dB

range: 0...20

default: 13


in BR8.0!

Handover thresho ld A MR decompress ion up l ink , this parameter represents the uplink quality threshold (as C/I value in dB) used totrigger an intracell AMR Decompression Handover "halfrate tofullrate".



Important: In contrast to the intracell AMR compression handover,the Intracell AMR decompression handover "halfrate to fullrate" istriggered if either the UL quality drops below the threshold HOTHAMRDDL or the DL quality drops below the threshold HOTHAMRDUL.

For further important details please refer to the description of HOTHAMRDDL (see above)!

HOTHCMPLVDL=<NULL>,


unit: 1 dB

range: 0...63

default: <NULL>

initial value: 40 (-70dBm)

Handover thresho ld for com press ion downl ink , this parameter isonly relevant if the feature ‘advanced AMR compression / decompression handover’ (parameter EADVCMPDCMHO, seeabove) is enabled and defines the compression threshold for the DL

receive level; i.e. in order for a compression from FR to HR to betriggered the condition

DL_RXLEV > HOTHCMPLVDL

must be fulfilled (as well as the respective condition for the UL and the quality conditions).

Please note that From BR7.0 on the AMR compression and decompression handover decision can be based on both quality and level conditions. The exact conditions for the initiation of an AMR compression and decompression handover as well as references tothe quality related parameters are contained in the description for the

parameter EADVCMPDCMHO (see above).

HOTHCMPLVUL=<NULL>,

object: HAND [BASICS]unit: 1 dB

range: 0...63

default: <NULL>

initial value: 40 (-70dBm)

Handover thresho ld for c ompress ion up l ink , this parameter isonly relevant if the feature ‘advanced AMR compression /

decompression handover’ (parameter EADVCMPDCMHO, seeabove) is enabled and defines the compression threshold for the ULreceive level; i.e. in order for a compression from FR to HR to betriggered the condition

UL_RXLEV > HOTHCMPLVUL

must be fulfilled (as well as the respective condition for the DL and the quality conditions).







HOTHDCMLVDL=<NULL>,


unit: 1 dB

range: 0...63

default: <NULL>

initial value: 26 (-84Bm)

Handover thresho ld for decompress ion downl ink , this parameter is only relevant if the feature ‘advanced AMR compression / decompression handover’ (parameter EADVCMPDCMHO, seeabove) is enabled and defines the decompression threshold for theDL level; i.e. in order for a decompression from HR to FR to betriggered the condition

DL_RXLEV < HOTHDCMLVDL

must be fulfilled (together with defined DL quality conditions).

Please note that from BR7.0 on the AMR compression and decompression handover decision can be based on both quality and level conditions. The exact conditions for the initiation of an AMR compression and decompression handover as well as references tothe quality related parameters are contained in the description for the


HOTHDCMLVUL=<NULL>,


unit: 1 dB

range: 0...63

default: <NULL>

initial value: 26 (-84Bm)

Handover thresho ld for decompress ion up l ink , this parameter isonly relevant if the feature ‘advanced AMR compression / decompression handover’ (parameter EADVCMPDCMHO, seeabove) is enabled and defines the decompression threshold for theUL level; i.e. in order for a decompression from HR to FR to betriggered the condition

UL_RXLEV < HOTHDCMLVUL

must be fulfilled (together with defined UL quality conditions).



HOTHEFRCDL=18,


unit: 1 dB

range: 0...20

default: 18

Handover thresho ld EFR com press ion downl ink , this parameter is used for detecting a compression Handover "Enhanced Fullrate toHalfrate" in order to use the resources more efficiently. The handover EFR Æ HR is triggered only if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see

above), all condition checks for UL- and DL-quality (HOTHEFRCDL,HOTHEFRCUL) and UL- and DL-level (HOTHCMPLVDL,HOTHCMPLVUL) signal a possible compression and if the respectivecall was selected as best suitable within the cell (EADVCMPHOSC and ADVCMPHOOAMR).For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below.


HOTHEFRCDL=18,


unit: 1 dB

range: 0...20

default: 18

Handover thresho ld EFR com press ion downl ink , this parameter is used for detecting a compression Handover "Enhanced Fullrate toHalfrate" in order to use the resources more efficiently. The handover EFR Æ HR is triggered only if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see

above), all condition checks for UL- and DL-quality (HOTHEFRCDL,HOTHEFRCUL) and UL- and DL-level (HOTHCMPLVDL,HOTHCMPLVUL) signal a possible compression and if the respectivecall was selected as best suitable within the cell (EADVCMPHOSC and ADVCMPHOOAMR).For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below.






HOTHFRCDL=18,


unit: 1 dB

range: 0...20

default: 18

Handover thresho ld FR com press ion downl ink , this parameter isused for detecting a compression Handover "Fullrate to Halfrate" inorder to use the resources more efficiently. The handover FR Æ HR istriggered only if the advanced compression/decompression algorithmis enabled (EADVCMPDCMHO, see above), all condition checks for UL- and DL-quality (HOTHFRCDL, HOTHFRCUL) and UL- and DL-level (HOTHCMPLVDL, HOTHCMPLVUL) signal a possiblecompression and if the respective call was selected as best suitable

within the cell (EADVCMPHOSC and ADVCMPHOOAMR).For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below.


HOTHFRCUL=18,


unit: 1 dB

range: 0...20

default: 18

Handover threshold FR com pression upl ink , this parameter isused for detecting a compression Handover "Fullrate to Halfrate" inorder to use the resources more efficiently. The handover FR Æ HR istriggered only if the advanced compression/decompression algorithmis enabled (EADVCMPDCMHO, see above), all condition checks for UL- and DL-quality (HOTHFRCDL, HOTHFRCUL) and UL- and DL-level (HOTHCMPLVDL, HOTHCMPLVUL) signal a possiblecompression and if the respective call was selected as best suitablewithin the cell (EADVCMPHOSC and ADVCMPHOOAMR).

For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below.


HOTHHRDDL =13,


unit: 1 dB

range: 0...20

default: 13

Handover thresho ld FR decompress ion downl ink , this parameter is used attribute is used for detecting a decompression Handover "Halfrate to (Enhanced) Fullrate" in order to provide better speechquality. The handover HR Æ (E)FR is triggered if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see above), and either any of the conditionchecks for UL- and DL-quality (HOTHHRDDL, HOTHHRDUL) and UL- and DL-level (HOTHDCMLVDL, HOTHDCMLVUL) signal anecessary decompression (For the mentioned parameters pleaserefer to descriptions provided in this command (SET HAND [BASICS]

above or below) or a low load condition exists (FRACTTHR1,FRACTTHR2) and the respective call was selected as best suitablewithin the cell (HRDCMLIMTH).


Note: A decompression HO of HR to EFR is preferred. If the MS isnot capable of EFR or EFR is not possible in the target cell then aHO HR to FR shall be executed.





HOTHHRDUL =13,


unit: 1 dB

range: 0...20

default: 13

Handover threshold FR decom pression upl ink , this parameter isused attribute is used for detecting a decompression Handover "Halfrate to (Enhanced) Fullrate" in order to provide better speechquality. The handover HR Æ (E)FR is triggered if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see above), and either any of the conditionchecks for UL- and DL-quality (HOTHHRDDL, HOTHHRDUL) and

UL- and DL-level (HOTHDCMLVDL, HOTHDCMLVUL) signal anecessary decompression (For the mentioned parameters pleaserefer to descriptions provided in this command (SET HAND [BASICS] above or below) or a low load condition exists (FRACTTHR1,FRACTTHR2) and the respective call was selected as best suitablewithin the cell (HRDCMLIMTH).


Note: A decompression HO of HR to EFR is preferred. If the MS isnot capable of EFR or EFR is not possible in the target cell then aHO HR to FR shall be executed.

HOTMSRM=34,


unit: 1km

range: 0..35

default: 34


Handover threshold MS range maxim um , defines the threshold for the maximum permitted distance between MS and the BTS in 1kmstep size which is used for intercell handover due to distance. It isonly relevant if intercell handover due to distance is enabled (DISTHO=TRUE, see above). The BTS calculates the distancebetween MS and BTS from the delay of the RACH burst (which isused for the CHANNEL REQUEST and the HANDOVER ACCESS)and the the delay of the normal bursts. If the determined distanceexceeds the entered threshold value an inter-cell handover withcause ‘distance’ is initiated. In case of an extended channel (doubletimeslot of an extended cell, see CELLTYPE=EXTCELL in CREATE BTS [BASICS]) the handover threshold MS range maximum isdetermined by the parameter HOTMSRME (HAND).

Rule: HOTMSRM (HAND) < EXCDIST (BTS [OPTIONS])

HOTMSRME=99,

object: HAND [BASICS]unit: 1km

range: 35-100

default: 99

Handover threshold MS range maxim um extended , this parameter replaces the parameter HOTMSRM (see above) in case of an

extended channel (double timeslot of an extended cell, seeCELLTYPE=EXTCELL in CREATE BTS [BASICS]). It is only relevant if distance handover is enabled (DISTHO=TRUE, see above) and specifies the handover threshold range maximum that is used for intercell handover due to distance in extended cells. If the BS-BTSdistance exceeds this threshold an inter-cell handover due todistance is executed.

Rule: HOMSTAM (HAND) < HOTMSRME < EXCDIST (BTS[OPTIONS])

HOTULINT=35,


unit: 1 dB

range: 0..63

0 = less than -110dBm1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 35


Handover threshold level upl ink intra , this parameter defines thereceive signal level threshold in the uplink for the quality intra-cell handover decision. It is only relevant if intracell handover due toquality is enabled (INTRACH=TRUE, see below) and defines thereceive signal level threshold on the uplink for intra-cell handover

decision.The actual threshold value in [dBm] is calculated as follows:Handover Threshold [dBm] = -110dBm + HOTULINT .


UPTLEVU > HOTULINT






HRDCMLIMTH=6,


unit: 1 dB

range: 0...100 (dB)

default: 6 (dB)

Half Rate decompressio n l imitat ion threshold , this parameter isonly relevant if the advanced compression / decompression algorithmis enabled (EADVCMPDCMHO, see above) and is used to limit thenumber of decompression handovers due to low load conditions tothose of low quality. Under low load conditions a call might beselected for a decompression handover HR/AHR Æ (E)FR/AFR, if thesum of its C/I and the power reduction level (PL) minus the threshold

HOTHxxCyy (xx=HR or AMR, yy=DL or UL) is below this attributesvalue; i.e.

C/I + PL – HOTHxxDyy < HRDCMLIMTH


For the relevant parameters HOTHAMRCDL, HOTHAMRCDL,HOTHHRCDL and HOTHHRCUL please see descriptions above.

Notes: Decompression handovers due to bad radio conditions are not affected by this attribute.

IERCHOSDCCH=FALSE,


range: TRUE, FALSE

default: FALSE

Inter-cel l handov er for SDCCH , this parameter determines whether inter-cell SDCCH-SDCCH handover is enabled or not.

Notes:- Setting this parameter to ‘enable’ only activates the SDCCH-

SDCCH handover controlled by the BSC, i.e. SDCCH-SDCCH handover to target cells belonging to the same BSC. If Inter-BSC Directed Retry shall be enabled the flag EISDCCHHO (see SET BSC [BASICS]) has to be set to ENABLE in addition.- Only if this parameter is set to TRUE, the settings of the flagsRXQUALHO, RXLEVHO, DISTHO, PBGTHO, ININHO and EFULHOare considered for SDCCH handover. These flags determine whichkinds of SDCCH-SDCCH inter-cell Handover are actually allowed.





ININHO=TRUE,


range: TRUE, FALSE

default: TRUE


Inner-inner h andover , this flag determines whether an intercell handover from inner to inner area in sectorized concentric cells isenabled. This parameter is only relevant in concentric cells (see

parameter CONCELL in command CREATE BTS [BASICS].

Under normal conditions (i.e. with ININHO=FALSE) any incoming handover to a concentric cell is always executed to a TCH belonging to the complete area, even if the level and distance conditions allow an assignment of a TCH belonging to the inner area of the target cell.In this case the inter-cell handover to the complete area of the target cell is directly followed by a complete-to-inner intracell handover within the target cell. If ININHO is set to TRUE these unnecessary handovers are avoided between colocated concentric cells as

described below. Which cells are to be considered as 'colocated' (i.e.for which neighbour cells the ININHO flag will be in effect) isdetermined by the parameters CCELL1 and CCELL2 (see above).

Principle: If the BTS triggers an inter-cell handover out of aconcentric cell towards a target cell which the BSC recognizes as'colocated' (see parameters CCELL1 and CCELL2), the BSC sends aPREFERRED AREA REQUEST message to the originating BTSwhich contains, among other parameters, the level threshold HORXLVDLO (see above) of the affected target cell. Based on thisthreshold and the measured RXLEV value of the target cell the BTSanswers with a PREFERRED AREA message which suggests either a 'complete' area TCH or an 'inner' area TCH. If the BTS suggests aninner area TCH in the PREFERRED AREA message, the BSC directly activates the target TCH on an inner area TRX (if available)

and sends the corresponding TCH info to the MS in the HANDOVER COMMAND.

In fact, when ININHO is set to TRUE, not only inner-to-inner handovers are possible, but also handovers from the complete areain the originating sector to the inner area of the target sector. Theenabling of the flag ININHO simply activates the PREFERRED AREAREQUEST procedure (towards the originating cell) for all intercell handovers for the neighbour cell relations defined by CCELL1 and CCELL2. Even if the call is currently served by a complete area TRX in the serving cell, the BSC will start the PREFERRED AREAREQUEST procedure towards the originating cell when an intercell handover is triggered. If the return message PREFERRED AREAmessage suggests the inner area, the handover is performed to acorresponding inner area TRX in the target cell.

Note: The BSC only allows the ‘to-inner’ handover if both theoriginating and target cell of a handover procedure are configured asconcentric cells (CONCELL=TRUE in command CREATE BTS[BASICS]). This means that only in this case the BSC will start thePREFERRED AREA REQUEST procedure during intre-cell handover. This means that it is up to the operator to enter only object

path names of BTS instances that are really configured correspondingly.

comp lete area

inner area inner-to-

inner

sector 2

(colocated cell 1)

sector 3

(colocated cell 2) sector 1

(own cel l )





INTERCH=TRUE,


range: TRUE, FALSE

default: TRUE

Internal inter-cell Hando ver enabled , determines whether inter-cell handovers for TCH (i.e. HOs starting from a TCH) are generally allowed for this BTS.Notes:- Only if this parameter is set to TRUE, the settings of the flagsRXQUALHO, RXLEVHO, DISTHO, PBGTHO, ININHO, EFULHO and TRFHOE considered for TCH handover. These flags determine

which kinds of TCH-TCH inter-cell Handover are actually allowed.- If an extended cell (CREATE BTS[BASICS]:CELLTYPE=EXTCELL) is the target of an inter-cell HO thehandover will always take place to a 'double' timeslot first as the BTScan only determine the actual MS-BTS distance when the first MSmessages are received. If the MS-BTS distance turns out to be short enough for a 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled).

INTRACH=TRUE,


range: TRUE, FALSE

default: TRUE

Internal intra-cell Hando ver enabled , determines whether intra-cell handovers due to quality shall be allowed this BTS. If this is the case,under defined quality and level conditions (see section handover algorithms) the handover algorithm always executes intra-cell ‘quality’ handovers before Inter-cell ‘quality’ handovers are attempted. TheseIntra-cell handovers are independent of the status of RXQUALHO,

which only refers to inter-cell handovers. If INTRACH is set to FALSE the quality conditions which normally cause an intra-cell ‘quality’ handover in the first place directly lead to an inter-cell ‘quality’ handover (provided that RXQUALHO is set to TRUE). Further

parameters relevant for this type of handover are HOAVQUAL,HOTDLINT and HOTULINT.Notes:- The intracell handover selects the available TCHs cyclically or based on the idle TCH measurements (if SET BTS [INTERF]:INTCLASS=TRUE;) in the scope of the intra-cell HO limitationfunctions set (see parameter ELIMITCH).- In a concentric cell (CREATE BTS [BASICS]:CONCELL=TRUE) theintracell handover (quality) may only take place within the completearea or within the inner area!

- In an extended cell the intra-cell handover due to quality may only take place from double to double ts or from single to single ts(exception: if no single TCH is available, a double one is selected).- For HSCSD calls the intracell HO due to quality is not performed,irrespective of the status of the INTRACH flag. In case of bad quality,HSCSD calls might be downgraded from 14,4 kbit/s to 9,6kbit/s (see

parameters in command SET HAND [DATA]).- To avoid a ping-pong handover from HR to FR and vice versa,which can occur due to subsequent execution of (AMR)decompression handover (parameter EADVCMPDCMHO, seeabove) and intracell handover due to quality (for a call whose quality is still poor after decompression handover), the features ‘Cell load dependent actvation of half rate’ (see parameter EHRACT incommand CREATE BTS [BASICS]) and ‘Abis load dependent

activation of half rate’ (see parameter ABISHRACTTHR in command CREATE BTSM) are not considered if the BSC receives anINTRACELL HANDOVER CONDITION INDICATION due to quality reasons (cause values ‘uplink quality’ or ‘downlink quality’). Thismeans that the BSC does not check the current BTS TCH load and the BTSM Abis pool TCH load in case of an intracell handover due toquality.





IRACHOSDCCH=FALSE,


range: TRUE, FALSE

default: FALSE

Intra-cel l handov er for SDCCH , this parameter determines whether intra-cell handover due to quality is enabled for SDCCH-SDCCH-handovers or not.

LOTERCH=TRUE,

object: HAND [BASICS]range: TRUE, FALSE

default: TRUE

Local inter-cel l Handover enabled , determines whether inter-cell handover is controlled by the BSC (TRUE) or MSC (FALSE). If the

flag is set to FALSE, and the BSC receives an INTERCELLHANDOVER CONDITION INDICATION (BWHCI) from the BTS, theBSC forwards the handover responsibility to the MSC by sending aHANDOVER REQUIRED to the MSC, even if the first target cell inthe target cell list of the BWHCI is an internal one.Notes:- This flag is valid both for TCH-TCH handover and SDCCH-SDCCH handover! - The setting of this parameter has an impact on performancemeasurement: It must be set to TRUE to ensure the correct working of specific counters related to inter-cell handover (ATINHIRC,SINTHINT).

LOTRACH=TRUE,

object: HAND [BASICS]range: TRUE, FALSE

default: TRUE

Local intra-cel l Handover enabled , determines whether intra-cell handover is controlled by the BSC (TRUE) or MSC (FALSE). If the

flag is set to FALSE, and the BSC receives an INTRACELLHANDOVER CONDITION INDICATION (WIHCI) from the BTS, theBSC forwards the handover responsibility to the MSC by sending aHANDOVER REQUIRED to the MSC, indicating the serving cell asthe only target cell.Notes:- This flag is valid both for TCH handover and SDCCH-SDCCH handover.- If the BTS is a concentric cell (CREATE BTS [BASICS]:CONCELL=TRUE) or an extended cell (CREATE BTS [BASICS]:CELLTYPE=EXTCELL) the setting of LOTRACH is ignored. Intracell handover (quality) is in this case always BSC-controlled! - If LOTRACH is set to FALSE the BSC automatically adds theserving cell to neighbour cell description IE (BA-list) in the SYSTEM

INFORMATION TYPE 5.- For a correct working of performance measurement counters(ATINHIAC, SINTHITA) for intracell handovers LOTRACH must beset to TRUE!

MAIRACHO=2,


range: 1-15

default: 2

Maximum n umb er of intra-cel l handovers , this parameter is only considered if the flag ELIMITCH (see above) is set to TRUE. It determines the maximum number of consecutive successful intracell handovers due to quality (parameter INTRACH, see above) or intracell handovers due to c ompression (parameter EADVCMPDCMHO, see above ) that are permitted in the same BTSfor a single connection.

In the BSC, two separate counters are managed :- The first counter monitors the number of consecutive intracell quality handovers. It is increased by ‘1’ whenever the BSC receives

an ASSIGNMENT COMPLETE after having sent an CHANNEL ACTIVATION / ASSIGNMENT COMMAND for a quality intracell handover to the BTS).- The second counter monitors the number of consecutivec ompressio-decompression back-and-forth handovers. This counter is increased by ‘1’ after receipt of the last ASSIGNMENT COMPLETE of a back-and-forth compression-decompression handover (i.e. FR->HR->FR).

MAIRACHO determines the common threshold value for bothcounters - however, both counters are managed separately and indepenently and lead to independent signalling of handover





suppression towards the BTS.

In other words: the BSC may a) send a CHAN ACT with cause ‘handover successful’ to the BTS(when the quality intracell handover counter has reached theMAIRACHO threshold) for one quality intracell handover (leading to asuppression of only quality intracell handover for the time defined by TINOIERCHO - as long as the call remains on that channel) and b) may also add the cause ‘handover successful’ also to the

subsequent CHAN ACT to the BTS, if an INTRACELL HANDOVER CONDITION INDICATION with cause ‘decompression’ was received and MAIRACHO was additionally reached for the compression-decompression handover counter in the BSC. This will then lead to asuppression of only compression intracell handovers for the timedefined by TINOIERCHO - as long as the call remains on that channel. Intracell quality handovers are not suppressed by the BTs at this stage.

Any kind of successful intracell handover or intercell handover with acause different from intracell quality of compression-decompressionon the same connection resets the counters.

Note:Due to the feature implementation actually the maximum allowed number of consecutive successful intra-cell handovers is

MAIRACHO+1 .

MAXFAILHO=2,


range: 1-15

default: 2

Maximum n umb er of fai led handovers , this parameter is only relevant if the parameter NOFREPHO is set to TRUE and determinesthe maximum number of consecutive failures of intra BSC handoversthat are permitted in the same BTS for a single connection.





NCELL=6,


range: 0..15

default: 6


(for HANDOVER

REQUIRED)

Numb er of preferred cel ls , defines the number of preferred cells inthe HANDOVER CONDITION INDICATION message. This messageis a result of the handover measurement pre-processing function inthe BTS and is sent periodically from the BTS towards the BSC (see

parameter THORQST). The handover measurement pre-processing function evaluates the measurement reports received from the MS inorder to determine whether a handover is necessary and - if yes -

which neighbour cells are suitable target cells. These cells are theninserted into the target cell list of the HCI. If the BSC does not execute the handover itself it sends the message HANDOVER REQUIRED towards the MSC.

NOBAKHO=TRUE,


range: TRUE, FALSE

default: TRUE

No back handover , this flag determines whether the feature'Prevention of Back handovers' is enabled or not. It enables amechanism that prevents a back-handovers due to power budget if the TCH in the serving cell was seized by an imperative handover

procedure (handover due to level, quality or distance). If the flag NOBAKHO is set to TRUE the back-handovers are prevented by thefollowing mechanism: if an imperative handover (to a cell for whichNOBAKHO=TRUE) is performed the BSC extends the CHANNEL

ACTIVATION message for the 'new' TCH in the target cell by the IE 'Cell List Preferred' which contains the CGI of the handover origin cell

and by a GSM 08.08 cause IE with the cause 'distance'. Thismessage makes the BTS suppress the handover origin cell in all following INTERCELL HANDOVER CONDITION INDICATION messages sent with the cause 'better cell' for an administrable time

period (see parameter TINHBAKHO (CREATE ADJC)).

Note: The flag NOBAKHO is relevant for the handover target cell, i.e.the CHAN ACT message is extended by the above mentioned IEs if the BSC detects that for the handover target cell the flag NOBAKHOis set to TRUE. The BTS then retrieves the TINHBAKHO value fromthe adjacent cell object that represents the handover origin cell from

point of view of the handover target cell.

NOFREPHO=TRUE,


range: TRUE, FALSE

default: TRUE

No handov er fai lures repeti t ion , this flag determines whether thefeature 'Prevention of handover failures repetition' is enabled or not.

It enables a mechanism which prevents unlimited handover repetitions to a target cells if previously handovers to this cell havenot been successful. A handover is regarded as unsuccessful if theMS returns to the old channel with a HANDOVER FAILURE messageor if in case of an external handover the timer T7 expires (e.g. due toreceipt of a HANDOVER REQUIRED REJECT message). If the flag NOFREPHO is set to TRUE every unsuccessful handover leads tothe increase of a counter in the BSC. If this counter reaches anadministrable threshold (see parameter MAXFAILHO) the BSC sendsa HANDOVER FAILURE INDICATION message to the BTS whichcontains the CGI of the target cell to which the handover attemptsfailed. As a result, the BTS excludes the affected cell from the target cell list of the HANDOVER CONDITION INDICATION messages for an administrable period of time (see parameter TINHFAIHO(CREATE ADJC)).

PBGTHO=TRUE,


range: TRUE, FALSE

default: TRUE


Power budget hando ver enabled , determines whether handover due to power budget is enabled. This flag is only relevant if intercell handover is enabled in the cell (INTERCH=TRUE, see above).Power budget handover means: handover to another cell if this cell offers a higher transmission level (irrespective of whether the power level of the actual cell is above the minimum - see RXLEVHO - or not.). Further parameters relevant for this type of handover areHOAVPWRB (HAND object, see above) and HOM (ADJC object).Note: this flag only determines whether inter-cell handovers may beexecuted with cause ‘better cell’.





PL=0,


range: 0..15

default: 0

Prior i ty layer , if hierarchical cell handover is enabled (HIERC=TRUE) this parameter determines the priority layer of theown cell. This priority is only evaluated for the Power Budget handover decision and the traffic handover decision (see parameter TRFKPRI). The priority layers of the neighbour cells are administered in the ADJC object (see ADJC object).

RXLEVHO=TRUE,


range: TRUE, FALSE

default: TRUE


RxLevel handov er enabled , determines whether handover due tolow receive level on uplink or downlink is enabled. This flag is only relevant if intercell handover is enabled in the cell (INTERCH=TRUE,see above). If the receive level is below the minimum threshold handover is necessary. Further parameters relevant for this type of handover are HOAVLEV, HOLTHLVDL and HOLTHLVUL (seeabove).Note: this flag only determines whether inter-cell handovers may beexecuted with cause ‘level’.

RXQUALHO=TRUE,


range: TRUE, FALSE

default: TRUE


RxQual handov er enabled , determines whether handover due tobad receive quality on uplink or downlink is enabled. This flag is only relevant if intercell handover is enabled in the cell (INTERCH=TRUE,see above). Bad receive Quality is determined by error ratemeasurements in the MS and the BTS. Further parameters relevant for this type of handover are HOAVQUAL, HOLTHQUDL and HOLTHLQUUL, HOLTHQAMRDL and HOLTHQAMRUL (see above).Note: this flag only determines whether inter-cell handovers may beexecuted with cause ‘quality’.

SG1HOPAR=<NULL>,


range: <NULL>,

8 fields with ranges in



represent.

default: <NULL>

Service group 1 hando ver parameters , this parameter is the first of the 14 parameters which allows a service group-dependent setting of handover parameters and thresholds.

The setting <NULL> indicates that for this service group no specific parameter settings are applied and the handover decision for thisservice group is based the ordinary HAND parameter settings.

Fo further details please refer to the section “Service dependent Handover and Power Control in the appendix of this document.

SG2HOPAR...SG14HOPAR=<NULL>,


range: <NULL>,

n fields with ranges in



represent.

default: <NULL>

Service group 2..14 handov er parameters , these parametersrepresent the remaining 13 parameters which allow a service group-dependent setting of handover parameters and thresholds.

The setting <NULL> indicates that for the affected service group nospecific parameter settings are applied and the handover decision for this service group is based the ordinary HAND parameter settings.

Fo further details please refer to the section “Service dependent Handover and Power Control” in the appendix of this document.

THLEVFULHO=8,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm...

62 = -48dBm


default: 8

Level threshold for fast upl ink handover , this parameters definesthe uplink receive signal strength threshold for an inter-cell fast uplink handover (see parameter EFULHO). If the UL RXLEV drops below the level defined by THLEVFULHO, the BTS triggers a fast uplink handover.

For further details please refer to the section ‘Handover Thresholds

and Algorithms’ in the appendix of this document.





THORQST=5,


unit: 2 SACCH multiframes

range: 0..31

default: 5


Timer for handover request defines the minimum interval betweenHANDOVER CONDITION INDICATION messages (see parameter NCELL) related to the same connection. If the BSC cannot executethe handover itself it sends a HANDOVER REQUIRED messagetowards the MSC. Like the HCI the HANDOVER REQUIREDmessage also contains a target cell list and a handover cause (e.g.‘uplink quality’, ‘better cell’ etc.) and is repeated under consideration

of the timer T7 (see SET BSC SET BSC [TIMER], parameter BSCT7).

Recommendation:

THORQST (HAND) > T7 (SET BSC [TIMER])Note: If THORQST is set to 0 then the HCI is repeated after every SACCH multiframe, i.e. every 480ms. If the call remains on the sameTCH this might lead to a 'toggling' of inter- and intra-cell HCIs.

TINOIERCHO=60,


unit: 1s

range: 1-254

default: 60

Timer for 'no in tra-cel l handover ' , this parameter is only considered if the flag ELIMITCH (see SET HAND [BASICS]) is set to TRUE. It specifies the timer used by the BTS to indicate how long a) quality intra-cell handover (see parameter INTRACH in command SET HAND [BASICS]) or b) AMR compression handover (see parameter EADVCMPDCMHOin command SET HAND [BASICS])shall be prevented for a specific connection in the cell if MAIRACHO+1 successful handovers of that particular types havetaken place before. The timer is started in the BTS on receipt of the

adapted CHANNEL ACTIVATION message which contains anadditional GSM 08.08. cause 'handover successful'. The only event that can stop this timer is the release of the call context (e.g. call release or inter-cell handover).

THORQSTpurpose: Minimum time between two HO_COND_IND messages related to the

same connectionstart: sending of HO_COND_IND message by the BTSstop: - receipt of a HANDOVER COMMAND from the MSC

- no further HO_COND_INDs received from the BTS- communication to MS is lost- transaction has ended, call cleared

expiry action: repetition of the HO_COND_IND message is permitted





TRFHITH=90,


unit: 1%

range: 50..100

default: 90

Traff ic handov er high threshold , this parameter specifies the cell traffic load that leads to the enabling of traffic handover in the BTS.The traffic load of a cell is calculated as follows:

Attention:- Generally a TCH\F is counted as 2, a TCH\H is counted as 1!




- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBTS [BASICS]) has an influence on the radio TCH traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]). a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all (non-reserved) TCHswhich are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like anyother TCH which is currently seized by a CS call.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currentlybusy due to GPRS traffic (PDCH) are considered as ‘idle’.- If the timer TEMPCH (see command CREATE PCU) is running for a particular

TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is setfor the DGRSTRGY parameter, as these TCHs are in any case immediately preemptedif a CS TCH request meets a TCH congestion situation.



The BSC cyclically checks the traffic load (controlled by the timer TRFCT, see SET BSC) in all cells in which traffic handover isenabled (see parameter TRFHOE) and compares it to the threshold specified by TRFHITH. If the traffic load in the cell is above the cell-

specific threshold TRFHITH, the BSC enables the traffic handover inthe affected BTS by sending an LAPD O&M message SET

ATTRIBUTE with the appropriate contents to the BTSM. This O&M message is the trigger for the BTS to start the traffic handover decision algorithm (for more details concerning the handover decision please refer to the appendix ‚Handover Thresholds and

Algorithms’).If the traffic handover was already enabled for a specific BTS on the

previous expiry of TRFCT and the traffic load in the affected BTS isstill above the threshold TRFHITH, no further message is sent to theBTS and the traffic handover remains enabled in the affected BTS. If the traffic handover was enabled for a specific BTS on the previousexpiry of TRFCT and the traffic load in the affected BTS hasdecreased below the threshold TRFHITH, the BSC disables the

traffic handover in the affected BTS by sending another LAPD O&M message SET ATTRIBUTE with the appropriate contents to theBTSM.







TRFHOE=TRUE,


range: TRUE, FALSE

default: FALSE

Traff ic handover enabled , this parameter enables the feature‘Handover due to BSS resource management criteria’ or shortly called ‘traffic handover’. If this flag is enabled, the BSC cyclically checks the traffic load situation of this cell. If the traffic load exceedsthe threshold TRFHITH, the BSC enables the traffic handover in theBTS by sending SET ATTRIBUTE message with the ‘traffic handover enabled’ indication to the BTS via the LPDLM link. As a result, the

BTS starts its handover decision process in such a way that it continuously evaluates the DL MEASUREMENT REPORTS for suitable neighbour cells for traffic handover. Similar to the power budget handover decision process the traffic handover decision

process monitors the level difference between the serving cell and the neighbour cells and compares it to an administrable handover margin (traffic handover margin, see explanations for TRFHOT):when the power budget exceeds the traffic handover margin, ahandover due to traffic is initiated by sending a corresponding INTERCELL HANDOVER CONDITION INDICATION with the

proprietary cause ‘traffic’. Differences to the normal power budget handover decision consist in the following aspectsa) While the power budget handover decision process is continuously running in the BTS if the database flag PBGTHO is set to TRUE, the

traffic handover decision process only runs in those time periodswhere the traffic handover was explicitly enabled by the mentioned SATT message from the BSC before.b) While the power budget handover margin has a static value, thetraffic handover margin is dynamically changed (reduced or increased) by a timer-controlled step-by-step reduction mechanism(see TRFHOT).

When the BSC receives the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with the proprietary cause ‘traffic’, it checksthe current TCH load of the target cells indicated in the BWHCI. Only if the current TCH load of the suggested target cell is lower than aconfigurable threshold (see TRFLTH), the handover to this target cell is actually executed.

Traffic Handover can only take place within the BSC as

- only for these cells the target cell traffic condition can be checked - the cause value ‘traffic’ is not defined for the A-interface signalling.This means that the

Parameters relevant for the control of the dynamic traffic handover margin and the target cell list generation performed in the BTS areTRFHOT, TRFHOM, TRFMS, TRFMMA and TRFKPRI (see HANDobject) and BHOFOT (see ADJC object). The parameter relevant for the measurement averaging is HOAVPWRB (see above).

Parameters relevant for the traffic handover tasks performed by theBSC (traffic load evaluation and traffic handover initiation) areTRFCT (see SET BSC) and the traffic load thresholds TRFHITH and TRFLTH (see HAND object).

Notes:

- This parameter is only relevant if intercell handover is enabled inthe cell (INTERCH=TRUE, see above).- Traffic handover towards a cell is always possible, irrespective of the TRFHOE flag (only TRFLTH is considered in this case).- In a Concentric Cell (see parameter CONCELL in command CREATE BTS [BASICS]), the BTS triggers Traffic Handover only for calls served by a complete area TRX.- In an Extended Cell (see parameter CELLTYPE=EXTCELL incommand CREATE BTS [BASICS]) the BTS does not trigger any Traffic Handover at all.





TRFHOT=10,


unit: 1s

range: 2.. 20

default: 10

Traff ic handover t imer , this timer is used for the traffic handover decision (see TRFHOE) in the BTS and defines the cycle in whichthe BTS recalculates the dynamic traffic handover margin while traffic handover is enabled in the BTS. TRFHOT is started first in the BTSwhen the BTS has received the ‘traffic handover enabled’ message(SET ATT) from the BSC via the LPDLM link and has started its first handover decision phase. The SET ATT message is sent from BSC

to BTS when the BSC has detected the exceeding of a traffic load threshold (see TRFHITH) on expiry of the traffic control timer (seeTRFCT in command SET BSC [BASICS]).

On expiry of TRFHOT the traffic handover margin is recalculated inthe following way: When the traffic handover is enabled due toreceipt of the SET ATT message from the BSC, the BTS starts thefirst handover decision phase with an ‘initial’ traffic handover margin.When TRFHOT expires for the first time, the next traffic handover decision phase starts with a reduced traffic handover margin and TRFHOT is restarted (as long as TRFHOT runs, the traffic handover margin remains constant). In other words, specific adjacent cells, that were not included in the target cell list of the first INTERCELLHANDOVER CONDITION INDICATION (HCI), might appear in oneof the subsequent HCIs (even if the level conditions do no change)

due to the fact that the traffic handover margin has decreased. Thistraffic handover margin reduction process is continued accordingly onthe next expiries of TRFHOT until the maximum allowed traffic handover margin reduction is reached. From this point of time on thetraffic handover margin remains the same on every further expiry of TRFHOT.

When the BSC disables the traffic handover in the BTS by sending aSET ATTRIBUTE message with the ‘traffic handover disabled’ indication to the BTS, the BTS does not immediately stop its traffic handover decision process but recalculates the traffic handover margin again on the next expiry of TRFHOT – this time, however, thehandover margin is increased. If the traffic handover remainsdisabled (i.e. no ‘traffic handover enabled’ indication received fromthe BSC), the dynamic traffic handover margin is increased step-by-

step with every expiry of TRFHOT. When the initial traffic handover margin is reached, the decision process is stopped and no traffic handover is triggered anymore.

A reasonable setting of the BSC traffic control timer TRFCT (see SET BSC [BASICS]) and TRFHOT is

TRFHOT (HAND) > TRFCT (BSC)

This timer combination ensures that the traffic load situation ischecked by the BSC before the BTS initiates the next step of traffic handover margin reduction.

Parameters relevant for the dynamic traffic handover marginreduction/increase mechanism are TRFHOM (ADJC object) and TRFMS and TRFMMA (HAND object). TRFHOM defines the basic traffic handover margin, TRFMS determines the reduction resp.

increase step size of the traffic handover margin (compared to the previous handover decision phase) and TRFMMA defines themaximum allowed reduction of the traffic handover margin.The diagrams on the next page illustrate the dynamic traffic handover reduction/increase mechanism.

continuation see next page…





The following diagrams might illustrate the dynamic traffic handover reduction/increase mechanism:

Note: This algorithm shows that the timer-controlled reduction of thetraffic handover margin can - depending on the setting of the

parameters TRFHOM, TRFMS and TRFMMA - lead to negative traffic handover margin values. Depending on the operator’s philosophy

and the setting of the traffic load threshold TRFHITH, it might alsomake sense to use negative traffic handover margin values for TRFHOM from the beginning (the closer the threshold TRFHITH is to100%, the more ‘aggressive’ (i.e. negative) the traffic handover margin setting should be). However, to avoid that in such cases thetraffic handover is triggered for calls with poor level conditions in theserving cell and even worse level conditions are expected in thetarget cell, the minimum RXLEV condition for traffic handover target cells includes an additional level offset TRFHORXLVMOFF (seecommand CREATE ADJC):

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + TRFHORXLVMOFF

For more details regarding the exact interworking of the mentioned

ime

TRFHOT

firstexpiry of TRFHOT

Traffic HO

enabledindicationreceivedfrom BSC

TRFHOT TRFHOT TRFHOT

secondexpiry of TRFHOT

Start of second traffic HO decision phase with

reduced traffic HO marginTraffic HO Margin = TRFHOM - 2*TRFMS

Start of first traffic HO decision phase withInitial traffic HO margin

Traffic HO Margin = TRFHOM - 1*TRFMS

thirdexpiry of TRFHOT

If n*TRFMS has reached TRFMMA and traffic

HO remains enabled, the traffic HO marginreduction remains stable (=TRFMMA) for allsubsequent expiries of TRFHOT.

Start of third traffic HO decision phase withreduced traffic HO marginTraffic HO Margin = TRFHOM - 3*TRFMS

Principle of the traffic handover margin reduction mechanism when traffichandover is enabled:

ime

TRFHOT

expiry of TRFHOT

Traffic HO

disabledindicationreceivedfrom BSC


expiry of TRFHOT

Traffic HO margin from the previousTRFHOT period is increased by TRFMS


expiry of TRFHOT

If the traffic HO remains disabled, andthe traffic HO margin reaches the initialvalue TRFHOM – 1*TRFMS, thehandover decision process is stopped onthe next ex ir of TRFHOT.

Principle of the traffic handover margin increase mechanism when traffic

handover is disabled:





parameters, please refer to the section ‘Handover Thresholds and Algorithms’ in the appendix of this document.

TRFKPRI=FALSE,


range: TRUE, FALSE

default: FALSE

Traff ic keep prior i ty , this parameter determines which neighbour cells are allowed as target cells for traffic handover if the feature‘hierarchical cell structure’ is enabled (parameter HIERC=TRUE).a) If TRFKPRI=TRUE, an adjacent cell may only be a traffic handover target cell if it has an equal priority level (see parameter PLNC in the

ADJC object) like he serving cell (see parameter PL).

b) If TRFKPRI=FALSE, an adjacent cell may be a traffic handover target cell if it has an equal or higher priority level like he serving cell.


TRFLTH=70,


unit: 1%

range: 0.. 85

default: 70

Traff ic handov er low threshold , this parameter specifies themaximum cell traffic load a BTS may have to accept incoming traffic handovers. The traffic load of a cell is calculated as follows:

Attention:





- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBTS [BASICS]) has an influence on the radio TCH traffic load calculation if theparameter DGRSTRGYBCNT is set to ENABLED (for further details please refer toparameter DGRSTRGYBCNT in command SET BSC [BASICS]). a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all (non-reserved) TCHswhich are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like anyother TCH which is currently seized by a CS call.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currentlybusy due to GPRS traffic (PDCH) are considered as ‘idle’.- If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is setfor the DGRSTRGY parameter, as these TCHs are in any case immediately preemptedif a CS TCH request meets a TCH congestion situation.


When the BSC has enabled the traffic handover in a specific BTS(see TRFHITH) the BTS makes a traffic handover decision and – if asuitable target cell is found - sends an INTERCELL HANDOVER CONDITION INDICATION (HCI) with cause ‘traffic’ and a list of thedetermined target cells to the BSC. The BSC only activates a TCH inthe target BTS, if the traffic load of this target BTS is below thethreshold TRFLTH. If the traffic load in the first target cell is above thethreshold, the BSC checks the next target cell in the list and so on. If none of the target cells has a suitable load situation (i.e. if the cell

traffic load > TRFLTH) the HCI does not lead to any handover and the next handover attempt HCI after expiry of TRFHOT (see below).







TRFMMA=9,


unit: 1dB

range: 1.. 48

default: 9

Traff ic handover margin maximum reduction , this parameter specifies the maximum reduction of the traffic handover margin (see

parameter TRFMS below). TRFMMA does not have to be an integer multiple of TRFMS but, of course, it makes sense to set the two

parameters in this way. In any case, TRFMMA is never exceeded.

In fact, the maximum reduction of the traffic handover margin is theresult of an integer division

max traffic HO margin reduction = (TRFMMA div TRFMS) ∗ TRFMS

For more details regarding the exact interworking of the mentioned parameters, please refer to the section ‘Handover Thresholds and Algorithms’ in the appendix of this document.

TRFMS=3,


unit: 1dB

range: 1.. 6

default: 3

Traff ic handov er margin reduction step , this parameter specifiesthe minimum reduction and simultaneously the reduction step size of the dynamic traffic handover margin. The BTS uses the traffic handover margin for the target cell list generation after the traffic handover decision. Only those neighbour cells are included in thetarget cell list of the INTERCELL HANDOVER CONDITION INDICATION (HCI) with cause ‘traffic’, for which the level differencebetween the serving and the neighbour cell exceeds the dynamic traffic handover margin. Whenever TRFHOT expires, the BTS

recalculates the traffic handover margin for the next TRFHOT period.If traffic handover is enabled (i.e. the ‘traffic handover enabled’ indication was received from the BSC in a SET ATT message), thetraffic handover margin is reduced by TRFMS in the next TRFHOT

period; if traffic handover is disabled (i.e. the ‘traffic handover disabled’ indication was received from the BSC in a SET ATT message) the traffic handover margin is increased by TRFMS in thenext TRFHOT period. Please see also the explanations provided for TRFHOT.

In fact, the basic traffic handover margin (TRFHOM, see ADJC object) is already reduced by TRFMS in the first traffic handover decision immediately after the receipt of the ‘traffic handover enabled’ indication. This means the ‘initial’ traffic handover margin after theenabling of traffic HO is TRFHOM-TRFMS. After the first

expiry/restart of TRFHOT, the basic traffic handover marginTRFHOM is reduced by 2 ∗ TRFMS for the duration of the next TRFHOT period and so on. However, the reduction of the traffic handover margin is not unlimited: the maximum reduction of thetraffic handover margin is defined by the parameter TRFMMA (seeabove).

For more details regarding the exact interworking of the mentioned parameters, please refer to the section ‘Handover Thresholds and Algorithms’ in the appendix of this document.





Handover Parameter RelationsInter-cell handover

Inter-Cel l Hando ver

Parameters relevant for all types of in ter-cell HO

HAND: NCELL, THORQST , NOFREPHO*, MAXFAILHO*

TGTBTS: MSTXPMAXGSM (-DCS, -PCS), ADJC: RXLEVMIN, TINHFAIHO*

* These parameters are not relevant for Directed Retry, Preemption, Fast Uplink Handover and Traffic Handover.

** - Forced Handover consists of ‘Directed Retry’ and ‘Forced Handover due to Preemption’.

Both forced HO types are independent of the INTERCH flag.

- Neither 'Directed Retry' nor 'Forced Handover due to Preemption' are relevant for SDCCH-SDCCH handovers.

*** Parameters for prevention of back-HO in the HAND and ADJC objects are set from point of view of the

handover target cells.

**** Not relevant for Directed Retry, Forced Handover due to Preemption and Traffic handover!

+ Traffic Handover is not performed for SDCCHs but for TCHs only. Thus the flags for SDCCH HO are not relevant.

Qual i ty HO

HAND: RXQUALHO=

TRUE

HOAVQUAL

HOLTHQUDL

(resp.HOLTHQAMRDL

for AMR calls)

HOLTHQUUL

(resp.HOLTHQAMRUL

for AMR calls)

Level HO

HAND: RXLEVHO=

TRUE

HOAVLEV

HOLTHLVDL

HOLTHLVUL

Forced HO**

BSC: ENFORCHO=

ENABLE

EISDCCHHO=

ENABLE

(inter-BSC DR)

ADJC: FHORLMO

Distance HO

HAND: DISTHO=

TRUE

HOAVDIST

HOTMSRM

Power Budget HO

HAND: PGBTHO=TRUE

HOAVPWRB

ADJC: HOM

Speed Sens. HO

HAND: DPBGTHO=

TRUE

ADJC: HOMSOFF

HOMDTIME

HOMDOFF

MICROCELL

HCS

HAND: HIERC=TRUE

HAND: PL

ADJC: PLNC

PPLNC

HCS

HAND: HIERC=TRUE

HAND: PL

ADJC: PLNC

PPLNC

Hierarchical Cel l Structure (HCS)

HAND: HIERC=TRUE

HAND: HIERF=RANK 1

ADJC: PLNC

LEVONC

HAND: HIERF=RANK 0

ADJC: PLNC

Prev. of

back HO

(PBGT)***

ADJC: TIMERFHO

Extended

Cell

HAND: HOTMSRME

SDCCH-SDCCH hando ver

HAND: IERCHOSDCCH=TRUE (intercell intra-BSC)BSC: EISDCCHHO=ENABLE (inter-BSC)

TCH handover

HAND: INTERCH=TRUE (intra- and inter-BSC)

Level HO

Margin

HAND: ELEVHOM

ADJC: LEVHOM

Fast Upl. HO

HAND: EFULHO=

TRUE

THLEVFULHO

ALEVFULHO

ADJC: FULHOC

FULRXLVMOFF

BSC/MSC contro l of inter-cell (TCH-TCH) handover

HAND: LOTERCH=TRUE→ HO is BSC controlled ****

LOTERCH=FALSE→ HO is MSC controlled ****

Traff ic HO +

BSC: TRFCT

HAND: TRFHOE

=TRUE

TRFHITH

TRFLTH

TRFMS

TRFMMA

ADJC: TRFHOM

TRFHORXLV

MOFF

HCS

HAND: HIERC=

TRUE

PL

TRFKPRI

ADJC: PLNC

Prevention o f back (PBGT) HO ***

HAND: NOBAKH=TRUE

ADJC: TINHBAKHO

Concentr ic Cel ls (sector ized)

BTS: CONCELL=TRUE

HAND: ININHO, CCELL

Prev. of

Back HO

(PBGT and

Traffic)*** ADJC:

BHOFOT





Intra-cell handove

Intra-Cel l Hando ver

* In a concentric cell the intra-cell handover due to quality only takes place within the inner or within the complete area,In an extended cell the intra-cell handover due to quality only takes place from double to double ts or from single to

single ts (exception: if no single TCH is available, a double one is selected)

For HSCSD calls no intra-cell handover due to quality is performed (independent of the state of the INTRACH flag).

** The setting of LOTRACH has no effect for concentric cells and for extended cells

*** Concentric Cell handover (inner <->complete) and Extended Cell handover (far <-> near) is NOT evaluated during the

SDCCH phase, thus these intra-cell handover causes are not relevant for SDCCH intracell handover.

Concent r ic Cell HO***

(comp lete to inner / inner to

complete)

BTS: CONCELL=TRUE

TRX: TRXAREA

PWRRED

HAND:

HORXLVDLI

HORXLVDLO

Extended Cell HO***

(near to far / far to near)

HAND: EXTCHO=TRUE

CHAN:

EXMODE=TRUE

('double' ts = far)

EXMODE=FALSE

('single' ts = near)

HAND:

HOMSTAM

HOMRGTA

HOAVDIST

Intra-cell HO due to quality

HAND: INTRACH=TRUE * HAND: IRACHOSDCCH=TRUE

(TCH-TCH HO) (SDCCH-SDCCH HO)***

HAND:

HOAVQUAL, HOAVLEV, HOLTHQUDL, HOLTHQUUL

HOTDLINT, HOTULINT, THORQST

BSC/MSC contro l of in t ra-ce l l handover (qual i ty)

HAND:

LOTRACH=TRUE → BSC controlled

LOTRACH=FALSE→ MSC controlled **

Limita t ion of in t ra-ce l l handover(qual i ty) repet i t ion

HAND: ELIMITCH=TRUE

MAIRACHO

TINOIERCHO

HO decis ion also

on distance cr i ter ia

HAND: CCDIST=TRUE

HOCCDIST

Intracell HO

due to

Enhanced

Pair ing

BSC:

EPA=TRUE

a) enhanced pairing due toradio TCH load

BTS:

EPAT1

EPAT2

b) enhanced pairing due to

BTSM Abis pool TCH load

BTSM: ABISHRACTHR

(Advanced)

Compression-

Decompression HO

BSC: TRFCT

HAND: EADVCMPCMDHO

EADVCMPHOAMR

EADVCMPHOSC

ADVCMPHOOAMR

C ompression HO

HOTHxxxCDL*

HOTHxxxCUL*

HOTHCMPLVDL

HOTHCMPLVUL

* xxx=AMR, FR or EFR

a) Compr. HO due toradio TCH load

BTS: HRACTAMRT1

HRACTAMRT2

HRACTT1

HRACTT2

b) Compr. HO dueto Abis TCH load

BTSM:

ABISHRACTHR

Decompression HO

HOTHyyyDDL**

HOTHyyyDUL**

HOTHDCMLVDL

HOTHDCMLVUL

** yyy=AMR, HR

a) Decompr. HO dueto radio TCH load

BTS:

FRACTAMRTH1

FRACTAMRTH2

FRACTTH1

FRACTTH2

HRDCMLIMTH

b) Decompr. HO dueto Abis TCH load

BTSM: ABISFRACTHR

Intracell

HO

due to

O&M

No

para-

meters !





Setting the cell specific parameters and threshold values for 14,4kbit/s datacall up- and downgrading and quality inter-cell handover:

< This command is used to set UL/DL quality thresholds for dataspeed up- and downgrade between 14.4kbit/s and 9.6kbit/s and quality inter-cell handovers for ongoing data calls. >

SET HAND [DATA] :

Attention: Since BR6.0 The DBAEM does not group the command

parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘HAND packages’ were moved below the object HAND (now subordinate to the BTS object) and appear in the DBAEM in the SET HAND command. The logical group “[DATA]” is normally only used on the LMT but was used here to allow a more useful grouping of thecommands .

NAME=BTSM:0/BTS:0/HAND:0,

Object path name .

ERUDGR=FALSE,

object: HAND [DATA]

range: TRUE, FALSE

default: FALSE

Enable rate up-/dow ngrade , this flag determines whether the quality evaluation for rate up-downgrading decision for 14.4kbit dataservices is enabled or not (see also parameter SPEED145 in thecommand SET BSC [BASICS]). If this feature is enabled, the BTSuses the DL measurement reports and UL measurement results todecide whether an upgrade from 14.4kbit/s to 9.6kbit/s or a

downgrade (vice versa) is necessary for an ongoing data call. Thisdecision is based exclusively on the UL/DL quality values determined for the serving TCHs.If the BTS decides that an up- or downgrade is necessary it sends aMODE MODIFICATION INDICATION message to the BSC which inturn executes the up- or downgrade.If the BTS recommends a rate downgrade and the data call is anHSCSD call, the BSC will downgrade the data rate per TCH from14.4Kbit/s to 9.6kbit/s but may decide to keep the user data rate by activating another TCH for the call.If a downgrade does not lead to a sufficiently improved quality, anintercell handover due to quality is initiated.For the threshold values for the up- and downgrade respectively theinter-cell quality handover please see the parameters RUGRUL,

RDGRUL,RHOLTQUL and RUGRDL, RDGRDL, RHOLTQDL.RAVEW=8,

object: HAND [DATA]

range: 4-32

default: 8

Rate averaging wind ow , this parameter specifies the size of the'gliding averaging window' used for the up- and downgrade decision.Before an up- or downgrade decision is made, the MEASUREMENT REPORTS from the MS and the BTS are averaged by a a 'gliding' averaging mechanism. The value of this parameter defines over many measurement samples the averaging is performed.

RDGRDL=2,

object: HAND [DATA]

range: 1-6

default: 2

Rate dow ngrade threshold downl ink , this parameter specifies thedownlink quality threshold (in RXQUAL values) for the downgrade(14.4 kbit/s -> 9.6kbit/s). To ensure a proper working of the decisionalgorithm the following rule has to be followed:

RUGRDL < RDGRDL < RHOLTQDL

RDGRUL=2,

object: HAND [DATA]

range: 1-6

default: 2

Rate dow ngrade threshold upl ink , this parameter specifies the

uplink quality threshold (in RXQUAL values) for the downgrade (14.4kbit/s -> 9.6 kbit/s). To ensure a proper working of the decisionalgorithm the following rule has to be followed:

RUGRUL < RDGRUL < RHOLTQUL





RHOLTQDL=3,

object: HAND [DATA]

range: 2-7

default: 3

Rate handover lower threshold qu al i ty downl ink , this parameter defines the receive signal quality threshold (in RXQUAL values) onthe downlink for handover decision for data calls where the rateup/downgrading mechanism was applied. To ensure a proper working of the decision algorithm the following rule has to befollowed:


RHOLTQUL=3,

object: HAND [DATA]

range: 2-7

default: 3

Rate handover low er threshold qual i ty upl ink , this parameter defines the receive signal quality threshold (in RXQUAL values) onthe uplink for handover decision for data calls where the rateup/downgrading mechanism was applied. To ensure a proper working of the decision algorithm the following rule has to befollowed:


RUGRDL=1,

object: HAND [DATA]

range: 0..5

default: 1

Rate upgrade threshold dow nl ink , this parameter specifies thedownlink quality threshold (in RXQUAL values) for the upgrade (9.6 kbit/s -> 14.4 kbit/s). To ensure a proper working of the decisionalgorithm the following rule has to be followed:


RUGRUL=1,

object: HAND [DATA]

range: 0..5

default: 1

Rate upgrade threshold up l ink , this parameter specifies the uplink quality threshold (in RXQUAL values) for the upgrade (9.6 kbit/s ->14.4 kbit/s). To ensure a proper working of the decision algorithm thefollowing rule has to be followed:


TINHRDGR=5,

object: HAND [DATA]

unit: 2 SACCH multiframes range: 2-100

default: 5

Timer to inhibi t rate dow ngrade , this parameter specifies theminimum time between an upgrade from 9.6 kbit/s to 14.4kbit/s and the next downgrade request sent by the BTS within the MODE MODIFICATION INDICATION.

TINHRUGR=10,

object: HAND [DATA]

unit: 2 SACCH multiframes range: 2-100

default: 10

Timer to inhibi t rate upgrade , this parameter specifies the minimumtime between a downgrade to from 14.4 kbit/s to 9.6kbit/s and thenext upgrade request sent by the BTS within the MODE

MODIFICATION INDICATION.





Enabling features related to ASCI, SMS-CB, Frequency Hopping, HSCSD, CallRelease due to Excessive Distance and Dynamic MAIO Allocation (DMA):

< The parameters listed below are basically included in the CREATE BTS command, but the enabling of the associated features is only

possible if particular preconditions are fulfilled. These preconditionsmainly consist of of other database objects and parameters that have

to be completely and conclusively defined befoer the feature can beenabled. If the associated objects or configurations do not consist inthe required way, the DBAEM and the BSC command interpreter will reject the feature enabling by an appropriate NACK cause.

For this reason DBAEM generates - in addition to the CREATE BTScommand - at an earliere point

the SET BTS command again at this position with only the relevant parameters included. >

SET BTS:

NAME= BTSM:0/BTS:0, Object path name .

ASCISER=ASCI_DISABLED,

object: BTS [CCCH]

range: ASCI_DISABLED,ASCI_ENABLED

default: ASCI_DISABLED

ASCI service , this attribute indicates whether for the BTS Advanced Speech Call Items (ASCI) are enabled. If ASCISER=ASCI_ENABLEDthis means that both VBS (Voice Broadcast service) and VGCS (Voice

Group Call Service) are enabled.Both VBS and VGCS call calls always involvea) one subscriber with special control permissions (called ‘dispatcher’)and b) a number of other subscribers (called ‘ASCI service subscribers’)which basically represent the ‘receiving’ parties of an ASCI call.

Voice Broadc ast Service (VBS)

A VBS call is always set up by the dispatcher. When a VBS call is set up by the dispatcher, the BSC activates an ‘ASCI Common TCH’ in all cells in which ASCI is enabled. This common TCH is a simplex TCH which only uses the DL direction (the UL is not used) and which isused by all ASCI service subscribers to ‘listen’ to the information sent by the dispatcher. In a VBS call, only the dispatcher may talk, all other

ASCI service subscribers are only allowed to ‘listen’.Voice Grou p Call Service (VGCS)

Basically a VGCS call is set up in the same way as a VBS call, i.e. anoriginating party initiates the call setup and for the called subscribersan ‘ASCI Common TCH’ is set up in the cells with ASCI enabled.

The differences towards a VBS call, however, are the following:- A VGCS call can not only be set up by the dispatcher but also by other ASCI service subcribers.- In case of a VGCS call, the ASCI service subscribers may not only listen but they can also talk. For this they can intiate the so-called ‘Talker Change’ procedure by pressing the PTT (‘Push To Talk’) buttonon their ASCI phone. In this case the requesting ASCI servicesubscriber is granted an uplink channel, which allows him to send speech information in the uplink direction, which is transmitted towards

all other ASCI service subscribers and and towards the dispatcher and is thus audible for all other parties involved in the VGCS call.

In this situation, the additional uplink TCH can be set up in two ways:a) A separate duplex TCH is allocated to the talking ASCI servicesubscriber for the transmission of the uplink speech information (“ASCI 1,5 channel model”)b) The so far unused uplink part of the ASCI Common TCH is activated and allocated to the talking ASCI service subscriber (“ASCI OneChannel Model”). For further details please refer to the parameter

ASCIONECHMDL in command SET BSC [BASICS].

ASCIULR=ULRDISABLE, ASCI Upl ink Reply , this parameter is relevant if ASCI is enabled





object: BTS [CONTROL]

range: ULRDISABLE,

VBSENABLE

VGCSENABLE

VBS_VGCSENABLE

default: ULRDISABLE

(parameter ASCISER, see above) and is used to enable or disable the‘Uplink Reply’ procedure for VGCS calls only (VGCSENABLE), VBScalls only (VBSENABLE) or both at the same time(VBS_VGCSENABLE).

Functional sequence of an ‘Uplink Reply’ procedureWhen an ASCI group call (VBS or VGCS) is set up in a cell and simultaneously an ASCI Common TCH was activated, the BTSbroadcasts the group call reference and the ‘Channel Description’ data

of the ASCI Common TCH via the Notification Channel (NCH) in thecell (please see also description of parameter NOCHFBLK). In thissituation, the BSC may initiate the release of the activated ASCI Common TCH, if no listening ASCI MSs are available in the cell. Tocheck whether ASCI MSs are present in the cell, the BTS sends theUPLINK FREE message via the FACCH associated to the ASCI common TCH and waits for an UPLINK ACCESS message. ThisUPLINK ACCESS message is sent on the ASCI common TCH and isthe response from the ASCI MSs, if they have previously received theUPLINK FREE message with the IE ‘Uplink Access Request’ included.For the supervision of this procedure, the BTS uses the timers TWUPA(timer to wait for uplink acccess, hardcoded in the BTS) and TUPLREP (administrable timer, see SET BTS [TIMER]) which are both started when the UPLINK FREE message is sent:

The BTS periodically repeats the sending of the abovementioned UPLINK FREE message (containing IE ‘Uplink Access Request’) viathe FACCH of the ASCI Common TCH. The time period between twoconsecutive transmissions of the UPLINK FREE message isdetermined by the timer TUPLREP. When no UPLINK ACCESSmessage was received from any ASCI MS before timer TWUPAexpires, the BTS assumes that no listening ASCI MS is present in thecell and initiates the de-allocation of the ASCI Common TCH in this cell by sending the the VBS/VGCS CHANNEL RELEASE INDICATION towards the BSC, which in turn releases the channel by sending CHANNEL RELEASE, DEACTIVATE SACCH, RF CHANNELRELEASE etc..

Notes:- The UPLINK FREE message is used in two different cases

a) in the Uplink reply procedure (as described above)b) during the ‘Talker Change’ procedure within a VGCS call (ASCI service subscriber presses the PTT button on the ASCI phone, see

parameter ASCISER in command SET BTS [CCCH]).Only in case a) the UPLINK ACCESS message contains the IE ‘Uplink

Access Request’. For case b) please refer to parameter VGRULF incommand SET BTS [TIMER])- If the ASCISER is disabled the Uplink Reply procedure must bedisabled as well; if ASCISER is enabled the uplink reply procedure canbe enabled or disabled optionally.- The activation state of the Uplink Reply procedure is indicated by aflag in the CHANNEL ACTIVATION message sent for the ASCI Common TCH contains within the IE ‘Channel Options’.- When the ASCI Common Channel was deallocated due to lack of

ASCI MS in the cell, the NOTIFICATION COMMAND is still sent viathe NCH but consequently does not contain the IE ‘ChannelDescription’ (which normally identifies the used ASCI Common TCH)any more, it just contains the group call references of all ASCI groupcalls currently ongoing in this cell. Moreover, the IE ‘CommandIndicator’ is set to the value ‘replace’. If in this situation an ASCI MS

performs a cell reselection to this cell, it will request the allocation of an ASCI Common TCH via a standard SDCCH request procedure(CHANNEL REQUIRED via the RACH followed by IMMEDIATE

ASSIGNMENT via the AGCH).- If the Uplink Reply procedure is disabled for a particular ASCI groupcall type (VBS or VGCS or both), the ASCI Common TCH will always





be activated in the affected cells as long as an ASCI group call isongoing, no matter whether ASCI subscribers are present in the cell or not. Consequently, the NOTIFICATION COMMAND is will alwayscontain the ‘Channel Description’ IE together with the group call reference.- On the LMT the parameter ASCIULR is grouped under theBTS [CONTROL] package. As this ‚package’ only consists of thissingle parameter it was added to the [CCCH] package here.

BTSHSCSD=FALSE,


range: TRUE, FALSE

default: FALSE


HSCSD enabled for the BTS , this attribute indicates whether HSCSD service is activated in the cell or not.Notes:- As a precondition for HSCSD the feature ‘early classmark sending’ (see SET BTS [OPTIONS]:EARCLM) must be enabled.- If an MS tries to set up an HSCSD call in a cell withBTSHSCSD=FALSE, the BSC starts a directed retry procedure if theflag ENFORCHO (see commandSET BSC [BASICS]) is set toENABLE: when the BSC receives an ASSIGNMENT REQUEST for an HSCSD call and a cell with BTSHSCSD=FALSE, it BSC sends aFORCED HANDOVER REQUEST message to the BTS, whichanswers, like in any case of forced handover, with an INTERCELLHANDOVER CONDITION INDICATION (cause ‘forced’) and a list of suitable target cells. The BSC checks the BTSHSCSD flag for the

suggested target cells - if it finds on target cell withBTSHSCSD=TRUE, the directed retry is executed (CHANNEL

ACTIVATION a HANDOVER COMMAND towards the target cell). If the BWHCI contains an external target cell (other BSC), the BSC sends the HANDOVER REQUIRED message towards the MSC, if the parameter EISDCCHHO (see commandSET BSC [BASICS]) isset to ENABLE.

EEXCDIST=FALSE,


range: TRUE, FALSE

default: FALSE

Excessive distance release enabled , this parameter determineswhether the feature 'call release due to excessive distance' isenabled. If the MS-BTS distance is bigger than the value entered for EXCDIST no call setup is possible. On the other hand, if during anongoing call the MS-BTS distance exceeds the EXCDIST threshold (see corresponding parameter) the BTS sends a CONNECTION FAILURE message with cause 'distance limit exceeded' to the BSC

and the call is released.ENDMA=FALSE,


range: TRUE, FALSE

default: FALSE

Enable Dynamic MAIO Al location , this parameter determineswhether the feature ‘Dynamic MAIO Allocation’ is enabled for theBTS.

Notes:- In the DBAEM, this parameter is listed within a SET BTS command behind the CREATE CHAN commands. In other words, the enabling of DMA is not possible together with the creation of the BTS object because for the DMA enabling both the DBAEM and the BSC command interpreter check, prior to command execution, whether all associated objects (CFHSY, TRX, CHAN etc.) have beenconsistently and conclusively created in the database before.- To be in effect, DMA must be enabled both in the BTS and theCBTS object. In the DBAEM, DMA is enabled in the BTS object first (see parameter ENDMA in command CREATE CBTS).

EXCDIST =35,


unit: 1km range: 1-35 (for standard cells)

1-100 (for extended cells)

default: 35 (for standard cells)

100 (for extended cells)

Excessive distance , this parameter specifies the distance limit (between MS and BTS) to be used for call release if the feature 'call release due to excessive distance' is enabled (EEXCDIST=TRUE)Note: The value entered for EXCDIST must be greater than the valueentered for the distance handover threshold (see parameter HOTMSRME (SET HAND)).

Rules:standard cells: HOTMSRM (HAND) < EXCDIST extended cells:HOMSTAM (HAND) < HOTMSRME (HAND) < EXCDIST





HOPP=TRUE,


range: TRUE, FALSE

default: FALSE


Frequency hoppin g enabled , indicates whether frequency hopping is manually enabled in the BTS by the operator. For ongoing calls,the information stating whether FH is enabled or not is sent on themain DCCH in the IE ‘Channel Description’ (contained e.g. in the

ASSIGNMENT COMMAND and the HANDOVER COMMAND) inform of the parameter H. If H=0 then frequency hopping is disabled, if H=1 then frequency hopping is enabled. For the MSs in idle mode thestatus of FH is indicated by the SYSTEM INFORMATION TYPE 1

message which is sent on the BCCH (see also parameter CALL inthe command CREATE BTS [BASICS]).Whether frequency hopping is actually active or not is not only determined by the ‘semipermanent’ flag HOPP but also by a‘transient’ system-internal flag BTS IS HOPPING (can be interrogated by the command GETINFO BTS) which is managed system-internally. If e.g. in a BTS with active baseband FH a TRX-HW (BBSIG, TPU, PA or CU) fails or is manually locked, FH isautomatically disabled by the BSC for the BTS to make sure that there is no impact on the call quality. In this case the state of the flag BTS IS HOPPING changes to ‘NO' while the (exclusively command-controlled) flag HOPP does not change. In any case the BSC is themaster for both the HOPP and the BTS IS HOPPING flag, i.e. theBTS only changes the FH if explicitly requested by the BSC via the

LPDLM link. For the BTS there is actually no difference between adisabling of hopping due to HOPP=FALSE or due toBTS_IS_HOPPING=NO.

Generally, every change of the frequency hopping mode is reported to all busy MSs in the cell by a FREQUENCY REDEFINITION message. These messages contain the channel data such as thenew ‘mobile allocation’, hopping sequence and MAIO and are specific for each ongoing call. When hopping is disabled (no matter whether this is done by command or automatically) the FREQUENCY REDEFINITION points out a new mobile allocation which consists of only one carrier and MAIO=0. This means that the MSs hop on onecarrier frequency only. If FH was disabled automatically due to failureor locking of a TRX-HW, it is again automatically enabled by the BSC if the failed/locked TRX-HW is put back to service: BTS IS HOPPING

changes its state to ‘YES’ and another FREQUENCY REDEFINITION procedure is started for all busy MSs.

If the hopping mode changes either due to manual or automatic disabling of hopping, the cell is set to “ barred “ for about 10s. This isdone to avoid unpredictable hopping errors in the hopping modeswitchover phase as the “ starting time “ of the new hopping systemis not known to mobiles currently in idle mode.

Attention: HOPP=FALSE actually means that the MSs hop on one

carrier if the channels are created with FHSYID≠ 0. In this case the parameter H in the messages ASSIGNMENT COMMAND,FREQUENCY REDEFINITION or HANDOVER COMMAND is alsoH=1 (=hopping channel)!

SMSCBUSE=TRUE,


range: TRUE, FALSE

default: FALSE


Short message service cel l broadcast used , this parameter canonly be set to TRUE if the BTS radio channels are created accordingly (see BCCH- and SDCCH creation).If this value is set to TRUE the SYSTEM INFORMATION TYPE 4 onthe BCCH contains the additional IE ‘CBCH Description’ and - if Frequency Hopping is enabled - the IE ‘CBCH Mobile Allocation’. Note: Control channels with CBCH capability (BCBCH or SCBCH)may only be deleted if SMSCBUSE is set to FALSE.





Creating the Target Cell Objects:

< The command CREATE TGTBTS has to be entered for all external neighbour cells, i.e. for neighbour cells that are served by a different BSC. The TGTBTS object inc ludes al l basic cel l parameters and

identi t ies of the external neighbour c el l . In BR6.0 a new approachin the creation and administration of adjacent cells was introduced:- If an ADJC object represents an in ternal cel l (i.e. a cell belonging to the same BSC), the ADJC object refers to the created BTS object .- If an ADJC object represents an external cel l (i.e. a cell belonging to a different BSC), the ADJC object refers to the created TGTBTS

object .- The BTS specific ADJC objects only include the parametersrelevant for the for handover decision and GPRS cell reselection.The advantage of this approach is that the basic cell data are not repeated in all (BTS specific) ADJC objects (which increases the

probability of errors) but are created only once in the database for all possible adjacent cell relations. >

CREATE TGTBTS:

NAME=TGTBTS:0, Object path name .

BCCHFREQ=103,

object: TGTBTS

range: 0..1023


GSM 04.08

GSM 05.05

GSM 12.20

BCCH frequency , This parameter defines the BCCH frequency of the neighbour cell. This info appears (together with the other adjacent cells)- for the MSs in 'idle' mode:on the BCCH in the SYSTEM INFORMATION TYPE 2, SYSTEM INFORMATION TYPE 2ter (in dualband networks) and SYSTEM INFORMATION TYPE 2bis in the IE ‘Neighbour Cells Description’.- for the MSs in 'dedicated mode' or 'busy' mode:on the main signalling channel (SDCCH or FACCH) in the SYSTEM INFORMATION TYPE 5, SYSTEM INFORMATION TYPE 5ter (for

dualband networks) and SYSTEM INFORMATION TYPE 5bis in theIE ‘Neighbour Cells Description’ and, during inter-cell handover, alsoin the main DCCH in the HANDOVER COMMAND in the IE ‘Cell Description’.

From the SYSTEM INFORMATION TYPE 2, 2ter and 2bis the MSknows the neighbour cells which have to be monitored for cell reselection in idle mode, via the information sent in the SYSTEM INFORMATION TYPE 5, 5ter and 5bis the MS is informed which of the neighbour cells are to be monitored during the call phase, i.e. for which neighbour cells measurement reports may be generated.

BSIC=7-3,

object: TGTBTS

range: 0..7 (NCC)

0..7 (BCC)Reference: GSM 03.03

GSM 04.08

GSM 05.02

GSM 05.08

GSM 12.20

Base Station Identi ty Code , parameter format: NCC - BCC (for detailed explanations see parameter BSIC (CREATE BTS[BASICS])). This parameter is sent in the DCCH in the HANDOVER COMMAND in the IE ‘Cell Description’. It is used by the MS to

correctly decode the BCCH bursts of the neighbour cell.

TGTCELL= TGTCELL=internal

neighbour cells

externalneighbour

cells TGTBTS:n BTSM:x/BTS:n

ADJC





CELLGLID="262"-"02"-23-111,

object: TGTBTS

range: MCC: 0..999

MNC: 0..999 (PCS1900)

MNC: 0..99 (all others)

LAC: 0..65535

CI: 0..65535


GSM 04.08

GSM 05.08

GSM 12.20

Cell Global Identit y , this identity corresponds to the info sent on theBCCH of the neighbour cell in the message SYSTEM INFORMATION TYPE 3 and 4. For details see the same parameter in the command CREATE BTS [BASICS].

MSTXPMAXDCS=0,

object: TGTBTS


range: 0..15

default: 0


GSM 05.05

GSM 04.08

GSM 03.22

GSM 12.10

Maximum transmiss ion power level in DCS target cell , indicatesthe maximum transmission power level a MS is allowed to use in theDCS target cell.This parameter is used in the handover pre-processing algorithm inthe BTS which evaluates the measurement reports in order todetermine the target cells for handover and directed retry. Theselection of a value corresponding to the actual settings of the BTSrepresented by the neighbour cell (see CREATE BTS [BASICS]:MSTXPMAXDCS=...) is recommended but not mandatory since the

two parameters are independent: MSTXPMAXGSM (TGTBTS) isonly used by the handover algorithm in the BTS, whileMSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) inCREATE BTS [BASICS] determines the allowed transmit power inthe IE ‘Power command’ on TCH Assignment.

Value range: 0..15 , default: 0=30dBm (step size -2dBm)

MSTXPMAXGSM=5,

object: TGTBTS


range: 2..15

default: 5

Maximum transmiss ion power level in GSM target cell , indicatesthe maximum transmission power level a MS is allowed to use in theGSM target cell.This parameter is used in the handover pre-processing algorithm inthe BTS which evaluates the measurement reports in order todetermine the target cells for handover and directed retry.

Value range:GSM900: 2..15 , default: 2=39dBm (step size -2dBm)GSMR: 2..15 , default: 0=30dBm (step size -2dBm)

For further information please refer to the explanation provided for the parameter MSTXPMAXDCS (TGTBTS) and, for the value ranges,to the parameter MSTXPMAXDCS (BTS [BASICS]).

MSTXPMAXPCS=0,

object: TGTBTS


range: 0..15, 30, 31

default: 0

Maximum transmiss ion power level in PCS target cell , indicatesthe maximum transmission power level a MS is allowed to use in thePCS target cell.This parameter is used in the handover pre-processing algorithm inthe BTS which evaluates the measurement reports in order todetermine the target cells for handover and directed retry.

Value range: 0..15, 30..31 (30=33dBm, 31=32dBm)default: 0=30dBm (step size -2dBm)

For further information please refer to the explanation provided for

the parameter MSTXPMAXDCS (TGTBTS) and, for the value ranges,to the parameter MSTXPMAXDCS (BTS [BASICS]).





SYSID=BB900,

object: TGTBTS

range: BB900 (GSM baseband)

DCS1800

F2ONLY900 (GSM ext. bd.)

EXT900 (GSM mixed band)

GSMR (railway GSM),

PCS1900GSMDCS

GSM850

GSM850PCS


System Indicator , indicates the frequency band used by the traffic channels.If F2ONLY900 is selected only phase2 mobiles can be used, phase1mobiles are not supported.If EXT900 is selected the GSM base band is still usable for phase1mobiles, the extension band, however, can only be used for traffic

purposes by phase2 mobiles.

Creating the Target Point-to-point Packet Flow Objects:

< The command CREATE TGTPTPPKF has to be entered for all external GPRS neighbour cells, i.e. for neighbour cells that support GPRS and that are served by a different BSC. The TGTPTPPKF

object includ es al l basic cel l parameters and identi t ies of the

external neighbo ur cel l . In BR6.0 a new approach in the creationand administration of adjacent cells was introduced:- If an ADJC object represents an intern al GPRS cell (i.e. a cell supporting GPRS and belonging to the same BSC), the ADJC object refers to the created BTS object which in turn is superordinate to aPTPPKF o bject .- If an ADJC object represents an external GPRS cell (i.e. a cell supporting GPRS and belonging to a different BSC), the ADJC object refers to the created TGTBTS object which in turn is superordinateto a TGTPTPPKF objec t .- The ADJC objects are specifically defined for each originating BTSand mainly comprise the handover decision parameters and advanced GPRS cell reselection parameters.The advantage of this approach is that the basic cell data are not repeated in all (BTS-specific) ADJC objects (which increases the

probability of errors) but are created only once in the database for all possible adjacent cell relations. >

CREATE TGTPTPPKF:

NAME=

TGTBTS:0/TGTPTPPKF:0,

Object path name .

EDTMSUP=DISABLED,

object: TGTPTPPKF


default: DISABLED

Enable Dual Transfer Mode supp ort , determines whether thefeature DTM (Dual Transfer Mode) is enabled in the target cell or not.

TGTCELL= TGTCELL= internal

neighbour cells

externalneighbour

cells TGTBTS:n

TGTBTS:n/TGTPTPPKF:m

ADJC

BTSM:x/BTS:y/PTPPKF:n

BTSM:x/BTS:y





GMSTXPMAC=2,

object: TGTPTPPKF

range: 0..31

default: 2



Maximum al lowed GPRS MS transmiss ion pow er on PBCCH/

PCCCH. GMSTXPMAC defines the maximum power level that may be used by the mobile to access the cell on the PRACH. The valid values and meanings are the same as defined for the parameter MSTXPMAXCH (see SET BTS [CCCH]).

Note: In case Network Controlled Cell Reselection (NCCR) isactivated in the serving cell (NCRESELFLAG=ENABLED), the PCU

uses GRXLAMI as well as GMSTXPMAC to calculate the C1 valuesalso in case no PBCCH is created in the cell.

This parameter corresponds to the GSM parameter GPRS_MS_TXPWR_MAX_CCH.

GRXLAMI=6,

object: TGTPTPPKF

range: 0..63

default: 6


GPRS minimum receive level for access at the MS required to access the network on the PRACH. In case a PBCCH is configured in the cell, GPRS mobiles use this value instead of the GSM equivalent RXLEVAMI (object BTS). It is used together with other

parameters to calculate C1 and C32 for cell reselection. This parameter is sent for the indicated neighbour cell on the PBCCH (PSI3).

Note: In case Network Controlled Cell Reselection (NCCR) isactivated in the serving cell (NCRESELFLAG=ENABLED), the PCU

uses GRXLAMI as well as GMSTXPMAC to calculate the C1 valuesalso in case no PBCCH is created.This parameter corresponds to the GSM parameter GPRS_RXLEV_ACCESS_MIN.

RACODE=10,

object: TGTPTPPKF

range: 0..255

Routing area code , this attribute represents the identification of theRA to which this cell belongs.

RACOL=10,

object: TGTPTPPKF

range: 0..7

default: 0

Routing area colour , this attribute is used by the mobile to identifiesthe specific routing area. Due to the fact that the RACODE can besmaller than LA and its numbering is not unique in the network but it’sunique in the LA, this parameter is used to choose the right RA whenthe mobile is listening different LA containing routing area with thesame code. The RA colour for the neighbour LA must be set different

by network planning.





) General hint concerning the neighbour cell relations:

All adjacent cells that are created for a certain BTS appear in the SYSTEM_INFORMATION_Type2,

2ter and 2bis on the BCCH (MS in idle mode) and SYSTEM INFORMATION Type5, 5ter and 5bis

on the SACCH (MS in dedicated mode) in the IE ‘Neighbour Cells Description’. From the SYSTEM

INFORMATION TYPE 2, 2ter and 2bis the MS knows the neighbour cells which have to be monitored

for cell reselection, from the SYSTEM INFORMATION TYPE 5, 5ter an 5bis the MS knows the

neighbour cells which have to be monitored for handover. The MS measures the RXLEV of theseneighbour cells to provide MEASUREMENT REPORTS to the serving BTS which uses them for the

handover decision.

The necessity to create a BTS as ADJC is completely independent of its physical location (same BTSE,

other BTSE, other BSC etc.).

If a GPRS PBCCH is configured, the neighbour cell data for GPRS mobiles are broadcast in the

PACKET_SYSTEM_INFORMATION_Type3, 3bis on the PBCCH in the IE ‘Neighbour cell

parameters’.

Creating the Adjacent Cell Objects:

< From BR6.0 on a new approach was used to structure the

neighbour cell data. With this approach ADJC objects mainly represent parameters used for handover and advanced GPRS cell selection parameters while the basic cell data and identities arerepresented by the BTS and PTPPKF objects (for internal cells) and by the TGTBTS and TGTPTPPKF objects (for external cells).For further details please refer to the commands CREATE TGTBTSand CREATE TGTPTPPKF. >

CREATE ADJC:

NAME=BTSM:0/BTS:0/ADJC:0,

Object path name .Important: The ‘adjacent cell no.’ is just a relative number of theadjacent cell from point of view of the cell (resp. BTS) for which it iscreated. There is no correspondence between this ‘adjacent cell no.’

and the actual ‘bts-no.’ of the adjacent cell! BARINSYSINFO10 =NO,

object: ADJC

range: YES, NO

default: NO

Barred in SYSINFO10 , this parameter BARINSYSINFO10 is used toconfigure a certain cell as barred in SI_10. In SI_10 it is possible toindicate a cell as barred. If barred in SI_10 the MS will skip this cell as a possible target for cell reselection.This opportunity can be used to avoid the cell reselection of a cell belonging to a different LAC in group receive mode while still maintaining the possibility to select such a cell both in idle mode and as HO target.

BHOFOT=30,

object: ADJC

unit: 1s

range: 1..120

default: 30

Back handov er forbidden timer for traff ic handov er , this parameter is used for back handover prevention and is considered after an incoming traffic handover. If the feature “Traffic Handover” respectively “Handover due to BSS Resource Management Criteria” (see parameter TRFHOE in command SET HAND [BASICS]) is

enabled, a cell might be the target of an incoming traffic handover. Inthis back-handovers due to traffic or power budget are prevented by the following mechanism: if an traffic handover is performed, the BSC extends the CHANNEL ACTIVATION message for the 'new' TCH inthe target cell by the IE 'Cell List Preferred' which contains the CGI of the handover origin cell and by a GSM 08.08 cause IE with the cause'traffic'. This message starts the timer BHOFOT in the BTS. As long as BHOFOT runs, the BTS excludes the CGI (that was previously received from the BSC in the CHAN ACT message) from all HANDOVER CONDITION INDICATIONs that are sent with thecauses “better cell” and “traffic“. The back handover preventionmechanism for traffic handover is permanently enabled and cannot





be deactivated by database flag.

FHORLMO=6,

object: ADJC

unit: 1dB

range: 0..24

default: 6

Forced handover Rx level minim um offs et, determines theadditional offset considered in addition to the handover minimumcriterion for “Forced Handover”. Forced handover consists of thefollowing handover types- Directed Retry (see parameter ENFORCHO in the command SET BSC [BASICS])- Forced Handover due to Preemption (see parameter EPRE in the

command SET BTS [OPTIONS]) and - Forced Handover due to O&M (automatically executed after aSHUTDOWN command for a BTS, TRX or CHAN object and not administrable by database parameters).

The value FHORLMO value is added to the RXLEVMIN entered for this adjacent cell in order to calculate the minimum RxLev theneighbour cell must provide to be considered as a target cell for thedirected retry. In other words: Only if the actual RxLev of an adjacent cell is greater than the sum of RXLEVMIN and FHORLMO(simplified) the BTS regards this cell as a suitable candidate for theforced handover procedure and will insert it into the target cell list included in the HANDOVER CONDITION INDICATION message.For details please refer to section 2.1.2.6.

FULHOC=FALSE,

object: ADJC

range: TRUE, FALSE

default: FALSE

Fast upl ink hando ver predefined cel l , this parameter is used during the target cell list generation process during a Fast Uplink Handover (see parameter EFULHO in command SET HAND[BASICS]) and is used to declare specific neighbour cells as“predefined” respectively ”preferential” target cells for fast uplink handover. When the BTS triggers a fast uplink handover it sends aINTERCELL HANDOVER CONDITION INDICATION that includesthe cause ‘fast uplink’ and a target cell list. The ranking on the target cells within this target cell list is based on two factors: the setting of the flag FULHOC and the level PBGT-HOM situation. The target cell list consists of two sublists: the upper list consists of all “preferential” target cells (FULHOC=TRUE), the lower one consists of ordinary target cells (FULHOC=FALSE). Within each sublist the target cellsare ranked in descending order of the difference between the power budget (which is, simply expressed, the level difference between theserving and the neighbour cell) and the power budget handover margin (see parameter HOM). In other words, the target cells withineach sublist are ranked in descending order of the value PBGT(n) –HOM(n).

For further details details concerning the fast uplink handover decision process and the ranking of the target cells please refer tothe section ‘Handover Thresholds and Algorithms’ in the appendix of this document.





FULRXLVMOFF=69,

object: ADJC

unit: 1dB

range: 0..126 (-63dB..+63dB)

default: 69 (=6dB)

Fast upl ink handover receive level minimum offs et , this parameter is used during the target cell list generation process during a Fast Uplink Handover (see parameter EFULHO in command SET HAND [BASICS]) and represents an additional offset which is added to the handover minimum criterion to qualify an adjacent cell as atarget cell for fast uplink handover. In other words: only if

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + FULRXLVMOFF(n)

i.e. if the measured DL receive level of the neighbour cells exceedsthe sum of RXLEVMIN, FULRXLVMOFF and the correction termMax(0,Pa), the neighbour cell is regarded as a suitable target cell for fast uplink handover and might appear in the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘fast uplink’.

For further details details concerning the fast uplink handover decision process and the ranking of the target cells please refer tothe section ‘Handover Thresholds and Algorithms’ in the appendix of this document.

GHCSPC =10,

object: ADJC



GPRS hierarchical cel l structur e pr ior i ty class , this attributerepresents the Hierarchical Cell Structure priority for the cell reselection procedure.

This parameter corresponds to the GSM parameter GPRS_HCS_PRIORITY_CLASS.

GHCSTH=10,

object: ADJC

unit: 2dB

range: 0..31

0=-110dB, 31=-48dB

default: 10


GPRS hierarchical cel l structure th reshold , this attribute indicatesthe signal strength threshold used in the HCS cell reselection

procedure (C31).

This parameter corresponds to the GSM parameter GPRS_HCS_THR.

GPENTIME=0,

object: ADJC

unit: 10s

range: 0..31

default: 0 (=10s)

GPRS penalty t im e , this attribute defines the duration for whichGTEMPOFF is applied to C31 and C32 in the cell reselection

procedure. The set values are coded as follows:

0 0 0 0 0 = 10s

0 0 0 0 1 = 20s…1 1 1 1 1 = 320s

This parameter corresponds to the GSM parameter GPRS_PENALTY_TIME.

GRESOFF=0,

object: ADJC

unit: 4dB (for the first 11 values

and for the last 9 values)

2dB (for all remaining

values)

range: 0..31

0 = -52 dB

31 = +48 dB

default: 16Reference: GSM 04.60

GPRS reselect offset , this attribute specifies the positive or negativeoffset to be applied to the C32 value of a neighbour cell. The set value ranges from -52 dB to +48 dB; the step size is 4 dB for the first 11 values, 2 dB for the next 12 values and 4 dB for the last 9 values,as shown in the table below:

0 1 ... 10 11 ... 22 23 ... 31

-52dB -48dB … -12dB -10dB … +12dB +16dB … +48dB

This parameter corresponds to the GSM parameter GPRS_RESELECT_OFFSET.





GSUP=TRUE,

object: ADJC

range: TRUE, FALSE

default: FALSE

GPRS supp ort , this attribute indicates if the adjacent cell informationis included in the PSI3 messages in case a PBCCH is configured inthe serving cell.The status of this flag is not relevant if no PBCCH is created in thesource cell!

Only if GSUP=TRUE, the GPRS cell reselection parameters defined in the related ADJC/PTPPKF/TGTPTPPKF objects are broadcast in

the PACKET SYSTEM INFORMATION TYPE 3 on the PBCCH.This allows the GPRS attached mobiles to autonomously calculate all criteria (C31/32) relevant for cell reselection. In case NCCR isactivated, the BSC will do this job based on level measurements

provided by the MS inside the PACKET MEASUREMENT REPORT messages.

The parameters of the neighbour cell that are broadcast in thePACKET SYSTEM INFORMATION on the PBCCH are derived fromthe PTPPKF object associated to the neighbour cell as follows:

a) if the cell is an internal cell (i.e. belonging to the same BSC), the parameters are derived from the PTPPKF object (see CREATE PTPPKF) subordinate to the BTS object (see CREATE BTS) entered in the TGTCELL parameter.

b) if the cell is an external cell (i.e. belonging to a different BSC), the parameters are derived from the TGTPTPPKF object (see CREATE PTPPKF) subordinate to the TGTBTS object (see CREATE TGTBTS)entered in the TGTCELL parameter.

GTEMPOFF=1,

object: ADJC

unit: 10dB

range: 0..7

7=infinity. default: 1


GPRS tempo rary offset , this attribute applies a negative offset to

C31 and C32 (depending if the cell priorities of source and neighbour cell are equal or not) for the duration of GPENTIME. The value rangeis coded as follows:

0 1 2 3 4 5 6 7

0dB 10dB 20dB 30dB 40dB 50dB 60dB infinite

This parameter corresponds to the GSM parameter GPRS_TEMPORARY_OFFSET.

TGTCELL= TGTCELL= internal

neighbour cells

externalneighbour

cells TGTBTS:n

TGTBTS:n/TGTPTPPKF:m

ADJC

BTSM:x/BTS:y/PTPPKF:z

BTSM:x/BTS:y





HOM=69,

object: ADJC

unit: 1dB

range: 0..126

0 = -63dB

126 = +63dB

default: 69 (= 6dB)


Handover margin , this parameter defines a threshold for the power budget handover (see parameter PBGTHO in command SET HAND[BASICS]). The handover margin is used for the power budget handover decision process: a power budget handover (‘better cell’ handover) is only triggered (i.e. an INTERCELL HANDOVER CONDITION INDICATION with cause ‘better cell’ is sent to the BSC)if the power budget of a specific neighbour cell exceeds the handover

margin set for the ADJC object representing this cell. The power budget is calculated for every neighbour cell and represents -simplified - the DL receive level difference between the serving and inthe neighbour cell, of course, taking the DL power control intoaccount.

The purpose of the handover margin is to prevent back-and-forthhandover repetitions between adjacent cells (‘ping pong handover’),e.g. if a MS moves along a boundary between two cells. Different adjacent cells can be assigned different handover margins in order tocontrol the handover flow.

Rule: To avoid 'ping pong' handovers between the inner and complete areas in sectorized concentric cells the following rule must be followed:

HOM coloc > (PWRREDinner - PWRREDcomplete ) [dB]

'HOM coloc ' is the handover margin set for an adjacent cell object that represents a 'colocated cell' (see parameter CCELL in command SET HAND [BASICS]).

HOMDOFF=0,

object: ADJC

unit: 1dB

range: 0..127

default: 0

Handover margin dynamic offset . This parameter is only relevant for speed sensitive handover (see parameters MICROCELL (below)and DPBGTHO in command SET HAND [BASICS]). It specifies thedynamic offset by which the handover margin is reduced after expiry of the timer HOMDTIME. For further details please refer to theexplanation given for the parameter HOMDTIME.

HOMDTIME=0,

object: ADJC



Handover margin delay time . This timer is only used if speed sensitive handover is active (see parameter MICROCELL). It specifies the time an immediate handover request is delayed when a

power budget handover to a microcell is requested.

General Principle of the speed sensi t ive handover algor i thm : If the BTS detects a power budget handover condition for a cell whichis created as MICROCELL, the timer HOMDTIME is started: as long as this timer runs the handover margin (see parameter HOM) isartificially increased by a static offset (see parameter HOMSOFF).This ‘new’ handover margin is called HO_MARGIN_TIME(t) since itsvalue is time dependent. If the basic power budget handover condition (i.e. PBGT > HOM) still exists when the timer expires, adynamic offset (see parameter HOMDOFF) is subtracted fromHO_MARGIN_TIME(t) again.Thus a speed sensitive handover condition is fulfilled if

PBGT > HO_MARGIN_TIME(t) where

HO_MARGIN_TIME(t) = HOM + HOMSOFF

for t ≤ HOMDTIME and

HO_MARGIN_TIME(n) = HOM + HOMSOFF - HOMDOFF for t > HOMDTIME

As long as the timer HOMDTIME runs the basic power budget handover condition is permanently checked; if the BTS detects that the basic power budget handover condition (i.e. PBGT > HOM) doesnot exist any more the timer is stopped and the handover is not executed.For further details please refer to chapter ‘Appendix’, section‘Handover Thresholds & Algorithms’ of this document.Note: The values should be set according to the rule:

HOMDOFF ≥ HOMSOFF.





HOMSOFF=0,

object: ADJC

unit: 1dB

range: 0..127

default: 0

Handover margin stat ic offset . This parameter is only relevant for speed sensitive handover (see parameters MICROCELL (below)and DPBGTHO in command SET HAND [BASICS]). It specifies thestatic offset by which the handover margin is increased as long asthe timer HOMDTIME runs. For further details please refer to theexplanation given for the parameter HOMDTIME.

LEVHOM=69,

object: ADJC

unit: 1dB

range: 0..126

0 = -63dB

126 = +63dB

default: 69 (= 6dB)

Level handover margin , this parameter defines the handover margin for handovers due to uplink level or downlink level. The level handover is triggered if the UL or DL receive level of the serving cell drops below the thresholds HOLTHLVUL resp. HOLTHLVDL. If thefeature “Level handover margin” (see parameter ELEVHOM incommand SET HAND [BASICS]) is disabled (ELEVHOM=FALSE),the target cell only has to fulfil the handover minimum condition

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa).

to be included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION with the cause values “uplink strength” or “downlink strength”.

If the feature “Level handover margin” is enabled (ELEVHOM=TRUE), also the level difference between the serving cell and the neighbour cell is considered. In this case the neighbour

cell only appears in the target cell list if its power budget exceeds theentered level handover margin:

RXLEV_NCELL(n) > RXLEV_DL + LEVHOM(n)

in addition to the handover minimum condition.

Attention: also in case of handovers due to uplink level, the PBGT calculation only considers the downlink levels of the serving and theneighbour cell!

For further details please refer to the section “Handover Thresholdsand Algorithms” in the appendix of this document.

LEVONC=0,

object: ADJC

unit: 1 dB


Level offset for neighbour cel l , this parameter determines the level offset that is added to the minimum receive level of an adjacent cell if ‘ranking method 1’ is selected in the ‘Hierarchical cell ranking flag’ (For further details please see the explanation for the parameter

HIERF in command SET HAND [BASICS]).

For the terms RXLEV_NCELL(n), RXLEVMIN (n), Max(0,Pa),PBGT(n) and HO_MARGIN(n) please refer to the section ‘Handover Thresholds & Algorithms’.

MICROCELL=FALSE,

object: ADJC

range: TRUE, FALSE

default: FALSE

Microcel l , determines whether the adjacent cell is regarded as a‘microcell’. Only if this parameter is set to TRUE the ‘speed sensitivehandover’ algorithm will be in effect for this neighbour cell.Precondition: the database flag for speed sensitive handover is set to‘enabled’ (SET HAND [BASICS]:DPBGTHO=TRUE). For this featurealso the parameters HOMDOFF, HOMDTIME and HOMSOFF (seeabove) are relevant.





MSTXPMAXCL=2,

object: ADJC

unit, range and default values see

explanation to the right!


GSM 05.05

GSM 12.20

Maximum transmiss ion power level , indicates the maximumtransmission power level a MS is allowed to use in the neighbour cell.This parameter is used in the handover pre-processing algorithm inthe BTS which evaluates the measurement reports in order todetermine the target cells for handover and directed retry. Theselection of a value corresponding to the actual settings of the BTSrepresented by the neighbour cell (see CREATE BTS [BASICS]:

MSTXPMAX=...) is recommended but not mandatory since the two parameters are independent: MSTXPMAXCL (ADJC) is only used by the handover algorithm in the BTS, MSTXPMAXGSM (resp.MSTXPMAXDCS or MSTXPMAXPCS) (CREATE BTS [BASICS])determines the allowed transmit power in the IE ‘Power command’ onTCH Assignment.Value range: GSM900: 2-15 default: 2=39dBm (step size -2dBm)

DCS1800: 0..15 default: 0=30dBm (step size -2dBm)GSMR: 0..15 default: 0=30dBm (step size -2dBm)PCS1900: 0..15 default: 0=30dBm (step size -2dBm),

30..31 30=33dBm, 31=32dBm

NCC1THADJC=DB05,

object: ADJC

range: DB00..DB63 (0dB..63dB)step size: 1dB

default: DB05 (5dB)

Network co ntrol led cel l reselect ion C1 threshold adjacent cel l ,this parameter is used during GPRS network controlled cell reselection (see parameter NCRESELFLAG in command SET BSC)

and defines the minimum C1 value of the adjacent cell required to beconsidered as potential target cell.

NCGPENTIME=SEC000,

object: ADJC

range: SEC000…SEC320

(0 sec. .. 320 sec.)

step size: 1 sec.

default: SEC000 (0 sec.)

Network co ntrol led cel l reselect ion GPRS penalty t ime , this parameter defines the duration for which NCGTEMPOFF is applied to C31 and C32 in case NCCR is activated (NCRESELFLAG =TRUE). The set value ranges from 0 to 320s in steps of 1 second.

The equivalent parameter in case NCCR is disabled is GPENTIME.

This parameter corresponds to the GSM parameter GPRS_PENALTY_TIME.

NCGRESOFF=DB00,

object: ADJC

range: MDB52...MDB01

(-52dB..-1dB)

DB00..DB48

(0dB..48dB)

step size: 1dB

default: DB00 (0dB)

Network co ntrol led cel l reselect ion GPRS reselect offset , thisattribute specifies the positive or negative offset to be applied to theC32 value of the neighbour cell in case NCCR is activated (NCRESELFLAG = TRUE). The set value ranges from -52 dB to +48 dB in steps of 1dB.

The equivalent parameter in case NCCR is disabled is GRESOFF.

This parameter corresponds to the GSM parameter GPRS_RESELECT_OFFSET.

NCGTEMPOFF=DB00,

object: ADJC

range: DB00..DB60

(0dB..60dB)

NEVER

step size: 1dB

default: DB00 (0dB)

Network co ntrol led cel l reselect ion GPRS temporary offs et , this parameter specifies the negative offset applied to C31 and C32 for the duration of NCGPENTIME in case NCCR is activated. The set value ranges from 0 to 60 dB in steps of 1dB. The value NEVER means infinity.

The equivalent parameter in case NCCR is disabled is GRESOFF.

This parameter corresponds to the GSM parameter GPRS_TEMPORARY_OFFSET.





PLNC=0,

object: ADJC

range: 0..15

0 = highest priority

15 = lowest priority

default: 0

Prior i ty layer of neighbour c el l , this parameter determines the priority layer of the adjacent cell. The priority layer is relevant for thehandover decision if the feature ‘ranking of target cells on the basis of

priority layer’ (see parameter HIERC in command SET HAND[BASICS]) is enabled.

PPLNC=0,

object: ADJC

range: 0..15



default: 0

Penalty pr ior i ty layer of neighb our cel l , this parameter is relevant for the handover decision if the features ‘speed sensitive handover’

(see parameter DPBGTHO in command SET HAND [BASICS]) and ‘ranking of target cells on the basis of priority’ (see parameter HIERC in command SET HAND [BASICS]) is enabled. It determines thetemporary priority layer of those adjacent cells which are defined asmicrocells (see parameter MICROCELL). PPLNC is only evaluated by the ranking algorithm as long as the handover margin delay timer HOMDTIME is running. Its purpose is to to allow the operator totemporarily decrease the priority of the affected neighbour cell toavoid handovers into this cell for fast moving MSs.Rule: PLNC(n) < PPLNC(n) n = no. of a certain ADJC object

QUALLEVHOM=69,

object: ADJCunit: 1dB

range: 0..126

0 = -63dB

126 = +63dB

default: 69 (= 6dB)

Level handov er margin for qual i ty handover , this parameter defines the handover margin for handovers due to uplink quality or

downlink quality. The quality handover is triggered if the UL or DLreceive level of the serving cell drops below of the thresholdsHOLTHQUDL (for AMR: HOLTHQAMRDL) resp. HOLTHQUUL (for

AMR: HOLTHQAMRUL) - for further details about the thresholds, please refer to the command SET HAND [BASICS]. If the feature“Level handover margin for quality handover” (see parameter ENAQUALEVHOM in command SET HAND [BASICS]) is disabled (ENAQUALEVHOM=FALSE), the target cell only has to fulfil thehandover minimum condition

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa).

to be included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION with the cause values “uplink quality” or “downlink quality”.

If the feature “Level handover margin for quality handover” is enabled

(ENAQUALEVHOM=TRUE), also the absolute level differencebetween the serving cell and the neighbour cell is considered. In thiscase the neighbour cell only appears in the target cell list if its power budget exceeds the entered level handover margin:

RXLEV_NCELL(n) > RXLEV_DL + QUALLEVHOM(n)

in addition to the handover minimum condition.

Attention: also in case of handovers due to uplink quality, the level difference calculation only considers the downlink levels of theserving and the neighbour cell!

For further details please refer to the section “Handover Thresholdsand Algorithms” in the appendix of this document.





RXLEVMIN=12,

object: ADJC

unit: 1 dB

range: 0..63


1 = -110dBm to -109dBm

2 = -109dBm to -108dBm

...62 = -49dBm to -48dBm


default: 12


GSM 12.20

Rx level minim um , determines the minimum received signal level the adjacent cell must provide to be regarded as a suitable target cell for handover. It is the minimum Rx level required for a MS to performthe handover to the adjacent cell. This parameter is used in thehandover pre-processing algorithm in the BTS which evaluates themeasurement reports in order to determine the target cells for handover and directed retry. The selected value should correspond

to the actual settings of the BTS represented by the neighbour cell (see CREATE BTS [BASICS]:RXLEVAMI =...) although both

parameters are basically independent from each other.

Note: Unlike other BTS parameters that cannot be entered anymore if the adjacent cell is an internal one (served by the same BSC) the

parameter RXLEVMIN can still be set if the ADJC object representsan internal cell. The reason is that RXLEVMIN plays an important rolein the handover evaluation algorithm and might be used for handover adjustment of special neighbour cell relations.

TGTCELL=BTSM:10/BTS:0,

object: ADJC

format: object instance path name

Internal cellsBTSM:n/BTS:m

External cells

TGTBTS:n

Target cell , this attribute specifies the object instance path name of the database object that represents the basic data of the neighbour cell. Depending on whether the neighbour cell is an internal (i.e.belonging to the same BSC) or an external one (belonging to adifferent BSC) the TGTCELL parameter points to different object types:a) If the ADJC object represents an internal cell (BTS), the TGTCELL

parameter points to the associated BTS object (see command CREATE BTS).b) If the ADJC object represents an external cell (BTS), theTGTCELL parameter points to the associated TGTBTS object (seecommand CREATE TGTBTS).

TIMERFHO=12,

object: ADJC

unit: 10s

range: 1-320

default: 12 (=120s)

Timer for forced handover, this timer is started after an incoming forced handover procedure. Forced handover consists of thefollowing handover types- Directed Retry (see parameter ENFORCHO in the command SET BSC [BASICS])- Forced Handover due to Preemption (see parameter EPRE in thecommand SET BTS [OPTIONS]) and - Forced Handover due to O&M (automatically executed after aSHUTDOWN command for a BTS, TRX or CHAN object and not administrable by database parameters).

A mechanism is implemented which prevents back-handovers due to power budget to the cell which was the origin of the forced handover.This mechanism works in the following way: if a forced handover is

performed the BSC extends the CHANNEL ACTIVATION message

for the 'new' TCH in the target cell by the IE 'Cell List Preferred' whichcontains the CGI of the handover origin cell and by a GSM 08.08 cause IE with the cause 'forced'. This message makes the BTSsuppress the handover origin cell in all following INTERCELLHANDOVER CONDITION INDICATION messages sent with thecause 'better cell' for the time period administrable with TIMERFHO.

After the timer expiry the power budget handover is allowed again.

TGTCELL= TGTCELL=internal

neighbour cells

externalneighbour

cells TGTBTS:n BTSM:x/BTS:n

ADJC





TINHBAKHO=30,

object: ADJC

unit: 1s

range: 1-254

default: 30

Timer to inhibi t back handover , this parameter is only considered if the flag NOBAKHO (see SET HAND [BASICS]) is set to TRUE. It specifies the time period for which the BTS excludes the adjacent cell from the power budget handover decision if this cell was the origin of an imperative handover.Rule: TINHBAKHO > THORQST(HAND) > T7 (SET BSC [TIMER])

Note: The flag NOBAKHO is relevant for the handover target cell, i.e.

the CHANNEL ACTIVATION message is extended by the abovementioned IEs if the BSC detects that for the handover target cell theflag NOBAKHO is set to TRUE. The BTS then retrieves theTINHBAKHO value from the adjacent cell object that represents thehandover origin cell from point of view of the handover target cell.

TINHFAIHO=7,

object: ADJC

unit: 1s

range: 1-254

default: 7

Timer to inh ibi t handov er fai lure repeti t ion , this parameter is only considered if the flag NOFREPHO (see SET HAND [BASICS]) is set to TRUE. It specifies the time period for which the BTS excludes aspecific adjacent cell from the target cell list when the threshold for the maximum allowed number of failed handovers (see parameter MAXFAILHO in command SET HAND [BASICS]) has been reached.Rule: TINHFAIHO > THORQST(HAND) > T7 (SET BSC [TIMER])

TRFHOM=67,

object: ADJC

unit: 1dB

range: 0..126

0 = -63dB

126 = +63dB

default: 67 (= 4dB)

Traff ic Handov er margin , this parameter defines the basic value of

the handover margin used for traffic handover (see parameter TRFHOE in the command SET HAND [BASICS]). Like for the power budget handover, the traffic handover margin is used for thehandover decision process in the BTS: a traffic handover is triggered (i.e. an INTERCELL HANDOVER CONDITION INDICATION withcause ‘traffic’ is sent to the BSC) only if the power budget of aspecific neighbour cell exceeds the traffic handover margin that wasset for the associated ADJC object representing this neighbour cell.The power budget is calculated for every neighbour cell and represents - simplified - the DL receive level difference between theserving and the neighbour cell, taking the DL power control intoaccount.

Different adjacent cells can be assigned different traffic handover margins in order to control the traffic handover flow.

Important notes:1) The traffic handover decision process only runs in the BTS, if theBSC has enabled it explicitly by an appropriate O&M message (see

parameter TRFCT in the command SET BSC).

2) The traffic handover decision process uses a ‘dynamic’ traffic handover margin, which is periodically recalculated on the basis of atimer-controlled process. The basic traffic handover margin that is set with TRFHOM is only a part of this ‘dynamic‘ traffic handover margincalculation. Thus the ‘real’ traffic handover margin that is actually used in the traffic handover decision process is never exactly asentered in the parameter TRFHOM but always applied in a ‘reduced’ form. The traffic handover margin is periodically reduced/increased by a process controlled by the timer TRFHOT (see parametersTRFMS and TRFMMA in command SET HAND [BASICS]).

The highest possible value of the dynamic traffic handover margin(e.g. in the first TRFHOT period after enabling of the traffic handover by the BSC) is

TRFHOM – TRFMS

The lowest possible value of the dynamic traffic handover margin is

TRFHOM – TRFMMA

3) For traffic handover it might be useful if the dynamic traffic handover margin

(TRFHOM–TRFMS) > dyn. traff. HO margin > (TRFHOM-TRFMMA)

assumes negative values as the purpose of the traffic handover is to





move calls from the serving cell to cells which provide a DL receivelevel which is not as good as that of the serving cell but still acceptable.

TRFHORXLVMOFF=6,

object: ADJC

unit: 1dB

range: -24...+24 (dB)

default: 6 (dB)

Traff ic handover receive level minim um o ffset , this parameter isused during the target cell list generation process for Traffic Handover (see parameter TRFHOE in command SET HAND[BASICS]) and represents an additional offset which is added to thehandover minimum criterion to qualify an adjacent cell as a target cell

for traffic handover. In other words: only if RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + TRFHORXLVMOFF(n)

i.e. if the measured DL receive level of the neighbour cells exceedsthe sum of RXLEVMIN, TRFHORXLVMOFF and the correction termMax(0,Pa), the neighbour cell is regarded as a suitable target cell for handover due to traffic and might appear in the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause‘traffic’.

The purpose of this additional offset is to prevent traffic handovers for those calls that fulfil the traffic handover conditions with respect to thetraffic handover margin (parameter TRFHOM, see above), but whoselevel is already low in the current serving cell. If the traffic handover margin is set to negative values or reaches negative values due to

the dynamic margin reduction (which is not only possible but quite a probable and even desirable setting) a handover to target cells withvery poor levels should be avoided to guarantee an acceptable gradeof service in the traffic handover target cell and to prevent undesired back-handovers due to level or quality (without the offset applied by the parameter TRFHORXLVMOFF a neighbour cell is regarded assuitable if it fulfils the minimum DL RXLEV on the basis of RXLEVMIN only). As many operators regard the quality of serviceguaranteed by RXLEVMIN as not sufficient or too insecure for ahandover that is mainly supposed to change the traffic distribution but which should not have a noticeable negative impact on the current QoS provided to the subscriber, the administrable traffic handover offset defined by TRFHORXLVMOFF is considered in addition toRXLEVMIN when evaluating the DL RXLEV of a particular neighbour cell.

For further details details concerning the traffic handover decision process and the ranking of the target cells please refer to the section‘Handover Thresholds and Algorithms’ in the appendix of thisdocument.

USG=SI_2_5,

object: ADJC

range: SI_2

SI_5

SI_2_5

INACTIVE

default: SI_2_5

Usage of neighbou r cel l in SYS INFO , this parameter indicateswhether this adjacent cell shall be indicated as neighbour cell on theBCCH in the idle mode (SYSTEM INFORMATION TYPE 2, 2bis and 2ter) or/and on the SACCH in busy mode (SYSTEM INFORMATION TYPE 5, 5bis and 5ter). The purpose of this parameter is to control the cell reselection and handover traffic separately. In other words,with this parameter it is possible to prevent either outgoing cell reselection or outgoing handovers for specific neighbour cell relations:

If a neighbour cell is included in the SYS_INFO_2 on the BCCH, theMS observes it for cell reselection. This means, that only in this casethe MS measures the DL receive level of this neighbour cell while it isin ‘idle’ mode. The DL receive level is used to calculate the C1respectively C2 criterion (see parameters CELLRESH and incommand CREATE BTS [BASICS]) for the ranking of the neighbour cells in the MS internal book-keeping list for cell reselection.

If a neighbour cell is included in the SYS_INFO_5 on the SACCH, theMS regards it as a target cell for handover. This means, that only inthis case the MS measures and the DL receive level of this neighbour cell while it is in ‘busy’ mode and reports it to the BTS via theSACCH. This again is the precondition for any outgoing intercell





handover decision by the BTS.

Thus the meaning of the values is pretty simple:- Setting USG=SI_2 means that the neighbour cell is only broadcast in the SYS_INFO_2x. Thus only cell reselection to this neighbour cell is possible, while this cell is blocked for outgoing intercell handover.- Setting USG=SI_5 means that the neighbour cell is only signaled inthe SYS_INFO_5x. Thus only outgoing intercell handover to thisneighbour cell is possible, while this cell is blocked for cell

reselection.- Setting USG=SI_2_5 means that the neighbour cell is both signaled in the SYSTEM INFORMATION TYPE _2x and SYSTEM INFORMATION TYPE 5x. Thus both cell reselection and outgoing intercell handover to this neighbour cell is possible. - Setting USG=INACTIVE means that the neighbour cell is only signaled in the SYSTEM INFORMATION TYPE 5x in order to havethe cell measured and reported by the MS - however, outgoing intercell handover to this neighbour cell is never triggered by theBTS, as the cell is only considered for measurement purposes. ???

If the BA lists (i.e. the lists of adjacent cell BCCH frequencies tomonitor) are different between SYS_INFO_2 and SYS_INFO_5 theBSC has to assign complementary BA indicators (possible values:0 or 1) to SYS_INFO_2 and SYS-INFO_5. This is necessary as the

MS may report the neighbours based on the SYS_INFO_2 (e.g.directly when the MS has changed from idle to busy mode, but hasnot yet read the new BA list from the SYS_INFO_5) and the MSreports the neighbour cells always by their relative BCCH frequency number. To correctly translate this relative BCCH frequency number into the CGI of the neighbour cell, the BTS must know for which BA-list the MEASUREMENT REPORT is valid. The MS indicates thevalid BA-list by the BA-indicator which is included in theMEASUREMENT REPORT.

Note: For ASCI VBS and VGCS calls in ‘group receive mode’ (i.e the ASCI subscribers are listening to the ASCI common channel in theDL) the relevant neighbour cell description is included in theSYSTEM INORMATION TYPE 10. At present, this SYSINFO 10 contains all neighbour cells created via ADJC objects, irrespective of

the setting of USG.

Starting from the BR7.0 ‘clean-up’ load, the USG parameter will alsoallow to control the presence of particular neighbour cells in theneighbour cell description of the SYSINFO 10 (FRQ 90569).





Creating the Target Cell Objects for handover from GSM to UMTS (FDD):

< The command CREATE TGTFDD has to be entered for all external UMTS (FDD) neighbour cells, to which a handover from GSM toUMTS and vice versa shall be possible. The TGTFDD object issubordinate to the TGTBTS object and defines parameters that arespecific for UMTS FDD neighbour cells. >

CREATE TGTFDD:NAME=TGTFDD:0, Object path name .

CELLGLID="262"-"02"-23-111,

object: TGTFDD

range: MCC: 0..999

MNC: 0..999 (PCS1900)

MNC: 0..99 (all others)

LAC: 0..65535

CI: 0..65535


Cell Global Identity , this identity corresponds to the info broadcast on the in the UMTS(FDD) neighbour cell.

FDDARFCN=9665,

object: TGTFDDrange: 412 .. 687

9662 .. 9938,

10838 .. 10838

Reference:

FDD absolute radio frequency num ber , this parameter defines theabsolute radio frequency number of the frequency used by the target

FDD cell.

FDDDIV=NO_DIVERSITY,

object: TGTFDD

range: DIVERSITY,

NO_DIVERSITY default: NO_DIVERSITY

FDD diversi ty , this parameter indicates if diversity is used in theUMTS FDD target cell or not.

FDDSCRMC=1,

object: TGTFDD

range: 0..511 Reference:

FDD scrambl ing c ode , this parameter defines the primary scrambling code used by the target FDD cell.

MSTXPMAXUMTS=11,

object: TGTFDD

range: 0..19

default: 0

Reference:

recommended value: 11

Maximum transmiss ion power level UMTS , indicates the maximumtransmission power level a MS is allowed to use in the UMTS FDDneighbour cell.This parameter is used in the handover pre-processing algorithm inthe BTS which evaluates the measurement reports in order todetermine the target cells for handover from GSM 2G to UMTS FDDneighbour cells. The selection of a value corresponding to the actual settings of the target NodeB is recommended but not mandatory since the two parameters are set in different network elements and are thus independent.

Attention: For a proper wo rking of 2G-3G handover

MSTXPMAXUMTS should be set to the value 11 (corresponds to21dBm). With the default value of ‘0’ the neighbour cells are reported but are not suitably considered during the target cell list generation(the value ‘0’ corresponds to 43dBm) and thus do not appear in theINTERCELL HANDOVER CONDITION INDICATION message.





RNCID=0,

object: TGTFDD

range: 0..4095

default: 0 Reference:

RNC Identity , this parameter determines the identity of the FDD-RNC (UMTS FDD Radio Network Controller) the target FDD cell isconnected to.

Creating the Adjacent Cell Objects for external UMTS FDD or UMTS TDD cells:

CREATE ADJC3G:

NAME=BTSM:0/BTS:0/ADJC3G:0,

Object path name .

GMICROCU=FALSE,

object: ADJC3G

range: TRUE, FALSE

default: FALSE

GPRS microcel l UMTS , this attribute indicates specifies whether anUMTS neighbour cell is a UMTS microcell for which the additional MSS condition of the Mobile Speed Sensitive (MSS) NC GSM/GPRSto UMTS cell reselection algorithm shall be applied.

HOM=69,

object: ADJC3G

unit: 1dB

range: 0..126

0 = -63dB

126 = +63dB

default: 69 (= 6dB)

Reference:

Handover m argin for 2G-3G better cel l handover , this parameter defines a threshold for the ‘better cell’ handover from GSM 2G toUMTS FDD neighbour cells (see parameter EUBCHO in command SET HAND). The handover margin is used for the ‘power budget’ handover decision process: a ‘power budget’ handover from 2G to3G is only triggered (i.e. an INTERCELL HANDOVER CONDITION INDICATION with cause ‘better cell’ is sent to the BSC) if the power budget of a specific UMTS FDD neighbour cell exceeds the handover margin set for the ADJC3G object representing this cell. The power budget is calculated for every neighbour cell and represents -simplified - the DL receive level difference between the serving 2Gand in the 3G neighbour cell, of course, taking the DL power control into account.

The purpose of the handover margin is to prevent back-and-forthhandover repetitions between adjacent cells (‘ping pong handover’),e.g. if a MS moves along a boundary between two cells. Different adjacent cells can be assigned different handover margins in order tocontrol the handover flow.

HOMDOFF=0,

object: ADJC3G

unit: 1dB

range: 0..127

default: 0

Handover margin dy namic offs et for 2G-3G speed sensi t ive

handover . This parameter is only relevant if speed sensitivehandover from GSM 2G to UMTS FDD neighbour cells (see

parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS]) is enabled. It specifies the dynamic offset by whichthe handover margin is reduced after expiry of the timer HOMDTIME.For further details please refer to the explanation given for the

parameter HOMDTIME (see below).





HOMDTIME=0,

object: ADJC3G


range: 0..255

default: 0

Handover m argin delay time for 2G-3G speed sensi t ive

handover . This parameter is only relevant if speed sensitivehandover from GSM 2G to UMTS FDD neighbour cells (see

parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS]) is enabled. It specifies the time an immediatehandover request is delayed when a power budget handover to amicrocell is requested.

General Principle of the speed sensi t ive handover algor i thm : If the BTS detects a power budget handover condition for an UMTSFDD neighbour cell which is created with MICROCELL=TRUE (seebelow), the timer HOMDTIME is started: as long as this timer runs thehandover margin (see parameter HOM) is artificially increased by astatic offset (see parameter HOMSOFF). This ‘new’ handover marginis called HO_MARGIN_TIME(t) since its value is time dependent. If the basic power budget handover condition (i.e. PBGT > HOM) still exists when the timer expires, a dynamic offset (see parameter HOMDOFF) is subtracted from HO_MARGIN_TIME(t) again.Thus a speed sensitive handover condition is fulfilled if

PBGT > HO_MARGIN_TIME(t) where

HO_MARGIN_TIME(t) = HOM + HOMSOFF

for t ≤ HOMDTIME and

HO_MARGIN_TIME(n) = HOM + HOMSOFF - HOMDOFF for t > HOMDTIME

As long as the timer HOMDTIME runs the basic power budget handover condition is permanently checked; if the BTS detects that the basic power budget handover condition (i.e. PBGT > HOM) doesnot exist any more the timer is stopped and the handover is not executed.

For further details please refer to chapter ‘Appendix’, section‘Handover Thresholds & Algorithms’ of this document.Note: The values should be set according to the rule:

HOMDOFF ≥ HOMSOFF.

HOMSOFF=0,

object: ADJC3G

unit: 1dB

range: 0..127

default: 0

Handover margin s tat ic offset for 2G-3G speed sensi t ive

handover . This parameter is only relevant if speed sensitivehandover from GSM to UMTS FDD neighbour cells (see parametersEUBCHO, PBGTHO and DPBGTHO in command SET HAND[BASICS]) is enabled. It specifies the static offset by which thehandover margin is increased as long as the timer HOMDTIME runs.For further details please refer to the explanation given for the

parameter HOMDTIME.

MICROCELL=FALSE,

object: ADJC3G

range: TRUE, FALSE

default: FALSE

Microcel l f lag for UMTS FDD neighbour c el l , determines whether the adjacent cell is regarded as a ‘microcell’. Only if this parameter isset to TRUE the ‘speed sensitive handover’ algorithm will be in effect for this neighbour cell. Precondition: the database flag for speed sensitive handover is set to ‘enabled’ (SET HAND[BASICS]:DPBGTHO=TRUE).

PLNC=0,

object: ADJC3G

range: 0..15



default: 0

Prior i ty layer of UMTS FDD neighbo ur cel l , this parameter

determines the priority layer of the adjacent UMTS FDD neighbour cell. The priority layer is relevant for the handover decision if thefeature ‘ranking of target cells on the basis of priority layer’ (see

parameter HIERC in command SET HAND [BASICS]) is enabled.





PPLNC=0,

object: ADJC3G

range: 0..15



default: 0

Penalty pr ior i ty layer of UMTS FDD neighbour cel l , this parameter is only relevant if speed sensitive handover from GSM to UMTS FDDneighbour cells (see parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS]) and ‘ranking of target cells on the basis of priority’ (see parameter HIERC in command SET HAND [BASICS]) is enabled. It determines the temporary priority layer of those adjacent UMTS FDD cells which are defined as

microcells (see parameter MICROCELL). PPLNC is only evaluated by the ranking algorithm as long as the handover margin delay timer HOMDTIME is running. Its purpose is to to allow the operator totemporarily decrease the priority of the affected UMTS FDDneighbour cell to avoid handovers into this cell for fast moving MSs.Rule: PLNC(n) < PPLNC(n) n = no. of a certain ADJC object

RXLEVMINC=5,

object: ADJC3G

unit: 1 dB

range: 0.. 63

0: RSCP < - 115 dBm

1: -115dBm ≤ RSCP < -114dBm

... ...

62: -54dBm ≤ RSCP < -53dBm

63: - 53 dBm ≤ RSCPdefault: 5

Reference:

Rx level minimum of UMTS FDD neighbour cel l , this parameter determines the minimum received signal level (indicated as RSCP –Received Signal Code Power) from UMTS the adjacent cell must

provide to be regarded as a suitable target cell for 2G-3G handover.It is the minimum Rx level required for a MS to perform a 2G-3Ghandover towards the UMTS FDD adjacent cell. This parameter isused in the handover pre-processing algorithm in the BTS whichevaluates the measurement reports in order to determine the UMTS

FDD target cells for 2G-3G handover (see parameter EUHO incommand SET HAND [BASICS]). The selected value should correspond to the actual settings of the UMTS FDD Node B althoughboth parameters are administered in different network elements and are thus independent from each other.

TINHFAIHO=7,

object: ADJC3G

unit: 1s

range: 1-254

default: 7

Timer to inh ibi t handov er fai lure repeti t ion for UMTS FDD

neighbou r cell , this parameter is only considered if the flag NOFREPHO (see SET HAND [BASICS]) is set to TRUE. It specifiesthe time period for which the BTS excludes a specific UMTS FDDadjacent cell from the target cell list when the threshold for themaximum allowed number of failed 2G-3G handovers (see parameter MAXFAILHO in command SET HAND [BASICS]) towards this

particular adjacent cell has been reached.Rule: TINHFAIHO > THORQST(HAND) > T7 (SET BSC [TIMER])

TGTCELL=TGTFDD:0,

object: ADJC3G

format: path name of a created

TGTFDD object instance

UMTS FDD target cell , this attribute specifies the object instance path name of the database object that represents the basic data of the UMTS FDD or TDD neighbour cell. The neighbour cell creationconcept for the ADJC3G objects is the same like for the ADJC objects (see CREATE ADJC): The TGTFDD/TGTTDD parameter always refers to an already created TGTFDD/TGTTDD object (seecommand CREATE TGTFDD)

TUESP=FALSE,

object: ADJC3G

unit: 1s

range: 0 .. 100

default: 5

Timer UE sp eed , this parameter is only relevant if the parameter GMICROCU (see above) is set to TRUE. TUESP specifies is used Mobile Speed Sensitive NC GSM/GPRS to UMTS cell reselection. AnUMTS microcell is only included in the UMTS target cell list, if thethreshold condition for “sufficient UMTS coverage” is met during thewhole timer period. A “fast moving” mobile will violate this timer condition and therefore, NC cell reselection from a GSM/GPRSserving cell to this UMTS microcell is not performed for a “fast moving” mobile.

TGTCELL=

externalUMTS FDD

neighbour cell

TGTFDD:n

ADJC3G





UADJ=63,

object: ADJC3G

unit: 1dB

range: 0..126 (-63dB..+63dB)

default: 63 (=0dB)

Reference:

UMTS adjust , this parameter is used in ‘better cell’ handover fromGSM to UMTS (see parameter EUBCHO in command SET HAND[BASICS]). Prior to the ‘better cell’ handover decision, the BTS addsthe value of UADJ to the reported RSCP value of the 3G cell (only ineffect if FDDREPQTY=RSCP, see SET BTS[BASICS]) to adjust theDL receive level of the related UMTS FDD adjacent cell compared tothe RXLEV_DL value of the serving cell as reported by the UE. ThusUADJ can be regarded as a fixed offset which is applied to all

reported RSCP values of 3G neighbour cells – it is up to the operator to decide whether this parameter should be used for particular 2G-3Gneighbour cell relations.

UMECNO=19,

object: ADJC3G

unit: 0.5 dB

range: 0.. 49

0: X < - 24 dB

1: - 24dB ≤ X < -23.5dB

... ...

48: - 0.5dB ≤ X < 0dB

49: 0dBm ≤ X

with X= CPICH Ec/No

default: 19

Reference:

UMTS min imum EcNo , this parameter defines the minimum level which is required to include an UMTS FDD cell into the handover target cell list in case of an ‘imperative’ handover (see parameter EUIMPHO in command SET HAND [BASICS]) from GSM to UMTSFDD when FDDREPQTY (see CREATE BTS [BASICS]) is set to thevalue EC_N0.

USECNO=23,

object: ADJC3G

unit: 0.5 dB

range: 0.. 49

0: X < - 24 dB

1: - 24dB ≤ X < -23.5dB

... ...

48: - 0.5dB ≤ X < 0dB

49: 0dBm ≤ X

with X= CPICH Ec/No

default: 23

UMTS suff ic ient EcNo , this parameter defines the threshold abovewhich BTS initiates a ‘sufficient coverage’ handover from GSM toUMTS FDD (see parameter EUSCHO in command SET HAND[BASICS]) when FDDREPQTY (see CREATE BTS [BASICS])attribute is set to the value EC_N0.

USECNONCRESEL=19,

object: ADJC3G

unit: 0.5 dBrange: 0.. 49

0: X < - 24 dB

1: - 24dB ≤ X < -23.5dB

... ...

48: - 0.5dB ≤ X < 0dB

49: 0dBm ≤ X

with X= CPICH Ec/No

default: 19 (= -15 ≤ Ec/No ≤ 14,5 dB)

UMTS suff ic ient EcNo for Network-Control led Cel l Reselect ion ,this parameter defines the sufficient Ec/No threshold above whichBSC initiates a “NC cell reselection from GSM/GPRS to UMTS due to

sufficient UMTS coverage”. For FDD cells this attribute is meaningful if the parameter FDD_REP_QUANT is set to Ec/No reporting; for TDD cells it is never used.

USRSCP=8,

object: ADJC3G

unit: 1 dB

range: 0.. 63

0: RSCP < - 115 dBm

1: -115dBm ≤ RSCP < -114dBm... ...

62: -54dBm ≤ RSCP < -53dBm

63: - 53 dBm ≤ RSCP

<NULL>

default: 8

Reference:

UMTS FDD suff ic ient RSCP , this parameter defines the threshold above which BTS initiates a ‘sufficient coverage’ handover (see

parameter EUSCHO in command from GSM to UMTS FDD whenFDDREPQTY (see CREATE BTS [BASICS]) is set to the valueRSCP.





USRSCP=8,

object: ADJC3G

unit: 1 dB

range: 0.. 63

0: RSCP < - 115 dBm

1: -115dBm ≤ RSCP < -114dBm

... ...

62: -54dBm ≤ RSCP < -53dBm

63: - 53 dBm ≤ RSCP<NULL>

default: 8

Reference:

UMTS FDD suff ic ient RSCP for Network -Control led Cel l

Reselect ion , this parameter defines defines the sufficient RSCP threshold above which BSC initiates a “NC cell reselection fromGSM/GPRS due to sufficient UMTS coverage”. For FDD cells thisattribute is meaningful if the parameter FDD_REP_QUANT is set toRSCP reporting; for TDD cells it is always used.





Creating the CCS7 level 3 addresses of BSC, MSC and SMLC and basic SCCPparameters for the SS7 connection:

CREATE OPC [BASICS]:

< This command defines basic CCS7 level 3 addresses and basic SCCP parameters.

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘OPC packages’ were moved below the object OPC and appear in the DBAEM in the CREATE OPC 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=opc:0, Object path name .

APLESSNBSC=250,

object: OPC [BASICS]

range: 15-255

default: 250

SCCP subsystem numb er of Appl icat ion Part BSSAP-LE in BSC ,this parameter defines the Subsystem Number for BSSAP-LE (BaseStation System Application Part - LCS Extension) from the BSC point of view. SCCP subsystems are Application Parts of the SCCP (likee.g. BSSAP, MAPMSC, MAPHLR etc.), which have to be addressed by an own number within the SCCP addressing scheme. For theBSSAP-LE, the SSN is not fixed by the standard and can thus be

selected by command. APLESSNSMLC=252,


range: 15-255

default: 252

SCCP subsystem numb er of Appl icat ion Part BSSAP-LE in

SMLC , this parameter defines the Subsystem Number for BSSAP-LE (Base Station System Application Part - LCS Extension) from theSMLC (Serving Mobile Location Center) point of view. See also

APLESSNBSC. BSSAPSSN=254,


range: 15-255

default: 254

SCCP subs ystem num ber of Appl icat ion Part BSSAP in BSC , this parameter determines which SCCP subsystem number is used for the BSSAP. SCCP subsystems are Application Parts of the SCCP (like e.g. BSSAP, MAPMSC, MAPHLR etc.), which have to beaddressed by an own number within the SCCP addressing scheme.For the BSSAP, the SSN is not fixed by the standard and can thus beselected by command.

MSCPERTFLAG=TRUE,


range: TRUE, FALSE

default: TRUE

Periodic signal ing l ink test f lag for SS7 conn ection to MSC , thisflag determines whether the periodic signaling link test is enabled for the OPC-SPC relation or not. The signaling test procedure for theSS7 link is a CCS7 level 3 availability check of a remote SPC and isbasically performed whenever a remote SPC (which has becomeunavailable due to failure of the SS7 link set) becomes availableagain after the SS7 link set recovery. The signaling test procedureconsists of a SIGNALING LINK TEST MESSAGE (SLTM) which issent from the BSC to the MSC which – in the positive case – answerswith the SIGNALING TEST ACKNOWLEDGE (SLTA) message. If PERTFLAG is set to TRUE, the signaling test procedure is

periodically performed for the OPC-SPC relation. The time period between the transmission of 2 SLTMs is determined by the timer M3T2TM, the supervision timer for the receipt of the SLTA is thetimer M3T1TM (see command SET OPC [MTL3] for further details).

MSCSPC=48-144,


range: see above (OPC)

Signal ing Point Code of MSC , identifies the Signaling Point Code(SPC) of the MSC. For the format please refer to the parameter OPC.

NTWIND=NAT0,


range: INAT0, INAT1,

NAT0, NAT 1 (CCITT)

NAT0 (ANSI)

default: NAT0

Network Indicator , determines the logical network the entered SPCsare valid for. The network indicator is an SS7 level 3 addresssupplement and is always sent together with the SPC in the level 3component of an SS7 message. Within one network, normally all network elements are addressed with one unique SPC valid for NAT0. The other possible values are normally used for network transitions.





OPC=219-48,


range:

Network Cluster Member

0..255 (CCITT)

1-255 (ANSI)

Network Cluster

0..63 (CCITT)

0..255 (ANSI)

Network Identifier

NO_CONFIG (CCITT)

1-254 (ANSI)

Own Signal ing Point Code , identifies the SPC of the BSC. Up toBR4.0 the value of the SPC had to be in entered in decimal format,from BR4.5 on the value of the SPC must be in entered in the format “NetwokClusterMember – NetworkCluster – NetworkIndetifier”. For CCITT the conversion from decimal format to the new format is donein the following way: Convert decimal value to Hex, the 2 least significant digits (converted to decimal) make up the ‘Network Cluster Member’, the 2 most significant bits make up the ‘Network Cluster’.

Example: SPC = 12507 dec = 30DBhex DBhex = 219dec = NetworkClusterMember value30 hex = 48 dec = NetworkCluster valueResult: OPC=219-48

In the MSC the SPC might be entered in structured format.Example for conversion of a structured SPC to the decimal format:

SPC = 12 - 1 - 11 - 3 (structured format)4bit - 3bit - 4bit - 3bit

SPC = 1100 - 001 - 1011 - 011SPC = 11000011011011 (binary format)SPC = 12507 (decimal format)

SMLCPERTFLAG=TRUE,


range: TRUE, FALSE

default: TRUE

Periodic signal ing l ink test f lag for SS7 conn ection to SMLC , thisflag determines whether the periodic signaling link test is enabled for the BSC-SMLC CCS7 connection or not. For further details pleasesee parameter MSCPERTFLAG.

Attention: The Signaling link Test Procedure is only used for the SS7 relation between BSC and SMLC if the SS7 link is created for link set LKSET=1, i.e. if theSS7 connection between BSC and SMLC isrealized via a nailed-up connection (NUC) in the MSC. For further details please refer to the parameter LKSET in command CREATE SS7L.

SMLCSPC=32-112,


range: see above (OPC)

Signal ing Point Code of SMLC , identifies the Signaling Point Code(SPC) of the SMLC (Serving Mobile Location Center). For the format

please refer to the parameter OPC.

SS7MTPTYP=CCITT,


range: CCITT; ANSIdefault: CCITT

SS7 MTP type , determines the type of message transfer part used by the SS7.

TCONN=3,


unit: 5s

range: 0..255

default: 3

Timer for CC , this timer determines the waiting time for theCONNECTION CONFIRM. The CONNECTION CONFIRM is theresponse to the CONNECTION REQUEST, which is used to set up alogical SCCP dialog using so-called ‘local references’ on the A-interface. Such a ‘local reference’ connection is set up for every transaction (call, SMS-transmission, Location Update etc.). The timer TCONN is started when the BSC transmits the CONNECTION REQUEST to the MSC. If it expires, the BSC regards the SCCP local reference connection request as unsuccessful and releases theassociated context.





TGUARD=36,


unit: 5s

range: 0..255

default: 36

(= recommeded value !)

Guard timer for adjacent Signal ing Poin t accessabi l i ty , this parameter is used to supervise the duration of the adjacent signaling point (SP) inaccessibility. This situation occurs if all SS7 linkstowards the MSC have failed. TGUARD sets the waiting time toresume normal procedures for temporary connection sections (i.e.the local reference SCCP and BSSMAP contexts that are set up for each dedicated signaling transaction) during the restart procedure.

TGUARD is started when the adjacent signaling point (e.g. the MSC)becomes inaccessible due to failure of all available SS7 links. Thismeans that TGUARD is started when the last SS7link goes down(SS7S object goes to ‘disabled’ state) and it is stopped when the first link is completely aligned again.If a link interruption is shorter than TGUARD (i.e. at least one SS7 link has successfully completed the re-alignment), busy CICs will not be released, i.e. existing speech connections will be saved and noRESET message will be sent on the A-interface. If the duration of atotal CCS7 link interruption exceeds the time defined by TGUARD,the existing speech connections will be released and after the link realignment a RESET message will be sent on the A-interface. Tosave existing calls for a defined period of SS7-link interruption thetimer values at the BSC and MSC should be equal.

As mentioned above, the BSC starts TGUARD when the last SS7 link goes down, i.e. when the SS7 link set (SS7S) has gone to ‘disabled’ state. As long as TGUARD runs the BSC discards all received CHANNEL REQUIRED messages, i.e. it does not activate any SDCCH and does not answer them by any IMMEDIATE

ASSIGNMENT message.In this period, when the MS has performed MAXRETR+1 RACH access attempts without response from the network it performs a cell reselection. In addition, the MS also increases an internal counter which is increased on every new RACH access attempt. If thecounter reaches a defined threshold, the MS performs a completenetwork reselection (PLMN reselection).When TGUARD has expired (long interruption) the BSC only acceptsand serves new CHANNEL REQUIRED messages when the first

SS7 link set has returned to service and when the GLOBAL RESET procedure is completed.

Notes:- TGUARD must be set according to the following rule:TGUARD > ALARMT2 (CREATE LICD) + TSBSThis setting is necessary in order to avoid A-interface reset (and thuscall release) procedures even if the link interruption is very short. For TSBS please see below.- In order to avoid the loss of existing calls in case of a TDPC switchor a BSMS switch (which causes an initialization of the SS7-link)TGUARD has to be set to a value bigger than 30 seconds. Arecommended value is 50s.- The equivalent of this timer in the SIEMENS MSC are the following timers:

a) in MSC configurations with SSNC HW (new CCS7 HW):Parameter ‘SPAP STFS Timer’ (Signaling Point Short Time FailureTimer) which is administered with the MSC command MOD SPAPLOC (SPAPLOC = SCCP Access Point Local).b) in configurations with (old) CCNC HW:Parameter SPSTFT (Signaling Point Short Time Failure Timer) whichis administered with the MSC command ENTR SCSSSD.

The affected timer (depending on the used CCS7 HW) is started when the remote SP becomes unavailable. As long as the timer runs,the calls are maintained. SPSTFT stopped, when the remote SP becomes available again. If it expires, the MSC releases all calls tothe affected SP (which is in this case the BSC) and performs a





BSSMAP RESET procedure when the SS7 connection has returned to service. Both SPAP STFS Timer and SPSTFT are set in units of 10s an unfortunately their default is ‘0’ (zero). Interworking tests haveestablished that it is recommended to equally set TGUARD and SPAP STFS Timer (respectively SPSTFT) to 180s:TGUARD=36 (BSC) and SPAP STFS Timer =18 (MSC).

TIAR=180,

object: OPC [BASICS]unit: 5s

range: 0..255

default: 180


Inact ivi ty test receive timer , this timer is used to supervise theactivity on an SCCP local reference connection by the INACTIVITY

TEST mechanism. The SCCP connection is released if there are noinactivity test messages received within the TIAR interval. TIAR isstarted when the BSC sends an inactivity test message to the MSC. If TIAR expires (i.e. no inactivity test message has been received fromthe MSC) the BSC sends a BSSMAP RESET CIRCUIT to the MSC.The RESET CIRCUIT message leads to the clearing of the SCCP local reference connection and thus to the release of the associated call.The same timer with the same functionality also exists in the MSC.Note: The following rule should be considered:

TIAR (of the receiving entity) ι 2 ∗ TIAS (of the sending entity)

Important: Please see also the parameter description for TIAS!

TIAS=96,


unit: 5s

range: 0..255

default: 96


Inact ivi ty test send timer , this timer determines the periodicity of thesending of INACTIVITY TEST messages (IT) on an SCCP local reference connection section. The INACTIVITY TEST messages areused to create a kind of 'keep alive' activity on the SCCP local reference connection in time periods without call signaling activity.The same timer (and mechanism) also exists in the MSC. TIAS isrestarted whenever the BSC has received an SCCP message for anexisting SCCP local reference connection. When it expires (i.e. whenno SCCP message has been received during the TIAS runtime), theBSC sends an INACTIVITY TEST to the MSC and TIAS is restarted.Every expiry of TIAS triggers the transmission of another INACTIVITY TEST message. On the MSC side an Inactivity Test Receive Timer (see TIAR) observes the receipt of the INACTIVITY TEST messages.Notes:- Basically the following rule must be considered:

TIAR (of the receiving entity) > 2 ∗ TIAS (of the sending entity)

- After a TDPC switch the timers TIAS and TIAR are reset to ‘0’.Under certain conditions it may happen that no INACTIVITY TEST message is sent towards the MSC for more than 2 times of the TIASinterval. In order to prevent the MSC from releasing the SCCP connections the Inactivity Test Receive Timer of the MSC should bemore than 2 times (better 3 times) as big as the TIAS value of theBSC.- In the Siemens MSC the Inactivity Test Send timer (i.e. theequivalent to TIAS) is called T118 (default value = 7 min) and theInactivity Test Receive Timer (i.e. the equivalent to TIAR) is called T119 (default value = 15 min). Both timers are administered with thecommand MOD TIOUT.

TINT=36,


unit: 5s

range: 0..255

default: 36

TINT , wait to report the abnormal release to the maintenancefunction.





TREL=20,


unit: 0,5s

range: 0..255

default: 20

Release timer , this timer determines the waiting time for RELEASE COMPLETE message. The RELEASE COMPLETE is theconfirmation message for the RELEASED message which is sent if an SCCP connection is cleared down. The timer TREL is started when the BSC transmits the RELEASED message to the MSC (thismessage is used to release the dedicated local reference connectionwhich is set up for every call transaction). If it expires, the BSC

releases the associated context without the receipt of the RELEASE COMPLETE..

TSBS=60,


unit: 0,5s

range: 0..255

default: 60

State inform ation timer . This timer is started by the BSC if after aninterruption of the CCS7 link the lower layers have come up again.On expiry of this timer the BSC sends the SST (SCCP SubsystemTest) towards the MSC and waits for the SSA (SCCP Subsystem

Available) message. With this message the local SCCP (in the BSC)checks the availability of the remote SCCP subsystem BSSAP (in theMSC). The same mechanism is used in the MSC. If the BSC receivesthe SST from the MSC before expiry of TSBS it answers with SSAand immediately sends the SST towards the MSC.Notes:- TSBS must be set according to the following rule:TSBS < TGUARD - ALARMT2 (CREATE LICD)

This setting is necessary in order to avoid A-interface reset (and thuscall release) procedures even if the link interruption is very short.

- The equivalent of this timer in the SIEMENS MSC are the following timers:a) in MSC configurations with SSNC HW (new CCS7 HW):Parameter ‘SCCP STFS Timer’ (SCCP Short Time Failure Timer)which is administered with the MSC command MOD SPAPLOC (SPAPLOC = SCCP Access Point Local).b) in configurations with (old) CCNC HW:Parameter SSSTFT (SCCP Subsystem Short Time Failure Timer)which is administered with the MSC command ENTR SCSSSD.

The affected timer (depending on the used CCS7 HW) is started when the remote SCCP subsystem (i.e. the BSSAP) becomesunavailable. As long as the timer runs, the calls are maintained. TheSCCP STFS Timer (resp. SPSTFT) is stopped, when the remoteSCCP subsystem becomes available again. If it expires, the MSC releases all calls to the affected entity (which is in this case the BSC)and performs a BSSMAP RESET procedure when the SS7 connection has returned to service. Both SCCP STFS Timer and SSSTFT are set in units of 10s an unfortunately their default is ‘0’ (zero). Interworking tests have established that a recommended is toset the SCCP STFS Timer (resp. SPSTFT) to 180s:SCCP STFS Timer (resp. SPSTFT) = 18 (MSC).

TWCUSER=20,


unit: 0,5s

range: 0..255

default: 20

TWCUSER , manufacturer dependent timer.





Setting the timer values for CCS7 MTP level 2:

SET OPC [MTL2]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘OPC packages’ were moved below the object OPC and appear in the DBAEM in the CREATE OPC command. The logical

group “[MTL2]” is normally only used on the LMT but was used hereto allow a more useful grouping of the commands .


CONGTH=0,

object: OPC [MTL2]

unit: 1%

range: 0..6

default: 0

Congestion control threshold , this parameter is used for thedetection of the BSC overload condition ‘SS7 Tx buffer congestion’ (see also parameter BSCOVLH in command SET BSC [BASICS]).The CCS7 level 2 functions feature a flow control and protectionmechanism which orders transmitted level 2 frames by sequencenumbers and buffers them for retransmission, if the receipt of thetransmitted frame was not positively acknowledged from the remoteend (i.e. from the MSC or the SMLC). The SS7 level 2 transmit buffers are physically located in the SS7 level 2 boards, i.e. in thePPXL. The BSC continuously observes the utilization percentage of

the available transmit buffers and compares it to the thresholds that are mapped to the CONGTH value in accordance with the tablebelow:

CONGTH value onset abatment discard

0 (default) 100 95 not used

1 50 45 not used

2 50 45 55

3 35 30 40

4 40 35 45

5 45 40 50

6 50 45 55

When the Tx buffer utilization exceeds the threshold defined by the‘onset’ value, the BSC overload condition ‘SS7 Tx buffer congestion’ is detected and the corresponding alarm ‘BSC overload detected’ with cause value ‘SS7 Tx buffer congestion’ is raised.When the Tx buffer utilization drops below the threshold defined by the ‘abatment’ value, the alarm is ceased.

When the Tx buffer utilization exceeds the threshold defined by the‘discard’ value, level 2 functions start to randomly discard level 2 frames.

The value CONGTH=0 means that the check on SS7 TX buffer congestion is disabled and the mentioned overload condition isdetected only when the SS7 Tx buffer utilization has reached 100%.

Note:The observation of the SS7 receive buffers is performed based on

thresholds defined by parameter FLOWCTH (see above).





ERRCORMTD=BASIC_ERROR_ CORRECTION,

object: OPC [MTL2]

range: BASIC_ERROR_CORRECTION

PREVENTIVE_CYCLIC_

RETRANS_ERR_CORR

default: BASIC_ERROR_CORRECTION

Error correct ion method , this parameter determines the layer-2 error correction principle used on the SS7 links.- The Basic Error Correction method is normally used on all terrestrial CCS7 links. It uses layer 2 acknowledgement mechanisms (based onforward sequence numbers, backward sequence numbers and indicator bits for positive or negative acknowledgements) to decidewhether a CCS7 layer 2 frame was correctly received and to request

a retransmission if a frame was not correctly received.- The Preventive Cyclic Retransmission Error Correction method must be used if the A interface link or the Asub interface link isconfigured as satellite link (see also SET BSC [BASICS], parameters

ASUBISAT and AISAT). As the name suggests, the 'PreventiveCyclic Retransmission Error Correction' method uses a preventivecyclic retransmission mechanism, i.e. sent messages are cyclically retransmitted without waiting for an acknowledgement from the

partner side. Especially for satellite links this method makes sense as- due to the high delay on satellite links - the waiting times for layer 2 acknowledgements are too long to allow a useful use of the basic error correction method.

FLOWCTH=3,

object: OPC [MTL2]

unit: 1%

range: 0..9

default: 3

Flow contro l thresho ld , this parameter determines a threshold for the observation of the CCS7 receive buffer utilization. The BSC continuously observes the utilization percentage of the available SS7 receive buffers and compares it to the thresholds that are mapped tothe FLOWCTH value in accordance with the table below:

FLOWCTH value onset abatment

0 = =

1 60 50

2 65 50

3 (default) 70 50

4 50 40

5 55 40

6 60 40

7 55 45

8 60 45

9 65 45

When the SS7 RX buffer utilization exceeds the ‘onset’ threshold, anLSSU message indicating ‘busy’ (LSSU-SIB) is cyclically sent to theremote end. The sending frequency of this message is determined by the parameter M2T5 (see below).

When the SS7 RX buffer utilization exceeds the ‘abatment’ threshold,the sending of LSSU ‘busy’ messages to the remote end is stopped.

Note: The observation of the SS7 transmit buffers is performed based on thresholds defined by parameter CONGTH (see above). Asopposed to the SS7 Tx buffer congestion detection based on

CONGTH, no alarms are generated in case of SS7 Rx buffer congestion (detected using parameter FLOWCTH).

M2T1=450,

object: OPC [MTL2]

unit: 100ms

range: CCITT: 400..500

ANSI: 129-160

default: CCITT: 450

ANSI: 140

M2T1 , ‘alignment ready’ timer, known as T1_timer_id in the CCITT blue book.





M2T2=100,

object: OPC [MTL2]

unit: 100ms


ANSI: 50..300

default: CCITT: 100

ANSI: 100


M2T2 , ‘not aligned’ timer, known as T2_timer_id in the CCITT bluebook.

M2T3=10,

object: OPC [MTL2]

unit: 100ms


ANSI: 50..140

default: CCITT: 10

ANSI: 120

M2T3 , ‘aligned’ timer, known as T3_timer_id in the CCITT blue book.

M2T4E=5,

object: OPC [MTL2]

unit: 100ms

range: CCITT: 4-5ANSI: 4-7

default: CCITT: 5

ANSI: 6

M2T4E , emergency proving period timer, known as T4e timer in theCCITT/ITU book.

M2T4N=80,

object: OPC [MTL2]

unit: 100ms

range: CCITT: 75-95

ANSI: 15-30

default: CCITT: 80

ANSI: 24

M2T4N , normal proving period timer, known as T4n timer in theCCITT/ITU book.

M2T5=1,

object: OPC [MTL2]

unit: 100msrange: 1-2

default: 1

M2T5 , SIB sending timer, known as T5_timer_id in the CCITT bluebook.

Please see also parameter FLOWCTH (see above).

M2T6=60,

object: OPC [MTL2]

unit: 100ms


ANSI: 10..60

default: CCITT: 60

ANSI: 50

M2T6 , remote congestion timer, known as T6_timer_id in the CCITT blue book.

M2T7=20,

object: OPC [MTL2]

unit: 100ms

range: CCITT: 5-20ANSI: 5-20

default: CCITT: 20

ANSI: 10

M2T7 , excessive delay of acknowledgement timer, known asT7_timer_id in the CCITT blue book.

N1 =110,

object: OPC [MTL2]

range: 100..127

default: 110

Maximum n umb er of MSU avai lable for retransmiss ion , this parameter determines the maximum number of SS7 message signal units (MSU), that can be buffered for retransmission.





N2 =3000,

object: OPC [MTL2]

range: 2000..4000

default: 3000

Maximum n umb er of MSU octets avai lable for retransm ission ,this parameter determines the maximum number SS7 MSU octetsthat can be buffered for retransmission.

SANTIME=10,

object: OPC [MTL2]range: 0..255

0 = timer disabled

default: 10

Sanity t imer, this parameter determines the value of the sanity timer used to control the level 2 processor (PPXL) outage. SANTIME

represents a keep alive time between TDPC and PPXL. If this timer isset to 0 (disabled), no “keep-alive” is performed. If SANTIME is set toa value different from 0, the PPXL expect a keep alive messagewithin this time frame. If the PPXL does not receive it, a LOCALPROCESSOR OUTAGE (LPO) is sent on layer 2 to the remote end (i.e. the MSC) in order to stop the traffic. This timer does not affect the call processing activity, is just used to inform the MSC very fast inabout failure of the layer 3 processor unit (i.e. the TDPC).

Setting the timer values for CCS7 MTP level 3:

SET OPC [MTL3]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘OPC packages’ were moved below the object OPC and appear in the DBAEM in the CREATE OPC command. The logical group “[MTL3]” is normally only used on the LMT but was used hereto allow a more useful grouping of the commands .


M3T1=9,

object: OPC [MTL3]

unit: 100ms

range: 5-12

default: 9

M3T1 , delay to avoid the out-of-sequence of messages on CO(CO = changeover of links in case of link failure or blocking), knownas T1_timer in the CCITT blue book.

M3T10=60,

object: OPC [MTL3]

unit: 0,5 s

range: 60..120

default: 60

M3T10 , this timer represents the waiting time to repeat the ROUTE SET TEST (RST) message. These messages are used by the CCS7 level 3 functions to periodically check the availability of CCS7 signaling routes.

General Background:Within the SSS, all SPCs are normally reachable via different “signaling routes”. These “signaling routes” are explicitly created inthe CCS7 routing database for each relation of local SPC (OPC) and remote SPC and are represented by so-called “signaling link sets” todirectly adjacent CCS7 signaling points (SP, i.e. network elementswith CCS7 routing capability). If the adjacent signaling point represents the final target signaling point of the OPC-SPC relation,the adjacent signaling point is simultaneously the “Signaling End Point” (SEP). If the adjacent signaling point just represents an

intermediate signaling point on the way to the destination SP, it worksas a “Signaling Transfer Point (STP)”. The STP just checks thedestination address of the CCS7 message and forwards themessage to the correct SEP respectively another intermediate STP via a signaling route defined in its own routing tables.

Application in the BSC:The only application of a “signaling route” from point of view of theBSC is the CCS7 connection towards the SMLC (Serving MobileLocation Center). This connection can be configured either via anailed-up connection (NUC) through the MSC or by configuring theMSC as an STP. Only in the latter case





- the appropriate routing tables have to be created in the MSC - the ROUTE SET TEST (RST) messages are sent to check the routeavailability and - the timer M3T10 is considered at all.

For further details concerning the possible configurations of the BSC-SMLC signaling connection please refer to the parameter LKSET inthe command CREATE SS7L..

M3T12=12,

object: OPC [MTL3]

unit: 100ms

range: 8-15

default: CCITT: 12, ANSI: 10

M3T12 , wait for UNINHIBIT acknowledgement, known as T12_timer in the CCITT blue book.

M3T13=8,

object: OPC [MTL3]

unit: 100ms

range: 8-15


M3T13 , wait to force UNINHIBIT, known as T13_timer in the CCITT blue book.

M3T14=4,

object: OPC [MTL3]

unit: 100msrange: 20..30


M3T14 , wait for INHIBIT acknowledgement, known as T14_timer inthe CCITT blue book.

M3T17=10,

object: OPC [MTL3]

unit: 100ms

range: 8-15

default: 10

M3T17 , delay to avoid oscillation of the initial alignment, known asT17_timer in the CCITT blue book.

M3T19=9,

object: OPC [MTL3]

unit: 5s

range: 12-120

default: CCITT: 12

M3T19 , Failed link craft referral timer , this timer is activated during the SS7L restoration phase and controls the disabled state of theSS7L. M3T19 was introduced to avoid a lot of SS7 ENABLE/DISABLE messages towards the RC. If the SS7 link interruption is less than M3T19, no notification is sent to the RC (incase of multiple link configurations with at least one link still working,no call handling is affected), if the interruption is longer than T19, theRC is informed and for call handling the behaviour is the same asbefore. Normally the expiry of M3T19 is caused by a layer 2 problemon the remote end. PCM interruptions or HW fault cause “ disabledependency “ on the SS7 link. In this case M3T19 is not started. Upto BR4.0 this timer was implemented in the system with hardcoded values.

M3T1TM=100,

object: OPC [MTL3]

unit: 100ms

range: 40..120

default: CCITT:100, ANSI:50

M3T1M , Supervision timer for SIGNALING LINK TEST ACKNOWLEDGMENT (SLTA) message. This timer controls thesignaling link test procedure on the SS7 link (see parameter MSCPERTFLAG in command CREATE OPC [BASICS]). M3T1TM isstarted when the BSC transmits the SLTM to the BSC. If the SLTA isnot received before expiry of M3T1TM the BSC restarts the test link

procedure. If the M3T1TM expires for two consecutive times theSS7L restoration procedure is started. Up to BR4.0 this timer wasimplemented in the system with hardcoded values.

M3T2=13,

object: OPC [MTL3]

unit: 100ms

range: 7-20


M3T2 , wait for CO acknowledgement, known as T2_timer in theCCITT blue book.





M3T22OR20=36,

object: OPC [MTL3]

unit: 5s

range: CCITT: 36-72

ANSI: 18-24


M3T22OR20 , Local INHIBIT test timer. This timer (T22 for CCITT or T20 for ANSI) controls the local INHIBIT test procedure. If the SS7Lis local inhibited a local INHIBIT test is sent to the MSC every M3T22OR20 seconds. Up to BR4.0 this timer was called M3T22.

M3T23OR21=36,

object: OPC [MTL3]

unit: 5s

range: CCITT: 36-72

ANSI: 18-24


M3T23OR21 , Remote INHIBIT test timer. This timer (T23 for CCITT or T21 for ANSI) controls the remote INHIBIT test procedure. If theSS7L is remote inhibited a remote INHIBIT test is sent to the MSC every M3T23OR21 time. Up to BR4.0 this timer was called M3T23.

M3T2TM=6,

object: OPC [MTL3]

unit: 5s

range: 6-18

default: CCITT: 6, ANSI:17

M3T2TM , timer for periodic sending of the signaling link test message(SLTM). This timer determines the time period between thetransmission of 2 consecutive SLTMs during the periodic signaling link test procedure on the SS7 link (see parameter MSCPERTFLAGin command CREATE OPC [BASICS]). Whenever M3T2TM expiresthe BSC sends an SLTM to the MSC. Up to BR4.0 this timer wasimplemented in the system with hardcoded values.

M3T3=9,

object: OPC [MTL3]

unit: 100ms

range: 5-12

default: 9

M3T3 , diversion delay controlled by a timer, known as T3_timer in theCCITT blue book.

M3T4=8,

object: OPC [MTL3]

unit: 100ms

range: 5-12

default: 8

M3T4 , wait for CB acknowledgement first attempt (CB = CHANGEBACK to original link after link failure or blocking end), known as T4_timer in the CCITT blue book.

M3T5=8,

object: OPC [MTL3]

unit: 100msrange: 5-12

default: 8

M3T5 , wait for CB acknowledgement second attempt, known asT5_timer in the CCITT blue book.





Creating the CCS7 link:

CREATE SS7L:

NAME=SS7L:0, Object path name .

LNKA=<NULL>,

object: SS7L

range: ppcc-no.: 0..1

port-no.: 0..3

<NULL>

Link access , up to BR7.0, this parameter used to describe the

physical port of the SS7L link at the PPCC , ppcc-no. - port-no..If NTWCARD=NTWSNAP then LNKA must have the value <NULL>.

As in BR8.0 NTWSN16 and PPCC is no longer supported, this is theonly allowed value.

LKSET=0,

object: SS7L

range: 0, 1

L ink set number , this parameter defines the link set number of thecreated SS7 link. A link set with LKSET=1 only has to be created if the signaling connection to the SMLC (Serving Mobile LocationCenter) is realized via a nailed-up connection (NUC) in the MSC. Inthis case link set 1 represents the object superordinate to the SS7Lobject created for the SMLC connection. The link set number determines the association of the created CCS7 link to one of the two

possible link sets as illustrated in the following example diagrams

The example configuration 2 assumes that the MSC works as CCS7 Signaling Transfer Point (STP). As a precondition, the corresponding CCS7 routing tables must have been created in the MSC. For further hints please see also command CREATE OPC [BASICS].

SLC=0,

object: SS7L

range: 0..15

Signal ing Link Code , defines the number of the link on the Ainterface.

TSLA=0..16,

object: SS7L

range: pcma-no.: 0..39


1-24 (PCM24)

Link on th e A interface , pcma-no. - timeslot-no..

SMLC

LKSET=1 SS7L:2

BSSAP-LEsignaling

SMLC<->BSC

LKSET=0 SS7L:0SS7L:1

BSSAP

signaling BSC<->MSC

MSCNUC

BSC

Example Configuration 1:

SS7L to SMLC via NUC in MSC

Example Configuration 2:

SS7L to SMLC via MSC, MSC works as STP

SMLC

LKSET=0 SS7L:0SS7L:1

BSSAP signaling

BSC<->MSCand

BSSAP-LE

signaling SMLC-BSC

MSC

CCS7 STP routing

BSC

CCNC





Creating a Nailed-Up Connection through the BSC/TRAU:

< This command is used to create a permanently switched connection between two timeslots on PCM links connected to theBSS. These permanently connected timeslots can be located on aPCMA, a PCMS or a PCMB. Thus the SBS network elements BSC and TRAU can assume the function of a crossconnector (DXC). >

CREATE NUC:

NAME=nuc:0, Object path name .

FRTERM=PCMA:3-3,

object: NUC

format: <pcm-link>-<timeslot no.>

The ‘pcm-link’ is entered

by the object instance name

of the PCMA, PCMS or

PCMB object

range: pcm-link:

PCMA:0.. PCMA:79 or

PCMB:0.. PCMB:34 or

PCMS:0.. PCMS:19

timeslot-no.:0..31 (for PCM30)

1-24 (for PCM24)

From terminal , determines the first timeslot to be interconnected by the nailed-up connection.

TOTERM=PCMB:4-17,

object: NUC

format: <pcm-link>-<timeslot no.>

The ‘pcm-link’ is entered

by the object instance name

of the PCMA, PCMS or

PCMB object

range: pcm-link:

PCMA:0.. PCMA:79 or

PCMB:0.. PCMB:34 or

PCMS:0.. PCMS:19

timeslot-no.:

0..31 (for PCM30)1-24 (for PCM24)

To terminal , determines the second timeslot to be interconnected by the nailed-up connection.





Creating an X25 connection via dedicated link:

< Note: The objects X25D and X25A are mutually exclusive. i.e either an X25A is created or an X25D. >

CREATE X25D:

NAME=X25D:0, Object path name . The range for the X25D-no. is 0..1 .

BAUDRATE=BAUD_64000,

object: X25D

range: BAUD_4800, BAUD_9600,

BAUD_38400,

BAUD_64000

default: BAUD_64000

Baud rate of communication between RC and BSS.It is necessary with CLOCK=INTERNAL. If CLOCK=EXTERNAL the

parameter is not relevant.

CLOCK=EXTERNAL,

object: X25D

range: INTERNAL,

EXTERNAL

default: EXTERNAL

Clock synchron iz ing m odal ity , indicates if the IXLT internal clock isused or a external one.

DTEDCE=DTE,

object: X25D

range: DTE, DCE

default: DTE

Data terminal equipment/data commun ication equipment ,determines whether the BSC is configured as DTE or as DCE.

L2WIN=7,

object: X25D

range: 1-7

default: 7

Layer 2 windo w size .

L3PS=PACKET_2048,

object: X25D

range: PACKET_128, _256, _512,

_1024, _2048

default: PACKET_2048

Network layer packet size .

L3WIN=7,

object: X25D

range: 1-7

default: 7


LCN2WC=1,

object: X25D

range: 0..4095

default: 1

Line circui t num ber of 1st 2-way channel .

N2WC=6,

object: X25D


Numb er of 2 way channels , this parameter is included in the X25Aand X25D configuration message (IXLT restart).





R20=3,

object: X25D

range: 1-255

default: 3

Restart request retry cou nt .

R22=3,

object: X25Drange: 1-255

default: 3

Reset request retry cou nt .

R23=3,

object: X25D

range: 1-255

default: 3

Clear request retry cou nt .

RETRY=8,

object: X25D

range: 1-254

default: 8

Retry number .

T1=80,

object: X25D

unit: 100ms

range: 1-3000

default: 80

Timer T1 .

T20=1800,

object: X25D

unit: 100ms

range: 0..3000

default: 1800

Restart request t imeou t .

T21=2000,

object: X25D

unit: 100ms


Cal l request t im eout .

T22=1800,

object: X25D

unit: 100ms

range: 0..3000

default: 1800

Reset request t im eout .

T23=1800,

object: X25D

unit: 100ms

range: 0..3000

default: 1800

Clear request t im eout .

T26=1800,

object: X25D

unit: 100ms

range: 0..3000

default: 1800

Interrupt request t imeout .

T28=0,

object: X25D

unit: 100ms

range: 0..3000

default: 0

Registrat ion request t imeout .





T4=200,

object: X25D

unit: 100ms

range: 0..9000

default: 200

Timer T4 .

Rule: T4 ≥ T1∗ 2

TRACE=””,

object: X25D

range: alphanumeric string of

10 characters

default: parameter skipped

Debugging coded str ing .

Creating an X25 connection via A-interface:

< Note: The objects X25D and X25A are mutually exclusive. i.e either an X25A is created or an X25D >.

CREATE X25A:

NAME=X25A:0, Object path name . The range for the X25A-no. is 0..1 .

ACHAN=0..30,

object: X25A

range: pcma-no.: 0..79


1-24 (PCM24)

A interface channel , identifies the timeslot on the A interface used for the RC connection.Parameter format: pcma-no. - timeslot-no..

L2WIN=7,

object: X25A

range: 1-7

default: 7


L3PS=PACKET_2048,

object: X25A

range: PACKET_128, _256, _512,

_1024, _2048

default: PACKET_2048

Network layer packet size .

L3WIN=7,

object: X25A

range: 1-7

default: 7


LCN2WC=1,

object: X25A

range: 0..4095

default: 1

Line circui t num ber of 1st 2-way channel .

N2WC=,

object: X25A

range: 0..4095

default: 6

Numb er of 2 way channels , this parameter is included in the X25Aand X25D configuration message (IXLT restart).





R20=3,

object: X25A

range: 1-255

default: 3

Restart request retry cou nt .

R22=3,

object: X25Arange: 1-255

default: 3

Reset request retry cou nt .

R23=3,

object: X25A

range: 1-255

default: 3

Clear request retry cou nt .

RETRY=10,

object: X25A

range: 1-254

default: 10

Retry number .

T1=150,

object: X25A

unit: 100ms

range: 1-3000

default: 150

Timer T1 .

T20=1800,

object: X25A

unit: 100ms

range: 0..3000

default: 1800

Restart request t imeou t .

T21=2000,

object: X25A

unit: 100ms


Cal l request t im eout .

T22=1800,

object: X25A

unit: 100ms

range: 0..3000

default: 1800

Reset request t im eout .

T23=1800,

object: X25A

unit: 100ms

range: 0..3000

default: 1800

Clear request t im eout .

T26=1800,

object: X25A

unit: 100ms

range: 0..3000

default: 1800

Interrupt request t imeout .

T28=0,

object: X25A

unit: 100ms

range: 0..3000

default: 0

Registrat ion request t imeout .





T4=650,

object: X25A

unit: 100ms

range: 0..9000

default: 650

Timer T4 .

Rule: T4 ≥ T1∗ 3

(TRACE=TRACE),

object: X25A

range: alphanumeric string of

10 characters

default: parameter skipped

Debugging coded str ing .

Creating an IP Link connection:

< The IPLI functional object represents the IP link which may optionally be used as the layer 1 base for the communicationbetween the BSC and RC (OMAL) or between BSC and CBC (CBCL)as an aöternative to the X25 connection. >

CREATE IPLI:NAME=IPLI:0, Object path name . The range for the X25D-no. is 0..0 .

GATEWAY0=<NULL>,

object: IPLI

range: 0..15 character string,

<NULL>

default: <NULL>

Gateway 0 , this parameter is the IP address of the default gateway connected to the MPCC copy 0. It is present only if either the RC or the CBC (or both) does not belong to the same IP sub-network of theBSC.


GATEWAY1=<NULL>,

object: IPLI

range: 0..15 character string,

<NULL>

default: <NULL>

Gateway 1 , this parameter is the IP address of the default gateway connected to the MPCC copy 1. It is present only if either the RC or the CBC (or both) does not belong to the same IP sub-network of theBSC.


PRIMARYIPADDR=255.255.255.255,

object: IPLI

range: 7..15 character string

Primary IP address , this parameter is the IP address assigned tothe ‘poviding service’ MPCC port. The RC and CBC always use thisaddress when calling the BSC.


SECONDARYIPADDR=255.255.255.255,

object: IPLI


Secondary IP address , this parameter is Ip address that is assigned to the ‘standby’ MPCC port. The RC and CBC will never use thisaddress when calling the BSC. It will be used in order to perform the

periodical Ip link test.


SUBNETMASK=255.255.255.255,

object: IPLI


Subnet mask , this parameter is the NetMask that is assigned to boththe MPCC portcopies. The value must be assigned according to thelocal LAN configuration.The convention used for this value is the dotted decimal format (e.g.“172.31.21.88”).





Creating the O&M link for the RC connection:

CREATE OMAL:

NAME=OMAL:0, Object path name . The range for the OMAL-no. is 0..1 .

LINKTYPE=X25D,

object: OMAL

range: X25A, X25D

default: X25D

X25 link typ e , indicates whether the X25 link is realized viadedicated link (X25D) or via an A-interface channel (X25A).

OMCCPT=60,

object: OMAL

range: 1..60

default: 60

OMC capabi l i ty t imer , this parameter represents the time period of the reachability test performed by RC on the "cold standby" OMAL.

X121ADDR="514501",

object: OMAL

range: numeric string

(max.33 characters)

in quotation marks

X121 addr ess , determines the remote X121 address used in the X25 network.

Creating the link for the external connection to the SMS-CB system:

CREATE CBCL:

NAME=CBCL:0, , Object path name . The range for the CBCL-no. is 0..1 .

LINKTYPE=X25D,

object: CBCL

range: X25A, X25D

default: X25D

X25 link typ e , indicates whether the X25 link is realized viadedicated link (X25D) or via an A-interface channel (X25A).

X121ADDR="514501",

object: CBCL

range: numeric string

(max.33 characters)

in quotation marks

X121 addr ess , determines the remote X121 address used in the X25 network.

Defining the BSC reference synchronization clock origin:

CREATE SYNC: < SYNC = synchronization clock >

NAME=sync:0, Object path name .PCMSOBJ=0,

object: SYNC

range: 0..19

PCMS object , identifies the number of the PCMS link from which thereference clock signal is retrieved.





Defining an external synchronization signal:

< It is possible to synchronize the GERAN BSS from asynchronization network, e.g. from GPS system. The command CREATE SYNE is used to create an external synchronization sourcewhich may be connected to the BSC clock by the operator. Theexternal synchronization source has higher priority than SYNC synchronization source. The external synchronization signal isdirectly connected to one of the two external input accesses of thePLLH card, which is represented by the W26 connector on the top of theBSC rack, which is a SUB-D 15 female connector provided for synchronization purposes.The connection shall be performed according device configuration by coaxial or balanced lines between

position W26 and the Installation Site termination.The synchronization signal is recommended in ITU-T G703, chapter 13. Before the external synchronization signal can be used, theSYNE object must be configured. >

CREATE SYNE: < SYNE = external synchronization source >

NAME=syne:0, Object path name , object range : 0..1.





Creating the Quality of Service Alarm Objects:

< The feature ‘Quality of Service Alarms’ was introduced in BR8.0 toallow a close an immediate supervision of the current network

performance by alarms that are based on important Key PerformnceIndicators (KPI), such as the ‘Call drop rate’, ‘Handover success rate’ etc.. In releases before BR8.0 these KPIs could only be calculated inthe framework of PM data postprocessing and thus only allowed thedetection of problematic performance areas with a considerabledelay. With the feature ‘QoS alarms’, the supervision of the KPIs iscontinuously done within the system during operation. For this, thesame internal counters which are used for the known PerformanceMeasurement Counters are continuously scanned and the BSC continuously calculates the current KPI values based on thesecounters for definable supervision periods (see parameter SUPPER in the CREATE QSMONxxx commands). When the calculated KPI values exceed particular defined thresholds for the affected KPI, theBSC generates an alarm which makes the operator immediately aware of performance figures which are not within the desired scope.The generated alarms can have the severity ‘minor’ or ‘major’,depending on the value of the calculated KPI and the configured alarm threshold. If a ‘minor’ QoS alarm for a particular object and KPI combination is already active, when the conditions for a ‘major’ alarmare fulfilled, the ‘minor’ alarm is cleared when the ‘major’ alarm israised.

The KPIs to be observed during operation are administered indifferent database objects for KPIs calculated - per BSC (object QSMONBSC)- per BTS (object QSMONBTS) and - per PTPPKF (object QSMONGPRS).

Different thresholds can be configured for ‘minor’ and ‘major’ alarmsfor each KPI and the thresholds can be dynamically adapted depending on the amount of the counted events (‘number of samples’) on which the KPI calculation is based - in other words, thethresholds can be configured in such a way that for less reliable KPI calculation results (due to a small number of samples / counts of theaffected events) the system uses more ‘defensive’ threshold values,while for reliable KPI calculation results (i.e. when the calculated KPI value is based on a sufficiently high number of event counts) realistic or more ‘aggressive’ thresholds are applied.

These settings are defined using the database object QSTHRS.

Note: The QoS alarms are only raised if the KPI value really exceedsthe defined threshold. If the KPI just reaches the threshold valuewithout exceeding it, the QoS alarm is not raised. >

number of samples

N u m S a m p l e s # 3

- 1 0 %


- 1 0 %


- 1 0 %

ThirdThresholdSet

FirstThresholdSet

SecondThresholdSet

no alarms





Creating the Quality of Service Alarm threshold sets:

< The QSTHRS object defines the threshold sets that can beallocated to the KPIs defined with the QSMONBSC, QSMONBTS and QSMONGPRS objects. In other words, if a particular KPI is to beobserved by QoS alarms, the corresponding parameter with theaforementioned database objects which represents a particular KPI will contain the reference to a created QoS alarm threshold set. For further examples, please see the CREATE QSMONxxx command descriptions below. >

CREATE QSTHRS:

NAME=BSC:0/QSTHRS:0,

Object path name , object range 0..49, i.e. up to 50 QSTHRS objects(i.e. 50 sets of QoS alarm thresholds) can be defined.

THRS1=1000-98-92-95-85-2,

object: QSTHRS

format: 6 fields

no. of samples -

- threshold major high

- threshold major low

- threshold minor high

- threshold minor low

- no. of periodsrange: numberOfSamples: 0..65535

thresholdMajorHigh 0..100 (%)

thresholdMajorLow 0..100 (%)

thresholdMinorHigh 0..100 (%)

thresholdMinorLow 0..100 (%)

numberOfPeriods 1..12

<NULL>

default: <NULL>

Threshold set 1 , this parameter defines the first threshold set for theQSTHRS object based on a particular ‘number of samples’ value.

Each threshold set consists of 6 fields:

1) Numb er of Samples specifies the number of relevant samples that have been counted within the supervision period (see parameter SUPPER in command CREATE QSMONxxx). The number of relevant samples correspondsto the denominator in the KPI formula (Example: the number of samples for the QoS indicator ‘TCH Drop Rate’ (see parameter TCHDROR in object QSMONBTS) represents the number of successful TCH seizures).

2) Threshold Major High specifies the ‘high’ alarm threshold for the QoS alarm with severity ‘major’. In other words: when the calculated KPI value exceeds thisthreshold for as many supervision periods as defined by ‘number of

periods’ (see (6)), the major QoS alarm is raised.

3) Threshold Major Low specifies the ’low’ alarm threshold for the QoS alarm with severity ‘major’. In other words: when the calculated KPI value drops below this threshold for as many supervision periods as defined by ‘number of periods (see (6)), the major QoS alarm is ceased.

4) Threshold Minor High specifies the ’high’ alarm threshold for the QoS alarm with severity ‘minor’. In other words: when the calculated KPI value exceeds thisthreshold for as many supervision periods as defined by ‘number of

periods (see (6)), the minor QoS alarm is raised.

5) Threshold Minor Low

specifies the ’low’ alarm threshold for the QoS alarm with severity ‘minor’. In other words: when the calculated KPI value drops below this threshold for as many supervision periods as defined by ‘number of periods (see (6)), the minor QoS alarm is ceased.

6) Number of Periods





specifies the number of supervision periods (see parameter SUPPER in commands CREATE QSMONxxx) in which the condition for thealarm to be raised or ceased must be present. In other words, only when the alarm condition is present for as many periods as indicated by ‘number of periods, the alarm is raised; only when the ‘alarmceased’ condition is present for as many periods as indicated by ‘number of periods’, the alarm is ceased / cleared (see examplediagram below, with ‘Number of periods’=2).

Remark: Active alarms are also ceased if the ‘number of samples’ was not reached in as many consecutive supervision periods asdefined by ‘number of periods’.

THRS2=<NULL>,

object: QSTHRS

format: see THRS1

range: see THRS1

default: <NULL>

Threshold set 2 , this parameter defines the second threshold set for

the QSTHRS object based on a particular ‘number of samples’ value.

Format, range and meaning of the fields are the same like for THRS1(see above).

The possibility to define different thresholds for different ‘number of samples’ values was implemented to allow a dynamic adaptation of the thresholds to the reliability of the calculated KPI figures - in other words, the thresholds can be configured in such a way that for lessreliable KPI calculation results (due to a small number of samples)the system uses more ‘defensive’ threshold values, while for reliableKPI calculation results (i.e. when the calculated KPI value is based on a sufficiently high number of event counts) realistic or more‘aggressive’ thresholds are applied.

THRS3=<NULL>,

object: QSTHRS

format: see THRS1

range: see THRS1

default: <NULL>

Threshold set 3 , this parameter defines the thirs threshold set for

the QSTHRS object based on a particular ‘number of samples’ value. Format, range and meaning of the fields are the same like for THRS1(see above).

For further details please refer to the parameters THRS1 and THRS2 (see above).





Creating the Quality of Service Alarm Objects for the BSC object:

CREATE QSMONBSC:

NAME=BSC:0/QSMONBSC:0,

Object path name .

PCUPRCSLD=BSC:0/ QSTHRS:0,

object: QSMONBSC

range: object path name of relevant

QSTHR object instance,

<NULL>

default: <NULL>

PCU processor load , this parameter indicates, when its value isdifferent from <NULL>, that the KPI ‘PCU Processor Load’ is

observed for the feature ‘Quality of service alarms’. The valueentered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI.

The observed KPI ‘PCU Processor Load’ is based on thePerformance Measurement Counter BSCPRCLD and calculated asfollows:

PCU Processor Load = BSCPRCLDmax [subcounters 31..42]

BSCPRCLDmax indicates the highest processor load that occurred within the supervision period (corresponds to ‘max total time’).

For further details concerning the involved PM counters please refer to the customer document ‘PM:SBS Counter’.

For this KPI the ‘number of samples’ portion which is defined in the

QSTHRS object addressed by this parameter is not relevant - this isdue to the fact that in this KPI formula no denominator exists which isnormally used as reference for the ‘number of samples’.

SUPPER=MINUTES_5,

object: QSMONBSC

range: MINUTES_5

MINUTES_10

MINUTES_15

default: MINUTES_5

Supervision per iod , this parameter defines the supervision period for the KPI calculation for the QoS alarms feature.During the supervision period, the BSC accumulates the counter values that are necessary for the calculation of the KPIs. When thesupervision period ends, the BSC calculates the KPI values based onthe accumulated counter results and triggers the output, clearance or maintenance of the QoS alarm, depending on the calculated KPI result value, the relevant configured threshold value and the relevant value of ‘number of periods (see command CREATE QSTHR).

TDPCPRCSLD=BSC:0/ QSTHRS:0,

object: QSMONBSC



<NULL>

default: <NULL>

TDPC processor load , this parameter indicates, when its value isdifferent from <NULL>, that the KPI ‘TDPC Processor Load’ is


The observed KPI ‘TDPC Processor Load’ is based on thePerformance Measurement Counter BSCPRCLD and calculated asfollows:

TDPC Processor Load = BSCPRCLDmax [subcounter 30]

BSCPRCLDmax indicates the highest processor load that occurred within the supervision period (corresponds to ‘max total time’).


For this KPI the ‘number of samples’ portion which is defined in the

QSTHRS object addressed by this parameter is not relevant - this isdue to the fact that in this KPI formula no denominator exists which isnormally used as reference for the ‘number of samples’.





Creating the Quality of Service Alarm Objects for BTS objects:

CREATE QSMONBTS:

NAME=BSC:0/QSMONBTS:0,

Object path name .

ASSFAIR=BSC:0/QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

Assig nment Fai lure Rate , this parameter indicates, when its valueis different from <NULL>, that the KPI ’Assignment Failure Rate’ is


The observed KPI ’Assignment Failure Rate’ calculation formula isbased on the Performance Measurement Counters TASATT,TASSFAIL, NCLRREQ and calculated as follows:

%100*3]TASSATT[2,

2] NRCLRREQ[215],..8,10..13TASSFAIL[6 +=e AssFailRat

For this KPI the ‘number of samples’ value in the referenced QSTHRS object corresponds to the denominator of the calculationformula:

Number of samples =TASSATT [2,3] For further details concerning the involved PM counters please refer to the customer document ‘PM:SBS Counter’.

CLSETFAIR=BSC:0/ QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

Call Setup Failure Rate , this parameter indicates, when its value isdifferent from <NULL>, that the KPI ’Call Setup Failure Rate’ isobserved for the feature ‘Quality of service alarms’. The valueentered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI.

The observed KPI ’Call Setup Failure Rate’ calculation formula isbased on the KPIs ‘Immediate Assignment Failure Rate’, ‘SDCCH Drop Rate’ and ‘Assignment Failure Rate’ which are in turn based numerous Performance Measurement Counters (for further detailsabout the calculation of these KPIS please refer to the parameters

IMMASSFAIR, SDCCHDROR and ASSFAIR).

For this KPI the ‘number of samples’ value in the referenced QSTHRS object corresponds to the number of successful SDCCH activations with successful seizure:

Number of samples = NSUCCHPC[1..4, 9..12, 17..20]


%100*))100

1(*)100

1(*)100

Im1(1(

e AssFailRat ateSDCCHDropRtemAssFAilRaailRateCallSetupF −−−−=





HANDROR=BSC:0/ QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

Handover Drop Rate , this parameter indicates, when its value isdifferent from <NULL>, that the KPI ’Handover Drop Rate’ isobserved for the feature ‘Quality of service alarms’. The valueentered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI.

The observed KPI ’Handover Drop Rate’ calculation formula is based

on the total amount of handover attempts and the total amount of handover drops which are in turn based numerous PerformanceMeasurement Counters as listed below:

%100*HoAtt

HoDrops= HoDropRate

where the parameters ‘HoDrops’ and ‘HoAtt’ are calculated by using the following formulas:

HoDrops = UNIHIALC[1] + UNIHIRLC[1] + ATINBHDO[all] - SUINBHDO[all]- NRUNINHD[all] + ATOISHDO[all] - SUOISHDO[all] - UNOISHDO[all]

HoAtt = ATINHIAC[all] + ATINHIRC[all] + ATINBHDO[all] + ATOISHDO[all]

In case of HoAtt = 0, HODropRate is set to 0.

For this KPI the ‘number of samples’ value in the referenced QSTHRS object corresponds to the denominator of the calculationformula:Number of samples = HoAtt


HANFAIR=BSC:0/QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

Handover Fai lure Rate , this parameter indicates, when its value isdifferent from <NULL>, that the KPI ’Handover Failure Rate’ isobserved for the feature ‘Quality of service alarms’. The valueentered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI.

The observed KPI ’Handover Failure Rate’ calculation formula isbased on the total amount of handover attempts and the total amount

of handover failures which are in turn based numerous PerformanceMeasurement Counters as listed below:

%100*HoAtt

HoFails= HoFailRate

where the parameters HoFails and HoAtt are calculated by using thefollowing formulas:

HOFails = UNINHOIA[all]+UNINHOIE[all]+NRUNINHD[all]+UNOISHDO[all]

HOAtt = ATINHIAC[all] + ATINHIRC[all] + ATINBHDO[all] + ATOISHDO[all]

In case of HoAtt = 0, HoFailRate is set to 0.


Number of samples = HoAtt






IMMASSFAIR=BSC:0/ QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

Immediate Assignm ent Fai lure Rate , this parameter indicates,when its value is different from <NULL>, that the KPI ’Immediate

Assignment Failure Rate’ is observed for the feature ‘Quality of service alarms’. The value entered for this parameter is the object

path name of the threshold set (command CREATE QSTHR, seeabove) that is to be used for this KPI.

The observed KPI ’Immediate Assignment Failure Rate’ calculation

formula is based on the Performance Measurement Counters ATIMASCA, NSUCCHPC as indicated below:

%100*ll]ATIMASCA[a

17..22]9..14,..6, NSUCCHPC[1-ll]ATIMASCA[atemAssFailRaIm =

In case of ATIMASCA[all] = 0 the ImmAssFailRate is set to 0.


Number of samples = ATIMASCA[all]


SDCCHDROR=BSC:0/ QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

SDCCH Drop Rate , this parameter indicates, when its value isdifferent from <NULL>, that the KPI ‘SDCCH Drop Rate’ is observed for the feature ‘Quality of service alarms’. The value entered for this

parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI.

The observed KPI ‘SDCCH Drop Rate’ calculation formula is based on the Performance Measurement Counters NCLRREQ, TASSFAILand NSUCCHPC as indicated below:

%100*..6] NSUCCHPC[1

,6,11]TASSFAIL[123..26]9..21, NRCLRREQ[1 +=ateSDCCHDropR

In case of NSUCCHPC [1..6] = 0 the SDCCHDropRate is set 0.

For this KPI the ‘number of samples’ value in the referenced QSTHRS object corresponds to the denominator of the calculation

formula:

Number of samples = NSUCCHPC [1..6]


SDCCHLOSR=BSC:0/ QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

SDCCH Loss Rate , this parameter indicates, when its value isdifferent from <NULL>, that the KPI ‘SDCCH Loss Rate’ is observed for the feature ‘Quality of service alarms’. The value entered for this


The observed KPI ‘SDCCH Loss Rate’ calculation formula is based on the Performance Measurement Counters NCLRREQ, TASSFAILand NSUCCHPC as indicated below:

%100*[1] NATTSDPE

[1]ATSDCMBSateSDCCHLossR =

In case of NATTSDPE[1] = 0 the SDCCHLossRate shall be set to 0.


Number of samples = NATTSDPE[1]






SUPPER=MINUTES_5,

object: QSMONBTS

range: MINUTES_5

MINUTES_10

MINUTES_15

default: MINUTES_5

Supervision per iod , this parameter defines the supervision period for the KPI calculation for the QoS alarms feature.During the supervision period, the BSC accumulates the counter values that are necessary for the calculation of the KPIs. When thesupervision period ends, the BSC calculates the KPI values based onthe accumulated counter results and triggers the output, clearance or maintenance of the QoS alarm, depending on the calculated KPI

result value, the relevant configured threshold value and the relevant value of ‘number of periods (see command CREATE QSTHR).

TCHDROR=BSC:0/ QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

TCH Drop Rate , this parameter indicates, when its value is different from <NULL>, that the KPI ‘TCH Drop Rate’ is observed for thefeature ‘Quality of service alarms’. The value entered for this


The observed KPI ‘TCH Drop Rate’ calculation formula is based onthe Performance Measurement Counters NCLRREQ and SUCTCHSE as indicated below

%100*,2]SUCTCHSE[1

14..18]5..12,..3, NRCLRREQ[1eTCHDropRat =

In case of SUCTCHSE [1,2] = 0 the TCHDropRate is set 0.For this KPI the ‘number of samples’ value in the referenced QSTHRS object corresponds to the denominator of the calculationformula:

Number of samples = SUCTCHSE [1,2]


TCHLOSR=BSC:0/ QSTHRS:1,

object: QSMONBTS



<NULL>

default: <NULL>

TCH Loss Rate , this parameter indicates, when its value is different from <NULL>, that the KPI ‘TCH Loss Rate’ is observed for thefeature ‘Quality of service alarms’. The value entered for this


The observed KPI ‘TCH Loss Rate’ calculation formula is based on

the Performance Measurement Counters ATCHSMBS, NMSGDISQand ATTCHSEI as indicated below:

%100*[all]ATTCHSEI

ll] NMSGDISQ[all]ATCHSMBS[aeTCHLossRat

+=

In case of ATTCHSEU[all] = 0 the TCHLossRate shall be set to 0.

For this KPI the ‘number of samples’ value in the referenced QSTHRS object corresponds to the denominator od the calculationformula:

Number of samples = NATTSDPE[1]






Creating the Quality of Service Alarm Objects for PTPPKF objects:

CREATE QSMONGPRS:

NAME=BSC:0/QSMONGPRS:0,

Object path name .

NTWCONCRESFAIR=BSC:0/QSTHRS:2,

object: QSMONBGPRS



<NULL>

default: <NULL>

Network Control led Cel l Reselect ion Fai lure Rate , this parameter indicates, when its value is different from <NULL>, that the KPI

‘Network Controlled Cell Reselection Failure Rate’ is observed for thefeature ‘Quality of service alarms’. The value entered for this


The observed KPI ‘Network Controlled Cell Reselection Failure Rate’ calculation formula is based on the Performance Measurement Counters UNCRORIG and ATCRORIG as follows:

%100*) ,2,3,9,10]ATCRORIG[1

[all]UNCRORIGte NCCRFailRa =

In case of ATCRORIG[1,2,3,9,10] = 0 the NCCRFailRate is set to 0.

For this KPI the ‘number of samples’ value in the referenced QSTHRS object corresponds to the denominator of the calculation

formula:

Number of samples = ATCRORIG[1,2,3,9,10].


SUPPER=MINUTES_5,

object: QSMONGPRS

range: MINUTES_5

MINUTES_10

MINUTES_15

default: MINUTES_5

Supervision per iod , this parameter defines the supervision period for the KPI calculation for the QoS alarms feature.During the supervision period, the BSC accumulates the counter values that are necessary for the calculation of the KPIs. When thesupervision period ends, the BSC calculates the KPI values based onthe accumulated counter results and triggers the output, clearance or maintenance of the QoS alarm, depending on the calculated KPI result value, the relevant configured threshold value and the relevant value of ‘number of periods (see command CREATE QSTHR).

TBFDROR=BSC:0/ QSTHRS:2,

object: QSMONBGPRS



<NULL>

default: <NULL>

TBF Drop Rate , this parameter indicates, when its value is different from <NULL>, that the KPI ‘TBF Drop Rate’ is observed for thefeature ‘Quality of service alarms’. The value entered for this


The observed KPI ‘TBF Drop Rate’ calculation formula is based onthe Performance Measurement Counters UNSTETBF and SULACCEL as follows:

%100*,2]SULACCEL[1

2,13],2,10,11,1UNSTETBF[1eTBFDropRat =

In case of SULACCEL[1,2] = 0 the TBFDropRate shall be set to 0.

For this KPI the ‘number of samples’ value in the referenced

QSTHRS object corresponds to the denominator of the calculationformula:

Number of samples = SULACCEL[1,2]






TBFLOSR=BSC:0/ QSTHRS:2,

object: QSMONBGPRS



<NULL>

default: <NULL>

TBF Loss Rate , this parameter indicates, when its value is different from <NULL>, that the KPI ‘TBF Loss Rate’ is observed for thefeature ‘Quality of service alarms’. The value entered for this


The observed KPI ‘TBF Loss Rate’ calculation formula is based onthe Performance Measurement Counters REJPDASS and

NUACATCL as follows:

%100*[all] NUACATCL

ll]REJPDASS[aeTBFLossRat =

In case of NUACATCL[all] = 0 the TBFLossRate shall be set to 0.


Number of samples = NUACATCL[all]


TBFREAFAIR=BSC:0/

QSTHRS:2,

object: QSMONBGPRS



<NULL>

default: <NULL>

TBF Reassignment Fai lure Rate , this parameter indicates, when its

value is different from <NULL>, that the KPI ‘TBF Reassignment Failure Rate’ is observed for the feature ‘Quality of service alarms’.The value entered for this parameter is the object path name of thethreshold set (command CREATE QSTHR, see above) that is to beused for this KPI.

The observed KPI ‘TBF Reassignment Failure Rate’ calculationformula is based on the Performance Measurement CountersNSUPRRE and NATPRRE as follows:

%100*) l] NATPRRE[al

[all] NSUPRRE1(eAssFailRatReTBF −=

In case of NATPRRE[all] = 0 the TBFReAssFailRate shall be set to 0.

For this KPI the ‘number of samples’ value in the referenced

QSTHRS object corresponds to the denominator of the calculationformula:

Number of samples = NATPRRE[all]






Activating IMSI tracing in the BSC:

<The feature IMSI Tracing allows the BSC to trace all signalling transactions of any call (MOC, MTC) or a short message transfer (SMS-MO, SMS-MT) performed by a specific subscriber (represented by his IMSI). This feature is foreseen for a limited number of subscribers to be traced and has to be activated in the MSC for specific IMSIs (up to 7 subscribers can be traced at the same timewithin one BSC). If a particular problem appears in an network-area(e.g. subscribers complain about the quality in a specific network area) IMSI tracing might be started for the IMSI of the affected subscriber or a tester may travel through this area performing test calls with a test SIM card while IMSI tracing is active. Specific commands have to be entered in the SIEMENS MSC to activate thefeature generally (MOD MSERVREL and MOD MSERVOPT) and for a specific IMSI (ACT IMSITRAC). In the BSC, the feature is generally activated by the CREATE TRACE command. As a result, if an MSwith the IMSI under test performs any call transaction, the MSC instructs the BSC to start the recording of the call events (using theBSSMAP message MSC INVOKE TRACE). The BSC sends the RSL

Abis message START TRACE to the BTS which starts the sending of the up- and downlink measurements measured during the call by theMS and the BTS in form of the so-called TRACE MEASUREMENT RESULTS. The operator is informed about the trace start by anappropriate notification, which is triggered by the message‘TraceStartedNotification’ sent by the BSC to the RC and to the LMT.The BSC collects the trace data and stores in a special directory onthe BSC disk (see command SET BSC SET BSC [CONTROL],

parameter IMSIFSIZ). At the end of the call, the BSC and the BTSstop the trace data collection and the BSC informs the RC/LMT using the ‘StoppedTraceNotification’. The trace file is compressed and automatically uploaded to the RC. In the RC, the file isdecompressed and converted to ASCII format. Thus the ASCII tracefile, which contains all messages and events related to the traced call, transaction is ready for analysis.

Note: With respect to the number of simultaneous traces manageableby the BSC also the feature ‘Cell Traffic Recording’ has to beconsidered. The maximum number of simultaneous (IMSI and CTR)traces is restricted to 128 . The difference between IMSI tracing and the CTR feature is that IMSI tracing is IMSI related (resp. subscriber related) while CTR is cell related. For further details please refer tothe descriptions provided for the command CREATE CTRSCHED. >

CREATE TRACE:

NAME=trace:0, Object path name .

RECCRI=NO_CRITERIA,

range: NO_CRITERIA

Record cr i ter ia , describes the criteria in which the traces arecollected by the BSC.





Creating a Cell Traffic Recording (CTR) job:

<The feature Cel l Traff ic Recordin g (CTR) is introduced in additionto the IMSI Trace (see command CREATE TRACE), to better monitor the system’s behaviour and the quality of service. CTR traces adefinable number of calls within a specified cell, so it is, in contrast tothe feature IMSI Tracing, resource (cell) related. Furthermore, CTR islocally performed in the BSS, i.e. neither a trace invocation isreceived from the MSC nor is the MSC informed about any cell tracing activities. The purpose of CTR is to collect call trace data insuch a way that they can be chronologically aligned to the existing cell specific event- and quality-of-service related system data such as

performance measurements and alarm files. Thus CTR allows theoperator to simultaneously observe the system's behaviour and itsimmediate effects on calls within the cell. This could be necessary if subscriber complaints or PM data point to problems in a specific cell or if a newly installed cell is to be observed for correct behaviour.Basically the contents of a CTR trace is exactly the same as the onefor an IMSI trace. Starting from BR8.0, the CTR does not only record the messages from the TCH phase of the call but can also record themessage events from the SDCCH phase (parameter TRACECH, seebelow). Differences in the recorded messages my arise due to thefact that the recording for IMSI tracing starts on explicit trigger messages from the MSC (MSC INVOKE TRACE), while for CTR theBSC starts the tracing itself. Moreover, while IMSI traces record complete BSC-controlled inter-cell handover procedures within onetrace, CTR in this case just follows up the signalling transactions inthe target cell for a defined ‘trace handover persistence time’ which isfixed to 10 sec.. In the other cases the recording is stopped on call termination (normal or abnormal), in case of forced termination due toan IMSI trace invocation (see MACONN) or in case of inter-BSC HO.

Another difference between IMSI Tracing and CTR consists in the filestructure: while for IMSI tracing one trace file only contains the traced messages related to one call only, a CTR file contains all traced callswithin the traced cell. These single calls are separated later on in theframework of postprocessing (via the OTS application DUIT/RNA).

The trace data recorded are temporarily stored in the BSC (see parameter CFS in command SET BSC SET BSC [CONTROL]) fromwhere they are compressed and automatically uploaded to the RC. Inthe RC the files are converted to ASCII so that they are ready for analysis and postprocessing . >

CREATE CTRSCHED:

NAME=CTRCO:0/CTRSCHED:0,

Object path name . The CTR control object (CTRCO) assumes thestate management functions of all CTRSCHED objects.Operational state: If operational state of the CTRCO object is‘enabled’ the CTR tracing activity is possible, if it is ‘disabled’ theBSC cannot start CTR any trace activities due to abnormal conditions(e.g. overload).

Administrative state: The OMT/LMT operator is able to stop all thetrace sessions on a BSC through the setting of the administrativestate to 'locked'. The ‘shutting down’ value for the administrative statemeans that the current connection traces in the cell is finished, but nonew connections are traced. When all active traces are terminated the administrative state automatically changes to ‘locked’ value.Usage state: The usage state of the CTR Control object reports theinformation related to the capacity of the BSC to trace another call:the ‘idle’ value means that no trace is running on that BSC, ‘active’ means that at least one trace session is running but the BSC is ableto start a new one, ‘busy’ means that the maximum number of tracesessions (maximum 128 per BSC) has been reached and no moretracing sessions are possible. As for tracing sessions there is nodifference between IMSI and CTR Trace, the ‘busy’ state does not





mean that all the active tracing sessions are CTR traces.

Note: Also the CTRSCHED object can be locked. In this case theCTR recording function is just stopped for a specific cell.

CID=BTSM:0/BTS:2,

range: 0..149

Cell Identity , this parameter determines the path name of the BTSobject that represents the cell to be traced in the CTRSCHED object.

MACONN=128,

range: 1..128

Maximum number of conn ect ions , this parameter determines the

maximum number of connections to be traced within the cell.Note: The overall maximum number of traced connections (IMSI and CTR traces) is restricted to 128 . IMSI tracing always has precedenceover CTR. The maximum number of IMSI traces is limited to 7. Thismeans that, if MACONN is set to a bigger value than 9 while IMSI tracing is active, ongoing CTR traces will be stopped if the maximumnumber of simultaneous traces is reached and new IMSI traceinvocations are received from the MSC.

PERWEEK=ALL,

format: ALL or

WEEKLY + <scheduling

description>

range: ALL, WEEKLY +

ALL 0..0

weekly: <day_of_week>noSched 0..0

suPeriod: startHour 0..23

startMinute 0..59

stopHour 0..23

stopMinute 0..59

where <day_of_week> is equal

wednesday, thursday, Friday

saturday

Period during th e week , this parameter is mandatory and definesthe periods during which the CTR trace activities should be activewithin a week by its start time and the trace duration. For every day of the week an appropriate period can be entered.

START=1-1-1992,

format: day - month - year

range: day: 1-31

month: 1-12

year: 1992 – 2099

default: 1-1-1992

Start date , this parameter defines the start date of the traceactivities.

STOP=31-12-2099,


range: day: 1-31

month: 1-12

year: 1992 – 2099

default: 31-12-2099

Stop date , this parameter defines the stop date of the trace activities.

TRACECH=BOTH,

range: TCH, SDCCH, BOTH

default: TCH

Traced channel , this parameter determines whether CTR shall record a) only TCH events (starting from the ASSIGNMENT COMPLETE message, as was the case up to BR7.0) or b) only SDCCH messages or c) both messages and events on the TCH and SDCCH

In case the options ‘SDCCH’ or ‘BOTH’ are selected, CTR does not only record calls, but also other SDCCH procedures such as LocationUpdates etc..

TRACERECTYP=ALL,

range: ALL, MESSAGE

default: ALL

Trace record t ype , this parameter determines whether the trace fileshall contain only the signalling messages only (MESSAGE) or whether it shall contain the uplink and downlink measurement results/reports in addition (ALL).





Enabling the data recording for the feature ‘History on Dropped Calls’:

< Introduction

The feature History on Drop ped Cal ls was introduced in BR8.0 as anew feature for the root cause analysis of dropped calls. The idea isto collect as much call processing information (and information about the radio conditions immediately before the call drop) as possible in

order to allow conclusions for improvements in the affected cells.The history data of each call or transaction are permanently collected in a dedicated cyclic buffer in the BTS and, if the call is not abnormally released due to a call drop event, deleted on the releaseof the involved radio resources (SDCCH or TCH). However, if the call is terminated by a call drop event, the BSC requests the preservationand upload of the history data to the BSC within a special IE ‘History Data Request’ within the Abis RSL message RF CHANNELRELEASE.

Trigger events for Histo ry Data Saving

The ‘Call Drop’ events which trigger the request of the history datafrom the BTS are the same as the ones which trigger the known call drop PM counters:

• ‘Number of lost radio links while using a TCH’ ( NRFLTCH ):

a) transmission of a valid CONNECTION FAILURE INDICATION (BTS->BSC) for a TCH b) transmission of a valid ERROR INDICATION (BTS->BSC) for aTCH with the causes:- ‘timer T200 expired N200+1 times’ - ‘unsolicited DM response, multiple frame established state’ - ‘sequence error’ c) T8 expiry during outgoing Inter-BSC handover

• ‘Unsuccessful internal handovers intracell with loss of MS’ ( UNIHIALC ): expiry of the BSC timer T10 in the context of aninternal intracell handover

• ‘Unsuccessful internal handovers intercell with loss of MS’ ( UNIHIRLC ): expiry of the BSC timer T8 in the context of aninternal intercell handover

• ‘Number of lost radio links while using a SDCCH ( NRFLSDCC )a) transmission of a valid CONNECTION FAILURE INDICATION (BTS->BSC) for an SDCCH b) transmission of a valid ERROR INDICATION (BTS->BSC) for anSDCCH with the causes:- ‘timer T200 expired N200+1 times’ - ‘unsolicited DM response, multiple frame established state’ - ‘sequence error’

• ‘Total Number of Assignment Failures’ ( TASSFAIL ,subcounters [6, 11] ): transmission of an ASSIGNMENT FAILURE message(BSC->MSC) with cause ‘radio Interface message failure’ after expiry of T10 during TCH assignment.

History Data Saving and Uplo ad by the BTS

When a radio resource is abnormally released due to one of theaforementioned conditions, the BTS transmits the history data to theBSC in a new Abis RSL message called HISTORY REPORT.Depending on the amount of collected data, up to 4 HISTORY REPORT messages may be sent to deliver the complete set of datain segments to the BSC.

A HDCTR HISTORY REPORT message consists of the following parts:

1) IE ‘Dropped Channel Characteristics’:This IE describes the type of channel that was dropped.

2) IE ‘Channel History’ This IE contains up to 4 CHANNEL HISTORY records (event





records) containing

• MEASUREMENT REPORTs (or ENHANCED MEASUREMENT REPORTs) containing - the complete information about the RXLEV and RXQUAL valuesin uplink and downlink for the serving cell including FULL and SUBvalues and relevant DTX flags- the current BS power level and MS power level - the current timing advance (TA) and timing offset

- downlink RXLEV values of the GSM and 3G neighbour cells• the number of measurement periods with skipped event records

due to missing MEASUREMENT REPORT messages (seeexplanation below)(*)

• flags indicating the occurrence of DTAP RR channel changemessages such as HANDOVER COMMAND, ASSIGNMENT COMMAND, HANDOVER FAILURE, ASSIGNMENT FAILURE.

Remark: The number of CHANNEL HISTORY records (event records) to be saved and uploaded is determined by the ‘Number of requested event records’ field which the BSC inserts into the ‘History Data Request’ IE within the RF CHANNEL RELEASE message. Thisfield, in turn, is configurable and determined by the parameter MEASET (see below).

3) IE ‘GSM 08.08 cause’ This IE indicates the cause value of the last transmitted HANDOVER CONDITION INDICATION sent for the dropped call

4) IE ‘Intracell Channel Change Information’ This IE contains parts of the ASSIGNMENT COMMAND message- Description of the First Channel, after time- Power Command

5) IE ‘Intercell Handover Information’ This IE contains parts of the HANDOVER COMMAND message- Description of the First Channel, after time- Power Command - Cell Description

(*) Organizat ion of th e Channel History data

The CHANNEL HISTORY records (event records) within the

‘Channel History’ IE are organized in measurement periods (480msSACCH periods), i.e. all event records are assigned to a particular measurement period. RR channel change messages received withina particular measurement period are indicated in the event record belonging to the measurement period (see record format below).

In those periods where no MEAS REP messages has been received from the MS (called ‘gap’), no event record is generated, but, instead,the last event record that contains a valid MEAS REP indicates thelength of the ‘gap’ by the number of subsequent measurement

periods without valid MEAS REP message.

As also the RR channel change messages received during measurement periods without valid MEAS REP have to be assigned to the existing measurement periods/event records, the following approach is used: The events

- INTRACELL / INTERCELL HANDOVER CONDITION INDICATION message sent - ASSIGNMENT COMMAND received - HANDOVER COMMAND received are indicated in the last event record before the gap.

The events

- HANDOVER FAILURE message received - ASSIGNMENT FAILURE message received

are indicated in the first event record after the gap.





The ‘Channel History ‘ IE has the following format:

When the last part of the HDCTR event records have beentransmitted, the BTS closes down the radio resource by the messageRF CHANNEL RELEASE ACKNOWLEDGE.

In the BSC, the history data are extracted from the received messages, extended by additional addressing data about theaffected radio resource (BTS, TRX), adjacent cell data and the typeof call drop that occurred and finally formatted to a complete HDCTR record which is subsequently stored on the BSC disk in the HDCTR logfile.

The complete HDCTR record file has the following format

BTS BSC

RF CHANNEL RELEASE

with IE ‘History data request’

HISTORY REPORT (part 1)

call drop occurred . . .

HISTORY REPORT (part n)

.

.

RF CHAN RELEASE ACK

MessageHeader

First eventrecord

n event record

Indication for length of thesubsequentmesaurement’gap’ (if

Flags indicatingpresence of RRchannel change

messages.





Activat ion and enabl ing of the feature HDCTR

The feature must be generally enabled in the BSC by using the

command CREATE HDCTR. In addition, the feature must be enabled per cell in the BTS object. This is done by the parameter EHDCTR incommand CREATE/SET BTS [BASICS].

HDCTR fi le management in B SC and upload to RC When the HDCTR logfile has reached the file size determined by the

parameter HDCFS (see command SET BSC [CONTROL]), it iscompressed and uploaded towards the RC for further processing within the Operator Tool Set (OTS), namely the applicationDUIT/RNA, which is also used for the postprocessing of IMSI traces,CTR traces etc.. Upload scheduling is controlled by the parameter HDCFUPE see command SET BSC [CONTROL]).>

HDCTR FileHeader

Addressing dataof affectedchannel object(BTS, TRX)

HDCTR eventrecords asreceived fromBTS

Adjacent celldescription data

Call drop cause

Number of calldrops that could notbe traced due tobuffer overflow in

the BSC (happensonly if too many calldrops (max. 64)occur at the sametime, value shouldbe always ‘0’).

n completeHDCTR record

First complete

HDCTR record





CREATE HDCTR:

NAME=BSC:0/HDCTR:0,

Object path name .

MEASET=16,

range: 1..16

Measuremen t Sets , this parameter defines the number of CHANNELHISTORY records (event records) that shall be saved and uploaded by the BTS in the HISTORY REPORT message set of dropped calls.

The BSC inserts the entered value is into the ‘Number of requested

event records’ field within the ‘History Data Request’ IE within the RF CHANNEL RELEASE message.

PERWEEK=ALL,

format: ALL or

WEEKLY + <scheduling

description>

range: ALL, WEEKLY +

ALL 0..0

weekly: <day_of_week>

noSched 0..0

suPeriod: startHour 0..23

startMinute 0..59

stopHour 0..23

stopMinute 0..59

where <day_of_week> is equal

to: sunday, monday, tuesday,

wednesday, thursday, Friday

saturday

Period during th e week , this parameter is mandatory and definesthe periods during which the HDCTR trace activities should be activewithin a week by its start time and the trace duration. For every day of the week an appropriate period can be entered.

START=1-1-1992,


range: day: 1-31

month: 1-12

year: 1992 – 2099

default: 1-1-1992

Start date , this parameter defines the start date of the HDCTR traceactivities.

STOP=31-12-2099,


range: day: 1-31

month: 1-12year: 1992 – 2099

default: 31-12-2099

Stop date , this parameter defines the stop date of the HDCTR traceactivities.





Defining the BSC environmental alarms:

CREATE ENVA:

NAME=enva:0, Object path name .

ASEV=CRITICAL,

range: MINOR, MAJOR,

CRITICAL

default: CRITICAL

Alarm sever i ty , determines the severity of the alarm to be raised on

the condition defined by INTINF.

ASTRING=”FIRE_IN_RACK”,

range: 26-character string in

quotation marks ( “ )

Alarm str ing , represents a free-definable character string that shall be displayed in the alarm message.

ENVANAME=FIRE,

range: SMOKE

INTR

TX_EQ_MIN

TX_EQ_MAJ

TX_EQ_CRIT

POW_MINPOW_MAJ

POW_CRIT

GEN_ALM_MIN

GEN_ALM_MAJ

DOOR_OPEN

FIRE

HEAT_EVENT

HUMIDITY

TEMPERATURE

Environm ental alarm name , identifies the alarm type of the external alarm.

INTINF=HIGH,

range: LOW, HIGH

default: HIGH

in terface logic , determines the interface logic of the alarm detectionequipment, i.e. the value entered determines the case in which analarm is to be raised.

THR=2,

unit: 1s

range: 0..65534

default: 2

error detect ion thresho ld , represents the error detection threshold

in seconds.





Configuring the feature Online RF Loopback:

< The RFLOOP object is the database object that represents thefeature “Online RF Loopback”.

Purpose of th e feature “ Onl ine RF Loopback “ This feature allows the operator to observe the complete RF signal

path of a BTSE including the cabling and connectors by permanently

monitoring the path loss difference between uplink and downlink – if the path loss difference between uplink and downlink exceeds aconfigurable threshold, the BTS outputs an alarm “Increased pathloss difference“. The purpose of this feature is to significantly enhance the overall test coverage in addition to other alarming features such as “Sleeping Cell Detection” or “RX Diversity Alarm”. If the alarm “Increased path loss difference“ is output, the operator ismade aware of some irregularities in the HF paths of the affected cell.Whether the problem is caused by a defective HW (such as CU,ECU, GCU, DUAMCO etc. (for BTSplus) or TPU, PA etc. (for BTSone)), can be established by a test (from the RC) on the affected boards: if the test fails, the affected HW must be replaced, if no faulty HW board can be identified, an on-site check of the HF cabling isrecommended.

Functional Descr ipt ion of Measurement & Calculat ion Process

The downlink path loss is calculated as follows:

PLDL = BSPOWER ANT - RXLEV_DL

where:RXLEV_DL = RX signal measured by MS in DL and reported in the

MEASUREMENT REPORT messages

BSPOWER ANT = current BS downlink transmit power at the antenna port= Declared Output Power of CU/PA - PWRRED

- PWR_C_D + TXLEVADJ - AttDUAMCO

where:PWRRED = static Power Reduction

(see parameter PWRRED in command CREATE / SET TRX)

PWR_C_D = dynamic Power Reduction due to BS Power Control

AttDUAMCO = Attenuation of DUAMCO and rack cablingdepending on HF configuration:

a) 2:2 configuration: ≈ 2 dB

b) 4:2 configuration: ≈ 5 dB

c) 8:2 configuration: ≈ 8,5 dB

* XXCOM / DxAMCO can be either DUAMCO or FICOM/DIAMCO

CUTMA

TMA

BSPOWER ANT

RXLEV_UL ANT

TXLEVADJ set by operator

RXLEVADJ set by operator

cable

cable

CU OutputPower

RXLEV_DL

MEAS REP

XXCOM /

DxAMCO *

UL RXLEVat ANT Inputof DxAMCO





The uplink path loss is calculated as follows:

PLUL = MSPOWER – RXLEV_UL ANT

where:MSPOWER = current uplink transmit power confirmed by the MS

RXLEV_UL ANT = current UL RX signal received at BTS antenna= current UL signal level at XXCOM ANT Input + RXLEVADJ

The path loss difference is calculated as

PLdiff = PLUL – PLDL The values of RXLEVADJ and TXLEVADJ are set in the BTSE by thefollowing commands:

RXLEVADJ: CREATE/ SET TPU, CREATE/SET CU TXLEVADJ: CREATE/SET BBSIG, CREATE/SET CU, CREATE/SET CA

BTSE Parameter RXLEVADJ

The purpose of the parameter RXLEVADJ is to correct the uplink RXLEV value (RXLEV_UL) measured at the DUAMCO input if thegain resp. attenuation deviates from standard values (Note: thesignal is physically measured in the CU but the CU measurement automatically considers the DUAMCO gain). This can happen either due to the use of third-vendor (i.e. non-SIEMENS-specified) TMAs or extremely long feeder cables. As the GSM standard requires that theRXLEV_UL values that are to be used for the Power Control and Handover decision shall refer to the antenna port (and not to theDUAMCO input), the value measured at the DUAMCO input has tobe corrected in correspondence with the actual gain or loss of thereceive path.

The value range of RXLEVADJ is -24dB ..+24dB in 1dB steps, i.e.RXLEVADJ can assume positive and negative values.

Generally the uplink RXLEV values will be correctly measured whenthe gain between BTS antenna port and DUAMCO input is about:19 dB for GSM900 and GSM850 and 21 dB for DCS1800 and PCS1900.

This gain figure will be maintained in a pure Siemens system withand without (Siemens-)TMA by setting the DUAMCO gainappropriately (AMCO / MUCO mode) using the DUAMCO dip

switches:a) if a (Siemens-)TMA is used , the DUAMCO is set to “MUCO mode” (no amplification, as amplification is done in the TMA)b) if no TMA is used, the DUAMCO is set to “AMCO mode” (amplification done in the DUAMCO).

Note: Basically the gain of the TMA is higher than that of the DUAMCO. Thisdifference is normally used to compensate the higher losses caused by thelonger feeder cable, that connects the TMA (at the top of the tower) to theBTSE rack.

In these cases, with a pure Siemens configuration and no excessivefeeder cable loss with the RXLEVADJ parameter should set todefault value RXLEVADJ=0dB. Only in case of deviating configurations the parameter RXLEVADJ must be set incorrespondence with the deviating gain or loss of the receive path.

Example: If there is an additional loss of 10dB on the uplink HF path,this loss has to be considered by setting RXLEVADJ=+10dB. These10dB are added to the measured RXLEV_UL at the DUAMCO input and are used by the BTS measurement processing procedures. Thusthe Power Control and Handover decision is based on theRXLEV_UL values at the antenna port. In the opposite direction if athird-vendor TMA is used which offers a gain 10dB higher than theSiemens TMA, this gain must be considered by setting RXLEVADJ=-10dB.

ATTENTION: Please cons ider that a change of th e RXLEVADJ

value has an impact on the Power Control and Handover





decis ion process! This means that the handover perform ance

measurements w i l l show different resul ts i f RXLEVADJ is

changed! As a correct sett ing of RXLEVADJ is obl igatory fo r the

proper operat ion of th e RF LOOPBACK feature, this has to

cons idered when the feature is configured for th e fi rst t ime.

In the same way, the uplink RF configuration and RXLEVADJC setting has an impact on the Idle TCH Measurements (see parameter INTCLASS in command SET BTS [INTERF])

BTSE Parameter TXLEVADJ

The purpose of the parameter TXLEVADJ is to consider non-standard gains or losses in the calculation for the BTS transmit power at the antenna port ( BSPOWER ANT ) as explained above. As opposed to the parameter RXLEVADJ, TXLEVADJ has no other impact.

The value range of TXLEVADJC is -63dB ..+63dB in 1dB steps.

Functional Descr ipt ion of Feature Management

The RFLOOP data is processed for each TX/RX pair.

• The BTS accumulates and calculates the data for every 30..minuteblock, and at the end of each block the BTS checks- the number of calls that were handled - the number of MEASUREMENT REPORTs processed in the

30..minute period.• Only if the number of calls handled exceeds the threshold

MINCCNT (see below) and the number of MEASUREMENT REPORTs exceeds the threshold (MECNT), the BTS calculatesthe mean path loss difference for that particular period.

• The alarm “Increased path los s dif ference” is output if thecalculated absolute average value exceeds the upper alarmthreshold ALTH (see below), i.e. if the following condition

PLdiff (averaged absolute) > ALTH

where PLdiff (averaged absolute) = | Σ1-n (PLUL – PLDL) | / n

• The alarm is ceased when at the end of a subsequent 30..minutes period the calculated path loss difference has dropped below the

lower alarm threshold, which is ALTH - BANDOFHYS.• The alarm is also ceased when the RFLOOP measurement is

locked.

Note: The feature “ Online RF Loopback “ does not work if baseband frequency hopping (see HOPMODE=BBHOP in command SET BTS[OPTIONS]) is configured. The implementation of baseband frequency hopping shows thefollowing difference regarding the two BTSE generations, i.e. BTS1and BTSplus:- In the BTS1 baseband hopping is realized by multiplexing different TPUs to one BBSIG. The TX and RX paths are tied together by switching TX & RX at the same time;

- The BTSplus implementation is different to the BTS1. Herebaseband hopping is exclusively used in downlink direction whereasin uplink direction always synthesizer hopping is applied. Downlink data is pre-processed in the TRX related CU, but the burst data isthen sent via the CU whose carrier frequency is equal to that of thecurrently calculated burst. Thus, for a call, a single RX path is used with multiple TX paths; so there are as many TX/RX pairings for thecall as the number of transmitters in use.

Since the mobile reports the measured RXLEV_DL values with afixed period of 480ms (= 104TDMA bursts), no mapping is possibleon TDMA burst base for the DL measurements. Due to the averaging effect this means that failures in the RF-TX signal path which arelocated in carrier specific parts may not be reliably detected in case





baseband hopping is applied (both for BTS1 and BTSplus). In fact,the MS will report an RXLEV_DL value which is the average of levelsreceived from different RF-TX equipment (and so from different

paths). On the other side, in uplink direction the BTSE knows whichRX path is used per received burst.

CREATE RFLOOP:

NAME=btsm:0/bts:0/rfloop:0, Object path name .

ALTH=30,

unit: 1dB

range: 14..100dB

default: 30

Alarm threshold , this parameter defines the upper alarm threshold for the alarm “Increased path loss difference”.

For further details please refer to the descriptions provided at the topof the command description.

AUTOREP=FALSE,

range: TRUE, FALSE

default: FALSE

Auto report , this parameter allows to the user to enable or disablethe automatic file upload. This operation can be activated for no morethan 20 cells.

BANDOFHYS=25,

unit: 1dB

range: 1..100dB

default: 25

Bandwidth of hysteresis , this parameter defines hysteresis value,which is used to calculate the lower alarm threshold for the ceasing of the alarm “Increased path loss difference”. The value of this

parameter must be lower than the ALTH parameter value.

For further details please refer to the descriptions provided at the top

of the command description.MECNT=200,

range: 100..1000

default: 200

Measurement coun t , this parameter defines the minimum number of measurement samples (taken in a 30..minutes observation period)required for the path loss calculation.


MINCCNT=50,

range: 20..250

default: 50

Min imum cal l count , this parameter defines the minimum number of calls handled (within a 30..minutes observation period) required for the path loss calculation.


RXLV=10,


RX level , this parameter defines how many measurement samplesvalues must have been taken for a particular call to take the call into

account for the RFLOOP data registration..

START=1-1-1992,


range: day: 1-31

month: 1-12

year: 1992 – 2099

default: 1-1-1992

Start date , this parameter defines the start date of the data collectionactivities.

STOP=31-12-2099,


range: day: 1-31

month: 1-12

year: 1992 – 2099

default: 31-12-2099

Stop date , this parameter defines the stop date of the data collectionactivities.





Creating Smart Carrier Allocation:

< SCA (Smart Carr ier Al loc ation) provides histograms of frequency based measurements and elaborates them to determine a list of ranked frequencies. This list then indicates the best substitute for afrequency that is being tested e.g. for a microcell or to be used in case of interference. The resulting reduction of interference

achieved here offers benefits especially for micro cellular and picocellular layers.The SCA object allows performing up to three new types of measures(Normal Measure, Busy Cumulative Measure and Extended IdleChannel Measure). The operator can choose those kind of measuretypes he wants to trace and also the list of frequencies to put under observation; for the Busy Cumulative Measures, the frequencies list is not required . >

CREATE SCA:

NAME=btsm:0/bts:0/sca:0, Object path name .

ATIME1=(6-0)-(23-59),

format: startHour-startMinute

stopTime-stopMinute

range: startHour/stop Hour: 6..23startMinute/stopMinute:0..59

range: startHour: 6

startMinute: 0

stop Hour: 23

stopMinute: 59

Accumula t ion t ime 1 , this parameter defines the daily time intervals(first, second, etc.) of observation of a SCA object (accumulation

periods); up to 4 accumulation periods are possible per day, theaccumulation time periods must not have intersections.

Each parameter consists of two fields:startTime (startHour - startMinute) and stopTime (stopHour - stopMinute).

4 parameters (ATIME1..ATIME4) are provided.

ATIME2..ATIME4 Accumulat ion tim e 2 .. accum ulat ion time 4 , see ATIME1.

BAND=30,

range: P, E, DCS, GSM_R,PCS,

GSM850

Frequency band , this parameter defines the band of frequenciesobserved by a SCA instance.

EBUSYCUM=FALSE,

range: TRUE, FALSE

default: FALSE

Enable busy cu mulat ive measurements , this parameter enables or disables the busy cumulative measurements.

EEICM=FALSE,

range: TRUE, FALSE

default: FALSE

Enable extended idle c hannel measurements , this parameter enables or disables the extended idle channel measurements.

EICNF1=103,

range: 0..1023

Extended Idle Channel Measurements Frequency 1 , this parameter defines a frequency for Extended Idle Channel Measurements observation.

32 parameters (EINCF1..EINCF32) are provided.

EICNF2..EICNF32 Extended Idle Channel Measurements Frequency 2 .. Extended

Idle Channel Measurements Frequency 32 , see EINCNF1.

ENDML=FALSE,

range: TRUE, FALSE

default: FALSE

Enable normal measurements , this parameter enables or disablesthe normal measurements.





NMDLATT1=104-3-5,

format: bcchFrequency-

netColorCode-

bsColorCode

range: bcchFrequency: 0..1023

netColorCode: 0..7

bsColorCode: 0..7

<NULL>

Normal measurements attr ibutes 1 , this parameter defines a pair of “BCCH frequencies-BSIC” for Normal Measurements observation.Each parameter consists of three fields: bcchFrequency,netColorCode and bsColorCode.

32 parameters (NMDLATT1..NMDLATT32) are provided.

The <NULL> value can be set for each of the NMDLATT<n>

parameters.

NMDLATT2..NMDLATT32 Normal m easurements attr ibutes 2 .. Normal m easurements

attr ibutes 32 , see NMDLATT1..

START=1-1-1992,


range: day: 1-31

month: 1-12

year: 1992 – 2099

default: 1-1-1992

Start date , this parameter defines the start date of the data collectionactivities.

STOP=31-12-2099,


range: day: 1-31

month: 1-12

year: 1992 – 2099

default: 31-12-2099

Stop date , this parameter defines the stop date of the data collectionactivities.





2 Appendix

2.1 Handover Thresholds & Algorithms

2.1.1 Functional Diagram Handover Thresholds for Inter-cell Handover andIntra-cell Handover (level, quality and power budget)

XX=UL : Uplink Bit-Error-Rate (RXQual)

Level (RXLev)

Handover

L_RXLev_XX_H L_RXLev_XX_IH

L_RXQual_XX_H

Inter-cell handover due to power budget /

Traffic Handover

Inter-cell handover due to level

made by: Gunther Döhler

HOLTHQUXX

HOLTHLVTXX HOTXXINT

XX=DL : DownlinkXX=UL : Uplink

Inter-cell handover due to quality(if skip flag=TRUE or if INTRACH=FALSE)

Intra-cell handover due to quality(if skip flag=FALSE)

Inter-cell handover due to quality(skip flag not evaluated)

Note: For clearness reasons, Fast Uplink Handover was not included in this diagram.

Abbreviations: RXLEV = receive level of serving cellRXQUAL = bit error rate of serving cell

GSM Parameter Name

DB parameter Name(SET HAND [BASICS])

Meaning

L_RXLev_DL_H HOLTHLVDL lower threshold value for level handover downlink

L_RXLev_UL_H HOLTHLVUL lower threshold value for level handover uplink

L_RXLev_DL_IH HOTDLINT threshold value for intra BTS handover downlink

L_RXLev_UL_IH HOTULINT threshold value for intra BTS handover uplink L_RXQual_DL_H HOLTHQUDL lower threshold value for quality handover downlink

L_RXQual_UL_H HOLTHQUUL lower threshold value for quality handover uplink





2.1.2 Rules: Handover Thresholds for Inter-cell Handover and Intra-cellHandover (level, quality and power budget), Power Control disabled

General Remark: The following explanations are a supplement to the diagrams shown in the previoussection. The purpose of both the diagrams and the written rules is to illustrate the interaction between thedifferent handover types depending of different level and quality conditions. Please be aware that the listedrules are only valid if all affected handover types (Level HO, Quality HO, PBGT HO) are enabled.

2.1.2.1 Inter-cell/Inter-system Handover due to level

2.1.2.1.1 Handover Decision / Handover Trigger Conditions

An Inter-cell-handover due to level is triggered by the BTS if all of the following conditions are fulfilled:

1. RXLEV_XX < L_RXLEV_XX_H XX = DL or UL

RXLEV_XX = received level average of the serving cell

(the averaging is done according to the setting of HOAVLEV (SET HAND))

L_RXLEV_XX_H = HOLTHLVXX (SET HAND) = lower threshold value for level handover

→ The received level average of the serving cell is lower than the value set for HOLTHLVXX

2. RXQUAL_XX < L_RXQUAL_XX_H XX = DL or UL

RXQUAL_XX = received quality (i.e. bit error rate) average of the serving cell

(the averaging is done according to the setting of HOAVQUAL (SET HAND))

L_RXQUAL_XX_H = HOLTHQUXX (SET HAND) = lower threshold value for quality handover

→ The received quality (i.e. bit error rate) average of the serving cell is lower than the valueset for HOLTHQUXX (if it was higher, a quality HO would be triggered)

3. YY_TXPWR = Min(YY_TXPWR_MAX,P) YY = MS or BTS

YY_TXPWR = current MS- or BTS transmit power

YY_TXPWR_MAX = maximum MS- or BTS transmit power

whereMS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) (CREATE BTS

[BASICS]), value in [dBm]BS_TXPWR_MAX is determined by the used type of PA and the parameter PWRRED (CREATE TRX)

P = power capability of the mobile in [dBm]

Min(YY_TXPWR_MAX,P)= YY_TXPWR_MAX if YY_TXPWR_MAX < P

Min(YY_TXPWR_MAX,P)= P if YY_TXPWR_MAX > P(for the mobile the maximum allowed transmit power is determined by its power classor by the administered value for MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) - dependingon whichever is lower)

→ The transmit power of MS and BTS is at the maximum(since in this case PWRC is disabled this is the case anyway)





2.1.2.1.2 Target Cell List Generation

A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘uplink strength’ or ‘downlink strength’ if itfulfils the handover minimum condition

4. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa)

where Pa = MS_TXPWR_MAX(n) - P

RXLEV_NCELL(n) = received DL RXLEV or DL RSCP average of the neighbour cell (n) *

RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) or

RXLEVMIN (CREATE ADJC3G) = minimum RSCP value of the 3G neighbour cell (n)

MS_TXPWR_MAX(n)= MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or

MSTXPMAXUMTS (TGTFDD object), value in [dBm]

= max. allowed transmit power of neighbour cell (n)


Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

→ The actual receive level average of the neighbour cell must be higher than the sum of theminimum receive level set for the neighbour cell and the correction term Max(0,Pa)

* Remarks:1) For 2G-3G handover, the 3G neighbour cells are considered if EUHO=TRUE and EUIMPHO=TRUE (see

For the reporting of the RSCP levels, please consider the explanations in section ‘Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells’.

2) 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)

If the optional feature “Level Handover Margin” is enabled (SET HAND:ELEVHOM=TRUE), the followingadditional condition must be fulfilled

5. RXLEV_NCELL > RXLEV-DL + LEVHOM(n)

LEVHOM(n) = LEVHOM (CREATE ADJC) = level handover margin of the neighbour cell (n) in [dB] RXLEV_NCELL(n) = received DL RXLEV or DL RSCP average of the neighbour cell (n)

RXLEV_DL = received level average downlink of the serving cell

→ The receive level average of the neighbour cell must be higher than the receive level average of the serving cell plus the level handover margin set for the neighbour cell





Target Cell Ranking

All target cells that fulfil the handover minimum condition (4.) are included in the target cell list of theINTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘uplink strength’ or ‘downlinkstrength’, unless the number of target cells is restricted by the parameter NCELL (see SET HAND).

The target cells included in the INTERCELL HANDOVER CONDITION INDICATION are sorted indescending order of

PBGT(n) – HO_MARGIN(n)

PBGT (n) = power budget of the neighbour cell (n)

HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) in [dB]

Inter-cell HCI: target celllist

1. neighbour cell

Target cells are 2. neighbour cell

sorted in descending 3. neighbour cell

order of 4. neighbour cell

PBGT(n) - HOM(n) 5. neighbour cell

. . .

. . .

This means that the ranking algorithm considers the DL receive level of the neighbour cell as well as thehandover margin used for power budget handover. For more detailed information about PBGT(n) pleaserefer to section 2.1.2.5 (power budget handover).

The target cell ranking is different if the feature “Hierarchical Cell Structure (HCS)” is enabled. For moredetails please refer to the section 2.4.2.





2.1.2.2 Intra-cell handover (quality)

An Intra-cell handover (quality) is triggered by the BTS if all of the following conditions are fulfilled:

1. RXQUAL_XX > L_RXQUAL_XX_H XX = DL or UL


(the averaging is done according to the setting of HOAVQUAL (SET HAND))

L_RXQUAL_XX_H = HOLTHQUXX (SET HAND) = lower threshold value for quality handover

→ The received quality (i.e. bit error rate) average of the serving cell is higher thanthe value set for HOLTHQUXX

Note: For AMR calls, the RXQUAL threshold HOLTHQUXX is replaced by the C/I [dB] thresholdHOLTHQAMRXX. Thus for AMR calls, the handover decision is not based on the comparison of measuredRXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived from measuredRXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (1.) must be expressed asfollows:

1.(AMR) RXQUAL_XX converted to C/I [dB] < HOLTHQAMRXX [dB] XX = DL or UL

For futher details please refer to the section “Mapping of RXQUAL and C/I values for AMR calls” and theparameter descriptions of HOLTHQAMRDL and HOLTHQAMRUL.

2. RXLEV_XX > L_RXLEV_XX_IH XX = DL or UL

RXLEV_XX = received level average of the serving cell (incl. Power Control)*


L_RXLEV_XX_IH = HOTXXINT (SET HAND) = threshold value for intra BTS handover

→ The received level average of the serving cell is higher than the value set for HOTXXINT

Notes:- * For the condition (2.) the BTS does not automatically add the current dynamic power reduction to themeasured value (like e.g. for the PBGT HO) but it takes the current RXLEV value as measured by the BTSresp. the MS. This means that, if Power Control is enabled, the intracell handover due to quality is onlytriggered, when the PWRC algorithm has increased the power in such a way, that the condition (2.) isfulfilled!

In other words, PWRC does not have to adjust the power to the maximum to allow this handover to betriggered, but it must have increased the power to a level higher than HOTDLINT resp. HOTULINT, beforethis type of handover is triggered!- If INTRACH=FALSE, i.e. if the intra-cell handover is disabled in the BSC database, the thresholdHOTXXINT is not evaluated and the conditions which normally cause an intra-cell handover directly lead toan inter-cell handover (if RXQUALHO=TRUE).





Function the Skip Flag – Intracell/Intercell Toggling Mechanism for Quality Handovers For the quality handovers an Intracell/Intercell HO “toggling” mechanism is implemented in the BTS:If an intracell handover due to quality could not be successfully completed (e.g. if no target TCH is availablefor the for the intracell handover or if the access to the target TCH fails due to radio reasons), thesubsequent quality handover attempt will be an intercell handover attempt.This function is achieved by the so-called “skip flag”.The ‘skip flag’ is a system internal flag (not administrable via DB commands) that is basically set to FALSEfor every busy TCH. When an Intra-cell handover (quality) is triggered by the above mentioned conditions,

i.e. an INTRACELL HANDOVER CONDITION INDICATION is sent to the BSC, the skip flag is set to TRUEfor the used TCH. If the handover is successfully completed the TCH is released and the skip flag has norelevance anymore. However, if the call remains on the same TCH (which means that the handover attemptcould not be successfully completed) and another quality handover decision is made while the skip flag isTRUE, the BTS triggers an Inter-cell handover (quality).

General Note:The in tra-cel l handover in c oncentr ic c el ls (inner-complete and complete-inner) and for extended cel ls (near-to-far and far-to-near) are not considered in this context. For details on these types of intra-cell handover please refer to the diagrams 'Handover Parameter Relations' and the associatedparameter descriptions in the SET HAND command.





2.1.2.3 Inter-cell/Inter-system Handover due to quality


An Inter-cell handover (quality) is triggered by the BTS if all of the following conditions are fulfilled:

1. RXQUAL_XX > L_RXQUAL_XX_H XX = DL or UL


(the averaging is done according to the setting of HOAVQUAL (SET HAND))L_RXQUAL_XX_H = HOLTHQUXX (SET HAND) = lower threshold value for quality handover

→ The received quality (i.e. bit error rate) average of the serving cell is higher thanthe value set for HOLTHQUXX

Note: For AMR calls, the RXQUAL threshold HOLTHQUXX is replaced by the C/I [dB] thresholdHOLTHQAMRXX. Thus for AMR calls, the handover decision is not based on the comparison of measuredRXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived from measuredRXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (1.) must be expressed asfollows:

1.(AMR) RXQUAL_XX converted to C/I [dB] < HOLTHQAMRXX [dB] XX = DL or UL

For further details please refer to the section “Mapping of RXQUAL and C/I values for AMR calls” and the

parameter descriptions of HOLTHQAMRDL and HOLTHQAMRUL.

2. * RXLEV_XX < L_RXLEV_XX_IH XX = DL or UL



L_RXLEV_XX_IH = HOTXXINT (SET HAND) = threshold value for intra BTS handover

→ The received level average of the serving cell is lower than the value set for HOTXXINT

* Note: This condition is not relevant if intracell handover due to quality is disabled(INTRACH=FALSE). If this is the case then only the quality conditions are considered.

3. YY_TXPWR = Min(YY_TXPWR_MAX,P) YY = MS or BTS

YY_TXPWR = current MS- or BTS transmit power, value in [dBm]

YY_TXPWR_MAX = maximum MS- or BTS transmit power, value in [dBm]

whereMS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) (CREATE BTS

[BASICS])BS_TXPWR_MAX is determined by the used type of PA and the parameter PWRRED (CREATE TRX)


Min(YY_TXPWR_MAX,P)= YY_TXPWR_MAX if YY_TXPWR_MAX < P

Min(YY_TXPWR_MAX,P)= P if YY_TXPWR_MAX > P(for the mobile the maximum allowed transmit power is determined by its power classor by the administered value for MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) -depending on whichever is lower)

→ The transmit power of MS and BTS is at the maximum(since in this case PWRC is disabled this condition is fulfilled anyway)






A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘uplink quality’ or ‘downlink quality’ if it fulfilsthe handover minimum condition












* Remarks:1) For 2G-3G handover, the 3G neighbour cells are considered if EUHO=TRUE and EUIMPHO=TRUE (see

SET HAND) based on the reported RSCP value if the setting FDDREPQTY=RSCP (see SET BTS[BASICS]) is applied.For the reporting of the RSCP levels, please consider the explanations in section ‘Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells’.


If the optional feature “Level Handover Margin” is enabled (SET HAND:ENAQUALEVHOM=TRUE), thefollowing additional condition must be fulfilled

5. RXLEV_NCELL > RXLEV-DL + QUALLEVHOM(n)

QUALLEVHOM(n) = QUALLEVHOM (CREATE ADJC) = quality level handover margin of theneighbour cell (n) in [dB]

RXLEV_NCELL(n) = received DL RXLEV or DL RSCP average of the neighbour cell (n)


→ The receive level average of the neighbour cell must be higher than the receive level average of the serving cell plus the level handover margin set for the neighbour cell





Target Cell Ranking

All target cells that fulfil the handover minimum condition (4.) are included in the target cell list of theINTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘uplink quality’ or ‘downlinkquality’, unless the number of target cells is restricted by the parameter NCELL (see SET HAND).






1. neighbour cell





. . .

. . .







2.1.2.4 Inter-cell/Inter-system Handover due to distance


An Inter-cell handover (distance) is triggered by the BTS if the following condition is fulfilled:

1. MS_BS_DIST > MS_RANGE_MAX

MS_BS_DIST = actual distance between MS and BTS

MS_RANGE_MAX = HOTMSRM (SET HAND) = maximum distance between MS and BTS (standard cells)= HOTMSRME (SET HAND) = max. distance between MS and BTS (for extended cells)

→ The actual distance between MS and BTS is bigger than the value set for HOTMSRM (for standardcells) respectively HOTMSRME (for extended cells


A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘distance’ if it fulfils the handover minimumcondition











→ The actual receive level average of the neighbour cell must be higher than the sum of the

minimum receive level set for the neighbour cell and the correction term Max(0,Pa)

* Remarks:

1) For 2G-3G handover, the 3G neighbour cells are considered if EUHO=TRUE and EUIMPHO=TRUE (seeSET HAND) based on the reported RSCP value if the setting FDDREPQTY=RSCP (see SET BTS[BASICS]) is applied.For the reporting of the RSCP levels, please consider the explanations in section ‘Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells’.






Target Cell Ranking

All target cells that fulfil the handover minimum condition (2.) are included in the target cell list of theINTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘distance’, unless the number of target cells is restricted by the parameter NCELL (see SET HAND).






1. neighbour cell





. . .

. . .







2.1.2.5 Inter-cell/Inter-system Handover due to better cell (power budget handover)


The SBS handover algorithm performs the handover decision for imperative handovers (Level HO, QualityHO, Distance HO) always before a decision for a power budget handover is made. Assuming that noimperative handover has to be performed beforehand an inter-cell handover (power budget) is triggered if one or more neighbour cells are found which fulfil the condition

1. PBGT(n) > HO_MARGIN(n)

where PBGT(n) = RXLEV_NCELL(n) - (RXLEV_DL + PWR_C_D) +Min (MS_TXPWR_MAX, P) - Min (MS_TXPWR_MAX(n), P(n))


HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) in [dB] or

HOM (CREATE ADJC3G) = handover margin of the 3G neighbour cell (n) in [dB]

RXLEV_NCELL(n) = received DL RXLEV or DL RSCP average of the neighbour cell (n)*


(averaging is done according to the setting of HOAVPWRB (SET HAND)

PWR_C_D = BS_TXPWR_MAX - BS_TXPWR

= averaged difference between the maximum downlink RF power andthe actual downlink due to Power Control

Note: In this case PWR_C_D = 0 since Power Control is disabled.

MS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) value of the serving

cell (see CREATE BTS [BASICS]) in dBm= max. allowed transmit power of serving cell (n)




P = power capability of the mobile in the serving cell [dBm]

P(n) = power capability of the mobile in the neighbour cell n [dBm]

Min(MS_TXPWR_MAX,P)= MS_TXPWR_MAX if MS_TXPWR_MAX < P

Min(MS_TXPWR_MAX,P)= P if MS_TXPWR_MAX > P

→ The power budget of the neighbour cell must be higher than the handover margin setfor the neighbour cell

* Remarks:

1) For 2G-3G handover, the 3G neighbour cells are considered if EUHO=TRUE and EUBCHO=TRUE (seeSET HAND) based on the reported RSCP value if the setting FDDREPQTY=RSCP (see SET BTS[BASICS]) is applied.For the reporting of the RSCP levels, please consider the explanations in section ‘Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells’.






Important note for Dualband handovers (GSM->DCS or DCS-> GSM):

In case of dualband handovers the parameterization of the Handover Margin (HOM) has to be handled withspecial care as - depending on the bands of the serving and neighbouring cells - the PBGT can assume apositive or a negative value, even if the receive levels are equal.

Example: If BS power control is disabled and RXLEV_DL=RXLEV_NCELL, the PBGT is calculated by

PBGT(n) = RXLEV_NCELL(n) - RXLEV_DL + Min (MS_TXPWR_MAX, P) - Min (MS_TXPWR_MAX(n), P)

= 0 + Min (MS_TXPWR_MAX, P) - Min (MS_TXPWR_MAX(n), P)

The calculation is done for a dualband mobile with P=33dBm (GSM) and P=30dBm (DCS)

a) GSM -> GSM:

Serving cell GSM 900, MSTXPMAX=5 (=33dBm), neighbour cell GSM 900, MSTXPMAXCL=5 (=33dBm)

PBGT(n) = 33dBm - 33dBm = 0dB = ‘initial PBGT’ for neighbour cell relations of the same band

b) GSM -> DCS:

Serving cell GSM 900, MSTXPMAX=5 (=33dBm), neighbour cell DCS 1800, MSTXPMAXCL=0 (=30dBm),

PBGT(n) = 33dBm - 30dBm = 3dB = ‘initial PBGT’ for GSM->DCS neighbour cell relations

c) DCS -> GSM:

Serving cell DCS1800, MSTXPMAX=0 (=30dBm), neighbour cell GSM 900, MSTXPMAXCL=5 (=33dBm),

PBGT(n) = 30dBm - 33dBm = - 3dB = ‘initial PBGT’ for DCS->GSM neighbour cell relations

Conclusion: If the same effective Handover Margin (HOMeff ) is desired in both directions (same cellborder), the ‘initial PBGT’ must be taken into account in the following way when HOM (ADJC) is set:

a) GSM -> GSM and DCS -> DCS: HOM = HOMeff Example: HOMeff = 4dB -> HOM = 67 ( = 4dB)

b) GSM -> DCS: HOM = HOMeff + 3dB Example: HOMeff = 4dB -> HOM = 70 ( = 7dB)

c) DCS -> GSM: HOM = HOMeff - 3dB Example: HOMeff = 4dB -> HOM = 64 ( = 1dB)






A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘better cell’ if it fulfils the handover minimumcondition












* Remarks:1) For 2G-3G handover, 3G neighbour cells are considered if EUHO=TRUE (see SET HAND) based on the

reported RSCP value if the setting FDDREPQTY=RSCP (see SET BTS [BASICS]) is applied.For the reporting and handling of the RSCP levels, please consider the explanations in section ‘Reporting,Display and BTS internal handling of RSCP values from 3G neighbour cells’.


Target Cell Ranking

All target cells that fulfil the handover minimum condition (2.) and the power budget condition (1.) areincluded in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) withcause ‘better cell’, unless the number of target cells is restricted by the parameter NCELL (see SET HAND).






1. neighbour cell





. . .

. . .

This means that the ranking algorithm considers the DL receive level of the neighbour cell as well as thehandover margin used for power budget handover.






2.1.2.5.1 Speed sensitive handover enabled

Precondition: speed sensitive handover is enabled for the cell (SET HAND:DPBGTHO=TRUE;).

For those neighbour cells for which speed sensitive handover is enabled (CREATE ADJC:MICROCELL=TRUE) the HOM value is increased by the value entered for HOMSOFF for the durationof HOMDTIME. HOMDTIME is started when the normal power budget condition is detected for the first time.When it expires, the value entered for HOMDOFF is subtracted from the sum of HOM and HOMSOFF. Thus,if e.g. HOMSOFF and HOMDOFF have the same value the original power budget condition is re-

established.This means: for speed sensitive handover the power budget condition (1.) is not


but

1.* PBGT(n) > HO_MARGIN_TIME(n)

where HO_MARGIN_TIME(t,n) = HO_MARGIN(n) + HO_STATIC_OFFSET(n) for t ≤ HOMDTIMEHO_MARGIN_TIME(t,n) = HO_MARGIN(n) + HO_STATIC_OFFSET(n)

- HO_DYNAMIC_OFFSET(n) for t ≥ HOMDTIME

where

HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) HO_STATIC_OFFSET(n) = HOMSOFF (CREATE ADJC) = handover static offset of the neighbour cell (n) HO_DYNAMIC_OFFSET(n)= HOMDOFF (CREATE ADJC) = handover dynamic offset of the neighbr. cell (n)

* the timer HOMDTIME is started for every neighbour cell when the normal power budget condition (PBGT(n)>HO_MARGIN) is fulfilledand is stopped again if the condition disappears.

HO_MARGIN_TIME(t)

t

HOM + HOMSOFF

HOM + HOMSOFF - HOMDOFF

HOMDOFF

HOMSOFF

HOM

HOMDTIME

expiry of timer start of timer*





2.1.2.5 Inter-system Handover due to suifficient coverage


An inter-system handover due to sufficient UMTS coverage is triggered if

1. RSCP(n) > USRSCP(n)

RSCP (n) = current reported RSCP value of the 3G neighbour cell

USRSCP(n) = USRSCP (CREATE ADJC3G)= handover margin of the 3G neighbour cell (n) in [dB]


* Remarks:







2.1.2.6 Forced Handover due to directed retry, preemption or O&M intervention


Unlike the standard handover tasks, forced handovers due to directed retry, preemption or O&M interventionare not triggered by the BTS but by the BSC when specific forced handover conditions are met. The BSCtriggers the handover by sending a FORCED HANDOVER REQUEST to the BTS which in turn determinesthe suitable target cells for the handover transaction and inserts them into the target cell list of theINTERCELL HANDOVER CONDITION INDICATION (with cause ‘forced’) which is then sent to the BSC.

Thus the task of the BTS is restricted to the target cell list generation.


A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘forced’ if it fulfils the handover minimumcondition enhanced by an additional forced handover offset

1. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + FHO_RXLEV_MIN_OFFSET (n)




RXLEVMIN (CREATE ADJC3G) = minimum RSCP value of the 3G neighbour cell (n)FHO_RXLEV_MIN_OFFSET(n)= FHORLMO (CREATE ADJC), value in [dB]

= additional offset for RXLEVMIN of neighbour cell (n) to increase the minimum criteria

P = power capability of the mobile (in [dBm])


→ The actual receive level average of the neighbour cell must be higher than the sum of minimum receive level set for the neighbour cell and the correction term Max(0,Pa) plusthe neighbour cell specific forced handover offset

* Remarks:

1) For 2G-3G handover, 3G neighbour cells are considered if EUHO=TRUE (see SET HAND) based on the

reported RSCP value if the setting FDDREPQTY=RSCP (see SET BTS [BASICS]) is applied.For the reporting and handling of the RSCP levels, please consider the explanations in section ‘Reporting,Display and BTS internal handling of RSCP values from 3G neighbour cells’.






2.1.2.7 Fast Uplink Handover (Intra-BSC only)


An Inter-cell-handover due to fast uplink is triggered by the BTS if the following condition is fulfilled:

1. RXLEV_UL < THLEVFULHO

RXLEV_UL = received uplink level average of the serving cell

(the averaging is done according to the setting of ALEVFULHO (SET HAND))THLEVFULHO = THLEVFULHO (SET HAND) = uplink level threshold value for fast uplink handover

→ The received uplink level average of the serving cell is lower than the value set for THLEVFULHO

Important: Even if the UL pow er level drops below the THLEVFULHO whi le the PWRC algor i thm has

already reduced the UL transmit po wer, the fast upl ink hando ver is tr iggered without w ait ing for the

Power Contro l algor i thm to ad just the power to the maximum !


A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘fast uplink’ if it fulfils the handover minimum condition enhanced by an additional fast uplink handover offset

2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + FULRXLVMOFF(n)


RXLEV_NCELL(n) = received DL RXLEV or average of the neighbour cell (n)

(the averaging is done according to the setting of ALEVFULHO (SET HAND))RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) or


FULRXLVMOFF(n) = FULRXLVMOFF (CREATE ADJC) = fast uplink receive level offset

of the neighbour cell (n) in [dB] added to the handover minimum criteria

MS_TXPWR_MAX(n)= MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm]



Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0

Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

→ The actual receive level average of the neighbour cell must be higher than the sum of theminimum receive level set for the neighbour cell, the correction term Max(0,Pa) and thefast uplink handover offset.





Target Cell Ranking

The fast uplink handover target cells are subdivided into two groups: ‘Preferred’ or ‘predefined’ cells(FULHOC=TRUE, see ADJC object), or non-predefined cells (FULHOC=FALSE). The ranking mechanismcreates two sublists in the INTERCELL HANDOVER CONDITION INDICATION: the predefined cells makeup the upper sublist, the non-predefined cells are placed into the lower sublist. Within each sublist the cellsare sorted in descending order of PBGT(n)-HO_MARGIN(n) (HO_MARGIN = HOM in ADJC package).

Inter-cell HCI: target cell list

upper sublist: FULHOC=TRUE 1. neighbour cell

Sorting in descending FULHOC=TRUE 2. neighbour cell

order of FULHOC=TRUE 3. neighbour cell

PBGT(n) - HOM(n) . . .

. . .

lower sublist: FULHOC=FALSE n. neighbour cell

Sorting in descending FULHOC=FALSE n+1. neighbour cell

order of FULHOC=FALSE n+2. neighbour cell

PBGT(n) - HOM(n) . . .

. . .





2.1.2.8 Inter-cell Handover due to BSS Resource Management Criteria (Traffic HO)


The traffic handover has the lowest priority of all handover types within the BTS handover decisionalgorithm, i.e. the BTS only triggers a traffic handover after all other handover types have been evaluatedbefore. Assuming that no imperative handover has to be performed beforehand an inter-cell handover due totraffic is triggered if one or more neighbour cells are found which fulfil the condition

1. PBGT(n) > HO_MARGIN_TRAF(n) - K

where PBGT(n) = RXLEV_NCELL(n) - (RXLEV_DL + PWR_C_D) +Min (MS_TXPWR_MAX, P) - Min (MS_TXPWR_MAX(n), P)

and K = m * TRFMS (with TRFMS ε K ε TRFMMA)


HO_MARGIN_TRAF(n) = TRFHOM (CREATE ADJC)

= administrable traffic handover margin of the neighbour cell (n) in [dB]

K = dynamic (time-dependent) traffic handover margin reduction term

m = internal (time-dependent) counter that is increased/decreased on expiry of

TRFHOT (see SET HAND) if traffic handover is currently enabled/disabled in the BTS

TRFMS = traffic handover margin reduction step in [dB]TRFMMA = maximum traffic handover margin reduction in [dB]

RXLEV_NCELL(n) = received DL RXLEV average of the neighbour cell (n)





= averaged difference between the maximum downlink RF power andthe actual downlink due to Power ControlNote: In this case PWR_C_D = 0 since Power Control is disabled.

MS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) (CREATE BTS

[BASICS]), value in [dBm]= max. allowed transmit power of serving cell (n)

MS_TXPWR_MAX(n)= MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm]





→ The power budget of the neighbour cell must be higher than the effect ive traff ic handover m argin of the neighbour cell





Principle Description of Traffic Handover Margin Reduction and Increase

Definitions: As the term ‘traffic handover margin’ is misunderstandable, it seems useful to start the explanation withsome term definitions to avoid confusion about the used terms:

1) Administrable traffic handover margin The administrable traffic handover margin corresponds to the value in [dB] entered for the parameter TRFHOM (ADJC object).

→ administrable traffic handover margin = HO_MARGIN_TRAF(n) = TRFHOM(n), value in [dB]

Note: This administrable traffic handover margin is never actually used by the traffic handover decisionalgorithm in its pure form.

2) Effective traffic handover margin The effective traffic handover margin is the reduced, time-dependent traffic handover margin which isactually used by the traffic handover decision algorithm as it considers the administrable traffic handover margin as well as the reduction term:

→ effective traffic handover margin = HO_MARGIN_TRAF_TIME(n)

= HO_MARGIN_TRAF(n) – K

→ effective traffic handover margin = HO_MARGIN_TRAF(n) – m*TRFMS

3) Initial traffic handover margin The initial traffic handover margin is the value of the effective traffic handover margin in the first traffichandover decision period after the first start of TRFHOT. In this period the value ‘m’ assumes the value m=1,so that the administrable traffic handover margin is reduced by TRFMS.

→ initial traffic handover margin = HO_MARGIN_TRAF(n) – TRFMS (as m=1)

4) Minimum traffic handover margin The minimum traffic handover margin is the effective traffic handover margin with the maximum reduction asdefined by the parameter TRFMMA.

→ minimum traffic handover margin = HO_MARGIN_TRAF(n) – TRFMMA





Dynamic Traffic Handover Margin Reduction Process after traffic handover enabling by the BSC

The dynamic reduction and increase of the traffic handover margin is is controlled by the BTS timer TRFHOT(see CREATE ADJC). When the BTS has received the ‘traffic handover enabled’ message (SET ATTRIBUTE) the traffic handover decision algorithm is started.

Traffic Handover Decision Phase 1: Traffic handover enabled, period before first expiry of TRFHOTThis phase starts immediately after the receipt of the ‘traffic handover enabled’ message (SET ATT) from thefrom the BSC and triggers the following steps in the BTS:

• TRFHOT is started for the first time.

• The internal counter ‘m’ changes its value from m=0 to m=1.

• The traffic handover decision algorithm is started considering the initial traffic handover margin

This means that in this first decision phase the condition (2.) is defined as follows:

2.(1) PBGT(n) > HO_MARGIN_TRAF(n) - TRFMS

This means that, if for an ongoing call a neighbour cell is found, whose PBGT is higher than the initial traffic handover margin, the handover due to traffic is triggered.

Traffic Handover Decision Phase 2: Traffic handover enabled, period after first expiry of TRFHOTWhen TRFHOT expires and the traffic handover is still enabled ( i.e. no ‘traffic handover disabled’ messagewas received from the BSC) the BTS performs the following steps:

• TRFHOT is restarted.

• The internal counter ‘m’ is increased from m=1 to m=2.

• The traffic handover decision algorithm is started considering the effective traffic handover marginwith m=2.


2.(2) PBGT(n) > HO_MARGIN_TRAF(n) – 2*TRFMS

This means that, if for an ongoing call a neighbour cell is found, whose PBGT is higher than the initial traffic handover margin reduced by TRFMS, the handover due to traffic is triggered for that call.

Traffic Handover Decision Phase n: Traffic handover enabled, period after (n-1) expiries of TRFHOTWith every new expiry of TRFHOT the BTs performs the following steps

• TRFHOT is restarted

• The internal counter m is increased by 1.

• Another traffic handover decision period starts in which the effective handover margin is reduced byTRFMS (compared to the previous TRFHOT period) so that the condition (2.) is defined as follows:

2.(n) PBGT(n) > HO_MARGIN_TRAF(n) – m*TRFMS with m*TRFMS < TRFMMA

Important: this is true as long as the reduction (m*TRFMS) has not yet reached the maximum reductionTRFMMA (see SET HAND)!

Final Traffic Handover Decision Phase – traffic handover enabled, maximum margin reduction reachedThe reduction of the effective traffic handover margin is restricted to TRFMMA (see SET HAND). This meansthat, when the reduction term has reached the value TRFMMA, the BTS performs the following steps:

• TRFHOT is restarted

• The internal counter ‘m’ is not increased any further but keeps its current value

• The traffic handover decision algorithm is started considering the minimum traffic handover marginwith m=2.


2.(final) PBGT(n) > HO_MARGIN_TRAF(n) – m max*TRFMS (m max = TRFMMA div TRFMS)

This means that, if for an ongoing call a neighbour cell is found, whose PBGT is higher than the minimumtraffic handover margin, the handover due to traffic is triggered for that call.





Dynamic Traffic Handover Margin Reduction Process after traffic handover enabling by the BSC

When the BTS receives the ‘traffic handover disabled’ indication in the SET ATTRIBUTE message from theBSC while the traffic handover decision process (and the TRFHOT cycle) is running, the BTS performs thefollowing steps:

• TRFHOT is restarted.

• The internal counter ‘m’ is decreased by 1.

• Another traffic handover decision period starts in which the effective handover margin is increased by

TRFMS (compared to the previous TRFHOT period).If the traffic handover remains disabled, every new expiry of TRFHOT leads to another decrease of ‘m’.When ‘m’ has reached the value m=0, the traffic handover decision is stopped in the BTS.

The maximum value of ‘m’ is determined by the integer division of TRFMMA and TRFMS:

mmax = TRFMMA div TRFMS (e.g. TRFMMA=9, TRFMS=2 -> mmax = 9 div 2 = 4).

Thus TRFMMA can never be exceeded even if TRFMMA is no integer multiple of TRFMS.

Principle Diagram of Traffic Handover Margin Reduction and Increase

The following diagrams illustrate the dynamic traffic handover reduction/increase mechanism:

ime zone

TRFHOT

firstexpiry of TRFHOT

Traffic HO

enabledindicationreceivedfrom BSC


secondexpiry of TRFHOT

Start of second traffic HO decision phase withreduced traffic HO margin


Start of first traffic HO decision phase withInitial traffic HO margin


thirdexpiry of TRFHOT

If n*TRFMS has reached TRFMMA and trafficHO remains enabled, the traffic HO marginreduction remains stable (=TRFMMA) for allsubsequent expiries of TRFHOT.

Start of third traffic HO decision phase withreduced traffic HO margin


Principle of the traffic handover margin reduction mechanism when traffichandover is enabled:

ime zone

TRFHOT

expiry of TRFHOT

Traffic HO

disabledindicationreceivedfrom BSC


expiry of TRFHOT



expiry of TRFHOT

If the traffic HO remains disabled, andthe traffic HO margin reaches the initialvalue TRFHOM – 1*TRFMS, thehandover decision process is stopped onthe next expiry of TRFHOT.

Principle of the traffic handover margin increase mechanism when traffic

handover is disabled:






A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘traffic’ if it fulfils the handover minimumcondition

2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + Traffic_HO_Offset(n)


RXLEV_NCELL(n) = received DL RXLEV average of the neighbour cell (n)



RXLEVMIN (CREATE ADJC3G) = minimum RSCP value of the 3G neighbour cell (n)MS_TXPWR_MAX(n)= MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm]


Traffic_HO_Offset(n)= TRFHORXLVMOFF (CREATE ADJC) = administrable traffic handover offset of

the neighbour cell (n)



→The actual receive level average of the neighbour cell must be higher than the sum of minimum receive level set for the neighbour cell and the correction term Max(0,Pa)





Target Cell Ranking

All target cells that fulfil the handover minimum condition (2.) and the traffic handover power budgetcondition (1.) are included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION(BWHCI) with cause ‘traffic’, unless the number of target cells is restricted by the parameter NCELL (seeSET HAND).






1. neighbour cell





. . .

. . .


If the feature Hierarchical Cell Structure is enabled (HIERC=TRUE, see SET HAND), it is possible to restricttraffic handovers only to those neighbour cells that have exactly the same priority as the serving one.

This is done by the parameter TRFKPRI.If TRFKPRI=TRUE, an adjacent cell may only be a traffic handover target cell if it has an equal priority level(see parameter PLNC in the ADJC object) like he serving cell (see parameter PL).If TRFKPRI=FALSE, an adjacent cell may be a traffic handover target cell if it has an equal or higher prioritylevel like he serving cell.

Please see also section ‘Target Cell Ranking for Traffic Handover with HCS’.





2.2 Hierarchical Cell Structure

2.2.1 Cell ranking for power budget handovers (non-imperative handover)

The SBS handover algorithm performs the handover decision for imperative handovers always before adecision for a power budget handover is made. Assuming that no imperative handover has to be performedbeforehand an inter-cell handover (power budget) is performed if all of the following conditions are fulfilled:

A) A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the HANDOVER CONDITION INDICATION if

1. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)




MS_TXPWR_MAX(n)= MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm]= max. allowed transmit power of neighbour cell (n)

P = power capability of the mobile in [dBm] Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

and









= averaged difference between the maximum downlink RF power andthe actual downlink due to Power Control

Note: In this case PWR_C_D = 0 since Power Control is disabled.MS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) value of the serving



MSTXPMAXUMTS (TGTFDD object), value in [dBm]= max. allowed transmit power of neighbour cell (n)





* Remarks:1) For 2G-3G handover, the 3G neighbour cells are considered if EUHO=TRUE and EUBCHO=TRUE (see

SET HAND) based on the reported RSCP value if the setting FDDREPQTY=RSCP (see SET BTS[BASICS]) is applied.For the reporting of the RSCP levels, please consider the explanations in section ‘Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells’.






and

3. PRIO_NCELL(n) ≤ PRIO_SCELL

PRIO_NCELL = PLNC (CREATE ADJC/ADJC3G) = priority layer assigned to the (3G) neighbour cell= PPLNC (CREATE ADJC/ADJC3G) = penalized priority layer assigned to

the (3G) neighbour cell (relevant only if speed sensitive handover is enabled)

PRIO_SCELL = PL (SET HAND) = priority layer assigned to the serving cell

Attention: The lower the value of the parameters PL and PLNC, the higher the priority level!0 = highest priority level, 15 = lowest priority level.

B) The cells in the target cell list of the HANDOVER CONDITION INDICATION message are orderedaccording to their priority (not according to their level).

priority Inter-cell HCI: target cell list

0 1. neighbour cell

2. neighbour cell

3. neighbour cell4. neighbour cell

5. neighbour cell

. . .

15 . . .

Cells with the same priority level are ordered according to the value of PBGT(n) - HO_MARGIN(n).

2.2.1.1 Speed sensitive handover enabled

Precondition: speed sensitive handover is enabled for the cell (SET HAND:DPBGTHO=TRUE).

For those neighbour cells for which speed sensitive handover is enabled (CREATE ADJC/CREATE

ADJC3G:MICROCELL=TRUE) the power budget handover decision algorithm considersa) the HO_MARGIN_TIME instead of HO_MARGIN.For details please refer to section 2.1.2.5.1 (Power Budget Handover / Speed sensitive handover).

b) the ‘penalty priority layer of neighbour cell’ (PPLNC) instead of ‘priority layer of neighbour cell’ (PLNC)as long as the handover margin delay timer (HOMDTIME) runs.For details please refer to the parameter description for the parameters PLNC, PPLNC and HOMDTIME inthe command CREATE ADJC/CREATE ADJC3G and to section 2.1.2.5.1 (Power Budget Handover / Speedsensitive handover).

.





2.2.2 Cell ranking for imperative handovers (due to level, quality anddistance) and forced handover (directed retry)

Note: The feature HCS does not have any influence on the ranking of target cells in the HCIs for Fast UplinkHandover. For Fast Uplink Handover the standard target cell ranking can be influenced by the parameter FULHOC (see CREATE ADJC), which is not coupled to HCS.

2.2.2.1 Ranking method 0If the cell ranking method RANK 0 (SET HAND:HIERF=RANK0;) is in effect for imperative handovers(i.e. handovers due to level, quality or distance) the cell ranking is done in the following way:

A) A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the HANDOVER CONDITION INDICATION if the following conditions are fulfilled:

for imperative handovers

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)



RXLEVMIN (CREATE ADJC3G) = minimum RSCP value of the 3G neighbour cell (n)MS_TXPWR_MAX(n)= MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or



for forced handover (directed retry)

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + FHO_RXLEV_MIN_OFFSET(n)





P = power capability of the mobile in [dBm]FHO_RXLEV_MIN_OFFSET(n) = FHORLMO (CREATE ADJC), value in [dBm]

= forced handover receive level minimum offset of adjacent cell (n) Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

continuation see next page...





B) The cells in the target cell list HANDOVER CONDITION INDICATIONare subdivided into two sublists:

1. The upper sublist consists of all cells with

PBGT(n) - HO_MARGIN(n) > 0

2. The lower sublist consists of all cells with

PBGT(n) - HO_MARGIN(n) ≤ 0

where PBGT(n) = RXLEV_NCELL(n) - (RXLEV_DL + PWR_C_D) +Min(MS_TXPWR_MAX, P) - Min(MS_TXPWR_MAX(n),P(n))







= averaged difference between the maximum downlink RF power andthe actual downlink due to Power ControlNote: In this case PWR_C_D = 0 since Power Control is disabled.

MS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) value of the serving








→ The power budget of the neighbour cell must be higher than the handover margin setfor the neighbour cell

* Remarks:







3. Within each sublist the cells in the target cell list HANDOVER CONDITION INDICATION are orderedaccording to their priority.



0 1. neighbour cell

upper sublist: 2. neighbour cell

PBGT - HO_MARGIN > 0 3. neighbour cell

. . .

15 . . .

0 n. neighbour cell

lower sublist: n+1. neighbour cell

PBGT - HO_MARGIN ≤ 0 n+2. neighbour cell

. . .

15 . . .

Attention: The lower the value of the parameter PLNC, the higher the priority level!0 = highest priority level, 15 = lowest priority level.





2.2.2.2 Ranking method 1

If the cell ranking method RANK 1 (SET HAND:HIERF=RANK1;) is in effect for imperative handovers(i.e. handovers due to level, quality or distance) the cell ranking is done in the following way:

A) A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the HANDOVER CONDITION INDICATION if the following conditions are fulfilled:

for imperative handovers (handover due to level, quality and distance)

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)






for forced handover (directed retry)

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + FHO_RXLEV_MIN_OFFSET(n)





P = power capability of the mobile in [dBm]FHO_RXLEV_MIN_OFFSET(n) = FHORLMO (CREATE ADJC), value in [dBm]

= forced handover receive level minimum offset of adjacent cell (n) Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

continuation see next page...





B) The cells in the target cell list HANDOVER CONDITION INDICATIONare subdivided into two sublists:

1. The upper sublist consists of all cells with

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + LEVONC(n)

2. The lower sublist consists of all cells with

RXLEV_NCELL(n) ≤ RXLEVMIN(n) + Max(0,Pa) + LEVONC(n)



= RXLEVMIN (CREATE ADJC3G) = minimum RSCP value of the 3G neighbour cell (n)MS_TXPWR_MAX(n)= MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or



Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0 LEVONC(n) = LEVONC (CREATE ADJC) = level offset of neighbour cell for ranking method 1 or

= LEVONC (CREATE ADJC3G) = level offset of neighbour 3G cell for ranking method 1

3. Within each sublist the cells in the target cell list HANDOVER CONDITION INDICATION are orderedaccording to their priority.



upper sublist: 0 1. neighbour cell

RXLEV_NCELL(n) > 2. neighbour cell

RXLEVMIN(n) + Max(0,Pa) 3. neighbour cell

+ LEVONC(n) 4. neighbour cell

15 5. neighbour cell

lower sublist: 0 . . .RXLEV_NCELL(n) ≤ . . .

RXLEVMIN(n) + Max(0,Pa) . . .

+ LEVONC(n) . . .

15 . . .






2.2.3 Target Cell Ranking for Traffic Handover with HCS

As without HCS enabled, the target cells included in the INTERCELL HANDOVER CONDITIONINDICATION are sorted in descending order of





If the feature Hierarchical Cell Structure is enabled (HIERC=TRUE, see SET HAND) basically all target cellsthat fulfil the handover minimum condition (2.) and the traffic handover power budget condition (1.) and thathave an equal or higher priority level (parameter PLNC, see CREATE ADJC) like the serving cell (parameter PL, see SET HAND) are included in the target cell list of the INTERCELL HANDOVER CONDITIONINDICATION (BWHCI) with cause ‘traffic’, unless the number of target cells is restricted by the parameter NCELL (see SET HAND).

Thus, to be included in the traffic handover target cell list (with HCS enabled) a neighbour cell must in anycase fulfil the following condition to be included in the target cell list of the BWHCI:

PRIO_NCELL(n) ≤ PRIO_SCELL

PRIO_NCELL = PLNC (CREATE ADJC) = priority layer assigned to the neighbour cell

= PPLNC (CREATE ADJC) = penalized priority layer assigned to the neighbour cell(relevant only if speed sensitive handover is enabled)

PRIO_SCELL = PL (SET HAND) = priority layer assigned to the serving cell


It is, however, possible to restrict traffic handovers only to those neighbour cells that have exactly the samepriority as the serving cell. This is done by the parameter TRFKPRI (see SET HAND):

a) If TRFKPRI=FALSE (default value), an adjacent cell may be a traffic handover target cell if it has an equalor higher priority level like he serving cell.


1. neighbour cell, PLNC(1) ≤ PL

Target cells are 2. neighbour cell, PLNC(2) ≤ PL

sorted in descending 3. neighbour cell, PLNC(3) ≤ PL

order of 4. neighbour cell, PLNC(4) ≤ PL

PBGT(n) - HOM(n) 5. neighbour cell, PLNC(5) ≤ PL

. . .

. . .

b) If TRFKPRI=TRUE, an adjacent cell may only be a traffic handover target cell if it has an equal prioritylevel (see parameter PLNC in the ADJC object) like he serving cell (see parameter PL).


1. neighbour cell, PLNC(1) = PL

Target cells are 2. neighbour cell, PLNC(2) = PL

sorted in descending 3. neighbour cell, PLNC(3) = PL

order of 4. neighbour cell, PLNC(4) = PL

PBGT(n) - HOM(n) 5. neighbour cell, PLNC(5) = PL

. . .

. . .





2.3 Sequence of Handover Types within the Handover DecisionAlgorithm in the BTS

Within the BTS handover decision algorithm, the handover conditions are checked in a certain sequence,that reflects the priority (or the ‘urgency’) of the respective handover type (e.g. GSM denotes power budgetas ’normal criterion’ and the other causes such as handover due to level , quality and distance as ‘alarmcriteria’ - these handovers are also called ‘imperative handovers’.

Handover decisions are taken according to the following priorities as listed in the following table:

Priority HO-Condition

1 Intercell handover due to Fast Uplink

2 Intracell handover in Extended Cell

• near -> far (single timeslot -> double timeslot)

• far -> near (double timeslot -> single timeslot)

3 Intracell handover in Concentric Cell *)

• inner -> complete

• complete -> inner

Intracell handover in Concentric Cell (GSMDCS/GSMPCS Mixed Cell)

• inner -> complete

• complete -> inner

4 Intercell handover due to Quality

5 Intercell handover due to Level

6 Intercell handover due to Distance

7 Inter-System handover due to UMTS sufficient coverage

8 Intercell handover due to Power Budget (‘better cell’ handover)

9 Intercell handover due to Resource Management Criteria (Traffic HO)

10 Intracell handover due to Quality

11 Intercell handover due to

• Compression (FR -> HR)

• Decompression (HR -> FR)

*) not used if UMTS sufficient is possible

The effect of this priority sequence is the following:

If the conditions for two or more different handover types are fulfilled at the same time, the BTS will alwaystrigger that type of handover (by checking for available target cells in the target cell list generation processand by sending a corresponding HANDOVER CONDITION INDICATION) which comes first in the prioritysequence.

If such a decision was made and the HANDOVER CONDITION INDICATION was sent to the BSC, the BTSsuspends all further handover decisions for the time defined by the parameter THORQST (timer for handover request, see command SET HAND [BASICS]).

When THORQST expires, the handover decision algorithm starts again from scratch. This means that, thesame handover decision will be made by the BTS if the conditions are exactly the same as before (when the

previous handover decision was made).Example: Assuming that the current RXQUAL / C/I conditions are given in such a way that both the conditions for quality intercell handover and decompression handover are fulfilled, the BTS will always trigger the qualityhandover first (assuming that the transmit power is at the maximum) and will stop the algorithm.Even if the target cell list generation process does not find any suitable target cell for the quality handover,the INTERCELL HANDOVER CONDITION INDICATION will be sent with an empty target cell list - no further handover decision is made until THORQST expires. If the conditions remain the same, also the triggeredhandover type will be the same.





2.4 Power Control Thresholds & Algorithms

2.4.1 Functional Diagram: Power Control Thresholds -Power Increase / Power Decrease (Classic Power Control)


GSM Parameter Name DB parameter Name

(SET PWRC)

Meaning

L_RXLev_DL_P LOWTLEVD power control lower level threshold downlink

L_RXLev_UL_P LOWTLEVU power control lower level threshold downlink

U_RXLev_DL_P UPTLEVD power control upper level threshold downlink

U_RXLev_UL_P UPTLEVU power control upper level threshold uplink

L_RXLev_XX_P +

2(dB)∗ POW_RED_STEP_SIZE

LOWTLEVX +PWREDSS

power control lower threshold +configured power reduction step size

L_RXQual_DL_P LOWTQUAD power control lower quality threshold downlink

L_RXQual_UL_P LOWTQUAU power control lower quality threshold uplink

U_RXQual_DL_P UPTQUAD power control upper quality threshold downlink

U_RXQual_UL_P UPTQUAU power control upper quality threshold uplink

Bit-Error-Rate (RXQual)

Level (RXLev)

L_RXQual_XX_P

U_RXQual_XX_P

L_RXLev_XX_P L_RXLev_XX_P +2(db)*Pow-Red-Step-Size

U_RXLev_XX_P

Power Increase

Power-Control

LOWTQUAX

UPTQUAX

UPTLEVXLOWTLEVX

LOWTLEVX +PWREDSS

X=D : DownlinkX=U : Uplink


no Power Control

Power Decrease

Power Decrease

Power Increase





2.4.2 Rules: Power Control Thresholds: Power Increase / Power Decrease

2.4.2.1 Power Increase

The TRX Power is increased if one of the following conditions is fulfilled:

1. RXLEV_XX < L_RXLEV_XX_P XX = DL or UL


(the averaging is done according to the setting of PAVRLEV (SET PWRC))

L_RXLEV_XX_P = LOWTLEVX (SET PWRC) = power control lower level threshold

→ The received level average of the serving cell is lower than the value set for LOWTLEVX

2. RXQUAL_XX > L_RXQUAL_XX_P XX = DL or UL


(the averaging is done according to the setting of PAVRQUAL (SET PWRC))

L_RXQUAL_XX_P = LOWTQUAX (SET PWRC) = power control lower quality threshold

→ The received quality average of the serving cell is higher than the value set for LOWTQUAX

Note: For AMR calls, the RXQUAL threshold LOWTQUAX is replaced by the C/I [dB] thresholdLOWTQUAMRXX. Thus for AMR calls, the power control decision is not based on the comparison of measured RXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived frommeasured RXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (2.) must beexpressed as follows:

2.(AMR) RXQUAL_XX converted to C/I [dB] < LOWTQUAMRXX [dB] XX = DL or UL

For futher details please refer to the section “Mapping of RXQUAL and C/I values for AMR calls” and theparameter descriptions of LOWTQUAMRDL and LOWTQUAMRUL.





2.4.2.2 Power Decrease

1) The TRX Power is decreased if both of the following conditions are fulfilled:

1a. RXLEV_XX ≥ L_RXLev_XX_P + 2∗ POW_RED_STEP_SIZE XX = DL or UL



L_RXLEV_XX_P = LOWTLEVX (SET PWRC) = power control lower level threshold

2∗ POW_RED_STEP_SIZE= PWREDSS (SET PWRC) = configured power reduction step size

→ The received level average of the serving cell is higher than the sum of the valueset for LOWTLEVX and 2 times the value set for PWREDSS

1b. RXQUAL_XX < U_RXQUAL_XX_P XX = DL or UL



U_RXQUAL_XX_P = UPTQUAX (SET PWRC) = power control upper quality threshold

→ The received quality average of the serving cell is lower than the value set for UPTQUAX

Note: For AMR calls, the RXQUAL threshold UPTQUAX is replaced by the C/I [dB] threshold

UPTQUAMRXX. Thus for AMR calls, the power control decision is not based on the comparison of measured RXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived frommeasured RXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (2.) must beexpressed as follows:

1b.(AMR) RXQUAL_XX converted to C/I [dB] > UPTQUAMRXX [dB] XX = DL or UL

For further details please refer to the section “Mapping of RXQUAL and C/I values for AMR calls” and theparameter descriptions of UPTQUAMRDL and UPTQUAMRUL.

OR

2) The TRX Power is decreased if both of the following conditions are fulfilled:

2a. RXLEV_XX > U_RXLEV_XX_P XX = DL or UL



U_RXLEV_XX_P = UPTLEVX (SET PWRC) = power control upper level threshold

→ The received level average of the serving cell is higher than the value set for UPTLEVX

2b. RXQUAL_XX < L_RXQUAL_XX_P XX = DL or UL



L_RXQUAL_XX_P = LOWTQUAX (SET PWRC) = power control lower quality threshold

→ The received quality average of the serving cell is lower than the value set for LOWTQUAX

Note: For AMR calls, the RXQUAL threshold LOWTQUAX is replaced by the C/I [dB] thresholdLOWTQUAMRXX. Thus for AMR calls, the power control decision is not based on the comparison of measured RXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived frommeasured RXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (2.) must beexpressed as follows:

2b.(AMR) RXQUAL_XX converted to C/I [dB] > LOWTQUAMRXX [dB] XX = DL or UL

For further details please refer to the section “Mapping of RXQUAL and C/I values for AMR calls” and theparameter descriptions of UPTQUAMRDL and UPTQUAMRUL.





2.4.3 Classic and Adaptive Power Control

2.4.3.1 Introduction

Power Control allows the increase respectively reduction of the UL and DL transmit power to react to currentradio conditions. As indicated in the previous sections, power control can be triggereda) due to specific RX level conditions: if the current RXLEV is too low, PWRC will increase the transmitpower to ensure a proper receive level on the receiving side and to prevent call dropsb) due to specific RX quality conditions: if the current RXQUAL value is too high (i.e. the corresponding C/Ivalue is too low), PWRC will increase the transmit power to ensure a proper receive quality on the receivingside and to prevent call drops.c) a combination of both level and quality conditions.

On the other hand, if the level and quality conditions are very good, the BTS shall reduce the power as far aspossible to minimize interference on the radio interface.

Starting from BR7.0, the operator can choose two types of Power Control: ‘CLASSIC’ or ‘ADAPTIVE’. Thesetwo power control types can be enabled separately for MS power control and BS power control in aparticular cell.

For the parameters EBSPWRC and EMSPWRC the possible values are CLASSIC, ADAPTIVE andDISABLED.

2.4.3.2 Classic Power Control decision process

Classic power control is in effect if the settings EBSPWRC=CLASSIC respectively EMSPWRC=CLASSICare applied. In the implementation before BR7.0 only the ‘classic’ power control was possible : this ‘classic’PWRC features a linear power increase in step sizes of PWRINCSS (min. 2dB) with a minimum timedifference between two consecutive power control increase or decrease steps defined by the parameter PCONINT (for BS power control only; for MS power control the time difference between two consecutivepower control steps is longer, for further details please see section ‘Functional sequence’).

The classic power control decision is performed in correspondence with the following diagram:

where: + = standard power increase by: PWRINCSS * 2dB

- = standard power reduction by: PWREDSS * 2dB

0 = no power change

low_lev = LOWTLEVD / LOWTLEVU

up_lev = UPTLEVD / UPTLEVUlow_qual = LOWTQUAD / LOWTQUAU (for non-AMR calls)

= LOWTQUAMRDL / LOWTQUAMRUL (for AMR calls)

up_qual = UPTQUAD / UPTQUAD (for non-AMR calls)= LOWTQUAMRDL / LOWTQUAMRUL (for AMR calls)

ATTENTION! please be aware that in this diagram the y-axis (RXQUAL and C/I values) are the other way round than in the diagram shown in section 2.2.1!

RXLE

up_qual

low_qual

0 / 30

7 /

0 6low_lev up_lev

1

a

2 3

4 5 6

7 8 9

b

PWREDSS

+

+

+ + +

0 -

--0

non-AMR / AMR RXQUAL / C/I





2.4.3.3 Adaptive Power Control decision process

In BR7.0 the so-called ‘adaptive’ power control was introduced. Adaptive power control is in effect if thesettings EBSPWRC=ADAPTIVE respectively EMSPWRC=ADAPTIVE are applied. This type of power controlallows a faster power increase (and also faster power reduction) under specific radio conditions. The stepsize for the power increase is in this case not defined by a static respectively semipermanent databasesetting but it is calculated on the basis of the configured power control level thresholds and the currentlymeasured RXLEV value.

The new adaptive power control decision is performed in correspondence with the following diagram:

where: + = standard power increase by: PWRINCSS * 2dB

- = standard power reduction by: PWREDSS * 2dB

0 = no power change

+A = fast power increase by: abs((0.5 * (up_lev + low_lev)) – RXLEV) [dB]

+B = fast power increase by: abs(low_lev – RXLEV) [dB]

- C = fast power decrease by: dB_diff [dB] (see explanation below)

low_lev = LOWTLEVD / LOWTLEVU

up_lev = UPTLEVD / UPTLEVU

low_qual = LOWTQUAD / LOWTQUAU (for non-AMR calls)= LOWTQUAMRDL / LOWTQUAMRUL (for AMR calls)

up_qual = UPTQUAD / UPTQUAD (for non-AMR calls)= LOWTQUAMRDL / LOWTQUAMRUL (for AMR calls)

2.4.3.4 Differences between CLASSIC and ADAPTIVE power control decision

Classic power increase (quadrants 8 and 9)The classic (slow) power increase (+) in the quadrants 8 and 9 (bad quality in conjunction with medium or high RXLEV values - in this scenario the bad quality is most probably caused by interference) is the same as

in case of the classic power control. Only exception: the power control delay timer is not defined by theparameter PCONINT but by the length of the power control quality averaging window, extended by 1(PAVRQUAL+1) for BS Power Control, reduced by 1 (PAVRQUAL-1) for MS Power Control (see belowsection ‘Functional sequence of a power control procedure’).

Classic power decrease (quadrant 2b)The classic (slow) power decrease in quadrant 2b (good quality in conjunction with medium or high RXLEVvalues) is exactly the same as in case of the classic power control. Adaptive power decrease (quadrant 3)For the power reduction in quadrant 3 a change request (CR2568) was implemented in BR8.0 to further accelarate the power reduction. In BR7.0 the acceleration was achieved by simply omitting the power controldelay timer between subsequent power reduction steps (the size of which corresponded to the operator defined reduction step size PWREDSS).

RXLE

up_qua

low_qual

0 /

7 /

0 6

1

a

2 3

4 5 6

7 9

b

PWREDSS

+

+ +

0 0

--0

low_lev up_lev

+

+A

non-AMR / AMR RXQUAL / C/I

8





As opposed to that, in BR8.0- the power reduction step is calculated based on the current level and quality conditions and- the delay timer may be applied again depending on the size of the calculated power reduction step.

In detail, in BR8.0 the power reduction in quadrant 3 is performed as follows:

1) At first the BTS determines the ‘allowed maximum power reduction step based on qual i ty cr i ter ia ‘(‘qual_diff’) by calculating the difference of the current quality to the ‘medium desired quality’ (RXQUALvalues will be converted to C/I values in dB first):

qual_diff = current_average_qual – ((up_qual + low_qual) / 2) [Result as integer value in dB]

where

up_qual = UPTQUAD / UPTQUAU [RXQUAL value converted to C/I value in dB]

low_qual = LOWTQUAD / LOWTQUAU [RXQUAL value converted to C/I value in dB]

current_average_qual = arithmetic mean of received RXQUAL values, mapped to C/I value in dB

Expressed in words, the above calculation considers the current quality by its C/I value and, assuming thatthe ‘medium desired quality’ is the arithmetic mean of the upper and the lower power control threshold,determines how much the power (i.e. the ‘C’ value of the C/I term) can be reduced without the qualitydropping below the ‘medium desired quality’. The resulting power reduction step is called ‘qual_diff’ in thiscalculation and can be regarded as ‘allowed maximum power reduction step based on quality ’.

2) Then the BTS determines the ‘allowed maximum power reduction step based on level criteria ’(‘lev_diff’) by simply calculating the difference between the current RXLEV average and the upper power

control level threshold:

lev_diff = average_level – up_lev

where

up_lev = UPTLEVD / UPTLEVU

average_level =arithmetic mean of received RXLEV values in dB

3) Finally the BTS determines the ‘allowed maximum power reduction step’ (‘dB_diff’) by simply takingthe smaller of the two values qual_diff or lev_diff .

dB_diff = MIN(qual_diff, lev_diff)

Expressed in words, the above calculation compares the previously calculated ‘allowed maximum power reduction step based on quality ’ (‘qual_diff’) and ‘allowed maximum power reduction step based on level ’(‘lev_diff’), declares the smaller of the two values as ‘dB_diff’ and uses this value as power reduction step inquadrant 3 instead of the decrease step size set by the operator (PWREDSS).

Use of the power control delay timer in quadrant 3If the calculated decrease step size is above 4dB, then additionally after having received the MS power levelconfirmation, the (existing) power control delay timer (which corresponds to the length of the power controlquality averaging window PAVRQUAL+1 for BS Power Control, and PAVRQUAL-1 for MS Power Control) isstarted to collect new quality measurements for the complete quality averaging window to make sure that thenext power control decision is based on the quality measurement data that was caused by the latest power level change. If the power decrease step is <4dB, then the delay timer is not applied, even if the resultingtransmit power (after the decrease step) ends up in quadrant 2b. In other words, the decision whether thedelay timer is started (and thus applied before the next decrease step) is made simultaneously together withthe power decrease decision.

Additionally, to improve the robustness against fast changing radio conditions a mechanism is implementedwhich, after a prior decrease step, checks whether conditions worsened so much that now an increase step

would be ordered. This check is executed for the first time after the confirmation of the new power setting(which means: for BS Power Control immediately and for MS Power Control after 3 SACCH periods) andthen as long as (and if) the power control delay timer (=PAVRQUAL+1 for BS Power Control, and=PAVRQUAL-1 for MS Power Control) is running. This avoids the delay of a necessary power increase stepespecially in cases with high power control delay timer values (e.g. in case of long averaging windows) andradio conditions that worsen considerably in the meantime. Also this mechanism is implemented for “adaptive” PC mode only.

Power Control in quadrant 6In quadrant no. 6, as opposed to classic power control, no power decrease is applied in case of adaptivepower control, as the quality values are only in medium but not good figures.





Fast power increase 1 (quadrant 7)Quadrant 7 represents the most critical radio situation: low RXLEV and bad quality. In this scenario the badquality is most probably caused by poor coverage conditions or problems on the radio path.In this situation, adaptive power control applies the most drastic variant of fast power increase (A+). In thiscase the power increase step is calculated as follows

adaptive power increase step [dB] = abs((0.5 * (up_lev + low_lev)) – RXLEV) [dB]

Expressed in words, the increase step is calculated as the difference between the arithmetic mean of theupper and lower PWRC level thresholds on the one hand and the current RXLEV value on the other hand.

Fast power increase 2 (quadrants 1 and 4)Quadrant 1 and 4 represent a less critical radio situation: low RXLEV values but medium or good qualityvalues: In this scenario the medium/good quality is most probably possible due to excellent interferenceconditions (very low interference).In this situation, adaptive power control applies a less drastic type of fast power increase (B+), as thequality values are, despite the low levels, still in acceptable dimensions.

In this case the power increase step is calculated as follows

adaptive power increase step [dB] = abs(low_lev – RXLEV) [dB]

Expressed in words, the increase step is calculated as the difference between the lower PWRC level

threshold and the current RXLEV value.

2.4.3.5 Functional sequence of a BS and MS power control procedure

2.4.3.5.1 BS power control procedure

1) The BTS makes a power control decision (increase or power reduction) based on the currently receiveddownlink MEASUREMENT REPORTs from the MS and increases or reduce the power for the affected TCH.The requested power change is immediately regarded as ‘executed and adjusted’ (i.e. no further internalpower control confirmation signalling takes place) and the BTS starts the delay timer for power controldecisions (time to pass between two consecutive power control steps) and suspends the BS power controldecision process (the insertion of measurement samples into the averaging window continues, but no power control decision is made).

Attention:Depending on the power control type (classic or adaptive) the ‘delay timer’ is based on different databaseparameters:

• If BSPRWC=CLASSIC the delay timer is defined by the parameter PCONINT.

• If BSPRWC=ADAPTIVE the delay timer is defined by the length of the power control averaging windowfor RXQUAL values PAVRQUAL (in SACCH periods) plus 1 (= value of parameter PAVRQUAL + 1*).

* The extension of the delay timer from PAVRQUAL (as used in BR7.0) to PAVRQUAL + 1 (in BR8.0) was implementedbecause the BTS always has to wait at least one SACCH period for MEASUREMENT REPORT which mirrors the resultof the last BS Power Control order.

Moreover, in case of adaptive power control (BSPRWC=ADAPTIVE), the delay timer is only applied if apower change decision was made due to quality reasons (quadrants 2b, 8 and 9 and, under specificconditions also in quadrant 3 (see above)). In all other quadrants the delay timer between twoconsecutive power control steps is not applied. As a result, in these quadrants the power change willtake place much faster (for further details, please see also section ‘Further differences between CLASSICand ADAPTIVE Power Control’ below).

2) When the delay timer expires, the BTS resumes the PWRC decision process. In this case, if the currentREXLEV_DL and RXQUAL_DL conditions suggest it, the power control decision process may suggestanother power control step (see 1)).

Special approach in case of missing UL SACCH frames The current value of the ‘S’-Counter in the BTS is also checked in the scope of the BS power controldecision: If no SACCH report was received in a particular SACCH period, no PC decision will be made for the DL (BS Power Control). If the ‘missing SACCH’ counter (‘S’-counter, initial value defined by RDLNKTBS)is more than 2 below RDLNKTBS (i.e. either at least three SACCH reports in a row were missed or thecurrent SACCH report is missing and additional SACCHs were missing before) then a normal BTS power increase will be commanded.





2.4.3.5.2 MS power control procedure

The MS power increase or power reduction procedure includes a ‘power control command’ and ‘power control confirmation’ signalling procedure, which (compared to the BS power control process) considerablyslows down the speed of the power adaption.

To make the sequence of events clear, the SACCH periods are numbered (SACCH period 1, 2, etc.).

1) The BTS makes a power control decision (increase or power reduction) based on the currently measureduplink measurements (visible on the Abis in the MEASUREMENT RESULT messages) and instructs the MS

to increase or reduce the power by sending a power control command (‘MS power level’) in the layer 1header of the next SACCH period (SACCH period 1) to the MS. Attention: the power control command does not order a relative power increase or reduction value (e.g.“increase by 4dB”) but it orders the absolute power level the MS shall use. This ‘MS power level’ is signalledin form of the power level values defined by GSM as shown in the power levels tables for the parametersMSTXPMAXDCS, MSTXPMAXGSM and MSTXPMAXPCS (see command CREATE BTS [BASICS]), e.g.‘MS power level’ = 7 (for GSM900) means that the MS shall adjust its power to 29dBm.Simultaneously the BTS starts the timers for power control confirmation (parameter PWRCONF) andsuspends the power control decision process (the insertion of measurement samples into the averagingwindow continues, but no power control decision is made).

2) The MS, having the received the power control command via the SACCH layer 1 header, adjusts itspower at a range of one power level step (2dB) every 60ms. The change is in effect at the first TDMA framebelonging to the next SACCH reporting period (SACCH period 2).

3) When the MS has executed the power change in the SACCH period after the receipt of the power control

command (SACCH period 2) the MS confirms the power level to the BTS in the next UL SACCH frame (i.e.in the MEASUREMENT REPORT for SACCH period 2, i.e. in the beginning of SACCH period 3). In detail,the MS confirms the last (absolute) power level that was actually used in the last burst of the previousSACCH period (end of SACCH period 2).

Attention: In case of adaptive power control it can happen that the power increase step ordered by the BTSis bigger than the increase step the MS can execute within one SACCH period. In this case the MS confirmsonly that power level which it actually managed to reach in the last burst of the SACCH period. Moreover,greater power increase steps will not be immediately mirrored by the UL power measurements done by theBTS as the MS always needs some time for the ‘ramp up’. To avoid another immediate power increasecommand from the BTS (which is in this case in fact not useful as the MS simply did not have enough time toexecute the ordered power increase step), the power control decision process is suspended for another additional SACCH period if the power increase step size was greater than 4dB (this is achieved by an‘artificial’ delay of the MS power confirmation by 1 SACCH period).

4) When the BTS has received the power confirmation from the MS in the MEASUREMENT REPORT(SACCH period 3), the BTS starts the delay timer for power control decisions (time to pass between twoconsecutive power control steps). As long as this delay timer runs, the BS power control decision processremains still suspended.

Attention: Depending on the power control type (classic or adaptive) the ‘delay timer’ is based on differentdatabase parameters:

• If MSPRWC=CLASSIC the delay timer is defined by the parameter PCONINT.

• If MSPRWC=ADAPTIVE the delay timer is defined by the length of the power control averaging windowfor RXQUAL values (in SACCH periods) minus 1 (= value of parameter PAVRQUAL – 1*).

* The reduction of the delay timer from PAVRQUAL (as used in BR7.0) to PAVRQUAL – 1 (in BR8.0) was implementedbecause at the time the delay timer is started (after having received the MS power level confirmation), the first newquality measurement is already contained in the current measurement report from the MS, so this can be subtracted fromthe waiting time.

5) When the ‘delay timer’ expires, the BTS resumes the PWRC decision process. When the waiting timer for the power confirmation from the MS (parameter PWRCONF) has expired without receipt of a power confirmation that confirms that the requested power command was actually executed, the BTS immediatelyresumes the power control decision process. In this case, if the current REXLEV_UL and RXQUAL_ULconditions suggest it, the power control decision process may trigger another power control step (see 1)).

Moreover, in case of adaptive power control (MSPRWC=ADAPTIVE), the delay timer is only applied if apower change decision was made due to quality reasons (quadrants 2b, 8 and 9 and, under specificconditions also in quadrant 3 (see above)). In all other quadrants the delay timer between twoconsecutive power control steps is not applied. As a result, in these quadrants the power change willtake place much faster.





2.4.3.6 Comparison of timing behaviour of different Power Control types -MS Power Control, BS Power Control, classic and adaptive

For MS power control, the time difference between two consecutive power control steps is considerablylonger than for BS power control, as, in case of MS power control, as described above, it takes a minimum of 3 SACCH periods (1 SACCH period = 480ms) for each power control step to receive a power controlconfirmation from the MS (one period for transmission of the power control command, one for the adjustmentand one for the confirmation). This means that each MS power control step takes considerably longer than a

BS power control step and, consequently, the whole MS power control process reacts considerably slower than BS power control.

MS Power and BS Power Indication within the MEASUREMENT RESULT messages on Abis A verification of the executed and confirmed MS and BS power control steps is possible by checking theMEASUREMENT RESULT / MEASUREMENT REPORT messages on the Abis, especially the InformationElements (IE) ‘BS Power’ and ‘MS Power’ are relevant. These Information Elements must be interpreted inthe following way:

BS Power Control The IE ‘BS Power’ indicates the currently ordered BS power level, i.e. it shows the BS power applied atthe end of this SACCH period as a consequence of a BS power control decision.The MEASUREMENT RESULT message that contains the power level change is simultaneously the onewhich reflects the SACCH period in which the decision for the BS power change took place. Moreover, thedownlink measurement sample contained in this MEAS RES message is the last one which was considered

for the decision (last sample in the averaging window). How many previous samples were considered inaddition (for averaging) depends on the length of the configured averaging windows (PAVRLEV,PAVRQUAL).

The diagram below illustrates the behaviour:

BS Power Control

decision

time

SACCH period (480ms)

MEAS RES MEAS RES’BS power’

value changes

MEAS RES

SACCH period (480ms) SACCH period (480ms)

--- New BS power in effect ---

DownlinkMeasurement

Sample n

Contains the lastmeasurement

sample (n) that wasconsidered in the

averaging window

for the BS power

control decision

DownlinkMeasurementSample n-1

DL measurementsfrom MS already

reflect adjusted BSpower

MEAS RES

DownlinkMeasurementSample n-2

X





MS Power Control The IE ‘MS Power’ indicates the MS power level that was confirmed by the MS (i.e. the power changecommand was sent by the BTS 3 SACCH frames before).In more detail:3) The MEAS RES message that contains the MS power level change reflects the SACCH period in whichthe MS sent the power confirmation.2) The MEAS RES message before the one described under (3) reflects the SACCH period where the MS

adjusted the MS power 1) The MEAS RES message before the one described under (2) reflects the SACCH period where the MSreceived the MS power control order.0) The MEAS RES message before the one described under (1) reflects the SACCH period which containsthe last considered uplink measurement sample for the MS power control decision. How many previoussamples were considered in addition (for averaging) depends on the length of the configured averagingwindows (PAVRLEV, PAVRQUAL).

The following diagrams illustrate the timing behaviour of the MEASUREMENT RESULT messages on the Abis and the associated power control events:

time

MEAS RES

’MS power’

value changes

SACCH period

MS confirms power

MEAS RES

SACCH period

MEAS RESMEAS RES

MS adjusts power BTS sends PRWC order

SACCH period

MEAS RES

SACCH period

UplinkMeasurementSample n-1

UplinkMeasurement

Sample n

X

SACCH period

MS Power Controldecision

Contains the lastUL measurement

sample (n) that wasconsidered in the

averaging window for the MS power

control decision

RES

plinkmentn-2





Power level change tracking within the MEASUREMENT RESULT messages on the Abis

Example:With the PWRC settings

PAVRLEV=2-1,PAVRQUAL=2-1,PCONINT=2,PWRCONF=2

the following typical timing behaviour that can observed for the different power control types, if continuousRXQUAL or RXLEV conditions trigger a continuous power increase or reduction:

Power Control Type Speed of power change visible on the Abis

MSPRWC = CLASSIC(all quadrants)

IE ‘MS power’ changes after every 7th

MEASUREMENT RESULT = 3 SACCH periods for confirmation + 4 SACCH periods delay (PCONINT=2)

BSPRWC = CLASSIC(all quadrants)

IE ‘BS power’ changes after every 4th

MEASUREMENT RESULT= 0 SACCH periods for confirmation + 4 SACCH periods delay (PCONINT=2)

MSPRWC = ADAPTIVE(quadrants 2b,8,9)

IE ‘MS power’ changes after every 4th

MEASUREMENT RESULT

= 3 SACCH periods confirmation + 1 SACCH periods delay (PAVRQUAL-1=1 )

MSPRWC = ADAPTIVE(quadrants 1,4,6,7)

IE ‘MS power’ changes after every 3rd

MEASUREMENT RESULT

= 3 SACCH periods for confirmation + 0 SACCH periods delay

MSPRWC = ADAPTIVE(quadrant 3)

a) If calculated power reduction step < 4dB IE ‘MS power’ changes after the 3

rdMEASUREMENT RESULT

= 3 SACCH periods for confirmation + 0 SACCH periods delay b) If calculated power reduction step >= 4dB IE ‘MS power’ changes after the 4

thMEASUREMENT RESULT

= 3 SACCH periods confirmation + 1 SACCH periods delay (PAVRQUAL-1=1)

BSPRWC = ADAPTIVE(quadrants 2b,8,9)

IE ‘BS power’ changes after every 3rd

MEASUREMENT RESULT

= 0 SACCH periods confirmation + 3 SACCH periods delay (PAVRQUAL+1=3 )

BSPRWC = ADAPTIVE(quadrants 1,4,6,7)

IE ‘BS power’ changes every MEASUREMENT RESULT


BSPRWC = ADAPTIVE(quadrant 3)

a) If calculated power reduction step < 4dB IE ‘BS power’ changes every MEASUREMENT RESULT *


b) If calculated power reduction step >= 4dB

IE ‘BS power’ changes after every 3

rd

MEASUREMENT RESULT *= 0 SACCH periods confirmation + 3 SACCH periods delay (PAVRQUAL+1=3)

2.4.3.7 Further differences between CLASSIC and ADAPTIVE Power Control

If power control is set to ADAPTIVE, all sample values in the RXLEV averaging windows will be corrected bythe respective power level change as if they were already received with the changed power. For MS power control, new UL RXLEV samples in the averaging window will be corrected until the power change wasconfirmed by the MS. Thus there is no need for a delay and power control can resume without suspension.

On the other hand, if very big power increase steps are ordered in case of adaptive MS power control, itmight happen that, due to the fact that the MS can only increase the UL transmit power with a certain speed(one power level step (2dB) every 60ms), it may happen that the power confirmation of the MS indicates apower increase which is smaller than the ordered one. In this case, the last sample which is received after the power confirmation (assuming a power confirmation interval of 4 SACCH periods, PWRCONF=2) iscorrected by only half the ordered power increase level.

Example: If the MS power control orders a power increase of 10dB in the UL, the BTS immediately adds the10dB increase to all samples that are currently in the averaging window for RXLEV_UL samples. Theincrease of 10dB is also added to all new arriving measurement samples, as long as the MS has not yetconfirmed the power change.If in the next power confirmation the MS only confirms less than the ordered increase step (increase of e.g.6dB), the BTS corrects the subsequent last measurement sample (assuming a power confirmation interval of 4 SACCH periods, PWRCONF=2) by adding only half of the ordered power increase step (i.e. in this case5dB).





2.4.3.8 Interaction of Power Control Measurement Preprocessing andPower Control Decision

Before the BTS makes a power control decision the received measurement samples are averaged incorrespondence with the averaging window defined by the parameters PAVRLEV (for level averaging) andPAVRQUAL (for quality averaging). In addition, the averaged RXLEV (non-integer) value is rounded to thenext integer value according to normal mathematic rounding principles (non-integer values < 0,5 arerounded down, values >= 0,5 are rounded up to 1).

The resulting value is compared to the power control thresholds and a power control decision is made on thebasis of this comparison if a power control decision is scheduled (i.e. if the power control interval timer (if applied at all) has already expired).

Example:The following BS Power Control scenario may give an idea about what happens during the measurementpreprocessing and the resulting power control decision (classic power control).

PWRC database parameters: EBSPWRC=CLASSIC,PWRINCSS=DB6,PWREDSS=DB2,PCONINT=2,PAVRLEV=4-3,LOWTLEVD=20,UPTLEVD=40,

Assuming perfect quality (RXQUAL=0) and the RXLEV measurement samples as indicated in the tablebelow the following PC decisions will be made:

+ (power increase) : if DL-RXLEV_avg < LOWTLEVD --> DL-RXLEV < 20

0 (no power change): if LOWTLEVD <= DL-RXLEV_avg < (LOWTLEVD + PWREDSS)--> 20 <= DL-RXLEV_avg < 22

- (power decrease) : if (LOWTLEVD + PWREDSS) <= DL-RXLEV_avg --> 22 <= DL-RXLEV_avg Meas.result # | DL-RXLEV_full | DL-RXLEV_avg*| BS-PL | INT-CTR | Decision--------------+---------------+--------------+-------+---------+----------

254 | 23 | -- | 10 | - |255 | 23 | -- | 10 | - |0 | 23 | -- | 10 | - | -1 | 23 | 23 | 11 | 3 |2 | 21 | 23 | 11 | 2 |3 | 21 | 22 | 11 | 1 |4 | 21 | 22 | 11 | 0 | -5 | 21 | 21 | 12 | 3 |6 | 19 | 21 | 12 | 2 |7 | 19 | 20 | 12 | 1 |8 | 19 | 20 | 12 | 0 | 09 | 19 | 19 | 12 | 0 | +10 | 20 | 19 | 9 | 3 |11 | 25 | 21 | 9 | 2 |12 | 25 | 22 | 9 | 1 |13 | 25 | 24 | 9 | 0 | -14 | 25 | 25 | 10 | 3 |15 | 23 | 25 | 10 | 2 |16 | 23 | 24 | 10 | 1 |17 | 23 | 24 | 10 | 0 | -18 | 23 | 23 | 11 | 3 |19 | 21 | 23 | 11 | 2 |20 | 21 | 22 | 11 | 1 |21 | 21 | 22 | 11 | 0 | -22 | 21 | 21 | 12 | 3 |23 | 19 | 21 | 12 | 2 |24 | 19 | 20 | 12 | 1 |25 | 19 | 20 | 12 | 0 | 026 | 19 | 19 | 12 | 0 | +... | ...

Notes:• *DL-RXLEV_avg is not the exact averaged value of the last n samples (n=length of the averaging

window) but the calculated value rounded to the next integer (0.5 is rounded up to 1).This is e.g. the reason why after Meas. result no. 8 a '0' decision (no increase/decrease) is made:the averaged value (19,5) is rounded to the next integer (20).

• BS-PL: the set BS-PL reflects the BS-PL set during the shown measurement period; a BS-PC decisionshows effect in the changed PL in the next measurement period and the DL reflects this change in thefollowing measurement period.

• INT-CTR: the intervall counter, set after a PC decision from (2xPCONINT); once it counted down to 0 anew PC decision will be taken.





2.5 Interworking of Handover and Power Control

2.5.1 Functional Diagram: Inter-cell Handover and Intra-cell Handover, Power Increase and Power Decrease

Note: for clearness reasons, Fast Uplink Handover was not included in this diagram.


GSM Parameter Name

DB parameter Name(SET HAND)

Meaning

L_RXLev_DL_H HOLTHLVDL lower threshold value for level handover downlink

L_RXLev_UL_H HOLTHLVUL lower threshold value for level handover uplink

L_RXLev_DL_IH HOTDLINT threshold value for intra BTS handover downlink

L_RXLev_UL_IH HOTULINT threshold value for intra BTS handover uplink

L_RXQual_DL_H HOLTHQUDL lower threshold value for quality handover downlink

L_RXQual_UL_H HOLTHQUUL lower threshold value for quality handover uplink

Bit-Error Rate(RxQual)

Level (RXLev)

Power-Control + Handover

L_RXQual_XX_H

L_RXQual_XX_P

L_RXLev_XX_P

L_RXLev_XX_H

U_RXLev_XX_P

U_RXQual_XX_P


HOLTHQUXX

LOWTQUAX

UPTQUAX

UPTLEVXLOWTLEVX

HOLTHLVXX

LOWTLEVX +PWREDSS

Inter-cell handover due to level

Inter-cell handover due to power budget /Traffic handover /

no Power Control

Inter-cell handover due toquality (if skip flag=TRUE or if INTRACH=FALSE)

Intra-cell handover due to quality(if skip flag=FALSE)

X=D : DownlinkX=U : Uplink

XX=DL: DownlinkXX=UL: Uplink

Power Budget HO / Traffic HO/Power Decrease

L_RXLev_XX_P +2(dB)*Pow-Red-Step-Size

Inter-cell handover due to quality(skip flag not evaluated)

Power Budget HO / Traffic HO /Power Decrease

Power Budget HO / Traffic HO / Power Increase

HOTXXINTL_RXLev_IH





General Parameter Name DB parameter Name(SET PWRC)

Meaning

L_RXLev_DL_P LOWTLEVD power control lower level threshold downlink

L_RXLev_UL_P LOWTLEVU power control lower level threshold downlink

U_RXLev_DL_P UPTLEVD power control upper level threshold downlink

U_RXLev_UL_P UPTLEVU power control upper level threshold uplink

L_RXLev_XX_P +

2(dB)∗ POW_RED_STEP_SIZE

LOWTLEVX +PWREDSS

power control lower threshold +configured power reduction step size

L_RXQual_DL_P LOWTQUAD power control lower quality threshold downlink

L_RXQual_UL_P LOWTQUAU power control lower quality threshold uplink

U_RXQual_DL_P UPTQUAD power control upper quality threshold downlink

U_RXQual_UL_P UPTQUAU power control upper quality threshold uplink

2.5.2 Rules

The diagram on the previous page shows the interaction between Handover and Power Control in the SBS.It has to be noted that the thresholds for Handover and Power Control should be set in accordance with thediagram, because the algorithms are designed for such a threshold configuration. The main point is:imperative handovers are only triggered if dynamic Dower Control has adjusted the power to the maximum.

The following rules should be followed:

1. L_RXLev_XX_H < L_RXLev_XX_P < L_RXLev_XX_P+2∗ POW_RED_STEP_SIZE < U_RXLev_XX_P

2. U_RXQual_XX_P < L_RXQual_XX_P < L_RXQual_XX_H

(XX = UL or DL)

Translated to the DB parameter names the rules are:

1. HOLTHLVXX < LOWTLEVX < LOWTLEVX+2∗PWREDSS < UPTLEVX

2. UPTQUAX < LOWTQUAX < HOLTHQUXX

(XX = UL or DL, X = U or D)





2.6 Service Dependent Handover and Power Control

2.6.1 Introduction

Starting from BR7.0 it is possible to configure specific parameters (mainly thresholds) related to Power Control and Handover separately per so-called ‘service group’. This means that the power control andhandover decisions can – optionally – be adapted to specific requirements of the different service types. Thefollowing table shows all service group categories, for which power control and handover parameters can be

specifically set.

Service Group Category Description

SG-1 Signalling Signalling on hopping channel

SG-2 Signalling on non-hopping channel

SG-3 Speech Calls CS speech FR-EFR-ASCI VBS-ASCI VGCS on hopping channel

SG-4 (non-AMR) CS speech FR-EFR-ASCI VBS-ASCI VGCS on non-hopping channel

SG-5 CS speech HR on hopping channel

SG-6 CS speech HR on non-hopping channel

SG-7 Data Calls CS data until 9,6kbit/s or HSCSD 9,6kbit/s on hopping channel

SG-8 CS data until 9,6kbit/s or HSCSD 9,6kbit/s on non-hopping channel

SG-9 CS data until 14,4kbit/s or HSCSD 14,4kbit/s on hopping channel

SG-10 CS data until 14,4kbit/s or HSCSD 14,4kbit/s on non-hopping channel

SG-11 AMR Calls CS speech AMR-FR on hopping channel

SG-12 CS speech AMR-FR on non-hopping channel

SG-13 CS speech AMR-HR on hopping channel

SG-14 CS speech AMR-HR on non-hopping channel

The standard parameters for handover and power control are defined by the known parameters.

The service group specific handover and power control settings are administered by new parameters in theSET HAND and SET PWRC command:

SET HAND: SG1HOPAR..SG14HOPAR

SET PWRC: SG1PCPAR..SG14PCPAR

These parameters are set to <NULL> by default, which means that no service-group specific handover or power control parameters are applied for the calls of the affected service group. If, however, service group

specific settings shall be applied, the parameter values have to be entered in a specific number of fields.

Example: SET HAND: SG1HOPAR=10-10-35-35-26-32-5-5;

Each field epresents a specific parameter which is already known from the standard parameters’ list.

Example:

SG1HOPAR = 10 - 10 - 35 - 35 - 26 - 32 - 5 - 5 ;HOLTHLVDL HOLTHLVUL HOTDLINT HOTULINT HORXLVDLI HORXLVDLO HOLTHQUDL HOLTHQUUL

The number of fields and the meaning of the fields per SGxHOPAR resp. SGxPCPAR (i.e. which parameter a specific field represents) depends on the service group as not all parameters are valid for all servicegroups.





2.6.2 SGxHOPAR and SGxPCPAR parameter values

2.6.2.1 SGxHOPAR parameter values (Handover)

The following parameters are represented by the SGxHOPAR fields:

HAND Attri bute Range Service Groups Description

HOLTHLVDL 0..63 all (SG-1..SG-14) lower RXLEV HO threshold for DL

HOLTHLVUL 0..63 all (SG-1..SG-14) lower RXLEV HO threshold for ULHOTDLINT 0..63 all (SG-1..SG-14) DL RXLEV threshold for intra-cell HO

HOTULINT 0..63 all (SG-1..SG-14) UL RXLEV threshold for intra-cell HO

HORXLVDLI 0..63 all (SG-1..SG-14) DL RXLEV threshold for concentric intra-cell HO from inner to complete cell

HORXLVDLO 0..63 all (SG-1..SG-14) DL RXLEV threshold for concentric intra-cell HO from complete to inner cell

HOLTHQUDL 0..7 SG-1..SG-10 lower RXQUAL HO threshold for DL

HOLTHQUUL 0..7 SG-1..SG-10 lower RXQUAL HO threshold for UL

HOTHEFRCDL 0..30 SG-3..SG-4 EFR Compression Handover threshold downlink

HOTHEFRCUL 0..30 SG-3..SG-4 EFR Compression Handover threshold uplink

HOTHFRCDL 0..30 SG-3..SG-4 FR Compression Handover threshold downlink

HOTHFRCUL 0..30 SG-3..SG-4 FR Compression Handover threshold uplink

HOTHHRDDL 0..30 SG-5..SG-6 non-AMR HR Decompression Handover threshold downlink

HOTHHRDUL 0..30 SG-5..SG-6 non-AMR HR Decompression Handover threshold uplink

RHOLTQUDL 2..7 SG-7..SG-10 RXQUAL DL threshold for intra- and inter-cell HO (of data calls only)

RHOLTQUUL 2..7 SG-7..SG-10 RXQUAL UL threshold for intra- and inter-cell HO (of data calls only)

HOLTHQAMRDL 0..30 SG-11..SG-14 lower C/I HO threshold for DL on AMR channels

HOLTHQAMRUIL 0..30 SG-11..SG-14 lower C/I HO threshold for UL on AMR channels

HOTHAMRCDL 0..30 SG-11..SG-12 AMR Compression Handover threshold downlink

HOTHAMRCUL 0..30 SG-11..SG-12 AMR Compression Handover threshold uplink

HOTHAMRDDL 0..30 SG-13..SG-14 AMR Decompression Handover threshold downlink

HOTHAMRDUL 0..30 SG-11..SG-12 AMR Decompression Handover threshold uplink

Looking at the SGxHOPAR parameters, the following parameter value structure is implemented in thedifferent service groups :

Handover Sevice Groups for Signalling (Service Group-1, Service Group-2)

SGxHOPAR(x=1..2, signaling)= <field 1>-<field 2>..<field 8> = HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQUDL-HOLTHQUUL

Handover Sevice Groups for non-AMR FR speech calls (Service Group-3, Service Group-4)

SGxHOPAR(x=3..6, non-AMR speech calls)= <field 1>-<field 2>..<field 8> = HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQUDL-HOLTHQUUL-HOTHEFRCDL-HOTHEFRCUL-HOTHFRCDL-HOTHFRCUL

Handover Sevice Groups for non-AMR HR speech calls (Service Group-5, Service Group-6)

SGxHOPAR(x=7..10, data calls)

= <field 1>-<field 2>..<field 10>= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQUDL-HOLTHQUUL-RHOLTQDL-RHOLTQUL-HOTHHRDDL-HOTHHRDUL





Handover Sevice Groups for AMR FR speech calls (Service Group-11, Service Group-12)

SGxHOPAR(x=11..12) = = <field 1>-<field 2>..<field 10>= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQAMRDL-HOLTHQAMRUL-HOTHAMRCDL-HOTHAMRCUL

Handover Sevice Groups for AMR HR speech calls (Service Group-13, Service Group-14

SGxHOPAR(x=13..14) = = <field 1>-<field 2>..<field 10>= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO--HOLTHQAMRDL-HOLTHQAMRUL-HOTHAMRDDL-HOTHAMRDUL





2.6.2.2 SGxPCPAR parameter values (Power Control)

The following parameters are represented by the SGxPCPAR fields:

PWRC Attribute Range Service Groups Description

EBSPWRC 0..2 all (SG-1..SG-14) enables the BS power control (DISABLED/CLASSIC/ADAPTIVE).

EMSPWRC 0..2 all (SG-1..SG-14) enables the MS power control (DISABLED/CLASSIC/ADAPTIVE).

EPWCRLFW 0..1 all (SG-1..SG-14) enables Radio Link Failure power control.

LOWTLEVD 0..63 all (SG-1..SG-14) lower DL RXLEV thresholdLOWTLEVU 0..63 all (SG-1..SG-14) lower UL RXLEV threshold

UPLTLEVD 0..63 all (SG-1..SG-14) upper DL RXLEV threshold

UPTLEVU 0..63 all (SG-1..SG-14) upper UL RXLEV threshold

PCRLFTH 0..64 all (SG-1..SG-14) threshold for the radio link failure counter

RDLNKTBS 0..15 all (SG-1..SG-14) radio link timeout BS

RDLNKTO 0..15 all (SG-1..SG-14) radio link timeout MS

LOWTQUAD 0..7 SG-1..SG-10 lower DL quality threshold for standard calls in RXQUAL

LOWTQUAU 0..7 SG-1..SG-10 lower UL quality threshold for standard calls in RXQUAL

UPTQUAD 0..7 SG-1..SG-10 upper DL quality threshold for standard calls in RXQUAL

UPTQUAU 0..7 SG-1..SG-10 upper UL quality threshold for standard calls in RXQUAL

LOWTQUAMRDL 0..30 SG-11..SG-14 lower DL quality threshold for AMR calls in C/I

LOWTQUAMRUL 0..30 SG-1..SG-10 lower UL quality threshold for AMR calls in C/I

UPTQUAMRDL 0..30 SG-1..SG-10 upper DL quality threshold for AMR calls in C/I

UPTQUAMRUL 0..30 SG-1..SG-10 upper UL quality threshold for AMR calls in C/I

Looking at the SGxHOPAR parameters in separate Service Group Sets, the following parameter valuestructure is implemented for each Service Group Set:

Power Control Sevice for Signalling, non-AMR speech calls and data calls (Service Group-1..ServiceGroup-10)

SGxPCPAR(x=1..2, signaling)= <field 1>-<field 2>..<field 12> = EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQUAD–LOWTQUAU-UPTQUAD-UPTQUAU-RDLNKTBS-RDLNKTO

SGxPCPAR(x=3..6, non-AMR speech calls)

= <field 1>-<field 2>..<field 12> = EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQUAD–LOWTQUAU-UPTQUAD-UPTQUAU-RDLNKTBS-RDLNKTO

SGxPCPAR(x=7..10, data calls)= <field 1>-<field 2>..<field 12> = EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQUAD–LOWTQUAU-UPTQUAD-UPTQUAU-RDLNKTBS-RDLNKTO

Power Control Sevice for AMR speech calls (Service Group-11..Service Group-14)

SGxPCPAR(x=11..12, AMR FR calls)= <field 1>-<field 2>..<field 12> = EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQAMRDL-LOWTQAMRUL-UPTQAMRDL-UPTQAMRUL-RDLNKTBS-RDLNKTO

SGxPCPAR(x=13..14, AMR HR calls)= <field 1>-<field 2>..<field 12> = EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQAMRDL-LOWTQAMRUL-UPTQAMRDL-UPTQAMRUL-RDLNKTBS-RDLNKTO





2.6.2.3 Effects on Call processing

In the BTS, the type of service group a particular call belongs to must be known to apply the correct servicegroup dependent power control and handover thresholds. To achieve this, the BSC determines the servicegroup for each call and sends the service groups specific parameters to the BTS using the optionalInformation Elements

“Service Group HO Settings” and”Service Group PC Settings”

These IEs are optionally included in the Abis RSL messages CHANNEL ACTIVATION or (in case of DirectTCH Assignment) MODE MODIFY REQUEST, if service group specific settings were entered for the type of call currently processed. In other words, the IE “Service Group HO Settings” is only sent, if for the processedcall’s service group specific HO thresholds were defined by the parameter SGxxHOPAR (SGxxHOPAR notequal to <NULL>) and the IE “Service Group PC Settings” is only sent, if for the processed call’s servicegroup specific power control flags and thresholds were defined by the parameter SGxxPCPAR(SGxxPCPAR not equal to <NULL>).

Moreover, the BSC can signal a change of the service group settings during an ongoing call by the new AbisRSL message CHANNEL CONFIGURATION CHANGE, which also optionally contains the mentioned IEs“Service Group HO Settings” and “Service Group PC Settings”.

The CHANNEL CONFIGURATION CHANGE message is sent for ongoing callsa) if the service group specific settings for handover and power control are changed manually by commandor

b) when the hopping status changes (i.e. hopping disabled or enabled manually (by command) or automatically (due to failure of a hopping TRX in case of Baseband Frequency Hopping). In the latter case,the CHANNEL CONFIGURATION CHANGE message contains the conditional IE ‘Starting Time’, whichindicates the TDMA frame number for the starting point of the new hopping mode.





2.7 Reporting, Display and BTS internal handling of RSCP valuesfrom 3G neighbour cells

When the MS/UE indicates the measured RXLEV values for GSM neighbour cells in the MEASUREMENTREPORT messages, they are indicated as the difference between the actual RXLEV value in dBm and thereference value -110dBm.

The K1205/K1297 decodes and indicates these RXLEV values (assuming the reference -110dBm) in ‘dBmranges’ in correspondence with the following table:

RXLEV(hex)

RXLEV(dec)

dBmvalue

dBm range(K1205/97)

RXLEV(hex)

RXLEV(dec)

dBmvalue

dBm range(K1205/97)

00 00 -110 -∞ ... ≤ -110 20 32 -78 -79 < ... ≤ -78

01 01 -109 -110 < ... ≤ -109 21 33 -77 -78 < ... ≤ -77

02 02 -108 -109 < ... ≤ -108 22 34 -76 -77 < ... ≤ -76

03 03 -107 -108 < ... ≤ -107 23 35 -75 -76 < ... ≤ -75

04 04 -106 -107 < ... ≤ -106 24 36 -74 -75 < ... ≤ -74

05 05 -105 -106 < ... ≤ -105 25 37 -73 -74 < ... ≤ -73

06 06 -104 -105 < ... ≤ -104 26 38 -72 -73 < ... ≤ -72

07 07 -103 -104 < ... ≤ -103 27 39 -71 -72 < ... ≤ -71

08 08 -102 -103 < ... ≤ -102 28 40 -70 -71 < ... ≤ -7009 09 -101 -102 < ... ≤ -101 29 41 -69 -70 < ... ≤ -69

0A 10 -100 -101 < ... ≤ -100 2A 42 -68 -69 < ... ≤ -68

0B 11 -99 -100 < ... ≤ -99 2B 43 -67 -68 < ... ≤ -67

0C 12 -98 -99 < ... ≤ -98 2C 44 -66 -67 < ... ≤ -66

0D 13 -97 -98 < ... ≤ -97 2D 45 -65 -66 < ... ≤ -65

0E 14 -96 -97 < ... ≤ -96 2E 46 -64 -65 < ... ≤ -64

0F 15 -95 -96 < ... ≤ -95 2F 47 -63 -64 < ... ≤ -63

10 16 -94 -95 < ... ≤ -94 30 48 -62 -63 < ... ≤ -62

11 17 -93 -94 < ... ≤ -93 31 49 -61 -62 < ... ≤ -61

12 18 -92 -93 < ... ≤ -92 32 50 -60 -61 < ... ≤ -60

13 19 -91 -92 < ... ≤ -91 33 51 -59 -60 < ... ≤ -59

14 20 -90 -91 < ... ≤ -90 34 52 -58 -59 < ... ≤ -58

15 21 -89 -90 < ... ≤ -89 35 53 -57 -58 < ... ≤ -57

16 22 -88 -89 < ... ≤ -88 36 54 -56 -57 < ... ≤ -56

17 23 -87 -88 < ... ≤ -87 37 55 -55 -56 < ... ≤ -55

18 24 -86 -87 < ... ≤ -86 38 56 -54 -55 < ... ≤ -54

19 25 -85 -86 < ... ≤ -85 39 57 -53 -54 < ... ≤ -53

1A 26 -84 -85 < ... ≤ -84 3A 58 -52 -53 < ... ≤ -52

1B 27 -83 -84 < ... ≤ -83 3B 59 -51 -52 < ... ≤ -51

1C 28 -82 -83 < ... ≤ -82 3C 60 -50 -51 < ... ≤ -50

1D 29 -81 -82 < ... ≤ -81 3D 61 -49 -50 < ... ≤ -49

1E 30 -80 -81 < ... ≤ -80 3E 62 -48 -49 < ... ≤ -48

1F 31 -79 -80 < ... ≤ -79 3F 63 -47 -48 < ... + ∞

Examples:

RXLEV value calculation MS/UE reports value as decode on K1205/K1297

-90dBm -90dBm = -110dBm + 20 dB 20 -91 dBm < … ≤ -90 dBm

-75dBm -75dBm = -110dBm + 35 dB 35 -76 dBm < …≤

-75 dBm





Special indication of RSCP value for UTRAN neighbour cells When a multi-RAT MS is currently busy on a GSM/DCS cell, it reports the UTRAN neighbour cells (visible bythe relative ARFCN number 31 in the MEASUREMENT REPORT) with their RSCP values according to thesame principle, however, for UMTS FDD the reference value is -115dBm (not -110dBm).

Examples:

RSCP value calculation MS/UE reports value as decode on K1205/K1297



BTS internal handling of reported RXLEV and RSP caluesBTS internally, the reported values (which are always relative values, which are referring to a specificreference value (-110dBm for 2G cells and -115 dBm for 3G neighbour cells) are corrected correspondingly:

- All reported RXLEV values from 2G cells are taken and considered as reported by the MS/UE without aycorrection.- From All reported values from 3G cells, the BTS subtracts the value ‘5’ prior to averaging, in order toestablish the ‘pseudo’ RXLEV value that reflects the real dBm RSCP value of the reported measurement andsubsequently considers this corrected value in any further calculation or handover decision.

Example: If the UE reports a value of ‘40’ for an UTRAN neighbour cell, the BTS corrects it to ‘35’ before

averaging and further measurement processing.





2.8 Mapping of RXQUAL and C/I values

For AMR calls, the BTS algorithms for Power Control due to quality and Handover due to quality consider quality threshold values, whose values are not entered in RXQUAL values but in C/I (carrier/interferenceratio in [dB], range 0..20) values. On the other hand, the MS and the BTS measure and classify the radioquality of the serving cell in RXQUAL values (range 0..7).The approach to consider C/I values for AMR calls was basically used to achieve a higher resolution of

quality values for the AMR link adaptation (i.e. the adjustment of the data rate used for the call). The Power Control and Handover Decision due to quality, however, is still based on the RXQUAL values measured byMS and BTS. The main difference consists in the fact that the averaged RXQUAL value is managed as a‘high-precision’ value with an accuracy of 2 places (digits) after the comma, which are mapped to theentered C/I value in accordance with the table below. These C/I values are compared to the concernedPWRC and Handover thresholds, which are also entered as C/I values. Thus for AMR calls a more subtledistinction regarding the quality values is possible.

Mapping of real RXQUAL rangesto Integer C/I values in [dB]

(conversion of measured andaveraged RXQUAL values)

Mapping of Integer RXQUAL toInteger C/I values in [dB]

(for conversion of RXQUALdatabase thresholds)

RXQUAL C/I [dB] RXQUAL C/I [dB]

6,88 ... 7 1 1 19

6,63 ... 6,87 2 2 17

6,38 ... 6,62 4 3 14

6,13 ... 6,37 5 4 12

5,88 ... 6,12 6 5 9

5,63 ... 5,87 7 6 6

5,38 ... 5,62 8 7 1

5,13 ... 5,37 8

4,88 ... 5,12 9

4,63 ... 4,87 10

4,38 ... 4,62 11

4,13 ... 4,37 113,88 ... 4,12 12

3,63 ... 3,87 13

3,38 ... 3,62 13

3,13 ... 3,37 14

2,88 ... 3,12 14

2,63 ... 2,87 15

2,38 ... 2,62 16

2,13 ... 2,37 16

1,88 ... 2,12 17

1,63 ... 1,87 17

1,38 ... 1,62 18

1,13 ... 1,37 18

0,88 ... 1,12 19

0,63 ... 0,87 19

0,38 ... 0,62 19

0,13 ... 0,37 20

0 ... 0,12 20





2.9 AMR Link Adaptation Thresholds Uplink

As described in the parameter AMRFRIC (see CREATE BTS [BASICS]), a so-called “Active CODEC Set(ACS)” is defined for each BTS, which is a set of up to 4 AMR speech CODECs (i.e. AMR speech codingschemes) that can be used for AMR FR and AMR HR calls (4 CODECs for AMR HR, and 4 for AMR FR).

The CODECs used in the ACS are defined by the parameters AMRFRC1..AMRFRC4 (for AMR FR) and AMRHRC1..AMRHRC4 (for AMR HR).

For AMR Full Rate (AMRFRC1..AMRFRC4) the following speech coding bit rates can be set:

RATE_01: 4.75 kbit/s RATE_02: 5.15 kbit/s RATE_03: 5.90 kbit/sRATE_04: 6.70 kbit/s RATE_05: 7.40 kbit/s RATE_06: 7.95 kbit/s RATE_07: 10.2 kbit/s RATE_08: 12.2 kbit/s

In BR6.0, for AMR Half Rate (AMRHRC1..AMRHRC4) the following speech coding bit rates can be set:

RATE_01: 4.75 kbit/s RATE_02: 5.15 kbit/s RATE_03: 5.90 kbit/s RATE_04: 6.70 kbit/sRATE_05: 7.40 kbit/s

When an AMR call has been set up, the BTS continuously evaluates the radio interface quality in the uplink(derived from the BER measurements performed by the BTS) and the downlink (derived from the RXQUALmeasurement results reported by the MS) and selects a suitable AMR CODEC from the ACS depending onthe radio conditions. The dynamic change of the AMR CODEC depending on the radio conditions is called“AMR Link Adaptation”. The AMR link adaptation is performed by the BTS based on the C/I (Carrier toInterference) thresholds.

For the AMR link adaptation downlink the thresholds and the associated hysteresis areadministrable by the parameters AMRFRTH12..AMRFRTH34 (for AMR FR) and AMRHRTH12..AMRHRTH34 (for AMR HR). For further details please refer to the description provided for the parameter AMRFRIC (see command SET BTS [BASICS]).

For the AMR link adaptation in the uplink so-called reference thresho lds for the transition betweenthe possible CODEC modes are hardcoded. However, the effective thresholds are not fixed, but they arecalculated for each call, depending on the used ACS and the value of the tuning parameter AMRLKAT (seecommand CREATE BTS [BASICS]). As a basis for this calculation, the BTS uses a table of ‘referencevalues’:

Threshold Reference Table

Codec (kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 4,00 3,50 5,00 5,50 5,00 6,50 7,50

5,15 9,50 - 3,00 5,00 5,50 5,00 6,50 8,005,9 11,00 12,00 - 6,00 6,50 6,00 7,00 8,50

6,7 12,00 12,50 13,00 - 7,00 6,00 7,50 9,50

7,4 12,50 13,50 14,50 14,50 - 3,50 8,00 10,50

7,95 13,50 14,00 15,00 15,00 16,00 - 10,00 11,50

10,2 - - - - - - - 11,00

- - - - - - - - -

Reference Threshold values for AMR FR link adaptation in [dB]

Reference Threshold values for AMR HR link adaptation in [dB]

This reference table is the basis for the calculation of so-call ‘upper’ and ‘lower’ thresholds:

• The ‘upper threshold’ is the one which is must be exceeded for the uplink link adaptation from a lower CODEC bitrate to a higher one (e.g. from AMR FR 5,15 kbit/s -> AMR FR 7,4 kbit/s).

• The ‘lower threshold’ is the one which is must be exceeded for the uplink link adaptation from a higher CODEC bitrate to a lower one (e.g. from AMR FR 7,4 kbit/s -> AMR FR 5,15 kbit/s).

Thus correspondence to the administrable downlink link adaptation thresholds is the following:

- the ‘lower threshold’ corresponds to the value of the AMRFRCx value (x=1..4).- the ‘upper threshold’ corresponds to the AMRFRCx + hysteresis(AMRFRCx) value (x=1..4).

To illustrate the effect of AMRLKAT, the tables on the following pages show examples of differentsettings of AMRLKAT (0, 100 and 200) and the resulting values of the upper and lower thresholds.





AMRLKAT=0 (= -100dB)

Upper Thresholds for AMRLKAT=0 (=-10dB)

Codec(kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 4,70 4,15 5,80 6,35 5,80 7,45 8,56

5,15 11,52 - 3,60 5,80 6,35 5,80 7,45 9,11

5,9 13,21 14,33 - 6,90 7,45 6,90 8,00 9,666,7 14,33 14,89 15,45 - 8,00 6,90 8,56 10,76

7,4 14,89 16,01 17,13 17,13 - 4,15 9,11 11,86

7,95 16,01 16,57 17,69 17,69 18,70 - 11,31 12,96

10,2 - - - - - - - 12,41

12,2 - - - - - - - -

Upper threshold values for AMR FR link adaptation in [dB]

Upper threshold values for AMR HR link adaptation in [dB]

Lower Thresholds for AMRLKAT=0 (=-10dB)

Codec(kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 2,89 2,44 3,79 4,24 3,79 5,14 6,03

5,15 7,27 - 1,99 3,79 4,24 3,79 5,14 6,48

5,9 8,50 9,32 - 4,69 5,14 4,69 5,59 6,93

6,7 9,32 9,73 10,14 - 5,59 4,69 6,03 7,83

7,4 9,73 10,55 11,37 11,37 - 2,44 6,48 8,73

7,95 10,55 10,96 11,78 11,78 12,60 - 8,28 9,63

10,2 - - - - - - - 9,18

12,2 - - - - - - - -

Lower threshold values for AMR FR link adaptation in [dB]

Lower threshold values for AMR HR link adaptation in [dB]

Example:

AMRFRC1=RATE_01 (4,75 kbit/s), AMRFRC2= RATE_03 (5,90 kbit/s)

AMRFRTH12=6-2 (threshold=6dB, hysteresis=2dB)

a) AMR link adaptation downlink

link adaptation 4,75kbit/s -> 5,90 kbit/s (AMRFRC1 -> AMRFRC2) takes place when

C/I > AMRFRTH12 + hysteresis (AMRFRTH12)

C/I > 8 dB

link adaptation 5,90 kbit/s -> 4,75 kbit/s (AMRFRC2 -> AMRFRC1) takes place when

C/I < AMRFRTH12

C/I < 6dB

b) AMR link adaptation uplinklink adaptation 4,75kbit/s -> 5,90 kbit/s (AMRFRC1 -> AMRFRC2) takes place when

C/I > upper threshold

C/I > 4,15 dB


C/I < lower threshold

C/I < 2,24 dB





AMRLKAT=100 (=0dB)

Upper Thresholds for AMRLKAT=100 (=0dB)

Codec(kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 5,80 5,25 6,90 7,45 6,90 8,56 9,66

5,15 12,65 - 4,70 6,90 7,45 6,90 8,56 10,21

5,9 14,33 15,45 - 8,00 8,56 8,00 9,11 10,766,7 15,45 16,01 16,57 - 9,11 8,00 9,66 11,86

7,4 16,01 17,13 18,25 18,25 - 5,25 10,21 12,96

7,95 17,13 17,69 18,70 18,70 18,70 - 12,41 14,06

10,2 - - - - - - - 13,51

12,2 - - - - - - - -



Lower Thresholds for AMRLKAT=100 (=0dB)

Codec(kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 3,79 3,34 4,69 5,14 4,69 6,03 6,93

5,15 8,09 - 2,89 4,69 5,14 4,69 6,03 7,38

5,9 9,32 10,14 - 5,59 6,03 5,59 6,48 7,83

6,7 10,14 10,55 10,96 - 6,48 5,59 6,93 8,73

7,4 10,55 11,37 12,19 12,19 - 3,34 7,38 9,63

7,95 11,37 11,78 12,60 12,60 13,42 - 9,18 10,53

10,2 - - - - - - - 10,08

12,2 - - - - - - - -



Example:






C/I > 8 dB


C/I < AMRFRTH12C/I < 6dB

b) AMR link adaptation uplinklink adaptation 4,75kbit/s -> 5,90 kbit/s (AMRFRC1 -> AMRFRC2) takes place when


C/I > 5,25 dB



C/I < 3,34 dB





AMRLKAT=200 (=100dB)

Upper Thresholds for AMRLKAT=200 (=10dB)

Codec(kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 6,90 6,35 8,00 8,56 8,00 9,66 10,76

5,15 13,77 - 5,80 8,00 8,56 8,00 9,66 11,31

5,9 15,45 16,57 - 9,11 9,66 9,11 10,21 11,866,7 16,57 17,13 17,69 - 10,21 9,11 10,76 12,96

7,4 17,13 18,25 18,70 18,70 - 6,35 11,31 14,06

7,95 18,25 18,70 18,70 18,70 18,70 - 13,51 15,16

10,2 - - - - - - - 14,61

12,2 - - - - - - - -



Lower Thresholds for AMRLKAT=200 (=10dB)

Codec(kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 4,69 4,24 5,59 6,03 5,59 6,93 7,83

5,15 8,91 - 3,79 5,59 6,03 5,59 6,93 8,28

5,9 10,14 10,96 - 6,48 6,93 6,48 7,38 8,73

6,7 10,96 11,37 11,78 - 7,38 6,48 7,83 9,63

7,4 11,37 12,19 13,01 13,01 - 4,24 8,28 10,53

7,95 12,19 12,60 13,42 13,42 14,24 - 10,08 11,43

10,2 - - - - - - - 10,98

12,2 - - - - - - - -

Lower threshold values for AMR FR link adaptation in [dB]

Lower threshold values for AMR HR link adaptation in [dB]

Example:






C/I > 8 dB


C/I < AMRFRTH12C/I < 6dB

b) AMR link adaptation uplink



C/I > 6,35 dB



C/I < 4,24 dB





2.10 BSC, MSC and BTS Overload Handling

2.10.1 BSC Overload

2.10.1.1 BSC overload conditions

The following situations represent an overload situation in the BSC:

Category A: /* SS7 Link Congestion */ (MSG_PCSTATEIND)

1) The Tx buffers of the CCS7 links are congested.

Background: The level 2 functions of the CCS7 protocol feature a flow control and buffering mechanism. Alltransmitted SS7 messages are buffered until they are positively acknowledged by the remote end (i.e. theMSC, the SMLC etc.). The associated level 2 buffers are located in the PPXL boards. Buffer congestion canoccur due to an excessive traffic volume or /and frequent retransmissions on the SS7 links (e.g. by badtransmission quality of the PCM lines or microwave links).

The overload condition is detected when the utilization of the SS7 levels 2 transmit buffers has exceeded athreshold defined by the parameter CONGTH (see command SET OPC [MTL2]).

Category B: /* Internal Message Congestion */ (MSG_INTOVL)

2) The percentage of busy level 3 radio registers to handle incoming call requests has exceeded a hard-coded threshold of 90%.

Background: The BSC provides a fixed (release-specific) number of level 3 call processing transactionregisters. Each dedicated transaction, i.e. a transaction that requires a dedicated channel and a dedicatedSCCP connection (MOC, MTC, SMS, incoming handover, location update etc.), occupies one level 3register. The percentage value for the usage of these registers is calculated by dividing the number of currently used registers by the total number of registers available. If the calculated value exceeds 90%, theoverload situation is detected.

3) The real time processor load of the telephony processor TDPC has exceeded a threshold set by theparameter OVLSTTHR.

Background: This kind of overload is only detected when the database flag BSCOVLH is set to TRUE! TheTDPC processor real time processor load is periodically compared to the percentage threshold whichadministrable by the parameter OVLSTTHR (see command SET BSC [BASICS]). If this threshold isexceeded for a duration of 2 seconds the BSC regards this as an overload condition and starts theassociated overload handling measures (if BSCOVLH=TRUE). The BSC regards the overload condition asno longer present, if the TDPC processor real time load has dropped below the threshold administered by

the parameter OVLENTHR (see command SET BSC [BASICS]).4) A lack of TDPC memory resources is detected.

Background: This overload condition indicates a lack of physical memory available in the TDPC board. If the memory occupation of the TDPC exceeds a hardcoded threshold of 70%, the BSC starts overloadhandling to avoid memory corruptions. The BSC regards the overload condition as no longer present, if theTDPC memory usage has dropped below the same hardcoded threshold - oscillations are avoided using thetimer T18 (see section ‘Mechanisms for traffic reduction').

Category C: /* PPXL Overload */ (MSG_PPXLOVL)

5) The real time processor load of the PPXX has exceeded 70%.

Background: The PPXX processor real time processor load is periodically compared to a threshold which ishardcoded to 70%. If this threshold is exceeded for a duration of 2 seconds the BSC regards this as anoverload condition and starts the associated overload handling measures (if BSCOVLH=TRUE). The BSC

regards the overload condition as no longer present, if the PPXX processor real time has dropped below thesame hardcoded threshold - oscillations are avoided using the timer T18 (see section ‘Mechanisms for trafficreduction').

6) A lack of PPXX memory resources is detected.

Background: This overload condition indicates a lack of physical memory available in the PPXX board. If the memory occupation of the PPXX exceeds a hardcoded threshold of 70%, the BSC starts overloadhandling (if BSCOVLH=TRUE) to avoid memory corruptions. The BSC regards the overload condition as nolonger present, if the PPXX memory usage has dropped below the same hardcoded threshold - oscillationsare avoided using the timer T18 (see section ‘Mechanisms for traffic reduction').





Category D: /* BSC Paging Queue Overflow */

7) An overflow occurs in the BSC paging queue.

Background: When the BSC receives PAGING messages from the MSC, it buffers them in a queue first,before it determines which BTSs belong to the affected LAC and delivers them towards the BTSs asPAGING COMMAND via the Abis LAPD channel(s) (LPDLR).

Starting from BR7.0/30 (since the implementation of CR2060), the BSC paging queue management wasredesigned to optimize the paging delivery and to avoid paging overload situations in the BTS preventively.

This redesign contains the following features:• A ‘two level’ paging queue concept is applied:

- one ‘receive’ paging queue for the temporary storage (buffering) of PAGING messages received fromthe MSC- additional ‘transmit/delivery’ paging queues, one per LAC and CCCH configuration ( called ‘scheduling’paging queues) with a varying number of queue places (please see the ‘threshold’ table below).

• For each of the ‘scheduling’ paging queues, the paging delivery rate (i.e. transmission rate of PAGINGCOMMAND messages to the BTSs) is adapted to the CCCH configuration (i.e. the number of CCCHblocks available for paging) of the affected cells. The ‘scheduling’ queues are not used for an additionalbuffering of the same paging messages but are only used to control the scheduled transmission of thePAGING COMMANDs to the BTSs with the suitable paging delivery rate.

• The paging, when received from the MSC, is stored in the primary queue. Immediately the paging isparsed to identify the scheduling queues that are relevant for this paging (i.e. for this LAC). A buffer isallocated for every scheduling queue. These buffers contain a ‘link’ (resp. reference) to the originalpaging stored in the primary queue. The scheduling queues are processed periodically and when the‘queuing timeout’ expires for a particular paging (i.e. when the paging is scheduled for transmission to theBTS in correspondence with the delivery rate applied in this scheduling queue), the paging is taken fromthe primary queue and sent to the involved BTSs as a PAGING COMMAND. When the paging has beensent to all the involved cells from all scheduling queues associated to this LAC (i.e. when the ’queuingtimeout’ has expired for the slowest and shortest secondary delivery queue for this paging), it is removedfrom the primary queue.

Architecture and characteristics of the BSC paging queuesWithin the BSC the cells (BTSs) are grouped by LAC and number of paging blocks available (depending onthe type of CCCH (MAINBCCH, MBCCHC or/and additional CCCH) and the setting of the parameter NBLKACGR (see command SET BTS [CCCH]). The maximum number of configurable LAC is restricted to20, the number of paging blocks possible are 9 (cells with number of paging blocks greater than 8 are

handled all together in the fastest delivery rate). Thus the number of possible delivery rates is limited to ‘9’. A paging scheduler mechanism is implemented which allows the generation of the theoretical maximum of 180 different ‘scheduling’ paging queues (20 LACs * 9 delivery rates).

The theoretical maximum number of buffered pagings is restricted to a little less than 360 (in releases beforeBR70/20 the total number of pagings that could be buffered in the BSC overall was restricted to 40). Theexpression ‘a little less than 360’ is used because 360 is the maximum number of internal buffers that can beused botha) for the temporary storage of PAGING messages in the primary queue (1 buffer per PAGING message)b) for the scheduling queues (1 buffer per queue).

Thus the number of buffers that are available for storage of PAGING messages in the primary queuedepends on the variety of different combinations of LAC and CCCH configuration (and thus the resultingnumber of scheduling queues) created in the BSC.

Examples:

1) If the theoretical maximum of LAC and delivery rate combinations (20 LACs * 9 delivery rates = 180) isconfigured in the BSC (which will never happen in any real-life-BSC!), a number of 180 buffers is reservedfor the scheduling queues. Consequently, the remaining number of buffer places for storage of PAGINGmessage in the primary queue would be 360-180=180.

2) If in the BSC configuration a realistic configuration of e.g. two different LACs and and two delivery ratesper LAC is used, then the number of buffer places reserved for the scheduling queue is2 LAC * 2 delivery rates = 4 buffers. Consequently, the remaining number of buffer places for storage of PAGING message in the primary queue is 360-4=354





The resulting paging delivery rates (PAGING COMMAND sent from BSC to BTS) are set in the followingway:

Paging delivery rates* for PPXL board:

In BR8.0 the MNTBMASK bits 30 and 31 (see command SET BSC [BASICS]) are used to control the pagingdelivery rate from BSC to BTS. The paging delivery rate can be adjusted to values of 100%..130% of the Umpaging throughput (considering that paging is only done with IMSI). These percentage values represent therelative percentage compared to the radio interface paging throughput which depends on the CCCHconfiguration (for further details please refer to the section ‘BSC Overload Handling’ in the appendix of thisdocument). The two bits are used as representation of a two-digit binary value to control the setting:

BIT31 BIT30 Paging delivery rate (BSC->BTS)

0 0 130% of Um paging throughput (paging with IMSI only)




In detail, the following throughput figures are achieved:

MNTBMASK BIT30-BIT31

No. of paging blocks inCCCH configuration

0 0

Delivery rate(130%)

0 1

Delivery rate(120%)

1 0

Delivery rate(110%)

1 1

Delivery rate(100%)

1 1/90.00 ms 1/100.00 ms 1/106.66 ms 1/116.66 ms

2 1/45.00 ms 1/50.00 ms 1/53.33 ms 1/60.00 ms

3 1/30.00 ms 1/33.33 ms 1/35.00 ms 1/40.00 ms

4 1/22.50 ms 1/25.00 ms 1/26.66 ms 1/30.00 ms

5 1/17.50 ms 1/20.00 ms 1/20.00 ms 1/23.33 ms

6 1/15.00 ms 1/16.66 ms 1/17.50 ms 1/20.00 ms

7 1/12.50 ms 1/15.00 ms 1/15.00 ms 1/15.00 ms

8 1/10.00 ms 1/12.50 ms 1/13.33 ms 1/16.66 ms

>8 1/10.00 ms 1/10.0 ms 1/10.0 ms 1/12.50 ms

For each delivery rate, a length threshold is defined for the ‘scheduling’ paging queues in correspondencewith the MNTBMASK bits 30 and 31 as follows:

MNTBMASK BIT30-BIT31

No. of paging blocks in

CCCH configuration

0 0

Secondary

queue places

0 1

Secondary

queue places

1 0

Secondary

queue places

1 1

Secondary

queue places

1 11 10 10 9

2 22 20 18 17

3 33 30 28 25

4 44 40 37 33

5 57 50 50 43

6 67 60 57 50

7 80 67 67 608 100 80 75 67

>8 100 100 100 80

This means that for a ‘scheduling’ paging queue the maximum number of queue places depends on theCCCH configuration and MNTBMASK setting as indicated in the table above. The length threshold (thelower the delivery rate, the less queue places are available) is applied to avoid that the ‘buffer time’ for thepagings gets too long. This is necessary because the MSC, when it does not receive a PAGINGRESPONSE to the first transmitted PAGING, repeats the paging procedure after a few seconds (therepetition time is defined by a configurable timer in the MSC (MOD NETTIMER, default 5 seconds).





Functional sequence of a CS paging deliveryWhen a paging arrives from A interface, it is analyzed in order to identify the queues involved in the deliveryof that paging. In detail, the "Cell Identifier List" Information Element (IE) is analyzed to identify the type of paging that was received.

a) If the “Cell Identifier List" IE contains

- a RACODE (can happen if a CS paging is received from the Gb interface) or - a Location Area Code (LAC) only or - a Location Area Identity (LAI, consisting of MCC, MNC and LAC)

the paging is queued in all the involved delivery queues that are under the threshold.

b) If the “Cell Identifier List" IE is missing , the paging is to be delivered to all cells of the BSC and the pagingis queued in all the involved delivery queues that are under the threshold in the way as indicated under (a).

c) If the “Cell Identifier List" IE contains

- a BVCI (can happen if a CS paging is received from the Gb interface) or - a Cell Identity (CI) only or - LAC and CI or - a Cell Global Identity (CGI, consisting of MCC, MNC LAC and CI)

the paging is sent directly towards the indicated cell without any queueing (CI included).

Hierarchical Paging in BR8.0To reduce the LAPD load due to PAGING COMMAND messages transmitted on Abis the feature‘Herarchical Paging’ was introduced in BR8.0. The purpose of this feature is supposed to eliminate the

redundancy that consists in the delivery of one and the same PAGING COMMAND messages to a BTSMseveral times parallel (once per BTS that belongs to the BTSM). Assuming e.g. that a BTSM contains 3BTSs (with all BTS having the same LAC), the BSC sends, for each paging procedure 3 PAGINGCOMMAND messages (1 per BTS) to the BTSM. This redundancy results in a waste of Abis LAPDbandwidth and thus increases the probability of LAPD link congestion or/and buffering delay of LAPDmessages.

For this reason, in BR8.0 the BSC combines the previous 3 PAGING COMMAND messages to one newmessage called PAGING COMMAND BTSM. This message has exactly the same format like a usualPAGING COMMAND, but contains an additional IE called ‘BTSM Broadcast Info’ which indicates, for eachBTS/cell addressed, the relevant addressing data of the paging channel, which isa) the channel no.b) the Paging groupc) the TEI of the BCCH TRX.

The BTSM then re-generates the PAGIN COMMAND messages to be sent to the individuial BTSs andforwards them to the relevant BTS TRXs.





Functional sequence of Gb PS paging delivery

Packet pagings may occur in particular networks, e.g. when the so-called ‘blackberry’ application is used(this application forsees the delivery of e-mails to GPRS attached subscribers via GPRS).

General remark: the PTPPKF objects (that represent the configured GPRS cells) are distributed over theavailable PCUs for loadsharing reasons. The distribution is unable to guarantee a one-to-one relashionshipbetween LAC/RAC and PCU. In other words, the cells (PTPPKF objects) that belong to the same LAC/RACmay be served by different PCUs. In any case, the load balancing tries to group as much as possible the

PTPPKF belonging to the same LAC/RAC on the same PCU1) The Packet Paging (PAPS) is received from Gb interface.The SGSN transmits the PAPS messages for a particular LAC/RAC, one message for each configured PCUthat serves a cell (PTPPKF) that belongs to the affected LAC/RAC. This means that multiple PCUs will leadto multiple PAPS messages, when the PTPPKFs of the same LAC/RAC are served by different PCUs.

2) The PCUs forward each received PAPS message to the TDPC. As a consequence of theabovementioned principle, the TDPC may receive multiple PAPS messages for the same LAC/RAC, butfrom different PCUs and thus belonging to different cells (PTPPKFs).

3) The TDPC stores stores the PAPS messages in the BSC paging queues as described below:

3.1)From the LAC/RAC information contained in the PAPS message, the TDPC determines which secondarypaging delivery queue is relevant. The secondary delivery queues are managed 'per LAC' (the 'Routing Area'represented by the RAC can only represent a ‘sub-area’ of the Location Area represented by the LAC).

Due to the fact that at maximum 20 LAC+RAC can be configured in the system, and as for the CS domain

there are at the maximum 9 different delivery rates, the resulting secondary queues are exactly the same asin the CS domain 20 LAC/RAC * 9 delivery rates = 180 secondary queues.

3.2) Asa) the distribution of PTPPKFs (GPRS cells) over the PCUs is done on a 'per cell' basis ('per PTPPKF') andthe load balancing tries to group as much as possible the PTPPKF belonging to the same LAC/RAC on thesame PCU (but may not always be able to do so)b) the paging delivery queues in the BSC are managed per combination of LAC/RAC and CCCHconfiguration,it is normal that PAPS messages for the same LAC/RAC, but received from different PCUs (for differentPTPPKFs) finally end up in the same paging delivery queue. This means that a PAPS for a particular LAC/RAC may appear in a paging delivery queue more than once. In networks with high PS pagingvolumes, this problem might induce BSC paging queue overflows, even if the total number of pagedsubscribers does not exceed the storage capacity of the BSC paging queue.

3.3) Together with the PAPS message contents itself, the TDPC stores the information from which PCU (andfor which PTPPKF) the PAPS was received in the queue places of the primary paging queue.

4) When the PAPS is scheduled for delivery to the BTSs, the BSC checks from which PCU and for whichcells (PTPPKFs) the PAPS was received and delivers the PS paging only to the affected cell.(Remark: In contrast to this, for CS pagings (that are held in the same queues) the check is not performed asthe paging is always delivered to all cells of the LAC).

BR8.0 Improvement in step 3.2) As the described implementation has the disadvantage that one and the same paging might end up severaltimes in the secondary delivery queues (increasing the probability of BSC paging queue overload), a (patch)solution was developed in BR8.0, which checks, for each received PAPS, whether exactly this paging isalready present in all the relevant secondary paging queues.If yes, the new received (redundant) PAPS is discarded and not placed into the primary paging queueanymore (as it is already present, coming from the SGSN for a different PCU). If the paging is not yet

present in the secondary queues, the PAPS is stored in the primary queue and a corresponding index is setin the relevant secondary delivery queues as dscribed above.

This modification is implemented in BR8.0 via TDPC patch (please refer to the Release Documentation for the exact patch number and the associated BSC loads).

The two diagrams on the subsequent pages show the differences between the old situation and the newimproved solution.





Diagram - PS paging delivery in BR7.0The diagram below shows the (BR7.0) implementation of PAPS delivery, which may lead to multipleinsertion of one and the same paging into the primary and secondary paging delivery queues.

Primary queue

TDPC

PCU-0 PCU-1 PCU-11…

SGSN

FRL-x FRL-y FRL-z FRL-w

MSC

a,e,I b,f,l c,g,m d,h,n

Secondaryqueues

BTS-a BTS-b

BTS-c

BTS-i BTS-l

BTS-m

BTS-e BTS-f

BTS-g

… …

RAC-x RAC-y

RAC-x RAC-y

RAC-x

BTS-d

BTS-h

BTS-n





Diagram - Improved PS paging delivery in BR8.0The diagram below shows the improved (BR8.0) implementation of PAPS delivery, which may lead tomultiple insertion of one and the same paging into the primary and secondary paging delivery queues.

TDPC

PCU-0 PCU-1 PCU-11…

SGSN

FRL-x FRL-y FRL-z FRL-w

Primary queue

Secondaryqueues

BTS-a BTS-b

BTS-c

BTS-i BTS-l

BTS-m

BTS-e BTS-f

BTS-g

… …

MSC

RAC-x RAC-y

RAC-x RAC-y

RAC-x

BTS-d

BTS-h

BTS-n

a,e,Ib,f,l c,g,m d,h,n

Is the received pagingalready present in all the

affected secondary queues ?

END

DISCARD

YES

NO

Rate

10 ms

Rate

90 ms





OVERLOAD detection conditions, notification to MSC and alarm "BSC PAGING QUEUE OVERLOAD"

An overload of the BSC paging queue occurs in the following cases

1) If a paging arrives from the A interface / Gb interface when the sum of scheduling queue buffers and thenumber of currently buffered pagings has already reached 360, the new paging is discarded.

2) If a paging arrives from the A interface / Gb interface when the sum of scheduling queue buffers and thenumber of currently buffered pagings has not yet reached 360 but the received paging cannot be queued inany scheduling queue associated to the LAC indicated in the PAGING message due to the fact that the

threshold was already reached in the queues related to the indicated LAC, the new paging is discarded.In both cases the BSC reacts in the same way:If the percentage of discarded pagings has exceeded the threshold defined by the parameter PAGQOVLIND(see command SET BSC [BASICS]) in the last second, the alarm ‘BSC PAGING QUEUE OVERLOAD’ israised and the BSSMAP OVERLOAD message is sent the MSC.

The alarm "BSC PAGING QUEUE OVERLOAD" is ceased and the BSSMAP OVERLOAD message sendingis stopped if for a time period defined by timer T18 time no pagings have been discarded. Please see section‘Special overload supervision algorithm in case of BSC paging queue overflow’ for further details.

Congestion situation in single scheduling paging queues

If a scheduling paging queue with a small CCCH configuration/delivery rate has reached the limit defined bythe ‘threshold’, and a new PAGING received for the same LAC cannot be placed in this queue, while it canbe placed in another queue for the same LAC but a greater CCCH configuration/delivery rate, the PAGING

COMMAND will not be sent to the BTSs with the small CCCH configuration/delivery rate (as the associatedqueue is congested) but no alarm will be output as the paging is not discarded because it can be placed inone queue for the affected LAC.

The alarm "BSC PAGING QUEUE OVERLOAD" is output only if a PAGING cannot be placed in any of thescheduling paging queues available for one LAC.





2.10.1.2 System reactions and overload regulation measures in case of BSCoverload

The BSC overload regulation measures depend on the type of overload condition which was detected by theBSC.

As listed above, the following BSC overload conditions exist:

(1) Congestion of the CCS7 Tx buffers(2) Lack of level 3 transaction registers(3) Excessive TDPC real time processor load(4) Lack of TDPC memory(5) Excessive PPXX real time processor load(6) Lack of PPXX memory(7) Overflow of the BSC paging queue

The BSC reaction to the listed overload condition varies depending on the type of overload condition. Thefollowing cases must be distinguished:

Case A: Conditions (1),(2), (3), (4), (5) or (6) are detected

When conditions (1),(2), (3), (4), (5) or (6) are detected (or more than one of them at the same time), theBSC- outputs an alarm message ‘249 - BSC Overload detected’ towards the O&M output media (RC, LMT, eventlogfile) *

- sends the BSSMAP message OVERLOAD without cell identity (**see note in section “Further importantnotes on BSC reactions”) and with cause value ‘processor overload’ to the MSC (one message every 2seconds, see timer T2 as explained in the sections below)- starts an algorithm for the reduction of terminating traffic which systematically discards PAGING messagesreceived from the MSC (detailed description see below)- starts an algorithm for the reduction of originating traffic which systematically discards CHANNELREQUIRED messages received from the BTSs (detailed description see below).

* Within the alarm message the BSC overload cause is indicated as shown in the following table:

BSC Overload condition Overload cause value in

’BSC overload detected’ alarm

message

Alarm output only if

BSCOVLH=TRUE ?

(1) Congestion of the CCS7 Tx buffers 05 no, output in any case

(2) Lack of level 3 transaction registers 02, 03, 05 no, output in any case

(3) Excessive TDPC real time processor load 01 yes

(4) Lack of TDPC memory 07, 08, 09 no, output in any case

(5) Excessive PPXX real time processor load 0F no, output in any case

(6) Lack of PPXX memory 0F no, output in any case

Case B: Conditions (7) is detected (overflow of BSC paging queue)

When condition (7) is detected, the BSC- outputs an alarm message ‘BSC PAGING QUEUE OVERLOAD’ towards the O&M output media (RC, LMT,event logfile)- sends the BSSMAP message OVERLOAD (without cell identity (**see note in section “Further important

notes on BSC reactions”) and with cause value ‘processor overload’ to the MSC (one message everysecond, see timer T1 as explained in the sections below)

In this case, no reduction of originating or terminating traffic is performed at all.Instead, terminating traffic is reduced indirectly due to the fact that the MSC reduces the PAGING messageswhen it receives an OVERLOAD message from the BSC which indicates BSC overload.





2.10.1.2.1 Further important notes on BSC reactions

- ** The BSSMAP OVERLOAD message which is sent from BSC to MSC contains the optional IE ‚Cell

Identifier’ if the overload to be reported only concerns specific BTSs (resp. cells) only (i.e. RACH or PCH

overload has occurred). Whether this IE is included or not makes an important difference in the MSC

overload handling:

If the SIEMENS MSC receives the OVERLOAD without the cell Identifier, it assumes a general overload

situation for the whole BSC and starts an algorithm for the reduction of the paging procedures towards this

BSC. If the MSC receives the OVERLOAD with the cell Identifier, it assumes an overload situation in theaffected BTS only and starts an algorithm for the reduction of the handover procedures towards the affected

cell.

For all the abovementioned BSC overload conditions, the BSC will indicate ‘processor overload’ asOVERLOAD cause.

- When one of the mentioned overload condition is detected, the BSC outputs the alarm message BSCOVERLOAD DETECTED to the O&M interfaces (LMT, RC, internal logfiles). If during the overloadregulations additional overload conditions are detected, they are not explicitly signaled to the O&M outputmedia (RC, LMT, event logfiles). When the overload regulation has stopped, the BSC outputs a ‘cleared’indication for the overload alarm (for details, please see below). Attention: the OVERLOAD DETECTED alarm message for the TDPC real time processor overload conditionis only output if BSCOVLH=TRUE!

- In case of TDPC processor overload, the overload condition ends if the TDPC processor load has dropped

below the threshold set by the parameter OVLENTHR (see command SET BSC [BASICS])





2.10.1.3 Mechanisms for reduction of originating traffic and reduction of terminating traffic

2.10.1.3.1 Overload level management

The new overload management is based ‘overload level’ mechanism. The ‘overload level’ determines towhich extent originating or terminating traffic is reduced. It is realized as a counter variable, which isautomatically increased if after a defined observation period the overload conditions still persist. Theoverload level is managed as shown in the following diagram:

Overload detected

Overload

Cause still

present

- Overload level ++

- Send Overload MSG

to MSC

YES

Overload level --

NO

Start Timer 2

sec.

Overload

Level == 0

YESOVERLOAD

ENDED

NO

- Overload level = 1

- Send Overload MSG to MSC

- Start T18

Wait T18

expiration

NOTE : If T18 expirates during Overload management (i.e. when Overload Level is notzero) this timer is simply restarted.

When the overload process receives the first trigger (BSC overload detected), the BSC overload level is setto ‘1’, a ‘BSC Overload Detected’ alarm is sent to O&M, a BSSMAP OVERLOAD message is sent towardsthe MSC, and two timers are started :

- T2 (timer fixed to 2 sec. ) represents the BSC overload level escalation/de-escalation timer .It drives the increase and reduction of the overload level. If after T2 expiry an overload condition is stillpresent, the overload level is increased, otherwise it is decreased.The timer T17 (see parameter BSCT17 in command SET BSC [TIMER]) is no longer used.

Overloadstill present after

T2 expiry?

reduce overloadlevel by 1

Start overloadescalation timer

T2 (2 sec.)

- increase overload level by 1- OVERLOAD message to MSC

- Restart of T18

Wait for T18

expiry

*When T18 expires during overload regulation and the overload level value is not ‘0’ (zero), T18 is simply restarted.

Only when T18 expires when the overload level has reached the value ‘0’, the expiry of T18 triggers the ceasing of the‘Overload detected’ alarm message.

T18 expiry

- overload end- overload alarmceased

- overload level = 1- output ‘overload detected’ alarm to O&M- send OVERLOAD message to MSC

- Start of timer overload alarm timerT18 *





- T18 (see parameter BSCT18 in command SET BSC [TIMER]) represents the Overload O&M alarmobservation timer and is used to observe and detect the overload end condition. If the overload levelhas reached the value ‘0’ (zero), the expiry of T18 triggers the ceasing of the ‘BSC overload detectedalarm’. T18 is restarted on every increase of the overload level. If the overload level is not ‘0’, a specificpercentage of PAGING messages and CHANNEL REQUIRED message is discarded as described inthe section below.

2.10.1.3.2 Traffic reduction algorithmsThe BSC reduces originating traffic by the discarding of CHANNEL REQUIRED messages (messages sentfrom BTS to BSC indicating a request of an MS for a dedicated channel) in a specific cycle. To which extentthe CHANNEL REQUEST messages are discarded depends on the current value of the ‘overload level’.The BSC reduces terminating traffic by the discarding of PAGING messages in a specific cycle. To whichextent the PAGING messages are discarded depends on the current value of the ‘overload level’.

The following table shows in which cycle CHANNEL REQUIRED and PAGING messages are discardeddepending on the current overload level.

Overload

LevelCH_REQ 1 CH_REQ 2 CH_REQ 3 CH_REQ 4 CH_REQ 5 CH_REQ 6 CH_REQ 7 CH_REQ 8 CH_REQ 9 CH_REQ 10 Perc.

0 0%

1 Discarded 10%2 Discarded Discarded 20%

3 Discarded Discarded Discarded 30%

4 Discarded Discarded Discarded Discarded 40%

5 Discarded Discarded Discarded Discarded Discarded 50%

6 Discarded Discarded Discarded Discarded Discarded Discarded 60%

7 Discarded Discarded Discarded Discarded Discarded Discarded Discarded 70%

8 Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded 80%

9 Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded 90%

10 Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded 100%

Overload

LevelPaging 1 Paging 2 Paging 3 Paging 4 Paging 5 Paging 6 Paging 7 Paging 8 Paging 9 Paging 10 Perc.

0 0%

1 Discarded 10%

2 Discarded Discarded 20%

3 Discarded Discarded Discarded 30%

4 Discarded Discarded Discarded Discarded 40%

5 Discarded Discarded Discarded Discarded Discarded 50%

6 Discarded Discarded Discarded Discarded Discarded Discarded 60%

7 Discarded Discarded Discarded Discarded Discarded Discarded Discarded 70%

8 Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded 80%

9 Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded 90%

10 Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded Discarded 100%

Channel Required and Paging messages discarding

Important Notes:

a) For BSC overload only one overload level variable is managed. This means that this overload levelsimultaneously determines degree of discarding for both PAGING and CHANNEL REQUIRED messagesthe.b) CHANNEL REQUIRED messages with establishment cause ‘emergency call’ and with with establishmentcause ‘answer to paging’ are not discarded in the algorithm of overload management. The exclusion of CHANNEL REQUIRED messages with cause ‘answer to paging from the discarding is done to avoid adouble discarding of one and the same terminating call attempt during paging and immediate assignment

and thus to ensure that for those PAGING messages, which were not discarded and which really reachedthe called mobile subscriber in a particular cell, the MTC or SMS-MT setup can be successfully completed.





2.10.1.3.3 Special overload supervision algorithm in case of BSC paging queue overflow

The overload supervision algorithm for the BSC paging queue overflow (alarm ‘BSC PAGING QUEUEOVERLOAD’ output) differs a little from the one which is used for all other BSC overload conditions (asdescribed in section 1.3.1).When an incoming PAGING message from the MSC is discarded due to lack of space in the BSC pagingqueue. When the percentage of discarded pagings has exceeded the threshold defined by the parameter PAGQOVLIND (see command SET BSC [BASICS]) in the last second, an alarm is sent to the O&M outputmedia (RC, LMT, event logfiles) and an OVERLOAD message (without cell identifier) is sent to the MSC

(one message every second). At the same time, two timers are started :

• T1, represents the BSC paging queue overload observation timer and is hardcoded to 1s. This timer also defines the frequency of the BSSMAP OVERLOAD message sending.

• T18 (see parameter BSCT18 in command SET BSC [TIMER]) represents the Overload O&M alarmobservation timer , see section 1.3.1.

When T1 expires, a check is performed to see if in the last second some PAGINGs were discarded. If yes,T18 is restarted and a BSSMAP OVERLOAD message is sent to the MSC again. If no further PAGING wasdiscarded during the runtime of T1, only T1 is restarted.

When T18 expires, T1 is stopped and the alarm ‘ceased’ indication is sent. In other words, the alarm isceased, if during the runtime of T18 no PAGING was discarded.

2.10.2 MSC Overload2.10.2.1 System reactions and overload regulation measures in case of MSCoverload

MSC overload regulation is only started, if the database flag MSCOVLH (see command SET BSC [BASICS])is set to TRUE. MSC overload is detected when the BSC receives the BSSMAP message OVERLOAD fromthe MSC.

2.10.2.1.1 Special overload level escalation algorithm in case of MSC overload

In early BR7.0 releases, MSC overload was treated in the same way as a BSC overload situation, i.e. thetraffic reduction measures as well as the overload supervision mechanism was the same in both cases. Theonly difference was (and is still) that, of course, in case of MSC overload, no BSSMAP OVERLOAD is sentto the MSC (like it is done in case of BSC overload condition).

Due to the implementation of the change request CR2202 in BR70/25 the BSC behaviour was changed: Thedifference in the overload handling mechanism between MSC overload and BSC overload (not consideringthe exception case ‘BSC paging queue overflow’) is that in case of MSC overload only originating traffic isreduced, as the reduction of the terminating traffic is performed by the MSC already.

Moreover, a different overload level management and overload supervision mechanism is applied based onthe timers T17 and T18 (see parameters BSCT17 and BSCT18 in command SET BSC [BASICS]). Thismeans that the diagram in the section ‘Overload level management’ is not valid for MSC overload handling.

Due to CR2202, the overload level management is implemented as follows:- When the BSC receives the first BSSMAP message OVERLOAD from the MSC, the timers T17 and T18are started, the overload level is set to ‘1’ and the first step of the originating traffic reduction (discarding of CHANNEL REQUIRED messages) takes place. Moreover, the alarm ‘MSC Overload detected’ is output.- As long as T17 is running, other MSC overload indications are ignored.- If at least one forther OVERLOAD message is received from the MSC in the time period between T17expiry and T18 expiry, the overload level is increased by ‘1’ when T18 expires and both timers restarted. If

no further OVERLOAD message is received from the MSC, the expiry of T18 triggers the decrease of theoverload level by one step.- When the overload level has reached the value ‘0’ and T18 expired for the last time, the MSC overloadalarm is cleared.

Remark: In the SIEMENS MSC the frequency of the OVERLOAD message sending is set by commandMOD NETTIMER:BSSAPT=TO-<value>, default value is 10s (1s step size).





Case E: MSC Overload detected (BSSMAP OVERLOAD message received from MSC)

When MSC overload is detected the BSC- outputs an alarm message ‘188 - MSC Overload detected’ with overload cause ‘0xFF’ towards the O&Moutput media (RC, LMT, event logfile)- starts an algorithm for the reduction of originating traffic which systematically discards CHANNELREQUIRED messages received from the BTSs (detailed description see above).Terminating traffic is not reduced as the MSC reduces the terminating traffic itself.

These measures are only taken if parameter MSCOVLH=TRUE (see command SET BSC [BASICS]).





2.10.3 BTS Overload

2.10.3.1 BTS overload conditions

The following situations represent an overload situation in the BSC:

Category A: /* PCH Overload in BTS */ (MSG_OVERLD)

1) The BSC has received the Abis RSL message OVERLOAD from the BTS.

Background: During the paging procedure (applied for MTC and SMS-MT procedures) the BSC receivesPAGING messages from the MSC, which contain a subscriber Identity, a paging group number and a LAC.The BSC determines which BTSs belong to the same LAC and forwards the paging in form of a PAGINGCOMMAND to the BTSs. The BTS keeps one paging queue with two queue places for each paging group.Each queue place can contain one PAGING REQUEST message, which in turn can contain up to 4subscriber identities. In correspondence with the paging group and the type of subscriber identity the BTSassembles the PAGING REQUEST messages by combining the subscriber identities of up to 4 PAGINGCOMMANDs into one PAGING REQUEST TYPE 1, 2 or 3 message (Which PAGING REQUEST TYPE isused depends on the type and number of identities stored in the paging queue), which are then transmittedover the radio interface if a suitable CCCH block is scheduled within the CCCH multiframe sequence.

If all BTS paging queues are congested and the BTS cannot place the subscriber identity a receivedPAGING COMMAND into a BTS paging queue, the BTS discards the PAGING COMMAND and sends the Abis RSL message OVERLOAD with cause ‘CCCH overload‘ to the BSC (at this point the BTS has alreadystarted to its own load management measures such as ‘extended paging and ‘paging reorganization). For

the BSC the receipt of this OVERLOAD message is the indication for a PCH overload situation in the BTSand, if BTS overload handling is enabled (BTSOVLH=TRUE), the trigger event for the BTS overload alarmoutput and the start or continuation of suitable overload regulation measures.

As another preventive load defense action against PCH overload escalation, an additional mechanism wasimplemented in BR7.0:

Category B: /* AGCH Overload in BTS */ (MSG_DELIND)

2) The BSC has received the Abis RSL message DELETE INDICATION from the BTS.

Background: Every call (MOC, MTC, MEC) or dedicated transaction (Location Update, IMSI Detach, SMSetc.) requires the assignment of a dedicated signalling channel (normally an SDCCH). The dedicatedsignaling channel assignment is performed by the IMMEDIATE ASSIGNMENT procedure: The BSC sendsan IMMEDIATE ASSIGNMENT COMMAND to the BTS which, in the successful case, forwards thismessage to the MS via the AGCH. AGCHs and PCHs share the same CCCH blocks on the Um interface, i.e. the same CCCH capacities are

used for the transmission of PAGING REQUEST messages (PCH) and for transmission of IMMEDIATE ASSIGNMENT COMMAND (or, if no SDCCH is available in the BTS, also IMMEDIATE ASSIGNMENTREJECT) messages.

For each configured CCCH (represented by the channel types MAINBCCH, MBCCHC and CCCH) the BTSprovides an AGCH queue with 16 places, where each IMMEDIATE ASSIGNMENT COMMAND or (in case of SDCCH blocking) IMMEDIATE ASSIGNMENT REJECT requires one place. How quickly the queue isemptied, generally depends on the current paging traffic volume and on how many CCCH blocks arereserved for AGCH (NBLKACGR setting). If the BTS receives an IMMEDIATE ASSIGNMENT COMMAND or IMMEDIATE ASSIGNMENT REJECT for a particular CCCH timeslot which cannot be placed in the AGCHqueue associated to that CCCH timeslot, the BTS discards the IMMEDIATE ASSIGNMENT message andsends a DELETE INDICATION (that contains the original IMMEDIATE ASSIGNMENT COMMAND or REJECT message) to the BSC to indicate that the request of the MS for the assignment of a dedicatedsignalling channel could not be satisfied. Since BR8.0 a DELETE INDICATION can be also be sent, if thevalidity of an IMMEDIATE ASSIGNMENT (REJECT) message has already expired (see below).

For the BSC the receipt of this DELETE INDICATION message is the indication for an AGCH overloadsituation in the BTS and, if BTS overload handling is enabled (BTSOVLH=TRUE), leads to the output of acorresponding alarm message - however, since BR8.0 the BSC will not start any traffic reduction measuresin this case.

In releases up to BR7.0 Paging was generally treated with priority, i.e. if both paging and IMMEDIATE ASSIGNMENT COMMAND messages were to be transmitted, the BTS used the CCCH slot for paging first.Thus the PCH traffic volume had a considerable impact on the IMMEDIATE ASSIGNMENT via the AGCH:the higher the paging traffic volume, the less CCCH space was available for IMMEDIATE ASSIGNMENT viathe AGCH. To guarantee a minimum throughput of IMMEDIATE ASSIGNMENTs via the AGCH, it was only possible to reserve CCCH blocks exclusively for AGCH (see parameter NBLKACGR in command SET BTS





[CCCH]), but the drawback of this implementation was that CCCH blocks that were reserved for AGCH byNBLKACGR could never be used for PCH.

This approach was replaced by a more intelligent way of CCCH block management between PCH and AGCH usage:

Improvement of CCCH handling between PCH and AGCH In order to avoid AGCH shortages in time periods of high PCH load and high AGCH load, in BR8.0 amechanism was introduced which observes the current state of the AGCH queues and dynamically priorizesthe AGCH messages higher than the paging messages if the detected AGCH queue load requires it.Priorizing paging message higher than AGCH messages by any means (as it was done in releases up toBR7.0) does not make sense without reservation of CCCH-blocks for AGCH, as a paging procedure canonly lead to the successful setup of an MTC, if AGCH resources are available for the SDCCH assignment,which is a precondition for the transmission of a paging response. On the other hand, the reservation of CCCH blocks for AGCH restricts the PCH throughput even if the reseved CCCH block is not used for AGCH.To make the CCCH block management more flexible the new mechanism was introduced which dynamicallymanages the AGCH message priority depending on the current filling state of the AGCH queue and featuresthe ‘preemption’ of unreserved CCCH blocks (i.e. blocks that are shared between PCH and AGCH) for AGCH procedures even if also paging messages are queued for transmission in the BTS paging queues.

Moreover, with the new approach, the BTS observes the ‘age’ of the AGCH messages in the AGCH queueanda) considers this ‘age’ for the AGCH priority management andb) discards AGCH messages from the queue that have been delayed by processing and queuing for too

long.

AGCH queue timeout mechanismThree operative states have been defined for the AGCH queue in order to tackle the statistical variability of the signaling load: NORMAL, MEDIUM and HIGH

These states determine the BTS behaviour with respect to the choice whether to apply preemption on PCHblocks or not. The transitions between the states are mediated by the supervision of the followingparameters, calculated on receipt of every IMMEDIATE ASSIGNMENT message:

AGCH_Q_FILLING

T1 = FN (IMM ASS received) – FN (CHAN REQ received)

T2 = FN (AGCH scheduled on air)

S = S (TX_INT, CCCH_CONF)

OVL

T = Max (M * (S + TX_INT -1), TX_INT + 2 * S)

with

FN = frame number

AGCH_Q_FILLING = the number of AGCH message pending in the AGCH queue.

T1 = the time (expressed in number of frames) elapsed between the receipt of the Channel Request and the receipt of the corresponding IMMEDIATE ASSIGNMENT message from BSC

T2 = the minimum time required to deliver on air the IMMEDIATE ASSIGNMENT, considering- the filling state of the AGCH queue and the availability of reserved blocks- the filling state of the different PCH queues (paging group) still to be scheduled- the state of the AGCH queue (NORMAL, MEDIUM, HIGH)

S = the minimum time interval between two RACH accesses (in case of retransmission). As stated in GSM 44018 this is

a function of TX_INT (derived from the parameter NSLOTST, see command SET BTS [CCCH]) and of the channelconfiguration (combined or not combined CCCH) and it is expressed in frame number as follows:

tx_integer

td (RACH slots,

combined BCCH )

td (RACH slots,

uncom bined BCCH )

3, 8, 14, 50 41 (0.35 sec) 55 (0.25 sec)

4, 9, 16 52 (0.45 sec) 76 (0.35 sec)

5, 10, 20 58 (0.50 sec) 109 (0.50 sec)

6, 11, 25 86 (0.75 sec) 163(0.75 sec)

7, 12, 32 115 (1.00 sec) 217(1.00 sec)





OVL = a 16-bits bitmap taking account of the number of IMMEDIATE ASSIGNMENT message liable to delay, because of the AGCH load. This bitmap provides a “positional” or “one to one” representation of the delayed blocks waiting for delivery. An OVL bit is raised if and only if

T1 + T2 > S (TX_INT, CCCH_CONF) AND T1 + T2 < T

i.e. it is raised for those IMM ASS (REJ) messages that are in danger of being delayed too much if not quickly deliveredover the Um interface. OVL bits are lowered every time a delayed AGCH (accounted by the OVL bitmap) leaves thequeue.

T = the maximum time taken to repeat the last M RACH, in case, meanwhile, no IMMEDIATE ASSIGNMENT message is

received by the MS. After this period any AGCH relating to one of these RACH will be ignored. In this sense T is thelongest probable period the MS waits for the IMMEDIATE ASSIGNMENT, before definitely aborting the procedure.TX_INT is a parameter broadcast in SYS_INFO 1-2-3-4.

M = min (MaxRetrans + 1, 3) and MaxRetrans, the number of RACH retransmissions configured by Operator (see

parameter MAXRETR in command SET BTS [CCCH]).

Whatever the state is, an IMMEDIATE ASSIGNMENT or IMMEDIATE ASSIGNMENT REJECT message isonly sent over the Um interface, if the condition

T1 + T2 <= T

is fulfilled.T1 + T2 is the total time elapsed from the receipt of the CHANNEL REQUEST on the RACH to theexpected/likely delivery of the corresponding AGCH message to the MS (the time spent on air interface isnegligible in this context).

This means that this mechanism ensures that AGCH messages are not transmitted if they have beendelayed for too long due to signalling processing and AGCH queuing. In other words, this mechanismguarantees that the BTS will not send an IMMEDIATE ASSIGNMENT or IMMEDIATE ASSIGNMENTREJECT message to the MS, when the waiting time of the MS for the receipt of these messages(determined by the parameters NSLOTST and MAXRETR) has already expired.

If the above condition is not fulfilled (i.e. if T1 +T2 > T), the IMMEDIATE ASSIGMENT (REJECT) messageare discarded in the BTS to avoid a waste of CCCH resources for AGCH messages that will in any case notbe accepted by the MS anymore.

The mentioned check (T1 + T2 <= T ?) is performed at two points of time in the processing:

a) on receipt of the IMMEDIATE ASSIGNMENT (REJECT) from the BSC via the Abis A delay of the IMMEDIATE ASSIGNMENT (REJECT) message when received from the BSC may happen incase of long Abis link propagation time or/and in case of congestion in LAPD transmit queues in the BSC).

Thus, if the IMM ASS (REJ) arrives at the BTS and the BTS check establishes that the sum of - the current delay and- the time that will additionally pass until the message can be delievered over the Umexceeds the time value ‘T’, the message is discarded immediately.

b) immediately before transmission of the the IMMEDIATE ASSIGNMENT (REJECT) via the Um The actual condition of the queues, at the moment of the delivery, could have been changed. Therefore,before sending the IMM ASS (REJ), the BTS performs the check again. If the check establishes thatT1 +T2 > T, the IMM ASS (REJ) is discarded and the AGCH queue is scanned looking for the first blockfulfilling the check positively.

In both cases, the BTS sends a DELETE INDICATION to the BSC indicating the unsuccessful delivery of themessage.

Attention: As, from the BSC point of view, these events are treated in the same way like normalAGCH overloads, the alarm ‘BTS OVERLOAD DETECTED’ for cause value ‘AGCH overload’ may

occur more often than in BR7.0. In these cases, however, the alarm does not necessarily indicate anoverflow of the AGCH queue but the discarding of AGCH messages that would arrive at the MS toolate!

Important note for case b): As in BR8.0, the BTS may

- combine two IMMEDIATE ASSIGNMENT messages into one IMMEDIATE ASSIGNMENT EXTENDEDmessage (i.e. one message serving two subscriber requests) and- combine the IMMEDIATE ASSIGNMENT REJECT messages for up to 4 received subcriber requests,

the DELETE INDICATION, which the BTS sends after the ‘T’ timeout detection immediately before the Um transmission and, may contain the AGCH messages as they have been enqueued in the AGCH queue, i.e. itmay contain IMM ASS EXT messages for two requests or IMM ASS REJ messages for up to 4 different





subscriber requests. Thus the BTS may send only one DEL IND for several IMM ASS procedures that werestarted by the BSC.

AGCH/PCH preemption mechanism The priority of PCH messages before AGCH messages depends on the current AGCH queue filling state.In detail, the aforementioned operative states defined for the AGCH queue (AGCH_Q_STATE) with thevalues NORMAL, MEDIUM and HIGH are managed as follows:

1) AGCH_Q_STATE = NORMAL

This NORMAL state value is defined by the following conditions:- No OVL bits raised and- AGCH_Q_FILLING < 12 (i.e. less than 12 of 16 AGCH queue places are currently used)

PCH/AGCH management:PCH messages continue to have a higher priority than AGCH messages (there is no preemption). Thisimplies that the IMMEDIATE ASSIGNMENT message waiting for delivery in the AGCH queue are deliveredon a non-reserved block only if no PAGING REQUEST (or, eventually, PACKET DOWNLINK ASSIGNMENT) message is pending in the paging queue (see picture below). This case reflects the systembehavior up to BR7.0.

As mentioned above, an OVL bit is raised if and only if


In this case the AGCH_Q_STATE becomes MEDIUM.





2) AGCH_Q_STATE = MEDIUM

This MEDIUM state value is defined by the following conditions:- At least one OVL bit already raised- AGCH_Q_FILLING < 12

PCH/AGCH management:Under these conditions, the preemption takes place only on those paging queues that are- Completely empty or

- Half full, but not already preempted during the last CCCH cycle As mentioned above, an OVL bit is raised if and only if


In this case the AGCH_Q_STATE becomes MEDIUM.

OVL bits are lowered every time a delayed AGCH (accounted by the OVL bitmap) leaves the queue.

3) AGCH_Q_STATE = HIGH

This HIGH state value is defined by the following conditions:- AGCH_Q_FILLING >= 12

PCH/AGCH management:In this case AGCH blocks have absolute precedence over PCH ones until the number of AGCH pending inqueue drops again below 12. The handling of OVL bit is the same as in MEDIUM state.

BCCH AGCH AGCH PCH

AGCH

PCH

AGCH

PCH

AGCH

PCH

AGCH

PCH

AGCH

PCH

AGCH

PCH

AGCH

16

15

14

13

12

11

10

09

08

07

06

05

04

03

02

01

02

01

P a gi n g Q u e u e s

S e c on d R e q u e s t F i r s t R e q u

e s t

B0 B1 B2 B3 B4 B5 B6 B7 B8

AGCH_BUCKET_FILLING >= 12

S = 41

LASTIMMASS

BCCH AGCH AGCH PCH

AGCH

PCH

AGCH

PCH

AGCH

PCH

AGCH

PCH

AGCH

PCH

AGCH

PCH

AGCH

B0 B1 B2 B3 B4 B5 B6 B7 B8

R e c e i v e d h e r e

51 Multiframe

preempted preemptedpreempted

Automatic limitation of CCCH block preemption for AGCH messages:When the CCCH block of a particular PCH group was preempted for transmission AGCH, the BTS suspendsthe AGCH preemption for this paging group for the next paging group cycle, i.e. when the same paginggroup is scheduled again for transmission over Um, the ‘shared’ CCCH blocks messages cannot bepreempted for AGCH again. This is done in order to not to delay the Um delivery of paging message for onepaging group via the Um interface for too long. CCCH blocks of other paging groups may be preemptedindependently of this suspesion, but, of course, the same principles apply for all paging groups.





Category C: /* Abis LAPD signaling overload UL */ (MSG_LAPDOVLUP)4) The BSC has received the Abis O&M message ‘LAPD overload’ from a particular BTSM

Background: The layer 2 functions of the LAPD protocol feature a buffering mechanism. All transmitted LAPD messagesare buffered until they are positively acknowledged by the remote end (in this case from the BSC). Theassociated layer 2 buffers are located in the COBA (for BTSplus) or the CCTRL (for BTSone). Buffer congestion can occur due to an excessive signalling traffic volume or/and frequent retransmissions on the

LAPD links (e.g. by bad transmission quality of the PCM lines or microwave links).When the BTSE has detected an overload situation on the LAPD link based on the LAPD load thresholdSLAPDOVLTH (see command CREATE BTSM), it sends the O&M message LAPD OVERLOAD towards theBSC (only valid for BTSEs of generation BTSplus). If the parameter DLAPDOVL (see command SET BSC[BASICS]) is set to TRUE, this message is the trigger for the BSC to start traffic reduction measures asdescribed in below. These reactions are independent of the state of the BTSOVLH flag!

Category D: /* RACH overload */

5) The BTS has detected an overload in on the RACH.

Background: A Random Access Channel (RACH) is used by the MSs to request a dedicated channeltowards the network by sending a CHANNEL REQUEST message via the RACH. RACH Overload isdetected when the percentage of busy RACHs exceeds a threshold (for further details please see parameter TCCCHLDI in CREATE BTS [BASICS]). The BTS sends a CCCH LOAD INDICATION message to the BSC(see parameter PCCCHLDI in CREATE BTS [BASICS]). No special overload defence actions are applied by

BTS or BSC.





2.10.3.2 Traffic reduction mechanisms in case of BTS overload

BTS overload regulation works in a similar way like BSC overload regulation:depending on the type of overload situation, terminating traffic is reduced by discarding PAGING messages,originating traffic is reduced by the discarding of CHANNEL REQUIRED messages.

The main difference between BSC overload handling and BTS overload handling are:

• While in case of BSC overload the load reduction mechanisms are executed for the whole BSC, in caseof BTS overload they are, of course, restricted to the affected BTSs only.

• The discarding of PAGING messages and the discarding of CHANNEL REQUIRED message is handledseparately by two different variables- ovld_level_uplink for the discarding of CHANNEL REQUIREDs and- ovld_level_downlink for the discarding of PAGING messages.

• PCH overload, i.e. the receipt of an OVERLOAD message (BTS->BSC), only incrementsovld_level_downlink

• AGCH overload, i.e. the receipt of a DELETE INDICATION message (BTS->BSC), does not lead to anyoverload defense action by the BSC anymore (change in BR8.0).This means, that, when the a DELETE INDICATION is received, there is no reaction from the BSC at all.Instead, the discarding of IMMEDIATE ASSIGNMENT or/andIMMEDIATE ASSIGNMENT REJECTmessages is entirely left to the BTS.





2.10.3.3 System reactions and overload regulation measures in case of BTSoverload

BTS overload regulation is only started, if the database flag BTSOVLH (see command SET BSC [BASICS])is set to TRUE.The overload regulation measures depend on the type of overload condition which was detected by theBSC.

As listed above, the following BSC overload conditions exist:

(1) PCH overload (Abis message OVERLOAD ‘CCCH overload’ received)(2) AGCH overload (Abis message DELETE INDICATION received)(3) RACH overload (BTS sends CCCH LOAD INDICATION)

Case A: PCH overload (Abis message OVERLOAD ‘CCCH overload’ received)

When condition (1) is detected (and BTSOVLH=TRUE), the BSC- outputs an alarm message ‘243 - BTS Overload detected’* with overload cause ‘CCCH overload’ towardsthe O&M output media (RC, LMT, event logfile)- sends the BSSMAP message OVERLOAD with cell identity (**see note in section “Further important noteson BSC reactions”) and overload cause ‘CCCH overload’ to the MSC (one message every 2 seconds, seetimer T2 as explained in the sections above)- starts an algorithm for the reduction of terminating traffic which discards PAGING messages for theaffected BTS in correspondence with the current value of ovld_level_downlink. On the first detection of the

PCH overload condition (Abis OVERLOAD message received), the variable ovld_level_downlink starts withthe value ‘0’.

Additional load defense actions in the BTS in case of PCH overload Since BR7.0 there is an additional PCH overload defense mechanism, which is controlled by the parameter PCCCHLDI (see command SET BTS [BASICS]). If PCCCHLDI set to a value different from ‘0’, a BTS pagingoverload situation (i.e. the BTS has sent an OVERLOAD message to the BSC, thus indicating that onePAGING COMMAND could not be placed in a paging queue and had to be discarded), triggers the followingmechanism: as long as the PCH load is still above the threshold defined by the parameter TCCCHLDI (seecommand SET BTS [BASICS]), the BTS discards all PAGING COMMANDs that contain an IMSI. This isdone because an IMSI needs twice the space than a TMSI in the BTS paging queues and is thus an attemptto effectively prevent further overload situations by removing those messages that have the biggest impacton the load in the AGCH queues.

Case B: AGCH overload (Abis message DELETE INDICATION received)

When condition (2) is detected (and BTSOVLH=TRUE), the BSC- outputs an alarm message ‘243 - BTS Overload detected’* with overload cause ‘AGCH overload’ towardsthe O&M output media (RC, LMT, event logfile)- sends the BSSMAP message OVERLOAD with cell identity (**see note in section “Further important noteson BSC reactions”) and overload cause ‘CCCH overload’ to the MSC (one message every 2 seconds, seetimer T2 as explained in the sections above)- does not start any overload defense actions (change implemented in BR8.0). Instead, the discarding of IMMEDIATE ASSIGNMENT or/and IMMEDIATE ASSIGNMENT REJECT messages is entirely left to theBTS.

Case C: RACH overload (BTS sends CCCH LOAD INDICATION)

When condition (3) is detected, no overload regulation measures are applied.

* Within the alarm message the BTS overload cause is indicated as follows

BTS Overload condition Overload cause value in

’BTS overload detected’ alarm

Alarm output only if

BTSOVLH=TRUE ?

(1) PCH overload (OVERLOAD received) 07 (CCCH congestion) yes

(2) AGCH overload (DELETE INDICATIONreceived)

06 (AGCH congestion) yes

(3) Abis LAPD signalling overload 00 no, output in any case

not used 08 (ACCH congestion) --





2.10.4 Interaction of BTS Overload and BSC Overload

If both BSC and BTS overload occur at the same time, the discarding of messages on one BTS (cell) isperformed using the maximum overload level value of the BSC overload level and the ovld_level_uplink (or ovld_level_downlink).

A particular treatment is reserved to Channel required with cause ‘answer to paging’ (see table below) .

If the BSC is discarding PAGING messages coming on the A interface (i.e. BSC overload level !=0 or BTSoverload downlink level != 0 ), then CHANNEL REQUIRED message with cause ‘answer to paging’ are not

discarded.

If no paging discarding is in progress on A interface the channel filter acts on all CHANNEL REQUIREDmessages except the ones related to emergency calls.

Note:

” != “ means “not equal to”

BSC overload level BTS ovld_level_uplink BTS ovld_level_downlink discarded

CHANNEL REQUIREDs

0 0 0 none

0 0 !=0 none

0 !=0 0 all CHAN REQUIREDs discarded

0 !=0 !=0 ‘answer to paging’ not discarded

!=0 0 0 ‘answer to paging’ not discarded

!=0 0 !=0 ‘answer to paging’ not discarded

!=0 !=0 0 ‘answer to paging’ not discarded

!=0 !=0 !=0 ‘answer to paging’ not discarded





2.10.5 Effects on Performance Measurement Counters

As a general rule, the discarding of messages always takes place prior to the triggering of the associatedperformance measurement counters.

If the BSC discards PAGING or CHANNEL REQUIRED messages due to the described overload regulationmeasures, the relevant PM counters will show smaller values in the affected granularity periods.

In detail, the counters are affected as follows:

a) PAGING messages discarded

• The discarded PAGING messages are not counted by TACCBPRO (subcounter 1), i.e. TACCBPRO (1.)will not be triggered.

• The discarded PAGING messages are not transmitted via the Abis as PAGING COMMAND, i.e.NTDMPCH will not be triggered.

b) CHANNEL REQUIRED messages discarded

• The discarded CHANNEL REQUIRED messages are not counted by ATIMASCA. Consequently, also themeasurement SUIMASCA will not be triggered.

• The discarded CHANNEL REQUIRED message will not lead to an IMMEDIATE ASSIGNMENTprocedure, i.e. TACCBPRO (subcounter 2) will not be triggered.





3 Alphabetical Command and Parameter Index

A

ABISCH...... ............ ............. ............ ............. ............ 114 ABISFRACTTHR........ ............ ............. ............. .......... 91 ABISHRACTTHR ........... ............. ............ ............. ...... 92 ABISTRFHITHR ............. ............ ............. ............. ...... 94

ABISTRFLTHR......... ............. ............ ............. ............ 95 ABUTYP....... ............ ............. ............ ............. .......... 237 ACBQPFF ............ ............. ............ ............ ............. .. 178 ACBQPMAX....... ............. ............ ............ ............. .... 178 ACCEPTGDEGR ........... ............. ............ ............. ...... 19 ACEFLFF ........... ............. ............ ............. ............ .... 178 ACFERMAX ............. ............. ............ ............. .......... 178 ACHAN............. ............. ............ ............ ............. ...... 377 ACLNKTYP ............ ............. ............ ............. ............ 178 ACMAXEFLDMA..... ............ ............ .............. ........... 179 ACMINEFLDMA ............. ............. ............ ............. .... 179 ACPER....... ............ ............. ............ ............. ............ 179 ADVCMPHOOAMR.......... ............ ............. ............. .. 284 AECST ........... ............ ............. ............ ............. .......... 77 AISAT....... ............ ............. ............ ............ ............. .... 20 ALACOUNT............ ........... .............. ............ ............. .. 56 ALARMT1............. ............. ............ ............. ............ .... 56 ALARMT2............. ............. ............ ............. ............ .... 56 ALARMT3............. ............. ............ ............. ............ .... 56 ALCST ............. ............ ............. ............ ............. ........ 77 ALCTGTLEV ............ ............ ............. ............ ............. 77 ALEVFULHO...... ............ ............. ............ ............. .... 284 ALLCRIT ............. ............. ............. ............ ............. .... 75 ALPHA ........... ............ ............. ............ ............. ........ 237 ALRMSEVBTS............ ............ ............. ............. ......... 50 ALRMSEVBTSM.............. ........... ............. ............ ...... 50 ALRMSEVCBCL ............. ............ ............. ............ ...... 50 ALRMSEVCPEX ............ ............. ............. ............ ...... 53 ALRMSEVDISK............ ............. ............ .............. ....... 53 ALRMSEVDK40........... ............. ............ .............. ....... 53 ALRMSEVEPWR ............. ........... ............. ............ ...... 53

ALRMSEVFRL ............. ............. ............ ............. ........ 50 ALRMSEVIPLI............ ............. ............ .............. ......... 50 ALRMSEVIXLT ............ ............. ............ .............. ....... 53 ALRMSEVLICD.... ............. ............ ............. ............ .... 53 ALRMSEVLICDS ............. ............. ............ ............. .... 53 ALRMSEVLPDLM............. ............ ............. ............ .... 51 ALRMSEVLPDLMTD ............ ............ .............. ........... 51 ALRMSEVLPDLR ............ ............ ............. ............ ..... 51 ALRMSEVLPDLRTD........... ............ ............. ............ .. 51 ALRMSEVLPDLS.............. ............ ............. ............ .... 51 ALRMSEVME2M............. ............ ............. ............ ...... 53 ALRMSEVMEMT ........... ............. ............ ............. ...... 54 ALRMSEVMPCC ........... ............. ............ ............. ...... 54 ALRMSEVNSVC............. ............ ............. ............ ...... 51 ALRMSEVNTW.... ............ ............. ............. ............ .... 54 ALRMSEVOMAL...... ............. ............ ............. ............ 51

ALRMSEVPCMA.............. ........... ............. ............ ...... 51 ALRMSEVPCMB.............. ........... ............. ............ ...... 51 ALRMSEVPCMG ............ ............ ............. ............ ...... 51 ALRMSEVPCMS.............. ........... ............. ............ ...... 51 ALRMSEVPCU ............. ............ ............. ............. ....... 51 ALRMSEVPCUTD............ ........... ............. ............ ...... 52 ALRMSEVPPXL........ ............ ............. ............. ........... 54 ALRMSEVPPXP ............ ........... ............. ............ ........ 54 ALRMSEVPPXT............... ............ ............. ........... ...... 54 ALRMSEVPPXU............ ........... ............. ............ ........ 54 ALRMSEVPTPPKF........... ............ .............. ........... .... 52 ALRMSEVPWRD............. ............ ............. ............ ..... 54 ALRMSEVSYNC............ ........... .............. ........... ........ 54

ALRMSEVSYNE ........... .............. ............ ............ ....... 54 ALRMSEVTDCU ........... ............. ............. ............ ....... 52 ALRMSEVTDPC ............ ............. ............ ............ ....... 54 ALRMSEVTRAU ............ ............. ............ ............ ....... 52 ALRMSEVTRX............. ............ ............. ............ ......... 52 ALRMSEVTRXTD ........... .............. ............ ............ ..... 52

ALRMSEVX25A...................... ............. ............ ........... 54 ALRMSEVX25D........... ............. ............ ............ ......... 55 ALTH ............ ............. ............ ............. ............. ......... 404 AMONTH..... ............. ............ ............. ............ ............ . 20 AMRACMRDL ............ ............ ............. .............. ....... 285 AMRFRC1 (BTS).......... ........... ............. ............. ....... 121 AMRFRC2 (BTS)......... ............ ............ ............. ........ 125 AMRFRC3 (BTS).......... ........... ............. ............. ....... 125 AMRFRC4 (BTS).......... ........... ............. ............. ....... 125 AMRFRIC (BTS)....... ............. ............ ............. .......... 126 AMRFRLLCOM ............. ............ ............. ............ ...... 218 AMRFRLLPRM.......... ............ ............. ............ .......... 219 AMRFRTH12 (BTS) ............ ............ ............. ............ 126 AMRFRTH23 (BTS) ............ ............ ............. ............ 127 AMRFRTH34 (BTS) ............ ............ ............. ............ 127 AMRHRC1 (BTS) ........... ............. ............. ............ .... 128

AMRHRC2 (BTS) ........... ............. ............. ............ .... 128 AMRHRC3 (BTS) ........... ............. ............. ............ .... 128 AMRHRC4 (BTS) ........... ............. ............. ............ .... 129 AMRHRIC (BTS) ............. ............ .............. ............ ... 129 AMRHRLLCOM.............. ............ ............. ............ ..... 219 AMRHRLLPRM ............. ............ ............. ............ ...... 219 AMRHRTH12 (BTS) ............ ............ .............. ........... 129 AMRHRTH23 (BTS) ............ ............ .............. ........... 130 AMRHRTH34 (BTS) ............ ............ .............. ........... 130 AMRLKAT ............ ............. ............ .............. ............ . 131 ANTHOPMOD.............. ............ ............. ............ ....... 131 ANTHOPP............. ............ .............. ............ ............. 131 APLESSNBSC ........... ............. ............ ............ ......... 362 APLESSNSMLC....... ............. ............ ............. .......... 362 ASCILLPRM............ ............ ............. ............. ........... 219

ASCIONECHMDL................ ............. ............. ............ . 21 ASCISER............. ............ ............. ............. ........... .... 336 ASCIULR.... .............. ........... ............. ............. ........... 337 ASEV........ .............. ........... .............. ............ ............ . 400 ASMONTH ............ ............ ............. ............. ........... .... 21 ASSFAIR............ ........... ............. ............. ............ ..... 386 ASSLAPD......... ............ ............ ............. ............ ....... 120 ASTRING ........... ............. ............ ............. ............ .... 400 ASUBCH .............. ........... .............. ............ ............. .... 79 ASUBENCAP ........... ............. ............ ............. ............ 21 ASUBISAT.............. ............ ............. ............ ............. .. 22 ATIME1 ............. ............. ............. ............ ............. .... 405 ATT1 ............. ............. ............ ............. ............ ........... 49 ATT2..ATT8... ............. ............ ............. ............ ........... 49 AUTOREP............ ............. ............ ............. ............ .. 404

B

BAF (PCMA)............................................................... 80BAF (PCMB)............................................................... 69BAF (PCMG)..............................................................87BAF (PCMS)............................................................... 73BAND ....................................................................... 405BANDOFHYS........................................................... 404BARINSYSINFO10...................................................344BAUDRATE.............................................................. 375BCCHFREQ (BTS [BASICS]).... ............. ............ ...... 131BCCHFREQ (TGTBTS)............................................340BCGRTODIFFSERV .................................................. 64BCGRWEI ................................................................ 237





BEPAVGP................................................................ 237BEPFIDLWEI ........................................................... 237BEPFITODIFFSERV.................................................. 64BER (PCMA) .............................................................. 80BER (PCMB) .............................................................. 70BER (PCMG).............................................................. 87BER (PCMS) .............................................................. 73BHOFOT .................................................................. 344BLERAVEDL............................................................ 238

BLERAVEUL............................................................ 238BMONTH.................................................................. 198BPAGCHR ............................................................... 238BPRACHR................................................................ 239BRIDGE BSC............................................................. 49BSCDVMA ............................................................... 239BSCOVLH.................................................................. 22BSCT1 ....................................................................... 12BSCT10...................................................................... 12BSCT11...................................................................... 13BSCT11PUB.............................................................. 13BSCT11WPS ............................................................. 13BSCT13...................................................................... 14BSCT17...................................................................... 14BSCT18...................................................................... 14BSCT19...................................................................... 14

BSCT20...................................................................... 15BSCT3 ....................................................................... 15BSCT3121.................................................................. 15BSCT4 ....................................................................... 16BSCT7 ....................................................................... 16BSCT8 ....................................................................... 17BSCTQHO ................................................................. 18BSCTQHOPUB.......................................................... 18BSCTQHOWPS......................................................... 18BSIC (BTS [BASICS]) .............................................. 132BSIC (TGTBTS) ....................................................... 340BSMONTH ............................................................... 198BSPBBLK................................................................. 239BSSAPSSN.............................................................. 362BTSHSCSD.............................................................. 338

BTSOVLH .................................................................. 23BULKDCONF............................................................. 77BURNOFFS ............................................................. 132BVCBHIPER ............................................................ 240BVCBLPER.............................................................. 240BVCBMAPER........................................................... 240BVCBSPPER........................................................... 240

C

C31H........................................................................ 240C32QUAL................................................................. 240CACKTYP ................................................................ 241CALLF01.................................................................. 132CALLF02..CALLF63................................................. 132CBCPH....................................................................... 23CBQ ......................................................................... 133

CCALLF01 ............................................................... 111CCALLF02..CCALLF63............................................ 111CCDIST.................................................................... 286CCELL1.................................................................... 286CCELL2.................................................................... 286CCHANTFACT........................................................... 23CELLBARR.............................................................. 198CELLGLID (BTS [BASICS]) ..................................... 133CELLGLID (TGTBTS) .............................................. 341CELLGLID (TGTFDD).............................................. 356CELLRESH.............................................................. 134CELLTYPE............................................................... 135CFS.............................................................................. 9

CHPOOLTYP........................................................... 280CHTYPE........................................... 273, 274, 276, 280CICFM........................................................................23CID........................................................................... 394CITASUP.................................................................... 23CLOCK.....................................................................375CLSETFAIR..............................................................386CMOBALLOC...........................................................113CODE (PCMA) ........................................................... 80

CODE (PCMB) ........................................................... 71CODE (PCMG)...........................................................87CODE (PCMS) ........................................................... 73CONCELL ................................................................138CONGTH.................................................................. 367CPCUN............................................................... 64, 241CRC (PCMA)..............................................................80CRC (PCMB)..............................................................70CRC (PCMG) ............................................................. 87CRC (PCMS)..............................................................73CREALL ...................................................................199CREATE ADJC ........................................................344CREATE ADJC3G.................................................... 357CREATE BTS [BASICS]........................................... 121CREATE BTSM..........................................................91CREATE CBCL ........................................................380

CREATE CBTS ........................................................111CREATE CFHSY...................................................... 112CREATE CHAN (BCCH) ..........................................273CREATE CHAN (SDCCH).......... ............. ............. .... 274CREATE CHAN (TCH).............................................276CREATE CHAN (TCH/SD)....................................... 280CREATE CPCU.......................................................... 57CREATE CTRSCHED.............................................. 393CREATE ENVA........................................................ 400CREATE EPWR......................................................... 55CREATE FHSY ........................................................265CREATE FRL............................................................. 89CREATE HDCTR .....................................................399CREATE IPLI ........................................................... 379CREATE LICD............................................................56

CREATE LICDS .........................................................56CREATE LPDLM......................................................114CREATE LPDLS ........................................................ 79CREATE NSVC..........................................................90CREATE NUC.......................................................... 374CREATE OMAL........................................................ 380CREATE OPC [BASICS]..........................................362CREATE PCMA .........................................................80CREATE PCMB .........................................................69CREATE PCMG......................................................... 87CREATE PCMS .........................................................73CREATE PCU ............................................................ 64CREATE PTPPKF....................................................237CREATE QSMONBSC............................................. 385CREATE QSMONBTS .............................................386CREATE QSMONGPRS..........................................390

CREATE QSTHRS................................................... 383CREATE RFLOOP...................................................404CREATE SCA ..........................................................405CREATE SS7L......................................................... 373CREATE SUBTSLB ................................................. 120CREATE SYNC........................................................380CREATE SYNE........................................................ 381CREATE TGTBTS.................................................... 340CREATE TGTFDD................................................... 356CREATE TGTPTPPKF............................................. 342CREATE TRACE...................................................... 392CREATE TRAU.......................................................... 75CREATE TRX........................................................... 267





CREATE X25A......................................................... 377CREATE X25D......................................................... 375CRESELTHRINP ..................................................... 241CRESELTRHSOUT ................................................. 241CRESOFF................................................................ 139CRESPARI............................................................... 140CRTSWDLLCOM..................................................... 220CRTSWDLLPRM ..................................................... 220CRTSWSPELLCOM ................................................ 220

CRTSWSPELLPRM................................................. 220CSCE....................................................................... 141CSCH3CSCH4SUP (BSC)......................................... 24CSCH3CSCH4SUP (PTPPKF) ................................ 241CUCONF.................................................................. 141

D

DEFPOOLTYP........................................................... 80DGRSTRGY............................................................. 141DGRSTRGYBCNT..................................................... 25DIFFSERVSUP.......................................................... 65DIRTCHASS ............................................................ 199DISTHO ................................................................... 287DLAPDOVL................................................................ 25DNLBSSPFCRET ...................................................... 57DNLBSSPFCT ........................................................... 57DPBGTHO ............................................................... 287DRXTMA.................................................................. 242DTEDCE .................................................................. 375DTXDLFR................................................................. 201DTXDLHR ................................................................ 203DTXUL ..................................................................... 203

E

EAC.......................................................................... 179EADVCMPDCMHO.................................................. 288EADVCMPHOAMR.................................................. 295EADVCMPHOSC..................................................... 295EANTHOP................................................................ 143EARCLM .................................................................. 204EAUTOREC ............................................................... 53

EBCCHTRX ............................................................. 271EBSPWCR............................................................... 223EBSPWRC............................................................... 224EBUSYCUM............................................................. 405EC............................................................................ 205EDASUP .................................................................. 242EDTMSUP................................................................ 242EDTMSUP................................................................ 342EEDGE..................................................................... 272EEICM...................................................................... 405EENHDTMSUP.......................................................... 25EEOTD..................................................................... 144EEXCDIST ............................................................... 338EFCRESEL .............................................................. 144EFRSUPP .................................................................. 26EFULHO................................................................... 295

EGPLGPEIGHTTS................................................... 242EGPLGPFIVETS...................................................... 242EGPLGPFOURTS.................................................... 242EGPLGPONETS...................................................... 242EGPLGPSEVENTS.................................................. 243EGPLGPSIXTS........................................................ 243EGPLGPTHREETS.................................................. 243EGPLGPTWOTS ..................................................... 243EGPRS..................................................................... 272EGWSEIGHTTS....................................................... 243EGWSFIVETS.......................................................... 243EGWSFOURTS ....................................................... 243EGWSONETS.......................................................... 244

EGWSSEVENTS......................................................244EGWSSIXTS............................................................ 244EGWSTHREETS...................................................... 244EGWSTWOTS .........................................................244EHDCTR ..................................................................144EHRACT...................................................................145EHRACTAMR........................................................... 147EICNF1.....................................................................405EINTSITSYN.............................................................. 96

EISDCCHHO..............................................................26ELEVHOM................................................................ 296ELIMITCH.................................................................296ELKADPT.................................................................244ELLCOM...................................................................221ELLPRM...................................................................221EMANPRESCOM.....................................................245EMANPRESPRM ..................................................... 245EMCSFAMA1DL ......................................................245EMCSFAMAP1DL.................................................... 245EMCSFAMB1DL ......................................................245EMCSFAMCDL ........................................................245EMCSFAMGDL........................................................ 245EMFA1UNIR8PSK................... ............ ............ ......... 245EMFAP1UNIR8PSK ................................................. 246EMFB1UNIR8PSK................... ............ ............ ......... 246

EMFCUNIR8PSK .....................................................246EMFCUNIRGMSK.................................................... 246EMFGUNIR8PSK..................................................... 246EMFGUNIRGMSK.................................................... 246EMSPWRC...............................................................225EMT1..........................................................................99EMT2........................................................................ 100ENANCD ..................................................................189ENAQUALEVHOM ................................................... 298ENCALSUP................................................................26ENDMA (BTS).......................................................... 338ENDMA (CBTS) .......................................................111ENDML..................................................................... 405ENFOIAHO.................................................................27ENFORCHO...............................................................27

ENHSCSD.................................................................. 29ENPERNOTDE ........................................................ 147ENVANAME ............................................................. 400EPA............................................................................30EPAT1......................................................................148EPAT2......................................................................148EPOOL....................................................................... 31EPRE........................................................................ 206EPREHSCSD.............................................................31EPWCRLFW ............................................................ 225EQ............................................................................207EQPOS....................................................................... 52ERRACT.....................................................................31ERRCORMTD.......................................................... 368ERUDGR.................................................................. 334ESUP.......................................................................... 31

ETFO..........................................................................77ETIME ..........................................................................9ETXDIVTS................................................................ 149EUBCHO..................................................................299EUHO.......................................................................299EUIMPHO.................................................................300EUMSSNCRESEL....................................................246EUSCHO..................................................................301EUSCNCRESEL................... ............. ............ ............. 32EUSDCHO .................................................................32EXCDIST.................................................................. 338EXPSWV (BTSM)..................................................... 100EXPSWV (TRAU).......................................................78





EXTCHO.................................................................. 301EXTMODE ........................................273, 275, 276, 281

F

FACCHQ.................................................................. 149FCRATE..................................................................... 57FDDARFCN ............................................................. 356FDDDIV.................................................................... 356FDDGQO ................................................................. 246

FDDMURREP .......................................................... 149FDDQMI................................................................... 149FDDQMIO................................................................ 149FDDQO.................................................................... 149FDDREPO................................................................ 149FDDREPQTY........................................................... 150FDDREPTH.............................................................. 151FDDREPTH2............................................................ 151FDDRSCPMI............................................................ 151FDDSCRMC............................................................. 356FHAMRFRC1........................................................... 151FHAMRFRC2........................................................... 151FHAMRFRC3........................................................... 151FHAMRFRC4........................................................... 152FHAMRFRIC............................................................ 152FHAMRFRTH12....................................................... 152FHAMRFRTH23....................................................... 152FHAMRFRTH34....................................................... 153FHAMRHRC1........................................................... 153FHAMRHRC2........................................................... 153FHAMRHRC3........................................................... 153FHAMRHRC4........................................................... 153FHAMRHRIC............................................................ 154FHAMRHRTH12 ...................................................... 154FHAMRHRTH23 ...................................................... 154FHAMRHRTH34 ...................................................... 154FHORLMO ............................................................... 345FHSYID.................................................................... 282FHSYID (CHAN) .......................................274, 275, 277FHSYID (TRX) ......................................................... 267FLAPDOVLTH.......................................................... 100

FLOWCTH............................................................... 368FPER ....................................................................... 246FRACTAMRTH1 ...................................................... 155FRACTAMRTH2 ...................................................... 156FRACTTH1.............................................................. 156FRACTTH2.............................................................. 157FRANOFFS.............................................................. 157FRSTD....................................................................... 89FRTERM.................................................................. 374FULHOC.................................................................. 345FULRXLVMOFF....................................................... 346

G

GAM......................................................................... 247GASTRABISTH........................................................ 101GASTRTH................................................................ 247

GATEWAY0............................................................. 379GATEWAY1............................................................. 379GBSNS....................................................................... 65GCELLRESH ........................................................... 247GDCH (TCH)............................................................ 277GDCH (TCHSD)....................................................... 282GEXTS..................................................................... 157GFDDMURREP ....................................................... 248GFDDQMI ................................................................ 248GFDDQMIO ............................................................. 248GFDDREPQTY ........................................................ 248GFDDRSCPMI......................................................... 248GHCSPC (ADJC)..................................................... 346

GHCSPC (PTPPKF)................................................. 248GHCSTH (ADJC) .....................................................346GHCSTH (PTPPKF).................................................248GLK............................................................................89GLLCOM ..................................................................221GLLPRM...................................................................221GMANMSAL............................................................. 248GMANPRESCOM ....................................................249GMANPRESPRM.....................................................249

GMANRETS............................................................. 249GMICROCU ............................................................. 357GMSTXPMAC (PTPPKF).........................................249GMSTXPMAC (TGTPTPPKF).................................. 343GNMULBAC............................................................. 249GPATH.....................................................................250GPDPDTCHA...........................................................250GPENTIME (ADJC).................................................. 346GRESOFF (ADJC) ................................................... 346GRXLAMI (PTPPKF)................................................ 251GRXLAMI (TGTPTPPKF).........................................343GS............................................................................252GSUP....................................................................... 347GTDDMURREP........................................................ 252GTEMPOFF (ADJC).................................................347GTS............................................................................ 89

GTXINT.................................................................... 252GUARMABIS............................................................ 157GUMTSSRHPRI.......................................................252

H

HANDROR ...............................................................387HANFAIR..................................................................387HCICN........................................................................85HDCFS.......................................................................10HDCFUPE..................................................................10HIERC...................................................................... 302HIERF.......................................................................302HOAVDIST...............................................................302HOAVLEV ................................................................303HOAVPWRB ............................................................ 304

HOAVQUAL ............................................................. 305HOCCDIST...............................................................306HOLTHLVDL ............................................................ 306HOLTHLVUL ............................................................ 306HOLTHQAMRDL......................................................307HOLTHQAMRUL......................................................308HOLTHQUDL ........................................................... 308HOLTHQUUL ........................................................... 309HOM (ADJC) ............................................................ 348HOM (ADJC3G) .......................................................357HOMDOFF (ADJC) .................................................. 348HOMDOFF (ADJC3G)..............................................357HOMDTIME (ADJC).................................................348HOMDTIME (ADJC3G) ............................................358HOMRGTA............................................................... 309HOMSOFF (ADJC)................................................... 349

HOMSOFF (ADJC3G).............................................. 358HOMSTAM............................................................... 309HOPMODE............................................................... 210HOPP....................................................................... 339HORXLVDLI.............................................................309HORXLVDLO........................................................... 310HOSYNC....................................................................33HOTDLINT ............................................................... 311HOTHAMRCDL........................................................ 312HOTHAMRCUL........................................................ 313HOTHAMRDDL........................................................ 313HOTHAMRDUL........................................................ 314HOTHCMPLVDL ......................................................314





HOTHCMPLVUL...................................................... 314HOTHDCMLVDL...................................................... 315HOTHDCMLVUL...................................................... 315HOTHEFRCDL......................................................... 315HOTHFRCDL........................................................... 316HOTHFRCUL........................................................... 316HOTHHRDDL........................................................... 316HOTHHRDUL........................................................... 317HOTMSRM............................................................... 317

HOTMSRME ............................................................ 317HOTULINT ............................................................... 317HRACTAMRT1......................................................... 158HRACTAMRT2......................................................... 159HRACTT1................................................................. 160HRACTT2................................................................. 161HRDCMLIMTH......................................................... 318HRSPEECH............................................................... 33HSCSDLLCOM ........................................................ 222HSCSDLLPRM......................................................... 222HSN ......................................................................... 265HSN (CFHSY) .......................................................... 113

I

IERCHOSDCCH ...................................................... 318IMCSULNIR8PSK .................................................... 253IMCSULNIRGMSK................................................... 253IMMASSFAIR........................................................... 388IMSIATDT ................................................................ 211IMSIFSIZ.................................................................... 10INIBLER ................................................................... 253INICSCH .................................................................. 253INIMCSDL................................................................ 253ININHO..................................................................... 319INTAVEPR............................................................... 187INTCLASS................................................................ 187INTCTMST................................................................. 78INTERCH................................................................. 320INTINF ..................................................................... 400INTRACH................................................................. 320INTRTRFH1TODIFFSERV ........................................ 65

INTRTRFH1WEI ...................................................... 253INTRTRFH2TODIFFSERV ........................................ 65INTRTRFH2WEI ...................................................... 253INTRTRFH3TODIFFSERV ........................................ 65INTRTRFH3WEI ...................................................... 253IRACHOSDCCH ...................................................... 321

L

L1CTS........................................................................ 70L2WIN.............................................................. 375, 377L3PS ................................................................ 375, 377L3WIN.............................................................. 375, 377LAPDOVLT .............................................................. 102LAPDPOOL (LPDLM)............................................... 115LAPDPOOL (LPDLS) ................................................. 80LAYERID.................................................................. 267

LCBM0..................................................................... 162LCBM1..................................................................... 162LCBM2..................................................................... 162LCBM3..................................................................... 162LCN2WC.......................................................... 375, 377LCSMONTH............................................................... 34LCSNSSC .................................................................. 34LEVHOM.................................................................. 349LEVONC .................................................................. 349LINKTYPE (CBCL)................................................... 380LINKTYPE (OMAL) .................................................. 380LKSET...................................................................... 373LNKA........................................................................ 373

LOTERCH ................................................................321LOTRACH ................................................................ 321LOWBER (PCMA) ......................................................85LOWBER (PCMB) ......................................................71LOWBER (PCMG)...................................................... 87LOWBER (PCMS) ......................................................73LOWTLEVD..............................................................225LOWTLEVU..............................................................225LOWTQUAD............................................................. 226

LOWTQUAMRDL..................................................... 226LOWTQUAMRUL..................................................... 227LOWTQUAU.............................................................227LPDLMN................................................................... 267LPDLMSAT .............................................................. 102LREDUNEQ (PCMB)..................................................71LREDUNEQ (PCMS)..................................................73LWWPSPRI.............................................................. 211

M

M2T1........................................................................ 368M2T2........................................................................ 369M2T3........................................................................ 369M2T4E...................................................................... 369M2T4N......................................................................369M2T5........................................................................ 369M2T6........................................................................ 369M2T7........................................................................ 369M3T1........................................................................ 370M3T10...................................................................... 370M3T12...................................................................... 371M3T13...................................................................... 371M3T14...................................................................... 371M3T17...................................................................... 371M3T19...................................................................... 371M3T1TM...................................................................371M3T2........................................................................ 371M3T22OR20............................................................. 372M3T22OR21............................................................. 372M3T2TM...................................................................372M3T3........................................................................ 372

M3T4........................................................................ 372M3T5........................................................................ 372MACONN .................................................................394MADGRLV..................................................................34MAFAILNCU............................................................. 254MAFIRACHO..............................................................34MAIO........................................................................ 282MAIO (CHAN)........................................... 274, 275, 278MAIO (TRX).............................................................. 268MAIRACHO.............................................................. 321MASCLOGFS............................................................. 11MAXFAILHO.............................................................322MAXLAPDMN.............................................................34MAXNCELL................................................................34MAXRETR................................................................ 180MEAEXTBCCH ........................................................162

MEASET...................................................................399MECNT.....................................................................404MEDAFUPE ...............................................................11MEDAFUST................................................................11MELID ..........................................................................9MICROCELL (ADJC)................................................349MICROCELL (ADJC3G)........................................... 358MINCCNT.................................................................404MISTSTRSH...............................................................34MNTBMASK...............................................................35MOBALLOC ............................................................. 265MODBSSPFCRET .....................................................57MODBSSPFCT .......................................................... 57





MOEC ...................................................................... 268MSBHIPER .............................................................. 254MSBLPER................................................................ 254MSBMAPER............................................................. 254MSBSPPER............................................................. 254MSCOVLH ................................................................. 37MSCPERTFLAG...................................................... 362MSCPOOL ................................................................. 37MSCSPC.................................................................. 362

MSCV......................................................................... 38MSRMAXU............................................................... 254MSTXPMAXCH........................................................ 181MSTXPMAXCL ........................................................ 350MSTXPMAXDCS (BTS [BASICS]) ........................... 162MSTXPMAXDCS (TGTBTS).................................... 341MSTXPMAXGSM (BTS [BASICS]) .......................... 163MSTXPMAXGSM (TGTBTS) ................................... 341MSTXPMAXPCS (BTS [BASICS]) ........................... 163MSTXPMAXPCS (TGTBTS) .................................... 341MSTXPMAXUMTS (TGTFDD)................................. 356MTU ........................................................................... 65

N

N1 369N2 370N2WC............................................................... 375, 377N3101......................................................................... 57N3103......................................................................... 58N3105......................................................................... 58N391........................................................................... 89N392........................................................................... 89N393........................................................................... 90NACCNTWCOR......................................................... 38NALLWACC............................................................. 211NAVGI...................................................................... 254NBLKACGR ............................................................. 181NBVCBR .................................................................... 58NBVCRR.................................................................... 58NBVCUR.................................................................... 58NCC1TH................................................................... 254

NCC1THADJC ......................................................... 350NCDP1..................................................................... 190NCDP2..................................................................... 190NCELL...................................................................... 323NCGPENTIME ......................................................... 350NCGRESOFF........................................................... 350NCGTEMPOFF........................................................ 350NCRARESH............................................................. 255NCRESELFLAG......................................................... 38NCSARA .................................................................. 255NCTRFPSCTH......................................................... 255NECI .......................................................................... 39NETWTYPE ............................................................... 40NFRAMEPG............................................................. 183NMDLATT1 .............................................................. 406NMO........................................................................... 66

NMULBAC................................................................ 165NNSVCTSTR............................................................. 66NNSVCUBLR............................................................. 67NOBAKHO ............................................................... 323NOCHBLKN ............................................................. 184NOCHFBLK.............................................................. 183NOFREPHO............................................................. 323NOIREDA................................................................... 78NOIREDST................................................................. 78NOTFACCH ............................................................... 40NRACPBLUPDRET ................................................... 58NRLCMAX.................................................................. 59NRPGRANT............................................................. 190

NSEI........................................................................... 67NSLOTST................................................................. 184NSVCI ........................................................................ 90NSVLI ......................................................................... 90NTWCARD.................................................................41NTWCNDRXP.......................................................... 255NTWCONCRESFAIR ............................................... 390NTWCOR.................................................................255NTWCREPPIDL.......................................................256

NTWCREPPTR........................................................ 256NTWIND................................................................... 362NUA (PCMA) .............................................................. 85NUA (PCMB) .............................................................. 71NUA (PCMG).............................................................. 87NUA (PCMS) .............................................................. 73NY1 .......................................................................... 186

O

OMCCPT (OMAL) ....................................................380OMLAPDRT ............................................................. 103OPC.......................................................................... 363OVLENTHR................................................................ 41OVLSTTHR ................................................................41

P

PAGCOORCLB..........................................................41PAGQOVLIND............................................................ 41PAVRLEV................................................................. 228PAVRQUAL.............................................................. 229PBGTHO ..................................................................323PCCCHLDI............................................................... 165PCMBSTXPRL......................................................... 230PCMCON0 ............................................................... 104PCMCON1 ............................................................... 104PCMCON2 ............................................................... 105PCMCON3 ............................................................... 105PCMCON4 ............................................................... 105PCMCON5 ............................................................... 105PCMCON6 ............................................................... 105PCMCON7 ............................................................... 105

PCMECH.................................................................. 256PCML (PCMB)............................................................71PCML (PCMG) ........................................................... 88PCML (PCMS)............................................................73PCMSN ...................................................................... 78PCMSOBJ................................................................380PCMT......................................................................... 85PCMTYPE..................................................................41PCONINT .................................................................230PCRLFTH................................................................. 231PCUID........................................................................ 90PCUPRCSLD........................................................... 385PENTIME .................................................................166PERSTLVPRI1 .........................................................256PERSTLVPRI2 .........................................................256PERSTLVPRI3 .........................................................256

PERSTLVPRI4 .........................................................256PERWEEK(CTRSCHED) .........................................394PERWEEK(HDCTR).................. ............ ............. ...... 399PFCBBHIPER .......................................................... 257PFCBBLPER............................................................257PFCBBMAPER......................................................... 257PFCBBMAPPER ......................................................257PFCBRMAXU...........................................................257PFCBRPER..............................................................257PFCFCSUP................................................................67PFCIBHIPER............................................................ 257PFCIBLPER ............................................................. 257PFCIBMAPER.......................................................... 258





PFCIBMAPPER ....................................................... 258PFCIRMAXU............................................................ 258PFCIRPER............................................................... 258PFCSBHIPER.......................................................... 258PFCSBLPER............................................................ 258PFCSBMAPER ........................................................ 258PFCSBMAPPER...................................................... 259PFCSRMAXU........................................................... 259PFCSRPER.............................................................. 259

PFCSUP..................................................................... 67PKTMEASREPCNT ................................................. 259PKTNDEC................................................................ 259PKTNINC ................................................................. 259PKTNMA.................................................................. 259PL 324PLMNP..................................................................... 166PLNC (ADJC)........................................................... 351PLNC (ADJC3G) ...................................................... 358PNOFACCH............................................................. 166POOLTYP .................................................................. 86PORT0....................................................................... 67PORT1....................................................................... 67PPLNC (ADJC) ........................................................ 351PPLNC (ADJC3G).................................................... 359PREAT....................................................................... 59

PRIMARYIPADDR ................................................... 379PRPBCCH................................................................ 259PWRCONF............................................................... 231PWREDSS............................................................... 231PWRINCSS.............................................................. 231PWROFS................................................................. 186PWROUT................................................................. 212PWRRED ................................................................. 269

Q

QLPUB..................................................................... 212QLWPS.................................................................... 212QSRHC.................................................................... 167QSRHCINI................................................................ 167QSRHI...................................................................... 167

QSRHPRI................................................................. 260QUALLEVHOM........................................................ 351

R

R20 .................................................................. 376, 378R22 .................................................................. 376, 378R23 .................................................................. 376, 378RAARET................................................................... 260RACHBT .................................................................. 167RACHLAS ................................................................ 168RACODE (PTPPKF) ................................................ 260RACODE (TGTPTPPKF) ......................................... 343RACOL (PTPPKF) ................................................... 260RACOL (TGTPTPPKF) ............................................ 343RADIOMG................................................................ 269RADIOMR................................................................ 269

RAENV..................................................................... 260RARESH .................................................................. 260RAVEW.................................................................... 334RDGRUL.......................................................... 334, 335RDLNKTBS.............................................................. 232RDLNKTO................................................................ 169RECCRI ................................................................... 392RELCMD.................................................................... 50RELOBJ ..................................................................... 50REMAL (PCMA) ......................................................... 85REMAL (PCMB) ......................................................... 71REMAL (PCMG)......................................................... 88REMAL (PCMS) ......................................................... 74

REPTYP...................................................................169RETRY............................................................. 376, 378RFRSINDP............................................................... 188RHOLTQDL..............................................................335RHOLTQUL..............................................................335RNCID......................................................................357ROUIPADD0 .............................................................. 42ROUIPADD1 .............................................................. 42RUGRDL .......................................................... 334, 335

RXLEVAMI ............................................................... 169RXLEVHO ................................................................324RXLEVMIN...............................................................352RXLEVMINC ............................................................ 359RXLV........................................................................404RXQUALHO ............................................................. 324

S

SALUNAME (BSCE).............. .............. ........... ............ 52SALUNAME (BTSM) ................................................ 106SALUNAME (TRAU)............ ............ ............. ............ .. 79SANTIME .................................................................370SCHWEIPRI1........................................................... 261SCHWEIPRI2........................................................... 261SCHWEIPRI3........................................................... 261SCHWEIPRI4........................................................... 261SDCCHCONGTH.....................................................170SDCCHDROR.......................................................... 388SDCCHLOSR...........................................................388SECONDARYIPADDR.............................................379SET BSC [ALARMSEV]............... ............ ............. ...... 50SET BSC [BASICS]....................................................19SET BSC [CONTROL] ................................................. 9SET BSC [TIMER]......................................................12SET BSCE [ALARMSEV] ...........................................53SET BSCE [REMINV].................................................52SET BTS [ADM] .......................................................178SET BTS [CCCH].....................................................180SET BTS [INTERF] .................................................. 187SET BTS [OPTIONS] ....................................... 198, 336SET BTS [SERVICE]................................................ 218

SET BTS [TIMER].................................................... 189SET HAND [BASICS] ............................................... 284SET HAND [DATA]...................................................334SET MEL......................................................................9SET OPC [MTL2] .....................................................367SET OPC [MTL3] .....................................................370SET PTPPKF ........................................................... 270SET PWRC .............................................................. 223SET TSLA ..................................................................86SG10HOPAR ........................................................... 324SG10PCPAR............................................................ 232SG11HOPAR ........................................................... 324SG11PCPAR............................................................ 232SG12HOPAR ........................................................... 324SG12PCPAR............................................................ 232SG13HOPAR ........................................................... 324

SG13PCPAR............................................................ 232SG14HOPAR ........................................................... 324SG14PCPAR............................................................ 232SG1HOPAR ............................................................. 324SG1PCPAR.............................................................. 232SG2HOPAR ............................................................. 324SG2PCPAR.............................................................. 232SG3HOPAR ............................................................. 324SG3PCPAR.............................................................. 232SG4HOPAR ............................................................. 324SG4PCPAR.............................................................. 232SG5HOPAR ............................................................. 324SG5PCPAR.............................................................. 232




SG6HOPAR............................................................. 324SG6PCPAR.............................................................. 232SG7HOPAR............................................................. 324SG7PCPAR.............................................................. 232SG8HOPAR............................................................. 324SG8PCPAR.............................................................. 232SG9HOPAR............................................................. 324SG9PCPAR.............................................................. 232SHLAPDIT................................................................ 106

SIMSCREL99............................................................. 42SISGSNREL99........................................................... 59SLAPDOVLTH ......................................................... 106SLC.......................................................................... 373SLLPRM................................................................... 222SMLCPERTFLAG .................................................... 363SMLCSPC................................................................ 363SMSCBUSE............................................................. 339SMSINFO................................................................. 261SMSPFITODIFFSERV............................................... 67SNSADDRET............................................................. 67SNSCHWEIRET......................................................... 67SNSCONFRET .......................................................... 68SNSDELRET.............................................................. 68SNSSIZERET............................................................. 68SPEED145................................................................. 43

SPENLAW.................................................................. 43SPFITODIFFSERV .................................................... 67SPFIWEI .................................................................. 261SS7MTPTYP............................................................ 363START ............................................................. 404, 406START(CTRSCHED) 394

T3169.........................................................................60T3172.........................................................................60T3191.........................................................................60T3192....................................................................... 262T3193.........................................................................60T3195.........................................................................61T3197.........................................................................44T3212....................................................................... 212T391...........................................................................90

T4 377, 379T4 (CPCU)..................................................................61T5 (CPCU)..................................................................61TAADJ......................................................................171TAVGT.....................................................................262TAVGW.................................................................... 262TBFDROR................................................................ 390TBFLOSR................................................................. 391TBFREAFAIR........................................................... 391TBNCU.....................................................................262TCBCSI...................................................................... 44TCCCHLDI ...............................................................172TCHDROR ............................................................... 389TCHLOSR ................................................................389TCONG ...................................................................... 90TCONN.....................................................................363

TCONOFF..................................................................90TDDGQO..................................................................263TDDMURREP .......................................................... 173TDDQO ....................................................................173TDDREPO................................................................173TDDREPTH 173

BSC Database Parameter Description BR8

Documents

Transcript of BSC Database Parameter Description BR8