Db70 Dsc Bettoni

s

Siemens Base Station (SBS)

BSC Database Parameter Description BR7.0 Version 05.07.2007

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

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

made by:

Eckardt Bertermann SIEMENS AG ICM N PG SI RG2, Technical Product Support BSS-SBS Tel.: +49 89 722 61361 FAX: +49 89 722 28990 e-mail: [email protected] GPRS contributions by:

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

Please consider the remarks on the next page!



IMPORTANT

• This document is not officially released and is designed as quick reference document for SBS BSC database parameters.

• This document is a working document and is continuously modified and enhanced with the latest information. Changes 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 and features shall be not be sent to the authors but to the local TAC2 or TAC3/NCC as an official hotline query!!!

(For queries to TPS-BSS, please use the well-known procedures e.g. via the URL https://ims.icn.siemens.de/livelink/livelink/Guest/Launch/308438668)

!



Contents:

1 DATABASE BR7.0 .........................................................................................................................................................7

1.1 PRINCIPLE CONFIGURATION DIAGRAMS .........................................................................................................................7 1.1.1 Example Configuration of Terrestrial Interfaces ..............................................................................................7 1.1.2 BR7.0 Object Tree of BSC database objects ..................................................................................................8

1.2 BSC DATABASE COMMANDS AND PARAMETERS...................................................................................................10 Setting the object entry point and time and date for the BSS:.................................................................................10 Setting the BSC control values for periodic measurement data file upload:............................................................10 Setting the timing values for BSSMAP control and BSC overload handling:...........................................................12 Setting the global parameters of the BSC: ..............................................................................................................18 Setting the alarm priorities of the BSS functional objects:.......................................................................................46 Setting the remote Inventory data of the BSC Equipment:......................................................................................49 Setting the alarm priorities of the BSCE objects:.....................................................................................................49 Creating the Power Supply:.....................................................................................................................................51 Creating the spare PCM interface boards: ..............................................................................................................52 Creating the PCM interface boards: ........................................................................................................................52 Creating the LAPD boards:......................................................................................................................................53 Creating the PCU objects: .......................................................................................................................................53 Creating the PCM links for the Abis interface:.........................................................................................................59 Creating the PCMS link: ..........................................................................................................................................63 Creating the TRAU: .................................................................................................................................................65

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

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

Power Control Parameter Relations .................................................................................................................185 Creating the GPRS point to point packet transfer service in a cell:.......................................................................186 Creating the LPDLR links: .....................................................................................................................................208 Creating the TRXs: ................................................................................................................................................209 Enabling GPRS and EDGE in a cell: .....................................................................................................................212 Creating the Frequency Hopping systems: ...........................................................................................................213 Creating the BCCH for the cell: .............................................................................................................................218 Creating the SDCCHs for the cell: .........................................................................................................................219 Creating the TCHs for the cell: ..............................................................................................................................221 Creating hybrid TCHs/SDCCHs (TCH/SD) for the cell: .........................................................................................223 Setting the cell specific parameters and threshold values for voice call Handover: ..............................................227

Handover Parameter Relations ........................................................................................................................266 Setting the cell specific parameters and threshold values for 14,4kbit/s data call up- and downgrading and quality inter-cell handover: ................................................................................................................................................268 Setting the status of SMS-CB, Frequency Hopping and Call Release due to Excessive Distance: ......................270 Creating the Target Cell Objects: ..........................................................................................................................272 Creating the Target Point-to-point Packet Flow Objects: ......................................................................................274 Creating the Adjacent Cell Objects:.......................................................................................................................276 Creating the Target Cell Objects for handover from GSM to UMTS (FDD): ..........................................................288 Creating the Adjacent Cell Objects for external UMTS FDD or UMTS TDD cells:.................................................289 Creating the CCS7 level 3 addresses of BSC, MSC and SMLC and basic SCCP parameters for the SS7 connection: ............................................................................................................................................................293 Setting the timer values for CCS7 MTP level 2: ....................................................................................................298 Setting the timer values for CCS7 MTP level 3: ....................................................................................................301 Creating the CCS7 link: .........................................................................................................................................304 Creating a Nailed-Up Connection through the BSC/TRAU:...................................................................................305 Creating an X25 connection via dedicated link:.....................................................................................................306 Creating an X25 connection via A-interface: .........................................................................................................308 Creating the O&M link for the RC connection:.......................................................................................................310 Creating the link for the external connection to the SMS-CB system: ...................................................................311 Defining the BSC reference synchronization clock origin:.....................................................................................311



Defining an external synchronization signal: .........................................................................................................311 Activating IMSI tracing in the BSC:........................................................................................................................311 Creating a Cell Traffic Recording (CTR) job: .........................................................................................................313 Defining the BSC environmental alarms:...............................................................................................................315 Configuring the feature Online RF Loopback: .......................................................................................................316 Creating Smart Carrier Allocation:.........................................................................................................................320

2 APPENDIX ...................................................................................................................................................................322

2.1 HANDOVER THRESHOLDS & ALGORITHMS..................................................................................................................322 2.1.1 Functional Diagram Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and power budget)........................................................................................................................................................322 2.1.2 Rules: Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and power budget), Power Control disabled ...........................................................................................................................323 2.1.2.1 Inter-cell Handover (level).....................................................................................................................323 2.1.2.1.1 Handover Decision / Handover Trigger Conditions.......................................................................323 2.1.2.1.2 Target Cell List Generation ..........................................................................................................324

2.1.2.2 Intra-cell handover (quality) .................................................................................................................326 2.1.2.3 Inter-cell handover (quality) .................................................................................................................328 2.1.2.3.1 Handover Decision / Handover Trigger Conditions......................................................................328 2.1.2.3.2 Target Cell List Generation ..........................................................................................................329

2.1.2.4 Inter-cell handover (distance) ..............................................................................................................330 2.1.2.4.1 Handover Decision / Handover Trigger Conditions......................................................................330 2.1.2.4.2 Target Cell List Generation ..........................................................................................................330

2.1.2.5 Inter-cell Handover (power budget) .....................................................................................................332 2.1.2.5.1 Handover Decision / Handover Trigger Conditions......................................................................332 2.1.2.5.2 Target Cell List Generation ..........................................................................................................334 2.1.2.5.1 Speed sensitive handover enabled ..............................................................................................335

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

2.1.2.7 Fast Uplink Handover ..........................................................................................................................337 2.1.2.7.1 Handover Decision / Handover Trigger Conditions......................................................................337 2.1.2.7.2 Target Cell List Generation ..........................................................................................................337

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

2.2 HIERARCHICAL CELL STRUCTURE .............................................................................................................................345 2.2.1 Cell ranking for power budget handovers (non-imperative handover).........................................................345 2.2.1.1 Speed sensitive handover enabled......................................................................................................346

2.2.2 Cell ranking for imperative handovers (due to level, quality and distance) and forced handover (directed retry) ......................................................................................................................................................................347 2.2.2.1 Ranking method 0................................................................................................................................347 2.2.2.2 Ranking method 1................................................................................................................................349

2.2.3 Target Cell Ranking for Traffic Handover with HCS ....................................................................................351 2.3 POWER CONTROL THRESHOLDS & ALGORITHMS ........................................................................................................352 2.3.1 Functional Diagram: Power Control Thresholds - Power Increase / Power Decrease (Classic Power Control)..............................................................................................................................................................................352 2.3.2 Rules: Power Control Thresholds: Power Increase / Power Decrease .......................................................353 2.3.2.1 Power Increase ....................................................................................................................................353 2.3.2.2 Power Decrease ..................................................................................................................................354

2.3.3 Classic and Adaptive Power Control ...........................................................................................................355 2.2.3.1 Introduction ...........................................................................................................................................355 2.3.3.2 Classic Power Control decision process..............................................................................................355 2.3.3.3 Adaptive Power Control decision process ...........................................................................................356 2.3.3.4 Differences between CLASSIC and ADAPTIVE power control decision .............................................356 2.3.3.4 Functional sequence of a BS and MS power control procedure..........................................................357 2.3.3.4.1 BS power control procedure ........................................................................................................357 2.3.3.4.2 MS power control procedure ........................................................................................................358

2.3.3.5 Comparison of timing behaviour of different Power Control types - MS Power Control, BS Power Control, classic and adaptive............................................................................................................................359 2.3.3.6 Further differences between CLASSIC and ADAPTIVE Power Control ..............................................359 2.3.3.7 Interaction of Power Control Measurement Preprocessing and Power Control Decision ...................360

2.4 INTERWORKING OF HANDOVER AND POWER CONTROL................................................................................................361 2.4.1 Functional Diagram: Inter-cell Handover and Intra-cell Handover, Power Increase and Power Decrease ..361 2.4.2 Rules ...........................................................................................................................................................362

2.5 SERVICE DEPENDENT HANDOVER AND POWER CONTROL ...........................................................................................363 2.5.1 Introduction..................................................................................................................................................363 2.5.2 SGxHOPAR and SGxPCPAR parameter values ..........................................................................................364 2.5.2.1 SGxHOPAR parameter values (Handover)...........................................................................................364 2.5.2.2 SGxPCPAR parameter values (Power Control)....................................................................................365 2.5.2.3 Effects on Call processing ....................................................................................................................366



2.6 MAPPING OF RXQUAL AND C/I VALUES FOR AMR CALLS ...........................................................................................367 2.7 AMR LINK ADAPTATION THRESHOLDS UPLINK ...........................................................................................................368 2.8 COMMON BCCH SOLUTION FOR MIXED FREQUENCY BANDS WITHIN THE COMPLETE AREA................................................372 2.9 BSC, MSC AND BTS OVERLOAD HANDLING .............................................................................................................374 2.9.1 BSC Overload..............................................................................................................................................374 2.9.1.1 BSC overload conditions ......................................................................................................................374 2.9.1.2 System reactions and overload regulation measures in case of BSC overload ..................................379 2.9.1.2 System reactions and overload regulation measures in case of BSC overload ..................................379 2.9.1.2.1 Further important notes on BSC reactions...................................................................................380

2.9.1.3 Mechanisms for reduction of originating traffic and reduction of terminating traffic.............................381 2.9.1.3.1 Overload level management ........................................................................................................381 2.9.1.3.2 Traffic reduction algorithms..........................................................................................................382 2.9.1.3.3 Special overload supervision algorithm in case of BSC paging queue overflow..........................383

2.9.2 MSC Overload .............................................................................................................................................383 2.9.2.1 System reactions and overload regulation measures in case of MSC overload...................................383 2.9.2.1.1 Special overload level escalation algorithm in case of MSC overload ..........................................383

2.9.3 BTS Overload ..............................................................................................................................................384 2.9.3.1 BTS overload conditions.......................................................................................................................384 2.9.3.2 Traffic reduction mechanisms in case of BTS overload.......................................................................386 2.9.3.3 System reactions and overload regulation measures in case of BTS overload...................................387

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

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



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

TRAU0

TRAU0

16 2 1 0

PCMS-0

OMAL

empty

CCS7 SW/FAW

0123

0123

TCH á 16 kbit/s

BSC

DTLP-1

port 1simpl. A

LPDLS-0

1 x PCM30

submult.

BSC

DTLP-0

port 0

simpl. A

16 2 1 0

PCMB-0

SW/FAW

123

LPDLM-0LPDLR-0-0

LPDLR-0-1

LPDLR-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-0

TRX-0-0TRX-0-1

TRX-0-2

TRX-0-3

BTSM-1

BTS-1

TRX-1-0TRX-1-1

LPDLM-1

LPDLR-1-0

LPDLR-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-1

QTLP-0



1.1.2 BR7.0 Object Tree of BSC database objects

Note: The objects BTSMOSUSW, TRAOSUSW, SCANCO, the scanner objects (“SCANxxxx”) as well as the objects 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 same order as they are generated by DBAEM when generating an ASCII database from a 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 so that all parameters subordinate to one object (e.g. BTS) are included in one and the same command (CREATE/SET BTS). The disadvantage is that among the huge number of parameters within one command it is hard to find a specific parameter quickly. I decided to use the following approach in this document: - For a better logical structure, the parameters are still grouped in the ‘pseudo-packages’ (e.g. CREATE BTS [BASICS], SET BTS [CCCH] etc.) used in the LMT GUI. - Within each package, an alphabetical order was used for the sequence of parameters (as done by DBAEM) to facilitate the handling and overview.



1.2 BSC Database Commands and Parameters

Setting the object entry point and time and date for the BSS:

< The MEL (Managed Element) object represents the entry point of the addressing of the BSS. It simultaneously represents the object with which the network element time and date can be set. >

SET MEL:

NAME=MEL:0, Object name.

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

object: MEL

format: hour –minute-second-

day-month-year

range: hour 0..23

minute 0..59

second 0..59

day 1..31

month 1..12

year 1992..2099

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

MELID=1;

object: MEL

range: 1..47

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

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

SET BSC [CONTROL]:

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

NAME=BSC:0, Object name.

CFS=3,

object: BSC [CONTROL]

unit: 1 Mbyte

range: 1-6

default: 1

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



IMSIFSIZ=30,


unit: 1 Mbyte

range: 0..30

default: 30

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

MASCLOGFS=3,


unit: 1 Mbyte

range: 1-6

default: 3

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

MEDAFUPE=UPPE_0H,


range: UPPE_0Hh= no per. upl.

UPPE_1h = Upl. period 1h






UPPE_12h= Upl. period 12h

UPPE_24h= Upl. period 24h

default: UPPE_0h

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

MEDAFUST=0-0;


range: upload start hour 0..23

upload start minute 0..59

default: upload start hour 0

upload start minute 0

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



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

SET BSC [TIMER]:

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

NAME=BSC:0, Object path name.

BSCT1=HLFSEC-12,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-12

Reference: GSM 08.08

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

BSCT10=HLFSEC-10,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-10

Reference: GSM 08.08 (04.08)

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

ASSIGNMENT COMPLETE message in case of call setup and intra-cell handover. This timer is started on the sending of an ASSIGNMENT COMMAND message and is normally stopped when the MS has correctly seized the new channels.

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

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



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 allowed queuing time. 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 the BSC receives an ASSIGNMENT REQUEST message from the MSC) is put into a queue due to TCH congestion, T11 determines the maximum time the TCH request may remain in the queue to wait for a busy TCH to become idle. If the TCH request for assignment procedure cannot be served within this time frame and T11 expires, the BSC sends a CLEAR REQUEST to the MSC and the context is released.

Notes: - Queuing a TCH request means a considerable extension of the SDCCH seizure duration! - It is important to consider that the feature 'Queuing' stresses the patience of the subscribers as it extends the time a subscriber has to wait (possibly in vain) for the assignment of a TCH in a busy cell. Therefore it has to be carefully considered which waiting time can be regarded as acceptable from the subscriber's point of view. In other words: it makes no sense to set T11 to a too high value. - It is possible to accelerate the release of busy TCHs by an appropriate setting of the timer T3111 (see SET BTS [TIMER]). This can decrease the queuing time considerably. - If the BSC receives an INTERCELL HANDOVER CONDITION INDICATION from the BTS during the queuing time, the BSC directly searches for an idle TCH in the target cell! In other words, during the queuing time no SDCCH-SDCCH handover will ever be performed. If no TCH can be found in the target cells, the TCH request is discarded from the queue.

BSCT13=HLFSEC-50,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-50


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

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



BSCT17=HLFSEC-20,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-20

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

For further details about the exact function of the timer BSCT18 within

the BSS overload regulation please refer to the section “BSC, BTS and MSC overload Handling” in the appendix of this document. As MSC, BSC and BTS overload handling are closely interwoven, the overload conditions and traffic reduction mechanisms are explained in an own chapter that comprises all possible scenarios of overload and overload handling as well as the references to the relevant parameters.

BSCT18=HLFSEC-60,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-60


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

For further details about the exact function of the timer BSCT18 within

the BSS overload regulation please refer to the section “BSC, BTS and MSC overload Handling” in the appendix of this document. As MSC, BSC and BTS overload handling are closely interwoven, the overload conditions and traffic reduction mechanisms are explained in an own chapter that comprises all possible scenarios of overload and overload handling as well as the references to the relevant parameters.

BSCT19=HLFSEC-12,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-12


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

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



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

BSCT3121=HLFSEC-50,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-10

Reference:

BSC timer T3121, this parameter represents a timer which is used to supervise the 2G-3G handover procedure towards an UTRAN-FDD cell. T3121 is the 2G-3G handover equivalent to the timer T8 (see parameter BSCT8). In this case the BSC has sent a BSSMAP HANDOVER REQUIRED with a UMTS 3G neighbour cell (see command CREATE ADJC3G) in the target cell list to the 3G MSC. When the target RNC has provided the target channel data and and the 3G-MSC has sent the associated HANDOVER COMMAND to the BSC, the BSC forwards this HANDOVER COMMAND to the multiRAT MS and simultaneously starts the timer T3121. The MS, on receipt of the HO CMD, switches over to the target channel in the UMTS 3G neighbour cell and, in case of successful link setup, sends the RRC HANDOVER COMPLETE towards the target RNC which in turn sends an Iu RELOCATION COMPLETE message to the 3G MSC. The timer T3121 is stopped, when the BSC has received the CLEAR COMMAND with cause ‘handover successful’. When it expires, the BSC sends a CLEAR REQUEST with cause ‘radio interface message failure’ to the 3G-MSC to indicate the drop of the connection during the handover procedure. This event is counted as a call drop by the PM counters NRFLTCH (subcounter 9) and NRCLRREQ (subcounter cause: radio interface message failure) and will thus appear as a call drop event in the PM 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 the HANDOVER REQUIRED is sent and it is stopped, when the CLEAR COMMAND with cause ‘handover successful’ is received.

BSCT4=HLFSEC-60,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-60


BSC timer T4, this BSSMAP timer determines the time to return a BSSMAP RESET ACKNOWLEDGE message. The BSC sends the BSSMAP message RESET to the MSC in the event of a failure which leads to the loss of transaction reference information. The purpose of the RESET message is to initialize the BSSMAP relation between MSc and BSC and to put all affected circuits into the idle state. When the MSC has received the RESET message form the BSC it releases all affected connections and initializes the associated traffic channels. After the a guard period of T2 (MSC timer) the MSC responds with a RESET ACKNOWLEDGE message. The timer T4 is started when the BSC transmits the RESET message to the MSC and watches over the receipt of a RESET ACKNOWLEDGE from the MSC. If no RESET ACKNOWLEDGE has been received before expiry of T4, the BSC retransmits the RESET message and starts T4 again.

Rule: BSCT4 (BSC) > T2 (MSC) The value of T4 must be higher than the value of the MSC timer T2 plus the transmission time of the RESET and the RESET ACKNOWLEDGE messages (It is recommended to set the MSC-timer T2 to ca. 10s). Note: The RESET procedure can also be initiated by the MSC. In this case equivalent timers are used: The MSC timer T16 supervises the receipt of the RESET ACKNOWLEDGE message (equivalent to the



BSC timer T4) and the guard period in the BSC for the transmission of the RESET ACKNOWLEDGE is the timer T13 (see BSCT13).

BSCT7=HLFSEC-8,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-4


GSM 05.08

BSC timer T7, this timer determines the waiting time for a HANDOVER COMMAND from the MSC after transmission of a HONDOVER REQUIRED to the MSC. If the BTSE has sent a HANDOVER CONDITION INDICATION message and the handover is to be executed by the MSC (if the first target cell is an external one or if LOTERCH or LOTRACH (see SET HAND [BASICS]) are set to FALSE) or if the MSC has initiated a HANDOVER CANDIDATE ENQUIRY procedure, the BSS sends a HANDOVER REQUIRED message to the MSC and starts T7. As long as T7 runs the BSC call processing code remains in a state 'waiting for HO CMD'. During this time the BSC ignores all new HO COND IND messages received from the BTS and no further HO RQDs are sent. If T7 expires (i.e. no HO CMD was received from the MSC), the BSC call processing terminates the 'waiting for HO CMD' state and the receipt of new HO COND IND message directly leads to the transmission of an updated HO RQD. All HO CMDs received after expiry of T7 are discarded by the BSC.

Notes: 1) Attention: Especially in case of Inter-MSC handovers or if the features “queuing” or/and ”preemption” are used for incoming MSC controlled handovers, the handover completion may take a long time due to the additional handover of the preempted call in the target cell. This has to be considered by setting BSCT7 to a sufficiently high value in the originating BSC. If BSCT7 is too short, the HO CMD might be received after T7 expiry. This leads to the discarding of the HO CMD and thus to a forced release of the call by the MSC as the MSC supervises the by an own timer (Trr7 in Siemens MSC) which is started when the HO CMD is transmitted and which waits for the ‘handover successful’ indication from the target side or a HANDOVER FAILURE (DTAP) from the originating side. As the experience has shown, during inter-MSC handover procedures it may take more than 2s until the HANDOVER COMMAND is received from the MSC (in case of inter-PLMN handover it may be even more), it is recommended to apply at least the setting

BSCT7 ≥≥≥≥ HLFSEC-6

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

THORQST (HAND) > BSCT7 (BSC)

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



BSCT8=HLFSEC-10,

object: BSC [TIMER]

unit: HLFSEC=0,5s

SEC5=5s

range: 0..254

default: HLFSEC-10


BSC timer T8, this timer determines the time to receive the HANDOVER COMPLETE message. T8 is defined as the time that BSC layer 3 will wait for a handover to complete before releasing the source channel.

The value must be bigger than the sum of the time for all messages to be sent to the MS plus the time to access a target and come back (if necessary). Note: Due to the SBS implementation T8 replaces the function of T3103 (see SET BTS [TIMER]). Rule: BSCT8 < TTRAU (for TTRAU see command SET BTS [TIMER]) This setting is necessary to ensure that a signaling failure (T8 and T10) 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 allowed queuing time for incoming handover. This parameter is only relevant if the feature ‘queuing’ is enabled (see parameter EQ in command SET BTS [OPTIONS]). When a TCH request for an incoming MSC-controlled handover (i.e. when the BSC receives a HANDOVER REQUEST message from the MSC) is put into a queue due to TCH congestion, TQHO determines the maximum time the TCH request may remain in the queue to wait for a busy TCH to become idle. If the TCH request for the incoming handover cannot be served within this time frame and TQHO expires in case of incoming MSC-controlled HO, the TCH request is rejected with a HANDOVER FAILURE. As a result, if there is another target cell available for the handover procedure, the MSC will attempt another HO REQUEST procedure towards the next target BTS.#

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

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

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



Setting the global parameters of the BSC:

SET BSC [BASICS] :

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


ACCEPTGDEGR=PER0;

object: BSC [BASICS]

range: PER0, PER10, PER20,

PER30 ... PER90

default: PER0

Acceptable GPRS degradation, this parameter defines, in percentage (steps of 10 %, from 0% to 90%), the acceptable degradation of packet service throughput (maximum sustainable throughput), before an upgrading of radio resources (i.e. TCH resources on the Um) is attempted.

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

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

where: T_A_CS = throughput of the Actual Coding Scheme

BLER = actual BLER #TS = number of allocated timeslots to the TBF

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

An extension to the number of allocated TSs is tried if:

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

where: T_A_CS = throughput of the Actual Coding Scheme BLER = actual BLER

PT = peak throughput #TS = number of allocated timeslots to the TBF

This means that, when the MST becomes lower than the maximum tolerable degradation of the peak throughput, the upgrading of radio resources is attempted. The upgrade is performed by adding one adjacent timeslot timeslot to the currently used ones (i.e. the PCU will send a PDCH_Upgrade_Request message to the TPDC), provided that the conditions regarding horizontal allocation and the percentage of idle timeslots are verified (see parameter GASTRTH in command CREATE PTPPKF).

Note: As long as the ‘one radio resource a time’ algorithm is implemented it is suggested to set the ACCEPTGDEGR attribute to ‘0’ (no degradation allowed, radio resource upgrading always attempted as soon as the upgrading condition is detected), in order to reach the required radio resource allocation in several steps.



AISAT=FALSE,


range: TRUE, FALSE

default: FALSE

A interface via satellite, this attribute indicates whether the A interface resp. SS7 link is realized via satellite link (TRUE) or not (FALSE). If the A interface link is configured as satellite link, the generally higher signal delay must be particularly considered by a) the higher layers on the CCS7 link (e.g. BSSAP) and b) the CCS7 layer 2 functions.

Setting AISAT=TRUE has the following consequences: a) BSSAP timers (e.g. BSCT7, BSCT8 etc., see SET BSC [BASICS]) have to be carefully checked as the delay on the lower layers slows down all signaling transactions. It might be necessary to extend selected timers to higher values to avoid undesired effects. b) If the A interface is realized via satellite link the CCS7 error correction method must be set to 'preventive cyclic retransmission error correction' (see CREATE SS7L, parameter ERRCORMTD).

Note: Also the Asub interface (parameter ASUBISAT, see below) and the Abis interface (see parameter LPDLMSAT in command CREATE/SET BTSM) can be configured as satellite link. However, only one of the mentioned interfaces should be configured as satellite link at the same time, because multiple satellite links within a BSS may cause an overall message and procedure delay that might lead to expiry of procedure supervision timers that are normally adapted to the propagation delay of terrestrial signalling links or at least to only one satellite link in the path. Although multiple satellite links are not officially tested and released, the BSC command interpreter and DBAEM do not perform any checks to avoid multiple satellite links - it is up to the operator to follow this rule.

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


range: ENABLED(1..100),

DISABLED

default: ENABLE(30) (minor)

ENABLE(60) (major)

ENABLE(90) (critical)

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

ASCIONECHMDL=FALSE,


range: TRUE, FALSE

default: FALSE

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

When a VGCS voice group call is set up (one dispatcher and several other called service subscribers in the group call area), for the called service subscribers basically only one downlink channel (ASCI common TCH) is provided, i.e. they can only listen to the dispatcher. However, a service subscriber has the possibility to request an uplink channel to transmit speech to the other group call partners by pressing the PTT (push to talk) button on the ASCI phone. In this situation, when ASCIONECHMDL is set to FALSE (1,5 channel mode), the following happens: when the service subscriber requests an uplink TCH by pressing the PTT button in order to transmit speech, the BSC assigns a completely new TCH to the subscriber in addition to the alredy existing downlink TCH - thus the service subscriber occupies ‘one and a half’ TCHs (therefore called “1,5 channel mode”).

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



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



DISABLED


ENABLE(60) (major)


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

ASUBENCAP=FALSE,


range: TRUE, FALSE

default: FALSE

Asub enhanced capacity allowed, this attribute indicates whether the creation of PCMS objects in single trunk mode is allowed. Single trunk mode (ASUBENCAP=TRUE) means that all physical ports (A and 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 satellite, this attribute indicates whether the Asub resp. LPDLS is realized via satellite link (TRUE) or not (FALSE). If the Asub interface link is configured as satellite link, the generally higher signal delay must be particularly taken into account by the LAPD layer 2 functions of the TRAU O&M link (LPDLS) and b) the higher layers on the CCS7 link (e.g. BSSAP) and c) the CCS7 layer 2 functions.

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

The extension of T200 ensures that the higher signal delay on the link does not lead to unnecessary retransmission of LAPD layer 2 frames, while the extension of the window size avoids further delays due 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 slows down all signaling transactions. It might be necessary to extend selected timers to higher values to avoid undesired effects. c) If the Asub interface is realized via satellite link the CCS7 error correction method must be set to 'preventive cyclic retransmission error correction' (see CREATE SS7L, parameter ERRCORMTD).

Notes: - The satellite mode of the Asub link has to be activated in the TRAU as well. This is done by the parameter ASUBLPDLSAT in the command 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 Abis interface (see parameter LPDLMSAT in command CREATE/SET BTSM) can be configured as satellite link. However, only one of the mentioned interfaces should be configured as satellite link at the same time, because multiple satellite links within a BSS may cause an overall message and procedure delay that might lead to expiry of procedure supervision timers that are normally adapted to the propagation delay of terrestrial signalling links or at least to only one satellite link in the path. Although multiple satellite links are not officially tested and released, the BSC command interpreter and



DBAEM do not perform any checks to avoid multiple satellite links - it is up to the operator to follow this rule.

BSCOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

BSC overload handling, determines whether BSC overload handling is enabled or not. For further details about the BSC overload regulation please refer to the section “BSC, BTS and MSC overload Handling” in the appendix of this document. As MSC, BSC and BTS overload handling are closely interwoven, the overload conditions and traffic reduction mechanisms are explained in an own chapter that comprises all possible scenarios of overload and overload handling as well as the references to the relevant parameters.

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 overload handling, determines whether BTS overload handling is enabled or not. For further details about the BTS overload regulation please refer to the section “BSC, BTS and MSC overload Handling” in the appendix of this document. As MSC, BSC and BTS overload handling are closely interwoven, the overload conditions and traffic reduction mechanisms are explained in an own chapter that comprises all possible scenarios of overload and overload handling as well as the references to the relevant parameters.

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

CBCPH = PH1_CBC,


range: PH1_CBC, PH2_CBC

default: PH1_CBC

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

From the BSC side, the old CBC interface (without Channel_Indicator parameter) is still supported. In this sense the RC/LMT operator can set the database flag CBCPH to PH1_CBC to indicate that the connected CBC uses the old interface (< BR6.0), or to PH2_CBC to indicate that the connected CBC supports the new Channel Indicator parameter value.

Note: The support of the ‘Channel Indicator’ has been implemented only at CBC-BSC interface level, this means that on the A-bis interface the EXTENDED channel is not implemented, as no mobile supports this feature at the moment. So the customer can choose a CBC centre implementing the new interface (including the channel_indicator parameter and setting theCBC phase = 2), but only the BASIC channel can be specified in the channel_indicator field from the CBC operator.

CICFM=GSM,


range: GSM, NOTSTRUCT

default: GSM

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

CITASUP=FALSE,


range: TRUE, FALSE

default: FALSE

Cell ID and Timing Advance Support, this parameter is relevant for the feature ‚Location Based Services’ and represents the flag to enable the transmission of the Timing Advance (TA) in the COMPLETE LAYER3 INFO (which the BSC sends to the MSC during any 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

Call policy, 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 BSC shall allocate incoming data calls (GPRS and CS/HSCSD) on the BCCH TRX first. SPEECH_CALL_ON_BCCH indicates that the BSC shall allocate incoming speech calls on the BCCH TRX first. The Call Policy is not only considered during call setup, but also features a ‘forced intracell handover due to preferred TRX’. This means that, if the call could not be set up on a preferred TRX as all TCHs were busy, the call is moved to the preferred TRX by a forced intracell handover as soon as the preferred TRX resources become idle again.

Notes: - The forced intracell handover due to preferred TRX is only performed for speech calls and for single slot data calls (data rate 2,4 kbit/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 TCH allocation for GPRS calls: 1. Maximum number of adjacent timeslots based on PCU estimation 2. Maximum re-use 3. Minimum number of forced handovers for CS calls 4. TRX preference defined by CPOLICY - In BR7.0 the priorization of a) satisfaction of requested CS data rates (for HSCSD calls) and b) the call policy was changed (due to CR1150). In BR6.0 the BSC always allocated a TCH on the preferred TRX, even if the data rate requirement could not be satisfied on the preferred TRX but could have been satisfied on a non-preferred TRX, in BR7.0 the ‘preferred TRX’ setting just determines on which TRX the BSC searches for the requested TCH resources first. Incoming CS requests (singleslot and multislot) are satisfied searching for the requested resources first on the preferred TRXs and then on the not-preferred TRXs. This means that the downgrade of incoming HSCSD multislot calls to 1 timeslot is done only when the requested data rate requirement cannot be satisfied on any 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 timer TEMPCH (see command CREATE PCU) is running due to the fact that there is no TBF on it) is attempted (no matter how the DGRSTRGY is set), otherwise the normal downgrade procedure for active 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 support, this parameter allows to enable or disable the feature GPRS Coding Scheme 3 and Coding Scheme 4 generally in the BSC. The same parameter is also available in the PTPPKF object where it can be used to enable/disable CS3/CS4 individually per BTS (see parameter CSCH3CSCH4SUP in command CREATE PTPPKF).

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

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

GPRS Coding scheme maximum gross data rate

CS-1 9,05 kbit/s

CS-2 13.4 kbit/s

CS-3 15.6 kbit/s

CS-4 21.4 kbit/s

Similar to the AMR speech coding, where - depending on the current radio conditions - a better speech quality is achieved by providing the smallest possible channel coding portion and the biggest possible speech coding portion, the higher data throughput of CS-3 and CS-4 is achieved by a smaller channel coding portion within the radio TCH. The basic principle is: the better the radio interface quality (defined by C/I - Carrier/Interference), the higher the available bandwidth (bitrate) for the user data coding and the smaller the bandwidth (bitrate) for channel coding and vice versa (‘Channel Coding’ is the term that represents the radio transmission error protection overhead, while ‘Data Coding’ represents the coding of the user data to be transmitted).

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

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

GPRS coding scheme Radio Block Size in Bits for DL/UL

No. of Concatenated PCU Frames

CS-1 181 1 (max. 216 payload bits)




Consequently, the GPRS coding scheme link adaptation, which can also be regarded as ‘coding scheme upgrade’ and ‘coding scheme downgrade’ also might cause the seizure (for coding scheme upgrade) or/and release (for coding scheme downgrade) of an additional Abis TCH.

Channel Coding Data Coding good radio conditions

Channel Coding Data Coding poor radio conditions



DGRSTRGY= NO_DOWNGRADE,

object: BSC [BASICS] range: HSCSD_FIRST_DOWNGRADE

GPRS_FIRST_DOWNGRADE

DOWNGRADE_HSCSD_ONLY

DOWNGRADE_GPRS_ONLY

NO_DOWNGRADE

default: NO_DOWNGRADE

Downgrade strategy, this parameter defines the downgrade strategy for HSCSD and GPRS calls used during the resource reallocation procedure for TCH requests for single-channel circuit switched 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 much the 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-channel circuit-switched call received when all TCH resources in the cell are busy. 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 HANDOVER REQUEST) c) an incoming intra-BSC handover (receipt of an INTERCELL HANDOVER CONDITION INDICATION) d) an intracell handover (receipt of an INTRACELL HANDOVER CONDITION INDICATION)

In any of the mentioned cases the downgrade procedure is started to provide TCH resources to the incoming TCH request in accordance with the value set for DGRSTRGY. Attention: If in case c) the INTERCELL HANDOVER CONDITION INDICATION contains more than one target cell, the BSC first analyzes the TCH resources in the first target cell. If no idle TCH can be found and if the TCH congestion is partly caused by multislot calls, the BSC first checks the other target cells for available TCH resources. Only if in none of the target cells a TCH can be found for allocation, the BSC starts the downgrade in the first target cell where this is possible.

The parameter values have the following meaning: 1) HSCSD_FIRST_DOWNGRADE means that all HSCSD calls are downgraded first before a GPRS call is downgraded. 2) GPRS_FIRST_DOWNGRADE means that all GPRS calls are downgraded 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 are downgraded while HSCSD calls remain unaffected. 5) NO_DOWNGRADE means that both GPRS and HSCSD calls remain unaffected.

Notes: - If a CS call request is received in a congested cell, the BSC tries to satisfy the TCH request in the following sequence: 1) preemption of a low priority CS call, if not possible then 2) directed retry, if not possible then 3) downgrade

- For GPRS the downgrade is only possible for those TCHs that can be dynamically shared between CS and GPRS traffic. For these channels, 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 load dependent features such as Traffic Handover (see parameter TRFHOE in command SET HAND[BASICS]), Cell Load Dependent Activation of Half Rate (see parameter EHRACT in command CREATE BTS [BASICS]), Enhanced Pairing (see parameter EPA in command 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 is currently seized by a CS call. b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e. DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currently busy due to GPRS traffic (PDCH) are considered as ‘idle’. However, if a TCH was activated as PDCH for GPRS traffic but the TEMPCH timer (see parameter TEMPCH in command CREATE PCU) is running for it, (which means that there is no ongoing TBF on the TCH), the TCH is always regarded as ‘downgradable’ resp. ‘preemptable’ for CS calls, no matter which value was set for the DGRSTRGY parameter. In other words, in periods of TCH congestion the BSC immediately releases PDCHs (TCHs activated for GPRS) with TEMPCH running if a CS TCH request is received and no other idle TCH is available for allocation. This change was implemented in BR7.0 in the scope of CR1150.

DLAPDOVL=TRUE,


range: TRUE, FALSE

default: TRUE

Downlink LAPD Overload, this parameter allows to enable or disable the procedure that detects the downlink LAPD overload. If the BTSE has detected an overload situation on the LAPD link based on the LAPD load thresholds SLAPDOVLTH (see command CREATE BTSM), it sends the O&M message LAPD OVERLOAD towards the BSC. If DLAPDOVL=TRUE, the BSC starts traffic reduction measures as described in the section ‘BTS overload’ in the chapter ‘BSC, MSC and BTS Overload handling’ in the appendix of this document.

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

EFRSUPP=FALSE,


range: TRUE, FALSE

default: FALSE

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



EHRACTAMR=FALSE,


range: TRUE, FALSE

default: FALSE

Enable cell load dependent activation of half rate for AMR calls, this parameter is the AMR equivalent to the parameter EHRACT (see command CREATE BTS [BASICS]) and allows to enable or disable the feature ‘Cell load dependent activation of half rate’ for AMR calls for all BTSs belonging to the BSC. This feature controls the allocation of AMR HR TCHs in such a way that AMR half rate TCHs are only assigned if the percentage of busy radio TCHs in the BTS or/and the percentage of busy Abis TCHs in the BTSM Abis channel pool have exceeded a configurable threshold.

For cell load dependent activation HR the radio TCH traffic load threshold is defined by the parameters HRACTAMRT1 and HRACTAMRT2 (see command CREATE BTS BASICS]).

For Abis load dependent activation HR the radio TCH traffic load threshold is defined by the parameter ABISHRACTTHR (see CREATE BTSM).

For further details about the feature functionality and the exact calculation of the traffic load please refer to the parameters EHRACT, HRACTAMRT1 and HRACTT1 (see CREATE BTS [BASICS]) and ABISHRACTTHR (see CREATE BTSM), as the basic concept and the traffic load calculation algorithm are exactly the same for 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 CREATE BTS [BASICS]).

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

EISDCCHHO=ENABLE,


range: ENABLE, DISABLE

default: ENABLE

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

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

ENCALSUP=NOENCR& GSMV1&GSMV2,


default: encalg1=NOENCR

encalg2=GSMV1

encalg3..10=NOCONFIG

Supported encryption algorithms, this parameter determines the algorithms 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-cell HO, this parameter enables the “ Forced Intracell Handover due to multislot calls ” procedure. EFOIAHO should be set to TRUE, if either GPRS or HSCSD is used in the BSC.

If there are not enough adjacent radio TCHs available when a request for multislot call (HSCSD or GPRS) is received a forced intracell handover is performed which reorders the current timeslot seizure in such a way that a sufficient number of adjacent timeslots is available to satisfy the multislot call request to the best possible extent. 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 in the handover initiation, i.e. no HANDOVER CONDITION INDICATION is sent from BTS to BSC.

ENFORCHO=ENABLE,


range: ENABLE, DISABLE

default: ENABLE

Forced handover enabled, this parameter determines whether the BSC may send a FORCED HANDOVER REQUEST message for running SDCCH connections to the BTS. This message is used for either for ‘Directed Retry’ or for the procedure ‘Forced handover due to Preemption’ (see parameter EPRE in command SET BTS [OPTIONS]). A ‘Directed Retry’ procedure is performed if a MS attempts a MOC in a cell in which no idle TCH is available, e.g. due to congestion. A successful ‘Directed Retry’ results in the assignment of a TCH in the best adjacent cell. During this procedure the BSC, having received the ASSREQ from the MSC, sends the ‘forced handover request’ message to the BTS, which in turn sends HANDOVER CONDITION INDICATION messages with the cause ‘forced’. The HCI messages contain a list of target cells that the BTS has determined by evaluating the measurement reports sent uplink by the MS during the SDCCH phase. (-> see also command CREATE ADJC., parameters FHORLMO and TIMERFHO and section 2.1.2.6). In case of ‘Forced handover due to Preemption’, the BSC sends the FORCED 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 the target cell ranking is exactly the same like for a directed retry – in both cases the forced handover offset (FHORLMO) is applied. However, the resulting signalling transaction rather corresponds to that of a normal handover procedure (with the appropriate cause values) than that of a directed retry.

Notes: - Setting this parameter to ‘enable’ only activates the Directed Retry controlled by the BSC, i.e. directed retry to target cells belonging to the same BSC. If Inter-BSC Directed Retry shall be enabled the flag EISDCCHHO (see above) has to be set to 'enable' in addition. - The setting ENFORCHO=FALSE does not only prevent BSC-internal and outgoing Inter-BSC directed retries, it also prevents incoming Inter-BSC directed retries and incoming handovers due to preemption: When the BSC receives a HANDOVER REQUEST message with the cause values ‘directed retry’ or ‘preemption’, it rejects the attempt by sending HANDOVER FAILURE with cause ‘Protocol error between BSS and MSC’. - In hierarchical cell structures the ranking of the target cells in the HCI sent as a result of the ‘forced handover request’ is performed according to the setting of the parameter HIERF (see SET HAND). - If the feature ‘Preemption’ is enabled, the forced handoverm due to preemption is only attempted, if ENFORCHO is set to ENABLE. If this is not the case the preempted call is immediately released ! - If an MS tries to set up an HSCSD call in a cell where HSCSD is disabled, the BSC also starts a directed retry procedure to satisfy - if possible - the MS’s multichannel requirement in a neighbour cell. For further details pleas refer to the parameter BTSHSCSD (see command SET BTS [BASICS]).



- Directed retry also works if direct TCH assignment (see parameter DIRTCHASS in command SET BTS [OPTIONS]) 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.

Note for Forced handover due to O&M: Forced handover due to O&M (initiated by the SHUTDOWN command is completely independent of any database flag.

ENHSCSD=FALSE,


range: TRUE, FALSE

default: FALSE

Enable HSCSD, this parameter specifies whether the feature ‘High Speed Circuit Switched Data (HSCSD)’ is enabled for the BSC or not. Notes: 1) This parameter enables HSCSD for the BSC base only. To activate it, however, it must be explicitly enabled for each BTS (see CREATE BTS [BASICS]: BTSHSCSD). 2) As a mandatory precondition for HSCSD the features ‘early classmark sending’ (see SET BTS [OPTIONS]:EARCLM) and ‘pooling’ (see parameter ENPOOL) must be enabled!

Principle: HSCSD is a feature which allows the ‘bunching’ of up to 4 consecutive radio timeslots for data connections of up to 38,4 (= 4 x 9,6) kbit/s (multislot connections). The data rate depends on the bearer capability requested by the MS and the negotiation result between MS and MSC. Each HSCSD connection consists of 1

main TCH which carries the main signalling (both FACCH and SACCH) and further 1..3 secondary TCHs. All radio timeslots used for one connection are FR timeslots located on the same TRX and use the same frequency hopping mode and the same TSC. Connection modes: There are 2 types of multislot connections: symmetric and asymmetric ones. In symmetric mode all secondary TCHs are bi-directional (UL and DL) and in asymmetric mode the secondary channels are only uni-directional (DL) TCHs or can be a mix 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). The downlink based asymmetry allows the use of a receive rate higher than the transmission rate and is thus very typical for Internet applications. The asymmetric mode is only possible for non-transparent data connections. Resource allocation: The BSC is responsible for the flexible air resource allocation. It may alter the number of TCH/F as well as the channel codings used for the connection. Reasons for the change of the resource allocation may be either the lack of radio resources, handover and/or the maintenance of the service quality. The change of the air resource allocation is done by the BSC using ‘service level upgrading and downgrading' procedures. For transparent HSCSD connections the BSC is not allowed to change the user data rate, but it may alter the number of TCHs used by the connection (in this case the data rate per TCH changes). For non-transparent calls the BSC is also allowed to downgrade the user rate to a lower value. Handover: In symmetric mode individual signal level and quality reporting for each used channel is applied. For an asymmetric HSCSD configuration individual signal level and quality reporting is used for the main TCH. The quality measurements reported on the main channel are based on the worst quality measured on the main and the unidirectional downlink timeslots used. In both symmetric and asymmetric HSCSD configuration the neighbour cell measurements are reported on each uplink channel used. All TCHs used in an HSCSD connection are handed over simultaneously. The BSC may alter the number of timeslots used for the connection and the channel codings when handing the connection over to the new channels. All kinds of inter-cell handovers are supported, intracell handover is possible only with cause 'complete to inner' or 'inner to complete'.



EPA=FALSE,


range: TRUE, FALSE

default: FALSE

Enable enhanced pairing of HR calls, this parameter enables the feature ‘enhanced pairing of TCH/H’. “Enhanced Pairing” implies automatically triggered forced intracell handovers that fill up dual rate TCHs, that carry only one HR call, with another HR call. In other words: the feature transfers HR calls that currently occupy one HR subslot of a DR TCH (while the other subslot is still idle) in such a way that as many HR calls as possible share one Dual Rate TCH with another HR call. A DR TCH can assume the following usage states: - a DR TCH is in usage state “idle” if none of the subslots is seized by a call, - the DR TCH is in usage state “active” if one of the two subslots (0 or 1) is occupied by a HR call, - the DR TCH is in usage state “busy” if both subslots are seized either by two HR calls or one FR call. The enhanced pairing intracell handover is controlled exclusively by the BSC and triggered by two different conditions:

a) Enhanced pairing due to Um radio TCH load is triggered if the percentage of dual rate TCHs or full rate TCHs in the BTS in usage state “idle” has dropped below a definable threshold. This threshold is based on the parameters EPAT1 and EPAT2 (see command CREATE BTS [BASICS]). Enhanced pairing intracell handovers are triggered if the following traffic load condition is fulfilled (for further details about the meaning of single terms of this formula, please refer to the description of parameter EPAT1).

b) Enhanced pairing due to BTSM Abis TCH load is triggered if the percentage of dual rate TCHs or full rate TCHs in a BTSM Abis pool with usage state “idle” has dropped below a definable threshold. This threshold is based on the parameter ABISHRACTTHR (see command CREATE BTSM). Enhanced pairing intracell handovers are triggered if the following traffic load condition is fulfilled (for further details about the meaning of single terms of this formula, please refer to the description of parameter ABISHRATTHR).

When the BSC detects TCHs in usage state “active” while at least one of the aforementioned condition is fulfilled, enhanced pairing intracell handovers are automatically performed by the BSC by simply activating the appropriate TCHs and by sending an ASSIGNMENT COMMAND with the new HR TCH data to the MS. As long 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 a cyclic process which is determined by the “Resource Allocation Timer“ (RR timer) which is fixed to 400ms: every 400 ms the BSC checks if the TCH load condition for enhanced pairing is fulfilled and if there are some ongoing HR calls to be paired. This means that, if the TCH load condition is fulfilled, it takes at the maximum 400ms until the unpaired HR calls are rearranged by enhanced pairing intracell handover.

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

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

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

no. of configured radio TCH EPAT1[%]



EPOOL=TRUE,


range: TRUE, FALSE

default: FALSE

Parameter name and value format

changed in BR7.0 (name changed from

ENPOOL to EPOOL, ‘initial pooling

type’ was removed)!

Enable pooling, this parameter indicates whether the ‘TSLA pooling’ feature is activated on the BSC side (‘enabling flag’). ‘TSLA pooling’ must be activated if HSCSD (see parameter ENHSCSD) is used on this BSC. If the pooling feature is enabled the available A-interface timeslots are classified by a ‘pooling type’. The different values for the pooling type are predefined by GSM and represent a certain combination of different ‘supported coding types’ for speech and data (see table at command CREATE PCMA and SET TSLA). Thus the BSC can separately manage the available resources e.g. for ordinary speech calls and for high speed data connections.

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-interface timeslot! Thus the previously rigid mapping pattern of A- and Asub-timeslots (represented by the parameter TRANMTX which was valid up to BR4.0) is now replaced by a semipermanent mapping pattern, which depends on the number and type of pools configured. Only the basic mapping principle can be selected initially (see command CREATE TRAU, parameter ALLCRIT).

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

EPREHSCSD=DISABLED,


range: ENABLED, DISABLED

default: DISABLED

Enable preemption for HSCSD requests, this attribute is only relevant if HSCSD is enabled (ENHSCSD=TRUE). If it is set to TRUE, HSCSD calls may preempt other calls. HSCSD calls themselves can never be preempted.

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


range: CRITICAL

MAJOR

MINOR

WARNING

NOFILTER

FERMAINT

default: NOFILTER

Error reactions, this parameter determines the output filters for different alarm event types. The five entered subattributes represent alarm messages in the alarm event types Communication-QualityOfService-Processing-Equipment-Environment. When ERRACT is set to one alarm priority for a specific alarm event type all alarms of lower and equal priority are ignored for this event type. Notes: - Attention: the filter setting defined by ERRACT is not only relevant for spontaneous alarm output but also for the alarm output as reaction to the command GET ACTIVEALARMS BSC! - The value FERMAINT can be used only for Processing Failure Events. Setting the PROC field to FERMAINT enables the output of certain call processing alarm messages which are normally suppressed (e.g. AP ERROR INDICATION, MESSAGE OUT OF SEQUENCE etc.) in order to allow a closer look on the grade of service in the cell for maintenance purposes. Thus FERMAINT works as a 'negative' filter.

ESUP=FALSE,


range: TRUE, FALSE

default: FALSE

EDGE support, this parameter enables or disable the feature EDGE in the BSC. Setting this parameter is a precondition before EDGE services can finally be enabled on cell level (EEDGE in object PTPPKF).



EUSDCHO=FALSE,


range: TRUE, FALSE,

<NULL>

default: FALSE

Enable UMTS SDCCH handover, this parameter is only relevant if the parameter EUHO (see command SET HAND [BASICS]) is set to TRUE and enables or disables the handovers of calls that are currently on an SDCCH towards external UMTS FDD or TDD neighbour cells in the BSC. With some restrictions, EUSDCHO is a kind 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 INTERCELL HANDOVER CONDITION INDICATION message that contains an UMTS FDD target cell (see commands CREATE TGTFDD and CREATE ADJC3G) or an UMTS TDD target cell (command CREATE TGTTDD) was received from the BTS for an activated SDCCH.

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

Setting EUSDCCHHO to FALSE has the following results: a) the BSC is prevented from sending HANDOVER REQUIRED messages with UMTS 3G target cells for ongoing SDCCH connections to the MSC and b) the BSC drops all UMTS FDD target cells if the original INTERCELL HANDOVER CONDITION INDICATION received from the BSC contained both GSM and UMTS 3G target cells.

HOSYNC=NOSYNC,


range: NONSYNC, SYNC

default: NONSYNC


GSM 05.10

Handover synchronicity, this parameter specifies whether the handover is ‘synchronized’ or ‘non-synchronized’. Synchronized handover is possible between cells belonging to the same site (intercell handover from one sector to the neighbour sector). 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 in the target cell by a CHANNEL ACTIVATION message with the IE ‘activation type: related to asynchronous handover’. In the HANDOVER COMMAND the BSC sets the ‘Synchronization Indication’ IE to the value ‘non-synchronized’. When the MS accesses the target cell after receipt of the HO CMD, it starts the timer T3124 on transmission of the first HO_ACCESS message and repeats the transmission until it receives the PHYSICAL INFO. This message contains the actual timing advance value which the new BTS derives from the delay of the HO_ACCESS messages received from the MS. When the PHYS INFO is received the MS stops T3124 and establishes the layer-2 connection on the new FACCH by sending the SABM. The MS falls back to the old TCH when T3124 expires or when the layer-2 connection setup fails.

Synchronous handover (cells finely synchronized): In case of synchronous HO the BSC activates the TCH in the target cell by a CHANNEL ACTIVATION message with the IE ‘activation type: related to synchronous handover’. The HANDOVER COMMAND sent by the BSC then contains the “ Synchronization Indication: synchronized “. When the MS accesses the target cell after receipt of the HO CMD, it transmits 4 consecutive HO_ACCESS messages and immediately establishes the layer-2 connection on the new FACCH by sending the SABM after that. No PHYS INFO is sent to the MS. A fallback to the to the old TCH is only possible if the 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 the handover procedure and thus reduces the ‘speech gap’ that can occur during the handover procedure.

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

HRSPEECH=TRUE,


range: TRUE, FALSE

default: FALSE

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

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



DISABLED


ENABLE(60) (major)


LCS monitor thresholds, this parameter indicates the A-Interface Monitor 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 is set to “enabled”.

LCSNSSC=FALSE,


range: TRUE, FALSE

default: FALSE

LCS NSS Centric solution, this parameter allows to choose the location service type ( NSS centric / BSS centric ) supported by BSC. If this parameter is set to TRUE, the BSC supports the NSS centric solution and all the BSS requests are rejected, on the contrary if it is set to FALSE the BSC support the BSS centric request and the NSS centric are rejected.

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

MADGRLV=2,


range: 0..3

default: 2

Maximum AIUR downgrade level for NT data calls, this attribute is only relevant if HSCSD is enabled (ENHSCSD=TRUE) and determines the maximum AIUR downgrade level for non-transparent data calls.

MAFIRACHO=2,


range: 1-3

default: 2

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



MAXNCELL=16,


unit: 1

range: 1-16

default: 1

Maximum number of target cells, this parameter indicates how many target cells may be included in the HANDOVER REQUIRED message sent to the MSC. The HO RQD message is sent, if the HO target does not belong to the own BSC area or if all handovers for a certain cell are to be performed by the MSC (see parameters LOTERCH and LOTRACH (SET HAND)).

MNTBMASK=<DEFAULT>,


unit: 1

range: BIT1.. BIT29

<DEFAULT>, Null

default: 1

Maintenance bit mask, this parameter was originally intended to be reserved for internal use only. The idea was to set specific bits of this parameter to enable manufacturer internal functions that require the installation of specific patches.

However, this parameter has also been repeatedly used to enable and control project-specific SW modifications or modifications that were introduced in BR6.02 as late features. For this reason it is urgently recommended to use this parameter only, if the operator knows the exact impact of each of the bits that can be set.

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

• Setting MNTBMASK=BIT25 disables the use of the GPRS coding schemes CS3 and CS4. This means that, if BIT25 is set, the BSC will only use the coding schemes CS1 and CS2 for GPRS. Some customers prefer to disable CS3/CS4 if EDGE is enabled, as with the number of concatenated EDGE radio timeslots supported by the currently available mobile phones the performance of EDGE is not far superior than the that of CS4. Thus the disabling of CS3/CS4 shall motivate the subscribers to subscribe to the EDGE services. However, setting MNTBMASK=BIT25 has the following side-effects: To enable CS3/CS4, it is mandatory to enable EDGE, as only in this mode the BSC can use concatenated TCH frames on the Abis - which is required for CS3 and CS4, as both coding schemes required two concatenated Abis TCHs. If, however, EDGE is enabled, two concatenated Abis TCHs will also be used for CS2 (If EDGE is disabled, CS1 and CS2 can be handled with a single Abis TCH). This means: if EDGE is enabled, but CS3/CS4 is disabled by BIT25, CS3 and CS4 will not be allocated but two concatenated Abis TCHs will be used for CS2 although this would not be necessary without EDGE. In other words, the customer has to consider that in any case additional GPRS resources are required for GPRS, even if CS3 and CS4 are disabled by BIT25.

• Setting MNTBMASK=BIT24 modifies the Implementation of the feature ‘Common BCCH’ in such a way that it is possible to mix TRXs of different Frequency bands within the complete area of the concentric cell while the inner area is not configured. Further details are described in section “Common BCCH Solution for mixed frequency bands within the complete area” in the appendix of this document. This functionality was originally only available for the US market and frequency bands (PCS1900 and GSM850), but was adapted also for the other frequency bands (GSM900 and DCS1800) 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 in the GSM900 extension band, both in EXT900 and in GSMDCS cells with the BCCH in the GSM900 primary band. This implies a sending of all frequencies (GSM900 primary band and GSM900 extension band) in SYSTEM INFORMATION TYPE1, causing a limitation on the number of possible frequencies (GSM900 primary band and GSM900 extension band) that can be used in the cell to only 22 (independently from thier value) and to a greather number only if they are "well distributed". This limitation is applied not only



to cells using GPRS but to all EXT900 or GSMDCS cells in the BSC. (CR2132)

• Setting MNTBMASK=BIT17 and MNTBMASK=BIT24 has the effect that GSUP can be enabled (and thus TRXMD can be set to EDGE) in all TRXs of the cells (GSM900 and DCS1800). This implies to sending of all frequencies (GSM900 primary band, GSM900 extension band and DCS1800 band) in in SYSTEM INFORMATION 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 if they are "well distributed". This limitation is applied not only to cells using GPRS but to all GSMDCS cells in the BSC. Note: The usage of the MNTBMASK=BIT17 alone, and the usage of both MNTBMASK=BIT17|BIT24 together, imply a change in the contents and encoding of the SYSTEM INFORMATION TYPE 1 for all cells in the BSC, and consequently of the related Mobile Allocation IEs, that have to be communicated to all BTS. This requires a complex procedure which is not foreseen in the BSC implementation. For this reason, and considering that the usage of BIT17 and BIT24 is related to a cell planning strategy and not to a punctual demand, a change of BIT17 and of BIT24 is rejected with a NACK cause if MNTBMASK=BIT17 was already set and if at least one cell is configured in the BSC. The change of both BIT17 and BIT24 are in this case only possible during offline generation/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 by MNTBMASK the default value is ‘0’. - The command allows to set 30 bits (BIT0..BIT29), however, only some of them can be really modified by command. Several bits of the maintenance 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 changes that bit which is included in the command. In other words, if BITy was set before, the command SET BSC:MNTBMASK=BITx; resets BITy to '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 to re-enter the command with ALL required bits set. - To set several bits at the same time, the parameter values must be linked with a 'pipe' (e.g. MNTBMASK=BIT8|BIT9). - All bits can be reset to their original values using the setting MNTBMASK=Null or MNTBMASK=<DEFAULT>.

MSCOVLH=TRUE,


range: TRUE, FALSE

default: TRUE

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

For further details about the BSC overload regulation please refer to the section “BSC, BTS and MSC overload Handling” in the appendix of this document. As MSC, BSC and BTS overload handling are closely interwoven, the overload conditions and traffic reduction mechanisms are explained in an own chapter that comprises all possible scenarios of overload and overload handling as well as the references to the relevant parameters.

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



MSCPOOL=TRUE,


range: TRUE, FALSE

default: FALSE

MSC pooling, this parameter specifies whether the connected MSC is able to manage the ‘pooling’ feature or not. As the MSC is the one to select the A-interface channels for a specific call the MSC has to manage the pooling types assigned to the A interface resources, too.

MSCV=PHASE2,


range: PHASE1

PHASE2

PHASE2CC

PHASE2EFR

PHASE2CCEFR

default: PHASE1

MSC version, this parameter determines the protocol type to be used 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 that MSC the supports the Information Element ‘Current Channel’ (‘CC’ in the value of MSCV actually means that the BSC includes the IE ‘Current Channel’ in the HANDOVER REQUIRED message, the receipt of this IE from the MSC is correctly handled anyway), PHASE2EFR indicates an MSC that supports the ‘Speech Version’ IEs, PHASE2CCEFR indicates that the MSC supports both the IE ‘Current Channel’ and the ‘Speech Version’ IEs. Note: If the feature 'ESVSIG' (extended speech version signaling) is enabled in the MSC the selected value must be PHASE2EFR, otherwise handover procedures may fail with 'protocol error between BSC and MSC’.

NCRESELFLAG=ENABLE,


range: DISABLE, ENABLE

default: DISABLE

Enable network-controlled GPRS cell reselection, this parameter determines whether GPRS network controlled cell reselection (NCCR) is enabled or disabled.

The ‘normal’ GPRS cell reselection algorithm is executed by the mobile station in case the parameter NTWCOR is set to NC0 (in BR70 always by default). Every GPRS MS in packet idle mode and in packet transfer mode measures received signals from both the serving cell and neighbouring cells and performs cell reselection autonomously on the basis of the cell selection criteria C1 (BCCH) or C31/C32 (in case a PBCCH is available in the cell).

The Network Controlled Cell Reselection is a different cell reselection method: The network requests measurement reports from the GPRS MSs and controls their cell reselection based on these measurements and configurable network controlled cell selection parameters. Thus, if network-controlled cell reselection is enabled, the network instructs the GPRS mobile to transmit the RXLEV_DL values of both serving and adjacent cells in PACKET MEASUREMENT REPORT messages. Based on the reported measurement values and on the configured network controlled cell reselection parameters, the network may command a GPRS MS to a neighbour cell that provides better radio conditions. This algorithm is called Radio Link Network Controlled Cell Reselection.

In addition, the operator can enable Traffic Control Network Controlled Cell Reselection (parameter TRFPS, see below). With this feature, the network may redistribute MSs among cells to satisfy the maximum number of service requests. The Traffic Control network controlled cell reselection guarantees the optimum usage of resources, i.e. a better GPRS/EGPRS traffic distribution among 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 reselection feature (NCRESELFLAG=ENABLE), only the Radio Link Network Controlled Cell Reselection is enabled. - if the user wants to enable the Traffic Control Network Controlled Cell Reselection, the traffic control strategy must be enabled (TRFPS=TRUE) in addition to the network controlled cell reselection (NCRESELFLAG=ENABLE).



NECI=FALSE,


range: TRUE, FALSE

default: FALSE


New establishment cause indication, this parameter controls the value of the NECI (New Establishment Cause Indicator) bit, which is broadcast in the SYSTEM INFORMATION TYPE 3 in the IE ‘Cell Selection Parameters.’ and which determines which ‘establishment cause’ values in the CHANNEL REQUEST message the MSs in the cell are allowed to use when requesting a dedicated control channel via the RACH for call setup or other transactions.

The available ‘establishment cause’ bit strings in the CHANNEL REQUEST message can be subdivided into two groups:

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

• GSM phase 2 establishment cause values GSM phase 2 introduced an additional set of establishment cause values, which consist of 4, 5 or 6 bits, which allow a more specific signaling of channel requirements (e.g. request for a HR TCH in case 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 CHANNEL REQUEST message in GSM 04.08.

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

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

Attention: The NECI parameter has an impact on the performance measurement counters for immediate assignment procedures ATIMASCA, SUIMASCA and NSUCCHPC. ATIMASCA counts the CHANNEL REQUEST messages that actually reach the BSC in the CHANNEL REQUIRED message, SUIMASCA counts the subsequent IMMEDIATE ASSIGNMENT messages. Both measurements distinguish the immediate assignment procedures by their establishment cause values and count them in separate cause-specific subcounters. As some of the subcounters of ATIMASCA and SUIMASCA represent specific phase 1 and phase 2 establishment causes, the changing of the NECI parameter will change the distribution of the counts over the subcounters. Moreover, especially if NECI=TRUE, the cause distribution between ATIMASCA/SUIMASCA on the one hand and NSUCCHPC on the other hand will deviate to a greater extent than with NECI=FALSE.

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



NETWTYPE=GSMDCS,


range: GSMDCS, GSMPCS,

GSMR, GSM850PCS,

GSM850DCS, GSMRAILPUB

GSMDCSTSM, GSMPCSTSM

default: GSMDCS

new values in BR7.0!

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

The value GSMRAILPUB means that the frequency bands GSMR and GSM900 and DCS1800 can be configured in the cells but, no handover 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

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

1. MTC during and ongoing ASCI group call When a particular ASCI MS is currently involved in a VBS or VGCS group call, it may still receive and accept normal terminating CS calls (MTC). As the ASCI MS normally does not monitor to the paging channel (PCH) of the BCCH during an ongoing ASCI group call, the BSC can instruct the ASCI MSs (currently involved in a group call) to monitor the PCH if a paging is to be transmitted. This is done with the DTAP message NOTIFICATION FACCH which is sent via the FACCH of the ASCI Common TCH (one DL TCH used by all ASCI MSs in the cell) directly prior to the PAGING COMMAND itself (which is sent via the PCH as usual) and which indicates ‘paging information is included’. The BSC sends the NOTIFICATION FACCH message to all cells with an activated ASCI common TCH only - if the PAGING message from the MSC contains the optional IE ‘eMLPP priority’ and - if the priority level indicated in the ‘eMLPP priority’ IE is equal or higher than the priority level defined by the parameter NOTFACCH. Exception: if NOTFACCH is set to ALWAYS, the priority level is not checked and the NOT FACCH message is sent in any case.

Notes: - A ‘talking’ ASCI subscriber (i.e. a subscriber who has requested and received a separate dedicated uplink TCH in 1,5 channel model (see parameter ASCIONECHMDL in command SET BSC [BASICS])) can never receive a notification via the FACCH because in this case notification is only sent via the ASCI Common TCH but not via the newly activated uplink TCH. In other words, only ‘listening’ ASCI subscribers can receive a notification on FACCH with paging information included.

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

2. Incoming ASCI group call during ongoing CS call (MOC, MTC) When a particular ASCI MS is currently involved in a CS call (MOC or MTC), the ASCI subscriber may still receive a VBS/VGCS group call. In this case the BSC informs the busy ASCI subscriber about the new ASCI group call via the NOTIFICATION FACCH message, which is sent on the dedicated CS TCH and which indicates ‘goup call information is included’. However, the BSC sends the NOTIFICATION FACCH message to the busy ASCI subscriber only - if the VBS/VGCS ASSIGNMENT REQUEST message from the MSC



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

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

The meaning of the values is the following:

ALWAYS (Notification/FACCH will always be sent) HIGHEQ4 (Notification/FACCH will always be sent for calls having priority equal or higher than 4) HIGHEQ3 (Notification/FACCH will always be sent for calls having priority equal or higher than 3) HIGHEQ2 (Notification/FACCH will always be sent for calls having priority equal or higher than 2) HIGHEQ1 (Notification/FACCH will always be sent for calls having priority equal or higher than 1) HIGHEQ0 (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 card type, determines whether a switching network SN64,SN16 is used.

If the BSC is upgraded to a high capacity BSC, the BSC must be equipped with a SNAP module. The corresponding setting must be NTWCARD=NTWSNAP. If, in addition, STLP boards are used as PCM interface cards the setting NTWCARD=NTWSNAP_STLP is mandatory.

OVLSTTHR=9500,


unit: 1000=10%

range: 7000..10000

default: 9500

BSC overload start threshold, this parameter determines the TDPC load threshold for the start of overload handling. The TDPC load is specified in %, where the value 1000 corresponds to 10% (see also parameters OVLENTHR and BSCOVLH).

OVLENTHR=8500,


unit: 1000=10%

range: 7000..10000

default: 8500

BSC overload end threshold, this parameter determines the TDPC load threshold for the end of overload handling. The TDPC load is specified 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 the network.



SIMSCREL99=FALSE,


range: TRUE, FALSE

default: FALSE

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

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

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

The reason for the introduction of this parameter was the necessity to support the message IMMEDIATE SETUP 2 in addition to the normal IMMEDIATE SETUP message. Both messages are used in the scope of ASCI (Advanced Speech Call Items, mainly used for GSM-R). The new IMMEDIATE SETUP 2 message allows the mobile to include the additional Information Element, OTDI (Originator To Dispatcher Information) into the IMMEDIATE SETUP message. This IE is relevant for the setup of ASCI emergency calls. An ASCI mobile is only allowed to send the IMMEDIATE SETUP 2 message if the MSC Release bit is set to ‘1’, which indicates that the MSC release is Release 99 or higher. This new procedure is allowed only with MSCs that are compliant to GSM release 99 or higher.

Also other applications might require the R99 compatibility of the MSC.

For the SIEMENS-MSC, this precondition is fulfilled starting with SR10 (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 determines the value of the ‘SGSN Release’ bit in the SYSTEM INFORMATION TYPE 13. This setting has a similar function like the parameter SIMSCREL99 (see above). It indicates that the Mobile Stations are allowed to use release-99-specific messages/information elements in their signaling towards the network, which is a mandatory precondition for specifc Rel. 99 procedures such as cell selection between 2G and 3G. If SISGSNREL99 is set to TRUE (and thus the ‘SGSN Revision’ bit is set to ‘1’ in the SYSINFO 13), the MSs are allowed to send Release-99-specific messages and information elements in their signaling messages towards the network.

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

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



SPEED145=FALSE,


range: TRUE, FALSE

default: FALSE

Speed 14.5 supported, this enables the data service with 14.5 kbit/s (brutto data rate, i.e. including frame header) respectively 14.4 kbit/s (netto data rate, i.e. without frame header) speed. This type of channel coding increases the data throughput of a single GSM time slot to 14.4 Kbit/s netto data rate and is based on a special transcoding algorithm which must be supported by the TRAU. The 14.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 a single connection. Both transparent and not-transparent connections are supported. The error correction mechanisms present in the Um coding of 14.4kbits channels is less effective compared to the one of the 9.6kbit/s coding. As a result the effective data rate of the 14.4kbit/s coding available to the user in non-transparent mode or when an external end-to-end error-control is applied may drop below the effective data rate achieved with the 9.6kbit/s coding. For this reason, a channel mode modify procedure in case of non-transparent mode (upgrading & downgrading: 9.6 kbit/s 14.4 kbit/s and vice versa) is implemented to adapt the data rate appropriately to the C/I environment. The BTS indicates the in-call-modification to the BSC using the MODIFICATION CONDITION INDICATION message which contains 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 a transparent call (both in case of established call or during handover). In transparent mode a 14.4 Kbit/s call handover to a cell that is not supporting 14.4 kbit/s coding will cause a drop. For further details related to the up- and downgrading of data calls please refer to the explanations provided for the parameters included in the command SET HAND [DATA].

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

SPENLAW=A_LAW,


range: A_LAW

M_LAW

default: A_LAW

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

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



T3122=5,


unit: 1s

range: 0..255

default: 5


Wait indication time, defines the MS waiting time before the MS allowed to attempt another RACH access by sending a CHANNEL REQUEST, if the BSS response to the previous RACH access was an 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 the CHANNEL REQUEST message by sending an IMMEDIATE ASSIGNMENT COMMAND via the AGCH. However, if the BSC cannot find any idle SDCCH to satisfy the request, it rejects the access attempts by sending an IMMEDIATE ASSIGNMENT REJECT message via the AGCH. The timer T3122 defines the time the MS must wait before it is allowed to send another CHANNEL REQUEST via the RACH in the same cell. This timer value is sent to the MS in the IE ‘Wait Indication’ within the IMMEDIATE ASSIGNMENT REJECT message.

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

TCBCSI=0,


unit: 1minute

range: 0..1440

default: 1

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

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



TGUARDTCHSD =SEC10,


range: SEC00, SEC10, SEC11,

SEC12, SEC13, SEC14,

SEC15

default: SEC00

Guard Timer for TCH/SD, this parameter defines the time the BSC has to wait before a TCH/SD is moved from the SDCCH_BACKUP_POOL to the TCH/SD_POOL. When a TCH is created with CHTYPE=TCHSD and CHPOOLTYP= TCHSDPOOL (see associated parameters in command CREATE CHAN), it can be used as TCH or as an additional SDCCH/8, allowing a dynamic on-demand enhancement of the SDCCH capacity. When a TCH/SD is created with TCHSDPOOL, it basically belongs to the TCH/SD_POOL, where it can be used as normal dual rate TCH. When the BSC receives an SDCCH request while the percentage of busy SDCCH subslots has exceeded the threshold SDCCHCONGTH (see command CREATE BTS [BASICS]), the BSC moves the 8 SDCCH subchannels of one TCH/SD from the TCH/SD_POOL to the SDCCH_BACKUP_POOL to keep additional SDCCH resources for further incoming SDCCH requests.

During the SDCCH allocation the SDCCHs of the SDCCH_POOL are always handled with priority, i.e. an SDCCH request will only be satisfied by a subslot from the SDCCH_BACKUP_POOL, if there is no subslot available in the SDCCH_POOL. This means that, when the SDCCH load decreases and the congestion in the SDCCH_POOL ends, no SDCCH will be allocated in the SDCCH_BACKUP_POOL anymore.

Whether a TCH/SD currently in the SDCCH_BACKUP_POOL can be moved back to the TCH/SD_POOL is checked during every release procedure for an SDCCH: during the SDCCH release the BSC checks the current SDCCH traffic load according to the following formula

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

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

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

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

a) In case of SDCCH traffic load ≥≥≥≥ SDCCHCONGTH the TCH/SD remains in the SDCCH_BACKUP_POOL and TGUARDTCHSD is not started. b) In case of SDCCH traffic load < SDCCHCONGTH the timer TGUARDTCHSD is started for those TCH/SDs which are in ‘idle’ mode (no SDCCH subslot in state ‘busy’). When it expires, the TCH/SD is moved back from the SDCCH_BACKUP_POOL to the TCH/SD_POOL. If TGUARDTCHSD=SEC00, idle TCH/SDs are immediately moved back to the TCH/SD_POOL when the abovementioned SDCCH traffic load condition is detected. If during the run time of TGUARDTCHSD another SDCCH request establishes that the move condition (SDCCH traffic load > SDCCHCONGTH) is fulfilled again, TGUARDTCHSD is stopped and the TCH/SD remains in the SDCCH_BACKUP_POOL.

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

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

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



threshold SDCCHCONGTH that is performed during the SDCCH release procedure is different from the one that is performed in case of SDCCH assignment! - 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’ 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 is still running for a specific TCH/SD in the BSC (i.e. the TCH/SD is still in the SDCCH_BACKUP_POOL), from point of view of the BTS the TCH/SD is treated as an dual rate TCH again. This means that the BTS might send idle channel measurements (see parameter INTCLASS in command SET BTS [INTERF]) during this period, even if the TCH/SD is still in the SDCCH_BACKUP_POOL.

TRACEMG=1,


(unit: 480ms)

range: 1..254

default: 1

Trace measurement granularity, this parameter determines the sending granularity for the TRACE MEASUREMENT RESULT messages. These TRACE MEASUREMENT RESULT messages are sent from BTS to BSC during calls for which the call trace features IMSI tracing (see command CREATE TRACE) or Cell Traffic recording (CTR, see command CREATE CTRSCHED) are enabled. The BTS starts to send the TRACE MEASUREMENT RESULT messages to the BSC when it receives the START TRACE message from the BSC (see also parameter TRACEMR). The sending is stopped when the BSC sends STOP TRACE message or when the call is released. As from point of view of the BTS there is no difference between IMSI tracing and CTR the sending granularity determined by TRACEMG is valid for both features.

TRACEMR=TRUE,


range: TRUE, FALSE

default: TRUE

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



TRFCT=20,


unit: 1 halfsecond

range: 10.. 200

default: 20 (=10 seconds)

Traffic (handover) control timer, this parameter determines the time between two consecutive traffic load checks which are performed by the BSC. TRFCT is initialized on every initialization or startup of the TDPCs and is automatically restarted on every expiry. When TRFCT expires, the BSC checks the traffic load in its cells and compares it to BTS specific thresholds associated to the following features:

a) Traffic handover (see parameter TRFHOE in command SET HAND [BASICS]): When TRFCT expires, the BSC checks the traffic load in its cells and compares it to the traffic handover high threshold (see parameter TRFHITH in command SET HAND) set for the affected BTS. If the traffic load in the cell is above the cell-specific threshold TRFHITH, the BSC enables the traffic handover in the affected BTS by sending an LAPD O&M message SET ATTRIBUTE with the indication ‚traffic handover enabled’ ‚to the BTSM. This O&M message is the trigger for the BTS to start the traffic handover decision algorithm (for more details 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 is still above the threshold TRFHITH, no further message is sent to the BTS and the traffic handover remains enabled in the affected BTS. If the traffic handover was enabled for a specific BTS on the previous expiry of TRFCT and the traffic load in the affected BTS has decreased below the threshold TRFHITH, the BSC disables the traffic handover in the affected BTS by sending an LAPD O&M message SET ATTRIBUTE with the indication ‚traffic handover disabled’ to the BTS.

In the BTS, the timer TRFHOT (see SET HAND [BASICS]) is used to cyclically decrease the dynamic traffic handover margin, if the traffic handover remains enabled for a longer time period. A reasonable setting 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 traffic handover margin reduction.

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

b) AMR compression handover (see parameter EADVCMPDCMHO in command SET HAND [BASICS]): The BSC checks the traffic load in its cells on every expiry of TRFCT and compares it to the threshold HRACTAMRT1 and HRACTAMRT2 (see command SET BTS [BASICS]). If the traffic load in the cell exceeds the threshold HRACTAMRT1, the BSC enables the AMR compression handover in the affected BTS by sending an LAPD O&M message SET ATTRIBUTE with the indication ‚AMR compression handover enabled’ to the BTS. This indication starts the AMR compression handover 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. 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

Traffic control packet switched, this parameter determines whether the feature ‘GPRS traffic control strategy’ is enabled for GPRS Network Controlled Cell Reselection in the BSC. This parameter is only relevant if GPRS Network Controlled Cell Reselection was enabled by setting the parameter NCRESELFLAG to ENABLE (see above). In case of traffic congestion within one cell, the Traffic Control Network Controlled Cell Reselection is applied for GPRS and EGPRS in order to spread the load by transferring some traffic towards the neighbour cells. Based on cell traffic thresholds, the traffic is distributed among the cells belonging to the same PCU (Packet Control Unit) within the appropriate BSC. The BSS updates the internal references that indicate the location of the MS, and related information is sent to the serving GPRS support nodes involved.

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

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

For further details please refer to the parameters CRESELTRHSOUT, CRESELTRHINP, NCTRFPSCTH, TRFPSCTRLT, NTWCREPPIDL, NTWCREPPTR, NTWCNDRXP, TDDGQO, GNMULBAC, GFDDREPQTY and GUMTSSRHPRI (see command 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 switched traffic, this parameter controls the time to pass between two consecutive radio resource upgrade attempts for packet services separately for the uplink (first field of parameter value) and the downlink (second field of parameter value) in steps of 1 second.

During a TBF lifetime, due to variations in radio conditions, either the BLER or the used CS/MCS coding scheme can change, leading to a change in the ‘maximum sustainable throughput’. The BSC periodically performs a check of the current maximum sustainable throughput (MST) and compares it to a particular threshold which is individually calculated on the basis of the parameter ACCEPTGDEGR. For details about the calculation and the upgrade of radio resources due to a drop of the MST please refer to the parameter ACCEPTGDEGR (see above).

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

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



Setting the alarm priorities of the BSS functional objects:

SET BSC [ALARMSEV]:

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


ALRMSEVBTS=CRITICAL,

object: BSC [ALARMSEV]

range: Minor, Major, Critical

default: Critical

Alarm severity BTS, determines the alarm severity of the BTS object.

ALRMSEVBTSM=MAJOR,



default: Major

Alarm severity BTSM, determines the alarm severity of the BTSM object.

ALRMSEVBTSMTD=MAJOR,



default: Major

Alarm severity BTSMTD, determines the alarm severity of the BTSMTD (BTSM for TD-SCDMA) object

ALRMSEVBTSTD= CRITICAL,



default: Critical

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

ALRMSEVCBCL =MAJOR,



default: Major

Alarm severity CBCL, determines the alarm severity of the CBCL object.

ALRMSEVFRL=MINOR,



default: Minor

Alarm severity FRL, determines the alarm severity of the FRL object.

ALRMSEVIPLI=MAJOR,



default: Major

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

ALRMSEVLPDLM=MAJOR,



default: Major

Alarm severity LPDLM, determines the alarm severity of the LPDLM object.



ALRMSEVLPDLMTD= MAJOR,



default: Major

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

ALRMSEVLPDLR=MAJOR,



default: Major

Alarm severity LPDLR, determines the alarm severity of the LPDLR object.

ALRMSEVLPDLRTD= MAJOR,



default: Major

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

ALRMSEVLPDLS=MAJOR,



default: Major

Alarm severity LPDLS, determines the alarm severity of the LPDLS object.

ALRMSEVNSVC=MINOR,



default: Minor

Alarm severity NSVC, determines the alarm severity of the NSVC object.

ALRMSEVOMAL=MAJOR,



default: Major

Alarm severity OMAL, determines the alarm severity of the OMAL object.

ALRMSEVPCMA=MAJOR,



default: Major

Alarm severity PCMA, determines the alarm severity of the PCMA object.

ALRMSEVPCMB=MAJOR,



default: Major

Alarm severity PCMB, determines the alarm severity of the PCMB object.

ALRMSEVPCMG=MAJOR;



default: Major

Alarm severity PCMG, determines the alarm severity of the PCMG object.

ALRMSEVPCMS=MAJOR,



default: Major

Alarm severity PCMS, determines the alarm severity of the PCMS object.

ALRMSEVPCU=CRITICAL,



default: Critical

Alarm severity PCU, determines the alarm severity of the PCU object.

ALRMSEVPCUTD= CRITICAL,

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





default: Critical

ALRMSEVPTPPKF=MAJOR,



default: Major

Alarm severity PTPPKF, determines the alarm severity of the PTPPKF object.

ALRMSEVTDCU=CRITICAL,



default: Critical

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

ALRMSEVTRAU=CRITICAL,



default: Critical

Alarm severity TRAU, determines the alarm severity of the TRAU object.

ALRMSEVTRX=MAJOR,



default: Major

Alarm severity TRX, determines the alarm severity of the TRX object.

ALRMSEVTRXTD=MAJOR,



default: Major

Alarm severity TRXTD, determines the alarm severity of the TRXTD object (TRX in TD-SCDMA BTS).



Setting the remote Inventory data of the BSC Equipment:

SET BSCE [REMINV] :

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BSCE packages’ were moved below the object BSCE and appear in the DBAEM in the SET BSCE command. The logical group “[REMINV]” is normally only used on the LMT but was used here to allow 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 Unique Name, this attribute defines the BSC Network Element by its unique symbolic name.

EQPOS=”010101”,

object: BSC [REMINV]


(6 characters)

in quotation marks

default: “010101”

Equipment position, this attribute defines the position of the Network 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 and appear in the DBAEM in the SET BSCE command. The logical group “[ALARMSEV]” is normally only used on the LMT but was used here to allow a more useful grouping of the commands .

NAME=BSCE:0, Object path name.

ALRMSEVCPEX=CRITICAL,

object: BSCE [ALARMSEV]


default: Minor

Alarm severity CPEX, determines the alarm severity of the CPEX object (the CPEX (Control Panel and External alarms device) is the card which reports to MPCC 16 external alarms and the FAN alarm and controls the fuse and alarm panel.

ALRMSEVDISK=MAJOR,



default: Major

Alarm severity DISK, determines the alarm severity of the DISK object.

ALRMSEVDK40=MAJOR,



default: Major

Alarm severity DK40, determines the alarm severity of the DK40 object.



ALRMSEVEPWR=MAJOR,



default: Major

Alarm severity EPWR, determines the alarm severity of the EPWR object.

ALRMSEVIXLT=MAJOR,



default: Major

Alarm severity IXLT, determines the alarm severity of the IXLT object.

ALRMSEVLICD=MINOR,



default: Minor

Alarm severity LICD, determines the alarm severity of the LICD object.

ALRMSEVLICDS=MINOR,



default: Minor

Alarm severity LICDS, determines the alarm severity of the LICDS object.

ALRMSEVME2M=MAJOR,



default: Major

Alarm severity ME2M, determines the alarm severity of the ME2M object.

ALRMSEVMEMT=MAJOR,



default: Major

Alarm severity MEMT, determines the alarm severity of the MEMT object.

ALRMSEVMPCC=MAJOR,



default: Major

Alarm severity MPCC, determines the alarm severity of the MPCC object.

ALRMSEVNTW=MAJOR,



default: Major

Alarm severity NTW, determines the alarm severity of the NTW object.

ALRMSEVPPCC=MAJOR,



default: Major

Alarm severity PPCC, determines the alarm severity of the PPCC object.

ALRMSEVPPCU=MINOR,



default: Min or

Alarm severity PPCU, determines the alarm severity of the PPCU object.

ALRMSEVPPLD=MINOR,



default: Min or

Alarm severity PPLD, determines the alarm severity of the PPLD object.

ALRMSEVPPXL=MINOR,



default: Major

Alarm severity PPXL, determines the alarm severity of the PPXL object.



ALRMSEVPPXP=MINOR,



default: Min or

Alarm severity PPXP, determines the alarm severity of the PPXP object.

ALRMSEVPPXT=MINOR,



default: Min or

Alarm severity PPXT, determines the alarm severity of the PPXT object.

ALRMSEVPPXU=MINOR,



default: Min or

Alarm severity PPXU, determines the alarm severity of the PPXT object.

ALRMSEVPWRD=MAJOR,



default: Major

Alarm severity PWRD, determines the alarm severity of the PWRD object.

ALRMSEVSYNC=MAJOR,



default: Major

Alarm severity SYNC, determines the alarm severity of the SYNC object.

ALRMSEVSYNE=MAJOR,



default: Major

Alarm severity SYNE, determines the alarm severity of the SYNE object.

ALRMSEVTDPC=MAJOR,



default: Major

Alarm severity TDPC, determines the alarm severity of the TDPC object.

ALRMSEVX25A=MAJOR,



default: Major

Alarm severity X25A, determines the alarm severity of the X25A object.

ALRMSEVX25D=MAJOR;



default: Major

Alarm severity X25D, determines the alarm severity of the X25D object.

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 counter, determines the threshold for errors that lead to a 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 line returns

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 a PCMS. It avoids A-interface reset (and thus call release) procedures even if the link interruption is very short. 2) ALARMT2 < TSYNC and ALARMT2 < TTRAU (for TSYNC and TTRAU see command SET BTS [TIMER]) This setting is necessary in order to avoid call release before PCM alarm detection.

ALARMT3=5;

object: LICD

unit: 5 min

range: 1-254

default: 1

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

line errors are detected within [ALARMT3∗5] minutes



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, where there are special LICDs which are not numbered like the others but explicitly defined as ‘spare’. For the PPLDs always the PPLD created last, i.e. the one with the highest object instance number is automatically configured as spare, i.e. in operation its status is ‘hot standby’. The distribution of the created LAPD channels (LPDLM, LPDLS, LPDLR) is managed via so-called LAPD pools. A LPAD pool is a functional instance that represents a group of LPDLx channels that can be managed by one PPLD. Thus one PPLD can manage one LAPD pool. The distribution of the created LAPD channels takes place either automatically or can be manually defined during the creation of the LPDLM and LPDLS (for further details please refer to the parameter LAPDPOOL in the commands CREATE LPDLM and CREATE LPDLS). The actual association the PPLD to the internal LAPD pools and the created LPDLx channels (x=M,R,S) can be interrogated by the command GETINFO PPLD. Deletion of the PPLD is not possible as long as the subordinate served LAPD channels are not deleted as well.

The PPLD objects must be deleted if the BSC is upgraded to a high capacity BSC and is equipped with PPXX modules! >

CREATE PPLD:

NAME=ppld:0; Object path name.

Creating the PCU objects:

< The PCU functional object represents the packet control unit designed to implement GPRS/EDGE services in the SBS. The creation of a PCU implies the creation of: - two redundant PPCU cards if NTWCARD = NTWSN16 - a PPXU card (same instance number as the PCU) if NTWCARD = NTWSNAP or NTWSNAP_STLP.

CREATE PCU:

NAME=PCU:pcun, Object path name. Range for pcun = 0..11 The 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 for non-valid-data error coming from the mobile station after having sent USF. N3101 represents a counter on the network side: If the network receives a valid data block from the MS after setting the Uplink State Flag (USF), N3101 is reset.. The counter is incremented for each USF for which no valid data is received. If N3101 reaches the threshold value, the PCU considers the TBF lost, stops scheduling RLC/MAC blocks for this USF and starts timer T3169.

N3103=10,

object: PCU

range: 1-255

default: 10

This parameter defines the threshold for not received PACKET CONTROL ACK as response to PACKET UPLINK ACK/NACK messages. N3103 represents a counter on the network side: If the network receives PACKET CONTROL ACK from the MS as response to a final PACKET UPLINK ACK/NACK, N3103 is reset. If the network does not receive the PACKET CONTROL ACK in the scheduled block, N3103 is incremented and the PACKET UPLINK



ACK/NACK message is retransmitted. If N3103 reaches the threshold value, timer T3169 is started.

N3105=10,

object: PCU

range: 1-255

default: 10

This parameter defines the threshold for not received RLC/MAC control 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 the TBF, N3105 is reset. The counter is incremented for each radio block allocated to that TBF with the RRBP field set, for which no RLC/MAC control message is received. If N3105 reaches the threshold value, the network regards the communication with the MS lost, stops transmitting RLC data blocks and starts T3195

NBVCBR=3,

object: PCU

range: 1-30

default: 3

Number of BVC Block Retries. This parameter is used within the BVCI block procedure. If a BVC-BLOCK PDU is not acknowledged within T1 seconds from the SGSN, the blocking procedure is repeated at maximum NBVCBR times. After NBVCBR unsuccessful reattempts, the BVCI status remains blocked and an O&M alarm is generated.

NBVCRR=3,

object: PCU

range: 1-30

default: 3

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

NBVCUR=3,

object: PCU

range: 1-30

default: 3

Number of BVC Unblock Retries. This parameter is used within the BVCI unblock procedure. If a BVC-UNBLOCK PDU is not acknowledged within T1 seconds from the SGSN, the unblocking procedure is repeated at maximum NBVCUR times. After NBVCUR unsuccessful reattempts, the BVCI status remains blocked and an O&M alarm is generated.

NMO=NMO_2,

object: PCU

range: NMO_1, NMO_2, NMO_3

default: NMO_2

Network mode of operation, this parameter determines which types of 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 same channel as the GPRS paging channel (CCCH or PCCCH if created) or on a GPRS traffic channel. Therefore the MS only needs to monitor one Paging Channel and it receives circuit-switched pagings even if it is in packet transfer mode (PDCH allocated). Circuit-switched pagings for GPRS attached mobiles are routed via the 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 both circuit-switched as well as packet-switched pagings on the CCCH paging channel. The MS therefore only needs to monitor this paging channel. As a consequence, circuit-switched pagings are ignored by the MS while it is in packet transfer mode. A PBCCH shall not be created in the cell while using NMO_2! In Network Mode 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 the PCCCH paging channel (if a PBCCH is created in the cell). Therefore an MS that wants to receive pagings for both circuit-switched and packet-switched services shall monitor both paging channels if the packet paging channel is allocated in the cell. Similar to NMO_2 the mobiles are not CS reachable while they are in packet transfer mode.

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

Note: For proper operation the 'Network Mode of Operation' should be the same in each cell of a routing area. The NMO value is broadcast



in the system infos on the BCCH/PBCCH.

NNSVCBLKR=3,

object: PCU

range: 1-254

default: 3

This parameter specifies the Maximum number of retries performed in the NSVC block procedure. If the SGSN does not answer to the block procedure, the procedure is retried for NNSVCBLKR times.

NNSVCRR=10,

object: PCU

range: 1-254

default: 10

This parameter specifies the Maximum number of retries performed in the NSVC reset procedure before generating any alarm. If the SGSN does not answer to the reset procedure, the procedure is retried infinitely but after NNSVCRR times an O&M alarm is notified.

NNSVCTSTR=10,

object: PCU

range: 1-30

default: 10

This parameter specifies the Number of consecutive retries performed for the NS test procedure (exchange of NS-ALIVE/NS-ALIVE-ACK PDUs) before the NSVC is marked dead and blocked, an O&M alarm is generated and a STATUS indication is sent to the NS user entity.

NNSVCUBLR=3,

object: PCU

range: 1-254

default: 3

This parameter specifies the Maximum number of retries performed in the NSVC unblock procedure. If the SGSN does not answer to the unblock procedure, the procedure is retried for NNSVCUBLR 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 blocks the PCU issues a PACKET UPLINK ACK/NACK message. This applies under all circumstances for the currently supported MS multislot classes 1-10 (max. 2 UL timeslots). During DL TBFs: In average every NRLCMAX-th DL data block is polled (RRBP set) to request a PACKET DOWNLINK ACK/NACK from the mobile. This behaviour applies for DL transfers with 1 or 2 timeslots allocated. In case the DL TBF is allocated on 3 timeslots, the effective polling distance is defined by (NRLCMAX-5). In case the DL TBF TBF is allocated on 4 timeslots, the effective polling distance is defined by (NRLCMAX-12). This reduced polling period (every 15

th/8

th block) is required to

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

NSEI=10,

object: PCU

range: 0..65534

Network Service Element Identifier, this parameter represents the PCU area identification and has end-to-end significance across the Gb interface. It uniquely identifies a PCU which is connected to the SGSN (via the Gb-interface) with one or more NSVCs (group of NSVCs).

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

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



T1=10,

object: PCU

unit: 1s

range: 2-29

default: 10

This timer defines the Waiting 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 parameters NBVCBR and NBVCUR).

T2=10,

object: PCU

unit: 1s

range: 2-119

default: 10

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

T3141=5,

object: PCU

unit: 1s

range: 1-30

default: 5

T3141, this timer is started on the network side when a TBF is assigned with an IMMEDIATE ASSIGNMENT message during a packet access procedure. It is stopped when the MS has correctly seized the TBF. If T3141 elapsis before a successful contention resolution procedure is completed, the newly allocated TBF is released.

T3169=1,

object: PCU

unit: 1s

range: 1-30

default: 1


T3169, this timer defines the waiting time to reuse the respective TFI and USF values after the thresholds N3101 and N3103 (see parameters above) were reached.

T3172=5,

object: PCU

unit: 1s

range: 0..255

default: 5

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

T3191=5,

object: PCU

unit: 1s

range: 1-30

default: 5

T3191, this timer defines the waiting time for reuse TFI after having sent the last RLC block. It is started with the last DL data block sent in a TBF (Final Block Indicator=1) and stopped with the reception of the final PACKET DOWNLINK ACK/NACK (or PACKET CONTROL ACK). On expiry the network releases the TFI allocated to that TBF.

T3193=4,

object: PCU

unit: 100 ms

range: 1-42

default: 4

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

Note: Setting T3193 to the value 4 (=400ms) still fulfils the above rule due to system-internal propagation times. Important is that T3193 expires after T3192 surely elapsed (ensuring that the MS already abandoned 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 after the threshold N3105 (see above parameter) was reached. Main reasons 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 the release of an allocated PDCH if there are no TBF activities.

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

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

The timer TEMPCH is started on the stop of the last TBF and keeps the allocated TCH activated to serve possible new TBFs, i.e. when the last MS associated to a PDCH is released (no TBF is ongoing on the PDCH anymore) the “virtual” assignment of the PDCH persists for the duration of the timer TEMPCH. The purpose of this timer is to avoid continuous channel allocation requests from the PCU to the TDPC and the associated CHANNEL ACTIVATIONs and IMMEDIATE ASSIGNMENT procedures which would happen in periods of high GPRS/EGPRS traffic if the allocated resources were directly released after the stop of the TBF activities on the allocated TCHs.

As long as TEMPCH is running, the allocated PDCH(s) for the “released” TBF are still regarded as allocated even if they are not used for the transfer of payload. However, if a TCH was activated as PDCH for GPRS traffic but the TEMPCH timer is running for it, (which means that there is no ongoing TBF on the TCH), the TCH is always regarded as ‘downgradable’ resp. ‘preemptable’ for CS calls, no matter which value was set for the DGRSTRGY parameter. In other words, in periods of TCH congestion the BSC immediately releases PDCHs (TCHs activated for GPRS) with TEMPCH running if a CS TCH request is received and no other idle TCH is available for allocation. This change was implemented in BR7.0 in the scope of CR1150 (see also parameters DGRSTRGY and CPOLICY in command 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 delay time for the release of an allocated PDT with subframe counter > 0 if the related PDCH does not require this PDT anymore (e.g. due to a downgrade of the used coding scheme). The value of TEMPPDT must be smaller than TEMPCH.

If GPRS/EDGE calls are set up, the TDPC is responsible for 1. the assignment of the proper radio resources on the air interface (PDCHs) and 2. the assignment of the Abis interface subslots related to these PDCHs. The timer TEMPPDT is used to avoid continuous requests for Abis resources from the PCU to the TDPC. Example situation: An MCS9 DL TBF is allocated on 2 radio timeslots (PDCH). Each of the PDCHs has five 16kbit/s Abis subslots allocated – in total 10 PDTs are in use on PCU side. Let us assume a sudden downgrade of the coding scheme to MCS6 now (due to bad radio conditions). As soon as the coding scheme MCS6 is applied from the PCU, only 3 of the previously 5 Abis subslots (and PDTs) are necessary to transport the user data for each PDCH. TEMPPDT is started at that moment for the 2+2 affected PDTs (with subframe counter 3 and 4) – and if no upgrade 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 capacity reporting period used in flow control algorithm. It corresponds to the C timer reported in the GSM 8.18 recommendation and specifies the minimum time period allowed 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 thresholds for TH-proximity evaluation. Note: These timers were implemented based on older specifications which are no more valid now. Therefore they are not used by the system.

Caution: These three parameters were repeatedly “abused” for development and system test purposes in order to implement additional test features – partly also customer relevant features. At the current stage of BR70 no official released functionalities are controlled by them, therefore we strongly recommend to set the default values unless otherwise officially specified!

THSULBAL=587,

object: PCU

range: 0..2000

default: 587

Threshold switch uplink balanced, this parameter indicates the threshold that the field ‘RLC_Octet_Count’ (part of the Channel Request Description IE) has to exceed to activate an ‘uplink priority’ condition. If ‘RLC_Octet_Count’ exceeds the value of THSULBAL, the system allocates two PDCHs in uplink direction instead of preferring the downlink direction (while a concurrent DL TBF is active). This functionality is important for mobiles with multislot class 6 (3+2; total 4) and 10 (4+2; total 5). A class 6 mobile e.g can be used either in 3+1 or in 2+2 configuration, so there is a trade-off between the maximum possible UL and DL speed. The network decides based on THSULBAL 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 release of an ongoing DL TBF. Dummy LLC-PDUs are inserted to keep a DL-TBF open for the specified time interval. This allows a faster transfer of new DL data arriving on the Gb-interface (DL TBF already open) and a faster setup of new UL TBFs (as concurrent TBFs).

TNSVCBLK=3,

object: PCU

unit: 1s

range: 1-10

default: 3

This timer defines the Waiting time for the NSVC block/unblock procedure. After an NS-BLOCK or NS-UNBLOCK PDU has been sent by the PCU, it waits TNSVCBLK seconds for the acknowledgement. If no acknowledge arrives in time, the procedure is repeated (parameters NNSVCBLKR and NNSVCUBLR).

TNSVCPTST=3,

object: PCU

unit: 1s

range: 1-10

default: 3

This timer defines the Waiting time for the NSVC test procedure. After an NS-ALIVE PDU has been sent by the PCU, it waits TNSVCPTST seconds for the acknowledgement. If no acknowledge arrives in time, the test procedure is repeated (parameter NNSVCTSTR).

TNSVCR=3,

object: PCU

unit: 1s

range: 1-10

default: 3

This timer defines the Waiting time for the NSVC reset procedure. After an NS-BLOCK PDU has been sent by the PCU, it waits TNSVCR seconds for the acknowledgement. If no acknowledge arrives in time, the reset procedure is repeated (parameter NNSVCRR).



TNSVCTST=30,

object: PCU

unit: 1s

range: 1-60

default: 30

This timer defines the Periodicity timer for the NSVC test procedure. As soon as the NS reset procedure is completed, the periodic NS test procedure is performed on the Gb-interface from both sides (BSC and SGSN independently). For this purpose an NS-ALIVE PDU is sent towards the SGSN every TNSVCTST seconds. If no acknowledge arrives in time (TNSCVPTST), the test procedure is repeated (NNSVCTSTR).

TSULBAL=20,

object: PCU

unit: 1s ???

range: 0..100

default: 20

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

Creating the PCM links for the Abis interface:

< PCMB is the PCM link on the Abis interface. >

CREATE PCMB:

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

BAF=2,

object: PCMB

range: 0..255

default: 0

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

BER=E10_3,

object: PCMB

range: E10_3, E10_4, E10_5

default: E10_3

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

CRC=TRUE,

object: PCMB

range: TRUE, FALSE

default: FALSE

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



(L1CTS=31-3),

object: PCMB

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

timeslot: 0..24 (for PCM24)

subslot: 0..3

Layer 1 control timeslot, defines the Abis timeslot to be used for layer 1 supervision of specific Abis line configurations (e.g. ‘31-3’ means: layer 1 supervision in timeslot 31, subslot 3). 1) Loop configuration on Abis: in this case the layer 1 control timeslot is used to control the loop direction switch. Principle of loop configuration: All BTSEs in the loop and the BSC permanently transmit a signal pattern via the layer-1 timeslot which indicates 'idle' or 'failure'. This pattern is transmitted only in the 'forward' direction. The layer-2 setup messages, however, are transmitted by all BTSEs in the loop (as well as by the BSC) in both directions but received only from the currently 'active' direction (LI port 1 or port 2). For this reason only in the 'active' direction the setup of the higher layers takes place and the traffic and signaling information is received only via the used LI port.

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

2) Abis connection using 2 PCM links (BTS+) In this case the supervision of the link availability has to be done either by layer 2 or layer 1 error detection functions. For those PCM links which carry a LAPD link the error detection is ensured by LAPD layer 2 functions. For all other links the error detection has to be ensured by configuration of an layer 1 control timeslot. E.g. in the example configuration below (BTS crossconnect function is supported from BR5.5 on) the PCMB links BSC <-> BTSM 1 and BSC <-> BTSM 3 have to be supervised by configuration of an appropriate layer 1 control timeslot.

BTSE

1

LI

port

2

LI port 1

BTSE

0

LI

port

2

LI port 1

BTSE

n

LI port 1

LI

port

2

BSC

QTLP

port

B

QTLP port 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 bit error rate.

LREDUNEQ=SIMPLEXA,

object: PCMB

range: SIMPLEXA, SIMPLEXB

DUPLEX

default: SIMPLEXA

Link redundancy. Every logical LICD port consists of 2 physical ports A and B. Here LREDUNEQ must be SIMPLEXA/B for STAR and MULTIDROP configuration and DUPLEX for LOOP configuration (where port B is used for the incoming end of the loop chain).

CODE=HDB3,

object: PCMB

range: HDB3, AMI

default: HDB3

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

NUA=FALSE,

object: PCMB

range: TRUE, FALSE

default: FALSE

‘Not Urgent Alarm’ enabled, determines whether or not ‘not urgent alarms’ can be signaled. 'Not urgent alarms' are signaled using the 4th bit (Sa4 bit) of the NFAS signal (“Service Word” in timeslot 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

Remote alarm.



WMOD=DOUBLE_TRUNK;

object: PCMB

range: SINGLE_TRUNK,

DOUBLE_TRUNK

default: DOUBLE_TRUNK

Working mode, this attribute indicates whether the PCMB works in single trunk mode or in double trunk mode. The SINGLE_TRUNK mode was introduced as part of the feature “High Capacity BSC” in BR6.0 and is used to extend the number of PCMBs that can be connected to the available QTLP ports. The value DOUBLE_TRUNK mode represents the only connection modes that were possible in releases up to BR5.5: a) One PCM link representing one PCMB can be connected to one port of the selected QTLP port only (REDUNEQ=SIMPLEXA or SIMPLEXB), in this case the remaining port remains unused. b) One PCM link can be connected to port A and another PCM link can be connected to port B of the QTLP port (REDUNEQ=DUPLEX) for an Abis loop configuration (see parameter L1CTS). In this case, both ports A and B represent the same PCMB object! The value SINGLE_TRUNK is represents a configuration in which one PCMB can be connected to each QTLP subport (A and B). In this 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

B BTSE

PCMB 1

BTSE

PCMB 0 A

DOUBLE_TRUNK mode:

QTLP port

BTSE

B BTSE

PCMB 0

BTSE



Creating the PCMS link:

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

BER=E10_3,

object: PCMS

range: E10_3, E10_4, E10_5

default: E10_3


CODE=HDB3,

object: PCMS

range: HDB3, AMI

default: HDB3

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

CRC=TRUE,

object: PCMS

range: TRUE, FALSE

default: FALSE

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

LREDUNEQ=SIMPLEXA,

object: PCMS

range: SIMPLEXA, SIMPLEXB

DUPLEX

default: SIMPLEXA

Link redundancy. Every logical LICD port consists of 2 physical ports A and B, port B can be used in addition to port one for a redundant link. Here LREDUNEQ must be SIMPLEXA/B if a non-redundant PCM link is used and DUPLEX if port B is equipped with a redundant PCM link. A redundant PCMS link is an additional physical line which is 'hot standby' to take over the traffic and signaling if the currently active one fails. Note: If the link redundancy is set to DUPLEX both traffic and signaling info is transmitted via both links while it is received only via the 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

Low bit error rate.

NUA=FALSE,

object: PCMS

range: TRUE, FALSE

default: FALSE

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



PCML=1-1,

object: PCMS



port-no. 0..3 (QTLP)

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

REMAL=CCITT,

object: PCMS

range: CCITT, BELLCORE

default: CCITT

Remote alarm.

WMOD=DOUBLE_TRUNK;

object: PCMS

range: SINGLE_TRUNK,

DOUBLE_TRUNK

default: DOUBLE_TRUNK

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

The value DOUBLE_TRUNK mode represents the only connection mode which was possible in releases up to BR5.0: One PCMS (i.e. one TRAU) can be connected to one port of the selected QTLP port only (REDUNEQ=SIMPLEXA or SIMPLEXB) or one PCMS can be connected 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 this setting it is possible to connect one PCMS to each physical QTLP port

redundant

link

PCMS 0 A

B

TRA

U

DOUBLE_TRUNK mode:

QTLP port

PCMS 1

PCMS 0 A

B

TRAU

TR

AU

SINGLE_TRUNK mode:

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 criteria, this attribute replaces the parameter TRANMTX which was used up to BR4.0 and defines which mapping system is used between the timeslots of the A- and Asub-interface. Since the introduction of the feature ‘pooling’ (see SET BSC [BASICS], parameter ENPOOL) the previously rigid mapping of timeslots is replaced by a semipermanent mapping (i.e. a mapping modifiable by configuration commands) which depends on the types and number of TCH pools created on the A-interface. a) The value NOT_COMPATIBLE_WITH_CROSS_CONNECT value can be chosen when no cross-connectors between BSC and TRAU are used (corresponds to the previous ‘TRAU matrix type 1’). For the basic mapping principle please refer to the diagram on the next page. b) COMPATIBLE_WITH_CROSS_CONNECT value has to be chosen when cross-connectors between BSC and TRAU are used (corresponds to the previous ‘TRAU matrix type 2’). For the basic mapping principle please refer to the diagram on the next page. The advantage of this mapping system is that all subslots of the PCMS timeslots can be completely filled even if not all 4 PCMA-links are used between TRAU and MSC. This solution is of special interest if the network operator does not rent complete PCM-links for the PCMS but only single timeslots.

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



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

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

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

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

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

U

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

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

Channel type Used timeslot

on Asub

Used timeslots

on A interface

Not usable timeslots

on 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 .. 31 are not usable !

Note: TRAU Matrix type 2: If specific timeslots on the PCMS are used for CCS7, OMAL and LPDLS all PCMA-timeslots that are mapped to the 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 timeslot

on Asub

Used timeslots

on A interface

Not usable timeslots

on 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 or disable the TFO mode. TFO is a feature that improves the speech quality of mobile-to-mobile speech calls by avoiding a double transcoding in both involved TRAUs.

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

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

Principle: If TFO is enabled, each TFO capable TRAU checks whether the peer TRAU is capable to support TFO and is using the same codec. After verifying these conditions, each TRAU can start to insert speech TFO frames into the call related PCM octet on the A interface. If at least one of these conditions stated above is not met, the speech call will be carried on in the traditional way. The TFO signalling procedures do not depend on the any call set up procedures, i.e. TFO does not involve the Call Control in the MSC and in the BSC. No information is forwarded to the BSC in order to modify 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 establishment mode', the TFO negotiation messages are transferred in the Least Significant Bit of (a-law) PCM samples. The TFO message bit is transferred by replacing the LSB in every 16 consecutive PCM samples. This will result in a 0.5 kbit/s signalling. The 0.5 kbits/s are regularly stolen of the 64 kbits/s circuit and by this small amount of data the degradation on the speech quality is inaudible. 2) In the second phase, the 'TFO established mode', when the FR, HR or EFR transcoder is used TFO speech frames, which are similar to the frames in 08.60, are carried by 16 kbit/s channel mapped onto the two LSB bits of each PCM sample. For HR channels the TFO speech frames, which are similar to the frames in 08.61, are carried by 8 kbit/s channel mapped onto the LSB bit of each PCM sample. The TFO speech frames have a fixed length of 160 bits (20msec) for 8 kbits/s traffic channels and 320 bits (20msec) for 16 kbits/s traffic channels.

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



EXPSWV= "02-04-01-02-06-00 _98-07-30",

object: TRAU

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

PCMSN=0,

object: TRAU

range: 0..19

PCMS-no..

SALUNAME=”BSC1TRAU0”,

object: TRAU


(11 characters)

in quotation marks


Sales Unique Name, this attribute defines every Network Element by its unique symbolic name. It can be optionally used for the network element identity verification during the alignment phase in addition to the TEI (see CREATE LPDLS). In previous releases (up to BR4.5) the (LPDLS-)TEI was the only criteria used for the network element identity verification during the alignment procedure. The new approach using the Sales Unique Name in addition to an individually configurable TEI allows a much higher flexibility in the allocation of the TRAUs to the BSCs without loss of safety.

TEI=0,

object: TRAU

range: 0...63

Terminal endpoint identifier of LPDLS, this attribute defines the TEI of the LPDLS resp. TRAU. In previous releases (up to BR4.5) the TEI had a fixed (i.e. not changeable) correspondence to the relative object number of the LPDLS resp. TRAU and was the only criteria used for the network element identity verification during the alignment procedure. From BR5.0 on the TEI can be explicitly set for every LPDLS by the parameter TEI. As with this new approach one and the same TEI can be used more than once within a BSC, another TRAU specific identity can optionally be used to unambiguously identify the TRAU during the alignment procedure: the Sales Unique Name (see command CREATE TRAU, parameter SALUNAME).

TSYNC=1000;

object: TRAU

unit: 10ms

range: 10..10000

default: 1000

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



Creating the LPDLS links:

< The LPDLS link is the LAPD channel for O&M Information between BSC 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 channel: 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 shall be assigned to. A “ LAPD Pool “ is a logical instance which represents a group of LAPD channels (LPDLM, LPDLR, LPDLS) that can be managed by one PPLD.

Each PPLD is responsible for one LAPD pool, thus the number of available LAPD pools is determined by the number of created PPLDs: If n PPLDs were created, n LAPD pools are available for assignment of created LPDLx channels. The relation between the created LAPD pools and the serving PPLD is variable and managed internally by the BSC (can be interrogated by the command GETINFO PLLD).

If the PPXL are used in a high capacity BSC, the parameter LAPDPOOL assumes the meaning of "primary PPXL" (i.e. the module no. of the PPXL where the LAPD must work if both PPXL are in service). If case of NTWSN16 or NTWSN64 the LAPDPOOL value does not have any relationship with the instance of the physical PPLDs equipped.

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

Creating the PCMA link:

< PCMA 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




BER=E10_3,

object: PCMA

range: E10_3, E10_4, E10_5

default: E10_3


CODE=HDB3,

object: PCMA

range: HDB3, AMI

default: HDB3

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

CRC=TRUE,

object: PCMA

range: TRUE, FALSE

default: FALSE

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

DEFPOOLTYP= NOT_DEFINED,

object: PCMA

range: NOT_DEFINED

POOL_1..POOL_13,

POOL_15.. POOL_35

POOL_42...POOL_48


New pool types in BR7.0!

Default pool type, this parameter is only relevant if the feature ‘pooling of A-interface TCH resources’ (see parameter EPOOL in command SET BSC [BASICS]) and defines the default type of pool assigned to every TSLA of the given PCMA. The different values for the pooling type are predefined and represent a certain combination of different ‘supported coding types’ for speech and data. For the different pooling types defined by GSM please refer to the table on the 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 1 FR data (12, 6, 3.6 kbit/s)

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

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

0000 0100 Circuit pool number 4 FR speech version 2 FR data (12, 6, 3.6 kbit/s)

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

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

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

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 1 FR speech version 2 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) HSCSD max 2 x FR data (12, 6 kbit/s)

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 1 FR speech version 2 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) HSCSD max 4 x FR data (12, 6 kbit/s)

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 2 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s)




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

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

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

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

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

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

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

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

0001 1101 Circuit pool number 29 FR speech version 1 FR speech version 2 FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR speech version 6 HR 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 1 FR speech version 2 FR speech version 3 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR speech version 6 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 1111 Circuit pool number 31 FR speech version 1 FR speech version 2 FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR speech version 6 HR 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 1 FR speech version 2 FR speech version 3 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR speech version 6 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)

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 1 FR speech version 2 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) HSCSD max 4 x FR data (14.5, 12, 6 kbit/s) EDGE max 2 x FR data (29.0 kbit/s) EDGE FR data (43.5 kbit/s) EDGE max 2 x FR data (32.0 kbit/s)

0010 0011 Circuit pool number 35 FR speech version 1 FR speech version 2 FR speech version 3 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR speech version 6 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 0100 Circuit pool number 36 FR speech version 4 FR speech version 5 HR speech version 4

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

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




0010 0111 Circuit pool number 39 FR speech version 1 FR speech version 2 FR speech version 3 FR speech version 4 FR speech version 5 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR speech version 4 HR speech version 6 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)

0010 1000 Circuit pool number 40 FR speech version 1 FR speech version 2 FR speech version 3 FR speech version 4 FR speech version 5 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR speech version 4 HR speech version 6 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)

0010 1001 Circuit pool number 41 FR speech version 1 FR speech version 2 FR speech version 3 FR speech version 4 FR speech version 5 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR speech version 4 HR speech version 6 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 1010 Circuit pool number 42 FR speech version 1 + CTM

0010 1011 Circuit pool number 43 FR speech version 2 + CTM

0010 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 + CTM FR speech version 2 + CTM HR speech version 1 + CTM

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

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

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



HCICN=0,

object: PCMA

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

0..2730

(if CICFM=NOTSTRUCT)

default: pcma-no.

High part of the CIC. The CIC (circuit identification code) is a 16bit-string used to address the PCMA-timeslot used for a traffic connection. The last 5 bits identify the timeslot (0..31), the first 11 bits are used to identify the PCM-link (0..2047). The HCICN determines the 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

Low bit error rate.

PCMT=0..0,

object: PCMA

range: trau-no.: 0..9

pcm-link-no.: 0..3

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

REMAL=CCITT;

object: PCMA

range: CCITT

BELLCORE

default: CCITT

Remote alarm.



Setting the uplink and downlink volumes for specific PCMA timeslots:

SET TSLA:

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

POOLTYP=NOT_DEFINED,

object: TSLA

range: NOT_DEFINED

POOL_1..POOL_13,

POOL_15..POOL_35

POOL_42...POOL_48


New pool types in BR7.0!

Pool type, this parameter defines the type of pool assigned to the TSLA (see also parameters DEFPOOLTYP (SET PCMA) and EPOOL (SET BSC [BASICS])). For the meaning of the different pooling types see the table in the command CREATE PCMA.

THROUGH=31,

object: TSLA

range: 1-31 (PCM30)

1-24 (PCM24)

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

VOLDL=12,

object: TSLA

step size: 1dB

range: 0..24

12 = normal link level

0 = 12dB attenuation

24 = 12dB amplification

default: 12

Volume downlink, determines the value for the timeslot volume in the 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 uplink, determines the value for the timeslot volume in the uplink (MS -> MSC) direction. The setting of VOLUL to 15 is used by some network operators because this setting was found the most suitable with respect to the subjective perception of test callers. Moreover, the volume adjustment has also been used to decrease echo effects which are mainly caused by the feedback within the housing of bag of the mobile phone.



Creating the PCMG link:

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

CREATE PCMG:

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

BAF=0,

object: PCMG

range: 0..255

default: 0


BER=E10_3,

object: PCMG

range: E10_3, E10_4, E10_5

default: E10_3


CRC=TRUE,

object: PCMG

range: TRUE, FALSE

default: FALSE

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

CODE=HDB3,

object: PCMG

range: HDB3, AMI

default: HDB3

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

LOWBER=0,

object: PCMG

range: E10_3, E10_4, E10_5, E10_6,

E10_7, E10_8, E10_9,

default: E10_3

Low bit error rate.



NUA=FALSE,

object: PCMG

range: TRUE, FALSE

default: FALSE


PCML=0-0-TRUNKA,

object: PCMG



0..3 (QTLP)

trunk TRUNKA, TRUNKB

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

Remarks on the term ‚trunk’: The PCMG links cannot be redundant, because the PCM redundancy is a proprietary feature of the BSS, and so it is used only in the interfaces Abis and Asub. In the A interface (PCMA) and in the Gb interface (PCMG) the redundancy is not allowed because this feature needs that it is handled on both peers, accordingly to specific rules. There is no standard management of the PCM redundancy in the specifications of the SGSN and of the MSC. Even though the PCMG cannot be redundant, nevertheless it can be configured in double trunk mode, although you cannot see this in the CREATE command. When a PCMG is created, the working mode is internally and implicitly set, in a way that is transparent to the operator, according to the value of the ASUBENCAP attribute of the BSC basic package. That is: if the ASUBENCAP is TRUE, this means 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 the operator, because in some cases it is desired to configure a PCMS in double trunk mode although it is not redundant, because in this way it will be possible to set the PCMS in duplex in the future, without deleting/creating the line. For the PCMG instead, for which the redundancy does not exist, it would be useless and wasteful to set a PCMG in double trunk mode: the second trunk would be wasted without reason.

In conclusion: if ASUBENCAP is TRUE, any PCMG shall be automatically 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 double trunk mode, and the second trunk cannot be used for another line.

REMAL=CCITT;

object: PCMG

range: CCITT

BELLCORE

default: CCITT

Remote alarm.



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

< The FRL functional object represents the 'Frame Relay Link' which is the physical link connection on the Gb interface. The Frame Relay Link connection can be realized via the A interface (PCMA) or directly to SGSN via a PCMG. In case of A interface connection the 64 kbit/s time slot are reserved on the PCMS and handled as transparent channel in the TRAU. >

CREATE FRL:

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

FRSTD=ITU,

object: FRL

range: ITU, ANSI, LMI

default: ITU

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

GLK=PCMG:0,

object: FRL

range: PCMA:0 - PCMA:191

PCMG:0 - PCMG:31

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

GTS=1&2,

object: FRL

range: 1-31

max. 31 values per FRL

linked with '&';

max. 64 timeslots per PCU

if PPXX is used,

max. 16 timeslots per PCU

if PPCU is used

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

Note: If the FRL object is created via PCMA (see parameter GLK), it has to be considered that the timeslots entered for GTS are also reserved for GPRS on the Asub. This again leads to the blocking of the A-interface timeslots that are associated to the selected Asub-channels depending on the used TRAU mapping principle (see parameter ALLCRIT in command CREATE TRAU). In the worst case, this means that 4 PCMA timeslots can no longer be used for CS traffic when one timeslot is used for the FRL object on the PCMA! The more timeslots are required for the FRL object the less useful it is to create the FRL via the PCMA!

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

N391=6,

object: FRL

range: 1-255

default: 6

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

N392=3,

object: FRL

range: 1-255

default: 3

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



N393=4,

object: FRL

range: 1-255

default: 4

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

PCUID=PCU:0,

object: FRL

format: path name of the PCU

range: PCU:0..PCU:11

Parameter name and format changed in

BR7.0 (name changed from PCUN to

PCUID)!

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

T391=10,

object: FRL

unit: 1s

range: 1-60

default: 10

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

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

TCONG=10,

object: FRL

unit: 1s

range: 1-30

default: 10

Congestion Timer, this parameter specifies the observation window for the congestion detection. If the number of frames coming from SGSN containing congestion is equal or greater than the number of frames indicating no congestion, the congestion state is notified to the upper layers.

TCONOFF=20;

object: FRL

unit: 1s

range: 0, 10, 20, 30

0 = no hysteresis time used

default: 20

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

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

< The NSVC (Network Service Virtual Connection) functional object represent the end-to-end communication between BSS and SGSN. At each side of Gb interface, there is one to one correspondence between NSVC and NSVL then the NSVL can be seen as an attribute of NSVC. >

CREATE NSVC:

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

NSVCI=1110,

object: NSVC

range: 0..65535

Network Service Virtual Connection Identifier, this parameter represents the common identification of the virtual connection between SGSN and BSS.

NSVLI=0..110;

object: NSVC

range: FRLN: 0..755

DLCIN: 16-991

Network Service Virtual Link Identifier, this parameter defines the association of the FR-DLCI (Data Link Connection Identifier) and the FRL (Frame Relay Link). It consists of two mandatory fields: FRLN and DLCIN.



Creating the BTS Site Manager:

< The BTS Site Manager represents the functionality that controls one 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 activation, this parameter is the equivalent of the parameter HRACTT1 (see command CREATE BTS [BASICS]) and defines an Abis traffic load threshold which is used for the following features:

a) BTSM Abis Load Dependent Activation of Half Rate b) Enhanced Pairing of half rate TCHs due to Abis TCH load c) AMR compression handover due to Abis TCH load

For all these features, the BSC calculates an Abis TCH traffic load for the Abis pool assigned to the BTSM. This ‘Abis pool’ is represented by all SUTSLB objects that are configured subordinate to the BTSM (for the exact definition of the term ‘Abis pool’ and the characteristics of the SUBTSLB objects please see command CREATE SUBTSLB). As the usage of the entered ABISHRACTTHR value depends on the feature used, the application of this threshold is separately described for each of the involved features:

a) Abis Load Dependent Activation of HR For the feature ‚Abis Load Dependent Activation of HR’ (see parameter EHRACT), ABISHRACTTHR defines a BTSM Abis traffic load threshold that is evaluated for the forced speech version selection for incoming TCH seizures. For this, the BSC compares ABISHRACTTHR to the percentage of busy Abis TCHs (related to the available Abis TCHs) within the pool of available Abis TCHs for the BTSM. For the feature CLDAHR the BSC calculates the Abis traffic load as follows

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

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

- (**) A SUBTSLB in usage state „busy“ (i.e. both HR subslots busy) is counted as 2 while a SUBTSLB in usage state „active“ (only one HR subslot busy) is counted as 1.

- The GPRS downgrade strategy (see parameter DGRSTRGY in the 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 subslots which are currently busy due to GPRS traffic are considered as ‘busy’ like any other Abis resources currently seized by CS calls. b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e. DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all Abis subslots which are currently busy due to GPRS 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, no matter which values are set for the DGRSTRGY parameter, as these subslots are in any case immediately preempted if a CS TCH request meets a TCH congestion situation.

If the calculated Abis TCH traffic load of the BTSM exceeds the percentage defined by ABISHRACTTHR, all incoming calls or incoming handovers to cells of the affected BTSM (for which HR is indicated as supported speech version) are forced to a HR TCH. This

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

no. of configured Abis pool TCHs



happens in all BTSs subordinate to the BTSM. If the Abis TCH traffic load of the BTSM is below the percentage defined by ABISHRACTTHR, all incoming calls are forced to FR or EFR (depending of the capability and preference indicated in the ASSIGNMENT REQUEST or HANDOVER REQUEST message). For further details please refer to the parameter EHRACT.

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

b) Enhanced Pairing of half rate TCH due to Abis TCH load The feature “Enhanced Pairing of TCH/H” (see parameter EPA in command SET BSC [BASICS]) transfers HR calls that currently occupy one HR subslot of a DR TCH (while the other subslot is still idle) in such a way that as many HR calls as possible share one Dual Rate TCH with another HR call. The enhanced pairing intracell handover is controlled exclusively by the BSC and is only triggered if either the percentage (within the pool of radio TCHs) of radio DR TCHs or/and radio FR TCHs in usage state “idle” has dropped below a definable threshold (see parameter HRACTT1) or/and the percentage (within the pool of Abis TCHs) of Abis DR TCHs or/and FR TCHs in usage state “idle” has dropped below a definable threshold. For enhanced pairing due to Abis TCH load, this threshold is based on the parameter ABISHRACTTHR: intracell handovers due to enhanced pairing are triggered if the following BTSM Abis pool traffic load condition is fulfilled:

Attention: - (*) An Abis TCH (SUBTSLB) is only considered as ‚idle’, if both HR subslots are idle.

- (**) For the ‘number of TCH configured in Abis pool’ each SUBTSLB is counted as ‘1’!


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

c) AMR compression handover due to Abis TCH load On every expiry of the timer TRFCT (see SET BSC) the BSC checks the current radio TCH load in its cells (see parameter HRACTAMRT1) and the current Abis TCH traffic load of its BTSMs and compares it to the threshold ABISHRACTTHR. For AMR compression handover (see parameter EADVCMPDCMHO in command SET HAND [BASICS]) the BSC calculates the BTSM Abis traffic load as follows



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

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

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

no. of Abis pool TCH in state unlocked/enabled





If the Abis traffic load of the BTSM exceeds the threshold ABISHRACTTHR, the BSC enables the AMR compression handover in 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 calls currently 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 thresholds HOTHAMRCDL and HOTHAMRCUL (see SET HAND [BASICS]).

ABISTRFHITHR=90,

object: BTSM

unit: 1%

range: 50..100

default: 90

Abis Traffic handover high threshold, this parameter is the equivalent to the paremeters TRFHITH (see SET HAND) and specifies the BTSM Abis traffic load threshold for enabling of traffic handover in the BTSM. For this feature, the BSC calculates a current BTSM Abis TCH traffic load for the Abis TCH pool. This pool is represented by all SUTSLB objects that are configured subordinate to the BTSM (see command CREATE SUBTSLB).

The traffic load of a cell is calculated as follows:





The BSC cyclically checks the BTSM Abis traffic load (controlled by the timer TRFCT, see SET BSC) in all BTSMs and compares it to the threshold specified by ABISTRFHITHR. If the Abis traffic load in the BTSM is above the BTSM-specific threshold ABISTRFHITHRR, the BSC activates the traffic handover in the those BTSs (subordinate to the BTSM) for which traffic handover is enabled in the database (see

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

no. of Abis pool TCH in state unlocked/enabled



parameter TRFHOE) by sending an LAPD O&M message SET ATTRIBUTE with the ‘traffic handover enabled’ indication to the BTSM. This O&M message is the trigger for the BTS to start the traffic handover decision algorithm (for more details concerning the handover decision please refer to the appendix ‚Handover Thresholds and Algorithms’). If the traffic handover was already enabled for a specific BTS on the previous expiry of TRFCT (either due to radio TCH load or due to Abis TCH load) and the radio traffic load in the affected BTS or/and the Abis traffic load of the BTSM are still above their threshold TRFHITH resp. ABISTRFHITHR, no further message is sent to the BTS and the traffic handover remains enabled in the affected BTSs. If the traffic handover was enabled for a specific BTS/BTSM on the previous expiry of TRFCT and both the radio traffic load in the affected BTS and Abis traffic load in the affected BTSM have dropped below the corresponding thresholds, the BSC disables the traffic handover in the affected BTSs by sending another LAPD O&M message SET ATTRIBUTE with the ‘traffic handover disabled’ indication to the BTSM.

ABISTRFLTHR=70,

object: BTSM

unit: 1%

range: 0.. 85

default: 70

Abis Traffic handover low threshold, this parameter specifies the maximum Abis traffic load a BTSM may have to accept incoming traffic handovers. The traffic load of a cell is calculated as follows:



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

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


When the BSC has enabled the traffic handover in a specific BTS (see parameters ABISTRFHITHR and TRFHITH) the BTS makes a traffic handover decision and – if a suitable target cell is found - sends an INTERCELL HANDOVER CONDITION INDICATION (HCI) with cause ‘traffic’ and a list of the determined target cells to the BSC. The BSC only activates a TCH in the target BTS, if the radio traffic load of this target BTS is below the threshold TRFLTH and if the Abis traffic load of the target BTSM is below the threshold ABISTRFLTHR. If the traffic load in the first target cell / target BTSM is above the threshold, the BSC checks the next target cell in the list and so on. If none of the target cells has a suitable load situation (i.e. if the cell traffic load > TRFLTH and/or Abis TCH load > ABISTRFLTHR ) the HCI does not lead to any successful handover completion - the next handover attempt HCI is then sent after expiry of TRFHOT (see SET HAND), if the handover conditions are still present.

Note: The BSC does not allow an incoming traffic handover towards a

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

no. of Abis TCH in state unlocked/enabled



BTS from another BTS within the same BTSM, if the Abis TCH load of that BTSM has exceeded the threshold ABISTRFLTHR. This means that it does not make any difference whether the originating cell 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 the transition to the 'BTSE emergency configuration' in case of breakdown of the BTSE primary power supply if a battery backup is available in the BTSE. The timer EMT1 is started when the alarm 'ACDC MAINS BREAKDOWN' occurs. If it expires the BTSE enters the 'BTSE emergency configuration'. 'BTSE emergency configuration' means that only the central BTSE control modules and the HW serving those TRXs which have been explicitly declared a 'Member of emergency configuration' (see parameter MOEC (CREATE TRX)) are powered. All other modules are switched off. The purpose of the 'BTSE emergency configuration' is to save energy as long as the BTSE is supplied by the battery backup and thus to delay the point of time when the battery runs out of current (BTSE power off). Note: BTSE emergency configuration can also be entered as a result of excessive shelter temperature in BS61 BTSEs (see explanation of parameter MOEC (CREATE TRX)).

EMT2=0,

object: BTSM

unit: 1min

range: 0..360

0 = switch to 'zero carrier

configuration' disabled.

default: 0

Emergency timer 2, this parameter indicates the delay for the transition to 'BTSE zero carrier configuration' in case of breakdown of the BTSE primary power supply if a battery backup is available in the BTSE. The timer EMT2 is started when the BTSE enters the 'BTSE emergency carrier configuration'. If it expires the BTSE enters the 'zero carrier configuration'. 'BTSE zero carrier configuration' means that only the central BTSE control modules are powered. All other modules are switched off (call processing disabled). The purpose of the 'BTSE zero carrier configuration' is to keep the central control modules available if microwave-equipment is used. If no microwave equipment is used the 'zero carrier configuration' should be disabled (EMT2=0). Note: All BTSE types also enter the 'zero carrier configuration' if the alarm 'RACK OVERTEMPERATURE' is raised. This behaviour is not administrable.

EXPSWV="01-01-08-00..07-00_98-7-21",

object: BTSM

Expected SW version, this parameter determines the SW version which should be loaded and running in the BTSE from the BSC's point of view. This SW load must be available and loaded in the BTSE. If during the alignment between BSC and BTS a different SW version than the expected one is detected, the expected SW load is immediately activated if it is available on the BTSE flash EPROMs. If it is not available an automatic download of this SW version from the BSC to the BTSE is initiated.

FLAPDOVLTH=80-70,

object: BTSM

format: firstLevelUpperThreshold -

firstLevelLowerThreshold unit: 1%

range: 10..100

default: firstLevelUpperThreshold: 80

firstLevelLowerThreshold: 70

First LAPD overload threshold, this parameter represents the first load level thresholds of the BTSE Radio Signalling links (LPDLRs). It consists of two fields: The fields of this attribute of type sequence are: - firstLevelUpperThreshold if the signalling traffic exceeds this threshold the BTSE suspends sending MEASUREMENT RESULT (MEASUREMENT REPORT) messages on the Abis. - firstLevelLowerThreshold if the signalling traffic drops below this threshold the BTSE resumes sending MEASUREMENT RESULT (MEASUREMENT REPORT) messages on the Abis.

The MEASUREMENT RESULT resp. MEASUREMENT REPORT messages are neither necessary for call processing nor for performance measurements. The sending of these messages can be optionally enabled using the parameter RADIOMR (see command CREATE/SET TRX) for test or monitoring purposes. If these messages are sent, they lead to a drastic increase of the uplink load on the LPDLR links. For this reason they are suspended in case of



LAPD overload.

Note: - If IMSI Tracing (see command CREATE TRACE) or Cell Traffic Recording (CTR, see command CREATE CTRSCHED) is enabled, the BTS also sends MEASUREMENT REPORT messages. The difference is that in this case the MEASUREMENT REPORTs are not embedded in the MEASUREMENT RESULT but in the TRACE MEASUREMENT RESULT messages. The sending of these messages is not suspended if the LAPD load exceeds FLAPDOVLTH. - Further parameters related to LAPD overload are SLAPDOVLTH, LAPDOVLT (CREATE BTSM) and DLAPDOVL (see command SET BSC [BASICS]). - The BTSE LAPD Overload thresholds are only used by BTSEs of the generation BTSplus.

GASTRABISTH=10..20..0..10,

object: BTSM

format: thresholdAbisHV -

thresholdAbisVH -

thresholdIdleAbisSU -

thresholdIdleAbisRU unit: 1%

range: 0..100

default: thresholdAbisHV: 10

thresholdAbisVH: 20

thresholdIdleAbisSU: 0

thresholdIdleAbisRU: 10

GPRS allocation strategy Abis thresholds, this parameter is the Abis equivalent to the parameter GASTRTH (see CREATE PTPPKF) used to control the switch from/to vertical/horizontal allocation strategy and the stop/restore of PDCH upgrading due to Abis scarcity. 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 the vertical allocation strategy due to Abis scarcity is activated. If vertical allocation is activated, new TBFs are preferably multiplexed on already used PDCHs. This implies that the related Abis subslots are also shared and results in saving Abis resources.

The second field (thresholdIdleAbisVH) defines the percentage of idle Abis subslots (related to the available Abis subslots) over which the horizontal allocation strategy is activated again (if also the thresholds for the radio resources allow that – see GASTRTH in object PTPPKF).

The third field (thresholdIdleAbisSU) defines the percentage of idle Abis subslots (over the available Abis subslots) under which the PCU stops sending Abis upgrading requests towards the TDPC. When this threshold is reached, the first allocation of Abis resources to a TBF is performed with the same criteria used under normal conditions (looking at the candidate’s initial coding scheme), but further upgrading of Abis resources is forbidden. The main purpose of this parameter is to avoid oscillating allocation/preemption cycles in case of Abis shortage, thus increasing the signaling load of the system due to multiple reconfiguration activities. E.g.: If only very few Abis resources are available (1 or 2 subslots), these are better kept free for incoming CS traffic instead of first upgrading a running TBF and then pre-empting it again to serve the CS call. ThresholdIdleAbisSU=0 means that the upgrade of TBF resources is stopped only after no Abis resources were left at all – the resumption of upgrades is then triggered with the below parameter.

The fourth field (thresholdIdleAbisRU) defines the percentage of idle Abis subslots (over the available Abis subslots) over which the Abis upgrade requests towards the TDPC are allowed again.

Constraints on the Abis thresholds are:

thresholdIdleAbisSU <= thresholdIdleAbisRU;

thresholdIdleAbisHV <= thresholdIdleAbisVH.

Note that there is no constraint between the Abis threshold to switch to vertical allocation and the Abis threshold to disable the ‘Abis upgrade requests’; the operator is free to set the one lower than the other, and vice versa.



LAPDOVLT=10,

object: BTSM

unit: 1s

range: 1..60

default: 10

LAPD overload timer, this parameter defines the time to pass between two consecutive LAPD OVERLOAD indication messages. These messages are sent on the LAPD O&M link (LPDLM) when the LAPD 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 the thresholds FLAPDOVLTH and SLAPDOVLTH are only used by BTSEs of the generation BTSplus.

Please see also parameter DLAPDOVLH in command SET BSC [BASICS]).

LPDLMSAT=FALSE,

object: BTSM

range: TRUE, FALSE

default: FALSE

LPDLM via satellite, this attribute indicates whether the Abis resp. LPDLM is realized via satellite link (TRUE) or not (FALSE). If the Abis interface link is configured as satellite link, the generally higher signal delay must be particularly taken into account by the LAPD layer 2 functions of the BTS O&M link (LPDLM) and the BTS radio signalling links (LPDLR). Setting LPDLMSAT=TRUE has the following effects: The LAPD timers T200 and T201 (waiting timers for LAPD acknowledgement frames) as well as the associated window sizes (the 'window size' is simply the number of I-frames that may be sent without any acknowledgement from the opposite side) are automatically extended according to the following table:

These settings ensure that the higher signal delay on the link does not lead to unnecessary retransmission of LAPD layer 2 frames. Notes: - The satellite mode of the Abis link has to be activated in the BTSE as well. This is done by the parameter ABISLKSAT in the command SET BTSM (at the BTSE LMT). The effect is the same as described above - just for the opposite direction. - Since the implementation of CR2716 in BR7.0 (TDPC patch T1340148) the setting LPDLMSAT=TRUE has an effect on call processing: To reduce the delay between the CHANNEL REQUEST and the IMMEDIATE ASSIGNMENT COMMAND messages, the BSC sends the IMMEDIATE ASSIGNMENT message immediately after sending the CHANNEL ACTIVATION message, without waiting for the CHAN ACT ACK. Thie means that the BSC saves the time for the completion and acknowledgement of the (satellite-link-delayed) Abis channel activation procedure. As this procedure has an expected success rate of 100% (it is only unsuccessful if the BTS itself has a serious problem) it is not mandatory to wait for a positive acknowledgement before the IMMEDIATE ASSIGNMENT message can be sent. This approach drastically reduces the RACH retransmissions due to delayed IMMEDIATE ASSIGNMENT and thus avoids unnecessary load on the SDCCHs. - If an Abis is realized via satellite link (or has a considerably increased delay due to other transmission equipment) it is strongly recommended to set the parameter NSLOTST (see SET BTS [CCCH]) to ‚14’ to achieve the longest possible RACH retransmission cycle. This avoids unnecessary retransmissions that lead to unnecessary SDCCH seizures and thus to a decrease of the Immediate Assignment Success Rate (or even SDCCH congestion). - When an Abis interface is configured via satellite, it is urgently recommended to configure multiple SDCCH channels on different TRXs. This is necessary because the Abis LAPD transmit queues in the BTS are managed per TRX(TEI), i.e. each TRX (TEI) has an own transmit queue. As the biggest percentage of all signalling activities in



a cell are processed via the SDCCHs, it is recommended, to avoid an excessive concentration of the SDCCH signalling within one TRX (and thus one LPAD transmit queue), to distribute multiple SDCCHs over different TRXs within the cell. Otherwise the probability of the BTSE alarm ‘LAPD TRANSMIT QUEUE OVERFLOW’ will considerably increase, although with a more even distribution of the signalling load over the TEIs this could be avoided. - Also the Asub interface and the A interface (parameter ASUBISAT in command SET BSC[BASICS]) can be configured as satellite link. However, only one of the mentioned interfaces should be configured as satellite link at the same time, because multiple satellite links within a BSS may cause an overall message and procedure delay that might lead to expiry of procedure supervision timers that are normally adapted to the propagation delay of terrestrial signalling links or at least to only one satellite link in the path. Although multiple satellite links are not officially tested and released, the BSC command interpreter and DBAEM do not perform any checks to avoid multiple satellite links - it is up to the operator to follow this rule.

OMLAPDRT=30,

object: BTSM

unit: 1s

range: 3-300

default: 30

O&M LAPD 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. BCCH active) on the BTSE will not be blocked as long as this timer runs. When the timer expires the BTSE call processing is blocked and functional related Managed Objects are deleted. In this case a full alignment 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 starts the timer OMLAPDRT and the BSC starts the timer SHLAPDIT. If the OMLAPDRT expires the BTSE blocks the call processing. On link reestablishment the BTSE forces the BSC to perform a full Abis alignment if one of the two timers has expired. If none of the two timers expires, the BSC performs a ‘Short Abis Alignment’.

Application: The timers SHLAPDIT and OMLAPDRT are relevant for a) LAPD interruption due to PPLD switch b) LAPD interruption to a certain BTSE within a multidrop chain. Here it has to be considered that the failure of the PCMB object (i.e. PCM link error between BSC and the first BTSE in the chain) always leads to a full alignment of all BTSEs in the chain after link recovery. If the PCM link error occurs between two BTSEs in the chain a full alignment is avoided if the link comes up before expiry of SHLAPDIT. Notes: - OMLAPDRT should always be greater than SHLAPDIT since a fast alignment (SHLAPDIT not yet expired when the layer 2 comes up) only makes sense if call processing has not been blocked by the expiry of OMLAPDRT before! - For both timers some additional delay time for the detection of the layer 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 connection for the BTSM, i.e. it indicates to which BTSM port it is connected. Depending on the LPDLM configuration two cases must be distinguished: a) If only one LPDLM is configured for the BTSM, PCMCON0 indicates which PCMB carries the LPDLM. b) If more than one LPDLM is configured for the BTSM, PCMCON0 indicates which PCMB carries LPDLM:0.

Notes: - Port numbers specified in all PCMCONx (x = 1..4) attributes must be compatible with the BTS hardware version, as shown in the table below:

The values PORT_2, PORT_4 or PORT_6 can be selected only if the object COSA is installed; with object COBA installed only the value PORT_0 can be selected. The hardware object PORT_<n> corresponds to the object BPORT:<n>. At the BTSE side, the BPORT object must be previously created by means of the CREATE BPORT command.

- Please see also command CREATE SUBTSLB.

PCMCON1=<NULL>,

object: BTSM


portNumber1


PCMB_nnn

portNumber1:

PORT_m

default: <NULL>

PCM connection 1, this attribute indicates the first auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected. Depending on the LPDLM configuration two cases must be distinguished: a) If only one LPDLM is configured for the BTSM, PCMCON1

indicates 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 HW of the BTSE (please refer to the ‘Notes’ in the description of PCMCON0, see above).

PCMCON2=<NULL>,

object: BTSM


portNumber2


PCMB_nnn

portNumber2:

PORT_m

default: <NULL>

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


PCMCON3=<NULL>,

object: BTSM


portNumber3


PCMB_nnn

portNumber3:

PORT_m

default: <NULL>

PCM connection 3, this attribute indicates the third auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected.




SALUNAME=”BSC1BTSE0”,

object: BTSM


(11 characters)

in quotation marks


Sales Unique Name, this attribute defines every Network Element by its unique symbolic name. It can be optionally used for the network element identity verification during the alignment phase in addition to the TEI (see parameter TEI). In previous releases (up to BR4.5) the (LPDLM-)TEI was the only criteria used for the network element identity verification during the alignment procedure. The new approach using the Sales Unique Name in addition to an individually configurable TEI allows a much higher flexibility in the allocation of the BTSEs to the BSCs (with minimization of efforts in case of BTSE swap) without loss of safety.

SHLAPDIT=5,

object: BTSM

unit: 1s

range: 3-20

default: 15

Short LAPD interruption timer, this parameter represents a BSC timer which is started after the detection of a LAPD interruption on the 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 of SHLAPDIT (<entered value> + 30s) all calls in the affected BTSE are released and a ‘full alignment’ is performed after link recovery. If the LAPD link comes up again before the timer expires only a ‘fast alignment’ procedure is started. ‘Fast alignment’ is a subset of the ‘full alignment’ and comprises only the state alignment and the alarm alignment, but not the creation of functional objects. Please see also the explanation for OMLAPDRT. This timer is also used for supervision of RSL. If an RSL fails for longer than this time limit (O&M link survives) only the channels of the affected TRX are released. Important Note: The actual 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 the second load level thresholds (in percentage) of the BTSE Radio Signalling links (LPDLRs). It consists of two fields: - secondLevelUpperThreshold if the signalling traffic overcomes this threshold the BTSE starts the periodic sending of LAPD OVERLOAD messages. - secondLevelLowerThreshold if the signalling traffic falls below this threshold the BTSE stops periodic sending LAPD OVERLOAD messages.

These messages are sent on the LAPD O&M link (LPDLM) when the LAPD load threshold defined by SLAPDOVLTH is exceeded and indicate the LAPD overload per TRX. The time period between two consecutive LAPD OVERLOAD indication messages is determined by the parameter LAPDOVLT.

Notes: - Further parameters related to LAPD overload are FLAPDOVLTH, LAPDOVLT (CREATE BTSM) and DLAPOVL (see command SET BSC [BASICS]). - The BTSE LAPD Overload thresholds are only used by BTSEs of the generation BTSplus. - If the exceeding of SLAPDOVLTH triggers the sending of LAPD OVERLOAD messages towards the BSC and the parameter DLAPDOVL (SET BSC [BASICS]) is set to TRUE, the BSC starts traffic reduction measures as described in the section ‘BTS overload’ in the chapter ‘BSC, MSC and BTS Overload handling’ in the appendix of this document.



TEI=0;

object: BTSM

range: 0...63

Terminal endpoint identifier of LPDLM, this attribute defines the TEI of the LPDLM resp. BTSM. The TEI is the basic criteria used for the network element identity verification during the alignment procedure. In previous releases (up to BR4.5) the TEI had a fixed (i.e. not changeable) correspondence to the relative object number of the LPDLM resp. BTSM (i.e. BTSM/LPDLM-no.=TEI-no.). This approach had the disadvantage that in case of BTSE swap the TEI had to be manually changed in the BTSE to the new LPDLM-no. in the new BSC. As a temporary solution, the parameter FIXTEI was introduced which allowed to set all TEIs of the BTSMs to ‘0’. The parameter FIXTEI was removed in BR5.0 as from BR5.0 on the TEI can be explicitly set for every LPDLM by the parameter TEI. Thus in case of a swap of BTSE from one BSC to another, the TEI can be easily set in the database of the new BSC by the SET BTSM command without any necessity to modify the BTSE data on site. As with this new approach one and the same TEI can be used more than once within a BSC, another BTSE specific identity can optionally be used to unambiguously identify the BTSE during the alignment: the Sales Unique Name (see parameter SALUNAME).



Creating the LPDLM links:

< The LPDLM link is the LAPD channel assigned to a BTS Site Manager 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 channel: pcmb-no. - timeslot (- subslot).

The Abis timeslot which is configured as LPDLM ais always used - as LPDLM for O&M signaling between BSC and BTSM and - as LPDLR for the call processing signalling communication (via Radio Signaling (RSL) messages) between BSC and a particular TRX.

The distinction between LPDLM messages and LPDLR radio signalling (RSL) messages is based on the LAPD layer 2 addressing scheme which uses the SAPI (Service Access Point Identifier) and TEI (Terminal Endpoint Identifier). LPDLM signalling is always addressed with SAPI=62, while Abis RSL messages are always addressed with SAPI=0. For further details, please refer to the parameters TEI (in command CREATE BTSM) and LPDLMN (in command CREATE TRX).

Configurations with multiple 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 be sent are distributed over all available LPDLMs. Every LPDLM created for a particular BTSM also carries the LPDLR signalling information related to the TRXs subordinate to the BTSM and the associated BTSs. The loadsharing among the created LPDLMs is based on a ‘preference’ which is defined per TRX/LPDLR, i.e. for each TRX the ‘preferred’ LPDLM indicates via which LPDLM (and thus via which physical Abis timelot) the associated LPDLR signalling messages shall be exchanged (see parameter LPDLMN in command CREATE TRX).

LPDLM link selection management for LPDLR messages in case of failure of one LPDLM When an LPDLM fails, the BTS performs a re-distribution of the LPDLRs over the LPDLM timeslots which are still available, i.e. the BTS 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 are distributed over the available LPDLM links as evenly as possibly, i.e. the number of LPDLRs handled by each LPDLM is more or less the same. When the failed LPDLM returns to service, the BTS switches those LPDLRs, for which the failed LPDLM was the “primary” one, back to the original (primary) LPDLR/LPDLM allocation. However, to avoid frequent LPDLR switchovers, this happens at the earliest 30 seconds after the failed LPDLM has returned to service. During the switchover RSL message can be lost. The associated BTS call processing subsystems (for Radio Link Control and Channel Control) are not informed about the loss of single RSL messages. Moreover, for the switchover process there is no difference in the handling between LPDLRs associated to a BCCH-TRX or non-BCCH TRX. The BSC just registers the layer 2 connection setup by the BTSE and routes the messages adressed to a particluar TRX to the associated LPDLM timeslot.

After a failure of all LPDLMs the BSC decides which of the configured LPDLMs is used for the Abis Alignment Procedure.

Note: For each LPDLM created in the BSC, the corresponding



counterpart has to be created in the BTSE using the command CREATE LAPDLE.

LAPDPOOL=0;

object: LPDLM

range: 0..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 shall be assigned to. A “ LAPD Pool “ is a logical instance which represents a group of LAPD channels (LPDLM, LPDLR, LPDLS) that can be managed by one PPLD or PPXL

Different distribution principles apply in case of PPLD and PPXL as follows:

Meaning of LAPDPOOL for configuration with PPLD Each PPLD is responsible for one LAPD pool, thus the number of available LAPD pools is determined by the number of created PPLDs: If n PPLDs were created, n LAPD pools are available for assignment of created LPDLx channels. The relation between the created LAPD pools and the serving PPLD is variable and managed internally by the BSC (can be interrogated by the command GETINFO PLLD). The following example configuration may illustrate the principle:

Basically, if the LAPDPOOL parameter is skipped during the LAPD channel creation, the BSC automatically assigns the LPDLx to one of the existing LAPD pools by an internal distribution algorithm (this was the only possible way in releases < BR6.0). This has the disadvantage that the created LPDLx channels might not be distributed over all equipped PPLDs (some of them might remain in state “ cold standby “ which means that the PPLD is neither serving any LPDLx channels nor the spare PPLD.) With the parameter LAPDPOOL the operator has the possibility to control the distribution of LAPD channels among the PPLDs and to ensure an even distribution of the LPDLx over all equipped PPLDs, achieving a minimum impact on the LAPD channels in case of PPLD failure. In this case (i.e. with NTWCARD=NTWSN16, see command SET BSC [BASICS]) the LAPDPOOL value does not have any relationship with the instance of the physical PPLDs equipped.

Meaning of LAPDPOOL for configuration with PPXL If PPXL boards are used (high capacity BSC HC-BSC, NTWCARD=NTWSNAP or NTWSNAP_STLP), the parameter LAPDPOOL can only assume the value 0 or 1. In a HC-BSC two PPXL boards are available, both of them are in service and serve a number of LAPD channels. If one of the PPXLs fails, the remaining PPXL board immediately takes over the LAPD channels of the failed one. This means that in case of HC-BSC the parameter LAPDPOOL assumes the meaning of "primary PPXL", i.e. the module no. of the PPXL which serves the LAPD channel by default (i.e. when both PPXL are in service).

LPDLS:0

PPLD:0 PPLD:1 PPLD:13

LPDLS:1

LPDLM:5 LPDLM: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 Allocation - Feature background and reason for introduction The high data rates enabled by the 8-PSK modulation for EDGE respectively EGPRS and the introduction of the additional high coding schemes (CS3 and CS4, see parameters CSCH3CSH4SUP in command SET BSC and CREATE BTS) for GPRS require the concatenation of up to 5 Abis TCHs for only one used Um radio TCH.

The following table shows the relationship between the number of 16kbit/s subslots on Abis and the coding schemes:

Coding Scheme Number of 16kbit/s

subslots

CS-1 1

CS-2 2

CS-3 2

CS-4 2

MCS-1 1

MCS-2 2

MCS-3 2

MCS-4 2

MCS-5 2

MCS-6 3

MCS-7 4

MCS-8 5

MCS-9 5

As the table shows, it is required, depending on the coding schemes, to concatenate up to 5 16kbit/s Abis TCHs to one Um radio TCH. Considering this precondition, the fixed allocation of Um radio TCHs to Abis TCHs, which was used up to BR6.0, is no longer sufficient and efficient, as it would require an Abis configuration according to the highest possible data rates. To avoid a waste of Abis TCH resources, BR7.0 provides a flexible and dynamic allocation of Abis TCHs, which is applied to both GPRS and CS calls. In correspondence with the service type, the BSC dynamically allocates the appropriate number of Abis TCHs to a particular call. As the capacity of each Um radio TCH can vary during runtime, the dynamic Abis allocation adapts the Abis capacity to the required air interface capacity.

New object SUBTSLB Due to the introduction of the feature ‘flexible Abis allocation’ in BR7.0 the fixed association of Um radio TCHs to a particular terrestrial Abis timeslot (and thus the ‘terrestrial channel’ parameter (TERTCH) in the CREATE CHAN command) was removed. To define the terrestrial Abis timeslots, a new database object called SUBTSLB (sub-timeslot on Abis) was introduced, which represents a physical terrestrial 16 kbit/s channel on one of the Abis links towards a particular BTSM. From BR7.0 on each terrestrial Abis timeslot must be created by an own CREATE SUBTSLB command.

Allocation principles of Um radio TCHs and Abis radio TCHs With the feature ‘flexible Abis allocation’ respectively ‘dynamic Abis allocation’ the Um radio TCHs of any BTS within the BTSM can be dynamically interconnected to any of the SUBTSLB assigned to the BTSM on a per-call base. For this, the BTS provides a switching matrix functionality which allows an individual throughconnection of Abis TCH resources towards Um radio TCH resources. The switching functionality, however, is restricted to interconnection or 16kbit/s Abis timeslots and full radio channels (full rate or dual rate), i.e. it is not possible to interconnect any HR subslot on the Abis to any other HR



sublot on the radio interface. In other words, the two associated HR subslots a particular radio timeslot can only be interconnected to the two associated HR subslots of a particular Abis timeslot, i.e. a HR TCH pair on the Um is always connected to a HR TCH pair on the Abis.

Both the Um radio TCH resources and the Abis TCH resources are managed and controlled by the BSC, i.e. the BSC keeps track on the availability state (enabled, disabled) and usage state (idle, busy or active) of each Um radio TCH and each Abis TCH, and determines for each TCH seizure request (call setup for CS and GPRS, incoming handovers etc.) which Um radio TCHs and Abis TCHs shall be interconnected by the BTS. The BSC sends the associated resource data (i.e. channel type , timeslot number etc.) of the selected radio TCH(s) and Abis TCH(s) to the BTS in the CHANNEL ACTIVATION message which then performs the necessary throughconnection.

The amount of allocated 16 kbit/s Abis resources per radio timeslot depends on several factors, first of all the service type. The next table shows how, depending on the service type, a single Um radio TCH must be interconnected to Abis TCH resources.

Required Abis capacity

1 x 16 kbit/s

1/2 x 16 kbit/s (= 8 kbit/s)

n x 16 kbit/s (n = 2..5)

Service

type

- FR CS speech

- EFR CS speech

- AMR FR CS speech

- CS data

- GPRS (CS1 and CS2 only)

- HR CS speech

- AMR HR CS speech

- EGPRS (MCS1 to MCS9)

- GPRS (CS3 and CS4)

For GPRS and EGPRS several Abis TCHs resources may be used to carry their (n) concatenated PCU frames. The number (n) of concatenated PCU frames depends on the coding scheme used for radio block transmission.

In case of a GPRS/EGPRS connection the BSC can adjust the Abis capacity according to Link Adaptation, and it signals modifications with respect to the initial radio / Abis association to the BTS. (which message???) For example, in case one Temporary Block Flow (TBF) applies the coding scheme MCS7, then 4 Abis resources get assigned. Thus the Abis capacity is adapted, according to Link Adaptation. If during the TBF lifetime the Link Adaptation algorithm leads to a higher coding scheme, e.g. MCS9, an additional Abis resource is dynamically allocated. In contrast, if the Link Adaptation algorithm leads to a lower coding scheme, e.g. MCS6, superfluous Abis resources are released. In order to avoid continuous sequences of allocation and release, any release and allocation of Abis capacity is not immediately executed, but follows after distinct timeout.

Pooling Concept of Abis TCH resources Every 16kbit/s Abis timeslot is an object subordinate to an existing PCMB. The relation of SUBTSLB and PCMB is implicitly defined in the object instance path name within the NAME attribute of the SUBTSLB object (see below), the relation of the SUBTSLB object to the BTSM is indirectly defined by the parameter ASSLAPD (see below). The relation of a BTSM to the PCMBs is defined by the parameters PCMCON0..PCMCON3 (see command CREATE BTSM).

All SUBTSLBs which are in this way created for (and thus assigned to) a particular BTSM make up the pool of Abis TCH resources that can be used to serve TCH requests (CS calls, GPRS calls, incoming handovers etc.) that are set up in the BTSs subordinate to the BTSM. In other words, the BTSs of the BTSM share the same Abis TCH



resources pool which is also called ‘Abis pool’.

In more detail, the pooling concept of the feature dynamic Abis allocation 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 ‘Abis subpool’ 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 is associated to a specific LPDLM. This relation of Abis TCH resources to a specific LPDLM channel (which always also carries the LPDLR signaling) is not call processing oriented, i.e. there is no whichever relation between the LPDLR call processing signalling within the LPDLM channel and the Abis TCHs in the associated Abis subpool. Instead, the purpose of the associated LPDLM (also called ‘control LAPD’) is to guarantee a suitable O&M supervision of the availability of the Abis TCH resources belonging to the Abis subpool. In other words, whenever the ‘control LAPD’ is out of service (e.g. due to failure of the PCMB link, the BSC considers the associated Abis resources (i.e. the complete Abis subpool) out of service, and the BSC immediately excludes them from the Abis pool and thus from the dynamic Abis allocation. As soon as the ‘control LAPD’ is in service again the associated Abis subpool is put in service again and the associated abis TCH resources are available again for dynamic Abis allocation. The failure of PCM lines affects only Abis resources, while radio channels may continue to be assigned to new incoming calls, as long as there is some available 16kbit/s Abis resource on the remaining PCMB lines. This is possible because the LPDLR radio signalling for a particluar TRX/radio TCH can be performed via any of the remaing LPDLM timeslots, if the LPDLM which was defined as the ‘preferred’ LPDLM for a particular TRX has changed its state to ‘disabled’ (for further details please refer to the parameter LPDLMN in command CREATE TRX).

Summary: - An ‘Abis pool’ consists of all SUBTSLB objects that are assigned to the same BTSM. The association of a particular SUBTSLB object to a BTSM is implicitly defined within the path name included in the parameter ASSLAPD (see below). - An ‘Abis subpool’ consists of all SUBTSLB objects that are assigned to the same BTSM and the same LPDLM. The association of a particular SUBTSLB object to a BTSM and the LPDLM is implicitly defined within the path name included in the parameter ASSLAPD (see below). Typically the different Abis subpools that belong to the same BTSM are created on different PCMB lines to achieve a better availabilty resp. failure safety of the Abis pool.

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



The following further notes on properties and relation of Abis pools and 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 separate LPDLM channel. - Abis subpools can be freely distributed over all PCMB lines that belong to a BTSM (see parameters PCMCON0..PCMCON3), at least one subpool must be created per PCMB line. - The Abis subslots allocated (interconnected) to a Um radio TCH may be distributed over different Abis subpools and consequently over different PCM lines. It is not necessary to guarantee that the subslots are adjacent. - Different Abis pools and Abis subpools must not overlap.

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

Guaranteed minimum percentage of Abis pool TCHs per BTS To avoid a stop of call handling due to excessive traffic volume demands 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 the minimum percentage of ‘in service’ Abis subslots (i.e. SUBTSLBs in state ‘unlocked/enabled’) of the Abis pool that shall in any case be kept available for allocation for this cell (BTS).

BTSM:0

BTSM:0 subpool 1

BTS:0

BTS:1

BTS:2

C O R E

BTSM:1

BTS:0

BTS:1

BTS:2

C O R 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 directly adjacent to the pool TCHs, it must only be on the same PCMB)

L*

B S C



CREATE SUBTSLB:

NAME=PCMB:0/TSLB:2/SUB

TSLB:0, Object path name.

ASSLAPD= BTSM:0/LPDLM:0,

object: SUBTSLB

format: object instance path name of

the associated LPDLM,

BTSM:n/LPDLM:m

Associated LAPD, this parameter defines the so-called ‘associated LAPD channel’ of a particular SUBTSLB (Abis TCH). The values entered 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 object to 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. these SUBTSLBs are the Abis TCH resources that can be dynamically used for CS and GPRS TCH requests for cells (BTSs) belonging to that BTSM.

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

For further details pleas refer to the explanations given in the command 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 to Common Control Channels are set. >

CREATE BTS [BASICS]:

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

NAME=BTSM:0/BTS:0, Object path name. Due to the new object architecture (the BTS object 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 Full 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 Multirate (AMR)

General background Adaptive Multi Rate (AMR) is a feature that introduces new speech versions 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, which consists of the speech versions “AMR Full Rate” and “AMR Half Rate”. The differences between AMR and the older GSM Speech Versions (FR, EFR, HR) is that in case of AMR the used Speech Codec is not statically set for each assigned TCH but permanently adapted to the current radio conditions. The basic principle is: the better the radio interface quality, the higher the available bandwidth (bitrate) for the speech coding and the smaller the bandwidth (bitrate) for channel coding and vice versa (‘Channel Coding’ is the term that represents the radio transmission error protection overhead, while ‘Speech Coding’ represents the coding of the speech signal itself).

Active CODEC Set (ACS) Both the speech versions AMR FR and AMR HR consist of a so-called “Active CODEC Set (ACS)”, which is a set of up to 4 AMR speech CODECs resp. speech coding schemes, which are defined in each BTS by the parameters AMRFRC1..AMRFRC4 (for AMR FR) and AMRHRC1..AMRHRC4 (for AMR HR). If the ACS for AMR FR shall consist of only 3 AMR CODECs, then AMRFRC4 must be set to <NULL>, if it shall consist of only 2 CODECs, then AMRFRC3 must be set to <NULL> and so on. For AMRFRC1 the value <NULL> is not allowed, as at least one CODEC must be defined within an ACS.

Channel Coding Speech Coding good radio conditions

Channel Coding Speech Coding poor radio conditions



For 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/s RATE_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

For 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/s

In any case, the following rule must be followed:

RATEAMRFRC4 > RATEAMRFRC3 > RATEAMRFRC2 > RATEAMRFRC1

AMR link Adaptation When an AMR call has been set up, both the BTS and the MS continuously evaluate the radio interface quality: the MS measures the downlink quality in the same way as it does for the regular measurement reporting and the BTS derives quality values from the uplink BER measurements. Depending on the results of these quality measurements, the MS (for the downlink) and the BTS (for the uplink) intiate the selection of a suitable AMR CODEC from the Active CODEC 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 downlink is controlled by the MS and is based on the C/I (Carrier to Interference) thresholds, which are administrable 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 CODECs used within the ACS and the thresholds and hysteresis values for the downlink 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 uplink is controlled by the BTS and is based 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 the tuning parameter AMRLKAT (see below).

Link adaptation Signalling The change of the CODEC is signalled in-band by 2 specific bits within the Um speech frames (allowing the adressing of 4 CODECs in the ACS). Moreover, as each AMR CODEC has its own TRAU frame format, each change of the AMR CODEC means a change of the type of TRAU frame that is to be used between the BTS and the TRAU. 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 CMR is to request a CODEC that shall be used for the downlink direction. If DTX is not used, the CMR is continuously sent from the MS to the BTS even if no change of the current CODEC is required. If the CMR request is correctly received by the BTS, the BTS requests the corresponding 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 for



the downlink direction are sent from BTS to the TRAU within uplink TRAU frames to request the TRAU frame type in correspondence with the CODEC required by the CMR from the AMR MS. The CMC is sent to the TRAU after an averaging process in the BTS (see parameter AMRACMRDL in command SET HAND [BASICS]): The size of the associated ‘averaging window’ for this process is defined in CODEC Mode Requests (CMRs), i.e. the BTS only instructs the TRAU to change the current downlink CODEC mode, if a sufficient number of corresponding CMRs received from the MS have confirmed the request to change the CODEC. CMCs for the uplink direction are sent from BTS to the MS in the downlink bursts in order to indicate which CODEC the MS shall use for the uplink speech frames.

CODEC MODE INDICATION (CMI) The CMIs are sent by MS, TRAU and BTS. CMIs are sent within the TRAU frames as well as in the UL and DL speech frames. The purpose of the CMI is to indicate which type of CODEC is currently used by the sending side, as the same CODEC must be used to correctly decode the received speech signal resp. TRAU frame. The BTS inserts CMIs into downlink bursts according to the CODEC signaled from the TRAU and into uplink TRAU frames according to the CODEC signaled by the MS. The TRAU sets the CMI for the downlink TRAU frames as requested by the CMC from the BTS. The MS sets the CMI in the uplink speech frames as requested by the CMC received from the BTS.

Summary: By the CMR the MS indicates which CODEC it desires, by the CMC the BTS commands which CODEC shall be used by TRAU and MS and by the CMI the MS, TRAU and BTS indicate which CODEC they currently use to allow a correct decoding on the receive side.

How is the initial AMR CODEC determined during call setup?

Whether an AMR FR or an AMR HR TCH is to be assigned during call setup, basically depends on the mobile’s speech version preference, which is indicated in the ASSIGNMENT REQUEST message (and which was normally originally indicated by the MS in the SETUP message (for MOC) or the CALL CONFIRMED message (for MTC)). Like for all non-AMR calls, the BSC can override the MS preference due to the feature “Cell Load Dependent Activation of Half Rate” (see parameter EHRACTAMR in command SET 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 AMR CODEC, i.e. the AMR CODEC that shall be used in the beginning of the call (this information is also included in the ASSIGNMENT COMMAND and CHANNEL ACTIVATION messages). Of course, the initial CODEC is then immediately adapted by the MS and BTS depending on the current radio conditions.

Interaction of AMR link adaptation and frequency hopping The parameters for the ACS AMRFRC1..AMRFRC4 and AMRHRC1..AMRHRC4, the initial CODECs AMRFRIC and AMRHRIC as well as the link adaptation thresholds for the downlink AMRFRTH12..AMRFRTH34 and AMRHRTH12..AMRHRTH34 can also be set in the FHSY object (see command CREATE FHSY). The BTS uses these AMR parameters from the FHSY object for the downlink CODEC mode adaptation if frequency hopping is active in the BTS (for the uplink CODEC mode adaptation there is no difference between hopping active or deactivated). In this context it is not 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 database flag



for frequency hopping (see parameter HOPP in command) indicates that hopping is enabled. The FHSY parameters for AMR are only considered for a particular AMR call if hopping is currently active for this call.

Handover and Power Control for AMR Calls The Handover and Power Control Decision for AMR calls is basically the same as for any other speech call. Exception: The Handover decision algorithm as well as the Power Control Decision algorithm uses special C/I thresholds for the Handover or Power Control decision due to quality. For further details, please refer to the parameters HOLTHQAMRDL (SET HAND [BASICS]) and LOWTQAMRDL (SET PWRC).

AMR Compression Handover / AMR Decompression Handover As mentioned before, the decision whether an AMR call is set up as AMR FR or AMR HR call is either based on the speech version preference indicated in the ASSIGNMENT REQUEST or on the BSC decision (Cell load dependent activation of HR). As opposed to non-AMR calls, special intracell handovers are implemented for AMR calls, that allow a switchover from an AMR HR TCH to an AMR FR TCH and vice versa.

For further details about AMR compression and AMR decompression handover please refer to parameter EADVCMPDCMHO in command SET HAND [BASICS].

Notes: - To support AMR, the involved TRAU must be equipped with TRAC V5 or TRAC V7. Neither TRAC V1 nor TRAC V3 support AMR. - In the MSC and the BSC, the associated A-interface resources must be created with the appropriate channel pool type (see parameters DEFPOOLTYP in command CREATE PCMA and POOLTYP in command SET TSLA). - During Inter-BSC handover, the originating BSC informs the target BSC about the currently used CODEC by the field element “MultiRate configuration Information”. This field element is included in the Information Element “Old BSS to new BSS Information” which is included in the HANDOVER REQUIRED message and which the MSC transparently passes to the target BSC in the HANDOVER REQUEST message.



AMRFRC2= RATE_03,



RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08,

<NULL>

default: RATE_03

AMR Full Rate Codec 2, this parameter defines the second AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Full Rate in the BTS.


If AMRFRC2 is set to <NULL>, the ACS for AMR FR consists of only one CODEC (defined by AMRFRC1).



Note: An equivalent parameter to this one is also included in the FHSY object (see command CREATE FHSY). The FHSY parameter eclipses 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 Full Rate Codec 3, this parameter defines the third AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Full Rate in the BTS.


If AMRFRC3 is set to <NULL>, the ACS for AMR FR only consists of maximally two AMR CODECs (defined by AMRFRC1and AMRFC2).





AMRFRC4= RATE_08,



RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08

<NULL>

default: RATE_08

AMR 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 the BTS.


If AMRFRC4 is set to <NULL>, the ACS for AMR FR only consists of maximally three AMR CODECs (defined by AMRFRC1..AMRFC3).



Note: An equivalent parameter to this one is also included in the FHSY object (see command CREATE FHSY). The FHSY parameter eclipses 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 FR CODEC of the created AMR FR ACS shall be used first after FR TCH assignment. The values CODEC_MODE_0x represent the created AMR FR CODECs (AMRFRCx) of the ACS. Example: If AMRFRIC=CODEC_MODE_01, then the CODEC defined in AMRFRC1 will be used as initial AMR FR CODEC after FR TCH assignment.

If the value START_MODE_FR is entered, the initial CODEC is selected as defined by the GSM standard: - If the ACS consists of 1 CODEC, then this CODEC shall be used. - If the ACS consists of 2 or 3 CODECs, then the one with the most robust channel coding (i.e. the one with the lower speech coding bitrate) shall be used. - If the ACS consists of 4 CODECs, then the one with the second most robust channel coding shall be used.


AMRFRTH12=7-4,


format: threshold-hysteresis

unit: threshold: 0.5dB

hysteresis: 0.5dB

range: threshold: 0..63 [0..31.5dB]

hysteresis: 0..15 [0..7.5dB]

default: threshold: 7 [3.5 dB]

hysteresis: 4 [2.0 dB]

Default value changed in BR7.0!

AMR Full Rate Thresholds 12, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRFRC1 to AMRFRC2 and vice versa. The entered values are applied as follows:

a) The upward transition from AMRFRC1 to AMRFRC2 is initiated when

C/I > thresholdAMRFRTH12 + hysteresisAMRFRTH12

b) The downward transition from AMRFRC2 to AMRFRC1 is initiated when C/I < thresholdAMRFRTH12

Thus a) can be regarded as the ‘upper threshold’, while b) can be regarded as the ‘lower threshold’ for downlink AMR link adaptation (please see also the section “AMR Link Adaptation Thresholds Uplink” in the Appendix of this document).

In any case, the following rule must be fulfilled

thresholdAMRFRTH12 + hysteresisAMRFRTH12

≤ thresholdAMRFRTH23 + hysteresisAMRFRTH23


Notes: - An equivalent parameter to this one is also included in the FHSY object (see command CREATE FHSY). The FHSY parameter eclipses this one if frequency hopping is active in the BTS. - Please be aware that this parameter only refers to the AMR downlink CODEC mode adaptation. The corresponding uplink thresholds are not administrable (see parameter AMRLKAT).



AMRFRTH23=12-4,




hysteresis: 0.5dB






AMR Full Rate Thresholds 23, this parameter defines the C/I threshold and the associated hysteresis for the AMR link adaptation transition from AMRFRC2 to AMRFRC3 and vice versa. The entered values are applied as follows:










AMRFRTH34=23-4,




hysteresis: 0.5dB






AMR Full Rate Thresholds 34, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRFRC3 to AMRFRC4 and vice versa. The entered values are applied as follows:












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/s RATE_03: 5.90 kbit/s RATE_04: 6.70 kbit/s RATE_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 2 CODECs, then AMRHRC3 must be set to <NULL> and so on. For AMRHRC1 the value <NULL> is not allowed, as at least one CODEC must be defined within an ACS.


RATEAMRHRC4 > RATEAMRHRC3 > RATEAMRHRC2 > RATEAMRHRC1


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.



If AMRHRC2 is set to <NULL>, the ACS for AMR HR only consists of only one CODEC (defined by AMRHRC1).





AMRHRC3= RATE_03,



RATE_03, RATE_04

RATE_05, <NULL>default:

RATE_03

AMR Half Rate Codec 3, this parameter defines the third AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Half Rate in the BTS.



If AMRHRC3 is set to <NULL>, the ACS for AMR HR only consists of maximally two AMR CODECs (defined by AMRHRC1..AMRHRC2).







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.



If AMRHRC4 is set to <NULL>, the ACS for AMR HR only consists of maximally three AMR CODECs (defined by AMRHRC1..AMRHRC3).





AMRHRIC=

START_MODE_HR,


range: START_MODE_HR

CODEC_MODE_01

CODEC_MODE_02

CODEC_MODE_03

CODEC_MODE_04 default: START_MODE_HR

AMR Half Rate Initial Codec, this parameter defines which AMR HR CODEC of the created AMR HR ACS shall be used first after HR TCH assignment. The values CODEC_MODE_0x represent the created AMR HR CODECs (AMRHRCx) of the ACS. Example: If AMRHRIC=CODEC_MODE_01, then the CODEC defined in AMRHRC1 will be used as initial AMR HR CODEC after AMR HR TCH assignment.

If the value START_MODE_HR is entered, the initial CODEC is selected as defined by the GSM standard: - If the ACS consists of 1 CODEC, then this CODEC shall be used. - If the ACS consists of 2 or 3 CODECs, then the one with the most robust channel coding (i.e. the one with the lower speech coding bitrate) shall be used. - If the ACS consists of 4 CODECs, then the one with the second most robust channel coding shall be used.

Notes: - An equivalent parameter to this one is also included in the FHSY object (see command CREATE FHSY). The FHSY parameter eclipses 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/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRHRC1 to AMRHRC2 and vice versa. The entered values are applied as follows:

a) The upward transition from AMRHRC1 to AMRHRC2 is initiated when

C/I > thresholdAMRHRTH12 + hysteresisAMRHRTH12

b) The downward transition from AMRHRC2 to AMRHRC1 is initiated when C/I < thresholdAMRHRTH12



thresholdAMRHRTH12 + hysteresisAMRHRTH12

≤ thresholdAMRHRTH23 + hysteresisAMRHRTH23



AMRHRTH23=24-4,




hysteresis: 0.5dB


















AMRHRTH34=30-4,




hysteresis: 0.5dB



default: threshold: 30 [15.0 dB] (BTS+)

<NULL> (BTS1)













AMRLKAT=100,


unit: 0,1dB

range: 0..200, where

0 = -10dB, 100 = 0dB,

200 = +10dB

default: 100 [0dB]

AMR link adaptation tuning, this parameter is used by the AMR Uplink Codec Mode Adaptation in the BTS (Please note that this parameter is the only one which refers to the uplink CODEC mode adaptation! All other administrable parameters refer to the downlink CODEC mode adaptation and have no relation to this parameter!). It tunes the transition between CODEC modes determined by internal thresholds. A value higher than the default shifts the transition towards higher carrier-to-interferer or signal-to-noise ratios. A value lower than the default has the opposite effect. The step size is 0,1dB. Adaptation of AMR Half Rate and AMR Full Rate is affected simultaneously. All possible transitions between modes are generally shifted by the same amount. However, to account for a limited range of the underlying measurements, shifts of transitions near the upper range limit tend to saturate when shifted closer to the limit. The default value is the optimum setting and normally requires no modification.

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

ANTHOPMOD = <NULL>,


range: ALLTRX, NOBCCHTRX,

<NULL>

default: <NULL>

Antenna hopping mode, this parameter is only relevant if the feature ‘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 hopping period, this parameter is only relevant if the feature ‘Antenna Hopping’ is enabled (EANTHOP=TRUE, see below) and defines the antenna hopping period.

After having grouped the CUs in pools, the BTS algorithm calculates the Antenna Hopping sequence individually for each CU-POOL. The operator, by means of the O&M parameter ANTHOPP, can set the hopping period, i.e. he can decide how many frames are transmitted over each antenna before the next antenna is used to send the frames. Antenna Hopping is performed every one, two or four frames. Additionally there is the mode 4-4-5, which means that each 3rd hopping step the period is extended from 4 to 5 frames (suitable especially for GPRS/EGPRS). The number of antenna changes depends on the number of used antennas and service (4-4-5 used for EDGE).

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 Identity 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 for handover (see also parameter PLMNP), i.e. only cells with a ‘permitted’ NCC may be included in the MEASUREMENT REPORTS. The BCC must correspond to the Training Sequence Code (TSC) assigned to the BCCH of that cell. The BCC is used by the MS to correctly decode the BCCH. In other words: From the BCC in the SCH the MS knows the TSC of the BCCH it has to select. The BCC is selected by default as TSC for the BCCH when it is created (see also CREATE CHAN). Within one PLMN more than one NCC may be allowed. From the point of view of network planning, care needs to be taken to ensure that the same NCC is not used in adjacent PLMNs which may use the same BCCH carrier frequencies in neighbouring areas.

BTSHSCSD=FALSE,


range: TRUE, FALSE

default: FALSE


HSCSD enabled for the BTS, this attribute indicates whether HSCSD service is activated in the cell or not. Notes: - As a precondition for HSCSD the feature ‘early classmark sending’ (see SET BTS [OPTIONS]:EARCLM) must be enabled. - If an MS tries to set up an HSCSD call in a cell with BTSHSCSD=FALSE, the BSC starts a directed retry procedure if the flag ENFORCHO (see commandSET BSC [BASICS]) is set to ENABLE: when the BSC receives an ASSIGNMENT REQUEST for an HSCSD call and a cell with BTSHSCSD=FALSE, it BSC sends a FORCED HANDOVER REQUEST message to the BTS, which answers, like in any case of forced handover, with an INTERCELL HANDOVER CONDITION INDICATION (cause ‘forced’) and a list of suitable target cells. The BSC checks the BTSHSCSD flag for the suggested target cells - if it finds on target cell with BTSHSCSD=TRUE, the directed retry is executed (CHANNEL ACTIVATION a HANDOVER COMMAND towards the target cell). If the BWHCI contains an external target cell (other BSC), the BSC sends the HANDOVER REQUIRED message towards the MSC, if the parameter EISDCCHHO (see commandSET BSC [BASICS]) is set to ENABLE.



CALLF01=60,


range: 0..1023 each field


GSM 05.02

GSM 12.20

Cell allocation frequency 1, this parameter defines the first non-BCCH radio frequency allocated to the cell. Further frequencies used in the cell are set with the remaining parameters CALLF02..CALLF63. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 1) or/and on the main DCCH (contained e.g. in the 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,DCS etc.) an own bit position is provided. If the bit position is '1' then the frequency represented by this bit position is included in the 'cell allocation'. If frequency hopping is enabled the ‘Cell Channel Description’ IE is needed by the MS to decode the info in the IE ‘Mobile Allocation’ which specifies the frequencies used in the frequency hopping sequence.

Which frequency numbers are allowed, depends on the used frequency band:

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

Notes: - The SYSTEM INFORMATION TYPE 1 is only sent if frequency hopping is used.

CALLF02..CALLF63


Cell allocation frequencies 2 to 63, these parameters define all the remaining non-BCCH radio frequencies used in the cell (see CALLF01).

CBQ=0,


range: 0= normal priority

1=low priority

default: 0


GSM 03.22

Cell bar qualify, is used to assign a priority to a cell which is to be considered by the MS during the cell selection decision. A suitable cell with low priority is only selected if no suitable cell of normal priority can be found. This parameter (CELL_BAR_QUALIFY) is sent in the IE ‘SI 4 Rest Octets’ on the BCCH (SYSTEM INFORMATION TYPE 4). This parameter only has to be set if CRESPARI is set to ‘1’.

Attention: CBQ is only considered for ‘cell selection’, but not for ‘cell reselection’.

Cell Reselection means that the MS is camping on a cell and decides (on the basis of the level criterion C1 resp. C2) to select a different neighbour cell because this cell offers better DL RXLEV conditions. As possible target cells, only neighbour cells are considered that are included in the 'Neighbour Cell Description' which is broadcast in the SYSTEM INFORMATION TYPE 2. In this case the cell priority defined by CBQ is NOT considered by the MS!

Cell selection means, that the MS is currently not or no longer booked in to a cells and starts a search for a suitable cell 'from scratch'. This happens e.g. after switching on the MS or when the MS has lost the connection to the network (lossloss of coverage). Only in this case the MS considers the cell priority defined by CBQ for the selection of the cell.



CELLGLID="262"-"02"-10-101,


range: MCC: "0..999"

MNC: "0..999" (PCS1900)

MNC: "0..99" (all others)

LAC: 0..65535

CI: 0..65535


GSM 04.08

Cell Global Identity, this digit string unambiguously identifies a cell within the worldwide GSM system. The format is "MCC"-"MNC"-LAC-CI. MCC= Mobile Country Code (identifies the country) MNC= Mobile Network Code (identifies the network within the country) LAC = Location Area Code (identifies the location area within the network) CI = Cell Identity (identifies the cell within the location area) This parameter is sent downlink on the BCCH (SYSTEM INFORMATION TYPE 3 or 4) or on the SACCH (SYSTEM INFORMATION TYPE 6). Within these messages MCC-MNC-LAC make up the IE ‘Location Area Identification’ and CI corresponds to the IE ‘Cell Identity’. SYSTEM INFORMATION TYPE 4 does not contain the CI but only the LAI.

CELLRESH=2,


unit: 2dB

range: 0..7

default: 2


GSM 04.08

GSM 03.22

GSM 12.20

Cell reselect hysteresis, indicates the value of the receiver RF power level hysteresis required for cell reselection (MS in idle mode) on the basis of the path loss criterion C1.

C1 = (A - Max(B,0))

where A = <receive level average> - RXLEV_ACCESS_MIN = RLA_P - RXLEVAMI

B = MS_TXPWR_MAX_CCH - P = MSTXPMAXCH - P

P = Maximum RF output power of the MS (see table under parameter MSTXPMAXDCS in command SET BTS [BASICS]).

Max (B,0)= MSTXPMAXCH - P if MSTXPMAXCH > P Max (B,0)= 0 if MSTXPMAXCH < P

For RXLEVAMI see corresponding parameter in this command, MSTXPMAXCH see SET BTS [CCCH].

The term Max(B,0) is applied to ensure a sufficient uplink RXLEV even for MS with low transmit power level. The term Max(B,0), added to RXLEVAMI, ensures that the transmit power capability is considered in addition to the minimum receive level defined by RXLEVAMI: the lower the maximum transmit power of the MS, the higher the minimum RXLEV for access must be.

The MS calculates the path loss criterion for the serving and the non-serving cell at least every 5 seconds (the MS derives the necessary calculation parameters from the BCCHs of the serving and the neighbour cells). The calculation result determines the priority of these cells within the list of the six strongest neighbour cells which is dynamically managed in the MS in idle mode. The path loss criterion is satisfied if C1 > 0 (If C1 has been < 0 for a period of 5 s the path to the cell is regarded as lost). If C1 of the non-serving cell is higher than C1 of the serving cell for a period of 5 s then the MS performs 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 path loss criterion C1 on the new cell exceeds C1 on the old serving cell by at least CELLRESH for a period of 5 seconds. This mechanism is used to avoid unnecessary location update procedures. The value of CELLRESH is sent on the BCCH (SYSTEM INFORMATION Type3 and Type 4) in the IE ‘Cell Selection Parameters’ and in the SET SYSTEM INFORMATION 10 in the IE ‘Differential Cell Parameters’.

Note: The C1 criterion can be replaced by the C2 criterion (see parameter CRESPARI) if the appropriate parameters are provided via the BCCH.



CELLTYPE=STDCELL,


range: STDCELL

EXTCELL

default: STDCELL

Cell type, this parameter determines which kind of cell is to be defined.

a) The value STDCELL means ‘standard cell’ and represents a normal cell with a maximum cell radius (i.e. max. MS-BTS distance) of 35km (this value, of course, only goes for GSM900/GSM850, for DCS1800/PCS1900 the cells must be naturally smaller due to the radio propagation characteristis in the corresponding frequency band). Standard cells use ordinary single timeslots for TCHs and do not distinguish different coverage areas within the cell.

b) The value EXTCELL means ‘extended cell’ and represents a special 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 coverage areas that are characterized by their distance from the antenna:- ordinary ‘single’ TCHs are used to provide TCH resources for the coverage area up to the maximum possible MS-BTS distance of 35km. A ‘single’ TCH is an ordinary TCH as used in standard cells and consists of one radio timeslot. The coverage area served by this type of TCHs is also called ‘near area’. - special ‘extended’ or ‘double’ TCHs are used to provide channel resources for the coverage area up to the maximum possible MS-BTS distance of 100km (please refer to the parameter EXTMODE in the command CREATE CHAN). These ‘double’ TCH are nothing but a pair of directly adjacent radio timelots that are merged together, thus working as one radio timeslot with an extremely extended ‘guard period’ and thus allow a much higher delay of the bursts received from the MS. The coverage area covered by this type of TCHs is also called ‘far area’.

In an extended cell, all control channels (BCCH, CCCH, SDCCH, CBCH) must be configured as ‘double’ timeslots. As opposed to concentric cells (parameter CONCELL, see below) there is no fixed relation 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

Signaling of extended TA values As in an extended cell the normal coding range of the timing advance (TA, ranbge 0..63) is not sufficient to display distance values greater than 35km, a new IE called ‘timing offset’ is used in the Abis RSL signalling which allows the representation of the corresponding extended MS delay values.

Call setup in an extended cell When an MS sets up a call in an extended cell, the BTS adds the current ‘timing offset’ measured from the RACH access burst delay to the CHANNEL REQUIRED message. Moreover, the BTS measures the current MS delay during the SDCCH phase (as mentioned, the SDCCH is always a ‘double’ timeslot) and provides it as a combination of TA and ‘timing offset’ value to the BSC within the PHYSICAL CONTEXT CONFIRM message which is sent prior to the CHANNEL ACTIVATION of the TCH. These values are used by the BSC to decide whether a ‘single’ or a ‘double’ TCH is to be assigned to the call. This decision is based on the value of the distance threshold HOMSTAM (see command SET HAND [BASICS]). When the BSC has selected a suitable TCH it forwards the TA and timing offset values to the BTS in the CHAN ACT for the TCH so that the BTS can can instruct the MS to correctly adjust the timing advance to the



current MS-BTS distance.

Intracell handover due to distance (far-near, near far) When a call has been established in an extended cell, it might be necessary to handover the call from a double to s single timeslot or vice versa, depending on the current chages of the MS-BTS distance. This handover is enabled by the parameter EXTCHO and the decision id based on the distance threshold HOMSTAM and the distance margin HOMRGTA (all parameters see command SET HAND [BASICS]).

For futher details please refer to the mentioned parameter descriptions.

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

CONCELL=FALSE,


range: TRUE, FALSE

default: FALSE

Concentric cell, this flag defines whether the cell is a concentric one or not. A ‘concentric cell’ is a cell in which different TRX may have different ranges. TRXs with the smaller range serve the so-called ‘inner area’, TRXs with the wider range serve the so-called ‘complete area’.

Whether a TRX serves the inner or the complete area is defined in the TRX object (see parameter TRXAREA (CREATE TRX)). The different TRX coverage ranges are, for single-band concentric cells, determined by the values entered for the power reduction (see parameter PWRRED (CREATE TRX)) and, for dualband concentric cells by the different TX ouput powers of the used TRX HW (CU/PA) and different propagation attenuations of the different used frequency bands.

In any case all control channels of the concentric cell (BCCH, CCCH, SDCCH, CBCH) must belong to the complete area. As opposed to extended cells (parameter CELLTYPE, see above) there a fixed relation of concentric cell areas and particular TRXs.

Example configuration:

ts 0 ts 1 ts 2 ts 3 ts 4 ts 5 ts 6 ts 7

TRX:0 BCCH SDCCH TCH TCH TCH TCH TCH TCH

TRX:1 TCH TCH TCH TCH TCH TCH TCH TCH

= complete area = inner area

Within a concentric cell, specific intra-cell handovers from the inner to the complete area and vice versa are possible. These handovers are executed on level / distance conditions defined by appropriate thresholds in the handover package (see parameters CCDIST, HORXLVDLI, HORXLVDLO and HOCCDIST (SET HAND [BASICS])). Moreover, during the call setup procedure in a concentric cell the same values are also evaluated to determine whether the call is set up on a TCH belonging to an inner or complete area TRX.

The Concentric cell Configuration is also an obligatory precondition for the feature “Common BCCH for GSM 900/1800 or GSM850/1900 Dual Band Operation”. This feature allows to assign frequencies of different 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 use GSM900 resp. GSM850 frequencies for the complete area (and thus for the BCCH and also the SDCCHs) and to assign DCS1800 resp.

INNER area

COMPLETE area



PCS1900 frequencies to the inner area. However, also the opposite configuration is also technically possible. In any case, if the feature “Common BCCH” is used, the SYSID parameter (see below) must bes set to GSMDCS resp. GSM850PCS and the parameters for maximum allowed transmission power must be set for both bands (see parameters MSTXPMAXGSM and MSTXPMAXDCS in CREATE BTS [BASICS]).

Notes: - The features 'Extended Cell' and 'Concentric Cell' exclude each other, i.e. CONCELL cannot be set to TRUE if CELLTYPE=EXTCELL. - The intracell handover cause (inner <-> complete) does not exist for SDCCH-SDCCH handover as in a concentric cell all SDCCHs are always created in the complete area.

CRESOFF=1,


unit: 2dB

range: 0..63

default: 1


GSM 03.22

Cell reselection offset. This parameter, contained in the IE ‘SI 4 Rest Octets’ on the BCCH (SYSTEM INFORMATION TYPE 4), is one of the necessary input values for the calculation of C2. It applies an offset to the cell reselection criterion C2. This parameter only has to be set if CRESPARI is set to ‘1’. For further details please refer to the parameter CRESPARI.



CRESPARI=1,


range: 0=C2 parameters not present

1=C2 parameters present

default: 1


GSM 03.22

Cell reselection parameter indicator, indicates the presence of C2 cell reselection parameters on the BCCH in the IE ‘SI 4 Rest Octets’ (SYSTEM INFORMATION TYPE 4) and the IE ‘SI 3 Rest Octets’ (SYSTEM INFORMATION TYPE 3); 0=not present, 1=present. The criterion C2 is an optional feature that can be enabled on a cell basis. It is an enhancement of the cell selection C1 (for C1 please see parameter CELLRESH). C2, however, is useful for microcell-configurations since it prevents fast moving MSs from performing unnecessary cell reselections. The MS calculates C2 (on the basis of C1) or C1 respectively (if the C2 cell reselection parameters are not broadcast in the affected cell) for the serving and all neighbour cells at least every 5 s. The result of this calculation determines the priority of these cells within the list of the six strongest neighbour cells which is dynamically managed in the MS in idle mode. Depending on the availability of C2 cell reselection parameters in the BCCH info the MS considers C1 or C2 for the cell reselection process.

General Principle of the C2 algorithm: If the MS places a non-serving cell on the list of six strongest carriers it starts a timer the value of which has been broadcast on the BCCH (see parameter PENTIME). Equation A: C2 = C1 + CRESOFF - TEMPOFF as long as the timer (PENTIME) runs and PENTIME < 31 Equation B: C2 = C1 + CRESOFF if the timer (PENTIME) has expired and PENTIME < 31 Equation 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 a temporary offset (see parameter TEMPOFF). By this temporary offset the C2 of the non-serving cell is artificially made worse and the cell reselection is not executed.

Equation B: On expiry of the timer the temporary offset is disregarded and thus - if the C2 of a non-serving cell still exceeds the one of the serving cell for a period of 5 s the MS performs a cell reselection. Exception: If the current cell and the new cell belong to different location areas the new cell shall only be selected if the C2 of the new cell exceeds C2 of the old serving cell by at least the cell reselect hysteresis (see parameter CELLRESH) for a period of 5 seconds. This mechanism is used to avoid unnecessary location update procedures.

Equation C: If the penalty time is set to 31 (i.e. 260s) the permanent offset (CRESOFF) is not added to but subtracted, i.e. setting PENTIME to 31 results in a permanent decrease of priority. Thus in this 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 hopping, this parameter enables or disables the feature “antenna hopping”. Antenna Hopping offers a new hopping mechanism in addition to frequency hopping: the DL bursts of a channel are transmitted on GSM frame basis (or every 2nd or 4th frame) over alternating antennas within a cell. Antenna Hopping allows to obtain a performance improvement (diversity gain) of several dBs in DL direction.

The hopping mechanism is the main difference between Antenna Hopping and the already supported frequency hopping schemes, baseband and synthesizer hopping: TX Antenna Hopping is performed on CU basis, not on timeslot basis, in other words: complete CUs, including all timeslots on them, perform Antenna Hopping. It is not possible to generate Antenna Hopping sequences for each timeslot individually. A combination of synthesizer frequency hopping and Antenna Hopping is possible, whereas a combination with baseband frequency hopping is not allowed, because the TX Diversity/Antenna Hopping feature itself is based on some baseband hopping mechanism. The feature is a complete SW feature, requiring no modifications in any HW.

Antenna Hopping is supported only by BTSplus mainline, BS240XS and e-Micro BTS. Due to the limitations of the CClink PicoBTS is not able to do baseband frequency hopping and therefore also no Antenna Hopping. Antenna Hopping is not specified for BTSs belonging to BTSone family, such as BS60, BS20. All types of BTS combiners are supported but FICOMs. FICOMs are tuned via motor to a specific TRX frequency so that only baseband frequency hopping is possible, which is forbidden parallel to Antenna Hopping. CUs connected to a FICOM are excluded automatically from Antenna Hopping.

Antenna Hopping has to deal with various types of CUs (e.g. GSM-CU, EDGE-CU and SB-EDGE-CU for switched beams) and frequency bands (e.g. GSM900, DCS1800 and PCS1900). For this a CU-POOL concept has been developed, restricting the Antenna Hopping between CUs of the same POOL only and thus also between the antennas to which the corresponding CUs of the POOL are connected. It is not possible to perform Antenna Hopping between CUs of different types and frequency bands.

All CUs of the same frequency band and of the same HW type are always assigned to the same CU-POOL. For each pool a hopping sequence is calculated. The pool grouping and the calculation of pool sequences are done in the BTS core (COBA) by a dedicated algorithm. Antenna Hopping is enabled for either all CUs including the BCCH-TRX CU or for all CUs except for the BCCH-TRX CU. If Antenna Hopping for the BCCH-TRX is excluded, the corresponding CU is not assigned to any CU-POOL. Enabling/disabling Antenna Hopping for the BCCH-TRX is done using the parameter ANTHOPMOD (see below). The feature "not-ramping for BCCH" will be deactivated if Antenna Hopping with ANTHOPMOD (AntennaHoppingMode)=ALLTRX is set.

Further related parameters are ANTHOPMOD and ANTHOPP.

EEOTD=TRUE,


range: TRUE, FALSE

default: FALSE

Enable equal TSC to BCC, this parameter represents the flag to enable the setting of the TSC (Training Sequence Code) equal to the BCC (Base Station Color Code) for all channels belonging to the BCCH TRX.



EHRACT=FALSE,


range: TRUE, FALSE

default: FALSE

Enable cell load dependent activation of HR, this parameter enables the feature “Cell load dependent activation of half rate” for non-AMR calls in the cell (for AMR calls, a separate database flag EHRACTAMR (see command SET BSC [BASICS] is available). This feature allows the BSC to override the speech version preferences indicated in incoming TCH seizures requests and to force these incoming TCH seizure requests to FR or HR TCHs depending on the actual radio traffic load situation in the cell (BTS) and the Abis traffic load situation in the BTSM. On the basis of the radio TCH load thresholds HRACTT1 resp. HRACTT2 (see command CREATE BTS

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

Detailed functional description: The BSC can receive an incoming CS TCH seizure request in the following 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 are triggered by messages which indicated the speech version capabilities an preference allowed from the MS and MSC point of view. Both ASS REQ and the HO REQ contain Information Elements indicating the supported speech versions and the speech version preference. The BSC stores the capability and preference ‘profile’ of each call in one transaction register and considers this profile for all subsequent TCH seizure requests (cases 3 and 4). If EHRACT=FALSE, the decisive factor for the BSC in the TCH assignment decision is the signalled speech version preference (unless there is TCH congestion). However, in situations with high traffic load it makes sense to ignore this preference and to force incoming calls to HR TCHs if HR is indicated as supported speech version in the TCH seizure request. This is achieved by setting EHRACT=TRUE and by applying a suitable traffic load threshold value (HRACTT1/HRACTT2).

Before assigning a TCH after having received one of the abovementioned TCH seizure requests (1..4) the BSC calculates a) the current cell traffic load (per BTS) and b) the current Abis traffic load (per BTSM)

Case A: HR activation due to radio TCH load in the cell Before assigning a TCH after having received one of the abovementioned TCH seizure requests (1..4) the BSC calculates the cell traffic load and compares it to the threshold HRACTT1 resp. HRACTT2 (for inner area in concentric cells or far area in extended cell).The BSC calculates the cell traffic load according to the formula

For further details about the meaning of single terms of this formula, please refer to the description of parameter HRACTT1.

As long as the cell traffic load remains below the threshold defined by the parameters HRACTT1 and HRACTT2, the BSC forces the incoming TCH seizures to FR or EFR (depending on the preference indicated in the ASS REQ or HO REQ and the BSC/TRAU capability).

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

no. of configured radio TCH



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

Case B: HR activation due to BTSM Abis TCH load Before assigning a TCH after having received one of the abovementioned TCH seizure requests (1..4) the BSC calculates the BTSM Abis traffic load and compares it to the threshold ABISHRACTTHR. The BSC calculates the Abis 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 ABISHRACTTHR (see command CREATE BTSM).

As long as the BTSM Abis traffic load remains below the threshold defined by the parameters ABISHRACTTHR, the BSC forces the incoming TCH seizures to FR or EFR (depending on the preference indicated 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, for which HR is indicated as supported speech version, are forced to a HR TCH.

Interworking between case A and case B

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

• Incoming calls or incoming handovers, for which HR is indicated as supported speech version, are forced to a FR or EFR TCH, if the BTS radio TCH load is below the threshold HRACTT1/HRACTT2 and 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 operation of the feature ‘Cell load dependent activation of half rate’ for AMR calls only the flag EHRACTAMR is relevant, the setting of the flag EHRACT does not have any influence. - Cell Load Dependent Activation of HR does not work when Direct TCH Asssignment (see parameter DIRTCHASS in command SET BTS [OPTIONS]) is enabled. In case of Direct TCH Assignment the BSC has to decide about the TCH type (FR, HR) when it receives the CHANNEL REQUIRED message. The only information about the MS’s speech version capability which is available at this point of time is included in the ‘Establishment cause’ IE within the included CHANNEL REQUEST message. This information is very restricted with respect to the grade of detail and the MS capabilities and preference. At this point of time the BSC does not check the current TCH load in the cell to decide about the allocation of FR or HR but assigns a TCH type in correspondence with the ‘establishment cause’ 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 in command SET HAND [BASICS]) and intracell handover due to quality (for a call whose quality is still poor after decompression handover), the features ‘Cell load dependent actvation of half rate’ and ‘Abis load dependent

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

no. of Abis TCHs configured in Abis pool ∗ 100



activation of half rate’ (see parameter ABISHRACTTHR in command CREATE BTSM) are not considered if the BSC receives an INTRACELL HANDOVER CONDITION INDICATION due to quality reasons (cause values ‘uplink quality’ or ‘downlink quality’). This means that the BSC does not check the current 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 Pairing Threshold 1, this parameter represents the threshold that indicates, when the Enhanced Pairing for TCH/H channels feature is enabled (see parameter EPA in command SET BSC), the percentage of busy radio TCHs

- in the whole BTS (in case of standard cell) - in the complete area of a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) - in the far area of an extended cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS])

The value 100 represents 1%.

Enhanced pairing intracell handovers are triggered if the following radio TCH traffic load condition is fulfilled (for further details about the meaning of single terms of this formula, please refer to the description of parameter EPAT1).

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

- A dual rate TCH (TCHF_HLF) can assume the usage state “busy“ (i.e. both 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) TCHs which are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like any other TCH which is currently seized by a CS call. b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e. DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currently busy due to GPRS traffic (PDCH) are considered as ‘idle’.

- If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is set for the DGRSTRGY parameter, as these TCHs are in any case immediately preempted if a CS TCH request meets a TCH congestion situation.

- TCHs ’reserved for GPRS’ (see parameter GMANPRES in the PTPPKF object) are not 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’ (not considering the reserved GPRS TCHs in state ‘idle’) and the value below the fraction bar is the number of the actually created TCHs minus the TCHs reserved for GPRS.

- If a GPRS call utilizes more TCHs than configured as ‘reserved’ by GMANPRES, the currently used but ‘not reserved’ TCHs (‘idle/shared’ TCHs) are considered in correspondence with the setting of DGRSTRGY as indicated above.

Attention: Although the default value of this parameter is 6000 (=60%), a more useful setting is 4000(=40%) as the threshold is compared to the percentage of ‘idle’ TCHs (not the ‘busy’)!

Note: This parameter only represents the traffic load threshold for the feature ‘Enhanced pairing due to BTS radio TCH load’. Enhanced pairing can also be triggered due to BTSM Abis pool TCH load. In this case the relevant Abis pool TCH load threshold is defined by the parameter ABISHRACTTHR (see command CREATE BTSM).

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

no. of configured radio TCH EPAT1[%]



EPAT2=4000,


unit: 0,01 %

range: 0..10000

default: 6000


Enhanced Pairing Threshold 2, this parameter represents the threshold that indicates, when the Enhanced Pairing for TCH/H channels feature is enabled (see parameter EPA in command SET BSC), the percentage of busy TCHs

- in the inner area of a concentric cell (see parameter CONCELL in command 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: Although the default value of this parameter is 6000 (=60%), a more useful setting is 4000(=40%) as the threshold is

compared to the percentage of ‘idle’ TCHs (not the ‘busy’)!

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

ETXDIVTS=FALSE,


range: TRUE, FALSE

default: FALSE

Enable TX diversity timeshift, this parameter allows to switch between coverage mode (enabled) and standard mode (disabled).

FACCHQ=5,


unit: 1 half burst

range: 0..7

default: 5

FACCH quality, defines the number of FACCH halfburst to be received for detecting a FACCH frame. FACCHs are normal speech bursts which are 'abused' as signaling channels. Within the 'Normal Bursts' the so-called 'steal-bits' are used to distinguish TCH from FACCH info. The general speech coding algorithm codes 20ms of speech to 456 bits and distributes it over 8 halfbursts. 'Halfburst' means that the speech information of one 20ms speech block is contained in one half of the burst only (due to the interleaving one burst carries the information for two different 20ms-speech-blocks). If - due to transmission problems on the radio interface - the steal-bits are falsified the FACCH halfbursts may be recognized as TCH by mistake. The FACCHQ parameter determines how many halfbursts with the correct steal-bits must have been received to regard a received half-burst sequence as FACCH frame.

FDDMURREP=0,


range: 0..3

default: 0

FDD multiRAT reporting, this parameter indicates the number FDD UTRAN 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. When the 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 MDB20

MDB16 MDB12

MDB08 MDB04

DB00 DB04 DB08

DB12 DB16 DB20

DB24 DB28

default: DB00

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



DBxx = xxdBm (e.g. DB20 = 20dBm)

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



FDDREPQTY =RSCP,


range: RSCP, ECNO

default: RSCP

reference: 3GPP 25.433

3GPP 25.215

FDD reporting quantity, this parameter determines in which way the MSs shall report the radio conditions of UMTS FDD neighbour cells.

The possible values are

• RSCP = Received Signal Code Power this value indicates the DL receive level in the UMTS FDD neighbour cell and is thus comparable to the RXLEV value in GSM.

• Ec/No = Energy chip to Noise over all, this value indicates the DL quality in the UMTS FDD neighbour cell and is thus comparable to the RXQUAL resp. C/I values in GSM.

MultiRAT mobiles (RAT=Radio Access Technology) can report the radio conditions of UMTS FDD neighbour cells either by RSCP values (level oriented) or by Ec/No values (quality oriented) but not both at the same time. The setting of FDDREPQTY determines which of the two reporting methods shall be used by the multiRAT MSs.

Important: The setting of the FDDREPQTY has an influence on the 2G-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 a comparison of the RXLEV value of the serving GSM cell to the RSCP value in the UMTS FDD neighbour cell is possible via the handover margin (see parameter HOM in command CREATE ADJC3G).

• Imperative 2G-3G handovers from GSM to UMTS (see parameter EUIMPHO in command SET HAND [BASICS]) are possible with both settings of FDDREQTY, but the processing of the measured values is different: - If FDDREPQTY is set to RSCP, the handover minimum condition, which is checked in order to determine whether a particular UMTS FDD neighbour cell is a suitable target cell for imperative handovers fromGSM to UMTS, is defined by the RSCP-oriented parameter RXLEVMINC (see command CREATE ADJC3G). - If FDDREPQTY is set to ECNO, the handover minimum condition, which is checked in order to determine whether a particular UMTS FDD neighbour cell is a suitable target cell for imperative handovers from GSM to UMTS, is defined by the Ec/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 of the measured values is different: - If FDDREPQTY is set to RSCP, the suifficient coverage condition, which is checked in order to determine whether a particular UMTS FDD 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 minimum condition, which is checked in order to determine whether a particular UMTS FDD neighbour cell is a suitable target cell for imperative handovers from GSM to UMTS, is defined by the Ec/No-oriented parameter USECNO (see command CREATE ADJC3G).

Additional background information: In a UMTS FDD network, the different calls are transmitted via the same radio frequency, the distinction of the channels is done on the basis of Code division multiplex, i.e. each channel is characterized by its own code. The overall downlink signal which is broadcast in a particular UMTS neighbour cell is expressed as



RSSI = Received Signal Strength Indicator. This RSSI value, however, must be distinguished from the RSCP value, which is valid only for a particular code only. The relation of RSSI, RSCP and Ec/No is defined as

RSSI – RSCP = Ec/No

GUARMABIS=0,


unit: 1 %

range: 0..20

default: 0

Guaranteed minimum Abis, this parameter specifies the minimum percentage of ‘in service ‘Abis subslots of the BTSM Abis pool (see command CREATE SUBTSLB) that shall in any case be kept available 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 Abis allocation for BTS X) for every BTS Y in the same BTSM the percentage of Abis subslots still idle and in service is equal or greater than

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 of the Abis pool that are in state unlocked/enabled.

Note: GUARMABIS is only guaranteed under normal conditions. It is not guaranteed: 1) in case a fault or an operator command causes the outage of service of part of or all the Abis subslots in the Abis pool, as long as the other cells of the site keep allocated most of the residual in service 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 the radio configuration.



HRACTAMRT1=6000,


unit: 0,01 %

range: 0..10000

default: 6000

Half Rate Activation AMR threshold, this parameter is used for two different 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, they are explained in separate points.

a) Cell Load Dependent Activation of Half Rate for AMR calls In this case HRACTAMRT1 is only relevant if the parameter EHRACTAMR (see command SET BSC [BASICS]) is set to TRUE.

HRACTAMRT1 is the equivalent to the parameter HRACTT1 (see below) for AMR calls and defines a traffic load threshold which is evaluated for the forced speech version selection for incoming AMR TCH seizures. For this, the BSC compares HRACTAMRT1 to the percentage of TCHs not available for CS allocation (in state busy, locked or shutting down) related to the number of TCHs configured in

- in the whole BTS (in case of standard cell) - in the complete area of a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) - in the far area of an extended cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS])

If the cell traffic load exceeds the percentage defined by HRACTAMRT1, all incoming AMR calls or incoming AMR handovers, for which AMR HR is indicated as supported speech version, are forced to an AMR HR TCH. If the cell traffic load is below the percentage defined by HRACTAMRT1, all incoming calls are forced to AMR FR. As the basic principle is exactly the same like for cell load dependent activation of HR for non-AMR calls please refer to the parameters HRACTT1 (see below) and EHRACT (see above) for further details (e.g. concerning the traffic load calculation)).

b) AMR compression handover On every expiry of the timer TRFCT (see SET BSC) the BSC checks the traffic load in its cells and compares it to the threshold HRACTAMRT1.

For AMR compression handover the BSC calculates the traffic load as follows

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

- (*) A dual rate TCH (TCHF_HLF) in usage state „busy“ (i.e. both HR subslots busy) is counted as 2 while a dual rate TCH in usage state „active“ (i.e. only on HR subslot busy) is counted as 1.

- (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command 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) TCHs which are currently busy due to GPRS traffic (PDCH) are considered as ‘busy’ like any other TCH which is currently seized by a CS call. b) If DGRSTRGY indicates ‘GPRS downgrade allowed’ (i.e. DOWNGRADE_GPRS_ONLY, DOWNGRADE_GPRS_FIRST or DOWNGRADE_HSCSD_FIRST, then all (non-reserved) TCHs which are currently busy due to GPRS traffic (PDCH) are considered as ‘idle’. - If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as ‘idle’ in any case, no matter which values is set for the DGRSTRGY parameter, as these TCHs are in any case immediately preempted if a CS TCH request meets a TCH congestion situation.

- TCHs indicated as ‘reserved for GPRS’ (see parameter GMANPRES in the PTPPKF object) 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 of TCHs 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

∗ 100 Cell 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 in correspondence with the setting of DGRSTRGY as indicated above.

If the traffic load in the cell exceeds the threshold HRACTAMRT1, the BSC enables the AMR compression handover in the affected BTS by sending a SET ATTRIBUTE message with the appropriate indications to the BTS. This indication starts the AMR compression handover decision process in the BTS which has the task to hand over all AMR calls currently occupying a FR TCH to a HR TCH if the quality (C/I) conditions of this call are good. The quality criteria for the AMR compression handover are defined by the C/I thresholds HOTHAMRCDL and HOTHAMRCUL (see SET HAND [BASICS]).

HRACTAMRT2=6000,


unit: 0,01 %

range: 0..10000

default: 6000

Half Rate Activation AMR threshold, like the parameter HRACTAMRT1, this parameter is used for the features

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

It has exactly the same function like the parameter HRACTAMRT1 (see above) but affactes different cell areas:

- in the inner area of a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) - in the near area of an extended cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS]).

HRACTAMRT2 is the equivalent to the parameter HRACTT2 (see below) for AMR calls and defines a traffic load threshold which is evaluated for the forced speech version selection for incoming AMR TCH seizures. For this, the BSC compares HRACTAMRT2 to the percentage of TCHs not available for CS allocation (in state busy, locked or shutting down) related to the number of TCHs configured in the cell areas mentioned above.

If the cell traffic load exceeds the percentage defined by HRACTAMRT2, all incoming AMR calls or incoming AMR handovers, for which AMR HR is indicated as supported speech version, are forced to an AMR HR TCH. If the cell traffic load is below the percentage defined by HRACTAMRT2, all incoming calls are forced to AMR FR. As the basic principle is exactly the same like for cell load dependent activation of HR for non-AMR calls please refer to the parameters HRACTT1 (see below) and EHRACT (see above) for further details (e.g. concerning the traffic load calculation).

For AMR compression handover, the same principles apply as described for parameter HRACTAMRT1.



HRACTT1=6000,


unit: 0,01 %

range: 0..10000

default: 6000

HR activation threshold 1, this parameter defines a threshold which is used by the following features ‘Cell Load Dependent Activation of Half Rate’ (parameter EHRACT, see above). HRACTT1 defines a traffic load threshold that is evaluated for the forced speech version selection for incoming non-AMR TCH seizures. For this, the BSC compares HRACTT1 to the percentage of busy TCHs (related to the available TCHs) within - the cell (for standard cells) - the complete area (for concentric cells) - the far area (for extended cells).

For the feature CLDAHR the BSC calculates the traffic load as follows


- (*) 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 subslot busy) is counted as 1.


- TCHs reserved for GPRS (see GMANPRES in CREATE PTPPKF) are totally excluded 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 indicated as supported speech version, are forced to a HR TCH. If the cell traffic load is below the percentage defined by HRACTT1, all incoming calls are forced to FR or EFR (depending on the capability and preference indicated in the ASSIGNMENT REQUEST or HANDOVER REQUEST message). For further details please refer to the parameter EHRACT.

HRACTT2=1000,


unit: 0,01 %

range: 0..10000

default: 6000

HR activation threshold 2, this parameter is only relevant for concentric cells or extended cells and defines thresholds for the features 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 the explanations provided for HRACTT1.

∗ 100 Cell 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 Cell Broadcast Message 0, this specifies the handling and the contents of the Local Cell Broadcast Message.

LCBM1=<NULL>,


format and range: see LCBM0

default: <NULL>

Local Cell Broadcast Message 1, this specifies the handling and the contents of the Local Cell Broadcast Message. For format, range and default settings of the parameter value please see parameter LCBM0.

LCBM2=<NULL>,



default: <NULL>


LCBM3=<NULL>,



default: <NULL>


MSTXPMAXDCS=0,


unit: see tables below

range: 0..15

default: 0


GSM 05.05

GSM 04.08

GSM 03.22

GSM 12.10

Maximum transmission power for DCS 1800, this parameter defines the maximum transmission level a MS is allowed to use on a dedicated channel (TCH and SDCCH) in the serving cell. This parameter is relevant if the cell contains frequencies of the DCS1800 band. This info determines the value of the IE 'MS Power' in the first CHANNEL ACTIVATION message sent by the BSC for a call context (e.g. CHAN ACT for an SDCCH in case of call setup, or CHAN ACT for a new TCH in case of handover). In the 'MS Power' IEs of the following CHAN ACT messages as well as in the 'Power Command' IEs contained in the ASSIGNMENT COMMAND and HANDOVER COMMAND messages the allowed power level is additionally determined by the MS power capability (whichever is lower) which is provided by the MS in the IE 'MS classmark' in the CM SERVICE REQUEST 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 Band Operation” is used in the cell, the both the parameters MSTXPMAXGSM and MSTXPMAXDCS must be set, as both bands are used within the cell. This information is evaluated during call setup



and for the complete-to-inner intracell handover decision.

MSTXPMAXGSM=5,



range: 2..15

default: 5

Maximum transmission power for GSM 900, this parameter defines the maximum transmission level a MS is allowed to use on a dedicated channel (TCH and SDCCH) in the serving cell. This parameter is relevant if the cell contains frequencies of the GSM900 band.

Value ranges: GSM900: 2..15, default: 2=39dBm (step size -2dBm) GSMR: 2..15, default: 2=39dBm (step size -2dBm)

For further information please refer to the explanation provided for the parameter MSTXPMAXDCS.

Note: If the feature “Common BCCH for GSM 850/1900 Dual Band Operation” is used in the cell, the both the parameters MSTXPMAXGSM and MSTXPMAXPCS must be set, as both bands are used within the cell. This information is evaluated during call setup and for the complete-to-inner intracell handover decision.

MSTXPMAXPCS=0,



range: 0..15, 30, 31

default: 0

Maximum transmission power for PCS 1900, this parameter defines the maximum transmission level a MS is allowed to use on a dedicated channel (TCH and SDCCH) in the serving cell. This parameter is relevant if the cell contains frequencies of the PCS 1900 band.

Value range: PCS1900: 0..15,30,31(30=33dBm, 31=32dBm)

default: 0=30dBm (step size -2dBm),

For further information please refer to the explanation provided for the parameter MSTXPMAXDCS.

Note: If the feature “Common BCCH for GSM 850/1900 Dual Band Operation” is used in the cell, the both the parameters MSTXPMAXGSM and MSTXPMAXPCS must be set, as both bands are used within the cell. This information is evaluated during call setup and for the complete-to-inner intracell handover decision.



Mobile station 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 900 and GSM 850 DCS 1800 PCS 1900

Power

control level

Nominal Output

power (dBm)

Power

control level

Nominal Output

power (dBm)

Power

Control Level

Nominal Output

Power (dBm)

0..2 39 29 36 22-29 Reserved

3 37 30 34 30 33

4 35 31 32 31 32

5 33 0 30 0 30

6 31 1 28 1 28

7 29 2 26 2 26

8 27 3 24 3 24

9 25 4 22 4 22

10 23 5 20 5 20

11 21 6 18 6 18

12 19 7 16 7 16

13 17 8 14 8 14

14 15 9 12 9 12

15 13 10 10 10 10

16 11 11 8 11 8

17 9 12 6 12 6

18 7 13 4 13 4

19-31 5 14 2 14 2

15-28 0 15 0

16-21 Reserved

from GSM 05.05, MS Output power tables



NMULBAC=0,


range: 0..3

default: 0


Number of multi band cells, this parameter is relevant for dualband configurations and specifies in which way the MS shall report the neighbour cells of the frequency bands used in the serving and neighbouring cells. Possible values: 0 - Normal reporting of the six strongest cells, with known and allowed NCC part of BSIC, irrespective of the band used. 1 - The MS shall report the strongest cell, with known and allowed NCC part of BSIC, in each of the frequency bands in the BA list, excluding the frequency band of the serving cell. The remaining positions in the measurement report shall be used for reporting of cells in the band of the serving cell. If there are still remaining positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used. 2 - The MS shall report the two strongest cells, with known and allowed NCC part of BSIC, in each of the frequency bands in the BA list, excluding the frequency band of the serving cell. The remaining positions in the measurement report shall be used for reporting of cells in the band of the serving cell. If there are still remaining positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used. 3 - The MS shall report the three strongest cells, with known and allowed NCC part of BSIC, in each of the frequency bands in the BA list, excluding the frequency band of the serving cell. The remaining positions in the measurement report shall be used for reporting of cells in the band of the serving cell. If there are still remaining positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used.

PCCCHLDI=255,


unit: 1s

range: 0..255

default: 255

Period of CCCH load indication, this value indicates the time distance between two CCCH LOAD INDICATION messages sent to the BSC (see also parameters RACHBT and RACHLAS). The CCCH LOAD INDICATION is only sent to the BSC if the CCCH load threshold TCCCHLDI (parameter description see below) is reached. The value PCCCHLDI=0 indicates that the CCCH LOAD INDICATION is not repeated but sent only once.

Note: In BR7.0 the parameter PCCCHLDI is additionally used to enable 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, thus indicating that one PAGING COMMAND could not be placed in a paging queue and had to be discarded), triggers the following mechanism: as long as the PCH load is still above the threshold defined by the parameter TCCCHLDI (see below), the BTS discards all PAGING COMMANDs that contain an IMSI. This is done because an IMSI needs twice the space than a TMSI in the BTS paging queues and is thus an attempt to effectively prevent further overload situations by removing those messages that have the biggest impact on the load in the AGCH queues.

Attention: if TMSI Reallocation is disabled in the network (i.e. paging is exclusively done with the IMSI), it is recommended to disable this functionality by setting PCCCHLDI=0 (as this would lead to too many discarding of pagings) and to leave the PCH overload handling to the BSC (see parameter BTSOVLH in command SET BSC [BASICS]).



PENTIME=0,


unit: 20s

range: 0..31

31= TEMPOFF ignored

default: 0


GSM 03.22

Penalty time, sets the duration for which the temporary offset is applied. This parameter, contained in the IE ‘SI 4 Rest Octets’ on the BCCH (SYSTEM INFORMATION TYPE 4), is one of the necessary input values for the calculation of C2. This parameter only has to be set 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 ‘NCC Permitted’. Only those neighbour cells whose NCC (please see also parameter BSIC) is indicated as ‘permitted’ in the ‘NCC permitted’ IE may be included in the MEASUREMENT REPORTs in busy mode. Thus only to these cells a handover is actually possible! In other words, if a specific cell has two cells using the same BCCH frequency or a directly adjacent BCCH frequency (whose “side-ramp” the MS might misinterpret as the signal of the allowed BCCH frequency due to co-channel interference) in the geographical neighbourhood, the MS will only report the one with the correct NCC (unless the interference leads to an unsuccessful BSIC decoding, in this case the MS cannot report anything). The decimal value entered for PLMNP is sent to the MS as a binary 8-bit string “ NCC permitted “ on the BCCH (SYSTEM INFORMATION TYPE 2, together with the list of the allowed neighbour cell BCCH frequencies) or on the SACCH (SYSTEM INFORMATION TYPE 6). The 8-bit string is used as a ‘bit-map’; every ‘1’ bit indicates that the NCC corresponding to the bit position is allowed.

Example: PLMNP=82Dec 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 NCCs 6, 4 and 1 will be reported.

Note: PLMNP has no influence on cell reselection, i.e. the MS might attempt a cell reselection to a cell with an NCC which is not included in “NCC Permitted”. “NCC Permitted” is included in the SYSINFO 2 only in order to inform the MS early enough which cells are allowed for measurement reporting when it switches to ‘busy’ mode.

PUREBBSIG44CONF= TRUE,


range: TRUE, FALSE,<NULL>

default: FALSE

Pure BBSIG44 Configuration, this parameter states if a BTS1 is equipped with all BBSIG44 (TRUE) or equipped with at least one “old BBSIG” (FALSE). It is up to the operator to ensure the consistency between the attribute value and the BS-2x/6x equipment. In case of BS-4x/240/241/240XL, BS-82 and BS-242 the attribute is not meaningful, and its value must be <NULL> value.

The BBSIG type used in BTSEs of the BTS1 family is relevant for the 14,4 kbit/s data coding and the ciphering algorithms for handover from 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 that include the IE ‘Encryption Information’ (e.g. CIPHERING COMMAND, HANDOVER REQUEST etc.) with an encryption key (Kc) of more than 54 bit. The ‘Encryption key’ parameter itself has a length of 64 bit, but the last 10 bits (last byte and the last 2 bits of the ‘last but one’ byte) must be set to ‘0’ as the old BBSIG only supports Kc’s of this format. If this condition is not fulfilled (it is automatically fulfilled if the standard A8 is used for the calculation of the Kc!), the BSC rejects the message with the cause value ‘Cipher algorithm not supported’.

Note: In BR7.0 the BBSIG1 (old BBSIG) is no longer supported (the associated BTS SW code was completely removed), which



means that for BTS1 the parameter PUREBBSIG44CONF must be set to TRUE in any case, while for BTSplus it must be set to <NULL>.

QSRHC=NEVER,


range: UMDB98 UMDB94

UMDB90 UMDB86

UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66

OMDB62 OMDB58

OMDB54 NEVER

default: NEVER

qSearchC, this parameter defines a threshold condition which enables the searching for 3G cells with regard to handover (MS in busy mode); in other words, if the threshold condition defined by QSRHC 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 (=over minus xxdB) define the threshold as

follows: When the level of the neighbour cell has exceeded the “xx dB” threshold value, the neighbour cell shall be considered for cell selection/reselection. - The values UMDBxx (=under minus xxdB) define the threshold as follows: When the level of the neighbour cell has dropped below the “xx dB” threshold value, the neighbour cell shall be considered for cell selection/reselection. - The value ALWAYS means the Mobile shall always consider 3G neighbours cells for cell selection/reselection. - The value NEVER means the Mobile shall not consider 3G neighbours cells for cell selection/reselection at all.

QSRHCINI=QSEARCHI,


range: QSEARCHI, ALWAYS

default: QSEARCHI

qSearchCinitial, this parameter indicates the initial value to be used before the MS receives QSRHC (Qsearch_c) in the measurement information message on the SACCH.

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

QSRHI=NEVER,



UMDB90 UMDB86

UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66

OMDB62 OMDB58

OMDB54 NEVER

default: NEVER

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

The parameter values have to be considered as described for the parameter QSRHC (see above).

RACHBT=109,


unit: -1dBm

range: 0..127

default: 109

RACH busy threshold, defines a threshold for the signal level on the RACH. The general purpose of this parameter is to define a minimum level criterion a received RACH signal must fulfil to be regarded as a real RACH access. To understand the mechanism better, it is required to describe the functional sequence of RACH signal evaluation in alittle more detail:

Functional sequence of RACH signal evaluation:

The BTS evaluates the RACH signals in two main stages: 1) The Um layer 1 SW subsystem of the BTS continuously observes the signals received on the RACH slots. As even without any MS RACH access there are always at least some ‘noise’ signals on the RACH, the task of the layer 1 SW subsystem is to evaluate the received signal with respect to specific criteria, e.g. it measures the receive level and checks if it exceeds a hardcoded minimum threshold

(RSSI level, not equal to RACHBT!), measures the signal-to-noise ratio (SNIR), evaluates a soft decision criterion (SOVA), tries to decode the training sequence, checks the Convolution Code, checks for block CRC errors and measures the delay of the RACH burst to determine the MS-BTS distance. Together with the decoded signal itself, the results of these checks are forwarded in form of a set of flags to the BTS call handling SW subsystem. These flags indicate the 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 be regarded as a successful RACH access or not. On the basis of the flags received, the BTS call handling subsystem classifies the received signals either as ‘noisy’ or ‘not noisy’. Five of the mentioned flags from the layer 1 evaluation are regarded as ‘killer criteria’ (RSSI, SOVA, SNIR, Conv Code and training sequence), i.e. if one of these flags was set to ‘1’ by the layer 1 SW subsystem, the call handling subsystem regards the received signal as ‘noisy’, which leads to an immediate discarding of the received signal. In this case the signal will neither lead to the transmission of a CHANNEL REQUIRED, nor will it be counted by the PM counter NINVRACH (Number of invalid RACH messages per cause). If, however the mentioned five flags assume the value ‘0’ (criterion fulfilled), the BTS call handling subsystem evaluates three further criteria to check whether a RACH signal is to be regarded as ‘valid’ or ‘invalid’ (the numbering defines sequence of the checks): 1. If the ‘block CRC error’ flag has the value ‘1’, the received RACH message is regarded as invalid and counted by NINVRACH subcounter 3 (’other causes’). 2. If the received signal level is below the threshold defined by the parameter RACHBT, the received RACH message is regarded as invalid and counted by NINVRACH subcounter 1 (’signal level too weak’). 3. If the delay of the RACH burst indicates that the MS-BTS distance is greater than the distance defined by the parameter EXCDIST (see command SET BTS [OPTIONS]), the received RACH message is regarded as invalid and counted by NINVRACH subcounter 2 (‘excessive distance’).

If none of the aforementioned conditions applies, the RACH access is regarded as ‘valid’ and leads to the transmission of a CHANNEL REQUIRED message towards the BSC.

Notes: - The value entered for parameter RACHBT is not only relevant for the CHANNEL REQUEST message on the RACH but also for the HANDOVER ACCESS message on the FACCH! The level evaluation of RACHBT against the receive level of the handover access burst on the FACCH is exactly the same as for the RACH. Thus, the setting of RACHBT also has an influence on the handover success rate.

- RACHBT is also relevant for the BTS load recognition procedure for the 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 bursts over which RACH measurements are performed by the BTS (see also parameter RACHBT). In other words: RACHLAS defines the averaging window for the RACH load measurements. The BTS reports these measurements to the BSC according to the setting of the parameter PCCCHLDI (see above). Please see also parameter TCCCHLDI. 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 link timeout, the value entered for this parameter determines the value of the parameter RADIO_LINK_TIMEOUT which is sent on the BCCH (SYSTEM INFORMATION TYPE 3) or on the SACCH (SYSTEM INFORMATION TYPE 6) in the IE ‘Cell Options’. It is used by the MS to calculate the maximum value of the radio link counter (‘S’ counter) in the MS which is needed to detect a radio link failure in the downlink (a similar counter is realized in the BTS for the uplink, see parameter RDLNKTBS (SET PWRC)). The maximum value S0 of the S-counter in the MS is calculated as follows:

S0 = 4 + 4∗ RDLNKTO

Its range is 4..64. The ‘radio link timeout’ value is the start point for the ‘S’ counter in the MS which is in effect if the mobile is in ‘dedicated’ (or ‘busy’) mode. Unsuccessful decoding of SACCH messages by the transceiver lead to a decrease of the ‘S’ counter by 1, successful decoding to an increase by 2. If the ‘S’ counter reaches 0, the MS regards the dedicated radio connection as failed and stops any further transmission on the dedicated channel. In such a situation, of course, also the BTS cannot correctly decode any uplink SACCH frames anymore (because the MS has stopped transmitting them) and it is just a question of time when the radio link counter in the BTS (see RDLNKTBS) reaches ‘0’. In this case a CONNECTION FAILURE INDICATION (BTS->BSC) is sent and indicates the loss of the dedicated connection (call drop). Note: If ‘Call Re-Establishment’ (see parameter CREALL) is enabled a low value of radio link time-out increases the number of call reestablishments because a decrease of RDLNKTO may lead to an earlier declaration of radio link failures.

REPTYP=NORMAL,


range: NORMAL, ENHANCED

default: NORMAL

Report type, this parameter indicates to the mobile to use the ENHANCED MEASUREMENT REPORT or MEASUREMENT REPORT messages for measurements reporting. Enhanced measurement reporting is only supported by special mobiles.

Note: ENHANCED MEASUREMENT REPORT is not to be mixed up with 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 the network on the RACH. It is used together with other parameters to define the path loss criterion C1 for cell selection and reselection (see parameter CELLRESH). Setting RXLEVAMI to a high value means that only those MSs attempt an access to the cell which are in a location with good coverage conditions. Thus the number of handover requests may be reduced. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3 and 4) in the IE ‘Cell Selection Parameters’.

Note: If a PBCCH is configured (see parameter CREATE CHAN for TCH with GDCH=PBCCH), an equivalent parameter is broadcast on the PBCCH for GPRS mobiles to allow a separate management of cell selection and cell reselection for GPRS- and non-GPRS-mobiles. This parameter is GRXLAMI (see command CREATE PTPPKF).



SDCCHCONGTH=70,


unit: 1 %

range: 70..100

default: 70

SDCCH congestion threshold, this parameter is associated to the feature “Smooth channel modification” (for further details please see command CREATE CHAN for TCH/SD) and defines the SDCCH load threshold which causes the move of a TCH/SD from the TCH/SD_POOL to the SDCCH_BACKUP_POOL and vice versa. SDCCHCONGTH determines the cell-specific trigger threshold for the percentage of busy SDCCHs which initiates the moving of a TCH/SD from the TCH/SD_POOL (see parameter setting CHPOOLTYP=TCHSDPOOL in command CREATE CHAN) to the SDCCH_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 the BSC calculates the SDCCH traffic load and compares it to the to the threshold SDCCHCONGTH. If the SDCCH traffic load exceeds SDCCHCONGTH, the BSC moves the TCH/SD from the TCH/SD_POOL to the SDCCH_BACKUP_POOL and thus extends the SDCCH capacity by 8 additional SDCCH subslots. The TCH/SD with the best quality (determined from the idle TCH measurements, see parameter INTCLASS in command SET BTS [INTERF]) is moved first. The following flow diagram shows the exact process that is triggered by an SDCCH request:

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

no. of SDCCH subslots in unlocked/enabled*



The parameter SDCCHCONGTH is also evaluated during SDCCH release in order to decide whether a TCH/SD currently in the SDCCH_BACKUP_POOL can be moved back to the TCH/SD_POOL. For this reason the BSC calculates the current SDCCH traffic load and compares it to SDCCHCONGTH. Attention: the calculation performed during the SDCCH release procedure is different from the formula shown above! For further details please refer to the descriptions provided for the parameter TGUARDTCHSD.

Note: SDCCHCONGTH has no relevance for the SDCCH allocation process itself, i.e. if the BSC receives an SDCCH request, it does not move a TCH/SD to the SDCCH_BACKUP_POOL to satisfy this request! Instead, for all incoming SDCCH requests the BSC first tries to allocate an SDCCH subslot from the SDCCH_POOL (i.e. a subslot from the non-TCH/SD SDCCHs), no matter whether additional SDCCH subslots are available in the SDCCH_BACKUP_POOL or not.

SYSID=BB900,


range: BB900 (GSM baseband)

DCS1800

F2ONLY900 (GSM ext. bd.)

EXT900 (GSM mixed band)

GSMR (railway GSM),

PCS1900

GSMDCS

GSM850

GSM850PCS


System Indicator, indicates the frequency band used by the traffic channels. If F2ONLY900 is selected only phase2 mobiles can be used, phase1 mobiles are not supported. If EXT900 is selected the GSM base band is still usable for phase1 mobiles, 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 shall be configured for the feature “Common BCCH for GSM 900/1800 or GSM850/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 correction term for the BTSE internal timing advance measurements (similar to the parameter RXLECADJ, see command CREATE RFLOOP). The idea of this correction term is to consider the propagation delay on the BTSE internal signal path for the determination of the real timing advance value. This is achieved by simply adding the TAADJ value to 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 be known, i.e. suitable measurements must have been made before. It is up to the operator to make sure that the parameter value is set in correspondence with the real propagation delay conditions in the BTSE.



TCCCHLDI=100,


unit: 1%

range: 0..100

default: 100

Threshold for CCCH load indication, this value is a threshold used by the BTS to inform the BSC about the load on the CCCH by sending the Abis RSL message CCCH LOAD INDICATION. This message is used to make the current PCH load and RACH load visible on the Abis interface. The BTS sends the CCCH LOAD INDICATION if either a) 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 any case 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 CCCH LOAD INDICATION, which includes the ‘Paging Load’ IE. This IE contains the parameter ‘Paging Buffer Space’, i.e. the guaranteed number of PAGING COMMANDs (i.e. MS IDs) that can still be stored in a paging queue. The BTS calculates this value as follows:

This calculation is based on the fact that at least one further MS ID can be added in a paging queue place, which already contains 1MS ID - 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 CCCH LOAD INDICATION, which includes the ‘RACH Load’ IE. This IE contains the following parameters:

- ‘RACH Slot Count’, corresponds to the abovementioned ‘RACH load measurement period’ (= parameter RACHLAS) - ‘RACH Access Count’, indicates the number of error-free decoded access bursts received on the RACH during the RACHLAS period. - ‘RACH Busy Count’, indicates the number of RACH bursts that were received 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 any overload 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 the description of this parameter.

∗ 100 PCH 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 buffer space 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)

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

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



TDDMURREP=0,


range: 0..3

default: 0

TDD multiRAT reporting, this parameter indicates the number TDD cells that shall be included in the MEASUREMENT REPORT messages.

TDDQO =DB00,


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 indicates an offset which is applied to the carrier level of the TDD serving cell.

TEMPOFF=1,

object:

unit:

range:

default:

Reference:

Temporary offset. This parameter, contained in the IE ‘SI 4 Rest Octets’ on the BCCH (SYSTEM INFORMATION TYPE 4), is one of the necessary input values for the calculation of C2. It applies a negative offset to C2 for the duration of the penalty time. This parameter only has to be set if CRESPARI is set to ‘1’. For further details please refer to the parameter CRESPARI.

TXDIVTSEXCPT=NONE,


range: NONE, SCH

BCCHTRXTS0,

BCCHTRX

default: NONE

TX diversity time shift except, this parameter parameter allows to configure time slots or logical channels which are excluded from being sent 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 diversity time shift parameter, this parameter defines the time shift of the TX signals of master and slave CU. The parameter is not relevant if ETXDIVTS parameter is set to FALSE.

UMTSSRHPRI =TRUE,


range: TRUE, FALSE

default: TRUE


UMTS search priority, this parameter indicates if a mobile can search 3G cells when BSIC decoding is required, i.e. if the searching time 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) have effects on the SYSTEM INFORMATION messages on the BCCH. >

SET BTS [CCCH]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BTS packages’ were moved below the object BTS and appear in the DBAEM in the CREATE BTS command. The logical group “[CCCH]” is normally only used on the LMT but was used here to allow 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 Advanced Speech Call Items (ASCI) are enabled. If ASCISER=ASCI_ENABLED this means that both VBS (Voice Broadcast service) and VGCS (Voice Group Call Service) are enabled.

Both VBS and VGCS call calls always involve a) one subscriber with special control permissions (called ‘dispatcher’) and b) a number of other subscribers (called ‘ASCI service subscribers’) which basically represent the ‘receiving’ parties of an ASCI call.

Voice Broadcast Service (VBS)

A VBS call is always set up by the dispatcher. When a VBS call is set up by the dispatcher, the BSC activates an ‘ASCI Common TCH’ in all cells in which ASCI is enabled. This common TCH is a simplex TCH which only uses the DL direction (the UL is not used) and which is used by all ASCI service subscribers to ‘listen’ to the information sent by the dispatcher. In a VBS call, only the dispatcher may talk, all other ASCI service subscribers are only allowed to ‘listen’.

Voice Group Call Service (VGCS)

Basically a VGCS call is set up in the same way as a VBS call, i.e. an originating party initiates the call setup and for the called subscribers an ‘ASCI Common TCH’ is set up in the cells with ASCI enabled.

The differences towards a VBS call, however, are the following: - A VGCS call can not only be set up by the dispatcher but also by other ASCI service subcribers. - In case of a VGCS call, the ASCI service subscribers may not only listen but they can also talk. For this they can intiate the so-called ‘Talker Change’ procedure by pressing the PTT (‘Push To Talk’) button on their ASCI phone. In this case the requesting ASCI service subscriber is granted an uplink channel, which allows him to send speech information in the uplink direction, which is transmitted towards all other ASCI service subscribers and and towards the dispatcher and is thus audible for all other parties involved in the VGCS call.

In this situation, the additional uplink TCH can be set up in two ways: a) A separate duplex TCH is allocated to the talking ASCI service subscriber for the transmission of the uplink speech information (“ASCI 1,5 channel model”) b) The so far unused uplink part of the ASCI Common TCH is activated and allocated to the talking ASCI service subscriber (“ASCI One Channel 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 Uplink 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), VBS calls only (VBSENABLE) or both at the same time (VBS_VGCSENABLE).

Functional sequence of an ‘Uplink Reply’ procedure When an ASCI group call (VBS or VGCS) is set up in a cell and



simultaneously an ASCI Common TCH was activated, the BTS broadcasts the group call reference and the ‘Channel Description’ data of the ASCI Common TCH via the Notification Channel (NCH) in the cell (please see also description of parameter NOCHFBLK). In this situation, the BSC may initiate the release of the activated ASCI Common TCH, if no listening ASCI MSs are available in the cell. To check whether ASCI MSs are present in the cell, the BTS sends the UPLINK FREE message via the FACCH associated to the ASCI common TCH and waits for an UPLINK ACCESS message. This UPLINK ACCESS message is sent on the ASCI common TCH and is the response from the ASCI MSs, if they have previously received the UPLINK FREE message with the IE ‘Uplink Access Request’ included. For the supervision of this procedure, the BTS uses the timers TWUPA (timer to wait for uplink acccess, hardcoded in the BTS) and TUPLREP (administrable timer, see SET BTS [TIMER]) which are both started when the UPLINK FREE message is sent: The BTS periodically repeats the sending of the abovementioned UPLINK FREE message (containing IE ‘Uplink Access Request’) via the FACCH of the ASCI Common TCH. The time period between two consecutive transmissions of the UPLINK FREE message is determined by the timer TUPLREP. When no UPLINK ACCESS message was received from any ASCI MS before timer TWUPA expires, 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 cell by sending the the VBS/VGCS CHANNEL RELEASE INDICATION towards the BSC, which in turn releases the channel by sending CHANNEL RELEASE, DEACTIVATE SACCH, RF CHANNEL RELEASE etc..

Notes: - The UPLINK FREE message is used in two different cases a) in the Uplink reply procedure (as described above) b) during the ‘Talker Change’ procedure within a VGCS call (ASCI service subscriber presses the PTT button on the ASCI phone, see parameter ASCISER in command SET BTS [CCCH]). Only in case a) the UPLINK ACCESS message contains the IE ‘Uplink Access Request’. For case b) please refer to parameter VGRULF in command SET BTS [TIMER]) - If the ASCISER is disabled the Uplink Reply procedure must be disabled as well; if ASCISER is enabled the uplink reply procedure can be enabled or disabled optionally. - The activation state of the Uplink Reply procedure is indicated by a flag in the CHANNEL ACTIVATION message sent for the ASCI Common TCH contains within the IE ‘Channel Options’. - When the ASCI Common Channel was deallocated due to lack of ASCI MS in the cell, the NOTIFICATION COMMAND is still sent via the NCH but consequently does not contain the IE ‘Channel Description’ (which normally identifies the used ASCI Common TCH) any more, it just contains the group call references of all ASCI group calls currently ongoing in this cell. Moreover, the IE ‘Command Indicator’ 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 group call type (VBS or VGCS or both), the ASCI Common TCH will always be activated in the affected cells as long as an ASCI group call is ongoing, no matter whether ASCI subscribers are present in the cell or not. Consequently, the NOTIFICATION COMMAND is will always contain the ‘Channel Description’ IE together with the group call reference. - On the LMT the parameter ASCIULR is grouped under the



BTS [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 retransmissions, this parameter defines the maximum number of retransmission attempts the MS can perform on the RACH if the previous attempts have been unsuccessful. To request a dedicated control channel (normally an SDCCH) from the network, the MS performs a RACH access by sending a CHANNEL REQUEST message to the BSS via the RACH. In the successful case, the MS receives an IMMEDIATE ASSIGNMENT COMMAND via the AGCH. The MS regards an access attempt unsuccessful when it has neither received an IMMEDIATE ASSIGNMENT COMMAND or - if no SDCCH is available in the cell - an IMMEDIATE ASSIGNMENT REJECT via the AGCH before the time defined by the parameter NSLOTST (see below) has expired. The value of MAXRETR determines how often the MS may repeat its access attempt. If after MAXRETR retransmissions the MS still did not receive any IMMEDIATE ASSIGNMENT COMMAND or IMMEDIATE ASSIGNMENT REJECT, it starts cell reselection to a suitable neighbour cell. To avoid a ‘ping-pong’ cell reselection, the MS must obey a waiting time of 5 seconds before it can return to the original cell with a further cell reselection procedure, if it has previously left it due to unsuccessful RACH access attempts..

A RACH access without subsequent receipt of an IMMEDIATE ASSIGNMENT COMMAND or REJECT message can occur due to: - RACH collisions (this happens when several MS access the same RACH at the same time - in this case the BTS cannot decode the CHANNEL REQUEST(s) and discards the messages) - radio interface problems (loss of messages) - delayed IMMEDIATE ASSIGNMENT sending due to Abis via satellite link (with the correspondingly high propagation delay on Abis) - overload handling (which features the discarding of CHANNEL REQUIRED messages and thus the discarding of the embedded CHANNEL REQUEST, see associated section in the appendix)

The value of MAXRETR is sent on the BCCH (SYSTEM INFORMATION TYPE 1, 2, 3 and 4) in the IE ‘RACH Control Parameters’

Notes: - For the MS it does make a difference, whether it receives an IMMEDIATE ASSIGNMENT REJECT as response to a transmitted CHANNEL REQUEST or whether it does not receive any response at all. While in the latter case, as described above, the MS will leave the cell after MAXRETR access attempts without receipt of an MMEDIATE ASSIGNMENT, in case of IMMEDIATE ASSIGNMENT REJECT the MS just has to obey a waiting time before it may attempt the next RACH access attempt (see parameter T3122 in command SET BSC [BASICS]) and will in any case stay in the cell. - The level of MAXRETR has an impact on the RACH load and the speed of MS access to a cell. In case of RACH and AGCH overload a decrease of MAXRETR can be used to decreases the number of access attempts of the MSs and therefore the RACH overload without barring any access classes (see parameter NALLWACC in command SET BTS [OPTIONS]). A high value of MAXRETR will speed up the access and thus increase the RACH and AGCH load, a low value will delay the access and may result in cell reselection and therefore in a delay 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 transmit power for CCCH, indicates the maximum transmit power level a MS is allowed to use when accessing a cell on the ‘random access channel’ (RACH) and before receiving the first ‘Power Command’ (see parameter MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) in command CREATE BTS [BASICS]) during a communication on a DCCH or TCH (after an IMMEDIATE ASSIGNMENT). This parameter is sent on the



BCCH (SYSTEM INFORMATION TYPE 3 and Type4) in the IE ‘Cell Selection Parameters’. This parameter is also used (together with other parameters) to define the path loss criterion C1 (see parameter CELLRESH in command CREATE BTS [BASICS]). The value of MSTXPMAXCH should be adapted to the size of the radio cell: the smaller the cell the lower the allowed transmit power should be in order to minimize channel interference in adjacent cells and to save MS battery. In a first step, MSTXPMAXCH may be set to the same value as MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) (CREATE BTS [BASICS]) to guarantee that a MS, which is accepted on the RACH, is able to communicate with the network also on the dedicated channel. Notes: - If a PBCCH is configured (see parameter CREATE CHAN for TCH with GDCH=PBCCH), an equivalent parameter is broadcast on the PBCCH for GPRS mobiles to allow a separate management of cell selection and cell reselection for GPRS- and non-GPRS-mobiles. This parameter is MSTXPMAC (see command CREATE PTPPKF). - Increasing the entered value decreases the allowed transmit power on the RACH and thus the maximum allowed distance between MS and BTS for RACH access! (For details regarding the power classes and power control levels please refer to the parameter MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) (CREATE BTS [BASICS])).

NBLKACGR=1,

object: BTS [CCCH]

range: 0..7

default: 0


GSM 05.02

Number of blocks for access grant, specifies the number of CCCH blocks to be reserved in each configured CCCH timeslot for the Access Grant Channel (AGCH) during a period of 51 TDMA frames, i.e. one multiframe. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) in the IE ‘Control Channel Description’.

Paging Channel (PCH) and AGCH share the same TDMA frame mapping when combined onto a basic physical channel. The channels are shared on a block by block basis and the information within each block - when de-interleaved and decoded - allows a MS to determine whether the CCCH block is used as PCH or AGCH. This means that the number of available CCCH blocks, which is determined by the created CCCH configuration (e.g. channel type MAINBCCH provides 9 CCCH blocks, while MBCCHC provides only 3 CCCH blocks) is shared between PCHs and AGCHs. Basically, in the BTS the transmission of PAGING REQUESTs via the PCH has priority before the transmission of IMMEDIATE ASSIGNMENTs via the AGCH, i.e. if there are pagings in the BTS paging queues the BTS will always use the available CCCH blocks for paging first, unless NBLKACGR is set to a value >0. In this case the NBLKACGR value determines the number of CCCH blocks that are never used as PCH but exclusively as AGCH, guaranteeing a basic network access even in case of high traffic.

For each BCCH/CCCH timeslot the BTS provides 1 AGCH queue with 4 places each (1 place for 1 IMMEDIATE ASSIGNMENT COMMAND or IMMEDIATE ASSIGNMENT REJECT). Setting NBLKACGR > 0 can increase the guaranteed AGCH throughput and thus lead to a quicker emptying of the AGCH queue, but is also reduces the number of CCCH blocks available for paging by the selected value and thus also reduces the number of paging groups (see also NFRAMEPG) and paging queues in the BTS. In correspondence with the GSM specification, the blocks that are reserved for AGCH are located in adjacent CCCH blocks at a specific position within the BCCH/CCCHmultiframes (235ms). This means that NBLKACGR should not be set to a too high values, as this would - in periods of high paging load - have the effect that, due to the resulting reduction of paging groups and the priority of paging in the non-reserved CCCH blocks, paging is performed mainly in the non-reserved CCCH blocks, while AGCH messages can only be transmitted on the reserved blocks. As these are grouped at adjacent



positions within the BCCH/CCCHmultiframes (235ms), the burst-wise receipt of more than 4 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 this document), as the AGCH queue can only be emptied every 235ms.

Notes: - According to a BR7.0 Operator Hint, NBLKACGR must be set to a value >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 cell b) NBLKACGR > 0 if a SCBCH is created in the cell (see CREATE CHAN) - The setting of NBLKACGR refers to each CCCH timeslot created in a cell. In other words, if in a cell two CCCHs are created (e.g. one MAINBCCH on timeslot 0 and an additional CCCH on timeslot 2 of the BCCH TRX (with 9 CCCH blocks each), in both CCCHs the BTS reserves one block for AGCH. E.g. with a setting of NBLKACGR=2 in this example, 2 blocks will be reserved for AGCH, while the 7 remaining 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

Number of multiframes 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 paging group determines which CCCH blocks the MS shall monitor for incoming paging messages. By just monitoring a subset of the CCCH blocks for paging (Discontinuous Reception (DRX)) the MS can save battery capacity. The BSC and the MS calculate the actual paging group from the IMSI, the used CCCH configuration in the current cell (also considering the setting NBLKACGR, see above) and the setting of NFRAMEPG. For each paging group an own paging queue is available in the BTS, i.e. the higher the CCCH capacity in the cell, the more paging groups and thus paging queues are available in the BTS. Setting NFRAMEPG to a higher value results in an increase of the number of paging groups (that are sent on the Um with a lower frequency as the Um capacity remains the same), and thus to an extension of the buffer space which is available in the BTS for the PAGING REQUESTs that are to be transmitted. Thus, with a higher value of NFRAMEPG the incoming paging traffic is distributed over a greater number of paging groups (paging queues) and thus the BTS can manage temporary paging ‘peaks’ in a better way than with a small value of NFRAMEPG. The smaller the value of NFRAMEPG, the earlier the BTS will run into congestion of single paging queues, which results in ‘extended paging’ or/and ‘paging reorganization’.

On the other hand, the higher the value of NFRAMEPG, the longer the time distance between pagings of the same paging group. This increases the average call setup time for MTCs (from point of view of the calling party).

Moreover, NFRAMEPG has an influence on the downlink signaling failure criterion which in turn is based on the ‘downlink signaling failure counter’ (DSC) in the MS. When the MS camps on a cell, DSC is initialized to a value equal to the nearest integer to 90/N where N is the NFRAMEPG parameter for that cell. If the MS successfully decodes a message in its paging subchannel DSC is increased by 1 (however never beyond the nearest integer to 90/N) otherwise DSC is decreased by 4. When DSC reaches 0 or a negative value, a downlink signaling failure is declared and cell reselection is performed.

This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) in the IE ‘Control Channel Description’.



NOCHFBLK=1,

object: BTS [CCCH]

range: 1-7

default: 1

Notification channel first 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 the NOTIFICATION COMMAND message (BSC -> ASCI MS) which is used to inform the ASCI MS about the currently active ASCI group calls (by a ‘Group Call Reference’ number) and to provide the ‘Channel description’ 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) is currently activated in the cell. Several ASCI groups calls can be active within one cell at the same time, thus the NCH might broadcast different NOTIFICATION COMMAND messages with different group call references and ASCI Common TCH description data. The NOTIFICATION COMMANDs are periodically repeated on the Um interface, the periodicity of these messages is determined by the parameter TNOCH (see command SET BTS [TIMER]). A NOTIFICATION COMMAND with ASCI group call reference but without ‘Channel Description’ (indicating an ongoing ASCI group call but, due to absense of ASCI subscribers currently participating in this group 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 channel organization of a BCCH/CCCH, that are reserved for AGCH (parameter NBLKACGR, see above). The parameter NOCHFBLK indicates the first CCCH block to be used as NCH. If more than one CCCH block is to be used, the total number of blocks is defined by the parameter NOCHBLKN (see below). In any case the total number of NCHs (NOCHBLKN) must be smaller than the number 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 (see command SET BTS [TIMER]): - If TNOCH=1 and NOCHBLKN=1 then the affected CCCH block is exclusively 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 a CCCH block remains available for AGCH or not.

- If NOCHBLKN ≥ 1 and TNOCH=N (N≥ 1), then the NCH is sent only every N

th SACCH multiframe anyway, i.e. in this case the CCCH blocks

for NCH can be used for AGCH in those SACCH MF where no NCH message is to be transmitted.

The position of the NCHs within the BCCH/CCCH timeslot is broadcast in the SYSTEM INFORMATION TYPE 1 within the IE ‘SI1 Rest Octets’. If this information is not included in the SYS INFO 1 message sent from BSC to BTS while ASCI is enabled (parameter ASCISER, see above), the BTS reacts with an ERROR REPORT message, cause value ‘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/VGCS group call. For further details, please refer to the parameter NOTFACCH in command SET BSC [BASICS].

NOCHBLKN=1,

object: BTS [CCCH]

range: 1-4

default: 1

Notification channel block number, this parameter indicates the total number of CCCH blocks to be used as Notification Channel (NCH).

The position of the NCHs within the BCCH/CCCH timeslot is broadcast in the SYSTEM INFORMATION TYPE 1 within the IE ‘SI1 Rest Octets’.

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



NSLOTST=10,

object: BTS [CCCH]

range: 0..15

default: 10


Number of slot spread transmission, determines the cycle period for retransmission of RACH accesses (i.e. transmission of a CHANNEL REQUEST message), i.e. it determines the time an MS must wait after a RACH access attempt before a new one can be started. In the mobile the retransmission mechanism is continuously executed after the first RACH access and only stopped if an IMMEDIATE ASSIGNMENT COMMAND or (if no SDCCH is available) an IMMEDIATE ASSIGNMENT REJECT message is received from the BSS via the AGCH. In the normal and successful case, the MS receives the IMMEDIATE ASSIGNMENT COMMAND before a second access attempt is started. However, under specific conditions, the IMMDIATE ASSIGNMENT COMMAND or REJECT message may not arrive 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 same RACH at the same time - in this case the BTS cannot decode the CHANNEL REQUEST(s) and discards the messages) - radio interface problems (loss of messages) - delayed IMMEDIATE ASSIGNMENT sending due to Abis via satellite link (with the correspondingly high propagation delay on Abis) - overload handling (which features the discarding of CHANNEL REQUIRED messages and thus the discarding of the embedded CHANNEL REQUEST, see associated section in the appendix)

The number of RACH retransmissions is restricted to a value determined 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 retransmission cycles for phase 2 mobiles. The delay time determined by NSLOTST

consists of a fixed (deterministic part “td” and a random part “tr”. 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 the static 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 to the fixed delay time td, which is different for different BCCH configurations (combined, not combined, see command CREATE CHAN for BCCH), according to the following table:

MS phase tr

td (RACH slots, combined BCCH)

td (RACH slots, uncombined 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 which the access can be randomly sent after the fixed period td.



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 to set the NSLOTST to 14 as this represents the longest possible RACH retransmission cycle that can be executed by phase 2 mobiles. This avoids unnecessary retransmissions that lead to additional SDCCH seizures and thus to a decrease of the Immediate Assignment Success Rate (or even to SDCCH congestion). - If the value of NSLOTST is to be decreased in case of high traffic density on the RACH it should be done in small steps with close observation of the load situation on the RACH in order to prevent RACH overload. NSLOTST values with a long td may extend the duration of location update, a value with a small td might cause sporadic 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 number of repetitions of PHYSICAL INFORMATION messages from the network to the MS during an asynchronous handover. After sending of the first HANDOVER ACCESS burst the MS waits to receive the PHYSICAL INFORMATION message from the BTS. The PHYS INFO message contains the actual timing advance which the BTS derives from the time delay of the handover access burst. After receipt of the PHYS INFO the MS normally sets up the layer-2 connection on the new channel by transmitting an SABM message. If the BTS has not received the SABM from the MS after transmission of the last PHYS INFO message and expiry of timer T3105 (see T3105 in command SET BTS [TIMER]) the BTS sends a CONNECTION FAILURE indication with cause ‘Handover access failure’ to the BSC and the new allocated channels are released. Notes: - The MS can only receive the PHYSICAL INFO within a time frame determined by the MS timer T3124 (time to receive the PHYS INFO) which is fixed to 320ms. - Any CONN FAIL is a trigger event for the TCH loss counter NRFLTCH. The following setting is necessary to avoid the transmission of the CONN FAIL indication while the MS falls back to the old channel due to unsuccessful access to the target cell and thus an unjustified registration of a ‘call drop’: NY1*T3105 >= 2 sec. - The combination of the values NY1=30 and T3105=MS10-10 has turned out to improve the ‘handover speech gap’ in case of BSC-controlled intercell handover as it avoids the ‘bombardement’ of the MS with unnecessary FACCH messages (that ‘steal’ the frames of the normal speech channel). - Since the introduction of the BR70 CR 2335 the values set for NY1 and T3105 are no longer applied for the PHYSICAL INFO procedure in case of SDCCH-SDCCH handover.

Please refer to the description of parameter T3105 (in command SET BTS [TIMER]) for further details!

PWROFS=0;

object: BTS [CCCH]

unit: 2dB

range: 0-3

0=feature disabled

default: 0


GSM 05.08

Power Offset, this parameter is relevant only for DCS 1800 cells. It is used only by DCS1800 Class 3 Mobile Stations to add a power offset to the value of MS_TXPWR_MAX_CCH (see MSTXPMAXCH ) used for its random access attempts. It is also used by the MS in its calculation of C1 and C2 parameters:

C1 = (A - Max(B,0))

where A = <received level average> - RXLEVAMI Max (B,0)= MSTXPMAXCH + PWROFS - P Max (B,0)= 0 P = Maximum RF output power of the MS (see table below). (RXLEVAMI see CREATE BTS [BASICS], MSTXPMAXCH see SET BTS [CCCH].) This info is sent on the BCCH (SYSTEM INFORMATION TYPE 4) in the IE ‘SI 4 Rest Octets’.



Setting the cell attributes for the Interference Measurement of idle TCHs:

< The parameters set with this command are used for averaging and reporting interference levels in idle traffic channels. >

SET BTS [INTERF]:

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


INTAVEPR=31- 2-6-12-22,

object: BTS [INTERF]

fomat: averaging period

- threshold boundary 1




unit: averaging period:

1 SACCH multiframe

threshold boundaries:

-1dBr

range: 1-31 (averaging period)

0..62 (threshold boundaries)

default: 31 (averaging period)

2 (threshold boundary 1)





Averaging period for idle TCH measurements, defines the number of SACCH multiframes (480ms = 4 multiframes, the interleaving function distributes the SACCH info over 4 bursts) over which values are averaged (value 1..31) and Interference threshold boundaries X (X= 1 to 5), these values set the limits of four interference bands for the idle time slots. The threshold values entered for INTAVEPR represent uplink RXLEV values that are measured and averaged by the BTS and then mapped to the ‘interference bands’ in correspondence with the setting of INTAVEPR.

Note: Like any other level measurements performed by the BTS, also the idle TCH measurements depend on a correct configuration of the uplink path and a suitable setting of the BTSE parameter RXLEVADJ (see command CREATE RFLOOP).

INTCLASS=TRUE,


range: TRUE, FALSE

default: TRUE

Interference classification enabled, if this parameter is set to ENABLED the BTS permanently performs interference measurements on the idle traffic channels and idle TCH/SDs in the uplink and reports he measurement results in form of ‘RF resource indication (RFRESIND)’ messages via the Abis to the BSC. In the RFRESIND messages the measured TCHs are assigned to so-called ‘interference classes’. An interference class is represented by an interference band (limited by an upper and lower interference level) which is defined by the parameter INTAVEPR. The status of the INTCLASS flag has an influence on the channel allocation by the BSC: Basically the channel allocation resp. selection of TCHs for incoming TCH requests is done cyclically, i.e. the BSC starts the TCH allocation by selecting the first TCH on TRX:0 (e.g. timeslot 2), the subsequent TCH request is served by the next TCH on TRX:0 (e.g. timeslot 3) and so on. If INTCLASS=TRUE, the BSC also evaluates the interference band of the idle TCHs for the TCH allocation, i.e. those TCHs with the best interference class are allocated first. Only if all TCHs with the best interference class are busy, the BSC allocates those with a worse interference class to an incoming 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 no difference between calls and handovers. Notes: - Only if INTCLASS is set to TRUE the PM counters for idle TCH interference measurements (MEITCHIB and ILUPLKIC) will deliver any results. - If frequency hopping is activated, the BTS measures the interference considering all frequencies used in the hopping sequence assigned to the a TCH (see parameter FHSY in command CREATE CHANNEL)! - The idle TCH measurements are performed for normal TCHs as well



as for TCH/SD channels (see command CREATE CHAN for TCH/SD) as long as they are neither occupied as TCH nor as SDCCH.

Generally the BTS does not know anything about the association of the TCH/SD channels to the ‘BSC channel pools’ (see parameter CHPOOLTYP in command CREATE CHAN for TCH/SD). Instead, for the 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. the TCH/SD is still in the SDCCH_BACKUP_POOL), from point of view of the BTS the TCH/SD is treated as a dual rate TCH again. This again means that the BTS might send idle channel measurements during this period (depending on the setting of RFRSINDP), even if the TCH/SD is still in the SDCCH_BACKUP_POOL.

RFRSINDP=60;


unit: 1 SACCH multiframe

range: 1-254

default: 60

RF resource indication period, defines the sending rate of the RFRESIND 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 and appear in the DBAEM in the CREATE BTS command. The logical group “[TIMER]” is normally only used on the LMT but was used here to allow a more useful grouping of the commands .


ENANCD=DISABLED,

object: BTS [TIMER]

range: DISABLED, ENABLED

default: DISABLED

Enable 'No call in TRX/cell detection', this flag enables resp. disables the features ‘sleeping cell detection’ and ‘sleeping TRX detection’ for the affected BTS. For both features two time zones (representing daytime and night time traffic) can be defined, in which the activity of the cell respectively the TRX is observed within time zone specific observation periods (see parameters NCDP1 and NCDP2). For both alarms the ceasing of the alarm can take place at the earliest at the end of the next observation period if in this period the alarm condition has ceased (successful activities).

1)The feature ‘sleeping cell detection’ supervises the SDCCH activations within the cell: If at the end of the observation period no successful SDCCH assignment could be registered, the alarm ‘alarm with error ID 66 - NO CALL IN CELL WITHIN A PREDEFINED TIME FRAME is output. For this, the BSC observes the number of ESTABLISH INDICATION messages for SDCCH received from the observed BTS. Principle:

Note: The 'SLEEPING CELL' alarm will in any case be output if a BTS is 'barred' (see SET BTS [OPTIONS]: CELLBARR). In many networks this approach is commonly used for cells which are exclusively used as handover target. In this case these cells carry traffic but issue the alarm with error ID 66 - NO CALL IN CELL WITHIN A PREDEFINED TIME FRAME due to missing SDCCH activity.

2)The feature ‘sleeping TRX detection’ supervises the TCH activations on a specific TRX: If at the end of the observation period the TCH activation success rate is below a fixed threshold, the alarm with error ID 70 - NO CALL IN TRX WITHIN A PREDEFINED TIME FRAME is output. For this, the BSC observes the number of CHANNEL ACTIVATION ACKNOWLEDGE* messages for TCH and the number of ESTABLISH INDICATION messages for TCH. If for a certain TRX the difference between the number of CHAN ACT ACK messages and the number of EST IND messages is equal or greater than eight (8), the SLEEPING TRX alarm is triggered.

* Note: CHANNEL ACTIVATIONs are only considered in case of TCH activations for CS TCH requests. Channel activations due to GPRS traffic are not considered in the supervision mechanism therefore the ‘sleeping TRX’ alarm can never be reaised for TRXs which are exclusively used for GPRS traffic.

no successful SDCCH ssignment

time zone

TNC TNC TNC

Sleeping Cell Alarm active

Sleeping Cell Alarm ceased

= 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 call in TRX/cell detection', this parameter allows to configure the first time-frame for the ‘sleeping TRX/cell detection’ procedure. StartTime1 represents the beginning of the time-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 call in TRX/cell detection', this parameter allows to configure 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


Number of repetitions of VGCS UPLINK GRANT this parameter is only relevant if the ASCI feature is enabled and only affects VGCS calls (see parameter ASCISER in SET BTS [CCCH]). It corresponds to the parameter NY2 described in the GSM Standard. It determines the number of repetitions of the VGCS UPLINK GRANT message during 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 Timer 200, this timer is used on different control channel types and determines the waiting time for a layer 2 frame acknowledgement.

Parameter format: sdcchSAPI0 - facchTCHF - facchTCHH - sacchTCHSAPI0 - sacchSDCCH - sdcchSAPI3 - sacchTCHSAPI3.

General: During any dedicated connection the BTS and the MS exchange specific LAPDm signaling messages in the so-called in “acknowledged mode”. This mode is started with an SABM and normally ends with the LAPDm DISCONNECT (not to be mixed up with the DTAP DISCONNECT which is transmitted between MS and MSC). All messages within this “acknowledged mode” are checked by the LAPDm flow control mechanisms based on sequence numbers that are assigned to each transmitted LAPD message. Only for those messages that are transmitted in acknowledged mode the timer T200 is used as waiting time for the layer2 acknowledgement to a transmitted message. Messages in acknowledged mode are SABM, DISCONNECT and I-frames. Signalling messages that do not have to be acknowledged are transmitted in “unacknowledged mode” via UI-frames, e.g. in the downlink the SYSTEM INFORMATION TYPE5 and 6 etc. and in the uplink the MEASUREMENT REPORTS. Of course, the acknowledgement mechanism based on T200 is used by the MS in the same way.

Principle: When the BTS transmits a DL layer-2 frame on the air (e.g. an I-frame with an embedded layer 3 message) the BTS starts the

CHAN ACT ACK (TCH) - EST IND (TCH) < 8

TNC TNC

CHAN ACT ACK (TCH) - EST IND (TCH) >= 8

time zone

Sleeping TRX Alarm active

Sleeping TRX Alarm ceased



timer T200 and waits for the acknowledgement frame from the MS. The acknowledgement frame can be another I-frame sent by the MS in the UL (if the MS has to transmit a layer-3 DTAP message anyway) as well as RECEIVE READY (RR) (if there is nothing to be transmitted on layer 3). If the acknowledgement from the MS is not received within T200 the transmission of the layer 2 frame is repeated and T200 restarted. The total number of repetitions is restricted to N200, a fixed value specified by GSM which depends on the control channel types: N200(SDCCH)=23, N200(SACCH)=5, N200(FACCH/FR)=34, N200(FACCH/HR)=29

If T200 expires after the last layer 2 frame repetition the BTS sends an ERROR INDICATION with cause ‘T200 expired N200+1 times’ (followed by a RELEASE INDICATION) message to the BSC, which releases the associated resources.

Recommended values: The different channel-type-specific values of the parameter T200 should be set in correspondence with the channel mapping and channel characteristics on the radio interface. To achieve an optimum radio interface performance (from the subscriber’s point of view), the timer values for T200 should be set in such a way that - a Um layer 2 frame retransmission should take place at the earliest after a time period the MS needs for the transmission of an acknowledgement 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 no acknowledgement was received from the MS - unnecessary retransmissions are avoided.

On the basis of these considerations, the BTS development recommends the following setting of the parameter T200

T200=29-31-38-90-70-29-168

Important: Please note that these values are the best settings from the technical point of view. The recommended values shown above might 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 T200 expiries will deliver a realistic image of the actual radio interface quality (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 for different radio signaling applications by the LAPDm protocol. SAPI 3 is used for Short Message Service (point-to-point) transmission only, while SAPI 0 is used for all other layer 3 radio signalling 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 system behaviour as on the SACCH associated to a TCH and the SACCH associated to an SDCCH the ‘acknowledged mode’ is not used at present (i.e. T200 is never used on these channel types). The mentioned fields are available because - possibly for future purposes - the associated T200 values are foreseen in the GSM standard. - When the BTS sends a channel assignment message to the MS that foresees a channel change (e.g. ASSIGNMENT COMMAND or HANDOVER COMMAND), the BTS starts T200 for these messages as they are embedded in an I-frame. Whether the MS acknowledges this I-frame on the old channel (by RR) before it switches over to the new 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 an IMMEDIATE ASSIGNMENT message and stopped when the MS has correctly seized the channels (ESTABLISH INDICATION is received for the assigned channel). If timer the dedicated channel is not established before T3101 expires, the allocated channel is released. This scenario can e.g. occur if noise on the radio is decoded as RACH 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, thus no ESTABLISH INDICATION message is sent from BTS to BSC and T3101 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 PHYSICAL INFORMATION message during the handover procedure between non synchronized cells. After receipt of HANDOVER ACCESS bursts with a correct handover reference the BSS sends a PHYSICAL INFORMATION message to the MS and starts timer T3105. If the timer expires before the BSS receives any correctly decoded layer 2 frame from the MS, it repeats the PHYSICAL INFORMATION and restarts T3105. Receipt of a correctly decoded layer 2 leads to the reset of T3105. The maximum number of repetitions is determined by the parameter NY1 (see command SET BTS [CCCH]). If this number is reached and T3105 expires again, the BTS sends a CONNECTION FAILURE INDICATION message with cause ‘Handover access failure' to the BSC which releases the new allocated channels and stops the context related to the handover.

Notes: - The MS can only receive the PHYS INFO within a time frame determined by the MS timer T3124 (time to receive the PHYS INFO) which is fixed to 320ms. T3124 is started when the MS transmits the first HO ACCESS, and is stopped when the PHYSICAL INFO was received. If no PHYS INFO is received before expiry of T3124, the MS returns to the old channel in the originating BTS and sends a HANDOVER FAILURE (DTAP) to the BSC. - The MS can also return to the old channel after it has successfully received the PHYS INFO. When the MS has received the PHYS INFO it tries to set up the layer-2 connection in the target cell by sending the SABM via the new FACCH. When the SABM was correctly acknowledged by a UA from the BTS, the setup is regarded as successful and the MS transmits the HANDOVER COMPLETE. If the MS does not receive the UA it retransmits the SABM. For an FACCH FR the time between two retransmissions is 34 TDMA frames and number of transmission is restricted to 5. This means that for approx. 800ms the MS tries to set up the layer 2 connection on the target channel. If all these attempts fail, the MS tries to return to the old channel. - Any CONN FAIL is a trigger event for the TCH drop counter NRFLTCH and the SDCCH drop counter NRFLSDCC. For this reason the parameters the time determined by (NY1*T3105) must be longer than the sum of the maximum time the MS might need to return to the old channel and the time necessary for the release of the new channel (RF CHANNEL RELEASE). If this rule is not considered, call drops

T3105 purpose: period for repetition of PHYSICAL INFORMATION message start: sending of PHYSICAL INFORMATION message stop: receipt of a correctly decoded signaling or TCH frame on new channel from the MS expiry action: repetition of the PHYSICAL INFORMATION message; if the maximum number of repetitions (NY1) has been reached: transmission of a CONNECTION FAILURE INDICAION with cause ‘HO access failure’ and subsequent release of new channel.



would be counted even if there is no real call drop but just a reversion to old channel during handover. As described above, in case of unsuccessful access to the target channel it may (in the worst case) take more than 1 second (T3124(=320ms)+800ms) before the MS returns to the old channel. The signalling of the handover failure and the subsequent release of the target channel takes additional time (especially in case of MSC-controlled handover). Field experiences have shown that he following setting is suitable to avoid the aforementioned drawbacks:

NY1*T3105 ≥≥≥≥ 2 sec.

The combination of the values NY1=30 and T3105=MS10-10 has turned out to improve the ‘handover speech gap’ in case of BSC-controlled intercell handover as it avoids the ‘bombardement’ of the MS with unnecessary FACCH messages (that ‘steal’ the frames of the normal speech channel). - Since the introduction of the BR70 CR 2335 the values set for NY1 and T3105 are no longer applied for the PHYSICAL INFO procedure in case of non-synchronized SDCCH-SDCCH handover. This change was introduced in order to optimize the T3105 and NY1 setting to the characteristic periodicity of the SDCCH channel (51 frames) in case of SDCCH handover, and as a consequence, to avoid overflows of the BTSE alarm buffer due "UI buffer overflow" alarms from subsystem U2. These alarms occur if the setting of T3105 and NY1 are optimized for TCH handover and are used for both TCH and SDCCH handover: while a correct setting for TCH leads to the overflow problem on the SDCCH, a correct setting for SDCCH leads to a insecure and potentially slow handover procedure for TCH. Therefore the handling for TCH and SDCCH was decoupled using fixed and the technically only meaningful values for SDCCH. This means that, in case of SDCCH handover, regardless the values of the two BTS attributes contained in the BSC database, the BTS applies the values

t3105 = 235 msec and ny1 = 9

T3109=HLFSEC-8,

object: BTS [TIMER]


HLFSEC = 0,5 sec

SEC5 = 5s

range: 0..255

default: HLFSEC-24


T3109: This timer is used by the BSC during the dedicated channel release procedures initiated by the MSC after O&M intervention or radio link failure conditions. The purpose of T3109 is to ensure the release of the radio channel in situations in which the MS cannot confirm connection release messages any more as the dedicated Um signalling connection has already been lost. After receipt of a CLEAR COMMAND message from the MSC or a detection of a lower layer failure the BSC sends a CHANNEL RELEASE message to the MS, starts T3109 and deactivates the SACCH. The BSC stops T3109 when it has received the RELEASE INDICATION from the BTS, which indicates that the MS has sent the DISCONNECT message on the main signalling link. If T3109 expires, the BSC deactivates all channels for this MS by sending the RF CHANNEL RELEASE message to the BTS.

Note: If a CONNECTION FAILURE messages is received from the BTSE during an ongoing release procedure the PM counters count a TCH loss (NRFLTCH) although there is no real TCH loss. To avoid these unnecessary CONNECTION FAILURE INDICATIONs, it is recommended to set T3109 to a small value, e.g. HLFSEC-8.

T3109 purpose: timer for forced deactivation of radio channels in case of communication loss towards the MS start: sending of the CHANNEL RELEASE message expiry action: sending of the RF CHANNEL RELEASE message



T3111=HLFSEC-1,

object: BTS [TIMER]


HLFSEC = 0,5 sec

SEC5 = 5s

range: 0..255

default: HLFSEC-1


T3111: This timer is used to delay the radio channel deactivation in the BSC after release of the main signaling link on the Um. During the call release procedure the BSC sends the CHANNEL RELEASE message. After receipt of the CHANNEL RELEASE message the MS sends a DISCONNECT message to the BTS to disconnect the FACCH. Subsequently the BTS acknowledges the DISCONNECT message towards the MS by an UA and informs the BSC by sending the RELEASE INDICATION message. On receipt of the RELEASE INDICATION the BSC stops timer T3109 and starts timer T3111. On expiry of T3111 the BSC deactivates the radio channels by sending the RF CHANNEL RELEASE message to the BTS. The sole purpose of timer T3111 is to let some time for the acknowledgement of the disconnection (by an UA) and to protect the channel in case of loss of the 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 (SET BSC [TIMER])): the longer the release procedure for an existing call takes, the later a queued TCH request can be served. A released TCH is 'available' for a queued TCH request if the BSC has received the RF CHANNEL RELEASE ACKNOWLEDGE for the released TCH. As a higher value of T3111 leads to a delay of the RF CHANNEL RELEASE message it simultaneously leads to an extension of the queuing time. Therefore it is recommended to set T3111 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 is enabled and only affects VGCS calls (see parameter ASCISER in SET BTS [CCCH]). It corresponds to the timer T3115 described in the GSM Standard. When a VGCS call was set up in a cell and one of the ASCI subscribers wants to talk, he starts the ‘Talker Change’ procedure by pressing the PTT button on the mobile phone to request an uplink TCH. As a result, the MS sends an UPLINK ACCESS message via the FACCH of the ASCI Common TCH and waits for the receipt of the VGCS UPLINK GRANT message. When the BTS sends the VGCS UPLINK GRANT message, it starts the timer TGRANT and waits for a correctly decoded message from the MS (normally SABM with TALKER INDICATION included). If no correctly decoded message is received from the MS before expiry of TGRANT, the BTS repeats the VGCS UPLINK GRANT message and restarts TGRANT. The number of VGCS UPLINK GRANT message repetitions is defined by parameter NRPGRANT (see above).

TNOCH=1,

object: BTS [TIMER]


range: 1-254

default: 16


Timer for notification 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 on the Notification Channel (NCH).

The NCH is located within those CCCH blocks that were reserved for AGCH (NBLKACGR) and is used to inform the ASCI MSs in the cell about the currently ongoing ASCI VBS/VGCS group calls and the currently activated ASCI Common TCH(s).

The value TNOCH=1 is recommended because test experiences have shown that other values can cause mobile problems.

For further details about the NCH and its function, please refer to description for parameter NOCHFBLK.

T3111 purpose: security period for acknowledgement of the main signalling link disconnection start: receipt of the RELEASE INDICATION message expiry 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 of TRAU frame handling for standard speech calls (FR,HR and EFR) and data calls except 14,4kbit/s data calls. The BTSE starts this timer if 3 downlink TRAU frames have not been correctly received from the TRAU and it is reset if a correct frame is received again (It is only used if a BTS-TRAU traffic connection is established). If it expires, the BTSE reports a CONNECTION FAILURE INDICATION with cause ‘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 PCM alarm detection. Note: For 14,4kbit/s data calls and AMR calls TSYNC is replaced by the timer TSYNCDL (see below).

TSYNCDL=1000,

object: BTS [TIMER]

unit: 10ms

range: 10..10000

default: 1000

TSYNC downlink, this timer replaces the timer TSYNC in case of 14.4 kbit/s data calls and AMR calls. If three consecutive DL TRAU frames have not been correctly received in the BTS the synchronization between TRAU and BTS (see explanation for TSYNCR) is considered as lost. If this is the case the BTS starts TSYNCDL and waits for the receipt of correct downlink frames. TSYNCDL is stopped when the BTS has received the first correct DL TRAU frame. When TSYNCDL expires the BTS sends a CONNECTION FAILURE INDICATION with cause ‘Remote Transcoder Failure’ to the BSC.

Rule: TSYNCR < TSYNCDL (Recommendation TSYNCDL=1000)

Note: According to GSM the timer TSYNCDL shall also be used for EFR calls. The current SBS implementation deviates from this recommendation as for EFR connections the timer TSYNC is used.

TSYNCR=400,

object: BTS [TIMER]

unit: 10ms

range: 10..10000

default: 400

TSYNC for resynchronization, this timer is used for 14.4 kbit/s data calls. At the beginning of every 14.4. kbit/s data connection BTS and TRAU exchange standard TRAU frames for synchronization. When this synchronization process is regarded as finished the BTS and TRAU switch over to the exchange of 'extended' TRAU frames. In the normal case this synchronization process is not repeated. If, however, the BTS loses the synchronization for the 14.4 kbits/s TRAU frames it starts timer TSYNCR and restarts the synchronization process by transmitting standard TRAU frames towards the TRAU. When the connection is re-synchronized BTS and TRAU start to send extended TRAU frames again and TSYNCR is stopped. If the synchronization could not be reestablished before expiry of TSYNCR, the resynchronization process is restarted again.

Rule: TSYNCR < TSYNCUL and TSYNCR < TSYNCDL

Note: According to GSM the timer TSYNCR shall also be used for EFR calls. The current SBS implementation deviates from this recommendation as EFR connections are handled in exactly the same way as FR connections.



TSYNCUL=1000,

object: BTS [TIMER]

unit: 10ms

range: 10..10000

default: 1000

TSYNC uplink, this timer is used only in case of 14.4 kbit/s data calls and AMR calls. If three consecutive UL TRAU frames have not been correctly received in the TRAU the synchronization between TRAU and BTS (see explanation for TSYNCR) is considered as lost. If this is the case the TRAU sets the control bit 'uplink frame error ' (UFE) in the downlink TRAU frames towards the BTS. When the BTS receives the first downlink TRAU frame with the control bit ‘uplink frame error’ set it starts TSYNCUL and waits for the UFE bit to disappear in the subsequent frames. TSYNCUL is stopped when three correct DL TRAU frames without the UFE have been received. When TSYNCUL expires the BTS sends a CONNECTION FAILURE INDICATION with cause ‘Remote Transcoder Failure’ to the BSC.

Rule: TSYNCR < TSYNCUL (Recommendation TSYNCUL=1000)

Note: According to GSM the timer TSYNCUL shall also be used for EFR calls. The current SBS implementation deviates from this recommendation as for EFR connections the timer TSYNC is used.

TTRAU=1000,

object: BTS [TIMER]

unit: 10ms

range: 10..10000

default: 1000

(recommended value >150)

TTRAU, this timer is used by the BTS to supervise time-out of TRAU datalink (traffic) at connection establishment or handover. After receipt of the CHANNEL ACTIVATION message the BTSE starts the timer TTRAU and starts sending uplink TRAU frames towards the TRAU. When the BTSE receives the first downlink TRAU frame from the TRAU it stops TTRAU again. If TTRAU expires, the BTSE reports a CONNECTION FAILURE INDICATION with cause ‘remote transcoder failure’ to the BSC and the connection is released. Rules: - TTRAU > ALARMT2 (see CREATE LICD) This setting is necessary in order to avoid call release before PCM alarm detection. - TTRAU > T8 and TTRAU > T10 (for T8 and T10 see command SET BSC SET BSC [TIMER]) This setting is necessary to ensure that a signaling failure (T8 and T10) is detected before transcoder failure (TSYNC and TTRAU)

TUPLREP=20,

object: BTS [TIMER]

unit: 1s

range: 5.. 60

default: 20

Timer for uplink 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 UPLINK FREE message (with ‘Uplink access request’ included) via the FACCH of the ASCI Common TCH and repeats it periodically. The time period between two consecutive transmissions of the UPLINK FREE message is determined by the parameter TUPLREP.

For further details about the functional sequence of the Uplink Reply procedure and the use of the timer defined by TUPLREP please refer to the descriptions provided for parameter ASCIULR (see command SET BTS [CCCH]).



VGRULF=1,

object: BTS [TIMER]

unit: 1

range: 1..100

default: 2

Voice group uplink free, this parameter is only relevant if the ASCI feature is enabled (see parameter ASCISER in command SET BTS [CCCH]) and is used for the repetition of the UPLINK FREE message during the ‘Talker Change’ procedure within a VGCS call (ASCI service subscriber presses the PTT button on the ASCI phone, see parameter ASCISER in command SET BTS [CCCH]).

During an ongoing VGCS call the BSC sends the UPLINK FREE message to the BTS which periodically sends this message via the ASCI Common TCH in order to inform the ASCI MSs in the cell that the uplink is currently free, i.e. the UL is not used by any other ASCI MS in the cell and a ‘Talker Change’ procedure can be started, if required. The frequency of this UPLINK FREE message sending is defined by the parameter VGRULF in the following way: The parameter VGRULF plus an offset of 440 ms defines the repetition rate of sending this message; the BTS limits the maximum repetition rate 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 no talker is in the cell on a dedicated channel.

If an ASCI MS has started the ‘Talker Change’ procedure (i.e. the ASCI subscriber has pressed the PTT button, the ASCI MS has sent the UPLINK ACCESS message via the ASCI Common TCH) and the UL TCH was successfully allocated, the BSC sends the UPLINK BUSY 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 the MSs on the BCCH. >

SET BTS [OPTIONS]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘BTS packages’ were moved below the object BTS and appear in the DBAEM in the CREATE BTS command. The logical group “[OPTIONS]” is normally only used on the LMT but was used here 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 monitoring thresholds, determines the state and the threshold values for the minor, major and critical QOS alarms on the PCMB link. The entered threshold value represents the percentage of unavailable terrestrial traffic channels on the Abis. If the number of unavailable terrestrial traffic channels exceeds the entered threshold, the alarm messages UNAVAILABLE ABIS TCH THRESHOLD MINOR, MAJOR or CRITICAL (error ID 164, 165 and 166) 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 signaling channels monitoring thresholds, determines the state and the threshold values for the minor, major and critical QOS alarms for the radio signaling channels of the BTS. The entered threshold value represents the percentage of unavailable SDCCHs in the BTS. If the number of unavailable SDCCHs exceeds the entered threshold the alarm message UNAVAILABLE RADIO SIGNALLING CHANNELS THRESHOLD MINOR, MAJOR or CRITICAL (error ID 102, 118 and 162) is output. The threshold values can only be assigned if the previous attribute is set to ENABLE.

CELLBARR=FALSE,


range: TRUE, FALSE

default: FALSE


GSM 05.08

Cell barred, the value TRUE indicates that the cell is barred and camping or any other access to the cell is forbidden. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 1,2,3 and 4) in the 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 certain conditions are fulfilled. These conditions could be e.g.: all TCHs locked or all SDCCHs locked A cell is also barred for about 10s if the hopping mode changes (e.g. due to automatic or manual disabling of frequency hopping). Please see parameter HOPP in command SET BTS [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 MS receives the “cell barred” indication in the SYSINFO, it immediately performs a cell reselection. If the SYSINFO indicates that its access class is barred, the MS stays in the cell but rejects all call attempts by the subscriber.



CREALL=NOTALLOWED


range: ALLOWED,

NOTALLOWED

default: NOTALLOWED


Call re-establishment allowed, indicates whether the MS may try to start a Call re-establishment procedure. With a call re-establishment procedure the MS tries to set up a new radio connection to the BSS directly after a call drop (which might have occurred e.g. due to sudden loss of a radio path in e.g. a tunnel). Depending on the radio conditions, the MS might set up the new call in a different BTS. For this, the MS sends a CM REESTABLISHMENT REQUEST (instead of a CM SERVICE REQUEST) to the network. It is then a task of the 'anchor' MSC (i.e. the MSC which served the dropped call) to quickly recognize the old call context and to interconnect the new radio path to the existing connection before the call is terminated by the end users or by expiry of call supervision timers. Whether a call re-establishment can be attempted or not depends on the call control state, as described in GSM Rec. 04.08, section 5.5.4. Inhibiting call reestablishment is a possibility to reduce the traffic load in the cell since call reestablishment causes considerable signaling load on the network. A low value of radio link time-out (see parameter RDLNKTO in command CREATE BTS [BASICS]) increases the number of call reestablishments because a decrease of RDLNKTO leads to an earlier declaration of radio link failures. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 1,2,3 and 4) in the IE ‘RACH Control Parameters’.



DIRTCHASS=FALSE,


range: FALSE, SDCCHMS

NOSDCCHMS

default: FALSE

Direct TCH assignment enabled, ‘Direct TCH Assignment’ means: assignment of a TCH without previous assignment of an SDCCH. If ‘Direct TCH Assignment’ is enabled the TCH is first of all assigned by an IMMEDIATE ASSIGNMENT (not by ASSIGNMENT COMMAND!) and the FACCH associated to the TCH is used as main DCCH for the call setup control messages. When the setup phase of the call is completed the TCH is put into service by a CHANNEL MODE MODIFY message. Setting DIRTCHASS to SDCCHMS means that direct TCH assignment is enabled but disabled for the cause 'answer to paging - any channel' of the CHANNEL REQUIRED message (since SDCCHonly MS may be supported by the network). Setting DIRTCHASS to NOSDCCHMS means that direct TCH assignment is enabled also for the cause 'answer to paging - any channel' of the CHANNEL REQUIRED message (since SDCCHonly MS is not supported by the network). Notes: - There is no impact on directed retry (see parameter ENFORCHO in command 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 the TCH type (FR, HR) when it receives the CHANNEL REQUIRED message. The only information about the MSs speech version capability which is available at this point of time is included in the ‘Establishment cause’ IE within the included CHANNEL REQUEST message. This information is very restricted with respect to the grade of detail and the MS capabilities and preference (see GSM04.08 for details). At this point of time the BSC does not check the current TCH load in the cell to decide about the allocation of FR or HR but assigns a TCH type in correspondence with the ‘establishment cause’ value received in the CHANNEL REQUIRED message. For this reason Cell Load Dependent Activation of HR (see parameters EHRACT in command CREATE BTS [BASICS] and EHRACTAMR in command SET BSC [BASICS]) does not work when Direct TCH Asssignment is enabled. - Direct TCH Assignment also has other disadvantages: In some cases the ‘establishment cause’ values contained in the CHANNEL REQUEST messages (especially if the parameter NECI (see command SET BSC BASICS])is set to TRUE) do not allow a clear distinction between calls (that require a TCH) and signaling procedures (for which an SDCCH is sufficient). This can happen, depending on the type of MS, e.g. for an IMSI DETACH INDICATION (which is sometimes indicated with the same establishment cause like MOC) or for SMS-MT (the BSS cannot distinguish SMS-MT from normal MTCs as the very first signaling messages are exactly the same for both procedures). In other words: it happens that that BSC assigns a TCH for signaling procedures, although these procedures could be processed using an SDCCH only . Moreover, several mobile types cause problems, when Direct TCH Assignment is enabled, especially when it is enabled for the establishment cause ‘answer to paging’



DTXDLFR=FALSE,


range: TRUE, FALSE

default: FALSE


GSM 05.08

GSM 06.31

GSM 08.60

Discontinuous transmission downlink for FR calls enabled, specifies whether “discontinuous transmission downlink (DTX downlink)“ is enabled for FR calls in the BTS. As a precondition for operation, DTX downlink must also be activated in the MSC, i.e. the MSC must declare DTX downlink ‘allowed’ in the DTX DL FLAG in the ASSIGNMENT REQUEST resp. HANDOVER REQUEST messages. The status of DTX downlink (applied/not applied) can be seen from the IE ‘Channel Mode’ in the CHANNEL ACTIVATION message on the Abis.

DTX downlink is performed by the TRAU. As the there is no call processing signaling between BSC and TRAU, but the TRAU must be informed about the ‘DTX DL allowed’ flags in the A-interface signalling and the BSC database nformed via ‘in-band’ signalling

Note: DTXDL is not allowed on the BCCH TRX.

General remarks about DTX: DTX was originally developed for satellite systems. The goal is to reduce the interference in a cell and to reduce the MS power consumption (DTX uplink only). During a normal voice call, the participants speak only 50% of time, thus each direction of transmission is occupied about 50% of time. DTX is a mode of operation where the transmitters are switched on only for those frames containing useful information. So-called VAD (Voice Activity Detection) algorithms are implemented in the MS as well as in the TRAU which are able to distinguish noisy speech from real noise even 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 parameters the receive sides generates a similar noise called “ comfort noise “ during periods without radio transmission. This is done because ‘total silence’ is experienced as considerably irritating by the listener. DTX reduces the speech data rate from 13 kbit/s to 500 bit/s. This low rate is enough to encode the background noise. This means instead of one frame of 260 bits per 20 ms only one frame per 480 ms is sent. These so-called SID frames (Silence Description Frames) are sent at the start of every inactivity period and repeated every 480 ms, as long as the voice inactivity between BTS and MS lasts. Between TRAU and BTS the comfort noise frames are sent every 20 ms.

The following example might illustrate this time behaviour:

Impacts of DTX on Measurement Processing in the BTS and MS: When DTX is used, the MS (for DTX downlink) as well as the BTS (for DTX uplink) have to consider the utilization of DTX during the radio measurement process. Both the MS and the BTS indicate in the MEASUREMENT REPORT resp. RESULT messages whether in the current measurement period DTX is active (speech transmitted) or not (silence). The BTS sets the DTX flag to ‘DTX employed’ if DTX was applied in at least one TDMA frame in the measurement period.

Both MS and BTS provide two different measurement values for RXLEV and RXQUAL: the so-called FULL and SUB values.

1) The FULL values represent the measurements that were made on

20 ms

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



the 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 radio conditions due to missing speech frames, even if the radio conditions are excellent. The higher the number of TDMA frames with active DTX, the worse the RXLEV/RXQUAL values will look.

2) The SUB values represent the measurements that were made on the SACCH frames, which are repeated every 480 ms and which carry the SYSTEM INFORMATION TYPE 5 and 6 (downlink) and the MEASUREMENT REPORTs (uplink). As a general rule, the SUB values always mirror the real radio conditions, but have a lower statistic reliability than the FULL values that were measured during speech periods. To increase the reliability of the SUB values for AMR calls, from BR8.0 onwards, the BTS does not only consider the SACCH frames but also the speech frames carrying reals speech (as the 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 in measurement periods with active DTX (silence) the BTS has to use the SUB values for these measurement periods for the Power Control and Handover Decision Process. In measurements periods without active DTX (speech frames transmitted) the BTS uses the FULL values for the PWRC and HO decision. Due to their higher statistic reliability it is possible to weight the FULL values in the Power Control and Handover averaging process higher than the SUB values. This is done by the so-called ‘DTX-weighting factor’ included in the parameters PAVRLEV and PAVRQUAL (see SET PWRC) and HOAVELEV, HOAVQUAL and ALEVFULHO (see SET HAND [BASICS]).

If the MS indicates “DTX used“ in a specific MEASUREMENT REPORT, the BTS has to consider the SUB values of the subsequent uplink MEASUREMENT RESULT (480 ms later) for the Power Control and Handover decision. On the other hand, if the BTS applies DTX for a specific downlink measurement period, it uses the SUB values of the subsequent downlink MEASUREMENT REPORT.

Attention: To allow an easier analysis of Abis measurement messages, in the MEASUREMENT RESULT and TRACE MEASUREMENT RESULT messages that are (optionally) sent from the BTS to the BSC via the Abis (see parameters RADIOMG in command CREATE TRX and TRACEMR in command SET BSC) , this “cross-relation” has been removed by a BTS-internal “frame-matching” process which shifts the associated DTX flags and measurements results to one and the same MEASUREMENT RESULT message. This means that - the DTX DL flag is valid for the downlink measurement results included in the same message - the DTX UL flag is valid for the uplink measurement results included in the same message!

continuation see next page…



The following example diagram may illustrate the principle:

measurement values used for UL PWRC and HO decision

measurement values 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

Discontinuous transmission downlink for HR calls enabled, specifies whether ‘discontinuous transmission (DTX)’ (explanation see DTXUL) is enabled for HR calls in the BTS. For further details see parameter DTXDLFR.

DTXUL=SHLFSHNH,


range: MAYFSHNH

SHLFSHNH

SHNFSHNH

MAYFMAYH

SHLFSHLH

SHNFSHLH

default: SHLFSHNH


GSM 05.08

GSM 06.31

Discontinuous transmission uplink enabled, specifies whether discontinuous transmission (DTX) shall be used by the MS. Discontinuous transmission is a mode of operation in which the transmitters turn down the sending power if the frames do not contain user information, e.g. during speech pauses. This feature is mainly used to save battery capacity in the MS; moreover, it helps to keep the overall radio interference on a low level. Meaning of the possible values:

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 INFORMATION TYPE 3) and on the SACCH (SYSTEM INFORMATION TYPE 6) in the 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 early classmark sending, this parameter indicates whether the “Early Classmark Sending” is enabled or disabled. Changing this flag just changes a flag in the BCCH (SYSTEM INFORMATION TYPE 3) in the IE ‘SI 3 Rest Octets’. This flag instructs the Mobile Stations to start the “Early classmark sending” procedure automatically for every call transaction, which means that the mobile station sends a CLASSMARK CHANGE message immediately after the first transaction request message (e.g. CM SERVICE REQUEST, PAGING RESONSE, LOCATZION UPDATE REQUEST) to provide the network with additional classmark information. The BSC forwards this information to the MSC within the BSSMAP message CLASSMARK UPDATE. This is, of course, only possible for those MSs that support the early classmark sending option. The ‘Controlled Early Classmark Sending’ option must be implemented in mobiles that support e.g. multi-band mode or HSCSD (‘multislot capability’). Thus the flag simultaneously enables/disables the multiband handovers.

Notes on CLASSMARK REQUEST procedure (started by MSC) For Location Update procedures, the CLASSMARK CHANGE / CLASSMARK UPDATE procedure can also be explicitly requested by the MSC. When this is the case, the MSC sends a CLASSMARK REQUEST 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 usual CLASSMARK CHANGE procedure.

The MSC starts the CLASSMARK REQUEST procedure to interrogate the CLASSMARK 2 information from the MS. As the CLASSMARK 2 information is already included in the CM SERVICE REQUEST message and the PAGING RESPONSE but not in the LOCATION UPDATE REQUEST message, the MSC starts the CLASSMARK REQUEST procedure only for Location Update. The CLASSMARK REQUEST procedure is only started on particular conditions: in the Siemens MSC it is only triggered, if in the MSC mobile project description data (MPRDDAT) the set of supported cipher 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 LOCATION UPDATE REQUEST message only contains the A5/1 capability, the CLASSMARK REQUEST procedure is started to figure out whether the MS also supports the other cipher algorithms allowed in the MSC.

In the Siemens-MSC it is not possible to disable the CLASSMARK REQUEST/CLASSMARK ENQUIRY procedure by database command. The only way to disable this procedure is to switch off the A5/2 / A5/3 support; this, however, cannot be done in normal operation, as the command MOD MPRDDAT can only be entered in the 'Installation Mode' of the MSC. Another possibility is to change the setting by MSC patch.

Remarks on 2G-3G network architectures The CLASSMARK CHANGE / CLASSMARK UPDATE and CLASSMARK REQUEST /CLASSMARK ENQUIRY procedure is also of special interest for 2G-3G network architectures as the network needs 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 CLASSMARK ENQUIRY message. Attention: A CLASSMARK ENQUIRY procedure can also be triggered by the BSC without receipt of a CLASSMARK REQUEST from the MSC. This can happen when an MS, which was handed over from 2G to 3G and returns to the 2G network by a 3G-2G handover. If in this case, the HANDOVER REQUEST message does not contain the suitable 3G radio capability data in the ‘Old BSS to new BSS Information’ IE, the BSC may autonomously request these data by an own CLASSMARK ENQUIRY procedure. The resulting CLASSMARK CHANGE message will in this case be forwarded to the MSC in the CLASSMARK UPDATE message as usual.

Timing and interaction of CLASSMARK REQUEST and ‘Early Classmark Sending’ procedures Experiences from real life Abis traces confirm that normally the CLASSMARK CHANGE message due to 'Early Classmark Sending' is normally sent after the MSC has sent the CIPHER MODE COMMAND (or, if authentication is performed, after the AUTHENTICATION REQUEST). When the MSC sends a CLASSMARK REQUEST message due to the cipher algorithm settings, the CLASSMARK REQUEST procedure must have been completed prior to the transmission of the CIPHER MODE COMMAND.

The procedures 'Early Classmark Sending' and CLASSMARK ENQUIRY (Abis message that follows the A-interface message CLASSMARK REQUEST) are independet from each other. - If the MS receives CLASSMARK ENQUIRY after having sent the CLASSMARK CHANGE message due to 'Early Classmark Sending', the MS will send the CLASSMARK CHANGE again. On the other hand, it also happens that an MS sends a CLASSMARK CHANGE message to the network due to ‘Early Classmark Sending’, even if a CLASSMARK ENQUIRY hes been received and answered by another CLASSMARK CHANGE message before.

EC=FALSE,


range: TRUE, FALSE

default: FALSE


GSM 02.11

Emergency call restricted, this parameter determines whether emergency calls are allowed to all MSs or restricted to MSs belonging to access classes in the range 11 to 15 . The value 'TRUE' indicates that emergency calls are restricted. This parameter is sent on the (SYSTEM INFORMATION TYPE 1,2,3 and 4) in the IE ‘RACH Control Parameters’, parameter ‘Emergency Call allowed’.

Attention: EC=FALSE means 'emergency calls allowed' EC=TRUE means 'emergency calls not allowed'



EPRE=DISABLED,



default: DISABLED

Enable Preemption, determines whether the feature ‘Preemption’ is enabled. If Preemption is allowed and an incoming highly priorized TCH request meets a TCH congestion in a cell, existing calls with a lower priority are handed over to a suitable neighbour cell by a forced HO procedure with cause ‘preemption’. If the forced HO procedure is not 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 HO REQ message. The ‘Priority’ IE contains the following entries: - The Preemptive Capability Indicator (PCI) applies to the allocation of resources for an event and indicates if the event is able to trigger the preemption of radio resources. - The Preemptive Vulnerability Indicator (PVI) applies for the entire duration of a connection and indicates whether the connection may become a target of preemption. - The Queuing Allowed Indicator (QAI) is used to decide on a per call basis if queuing may be applied or not. - The Priority Level (PL) is subdivided in 14 different levels, Priority Level 1 being the highest value. A priority table which correlates the subscriber 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 an incoming TCH request may lead to a forced HO of an existing low-priority call for TCH resource provision for high-priorized TCH requests.

The basic (simplified!) sequence of decision for incoming TCH requests is 1. Preemption -> if not possible, then 2. Directed Retry -> if not possible, then 3. Queuing

Notes: - The forced handover due to preemption is only attempted if the flag ENFORCHO (SET BSC [BASICS]) is set to ENABLE. If this is not the case 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 additional handover of the preempted call in the target cell. This has to be considered 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 or a HANDOVER REQUEST received in case of incoming MSC-controlled handover) cannot be served due to TCH congestion. If queuing 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 cell queue 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 policy The cell queue consists of a set of queue places all having the same characteristics. All places may be used by all 14 priority levels. TCH requests 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, 14 the lowest priority). Technically each cell has 14 queues, one for each priority. When a TCH becomes available (i.e. released by the previous call or it is returned to service) while TCH requests are queued, the TCH is assigned to the first TCH request of the queue (with the highest priority) and the TCH request is removed from the queue. If the queue is full and an incoming TCH request is has a higher priority than at least one of the queued requests, the TCH requests in the queue are re-ordered in order to insert the new request and to exclude the (youngest) lowest priority one (resulting in a rejection of the TCH request with an ASSIGNMENT FAILURE or HANDOVER FAILURE with cause ‘no radio resource available’). If the queue is full and the new TCH request is lower than the lowest queued one, the request is rejected in the same way as described above. The maximum length of the queue is determined by the parameter QL (see below). Queued TCH requests can be discarded from the queue a) if further TCH requests with a higher priority are received or b) if (for the TCH assignment case) during the queuing time an SDCCH HO attempt fails. In these cases an ASSIGNMENT FAILURE message (for assignment requests) resp. a HANDOVER FAILURE message (for inc. HO requests) with cause ‘no radio resource available’ are sent to the MSC. Moreover, the maximum queuing time is restricted by administrable timers: for assignment requests the maximum queuing time is determined by the timer T11 (see BSCT11 in SET BSC [TIMER]) and for incoming MSC-controlled HO requests it is determined by the timer TQHO (see BSCTQHO in SET BSC [TIMER]). If T11 expires, the BSC sends a CLEAR REQUEST message with cause ‘no radio resource available’ to the MSC and the requesting connection is released. If TQHO expires in case of incoming MSC-controlled HO, the TCH request is rejected with a HANDOVER 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 parameter EPRE below) is allowed for the TCH request. Notes: - In case of MSC-controlled HO the Siemens MSC first attempts the HO REQ procedure for all target cells (previously received in the HO RQD message) with the ‘Queuing Allowed Indicator’ set to ‘not allowed’! Only if these attempts are not successful the MSC repeats the HO REQ procedure with the ‘Queuing Allowed Indicator’ set to ‘allowed’! This means that only for this second cycle queuing can be performed by the BSC. - If the BSC receives an INTERCELL HANDOVER CONDITION INDICATION from the BTS during the queuing time, the BSC directly searches for an idle TCH in the target cell! In other words, during the



queuing time no SDCCH-SDCCH handover will ever be performed. If no TCH can be found in the target cells, the TCH request is discarded from the queue.

HOPMODE=BBHOP,


range: BBHOP, SYNHOP

default: BBHOP

Hopping Mode, this parameter indicates whether baseband hopping or synthesizer hopping is to be used in this cell. Basband Frequency Hopping features a continuous switching of the BBSIG responsible for a particular TRX to different TPUs. In other words, the hopping is executed by switching one and the same BBSIG among different TPUs in correspondence with the configured hopping sequence (see command CREATE FHSY). The number of frequencies in the frequency hopping system (mobile allocation) is restricted to the number of TRXs configured in the cell. If baseband frequency hopping is used, it is the hopping system (FHSY) may include also channels of the BCCH TRX.

Synthesizer Frequency Hopping features a continuous re-tuning of the TPU/CU in correspondence with the created in correspondence with the configured hopping sequence. The advantage of synthesizer hopping is that it is possible to define frequency hopping systems with more frequencies than TRXs are available in the BTS. Synthesizer FH requires specific HW (e.g. filter combiners are not allowed) and is not allowed on the BCCH-TRX.

Note: The implementation of frequency baseband hopping shows the following difference regarding the two BTSE generations, i.e. BTS1 and BTSplus: - in the BTS1 baseband hopping is realized by multiplexing different TPUs to one BBSIG. The TX and RX paths are tied together by switching TX & RX at the same time;

- the BTSplus' implementation is different to the BTS1. Here baseband hopping is exclusively used in downlink direction whereas in uplink direction always synthesizer hopping is applied. Downlink data is pre-processed in the TRX related CU, but the burst data is then sent via the CU whose carrier frequency is equal to that of the currently calculated burst. Thus, for a call, a single RX path is used with multiple TX paths; so there are as many TX/RX pairings for the call as the number of transmitters in use.

Since the mobile reports the measured RXLEV_DL values with a fixed period of 480ms (= 104TDMA bursts), no mapping is possible on TDMA burst base for the DL measurements. Due to the averaging effect this means that failures in the RF-TX signal path which are located in carrier specific parts may not be reliably detected in case baseband hopping is applied (both for BTS1 and BTSplus). For this reason the feature “ Online Rf Loopback “ does not work if baseband frequency hopping is configured.

In fact the MS will report an RXLEV_DL value which is the average of levels received from different RF-TX equipment (and so from different paths). On the other side, in uplink direction the BTSE knows which RX path is used per received burst.



IMSIATDT=TRUE,


range: TRUE, FALSE

default: TRUE


IMSI attach/detach enabled, This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) in the IE ‘Control Channel Description’, parameter ‘Attach/detach allowed’. If this parameter is set to TRUE the MSs are requested by the above mentioned BCCH parameter to send an ‘IMSI Attach’ message when they are switched on respectively an ‘IMSI Detach’ message when they are switched off. If an ‘IMSI Attach’ message is sent to the MSC the mobile subscriber is marked as ‘attached’ in the VLR. This means that the mobile subscriber is regarded as ‘reachable’ and paging is performed in case of an MTC. If an ‘IMSI Detach’ message is sent to the MSC the mobile subscriber is marked as ‘detached’ in the VLR, i.e. the VLR regards the mobile subscriber as ‘not reachable’ and rejects the call completion in case of MTC; paging is not performed in this case. The IMSI attach procedure is only used if the IMSI was deactivated while the MS was in ‘idle updated’ state before switch-off and the stored Location Area Identification is the same as the one which is actually broadcast on the BCCH of the current serving cell when it is switched on again. In the case of difference between the stored LAI and the one received on the BCCH of the current serving cell, a normal location updating procedure is invoked independently of the ‘attach’ flag indication. The ‘IMSI attach’ message is a LOCATION UPDATE REQUEST’ message with the parameter ‘Location Update Type’ set to ‘IMSI Attach’. For the ‘IMSI Detach’ procedure the message IMSI DETACH INDICATION is used.

NALLWACC=ALLALLOWED,


range: NA0..NA9, NA11..NA15,

default: ALLALLOWED


GSM 02.11

Not-allowed access classes, with this parameter the access classes 1 to 15 (the access class is stored on the SIM-card: classes 1-9 are ordinary subscribers, class 10 is a mobile emergency call, classes 11-15 are priorized subscribers) can be explicitly barred for access to the cell (except for class 10). The information stating which classes are barred is sent on the BCCH (SYSINFO Type 1, 2, 3 and 4) in the IE ‘RACH Control Parameters’. If the MS receives the indication that its access class is barred it remains camping in the cell but it is not allowed not perform a RACH access anymore. On the mobile phone, there is no special indication on the display if the SIM’s access class is barred while the MS is already booked in, the subscriber only notices an immediate call rejection when he tries to set up a call.

Notes: - The access class barring using NALLWACC is a semipermanent one, i.e. the access class barring remains active until the access classes are unbarred by a repeated entry of the command SET BTS using the appropriate setting of NALLWACC. The manual barring of access classes using NALLWACC is completely independent of automatic access class barring due to overload situations in the BSC, BTS or MSC (please see parameters BSCOVLH, BTSOVLH and MSCOVLH in command SET BSC). - For the MS there is a big difference between a barred cell (see parameter CELLBARR) and a barred access class! When the MS receives the “cell barred” indication in the SYSINFO, it immediately performs a cell reselection. If the SYSINFO indicates that its access class 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 thresholds, defines three power output thresholds: outputPowerFaultThreshold = defines the minimum output power level at the PA resp. CU which results in an alarm output to the BTSE core unit. reducedOutputPowerThreshold = defines the PA resp. CU output power level to initiate output of a warning. excessiveOutputPowerThreshold = defines the power level when a major alarm is generated due to too high output power.

The PA supervises its actual output power and compares it to the desired value. The desired value, i.e. the reference for the entered thresholds is the maximum output power of the PA resp. CU (depending on the type of PA resp. CU) minus the power reduction (see parameter PWRRED (CREATE TRX)).

QL=50,


range: 0..100

default: 50

Queue length, This attribute specifies the maximum number of TCH request that can be queued in the cell. This parameter is only relevant 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, timer for periodic location update. A recovery in the VLR normally leads to the loss of the subscriber data. Periodic location update is used to ensure the continuous update of subscriber data in the 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 has taken place on the radio path (e.g. Location update, MOC, IMSI Attach). When the MS is powered down the current value of T3212 is kept in memory. When the MS is powered up the timer starts running from the value thus contained in memory. On expiry the MS initiates a location updating. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) in the IE ‘Control Channel Description’. This timer must be set in consideration of the „Implicit Detach“ timer in the VLR (command in SIEMENS MSC: ENTR MOBTHR:IDETTIM=...) according to the following

Rule: T3212 < IDETTIM.

If the setting is vice versa, the MS may be set to ‘detached’ in the VLR even before it executes a Periodic Location Update.

Note: Some parameters of the command SET BTS [OPTIONS] appear at a later position when generated by the DBAEM. The command reappears after the CREATE CHAN commands with the parameters SMSCBUSE and HOPP. This order is necessary to ensure that SMS Cell Broadcast and Frequency Hopping may already be enabled when the DB is loaded to the system. Frequency Hopping and SMS-CB, however, can only be enabled if the CHAN objects are created accordingly (parameters FHSYID for frequency hopping and CHTYPE for SMS-CB).



Setting the cell specific attributes for Power Control:

� For detailed information regarding the Power Control thresholds please refer to the chapter Appendix, section “Power Control Thresholds & Algorithms” and “Interworking of Handover and Power 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 control correction, this parameter is necessary to ensure full handover functionality if BS power control is enabled while channels are created with frequency hopping system and the hopping system involves the BCCH TRX (baseband frequency hopping only, see parameter HOPMODE=BBHOP in command SET BTS BTS [OPTIONS]). Normally, if BS PWRC is enabled the MS is informed about this by a flag in the SYSTEM INFORMATION (see parameter EBSPWRC). This flag makes the MS suppress measurement reports derived from the BCCH carrier in order to avoid the measurements to be falsified by the ‘full power’ part of the BCCH (PWRC must not be used on the BCCH carrier). If frequency hopping is configured for the TCHs (see parameter FHSY and MAIO in command CREATE CHAN) but disabled, which can happen either if hopping is manually disabled (SET BTS [OPTIONS]: HOPP=FALSE) or automatically disabled (e.g. due to failure of a TRX involved in a baseband FH system) – a frequency redefinition procedure is started which instructs the MSs in a cell to change the hopping system in such a way that hopping shall continue with one frequency only (which is always that frequency which is assigned to the TRX by parameter TRXFREQ in command CREATE TRX). Calls that are served by a radio TCH which belongs to the BCCH TRX will in this case hop on the BCCH frequency only. In this case 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 the SYSTEM INFORMATION TYPE 6 even if the database parameter indicates the opposite (EBSPWRC=CLASSIC or EBSPWRC=ADAPTIVE). b) The MS thus provides valid measurement reports even for the BCCH carrier. c) The BTS takes care that the ‘full power’ part from the BCCH carrier is correctly subtracted from the DL RXLEV values reported in the MEASUREMENT REPORTs.

Note: the BS Power Control Correction is managed differently for AMR-calls and non-AMR calls (due to introduction of CR 1435) in correspondence with the following table:

EBSPWRC EBSPWCR PWRC -Flag in SYSINFO-6 and MEASINFO 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 control, determines whether the BTS dynamically adjusts its sending power according to the current radio conditions (on non-BCCH carriers). Enabling BS Power Control results in a minimization of the downlink interference on the radio interface. Whether the sending power is to be increased or decreased is determined from the downlink measurement reports the MS sends to the BTS. This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) or on the SACCH (SYSTEM INFORMATION TYPE 6) in the IE ‘Cell Options’.

Two variants of BS power control can be selected: CLASSIC power control and ADAPTIVE power control. While ‘classic’ BS power control exclusively uses fixed power increase steps (see parameter PWRINCSS) and fixed power reduction steps (see parameter PWREDSS), the ‘adaptive’ BS power control uses power increase and reduction step sizes that depend on the current radio conditions defined by RXLEV and REXQUAL values.

For further details about the power control decision process and classic and adaptive power control, please refer to the section ‘Power Control’ in the section “Classic and Adaptive Power Control” in the appendix of this document.

Note: Under specific conditions, the BS power control decision algorithm also checks the ‘missing SACCH’ counter (S-counter, initial value defined by RDLNKTBS): If no SACCH report was received in a particular SACCH period, no PC decision will be made for the DL. Field experiences have shown that under specific circumstances it can happen that, e.g. due to excessive path inbalance, the MS reports very good RXLEV_DL values, but the BTS cannot correctly decode all received SACCH frames in the UL. As the BS power control decision is based on the measurement samples stored in the averaging window (if an UL SACCH cannot be decoded, this just means that no new sample is inserted into the window), the RXLEV_DL average value could suggest a further DL power decrease. To avoid this behaviour, the following mechanism was implemented: If the S-counter is more than 2 below RDLNKTBS (i.e. either at least three SACCH reports in a row were missed or the current SACCH report is missing and additional SACCHs were missing before) then a normal BTS power increase will be commanded (if the interval timer is not running). Please consider that with the current default values (RDLNKTBS=20 and PCTHRLF=18) the abovementioned conditions are met (RDLNKTBS minus 2 counts) and thus PWRC will increase the power to the maximum instead of increasing the power by a normal power control step. If a power increase was executed the normal power control interval timer (PCONINT in case of ‘classic’, or PAVRQUAL in case of ‘adaptive’ power control) is started, so that a new power increase due to missing SACCH reports may only be triggered once the interval timer has expired. This way it is ensured that during periods of (or single) missing SACCH reports the DL power control does not further decrease the power but rather increases it in normal steps if the situation persists until the RLFW is triggered 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)


GSM 04.08

GSM 05.05

GSM 12.20

New value range in BR7.0!

Enable MS power control, determines whether the BTS instructs the MS to dynamically adjust its sending power according to the current radio conditions. MS Power Control is used to save MS battery capacity and to minimize the uplink interference on the radio interface. If MS power control is disabled, the BTS instructs every MS in the concerned cell to use the maximum RF output power as defined by the parameter MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS, see CREATE BTS [BASICS]) or by the MS power class - whichever is the lower. If MS power control is enabled the MS adjusts the power according to appropriate commands received from the BTS. The BTS generates these commands after evaluation of uplink measurement results.

Two variants of MS power control can be selected: CLASSIC power control and ADAPTIVE power control. While ‘classic’ MS power control exclusively uses fixed power increase steps (see parameter PWRINCSS) and fixed power reduction steps (see parameter PWREDSS), the ‘adaptive’ MS power control uses power increase and reduction step sizes that depend on the current radio conditions defined by RXLEV and REXQUAL values.

For further details about the power control decision process and classic and adaptive power control, please refer to the section ‘Power Control’ in the section “Classic and Adaptive Power Control” in the appendix of this document.

EPWCRLFW=TRUE,

object: PWRC

range: TRUE, FALSE

default: TRUE


MS and BS power control indication due to ‘radio link failure warning' enabled, this parameter enables/disables the “BS and MS power control due to radio link failure warning”. This feature checks the radio link counter (also called ‘S’ counter) in the BTS, whose initial value is determined by the parameter RDLNKTBS (see below) and which is decreased by ‘1’ if an UL SACCH frame could not be correctly decoded. As a not successfully decoded UL SACCH frame is a clear indication for serious radio interface problems, the BTS increases the MS and BS transmit power to the maximum when the radio 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 downlink, defines the lower threshold of the received signal level on the downlink for power increase. The following rule has to be considered: HOLTHLVDL (SET HAND) < LOWTLEVD

< [LOWTLEVD (SET PWRC) + 2∗PWREDSS (SET PWRC)] < UPTLEVD (SET PWRC)

LOWTLEVU=25,

object: PWRC

unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 25


Power control lower threshold level uplink, defines the lower threshold of the received signal level on the uplink for power increase. The following rule has to be considered: HOLTHLVUL (SET HAND) < LOWTLEVU

< [LOWTLEVU (SET PWRC) + 2∗PWREDSS (SET PWRC)] < UPTLEVU (SET PWRC)



LOWTQUAD=4,

object: PWRC

unit: 1 dB

range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%

2 = 0,4% to 0,8%

3 = 0,8% to 1,6%

4 = 1,6% to 3,2%

5 = 3,2% to 6,4%

6 = 6,4% to 12,8%

7 = greater than 12,8%

default: 4


Power control lower threshold quality downlink, defines the lower threshold of the received signal quality on the downlink for power increase. The following rule has to be considered: HOLTHQUDL (SET HAND) > LOWTQUAD (SET PWRC) > UPTQUAD (SET PWRC)

LOWTQUAMRDL=10,

object: PWRC

unit: 1 dB

range: 0 .. 30

default: 10

Power control lower threshold quality AMR downlink, this parameter eclipses the threshold LOWTQUAD in case of an AMR (Adaptive Multi Rate) call: For AMR calls, the power control algorithm increases the DL transmit power if the downlink quality drops below the threshold determined by LOWTQUAMRDL.

Attention: Unlike for the parameter LOWTQUAD, for which the quality values are entered in RXQUAL values (range 0..7), the values for LOWTQUAMRDL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way: - Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (range 0..7) in the MEASUREMENT REPORT messages. - From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter PAVRQUAL. The resulting average RXQUAL value is calculated with a resolution of two places (digits) after the comma (this is achieved by multiplying the RXQUAL values with 100 before averaging). - The resulting ‘high-precision’ RXQUAL value is then mapped to an integer 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

For a more detailed mapping table please refer to the section “Mapping of RXQUAL and C/I values for AMR calls” in the appendix of this document.

- The integer C/I value is then compared to the threshold determined by LOWTQUAMRDL. If it drops below the threshold, the BTS increases the DL transmit power.

Notes: - Although the total value range of LOWTQUAMRDL is 0..30, the mapping limits the maximum useful C/I value to 20dB (see mapping table above). C/I threshold values above 20dB therefore can never be reached and will not show any effect. - In order to achieve a suitable accuracy of the RXQUAL 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 quality uplink, defines the lower threshold of the received signal quality on the uplink for power increase. The following rule has to be considered: HOLTHQUUL (SET HAND) > LOWTQUAU (SET PWRC) > UPTQUAU (SET PWRC)

LOWTQUAMRUL=10,

object: PWRC

unit: 1 dB

range: 0..30

default: 10

Power control lower threshold quality AMR uplink, this parameter eclipses the threshold LOWTQUAU in case of an AMR (Adaptive Multi Rate) call: For AMR calls, the power control algorithm increases the DL transmit power if the uplink quality drops below the threshold determined by LOWTQUAMRUL.

Attention: Unlike for the parameter LOWTQUAU, for which the quality values are entered in RXQUAL values (range 0..7), the values for LOWTQUAMRUL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way: - As usual, the BTS measures the uplink quality in RXQUAL values (range 0..7). - From the measured RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter PAVRQUAL. The resulting average RXQUAL value is calculated with a resolution of two places (digits) after the comma (this is achieved by multiplying the RXQUAL values with 100 before averaging). - The resulting ‘high-precision’ RXQUAL value is then mapped to an integer C/I value according to the table included in the parameter description of LOWTQUAMRDL (see above). - The integer C/I value is then compared to the threshold determined by LOWTQUAMRUL. If it drops below the threshold, the BTS increases the UL transmit power.

Notes: - Although the total value range of LOWTQUAMRDL is 0..30, the mapping limits the maximum useful C/I value to 20dB (see mapping table for LOWTQAMRDL). C/I threshold values above 20dB therefore can never be reached and will not show any effect. - In order to achieve a suitable accuracy of the RXQUAL average value for AMR calls, it is recommended to use a minimum RXQUAL averaging window size of 4 (see parameter PAVRQUAL).



PAVRLEV=4-2,

object: PWRC

format: averaging period-

DTX weighting factor


=480ms

(averaging period)


1-3 (DTX weighting factor)


2 (DTX weighting factor)


Power control averaging parameters level, defines the averaging parameters for the RXLEV measurements.

Parameter format: averaging period - DTX weighting factor

All measurements for Power Control pass an averaging algorithm. The algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate the arithmetic average. The averaging window is called “gliding”, as the window works as a queue: when a new measurement is received, the oldest measurement is removed from the window.

The PAVRLEV “averaging period” defines the size of the gliding averaging window for the measured RXLEV values. The size of the averaging window determines the number of measurement samples (a new measurement sample is received every 480 ms from the MEASUREMENT REPORTs from the BTS and the MS) over which the BTS calculates the arithmetic average. This calculated value is finally used in the Power Control decision process.

The DTX weighting factor determines how much more the FULL values shall be weighted for radio measurement results measured over a period with voice activity (DTX not active).

Up to BR6.0, the higher weighting was implemented by the multiple insertion of the FULL measurement sample into the gliding averaging window. In other words, if the DTX weighting factor was set to “2”, FULL measurement samples from measurement periods with inactive DTX (speech transmitted) were inserted into the averaging window twice, while SUB measurement samples from measurement periods with active DTX (silence) were inserted into the averaging window only once (for further details about DTX and the meaning of FULL and SUB values please refer to the explanations provided for the parameter DTXDLFR).

Starting from BR7.0, this approach has been changed: FULL measurement samples values for non-DTX channels no longer entered n-times into the averaging window anymore but every value will be entered once. In addition, the current weighting factor is stored in parallel under the same offset as shown in the following picture:

Thus the time needed to fill the averaging window will always be the same (i.e. only dependent on the ‘laveraging period’ portion of the parameter PAVRLEV). The averaging window total is then calculated by adding up all sample values currently stored in the within 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).

Note: In the SDCCH phase there are no TCH speech frames. For this reason 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)


1-3 (DTX weighting factor)




Power control averaging parameters quality, defines the averaging parameters for the RXLEV measurements.


All measurements for Power Control pass an averaging algorithm. The algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate the arithmetic average. The averaging window is called “gliding”, as the window works as a queue: when a new measurement is received, the oldest measurement is removed from the window.

The PAVRLEV “averaging period” defines the size of the gliding averaging window for the measured RXQUAL values. The size of the averaging window determines the number of measurement samples (a new measurement sample is received every 480 ms from the MEASUREMENT REPORTs from the BTS and the MS) over which the BTS calculates the arithmetic average. This calculated value is finally 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 parameter PAVRLEV.

Notes: - In the SDCCH phase there are no TCH speech frames. For this reason 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 RXQUAL averaging window size of 4 in order to achieve a suitable accuracy of the RXQUAL average value for AMR calls.



PCMBSTXPRL=15,

object: PWRC

unit: 1 power reduction step =

2dB

range: 0..15

default: 15

Power control maximum BS TX power reduction Level, this parameter defines the maximum allowed dynamic power reduction. This maximum allowed power reduction affects all calls in the BTS for which BS power control is applied.

Basically the limit for the power reduction due to BS power control is determined by the lower power control threshold (LOWTLEVD, see below), i.e. BS power control does not adjust the power to a level lower than LOWTLEVD. The parameter PCMBSTXPRL, however, provides another possibility for a limitation of dynamic BS power reduction which is not related to an absolute DL RXLEV value (like LOWTLEVD) but to the relative power reduction with respect to the maximum possible DL receive level (that applied before start of power reduction) for a call.

There are two types of power reduction: static power reduction and dynamic power reduction.

Static power reduction is a continuous power reduction which is applied to a particular TRX by the parameter PWRRED (see command CREATE TRX). The purpose of this parameter is basically to adapt the transmit power of the used CU or PA type to the actual size and radio propagation conditions of a particular cell.

Dynamic power reduction is performed by BS or MS power control in order to adjust the MS and BS transmit level in correspondence with the radio conditions of an individual call.

PCMBSTXPRL determines the maximum dynamic power reduction which may be applied to a call in the cell. This reduction is applied in addition 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 power reduction steps supported by the BTSE (related to the maximum nominal output power of the used CU resp. PA), which depends on the type and generation of BTSE in correspondence with the following 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 of 2 SACCH multiframes) between two successive modifications of the BTS or MS transmission power level. I.e. the BTS or MS power control 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 power control (PWRC) algorithm determines whether a power increase or decrease is necessary based on the current BTS/MS averaged level and quality values (see also averaging window settings PAVRLEV/PAVRQUAL). In case a power level was changed a timer with the length defined by PCONINT is started (immediately if the BTS power level was changed and in case of a MS power level change only after the MS has confirmed the new power level – see also PWRCONF). While this timer is running (there are independent timers for BTS and MS PWRC) the PWRC algorithm continues to fill the respective level and quality averaging windows with new measurement samples. In order to allow for the most exact PWRC decisions the averaging windows should be filled completely with new measurement samples that reflect the state after the power level change. Therefore the value of PCONINT should correspond to the size of the level or quality averaging window (whichever is longer):



e.g. PAVRLEV/PAVRQUAL=4-x � PCONINT=2, wait 4 SACCH multiframes (since the granularity of PCONINT is 2 SACCH multiframes the value should be rounded to the next higher value in case the longest averaging window length has an odd value).

If the PWRC mode is set to 'adaptive' (see parameters EBSPWRC and EMSPWRC) this suspension timer will only be started if the power level was changed due to a decision based on signal quality, since with the 'adaptive' mode the level samples will be automatically corrected by the value of the power level change and therefore PWRC can resume immediately after a level based decision without having to wait for the collection of new level samples. Since the suspension timer is now only started in case of quality based decisions and the level samples are automatically corrected, there is only the need to wait for the collection of all new quality samples. Therefore the PWRC algorithm sets the timer length automatically to the time needed to re-fill the quality averaging window, so that the value of PCONINT is not relevant in case of the 'adaptive' PWRC mode!

PCRLFTH=18,

object: PWRC

range: 0..64

default: 18


Power control radio link failure threshold, this parameter is only relevant if the parameter EPWCRLFW (see above) is set to TRUE. It defines the threshold value for the radio link counter in the BTS for the ‘radio link failure warning’ detection. If the radio link counter in the BTS reaches the value of PCRLFTH, the BTS immediately increases the BS and MS transmit power to the maximum.

Please see also parameter RDLNKTBS.

PWRCONF=2,

object: PWRC


range: 1-31

default: 2


Power confirmation interval, defines the maximum interval that the BTS will wait for the confirmation of a newly set RF power level by the MS in units of 2 SACCH multiframes. The timer administered with PWRCONF is started after a new MS power level was set. As long as this timer is running the BTS compares the received MS power level with the requested power level. If the timer expires before the MS confirmed the requested power level the power control decision process is resumed.

PWRINCSS=DB6,

object: PWRC

unit: 2dB

range: DB2, DB4, DB6

default: DB6


Power increase step size, defines the step size used when increasing the MS transmit power.

PWREDSS=DB2,

object: PWRC

unit: 2dB

range: DB2, DB4

default: DB2


Power reduction step size, defines the step size used when reducing 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 link counter BS, indicates the maximum value of the radio link counter needed to detect a radio link failure in the uplink. The entered value is the start point for the ‘radio link counter’ (also called ‘missing SACCH’ counter or ‘Scounter’) in the BTS which is managed for every dedicated channel (TCH or SDCCH). Unsuccessful decoding of uplink SACCH messages (i.e. MEASUREMENT REPORTs) in the BTS lead to a decrease of the counter by 1, successful decoding to an increase by 2 (a similar counter for the observation of raio link problems is also used in the MS (see parameter RDLNKTO in command CREATE BTS [BASICS]). If the parameter EPWCRLFW is set to TRUE and the BTS radio link counter counter reaches the value entered for the parameter PCRLFTH (see above) the BTS initiates the adjustment of the MS transmit power and BS transmit power to maximum transmit power. If the counter reaches the value 0 (‘radio link timeout’), the BTS sendes a CONNECTION FAILURE INDICATION with cause 'radio link failure' to the BSC which initiates the release of the whole dedicated connection. This scenario represents (together with the ERROR INDICATION with cause ‘T200 expired (N200+1) times’ (see parameter T200 in command SET BTS [TIMER])) the most common and ‘classic’ case of a call drop.

Rule: RDLNKTBS > PCRLFTH .

Notes: - An expiry of the radio link counter in the MS (see RDLNKTO in command CREATE BTS [BASICS]) also indirectly leads to the ‘radio link timeout’ in the BTS, as in this case the MS stops any transmission activity on the dedicated channel. This leads to unsuccessful decoding of UL SACCH frames in the BTS (as the MS does not send any SACCH frames anymore) and thus to the continuous decrease of the BTS radio link counter. - The current value of the S-Counter in the BTS is also checked in the scope of the BS power control (parameter EBSPWRC, see above) decision: If no SACCH report was received in a particular SACCH 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 least three SACCH reports in a row were missed or the current SACCH report is missing and additional SACCHs were missing before) then a normal BTS power increase will be commanded.

SG1PCPAR=<NULL>,

object: PWRC

range: <NULL>,

12 fields with ranges in

correspomdemce with the

PWRC parameters they

represent.

default: <NULL>

Service group 1 power control parameters, this parameter is the first of the 14 parameters which allows a service group-dependent setting of power control parameters and thresholds.

The setting <NULL> indicates that for this service group no specific parameter settings are applied and the power controld decision for this service group is based the ordinary PWRC parameter settings.

Fo further details please refer to the section “Service dependent Handover and Power Control” in the appendix of this document.

SG2PCPAR...SG14PCPAR=<NULL>,

object: PWRC

range: <NULL>,

n fields with ranges in

correspondence with the


represent.

default: <NULL>

Service group 2..14 power control 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 no specific parameter settings are applied and the power controld decision for this service group is based the ordinary PWRC parameter settings.




UPTLEVD=36,

object: PWRC

unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 35


Power control upper threshold level downlink, defines the upper threshold of the received signal level on the downlink for power reduction. The following rule has to be considered: UPTLEVD (SET PWRC)

> [LOWTLEVD (SET PWRC) + 2∗PWREDSS (SET PWRC)] > LOWTLEVD > HOLTHLVDL (SET HAND)

To guarantee a correct interworking of power control and intracell handover, the following rule must be fulfilled:

UPTLEVD > HOTDLINT

For further details please refer to the section ‘Handover Thresholds and Algorithms’ in the appendix of this document.

UPTLEVU=36,

object: PWRC

unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


range: 0..63

default: 35


Power control upper threshold level uplink, defines the upper threshold of the received signal level on the uplink for power reduction. The following rule has to be considered: UPTLEVU (SET PWRC)

> [LOWTLEVU (SET PWRC) + 2∗PWREDSS (SET PWRC)] > LOWTLEVU > HOLTHLVUL (SET HAND)


UPTLEVU > HOTULINT


UPTQUAD=2,

object: PWRC

range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%

2 = 0,4% to 0,8%

3 = 0,8% to 1,6%

4 = 1,6% to 3,2%

5 = 3,2% to 6,4%

6 = 6,4% to 12,8%


default: 2


Power control upper threshold quality downlink, defines the upper 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 quality AMR downlink, this parameter eclipses the threshold UPTQUAD in case of an AMR (Adaptive Multi Rate) call: For AMR calls, the power control algorithm reduces the DL transmit power if the downlink quality exceeds the threshold determined by LOWTQUAMRDL.

Attention: Unlike for the parameter UPTQUAD, for which the quality values are entered in RXQUAL values (range 0..7), the values for UPTQUAMRDL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way: - Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (range 0..7) in the MEASUREMENT REPORT messages. - From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter PAVRQUAL. The resulting average RXQUAL value is calculated with a resolution of two places (digits) after the comma (this is achieved by multiplying the RXQUAL values with 100 before averaging). - The resulting ‘high-precision’ RXQUAL value is then mapped to an integer C/I value according to the following table:


6,88 ... 7 1 3,88 ... 4,12 12

6,63 ... 6,87 2 3,38 ... 3,87 13

6,38 ... 6,62 4 2,88 ... 3,37 14

6,13 ... 6,37 5 2,63 ... 2,87 15

5,88 ... 6,12 6 2,13 ... 2,62 16

5,63 ... 5,87 7 1,63 ... 2,12 17

5,13 ... 5,62 8 1,13 ... 1,62 18

4,88 ... 5,12 9 0,38 ... 1,12 19

4,63 ... 4,87 10 0 ... 0,37 20

4,13 ... 4,62 11


- The integer C/I value is then compared to the threshold determined by UPTQUAMRDL. If it exceeds the threshold, the BTS reduces the DL transmit power.

Notes: - Although the total value range of UPTQUAMRDL is 0..30, the mapping limits the maximum useful C/I value to 20dB (see mapping table above). C/I threshold values above 20dB therefore can never be reached and will not show any effect. - In order to achieve a suitable accuracy of the RXQUAL average value for AMR calls, it is recommended to use a minimum RXQUAL averaging window size of 4 (see parameter PAVRQUAL).

UPTQUAMRUL=13,

object: PWRC

unit: 1 dB

range: 0..30

default: 13

Power control upper threshold quality AMR uplink, this parameter eclipses the threshold UPTQUAU in case of an AMR (Adaptive Multi Rate) call: For AMR calls, the power control algorithm reduces the UL transmit power if the uplink quality exceeds the threshold determined by UPTQUAMRUL.

Attention: Unlike for the parameter UPTQUAU, for which the quality values are entered in RXQUAL values (range 0..7), the values for UPTQUAMRUL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way: - As usual, the BTS measures the uplink quality in RXQUAL values



(range 0..7). - From the measured RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter PAVRQUAL. The resulting average RXQUAL value is calculated with a resolution of two places (digits) after the comma (this is achieved by multiplying the RXQUAL values with 100 before averaging). - The resulting ‘high-precision’ RXQUAL value is then mapped to an integer C/I value according to the table included in the parameter description of UPTQUAMRDL (see above). - The integer C/I value is then compared to the threshold determined by UPTQUAMRUL. If it exceeds the threshold, the BTS reduces the UL transmit power.

Notes: - Although the total value range of LOWTQUAMRDL is 0..30, the mapping limits the maximum useful C/I value to 20dB (see mapping table for UPTQUAMRDL). C/I threshold values above 20dB therefore can never be reached and will not show any effect. - In order to achieve a suitable accuracy of the RXQUAL average value for AMR calls, it is recommended to use a minimum RXQUAL averaging 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 quality uplink, defines the upper threshold of the received signal quality on the uplink for power reduction. The following rule has to be considered: UPTQUAU (SET PWRC) < LOWTQUAU (SET PWRC) < HOLTHQUUL (SET HAND)



Power Control Parameter Relations

Power Control

Power Control Indiaction due to link failure warning

PWRC: EPWCRLFW

PCRLFTH

RDLNKTBS

BS Power Control

PWRC: EBSPWRC

LOWTLEVD

LOWTQUAD

(is for AMR replaced by

LOWTQAMRDL)

UPTLEVD

UPTQUAD


UPTQAMRDL)

EBSPWCR

PCMBSTXPRL

MS Power Control

PWRC: EMSPWRC

LOWTLEVU

LOWTQUAU


LOWTQAMRUL)

UPTLEVU

UPTQUAU


UPTQAMRUL)

Parameters relevant for both MS and BS Power Control

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 service in a cell. In GSM 08.18, for point to point packet transfer, it is specified that a cell is identified by a BVCI so there is a relation one to one from cell and BVCI. The BVCI is allocated by the system to each PTPPKF according to the creation position in the database: BVCI=2 for the first PTPPKF, BVCI=3 for the second PTPPKF, etc. >

CREATE PTPPKF:

NAME= BTSM:0/BTS:0/PTPPKF:0,

Object path name, range for PTPPKF: 0..0.

ABUTYP=ACBU8BIT,

object: PTPPKF

range: ACBU8BIT, ACBU11BIT

default: ACBU8BIT


Access burst type, this parameter indicates the type of access burst used on uplink PDCH (PACCH or PRACH). The value ACBU8BIT means that the 8 bits access burst shall be used by the mobile station and ACBU11BIT means that 11 bits access bursts shall be used by mobile station (see GSM 05.02). Access Bursts are mainly used on the PRACH to access the system or – currently more common – as blocks of four identical access bursts 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 in the UL power control algorithm used with GPRS/EDGE. The MS uses an UL power value according to GSM 05.08: Pch = min (Γ0 – Γch – α * (C + 48), Pmax) - Pch is the MS ouput power - Γ0 is a constant value - Γch is given by the parameter GAM (object PTPPKF) - C is the normalized receive level at the MS - Pmax is the maximum MS output power Based on the above formula, the parameter ALPHA determines the influence 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 probability averaging period, this parameter is broadcast inside the (packet) system information messages PSI1, PSI13 or SI13. It is used in the mobile as filter constant for EGPRS channel quality measurements according to GSM 45.008 Chapter 10.2.3.2.1. The measurement results are reported to the network as EGPRS Channel 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: UNIT400

Reference:

recommended value : UNIT200

Block error rate averaging period downlink, this parameter is relevant for GPRS and EDGE and is used as averaging period for the Block Error Rate (BLER) calculation for a downlink TBF. The BLER value is used as base for the link adaptation algorithm (dynamic switch of coding schemes). The BLERAVDL value is based on frame periods of 20 ms, thus the unit for the entered value is 20ms. The averaging period for BLER calculation additionally depends on the number of radio timeslots allocated to a TBF and is calculated according to the following formula:

TAVGBLER = BLERAVEDL ∗ 20ms / #TS

where TAVGBLER = BLER averaging period #TS = number of radio timeslots used for the TBF

As a coding scheme upgrade or downgrade is only possible when the BLER averaging window was completely filled, TAVGBLER also defines the minimum time to pass between two consecutive upgrade/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 time between 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. three transitions) theoretically takes a minimum of 24 seconds.

BLERAVEUL=UNIT100,

object: PTPPKF

range: UNIT025, UNIT050

UNIT075, UNIT100

UNIT150, UNIT200

UNIT250, UNIT300

UNIT350, UNIT400

default: UNIT400

Reference:

recommended value : UNIT100

Block error rate averaging period uplink, this parameter is relevant for GPRS and EDGE and is used as averaging period for the Block Error Rate (BLER) calculation for an uplink TBF. The value is expressed in unit of 20 ms. The averaging period depends also on the number of radio timeslots (#TS) allocated to a radio timeslots, according to the formula:

TAVGBLER = BLERAVEUL / #TS.

Please refer to the parameter BLERAVEDL for further details.

BPAGCHR=7,

object: PTPPKF

range: 0..12

default: 7


BS PAGCH blocks reserved, this parameter specifies the number of blocks reserved for PAGCH, PDTCH and PACCH for the 52 frames multiframe case (see GSM 05.02). The parameter is coded according to the following table:

0 0 0 0 0 blocks reserved for PAGCH, PDTCH and PACCH 0 0 0 1 1 blocks reserved for PAGCH, PDTCH and PACCH … …

1 1 0 0 12 blocks reserved for PAGCH, PDTCH and PACCH

This parameter corresponds to the GSM parameter BS_PAG_BLKS_RES. Note: The system does not refuse entering senseless values which may cause blocking of the PBCCH functionality itself (e.g. reserving 12 PAGCH blocks leaving no PPCH blocks!).



BPRACHR=4,

object: PTPPKF

range: 0..12

default: 4


BS PRACH blocks reserved, this parameter specifies the number of blocks reserved in a fixed way to the PRACH channel on any PDCH carrying PCCCH and PBCCH (see GSM 05.02). The parameter is coded according to the following table:

coding blocks reserved for PRACH

0 0 0 0 none (default) 0 0 0 1 Block B0 0 0 1 0 Block B0, B6 0 0 1 1 Block B0, B6, B3 0 1 0 0 Block B0, B6, B3, B9 0 1 0 1 Block B0, B6, B3, B9, B1 0 1 1 0 Block B0, B6, B3, B9, B1, B7 0 1 1 1 Block B0, B6, B3, B9, B1, B7, B4 1 0 0 0 Block B0, B6, B3, B9, B1, B7, B4, B10 1 0 0 1 Block B0, B6, B3, B9, B1, B7, B4, B10, B2 1 0 1 0 Block B0, B6, B3, B9, B1, B7, B4, B10, B2, B8 1 0 1 1 Block B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5 1 1 0 0 Block B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11

This parameter corresponds to the GSM parameter BS_PRACH_BLKS. Note: Also for this parameter the system does not refuse entering senseless values which may cause blocking of the PBCCH functionality itself (e.g. reserving 0 PRACH blocks allows no more packet accesses in the cell!).

BSCDVMA=10,

object: PTPPKF

range: 1-15

default: 15



Maximum BSC countdown value, this parameter is used during the countdown procedure when terminating an UL TBF. The mobile includes the Countdown Value CV in each uplink data block to indicate the last Block Sequence Number (BSN=0) that is sent in the UL TBF. As soon as the MS transmits the first data block indicating a CV value different to 15 (starting with BSCDVMA), the mobile will send exactly BSCDVMA more blocks until the UL TBF is completed. Example: Using BSCDVMA=10 will result in a CV sequence similar to: 15,15, … 15,10,9,8,7,6,5,4,3,2,1,0 Any UL data arriving from higher layers after the countdown procedure has started on RLC/MAC shall be sent within a future TBF. Thus using a smaller BSCDVMA value may allow (internally) ‘slow’ mobiles to continue the UL data transfer without opening a new TBF.

This parameter corresponds to the GSM parameter BS_CV_MAX. Its value 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 blocks allocated to the PBCCH in the multiframe. The field is coded according to the following table:

0 0 Block B0 used for PBCCH 0 1 Block B0, B6 used for PBCCH 1 0 Block B0, B6, B3 used for PBCCH 1 1 Block B0, B6, B3, B9 used for PBCCH

This parameter corresponds to the GSM parameter BS_PBCCH_BLKS.



BVCBHIPER=PER70,

object: PTPPKF


PER80, PER90

default: PER70

Reference:

BVC bucket high percentage. If BVC Bucket Level is greater than BVCBHIPER * BVC Bucket Size PCU, the ‘Bucket Congestion’ state is activated. As a consequence, the Flow Control Algorithm will reduce the reported leak rate ‘R’ inside the FLOW-CONTROL-BVC PDU, thus limiting the amount of data being sent from the SGSN towards the BSC. If the congestion state persists, the leak rate is further 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 than BVCBHIPER * BVC Bucket Size PCU, the ‘Bucket Congestion’ state is ceased. As soon as the congestion state is cleared, the leak rate ‘R’ inside the FLOW-CONTROL-BVC PDU is set to its original value and the SGSN may increase the data rate sent towards the BSC.


BVCBMAPER=PER100,

object: PTPPKF


PER040, PER050, PER060


PER100, PER110, PER120,



PER190 PER200

default: PER100

Reference: GSM08.18

BVC bucket max percentage defines the value of the BVC Bucket Size (Bmax) reported in the FLOW-CONTROL-BVC PDU towards the SGSN:

BVC Bucket Size = BVCBMAPER * (C + 1 sec.) * Rmax

- C corresponds to the parameter TF1 (object PCU) - Rmax is the maximum rate assigned to that BVC: Number of timeslots that can be assigned to GPRS/EDGE in this cell multiplied by the respective maximum rate per TS..


BVCBSPPER=PER200,

object: PTPPKF




PER190 PER200

default: PER200

Reference:

BVC bucket size PCU percentage.This parameter specifies the ‘BVC Bucket Size PCU’ value based on the ‘BVC Bucket Size’ value Bmax reported to the SGSN.

BVC Bucket Size PCU = BVCBSPPER * BVC Bucket Size

It represents the buffer space ‘reserved’ in the PCU for this BVC. The BVC congestion thresholds (BVCBHIPER, BVCBLPER) are based on this value. Caution: It is strictly recommended to maintain the default value!

C31H=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE


GPRS C31 hysteresis, this attribute indicates if the GPRS reselect hysteresis (GCELLRESH) shall be applied to the C31 criterion (in ready state if the new cell is in the same RA). This parameter corresponds to the GSM parameter C31_HYSTERESIS.

C32QUAL=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE


GPRS C32 qualifier. If C32_QUAL is set, positive GPRS_RESELECT_OFFSET values are only applied to the neighbour cell with the highest RLA value of those cells for which C32 is compared.

This parameter corresponds to the GSM parameter C32_QUALIFIER.



CACKTYP=0,

object: PTPPKF

range: 0..1

default: 0


Control acknowledgement type, this parameter indicates the format of the PACKET CONTROL ACKNOWLEDGEMENT message the MS shall transmit when polled. The meaning of the parameter values is:

0 PACKET CONTROL ACKNOWLEDGEMENT format is four access bursts

1 PACKET CONTROL ACKNOWLEDGEMENT format is RLC/MAC control block

Since BR55/10 onwards this parameter is hardcoded to the value ‘0’ (four access bursts format)!

This parameter corresponds to the GSM parameter CONTROL_ACK_TYPE.

CRESELTRHSOUT=85,

object: PTPPKF

range: 50..100

default: 85

Reference:

Cell reselection threshold output, this parameter specifies the minimum traffic load threshold above which mobiles in packet transfer mode may be moved out of the cell for load balancing purpose.

The GPRS traffic control strategy is based on the feature Network Controlled Cell Reselection (NCCR). If NCCR is activated in the cell (NCRESELFLAG = TRUE), the traffic control feature may be additionally enabled by setting TRFPS = TRUE.

If the GPRS load in the source cell exceeds a certain threshold (CRESELTRHSOUT), the BSC starts to move TBFs to neighbour cells. This is done as long as the load in the source cell remains above NCTRFPSCTH and the available target cells are loaded with less packet load than given with the parameter CRESELTRHINP.

Notes: - The traffic control strategy is only applicable between cells belonging to the same PCU. An example for calculating the ‘traffic percentage values’ is available in the GPRS Global Description or in the ATMN Testcase AC701683. - CRESELTRHSOUT is a kind of equivalent to the parameter TRFHITH (see command SET HAND [BASICS]) for CS call ‘traffic handover’.

CRESELTHRINP=75, object: PTPPKF

range: 0.. 85

default: 75

Reference:

Cell reselection threshold input, this parameter specifies the maximum traffic load threshold allowed in a cell to be considered as potential target. Please refer to the parameter CRESELTRHSOUT for further details.

Note: CRESELTHRINP is a kind of equivalent to the parameter TRFLTH (see command SET HAND [BASICS]) for CS call ‘traffic handover’.

CSCH3CSCH4SUP=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

CS3 and CS4 support, this parameter allows to enable or disable the feature GPRS Coding Scheme 3 and Coding Scheme 4 in the BTS associated to the PTPPKF object. This flag may only be set if the same parameter available in the BSC object was set to TRUE already (see parameter CSCH3CSCH4SUP in command SET BSC [BASICS]). Please refer to the aforementioned parameter in the BSC object for further details.



DRXTMA=0,

object: PTPPKF

range: 0..7

default: 7


Maximum discontinuous receipt timer, this parameter indicates the maximum time allowed for the mobile station to request for Non-DRX mode after packet transfer mode. Each MS selects the value that it prefers and forwards this info within the ATTACH REQUEST message towards the SGSN.

The parameter is coded according to the following table and broadcast on the BCCH/PBCCH within the PSI1 and (P)SI13 messages:

0 0 0 No Non-DRX mode after packet transfer mode 0 0 1 1 sec. non-DRX mode after packet transfer mode 0 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 parameter DRX_TIMER_MAX.

EGPLGPEIGHTTS=16,

object: PTPPKF


default: 16

Reference:

EGPRS polling period eight time slots, this parameter specifies the polling period to be used if eight timeslots are assigned. Its value is given 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 a single PDCHis allocated and only 40ms in case 8 PDCHs are allocated to that TBF.

The polling period is a decisive factor in case RLC/MAC acknowledged mode is used. The more often the network polls the mobile for EPDAN messages, the earlier it can retransmit not acknowledged RLC/MAC blocks. This generally helps to increase the data transfer speed under real network conditions (BLER>0).

EGPLGPFIVETS=16,

object: PTPPKF


default: 16

Reference:

EGPRS polling period 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 polling period four time slots, this parameter specifies the polling period to be used if four timeslots are assigned.

EGPLGPONETS=8,

object: PTPPKF


default: 16

Reference:


EGPRS polling period 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 polling period 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 polling period six time slots, this parameter specifies the polling period to be used if six timeslots are assigned.



EGPLGPTHREETS=16,

object: PTPPKF


default: 16

Reference:


EGPRS polling period three time slots, this parameter specifies the polling period to be used if three timeslots are assigned.

EGPLGPTWOTS=8,

object: PTPPKF


default: 16

Reference:


EGPRS polling period two 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 window size eight time slots, this parameter specifies the window size to be used if eight timeslots are assigned.

The value is transferred to the MS within the PDAS, PUAS or PTR messages and is applied for both the UL and DL case. The biggest window size possible for each of the 8 following parameters (1-8 timeslots) is used as respective default value.

For GPRS transfers a fixed window size of 64 blocks is applied.

EGWSFIVETS=WS128,

object: PTPPKF


WS160, WS192, WS224,

WS256, WS288, WS320,

WS352, WS384, WS416,

WS448, WS480, WS512,

WS544, WS576, WS608,

WS640

<NULL>

default: WS640

Reference:

EGPRS window size five time slots, this parameter specifies the window 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 window size four time slots, this parameter specifies the window size to be used if four timeslots are assigned.

EGWSONETS=WS64,

object: PTPPKF


WS160, WS192,

<NULL>

default: WS192

Reference:

EGPRS window size one time slot, this parameter specifies the window size to be used if one timeslot is assigned.

EGWSSEVENTS=WS160,

object: PTPPKF


WS160, WS192, WS224,

WS256, WS288, WS320,

WS352, WS384, WS416,

EGPRS window size seven time slots, this parameter specifies the window size to be used if seven timeslots are assigned.



WS448, WS480, WS512,

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 window size six time slots, this parameter specifies the window 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 window size three time slots, this parameter specifies the window size to be used if three timeslots are assigned.

EGWSTWOTS=WS64,

object: PTPPKF


WS160, WS192, WS224,

WS256,

<NULL>

default: WS256

Reference:

EGPRS window size two slots, this parameter specifies the window size to be used if two timeslots are assigned.

ELKADPT=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable link adaptation, this parameter enables/disables the GPRS/EGPRS coding scheme Link Adaptation (LA).

This feature adapts the used coding scheme to the current radio conditions. The system continuously evaluates the Block Erasure Rate (BLER) values during a packet transfer and switches, if required, to a lower or higher coding scheme. The decision is based on two internal tables. The use of the two different tables is controlled by the parameter RAENV (object PTPPKF, see below), the decision averaging speed for coding scheme changes is controlled by the parameters BLERAVEUL and BLERAVEDL (object PTPPKF, see above).

EMCSFAMA1DL=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE

Enable MCS family A MSC1 downlink, this parameter enables all coding schemes belonging to Family A plus MCS1 to be used for downlink TBFs. Family A consists of: MCS3, MCS6, MCS9

EMCSFAMAP1DL=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family A padding MSC1 downlink, this parameter all coding schemes belonging to Family A Padding plus MCS1 to be used 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 downlink, this parameter enables all coding schemes belonging to Family B plus MCS1 to be used for downlink TBFs. Family B consists of: MCS2, MCS5, MCS7

EMCSFAMCDL=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family C downlink, 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 downlink, this parameter enables all coding schemes with GMSK modulation to be used for downlink TBFs.

Coding schemes using GMSK are: MCS1, MCS2, MCS3, MCS4

EMFA1UNIR8PSK=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE

Enable MCS family A MCS1 uplink without incremental redundancy 8PSK, this parameter enables all coding schemes belonging to Family A plus MCS1 to be used for uplink TBFs.

Family A consists of: MCS3, MCS6, MCS9

Note: Incremental Redundancy (IR) in uplink direction is not supported in BR70. In downlink direction IR is applied by the BSC and all mobiles have to support it according to specifications.

EMFAP1UNIR8PSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family A padding MCS1 uplink without incremental redundancy 8PSK, this parameter enables all coding schemes belonging to Family A Padding plus MCS1 to be used for uplink TBFs.

Family A consists of: MCS3, MCS6; MCS8


EMFB1UNIR8PSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family B MCS1 uplink without incremental 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 uplink without incremental redundancy 8PSK, this parameter enables all coding schemes belonging to Family 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 uplink without incremental redundancy GMSK, this parameter enables the GMSK coding schemes belonging to Family C to be used for uplink TBFs in case the MS does not support 8PSK.

EMFGUNIR8PSK=FALSE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Enable MCS family GMSK uplink without incremental redundancy 8PSK, this parameter enables all GMSK coding schemes (MCS1-MCS4) to be used for uplink TBFs in case the MS supports 8PSK.

EMFGUNIRGMSK=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE

Enable MCS family GMSK uplink without incremental redundancy GMSK, this parameter enables all GMSK coding schemes (MCS1-MCS4) to be used for uplink TBFs in case the MS does not support 8PSK.



FDDGQO=10..20,

object: PTPPKF

range: ALWAYS MDB28

MDB24 MDB20

MDB16 MDB12

MDB08 MDB04

DB00 DB04 DB08

DB12 DB16 DB20

DB24 DB28 default: DB0

FDD GPRS Q offset, this parameter is related to multiRAT MSs considering a reselection towards an FDD cell; it indicates an offset which is applied to the RLA_P value of the serving cell.




The value ALWAYS indicates an infinite negative offset, so with this setting a 3G Mobile will always change to the 3G network if any acceptable 3G cell is available (see parameter GFDDQMI).

This parameter corresponds to the GSM parameter FDD_GPRS_Qoffset.

GAM=3,

object: PTPPKF

unit: 2dB

range: 0..31

0 = 0dB, 31 = 62dB

default: 3 = 6dB

Gamma, this parameter defines the “gamma” value applied in the power control algorithm. It is an MS and channel specific power control parameter and is sent to the MS within an RLC control message (e.g. PDAS, PUAS, PUAN, PPCTA, PTR, …).

The default value of 6dB means basically that the MS always transmits 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 as closed loop power control.

GASTRTH=10-20,

object: PTPPKF

format: ThresholdIdleChanHV -

ThresholdIdleChanVH -

ThresholdIdleChanEU

range: ThresholdIdleChanHV:

0..100

ThresholdIdleChanVH:

0..100

ThresholdIdleChanEU:

0..100

default: ThresholdIdleChanHV: 10

ThresholdIdleChanVH: 20

ThresholdIdleChanEU: 20

GPRS allocation strategy thresholds, defines the thresholds for the system to switch between horizontal and vertical GPRS channel allocation (and back). It consists of three fields:

ThresholdIdleChanHV defines the point when the allocation strategy is switched from horizontal to vertical: If less than (ThresholdIdleChanHV) percent of CS-only and CS/PS-shared timeslots are idle, vertical allocation is enabled.

ThresholdIdleChanVH defines the point when the allocation strategy is switched back from vertical to horizontal: If more than (ThresholdIdleChanVH) percent of CS-only and CS/PS-shared timeslots are idle, horizontal allocation is enabled again.

ThresholdIdleChanEU defines the threshold above which the upgrading of radio resources is enabled (see parameters UPGRFREQ, GASTRABISTH). Remarks: - ThresholdIdleChanHV has to be lower than ThresholdIdleChanVH. - ThresholdIdleChanVH has to be lower than or equal to ThresholdIdleChanEU. - PDCHs are reserved in a flexible way with the parameter GMANPRES only on thoseTRXs with GSUP=TRUE. They are not considered at all within the above load calculations. - Idle shared timeslots are all available timeslots in the cell that can handle both GPRS and CS services (GSUP=TRUE and not reserved). - Idle CS-only timeslots are all available timeslots in the cell on TRXs with GSUP=FALSE. - The decisive total number of idle channels changes due to GPRS and CS load. Therefore vertical allocation may be activated by both CS calls or PDCH allocations only.



GCELLRESH=2,

object: PTPPKF

unit: 2dB

range: 0..7

0=0dB, 7=14dB

default: 2


GPRS cell reselect hysteresis, this attribute indicates the hysteresis to be subtracted from the C32 value of the neighbour cells if the MS is in ready state and the neighbour cell belongs to the same routing area. If C31H=TRUE, GCELLRESH is additionally substracted from the C31 values of the neighbour cells.

The value ranges from 0 dB to 14 dB (2 dB step size).

This parameter corresponds to the GSM parameter GPRS_CELL_RESELECT_HYSTERESIS.

GFDDMURREP=<NULL>,

object: PTPPKF

range: 0..3, <NULL>

default: <NULL>

GPRS FDD multiRAT reporting, this parameter indicates the number of FDD UTRAN cells to be included in the MEASUREMENT REPORTs sent by GPRS attached mobiles.

This parameter corresponds to the GSM parameter FDD_MULTIRAT_REPORTING.

Note: This parameter is not relevant in BR7.0

GFDDQMI =<NULL>,

object: PTPPKF

range: MDB20 MDB19

MDB18 MDB17

MDB16 MDB15

MDB14 MDB13

<NULL>

default: <NULL>

GPRS FDD_Q_Min, this parameter defines the minimum Ec/No (signal to noise ratio) the adjacent cell must provide to be considered as suitable neighbour.

This parameter corresponds to the GSM parameter FDD_Qmin..

GFDDREPQTY =<NULL>,

object: PTPPKF

range: RSCP, ECNO, <NULL>

default: <NULL>

GPRS FDD reporting quantity, this parameter indicates the reporting quantity to be used for UMTS FDD cells.

Note: This parameter is not relevant in BR7.0.

This parameter corresponds to the GSM parameter FDD_REP_QUANT.

GHCSPC=3,

object: PTPPKF

range: 0..7

default: 3


GPRS hierarchical cell structure priority class, this attribute represents the Hierarchical Cell Structure priority for the cell reselection procedure.

This parameter corresponds to the GSM parameter PRIORITY_CLASS.

GHCSTH=10,

object: PTPPKF

unit: 2dB

range: 0..31

0=-110dB, 31=-48dB

default: 10


GPRS hierarchical cell structure threshold, this attribute indicates the 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 maximum number of allocated MSs , this parameter indicates the maximum number of MSs that can be multiplexed on a PDCH in the cell. It is composed of two fields: the first indicates the maximum number of MS that can be multiplexed on a PDCH in uplink direction, the second one indicates the maximum number of MS that can be multiplexed on a PDCH in downlink direction.

The total amount of TBFs multiplexed on a PDCH is limited



GMANPRES =4,

object: PTPPKF

unit: 1

range: 0..190

BR7.0: Parameter renamed from

GMAPERTCHRES to GMANPRES,

the parameter range changed!

GPRS maximum number of PDCH reserved, this parameter defines the number of timeslots exclusively reserved for GPRS services. These timeslots are dynamically reserved only on those TRXs which are created with GSUP=TRUE (see command CREATE TRX).

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 retransmissions, this parameter indicates for each priority level 1 to 4 the maximum number of retransmission allowed on the PRACH. The parameter value consists of 4 fields, each field indicates the maximum number of retransmissions allowed for the affected priority level. Priority 1 represents the highest priority. For each Radio Priority x parameter the following table is applied:

0 0 1 retransmission allowed 0 1 2 retransmissions allowed 1 0 4 retransmissions allowed 1 1 7 retransmissions allowed

This parameter corresponds to the GSM parameter MAX_RETRANS.

GMSTXPMAC=2,

object: PTPPKF

range: 0..31

default: 2


Maximum allowed GPRS MS transmission power on PBCCH/ PCCCH. GMSTXPMAC defines the maximum power level that may be used by the mobile to access the cell on the PRACH. The valid values and meanings are the same as defined for the parameter MSTXPMAXCH (see SET BTS [CCCH]).

Note: In case Network Controlled Cell Reselection (NCCR) is activated in the cell (NCRESELFLAG=ENABLED), the PCU uses GRXLAMI as well as GMSTXPMAC to calculate the C1 values also in case no PBCCH is created in the cell.

This parameter corresponds to the GSM parameter GPRS_MS_TXPWR_MAX_CCH.

GNMULBAC=<NULL>,

object: PTPPKF

range: 0..3

default: <NULL>


GPRS Number of multi band cells, this parameter is relevant for GPRS network-controlled cell reselection in dualband configurations. It is the GPRS equivalent to the parameter NMULBAC (see command CREATE BTS [BASICS]) and used by GPRS attached mobiles in case a PBCCH is created in the cell. It specifies in which way the MS shall monitor and report the neighbour cells of the frequency bands used in the serving and neighbouring cells. Possible values are: 0 - Normal reporting of the six strongest cells, with known and allowed NCC part of BSIC, irrespective of the band used. 1 - The MS shall report the strongest cell, with known and allowed NCC part of BSIC, in each of the frequency bands in the BA list, excluding the frequency band of the serving cell. The remaining positions in the measurement report shall be used for reporting of cells in the band of the serving cell. If there are still remaining positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used. 2 - The MS shall report the two strongest cells, with known and allowed NCC part of BSIC, in each of the frequency bands in the BA list, excluding the frequency band of the serving cell. The remaining positions in the measurement report shall be used for reporting of cells in the band of the serving cell. If there are still remaining positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used. 3 - The MS shall report the three strongest cells, with known and allowed NCC part of BSIC, in each of the frequency bands in the BA list, excluding the frequency band of the serving cell. The remaining positions in the measurement report shall be used for reporting of cells in the band of the serving cell. If there are still remaining



positions, these shall be used to report the next strongest identified cells in the other bands irrespective of the band used.

GPATH=PKAAP4,

object: PTPPKF

range: PKANA

PKAAP1 - PKAAP4

default: PKAAP4


GPRS priority access threshold, this parameter indicates whether or not a mobile station of a certain priority class is authorised to do a random access in order to request for GPRS services. The field is coded according to the following table:

PKANA 0 0 0 packet access is not allowed in the cell PKAAP1 0 1 1 packet access is allowed for Priority class 1 PKAAP2 1 0 0 packet access is allowed for Priority class 1 to 2 PKAAP3 1 0 1 packet access is allowed for Priority class 1 to 3 PKAAP4 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 the network indicates e.g. only Prio 1 accesses are allowed, all mobiles having Prio 4 assigned do not perform a network access. GMM/SM procedures are not affected.

This parameter corresponds to the GSM parameter PRIORITY_ACCESS_THR.

GPDPDTCHA=100,

object: PTPPKF

unit: 1% range: 0..100

default: 30


GPRS Percentage of dynamic PDTCH Available, this parameter indicates the percentage of available “shared” traffic channels that may be used for GPRS traffic. “Shared traffic channels” are those channels (TCHFULL, TCHF_HLF, TCHSD in TCHPOOL) for which the parameter GDCH is set to <NULL> (see CREATE CHAN for TCH) and for which the superordinate TRX is in service and available for GPRS service (GSUP=TRUE, see CREATE TRX).

All TCHs created with these attributes represent 100%.

GPDPDTCHA determines the percentage of these TCHs that the BSC may use for GPRS traffic (the calculated value is rounded down). Whether these TCHs may be preempted respectively downgraded for circuit-switched calls, depends on the setting of the parameter DGRSTRGY (see SET BSC [BASICS]).

Note: Modification of the GPDPDTCHA setting is only possible, if the PTPPKF 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 the network on the PRACH. In case a PBCCH is configured in the cell, GPRS mobiles use this parameter instead of the GSM equivalent RXLEVAMI (object BTS).

It is used together with other parameters to calculate the path loss criteria C1 and C32 for cell selection and reselection. Setting GRXLAMI to a high value means that only those GPRS mobiles attempt to access the cell which are in a location with good coverage conditions. This parameter is sent for the serving as well as the indicated neighbour cells on the PBCCH (PSI3).

A GPRS MS measures the received signal level on the PBCCH carriers of the serving cell and the surrounding cells and calculates the 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 the BA(GPRS) list, which is broadcast in the PACKET SYSTEM INFORMATION TYPE 3 on the PBCCH and which is defined by the ADJC cell objects with GSUP=TRUE (see command CREATE ADJC).

At least 5 received signal level measurement samples are required for a valid RLA_P:

RLA_P = 1/5 ∗ (GPRS_RXLEV1 + GPRS_RXLEV2 + ...+ GPRS_RXLEV5)

The path loss criterion C1, the minimum signal level criterion for GPRS/EGPRS cell selection and cell re-selection, is calculated by the following formula:

C1 = (A - Max(B,0))

where A = <receive level average> - GPRS_RXLEV_ACCESS_MIN = RLA_P – GRXLAMI

B = GPRS_MS_TXPWR_MAX_CCH - P = GMSTXPMAC – P P = Maximum RF output power of the MS (see table under parameter MSTXPMAXDCS in command SET BTS [BASICS]).

Max (B,0)= GMSTXPMAC - P if GMSTXPMAC > P Max (B,0)= 0 if GMSTXPMAC < P

Subtracting Max(B,0) ensures that the transmit power capability is considered in addition to the minimum receive level defined by GRXLAMI: The lower the maximum transmit power of the MS is , the higher must be the minimum RXLEV for access.

Notes: - In case Network Controlled Cell Reselection (NCCR) is activated in the cell (NCRESELFLAG=ENABLED), the PCU uses GRXLAMI as well as GMSTXPMAC to calculate the C1 values also in case no PBCCH is created in the cell. - If no PBCCH is configured in the cell, the C1 criterion is calculated in the same way as it is done for standard GSM (non-GPRS MS)on the basis of the parameters RXLEVAMI and MSTXPMAXCH as described in parameter CELLRESH (see command CREATE BTS [BASICS]). - This parameter corresponds to the GSM parameter GPRS_RXLEV_ACCESS_MIN.



GS=8,

object: PTPPKF

range: 0..9

default: 8


GPRS number of slots between two PRACH accesses, this parameter is used for calculation of the number of slots between two successive Channel request messages on PRACH channel. The field is coded according to the following table:

0 0 0 0 S = 12 0 0 0 1 S = 15 0 0 1 0 S = 20 0 0 1 1 S = 30 0 1 0 0 S = 41 0 1 0 1 S = 55 0 1 1 0 S = 76 0 1 1 1 S = 109 1 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 multiband reporting, this parameter indicates the number of TDD UTRAN cells to be included in the MEASUREMENT REPORTs sent by GPRS attached mobiles.

This parameter corresponds to the GSM parameter TDD_MULTIRAT_REPORTING.

Note: This parameter is not relevant in BR7.0

GTEMPOFF Cancelled - in BR7.0 this parameter is only available in ADJC object

GTXINT=3,

object: PTPPKF

range: 0..15

default: 3


GPRS transmission interval, this parameter defines the number of slots to spread transmission of the random access on PRACH channel. The field is coded according to the following table:

0 0 0 0 3 slots 1 0 0 0 11 slots 0 0 0 1 4 slots 1 0 0 1 12 slots 0 0 1 0 5 slots 1 0 1 0 14 slots 0 0 1 1 6 slots 1 0 1 1 16 slots 0 1 0 0 7 slots 1 1 0 0 20 slots 0 1 0 1 8 slots 1 1 0 1 25 slots 0 1 1 0 9 slots 1 1 1 0 32 slots 0 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 priority, this parameter indicates if a ‘GPRS attached’ mobile can search 3G cells when BSIC decoding is required. If GUMTSSRHPRI=TRUE, the MS may use up to 25 search frames per 13 seconds without considering the need for BSIC decoding or packet transfer mode interference measurements in these frames.

The MS continuously measures the received RF signal level on: - the BCCH carrier of the serving cell; - the BCCH carriers of neighbour cells as indicated in the BA(GPRS) list.

For each of the monitored cells it calculates the average received level (RLA_P). In addition the MS verifies the BSIC of the BCCH carriers. Only cells with allowed BSIC are considered for re-selection purposes.

If a GPRS MS works in packet transfer mode it monitors continuously all BCCH carriers as indicated by the BA(GPRS) list and the PBCCH carrier of the serving cell. In every TDMA frame, a received signal level measurement sample is taken on at least one of the BCCH carriers, one after the another. RLA_P is an average value determined using samples collected over a period of 5s, and is maintained for each BCCH carrier. The samples allocated to each carrier shall as far as possible be uniformly distributed over the evaluation period. At least 5 received signal level measurement samples are required for a valid RLA_P value. The MS shall attempt to check the BSIC for each of the 6 strongest non-serving cell BCCH carriers as often as possible, and at least every 10 seconds.

A multi-RAT MS is allowed to extend this period to 13 seconds, if the neighbor cell list contains cells from other radio access technologies (RATs), e.g. 3g neighbour cells.



This parameter corresponds to the GSM parameter 3G_SEARCH_PRIO.

IMCSULNIR8PSK =MCS3,

object: PTPPKF

range: MCS1, MCS2, MCS3,

MCS4, MCS5, MCS6,

MCS7, MCS8, MCS9

<NULL>

default: MCS6

recommended value: MCS3

Initial MCS uplink Wout incremental redundancy 8PSK, this parameter specifies the MCS to be used in an EDGE UL TBF if the MS supports 8PSK and no other information about that MS in that BVC is available (see parameter STGTTLLIINF). If the BSC is informed about the EDGE capability (e.g. 2-phase access or EDGE PACKET CHANNEL REQUEST was used) of this mobile, it uses the value of IMCSULNIR8PSK in order to calculate the best possible resource allocation for the requested UL TBF.

IMCSULNIRGMSK =MCS3,

object: PTPPKF

range: MCS1, MCS2,

MCS3, MCS4,

<NULL>

default: MCS3

Initial MCS uplink Wout incremental redundancy GMSK, this parameter specifies the MCS to be used in an EDGE UL TBF if the MS supports GMSK only and no other information about that MS in that BVC is available (see parameter STGTTLLIINF). If the BSC is informed about the EDGE capability (e.g. 2-phase access or EDGE PACKET CHANNEL REQUEST was used) of this mobile, it uses the value of IMCSULNIR8PSK in order to calculate the best possible resource allocation for the requested UL TBF.

INIBLER=PER10,

object: PTPPKF


PER80, PER90

default: PER50

Reference:

recommended value: PER10

Initial BLER, this parameter defines the initial BLER estimation in a cell to be used. This value is used in radio resource management to calculate the initial number of radio resources to be assigned to packet services in case no ‘historical’ information about BLER is available (see parameter STGTTLLIINF).

INICSCH=CS2,

object: PTPPKF

range: CS1, CS2, CS3, CS4

default: CS2


Initial coding scheme, this parameter indicates the coding scheme to be allocated when the packet transfer starts. It is also used as input parameter to calculate the amount of radio resources necessary to fulfil the QOS requirements (Peak Throughput Class).

The values CS3 and CS4 are available only in case CSCH3CSCH4SUP=TRUE in the cell.

This parameter corresponds to the GSM parameter INITIAL_CODING_SCHEME.

INIMCSDL =MCS6,

object: PTPPKF

range: MCS1, MCS2, MCS3,

MCS4, MCS5, MCS6,

MCS7, MCS8, MCS9

<NULL>

default: MCS9

recommended value: MCS6

Initial MCS downlink, this parameter specifies the MCS to be used in an EDGE DL TBF if the MS supports 8PSK and no other information about that MS in that BVC is available (see parameter STGTTLLIINF). The value of INIMCSDL is also used as input parameter to calculate the amount of radio resources necessary to fulfil 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 than MSBHIPER * MS Bucket Size PCU, the ‘Bucket Congestion’ state is activated. As consequence the Flow Control Algorithm will reduce the reported leak rate ‘R’ inside the FLOW-CONTROL-MS PDU, thus limiting the amount of data being sent from the SGSN towards the BSC. If the congestion state persists, the leak rate is further decreased.


MSBLPER=PER60,

object: PTPPKF


PER40, PER50, PER60,

PER70, PER80,

default: PER60

Reference:

MS bucket low percentage. If the MS Bucket Level is lower than MSBLPER * MS Bucket Size PCU, the ‘Bucket Congestion’ state is ceased. As soon as the congestion state is cleared, the leak rate ‘R’ inside the FLOW-CONTROL-MS PDU is set to its original value and the SGSN may increase the data rate sent towards the BSC.




MSBMAPER=PER100,

object: PTPPKF




PER100, PER110, PER120,



PER190 PER200

default: PER100

Reference: GSM08.18

MS bucket max percentage. defines the value of the ‘MS Bucket Size’ (Bmax) reported in the FLOW-CONTROL-MS PDU towards the SGSN:

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 TS multiplied by the usage percentage (100% if no other MS is sharing that TS).


MSBSPPER=PER200,

object: PTPPKF




PER190 PER200

default: PER200

Reference: GSM08.18

MS bucket size PCU percentage. This parameter specifies the ‘MS Bucket Size PCU’ value based on the ‘MS Bucket Size’ value Bmax reported to the SGSN.

MS Bucket Size PCU = MSBSPPER * MS Bucket Size

It represents the buffer space ‘reserved’ in the PCU for this MS. The MS congestion thresholds (MSBHIPER, MSBLPER) are based on this value.


NAVGI=10,

object: PTPPKF

range: 0..15

default: 10


N averaging interference, this attribute represents an interfering signal strength filter constant for power control 2(k/2), k = 0, 1, … , 15.

This parameter corresponds to the GSM parameter N_AVG_I.

NCC1TH=DB03,

object: PTPPKF

range: DB00, DB01..DB62,DB63

default: DB03

Reference:

Network controlled cell reselection C1 threshold. This parameter establishes the threshold concerning the C1 value for network controlled cell reselection (NCCR) in steps of 1dB (DB01 = 1dB, DB02 = 2dB etc.): If the C1 value measured on the serving cell falls below NCC1TH, a network controlled cell reselection is attempted.

NCRARESH=DB00,

object: PTPPKF

range: DB00, DB01..DB29,DB30

default: DB00

Reference:

Network controlled cell reselection routing area reselect hysteresis, this parameter specifies the additional hysteresis (in steps of 1dB, DB01 = 1dB, DB02 = 2dB etc.) to be subtracted from C32 of an adjacent cell belonging to a different routing area than the serving 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 controlled cell reselection same routing area, this parameter determines whether cells of the same routing area are to be preferred during the network controlled cell reselection procedure. When NCSARA is set to TRUE, the BSC classifies the available adjacent cells in two subgroups:

a) adjacent cells that belong to the same routing area as the serving cell and b) adjacent cells that do not belong to the same routing area as the serving cell.

If network controlled cell reselection is to be performed and NCSARA is set to TRUE, the BSC first of all searches an adjacent cell that belongs to the same routing area like the serving cell. If the BSC finds a suitable adjacent cell in this subgroup, this cell will be selected for cell reselection. If NCSARA is set to FALSE, the adjacent cells of the same routing area have no priority compared to the adjacent cells of other routing areas and the BSC will select the best suitable cell for cell reselection, irrespective of its association to a routing area.

Note: When this attribute is set to TRUE , the parameter NCRARESH (see above) has to be set to DB00 (default value).

NCTRFPSCTH=75,

object: PTPPKF

range: 30..100

default: 75

Reference:

Network controlled cell reselection traffic packet switched control threshold, this parameter specifies the traffic load threshold in percent below which no more mobiles are moved out of a cell due to traffic reasons. Please refer to the parameter CRESELTRHSOUT for further details.

NTWCNDRXP=MSEC0480,

object: PTPPKF

range: NODRX, MSEC240,

MSEC480, MSEC720,

MSEC960, MSEC1200,

MSEC1440, MSEC1920

default: MSEC0480

Reference:

Network controlled cell reselection report period transfer, this parameter indicates the minimum time (in milliseconds, MSC0480 =480ms) the mobile station shall remain in non-DRX mode after a PACKET MEASUREMENT REPORT message had been sent.

NTWCOR=NC0,

object: PTPPKF

range: NC0, NC1

default: NC0


Network control order, this parameter reported in (P)SI 13, PSI 1 and 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 PACKET MEASUREMENT ORDER at the beginning of each TBF indicating NC2 for the respective mobile. Before the TBF is terminated, the Network Control Order is reset to NC0. NC1 is not used at all in within BR70. This parameter corresponds to the GSM parameter NETWORK_CONTROL_ORDER.



NTWCREPPIDL= MSEC61440,

object: PTPPKF

range: MSEC480 , MSEC960,

MSEC1920, ,MSEC3840,

MSEC7680,MSEC15360,

MSEC30720, MSEC61440

default: MSEC61440

Reference:

Network controlled cell reselection report period idle, this parameter indicates the time period between two consecutive PACKET MEASUREMENT REPORT (PMO) messages while the MS is in packet idle mode.

Note: This parameter is not used in BR70 as the BSC does not set NC1/NC2 for mobiles in packet idle mode. This parameter corresponds to the GSM parameter NC_REPORTING_PERIOD_I.

NTWCREPPTR= MSEC3840,

object: PTPPKF

range: MSEC480, MSEC960,

MSEC1920, ,MSEC3840,

MSEC7680,MSEC15360,

MSEC30720, MSEC61440

default: MSEC3840

Reference:

Network controlled cell reselection report period transfer, this parameter indicates the time period between two consecutive PACKET MEASUREMENT REPORT (PMO) messages while the MS is in packet transfer mode.

This parameter corresponds to the GSM parameter NC_REPORTING_PERIOD_T.

PCMECH=MEABCCH,

object: PTPPKF

range: MEABCCH, MEAPDTCH

default: MEABCCH


Power control measurement channel, this attribute indicates where the mobile station shall measure the received power level on the downlink for the purpose of the uplink power control.

Setting PCMECH to MEABCCH means: downlink measurements for power control shall be performed on the BCCH.

Setting PCMECH to MEAPDTCH means: downlink measurements for power control shall be performed on the PDCH.

This parameter corresponds to the GSM parameter PC_MEAS_CHAN.

PERSTLVPRI1=5,

object: PTPPKF

range: 0..14, 16

default: 5


Persistence level priority 1, this parameter is broadcast in the Packet System Information Type 1 on the PBCCH. It specifies the access persistence on PRACH for TBFs with radio priority 1. For each access attempt the MS shall draw a random value R with uniform distribution in the range (0, …, 15). The MS is allowed to transmit an (EGPRS) PACKET CHANNEL REQUEST message only in case the value of PERSTLVPRI1 is less or equal to R.

Therefore a high value of PERSTLVPRI1 decreases the probability of a network access for a TBF with radio priority 1.

PERSTLVPRI2=5,

object: PTPPKF

range: 0.. 14, 16

default: 5


Persistence level priority 2, this parameter is broadcast in the Packet System Information Type 1 on the PBCCH. It specifies the access 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 the number of consecutive serving cell’s BCCH carrier measurements under 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 having received a PACKET UPLINK ACK/NACK message from the network. Refer also to parameters PKTNINC and PKTNMA.

This parameter corresponds to the GSM parameter PAN_DEC.

PKTNINC=2,

object: PTPPKF

range: 0..7

default: 2


Packet number increment, this parameter defines the stepsize to increase counter N3102 in case a PACKET UPLINK ACK/NACK message was correctly received by the MS. N3102 cannot exceed the value set by PKTNMA. Refer also to parameters PKTNDEC and PKTNMA.

This parameter corresponds to the GSM parameter PAN_INC.

PKTNMA=4,

object: PTPPKF

range: 0..7

default: 4


Maximum packet number, this parameter defines the maximum value for the counter N3102 used on MS side. N3102 is set to PKTNMA at each cell reselection of the MS. In case N3102 reaches the value 0 or below (see PKNDEC and PKNINC), the mobile station shall perform an abnormal release with cell reselection.

This parameter corresponds to the GSM parameter PAN_MAX.

PRPBCCH=0,

object: PTPPKF

range: 0..15

default: 0


GSM 04.60

Power reduction on PBCCH, this attribute indicates the power reduction value used by the BTS on PBCCH blocks, relative to the output power used on the BCCH. It is broadcast within the PACKET SYSTEM INFO TYPE 1 on the PBCCH and the stepsize is 2 dBm.

This parameter corresponds to the GSM parameter Pb.

QSRHPRI=NEVER,

object: PTPPKF


UMDB90 UMDB86

UMDB82 UMDB78

UMDB74 ALWAYS

OMDB78 OMDB74

OMDB70 OMDB66

OMDB62 OMDB58

OMDB54 NEVER

default: NEVER

Q Search priority, this parameter is broadcast on the PBCCH and defines a threshold condition under which the Mobile shall monitor and report 3G neighbour cells.

The parameter values have to be considered as follows: - The values OMDBxx (=over minus xxdB) define the threshold as follows: When the level of the neighbour cell has exceeded the “xx dB” threshold value, the neighbour cell shall be considered for reporting. - The values UMDBxx (=under minus xxdB) define the threshold as follows: When the level of the neighbour cell has dropped below the “xx dB” threshold value, the neighbour cell shall be considered for reporting.

- The value ALWAYS means the Mobile shall always consider 3G neighbours for reporting. - The value NEVER means the Mobile shall not consider 3G neighbours for reporting at all.

RAARET=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: TRUE


Random access retry, this parameter determines whether random access retry is allowed or not. If RAARET=FALSE random access retry to another cell is not allowed. If RAARET=TRUE random access retry to other cell is allowed. Its value is broadcast on the PBCCH within the PSI3 message.

This parameter corresponds to the GSM parameter RANDOM_ACCESS_RETRY.



RACODE=10,

object: PTPPKF

range: 0..255

Routing area code, this attribute represents the identification of the RA to which this cell belongs.

A routing area may comprise at minimum a single cell and as maximum a complete LAC area.

RACOL=7,

object: PTPPKF

range: 0..7

Routing area colour, this attribute is used by the mobile to identify the specific routing area. Due to the fact that the RACODE can be smaller 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 when the mobile is listening to different LA containing routing area with the same code. The RA colour for the neighbour LA must be set different by network planning.

RAENV=HIGHDIV,

object: PTPPKF

range: HIGHDIV, LOWDIV

default: HIGHDIV

Radio environment, this parameter specifies the radio environment in the cell. It is an indicator of user mobility. Two values are possible:

- LOWDIV (lowDiversity): this value means that for an MS radio conditions can change slowly, because the cell is characterized by low user mobility (pico cells, indoor cells, or MSs have a speed lower than 50 km/h). - HIGHDIV (highDiversity): this value means that for a MS radio conditions can change fast, because MSs have a speed higher than 50 km/h. This parameter determines which decision threshold table is applied for the Link Adaptation (LA) feature if EDGE is used. In case of HIGHDIV, coding scheme downgrades are started already at lower BLER values compared to the LOWDIV case (means earlier). Coding scheme upgrades are also performed at lower BLER values compared to the LOWDIV case. This applies some safety margin in case 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 the additional hysteresis (in steps of 2dB) to be subtracted from C32 of an adjacent cell belonging to a different routing area than the serving cell. The value is applied in both GMM standby and ready state of the mobile.

This parameter corresponds to the GSM parameter RA_RESELECT_HYSTERESIS.

SCHWEIPRI1=8,

object: PTPPKF

range: 0..16

default: 8

Reference:

Scheduling weight of priority 1, this parameter indicates the scheduling weight associated to scheduling priorities 1. If more than one MS is allocated on a PDCH (vertical allocation), the relative importance of each MS (TBF) compared to another one can be influenced. For this purpose the system internally maps two of the available QOS parameters on the internal scheduling priority:

DL Precedence UL Radio Priority Internal Priority Weight (default)

1 1 1 8

2 2 2 4

3 3 3 2

4 4 1

The UL radio priority is present in the PACKET RESOURCE REQUEST (PRR) message in case of a two-phase access. In case of 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-UNITDATA PDU.

Example: 2 MS sharing 4 timeslots; MS1 with Prio 1, MS2 with Prio 4 If the mobiles use each 4 timeslots and the same coding scheme, the throughput of a DL Transfer will be split according to: MS1: 8/9 * ThroughputMAX MS2: 1/9 * ThroughputMAX



SCHWEIPRI2=4,

object: PTPPKF

range: 0..16

default: 4

Reference:

Scheduling weight of priority 2, this parameter indicates the scheduling weight associated to scheduling priorities 2. Please refer to SCHWEIPRI1 for further details.

SCHWEIPRI3=2,

object: PTPPKF

range: 0..16

default: 2

Reference:


SCHWEIPRI4=1,

object: PTPPKF

range: 0..16

default: 1

Reference:


STGTTLLIINF=10,

object: PTPPKF

unit: 1s

range: 10..90

default: 10

Storage time of TLLI info, this parameter indicates the time (in seconds) for which the BSC stores the information about the last used coding scheme and BLER of a certain TLLI (=mobile) after it terminated its last TBF (UL or DL). If a new TBF is setup towards this TLLI within STGTTLLIINF time, the system uses the previously applied BLER and coding scheme info during 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 MS stops waiting for a PACKET UPLINK ASSIGNMENT message after it had asked for new uplink resources (via PRR, (E)PDAN or PCA). Its value plus one must be multiplied by 500 msec. to obtain the real value broadcast in (P)SI 1/13.

T3192=0,

object: PTPPKF

range: 0..7

default: 0


T3192, this timer is used on the MS side when the mobile station has received all of the RLC/MAC data blocks of a TBF. When T3192 expires, the mobile shall release the resources associated with the TBF (TFI, etc.) and begin to monitor its paging channel. The timer is broadcast withing (P)SI 1/13 and coded as follows:

0 500 ms 1 1000 ms 2 1500 ms 3 0 ms 4 80 ms 5 120 ms 6 160 ms 7 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 offset. this parameter is related to multiRAT MSs considering a reselection towards a TDD cell; it indicates an offset which is applied to the RLA_P value of the serving cell.




The value ALWAYS indicates an infinite negative offset, so with this setting a 3G Mobile will always change to the 3G network if any acceptable 3G cell is available). This parameter corresponds to the GSM parameter TDD_GPRS_Qoffset.

TRESEL=0,

object: PTPPKF

range: 0..7

default: 0


Timer for cell reselection. This parameter is broadcast within the PSI3 message on the PBCCH. If the MS has performed an abnormal release with cell reselection towards a new cell (see parameter RAARET), the MS shall not reselect back to the original cell for T_RESEL seconds if another suitable cell is available. The field is coded according to the following table:

000 5 seconds 100 30 seconds 001 10 seconds 101 60 seconds 010 15 seconds 110 120 seconds 011 20 seconds 111 300 seconds

This parameter corresponds to the GSM parameter T_RESEL.

TRFPSCTRLT=5,

object: PTPPKF

unit: 1s

range: 1..100

default: 5

Reference:

Traffic packet switched control timer, this parameter defines the minimum time between two consecutive NCCR procedures of an MS towards the same adjacent cell.

The timer is started in the BSC after reception of a PACKET CELL CHANGE FAILURE message in the source cell. It avoids repeated NCCR attempts towards a target cell which is not able to provide service.

Creating the LPDLR links:

CREATE LPDLR This command was deleted in BR6.0! From BR6.0 on the LPDLR is automatically created by the command CREATE TRX, the physical assignment of the created LPDLR is determined by the parameter LPDLMN (in command 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 TCHs subordinate to the TRX are exclusively used for circuit-switched traffic. If GSUP=TRUE, the TCHs may be used for GPRS traffic as well. How exactly the subordinate channels can be used depends on the 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 the radio signaling (i.e. signalling for call processing) of this particular TRX. In other words, any cell access, signaling transaction or call which invloves any radio channel (CHAN object) subordinate to this TRX, is signaled via this LPDLR, no matter whether it is - a BCCH procedure (e.g. random access via the RACH (CHANNEL REQUIRED sent by the BTS), paging via the PCH (PAGING COMMANDs sent the BSC) or an Immediate Assignment procedure via the AGCH (IMMEDIATE ASSIGNMENT sent by the BSC)) - an SDCCH transaction (e.g. Location Update, SMS in idle mode, IMSI detach etc.) or - a transaction signaled via an SACCH or FACCH (TCH assignment, handover, SMS in busy mode etc.)

Physically the LPDLR signalling messages are sent within the same Abis timeslot(s) which is (are) assigned to an existing LPDLM object(s) for the responsible BTSM. The distinction between the LPDLM messages (O&M messages between BSC and BTSM) and the LPDLR messages (TRX-specific radio signaling communication between 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 LAPD messages: While LPDLM messages are always signaled with SAPI=62 and the TEI of the BTSM (as defined in the parameter TEI in command CREATE BTSM), the radio signalling messages related to a particular TRX are always signaled with SAPI=0 and the TEI no. which is automatically assigned to the TRX during the BTSE alignment (the TEI assignment of a TRX can be interrogated by the command GET TRX).

The parameter LPDLMN identifies the LPDLM link (and thus the physical Abis timeslot) via which the LPDLR signalling of the TRX shall be performed. If only one LPDLM is created for a particular BTSM, of course, only this LPDLM number can be selected for LPDLMN. If, however, more than one LPDLM is created for a particular BTSM, LPDLMN determines the LPDLM, via which the LPDLR signalling of a particular TRX shall be performed by default. Thus the LPDLMN definition defines the standard load sharing distribution for radio signalling communication among the available physical Abis timeslots that were configured as LPDLMs. If an LPDLM fails (e.g. due to failure of the superordinate PCMB link), the radio signalling messages of the affected TRX are automatically transmitted via one of the remaing LPDLMs in order to guarantee the availability of all TRXs of the BTSM, even if one of the PCMB connections has failed. The only restriction to be considered in this case is the fact that the possible traffic volume will be limited due to the 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 configuration, this parameter determines whether a TRX belongs to the 'Emergency Configuration' or not (see also parameters EMT1 and EMT2 in the command CREATE BTSM). 'Emergency configuration' is entered in case of a failure of the external BTSE power supply (alarm 'ACDC MAINS BREAKDOWN') or if the shelter temperature exceeds the allowed threshold (alarm 'SHELTER TEMPERATURE OUT OF TOLERANCE'). Its purpose is to keep only the most important BTSE units and TRXs alive and thus to save power as long as the BTSE is powered by the backup battery. Setting MOEC to TRUE for a TRX means that the HW associated to this TRX will be powered if emergency configuration is entered.

PWRRED=6,

object: TRX

unit: 2dB

range: 0..6 (0dB-12dB)

default: 6


Power reduction, specifies the number of 2-dB-steps the Tx power should be reduced from the maximum transmit power. Since the sending power determines the actual cell size the PWRRED parameter is used to adjust the sending power according to the desired transmission range. Note for concentric cells: Since in concentric cells (see parameter CONCELL in command CREATE BTS [BASICS]) this parameter determines the different ranges of inner and complete area TRXs it must be set in accordance with the setting of the parameter TRXAREA (see below)! If a cell is configured for support of the feature “Common BCCH for GSM 900/1800 or GSM850/1900 Dual Band Operation”, the use of the PWRRED is usually not necessary as the output power of the TRX HW (CU/PA) for different frequency bands and the propagation attenuation of the different used frequency bands differs in such a way that the coverage areas are established naturally.

Rules: For configuration rules concerning concentric cells and dualband concentric cells please refer to the description of parameter HORXLVDLO (see command SET HAND [BASICS]).



RADIOMG=254,

object: TRX


range: 1-254

default: 254

Radio measurement granularity for measurements on Abis, specifies the granularity periods for retrieval of the measurement reports which are to be sent on the Abis interface in case they are enabled. If the Abis has to be traced for radio diagnostic of handover performance diagnostic reasons it is recommended to set the radio measurement granularity to ‚1’ because only in this case all measurement reports from the MS and the BTS will be transmitted on the Abis. However, it has to be considered that the enabling of the Radio Measurements on the Abis interface cause an additional load on the LPDLR links: the lower the value for RADIOMG, the higher the signalling load on the LPDLRs.

RADIOMR=OFF,

object: TRX

range: ON, OFF

default: OFF

Radio measurement reports, specifies whether radio measurement report transmission via the Abis interface is enabled. Since in the SBS the preevaluation of measurement reports for handover decisions is done in the BTS, normally no measurement reports are sent from BTS to BSC. In some cases, however, it is useful to monitor the measurement reports on the Abis interface for test purposes. Only in this case the feature should be activated since it results in additional load on the LPDLR links. The frequency of the measurement reports to be sent via the Abis can be controlled by the following parameter RADIOMG (see below).

Note: The MEASUREMENT RESULT messages on the Abis also contain a timing advance (TA) value. The timing advance value is determined 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 to instruct the MS to transmit its next bursts with a specific ‘timing advance’ in order to ensure that the BTS receives the burst within the guard period. This instruction from BTS to MS is called ‘timing advance order’ and is acknowledged by the MS in the ‘TA confirm’, i.e. with the ‘TA confirm’ the MS confirms that it has transmitted its bursts in correspondence with the previous ‘TA order’. The MEASUREMENT RESULTs contain the ‘confirmed’ TA value of the previous measurement period. This principle also goes for the TRACE MEASUREMENT RESULTs that are sent on the Abis when CTR (see command CREATE CTRSCHED) or IMSI Tracing (see command CREATE TRACE) is enabled. In contrast, the SCA measurements (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 to support EDGE. Thie parameter can only be set to the value EDGE, if the TRX-HW which is associated to the created TRX object an EDGE CU (ECU).

Only if TRXMD is set to EDGE for the BCCH TRX, it is possible to set the parameter EBCCHTRX (command SET PTPPKF, see next command) to TRUE.



TRXAREA=NONE,

object: TRX

range: NONE, INNER,

COMPLETE

default: NONE

TRX area, this parameter specifies whether a TRX belongs to a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) and, if yes, whether it serves the inner or the complete area. Notes: - this parameter must be set in conjunction with a sensible setting of PWRRED (see above)! - the BCCH frequency and all other frequencies with control channels (CCCH, SDCCH) must belong to the complete area (see command CREATE CHAN).

TRXFREQ=CALLF01,

object: TRX

range: BCCHFREQ,

CALLF01.. CALLF63


GSM 05.08

TRX frequency, assigns a radio frequency to a transceiver. From BR6.0 on the radio frequency assigned to the TRX is no longer represented by its absolute radio frequency number (ARFCN) but by its relative number CALLFxx which was assigned to the frequency during creation of the BTS cell allocation (please refer to the parameters CALLF01..CALLF63 and BCCHFREQ in the command CREATE BTS [BASICS]). If the TRX represents the BCCH carrier, the value of TRXFREQ must be BCCHFREQ.

Enabling GPRS and EDGE in a cell:

< The specific parameters related to the enabling of GPRS and EDGE can only be entered if TRX objects were created before with the appropriate attributes. For this reason DBAEM places the command CREATE PTPPKF again after the creation commands for the TRXs with additional parameters. >

SET PTPPKF:

NAME= BTSM:0/BTS:0/PTPPKF:0,

Object path name, range for PTPPKF: 0..0.

EBCCHTRX=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Reference:


(if BCCH TRX is equipped with ECU)

EGPRS 8PSK on BCCH TRX, this parameter indicates if EDGE 8PSK modulation is supported on the BCCH TRX. The setting TRUE is only possible if the BCCH TRX is epuipped with EDGE CU (ECU) at least for the BCCH TRX. Attention: Also the other TRXs of the same BTSE should be equipped with ECU in this case, as in case of automatic BCCH reconfiguration, 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/disable EGPRS (EDGE GPRS) on a per cell basis. As this paramter can only be set to TRUE, if at least one of the TRXs in the cell support EDGE (see parameter TRXMD in command CREATE TRX),

EGPRS=TRUE,

object: PTPPKF

range: TRUE, FALSE

default: FALSE

Reference:


Enable GPRS, this parameter parameter allows to enable/disable GPRS on a per cell basis. As this paramter can only be set to TRUE, if at least one of the TRXs in the cell supports GPRS (see parameter GSUP 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 Full 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 parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRFRC1 in command CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call. If frequency hopping is disabled - no matter whether 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 one defined in the FHSY object is used for a particular call is determined by the BSC, which sends the AMR parameter set to the BTS in the CHANNEL ACTIVATION and to the MS in the ASSIGNMENT COMMAND (resp. HANDOVER COMMAND in case of inter-cell handover).

For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1 in the command 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 Full 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 parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRFRC2 in command CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call.


AMRFRC3= RATE_06,

object: FHSY


RATE_03, RATE_04,

RATE_05, RATE_06,

RATE_07, RATE_08,

<NULL>

default: RATE_06

AMR Full 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 parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRFRC3 in command CREATE BTS [BASICS]) if frequency hopping is currently active 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 parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRFRC4 in command CREATE BTS [BASICS]) if frequency hopping is currently active 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 FR CODEC of the created AMR FR ACS shall be used first after FR TCH assignment in case of frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. The values CODEC_MODE_0x represent 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]) if frequency hopping is currently active for an AMR call.


AMRFRTH12=7-4,

object: FHSY



hysteresis: 0.5dB






AMR Full Rate Thresholds 12, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRFRC1 to AMRFRC2 and vice versa in case of frequency hopping (see also parameter HOPP 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











AMRFRTH34=23-4,

object: FHSY



hysteresis: 0.5dB









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 parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRHRC1 in command CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call.


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 parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRHRC2 in command CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call.


AMRHRC3= RATE_03,

object: FHSY


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 parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRHRC3 in command CREATE BTS [BASICS]) if frequency hopping is currently active 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 parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRHRC4 in command CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call.




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 HR CODEC of the created AMR HR ACS shall be used first after HR TCH assignment in case of frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. The values CODEC_MODE_0x represent the created AMR HR CODECs (AMRHRCx) of the ACS. This parameter eclipses its equivalent parameter in the BTS object (see parameter AMRHRIC in command CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call.


AMRHRTH12=19-4,

object: FHSY



hysteresis: 0.5dB






AMR Half Rate Thresholds 12, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRHRC1 to AMRHRC2 and vice versa in case of frequency hopping (see also parameter HOPP 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’s respective algorithm. The value ‘0’ means cyclic hopping. This parameter is sent in the main DCCH in the IE ‘Channel Description’ contained in the ASSIGNMENT COMMAND and in the HANDOVER COMMAND if it was assigned to the used channel. If frequency hopping is enabled the parameter H is set to 1. In this case the IE also contains the HSN together with the MAIO.



MOBALLOC=CALLF01& CALLF02&...,

object: FHSY

range: 0..1023 (each field)


GSM 04.08

Mobile allocation list, this parameter defines is a list of those cell allocation frequencies used in the hopping sequence. This parameter is sent in the main DCCH in the IE ‘Mobile Allocation’, which is contained in the ASSIGNMENT COMMAND and in the HANDOVER COMMAND. This IE ‘Mobile Allocation’ is a bit map in which e.g. for every frequency contained in the 'cell allocation frequency list' an own bit position is provided. The 'cell allocation frequency list' is derived from the set of frequencies defined by the reference 'Cell Channel Description' IE (see also parameter CALL in CREATE BTS [BASICS]). If the bit position representing a frequency is ‘1’ then the associated frequency is contained in the mobile allocation. In the cell allocation frequency list the absolute RF channel numbers are placed in increasing order of ARFCN, except that ARFCN 0, if included in the set, is put in the last position in the list. Notes: - From BR6.0 on the radio frequencies assigned to the FHSY are no longer represented by their absolute radio frequency number (ARFCN) but by their relative number CALLFxx which was assigned to the frequencies during creation of the BTS cell allocation (please refer to the parameters CALLF01..CALLF63 and BCCHFREQ in the command CREATE BTS [BASICS]). If the TRX represents the BCCH carrier, the value of TRXFREQ must be BCCHFREQ. - If the FHSYID is created for a concentric cell (see CREATE BTS [BASICS]:CONCELL=TRUE) then hopping is only allowed within the complete and within the inner area. This means that two FHSYIDs have to be defined: one for the complete area (MOBALLOC may only consist of TRX frequencies of the complete area) and one for the inner area (MOBALLOC may only consist of TRX frequencies of the complete 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 correction and synchronization cannel: MAINBCCH = FCCH + SCH + BCCH + CCCH* b) broadcast and common CCH only CCCH = BCCH + CCCH (CCCH = PCH + RACH + AGCH) c) Main BCCH with reduced CCCH capacity plus stand-alone dedicated CCH/4 MBCCHC = FCH + SCH + BCCH + CCCH* + SDCCH/C4 (0..3) + SACCH/C4 (0..3) d) MBCCHC plus SMS cell broadcast channel BCBCH = FCCH + SCH + BCCH + CCCH* + SDCCH/C4 (0..3) + SACCH/C4 (0..3) + CBCH Notes: - Only one FCCH/SCH is allowed per cell - on timeslot 0 of C0! - Creation of additional BCCH+CCCH (CHTYPE=CCCH) is possible but only on the timeslots 2,4 and 6 of C0. The info about the used control channel configuration is sent in the Parameter ‘CCCH_CONF’, which is part of the IE ‘Control Channel description’ sent in the SYS_INFO3 on the BCCH. If more than one BCCH is created for a cell the MSs observe the BCCH on timeslot 0 first and - having detected that there are more than one (from the CCCH_CONF) - select one BCCH/CCCH timeslot for all their CCCH activities on the basis of their “CCCH_GROUP”. The CCCH_GROUP is calculated from the last three digits if the IMSI and the CCCH configuration (which is derived from the parameters CCCH_CONF, NFRAMEPG and NBLKACGR - see GSM05.02 for details). - The CBCH replaces the 2nd SDCCH, i.e. there are only 3 SDCCH available if BCBCH is selected; only one CBCH is allowed per cell.

- A MBCCHC or a BCBCH can only be created if NBLKACGR ≤ 2 (see corresponding parameter in command SET BTS [CCCH]) - In a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) all frequencies with common control channels (BCCH,CCCH) must belong to the complete area.

EXTMODE=FALSE,

object: CHAN

range: TRUE, FALSE

default: FALSE

Extended mode, this parameter defines whether the channel is used in 'extended mode' for extended cells or not. Notes: - If the cell type is extended cell (i.e. CELLTYPE=EXTCELL (CREATE BTS [BASICS])) then all control channels must be set for 'extended mode'. - The radio timeslot of an 'extended' channel must have an even number (0,2,4... etc.).



FHSYID=0,

object: CHAN

range: 0..10

default: 0 = no hopping


GSM 04.08

GSM 12.20

Frequency hopping system identifier, 0(=no hopping) is mandatory for the BCCH.

MAIO=0,

object: CHAN

range: 0..63

default: 0


GSM 04.08

Mobile allocation 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 the Training 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 BCCH from the SCH. This is necessary for the correct selection and decoding of the BCCH bursts, especially if within a limited geographical area a frequency is used several times. If no value is entered 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. SACCH SDCCH = SDCCH/C8 (0..7) + SACCH/C8 (0..7) b) SDCCH/8 plus SMS cell broadcast channel SCBCH = SDCCH/C8 (0..7) + SACCH/C8 (0..7) + CBCH

Notes: - An SDCCH/8 can also be created as follows:

CHTYP=TCHSD,CHPOOLTYP=TCHPOOL (see CREATE CHAN command for TCHSDs). - At least one SDCCH must be created on the BCCH TRX (due to the implementation 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 (see corresponding parameter in command SET BTS [CCCH]) - The CBCH replaces the 2nd SDCCH, i.e. there are only 7 SDCCH available; only one CBCH is allowed per cell. - In a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) all frequencies with SDCCHs must belong to the complete area. - In an extended cell (CELLTYPE=EXTCELL, see command CREATE BTS [BASICS]), all SDCCHs must be created as ‘double’ timeslots (EXTMODE=TRUE, see below). - When an Abis interface is configured via satellite, it is urgently recommended to configure multiple SDCCH channels on different TRXs. This is necessary because the Abis LAPD transmit queues in



the BTS are managed per TRX(TEI), i.e. each TRX (TEI) has an own transmit queue. As the biggest percentage of all signalling activities in a cell are processed via the SDCCHs, it is recommended, to avoid an excessive concentration of the SDCCH signalling within one TRX (and thus one LPAD transmit queue), to distribute multiple SDCCHs over different TRXs within the cell. Otherwise the probability of the BTSE alarm ‘LAPD TRANSMIT QUEUE OVERFLOW’ will considerably increase, although with a more even distribution of the signalling load over the TEIs this could be avoided.

EXTMODE=FALSE,

object: CHAN

range: TRUE, FALSE

default: FALSE

Extended mode, this parameter defines whether the channel is used in 'extended mode' for extended cells or not. Notes: - If the cell type is extended cell (i.e. CELLTYPE=EXTCELL (CREATE BTS [BASICS])) then all control channels (BCCH, CCCH, CBCH and SDCCH) must be configured as ‘double’ timeslots (EXTMODE=TRUE). - The radio timeslot of an 'extended' channel must have an even number (0,2,4... etc.).

FHSYID=2,

object: CHAN

range: 0..10



GSM 04.08

GSM 12.20

Frequency hopping system identifier, 0=no hopping, all other values ‘X’ must have been created for this cell (BTS) before by CREATE FHSY:NAME=bsc:n/bts:n/fhsyid:x. Notes: - If synthesizer frequency hopping is used, hopping is not allowed for any CHAN object belonging to the BCCH TRX. - In concentric cells (CREATE BTS [BASICS]:CONCELL=TRUE) hopping is only allowed within the complete and within the inner area. This has to be taken into account when the FHSYIDs are assigned to the CHAN objects. - If Interference Classification of idle TCHs is enabled (see parameter INTCLASS in command SET BTS) while frequency hopping is active, the BTS measures the interference considering all frequencies used in the hopping sequence assigned to the a TCH in the frequency hopping system!

MAIO=0,

object: CHAN

range: 0..63

default: 0


GSM 04.08

Mobile allocation index offset, start position of the channel in the frequency hopping algorithm.

(TSC=),

object: CHAN

range: 0..7




GSM 04.08

Training Sequence Code, this optional parameter specifies the Training 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 SDCCH. This is necessary for the correct decoding of the SDCCH. The TSC for any type of SDCCH must correspond to the BCC (part of the BSIC sent on the SCH, see CREATE BTS [BASICS] parameter BSIC). If no value is entered for the parameter TSC the system automatically selects the BCC (see parameter BSIC (CREATE BTS [BASICS])) 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 channels TCHFULL = TCH/F + FACCH/F + SACCH/TF

b) Dual rate (full and half) channels TCHF_HLF = TCH/H(0) + FACCH/H(0) + SACCH/H(0) + TCH/H(1) or TCH/F + FACCH/F + SACCH/TF Notes: - A dual rate TCH can also be created as follows: CHTYP=TCHSD,CHPOOLTYP=TCHPOOL (see next CREATE CHAN command for TCH/SDs). - The FR portion of the TCH always implies speech versions FR, EFR and AMR FR; the HR portion implies HR and AMR HR. Which speech 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 mode, this parameter defines whether the channel is used in 'extended mode' for extended cells or not. Notes: - If the cell type is extended cell (CREATE BTS [BASICS]:CELLTYPE=EXTCELL) then all control channels must be set for 'extended mode', while TCHs may be created as 'single' and 'extended' timeslots (see also parameters CELLTYPE in command CREATE BTS [BASICS] and EXTCHO in command SET HAND [BASICS]). - The radio timeslot of an 'extended' channel must have an even number (0,2,4... etc.). - If an extended cell is the target of an inter-cell HO the handover will always take place to a 'double' timeslot first as the BTS can only determine the actual MS-BTS distance when the first MS messages are received. If the MS-BTS distance turns out to be small enough for a 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled).

FHSYID=1,

object: CHAN

range: 0..10



GSM 04.08

GSM 12.20

Frequency hopping system identifier, 0=no hopping, all other values Y must have been created before by CREATE FHSY:NAME=bsc:n/bts:n/fhsyid:y. Notes: - If synthesizer frequency hopping is used, hopping is not allowed for any CHAN object belonging to the BCCH TRX. - In concentric cells (see CREATE BTS [BASICS]:CONCELL=TRUE) hopping is only allowed within the complete and within the inner area. This has to be taken into account when the FHSYIDs are assigned to the CHAN objects. - If Interference Classification of idle TCHs is enabled (see parameter INTCLASS in command SET BTS [INTERF]) while frequency hopping is active, the BTS measures the interference considering all frequencies used in the hopping sequence assigned to the a TCH in the frequency hopping system!



GDCH=<NULL>,

object: CHAN

range: <NULL>

PBCCH, PCCCH,

default: <NULL>

GPRS Dedicated Channel, this parameter determines the TCH configuration for GPRS usage. The following values are possible: a) PBCCH: The TCH is fixed defined as Packet BCCH. b) PCCCH: The TCH is fixed defined as Packet Common Control CHannel c) <NULL> identifies a “shared” TCH. Shared TCHs can be used for GPRS and circuit switched traffic. All TCHs (TCHFULL, TCHF_HLF and TCHSD with CHPOOLTYP=TCHPOOL) for which GDCH is set to <NULL> (and for which the superordinate TRX was created with GSUP=TRUE) belong to the pool of TCHs that can be used for both circuit-switched calls and GPRS calls (so-called “Shared traffic channels”). The number of these TCHs that may be aligned as PDCHs simultaneously is determined by the parameter GPDPDTCHA (see CREATE PTPPKF). Whether the GPRS calls can be preempted by CS calls depends on the setting of the downgrade strategy (see parameter DGRSTRGY in command SET BSC).

Notes: - If GDCH is set to PBCCH, the GPRS mobile will not listen to the GSM BCCH but instead read the packet system information on the PBCCH. 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 already created PBCCH. - If no PBCCH is defined in the cell, the GPRS system information is broadcast on the existing (GSM-)BCCH within the SYSTEM INFORMATION TYPE 13. GPRS access is then performed via the normal (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


GSM 04.08

Mobile allocation index offset, determines start position of the channel in the frequency hopping algorithm. This parameter is sent in the 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 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

Terrestrial channel, this parameter defines the terrestrial channel, to which the TCH is mapped. The mapping is fixed. T: pcmb-no. - timeslot no. - subslot-no.

(TSC=),

object: CHAN

range: 0..7




GSM 04.08

Training Sequence Code, this optional parameter specifies the Training 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 automatically selects the BCC (see parameter BSIC (CREATE BTS [BASICS])) as TSC.



Creating hybrid TCHs/SDCCHs (TCH/SD) for the cell:

< The creation of hybrid TCHs/SDCCHs (TCH/SD) is an integral part of the feature “Set Command for Changes of Channel Combinations” and “Smooth Channel Modification” introduced in BR6.0.

a) The purpose of the feature “Set Command for Changes of Channel Combinations” is to allow a change of the channel type from TCH to SDCCH and vice versa without any service impact. To change the channel type (CHTYPE) for a specific CHAN object, it is necessary to delete and re-create it. However, whenever a channel on a TRX is deleted and created again, a reset of the BBSIG respectively CU is triggered which causes the interruption of all calls currently served by the affected TRX. With the new feature it is possible to use the new channel type TCH/SD and to determine its mode of operation (SDCCH or TCH) by the parameter CHPOOLTYP (for further details please see below). The mode of operation (SDCCH or TCH) can be changed using the CHPOOLTYP in a SET CHAN command. This SET CHAN command can be executed without any impact on the calls ongoing on the superordinate TRX.

b) The purpose of the feature “Smooth Channel Modification” is to allow a dynamic “on-demand” extension of the SDCCH capacity in case of SDCCH congestion. The feature avoids blocking of the SDCCH in cases of unexpected high SDCCH loads generated by SMS traffic or in specific areas (e.g. airports, train stations etc.). Channels that shall be dynamically used both as SDCCH and TCH must be created with CHTYPE=TCHSD and parameter CHPOOLTYP=TCHSDPOOL (see below). When the SDCCH utilization resp. SDCCH traffic load exceeds the threshold SDCCHCONGTH (see command CREATE BTS [BASICS]) the switchover from ‘Dual Rate TCH mode’ to ‘SDCCH/8 mode’ takes place automatically.

For this feature, a pool-concept was introduced for the dedicated radio channel resources:

• The SDCCH_POOL contains all channels declared as SDCCH/4

(CHTYPE=MBCCHC and BCBCH), SDCCH/8 (CHTYPE=SDCCH

and SCBCH) and TCH/SD that the operator decides to use as

configured SDCCHs (CHTYPE=TCHSD with POOLTYPE=

SDCCHPOOL).

• The TCH_POOL contains all channels declared as TCH full or TCH

dual (CHTYPE=TCHFULL or TCHF_HLF) and TCH/SD that the

operator decides to use as configured TCHs (CHTYPE=TCHSD

with POOLTYPE=TCHPOOL). These TCH may be used for both

CS and GPRS traffic.

• The TCH/SD_POOL contains all channels created as TCH/SD that

the operator decides to share between the TCH and SDCCH

resources depending on the SDCCH traffic load situation

(CHTYPE=TCHSD with POOLTYPE=TCHSDPOOL).

• The SDCCH_BACKUP_POOL is an additional system-internal (not

configurable) pool that contains the TCH/SD sub-channels that are

temporarily used as SDCCH. If during the processing of an SDCCH

request the percentage of busy SDCCHs has exceeded the

threshold SDCCHCONGTH, the BSC moves 8 SDCCH sub-

channels from the TCH/SD_POOL to the SDCCH_BACKUP_POOL

A configurable timer (see parameter TGUARD in the command

SET BSC [BASICS]) avoids oscillation between both pools.

Within each pool the ‘idle Interference band’ classifies the resources.

This classification is also valid for the TCH_SD used as SDCCH. >



CREATE CHAN:

NAME=BTSM:0/BTS:0/

TRX:0/CHAN:4,

Object path name.

CHTYPE=TCHSD,

object: CHAN


on the right


GSM 05.02

GSM 04.08

Channel type = TCHSD, this parameter was introduced in BR6.0 for the features ‘ Smooth Channel modification ’ and ‘ Set Command for Changes of Channel Combinations ‘.

TCHSD = SDCCH/8 + SACCH/8 + TCH/H(0,1) + FACCH/H(0,1) + SACCH/TH(0,1) or TCH/F + FACCH/F + SACCH/F

The above channel capability description means that the channel type TCHSD represents a channel, that can work a) as pure Dual Rate TCH, b) as pure SDCCH/8 or b) can dynamically change between both modes (DR-TCH or SDCCH/8).

Which of these operation modes is in effect, depends on the setting of the parameter CHPOOLTYP (see below). Please refer to CHPOOLTYP 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 also all TCHSDs with CHPOOLTYP=SDCCHPOOL or TCHSD) on different TRXs. This is necessary because the Abis LAPD transmit queues in the BTS are managed per TRX(TEI), i.e. each TRX (TEI) has an own transmit queue. As the biggest percentage of all signalling activities in a cell are processed via the SDCCHs, it is recommended, to avoid an excessive concentration of the SDCCH signalling within one TRX (and thus one LPAD transmit queue), to distribute multiple SDCCHs over different TRXs within the cell. Otherwise the probability of the BTSE alarm ‘LAPD TRANSMIT QUEUE OVERFLOW’ will considerably increase, although with a more even distribution of the signalling load over the TEIs this could be avoided.

CHPOOLTYP= TCHSDPOOL,

object: CHAN

range: TCHPOOL

SDCCHPOOL

TCHSDPOOL

<NULL>

default: <NULL>

Channel pool type, this parameter can only be set for those

channels that have been created with CHTYPE=TCHSD and defines

its application (pool type).

1) If CHPOOLTYP=TCHPOOL the TCHSD is fixed configured as

TCH and used exclusively as TCH, i.e. it is handled by the call

processing and channel allocation as a normal dual rate TCH. The

advantage of this configuration compared to the one with

CHTYPE=TCHF_HLF is that it is possible to change this channel to

‘SDCCH mode’ without service interruption of the TRX by entering the

command SET TRX:CHPOOLTYP=SDCCHPOOL.

Channels of this type are part of the system-internal TCH_POOL.

2) If CHPOOLTYP=SDCCHPOOL the TCHSD is fixed configured as

SDCCH/8 and used exclusively as SDCCH/8, i.e. it is handled by the

call processing and channel allocation in the same way as if it was

created with CHTYPE=SDCCH. The advantage of this configuration

compared to a normal SDCCH is that it is possible to change this

channel to ‘Dual rate TCH mode’ without service interruption of the

TRX by entering the command SET TRX:CHPOOLTYP=TCHPOOL.

Channels of this type are part of the system-internal SDCCH_POOL.

3) If CHPOOLTYP=TCHSDPOOL the TCHSD can be used for

Smooth Channel Modification, i.e. its mode of operation (Dual Rate

TCH or SDCCH/8) can be dynamically changed depending on the

SDCCH traffic load in the cell (see parameter SDCCHCONGTH in

command CREATE BTS).

TCHSD mode (Dual Rate TCH) TCHSDs with CHPOOLTYP=TCHSDPOOL are initially part of the

system-internal TCH/SD_POOL. In this mode a TCH/SD works as



normal dual rate TCH, but is only selected by the TCH allocation

algorithm if no idle TCH from the TCH_POOL (CHTYPE=TCHFULL or

TCHF_HLF) can be found. Within the TCH_POOL and the

TCH/SD_POOL, the TCHs with the best interference class (see par.

INTCLASS in command SET BTS [INTERF]) are allocated first.

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

Notes:

- Only TCH/SDs with CHPOOLTYP=TCHPOOL can be used for

GPRS traffic (“shared” TCH)!

- The BTS does not know anything about the association of the

TCH/SD channels to the ‘BSC channel pools’. Instead, for the BTS a

TCH/SD is treated as a normal dual rate TCH if it is ‘idle’ (i.e.in 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 mode, this parameter defines whether the channel is used in 'extended mode' for extended cells or not. Notes: - If the cell type is extended cell (CREATE BTS [BASICS]:CELLTYPE=EXTCELL) then all control channels must be set for 'extended mode', while TCHs may be created as 'single' and 'extended' timeslots (see also parameter EXTCHO in command SET HAND [BASICS]). - The radio timeslot of an 'extended' channel must have an even number (0,2,4... etc.). - If an extended cell is the target of an inter-cell HO the handover will always take place to a 'double' timeslot first as the BTS can only determine the actual MS-BTS distance when the first MS messages are received. If the MS-BTS distance turns out to be small enough for a 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled).



FHSYID=1,

object: CHAN

range: 0..10



GSM 04.08

GSM 12.20

Frequency hopping system identifier, 0=no hopping, all other values Y must have been created before by CREATE FHSY:NAME=bsc:n/bts:n/fhsyid:y. Notes: - If synthesizer frequency hopping is used, hopping is not allowed for any CHAN object belonging to the BCCH TRX. - In concentric cells (see CREATE BTS [BASICS]:CONCELL=TRUE) hopping is only allowed within the complete and within the inner area. This has to be taken into account when the FHSYIDs are assigned to the CHAN objects. - If Interference Classification of idle TCHs is enabled (see parameter INTCLASS in command SET BTS [INTERF]) while frequency hopping is active, the BTS measures the interference considering all frequencies used in the hopping sequence assigned to the a TCH in the frequency hopping system!

GDCH=<NULL>,

object: CHAN

range: <NULL>

default: <NULL>

GPRS Dedicated Channel, this parameter determines the TCH configuration for GPRS usage (for further details please see the same parameter in the previous CREATE CHAN command for the creation of Full Rate or Dual Rate TCHs). It is only relevant for the parameter combination CHTYP=TCHSD,CHPOOLTYP=TCHPOOL (for parameter CHPOOLTYP please see above) which indicates that the TCHSD operates as a normal TCH. Only in this case the CHAN object belongs to the system-internal TCH_POOL. In this configuration only the value <NULL> is allowed for GDCH – this value indicates that the TCHSD works as “shared” TCH, i.e. the TCHSD can be used for CS as well as for GPRS traffic.

If the TCH is created with the parameter combination CHTYP=TCHSD,CHPOOLTYP=TCHPOOL it can never be used for GPRS traffic. Of course, the same goes for the the parameter combination CHTYP=TCHSD,CHPOOLTYP=TCHPOOL

MAIO=0,

object: CHAN

range: 0..63

default: 0


GSM 04.08

Mobile allocation index offset, determines start position of the channel in the frequency hopping algorithm. This parameter is sent in the 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 case the 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




GSM 04.08

Training Sequence Code, this optional parameter specifies the Training 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 SDCCH. This is necessary for the correct decoding of the SDCCH. The TSC for any type of SDCCH and TCH/SD must correspond to the BCC (part of the BSIC sent on the SCH, see CREATE BTS [BASICS] parameter BSIC). If no value is entered for the parameter TSC the system automatically selects the BCC (see parameter BSIC (CREATE BTS [BASICS])) as TSC.



Setting the cell specific parameters and threshold values for voice call Handover:

� For detailed information regarding Handover Thresholds please

refer to the chapter Handover Thresholds & Algorithms and Interworking of Handover and Power Control!

SET HAND [BASICS] :

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

NAME=

BTSM:0/BTS:0/HAND:0, Object path name.

ALEVFULHO=2-1,

object: HAND [BASICS]


(averaging period)


1-3 (DTX weight. factor)



Handover averaging parameters for fast uplink handover decision, this attribute defines two averaging parameters for the measurement process that is used for the fast uplink handover decision. The first field, aLevFuHo, defines the averaging window size (that is smaller than the normal window size), the second one, wLevFuho, indicates the DTX weighting factor. As the fast uplink handover should react quite quickly to UL level drops, the averaging window should be significantly smaller than that of other handover types (e.g. level handover). The default value of ‘2’ is therefore reasonable. To additionally speed up the fast uplink handover decision, the BTS uses a special algorithm for the UL measurement processing. In case of a normal uplink handover, the BTS cannot make a handover decision directly after the end of the UL measurement period, because it has to wait for the next MEASUREMENT REPORT from the MS which contains the ‘DTX used’ flag. This flag determines whether the BTS must enter the FULL values (if DTX was not used in the measurement) or the SUB values (if DTX was used in the measurement period) into the averaging window for the handover decision (for further details about DTX and FULL and SUB values please refer to the parameter DTXDL in command SET BTS [OPTIONS]). For fast uplink handover, a different approach is used: At the end of the UL measurement period, the BTS directly inserts the SUB values into the averaging window (assuming that DTX was active in the measurement period) thus allowing a preliminary decision. During periods with speech transmission (i.e. DTX not used), the SUB values have a lower statistic reliability than the FULL values, but tests have shown that they reflect the real radio conditions well enough to justify a preliminary decision. If the ‘DTX used’ flag, that is received in the MEASUREMENT REPORT from the MS 480ms later, indicates that in the affected measurement period DTX was ‘not used’, the BTS removes the SUB value from the averaging window and replaces it by the FULL value (the number of FULL values inserted depends on the DTX weighting factor). This algorithm reduces the handover decision time by one measurement period (480ms) with a minimum impact on the reliability of the averaged UL RXLEV values.

Also for the averaging of the neighbour cell downlink RXLEV measurements, the approach for fast uplink handover is different from the one of the other handover types: while for all other handover types the size of the averaging window for the neighbour cell downlink RXLEV measurements is determined by the parameter HOAVPWRB (see below), which generally defines a comparatively long averaging period, the averaging window for the neighbour cell measurements for fast uplink handover is



AveragingPeriodFULHO-NC = ALEVFULHO – 1 SACCH multiframe

This approach was chosen, as a very quick handover decision due to fast uplink requires the consideration of the neighbour cells that offer a sufficient DL RXLEV at that particular point of time. This means that, if the default value is used (ALEVFULHO=2-1), this means that the suitable neighbour cell for fast uplink handover is derived from only 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 window for downlink CODEC MODE REQUESTs (CMR) received from the MS during an AMR (Adaptive MultiRate) call. The CMRs are continuously sent from the MS to the BTS, even if no change of the current 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 is rounded to the nearest integer value. The rounded average indicates the offset of the presently most appropriate CODEC within the ACS. The purpose of this parameter is to avoid a too frequent changes of the downlink CODEC mode in case of instable or quickly varying radio conditions.

The Periodicity of the CMR sending depends on whether DTX uplink is currently used or not. If DTX uplink is not used, the CMR is sent every second TDMA speech frame (i.e. every 40 ms). If DTX uplink is continuously used, the CMR CMR is repeated every 8. TDMA speech frame (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 value range that is supported by the BTS is 1..31. In other words, it does not 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 is created via satellite link, this attribute should be set to its maximum value as a the CODEC mode adaptation process (which is - for the downlink - executed by the TRAU) is considerably slowed down by the higher transmission delay on the satellite link. As mentioned in the parameter AMRFRC1 (see CREATE BTS [BASICS]), if the BTS detects (after averaging) that the MS requests a CODEC mode change in the downlink, the BTS sends a corresponding CODEC MODE COMMAND (CMC) to the TRAU to instruct the TRAU to perform the switchover to the new mode. Due to the higher delay on the satellite link, this CMC reaches the TRAU much later than in case of a terrestrial link. This means that, in case of a small value of AMRACMRDL and quickly changing radio conditions, the CODEC mode change could be executed at a point of time when the radio conditions, that triggered it, are no longer present. Thus, as the execution of the CODEC mode change (via CMR and CMC) is slowed down, it also makes sense to slow down the CODEC mode change decision, to avoid a ‘too nervous’ link adaptation reaction in case of quickly changing radio quality conditions. - The averaging mechanism for the uplink AMR CODEC mode adaptation is independent of AMRACMRDL as the associated averaging mechanisms are hardcoded. - although the parameter AMRACMRDL is included in the SET HAND command, it has no relevance for the handover decisions for AMR calls.



CCDIST=FALSE,


range: TRUE, FALSE

default: FALSE

Enable concentric cell distance handover, this flag determines whether in the concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) the distance should also be taken into account for the intracell handover decision and for the channel assignment 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 (for handover) are fulfilled or if the MS-BTS distance exceeds the distance limit according to the principles explained for the parameter HOCCDIST.

- new calls are set up in the inner area or a handover from complete to inner area is executed if the level conditions defined by the

parameter HORXLVDLO are fulfilled and if the MS-BTS distance is smaller than the distance limit according to the principles explained for the parameter HOCCDIST.

For the parameters HORXLVDLI, HORXLVDLO and HOCCDIST, please see below.

CCELL1=<NULL>,


range: BTSM:<n>/BTS:<n>,

<NULL>

default: <NULL>

Colocated cell 1, this parameter is only relevant if the parameter ININHO (see below) is set to TRUE and defines the first of two possible adjacent sectorized concentric cells (see parameter CONCELL in command CREATE BTS [BASICS]) to which an intercell handover from inner-to-inner area shall be possible, resp. for which the target area (inner or complete) shall be determined by the PREFERRED AREA REQUEST procedure during intercell handover.

The ‘Colocated Cell' (for meaning of the term ‘colocated cell’ please refer to the parameter ININHO, see below) is represented by the path name 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 cell 2, this parameter defines the second of two possible adjacent sectorized concentric cells suitable for inner-to-inner handover. For more details please see parameter CCELL1.

DISTHO=TRUE,


range: TRUE, FALSE

default: TRUE


Distance Handover enabled, determines whether handover due to long distance between MS and BTS is enabled. Note: This flag only determines whether inter-cell handovers may be executed with cause ‘distance’. It is only relevant if intercell handover is enabled (INTERCH=TRUE, see below).



DPBGTHO=FALSE,


range: TRUE, FALSE

default: FALSE

Dynamic power budget handover, this parameter determines whether ‘dynamic power budget’ handover or ‘speed sensitive handover’ is active. This flag is only relevant if power budget handover is enabled (PBGTHO=TRUE.) Speed sensitive handover is e.g. used for micro-/umbrella-cell configurations. An umbrella cell covers the same area as a number of microcells and is normally used as handover target cell in case of microcell congestion or for MSs which move very fast. Speed sensitive handover shall allow power budget handovers to a microcell if an MS moves slow but shall prohibit them if the MS moves fast in order to avoid unnecessary signaling load due to repeated handovers (if the MS moves fast it may have left the microcell already when the handover is actually executed). For this reason the power budget handover to a microcell is delayed by a special timer (the microcell is ‘penalized’ as long as the timer runs). If the handover conditions are still present when the timer expires the handover is executed. The timer is administered with the parameter HOMDTIME (CREATE ADJC). It is, however, only in effect for a certain neighbour cell if the parameter MICROCELL is also set to TRUE in addition. The parameters relevant for the administration of speed sensitive handover are: MICROCELL, HOMDTIME, HOMDOFF and HOMSOFF (see command CREATE ADJC).

EADVCMPDCMHO=<NULL>,


range: TRUE, FALSE, <NULL>

default: <NULL>

Enable advanced compression decompression handover, this parameter is used to enable/disable the feature ‘advanced compression/decompression handover’ algorithm which was introduced by CR1632 in BR7.0.

AMR compression handover The purpose of AMR compression handover is to transfer AMR FR calls with suitably good radio link quality to an AMR HR TCH in order to use the TCH resources more efficiently. The Intracell AMR compression handover is not continuously enabled in the BTS, but is temporarily enabled / disabled by the BSC (by sending the Abis O&M message SET ATTRIBUTE to the BTS) depending on a) the current radio TCH load of the cell (see parameters EHRACTAMR in command SET BSC [BASICS] and HRACTAMRT1 in command CREATE BTS [BASICS]) or b) the current Abis pool TCH load of the BTSM (see parameters ABISHRACTAMR and ABISHRACTTHR in command CREATE BTSM).

AMR Decompression handover The purpose of AMR decompression handover is to transfer AMR HR calls with poor radio link quality to an AMR FR TCH in order to improve the speech quality. Important: In contrast to the AMR compression handover the intracell AMR decompression handover is continuously enabled and is completely 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 automatically disabled if HR is generally disabled in the BSC by setting the parameter HRSPEECH to FALSE (see command SET BSC [BASICS]). The parameter EADVCMPDCMHO just allows to switch between different modes of AMR compression/decompression handover (standard or advanced).

AMR compression/decompression handover decision

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 in BR6.0. In this case the AMR compression and decompression



handover decision is solely based based on quality (C/I) criteria defined by the parameters HOTHAMRCDL, HOTHAMRCUL, HOTHAMRDDL and HOTHAMRDUL (see below).

Standard AMR Compression handover decision criteria (EADVCMPDCMHO=FALSE) An AMR compression handover from AMR FR to AMR HR is triggered if for a particular AMR FR call the following conditions are fulfilled:

(C/I_UL > HOTHAMRCUL) AND

(C/I_DL > HOTHAMRCDL)

Standard AMR Decompression handover decision criteria (EADVCMPDCMHO=FALSE) An AMR de-compression handover from AMR HR to AMR FR is triggered if for a particular AMR HR call the following conditions are fulfilled:

(C/I_UL < HOTHAMRDUL) OR

(C/I_DL < HOTHAMRDDL)

Advanced AMR Compression Handover (EADVCMPDCMHO=FALSE) The advanced AMR compression/dedcompression handover algorithm additionally considers the current level conditions and the current dynamic power reduction due to BS and MS power control. This is done by considering an additional level threshold and by comparing the C/I thresholds to a C/I value that was ‘corrected’ by the corrent power reduction.

In this context the new parameters HOTHCMPLVDL, HOTHCMPLVUL, HOTHDCMLVDL and HOTHDCMLVUL (see below) are considered.

The new BR7.0 AMR compression handover decision is based on the rules listed below:

Advanced AMR Compression handover decision criteria (EADVCMPDCMHO=TRUE) An AMR compression handover from AMR FR to AMR HR is triggered if for a particular AMR FR call the following conditions are fulfilled:

{[(RXLEV_UL > HOTHCMPLVUL) AND (C/I_UL >= C/Imax)] OR (C/I_UL + MS_PWRRED > HOTHAMRCUL)}

AND

{[(RXLEV_DL > HOTHCMPLVDL) AND (C/I_DL >= C/Imax)] OR (C/I_DL + BS_PWRRED > HOTHAMRCDL)}

Advanced AMR Decompression handover decision criteria (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 are fulfilled:

{[(RXLEV_UL < HOTHDCMLVUL) OR (C/I_UL < C/Imax)] AND (C/I_UL + MS_PWRRED < HOTHAMRDUL)}

OR

{[(RXLEV_DL < HOTHCMPLVDL) OR (C/I_DL < C/Imax)] AND (C/I_DL + BS_PWRRED < HOTHAMRDDL)}

where MS_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 information on the advanced AMR compression handover condition formulas and C/Imax



In practice the process for the continuous determination of C/I values is limited to a maximum hard-coded value C/Imax=20dB. This limitation is related to the determination of C/I via measurements of BER and mapping on corresponding C/I values. For high C/I values, the BER is very low and, for a reasonable averaging window length, the accuracy of the resulting C/I is limited. In case that no bit 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 adding C/I to the current MS/BS_PWRRED (power reduction due to power control) in the transient phase of a call (The ‘transient phase’ is the start phase of a call in good coverage conditions, when the BS/MS power is still at the maximum or close to it but is continuously changing due to dynamic power reduction) in the following way: Reaching the compression threshold may be delayed whereas an unlimited C/I measurement would trigger compression immediately. Similarly, decompression threshold may be reached within the transient phase causing an unjustified decompression handover whereas an unlimited C/I measurement would have prevented this.

To avoid unjustified decompression handover in transient phase, irrespective of whether C/I was considered in the primary condition or not, the following additional conditions for decompression are therefore taken into account:

1. C/I is smaller than a certain threshold, e.g. C/Imax, or alternatively, averaged RXQUAL is greater than a certain threshold 2. RXLEV is smaller than a certain threshold.

To avoid delayed compression handover in the transient phase, irrespective of whether C/I was considered in the primary condition or not, the following additional conditions for compression are taken into account:

1. C/I is equal or greater than hard coded C/Imax, or, alternatively, averaged RXQUAL is equal or smaller than a certain threshold, 2. RXLEV is greater than a certain threshold

As an example for a combination of these additional conditions with the primary conditions the following expression shall be used to trigger compression handover (must be fulfilled for both, xx = UL, DL; measurements C/I are different entities for both links but not marked as 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 and MS/BS_PWRRED (power reduction due to power control) is lower than the decompression handover threshold.

To avoid unjustified decompression handover during the transient phase (e.g. immediately after compression handover) a further condition has to be fulfilled: C/I has to be lower than C/Imax. This avoids that in case of unproper setting of the decompression handover threshold, the decompression handover is triggered immediately after allocating the call on the HR channel (PR = 0 and hoThresAMRDecompr > 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 unjustified decompression handover.

Notes on averaging With each new channel activation the channels averaging windows



are initialized and in case of the HO quality averaging windows they are initialized to RXQUAL=0 (i.e. C/I=20). The point of time of the first AMR compression/decompression handover decision depends on the type (FR, HR) of activated TCH:

1) If a FR TCH is activated the BTS starts checking for decompression only when the HO quality averaging windows for UL and DL are completely filled for the first time (i.e. (HOAVQUAL * 480ms(SACCH-period time) + 480ms (results of first SACCH-period are not entered in averaging windows)), so that in this case the initialization value does not have any influence (otherwise it might lead to an unjustified compression HO right away).

2) If a HR TCH is activated the radio conditions are checked right away (after omitting the first SACCH-period results) since the average 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 (parameter INTRACH, see below) due to quality (for a call whose quality is still poor after decompression handover), the features ‘Cell load dependent actvation of half rate’ (see parameter EHRACT in command CREATE BTS [BASICS]) and ‘Abis load dependent activation of half rate’ (see parameter ABISHRACTTHR in command CREATE BTSM) are not considered if the BSC receives an INTRACELL HANDOVER CONDITION INDICATION due to quality reasons (cause values ‘uplink quality’ or ‘downlink quality’). This means that the BSC does not check the current BTS TCH load and the BTSM Abis pool TCH load in case of an intracell handover due to quality.

EFULHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable Fast Uplink handover, this parameter enables the feature ‘Fast Uplink Handover’ (this parameter only relevant if intercell handover is enabled (INTERCH=TRUE, see below). Fast Uplink Handover was introduced in BR6.0 to as an additional fast handover mechanism that is able to prevent call drops that occur due to a sudden and drastic drop of the UL receive level. Such level drops can occur e.g. in urban areas with small cells and obstacles in the radio path (e.g. buildings). If the level drops too quickly, the standard level handover mechanism is often too slow to ‘rescue’ the call as a the standard level handover normally uses small but not very small averaging window sizes (normal is 4 SACCH multiframes ≈ 2 sec) and is only triggered after the PWRC control algorithm (if PWRC is enabled) has adjusted the transmit power to the maximum. For this reason the ‘fast uplink handover’ was introduced: This handover type uses own averaging windows (see parameter ALEVFULHO), which should be set shorter than the ones of the standard level handovers to allow a shorter reaction times, and own handover trigger thresholds (THLEVFULHO). Fast uplink handover is completely de-coupled from the PWRC algorithm, i.e. fast uplink handover is immediately triggered if the UL receive level drops below the fast uplink handover threshold THLEVFULHO, no matter whether the MS transmit power is already at the maximum or not.

To qualify an adjacent cell as a suitable target cell for fast uplink handover, an additional administrable level offset is considered during the handover decision (see parameter FULRXLVMOFF in the ADJC object). Moreover, it is possible to priorize specific adjacent cells in the ranking of the target cells by a flag in the ADJC data (see parameter FULHOC in the ADJC object).


Note: If the BTS transmits a HANDOVER COMMAND for a fast uplink



handover to the MS via the Um, it simultaneously increases the BS and MS power. This mechanism was implemented to increase the probability that the message is successfully transmitted and received/acknowledged from the MS side.

ELEVHOM=FALSE,


range: TRUE, FALSE

default: FALSE

Enable level handover margin, this parameter enables the feature ‘level handover margin’. This feature foresees the consideration of an additional level handover margin for the determination of suitable level handover target cells.

For further details, please refer to the parameter LEVHOM (command CREATE/CREATE ADJC) and to the section “Handover Thresholds and Algorithms” in the appendix of this document.

ELIMITCH=TRUE,


range: TRUE, FALSE

default: TRUE

Enable limitation of intra-cell handover repetition, this flag determines whether the feature 'Limitation of Intracell handover repetition’ is enabled or not. It enables a mechanism that prevents an unlimited repetition of intra-cell handovers due to quality (see parameter INTRACH in command SET HAND [BASICS]) and AMR Compression (see parameter EADVCMPDCMHO in command SET HAND [BASICS]).

a) Limitation of Intracell Handover due to quality In the current implementation the following scenario might happen quite easily: if the flag ELIMITCH is set to FALSE, for consecutive repeated intra-cell handovers due to quality (triggered for a particular call) the idle TCHs are assigned cyclically without ever triggering an inter-cell HO unless one of the intra-cell HOs is not successful. If Idle Channel Supervision is activated (see command SET BTS [INTERF]) the BSC TCH allocation algorithm considers the interference levels reported via the RF RESOURCE INDICATION messages in addition.

In cells with good level but high interference, however, an inter-cell handover is desired, if intra-cell handovers do not lead to better radio conditions, especially if frequency hopping is used. If the flag ELIMITCH is set to TRUE, a counter implemented in the BSC is increased on every successful quality intracell HO completion. If the counter reaches an administrable threshold (see parameter MAIRACHO), the next CHAN ACT message the BSC sends for an intra-cell quality handover contains the GSM08.08 cause 'handover successful'. This message leads to the start of an administrable timer (see parameter TINOIERCHO) in the BTS which suppresses the generation of further INTRACELL HANDOVER CONDITION INDICATION messages with cause ‘quality’ as long as the timer runs. If in this period a suitable neighbour cell is found an inter-cell handover is attempted.

b) Limitation of Intracell Handover due to AMR Compression Since BR6.0 the same mechanism as described above is also used for AMR Compression Handover (Intracell handover AMR FR -> AMR HR, see parameter HOTHANRCDL) and AMR decompression handover (Intracell handover AMR HR -> AMR FR, see parameter HOTHAMRDDL). Tests have shown that, if the quality conditions are near to the quality thresholds for AMR compression/decompression handover, a ping-pong between AMR compression handover and AMR decompression handover may occur. For the “Limitation AMR Compression Handover Repetition” an own counter is implemented in the BSC, which is increased whenever the BSC executes an AMR compression handover (i.e. sends a CHANNEL ACTIVATION after receipt of an appropriate INTRACELL HANDOVER CONDITION INDICATION). If this counter reaches the threshold MAIRACHO (see above) due to continuous ping-pong between AMR compression handover and AMR decompression handover, the next CHAN ACT message the BSC sends for an intracell AMR compression handover contains the GSM08.08 cause 'handover successful'. This message leads to the start of the timer (see parameter TINOIERCHO) in the BTS which suppresses the generation of further INTRACELL



HANDOVER CONDITION INDICATION messages with cause ‘AMR compression’ for the same cause as long as the timer runs. Note: For quality intracell handover, this feature only works if the quality intra-cell HO is controlled by the BSC (LOTRACH=TRUE).

EUBCHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS better cell handover, this parameter represents the database flag to enable or disable ‘better cell’ handover from GSM to UMTS (2G-3G handover). This parameter is only relevant if UMTS handover is generally enabled for this BTS (see parameter EUHO) and if ‘better cell’ handover (also called Power Budget Handover) is enabled in this BTS (see parameter PBGTHO).

Attention: 2G-3G handover from GSM to UMTS FDD due to ‘better cell’ is only possible if the measurement reporting of the multiRAT mobiles is based on RSCP (level-oriented), i.e. the parameter FDDREPQTY (see command CREATE BTS [BASICS]) must be set to the value RSCP.

Setting this EUBCHO=TRUE simply means that the BTS will also consider UMTS FDD neighbour cells as possible target cells in addition to the normal 2G (GSM, DCS, PCS) neighbour cells for power budget handover decisions. If EUBCHO is set to FALSE, the BTS excludes these 3G cells from the target cell list during the power budget handover decision process, even if they have been created as neighbour cells in the BSC database (see commands CREATE TGTFDD and CREATE ADJC3G).

Of course, different minimum criteria and better cell criteria apply for UMTS FDD neighbour cells than for for GSM 2G neighbour cells: - While for GSM neighbour cells the minimum receive level for handovers is defined by the parameters RXLEVMIN (see command CREATE ADJC), the minimum radio requirements for UMTS FDD neighbour cells are defined by the parameter RXLEVMINC (see command CREATE ADJC3G) - While for GSM neighbour cells the better cell criterion for power budget handovers is defined by the parameter HOM (see command CREATE ADJC), the ‘better cell’ radio requirement for UMTS FDD neighbour cells is defined by the parameter HOM defined in object ADJC3G (see command CREATE ADJC3G). For an accurate comparison of the current RXLEV value of the serving 2G cell to the RSCP value of the UMTS FDD neighbour cell (see explanations provided for parameter FDDREPQTY in command CREATE BTS [BASICS]), the parameter UADJ (see command CREATE ADJC3G) is considered in addition.

UMTS handover due to ‘better cell’ and UMTS handover due to ‘sufficient coverage’ (see parameter EUBCHO) cannot be enabled at the same time, i.e. it is up to the operator to decide which type of handover shall be used for a particular cell.

Note: Handover from GSM to UMTS (2G-3G handover) is only supported 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 (see above), EUIMPHO and EUSCHO (see below) are relevant.




EUIMPHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS imperative handover, this parameter represents the database flag to enable or disable ‘imperative’ handover from GSM to UMTS (2G-3G handover). This parameter is only relevant if UMTS handover is generally enabled for this BTS (see parameter EUHO). The term ‘imperative handover’ represents handover types which are triggered to ‘rescue’ ongoing calls that suffer from bad radio conditions, such as - handover due to level (handover causes ‘uplink strength’ or ‘downlink strength’, see parameter RXLEVHO) - handover due to quality (handover causes ‘uplink quality’, ‘downlink quality’, see parameter RXQUALHO) - forced handover (handover cause ‘forced’) due to directed retry, preemption and O&M intervention (see parameters ENFORCHO (SET BSC [BASICS]) and EPRE (SET BTS [OPTIONS])). - handover due to distance (handover cause ‘distance’, see parameter DISTHO).

EUIMPHO is only relevant if at least one of the listed handover types is enabled by the abovementioned parameters. Setting EUIMPHO to TRUE simply means that the BTS will also consider UMTS FDD neighbour cells as possible target cells in addition to the normal 2G (GSM, DCS, PCS) neighbour cells for imperative handover decisions. Which type of imperative handover is considered, exclusively depends on the handover-type-specific settings of the abovementioned database flags resp. parameters. If EUIMPHO is set to FALSE, the BTS excludes these 3G cells from the target cell list during the imperative handover decision process, even if they have been created as neighbour cells in the BSC database (see commands CREATE TGTFDD and CREATE ADJC3G).

Of course, different minimum criteria apply for UMTS FDD neighbour cells than for for GSM 2G neighbour cells. - While for GSM neighbour cells the minimum receive level for handovers is defined by the parameters RXLEVMIN (see command CREATE ADJC), the minimum radio requirements for UMTS FDD neighbour cells are defined by the parameter RXLEVMINC (if FDDREPQTY the (see command CREATE ADJC3G). - As opposed to GSM 2G internal handovers, an additional minimum criterion is evaluated for imperative handovers towards UMTS FDD neighbour cells: the minimum radio requirements for UMTS FDD neighbour cells for an imperative handover are defined by the parameter UMECNO (see command CREATE ADJC3G).




EUSCHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable UMTS sufficient coverage handover, this parameter represents the database flag to enable or disable ‘sufficient coverage’ handover from GSM to UMTS (2G-3G handover). This parameter is only 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 handovers and which is only applied for 2G-3G neighbour cell relations. Thus the parameter EUSCHO explicitly enables this handover type and applies it to all UMTS neighbour cells that were created in the BSC database (see commands CREATE TGTFDD and CREATE ADJC3G).

‘Sufficient coverage’ handover is triggered, if the DL radio conditions of a particular 3G UMTS neighbour cell have exceeded configurable thresholds. Which thresholds are relevant, depends on the measurement reporting method defined by the parameter FDDREPQTY (see command SET BTS [BASICS]): - If FDDREPQTY is set to RSCP (level-oriented measurement reporting based on RSCP), the minimum target cell level requirement is defined by the the parameter USRSCP (see command CREATE ADJC3G). - If FDDREPQTY is set to ECNO (quality-oriented measurement reporting based on Ec/No), the minimum target cell quality requirement is defined by the the parameter USECNO (see command CREATE ADJC3G).

(defined as RSCP – Received Signal Code Power from UMTS, Ec/No – quality related for UMTS cells) have exceeded the threshold defined by

UMTS handover due to ‘better cell’ (see parameter EUBCHO) and UMTS handover due to ‘sufficient coverage’ cannot be enabled at the same time, i.e. it is up to the operator to decide which type of handover shall be used for a particular cell.


EXTCHO=FALSE,


range: TRUE, FALSE

default: FALSE

Enable extended cell handover, determines whether the feature Extended Cell Handover is enabled for this cell. 'Extended cell handover' means an intra-cell handover from near to far (singleTS-to-doubleTS) or from far to near (doubleTS-to-singleTS). This handover is performed on distance criteria determined on the basis of the threshold 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 the handover will always take place to a 'double' timeslot first as the BTS can only determine the actual MS-BTS distance when the first MS messages are received. If the MS-BTS distance turns out to be small enough for a 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled). - The intracell handover causes “near to far” (single to double) respectively “far to near” (double to single) do not exist for SDCCH-SDCCH handover as in an extended cell all SDCCHs are always configured as double timeslots. In other words, as all SDCCHs are only in the far area, an SDCCH-SDCCH handover to the near area can never take place.



HIERC=FALSE,


range: TRUE, FALSE

default: FALSE

Hierarchical Cell Handover, this flag enables the feature ‘hierarchical cell structures’. If it is set to TRUE, this simply means that the target cell list generation process in the BTS considers the priority levels of the serving cell (see parameter PL, only relevant in case of power budget handover and traffic handover) and the neighbour cells (see parameters PLNC and PPLNC in the ADJC object, relevant for all imperative handovers, except fast uplink handover).

HIERF=RANK0,


range: RANK0, RANK1

default: RANK0

Hierarchical cell ranking flag, this parameter is used to switch between two different ranking methods. This flag is only relevant if intercell handover is enabled (INTERCH=TRUE, see below).

The selectable ranking methods RANK0 and RANK1 are only relevant for imperative handovers (i.e. level, quality and distance) and forced handover (directed retry, see parameter ENFORCHO (SET BSC [BASICS])). Possible values:

Rank0 (Ranking Method 0): All adjc. cells where RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) are subdivided into two sublists: The upper sublist consists of all neighbour cells where PBGT(n) - HO_MARGIN(n) > 0 , the lower sublist consists of all neighbour cells where

PBGT(n) - HO_MARGIN(n) ≤ 0. Within each sublist the cells are sorted in increasing order of priority Neighbour cells with the same priority are sorted by PBGT(n) - HO_MARGIN(n).

Rank1 (Ranking Method 1): All adjc.cells where RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) are subdivided into two sublists: The upper sublist consists of all neighbour cells where RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + levelOffsetNcell, the lower sublist consists of all neighbour cells where

RXLEV_NCELL(n) ≤ RXLEVMIN(n) + Max(0,Pa) + levelOffsetNcell, Within each sublist the cells are sorted in increasing order of priority Neighbour cells with the same priority are sorted by PBGT(n) - HO_MARGIN(n).

For further details please refer to the section ‘Handover Thresholds & Algorithms’. The term ‘levelOffsetNcell’ represents the parameter LEVONC (CREATE ADJC).

HOAVDIST=8,



=480ms

range: 1-31

default: 8

Handover averaging window for distance handover, this parameter defines the size of the gliding averaging window for the timing advance measurements used for distance handover. This flag is only relevant if intercell handover due to distance is enabled (DISTHO=TRUE, see above). The distance between BTS and MS is determined from the ‘timing advance value’ which is continously measured by the BTS from the propagation time on the radio path.

All measurements for handover pass an averaging algorithm. The algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate the arithmetic average. The averaging window is called “gliding”, as the window works as a queue: when a new measurement is received, the oldest measurement is removed from the window. The parameter HOAVDIST defines the size of the gliding averaging window for the measured timing advance values. The size of the averaging window determines the number of measurement samples (a new measurement sample is received every 480 ms from the MEASUREMENT REPORTs from the BTS and the MS) over which the BTS calculates the arithmetic average. This calculated value is finally used in the distance handover decision process.

HOAVELEV=8-2, Handover averaging parameters for level handover, this




format: averaging period -



=480ms

(averaging period)





parameter defines the size of the gliding averaging window and the DTX weighting factor for the uplink and downlink RXLEV measurements for level handovers. It is only relevant if intercell handover due to level is enabled (RXLEVHO=TRUE, see below).


All measurements for handover pass an averaging algorithm. The algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate the arithmetic average. The averaging window is called “gliding”, as the window works as a queue: when a new measurement is received, the oldest measurement is removed from the window. The HOAVELEV “averaging period” defines the size of the gliding averaging window for the measured RXLEV values. The size of the averaging window determines the number of measurement samples (a new measurement sample is received every 480 ms from the MEASUREMENT REPORTs from the BTS and the MS) over which the BTS calculates the arithmetic average. This calculated value is finally used in the handover decision process.

The DTX weighting factor determines how much more the FULL values shall be weighted for radio measurement results measured over a period with voice activity (DTX not active).

Up to BR6.0, the higher weighting was implemented by the multiple insertion of the FULL measurement sample into the gliding averaging window. In other words, if the DTX weighting factor was set to “2”, FULL measurement samples from measurement periods with inactive DTX (speech transmitted) were inserted into the averaging window twice, while SUB measurement samples from measurement periods with active DTX (silence) were inserted into the averaging window only once (for further details about DTX and the meaning of FULL and SUB values please refer to the explanations provided for the parameter DTXDLFR).

Starting from BR7.0, this approach has been changed: FULL measurement samples values for non-DTX channels no longer entered n-times into the averaging window anymore but every value will be entered once. In addition, the current weighting factor is stored in parallel under the same offset as shown in the following picture:

Thus the time needed to fill the averaging window will always be the same (i.e. only dependent on the ‘laveraging period’ portion of the parameter HOAVELEV). The averaging window total is then calculated by adding up all sample values currently stored in the within 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 this reason only the SUB values (determined from the SACCH frames) are considered for the handover decision which are - as usual - inserted into the averaging window as single values only. - The size of the averaging window does not determine the minimum time the BTS needs to trigger a level handover at the very beginning of a call, as the BTS can trigger an level handover even if the averaging window is not yet completely filled with measurement samples. For each setting of the averaging window size there is a

0 4321 98765 3029

0 4321 00065 00sample

offset

length

max_av_win_size

1 2111 00012 00weight



fixed defined minimum number of measurement samples that are necessary for a handover decision.

Window size Minimum no. of Measurement samples 0 0 1 1

2 2 3-12 3 13-20 4 21-31 5

Thus, if this minimum number of measurement samples was received and their averaged value indicates the handover condition with respect to the configured handover thresholds, the level handover is triggered. - The averaging window size for the neighbour cell DL RXLEV measurements is determined by the parameter HOAVPWRB (see below).

HOAVPWRB=8,



=480ms

range: 1-31

default: 8


Handover averaging window for power budget handover, defines the size of the size of the averaging window for downlink RXLEV values of the serving cell (considering the current power reduction by the Power Control) for intercell handover due to Power Budget (PBGTHO=TRUE, see below) and intercell handover due to traffic (TRFHOE=TRUE, see below). Moreover, this averaging window is used for all types of intercell handovers (except for Fast Uplink Handover), as it is used for the averaging of the downlink RXLEV values of the neighbour cells.

All measurements for handover pass an averaging algorithm. The algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate the arithmetic average. The averaging window is called “gliding”, as the window works as a queue: when a new measurement is received, the oldest measurement is removed from the window. The parameter HOAVPWRB defines the size of the gliding averaging window for the measured RXLEV values. The size of the averaging window determines the number of measurement samples (a new measurement sample is received every 480 ms from the MEASUREMENT REPORTs from the BTS and the MS) over which the BTS calculates the arithmetic average. This calculated value is finally used in the handover decision process for handover due to power budget and handover due to traffic.

Note: The BTS uses the same averaging window size determined by HOAVPWRB also for the averaging of the neighbour cell DL RXLEV measurements for all other handover types (except Fast Uplink Handover). It is important, however, to point out that for the neighbour cell DL RXLEV measurements HOAVPWRB just determined the maximum window size for averaging. Basically the BTS averages the received DL RXLEV measurement values of each reported neighbour cell over as many samples as have been received from the MS. If the number of measurement samples for a particular neighbour cell have reached the value of HOAVPWRB, the further averaging is only done over as many samples as determined by HOAVPWRB.



HOAVQUAL=6-2,


format: averaging period -



=480ms

(averaging period)





Handover averaging parameters for quality handover, this parameter defines the averaging period and DTX weighting factor for the uplink and downlink RXQUAL measurements.


All measurements for handover pass an averaging algorithm. The algorithm can be described as a “gliding” averaging window: all measurement samples inside the window are used to calculate the arithmetic average. The averaging window is called “gliding”, as the window works as a queue: when a new measurement is received, the oldest measurement is removed from the window. The HOAVQUAL “averaging period” defines the size of the gliding averaging window for the measured RXQUALvalues. The size of the averaging window determines the number of measurement samples (a new measurement sample is received every 480 ms from the MEASUREMENT REPORTs from the BTS and the MS) over which the BTS calculates the arithmetic average. This calculated value is finally used in the quality handover decision process.

The DTX weighting factor determines how much more the FULL values shall be weighted for radio measurement results measured over a period with voice activity (DTX not active). The higher weighting is achieved by the multiple insertion of the measurement sample into the gliding averaging window. In other words, if the DTX weighting factor is set to “2”, FULL measurement samples from measurement periods with inactive DTX (speech transmitted) are inserted into the averaging window twice, while SUB measurement samples from measurement periods with active DTX (silence) are inserted 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 parameter PAVRLEV.

Notes: - In the SDCCH phase there are no TCH speech frames. For this reason only the SUB values (determined from the SACCH frames) are considered for the handover decision which are - as usual - inserted into the averaging window as single values only. - The size of the averaging window does not determine the minimum time the BTS needs to trigger a handover at the very beginning of a call, as the BTS can trigger an imperative handover even if the averaging window is not yet completely filled with measurement samples. For quality handovers, the averaging window is initialized with values RXQUAL=0. If the first samples have been inserted into the window, the BTS can trigger a quality handover, if the RXQUAL average exceeds the defined threshold, even if less samples have been received than places are foreseen in the averaging window. - The averaging window size for the neighbour cell DL RXLEV measurements is determined by the parameter HOAVPWRB (see below).



HOCCDIST=5,


unit: 1 km

range: 0..35

default: 5

Handover concentric cell distance limit; this parameter is only relevant if the parameter CCDIST is set to TRUE (see above) and if the concentric cell is no ‘dualband cell’ (i.e. a cell with mixed frequency bands in the TRXs)! It determines the distance limit used for the 'distance' intracell handover decision within the concentric cell and for the channel assignment decision during call setup. During the call setup procedure the BSC sends the PREFERRED AREA REQUEST message to the BTS to ask whether the TCH shall be assigned in the inner or complete area of the concentric cell. The BTS responds with a PREFERRED AREA message stating which area 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 in the inner area or, if the MS is already served by a TRX of the complete area, the call will be handed over to the inner area.

- If MS-BTS-distance > HOCCDIST+1 then new calls will be set up in the complete area or, if the MS is already served by a TRX of the inner area, the call will be handed over to the complete area. The hysteresis '+1' is automatically applied to avoid handover oscillation if the MS moves very close to the defined distance limit.

Please pay attention to the explanations for CCDIST (see above)!

HOLTHLVDL=10,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 10


Handover lower threshold level downlink, defines the receive signal level threshold on the downlink for inter-cell level handover decision. This parameter is only relevant if intercell handover due to level 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 uplink, 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 is enabled (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 quality AMR downlink, this parameter eclipses the threshold HOLTHQUDL in case of an AMR (Adaptive Multi Rate) call: For AMR calls, an intercell handover due to quality downlink is triggered if the downlink quality drops below the threshold determined by HOLTHQAMRDL. This parameter is only relevant if intercell handover due to quality is enabled (RXQUALHO=TRUE, see below). Attention: Unlike for the parameter HOLTHQUDL, for which the quality values are entered in RXQUAL values (range 0..7), the values for HOLTHQAMRDL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way: - Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (0..7) in the MEASUREMENT REPORT messages. - From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter HOAVQUAL. The resulting average RXQUAL value is calculated with a resolution of two places (digits) after the comma (this is achieved by multiplying the RXQUAL values with 100 before averaging). - The resulting ‘high-precision’ RXQUAL value is then mapped to an integer C/I value according to the following table:


6,88 ... 7 1 3,88 ... 4,12 12

6,63 ... 6,87 2 3,38 ... 3,87 13

6,38 ... 6,62 4 2,88 ... 3,37 14

6,13 ... 6,37 5 2,63 ... 2,87 15

5,88 ... 6,12 6 2,13 ... 2,62 16

5,63 ... 5,87 7 1,63 ... 2,12 17

5,13 ... 5,62 8 1,13 ... 1,62 18

4,88 ... 5,12 9 0,38 ... 1,12 19

4,63 ... 4,87 10 0 ... 0,37 20

4,13 ... 4,62 11


- The integer C/I value is then compared to the threshold determined by HOLTHQUAMRDL. If it drops below the threshold, the BTS triggers an intercell handover due to “downlink quality”.

Notes: - Although the total value range of HOLTHQUAMRDL is 0..30, the mapping limits the maximum useful C/I value to 20dB (see mapping table above). C/I threshold values above 20dB therefore can never be reached and will not show any effect. - In order to achieve a suitable accuracy of the RXQUAL average value 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 quality AMR uplink, this parameter eclipses the threshold HOLTHQUUL in case of an AMR (Adaptive Multi Rate) call: For AMR calls, an intercell handover due to quality is triggered if the quality drops below the threshold determined by HOLTHQAMRDL. This parameter is only relevant if intercell handover due to quality is enabled (RXQUALHO=TRUE, see below).

Attention: Unlike for the parameter HOLTHQUDL, for which the quality values are entered in RXQUAL values (range 0..7), the values for HOLTHQAMRDL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way: - Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (0..7) in the MEASUREMENT REPORT messages. - From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter HOAVQUAL. The resulting average RXQUAL value is calculated with a resolution of two places (digits) after the comma (this is achieved by multiplying the RXQUAL values with 100 before averaging). - The resulting ‘high-precision’ RXQUAL value is then mapped to an integer C/I value according to the mapping table included in the parameter description of HOLTHQAMRDL (see above). - The integer C/I value is then compared to the threshold determined by HOLTHQUAMRUL. If it drops below the threshold, the BTS triggers an intercell handover due to “uplink quality”.

Notes: - Although the total value range of HOLTHQUAMRDL is 0..30, the mapping limits the maximum useful C/I value to 20dB (see mapping table shown for HOLTHQAMRDL). C/I threshold values above 20dB therefore can never be reached and will not show any effect. - In order to achieve a suitable accuracy of the RXQUAL average value for AMR calls, it is recommended to use a minimum RXQUAL averaging window size of 4 (see parameter HOAVQUAL).

HOLTHQUDL=5,


range: 0..7

0 = less than 0,2%

1 = 0,2% to 0,4%

2 = 0,4% to 0,8%

3 = 0,8% to 1,6%

4 = 1,6% to 3,2%

5 = 3,2% to 6,4%

6 = 6,4% to 12,8%


default: 5


Handover lower threshold quality downlink, defines the receive signal quality threshold on the downlink for inter-cell quality handover decision. This parameter is only relevant if intercell handover due to quality 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 quality uplink, defines the receive signal quality threshold on the uplink for inter-cell quality handover decision. This parameter is only relevant if intercell handover due to quality 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 timing advance, this parameter specifies the timing advance margin for the extended cell handover (see parameter EXTCHO). It is applied to the MS-BTS distance threshold for the maximum MS distance (see parameter HOMSTAM) in the following 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-HOMRGTA

HOMSTAM=32,


unit: 1km

range: 0..34

default: 32

Threshold for the maximum MS distance, this parameter is only relevant for extended cells (see parameter CELLTYPE in command CREATE/SET BTS [BASICS]). It specifies the maximum allowed MS-BTS distance for the use of a 'not extended' radio channel (i.e. a ‘single’ TCH, see parameter EXTMODE (CREATE CHAN)). If the MS-BTS distance determined during call setup is below this threshold the call is set up on a 'single' timeslot - if it is above the threshold the call is set up on a 'extended' TCH (also called ‘double’ timeslot).

The threshold HOMSTAM is also used for intracell handover decisions for extended cell handovers (see parameter EXTCHO in command SET HAND [BASICS]) between the areas (far-to-near or near-to-far handovers). To avoid ping-pong handovers an additional margin (parameter HOMRGTA, see above) is applied to this threshold.

Rule: HOMSTAM < HOTMSRME (HAND) < EXCDIST (BTS [options])

HORXLVDLI=22,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 26

RXLEV threshold downlink inner, this parameter defines the downlink receive level threshold in the inner area of a concentric cell (see parameter CCELL in command CREATE BTS [BASICS]). Its transition causes an intracell handover from the inner area the complete 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 on the distance criteria defined by the parameter HOCCDIST (see parameters CCDIST and HOCCDIST).

Rules: for configuration rules for concentric cells and dualband concentric cells please refer to the parameter description of HORXLVDLO (see below).

HORXLVDLO=42,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

RXLEV threshold downlink outer, this parameter defines the downlink receive level threshold in the complete area of a concentric cell (see parameter CCELL in command CREATE BTS [BASICS]). Its transition causes a call setup in the inner area or an intracell handover from the complete area to the inner area.

Call Setup: During the call setup procedure the BSC sends the PREFERRED AREA REQUEST message to the BTS to ask whether



62 = -48dBm


default: 32

the TCH shall be assigned in the inner or complete area of the concentric cell. The BTS responds with a PREFERRED AREA message stating which area is preferred. The decision is made on the 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 complete area, the MS will be handed over to the inner area TRX if the condition

RXLEV_DL > HORXLVDLO

is fulfilled. Optionally, the handover decision can also be based on the distance criteria defined by the parameter HOCCDIST (see parameters CCDIST and HOCCDIST).

Special Case: If in the cell the feature “Common BCCH for GSM 900/1800 or 850/1900 Dual Band Operation” is used, the call setup and intracell handover decision considers the difference in the maximum allowed transmission power (derived from the parameters MSTXPMAXGSM, MSTXPMAXDCS and MSTXPMAXPCS, see CREATE BTS [BASICS]) and the MS power capability in the band used for the inner area.

This means that a call is set up in the inner area, if the condition

RXLEV_DL > HORXLVDLO + Max[0, (MS_TXPWR_MAXINN - PINN)]

is fulfilled. The decision for an complete-to-inner intracell handover is based on exactly the same calculation, i.e. a complete-to-innet handover is triggered if the condition

RXLEV_DLCOMPL > HORXLVDLO + Max[0, (MS_TXPWR_MAXINN - PINN)]

is fulfilled.

Rules: - To avoid 'ping pong' handovers between inner and complete area the following rule should be followed:

HORXLVDLO - HORXLVDLI > (PWRREDinner - PWRREDcomplete) + HOM [dB]

where

HOM = margin to avoid ping-pong HO due to fading, suggested value = default value of parameter HOM (ADJC object)

This rule is relevant for single-band concentric cells, as in such configurations the coverage difference between inner and complete area is controlled by the PWRRED parameter (see command CREATE TRX). The additional margin must be applied as a kind of ‘hysteresis’ which avoids ping-pong handovers due to fading effects, i.e. handovers that might occur due to normal level variations even when the subscriber remains in a stationary position on the border between inner and complete area. It is not necessary to use the default value of HOM (power budget handover margin, see command SET ADJC) for this calculation, but it makes sense to assume the HOM default value as a suitable default setting.

- If in the cell the feature “Common BCCH for GSM 900/1800 or GSM850/1900 Dual Band Operation” (dualband cell) is used, the coverage difference is not determined by different values of static power reduction of the TRXs but by the different transmission power values of the used CU resp. PA modules and the different propagation attenuation in different frequency bands. In this case the rule should be expressed as follows:

HORXLVDLO - HORXLVDLI > BS_TXPWR_MAXCOMPL - BS_TXPWR_MAXINN

+ HOM + PLD [dB]

where

BS_TXPWR_MAXCOMPL = Maximum BS transmission power of complete area TRX at the antenna output

BS_TXPWR_MAXINN = Maximum BS transmission power of inner area



TRX at the antenna output

HOM = margin to avoid ping-pong HO due to fading, suggested value = default value of parameter HOM (ADJC object)

PLD = Path Loss Difference

The additional margin must be applied as a kind of ‘hysteresis’ which avoids ping-pong handovers due to fading effects, i.e. handovers that might occur due to normal level variations even when the subscriber remains in a stationary position on the border between inner and complete area. It is not necessary to use the default value of HOM (power budget handover margin, see command SET ADJC) for this calculation, but it makes sense to assume the HOM default value as a suitable default setting. The Path Loss Difference (PLD) is the difference in the radio propagation attenuation between the different used frequency bands (e.g. GSM900 and DCS1800). This value must be known to the operator from live network measurements.

For dualband cells, the rule of thumb

HORXLVDLO - HORXLVDLI >= 20dB

has turned out to work fine without any ping-pong effects between inner and complete area.

Note: The intracell handover causes “complete to inner” and inner to complete” do not exist for SDCCH-SDCCH handover as in a Concentric Cell all SDCCHs are always configured in the complete area. 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 downlink intra, this parameter defines the receive signal level threshold in the downlink for the quality intra-cell handover decision. It is only relevant if intracell handover due to quality is enabled (INTRACH=TRUE, see below). The actual threshold value in [dBm] is calculated as follows: Handover Threshold [dBm] = -110dBm + HOTDLINT .


UPTLEVD > HOTDLINT


HOTHAMRCDL=23,


unit: 1 dB

range: 0...30

default: 23

Handover threshold AMR compression downlink, this parameter represents the downlink quality threshold used to trigger an intracell AMR Compression Handover "fullrate to halfrate”.

From BR7.0 on the AMR compression and decompression handover decision can be based on both quality and level conditions. The exact conditions for the initiation of an AMR compression and decompression handover as well as references to the quality related parameters are contained in the description for the parameter EADVCMPDCMHO (see above).

Important: In contrast to the AMR decompression handover (see parameter HOTHAMRDDL), the AMR compression handover (AMR fullrate to AMR halfrate) is triggered only if both the thresholds for UL quality and DL quality (HOTHAMRCDL and HOTHAMRCUL, see below) are exceeded.

Attention: Like for other AMR quality handover parameters (such as HOLTHQAMRDL), the values for HOLTHQAMRDL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way: - Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (0..7) in the MEASUREMENT REPORT messages. - From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter HOAVQUAL. The resulting average RXQUAL value is calculated with a resolution of two places (digits) after the comma (this is achieved by multiplying the RXQUAL values with 100 before averaging). - The resulting ‘high-precision’ RXQUAL value is then mapped to an integer C/I value according to the table included in the parameter description of HOLTHQAMRDL (see above). - The integer C/I value is then compared to the threshold determined by HOTHAMRCDL. If it exceeds the threshold (and HOTHAMRCUL is 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 mapping table shown for HOLTHQAMRDL). C/I threshold values above 20dB therefore can never be reached and will not show any effect. - In order to achieve a suitable accuracy of the RXQUAL average value for AMR calls, it is recommended to use a minimum RXQUAL averaging window size of 4 (see parameter HOAVQUAL).



HOTHAMRCUL=23,


unit: 1 dB

range: 0...30

default: 23

Handover threshold AMR compression uplink, this parameter represents the uplink quality threshold used to trigger an intracell AMR Compression Handover "fullrate to halfrate”.


Important: In contrast to the AMR decompression handover (see parameter HOTHAMRDDL), the AMR compression handover (AMR fullrate to AMR halfrate) is triggered only if both the thresholds for UL

quality and DL quality (HOTHAMRCDL and HOTHAMRCUL) are exceeded.

For further important details please refer to the description of HOTHAMRCUL (see above)!

HOTHAMRDDL=10,


unit: 1 dB

range: 0...30

default: 23

Handover threshold AMR decompression downlink, this parameter represents the downlink quality threshold used to trigger an intracell AMR Decompression Handover "halfrate to fullrate".


Important: In contrast to the intracell AMR compression handover (see parameter HOTHAMRCDL), the Intracell AMR decompression handover "halfrate to fullrate" is triggered if either the UL quality drops below the threshold HOTHAMRDDL or the DL quality drops below the threshold HOTHAMRDUL.

Attention: Like for other AMR quality handover parameters (such as HOLTHQAMRDL), the values for HOLTHQAMRDL are entered in C/I values (carrier/interference in [dB]). The BTSE-internal processing of these values is done in the following way: - Like any other MS, the AMR mobile reports the downlink quality values of the serving cell in form of the RXQUAL values (0..7) in the MEASUREMENT REPORT messages. - From the received RXQUAL values the BTS builds the arithmetic mean in accordance with the averaging parameters determined by the parameter HOAVQUAL. The resulting average RXQUAL value is calculated with a resolution of two places (digits) after the comma (this is achieved by multiplying the RXQUAL values with 100 before averaging). - The resulting ‘high-precision’ RXQUAL value is then mapped to an integer C/I value according to the table included in the parameter description of HOLTHQAMRDL (see above). - The integer C/I value is then compared to the threshold determined by HOTHAMRDDL. If it drops below the threshold HOTHAMRDDL, the BTS triggers an intracell handover due to AMR decompression.

Notes: - Although the total value range of HOTHAMRCDL is 0..30, the mapping limits the maximum useful C/I value to 20dB (see mapping table shown for HOLTHQAMRDL). C/I threshold values above 20dB therefore can never be reached and will not show any effect. - In order to achieve a suitable accuracy of the RXQUAL average value for AMR calls, it is recommended to use a minimum RXQUAL averaging window size of 4 (see parameter HOAVQUAL).



HOTHAMRDUL=10,


unit: 1 dB

range: 0...30

default: 23

Handover threshold AMR decompression uplink, this parameter represents the uplink quality threshold used to trigger an intracell AMR Decompression Handover "halfrate to fullrate".


Important: In contrast to the intracell AMR compression handover, the Intracell AMR decompression handover "halfrate to fullrate" is triggered if either the UL quality drops below the threshold HOTHAMRDDL or the DL quality drops below the threshold HOTHAMRDUL.

For further important details please refer to the description of HOTHAMRDDL (see above)!

HOTHCMPLVDL=<NULL>,


unit: 1 dB

range: 0...63

default: <NULL>

initial value: 40 (-70dBm)

Handover threshold for compression downlink, this parameter is only relevant if the feature ‘advanced AMR compression / decompression handover’ (parameter EADVCMPDCMHO, see above) is enabled and defines the compression threshold for the DL receive level; i.e. in order for a compression from FR to HR to be triggered the condition

DL_RXLEV > HOTHCMPLVDL

must be fulfilled (as well as the respective condition for the UL and the quality conditions).

Please note that From BR7.0 on the AMR compression and decompression handover decision can be based on both quality and level conditions. The exact conditions for the initiation of an AMR compression and decompression handover as well as references to the quality related parameters are contained in the description for the parameter EADVCMPDCMHO (see above).

HOTHCMPLVUL=<NULL>,


unit: 1 dB

range: 0...63

default: <NULL>

initial value: 40 (-70dBm)

Handover threshold for compression uplink, this parameter is only relevant if the feature ‘advanced AMR compression / decompression handover’ (parameter EADVCMPDCMHO, see above) is enabled and defines the compression threshold for the UL receive level; i.e. in order for a compression from FR to HR to be triggered the condition

UL_RXLEV > HOTHCMPLVUL

must be fulfilled (as well as the respective condition for the DL and the quality conditions).




HOTHDCMLVDL=<NULL>,


unit: 1 dB

range: 0...63

default: <NULL>

initial value: 26 (-84Bm)

Handover threshold for decompression downlink, this parameter is only relevant if the feature ‘advanced AMR compression / decompression handover’ (parameter EADVCMPDCMHO, see above) is enabled and defines the decompression threshold for the DL level; i.e. in order for a decompression from HR to FR to be triggered the condition

DL_RXLEV < HOTHDCMLVDL

must be fulfilled (independent from the respective UL or quality conditions).


HOTHDCMLVUL=<NULL>,


unit: 1 dB

range: 0...63

default: <NULL>

initial value: 26 (-84Bm)

Handover threshold for decompression uplink, this parameter is only relevant if the feature ‘advanced AMR compression / decompression handover’ (parameter EADVCMPDCMHO, see above) is enabled and defines the decompression threshold for the UL level; i.e. in order for a decompression from HR to FR to be triggered the condition

UL_RXLEV < HOTHDCMLVUL

must be fulfilled (independent from the respective DL or quality conditions).


HOTMSRM=34,


unit: 1km

range: 0..35

default: 34


Handover threshold MS range maximum, defines the threshold for the maximum permitted distance between MS and the BTS in 1km step 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 distance between MS and BTS from the delay of the RACH burst (which is used for the CHANNEL REQUEST and the HANDOVER ACCESS) and the the delay of the normal bursts. If the determined distance exceeds the entered threshold value an inter-cell handover with cause ‘distance’ is initiated. In case of an extended channel (double timeslot of an extended cell, see CELLTYPE=EXTCELL in CREATE BTS [BASICS]) the handover threshold MS range maximum is determined by the parameter HOTMSRME (HAND).

Rule: HOTMSRM (HAND) < EXCDIST (BTS [OPTIONS])

HOTMSRME=99,


unit: 1km

range: 35-100

default: 99

Handover threshold MS range maximum extended, this parameter replaces the parameter HOTMSRM (see above) in case of an extended channel (double timeslot of an extended cell, see CELLTYPE=EXTCELL in CREATE BTS [BASICS]). It is only relevant if distance handover is enabled (DISTHO=TRUE, see above) and specifies the handover threshold range maximum that is used for intercell handover due to distance in extended cells. If the BS-BTS distance exceeds this threshold an inter-cell handover due to distance 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 uplink intra, this parameter defines the receive signal level threshold in the uplink for the quality intra-cell handover decision. It is only relevant if intracell handover due to quality is enabled (INTRACH=TRUE, see below) and defines the receive signal level threshold on the uplink for intra-cell handover decision. The actual threshold value in [dBm] is calculated as follows: Handover Threshold [dBm] = -110dBm + HOTULINT .


UPTLEVU > HOTULINT


IERCHOSDCCH=FALSE,


range: TRUE, FALSE

default: FALSE

Inter-cell handover for SDCCH, this parameter determines whether inter-cell SDCCH-SDCCH handover is enabled or not.

Notes: - Setting this parameter to ‘enable’ only activates the SDCCH-SDCCH handover controlled by the BSC, i.e. SDCCH-SDCCH handover to target cells belonging to the same BSC. If Inter-BSC Directed Retry shall be enabled the flag EISDCCHHO (see SET BSC [BASICS]) has to be set to ENABLE in addition. - Only if this parameter is set to TRUE, the settings of the flags RXQUALHO, RXLEVHO, DISTHO, PBGTHO, ININHO and EFULHO are considered for SDCCH handover. These flags determine which kinds of SDCCH-SDCCH inter-cell Handover are actually allowed.



ININHO=FALSE,


range: TRUE, FALSE

default: FALSE

Inner-inner handover, this flag determines whether an intercell handover from inner to inner area in sectorized concentric cells is enabled. 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 incoming handover to a concentric cell is always executed to a TCH belonging to the complete area, even if the level and distance conditions allow an assignment of a TCH belonging to the inner area of the target cell. In this case the inter-cell handover to the complete area of the target cell is directly followed by a complete-to-inner intracell handover within the target cell. If ININHO is set to TRUE these unnecessary handovers are avoided between colocated concentric cells as described below. Which cells are to be considered as 'colocated' (i.e. for which neighbour cells the ININHO flag will be in effect) is determined by the parameters CCELL1 and CCELL2 (see above).

Principle: If the BTS triggers an inter-cell handover out of a concentric cell towards a target cell which the BSC recognizes as 'colocated' (see parameters CCELL1 and CCELL2), the BSC sends a PREFERRED AREA REQUEST message to the originating BTS which contains the level thresholds HORXLVDLI and HORXLVDLO of the affected neighbour cell. Based on these thresholds and the measured RXLEV value of the neighbour cell the BTS answers with a PREFERRED AREA message which suggests either a 'complete' area TCH or an 'inner' area TCH. If the BTS suggests an inner area TCH in the PREFERRED AREA message, the BSC directly activates the target TCH on an inner area TRX and sends the corresponding TCH info to the MS in the HANDOVER COMMAND.

In fact, when ININHO is set to TRUE, not only inner-to-inner handovers are possible, but also handovers from the complete area in the originating sector to the inner area of the target sector. The enabling of the flag ININHO simply activates the PREFERRED AREA REQUEST procedure (towards the originating cell) for all intercell handovers for the neighbour cell relations defined by CCELL1 and CCELL2. Even if the call is currently served by a complete area TRX in the serving cell, the BSC will start the PREFERRED AREA REQUEST procedure towards the originating cell when an intercell handover is triggered. If the return message PREFERRED AREA message suggests the inner area, the handover is performed to a corresponding inner area TRX in the target cell.

complete area

inner area inner-to-inner

sector 2 (colocated cell 1)

sector 3 (colocated cell 2)

sector 1 (own cell)



INTERCH=TRUE,


range: TRUE, FALSE

default: TRUE

Internal inter-cell Handover enabled, determines whether inter-cell handovers for TCH (i.e. HOs starting from a TCH) are generally allowed for this BTS. Notes: - Only if this parameter is set to TRUE, the settings of the flags RXQUALHO, RXLEVHO, DISTHO, PBGTHO, ININHO, EFULHO and TRFHOE considered for TCH handover. These flags determine which kinds of TCH-TCH inter-cell Handover are actually allowed. - If an extended cell (CREATE BTS [BASICS]:CELLTYPE=EXTCELL) is the target of an inter-cell HO the handover will always take place to a 'double' timeslot first as the BTS can only determine the actual MS-BTS distance when the first MS messages are received. If the MS-BTS distance turns out to be short enough for a 'single' timeslot an intra-cell handover from far to near ('double-to-single') is executed immediately (if enabled).

INTRACH=TRUE,


range: TRUE, FALSE

default: TRUE

Internal intra-cell Handover enabled, determines whether intra-cell handovers due to quality shall be allowed this BTS. If this is the case, under defined quality and level conditions (see section handover algorithms) the handover algorithm always executes intra-cell ‘quality’ handovers before Inter-cell ‘quality’ handovers are attempted. These Intra-cell handovers are independent of the status of RXQUALHO, which only refers to inter-cell handovers. If INTRACH is set to FALSE the quality conditions which normally cause an intra-cell ‘quality’ handover in the first place directly lead to an inter-cell ‘quality’ handover (provided that RXQUALHO is set to TRUE). Further parameters relevant for this type of handover are HOAVQUAL, HOTDLINT and HOTULINT. Notes: - The intracell handover selects the available TCHs cyclically or based on the idle TCH measurements (if SET BTS [INTERF]: INTCLASS=TRUE;) in the scope of the intra-cell HO limitation functions set (see parameter ELIMITCH). - In a concentric cell (CREATE BTS [BASICS]:CONCELL=TRUE) the intracell handover (quality) may only take place within the complete area or within the inner area! - In an extended cell the intra-cell handover due to quality may only take place from double to double ts or from single to single ts (exception: if no single TCH is available, a double one is selected). - For HSCSD calls the intracell HO due to quality is not performed, irrespective of the status of the INTRACH flag. In case of bad quality, HSCSD calls might be downgraded from 14,4 kbit/s to 9,6kbit/s (see parameters in command SET HAND [DATA]). - To avoid a ping-pong handover from HR to FR and vice versa, which can occur due to subsequent execution of (AMR) decompression handover (parameter EADVCMPDCMHO, see above) and intracell handover due to quality (for a call whose quality is still poor after decompression handover), the features ‘Cell load dependent actvation of half rate’ (see parameter EHRACT in command CREATE BTS [BASICS]) and ‘Abis load dependent activation of half rate’ (see parameter ABISHRACTTHR in command CREATE BTSM) are not considered if the BSC receives an INTRACELL HANDOVER CONDITION INDICATION due to quality reasons (cause values ‘uplink quality’ or ‘downlink quality’). This means that the BSC does not check the current BTS TCH load and the BTSM Abis pool TCH load in case of an intracell handover due to quality.



IRACHOSDCCH=FALSE,


range: TRUE, FALSE

default: FALSE

Intra-cell handover for SDCCH, this parameter determines whether intra-cell handover due to quality is enabled for SDCCH-SDCCH-handovers or not.

LOTERCH=TRUE,


range: TRUE, FALSE

default: TRUE

Local inter-cell Handover enabled, determines whether inter-cell handover is controlled by the BSC (TRUE) or MSC (FALSE). If the flag is set to FALSE, and the BSC receives an INTERCELL HANDOVER CONDITION INDICATION (BWHCI) from the BTS, the BSC forwards the handover responsibility to the MSC by sending a HANDOVER REQUIRED to the MSC, even if the first target cell in the target cell list of the BWHCI is an internal one. Notes: - This flag is valid both for TCH-TCH handover and SDCCH-SDCCH handover! - The setting of this parameter has an impact on performance measurement: It must be set to TRUE to ensure the correct working of specific counters related to inter-cell handover (ATINHIRC, SINTHINT).

LOTRACH=TRUE,


range: TRUE, FALSE

default: TRUE

Local intra-cell Handover enabled, determines whether intra-cell handover is controlled by the BSC (TRUE) or MSC (FALSE). If the flag is set to FALSE, and the BSC receives an INTRACELL HANDOVER CONDITION INDICATION (WIHCI) from the BTS, the BSC forwards the handover responsibility to the MSC by sending a HANDOVER REQUIRED to the MSC, indicating the serving cell as the only target cell. Notes: - This flag is valid both for TCH handover and SDCCH-SDCCH handover. - If the BTS is a concentric cell (CREATE BTS [BASICS]: CONCELL=TRUE) or an extended cell (CREATE BTS [BASICS]: CELLTYPE=EXTCELL) the setting of LOTRACH is ignored. Intracell handover (quality) is in this case always BSC-controlled! - If LOTRACH is set to FALSE the BSC automatically adds the serving 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 be set to TRUE!

MAIRACHO=2,


range: 1-15

default: 2

Maximum number of intra-cell handovers, this parameter is only considered if the flag ELIMITCH (see above) is set to TRUE. It determines the maximum number of consecutive successful intracell handovers due to quality (see parameter INTRACH in command SET HAND [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 single connection.

In the BSC, separate two counters are managed, one for intracell quality handovers and one for AMR compression handovers. MAIRACHO determines the threshold value for both counters

Note: Due to the feature implementation actually the maximum allowed number of consecutive successful intra-cell handovers is MAIRACHO+1.



MAXFAILHO=2,


range: 1-15

default: 2

Maximum number of failed handovers, this parameter is only relevant if the parameter NOFREPHO is set to TRUE and determines the maximum number of consecutive failures of intra BSC handovers that are permitted in the same BTS for a single connection.

NCELL=6,


range: 0..15

default: 6


(for HANDOVER

REQUIRED)

Number of preferred cells, defines the number of preferred cells in the HANDOVER CONDITION INDICATION message. This message is a result of the handover measurement pre-processing function in the BTS and is sent periodically from the BTS towards the BSC (see parameter THORQST). The handover measurement pre-processing function evaluates the measurement reports received from the MS in order to determine whether a handover is necessary and - if yes - which neighbour cells are suitable target cells. These cells are then inserted into the target cell list of the HCI. If the BSC does not execute the handover itself it sends the message HANDOVER REQUIRED towards the MSC.

NOBAKHO=TRUE,


range: TRUE, FALSE

default: TRUE

No back handover, this flag determines whether the feature 'Prevention of Back handovers' is enabled or not. It enables a mechanism that prevents a back-handovers due to power budget if the TCH in the serving cell was seized by an imperative handover procedure (handover due to level, quality or distance). If the flag NOBAKHO is set to TRUE the back-handovers are prevented by the following mechanism: if an imperative handover (to a cell for which NOBAKHO=TRUE) is performed the BSC extends the CHANNEL ACTIVATION message for the 'new' TCH in the target cell by the IE 'Cell List Preferred' which contains the CGI of the handover origin cell and by a GSM 08.08 cause IE with the cause 'distance'. This message makes the BTS suppress the handover origin cell in all following INTERCELL HANDOVER CONDITION INDICATION messages sent with the cause 'better cell' for an administrable time period (see parameter TINHBAKHO (CREATE ADJC)).

Note: The flag NOBAKHO is relevant for the handover target cell, i.e. the CHAN ACT message is extended by the above mentioned IEs if the BSC detects that for the handover target cell the flag NOBAKHO is 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 handover failures repetition, this flag determines whether the feature 'Prevention of handover failures repetition' is enabled or not. It enables a mechanism which prevents unlimited handover repetitions to a target cells if previously handovers to this cell have not been successful. A handover is regarded as unsuccessful if the MS returns to the old channel with a HANDOVER FAILURE message or if in case of an external handover the timer T7 expires (e.g. due to receipt of a HANDOVER REQUIRED REJECT message). If the flag NOFREPHO is set to TRUE every unsuccessful handover leads to the increase of a counter in the BSC. If this counter reaches an administrable threshold (see parameter MAXFAILHO) the BSC sends a HANDOVER FAILURE INDICATION message to the BTS which contains the CGI of the target cell to which the handover attempts failed. As a result, the BTS excludes the affected cell from the target cell list of the HANDOVER CONDITION INDICATION messages for an administrable period of time (see parameter TINHFAIHO (CREATE ADJC)).



PBGTHO=TRUE,


range: TRUE, FALSE

default: TRUE


Power budget handover enabled, determines whether handover due to power budget is enabled. This flag is only relevant if intercell handover is enabled in the cell (INTERCH=TRUE, see above). Power budget handover means: handover to another cell if this cell offers a higher transmission level (irrespective of whether the power level of the actual cell is above the minimum - see RXLEVHO - or not.). Further parameters relevant for this type of handover are HOAVPWRB (HAND object, see above) and HOM (ADJC object). Note: this flag only determines whether inter-cell handovers may be executed with cause ‘better cell’.

PL=0,


range: 0..15

default: 0

Priority layer, if hierarchical cell handover is enabled (HIERC=TRUE) this parameter determines the priority layer of the own cell. This priority is only evaluated for the Power Budget handover decision and the traffic handover decision (see parameter TRFKPRI). The priority layers of the neighbour cells are administered in the ADJC object (see ADJC object).

RXLEVHO=TRUE,


range: TRUE, FALSE

default: TRUE


RxLevel handover enabled, determines whether handover due to low receive level on uplink or downlink is enabled. This flag is only relevant if intercell handover is enabled in the cell (INTERCH=TRUE, see above). If the receive level is below the minimum threshold handover is necessary. Further parameters relevant for this type of handover are HOAVELEV, HOLTHLVDL and HOLTHLVUL (see above). Note: this flag only determines whether inter-cell handovers may be executed with cause ‘level’.

RXQUALHO=TRUE,


range: TRUE, FALSE

default: TRUE


RxQual handover enabled, determines whether handover due to bad receive quality on uplink or downlink is enabled. This flag is only relevant if intercell handover is enabled in the cell (INTERCH=TRUE, see above). Bad receive Quality is determined by error rate measurements in the MS and the BTS. Further parameters relevant for this type of handover are HOAVQUAL, HOLTHQUDL and HOLTHLQUUL, HOLTHQAMRDL and HOLTHQAMRUL (see above). Note: this flag only determines whether inter-cell handovers may be executed with cause ‘quality’.



SG1HOPAR=<NULL>,


range: <NULL>,

8 fields with ranges in



represent.

default: <NULL>

Service group 1 handover parameters, this parameter is the first of the 14 parameters which allows a service group-dependent setting of handover parameters and thresholds.

The setting <NULL> indicates that for this service group no specific parameter settings are applied and the handover decision for this service group is based the ordinary HAND parameter settings.

Fo further details please refer to the section “Service dependent Handover and Power Control in the appendix of this document.

SG2HOPAR...SG14HOPAR=<NULL>,


range: <NULL>,

n fields with ranges in



represent.

default: <NULL>

Service group 2..14 handover parameters, these parameters represent 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 no specific parameter settings are applied and the handover decision for this service group is based the ordinary HAND parameter settings.


THLEVFULHO=8,


unit: 1 dB

range: 0..63


1 = -110dBm

2 = -109dBm

...

62 = -48dBm


default: 8

Level threshold for fast uplink handover, this parameters defines the uplink receive signal strength threshold for an inter-cell fast uplink handover (see parameter EFULHO). If the UL RXLEV drops below the level defined by THLEVFULHO, the BTS triggers a fast uplink handover.




THORQST=5,



range: 0..31

default: 5


Timer for handover request defines the minimum interval between HANDOVER CONDITION INDICATION messages (see parameter NCELL) related to the same connection. If the BSC cannot execute the handover itself it sends a HANDOVER REQUIRED message towards the MSC. Like the HCI the HANDOVER REQUIRED message also contains a target cell list and a handover cause (e.g. ‘uplink quality’, ‘better cell’ etc.) and is repeated under consideration of the timer T7 (see SET BSC SET BSC [TIMER], parameter BSCT7).

Recommendation:

THORQST (HAND) > T7 (SET BSC [TIMER])

Note: If THORQST is set to 0 then the HCI is repeated after every SACCH multiframe, i.e. every 480ms. If the call remains on the same TCH this might lead to a 'toggling' of inter- and intra-cell HCIs.

TINOIERCHO=60,


unit: 1s

range: 1-254

default: 60

Timer for 'no intra-cell handover', this parameter is only considered if the flag ELIMITCH (see SET HAND [BASICS]) is set to TRUE. It specifies the timer used by the BTS to indicate how long a) quality intra-cell handover (see parameter INTRACH in command SET HAND [BASICS]) or b) AMR compression handover (see parameter EADVCMPDCMHO in command SET HAND [BASICS]) shall be prevented for a specific connection in the cell if MAIRACHO+1 successful handovers of that particular types have taken place before. The timer is started in the BTS on receipt of the adapted CHANNEL ACTIVATION message which contains an additional GSM 08.08. cause 'handover successful'. The only event that can stop this timer is the release of the call context (e.g. call release or inter-cell handover).

THORQST purpose: Minimum time between two HO_COND_IND messages related to the same connection start: sending of HO_COND_IND message by the BTS stop: - 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

Traffic handover high threshold, this parameter specifies the cell traffic load that leads to the enabling of traffic handover in the BTS. The traffic load of a cell is calculated as follows:


- (*) 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 BSC cyclically checks the traffic load (controlled by the timer TRFCT, see SET BSC) in all cells in which traffic handover is enabled (see parameter TRFHOE) and compares it to the threshold specified by TRFHITH. If the traffic load in the cell is above the cell-specific threshold TRFHITH, the BSC enables the traffic handover in the affected BTS by sending an LAPD O&M message SET ATTRIBUTE with the appropriate contents to the BTSM. This O&M message is the trigger for the BTS to start the traffic handover decision algorithm (for more details concerning the handover decision please refer to the appendix ‚Handover Thresholds and Algorithms’). If the traffic handover was already enabled for a specific BTS on the previous expiry of TRFCT and the traffic load in the affected BTS is still above the threshold TRFHITH, no further message is sent to the BTS and the traffic handover remains enabled in the affected BTS. If the traffic handover was enabled for a specific BTS on the previous expiry of TRFCT and the traffic load in the affected BTS has decreased below the threshold TRFHITH, the BSC disables the traffic handover in the affected BTS by sending another LAPD O&M message SET ATTRIBUTE with the appropriate contents to the BTSM.





TRFHOE=TRUE,


range: TRUE, FALSE

default: FALSE

Traffic handover enabled, this parameter enables the feature ‘Handover due to BSS resource management criteria’ or shortly called ‘traffic handover’. If this flag is enabled, the BSC cyclically checks the traffic load situation of this cell. If the traffic load exceeds the threshold TRFHITH, the BSC enables the traffic handover in the BTS by sending SET ATTRIBUTE message with the ‘traffic handover enabled’ indication to the BTS via the LPDLM link. As a result, the BTS starts its handover decision process in such a way that it continuously evaluates the DL MEASUREMENT REPORTS for suitable neighbour cells for traffic handover. Similar to the power budget handover decision process the traffic handover decision process monitors the level difference between the serving cell and the neighbour cells and compares it to an administrable handover margin (traffic handover margin, see explanations for TRFHOT): when the power budget exceeds the traffic handover margin, a handover due to traffic is initiated by sending a corresponding INTERCELL HANDOVER CONDITION INDICATION with the proprietary cause ‘traffic’. Differences to the normal power budget handover decision consist in the following aspects a) While the power budget handover decision process is continuously running in the BTS if the database flag PBGTHO is set to TRUE, the traffic handover decision process only runs in those time periods where the traffic handover was explicitly enabled by the mentioned SATT message from the BSC before. b) While the power budget handover margin has a static value, the traffic handover margin is dynamically changed (reduced or increased) by a timer-controlled step-by-step reduction mechanism (see TRFHOT).

When the BSC receives the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with the proprietary cause ‘traffic’, it checks the current TCH load of the target cells indicated in the BWHCI. Only if the current TCH load of the suggested target cell is lower than a configurable threshold (see TRFLTH), the handover to this target cell is actually executed.

Traffic Handover can only take place within the BSC as - only for these cells the target cell traffic condition can be checked - the cause value ‘traffic’ is not defined for the A-interface signalling. This means that the

Parameters relevant for the control of the dynamic traffic handover margin and the target cell list generation performed in the BTS are TRFHOT, TRFHOM, TRFMS, TRFMMA and TRFKPRI (see HAND object) and BHFOT (see ADJC object). The parameter relevant for the measurement averaging is HOAVPWRB (see above).

Parameters relevant for the traffic handover tasks performed by the BSC (traffic load evaluation and traffic handover initiation) are TRFCT (see SET BSC) and the traffic load thresholds TRFHITH and TRFLTH (see HAND object).

Notes: - This parameter is only relevant if intercell handover is enabled in the cell (INTERCH=TRUE, see above). - Traffic handover towards a cell is always possible, irrespective of the TRFHOE flag (only TRFLTH is considered in this case). - In a Concentric Cell (see parameter CONCELL in command CREATE BTS [BASICS]), the BTS triggers Traffic Handover only for calls served by a complete area TRX. - In an Extended Cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS]) the BTS does not trigger any Traffic Handover at all.



TRFHOT=10,


unit: 1s

range: 2.. 20

default: 10

Traffic handover timer, this timer is used for the traffic handover decision (see TRFHOE) in the BTS and defines the cycle in which the BTS recalculates the dynamic traffic handover margin while traffic handover is enabled in the BTS. TRFHOT is started first in the BTS when the BTS has received the ‘traffic handover enabled’ message (SET ATT) from the BSC via the LPDLM link and has started its first handover decision phase. The SET ATT message is sent from BSC to BTS when the BSC has detected the exceeding of a traffic load threshold (see TRFHITH) on expiry of the traffic control timer (see TRFCT in command SET BSC [BASICS]).

On expiry of TRFHOT the traffic handover margin is recalculated in the following way: When the traffic handover is enabled due to receipt of the SET ATT message from the BSC, the BTS starts the first handover decision phase with an ‘initial’ traffic handover margin. When TRFHOT expires for the first time, the next traffic handover decision phase starts with a reduced traffic handover margin and TRFHOT is restarted (as long as TRFHOT runs, the traffic handover margin remains constant). In other words, specific adjacent cells, that were not included in the target cell list of the first INTERCELL HANDOVER CONDITION INDICATION (HCI), might appear in one of the subsequent HCIs (even if the level conditions do no change) due to the fact that the traffic handover margin has decreased. This traffic handover margin reduction process is continued accordingly on the next expiries of TRFHOT until the maximum allowed traffic handover margin reduction is reached. From this point of time on the traffic handover margin remains the same on every further expiry of TRFHOT.

When the BSC disables the traffic handover in the BTS by sending a SET ATTRIBUTE message with the ‘traffic handover disabled’ indication to the BTS, the BTS does not immediately stop its traffic handover decision process but recalculates the traffic handover margin again on the next expiry of TRFHOT – this time, however, the handover margin is increased. If the traffic handover remains disabled (i.e. no ‘traffic handover enabled’ indication received from the BSC), the dynamic traffic handover margin is increased step-by-step with every expiry of TRFHOT. When the initial traffic handover margin is reached, the decision process is stopped and no traffic handover is triggered anymore.

A reasonable setting of the BSC traffic control timer TRFCT (see SET BSC [BASICS]) and TRFHOT is

TRFHOT (HAND) > TRFCT (BSC)

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

Parameters relevant for the dynamic traffic handover margin reduction/increase mechanism are TRFHOM (ADJC object) and TRFMS and TRFMMA (HAND object). TRFHOM defines the basic traffic handover margin, TRFMS determines the reduction resp. increase step size of the traffic handover margin (compared to the previous handover decision phase) and TRFMMA defines the maximum allowed reduction of the traffic handover margin. The diagrams on the next page illustrate the dynamic traffic handover reduction/increase mechanism.

continuation see next page…



The following diagrams might illustrate the dynamic traffic handover

reduction/increase mechanism:

Note: This algorithm shows that the timer-controlled reduction of the traffic handover margin can - depending on the setting of the parameters TRFHOM, TRFMS and TRFMMA - lead to negative traffic handover margin values. Depending on the operator’s philosophy and the setting of the traffic load threshold TRFHITH, it might also make sense to use negative traffic handover margin values for TRFHOM from the beginning (the closer the threshold TRFHITH is to 100%, the more ‘aggressive’ (i.e. negative) the traffic handover margin setting should be). However, to avoid that in such cases the traffic handover is triggered for calls with poor level conditions in the serving cell and even worse level conditions are expected in the target cell, the minimum RXLEV condition for traffic handover target cells includes an additional level offset. In BR6.1 this offset is fixed to 6dB:

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + 6dB

For more details regarding the exact interworking of the mentioned

time

TRFHOT

first expiry of TRFHOT

Traffic HO enabled indication received from BSC

TRFHOT TRFHOT TRFHOT

second expiry of TRFHOT

Start of second traffic HO decision phase with reduced traffic HO margin Traffic HO Margin = TRFHOM - 2*TRFMS

Start of first traffic HO decision phase with Initial traffic HO margin Traffic HO Margin = TRFHOM - 1*TRFMS

third expiry of TRFHOT

If n*TRFMS has reached TRFMMA and traffic HO remains enabled, the traffic HO margin reduction remains stable (=TRFMMA) for all subsequent expiries of TRFHOT.

Start of third traffic HO decision phase with reduced traffic HO margin Traffic HO Margin = TRFHOM - 3*TRFMS

Principle of the traffic handover margin reduction mechanism when traffic

handover is enabled:

time

TRFHOT

expiry of TRFHOT

Traffic HO disabled indication received from BSC


expiry of TRFHOT

Traffic HO margin from the previous TRFHOT period is increased by TRFMS


expiry of TRFHOT

If the traffic HO remains disabled, and the traffic HO margin reaches the initial value TRFHOM – 1*TRFMS, the handover decision process is stopped on the next expiry 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

Traffic keep priority, this parameter determines which neighbour cells are allowed as target cells for traffic handover if the feature ‘hierarchical cell structure’ is enabled (parameter HIERC=TRUE). a) If TRFKPRI=TRUE, an adjacent cell may only be a traffic handover target cell if it has an equal priority level (see parameter PLNC in the ADJC object) like he serving cell (see parameter PL). b) If TRFKPRI=FALSE, an adjacent cell may be a traffic handover target cell if it has an equal or higher priority level like he serving cell.


TRFLTH=70,


unit: 1%

range: 0.. 85

default: 70

Traffic handover low threshold, this parameter specifies the maximum cell traffic load a BTS may have to accept incoming traffic handovers. The traffic load of a cell is calculated as follows:


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



When the BSC has enabled the traffic handover in a specific BTS (see TRFHITH) the BTS makes a traffic 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 traffic load of this target BTS is below the threshold TRFLTH. If the traffic load in the first target cell is above the threshold, the BSC checks the next target cell in the list and so on. If none of the target cells has a suitable load situation (i.e. if the cell traffic load > TRFLTH) the HCI does not lead to any handover and the next handover attempt HCI after expiry of TRFHOT (see below).





TRFMMA=9,


unit: 1dB

range: 1.. 48

default: 9

Traffic handover margin maximum reduction, this parameter specifies the maximum reduction of the traffic handover margin (see parameter TRFMS below). TRFMMA does not have to be an integer multiple of TRFMS but, of course, it makes sense to set the two parameters in this way. In any case, TRFMMA is never exceeded.

In fact, the maximum reduction of the traffic handover margin is the result 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

Traffic handover margin reduction step, this parameter specifies the minimum reduction and simultaneously the reduction step size of the dynamic traffic handover margin. The BTS uses the traffic handover margin for the target cell list generation after the traffic handover decision. Only those neighbour cells are included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (HCI) with cause ‘traffic’, for which the level difference between the serving and the neighbour cell exceeds the dynamic traffic handover margin. Whenever TRFHOT expires, the BTS recalculates the traffic handover margin for the next TRFHOT period. If traffic handover is enabled (i.e. the ‘traffic handover enabled’ indication was received from the BSC in a SET ATT message), the traffic handover margin is reduced by TRFMS in the next TRFHOT period; if traffic handover is disabled (i.e. the ‘traffic handover disabled’ indication was received from the BSC in a SET ATT message) the traffic handover margin is increased by TRFMS in the next TRFHOT period. Please see also the explanations provided for TRFHOT.

In fact, the basic traffic handover margin (TRFHOM, see ADJC object) is already reduced by TRFMS in the first traffic handover decision immediately after the receipt of the ‘traffic handover enabled’ indication. This means the ‘initial’ traffic handover margin after the enabling of traffic HO is TRFHOM-TRFMS. After the first expiry/restart of TRFHOT, the basic traffic handover margin TRFHOM is reduced by

2∗TRFMS for the duration of the next TRFHOT period and so on. However, the reduction of the traffic handover margin is not unlimited: the maximum reduction of the traffic handover margin is defined by the parameter TRFMMA (see above).

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 Relations Inter-cell handover

Inter-Cell Handover

Parameters relevant for all types of inter-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.

Quality 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 Cell 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 handover

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 control of inter-cell (TCH-TCH) handover

HAND: LOTERCH=TRUE → HO is BSC controlled ****

LOTERCH=FALSE → HO is MSC controlled ****

Traffic HO +

BSC: TRFCT

HAND: TRFHOE

=TRUE

TRFHITH

TRFLTH

TRFMS

TRFMMA

ADJC: TRFHOM

TRFHORXLV

MOFF

HCS

HAND: HIERC=

TRUE

PL

TRFKPRI

ADJC: PLNC

Prevention of back (PBGT) HO ***

HAND: NOBAKH=TRUE

ADJC: TINHBAKHO

Concentric Cells (sectorized)

BTS: CONCELL=TRUE

HAND: ININHO, CCELL

Prev. of Back HO

(PBGT and Traffic)***

ADJC: BHFOT



Intra-cell handover

Intra-Cell Handover

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

Concentric 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 control of intra-cell handover (quality)

HAND:

LOTRACH=TRUE → BSC controlled

LOTRACH=FALSE → MSC controlled **

Limitation of intra-cell handover(quality) repetition

HAND: ELIMITCH=TRUE

MAIRACHO

TINOIERCHO

HO decision also on distance criteria

HAND: CCDIST=TRUE

HOCCDIST

Intracell HO due to

Enhanced Pairing

BSC: EPA=TRUE

a) enhanced pairing due to

radio TCH load

BTS: EPAT1

EPAT2

b) enhanced pairing due to

BTSM Abis pool TCH 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 pool TCH load

BTSM: ABISHRACTHR

Intracell HO due to O&M

No

parameters !



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

< This command is used to set UL/DL quality thresholds for data speed up- and downgrade between 14.4kbit/s and 9.6kbit/s and quality inter-cell handovers for ongoing data calls. >

SET HAND [DATA] :

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

NAME= BTSM:0/BTS:0/HAND:0,

Object path name.

ERUDGR=FALSE,

object: HAND [DATA]

range: TRUE, FALSE

default: FALSE

Enable rate up-/downgrade, this flag determines whether the quality evaluation for rate up-downgrading decision for 14.4kbit data services is enabled or not (see also parameter SPEED145 in the command SET BSC [BASICS]). If this feature is enabled, the BTS uses the DL measurement reports and UL measurement results to decide whether an upgrade from 14.4kbit/s to 9.6kbit/s or a downgrade (vice versa) is necessary for an ongoing data call. This decision is based exclusively on the UL/DL quality values determined for the serving TCHs. If the BTS decides that an up- or downgrade is necessary it sends a MODE MODIFICATION INDICATION message to the BSC which in turn executes the up- or downgrade. If the BTS recommends a rate downgrade and the data call is an HSCSD call, the BSC will downgrade the data rate per TCH from 14.4Kbit/s to 9.6kbit/s but may decide to keep the user data rate by activating another TCH for the call. If a downgrade does not lead to a sufficiently improved quality, an intercell handover due to quality is initiated. For the threshold values for the up- and downgrade respectively the inter-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 window, this parameter specifies the size of the 'gliding averaging window' used for the up- and downgrade decision. Before an up- or downgrade decision is made, the MEASUREMENT REPORTS from the MS and the BTS are averaged by a a 'gliding' averaging mechanism. The value of this parameter defines over many measurement samples the averaging is performed.

RDGRDL=2,

object: HAND [DATA]

range: 1-6

default: 2

Rate downgrade threshold downlink, this parameter specifies the downlink quality threshold (in RXQUAL values) for the downgrade (14.4 kbit/s -> 9.6kbit/s). To ensure a proper working of the decision algorithm the following rule has to be followed:

RUGRDL < RDGRDL < RHOLTQDL

RDGRUL=2,

object: HAND [DATA]

range: 1-6

default: 2

Rate downgrade threshold uplink, this parameter specifies the uplink quality threshold (in RXQUAL values) for the downgrade (14.4 kbit/s -> 9.6 kbit/s). To ensure a proper working of the decision algorithm the following rule has to be followed:

RUGRUL < RDGRUL < RHOLTQUL



RHOLTQDL=3,

object: HAND [DATA]

range: 2-7

default: 3

Rate handover lower threshold quality downlink, this parameter defines the receive signal quality threshold (in RXQUAL values) on the downlink for handover decision for data calls where the rate up/downgrading mechanism was applied. To ensure a proper working of the decision algorithm the following rule has to be followed:


RHOLTQUL=3,

object: HAND [DATA]

range: 2-7

default: 3

Rate handover lower threshold quality uplink, this parameter defines the receive signal quality threshold (in RXQUAL values) on the uplink for handover decision for data calls where the rate up/downgrading mechanism was applied. To ensure a proper working of the decision algorithm the following rule has to be followed:


RUGRDL=1,

object: HAND [DATA]

range: 0..5

default: 1

Rate upgrade threshold downlink, this parameter specifies the downlink quality threshold (in RXQUAL values) for the upgrade (9.6 kbit/s -> 14.4 kbit/s). To ensure a proper working of the decision algorithm the following rule has to be followed:


RUGRUL=1,

object: HAND [DATA]

range: 0..5

default: 1

Rate upgrade threshold uplink, this parameter specifies the uplink quality threshold (in RXQUAL values) for the upgrade (9.6 kbit/s -> 14.4 kbit/s). To ensure a proper working of the decision algorithm the following rule has to be followed:


TINHRDGR=5,

object: HAND [DATA]

unit: 2 SACCH multiframes range: 2-100

default: 5

Timer to inhibit rate downgrade, this parameter specifies the minimum time between an upgrade from 9.6 kbit/s to 14.4kbit/s and the next downgrade request sent by the BTS within the MODE MODIFICATION INDICATION.

TINHRUGR=10,

object: HAND [DATA]

unit: 2 SACCH multiframes range: 2-100

default: 10

Timer to inhibit rate upgrade, this parameter specifies the minimum time between a downgrade to from 14.4 kbit/s to 9.6kbit/s and the next upgrade request sent by the BTS within the MODE MODIFICATION INDICATION.



Setting the status of SMS-CB, Frequency Hopping and Call Release due to Excessive Distance:

< The command SET BTS [OPTIONS] already appeared together with the other BTS-specific packages. The parameters, however, that determine the status of SMS Cell Broadcast, Frequency Hopping and Extended Cell Handover must be placed after the CREATE CHAN commands because an activation of these features is only possible if the CHAN objects have been created with the appropriate attributes before (for Frequency Hopping: CHAN must be created with a FHSYID, for SMS-CB a SCBCH or a BCBCH must be created for the cell, for Extended Cell Handover: CHAN must be created with EXTMODE=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,


range: TRUE, FALSE

default: FALSE

Excessive distance release enabled, this parameter determines whether the feature 'call release due to excessive distance' is enabled. If the MS-BTS distance is bigger than the value entered for EXCDIST no call setup is possible. On the other hand, if during an ongoing call the MS-BTS distance exceeds the EXCDIST threshold (see corresponding parameter) the BTS sends a CONNECTION FAILURE message with cause 'distance limit exceeded' to the BSC and the call is released.

EXCDIST =35,


unit: 1km range: 1-35 (for standard cells)

1-100 (for extended cells)

default: 35 (for standard cells)

100 (for extended cells)

Excessive distance, this parameter specifies the distance limit (between MS and BTS) to be used for call release if the feature 'call release due to excessive distance' is enabled (EEXCDIST=TRUE) Note: The value entered for EXCDIST must be greater than the value entered for the distance handover threshold (see parameter HOTMSRME (SET HAND)).

Rules: standard cells: HOTMSRM (HAND) < EXCDIST extended cells: HOMSTAM (HAND) < HOTMSRME (HAND) < EXCDIST

HOPP=TRUE,


range: TRUE, FALSE

default: FALSE


Frequency hopping enabled, indicates whether frequency hopping is manually enabled in the BTS by the operator. For ongoing calls, the information stating whether FH is enabled or not is sent on the main DCCH in the IE ‘Channel Description’ (contained e.g. in the ASSIGNMENT COMMAND and the HANDOVER COMMAND) in form of the parameter H. If H=0 then frequency hopping is disabled, if H=1 then frequency hopping is enabled. For the MSs in idle mode the status of FH is indicated by the SYSTEM INFORMATION TYPE 1 message which is sent on the BCCH (see also parameter CALL in the command CREATE BTS [BASICS]). Whether frequency hopping is actually active or not is not only determined by the ‘semipermanent’ flag HOPP but also by a ‘transient’ system-internal flag BTS IS HOPPING (can be interrogated by the command GETINFO BTS) which is managed system-internally. If e.g. in a BTS with active baseband FH a TRX-HW (BBSIG, TPU, PA or CU) fails or is manually locked, FH is automatically disabled by the BSC for the BTS to make sure that there is no impact on the call quality. In this case the state of the flag BTS IS HOPPING changes to ‘NO' while the (exclusively command-controlled) flag HOPP does not change. In any case the BSC is the master for both the HOPP and the BTS IS HOPPING flag, i.e. the BTS only changes the FH if explicitly requested by the BSC via the LPDLM link. For the BTS there is actually no difference between a disabling of hopping due to



HOPP=FALSE or due to BTS_IS_HOPPING=NO.

Generally, every change of the frequency hopping mode is reported to all busy MSs in the cell by a FREQUENCY REDEFINITION message. These messages contain the channel data such as the new ‘mobile allocation’, hopping sequence and MAIO and are specific for each ongoing call. When hopping is disabled (no matter whether this is done by command or automatically) the FREQUENCY REDEFINITION points out a new mobile allocation which consists of only one carrier and MAIO=0. This means that the MSs hop on one carrier frequency only. If FH was disabled automatically due to failure or locking of a TRX-HW, it is again automatically enabled by the BSC if the failed/locked TRX-HW is put back to service: BTS IS HOPPING changes its state to ‘YES’ and another FREQUENCY REDEFINITION procedure is started for all busy MSs.

If the hopping mode changes either due to manual or automatic disabling of hopping, the cell is set to “ barred “ for about 10s. This is done to avoid unpredictable hopping errors in the hopping mode switchover phase as the “ starting time “ of the new hopping system is 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 also H=1 (=hopping channel)!

SMSCBUSE=TRUE,


range: TRUE, FALSE

default: FALSE


Short message service cell broadcast used, this parameter can only be set to TRUE if the BTS radio channels are created accordingly (see BCCH- and SDCCH creation). If this value is set to TRUE the SYSTEM INFORMATION TYPE 4 on the BCCH contains the additional IE ‘CBCH Description’ and - if Frequency Hopping is enabled - the IE ‘CBCH Mobile Allocation’. Note: Control channels with CBCH capability (BCBCH or SCBCH) may only be deleted if SMSCBUSE is set to FALSE.



Creating the Target Cell Objects:

< The command CREATE TGTBTS has to be entered for all external neighbour cells, i.e. for neighbour cells that are served by a different BSC. The TGTBTS object includes all basic cell parameters and identities of the external neighbour cell. In BR6.0 a new approach in the creation and administration of adjacent cells was introduced: - If an ADJC object represents an internal cell (i.e. a cell belonging to the same BSC), the ADJC object refers to the created BTS object. - If an ADJC object represents an external cell (i.e. a cell belonging to a different BSC), the ADJC object refers to the created TGTBTS object. - The BTS specific ADJC objects only include the parameters relevant for the for handover decision and GPRS cell reselection. The advantage of this approach is that the basic cell data are not repeated in all (BTS specific) ADJC objects (which increases the probability of errors) but are created only once in the database for all possible adjacent cell relations. >

CREATE TGTBTS:

NAME=TGTBTS:0, Object path name.

BCCHFREQ=103,

object: TGTBTS

range: 0..1023


GSM 04.08

GSM 05.05

GSM 12.20

BCCH frequency, This parameter defines the BCCH frequency of the neighbour cell. This info appears (together with the other adjacent cells) - for the MSs in 'idle' mode: on the BCCH in the SYSTEM INFORMATION TYPE 2, SYSTEM INFORMATION TYPE 2ter (in dualband networks) and SYSTEM INFORMATION TYPE 2bis in the IE ‘Neighbour Cells Description’. - for the MSs in 'dedicated mode' or 'busy' mode: on the main signalling channel (SDCCH or FACCH) in the SYSTEM INFORMATION TYPE 5, SYSTEM INFORMATION TYPE 5ter (for dualband networks) and SYSTEM INFORMATION TYPE 5bis in the IE ‘Neighbour Cells Description’ and, during inter-cell handover, also in the main DCCH in the HANDOVER COMMAND in the IE ‘Cell Description’.

From the SYSTEM INFORMATION TYPE 2, 2ter and 2bis the MS knows the neighbour cells which have to be monitored for cell reselection in idle mode, via the information sent in the SYSTEM INFORMATION TYPE 5, 5ter and 5bis the MS is informed which of the neighbour cells are to be monitored during the call phase, i.e. for which neighbour cells measurement reports may be generated.

BSIC=7-3,

object: TGTBTS

range: 0..7 (NCC)

0..7 (BCC)


GSM 04.08

GSM 05.02

GSM 05.08

GSM 12.20

Base Station Identity Code, parameter format: NCC - BCC (for detailed explanations see parameter BSIC (CREATE BTS [BASICS])). This parameter is sent in the DCCH in the HANDOVER COMMAND in the IE ‘Cell Description’. It is used by the MS to correctly decode the BCCH bursts of the neighbour cell.

TGTCELL= TGTCELL= internal

neighbour cells

external neighbour

cells TGTBTS:n BTSM:x/BTS:n

ADJ



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 Identity, this identity corresponds to the info sent on the BCCH of the neighbour cell in the message SYSTEM INFORMATION TYPE 3 and 4. For details see the same parameter in the command CREATE BTS [BASICS].

MSTXPMAXDCS=0,

object: TGTBTS


range: 0..15

default: 0


GSM 05.05

GSM 04.08

GSM 03.22

GSM 12.10

Maximum transmission power level in DCS target cell, indicates the maximum transmission power level a MS is allowed to use in the DCS target cell. This parameter is used in the handover pre-processing algorithm in the BTS which evaluates the measurement reports in order to determine the target cells for handover and directed retry. The selection of a value corresponding to the actual settings of the BTS represented by the neighbour cell (see CREATE BTS [BASICS]: MSTXPMAXDCS=...) is recommended but not mandatory since the two parameters are independent: MSTXPMAXGSM (TGTBTS) is only used by the handover algorithm in the BTS, while MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) in CREATE BTS [BASICS] determines the allowed transmit power in the 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 transmission power level in GSM target cell, indicates the maximum transmission power level a MS is allowed to use in the GSM target cell. This parameter is used in the handover pre-processing algorithm in the BTS which evaluates the measurement reports in order to determine the target cells for handover and directed retry.

Value range: GSM900: 2..15 , default: 2=39dBm (step size -2dBm) GSMR: 2..15 , default: 0=30dBm (step size -2dBm)

For further information please refer to the explanation provided for the parameter MSTXPMAXDCS (TGTBTS) and, for the value ranges, to the parameter MSTXPMAXDCS (BTS [BASICS]).

MSTXPMAXPCS=0,

object: TGTBTS


range: 0..15, 30, 31

default: 0

Maximum transmission power level in PCS target cell, indicates the maximum transmission power level a MS is allowed to use in the PCS target cell. This parameter is used in the handover pre-processing algorithm in the BTS which evaluates the measurement reports in order to determine 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),

PCS1900

GSMDCS

GSM850

GSM850PCS


System Indicator, indicates the frequency band used by the traffic channels. If F2ONLY900 is selected only phase2 mobiles can be used, phase1 mobiles are not supported. If EXT900 is selected the GSM base band is still usable for phase1 mobiles, the extension band, however, can only be used for traffic purposes by phase2 mobiles.

Creating the Target Point-to-point Packet Flow Objects:

< The command CREATE TGTPTPPKF has to be entered for all external GPRS neighbour cells, i.e. for neighbour cells that support GPRS and that are served by a different BSC. The TGTPTPPKF object includes all basic cell parameters and identities of the external neighbour cell. In BR6.0 a new approach in the creation and administration of adjacent cells was introduced: - If an ADJC object represents an internal GPRS cell (i.e. a cell supporting GPRS and belonging to the same BSC), the ADJC object refers to the created BTS object which in turn is superordinate to a PTPPKF object.

- If an ADJC object represents an external GPRS cell (i.e. a cell supporting GPRS and belonging to a different BSC), the ADJC object refers to the created TGTBTS object which in turn is superordinate to a TGTPTPPKF object. - The ADJC objects are specifically defined for each originating BTS and mainly comprise the handover decision parameters and advanced GPRS cell reselection parameters. The advantage of this approach is that the basic cell data are not repeated in all (BTS-specific) ADJC objects (which increases the probability of errors) but are created only once in the database for all possible adjacent cell relations. >

CREATE TGTPTPPKF:

NAME= TGTBTS:0/TGTPTPPKF:0,

Object path name.

GMSTXPMAC=2,

object: TGTPTPPKF

range: 0..31

default: 15



Maximum allowed GPRS MS transmission power on PBCCH/ PCCCH. GMSTXPMAC defines the maximum power level that may be used by the mobile to access the cell on the PRACH. The valid values and meanings are the same as defined for the parameter MSTXPMAXCH (see SET BTS [CCCH]).

Note: In case Network Controlled Cell Reselection (NCCR) is activated in the serving cell (NCRESELFLAG=ENABLED), the PCU uses GRXLAMI as well as GMSTXPMAC to calculate the C1 values also in case no PBCCH is created in the cell.

This parameter corresponds to the GSM parameter GPRS_MS_TXPWR_MAX_CCH.


neighbour cells

external neighbour

cells TGTBTS:n

TGTBTS:n/TGTPTPPKF:m

ADJ

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 configured in the cell, GPRS mobiles use this value instead of the GSM equivalent RXLEVAMI (object BTS). It is used together with other parameters to calculate C1 and C32 for cell reselection. This parameter is sent for the indicated neighbour cell on the PBCCH (PSI3).

Note: In case Network Controlled Cell Reselection (NCCR) is activated in the serving cell (NCRESELFLAG=ENABLED), the PCU uses GRXLAMI as well as GMSTXPMAC to calculate the C1 values also in case no PBCCH is created. This parameter corresponds to the GSM parameter GPRS_RXLEV_ACCESS_MIN.

RACODE=10,

object: TGTPTPPKF

range: 0..255

Routing area code, this attribute represents the identification of the RA 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 identifies the 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’s unique in the LA, this parameter is used to choose the right RA when the mobile is listening different LA containing routing area with the same code. The RA colour for the neighbour LA must be set different by network planning.



� General hint concerning the neighbour cell relations:

All adjacent cells that are created for a certain BTS appear in the SYSTEM_INFORMATION_Type2,

2ter and 2bis on the BCCH (MS in idle mode) and SYSTEM INFORMATION Type5, 5ter and 5bis

on the SACCH (MS in dedicated mode) in the IE ‘Neighbour Cells Description’. From the SYSTEM

INFORMATION TYPE 2, 2ter and 2bis the MS knows the neighbour cells which have to be monitored for

cell reselection, from the SYSTEM INFORMATION TYPE 5, 5ter an 5bis the MS knows the neighbour

cells which have to be monitored for handover. The MS measures the RXLEV of these neighbour cells to

provide MEASUREMENT REPORTS to the serving BTS which uses them for the handover decision.

The necessity to create a BTS as ADJC is completely independent of its physical location (same BTSE,

other BTSE, other BSC etc.).

If a GPRS PBCCH is configured, the neighbour cell data for GPRS mobiles are broadcast in the

PACKET_SYSTEM_INFORMATION_Type3, 3bis on the PBCCH in the IE ‘Neighbour cell

parameters’.

Creating the Adjacent Cell Objects:

< From BR6.0 on a new approach was used to structure the neighbour cell data. With this approach ADJC objects mainly represent parameters used for handover and advanced GPRS cell selection parameters while the basic cell data and identities are represented by the BTS and PTPPKF objects (for internal cells) and by the TGTBTS and TGTPTPPKF objects (for external cells). For further details please refer to the commands CREATE TGTBTS and 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 the adjacent cell from point of view of the cell (resp. BTS) for which it is created. 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 handover forbidden timer for traffic handover, this parameter is used for back handover prevention and is considered after an incoming traffic handover. If the feature “Traffic Handover” respectively “Handover due to BSS Resource Management Criteria” (see parameter TRFHOE in command SET HAND [BASICS]) is enabled, a cell might be the target of an incoming traffic handover. In this back-handovers due to traffic or power budget are prevented by the following mechanism: if an traffic handover is performed, the BSC extends the CHANNEL ACTIVATION message for the 'new' TCH in the target cell by the IE 'Cell List Preferred' which contains the CGI of the handover origin cell and by a GSM 08.08 cause IE with the cause 'traffic'. This message starts the timer BHOFOT in the BTS. As long as BHOFOT runs, the BTS excludes the CGI (that was previously received from the BSC in the CHAN ACT message) from all HANDOVER CONDITION INDICATIONs that are sent with the causes “better cell” and “traffic“. The back handover prevention mechanism for traffic handover is permanently enabled and cannot be deactivated by database flag.



FHORLMO=6,

object: ADJC

unit: 1dB

range: 0..24

default: 6

Forced handover Rx level minimum offset, determines the additional offset considered in addition to the handover minimum criterion for “Forced Handover”. Forced handover consists of the following handover types - Directed Retry (see parameter ENFORCHO in the command SET BSC [BASICS]) - Forced Handover due to Preemption (see parameter EPRE in the command SET BTS [OPTIONS]) and - Forced Handover due to O&M (automatically executed after a SHUTDOWN command for a BTS, TRX or CHAN object and not administrable by database parameters).

The value FHORLMO value is added to the RXLEVMIN entered for this adjacent cell in order to calculate the minimum RxLev the neighbour cell must provide to be considered as a target cell for the directed retry. In other words: Only if the actual RxLev of an adjacent cell is greater than the sum of RXLEVMIN and FHORLMO (simplified) the BTS regards this cell as a suitable candidate for the forced handover procedure and will insert it into the target cell list included in the HANDOVER CONDITION INDICATION message. For details please refer to section 2.1.2.6.

FULHOC=FALSE,

object: ADJC

range: TRUE, FALSE

default: FALSE

Fast uplink handover predefined cell, this parameter is used during the target cell list generation process during a Fast Uplink Handover (see parameter EFULHO in command SET HAND [BASICS]) and is used to declare specific neighbour cells as “predefined” respectively ”preferential” target cells for fast uplink handover. When the BTS triggers a fast uplink handover it sends a INTERCELL HANDOVER CONDITION INDICATION that includes the cause ‘fast uplink’ and a target cell list. The ranking on the target cells within this target cell list is based on two factors: the setting of the flag FULHOC and the level PBGT-HOM situation. The target cell list consists of two sublists: the upper list consists of all “preferential” target cells (FULHOC=TRUE), the lower one consists of ordinary target cells (FULHOC=FALSE). Within each sublist the target cells are ranked in descending order of the difference between the power budget (which is, simply expressed, the level difference between the serving and the neighbour cell) and the power budget handover margin (see parameter HOM). In other words, the target cells within each sublist are ranked in descending order of the value PBGT(n) – HOM(n).

For further details details concerning the fast uplink handover decision process and the ranking of the target cells please refer to the section ‘Handover Thresholds and Algorithms’ in the appendix of this document.



FULRXLVMOFF=69,

object: ADJC

unit: 1dB

range: 0..126 (-63dB..+63dB)

default: 69 (=6dB)

Fast uplink handover receive level minimum offset, this parameter is used during the target cell list generation process during a Fast Uplink Handover (see parameter EFULHO in command SET HAND [BASICS]) and represents an additional offset which is added to the handover minimum criterion to qualify an adjacent cell as a target 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 exceeds the sum of RXLEVMIN, FULRXLVMOFF and the correction term Max(0,Pa), the neighbour cell is regarded as a suitable target cell for fast uplink handover and might appear in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION with cause ‘fast uplink’.

For further details details concerning the fast uplink handover decision process and the ranking of the target cells please refer to the section ‘Handover Thresholds and Algorithms’ in the appendix of this document.

GHCSPC =10,

object: ADJC

range: 0..7

default: 3


GPRS hierarchical cell structure priority class, this attribute represents the Hierarchical Cell Structure priority for the cell reselection procedure.

This parameter corresponds to the GSM parameter GPRS_HCS_PRIORITY_CLASS.

GHCSTH=10,

object: ADJC

unit: 2dB

range: 0..31

0=-110dB, 31=-48dB

default: 10


GPRS hierarchical cell structure threshold, this attribute indicates the signal strength threshold used in the HCS cell reselection procedure (C31).

This parameter corresponds to the GSM parameter GPRS_HCS_THR.

GPENTIME=0,

object: ADJC

unit: 10s

range: 0..31

default: 0 (=10s)

GPRS penalty time, this attribute defines the duration for which GTEMPOFF is applied to C31 and C32 in the cell reselection procedure. The set values are coded as follows:

0 0 0 0 0 = 10s 0 0 0 0 1 = 20s … 1 1 1 1 1 = 320s

This parameter corresponds to the GSM parameter GPRS_PENALTY_TIME.

GRESOFF=0,

object: ADJC

unit: 4dB (for the first 11 values

and for the last 9 values)

2dB (for all remaining

values)

range: 0..31

0 = -52 dB

31 = +48 dB

default: 16


GPRS reselect offset, this attribute specifies the positive or negative offset to be applied to the C32 value of a neighbour cell. The set value ranges from -52 dB to +48 dB; the step size is 4 dB for the first 11 values, 2 dB for the next 12 values and 4 dB for the last 9 values, as shown in the table below:

0 1 ... 10 11 ... 22 23 ... 31

-52dB -48dB … -12dB -10dB … +12dB +16dB … +48dB

This parameter corresponds to the GSM parameter GPRS_RESELECT_OFFSET.



GSUP=TRUE,

object: ADJC

range: TRUE, FALSE

default: FALSE

GPRS support, this attribute indicates if the adjacent cell information is included in the PSI3 messages in case a PBCCH is configured in the serving cell. The status of this flag is not relevant if no PBCCH is created in the source cell!

Only if GSUP=TRUE, the GPRS cell reselection parameters defined in the related ADJC/PTPPKF/TGTPTPPKF objects are broadcast in the PACKET SYSTEM INFORMATION TYPE 3 on the PBCCH. This allows the GPRS attached mobiles to autonomously calculate all criteria (C31/32) relevant for cell reselection. In case NCCR is activated, the BSC will do this job based on level measurements provided by the MS inside the PACKET MEASUREMNT REPORT messages.

The parameters of the neighbour cell that are broadcast in the PACKET SYSTEM INFORMATION on the PBCCH are derived from the PTPPKF object associated to the neighbour cell as follows:

a) if the cell is an internal cell (i.e. belonging to the same BSC), the parameters are derived from the PTPPKF object (see CREATE PTPPKF) subordinate to the BTS object (see CREATE BTS) entered in the TGTCELL parameter. b) if the cell is an external cell (i.e. belonging to a different BSC), the parameters are derived from the TGTPTPPKF object (see CREATE PTPPKF) subordinate to the TGTBTS object (see CREATE TGTBTS) entered in the TGTCELL parameter.

GTEMPOFF=1,

object: ADJC

unit: 10dB

range: 0..7

7=infinity.

default: 1


GPRS temporary offset, this attribute applies a negative offset to C31 and C32 (depending if the cell priorities of source and neighbour cell are equal or not) for the duration of GPENTIME. The value range is coded as follows:

0 1 2 3 4 5 6 7

0dB 10dB 20dB 30dB 40dB 50dB 60dB infinite

This parameter corresponds to the GSM parameter GPRS_TEMPORARY_OFFSET.


neighbour cells

external neighbour

cells TGTBTS:n

TGTBTS:n/TGTPTPPKF:m

ADJ

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)


GSM 12.20

Handover margin, this parameter defines a threshold for the power budget handover (see parameter PBGTHO in command SET HAND [BASICS]). The handover margin is used for the power budget handover decision process: a power budget handover (‘better cell’ handover) is only triggered (i.e. an INTERCELL HANDOVER CONDITION INDICATION with cause ‘better cell’ is sent to the BSC) if the power budget of a specific neighbour cell exceeds the handover margin set for the ADJC object representing this cell. The power budget is calculated for every neighbour cell and represents - simplified - the DL receive level difference between the serving and in the neighbour cell, of course, taking the DL power control into account.

The purpose of the handover margin is to prevent back-and-forth handover repetitions between adjacent cells (‘ping pong handover’), e.g. if a MS moves along a boundary between two cells. Different adjacent cells can be assigned different handover margins in order to control the handover flow.

Rule: To avoid 'ping pong' handovers between the inner and complete areas in sectorized concentric cells the following rule must be followed:

HOMcoloc > (PWRREDinner - PWRREDcomplete) [dB]

'HOMcoloc ' is the handover margin set for an adjacent cell object that represents a 'colocated cell' (see parameter CCELL in command SET HAND [BASICS]).

HOMDOFF=0,

object: ADJC

unit: 1dB

range: 0..127

default: 0

Handover margin dynamic offset. This parameter is only relevant for speed sensitive handover (see parameters MICROCELL (below) and DPBGTHO in command SET HAND [BASICS]). It specifies the dynamic offset by which the handover margin is reduced after expiry of the timer HOMDTIME. For further details please refer to the explanation given for the parameter HOMDTIME.

HOMDTIME=0,

object: ADJC


range: 0..255

default: 0

Handover margin delay time. This timer is only used if speed sensitive handover is active (see parameter MICROCELL). It specifies the time an immediate handover request is delayed when a power budget handover to a microcell is requested. General Principle of the speed sensitive handover algorithm: If the BTS detects a power budget handover condition for a cell which is created as MICROCELL, the timer HOMDTIME is started: as long as this timer runs the handover margin (see parameter HOM) is artificially increased by a static offset (see parameter HOMSOFF). This ‘new’ handover margin is called HO_MARGIN_TIME(t) since its value is time dependent. If the basic power budget handover condition (i.e. PBGT > HOM) still exists when the timer expires, a dynamic offset (see parameter HOMDOFF) is subtracted from HO_MARGIN_TIME(t) again. Thus a speed sensitive handover condition is fulfilled if

PBGT > HO_MARGIN_TIME(t) where

HO_MARGIN_TIME(t) = HOM + HOMSOFF

for t ≤ HOMDTIME and

HO_MARGIN_TIME(n) = HOM + HOMSOFF - HOMDOFF for t > HOMDTIME

As long as the timer HOMDTIME runs the basic power budget handover condition is permanently checked; if the BTS detects that the basic power budget handover condition (i.e. PBGT > HOM) does not exist any more the timer is stopped and the handover is not executed. For further details please refer to chapter ‘Appendix’, section ‘Handover Thresholds & Algorithms’ of this document. Note: The values should be set according to the rule:

HOMDOFF ≥ HOMSOFF.



HOMSOFF=0,

object: ADJC

unit: 1dB

range: 0..127

default: 0

Handover margin static offset. This parameter is only relevant for speed sensitive handover (see parameters MICROCELL (below) and DPBGTHO in command SET HAND [BASICS]). It specifies the static offset by which the handover margin is increased as long as the timer HOMDTIME runs. For further details please refer to the explanation 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 handover margin for handovers due to uplink level or downlink level. The level handover is triggered if the UL or DL receive level of the serving cell falls short of the thresholds HOLTHLVUL resp. HOLTHLVDL. If the feature “Level handover margin” (see parameter ELEVHOM in command SET HAND [BASICS]) is disabled (ELEVHOM=FALSE), the target cell only has to fulfil the handover minimum condition

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa).

to be included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION with the cause values “uplink strength” or “downlink strength”.

If the feature “Level handover margin” is enabled (ELEVHOM=TRUE), also the level difference between the serving cell and the neighbour cell (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 PBGT calculation only considers the downlink levels of the serving and the neighbour cell!

For further details please refer to the section “Handover Thresholds and Algorithms” in the appendix of this document.

LEVONC=0,

object: ADJC

unit: 1 dB

range: 0..63

default: 0

Level offset for neighbour cell, this parameter determines the level offset that is added to the minimum receive level of an adjacent cell if ‘ranking method 1’ is selected in the ‘Hierarchical cell ranking flag’ (For further details please see the explanation for the parameter HIERF in command SET HAND [BASICS]).

For the terms RXLEV_NCELL(n), RXLEVMIN (n), Max(0,Pa), PBGT(n) and HO_MARGIN(n) please refer to the section ‘Handover Thresholds & Algorithms’.

MICROCELL=FALSE,

object: ADJC

range: TRUE, FALSE

default: FALSE

Microcell, determines whether the adjacent cell is regarded as a ‘microcell’. Only if this parameter is set to TRUE the ‘speed sensitive handover’ algorithm will be in effect for this neighbour cell. Precondition: the database flag for speed sensitive handover is set to ‘enabled’ (SET HAND [BASICS]:DPBGTHO=TRUE). For this feature also the parameters HOMDOFF, HOMDTIME and HOMSOFF (see above) are relevant.

Attention: With the BR7.0 ‘cleanup load’ (BR70/45, TDPC load 34-02) the change request CR2829 is introduced. This CR is activated when the patches T1340226, T1340228 and M1340212 are loaded and changes the meaning of the MICROCELL parameter for a special purpose related to ASCI features: When MICROCELL s set to TRUE, the adjacent cell is set to ‘barred’ in the SYSTEM INFORMATION TYPE 10. This is necessary to prevent cell reselection in ‘Group Receive Mode’ to the affected neighbour cells for ASCI mobiles.



MSTXPMAXCL=2,

object: ADJC

unit, range and default values see

explanation to the right!


GSM 05.05

GSM 12.20

Maximum transmission power level, indicates the maximum transmission power level a MS is allowed to use in the neighbour cell. This parameter is used in the handover pre-processing algorithm in the BTS which evaluates the measurement reports in order to determine the target cells for handover and directed retry. The selection of a value corresponding to the actual settings of the BTS represented by the neighbour cell (see CREATE BTS [BASICS]: MSTXPMAX=...) is recommended but not mandatory since the two parameters are independent: MSTXPMAXCL (ADJC) is only used by the handover algorithm in the BTS, MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) (CREATE BTS [BASICS]) determines the allowed transmit power in the IE ‘Power command’ on TCH 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 controlled cell reselection C1 threshold adjacent cell, this parameter is used during GPRS network controlled cell reselection (see parameter NCRESELFLAG in command SET BSC) and defines the minimum C1 value of the adjacent cell required to be considered as potential target cell.

NCGPENTIME=SEC000,

object: ADJC

range: SEC000…SEC320

(0 sec. .. 320 sec.)

step size: 1 sec.

default: SEC000 (0 sec.)

Network controlled cell reselection GPRS penalty time, this parameter defines the duration for which NCGTEMPOFF is applied to C31 and C32 in case NCCR is activated (NCRESELFLAG = TRUE). The set value ranges from 0 to 320s in steps of 1 second.

The equivalent parameter in case NCCR is disabled is GPENTIME.

This parameter corresponds to the GSM parameter GPRS_PENALTY_TIME.

NCGRESOFF=DB00,

object: ADJC

range: MDB52...MDB01

(-52dB..-1dB)

DB00..DB48

(0dB..48dB)

step size: 1dB

default: DB00 (0dB)

Network controlled cell reselection GPRS reselect offset, this attribute specifies the positive or negative offset to be applied to the C32 value of the neighbour cell in case NCCR is activated (NCRESELFLAG = TRUE). The set value ranges from -52 dB to +48 dB in steps of 1dB.

The equivalent parameter in case NCCR is disabled is GRESOFF.

This parameter corresponds to the GSM parameter GPRS_RESELECT_OFFSET.

NCGTEMPOFF=DB00,

object: ADJC

range: DB00..DB60

(0dB..60dB)

NEVER

step size: 1dB

default: DB00 (0dB)

Network controlled cell reselection GPRS temporary offset, this parameter specifies the negative offset applied to C31 and C32 for the duration of NCGPENTIME in case NCCR is activated. The set value ranges from 0 to 60 dB in steps of 1dB. The value NEVER means infinity.

The equivalent parameter in case NCCR is disabled is GRESOFF.

This parameter corresponds to the GSM parameter GPRS_TEMPORARY_OFFSET.



PLNC=0,

object: ADJC

range: 0..15

0 = highest priority

15 = lowest priority

default: 0

Priority layer of neighbour cell, this parameter determines the priority layer of the adjacent cell. The priority layer is relevant for the handover 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 priority layer of neighbour cell, this parameter is relevant for the handover decision if the features ‘speed sensitive handover’ (see parameter DPBGTHO in command SET HAND [BASICS]) and ‘ranking of target cells on the basis of priority’ (see parameter HIERC in command SET HAND [BASICS]) is enabled. It determines the temporary priority layer of those adjacent cells which are defined as microcells (see parameter MICROCELL). PPLNC is only evaluated by the ranking algorithm as long as the handover margin delay timer HOMDTIME is running. Its purpose is to to allow the operator to temporarily decrease the priority of the affected neighbour cell to avoid handovers into this cell for fast moving MSs. Rule: PLNC(n) < PPLNC(n) n = no. of a certain ADJC object

RXLEVMIN=12,

object: ADJC

unit: 1 dB

range: 0..63


1 = -110dBm to -109dBm

2 = -109dBm to -108dBm

...

62 = -49dBm to -48dBm


default: 12


GSM 12.20

Rx level minimum, determines the minimum received signal level the adjacent cell must provide to be regarded as a suitable target cell for handover. It is the minimum Rx level required for a MS to perform the handover to the adjacent cell. This parameter is used in the handover pre-processing algorithm in the BTS which evaluates the measurement reports in order to determine the target cells for handover and directed retry. The selected value should correspond to the actual settings of the BTS represented by the neighbour cell (see CREATE BTS [BASICS]:RXLEVAMI =...) although both parameters are basically independent from each other.

Note: Unlike other BTS parameters that cannot be entered anymore if the adjacent cell is an internal one (served by the same BSC) the parameter RXLEVMIN can still be set if the ADJC object represents an internal cell. The reason is that RXLEVMIN plays an important role in the handover evaluation algorithm and might be used for handover adjustment of special neighbour cell relations.

TGTCELL= BTSM:10/BTS:0,

object: ADJC

format: object instance path name

Internal cells

BTSM:n/BTS:m

External cells

TGTBTS:n

Target cell, this attribute specifies the object instance path name of the database object that represents the basic data of the neighbour cell. Depending on whether the neighbour cell is an internal (i.e. belonging to the same BSC) or an external one (belonging to a different BSC) the TGTCELL parameter points to different object types: a) If the ADJC object represents an internal cell (BTS), the TGTCELL parameter points to the associated BTS object (see command CREATE BTS). b) If the ADJC object represents an external cell (BTS), the TGTCELL parameter points to the associated TGTBTS object (see command CREATE TGTBTS).


neighbour cells

external neighbour

cells TGTBTS:n BTSM:x/BTS:n

ADJ



TIMERFHO=12,

object: ADJC

unit: 10s

range: 1-320

default: 12 (=120s)

Timer for forced handover, this timer is started after an incoming forced handover procedure. Forced handover consists of the following handover types - Directed Retry (see parameter ENFORCHO in the command SET BSC [BASICS]) - Forced Handover due to Preemption (see parameter EPRE in the command SET BTS [OPTIONS]) and - Forced Handover due to O&M (automatically executed after a SHUTDOWN command for a BTS, TRX or CHAN object and not administrable by database parameters).

A mechanism is implemented which prevents back-handovers due to power budget to the cell which was the origin of the forced handover. This mechanism works in the following way: if a forced handover is performed the BSC extends the CHANNEL ACTIVATION message for the 'new' TCH in the target cell by the IE 'Cell List Preferred' which contains the CGI of the handover origin cell and by a GSM 08.08 cause IE with the cause 'forced'. This message makes the BTS suppress the handover origin cell in all following INTERCELL HANDOVER CONDITION INDICATION messages sent with the cause 'better cell' for the time period administrable with TIMERFHO. After the timer expiry the power budget handover is allowed again.

TINHBAKHO=30,

object: ADJC

unit: 1s

range: 1-254

default: 30

Timer to inhibit back handover, this parameter is only considered if the flag NOBAKHO (see SET HAND [BASICS]) is set to TRUE. It specifies the time period for which the BTS excludes the adjacent cell from the power budget handover decision if this cell was the origin of an imperative handover. Rule: TINHBAKHO > THORQST(HAND) > T7 (SET BSC [TIMER])

Note: The flag NOBAKHO is relevant for the handover target cell, i.e. the CHANNEL ACTIVATION message is extended by the above mentioned IEs if the BSC detects that for the handover target cell the flag NOBAKHO is 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.

TINHFAIHO=7,

object: ADJC

unit: 1s

range: 1-254

default: 7

Timer to inhibit handover failure repetition, this parameter is only considered if the flag NOFREPHO (see SET HAND [BASICS]) is set to TRUE. It specifies the time period for which the BTS excludes a specific adjacent cell from the target cell list when the threshold for the maximum allowed number of failed handovers (see parameter MAXFAILHO in command SET HAND [BASICS]) has been reached. Rule: TINHFAIHO > THORQST(HAND) > T7 (SET BSC [TIMER])



TRFHOM=67,

object: ADJC

unit: 1dB

range: 0..126

0 = -63dB

126 = +63dB

default: 67 (= 4dB)

Traffic Handover margin, this parameter defines the basic value of the handover margin used for traffic handover (see parameter TRFHOE in the command SET HAND [BASICS]). Like for the power budget handover, the traffic handover margin is used for the handover decision process in the BTS: a traffic handover is triggered (i.e. an INTERCELL HANDOVER CONDITION INDICATION with cause ‘traffic’ is sent to the BSC) only if the power budget of a specific neighbour cell exceeds the traffic handover margin that was set for the associated ADJC object representing this neighbour cell. The power budget is calculated for every neighbour cell and represents - simplified - the DL receive level difference between the serving and the neighbour cell, taking the DL power control into account.

Different adjacent cells can be assigned different traffic handover margins in order to control the traffic handover flow.

Important notes: 1) The traffic handover decision process only runs in the BTS, if the BSC has enabled it explicitly by an appropriate O&M message (see parameter TRFCT in the command SET BSC).

2) The traffic handover decision process uses a ‘dynamic’ traffic handover margin, which is periodically recalculated on the basis of a timer-controlled process. The basic traffic handover margin that is set with TRFHOM is only a part of this ‘dynamic‘ traffic handover margin calculation. Thus the ‘real’ traffic handover margin that is actually used in the traffic handover decision process is never exactly as entered in the parameter TRFHOM but always applied in a ‘reduced’ form. The traffic handover margin is periodically reduced/increased by a process controlled by the timer TRFHOT (see parameters TRFMS and TRFMMA in command SET HAND [BASICS]). The highest possible value of the dynamic traffic handover margin (e.g. in the first TRFHOT period after enabling of the traffic handover by the BSC) is

TRFHOM – TRFMS

The lowest possible value of the dynamic traffic handover margin is

TRFHOM – TRFMMA

3) For traffic handover it might be useful if the dynamic traffic handover margin

(TRFHOM–TRFMS) > dyn. traff. HO margin > (TRFHOM-TRFMMA)

assumes negative values as the purpose of the traffic handover is to move calls from the serving cell to cells which provide a DL receive level which is not as good as that of the serving cell but still acceptable.

TRFHORXLVMOFF=30,

object: ADJC

unit: 1dB

range: 0..48 (-24dB..+24dB)

default: 30 (=6dB)

Traffic handover receive level minimum offset, this parameter is used during the target cell list generation process for Traffic Handover (see parameter TRFHOE in command SET HAND [BASICS]) and represents an additional offset which is added to the handover minimum criterion to qualify an adjacent cell as a target cell for traffic handover. In other words: only if

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + TRFHORXLVMOFF(n)

i.e. if the measured DL receive level of the neighbour cells exceeds the sum of RXLEVMIN, TRFHORXLVMOFF and the correction term Max(0,Pa), the neighbour cell is regarded as a suitable target cell for handover due to traffic and might appear in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION with cause ‘traffic’.

The purpose of this additional offset is to prevent traffic handovers for those calls that fulfil the traffic handover conditions with respect to the traffic handover margin (parameter TRFHOM, see above), but whose level is already low in the current serving cell. If the traffic handover



margin is set to negative values or reaches negative values due to the dynamic margin reduction (which is not only possible but quite a probable and even desirable setting) a handover to target cells with very poor levels should be avoided to guarantee an acceptable grade of service in the traffic handover target cell and to prevent undesired back-handovers due to level or quality (without the offset applied by the parameter TRFHORXLVMOFF a neighbour cell is regarded as suitable if it fulfils the minimum DL RXLEV on the basis of RXLEVMIN only). As many operators regard the quality of service guaranteed by RXLEVMIN as not sufficient or too insecure for a handover that is mainly supposed to change the traffic distribution but which shoul not have a noticeable negative impact on the current QoS provided to the subscriber, the administrable traffic handover offset defined by TRFHORXLVMOFF is considered in addition to RXLEVMIN when evaluating the DL RXLEV of a particular neighbour cell.

For further details details concerning the traffic handover decision process and the ranking of the target cells please refer to the section ‘Handover Thresholds and Algorithms’ in the appendix of this document.

USG=SI_2_5,

object: ADJC

range: SI_2

SI_5

SI_2_5

default: SI_2_5

Usage of neighbour cell in SYS INFO, this parameter indicates whether this adjacent cell shall be indicated as neighbour cell on the BCCH in the idle mode (SYSTEM INFORMATION TYPE 2, 2bis and 2ter) or/and on the SACCH in busy mode (SYSTEM INFORMATION TYPE 5, 5bis and 5ter). The purpose of this parameter is to control the cell reselection and handover traffic separately. In other words, with this parameter it is possible to prevent either outgoing cell reselection or outgoing handovers for specific neighbour cell relations: If a neighbour cell is included in the SYS_INFO_2 on the BCCH, the MS observes it for cell reselection. This means, that only in this case the MS measures the DL receive level of this neighbour cell while it is in ‘idle’ mode. The DL receive level is used to calculate the C1 respectively C2 criterion (see parameters CELLRESH and in command 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, the MS regards it as a target cell for handover. This means, that only in this case the MS measures and the DL receive level of this neighbour cell while it is in ‘busy’ mode and reports it to the BTS via the SACCH. This again is the precondition for any outgoing intercell handover decision by the BTS.

Thus the meaning of the values is pretty simple: - Setting USG=SI_2 means that the neighbour cell is only broadcast in the SYS_INFO_2x. Thus only cell reselection to this neighbour cell is possible, while this cell is blocked for outgoing intercell handover.

- Setting USG=SI_5 means that the neighbour cell is only signaled in the SYS_INFO_5x. Thus only outgoing intercell handover to this neighbour cell is possible, while this cell is blocked for cell reselection. - Setting USG=SI_2_5 means that the neighbour cell is both signaled in the SYSTEM INFORMATION TYPE _2x and SYSTEM INFORMATION TYPE 5x. Thus both cell reselection and outgoing intercell handover to this neighbour cell is possible.

If the BA lists (i.e. the lists of adjacent cell BCCH frequencies to monitor) are different between SYS_INFO_2 and SYS_INFO_5 the BSC has to assign complementary BA indicators (possible values: 0 or 1) to SYS_INFO_2 and SYS-INFO_5. This is necessary as the MS may report the neighbours based on the SYS_INFO_2 (e.g. directly when the MS has changed from idle to busy mode, but has not yet read the new BA list from the SYS_INFO_5) and the MS reports the neighbour cells always by their relative BCCH frequency number. To correctly translate this relative BCCH frequency number into the CGI of the neighbour cell, the BTS must know for which BA-



list the MEASUREMENT REPORT is valid. The MS indicates the valid BA-list by the BA-indicator which is included in the MEASUREMENT 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 the DL) the relevant neighbour cell description is included in the SYSTEM INORMATION TYPE 10. At present, this SYSINFO 10 contains all neighbour cells created via ADJC objects, irrespective of the setting of USG.

Starting from the BR7.0 ‘clean-up’ load, the USG parameter will also allow to control the presence of particular neighbour cells in the neighbour cell description of the SYSINFO 10 (FRQ 90569).



Creating the Target Cell Objects for handover from GSM to UMTS (FDD):

< The command CREATE TGTFDD has to be entered for all external UMTS (FDD) neighbour cells, to which a handover from GSM to UMTS and vice versa shall be possible. The TGTFDD object is subordinate to the TGTBTS object and defines parameters that are specific for UMTS FDD neighbour cells. >

CREATE TGTFDD:

NAME=TGTFDD:0, Object path name.

CELLGLID= "262"-"02"-23-111,

object: TGTFDD

range: MCC: 0..999

MNC: 0..999 (PCS1900)

MNC: 0..99 (all others)

LAC: 0..65535

CI: 0..65535


Cell Global Identity, this identity corresponds to the info broadcast on the in the UMTS(FDD) neighbour cell.

FDDARFCN=9665,

object: TGTFDD

range: 412 .. 687

9662 .. 9938,

10838 .. 10838 Reference:

FDD absolute radio frequency number, this parameter defines the absolute 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 diversity, this parameter indicates if diversity is used in the UMTS FDD target cell or not.

FDDSCRMC=1,

object: TGTFDD

range: 0..511 Reference:

FDD scrambling code, this parameter defines the primary scrambling code used by the target FDD cell.

MSTXPMAXUMTS=11,

object: TGTFDD

range: 0..19

default: 0

Reference:


Maximum transmission power level UMTS, indicates the maximum transmission power level a MS is allowed to use in the UMTS FDD neighbour cell. This parameter is used in the handover pre-processing algorithm in the BTS which evaluates the measurement reports in order to determine the target cells for handover from GSM 2G to UMTS FDD neighbour cells. The selection of a value corresponding to the actual settings of the target NodeB is recommended but not mandatory since the two parameters are set in different network elements and are thus independent.

Attention: For a proper working of 2G-3G handover MSTXPMAXUMTS should be set to the value 11 (corresponds to 21dBm). With the default value of ‘0’ the neighbour cells are reported but are not suitably considered during the target cell list generation (the value ‘0’ corresponds to 43dBm) and thus do not appear in the INTERCELL 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 is connected 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 = +63dB

default: 69 (= 6dB)

Reference:

Handover margin for 2G-3G better cell handover, this parameter defines a threshold for the ‘better cell’ handover from GSM 2G to UMTS FDD neighbour cells (see parameter EUBCHO in command SET HAND). The handover margin is used for the ‘power budget’ handover decision process: a ‘power budget’ handover from 2G to 3G is only triggered (i.e. an INTERCELL HANDOVER CONDITION INDICATION with cause ‘better cell’ is sent to the BSC) if the power budget of a specific UMTS FDD neighbour cell exceeds the handover margin set for the ADJC3G object representing this cell. The power budget is calculated for every neighbour cell and represents - simplified - the DL receive level difference between the serving 2G and in the 3G neighbour cell, of course, taking the DL power control into account.

The purpose of the handover margin is to prevent back-and-forth handover repetitions between adjacent cells (‘ping pong handover’), e.g. if a MS moves along a boundary between two cells. Different adjacent cells can be assigned different handover margins in order to control the handover flow.

HOMDOFF=0,

object: ADJC3G

unit: 1dB

range: 0..127

default: 0

Handover margin dynamic offset for 2G-3G speed sensitive handover. This parameter is only relevant if speed sensitive handover from GSM 2G to UMTS FDD neighbour cells (see parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS]) is enabled. It specifies the dynamic offset by which the 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 margin delay time for 2G-3G speed sensitive handover. This parameter is only relevant if speed sensitive handover from GSM 2G to UMTS FDD neighbour cells (see parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS]) is enabled. It specifies the time an immediate handover request is delayed when a power budget handover to a microcell is requested. General Principle of the speed sensitive handover algorithm: If the BTS detects a power budget handover condition for an UMTS FDD neighbour cell which is created with MICROCELL=TRUE (see below), the timer HOMDTIME is started: as long as this timer runs the handover margin (see parameter HOM) is artificially increased by a static offset (see parameter HOMSOFF). This ‘new’ handover margin is called HO_MARGIN_TIME(t) since its value is time dependent. If the basic power budget handover condition (i.e. PBGT > HOM) still exists when the timer expires, a dynamic offset (see parameter HOMDOFF) is subtracted from HO_MARGIN_TIME(t) again. Thus a speed sensitive handover condition is fulfilled if

PBGT > HO_MARGIN_TIME(t) where

HO_MARGIN_TIME(t) = HOM + HOMSOFF

for t ≤ HOMDTIME and

HO_MARGIN_TIME(n) = HOM + HOMSOFF - HOMDOFF for t > HOMDTIME

As long as the timer HOMDTIME runs the basic power budget handover condition is permanently checked; if the BTS detects that the basic power budget handover condition (i.e. PBGT > HOM) does not exist any more the timer is stopped and the handover is not executed.

For further details please refer to chapter ‘Appendix’, section ‘Handover Thresholds & Algorithms’ of this document. Note: The values should be set according to the rule:

HOMDOFF ≥ HOMSOFF.

HOMSOFF=0,

object: ADJC3G

unit: 1dB

range: 0..127

default: 0

Handover margin static offset for 2G-3G speed sensitive handover. This parameter is only relevant if speed sensitive handover from GSM to UMTS FDD neighbour cells (see parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS]) is enabled. It specifies the static offset by which the handover 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

Microcell flag for UMTS FDD neighbour cell, determines whether the adjacent cell is regarded as a ‘microcell’. Only if this parameter is set to TRUE the ‘speed sensitive handover’ algorithm will be in effect for this neighbour cell. Precondition: the database flag for speed sensitive handover is set to ‘enabled’ (SET HAND [BASICS]:DPBGTHO=TRUE).

PLNC=0,

object: ADJC3G

range: 0..15



default: 0

Priority layer of UMTS FDD neighbour cell, this parameter determines the priority layer of the adjacent UMTS FDD neighbour cell. The priority layer is relevant for the handover 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: ADJC3G

range: 0..15



default: 0

Penalty priority layer of UMTS FDD neighbour cell, this parameter is only relevant if speed sensitive handover from GSM to UMTS FDD neighbour cells (see parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS]) and ‘ranking of target cells on the basis of priority’ (see parameter HIERC in command SET HAND [BASICS]) is enabled. It determines the temporary priority layer of those adjacent UMTS FDD cells which are defined as microcells (see parameter MICROCELL). PPLNC is only evaluated by the ranking algorithm as long as the handover margin delay timer HOMDTIME is running. Its purpose is to to allow the operator to temporarily decrease the priority of the affected UMTS FDD neighbour 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 ≤ RSCP

default: 5

Reference:

Rx level minimum of UMTS FDD neighbour cell, this parameter determines the minimum received signal level (indicated as RSCP – Received Signal Code Power) from UMTS the adjacent cell must provide to be regarded as a suitable target cell for 2G-3G handover. It is the minimum Rx level required for a MS to perform a 2G-3G handover towards the UMTS FDD adjacent cell. This parameter is used in the handover pre-processing algorithm in the BTS which evaluates the measurement reports in order to determine the UMTS FDD target cells for 2G-3G handover (see parameter EUHO in command SET HAND [BASICS]). The selected value should correspond to the actual settings of the UMTS FDD Node B although both parameters are administered in different network elements and are thus independent from each other.

TINHFAIHO=7,

object: ADJC3G

unit: 1s

range: 1-254

default: 7

Timer to inhibit handover failure repetition for UMTS FDD neighbour cell, this parameter is only considered if the flag NOFREPHO (see SET HAND [BASICS]) is set to TRUE. It specifies the time period for which the BTS excludes a specific UMTS FDD adjacent cell from the target cell list when the threshold for the maximum allowed number of failed 2G-3G handovers (see parameter MAXFAILHO in command SET HAND [BASICS]) towards this particular adjacent cell has been reached. Rule: TINHFAIHO > THORQST(HAND) > T7 (SET BSC [TIMER])

TGTCELL=TGTFDD:0,

object: ADJC3G

format: path name of a created

TGTFDD object instance

UMTS FDD target cell, this attribute specifies the object instance path name of the database object that represents the basic data of the UMTS FDD or TDD neighbour cell. The neighbour cell creation concept for the ADJC3G objects is the same like for the ADJC objects (see CREATE ADJC): The TGTFDD/TGTTDD parameter always refers to an already created TGTFDD/TGTTDD object (see command CREATE TGTFDD)

TGTCELL=

external UMTS 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 from GSM to UMTS (see parameter EUBCHO in command SET HAND [BASICS]) to adjust the carrier level of the related UMTS FDD adjacent 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 minimum EcNo, this parameter defines the minimum level which is required to include an UMTS FDD cell into the handover target cell list in case of an ‘imperative’ handover (see parameter EUIMPHO in command SET HAND [BASICS]) from GSM to UMTS FDD when FDDREPQTY (see CREATE BTS [BASICS]) is set to the value 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 sufficient EcNo, this parameter defines the threshold above which BTS initiates a ‘sufficient coverage’ handover from GSM to UMTS 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 sufficient RSCP, this parameter defines the threshold above which BTS initiates a ‘sufficient coverage’ handover (see parameter EUSCHO in command from GSM to UMTS FDD when FDDREPQTY (see CREATE BTS [BASICS]) is set to the value RSCP.



Creating the CCS7 level 3 addresses of BSC, MSC and SMLC and basic SCCP

parameters for the SS7 connection:

CREATE OPC [BASICS]:

< This command defines basic CCS7 level 3 addresses and basic SCCP parameters.

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

NAME=opc:0, Object path name.

APLESSNBSC=250,

object: OPC [BASICS]

range: 15-255

default: 250

SCCP subsystem number of Application Part BSSAP-LE in BSC, this parameter defines the Subsystem Number for BSSAP-LE (Base Station System Application Part - LCS Extension) from the BSC point of view. SCCP subsystems are Application Parts of the SCCP (like e.g. BSSAP, MAPMSC, MAPHLR etc.), which have to be addressed by an own number within the SCCP addressing scheme. For the BSSAP-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 number of Application Part BSSAP-LE in SMLC, this parameter defines the Subsystem Number for BSSAP-LE (Base Station System Application Part - LCS Extension) from the SMLC (Serving Mobile Location Center) point of view. See also APLESSNBSC.

BSSAPSSN=254,


range: 15-255

default: 254

SCCP subsystem number of Application Part BSSAP in BSC, this parameter determines which SCCP subsystem number is used for the BSSAP. SCCP subsystems are Application Parts of the SCCP (like e.g. BSSAP, MAPMSC, MAPHLR etc.), which have to be addressed by an own number within the SCCP addressing scheme. For the BSSAP, the SSN is not fixed by the standard and can thus be selected by command.

MSCPERTFLAG=TRUE,


range: TRUE, FALSE

default: TRUE

Periodic signaling link test flag for SS7 connection to MSC, this flag determines whether the periodic signaling link test is enabled for the OPC-SPC relation or not. The signaling test procedure for the SS7 link is a CCS7 level 3 availability check of a remote SPC and is basically performed whenever a remote SPC (which has become unavailable due to failure of the SS7 link set) becomes available again after the SS7 link set recovery. The signaling test procedure consists of a SIGNALING LINK TEST MESSAGE (SLTM) which is sent from the BSC to the MSC which – in the positive case – answers with the SIGNALING TEST ACKNOWLEDGE (SLTA) message. If PERTFLAG is set to TRUE, the signaling test procedure is periodically performed for the OPC-SPC relation. The time period between the transmission of 2 SLTMs is determined by the timer M3T2TM, the supervision timer for the receipt of the SLTA is the timer M3T1TM (see command SET OPC [MTL3] for further details).

MSCSPC=48-144,


range: see above (OPC)

Signaling 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 SPCs are valid for. The network indicator is an SS7 level 3 address supplement and is always sent together with the SPC in the level 3 component of an SS7 message. Within one network, normally all network elements are addressed with one unique SPC valid for NAT0. The other possible values are normally used for network transitions.

OPC=219-48,


range:

Network Cluster Member

0..255 (CCITT)

1-255 (ANSI)

Network Cluster

0..63 (CCITT)

0..255 (ANSI)

Network Identifier

NO_CONFIG (CCITT)

1-254 (ANSI)

Own Signaling Point Code, identifies the SPC of the BSC. Up to BR4.0 the value of the SPC had to be in entered in decimal format, from BR4.5 on the value of the SPC must be in entered in the format “NetwokClusterMember – NetworkCluster – NetworkIndetifier”. For CCITT the conversion from decimal format to the new format is done in the following way: Convert decimal value to Hex, the 2 least significant digits (converted to decimal) make up the ‘Network Cluster Member’, the 2 most significant bits make up the ‘Network Cluster’.

Example: SPC = 12507dec = 30DBhex DBhex = 219dec = NetworkClusterMember value 30hex = 48dec = NetworkCluster value Result: 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 - 011 SPC = 11000011011011 (binary format) SPC = 12507 (decimal format)

SMLCPERTFLAG=TRUE,


range: TRUE, FALSE

default: TRUE

Periodic signaling link test flag for SS7 connection to SMLC, this flag determines whether the periodic signaling link test is enabled for the BSC-SMLC CCS7 connection or not. For further details please see parameter MSCPERTFLAG.

Attention: The Signaling link Test Procedure is only used for the SS7 relation between BSC and SMLC if the SS7 link is created for link set LKSET=1, i.e. if theSS7 connection between BSC and SMLC is realized via a nailed-up connection (NUC) in the MSC. For further details please refer to the parameter LKSET in command CREATE SS7L.

SMLCSPC=32-112,


range: see above (OPC)

Signaling 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 by the SS7.

TCONN=3,


unit: 5s

range: 0..255

default: 3

Timer for CC, this timer determines the waiting time for the CONNECTION CONFIRM. The CONNECTION CONFIRM is the response to the CONNECTION REQUEST, which is used to set up a logical SCCP dialog using so-called ‘local references’ on the A-interface. Such a ‘local reference’ connection is set up for every transaction (call, SMS-transmission, Location Update etc.). The timer TCONN is started when the BSC transmits the CONNECTION REQUEST to the MSC. If it expires, the BSC regards the SCCP local reference connection request as unsuccessful and releases the associated context.



TGUARD=36,


unit: 5s

range: 0..255

default: 36

(= recommeded value !)

Guard timer for adjacent Signaling Point accessability, this parameter is used to supervise the duration of the adjacent signaling point (SP) inaccessibility. This situation occurs if all SS7 links towards the MSC have failed. TGUARD sets the waiting time to resume normal procedures for temporary connection sections (i.e. the local reference SCCP and BSSMAP contexts that are set up for each dedicated signaling transaction) during the restart procedure. TGUARD is started when the adjacent signaling point (e.g. the MSC) becomes inaccessible due to failure of all available SS7 links. This means that TGUARD is started when the last SS7link goes down (SS7S object goes to ‘disabled’ state) and it is stopped when the first link is completely aligned again. If a link interruption is shorter than TGUARD (i.e. at least one SS7 link has successfully completed the re-alignment), busy CICs will not be released, i.e. existing speech connections will be saved and no RESET message will be sent on the A-interface. If the duration of a total CCS7 link interruption exceeds the time defined by TGUARD, the existing speech connections will be released and after the link realignment a RESET message will be sent on the A-interface. To save existing calls for a defined period of SS7-link interruption the timer values at the BSC and MSC should be equal.

As mentioned above, the BSC starts TGUARD when the last SS7 link goes down, i.e. when the SS7 link set (SS7S) has gone to ‘disabled’ state. As long as TGUARD runs the BSC discards all received CHANNEL REQUIRED messages, i.e. it does not activate any SDCCH and does not answer them by any IMMEDIATE ASSIGNMENT message. In this period, when the MS has performed MAXRETR+1 RACH access attempts without response from the network it performs a cell reselection. In addition, the MS also increases an internal counter which is increased on every new RACH access attempt. If the counter reaches a defined threshold, the MS performs a complete network reselection (PLMN reselection). When TGUARD has expired (long interruption) the BSC only accepts and serves new CHANNEL REQUIRED messages when the first SS7 link set has returned to service and when the GLOBAL RESET procedure is completed.

Notes: - TGUARD must be set according to the following rule: TGUARD > ALARMT2 (CREATE LICD) + TSBS This setting is necessary in order to avoid A-interface reset (and thus call release) procedures even if the link interruption is very short. For TSBS please see below. - In order to avoid the loss of existing calls in case of a TDPC switch or a BSMS switch (which causes an initialization of the SS7-link) TGUARD has to be set to a value bigger than 30 seconds. A recommended value is 50s. - The equivalent of this timer in the SIEMENS MSC are the following timers: a) in MSC configurations with SSNC HW (new CCS7 HW): Parameter ‘SPAP STFS Timer’ (Signaling Point Short Time Failure Timer) which is administered with the MSC command MOD SPAPLOC (SPAPLOC = SCCP Access Point Local). b) in configurations with (old) CCNC HW: Parameter SPSTFT (Signaling Point Short Time Failure Timer) which is administered with the MSC command ENTR SCSSSD.

The affected timer (depending on the used CCS7 HW) is started when the remote SP becomes unavailable. As long as the timer runs, the calls are maintained. SPSTFT stopped, when the remote SP becomes available again. If it expires, the MSC releases all calls to



the affected SP (which is in this case the BSC) and performs a BSSMAP RESET procedure when the SS7 connection has returned to service. Both SPAP STFS Timer and SPSTFT are set in units of 10s an unfortunately their default is ‘0’ (zero). Interworking tests have established that it is recommended to equally set TGUARD and SPAP STFS Timer (respectively SPSTFT) to 180s: TGUARD=36 (BSC) and SPAP STFS Timer =18 (MSC).

TIAR=180,


unit: 5s

range: 0..255

default: 180


Inactivity test receive timer, this timer is used to supervise the activity on an SCCP local reference connection by the INACTIVITY TEST mechanism. The SCCP connection is released if there are no inactivity test messages received within the TIAR interval. TIAR is started when the BSC sends an inactivity test message to the MSC. If TIAR expires (i.e. no inactivity test message has been received from the MSC) the BSC sends a BSSMAP RESET CIRCUIT to the MSC. The RESET CIRCUIT message leads to the clearing of the SCCP local reference connection and thus to the release of the associated call. The same timer with the same functionality also exists in the MSC. Note: The following rule should be considered:

TIAR (of the receiving entity) ι 2∗TIAS (of the sending entity)

Important: Please see also the parameter description for TIAS!

TIAS=96,


unit: 5s

range: 0..255

default: 96


Inactivity test send timer, this timer determines the periodicity of the sending of INACTIVITY TEST messages (IT) on an SCCP local reference connection section. The INACTIVITY TEST messages are used to create a kind of 'keep alive' activity on the SCCP local reference connection in time periods without call signaling activity. The same timer (and mechanism) also exists in the MSC. TIAS is restarted whenever the BSC has received an SCCP message for an existing SCCP local reference connection. When it expires (i.e. when no SCCP message has been received during the TIAS runtime), the BSC sends an INACTIVITY TEST to the MSC and TIAS is restarted. Every expiry of TIAS triggers the transmission of another INACTIVITY TEST message. On the MSC side an Inactivity Test Receive Timer (see TIAR) observes the receipt of the INACTIVITY TEST messages. Notes: - Basically the following rule must be considered:

TIAR (of the receiving entity) > 2∗TIAS (of the sending entity)

- After a TDPC switch the timers TIAS and TIAR are reset to ‘0’. Under certain conditions it may happen that no INACTIVITY TEST message is sent towards the MSC for more than 2 times of the TIAS interval. In order to prevent the MSC from releasing the SCCP connections the Inactivity Test Receive Timer of the MSC should be more than 2 times (better 3 times) as big as the TIAS value of the BSC. - In the Siemens MSC the Inactivity Test Send timer (i.e. the equivalent to TIAS) is called T118 (default value = 7 min) and the Inactivity Test Receive Timer (i.e. the equivalent to TIAR) is called T119 (default value = 15 min). Both timers are administered with the command MOD TIOUT.

TINT=36,


unit: 5s

range: 0..255

default: 36

TINT, wait to report the abnormal release to the maintenance function.



TREL=20,


unit: 0,5s

range: 0..255

default: 20

Release timer, this timer determines the waiting time for RELEASE COMPLETE message. The RELEASE COMPLETE is the confirmation message for the RELEASED message which is sent if an SCCP connection is cleared down. The timer TREL is started when the BSC transmits the RELEASED message to the MSC (this message is used to release the dedicated local reference connection which is set up for every call transaction). If it expires, the BSC releases the associated context without the receipt of the RELEASE COMPLETE..

TSBS=60,


unit: 0,5s

range: 0..255

default: 60

State information timer. This timer is started by the BSC if after an interruption of the CCS7 link the lower layers have come up again. On expiry of this timer the BSC sends the SST (SCCP Subsystem Test) 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 the MSC). The same mechanism is used in the MSC. If the BSC receives the SST from the MSC before expiry of TSBS it answers with SSA and 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 thus call release) procedures even if the link interruption is very short.

- The equivalent of this timer in the SIEMENS MSC are the following timers: a) in MSC configurations with SSNC HW (new CCS7 HW): Parameter ‘SCCP STFS Timer’ (SCCP Short Time Failure Timer) which is administered with the MSC command MOD SPAPLOC (SPAPLOC = SCCP Access Point Local). b) in configurations with (old) CCNC HW: Parameter SSSTFT (SCCP Subsystem Short Time Failure Timer) which is administered with the MSC command ENTR SCSSSD.

The affected timer (depending on the used CCS7 HW) is started when the remote SCCP subsystem (i.e. the BSSAP) becomes unavailable. As long as the timer runs, the calls are maintained. The SCCP STFS Timer (resp. SPSTFT) is stopped, when the remote SCCP subsystem becomes available again. If it expires, the MSC releases all calls to the affected entity (which is in this case the BSC) and performs a BSSMAP RESET procedure when the SS7 connection has returned to service. Both SCCP STFS Timer and SSSTFT are set in units of 10s an unfortunately their default is ‘0’ (zero). Interworking tests have established that a recommended is to set the SCCP STFS Timer (resp. SPSTFT) to 180s: SCCP STFS Timer (resp. SPSTFT) = 18 (MSC).

TWCUSER=20,


unit: 0,5s

range: 0..255

default: 20

TWCUSER, manufacturer dependent timer.



Setting the timer values for CCS7 MTP level 2:

SET OPC [MTL2]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘OPC packages’ were moved below the object OPC and appear in the DBAEM in the CREATE OPC command. The logical group “[MTL2]” is normally only used on the LMT but was used here to 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 the detection 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 protection mechanism which orders transmitted level 2 frames by sequence numbers and buffers them for retransmission, if the receipt of the transmitted frame was not positively acknowledged from the remote end (i.e. from the MSC or the SMLC). The SS7 level 2 transmit buffers are physically located in the SS7 level 2 boards, i.e. in the PPCC or the PPXL. The BSC continuously observes the utilization percentage of the available transmit buffers and compares it to the thresholds that are mapped to the CONGTH value in accordance with the 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’ with cause value ‘SS7 Tx buffer congestion’ is raised. When the Tx buffer utilization drops below the threshold defined by the ‘abatment’ value, the alarm is ceased.

When the Tx buffer utilization exceeds the threshold defined by the ‘discard’ value, level 2 functions start to randomly discard level 2 frames.

The value CONGTH=0 means that the check on SS7 TX buffer congestion is disabled and the mentioned overload condition is detected 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 correction method, this parameter determines the layer-2 error correction principle used on the SS7 links. - The Basic Error Correction method is normally used on all terrestrial CCS7 links. It uses layer 2 acknowledgement mechanisms (based on forward sequence numbers, backward sequence numbers and indicator bits for positive or negative acknowledgements) to decide whether a CCS7 layer 2 frame was correctly received and to request a retransmission if a frame was not correctly received.

- The Preventive Cyclic Retransmission Error Correction method must be used if the A interface link or the Asub interface link is configured as satellite link (see also SET BSC [BASICS], parameters ASUBISAT and AISAT). As the name suggests, the 'Preventive Cyclic Retransmission Error Correction' method uses a preventive cyclic retransmission mechanism, i.e. sent messages are cyclically retransmitted without waiting for an acknowledgement from the partner side. Especially for satellite links this method makes sense as - due to the high delay on satellite links - the waiting times for layer 2 acknowledgements are too long to allow a useful use of the basic error correction method.

FLOWCTH=3,

object: OPC [MTL2]

unit: 1%

range: 0..9

default: 3

Flow control threshold, this parameter determines a threshold for the observation of the CCS7 receive buffer utilization. The BSC continuously observes the utilization percentage of the available SS7 receive buffers and compares it to the thresholds that are mapped to the FLOWCTH value in accordance with the table below:

FLOWCTH value onset abatment

0 = =

1 60 50

2 65 50

3 (default) 70 50

4 50 40

5 55 40

6 60 40

7 55 45

8 60 45

9 65 45

When the SS7 RX buffer utilization exceeds the ‘onset’ threshold, an LSSU message indicating ‘busy’ (LSSU-SIB) is cyclically sent to the remote end. The sending frequency of this message is determined by the parameter M2T5 (see below).

When the SS7 RX buffer utilization exceeds the ‘abatment’ threshold, the sending of LSSU ‘busy’ messages to the remote end is stopped.

Note: The observation of the SS7 transmit buffers is performed based on thresholds defined by parameter CONGTH (see above). As opposed to the SS7 Tx buffer congestion detection based on CONGTH, no alarms are generated in case of SS7 Rx buffer congestion (detected using parameter FLOWCTH).

M2T1=450,

object: OPC [MTL2]

unit: 100ms

range: CCITT: 400..500

ANSI: 129-160

default: CCITT: 450

ANSI: 140

M2T1, ‘alignment ready’ timer, known as T1_timer_id in the CCITT blue book.



M2T2=100,

object: OPC [MTL2]

unit: 100ms


ANSI: 50..300

default: CCITT: 1000

ANSI: 120

recommended value : 100

M2T2, ‘not aligned’ timer, known as T2_timer_id in the CCITT blue book.

Attention: With the introduction of the BR7.0 PPXL patch Y1340005 the listed default values are no longer valid. In fact, the value must be set 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: 5

ANSI: 6

M2T4E, emergency proving period timer, known as T4e timer in the CCITT/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 the CCITT/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 blue book.

Please see also parameter FLOWCTH (see above).

M2T6=60,

object: OPC [MTL2]

unit: 100ms


ANSI: 10..60

default: CCITT: 60

ANSI: 50

M2T6, remote congestion timer, known as T6_timer_id in the CCITT blue book.

M2T7=20,

object: OPC [MTL2]

unit: 100ms

range: CCITT: 5-20

ANSI: 5-20

default: CCITT: 20

ANSI: 10

M2T7, excessive delay of acknowledgement timer, known as T7_timer_id in the CCITT blue book.

N1 =110,

object: OPC [MTL2]

range: 100..127

default: 110

Maximum number of MSU available for retransmission, this parameter determines the maximum number of SS7 message signal units (MSU), that can be buffered for retransmission.



N2 =3000,

object: OPC [MTL2]

range: 2000..4000

default: 3000

Maximum number of MSU octets available for retransmission, this parameter determines the maximum number SS7 MSU octets that can be buffered for retransmission.

SANTIME=10,

object: OPC [MTL2]

range: 0..255

0 = timer disabled

default: 10

Sanity timer, this parameter determines the value of the sanity timer used to control the level 2 processor (PPCC) outage. SANTIME represents a keep alive time between TDPC and PPCC. If this timer is set to 0 (disabled), no “keep-alive” is performed. If SANTIME is set to a value different from 0, the PPCC expect a keep alive message within this time frame. If the PPCC does not receive it, a LOCAL PROCESSOR OUTAGE (LPO) is sent on layer 2 to the remote end (i.e. the MSC) in order to stop the traffic. This timer does not affect the call processing activity, is just used to inform the MSC very fast in about failure of the layer 3 processor unit (i.e. the TDPC).

Setting the timer values for CCS7 MTP level 3:

SET OPC [MTL3]:

Attention: Since BR6.0 The DBAEM does not group the command parameters into ‘packages’ anymore. Instead, all parameters of the previous ‘OPC packages’ were moved below the object OPC and appear in the DBAEM in the CREATE OPC command. The logical group “[MTL3]” is normally only used on the LMT but was used here to 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), known as T1_timer in the CCITT blue book.

M3T10=60,

object: OPC [MTL3]

unit: 0,5 s

range: 60..120

default: 60

M3T10, this timer represents the waiting time to repeat the ROUTE SET TEST (RST) message. These messages are used by the CCS7 level 3 functions to periodically check the availability of CCS7 signaling routes.

General Background: Within the SSS, all SPCs are normally reachable via different “signaling routes”. These “signaling routes” are explicitly created in the CCS7 routing database for each relation of local SPC (OPC) and remote SPC and are represented by so-called “signaling link sets” to directly adjacent CCS7 signaling points (SP, i.e. network elements with CCS7 routing capability). If the adjacent signaling point represents the final target signaling point of the OPC-SPC relation, the adjacent signaling point is simultaneously the “Signaling End Point” (SEP). If the adjacent signaling point just represents an intermediate signaling point on the way to the destination SP, it works as a “Signaling Transfer Point (STP)”. The STP just checks the destination address of the CCS7 message and forwards the message to the correct SEP respectively another intermediate STP via a signaling route defined in its own routing tables.

Application in the BSC: The only application of a “signaling route” from point of view of the BSC is the CCS7 connection towards the SMLC (Serving Mobile Location Center). This connection can be configured either via a nailed-up connection (NUC) through the MSC or by configuring the MSC 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 in the command CREATE SS7L..

M3T12=12,

object: OPC [MTL3]

unit: 100ms

range: 8-15

default: CCITT: 12, ANSI: 10

M3T12, wait for UNINHIBIT acknowledgement, known as T12_timer in the CCITT blue book.

M3T13=8,

object: OPC [MTL3]

unit: 100ms

range: 8-15


M3T13, wait to force UNINHIBIT, known as T13_timer in the CCITT blue book.

M3T14=4,

object: OPC [MTL3]

unit: 100ms

range: 20..30


M3T14, wait for INHIBIT acknowledgement, known as T14_timer in the 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 as T17_timer in the CCITT blue book.

M3T19=9,

object: OPC [MTL3]

unit: 5s

range: 12-120

default: CCITT: 12

M3T19, Failed link craft referral timer, this timer is activated during the SS7L restoration phase and controls the disabled state of the SS7L. M3T19 was introduced to avoid a lot of SS7 ENABLE/DISABLE messages towards the RC. If the SS7 link interruption is less than M3T19, no notification is sent to the RC (in case of multiple link configurations with at least one link still working, no call handling is affected), if the interruption is longer than T19, the RC is informed and for call handling the behaviour is the same as before. Normally the expiry of M3T19 is caused by a layer 2 problem on the remote end. PCM interruptions or HW fault cause “ disable dependency “ on the SS7 link. In this case M3T19 is not started. Up to BR4.0 this timer was implemented in the system with hardcoded values.

M3T1TM=100,

object: OPC [MTL3]

unit: 100ms

range: 40..120

default: CCITT:100, ANSI:50

M3T1M, Supervision timer for SIGNALING LINK TEST ACKNOWLEDGMENT (SLTA) message. This timer controls the signaling link test procedure on the SS7 link (see parameter MSCPERTFLAG in command CREATE OPC [BASICS]). M3T1TM is started when the BSC transmits the SLTM to the BSC. If the SLTA is not received before expiry of M3T1TM the BSC restarts the test link procedure. If the M3T1TM expires for two consecutive times the SS7L restoration procedure is started. Up to BR4.0 this timer was implemented 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 the CCITT blue book.



M3T22OR20=36,

object: OPC [MTL3]

unit: 5s

range: CCITT: 36-72

ANSI: 18-24


M3T22OR20, Local INHIBIT test timer. This timer (T22 for CCITT or T20 for ANSI) controls the local INHIBIT test procedure. If the SS7L is local inhibited a local INHIBIT test is sent to the MSC every M3T22OR20 seconds. Up to BR4.0 this timer was called M3T22.

M3T23OR21=36,

object: OPC [MTL3]

unit: 5s

range: CCITT: 36-72

ANSI: 18-24


M3T23OR21, Remote INHIBIT test timer. This timer (T23 for CCITT or T21 for ANSI) controls the remote INHIBIT test procedure. If the SS7L is remote inhibited a remote INHIBIT test is sent to the MSC every M3T23OR21 time. Up to BR4.0 this timer was called M3T23.

M3T2TM=6,

object: OPC [MTL3]

unit: 5s

range: 6-18

default: CCITT: 6, ANSI:17

M3T2TM, timer for periodic sending of the signaling link test message (SLTM). This timer determines the time period between the transmission of 2 consecutive SLTMs during the periodic signaling link test procedure on the SS7 link (see parameter MSCPERTFLAG in command CREATE OPC [BASICS]). Whenever M3T2TM expires the BSC sends an SLTM to the MSC. Up to BR4.0 this timer was implemented 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 the CCITT blue book.

M3T4=8,

object: OPC [MTL3]

unit: 100ms

range: 5-12

default: 8

M3T4, wait for CB acknowledgement first attempt (CB = CHANGEBACK to original link after link failure or blocking end), known as T4_timer in the CCITT blue book.

M3T5=8,

object: OPC [MTL3]

unit: 100ms

range: 5-12

default: 8

M3T5, wait for CB acknowledgement second attempt, known as T5_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 different from <NULL>.

LKSET=0,

object: SS7L

range: 0, 1

Link set number, this parameter defines the link set number of the created SS7 link. A link set with LKSET=1 only has to be created if the signaling connection to the SMLC (Serving Mobile Location Center) is realized via a nailed-up connection (NUC) in the MSC. In this case link set 1 represents the object superordinate to the SS7L object created for the SMLC connection. The link set number determines the association of the created CCS7 link to one of the two possible link sets as illustrated in the following example diagrams

The example configuration 2 assumes that the MSC works as CCS7 Signaling Transfer Point (STP). As a precondition, the corresponding CCS7 routing tables must have been created in the MSC. For further hints please see also command CREATE OPC [BASICS].

SLC=0,

object: SS7L

range: 0..15

Signaling Link Code, defines the number of the link on the A interface.

TSLA=0..16,

object: SS7L

range: pcma-no.: 0..39


1-24 (PCM24)

Link on the A interface, pcma-no. - timeslot-no..

SMLC

LKSET=1

SS7L:2 BSSAP-LE signaling

SMLC<->BSC

LKSET=0

SS7L:0 SS7L:1 BSSAP

signaling

BSC<->MSC

MSC NUC

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:0 SS7L:1 BSSAP

signaling

BSC<->MSC and

BSSAP-LE

signaling

SMLC-BSC

MSC

CCS7 STP

routing

BSC

CCNC



Creating a Nailed-Up Connection through the BSC/TRAU:

< This command is used to create a permanently switched connection between two timeslots on PCM links connected to the BSS. These permanently connected timeslots can be located on a PCMA, a PCMS or a PCMB. Thus the SBS network elements BSC and TRAU can assume the function of a crossconnector (DXC). >

CREATE NUC:

NAME=nuc:0, Object path name.

FRTERM=PCMA:3-3,

object: NUC

format: <pcm-link>-<timeslot no.>

The ‘pcm-link’ is entered

by the object instance name

of the PCMA, PCMS or

PCMB object

range: pcm-link:

PCMA:0.. PCMA:79 or

PCMB:0.. PCMB:34 or

PCMS:0.. PCMS:19

timeslot-no.:

0..31 (for PCM30)

1-24 (for PCM24)

From terminal, determines the first timeslot to be interconnected by the nailed-up connection.

TOTERM=PCMB:4-17,

object: NUC

format: <pcm-link>-<timeslot no.>

The ‘pcm-link’ is entered

by the object instance name

of the PCMA, PCMS or

PCMB object

range: pcm-link:

PCMA:0.. PCMA:79 or

PCMB:0.. PCMB:34 or

PCMS:0.. PCMS:19

timeslot-no.:

0..31 (for PCM30)

1-24 (for PCM24)

To terminal, determines the second timeslot to be interconnected by the nailed-up connection.



Creating an X25 connection via dedicated link:

< Note: The objects X25D and X25A are mutually exclusive. i.e either an X25A is created or an X25D. >

CREATE X25D:

NAME=X25D:0,

Object path name. The range for the X25D-no. is 0..1.

BAUDRATE=BAUD_64000,

object: X25D

range: BAUD_4800, BAUD_9600,

BAUD_38400,

BAUD_64000

default: BAUD_64000

Baud rate of communication between RC and BSS. It is necessary with CLOCK=INTERNAL. If CLOCK=EXTERNAL the parameter is not relevant.

CLOCK=EXTERNAL,

object: X25D

range: INTERNAL,

EXTERNAL

default: EXTERNAL

Clock synchronizing modality, indicates if the IXLT internal clock is used or a external one.

DTEDCE=DTE,

object: X25D

range: DTE, DCE

default: DTE

Data terminal equipment/data communication equipment, determines whether the BSC is configured as DTE or as DCE.

L2WIN=7,

object: X25D

range: 1-7

default: 7

Layer 2 window 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 circuit number of 1st 2-way channel.

N2WC=6,

object: X25D

range: 0..4095

default: 6

Number of 2 way channels, this parameter is included in the X25A and X25D configuration message (IXLT restart).



R20=3,

object: X25D

range: 1-255

default: 3

Restart request retry count.

R22=3,

object: X25D

range: 1-255

default: 3

Reset request retry count.

R23=3,

object: X25D

range: 1-255

default: 3

Clear request retry count.

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

T21=2000,

object: X25D

unit: 100ms

range: 0..3000

default: 2000

Call request timeout.

T22=1800,

object: X25D

unit: 100ms

range: 0..3000

default: 1800

Reset request timeout.

T23=1800,

object: X25D

unit: 100ms

range: 0..3000

default: 1800

Clear request timeout.

T26=1800,

object: X25D

unit: 100ms

range: 0..3000

default: 1800

Interrupt request timeout.

T28=0,

object: X25D

unit: 100ms

range: 0..3000

default: 0

Registration request timeout.



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

Creating an X25 connection via A-interface:

< Note: The objects X25D and X25A are mutually exclusive. i.e either an X25A is created or an X25D >.

CREATE X25A:

NAME=X25A:0,

Object path name. The range for the X25A-no. is 0..1.

ACHAN=0..30,

object: X25A

range: pcma-no.: 0..79


1-24 (PCM24)

A interface channel, identifies the timeslot on the A interface used for the RC connection. Parameter format: pcma-no. - timeslot-no..

L2WIN=7,

object: X25A

range: 1-7

default: 7


L3PS=PACKET_2048,

object: X25A

range: PACKET_128, _256, _512,

_1024, _2048

default: PACKET_2048

Network layer packet size.

L3WIN=7,

object: X25A

range: 1-7

default: 7


LCN2WC=1,

object: X25A

range: 0..4095

default: 1

Line circuit number of 1st 2-way channel.

N2WC=,

object: X25A

range: 0..4095

default: 6

Number of 2 way channels, this parameter is included in the X25A and X25D configuration message (IXLT restart).



R20=3,

object: X25A

range: 1-255

default: 3

Restart request retry count.

R22=3,

object: X25A

range: 1-255

default: 3

Reset request retry count.

R23=3,

object: X25A

range: 1-255

default: 3

Clear request retry count.

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

T21=2000,

object: X25A

unit: 100ms

range: 0..3000

default: 2000

Call request timeout.

T22=1800,

object: X25A

unit: 100ms

range: 0..3000

default: 1800

Reset request timeout.

T23=1800,

object: X25A

unit: 100ms

range: 0..3000

default: 1800

Clear request timeout.

T26=1800,

object: X25A

unit: 100ms

range: 0..3000

default: 1800

Interrupt request timeout.

T28=0,

object: X25A

unit: 100ms

range: 0..3000

default: 0

Registration request timeout.



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

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 type, indicates whether the X25 link is realized via dedicated link (X25D) or via an A-interface channel (X25A).

OMCCPT=60,

object: OMAL

range: 1..60

default: 60

OMC capability timer, this parameter represents the time period of the reachability test performed by RC on the "cold standby" OMAL.

X121ADDR="514501",

object: OMAL

range: numeric string

(max.33 characters)

in quotation marks

X121 address, determines the remote X121 address used in the X25 network.



Creating the link for the external connection to the SMS-CB system:

CREATE CBCL:

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

LINKTYPE=X25D,

object: CBCL

range: X25A, X25D

default: X25D

X25 link type, 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 address, determines the remote X121 address used in the X25 network.

Defining the BSC reference synchronization clock origin:

CREATE SYNC: < SYNC = synchronization clock >

NAME=sync:0, Object path name.

PCMSOBJ=0,

object: SYNC

range: 0..19

PCMS object, identifies the number of the PCMS link from which the reference clock signal is retrieved.

Defining an external synchronization signal:

< It is possible to synchronize the GERAN BSS from a synchronization network, e.g. from GPS system. The command CREATE SYNE is used to create an external synchronization source which may be connected to the BSC clock by the operator. The external synchronization source has higher priority than SYNC synchronization source. The external synchronization signal is directly connected to one of the two external input accesses of the PLLH card, which is represented by the W26 connector on the top of the BSC rack, which is a SUB-D 15 female connector provided for synchronization purposes.The connection shall be performed according device configuration by coaxial or balanced lines between position W26 and the Installation Site termination. The synchronization signal is recommended in ITU-T G703, chapter 13. Before the external synchronization signal can be used, the SYNE 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 signalling transactions of any call (MOC, MTC) or a short message transfer (SMS-MO, SMS-MT) performed by a specific subscriber (represented by his IMSI). This feature is foreseen for a limited number of



subscribers to be traced and has to be activated in the MSC for specific IMSIs (up to 7 subscribers can be traced at the same time within one BSC). If a particular problem appears in an network-area (e.g. subscribers complain about the quality in a specific network area) IMSI tracing might be started for the IMSI of the affected subscriber or a tester may travel through this area performing test calls with a test SIM card while IMSI tracing is active. Specific commands have to be entered in the SIEMENS MSC to activate the feature generally (MOD MSERVREL and MOD MSERVOPT) and for a specific IMSI (ACT IMSITRAC). In the BSC, the feature is generally activated by the CREATE TRACE command. As a result, if an MS with the IMSI under test performs any call transaction, the MSC instructs the BSC to start the recording of the call events (using the BSSMAP message MSC INVOKE TRACE). The BSC sends the RSL Abis message START TRACE to the BTS which starts the sending of the up- and downlink measurements measured during the call by the MS and the BTS in form of the so-called TRACE MEASUREMENT RESULTS. The operator is informed about the trace start by an appropriate 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 on the BSC disk (see command SET BSC SET BSC [CONTROL], parameter IMSIFSIZ). At the end of the call, the BSC and the BTS stop the trace data collection and the BSC informs the RC/LMT using the ‘StoppedTraceNotification’. The trace file is compressed and automatically uploaded to the RC. In the RC, the file is decompressed and converted to ASCII format. Thus the ASCII trace file, which contains all messages and events related to the traced call, transaction is ready for analysis.

Note: With respect to the number of simultaneous traces manageable by the BSC also the feature ‘Cell Traffic Recording’ has to be considered. The maximum number of simultaneous (IMSI and CTR) traces is restricted to 16. The difference between IMSI tracing and the CTR feature is that IMSI tracing is IMSI related (resp. subscriber related) while CTR is cell related. For further details please refer to the descriptions provided for the command CREATE CTRSCHED. >

CREATE TRACE:

NAME=trace:0, Object path name.

RECCRI=NO_CRITERIA,

range: NO_CRITERIA

Record criteria, describes the criteria in which the traces are collected by the BSC.



Creating a Cell Traffic Recording (CTR) job:

<The feature Cell Traffic Recording (CTR) is introduced in addition to the IMSI Trace (see command CREATE TRACE), to better monitor the system’s behaviour and the quality of service. CTR traces a definable number of calls within a specified cell, so it is, in contrast to the feature IMSI Tracing, resource (cell) related. Furthermore, CTR is locally performed in the BSS, i.e. neither a trace invocation is received from the MSC nor is the MSC informed about any cell tracing activities. The purpose of CTR is to collect call trace data in such a way that they can be chronologically aligned to the existing cell specific event- and quality-of-service related system data such as performance measurements and alarm files. Thus CTR allows the operator to simultaneously observe the system's behaviour and its immediate effects on calls within the cell. This could be necessary if subscriber complaints or PM data point to problems in a specific cell or if a newly installed cell is to be observed for correct behaviour. Basically the contents of a CTR trace is exactly the same as the one for an IMSI trace. However, the CTR files only start recording the events 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 the signalling transactions in the target cell for a defined ‘trace handover persistence time’ which is fixed to 10 sec.. In the other cases the recording is stopped on call termination (normal or abnormal), in case of 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]) from where they are compressed and automatically uploaded to the RC. In the RC the files are converted to ASCII so that they are ready for analysis. >

CREATE CTRSCHED:

NAME=CTRCO:0/ CTRSCHED:0,

Object path name. The CTR control object (CTRCO) assumes the state 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’ the BSC cannot start CTR any trace activities due to abnormal conditions (e.g. overload). Administrative state: The OMT/LMT operator is able to stop all the trace sessions on a BSC through the setting of the administrative state to 'locked'. The ‘shutting down’ value for the administrative state means that the current connection traces in the cell is finished, but no new connections are traced. When all active traces are terminated the administrative state automatically changes to ‘locked’ value. Usage state: The usage state of the CTR Control object reports the information 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 trace sessions (maximum 16 per BSC) has been reached and no more tracing sessions are possible. As for tracing sessions there is no difference between IMSI and CTR Trace, the ‘busy’ state does not mean that all the active tracing sessions are CTR traces.

Note: Also the CTRSCHED object can be locked. In this case the CTR 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 BTS object that represents the cell to be traced in the CTRSCHED object.

MACONN=16,

range: 1-16

Maximum number of connections, this parameter determines the maximum number of connections to be traced within the cell. Note: The overall maximum number of traced connections (IMSI and CTR traces) is restricted to 16. IMSI tracing always has precedence over CTR. The maximum number of IMSI traces is limited to 7. This means that, if MACONN is set to a bigger value than 9 while IMSI tracing is active, ongoing CTR traces will be stopped if the maximum number of simultaneous traces is reached and new IMSI trace invocations 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 the week, this parameter defines the periods during which the CTR trace activities should be active within a week by its start time and the trace duration. For every day of the week an appropriate period can be entered.

START=1-1-1992,

format: day - month - year

range: day: 1-31

month: 1-12

year: 1992 – 2099

default: 1-1-1992

Start date, this parameter defines the start date of the trace activities.

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 type, this parameter determines whether the trace file shall contain only the signalling messages only (MESSAGE) or whether it shall contain the uplink and downlink measurement results/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 severity, 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 string, represents a free-definable character string that shall be displayed in the alarm message.

ENVANAME=FIRE,

range: SMOKE

INTR

TX_EQ_MIN

TX_EQ_MAJ

TX_EQ_CRIT

POW_MIN

POW_MAJ

POW_CRIT

GEN_ALM_MIN

GEN_ALM_MAJ

DOOR_OPEN

FIRE

HEAT_EVENT

HUMIDITY

TEMPERATURE

Environmental alarm name, identifies the alarm type of the external alarm.

INTINF=HIGH,

range: LOW, HIGH

default: HIGH

interface logic, determines the interface logic of the alarm detection equipment, i.e. the value entered determines the case in which an alarm is to be raised.

THR=2,

unit: 1s

range: 0..65534

default: 2

error detection threshold, represents the error detection threshold in seconds.



Configuring the feature Online RF Loopback:

< The RFLOOP object is the database object that represents the feature “Online RF Loopback”.

Purpose of the feature “ Online RF Loopback “ This feature allows the operator to observe the complete RF signal path of a BTSE including the cabling and connectors by permanently monitoring the path loss difference between uplink and downlink – if the path loss difference between uplink and downlink exceeds a configurable threshold, the BTS outputs an alarm “Increased path loss difference“. The purpose of this feature is to significantly enhance the overall test coverage in addition to other alarming features such as “Sleeping Cell Detection” or “RX Diversity Alarm”. If the alarm “Increased path loss difference“ is output, the operator is made aware of some irregularities in the HF paths of the affected cell. Whether the problem is caused by a defective HW (such as CU, ECU, GCU, DUAMCO etc. (for BTSplus) or TPU, PA etc. (for BTSone)), can be established by a test (from the RC) on the affected boards: if the test fails, the affected HW must be replaced, if no faulty HW board can be identified, an on-site check of the HF cabling is recommended.

Functional Description of Measurement & Calculation Process

The downlink path loss is calculated as follows:

PLDL = BSPOWERANT - RXLEV_DL

where: RXLEV_DL = RX signal measured by MS in DL and reported in the MEASUREMENT REPORT messages

BSPOWERANT = 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 cabling depending 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

CU TMA

TMA

BSPOWERANT

RXLEV_ULANT

TXLEVADJ set by operator

RXLEVADJ set by operator

cable

cable

CU Output Power

RXLEV_DL

MEAS REP

XXCOM / DxAMCO *

UL RXLEV at ANT Input of DxAMCO



The uplink path loss is calculated as follows:

PLUL = MSPOWER – RXLEV_ULANT

where: MSPOWER = current uplink transmit power confirmed by the MS

RXLEV_ULANT = 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 the following commands:

RXLEVADJ: CREATE/ SET TPU, CREATE/SET CU TXLEVADJ: CREATE/SET BBSIG, CREATE/SET CU, CREATE/SET CA

BTSE Parameter RXLEVADJ The purpose of the parameter RXLEVADJ is to correct the uplink RXLEV value (RXLEV_UL) measured at the DUAMCO input if the gain resp. attenuation deviates from standard values (Note: the signal is physically measured in the CU but the CU measurement automatically considers the DUAMCO gain). This can happen either due to the use of third-vendor (i.e. non-SIEMENS-specified) TMAs or extremely long feeder cables. As the GSM standard requires that the RXLEV_UL values that are to be used for the Power Control and Handover decision shall refer to the antenna port (and not to the DUAMCO input), the value measured at the DUAMCO input has to be corrected in correspondence with the actual gain or loss of the receive 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 when the gain between BTS antenna port and DUAMCO input is about: 19 dB for GSM900 and GSM850 and 21 dB for DCS1800 and PCS1900.

This gain figure will be maintained in a pure Siemens system with and without (Siemens-)TMA by setting the DUAMCO gain appropriately (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. This difference is normally used to compensate the higher losses caused by the longer feeder cable, that connects the TMA (at the top of the tower) to the BTSE rack.

In these cases, with a pure Siemens configuration and no excessive feeder cable loss with the RXLEVADJ parameter should set to default value RXLEVADJ=0dB. Only in case of deviating configurations the parameter RXLEVADJ must be set in correspondence 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. These 10dB are added to the measured RXLEV_UL at the DUAMCO input and are used by the BTS measurement processing procedures. Thus the Power Control and Handover decision is based on the RXLEV_UL values at the antenna port. In the opposite direction if a third-vendor TMA is used which offers a gain 10dB higher than the Siemens TMA, this gain must be considered by setting RXLEVADJ=-10dB.

ATTENTION: Please consider that a change of the RXLEVADJ value has an impact on the Power Control and Handover decision process! This means that the handover performance measurements will show different results if RXLEVADJ is



changed! As a correct setting of RXLEVADJ is obligatory for the proper operation of the RF LOOPBACK feature, this has to considered when the feature is configured for the first time.

In the same way, the uplink RF configuration and RXLEVADJC setting has an impact on the Idle TCH Measurements (see parameter INTCLASS in command SET BTS [INTERF])

BTSE Parameter TXLEVADJ The purpose of the parameter TXLEVADJ is to consider non-standard gains or losses in the calculation for the BTS transmit power at the antenna port (BSPOWERANT) as explained above. As opposed to the parameter RXLEVADJ, TXLEVADJ has no other impact.

The value range of TXLEVADJC is -63dB ..+63dB in 1dB steps.

Functional Description of Feature Management

The RFLOOP data is processed for each TX/RX pair.

• The BTS accumulates and calculates the data for every 30..minute block, and at the end of each block the BTS checks - the number of calls that were handled - the number of MEASUREMENT REPORTs processed in the 30..minute period.

• Only if the number of calls handled exceeds the threshold MINCCNT (see below) and the number of MEASUREMENT REPORTs exceeds the threshold (MECNT), the BTS calculates the mean path loss difference for that particular period.

• The alarm “Increased path loss difference” is output if the calculated absolute average value exceeds the upper alarm threshold ALTH (see below), i.e. if the following condition

PLdiff (averaged absolute) > ALTH

where PLdiff (averaged absolute) = | ΣΣΣΣ1-n (PLUL – PLDL) | / n

• The alarm is ceased when at the end of a subsequent 30..minutes period the calculated path loss difference has dropped below the lower alarm threshold, which is ALTH - BANDOFHYS.

• The alarm is also ceased when the RFLOOP measurement is locked.

Note: The feature “ Online RF Loopback “ does not work if baseband frequency hopping (see HOPMODE=BBHOP in command SET BTS [OPTIONS]) is configured. The implementation of baseband frequency hopping shows the following difference regarding the two BTSE generations, i.e. BTS1 and BTSplus: - In the BTS1 baseband hopping is realized by multiplexing different TPUs to one BBSIG. The TX and RX paths are tied together by switching TX & RX at the same time;

- The BTSplus implementation is different to the BTS1. Here baseband hopping is exclusively used in downlink direction whereas in uplink direction always synthesizer hopping is applied. Downlink data is pre-processed in the TRX related CU, but the burst data is then sent via the CU whose carrier frequency is equal to that of the currently calculated burst. Thus, for a call, a single RX path is used with multiple TX paths; so there are as many TX/RX pairings for the call as the number of transmitters in use.

Since the mobile reports the measured RXLEV_DL values with a fixed period of 480ms (= 104TDMA bursts), no mapping is possible on TDMA burst base for the DL measurements. Due to the averaging effect this means that failures in the RF-TX signal path which are located in carrier specific parts may not be reliably detected in case baseband hopping is applied (both for BTS1 and BTSplus). In fact, the MS will report an RXLEV_DL value which is the average of levels



received from different RF-TX equipment (and so from different paths). On the other side, in uplink direction the BTSE knows which RX path is used per received burst.

CREATE RFLOOP:

NAME=btsm:0/bts:0/rfloop:0, Object path name.

ALTH=30,

unit: 1dB

range: 14..100dB

default: 30

Alarm threshold, this parameter defines the upper alarm threshold for the alarm “Increased path loss difference”.

For further details please refer to the descriptions provided at the top of the command description.

AUTOREP=FALSE,

range: TRUE, FALSE

default: FALSE

Auto report, this parameter allows to the user to enable or disable the automatic file upload. This operation can be activated for no more than 20 cells.

BANDOFHYS=25,

unit: 1dB

range: 1..100dB

default: 25

Bandwidth of hysteresis, this parameter defines hysteresis value, which is used to calculate the lower alarm threshold for the ceasing of the alarm “Increased path loss difference”. The value of this parameter must be lower than the ALTH parameter value.


MECNT=200,

range: 100..1000

default: 200

Measurement count, this parameter defines the minimum number of measurement samples (taken in a 30..minutes observation period) required for the path loss calculation.


MINCCNT=50,

range: 20..250

default: 50

Minimum call count, this parameter defines the minimum number of calls handled (within a 30..minutes observation period) required for the path loss calculation.


RXLV=10,

range: 1..62

default: 10

RX level, this parameter defines how many measurement samples values 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 collection activities.

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 collection activities.



Creating Smart Carrier Allocation:

< SCA (Smart Carrier Allocation) provides histograms of frequency based measurements and elaborates them to determine a list of ranked frequencies. This list then indicates the best substitute for a frequency that is being tested e.g. for a microcell or to be used in case of interference. The resulting reduction of interference achieved here offers benefits especially for micro cellular and pico cellular layers. The SCA object allows performing up to three new types of measures (Normal Measure, Busy Cumulative Measure and Extended Idle Channel Measure). The operator can choose those kind of measure types he wants to trace and also the list of frequencies to put under observation; for the Busy Cumulative Measures, the frequencies list is not required. >

CREATE SCA:

NAME=btsm:0/bts:0/sca:0, Object path name.

ATIME1=(6-0)-(23-59),

format: startHour-startMinute

stopTime-stopMinute

range: startHour/stop Hour: 6..23

startMinute/stopMinute:0..59

range: startHour: 6

startMinute: 0

stop Hour: 23

stopMinute: 59

Accumulation time 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, the accumulation time periods must not have intersections.

Each parameter consists of two fields: startTime (startHour - startMinute) and stopTime (stopHour - stopMinute).

4 parameters (ATIME1..ATIME4) are provided.

ATIME2..ATIME4 Accumulation time 2 .. accumulation time 4, see ATIME1.

BAND=30,

range: P, E, DCS, GSM_R,PCS,

GSM850

Frequency band, this parameter defines the band of frequencies observed by a SCA instance.

EBUSYCUM=FALSE,

range: TRUE, FALSE

default: FALSE

Enable busy cumulative measurements, this parameter enables or disables the busy cumulative measurements.

EEICM=FALSE,

range: TRUE, FALSE

default: FALSE

Enable extended idle channel measurements, this parameter enables or disables the extended idle channel measurements.

EICNF1=103,

range: 0..1023

Extended Idle Channel Measurements Frequency 1, this parameter defines a frequency for Extended Idle Channel Measurements observation.

32 parameters (EINCF1..EINCF32) are provided.

EICNF2..EICNF32 Extended Idle Channel Measurements Frequency 2 .. Extended Idle Channel Measurements Frequency 32, see EINCNF1.

ENDML=FALSE,

range: TRUE, FALSE

default: FALSE

Enable normal measurements, this parameter enables or disables the normal measurements.



NMDLATT1=104-3-5,

format: bcchFrequency-

netColorCode-

bsColorCode

range: bcchFrequency: 0..1023

netColorCode: 0..7

bsColorCode: 0..7

<NULL>

Normal measurements attributes 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 measurements attributes 2 .. Normal measurements

attributes 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 collection activities.

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 collection activities.



2 Appendix

2.1 Handover Thresholds & Algorithms

2.1.1 Functional Diagram Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and power budget)

XX=UL : Uplink

Bit-Error-Rate (RXQual)

Level (RXLev)

Handover

L_RXLev_XX_H L_RXLev_XX_IH

L_RXQual_XX_H

Inter-cell handover due to power budget /

Traffic Handover

Inter-cell handover due to level

made by: Gunther Döhler

HOLTHQUXX

HOLTHLVTXX HOTXXINT

XX=DL : Downlink XX=UL : Uplink

Inter-cell handover due to quality (if skip flag=TRUE or if INTRACH=FALSE)

Intra-cell handover due to quality (if skip flag=FALSE)

Inter-cell handover due to quality (skip flag not evaluated)

Note: For clearness reasons, Fast Uplink Handover was not included in this diagram.

Abbreviations: RXLEV = receive level of serving cell RXQUAL = bit error rate of serving cell

GSM Parameter Name

DB parameter Name (SET HAND [BASICS])

Meaning

L_RXLev_DL_H HOLTHLVDL lower threshold value for level handover downlink

L_RXLev_UL_H HOLTHLVUL lower threshold value for level handover uplink

L_RXLev_DL_IH HOTDLINT threshold value for intra BTS handover downlink

L_RXLev_UL_IH HOTULINT threshold value for intra BTS handover uplink

L_RXQual_DL_H HOLTHQUDL lower threshold value for quality handover downlink

L_RXQual_UL_H HOLTHQUUL lower threshold value for quality handover uplink



2.1.2 Rules: Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and power budget), Power Control disabled

General Remark: The following explanations are a supplement to the diagrams shown in the previous section. The purpose of both the diagrams and the written rules is to illustrate the interaction between the different handover types depending of different level and quality conditions. Please be aware that the listed rules 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 value set 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 where MS_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 class or 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 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 the INTERCELL HANDOVER CONDITION INDICATION with cause ‘uplink strength’ or ‘downlink strength’ if it fulfils 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 the minimum 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 following additional 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 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)



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 set for the neighbour cell



Target Cell Ranking

All target cells that fulfil the handover minimum condition (4.) are included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘uplink strength’ or ‘downlink strength’, 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 in descending order of

PBGT(n) – HO_MARGIN(n)

PBGT (n) = power budget of the neighbour cell (n) HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) in [dB]

Inter-cell HCI: target cell list

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 the handover margin used for power budget handover. For more detailed information about PBGT(n) please refer 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 more details 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

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


→→→→ The received quality (i.e. bit error rate) average of the serving cell is higher than the value set for HOLTHQUXX

Note: For AMR calls, the RXQUAL threshold HOLTHQUXX is replaced by the C/I [dB] threshold HOLTHQAMRXX. Thus for AMR calls, the handover decision is not based on the comparison of measured RXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived from measured RXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (1.) must be expressed as follows:

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 the parameter 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)* (the averaging is done according to the setting of HOAVELEV (SET HAND))

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 the measured value (like e.g. for the PBGT HO) but it takes the current RXLEV value as measured by the BTS resp. the MS. This means that, if Power Control is enabled, the intracell handover due to quality is only triggered, when the PWRC algorithm has increased the power in such a way, that the condition (2.) is fulfilled! In other words, PWRC does not have to adjust the power to the maximum to allow this handover to be triggered, but it must have increased the power to a level higher than HOTDLINT resp. HOTULINT, before this type of handover is triggered! - If INTRACH=FALSE, i.e. if the intra-cell handover is disabled in the BSC database, the threshold HOTXXINT is not evaluated and the conditions which normally cause an intra-cell handover directly lead to an 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 available for the for the intracell handover or if the access to the target TCH fails due to radio reasons), the subsequent 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 FALSE for 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 TRUE for the used TCH. If the handover is successfully completed the TCH is released and the skip flag has no relevance anymore. However, if the call remains on the same TCH (which means that the handover attempt could not be successfully completed) and another quality handover decision is made while the skip flag is TRUE, the BTS triggers an Inter-cell handover (quality).

General Note: The intra-cell handover in concentric cells (inner-complete and complete-inner) and for extended cells (near-to-far and far-to-near) are not considered in this context. For details on these types of intra-cell handover please refer to the diagrams 'Handover Parameter Relations' and the associated parameter 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

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


→→→→ The received quality (i.e. bit error rate) average of the serving cell is higher than the value set for HOLTHQUXX

Note: For AMR calls, the RXQUAL threshold HOLTHQUXX is replaced by the C/I [dB] threshold HOLTHQAMRXX. Thus for AMR calls, the handover decision is not based on the comparison of measured RXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived from measured RXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (1.) must be expressed as follows:

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

RXLEV_XX = received level average of the serving cell (the averaging is done according to the setting of HOAVELEV (SET HAND))

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] where MS_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 class or 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 the INTERCELL HANDOVER CONDITION INDICATION with cause ‘uplink quality’ or ‘downlink quality’ if it fulfils the handover minimum condition








→→→→ 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 (4.) are included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘uplink quality’ or ‘downlink quality’, 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 standard cells) 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 the INTERCELL HANDOVER CONDITION INDICATION with cause ‘distance’ if it fulfils the handover minimum condition











Target Cell Ranking

All target cells that fulfil the handover minimum condition (2.) are included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘distance’, unless the number of target cells is restricted by the parameter NCELL (see SET HAND).





1. neighbour cell





. . .

. . .





2.1.2.5 Inter-cell Handover (power budget)


The SBS handover algorithm performs the handover decision for imperative handovers (Level HO, Quality HO, Distance HO) always before a decision for a power budget handover is made. Assuming that no imperative handover has to be performed beforehand an inter-cell handover (power budget) is triggered if one or more neighbour cells are found which fulfil the condition

1. PBGT(n) > HO_MARGIN(n)



HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) in [dB]



PWR_C_D = BS_TXPWR_MAX - BS_TXPWR = averaged difference between the maximum downlink RF power and the 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 set for 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 with special care as - depending on the bands of the serving and neighbouring cells - the PBGT can assume a positive 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 cell border), 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 the INTERCELL HANDOVER CONDITION INDICATION with cause ‘better cell’ if it fulfils the handover minimum condition









Target Cell Ranking

All target cells that fulfil the handover minimum condition (2.) and the power budget condition (1.) are included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘better cell’, unless the number of target cells is restricted by the parameter NCELL (see SET HAND).





1. neighbour cell





. . .

. . .

This means that the ranking algorithm considers the DL receive level of the neighbour cell as well as the handover margin used for power budget handover.




2.1.2.5.1 Speed sensitive handover enabled

Precondition: speed sensitive handover is enabled for the cell (SET HAND:DPBGTHO=TRUE;).

For those neighbour cells for which speed sensitive handover is enabled (CREATE ADJC:MICROCELL=TRUE) the HOM value is increased by the value entered for HOMSOFF for the duration of 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 ≤ HOMDTIME HO_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 fulfilled and 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 intervention are not triggered by the BTS but by the BSC when specific forced handover conditions are met. The BSC triggers the handover by sending a FORCED HANDOVER REQUEST to the BTS which in turn determines the suitable target cells for the handover transaction and inserts them into the target cell list of the INTERCELL 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 the INTERCELL HANDOVER CONDITION INDICATION with cause ‘forced’ if it fulfils the handover minimum condition 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 of minimum receive level set for the neighbour cell and the correction term Max(0,Pa) plus the 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 power level drops below the THLEVFULHO while the PWRC algorithm has already reduced the UL transmit power, the fast uplink handover is triggered without waiting for the Power Control algorithm to adjust the power to the maximum!


A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the INTERCELL HANDOVER CONDITION INDICATION with cause ‘fast uplink’ if it fulfils the handover minimum condition enhanced by an additional fast uplink handover offset

2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + FULRXLVMOFF(n)




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 the minimum receive level set for the neighbour cell, the correction term Max(0,Pa) and the fast 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 mechanism creates two sublists in the INTERCELL HANDOVER CONDITION INDICATION: the predefined cells make up the upper sublist, the non-predefined cells are placed into the lower sublist. Within each sublist the cells are sorted in descending order of PBGT(n)-HO_MARGIN(n) (HO_MARGIN = HOM in ADJC package).


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 decision algorithm, i.e. the BTS only triggers a traffic handover after all other handover types have been evaluated before. Assuming that no imperative handover has to be performed beforehand an inter-cell handover due to traffic 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 and the 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 effective traffic handover margin 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 with some term definitions to avoid confusion about the used terms:

1) Administrable traffic handover margin The administrable traffic handover margin corresponds to the value in [dB] entered for the parameter TRFHOM (ADJC object).

→→→→ administrable traffic handover margin = HO_MARGIN_TRAF(n) = TRFHOM(n), value in [dB]

Note: This administrable traffic handover margin is never actually used by the traffic handover decision algorithm in its pure form.

2) Effective traffic handover margin The effective traffic handover margin is the reduced, time-dependent traffic handover margin which is actually used by the traffic handover decision algorithm as it considers the administrable traffic handover margin as well as the reduction term:

→→→→ effective traffic handover margin = HO_MARGIN_TRAF_TIME(n)

= HO_MARGIN_TRAF(n) – K

→→→→ effective traffic handover margin = HO_MARGIN_TRAF(n) – m*TRFMS

3) Initial traffic handover margin The initial traffic handover margin is the value of the effective traffic handover margin in the first traffic handover 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 TRFHOT This phase starts immediately after the receipt of the ‘traffic handover enabled’ message (SET ATT) from the from the BSC and triggers the following steps in the BTS:

• TRFHOT is started for the first time.

• The internal counter ‘m’ changes its value from m=0 to m=1.

• The traffic handover decision algorithm is started considering the initial traffic handover margin

This means that in this first decision phase the condition (2.) is defined as follows:

2.(1) PBGT(n) > HO_MARGIN_TRAF(n) - TRFMS

This means that, if for an ongoing call a neighbour cell is found, whose PBGT is higher than the initial traffic handover margin, the handover due to traffic is triggered.

Traffic Handover Decision Phase 2: Traffic handover enabled, period after first expiry of TRFHOT When TRFHOT expires and the traffic handover is still enabled ( i.e. no ‘traffic handover disabled’ message was 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 margin with m=2.


2.(2) PBGT(n) > HO_MARGIN_TRAF(n) – 2*TRFMS

This means that, if for an ongoing call a neighbour cell is found, whose PBGT is higher than the initial traffic handover margin reduced by TRFMS, the handover due to traffic is triggered for that call.

Traffic Handover Decision Phase n: Traffic handover enabled, period after (n-1) expiries of TRFHOT With 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 by TRFMS (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 reduction TRFMMA (see SET HAND)!

Final Traffic Handover Decision Phase – traffic handover enabled, maximum margin reduction reached The reduction of the effective traffic handover margin is restricted to TRFMMA (see SET HAND). This means that, 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 margin with m=2.


2.(final) PBGT(n) > HO_MARGIN_TRAF(n) – mmax*TRFMS (mmax = TRFMMA div TRFMS)

This means that, if for an ongoing call a neighbour cell is found, whose PBGT is higher than the minimum traffic 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 the BSC while the traffic handover decision process (and the TRFHOT cycle) is running, the BTS performs the following 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:

time zone

TRFHOT

first expiry of TRFHOT

Traffic HO enabled indication received from BSC


second expiry of TRFHOT

Start of second traffic HO decision phase with reduced traffic HO margin Traffic HO Margin = TRFHOM - 2*TRFMS

Start of first traffic HO decision phase with Initial traffic HO margin Traffic HO Margin = TRFHOM - 1*TRFMS

third expiry of TRFHOT

If n*TRFMS has reached TRFMMA and traffic HO remains enabled, the traffic HO margin reduction remains stable (=TRFMMA) for all subsequent expiries of TRFHOT.

Start of third traffic HO decision phase with reduced traffic HO margin Traffic HO Margin = TRFHOM - 3*TRFMS

Principle of the traffic handover margin reduction mechanism when traffic

handover is enabled:

time zone

TRFHOT

expiry of TRFHOT

Traffic HO disabled indication received from BSC


expiry of TRFHOT



expiry of TRFHOT

If the traffic HO remains disabled, and the traffic HO margin reaches the initial value TRFHOM – 1*TRFMS, the handover decision process is stopped on the next expiry of TRFHOT.

Principle of the traffic handover margin increase mechanism when traffic handover is disabled:




A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the INTERCELL HANDOVER CONDITION INDICATION with cause ‘traffic’ if it fulfils the handover minimum condition

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)






Target Cell Ranking

All target cells that fulfil the handover minimum condition (2.) and the traffic handover power budget condition (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 (see SET HAND).





1. neighbour cell





. . .

. . .


If the feature Hierarchical Cell Structure is enabled (HIERC=TRUE, see SET HAND), it is possible to restrict traffic 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 priority level 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 a decision for a power budget handover is made. Assuming that no imperative handover has to be performed beforehand an inter-cell handover (power budget) is performed if all of the following conditions are fulfilled:

A) A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the HANDOVER CONDITION INDICATION if

1. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)

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 > 0 Max(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 cell PWR_C_D = BS_TXPWR_MAX - BS_TXPWR = averaged difference between the maximum downlink RF power and the 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]


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 ordered according to their priority (not according to their level).

priority Inter-cell HCI: target cell list

0 1. neighbour cell

2. neighbour cell

3. neighbour cell

4. 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 in the command CREATE ADJC and to section 2.1.2.5.1 (Power Budget Handover / Speed sensitive handover).

.



2.2.2 Cell ranking for imperative handovers (due to level, quality and distance) 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 Uplink Handover. For Fast Uplink Handover the standard target cell ranking can be influenced by the parameter FULHOC (see CREATE ADJC), which is not coupled to HCS.

2.2.2.1 Ranking method 0

If the cell ranking method RANK 0 (SET HAND:HIERF=RANK0;) is in effect for imperative handovers (i.e. handovers due to level, quality or distance) the cell ranking is done in the following way:

A) A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the HANDOVER CONDITION INDICATION if the following conditions are fulfilled:

for imperative handovers

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)

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 > 0

Max(0,Pa) = 0 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)

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] 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 INDICATION are 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 cell PWR_C_D = BS_TXPWR_MAX - BS_TXPWR = averaged difference between the maximum downlink RF power and the 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]


3. Within each sublist the cells in the target cell list HANDOVER CONDITION INDICATION are ordered according to their priority.



0 1. neighbour cell

upper sublist: 2. neighbour cell

PBGT - HO_MARGIN > 0 3. neighbour cell

. . .

15 . . .

0 n. neighbour cell

lower sublist: n+1. neighbour cell

PBGT - HO_MARGIN ≤≤≤≤ 0 n+2. neighbour cell

. . .

15 . . .

Attention: The lower the value of the parameter PLNC, the higher the priority level! 0 = highest priority level, 15 = lowest priority level.



2.2.2.2 Ranking method 1

If the cell ranking method RANK 1 (SET HAND:HIERF=RANK1;) is in effect for imperative handovers (i.e. handovers due to level, quality or distance) the cell ranking is done in the following way:

A) A neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the HANDOVER CONDITION INDICATION if the following conditions are fulfilled:

for imperative handovers (handover due to level, quality and distance)

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa)

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 > 0


for forced handover (directed retry)

RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0,Pa) + FHO_RXLEV_MIN_OFFSET(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] 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 INDICATION are 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 > 0 Max(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 ordered according to their priority.



upper sublist: 0 1. neighbour cell

RXLEV_NCELL(n) > 2. neighbour cell

RXLEVMIN(n) + Max(0,Pa) 3. neighbour cell

+ LEVONC(n) 4. neighbour cell

15 5. neighbour cell

lower sublist: 0 . . .

RXLEV_NCELL(n) ≤≤≤≤ . . .

RXLEVMIN(n) + Max(0,Pa) . . .

+ LEVONC(n) . . .

15 . . .




2.2.3 Target Cell Ranking for Traffic Handover with HCS

As without HCS enabled, the target cells included in the INTERCELL HANDOVER CONDITION INDICATION are sorted in descending order of




If the feature Hierarchical Cell Structure is enabled (HIERC=TRUE, see SET HAND) basically all target cells that fulfil the handover minimum condition (2.) and the traffic handover power budget condition (1.) and that have an equal or higher priority level (parameter PLNC, see CREATE ADJC) like the serving cell (parameter PL, see SET HAND) are included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause ‘traffic’, unless the number of target cells is restricted by the parameter NCELL (see SET HAND).

Thus, to be included in the traffic handover target cell list (with HCS enabled) a neighbour cell must in any case 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 same priority 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 equal or 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 priority level (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 uplink

U_RXQual_DL_P UPTQUAD power control upper quality threshold downlink

U_RXQual_UL_P UPTQUAU power control upper quality threshold uplink

Bit-Error-Rate (RXQual)

Level (RXLev)

L_RXQual_XX_P

U_RXQual_XX_P

L_RXLev_XX_P L_RXLev_XX_P + 2(db)*Pow-Red-Step-Size

U_RXLev_XX_P

Power Increase

Power-Control

LOWTQUAX

UPTQUAX

UPTLEVX LOWTLEVX

LOWTLEVX +

PWREDSS

X=D : Downlink

X=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

RXLEV_XX = received level average of the serving cell (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

RXQUAL_XX = received quality (i.e. bit error rate) average of the serving cell (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] threshold LOWTQUAMRXX. Thus for AMR calls, the power control decision is not based on the comparison of measured RXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived from measured RXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (2.) must be expressed 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 the parameter 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 value set for LOWTLEVX and 2 times the value set for PWREDSS

1b. RXQUAL_XX < U_RXQUAL_XX_P 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 PAVRQUAL (SET PWRC))

U_RXQUAL_XX_P = UPTQUAX (SET PWRC) = power control upper quality threshold

→→→→ The received quality average of the serving cell is lower than the value set for UPTQUAX

Note: For AMR calls, the RXQUAL threshold UPTQUAX is replaced by the C/I [dB] threshold UPTQUAMRXX. Thus for AMR calls, the power control decision is not based on the comparison of measured RXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived from measured RXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (2.) must be expressed 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 the parameter 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

RXQUAL_XX = received quality (i.e. bit error rate) average of the serving cell

(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 lower than the value set for LOWTQUAX Note: For AMR calls, the RXQUAL threshold LOWTQUAX is replaced by the C/I [dB] threshold LOWTQUAMRXX. Thus for AMR calls, the power control decision is not based on the comparison of measured RXQUAL values to an RXQUAL threshold, but on a comparison of C/I [dB] values (derived from measured RXQUAL values) to a set C/I [dB] threshold. Thus for AMR calls, the condition (2.) must be expressed 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 the parameter 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 current radio conditions. As indicated in the previous sections, power control can be triggered a) due to specific RX level conditions: if the current RXLEV is too low, PWRC will increase the transmit power to ensure a proper receive level on the receiving side and to prevent call drops b) due to specific RX quality conditions: if the current RXQUAL value is too high (i.e. the corresponding C/I value is too low), PWRC will increase the transmit power to ensure a proper receive quality on the receiving side 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 as possible to minimize interference on the radio interface.

Starting from BR7.0, the operator can choose two types of Power Control: ‘CLASSIC’ or ‘ADAPTIVE’. These two power control types can be enabled separately for MS power control and BS power control in a particular cell.

For the parameters EBSPWRC and EMSPWRC the possible values are CLASSIC, ADAPTIVE and DISABLED.

2.3.3.2 Classic Power Control decision process

Classic power control is in effect if the settings EBSPWRC=CLASSIC respectively EMSPWRC=CLASSIC are 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 time difference between two consecutive power control increase or decrease steps defined by the parameter PCONINT (for BS power control only; for MS power control the time difference between two consecutive power 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 / 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)

ATTENTION! please be aware that in this diagram the y-axis (RXQUAL and C/I values) are the other way round than in the diagram shown in section 2.2.1!

RXLEV

up_qual

low_qua

0 / 30

7 / 0

0 63 up_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 the settings EBSPWRC=ADAPTIVE respectively EMSPWRC=ADAPTIVE are applied. This type of power control allows a faster power increase (and also faster power reduction) under specific radio conditions. The step size for the power increase is in this case not defined by a static respectively semipermanent database setting but it is calculated on the basis of the configured power control level thresholds and the currently measured 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 or high RXLEV values - in this scenario the bad quality is most probably caused by interference) is the same as

in case of the classic power control. Only exception: the power control delay timer is not defined by the parameter PCONINT but by the parameter PAVRQUAL (see section 2.2.3.4, Functional sequence of a power 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 RXLEV

values) is exactly the same as in case of the classic power control. In quadrant 3, the difference is, that the power decrease will take place very fast, as the power control delay timer (defined by PAVRQUAL) is not applied in this quadrant.

Power Control in quadrant 6 In quadrant no. 6, as opposed to classic power control, no power decrease is applied in case of adaptive power control, as the quality values are only in medium but not good figures.

RXLEV

up_qual

low_qua

0 / 30

7 / 0

0 63 up_lev

1

a

2 3

4 5 6

7 9

b

PWREDSS

+

+ +

0 0

- - 0

low_lev

+

+

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 bad quality 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 this case 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 the upper and lower PWRC level thresholds on the one hand and the current RXLEV value on the other hand.

Fast power increase 2 (quadrants 1 and 4) Quadrant 1 and 4 represent a less critical radio situation: low RXLEV values but medium or good quality values: In this scenario the medium/good quality is most probably possible due to excellent interference conditions (very low interference). In this situation, adaptive power control applies a less drastic type of fast power increase (B+), as the quality 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 received downlink 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 internal power control confirmation signalling takes place) and the BTS starts the delay timer for power control decisions (time to pass between two consecutive power control steps) and suspends the BS power control decision process (the insertion of measurement samples into the averaging window continues, but no power control decision is made).

Attention: Depending on the power control type (classic or adaptive) the ‘delay timer’ is based on different database parameters:

• 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 window for RXQUAL values (parameter PAVRQUAL).

Moreover, in case of adaptive power control (BSPRWC=ADAPTIVE), the delay timer is only applied if a power change decision was made due to quality reasons (quadrants 2b, 8 and 9). In all other quadrants the delay timer between two consecutive power control steps is not applied. As a result, in these 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 current REXLEV_DL and RXQUAL_DL conditions suggest it, the power control decision process may suggest another 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 ‘power control confirmation’ signalling procedure, which (compared to the BS power control process) considerably slows 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 measured uplink 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 1 header 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 signalled in form of the power level values defined by GSM as shown in the power levels tables for the parameters MSTXPMAXDCS, 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) and suspends the power control decision process (the insertion of measurement samples into the averaging window 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 its power at a range of one power level step (2dB) every 60ms. The change is in effect at the first TDMA frame belonging 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 SACCH period (end of SACCH period 2).

Attention: In case of adaptive power control it can happen that the power increase step ordered by the BTS is bigger than the increase step the MS can execute within one SACCH period. In this case the MS confirms only 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 the BTS as the MS always needs some time for the ‘ramp up’. To avoid another immediate power increase command from the BTS (which is in this case in fact not useful as the MS simply did not have enough time to execute the ordered power increase step), the power control decision process is suspended for another additional SACCH period if the power increase step size was greater than 4dB (this is achieved by an ‘artificial’ delay of the MS power confirmation by 1 SACCH period).

4) When the BTS has received the power confirmation from the MS in the MEASUREMENT REPORT (SACCH period 3), the BTS starts the delay timer for power control decisions (time to pass between two consecutive power control steps). As long as this delay timer runs, the BS power control decision process remains still suspended.

Attention: Depending on the power control type (classic or adaptive) the ‘delay timer’ is based on different database 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 window for RXQUAL values (parameter PAVRQUAL).

5) When the ‘delay timer’ expires, the BTS resumes the PWRC decision process. When the waiting timer for the power confirmation from the MS (parameter PWRCONF) has expired without receipt of a power confirmation that confirms that the requested power command was actually executed, the BTS immediately resumes 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 a power change decision was made due to quality reasons (quadrants 2b, 8 and 9). In all other

quadrants the delay timer between two consecutive power control steps is not applied. As a result, in these 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 considerably longer than for BS power control, as, in case of MS power control, as described above, it takes a minimum of 3 SACCH periods (1 SACCH period = 480ms) for each power control step to receive a power control confirmation from the MS (one period for transmission of the power control command, one for the adjustment and 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 slower than BS power control.

A verification of the executed and confirmed MS and BS power control steps is possible by checking the MEASUREMENT RESULT / MEASUREMENT REPORT messages on the Abis, especially the Information Elements (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 change command 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 continuous RXQUAL 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 by the respective power level change as if they were already received with the changed power. For MS power control, new UL RXLEV samples in the averaging window will be corrected until the power change was confirmed 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, it might 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 a power 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) is corrected 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 the 10dB increase to all samples that are currently in the averaging window for RXLEV_UL samples. The increase of 10dB is also added to all new arriving measurement samples, as long as the MS has not yet confirmed the power change. If in the next power confirmation the MS only confirms less than the ordered increase step (increase of e.g. 6dB), the BTS corrects the subsequent last measurement sample (assuming a power confirmation interval of 4 SACCH periods, PWRCONF=2) by adding only half of the ordered power increase step (i.e. in this case 5dB).



2.3.3.7 Interaction of Power Control Measurement Preprocessing and Power Control Decision

Before the BTS makes a power control decision the received measurement samples are averaged in correspondence with the averaging window defined by the parameters PAVRLEV (for level averaging) and PAVRQUAL (for quality averaging). In addition, the averaged RXLEV (non-integer) value is rounded to the next integer value according to normal mathematic rounding principles (non-integer values < 0,5 are rounded 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 the basis of this comparison if a power control decision is scheduled (i.e. if the power control interval timer (if applied at all) has already expired).

Example: The following BS Power Control scenario may give an idea about what happens during the measurement preprocessing 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 table below 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 | 0 9 | 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 | 0 26 | 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 decision shows effect in the changed PL in the next measurement period and the DL reflects this change in the following measurement period.

• INT-CTR: the intervall counter, set after a PC decision from (2xPCONINT); once it counted down to 0 a new 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, Power Increase and Power Decrease

Note: for clearness reasons, Fast Uplink Handover was not included in this diagram.


GSM Parameter Name

DB parameter Name (SET HAND)

Meaning

L_RXLev_DL_H HOLTHLVDL lower threshold value for level handover downlink

L_RXLev_UL_H HOLTHLVUL lower threshold value for level handover uplink

L_RXLev_DL_IH HOTDLINT threshold value for intra BTS handover downlink

L_RXLev_UL_IH HOTULINT threshold value for intra BTS handover uplink

L_RXQual_DL_H HOLTHQUDL lower threshold value for quality handover downlink

L_RXQual_UL_H HOLTHQUUL lower threshold value for quality handover uplink

Bit-Error Rate(RxQual)

Level (RXLev)

Power-Control + Handover

L_RXQual_XX_H

L_RXQual_XX_P

L_RXLev_XX_P

L_RXLev_XX_H

U_RXLev_XX_P

U_RXQual_XX_P


LOWTQUAX

UPTQUAX

UPTLEVX LOWTLEVX

HOLTHLVXX

LOWTLEVX +

PWREDSS

Inter-cell handover

due to level

Inter-cell handover

due to power budget /

Traffic handover /

no Power Control

Inter-cell handover due to

quality (if skip flag=TRUE or

if INTRACH=FALSE)

Intra-cell handover

due to quality

(if skip flag=FALSE)

X=D : Downlink

X=U : Uplink

XX=DL: Downlink

XX=UL: Uplink

Power Budget HO / Traffic HO/

Power Decrease

L_RXLev_XX_P + 2(dB)*Pow-Red-Step-Size

Inter-cell handover

due to quality

(skip flag not evaluated)

Power Budget HO / Traffic HO /

Power Decrease

Power Budget HO / Traffic HO / Power Increase

HOTXXINT L_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 the diagram, 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 Power Control and Handover separately per so-called ‘service group’. This means that the power control and handover decisions can – optionally – be adapted to specific requirements of the different service types. The following 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 the SET HAND and SET PWRC command:

SET HAND: SG1HOPAR..SG14HOPAR

SET PWRC: SG1PCPAR..SG14PCPAR

These parameters are set to <NULL> by default, which means that no service-group specific handover or power control parameters are applied for the calls of the affected service group. If, however, service group specific settings shall be applied, the parameter values have to be entered in a specific number of fields.

Example: SET HAND: SG1HOPAR=10-10-35-35-26-32-5-5;

Each field epresents a specific parameter which is already known from the standard parameters’ list.

Example:

SG1HOPAR = 10 - 10 - 35 - 35 - 26 - 32 - 5 - 5 ; HOLTHLVDL HOLTHLVUL HOTDLINT HOTULINT HORXLVDLI HORXLVDLO HOLTHQUDL HOLTHQUUL

The number of fields and the meaning of the fields per SGxHOPAR resp. SGxPCPAR (i.e. which parameter a specific field represents) depends on the service group as not all parameters are valid for all service groups.



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 Attribute Range Service Group Set Description

HOLTHLVDL 0..63 1, 2, 3, 4 lower RXLEV HO threshold for DL

HOLTHLVUL 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 value structure 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-HOTHAMRCDL-HOTHAMRCUL

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-HOTHAMRDDL-HOTHAMRDUL



2.5.2.2 SGxPCPAR parameter values (Power Control)

The following parameters are represented by the SGxPCPAR fields:

PWRC Attribute Range Service Group Set 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 value structure 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


SGxPCPAR(x=7..10, data calls) = <field 1>-<field 2>..<field 12> = EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH


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 service group dependent power control and handover thresholds. To achieve this, the BSC determines the service group for each call and sends the service groups specific parameters to the BTS using the optional Information 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 Direct TCH Assignment) MODE MODIFY REQUEST, if service group specific settings were entered for the type of call currently processed. In other words, the IE “Service Group HO Settings” is only sent, if for the processed call’s service group specific HO thresholds were defined by the parameter SGxxHOPAR (SGxxHOPAR not equal to <NULL>) and the IE “Service Group PC Settings” is only sent, if for the processed call’s service group 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 Abis RSL 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 calls a) if the service group specific settings for handover and power control are changed manually by command or b) when the hopping status changes (i.e. hopping disabled or enabled manually (by command) or automatically (due to failure of a hopping TRX in case of Baseband Frequency Hopping). In the latter case, the CHANNEL CONFIGURATION CHANGE message contains the conditional IE ‘Starting Time’, which indicates 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 consider quality threshold values, whose values are not entered in RXQUAL values but in C/I (carrier/interference ratio in [dB], range 0..20) values. On the other hand, the MS and the BTS measure and classify the radio quality of the serving cell in RXQUAL values (range 0..7). The approach to consider C/I values for AMR calls was basically used to achieve a higher resolution of quality values for the AMR link adaptation (i.e. the adjustment of the data rate used for the call). The Power Control and Handover Decision due to quality, however, is still based on the RXQUAL values measured by MS 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 the entered C/I value in accordance with the table below. These C/I values are compared to the concerned PWRC and Handover thresholds, which are also entered as C/I values. Thus for AMR calls a more subtle distinction 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 19

0,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 coding schemes) 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:


In BR6.0, for AMR Half Rate (AMRHRC1..AMRHRC4) the following speech coding bit rates can be set:


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 RXQUAL measurement results reported by the MS) and selects a suitable AMR CODEC from the ACS depending on the 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 to Interference) thresholds.

For the AMR link adaptation downlink the thresholds and the associated hysteresis are administrable by the parameters AMRFRTH12..AMRFRTH34 (for AMR FR) and AMRHRTH12..AMRHRTH34 (for AMR HR).

For further details please refer to the description provided for the parameter AMRFRIC (see command SET BTS BASICS]).

For the AMR link adaptation in the uplink so-called reference thresholds for the transition between the possible CODEC modes are hardcoded. However, the effective thresholds are not fixed, but they are calculated for each call, depending on the used ACS and the value of the tuning parameter AMRLKAT (see command CREATE BTS [BASICS]). As a basis for this calculation, the BTS uses a table of ‘reference values’:

Threshold Reference Table

Codec (kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 4,00 3,50 5,00 5,50 5,00 6,50 7,50

5,15 9,50 - 3,00 5,00 5,50 5,00 6,50 8,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 lower CODEC bitrate to a higher one (e.g. from AMR FR 5,15 kbit/s -> AMR FR 7,4 kbit/s).

• The ‘lower threshold’ is the one which is must be exceeded for the uplink link adaptation from a higher CODEC bitrate to a lower one (e.g. from AMR FR 7,4 kbit/s -> AMR FR 5,15 kbit/s).

Thus correspondence to the administrable downlink link adaptation thresholds is the following:

- the ‘lower threshold’ corresponds to the value of the AMRFRCx value (x=1..4). - the ‘upper threshold’ corresponds to the AMRFRCx + hysteresis(AMRFRCx) value (x=1..4).

To illustrate the effect of AMRLKAT, the tables on the following pages show examples of different settings 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,66

6,7 14,33 14,89 15,45 - 8,00 6,90 8,56 10,76

7,4 14,89 16,01 17,13 17,13 - 4,15 9,11 11,86

7,95 16,01 16,57 17,69 17,69 18,70 - 11,31 12,96

10,2 - - - - - - - 12,41

12,2 - - - - - - - -

Upper threshold values for AMR FR link adaptation in [dB]

Upper threshold values for AMR HR link adaptation in [dB]

Lower Thresholds for AMRLKAT=0 (=-10dB)

Codec (kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 2,89 2,44 3,79 4,24 3,79 5,14 6,03

5,15 7,27 - 1,99 3,79 4,24 3,79 5,14 6,48

5,9 8,50 9,32 - 4,69 5,14 4,69 5,59 6,93

6,7 9,32 9,73 10,14 - 5,59 4,69 6,03 7,83

7,4 9,73 10,55 11,37 11,37 - 2,44 6,48 8,73

7,95 10,55 10,96 11,78 11,78 12,60 - 8,28 9,63

10,2 - - - - - - - 9,18

12,2 - - - - - - - -

Lower threshold values for AMR FR link adaptation in [dB]

Lower threshold values for AMR HR link adaptation in [dB]

Example:

AMRFRC1=RATE_01 (4,75 kbit/s), AMRFRC2= RATE_03 (5,90 kbit/s)

AMRFRTH12=6-2 (threshold=6dB, hysteresis=2dB)

a) AMR link adaptation downlink

link adaptation 4,75kbit/s -> 5,90 kbit/s (AMRFRC1 -> AMRFRC2) takes place when

C/I > AMRFRTH12 + hysteresis (AMRFRTH12) C/I > 8 dB

link adaptation 5,90 kbit/s -> 4,75 kbit/s (AMRFRC2 -> AMRFRC1) takes place when

C/I < AMRFRTH12 C/I < 6dB

b) AMR link adaptation uplink


C/I > upper threshold

C/I > 4,15 dB


C/I < lower threshold

C/I < 2,24 dB



AMRLKAT=100 (=0dB)

Upper Thresholds for AMRLKAT=100 (=0dB)

Codec (kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 5,80 5,25 6,90 7,45 6,90 8,56 9,66

5,15 12,65 - 4,70 6,90 7,45 6,90 8,56 10,21

5,9 14,33 15,45 - 8,00 8,56 8,00 9,11 10,76

6,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 > 5,25 dB



C/I < 3,34 dB



AMRLKAT=200 (=100dB)

Upper Thresholds for AMRLKAT=200 (=10dB)

Codec (kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 6,90 6,35 8,00 8,56 8,00 9,66 10,76

5,15 13,77 - 5,80 8,00 8,56 8,00 9,66 11,31

5,9 15,45 16,57 - 9,11 9,66 9,11 10,21 11,86

6,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 > 6,35 dB



C/I < 4,24 dB



2.8 Common BCCH Solution for mixed frequency bands within the complete area

The implementation of the feature ‘Common BCCH’ was modified in order to allow special requirements of the 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 the INNER area was supposed to be configured with the higher frequency band (i.e. with DCS1800, or PCS1900 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 area would be more or less automatically determined by the different propagation characteristics of the used frequency bands.

In the normal implementation there are database command checks that prevent the operator from mixing frequencies within the areas, i.e. it is not allowed to assign frequencies of the BCCH frequency band and non-BCCH frequency band to TRXs that belong to the same area (INNER or COMPLETE). The database command checks are in effect, if the SYSID Parameter (BTS object) is set to GSMDCS, GSM850PCS or GSM850DCS.

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 bands should provide exactly the same coverage area. Moreover, the main frequency band in the USA is PCS1900 and GSM850 should be used as extension band (in a similar way as E-GSM is used as extension band for GSM900).

In the scope of the change request CRX688 which was written and approved for this reason, one MPCC patch 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 database command checks allow configuration of both TRXs with frequencies of the BCCH frequency band and TRXs 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 totally removed).

• 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 the operator, not to create any TRX in the INNER area (CREATE TRX: TRXAREA=INNER). Instead, only TRXs with TRXAREA=COMPLETE should be created. Due to the disabled database command checks it is allowed to assign both GSM850 and PCS1900 frequencies to the COMPLETE area TRXs, although they belong to the same area.

• During call setup, the PREFERRED AREA REQUEST procedure is executed as normal. But, as there are 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, of course, allocates the best TCHs (considering the interference class) from the BCCH frequency band only. For MSs that support both bands, the BSC allocates the best TCH (considering the interference class), 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 idle TCHs) in the INNER AREA is empty, which is the same condition as if all TCHs of the INNER area were busy. 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 suspension of 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 cells the TCH allocation in separate areas (INNER or COMPLETE) as well as the complete-to-inner and inner-to-complete intracell handovers works as normal.

Modified implementation of the feature ‘Common BCCH’ for the US-Market and world market in BR7.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.0 does not allow it. In BR7.0 a command check is introduced, which prevents the operator from creating and INNER area TRX, if MNTBMASK=BIT24 is set. Vice versa, if an INNER area TRX was already created, 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 band and frequencies of the non-BCCH frequency band both in inner and complete area, in BR7.0 this mixture 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 is now 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. All transmitted SS7 messages are buffered until they are positively acknowledged by the remote end (i.e. the MSC, 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 SS7 links (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 a threshold 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 transaction registers. Each dedicated transaction, i.e. a transaction that requires a dedicated channel and a dedicated SCCP connection (MOC, MTC, SMS, incoming handover, location update etc.), occupies one level 3 register. The percentage value for the usage of these registers is calculated by dividing the number of currently used registers by the total number of registers available. If the calculated value exceeds 90%, the overload situation is detected.

3) The real time processor load of the telephony processor TDPC has exceeded a threshold set by the parameter OVLSTTHR.

Background: This kind of overload is only detected when the database flag BSCOVLH is set to TRUE! The TDPC processor real time processor load is periodically compared to the percentage threshold which administrable by the parameter OVLSTTHR (see command SET BSC [BASICS]). If this threshold is 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 as no longer present, if the TDPC processor real time load has dropped below the threshold administered by the parameter OVLENTHR (see command SET BSC [BASICS]).

4) A lack of TDPC memory resources is detected.

Background: This overload condition indicates a lack of physical memory available in the TDPC board. If the memory occupation of the TDPC exceeds a hardcoded threshold of 70%, the BSC starts overload handling to avoid memory corruptions. The BSC regards the overload condition as no longer present, if the TDPC memory usage has dropped below the same hardcoded threshold - oscillations are avoided using the timer 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 processor real time processor load is periodically compared to a threshold which is hardcoded to 70%. If this threshold is 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 as no 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 condition indicates a lack of physical memory available in the PPXX board. If the memory occupation of the PPXX exceeds a hardcoded threshold of 70%, the BSC starts overload handling (if BSCOVLH=TRUE) to avoid memory corruptions. The BSC regards the overload condition as no longer present, if the PPXX memory usage has dropped below the same hardcoded threshold - oscillations are avoided using the timer T18 (see section ‘Mechanisms for traffic reduction').



Category D: /* BSC Paging Queue Overflow */

7) An overflow occurs in the BSC paging queue.

Background: When the BSC receives PAGING messages from the MSC, it buffers them in a queue first, before it determines which BTSs belong to the affected LAC and delivers them towards the BTSs as PAGING COMMAND via the Abis LAPD channel(s) (LPDLR).

Starting from BR7.0/30 (since the implementation of CR2060), the BSC paging queue management was redesigned 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 from the 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 PAGING COMMAND messages to the BTSs) is adapted to the CCCH configuration (i.e. the number of CCCH blocks available for paging) of the affected cells. The ‘scheduling’ queues are not used for an additional buffering of the same paging messages but are only used to control the scheduled transmission of the PAGING 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 is parsed to identify the scheduling queues that are relevant for this paging (i.e. for this LAC). A buffer is allocated for every scheduling queue. These buffers contain a ‘link’ (resp. reference) to the original paging 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 the BTS in correspondence with the delivery rate applied in this scheduling queue), the paging is taken from the primary queue and sent to the involved BTSs as a PAGING COMMAND. When the paging has been sent to all the involved cells from all scheduling queues associated to this LAC (i.e. when the ’queuing timeout’ has expired for the slowest and shortest secondary delivery queue for this paging), it is removed from the primary queue.

Architecture and characteristics of the BSC paging queues Within the BSC the cells (BTSs) are grouped by LAC and number of paging blocks available (depending on the type of CCCH (MAINBCCH, MBCCHC or/and additional CCCH) and the setting of the parameter NBLKACGR (see command SET BTS [CCCH]). The maximum number of configurable LAC is restricted to 20, the number of paging blocks possible are 9 (cells with number of paging blocks greater than 8 are handled all together in the fastest delivery rate). Thus the number of possible delivery rates is limited to ‘9’. A paging scheduler mechanism is implemented which allows the generation of the theoretical maximum of 180 different ‘scheduling’ paging queues (20 LACs * 9 delivery rates).

The theoretical maximum number of buffered pagings is restricted to a little less than 360 (in releases before BR70/20 the total number of pagings that could be buffered in the BSC overall was restricted to 40). The expression ‘a little less than 360’ is used because 360 is the maximum number of internal buffers that can be used both a) 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 queue depends on the variety of different combinations of LAC and CCCH configuration (and thus the resulting number 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) is configured in the BSC (which will never happen in any real-life-BSC!), a number of 180 buffers is reserved for the scheduling queues. Consequently, the remaining number of buffer places for storage of PAGING message 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 rates per LAC is used, then the number of buffer places reserved for the scheduling queue is 2 LAC * 2 delivery rates = 4 buffers. Consequently, the remaining number of buffer places for storage of PAGING message in the primary queue is 360-4=354



The resulting paging delivery rates (PAGING COMMAND sent from BSC to BTS) are set in the following way:

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 ms 5 paging block are available 1/26.6 ms 1/17.5 ms 6 paging block are available 1/22.5 ms 1/15.0 ms 7 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/45.0 ms when 3 paging block are available 1/33.3 ms when 4 paging block are available 1/30.0 ms when 5 paging block are available 1/27.5 ms when 6 paging block are available 1/25.0 ms when 7 paging block are available 1/22.5 ms when 8 paging block are available 1/20.0 ms when >8 paging block are available

* The '1/<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 4 paging blocks | 30 | 44 5 paging blocks | 40 | 57 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 the CCCH configuration / paging delivery rate as indicated in the table above. The length threshold (the lower the delivery rate, the less queue places are available) is applied to avoid that the ‘buffer time’ for the pagings gets too long. This is necessary because the MSC, when it does not receive a PAGING RESPONSE to the first transmitted PAGING, repeats the paging procedure after a few seconds (the repetition time is defined by a 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) in SBS 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 was applied in order to avoid unnecessary buffer congestion situations in the BTS). However, due to the fact that the new paging delivery rate (1 paging/15ms) is valid per delivery queue and thus per LAC, the resulting paging delivery rate for the entire BSC can be, if more than one LAC is configured, considerably higher.



Functional sequence of a CS paging delivery When a paging arrives from A interface, it is analyzed in order to identify the queues involved in the delivery of that paging. In detail, the "Cell Identifier List" Information Element (IE) is analyzed to identify the type of paging that was received.

a) If the “Cell Identifier List" IE contains

- a RACODE (can happen if a CS paging is received from the Gb interface) or - a Location Area Code (LAC) only or - a Location Area Identity (LAI, consisting of MCC, MNC and LAC)

the paging is queued in all the involved delivery queues that are under the threshold.

b) If the “Cell Identifier List" IE is missing, the paging is to be delivered to all cells of the BSC and the paging is 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 the available PCUs for loadsharing reasons. The distribution is unable to guarantee a one-to-one relashionship between LAC/RAC and PCU. In other words, the cells (PTPPKF objects) that belong to the same LAC/RAC may be served by different PCUs. In any case, the load balancing tries to group as much as possible the PTPPKF belonging to the same LAC/RAC on the same 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 configured PCU that serves a cell (PTPPKF) that belongs to the affected LAC/RAC. This means that multiple PCUs will lead 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 abovementioned principle, the TDPC may receive multiple PAPS messages for the same LAC/RAC, but from different PCUs and 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 secondary paging delivery queue is relevant. The secondary delivery queues are managed 'per LAC' (the 'Routing Area' represented by the RAC can only represent a ‘sub-area’ of the Location Area represented by the LAC).

- Due to the fact that at maximum 20 LAC+RAC can be configured in the system, and as for the CS domain there are at the maximum 9 different delivery rates, the resulting secondary queue are exactly the same as in the CS domain 20 LAC/RAC * 9 delivery rates = 180 secondary queues.

- As a) the distribution of PTPPKFs (GPRS cells) over the PCUs is done on a 'per cell' basis ('per PTPPKF') and the load balancing tries to group as much as possible the PTPPKF belonging to the same LAC/RAC on the same 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 CCCH configuration, it is normal that PAPS messages for the same LAC/RAC, but received from different PCUs (for different PTPPKFs) finally end up in the same paging delivery queue. This means that a PAPS for a particular LAC/RAC may appear in a paging delivery queue more than once.

- Together with the PAPS message contents itself, the TDPC stores the information from which PCU (and for which 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 as the 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 the number of currently buffered pagings has already reached 360, the new paging is discarded and the BSSMAP OVERLOAD message is sent to the MSC. Moreover, the alarm "A Interface Paging Overload Detected" is output.

2) If a paging arrives from the A interface / Gb interface when the sum of scheduling queue buffers and the number of currently buffered pagings has not yet reached 360 but the received paging cannot be queued in

any scheduling queue associated to the LAC indicated in the PAGING message due to the fact that the threshold was already reached in the queues related to the indicated LAC, the new paging is discarded and the BSSMAP OVERLOAD message is sent towards the MSC. Moreover the alarm "A Interface Paging Overload Detected" is printed out.

The alarm "A Interface Paging Overload Detected" is ceased in case for T18 time there are no paging completely discarded.

Remark: As can be seen from the above descriptions, the name of the alarm message "A Interface Paging Overload 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 by the ‘threshold’, and a new PAGING received for the same LAC cannot be placed in this queue, while it can be 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 associated queue is congested) but no alarm will be output as the paging is not discarded because it can be placed in one queue for the affected LAC.

The alarm "A Interface Paging Overload Detected" is output only if a PAGING cannot be placed in any of the scheduling paging queues available for one LAC.



2.9.1.2 System reactions and overload regulation measures in case of BSC

overload

The BSC overload regulation measures depend on the type of overload condition which was detected by the BSC.

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. The following 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), the BSC - outputs an alarm message ‘249 - BSC Overload detected’ towards the O&M output media (RC, LMT, event logfile) * - sends the BSSMAP message OVERLOAD without cell identity (**see note in section “Further important notes on BSC reactions”) and with cause value ‘processor overload’ to the MSC (one message every 2 seconds, see timer T2 as explained in the sections below) - starts an algorithm for the reduction of terminating traffic which systematically discards PAGING messages received from the MSC (detailed description see below) - starts an algorithm for the reduction of originating traffic which systematically discards CHANNEL REQUIRED 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 output media (RC, LMT, event logfile) - sends the BSSMAP message OVERLOAD (without cell identity (**see note in section “Further important notes on BSC reactions”) and with cause value ‘processor overload’ to the MSC (one message every second, 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 messages when 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 the

affected 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’ as OVERLOAD cause.

- When one of the mentioned overload condition is detected, the BSC outputs the alarm message BSC OVERLOAD DETECTED to the O&M interfaces (LMT, RC, internal logfiles). If during the overload regulations additional overload conditions are detected, they are not explicitly signaled to the O&M output media (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 condition is 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 terminating traffic

2.9.1.3.1 Overload level management

The new overload management is based ‘overload level’ mechanism. The ‘overload level’ determines to which extent originating or terminating traffic is reduced. It is realized as a counter variable, which is automatically increased if after a defined observation period the overload conditions still persist. The overload 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 not

zero) this timer is simply restarted.

When the overload process receives the first trigger (BSC overload detected), the BSC overload level is set to ‘1’, a ‘BSC Overload Detected’ alarm is sent to O&M, a BSSMAP OVERLOAD message is sent towards the 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 still present, the overload level is increased, otherwise it is decreased. The timer T17 (see parameter BSCT17 in command SET BSC [TIMER]) is no longer used.

Overload still present after T2 expiry?

reduce overload level by 1

Start overload

escalation timer T2 (2 sec.)

- increase overload level by 1 - OVERLOAD message to MSC - Restart of T18

Wait for T18

expiry

*When T18 expires during overload regulation and the overload level value is not ‘0’ (zero), T18 is simply restarted. Only when T18 expires when the overload level has reached the value ‘0’, the expiry of T18 triggers the ceasing of the

‘Overload detected’ alarm message.

T18 expiry

- overload end - overload alarm ceased

- 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 alarm observation timer and is used to observe and detect the overload end condition. If the overload level has reached the value ‘0’ (zero), the expiry of T18 triggers the ceasing of the ‘BSC overload detected alarm’. T18 is restarted on every increase of the overload level. If the overload level is not ‘0’, a specific percentage of PAGING messages and CHANNEL REQUIRED message is discarded as described in the section below.

2.9.1.3.2 Traffic reduction algorithms

The BSC reduces originating traffic by the discarding of CHANNEL REQUIRED messages (messages sent from BTS to BSC indicating a request of an MS for a dedicated channel) in a specific cycle. To which extent the 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 which extent 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 discarded depending on the current overload level.

Overload

Level CH_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

Level Paging 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 level simultaneously determines degree of discarding for both PAGING and CHANNEL REQUIRED messages the. b) CHANNEL REQUIRED messages with establishment cause ‘emergency call’ and with with establishment cause ‘answer to paging’ are not discarded in the algorithm of overload management. The exclusion of CHANNEL REQUIRED messages with cause ‘answer to paging from the discarding is done to avoid a double 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 reached the 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 is used 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 paging queue, 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 timer also defines the frequency of the BSSMAP OVERLOAD message sending.

• T18 (see parameter BSCT18 in command SET BSC [TIMER]) represents the Overload O&M alarm observation 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 was discarded 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 is ceased, 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 from the 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. the traffic reduction measures as well as the overload supervision mechanism was the same in both cases. The only difference was (and is still) that, of course, in case of MSC overload, no BSSMAP OVERLOAD is sent to 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: The difference in the overload handling mechanism between MSC overload and BSC overload (not considering the exception case ‘BSC paging queue overflow’) is that in case of MSC overload only originating traffic is reduced, 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 on the timers T17 and T18 (see parameters BSCT17 and BSCT18 in command SET BSC [BASICS]). This means 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 T18 are started, the overload level is set to ‘1’ and the first step of the originating traffic reduction (discarding of CHANNEL REQUIRED messages) takes place. Moreover, the alarm ‘MSC Overload detected’ is output. - As long as T17 is running, other MSC overload indications are ignored. - If at least one forther OVERLOAD message is received from the MSC in the time period between T17 expiry and T18 expiry, the overload level is increased by ‘1’ when T18 expires and both timers restarted. If no further OVERLOAD message is received from the MSC, the expiry of T18 triggers the decrease of the overload level by one step. - When the overload level has reached the value ‘0’ and T18 expired for the last time, the MSC overload alarm is cleared.

Remark: In the SIEMENS MSC the frequency of the OVERLOAD message sending is set by command MOD 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&M output media (RC, LMT, event logfile) - starts an algorithm for the reduction of originating traffic which systematically discards CHANNEL REQUIRED 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 receives PAGING 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 PAGING COMMAND 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 4 subscriber identities. In correspondence with the paging group and the type of subscriber identity the BTS assembles the PAGING REQUEST messages by combining the subscriber identities of up to 4 PAGING COMMANDs into one PAGING REQUEST TYPE 1, 2 or 3 message (Which PAGING REQUEST TYPE is used depends on the type and number of identities stored in the paging queue), which are then transmitted over 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 received PAGING 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 already started 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 BTS and, if BTS overload handling is enabled (BTSOVLH=TRUE), the trigger event for the BTS overload alarm output and the start or continuation of suitable overload regulation measures.

As another preventive load defense action against PCH overload escalation, an additional mechanism was implemented 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, SMS etc.) requires the assignment of a dedicated signalling channel (normally an SDCCH). The dedicated signaling channel assignment is performed by the IMMEDIATE ASSIGNMENT procedure: The BSC sends an IMMEDIATE ASSIGNMENT COMMAND to the BTS which, in the successful case, forwards this message 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 ASSIGNMENT REJECT) messages. Paging is treated with priority, i.e. if both paging and IMMEDIATE ASSIGNMENT COMMAND message are to be transmitted, the BTS uses the CCCH slot for paging first. Thus the PCH traffic volume has an impact on the IMMEDIATE ASSIGNMENT via the AGCH: the higher the paging traffic volume, the less CCCH space is available for IMMEDIATE ASSIGNMENT via the AGCH. To guarantee a minimum throughput of IMMEDIATE ASSIGNMENTs via the AGCH, it is possible to reserve CCCH blocks exclusively for AGCH (see parameter NBLKACGR in command SET BTS [CCCH]).

For each configured CCCH (represented by the channel types MAINBCCH, MBCCHC and CCCH) the BTS provides an AGCH queue with 16 places, where each IMMEDIATE ASSIGNMENT COMMAND or (in case of SDCCH blocking) IMMEDIATE ASSIGNMENT REJECT requires one place. How quickly the queue is emptied 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 or IMMEDIATE 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 and sends a DELETE INDICATION (that contains the original IMMEDIATE ASSIGNMENT COMMAND or REJECT message) to the BSC to indicate that the request of the MS for the assignment of a dedicated signalling channel could not be satisfied.

For the BSC the receipt of this DELETE INDICATION message is the indication for an AGCH overload situation 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 that BTSM 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 messages are buffered until they are positively acknowledged by the remote end (in this case from the BTS). The associated layer 2 buffers are located in the PPLD boards. Buffer congestion can occur due to an excessive signalling traffic volume or/and frequent retransmissions on the LAPD links (e.g. by bad transmission quality of the PCM lines or microwave links). An inter-processor communication task (TDPC-PPLD) periodically checks the link throughput for each physical Abis signaling timeslot (i.e. the LPDLM timeslot that also carries the LPDLR radio signaling for the TRXs). The overload condition is detected when the throughput of at least one physical Abis LPDLM timeslot configured for a particular BTSM exceeds the threshold of 80% of the LAPD link capacity. If this kind of Abis LAPD overload situation is detected, the BSC regards this situation 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 regulation measures are started or continued (if the overload situation already existed before). These reactions are independent 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 messages are buffered until they are positively acknowledged by the remote end (in this case from the BSC). The associated layer 2 buffers are located in the COBA (for BTSplus) or the CCTRL (for BTSone). Buffer congestion can occur due to an excessive signalling traffic volume or/and frequent retransmissions on the LAPD links (e.g. by bad transmission quality of the PCM lines or microwave links). When the BTSE has detected an overload situation on the LAPD link based on the LAPD load threshold SLAPDOVLTH (see command CREATE BTSM), it sends the O&M message LAPD OVERLOAD towards the BSC (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 as described 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 is detected when the percentage of busy RACHs exceeds a threshold (for further details please see parameter TCCCHLDI in CREATE BTS [BASICS]). The BTS sends a CCCH LOAD INDICATION message to the BSC (see parameter PCCCHLDI in CREATE BTS [BASICS]). No special overload defence actions are applied by BTS or BSC.



2.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 case of 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 handled separately 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 increments ovld_level_downlink

• AGCH overload, i.e. the receipt of a DELETE INDICATION message (BTS->BSC), only increments ovld_level_uplink. However, the first increase of ovld_level_uplink is performed starting from the second DELETE INDICATION message. This means, that, when the first DELETE INDICATION is received, the timer T18 is started and the alarm 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 received This approach was used because the receipt of a single DELETE INDICATION just indicates that the BTS had to discard an IMMEDIATE ASSIGNMENT - this event can happen due to temporary lack of CCCH resources and does not necessarily mean a persisting AGCH overload situation. For this reason the overload handling is started only if the AGCH overload situation is confirmed by at least one further DELETE INDICATION.

• Whenever PPLD Abis LAPD signalling overload is detected, both ovld_level_uplink and ovld_level_downlink are immediately set to their maximum value (i.e. 10). This reaction is required to keep 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 is started, irrespective of the value of the database flag BTSOVLH.

The overload regulation measures depend on the type of overload condition which was detected by the BSC.

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’ towards the O&M output media (RC, LMT, event logfile) - sends the BSSMAP message OVERLOAD with cell identity (**see note in section “Further important notes on BSC reactions”) and overload cause ‘CCCH overload’ to the MSC (one message every 2 seconds, see timer T2 as explained in the sections above) - 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 PCH overload condition (Abis OVERLOAD message received), the variable ovld_level_downlink starts with the value ‘0’.

Additional load defense actions in the BTS in case of PCH overload Since BR7.0 there is an additional PCH overload defense mechanism, which is controlled by the parameter PCCCHLDI (see command SET BTS [BASICS]). If PCCCHLDI set to a value different from ‘0’, a BTS paging overload situation (i.e. the BTS has sent an OVERLOAD message to the BSC, thus indicating that one PAGING COMMAND could not be placed in a paging queue and had to be discarded), triggers the following mechanism: as long as the PCH load is still above the threshold defined by the parameter TCCCHLDI (see command SET BTS [BASICS]), the BTS discards all PAGING COMMANDs that contain an IMSI. This is done because an IMSI needs twice the space than a TMSI in the BTS paging queues and is thus an attempt to effectively prevent further overload situations by removing those messages that have the biggest impact on the load in the 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’ towards the O&M output media (RC, LMT, event logfile) - sends the BSSMAP message OVERLOAD with cell identity (**see note in section “Further important notes on BSC reactions”) and overload cause ‘CCCH overload’ to the MSC (one message every 2 seconds, see timer T2 as explained in the sections above) - starts an algorithm for the reduction of originating traffic which discards CHANNEL REQUIRED messages for the affected BTS in correspondence with the current value of ovld_level_uplink. On the first detection of the AGCH overload condition (DELETE INDICATION message received), the variable ovld_level_downlink starts 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 the affected LPDLM timeslot! - sends the BSSMAP message OVERLOAD with cell identity (**see note in section “Further important notes on 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 to the BTSM that is associated to the affected LPDLM timeslot! - starts an algorithm for the reduction of originating traffic which discards CHANNEL REQUIRED messages for 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 message received), the both variables ovld_level_downlink and ovld_level_uplink start with the maximum value ‘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 INDICATION received)

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 Overload

If both BSC and BTS overload occur at the same time, the discarding of messages on one BTS (cell) is performed using the maximum overload level value of the BSC overload level and the ovld_level_uplink (or ovld_level_downlink).

A particular treatment is reserved to Channel required with cause ‘answer to paging’ (see table below) .

If the BSC is discarding PAGING messages coming on the A interface (i.e. BSC overload level !=0 or BTS overload downlink level != 0 ), then CHANNEL REQUIRED message with cause ‘answer to paging’ are not discarded.

If no paging discarding is in progress on A interface the channel filter acts on all CHANNEL REQUIRED messages except the ones related to emergency calls.

Note:

” != “ means “not equal to”

BSC overload level BTS ovld_level_uplink BTS ovld_level_downlink discarded CHANNEL REQUIREDs

0 0 0 none

0 0 !=0 none

0 !=0 0 all CHAN REQUIREDs discarded

0 !=0 !=0 ‘answer to paging’ not discarded

!=0 0 0 ‘answer to paging’ not discarded

!=0 0 !=0 ‘answer to paging’ not discarded

!=0 !=0 0 ‘answer to paging’ not discarded

!=0 !=0 !=0 ‘answer to paging’ not discarded



2.9.5 Effects on Performance Measurement Counters

As a general rule, the discarding of messages always takes place prior to the triggering of the associated performance measurement counters.

If the BSC discards PAGING or CHANNEL REQUIRED messages due to the described overload regulation measures, 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 the measurement SUIMASCA will not be triggered.

• The discarded CHANNEL REQUIRED message will not lead to an IMMEDIATE ASSIGNMENT procedure, 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)...............................................................59 BAF (PCMG) ..............................................................77 BAF (PCMS)...............................................................63 BAND .......................................................................321 BANDOFHYS ...........................................................320 BAUDRATE..............................................................307 BCCHFREQ (BTS [BASICS])...................................111 BCCHFREQ (TGTBTS)............................................273 BEPAVGP ................................................................187 BER (PCMA) ..............................................................70 BER (PCMB) ..............................................................59 BER (PCMG)..............................................................77 BER (PCMS) ..............................................................63 BHOFOT ..................................................................277 BLERAVEDL ............................................................188



BLERAVEUL............................................................ 188 BMONTH.................................................................. 160 BPAGCHR ............................................................... 188 BPRACHR................................................................ 189 BSCDVMA ............................................................... 189 BSCOVLH.................................................................. 21 BSCT1........................................................................ 12 BSCT10...................................................................... 12 BSCT11...................................................................... 13 BSCT13...................................................................... 13 BSCT17...................................................................... 14 BSCT18...................................................................... 14 BSCT19...................................................................... 14 BSCT20...................................................................... 14 BSCT3........................................................................ 15 BSCT3121.................................................................. 15 BSCT4........................................................................ 15 BSCT7........................................................................ 16 BSCT8........................................................................ 17 BSCTQHO ................................................................. 17 BSIC (BTS [BASICS]) .............................................. 111 BSIC (TGTBTS) ....................................................... 273 BSMONTH ............................................................... 160 BSPBBLK................................................................. 189 BSSAPSSN.............................................................. 294 BTSHSCSD.............................................................. 111 BTSOVLH .................................................................. 21 BVCBHIPER ............................................................ 190 BVCBLPER.............................................................. 190 BVCBMAPER........................................................... 190 BVCBSPPER ........................................................... 190

C

C31H ........................................................................ 190 C32QUAL................................................................. 190 CACKTYP ................................................................ 191 CALLF01 .................................................................. 112 CALLF02..CALLF63................................................. 112 CBCPH....................................................................... 21 CBQ ......................................................................... 112 CCDIST.................................................................... 230 CCELL1 ................................................................... 230 CCELL2 ................................................................... 230 CELLBARR .............................................................. 160 CELLGLID (BTS [BASICS]) ..................................... 113 CELLGLID (TGTBTS) .............................................. 274 CELLGLID (TGTFDD) .............................................. 289 CELLRESH .............................................................. 113 CELLTYPE............................................................... 114 CFS............................................................................ 10 CHPOOLTYP ........................................................... 225 CHTYPE........................................... 219, 220, 222, 225 CICFM........................................................................ 21 CID........................................................................... 315 CITASUP.................................................................... 21 CLOCK..................................................................... 307 CODE (PCMA) ........................................................... 70 CODE (PCMB) ........................................................... 61 CODE (PCMG)........................................................... 77 CODE (PCMS) ........................................................... 63 CONCELL ................................................................ 115 CONGTH.................................................................. 299 CPOLICY ................................................................... 22 CRC (PCMA).............................................................. 70 CRC (PCMB).............................................................. 59 CRC (PCMG) ............................................................. 77 CRC (PCMS).............................................................. 63 CREALL ................................................................... 161 CREATE ADJC ........................................................ 277 CREATE ADJC3G ................................................... 290

CREATE BTS [BASICS]...........................................100 CREATE BTSM..........................................................81 CREATE CBCL ........................................................312 CREATE CHAN (BCCH) ..........................................219 CREATE CHAN (SDCCH)........................................220 CREATE CHAN (TCH) .............................................222 CREATE CHAN (TCH/SD) .......................................225 CREATE CTRSCHED ..............................................314 CREATE ENVA ........................................................316 CREATE EPWR.........................................................51 CREATE FHSY ........................................................214 CREATE FRL .............................................................79 CREATE LICD............................................................52 CREATE LICDS .........................................................52 CREATE LPDLM........................................................93 CREATE LPDLS ........................................................69 CREATE NSVC..........................................................80 CREATE NUC ..........................................................306 CREATE OMAL........................................................311 CREATE OPC [BASICS] ..........................................294 CREATE PCMA..........................................................69 CREATE PCMB..........................................................59 CREATE PCMG .........................................................77 CREATE PCMS..........................................................63 CREATE PCU ............................................................53 CREATE PPLD ..........................................................53 CREATE PTPPKF....................................................187 CREATE RFLOOP ...................................................320 CREATE SCA ..........................................................321 CREATE SS7L .........................................................305 CREATE SUBTSLB....................................................99 CREATE SYNC........................................................312 CREATE SYNE ........................................................312 CREATE TGTBTS....................................................273 CREATE TGTFDD ...................................................289 CREATE TGTPTPPKF.............................................275 CREATE TRACE......................................................313 CREATE TRAU ..........................................................65 CREATE TRX...........................................................210 CREATE X25A .........................................................309 CREATE X25D .........................................................307 CRESELTHRINP......................................................191 CRESELTRHSOUT..................................................191 CRESOFF ................................................................116 CRESPARI ...............................................................117 CSCH3CSCH4SUP (BSC) .........................................23 CSCH3CSCH4SUP (PTPPKF) ................................191

D

DEFPOOLTYP ...........................................................70 DGRSTRGY ...............................................................24 DIRTCHASS.............................................................162 DISTHO....................................................................230 DLAPDOVL ................................................................25 DPBGTHO................................................................231 DRXTMA ..................................................................192 DTEDCE...................................................................307 DTXDLFR.................................................................163 DTXDLHR ................................................................166 DTXUL......................................................................166

E

EADVCMPDCMHO ..................................................231 EANTHOP ................................................................118 EARCLM ..................................................................166 EBCCHTRX..............................................................213 EBSPWCR ...............................................................173 EBSPWRC ...............................................................174 EBUSYCUM .............................................................321 EC ............................................................................167



EEDGE..................................................................... 213 EEICM...................................................................... 321 EEOTD..................................................................... 118 EEXCDIST ............................................................... 271 EFRSUPP .................................................................. 25 EFULHO................................................................... 234 EGPLGPEIGHTTS................................................... 192 EGPLGPFIVETS...................................................... 192 EGPLGPFOURTS.................................................... 192 EGPLGPONETS ...................................................... 192 EGPLGPSEVENTS.................................................. 192 EGPLGPSIXTS ........................................................ 192 EGPLGPTHREETS.................................................. 193 EGPLGPTWOTS ..................................................... 193 EGPRS..................................................................... 213 EGWSEIGHTTS....................................................... 193 EGWSFIVETS ......................................................... 193 EGWSFOURTS ....................................................... 193 EGWSONETS.......................................................... 193 EGWSSEVENTS ..................................................... 193 EGWSSIXTS............................................................ 194 EGWSTHREETS ..................................................... 194 EGWSTWOTS......................................................... 194 EHRACT .................................................................. 119 EHRACTAMR............................................................. 26 EICNF1 .................................................................... 321 EISDCCHHO.............................................................. 26 ELEVHOM................................................................ 235 ELIMITCH ................................................................ 235 ELKADPT................................................................. 194 EMCSFAMA1DL ...................................................... 194 EMCSFAMAP1DL .................................................... 194 EMCSFAMB1DL ...................................................... 195 EMCSFAMCDL ........................................................ 195 EMCSFAMGDL........................................................ 195 EMFA1UNIR8PSK ................................................... 195 EMFAP1UNIR8PSK ................................................. 195 EMFB1UNIR8PSK ................................................... 195 EMFCUNIR8PSK ..................................................... 195 EMFCUNIRGMSK.................................................... 195 EMFGUNIR8PSK ..................................................... 195 EMFGUNIRGMSK.................................................... 195 EMSPWRC .............................................................. 175 EMT1.......................................................................... 85 EMT2.......................................................................... 86 ENANCD.................................................................. 151 ENCALSUP................................................................ 26 ENDML..................................................................... 321 ENFOIAHO ................................................................ 27 ENFORCHO............................................................... 27 ENHSCSD.................................................................. 28 ENVANAME ............................................................. 316 EPA............................................................................ 29 EPAT1...................................................................... 121 EPAT2...................................................................... 122 EPOOL....................................................................... 30 EPRE ....................................................................... 168 EPREHSCSD............................................................. 30 EPWCRLFW............................................................ 175 EQ............................................................................ 169 EQPOS ...................................................................... 49 ERRACT .................................................................... 30 ERRCORMTD.......................................................... 300 ERUDGR.................................................................. 269 ESUP ......................................................................... 30 ETFO.......................................................................... 67 ETIME ........................................................................ 10 ETXDIVTS................................................................ 122 EUBCHO.................................................................. 236 EUHO....................................................................... 236

EUIMPHO.................................................................237 EUSCHO..................................................................238 EUSDCHO .................................................................31 EXCDIST..................................................................271 EXPSWV (BTSM).......................................................86 EXPSWV (TRAU).......................................................68 EXTCHO ..................................................................238 EXTMODE........................................219, 221, 222, 226

F

FACCHQ ..................................................................122 FDDARFCN..............................................................289 FDDDIV....................................................................289 FDDGQO..................................................................196 FDDMURREP...........................................................122 FDDQMI ...................................................................122 FDDQO ....................................................................122 FDDREPQTY ...........................................................123 FDDSCRMC.............................................................289 FHORLMO ...............................................................278 FHSYID ............................................220, 221, 222, 227 FLAPDOVLTH............................................................86 FLOWCTH ...............................................................300 FRSTD .......................................................................79 FRTERM ..................................................................306 FULHOC...................................................................278 FULRXLVMOFF .......................................................279

G

GAM .........................................................................196 GASTRABISTH ..........................................................87 GASTRTH ................................................................196 GCELLRESH............................................................197 GDCH (TCH) ............................................................223 GDCH (TCHSD) .......................................................227 GFDDMURREP........................................................197 GFDDQMI ................................................................197 GFDDREPQTY.........................................................197 GHCSPC (ADJC) .....................................................279 GHCSPC (PTPPKF).................................................197 GHCSTH (ADJC)......................................................279 GHCSTH (PTPPKF) .................................................197 GLK ............................................................................79 GMANMSAL.............................................................197 GMANPRES.............................................................198 GMANRETS .............................................................198 GMSTXPMAC (PTPPKF) .........................................198 GMSTXPMAC (TGTPTPPKF) ..................................275 GNMULBAC .............................................................198 GPATH.....................................................................199 GPDPDTCHA...........................................................199 GPENTIME (ADJC) ..................................................279 GPENTIME (PTPPKF) .............................................199 GRESOFF (ADJC) ...................................................279 GRESOFF (PTPPKF)...............................................199 GRXLAMI (PTPPKF) ................................................200 GRXLAMI (TGTPTPPKF) .........................................276 GS ............................................................................201 GSUP (ADJC) ..........................................................280 GSUP (TRX).............................................................210 GTDDMURREP........................................................201 GTEMPOFF (ADJC).................................................280 GTEMPOFF (PTPPKF) ............................................201 GTS............................................................................79 GTXINT ....................................................................201 GUARMABIS............................................................124 GUMTSSRHPRI .......................................................201

H

HCICN........................................................................75



HIERC...................................................................... 239 HIERF ...................................................................... 239 HOAVDIST............................................................... 239 HOAVELEV.............................................................. 240 HOAVPWRB ............................................................ 241 HOAVQUAL ............................................................. 242 HOCCDIST .............................................................. 243 HOLTHLVDL ............................................................ 243 HOLTHLVUL ............................................................ 243 HOLTHQAMRDL...................................................... 244 HOLTHQAMRUL...................................................... 245 HOLTHQUDL ........................................................... 245 HOLTHQUUL ........................................................... 246 HOM (ADJC) ............................................................ 281 HOM (ADJC3G) ....................................................... 290 HOMDOFF (ADJC) .................................................. 281 HOMDOFF (ADJC3G).............................................. 290 HOMDTIME (ADJC) ................................................. 281 HOMDTIME (ADJC3G) ............................................ 291 HOMRGTA............................................................... 246 HOMSOFF (ADJC)................................................... 282 HOMSOFF (ADJC3G).............................................. 291 HOMSTAM............................................................... 246 HOPMODE............................................................... 170 HOPP....................................................................... 271 HORXLVDLI............................................................. 247 HORXLVDLO ........................................................... 248 HOSYNC.................................................................... 31 HOTDLINT ............................................................... 249 HOTHAMRCDL........................................................ 249 HOTHAMRCUL........................................................ 250 HOTHAMRDDL........................................................ 250 HOTHAMRDUL........................................................ 251 HOTHCMPLVDL ...................................................... 251 HOTHCMPLVUL ...................................................... 251 HOTHDCMLVDL...................................................... 252 HOTHDCMLVUL...................................................... 252 HOTMSRM............................................................... 252 HOTMSRME ............................................................ 252 HOTULINT ............................................................... 253 HRACTAMRT1......................................................... 125 HRACTAMRT2......................................................... 126 HRACTT1................................................................. 127 HRACTT2................................................................. 127 HRSPEECH ............................................................... 32 HSN ......................................................................... 217

I

IERCHOSDCCH ...................................................... 253 IMCSULNIR8PSK .................................................... 202 IMCSULNIRGMSK................................................... 202 IMSIATDT ................................................................ 171 IMSIFSIZ .................................................................... 11 INIBLER ................................................................... 202 INICSCH .................................................................. 202 INIMCSDL ................................................................ 202 ININHO..................................................................... 254 INTAVEPR ............................................................... 149 INTCLASS................................................................ 149 INTERCH ................................................................. 255 INTINF...................................................................... 316 INTRACH ................................................................. 255 IRACHOSDCCH ...................................................... 256

L

L1CTS ........................................................................ 60 L2WIN .............................................................. 307, 309 L3PS ................................................................ 307, 309 L3WIN .............................................................. 307, 309 LAPDOVLT ................................................................ 87

LAPDPOOL (LPDLM).................................................94 LAPDPOOL (LPDLS) .................................................69 LCBM0 .....................................................................128 LCBM1 .....................................................................128 LCBM2 .....................................................................128 LCBM3 .....................................................................128 LCN2WC ..........................................................307, 309 LCSMONTH ...............................................................32 LCSNSSC ..................................................................32 LEVHOM ..................................................................282 LEVONC...................................................................282 LINKTYPE (CBCL) ...................................................312 LINKTYPE (OMAL)...................................................311 LKSET......................................................................305 LNKA........................................................................305 LOTERCH ................................................................256 LOTRACH ................................................................256 LOWBER (PCMA) ......................................................75 LOWBER (PCMB) ......................................................61 LOWBER (PCMG)......................................................77 LOWBER (PCMS) ......................................................63 LOWTLEVD .............................................................175 LOWTLEVU .............................................................175 LOWTQUAD ............................................................176 LOWTQUAMRDL .....................................................176 LOWTQUAMRUL .....................................................177 LOWTQUAU ............................................................177 LPDLMN...................................................................210 LPDLMSAT ................................................................88 LREDUNEQ (PCMB)..................................................61 LREDUNEQ (PCMS)..................................................63

M

M2T1 ........................................................................300 M2T2 ........................................................................301 M2T3 ........................................................................301 M2T4E......................................................................301 M2T4N......................................................................301 M2T5 ........................................................................301 M2T6 ........................................................................301 M2T7 ........................................................................301 M3T1 ........................................................................302 M3T10 ......................................................................302 M3T12 ......................................................................303 M3T13 ......................................................................303 M3T14 ......................................................................303 M3T17 ......................................................................303 M3T19 ......................................................................303 M3T1TM ...................................................................303 M3T2 ........................................................................303 M3T22OR20 .............................................................304 M3T22OR21 .............................................................304 M3T2TM ...................................................................304 M3T3 ........................................................................304 M3T4 ........................................................................304 M3T5 ........................................................................304 MACONN .................................................................315 MADGRLV..................................................................32 MAFIRACHO..............................................................32 MAIO ................................................220, 221, 223, 227 MAIRACHO ..............................................................256 MASCLOGFS.............................................................11 MAXFAILHO.............................................................257 MAXNCELL ................................................................33 MAXRETR................................................................142 MECNT.....................................................................320 MEDAFUPE ...............................................................11 MEDAFUST................................................................11 MELID ........................................................................10 MICROCELL (ADJC)................................................282



MICROCELL (ADJC3G)........................................... 291 MINCCNT................................................................. 320 MNTBMASK............................................................... 33 MOBALLOC ............................................................. 218 MOEC ...................................................................... 211 MSBHIPER .............................................................. 202 MSBLPER ................................................................ 202 MSBMAPER............................................................. 203 MSBSPPER ............................................................. 203 MSCOVLH ................................................................. 34 MSCPERTFLAG ...................................................... 294 MSCPOOL ................................................................. 35 MSCSPC.................................................................. 294 MSCV......................................................................... 35 MSTXPMAXCH ........................................................ 142 MSTXPMAXCL......................................................... 283 MSTXPMAXDCS (BTS [BASICS]) ........................... 128 MSTXPMAXDCS (TGTBTS) .................................... 274 MSTXPMAXGSM (BTS [BASICS])........................... 129 MSTXPMAXGSM (TGTBTS).................................... 274 MSTXPMAXPCS (BTS [BASICS])............................ 129 MSTXPMAXPCS (TGTBTS)..................................... 274 MSTXPMAXUMTS (TGTFDD) ................................. 289

N

N1 301 N2 302 N2WC .............................................................. 307, 309 N3101 ........................................................................ 53 N3103 ........................................................................ 53 N3105 ........................................................................ 54 N391 .......................................................................... 79 N392 .......................................................................... 79 N393 .......................................................................... 80 NALLWACC............................................................. 171 NAVGI...................................................................... 203 NBLKACGR ............................................................. 143 NBVCBR .................................................................... 54 NBVCRR.................................................................... 54 NBVCUR.................................................................... 54 NCC1TH................................................................... 203 NCC1THADJC ......................................................... 283 NCDP1 ..................................................................... 152 NCDP2 ..................................................................... 152 NCELL ..................................................................... 257 NCGPENTIME ......................................................... 283 NCGRESOFF........................................................... 283 NCGTEMPOFF ........................................................ 283 NCRARESH............................................................. 203 NCRESELFLAG......................................................... 35 NCSARA .................................................................. 204 NCTRFPSCTH......................................................... 204 NECI .......................................................................... 36 NETWTYPE ............................................................... 37 NFRAMEPG............................................................. 144 NMDLATT1 .............................................................. 322 NMO........................................................................... 54 NMULBAC................................................................ 131 NNSVCBLKR ............................................................. 55 NNSVCRR ................................................................. 55 NNSVCTSTR ............................................................. 55 NNSVCUBLR............................................................. 55 NOBAKHO ............................................................... 257 NOCHBLKN ............................................................. 145 NOCHFBLK.............................................................. 145 NOFREPHO............................................................. 257 NOTFACCH ............................................................... 37 NRLCMAX.................................................................. 55 NRPGRANT ............................................................. 152 NSEI........................................................................... 55

NSLOTST.................................................................146 NSVCI ........................................................................80 NSVLI .........................................................................80 NTWCARD.................................................................38 NTWCNDRXP..........................................................204 NTWCOR .................................................................204 NTWCREPPIDL .......................................................205 NTWCREPPTR........................................................205 NTWIND...................................................................295 NUA (PCMA) ..............................................................75 NUA (PCMB) ..............................................................61 NUA (PCMG)..............................................................78 NUA (PCMS) ..............................................................63 NY1 ..........................................................................148

O

OMCCPT (OMAL) ....................................................311 OMLAPDRT................................................................89 OPC..........................................................................295 OVLENTHR................................................................38 OVLSTTHR ................................................................38

P

PAVRLEV.................................................................178 PAVRQUAL..............................................................179 PBGTHO ..................................................................258 PCCCHLDI ...............................................................131 PCMBSTXPRL .........................................................180 PCMCON0 .................................................................90 PCMCON1 .................................................................90 PCMCON2 .................................................................90 PCMCON3 .................................................................90 PCMECH..................................................................205 PCML (PCMB)............................................................61 PCML (PCMG) ...........................................................78 PCML (PCMS)............................................................64 PCMSN ......................................................................68 PCMSOBJ ................................................................312 PCMT .........................................................................75 PCMTYPE ..................................................................38 PCONINT .................................................................180 PCRLFTH.................................................................181 PCUID ........................................................................80 PENTIME .................................................................132 PERSTLVPRI1 .........................................................205 PERSTLVPRI2 .........................................................205 PERSTLVPRI3 .........................................................205 PERSTLVPRI4 .........................................................205 PERWEEK ...............................................................315 PKTMEASREPCNT..................................................206 PKTNDEC ................................................................206 PKTNINC..................................................................206 PKTNMA ..................................................................206 PL 258 PLMNP.....................................................................132 PLNC (ADJC) ...........................................................284 PLNC (ADJC3G) ......................................................291 POOLTYP ..................................................................76 PPLNC (ADJC).........................................................284 PPLNC (ADJC3G) ....................................................292 PRPBCCH................................................................206 PUREBBSIG44CONF ..............................................132 PWRCONF...............................................................181 PWRINCSS..............................................................181 PWROFS .................................................................148 PWROUT .................................................................172 PWRRED .................................................................211 PWREDSS ...............................................................181



Q

QL ............................................................................ 172 QSRHC .................................................................... 133 QSRHCINI................................................................ 133 QSRHI...................................................................... 133 QSRHPRI................................................................. 206

R

R20 .................................................................. 308, 310 R22 .................................................................. 308, 310 R23 .................................................................. 308, 310 RAARET................................................................... 206 RACHBT .................................................................. 133 RACHLAS ................................................................ 134 RACODE (PTPPKF)................................................. 207 RACODE (TGTPTPPKF) ......................................... 276 RACOL (PTPPKF) ................................................... 207 RACOL (TGTPTPPKF) ............................................ 276 RADIOMG ................................................................ 212 RADIOMR ................................................................ 212 RAENV..................................................................... 207 RARESH .................................................................. 207 RAVEW.................................................................... 269 RDGRUL.......................................................... 269, 270 RDLNKTBS.............................................................. 182 RDLNKTO................................................................ 135 RECCRI ................................................................... 313 REMAL (PCMA) ......................................................... 75 REMAL (PCMB) ......................................................... 61 REMAL (PCMG)......................................................... 78 REMAL (PCMS) ......................................................... 64 REPTYP................................................................... 135 RETRY............................................................. 308, 310 RFRSINDP............................................................... 150 RHOLTQDL.............................................................. 270 RHOLTQUL.............................................................. 270 RNCID...................................................................... 290 RUGRDL.......................................................... 269, 270 RXLEVAMI ............................................................... 135 RXLEVHO................................................................ 258 RXLEVMIN............................................................... 284 RXLEVMINC ............................................................ 292 RXLV........................................................................ 320 RXQUALHO ............................................................. 258

S

SALUNAME (BSCE) .................................................. 49 SALUNAME (BTSM) .................................................. 91 SALUNAME (TRAU) .................................................. 68 SANTIME ................................................................. 302 SCHWEIPRI1........................................................... 207 SCHWEIPRI2........................................................... 208 SCHWEIPRI3........................................................... 208 SCHWEIPRI4........................................................... 208 SDCCHCONGTH..................................................... 136 SET BSC [ALARMSEV] ............................................. 46 SET BSC [BASICS].................................................... 18 SET BSC [CONTROL] ............................................... 10 SET BSC [TIMER]...................................................... 12 SET BSCE [ALARMSEV] ........................................... 49 SET BSCE [REMINV]................................................. 49 SET BTS [CCCH]..................................................... 140 SET BTS [INTERF] .................................................. 149 SET BTS [OPTIONS] ....................................... 160, 271 SET BTS [TIMER] .................................................... 151 SET HAND [BASICS]............................................... 228 SET HAND [DATA]................................................... 269 SET MEL.................................................................... 10 SET OPC [MTL2] ..................................................... 299

SET OPC [MTL3]......................................................302 SET PTPPKF ...........................................................213 SET PWRC ..............................................................173 SET TSLA ..................................................................76 SG10HOPAR ...........................................................259 SG10PCPAR ............................................................182 SG11HOPAR ...........................................................259 SG11PCPAR ............................................................182 SG12HOPAR ...........................................................259 SG12PCPAR ............................................................182 SG13HOPAR ...........................................................259 SG13PCPAR ............................................................182 SG14HOPAR ...........................................................259 SG14PCPAR ............................................................182 SG1HOPAR .............................................................259 SG1PCPAR..............................................................182 SG2HOPAR .............................................................259 SG2PCPAR..............................................................182 SG3HOPAR .............................................................259 SG3PCPAR..............................................................182 SG4HOPAR .............................................................259 SG4PCPAR..............................................................182 SG5HOPAR .............................................................259 SG5PCPAR..............................................................182 SG6HOPAR .............................................................259 SG6PCPAR..............................................................182 SG7HOPAR .............................................................259 SG7PCPAR..............................................................182 SG8HOPAR .............................................................259 SG8PCPAR..............................................................182 SG9HOPAR .............................................................259 SG9PCPAR..............................................................182 SHLAPDIT..................................................................91 SIMSCREL99 .............................................................39 SISGSNREL99...........................................................39 SLAPDOVLTH............................................................91 SLC ..........................................................................305 SMLCPERTFLAG.....................................................295 SMLCSPC ................................................................295 SMSCBUSE .............................................................272 SPEED145 .................................................................40 SPENLAW..................................................................40 SS7MTPTYP ............................................................295 START......................................................315, 320, 322 STGTTLLIINF...........................................................208 STOP........................................................315, 320, 322 SYSID (BTS) ............................................................137 SYSID (TGTBTS) .....................................................275

T

T1 (PCU) ....................................................................56 T1 (X25A) .................................................................310 T1 (X25D).................................................................308 T2 (PCU) ....................................................................56 T20 ...................................................................308, 310 T200 .........................................................................152 T21 ...................................................................308, 310 T22 ...................................................................308, 310 T23 ...................................................................308, 310 T26 ...................................................................308, 310 T28 ...................................................................308, 310 T3101 .......................................................................154 T3105 .......................................................................154 T3109 .......................................................................155 T3111 .......................................................................156 T3122 .........................................................................41 T3141 .........................................................................56 T3168 .......................................................................208 T3169 .........................................................................56 T3172 .........................................................................56



T3191 ......................................................................... 56 T3192 ....................................................................... 208 T3193 ......................................................................... 56 T3195 ......................................................................... 56 T3212 ....................................................................... 172 T391 ........................................................................... 80 T4 .................................................................... 309, 311 TAADJ...................................................................... 137 TAVGT ..................................................................... 208 TAVGW.................................................................... 208 TCBCSI ...................................................................... 41 TCCCHLDI ............................................................... 138 TCONG ...................................................................... 80 TCONN .................................................................... 295 TCONOFF.................................................................. 80 TDDGQO ................................................................. 209 TDDMURREP .......................................................... 139 TDDQO .................................................................... 139 TEI (LPDLM) .............................................................. 92 TEI (LPDLS)............................................................... 68 TEMPCH .................................................................... 57 TEMPOFF ................................................................ 139 TEMPPDT .................................................................. 57 TERTCH........................................................... 223, 227 TF1............................................................................. 58 TGRANT .................................................................. 156 TGTCELL ......................................................... 284, 292 TGUARD.................................................................. 296 TGUARDTCHSD........................................................ 42 THLEVFULHO ......................................................... 259 THORQST................................................................ 260 THPROXT .................................................................. 58 THR.......................................................................... 316 THROUGH ................................................................. 76 THSULBAL................................................................. 58 TIAR......................................................................... 297 TIAS ......................................................................... 297 TIMEDTBFREL .......................................................... 58 TIMERFHO .............................................................. 285 TINHBAKHO ............................................................ 285 TINHFAIHO.............................................................. 285 TINHFAIHO (ADJC3G) ............................................ 292 TINHRDGR .............................................................. 270 TINHRUGR .............................................................. 270 TINOIERCHO........................................................... 260 TINT ......................................................................... 297 TNOCH .................................................................... 156 TNSVCBLK ................................................................ 58 TNSVCPTST.............................................................. 58 TNSVCR .................................................................... 58 TNSVCTST ................................................................ 59 TOTERM.................................................................. 306 TRACE............................................................. 309, 311 TRACEMG ................................................................. 43 TRACEMR ................................................................. 43 TRACERECTYP....................................................... 315 TREL........................................................................ 298 TRESEL ................................................................... 209

TRFCT........................................................................44 TRFHITH ..................................................................261 TRFHOE...................................................................262 TRFHOM..................................................................286 TRFHORXLVMOFF..................................................286 TRFHOT...................................................................263 TRFKPRI ..................................................................265 TRFLTH....................................................................265 TRFMMA ..................................................................266 TRFMS .....................................................................266 TRFPS........................................................................45 TRFPSCTRLT ..........................................................209 TRXAREA ................................................................213 TRXFREQ ................................................................213 TRXMD.....................................................................212 TSBS........................................................................298 TSC ..................................................220, 221, 223, 227 TSLA ........................................................................305 TSULBAL ...................................................................59 TSYNC (BTS [TIMER]) .............................................157 TSYNC (TRAU) ..........................................................68 TSYNCDL.................................................................157 TSYNCR...................................................................157 TSYNCUL.................................................................158 TTRAU .....................................................................158 TUPLREP.................................................................158 TWCUSER ...............................................................298 TXDIVTSEXCPT ......................................................139 TXDIVTSPAR...........................................................139

U

UADJ........................................................................293 UMECNO .................................................................293 UMTSSRHPRI..........................................................139 UPGRFREQ ...............................................................45 UPTLEVD.................................................................183 UPTLEVU.................................................................183 UPTQUAD................................................................183 UPTQUAMRDL ........................................................184 UPTQUAMRUL ........................................................184 UPTQUAU................................................................185 USECNO..................................................................293 USG..........................................................................287 USRSCP ..................................................................293

V

VGRULF...................................................................159 VOLDL........................................................................76 VOLUL........................................................................76

W

WMOD .................................................................62, 64

X

X121ADDR (CBCL) ..................................................312 X121ADDR (OMAL) .................................................311

Db70 Dsc Bettoni

Documents

Transcript of Db70 Dsc Bettoni