BSC_Database_Parameter_Description_BR7(Version_01.03.05).pdf

8/11/2019 BSC_Database_Parameter_Description_BR7(Version_01.03.05).pdf

http://slidepdf.com/reader/full/bscdatabaseparameterdescriptionbr7version010305pdf 1/396

s

Siemens Base Station (SBS)

BSC Database Parameter Description BR7.0

Version 01.03.2005



SBS: BSC Database Parameter Description BR7.0 Version 01.03.05 __________________________________________________________________________________________________________

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

made by:

Eckardt BertermannSIEMENS AG

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

GPRS contributions by:

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

Please consider the remarks on the next page!





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!

• Any comments for corrections or suggestions for improvements are welcome!

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

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

!





Contents:

1 DATABASE BR7.0 .........................................................................................................................................................3

1.1 PRINCIPLE CONFIGURATION DIAGRAMS......................................................................................................................... 31.1.1 Example Configuration of Terrestrial Interfaces.............. ............. ............ ............. ............ .............. ............. .... 31.1.2 BR7.0 Object Tree of BSC database objects.... ............. ............ ............. ............ ............. ............. ............. ...... 3

1.2 BSC D ATABASE COMMANDS AND P ARAMETERS ....................................................................................................3Setting the object entry point and time and date for the BSS:.................... ............. ............ ............. .............. ............ 3

Setting the BSC control values for periodic measurement data file upload:.................... ............ ............ ............... .... 3Setting the timing values for BSSMAP control and BSC overload handling:.......... ............ ............. ............ ............. .. 3Setting the global parameters of the BSC:....... ............. ............ ............. ............ ............. ............ .............. ............. .... 3Setting the alarm priorities of the BSS functional objects: ........... ............. ............. ............ ............. ............... ............ 3Setting the remote Inventory data of the BSC Equipment:............... ............ ............. ............ ............. .............. .......... 3Setting the alarm priorities of the BSCE objects: ........... ............ ............. ............. ........... ............. ............... ............. .. 3Creating the Power Supply: ............ ............ ............. ............. ............ ............. ............ ............. .............. ............. ........ 3Creating the spare PCM interface boards:........ ............ ............. ............ ............. ............ ............. ............. ............. .... 3Creating the PCM interface boards:............ ............ ............ ............. ............ ............. ............ ................ ............. ........ 3Creating the LAPD boards:.............. ............ ............. ............ ............ ............. ............ ............. .............. ............. ........ 3Creating the PCU objects: ......................................................................................................................................... 3Creating the PCM links for the Abis interface: .............. ............ ............. ............ ............. ............ .............. ............. .... 3Creating the PCMS link: ............................................................................................................................................ 3Creating the TRAU: ................................................................................................................................................... 3

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

Creating the LPDLS links:...... ............ ............. ............ ............. ............ .............. ............ ............... ............ ............. .... 3Creating the PCMA link: ............................................................................................................................................ 3Setting the uplink and downlink volumes for specific PCMA timeslots:... ............. ............. ............ .............. ............. .. 3Creating the PCMG link:............................................................................................................................................3Creating the physical link connection on the GPRS Gb interface (Frame Relay Link): ............. ............. ............ ....... 3Creating the end-to-end communication between BSS and SGSN: Network Service Virtual Connection (NSVC): ... 3Creating the BTS Site Manager:.............. ............ ............. ............ ............. ............ ............ ............... ............ ............. 3Creating the LPDLM links: ......................................................................................................................................... 3Creating the terrestrial Abis timelots for flexible Abis allocation:.............. ............. ............ ............. ............. ............. .. 3Creating a cell with definition of global parameters:...... ............. ............ ............. ............ ............. ............. ............. .... 3Setting the cell attributes for the Interference Measurement of idle TCHs: ............. ............ ............. ............. ............. 3Setting the cell specific timer values: ............ ............ ............. ............ ............. ............. ........... ................ ............. ...... 3Setting the cell specific optional features: ............. ............ ............. ............ ............ ............. .............. ............ ............. 3Setting the cell specific attributes for Power Control: ............. ............ ............. ............. ........... .............. ............. ........ 3

Power Control Parameter Relations....... ............ .............. ........... .............. ............ ............. .............. ............. ........ 3Creating the GPRS point to point packet transfer service in a cell:................ ............ ............. .............. ............. ........ 3Creating the LPDLR links: ......................................................................................................................................... 3Creating the TRXs: .................................................................................................................................................... 3Enabling GPRS and EDGE in a cell: ........... ............. ............ ............. ............ ............ ............. .............. ............. ........ 3Creating the Frequency Hopping systems: ........... .............. ............ ............. ............ ............. .............. ............. .......... 3Creating the BCCH for the cell:............ ............. ............ .............. ............ ............. ............ ............... ............ ............. .. 3Creating the SDCCHs for the cell: ............................................................................................................................. 3Creating the TCHs for the cell: ..................................................................................................................................3Creating hybrid TCHs/SDCCHs (TCH/SD) for the cell:....... ............. ............. ............. ............. ............. .............. ........ 3Setting the cell specific parameters and threshold values for voice call Handover: ........... ............. ............ ............. .. 3

Handover Parameter Relations.... ............ ............. ............. ............ ............. ............ ............. .............. ............. ...... 3Setting the cell specific parameters and threshold values for 14,4kbit/s data call up- and downgrading and qualityinter-cell handover: ....................................................................................................................................................3Setting the status of SMS-CB, Frequency Hopping and Call Release due to Excessive Distance: .............. ............. 3Creating the Target Cell Objects:........... ............. ............. ............ ............. ............. ............. .............. ............ ............. 3Creating the Target Point-to-point Packet Flow Objects: ........... ............. ............. ............. ............ ............... ............ .. 3

Creating the Adjacent Cell Objects: ............ ............ ............. ............ .............. ............ ............. .............. ............. ........ 3Creating the Target Cell Objects for handover from GSM to UMTS (FDD): ............ ............. ............ ............. ............ 3Creating the Adjacent Cell Objects for external UMTS FDD or UMTS TDD cells:. ............ ............. ............. .............. 3Creating the CCS7 level 3 addresses of BSC, MSC and SMLC and basic SCCP parameters for the SS7connection: ................................................................................................................................................................3Setting the timer values for CCS7 MTP level 2:..... ............. ............ ............. ............ ............. .............. ............. .......... 3Setting the timer values for CCS7 MTP level 3:..... ............. ........... .............. ............ ............. ............ ............... .......... 3Creating the CCS7 link: ............................................................................................................................................. 3Creating a Nailed-Up Connection through the BSC/TRAU: ............. ............. ............. ........... ............. .............. .......... 3Creating an X25 connection via dedicated link: ............ .............. ............ ............. ............ ............. .............. ............. .. 3Creating an X25 connection via A-interface:....... ............. ............ ............ .............. ........... ............. ............. ............. .. 3Creating the O&M link for the RC connection: ............ ............ ............. ............ ............. ............ .............. ............. ...... 3Creating the link for the external connection to the SMS-CB system:............ ............ ............ ............. ............. .......... 3





Defining the BSC reference synchronization clock origin:............. ............. ............. ............ ............. .............. ............ 3Defining an external synchronization signal:.. ............. .............. ............ ............. ............ ............. .............. ............. .... 3 Activating IMSI tracing in the BSC:............ ............. ............ ............ ............. ............ ............. .............. ............ ........... 3Creating a Cell Traffic Recording (CTR) job: ............ ............. ............ .............. ............ ............. .............. ............. ...... 3Defining the BSC environmental alarms: ........... ............. ............ ............. ............ ............. ............. ............. ............. .. 3Configuring the feature Online RF Loopback:....... ............. ............ ............ ............. ............ ............ ................. .......... 3Creating Smart Carrier Allocation: ............ ............ .............. ............ ............. ............ ............. .............. ............ ........... 3

2 APPENDIX....................................................................................................................................................................... 3

2.1 H ANDOVER THRESHOLDS & ALGORITHMS ..................................................................................................................... 32.1.1 Functional Diagram Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality andpower budget)...... ............ ............. ............ ............ ............. ............ ............. ............. .............. ............. ............ ........... 32.1.2 Rules: Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and powerbudget), Power Control disabled............ ........... .............. ........... ............. ............. ............ ............... ............ ............. .. 3

2.1.2.1 Inter-cell Handover (level) ............ .............. ............ ............ ............. ............ ............. .............. ............. ...... 32.1.2.1.1 Handover Decision / Handover Trigger Conditions ............ ............. ............ ............. ............ ............. 32.1.2.1.2 Target Cell List Generation ..............................................................................................................3

2.1.2.2 Intra-cell handover (quality)......... .............. ............ ............ ............. ............ ............. .............. ............. ...... 32.1.2.3 Inter-cell handover (quality).......... ............. ............ ............. ............ ............. ............ .............. ............. ...... 3

2.1.2.3.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... .............. ........... ............ 32.1.2.3.2 Target Cell List Generation ..............................................................................................................3

2.1.2.4 Inter-cell handover (distance).......... ............ ............. ............ ............ ............. ............ .............. ............. .... 32.1.2.4.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... ............. ............ ............ 32.1.2.4.2 Target Cell List Generation ..............................................................................................................3

2.1.2.5 Inter-cell Handover (power budget).... ............. ............. ............ ............. ............ ............. .............. ............ 32.1.2.5.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... ............. ............ ............ 32.1.2.5.2 Target Cell List Generation ..............................................................................................................32.1.2.5.1 Speed sensitive handover enabled ............. ............ ............. ............ ............ ............. ............... ........ 3

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

2.1.2.7 Fast Uplink Handover................ ............ ............. ............ ............ ............. ............ ................ ............. ........ 32.1.2.7.1 Handover Decision / Handover Trigger Conditions ............ .............. ........... ............. ............ ............ 32.1.2.7.2 Target Cell List Generation ..............................................................................................................3

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

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

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

retry) ..........................................................................................................................................................................32.2.2.1 Ranking method 0............ ............ ............. ............ ............. ............ ............ ............. .............. ............. ...... 32.2.2.2 Ranking method 1............ ............ ............. ............ ............. ............ ............ ............. .............. ............. ...... 3

2.2.3 Target Cell Ranking for Traffic Handover with HCS.... ............. ............ ............. ............ ............. .............. ........ 32.3 POWER CONTROL THRESHOLDS & ALGORITHMS............................................................................................................3

2.3.1 Functional Diagram: Power Control Thresholds - Power Increase / Power Decrease (Classic Power Control)32.3.2 Rules: Power Control Thresholds: Power Increase / Power Decrease ............ ............ ............. ............ ........... 3

2.3.2.1 Power Increase ........................................................................................................................................32.3.2.2 Power Decrease............. ............. ............ ............ ............. ............ ............ ............. ................ ............. ...... 3

2.3.3 Classic and Adaptive Power Control..... ............. ............. ............. ............ ............ ............. .............. ............. .... 32.2.3.1 Introduction ...............................................................................................................................................32.3.3.2 Classic Power Control decision process ............. ............ ............. ............ ............. ............ ............... ........ 32.3.3.3 Adaptive Power Control decision process............ ............ ............. ............. ............ ............. ............. ........ 32.3.3.4 Differences between CLASSIC and ADAPTIVE power control decision ............. ............ ............. ............ 32.3.3.4 Functional sequence of a BS and MS power control procedure............. ............ ............. ............ ............. 3

2.3.3.4.1 BS power control procedure.............. ............ ............. ............ ............. ............ ............. .............. ...... 3

2.3.3.4.2 MS power control procedure ............ ............ ............ ............. ............. ........... ............. ................ ...... 32.3.3.5 Comparison of timing behaviour of different Power Control types - MS Power Control, BS PowerControl, classic and adaptive ................................................................................................................................ 32.3.3.6 Further differences between CLASSIC and ADAPTIVE Power Control ............ ............. ............. ............ . 32.3.3.7 Interaction of Power Control Measurement Preprocessing and Power Control Decision ............ ............ 3

2.4 INTERWORKING OF H ANDOVER AND POWER CONTROL ...................................................................................................32.4.1 Functional Diagram: Inter-cell Handover and Intra-cell Handover, Power Increase and Power Decrease........ 32.4.2 Rules ............................................................................................................................................................... 3

2.5 SERVICE DEPENDENT H ANDOVER AND POWER CONTROL ............................................................................................... 32.5.1 Introduction...................................................................................................................................................... 32.5.2 SGxHOPAR and SGxPCPAR parameter values ............ ............ ............ ............. ............ ............. .............. ...... 3

2.5.2.1 SGxHOPAR parameter values (Handover).... ............. ............ ............ ............. ............ ............. .............. .. 32.5.2.2 SGxPCPAR parameter values (Power Control) ............ ............ ............. ............ ............. ............. ............. 3





2.5.2.3 Effects on Call processing............ ............ .............. ............ ............. ............ ............. .............. ............. ...... 32.6 M APPING OF RXQUAL AND C/I VALUES FOR AMR CALLS .............................................................................................. 32.7 AMR LINK ADAPTATION THRESHOLDS UPLINK...............................................................................................................32.8 COMMON BCCH SOLUTION FOR MIXED FREQUENCY BANDS WITHIN THE COMPLETE AREA................................................... 32.9 BSC, MSC AND BTS OVERLOAD H ANDLING.................................................................................................................3

2.9.1 BSC Overload....... ............. ............ ............ ............. ............ ............. ............ ............ ................. ............ ........... 32.9.1.1 BSC overload conditions..... ............. ............ ............ ............. ............ ............. ............ .............. ............. .... 32.9.1.2 System reactions and overload regulation measures in case of BSC overload .............. .............. ........... 32.9.1.2 System reactions and overload regulation measures in case of BSC overload .............. .............. ........... 3

2.9.1.2.1 Further important notes on BSC reactions ........... ............ ............. ............ ............. ............. ............. 32.9.1.3 Mechanisms for reduction of originating traffic and reduction of terminating traffic ............. ............ ......... 3

2.9.1.3.1 Overload level management................. ............. ............. ............ ............. ............ ............... ............ .. 32.9.1.3.2 Traffic reduction algorithms............ ............. ............ ............. ............. ............ .............. ............. ........ 32.9.1.3.3 Special overload supervision algorithm in case of BSC paging queue overflow...... ............. ............ 3

2.9.2 MSC Overload .................................................................................................................................................32.9.2.1 System reactions and overload regulation measures in case of MSC overload.... ............. ............. .......... 3

2.9.2.1.1 Special overload level escalation algorithm in case of MSC overload...... ............. ............. ............. .. 32.9.3 BTS Overload ..................................................................................................................................................3

2.9.3.1 BTS overload conditions ........... ............. ............ ............. ............ ............ ............. .............. ............. .......... 32.9.3.2 Traffic reduction mechanisms in case of BTS overload ............ ............. ............ ............. ............ ............. 32.9.3.3 System reactions and overload regulation measures in case of BTS overload.... ............. ............ ........... 3

2.9.4 Interaction of BTS Overload and BSC Overload..... ............. ............. ............. ............ ............. ............... .......... 32.9.5 Effects on Performance Measurement Counters ............ ............ ............. ............ ............. ............. .............. .... 3

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





1 Database BR7.0

1.1 Principle Configuration Diagrams

1.1.1 Example Configuration of Terrestrial Interfaces

OMAL CCS7

0-0

0-1

0-2

0-3

MSC

4 x PCM30

31 30 16 2 1 0

SW/FAW

PCMA

TRAU

0

TRAU

0

16 2 1 0

PCMS-0

OMAL

empty

CCS7 SW/FAW

0123

0123

TCH á 16 kbit/s

BSC

DTLP-1port 1

simpl. A

LPDLS-0

1 x PCM30submult.

BSC

DTLP-0

port 0simpl. A

16 2 1 0

PCMB-0

SW/FAW

123

LPDLM-0LPDLR-0-0LPDLR-0-1LPDLR-0-2

LPDLR-0-3

1 x PCM30

submult.

123

0123

123

0123

0123

empty

TRX0-0

TRX0-1

TRX0-2

31 30

31 30BTSM-0

BTS-0TRX-0-0TRX-0-1TRX-0-2TRX-0-3

BTSM-1

BTS-1TRX-1-0TRX-1-1

LPDLM-1LPDLR-1-0LPDLR-1-1

10

............

............

Asub Interface

A Interface

Abis Interface

3

the PCMS is used as LPDLS (TRAU matrix type1).Timeslot is empty because the corresponding timeslot on

empty

(TRAU matrix type1).

0

Fig. 1 Example: Terrestrial Interfaces Configuration

0 .

QTLP-

QTLP-





1.1.2 BR7.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 BR7.0

(compared to BR6.0/BR6.1).

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

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

4) In BR6.0 the ‘packages’ (e.g. PKGBTSB, PKGBSCT etc.) were removed s o

that al l parameters su bord inate to one o bject (e.g. BTS) are included in oneand 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 quick ly.

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

- For a better logical structur e, the parameters are st i l l group ed 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 ofthe addressing of the BSS. It simultaneously represents the objectwith which the network element time and date can be set. >

SET MEL:NAME=MEL:0, Object name .

ETIME=12-00..00..1-1-2002,

object: MEL

format: hour –minute-second-

day-month-year

range: hour 0..23

minute 0..59

second 0..59

day 1..31

month 1..12

year 1992..2099

External t ime , this parameter defines the network element time inthe BSS.

MELID=1;

object: MELrange: 1..47

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

MELID must match to the BSS_RDN in the RC database to ensurethe correct operation of the higher communication layers on the O&Mlink between BSC and RC.This parameter replaces the BSSNAME parameter which was usedin older releases up to BR5.5.

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

SET BSC [CONTROL]:

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

NAME=BSC:0, Object name .

CFS=3,

object: BSC [CONTROL]

unit: 1 Mbyte

range: 1-6

default: 1

CTR file size , this attribute indicates the maximum size of the ‘CellTraffic Recording’ logfile on the BSC disk. The feature ‘Cell TrafficRecording’ or ‘Cell Trace’ (CTR) is a feature used to record cellspecific call events for monitoring purposes in a similar way like IMSItracing (for details please see command CREATE CTRSCHED).The

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

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

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

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





IMSIFSIZ=30,


unit: 1 Mbyte

range: 0..30

default: 30

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

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

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 ofscanners which were created ‘BYFILE’ are written. This file isavailable in the BSC directory MEASURE_DIR. To upload thescanner results to the RC the file SCAN.TMP is closed, renamed toSCAN.LOG and transferred to the directory READY_MEAS. Form

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

MEDAFUPE=UPPE_0H,


range: UPPE_0Hh= no per. upl.

UPPE_1h = Upl. period 1h




UPPE_6h = Upl. period 6hUPPE_8h = Upl. period 8h

UPPE_12h= Upl. period 12h

UPPE_24h= Upl. period 24h

default: UPPE_0h

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

parameter to UPPE_0h disables the periodic upload.

MEDAFUST=0-0;


range: upload start hour 0..23

upload start minute 0..59

default: upload start hour 0

upload start minute 0

Measurement data fi le upload start , defines the start time formeasurement 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 andappear in the DBAEM in the SET BSC command. The logical group“[TIMER]” is normally only used on the LMT but was used here toallow a more useful grouping of the commands .

NAME=BSC:0, Object path name .

BSCT1=HLFSEC-12,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-12

Reference: GSM 08.08

BSC timer T1 , this timer determines the t ime to receive the

BSSMAP message BLOCKING ACKNOWLEDGE . The MSCselects the terrestrial resources (A interface traffic channels) to beused for a call. The MSC therefore needs to be informed about A-interface circuits that are out of service in the BSC or cannot be useddue to configuration of OMAL, LPDLS or SS7L etc.. The BSCinstructs the MSC to block resp. unblock single affected A-timeslotsby using the BSSMAP message BLOCKING/UNBLOCKING. As aresult, the MSC marks the affected timeslots as 'unavailable'. If agroup of A-interface timeslots is to be blocked simultaneously, theCIRCUIT GROUP BLOCKING/UNBLOCKING procedure is used

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

BSCT10=HLFSEC-10,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254default: HLFSEC-10

Reference: GSM 08.08 (04.08)

BSC timer T10 , this timer determines the time to return the

ASSIGNMENT COMPLETE message in case of call setup andintra-cell handover. This timer is started on the sending of an

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

The value must be higher than the maximum transmission time of the ASSIGNMENT COMMAND and the ASSIGNMENT COMPLETEmessage plus the maximum duration of an attempt to establish adata link multiframe mode.Note: Due to the SBS implementation T10 replaces the function ofthe GSM timer T3107, i.e. T3107 is not used by the SBS.Rule: BSCT10 < TTRAU(for TTRAU see command SET BTS [TIMER])This setting is necessary to ensure that a signaling failure (T8 andT10) is detected before transcoder failure (TTRAU)

T10purpose: a) Assignment procedure: release of the associated resources if the

MS is lost during the assignment procedure.b) Intra-cell handover: keep the old channels available for a sufficient timein order to allow the MS to return to the old channel return to it if thehandover is not successful and to release the old channel if the MS islost during the handover procedure.

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

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

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





BSCT11=HLFSEC-16,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-16


BSC timer T11 , this timer determines the maximum al lowed

queu ing t ime . 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 assignment procedure (i.e. when theBSC receives an ASSIGNMENT REQUEST message from the MSC)is put into a queue due to TCH congestion, T11 determines themaximum time the TCH request may remain in the queue to wait fora busy TCH to become idle. If the TCH request for assignment

procedure cannot be served within this time frame and T11 expires,the BSC sends a CLEAR REQUEST to the MSC and the context isreleased.

Notes:- Queuing a TCH request means a considerable extension of the

SDCCH seizure duration!- It is important to consider that the feature 'Queuing' stresses the

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

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

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 allaffected calls and to erase all affected references.Rule: T16 (MSC) > BSCT13 (BSC)The value of the "Wait for Acknowledge timer" T16 in the MSC mustbe higher than the value of T13 plus the transmission time of theRESET and the RESET ACKNOWLEDGE message (it is

recommended to set the MSC-timer T16 to 35s). It is recommendedto set both T13 in the BSC and T2 in the MSC to ca. 10s.

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.





BSCT17=HLFSEC-20,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-20

BSC timer T17 , this timer represents the overload message ignoretimer which is used only in case of MSC overload. BSCT17 is used inclose relation to the timer BSCT18 (see below).

For further details about the exact function of the timer BSCT18within the BSS overload regulation please refer to the section “BSC,

BTS and MSC overload Handl ing” in the appendix of thisdocument. As MSC, BSC and BTS overload handling are closelyinterwoven, the overload conditions and traffic reduction mechanismsare explained in an own chapter that comprises all possible scenariosof overload and overload handling as well as the references to therelevant parameters.

BSCT18=HLFSEC-60,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-60


BSC timer T18 , this timer represents the over load observation

t imer and it is used in all cases of BSS overload regulation:BSC overload regulation, MSC overload regulation and BTS overloadregulation (see parameters BSCOVLH, MSCOVLH and BTSOVLH incommand SET BSC [BASICS]).

For further details about the exact function of the timer BSCT18within the BSS overload regulation please refer to the section “BSC,

BTS and MSC overload 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 tim e to receive RESET

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

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

CIRCUIT PROCEDURE and restarts T19.BSCT20=HLFSEC-12,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-12


BSC timer T20 , this timer determines the time to receive 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 anymore (e.g. due to failure of a TRAU) the BSC instructs the MSC toblock the affected A-interface circuits by using the BSSMAPmessage CIRCUIT GROUP BLOCKING/UNBLOCKING. As a result,the MSC marks all affected timeslots as 'unavailable'. The timer T20supervises the receipt of the BLOCKING/ UNBLOCKING

ACKNOWLEDGE message from the MSC. The value of T20 must behigher than the MSC maximum reaction time and the transmission

time 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,5s

SEC5=5s

range: 0..254

default: HLFSEC-50


BSC timer T3 , this timer determines the frequency of the BSSMAP

mes sage RESOURCE INDICATION sending. The RESOURCEINDICATION message contains information about the number ofavailable TCHs per interference band for a specific cell and is sent byfrom the BSC to the MSC if the BSC has previously received theBSSMAP message RESOURCE REQUEST from the MSC. TheRESOURCE REQUEST message indicates a specific cell identifier

and can trigger the transmission a single RESOURCE INDICATIONas well as the transmission of several RESOURCE INDICATIONs ina periodic manner. For the periodic transmission of RESOURCEINDICATION the timer T3 determines the period between twoconsecutive transmissions of the RESOURCE INDICATION.

BSCT3121=HLFSEC-50,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: 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 BSSMAPHANDOVER REQUIRED with a UMTS 3G neighbour cell (seecommand CREATE ADJC3G) in the target cell list to the 3G MSC.When the target RNC has provided the target channel data and andthe 3G-MSC has sent the associated HANDOVER COMMAND to theBSC, the BSC forwards this HANDOVER COMMAND to the

multiRAT MS and simultaneously starts the timer T3121. The MS, onreceipt of the HO CMD, switches over to the target channel in theUMTS 3G neighbour cell and, in case of successful link setup, sendsthe RRC HANDOVER COMPLETE towards the target RNC which inturn sends an Iu RELOCATION COMPLETE message to the 3GMSC. The timer T3121 is stopped, when the BSC has received theCLEAR COMMAND with cause ‘handover successful’. When itexpires, the BSC sends a CLEAR REQUEST with cause ‘radiointerface message failure’ to the 3G-MSC to indicate the drop of theconnection during the handover procedure. This event is counted asa call drop by the PM counters NRFLTCH (subcounter 9) andNRCLRREQ (subcounter cause: radio interface message failure) andwill thus appear as a call drop event in the PM statistcs.

Note: T3121 has the same function for 2G-3G handover from GSM to

a UTRAN-TDD neighbour cell (TD-SCDMA). It is started when theHANDOVER REQUIRED is sent and it is stopped, when the CLEARCOMMAND with cause ‘handover successful’ is received.

BSCT4=HLFSEC-60,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-60


BSC timer T4 , this BSSMAP timer determines the time to return 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 ofthe RESET message is to initialize the BSSMAP relation betweenMSc and BSC and to put all affected circuits into the idle state. Whenthe MSC has received the RESET message form the BSC it releasesall affected connections and initializes the associated traffic channels.

After the a guard period of T2 (MSC timer) the MSC responds with aRESET ACKNOWLEDGE message. The timer T4 is started when theBSC transmits the RESET message to the MSC and watches overthe receipt of a RESET ACKNOWLEDGE from the MSC. If noRESET ACKNOWLEDGE has been received before expiry of T4, theBSC retransmits the RESET message and starts T4 again.

Rule: BSCT4 (BSC) > T2 (MSC)The value of T4 must be higher than the value of the MSC timer T2

plus the transmission time of the RESET and the 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 thereceipt of the RESET ACKNOWLEDGE message (equivalent to the





BSC 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-4


GSM 05.08

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 handoveris to be executed by the MSC (if the first target cell is an external oneor if LOTERCH or LOTRACH (see SET HAND [BASICS]) are set to

FALSE) or if the MSC has initiated a HANDOVER CANDIDATEENQUIRY procedure, the BSS sends a HANDOVER REQUIREDmessage to the MSC and starts T7. As long as T7 runs the BSC call

processing code remains in a state 'waiting for HO CMD'. During thistime the BSC ignores all new HO COND IND messages receivedfrom the BTS and no further HO RQDs are sent. If T7 expires (i.e. noHO CMD was received from the MSC), the BSC call processingterminates the 'waiting for HO CMD' state and the receipt of new HOCOND IND message directly leads to the transmission of an updatedHO RQD. All HO CMDs received after expiry of T7 are discarded bythe BSC.

Notes:1) Attention: Especially in case of Inter-MSC handovers or if thefeatures “queuing” or/and ”preemption” are used for incoming MSCcontrolled handovers, the handover completion may take a long timedue to the additional handover of the preempted call in the target cell.This has to be considered by setting BSCT7 to a sufficiently highvalue in the originating BSC. If BSCT7 is too short, the HO CMDmight be received after T7 expiry. This leads to the discarding of the

HO 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‘handover successful’ indication from the target side or aHANDOVER FAILURE (DTAP) from the originating side. As theexperience has shown, during inter-MSC handover procedures it maytake more than 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-6

2) This timer should be set with respect to the timer value THORQST(see command SET HAND) and the SIEMENS MSC internal timerT_HO_REJ. Recommended setting:

THORQST (HAND) > BSCT7 (BSC)

T7purpose: Waiting time for a HANDOVER COMMAND from the MSCstart: sending of HANDOVER REQUIRED by the BSC

stop: - receipt of a HANDOVER COMMAND from the MSC- communication to MS is lost- transaction has ended, call cleared

expiry action: - HO CMDs are ignored- new HO_RQD is sent if HO_COND_IND is received from the BTS





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 thatBSC layer 3 will wait for a handover to complete before releasing thesource channel.

The value must be bigger than the sum of the time for all messagesto be sent to the MS plus the time to access a target and come back(if necessary).Note: Due to the SBS implementation T8 replaces the function ofT3103 (see SET BTS [TIMER]).

Rule: BSCT8 < TTRAU(for TTRAU see command SET BTS [TIMER])This setting is necessary to ensure that a signaling failure (T8 andT10) is detected before transcoder failure (TTRAU)

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 TCHrequest for an incoming MSC-controlled handover (i.e. when the BSCreceives a HANDOVER REQUEST message from the MSC) is putinto a queue due to TCH congestion, TQHO determines themaximum time the TCH request may remain in the queue to wait fora busy TCH to become idle. If the TCH request for the incominghandover cannot be served within this time frame and TQHO expires

in case of incoming MSC-controlled HO, the TCH request is rejectedwith a HANDOVER FAILURE. As a result, if there is another targetcell available for the handover procedure, the MSC will attemptanother HO REQUEST procedure towards the next target BTS.#

Note:It is possible to accelerate the release of busy TCHs by anappropriate setting of the timer T3111 (see SET BTS [TIMER]). Thiscan decrease the queuing time considerably.

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 not

successful 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).

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

MSC-controlled handoverstart: sending of the QUEUING INDICATION (BSC->MSC)stop: - successful allocation of a TCH to the queued TCH request

- discarding of the TCH request from the TCH queue(all cases except TQHO expiry)

expiry action: Sending of a HANDOVER FAILURE with cause 'no radio resourceavailable' to the MSC followed by release of the call resources.





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 andappear in the DBAEM in the SET BSC command. The logical group“[BASICS]” is normally only used on the LMT but was used here toallow a more useful grouping of the commands .


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. TCHresources on the Um) is attempted.

During a TBF lifetime, due to variations in radio conditions, either theBLER or the used CS/MCS coding scheme can change, leading to achange in the ‘maximum sustainable throughput’. The maximumsustainable throughput (MST) is defined as the maximum throughputthat would be achieved by a given TBF if it was alone on the multislotconfiguration, that is:

Maximum sustainable throughput (MST) = T_A_CS ∗ (1-BLER) ∗ #TS

where:

T_A_CS = throughput of the Actual Coding Scheme

BLER = actual BLER

#TS = number of allocated timeslots to the TBF

A check on the current maximum sustainable throughput is performed periodically, with a periodicity defined by the parameterUPGRFREQ (see below). As a general rule, only a decrease of themaximum sustainable throughput is considered; an increase of theMST will not lead to any system reactions, as a ‘downgrading’ ofradio resources due to MST criteria is not performed. Moreover,since the variations in the maximum sustainable throughput canhappen very frequently, only the decrease of the MST below a

particular threshold will lead to a system reaction (i.e. upgrading of

radio resources). An extension to the number of allocated TSs is tried if:

T_A_CS ∗ (1-BLER) ∗ #TS < (1- ACCEPTGDEGR) ∗ PT

where:

T_A_CS = throughput of the Actual Coding Scheme

BLER = actual BLER

PT = peak throughput

#TS = number of allocated timeslots to the TBF

This means that, when the MST becomes lower than the maximumtolerable degradation of the peak throughput, the upgrading of radioresources is attempted. The upgrade is performed by adding oneadjacent timeslot timeslot to the currently used ones (i.e. the PCU willsend a PDCH_Upgrade_Request message to the TPDC), providedthat the conditions regarding horizontal allocation and the percentage

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

Note: As long as the ‘one radio resource a time’ algorithm isimplemented it is suggested to set the ACCEPTGDEGR attribute 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 bya) the higher layers on the CCS7 link (e.g. BSSAP) andb) the CCS7 layer 2 functions.

Setting AISAT=TRUE has the following consequences:

a) BSSAP timers (e.g. BSCT7, BSCT8 etc., see SET BSC [BASICS])have to be carefully checked as the delay on the lower layers slowsdown all signaling transactions. It might be necessary to extendselected timers to higher values to avoid undesired effects.b) If the A interface is realized via satellite link the CCS7 errorcorrection method must be set to 'preventive cyclic retransmissionerror correction' (see CREATE SS7L, parameter ERRCORMTD).

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

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

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


range: ENABLED(1..100),

DISABLED

default: ENABLE(30) (minor)

ENABLE(60) (major)

ENABLE(90) (critical)

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

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

ASCIONECHMDL=FALSE,


range: TRUE, FALSE

default: FALSE

ASCI one channel model , this parameter is only relevant if thefeature ASCI is enabled (see parameter ASCISER in command SETBTS [CCCH]) and determines whether the ASCI ‘one channel 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 severalother called service subscribers in the group call area), for the calledservice subscribers basically only one downlink channel (ASCIcommon TCH) is provided, i.e. they can only listen to the dispatcher.However, a service subscriber has the possibility to request an uplinkchannel to transmit speech to the other group call partners by

pressing the PTT (push to talk) button on the ASCI phone.In this situation, when ASCIONECHMDL is set to FALSE (1,5

channel mode), the following happens: when the service subscriberrequests an uplink TCH by pressing the PTT button in order totransmit speech, the BSC assigns a completely new TCH to thesubscriber in addition to the alredy existing downlink TCH - thus theservice subscriber occupies ‘one and a half’ TCHs (therefore called“1,5 channel mode”).

Setting ASCIONECHMDL to TRUE guarantees a more economicutilization of the radio TCH resources: when the service subscriberrequests an uplink TCH via the PTT button in order to transmitspeech, the BSC only assigns an uplink channel to the alreadyexisting downlink channel, so that in the end only one ordinary ‘two-way’ TCH is occupied by the service subscriber (“1 channel mode”).





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



DISABLED


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 enteredthreshold value represents the percentage of unavailable SS7 linkson the A interface. If the number of unavailable SS7 links exceedsthe entered threshold, the alarm messages UNAVAILABLE SS7 LINKTHRESHOLD MINOR, MAJOR or CRITICAL (error ID 236, 238 and241) are output. The threshold values can only be assigned if the

previous attribute is set to ENABLE.ASUBENCAP=FALSE,


range: TRUE, FALSE

default: FALSE

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

parameter WMOD in the command CREATE PCMS.

ASUBISAT=FALSE,


range: TRUE, FALSE

default: FALSE

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

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

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

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

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

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

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





is up to the operator to follow this rule.

BSCOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

BSC overload handl ing , determines whether BSC overloadhandling is enabled or not. For further details about the BSC overloadregulation 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 chapterthat 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 handlingis enabled or not. For further details about the BTS overloadregulation 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 chapterthat comprises all possible scenarios of overload and overloadhandling as well as the references to the relevant parameters.

Further parameters relevant for BTS overload handling:

BSCT18 and BSCT17 (see command SET BSC [TIMER])CBCPH = PH1_CBC,


range: PH1_CBC, PH2_CBC

default: PH1_CBC

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

From the BSC side, the old CBC interface (without Channel_Indicator parameter) is still supported. In this sense the RC/LMT operator canset the database flag CBCPH to PH1_CBC to indicate that theconnected 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 implementedonly at CBC-BSC interface level, this means that on the A-bisinterface the EXTENDED channel is not implemented, as no mobilesupports this feature at the moment. So the customer can choose aCBC centre implementing the new interface (including thechannel_indicator parameter and setting theCBC phase = 2), but onlythe BASIC channel can be specified in the channel_indicator fieldfrom the CBC operator.

CICFM=GSM,


range: GSM, NOTSTRUCT

default: GSM

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

CITASUP=FALSE,


range: TRUE, FALSE

default: FALSE

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





CPOLICY=NO_PREFERENCE,


range: DATA_CALL_ON_BCCH

SPEECH_CALL_ON_BCCH

NO_PREFERENCE

default: NO_PREFERENCE

Cal l pol icy , this parameter specifies the BSC channel allocation policy when different services are required. This feature is also called“ preferred TRX “. DATA_CALL_ON_BCCH indicates that the BSCshall allocate incoming data calls (GPRS and CS/HSCSD) on theBCCH TRX first. SPEECH_CALL_ON_BCCH indicates that the BSCshall allocate incoming speech calls on the BCCH TRX first. The CallPolicy is not only considered during call setup, but also features a

‘forced intracell handover due to preferred TRX’. This means that, ifthe call could not be set up on a preferred TRX as all TCHs werebusy, the call is moved to the preferred TRX by a forced intracellhandover as soon as the preferred TRX resources become idleagain.

Notes:- The forced intracell handover due to preferred TRX is only

performed for speech calls and for single slot data calls (data rate 2,4kbit/s .. 14,4 kbit/s). For HSCSD calls no intracell HO is possible.- For GPRS calls, the call policy is considered, but with a very low

priority. In fact, the following rules are considered for the TCHallocation for GPRS calls:1. Maximum number of adjacent timeslots based on PCU estimation2. Maximum re-use

3. Minimum number of forced handovers for CS calls4. TRX preference defined by CPOLICY- In BR7.0 the priorization ofa) satisfaction of requested CS data rates (for HSCSD calls) andb) the call policywas changed (due to CR1150). In BR6.0 the BSC always allocated aTCH on the preferred TRX, even if the data rate requirement couldnot be satisfied on the preferred TRX but could have been satisfiedon a non-preferred TRX, in BR7.0 the ‘preferred TRX’ setting justdetermines on which TRX the BSC searches for the requested TCHresources first. Incoming CS requests (singleslot and multislot) aresatisfied searching for the requested resources first on the preferredTRXs and then on the not-preferred TRXs. This means that thedowngrade of incoming HSCSD multislot calls to 1 timeslot is done

only when the requested data rate requirement cannot be satisfied onany of the available TRXs in the cell.- In case of TCH congestion, the preemption of an empty channel(i.e. a TCH which is activated for GPRS (PDCH), but the timerTEMPCH (see command CREATE PCU) is running due to the factthat there is no TBF on it) is attempted (no matter how theDGRSTRGY is set), otherwise the normal downgrade procedure foractive multislot calls, or preemption, directed retry or queuing are

performed according to the existing rules.Please see also parameter DGRSTRGY (see below).





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 generallyin the BSC. The same parameter is also available in the PTPPKFobject where it can be used to enable/disable CS3/CS4 individually

per BTS (see parameter CSCH3CSCH4SUP in command CREATEPTPPKF).

The coding schemes 3 and 4 allow a considerably higher GPRS datathroughput than the previously available coding schemes 1 and 2.

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

GPRS Coding scheme maximum gross data rate

CS-1 9,05 kbit/s

CS-2 13.4 kbit/s

CS-3 15.6 kbit/s

CS-4 21.4 kbit/s

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

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

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

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

GPRS coding scheme Radio Block Size in 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=NO_DOWNGRADE,

object: BSC [BASICS]range: HSCSD_FIRST_DOWNGRADE

GPRS_FIRST_DOWNGRADE

DOWNGRADE_HSCSD_ONLY

DOWNGRADE_GPRS_ONLY

NO_DOWNGRADEdefault: NO_DOWNGRADE

Downg rade strategy , this parameter defines the downgradestrategy for HSCSD and GPRS calls used during the resourcereallocation procedure for TCH requests for single-channel circuitswitched calls. The downgrade can be considered as a kind of

preemption for resources currently seized by multi-channel calls.With the ‚downgrade strategy’ the operator can determine how muchthe bandwidth and grade of service of HSCSD and GPRS is affected

in case of TCH congestion. The scenario that triggers a downgrade procedure is always a TCH seizure request for a single-channelcircuit-switched call received when all TCH resources in the cell arebusy. TCH requests for single-channel CS calls can occur in form of:a) a new call setup of a (receipt of an ASSIGNMENT REQUEST)b) an incoming inter-BSC handover (receipt of a HANDOVERREQUEST)c) an incoming intra-BSC handover (receipt of an INTERCELLHANDOVER CONDITION INDICATION)d) an intracell handover (receipt of an INTRACELL HANDOVERCONDITION INDICATION)

In any of the mentioned cases the downgrade procedure is started to provide TCH resources to the incoming TCH request in accordancewith the value set for DGRSTRGY.

Attention: If in case c) the INTERCELL HANDOVER CONDITIONINDICATION contains more than one target cell, the BSC firstanalyzes the TCH resources in the first target cell. If no idle TCH canbe found and if the TCH congestion is partly caused by multislotcalls, the BSC first checks the other target cells for available TCHresources. Only if in none of the target cells a TCH can be found forallocation, the BSC starts the downgrade in the first target cell wherethis is possible.

The parameter values have the following meaning:1) HSCSD_FIRST_DOWNGRADE means that all HSCSD calls aredowngraded first before a GPRS call is downgraded.2) GPRS_FIRST_DOWNGRADE means that all GPRS calls aredowngraded first before an HSCSD call is downgraded.3) DOWNGRADE_HSCSD_ONLY means that only HSCSD calls are

downgraded while GPRS calls remain unaffected.4) DOWNGRADE_GPRS_ONLY means that only GPRS calls aredowngraded while HSCSD calls remain unaffected.5) NO_DOWNGRADE means that both GPRS and HSCSD callsremain unaffected.

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) downgrade

- 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 superordinate to the TCH is created with GSUP=TRUE(see CREATE TRX).- The GPRS downgrade strategy has an influence on all TCH loaddependent features such as Traffic Handover (see parameterTRFHOE in command SET HAND[BASICS]), Cell Load Dependent

Activation of Half Rate (see parameter EHRACT in commandCREATE 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 orDOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which

are 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 CREATEPCU) 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 TCHcongestion the BSC immediately releases PDCHs (TCHs activatedfor GPRS) with TEMPCH running if a CS TCH request is receivedand no other idle TCH is available for allocation. This change wasimplemented in BR7.0 in the scope of CR1150.

DLAPDOVL=TRUE,

object: BSC [BASICS]range: TRUE, FALSE

default: TRUE

Downl ink L APD Overload , this parameter allows to enable ordisable the procedure that detects the downlink LAPD overload. If the

BTSE has detected an overload situation on the LAPD link based onthe LAPD load thresholds SLAPDOVLTH (see command CREATEBTSM), it sends the O&M message LAPD OVERLOAD towards theBSC. If DLAPDOVL=TRUE, the BSC starts traffic reductionmeasures 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 CREATEBTSM).

EFRSUPP=FALSE,


range: TRUE, FALSE

default: FALSE

Enhanced ful l rate supported , this parameter determines whetherthe assignment of enhanced full rate TCHs is generally allowed forthe BSC or not.Notes:- The decision, which kind of TCH (EFR, FR or HR) is finallyassigned to a TCH request is made by the BSC on the basis ofa) the channel requirement provided by the MS in the SETUPmessage,b) the MSCs capability to support the requested speech versions(which results in a corresponding contents of the ASSIGNMENTREQUEST /HANDOVER REQUEST message which the MSC sendsto the BSC) andc) the current occupation of TCH resources in the affected BTS andTCH allocation strategy used by the BSC.- As opposed to HRSPEECH, which enables/disables both standardhalf rate speech (HR version 1) and AMR half rate (HR version 3),the setting of EFRSUPP has no effect on AMR.





EHRACTAMR=FALSE,


range: TRUE, FALSE

default: FALSE

Enable cel l load dependent activat ion o f hal f rate for AMR cal 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 onlyassigned 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 loadthreshold is defined by the parameters HRACTAMRT1 andHRACTAMRT2 (see command CREATE BTS BASICS]).

For Abis load dependent activation HR the radio TCH traffic loadthreshold is defined by the parameter ABISHRACTTHR (seeCREATE BTSM).

For further details about the feature functionality and the exactcalculation 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 andthe traffic load calculation algorithm are exactly the same for calls

with 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 CREATEBTS [BASICS]).

Note: The database flags EHRACTAMR (SET BSC) and EHRACT(CREATE/SET BTS) are independent of each other, i.e. for operationof the feature ‘Cell load dependent activation of half rate’ for AMRcalls only the flag EHRACTAMR is relevant, the setting of the flagEHRACT does not have any influence.

EISDCCHHO=ENABLE,


range: ENABLE, DISABLE

default: ENABLE

Inter SDCCH hand over enabled, determines whether ‘Inter BSCSDCCH handover’ is enabled.‘Inter-BSC SDCCH handover’ consists of1) Inter-BSC Directed Retry (see param. ENFORCHO) and2) 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 andb) the BSC drops all target cells (received in the HCI) that do notbelong to the own area.

ENCALSUP=NOENCR&GSMV1&GSMV2,


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.





ENFOIAHO=TRUE,


range: TRUE, FALSE

default: FALSE

recommended value: TRUE

(if GPRS and/or HSCSD are enabled)

Enable forced intra-cel l HO , this parameter enables the “ ForcedIntracell Handover due to multislot calls ” procedure. EFOIAHOshould be set to TRUE, if either GPRS or HSCSD is used in the BSC.

If there are not enough adjacent radio TCHs available when arequest for multislot call (HSCSD or GPRS) is received a forcedintracell handover is performed which reorders the current timeslotseizure in such a way that a sufficient number of adjacent timeslots is

available to satisfy the multislot call request to the best possibleextent. This kind of handover is triggered and executed by the BSC: it

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 CONDITIONINDICATION is sent from BTS to BSC.

ENFORCHO=ENABLE,


range: ENABLE, DISABLE

default: ENABLE

Forced handov er enabled , this parameter determines whether theBSC may send a FORCED HANDOVER REQUEST message forrunning SDCCH connections to the BTS. This message is used foreither 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 MSattempts a MOC in a cell in which no idle TCH is available, e.g. dueto congestion. A successful ‘Directed Retry’ results in the assignmentof a TCH in the best adjacent cell. During this procedure the BSC,having received the ASSREQ from the MSC, sends the ‘forcedhandover request’ message to the BTS, which in turn sendsHANDOVER CONDITION INDICATION messages with the cause‘forced’. The HCI messages contain a list of target cells that the BTShas determined by evaluating the measurement reports sent uplinkby the MS during the SDCCH phase. (-> see also commandCREATE ADJC., parameters FHORLMO and TIMERFHO andsection 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:- Setting this parameter to ‘enable’ only activates the Directed Retrycontrolled by the BSC, i.e. directed retry to target cells belonging tothe same BSC. If Inter-BSC Directed Retry shall be enabled the flagEISDCCHHO (see above) has to be set to 'enable' in addition.- In hierarchical cell structures the ranking of the target cells in theHCI sent as a result of the ‘forced handover request’ is performedaccording 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. Forfurther details pleas refer to the parameter BTSHSCSD (seecommand SET BTS [BASICS]).- Directed retry also works if direct TCH assignment (see parameterDIRTCHASS 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 SHUTDOWNcommand 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 ‘earlyclassmark 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 andSACCH) and further 1..3 secondary TCHs . All radio timeslots usedfor one connection are FR timeslots located on the same TRX anduse 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 thesecondary 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 higherthan the transmission rate and is thus very typical for Internetapplications. The asymmetric mode is only possible for non-transparent data connections.Resource allocation: The BSC is responsible for the flexible airresource allocation. It may alter the number of TCH/F as well as thechannel codings used for the connection. Reasons for the change ofthe resource allocation may be either the lack of radio resources,handover and/or the maintenance of the service quality. The change

of the air resource allocation is done by the BSC using ‘service levelupgrading and downgrading' procedures. For transparent HSCSDconnections the BSC is not allowed to change the user data rate, butit 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 qualityreporting for each used channel is applied. For an asymmetricHSCSD 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 andasymmetric HSCSD configuration the neighbour cell measurementsare reported on each uplink channel used. All TCHs used in an

HSCSD connection are handed over simultaneously. The BSC mayalter the number of timeslots used for the connection and the channelcodings when handing the connection over to the new channels. Allkinds 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: FALSE

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 otherwords: the feature transfers HR calls that currently occupy one HRsubslot 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 bya 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 seizedeither by two HR calls or one FR call.The enhanced pairing intracell handover is controlled exclusively bythe 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 pairingintracell 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).

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 pairingintracell handovers are triggered if the following traffic load condition

is 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 leastone of the aforementioned condition is fulfilled, enhanced pairingintracell handovers are automatically performed by the BSC bysimply 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 handovers

due 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 BSCchecks if the TCH load condition for enhanced pairing is fulfilled andif there are some ongoing HR calls to be paired. This means that, ifthe TCH load condition is fulfilled, it takes at the maximum 400msuntil the unpaired HR calls are rearranged by enhanced pairingintracell handover.

< ∗ 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[%]





EPOOL=TRUE,


range: TRUE, FALSE

default: FALSE

Parameter name and value formatchanged in BR7.0 (name changed from

ENPOOL to EPOOL, ‘initial pooling

type’ was removed)!

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 onthis 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 ordinaryspeech 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 validup to BR4.0) is now replaced by a semipermanent mapping pattern,which depends on the number and type of pools configured. Only thebasic mapping principle can be selected initially (see commandCREATE TRAU, parameter ALLCRIT).

Moreover, the pooling type must be adapted to the version andcapabilities of the used TRAC-HW in the TRAU, i.e. the pooling typesthat include the support of more advanced features must be assignedto 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 correspondingtables included in the HW-FW Crossreference List in the SBSRelease Documentation!). Thus it is possible to assign differentspeech and data coding types to different TRAU shelves.

EPREHSCSD=DISABLED,


range: ENABLED, DISABLED

default: DISABLED

Enable preemp tion for HSCSD requests , this attribute is onlyrelevant if HSCSD is enabled (ENHSCSD=TRUE). If it is set toTRUE, 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 fordifferent alarm event types. The five entered subattributes representalarm messages in the alarm event types Communication-QualityOfService-Processing-Equipment-Environment. WhenERRACT is set to one alarm priority for a specific alarm event type allalarms of lower and equal priority are ignored for this event type.Notes:- Attention: the filter setting defined by ERRACT is not only relevantfor 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 ofcertain call processing alarm messages which are normallysuppressed (e.g. AP ERROR INDICATION, MESSAGE OUT OFSEQUENCE etc.) in order to allow a closer look on the grade ofservice in the cell for maintenance purposes. Thus FERMAINT works

as a 'negative' filter.

ESUP=FALSE,


range: TRUE, FALSE

default: FALSE

EDGE supp ort , this parameter enables or disable the feature EDGEin the BSC. Setting this parameter is a precondition before EDGEservices can finally be enabled on cell level (EEDGE in objectPTPPKF).





EUSDCHO=FALSE,


range: TRUE, FALSE,

<NULL>

default: FALSE

Enable UMTS SDCCH handover , this parameter is only relevant ifthe 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. With some restrictions, EUSDCHO is akind of equivalent to the parameter EISDCCHHO (see above).

This means that, only if EUSDCHO is enabled, the BSC forwards a

HANDOVER REQUIRED message to the MSC, if an INTERCELLHANDOVER CONDITION INDICATION message that contains anUMTS FDD target cell (see commands CREATE TGTFDD andCREATE ADJC3G) or an UMTS TDD target cell (command CREATETGTTDD) 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 or2) Service-Based Directed-Retry, i.e. a FORCED HANDOVERREQUEST message was triggered towards the BTS if the new IE"Service Handover" in the ASSIGNMENT REQUEST message is setto "Handover to either UTRAN or cdma2000 should be performed"and the resulting INTERCELL HO CONDITION INDICATIONmessage contains an UTRAN target cell.

Setting EUSDCCHHO to FALSE has the following results:a) the BSC is prevented from sending HANDOVER REQUIREDmessages with UMTS 3G target cells for ongoing SDCCHconnections to the MSC andb) the BSC drops all UMTS FDD target cells if the originalINTERCELL HANDOVER CONDITION INDICATION received fromthe BSC contained both GSM and UMTS 3G target cells.

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’. Synchronizedhandover is possible between cells belonging to the same site(intercell handover from one sector to the neighbour sector). The

difference between the both handover procedure is the following: Asynchronous handover (cells not synchronized):In case of (normal) asynchronous HO the BSC activates the TCH inthe 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 andrepeats the transmission until it receives the PHYSICAL INFO. Thismessage contains the actual timing advance value which the newBTS derives from the delay of the HO_ACCESS messages receivedfrom 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 targetcell by a CHANNEL ACTIVATION message with the IE ‘activationtype: related to synchronous handover’. The HANDOVERCOMMAND sent by the BSC then contains the “ SynchronizationIndication: synchronized “. When the MS accesses the target cellafter 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 sentto the MS. A fallback to the to the old TCH is only possible if the MS





fails 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 SBS.

HRSPEECH=TRUE,


range: TRUE, FALSE

default: FALSE

Half rate speech , this parameter specifies whether the feature ‘HalfRate Speech’ is generally enabled for the BSC or not. The status ofthis flag determines whether the BSC allows the assignment of anHR TCH if the ASS REQ contains a corresponding ‘preferred channeltype’. To assign a HR TCH, of course, the appropriate TCH types(see CREATE CHAN, parameter CHTYPE) have to be configured forthe 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 parameterEADVCMPDCMHO in command SET HAND).

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



DISABLED


ENABLE(60) (major)ENABLE(90) (critical)

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 centricsolution 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 centricsolution is used!

MADGRLV=2,


range: 0..3

default: 2

Maximum AIUR downg rade level for NT data cal ls , this attribute isonly relevant if HSCSD is enabled (ENHSCSD=TRUE) anddetermines the maximum AIUR downgrade level for non-transparentdata 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 handoverintracell handover is enabled (ENHSCSD=TRUE,ENFOIAHO=TRUE) and determines the maximum number of forcedintracell 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) .





MAXNCELL=16,


unit: 1

range: 1-16

default: 1

Maximum n umb er of target cel ls , this parameter indicates howmany 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)).

MNTBMASK=<DEFAULT>,


unit: 1

range: BIT1.. BIT29

<DEFAULT>, Null

default: 1

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 thatwere introduced in BR6.02 as late features. For this reason it isurgently recommended to use this parameter only, if the operatorknows the exact impact of each of the bits that can be set.

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

• Setting MNTBMASK=BIT25 disables the use of the GPRS codingschemes CS3 and CS4. This means that, if BIT25 is set, the BSCwill only use the coding schemes CS1 and CS2 for GPRS. Some

customers prefer to disable CS3/CS4 if EDGE is enabled, as withthe number of concatenated EDGE radio timeslots supported bythe currently available mobile phones the performance of EDGE isnot far superior than the that of CS4. Thus the disabling ofCS3/CS4 shall motivate the subscribers to subscribe to the EDGEservices. However, setting MNTBMASK=BIT25 has the followingside-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 codingschemes required two concatenated Abis TCHs. If, however,EDGE is enabled, two concatenated Abis TCHs will also be usedfor CS2 (If EDGE is disabled, CS1 and CS2 can be handled with asingle Abis TCH). This means: if EDGE is enabled, but CS3/CS4is disabled by BIT25, CS3 and CS4 will not be allocated but two

concatenated Abis TCHs will be used for CS2 although this wouldnot 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=BIT24 modifies the Implementation of thefeature ‘Common BCCH’ in such a way that it is possible to mixTRXs of different Frequency bands within the complete area of theconcentric cell while the inner area is not configured. Furtherdetails are described in section “Common BCCH Solution formixed frequency bands within the complete area” in the appendixof this document. This functionality was originally only available forthe US market and frequency bands (PCS1900 and GSM850), butwas adapted also for the other frequency bands (GSM900 andDCS1800) with the implementation of the change request CR2199

in BR70/05.• Setting MNTBMASK=BIT17 has the effect that GSUP can be

enabled (and thus TRXMD can be set to EDGE) also in TRXs inthe GSM900 extension band, both in EXT900 and in GSMDCScells with the BCCH in the GSM900 primary band. This implies asending of all frequencies (GSM900 primary band and GSM900extension band) in SYSTEM INFORMATION TYPE1, causing alimitation on the number of possible frequencies (GSM900 primaryband and GSM900 extension band) that can be used in the cell toonly 22 (independently from thier value) and to a greather numberonly if they are "well distributed". This limitation is applied not onlyto cells using GPRS but to all EXT900 or GSMDCS cells in the





BSC. (CR2132)

• Setting MNTBMASK=BIT17 and MNTBMASK=BIT24 has theeffect that GSUP can be enabled (and thus TRXMD can be set toEDGE) in all TRXs of the cells (GSM900 and DCS1800). Thisimplies to sending of all frequencies (GSM900 primary band,GSM900 extension band and DCS1800 band) in in SYSTEMINFORMATION TYPE1, causing a limitation on the number of

possible frequencies that can be used in the cell to only 16

(independently from thier value) and to a greather number only ifthey are "well distributed". This limitation is applied not only to cellsusing GPRS but to all GSMDCS cells in the BSC.Note: The usage of the MNTBMASK=BIT17 alone, and the usageof both MNTBMASK=BIT17|BIT24 together, imply a change in thecontents and encoding of the SYSTEM INFORMATION TYPE 1for all cells in the BSC, and consequently of the related Mobile

Allocation IEs, that have to be communicated to all BTS. Thisrequires a complex procedure which is not foreseen in the BSCimplementation. For this reason, and considering that the usage ofBIT17 and BIT24 is related to a cell planning strategy and not to a

punctual demand, a change of BIT17 and of BIT24 is rejected witha NACK cause if MNTBMASK=BIT17 was already set and if atleast one cell is configured in the BSC. The change of both BIT17

and BIT24 are in this case only possible during offlinegeneration/conversion of the BSC database file.

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 byMNTBMASK the default value is ‘0’.- The command allows to set 30 bits (BIT0..BIT29), however, onlysome 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 BITyto '0' and sets BITx to '1'. This means that, if some of the bits are

already 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 settingMNTBMASK=Null or MNTBMASK=<DEFAULT>.

MSCOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

MSC overload handl ing , determines whether MSC overloadhandling is enabled or not. MSC overload is detected by the MSCitself. The BSC is informed by the BSSMAP message OVERLOADwith cause „ processor overload“ . The MSC reduces paging load byits 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 overloadhandling are closely interwoven, the overload conditions and trafficreduction mechanisms are explained in an own chapter thatcomprises all possible scenarios of overload and overload handlingas 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,


range: TRUE, FALSE

default: FALSE

MSC pool ing , this parameter specifies whether the connected MSCis 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 tomanage the pooling types assigned to the A interface resources, too.

MSCV=PHASE2,

object: BSC [BASICS]range: PHASE1

PHASE2

PHASE2CC

PHASE2EFR

PHASE2CCEFR

default: PHASE1

MSC version , this parameter determines the protocol type to beused on the A-interface. This parameter has to be set in

correspondence with the GSM phase resp. the supported A-interface protocol variants of the connected MSC. PHASE2CC indicates thatMSC 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, thereceipt 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’.

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) orC31/C32 (in case a PBCCH is available in the cell).

The Network Controlled Cell Reselection is a different cell reselectionmethod: The network requests measurement reports from the GPRSMSs and controls their cell reselection based on thesemeasurements and configurable network controlled cell selection

parameters. Thus, if network-controlled cell reselection is enabled,the network instructs the GPRS mobile to transmit the RXLEV_DLvalues of both serving and adjacent cells in PACKETMEASUREMENT REPORT messages. Based on the reportedmeasurement values and on the configured network controlled cellreselection 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 NetworkControlled 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 networkcontrolled cell reselection guarantees the optimum usage ofresources, i.e. a better GPRS/EGPRS traffic distribution among the

available 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 NetworkControlled Cell Reselection is enabled.- if the user wants to enable the Traffic Control Network ControlledCell 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 stablishmentC ause I ndicator) bit, which isbroadcast in the SYSTEM INFORMATION TYPE 3 in the IE ‘CellSelection Parameters.’ and which determines which ‘establishmentcause’ values in the CHANNEL REQUEST message the MSs in thecell are allowed to use when requesting a dedicated control channelvia the RACH for call setup or other transactions.

The available ‘establishment cause’ bit strings in the CHANNELREQUEST 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 signalingof 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 specificsignaling 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 onlyallowed to use only 3-bit establishment cause values, i.e. even if theysupport phase 2 establishment cause values, they are not allowed touse them. Thus all mobiles must behave like phase 1 mobiles duringthe 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 byNOKIA 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 bitwas controlled by a TDPC patch (i.e. if the patch was loaded, theNECI 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 bytheir establishment cause values and count them in separate cause-specific subcounters. As some of the subcounters of ATIMASCA andSUIMASCA represent specific phase 1 and phase 2 establishmentcauses, the changing of the NECI parameter will change thedistribution of the counts over the subcounters. Moreover, especiallyif 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 ’thatwas provided for each load up to BR6.0. To achieve the same effectas 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

new values in BR7.0!

Network typ e , determines the type of network respectively frequencyband.

The value GSMRAILPUB means that the frequency bands GSMRand 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 andand indicates for which mobile priorities the NOTIFICATION FACCHmessages (BSC->MS) are sent on the FACCH belonging to the TCHseized 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 pagingchannel (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 ASCIMSs 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 onlyif the PAGING message from the MSC contains the optional IE‘eMLPP priority’ andif the priority level indicated in the ‘eMLPP priority’ IE is equal orhigher than the priority level defined by the parameter NOTFACCH.Exception: if NOTFACCH is set to ALWAYS, the priority level is notchecked and the NOT FACCH message is sent in any case.

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

parameter ASCIONECHMDL in command SET BSC [BASICS])) cannever 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’ ASCIsubscribers can receive a notification on FACCH with paginginformation 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 ASCIsubscribers 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 levelindicated in the PAGING message is higher or lower than the prioritylevel indicated in the VGCS/VBS ASSIGNMENT REQUESTmessage.

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 orMTC), 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 callinformation is included’. However, the BSC sends theNOTIFICATION FACCH message to the busy ASCI subscriber only





- if the VBS/VGCS ASSIGNMENT REQUEST message from theMSC contains the IE ‘ call priority’ andif the priority level indicated in the ‘ call priority’ IE is equal or higherthan the priority level defined by the parameter NOTFACCH. Onlyexception: if NOTFACCH is set to ALWAYS, the priority level is notchecked and the NOTIFICATION FACCH message is sent in anycase.

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=NTWSN16,


range: NTWSN16,

NTWSNAP

NTWSNAP_STLP

default: NTWSN64

Network c ard type , determines whether a switching networkSN64,SN16 is used.

If the BSC is upgraded to a high capacity BSC, the BSC must beequipped with a SNAP module. The corresponding setting must beNTWCARD=NTWSNAP. If, in addition, STLP boards are used asPCM interface cards the setting NTWCARD=NTWSNAP_STLP ismandatory.

OVLSTTHR=9500,


unit: 1000=10%

range: 7000..10000

default: 9500

BSC overload start threshold , this parameter determines the TDPCload 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 TDPCload 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).

PCMTYPE=PCM30,


range: PCM30, PCM24

default: PCM30

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





SIMSCREL99=FALSE,


range: TRUE, FALSE

default: FALSE

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 parameterSIMSCREL99. If SIMSCREL99 is set to TRUE (and thus the ‘MSCRevision’ bit is set to ‘1’ in the SYSINFO 3), the MSs are allowed to

send 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 wayto 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 normalIMMEDIATE 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 DispatcherInformation) 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 2message if the MSC Release bit is set to ‘1’, which indicates that theMSC release is Release 99 or higher. This new procedure is allowedonly with MSCs that are compliant to GSM release 99 or higher.

Also other applications might require the R99 compatibility of theMSC.

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

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

SISGSNREL99=FALSE,


range: TRUE, FALSE

default: FALSE

System Information SGSN release 99 , this parameter determinesthe value of the ‘SGSN Release’ bit in the SYSTEM INFORMATIONTYPE 13. This setting has a similar function like the parameterSIMSCREL99 (see above). It indicates that the Mobile Stations are

allowed 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 selectionbetween 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 wayto check the release compliance of the SGSN) to avoid protocolerrors.

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





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 ofchannel coding increases the data throughput of a single GSM timeslot to 14.4 Kbit/s netto data rate and is based on a specialtranscoding 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 ofthe 9.6kbit/s coding. As a result the effective data rate of the14.4kbit/s coding available to the user in non-transparent mode orwhen an external end-to-end error-control is applied may drop belowthe effective data rate achieved with the 9.6kbit/s coding. For thisreason, a channel mode modify procedure in case of non-transparentmode (upgrading & downgrading: 9.6 kbit/s 14.4 kbit/s and viceversa) is implemented to adapt the data rate appropriately to the C/Ienvironment. The BTS indicates the in-call-modification to the BSCusing 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 notsupporting 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 includedin the command SET HAND [DATA].

Note: If SPEED145 is set to TRUE, the 14,5 kbit/s data service isgenerally allowed for the BSC. For BTSs of the BTS1 family theexplicit activation is done by the parameter PUREBBSIG44CONF(see CREATE BTS [BASICS]). For BTSs of type BTSplus an explicitactivation is not required.

SPENLAW=A_LAW,


range: A_LAW

M_LAW

default: A_LAW

Speech enco ding law , specifies the used speech coding law usedon the PCMA links. The PCM30 standard (normally used in all

European and non-American countries) uses the A-law transcodingstandard, while in countries PCM24 links (normally used in American

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





T3122=5,


unit: 1s

range: 0..255

default: 5


Wait indicat ion time , defines the MS waiting time before the MSallowed 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 BSCcannot find any idle SDCCH to satisfy the request, it rejects theaccess attempts by sending an IMMEDIATE ASSIGNMENT REJECTmessage via the AGCH. The timer T3122 defines the time the MSmust wait before it is allowed to send another CHANNEL REQUESTvia 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 transmittedCHANNEL REQUEST or whether it does not receive any response atall. While in the latter case the MS will leave the cell (by cellreselection) after a defined number of RACH access attempts without(see parameters MAXRETR and NSLOTST in command SET BTS

[CCCH]) without receipt of an IMMEDIATE ASSIGNMENTCOMMAND 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 RACHaccess attempt. In this case the MS will stay in the cell.

TCBCSI=0,


unit: 1s

range: 0..1440

default: 1

Timer for CBC service interruption . The BSC transiently stores allShort 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 ofthe CBC messages from the TDPC memory. In other words: whenthe outage time of a BTS exceeds the time specified by TCBCSI, allSMS-CB messages for the affected BTS are deleted from thetransient TDPC memory. On recovery of the failed BTS the BSCsends a RESTART INDICATION to the CBC which initiates a

realignment with the BSC which re-establishes the transient SMS-CBdata in the TDPC.

Value ‘0’ means: “No message clearing from BSC'





TGUARDTCHSD =SEC10,


range: SEC00, SEC10, SEC11,

SEC12, SEC13, SEC14,

SEC15

default: SEC00

Guard Tim er for TCH/SD, this parameter defines the time the BSChas 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 CREATECHAN), 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 basicallybelongs to the TCH/SD_POOL, where it can be used as normal dualrate TCH. When the BSC receives an SDCCH request while the

percentage of busy SDCCH subslots has exceeded the thresholdSDCCHCONGTH (see command CREATE BTS [BASICS]), the BSCmoves the 8 SDCCH subchannels of one TCH/SD from theTCH/SD_POOL to the SDCCH_BACKUP_POOL to keep additionalSDCCH 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 BSCchecks the current SDCCH traffic load according to the followingformula

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 thresholdSDCCHCONGTH (see command SET BTS).

a) In case of SDCCH traffic load SDCCHCONGTH the TCH/SD remains in the SDCCH_BACKUP_POOL andTGUARDTCHSD 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 duringthe 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 BSCreceives 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 SDCCHrelease 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 parameterINTCLASS 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 RESULTmessages. 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 Trafficrecording (CTR, see command CREATE CTRSCHED) are enabled.

The BTS starts to send the TRACE MEASUREMENT RESULTmessages 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 granularitydetermined 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 sendthe START TRACE message to the BTS and no radio measurementscan be recorded in the IMSI trace record or CTR trace record.





TRFCT=20,


unit: 1 halfsecond

range: 10.. 200

default: 20 (=10 seconds)

Traff ic (handov er) contro l t imer , this parameter determines thetime between two consecutive traffic load checks which are

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

a) Traffic handover (see parameter TRFHOE in command SETHAND [BASICS]):When TRFCT expires, the BSC checks the traffic load in its cells andcompares it to the traffic handover high threshold (see parameterTRFHITH 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 sendingan LAPD O&M message SET ATTRIBUTE with the indication ‚traffichandover enabled’ ‚to the BTSM. This O&M message is the triggerfor 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 specificBTS 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 enabledin the affected BTS. If the traffic handover was enabled for a specificBTS on the previous expiry of TRFCT and the traffic load in theaffected BTS has decreased below the threshold TRFHITH, the BSCdisables the traffic handover in the affected BTS by sending an LAPDO&M message SET ATTRIBUTE with the indication ‚traffic handoverdisabled’ to the BTS.

In the BTS, the timer TRFHOT (see SET HAND [BASICS]) is used tocyclically decrease the dynamic traffic handover margin, if the traffichandover 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 is

checked by the BSC before the BTS initiates the next step of traffichandover margin reduction.

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

b) AMR compression handover (see parameter EADVCMPDCMHOin command SET HAND [BASICS]):The BSC checks the traffic load in its cells on every expiry of TRFCTand compares it to the threshold HRACTAMRT1 and HRACTAMRT2(see command SET BTS [BASICS]). If the traffic load in the cellexceeds the threshold HRACTAMRT1, the BSC enables the AMRcompression handover in the affected BTS by sending an LAPDO&M message SET ATTRIBUTE with the indication ‚AMRcompression handover enabled’ to the BTS. This indication starts the

AMR compression handover decision process in the BTS which hasthe task to handover all AMR calls currently occupying a FR TCH to aHR TCH if the quality (C/I) conditions of this call are good. For this,the BTS considers the special quality thresholds determined by the

parameters HOTHAMRCDL and HOTHAMRCUL (see SET HAND).





TRFPS=FALSE,


range: TRUE, FALSE

default: FALSE

Traff ic control packet switched , this parameter determines whetherthe 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 andEGPRS in order to spread the load by transferring some traffictowards 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, andrelated 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 establishedin 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 (seecommand CREATE PTPPKF) and NCGRESOFF, NCGTEMPOFF,NCGPENTIME (see command CREATE ADJC).

UPGRFREQ=SEC1-SEC1,


format: <uplink> - <downlink>

range: SEC1..SEC8 (both fields)

default: SEC1 (both fields)

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

During a TBF lifetime, due to variations in radio conditions, either the

BLER or the used CS/MCS coding scheme can change, leading to achange 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 thatwere initially allocated less timeslots than requested (lack ofresources) or downgraded during TBF operation by higher priorizedCS connections.





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 andappear in the DBAEM in the SET BSC command. The logical group

“[ALARMSEV]” is normally only used on the LMT but was used hereto allow a more useful grouping of the commands .


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 BTSMobject.

ALRMSEVBTSMTD=MAJOR,



default: Major

Alarm sever i ty BTSMTD , determines the alarm severity of theBTSMTD (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,


range: Minor, Major, Criticaldefault: 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 (IPlink for connetion to RC/) object

ALRMSEVLPDLM=MAJOR,

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

default: Major

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





ALRMSEVLPDLMTD=MAJOR,



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 NSVCobject.

ALRMSEVOMAL=MAJOR,



default: Major

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

ALRMSEVPCMA=MAJOR,


range: Minor, Major, Criticaldefault: 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;



default: Major

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

ALRMSEVPCMS=MAJOR,

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

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 PCUobject.

ALRMSEVPCUTD=CRITICAL,


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






default: Critical

ALRMSEVPTPPKF=MAJOR,



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 TRAUobject.

ALRMSEVTRX=MAJOR,



default: Major

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

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 andappear 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 Elementby 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.

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 andappear 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]


default: Minor

Alarm sever i ty CPEX , determines the alarm severity of the CPEXobject (the CPEX (Control Panel and External alarms device) is thecard which reports to MPCC 16 external alarms and the FAN alarmand controls the fuse and alarm panel.

ALRMSEVDISK=MAJOR,



default: Major

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

ALRMSEVDK40=MAJOR,



default: Major

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





ALRMSEVEPWR=MAJOR,



default: Major

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

ALRMSEVIXLT=MAJOR,



default: Major

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

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 MEMTobject.

ALRMSEVMPCC=MAJOR,



default: Major

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

ALRMSEVNTW=MAJOR,



default: Major

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

ALRMSEVPPCC=MAJOR,



default: Major

Alarm sever i ty PPCC , determines the alarm severity of the PPCCobject.

ALRMSEVPPCU=MINOR,



default: Min or

Alarm sever i ty PPCU , determines the alarm severity of the PPCUobject.

ALRMSEVPPLD=MINOR,



default: Min or

Alarm sever i ty PPLD , determines the alarm severity of the PPLDobject.

ALRMSEVPPXL=MINOR,



default: Major

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





ALRMSEVPPXP=MINOR,



default: Min or

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

ALRMSEVPPXT=MINOR,


range: Minor, Major, Criticaldefault: Min or

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

ALRMSEVPPXU=MINOR,



default: Min or

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

ALRMSEVPWRD=MAJOR,



default: Major

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

ALRMSEVSYNC=MAJOR,

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

default: Major

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

ALRMSEVSYNE=MAJOR,



default: Major

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

ALRMSEVTDPC=MAJOR,



default: Major

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

ALRMSEVX25A=MAJOR,



default: Major

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

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 PCMalarm detection.

ALARMT3=5;

object: LICD

unit: 5 min

range: 1-254

default: 1

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

line errors are detected within [ ALARMT3∗ 5] minutes





Creating the LAPD boards:

< Note: The PPLDs work in n+1 redundancy. This redundancy,however, is realized in a different way than for e.g. the LICDs, wherethere are special LICDs which are not numbered like the others butexplicitly defined as ‘spare’.For the PPLDs always the PPLD created last, i.e. the one with thehighest object instance number is automatically configured as spare,i.e. in operation its status is ‘hot standby’. The distribution of thecreated LAPD channels (LPDLM, LPDLS, LPDLR) is managed viaso-called LAPD pools. A LPAD pool is a functional instance thatrepresents a group of LPDLx channels that can be managed by onePPLD. Thus one PPLD can manage one LAPD pool. The distributionof the created LAPD channels takes place either automatically or canbe manually defined during the creation of the LPDLM and LPDLS(for further details please refer to the parameter LAPDPOOL in thecommands CREATE LPDLM and CREATE LPDLS). The actualassociation the PPLD to the internal LAPD pools and the createdLPDLx channels (x=M,R,S) can be interrogated by the commandGETINFO PPLD. Deletion of the PPLD is not possible as long as thesubordinate served LAPD channels are not deleted as well.

The PPLD objects m ust be deleted i f the BSC is upgraded to ahigh capaci ty BSC and is equipped w ith PPXX modules! >

CREATE PPLD:

NAME=ppld:0; Object path name .

Creating the PCU objects:

< The PCU functional object represents the packet control unitdesigned to implement GPRS/EDGE services in the SBS.The creation of a PCU implies the creation of:

- two redundant PPCU cards if NTWCARD = NTWSN16- a PPXU card (same instance number as the PCU) ifNTWCARD = 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,1 Regular Capacity BSC (PPCU)- pcun = 0,…,5 HC BSC 72 (PPXX; QTLP)- pcun = 0,…,11 HC BSC 120 (PPXX; STLP)

N3101=20,

object: PCU

range: 9-255

default: 10

recommended value: 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 settingthe Uplink State Flag (USF), N3101 is reset.. The counter isincremented for each USF for which no valid data is received. IfN3101 reaches the threshold value, the PCU considers the TBF lost,stops scheduling RLC/MAC blocks for this USF and starts timerT3169.

N3103=10,

object: PCU

range: 1-255

default: 10

This parameter defines the threshold for n ot received PACKET

CONTROL ACK as response to PACKET UPLINK ACK/NACKmessages.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. Ifthe 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: PCU

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/MACcontrol 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: PCU

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 acknowledgedwithin T1 seconds from the SGSN, the blocking procedure isrepeated at maximum NBVCBR times. After NBVCBR unsuccessfulreattempts, the BVCI status remains blocked and an O&M alarm isgenerated.

NBVCRR=3,

object: PCU

range: 1-30

default: 3

Numb er of B VC 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 atmaximum NBVCRR times. After NBVCRR unsuccessful reattempts,the BVC status shall be blocked and an O&M alarm is generated.

NBVCUR=3,

object: PCU

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 notacknowledged within T1 seconds from the SGSN, the unblocking

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

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 as the GPRS paging channel (CCCH or PCCCH if created)

or on a GPRS traffic channel. Therefore the MS only needs tomonitor one Paging Channel and it receives circuit-switched pagingseven if it is in packet transfer mode (PDCH allocated).Circuit-switched pagings for GPRS attached mobiles are routed viathe SGSN and arrive on the Gb interface together with the packet-

pagings. The Gs-interface must exist to allow paging coordination.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 pagingchannel.

As a consequence, circuit-switched pagings are ignored by the MSwhile it is in packet transfer mode.

A PBCCH shall not be created in the cell while using NMO_2!In Network Mod e of Operation III (NMO_3) the network sends

circuit-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 pagingchannels 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 SGSNvia Gb-interface to the BSC.





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

NNSVCBLKR=3,

object: PCU

range: 1-254

default: 3

This parameter specifies the Maximum num ber of retr ies

performed in the NSVC block proc edure . If the SGSN does notanswer to the b lock procedure, the procedure is retried forNNSVCBLKR times.

NNSVCRR=10,

object: PCU

range: 1-254

default: 10

This parameter specifies the Maximum number of re t riesperformed in th e NSVC reset procedure before generating anyalarm. If the SGSN does not answer to the reset procedure, the

procedure is retried infinitely but after NNSVCRR times an O&Malarm is notified.

NNSVCTSTR=10,

object: PCU

range: 1-30

default: 10

This parameter specifies the Number of con secutive 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 num ber of retr ies

performed in the NSVC unblock pr ocedure . If the SGSN does notanswer to the unb lock procedure, the procedure is retried forNNSVCUBLR times.

NRLCMAX=20,

object: PCU

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/NACKfrom the mobile. This behaviour applies for DL transfers with 1 or 2timeslots allocated.In case the DL TBF is allocated on 3 timeslots, the effective pollingdistance 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

th block) 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).

NSEI=10,

object: PCU

range: 0..65534

Network Service Element Identi f ier , this parameter represents thePCU 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 virtualconnection (BVCI) for each of these cells on the respective group ofNSVCs.

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





T1=10,

object: PCU

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.In case of timeout the procedure is repeated (refer to parametersNBVCBR and NBVCUR).

T2=10,

object: PCU

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 foracknowledgement. In case of timeout the procedure is repeated(refer to parameter NBVCRR).

T3141=5,

object: PCU

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 correctlyseized the TBF. If T3141 elapsis before a successful contentionresolution procedure is completed, the newly allocated TBF isreleased.

T3169=1,

object: PCU

unit: 1s

range: 1-30default: 1


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

parameters above) were reached.

T3172=5,

object: PCU

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: PCU

unit: 1s

range: 1-30

default: 5

T3191 , this timer defines the waiting time for reuse TFI after havingsent the last RLC block. It is started with the last DL data block sentin a TBF (Final Block Indicator=1) and stopped with the reception ofthe final PACKET DOWNLINK ACK/NACK (or PACKET CONTROL

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

T3193=4,

object: PCU

unit: 100 ms

range: 1-42

default: 4

T3193 , this timer defines the time to wait for a reuse of the TFI afterreception 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 alreadyabandoned this TFI).

T3195=1,

object: PCU

unit: 1s

range: 0..255

default: 1


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





TEMPCH=30,

object: PCU

unit: 1s

range: 1-254

default: 90


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 for1. the assignment of the proper radio resources on the air interface(PDCHs) and2. the assignment of the Abis interface subslots related to thesePDCHs.

The PPCU/PPXU always knows the number of PDCHs (i.e. radioTCHs used as PDCH) in use in a particular cell at a given time.These allocated PDTCHs can assume two main states: eithera) at least one TBF is currently assigned on the PDCH orb) 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 forthe 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 andIMMEDIATE 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 allocatedTCHs.

As long as TEMPCH is running, the allocated PDCH(s) for the“released” TBF are still regarded as allocated even if they are notused 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. In otherwords, in periods of TCH congestion the BSC immediately releasesPDCHs (TCHs activated for GPRS) with TEMPCH running if a CSTCH request is received and no other idle TCH is available forallocation. This change was implemented in BR7.0 in the scope of

CR1150 (see also parameters DGRSTRGY and CPOLICY incommand SET BSC [BASICS]).

TEMPPDT=1,

object: PCU

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 delaytime for the release of an allocated PDT with subframe counter > 0 ifthe 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 for1. the assignment of the proper radio resources on the air interface(PDCHs) and2. 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 ofthe PDCHs has five 16kbit/s Abis subslots allocated – in total 10PDTs 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 ofthe previously 5 Abis subslots (and PDTs) are necessary to transportthe user data for each PDCH. TEMPPDT is started at that momentfor 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.

TF1=5,

object: PCU

unit: 1s

range: 2-9

default: 9

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 periodallowed between two consecutive FLOW-CONTROL PDUs..

THPROXT=500..50..550,

object: PCU

format: thproxt1-thproxt2-thproxt3

unit: thproxt1: 1ms

thproxt2: 1s

thproxt3: 1s

range: thproxt1: 10..999

thproxt2: 1..100

thproxt3: 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” fordevelopment and system test purposes in order to implementadditional 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: PCU

range: 0..2000

default: 587

Threshold switch up l ink balanced , this parameter indicates the

threshold that the field ‘RLC_Octet_Count’ (part of the ChannelRequest 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; total4) 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.

TIMEDTBFREL=15

object: PCU 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 fastersetup of new UL TBFs (as concurrent TBFs).

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 procedu re . 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 (parameterNNSVCRR).





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. Ifno acknowledge arrives in time (TNSCVPTST), the test procedure isrepeated (NNSVCTSTR).

TSULBAL=20,

object: PCU

unit: 1s ???

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), onlya single timeslot was allocated in UL. If however the resulting UL TBFlasts longer than TSULBAL, the system activates the ‘uplink priority’condition and upgrades the UL TBF resources if applicable.Please see also parameter THSULBAL.

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 parameterdetermines - converted to binary format - the bits of the PCM30‘Service Word’ (or ‘Non-frame alignment signal’ NFAS). The entereddecimal 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 PCMlink functions (bit 1 is the ‘Si’ bit and used for CRC, bit 2 has a fixedvalue of ‘1’ and bit 3 is the A-bit for urgent alarms). If CRC is notused, 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 checksystems CRC4 (for PCM30 lines) respectively CRC6 (for PCM24links) 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 forlayer 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 timeslotis 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 which

indicates '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 signalinginformation 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 immediatelychanges the 'receive' direction to the other LI port. Moreover, theBTSEs start to transmit 'failure' patterns via the L1CTS. If a linkinterruption occurs on a PCM-link between the BTSEs normally a fastalignment 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 directlyconnected to the BSC normally the direction switch is executedwithout 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 doneeither by layer 2 or layer 1 error detection functions. For those PCMlinks 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 BTSE

0

LIport

2

LIport

1

BTSEn

LIport

1 LI

port2

BSC

QTLPport

B

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 STARand 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 avoidlonger ‘0’ periods by automatic insertion of so-called ‘violation’ bits ifa 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 signaledusing 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_TRUNKmode 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 orSIMPLEXB), in this case the remaining port remains unused.

b) One PCM link can be connected to port A and another PCM linkcan 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 parameterdetermines - 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 reservedfor 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 ifa longer ‘0’ period is detected.

CRC=TRUE,

object: PCMS

range: TRUE, FALSE

default: FALSE

CRC enabled , determines whether the cyclic redundancy checksystems 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 physicalline 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 andsignaling 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 signaledusing the 5th bit of the NFAS signal (Service Word in timeslot 0 of thePCM system).





PCML=1-1,

object: PCMS

range: licd-no. 0..8


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: PCMS

range: 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 portonly (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 TRANMTXwhich 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 byconfiguration commands) which depends on the types and number ofTCH pools created on the A-interface.a) The value NOT_COMPATIBLE_WITH_CROSS_CONNECT valuecan be chosen when no cross-connectors between BSC and TRAUare 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 basicmapping 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 ifthe 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 dependingon 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 allother 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 Matr ix type 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





ETFO=FALSE,

object: TRAU

range: TRUE, FALSE

default: FALSE


Enable Tandem Free Operation , this flag allows to enable ordisable the TFO mode. TFO is a feature that improves the speechquality of mobile-to-mobile speech calls by avoiding a doubletranscoding 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 speech

coding algorithms such as Full Rate, Half Rate or Enhanced FullRate. The main task of the TRAU (for speech calls) is the transcodingof 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 involvedTRAUs - at the expense of the speech quality. If TFO is enabled andall preconditions are fulfilled the uplink TRAU frames are no longerdecoded 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 MSCand 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 byreplacing the LSB in every 16 consecutive PCM samples. This willresult in a 0.5 kbit/s signalling. The 0.5 kbits/s are regularly stolen ofthe64 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 similarto 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 carriedby 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) for8 kbits/s traffic channels and 320 bits (20msec) for 16 kbits/s trafficchannels.

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 andloaded in the TRAU. If it is not available the TRAU automaticallyrequests a download of this SW version from the BSC.

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 byits unique symbolic name. It can be optionally used for the networkelement 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 elementidentity verification during the alignment procedure. The newapproach using the Sales Unique Name in addition to an individuallyconfigurable TEI allows a much higher flexibility in the allocation ofthe 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. notchangeable) correspondence to the relative object number of theLPDLS resp. TRAU and was the only criteria used for the networkelement 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 specificidentity can optionally be used to unambiguously identify the TRAUduring the alignment procedure: the Sales Unique Name (seecommand CREATE TRAU, parameter SALUNAME).

TSYNC=1000;

object: TRAU

unit: 10ms

range: 10..10000default: 1000

TSYNC, this timer is used by the TRAU to supervise time-out ofTRAU frame handling. The TRAU starts this timer if 3 uplink TRAUframes 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 TRAUreports a transcoder failure warning to the BSC and the TRAU issuesthe warning DSP TSYNCEXPIRED.





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..13

default: (LAPD pool is assigned

by the BSC automatically)

LAPD pool , this parameter defines the LAPDPOOL the LPDLM shallbe assigned to. A “ LAPD Pool “ is a logical instance whichrepresents a group of LAPD channels (LPDLM, LPDLR, LPDLS) thatcan be managed by one PPLD.

Each PPLD is responsible for one LAPD pool, thus the number ofavailable LAPD pools is determined by the number of createdPPLDs: If n PPLDs were created, n LAPD pools are available forassignment of created LPDLx channels. The relation between thecreated LAPD pools and the serving PPLD is variable and managedinternally by the BSC (can be interrogated by the commandGETINFO PLLD).

If the PPXL are used in a high capacity BSC, the parameterLAPDPOOL assumes the meaning of "primary PPXL" (i.e. themodule no. of the PPXL where the LAPD must work if both PPXL arein service). If case of NTWSN16 or NTWSN64 the LAPDPOOL valuedoes not have any relationship with the instance of the physicalPPLDs equipped.

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 parameterdetermines - converted to binary format - the bits of the PCM30‘Service Word’ (or ‘Non-frame alignment signal’ NFAS). The entereddecimal value, converted to binary, determines the bit values in

selected 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 PCMlink functions (bit 1 is the ‘Si’ bit and used for CRC, bit 2 has a fixedvalue of ‘1’ and bit 3 is the A-bit for urgent alarms). If CRC is notused, the value of BAF also determines the value of bit 1 (Si bit).





BER=E10_3,

object: PCMA

range: 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 avoidlonger ‘0’ periods by automatic insertion of so-called ‘violation’ bits ifa longer ‘0’ period is detected.

CRC=TRUE,

object: PCMA

range: TRUE, FALSE

default: FALSE

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

DEFPOOLTYP=NOT_DEFINED,

object: PCMA

range: NOT_DEFINED

POOL_1..POOL_13,

POOL_15.. POOL_35POOL_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 poolassigned to every TSLA of the given PCMA. The different values forthe pooling type are predefined and represent a certain combinationof different ‘supported coding types’ for speech and data. For the

different 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 trafficconnection. 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) andEPOOL (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 ifthe 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 bysome network operators because this setting was found the mostsuitable 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 physicalconnection 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 withoutany 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 notlimited 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 parameterdetermines - converted to binary format - the bits of the PCM30‘Service Word’ (or ‘Non-frame alignment signal’ NFAS). The entereddecimal 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 PCMlink functions (bit 1 is the ‘Si’ bit and used for CRC, bit 2 has a fixedvalue of ‘1’ and bit 3 is the A-bit for urgent alarms). If CRC is notused, 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 checksystems 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 avoidlonger ‘0’ periods by automatic insertion of so-called ‘violation’ bits ifa 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: PCMG

range: TRUE, FALSE

default: FALSE


PCML=0-0-TRUNKA,

object: PCMGrange: licd-no. 0..8


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 redundancyis 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 possible

to 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 itwill be possible to set the PCMS in duplex in the future, withoutdeleting/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 wastedwithout 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 RelayLink connection can be realized via the A interface (PCMA) or directlyto SGSN via a PCMG. In case of A interface connection the 64 kbit/s

time slot are reserved on the PCMS and handled as transparentchannel 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 Relaynetwork 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 thata single PCU may be connected to the SGSN via both PCMA andPCMG 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,

max. 16 timeslots per PCU

if PPCU 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), ithas to be considered that the timeslots entered for GTS are alsoreserved for GPRS on the Asub. This again leads to the blocking ofthe 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 itis 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 Relaylinks comprising more than 1 timeslots may be corrupted due todifferent delays applied to the single timeslots. The Siemens MSCallows to route only single timeslot FRLs through its switchingnetwork!

N391=6,

object: FRL

range: 1-255

default: 6

N391 , this parameter represents the polling cycle. After N expiries ofT391 a STATUS-ENQUIRY (STAE) message requesting a FullStatus 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 putin '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 PCUobject 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 lowerthan 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 windowfor the congestion detection. If the number of frames coming from

SGSN containing congestion is equal or greater than the number offrames 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 forcongestion abatement. After a congestion notification, no othernotifications 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 objectrepresent 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 parameterrepresents 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: FRLNand 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..

ABISHRACTTHR=60,

object: BTSM

unit: 1 %

range: 0..100

default: 60

BTSM Abis TCH load threshold for HR activat ion, this parameteris the equivalent of the parameter HRACTT1 (see commandCREATE BTS [BASICS]) and defines an Abis traffic load thresholdwhich 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 loadc) AMR compression handover due to Abis TCH load

For all these features, the BSC calculates an Abis TCH traffic load forthe Abis pool assigned to the BTSM. This ‘Abis pool’ is representedby 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 describedfor each of the involved features:

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

parameter EHRACT), ABISHRACTTHR defines a BTSM Abis trafficload 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 forthe BTSM. For the feature CLDAHR the BSC calculates the Abistraffic load as follows

Attention:

- Generally a TCH\F is counted as 2, a TCH\H is counted as 1!

- * The “no. of Abis pool 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) 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 the command SETBSC [BASICS]) has an influence on the Abis traffic load calculation: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 orDOWNGRADE_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 DGRSTRGY parameter, as these subslots are inany case immediately preempted if a CS TCH request meets a TCH congestionsituation.

If the calculated Abis TCH traffic load of the BTSM exceeds the percentage defined by ABISHRACTTHR, all incoming calls orincoming 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

BTSM Abis traffic load [%] = ∗ 100no. of Abis pool TCH not available for CS allocation *

no. of configured Abis pool TCHs





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). Forfurther details please refer to the parameter EHRACT.

Note: if the parameter EHRACTAMR (see command SET BSC) is setto TRUE, the HR activation also goes for AMR calls.

b) Enhanced Pairing of half rate TCH due to Abis TCH loadThe feature “Enhanced Pairing of TCH/H” (see parameter EPA incommand SET BSC [BASICS]) transfers HR calls that currentlyoccupy one HR subslot of a DR TCH (while the other subslot is stillidle) in such a way that as many HR calls as possible share one DualRate TCH with another HR call. The enhanced pairing intracellhandover is controlled exclusively by the BSC and is only triggered ifeither the percentage (within the pool of radio TCHs) of radio DRTCHs or/and radio FR TCHs in usage state “idle” has dropped belowa definable threshold (see parameter HRACTT1) or/and the

percentage (within the pool of Abis TCHs) of Abis DR TCHs or/andFR TCHs in usage state “idle” has dropped below a definablethreshold. For enhanced pairing due to Abis TCH load, this thresholdis based on the parameter ABISHRACTTHR: intracell handovers dueto enhanced pairing are triggered if the following BTSM Abis pooltraffic load condition is fulfilled:

Attention:- (*) A dual rate TCH is only considered as ‚idle’, if both subslots are idle.

- (**) For the ‘number of TCH configured in Abis pool’ each FR TCH and DR TCH iscounted as ‘1’!

- The GPRS downgrade strategy (see parameter DGRSTRGY in the command SETBSC [BASICS]) has an influence on the Abis traffic load calculation: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 orDOWNGRADE_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 DGRSTRGY parameter, as these subslots are inany case immediately preempted if a CS TCH request meets a TCH congestionsituation.

For further details please refer to the parameter EPA (in commandSET BSC).

c) AMR compression handover due to Abis TCH load On every expiry of the timer TRFCT (see SET BSC) the BSC checksthe current radio TCH load in its cells (see parameterHRACTAMRT1) and the current Abis TCH traffic load of its BTSMsand compares it to the threshold ABISHRACTTHR. For AMR

compression handover (see parameter EADVCMPDCMHO incommand SET HAND [BASICS]) the BSC calculates the BTSM Abistraffic 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


- The GPRS downgrade strategy (see parameter DGRSTRGY in the command SET

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

no. of TCH configured in the Abis pool**100% - ABISHRACTTHR[%]

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

no. of Abis pool TCH in state unlocked/enabled





BSC [BASICS]) has an influence on the Abis traffic load calculation: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 orDOWNGRADE_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 a

particular PDCH, the associated Abis subslots are regarded as ‘idle’ in any case, nomatter which values are set for the DGRSTRGY parameter, as these subslots are inany case immediately preempted if a CS TCH request meets a TCH congestionsituation.

If the Abis traffic load of the BTSM exceeds the threshold ABISHRACTTHR, the BSC enables the AMR compression handoverin the BTSs subordinate to the affected BTSM by sending a SET

ATTRIBUTE message with the appropriate indications to the BTSs.This message starts the AMR compression handover decision

process in the BTS which has the task to hand over all AMR callscurrently occupying a FR TCH to a HR TCH if the quality (C/I)conditions of this call are suitably good. The quality criteria for the

AMR compression handover are defined by the C/I thresholdsHOTHAMRCDL and HOTHAMRCUL (see 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) andspecifies the BTSM Abis traffic load threshold for enabling of traffichandover in the BTSM. For this feature, the BSC calculates a currentBTSM 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:





- The GPRS downgrade strategy (see parameter DGRSTRGY in command SET BSC[BASICS]) has an influence on the Abis traffic load calculation:a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all Abis TCHs which arecurrently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like any other AbisTCH which is currently seized by a CS call.

b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST orDOWNGRADE_HSCSD_FIRST, then all Abis TCHs which are currently busy due toGPRS traffic (PDCH) are considered as ‘idle’.- If the timer TEMPCH (see command CREATE PCU) is running for a particularTCH/PDCH, the radio TCH as well as the associated Abis TCH is regarded as ‘idle’ inany case, no matter which values is set for the DGRSTRGY parameter, as these TCHsare in any case immediately preempted if a CS TCH request meets a TCH congestionsituation.

The BSC cyclically checks the BTSM Abis traffic load (controlled bythe 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 ‚HandoverThresholds 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/andthe Abis traffic load of the BTSM are still above their thresholdTRFHITH resp. ABISTRFHITHR, no further message is sent to theBTS and the traffic handover remains enabled in the affected BTSs. Ifthe 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 have

dropped below the corresponding thresholds, the BSC disables thetraffic handover in the affected BTSs by sending another LAPD O&Mmessage SET ATTRIBUTE with the ‘traffic handover disabled’indication to the BTSM.

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

no. of Abis pool TCH in state unlocked/enabled





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 incomingtraffic handovers. The traffic load of a cell is calculated as follows:

Attention:




busy) is counted as 1.- The GPRS downgrade strategy (see parameter DGRSTRGY in command SET BSC[BASICS]) has an influence on the Abis traffic load calculation:a) If DGRSTRGY indicates ‘GPRS downgrade not allowed’ (i.e.DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all Abis TCHs which arecurrently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like any other AbisTCH which is currently seized by a CS call.b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e.DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST orDOWNGRADE_HSCSD_FIRST, then all Abis TCHs which are currently busy due toGPRS traffic (PDCH) are considered as ‘idle’.- If the timer TEMPCH (see command CREATE PCU) is running for a particularTCH/PDCH, the radio TCH as well as the associated Abis TCH is regarded as ‘idle’ inany case, no matter which values is set for the DGRSTRGY parameter, as these TCHs

are in any case immediately preempted if a CS TCH request meets a TCH congestionsituation.

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 trafficload 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. Ifnone of the target cells has a suitable load situation (i.e. if the celltraffic load > TRFLTH and/or Abis TCH load > ABISTRFLTHR ) the

HCI does not lead to any successful handover completion - the nexthandover attempt HCI is then sent after expiry of TRFHOT (see SETHAND), 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 loadof that BTSM has exceeded the threshold ABISTRFLTHR. Thismeans that it does not make any difference whether the originatingcell of the traffic handover belongs to the same BTSM or not.

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 ofbreakdown 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 HWserving those TRXs which have been explicitly declared a 'Memberof 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 oftime when the battery runs out of current (BTSE power off).Note: BTSE emergency configuration can also be entered as a resultof excessive shelter temperature in BS61 BTSEs (see explanation of

parameter MOEC (CREATE TRX)).

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

no. of Abis TCH in state unlocked/enabled





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 ofthe BTSE primary power supply if a battery backup is available in theBTSE. The timer EMT2 is started when the BTSE enters the 'BTSEemergency 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 ofthe 'BTSE zero carrier configuration' is to keep the central controlmodules 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 notadministrable.

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 SWversion 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 firstload level thresholds of the BTSE Radio Signalling links (LPDLRs). Itconsists of two fields: The fields of this attribute of type sequenceare:- firstLevelUpperThresholdif the signalling traffic exceeds this threshold the BTSE suspendssending MEASUREMENT RESULT (MEASUREMENT REPORT)messages on the Abis.- firstLevelLowerThresholdif the signalling traffic drops below this threshold the BTSE resumessending MEASUREMENT RESULT (MEASUREMENT REPORT)messages on the Abis.

The MEASUREMENT RESULT resp. MEASUREMENT REPORTmessages are neither necessary for call processing nor for

performance measurements. The sending of these messages can beoptionally enabled using the parameter RADIOMR (see commandCREATE/SET TRX) for test or monitoring purposes. If thesemessages are sent, they lead to a drastic increase of the uplink loadon the LPDLR links. For this reason they are suspended in case ofLAPD overload.

Note:- If IMSI Tracing (see command CREATE TRACE) or Cell TrafficRecording (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 TRACEMEASUREMENT 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 SETBSC [BASICS]).- The BTSE LAPD Overload thresholds are only used by BTSEs ofthe 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 verticalallocation 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 ofidle 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 PCUstops 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 furtherupgrading 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 firstupgrading a running TBF and then pre-empting it again to serve theCS call. ThresholdIdleAbisSU=0 means that the upgrade of TBFresources 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


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 (see

below) 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 byBTSEs 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 generallyhigher signal delay must be particularly taken into account bythe 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 sentwithout 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 BTSEas well. This is done by the parameter ABISLKSAT in the commandSET BTSM (at the BTSE LMT). The effect is the same as describedabove - just for the opposite direction.- Since the implementation of CR2716 in BR7.0 (TDPC patchT1340148) the setting LPDLMSAT=TRUE has an effect on call

processing: To reduce the delay between the CHANNEL REQUESTand the IMMEDIATE ASSIGNMENT COMMAND messages, the BSCsends the IMMEDIATE ASSIGNMENT message immediately aftersending the CHANNEL ACTIVATION message, without waiting forthe 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 expectedsuccess 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 message

can be sent. This approach drastically reduces the RACHretransmissions due to delayed IMMEDIATE ASSIGNMENT and thusavoids unnecessary load on the SDCCHs.- If an Abis is realized via satellite link (or has a considerablyincreased delay due to other transmission equipment) it is stronglyrecommended 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 urgentlyrecommended to configure multiple SDCCH channels on differentTRXs. This is necessary because the Abis LAPD transmit queues inthe BTS are managed per TRX(TEI), i.e. each TRX (TEI) has an own

transmit queue. As the biggest percentage of all signalling activitiesin a cell are processed via the SDCCHs, it is recommended, to avoidan 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’ willconsiderably 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 ASUBISATin command SET BSC[BASICS]) can be configured as satellite link.However, only one of the mentioned interfaces should be configuredas satellite link at the same time, because multiple satellite links





within a BSS may cause an overall message and procedure delaythat might lead to expiry of procedure supervision timers that arenormally adapted to the propagation delay of terrestrial signallinglinks or at least to only one satellite link in the path. Although multiplesatellite links are not officially tested and released, the BSCcommand interpreter and DBAEM do not perform any checks toavoid multiple satellite links - it is up to the operator to follow this rule.

OMLAPDRT=30,

object: BTSM

unit: 1s

range: 3-300

default: 30

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. Call processing activity (i.e. BCCHactive) on the BTSE will not be blocked as long as this timer runs.When the timer expires the BTSE call processing is blocked andfunctional related Managed Objects are deleted. In this case a fullalignment is necessary to put the BTSE in service again after the

Abis link has come up again.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. On linkreestablishment the BTSE forces the BSC to perform a full Abisalignment if one of the two timers has expired. If none of the twotimers expires, the BSC performs a ‘Short Abis Alignment’.

Application: The timers SHLAPDIT and OMLAPDRT are relevant for

a) LAPD interruption due to PPLD 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. PCMlink 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 fullalignment is avoided if the link comes up before expiry of SHLAPDIT.Notes:- OMLAPDRT should always be greater than SHLAPDIT since a fastalignment (SHLAPDIT not yet expired when the layer 2 comes up)only makes sense if call processing has not been blocked by theexpiry of OMLAPDRT before!- 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, PCMCON0indicates 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 mustbe 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 BPORTobject must be previously created by means of the CREATEBPORT command.

- Please see also command CREATE SUBTSLB.

PCMCON1=<NULL>,

object: BTSM


portNumber1


PCMB_nnn

portNumber1:

PORT_mdefault: <NULL>

PCM connection 1 , this attribute indicates the first auxiliary PCMconnection for the given BTSM, i.e. it indicates to which BTSM port itis connected. Depending on the LPDLM configuration two casesmust be distinguished:a) If only one LPDLM is configured for the BTSM, PCMCON1indicates which PCMB does not carry the LPDLM.b) If more than one LPDLM is configured for the BTSM, PCMCON1

indicates which PCMB does not carry LPDLM:0.The port numbers must be selected in correspondence with the HWof the BTSE (please refer to the ‘Notes’ in the description ofPCMCON0, see above).

PCMCON2=<NULL>,

object: BTSM


portNumber2


PCMB_nnn

portNumber2:

PORT_m

default: <NULL>

PCM connection 2 , this attribute indicates the second auxiliary PCMconnection for the given BTSM, i.e. it indicates to which BTSM port itis connected.

The port numbers must be selected in correspondence with the HWof the BTSE (please refer to the ‘Notes’ in the description ofPCMCON0, see above).

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 itis connected.

The port numbers must be selected in correspondence with the HWof the BTSE (please refer to the ‘Notes’ in the description ofPCMCON0, see above).





SALUNAME=”BSC1BTSE0”,

object: BTSM


(11 characters)

in quotation marks


Sales Uniqu e Name , this attribute defines every Network Element byits unique symbolic name. It can be optionally used for the networkelement 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 elementidentity verification during the alignment procedure. The newapproach using the Sales Unique Name in addition to an individually

configurable TEI allows a much higher flexibility in the allocation ofthe BTSEs to the BSCs (with minimization of efforts in case of BTSEswap) without loss of safety.

SHLAPDIT=5,

object: BTSM

unit: 1s

range: 3-20

default: 15

Short LAPD interruption timer , this parameter represents a BSCtimer 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 actual value ofSHLAPDIT (<entered value> + 30s) all calls in the affected BTSE arereleased and a ‘full alignment’ is performed after link recovery. If theLAPD link comes up again before the timer expires only a ‘fastalignment’ procedure is started. ‘Fast alignment’ is a subset of the‘full alignment’ and comprises only the state alignment and the alarmalignment, but not the creation of functional objects. Please see alsothe explanation for OMLAPDRT.

This timer is also used for supervision of RSL. If an RSL fails forlonger than this time limit (O&M link survives) only the channels ofthe affected TRX are released.Important Note:

The actu al value of the SHLAPDIT is <entered value> + 30 s !

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:- secondLevelUpperThresholdif the signalling traffic overcomes this threshold the BTSE starts the

periodic sending of LAPD OVERLOAD messages.- secondLevelLowerThresholdif 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 andindicate the LAPD overload per TRX. The time period between twoconsecutive LAPD OVERLOAD indication messages is determinedby the parameter LAPDOVLT.

Notes:- Further parameters related to LAPD overload are FLAPDOVLTH,LAPDOVLT (CREATE BTSM) and DLAPOVL (see command SETBSC [BASICS]).- The BTSE LAPD Overload thresholds are only used by BTSEs ofthe generation BTSplus.- If the exceeding of SLAPDOVLTH triggers the sending of LAPDOVERLOAD messages towards the BSC and the parameterDLAPDOVL (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 forthe 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 ofthe 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 TEIcan 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 BTSMcommand 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 optionallybe used to unambiguously identify the BTSE during the alignment:the Sales Unique Name (see parameter SALUNAME).





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 usedas 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 particularTRX.

The distinction between LPDLM messages and LPDLR radiosignalling (RSL) messages is based on the LAPD layer 2 addressingscheme which uses the SAPI (Service Access Point Identifier) andTEI (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 createdfor a particular BTSM also carries the LPDLR signalling informationrelated to the TRXs subordinate to the BTSM and the associatedBTSs. 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 CREATETRX).

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 avoidfrequent 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 ChannelControl) 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-BCCHTRX. The BSC just registers the layer 2 connection setup by the BTSE androutes the messages adressed to a particluar TRX to the associatedLPDLM timeslot.

After a failure of all LPDLMs the BSC decides which of the configuredLPDLMs 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 commandCREATE LAPDLE.

LAPDPOOL=0;

object: LPDLM

range: 0..13 (if PPLD is used)

0..1 (if PPXL is used)

default: (LAPD pool is assigned

by the BSC automatically)

LAPD pool , this parameter defines the LAPDPOOL the LPDLM shallbe assigned to. A “ LAPD Pool “ is a logical instance whichrepresents a group of LAPD channels (LPDLM, LPDLR, LPDLS) thatcan be managed by one PPLD or PPXL

Different distribution principles apply in case of PPLD and PPXL asfollows:

Meaning of LAPDPOOL for configurat ion w ith PPLD

Each PPLD is responsible for one LAPD pool, thus the number ofavailable LAPD pools is determined by the number of createdPPLDs: If n PPLDs were created, n LAPD pools are available forassignment of created LPDLx channels. The relation between thecreated LAPD pools and the serving PPLD is variable and managedinternally by the BSC (can be interrogated by the commandGETINFO PLLD). The following example configuration may illustratethe principle:

Basically, if the LAPDPOOL parameter is skipped during the LAPDchannel creation, the BSC automatically assigns the LPDLx to one ofthe existing LAPD pools by an internal distribution algorithm (this was

the only possible way in releases < BR6.0). This has thedisadvantage that the created LPDLx channels might not bedistributed over all equipped PPLDs (some of them might remain instate “ cold standby “ which means that the PPLD is neither servingany LPDLx channels nor the spare PPLD.) With the parameterLAPDPOOL the operator has the possibility to control the distributionof LAPD channels among the PPLDs and to ensure an evendistribution of the LPDLx over all equipped PPLDs, achieving aminimum impact on the LAPD channels in case of PPLD failure.In this case (i.e. with NTWCARD=NTWSN16, see command SETBSC [BASICS]) the LAPDPOOL value does not have any relationshipwith the instance of the physical PPLDs equipped.

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 parameterLAPDPOOL 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 remainingPPXL board immediately takes over the LAPD channels of the failedone. 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).

LPDLS:0

PPLD:0 PPLD:1 PPLD:13

LPDLS:1

LPDLM:5LPDLM:4

LAPDPOOL 13 LAPDPOOL 4. . . .

. . . .

. . . .

BTSM:4/../LPDLR:0

BTSM:2/../LPDLR:0

LPDLM:0

LAPDPOOL 0

BTSM:0/../LPDLR:0

BTSM:1/../LPDLR:0

LPDLS:3

BTSM:5/../LPDLR:0

BTSM:6/../LPDLR:0

. . . . . . . .





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 EDGErespectively EGPRS and the introduction of the additional highcoding schemes (CS3 and CS4, see parameters CSCH3CSH4SUPin 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 of16kbit/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 sufficientand efficient, as it would require an Abis configuration according tothe highest possible data rates. To avoid a waste of Abis TCHresources, 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 particularterrestrial 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 calledSUBTSLB (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 mustbe 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 switchingmatrix functionality which allows an individual throughconnection of

Abis TCH resources towards Um radio TCH resources. The switchingfunctionality, 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 HRsubslots a particular radio timeslot can only be interconnected to thetwo associated HR subslots of a particular Abis timeslot, i.e. a HRTCH 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, incominghandovers 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 ACTIVATIONmessage which then performs the necessary throughconnection.

The amount of allocated 16 kbit/s Abis resources per radio timeslotdepends on several factors, first of all the service type. The next tableshows how, depending on the service type, a single Um radio TCHmust 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) ofconcatenated PCU frames depends on the coding scheme used forradio block transmission.

In case of a GPRS/EGPRS connection the BSC can 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 ionto the BTS. (whic h mess age???)

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 codingscheme, e.g. MCS9, an additional Abis resource is dynamicallyallocated. In contrast, if the Link Adaptation algorithm leads to a lowercoding scheme, e.g. MCS6, superfluous Abis resources are released.In order to avoid continuous sequences of allocation and release, anyrelease 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 existingPCMB. 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 assignedto) a particular BTSM make up the pool of Abis TCH resources thatcan be used to serve TCH requests (CS calls, GPRS calls, incominghandovers 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 LPDLRsignaling) is not call processing oriented, i.e. there is no whicheverrelation 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 ‘controlLAPD’) is to guarantee a suitable O&M supervision of the availabilityof the Abis TCH resources belonging to the Abis subpool. In otherwords, 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 ofthe 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 LPDLMNin 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 assignedto the same BTSM and the same LPDLM. The association of a

particular SUBTSLB object to a BTSM and the LPDLM is implicitlydefined 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 betteravailabilty resp. failure safety of the Abis pool.

The following example configuration may illustrate a typicalconfiguration:... (two BTSEs in multidrop, with different Abis subpoolsfor different BTSMs distributed over different PCMBs).





The following further notes on properties and relation of Abis poolsand Abis subpools are important for consideration:- Different Abis subpools can be defined on the same PCMB line.These different Abis subpools may belong to different BTSMs (i.e.

Abis pools, which is the most useful case!) as well as to the same

BTSM. In any case each subpool is associated to an own separateLPDLM channel.- Abis subpools can be freely distributed over all PCMB lines thatbelong to a BTSM (see parameters PCMCON0..PCMCON3), at leastone subpool must be created per PCMB line.- The Abis subslots allocated (interconnected) to a Um radio TCHmay be distributed over different Abis subpools and consequentlyover different PCM lines. It is not necessary to guarantee that thesubslots are adjacent.- Different Abis pools and Abis subpools must not overlap.

With the common pool concept any radio timeslot is dynamicallyassociated to an appropriate number of Abis resources from the Abis

pool.

Guaranteed minim um p ercentage of Abis p ool TCHs per BTS

To avoid a stop of call handling due to excessive traffic volumedemands of other BTSs of the same BTSM and a resulting lack of

Abis resources for a particular BTS, the BSC considers the parameter GUARMABIS (see command command CREATE BTS[BASICS]). during TCH allocation. This parameter specifies theminimum percentage of ‘in service’ Abis subslots (i.e. SUBTSLBs instate ‘unlocked/enabled’) of the Abis pool that shall in any case bekept available for allocation for this cell (BTS).

BTSM:0

BTSM:0 subpool 1

BTS:0

BTS:1

BTS:2

CORE

BTSM:1

BTS:0

BTS:1

BTS:2

C

OR

E

Abis pool BTSM:1

Abis pool BTSM:1 Abis pool BTSM:0

BTSM:0 subpool 2

BTSM:1 subpool 1

BTSM:1 subpool 1

L*L*

L*

L* = associated LAPD(does not have to be directlyadjacent to the pool TCHs, itmust only be on the samePCMB)

L*

B

SC





CREATE SUBTSLB:

NAME=PCMB:0/TSLB:2/SUBTSLB:0,

Object path name .

ASSLAPD=BTSM:0/LPDLM:0,

object: SUBTSLBformat: object instance path name of

the associated LPDLM,

BTSM:n/LPDLM:m

Associa ted LAPD , this parameter defines the so-called ‘associatedLAPD channel’ of a particular SUBTSLB (Abis TCH). The valuesentered for this parameter consist of the object path name of an

existing LPDLM. As each LPDLM is an object subordinate a BTSM,the path name also identifies a BTSM (BTSM:n/LPDLM:m).

The ASSLAPD parameter indicates the relation of a SUBTSLB objectto a BTSM ‘Abis pool’ and an ‘Abis subpool’ in the following way:

1) All SUBTSLBs that contain the same BTSM no. in the ASSLAPD path name, make up the ‘Abis pool’ of the BTSM , i.e. theseSUBTSLBs are the Abis TCH resources that can be dynamicallyused for CS and GPRS TCH requests for cells (BTSs) belonging tothat BTSM.

2) All SUBTSLBs that contain the same BTSM no. and the sameLPDLM no. in the ASSLAPD path name, make up one ‘Abis subpool’for the BTSM , i.e. these SUBTSLBs are that part of the BTSM AbisTCH resources which are created on the same PCMB and whoseavailability is supervised with the help of the same LPDLM.

For further details pleas refer to the explanations given in thecommand introdcution (see above).





! 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 andappear in the DBAEM in the CREATE BTS command. The logicalgroup “[BASICS]” is normally only used on the LMT but was usedhere 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 permanentlyadapted 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 thatrepresents 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 AMRspeech 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 FRshall consist of only 3 AMR CODECs, then AMRFRC4 must be set to<NULL>, if it shall consist of only 2 CODECs, then AMRFRC3 mustbe set to <NULL> and so on. For AMRFRC1 the value <NULL> is notallowed, 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/s

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 regularmeasurement reporting and the BTS derives quality values from theuplink BER measurements. Depending on the results of these qualitymeasurements, 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 mode

depending 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 up l 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 SignallingThe 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 TRAUframe format, each change of the AMR CODEC means a change ofthe 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 the

TRAU.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 CMRis to request a CODEC that shall be used for the downlink direction. IfDTX 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 CMRrequest 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 purpose





is to instruct the TRAU and MS to use a specifc CODEC. CMCs forthe downl ink direction are sent from BTS to the TRAU within uplinkTRAU frames to request the TRAU frame type in correspondencewith the CODEC required by the CMR from the AMR MS. The CMCis sent to the TRAU after an averaging process in the BTS (see

parameter AMRACMRDL in command SET HAND [BASICS]): Thesize of the associated ‘averaging window’ for this process is definedin CODEC Mode Requests (CMRs), i.e. the BTS only instructs the

TRAU to change the current downlink CODEC mode, if a sufficientnumber 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 currentlyused by the sending side, as the same CODEC must be used tocorrectly decode the received speech signal resp. TRAU frame. TheBTS inserts CMIs into downlink bursts according to the CODECsignaled from the TRAU and into uplink TRAU frames according to

the CODEC signaled by the MS. The TRAU sets the CMI for thedownlink TRAU frames as requested by the CMC from the BTS. TheMS sets the CMI in the uplink speech frames as requested by theCMC received from the BTS.

Summary: By the CMR the MS indicates which CODEC it desires, bythe CMC the BTS commands which CODEC shall be used by TRAUand 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 duringcall 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 HalfRate” (see parameter EHRACTAMR in command SET BSC[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 AMRCODEC, i.e. the AMR CODEC that shall be used in the beginning ofthe call (this information is also included in the ASSIGNMENTCOMMAND and CHANNEL ACTIVATION messages). Of course, theinitial CODEC is then immediately adapted by the MS and BTSdepending on the current radio conditions.

Interaction of AMR link adaptation and frequency hoppingThe 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 canalso be set in the FHSY object (see command CREATE FHSY). TheBTS uses these AMR parameters from the FHSY object for thedownlink CODEC mode adaptation if frequency hopping is active inthe BTS (for the uplink CODEC mode adaptation there is nodifference between hopping active or deactivated). In this context it isnot relevant, whether frequency hopping is configured or not,Frequency hopping can be temporarily deactivated in the BTS (e.g. in





case of baseband hopping with TRX failure), even if the databaseflag for frequency hopping (see parameter HOPP in command)indicates that hopping is enabled. The FHSY parameters for AMRare only considered for a particular AMR call if hopping is currentlyactive for this call.

Handover and Power Control for AMR CallsThe Handover and Power Control Decision for AMR calls is basicallythe 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 Controldecision due to quality. For further details, please refer to the

parameters HOLTHQAMRDL (SET HAND [BASICS]) andLOWTQAMRDL (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 BSCdecision (Cell load dependent activation of HR). As opposed to non-

AMR calls, special intracell handovers are implemented for AMRcalls, that allow a switchover from an AMR HR TCH to an AMR FRTCH and vice versa.

For further details about AMR compression and AMR decompressionhandover please refer to parameter EADVCMPDCMHO in commandSET HAND [BASICS].

Notes:- To support AMR, the involved TRAU must be equipped with TRACV5 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 andPOOLTYP in command SET TSLA).- During Inter-BSC handover, the originating BSC informs the targetBSC 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 HANDOVERREQUEST 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 onlyone CODEC (defined by AMRFRC1).



Note: An equivalent parameter to this one is also included in theFHSY object (see command CREATE FHSY). The FHSY parametereclipses this one if frequency hopping is active in the BTS.

For further details please 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 ofmaximally 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 ofmaximally three AMR CODECs (defined by AMRFRC1..AMRFC3).



Note: An equivalent parameter to this one is also included in the

FHSY object (see command CREATE FHSY). The FHSY parametereclipses this one if frequency hopping is active in the BTS..






AMRFRIC=

START_MODE_FR,


range: START_MODE_FR

CODEC_MODE_01

CODEC_MODE_02

CODEC_MODE_03

CODEC_MODE_04 default: START_MODE_FR

AMR Full Rate Initial Codec , this parameter defines which AMR FRCODEC of the created AMR FR ACS shall be used first after FR TCHassignment. The values CODEC_MODE_0x represent the created

AMR FR CODECs (AMRFRCx) of the ACS.Example: If AMRFRIC=CODEC_MODE_01, then the CODECdefined in AMRFRC1 will be used as initial AMR FR CODEC after FRTCH assignment.

If the value START_MODE_FR 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 mostrobust channel coding (i.e. the one with the lower speech codingbitrate) shall be used.- If the ACS consists of 4 CODECs, then the one with the secondmost robust channel coding shall be used.


AMRFRTH12=7-4,

object: BTS [BASICS]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: 7 [3.5 dB]

hysteresis: 4 [2.0 dB]

Default value changed in BR7.0!

AMR Ful l Rate Thresholds 12 , this parameter defines the C/Ithreshold and the associated hysteresis for the AMR downlink

CODEC mode adaptation transition from AMRFRC1 to AMRFRC2and vice versa. The entered values are applied as follows:

a) The upward transition from AMRFRC1 to AMRFRC2 is initiatedwhen

C/I > threshold AMRFRTH12 + hysteresis AMRFRTH12

b) The downward transition from AMRFRC2 to AMRFRC1 is initiatedwhen

C/I < threshold AMRFRTH12

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 to this one is also included in the FHSYobject (see command CREATE FHSY). The FHSY parametereclipses this one if frequency hopping is active in the BTS.- Please be aware that this parameter only refers to the AMRdownlink CODEC mode adaptation. The corresponding uplinkthresholds are not administrable (see parameter AMRLKAT).





AMRFRTH23=12-4,


format: threshold-hysteresis


hysteresis: 0.5dB



default: threshold: 12 [6.0 dB]hysteresis: 4 [2.0 dB]


AMR Ful l Rate Thresholds 23 , this parameter defines the C/Ithreshold and the associated hysteresis for the AMR link adaptationtransition from AMRFRC2 to AMRFRC3 and vice versa.The entered values are applied as follows:


C/I > threshold AMRFRTH23 + hysteresis AMRFRTH23 b) The downward transition from AMRFRC3 to AMRFRC2 is initiatedwhen








AMRFRTH34=23-4,




hysteresis: 0.5dB






AMR Ful l Rate Thresholds 34 , this parameter defines the C/Ithreshold and the associated hysteresis for the AMR downlinkCODEC mode adaptation transition from AMRFRC3 to AMRFRC4and vice versa. The entered values are applied as follows:


C/I > threshold AMRFRTH34 + hysteresis AMRFRTH34

b) The downward transition from AMRFRC2 to AMRFRC1 is initiatedwhen







Notes:

- An equivalent parameter to this one is also included in the FHSYobject (see command CREATE FHSY). The FHSY parametereclipses this one if frequency hopping is active in the BTS.- Please be aware that this parameter only refers to the AMRdownlink CODEC mode adaptation. The corresponding uplinkthresholds 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_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)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 2CODECs, then AMRHRC3 must be set to <NULL> and so on. For

AMRHRC1 the value <NULL> is not allowed, as at least one CODECmust be defined within an ACS.


RATE AMRHRC4 > RATE AMRHRC3 > RATE AMRHRC2 > RATE AMRHRC1


For further general details please 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.


(RATE_04 and RATE_05 only for BTSplus)

If AMRHRC2 is set to <NULL>, the ACS for AMR HR only consists ofonly 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.


(RATE_04 and RATE_05 only for BTSplus)

If AMRHRC3 is set to <NULL>, the ACS for AMR HR only consists ofmaximally 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 ofmaximally 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 HRCODEC of the created AMR HR ACS shall be used first after HRTCH assignment. The values CODEC_MODE_0x represent the

created AMR HR CODECs (AMRHRCx) of the ACS.Example: If AMRHRIC=CODEC_MODE_01, then the CODECdefined 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 mostrobust channel coding (i.e. the one with the lower speech codingbitrate) shall be used.- If the ACS consists of 4 CODECs, then the one with the secondmost robust channel coding shall be used.

Notes:- An equivalent parameter to this one is also included in the FHSYobject (see command CREATE FHSY). The FHSY parametereclipses this one if frequency hopping is active in the BTS.





AMRHRTH12=19-4,




hysteresis: 0.5dB





AMR Half Rate Thresholds 12 , this parameter defines the C/Ithreshold and the associated hysteresis for the AMR downlinkCODEC mode adaptation transition from AMRHRC1 to AMRHRC2and vice versa. The entered values are applied as follows:

a) The upward transition from AMRHRC1 to AMRHRC2 is initiatedwhen

C/I > threshold AMRHRTH12 + hysteresis AMRHRTH12 b) The downward transition from AMRHRC2 to AMRHRC1 is initiatedwhen

C/I < threshold AMRHRTH12



threshold AMRHRTH12 + hysteresis AMRHRTH12

ω threshold AMRHRTH23 + hysteresis AMRHRTH23



AMRHRTH23=24-4,




hysteresis: 0.5dB








C/I > threshold AMRHRTH23 + hysteresis AMRHRTH23

b) The downward transition from AMRHRC3 to AMRHRC2 is initiatedwhen







Notes:

- An equivalent parameter to this one is also included in the FHSYobject (see command CREATE FHSY). The FHSY parametereclipses this one if frequency hopping is active in the BTS.- Please be aware that this parameter only refers to the AMRdownlink CODEC mode adaptation. The corresponding uplinkthresholds are not administrable (see parameter AMRLKAT).





AMRHRTH34=30-4,




hysteresis: 0.5dB



default: threshold: 30 [15.0 dB] (BTS+)<NULL> (BTS1)





C/I > threshold AMRHRTH34 + hysteresis AMRHRTH34 b) The downward transition from AMRHRC4 to AMRHRC3 is initiatedwhen








AMRLKAT=100,


unit: 0,1dB

range: 0..200, where

0 = -10dB, 100 = 0dB,

200 = +10dB

default: 100 [0dB]

AMR l ink adaptat ion tuning , this parameter is used by the AMRUplink Codec Mode Adaptation in the BTS (Please note that this

parameter is the only one which refers to the uplink CODEC modeadaptation! All other administrable parameters refer to the downlinkCODEC mode adaptation and have no relation to this parameter!). Ittunes the transition between CODEC modes determined by internalthresholds. A value higher than the default shifts the transitiontowards higher carrier-to-interferer or signal-to-noise ratios. A valuelower than the default has the opposite effect. The step size is 0,1dB.

Adaptation of AMR Half Rate and AMR Full Rate is affectedsimultaneously. All possible transitions between modes are generallyshifted by the same amount. However, to account for a limited rangeof the underlying measurements, shifts of transitions near the upperrange limit tend to saturate when shifted closer to the limit. Thedefault value is the optimum setting and normally requires nomodification.

For further details please refer to the section “AMR Link AdaptationThresholds Uplink” in the Appendix of this document.

ANTHOPMOD = <NULL>,


range: ALLTRX, NOBCCHTRX,<NULL>

default: <NULL>

Antenna hopp ing mode , this parameter is only relevant if thefeature ‘Antenna Hopping’ is enabled (EANTHOP=TRUE, see below)and defines whether Antenna Hopping is applied for the BCCH TRX

or not. Antenna Hopping is enabled either- for all CUs including the BCCH-TRX CU (value ALLTRX) or- for all CUs except for the BCCH-TRX CU (value NOBCCHTRX).

The feature "not-ramping for BCCH" is deactivated if ANTHOPMOD=ALLTRX is set.





ANTHOPP = <NULL>


range: ALL, SECOND, FOURTH,

SEQ_445, <NULL>

<NULL>

default: <NULL>

Antenna hopp ing per iod , this parameter is only relevant if thefeature ‘Antenna Hopping’ is enabled (EANTHOP=TRUE, see below)and defines the antenna hopping period.

After having grouped the CUs in pools, the BTS algorithm calculatesthe Antenna Hopping sequence individually for each CU-POOL. Theoperator, by means of the O&M parameter ANTHOPP, can set thehopping period, i.e. he can decide how many frames are transmitted

over each antenna before the next antenna is used to send theframes. Antenna Hopping is performed every one, two or fo ur

frames . Additionally there is the mode 4-4-5 , which means that each3rd hopping step the period is extended from 4 to 5 frames (suitableespecially for GPRS/EGPRS). The number of antenna changesdepends on the number of used antennas and service (4-4-5 used forEDGE).

BCCHFREQ=10,


range: 0..1023


GSM 05.08

BCCH frequency , specifies the Um channel no.(e.g. BCCHFREQ 10 = C10) of that carrier which contains the FCH,SCH, BCCH and CCCH.

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 the

SCH. The format is NCC - BCC.NCC= Network Colour Code, BCC= Base Station Colour Code.From the NCC the MS determines which cells are allowed forhandover (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 BCCis 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.BTSHSCSD=FALSE,


range: TRUE, FALSE

default: FALSE


HSCSD enabled for th e BTS , this attribute indicates whetherHSCSD 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 foran 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 thesuggested target cells - if it finds on target cell withBTSHSCSD=TRUE, the directed retry is executed (CHANNEL

ACTIVATION a HANDOVER COMMAND towards the target cell). Ifthe BWHCI contains an external target cell (other BSC), the BSCsends the HANDOVER REQUIRED message towards the MSC, ifthe parameter EISDCCHHO (see commandSET BSC [BASICS]) isset to ENABLE.





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 usedin the cell are set with the remaining parametersCALLF02..CALLF63. This parameter is sent on the BCCH (SYSTEMINFORMATION 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 'cellallocation'. 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 usedfrequency band:

SYSID=BB900: 1..124SYSID=F2ONLY900: 0..124, 975..1023SYSID=EXT900: 0..124, 975..1023SYSID=DCS1800: 512..885SYSID=GSM850: 128..251SYSID=GSM850PCS: 128..251, 512..885SYSID=GSM850DCS: 128..251, 512..810SYSID=GSMR: 955..974SYSID=PCS1900: 512..810

Notes:- The SYSTEM INFORMATION TYPE 1 is only sent if frequencyhopping 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).

CBQ=0,


range: 0= normal priority1=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 sentin the IE ‘SI 4 Rest Octets’ on the BCCH (SYSTEM INFORMATIONTYPE 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

‘cell reselectio n’.

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 differentneighbour 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 prioritydefined 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 theselection 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..65535Reference: GSM 03.03

GSM 04.08

Cell Global Identit y , this digit string unambiguously identifies a cellwithin 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 (SYSTEMINFORMATION TYPE 3 or 4) or on the SACCH (SYSTEMINFORMATION TYPE 6). Within these messagesMCC-MNC-LAC make up the IE ‘Location Area Identification’ and CIcorresponds to the IE ‘Cell Identity’. SYSTEM INFORMATION TYPE4 does not contain the CI but only the LAI.

CELLRESH=2,


unit: 2dB

range: 0..7

default: 2

Reference: GSM 05.08GSM 04.08

GSM 03.22

GSM 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 underparameter 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 RXLEVeven for MS with low transmit power level. The term Max(B,0), addedto RXLEVAMI, ensures that the transmit power capability isconsidered in addition to the minimum receive level defined byRXLEVAMI: 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 necessarycalculation parameters from the BCCHs of the serving and theneighbour cells). The calculation result determines the priority ofthese 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 higherthan 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 belongto 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 servingcell 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 (SYSTEMINFORMATION 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 providedvia the BCCH.





CELLTYPE=STDCELL,


range: STDCELL

EXTCELL

default: STDCELL

Cel l type , this parameter determines which kind of cell is to bedefined.

a) The value STDCELL means ‘standard cell’ 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, forDCS1800/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 cell’ 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 of35km. 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 channelresources 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 buta 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 receivedfrom 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 fixedrelation between an ‘area’ (far or near) and 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

Signal ing of extended TA v alues As in an extended cell the normal coding range of the timing advance(TA, ranbge 0..63) is not sufficient to display distance values greaterthan 35km, a new IE called ‘timing offset’ is used in the Abis RSLsignalling which allows the representation of the correspondingextended MS delay values.

Cal l setup in an extended cel l 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 assignedto 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 timingoffset 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 to





the current MS-BTS distance.

Intracell hando ver due to dis tanc e (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 orvice versa, depending on the current chages of the MS-BTSdistance. This handover is enabled by the parameter EXTCHO andthe 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 parameterdescriptions.

Note: The features 'Extended Cell' and 'Concentric Cell' (seeCONCELL) exclude each other.

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 ranges are determined by the values entered for the

power reduction (see parameter PWRRED (CREATE TRX)).

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 a fixedrelation 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

= 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 areexecuted 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 concentriccell the same values are also evaluated to determine whether the callis set up on a TCH belonging to an inner or complete area TRX.

The Concentric cell Configuration is also an obligatory preconditionfor the feature “Common BCCH for GSM 900/1800 or GSM850/1900Dual Band Operation”. This feature allows to assign frequencies ofdifferent bands 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 useGSM900 resp. GSM850 frequencies for the complete area (and thusfor 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. In any case, if the feature“Common BCCH” is used, the SYSID parameter (see below) mustbes set to GSMDCS resp. GSM850PCS and the parameters for

INNER area

COMPLETE area





maximum allowed transmission power must be set for both bands(see parameters MSTXPMAXGSM and MSTXPMAXDCS in CREATEBTS [BASICS]).

Notes:- The features 'Extended Cell' and 'Concentric Cell' exclude eachother, i.e. CONCELL cannot be set to TRUE ifCELLTYPE=EXTCELL.- The intracell handover cause (inner <-> complete) does not exist for

SDCCH-SDCCH handover as in a concentric cell all SDCCHs arealways created in the complete area.

CRESOFF=1,


unit: 2dB

range: 0..63

default: 1


GSM 03.22

Cel l reselect ion offset . This parameter, contained in the IE ‘SI 4Rest Octets’ on the BCCH (SYSTEM INFORMATION TYPE 4), isone of the necessary input values for the calculation of C2. It appliesan offset to the cell reselection criterion C2. This parameter only hasto be set if CRESPARI is set to ‘1’. For further details please refer tothe parameter CRESPARI.





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 C2cell 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 cellbasis. 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 performingunnecessary 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 ofthis calculation determines the priority of these cells within the list ofthe six strongest neighbour cells which is dynamically managed inthe MS in idle mode. Depending on the availability of C2 cellreselection parameters in the BCCH info the MS considers C1 or C2for the cell reselection process.

General Principle of the C2 algorithm: If the MS places a non-servingcell on the list of six strongest carriers it starts a timer the value ofwhich 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 offsetthe C2 of the non-serving cell is artificially made worse and the cellreselection is not executed.

Equation B: On expiry of the timer the temporary offset is disregardedand 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 newcell exceeds C2 of the old serving cell by at least the cell reselecthysteresis (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 permanentoffset (CRESOFF) is not added to but subtracted, i.e. settingPENTIME 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





PENTIME, CBQ have to be skipped.

EANTHOP = FALSE,


range: TRUE, FALSE

default: FALSE

Enable antenna hopp ing , this parameter enables or disables thefeature “antenna hopping”. Antenna Hopping offers a new hoppingmechanism 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 Hoppingallows to obtain a performance improvement (diversity gain) ofseveral 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 basebandfrequency hopping is not allowed, because the TX Diversity/AntennaHopping feature itself is based on some baseband hoppingmechanism. The feature is a complete SW feature, requiring nomodifications in any HW.

Antenna Hopping is supported only by BTSplu s mainlin e, BS240XS

and e-Micro BTS . Due to the limitations of the CClink PicoBTS is notable 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 motorto a specific TRX frequency so that only baseband frequencyhopping 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) andfrequency 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 Hoppingbetween 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 hoppingsequence is calculated. The pool grouping and the calculation of poolsequences are done in the BTS core (COBA) by a dedicatedalgorithm. 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 correspondingCU 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.





EHRACT=FALSE,


range: TRUE, FALSE

default: FALSE

Enable cel l load dependent activat ion o f HR , this parameterenables the feature “Cell load dependent activation of half rate” fornon-AMR calls in the cell (for AMR calls, a separate database flagEHRACTAMR (see command SET BSC [BASICS] is available). Thisfeature allows the BSC to override the speech version preferencesindicated in incoming TCH seizures requests and to force theseincoming TCH seizure requests to FR or HR TCHs depending on the

actual radio traffic load situation in the cell (BTS) and the Abis trafficload situation in the BTSM. On the basis of the radio TCH loadthresholds HRACTT1 resp. HRACTT2 (see command CREATE BTS

[ BASICS ] ) and the Abis TCH load threshold ABISHRACTTHR (seecommand CREATE BTSM) the BSC decides which kind of TCH type(resp. speech version) is to be assigned for a particular TCH seizurerequest.

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 ofview. 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’ ofeach call in one transaction register and considers this profile for allsubsequent TCH seizure requests (cases 3 and 4). IfEHRACT=FALSE, the decisive factor for the BSC in the TCHassignment 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) andb) the current Abis traffic load (per BTSM)

Case A: HR activat ion due to radio TCH load in the cel 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 extendedcell).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 bythe 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

∗ 100Cell traffic load [%] =no. of radio TCH not available for CS TCH allocation

no. of configured radio TCH





capability).

If the cell traffic load exceeds the percentage defined by HRACTT1resp. HRACTT2, all incoming calls or incoming MSC-controlledhandovers, for which HR is indicated as supported speech version(half rate version 1), are forced to a HR TCH.

Case B: HR activat ion due to BTSM Abis TCH load

Before assigning a TCH after having received one of theabovementioned TCH seizure requests (1..4) the BSC calculatesthe BTSM Abis traffic load and compares it to the threshold

ABISHRACTTHR. The BSC calculates the Abis traffic load accordingto the formula

For further details about the meaning of single terms of this formula, please refer to the description of parameter ABISHRACTTHR (seecommand CREATE BTSM).

As long as the BTSM Abis traffic load remains below the thresholddefined by the parameters ABISHRACTTHR, 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).If the BTSM Abis traffic load exceeds the percentage defined by

ABISHRACTTHR, all incoming calls or incoming handovers, forwhich HR is indicated as supported speech version, are forced to aHR TCH.

Interworking between case A and case B

• Incoming calls or incoming handovers, for which HR is indicated assupported speech version, are forced to a HR TCH, if either the BTS radio TCH load has exceeded the thresholdHRACTT1/HRACTT2 or the BTSM Abis pool TCH load hasexceeded the threshold ABISHRACTTHR (or both).

• Incoming calls or incoming handovers, for which HR is indicated assupported speech version, are forced to a FR or EFR TCH, if the

BTS radio TCH load is below the threshold HRACTT1/HRACTT2an d the BTSM Abis pool TCH is below the threshold ABISHRACTTHR.

Notes:- The database flags EHRACTAMR (SET BSC) and EHRACT(CREATE/SET BTS) are independent of each other, i.e. for operationof the feature ‘Cell load dependent activation of half rate’ for AMRcalls only the flag EHRACTAMR is relevant, the setting of the flagEHRACT does not have any influence.- Cell Load Dependent Activation of HR does not work when DirectTCH Asssignment (see parameter DIRTCHASS in command SETBTS [OPTIONS]) is enabled. In case of Direct TCH Assignment theBSC has to decide about the TCH type (FR, HR) when it receives theCHANNEL REQUIRED message. The only information about the

MS’s speech version capability which is available at this point of timeis included in the ‘Establishment cause’ IE within the includedCHANNEL REQUEST message. This information is very restrictedwith respect to the grade of detail and the MS capabilities and

preference. At this point of time the BSC does not check the currentTCH load in the cell to decide about the allocation of FR or HR butassigns a TCH type in correspondence with the ‘establishmentcause’ value received in the CHANNEL REQUIRED message.- To avoid a ping-pong handover from HR to FR and vice versa,which can occur due to subsequent execution of (AMR)decompression handover (see parameter EADVCMPDCMHO incommand SET HAND [BASICS]) and intracell handover due to

BTSM Abis traffic load [%] =no. of Abis TCH not available for CS TCH allocation

no. of Abis TCHs configured in Abis pool∗ 100





quality (for a call whose quality is still poor after decompressionhandover), 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 ifthe BSC receives an INTRACELL HANDOVER CONDITIONINDICATION 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. EPAT1=4000,


unit: 0,01 %

range: 0..10000

default: 6000


Enhanced Pair ing Threshold 1 , this parameter represents thethreshold that indicates, when the Enhanced Pairing for TCH/Hchannels feature is enabled (see parameter EPA in command SETBSC), 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 parameterCELLTYPE=EXTCELL in command CREATE BTS [BASICS])

The value 100 represents 1%.

Enhanced pairing intracell handovers are triggered if the followingradio TCH traffic load condition is fulfilled (for further details about the

meaning of single terms of this formula, please refer to thedescription of parameter EPAT1).

* Attention:


- A dual rate TCH (TCHF_HLF) can assume the usage state “busy“ (i.e. both HR

subslots 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 BSC[BASICS]) has an influence on the radio TCH traffic load caluculation: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 orDOWNGRADE_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 particularTCH/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 GMANPRES in the PTPPKF object) arenot considered in the calculation, i.e. they are treated as if they were not configured!Thus the value above the fraction bar represents all TCHs in state ‘idle’ (notconsidering the reserved GPRS TCHs in state ‘idle’) and the value below the fractionbar 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 GMANPRES, thecurrently used but ‘not reserved’ TCHs (‘idle/shared’ TCHs) are considered incorrespondence with the setting of DGRSTRGY as indicated above.

Attention: A lthough the defaul t value of this parameter is 6000

(=60%), a more us eful settin g is 4000(=40%) as the thres hold is

com pared to the percentage of ‘ id le ’ TCHs (not the ‘busy’) !

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).

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

no. of configured radio TCHEPAT1[%]





EPAT2=4000,


unit: 0,01 %

range: 0..10000

default: 6000


Enhanced Pair ing Threshold 2 , this parameter represents thethreshold that indicates, when the Enhanced Pairing for TCH/Hchannels feature is enabled (see parameter EPA in command SETBSC), 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%.

Attention: A lthough the defaul t value of this parameter is 6000

(=60%), a more us eful settin g is 4000(=40%) as the thres hold is

com pared to the percentage of ‘ id le ’ TCHs (not the ‘busy’) !

For further details please refer to parameter EPAT1 (see above).

ETXDIVTS=FALSE,


range: TRUE, FALSE

default: FALSE

Enable TX diversi ty t im eshif t , this parameter allows to switchbetween coverage mode (enabled) and standard mode (disabled).

FACCHQ=5,

object: BTS [BASICS]unit: 1 half burst

range: 0..7

default: 5

FACCH qual i ty , defines the number of FACCH halfburst to bereceived for detecting a FACCH frame. FACCHs are normal speech

bursts which are 'abused' as signaling channels. Within the 'NormalBursts' the so-called 'steal-bits' are used to distinguish TCH fromFACCH info. The general speech coding algorithm codes 20ms ofspeech to 456 bits and distributes it over 8 halfbursts. 'Halfburst'means that the speech information of one 20ms speech block iscontained in one half of the burst only (due to the interleaving oneburst carries the information for two different 20ms-speech-blocks). If- due to transmission problems on the radio interface - the steal-bitsare falsified the FACCH halfbursts may be recognized as TCH bymistake. The FACCHQ parameter determines how many halfburstswith the correct steal-bits must have been received to regard areceived half-burst sequence as FACCH frame.

FDDMURREP=0,

object: BTS [BASICS]range: 0..3

default: 0

FDD mult i rate report ing , this parameter indicates the number FDDUTRAN cells that shall be included in the MEASUREMENT

REPORTs.

FDDQMI =MDB20,


range: MDB20 MDB19

MDB18 MDB17

MDB16 MDB15

MDB14 MDB13 default: MDB20

FDD_Q_Min , this parameter is a threshold for signal Ec/No. Whenthe FDD adjacent level carrier is higher than serving cell of FDDGQO(fddGprsqOffset) and Ec/No is higher than FDDQMI (fddQMin)fdd_ms selects the adjacent FDD cell.

The parameter values express a value in dBm

MDBxx = - xxdBm (e.g. MDB20 = -20dBm)

FDDQO =DB00,


range: ALWAYS MDB28

MDB24 MDB20MDB16 MDB12

MDB08 MDB04

DB00 DB04 DB08

DB12 DB16 DB20

DB24 DB28

default: DB00

FDD_Q_Offset , this parameter relates multiRAT mobiles; it indicatesan offset which is applied to the level of the FDD serving cell.


MDBxx = - xxdBm (e.g. MDB20 = -20dBm)DBxx = xxdBm (e.g. DB20 = 20dBm)

The value ALWAYS indicates an infinite negative offset, so with thissetting a 3G Mobile will always change to the 3G network if anyacceptable 3G cell is available.





FDDREPQTY =RSCP,


range: RSCP, ECNO

default: RSCP

reference: 3GPP 25.433

3GPP 25.215

FDD report ing q uanti ty , this parameter determines in which way theMSs shall report the radio conditions of UMTS FDD neighbour cells.

The possible values are

• RSCP = R eceived S ignal C ode P owerthis value indicates the DL receive level in the UMTS FDDneighbour cell and is thus comparable to the RXLEV value in

GSM.• Ec/No = E nergy c hip to N oise o ver all, this value indicates the DL

quality in the UMTS FDD neighbour cell and is thus comparable tothe RXQUAL resp. C/I values in GSM.

MultiRAT mobiles (RAT=Radio Access Technology) can report theradio conditions of UMTS FDD neighbour cells either by RSCP

values ( level or iented) or by Ec/No values (qual i ty or iented) butnot both at the same time. The setting of FDDREPQTY determineswhich of the two reporting methods shall be used by the multiRATMSs.

Important: The setting of the FDDREPQTY has an influence on the2G-3G handover processing in the BTS:

• 2G-3G handovers from GSM to UMTS due to ‘better cell’ (see

parameter EUBCHO in command SET HAND [BASICS]) are only possible if FDDREPQTY is set to RSCP , as only in this case acomparison of the RXLEV value of the serving GSM cell to theRSCP value in the UMTS FDD neighbour cell is possible via thehandover margin (see parameter HOM in command CREATE

ADJC3G).

• Imperative 2G-3G handovers from GSM to UMTS (see parameterEUIMPHO in command SET HAND [BASICS]) are possible withboth settings of FDDREQTY, but the processing of the measuredvalues is different:- If FDDREPQTY is set to RSCP, the handover minimum condition,which is checked in order to determine whether a particular UMTSFDD neighbour cell is a suitable target cell for imperativehandovers fromGSM to UMTS, is defined by the RSCP-oriented

parameter RXLEVMINC (see command CREATE ADJC3G).- If FDDREPQTY is set to ECNO, the handover minimumcondition, which is checked in order to determine whether a

particular UMTS FDD neighbour cell is a suitable target cell forimperative handovers from GSM to UMTS, is defined by theEc/No-oriented parameter UMECNO (see command CREATE

ADJC3G).

• 2G-3G handovers from GSM to UMTS due to ‘sufficient coverage’(see parameter EUSCHO in command SET HAND [BASICS]) are

possible with both settings of FDDREQTY, but the processing ofthe measured values is different:- If FDDREPQTY is set to RSCP, the suifficient coverage condition,which is checked in order to determine whether a particular UMTSFDD neighbour cell is a suitable target cell for ‘sufficient coverage’

handovers from GSM to UMTS, is defined by the RSCP-oriented parameter USRSCP (see command CREATE ADJC3G).- If FDDREPQTY is set to ECNO, the handover minimumcondition, which is checked in order to determine whether a

particular UMTS FDD neighbour cell is a suitable target cell forimperative handovers from GSM to UMTS, is defined by theEc/No-oriented parameter USECNO (see command CREATE

ADJC3G).

Additional background information:In a UMTS FDD network, the different calls are transmitted via thesame radio frequency, the distinction of the channels is done on the





basis of Code division multiplex, i.e. each channel is characterized byits own code. The overall downlink signal which is broadcast in a

particular UMTS neighbour cell is expressed as

RSSI = R eceived S ignal S trength I ndicator. This RSSI value,however, must be distinguished from the RSCP value, which is validonly for a particular code only. The relation of RSSI, RSCP andEc/No is defined as

RSSI – RSCP = Ec/No

GUARMABIS=0,


unit: 1 %

range: 0..20

default: 0

Guaranteed minimum A bis , this parameter specifies the minimum percentage of ‘in service ‘Abis subslots of the BTSM Abis pool (seecommand CREATE SUBTSLB) that shall in any case be keptavailable for allocation for this cell (BTS).

When allocating new Abis TCH resources in any BTS X of a particular BTSM, the system guarantees that (after the Abisallocation for BTS X) for every BTS Y in the same BTSM the

percentage of Abis subslots still idle and in service is equal or greaterthan

GUARMABISy - %BusyAbisy

where: (GUARMABISy ≠ 0) and (%BusyAbisy ! GUARMABISy ).

BusyAbisy is the percentage of Abis subslots currently allocated to

BTS Y, calculated with respect to the total number of Abis subslots ofthe Abis pool that are in state unlocked/enabled.

Note: GUARMABIS is only guaranteed under normal conditions. It isnot guaranteed:1) in case a fault or an operator command causes the outage ofservice of part of or all the Abis subslots in the Abis pool, as long asthe other cells of the site keep allocated most of the residual inservice Abis resources.2) temporarily, after a reconfiguration that reduces the Abis pool size.3) in case the Abis pool is heavily undersized with respect to theradio configuration.





HRACTAMRT1=6000,


unit: 0,01 %

range: 0..10000

default: 6000

Half Rate Activat ion AMR threshold , this parameter is used for twodifferent features related to AMR calls

- Cell Load Dependent Activation of Half Rate for AMR Calls- AMR Compression Handover

As the functionality of these features is different in both cases, theyare explained in separate points.

a) Cell Load Dependent Activation of Half Rate for AMR callsIn this case HRACTAMRT1 is only relevant if the parameterEHRACTAMR (see command SET BSC [BASICS]) 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 AMRTCH 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 whole BTS (in case of standard cel l )- in the com plete area of a concentr ic cel l (see parameterCONCELL in command CREATE BTS [BASICS])- in the far area of an extended cel l (see parameterCELLTYPE=EXTCELL in command CREATE BTS [BASICS])

If the cell traffic load exceeds the percentage defined byHRACTAMRT1, 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 forcedto AMR FR. As the basic principle is exactly the same like for cellload dependent activation of HR for non-AMR calls please refer tothe parameters HRACTT1 (see below) and EHRACT (see above) forfurther details (e.g. concerning the traffic load calculation)).

b) AMR compression handoverOn every expiry of the timer TRFCT (see SET BSC) the BSC checksthe traffic load in its cells and compares it to the thresholdHRACTAMRT1.

For AMR compression handover the BSC calculates the traffic loadas follows

Attention:





- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBSC [BASICS]) has an influence on the radio TCH traffic load caluculation: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 orDOWNGRADE_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 particularTCH/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 GMANPRES in the PTPPKFobject) are not considered in the calculation, i.e. they are treated as if they were notconfigured! Thus, reserved GPRS TCHs in state ‘GPRS busy’ are not considered(value above the fraction bar) and the value below the fraction bar is the number ofTCHs in ‘unlocked/enabled’ minus the TCHs reserved for GPRS in the same state.

- If a GPRS call utilizes more TCHs than configured as ‘reserved’ by GMANPRES, the

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

no. of TCH in state unlocked/enabled





currently used but ‘not reserved’ TCHs (‘idle/shared’ TCHs) are considered incorrespondence with the setting of DGRSTRGY as indicated above.

If the traffic load in the cell exceeds the threshold HRACTAMRT1, theBSC enables the AMR compression handover in the affected BTS bysending 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 handover all AMR calls currently occupying a FR TCH to a HR TCH if the

quality (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]).

HRACTAMRT2=6000,


unit: 0,01 %

range: 0..10000

default: 6000

Half Rate Activat ion AMR threshold , like the parameterHRACTAMRT1, 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 affactes different cell areas:

- in the inner area of a concentr ic cel l (see parameter CONCELL incommand CREATE BTS [BASICS])- in the near area of an extend ed cell (see parameterCELLTYPE=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 AMRTCH 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 byHRACTAMRT2, 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 forcedto AMR FR. As the basic principle is exactly the same like for cellload dependent activation of HR for non-AMR calls please refer to

the parameters HRACTT1 (see below) and EHRACT (see above) forfurther 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 ‘Cell Load Dependent Activation ofHalf Rate’ (parameter EHRACT, see above).HRACTT1 defines a traffic load threshold that is evaluated for theforced speech version selection for incoming non-AMR TCHseizures. For this, the BSC compares HRACTT1 to the percentage ofbusy 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)

is counted as 2 while a dual rate TCH in usage state „active“ (i.e. only on HR subslotbusy) is counted as 1.

- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBSC [BASICS]) has an influence on the radio TCH traffic load caluculation: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 orDOWNGRADE_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 particularTCH/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. Thus

neither 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 indicatedas supported speech version, are forced to a HR TCH. If the celltraffic load is below the percentage defined by HRACTT1, allincoming calls are forced to FR or EFR (depending on the capabilityand preference indicated in the ASSIGNMENT REQUEST orHANDOVER REQUEST message). For further details please refer tothe parameter EHRACT.

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.

∗ 100Cell traffic load [%] =no. of TCH not available for CS TCH allocation*

no. of configured TCH





LCBM0=<NULL>,


format: <msgid> – <page> –

<reprate> - <scheme>

range: msgid: 0..65534

page: 1..92 characters string

reprate:

SEC_0002, SEC_0010,SEC_0030, SEC_0060,

SEC_0090, SEC_0120,

SEC_0150, SEC_0180,

SEC_0240, SEC_0360,

SEC_0480, SEC_0960,

SEC_1920

scheme:

GERMAN, ENGLISH,

ITALIAN, FRENCH,

SPANISH, DUTCH,

SWEDISH, DANISH,

PORTUGUESE, FINNISH,

NORWEGIAN, GREEK,

TURKISH, UNSPECIFIED

default: <NULL>

Local Cel l Broadcast Message 0 , this specifies the handling andthe contents of the Local Cell Broadcast Message.

LCBM1=<NULL>,


format and range: see LCBM0

default: <NULL>

Local Cel l Broadcast Message 1 , this specifies the handling andthe contents of the Local Cell Broadcast Message. For format, range

and default settings of the parameter value please see parameterLCBM0.

LCBM2=<NULL>,



default: <NULL>

Local Cel l Broadcast Message 2 , this specifies the handling andthe contents of the Local Cell Broadcast Message. For format, rangeand default settings of the parameter value please see parameterLCBM0.

LCBM3=<NULL>,



default: <NULL>

Local Cel l Broadcast Message 3 , this specifies the handling andthe contents of the Local Cell Broadcast Message. For format, rangeand default settings of the parameter value please see parameterLCBM0.

MSTXPMAXDCS=0,


unit: see tables below

range: 0..15

default: 0


GSM 05.05

GSM 04.08

GSM 03.22

GSM 12.10

Maximum tr ansmiss ion pow er for DCS 1800 , this parameterdefines 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 DCS1800band. This info determines the value of the IE 'MS Power' in the firstCHANNEL ACTIVATION message sent by the BSC for a call context(e.g. CHAN ACT for an SDCCH in case of call setup, or CHAN ACTfor a new TCH in case of handover). In the 'MS Power' IEs of thefollowing CHAN ACT messages as well as in the 'Power Command'IEs contained in the ASSIGNMENT COMMAND and HANDOVERCOMMAND messages the allowed power level is additionallydetermined by the MS power capability (whichever is lower) which is

provided by the MS in the IE 'MS classmark' in the CM SERVICEREQUEST message.

Value range:DCS1800: 0..15 default: 0=30dBm (step size -2dBm)

Note:- Increasing the entered value decreases the allowed transmit power.For details regarding the power classes and power control levels

please refer to the GSM-tables on the following pages.- If the feature “Common BCCH for GSM 900/1800 Dual BandOperation” is used in the cell, the both the parametersMSTXPMAXGSM and MSTXPMAXDCS must be set, as both bandsare used within the cell. This information is evaluated during callsetup and for the complete-to-inner intracell handover decision.





MSTXPMAXGSM=5,



range: 2..15

default: 5

Maximum transmiss ion pow er for GSM 900 , this parameterdefines 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 GSM900band.

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 forthe parameter MSTXPMAXDCS.

Note: If the feature “Common BCCH for GSM 850/1900 Dual BandOperation” is used in the cell, the both the parametersMSTXPMAXGSM and MSTXPMAXPCS must be set, as both bandsare used within the cell. This information is evaluated during callsetup and for the complete-to-inner intracell handover decision.

MSTXPMAXPCS=0,



range: 0..15, 30, 31

default: 0

Maximum transm ission pow er for PCS 1900 , this parameterdefines 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 1900band.

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 forthe parameter MSTXPMAXDCS.

Note: If the feature “Common BCCH for GSM 850/1900 Dual BandOperation” is used in the cell, the both the parametersMSTXPMAXGSM and MSTXPMAXPCS must be set, as both bandsare used within the cell. This information is evaluated during callsetup and for the complete-to-inner intracell handover decision.





Mobi le stat ion Power 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

Powercontrol

level

Nominal Outputpower (dBm)

Powercontrol

level

Nominal Outputpower (dBm)

Power ControlLevel

Nominal OutputPower (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 dualbandconfigurations and specifies in which way the MS shall report theneighbour cells of the frequency bands used in the serving andneighbouring 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 allowedNCC 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 ofcells in the band of the serving cell. If there are still remaining

positions, these shall be used to report the next strongest identifiedcells in the other bands irrespective of the band used.2 - The MS shall report the two strongest cells, with known andallowed 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 andallowed 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 identifiedcells 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 CCCHLOAD INDICATION is only sent to the BSC if the CCCH loadthreshold 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 followingmechanism: as long as the PCH load is still above the thresholddefined 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 pagingqueues and is thus an attempt to effectively prevent further overloadsituations by removing those messages that have the biggest impacton the load in the AGCH queues.

Attention: if TMSI Reallocation is disabled in the network (i.e. pagingis exclusively done with the IMSI), it is recommended to disable thisfunctionality by setting PCCCHLDI=0 (as this would lead to too manydiscarding 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 necessaryinput 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’ IEmay be included in the MEASUREMENT REPORTs in busy mode.Thus only to these cells a handover is actually possible! In otherwords, if a specific cell has two cells using the same BCCHfrequency or a directly adjacent BCCH frequency (whose “side-ramp”the MS might misinterpret as the signal of the allowed BCCHfrequency due to co-channel interference) in the geographicalneighbourhood, 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 (SYSTEMINFORMATION TYPE 2, together with the list of the allowedneighbour cell BCCH frequencies) or on the SACCH (SYSTEMINFORMATION 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 includedin “NCC Permitted”. “NCC Permitted” is included in the SYSINFO 2only in order to inform the MS early enough which cells are allowedfor measurement reporting when it switches to ‘busy’ mode.

PUREBBSIG44CONF=TRUE,


range: TRUE, FALSE,<NULL>

default: FALSE

Pure BBSIG44 Configurat ion, this parameter states if a BTS1 isequipped with all BBSIG44 (TRUE) or equipped with at least one “oldBBSIG” (FALSE). It is up to the operator to ensure the consistencybetween the attribute value and the BS-2x/6x equipment. In case ofBS-4x/240/241/240XL, BS-82 and BS-242 the attribute is notmeaningful, and its value must be <NULL> value.

The BBSIG type used in BTSEs of the BTS1 family is relevant for the14,4 kbit/s data coding and the ciphering algorithms for handoverfrom and towards UMTS radio cells: If these features are required, it

is obligatory to use BBSIG44 HW.Note: If PUREBBSIG44=FALSE, the BSC rejects all messages thatinclude the IE ‘Encryption Information’ (e.g. CIPHERING COMMAND,HANDOVER REQUEST etc.) with an encryption key (Kc) of morethan 54 bit. The ‘Encryption key’ parameter itself has a length of 64bit, but the last 10 bits (last byte and the last 2 bits of the ‘last butone’ byte) must be set to ‘0’ as the old BBSIG only supports Kc’s ofthis format. If this condition is not fulfilled (it is automatically fulfilled ifthe standard A8 is used for the calculation of the Kc!), the BSCrejects the message with the cause value ‘Cipher algorithm notsupported’.

Note: In BR7.0 the BBSIG1 (old B BSIG) is no longer sup ported





( the assoc iated BTS SW code w as com pletely removed), which

means th at for B TS1 the parameter PUREBBSIG44CONF must

be set to TRUE in any case, whi le for BTSplus i t mus t be set to

<NULL>.

QSRHC=NEVER,


range: UMDB98 UMDB94

UMDB90 UMDB86UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66

OMDB62 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 byQSRHC is fulfilled for a particular 3G neighbour cell, then this cell

shall be considered 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 “xxdB” threshold value, the neighbour cell shall be considered for cellselection/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 forcell 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 usedbefore the MS receives QSRHC (Qsearch_c) in the measurementinformation message on the SACCH.

If the value QSEARCHI is selected, the actual threshold is definedby the parameter QSRHI (see below).

QSRHI=NEVER,



UMDB90 UMDB86

UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66

OMDB62 OMDB58OMDB54 NEVER

default: NEVER

qSearchI , this parameter defines a threshold condition whichenables the searching for 3G cells with regard to cellselection/reselection (in idle mode); in other words, if the thresholdcondition defined by QSRHI is fulfilled for a particular 3G neighbourcell, then this cell shall be considered for cell selection/reselection.QSRHI defines the default value of the attribute QSRHCINI (seeabove).

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 signalevaluation 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 the

RACH, 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 minimumthreshold (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 RACHburst to determine the MS-BTS distance. Together with the decodedsignal itself, the results of these checks are forwarded in form of a setof 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 thereceived signals either as ‘noisy’ or ‘not noisy’. Five of the mentionedflags from the layer 1 evaluation are regarded as ‘killer criteria’ (RSSI,SOVA, SNIR, Conv Code and training sequence), i.e. if one of theseflags was set to ‘1’ by the layer 1 SW subsystem, the call handlingsubsystem regards the received signal as ‘noisy’, which leads to an

immediate discarding of the received signal. In this case the signalwill neither lead to the transmission of a CHANNEL REQUIRED, norwill it be counted by the PM counter NINVRACH (Number of invalidRACH messages per cause). If, however the mentioned five flagsassume the value ‘0’ (criterion fulfilled), the BTS call handlingsubsystem evaluates three further criteria to check whether a RACHsignal is to be regarded as ‘valid’ or ‘invalid’ (the numbering definessequence of the checks):1. If the ‘block CRC error’ flag has the value ‘1’, the received RACHmessage is regarded as invalid and counted by NINVRACHsubcounter 3 (’other causes’).2. If the received signal level is below the threshold defined by the

parameter RACHBT, the received RACH message is regarded asinvalid and counted by NINVRACH subcounter 1 (’signal level too

weak’).3. If the delay of the RACH burst indicates that the MS-BTS distanceis greater than the distance defined by the parameter EXCDIST (seecommand SET BTS [OPTIONS]), the received RACH message isregarded as invalid and counted by NINVRACH subcounter 2(‘excessive distance’).

If none of the aforementioned conditions applies, the RACH access isregarded as ‘valid’ and leads to the transmission of a CHANNELREQUIRED message towards the BSC.

Notes:- The value entered for parameter RACHBT is not only relevant forthe CHANNEL REQUEST message on the RACH but also for theHANDOVER ACCESS message on the FACCH! The level evaluationof RACHBT against the receive level of the handover access burst on

the FACCH is exactly the same as for the RACH. Thus, the setting ofRACHBT also has an influence on the handover success rate.

- RACHBT is also relevant for the BTS load recognition procedure forthe RACH which is controlled by the O&M-parameters- RACH busy threshold (RACHBT)- measurement period(see parameter RACHLAS = RACH load averaging slots)

- reporting rate(see parameter PCCCHLDI = CCCH load indication period)

RACHLAS=204,


unit: 1 RACH burst

range: 102-65535

default: 204

RACH load averaging slots , defines the number of RACH burstsover which RACH measurements are performed by the BTS (seealso parameter RACHBT). In other words: RACHLAS defines theaveraging window for the RACH load measurements. The BTSreports these measurements to the BSC according to the setting ofthe parameter PCCCHLDI (see above). Please see also parameterTCCCHLDI.Rule: The CCCH LOAD INDICATION reporting period should always

be greater than the averaging time: RACHLAS ≤ PCCCHLDI.





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 usedby 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 ofthe 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 forthe ‘S’ counter in the MS which is in effect if the mobile is in‘dedicated’ (or ‘busy’) mode. Unsuccessful decoding of SACCHmessages by the transceiver lead to a decrease of the ‘S’ counter by1, 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 uplinkSACCH frames anymore (because the MS has stopped transmittingthem) and it is just a question of time when the radio link counter inthe BTS (see RDLNKTBS) reaches ‘0’. In this case a CONNECTIONFAILURE INDICATION (BTS->BSC) is sent and indicates the loss ofthe dedicated connection (call drop).Note: If ‘Call Re-Establishment’ (see parameter CREALL) is enableda low value of radio link time-out increases the number of callreestablishments 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 MEASUREMENTREPORT messages for measurements reporting.Enhanced measurement reporting is only supported by specialmobiles.

Note: ENHANCED MEASUREMENT REPORT is not to be mixed upwith EXTENDED MEASUREMENT REPORT, although for both the

same 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 ofhandover 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 forTCH with GDCH=PBCCH), an equivalent parameter is broadcast onthe PBCCH for GPRS mobiles to allow a separate management ofcell 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 loadthreshold 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 forthe percentage of busy SDCCHs which initiates the moving of a

TCH/SD from the TCH/SD_POOL (see parameter settingCHPOOLTYP=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 thatis 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 SDCCHrelease 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 currentSDCCH traffic load and compares it to SDCCHCONGTH.Attention: the calculation performed during the SDCCH release

procedure is different from the formula shown above! For furtherdetails 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 notmove 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 subslotfrom the non-TCH/SD SDCCHs), no matter whether additionalSDCCH subslots are available in the SDCCH_BACKUP_POOL ornot.

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 trafficchannels.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 shallbe configured for the feature “Common BCCH for GSM 900/1800 orGSM850/1900 Dual Band Operation” (see parameter CONCELL).

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 timingadvance 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.





TCCCHLDI=100,


unit: 1%

range: 0..100

default: 100

Threshold for CCCH load indicat ion , this value is a threshold usedby the BTS to inform the BSC about the load on the CCCH bysending the Abis RSL message CCCH LOAD INDICATION. Thismessage is used to make the current PCH load and RACH loadvisible on the Abis interface. The BTS sends the CCCH LOADINDICATION if eithera) the PCH load (in %) exceeds the threshold TCCCHLDI or

b) the RACH load (in %) exceeds the threshold TCCCHLDI.Even if both conditions occur simultaneously, these events are in anycase signaled in separate CCCH LOAD INDICATION messages.

Case a): PCH load exceeds TCCCHLDI:

The BTS calculates the PCH load as follows:

Notes:- A ‘PCH block’ can also be called a place in the BTS paging queue; for each paging

group one queue is available, each paging queue contains 2 blocks, each block(resp. paging queue place) provides the buffer space for at least 2 MS IDs

- (*) MS ID = IMSI or TMSI- (**) depends on the number of paging groups, which in turn depends on the CCCH

configuration and the setting of NBLKACGR and NFRAMEPG.

If the calculated value exceeds TCCCHLDI, the BTS sends a CCCHLOAD INDICATION, which includes the ‘Paging Load’ IE. This IEcontains the parameter ‘Paging Buffer Space’, i.e. the guaranteednumber of PAGING COMMANDs (i.e. MS IDs) that can still be storedin a paging queue. The BTS calculates this value as follows:

This calculation is based on the fact that at least one further MS IDcan be added in a paging queue place, which already contains 1MSID - depending on the MS IDs type, more MS IDs can be buffered,but it is not predictable which types of MS IDs will be received

furtheron.Case b): RACH load exceeds TCCCHLDI:

The BTS calculates the RACH load as follows:

Note:(*) RACH load measurement period = RACH averaging slots (parameter RACHLAS)

If the calculated value exceeds TCCCHLDI, the BTS sends a CCCHLOAD INDICATION, which includes the ‘RACH Load’ IE. This IEcontains the following parameters:

- ‘RACH Slot Count’, corresponds to the abovementioned ‘RACHload measurement period’ (= parameter RACHLAS)- ‘RACH Access Count’, indicates the number of error-free decodedaccess bursts received on the RACH during the RACHLAS period.- ‘RACH Busy Count’, indicates the number of RACH bursts that werereceived with a level higher than (RACH busy threshold + 35dB).(RACH busy threshold = parameter RACHBT, see above).

Notes:- The receipt of a CCCH LOAD INDICATION does not trigger anyoverload mechanism in the BSC.- BUT: In BR7.0 the parameter TCCCHLDI is additionally used for a

paging overload prevention funtionality which is enabled by the parameter PCCCHLDI (see above). For further details please refer to

∗ 100PCH load [%] =no. of seized PCH blocks ∗ 2 – no. of PCH blocks seized by only 1 MS ID*

2∗ Total number of PCH blocks available**

Remaining bu ffer sp ace for PAGING COMMANDs (MS IDs) =

2∗ Total no. of PCH blocks available – (no. of seized PCH blocks ∗ 2 – no. of PCH blocks seized by only 1 MS-ID)

∗ 100RACH load [%] =no. of busy RACH slots in the RACH load measurement period*

Total no. of RACH slots in the RACH load measurement period*





the description of this parameter.

TDDMURREP=0,


range: 0..3

default: 0

TDD mult i rate report ing , this parameter indicates the number TDDcells that shall be included in the MEASUREMENT REPORTmessages.

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.

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 ofthe 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 furtherdetails 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 beingsent in TX Diversity Time Shift mode.

TXDIVTSPAR=NONE,


range: MDB5, MDB475,

MDB45, MDB425,

MDB4, MDB375,

MDB35, MDB325,

MDB3, MDB275,

MDB25, MDB225,MDB2, MDB175,

MDB15, MDB125,

MDB1, MDB075,

MDB05, MDB025,

DB0, DB025,

DB05, DB075,

DB1, DB125,

DB15, DB175,

DB2, DB225,

DB25, DB275,

DB3, DB325,

DB35, DB3705,

DB4, DB425,

DB45, DB475,

DB5

default: NONE

TX diversi ty t ime shif t parameter , this parameter defines the timeshift of the TX signals of master and slave CU. The parameter is notrelevant if ETXDIVTS parameter is set to FALSE.

UMTSSRHPRI =TRUE,


range: TRUE, FALSE

default: TRUE


UMTS search p r ior i ty, this parameter indicates if a mobile cansearch 3G cells when BSIC decoding is required, i.e. if the searchingtime can be longer than the normal value (13s instead of 10s ).





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 logicalgroup “[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 .

ASCISER=ASCI_DISABLED,

object: BTS [CCCH]

range: ASCI_DISABLED,

ASCI_ENABLED

default: ASCI_DISABLED

ASCI service , this attribute indicates whether for the BTS AdvancedSpeech Call Items (ASCI) are enabled. If ASCISER=ASCI_ENABLEDthis means that both VBS (Voice Broadcast service) and VGCS (VoiceGroup Call Service) are enabled.

Both VBS and VGCS call calls always involvea) one subscriber with special control permissions (called ‘dispatcher’)andb) 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 setup by the dispatcher, the BSC activates an ‘ASCI Common TCH’ in allcells in which ASCI is enabled. This common TCH is a simplex TCHwhich only uses the DL direction (the UL is not used) and which isused by all ASCI service subscribers to ‘listen’ to the information sentby 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 byother ASCI service subcribers.- In case of a VGCS call, the ASCI service subscribers may not onlylisten 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 sendspeech information in the uplink direction, which is transmitted towardsall other ASCI service subscribers and and towards the dispatcher andis 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 (“ASCI1,5 channel model”)

b) The so far unused uplink part of the ASCI Common TCH is activatedand 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,

object: BTS [CONTROL]

range: ULRDISABLE,

VBSENABLE

VGCSENABLE

VBS_VGCSENABLE

default: ULRDISABLE

ASCI Upl ink Reply , this parameter is relevant if ASCI is enabled(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 andsimultaneously an ASCI Common TCH was activated, the BTS





broadcasts the group call reference and the ‘Channel Description’ dataof 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 ASCICommon 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 ASCIcommon TCH and waits for an UPLINK ACCESS message. This

UPLINK 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 startedwhen the UPLINK FREE message is sent:The BTS periodically repeats the sending of the abovementionedUPLINK 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 the

cell and initiates the de-allocation of the ASCI Common TCH in this cellby sending the the VBS/VGCS CHANNEL RELEASE INDICATIONtowards the BSC, which in turn releases the channel by sendingCHANNEL RELEASE, DEACTIVATE SACCH, RF CHANNELRELEASE etc..

Notes:- The UPLINK FREE message is used in two different casesa) in the Uplink reply procedure (as described above)b) during the ‘Talker Change’ procedure within a VGCS call (ASCIservice 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 ASCICommon 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 alwaysbe activated in the affected cells as long as an ASCI group call isongoing, no matter whether ASCI subscribers are present in the cell ornot. Consequently, the NOTIFICATION COMMAND is will alwayscontain the ‘Channel Description’ IE together with the group callreference.- On the LMT the parameter ASCIULR is grouped under theBTS [CONTROL] package. As this ‚package’ only consists of this





single parameter it was added to the [CCCH] package here.

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 requesta dedicated control channel (normally an SDCCH) from the network,the MS performs a RACH access by sending a CHANNEL REQUESTmessage 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 neitherreceived an IMMEDIATE ASSIGNMENT COMMAND or - if no SDCCHis available in the cell - an IMMEDIATE ASSIGNMENT REJECT viathe 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 ASSIGNMENTCOMMAND or IMMEDIATE ASSIGNMENT REJECT, it starts cellreselection to a suitable neighbour cell. To avoid a ‘ping-pong’ cellreselection, the MS must obey a waiting time of 5 seconds before itcan return to the original cell with a further cell reselection procedure, ifit 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 embeddedCHANNEL REQUEST, see associated section in the appendix)

The value of MAXRETR is sent on the BCCH (SYSTEMINFORMATION 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 transmittedCHANNEL REQUEST or whether it does not receive any response atall. 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 nextRACH 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 ofaccess attempts of the MSs and therefore the RACH overload withoutbarring any access classes (see parameter NALLWACC in commandSET BTS [OPTIONS]). A high value of MAXRETR will speed up theaccess and thus increase the RACH and AGCH load, a low value willdelay 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


GSM 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 commandCREATE 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 ‘Cell





Selection Parameters’. This parameter is also used (together withother parameters) to define the path loss criterion C1 (see parameterCELLRESH in command CREATE BTS [BASICS]). The value ofMSTXPMAXCH should be adapted to the size of the radio cell: thesmaller the cell the lower the allowed transmit power should be in orderto 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 acceptedon the RACH, is able to communicate with the network also on thededicated channel.Notes:- If a PBCCH is configured (see parameter CREATE CHAN for TCHwith GDCH=PBCCH), an equivalent parameter is broadcast on thePBCCH for GPRS mobiles to allow a separate management of cellselection 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 poweron 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 parameterMSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS)

(CREATE BTS [BASICS])).NBLKACGR=1,

object: BTS [CCCH]

range: 0..7

default: 0


GSM 05.02

Number of b locks for access grant , specifies the number of CCCHblocks to be reserved in each configured CCCH timeslot for the AccessGrant Channel (AGCH) during a period of 51 TDMA frames, i.e. onemultiframe. This parameter is sent on the BCCH (SYSTEMINFORMATION 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 thatthe 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) is

shared between PCHs and AGCHs. Basically, in the BTS thetransmission of PAGING REQUESTs via the PCH has priority beforethe transmission of IMMEDIATE ASSIGNMENTs via the AGCH, i.e. ifthere are pagings in the BTS paging queues the BTS will always usethe available CCCH blocks for paging first, unless NBLKACGR is setto a value >0. In this case the NBLKACGR value determines thenumber of CCCH blocks that are never used as PCH but exclusivelyas AGCH, guaranteeing a basic network access even in case of hightraffic.

For each BCCH/CCCH timeslot the BTS provides 1 AGCH queue with4 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 quickeremptying 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 GSMspecification, the blocks that are reserved for AGCH are located inadjacent CCCH blocks at a specific position within theBCCH/CCCHmultiframes (235ms). This means that NBLKACGRshould 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 CCCHblocks, paging is performed mainly in the non-reserved CCCH blocks,while AGCH messages can only be transmitted on the reservedblocks. As these are grouped at adjacent positions within the





BCCH/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, NBLKACGR=1 is a recommended setting to guarantee AGCH traffic also in hours of high traffic.- NBLKACGR must be set as follows

a) NBLKACGR ≤ 2 if a BCBCH is created in the cellb) 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. oneMAINBCCH 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 7remaining ones remain ‘shared’ for PCH and AGCH in either CCCH.

NFRAMEPG=2,

object: BTS [CCCH]

range: 2-9

default: 2


GSM 05.02

GSM 05.08

Numb er of mult i frames between paging , defines the number of

multiframes (51 TDMA frames) between two transmissions of the same paging message to mobiles of the same ‘paging group’. The paginggroup determines which CCCH blocks the MS shall monitor forincoming paging messages. By just monitoring a subset of the CCCHblocks for paging (Discontinuous Reception (DRX)) the MS can savebattery capacity. The BSC and the MS calculate the actual paginggroup from the IMSI, the used CCCH configuration in the current cell(also considering the setting NBLKACGR, see above) and the settingof NFRAMEPG. For each paging group an own paging queue isavailable in the BTS, i.e. the higher the CCCH capacity in the cell, themore paging groups and thus paging queues are available in the BTS.Setting NFRAMEPG to a higher value results in an increase of thenumber of paging groups (that are sent on the Um with a lowerfrequency as the Um capacity remains the same), and thus to an

extension of the buffer space which is available in the BTS for thePAGING REQUESTs that are to be transmitted. Thus, with a highervalue of NFRAMEPG the incoming paging traffic is distributed over agreater number of paging groups (paging queues) and thus the BTScan manage temporary paging ‘peaks’ in a better way than with a smallvalue of NFRAMEPG. The smaller the value of NFRAMEPG, theearlier the BTS will run into congestion of single paging queues, whichresults in ‘extended paging’ or/and ‘paging reorganization’.

On the other hand, the higher the value of NFRAMEPG, the longer thetime distance between pagings of the same paging group. Thisincreases the average call setup time for MTCs (from point of view ofthe calling party).

Moreover, NFRAMEPG has an influence on the downlink signalingfailure criterion which in turn is based on the ‘downlink signaling failurecounter’ (DSC) in the MS. When the MS camps on a cell, DSC isinitialized to a value equal to the nearest integer to 90/N where N is theNFRAMEPG parameter for that cell. If the MS successfully decodes amessage in its paging subchannel DSC is increased by 1 (howevernever beyond the nearest integer to 90/N) otherwise DSC is decreasedby 4. When DSC reaches 0 or a negative value, a downlink signalingfailure is declared and cell reselection is performed.

This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE3) in the IE ‘Control Channel Description’.





NOCHFBLK=1,

object: BTS [CCCH]

range: 1-7

default: 1

Noti f icat ion channel f i rst block . This parameter is relevant for ASCI(parameter ASCISER, see above) and refers to the so-called‘Notification Channel’ (NCH). The NCH is used to transport theNOTIFICATION COMMAND message (BSC -> ASCI MS) which isused to inform the ASCI MS about the currently active ASCI groupcalls (by a ‘Group Call Reference’ number) and to provide the ‘Channeldescription’ data if an ‘ASCI Common TCH’ (TCH used simulaneously

by all ASCI MSs in the cell as DL TCH for a VBS/VGCS group call) iscurrently activated in the cell. Several ASCI groups calls can be activewithin one cell at the same time, thus the NCH might broadcastdifferent NOTIFICATION COMMAND messages with different groupcall references and ASCI Common TCH description data. TheNOTIFICATION COMMANDs are periodically repeated on the Uminterface, the periodicity of these messages is determined by the

parameter TNOCH (see command SET BTS [TIMER]). ANOTIFICATION COMMAND with ASCI group call reference butwithout ‘Channel Description’ (indicating an ongoing ASCI group callbut, due to absense of ASCI subscribers currently participating in thisgroup call, no allocated ASCI Common TCH) can only be sent, if the‘Uplink Reply’ procedure is activated in the cell (see parameter

ASCIULR in command SET BTS [CCCH]).

A NCH can be configured on those CCCH blocks within the channelorganization of a BCCH/CCCH, that are reserved for AGCH(parameter NBLKACGR, see above).The parameter NOCHFBLK indicates the first CCCH block to be usedas NCH. If more than one CCCH block is to be used, the total numberof blocks is defined by the parameter NOCHBLKN (see below). In anycase the total number of NCHs (NOCHBLKN) must be smaller than thenumber of CCCH blocks reserved for access grant (NBLKACGR).

If a CCCH block used as NCH can be used for AGCH traffic as well,depends on the setting of both NOCHBLKN and TNOCH (seecommand SET BTS [TIMER]):- If TNOCH=1 and NOCHBLKN=1 then the affected CCCH block isexclusively reserved for NCH.

- If NOCHBLKN ≥ 1 and TNOCH=1, it depends on the number of NCH

blocks to be transmitted/repeated whether every now and then aCCCH block remains available for AGCH or not.

- If NOCHBLKN ≥ 1 and TNOCH=N (N ≥ 1), then the NCH is sent onlyevery N

thSACCH multiframe anyway, i.e. in this case the CCCH blocks

for NCH can be used for AGCH in those SACCH MF where no NCHmessage is to be transmitted.

The position of the NCHs within the BCCH/CCCH timeslot is broadcastin the SYSTEM INFORMATION TYPE 1 within the IE ‘ SI1 RestOctets’. If this information is not included in the SYS INFO 1 messagesent from BSC to BTS while ASCI is enabled (parameter ASCISER,see above), the BTS reacts with an ERROR REPORT message, causevalue ‘message sequence error’.

Note: The NOTIFICATION COMMAND message can also be sent the

FACCH, if an ASCI MS is already involved in a CS or VBS/VGCSgroup call. For further details, please refer to the parameterNOTFACCH in command SET BSC [BASICS].

NOCHBLKN=1,

object: BTS [CCCH]

range: 1-4

default: 1

Noti f icat ion channel block num ber , this parameter indicates the totalnumber of CCCH blocks to be used as Notification Channel (NCH).

The position of the NCHs within the BCCH/CCCH timeslot is broadcastin the SYSTEM INFORMATION TYPE 1 within the IE ‘SI1 RestOctets’.

For further details please refer to the parameter NOCHFBLK (seeabove).





NSLOTST=10,

object: BTS [CCCH]

range: 0..15

default: 10


Numb er of slot spread transmission , determines the cycle periodfor retransmission of RACH accesses (i.e. transmission of aCHANNEL REQUEST message), i.e. it determines the time an MSmust wait after a RACH access attempt before a new one can bestarted. In the mobile the retransmission mechanism is continuouslyexecuted after the first RACH access and only stopped if anIMMEDIATE ASSIGNMENT COMMAND or (if no SDCCH is available)

an IMMEDIATE ASSIGNMENT REJECT message is received fromthe BSS via the AGCH. In the normal and successful case, the MSreceives the IMMEDIATE ASSIGNMENT COMMAND before a secondaccess attempt is started. However, under specific conditions, theIMMDIATE ASSIGNMENT COMMAND or REJECT message may notarrive on time before the MS sends the next random access attempt.

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 embeddedCHANNEL REQUEST, see associated section in the appendix)

The number of RACH retransmissions is restricted to a valuedetermined by the parameter MAXRETR (see above).

For phase 1 mobiles there is only one fixed retransmission period, i.e.the different settings of NSLOTST only lead to different retransmissioncycles for phase 2 mobiles. The delay time determined by NSLOTSTconsists of a fixed (deterministic part “ t d ” and a random part “ t r ”.Calculation: the value NSLOTST is sent as a value called “ tx_integer ”on the BCCH (SYSTEM INFORMATION TYPE 1, 2, 3 and 4) in the IE‘RACH Control Parameters’. The MS maps the tx_integer value to thestatic and deterministic parts td and tr.

NSLOTST(tx_integer)

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

tr 3 4 5 6 7 8 9 10 11 12 14 16 20 25 32 50

For phase 2 mobiles the tx_integer values have a fixed mapping tothe fixed delay time t d , which is different for different BCCHconfigurations (combined, not combined, see command CREATECHAN for BCCH), according to the following table:

MS

phase tr

td (RACH slots,

combined BCCH )

td (RACH slots,

uncom bined BCCH )

Phase 1 ----- 41 (0.35 sec) 55 (0.25 sec)

Phase 2 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)

tx_integer itself determines the size of a ‘window’ (in RACH slots) in





tr = tx_integer = 6

retransmission

td = 163 slots

first transmission with a

collision

Notes:- If an Abis is realized via satellite link it is strongly recommended toset the NSLOTST to 14 as this represents the longest possible RACHretransmission cycle that can be executed by phase 2 mobiles. Thisavoids unnecessary retransmissions that lead to additional SDCCHseizures and thus to a decrease of the Immediate AssignmentSuccess Rate (or even to SDCCH congestion).- If the value of NSLOTST is to be decreased in case of high trafficdensity on the RACH it should be done in small steps with closeobservation of the load situation on the RACH in order to preventRACH overload. NSLOTST values with a long t d may extend theduration of location update, a value with a small t d might causesporadic RACH overload even with few MSs roaming in the cell.

NSLOTST = tx_integer = 3"

td = 6





NY1=30,

object: BTS [CCCH]

range: 1-254

default: 50


NY1 , indicates the maximum 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 INFORMATIONmessage from the BTS. The PHYS INFO message contains the actualtiming 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 bytransmitting an SABM message. If the BTS has not received the SABMfrom the MS after transmission of the last PHYS INFO message andexpiry 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 counterNRFLTCH. 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 SETBTS [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 poweroffset 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> - RXLEVAMIMax (B,0)= MSTXPMAXCH + PWROFS - PMax (B,0)= 0P = 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 andreporting interference levels in idle traffic channels. >

SET BTS [INTERF]:


appear in the DBAEM in the CREATE BTS command. The logicalgroup “[INTERF]” is normally only used on the LMT but was usedhere 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 numberof SACCH multiframes (480ms = 4 multiframes, the interleavingfunction distributes the SACCH info over 4 bursts) over which valuesare averaged (value 1..31) andInterference threshold bo undaries X (X= 1 to 5), these values setthe limits of four interference bands for the idle time slots. Thethreshold values entered for INTAVEPR represent uplink RXLEVvalues 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,


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 channelallocation by the BSC: Basically the channel allocation resp. selectionof TCHs for incoming TCH requests is done cyclically, i.e. the BSCstarts the TCH allocation by selecting the first TCH on TRX:0 (e.g.timeslot 2), the subsequent TCH request is served by the next TCHon TRX:0 (e.g. timeslot 3) and so on. If INTCLASS=TRUE, the BSCalso evaluates the interference band of the idle TCHs for the TCHallocation, 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 TCHinterference measurements (MEITCHIB and ILUPLKIC) will deliverany results.- If frequency hopping is activated, the BTS measures theinterference considering all frequencies used in the hoppingsequence assigned to the a TCH (see parameter FHSY in commandCREATE CHANNEL)!- The idle TCH measurements are performed for normal TCHs as





well as for TCH/SD channels (see command CREATE CHAN forTCH/SD) as long as they are neither occupied as TCH nor asSDCCH.

Generally the BTS does not know anything about the association ofthe TCH/SD channels to the ‘BSC channel pools’ (see parameterCHPOOLTYP in command CREATE CHAN for TCH/SD). Instead, forthe BTS a TCH/SD is treated as a normal dual rate TCH if it is ‘idle’or if it has received a CHANNEL ACTIVATION for channel type

‘TCH’. If it has received a CHANNEL ACTIVATION for channel type‘SDCCH’, it is treated as SDCCH.This means that, even if TGUARDTCHSD (see command SET BSC[BASICS]) is still running for a specific TCH/SD in the BSC (i.e. theTCH/SD is still in the SDCCH_BACKUP_POOL), from point of viewof the BTS the TCH/SD is treated as a dual rate TCH again. Thisagain means that the BTS might send idle channel measurementsduring this period (depending on the setting of RFRSINDP), even ifthe TCH/SD is still in the SDCCH_BACKUP_POOL.

RFRSINDP=60;


unit: 1 SACCH multiframe

range: 1-254

default: 60

RF resource indicat ion per iod , defines the sending rate of theRFRESIND message towards the BSC.





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 andappear 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=DISABLED,

object: BTS [TIMER]

range: DISABLED, ENABLED

default: DISABLED

Enable 'No call in TRX/cell detectio n' , this flag enables resp.disables the features ‘sleeping cell detection’ and ‘sleeping TRXdetection’ 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 andNCDP2). For both alarms the ceasing of the alarm can take place atthe earliest at the end of the next observation period if in this periodthe alarm condition has ceased (successful activities).

1)The feature ‘sleeping cell detection’ supervises the SDCCHactivations 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 TIMEFRAME is output. For this, the BSC observes the number ofESTABLISH 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 manynetworks this approach is commonly used for cells which areexclusively used as handover target. In this case these cells carrytraffic but issue the alarm with error ID 66 - NO CALL IN CELLWITHIN A PREDEFINED TIME FRAME due to missing SDCCHactivity.

2)The feature ‘sleeping TRX detection’ supervises the TCHactivations on a specific TRX: If at the end of the observation periodthe TCH activation success rate is below a fixed threshold, the alarmwith error ID 70 - NO CALL IN TRX WITHIN A PREDEFINED TIMEFRAME is output. For this, the BSC observes the number of

CHANNEL ACTIVATION ACKNOWLEDGE* messages for TCH andthe number of ESTABLISH INDICATION messages for TCH. If for acertain TRX the difference between the number of CHAN ACT ACKmessages and the number of EST IND messages is equal or greaterthan eight (8), the SLEEPING TRX alarm is triggered.

* Note: CHANNEL ACTIVATIONs are only considered in case ofTCH 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=H5-1,

object: BTS [TIMER]

format: StartTime1-TimerNoCall 1

unit: StartTime1: Time in ‘1h’

TimerNoCall1:

Periods of 10min

range: StartTime1: H0..H23

TimerNoCall1: 1-432

default: H5-1

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)

NCDP2=NOTUSED,

object: BTS [TIMER]format: StartTime2-TimerNoCall2

unit: StartTime2: Time in ‘1h’

TimerNoCall2:

Periods of 10min

range: StartTime2: NOTUSED,

H0..H23

TimerNoCall2: 1-432

default: NOTUSED

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))

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 VGCScalls (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: 44 (sdcchSAPI0)

31 (facchTCHF)

41 (facchTCHH)

90 (sacchTCHSAPI0)90 (sacchSDCCH)

90 (sdcchSAPI3)

135 (sacchTCHSAPI3)

recommended values:

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 channeltypes 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 andnormally ends with the LAPDm DISCONNECT (not to be mixed upwith the DTAP DISCONNECT which is transmitted between MS andMSC). All messages within this “acknowledged mode” are checkedby the LAPDm flow control mechanisms based on sequencenumbers that are assigned to each transmitted LAPD message. Onlyfor 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 nothave to be acknowledged are transmitted in “unacknowledged mode”via UI-frames, e.g. in the downlink the SYSTEM INFORMATIONTYPE5 and 6 etc. and in the uplink the MEASUREMENT REPORTS.Of course, the acknowledgement mechanism based on T200 is usedby the MS in the same way.

Principle: When the BTS transmits a DL layer-2 frame on the air (e.g.

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





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 messageanyway) as well as RECEIVE READY (RR) (if there is nothing to betransmitted on layer 3). If the acknowledgement from the MS is notreceived within T200 the transmission of the layer 2 frame isrepeated and T200 restarted. The total number of repetitions is

restricted to N200, a fixed value specified by GSM which depends onthe 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 T200should be set in correspondence with the channel mapping andchannel characteristics on the radio interface. To achieve anoptimum radio interface performance (from the subscriber’s point ofview), the timer values for T200 should be set in such a way that

- a Um layer 2 frame retransmission should take place at the earliestafter 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 developmentrecommends the following setting of the parameter T200

T200=29-31-38-90-70-29-168

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 to

ERROR INDICATION s with cause ‘T200 expired (N200+1) times’)look ‘nice’. In fact, with these settings, the call drop rate due to T200expiries will deliver a realistic image of the actual radio interfacequality (rather than making the call drop rate ‘look nice’ in the

performance measurement counters).

Notes:- The SAPI (service access point identifier) is used as address fordifferent 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 be

changed, but their value does not have any impact on the systembehaviour as on the SACCH associated to a TCH and the SACCHassociated 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 MSthat foresees a channel change (e.g. ASSIGNMENT COMMAND orHANDOVER COMMAND), the BTS starts T200 for these messagesas they are embedded in an I-frame. Whether the MS acknowledgesthis I-frame on the old channel (by RR) before it switches over to thenew channel depends on the mobile type (i.e. some mobiles do send





the RR, others do not).

T3101=HLFSEC-6,

object: BTS [TIMER]

units: MS100 = 100 ms

HLFSEC = 0,5 sec

SEC5 = 5s

range: 0..255

default: HLFSEC-6


T3101 : This timer is started, when a channel is allocated with anIMMEDIATE ASSIGNMENT message and stopped when the MS hascorrectly seized the channels (ESTABLISH INDICATION is receivedfor the assigned channel). If timer the dedicated channel is notestablished before T3101 expires, the allocated channel is released.This scenario can e.g. occur if noise on the radio is decoded asRACH access ("phantom RACH") by mistake. In this case the BSC

sends an IMMEDIATE ASSIGNMENT message to the (not existing)MS which is never answered: no SABM is received from the MS, thusno ESTABLISH INDICATION message is sent from BTS to BSC andT3101 expires.

T3105=MS10-10

object: BTS [TIMER]

units: MS10 = 10ms

range: 0..255

default: MS10-4


T3105 : The Timer T3105 is used for the repetition of PHYSICALINFORMATION message during the handover procedure betweennon synchronized cells. After receipt of HANDOVER ACCESS burstswith a correct handover reference the BSS sends a PHYSICALINFORMATION message to the MS and starts timer T3105. If thetimer expires before the BSS receives any correctly decoded layer 2frame from the MS, it repeats the PHYSICAL INFORMATION andrestarts T3105. Receipt of a correctly decoded layer 2 leads to thereset of T3105. The maximum number of repetitions is determined bythe parameter NY1 (see command SET BTS [CCCH]). If this number

is reached and T3105 expires again, the BTS sends aCONNECTION FAILURE INDICATION message with cause‘Handover access failure' to the BSC which releases the newallocated channels and stops the context related to the handover.

Notes:- The MS can only receive the PHYS INFO within a time framedetermined by the MS timer T3124 (time to receive the PHYS INFO)which is fixed to 320ms. T3124 is started when the MS transmits thefirst HO ACCESS, and is stopped when the PHYSICAL INFO wasreceived. If no PHYS INFO is received before expiry of T3124, theMS returns to the old channel in the originating BTS and sends aHANDOVER FAILURE (DTAP) to the BSC.- The MS can also return to the old channel after it has successfullyreceived the PHYS INFO. When the MS has received the PHYSINFO it tries to set up the layer-2 connection in the target cell bysending the SABM via the new FACCH. When the SABM wascorrectly acknowledged by a UA from the BTS, the setup is regardedas 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 is 34 TDMAframes and number of transmission is restricted to 5. This means thatfor approx. 800ms the MS tries to set up the layer 2 connection onthe target channel. If all these attempts fail, the MS tries to return tothe old channel.- Any CONN FAIL is a trigger event for the TCH drop counterNRFLTCH 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 ofthe new channel (RF CHANNEL RELEASE). If this rule is not

T3105purpose: period for repetition of PHYSICAL INFORMATION messagestart: sending of PHYSICAL INFORMATION messagestop: receipt of a correctly decoded signaling or TCH frame on new channel

from the MSexpiry action: repetition of the PHYSICAL INFORMATION message; if the maximum

number of repetitions (NY1) has been reached: transmission of aCONNECTION FAILURE INDICAION with cause ‘HO access failure’and subsequent release of new channel.





considered, call drops would be counted even if there is no real calldrop but just a reversion to old channel during handover. Asdescribed above, in case of unsuccessful access to the targetchannel 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 ofthe 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 ofthe 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 ofthe 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 andSDCCH 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 usingfixed and the technically only meaningful values for SDCCH. Thismeans that, in case of SDCCH handover, regardless the values ofthe two BTS attributes contained in the BSC database, the BTSapplies the values

t3105 = 235 ms ec and ny1 = 9

T3109=HLFSEC-8,

object: BTS [TIMER]units: MS100 = 100 ms

HLFSEC = 0,5 sec

SEC5 = 5s

range: 0..255

default: HLFSEC-24


T3109 : This timer is used by the BSC during the dedicated channelrelease procedures initiated by the MSC after O&M intervention or

radio link failure conditions. The purpose of T3109 is to ensure therelease of the radio channel in situations in which the MS cannotconfirm connection release messages any more as the dedicated Umsignalling connection has already been lost. After receipt of a CLEARCOMMAND message from the MSC or a detection of a lower layerfailure the BSC sends a CHANNEL RELEASE message to the MS,starts T3109 and deactivates the SACCH. The BSC stops T3109when it has received the RELEASE INDICATION from the BTS,which indicates that the MS has sent the DISCONNECT message onthe main signalling link. If T3109 expires, the BSC deactivates allchannels for this MS by sending the RF CHANNEL RELEASEmessage to the BTS.

Note: If a CONNECTION FAILURE messages is received from theBTSE during an ongoing release procedure the PM counters count aTCH loss (NRFLTCH) although there is no real TCH loss.To avoid these unn ecessary CONNECTION FAILURE

INDICATIONs, i t is recomm ended to set T3109 to a sm al l value,

e.g. HLFSEC-8 .

T3109purpose: timer for forced deactivation of radio channels in case of

communication loss towards the MSstart: sending of the CHANNEL RELEASE messageexpiry action: sending of the RF CHANNEL RELEASE message





T3111=HLFSEC-1,

object: BTS [TIMER]

units: MS100 = 100 ms

HLFSEC = 0,5 sec

SEC5 = 5s

range: 0..255

default: HLFSEC-1


T3111 : This timer is used to delay the radio channel deactivation inthe BSC after release of the main signaling link on the Um. Duringthe call release procedure the BSC sends the CHANNEL RELEASEmessage. After receipt of the CHANNEL RELEASE message the MSsends a DISCONNECT message to the BTS to disconnect theFACCH. Subsequently the BTS acknowledges the DISCONNECTmessage towards the MS by an UA and informs the BSC by sending

the RELEASE INDICATION message. On receipt of the RELEASEINDICATION the BSC stops timer T3109 and starts timer T3111. Onexpiry of T3111 the BSC deactivates the radio channels by sendingthe RF CHANNEL RELEASE message to the BTS. The sole purposeof timer T3111 is to let some time for the acknowledgement of thedisconnection (by an UA) and to protect the channel in case of loss ofthe acknowledge frame.

Note: The higher the value of T3111 is the longer the call release procedure takes. Thus T3111 has an impact on the feature 'Queuing'(see also parameters EQ (SET BTS [OPTIONS]) and BSCT11 (SETBSC [TIMER])): the longer the release procedure for an existing calltakes, the later a queued TCH request can be served. A releasedTCH is 'available' for a queued TCH request if the BSC has receivedthe RF CHANNEL RELEASE ACKNOWLEDGE for the releasedTCH. As a higher value of T3111 leads to a delay of the RFCHANNEL RELEASE message it simultaneously leads to anextension of the queuing time. Therefore it is recommended to setT3111 to the default value (HLFSEC-1).

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 in

the 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 andwaits 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 ofTGRANT, the BTS repeats the VGCS UPLINK GRANT message andrestarts TGRANT. The number of VGCS UPLINK GRANT messagerepetitions is defined by parameter NRPGRANT (see above).

TNOCH=1,

object: BTS [TIMER]


range: 1-254

default: 16


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 cellabout 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.

T3111purpose: security period for acknowledgement of the main signalling link

disconnectionstart: receipt of the RELEASE INDICATION messageexpiry action: sending of the RF CHANNEL RELEASE message





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 ofTRAU frame handling for standard speech calls (FR,HR and EFR)and data calls except 14,4kbit/s data calls. The BTSE starts this timerif 3 downlink TRAU frames have not been correctly received from theTRAU and it is reset if a correct frame is received again (It is onlyused 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 is

released.Rules:- TSYNC > ALARMT2 (see CREATE LICD)This setting is necessary in order to avoid call release before PCMalarm detection.Note: For 14,4kbit/s data calls and AMR calls TSYNC is replaced bythe 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 of14.4 kbit/s data calls and AMR calls. If three consecutive DL TRAUframes have not been correctly received in the BTS thesynchronization between TRAU and BTS (see explanation forTSYNCR) is considered as lost. If this is the case the BTS startsTSYNCDL and waits for the receipt of correct downlink frames.TSYNCDL is stopped when the BTS has received the first correct DL

TRAU 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 forEFR 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 resync hronizat ion, this timer is used for 14.4 kbit/s datacalls. At the beginning of every 14.4. kbit/s data connection BTS andTRAU exchange standard TRAU frames for synchronization. Whenthis synchronization process is regarded as finished the BTS andTRAU 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/sTRAU frames it starts timer TSYNCR and restarts thesynchronization process by transmitting standard TRAU framestowards the TRAU. When the connection is re-synchronized BTS andTRAU 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 forEFR 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 beencorrectly received in the TRAU the synchronization between TRAUand 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 forEFR 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 TRAUdatalink (traffic) at connection establishment or handover. Afterreceipt of the CHANNEL ACTIVATION message the BTSE starts thetimer TTRAU and starts sending uplink TRAU frames towards the

TRAU. 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 PCMalarm 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 andT10) 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 represents

a 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 UPLINKFREE message (with ‘Uplink access request’ included) via theFACCH of the ASCI Common TCH and repeats it periodically. Thetime period between two consecutive transmissions of the UPLINKFREE 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 referto the descriptions provided for parameter ASCIULR (see commandSET BTS [CCCH]).





VGRULF=1,

object: BTS [TIMER]

unit: 1

range: 1..100

default: 2

Voice group upl ink free , this parameter is only relevant if the ASCIfeature 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 (ASCIservice 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 thatthe uplink is currently free, i.e. the UL is not used by any other ASCIMS in the cell and a ‘Talker Change’ procedure can be started, ifrequired. 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 sentthe UPLINK ACCESS message via the ASCI Common TCH) and theUL TCH was successfully allocated, the BSC sends the UPLINKBUSY message via the DL of the ASCI Common TCH.

Recommended value: VGRULF=1.





Setting the cell specific optional features:

< Most of the values are of Boolean type and are broadcast to theMSs on the BCCH. >

SET BTS [OPTIONS]:


appear in the DBAEM in the CREATE BTS command. The logicalgroup “[OPTIONS]” is normally only used on the LMT but was usedhere to allow a more useful grouping of the commands .


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

object: BTS [OPTIONS]


DISABLED


ENABLE(60) (major)


Abis- interface mon itor ing thresholds , determines the state and thethreshold values for the minor, major and critical QOS alarms on thePCMB link. The entered threshold value represents the percentage ofunavailable terrestrial traffic channels on the Abis. If the number ofunavailable terrestrial traffic channels exceeds the enteredthreshold, the alarm messages UNAVAILABLE ABIS TCHTHRESHOLD MINOR, MAJOR or CRITICAL (error ID 164, 165 and166) are output. The threshold values can only be assigned if the

previous attribute is set to ENABLE.

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



DISABLED


ENABLE(60) (major)


Um radio signal ing channels monitor in g thresholds , determinesthe state and the threshold values for the minor, major and criticalQOS alarms for the radio signaling channels of the BTS. The enteredthreshold value represents the percentage of unavailable SDCCHsin the BTS. If the number of unavailable SDCCHs exceeds theentered threshold the alarm message UNAVAILABLE RADIOSIGNALLING CHANNELS THRESHOLD MINOR, MAJOR orCRITICAL (error ID 102, 118 and 162) is output. The thresholdvalues can only be assigned if the previous attribute is set toENABLE.

CELLBARR=FALSE,


range: TRUE, FALSE

default: FALSEReference: GSM 04.08

GSM 05.08

Cell barred , the value TRUE indicates that the cell is barred andcamping or any other access to the cell is forbidden. This parameteris sent on the BCCH (SYSTEM INFORMATION TYPE 1,2,3 and 4) inthe IE ‘RACH Control Parameters’. If a cell is set to ‘barred’ in the

SYS_INFO, this has the following consequences:- RACH access to the cell is not allowed anymore- All mobiles in ‘idle’ mode perform a cell reselection- Existing calls are continued and handovers to this cell are still

possible but as soon as the busy MSs return to idle mode they perform a cell reselection, too. Notes:- A cell can be set to 'barred' by the BSC automatically if certainconditions are fulfilled. These conditions could be e.g.: all TCHslocked or all SDCCHs locked A cell is also barred for about 10s if thehopping mode changes (e.g. due to automatic or manual disabling offrequency hopping). Please see parameter HOPP in command SETBTS [OPTIONS] for further details.- For the MS there is a big difference between a barred cell and a

barred access class (see parameter NALLWACC)! 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 but rejects all call attempts bythe subscriber.





CREALL=NOTALLOWED


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. Forthis, 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 quicklyrecognize the old call context and to interconnect the new radio pathto the existing connection before the call is terminated by the endusers or by expiry of call supervision timers. Whether a call re-establishment can be attempted or not depends on the call controlstate, as described in GSM Rec. 04.08, section 5.5.4.Inhibiting call reestablishment is a possibility to reduce the traffic loadin the cell since call reestablishment causes considerable signalingload on the network. A low value of radio link time-out (see parameterRDLNKTO 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 byan 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 TCHassignment 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 TCHassignment is enabled also for the cause 'answer to paging - anychannel' of the CHANNEL REQUIRED message (since SDCCHonlyMS is not supported by the network).Notes:- 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 can

be 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 REQUESTmessage. This information is very restricted with respect to the gradeof detail and the MS capabilities and preference (see GSM04.08 fordetails). At this point of time the BSC does not check the current TCHload 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 CellLoad Dependent Activation of HR (see parameters EHRACT incommand CREATE BTS [BASICS] and EHRACTAMR in command

SET BSC [BASICS]) does not work when Direct TCH Asssignment isenabled.- 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 cleardistinction 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 anSDCCH 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 transmis sion dow nl ink for FR cal ls enabled ,specifies whether “discontinuous transmission downlink (DTXdownlink)“ is enabled for FR calls in the BTS.

As a precondition for operation, DTX downlink must also be activatedin the MSC, i.e. the MSC must declare DTX downlink ‘allowed’ in theDTX DL FLAG in the ASSIGNMENT REQUEST resp. HANDOVERREQUEST 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 powerconsumption (DTX uplink only). During a normal voice call, the

participants speak only 50% of time, thus each direction oftransmission is occupied about 50% of time. DTX is a mode ofoperation where the transmitters are switched on only for thoseframes containing useful information. So-called VAD (Voice ActivityDetection) 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 ‘totalsilence’ 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 480ms is sent. These so-called SID frames (Silence Description Frames)are sent at the start of every inactivity period and repeated every 480ms, as long as the voice inactivity between BTS and MS lasts.Between TRAU and BTS the comfort noise frames are sent every 20ms.

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) ornot (silence). The BTS sets the DTX flag to ‘DTX employed’ if DTXwas applied in at least one TDMA frame in the measurement period.

Both MS and BTS provide two different measurement values forRXLEV 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 duringspeech periods. To increase the reliability of the SUB values for AMRcalls, 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 Controland Handover Decision Process. In measurements periods withoutactive DTX (speech frames transmitted) the BTS uses the FULLvalues for the PWRC and HO decision. Due to their higher statisticreliability it is possible to weight the FULL values in the PowerControl and Handover averaging process higher than the SUB

values. This is done by the so-called ‘DTX-weighting factor’ includedin the parameters PAVRLEV and PAVRQUAL (see SET PWRC) andHOAVELEV, HOAVQUAL and ALEVFULHO (see SET HAND[BASICS]).

If the MS indicates “DTX used“ in a specific MEASUREMENTREPORT, 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 measurementmessages, in the MEASUREMENT RESULT and TRACEMEASUREMENT 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 andmeasurements results to one and the same MEASUREMENTRESULT 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…





The following example diagram may illustrate the principle:

measurement valuesused for UL PWRC

and HO decision

measurementvalues used for DL

PWRC and HO decision

(TRACE) MEASUREMENT RESULT

Uplink Measurements:

DTX (DL) indicator: DTX employed

RXLEV FULL: <rxlev-full> RXLEV SUB: <rxlev-sub>

RXQUAL FULL:<rxqual-full> RXQUAL SUB: <rxqual-sub>

Downlink Measurements:

DTX (UL) used: not used

RXLEV FULL: <rxlev-full>RXLEV SUB: <rxlev-sub>

RXQUAL FULL:<rxqual-full>RXQUAL SUB: <rxqual-sub>





DTXDLHR=FALSE,


range: TRUE, FALSE

default: FALSE


GSM 05.08

GSM 06.31

Discont inuous transmiss ion dow nl ink for HR ca l ls enab led ,specifies whether ‘discontinuous transmission (DTX)’ (explanationsee DTXUL) is enabled for HR calls in the BTS. For further detailssee parameter DTXDLFR.

DTXUL=SHLFSHNH,


range: MAYFSHNH

SHLFSHNH

SHNFSHNH

MAYFMAYH

SHLFSHLH

SHNFSHLH

default: SHLFSHNH


GSM 05.08

GSM 06.31

Discont inuous transmiss ion up l ink enab led , specifies whetherdiscontinuous transmission (DTX) shall be used by the MS.Discontinuous transmission is a mode of operation in which thetransmitters turn down the sending power if the frames do not containuser information, e.g. during speech pauses. This feature is mainlyused to save battery capacity in the MS; moreover, it helps to keepthe overall radio interference on a low level. Meaning of the possiblevalues:

MAYFSHNH (MS may use DTX for FR TCHs, shall not for HR TCHs).SHLFSHNH (MS shall use DTX for FR TCHs, shall not for HR TCHs).SHNFSHNH (MS shall not use DTX for FR TCHs, shall not for HR TCHs).MAYFMAYH (MS may use DTX for FR TCHs, may use for HR TCHs).SHLFSHLH (MS shall use DTX for FR TCHs, shall for HR TCHs).SHNFSHLH (MS shall not use DTX for Full Rate TCHs, shall for Half Rate TCHs)

This parameter is sent on the BCCH (SYSTEM INFORMATIONTYPE 3) and on the SACCH (SYSTEM INFORMATION TYPE 6) inthe IE ‘Cell Options’.

For more general details about DTX please refer to the descriptions provided for the parameter DTXDLFR.

EARCLM=FALSE,


range: TRUE, FALSE

default: TRUE


Enable ear ly classmark sendin g , this parameter indicates whetherthe “Early Classmark Sending” is enabled or disabled. Changing thisflag just changes a flag in the BCCH (SYSTEM INFORMATIONTYPE 3) in the IE ‘SI 3 Rest Octets’. This flag instructs the MobileStations to start the “Early classmark sending” procedureautomatically for every call transaction, which means that the mobilestation sends a CLASSMARK CHANGE message immediately afterthe first transaction request message (e.g. CM SERVICE REQUEST,PAGING RESONSE, LOCATZION UPDATE REQUEST) to provide

the network with additional classmark information. The BSC forwardsthis information to the MSC within the BSSMAP messageCLASSMARK UPDATE. This is, of course, only possible for thoseMSs that support the early classmark sending option. The ‘ControlledEarly Classmark Sending’ option must be implemented in mobilesthat support e.g. multi-band mode or HSCSD (‘multislot capability’).Thus the flag simultaneously enables/disables the multibandhandovers.

Notes on CLASSMARK REQUEST procedure (started by MSC)

For Location Update procedures, the CLASSMARK CHANGE /CLASSMARK UPDATE procedure can also be explicitly requestedby the MSC. When this is the case, the MSC sends a CLASSMARKREQUEST message (BSSMAP) to the BSC during the call setup.The BSC forwards the request in form of a CLASSMARK ENQUIRY

message (DTAP) to the MS, which answers by starting the usualCLASSMARK CHANGE procedure.

The MSC starts the CLASSMARK REQUEST procedure tointerrogate the CLASSMARK 2 information from the MS. As theCLASSMARK 2 information is already included in the CM SERVICEREQUEST message and the PAGING RESPONSE but not in theLOCATION UPDATE REQUEST message, the MSC starts theCLASSMARK REQUEST procedure only for Location Update. TheCLASSMARK REQUEST procedure is only started on particularconditions: in the Siemens MSC it is only triggered, if in the MSCmobile project description data (MPRDDAT) the set of supportedcipher algorithms is different from ‘A5/1 only’, i.e. when these entries.





indicate that other ciphering algorithms (A5/2, A5/3) are supported. As the CLASSMARK 1 information included in the LOCATIONUPDATE REQUEST message only contains the A5/1 capability, theCLASSMARK REQUEST procedure is started to figure out whetherthe MS also supports the other cipher algorithms allowed in the MSC.

In the Siemens-MSC it is not possible to disable the CLASSMARKREQUEST/CLASSMARK ENQUIRY procedure by databasecommand. The only way to disable this procedure is to switch off the

A5/2 / A5/3 support; this, however, cannot be done in normaloperation, as the command MOD MPRDDAT can only be entered inthe 'Installation Mode' of the MSC. Another possibility is to changethe setting by MSC patch.

Remarks on 2G-3G network archi tectures

The CLASSMARK CHANGE / CLASSMARK UPDATE andCLASSMARK REQUEST /CLASSMARK ENQUIRY procedure is alsoof special interest for 2G-3G network architectures as the networkneeds to be informed about the 3G radio capabilities of the MS.These UMTS radio capabilities are requested from the MS by the IE‘Classmark Enquiry Mask’ which is included in the CLASSMARKENQUIRY message.

Attention: A CLASSMARK ENQUIRY procedure can also betriggered by the BSC without receipt of a CLASSMARK REQUEST

from the MSC. This can happen when an MS, which was handedover from 2G to 3G and returns to the 2G network by a 3G-2Ghandover. If in this case, the HANDOVER REQUEST message doesnot 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 resultingCLASSMARK 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 theCLASSMARK CHANGE message due to 'Early Classmark Sending'is normally sent after the MSC has sent the CIPHER MODECOMMAND (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 MODECOMMAND.

The procedures 'Early Classmark Sending' and CLASSMARKENQUIRY (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 CLASSMARKCHANGE message to the network due to ‘Early Classmark Sending’,even if a CLASSMARK ENQUIRY hes been received and answeredby another CLASSMARK CHANGE message before.

EC=FALSE,


range: TRUE, FALSE

default: FALSE


GSM 02.11

Emergency cal l restr icted , this parameter determines whetheremergency 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 senton 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'





EPRE=DISABLED,



default: DISABLED

Enable Preemp tion , determines whether the feature ‘Preemption’ isenabled. If Preemption is allowed and an incoming highly priorizedTCH request meets a TCH congestion in a cell, existing calls with alower priority are handed over to a suitable neighbour cell by a forcedHO procedure with cause ‘preemption’. If the forced HO procedure isnot successful for the preempted low-priority call is forced released.

In GSM different priorities and access types are supported via the

‘Priority’ IE which is (optionally) conveyed in the ASS REQ and HOREQ message. The ‘Priority’ IE contains the following entries:- The Preemptive Capability Indicator (PCI) applies to the allocationof resources for an event and indicates if the event is able to triggerthe preemption of radio resources.- The Preemptive Vulnerability Indicator (PVI) applies for the entireduration of a connection and indicates whether the connection maybecome a target of preemption.- The Queuing Allowed Indicator (QAI) is used to decide on a per callbasis if queuing may be applied or not.- The Priority Level (PL) is subdivided in 14 different levels, PriorityLevel 1 being the highest value. A priority table which correlates thesubscriber and event dependent priorities and the associated

parameter settings for the ‘Priority’ IE is maintained in the MSC.

The combination of these parameters determines whether anincoming TCH request may lead to a forced HO of an existing low-

priority call for TCH resource provision for high-priorized TCHrequests.

The basic (simplified!) sequence of decision for incoming TCHrequests is1. Preemption -> if not possible, then2. Directed Retry -> if not possible, then3. Queuing

Notes:- The forced handover due to preemption is only attempted if the flagENFORCHO (SET BSC [BASICS]) is set to ENABLE. If this is not thecase the preempted (low-priority) call is immediately released.- One FR call cannot preempt tow HR calls.- One FR call cannot preempt one HR call if one subslot is still idle.- If the feature ‚preemption’ is used for MSC controlled handovers,the handover completion may take a long time due to the additionalhandover of the preempted call in the target cell. This has to beconsidered by setting the timer T7 (see BSCT7 see SET BSC[BASICS]) to a sufficiently high value in the originating BSC.





EQ=DISABLED,



default: DISABLED

Enable queuing , this parameter is used to enable/disable the‘Queuing’ feature for TCH channels. The queuing feature is used to

prevent an immediate rejection if an incoming TCH request(ASSIGNMENT REQUEST received in case of normal assignment ora HANDOVER REQUEST received in case of incoming MSC-controlled handover) cannot be served due to TCH congestion. Ifqueuing is enabled, incoming TCH requests for which queuing is

allowed and which cannot be served via directed retry (see parameter ENFORCHO in SET BSC [BASICS]) are put in a cellqueue based on its priority and the MSC is informed about this

process by the QUEUING INDICATION message. As a general rule,incoming Inter-BSC directed retries are not queued.

Queuing po l icy

The cell queue consists of a set of queue places all having the samecharacteristics. All places may be used by all 14 priority levels. TCHrequests are put into and served by the queue using a first-in, first-out queuing discipline for each priority level (1..14, 1 the highest, 14the lowest priority). Technically each cell has 14 queues, one foreach priority. When a TCH becomes available (i.e. released by the

previous call or it is returned to service) while TCH requests arequeued, the TCH is assigned to the first TCH request of the queue

(with the highest priority) and the TCH request is removed from thequeue. If the queue is full and an incoming TCH request is has ahigher priority than at least one of the queued requests, the TCHrequests in the queue are re-ordered in order to insert the newrequest and to exclude the (youngest) lowest priority one (resulting ina rejection of the TCH request with an ASSIGNMENT FAILURE orHANDOVER FAILURE with cause ‘no radio resource available’). Ifthe queue is full and the new TCH request is lower than the lowestqueued one, the request is rejected in the same way as describedabove.The maximum length of the queue is determined by the parameterQL (see below). Queued TCH requests can be discarded from thequeue a) if further TCH requests with a higher priority are received orb) if (for the TCH assignment case) during the queuing time an

SDCCH HO attempt fails. In these cases an ASSIGNMENT FAILUREmessage (for assignment requests) resp. a HANDOVER FAILUREmessage (for inc. HO requests) with cause ‘no radio resourceavailable’ are sent to the MSC. Moreover, the maximum queuing timeis restricted by administrable timers: for assignment requests themaximum queuing time is determined by the timer T11 (see BSCT11in SET BSC [TIMER]) and for incoming MSC-controlled HO requestsit is determined by the timer TQHO (see BSCTQHO in SET BSC[TIMER]). If T11 expires, the BSC sends a CLEAR REQUESTmessage with cause ‘no radio resource available’ to the MSC and therequesting connection is released. If TQHO expires in case ofincoming MSC-controlled HO, the TCH request is rejected with aHANDOVER FAILURE message using the same cause.Every incoming TCH request contains a set of flags which determine

whether a) ‘queuing’ and b) ‘preemption’ (for details see parameterEPRE below) is allowed for the TCH request.Notes: - 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 ‘notallowed’! 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 CONDITIONINDICATION 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. Ifno 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 hoppingor 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 configuredhopping sequence (see command CREATE FHSY). The number offrequencies in the frequency hopping system (mobile allocation) isrestricted to the number of TRXs configured in the cell. If basebandfrequency hopping is used, it is the hopping system (FHSY) mayinclude also channels of the BCCH TRX.

Synthesizer Frequency Hopping features a continuous re-tuning ofthe TPU/CU in correspondence with the created in correspondencewith the configured hopping sequence. The advantage of synthesizerhopping 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 notallowed) 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 differentTPUs to one BBSIG. The TX and RX paths are tied together byswitching 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. Downlinkdata 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 usedwith multiple TX paths; so there are as many TX/RX pairings for the

call as the number of transmitters in use.Since the mobile reports the measured RXLEV_DL values with afixed period of 480ms (= 104TDMA bursts), no mapping is possibleon TDMA burst base for the DL measurements. Due to the averagingeffect this means that failures in the RF-TX signal path which arelocated 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 basebandfrequency hopping is configured.

In fact the MS will report an RXLEV_DL value which is the average oflevels 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 switchedon respectively an ‘IMSI Detach’ message when they are switchedoff.

If an ‘IMSI Attach’ message is sent to the MSC the mobile subscriberis 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 VLRregards the mobile subscriber as ‘not reachable’ and rejects the callcompletion in case of MTC; paging is not performed in this case.The IMSI attach procedure is only used if the IMSI was deactivatedwhile 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 LAIand 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 LOCATIONUPDATE REQUEST’ message with the parameter ‘Location UpdateType’ set to ‘IMSI Attach’. For the ‘IMSI Detach’ procedure themessage IMSI DETACH INDICATION is used.

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 foraccess to the cell (except for class 10). The information stating whichclasses are barred is sent on the BCCH (SYSINFO Type 1, 2, 3 and4) in the IE ‘RACH Control Parameters’. If the MS receives theindication that its access class is barred it remains camping in the cellbut it is not allowed not perform a RACH access anymore. On themobile phone, there is no special indication on the display if the SIM’s

access 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 semipermanentone, 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 ofaccess classes using NALLWACC is completely independent ofautomatic access class barring due to overload situations in the BSC,BTS or MSC (please see parameters BSCOVLH, BTSOVLH andMSCOVLH 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 MS

receives 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 powerlevel at the PA resp. CU which results in an alarm output to the BTSEcore unit.reducedOutputPowerThreshold = defines the PA resp. CU output

power level to initiate output of a warning.excessiveOutputPowerThreshold = defines the power level when a

major 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 enteredthresholds 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=50,


range: 0..100

default: 50

Queue length , This attribute specifies the maximum number of TCHrequest that can be queued in the cell. This parameter is onlyrelevant if queuing (see parameter EQ) is enabled).

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 VLRnormally leads to the loss of the subscriber data. Periodic location

update 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 runningfrom the value thus contained in memory. On expiry the MS initiatesa location updating. This parameter is sent on the BCCH (SYSTEMINFORMATION TYPE 3) in the IE ‘Control Channel Description’.This timer must be set in consideration of the „Implicit Detach“ timerin the VLR (command in SIEMENS MSC: ENTRMOBTHR: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.

Note: Some parameters of the command SET BTS [OPTIONS] appear at a later position when generated bythe 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 FrequencyHopping 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 forfrequency hopping and CHTYPE for SMS-CB).





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 necessaryto ensure full handover functionality if BS power control is enabledwhile channels are created with frequency hopping system and thehopping system involves the BCCH TRX (baseband frequencyhopping only, see parameter HOPMODE=BBHOP in command SETBTS 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 falsifiedby the ‘full power’ part of the BCCH (PWRC must not be used on theBCCH carrier).

If frequency hopping is configured for the TCHs (see parameterFHSY 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 frequencyredefinition 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 CREATETRX). 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 parameterindicates the opposite (EBSPWRC=CLASSIC orEBSPWRC=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 carrieris 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

New value range in BR7.0!

Enable BS power cont rol , determines whether the BTS dynamicallyadjusts 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 (SYSTEMINFORMATION TYPE 6) in the IE ‘Cell Options’.

Two variants of BS power control can be selected: CLASSIC powercontrol and ADAPTIVE power control. While ‘classic’ BS powercontrol exclusively uses fixed power increase steps (see parameterPWRINCSS) and fixed power reduction steps (see parameterPWREDSS), 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 andclassic and adaptive power control, please refer to the section ‘PowerControl’ 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, initialvalue 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 itcan happen that, e.g. due to excessive path inbalance, the MSreports very good RXLEV_DL values, but the BTS cannot correctlydecode all received SACCH frames in the UL. As the BS powercontrol decision is based on the measurement samples stored in theaveraging window (if an UL SACCH cannot be decoded, this justmeans that no new sample is inserted into the window), theRXLEV_DL average value could suggest a further DL powerdecrease. To avoid this behaviour, the following mechanism wasimplemented:If the S-counter is more than 2 below RDLNKTBS (i.e. either at leastthree SACCH reports in a row were missed or the current SACCHreport is missing and additional SACCHs were missing before) then anormal BTS power increase will be commanded (if the interval timeris 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’, orPAVRQUAL 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 ensuredthat 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

New value range in BR7.0!

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 enabledthe MS adjusts the power according to appropriate commandsreceived from the BTS. The BTS generates these commands afterevaluation of uplink measurement results.

Two variants of MS power control can be selected: CLASSIC powercontrol and ADAPTIVE power control. While ‘classic’ MS powercontrol exclusively uses fixed power increase steps (see parameterPWRINCSS) and fixed power reduction steps (see parameterPWREDSS), 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 andclassic and adaptive power control, please refer to the section ‘PowerControl’ 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 lowerthreshold of the received signal level on the downlink for powerincrease.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 lowerthreshold of the received signal level on the uplink for powerincrease.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 lowerthreshold of the received signal quality on the downlink for powerincrease.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 belowthe threshold determined by LOWTQUAMRDL.

Attention: Unlike for the parameter LOWTQUAD, for which the qualityvalues are entered in RXQUAL values (range 0..7), the values forLOWTQUAMRDL 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 qualityvalues 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 arithmeticmean in accordance with the averaging parameters determined bythe 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 ofRXQUAL and C/I values for AMR calls” in the appendix of this document.

- The integer C/I value is then compared to the threshold determinedby 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 mappingtable above). C/I threshold values above 20dB therefore can neverbe reached and will not show any effect.- In order to achieve a suitable accuracy of the RXQUAL average





averaging 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 lowerthreshold of the received signal quality on the uplink for powerincrease.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 parametereclipses 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 thresholddetermined by LOWTQUAMRUL.

Attention: Unlike for the parameter LOWTQUAU, for which the qualityvalues are entered in RXQUAL values (range 0..7), the values forLOWTQUAMRUL 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 arithmeticmean in accordance with the averaging parameters determined bythe 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 parameterdescription 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 BTSincreases 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 mappingtable 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: allmeasurement 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 glidingaveraging 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 measuredover 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 averagingwindow. 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 windowtwice, while SUB measurement samples from measurement periodswith active DTX (silence) were inserted into the averaging windowonly 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 longerentered n-times into the averaging window anymore but every valuewill be entered once. In addition, the current weighting factor is storedin 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 calculatedby 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: allmeasurement 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 glidingaveraging 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.

For the meaning and management of the DTX weigthing factor please refer to the explanations provided for the parameterPAVRLEV.

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 ofthe RXQUAL average value for AMR calls.





PCMBSTXPRL=15,

object: PWRC

unit: 1 power reduction step = 2dB

range: 0..15

default: 15

Power control maximu m BS TX pow er reductio n Level , this parameter defines the maximum allowed dynamic power reduction.This maximum allowed power reduction affects all calls in the BTS forwhich BS power control is applied.

Basically the limit for the power reduction due to BS power control isdetermined by the lower power control threshold (LOWTLEVD, seebelow), i.e. BS power control does not adjust the power to a levellower than LOWTLEVD. The parameter PCMBSTXPRL, however,

provides another possibility for a limitation of dynamic BS powerreduction which is not related to an absolute DL RXLEV value (likeLOWTLEVD) but to the relative power reduction with respect to themaximum possible DL receive level (that applied before start of

power reduction) for a call.

There are two types of power reduction: static power reduction anddynamic power reduction.

Static power reductio n is a continuous power reduction which isapplied to a particular TRX by the parameter PWRRED (seecommand CREATE TRX). The purpose of this parameter is basicallyto adapt the transmit power of the used CU or PA type to the actualsize and radio propagation conditions of a particular cell.

Dynamic power reduct ion is performed by BS or MS power control

in order to adjust the MS and BS transmit level in correspondencewith the radio conditions of an individual call.

PCMBSTXPRL determines the maximum dynamic power reductionwhich may be applied to a call in the cell. This reduction is applied inaddition to the static power reduction that may have been set by the

parameter PWRRED. However, the sum of both static and dynamic power reduction can never exceed the maximum possible powerreduction steps supported by the BTSE (related to the maximumnominal output power of the used CU resp. PA), which depends onthe type and generation of BTSE in correspondence with thefollowing table.

Band

BTS type

GSM900 &

GSM850

DCS1800 PCS1900

eMicro (BS-82) 42 dB 42 dB 42 dB

Pico BTS (BS-242) 30 dB 30 dB 30 dB

BTSplus (main) 46 dB 36 dB 36 dB

BTS1 (e.g. BS-60) 30 dB 30 dB 30 dB

PCONINT=2,

object: PWRC

unit: 2 SACCH multiframes

range: 0..31

default: 2


Power control interval , defines the minimum time period (in units of2 SACCH multiframes) between two successive modifications of theBTS or MS transmission power level. I.e. the BTS or MS powercontrol decision will be suspended after a new power level was set,for as long as the timer has not expired.

In other words: At the end of every measurement period the powercontrol (PWRC) algorithm determines whether a power increase ordecrease is necessary based on the current BTS/MS averaged leveland quality values (see also averaging window settings

PAVRLEV/PAVRQUAL). In case a power level was changed a timerwith the length defined by PCONINT is started (immediately if theBTS power level was changed and in case of a MS power levelchange only after the MS has confirmed the new power level – seealso PWRCONF). While this timer is running (there are independenttimers for BTS and MS PWRC) the PWRC algorithm continues to fillthe respective level and quality averaging windows with newmeasurement samples. In order to allow for the most exact PWRCdecisions the averaging windows should be filled completely withnew measurement samples that reflect the state after the power levelchange. Therefore the value of PCONINT should correspond to thesize of the level or quality averaging window (whichever is longer):





e.g. PAVRLEV/PAVRQUAL=4-x # PCONINT=2, wait 4 SACCHmultiframes (since the granularity of PCONINT is 2 SACCHmultiframes 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 EBSPWRCand 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 withouthaving to wait for the collection of new level samples. Since thesuspension timer is now only started in case of quality baseddecisions 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' PWRCmode!

PCRLFTH=18,

object: PWRC

range: 0..64

default: 18Reference: GSM 05.08

Power control radio l ink fai lure threshold , this parameter is onlyrelevant if the parameter EPWCRLFW (see above) is set to TRUE. Itdefines the threshold value for the radio link counter in the BTS forthe ‘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


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 bythe 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 levelwith 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 managedfor every dedicated channel (TCH or SDCCH). Unsuccessfuldecoding of uplink SACCH messages (i.e. MEASUREMENTREPORTs) 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 linkcounter counter reaches the value entered for the parameterPCRLFTH (see above) the BTS initiates the adjustment of the MStransmit power and BS transmit power to maximum transmit power. Ifthe counter reaches the value 0 (‘radio link timeout’), the BTS sendesa CONNECTION FAILURE INDICATION with cause 'radio linkfailure' to the BSC which initiates the release of the whole dedicatedconnection. This scenario represents (together with the ERRORINDICATION 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 anytransmission 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 particularSACCH period, no PC decision will be made for the DL. If the‘missing SACCH’ counter (S-counter, initial value defined by

RDLNKTBS) is more than 2 below RDLNKTBS (i.e. either at leastthree SACCH reports in a row were missed or the current SACCHreport is missing and additional SACCHs were missing before) then anormal 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-dependentsetting 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 forthis service group is based the ordinary PWRC parameter settings.

Fo further details please refer to the section “ Service dependentHandover 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 controlddecision for this service group is based the ordinary PWRC

parameter settings.

Fo further details please refer to the section “ Service dependentHandover 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: 35


Power control upper threshold level down l ink , defines the upperthreshold of the received signal level on the downlink for powerreduction.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 intracellhandover, 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 = -48dBm63 = greater than -48dBm

range: 0..63

default: 35


Power control upp er threshold level upl ink , defines the upperthreshold of the received signal level on the uplink for powerreduction.The following rule has to be considered:UPTLEVU (SET PWRC)

> [LOWTLEVU (SET PWRC) + 2 ∗ PWREDSS (SET PWRC)]> LOWTLEVU > HOLTHLVUL (SET HAND)

To guarantee a correct interworking of power control and intracellhandover, the following rule must be fulfilled:

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%7 = greater than 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 qualityvalues 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 qualityvalues 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 arithmeticmean in accordance with the averaging parameters determined bythe 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 determinedby 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 mappingtable above). C/I threshold values above 20dB therefore can neverbe 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 parametereclipses the threshold UPTQUAU in case of an AMR (Adaptive MultiRate) call: For AMR calls, the power control algorithm reduces the ULtransmit power if the uplink quality exceeds the threshold determinedby UPTQUAMRUL.

Attention: Unlike for the parameter UPTQUAU, for which the qualityvalues are entered in RXQUAL values (range 0..7), the values forUPTQUAMRUL 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 arithmeticmean in accordance with the averaging parameters determined bythe 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 parameterdescription of UPTQUAMRDL (see above).- The integer C/I value is then compared to the threshold determinedby 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 mappingtable 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 powerreduction.The following rule has to be considered:UPTQUAU (SET PWRC) < LOWTQUAU (SET PWRC)< HOLTHQUUL (SET HAND)





Power Control Parameter Relations

Power Control

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

LOWTLEVU

LOWTQUAU

(is for AMR replaced byLOWTQAMRUL)

UPTLEVU

UPTQUAU

(is for AMR replaced by

UPTQAMRUL)

EBSPWCR

PCMBSTXPRL

MS Power Contro l

PWRC: EMSPWRC

LOWTLEVD

LOWTQUAD

(is for AMR replaced byLOWTQAMRDL)

UPTLEVD

UPTQUAD

(is for AMR replaced by

UPTQAMRDL)

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 burstused on uplink PDCH (PACCH or PRACH). The value ACBU8BITmeans 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 powerBased 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.

BEPAVGP=5,

object: PTPPKF

range: 0..15

default: 5


Bit error probabi l i ty averaging period , this parameter is broadcastinside the (packet) system information messages PSI1, PSI13 orSI13. It is used in the mobile as filter constant for EGPRS channelquality 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: UNIT400Reference:

recommended value : 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 BLERvalue is used as base for the link adaptation algorithm (dynamicswitch 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 calculatedaccording 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: UNIT400

Reference:

recommended value : UNIT100

Block error rate averaging period upl ink , this parameter is relevantfor GPRS and EDGE and is used as averaging period for the BlockError 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 ofblocks reserved for PAGCH, PDTCH and PACCH for the 52 framesmultiframe case (see GSM 05.02). The parameter is coded accordingto 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 parameterBS_PAG_BLKS_RES.Note: The system does not refuse entering senseless values whichmay cause blocking of the PBCCH functionality itself (e.g. reserving12 PAGCH blocks leaving no PPCH blocks!).





BPRACHR=4,

object: PTPPKF

range: 0..12

default: 4


BS PRACH blocks reserved , this parameter specifies the number ofblocks reserved in a fixed way to the PRACH channel on any PDCHcarrying 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 parameterBS_PRACH_BLKS.

Note: Also for this parameter the system does not refuse enteringsenseless values which may cause blocking of the PBCCHfunctionality itself (e.g. reserving 0 PRACH blocks allows no more

packet accesses in the cell!).

BSCDVMA=10,

object: PTPPKF

range: 1-15

default: 15



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 blockindicating 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 similarto: 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 codedaccording 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 parameterBS_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 willreduce the reported leak rate ‘R’ inside the FLOW-CONTROL-BVCPDU, thus limiting the amount of data being sent from the SGSNtowards 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 BucketSize (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 oftimeslots that can be assigned to GPRS/EDGE in this cell multipliedby 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 basedon 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 reselecthysteresis (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 parameterC31_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 parameterC32_QUALIFIER.





CACKTYP=0,

object: PTPPKF

range: 0..1

default: 0


Contro l acknowledgement typ e , this parameter indicates the formatof the PACKET CONTROL ACKNOWLEDGEMENT message the MSshall transmit when polled. The meaning of the parameter values is:

0 PACKET CONTROL ACKNOWLEDGEMENT format is fouraccess 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 parameterCONTROL_ACK_TYPE.

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 packettransfer mode may be moved out of the cell for load balancing

purpose.

The GPRS traffic control strategy is based on the feature NetworkControlled 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 neighbourcells. 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 parameterTRFHITH (see command SET HAND [BASICS]) for CS call ‘traffichandover’.

CRESELTHRINP=75,

object: PTPPKF

range: 0.. 85

default: 75

Reference:

Cel l reselect ion threshold in put , this parameter specifies the

maximum traffic load threshold allowed in a cell to be considered as potential target. Please refer to the parameter CRESELTRHSOUT forfurther details.

Note: CRESELTHRINP is a kind of equivalent to the parameterTRFLTH (see command SET HAND [BASICS]) for CS call ‘traffichandover’.

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 ifthe same parameter available in the BSC object was set to TRUEalready (see parameter CSCH3CSCH4SUP in command SET BSC[BASICS]). Please refer to the aforementioned parameter in the BSCobject for further details.





DRXTMA=0,

object: PTPPKF

range: 0..7

default: 7


Maximum discont inuous rece ip t t imer , this parameter indicatesthe maximum time allowed for the mobile station to request for Non-DRX mode after packet transfer mode. Each MS selects the valuethat it prefers and forwards this info within the ATTACH REQUESTmessage towards the SGSN.

The parameter is coded according to the following table andbroadcast on the BCCH/PBCCH within the PSI1 and (P)SI13

messages:0 0 0 No Non-DRX mode after packet transfer mode0 0 1 1 sec. non-DRX mode after packet transfer mode0 1 0 2 sec.0 1 1 4 sec.1 0 0 8 sec.1 0 1 16 sec.1 1 0 32 sec.1 1 1 64 sec.

This parameter corresponds to the GSM parameterDRX_TIMER_MAX.

EGPLGPEIGHTTS=16,

object: PTPPKF

range: 8..64, <NULL>default: 16

Reference:

EGPRS pol l ing per iod eight t im e slots , this parameter specifies the polling period to be used if eight timeslots are assigned. Its value isgiven in units of RLC-blocks; e.g. 16 means that every 16

th DL data

block is polled. This results in a polling period of 320ms in case asingle PDCHis allocated and only 40ms in case 8 PDCHs areallocated to that TBF.

The polling period is a decisive factor in case RLC/MACacknowledged mode is used. The more often the network polls themobile for EPDAN messages, the earlier it can retransmit notacknowledged RLC/MAC blocks. This generally helps to increase thedata transfer speed under real network conditions (BLER>0).

EGPLGPFIVETS=16,

object: PTPPKF


default: 16

Reference:

EGPRS pol l ing p er iod five time slots , this parameter specifies the polling period to be used if five timeslots are assigned.

EGPLGPFOURTS=16,

object: PTPPKF


default: 16

Reference:


EGPRS pol l ing per iod fou r t ime slots , this parameter specifies the polling period to be used if four timeslots are assigned.

EGPLGPONETS=8,

object: PTPPKF


default: 16

Reference:


EGPRS pol l ing p er iod one time slot , this parameter specifies the polling period to be used if one timeslot is assigned.

EGPLGPSEVENTS=16,

object: PTPPKF


default: 16

Reference:

EGPRS pol l ing p er iod seven time slots , this parameter specifies

the 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: 16

Reference:


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: 16

Reference:


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 PTRmessages 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: PTPPKF


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: PTPPKFrange: WS64, WS96, WS128,

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,

EGPRS wind ow s ize seven time slots , this parameter specifies thewindow size to be used if seven timeslots are assigned.





WS544, WS576, WS608,

WS640, WS672, WS704,

WS736, WS768, WS800,

WS832, WS864, WS896,

<NULL>

default: WS896

Reference:

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 windowsize 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, ifrequired, to a lower or higher coding scheme. The decision is basedon two internal tables. The use of the two different tables is controlledby 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).

EMCSFAMA1DL=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE

Enable MCS family A MSC1 downl ink , this parameter enables allcoding schemes belonging to Family A plus MCS1 to be used fordownlink 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 allcoding 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 allcoding schemes belonging to Family B plus MCS1 to be used fordownlink 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 allcoding schemes with GMSK modulation to be used for downlinkTBFs.

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 notsupported in BR70. In downlink direction IR is applied by the BSCand all mobiles have to support it according to specifications.

EMFAP1UNIR8PSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family A padding MCS1 upl ink withou t incremental

redundancy 8PSK , this parameter enables all coding schemesbelonging to Family A Padding plus MCS1 to be used for uplinkTBFs.

Family A consists of: MCS3, MCS6; MCS8


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 schemes

belonging to Family B plus MCS1 to be used for uplink TBFs.Family B consists of: MCS2, MCS5; MCS7


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 belongingto Family C to be used for uplink TBFs in case the MS does notsupport 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 codingschemes (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 codingschemes (MCS1-MCS4) to be used for uplink TBFs in case the MSdoes not support 8PSK.





FDDGQO=10..20,

object: PTPPKF

range: ALWAYS MDB28

MDB24 MDB20

MDB16 MDB12

MDB08 MDB04

DB00 DB04 DB08

DB12 DB16 DB20DB24 DB28

default: DB0

FDD GPRS Q offs et , this parameter is related to multiRAT MSsconsidering a reselection towards an FDD cell; it indicates an offsetwhich is applied to the RLA_P value of the serving cell.



DBxx = xxdBm (e.g. DB20 = 20dBm)

The value ALWAYS indicates an infinite negative offset, so with thissetting a 3G Mobile will always change to the 3G network if anyacceptable 3G cell is available (see parameter GFDDQMI).

This parameter corresponds to the GSM parameterFDD_GPRS_Qoffset.

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 powercontrol parameter and is sent to the MS within an RLC controlmessage (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: 20ThresholdIdleChanEU: 20

GPRS al location strategy thresh olds , defines the thresholds forthe system to switch between horizontal and vertical GPRS channelallocation (and back). It consists of three fields:

ThresholdIdleChanHV defines the point when the allocation strategyis switched from horizontal to vertical: If less than(ThresholdIdleChanHV) percent of CS-only and CS/PS-sharedtimeslots are idle, vertical allocation is enabled.

ThresholdIdleChanVH defines the point when the allocation strategyis switched back from vertical to horizontal: If more than(ThresholdIdleChanVH) percent of CS-only and CS/PS-sharedtimeslots 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 parameterGMANPRES only on thoseTRXs with GSUP=TRUE. They are notconsidered at all within the above load calculations.- Idle shared timeslots are all available timeslots in the cell that canhandle both GPRS and CS services (GSUP=TRUE and notreserved).

- Idle CS-only timeslots are all available timeslots in the cell on TRXswith GSUP=FALSE.- 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.





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 hysteresisto be subtracted from the C32 value of the neighbour cells if the MSis in ready state and the neighbour cell belongs to the same routingarea. 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 parameterGPRS_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 MEASUREMENTREPORTs sent by GPRS attached mobiles.

This parameter corresponds to the GSM parameterFDD_MULTIRAT_REPORTING.

Note: This p arameter is n ot 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 consideredas suitable neighbour.

This parameter corresponds to the GSM parameter FDD_Qmin..

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 parameterFDD_REP_QUANT.

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 cellreselection procedure.

This parameter corresponds to the GSM parameterPRIORITY_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 parameterindicates 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 uplinkdirection, the second one indicates the maximum number of MS thatcan be multiplexed on a PDCH in downlink direction.

The total amount of TBFs multiplexed on a PDCH is limited





GMANPRES =4,

object: PTPPKF

unit: 1

range: 0..190

BR7.0: Parameter renamed from

GMAPERTCHRES to GMANPRES,the parameter range changed!

GPRS maxim um numb er of PDCH reserved , this parameterdefines the number of timeslots exclusively reserved for GPRSservices. These timeslots are dynamically reserved only on thoseTRXs which are created with GSUP=TRUE (see command CREATETRX).

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 parameterindicates for each priority level 1 to 4 the maximum number ofretransmission allowed on the PRACH. The parameter value consistsof 4 fields, each field indicates the maximum number ofretransmissions allowed for the affected priority level. Priority 1represents the highest priority. For each Radio Priority x parameterthe 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 transm ission po wer on PBCCH/PCCCH . GMSTXPMAC defines the maximum power level that maybe used by the mobile to access the cell on the PRACH. The validvalues and meanings are the same as defined for the parameterMSTXPMAXCH (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 parameterGPRS_MS_TXPWR_MAX_CCH.

GNMULBAC=<NULL>,

object: PTPPKFrange: 0..3

default: <NULL>


GPRS Numb er of mult i band c el ls , this parameter is relevant forGPRS network-controlled cell reselection in dualband configurations.

It is the GPRS equivalent to the parameter NMULBAC (seecommand CREATE BTS [BASICS]) and used by GPRS attachedmobiles 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 andallowed NCC part of BSIC, irrespective of the band used.1 - The MS shall report the strongest cell, with known and allowedNCC 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 andallowed 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 identifiedcells in the other bands irrespective of the band used.3 - The MS shall report the three strongest cells, with known andallowed 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 identifiedcells in the other bands irrespective of the band used.

GPATH=PKAAP4,

object: PTPPKF

range: PKANA

PKAAP1 - PKAAP4

default: PKAAP4Reference: GSM 04.60

GPRS prior i ty access th reshold , this parameter indicates whetheror 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 parameterPRIORITY_ACCESS_THR.

GPDPDTCHA=100,

object: PTPPKFunit: 1% range: 0..100

default: 30


GPRS Percentage of dy namic PDTCH Avai lable , this parameterindicates 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 forTCH) and for which the superordinate TRX is in service and availablefor GPRS service (GSUP=TRUE, see CREATE TRX).

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 roundeddown). Whether these TCHs may be preempted respectivelydowngraded for circuit-switched calls, depends on the setting of the

parameter DGRSTRGY (see SET BSC [BASICS]).

Note: Modification of the GPDPDTCHA setting is only possible, if thePTPPKF object is in administrative state ‘locked’.

GPENTIME Cancelled - in BR7.0 this parameter is only available in ADJC object

GRESOFF Cancelled - in BR7.0 this parameter is only available in ADJC object





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 equivalentRXLEVAMI (object BTS).

It is used together with other parameters to calculate the path losscriteria C1 and C32 for cell selection and reselection. SettingGRXLAMI 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 PBCCHcarriers 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 SYSTEMINFORMATION 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 requiredfor a valid RLA_P:

RLA_P = 1/5 ∗ (GPRS_RXLEV1 + GPRS_RXLEV2 + .. .+ GPRS_RXLEV5)

The path loss criterion C1, the minimum signal level criterion forGPRS/EGPRS cell selection and cell re-selection, is calculated bythe 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 underparameter 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 byGRXLAMI: 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 calculatedin 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 parameterGPRS_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 fieldis 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 MEASUREMENTREPORTs sent by GPRS attached mobiles.

This parameter corresponds to the GSM parameterTDD_MULTIRAT_REPORTING.

Note: This p arameter is n ot relevant in B R7.0

GTEMPOFF Cancelled - in BR7.0 this parameter is only available in ADJC object

GTXINT=3,

object: PTPPKF

range: 0..15

default: 3


GPRS transmis sion interval , this parameter defines the number ofslots to spread transmission of the random access on PRACHchannel. 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

range: TRUE, FALSE, <NULL>

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 inthese 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 receivedlevel (RLA_P). In addition the MS verifies the BSIC of the BCCHcarriers. Only cells with allowed BSIC are considered for re-selection

purposes.

If a GPRS MS works in packet transfer mode it monitors continuouslyall BCCH carriers as indicated by the BA(GPRS) list and the PBCCHcarrier of the serving cell. In every TDMA frame, a received signal

level measurement sample is taken on at least one of the BCCHcarriers, one after the another. RLA_P is an average valuedetermined 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 measurementsamples are required for a valid RLA_P value. The MS shall attemptto check the BSIC for each of the 6 strongest non-serving cell BCCHcarriers 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 parameter3G_SEARCH_PRIO.

IMCSULNIR8PSK =MCS3,

object: PTPPKF

range: MCS1, MCS2, MCS3,

MCS4, MCS5, MCS6,

MCS7, MCS8, MCS9

<NULL>

default: MCS6

recommended value: 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 thatBVC is available (see parameter STGTTLLIINF). If the BSC isinformed about the EDGE capability (e.g. 2-phase access or EDGEPACKET CHANNEL REQUEST was used) of this mobile, it uses the

value 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 EDGEPACKET 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: PER50

Reference:

recommended value: 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 necessaryto 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 parameterINITIAL_CODING_SCHEME.

INIMCSDL =MCS6,

object: PTPPKF

range: MCS1, MCS2, MCS3,

MCS4, MCS5, MCS6,

MCS7, MCS8, MCS9

<NULL>

default: MCS9

recommended value: 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 otherinformation about that MS in that BVC is available (see parameterSTGTTLLIINF). 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).

MSBHIPER=PER70,

object: PTPPKF


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 thereported 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 furtherdecreased.


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 SGSNmay increase the data rate sent towards the BSC.






MSBMAPER=PER100,

object: PTPPKF




PER100, PER110, PER120,


PER160, PER170, PER180PER190 PER200

default: PER100

Reference: GSM08.18

MS bucket max percentage . defines the value of the ‘MS BucketSize’ (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 sharingthat 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 Bmaxreported 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.


NAVGI=10,

object: PTPPKF

range: 0..15

default: 10


N averaging interference , this attribute represents an interferingsignal 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 parameterestablishes the threshold concerning the C1 value for networkcontrolled 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,DB30default: 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 from

C32 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 servingcell 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 thatbelongs to the same routing area like the serving cell. If the BSCfinds 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 routingarea have no priority compared to the adjacent cells of other routingareas and the BSC will select the best suitable cell for cellreselection, 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 switchedcontro l thresho ld , this parameter specifies the traffic load thresholdin percent below which no more mobiles are moved out of a cell dueto traffic reasons. Please refer to the parameter CRESELTRHSOUTfor 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 reports

NC2: 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 PACKETMEASUREMENT ORDER at the beginning of each TBF indicatingNC2 for the respective mobile. Before the TBF is terminated, theNetwork Control Order is reset to NC0. NC1 is not used at all in

within BR70.This parameter corresponds to the GSM parameterNETWORK_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 setNC1/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 parameterNC_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 parameterPC_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 onlyin case the value of PERSTLVPRI1 is less or equal to R.

Therefore a high value of PERSTLVPRI1 decreases the probability ofa 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







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 to

decrease counter N3102 in case T3182 expires without havingreceived 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 toincrease counter N3102 in case a PACKET UPLINK ACK/NACKmessage was correctly received by the MS. N3102 cannot exceedthe value set by PKTNMA. Refer also to parameters PKTNDEC andPKTNMA.

This parameter corresponds to the GSM parameter PAN_INC.

PKTNMA=4,

object: PTPPKF



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 reaches

the 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 powerreduction value used by the BTS on PBCCH blocks, relative to theoutput power used on the BCCH. It is broadcast within the PACKETSYSTEM 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 UMDB86UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66

OMDB62 OMDB58 OMDB54

NEVER

default: NEVER

Q Search p r ior i ty , this parameter is broadcast on the PBCCH anddefines a threshold condition under which the Mobile shall monitorand 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 “xxdB” threshold value, the neighbour cell shall be considered forreporting.- 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 forreporting.- 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 PBCCHwithin the PSI3 message.

This parameter corresponds to the GSM parameterRANDOM_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,


Routing area colour , this attribute is used by the mobile to identifythe specific routing area. Due to the fact that the RACODE can be

smaller 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 differentby network planning.

RAENV=HIGHDIV,

object: PTPPKF

range: HIGHDIV, LOWDIV

default: HIGHDIV

Radio environm ent , this parameter specifies the radio environmentin 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 bylow user mobility (pico cells, indoor cells, or MSs have a speed lowerthan 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 appliedfor the Link Adaptation (LA) feature if EDGE is used. In case ofHIGHDIV, coding scheme downgrades are started already at lowerBLER values compared to the LOWDIV case (means earlier). Codingscheme 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 ofan adjacent cell belonging to a different routing area than the servingcell. The value is applied in both GMM standby and ready state of themobile.

This parameter corresponds to the GSM parameterRA_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 RESOURCEREQUEST (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 the

scheduling weight associated to scheduling priorities 3.Please refer to SCHWEIPRI1 for further details.

SCHWEIPRI4=1,

object: PTPPKF

range: 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.

STGTTLLIINF=60,

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 lastused coding scheme and BLER of a certain TLLI (=mobile) after itterminated 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: 7



T3168 , is a timer used on the mobile side. It defines when the MSstops waiting for a PACKET UPLINK ASSIGNMENT message after ithad asked for new uplink resources (via PRR, (E)PDAN or PCA). Itsvalue plus one must be multiplied by 500 msec. to obtain the realvalue broadcast in (P)SI 1/13.

T3192=0,


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.





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 offsetwhich is applied to the RLA_P value of the serving cell.



DBxx = xxdBm (e.g. DB20 = 20dBm)

The value ALWAYS indicates an infinite negative offset, so with thissetting a 3G Mobile will always change to the 3G network if anyacceptable 3G cell is available).

This parameter corresponds to the GSM parameterTDD_GPRS_Qoffset.

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 abnormalrelease with cell reselection towards a new cell (see parameterRAARET), the MS shall not reselect back to the original cell forT_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 =60,

object: PTPPKF

unit: 1s

range: 1..100

default:5

Reference:

Traff ic packet switch ed control t imer , this parameter indicates thetime period to estimate the GPRS cell traffic load.

Note: In BR7.0 this parameter can be set but has no effect on thesystem.

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 TRXs:

CREATE TRX:

NAME=BTSM:0/BTS:0/TRX:0,

Object path name .

GSUP=TRUE,

object: TRX

range: TRUE, FALSE

default: FALSE

GPRS Supported , this parameter indicates if GPRS/EDGE services

are supported by this TRX or not. If GSUP=FALSE, the TCHssubordinate to the TRX are exclusively used for circuit-switchedtraffic. If GSUP=TRUE, the TCHs may be used for GPRS traffic aswell. How exactly the subordinate channels can be used depends onthe setting of the channel data (see command CREATE CHAN).

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 particularTRX. In other words, any cell access, signaling transaction or callwhich 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 LPDLMobject(s) for the responsible BTSM. The distinction between theLPDLM messages (O&M messages between BSC and BTSM) andthe LPDLR messages (TRX-specific radio signaling communicationbetween BSC and BTS/TRX) is made on the basis of the LAPD

addressing 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 TEIin command CREATE BTSM), the radio signalling messages relatedto a particular TRX are always signaled with SAPI=0 and the TEI no.which is automatically assigned to the TRX during the BTSEalignment (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 TRXshall be performed. If only one LPDLM is created for a particularBTSM, of course, only this LPDLM number can be selected forLPDLMN. 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 sharingdistribution 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), theradio signalling messages of the affected TRX are automaticallytransmitted 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 only restriction to be considered in thiscase is the fact that the possible traffic volume will be limited due tothe unavailability of a part of the Abis TCH resources.





Please see also the parameters TEI (in command CREATE BTSM), ABISCH (in command CREATE LPDLM) and the explanations provided for the command CREATE SUBTSLB.

MOEC=TRUE,

object: TRX

range: TRUE, FALSE

default: TRUE

Member of emergency con figurat ion , this parameter determineswhether a TRX belongs to the 'Emergency Configuration' or not (seealso 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 HWassociated 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 powershould 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 parameterCONCELL in command CREATE BTS [BASICS]) this parameter

determines the different ranges of inner and complete area TRXs itmust be set in accordance with the setting of the parameterTRXAREA (see below)! If a cell is configured for support of thefeature “Common BCCH for GSM 900/1800 or GSM850/1900 DualBand Operation”, the use of the PWRRED might not

Rules:1) To avoid 'ping pong' handovers between inner and complete areathe following rule should be followed:

HORXLVDLO - HORXLVDLI > (PWRREDinner - PWRREDcomplete ) [dB]

This rule is mainly relevant for single-band concentric cells, as insuch configurations the coverage difference between inner andcomplete area is controlled by the PWRRED parameter.

However, if in the cell the feature “Common BCCH for GSM 900/1800

or GSM850/1900 Dual Band Operation” is used, the coveragedifference is mainly determined by the different transmission powervalues of the used CU resp. PA modules. In this case the rule shouldbe expressed as follows:

HORXLVDLO - HORXLVDLI > BS_TXPWR_MAX COMPL - BS_TXPWR_MAX INN

(for the parameters HORXLVDLI and HORXLVDLO see commandSET HAND [BASICS]).

2) To avoid 'ping pong' handovers between the inner and completeareas in sectorized concentric cells the following rule must befollowed:

HOM coloc > (PWRREDinner - PWRREDcomplete ) [dB]

'HOM coloc ' is the handover margin set for an adjacent cell object thatrepresents a 'colocated cell' (see parameter CCELL in command

SET HAND [BASICS]).





RADIOMG=254,

object: TRX


range: 1-254

default: 254

Radio measurement granular i ty for measurements on Abis ,specifies the granularity periods for retrieval of the measurementreports which are to be sent on the Abis interface in case they areenabled. If the Abis has to be traced for radio diagnostic of handover

performance diagnostic reasons it is recommended to set the radiomeasurement granularity to ‚1’ because only in this case allmeasurement reports from the MS and the BTS will be transmitted on

the Abis. However, it has to be considered that the enabling of theRadio Measurements on the Abis interface cause an additional loadon the LPDLR links: the lower the value for RADIOMG, the higher thesignalling load on the LPDLRs.

RADIOMR=OFF,

object: TRX

range: ON, OFF

default: OFF

Radio measurement reports , specifies whether radio measurementreport transmission via the Abis interface is enabled. Since in theSBS the preevaluation of measurement reports for handoverdecisions 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 itresults 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 ‘timingadvance’ in order to ensure that the BTS receives the burst within theguard period. This instruction from BTS to MS is called ‘timingadvance 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 (see

command 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, ifthe TRX-HW which is associated to the created TRX object an EDGECU (ECU).

Only if TRXMD is set to EDGE for the BCCH TRX, it is possible to setthe parameter EBCCHTRX (command SET PTPPKF, see nextcommand) 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 ofPWRRED (see above)!

- the BCCH frequency and all other frequencies with control channels(CCCH, SDCCH) must belong to the complete area (see commandCREATE CHAN).

TRXFREQ=CALLF01,

object: TRX

range: BCCHFREQ,

CALLF01.. CALLF63


GSM 05.08

TRX frequency , assigns a radio frequency to a transceiver. FromBR6.0 on the radio frequency assigned to the TRX is no longerrepresented by its absolute radio frequency number (ARFCN) but byits relative number CALLFxx which was assigned to the frequencyduring creation of the BTS cell allocation (please refer to the

parameters CALLF01..CALLF63 and BCCHFREQ in the commandCREATE BTS [BASICS]). If the TRX represents the BCCH carrier,the value of TRXFREQ must be BCCHFREQ.

Enabling GPRS and EDGE in a cell:

< The specific parameters related to the enabling of GPRS andEDGE 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 forthe 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:


(if BCCH TRX is equipped with ECU)

EGPRS 8PSK on BCCH TRX , this parameter indicates if EDGE8PSK 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 beequipped with ECU in this case, as in case of automatic BCCHreconfiguration, the BCCH TRX might be served by a different TRX-HW branch.

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 onlybe 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 (see parameterGSUP in command CREATE TRX),





Creating the Frequency Hopping systems:

CREATE FHSY:

NAME=BTSM:0/BTS:0/FHSY:0,

Object path name .

AMRFRC1= RATE_01,

object: FHSY


RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08,

<NULL>

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 case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. This parameter eclipses itsequivalent parameter in the BTS object (see parameter AMRFRC1 incommand CREATE BTS [BASICS]) if frequency hopping is currentlyactive for an AMR call. If frequency hopping is disabled - no matterwhether semipermanently (i.e. HOPP=FALSE) or only temporarily(e.g. in case of baseband hopping with CU failure), the equivalent

parameter of the BTS package will be considered.

Whether the AMR parameter set defined in the BTS object or the onedefined in the FHSY object is used for a particular call is determinedby the BSC, which sends the AMR parameter set to the BTS in theCHANNEL ACTIVATION and to the MS in the ASSIGNMENT

COMMAND (resp. HANDOVER COMMAND in case of inter-cellhandover).

For further details about the parameter values and AMR parametersand thresholds please refer to the parameter AMRFRC1 in thecommand SET BTS [OPTIONS].

AMRFRC2= RATE_03,

object: FHSY


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 case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. This parameter eclipses itsequivalent parameter in the BTS object (see parameter AMRFRC2 incommand CREATE BTS [BASICS]) if frequency hopping is currentlyactive for an AMR call.

For further details about the parameter values and AMR parameters

and thresholds please refer to the parameter AMRFRC1 in thecommand SET BTS [OPTIONS].

AMRFRC3= RATE_06,

object: FHSY


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 case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. This parameter eclipses itsequivalent parameter in the BTS object (see parameter AMRFRC3 incommand CREATE BTS [BASICS]) if frequency hopping is currentlyactive for an AMR call.






AMRFRC4= RATE_08,

object: FHSY


RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08,

<NULL>

default: RATE_08

AMR Full 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 case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. This parameter eclipses itsequivalent parameter in the BTS object (see parameter AMRFRC4 incommand CREATE BTS [BASICS]) if frequency hopping is currentlyactive for an AMR call.


AMRFRIC=

START_MODE_FR,

object: FHSY

range: START_MODE_FR

CODEC_MODE_01

CODEC_MODE_02

CODEC_MODE_03

CODEC_MODE_04 default: START_MODE_FR

AMR Full Rate Initial Codec , this parameter defines which AMR FRCODEC of the created AMR FR ACS shall be used first after FR TCHassignment in case of frequency hopping (see also parameter HOPPin command SET BTS [OPTIONS]. The values CODEC_MODE_0xrepresent the created AMR FR CODECs (AMRFRCx) of the ACS.This parameter eclipses its equivalent parameter in the BTS object(see parameter AMRFRIC in command CREATE BTS [BASICS]) iffrequency 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 in the

command SET BTS [OPTIONS]. AMRFRTH12=7-4,

object: FHSY



hysteresis: 0.5dB






AMR Ful l Rate Thresholds 12 , this parameter defines the C/Ithreshold and the associated hysteresis for the AMR downlinkCODEC mode adaptation transition from AMRFRC1 to AMRFRC2and vice versa in case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS].

This parameter eclipses its equivalent parameter in the BTS object(see parameter AMRFRTH12 in command CREATE BTS [BASICS])if frequency hopping is currently active for an AMR call.


AMRFRTH23=12-4,

object: FHSY



hysteresis: 0.5dB






AMR Ful l Rate Thresholds 23 , this parameter defines the C/I

threshold and the associated hysteresis for the AMR downlinkCODEC mode adaptation transition from AMRFRC2 to AMRFRC3and vice versa in case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS].

This parameter eclipses its equivalent parameter in the BTS object(see parameter AMRFRTH23 in command CREATE BTS [BASICS])if frequency hopping is currently active for an AMR call.






AMRFRTH34=23-4,

object: FHSY



hysteresis: 0.5dB





AMR Ful l Rate Thresholds 34 , this parameter defines the C/Ithreshold and the associated hysteresis for the AMR downlinkCODEC mode adaptation transition from AMRFRC3 to AMRFRC4and vice versa in case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS].

This parameter eclipses its equivalent parameter in the BTS object(see parameter AMRFRTH34 in command CREATE BTS [BASICS])

if frequency hopping is currently active for an AMR call.


AMRHRC1= RATE_01,

object: FHSY


RATE_03, RATE_04,

RATE_05, <NULL>

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 case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. This parameter eclipses itsequivalent parameter in the BTS object (see parameter AMRHRC1 incommand CREATE BTS [BASICS]) if frequency hopping is currentlyactive for an AMR call.

For further details about the parameter values and AMR parametersand thresholds please refer to the parameter AMRFRC1 in the

command SET BTS [OPTIONS]. AMRHRC2= RATE_02,

object: FHSY


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 case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. This parameter eclipses itsequivalent parameter in the BTS object (see parameter AMRHRC2 incommand CREATE BTS [BASICS]) if frequency hopping is currentlyactive for an AMR call.


AMRHRC3= RATE_03,

object: FHSYrange: RATE_01, RATE_02,

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 case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. This parameter eclipses itsequivalent parameter in the BTS object (see parameter AMRHRC3 incommand CREATE BTS [BASICS]) if frequency hopping is currentlyactive for an AMR call.


AMRHRC4= RATE_04,

object: FHSY


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 case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. This parameter eclipses itsequivalent parameter in the BTS object (see parameter AMRHRC4 incommand CREATE BTS [BASICS]) 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 in thecommand SET BTS [OPTIONS].





AMRHRIC=

START_MODE_HR,

object: FHSY

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 HRCODEC of the created AMR HR ACS shall be used first after HRTCH assignment in case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS]. The valuesCODEC_MODE_0x represent the created AMR HR CODECs(AMRHRCx) of the ACS. This parameter eclipses its equivalent

parameter in the BTS object (see parameter AMRHRIC in command

CREATE BTS [BASICS]) if frequency hopping is currently active foran AMR call.


AMRHRTH12=19-4,

object: FHSY



hysteresis: 0.5dB






AMR Half Rate Thresh olds 12 , this parameter defines the C/Ithreshold and the associated hysteresis for the AMR downlinkCODEC mode adaptation transition from AMRHRC1 to AMRHRC2and vice versa in case of frequency hopping (see also parameterHOPP in command SET BTS [OPTIONS].

This parameter eclipses its equivalent parameter in the BTS object(see parameter AMRHRTH12 in command CREATE BTS [BASICS])if frequency hopping is currently active for an AMR call.


AMRHRTH23=24-4,

object: FHSY



hysteresis: 0.5dB









AMRHRTH34=30-4,

object: FHSY



hysteresis: 0.5dB



default: threshold: 30 [15.0 dB] (BTS+)

<NULL> (BTS1)






HSN=10,

object: FHSY

range: 0..63


GSM 04.08

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 HANDOVERCOMMAND if it was assigned to the used channel. If frequencyhopping is enabled the parameter H is set to 1. In this case the IEalso 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 cellallocation frequencies used in the hopping sequence. This parameteris sent in the main DCCH in the IE ‘Mobile Allocation’, which iscontained in the ASSIGNMENT COMMAND and in the HANDOVERCOMMAND. This IE ‘Mobile Allocation’ is a bit map in which e.g. forevery frequency contained in the 'cell allocation frequency list' an ownbit position is provided. The 'cell allocation frequency list' is derived

from the set of frequencies defined by the reference 'Cell ChannelDescription' 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 cellallocation frequency list the absolute RF channel numbers are placedin 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 nolonger represented by their absolute radio frequency number(ARFCN) but by their relative number CALLFxx which was assignedto 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 onlyconsist of TRX frequencies of the complete area) and one for theinner area (MOBALLOC may only consist of TRX frequencies of thecomplete area.)





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 onlyCCCH = 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 channelBCBCH = FCCH + SCH + BCCH + CCCH* + SDCCH/C4 (0..3) +

SACCH/C4 (0..3) + CBCHNotes:- 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 usedcontrol 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 CCCHactivities on the basis of their “CCCH_GROUP”. The CCCH_GROUPis calculated from the last three digits if the IMSI and the CCCHconfiguration (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 SDCCHavailable 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 commandCREATE BTS [BASICS]) all frequencies with common controlchannels (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 usedin '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: 0..10

default: 0 = no hopping


GSM 04.08

GSM 12.20

Frequency hopping sy stem identi f ier , 0(=no hopping) is mandatoryfor the BCCH.

MAIO=0,

object: CHAN

range: 0..63

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 the BCC(part of the BSIC sent on the SCH, see CREATE BTS [BASICS]

parameter BSIC) so that the MS can derive the TSC of the BCCHfrom the SCH. This is necessary for the correct selection and

decoding of the BCCH bursts, especially if within a limitedgeographical 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:

CREATE CHAN:


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. SACCHSDCCH = SDCCH/C8 (0..7) + SACCH/C8 (0..7)b) SDCCH/8 plus SMS cell broadcast channelSCBCH = 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 CHANcommand 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 SDCCHavailable; only one CBCH is allowed per cell.- In a concentric cell (see parameter CONCELL in commandCREATE BTS [BASICS]) all frequencies with SDCCHs must belongto the complete area.- In an extended cell (CELLTYPE=EXTCELL, see commandCREATE BTS [BASICS]), all SDCCHs must be created as ‘double’timeslots (EXTMODE=TRUE, see below).- When an Abis interface is configured via satellite, it is urgentlyrecommended to configure multiple SDCCH channels on differentTRXs. This is necessary because the Abis LAPD transmit queues inthe BTS are managed per TRX(TEI), i.e. each TRX (TEI) has an own





transmit queue. As the biggest percentage of all signalling activitiesin a cell are processed via the SDCCHs, it is recommended, to avoidan 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’ willconsiderably 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 usedin '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=2,

object: CHAN

range: 0..10



GSM 12.20

Frequency hopping sy stem identi f ier , 0=no hopping, all othervalues ‘X’ must have been created for this cell (BTS) before byCREATE 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 parameterINTCLASS in command SET BTS) while frequency hopping is active,the BTS measures the interference considering all frequencies usedin the hopping sequence assigned to the a TCH in the frequencyhopping system!

MAIO=0,

object: CHAN

range: 0..63


GSM 04.08

Mobi le al location index offset , start position of the channel in thefrequency hopping algorithm.

(TSC=),

object: CHAN

range: 0..7


(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 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 ofthe BSIC sent on the SCH, see CREATE BTS [BASICS] parameterBSIC).If no value is entered for the parameter TSC the system automaticallyselects the BCC (see parameter BSIC (CREATE BTS [BASICS])) as

TSC.





Creating the TCHs for the cell:

CREATE CHAN:


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/TFNotes:- A dual rate TCH can also be created as follows:CHTYP=TCHSD,CHPOOLTYP=TCHPOOL (see next CREATECHAN command for TCH/SDs).- The FR portion of the TCH always implies speech versions FR, EFRand AMR FR; the HR portion implies HR and AMR HR. Whichspeech version is used for TCH assignment depends on the MS

capability 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 usedin '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 commandCREATE 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 willalways take place to a 'double' timeslot first as the BTS can onlydetermine the actual MS-BTS distance when the first MS messagesare received. If the MS-BTS distance turns out to be small enough fora 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled).

FHSYID=1,

object: CHAN

range: 0..10



GSM 04.08

GSM 12.20

Frequency hopping sy stem identi f ier , 0=no hopping, all othervalues Y must have been created before byCREATE FHSY:NAME=bsc:n/bts:n/fhsyid:y.Notes:- If synthesizer frequency hopping is used, hopping is not allowed forany 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 parameterINTCLASS in command SET BTS [INTERF]) while frequencyhopping is active, the BTS measures the interference considering allfrequencies used in the hopping sequence assigned to the a TCH inthe frequency hopping system!





GDCH=<NULL>,

object: CHAN

range: <NULL>

PBCCH, PCCCH,

default: <NULL>

GPRS Dedicated Channel , this parameter determines the TCHconfiguration 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 ControlCHannelc) <NULL> identifies a “shared” TCH. Shared TCHs can be used forGPRS and circuit switched traffic. All TCHs (TCHFULL, TCHF_HLF

and TCHSD with CHPOOLTYP=TCHPOOL) for which GDCH is setto <NULL> (and for which the superordinate TRX was created withGSUP=TRUE) belong to the pool of TCHs that can be used for bothcircuit-switched calls and GPRS calls (so-called “Shared trafficchannels”). The number of these TCHs that may be aligned asPDCHs simultaneously is determined by the parameterGPDPDTCHA (see CREATE PTPPKF). Whether the GPRS calls canbe preempted by CS calls depends on the setting of the downgradestrategy (see parameter DGRSTRGY in command SET BSC).

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 the

circuit 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 alreadycreated PBCCH.- If no PBCCH is defined in the cell, the GPRS system information isbroadcast on the existing (GSM-)BCCH within the SYSTEMINFORMATION 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

range: 0..63

default: 0


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. Iffrequency hopping is enabled the parameter H is set to 1. In this case

the IE also contains the HSN together with the MAIO.

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

Terrestr ia l channel , 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


(CREATE BTS [BASICS])Reference: GSM 05.02

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 the

TCH. This is necessary for the correct decoding of the TCH.If no value is entered for the parameter TSC the system automaticallyselects the BCC (see parameter BSIC (CREATE BTS [BASICS])) asTSC.







CREATE CHAN:


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 forthe features ‘ Smooth Channel modification ’ and ‘ Set Command forChanges 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 channeltype TCHSD represents a channel, that can worka) as pure Dual Rate TCH,b) as pure SDCCH/8 orb) can dynamically change between both modes (DR-TCH orSDCCH/8).

Which of these operation modes is in effect, depends on the settingof 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 transmitqueues in the BTS are managed per TRX(TEI), i.e. each TRX (TEI)has an own transmit queue. As the biggest percentage of allsignalling activities in a cell are processed via the SDCCHs, it isrecommended, to avoid an excessive concentration of the SDCCHsignalling within one TRX (and thus one LPAD transmit queue), todistribute multiple SDCCHs over different TRXs within the cell.Otherwise the probability of the BTSE alarm ‘LAPD TRANSMITQUEUE OVERFLOW’ will considerably increase, although with amore even distribution of the signalling load over the TEIs this couldbe 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 definesits 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 configurationcompared 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 thesystem-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 mode (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 SDCCHassignment).

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 this

case 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 usedin '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 SETHAND [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 willalways take place to a 'double' timeslot first as the BTS can onlydetermine the actual MS-BTS distance when the first MS messagesare received. If the MS-BTS distance turns out to be small enough fora 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled).





FHSYID=1,

object: CHAN

range: 0..10



GSM 04.08

GSM 12.20

Frequency hopping sy stem identi f ier , 0=no hopping, all othervalues Y must have been created before byCREATE FHSY:NAME=bsc:n/bts:n/fhsyid:y.Notes:- If synthesizer frequency hopping is used, hopping is not allowed forany 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 parameterINTCLASS in command SET BTS [INTERF]) while frequencyhopping is active, the BTS measures the interference considering allfrequencies used in the hopping sequence assigned to the a TCH inthe frequency hopping system!

GDCH=<NULL>,

object: CHAN

range: <NULL>

default: <NULL>

GPRS Dedicated Channel , this parameter determines the TCHconfiguration 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 CHANobject belongs to the system-internal TCH_POOL. In thisconfiguration only the value <NULL> is allowed for GDCH – this valueindicates that the TCHSD works as “shared” TCH, i.e. the TCHSDcan 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 forthe the parameter combinationCHTYP=TCHSD,CHPOOLTYP=TCHPOOL

MAIO=0,

object: CHAN

range: 0..63


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.

TERTCH=0..2-3,

object: CHAN

range: PCMB: 0..34


1-24 (PCM24)

subslot-no.: 0..3

terrestrial channel, parameter structure: pcmb-no. - timeslot no. - subslot-no.

(TSC=),

object: CHAN

range: 0..7


(CREATE BTS [BASICS])Reference: GSM 05.02

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 tothe 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 automaticallyselects 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 (nowsubordinate to the BTS object) and appear in the DBAEM in the SETHAND command. The logical group “[BASICS]” is normally only usedon the LMT but was used here to allow a more useful grouping of thecommands .

NAME=BTSM:0/BTS:0/HAND:0,

Object path name .

ALEVFULHO=2-1,

object: HAND [BASICS]


(averaging period)


1-3 (DTX weight. factor)default: 2 (averaging period)


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 handoverdecision. The first field, aLevFuHo, defines the averaging windowsize (that is smaller than the normal window size), the second one,wLevFuho, indicates the DTX weighting factor. As the fast uplinkhandover should react quite quickly to UL level drops, the averagingwindow should be significantly smaller than that of other handovertypes (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 REPORTfrom the MS which contains the ‘DTX used’ flag. This flag determineswhether the BTS must enter the FULL values (if DTX was not used inthe measurement) or the SUB values (if DTX was used in themeasurement period) into the averaging window for the handoverdecision (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 ofthe 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 itby the FULL value (the number of FULL values inserted depends on

the DTX weighting factor). This algorithm reduces the handoverdecision 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 RXLEVmeasurements, the approach for fast uplink handover is differentfrom the one of the other handover types: while for all other handovertypes the size of the averaging window for the neighbour celldownlink RXLEV measurements is determined by the parameterHOAVPWRB (see below), which generally defines a comparativelylong averaging period, the averaging window for the neighbour cellmeasurements 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 offera sufficient DL RXLEV at that particular point of time. This meansthat, if the default value is used (ALEVFULHO=2-1), this means thatthe suitable neighbour cell for fast uplink handover is derived fromonly one Measurement Report.

AMRACMRDL=5,


unit: 1 CMR

range: 1..63

actual range: 1..31 !

default: 5

Handover averaging parameters for AMR CODEC MODE

REQUESTs , this parameter defines the size of the averaging windowfor 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 ofthe downlink CODEC mode in case of instable or quickly varyingradio conditions.

The Periodicity of the CMR sending depends on whether DTX uplinkis currently used or not. If DTX uplink is not used, the CMR is sentevery 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 the

downlink - executed by the TRAU) is considerably slowed down bythe 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 CODECMODE 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 CODECmode 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 mode

change decision, to avoid a ‘too nervous’ link adaptation reaction incase of quickly changing radio quality conditions.- The averaging mechanism for the uplink AMR CODEC modeadaptation is independent of AMRACMRDL as the associatedaveraging mechanisms are hardcoded.- although the parameter AMRACMRDL is included in the SET HANDcommand, it has no relevance for the handover decisions for AMRcalls.





CCDIST=FALSE,


range: TRUE, FALSE

default: FALSE

Enable concentr ic cel l distance handov er , this flag determineswhether in the concentric cell (see parameter CONCELL in commandCREATE BTS [BASICS]) the distance should also be taken intoaccount for the intracell handover decision and for the channelassignment decision during call setup.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 (forhandover) are fulfilled or if the MS-BTS distance exceeds thedistance limit according to the principles explained for the parameterHOCCDIST.

- 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 explainedfor 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 parameterCONCELL in command CREATE BTS [BASICS]) to which anintercell handover from inner-to-inner area shall be possible, resp. forwhich 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”.

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-innerhandover. 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 handoveris enabled (INTERCH=TRUE, see below).





DPBGTHO=FALSE,


range: TRUE, FALSE

default: FALSE

Dynamic power bu dget handover , this parameter determineswhether ‘dynamic power budget’ handover or ‘speed sensi t ivehandover ’ is active. This flag is only relevant if power budgethandover is enabled (PBGTHO=TRUE.) Speed sensitive handover ise.g. used for micro-/umbrella-cell configurations. An umbrella cellcovers the same area as a number of microcells and is normally usedas handover target cell in case of microcell congestion or for MSs

which move very fast. Speed sensitive handover shall allow powerbudget handovers to a microcell if an MS moves slow but shall

prohibit them if the MS moves fast in order to avoid unnecessarysignaling load due to repeated handovers (if the MS moves fast itmay have left the microcell already when the handover is actuallyexecuted). For this reason the power budget handover to a microcellis delayed by a special timer (the microcell is ‘penalized’ as long asthe timer runs). If the handover conditions are still present when thetimer expires the handover is executed. The timer is administeredwith the parameter HOMDTIME (CREATE ADJC). It is, however, onlyin 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>,


range: TRUE, FALSE, <NULL>

default: <NULL>

Enable advanced compressio n decompression hando ver , this parameter is used to enable/disable the feature ‘advancedcompression/decompression handover’ algorithm which wasintroduced by CR1632 in BR7.0.

AMR comp ress ion handover

The purpose of AMR compression handover is to transfer AMR FRcalls with suitably good radio link quality to an AMR HR TCH in orderto use the TCH resources more efficiently. The Intracell AMRcompression handover is not continuously enabled in the BTS, but istemporarily enabled / disabled by the BSC (by sending the Abis O&Mmessage SET ATTRIBUTE to the BTS) depending ona) the current radio TCH load of the cell (see parametersEHRACTAMR in command SET BSC [BASICS] and HRACTAMRT1in command CREATE BTS [BASICS]) orb) the current Abis pool TCH load of the BTSM (see parameters

ABISHRACTAMR and ABISHRACTTHR in command CREATEBTSM).

AMR Decompress ion handover The purpose of AMR decompression handover is to transfer AMR HRcalls with poor radio link quality to an AMR FR TCH in order toimprove the speech quality.Important: In contrast to the AMR compression handover the intracell

AMR decompression handover is continuously enabled and iscompletely independent of the current BTS radio TCH load or Abis

pool TCH load.

Please note that AMR compression/decompression handover cannot

be disabled by database command (it is, however automaticallydisabled 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 to switchbetween different modes of AMR compression/decompressionhandover (standard or advanced).

AMR co mpress ion/decompress ion handover decis ion

Standard AMR Compression Handover (EADVCMPDCMHO=FALSE)Setting the flag EADVCMPDCMHO to FALSE simply means that the

AMR compression handover decision is done in the same way as inBR6.0. In this case the AMR compression and decompression





handover decision is solely based based on quality (C/I) criteriadefined by the parameters HOTHAMRCDL, HOTHAMRCUL,HOTHAMRDDL and HOTHAMRDUL (see below).

Standard AMR Compression hando ver decision cr i ter ia

(EADVCMPDCMHO=FALSE) An AMR compression handover from AMR FR to AMR HR istriggered if for a particular AMR FR call the following conditions arefulfilled:

(C/I_UL > HOTHAMRCUL)AND

(C/I_DL > HOTHAMRCDL)

Standard AMR Decomp ression handov er decision cr i ter ia

(EADVCMPDCMHO=FALSE) An AMR de-compression handover from AMR HR to AMR FR istriggered if for a particular AMR HR call the following conditions arefulfilled:

(C/I_UL < HOTHAMRDUL)OR

(C/I_DL < HOTHAMRDDL)

Advanced AMR Compression Handover(EADVCMPDCMHO=FALSE)The advanced AMR compression/dedcompression handoveralgorithm additionally considers the current level conditions and thecurrent dynamic power reduction due to BS and MS power control.This is done by considering an additional level threshold and bycomparing the C/I thresholds to a C/I value that was ‘corrected’ bythe corrent power reduction.

In this context the new parameters HOTHCMPLVDL,HOTHCMPLVUL, HOTHDCMLVDL and HOTHDCMLVUL (seebelow) are considered.

The new BR7.0 AMR compression handover decision is based onthe rules listed below:

Adv anced AMR Comp ression handover decision cr i ter ia

(EADVCMPDCMHO=TRUE) An AMR compression handover from AMR FR to AMR HR istriggered if for a particular AMR FR call the following conditions arefulfilled:

{[(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 (EADVCMPDCMHO=TRUE)

An AMR de-compression handover from AMR HR to AMR FR is

triggered if for a particular AMR HR call the following conditions arefulfilled:

{[(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 AMR com press 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 ofBER 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 errors

have 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 addingC/I to the current MS/BS_PWRRED (power reduction due to powercontrol) 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 continuouslychanging 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 handoverwhereas an unlimited C/I measurement would have prevented this.

To avoid unjust i f ied decompression handover in transient phase,irrespective of whether C/I was considered in the primary condition ornot, the following additional conditions for decompression aretherefore taken into account:

1. C/I is smaller than a certain threshold, e.g. C/Imax, oralternatively, 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 ornot, 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 withthe primary conditions the following expression shall be used totrigger compression handover (must be fulfilled for both, xx = UL, DL;measurements C/I are different entities for both links but not markedas such in the following for the sake of simplicity):

[(RXLEVxx > hoThresComprLevxx) AND (C/I >= C/Imax)] OR(C/I + MS/BS_PWRRED > hoThresAMRComprxx)

Decompression handover shall be triggered if the sum of C/I andMS/BS_PWRRED (power reduction due to power control) is lowerthan the decompression handover threshold.

To avoid unjustified decompression handover during the transient phase (e.g. immediately after compression handover) a furthercondition has to be fulfilled: C/I has to be lower than C/Imax. This

avoids that in case of unproper setting of the decompressionhandover threshold, the decompression handover is triggeredimmediately after allocating the call on the HR channel (PR = 0 andhoThresAMRDecompr > 20 dB). An alternative conditions to

C/I < C/Imax

is

RXLEV < hoThresDecomprLev

This will avoid that e.g. a MS close to the BTS will perform unjustifieddecompression handover.





Notes on averaging

With each new channel activation the channels averaging windowsare initialized and in case of the HO quality averaging windows theyare initialized to RXQUAL=0 (i.e. C/I=20). The point of time of the first

AMR compression/decompression handover decision depends onthe type (FR, HR) of activated TCH:

1) If a FR TCH is activated the BTS starts checking fordecompression only when the HO quality averaging windows for UL

and DL are completely filled for the first time (i.e. (HOAVQUAL *480ms(SACCH-period time) + 480ms (results of first SACCH-periodare not entered in averaging windows)), so that in this case theinitialization value does not have any influence (otherwise it mightlead to an unjustified compression HO right away).

2) If a HR TCH is activated the radio conditions are checked rightaway (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).

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 (parameterINTRACH, see below) due to quality (for a call whose quality is still

poor after decompression handover), the features ‘Cell loaddependent actvation of half rate’ (see parameter EHRACT incommand CREATE BTS [BASICS]) and ‘Abis load dependentactivation of half rate’ (see parameter ABISHRACTTHR in commandCREATE BTSM) are not considered if the BSC receives anINTRACELL HANDOVER CONDITION INDICATION due to qualityreasons (cause values ‘uplink quality’ or ‘downlink quality’). Thismeans that the BSC does not check the current BTS TCH load andthe BTSM Abis pool TCH load in case of an intracell handover due toquality.

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 intercellhandover is enabled (INTERCH=TRUE, see below). Fast UplinkHandover 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 levelhandover mechanism is often too slow to ‘rescue’ the call as a thestandard level handover normally uses small but not very smallaveraging 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 is

completely de-coupled from the PWRC algorithm, i.e. fast uplinkhandover is immediately triggered if the UL receive level drops belowthe fast uplink handover threshold THLEVFULHO, no matter whetherthe MS transmit power is already at the maximum or not.

To qualify an adjacent cell as a suitable target cell for fast uplinkhandover, an additional administrable level offset is consideredduring the handover decision (see parameter FULRXLVMOFF in the

ADJC object). Moreover, it is possible to priorize specific adjacentcells in the ranking of the target cells by a flag in the ADJC data (see

parameter FULHOC in the ADJC object).

For further details please refer to the section ‘Handover Thresholds





and Algorithms’ in the appendix of this document.

Note: If the BTS transmits a HANDOVER COMMAND for a fastuplink 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 andreceived/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 (commandCREATE/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 flagdetermines whether the feature 'Limitation of Intracell handoverrepetition’ is enabled or not. It enables a mechanism that prevents anunlimited repetition of intra-cell handovers due to quality (see

parameter INTRACH in command SET HAND [BASICS]) and AMRCompression (see parameter EADVCMPDCMHO in command SETHAND [BASICS]).

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 particularcall) 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-cellhandover is desired, if intra-cell handovers do not lead to better radioconditions, especially if frequency hopping is used. If the flagELIMITCH 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 'handoversuccessful'. This message leads to the start of an administrable timer(see parameter TINOIERCHO) in the BTS which suppresses thegeneration of further INTRACELL HANDOVER CONDITIONINDICATION messages with cause ‘quality’ as long as the timer runs.If in this period a suitable neighbour cell is found an inter-cellhandover is attempted.

b) Limitation of Intracell Handover due to AMR CompressionSince BR6.0 the same mechanism as described above is also usedfor AMR Compression Handover (Intracell handover AMR FR ->

AMR HR, see parameter HOTHANRCDL) and AMR decompressionhandover (Intracell handover AMR HR -> AMR FR, see parameterHOTHAMRDDL). Tests have shown that, if the quality conditions are

near to the quality thresholds for AMR compression/decompressionhandover, a ping-pong between AMR compression handover and

AMR decompression handover may occur. For the “Limitation AMRCompression Handover Repetition” an own counter is implementedin the BSC, which is increased whenever the BSC executes an AMRcompression handover (i.e. sends a CHANNEL ACTIVATION afterreceipt of an appropriate INTRACELL HANDOVER CONDITIONINDICATION). If this counter reaches the threshold MAIRACHO (seeabove) due to continuous ping-pong between AMR compressionhandover and AMR decompression handover, the next CHAN ACTmessage the BSC sends for an intracell AMR compression handovercontains the GSM08.08 cause 'handover successful'. This message





leads to the start of the timer (see parameter TINOIERCHO) in theBTS which suppresses the generation of further INTRACELLHANDOVER CONDITION INDICATION messages with cause ‘AMRcompression’ for the same cause as long as the timer runs.Note: For quality intracell handover, this feature only works if thequality intra-cell HO is controlled by the BSC (LOTRACH=TRUE).

EUBCHO=FALSE,

object: HAND [BASICS]range: TRUE, FALSE

default: FALSE

Enable UMTS better cel l h andover , this parameter represents thedatabase flag to enable or disable ‘better cell’ handover from GSM to

UMTS (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 ‘bettercell’ is only possible if the measurement reporting of the multiRATmobiles is based on RSCP (level-oriented), i.e. the parameterFDDREPQTY (see command CREATE BTS [BASICS]) must be setto the value RSCP.

Setting this EUBCHO=TRUE simply means that 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 powerbudget handover decision process, even if they have been createdas neighbour cells in the BSC database (see commands CREATETGTFDD and CREATE ADJC3G).

Of course, different minimum criteria and better cell criteria apply forUMTS FDD neighbour cells than for for GSM 2G neighbour cells:- While for GSM neighbour cells the minimum receive level forhandovers is defined by the parameters RXLEVMIN (see commandCREATE 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 powerbudget handovers is defined by the parameter HOM (see commandCREATE ADJC), the ‘better cell’ radio requirement for UMTS FDD

neighbour 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 atthe same time, i.e. it is up to the operator to decide which type ofhandover shall be used for a particular cell.

Note: Handover from GSM to UMTS (2G-3G handover) is onlysupported starting from BR7.0 step2.

EUHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS handover , this parameter represents the database

flag to generally enable or disable handover from GSM to UMTS (2G-3G handover). Only if EUHO=TRUE the parameters EUBCH (seeabove), EUIMPHO and EUSCHO (see below) are relevant.






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’, ‘downlinkquality’, 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, exclusivelydepends on the handover-type-specific settings of theabovementioned database flags resp. parameters. If EUIMPHO is setto FALSE, the BTS excludes these 3G cells from the target cell listduring 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 neighbourcells than for for GSM 2G neighbour cells.- While for GSM neighbour cells the minimum receive level forhandovers is defined by the parameters RXLEVMIN (see commandCREATE ADJC), the minimum radio requirements for UMTS FDDneighbour cells are defined by the parameter RXLEVMINC (ifFDDREPQTY 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).






EUSCHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS suff ic ient c overage handover , this parameterrepresents 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 andapplies it to all UMTS neighbour cells that were created in the BSCdatabase (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 parameterFDDREPQTY (see command SET BTS [BASICS]):- If FDDREPQTY is set to RSCP (level-oriented measurementreporting based on RSCP), the minimum target cell level requirementis defined by the the parameter USRSCP (see command CREATE

ADJC3G).- If FDDREPQTY is set to ECNO (quality-oriented measurementreporting based on Ec/No), the minimum target cell qualityrequirement 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 thresholddefined by

UMTS handover due to ‘better cell’ (see parameter EUBCHO) andUMTS handover due to ‘sufficient coverage’ cannot be enabled at thesame time, i.e. it is up to the operator to decide which type ofhandover 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 cellhandover' means an intra-cell handover from near to far (singleTS-to-doubleTS) or from far to near (doubleTS-to-singleTS). This handoveris 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 smallenough 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 ADJCobject, 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 ifintercell handover is enabled (INTERCH=TRUE, see below).

The selectable ranking methods RANK0 and RANK1 are onlyrelevant 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 priorityNeighbour cells with the same priority are sorted byPBGT(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 byPBGT(n) - HO_MARGIN(n).

For further details please refer to the section ‘Handover Thresholds & Algorithms’. The term ‘levelOffsetNcell’ represents the parameterLEVONC (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 flagis 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 continouslymeasured 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: allmeasurement 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 averagingwindow 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.





HOAVELEV=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 RXLEVmeasurements for level handovers. It is only relevant if intercellhandover 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: allmeasurement 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 HOAVELEV “averaging period” defines the size of the glidingaveraging 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 measuredover 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 averagingwindow. 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 windowtwice, while SUB measurement samples from measurement periodswith active DTX (silence) were inserted into the averaging windowonly 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 longerentered n-times into the averaging window anymore but every value

will be entered once. In addition, the current weighting factor is storedin 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 HOAVELEV). The averaging window total is thencalculated by adding up all sample values currently stored in thewithin the averaging 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 beginningof a call, as the BTS can trigger an 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 receivedand 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 RXLEVmeasurements 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 RXLEVvalues of the serving cell (considering the current power reduction bythe 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 UplinkHandover), as it is used for the averaging of the downlink RXLEVvalues of the neighbour cells.

All measurements for handover pass an averaging algorithm. Thealgorithm can be described as a “gliding” averaging window: allmeasurement 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 averagingwindow for the measured RXLEV values. The size of the averagingwindow determines the number of measurement samples (a newmeasurement 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 byHOAVPWRB also for the averaging of the neighbour cell DL RXLEVmeasurements for all other handover types (except Fast UplinkHandover). It is important, however, to point out that for theneighbour cell DL RXLEV measurements HOAVPWRB justdetermined 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 forthe uplink and downlink RXQUAL measurements.


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 glidingaveraging window for the measured RXQUALvalues. 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 measuredover a period with voice activity (DTX not active). The higher

weighting is achieved by the multiple insertion of the measurementsample into the gliding averaging window. In other words, if the DTXweighting factor is set to “2”, FULL measurement samples frommeasurement periods with inactive DTX (speech transmitted) areinserted into the averaging window twice, while SUB measurementsamples from measurement periods with active DTX (silence) areinserted into the averaging window only once.

Fo For the meaning and management of the DTX weigthing factor please refer to the explanations provided for the parameterPAVRLEV.

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 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 measurementsamples. For quality handovers, the averaging window is initializedwith 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 RXLEVmeasurements 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 onlyrelevant if the parameter CCDIST is set to TRUE (see above). Itdetermines the distance limit used for the 'distance' intracellhandover decision within the concentric cell and for the channelassignment 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 handoveroscillation 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 handoverdecision. 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...30

default: 8

Handover lower threshold qual i ty AMR downl ink , this parametereclipses the threshold HOLTHQUDL in case of an AMR (AdaptiveMulti Rate) call: For AMR calls, an intercell handover due to qualitydownlink is triggered if the downlink quality drops below the thresholddetermined by HOLTHQAMRDL. This parameter is only relevant ifintercell 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 qualityvalues 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 arithmeticmean in accordance with the averaging parameters determined bythe 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 determinedby HOLTHQUAMRDL. If it drops below the threshold, the BTStriggers an intercell handover due to “downlink quality”.

Notes:- Although the total value range of HOLTHQUAMRDL is 0..30, themapping limits the maximum useful C/I value to 20dB (see mappingtable above). C/I threshold values above 20dB therefore can neverbe 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 RXQUAL

averaging window size of 4 (see parameter HOAVQUAL).





HOLTHQAMRUL=8,


unit: 1 dB

range: 0...30

default: 8

Handover lower threshold qual i ty AMR upl ink , this parametereclipses 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 byHOLTHQAMRDL. This parameter is only relevant if intercellhandover 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 qualityvalues 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 arithmeticmean in accordance with the averaging parameters determined bythe 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 determinedby HOLTHQUAMRUL. If it drops below the threshold, the BTStriggers an intercell handover due to “uplink quality”.

Notes:- Although the total value range of HOLTHQUAMRDL is 0..30, themapping limits the maximum useful C/I value to 20dB (see mappingtable 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).

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 handoverdecision. 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 handoverdecision. 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 thresholdfor 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 onlyrelevant for extended cells (see parameter CELLTYPE in commandCREATE/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 thresholdthe 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 handoverdecisions for extended cell handovers (see parameter EXTCHO incommand SET HAND [BASICS]) between the areas (far-to-near ornear-to-far handovers). To avoid ping-pong handovers an additionalmargin (parameter HOMRGTA, see above) is applied to this

threshold.Rule: HOMSTAM < HOTMSRME (HAND) < EXCDIST (BTS[options])





HORXLVDLI=26,


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:- To avoid 'ping pong' handovers between inner and complete areathe following rule should be followed:


This rule is mainly relevant for single-band concentric cells, as insuch configurations the coverage difference between inner andcomplete area is controlled by the PWRRED parameter (seecommand CREATE TRX).

- If in the cell the feature “Common BCCH for GSM 900/1800 DualBand Operation” is used, the coverage difference is mainlydetermined by the different transmission power values of the usedCU resp. PA modules. In this case the rule should be expressed asfollows:






HORXLVDLO=32,


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 concentriccell (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 whetherthe 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 “Common BCCH for GSM900/1800 or 850/1900 Dual Band Operation” is used, the call setupand intracell handover decision considers the difference in themaximum allowed transmission power (derived from the parametersMSTXPMAXGSM, MSTXPMAXDCS and MSTXPMAXPCS, seeCREATE BTS [BASICS]) and the MS power capability in the bandused 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-innethandover 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:


This rule is mainly relevant for single-band concentric cells, as insuch configurations the coverage difference between inner andcomplete area is controlled by the PWRRED parameter (seecommand CREATE TRX).

- If in the cell the feature “Common BCCH for GSM 900/1800 orGSM850/1900 Dual Band Operation” is used, the coveragedifference is mainly determined by the different transmission power

values of the used CU resp. PA modules. In this case the rule shouldbe expressed as follows:


Note:The intracell handover causes “complete to inner” and inner tocomplete” do not exist for SDCCH-SDCCH handover as in aConcentric 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 .

To guarantee a correct interworking of power control and intracell

handover, the following rule must be fulfilled:

UPTLEVD > HOTDLINT


HOTHAMRCDL=23,


unit: 1 dB

range: 0...30

default: 23

Handover thresho ld AMR com press ion downl ink , this parameterrepresents the downlink quality threshold used to trigger an intracell

AMR Compression Handover "fullrate to halfrate”.

From BR7.0 on the AMR compression and decompression handoverdecision can be based on both quality and level conditions. The exactconditions for the initiation of an AMR compression anddecompression handover as well as references to the quality related

parameters are contained in the description for the parameterEADVCMPDCMHO (see above).

Important: In contrast to the AMR de compression handover (see parameter HOTHAMRDDL), the AMR compression handover (AMRfullrate 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/Ivalues (carrier/interference in [dB]). The BTSE-internal processing ofthese values is done in the following way:- Like any other MS, the AMR mobile reports the downlink qualityvalues 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 bythe 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 parameterdescription of HOLTHQAMRDL (see above).- The integer C/I value is then compared to the threshold determinedby HOTHAMRCDL. If it exceeds the threshold (and HOTHAMRCULis exceeded, too!), the BTS triggers an intracell handover due to

AMR compression.

Notes:- Although the total value range of HOTHAMRCDL is 0..30, the

mapping limits the maximum useful C/I value to 20dB (see mappingtable 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).





HOTHAMRCUL=23,


unit: 1 dB

range: 0...30

default: 23

Handover thresho ld AMR c ompress ion up l ink , this parameterrepresents 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 (AMRfullrate 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 ofHOTHAMRCUL (see above)!

HOTHAMRDDL=10,


unit: 1 dB

range: 0...30default: 23

Handover thresho ld AMR d ecompress ion downl ink , this parameter represents the downlink quality threshold used to triggeran intracell AMR Decompression Handover "halfrate to fullrate".

From BR7.0 on the AMR compression and decompression handover

decision can be based on both quality and level conditions. The exactconditions for the initiation of an AMR compression anddecompression handover as well as references to the quality related


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 qualitydrops 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/Ivalues (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 qualityvalues 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 arithmeticmean in accordance with the averaging parameters determined bythe 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 parameterdescription of HOLTHQAMRDL (see above).- The integer C/I value is then compared to the threshold determinedby 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 mappingtable 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=10,


unit: 1 dB

range: 0...30

default: 23

Handover thresho ld A MR decompress ion up l ink , this parameterrepresents the uplink quality threshold used to trigger an intracell

AMR Decompression Handover "halfrate to fullrate".


parameters are contained in the description for the parameter

EADVCMPDCMHO (see above).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 thresholdHOTHAMRDDL or the DL quality drops below the thresholdHOTHAMRDUL.

For further important details please refer to the description ofHOTHAMRDDL (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 DLreceive level; i.e. in order for a compression from FR to HR to be

triggered the conditionDL_RXLEV > HOTHCMPLVDL

must be fulfilled (as well as the respective condition for the UL andthe quality conditions).

Please note that From BR7.0 on the AMR compression anddecompression handover decision can be based on both quality andlevel conditions. The exact conditions for the initiation of an AMRcompression and decompression handover as well as references tothe quality related parameters are contained in the description for the

parameter EADVCMPDCMHO (see above).

HOTHCMPLVUL=<NULL>,


unit: 1 dBrange: 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, see

above) 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 andthe 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 parameteris 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 (independent from the respective UL or qualityconditions).



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 be

triggered the conditionUL_RXLEV < HOTHDCMLVUL

must be fulfilled (independent from the respective DL or qualityconditions).



HOTMSRM=34,


unit: 1kmrange: 0..35

default: 34


Handover threshold MS range maxim um , defines the threshold forthe maximum permitted distance between MS and the BTS in 1kmstep size which is used for intercell handover due to distance. It is

only 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 CREATEBTS [BASICS]) the handover threshold MS range maximum isdetermined by the parameter HOTMSRME (HAND).

Rule: HOTMSRM (HAND) < EXCDIST (BTS [OPTIONS])

HOTMSRME=99,


unit: 1kmrange: 35-100

default: 99

Handover threshold MS range maxim um extended , this parameterreplaces the parameter HOTMSRM (see above) in case of anextended channel (double timeslot of an extended cell, see

CELLTYPE=EXTCELL in CREATE BTS [BASICS]). It is only relevantif distance handover is enabled (DISTHO=TRUE, see above) andspecifies the handover threshold range maximum that is used forintercell 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


1 = -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-cellhandover 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 handoverdecision.The actual threshold value in [dBm] is calculated as follows:

Handover Threshold [dBm] = -110dBm + HOTULINT .To guarantee a correct interworking of power control and intracellhandover, the following rule must be fulfilled:

UPTLEVU > HOTULINT


IERCHOSDCCH=FALSE,


range: TRUE, FALSE

default: FALSE

Inter-cel l handov er for SDCCH , this parameter determines whetherinter-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-SDCCHhandover to target cells belonging to the same BSC. If Inter-BSCDirected 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=FALSE,


range: TRUE, FALSE

default: FALSE

Inner-inner h andover , this flag determines whether an intercellhandover from inner to inner area in sectorized concentric cells isenabled. This parameter is only relevant in concentric cells (see

parameter CCELL in command CREATE BTS [BASICS].

Under normal conditions (i.e. with ININHO=FALSE) any incominghandover to a concentric cell is always executed to a TCH belongingto the complete area, even if the level and distance conditions allowan 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 targetcell is directly followed by a complete-to-inner intracell handoverwithin the target cell. If ININHO is set to TRUE these unnecessaryhandovers 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 BTS.

After check of the current level and distance conditions the BTSanswers with a PREFERRED AREA message which suggests eithera 'complete' area TCH or an 'inner' area TCH. This suggestion isbased on the assumption that, for neighbour sectors of the sameBTSM, the level and distance conditions in the target cell for that

particular call are the same as in the originating cell as the antennasare normally colocated. If the BTS suggests an inner area TCH in the

PREFERRED AREA message, the BSC directly activates the targetTCH on an inner area TRX and sends the corresponding TCH info tothe MS in the HANDOVER COMMAND.

In fact, when ININHO is set to TRUE, not only inner-to-innerhandovers 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 intercellhandovers for the neighbour cell relations defined by CCELL1 andCCELL2. Even if the call is currently served by a complete area TRXin the serving cell, the BSC will start the PREFERRED AREAREQUEST procedure towards the originating cell when an intercellhandover is triggered. If the return message PREFERRED AREAmessage suggests the inner area, the handover is performed to a

corresponding inner area TRX in the target cell.

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-cellhandovers for TCH (i.e. HOs starting from a TCH) are generallyallowed for this BTS.Notes:- Only if this parameter is set to TRUE, the settings of the flagsRXQUALHO, RXLEVHO, DISTHO, PBGTHO, ININHO, EFULHO andTRFHOE 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 shortenough 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-cellhandovers due to quality shall be allowed this BTS. If this is the case,under defined quality and level conditions (see section handoveralgorithms) 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 FALSEthe 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 orbased 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 onlytake 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 qualityis still poor after decompression handover), the features ‘Cell loaddependent actvation of half rate’ (see parameter EHRACT incommand CREATE BTS [BASICS]) and ‘Abis load dependent

activation of half rate’ (see parameter ABISHRACTTHR in commandCREATE BTSM) are not considered if the BSC receives anINTRACELL HANDOVER CONDITION INDICATION due to qualityreasons (cause values ‘uplink quality’ or ‘downlink quality’). Thismeans that the BSC does not check the current BTS TCH load andthe 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 whetherintra-cell handover due to quality is enabled for SDCCH-SDCCH-handovers or not.

LOTERCH=TRUE,


default: TRUE

Local inter-cel l Handover enabled , determines whether inter-cellhandover 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-SDCCHhandover!- The setting of this parameter has an impact on performancemeasurement: It must be set to TRUE to ensure the correct workingof specific counters related to inter-cell handover (ATINHIRC,SINTHINT).

LOTRACH=TRUE,


default: TRUE

Local intra-cel l Handover enabled , determines whether intra-cellhandover 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-SDCCHhandover.- 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. Intracellhandover (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 onlyconsidered if the flag ELIMITCH (see above) is set to TRUE. Itdetermines the maximum number of consecutive successful intracellhandovers due to quality (see parameter INTRACH in command SETHAND [BASICS]) or intracell handovers due to AMR Compression(see parameter EADVCMPDCMHO in command SET HAND[BASICS]) that are permitted in the same BTS for a singleconnection.

In the BSC, separate two counters are managed, one for intracellquality handovers and one for AMR compression handovers.

MAIRACHO determines the threshold value for both counters

Note:Due to the feature implementation actually the maximum allowednumber of consecutive successful intra-cell handovers isMAIRACHO+1 .





MAXFAILHO=2,


range: 1-15

default: 2

Maximum n umb er of fai led handovers , this parameter is onlyrelevant 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,

object: HAND [BASICS]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 message

is 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-processingfunction 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 notexecute the handover itself it sends the message HANDOVERREQUIRED 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 ifthe 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 celland by a GSM 08.08 cause IE with the cause 'distance'. Thismessage makes the BTS suppress the handover origin cell in allfollowing INTERCELL HANDOVER CONDITION INDICATIONmessages 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 ifthe BSC detects that for the handover target cell the flag NOBAKHOis set to TRUE. The BTS then retrieves the TINHBAKHO value from

the 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 handoverrepetitions 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 flagNOFREPHO 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 which

contains the CGI of the target cell to which the handover attemptsfailed. As a result, the BTS excludes the affected cell from the targetcell list of the HANDOVER CONDITION INDICATION messages foran administrable period of time (see parameter TINHFAIHO(CREATE ADJC)).





PBGTHO=TRUE,


range: TRUE, FALSE

default: TRUE


Power budget hando ver enabled , determines whether handoverdue to power budget is enabled. This flag is only relevant if intercellhandover is enabled in the cell (INTERCH=TRUE, see above).Power budget handover means: handover to another cell if this celloffers a higher transmission level (irrespective of whether the powerlevel of the actual cell is above the minimum - see RXLEVHO - ornot.). Further parameters relevant for this type of handover are

HOAVPWRB (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 Budgethandover decision and the traffic handover decision (see parameterTRFKPRI). The priority layers of the neighbour cells are administeredin 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 onlyrelevant if intercell handover is enabled in the cell (INTERCH=TRUE,see above). If the receive level is below the minimum thresholdhandover is necessary. Further parameters relevant for this type ofhandover are HOAVELEV, 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 onlyrelevant 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 relevantfor this type of handover are HOAVQUAL, HOLTHQUDL andHOLTHLQUUL, 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 ofthe 14 parameters which allows a service group-dependent setting ofhandover 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 dependentHandover 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 forthis service group is based the ordinary HAND parameter settings.

Fo further details please refer to the section “Service dependentHandover and Power Control” in the appendix of this document.

THLEVFULHO=8,


unit: 1 dBrange: 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 uplinkhandover (see parameter EFULHO). If the UL RXLEV drops below

the level defined by THLEVFULHO, the BTS triggers a fast uplinkhandover.






THORQST=5,



range: 0..31

default: 5


Timer for handover request defines the minimum interval betweenHANDOVER CONDITION INDICATION messages (see parameterNCELL) 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], parameterBSCT7).

Recommendation:

THORQST (HAND) > T7 (SET BSC [TIMER])Note: If THORQST is set to 0 then the HCI is repeated after everySACCH 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 consideredif the flag ELIMITCH (see SET HAND [BASICS]) is set to TRUE. Itspecifies the timer used by the BTS to indicate how longa) quality intra-cell handover (see parameter INTRACH in commandSET HAND [BASICS]) orb) AMR compression handover (see parameter EADVCMPDCMHOin command SET HAND [BASICS])shall be prevented for a specific connection in the cell ifMAIRACHO+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 eventthat can stop this timer is the release of the call context (e.g. callrelease 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 celltraffic 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 SETBSC [BASICS]) has an influence on the radio TCH traffic load caluculation: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 orDOWNGRADE_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 particularTCH/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 preempted

if a CS TCH request meets a TCH congestion situation.

- TCHs indicated as ‘reserved for GPRS’ (see parameter GMANPRES in the PTPPKFobject) are not considered in the calculation, i.e. they are treated as if they were notconfigured! Thus, reserved GPRS TCHs in state ‘GPRS busy’ are not considered(value above the fraction bar) and the value below the fraction bar is the number ofTCHs in ‘unlocked/enabled’ minus the TCHs reserved for GPRS in the same state.


The BSC cyclically checks the traffic load (controlled by the timerTRFCT, see SET BSC) in all cells in which traffic handover isenabled (see parameter TRFHOE) and compares it to the thresholdspecified 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&Mmessage is the trigger for the BTS to start the traffic handoverdecision algorithm (for more details concerning the handoverdecision 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. Ifthe 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 thetraffic handover in the affected BTS by sending another LAPD O&Mmessage 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 shortlycalled ‘traffic handover’. If this flag is enabled, the BSC cyclicallychecks 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 handoverenabled’ indication to the BTS via the LPDLM link. As a result, the

BTS starts its handover decision process in such a way that itcontinuously evaluates the DL MEASUREMENT REPORTS forsuitable neighbour cells for traffic handover. Similar to the powerbudget handover decision process the traffic handover decision

process monitors the level difference between the serving cell andthe neighbour cells and compares it to an administrable handovermargin (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 correspondingINTERCELL HANDOVER CONDITION INDICATION with the

proprietary cause ‘traffic’. Differences to the normal power budgethandover decision consist in the following aspectsa) While the power budget handover decision process is continuouslyrunning 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 mentionedSATT message from the BSC before.b) While the power budget handover margin has a static value, thetraffic handover margin is dynamically changed (reduced orincreased) by a timer-controlled step-by-step reduction mechanism(see TRFHOT).

When the BSC receives the INTERCELL HANDOVER CONDITIONINDICATION (BWHCI) with the proprietary cause ‘traffic’, it checksthe current TCH load of the target cells indicated in the BWHCI. Onlyif the current TCH load of the suggested target cell is lower than aconfigurable threshold (see TRFLTH), the handover to this target cellis 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 handovermargin and the target cell list generation performed in the BTS areTRFHOT, TRFHOM, TRFMS, TRFMMA and TRFKPRI (see HANDobject) and BHFOT (see ADJC object). The parameter relevant forthe 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 andTRFLTH (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 ofthe TRFHOE flag (only TRFLTH is considered in this case).- In a Concentric Cell (see parameter CONCELL in commandCREATE BTS [BASICS]), the BTS triggers Traffic Handover only forcalls served by a complete area TRX.- In an Extended Cell (see parameter CELLTYPE=EXTCELL incommand CREATE BTS [BASICS]) the BTS does not trigger anyTraffic Handover at all.





TRFHOT=10,


unit: 1s

range: 2.. 20

default: 10

Traff ic handover t imer , this timer is used for the traffic handoverdecision (see TRFHOE) in the BTS and defines the cycle in which theBTS recalculates the dynamic traffic handover margin while traffichandover 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 firsthandover decision phase. The SET ATT message is sent from BSC

to BTS when the BSC has detected the exceeding of a traffic loadthreshold (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 handoverdecision phase starts with a reduced traffic handover margin andTRFHOT is restarted (as long as TRFHOT runs, the traffic handovermargin remains constant). In other words, specific adjacent cells, thatwere 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 traffichandover margin reduction is reached. From this point of time on thetraffic handover margin remains the same on every further expiry ofTRFHOT.

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 traffichandover decision process but recalculates the traffic handovermargin 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 handovermargin is reached, the decision process is stopped and no traffichandover is triggered anymore.

A reasonable setting of the BSC traffic control timer TRFCT (see SETBSC [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 traffichandover margin reduction.

Parameters relevant for the dynamic traffic handover marginreduction/increase mechanism are TRFHOM (ADJC object) andTRFMS and TRFMMA (HAND object). TRFHOM defines the basictraffic 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 handoverreduction/increase mechanism.

continuation see next page…





The following diagrams might illustrate the dynamic traffic handoverreduction/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 traffichandover 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 forTRFHOM from the beginning (the closer the threshold TRFHITH is to100%, the more ‘aggressive’ (i.e. negative) the traffic handovermargin 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 targetcells includes an additional level offset. In BR6.1 this offset is fixed to6dB:

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + 6dB

For more details regarding the exact interworking of the mentioned

ime

TRFHOT

firstexpiry ofTRFHOT

Traffic HO

enabledindicationreceivedfrom BSC

TRFHOT TRFHOT TRFHOT

secondexpiry ofTRFHOT

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 ofTRFHOT

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 ofTRFHOT

Traffic HO

disabledindicationreceivedfrom BSC


expiry ofTRFHOT

Traffic HO margin from the previousTRFHOT period is increased by TRFMS


expiry ofTRFHOT

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 neighbourcells 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 handovertarget 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 handovertarget 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 traffichandovers. The traffic load of a cell is calculated as follows:

Attention:





- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SETBSC [BASICS]) has an influence on the radio TCH traffic load caluculation: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 orDOWNGRADE_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 particularTCH/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 GMANPRES in the PTPPKFobject) are not considered in the calculation, i.e. they are treated as if they were 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 the number ofTCHs in ‘unlocked/enabled’ minus the TCHs reserved for GPRS in the same state.

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 HANDOVERCONDITION 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. Ifnone of the target cells has a suitable load situation (i.e. if the celltraffic load > TRFLTH) the HCI does not lead to any handover andthe 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 parameterspecifies the maximum reduction of the traffic handover margin (see

parameter TRFMS below). TRFMMA does not have to be an integermultiple 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 ofthe dynamic traffic handover margin. The BTS uses the traffichandover margin for the target cell list generation after the traffichandover decision. Only those neighbour cells are included in thetarget cell list of the INTERCELL HANDOVER CONDITIONINDICATION (HCI) with cause ‘traffic’, for which the level differencebetween the serving and the neighbour cell exceeds the dynamictraffic 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 handoverdisabled’ indication was received from the BSC in a SET ATTmessage) the traffic handover margin is increased by TRFMS in thenext TRFHOT period. Please see also the explanations provided forTRFHOT.

In fact, the basic traffic handover margin (TRFHOM, see ADJCobject) is already reduced by TRFMS in the first traffic handoverdecision 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 nextTRFHOT period and so on. However, the reduction of the traffichandover 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

HOAVELEV

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: BHFOT





Intra-cell handover

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***

(complete 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, HOAVELEV, 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 poolTCH load

BTSM: ABISHRACTHR

Intracell HO

due to

AMR

Compression-

Decompression

BSC: TRFCT

HAND: (advanced)

EADVCMPCMDHO

compression

HOTHAMRCDL

HOTHAMRCUL

(advanced) HOTHCMPLVDL

HOTHCMPLVUL

decompression

HOTHAMRDDL

HOTHAMRDUL

(advanced) HOTHDCMLVDL

HOTHDCMLVUL

a) AMR compr.HO due to radio

TCH load

BTS: HRACTAMRT1

HRACTAMRT2

b) AMR compr.HO due to

BTSM Abis poolTCH load

BTSM: ABISHRACTHR

Intracell HO

due to

O&M

No

parameters !





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 andquality 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 (nowsubordinate to the BTS object) and appear in the DBAEM in the SETHAND command. The logical group “[DATA]” is normally only usedon 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 qualityevaluation 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 determinedfor 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 byactivating 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 MEASUREMENTREPORTS from the MS and the BTS are averaged by a a 'gliding'averaging mechanism. The value of this parameter defines overmany 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 parameterdefines 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 properworking 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 parameterdefines 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 properworking 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.6kbit/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 uplinkquality 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 andthe next downgrade request sent by the BTS within the MODEMODIFICATION 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.





Setting the status of SMS-CB, Frequency Hopping and Call Release due toExcessive Distance:

< The command SET BTS [OPTIONS] already appeared togetherwith the other BTS-specific packages. The parameters, however, thatdetermine the status of SMS Cell Broadcast, Frequency Hopping andExtended Cell Handover must be placed after the CREATE CHAN

commands because an activation of these features is only possible ifthe CHAN objects have been created with the appropriate attributesbefore (for Frequency Hopping: CHAN must be created with aFHSYID, for SMS-CB a SCBCH or a BCBCH must be created for thecell, for Extended Cell Handover: CHAN must be created withEXTMODE=TRUE). For this reason DBAEM generates the SET BTS[OPTIONS] command again at this position with only the relevant

parameters included. >

SET BTS [OPTIONS] :

NAME= BTSM:0/BTS:0, Object path name .

EEXCDIST=FALSE,

object: BTS [OPTIONS]range: TRUE, FALSE

default: FALSE

Excessive distance release enabled , this parameter determineswhether the feature 'call release due to excessive distance' is

enabled. If the MS-BTS distance is bigger than the value entered forEXCDIST 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 CONNECTIONFAILURE message with cause 'distance limit exceeded' to the BSCand the call is released.

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 'callrelease 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 parameterHOTMSRME (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 hoppingis 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, ifH=1 then frequency hopping is enabled. For the MSs in idle mode thestatus of FH is indicated by the SYSTEM INFORMATION TYPE 1message 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 onlydetermined by the ‘semipermanent’ flag HOPP but also by a

‘transient’ system-internal flag BTS IS HOPPING (can be interrogatedby 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 thatthere is no impact on the call quality. In this case the state of the flagBTS 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 theLPDLM link. For the BTS there is actually no difference between adisabling of hopping due to HOPP=FALSE or due to





BTS_IS_HOPPING=NO.

Generally, every change of the frequency hopping mode is reportedto all busy MSs in the cell by a FREQUENCY REDEFINITIONmessage. These messages contain the channel data such as thenew ‘mobile allocation’, hopping sequence and MAIO and are specificfor each ongoing call. When hopping is disabled (no matter whetherthis is done by command or automatically) the FREQUENCYREDEFINITION 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 BSCif the failed/locked TRX-HW is put back to service: BTS IS HOPPINGchanges its state to ‘YES’ and another FREQUENCYREDEFINITION procedure is started for all busy MSs.

If the hopping mode changes either due to manual or automaticdisabling 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 createdaccordingly (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 - ifFrequency 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 externalneighbour cells, i.e. for neighbour cells that are served by a differentBSC. 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 belongingto 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 belongingto 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 notrepeated 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 ofthe neighbour cell. This info appears (together with the other adjacentcells)- for the MSs in 'idle' mode:on the BCCH in the SYSTEM INFORMATION TYPE 2, SYSTEMINFORMATION TYPE 2ter (in dualband networks) and SYSTEMINFORMATION 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 (fordualband 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 ‘CellDescription’.

From the SYSTEM INFORMATION TYPE 2, 2ter and 2bis the MSknows the neighbour cells which have to be monitored for cellreselection in idle mode, via the information sent in the SYSTEMINFORMATION TYPE 5, 5ter and 5bis the MS is informed which ofthe neighbour cells are to be monitored during the call phase, i.e. forwhich neighbour cells measurement reports may be generated.

BSIC=7-3,

object: TGTBTS

range: 0..7 (NCC)

0..7 (BCC)


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 HANDOVERCOMMAND in the IE ‘Cell Description’. It is used by the MS tocorrectly decode the BCCH bursts of the neighbour cell.

TGTCELL= TGTCELL=internal

neighbourcells

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 SYSTEMINFORMATION TYPE 3 and 4. For details see the same parameterin 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 forthe 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 trafficchannels.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 allexternal GPRS neighbour cells, i.e. for neighbour cells that supportGPRS and that are served by a different BSC. The TGTPTPPKF

object inclu des 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 cellsupporting GPRS and belonging to the same BSC), the ADJC objectrefers 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 cellsupporting GPRS and belonging to a different BSC), the ADJC objectrefers 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 andadvanced GPRS cell reselection parameters.The advantage of this approach is that the basic cell data are notrepeated 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 .

GMSTXPMAC=2,

object: TGTPTPPKF

range: 0..31

default: 15



Maximum al lowed GPRS MS transm ission po wer on PBCCH/PCCCH. GMSTXPMAC defines the maximum power level that maybe used by the mobile to access the cell on the PRACH. The validvalues and meanings are the same as defined for the parameterMSTXPMAXCH (see SET BTS [CCCH]).

Note: In case Network Controlled Cell Reselection (NCCR) isactivated in the serving cell (NCRESELFLAG=ENABLED), the PCUuses 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 parameterGPRS_MS_TXPWR_MAX_CCH.

TGTCELL= TGTCELL= internal

neighbourcells

externalneighbour

cells TGTBTS:n

TGTBTS:n/TGTPTPPKF:m

ADJC

BTSM:x/BTS:y/PTPPKF:n

BTSM:x/BTS:y





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 configuredin the cell, GPRS mobiles use this value instead of the GSMequivalent 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 PCUuses GRXLAMI as well as GMSTXPMAC to calculate the C1 valuesalso in case no PBCCH is created.This parameter corresponds to the GSM parameterGPRS_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’s

unique 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 differentby 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 mainlyrepresent parameters used for handover and advanced GPRS cellselection parameters while the basic cell data and identities arerepresented by the BTS and PTPPKF objects (for internal cells) andby 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!BHOFOT=30,

object: ADJC

unit: 1s

range: 1-254

default: 30

Back handov er forbidden timer for traff ic handov er , this parameter is used for back handover prevention and is consideredafter 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]) isenabled, a cell might be the target of an incoming traffic handover. Inthis back-handovers due to traffic or power budget are prevented bythe following mechanism: if an traffic handover is performed, the BSCextends the CHANNEL ACTIVATION message for the 'new' TCH inthe target cell by the IE 'Cell List Preferred' which contains the CGI ofthe 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 longas BHOFOT runs, the BTS excludes the CGI (that was previously

received from the BSC in the CHAN ACT message) from allHANDOVER CONDITION INDICATIONs that are sent with thecauses “better cell” and “traffic“. The back handover preventionmechanism for traffic handover is permanently enabled and cannotbe 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 SETBSC [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 notadministrable by database parameters).

The value FHORLMO value is added to the RXLEVMIN entered forthis 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 adjacentcell 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 listincluded 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 usedduring the target cell list generation process during a Fast UplinkHandover (see parameter EFULHO in command SET HAND[BASICS]) and is used to declare specific neighbour cells as“predefined” respectively ”preferential” target cells for fast uplinkhandover. 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 targetcells within this target cell list is based on two factors: the setting ofthe flag FULHOC and the level PBGT-HOM situation. The target celllist consists of two sublists: the upper list consists of all “preferential”target cells (FULHOC=TRUE), the lower one consists of ordinarytarget cells (FULHOC=FALSE). Within each sublist the target cellsare ranked in descending order of the difference between the powerbudget (which is, simply expressed, the level difference between the

serving and the neighbour cell) and the power budget handovermargin (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 handoverdecision process and the ranking of the target cells please refer tothe section ‘Handover Thresholds and Algorithms’ in the appendix ofthis 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 duringa Fast Uplink Handover (see parameter EFULHO in command SETHAND [BASICS]) and represents an additional offset which is addedto 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 forfast uplink handover and might appear in the target cell list of theINTERCELL HANDOVER CONDITION INDICATION with cause ‘fastuplink’.

For further details details concerning the fast uplink handoverdecision process and the ranking of the target cells please refer tothe section ‘Handover Thresholds and Algorithms’ in the appendix ofthis 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 cellreselection procedure.

This parameter corresponds to the GSM parameterGPRS_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 parameterGPRS_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 parameterGPRS_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


GPRS reselect offset , this attribute specifies the positive or negativeoffset to be applied to the C32 value of a neighbour cell. The setvalue ranges from -52 dB to +48 dB; the step size is 4 dB for the first11 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 parameterGPRS_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 definedin 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 allcriteria (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 MEASUREMNT REPORTmessages.

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 CREATEPTPPKF) subordinate to the BTS object (see CREATE BTS) enteredin 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 CREATEPTPPKF) 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 neighbourcell 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 parameterGPRS_TEMPORARY_OFFSET.

TGTCELL= TGTCELL= internal

neighbourcells

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 powerbudget handover (see parameter PBGTHO in command SET HAND[BASICS]). The handover margin is used for the power budgethandover decision process: a power budget handover (‘better cell’handover) is only triggered (i.e. an INTERCELL HANDOVERCONDITION 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 powerbudget 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. Differentadjacent cells can be assigned different handover margins in order tocontrol the handover flow.

Rule: To avoid 'ping pong' handovers between the inner andcomplete areas in sectorized concentric cells the following rule mustbe followed:

HOM coloc > (PWRREDinner - PWRREDcomplete ) [dB]

'HOM coloc ' is the handover margin set for an adjacent cell object thatrepresents a 'colocated cell' (see parameter CCELL in commandSET HAND [BASICS]).

HOMDOFF=0,

object: ADJC

unit: 1dB

range: 0..127

default: 0

Handover margin dynamic offset . This parameter is only relevantfor 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 expiryof 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 speedsensitive 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 longas 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 handovercondition (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 - HOMDOFFfor t > HOMDTIME

As long as the timer HOMDTIME runs the basic power budgethandover condition is permanently checked; if the BTS detects thatthe basic power budget handover condition (i.e. PBGT > HOM) doesnot exist any more the timer is stopped and the handover is notexecuted.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 relevantfor 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)


GSM 12.20

Level handover margin , this parameter defines the handovermargin for handovers due to uplink level or downlink level. The levelhandover is triggered if the UL or DL receive level of the serving cellfalls short of 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 HANDOVERCONDITION 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 servingcell and the neighbour cell (power budget PBGT) is considered. In

this case the neighbour cell only appears in the target cell list if its power budget exceeds the entered level handover margin:

PBGT(n) > LEVHOM(n)

in addition to the handover minimum condition.

Attention: also in case of handovers due to uplink level, the PBGTcalculation 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 leveloffset 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 ‘HandoverThresholds & 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 bythe 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=0,

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 cellreselection (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 appliedto 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 parameterGPRS_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 +48dB in steps of 1dB.

The equivalent parameter in case NCCR is disabled is GRESOFF.

This parameter corresponds to the GSM parameterGPRS_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 forthe duration of NCGPENTIME in case NCCR is activated. The setvalue ranges from 0 to 60 dB in steps of 1dB. The value NEVERmeans infinity.

The equivalent parameter in case NCCR is disabled is GRESOFF.

This parameter corresponds to the GSM parameterGPRS_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 relevantfor 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 HIERCin 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 evaluatedby the ranking algorithm as long as the handover margin delay timerHOMDTIME 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

RXLEVMIN=12,

object: ADJCunit: 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 levelthe 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 forhandover and directed retry. The selected value should correspondto 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 ifthe 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 handoveradjustment of special neighbour cell relations.

TGTCELL=BTSM:10/BTS:0,

object: ADJC

format: object instance path name

Internal cells

BTSM:n/BTS:m

External cells

TGTBTS:n

Target cell , this attribute specifies the object instance path name ofthe database object that represents the basic data of the neighbourcell. 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 objecttypes:a) If the ADJC object represents an internal cell (BTS), the TGTCELL

parameter points to the associated BTS object (see commandCREATE BTS).b) If the ADJC object represents an external cell (BTS), theTGTCELL parameter points to the associated TGTBTS object (seecommand CREATE TGTBTS).

TGTCELL= TGTCELL=internal

neighbourcells

external

neighbourcells

TGTBTS:n BTSM:x/BTS:n

ADJC







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 ofthe handover margin used for traffic handover (see parameterTRFHOE in the command SET HAND [BASICS]). Like for the powerbudget 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 a

specific 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 andrepresents - 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 handovermargins 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’ traffichandover margin, which is periodically recalculated on the basis of atimer-controlled process. The basic traffic handover margin that is setwith TRFHOM is only a part of this ‘dynamic‘ traffic handover margincalculation. Thus the ‘real’ traffic handover margin that is actuallyused 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 bya process controlled by the timer TRFHOT (see parameters TRFMSand 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 handoverby the BSC) is

TRFHOM – TRFMS

The lowest possible value of the dynamic traffic handover margin is

TRFHOM – TRFMMA3) For traffic handover it might be useful if the dynamic traffichandover margin

(TRFHOM–TRFMS) > dyn. traff. HO margin > (TRFHOM-TRFMMA)

assumes negative values as the purpose of the traffic handover is tomove calls from the serving cell to cells which provide a DL receivelevel which is not as good as that of the serving cell but stillacceptable.

TRFHORXLVMOFF=30,

object: ADJC

unit: 1dB

range: 0..48 (-24dB..+24dB)

default: 30 (=6dB)

Traff ic handover receive level minim um o ffset , this parameter isused during the target cell list generation process for TrafficHandover (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 ifRXLEV_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 forhandover 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 forthose calls that fulfil the traffic handover conditions with respect to thetraffic handover margin (parameter TRFHOM, see above), but whose





level is already low in the current serving cell. If the traffic handovermargin is set to negative values or reaches negative values due tothe 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 undesiredback-handovers due to level or quality (without the offset applied bythe parameter TRFHORXLVMOFF a neighbour cell is regarded as

suitable if it fulfils the minimum DL RXLEV on the basis ofRXLEVMIN 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 butwhich shoul not have a noticeable negative impact on the currentQoS provided to the subscriber, the administrable traffic handoveroffset defined by TRFHORXLVMOFF is considered in addition toRXLEVMIN when evaluating the DL RXLEV of a particular neighbourcell.

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

default: SI_2_5

Usage of neighbou r cel l in SYS INFO , this parameter indicates

whether this adjacent cell shall be indicated as neighbour cell on theBCCH in the idle mode (SYSTEM INFORMATION TYPE 2, 2bis and2ter) or/and on the SACCH in busy mode (SYSTEM INFORMATIONTYPE 5, 5bis and 5ter). The purpose of this parameter is to controlthe cell reselection and handover traffic separately. In other words,with this parameter it is possible to prevent either outgoing cellreselection or outgoing handovers for specific neighbour cellrelations: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 neighbourcell while it is in ‘busy’ mode and reports it to the BTS via theSACCH. This again is the precondition for any outgoing intercellhandover decision by the BTS.

Thus the meaning of the values is pretty simple:- Setting USG=SI_2 means that the neighbour cell is only broadcastin the SYS_INFO_2x. Thus only cell reselection to this neighbour cellis 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 signaledin the SYSTEM INFORMATION TYPE _2x and SYSTEMINFORMATION TYPE 5x. Thus both cell reselection and outgoingintercell handover to this neighbour cell is possible.

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 theMS may report the neighbours based on the SYS_INFO_2 (e.g.directly when the MS has changed from idle to busy mode, but has





not yet read the new BA list from the SYS_INFO_5) and the MSreports the neighbour cells always by their relative BCCH frequencynumber. To correctly translate this relative BCCH frequency numberinto 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 the SYSTEMINORMATION TYPE 10. At present, this SYSINFO 10 contains allneighbour cells created via ADJC objects, irrespective of the settingof 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 externalUMTS (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 broadcaston 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 primaryscrambling code used by the target FDD cell.

MSTXPMAXUMTS=11,

object: TGTFDD

range: 0..19

default: 0

Reference:


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 actualsettings of the target NodeB is recommended but not mandatorysince the two parameters are set in different network elements andare 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 reportedbut 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 .

HOM=69,

object: ADJC3G

unit: 1dB

range: 0..126

0 = -63dB

126 = +63dBdefault: 69 (= 6dB)

Reference:

Handover m argin for 2G-3G better cel l handover , this parameterdefines a threshold for the ‘better cell’ handover from GSM 2G toUMTS FDD neighbour cells (see parameter EUBCHO in commandSET HAND). The handover margin is used for the ‘power budget’handover decision process: a ‘power budget’ handover from 2G to

3G is only triggered (i.e. an INTERCELL HANDOVER CONDITIONINDICATION with cause ‘better cell’ is sent to the BSC) if the powerbudget of a specific UMTS FDD neighbour cell exceeds the handovermargin set for the ADJC3G object representing this cell. The powerbudget 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 controlinto 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. Differentadjacent 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 d ynamic o ffset 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 SETHAND [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 SETHAND [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. Ifthe basic power budget handover condition (i.e. PBGT > HOM) stillexists when the timer expires, a dynamic offset (see parameterHOMDOFF) 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 - HOMDOFFfor t > HOMDTIME

As long as the timer HOMDTIME runs the basic power budgethandover condition is permanently checked; if the BTS detects thatthe basic power budget handover condition (i.e. PBGT > HOM) doesnot exist any more the timer is stopped and the handover is notexecuted.

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 whetherthe adjacent cell is regarded as a ‘microcell’. Only if this parameter isset to TRUE the ‘speed sensitive handover’ algorithm will be in effectfor this neighbour cell. Precondition: the database flag for speedsensitive 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 neighbourcell. 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 parameteris only relevant if speed sensitive handover from GSM to UMTS FDDneighbour cells (see parameters EUBCHO, PBGTHO andDPBGTHO in command SET HAND [BASICS]) and ‘ranking of targetcells on the basis of priority’ (see parameter HIERC in command SETHAND [BASICS]) is enabled. It determines the temporary prioritylayer of those adjacent UMTS FDD cells which are defined as

microcells (see parameter MICROCELL). PPLNC is only evaluatedby the ranking algorithm as long as the handover margin delay timerHOMDTIME 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 parameterdetermines 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 shouldcorrespond to the actual settings of the UMTS FDD Node B althoughboth parameters are administered in different network elements andare 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 flagNOFREPHO (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 parameterMAXFAILHO 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 ofthe UMTS FDD or TDD neighbour cell. The neighbour cell creationconcept for the ADJC3G objects is the same like for the ADJCobjects (see CREATE ADJC): The TGTFDD/TGTTDD parameteralways refers to an already created TGTFDD/TGTTDD object (seecommand CREATE TGTFDD)

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]) to adjust the carrier level of the related UMTS FDDadjacent cell compared to the carrier level of the serving cell.UADJ is applied only for RSCP value (FDDREPQTY=RSCP).

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 levelwhich is required to include an UMTS FDD cell into the handovertarget cell list in case of an ‘imperative’ handover (see parameterEUIMPHO 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

Reference:

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.

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 thresholdabove 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.





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 basicSCCP 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 andappear in the DBAEM in the CREATE OPC command. The logicalgroup “[BASICS]” is normally only used on the LMT but was usedhere 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 pointof view. SCCP subsystems are Application Parts of the SCCP (likee.g. BSSAP, MAPMSC, MAPHLR etc.), which have to be addressedby 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 usedfor 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 , this

flag determines whether the periodic signaling link test is enabled forthe 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. IfPERTFLAG is set to TRUE, the signaling test procedure is

periodically performed for the OPC-SPC relation. The time periodbetween the transmission of 2 SLTMs is determined by the timerM3T2TM, 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 allnetwork elements are addressed with one unique SPC valid forNAT0. The other possible values are normally used for networktransitions.

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”. ForCCITT the conversion from decimal format to the new format is donein the following way: Convert decimal value to Hex, the 2 leastsignificant digits (converted to decimal) make up the ‘Network ClusterMember’, 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 forthe BSC-SMLC CCS7 connection or not. For further details pleasesee parameter MSCPERTFLAG.

Attention: The Signaling link Test Procedure is only used for the SS7relation between BSC and SMLC if the SS7 link is created for link setLKSET=1, i.e. if theSS7 connection between BSC and SMLC isrealized via a nailed-up connection (NUC) in the MSC. For furtherdetails 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; ANSI

default: CCITT

SS7 MTP type , determines the type of message transfer part used bythe SS7.

TCONN=3,


unit: 5s


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 everytransaction (call, SMS-transmission, Location Update etc.). The timerTCONN is started when the BSC transmits the CONNECTIONREQUEST to the MSC. If it expires, the BSC regards the SCCP localreference connection request as unsuccessful and releases theassociated context.







BSSMAP RESET procedure when the SS7 connection has returnedto service. Both SPAP STFS Timer and SPSTFT are set in units of10s an unfortunately their default is ‘0’ (zero). Interworking tests haveestablished that it is recommended to equally set TGUARD andSPAP 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

(= recommeded value !)

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. IfTIAR 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 SCCPlocal reference connection and thus to the release of the associatedcall.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

(= recommeded value !)

Inact ivi ty test send timer , this timer determines the periodicity of thesending of INACTIVITY TEST messages (IT) on an SCCP localreference connection section. The INACTIVITY TEST messages areused to create a kind of 'keep alive' activity on the SCCP localreference 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 anotherINACTIVITY TEST message. On the MSC side an Inactivity TestReceive Timer (see TIAR) observes the receipt of the INACTIVITYTEST 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 TESTmessage is sent towards the MSC for more than 2 times of the TIASinterval. In order to prevent the MSC from releasing the SCCPconnections 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 calledT119 (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 RELEASECOMPLETE message. The RELEASE COMPLETE is theconfirmation message for the RELEASED message which is sent ifan SCCP connection is cleared down. The timer TREL is startedwhen 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 RELEASECOMPLETE..

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 followingtimers: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 commandMOD 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 startedwhen the remote SCCP subsystem (i.e. the BSSAP) becomesunavailable. As long as the timer runs, the calls are maintained. The

SCCP STFS Timer (resp. SPSTFT) is stopped, when the remoteSCCP subsystem becomes available again. If it expires, the MSCreleases all calls to the affected entity (which is in this case the BSC)and performs a BSSMAP RESET procedure when the SS7connection has returned to service. Both SCCP STFS Timer andSSSTFT 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 andappear 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 transmitbuffers are physically located in the SS7 level 2 boards, i.e. in thePPCC or the PPXL. The BSC continuously observes the utilization

percentage of the available transmit buffers and compares it to thethresholds that are mapped to the CONGTH value in accordance withthe table below:

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’ withcause value ‘SS7 Tx buffer congestion’ is raised.When the Tx buffer utilization drops below the threshold defined bythe ‘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 2frames.

The value CONGTH=0 means that the check on SS7 TX buffercongestion 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-2error correction principle used on the SS7 links.- The Basic Error Correction method is normally used on all terrestrialCCS7 links. It uses layer 2 acknowledgement mechanisms (based onforward sequence numbers, backward sequence numbers andindicator 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 methodmust 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 cyclicallyretransmitted 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 2acknowledgements are too long to allow a useful use of the basicerror correction method.

FLOWCTH=3,

object: OPC [MTL2]

unit: 1%

range: 0..9

default: 3

Flow contro l thresho ld , this parameter determines a threshold forthe observation of the CCS7 receive buffer utilization. The BSC

continuously observes the utilization percentage of the available SS7receive 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 458 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 bythe 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 basedon thresholds defined by parameter CONGTH (see above). Asopposed to the SS7 Tx buffer congestion detection based onCONGTH, 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 CCITTblue book.





M2T2=100,

object: OPC [MTL2]

unit: 100ms


ANSI: 50..300

default: CCITT: 1000

ANSI: 120

recommended value : 100

M2T2 , ‘not aligned’ timer, known as T2_timer_id in the CCITT bluebook.

Attention: With the introduction of the BR7.0 PPXL patch Y1340005the listed default values are no longer valid. In fact, the value must beset to 100 before the patch is loaded.

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-5

ANSI: 4-7

default: CCITT: 5ANSI: 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: 100ms

range: 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 CCITTblue book.

M2T7=20,

object: OPC [MTL2]

unit: 100ms

range: CCITT: 5-20

ANSI: 5-20

default: CCITT: 20ANSI: 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 signalunits (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 im er, this parameter determines the value of the sanity timerused to control the level 2 processor (PPCC) outage. SANTIME

represents a keep alive time between TDPC and PPCC. If this timeris set to 0 (disabled), no “keep-alive” is performed. If SANTIME is setto a value different from 0, the PPCC expect a keep alive messagewithin this time frame. If the PPCC 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 affectthe 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 andappear in the DBAEM in the CREATE OPC command. The logicalgroup “[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 CCS7level 3 functions to periodically check the availability of CCS7signaling 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) andremote 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 pointrepresents the final target signaling point of the OPC-SPC relation,the adjacent signaling point is simultaneously the “Signaling EndPoint” (SEP). If the adjacent signaling point just represents anintermediate signaling point on the way to the destination SP, it works

as a “Signaling Transfer Point (STP)”. The STP just checks thedestination address of the CCS7 message and forwards the messageto the correct SEP respectively another intermediate STP via asignaling 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 route





availability 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_timerin 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 CCITTblue book.

M3T14=4,

object: OPC [MTL3]

unit: 100ms

range: 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 duringthe SS7L restoration phase and controls the disabled state of theSS7L. M3T19 was introduced to avoid a lot of SS7ENABLE/DISABLE messages towards the RC. If the SS7 linkinterruption 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 hardcodedvalues.

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 parameterMSCPERTFLAG 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 orT20 for ANSI) controls the local INHIBIT test procedure. If the SS7Lis local inhibited a local INHIBIT test is sent to the MSC everyM3T22OR20 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 CCITTor T21 for ANSI) controls the remote INHIBIT test procedure. If theSS7L is remote inhibited a remote INHIBIT test is sent to the MSCevery 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 signalinglink 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 blockingend), 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=0..0,

object: SS7L

range: ppcc-no.: 0..1

port-no.: 0..3

<NULL>

Link access , describes the physical port, ppcc-no. - port-no..

If NTWCARD=NTWSNAP then LNKA must have the value <NULL>.If NTWCARD=NTWSN16, then LNKA must have a value differentfrom <NULL>.

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 ifthe 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 numberdetermines 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 CCS7Signaling Transfer Point (STP). As a precondition, the correspondingCCS7 routing tables must have been created in the MSC. For furtherhints 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

timeslot-no.: 1-31 (PCM30)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 switchedconnection 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 BSCand 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 bythe 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 bythe nailed-up connection.





Creating an X25 connection via dedicated link:

< Note: The objects X25D and X25A are mutually exclusive. i.e eitheran 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 eitheran 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 usedfor 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 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 ofthe 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 X25network.





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 via

dedicated 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 X25network.

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 commandCREATE 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 SYNCsynchronization source. The external synchronization signal isdirectly connected to one of the two external input accesses of thePLLHcard, which is represented by the W26 connector on the top of theBSC rack, which is a SUB-D 15 female connector provided forsynchronization purposes.The connection shall be performedaccording 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.

Activating IMSI tracing in the BSC:

<The feature IMSI Tracing allows the BSC to trace all signallingtransactions of any call (MOC, MTC) or a short message transfer(SMS-MO, SMS-MT) performed by a specific subscriber (representedby his IMSI). This feature is foreseen for a limited number of





subscribers to be traced and has to be activated in the MSC forspecific 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 networkarea) IMSI tracing might be started for the IMSI of the affectedsubscriber or a tester may travel through this area performing testcalls with a test SIM card while IMSI tracing is active. Specificcommands have to be entered in the SIEMENS MSC to activate the

feature generally (MOD MSERVREL and MOD MSERVOPT) and fora specific IMSI (ACT IMSITRAC). In the BSC, the feature is generallyactivated by the CREATE TRACE command. As a result, if an MSwith the IMSI under test performs any call transaction, the MSCinstructs 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 ofthe up- and downlink measurements measured during the call by theMS and the BTS in form of the so-called TRACE MEASUREMENTRESULTS. 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 usingthe ‘StoppedTraceNotification’. The trace file is compressed andautomatically uploaded to the RC. In the RC, the file is decompressedand converted to ASCII format. Thus the ASCII trace file, whichcontains 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 16. The difference between IMSI tracing andthe CTR feature is that IMSI tracing is IMSI related (resp. subscriberrelated) 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 monitorthe 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 celltracing activities. The purpose of CTR is to collect call trace data insuch a way that they can be chronologically aligned to the existingcell 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 ifsubscriber complaints or PM data point to problems in a specific cellor 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. However, the CTR files only start recording theevents during the ‘TCH assigned’ phase, call transactions in the‘signalling only’ phase (SDCCH phase) are not recorded. Moreover,while IMSI traces record complete BSC-controlled inter-cell handover

procedures within one trace, CTR in this case just follows up thesignalling transactions in the target cell for a defined ‘trace handover

persistence time’ which is fixed to 10 sec.. In the other cases therecording is stopped on call termination (normal or abnormal), in caseof forced termination due to an IMSI trace invocation (see MACONN)or in case of inter-BSC HO.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 foranalysis. >

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 terminatedthe 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 able

to start a new one, ‘busy’ means that the maximum number of tracesessions (maximum 16 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 notmean 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=16,

range: 1-16

Maximum number of conn ect ions , this parameter determines themaximum number of connections to be traced within the cell.Note: The overall maximum number of traced connections (IMSI andCTR traces) is restricted to 16. 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 IMSItracing 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=31-12-2099,

format: 7 fields with the structure

hour - minute - duration,

first field represents sunday,

last field represents saturday

range: hour: 0..23

minute: 0..59

duration: 0..1440

default: NO_CONFIG (for each field)

Period during th e week , this parameter defines the periods duringwhich the CTR trace activities should be active within a week by itsstart time and the trace duration. For every day of the week anappropriate 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.

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) orwhether it shall contain the uplink and downlink measurementresults/reports in addition (ALL).





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 shallbe 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 externalalarm.

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 – ifthe 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 significantlyenhance the overall test coverage in addition to other alarmingfeatures such as “Sleeping Cell Detection” or “RX Diversity Alarm”. Ifthe 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. (forBTSone)), can be established by a test (from the RC) on the affectedboards: if the test fails, the affected HW must be replaced, if no faultyHW 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 CUTXLEVADJ: CREATE/SET BBSIG, CREATE/SET CU, CREATE/SET CA

BTSE Parameter RXLEVADJ

The purpose of the parameter RXLEVADJ is to correct the uplinkRXLEV 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 measurementautomatically considers the DUAMCO gain). This can happen eitherdue to the use of third-vendor (i.e. non-SIEMENS-specified) TMAs orextremely long feeder cables. As the GSM standard requires that theRXLEV_UL values that are to be used for the Power Control andHandover 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 and21 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 deviatingconfigurations 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 inputand 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 performance

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 RXLEVADJCsetting has an impact on the Idle TCH Measurements (see parameterINTCLASS 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 powerat the antenna port ( BSPOWER ANT ) as explained above. As opposedto 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 MEASUREMENTREPORTs 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 basebandfrequency 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 differentTPUs to one BBSIG. The TX and RX paths are tied together byswitching TX & RX at the same time;

- The BTSplus implementation is different to the BTS1. Herebaseband hopping is exclusively used in downlink direction whereas

in uplink direction always synthesizer hopping is applied. Downlinkdata 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 usedwith 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 averagingeffect 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 thresholdfor 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

Bandwid th of hysteresis , this parameter defines hysteresis value,which is used to calculate the lower alarm threshold for the ceasing ofthe 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 ofmeasurement 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 ofcalls handled (within a 30..minutes observation period) required forthe 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 frequencybased measurements and elaborates them to determine a list ofranked frequencies. This list then indicates the best substitute for afrequency that is being tested e.g. for a microcell or to be usedin 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 underobservation; for the Busy Cumulative Measures, the frequencies listis 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) andstopTime (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 ordisables the busy cumulative measurements.

EEICM=FALSE,

range: TRUE, FALSE

default: FALSE

Enable extended idle c hannel measurements , this parameterenables 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 ChannelMeasurements 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 handoverdue to power budget /

Traffic Handover

Inter-cell handoverdue to level

made by: Gunther Döhler

HOLTHQUXX

HOLTHLVTXX HOTXXINT

XX=DL : DownlinkXX=UL : Uplink

Inter-cell handoverdue to quality(if skip flag=TRUE orif INTRACH=FALSE)

Intra-cell handoverdue to quality(if skip flag=FALSE)

Inter-cell handoverdue 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 ParameterName

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 Handover (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 HOAVELEV (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 level average of the neighbour cell (n)

(the averaging is done according to the setting of HOAVPWRB (SET HAND))

RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum receive level of the neighbour cell (n)

MS_TXPWR_MAX(n)= MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS 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 > 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 and the correction term Max(0,Pa)

If the optional feature “Level Handover Margin” is enabled (SET HAND:ELEVHOM=TRUE), the followingadditional condition must be fulfilled

5. PBGT(n) > LEV_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)

PBGT (n) = power budget of the neighbour cell (n)

LEV_HO_MARGIN(n)= LEVHOM (CREATE ADJC) = level handover margin of the neighbour cell (n) in [dB]



RXLEV_DL = received level average downlink of the serving cell

PWR_C_D = BS_TXPWR_MAX - BS_TXPWR = averaged difference between the maximum downlink RF power and

the 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)




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 level handover margin setfor 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)


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 extendedcel ls (near-to-far and far-to-near) are not considered in this context. For details on these types ofintra-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 handover (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











→ The actual receive level average of the neighbour cell must be higher than the sum ofminimum 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 (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 handover (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 (for 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 ofminimum 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.) are included in the target cell list of theINTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘distance’, unless the number oftarget cells is restricted by the parameter NCELL (see SET HAND).






1. neighbour cell





. . .

. . .







2.1.2.5 Inter-cell Handover (power budget)


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 ifone or more neighbour cells are found which fulfil the condition

1. PBGT(n) > HO_MARGIN(n)







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) (CREATE BTS

[BASICS]), value in dBm= max. allowed transmit power of serving cell (n)






→ The power budget of the neighbour cell must be higher than the handover margin setfor the neighbour cell





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











→ The actual receive level average of the neighbour cell must be higher than the sum ofminimum 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 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).





Inter-cell HCI: target cell

list1. 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.

The target cell ranking is different if the feature “Hierarchical Cell Structure (HCS)” is enabled. For more

details please refer to the section 2.4.1.





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.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(n) = RXLEVMIN (CREATE ADJC) = minimum receive level of the neighbour cell (n)RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum receive level of the 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 ofminimum receive level set for the neighbour cell and the correction term Max(0,Pa) plusthe neighbour cell specific forced handover offset





2.1.2.7 Fast Uplink Handover


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 Control algor i thm to adjust the pow er 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 handoverminimum condition enhanced by an additional fast uplink handover offset

2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + FULRXLVMOFF(n)





FULRXLVMOFF(n) = FULRXLVMOFF (CREATE ADJC) = fast uplink receive level offset

of the neighbour cell (n) in [dB] added to the handover minimum criteria






→ 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


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]




PWR_C_D = BS_TXPWR_MAX - BS_TXPWR

= 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]= max. allowed transmit power of neighbour cell (n)




→ 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 parameterTRFHOM (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 handovermargin 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.

→ 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 traffichandover 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 traffichandover 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 ofTRFHOT

Traffic HO

enabledindicationreceivedfrom BSC


secondexpiry ofTRFHOT

Start of second traffic HO decision phase withreduced traffic HO margin

Traffic HO Margin = TRFHOM - 2*TRFMS

Start of first traffic HO decision phase withInitial traffic HO marginTraffic HO Margin = TRFHOM - 1*TRFMS

thirdexpiry ofTRFHOT

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 marginTraffic HO Margin = TRFHOM - 3*TRFMS

Principle of the traffic handover margin reduction mechanism when traffic

handover is enabled:

ime zone

TRFHOT

expiry ofTRFHOT

Traffic HO

disabledindicationreceivedfrom BSC


expiry ofTRFHOT



expiry ofTRFHOT

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 traffichandover 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)







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 2.4.3..





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 ofthe HANDOVER CONDITION INDICATION if

1. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)

RXLEV_NCELL(n) = received level average of the neighbour cell (n)RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum receive level of the neighbour cell (n) 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


where PBGT(n) = RXLEV_NCELL(n) - (RXLEV_DL + PWR_C_D) +Min(MS_TXPWR_MAX, P) - Min(MS_TXPWR_MAX(n),P)

PBGT (n) = power budget of the neighbour cell (n)HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n)RXLEV_NCELL(n) = received level average of the neighbour cell (n)RXLEV_DL = received level average downlink of the serving cellPWR_C_D = BS_TXPWR_MAX - BS_TXPWR

= averaged difference between the maximum downlink RF power andthe actual downlink due to power budget.

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]

= max. allowed transmit power of neighbour cell (n)P = power capability of the mobile in [dBm]

Min(MS_TXPWR_MAX,P) = MS_TXPWR_MAX if MS_TXPWR_MAX < PMin(MS_TXPWR_MAX,P) = P if MS_TXPWR_MAX > P

and

3. 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

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:MICROCELL=TRUE) the power budget handover decision algorithm considers

a) 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 and to section 2.1.2.5.1 (Power Budget Handover / Speed sensitivehandover).

.





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 parameterFULHOC (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 ofthe HANDOVER CONDITION INDICATION if the following conditions are fulfilled:

for imperative handovers

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)


= 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 > 0


for forced handover (directed retry)

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + FHO_RXLEV_MIN_OFFSET(n)


= max. allowed transmit power of neighbour cell (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 > 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)

PBGT (n) = power budget of the neighbour cell (n)HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n)RXLEV_NCELL(n) = received level average of the neighbour cell (n)RXLEV_DL = received level average downlink of the serving cellPWR_C_D = BS_TXPWR_MAX - BS_TXPWR

= averaged difference between the maximum downlink RF power andthe actual downlink due to power budget.

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]

= max. allowed transmit power of neighbour cell (n)P = power capability of the mobile in [dBm]

Min(MS_TXPWR_MAX,P) = MS_TXPWR_MAX if MS_TXPWR_MAX < PMin(MS_TXPWR_MAX,P) = P if MS_TXPWR_MAX > P

3. Within each sublist the cells in the target cell list HANDOVER CONDITION INDICATION are orderedaccording to their priority.

Cells with the same priority level are ordered according to the value ofPBGT(n) - HO_MARGIN(n).


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 ofthe 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)


= 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 > 0


for forced handover (directed retry)

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + FHO_RXLEV_MIN_OFFSET(n)


= max. allowed transmit power of neighbour cell (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 > 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)

RXLEV_NCELL(n) = received level average of the neighbour cell (n)RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum receive level of the neighbour cell (n) 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

LEVONC(n)= LEVONC (CREATE ADJC) = level offset of neighbour cell for ranking method 1

3. Within each sublist the cells in the target cell list HANDOVER CONDITION INDICATION are orderedaccording to their priority.

Cells with the same priority level are ordered according to the value of

PBGT(n) - HO_MARGIN(n).


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 (parameterPL, 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 parameterNCELL (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 Power Control Thresholds & Algorithms

2.3.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 uplinkU_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.3.2 Rules: Power Control Thresholds: Power Increase / Power Decrease

2.3.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 ofmeasured 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.3.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 ofmeasured 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 ofmeasured 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.3.3 Classic and Adaptive Power Control

2.2.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.3.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 parameterPCONINT (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 otherway round than in the diagram shown in section 2.2.1!

RXLEV

up_qual

low_qual

0 / 30

7 / 0

0 63up_lev

1

a

2 3

4 5 6

7 8 9

b

PWREDSS

+

+

+ + +

0 -

--0

non-AMR / AMR

low_lev

RXQUAL / C/I





2.3.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]

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.3.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 orhigh RXLEV values - in this scenario the bad quality is most probably caused by interference) is the same asin case of the classic power control. Only exception: the power control delay timer is not defined by theparameter PCONINT but by the parameter PAVRQUAL (see section 2.2.3.4, Functional sequence of apower control procedure)

Classic power decrease (quadrants 2b and 3)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. In quadrant 3, the difference is, thatthe power decrease will take place very fast, as the power control delay timer (defined byPAVRQUAL) is not applied in this quadrant.

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.

RXLEV

up_qual

low_qual

0 / 30

7 / 0

0 63up_lev

1

a

2 3

4 5 6

7 9

b

PWREDSS

+B

+ +

0 0

--0

low_lev

+B

+A

non-AMR / AMR RXQUAL / C/I

8





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 otherhand.

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.3.3.4 Functional sequence of a BS and MS power control procedure

2.3.3.4.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 powercontrol 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 (parameter PAVRQUAL).

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). In all otherquadrants the delay timer between two consecutive power control steps is not applied. As a result, inthese quadrants the power change will take place much faster.

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)).





2.3.3.4.2 MS power control procedure

The MS power increase or power reduction procedure includes a ‘power control command’ and ‘powercontrol 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 (abslute) power level that was actually used in the last burst of the previous SACCHperiod (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 anotheradditional 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 (parameter PAVRQUAL).

5) When the ‘delay timer’ expires, the BTS resumes the PWRC decision process. When the waiting timer forthe power confirmation from the MS (parameter PWRCONF) has expired without receipt of a powerconfirmation 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_UL

conditions 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). In all otherquadrants the delay timer between two consecutive power control steps is not applied. As a result, inthese quadrants the power change will take place much faster.





2.3.3.5 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 of3 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 that a

BS power control step and, consequently, the whole MS power control process reacts considerably slowerthan BS power control.

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.

• The IE BS Power indicates the currently ordered BS power level

• 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 SACHH frames before).

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 5th

MEASUREMENT RESULT *

= 3 SACCH periods confirmation + 2 SACCH periods delay (PAVRQUAL=2-x)

MSPRWC = ADAPTIVE(quadrants 1,3,4,6,7)

IE ‘MS power’ changes after every 3rd


= 3 SACCH periods for confirmation + 0 SACCH periods delay

BSPRWC = ADAPTIVE(quadrants 2b,8,9)

IE ‘BS power’ changes after after every 2nd


= 0 SACCH periods confirmation + 2 SACCH periods delay (PAVRQUAL=2-x)

BSPRWC = ADAPTIVE(quadrants 1,3,4,6,7)

IE ‘BS power’ changes every MEASUREMENT RESULT *

= 0 SACCH periods for confirmation + 0 SACCH periods delay

2.3.3.6 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 powercontrol, 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 of4 SACCH periods, PWRCONF=2) by adding only half of the ordered power increase step (i.e. in this case5dB).





2.3.3.7 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 (ifapplied 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 avaraged 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.4 Interworking of Handover and Power Control

2.4.1 Functional Diagram: Inter-cell Handover and Intra-cell Handover, PowerIncrease and Power Decrease

Note: for clearness reasons, Fast Uplink Handover was not included in this diagram.


GSM ParameterName

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 handoverdue to level

Inter-cell handoverdue to power budget /Traffic handover /

no Power Control

Inter-cell handover due toquality (if skip flag=TRUE orif INTRACH=FALSE)

Intra-cell handoverdue 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 handoverdue 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.4.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 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.5 Service Dependent Handover and Power Control

2.5.1 Introduction

Starting from BR7.0 it is possible to configure specific parameters (mainly thresholds) related to PowerControl 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 orpower 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 parametera specific field represents) depends on the service group as not all parameters are valid for all servicegroups.





2.5.2 SGxHOPAR and SGxPCPAR parameter values

2.5.2.1 SGxHOPAR parameter values (Handover)

The following parameters are represented by the SGxHOPAR fields:

HAND Attri bute Range Service GroupSet

Description

HOLTHLVDL 0..63 1, 2, 3, 4 lower RXLEV HO threshold for DLHOLTHLVUL 0..63 1, 2, 3, 4 lower RXLEV HO threshold for UL

HOTDLINT 0..63 1, 2, 3, 4 DL RXLEV threshold for intra-cell HO

HOTULINT 0..63 1, 2, 3, 4 UL RXLEV threshold for intra-cell HO

HORXLVDLI 0..63 1, 2, 3, 4 DL RXLEV threshold for concentric intra-cell HO from inner to complete cell

HORXLVDLO 0..63 1, 2, 3, 4 DL RXLEV threshold for concentric intra-cell HO from complete to inner cell

HOLTHQUDL 0..7 1, 2 lower RXQUAL HO threshold for DL

HOLTHQUUL 0..7 1, 2 lower RXQUAL HO threshold for UL

RHOLTQUDL 2..7 2 RXQUAL DL threshold for intra- and inter-cell HO (of data calls only)

RHOLTQUUL 2..7 2 RXQUAL UL threshold for intra- and inter-cell HO (of data calls only)

HOLTHQAMRDL 0..30 3, 4 lower C/I HO threshold for DL on AMR channels

HOLTHQAMRUIL 0..30 3, 4 lower C/I HO threshold for UL on AMR channels

HOTHAMRCDL 0..30 3 AMR Compression Handover threshold downlink

HOTHAMRCUL 0..30 3 AMR Compression Handover threshold uplink

HOTHAMRDDL 0..30 4 AMR Decompression Handover threshold downlink

HOTHAMRDUL 0..30 4 AMR Decompression Handover threshold uplink

Service Group Sets: 1 = signalling, non-AMR speech calls (SG-1, SG-2, SG-3, SG-4, SG-5, SG-6)2 = data calls (SG-7, SG-8, SG-9, SG-10)3 = AMR speech calls FR (SG-11, SG-12)4 = AMR speech calls HR (SG-13, SG-14)

Looking at the SGxHOPAR parameters in separate Service Group Sets, the following parameter valuestructure is implemented for each Service Group Set:

Handover Sevice Group Set 1 – Signalling and non-AMR speech calls (SG-1..SG-6)

SGxHOPAR(x=1..2, signaling)

= <field 1>-<field 2>..<field 8> = HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO

-HOLTHQUDL-HOLTHQUUL

SGxHOPAR(x=3..6, non-AMR speech calls)= <field 1>-<field 2>..<field 8> = HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO

-HOLTHQUDL-HOLTHQUUL

Handover Sevice Group Set 2 – Data calls (SG-7..SG-10)

SGxHOPAR(x=7..10, data calls) = <field 1>-<field 2>..<field 10>

= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQUDL-HOLTHQUUL

-RHOLTQDL-RHOLTQUL

Handover Sevice Group Set 3 – AMR FR calls (SG-11, SG-12)

SGxHOPAR(x=11..12) = = <field 1>-<field 2>..<field 10>

= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO

-HOLTHQAMRDL-HOLTHQAMRUL-HOTHAMR CDL-HOTHAMR CUL

Handover Sevice Group Set 4 – AMR HR calls (SG-13, SG-14)

SGxHOPAR(x=13..14) = = <field 1>-<field 2>..<field 10>

= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-

-HOLTHQAMRDL-HOLTHQAMRUL-HOTHAMR DDL-HOTHAMR DUL





2.5.2.2 SGxPCPAR parameter values (Power Control)

The following parameters are represented by the SGxPCPAR fields:

PWRC Attribute Range Service GroupSet

Description

EBSPWRC 0..2 1, 2 enables the BS power control (DISABLED/CLASSIC/ADAPTIVE).

EMSPWRC 0..2 1, 2 enables the MS power control (DISABLED/CLASSIC/ADAPTIVE).

EPWCRLFW 0..1 1, 2 enables Radio Link Failure power control.LOWTLEVD 0..63 1, 2 lower DL RXLEV threshold

LOWTLEVU 0..63 1, 2 lower UL RXLEV threshold

UPLTLEVD 0..63 1, 2 upper DL RXLEV threshold

UPTLEVU 0..63 1, 2 upper UL RXLEV threshold

PCRLFTH 0..64 1, 2 threshold for the radio link failure counter

LOWTQUAD 0..7 1 lower DL quality threshold for standard calls in RXQUAL

LOWTQUAU 0..7 1 lower UL quality threshold for standard calls in RXQUAL

UPTQUAD 0..7 1 upper DL quality threshold for standard calls in RXQUAL

UPTQUAU 0..7 1 upper UL quality threshold for standard calls in RXQUAL

LOWTQUAMRDL 0..30 2 lower DL quality threshold for AMR calls in C/I

LOWTQUAMRUL 0..30 2 lower UL quality threshold for AMR calls in C/I

UPTQUAMRDL 0..30 2 upper DL quality threshold for AMR calls in C/I

UPTQUAMRUL 0..30 2 upper UL quality threshold for AMR calls in C/I

Service Group Sets: 1 = signaling, non-AMR speech calls and data calls(SG-1, SG-2, SG-3, SG-4, SG-5, SG-6, SG-7, SG-8, SG-9, SG-10)

2 = AMR speech calls (SG-11, SG-12, SG-13, SG-14)

Looking at the SGxHOPAR parameters in separate Service Group Sets, the following parameter valuestructure is implemented for each Service Group Set:

Power Control Sevice Group Set 1 – Signalling, non-AMR speech calls and data calls (SG-1..SG-10)

SGxPCPAR(x=1..2, signaling)= <field 1>-<field 2>..<field 12> = EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH

-LOWTQUAD–LOWTQUAU-UPTQUAD-UPTQUAU

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

SGxPCPAR(x=7..10, data calls)

= <field 1>-<field 2>..<field 12> = EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH

-LOWTQUAD–LOWTQUAU-UPTQUAD-UPTQUAU

Power Control Sevice Group Set 2 – AMR calls (SG-11..SG-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

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





2.5.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 ofcall 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) orautomatically (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.6 Mapping of RXQUAL and C/I values for AMR calls

For AMR calls, the BTS algorithms for Power Control due to quality and Handover due to quality considerquality 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 PowerControl 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.

RXQUAL C/I

6,88 ... 7 1

6,63 ... 6,87 2

6,38 ... 6,62 4

6,13 ... 6,37 5

5,88 ... 6,12 6

5,63 ... 5,87 7

5,38 ... 5,62 8

5,13 ... 5,37 8

4,88 ... 5,12 9

4,63 ... 4,87 10

4,38 ... 4,62 11

4,13 ... 4,37 11

3,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 190,13 ... 0,37 20

0 ... 0,12 20





2.7 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 and is 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 SETBTS 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,505,15 9,50 - 3,00 5,00 5,50 5,00 6,50 8,00

5,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 lowerCODEC 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 higherCODEC 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 < AMRFRTH12C/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 thresholdC/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 > AMRFRTH12 + hysteresis (AMRFRTH12)C/I > 8 dB


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 > 5,25 dB


C/I < lower threshold

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 > AMRFRTH12 + hysteresis (AMRFRTH12)C/I > 8 dB


C/I < AMRFRTH12

C/I < 6dB

b) AMR link adaptation uplink



C/I > 6,35 dB


C/I < lower threshold

C/I < 4,24 dB





2.8 Common BCCH Solution for mixed frequency bands within thecomplete area

The implementation of the feature ‘Common BCCH’ was modified in order to allow special requirements ofthe US market (in BR6.1) and also the world market (in BR7.0).

Normal implementation of the feature common BCCH (starting from BR6.0)

Basically the feature ‘Common BCCH’ was designed in the following way:

• A ‘Common BCCH’ cell is a Concentric Cell with dual band configuration (SYSID=GSMDCS,GSM850PCS or GSM850DCS).

• Due to the propagation characteristics and the resulting cell size of the different frequency bands theINNER area was supposed to be configured with the higher frequency band (i.e. with DCS1800, orPCS1900 respectively) while the COMPLETE area should be created with the lower frequency band(GSM900, or GSM850 respectively). Thus the different coverage areas of INNER and COMPLETE areawould be more or less automatically determined by the different propagation characteristics of the usedfrequency bands.

In the normal implementation there are database command checks that prevent the operator from mixingfrequencies within the areas, i.e. it is not allowed to assign frequencies of the BCCH frequency band andnon-BCCH frequency band to TRXs that belong to the same area (INNER or COMPLETE). The databasecommand checks are in effect, if the SYSID Parameter (BTS object) is set to GSMDCS, GSM850PCS orGSM850DCS.

Modified implementation of the feature Common BCCH for the US-Market in BR6.0/BR6.1

In the US-Market the requirement was a little different from the basic idea of the feature:the customer wanted to install dual-band cells without necessity to configure a concentric cell, as both bandsshould provide exactly the same coverage area. Moreover, the main frequency band in the USA is PCS1900and GSM850 should be used as extension band (in a similar way as E-GSM is used as extension band forGSM900).

In the scope of the change request CRX688 which was written and approved for this reason, one MPCCpatch and one TDPC patch were developed in BR6.01 which changed the BSC behavior. In BR6.02 (BR6.1)the patches were removed an their function replaced by the MNTBMASK setting MNTBMASK=BIT24.

The effects of this modification in BR6.02 (BR6.1) is described below:

• The BIT24 modification has an impact on the MPCC and the TDPC

• MPCC impact:

Command checks for the Common BCCH feature are disabled. When BIT24 is selected, the databasecommand checks allow configuration of both TRXs with frequencies of the BCCH frequency band andTRXs with frequencies of the non-BCCH band both in INNER and in COMPLETE areas (the checks"same band on the same area and different bands on different areas, in dual band cells" are totallyremoved).

• TDPC impact: Modification of an internal check.

• To make the modified feature work in the desired way, it is, in BR6.1, urgently recommended to theoperator, not to create any TRX in the INNER area (CREATE TRX: TRXAREA=INNER). Instead, onlyTRXs with TRXAREA=COMPLETE should be created. Due to the disabled database command checksit is allowed to assign both GSM850 and PCS1900 frequencies to the COMPLETE area TRXs, althoughthey belong to the same area.

• During call setup, the PREFERRED AREA REQUEST procedure is executed as normal. But, as thereare no INNER area TCHs available, the BSC will allocate a COMPLETE area TCH on the basis of the

MS capabilities and the interference class only. For MSs that support the BCCH band only, the BSC, ofcourse, allocates the best TCHs (considering the interference class) from the BCCH frequency bandonly. For MSs that support both bands, the BSC allocates the best TCH (considering the interferenceclass), irrespective of the frequency band.

• Due to the fact that no INNER area TCH exists, the TDPC detects that the TCH ‘idle list’ (list of idleTCHs) in the INNER AREA is empty, which is the same condition as if all TCHs of the INNER area werebusy. This detection takes place on the first TCH allocation in the cell and triggers the sending of a SET ATTRIBUTE notification with 'INNER area congestion' towards the BTS which leads to the suspensionof the complete-to-inner handover. In other words, this handover will never be triggered by the BTS.





• MNTBMASK is set for the whole BSC (command SET BSC) but only has an impact on ‘Common BCCH’cells (i.e. cells that are configured as dualband concentric cells. In normal single-band concentric cellsthe TCH allocation in separate areas (INNER or COMPLETE) as well as the complete-to-inner andinner-to-complete intracell handovers works as normal.

Modified implementation of the feature ‘Common BCCH’ for the US-Market and world market inBR7.0

In BR7.0 the following changes were introduced compared to BR6.1:

• While in BR6.0/BR6.1 there is only a recommendation to refrain from creating INNER area TRXs, BR7.0does not allow it. In BR7.0 a command check is introduced, which prevents the operator from creatingand INNER area TRX, if MNTBMASK=BIT24 is set. Vice versa, if an INNER area TRX was alreadycreated, the command SET BSC: MNTBMASK=BIT24 is rejected with an appropriate NACK cause.

• Moreover, while in BR6.1 it was theoretically allowed to mix frequencies of the BCCH frequency bandand frequencies of the non-BCCH frequency band both in inner and complete area, in BR7.0 thismixture is only allowed in the COMPLETE area when MNTBMASK=BIT24 is selected.

• As a consequence of CR2199 (implemented with BR70/05), the modified common BCCH solution isnow also available for the frequency band pair GSM900 and DCS1800 (SYSID=GSMDCS).





2.9 BSC, MSC and BTS Overload Handling

2.9.1 BSC Overload

2.9.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 PPCC respectively PPXL boards.Buffer congestion can occur due to an excessive traffic volume or /and frequent retransmissions on the SS7links (e.g. by bad transmission 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 ofcurrently 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. Ifthe 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: This overload cause does not exist if PPLD is used instead of PPXX. The PPXX processorreal time processor load is periodically compared to a threshold which is hardcoded to 70%. If this thresholdis exceeded for a duration of 2 seconds the BSC regards this as an overload condition and starts the

associated overload handling measures (if BSCOVLH=TRUE). The BSC regards the overload condition asno longer present, if the PPXX processor real time has dropped below the same hardcoded threshold -oscillations are avoided using the timer T18 (see section ‘Mechanisms for traffic reduction').

6) A lack of PPXX memory resources is detected.

Background: This overload cause does not exist if PPLD is used instead of PPXX. This overload conditionindicates a lack of physical memory available in the PPXX board. If the memory occupation of the PPXXexceeds a hardcoded threshold of 70%, the BSC starts overload handling (if BSCOVLH=TRUE) to avoidmemory corruptions. The BSC regards the overload condition as no longer present, if the PPXX memoryusage has dropped below the same hardcoded threshold - oscillations are avoided using the timer T18 (seesection ‘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 parameterNBLKACGR (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 of180 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 ofPAGING 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: BR7.0/30 .. BR7.0/35 with patch T1340156

1 paging block is available 1/133.3 ms 1/90.0 ms

2 paging block are available 1/66.6 ms 1/45.0 ms 3 paging block are available 1/45.0 ms 1/30.0 ms

4 paging block are available 1/33.3 ms 1/22.5 ms5 paging block are available 1/26.6 ms 1/17.5 ms6 paging block are available 1/22.5 ms 1/15.0 ms7 paging block are available 1/20.0 ms 1/12.5 ms

8 paging block are available 1/16.6 ms 1/10.0 ms>8 paging block are available 1/15.0 ms 1/10.0 ms

Paging delivery rates* for PPLD board:

1/133.3 ms when 1 paging block is available

1/66.6 ms when 2 paging block are available






1/22.5 ms when 8 paging block are available1/20.0 ms when >8 paging block are available

* The '<n> ms' value means: '1 paging per <n> ms' (i.e. '20'ms' means '1 paging/20ms')

For each delivery rate, a length threshold is defined for the ‘scheduling’ paging queues as follows:

No. of paging blocks | Length threshold (no. of places in delivery queue)

available in the BTS | BR70/30..BR70/35 | with patch T1340156 +----------------------+------------------+------------------------+

1 paging block | 10 | 11 2 paging blocks | 20 | 22

3 paging blocks | 25 | 33



6 paging blocks | 40 | 67 7 paging blocks | 40 | 80

8 paging blocks | 40 | 100 >8 paging blocks | 40 | 100

+----------------------+------------------+------------------------+

This means that for a ‘scheduling’ paging queue the maximum number of queue places depends on theCCCH configuration / paging delivery rate as indicated in the table above. The length threshold (the lowerthe delivery rate, the less queue places are available) is applied to avoid that the ‘buffer time’ for the pagingsgets too long. This is necessary because the MSC, when it does not receive a PAGING RESPONSE to thefirst transmitted PAGING, repeats the paging procedure after a few seconds (the repetition time is defined bya configurable timer in the MSC (MOD NETTIMER, default 5 seconds).

Note: The maximum paging delivery rate for PPXL used to be 1 paging/10ms (360.000 pagings per hour) inSBS releases < BR70/30 and thus higher than the maximum delivery rate of 1 paging/15ms (240.000

pagings per hour) which is applied in releases starting from BR70/30 (the slightly slower delivery rate wasapplied in order to avoid unnecessary buffer congestion situations in the BTS). However, due to the fact thatthe new paging delivery rate (1 paging/15ms) is valid per delivery queue and thus per LAC, the resultingpaging delivery rate for the entire BSC can be, if more than one LAC is configured, considerably higher.





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 ofpaging 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).

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 thePTPPKF belonging to the same LAC/RAC on the same PCU

- The Packet Paging (PAPS) is received from Gb interface.

- The SGSN transmits the PAPS messages for a particular LAC/RAC, one message for each configuredPCU that serves a cell (PTPPKF) that belongs to the affected LAC/RAC. This means that multiple PCUs willlead to multiple PAPS messages, when the PTPPKFs of the same LAC/RAC are served by different PCUs.

- The PCUs forward each received PAPS message to the TDPC. As a consequence of the abovementionedprinciple, the TDPC may receive multiple PAPS messages for the same LAC/RAC, but from different PCUsand thus belonging to different cells (PTPPKFs).

- The TDPC stores stores the PAPS messages in the BSC paging queues as described below:

- 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 domainthere are at the maximum 9 different delivery rates, the resulting secondary queue are exactly the same asin the CS domain 20 LAC/RAC * 9 delivery rates = 180 secondary queues.

- 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 particularLAC/RAC may appear in a paging delivery queue more than once.

- Together with the PAPS message contents itself, the TDPC stores the information from which PCU (and forwhich PTPPKF) the PAPS was received in the queue places of the primary paging queue.

- When the PAPS is scheduled for delivery to the BTSs, the BSC checks from which PCU and for which cells(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).





OVERLOAD notification to MSC and alarm "A Interface Paging Overload Detected"

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 and theBSSMAP OVERLOAD message is sent to the MSC. Moreover, the alarm "A Interface Paging OverloadDetected" is output.

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 thethreshold was already reached in the queues related to the indicated LAC, the new paging is discarded andthe BSSMAP OVERLOAD message is sent towards the MSC. Moreover the alarm "A Interface PagingOverload Detected" is printed out.

The alarm "A Interface Paging Overload Detected" is ceased in case for T18 time there are no pagingcompletely discarded.

Remark: As can be seen from the above descriptions, the name of the alarm message "A Interface PagingOverload Detected" is a little misleading, as the pagings can also be received from the Gb interface.In fact, packet paging

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 "A Interface Paging Overload Detected" is output only if a PAGING cannot be placed in any of thescheduling paging queues available for one LAC.





2.9.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 ‘A INTERFACE PAGING OVERLOAD DETECTED’ towards the O&M outputmedia (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.9.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.9.1.3 Mechanisms for reduction of originating traffic and reduction of terminatingtraffic

2.9.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 forT18

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.9.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 ofCHANNEL 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.9.1.3.3 Special overload supervision algorithm in case of BSC paging queue overflow

The overload supervision algorithm for the BSC paging queue overflow differs a little from the one which isused for all other BSC overload conditions (as described in section 1.3.1).When an incoming PAGING message from the MSC is discarded due to lack of space in the BSC pagingqueue, an alarm is sent to the O&M output media (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 timeralso 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.9.2 MSC Overload

2.9.2.1 System reactions and overload regulation measures in case of MSC overload

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.9.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 ofCHANNEL 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. Ifno 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.9.3 BTS Overload

2.9.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. Paging is treated with priority, i.e. if both paging and IMMEDIATE ASSIGNMENTCOMMAND message are to be transmitted, the BTS uses the CCCH slot for paging first. Thus the PCHtraffic volume has an impact on the IMMEDIATE ASSIGNMENT via the AGCH: the higher the paging trafficvolume, the less CCCH space is available for IMMEDIATE ASSIGNMENT via the AGCH. To guarantee aminimum throughput of IMMEDIATE ASSIGNMENTs via the AGCH, it is possible to reserve CCCH blocksexclusively for AGCH (see parameter NBLKACGR in command SET BTS [CCCH]).

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 ofSDCCH blocking) IMMEDIATE ASSIGNMENT REJECT requires one place. How quickly the queue isemptied depends on the current paging traffic volume and on how many CCCH blocks are reserved for AGCH (NBLKACGR setting). If the BTS receives an IMMEDIATE ASSIGNMENT COMMAND orIMMEDIATE ASSIGNMENT REJECT for a particular CCCH timeslot which cannot be placed in the AGCH

queue associated to that CCCH timeslot, the BTS discards the IMMEDIATE ASSIGNMENT message andsends a DELETE INDICATION (that contains the original IMMEDIATE ASSIGNMENT COMMAND orREJECT message) to the BSC to indicate that the request of the MS for the assignment of a dedicatedsignalling channel could not be satisfied.

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), the trigger event for the‘BTS overload detected’ alarm output and the start or continuation of suitable overload regulation measures.





Category C: /* Abis LAPD signaling overload DL */ (MSG_LAPDOVLDN)

3) The BSC has detected an Abis LAPD signalling overload for a particular BTSM (throughput towards thatBTSM exceeds the link capacity)

Background: This overload situation can only occur if the BSC is equipped with PPLD boards.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 BTS). Theassociated layer 2 buffers are located in the PPLD boards. Buffer congestion can occur due to an excessivesignalling traffic volume or/and frequent retransmissions on the LAPD links (e.g. by bad transmission qualityof the PCM lines or microwave links). An inter-processor communication task (TDPC-PPLD) periodicallychecks the link throughput for each physical Abis signaling timeslot (i.e. the LPDLM timeslot that also carriesthe LPDLR radio signaling for the TRXs). The overload condition is detected when the throughput of at leastone physical Abis LPDLM timeslot configured for a particular BTSM exceeds the threshold of 80% of theLAPD link capacity. If this kind of Abis LAPD overload situation is detected, the BSC regards thissituation as an overload situation for all BTSs that belong to the same BTSM. When it is detected, the‘BTS overload detected’ alarm with the associated cause value is output and the suitable overload regulationmeasures are started or continued (if the overload situation already existed before). These reactions areindependent of the state of the BTSOVLH flag!

Category D: /* 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). Buffercongestion can occur due to an excessive signalling traffic volume or/and frequent retransmissions on theLAPD 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 E: /* 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 channel

towards 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 parameterTCCCHLDI 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 byBTS or BSC.





2.9.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), only incrementsovld_level_uplink.However, the first increase of ovld_level_uplink is performed starting from the second DELETEINDICATION message.This means, that, when the first DELETE INDICATION is received, the timer T18 is started and thealarm message ‘BTS overload detected’ is output, but in the first place the reduction of originating traffic(discarding of CHANNEL REQUIRED messages) is not yet started. This is only done if, before T2

expires, another DELETE INDICATION is receivedThis approach was used because the receipt of a single DELETE INDICATION just indicates that theBTS had to discard an IMMEDIATE ASSIGNMENT - this event can happen due to temporary lack ofCCCH resources and does not necessarily mean a persisting AGCH overload situation. For this reasonthe overload handling is started only if the AGCH overload situation is confirmed by at least one furtherDELETE INDICATION.

• Whenever PPLD Abis LAPD signalling overload is detected, both ovld_level_uplink andovld_level_downlink are immediately set to their maximum value (i.e. 10). This reaction is required tokeep the affected PPLD in service and to avoid unpredictable impacts on the board.





2.9.3.3 System reactions and overload regulation measures in case of BTS overload

BTS overload regulation is only started, if the database flag BTSOVLH (see command SET BSC [BASICS])is set to TRUE.Exception: When condition (3) (PPLD Abis LAPD signalling overload) is detected, the overload handling isstarted, irrespective of the value of the database flag BTSOVLH.

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) PPLD Abis LAPD signalling overload (internal TDPC check on DUAM usage)(4) 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 thePCH 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 parameterPCCCHLDI (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)- starts an algorithm for the reduction of originating traffic which discards CHANNEL REQUIRED messagesfor the affected BTS in correspondence with the current value of ovld_level_uplink. On the first detection ofthe AGCH overload condition (DELETE INDICATION message received), the variable ovld_level_downlinkstarts with the value ‘0’.

Case C: Abis LAPD signalling overload (internal TDPC check on DUAM usage)

When condition (3) is detected, the BSC- outputs an alarm message ‘243 - BTS Overload detected’* towards the O&M output media (RC, LMT,event logfile). This alarm is output for each BTS which belongs to the BTSM that is associated to theaffected LPDLM timeslot! - sends the BSSMAP message OVERLOAD with cell identity (**see note in section “Further important noteson BSC reactions”) and overload cause ‘processor overload’ to the MSC (one message every 2 seconds,see timer T2 as explained in the sections above). This message is sent for each cell which belongs tothe BTSM that is associated to the affected LPDLM timeslot! - starts an algorithm for the reduction of originating traffic which discards CHANNEL REQUIRED messagesfor the affected BTS in correspondence with the current value of ovld_level_uplink.- starts an algorithm for the reduction of terminating traffic which discards PAGING messages for the





affected BTS in correspondence with the current value of ovld_level_downlink.- On the first detection of the Abis LAPD signalling overload condition (DELETE INDICATION messagereceived), the both variables ovld_level_downlink and ovld_level_uplink start with the maximumvalue ‘10’.

Attention: All described measures in case C are independent of the flag BTSOVLH!

Case D: RACH overload (BTS sends CCCH LOAD INDICATION)

When condition (4) 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.9.4 Interaction of BTS Overload and BSC OverloadIf 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 (orovld_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 notdiscarded.

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 REQUIREDs0 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.9.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 (LPDLM) ........................................................ 93 ABISHRACTTHR......................................................... 81 ABISTRFHITHR........................................................... 84 ABISTRFLTHR............................................................. 85

ABUTYP........................ ............................................. 187 ACCEPTGDEGR......................................................... 18 ACHAN................................................... ....................309 AISAT........................................................................... 19 ALACOUNT.................................................................. 52 ALARMT1..................................................................... 52 ALARMT2..................................................................... 52 ALARMT3..................................................................... 52 ALEVFULHO.............................................................. 228 ALLCRIT ...................................................................... 65 ALPHA ....................................................................... 187 ALRMSEVBTS............................ ................................. 46 ALRMSEVBTSM........................................... ...............46 ALRMSEVCBCL .......................................................... 46 ALRMSEVCPEX.......................................................... 49 ALRMSEVDISK............................................................49

ALRMSEVDK40............................................... ............49 ALRMSEVEPWR......................................................... 50 ALRMSEVFRL............................................................. 46 ALRMSEVIPLI.............................................................. 46 ALRMSEVIXLT ............................................................ 50 ALRMSEVLICD............................................................ 50 ALRMSEVLICDS ......................................................... 50 ALRMSEVLPDLM................................................... .....46 ALRMSEVLPDLMTD................ ................................... 47 ALRMSEVLPDLR........................................................ 47 ALRMSEVLPDLRTD ................................................... 47 ALRMSEVLPDLS ........................................................ 47 ALRMSEVME2M..........................................................50 ALRMSEVMEMT ......................................................... 50 ALRMSEVMPCC ......................................................... 50

ALRMSEVNSVC........................................... ...............47 ALRMSEVNTW............................................................ 50 ALRMSEVOMAL.......................................................... 47 ALRMSEVPCMA ......................................................... 47 ALRMSEVPCMB ......................................................... 47 ALRMSEVPCMG......................................................... 47 ALRMSEVPCMS ......................................................... 47 ALRMSEVPCU ............................................................ 47 ALRMSEVPCUTD ....................................................... 47 ALRMSEVPPCC............................................ ..............50 ALRMSEVPPCU............................................ ..............50 ALRMSEVPPLD .......................................................... 50 ALRMSEVPPXL........................................................... 50 ALRMSEVPPXP .......................................................... 51 ALRMSEVPPXT .......................................................... 51 ALRMSEVPPXU.......................................................... 51

ALRMSEVPTPPKF...................................................... 48 ALRMSEVPWRD.......................................... ...............51 ALRMSEVSYNC............................................ ..............51 ALRMSEVSYNE.......................................................... 51 ALRMSEVTDCU.............................. ............................ 48 ALRMSEVTDPC.......................................................... 51 ALRMSEVTRAU.......................................................... 48 ALRMSEVTRX............................................................. 48 ALRMSEVTRXTD.......................................... ..............48 ALRMSEVX25A........................................................... 51 ALRMSEVX25D...................................... ..................... 51 ALTH .......................................................................... 320 AMONTH...................................................................... 19

AMRACMRDL............................................................ 229 AMRFRC1 (BTS)....................................................... 100 AMRFRC1 (FHSY) .................................................... 214 AMRFRC2 (BTS)....................................................... 104 AMRFRC2 (FHSY) .................................................... 214 AMRFRC3 (BTS)....................................................... 104

AMRFRC3 (FHSY) .................................................... 214 AMRFRC4 (BTS)....................................................... 104 AMRFRC4 (FHSY) .................................................... 215 AMRFRIC (BTS) ........................................................ 105 AMRFRIC (FHSY)...................................................... 215 AMRFRTH12 (BTS)................................................... 105 AMRFRTH12 (FHSY)................................................ 215 AMRFRTH23 (BTS)................................................... 106 AMRFRTH23 (FHSY)................................................ 215 AMRFRTH34 (BTS)................................................... 106 AMRFRTH34 (FHSY)................................................ 216 AMRHRC1 (BTS)....................................................... 107 AMRHRC1 (FHSY).......... .......................................... 216 AMRHRC2 (BTS)....................................................... 107 AMRHRC2 (FHSY).......... .......................................... 216 AMRHRC3 (BTS)....................................................... 107

AMRHRC3 (FHSY).......... .......................................... 216 AMRHRC4 (BTS)....................................................... 108 AMRHRC4 (FHSY).......... .......................................... 216 AMRHRIC (BTS)........................................................ 108 AMRHRIC (FHSY)..................................................... 217 AMRHRTH12 (BTS) .................................................. 109 AMRHRTH12 (FHSY)................................................ 217 AMRHRTH23 (BTS) .................................................. 109 AMRHRTH23 (FHSY)................................................ 217 AMRHRTH34 (BTS) .................................................. 110 AMRHRTH34 (FHSY)................................................ 217 AMRLKAT.................................................................. 110 ANTHOPMOD ........................................................... 110 ANTHOPP.................................................................. 111 APLESSNBSC........................................................... 294 APLESSNSMLC........................................................ 294 ASCIONECHMDL........................................................ 19 ASCISER................................................................... 140 ASCIULR ................................................................... 140 ASEV ......................................................................... 316 ASMONTH................................................................... 20 ASSLAPD .................................................................... 99 ASTRING................................................................... 316 ASUBCH...................................................................... 69 ASUBENCAP............................................................... 20 ASUBISAT................................................................... 20 ATIME1...................................................................... 321 AUTOREP.................................................................. 320

B

BAF (PCMA) ................................................................ 69

BAF (PCMB) ................................................................ 59BAF (PCMG)................................................................ 77BAF (PCMS) ................................................................ 63BAND......................................................................... 321BANDOFHYS............................................................. 320BAUDRATE ............................................................... 307BCCHFREQ (BTS [BASICS]).................................... 111BCCHFREQ (TGTBTS)..................... ........................ 273BEPAVGP.................................................................. 187BER (PCMA)..................................................... ........... 70BER (PCMB)..................................................... ........... 59BER (PCMG) ............................................................... 77BER (PCMS)..................................................... ........... 63





BHOFOT .................................................................... 277BLERAVEDL..............................................................188BLERAVEUL..............................................................188BMONTH....................................................................160BPAGCHR ................................................................. 188BPRACHR..................................................................189BSCDVMA ................................................................. 189BSCOVLH.................................................................... 21BSCT1.................................................................. ........12

BSCT10........................................................................ 12BSCT11........................................................................ 13BSCT13........................................................................ 13BSCT17........................................................................ 14BSCT18........................................................................ 14BSCT19........................................................................ 14BSCT20........................................................................ 14BSCT3.................................................................. ........15BSCT3121.................................................................... 15BSCT4.................................................................. ........15BSCT7.................................................................. ........16BSCT8.................................................................. ........17BSCTQHO ................................................................... 17BSIC (BTS [BASICS]) ................................................ 111BSIC (TGTBTS) ......................................................... 273BSMONTH ................................................................. 160

BSPBBLK...................................................................189BSSAPSSN................................................................294BTSHSCSD................................................................111BTSOVLH .................................................................... 21BVCBHIPER .............................................................. 190BVCBLPER..... ........................................................... 190BVCBMAPER.............................................................190BVCBSPPER............................................................. 190

C

C31H .......................................................................... 190C32QUAL...................................................................190CACKTYP .................................................................. 191CALLF01.................................................................... 112CALLF02..CALLF63...................................................112CBCPH........................................................ .................21CBQ............................................................................112CCDIST......................................................................230CCELL1......................................................................230CCELL2......................................................................230CELLBARR................................................................ 160CELLGLID (BTS [BASICS]).......................................113CELLGLID (TGTBTS)................................................274CELLGLID (TGTFDD)................................................289CELLRESH................................................................ 113CELLTYPE.................................................................114CFS .............................................................................. 10CHPOOLTYP.............................................................225CHTYPE.............................................219, 220, 222, 225CICFM..........................................................................21CID ............................................................................. 315

CITASUP...................................................................... 21CLOCK.......................................................................307CODE (PCMA).............................................................70CODE (PCMB).............................................................61CODE (PCMG)............................................................. 77CODE (PCMS).............................................................63CONCELL .................................................................. 115CONGTH....................................................................299CPOLICY...................................................................... 22CRC (PCMA)................................................................ 70CRC (PCMB)................................................................ 59CRC (PCMG) ............................................................... 77CRC (PCMS)................................................................ 63

CREALL..................................................................... 161CREATE ADJC.......................................................... 277CREATE ADJC3G..................................................... 290CREATE BTS [BASICS]..................... ....................... 100CREATE BTSM ........................................................... 81CREATE CBCL.......................................................... 312CREATE CHAN (BCCH) ........................................... 219CREATE CHAN (SDCCH)......................................... 220CREATE CHAN (TCH) .............................................. 222

CREATE CHAN (TCH/SD)........................................ 225CREATE CTRSCHED ............................................... 314CREATE ENVA ......................................................... 316CREATE EPWR .......................................................... 51CREATE FHSY.......................................................... 214CREATE FRL .............................................................. 79CREATE LICD ............................................................. 52CREATE LICDS.................................................... ....... 52CREATE LPDLM ......................................................... 93CREATE LPDLS..................... ..................................... 69CREATE NSVC ........................................................... 80CREATE NUC ........................................................... 306CREATE OMAL......................................................... 311CREATE OPC [BASICS] ........................................... 294CREATE PCMA............ ............................................... 69CREATE PCMB............ ............................................... 59

CREATE PCMG .......................................................... 77CREATE PCMS............ ............................................... 63CREATE PCU................................................ .............. 53CREATE PPLD........... ................................................. 53CREATE PTPPKF ..................................................... 187CREATE RFLOOP .................................................... 320CREATE SCA............................................................ 321CREATE SS7L .......................................................... 305CREATE SUBTSLB..................................................... 99CREATE SYNC ......................................................... 312CREATE SYNE ......................................................... 312CREATE TGTBTS..................................................... 273CREATE TGTFDD..................................................... 289CREATE TGTPTPPKF....................... ....................... 275CREATE TRACE....................................................... 313CREATE TRAU ........................................................... 65CREATE TRX ............................................................ 210CREATE X25A .......................................................... 309CREATE X25D .......................................................... 307CRESELTHRINP....................................................... 191CRESELTRHSOUT.................................. ................. 191CRESOFF......................................................... ......... 116CRESPARI................................................................. 117CSCH3CSCH4SUP (BSC).......................................... 23CSCH3CSCH4SUP (PTPPKF) ................................. 191

D

DEFPOOLTYP............................................................. 70DGRSTRGY................................................................. 24DIRTCHASS.............................................................. 162DISTHO ..................................................................... 230

DLAPDOVL.................................................................. 25DPBGTHO................................................................. 231DRXTMA...................................... .............................. 192DTEDCE .................................................................... 307DTXDLFR .................................................................. 163DTXDLHR.................................................................. 166DTXUL ....................................................................... 166

E

EADVCMPDCMHO ................................................... 231EANTHOP.................................................................. 118EARCLM.................................................................... 166EBCCHTRX............................................................... 213





EBSPWCR................................................................. 173EBSPWRC................................................................. 174EBUSYCUM...............................................................321EC .............................................................................. 167EEDGE.......................................................................213EEICM........................................................................321EEOTD.......................................................................118EEXCDIST ................................................................. 271EFRSUPP .................................................................... 25

EFULHO.....................................................................234EGPLGPEIGHTTS.....................................................192EGPLGPFIVETS........................................................192EGPLGPFOURTS ..................................................... 192EGPLGPONETS........................................................192EGPLGPSEVENTS ................................................... 192EGPLGPSIXTS..........................................................192EGPLGPTHREETS ................................................... 193EGPLGPTWOTS ....................................................... 193EGPRS.......................................................................213EGWSEIGHTTS ........................................................ 193EGWSFIVETS............................................................193EGWSFOURTS ......................................................... 193EGWSONETS............................................................193EGWSSEVENTS....................................................... 193EGWSSIXTS..............................................................194

EGWSTHREETS ....................................................... 194EGWSTWOTS........................................................... 194EHRACT .................................................................... 119EHRACTAMR .............................................................. 26EICNF1.......................................................................321EISDCCHHO................................................................ 26ELEVHOM..................................................................235ELIMITCH .................................................................. 235ELKADPT...................................................................194EMCSFAMA1DL........................................................ 194EMCSFAMAP1DL......................................................194EMCSFAMB1DL........................................................ 195EMCSFAMCDL..........................................................195EMCSFAMGDL..........................................................195EMFA1UNIR8PSK..................................................... 195EMFAP1UNIR8PSK...................................................195EMFB1UNIR8PSK..................................................... 195EMFCUNIR8PSK.......................................................195EMFCUNIRGMSK ..................................................... 195EMFGUNIR8PSK.......................................................195EMFGUNIRGMSK ..................................................... 195EMSPWRC ................................................................ 175EMT1............................................................................85EMT2............................................................................86ENANCD.................................................................... 151ENCALSUP..................................................................26ENDML.......................................................................321ENFOIAHO .................................................................. 27ENFORCHO................................................................. 27ENHSCSD.................................................................... 28ENVANAME...... ......................................................... 316

EPA .............................................................................. 29EPAT1........................................................................121EPAT2........................................................................122EPOOL.........................................................................30EPRE..........................................................................168EPREHSCSD............................................................... 30EPWCRLFW .............................................................. 175EQ .............................................................................. 169EQPOS ........................................................................ 49ERRACT ...................................................................... 30ERRCORMTD............................................................300ERUDGR....................................................................269ESUP............................................................................ 30ETFO............................................................................67

ETIME.......................................................................... 10ETXDIVTS ................................................................. 122EUBCHO.................................................................... 236EUHO.................................................................... ..... 236EUIMPHO .................................................................. 237EUSCHO.................................................................... 238EUSDCHO................................................................... 31EXCDIST ................................................................... 271EXPSWV (BTSM) ........................................................ 86

EXPSWV (TRAU) ........................................................ 68EXTCHO.................................................................... 238EXTMODE......................................... 219, 221, 222, 226

F

FACCHQ...................................... .............................. 122FDDARFCN............................................................... 289FDDDIV...................................................................... 289FDDGQO................................................................... 196FDDMURREP.................... ........................................ 122FDDQMI............................... ...................................... 122FDDQO...................................................................... 122FDDREPQTY............................................................. 123FDDSCRMC .............................................................. 289FHORLMO........ ......................................................... 278FHSYID.......................... ....................220, 221, 222, 227

FLAPDOVLTH ............................................................. 86FLOWCTH................................................................. 300FRSTD......................................................................... 79FRTERM.................................................................... 306FULHOC .................................................................... 278FULRXLVMOFF ........................................................ 279

G

GAM.................. ......................................................... 196GASTRABISTH ........................................................... 87GASTRTH......................................................... ......... 196GCELLRESH............................................................. 197GDCH (TCH) ............................................................. 223GDCH (TCHSD) ........................................................ 227GFDDMURREP......................................................... 197

GFDDQMI.................................................................. 197GFDDREPQTY................................................. ......... 197GHCSPC (ADJC)....................................................... 279GHCSPC (PTPPKF)............... ................................... 197GHCSTH (ADJC)................................ ....................... 279GHCSTH (PTPPKF).................................................. 197GLK............. ................................................................. 79GMANMSAL .............................................................. 197GMANPRES .............................................................. 198GMANRETS .............................................................. 198GMSTXPMAC (PTPPKF).......................................... 198GMSTXPMAC (TGTPTPPKF)................................... 275GNMULBAC............................................................... 198GPATH....................................................................... 199GPDPDTCHA ............................................................ 199GPENTIME (ADJC) ................................................... 279

GPENTIME (PTPPKF) .............................................. 199GRESOFF (ADJC)..................................................... 279GRESOFF (PTPPKF)......................... ....................... 199GRXLAMI (PTPPKF) ................................................. 200GRXLAMI (TGTPTPPKF)........................................ .. 276GS.............................................................................. 201GSUP (ADJC)........... ................................................. 280GSUP (TRX) .............................................................. 210GTDDMURREP......................................................... 201GTEMPOFF (ADJC).................................................. 280GTEMPOFF (PTPPKF) ............................................. 201GTS.............................................................. ................ 79GTXINT............................ .......................................... 201





GUARMABIS..............................................................124GUMTSSRHPRI ........................................................ 201

H

HCICN..........................................................................75HIERC ........................................................................ 239HIERF.........................................................................239HOAVDIST.................................................................239HOAVELEV................................................................240

HOAVPWRB.............................................................. 241HOAVQUAL............................................................... 242HOCCDIST ................................................................ 243HOLTHLVDL..............................................................243HOLTHLVUL..............................................................243HOLTHQAMRDL ....................................................... 244HOLTHQAMRUL ....................................................... 245HOLTHQUDL.............................................................245HOLTHQUUL.............................................................246HOM (ADJC).............................................................. 281HOM (ADJC3G) ......................................................... 290HOMDOFF (ADJC) .................................................... 281HOMDOFF (ADJC3G) ............................................... 290HOMDTIME (ADJC)...................................................281HOMDTIME (ADJC3G)..............................................291HOMRGTA.................................................................246

HOMSOFF (ADJC) .................................................... 282HOMSOFF (ADJC3G) ............................................... 291HOMSTAM.................................................................246HOPMODE.................................................................170HOPP ......................................................................... 271HORXLVDLI...............................................................247HORXLVDLO.............................................................248HOSYNC......................................................................31HOTDLINT ................................................................. 249HOTHAMRCDL..........................................................249HOTHAMRCUL..........................................................250HOTHAMRDDL..........................................................250HOTHAMRDUL..........................................................251HOTHCMPLVDL........................................................251HOTHCMPLVUL........................................................251HOTHDCMLVDL........................................................252HOTHDCMLVUL........................................................252HOTMSRM.................................................................252HOTMSRME .............................................................. 252HOTULINT ................................................................. 253HRACTAMRT1...........................................................125HRACTAMRT2...........................................................126HRACTT1...................................................................127HRACTT2...................................................................127HRSPEECH ................................................................. 32HSN............................................................................217

I

IERCHOSDCCH ........................................................ 253IMCSULNIR8PSK...................................................... 202IMCSULNIRGMSK.....................................................202

IMSIATDT .................................................................. 171IMSIFSIZ ...................................................................... 11INIBLER ..................................................................... 202INICSCH .................................................................... 202INIMCSDL .................................................................. 202ININHO.......................................................................254INTAVEPR ................................................................. 149INTCLASS..................................................................149INTERCH ................................................................... 255INTINF........................................................................316INTRACH ................................................................... 255IRACHOSDCCH ........................................................ 256

L

L1CTS........................... ............................................... 60L2WIN................................................................ 307, 309L3PS .................................................................. 307, 309L3WIN................................................................ 307, 309LAPDOVLT.................................................................. 87LAPDPOOL (LPDLM).................. ................................ 94LAPDPOOL (LPDLS) .................................................. 69LCBM0....................................................................... 128LCBM1....................................................................... 128LCBM2....................................................................... 128LCBM3....................................................................... 128LCN2WC................................... ......................... 307, 309LCSMONTH................................................................. 32LCSNSSC.................................................................... 32LEVHOM.................................................................. .. 282LEVONC.................................................................... 282LINKTYPE (CBCL) .................................................... 312LINKTYPE (OMAL)............................................... ..... 311LKSET........................................................................ 305LNKA.......................................................................... 305LOTERCH...................................................... ............ 256LOTRACH................................................................ .. 256LOWBER (PCMA) ....................................................... 75

LOWBER (PCMB) ....................................................... 61LOWBER (PCMG)....................................................... 77LOWBER (PCMS) ....................................................... 63LOWTLEVD............................................................... 175LOWTLEVU............................................................... 175LOWTQUAD.............................................................. 176LOWTQUAMRDL ...................................................... 176LOWTQUAMRUL ...................................................... 177LOWTQUAU.............................................................. 177LPDLMN .................................................................... 210LPDLMSAT.................... .............................................. 88LREDUNEQ (PCMB)................................................... 61LREDUNEQ (PCMS)................................................... 63

M

M2T1........... ............................................................... 300

M2T2........... ............................................................... 301M2T3........... ............................................................... 301M2T4E ....................................................................... 301M2T4N ....................................................................... 301M2T5........... ............................................................... 301M2T6........... ............................................................... 301M2T7........... ............................................................... 301M3T1........... ............................................................... 302M3T10......................... ............................................... 302M3T12......................... ............................................... 303M3T13......................... ............................................... 303M3T14......................... ............................................... 303M3T17......................... ............................................... 303M3T19......................... ............................................... 303M3T1TM..................................................................... 303M3T2........... ............................................................... 303M3T22OR20 .............................................................. 304M3T22OR21 .............................................................. 304M3T2TM..................................................................... 304M3T3........... ............................................................... 304M3T4........... ............................................................... 304M3T5........... ............................................................... 304MACONN................................................................... 315MADGRLV................................................................... 32MAFIRACHO ............................................................... 32MAIO............. ..................................... 220, 221, 223, 227MAIRACHO................................................................ 256MASCLOGFS .............................................................. 11MAXFAILHO.............................................................. 257





MAXNCELL..................................................................33MAXRETR..................................................................142MECNT ...................................................................... 320MEDAFUPE ................................................................. 11MEDAFUST ................................................................. 11MELID .......................................................................... 10MICROCELL (ADJC) ................................................. 282MICROCELL (ADJC3G) ............................................ 291MINCCNT...................................................................320

MNTBMASK.................................................................33MOBALLOC............................................................... 218MOEC.........................................................................211MSBHIPER ................................................................ 202MSBLPER.................................................................. 202MSBMAPER...............................................................203MSBSPPER............................................................... 203MSCOVLH ................................................................... 34MSCPERTFLAG........................................................ 294MSCPOOL ................................................................... 35MSCSPC....................................................................294MSCV...........................................................................35MSTXPMAXCH..........................................................142MSTXPMAXCL .......................................................... 283MSTXPMAXDCS (BTS [BASICS]) ............................ 128MSTXPMAXDCS (TGTBTS) ..................................... 274

MSTXPMAXGSM (BTS [BASICS])............................129MSTXPMAXGSM (TGTBTS).....................................274MSTXPMAXPCS (BTS [BASICS]).............................129MSTXPMAXPCS (TGTBTS)......................................274MSTXPMAXUMTS (TGTFDD) .................................. 289

N

N1 301N2 302N2WC.................................................................307, 309N3101...........................................................................53N3103...........................................................................53N3105...........................................................................54N391.............................................................................79N392.............................................................................79N393.............................................................................80NALLWACC ............................................................... 171NAVGI ........................................................................ 203NBLKACGR ............................................................... 143NBVCBR ...................................................................... 54NBVCRR...................................................................... 54NBVCUR...................................................................... 54NCC1TH.....................................................................203NCC1THADJC ........................................................... 283NCDP1 ....................................................................... 152NCDP2 ....................................................................... 152NCELL........................................................................257NCGPENTIME ........................................................... 283NCGRESOFF.............................................................283NCGTEMPOFF..........................................................283NCRARESH............................................................... 203

NCRESELFLAG........................................................... 35NCSARA .................................................................... 204NCTRFPSCTH...........................................................204NECI.............................................................................36NETWTYPE ................................................................. 37NFRAMEPG...............................................................144NMDLATT1 ................................................................ 322NMO.............................................................................54NMULBAC..................................................................131NNSVCBLKR............................................................... 55NNSVCRR ................................................................... 55NNSVCTSTR............................................................... 55NNSVCUBLR...............................................................55

NOBAKHO................ ................................................. 257NOCHBLKN..................... .......................................... 145NOCHFBLK ............................................................... 145NOFREPHO .............................................................. 257NOTFACCH................................................................. 37NRLCMAX ................................................................... 55NRPGRANT............................................................... 152NSEI........................................................... .................. 55NSLOTST .................................................................. 146

NSVCI .......................................................................... 80NSVLI....................................................................... .... 80NTWCARD................................................................... 38NTWCNDRXP ........................................................... 204NTWCOR.................................... ............................... 204NTWCREPPIDL......................................................... 205NTWCREPPTR ......................................................... 205NTWIND................................................................ ..... 295NUA (PCMA)................................................................ 75NUA (PCMB)................................................................ 61NUA (PCMG) ............................................................... 78NUA (PCMS)................................................................ 63NY1 ............................................................................ 148

O

OMCCPT (OMAL)...................................................... 311

OMLAPDRT................ ................................................. 89OPC ........................................................................... 295OVLENTHR ................................................................. 38OVLSTTHR.................................................................. 38

P

PAVRLEV .................................................................. 178PAVRQUAL ............................................................... 179PBGTHO.......................................................... .......... 258PCCCHLDI................................................................. 131PCMBSTXPRL .......................................................... 180PCMCON0................................................................... 90PCMCON1................................................................... 90PCMCON2................................................................... 90PCMCON3................................................................... 90

PCMECH ................................................................... 205PCML (PCMB) ............................................................. 61PCML (PCMG)............................................................. 78PCML (PCMS) ............................................................. 64PCMSN........................................................................ 68PCMSOBJ.................................................................. 312PCMT..... ...................................................................... 75PCMTYPE.................................................................... 38PCONINT.............................. ..................................... 180PCRLFTH .................................................................. 181PCUID......... ................................................................. 80PENTIME................................................................... 132PERSTLVPRI1 .......................................................... 205PERSTLVPRI2 .......................................................... 205PERSTLVPRI3 .......................................................... 205PERSTLVPRI4 .......................................................... 205

PERWEEK............................. .................................... 315PKTMEASREPCNT................................................... 206PKTNDEC...................................................... ............ 206PKTNINC ................................................................... 206PKTNMA.................................................................... 206PL 258PLMNP....................................................................... 132PLNC (ADJC) ............................................................ 284PLNC (ADJC3G)........................................................ 291POOLTYP.............................. ...................................... 76PPLNC (ADJC) .......................................................... 284PPLNC (ADJC3G) ..................................................... 292PRPBCCH ................................................................. 206




PUREBBSIG44CONF................................................132PWRCONF.................................................................181PWRINCSS................................................................181PWROFS ................................................................... 148PWROUT ................................................................... 172PWRRED ................................................................... 211PWRREDSS .............................................................. 181

Q

QL...............................................................................172QSRHC ...................................................................... 133QSRHCINI..................................................................133QSRHI........................................................................133QSRHPRI...................................................................206

R

R20.....................................................................308, 310R22.....................................................................308, 310R23.....................................................................308, 310RAARET.....................................................................206RACHBT .................................................................... 133RACHLAS .................................................................. 134RACODE (PTPPKF) .................................................. 207RACODE (TGTPTPPKF)...........................................276RACOL (PTPPKF) ..................................................... 207RACOL (TGTPTPPKF)..............................................276RADIOMG.................................................................. 212RADIOMR .................................................................. 212RAENV.......................................................................207RARESH .................................................................... 207RAVEW...................................................................... 269RDGRUL............................................................ 269, 270RDLNKTBS................................................................ 182RDLNKTO.................................................................. 135RECCRI ..................................................................... 313REMAL (PCMA)...........................................................75REMAL (PCMB)...........................................................61REMAL (PCMG)...........................................................78REMAL (PCMS)...........................................................64REPTYP.....................................................................135

RETRY ............................................................... 308, 310RFRSINDP.................................................................150RHOLTQDL................................................................270RHOLTQUL................................................................270RNCID........................................................................290RUGRDL............................................................ 269, 270RXLEVAMI................................................................. 135RXLEVHO.................................................................. 258RXLEVMIN.................................................................284RXLEVMINC .............................................................. 292RXLV..........................................................................320RXQUALHO...............................................................258

S

SALUNAME (BSCE).................................................... 49SALUNAME (BTSM)........................ ............................ 91

SET BTS [CCCH] ...................................................... 140SET BTS [INTERF]... ................................................. 149SET BTS [OPTIONS] ........................................ 160, 271SET BTS [TIMER].................................................... .. 151SET HAND [BASICS] ................................................ 228SET HAND [DATA].................................................... 269SET MEL...................................................................... 10SET OPC [MTL2]............ ........................................... 299SET OPC [MTL3]............ ........................................... 302

SET PTPPKF................... .......................................... 213SET PWRC................................................................ 173SET TSLA.................................................................... 76SG10HOPAR........................................................... .. 259SG10PCPAR............................................................. 182SG11HOPAR........................................................... .. 259SG11PCPAR............................................................. 182SG12HOPAR........................................................... .. 259SG12PCPAR............................................................. 182SG13HOPAR........................................................... .. 259SG13PCPAR............................................................. 182SG14HOPAR........................................................... .. 259SG14PCPAR............................................................. 182SG1HOPAR............................................... ................ 259SG1PCPAR ............................................................... 182SG2HOPAR............................................... ................ 259

SG2PCPAR ............................................................... 182SG3HOPAR............................................... ................ 259SG3PCPAR ............................................................... 182SG4HOPAR............................................... ................ 259SG4PCPAR ............................................................... 182SG5HOPAR............................................... ................ 259SG5PCPAR ............................................................... 182SG6HOPAR............................................... ................ 259SG6PCPAR ............................................................... 182SG7HOPAR............................................... ................ 259SG7PCPAR ............................................................... 182SG8HOPAR............................................... ................ 259SG8PCPAR ............................................................... 182SG9HOPAR............................................... ................ 259SG9PCPAR ............................................................... 182SHLAPDIT ................................................................... 91SIMSCREL99............................................................... 39SISGSNREL99 ............................................................ 39SLAPDOVLTH............................................................. 91SLC............................................................................ 305SMLCPERTFLAG...................................................... 295SMLCSPC.................................................................. 295SMSCBUSE............................................................... 272SPEED145................................................................... 40SPENLAW ................................................................... 40SS7MTPTYP.............................................................. 295START ....................................................... 315, 320, 322STGTTLLIINF ............................................................ 208STOP ......................................................... 315, 320, 322SYSID (BTS).................................. ............................ 137SYSID (TGTBTS) ...................................................... 275

Documents

BSC_Database_Parameter_Description_BR7(Version_01.03.05).pdf