bsc database parameter description br8.0 - updated draft

s

Siemens Base Station (SBS) BSC Database Parameter Description BR8.0 - DRAFT Version 24.08.2006

SBS: BSC Database Parameter Description BR8.0 - DRAFT - COMMERCIALLY NOT BINDING Version 24.08.06 __________________________________________________________________________________________________________

2 / 526 Eckardt Bertermann, Network Engineering GERAN

made by:

Eckardt Bertermann SIEMENS AG COM MN PG NT NE 1, Network Engineering GERAN Tel.: +49 89 636 47691 FAX: +49 89 636 40109 e-mail: [email protected] GPRS contributions by:

Wolfgang Malter SIEMENS AG COM MN PG SI RA2, 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! • CONTENTS ARE NOT COMMERCIALLY BINDING! • Any comments for corrections or suggestions for improvements are welcome! • The authors’ e-mail-address is only mentioned for feedback purposes! ► If you find mistakes, please check the latest versions of the document in IMS or Siemens Extranet first, before you feed back.

• Technical queries concerning specific parameters and features shall be not be sent to the authors but to CIC, R-NCC or NCC as an official hotline query!!!

(For queries to TPS-BSS, please use the well-known procedures.)

!



Contents:

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

1.1 BR8.0 OBJECT TREE OF BSC DATABASE OBJECTS ........................................................................................................7 1.2 BSC DATABASE COMMANDS AND PARAMETERS.....................................................................................................9

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

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

Creating the LPDLS links: ........................................................................................................................................81 Creating the PCMA link: ...........................................................................................................................................82 Setting the uplink and downlink volumes for specific PCMA timeslots: ....................................................................88 Creating the PCMG link: ..........................................................................................................................................89 Creating the physical link connection on the GPRS Gb interface (Frame Relay Link): ...........................................91 Creating the end-to-end communication between BSS and SGSN: Network Service Virtual Connection (NSVC): .92 Creating the BTS Site Manager: ..............................................................................................................................93 Creating the Common BTS data of a BTSM for Dynamic MAIO Allocation (DMA): ...............................................110 Creating the hopping laws used for Dynamic MAIO Allocation:..............................................................................115 Creating the LPDLM links: .....................................................................................................................................116 Creating the terrestrial Abis timeslots for flexible Abis allocation: ..........................................................................118 Creating a cell with definition of global parameters: ...............................................................................................123 Setting the cell specific parameters for DMA Admission Control............................................................................184 Setting the cell attributes for the Interference Measurement of idle TCHs: ............................................................196 Setting the cell specific timer values: .....................................................................................................................198 Setting the cell specific optional features: ..............................................................................................................208 Defining the cell specific service layer lists for the feature 'Service dependent Channel Allocation' (SDCA) via 'Multi Service Layer Support' (MSLS): .............................................................................................................................224 Setting the cell specific attributes for Power Control: .............................................................................................235

Power Control Parameter Relations ..................................................................................................................248 Creating the GPRS point to point packet transfer service in a cell: ........................................................................249 Creating the LPDLR links: ......................................................................................................................................281 Creating the cell-specific Frequency Hopping systems for static MAIO Allocation (SMA):.....................................282 Creating the TRXs:.................................................................................................................................................284 Enabling GPRS and EDGE in a cell: ......................................................................................................................288 Creating the BCCH for the cell: ..............................................................................................................................290 Creating the SDCCHs for the cell:..........................................................................................................................291 Creating the TCHs for the cell: ...............................................................................................................................293 Creating hybrid TCHs/SDCCHs (TCH/SD) for the cell: ..........................................................................................296 Setting the cell specific parameters and threshold values for voice call Handover:................................................301

Handover Parameter Relations .........................................................................................................................350 Setting the cell specific parameters and threshold values for 14,4kbit/s data call up- and downgrading and quality inter-cell handover:.................................................................................................................................................352 Enabling features related to ASCI, SMS-CB, Frequency Hopping, HSCSD, Call Release due to Excessive Distance and Dynamic MAIO Allocation (DMA): ...................................................................................................................354 Creating the Target Cell Objects: ...........................................................................................................................359 Creating the Target Point-to-point Packet Flow Objects:........................................................................................361 Creating the Adjacent Cell Objects: .......................................................................................................................363 Creating the Target Cell Objects for handover from GSM to UMTS (FDD):...........................................................376 Creating the Adjacent Cell Objects for external UMTS FDD or UMTS TDD cells: .................................................378 Creating the CCS7 level 3 addresses of BSC, MSC and SMLC and basic SCCP parameters for the SS7 connection:.............................................................................................................................................................383 Setting the timer values for CCS7 MTP level 2: .....................................................................................................388 Setting the timer values for CCS7 MTP level 3: .....................................................................................................391 Creating the CCS7 link:..........................................................................................................................................394



Creating a Nailed-Up Connection through the BSC/TRAU:....................................................................................395 Creating an X25 connection via dedicated link:......................................................................................................396 Creating an X25 connection via A-interface: ..........................................................................................................398 Creating an IP Link connection: .............................................................................................................................400 Creating the O&M link for the RC connection:........................................................................................................401 Creating the link for the external connection to the SMS-CB system: ....................................................................401 Defining the BSC reference synchronization clock origin: ......................................................................................402 Defining an external synchronization signal: ..........................................................................................................402 Creating the Quality of Service Alarm Objects: ......................................................................................................403 Creating the Quality of Service Alarm threshold sets: ............................................................................................404 Creating the Quality of Service Alarm Objects for the BSC object: ........................................................................406 Creating the Quality of Service Alarm Objects for BTS objects:.............................................................................407 Creating the Quality of Service Alarm Objects for PTPPKF objects:......................................................................411 Activating IMSI tracing in the BSC: ........................................................................................................................413 Creating a Cell Traffic Recording (CTR) job:..........................................................................................................414 Enabling the data recording for the feature 'History on Dropped Calls': .................................................................416 Defining the BSC environmental alarms:................................................................................................................421 Configuring the feature Online RF Loopback: ........................................................................................................422 Creating Smart Carrier Allocation:..........................................................................................................................426

2 APPENDIX ...................................................................................................................................................................428

2.1 HANDOVER THRESHOLDS & ALGORITHMS..................................................................................................................428 2.1.1 Functional Diagram Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and power budget) ........................................................................................................................................................428 2.1.2 Rules: Handover Thresholds for Inter-cell Handover and Intra-cell Handover (level, quality and power budget), Power Control disabled ............................................................................................................................429

2.1.2.1 Inter-cell/Inter-system Handover due to level ........................................................................................429 2.1.2.1.1 Handover Decision / Handover Trigger Conditions........................................................................429 2.1.2.1.2 Target Cell List Generation...........................................................................................................430 2.1.2.1.3 Target Cell Ranking (HCS disabled)..............................................................................................431 2.1.2.1.4 Target Cell Ranking with HCS .......................................................................................................434 2.1.2.1.4.1 Ranking of 3G target cells within 3G sublist...............................................................................434 2.1.2.1.4.2 Ranking of 2G target cells within 2G sublist - Ranking Method 0...............................................435 2.1.2.1.4.3 Ranking of 2G target cells within 2G sublist - Ranking Method 1...............................................436 2.1.2.1.4. Resulting ranking of 2G and 3G target cells and sublists.............................................................437

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

2.1.2.3.1 Handover Decision / Handover Trigger Conditions.......................................................................441 2.1.2.3.2 Target Cell List Generation...........................................................................................................442 2.1.2.3.3 Target Cell Ranking (HCS disabled).............................................................................................443 2.1.2.3.4 Target Cell Ranking with HCS ......................................................................................................443

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

2.1.2.5 Inter-cell/Inter-system Handover due to better cell (power budget handover) ......................................446 2.1.2.5.1 Handover Decision / Handover Trigger Conditions.......................................................................446 2.1.2.5.2 Target Cell List Generation (HCS disabled)..................................................................................448 2.1.2.5.3 Target Cell Ranking (HCS disabled).............................................................................................449 2.1.2.5.3.1 Speed sensitive handover enabled............................................................................................450 2.1.2.5.4 Handover Initiation and Target Cell List Generation with HCS .....................................................451 2.1.2.5.5 Target Cell Ranking with HCS ......................................................................................................452

2.1.2.5.6 Speed sensitive handover enabled....................................................................................................452 2.1.2.6 Inter-system Handover due to sufficient coverage................................................................................453

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

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

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



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

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

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

2.4.2.1 Power Increase.....................................................................................................................................470 2.4.2.2 Power Decrease ...................................................................................................................................471

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

2.4.3.5.1 BS power control procedure .........................................................................................................476 2.4.3.5.2 MS power control procedure.........................................................................................................477

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

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

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

2.6.2.1 SGxxHOPAR parameter values (Handover)..........................................................................................485 2.6.2.2 SGxxPCPAR parameter values (Power Control)...................................................................................487 2.6.2.3 Effects on Call processing .....................................................................................................................488

2.7 MAPPING OF RXQUAL AND C/I VALUES....................................................................................................................489 2.8 AMR LINK ADAPTATION THRESHOLDS UPLINK ...........................................................................................................490 2.9 BSC, MSC AND BTS OVERLOAD HANDLING .............................................................................................................494

2.9.1 BSC Overload ..............................................................................................................................................494 2.9.1.1 BSC overload conditions .......................................................................................................................494 2.9.1.2 System reactions and overload regulation measures in case of BSC overload....................................502

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

2.9.1.3.1 Overload level management .........................................................................................................504 2.9.1.3.2 Traffic reduction algorithms ..........................................................................................................505 2.9.1.3.3 Special overload supervision algorithm in case of BSC paging queue overflow ...........................506

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

2.9.2.1.1 Special overload level escalation algorithm in case of MSC overload ...........................................506 2.9.3 BTS Overload...............................................................................................................................................508

2.9.3.1 BTS overload conditions........................................................................................................................508 2.9.3.2 Traffic reduction mechanisms in case of BTS overload........................................................................514 2.9.3.3 System reactions and overload regulation measures in case of BTS overload ....................................515

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

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



1 Database BR8.0 1.1 BR8.0 Object Tree of BSC database objects

Note: The objects BTSMOSUSW, TRAOSUSW, SCANCO, the scanner objects ('SCANxxxx') as well as 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 BR8.0 (compared to BR7.0). 3) Changes of parameter values, value ranges and default values are indicated by

highlighted letters. Changes of parameter names are marked, too. 4) In BR6.0 the 'packages' (e.g. PKGBTSB, PKGBSCT etc.) were removed so

that all parameters subordinate to one object (e.g. BTS) are included in 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..83

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

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

SET BSC [CONTROL]:

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

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

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



IMSIFSIZ=30, object: BSC [CONTROL] unit: 1 Mbyte range: 0..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 for analysis by the DUIT application.

HDCFS=1, object: BSC [CONTROL] unit: 1 Mbyte range: 1-12 default: 1

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

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

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



MASCLOGFS=3, object: BSC [CONTROL] unit: 1 Mbyte range: 1-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, object: BSC [CONTROL] range: UPPE_0h= no per. upl.. UPPE_1h = Upl. period 1h UPPE_2h = Upl. period 2h UPPE_3h = Upl. period 3h UPPE_4h = Upl. period 4h UPPE_6h = Upl. period 6h UPPE_8h = Upl. period 8h UPPE_12h= Upl. period 12h UPPE_24h= Upl. period 24h default: UPPE_0h

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

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

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

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

SET BSC [TIMER]:

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

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

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

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



BSCT11 Cancelled – parameter is replaced by parameters BSCT11PUB and BSCT11WPS in BR8.0.

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

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

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

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

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



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

BSC timer T13, this timer determines the RESET guard period at the BSS. The timer T13 is a guard timer which is started after the receipt of the BSSMAP message RESET (see also BSCT4). It provides the time for the BSS to release all affected calls and to erase all affected references. After 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.

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

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


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


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




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


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

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

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




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

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

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

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

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


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

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



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

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

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

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

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

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

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

Setting the global parameters of the BSC:

SET BSC [BASICS] :

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

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

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

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

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

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

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



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

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

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

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



ASCIONECHMDL=FALSE, object: BSC [BASICS] 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 already 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), object: BSC [BASICS] range: ENABLED(1..100), DISABLED default: ENABLE(30) (minor) ENABLE(60) (major) ENABLE(90) (critical)

A-interface signalling monitoring thresholds, determines the state and the threshold values for the minor, major and critical QOS alarms for the SS7 signalling 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 Parameter removed in BR8.0!



ASUBISAT=FALSE, object: BSC [BASICS] 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 signalling 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, object: BSC [BASICS] 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, object: BSC [BASICS] 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, object: BSC [BASICS] 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 Abis 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 the CBC phase = 2), but only the BASIC channel can be specified in the channel_indicator field from the CBC operator.

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

Channel change notification active, this flag determines whether Channel Change Notification (CCN) is enabled in the BSC (TRUE) or not (FALSE).

CICFM=GSM, object: BSC [BASICS] 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, object: BSC [BASICS] 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 Parameter cancelled in BR8.0 due to multi-layer service concept.



CSCH3CSCH4SUP=TRUE, object: BSC [BASICS] range: TRUE, FALSE default: FALSE reference: GSM 03.64 recommended 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) CS-2 268 2 (max. 488 payload bits) CS-3 312 2 (max. 488 payload bits) CS-4 428 2 (max. 488 payload bits)

Consequently, the GPRS coding scheme link adaptation, which 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 Parameter moved to BTS object in BR8.0!

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

DGRSTRGYBCNT= DISABLED, object: BSC [BASICS] range: ENABLED, DISABLED default: DISABLED

Downgrade strategy busy counting, this flag enables/disables the functionality that considers the setting of the parameter DGRSTRGY (see command CREATE BTS [BASICS]) for the traffic load calculation. If DGRSTRGYBCNT is set to ENABLED, the BSC considers the setting of the DGRSTRGY parameter in the - radio TCH load calculation and - Abis TCH load calculation as follows: a) If DGRSTRGY indicates 'GPRS downgrade not allowed' (i.e. DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all (non-reserved) TCHs which are currently busy due to GPRS traffic (PDCH) are considered as 'busy' like any other TCH which 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 DGRSTRGYBCNT is set to DISABLED, the BSC considers all (non-reserved) TCHs which are currently busy due to GPRS traffic (PDCH) as 'busy' (like any other TCH currently seized by a CS call) in any case, no matter what the setting of DGRSTRGY is. Note: This functionality is available via patch in BR8.0 starting from TDPC load 32 (please see release documentation for details).

DLAPDOVL=TRUE, object: BSC [BASICS] 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).

EENHDTMSUP=DISABLED, object: BSC [BASICS] range: ENABLED, DISABLED default: DISABLED

Enable Enhanced DTM Support, this flag enables/disables the 'Enhanced DTM Establish' mode, as defined in 3GPP Release 6.



EFRSUPP=FALSE, object: BSC [BASICS] 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 Parameter was moved from BSC object to BTS object in BR8.0!

Enable HR activation for AMR calls - moved to BTS object in BR8.0.

EISDCCHHO=ENABLE, object: BSC [BASICS] 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, object: BSC [BASICS] 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. When the BSC receives a CIPHER MODE COMMAND from the MSC, the BSC makes the decision for the cipher algorithm to be used by matching the list of allowed cipher algorithms as indicated in the CIPHER MODE COMMAND and the ones defined in the parameter ENCALSUP and selects the best (safest) algorithm (A5/1 is the 'stronger' and safer algorithm and is therefore preferred against A5/2, if both are allowed) for the CIPHERING MODE COMMAND towards the BTS. It is up to the operator to take care that the setting of ENCALSUP matches to the cipher algorithms that are supported by the used BTS SW loads (see BTS SW Release Documentation for details).



ENFOIAHO=TRUE, object: BSC [BASICS] range: TRUE, FALSE default: TRUE Default value changed in BR8.0!

Enable forced intra-cell HO, this parameter enables the procedures a) 'Upgrade of originally downgraded multislot calls' and b) 'Forced Handover due to preferred service layer'. This means that ENFOIAHO should be set to TRUE a) if HSCSD is used in the BSC (parameter ENHSCSD, see below) and if there are not as many adjacent radio TCHs available as were requested for a multislot CS call (HSCSD), or when an HSCSD call was previously downgraded to a smaller bandwidth (smaller number of timeslots) due to the fact that TCH resources were needed for other calls, a channel reconfiguration procedure (using the CHANNEL CONFIGURATION COMMAND / ACKNOWLEDGE messages) is performed which expands the bandwidth again by adding further adjacent timeslots in order to satisfy the original multislot call request to the best possible extent. b) if the feature 'Multilayer Service Layer Support' (MSLS, see command SET BTS [SEVICE]) is applied. If a call is set up on a TRX that belongs to service layer different from the 'preferred' one (i.e. the TRX belongs to a service layer which is not at the TOP of the SLL), the BSC periodically tries to hand over the established call to a TRX of a layer with higher SLL priority. If an idle TCH is found during this check, the handover to the preferred layer is performed. This procedure is triggered and executed exclusively by the BSC: when the described conditions are fulfilled, the BSC 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. Note: For both cases, (a and b) the maintenance bit 12 (MNTBMASK=BIT12, see below) must be set in addition to this parameter.

ENFORCHO=ENABLE, object: BSC [BASICS] 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 MOC or an MTC is attempted in a cell for which a) no idle TCH is available due to radio TCH congestion or b) no Abis TCH is available in the Abis TCH pool associated to the serving BTSM. 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: - 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) (WPS) queuing 4) downgrade of multislot calls (GPRS/HSCSD) may be periodically attempted in parallel and queued calls can be served when down grade is successfully completed. Please refer to the parameters EPRE (for preemption) and EQ (for (WPS) queuing) in command SET BTS [OPTIONS] and to parameter DGRSTRGY (for multislot call downgrade) in command SET BTS [BASICS]. - Setting this parameter to 'enable' only activates the Directed Retry controlled by the BSC, i.e. directed retry to target cells belonging 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 handover 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. Notes on 2G-3G forced handover procedures: For 2G-3G handover due to preemption and O&M intervention also the flag EUIMPHO (see command SET HAND [BASICS] is considered. This is, however, not the case for 2G-3G directed retry. In correspondence with the change request CR2313, 2G-3G directed retry is exclusively controlled by parameter EUSDCHO (see command SET BSC [BASICS]). The distinction between the different forced handover procedures is made on the basis of the currently used channel type. In other words: the BTS does not check the status of the EUIMP flag, if the FORCED HANDOVER REQUEST message is received for an SDCCH. If it is received for a TCH (as is the case for forced handover due to preemption and O&M intervention) the flag is checked and correspondingly considered.



ENHSCSD=FALSE, object: BSC [BASICS] 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, object: BSC [BASICS] range: TRUE, FALSE default: TRUE Default value changed in BR8.0!

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). Note: Interworking of 'Service Dependent Channel Allocation' with traffic load calculation The percentage calculation done for the Enhanced Pairing is done referring only to the TRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea (primary/complementary). Please refer to the command SET BTS [SERVICE] for further explanations.

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

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



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.

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

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, object: BSC [BASICS] 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, object: BSC [BASICS] 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, object: BSC [BASICS] range: TRUE, FALSE default: FALSE

EDGE support, this parameter enables or disables 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).

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

Enable UMTS sufficient coverage network controlled cell reselection, this parameter enables or disables the 'Network Controlled Cell Reselection from GSM/GPRS due to UMTS sufficient Coverage' for GPRS connections. Further relevant parameters are GFDDREPQTY, GFDDMURREP, GTDDMURREP, TFAILNCU (see command CREATE PTPPKF), GMICROCU, USECNONCRESEL and USRSCPNCRESEL (see command CREATE ADJC3G). For the speed-sensitive variant of this feature please see parameter EUMSSNCRESEL in command CREATE PTPPKF. For further details about the criterion 'sufficient coverage' please refer to the corresponding handover parameter EUSCHO (command SET HAND).

EUSDCHO=FALSE, object: BSC [BASICS] 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. The status of this flag is also sent to the BTS during the database alignment procedure. 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 parameter 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. The purpose of this feature is to initiate the TCH allocation already in the 3G neighbour cell (if requested by the MSC for the requested service type) even if the call is set up in the 2G network. 'Service Based Directed Retry' is detected when in the ASSIGNMENT REQUEST message the new IE 'Service Handover Information' is set to 'Handover to either UTRAN or cdma2000 should be performed'. As a result, the BSC sends a FORCED HANDOVER REQUEST message (containing also the aforementioned IEs) towards the BTS. If the response INTERCELL HO CONDITION INDICATION message contains a UTRAN target cell in the target cell list, the BSC tries to hand over the MS/UE to this cell; if only GSM cells are contained in the INTERCELL HO CONDITION INDICATION, these adjacent cells are stored in the BSC; then the normal allocation procedure is started and, in case of congestion, the stored list is used for a normal Directed Retry procedure. This procedure is implemented both for CS and HSCSD calls. Setting EUSDCCHHO to TRUE has the following results: a) the BSC explicitly allows the BTS to include 3G target cells within the INTERCELL HANDOVER CONDITION INDICATION message. This is done by the optional IE 'Service Handover Information' which is included in the FORCED HANDOVER REQUEST message. b) the BTS inserts, if available, the 3G target cells into the target cell list within the INTERCELL HANDOVER CONDITION INDICATION message (as also within the BTS the EUSDCCHHO flag is managed and checked) c) the BSC permits 3G neighbour cells as target cells to be sent to the MSC within the HANDOVER REQUIRED message for ongoing



SDCCH connections. HOSYNC=NOSYNC, object: BSC [BASICS] range: NONSYNC, SYNC default: NONSYNC reference: GSM 04.08 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 Siemens BSS.

HRSPEECH=TRUE, object: BSC [BASICS] 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), object: BSC [BASICS] range: ENABLED(1..100), DISABLED default: ENABLE(30) (minor) ENABLE(60) (major) ENABLE(90) (critical)

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, object: BSC [BASICS] 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, object: BSC [BASICS] 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, object: BSC [BASICS] 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) .

MAXLAPDMN=5, object: BSC [BASICS] range: 5..12 default: 5

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

MAXNCELL=6, object: BSC [BASICS] unit: 1 range: 1..16 default: 6 Default value changed in BR8.0!

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

MISTSTRSH=3, object: BSC [BASICS] range: 1.. 40 default: 3

Missing timeslot threshold, this attribute defines the alarming threshold for the feature 'Detection of missing timeslots on Abis'. If the number of failed consecutive CHAN activations on one Abis timeslot (TSLB) exceeds this threshold, an alarm on all configured SUBTSLB objects (max 4) is emitted. The alarm(s) indicate(s) that the timeslot is missing (e.g. not put into service by the network provider). The configured threshold value is multiplied by 4, i.e. if the value is set to 1 the threshold value is 4 and so on.

MNTBMASK=<DEFAULT>, object: BSC [BASICS] unit: 1 range: BIT1.. BIT61 <DEFAULT>, Null default: 1 parameter range extended in BR8.0!

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): • MNTBMASK=BIT9 is used to enable the PCU overload handling.

When BIT9 is set, BIT10 must be set in addition. Setting these bits is generally recommended.

• MNTBMASK=BIT10 is used to enable delayed TBF release during Mobility Management (MM) procedures. If BIT10 is not set (default value) corresponds to 'Delayed TBF Release' disabled during MM procedures; If MNTBMASK=BIT10 is set, this corresponds to 'Delayed TBF Release' enabled during MM procedures.

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

• MNTBMASK=BIT16 - this setting suppresses the sending of the BSSMAP OVERLOAD message to the MSC in case of Abis LAPD overload (the bit can be set starting from the BR8.0 'DTM load', see release documentation for details). This change avoids interworking problems with Ericsson MSCs.

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

• MNTBMASK=BIT22 is used to suppress the use of variable format in the SYSTEM INFO TYPEx messages which are sent on the Um. It has been verified that, although compliant to Standards, the variable bitmap format included in some SYSINFO messages is not correctly managed by several mobiles in the following scenario: mix of frequencies in the two ranges (0, 1...124) and (975..1023) in the same cell.

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

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

• The setting MNTBMASK=BIT26 is used to enable/disable the following behaviour: when an INTERCELL HANDOVER CONDITION INDICATION message with cause 'better cell' is received from BTS for a DTM capable MS, the BSC will execute the handover when it has analyzed the target cell list and checked if one of the target cells meets the following conditions: 1) DTM is enabled 2) EDGE is configured If no cells meet the condition above, the BSC discards the Power Budget handover request and does not trigger the associated PM counters.

• The setting MNTBMASK=BIT30 and MNTBMASK=BIT31 are used in BR8.0 to control the paging delivery rate from BSC to BTS. The paging delivery rate can be adjusted to values of 100%..130%. These percentage values represent the relative percentage compared to the radio interface paging throughput which depends on the CCCH configuration (for further details please refer to the section 'BSC Overload Handling' in the appendix of this document). The two bits are used as representation of a two-digit binary value to control the setting:

BIT31 BIT30 Paging delivery rate (BSC->BTS) 0 0 130% of Um paging throughput 0 1 120% of Um paging throughput 1 0 110% of Um paging throughput 1 1 100% of Um paging throughput

• The setting MNTBMASK=BIT32 and MNTBMASK=BIT33 are used in BR8.0 to enable the change request CR2870 which is supposed to reduce the length of a HANDOVER COMMAND to the smallest possible size in order to use as few layer 2 messages on the Um interface as possible. This is done to reduce the probability of decoding errors on the MS side for the HANDOVER COMMAND messages: the shorter the message (and the less layer 2 messages are needed for delivery to the MS), the smaller the probability that it is not correctly received by the MS. Messages that cannot be correctly decoded and assembled by the MS lead to call drops during handover. To achieve the smallest possible message size, the CR allows an optimal decoding of the frequency list, e.g. by the usage of a variable bit map in case of handover to a hopping TCH using block wise frequency allocation (coding of up to 32 frequencies is feasible in one FACCH block). If a minimization is not possible then the present coding is used. As there are mobiles on the market which might not support the variable bit length the functionality is administrable by the MNTBMASK bits 32 and 33. Two improvements are introduced: 1) If MNTBMASK=BIT32 is set the DBA subsystem will calculate the effective length of the frequency list encoded by the variable bit map, instead of using the currently fixed value '16'. 2) If MNTBMASK=BIT32 is set, the DBA subsystem will chose the best encoding law, between 'VariableBitMap' and 'Range128', in terms of used bytes. If the frequency list could be encoded with Range128 format (possible if less than 29 frequencies have to be coded), since the two improvements are controlled by two different bits of MNTBMASK, they could be used independently or together.



• The setting MNTBMASK=BIT34 is used to enable the request if the BTSM becomes an additional broadcasting element in the BSS. ???

• If MNTBMASK=BIT38 is set the BS-240XS cannot have SYSID value (see BTS object) equal to GSMDCS, GSM850PCS or GSM850DCS. All the subordinate objects of a BS-240XS must have the same frequency range, no mixed configurations are allowed. The allowed configurations are: BB900, EXT900, PCS1900, DCS1800, GSMR, GSM850. Note: When a resource is allocated on the not preferred layer of its Service Layer List, the resource reallocator will rearrange it by moving towards the preferred layer as soon as resources will be available. This moving procedure is executed only if the MNTBMASK=BIT12 is set (see above).

• If MNTBMASK=BIT35 is set, only R99 onwards GPRS/EGPRS MSs will be controlled by NCCR (NC2), if NCCR is enabled at BSC level; if it is set to 0 (default), all GPRS/EGPRS MSs regardless of their release, will be submitted no NCCR, if enabled at BSC level.

• If MNTBMASK=BIT41 is set, the back-handover prevention mechanism which is usually only enabled for imperative handovers (see parameter NOBAKHO in command SET HAND[BASICS]) is also enabled for Power Budget Handover. This means that, if BIT41 is set, the BSC adds the IE 'Cell List Preferred' containing the cell identity of the handover originating cell to the CHANNEL ACTIVATION message for the target TCH. As a result, back handovers due to 'better cell' towards the originating cell are suspended for the duration defined by the back handover prevention time (see parameter TINHBAKHO in command CREATE ADJC).

• MNTBMASK=BIT42 is used to remove TCH/SD channels in the TCHSDPOOL (see command CREATE CHAN for TCHSD) from channels usable for DTM.

• MNTBMASK=BIT43 is used to enable a 16 bit room saving in DL IMMEDIATE ASSIGNMENT. In this way, the number of frequencies that can fit into DL IMMEDIATE ASSIGNMENT can be increased without splitting it in two parts. This is necessary as the DL IMMEDIATE ASSIGNMENT splitting is a feature which is not correctly supported by many MS on the market. The maximum number of frequencies which currently fit into a single composed DL IMMEDIATE ASSIGNMENT is: - GPRS: 15 frequencies - EDGE: 7 frequencies With bit 43 set the maximum number of frequencies that can fit into a single DL IMMEDIATE ASSIGNMENT is extended to: - GPRS: 31 frequencies - EDGE: 23 frequencies Value 0 (default) disables the extension of frequencies and value 1 enables it.'

• Setting MNTBMASK=BIT44 enables fault tolerant handling of those MSs that do not behave in the proper way for the feature 'Network Controlled Cell Reselection (see parameter proper way. Due to the fact that most of Rel. 97/98 MSs doesn't correctly handle the Network Controlled Order 2 (accepted but no measurements are sent to BSC in order to decide on which cell MS can be moved), there is an additional algorithm implemented at BSC level. The algorithm provides a fault tolerant handling of those MSs that do not behave in proper way, for example because after a Packet Measurement Order message from BSC they do not send any Packet Measurement Report. If no VALID measurement report

arrived at the BSC within the observation time (NTWCREPPTR) the BSC sends a PMO with NC0 to force this faulty MS back to mobile controlled cell reselection mode. The algorithm can be enabled by the operator setting to 1 bit 44 of maintenance bit mask (MNTBMASK attribute of BSC object). Bit 44 is, as default, set to 0, so default behavior is CRs' algorithm disabled.

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, object: BSC [BASICS] 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, object: BSC [BASICS] 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=PHASE2CCEFR, object: BSC [BASICS] range: PHASE1 PHASE2 PHASE2CC PHASE2EFR PHASE2CCEFR default: PHASE2CCEFR Default value changed in BR8.0!

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 signalling) is enabled in the MSC the selected value must be PHASE2EFR, otherwise handover procedures may fail with 'protocol error between BSC and MSC'.



NACCNTWCOR=nc0, object: BSC [BASICS] range: nc0, nc1 default: nc0

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

NCRESELFLAG=ENABLE, object: BSC [BASICS] 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. 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 (Radio Link) 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, object: BSC [BASICS] range: TRUE, FALSE default: FALSE reference: GSM 04.08

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 signalling 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 signalling 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, object: BSC [BASICS] range: GSMDCS, GSMPCS, GSMR, GSM850PCS, GSM850DCS, GSMRAILPUB GSMDCSTSM, GSMPCSTSM default: GSMDCS

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, object: BSC [BASICS] 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 foresees 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 'group 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=NTWSNAP, object: BSC [BASICS] range: NTWSNAP NTWSNAP_STLP default: NTWSNAP

Network card type, up to BR7.0, this parameter used to determine the kind of switching network whether a switching network (SN16, SNAP used in the BSC). As, starting from BR8.0 only high capacity BSC (HC-BSC) configurations are supported, the only allowed values in BR8.0 are NTWSNAP and NTWSNAP_STLP. The value NTWCARD=NTWSNAP_STLP is mandatory if, in addition to the SNAP board, STLP boards are used as PCM interface cards.

OVLSTTHR=9500, object: BSC [BASICS] unit: 1000=10% range: 1000..10000 default: 9500

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

OVLENTHR=8500, object: BSC [BASICS] 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).

PAGCOORCLB=DISABLED, object: BSC [BASICS] range: ENABLED, DISABLED default: DISABLED

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

PAGQOVLIND=DISABLED, object: BSC [BASICS] range: 0..100 default: 0

Paging queue overload indication, this parameter defines a percentage threshold for the indication of the alarm 'BSC PAGING QUEUE OVERLOAD' and the transmission of the BSSMAP message OVERLOAD on the A-interface. The threshold is applied as follows: if the percentage of discarded pagings has exceeded the threshold defined by PAGQOVLIND in the last second, the alarm 'BSC PAGING QUEUE OVERLOAD' is raised and the BSSMAP OVERLOAD message is sent to the MSC.

PCMTYPE=PCM30, object: BSC [BASICS] range: PCM30, PCM24 default: PCM30

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

ROUIPADD0=<NULL>, object: BSC [BASICS] range: 15 character string, <NULL> default: <NULL>

Router IP address 0, this parameter indicates the Router IP address associated to all PCU port 0 (Ethernet port on the PPXU). It is used in order to support High speed Gb Interface. The convention used for this value is the dotted decimal format (e.g. '172.31.21.88'). Note: The attributes ROUIPADD0, ROUIPADD1, SUBNETMASK0, SUBNETMASK1 are necessary only if SGSN is connected to BSC via router. If the router is not present, these attributes must be set to <NULL>. In case of co-located SGSN without a router between BSC and SGSN the following configuration rules apply: - the operator sets to <NULL> both Router IP Address 0 and 1 (parameters ROUIPADD0, ROUIPADD1), so that each PPXU's routing table contains no entry for default gateways - all SGSN and PPXU IP Adresses must belong to same IP subnets (as identified by two respective subnet masks, parameters SUBNETMASK0, SUBNETMASK1).

ROUIPADD1=<NULL>, object: BSC [BASICS] range: 15 character string, <NULL> default: <NULL>

Router IP address 1, this parameter indicates the Router IP address associated to all PCU port 1. For further information please refer to parameter ROUIPADD0 (see above)

SIMSCREL99=TRUE, object: BSC [BASICS] range: TRUE, FALSE default: TRUE Default value changed in BR8.0!

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 signalling 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 Moved to CPCU object in BR8.0.

SPEED145=FALSE, object: BSC [BASICS] 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].

SPENLAW=A_LAW, object: BSC [BASICS] 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)

SUBNETMASK0=<NULL>, object: BSC [BASICS] range: 15 character string, <NULL> default: <NULL>

Sub net mask 0, this parameter is the NetMask for IP address of the PPXU-External router associated to all PCU port 0 (Ethernet port on the PPXU). It is used in order to support High speed Gb Interface. The value must be assigned according to the local LAN configuration. The convention used for this value is the dotted decimal format (e.g. '255.255.255.0'). Note: The attributes ROUIPADD0, ROUIPADD1, SUBNETMASK0, SUBNETMASK1 are necessary only if SGSN is connected to BSC via router. If the router is not present, these attributes must be set to<NULL>. In case of co-located SGSN without a router between BSC and SGSN the following configuration rules apply: - the operator sets to <NULL> both Router IP Address 0 and 1 (parameters ROUIPADD0, ROUIPADD1), so that each PPXU's routing table contains no entry for default gateways - all SGSN and PPXU IP Adresses must belong to same IP subnets (as identified by two respective subnet masks, parameters SUBNETMASK0, SUBNETMASK1).

SUBNETMASK1=<NULL>, object: BSC [BASICS] range: 15 character string, <NULL> default: <NULL>

Sub net mask 1, this parameter this parameter is the NetMask for IP address of the the PPXU-External router associated to all PCU port 1 (Ethernet port on the PPXU). For further details please refer to parameter SUBNETMASK0 (see above).



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

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

T3122=5, object: BSC [BASICS] unit: 1s range: 0..255 default: 5 Reference: GSM 04.08

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.

T3197=5, object: BSC [BASICS] unit: 0.5s range: 3.. 5 default: 4

T3197, this timer is relevant for the feature Dual Transfer Mode (DTM, see parameter EDTMSUP in command CREATE PTPPKF] and defines the maximum duration by which the BSC will delay the release of the RR connection.

TCBCSI=1, object: BSC [BASICS] unit: 1 minute range: 0..1440 default: 1

Timer for CBC service interruption. The BSC transiently stores all Short Message Service Cell Broadcast (SMS-CB) 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 TCBCSI=0 means: The SMS-CB messages are not cleared from the TDPC memory - therefore the RESTART INDICATION towards the CBC is not necessary after BTS recovery..

TDTMWIND=5, object: BSC [BASICS] unit: 1s range: 0..255 default: 5 Reference: GSM 04.08

Timer DTM wait indicator, this timer is relevant for the feature Dual Transfer Mode (DTM, see parameter EDTMSUP in command CREATE PTPPKF] and defines the waiting time, before MS may send a DTM-Request Indicator again after receipt of a DTM REJECT message. The value of this timer is sent to the MS in within the DTM REJECT message.

TGUARDTCHSD =SEC10, object: BSC [BASICS] range: SEC00, SEC10, SEC11, SEC12, SEC13, SEC14, SEC15 default: SEC10 default value changed in BR8.0 !

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 prepare 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 in the SDCCH_BACKUP_POOL 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.

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

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



- Attention: The calculation of the SDCCH load that is compared to the 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, object: BSC [BASICS] (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, object: BSC [BASICS] 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.



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

Transparent messages, this parameter is relevant for a new BR8.0 Performance Measurement Counter called 'Mean number of busy SDCCHs per signalling procedure (MBUSYSSP)'. The purpose of this counter is to allow a more detailed observation of the SDCCH traffic with respect to the traffic type that was processed via the allocated SDCCH. Different subcounters distinguish the mean number of busy SDCCHs for - Signalling for TCH connection (MOC, MTC) - Short Message Service (SMS-MO and SMS-MT) - SS Supplementary Service Management (SCI) - USSD Transactions - other signalling procedures (Location Update, IMSI Detach etc.) - abnormal SDCCH activations (e.g. no ESTABLISH INDICATION received for activated SDCCH). One central requirement for the introduction of the counter MBUSYSSP was the possibility to count USSD procedures (Unstructured Supplementary Service Data) separately. USSD procedures are non-standardized Supplementary Service procedures that may be defined operator specifically and which allow the subscribers to control particular network- specific services by entering specific service codes as key combination on the mobile phone. As the general signalling message sequence for USSD transaction is exactly the same like for SCI procedures for standardized SS procedures, the distinction between both cases is only possible if the BSC analyzes the contents of the FACILITY messages which are normally transparent for the BSS. This 'in depth' analysis of normally transparent messages, however, considerably increases the TDPC processor load. For this reason, the parameter TRANSPM was introduced to allow the operator to avoid the described TDPC performance impact if a separate counting of standardized SCI procedures and USSD transactions is not required:a) If TRANSPM is set to TRUE and the measurement MBUSYSSP is activated, then USSD transactions will be counted separately by the subcounter for 'USSD signalling'. The subcounter 'SS Management' will only count all other standardized SCI procedures. In this case the TDPC processor load is increased by the necessary additional analysis efforts. b) If TRANSPM is set to FALSE and the measurement MBUSYSSP is activated, then USSD transactions will be counted together with all other standardized SCI procedures by the subcounter 'SS Management'. In this case the TDPC processor load is not affected.



TRFCT=20, object: BSC [BASICS] 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) Compression-Decompression handover: On every expiry of TRFCT the BSC checks a) the traffic load in its cells and compares it to the threshold HRACTAMRT1/HRACTAMRT2, HRACTT1/HRACTT2 (for compression handover) and FRACTTH1/FRACTTH2 and FRACTAMRTH1/FRACTAMRTH2 (for decompression handover, see command SET BTS [BASICS]) or/and b) the Abis pool TCH load towards a particular BTSM and compares it to the threshold ABISHRACTTHR and ABISFRACTTHR. If, based on the thresholds and the current TCH load the BSC detects the condition for compression or decompression handover, the BSC enables the compression or decompression handover in the affected BTS by sending an LAPD O&M message SET ATTRIBUTE with the appropriate indication to the BTS. This indication starts the Compression/Decompression handover decision process in the BTS. For further details, please refer to the parameter EADVCMPDCMHO (see command SET HAND [BASICS].



TRFPS=FALSE, object: BSC [BASICS] 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).

TYPOFAMC=DK40, object: BSC [BASICS] range: DK40, CPEX, ES

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

TYPOFETH=DK40, object: BSC [BASICS] range: ETHERNETII, IEEE802 default: ETHERNETII

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

UPGRFREQ Moved to CPCU object in BR8.0.

Creating new database parameters without info model change:

BRIDGE BSC:

<The BRIDGE BSC command was introduced to avoid high development cost CR solutions that are introduced on customer pressure within a life cycle of a release. BRIDGE BSC allows the introduction/management of new configurable database parameters, required by change requests (CR) in the latest phases of a release, without any further InfoModel change. Nearly all CRs introducing new functionalities require an enabling/disabling mechanism, and most of them require also some specific attributes. In general the modelling of attributes is decided in accordance with R&D. In the subsequent releases the management of these new database parameters, already known and used by customers, can be moved into the specific command/object of the info model in correspondence with the parameters' association to a particular object. The databases are automatically converted correctly by DBAEM and CONVFILE tools.>

NAME=BSC:0, Object path name. ATT1=<NULL>, object: BSC format: parameter name - parameter value range: parameter name: '<15 characters string>' - parameter value <value as defined by R&D> default: <NULL>

Attribute 1, this parameter allows the definition of a new attribute name and its attribute value. The association of this parameter to a particular database command and object is defined by the parameters RELCMD and RELOBJ (see below). The ATTx parameter value consists of two parts a) a parameter name, which consists of a symbolic name string (max. 15 characters) and b) the associated parameter value as defined by R&D. the following example may illustrate the application of the BRIDGE BSC command

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

The equivalent for this command in classic syntax would be: SET BTS:

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

ATT2..ATT8=<NULL>, object: BSC format: parameter name - parameter value range: parameter name: '<15 characters string>' - parameter value <value as defined by R&D> default: <NULL>

Attribute 2 .. Attribute 8, these parameters allow the definition of additional parameters and values (see parameter ATT1).

RELCMD=<NULL>, object: BSC range: SET, GET default: <NULL>

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

RELOBJ=<NULL>, object: BSC range: <object path name> default: <NULL>

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

Setting the alarm priorities of the BSS functional objects:

SET BSC [ALARMSEV]:

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

NAME=BSC:0, Object path name. ALRMSEVBTS=CRITICAL, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Critical

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

ALRMSEVBTSM=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVBTSMTD=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVBTSTD= CRITICAL, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Critical

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

ALRMSEVCBCL =MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVFRL=MINOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Minor

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

ALRMSEVIPLI=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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



ALRMSEVLPDLM=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVLPDLMTD= MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVLPDLR=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVLPDLRTD= MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVLPDLS=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVNSVC=MINOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Minor

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

ALRMSEVOMAL=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVPCMA=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVPCMB=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVPCMG=MAJOR; object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVPCMS=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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



ALRMSEVPCU=CRITICAL, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Critical

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

ALRMSEVPCUTD= CRITICAL, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Critical

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

ALRMSEVPTPPKF=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVTDCU=CRITICAL, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Critical

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

ALRMSEVTRAU=CRITICAL, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Critical

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

ALRMSEVTRX=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVTRXTD=MAJOR, object: BSC [ALARMSEV] range: Minor, Major, Critical 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] range: alphanumeric string (6 characters) in quotation marks default: '010101'

Equipment position, this attribute defines the position of the Network Element.

EAUTOREC=ENABLED, object: BSC[REMINV] range: ENABLED, DISABLED default: DISABLED

Enable auto recovery, this attribute enables the automatic recovery.

Setting the alarm priorities of the BSCE objects:

SET BSCE [ALARMSEV]:

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

NAME=BSCE:0, Object path name. ALRMSEVCPEX=CRITICAL, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Minor

Alarm 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, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVDK40=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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



ALRMSEVEPWR=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVIXLT=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVLICD=MINOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Minor

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

ALRMSEVLICDS=MINOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Minor

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

ALRMSEVME2M=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVMEMT=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVMPCC=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVNTW=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVPPCC Cancelled in BR8.0 ALRMSEVPPCU Cancelled in BR8.0 ALRMSEVPPLD Cancelled in BR8.0 ALRMSEVPPXL=MINOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVPPXP=MINOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Min or

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



ALRMSEVPPXT=MINOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Min or

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

ALRMSEVPPXU=MINOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Min or

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

ALRMSEVPWRD=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVSYNC=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVSYNE=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVTDPC=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVX25A=MAJOR, object: BSCE [ALARMSEV] range: Minor, Major, Critical default: Major

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

ALRMSEVX25D=MAJOR; object: BSCE [ALARMSEV] range: Minor, Major, Critical 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

CREATE PPLD Cancelled - PPLD is no longer supported in BR8.0!

Creating the common attributes for all PCUs belonging to the entire BSC: < The CPCU object was introduced with BR8.0 to define attributes

common for several PCUs belonging to the BSC. Please note that many parameters were moved from the PCU object to the CPCU object in BR8.0. >

CREATE CPCU: NAME=CPCU:0, Object path name. Range for pcun = 0..11

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

DNLBSSPFCRET=3, object: CPCU range: 1.. 5 default: 3

Download BSS PFC Retries, this parameter guards the DOWNLOAD-BSS-PFC-RETRIES number.

DNLBSSPFCT=50, object: CPCU unit: 100ms range: 2.. 99 default: 50

Download BSS PFC Timer, this parameter represents the timer T6 and guards the DOWNLOADBSS-PFC procedure.

FCRATE=100, object: CPCU range: 0.. 100 default: 100

Lowpass filter coefficient leak rate, this parameter is the Low Pass Filter Coefficient used to filter Leak_Rate oscillation. The filtering applied is the following: Rmax_eFC=alpha*Rmax(Tnow)+(1-alpha)*Rmax(Tnow-C).

MODBSSPFCRET=3, object: CPCU range: 1.. 5 default: 3

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

MODBSSPFCT=50, object: PCU unit: 100ms range: 2.. 99 default: 50

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

N3101=20, object: CPCU range: 9..255 default: 20 Default value changed in BR8.0!

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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.



N3103=10, object: CPCU range: 1.. 255 default: 10

This parameter defines the threshold for 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

N3105=10, object: CPCU 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

NBVCBR=3, object: CPCU 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

NBVCRR=3, object: CPCU 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

NBVCUR=3, object: CPCU 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

NRACPBLUPDRET=3, object: CPCU range: 1.. 30 default: 3

Number of RA capability update retries, this parameter provides the maximum number of retransmission of RA-Capability-Update to SGSN when BSC does not accept correspondent answer (RA-Capability-Update-Ack) from SGSN.



NRLCMAX=20, object: CPCU range: 20..64 default: 20

This parameter specifies the rate of PACKET UPLINK ACK/NACK and PACKET DOWNLINK ACK/NACK messages being used during packet transfers in RLC/MAC acknowledged mode. During UL TBFs: After each reception of NRLCMAX UL data 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 station. 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 is allocated on 4 timeslots, the effective polling distance is defined by (NRLCMAX-12). This reduced polling period (every 15th/8th 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). Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

PREAT=20, object: CPCU unit: 100ms range: 0.. 100 default: 20

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

SISGSNREL99=TRUE, object: CPCU range: TRUE, FALSE default: TRUE Default value changed in BR8.0!

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 signalling towards the network, which is a mandatory precondition for specific 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 signalling 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. Note: This parameter was moved from the BSC object to the CPCU object in BR8.0.

T1=10, object: CPCU unit: 1s range: 2.. 29 default: 10

This timer defines the 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). Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.




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). Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

T3=50, object: CPCU unit: 0,1s range: 1.. 100 default: 50 (= 5s)

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


T3141, 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 elapses before a successful contention resolution procedure is completed, the newly allocated TBF is released. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

T3169=5, object: CPCU unit: 1s range: 1.. 30 default: 5 Default value changed in BR8.0!

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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

T3172=5, object: CPCU 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

T3191=5, object: CPCU unit: 1s range: 1-30 default: 5

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

T3193=4, object: CPCU unit: 100 ms range: 1-42 default: 4

T3193, this timer defines the time to wait for a reuse of the TFI after reception of the final Packet Downlink Ack/Nack from the 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). Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.



T3195=5, object: CPCU unit: 1s range: 0..255 default: 5 Default value changed in BR8.0!

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.

T4=10, object: CPCU unit: 0,1s range: 1.. 100 default: 10 (= 1s)

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

T5=10, object: CPCU range: 2.. 29 default: 10

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

TEMPCH=30, object: CPCU unit: 1s range: 1.. 254 default: 30 Default value changed in BR8.0!

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 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 (see command CREATE BTS [BASICS]). 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 (in command CREATE BTS [BASICS]. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.



TEMPPDT=1, object: CPCU unit: 1s range: 1.. 30 default: 15

Timer for empty PDT, this parameter is the equivalent to the parameter TEMPCH (see above) for Packet Data Terminal (PDT) resources allocated on the PCU. TEMPPDT determines the delay time for the release of an allocated PDT with subframe counter > 0 if the related PDCH does not require this PDT anymore (e.g. due to 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

TEXTULTBF=15, object: CPCU unit: 1s range: 0.. 49 default: 15

Time extended Uplink TBF, this attribute is used to delay the release of an UL Temporary Block Flow (TBF) in Extended UL TBF mode.

TF=6, object: CPCU range: 6.. 5999 default: ???

TF, when SGSN receives PFC FLOW CONTROL parameters, SGSN starts TF Timer. When TF expires SGSN may use SGSN Bmax and R generated and not more last Bmax and R sent by BSC. TF is restarted each time a PFC FLOW CONTROL parameters are received.

TF1=5, object: CPCU unit: 1s range: 2.. 9 default: 5 GSM: 08.18 Default value changed in BR8.0!

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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

TH=6, object: CPCU range: 6.. 5999 default: ???

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

THPROXT=500..50..550, object: CPCU 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: CPCU 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

TIMEDTBFREL=15 object: CPCU unit: 100ms range: 0.. 49 default: 15

Time delay for TBF release, this timer is used to delay the 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). Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

TPFCBUFF=20 object: CPCU unit: 1s range: 5.. 30 default: 20

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

TSULBAL=20, object: CPCU range: 0..100 default: 20

Timer switch 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. Note: This parameter was moved from the PCU object to the CPCU object in BR8.0.

UPGRFREQ=SEC1-SEC1, object: CPCU 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. Note: This parameter was moved from the BSC object to the CPCU object in BR8.0.

Creating the PCU objects: < The PCU functional object represents the packet control unit

designed to implement GPRS/EDGE services in the SBS. The creation of a PCU implies the creation of a PPXU card (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,…,5 HC BSC 72 (PPXX; QTLP) - pcun = 0,…,11 HC BSC 120 (PPXX; STLP)

BCGRTODIFFSERV=0, object: PCU range: 0.. 63 default: 0

Background to Different Service, this parameter represents the mapping between background class and DSCP coding.

BEPFITODIFFSERV=0, object: PCU range: 0.. 63 default: 0

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

CPCUN=0, object: PCU range: 0..11

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

DIFFSERVSUP=<NULL>, object: PCU range: DISABLED (0) ENABLED (1) <NULL> default: see description

Different Service Support, the default of DIFFSERVSUP depends on the value of GBSNS attribute:

GBSNS (value) FRFIX IPV4 DIFFSERVSUP (default) NULL DISABLED

GBSNS=FRFIX, object: PCU range: FRFIX, FRVAR, PV4 default: FRFIX

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

INTRTRFH2TODIFFSERV=0, object: PCU range: 0.. 63 default: 0

Interactive traffic handling priority 2 to Different Service, this parameter represents the mapping between interactive class with traffic handling 2 and DSCP coding.





MTU=<NULL>, object: PCU range: 68 .. 1500 <NULL> default: see description

Maximum transmission unit, this parameter indicates the maximum transmission unit, i.e. the size of the largest packet that can be transmitted on the Ethernet. The default value of this parameter depends on the value of GBSNS attribute:

GBSNS (value) FRFIX IPV4 MTU (default) NULL 1500

N3101 Moved to CPCU object in BR8.0 N3103 Moved to CPCU object in BR8.0 N3105 Moved to CPCU object in BR8.0 NBVCBR Moved to CPCU object in BR8.0 NBVCRR Moved to CPCU object in BR8.0 NBVCUR Moved to CPCU object in BR8.0



NMO=NMO_2, object: PCU range: NMO_1, NMO_2, NMO_3 default: NMO_2

Network 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 that is used for GPRS paging (i.e. CCCH or, if configured, PCCCH) or on a GPRS traffic channel (PDCH). Therefore the MS only needs to monitor this one and only paging channel and it receives circuit-switched pagings even if it is in packet transfer mode via the PDCH (when allocated). CS 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 between MSN and SGSN. 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 (i.e. when a PDCH is allocated). A PBCCH must not be created in the cell when NMO_2 is used! 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. The following table summarizes the described modes:

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

NNSVCBLKR Moved to CPCU object in BR8.0 NNSVCRR Moved to CPCU object in BR8.0 NBVCUR Moved to CPCU object in BR8.0 NNSVCTSTR=10, object: PCU range: 1.. 30 default: 10

This parameter specifies the Number of 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 Moved to CPCU object in BR8.0 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.

PFCFCSUP=FALSE, object: PCU range: TRUE, FALSE default: FALSE

Packet flow context flow control support, this parameter is used to indicate whether the Enhanced Flow Control is enabled or not. This value is TRUE if BSC supports the Enhanced Flow Control.

PFCSUP=DISABLED, object: PCU range: ENABLED, DISABLED default: DISABLED

Packet flow context support, this parameter allows to enable/disable the Packet Flow Context procedure support.

PORT0=<NULL>, object: PCU range: string 7..15 chars default: <NULL>

Port 0, this parameter indicates the IP address for the PCU. The convention used for this value is the dotted decimal format (e.g. '255.255.255.0').

PORT1=<NULL>, object: PCU range: string 7..15 chars default: <NULL>

Port 1, this parameter indicates the IP address for the PCU. The convention used for this value is the dotted decimal format (e.g. '255.255.255.0').

SMSPFITODIFFSERV=0, object: PCU range: 0.. 63 default: 0

SMS PFI to Different Service, this parameter represents the mapping between predefined PFI SMS parameter and DSCP coding.

SPFITODIFFSERV=0, object: PCU range: 0.. 63 default: 0

Signalling PFI to Different Service, this parameter represents the mapping between predefined PFI signalling parameter and DSCP coding.

SNSADDRET=<NULL>, object: PCU range: 0.. 16 <NULL> default: see description

Subnetwork service address retries, the default value of this parameter depends on the value of GBSNS attribute:

GBSNS (value) FRFIX IPV4 SNSADDRET (default) NULL 3

SNSCHWEIRET=<NULL>, object: PCU range: 0.. 16 <NULL> default: see description

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

GBSNS (value) FRFIX IPV4 SNSCHWEIRET (default) NULL 3

SNSCONFRET=<NULL>, object: PCU range: 0.. 16 <NULL> default: see description

Subnetwork Service configuration retries, the default of this parameter depends on the value of GBSNS attribute:

GBSNS (value) FRFIX IPV4 SNSCONFRET (default) NULL 3

SNSDELRET=<NULL>, object: PCU range: 0.. 16 <NULL> default: see description

Subnetwork Service delete retries, the default of this parameter depends on the value of GBSNS attribute:

GBSNS (value) FRFIX IPV4 SNSDELRET (default) NULL 3

SNSSIZERET=<NULL>, object: PCU range: 0.. 16 <NULL> default: see description

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

GBSNS (value) FRFIX IPV4 SNSSIZERET (default) NULL 3

STPIPEP=<NULL>, object: PCU format: <ipAddress>-<udpPort> range: ipAddress: string 7...15 chars udpPort: 1024 ... 65535 default: <NULL>

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

STREAMSUP=DISABLED, object: PCU range: ENABLED, DISABLED default: DISABLED

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

STREAMTODIFFSERV=0, object: PCU range: 0.. 63 default: 0

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

TSNPRO=<NULL>, object: PCU range: 0.. 16 <NULL> default: see description

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

GBSNS (value) FRFIX IPV4 TSNPRO (default) NULL 10

TYPOFNSVCCONF=<NULL>, object: PCU range: 0.. 16 <NULL> default: see description

Type of NSVC Configuration, this parameter indicates the method of configuration of the NS-VCs for the IP sub network service. The default of this parameter depends on the value of GBSNS attribute:

GBSNS (value) FRFIX IPV4 TYPOFNSVCCONF (default) NULL STATIC

T1 Moved to CPCU object in BR8.0 T2 Moved to CPCU object in BR8.0 T3141 Moved to CPCU object in BR8.0 T3169 Moved to CPCU object in BR8.0 T3172 Moved to CPCU object in BR8.0 T3169 Moved to CPCU object in BR8.0 T3191 Moved to CPCU object in BR8.0 T3193 Moved to CPCU object in BR8.0 T3195 Moved to CPCU object in BR8.0 TEMPCH Moved to CPCU object in BR8.0 TEMPPDT Moved to CPCU object in BR8.0 TF1 Moved to CPCU object in BR8.0

THPROXT=500..50..550, object: PCU format: thproxt1-thproxt2-thproxt3 unit: thproxt1: 1ms thproxt2: 1s thproxt3: 1s range: thproxt1: 10..999 thproxt2: 1..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 Moved to CPCU object in BR8.0 TIMEDTBFREL Moved to CPCU object in BR8.0 TNSVCBLK=3, object: PCU unit: 1s range: 1.. 10 default: 3

This timer defines the 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 Moved to CPCU object in BR8.0

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

BTSEn

LI port

1

LI port

2

BSC

QTLP port

B

QTLP port A

= transmit direction layer-1 timeslot = transmit direction traffic & signalling= receive direction traffic & signalling



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 LICD 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 STLP 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 STLP 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 STLP 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:

STLP port

BTSE

B

PCMB 0 A

SINGLE_TRUNK mode:

STLP port

BTSE

B BTSE PCMB 1

BTSE

PCMB 0 A

DOUBLE_TRUNK mode:

STLP 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 signalling if the currently active one fails. Note: If the link redundancy is set to DUPLEX both traffic and signalling 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 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: 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

TRAU

DOUBLE_TRUNK mode:

QTLPport

PCMS 1

PCMS 0 A

B

TRAU

TRAU

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



AECST=DISABLED, object: TRAU range: ENABLED, DISABLED default: DISABLED

Acoustic Echo Control activation status, this parameter determines whether the feature Acoustic Echo Control feature is enabled or not.

ALCST=DISABLED, object: TRAU range: DISABLED, EDDLONLY, EDULONLY, EDULDL default: DISABLED

Acoustic Level Control activation status, this parameter determines whether the feature Acoustic Level Control feature is enabled and, if yes, whether it is enabled for uplink and downlink or only one direction.

ALCTGTLEV=m19dBM0, object: TRAU range: ITU, m23dBM0, m22dBM0, m21dBM0, m20dBM0, m19dBM0, m18dBM0, m17dBM0, m16dBM0, m15dBM0 default: m19dBM0

Acoustic Level Control target level, this parameter indicates the target speech level for the Automatic Level Control. Target level is applicable to both directions if both enabled. It is possible to choose between ITU-T G.169 compliant mode (value ITU) and Siemens Enhanced solution with customizable settings.

BULKDCONF= DELAY_160_ms, object: TRAU step size:range: DELAY_0_ms, DELAY_10_ms, DELAY_20_ms, DELAY_30_ms, … DELAY_740_ms, DELAY_750_ms, AUTOMATIC_LINK_DETEC- TION default: DELAY_160_ms

Bulk delay configuration, this parameter is used for the default configuration of the terrestrial link. The Automatic Link Detection monitors two default windows, terrestrial (160-260 ms) and satellite window (650-750 ms), until one of two links is detected. The manual configuration is a particular case of automatic link working where the two windows are adjacent and the operator can insert the lower limit of the first window (bulk delay).

ETFO=FALSE, object: TRAU range: TRUE, FALSE default: FALSE Reference: GSM 04.53

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.

INTCTMST=DISABLED, object: TRAU range: ENABLED, DISABLED default: DISABLED

Integrated Cellular Telephone Modem status, this parameter determines whether the feature 'Integrated Cellular Telephone Modem' is enabled or not.

NOIREDA=DISABLED, object: TRAU unit: dB range: -18... -6 (dB) default: -12

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

NOIREDST=DISABLED, object: TRAU range: ENABLED, DISABLED default: DISABLED

Noise reduction status, this parameter determines whether the feature 'Noise reduction' is enabled or not.

PCMSN=0, object: TRAU range: 0..19

PCMS-no..

SALUNAME='BSC1TRAU0', object: TRAU range: alphanumeric string (11 characters) in quotation marks default: NOT_DEFINED

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.

VQEST=DISABLED, object: TRAU range: ENABLED, DISABLED default: DISABLED

Voice quality enhancement status, this parameter determines whether the feature 'Voice Quality Enhancement' is enabled or not.

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) timeslot-no. 1-24 (PCM24) subslot-no. 0..3

Asub channel: pcms-no. - timeslot (- subslot).

LAPDPOOL=0, object: LPDLS range: 0..1 default: (LAPD pool is assigned by the BSC automatically)

LAPD pool, up to BR7.0 this parameter used to define the LAPDPOOL the LPDLM should be assigned to. A ' LAPD Pool ' was a logical instance which represented a group of LAPD channels (LPDLM, LPDLR, LPDLS) that could be managed by one PPLD. Since in BR8.0 the PPLD boards are no longer supported also this meaning of the parameter does no longer exist. For PPXL, the parameter LAPDPOOL assumes the meaning of 'primary PPXL' (i.e. the module no. of the PPXL where the LAPD must work if both PPXL are in service). 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 default: NOT_DEFINED 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)



Coding Pool Supported channels and speech coding algorithms

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)



Coding Pool Supported channels and speech coding algorithms 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



Coding Pool Supported channels and speech coding algorithms

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 default: NOT_DEFINED 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 range: licd-no. 0..8 port-no. 0..1 (DTLP) 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,

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, this parameter represents the error threshold of the polling procedure (based on N391 counter) used to put the FRL in 'disabled' state.

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.. ABISFRACTTHR=30, object: BTSM unit: 1 % range: 0..100 default: 30

BTSM Abis TCH load threshold for FR activation, this parameter this parameter is only relevant if the parameters EADVCMPDCMHO and EADVCMPHOAMR (for AMR calls) and EADVCMPHOSC (for non-AMR calls) are set to TRUE (for the parameters please see SET HAND [BASICS]). It defines the lower Abis pool TCH load threshold for load-dependent decompression handover. The task of this handover type is to hand over as many calls that currently occupy a HR (or AMR-HR) TCH to an (E)FR (of AMR FR)TCH as possible to provide the best possible QoS and speech quality in time periods with an acceptably low TCH load and Abis pool 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 FRACTTH1 and FRACTAMRTH1) and the current Abis TCH traffic load of its BTSMs and compares it to the threshold ABISFRACTTHR. For Decompression handover the BSC calculates the BTSM Abis traffic load as follows Attention: - Generally a 16 kbit/s Abis TCH (SUBTSLB) is counted as 2, an 8 kbit/s HR subslot of the SUBTSLB is counted as 1! - (*) The 'no. of Abis pool TCH not available for CS TCH allocation' includes - SUBTSLBs in usage state „busy' ** - SUBTSLB in usage state „locked' or „shutting down' - (**) A SUBTSLB in usage state „busy' (i.e. both HR subslots busy) is counted as 2 while a SUBTSLB in usage state „active' (only one HR subslot busy) is counted as 1. - The GPRS downgrade strategy (see parameter DGRSTRGY in the command CREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the 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 parameters DGRSTRGY and DGRSTRGYBCNT, as these subslots are in any case immediately preempted if a CS TCH request meets a TCH congestion situation.

If the Abis pool TCH load of the BTSM drops below the threshold ABISFRACTTHR, the BSC enables decompression handover in the BTSs subordinate to the affected BTSM by sending a SET ATTRIBUTE message with the appropriate indications to the BTSs. This message triggers the start the load-dependent AMR decompression handover decision process in the BTS. For further details, please refer to the parameter EADVCMPDCMHO (see command SET HAND [BASICS]).

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

no. of Abis pool TCH in state unlocked/enabled



ABISHRACTTHR=60, object: BTSM unit: 1 % range: 0..100 default: 60

BTSM Abis TCH load threshold for HR 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) 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 CREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). a) If DGRSTRGY indicates 'GPRS downgrade not allowed' (i.e. DOWNGRADE_HSCSD_ONLY or NO_DOWNGRADE), then all Abis subslots 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 parameters DGRSTRGY and DGRSTRGYBCNT, 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 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 BTS [BASICS]) is set to TRUE, the HR activation also goes for AMR calls.

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

no. of configured Abis pool TCHs

b) Enhanced Pairing of half rate TCH due to Abis TCH load The feature 'Enhanced Pairing of TCH/H' (see parameter EPA 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'! - The GPRS downgrade strategy (see parameter DGRSTRGY in the command CREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the 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 parameters DGRSTRGY and DGRSTRGYBCNT, as these subslots are in any case immediately preempted if a CS TCH request meets a TCH congestion situation.

For further details please refer to the parameter EPA (in command SET BSC). c) Compression handover due to Abis TCH load The task of Compression handover is, in case of high TCH load, to transfer AMR-FR or (E)FR calls with suitably good radio link quality to an AMR-HR or HR TCH by an intracell handover in order to prevent TCH blocking by providing additional TCH resources. Whether AMR calls or/and non AMR calls are considered for this type of handover, depends on the setting of the parameters EADVCMPHOAMR and EADVCMPHOSC (see command SET HAND[BASICS]). On every expiry of the timer TRFCT (see SET BSC) the BSC 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 Compression handover the BSC calculates the BTSM Abis traffic load as follows Attention: - Generally a 16 kbit/s Abis TCH (SUBTSLB) is counted as 2, an 8 kbit/s HR subslot of the SUBTSLB is counted as 1! - (*) The 'no. of Abis pool TCH not available for CS TCH allocation' includes - SUBTSLBs in usage state „busy' ** - SUBTSLB in usage state „locked' or „shutting down' - (**) A SUBTSLB in usage state „busy' (i.e. both HR subslots busy) is counted as 2 while a SUBTSLB in usage state „active' (only one HR subslot busy) is counted as 1. - The GPRS downgrade strategy (see parameter DGRSTRGY in the command CREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the 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 parameters DGRSTRGY and DGRSTRGYBCNT,

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

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



as these subslots are in any case immediately preempted if a CS TCH request meets a TCH congestion situation.

If the Abis pool TCH load of the BTSM exceeds the threshold ABISHRACTTHR, the BSC enables 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 Compression handover decision process in the BTS. For further details, please refer to the parameter EADVCMPDCMHO (see command SET HAND [BASICS]).

ABISTRFHITHR=90, object: BTSM unit: 1% range: 50..100 default: 90

Abis Traffic handover high threshold, this parameter is the equivalent to the parameters 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: 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 CREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the 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 parameters DGRSTRGY and DGRSTRGYBCNT, as these subslots are in any case immediately preempted if a CS TCH request meets a TCH congestion situation.

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 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: 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 CREATE BTS [BASICS]) has an influence on the Abis traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the 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 parameters DGRSTRGY and DGRSTRGYBCNT, as these subslots are in any case immediately preempted if a CS TCH request meets a TCH congestion situation.

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

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

no. of Abis TCH in state unlocked/enabled

EINTSITSYN=FALSE, object: BTSM range: TRUE, FALSE, <NULL> default: FALSE

Enable Inter-Site Synchronization, this parameter determines whether the feature 'Inter-Site Synchronization' (ISS) is enabled or not. The feature ISS is mainly relevant for networks with a tight frequency reuse pattern (e.g. 1/1 or 1/3) and interference management based on MAIO planning for the (synthesizer) hopping frequencies. For other network types this feature is not really relevant. Purpose and principle of the ISS feature Usually the frequency planning in a GSM network is done in such a way that co-channel interference and adjacent channel interference between adjacent or colocated sites is avoided by an intelligent allocation of TRX frequencies and frequency subsets among the cells to be covered. However, in some networks the frequency spectrum granted to the operators is so small that the number of available frequencies does not allow a suitable frequency distribution, especially if the network must handle considerable traffic capacities. In these networks, the resource planning can therefore not be based on the frequencies only and a different approach must be used. Usually, in such networks, frequency planning is reduced to the BCCH-TRXs only. For the non-BCCH-TRXs the operator may decide to deploy e.g. a 1/1 frequency reuse pattern, which means that the non-BCCH-TRXs TRXs use the same set of hopping frequencies. In such configurations the interference can be minimized by minimization of possible collisions of the hopping channels by an intelligent MAIO distribution (please see also explanations given for the feature DMA Admission Control in command SET BTS [ADM]), especially when the same hopping sequence (see parameter HSN in command CREATE FHSY and CREATE CFHSY) is used in all cells. However, to achieve a controlled time de-coupling of the resources by an intelligent separation of MAIO values among the TRXs (and thus to optimally avoid co-channel interference and adjacent channel interference) the cells within a site and cells belonging to different sites must be, in a first step, time-aligned and synchronized. In a second step, the hopping patterns of the different TRXs can then be de-coupled by a suitable timing-offset value to each TRX. This is done with the appropriate database parameters. The synchronicity within a site (i.e. within a BTSM) is guaranteed in any case, as all cells within a BTSM are controlled by a common master clock. In fact, all cells of the same BTSM have, by default, even the same frame numbers, as all cells of a BTSM start their operation at exactly the same point of time.

BTSM cellA

cellBcellC

BTSM cellA

cellBcellC

CellA

CellB

CellC

TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7 TS0 TS1



Frame n Frame n + 1

CellA

CellB

CellC

TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7 TS0 TS1TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7 TS0 TS1



Frame n Frame n + 1

The synchronicity of cells belonging to different sites, however, can only be achieved with the feature 'Inter-Site Synchronization' (ISS) which was introduced in BR8.0. The synchronicity of the cells is based on GPS (Global Positioning System) technology, i.e. GPS is used as time



reference. The purpose of ISS is to a) synchronize the cells of different sites and b) to introduce and control a fixed timing-offset (frame number offset and burst number offset) between cells of different sites. As explained below in section 'Impact of ISS on neighbour cells identification and SACCH performance', a common frame numbering within a synchronized area is not desirable as this leads to simultaneous transmission of SCH and SACCH slots and thus impacts the BSIC and SACCH decoding.

TS0 TS7

BTSA

TS0 TS7

BTSB

TS0 TS7

BTSC

frame X+4 frame X+5 frame X+6

frame X-1


frame X frame X+1TS0 TS7

BTSA

TS0 TS7

BTSB

TS0 TS7

BTSC


frame X-1


frame X frame X+1

The frame number offset can be administered by parameter FRANOFFS, the burst number offset is administered by parameter BURNOFFS (both parameters see command SET BTS [BASICS]).

In case of a 1/1 reuse pattern for the hopping TCH-TRXs, ISS thus allows the operator to allocate the available MAIOs (the number of which is determined by the number of frequencies used in the frequency hopping system (Mobile Allocation MA) to cells that are adjacent but do not belong to the same BTSM.

Example: 1/1 reuse configuration A) Without ISS: Only intra-site interference can be controlled by distributing MAIOs among the cells of the same site..

B) With ISS: Also inter-site interference can be controlled by distributing MAIOs among the cells of different sites. .

As interference is always a capacity-limiting factor (considering the fact that usually every operator tries to achieve the highest possible



traffic volume against a defined minimum QoS requirement), ISS can thus be used to extend the network capacity by reducing the inter-site interference.

Impact of ISS on Training Sequence Code (TSC) planning The training sequence code is transmitted in the center or each burst within a TDMA slot (please see also parameter TSC in command CREATE CHAN) and is used as an additional identification pattern in addition to the frequency itself. In synchronized networks, the TSCs may arrive at the MS receiver approximately at the same time.

TDMA slot n

Desiredburst

Interfererburst

TSCEncrypted Bits Encrypted Bits


t

TDMA slot n

Desiredburst

Interfererburst



t Some combinations of TSCs may degrade receiver performance when the TSC values are not orthogonal (only four TSC pairs are orthogonal (0; 2), (0; 7), (1; 3) and (3; 4)). Thus, to avoid degradation in channel estimation process a proper TSC planning has to be performed: cells operating on the same frequency should not use the same TSC, but should use pairs of TSCs that have a vanishing cross-correlation.

Impact of ISS on neighbour cells identification and SACCH performance Choosing a common frame numbering for cells that belong to synchronized cluster is not desirable, as this would mean a) simultaneous transmission of Synchronization Channel (SCH) slots in all cells (this impacts the BSIC decoding in a negative way and results in a lower performance of BSIC decoding and thus leading to a lower effectiveness of the handover algorithm).

b) simultaneous transmission of SACCH slots in the synchronized area which would increase the impact of interfering signals on the SACCH message decoding in a negative way. Moreover, due to the fact that SACCH messages are always transmitted regardless of the voice activity, the positive effect of DTX (see parameter DTXDL in command SET BTS [OPTIONS]) on the SACCH decoding would be undone.

Therefore, the frame numbering of the synchronized cells should be



time de-coupled in a controlled way using the FRANOFFS parameter (see SET BTS [BASICS]): FRANOFFS should thus not be set to '0' (means: no frame offset at all) or multiple values of 51 (length of a TDMA multiframe, similar effect like '0') to really achieve a de-synchronization of SCH and SACCH slots.

Impact of ISS on Interference cancellation features The features UIC (Uplink Interference Cancellation) and SAIC (Single Antenna Interference Cancellation) provide the best performance when the interfering signal does not change its characteristics throughout the duration of the 'desired' signal's burst in the serving cell. Thus, these features offer the best possible interference reduction when ISS is activated. Interaction of ISS and Dynamic MAIO Allocation (DMA) If feature DMA is enabled (see command CREATE CBTS for details about DMA), the ISS parameters must be set in such a way that all cells (BTSs) within the site (BTSM) have the same values for frame number offset (FRANOFFS) and burst number offset (BURNOFFS). Interaction of ISS and 'handover between finely synchronized cells' If the feature 'handover between finely synchronized cells' is enabled (see parameter HOSYNC in command SET BSC [BASICS]), handover between BTSs of the same BTSM can be performed without transmission of the PHYSICAL INFO message (which is used for timing advance alignment). In this case BTSs of the same BTSM must have been configured with the same burst number offset (BURNOFFS), the frame number offset may be different. Notes on configuration and enabling of the feature • For the configuration of the GPS synchronization source the object • SYNCBTSE (available only in the BTSE via BTSE-LMT) must be

used: the parameter SYNCSRC (SYNC source) must be set to 'extGPS'.

• Only if additionally EINTSITSYN is set to TRUE, the BTSE considers the FRANOFFS and BURNOFFS values as configured in the BSC database and as signaled to the BTSM during Abis alignment.

• When EINTSITSYN is set to FALSE in the BSC database while still the BTSE setting SYNCSRC=extGPS applies, - the BTSE ignores the FRANOFFS and BURNOFFS values - the BTSE is in 'Intra-site-synchronized' mode - the clocking source is still the external GPS This is, however, only the case if the BTSE has been restarted after the change from EINTSITSYN=TRUE to EINTSITSYN=FALSE, as only in this case all frame numbering and burst numbering is initialized and starts from scratch (with frame and burst number synchronicity within the site (BTSE)).

• When a BTSE has been configured for ISS with EINTSITSYN=TRUE, suitable FRANOFFS and BURNOFFS values and the suitable BTSE settings (SYNCSRC=extGPS), and the setting from EINTSITSYN=TRUE is changed to EINTSITSYN=FALSE only, actually the network behaviour does not change, because - the external GPS system remains the clock source and - the frame and burst number offset values do not change (!) as the BTSE remains in its currently running cycles. In other words, by just changing the setting from EINTSITSYN=TRUE to EINTSITSYN=FALSE, the network remains in ISS mode until a restart of the involved BTSEs occurs.

• ISS is only supported by BTSEs of generation BTSplus. - Multidrop- and Loop-configurations (see parameter L1CTS in command CREATE PCMB) with mixture of Abis-synchronized



BTSEs and GPS synchronized BTSEs is not allowed. EMT1=10, object: BTSM unit: 1min range: 0..360 default: 10

Emergency timer 1, this parameter indicates the delay for 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 signalling 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 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. This 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

4



in a cell are processed via the SDCCHs, it is recommended, to avoid an excessive concentration of the SDCCH signalling within one TRX (and thus one LPAD transmit queue), to distribute multiple 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=17, object: BTSM unit: 1s range: 3-300 default: 30 recommended value: 17

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. As long as this timer runs, the BTSE maintains the call processing activity (i.e. BCCH active) in the subordinate cells. When the timer expires the BTSE call processing is blocked and functional related Managed Objects (BTS, TRX, CHAN, HAND, PWRC, ADJC, ADJC3G etc.) are deleted. In this case no BCCH information is broadcast in the subordinate cells anymore and this results in a cell reselection of the mobile stations that previously camped in this cell. After recovery of the LAPD link a 'full alignment' is necessary to put the BTSE in service again, as this procedure recreates and re-establishes the functional object database in the BTSE which were deleted by the expiry of OMLAPDRT before. Summary: On detection of an Abis LAPD link failure the BTSE starts the timer OMLAPDRT and the BSC starts the timer SHLAPDIT. If the OMLAPDRT expires the BTSE blocks the call processing and deletes all functional objects. On link reestablishment the BTSE forces the BSC to perform a full Abis alignment if one of the two timers has expired. If the Abis link (LAPD connection) is recovered before one of the two timers expires, the BSC performs a 'Short Abis Alignment' (also called 'fast alignment') after recovery of the Abis link. When SHLAPDIT expires, all ongoing calls in then affected cells (including ASCI group calls VBS and VGCS) are released by the BSC. Application: The timers SHLAPDIT and OMLAPDRT are relevant for a) LAPD interruption due to PPXL 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 be greater than SHLAPDIT since a 'fast alignment' (SHLAPDIT not yet expired when the layer 2 comes up) only makes sense if call processing has not been blocked (and the functional objects have not been deleted in the BTSE) by the expiry of OMLAPDRT before! As, on the other hand, it does not make sense to keep a BTSE with a failed LAPD connection on air even after the expiry of SHLAPDIT in the BSC (which leads to a full alignment after link recovery anyway) and as it is generally not useful to keep a BTSE with afailed LAPD connection on air for a too long time (and thus to prevent any originating call setup), the recommendation is to use the following setting

SHLAPDIT=15, OMLAPDRT=17. Exception: In cells where ASCI features (VBS,VGCS) are enabled, it is recommended to set OMLAPDRT to a generally smaller value and, particularly, to a smaller value than SHLAPDIT to speed up the cell reselection in case of a LAPD link interruption. This is necessary in order to prevent the ASCI MSs from 'listening' to the Notification Channel NCH (and attempting to 'join' the ASCI common channel) in the cells where the ASCI common channel has already been released after expiry of SHLAPDIT. In this case, it is recommended to apply the following settings: SHLAPDIT=12, OMLAPDRT=10. - Please consider that normally, together with the LAPD link interruption, also the speech path (i.e. the used Abis TCH) is interrupted, so that all ongoing calls will be released by a CONNECTION FAILURE INDICATION with cause 'remote transcoder failure' after expiry of TSYNC or TSYNCDL (see command SET BTS [TIMER]). - 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 format: pcmbNumber1 - portNumber1 value format: pcmbNumber1: 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).




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


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


PCM connection 4, this attribute indicates the fourth auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected. 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).


PCM connection 5, this attribute indicates the fifth auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected. 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).


PCM connection 6, this attribute indicates the sixth auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected. 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).


PCM connection 7, this attribute indicates the seventh auxiliary PCM connection for the given BTSM, i.e. it indicates to which BTSM port it is connected. The port numbers must be selected in correspondence with the HW of the BTSE (please refer to the 'Notes' in the description of PCMCON0, see above).



SALUNAME='BSC1BTSE0', object: BTSM range: alphanumeric string (11 characters) in quotation marks default: NOT_DEFINED

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=15, object: BTSM unit: 1s range: 3-20 default: 15

Short LAPD interruption timer, this parameter represents a BSC timer which is started after the detection of a LAPD interruption 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 time defined by SHLAPDIT all calls in the affected BTSE are released and a 'full alignment' is performed after link recovery. When the LAPD link has recovered after expiry of SHLAPDIT, the BSC waits for another 30 seconds before it starts the 'full alignment'. 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.

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 Common BTS data of a BTSM for Dynamic MAIO Allocation (DMA): < With this command the CBTS object is created which defines the

data common for all BTSs of the BTSM which are necessary for the configuration of the synthesizer frequency hopping mode with the feature 'Dynamic MAIO Allocation' (DMA). The CBTS object defines the common pool of TRX/hopping frequencies shared by all BTSs that belong to the BTSM (for general information about frequency hopping please refer to the parameters HOPP and HOPMODE in command SET BTS [OPTIONS]).

Purpose and principle of the DMA feature Static MAIO Allocation Up to BR7.0 in the Siemens BSS only 'Static MAIO Allocation' (SMA) was supported for Frequency Hopping. SMA means that the hopping characteristics of a TCH resource that participates in a hopping pattern is fixed defined by - Mobile Allocation MA (list of frequencies included in the hopping pattern) - Hopping Sequence Number HSN (determines, together with the number of frequencies in the MA, the hopping algorithm or hopping sequence) - Mobile Allocation Index Offset MAIO (determines the position of that particular TCH within the hopping sequence). In case of SMA, the MA and HSN may be defined a) in the FHSY object (see command CREATE FHSY), in this case the MAIO can be defined (together with the relevant FHSYID) in the CHAN object that represents the TCH (see command CREATE CHAN) or in the TRX object (see command CREATE TRX). b) in the CFHSY object (see command CREATE CFHSY), in this case the MAIO can only be defined (together with the relevant FHSYID) in the TRX object (see command CREATE TRX). The definition of FHSYID and MAIO in the TRX object was introduced in BR8.0 as usually all TCHs of the same TRX are defined with the same FHSY and MAIO combination (which means that the hopping pattern is the same for all adjacent TCHs on a TRX). Dynamic MAIO Allocation DMA is a feature designed for network configurations with Synthesizer Frequency Hopping and a 1/1 frequency reuse on the non-BCCH TRXs. Remarks on 1/1 frequency reuse: Usually the frequency planning in a GSM network is done in such a way that co-channel interference and adjacent channel interference between adjacent or colocated sites is avoided by an intelligent allocation of TRX frequencies and frequency subsets among the cells to be covered. However, in some networks the frequency spectrum granted to the operators is so small that the number of available frequencies does not allow a suitable frequency distribution, especially if the network must handle considerable traffic capacities. In these networks, the resource planning can therefore not be based on the frequencies only and a different approach must be used. Usually, in such networks, frequency planning is reduced to the BCCH-TRXs only. For the non-BCCH-TRXs the operator may decide to deploy e.g. a 1/1 frequency reuse pattern, which means that the non-BCCH-TRXs TRXs use the same set of hopping frequencies. In such configurations the interference is minimized by minimization of possible collisions of the hopping channels by an intelligent MAIO management (please see also explanations given for the feature DMA Admission Control in command SET BTS [ADM]).



In such networks, SMA can be applied if an intelligent MAIO planning is ensured: although the same MA frequencies are used in the hopping pattern of the cells (sectors) of the same site, interference can be avoided by splitting the set of MAIOs allocated to the site into three subsets with different MAIOs for each cell (sector). Precondition: all cells of the site must be frame-number-synchronized, i.e. all cells have the same frame numbering (please see also parameter EINTSITSYN in command CREATE BTSM). This configuration, however, only works fine as long as the number of hopping TRXs in the BTSM (site) does not exceed the number of frequencies available in the Mobile Allocation (the MA is the list of hopping frequencies, which is in this case the same for all cells of the site). As the number of frequencies defined in the MA simultaneously determines the number of available MAIOs, MAIO re-use is an obligatory consequence if the number of hopping TRXs in the BTSM exceeds the number of frequencies in the common MA. MAIO reuse, however, in any case means a continuous intra-site co-channel interference. As the distribution of traffic among the cells of a BTSM is usually not exactly balanced and may vary temporarily, it is reasonable not to split the available pool of MAIOs into fixed subsets (as done in case of SMA) as this lacks the required flexibility. Instead, it is reasonable to apply DMA, which regards the complete pool of MAIOs defined by the commonly used Mobile Allocation as a common resource on site level and which uses an intelligent and sophisticated algorithm which assigns, during TCH allocation, those TCHs first whose combination of timeslot and MAIO has the smallest possible impact on the overall interference. DMA increases the network capacity if the number of TRXs per site (BTSM) exceeds the number of available hopping frequencies and if the traffic is inhomogeneously distributed among the sectors of the site.

The Dynamic MAIO Allocation (DMA) algorithm The DMA algorithm processes the following input data: • a list of free time slots of the serving cell • a list of MAIOs available for DMA • a table with the number of occurrences of dynamic MAIO values

within the site for each timeslot • table with allocation state of dynamic MAIO values within the

serving cell for each timeslot For each incoming voice call the DMA algorithm: • selects a channel on the basis of the current MAIO utilization

within the site • operates on the entire timeslot x MAIO domain • uses and reuses all MAIOs in all sectors of the site

TRX3MAIO = 16

TRX2MAIO = 10

TRX1MAIO = 4

TRX0BCCH

TRX3MAIO = 16

TRX2MAIO = 10

TRX1MAIO = 4

TRX0BCCH

TRX3MAIO = 14

TRX2MAIO = 8

TRX1MAIO = 2

TRX0BCCH

TRX3MAIO = 14

TRX2MAIO = 8

TRX1MAIO = 2

TRX0BCCH

TRX3MAIO = 12

TRX2MAIO = 6

TRX1MAIO = 0

TRX0BCCH

TRX3MAIO = 12

TRX2MAIO = 6

TRX1MAIO = 0

TRX0BCCHRandom Hopping (1, 2, 10, 7, . . . )

Time (TDMA frame)

MA

DMA algorithm channel selection principles: The DMA channel allocation algorithm • avoids MAIO repetition in the serving cell

(thus avoiding intra-cell co-channel interference) • minimizes the number of MAIO repetitions within the site

(thus minimizing the number of channels affected by intra-site co-channel interference)

• controls the number of MAIO adjacencies in the serving cell (thus minimizing the number of channels affected by intra-cell adjacent channel interference)

• controls the number of MAIO adjacencies within the site (thus minimizing the number of channels affected by intra-site adjacent channel interference)

DMA feature preconditions & requirements • DMA applies to speech calls only (AMR, non-AMR) • DMA only applies to Synthesizer Frequency Hopping only • Within the site the same hopping system is used.

This common frequency hopping system consists of - a Cell Allocation (list of used frequencies) common for all cells of the BTSM (site), which is defined by the parameter CCALLFxy (see command CREATE CBTS below) - a Mobile Allocation (list of used frequencies) and Hopping Sequence Number (HSN) common for all cells of the BTSM (see parameters CMOBALLOC and HSN in command CREATE CFHSY).

• all cells of the site must be air-interface-synchronized • service layers not exclusively dedicated to speech services (e.g.

service layers for data calls and (E)GPRS) can only use Static MAIO allocation (SMA).

In case of DMA, the Mobile Allocation and HSN can only be defined be defined in the CFHSY object (see command CREATE CFHSY) - the MAIO can only be defined (together with the relevant FHSYID) in the TRX object (see command CREATE TRX). The previously known administration of hopping parameters in the CHAN object is not possible for those TRXs where DMA is applied.

Interworking of DMA, SMA and Multi Layer Service Support (MSLS) All TRXs belonging to service layers that support other services than 'CS speech only' cannot use DMA - on these layers SMA has to be used (for further details about MSLS please see command CREATE CBTS). Basically there are two main possibilities to configure SMA and DMA in parallel within a BTS: a) Separate frequency sets used for DMA and SMA - The DMA layers use a Cell Allocation (list of cell frequencies) as defined by the CCALL parameter (see command CREATE CBTS) and a Mobile Allocation (i.e. list of hopping frequencies) as defined by parameter CMOBALLOC (see command CREATE CFHSY). Here the CFHSYID and MAIO data must be assigned in the TRX object. - The SMA layers use a Cell Allocation (list of cell frequencies) as defined by the CALLF<nn> parameter (see command CREATE BTS) and a Mobile Allocation (i.e. list of hopping frequencies) as defined by parameter MOBALLOC (see command CREATE FHSY). Here the FHSYID and MAIO data can be either assigned in the TRX object or in the CHAN objects subordinate to the SMA TRX.

b) Common set of frequencies used for DMA and SMA In this configuration the DMA layers and SMA layers use the same



Cell Allocation (list of cell frequencies) as defined by the CCALL parameter (see command CREATE CBTS) and a Mobile Allocation (i.e. list of hopping frequencies) as defined by parameter CMOBALLOC (see command CREATE CFHSY). Here the CFHSYID and MAIO data - of the DMA layer TRXs must be configured in the TRX object - of the SMA layer TRXs can be either configured in the TRX object or in the CHAN objects subordinate to the SMA TRX.

The MAIO values assigned to the DMA layer TRXs are only in effect when DMA is still disabled (ENDMA=FALSE in BTS and CBTS object). When DMA is enabled, the number of available MAIOs is automatically determined by the number of hopping frequencies in the Mobile Allocation. This pool of MAIOs is then used as a common resource on BTSM (=site) level and allocated in correspondence with the described above. Attention: When the SMA TRXs use the same CFHSY like the DMA TRXs, the BSC excludes the MAIO values of the SMA TRXs automatically from the pool of MAIOs that can be used and allocated for calls on the DMA layers. If for both the SMA and DMA TRXs the CFHSYID and MAIO data are assigned in the TRX object, there is no visible difference in the TRX creation data between the SMA from the DMA TRXs. The BSC can distinguish the SMA from the DMA TRXs by their service layer association: all TRX belonging to 'CS speech only' service layers are regarded as DMA TRXs, all others are considered for SMA.

DMA Admission Control To avoid the allocation of channels with unacceptable interference figures, the feature 'DMA Admission Control' is used. For this feature, please refer to the description provided for the command SET BTS [ADM].

As mentioned above, another feature to be considered in networks with 1/1 frequency reuse (together with SMA and DMA) is 'Inter-Site Synchronization' (ISS). For further information about this feature, please refer to parameter EINTSITSYN in command CREATE BTSM.>

CREATE CBTS: NAME=BTSM:0/CBTS:0, Object path name. CCALLF01=77, object: CBTS range: 0..1023 each field Reference: GSM 04.08 GSM 05.02 GSM 12.20

Common cell allocation frequency 1, this parameter defines the first non-BCCH radio frequency allocated to all cells of the BTSM for Dynamic MAIO Allocation. Further frequencies used in the cell are set with the remaining parameters CCALLF02..CCALLF63. Which frequency numbers are allowed, depends on the used frequency band: SYSID=BB900: 1..124 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



CCALLF02..CCALLF63 object: CBTS range: 0..1023 each field

Common cell allocation frequencies 2 to 63, these parameters define all the remaining non-BCCH radio frequencies allocated to all cells of the BTSM for Dynamic MAIO Allocation (see CCALLF01). For each frequency an own parameter is available - to save space, they were summarized here in one table line.

ENDMA=FALSE, object: CBTS range: TRUE, FALSE default: FALSE

Enable Dynamic MAIO Allocation, this parameter determines whether the feature 'Dynamic MAIO Allocation' is enabled in the CBTS object. Notes: - In the DBAEM, this parameter is listed within a SET CBTS command behind the CREATE CHAN commands. In other words, the enabling of DMA is not possible together with the creation because for the DMA enabling both the DBAEM and the BSC command interpreter check, prior to command execution, whether all associated objects (CFHSY, TRX, CHAN etc.) have been consistently and conclusively created in the database before. - To be in effect, DMA must be enabled both in the BTS and the CBTS object. In the DBAEM, DMA is enabled in the BTS object first (see parameter ENDMA in command CREATE BTS).

Creating the hopping laws used for Dynamic MAIO Allocation: < With this command the hopping systems used for cells in which

Dynamic MAIO Allocation is to be applied (CFHSY= Common Frequency Hopping System). For further details about DMA please refer to the command CREATE CBTS. Starting from BR8.0 the definition of frequency hopping systems can be done in two different ways: a) the frequency hopping system is defined per BTS (per cell) in the FHSY object (see command CREATE FHSY)which is subordinate to the affected BTS (as done in releases before BR8.0). b) the frequency hopping system is defined per BTSM (per site) in the CFHSY object which is subordinate to the CBTS object. Variant a) can be used for Static MAIO Allocation (SMA) only, which means that the BTS-specifically defined hopping system (FHSY) is allocated to the CHAN object together with a fixed MAIO value (see command CREATE CHAN for TCH and SDCCH) which determines the position of that particular channel in the applied hopping sequence. Starting from BR8.0, the allocation of a FHSY and MAIO can alternatively be done in the TRX object (see command CREATE TRX). Variant b) can be used for - Static MAIO Allocation (see above), which means that the BTSM-specifically defined hopping system (CFHSY) is allocated to the TRX object together with a fixed MAIO value (see command CREATE TRX) which determines the position of the channels subordinate to the TRX in the applied hopping sequence when Dynamic MAIO Allocation (DMA) is not used by the service layer assigned to that TRX. - Dynamic MAIO Allocation (see above), which means that the BTSM-specifically defined hopping system (CFHSY) is allocated to the TRX object together with a fixed MAIO value (see command CREATE TRX) which determines the position of the channels subordinate to the TRX in the hopping sequence when DMA is not enabled (see parameter ENDMA in commands CREATE CBTS and CREATE BTS [BASICS]). When DMA is enabled, the defined MAIO is no longer relevant as for the channels, MAIOs are dynamically assigned by a special algorithm. The below listed command CREATE FHSY is thus only relevant for variant (b), i.e. if DMA is to be used. >

CREATE CFHSY: NAME=BTSM:0/CBTS:0/CFHSY:0,

Object path name.

CMOBALLOC=CCALLF01& CCALLF02&..., object: CFHSY range: 0..1023 (each field) Reference: GSM 05.02 GSM 04.08

Common Mobile allocation list, this parameter defines is a list of those common cell allocation frequencies (defined in the CBTS object) which are used in the hopping sequence for the BTSM/CBTS.

HSN=10, object: CFHSY range: 0..63 Reference: 3GPP 45.008 GSM 04.08

Common Hopping sequence number, determines the hopping sequence number commonly used in the site that is configured for DMA.

SUBBAND=10, object: CFHSY range: GSM850, PCS1900, DCS1800, BB900, EB900 Reference: 3GPP 45.008 GSM 04.08

Subordinate band, this parameter determines the frequency band to which the CFHSY is applicable.

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 timeslot-no. 1-31 (PCM30) timeslot-no. 1-24 (PCM24) subslot-no. 0..3

Abis channel: pcmb-no. - timeslot (- subslot). The Abis timeslot which is configured as LPDLM as always used - as LPDLM for O&M signalling between BSC and BTSM and - as LPDLR for the call processing signalling communication (via Radio Signalling (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 timeslot) 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 addressed to a particular TRX to the associated LPDLM timeslot. After a failure of all LPDLMs the BSC decides which of the configured LPDLMs is used for the Abis Alignment Procedure. Note: For each LPDLM created in the BSC, the corresponding counterpart has to be created in the BTSE using the command CREATE LAPDLE.

LAPDPOOL=0; object: LPDLM range: 0..1 default: (LAPD pool is assigned by the BSC automatically)

LAPD pool, this parameter used to define the LAPDPOOL the LPDLM should be assigned to. A 'LAPD Pool' was a logical instance which represented a group of LAPD channels (LPDLM, LPDLR, LPDLS) that could be managed by one PPLD. As, starting from BR8.0, the PPLD is no longer supported, the parameter is only relevant for PPXL Meaning of LAPDPOOL for 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).

Creating the terrestrial Abis timeslots 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



subslot 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 specific 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 signalling) 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 particular TRX/radio TCH can be performed via any of the remaining 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 availability 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 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/SUBTSLB: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 introduction (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. Adaptive 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 RATE_05: 7.40 kbit/s (RATE_04 and RATE_05 only for BTSplus) 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) initiate 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 Adaptation'. 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 addressing 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 purpose 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 specific 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, or TRAU frame, respectively. 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 BTS [BASICS]) or 'Abis Load Dependent Activation of Half Rate' (see parameter ABISHRACTTHR). When the decision for AMR FR or AMR HR was made, the parameters AMRFRIC resp. AMRHRIC determine the initial AMR CODEC, i.e. the AMR CODEC that shall be used in the beginning of the call (this information is also included in the ASSIGNMENT COMMAND and CHANNEL ACTIVATION messages). Of course, the initial CODEC is then immediately adapted by the MS and BTS depending on the current radio conditions in the scope of the AMR link adaptation. Interaction of AMR link adaptation and frequency hopping The parameters for the ACS AMRFRC1..AMRFRC4 and AMRHRC1..AMRHRC4, the initial CODECs AMRFRIC and AMRHRIC as well as the link adaptation thresholds for the downlink AMRFRTH12..AMRFRTH34 and AMRHRTH12..AMRHRTH34 are valid for all calls with 'frequency hopping inactive'. Separate parameters and thresholds are used for calls with 'frequency hopping active'. These parameters have exactly the same acronyms like the parameters listed above, but their acronym is extended by the prefix



'FH'. This means that, for example, the 'frequency hopping active' equivalent to parameter AMRFRC1 has the acronym FHAMRFRC1. The BTS uses these 'FH'-AMR parameters for the downlink CODEC mode adaptation if frequency hopping is active for the call (for the uplink CODEC mode adaptation there is no difference between hopping active or deactivated). In this context it is not only relevant, whether frequency hopping is configured or not, as 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 a particular 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). Moreover, please consider that for AMR calls special handover and power control thresholds may apply, if they have been correspondingly set in the handover and power control service group settings (see parameters SGxxHOPAR in command SET HAND[BASICS] and SGxxPCPAR in command SET PWRC). AMR Compression Handover / AMR Decompression Handover As mentioned before, the decision whether an AMR call is set up as AMR FR or AMR HR call is either based on the speech version preference indicated in the ASSIGNMENT REQUEST or on the BSC decision (Cell load dependent activation of HR). Special intracell handovers are implemented for AMR calls, that allow a switchover from an AMR HR TCH to an AMR FR TCH and vice versa based on quality and load criteria. 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, object: BTS [BASICS] range: RATE_01, RATE_02, 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. 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 If AMRFRC2 is set to <NULL>, the ACS for AMR FR consists of only one CODEC (defined by AMRFRC1). In any case, the following rule must be followed: RATEAMRFRC4 > RATEAMRFRC3 > RATEAMRFRC2 > RATEAMRFRC1 Note: An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping. For further details please refer to the descriptions provided for the parameter AMRFRC1.

AMRFRC3= RATE_06, object: BTS [BASICS] range: RATE_01, RATE_02, 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. 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 If AMRFRC3 is set to <NULL>, the ACS for AMR FR only consists of maximally two AMR CODECs (defined by AMRFRC1and AMRFC2). In any case, the following rule must be followed: RATEAMRFRC4 > RATEAMRFRC3 > RATEAMRFRC2 > RATEAMRFRC1

Note: An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping. For further details please refer to the descriptions provided for the parameter AMRFRC1.

AMRFRC4= RATE_08, object: BTS [BASICS] range: RATE_01, RATE_02, 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. 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 If AMRFRC4 is set to <NULL>, the ACS for AMR FR only consists of maximally three AMR CODECs (defined by AMRFRC1..AMRFC3). In any case, the following rule must be followed: RATEAMRFRC4 > RATEAMRFRC3 > RATEAMRFRC2 > RATEAMRFRC1

Note: An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping.. For further details please refer to the descriptions provided for the parameter AMRFRC1.

AMRFRIC= START_MODE_FR, object: BTS [BASICS] 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. Note: An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping.

AMRFRTH12=7-4, object: BTS [BASICS] format: threshold-hysteresis unit: threshold: 0.5dB hysteresis: 0.5dB range: threshold: 0..63 [0..31.5dB] hysteresis: 0..15 [0..7.5dB] default: threshold: 7 [3.5 dB] hysteresis: 4 [2.0 dB]

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 is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping. - Please be aware that this parameter only refers to the AMR downlink CODEC mode adaptation. The corresponding uplink thresholds are not administrable (see parameter AMRLKAT).

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: a) The upward transition from AMRFRC2 to AMRFRC3 is initiated when C/I > thresholdAMRFRTH23 + hysteresisAMRFRTH23 b) The downward transition from AMRFRC3 to AMRFRC2 is initiated when C/I < thresholdAMRFRTH23






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: a) The upward transition from AMRFRC3 to AMRFRC4 is initiated when C/I > thresholdAMRFRTH34 + hysteresisAMRFRTH34 b) The downward transition from AMRFRC2 to AMRFRC1 is initiated when C/I < thresholdAMRFRTH34

AMRHRC1= RATE_01, object: BTS [BASICS] range: RATE_01, RATE_02, 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. In any case, the following rule must be followed: RATEAMRHRC4 > RATEAMRHRC3 > RATEAMRHRC2 > RATEAMRHRC1 Note: An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping. For further general details please refer to the descriptions provided for the parameter AMRFRC1.

AMRHRC2= RATE_02, object: BTS [BASICS] range: RATE_01, RATE_02, RATE_03, RATE_04 RATE_05, <NULL> default: RATE_02

AMR Half Rate Codec 2, this parameter defines the second AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Half Rate in the BTS. RATE_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 AMRHRC2 is set to <NULL>, the ACS for AMR HR only consists of only one CODEC (defined by AMRHRC1). In any case, the following rule must be followed: RATEAMRHRC4 > RATEAMRHRC3 > RATEAMRHRC2 > RATEAMRHRC1 Note: An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping. For further general details please refer to the descriptions provided for the parameter AMRFRC1.

AMRHRC3= RATE_03, object: BTS [BASICS] range: RATE_01, RATE_02, RATE_03, RATE_04 RATE_05, <NULL>default: RATE_03

AMR Half Rate Codec 3, this parameter defines the third AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Half Rate in 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 AMRHRC3 is set to <NULL>, the ACS for AMR HR only consists of maximally two AMR CODECs (defined by AMRHRC1..AMRHRC2). In any case, the following rule must be followed: RATEAMRHRC4 > RATEAMRHRC3 > RATEAMRHRC2 > RATEAMRHRC1 Note: An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping. For further general details please refer to the descriptions provided for the parameter AMRFRC1.

AMRHRC4= RATE_04, object: BTS [BASICS] range: RATE_01, RATE_02, RATE_03, RATE_04 RATE_05, <NULL>default: RATE_04

AMR Half Rate Codec 4, this parameter defines the fourth AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Half Rate in the BTS. RATE_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 AMRHRC4 is set to <NULL>, the ACS for AMR HR only consists of maximally three AMR CODECs (defined by AMRHRC1..AMRHRC3). In any case, the following rule must be followed: RATEAMRHRC4 > RATEAMRHRC3 > RATEAMRHRC2 > RATEAMRHRC1 Note: An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping. For further general details please refer to the descriptions provided for the parameter AMRFRC1.

AMRHRIC= START_MODE_HR, object: BTS [BASICS] range: START_MODE_HR CODEC_MODE_01 CODEC_MODE_02 CODEC_MODE_03 CODEC_MODE_04 default: START_MODE_HR

AMR Half Rate Initial Codec, this parameter defines which AMR HR CODEC of the created AMR HR ACS shall be used first after HR TCH assignment. The values CODEC_MODE_0x represent the created AMR HR CODECs (AMRHRCx) of the ACS. Example: If AMRHRIC=CODEC_MODE_01, then the CODEC defined in AMRHRC1 will be used as initial AMR HR CODEC after AMR HR TCH assignment. If the value START_MODE_HR is entered, the initial CODEC 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 is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping.

AMRHRTH12=19-4, object: BTS [BASICS] format: threshold-hysteresis unit: threshold: 0.5dB hysteresis: 0.5dB range: threshold: 0..63 [0..31.5dB] hysteresis: 0..15 [0..7.5dB] default: threshold: 19 [9.5 dB] hysteresis: 4 [2.0 dB]

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

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 thresholdAMRHRTH12 + hysteresisAMRHRTH12

≤ thresholdAMRHRTH23 + hysteresisAMRHRTH23


Notes: - An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of

active frequency hopping. - Please be aware that this parameter only refers to the AMR downlink CODEC mode adaptation. The corresponding uplink thresholds are not administrable (see parameter AMRLKAT).

AMRHRTH23=24-4, object: BTS [BASICS] format: threshold-hysteresis unit: threshold: 0.5dB hysteresis: 0.5dB range: threshold: 0..63 [0..31.5dB] hysteresis: 0..15 [0..7.5dB] default: threshold: 24 [12.0 dB] hysteresis: 4 [2.0 dB]



> thresholdAMRHRTH23 + hysteresisAMRHRTH23



AMRHRTH34=30-4, object: BTS [BASICS] format: threshold-hysteresis unit: threshold: 0.5dB hysteresis: 0.5dB range: threshold: 0..63 [0..31.5dB] hysteresis: 0..15 [0..7.5dB] default: threshold: 30 [15.0 dB] (BTS+) <NULL> (BTS1) hysteresis: 4 [2.0 dB]




≤ thresholdAMRHRTH34 + hysteresisAMRHRTH34Notes: - An equivalent parameter is available (see below, parameter with the same name but the prefix 'FH') which eclipses this one in case of active frequency hopping. - Please be aware that this parameter only refers to the AMR downlink CODEC mode adaptation. The corresponding uplink thresholds are not administrable (see parameter AMRLKAT).

AMRLKAT=100, object: BTS [BASICS] 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. AMRLKAT simply shifts all reference thresholds by the same amount.

AMRLKAT internal tune value tune [dB] range 0 ... +200 -100 ... +100 -10 ... +10 [dB]

default 100 0 0 [dB]

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. Notes: - Negative values in general have to be chosen with care as they increasingly tend to keep less robust modes even at high FER. - Positive values do not always shift higher thresholds as expected because there is an upper soft limit to realizable thresholds. For further details please refer to the section 'AMR Link Adaptation Thresholds Uplink' in the Appendix of this document.

ANTHOPMOD = <NULL>, object: BTS [BASICS] 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> object: BTS [BASICS] 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, object: BTS [BASICS] range: 0..1023 Reference: GSM 04.08 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, object: BTS [BASICS] range: NCC: 0..7 BCC: 0..7 Reference: GSM 03.03 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.

BURNOFFS=<NULL>, object: BTS [BASICS] range: 0..7, <NULL> Reference: <NULL>

Burst number offset, this parameter is relevant if the feature 'inter Site Synchronization' (ISS) is used and indicates, as an integer value, the burst number offset of the BTS. For further details about ISS and the meaning of this parameter please refer to parameter EINTSITSYN (see command CREATE BTSM).

CALLF01=60, object: BTS [BASICS] range: 0..1023 each field Reference: GSM 04.08 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=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 object: BTS [BASICS]

Cell allocation frequencies 2 to 63, these parameters define all the remaining non-BCCH radio frequencies used in the cell (see CALLF01). For each frequency an own parameter is available - to save space, they were summarized here in one table line. Note: Please consider also the explanations provided for parameter CCALL (see below), which is relevant in case of frequency definitions on BTSM level via the CBTS object.

CBQ=0, object: BTS [BASICS] range: 0= normal priority 1=low priority default: 0 Reference: 3GPP 45.008 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 (loss of coverage). Only in this case the MS considers the cell priority defined by CBQ for the selection of the cell.

CCALL=<NULL>, object: BTS [BASICS] range: CCALLF<nn>, linked with '&' <NULL> default: <Null>

Common Cell Allocation, these parameters defines the list of frequencies that are to be used in the BTS and which are inherited from the CBTS object (see command CREATE CBTS). The CBTS object must be created if the feature 'Dynamic MAIO Allocation' (DMA) is to be used, but may also be defined if the frequencies used for the (synthesizer) hopping TRXs are to be defined on a BTSM level (instead of on BTS level) and later on 'passed on' to the BTS objects subordinate to the BTSM. Within the CBTS object, the parameters CCALLF<nn> define the list of (hopping) frequencies. The CCALL parameter defines which of these frequencies (either the complete set or only a subset) are to be used in the BTSs subordinate to the BTSM. In addition to the frequencies defined by the CCALL parameter, further frequencies may be defined using CALLF<nn> parameters (see above). The frequency used for the BCCH TRX of the BTS/cell must be defined by parameter BCCHFREQ (see above) in any case. An overlapping of the frequencies defined by CCALL, CALLF<nn> and BCCHFREQ is not allowed. Different combinations of frequency definitions and frequency hopping pattern definitions are possible, depending on whether DMA is to be used and how this is to be combined with frequency hopping patterns based on Static MAIO Allocation (SMA): a) Separate frequency sets used for DMA and SMA - The DMA layers use a Cell Allocation (list of cell frequencies) as defined by the CCALL parameter (see command CREATE CBTS) and a Mobile Allocation (i.e. list of hopping frequencies) as defined by parameter CMOBALLOC (see command CREATE CFHSY). Here the CFHSYID and MAIO data must be assigned in the TRX object. - The SMA layers use a Cell Allocation (list of cell frequencies) as defined by the CALLF<nn> parameter (see command CREATE BTS) and a Mobile Allocation (i.e. list of hopping frequencies) as defined by parameter MOBALLOC (see command CREATE FHSY). Here the FHSYID and MAIO data can be either assigned in the TRX object or in the CHAN objects subordinate to the SMA TRX.

b) Common set of frequencies used for DMA and SMA In this configuration the DMA layers and SMA layers use the same Cell Allocation (list of cell frequencies) as defined by the CCALL

parameter (see command CREATE CBTS) and a Mobile Allocation (i.e. list of hopping frequencies) as defined by parameter CMOBALLOC (see command CREATE CFHSY). Here the CFHSYID and MAIO data - of the DMA layer TRXs must be configured in the TRX object - of the SMA layer TRXs can be either configured in the TRX object or in the CHAN objects subordinate to the SMA TRX.

For further details, please refer to the introduction description of command CREATE CBTS.

CELLGLID='262'-'02'-10-101, object: BTS [BASICS] range: MCC: '0..999' MNC: '0..999' (PCS1900) MNC: '0..99' (all others) LAC: 0..65535 CI: 0..65535 Reference: GSM 03.03 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, object: BTS [BASICS] unit: 2dB range: 0..7 default: 2 Reference: 3GPP 45.008 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, object: BTS [BASICS] range: STDCELL EXTCELL DBSTDCELL 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 characteristics 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 timeslots 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. Instead, the 'area' is defined by the pool of 'single' or 'double' timeslots - independent of the timeslots' association to a TRX. Example configuration:

ts 0 ts 1 ts 2 ts 3 ts 4 ts 5 ts 6 ts 7 TRX:0 BCCH ext SDCCH ext TCH TCH TCH ext TRX:1 TCH ext TCH ext TCH TCH TCH TCH

= near area = far area Signalling of extended TA values As in an extended cell the normal coding range of the timing advance (TA, range 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 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 changes 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 further details please refer to the mentioned parameter descriptions. Note: The features 'Extended Cell' and 'Concentric Cell' (see CONCELL) exclude each other. c) The value DBSTDCELL means 'Dual band standard cell' and represents a new type of cell having frequencies in two different frequency bands and a BCCH in one of these bands. The dual band standard cell is also called 'Common BCCH cell' (Attention: As opposed to BR7.0, the 'Common BCCH' cells in BR8.0 are no longer based on the feature 'concentric cells' (parameter CONCELL, see above), but only on the setting CELLTYPE=DBSTDCELL. In other words, the parameter CONCELL must be set to FALSE in this configuration). Cell characteristics The frequency bands to be supported are GSM850/PCS1900, GSM900/DCS1800 and GSM850/DCS1800. The Dual Band Standard Cell must be planned in such a way that the frequency bands have exactly the same coverage. This implies that at any location within a Dual Band Standard Cell, a service can be allocated on either of the frequency bands. The dualband standard cell has a cell identity as any single band GSM cell. Both circuit switched, e.g. speech, and packet switched data e.g. GPRS/EGPRS, services can be allocated in both frequency bands. If PBCCH is configured, it must be on the BCCH frequency band. TCH allocation principles The radio resource allocation in a Dual band Standard Cell is performed in accordance with the feature 'Service Dependent Channel Allocation' but having a only one single Service Layer List (SLL), which is the Service Layer Primary Area (SLPA) like a Standard cell, with layers having TRXs of BCCH frequency band and TRXs of non-BCCH frequency band. In other words, the SLL is common to both the frequency bands. The service layer selected for search of the TCH resources is determined by the service type requested by the mobile. For every layer, the favoured TCHs are the ones with the lowest interference class (see parameter INTCLASS in command SET BTS [INTERF] and compatible with the mobile's service capabilities. A mobile requesting a TCH within a dual band standard cell is granted TCH resources according to the SLL and its capabilities, i.e. dual band MSs are allocated on either of the frequency bands, whereas single band MSs shall be allocated only on BCCH frequencies. If the operator wants to preserve resources for single band mobiles, he must create service layers with unique band (layers with BCCH band separated by layers with non-BCCH band) and must define the layers of the non-BCCH band as last in the SLL. If the value of parameter SYSID is GSMDCS and the operator wants



to preserve the resource for phase1-mobiles, he must distribute the TRXs with frequencies in GSM baseband and the TRXs in GSM extended band over different service layers. Then he must define in the service layer list first the layers for GSM extended band, and after that the layers for the GSM base band. If a GPRS mobile accesses the cell, the mobile frequency bands of operation and relative power capabilities are sent to the network in the PACKET RESOURCE REQUEST message during the two phase access and within Additional MS Radio Access Capabilities message during one phase access. Hence the GPRS mobile is allocated resources within Dual Band Standard Cell depending on the operator policy and according to the settings of the feature 'Service Dependent Channel Allocation'. Packet data service on the non-BCCH frequency band is allowed by associating EGPRS/GPRS service with a service layer comprising TRXs of the non-BCCH frequency band and setting GEXTS parameter (see below) to the right value. Evaluation of MS capabilities A multiband network uses 2-ter and 5-ter System Info messages which enable multiband mobiles to access the network and, at the same time, to maintain compatibility with single band mobiles. The BSS is informed about the frequency capabilities and associated power capabilities of the multiband MS on each frequency band by the Early Classmark Sending procedure (see parameter EARCLM in command SET BTS [OPTIONS]. Interworking with feature 'Multiple Service Layer Support If the operator wants to prioritize a particular frequency band for any given service, this can be achieved by: - Definition of dedicated layers, with BCCH band frequencies only or, conversely, non-BCCH band frequencies only - Definition of mixed layers (composed of BCCH and non-BCCH frequencies) through a proper order of layers within the list associated to that service. If a layer contains TRXs of both frequency bands of the Dual Band Standard cell, resources are ordered in this layer on the basis of the interference band they belong to and kept with regards both with this criteria and MS capability. If e.g. a particular service supported both in the 900 MHz and in the 1800 MHz band. In this case, the (for both bands) unique SLL may have, in the first positions, the 900 MHz layers (if e.g. the operator wants to prioritize the 900 MHz band) ordered according to a radio quality criterion and in the remaining positions the 1800 MHz layers still ordered according to the same criterion. If a layer contains TRXs from both frequency bands of the Dual band standard cell, resources are ordered on the basis of the interference band they belong to. Interworking with frequency Hopping According to the GSM/3GPP standard, Frequency Hopping is not allowed across frequency bands. The only exception is between P900 and E900 bands specifying the first ones with the notation (301..424). Therefore frequencies on which to perform Dynamic MAIO Allocation (DMA) must belong to the same frequency band and two frequency bands must be defined for DMA.



CONCELL=FALSE, object: BTS [BASICS] 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 output 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 is a fixed relation of concentric cell areas and particular TRXs. Example configuration:

ts 0 ts 1 ts 2 ts 3 ts 4 ts 5 ts 6 ts 7 TRX:0 BCCH SDCCH TCH TCH TCH TCH TCH TCH TRX:1 TCH TCH TCH TCH TCH TCH TCH TCH TRX:2 TCH TCH TCH TCH TCH TCH TCH TCH

= complete area = inner area Within a concentric cell, specific intra-cell handovers from the inner 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 possible in cells with mixed frequency bands - in this case, in addition to CONCELL=TRUE, the parameter CELLTYP must be set to the value STDCELL (see above), the parameter SYSID (see below) must be set to GSMDCS resp. GSM850PCS and the parameters for maximum allowed transmission power must be set for both bands (parameters MSTXPMAXGSM and MSTXPMAXDCS, see below). In this case, frequencies of different frequency bands are assigned to the inner and complete area of a concentric cell. Considering the frequency propagation characteristics and the band-specific maximum cell radius, the most useful configuration is to use GSM900 resp. GSM850 frequencies for the complete area (and thus for the BCCH and also the SDCCHs) and to assign DCS1800 resp. PCS1900 frequencies to the inner area. However, also the opposite configuration is also technically possible. Attention: Please be aware that the above configuration is to be regarded as a 'dual band concentric cell', with all known features of a concentric cell but with different frequency bands in each area. This configuration is different from the so-called 'dual band standard cell' configuration (CELLTYP=DBSTDCELL, see above), which was

INNER area COMPLETE area

introduced in BR8.0 and which is a standard cell with TRXs belonging to different frequency bands but with equal coverage and without any inner /complete area separation. 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, object: BTS [BASICS] unit: 2dB range: 0..63 default: 1 Reference: 3GPP 45.008 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, object: BTS [BASICS] range: 0=C2 parameters not present 1=C2 parameters present default: 1 Reference: 3GPP 45.008 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, PENTIME, CBQ have to be skipped.

C2

expiry of timer start of timer

C1

PENTIME

CRESOFF TEMPOFF

C1 + CRESOFF - TEMPOFF

C1 + CRESOFF

t



CSCE=URBAN, object: BTS [BASICS] range: URBAN, SUB_URBAN RURAL_QUASI_OPEN, RURAL_OPEN default: URBAN

Coverage of serving cell, this parameter defines the propagation of a cell covered by the BTS.

CUCONF=HOMOGENEOUS, object: BTS [BASICS] range: CU_FLEXCU_BS82II, CU_ECU_DCSPCS, HOMOGENEOUS default: HOMOGENEOUS

CU configuration, this parameter indicates which types of CU are used within the BTSE serving the cell. This information must be considered for power aspects, as different CU types differ in their transmission power levels.

DGRSTRGY= GPRS_FIRST_DOWNGRADE, object: BTS [BASICS] range: HSCSD_FIRST_DOWNGRADE GPRS_FIRST_DOWNGRADE DOWNGRADE_HSCSD_ONLY DOWNGRADE_GPRS_ONLY NO_DOWNGRADE default: GPRS_FIRST_DOWNGRADE Parameters moved from BSC object to BTS object in BR8.0! Default value changed in BR8.0!

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. Impacts on TCH Allocation 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) (WPS) queuing 4) downgrade of multislot calls (GPRS/HSCSD) may be periodically attempted in parallel and queued calls can be served when down

grade is successfully completed. Please refer to the parameters EPRE (for preemption) and EQ (for (WPS) queuing) in command SET BTS [OPTIONS] and to parameter ENFORCHO (for directed retry) in command SET BTS [BASICS]. Interworking of the features 'Downgrade strategy' and (WPS) queuing When a TCH request is queued, the BSC tries, when possible, to serve the queued TCH requests by a multislot call downgrade procedure (e.g. (E)GPRS downgrade: Every call is put in the queue with its relevant data (channel request type, WPS/Public call info, Service List, running procedure, …). After the call is queued, the resource management process periodically starts the downgrade procedure (if correspondingly enabled via parameter DGRSTRGY) on HSCSD data calls and/or (E)GPRS data calls (if any) in order to get new resources for TCH allocation. The call that triggers the downgrade procedure is marked as 'downgrade requested' in order to wait for the resources that will be available after successful completion of the downgrade procedure. If during the ongoing downgrade procedure other TCHs become 'idle' again, these resources cannot be assigned to the call marked as 'downgrade requested'. The call marked as 'downgrade requested' must in any case wait for the resources achieved by the downgrade procedure. The downgrade procedure is requested for the multislot calls established on the shared layers with service layer association matching to the service type of the enqueued call, starting from the preferred layer. On the other hand, in case of Abis congestion the multislot downgrade procedure will be requested on all layers of this cell associated to the multislot service layer list and in the extreme case also on other cells of the same BTSM. Notes: - 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 supports GPRS (this is the case if the TRX is defined as belonging to a service layer which is included in the SLL for GPRS services - please see command SET BTS [SERVICE] for further explanations). - 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. - Please see also parameter DGRSTRGYBCNT (command SET BSC [BASICS]).

EANTHOP = FALSE, object: BTS [BASICS] 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, object: BTS [BASICS] 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.

EFCRESEL=FALSE, object: BTS [BASICS] range: TRUE, FALSE default: FALSE

Enable Fast Cell reselection, when this attribute is set to TRUE, the BSC inserts the BCCH frequency on the BA list sent on System Info 2. The relevant BSIC inside to SYSTEM INFORMATION TYPE 2 quater will broadcast it for the specific cell.

EHDCTR=FALSE, object: BTS [BASICS] range: TRUE, FALSE default: FALSE

Enable history on dropped call tracing, this parameter determines whether the feature 'history on dropped calls' (History on Dropped Call Tracing HDCTR) is enabled in the cell. This parameter is only relevant if the HDCTR feature is generally enabled for the BSC (see command CREATE HDTCR). Further relevant parameters for the HDCTR file handling are HDCFS and HDCFUPE (see command SET BSC [CONTROL].



EHRACT=TRUE, object: BTS [BASICS] range: TRUE, FALSE default: TRUE Default value changed in BR8.0!

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 below). 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 traffic load in the TRXs/service layers that are included in the SLLs of the requested (non-AMR speech) service 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 traffic load in the TRXs/service layers that are included in the SLLs of the requested (non-AMR speech) service 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 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 traffic load remains below the threshold defined by the parameters HRACTT1 and HRACTT2, the BSC forces the incoming

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

no. of configured radio TCH



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 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 radio TCH load in the TRXs/service layers that are included in the SLLs of the requested (non-AMR speech) service 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 radio TCH load in the TRXs/service layers that are included in the SLLs of the requested (non-AMR speech) service is below the threshold HRACTT1/HRACTT2 and the BTSM Abis pool TCH is below the threshold ABISHRACTTHR.

Notes: - The database flags EHRACTAMR and EHRACT are independent of each other, i.e. for operation of the feature 'Cell load dependent activation of half rate' for AMR calls only the flag EHRACTAMR is relevant, the setting of the flag EHRACT does not have any influence. - Cell Load Dependent Activation of HR does not work when Direct TCH Assignment (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.

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

no. of Abis TCHs configured in Abis pool ∗ 100



- 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 activation of half rate' and 'Abis load dependent activation of half rate' (see parameter ABISHRACTTHR in command CREATE BTSM) are not considered if the BSC receives an INTRACELL HANDOVER CONDITION INDICATION due to quality reasons (cause values 'uplink quality' or 'downlink quality'). This means that the BSC does not check the current BTS TCH load and the BTSM Abis pool TCH load in case of an intracell handover due to quality. Instead, the BSC just maintains the same channel type / speech codec as used before on the old channel.

EHRACTAMR=FALSE, object: BTS [BASICS] range: TRUE, FALSE default: TRUE Default value changed in BR8.0! Parameters moved from BSC object to BTS object in BR8.0!

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 and EHRACT are independent of each other, i.e. for operation of the feature 'Cell load dependent activation of half rate' for AMR calls only the flag EHRACTAMR is relevant, the setting of the flag EHRACT does not have any influence.

ENPERNOTDE= FALSE, object: BTS [BASICS] range: TRUE, FALSE default: FALSE

Enable periodic notification on dedicated channel, this parameter enables/disables the periodical notification repetition on dedicated channels.

EPAT1=4000, object: BTS [BASICS] unit: 0,01 % range: 0..10000 default: 4000 Default value changed in BR8.0!

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 TRXs/service layers that are included in the SLLs of AMR and non-AMR speech service (in case of standard cell) - in the TRXs/service layers that are included in the SLLs of the requested service belonging to the complete area of a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) - in TRXs/service layers that are included in the SLLs of AMR and non-AMR speech service belonging to 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 BTS [BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). - If the timer TEMPCH (see command CREATE PCU) is running for a particular TCH/PDCH, this TCH is regarded as 'idle' in any case, no matter which values is 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 GMANPRESPRM 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 GMANPRESPRM, the currently used but 'not reserved' TCHs ('idle/shared' TCHs) are considered in correspondence with the setting of DGRSTRGY as indicated above.

Note: Interworking of 'Service Dependent Channel Allocation' with 'Multiple Service Layer Support' (MSLS) and traffic load calculation: The percentage calculation done for the Enhanced Pairing is done referring only to the TRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea (primary/complementary). Please refer to the command SET BTS [SERVICE] for further explanations. 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, object: BTS [BASICS] unit: 0,01 % range: 0..10000 default: 4000 Default value changed in BR8.0!

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 TRXs/service layers that are included in the SLLs of the AMR and non-AMR speech service belonging to the inner area of a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) - in the TRXs/service layers that are included in the SLLs of the AMR and non-AMR speech service belonging to the near area of an extended cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS]). The value 100 represents 1%. For further details please refer to parameter EPAT1 (see above).

ETXDIVTS=FALSE, object: BTS [BASICS] range: TRUE, FALSE default: FALSE

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

FACCHQ=5, object: BTS [BASICS] 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 signalling 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, object: BTS [BASICS] range: 0..3 default: 0 reference: 3GPP 44.018 3GPP 45.008

FDD multiRAT reporting, this parameter corresponds to the 3GPP parameter FDD_MULTIRAT_REPORTING which is - broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater (in idle mode) and - sent to the MS/UE within the MEASUREMENT INFORMATION messages (in connected mode). It indicates the number FDD UTRAN cells the UE shall include in the MEASUREMENT REPORTs. The UE is thus instructed to report, if available, this number of 3G neighbour cells. Which value should be set for this parameter strongly depends on the environment of the cell (BTS). The default value of '0' only makes sense in areas without any 3G neighbours (no ADJC3G object created for this BTS). The more really relevant 3G cells are available, the higher the value should be set. Usually 6 neighbour cells can be reported within one MEASUREMENT REPORT message. The value must therefore be set considering how many 2G neighbour cells shall be reported in any case.



FDDQMI=MDB12, object: BTS [BASICS] range: MDB20 MDB18 MDB16 MDB14 MDB12 MDB10 MDB08 MDB06 default: MDB12 reference: 3GPP 44.018 3GPP 45.008

FDD Q minimum, this parameter corresponds to the 3GPP parameter FDD_Qmin which is broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2ter and SI2quater and is a threshold for signal Ec/No which is used for the algorithm for GSM to UTRAN cell reselection. The parameter values express a value in dB MDBxx = - xxdB (e.g. MDB20 = -20dB) Algorithm for (CS) cell re-selection from GSM to UTRAN If the 3G Cell Reselection list includes UTRAN frequencies, the MS updates the value RLA_C (receive level average of cell) for the serving cell and of the at least 6 strongest non-serving GSM cells at least every 5s. The MS then reselects a suitable FDD UTRAN cell if for this FDD cell the following criteria are all met for a period of 5s: 1. The cell's measured RSCP value exceeds the value of RLA_C for

the serving cell and all of the suitable non-serving GSM cells by the value FDD_Qoffset (parameter FDDQO, see below). Note: When a cell reselection has occurred within the previous 15 seconds, FDD_Qoffset is increased by 5 dB.

2. The cell's measured Ec/No value is equal or greater than the value FDD_Qmin - FDD_Qmin_Offset (parameter FDDQMIO, see below) and

3. The cell's measured RSCP value is equal to or greater than the threshold FDD_RSCPmin (parameter FDDRSCPMI, see below) when broadcast in the serving cell.

The parameters required to determine if the UTRAN cell is suitable are broadcast on BCCH of the UTRAN cell. An MS/UE may start reselection towards the UTRAN cell before decoding the BCCH of the UTRAN cell. The UE stores the UTRAN cell RSCP suitability criterion parameters above, whenever decoded from a UTRAN FDD cell of an equivalent PLMN. If more than one UTRAN cell fulfils the above criteria, the MS selects the cell with the greatest RSCP value. Cell reselection to UTRAN is prohibited within 5 seconds after the MS/UE has reselected a GSM cell from an UTRAN cell if a suitable GSM cell can be found. Note: For the meaning of the measurement values RSCP and Ec/No please refer to the description of parameter FDDREPQTY (see below).

FDDQMIO=DB00, object: BTS [BASICS] range: DB00 DB04 DB06 DB08 DB10 DB12 DB14 default: DB00 reference: 3GPP 44.018 3GPP 45.008

FDD Q minimum offset, this parameter corresponds to the 3GPP parameter FDD_Qmin_Offset which is broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2ter and SI2quater and is related to multiRAT mobiles; it is used by the MS/UE for the cell re-selection algorithm from GSM to UTRAN. FDDQMIO represents an offset which is applied to the parameter FDD_Qmin (parameter FDDQMI, see above). For details about the cell reselection algorithm from GSM to UTRAN please refer to the description of parameter FDDQMI (see above). The parameter values express a value in dB DBxx = xxdB (e.g. DB10 = 10dB)



FDDQO=DB00, object: BTS [BASICS] range: ALWAYS MDB28 MDB24 MDB20 MDB16 MDB12 MDB08 MDB04 DB00 DB04 DB08 DB12 DB16 DB20 DB24 DB28 default: DB00 reference: 3GPP 44.018 3GPP 45.008

FDD Q offset, this parameter corresponds to the 3GPP parameter FDD_Qoffset which is broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2ter and SI2quater and is related multiRAT mobiles; it is used by the UE for the cell re-selection algorithm from GSM to UTRAN. It defines a level offset by which the RLA_C value of an UTRAN FDD neighbour cell must exceed the RLA_C of the serving GSM cell before the UTRAN neighbour cell is considered for cell reselection from GSM to UTRAN. For details about the cell reselection algorithm from GSM to UTRAN please refer to the description of parameter FDDQMI (see above). The parameter values express a value in dB MDBxx = - xxdB (e.g. MDB20 = -20dB) DBxx = xxdB (e.g. DB20 = 20dB) The value ALWAYS indicates an infinite negative (-∞ dB) offset, so with this setting a 3G Mobile will always change to the 3G network if any acceptable 3G cell is available.

FDDREPO=DB00, object: BTS [BASICS] range: DB00 DB06 DB12 DB18 DB24 DB30 DB36 DB42 default: DB00 reference: 3GPP 44.018 3GPP 45.008

FDD reporting offset, this parameter corresponds to the 3GPP parameter FDD_REPORTING_OFFSET which is - broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater (in idle mode) and - sent to the MS/UE within the MEASUREMENT INFORMATION messages (in connected mode). FDDREPO is relevant for 'Enhanced Measurement Reporting' (parameter REPTYP, see below) and defines a fixed offset to be applied to all reported 3G neighbour cells. The offset is applied as follows: if there is not enough space in the report for all valid cells, those cells are reported that have the highest sum of the reported value and the parameter FDD_REPORTING_OFFSET. This offset parameter, however, does not affect the actual reported value. If a cell can not be reported due to lack of space in the report message (MEASUREMENT REPORT or ENHANCED MEASUREMENT REPORT), then no cell with a lower value shall be reported, even if one of these cells with a lower value would fit into the report. The parameter values express a value in dB DBxx = xxdB (e.g. DB10 = 10dB) Note: The 3GPP standard (e.g. 44.0018) defines various similar reporting offsets for different radio access technologies, and, within GERAN, different offsets for the different frequency bands. Therefore the standard often mentions the reporting threshold with a wildcard: XXX_REPORTING_OFFSET, where XXX represents values such as (FDD, TDD, 900, 1800, 1900, 850, 400 etc.)



FDDREPQTY=RSCP, object: BTS [BASICS] range: RSCP, ECNO default: RSCP reference: 3GPP 44.018 3GPP 45.008 3GPP 25.433 3GPP 25.215

FDD reporting quantity, this parameter corresponds to the 3GPP parameters a) FDD_REP_QUANT which is sent to the MS/UE

- in the SYSTEM INFORMATION TYPE 2quater messages via the BCCH (in idle mode) and - in the MEASUREMENT INFORMATION messages via the SACCH

b) REPORTING_QUANTITY which is indicated by the MS/UE in the ENHANCED MEASUREMENT REPORT messages sent via the SACCH.

It 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 from GSM 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 FDDREPQTY, but the processing of the measured values is different: - If FDDREPQTY is set to RSCP, the sufficient 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 sufficient coverage 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

FDDREPTH=RXLEV_00, object: BTS [BASICS] range: RXLEV_00, RXLEV_06, RXLEV_12, RXLEV_18, RXLEV_24, RXLEV_30, RXLEV_36, NEVER default: RXLEV_00 reference: 3GPP 45.008 3GPP 44.018

FDD reporting threshold, this parameter corresponds to the 3GPP parameter FDD_REPORTING_THRESHOLD which is - broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater (in idle mode) and - sent to the MS/UE within the MEASUREMENT INFORMATION messages (in connected mode). FDDREPTH defines a threshold which UTRAN cell has to exceed in order to be reported in the ENHANCED MEASUREMENT REPORT (for further details about enhanced measurement reporting please refer to parameter REPTYP (see below)). The parameter values express an RXLEV value in dB RXLEV_xx = xxdB (e.g. RXLEV_06 = -115 dBm + 6dB = -109 dBm) Note: The 3GPP standard (e.g. 44.0018) defines various similar reporting thresholds for different radio access technologies, and, within GERAN, different thresholds for the different frequency bands. Therefore the standard often mentions the reporting threshold with a wildcard: XXX_REPORTING_THRESHOLD, where XXX represents values such as (FDD, TDD, 900, 1800, 1900, 850, 400 etc.)

FDDREPTH2=0, object: BTS [BASICS] range: 0.. 63 default: 0 reference: 3GPP 45.008 3GPP 44.018

FDD reporting threshold 2, this parameter corresponds to the 3GPP parameter FDD_REPORTING_THRESHOLD_2 which is - broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater (in idle mode) and - sent to the MS/UE within the MEASUREMENT INFORMATION messages (in connected mode). It defines the threshold which each reported UTRAN FDD adjacent cell has to exceed with its not-reported value in order to be included in the ENHANCED MEASUREMENT REPORT (for further details about enhanced measurement reporting please refer to parameter REPTYP (see below)). As described for parameter FDDREPQTY, the UTRAN neighbour cell can either be reported by its RSCP or its Ec/No value. This means that a) when FDDREPQTY=RSCP, the threshold FDDREPTH2 is valid for the not-reported Ec/No value of the affected 3G neighbour cell. b) when FDDREPQTY=ECNO, the threshold FDDREPTH2 is valid for the not-reported RSCP value of the affected 3G neighbour cell. For the exact consideration of these threshold values within the neighbour cell ranking algorithm within the ENHANCED MEASUREMENT REPORT messages, please refer to parameter REPTYP.

FDDRSCPMI=MDB101, object: BTS [BASICS] range: MDB115, MDB113, MDB111, MDB109, MDB107, MDB105, MDB103, MDB101, MDB099, MDB097, MDB095, MDB093, MDB091, MDB089, MDB087, MDB085 default: MDB101 reference: 3GPP 45.008 3GPP 44.018

FDD RSCP minimum, this parameter corresponds to the 3GPP parameter FDD_ which is broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2ter and SI2quater and is related multiRAT mobiles - it is used by the UE for the cell re-selection algorithm from GSM to UTRAN. FDDRSPMI represents a minimum RSCP threshold a UTRAN must exceed to be considered for GSM to UTRAN cell reselection. For details about the cell reselection algorithm from GSM to UTRAN please refer to the description of parameter FDDQMI (see above). The parameter values express a value in dBm MDBxxx = - xxxdBm (e.g. MDB115 = -115dBm)

FHAMRFRC1=RATE_01, object: BTS[BASICS] range: RATE_01, RATE_02, RATE_03, RATE_04, RATE_05, RATE_06, RATE_07, RATE_08, <NULL> default: RATE_01 Parameter renamed from '<old name>'to 'FH<old name>' and moved from FHSY object to BTS[BASICS] object in BR8.0

AMR Full Rate Codec 1 for frequency hopping, this parameter defines the first AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Full Rate in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRFRC1 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.


AMR Full Rate Codec 2 for frequency hopping, this parameter defines the second AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Full Rate in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRFRC2 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.


AMR Full Rate Codec 3 for frequency hopping, this parameter defines the third AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Full Rate in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRFRC3 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.

AMR Full Rate Codec 4 for frequency hopping, this parameter defines the fourth AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Full Rate in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRFRC4 in command CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.

FHAMRFRIC=START_MODE_FR, object: BTS[BASICS] range: START_MODE_FR CODEC_MODE_01 CODEC_MODE_02 CODEC_MODE_03 CODEC_MODE_04 default: START_MODE_FR Parameter renamed from '<old name>'to 'FH<old name>' and moved from FHSY object to BTS[BASICS] object in BR8.0

AMR Full Rate Initial Codec for frequency hopping, this parameter defines which AMR FR CODEC of the created AMR FR ACS shall be used first after FR TCH assignment in case of active 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 AMRFRIC if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.

FHAMRFRTH12=7-4, object: BTS[BASICS] format: threshold-hysteresis unit: threshold: 0.5dB hysteresis: 0.5dB range: threshold: 0..63 [0..31.5dB] hysteresis: 0..15 [0..7.5dB] default: threshold: 7 [3.5 dB] hysteresis: 4 [1.0 dB] Parameter renamed from '<old name>'to 'FH<old name>' and moved from FHSY object to BTS[BASICS] object in BR8.0

AMR Full Rate Thresholds 12 for frequency hopping, 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 active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRFRTH12 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.


AMR Full Rate Thresholds 23 for frequency hopping, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRFRC2 to AMRFRC3 and vice versa in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRFRTH23 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.


AMR Full Rate Thresholds 34 for frequency hopping, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRFRC3 to AMRFRC4 and vice versa in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent AMRFRTH34 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.

FHAMRHRC1=RATE_01, object: BTS[BASICS] range: RATE_01, RATE_02, RATE_03, RATE_04, RATE_05, <NULL> default: RATE_01 Parameter renamed from '<old name>'to 'FH<old name>' and moved from FHSY object to BTS[BASICS] object in BR8.0

AMR Half Rate Codec 1 for frequency hopping, this parameter defines the first AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Half Rate in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRHRC1 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.


AMR Half Rate Codec 2 for frequency hopping, this parameter defines the second AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Half Rate in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRHRC2 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.


AMR Half Rate Codec 3 for frequency hopping, this parameter defines the third AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Half Rate in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRHRC3 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.


AMR Half Rate Codec 4 for frequency hopping, this parameter defines the fourth AMR (Adaptive Multi Rate) active CODEC of the Active CODEC Set (ACS) for AMR Half Rate in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRHRC4 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.

FHAMRHRIC=START_MODE_HR, object: BTS[BASICS] range: START_MODE_HR CODEC_MODE_01 CODEC_MODE_02 CODEC_MODE_03 CODEC_MODE_04 default: START_MODE_HR Parameter renamed from '<old name>'to 'FH<old name>' and moved from FHSY object to BTS[BASICS] object in BR8.0

AMR Half Rate Initial Codec for frequency hopping, this parameter defines which AMR HR CODEC of the created AMR HR ACS shall be used first after HR TCH assignment in case of active 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 AMRHRIC if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.

FHAMRHRTH12=19-4, object: BTS[BASICS] format: threshold-hysteresis unit: threshold: 0.5dB hysteresis: 0.5dB range: threshold: 0..63 [0..31.5dB] hysteresis: 0..15 [0..7.5dB] default: threshold: 19 [9.0 dB] hysteresis: 4 [2.0 dB] Parameter renamed from '<old name>'to 'FH<old name>' and moved from FHSY object to BTS[BASICS] object in BR8.0

AMR Half Rate Thresholds 12 for frequency hopping, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRHRC1 to AMRHRC2 and vice versa in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRHRTH12 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.

FHAMRHRTH23=24-4, object: BTS[BASICS] format: threshold-hysteresis unit: threshold: 0.5dB hysteresis: 0.5dB range: threshold: 0..63 [0..31.5dB] hysteresis: 0..15 [0..7.5dB] default: threshold: 24 [12.0 dB] hysteresis: 4 [2.0 dB] Parameter renamed from '<old name>'to 'FH<old name>' and moved from FHSY object to BTS[BASICS] object in BR8.0

AMR Half Rate Thresholds 23 for frequency hopping, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRHRC2 to AMRHRC3 and vice versa in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRHRTH23 in command CREATE BTS [BASICS]) if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.

FHAMRHRTH34=30-4, object: BTS[BASICS] 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: 30 [15.0 dB] (BTS+) <NULL> (BTS1) hysteresis: 4 [2.0 dB] Parameter renamed from '<old name>'to 'FH<old name>' and moved from FHSY object to BTS[BASICS] object in BR8.0

AMR Half Rate Thresholds 34 for frequency hopping, this parameter defines the C/I threshold and the associated hysteresis for the AMR downlink CODEC mode adaptation transition from AMRHRC3 to AMRHRC4 and vice versa in case of active frequency hopping (see also parameter HOPP in command SET BTS [OPTIONS]. This parameter eclipses its equivalent parameter AMRHRTH34 if frequency hopping is currently active for an AMR call. For further details about the parameter values and AMR parameters and thresholds please refer to the parameter AMRFRC1.



FRACTAMRTH1=3000, object: BTS [BASICS] range: 0.. 10000 default: 3000

Full Rate Activation AMR threshold, this parameter is only relevant if the parameters EADVCMPDCMHO and EADVCMPHOAMR are set to TRUE (see SET HAND [BASICS]). It is used for load-dependent AMR Decompression Handover. The task of this handover type is to hand over as many AMR calls (that currently occupy a HR TCH to a FR TCH) as possible to provide the best possible QoS and speech quality in time periods with an acceptably low TCH load and Abis pool TCH load. On every expiry of the timer TRFCT (see SET BSC) the BSC checks the traffic load in the TRXs/service layers that are included in the SLLs for AMR and non-AMR speech service of its cells and compares it to the threshold FRACTAMRTH1. 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 BTS [BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). 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 GMANPRESPRM 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 GMANPRESPRM, the 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 TRXs/service layers that are included in the SLLs for AMR and non-AMR speech service) drops below the threshold FRACTAMRTH1, the BSC enables the load-dependent AMR decompression handover in the affected BTS by sending a SET ATTRIBUTE message with the appropriate indications to the BTS. This indication starts the load-dependent AMR decompression handover decision process in the BTS. For further details, please refer to the parameter EADVCMPDCMHO (see command SET HAND [BASICS]). Note: Interworking of 'Service Dependent Channel Allocation' with traffic load calculation The percentage calculation done for load dependent Compression/Decompression Handover is done referring only to the TRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea (primary/complementary). Please refer to the command SET BTS [SERVICE] for further explanations.

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

no. of TCH in state unlocked/enabled



FRACTAMRTH2=3000, object: BTS [BASICS] range: 0.. 10000 default: 3000

Full Rate Activation Threshold 2 for AMR calls, this parameter is only relevant if the parameters EADVCMPDCMHO and EADVCMPHOAMR are set to TRUE (see SET HAND [BASICS]). FRACTAMRTH2 is the equivalent to the parameter FRACTTH2 (see below) for AMR calls and defines a traffic load threshold which is evaluated for load-dependent AMR decompression handover. It has exactly the same function like the parameter FRACTAMRTH1 (see above) but affects 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]).

FRACTTH1=3000, object: BTS [BASICS] range: 0.. 10000 default: 3000

Full Rate Activation Threshold 1, this parameter this parameter is only relevant if the parameters EADVCMPDCMHO and EADVCMPHOAMR are set to TRUE (see SET HAND [BASICS]). It is used for load-dependent non-AMR Decompression Handover. The task of this handover type is to hand over as many non-AMR calls (that currently occupy a HR TCH to a (E)FR TCH) as possible to provide the best possible QoS and speech quality in time periods with an acceptably low TCH load and Abis pool TCH load. On every expiry of the timer TRFCT (see SET BSC) the BSC checks the traffic load in the TRXs/service layers that are included in the SLLs for AMR and non-AMR speech service of its cells and compares it to the threshold FRACTTH1. 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 BTS [BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). 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 GMANPRESPRM 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 GMANPRESPRM, the 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 TRXs/service layers that are included in the SLLs for AMR and non-AMR speech service) drops below the threshold FRACTTH1, the BSC enables the load-dependent non-AMR decompression handover in the affected BTS by sending a SET ATTRIBUTE message with the appropriate indications to the BTS.



This indication starts the load-dependent non-AMR decompression handover decision process in the BTS. For further details, please refer to the parameter EADVCMPDCMHO (see command SET HAND [BASICS]). Note: Interworking of 'Service Dependent Channel Allocation' with traffic load calculation The percentage calculation done for load dependent Compression/Decompression Handover is done referring only to the TRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea (primary/complementary). Please refer to the command SET BTS [SERVICE] for further explanations.

FRACTTH2=3000, object: BTS [BASICS] range: 0.. 10000 default: 3000

Full Rate Activation Threshold 2 for non-AMR calls, this parameter is only relevant if the parameters EADVCMPDCMHO and EADVCMPHOAMR are set to TRUE (see SET HAND [BASICS]). FRACTTH2 is the equivalent to the parameter FRACTAMRTH2 (see above) for non-AMR calls and defines a traffic load threshold which is evaluated for load-dependent non-AMR decompression handover. It has exactly the same function like the parameter FRACTTH1 (see above) but affects 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]).

FRANOFFS=<NULL>, object: BTS [BASICS] range: 0.. 255, <NULL> default: <NULL>

Frame number offset, this parameter is relevant if the feature 'inter Site Synchronization' (ISS) is used and indicates, as an integer value, the frame number offset of the BTS. For further details about ISS and the meaning of this parameter please refer to parameter EINTSITSYN (see command CREATE BTSM).

GEXTS=<NULL>, object: BTS [BASICS] range: ALL900, ALLFREQ, <NULL> default: <NULL>

GPRS extension, this parameter specifies if GPRS/EGPRS is allowed also in non-BCCH bands of a dual band standard cell (parameter value CELLTYP=DBSTDCELL, see above). Please do also refer to parameter SYSID (see below) for further information.

GUARMABIS=0, object: BTS [BASICS] 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, object: BTS [BASICS] 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 - load dependent AMR Compression Handover As the functionality of these features is different in both cases, they are explained in separate points. a) Cell Load Dependent Activation of Half Rate for AMR calls In this case HRACTAMRT1 is only relevant if the parameter EHRACTAMR (see above) 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 all TRXs/service layers that are included in the SLLs defined for the AMR services (in case of standard cell) - in the TRXs/service layers that are included in the SLLs defined for the AMR services belonging to the complete area of a concentric cell (see parameter CONCELL in command CREATE BTS [BASICS]) - in the TRXs/service layers that are included in the SLLs defined for the AMR services belonging to the far area of an extended cell (see parameter CELLTYPE=EXTCELL in command CREATE BTS [BASICS]) If the traffic load on the TRXs/service layers that are included in the SLLs of the AMR service 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 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)).

Interworking of Cell Load Dependent Activation of HR for AMR (EHRACTAMR=TRUE) and non-AMR (EHRACT=TRUE) with MSLS Assuming that - the BSC receives a TCH request with all speech versions supported and AMR indicated as 'preferred' (AMR FR, AMR HR, E(FR), HR) and - the BTS has SLLs for both AMR and non-AMR speech services and - CLDAHR is activated for both AMR and non-AMR the following sequence of events will take place during the BSC resource allocation process: 1) As AMR is indicated as preferred, the BSC will calculate the load on all TCH resources that belong to TRX that included in the SLLs supporting AMR services and compare it against the threshold HRACTAMRT1 or -T2 depending on the affected area. 2) Depending on the load/threshold comparison result the BSC looks for a suitable resource (FR/HR) on the AMR layer. 3) When no resource can be found on the AMR layer, the BSC will compare the calculated the load on all TCH resources (that belong to TRX that included in the SLLs supporting non-AMR services) against the threshold HRACTT1 or -T2 depending on the affected area. 4) Depending on the load/threshold comparison result the BSC looks for a suitable resource (FR/HR) on the non-AMR layer.



b) Load dependent AMR compression handover On every expiry of the timer TRFCT (see SET BSC) the BSC checks the traffic load in the TRXs/service layers that are included in the SLLs for AMR and non-AMR speech service of 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 BTS [BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). 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 GMANPRESPRM 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 GMANPRESPRM, the 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 TRXs/service layers that are included in the SLLs for AMR and non-AMR speech service 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. Note: Interworking of 'Service Dependent Channel Allocation' with traffic load calculation The percentage calculation done for load dependent Compression/Decompression Handover is done referring only to the TRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea (primary/complementary). Please refer to the command SET BTS [SERVICE] for further explanations.





HRACTAMRT2=6000, object: BTS [BASICS] 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 affects 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 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 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, object: BTS [BASICS] unit: 0,01 % range: 0..10000 default: 6000

HR activation threshold 1, this parameter defines a threshold which is used by the following features a) Cell Load Dependent Activation of Half Rate and b) load-dependent AMR compression handover a) Cell Load Dependent Activation of Half Rate This feature applies if the parameter EHRACT (see above) is set to TRUE. For this case HRACTT1 defines a traffic load threshold that is evaluated for the forced speech version selection for incoming non-AMR TCH seizures. For this, the BSC compares HRACTT1 to the percentage of busy TCHs (related to the available TCHs) within - all TRXs/service layers that are included in the SLLs defined for the non-AMR speech services in the cell (for standard cells) - the TRXs/service layers that are included in the SLLs defined for the non-AMR speech services in the complete area (for concentric cells) - the TRXs/service layers that are included in the SLLs defined for the non-AMR speech services in the far area (for extended cells). For the feature CLDAHR the BSC calculates the traffic load as follows Attention: - Generally a TCH\F is counted as 2, a TCH\H is counted as 1! - (*) 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. - (**) The GPRS downgrade strategy (see parameter DGRSTRGY in command SET BTS [BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). 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 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 a GPRS call utilizes more TCHs than configured as 'reserved' by GMANPRESPRM, the 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 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 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.

Interworking of Cell Load Dependent Activation of HR for AMR (EHRACTAMR=TRUE) and non-AMR (EHRACT=TRUE) with MSLS Assuming that

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

no. of configured TCH



- the BSC receives a TCH request with all speech versions supported and AMR indicated as 'preferred' (AMR FR, AMR HR, E(FR), HR) and - the BTS has SLLs for both AMR and non-AMR speech services and - CLDAHR is activated for both AMR and non-AMR the following sequence of events will take place during the BSC resource allocation process: 1) As AMR is indicated as preferred, the BSC will calculate the load on all TCH resources that belong to TRX that included in the SLLs supporting AMR services and compare it against the threshold HRACTAMRT1 or -T2 depending on the affected area. 2) Depending on the load/threshold comparison result the BSC looks for a suitable resource (FR/HR) on the AMR layer. 3) When no resource can be found on the AMR layer, the BSC will compare the calculated the load on all TCH resources (that belong to TRX that included in the SLLs supporting non-AMR services) against the threshold HRACTT1 or -T2 depending on the affected area. 4) Depending on the load/threshold comparison result the BSC looks for a suitable resource (FR/HR) on the non-AMR layer.

b) load dependent non-AMR compression handover The purpose of Compression handover is, in case of high TCH load, to transfer (E)FR calls with suitably good radio link quality to a HR TCH by an intracell handover in order to prevent TCH blocking by providing additional TCH resources. On every expiry of the timer TRFCT (see SET BSC) the BSC checks the traffic load in the TRXs/service layers that are included in the SLLs for AMR and non-AMR speech service of its cells and compares it to the threshold HRACTT1. For non-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 BTS [BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). 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 GMANPRESPRM 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 GMANPRESPRM, the 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 TRXs/service layers that are included in the SLLs for AMR and non-AMR speech service exceeds the threshold HRACTT1, the BSC enables the non-AMR compression handover in



the affected BTS by sending a SET ATTRIBUTE message with the appropriate indications to the BTS. This indication starts the non-AMR compression handover decision process in the BTS which has the task to hand over all non-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 non-AMR compression handover are defined by the C/I thresholds HOTH(E)FRCDL and HOTH(E)FRCUL (see SET HAND [BASICS]). Interworking of the feature 'Multiple service Layer Support' (MSLS) with traffic load calculation The percentage calculation done for load dependent Compression/Decompression Handover is done referring only to the TRXs included in the SLLs for the AMR speech and non-AMR speech service types, separately for every subarea (primary/complementary). Please refer to the command SET BTS [SERVICE] for further explanations.

HRACTT2=1000, object: BTS [BASICS] 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 TRXs/service layers that are included in the SLLs defined for the non-AMR speech services in the inner area (for concentric cells) - the TRXs/service layers that are included in the SLLs defined for the non-AMR speech services in the near area (for extended cells). The thresholds are used in exact correspondence with the explanations provided for HRACTT1.

LCBM0=<NULL>, object: BTS [BASICS] 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>, object: BTS [BASICS] format and range: see LCBM0 default: <NULL>

Local Cell Broadcast Message 1, this parameter 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.



MEAEXTBCCH= FALSE, object: BTS [BASICS] range: TRUE, FALSE default: FALSE

Measure extra BCCH frequencies, this parameter enables/disables the feature 'Automatic Procedure to measure extra BCCH Frequencies per cell'.

MSTXPMAXDCS=0, object: BTS [BASICS] unit: see tables below range: 0..15 default: 0 Reference: 3GPP 45.008 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 frequencies of two different frequency bands are used in the cell (dual band concentric cells, or dual band standard cells, refer to parameters CELLTYP and CONCELL, see above), both the parameters MSTXPMAXGSM and MSTXPMAXDCS must be set, 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, object: BTS [BASICS] unit: see tables below 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 frequencies of two different frequency bands are used in the cell (dual band concentric cells, or dual band standard cells, refer to parameters CELLTYP and CONCELL, see above), both the parameters MSTXPMAXGSM and MSTXPMAXDCS must be set, 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, object: BTS [BASICS] unit: see tables below 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 frequencies of two different frequency bands are used in the cell (dual band concentric cells, or dual band standard cells, refer to parameters CELLTYP and CONCELL, see above), both the parameters MSTXPMAXGSM and 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



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, object: BTS [BASICS] range: 0..3 default: 0 reference: 3GPP 45.008 3GPP 44.018

Number of multi band cells, this parameter corresponds to the 3GPP parameter MULTIBAND_REPORTING which is - broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater (in idle mode) and - sent to the MS/UE within the MEASUREMENT INFORMATION messages (in connected mode). 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. Please see also parameter UMTSSRHPRI (same command, see below).

PCCCHLDI=255, object: BTS [BASICS] 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 PCH queues. Attention: if TMSI Reallocation is disabled in the network (i.e. paging is exclusively done with the IMSI), it is recommended to disable 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, object: BTS [BASICS] unit: 20s range: 0..31 31= TEMPOFF ignored default: 0 Reference: 3GPP 45.008 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, object: BTS [BASICS] range: 0..255 default: 255 Reference: GSM 03.03 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.

PNOFACCH=5, object: BTS [BASICS] unit: 0.5 sec range: 2..10 2=1.0 sec 3=1.5 sec ... 10=5.0 sec <NULL> default: 5= 2.5 sec

Period for Notification on FACCH, this parameter specifies period (repetition rate) for the FACCH notification for a given ASCI call.

PUREBBSIG44CONF parameter cancelled in BR8.0



QSRHC=NEVER, object: BTS [BASICS] range: UMDB98 UMDB94 UMDB90 UMDB86 UMDB82 UMDB78 UMDB74 ALWAYS OMDB78 OMDB74 OMDB70 OMDB66 OMDB62 OMDB58 OMDB54 NEVER default: NEVER reference: 3GPP 45.008 3GPP 44.018

Qsearch Connected, this parameter corresponds to the 3GPP parameter Qsearch_C which is sent to the MS/UE within the MEASUREMENT INFORMATION messages on the SACCH. It defines a threshold condition which enables the searching for 3G cells in connected mode, that is valid after receipt of the MEASUREMENT INORMATION message on the SACCH. In other words, if the threshold condition defined by QSRHC is fulfilled for the serving (2G) cell, then 3G cells shall be considered for handover neighbour cell monitoring. An equivalent 3G search threshold does also exist for the idle mode: Qsearch Idle (parameter QSRHI, see below). 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 serving 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 serving 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. As long as no MEASUREMENT INFORMATION message has been received after the MS/UE has entered the 'connected mode', the 3G search mode is determined by the parameter Qsearch_C_Initial (parameter QSRHCINI, see below).

QSRHCINI=QSEARCHI, object: BTS [BASICS] range: QSEARCHI, ALWAYS default: QSEARCHI reference: 3GPP 45.008 3GPP 44.018

Q search Connected initial, this parameter corresponds to the 3GPP parameter Qsearch_C_Initial which is broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater and indicates the initial value to be used in connected mode before the MS receives QSRHC (Qsearch_C, see above) 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, object: BTS [BASICS] range: UMDB98 UMDB94 UMDB90 UMDB86 UMDB82 UMDB78 UMDB74 ALWAYS OMDB78 OMDB74 OMDB70 OMDB66 OMDB62 OMDB58 OMDB54 NEVER default: NEVER reference: 3GPP 45.008 3GPP 44.018

Q Search Idle, this parameter corresponds to the 3GPP parameter Qsearch_l which is broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater and 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 the serving 2G cell, then 3G cells shall be considered for cell selection/reselection. This threshold is valid as long as the MS/UE has not entered the connected mode. If it does, the initial threshold value to be used for connected mode is defined by the parameter Qsearch_C_Initial (see parameter QSRHCINI), which is then replaced by the threshold Qsearch_C, which is sent to the MS within the first MEASUREMENT INFORMATION message. 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, object: BTS [BASICS] 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 a little 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, Convolution 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). 2) 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, object: BTS [BASICS] 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, object: BTS [BASICS] range: 0..15 0 = counter value 4 15 = counter value 64 default: 4 Reference: 3GPP 45.008 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). Notes: - Please note that, starting from BR8.0, this parameter can also be separately managed for different service types using the parameters SGxxPCPAR (see command SET PWRC). - If 'Call Re-Establishment' (see parameter CREALL) is enabled a low value of radio link time-out increases the number of call reestablishments because a decrease of RDLNKTO may lead to an earlier declaration of radio link failures.



REPTYP=NORMAL, object: BTS [BASICS] range: NORMAL, ENHANCED default: NORMAL reference: 3GPP 45.008 3GPP 44.018

Report type, this parameter indicates to the mobile to use the ENHANCED MEASUREMENT REPORT or MEASUREMENT REPORT messages for measurements reporting. The setting of this parameter is reflected in the IE REPORT_TYPE which is sent to the MS/UE in connected mode within the MEASUREMENT INFORMATION message via the SACCH. Further information the MS/UE needs for enhanced measurement reporting is sent to the MS/UE within the SYSTEM INFORMATION TYPE 2quater via the BCCH. Enhanced measurement reporting is only supported by particular mobiles and comprises new features and functionalities: - While in case of normal reporting only 6 neighbour cells can be reported within one MEASUREMENT REPORT message, EMR can report much more than 6 neighbour cells within one ENHANCED MEASUREMENT REPORT message. - EMR reports provide additional measurement values such as the Bit Error probability (BEP) of the serving cell channel, the 'number of correctly received downlink blocks' which can be used to determined the downlink Frame Erasure Rate (FER) which is monitored by suitable PM counters in the BTS - With EMR a reporting is possible for both 'valid' and 'invalid' BSICs. Reporting with Enhanced Measurement Reporting (EMR) When in dedicated mode or group transmit mode, the MS/UE regularly sends either MEASUREMENT REPORT or ENHANCED MEASUREMENT REPORT messages to the network (the uses ENHANCED MEASUREMENT REPORT messages instead of MEASUREMENT REPORT messages if this is indicated by the parameter REPORT_TYPE and if at least one BSIC is allocated to each BA (list) frequency). These messages contain measurement results about reception characteristics from the current cell and from neighbour cells. The MS/UE derives the BA list (BA = BCCH Allocation, list of the BCCHs used by the configured neighbour cells as defined in the ADJC and ADJC3G objects), which is the initial basis for the measurements, from information received a) on the BCCH in SYSTEM INFORMATION TYPE 2 and optionally SI2bis and/or SI2ter messages (SI2quater messages may add information for the GSM Neighbour and provide the 3G Neighbour Cell list) and b) on the SACCH in System Information 5 and optionally 5bis and/or 5ter messages (MEASUREMENT INFORMATION messages may add information for the GSM Neighbour Cell List and provide the 3G Neighbour Cell list). For reporting with the MEASUREMENT REPORT message, reporting is performed on two separate neighbour lists: the BA (list) and the 3G Neighbour Cell List (for a multi-RAT MS). For reporting with the ENHANCED MEASUREMENT REPORT message, reporting is performed on the Neighbour Cell List, which is the concatenation of the GSM Neighbour Cell list and the 3G Neighbour Cell list (if any). The Neighbour Cell list may contain up to 96 Neighbour Cells. ENHANCED MEASUREMENT REPORT messages are sent by the MS with a defined periodicity which depends on the used channel type and the mode the MS/UE is currently in (see 3GPP 45.008 for further details). Contents of ENHANCED MEASUREMENT REPORT An ENHANCED MEASUREMENT REPORT message contains (among others) the following main data: • BA_USED = 2G BCCH Allocation (BCCH list of 2G neighbours) • 3G_BA_USED = 3G BCCH Allocation (BCCH list of 3G

neighbours)



• REPORTING_QUANTITY = Type of reported value (parameter FDDREPQTY, see above)

• Serving cell measurement data - DTX used flag, indicates if DTX was used in uplink in the measurement period - RXLEV_VAL, downlink RXLEV value of serving cell - RXQUAL_FULL, downlink RXQUAL value of serving cell - MEAN_BEP and CV-BEP, the average over the reporting period of the mean and 'coefficient of variation' of the Bit Error Probability (BEP) measures. - NBR_RCVD_BLOCKS, number of correctly decoded downlink blocks in the measurement period (this value is used by the BTS to calculate the downlink FER)

• Neighbour cell measurement data - BCCH frequency number, relative frequency number within BA list - BSIC - RXLEV_NCELL, downlink RXLEV value of neighbour cell

Neighbour cell ordering Within the message part that contains the neighbour cell measurement data the neighbour cell measurements are listed in a defined priority order: 1) the number of strongest valid GSM cells with a reported value

equal or greater than the reporting threshold for its band (see parameter FDDREPTH) in the frequency band of the serving cell

2) the number of strongest valid GSM cells with a reported value equal or greater than the reporting threshold for its band (see parameter FDDREPTH) in each of the frequency bands in the BA list excluding that of the serving cell

3) the number of best valid cells and with a reported value equal or greater than XXX_REPORTING_THRESHOLD (see parameter FDDREPTH), in each supported other radio access technology/mode in the 3G neighbour cell list, according to the value of the parameters XXX_MULTIRAT_REPORTING (see parameter FDDMURREP). When the radio access technology is UTRAN FDD, then additionally the non-reported value (from CPICH Ec/No and CPICH RSCP) must be equal or greater than FDD_REPORTING_THRESHOLD_2 (see parameter FDDREPTH2).

4) Remaining cells of lower priorities, validity or access technologies (see 3GPP specification 44.018)

For each of the priority levels above, the following rules apply: - If the number of valid cells is less than indicated the unused positions in the report are left for the lower priorized cells; - If there is not enough space in the report for all valid cells, the cells are reported that have the highest sum of the reported value (RXLEV or as defined in subclause 8.1.5) and the parameter XXX_REPORTING_OFFSET for respective radio access technology (see parameter FDDREPO). This offset parameter, however, does not affect the actual reported value. If a cell can not be reported due to lack of space in the report, then no cell with a lower value shall be reported, even if one of these cells with a lower value would fit into the report. 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, object: BTS [BASICS] 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 Reference: 3GPP 45.008 GSM 04.08 GSM 03.22

Minimum received level at the MS required for access to the network on the RACH. This parameter corresponds to the 3GPP parameter RXLEV_ACCESS_MIN which 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, object: BTS [BASICS] 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, object: BTS [BASICS] range: BB900 (GSM baseband) DCS1800 EXT900 (GSM mixed band) GSMR (railway GSM), PCS1900 GSMDCS GSM850 GSM850PCS Reference: GSM 04.08 Parameter value F2ONLY900 removed in BR8.0!

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 is to be configured with TRX frequencies of two different frequency bands (dual band concentric cells, or dual band standard cells, refer to parameters CELLTYP and CONCELL, see above). The value F2ONLY900 value has been removed in BR8.0 since the behaviour associated to this value has been realized by defining all the primary frequencies as “hybrid” including also the BCCH. When the BCCH is configured in the extended band or on a “hybrid” frequency, the BSC refuses the configuration of the primary frequency. As a consequence, the current GSMDCS (EXT900+DCS1800) configuration is extended in such a way that it includes also the combination F2ONLY900+DSC1800. The attribute GEXTS (see above) has been introduced with the values ALL900 and <NULL>”. The value ALL900 specifies that all the 900Mhz frequencies can be used for GPRS/EGPRS and therefore can be included into the SYS INFO TYPE 1 message. The value NULL specifies that only the primary frequencies are considered and therefore GPRS/EGPRS services are supported and provided only in the primary band.

TAADJ=0, object: BTS [BASICS] 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, object: BTS [BASICS] 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 further on. 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 functionality 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, object: BTS [BASICS] range: 0..3 default: 0 reference: 3GPP 44.018 3GPP 45.008

TDD multiRAT reporting, this parameter corresponds to the 3GPP parameter TDD_MULTIRAT_REPORTING which is - broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater (in idle mode) and - sent to the MS/UE within the MEASUREMENT INFORMATION messages (in connected mode). It indicates the number TDD UTRAN cells the UE shall include in the MEASUREMENT REPORTs. The UE is thus instructed to report, if available, this number of 3G neighbour cells. Which value should be set for this parameter strongly depends on the environment of the cell (BTS). The default value of '0' only makes sense in areas without any 3G TDD neighbours (no ADJC3G object created for this BTS). The more really relevant 3G TDD cells are available, the higher the value should be set. Usually 6 neighbour cells can be reported within one MEASUREMENT REPORT message. The value must therefore be set considering how many 2G neighbour cells shall be reported in any case.

TDDQO=DB00, object: BTS [BASICS] range: ALWAYS MDB28 MDB24 MDB20 MDB16 MDB12 MDB08 MDB04 DB00 DB04 DB08 DB12 DB16 DB20 DB24 DB28 default: DB00 reference: 3GPP 44.018 3GPP 45.008

TDD Q offset, this parameter corresponds to the 3GPP parameter TDD_Qoffset which is broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2ter and SI2quater and is related multiRAT mobiles; it is used by the UE for the cell re-selection algorithm from GSM to UTRAN. It defines a level offset by which the RLA_C value of an UTRAN FDD neighbour cell must exceed the RLA_C of the serving GSM cell before the UTRAN neighbour cell is considered for cell reselection from GSM to UTRAN. For details about the cell reselection algorithm from GSM to UTRAN please refer to the description of parameter FDDQMI (see above). The parameter values express a value in dB MDBxx = - xxdB (e.g. MDB20 = -20dB) DBxx = xxdB (e.g. DB20 = 20dB) The value ALWAYS indicates an infinite negative (-∞ dB) offset, so with this setting a 3G Mobile will always change to the 3G network if any acceptable 3G cell is available.

TDDREPO=DB00, object: BTS [BASICS] range: DB00 DB06 DB12 DB18 DB24 DB30 DB36 DB42 default: DB00 reference: 3GPP 44.018 3GPP 45.008

TDD Reporting Offset, this parameter corresponds to the 3GPP parameter TDD_REPORTING_OFFSET and is broadcast on the BCCH in the SYSTEM INFORMATION 2quater. It defines a fixed offset to be applied to all reported TDD 3G neighbour cells. The parameter values express a value in dBm DBxx = xxdBm (e.g. DB10 = 10dBm) For further details please refer to the description of parameter FDDREPO (see above).

TDDREPTH=RXLEV_00, object: BTS [BASICS] range: RXLEV_00, RXLEV_06, RXLEV_12, RXLEV_18, RXLEV_24, RXLEV_30, RXLEV_36, NEVER default: RXLEV_00 reference: 3GPP 44.018 3GPP 45.008

TDD Reporting Threshold, this parameter corresponds to the 3GPP parameter TDD_REPORTING_THRESHOLD and is broadcast on the BCCH in the SYSTEM INFORMATION 2quater. It defines threshold which TDD 3G cell has to exceed in order to be reported in Enhanced Measurement Report. The parameter values express an RXLEV value in dB RXLEV_xx = xxdB (e.g. RXLEV_06 = -115 dBm + 6dB = -109 dBm) For further details please refer to the description of parameter FDDREPTH (see above).

TEMPOFF=1, object: BTS [BASICS] unit: 10dB range: 0..7, 7=∞ default: 1 Reference: 3GPP 45.008 GSM 03.22

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, object: BTS [BASICS] 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, object: BTS [BASICS] 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, object: BTS [BASICS] range: TRUE, FALSE default: TRUE reference: 3GPP 44.018 3GPP 45.008

UMTS search priority, this parameter corresponds to the 3GPP parameter 3G_SEARCH_PRIO which is - broadcast on the BCCH in the SYSTEM INFORMATION TYPE 2quater (in idle mode) and - sent to the MS/UE within the MEASUREMENT INFORMATION messages (in connected mode). indicates if a mobile may 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 ). The parameter 3G_SEARCH_PRIO is considered during BSIC decoding of surrounding neighbour cells of different radio access technologies. The MS uses at least 4 spare frames per SACCH block period for the decoding the BSICs (e.g. in the case of TCH/F, four idle frames per SACCH block period). These frames are termed 'search' frames. The MS attempts to demodulate the SCH on the BCCH carrier of as many surrounding cells as possible, and to decode the BSIC as often as possible, and as a minimum, at least once every 10 seconds. A multi-RAT MS is allowed to extend this period to 13 seconds, if the neighbour cell list contains cells from other RATs and if indicated by the parameter 3G_SEARCH_PRIO. The MS gives priority for synchronisation attempts in signal strength order and considering the parameter MULTIBAND_REPORTING (parameter ENMU, see command SET BTS).

Setting the cell specific parameters for DMA Admission Control < With this command all cell specific attributes related to the feature

'Admission Control' which is associated to the feature 'Dynamic MAIO Allocation' (DMA). For further details about DMA, please refer to the explanations given for the command CREATE CBTS. As described in the CBTS object, DMA is a feature which is used in networks with a 1/1 reuse (i.e. the same frequencies are used for the hopping TRXs in all cells). The DMA algorithm manages the pool of available MAIOs/timeslots on a BTSM (site) level and tries to avoid, during TCH allocation, co-channel interference and adjacent channel interference as good as possible. However, as DMA is used mainly in site configurations where the number of TRXs is higher than the number of frequencies used in the Mobile Allocation of the frequency hopping system, a reuse of MAIOs cannot be avoided. The benefit of DMA becomes mainly evident in case of inhomogeneous traffic distribution among the cells of the same site, i.e. the interference can be kept acceptably low if e.g. one cell of the BTSM carries a high traffic volume, while the other two cells serve lower traffic figures. The more traffic is managed in the other cells, the more probable a MAIO reuse and thus the higher the risk of interference will be.

Purpose and principle of the feature 'DMA Admission Control' From the operator point of view the a network is usually planned in such a way that a maximum capacity is achieved at an acceptable quality of service (QoS) - this is especially relevant in networks with a tight frequency reuse (e.g. 1/1). The capacity enhancement of DMA is achieved by an intelligent sharing the channel resources of the cells belonging to the same BTSM, but, as an increase of traffic in the cells always means an increase of the overall interference level, the capacity enhancement is limited by 1) a QoS requirement which is, for DMA, defined by the 'Bad Quality Probability' (BQP) and 2) the load criterion 'Effective Fractional Load' (EFL). The explanation of these two indicators is as follows: 1) The Bad Quality Probability BQP is a value that estimates the probability for a speech call to suffer from bad quality and is calculated from the Frame Erasure Rate (FER, measured by the BTS) as follows:

In other words, the BQP is the probability (P) that the FER exceeds a certain maximum threshold. The FER maximum threshold FERmax is defined by the parameter ACFERMAX (see parameter listing below). The QoS requirement is still fulfilled if the BQP does not exceed a configurable BQP threshold:

The BQP threshold BQPmax is defined by the parameter ACBQPMAX (see parameter listing below). 2) The Effective Fractional Load EFL represents the 'Traffic volume (Erlang) per hopping frequency' and is calculated by the formula

BQP ≤ BQPmax

* Mean no. of busy TCH on DMA layer = Mean no. busy FR + 0.5∗mean no. busy HR

BQP = P(FER > FERmax)

∗ 100EFL [%] = Mean no. of busy TCH on DMA layer *

8 ∗ Total no. of hopping frequencies on DMA layer

While in releases < BR8.0, admission control was only based on 'hard blocking' (which means that a TCH request is rejected only no TCH is available in the BTS), in releases starting from BR8.0 admission control (i.e. rejection of new TCH requests) can be also based on 'soft blocking' if the site configuration features DMA service layers. The task of the feature DMA AC is to monitor both the current EFL and the current BQP in the cell and to consider these two factors during the TCH allocation: if particular requirements for BQP and EFL are not fulfilled (e.g. if the BQP exceeds a configurable threshold for a particular EFL, see further details below), new call requests are rejected to keep the interference low enough to ensure an acceptable speech quality for the already established calls. The rejection of a new call request based on the BQP criterion is called 'soft blocking'. Due to the fact that DMA is only applicable to 'speech only' service layers (AMR, non-AMR), also DMA Admission Control (DMA AC) is only applicable to these service layers. Remark: The evaluation of the 'soft blocking' criteria (and thus the rejection of TCH requests in case these criteria are fulfilled) is only performed for call setups in the serving cell. All types of incoming inter-cell handovers are served by idle TCHs (if available) even if the DMA layers of the cell are soft-blocked for call setup.

Detailed Functional Description of DMA Admission Control 1) DMA Admission Control Decision Algorithm The BTS continuously measures the FER of the ongoing calls and calculates the current EFL and BQP figures for each configured DMA layer / CFHSY (see command CREATE CFHSY - one CFHSY can be created per frequency band). As during the BTS alignment all parameter values relevant for DMA AC are transmitted to the BTS, the BTS can (and actually does) check the DMA AC soft-blocking criterion using the AC decision algorithm. The determine the value of the 'soft blocking flag', the AC decision algorithm in the BTS checks the EFL and BQP conditions in a way as indicated in the table below:

Explanation: - If the EFL is lower than or equal to the configurable maximum EFL threshold 'min EFL_DMA' (see parameter ACMINEFLDMA), the new call setup on the DMA layer is admitted in any case. - If the EFL is higher than the configurable maximum EFL threshold 'max EFL_DMA' (see parameter ACMAXEFLDMA), the new call setup on the DMA layer is rejected in any case.



- If the EFL is lower than or equal to the configurable maximum EFL threshold 'max EFL_DMA' (see parameter ACMAXEFLDMA) but higher than ACMINEFLDMA, the new call setup on the DMA layer is only allowed if the BQP criterion is fulfilled in correspondence with the configured 'Admission Control Link Type' as shown in the table below.

Explanation: The 'Admission Control Link Type' (see parameter ACLNKTYP) defines the type of samples to be collected and the way they are used for the estimation of BQP: • acLinkType = 0

UL and DL samples are collected and separately evaluated • acLinkType =1

only UL samples are collected and evaluated • acLinkType =2

UL and DL samples shall be collected, merged and commonly evaluated

If the calculated BQP is higher than the already mentioned configurable BQP threshold BQPmax (parameter ACBQPMAX), the soft-blocking flag is set for the affected DMA layer. 2) DMA Admission Control Signalling The BTS periodically sends the spontaneous Abis O&M message RADIO LINK ADMISSION CONTROL to the BSC. This message contains (for each configured DMA layer / CFHSYID) -> the current BQP values -> the current EFL value -> a flag that indicates whether the DMA layer must be soft-blocked. The sending period for the RADIO LINK ADMISSION CONTROL message (i.e. the time between two consecutive transmissions) is determined by the parameter ACPER. 3) TCH Allocation with DMA Admission Control When the BSC receives a TCH request during a call setup procedure for a particular DMA layer it checks the received soft blocking flag for the affected DMA layer. If the preferred DMA layer is soft-blocked, the TCH request is not served on the preferred DMA layer 1. the BSC attempts to allocate a TCH on a different service layer where speech is allowed. 2. If the BSC either does not find any other service layer supporting speech services or if it finds a suitable layer but no suitable TCH (or meets with soft blocking on this layer as well) it will start/check all the procedures that it also starts in case of hard blocking (i.e. no TCH available), i.e. will it attempt preemption -> directed retry -> queuing & downgrade etc. (see parameters EPRE and EQ in command SET BTS [OPTIONS], ENFORCHO in command SET BSC [BASICS] and DGRSTRGY in command CREATE BTS [BASICS]). If preemption is attempted, the BSC looks into its internal tables where previously all vulnerable (i.e. preemptable) calls have been stored (ordered by priority) and, starting from the lowest priority calls, it preempts one which is compatible with the request - also a call in the DMA layer

can be preempted, but in this case the MAIO of the preempted call is maintained for the preempting one. If a TCH request is queued (no matter whether it is queued due to soft blocking of a DMA layer or due to lack of idle TCHs), the TCH request is served when a TCH resource becomes available - this can be either due to PS call downgrade or due to release of a CS call. If the released TCH belongs to the DMA layer and if the TCH is compatible with the request, the BSC, assuming that the current BQP figures do not change, allocates this TCH and reuses the previously used MAIO for the new call. >

SET BTS [ADM]: 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.

ACBQPFF=0.2, object: BTS [ADM] range: 0.1 .. 1.0, <NULL> step size: 0.1 default: 0.2

Admission Control BQP forgetting factor, this parameter is only relevant if the parameter EAC is set to TRUE and it defines the forgetting factor β for the time exponential filter used for BQP averaging for the feature 'Admission Control'. To avoid the impact of stochastic fluctuation in BQP on the DMA AC decision the BQP values calculated in each AC Period (parameter ACPER, see below) are averaged using an exponential filter with adjustable forgetting factor (β).

mean_BQPn = (1- β) * mean_BQPn-1 + β * BQPn

As this formula shows, the averaging is not done by a gliding averaging window (as done e.g. for Handover and Power Control decisions) but by adding the new sample with the weighting factor β and by simultaneously reducing the weight of the existing average value by the factor (1-β). In other words: the higher the 'forgetting factor' β, the higher the weight of the latest sample and the lower the one of the previous average value.

ACBQPMAX=5, object: BTS [ADM] range: 2 .. 10, <NULL> unit: 1% default: 5

Admission Control BQP max, this parameter is only relevant if the parameter EAC is set to TRUE and it defines the maximum tolerated BQP in a DMA layer for the feature 'DMA Admission Control'. For further details please refer to the feature description above the parameter listing.

ACEFLFF=0.04, object: BTS [ADM] range: 0.02 .. 0.2, <NULL> step size: 0.02 default: 0.04

Admission Control exponential filter forgetting factor, this parameter is only relevant if the parameter EAC is set to TRUE and it defines the forgetting factor for the exponential filter used for fractional load averaging. To get an estimate of the traffic on the DMA layer of the cell the average number of busy channels is calculated using exponential filter with an adjustable forgetting factor (λ)

mean_ZZ_DMAn = (1- λ) * mean_ZZ_DMAn-1 + λ * ZZ_DMAn with (ZZ = FR or HR)

As this formula shows, the averaging is not done by a gliding averaging window (as done e.g. for Handover and Power Control decisions) but by adding the new sample with the weighting factor λ and by simultaneously reducing the weight of the existing average value by the factor (1-λ). In other words: the higher the 'forgetting factor' λ, the higher the weight of the latest sample and the lower the one of the previous average value.

ACFERMAX=5.0, object: BTS [ADM] range: 1.0 .. 10.0, <NULL> unit: 1% default: 5.0

Admission Control FER max, this parameter is only relevant if the parameter EAC is set to TRUE and it defines the maximum FER value which is used for the calculation of the Bad Quality Pro. For further details please refer to the feature description above the parameter listing.

ACLNKTYP= UL_SAMPLES_ONLY, object: BTS [ADM] range: uLAndDLSamplesSeparately, uLSamplesOnly, uLAndDLSamplesCommonly, <NULL> default: uLSamplesOnly

Admission Control link type, this parameter is only relevant if the parameter EAC is set to TRUE and it defines the type of samples to be collected for the BQP determination and the way they are used for the estimation of BQP: • acLinkType = 0 -> ACLNKTYP = uLAndDLSamplesSeparately

UL and DL samples are collected and separately evaluated • acLinkType = 1 -> ACLNKTYP = uLSamplesOnly

only UL samples are collected and evaluated • acLinkType = 2 -> ACLNKTYP = uLAndDLSamplesCommonly

UL and DL samples shall be collected, merged and commonly evaluated

For further details please refer to the feature description above the parameter listing.

ACMAXEFLDMA=PER_50, object: BTS [ADM] range: PER_10, PER_15, PER_20, PER_25, … PER_95, PER_100 default: PER_50

Admission Control maximum EFL on DMA, this parameter is only relevant if the parameter EAC is set to TRUE and it specifies, in percent, the maximum EFL on the DMA layer of the cell.


ACMINEFLDMA=PER_10, object: BTS [ADM] range: PER_5, PER_10, PER_15, … PER_45, PER_50, default: PER_10

Admission Control minimum EFL on DMA, this parameter is only relevant if the parameter EAC is set to TRUE and it specifies, in percent, the minimum EFL on the DMA layer of the cell.


ACPER=SACCH_120, object: BTS [ADM] range: SACCH_020, SACCH_024, SACCH_028, SACCH_032, SACCH_036, SACCH_040 ... SACCH_400 default: SACCH_120

Admission Control period, this parameter is only relevant if the parameter EAC is set to TRUE and it defines the sending period for the RADIO LINK ADMISSION CONTROL message (i.e. the time between two consecutive transmissions) in SACCH multiframes (1 SACCH multiframe = 480ms).


EAC=FALSE, object: BTS [ADM] range: TRUE, FALSE default: FALSE

Enable admission control, this parameter determines whether the feature 'Admission Control' for Dynamic MAIO Allocation (DMA) is enabled in the cell. Note: This parameter can only be set to TRUE in a particular BTS if DMA was enabled in the associated BTS and CBTS objects before. In the DBAEM, this parameter is listed within a SET BTS command behind the SET CBTS command that enables DMA (which itself can only be enabled if all associated objects (CFHSY, TRX, CHAN etc.) have been consistently and conclusively created in the database before. Thus, if DMA and DMA AC are to be enabled, the DBAEM command sequence is the following (for a particular BTS): CREATE CHAN......SET BTS:ENDMA=TRUE...SET CBTS:ENDMA=TRUE...SET BTS:EAC=TRUE

Setting the cell specific attributes for the CCCH: < All attribute values set by this command (except for NY1) 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. MAXRETR=FOUR, object: BTS [CCCH] range: ONE, TWO, FOUR, SEVEN default: FOUR Reference: GSM 04.08 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 Reference: GSM 04.08 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: 1 Reference: GSM 04.08 GSM 05.02 Default value changed in BR8.0!

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. Up to BR7.0 in the BTS the transmission of PAGING REQUESTs via the PCH was strictly priorized against the transmission of IMMEDIATE ASSIGNMENTs via the AGCH, i.e. if there were pagings in the BTS paging queues the would use the available CCCH blocks for paging first. To guarantee a basic throughput of AGCH messages (no matter how high the paging load is), NBLKACGR can be set to a value > 0 to reserve a defined number of CCCHs exclusively for AGCH. These reserved CCCH blocks are never used as PCH but exclusively as AGCH, thus guaranteeing a basic network access even in case of high paging traffic. Starting from BR8.0 an improved CCCH management mechanism was implemented which features a priorization of AGCH messages over PCH messages in the 'shared' CCCH blocks under particular load conditions, i.e. the mechanism checks the filling state of the AGCH queue and the 'age' of the enqueued messages in order to determine



whether a CCCH block should be 'preempted' for AGCH. For further details, please refer to the section 'BTS Overload Handling' in the appendix of this document. For each BCCH/CCCH timeslot the BTS provides 1 AGCH queue with 16 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/CCCH multiframes (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/CCCH multiframes (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, the default value NBLKACGR=1 is a recommended setting to guarantee AGCH traffic also in hours of high PCH traffic. - NBLKACGR must be set as follows a) NBLKACGR ≤ 2 if a BCBCH is created in the cell b) NBLKACGR > 0 if a SCBCH is created in the cell (see CREATE CHAN) - The setting of NBLKACGR refers to each CCCH timeslot created in 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 Reference: GSM 04.08 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 signalling failure criterion which in turn is based on the 'downlink signalling 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 signalling 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 simultaneously 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 Nth 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 Reference: GSM 04.08

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 acollision

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 = 6 tr = 6

NY1=30, object: BTS [CCCH] range: 1-254 default: 30 Reference: GSM 04.08 Default value changed in BR8.0! Recommended value after implementation of BR8.0 CR CR2795: NY1=50, T3105=MS10-10

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. Attention: Due to the implementation of the CR2795, the handling of the timer T3105 was changed in such a way that NY1 should be increased to avoid unnecessary call drop counts for CONNECTION FAILURE cause 'handover access failure'. Please refer to the description of parameter T3105 (see command SET BTS [TIMER]) for further details. - 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 Reference: GSM 04.08 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 .

NAME=BTSM:0/BTS:0, Object path name. INTAVEPR=31- 2-6-12-22, object: BTS [INTERF] fomat: averaging period - threshold boundary 1 - threshold boundary 2 - threshold boundary 3 - threshold boundary 4 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) 6 (threshold boundary 2) 12 (threshold boundary 3) 22 (threshold boundary 4) Reference: 3GPP 45.008

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, object: BTS [INTERF] 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, object: BTS [INTERF] 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 .

NAME=BTSM:0/BTS:0, Object path name. ENANCD=ENABLED, object: BTS [TIMER] range: DISABLED, ENABLED default: ENABLED Default value changed in BR8.0!

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 raised 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=H1-6, object: BTS [TIMER] format: StartTime1-TimerNoCall 1 unit: StartTime1: Time in '1h' TimerNoCall1: Periods of 10min range: StartTime1: H0..H23 TimerNoCall1: 1-432 default: H1-6 Default value changed in BR8.0!

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) The change of the default value was implemented to avoid unnecessary 'sleeping cell' alarms during night time.

NCDP2=H6-1, object: BTS [TIMER] format: StartTime2-TimerNoCall2 unit: StartTime2: Time in '1h' TimerNoCall2: Periods of 10min range: StartTime2: NOTUSED, H0..H23 TimerNoCall2: 1-432 default: H6-1 Default value changed in BR8.0!

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)) The change of the default value was implemented to avoid unnecessary 'sleeping cell' alarms during night time.

NRPGRANT=20, object: BTS [TIMER] range: 1-254 default: 20 reference: GSM 04.18

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, sdcchSAPI3) 10ms (for sacchTCHSAPI0, sacchSDCCH, sacchTCHSAPI3) range: 0..255 default: 29 (sdcchSAPI0) 31 (facchTCHF) 38 (facchTCHH) 90 (sacchTCHSAPI0) 70 (sacchSDCCH) 23 (sdcchSAPI3) 168 (sacchTCHSAPI3) reference: 3GPP 44.006 Default value changed in BR8.0!

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

CHAN ACT ACK (TCH) - EST IND (TCH) < 8

TNC TNCCHAN ACT ACK (TCH) - EST IND (TCH) >= 8

time zone

Sleeping TRX Alarm active

Sleeping TRX Alarm ceased



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 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 else 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 for the BTS side specified by GSM which depends on the control channel types: N200(SDCCH)=23, N200(SACCH)=5, N200(FACCH/FR)=34, N200(FACCH/HR)=29 If T200 expires after the last layer 2 frame repetition the BTS 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. Attention: Deviating from the N200 numbers listed above, special rules apply for layer 2 connection setup and release: For SABM and DISC messages the value of N200 is restricted to 5 (i.e. SABM and DISC are transmitted at the maximum 6 times). For UA frames, there is no repetition based on T200 - UA frames are only sent as a response to received command frames (e.g. SABM or DISC). 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 which has been implemented as default value starting from BR8.0. 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 faking a good call drop rate in the performance measurement counters). Notes: - The SAPI (service access point identifier) is used as address for different radio signalling 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 signalling 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). This means that it can happen that, during an ongoing channel change procedure (handover, TCH assignment etc.) the I-frame that contains channel change message (e.g. HANDOVER COMMAND) is continuously repeated by the BTS due to missing layer-2 acknowledgement on the old channel. This 'T200-context' is terminated a) after successful access to the new channel: by the release of the old channel (RF CHANNEL RELEASE received at the BTS), or b) by the receipt of a new SABM from the MS on return to the old channel after unsuccessful access to the target channel (this SABM initializes the T200 context and flushes the previous timer history). It is up to the operator to ensure that the T200 values are set long enough to avoid a call drop indication during a channel change procedure (e.g. handover).

T3101=HLFSEC-6, object: BTS [TIMER] units: MS100 = 100 ms HLFSEC = 0,5 sec SEC5 = 5s range: 0..255 default: HLFSEC-6 Reference: GSM 04.08

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 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: 1..254 since BR8.0 CR2795: effective range: 1..12 default: MS10-10 Reference: GSM 04.08 Recommended value after implementation of BR8.0 CR CR2795: NY1=50, T3105=MS10-10 Default value changed in BR8.0!

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 (determined by the value of timer T200 for this channel type as implemented in the MS) - is 32 TDMA frames and number of retransmissions (N200) is restricted to 5 (please refer to parameter T200 in command SET BTS [TIMER]). 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 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:

T3105 purpose: period for repetition of PHYSICAL INFORMATION message start: sending of PHYSICAL INFORMATION message stop: receipt of a correctly decoded signalling 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.



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 'bombardment' of the MS with unnecessary FACCH messages (that 'steal' the frames of the normal speech channel). - Attention: With the BR8.0 change request CR2795 an additional modification was implemented with the following features: a) T3105 is restricted to a maximum time of 120ms This means that all settings greater than T3105=MS10-12 are treated as if the value T3105=MS10-12 was entered. b) After the first PHYS INFO retransmission the BTS sets T3105 to the fixed value 50ms and thus ignores the database setting of T3105, i.e. the second and following retransmissions are all scheduled with T3105=50ms. As still the overall time the BTS spends to transmit the PHYS INFO and to receive the SABM should be greater or equal 2 seconds, the abovementioned rule (NY1*T3105 ≥ 2 sec.) must be adapted as follows: T3105 + NY1*50ms ≥ 2 sec. Thus (e.g. with a setting of T3105=MS10-10) the value NY1 should be set at least to 40. The recommendation is therefore to set the values to T3105=MS10-10 and NY1=50. - 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] units: MS100 = 100 ms HLFSEC = 0,5 sec SEC5 = 5s range: 0..255 default: HLFSEC-8 Reference: GSM 04.08 Default value changed in BR8.0!

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. the default value HLFSEC-8.

T3111=HLFSEC-1, object: BTS [TIMER] units: MS100 = 100 ms HLFSEC = 0,5 sec SEC5 = 5s range: 0..255 default: HLFSEC-1 Reference: GSM 04.08

T3111: This timer is used to delay the radio channel deactivation in the BSC after release of the main signalling 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 BSCT11PUB (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).

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

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

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] unit: 1 SACCH multiframe range: 1-254 default: 1 Default value changed in BR8.0!

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.

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 signalling 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: 1 Default value changed in BR8.0!

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 .

NAME=BTSM:0/BTS:0, Object path name. BMONTH= ENABLED(30)-ENABLE(60)-ENABLED(90), object: BTS [OPTIONS] range: ENABLED(1..100), DISABLED default: ENABLE(30) (minor) ENABLE(60) (major) ENABLE(90) (critical)

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), object: BTS [OPTIONS] range: ENABLED(1..100), DISABLED default: ENABLE(30) (minor) ENABLE(60) (major) ENABLE(90) (critical)

Um radio signalling channels monitoring thresholds, determines the state and the threshold values for the minor, major and critical QOS alarms for the radio signalling 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, object: BTS [OPTIONS] range: TRUE, FALSE default: FALSE Reference: GSM 04.08 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 object: BTS [OPTIONS] range: ALLOWED, NOTALLOWED default: NOTALLOWED Reference: GSM 04.08

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 signalling 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, object: BTS [OPTIONS] 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: - Interworking of 'Service Dependent Channel Allocation' and Direct TCH Assignment If Direct TCH Assignment is enabled the SLL associated to 'signalling' is used for allocation (see command SET BTS [SERVICE] for details). This SLL should be defined by the operator in such a way that the TRXs with less SDCCH and more TCHs are listed at the top. For call setups with direct TCH assignment, the TCHs are first searched in the SLL defined for signalling (see SLLPRM) and, if the allocated channel does not perfectly match to service type requested in the ASSIGNMENT REQUEST message, the channel is changed after receipt of this message (as it is done during normal change from SDCCH to TCH when direct assignment is not applied.) - There is no impact on directed retry (see parameter ENFORCHO 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 and EHRACTAMR in command CREATE BTS [BASICS] in command) does not work when Direct TCH Assignment 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, object: BTS [OPTIONS] range: TRUE, FALSE default: FALSE Reference: GSM 04.08 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. 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 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

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



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 real 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 HOAVLEV, HOAVQUAL and ALEVFULHO (see SET HAND [BASICS]). If the MS indicates 'DTX used' in a specific MEASUREMENT REPORT, the BTS has to consider the SUB values of 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:

DTXDLHR=FALSE, object: BTS [OPTIONS] range: TRUE, FALSE default: FALSE Reference: GSM 04.08 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, object: BTS [OPTIONS] range: MAYFSHNH SHLFSHNH SHNFSHNH MAYFMAYH SHLFSHLH SHNFSHLH default: SHLFSHNH Reference: GSM 04.08 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.

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>



EARCLM=TRUE, object: BTS [OPTIONS] range: TRUE, FALSE default: TRUE reference: GSM 04.08 Default value changed in BR8.0!

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 independent 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 has been received and answered by another CLASSMARK CHANGE message before.

EC=FALSE, object: BTS [OPTIONS] range: TRUE, FALSE default: FALSE Reference: GSM 04.08 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, object: BTS [OPTIONS] range: ENABLED, 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) transmitted in the ASS REQ and HO REQ message. The 'Priority' IE contains the following entries: - The Preemption 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 Preemption 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: If the PCI is set to 'preemption allowed' for the incoming CS TCH request, and if the BSC finds an existing call with lower priority level for which the PVI is set to 'may be preempted', the BSC will start the procedure 'forced handover due to preemption' for the ongoing call to provide the resource to the new incoming call. 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) (WPS) queuing 4) downgrade of multislot calls (GPRS/HSCSD) may be periodically attempted in parallel and queued calls can be served when down grade is successfully completed. Please refer to the parameters EQ (for (WPS) queuing) in this command, ENFORCHO (for directed retry) in command SET BSC [BASICS] and to parameter DGRSTRGY (for multislot call downgrade) in command SET BTS [BASICS]. - 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 two 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, object: BTS [OPTIONS] range: ENABLED, DISABLED default: DISABLED

Enable (WPS) queuing, this parameter originally enable/disable the feature 'Queuing' for TCH channels. Starting from BR8.0, it enables the enhanced queuing feature called 'Wireless Priority Services' (WPS) which was required especially for the U.S. market. The (WPS) 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 by preemption (see parameter, via directed retry (see parameter ENFORCHO in SET BSC [BASICS]) are put in two different cell-specific queues based on its priority. If a TCH request is enqueued, the MSC is informed about this process by the QUEUING INDICATION message. As a general rule, incoming Inter-BSC directed retries are not queued. 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. In GSM different priorities and access types are supported via the 'Priority' IE which is (optionally) transmitted in the ASS REQ and HO REQ message. The 'Priority' IE contains the following entries: - The Preemption 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 Preemption 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 (1..14, 1 the highest, 14 the lowest priority). 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 be queued: If the QAI is set to 'queuing allowed' for the incoming CS TCH request, and if the BSC has previously tried all other measures to free currently used TCH resources in the cell (see first 'Note' below), the TCH request can be queued. Queuing policy Originally (i.e. in releases up to BR7.0) only one queue was managed in the BSC per cell. The sequence of queued TCH requests within this queue was determined by - the priority of the received TCH request - for TCH requests of the same priority the point of tine of receipt. With the WPS queuing mechanism, which was introduced starting from BR8.0, two different queues are incoming TCH requests: one so-called 'WPS queue' for TCH requests from high priority subscribers and one 'Public queue' for TCH requests from ordinary subscribers.

channel?

Queue

Happy

No –Public

No –NS/EP

Arrivals

Queue

Yes

channel?

publicqueue

Happy

No –Public

No –WPS

Arrivals

WPSqueue

Yes

channel?

Queue

Happy

No –Public

No –NS/EP

Arrivals

Queue

Yes

channel?

publicqueue

Served

no:public

no:WPS

Arrival

WPSqueue

yes

channel?

Queue

Happy

No –Public

No –NS/EP

Arrivals

Queue

Yes

channel?

publicqueue

Happy

No –Public

No –WPS

Arrivals

WPSqueue

Yes

channel?

Queue

Happy

No –Public

No –NS/EP

Arrivals

Queue

Yes

channel?

publicqueue

Served

no:public

no:WPS

Arrival

WPSqueue

yes



Which priority levels are to be placed in which queue, is determined by the parameter LWWPSPRI, which defines the lowest priority level (PL) to be placed in the WPS queue. In other words: all incoming TCH requests with PL >= LWWPSPRI are enqueued in the 'WPS queue', all others are enqueued in the 'Public queue'. For both queues the length and characteristics are defined by separate parameters: WPS queue: - the queue length is defined by parameter QLWPS (see below) - the queuing time for TCH requests due to TCH assignment is defined by parameter BSCT11WPS and - the queuing time for TCH requests due to incoming MSC-controlled handover is defined by parameter BSCTQHOWPS (see command SET BSC [TIMER]). Public queue: - the queue length is defined by parameter QLWPUB (see below) - the queuing time for TCH requests due to TCH assignment is defined by parameter BSCT11PUB and - the queuing time for TCH requests due to incoming MSC-controlled handover is defined by parameter BSCTQHOPUB (see command SET BSC [TIMER]). Each queue consists of a set of queue places all having the same characteristics. Technically each cell has 14 queues, one for each priority. These 14 queues are separated into two different queue groups as defined by LWWPSPRI according to the priority levels, i.e. the queues with the higher priority levels make up the WPS queue (group), the ones with the lower priority levels make up the Public queue (group).

TCH requests are put into the WPS queue or the Public queue depending on their PL and are placed into the relevant queue using a first-in/first-out queuing discipline for each priority level. If one queue (i.e. WPS or public) is full (i.e. the number of queued TCH requests has reached the threshold defined by the parameters QLWPS and QLPUB) and an incoming TCH request 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 remove the (youngest) lowest priority one from the respective queue (resulting in a rejection of the TCH request with an ASSIGNMENT FAILURE or HANDOVER FAILURE with cause 'no radio 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. When a previously 'busy' TCH becomes 'idle' again (i.e. when the previously active call on one TCH resource is released) while TCH requests are queued, the enqueued TCH requests are served according to the following mechanism: Starting from the beginning, the first call to be served is a TCH request in the WPS queue (if any is available), then, in order to



realize e.g. a requested sharing between WPS and Public calls of 25% (reflected by the parameter setting WPSPREF=4-1, parameter description see below) the subsequent 3 requests will be taken from the Public queue, when present. If they are not present or the queue becomes empty again it will be served the WPS queue or if also this queue is empty the resource will be available for the other needs. Queued TCH requests can be discarded from a 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' is sent to the MSC.) c) if the queuing time expires for the queue TCH request As mentioned above, the queuing times are defined by separate database parameters for the two different queues (BSCT11WPS etc.). If BSCT11WPS or BSCT11PUB expires, the BSC sends a CLEAR REQUEST message with cause 'no radio resource available' to the MSC and the requesting connection is released. If BSCTQHOWPS or BSCTQHOPUB expires in case of incoming MSC-controlled HO, the TCH request is rejected with a HANDOVER FAILURE message using the same cause 'no radio resource available'. 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) (WPS) queuing 4) downgrade of multislot calls (GPRS/HSCSD) may be periodically attempted in parallel and queued calls can be served when down grade is successfully completed. Please refer to the parameters EPRE (for preemption) in this command, ENFORCHO (for directed retry) in command SET BSC [BASICS] and to parameter DGRSTRGY (for multislot call downgrade) in command SET BTS [BASICS]. - Interworking of the features 'Downgrade strategy' and (WPS) queuing When a TCH request is queued, the BSC tries, when possible, to serve the queued TCH requests by a multislot call downgrade procedure (e.g. (E)GPRS downgrade: Every call is put in the queue with its relevant data (channel request type, WPS/Public call info, Service List, running procedure, …). After the call is queued, the resource management process periodically starts the downgrade procedure (if correspondingly enabled via parameter DGRSTRGY) on HSCSD data calls and/or (E)GPRS data calls (if any) in order to get new resources for TCH allocation. The call that triggers the downgrade procedure is marked as 'downgrade requested' in order to wait for the resources that will be available after successful completion of the downgrade procedure. If during the ongoing downgrade procedure other TCHs become 'idle' again, these resources cannot be assigned to the call marked as 'downgrade requested'. The call marked as 'downgrade requested' must in any case wait for the resources achieved by the downgrade procedure. The downgrade procedure is requested for the multislot calls established on the shared layers with service layer association matching to the service type of the enqueued call, starting from the preferred layer. On the other hand, in case of Abis congestion the

multislot downgrade procedure will be requested on all layers of this cell associated to the multislot service layer list and in the extreme case also on other cells of the same BTSM. Other scenarios that allow the serving of a queued TCH request are release requests of previously 'busy' TCHs or the 'return to service' of previously 'disabled' TCHs. As soon as a TCH resource returns to service or becomes 'idle', the TCH allocation process attempts to serve the enqueued TCH requests with the highest priority. Of course, the new resource and the queued request must be compatible in terms of supported layer, requested band and so on. - By setting the parameter QLWPS=0, the BSC queuing behaviour is exactly the same as in releases < BR8.0. - 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, object: BTS [OPTIONS] range: BBHOP, SYNHOP default: BBHOP

Hopping Mode, this parameter indicates whether baseband hopping or synthesizer hopping is to be used in this cell. Baseband 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, object: BTS [OPTIONS] range: TRUE, FALSE default: TRUE Reference: GSM 04.08

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.

LWWPSPRI=<NULL>, object: BTS [OPTIONS] range: 1.. 10, <NULL> default: <NULL>

Lowest WPS Priority, this parameter is only relevant if the feature 'Wireless Priority Service (WPS)' is applied, which is a special enhancement of the feature 'queuing' required by the U.S. market (please see parameter EQ (above) for further details). It specifies the lowest Priority level to be considered in the WPS queue. Further parameters related to the WPS feature are BSCT11PUB, BSCT11WPS, BSCTQHOPUB, BSCTQHOWPS (see command SET BSC [BASICS]) and QLWPS, QLPUB and WPSPREF (see below).

NALLWACC=ALLALLOWED, object: BTS [OPTIONS] range: NA0..NA9, NA11..NA15, default: ALLALLOWED Reference: GSM 04.08 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, object: BTS [OPTIONS] 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 Queue length, removed in BR8.0, replaced by QLPUB and QLWPS. QLPUB=50, object: BTS [OPTIONS] range: 1.. 100, <NULL> default: 50

Length of public queue, this parameter is only relevant if the feature 'Wireless Priority Service (WPS)' is applied, which is a special enhancement of the feature 'queuing' required by the U.S. market (parameter EQ, see above). It specifies the length of the 'Public' queue for the Wireless Priority Services (WPS) feature. Further parameters related to the WPS feature are BSCT11PUB, BSCT11WPS, BSCTQHOPUB, BSCTQHOWPS (see command SET BSC [BASICS]) and QLWPS and WPSPREF (see below).

QLWPS=0, object: BTS [OPTIONS] range: 1.. 100, <NULL> default: 0 (=WPS queuing disabled)

Length of WPS queue, this parameter specifies the length of the ''WPS' queue for the Wireless Priority Services (WPS) feature. Please refer also to parameter QLPUB (see above). By setting the parameter to its default value QLWPS=0, the BSC queuing behaviour is exactly the same as in releases < BR8.0.

T3212=6, object: BTS [OPTIONS] unit: 1 decihour (6 min) range: 0..255 0 means 'infinite timeout', i.e. periodic loc. updating is not used in the cell.. default: 10 = 60 min. Reference: GSM 04.08

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

WPSPREF=4-1, object: BTS [OPTIONS] format: <councerCycle>- <numberWPS> range: counterCycle: 2 .. 10 numberWPS: 1.. 3 default: 4-1

WPS preference, this parameter is only relevant if the feature 'Wireless Priority Service (WPS)' is applied, which is a special enhancement of the feature 'queuing' required by the U.S. market (parameter EQ, see above). The value of this parameter consists of two parts: 1. The first part 'counter cycle' defines the complete cycling period in terms of: number of calls served and 2. the second part 'number WPS' defines, for each complete cycle period, how many WPS requests should be consecutively served. Example: The default setting WPSPREF=4-1 has the following effect: When a previously busy TCH becomes 'idle' and TCH requests are enqueued in both the WPS queue and in the Public queue, the enqueued WPS calls are served by every 4th TCH which becomes 'idle'. When the 'serving' of a TCH request from the WPS call is scheduled, only 1 call is served at a time. In other words: the setting WPSPREF=4-1 will have the effect that 1 out 4 served TCH requests is a WPS call. Further parameters related to the WPS feature are BSCT11PUB, BSCT11WPS, BSCTQHOPUB, BSCTQHOWPS (see command SET BSC [BASICS]), QLPUB and QLWPS (see above).

Note: Some parameters of the command SET BTS [OPTIONS] appear at a later position when generated by the DBAEM. The command reappears after the CREATE CHAN commands with the 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).

Defining the cell specific service layer lists for the feature 'Service dependent Channel Allocation' (SDCA) via 'Multi Service Layer Support' (MSLS): < This part of the BTS object is associated to the feature 'Service

Dependent Channel Allocation' (SDCA) via 'Multi Service Layer Support' (MSLS) and defines Service Layer Lists (SLL) for each service type (AMR and non-AMR speech, CS data, (E)GPRS etc.). Feature Background 'Service Dependent Channel Allocation' The idea of the feature 'Service Dependent Channel Allocation' (SDCA) via 'Multi Service Layer Support' (MSLS) was introduced in BR8.0 to allow a sophisticated TCH allocation strategy which selects, for different requested service types, a TCH from the most suitable TRX, depending on the (expected) radio interface quality of this TRX (which in turn depends of the frequency planning strategy applied by the operator) and the robustness of the affected service against radio quality degradations. In this context the term 'layer' defines a group of one or more TRXs with a common (expected) radio interface quality, whose association to a particular layer number is defined by the parameter LAYERID (see command CREATE TRX). When defined in the TRX object, the layers do not yet have any service association but just a 'layer number', which is later on used as a kind of 'TCH pool address' when the associated TRXs are checked for available TCH resources during the TCH allocation process.

Thus the defined layers can be regarded as virtual TCH pools which are accessed and checked by the BSC in a certain 'preferred' sequence when a particular service type is requested. Service Layer List (SLL) Which layer is accessed by the BSC's channel allocation process and in which sequence the BSC searches for channel resources, depends on the requested service type, as for each service type a 'preferred sequence', which is also called 'Service Layer List' (SLL) is defined by an own parameter or parameter pair. In this SLL, the available service layers are sorted in descending order or priority resp. preference. If the SLL is defined as a parameter pair, a) the first parameter is always named <service name>LLPRM (PRM = primary area)

Cell

Radio quality

TRX:1

Layers TRXs

TRX:2

TRX:3

TRX:4

TRX:5

LY_00

LY_01

LY_02

LY_02

and identifies - the one and only SLL for standard cells or - the SLL of the complete are of a concentric cell or - the SLL for the far area (double timeslots) of an extended cell b) the second parameter is always named <service name>LLCOM (COM = complementary area) and identifies - the SLL of the inner are of a concentric cell or - the SLL of the near area (single timeslots) of an extended cell On the whole, 9 different service types are defined - their SLLs are defined by the parameters as listed in the table below.

Service Type parameters for SLL of primary area

parameters for SLL of complementary area

Signalling SLLPRM --- CS speech (E)FR-HR CRTSWSPELLPRM CRTSWSPELLCOM CS speech AMR FR AMRFRLLPRM AMRFRLLCOM CS speech AMR HR AMRHRLLPRM AMRHRLLCOM CS data CRTSWDLLPRM CRTSWDLLCOM HSCSD HSCSDLLPRM HSCSDLLCOM GPRS GLLPRM GLLCOM EGPRS ELLPRM ELLCOM ASCI ASCIPRM ---

Please note that GPRS and EGPRS are not supported in the inner area of a concentric cell and HSCSD is not supported in the far area of an extended cell. Therefore GLLCOM and ELLCOM cannot be defined in a concentric cell (CONCELL=TRUE, see CREATE BTS [BASICS]) and HSCSDPRM cannot be defined in an extended cell (CELLTYPE=EXTCELL, see CREATE BTS [BASICS]). Attention: The value <NULL> for a particular layer list parameter (<service name>LLPRM) means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell! If the service shall be supported in the cell as a default configuration without a sophisticated configuration of the feature MSLS, it is at least necessary to assign to each TRX of the cell the LAYERID=LL_00 and to define this layer as the only entry in the SLL of each configured service (i.e. SLLPRM=LY_00, CRTSWSPELLPRM=LY_00, AMRFRLLPRM=LY_00, AMRHRLLPRM=LY_00, GLLPRM=LY_00 etc.). Channel allocation process with SDCA/MSLS When the BSC receives a channel request for a particular service type, it first checks if for the requested service an SLL is defined. If yes, it looks inside the SLL defined for the requested service type and starts to search for an available resource in the service layer that has the highest priority within the SLL. If a resource can be found in this preferred layer, the channel is allocated. If no channel can be found on the TRX(s) belonging to the preferred layer of the SLL, the BSC searches the next lower layer for resources and so on. Example: BSC receives TCH request for service type EFR. SLL definition The SLL for service type E(FR), HR is defined as LY_01, LY_00, LY_02 by the parameter CRTSWSPELLPRM=LY_01&LY00&LY02, while the association of the layers to the TRXs is defined as LY_00 -> TRX:0, LY_01 -> TRX:1&TRX:2, LY_02 -> TRX:3. by the commands CREATE TRX:NAME=TRX:0,...LAYERID=LL_00;



CREATE TRX:NAME=TRX:1,...LAYERID=LL_01; CREATE TRX:NAME=TRX:2,...LAYERID=LL_01; CREATE TRX:NAME=TRX:3,...LAYERID=LL_02; The diagram below illustrates this configuration.

Resource allocation When the TCH request for service type EFR speech is received, the system searches for free resources in the layer LY_01 (TRX1 and TRX2) first. If no idle TCH resources can be found in layer LY_01, the BSC resource management task checks the next layer of the SLL, i.e. LY_00. If also in LY_00 (TRX:0) no free resources are available, the BSC resource management task checks the last layer of the valid SLL, i.e. LY_02. SDCA/MSLS resource management in case of TCH congestion If no idle channel resources can be found in any of the service layers defined for the requested service type, the BSC starts the known procedures to satisfy TCH requests in case of TCH congestion (if enabled): 1. preemption (see parameter EPRE in command SET BTS [OPTIONS]) 2. directed retry (see parameter ENFORCHO in command SET BSC [BASICS]) 3. queuing (see parameter EQ in command SET BTS [OPTIONS]) and, in parallel, also 4. multislot call downgrade (see parameter DGRSTRGY in command SET BTS [BASICS]). Intra-cell handover due to 'preferred service layer' When a TCH was allocated on a service layer different from the preferred one, the BSC resource management task periodically checks the preferred layer for idle resources and, if a TCH resource is found, transfers the call by an intra-cell handover to a TRX that belongs to the layer with higher preference. This mechanism is only available for CS services. Moreover, for HSCSD multislot calls that did not receive the requested number of TCH resources, a periodic task tries to move the CS call to a better Layer with a sufficient number of free channels as soon as possible to satisfy the multislot bandwidth that was

Layers TRXs

Cell

TRX:1

TRX:2

TRX:3

TRX:4

TRX:5

LY_00

LY_01

LY_02

LY_03

TCH request (requested service

type = (E)FR)

SLL for non-AMR speech

SLL (E)FR, HR defined by SET BTS [SERVICE]:CRTSWSPELLPRM=LY 01&LY00&LY02

2. layer

1. layer

3. layer



originally requested by the MS. Please note that these intracell handovers are only triggered by the BSC if the parameter ENFOIAHO is set to TRUE and MNTBMASK BIT12 is set (both parameters see command SET BSC [BASICS])!

Interworking of SDCA/MSLS with 'Cell Load Dependent activation of Half Rate' When for an incoming TCH request both (E)FR and HR (or/and AMR-FR and AMR-HR) are indicated as allowed, the MS's speech version preference (indicated in the ASSIGNMENT REQUEST or HANDOVER REQUEST message) is first of all overwritten by the BSC's speech version preference, which depends on - the activation state of the feature 'Cell Load Dependent Activation of Half Rate' (CLDAHR, see parameters EHRACT and EHRACTAMR in command CREATE BTS[BASICS] is enabled) and - the current TCH load in the cell. When the decision for FR or HR has been made, the corresponding SLL for FR is searched first. If an MS supports all speech CODECs and rates (AMR, non-AMR, FR and HR) and FR is preferred (e.g. due to EHRACT and current TCH load) the BSC searches in more than one SLL in the following order: 1. SLL for CS AMR FR 2. SLL for CS AMR HR 3. SLL for CS (E)FR/HR Within each SLL, every layer is checked for resources before the search in the next SLL is started.

Interworking of MSLS with Cell Load Dependent Activation of HR for AMR and non-AMR Assuming that - the BSC receives a TCH request with all speech versions supported and AMR indicated as 'preferred' (AMR FR, AMR HR, E(FR), HR) and - the BTS has SLLs for both AMR and non-AMR speech services and - CLDAHR is activated for both AMR and non-AMR the following sequence of events will take place during the BSC resource allocation process: 1) As AMR is indicated as preferred, the BSC will calculate the load on all TCH resources that belong to TRX that included in the SLLs supporting AMR services and compare it against the threshold HRACTAMRT1 or -T2 (see CREATE BTS [BASICS]) depending on the affected area. 2) Depending on the load/threshold comparison result the BSC looks for a suitable resource (FR/HR) on the AMR layer. 3) When no resource can be found on the AMR layer, the BSC will compare the calculated the load on all TCH resources (that belong to TRX that included in the SLLs supporting non-AMR services) against the threshold HRACTT1 or -T2 (see CREATE BTS [BASICS]) depending on the affected area. 4) Depending on the load/threshold comparison result the BSC looks for a suitable resource (FR/HR) on the non-AMR layer.

Interworking of SDCA/MSLS with traffic load calculation The percentage calculation done for the features Enhanced Pairing and Compression/Decompression Handover (see parameters EPAT1, HRACTT1, HRACTAMRT1, FRACTTH1 and FRACTAMRTH1 in command CREATE BTS [BASICS]) is done referring only to the TRXs included into the SLLs for relevant to CS speech AMR service and CS speech services, separately for every subarea (primary / complementary). The traffic load calculation for Traffic Handover (see parameter TRFHOE in command SET HAND [BASICS]) is still performed for the whole cell. Due to the fact that the



BTS cannot apply the Traffic handover only to a particular service the load is calculated on all the resources available for CS service (resources reserved for ASCI and (E)GPRS are excluded).

SLL search in case of cells with two separate areas As described above, when a cell is configured as concentric cell or extended cell, two separate SLLs can be defined for each area, i.e. in a concentric cell one for the inner and one for the complete are and in an extended cell one for the near and one for the far area. The main area's SLL is called 'primary' SLL, the other is called 'complementary' SLL. Note: TRXs belonging to different areas (of a concentric or an extended cell) can belong to the same layer (LAYERID), but for each area an own separate SLL must be defined. When a channel is requested in a cell, for every service (except for (E)GPRS services), the 'complementary' SLL is checked first, if the MS is suitably positioned within the TRX's coverage area and the radio conditions are correspondingly good. Only when no resource can be found in the complementary SLL, the primary SLL is searched and the channel request is served if a resource is available. A downgrade of an incoming multislot call is only performed if no resource can be found in any of the relevant SLLs. Interworking of service layers and Idle Channel Supervision If the feature 'Idle Channel Supervision' (see parameter INTCLASS in command SET BTS [INTERF]) is enabled, the resources within each service layer are sorted according to their interference class. Within a service layer, the resource with the best interference class is always allocated first. Channel allocation for signalling channels (SDCCH, TCHSD) in the service layers All the TRXs with channels of type SDCCH, TCHSD in SDCCH_POOL, TCHSD in TCHSD_POOL have to be included in a Layer associated at least to the Signalling SLL, otherwise these channels will never be used as signaling channel (TCHSDs in TCHSDPOOL (see parameter CHPOOLTYP in command CREATE CHAN) can be used also as traffic channels). If several TCH/SDs are configured in different service layers, the BSC will first allocate a TCH from a less priorized service layer, before its starts to allocate a TCH/SD in the TCHSDPOOL located on the high-priorized service layer. Service layers for EGPRS Generally, for all service types, all TRXs associated to a layer of the SLL are available for resource allocation. However, there is one exception: for EGPRS only those TRXs within the layers of the SLL can be used for EGPRS resource allocation, that have the parameter TRXMD (see command CREATE TRX) set to the value EDGE. Interworking of SDCA/MSLS and Direct TCH Assignment If Direct TCH Assignment is enabled (see parameter DIRTCHASS in command SET BTS [OPTIONS]), the SLL associated to 'signalling' is used for allocation. This SLL should be defined by the operator in such a way that the TRXs with less SDCCH and more TCHs are listed at the top. For call setups with direct TCH assignment, the TCHs are first (i.e. after receipt of the CHANNEL REQUEST message) searched in the SLL defined for signalling (see SLLPRM) and, if the allocated channel does not perfectly match to service type requested in the ASSIGNMENT REQUEST message, the channel is changed after receipt of this message (in a similar way as it is done during normal change from SDCCH to TCH when direct assignment is not applied.) Reservation of (E)GPRS resources in service layers For the management of reserved packet channels in service layers



that are shared between CS and packet services (this happens e.g. when the same service layer is simultaneously included in both the SLL of speech services and GPRS services) four parameters (see command CREATE PTPPKF) are used for the reservation: - GMANPRESPRM (old BR7.0 GMANPRES) is the number of reserved channels for GPRS service in the primary area - GMANPRESCOM is the number of reserved channels for GPRS service in the complementary area (significant only if the cell is an extended cell) - EMANPRESPRM is the number of reserved channels for EGPRS service in the primary area - EMANPRESCOM is the number of reserved channels for EGPRS service in the complementary area (significant only if the cell is an extended cell). Two cell configuration cases must be distinguished: Standard and Concentric Cells For standard and concentric cells (see parameters CELLTYPE and CONCELL in command CREATE BTS [BASICS]), the channels are reserved in the first service layer that is defined both in the SLLs for GPRS/EDGE and the SLLs for CS services in the Primary/Complementary area. Example: Standard or Concentric Cell with ELLPRM=LY00,GLLPRM=LY01&LY00,CRTSWSPELLPRM=LY02&LY01&LY00GMANPRESPRM=2EMANPRESPRM=2 -> 2 channels are reserved for GPRS on LY_01, as this is the first layer shared between GPRS and speech services -> 2 channels are reserved for EGPRS on LY_00, as this is the first layer shared between GPRS and speech services

Extended Cells The extended cell (CELLTYPE=EXTCELL, see command CREATE BTS [BASICS]) is an exception since the PS channels can be always seized on SINGLE TIMESLOTS (both for calls in the near or far area). For this reason, due to the fact that single timeslots in the primary area (far area) cannot be used for CS, PS channels are reserved on the resources that can be used by CS services. Thus, a) the 'shared' layer to apply GMANPRESPRM(EMANPRESPRM) is the one that belongs to both - the SLL for CS in the complementary area (e.g. CTRSWSPELLCOM) and to - the SLL for PS services in the primary area, i.e. GLLPRM(ELLPRM) and b) the 'shared' layer to apply GMANPRESCOM(EMANPRESCOM) is the one that belongs to both - the SLL for CS in the complementary area (e.g. CTRSWSPELLCOM) and to - the SLL for PS services in the complementary area, i.e. GLLCOM(ELLCOM). Example: Extended Cell configured with

3 TRX's. TRX0 is preferred Layer for signaling, and has double timeslots for CS in the 'far area'. TRX1 and TRX2 have single timeslots for CS in 'near area'. TRX-0: MAINBCCH + SDCCH + TCHSD + TCHFULL,

EXTMODE=TRUE(all ts -> far area), TRXMD=GSM, LAYERID=LY_00

TRX-1: TCHFULL(all ts), EXTMODE=FALSE (all ts -> near area), TRXMD=EDGE, LAYERID=LY_01

TRX-2: TCHFULL (all ts), EXTMODE=FALSE (all ts -> near area), TRXMD=GSM, LAYERID=LY_02

Service Layer definitions (BTS object):SLLPRM=LY_00CRTSWSPELLPRM=LY_00,CRTSWSPELLCOM=LY_02&LY_01&LY_00GLLPRM=LY_02&LY_01,GLLCOM=LY_02&LY_01ELLPRM=LY_01,ELLCOM=LY_01

Reserved packet channel definitions (PTPPKF object):GMANPRESPRM=2,GMANPRESCOM=2EMANPRESPRM=2,EMANPRESCOM=1

With the configuration shown above, the 'shared' layer for GPRS is TRX-2 (LY_02) in both areas; on the whole, 4 channels are reserved (GMANPRESPRM+GMANPRESCOM=2+2=4). For EDGE, the shared layer is the one with TRX-1 (LY_01) in both in both areas; on the whole, 3 channels are reserved (EMANPRESPRM+EMANPRESCOM=2+1=3). This is a very particular database setting, due to the fact that the shared layer is the same in both areas, so it is not guaranteed that 2 channels are reserved for the primary and 1 for the complementary area, but the channels will be seized as dedicated channels by the first (4 GPRS) requests (no matter which is the involved area).

Interworking of SDCA/MSLS and Dynamic MAIO Allocation (DMA) The feature Dynamic MAIO Allocation (DMA, see command CREATE CBTS) is only permitted on service layers that have been configured for CS speech services only. In other words, the DMA service layer may only be included in the SLLs defined for CS speech AMR and non-AMR services. If the DMA service layer is included in the SLL of any other service type (including signalling), the enabling of DMA is rejected by the DBAEM and the BSC command interpreter. >

SET BTS [SERVICE]: NAME=BTSM:0/BTS:0, Object path name. AMRFRLLCOM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

AMR Full Rate layer list complementary, this parameter defines the service layer list (SLL) associated to speech call applying AMR FR codec in the inner/near area of dual area cell (extended, concentric, single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

AMRFRLLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

AMR Full Rate layer list primary, this parameter defines the service layer list (SLL) associated to speech call applying AMR FR codec in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

AMRHRLLCOM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

AMR Half Rate layer list complementary, this parameter defines the service layer list (SLL) associated to speech call applying AMR HR codec in the inner/near area of dual area cell (extended, concentric, single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

AMRHRLLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

AMR Half Rate layer list primary, this parameter defines the service layer list (SLL) associated to speech call applying AMR HR codec in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

ASCILLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

ASCI layer list primary, this parameter defines the service layer list (SLL) associated to ASCI VBS/VGCS services in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

CRTSWDLLCOM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

Circuit switched data layer list complementary, this parameter defines the service layer list (SLL) associated to circuit switched single slot data call in the inner/near area of dual area cell (extended, concentric single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

CRTSWDLLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

Circuit switched data layer list primary, this parameter defines list of TRX layers assigned to Circuit switched single slot data call in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

CRTSWSPELLCOM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

Circuit switched speech layer list complementary, this parameter defines the service layer list (SLL) associated to circuit switched speech call applying EFR-FR-HR codec in the inner/near area of dual area cell (extended, concentric single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

CRTSWSPELLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

Circuit switched speech layer list primary, this parameter defines list of TRX layers assigned to circuit switched speech call applying EFR-FR-HR codec in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

ELLCOM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

EDGE layer list complementary, this parameter defines the service layer list (SLL) associated to EDGE service in the inner/near area of dual area cell (extended, concentric single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object). Note: Generally for all service types all TRXs associated to a layer of the SLL are available for resource allocation. However, there is one exception: for EGPRS only those TRXs within the layers of the SLL can be used for EGPRS resource allocation, that have the parameter TRXMD (see command CREATE TRX) set to the value EDGE.

ELLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

EDGE layer list primary, this parameter defines list of TRX layers assigned to EDGE service in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object). Note: Generally for all service types all TRXs associated to a layer of the SLL are available for resource allocation. However, there is one exception: for EGPRS only those TRXs within the layers of the SLL can be used for EGPRS resource allocation, that have the parameter TRXMD (see command CREATE TRX) set to the value EDGE.

GLLCOM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

GPRS layer list complementary, this parameter defines the service layer list (SLL) associated to GPRS service in the inner/near area of dual area cell (extended, concentric single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

GLLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

GPRS layer list primary, this parameter defines list of TRX layers assigned to GPRS service in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

HSCSDLLCOM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

HSCSD layer list complementary, this parameter defines the service layer list (SLL) associated to HSCSD service in the inner/near area of dual area cell (extended, concentric single/dual band), or in the complementary band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

HSCSDLLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

HSCSD layer list primary, this parameter defines list of TRX layers assigned to HSCSD service in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).

SLLPRM= LL_00, object: BTS [SERVICE] range: 1..12 items max list, and for each item: LL_00 .. LL_11 default: <NULL>

Signaling layer list primary, this parameter defines list of TRX layers assigned to services that require only a signalling channel in a single band standard cell, or in the complete/far area of a dual area cell (extended, concentric single/dual band), or in the BCCH band of a dual band standard cell. The service layers of the SLL are defined in a decreasing priority order, i.e. the entered sequence of layer-IDs determines the layer preference for the resource allocation for this service. Attention: The value <NULL> means that for the associated service no SLL is defined. If this is the case, the service is regarded as 'not supported' in the cell. If the service shall be supported, at least LY_00 must be set (in correspondence to the default setting of LAYERID=LY_00 in the TRX object).



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) Reference: 3GPP 45.008 GSM 04.08 GSM 05.05 GSM 12.20

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) Reference: 3GPP 45.008 GSM 04.08 GSM 05.05 GSM 12.20

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 Reference: 3GPP 45.008

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 PCRLFTH (see below).

LOWTLEVD=25, object: PWRC unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm default: 25 Reference: GSM 05.08

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 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm default: 25 Reference: GSM 05.08

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 Reference: GSM 05.08

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 value for AMR calls, it is recommended to use a minimum RXQUAL 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% 7 = greater than 12,8% default: 4 Reference: GSM 05.08

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 unit: 1 SACCH multiframe =480ms (averaging period) range: 1-31 (averaging period) 1-3 (DTX weighting factor) default: 4 (averaging period) 2 (DTX weighting factor) Reference: 3GPP 45.008

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

lengthmax_av_win_size

1 2111 00012 00weight



PAVRQUAL=4-2, object: PWRC format: averaging period- DTX weighting factor unit: 1 SACCH multiframe =480ms (averaging period) range: 1-31 (averaging period) 1-3 (DTX weighting factor) default: 4 (averaging period) 2 (DTX weighting factor) Reference: 3GPP 45.008

Power control averaging parameters quality, 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 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. 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). For further information about the management of the DTX weigthing factor please refer to the explanations provided for the parameter PAVRLEV. Notes: - In the SDCCH phase there are no TCH speech frames. For 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 = 2dBrange: 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 Reference: 3GPP 45.008

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 Reference: 3GPP 45.008

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 unit: 2 SACCH multiframes range: 1-31 default: 2 Reference: 3GPP 45.008

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 Reference: 3GPP 45.008

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 Reference: 3GPP 45.008

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 Reference: GSM 04.08 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 'S-counter') 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 radio 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 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 sends 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 (BS Power Control). If the 'missing SACCH' counter (S-counter, initial value defined by RDLNKTBS) is more than 2 below RDLNKTBS (i.e. either at least three SACCH reports in a row were missed or the current SACCH report is missing and additional SACCHs were missing before) then a normal BTS power increase will be commanded.

SG1PCPAR=<NULL>, object: PWRC range: <NULL>, 12 fields with ranges in correspondence 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 control decision for this service group is based the ordinary PWRC parameter settings. For 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 PWRC parameters they 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 control decision for this service group is based the ordinary PWRC parameter settings. Fo further details please refer to the section 'Service dependent Handover and Power Control' in the appendix of this document.

UPTLEVD=36, object: PWRC unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm default: 36 Reference: GSM 05.08 Default value changed in BR8.0!

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 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm range: 0..63 default: 36 Reference: GSM 05.08 Default value changed in BR8.0!

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) To guarantee a correct interworking of power control and intracell handover, the following rule must be fulfilled: UPTLEVU > HOTULINT For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.

UPTQUAD=2, object: PWRC range: 0..7 0 = less than 0,2% 1 = 0,2% to 0,4% 2 = 0,4% to 0,8% 3 = 0,8% to 1,6% 4 = 1,6% to 3,2% 5 = 3,2% to 6,4% 6 = 6,4% to 12,8% 7 = greater than 12,8% default: 2 Reference: GSM 05.08

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,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% 7 = greater than 12,8% default: 2 Reference: GSM 05.08

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 Indication due to link failure warning

PWRC: EPWCRLFW

PCRLFTH RDLNKTBS

BS Power Control

PWRC: EBSPWRC

LOWTLEVD

LOWTQUAD (is for AMR replaced by

LOWTQAMRDL)

UPTLEVD

UPTQUAD (is for AMR replaced by

UPTQAMRDL)

EBSPWCR

PCMBSTXPRL

MS Power Control

PWRC: EMSPWRC

LOWTLEVU

LOWTQUAU (is for AMR replaced by

LOWTQAMRUL)

UPTLEVU

UPTQUAU (is for AMR replaced by

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 Reference: 3GPP 44.060

Access burst type, this parameter corresponds to the 3GPP parameter ACCESS_BURST_TYPE and 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.

ALPHA=3, object: PTPPKF unit: 0.1 range: 0..10 0=0.0, 1=0.1, ... 10=1.0 default: 3 Reference: 3GPP 45.008

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

BCGRWEI=1, object: PTPPKF range: 1...32 default: 1

Background weight, this parameter represents the weight for background class, (scheduling priority 4).

BEPFIDLWEI=1, object: PTPPKF range: 1...32 default: 1

Best effort PFIDL weight, this parameter represents the weight for predefined PFI best effort in DL.

BEPAVGP=5, object: PTPPKF range: 0..15 default: 5 Reference: 3GPP 45.008

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: UNIT200 Default value changed in BR8.0!

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: UNIT100 Default value changed in BR8.0!

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 Reference: GSM 05.02

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 3GPP 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 Reference: GSM 05.02

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 3GPP parameter BS_PRACH_BLKS. Note: Also for this parameter the system does not refuse entering senseless values which may cause blocking of the PBCCH functionality itself (e.g. reserving 0 PRACH blocks allows no more packet accesses in the cell!).

BSCDVMA=10, object: PTPPKF range: 1-15 default: 10 Reference: 3GPP 44.060 Default value changed in BR8.0!

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 3GPP 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 Reference: GSM 05.02

BS PBCCH blocks, this parameter corresponds to the 3GPP parameter BS_PBCCH_BLKS and 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



BVCBHIPER=PER70, object: PTPPKF range: PER50, PER60, PER70, 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 range: PER50, PER60, PER70, 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. Caution: It is strictly recommended to maintain the default value!

BVCBMAPER=PER100, object: PTPPKF range: PER010, PER020, PER030, PER040, PER050, PER060 PER070, PER080, PER090 PER100, PER110, PER120, PER130, PER140, PER150 PER160, PER170, PER180 PER190 PER200 default: PER100 Reference: GSM08.18

BVC bucket max percentage defines the value of the BVC Bucket Size (Bmax) reported in the FLOW-CONTROL-BVC PDU 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.. Caution: It is strictly recommended to maintain the default value!

BVCBSPPER=PER200, object: PTPPKF range: PER100, PER110, PER120, PER130, PER140, PER150 PER160, PER170, PER180 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 Reference: 3GPP 45.008

GPRS C31 hysteresis, this parameter corresponds to the 3GPP parameter C31_HYSTERESIS and 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).

C32QUAL=FALSE, object: PTPPKF range: TRUE, FALSE default: FALSE Reference: 3GPP 45.008

GPRS C32 qualifier, this parameter corresponds to the 3GPP parameter 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.



CACKTYP=0, object: PTPPKF range: 0..1 default: 0 Reference: 3GPP 44.060

Control acknowledgement type, this parameter corresponds to the 3GPP parameter CONTROL_ACK_TYPE and 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)!

CPCUN=1, object: PTPPKF range: 0..11

CPCU number, this parameter is mandatory and represents the Common PCU the PCU refers to (see command CREATE CPCU).

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. - 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 Reference: 3GPP 44.060

Maximum discontinuous receipt timer, this parameter corresponds to the 3GPP parameter DRX_TIMER_MAX and 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.

EDASUP=DISABLED, object: PTPPKF range: ENABLED, DISABLED default: DISABLED

Extended dynamic allocation support, this parameter defines if Extended Dynamic Allocation is supported or not.

EDTMSUP=DISABLED, object: PTPPKF range: ENABLED, DISABLED default: DISABLED

Enable DTM support, this parameter defines if Dual Transfer Mode (DTM) is supported or not.

EGPLGPEIGHTTS=16, object: PTPPKF range: 8..64, <NULL> 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 16th DL data block is polled. This results in a polling period of 320ms in case a single PDCH is 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 range: 8..64, <NULL> 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 range: 8..64, <NULL> default: 8 Default value changed in BR8.0!

EGPRS polling period four time slots, this parameter specifies the polling period to be used if four timeslots are assigned.

EGPLGPONETS=8, object: PTPPKF range: 8..64, <NULL> default: 8 Default value changed in BR8.0!

EGPRS polling period one time slot, this parameter specifies the polling period to be used if one timeslot is assigned.

EGPLGPSEVENTS=16, object: PTPPKF range: 8..64, <NULL> 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 range: 8..64, <NULL> 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 range: 8..64, <NULL> default: 8 Default value changed in BR8.0!

EGPRS polling period three time slots, this parameter specifies the polling period to be used if three timeslots are assigned.

EGPLGPTWOTS=8, object: PTPPKF range: 8..64, <NULL> default: 8 Default value changed in BR8.0!

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 range: WS64, WS96, WS128, 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 range: WS64, WS96, WS128, 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 range: WS64, WS96, WS128, 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 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, <NULL> default: WS896 Reference:

EGPRS window size seven time slots, this parameter specifies the window size to be used if seven timeslots are assigned.

EGWSSIXTS=WS160, 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, <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 range: WS64, WS96, WS128, 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 range: WS64, WS96, WS128, 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).



EMANPRESCOM=0, object: PTPPKF range: 0..190 default: DISABLED

EGPRS maximum Number of PDCH reserved Complementary, this parameter defines the number of traffic channels reserved for EGPRS in the 'Complementary Area' which corresponds to the 'near area' (single timeslots) in an extended cell (CELLTYPE=EXTCELL, see command CREATE BTS [BASICS]). In case of non-extended cell, only the parameter EMANPRESPRM (see below) is relevant. Please see also command SET BTS [SERVICE] for further explanations about the feature 'Service Dependent Channel Allocation.

EMANPRESPRM=0, object: PTPPKF range: 0..190 default: DISABLED

EGPRS maximum Number of PDCH reserved Primary, this parameter defines the number of traffic channels reserved for EGPRS in the 'Primary Area'. For standard cells and dualband standard cells (CELLTYPE=STDCELL or DBSTDCELL, see command CREATE BTS [BASICS]) there is only one primary area, i.e. in this case EMANPRESPRM defines the overall number of TCHs reserved for EGPRS on the TRXs that are included in the SLLs of EGPRS services. If the cell is configured as extended cell (CELLTYPE=EXTCELL, see command CREATE BTS [BASICS]), the primary area corresponds to the 'far area' (double timeslots) of the extended cell. Please see also command SET BTS [SERVICE] for further explanations about the feature 'Service Dependent Channel Allocation.

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 Note: Incremental Redundancy (IR) in uplink direction is not supported in BR70. In downlink direction IR is applied by the BSC and all mobiles have to support it according to specifications.

EMFB1UNIR8PSK=FALSE, object: PTPPKF range: TRUE, FALSE default: FALSE

Enable MCS family B MCS1 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 Note: Incremental Redundancy (IR) in uplink direction is not supported in BR70. In downlink direction IR is applied by the BSC and all mobiles have to support it according to specifications.

EMFCUNIR8PSK=FALSE, object: PTPPKF range: TRUE, FALSE default: FALSE

Enable MCS family C 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.

EUMSSNCRESEL=TRUE, object: PTPPKF range: TRUE, FALSE default: FALSE

Enable UMTS MSS network controlled reselection, this parameter shall be used to enable the mobile speed sensitive network controlled GSM/GPRS to UMTS cell reselection algorithm. Further relevant parameters are EUSCNCRESEL (see command SET BSC [BASICS]) and GMICROCU, TUESP and USRSCPNCRESEL (see command CREATE ADJC3G).

FDDGQO=DB00, object: PTPPKF range: ALWAYS MDB28 MDB24 MDB20 MDB16 MDB12 MDB08 MDB04 DB00 DB04 DB08 DB12 DB16 DB20 DB24 DB28 default: DB00 reference: 3GPP 45.008 3GPP 44.060

FDD GPRS Q offset, this parameter corresponds to the 3GPP parameter FDD_GPRS_Qoffset which is broadcast on the PBCCH in the PACKET SYSTEM INFORMATION TYPE 3quater and is related multiRAT mobiles; it is used by the MS/UE for the cell re-selection algorithm from GSM to UTRAN. It defines a level offset by which the RLA_P value of an UTRAN FDD neighbour cell must exceed the RLA_P of the serving GSM cell before the UTRAN neighbour cell is considered for cell reselection from GSM to UTRAN. For details about the GPRS cell reselection algorithm from GSM to UTRAN please refer to the description of parameter GFDDQMI (see below). The parameter values express a value in dB MDBxx = - xxdB (e.g. MDB20 = -20dB) DBxx = xxdB (e.g. DB20 = 20dB) The value ALWAYS indicates an infinite negative (-∞ dB) offset, so with this setting a 3G Mobile will always change to the 3G network if any acceptable 3G cell is available.



FPER=per_15, object: PTPPKF range: per_05, per_10, per_15, per_20, per_25, per_30, per_35, per_40, per_45, per_50 default: per_15

Flow percentage, this parameter is common to MS and PFC; it represents the shrinking value used in case of PDU life time expiration or in case of Bucket Ratio not supported in order to reduce R value sent to SGSN.

GAM=3, object: PTPPKF unit: 2dB range: 0..31 0 = 0dB, 31 = 62dB default: 3 = 6dB

Gamma, this parameter defines the 'gamma' value applied in the power control algorithm. It is an MS and channel specific power control parameter and is sent to the MS within an RLC control message (e.g. PDAS, PUAS, PUAN, PPCTA, PTR, …). The default value of 6dB means basically that the MS 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 GMANPRESPRM and GMANPRESCOM only on those TRXs that belong to service layers that are included in the SLLs defined for GPRS services (see command SET BTS [SERVICE] for further explanations). They are not considered at all within the above load calculations. - 'Idle shared' timeslots are all available timeslots in the cell that can handle both GPRS and CS services. This is the case for TCHs of TRXs that belong to service layers which are included in the SLLs for both GPRS and CS services. - Idle 'CS-only' timeslots are all available TCHs of TRXs that belong to service layers which are included in the SLLs for CS services only. - The decisive total number of idle channels changes due to GPRS and CS load. Therefore vertical allocation may be activated both due to CS calls and PDCH allocations. - The GASTRTH thresholds applied only on the TRXs shared between packet services and other services, i.e. it is applied only on TRXs that belong to service layers which are included in the SLLs for both GPRS and other services. - The BSC vertical allocation decision algorithm does not consider the 'layers' - in fact, the decision about horizontal or vertical allocation is based on the load threshold GASTRTH only, which is considered only on the TRXs shared between packet services and CS services, i.e. it is applied only on TRXs that belong to service layers which are

included in the SLLs for both (E)GPRS and CS. In other words, the BSC will always allocate the PDCHs on all shared layers (starting on the preferred one) but it will not start vertical allocation before the load threshold GASTRTH has not been exceeded. When GASTRTH is exceeded the vertical allocation will start on the layer preferred for the affected GPRS service. For the load calculation the BSC considers, as described above, all resources that can be used by CS calls, not only the ones on the 'shared' layers. This approach was used as it does not make sense to restrict the bandwidth for packet calls as long as enough other resources are still available. If a CS call is to be served, the shared 'packet busy' channels can still be preempted.

GCELLRESH=2, object: PTPPKF unit: 2dB range: 0..7 0=0dB, 7=14dB default: 2 reference: 3GPP 45.008 3GPP 44.060

GPRS cell reselect hysteresis, this parameter corresponds to the 3GPP parameter GPRS_CELL_RESELECT_HYSTERESIS and 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 subtracted from the C31 values of the neighbour cells. The value ranges from 0 dB to 14 dB (2 dB step size).

GFDDMURREP=<NULL>, object: PTPPKF range: 0..3, <NULL> default: 2 reference: 3GPP 45.008 3GPP 44.060

GPRS FDD multiRAT reporting, this parameter is relevant for the feature 'Network Controlled Cell Reselection from GSM/GPRS to UMTS due to UMTS Sufficient Coverage' (see parameter EUSCNCRESEL in command SET BSC [BASICS]) and corresponds to the 3GPP parameter FDD_MULTIRAT_REPORTING which is sent to the MS/UE - in the PACKET SYSTEM INFORMATION TYPE 3quater messages via the PBCCH and - in the PACKET SYSTEM INFORMATION TYPE 5 messages via the PBCCH - in the PACKET CELL CHANGE ORDER messages via the PACCH which commands to leave the current cell and to change to a new one (which may also be an FDD cell). This parameter indicates the number FDD UTRAN cells the MS/UE shall include in the MEASUREMENT REPORTs sent in 'GPRS attached' mode. The UE is thus instructed to report, if available, this number of 3G neighbour cells. Which value should be set for this parameter strongly depends on the environment of the cell (BTS). The default value of '0' only makes sense in areas without any 3G neighbours (no ADJC3G object created for this BTS). The more really relevant 3G cells are available, the higher the value should be set. Usually 6 neighbour cells can be reported within one MEASUREMENT REPORT message. The value must therefore be set considering how many 2G neighbour cells shall be reported in any case.

GFDDQMI =<NULL>, object: PTPPKF range: MDB20 MDB19 MDB18 MDB17 MDB16 MDB15 MDB14 MDB13 <NULL> default: <NULL> reference: 3GPP 45.008 3GPP 44.060

GPRS FDD Q minimum, this parameter corresponds to the 3GPP parameter FDD_Qmin which is broadcast on the PBCCH in the PACKT SYSTEM INFORMATION TYPE 3quater and is a threshold for signal Ec/No which is used for the algorithm for GPRS GSM to UTRAN cell reselection. The parameter values express a value in dB MDBxx = - xxdB (e.g. MDB20 = -20dB) Algorithm for (GPRS) cell re-selection from GSM to UTRAN If the 3G Cell Reselection list includes UTRAN frequencies, the MS updates the value RLA_P (receive level average of cell) for the serving cell and of the at least 6 strongest non-serving GSM cells at least every 5s. The MS then reselects a suitable FDD UTRAN cell if for this FDD cell the following criteria are all met for a period of 5s: 1. The cell's measured RSCP value exceeds the value of RLA_P for

the serving cell and all of the suitable non-serving GSM cells by the value FDD_GPRS_Qoffset (parameter FDDGQO, see above). Note: When a cell reselection has occurred within the previous 15 seconds, FDD_GPRS_Qoffset is increased by 5 dB.

2. The cell's measured Ec/No value is equal or greater than the value FDD_Qmin - FDD_Qmin_Offset (parameter GFDDQMIO, see below) and

3. The cell's measured RSCP value is equal to or greater than the threshold FDD_RSCPmin (parameter GFDDRSCPMI, see below) when broadcast in the serving cell.

The parameters required to determine if the UTRAN cell is suitable are broadcast on BCCH of the UTRAN cell. An MS/UE may start reselection towards the UTRAN cell before decoding the BCCH of the UTRAN cell. The UE stores the UTRAN cell RSCP suitability criterion parameters above, whenever decoded from a UTRAN FDD cell of an equivalent PLMN. If more than one UTRAN cell fulfils the above criteria, the MS selects the cell with the greatest RSCP value. Cell reselection to UTRAN is prohibited within 5 seconds after the MS/UE has reselected a GSM cell from an UTRAN cell if a suitable GSM cell can be found. Note: For the meaning of the measurement values RSCP and Ec/No please refer to the description of parameter GFDDREPQTY (see below).

GFDDQMIO=DB00, object: PTPPKF range: DB00 DB04 DB06 DB08 DB10 DB12 DB14 default: DB00 reference: 3GPP 45.008 3GPP 44.060

GPRS FDD Q minimum offset, this parameter corresponds to the 3GPP parameter FDD_Qmin_Offset which is broadcast on the PBCCH in the PACKET SYSTEM INFORMATION TYPE 3quater and is related to multiRAT mobiles; it is used by the MS/UE for the cell re-selection algorithm from GSM to UTRAN. FDDQMIO represents an offset which is applied to the parameter FDD_Qmin (parameter FDDQMI, see above). For details about the cell reselection algorithm from GSM to UTRAN please refer to the description of parameter FDDQMI (see above). The parameter values express a value in dBm DBxx = xxdB (e.g. DB10 = 10dB)

GFDDREPQTY=<NULL>, object: PTPPKF range: RSCP, EC_NO, <NULL> default: RSCP reference: 3GPP 45.008 3GPP 44.060

GPRS FDD reporting quantity, this parameter corresponds to the 3GPP parameter FDD_REP_QUANT which is sent to the MS/UE - in the PACKET SYSTEM INFORMATION TYPE 3quater messages via the PBCCH and - in the PACKET SYSTEM INFORMATION TYPE 5 messages via the PBCCH - in the PACKET CELL CHANGE ORDER messages via the PACCH which commands to leave the current cell and to change to a new one (which may also be an FDD cell). It 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. The setting of the GFDDREPQTY has an influence on the decision process of the feature 'NCCR from GSM/GPRS to UMTS due to UMTS sufficient coverage': 2G-3G cell reselection due to 'sufficient coverage' is possible with both settings of FDDREPQTY, but the processing of the measured values is different: - If GFDDREPQTY is set to RSCP, the sufficient coverage condition is defined by the RSCP-oriented parameter USRSCPNCRESEL. - If GFDDREPQTY is set to EC_NO, the sufficient coverage condition is defined by the Ec/No-oriented parameter USECNONCRESEL. For both parameters (USRSCPNCRESEL and USECNONCRESEL) please refer to command CREATE ADJC3G.

GFDDRSCPMI=MDB101, object: PTPPKF range: MDB115, MDB113, MDB111, MDB109, MDB107, MDB105, MDB103, MDB101, MDB099, MDB097, MDB095, MDB093, MDB091, MDB089, MDB087, MDB085 default: MDB101 reference: 3GPP 45.008 3GPP 44.060

GPRS FDD RSCP minimum, this parameter corresponds to the 3GPP parameter FDD_RSCPmin which is broadcast on the PBCCH in the PACKET SYSTEM INFORMATION TYPE 3quater and is related multiRAT mobiles - it is used by the UE for the GPRS cell re-selection algorithm from GSM to UTRAN. FDDRSPMI represents a minimum RSCP threshold a UTRAN must exceed to be considered for GSM to UTRAN cell reselection. For details about the cell reselection algorithm from GSM to UTRAN please refer to the description of parameter GFDDQMI (see above). The parameter values express a value in dBm MDBxxx = - xxxdBm (e.g. MDB115 = -115dBm)

GHCSPC=3, object: PTPPKF range: 0..7 default: 3 Reference: 3GPP 45.008

GPRS hierarchical cell structure priority class, this parameter corresponds to the 3GPP parameter PRIORITY_CLASS and represents the Hierarchical Cell Structure priority for the cell reselection procedure.

GHCSTH=10, object: PTPPKF unit: 2dB range: 0..31 0=-110dB, 31=-48dB default: 10 Reference: 3GPP 45.008

GPRS hierarchical cell structure threshold, this parameter corresponds to the 3GPP parameter HCS_THR and indicates the signal strength threshold used in the HCS cell reselection procedure (C31).

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) Reference: 3GPP 44.060

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 replaced by GMANPRESPRM in BR8.0 GMANPRESCOM=0, object: PTPPKF range: 0..190 default: 0

GPRS maximum Number of PDCH reserved Complementary, this parameter defines the number of traffic channels reserved for GPRS in the 'Complementary Area' which corresponds to the 'near area' (single timeslots) in an extended cell (CELLTYPE=EXTCELL, see command CREATE BTS [BASICS]). In case of non-extended cell, only the parameter GMANPRESPRM (see below) is relevant. Please see also command SET BTS [SERVICE] for further explanations about the feature 'Service Dependent Channel Allocation'.

GMANPRESPRM=0, object: PTPPKF range: 0..190 default: 0

GPRS maximum Number of PDCH reserved Primary, this parameter defines the number of traffic channels reserved for GPRS in the 'Primary Area'. For standard cells and dualband standard cells (CELLTYPE=STDCELL or DBSTDCELL, see command CREATE BTS [BASICS]) there is only one primary area, i.e. in this case GMANPRESPRM defines the overall number of TCHs reserved for GPRS on the TRXs that are included in the SLLs of GPRS services. If the cell is configured as extended cell (CELLTYPE=EXTCELL, see command CREATE BTS [BASICS]), the primary area corresponds to the 'far area' (double timeslots) of the extended cell. Please see also command SET BTS [SERVICE] for further explanations about the feature 'Service Dependent Channel Allocation.

GMANRETS=2-2-2-2, object: PTPPKF format: 4 fields for each priority level: prio1-prio2-prio3-prio4 range: 0..3 (for each field) default: 2-2-2-2 Reference: 3GPP 44.060

GPRS maximum number of retransmissions, this parameter corresponds to the 3GPP parameter MAX_RETRANS and 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

GMSTXPMAC=2, object: PTPPKF range: 0..31 default: 2 Reference: 3GPP 44.060

Maximum allowed GPRS MS transmission power on PBCCH/ PCCCH, this parameter corresponds to the 3GPP parameter GPRS_MS_TXPWR_MAX_CCH and 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.

GNMULBAC=<NULL>, object: PTPPKF range: 0..3 default: <NULL> Reference: 3GPP 45.008

GPRS Number of multi band cells, this parameter corresponds to the 3GPP parameter MULTIBAND_REPORTING which is - broadcast on the PBCCH in the PACKET SYSTEM INFORMATION TYPE 3 and - sent to the MS/UE within the PACKET CELL CHANGE ORDER message and within the PACKET MEASUREMENT ORDER message via the PACCH. 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. Please see also parameter GUMTSSRHPRI (same command, see below).

GPATH=PKAAP4, object: PTPPKF range: PKANA PKAAP1 - PKAAP4 default: PKAAP4 Reference: 3GPP 44.060

GPRS priority access threshold, this parameter corresponds to the 3GPP parameter PRIORITY_ACCESS_THR and 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.

GPDPDTCHA=100, object: PTPPKF unit: 1% range: 0..100 default: 100 Default value changed in BR8.0!

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 (E)GPRS service (this is the case if the TRX is defined as belonging to a service layer which is included in the SLL for (E)GPRS services - please see command SET BTS [SERVICE] for further explanations). All TCHs created with these attributes represent 100%. GPDPDTCHA determines the percentage of these TCHs that the BSC may use for (E)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 BTS [BASICS]). Notes: - The percentage defined by GPDPDTCHA is calculated without considering the service layer definition. In other words, the BSC considers all TCH resources that are included in the CS SLLs as well as in either GPRS or/and EGPRS SLLs as the 'shared' resources (100%) and does not allow the (E)GPRS allocation anymore on any of the affected layers when the GPDPDTCHA threshold has been exceeded. For which kind of service (GPRS or EGPRS) the PDTCHs have been previously allocated (and on which layer) does not make any difference. - A modification of the GPDPDTCHA setting is only possible if the PTPPKF object is in administrative state 'locked'.

GRXLAMI=6, object: PTPPKF range: 0..63 default: 6 Reference: 3GPP 44.060

GPRS minimum receive level, this parameter corresponds to the 3GPP parameter GPRS_RXLEV_ACCESS_MIN and is used by 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 (PACKET SYSTEM INFORMATION TYPE 3). 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 neighbour 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]).

GS=8, object: PTPPKF range: 0..9 default: 8 Reference: 3GPP 44.060

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: 3GPP 45.008 3GPP 44.060

GPRS TDD multiRAT reporting, this parameter corresponds to the 3GPP parameter TDD_MULTIRAT_REPORTING which is sent to the MS/UE - in the PACKET SYSTEM INFORMATION TYPE 3quater messages via the PBCCH and - in the PACKET SYSTEM INFORMATION TYPE 5 messages via the PBCCH - in the PACKET CELL CHANGE ORDER messages via the PACCH which commands to leave the current cell and to change to a new one (which may also be a TDD cell). This parameter indicates the number TDD UTRAN cells the MS/UE shall include in the MEASUREMENT REPORTs sent in 'GPRS attached' mode. The UE is thus instructed to report, if available, this number of 3G neighbour cells. Which value should be set for this parameter strongly depends on the environment of the cell (BTS). The default value of '0' only makes sense in areas without any 3G TDD neighbours (no ADJC3G object created for this BTS). The more really relevant 3G TDD cells are available, the higher the value should be set. Usually 6 neighbour cells can be reported within one MEASUREMENT REPORT message. The value must therefore be set considering how many 2G neighbour cells shall be reported in any case.

GTXINT=3, object: PTPPKF range: 0..15 default: 3 Reference: 3GPP 44.060

GPRS transmission interval, this parameter corresponds to the 3GPP parameter TX_INT and 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.

GUMTSSRHPRI =TRUE, object: PTPPKF range: TRUE, FALSE, <NULL> default: TRUE reference: 3GPP 45.008 3GPP 44.060

GPRS UMTS search priority, this parameter corresponds to the 3GPP parameter 3G_SEARCH_PRIO which is sent to the MS/UE - in the PACKET SYSTEM INFORMATION TYPE 3quater messages via the PBCCH and - in the PACKET SYSTEM INFORMATION TYPE 5 messages via the PBCCH - in the PACKET CELL CHANGE ORDER messages via the PACCH which commands to leave the current cell and to change to a new one (which may also be an FDD cell). 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 attempts 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 neighbour cell list contains cells from other radio access technologies (RATs), e.g. 3G neighbour cells. For a multi-RAT MS, cells or frequencies with other radio access technologies may also be included in the GPRS 3G Cell Reselection list. This list may be modified by PACKET MEASUREMENT ORDER or PACKET CELL CHANGE ORDER messages sent via the PACCH. The network controls the measurements for reselection of those cells by the parameter Qsearch_P broadcast on PBCCH (parameter QSRHPRI, see below in same command). For this monitoring, the MS may use search frames that are not required for BSIC decoding or interference measurements in packet transfer mode or MAC-Shared state. If indicated by the parameter 3G_SEARCH_PRIO (=GUMTSSRHPRI), the MS may use up to 25 search frames per 13 seconds without considering the need for BSIC decoding or packet transfer mode / MAC-Shared state interference measurements in these frames.

INTRTRFH1WEI=8, object: PTPPKF range: 1...32 default: 8

Interactive Traffic Handling Priority 1 Weight, this parameter the weight for class, traffic handling priority 1 (scheduling priority 1).





IMCSULNIR8PSK =MCS3, object: PTPPKF range: MCS1, MCS2, MCS3, MCS4, MCS5, MCS6, MCS7, MCS8, MCS9 <NULL> default: MCS3 Default value changed in BR8.0!

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 range: PER50, PER60, PER70, PER80, PER90 default: PER10 Default value changed in BR8.0!

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 Reference: 3GPP 44.060

Initial coding scheme, this parameter corresponds to the 3GPP parameter INITIAL_CODING_SCHEME and 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.

INIMCSDL =MCS6, object: PTPPKF range: MCS1, MCS2, MCS3, MCS4, MCS5, MCS6, MCS7, MCS8, MCS9 <NULL> default: MCS6 Default value changed in BR8.0!

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

MAFAILNCU=4, object: PTPPKF range: 1...100 default: 4

Maximum failures neighbour cell UMTS, this parameter the maximum number of PACKET CELL CHANGE ORDER messages transmitted vie the PACCH for the same UMTS Neighbour cell for a MS/UE, in case the ordered cell change fails.

MSBHIPER=PER70, object: PTPPKF range: PER50, PER60, PER70, PER80, PER90 default: PER70 Reference:

MS bucket high percentage. If the MS Bucket Level is greater 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. Caution: It is strictly recommended to maintain the default value!

MSBLPER=PER60, object: PTPPKF range: PER10, PER20, PER30, 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. Caution: It is strictly recommended to maintain the default value!

MSBMAPER=PER100, object: PTPPKF range: PER010, PER020, PER030, PER040, PER050, PER060 PER070, PER080, PER090 PER100, PER110, PER120, PER130, PER140, PER150 PER160, PER170, PER180 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). Caution: It is strictly recommended to maintain the default value!

MSBSPPER=PER200, object: PTPPKF range: PER100, PER110, PER120, PER130, PER140, PER150 PER160, PER170, PER180 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. Caution: It is strictly recommended to maintain the default value!



MSRMAXU=FALSE, object: PTPPKF range: TRUE, FALSE default: FALSE

Mobile station rate max used, if this parameter is TRUE, Rmax is used for Bmax and R computation, otherwise RGUA is used.

NAVGI=10, object: PTPPKF range: 0..15 default: 10 Reference: 3GPP 45.008

N averaging interference, this parameter corresponds to the 3GPP parameter N_AVG_I represents an interfering signal strength filter constant for power control 2(k/2), k = 0, 1, … , 15.

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 Reference: 3GPP 44.060 Changed to 'read-only' parameter in BR8.0 (i.e. parameter can only be interrogated by GET PTPPKF)!

Network control order, this parameter corresponds to the 3GPP parameter NETWORK_CONTROL_ORDER and is transmitted in (PACKET) SYSTEM INFORMATION TYPE 13, PACKET SYSTEM INFORMATION TYPE 1 and PACKET SYSTEM INFORMATION TYPE 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.

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 corresponds to the 3GPP parameter NC_REPORTING_PERIOD_I and defines 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.

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 corresponds to the 3GPP parameter NC_REPORTING_PERIOD_T and indicates the time period between two consecutive PACKET MEASUREMENT REPORT (PMO) messages while the MS is in packet transfer mode.

PCMECH=MEABCCH, object: PTPPKF range: MEABCCH, MEAPDTCH default: MEABCCH Reference: 3GPP 44.060

Power control measurement channel, this parameter corresponds to the 3GPP parameter PC_MEAS_CHAN and 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.



PERSTLVPRI1=5, object: PTPPKF range: 0..14, 16 default: 5 Reference: GSM 04.60

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 Reference: GSM 04.60

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.





PFCBBHIPER=per_70, object: PTPPKF range: per_50, per_60, per_70, per_80, per_90 default: per_70

PFC background bucket high percentage, if PFC Bucket Level is greater than PFCBackgroundBucketHighPercentage * BackgroundBucketMaxPCU the Bucket Congestion is started.

PFCBBLPER=per_60, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80 default: per_60

PFC background bucket low percentage, if PFC Bucket Level is lower than PFCBackgroundBucketHighPercentage * BackgroundBucketMaxPCU the Bucket Congestion is stopped.

PFCBBMAPER=per_100, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80, per_90, per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_100

PFC background bucket maximum percentage, this parameter reduces the value of Bmax automatically computed by the BSC. BSC criteria is BmaxPFC=PFCBBMAPER *Fn*(1sec+TF1)*Rgua, pfc) and Rgua,pfc guaranteed flow rate out of the buffer in the PCU.

PFCBBMAPPER=per_200, object: PTPPKF range: per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_200

PFC background bucket maximum percentage, this parameter assigns the value of Background Bucket Max PCU as percentage of Bmax.



PFCBRMAXU=FALSE, object: PTPPKF range: TRUE, FALSE default: FALSE

PFC background rate max used, if this parameter is TRUE, Rmax is used for Bmax and R computation, otherwise RGUA is used.

PFCBRPER=per_100, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80, per_90, per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_100

PFC background rate percentage

PFCIBHIPER=per_70, object: PTPPKF range: per_50, per_60, per_70, per_80, per_90 default: per_70

PFC interactive bucket high percentage, if PFC Bucket Level is greater than PFCInteractiveBucketHighPercentage * InteractiveBucketMaxPCU the Bucket Congestion is started.

PFCIBLPER=per_60, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80 default: per_60

PFC interactive bucket low percentage, if PFC Bucket Level is lower than PFCInteractiveBucketLowPercentage * InteractiveBucketMaxPCU the Bucket Congestion is finished.

PFCIBMAPER=per_100, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80, per_90, per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_100

PFC interactive bucket high percentage, this parameter reduces the value of Bmax automatically computed by the BSC. BSC criteria is BmaxPFC=PFCIBMAPER *Fn*(1sec+TF1)*Rgua, pfc) and Rgua, pfc guaranteed flow rate out of the buffer in the PCU.

PFCIBMAPPER=per_200, object: PTPPKF range: per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_200

PFC interactive bucket max PCU percentage, this parameter assigns the value of Interactive Bucket Max PCU as percentage of Bmax.

PFCIRMAXU=FALSE, object: PTPPKF range: TRUE, FALSE default: FALSE

PFC interactive rate max used, if this parameter is TRUE, Rmax is used for Bmax and R computation, otherwise RGUA is used.

PFCIRPER=per_100, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80, per_90, per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_100

PFC interactive rate percentage, this parameter defines ???



PFCSBHIPER=per_70, object: PTPPKF range: per_50, per_60, per_70, per_80, per_90 default: per_70

PFC streaming bucket high percentage, if PFC Bucket Level is greater than PFCStreamingBucketHighPercentage * StreamingBucketMaxPCU the Bucket Congestion is started.

PFCSBLPER=per_60, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80 default: per_60

PFC streaming bucket low percentage, if PFC Bucket Level is lower than PFCStreamingBucketHighPercentage * StreamingBucketMaxPCU the Bucket Congestion is stopped.

PFCSBMAPER=per_100, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80, per_90, per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_100

PFC streaming bucket max percentage, this parameter reduces the value of Bmax automatically computed by the BSC. BSC criteria is maxPFC=PFCSBMAPER *Fn*(1sec+TF1)*Rgua, pfc) and Rgua, pfc guaranteed flow rate out of the buffer in the PCU.

PFCSBMAPPER=per_200, object: PTPPKF range: per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_200

PFC streaming bucket max PCU percentage, this parameter assigns the value of Streaming Bucket Max PCU as percentage of Bmax.

PFCSRMAXU=FALSE, object: PTPPKF range: TRUE, FALSE default: FALSE

PFC streaming rate max used, if this parameter is TRUE, Rmax is used for Bmax and R computation, otherwise RGUA is used.

PFCSRPER=per_100, object: PTPPKF range: per_10, per_20, per_30, per_40, per_50, per_60, per_70, per_80, per_90, per_100, per_110, per_120, per_130, per_140, per_150, per_160, per_170, per_180, per_190, per_200 default: per_100

PFC streaming rate percentage

PKTMEASREPCNT=1, object: PTPPKF range: 0..10 default: 1 Reference:

Packet measurement report counter, this parameter indicates 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 Reference: 3GPP 44.060

Packet number decrement, this parameter corresponds to the 3GPP parameter PAN_DEC and defines the step size 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.



PKTNINC=2, object: PTPPKF range: 0..7 default: 2 Reference: 3GPP 44.060

Packet number increment, this parameter This parameter corresponds to the 3GPP parameter PAN_INC and defines the step size 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.

PKTNMA=4, object: PTPPKF range: 0..7 default: 4 Reference: 3GPP 44.060

Maximum packet number, this parameter corresponds to the 3GPP parameter PAN_MAX and 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.

PRPBCCH=0, object: PTPPKF range: 0..15 default: 0 Reference: 3GPP 45.008 GSM 04.60

Power reduction on PBCCH, this parameter corresponds to the 3GPP parameter Pb and 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 step size is 2 dBm.

QSRHPRI=NEVER, object: PTPPKF range: UMDB98 UMDB94 UMDB90 UMDB86 UMDB82 UMDB78 UMDB74 ALWAYS OMDB78 OMDB74 OMDB70 OMDB66 OMDB62 OMDB58 default: NEVER reference: 3GPP 45.008 3GPP 44.060

Q Search priority, this parameter corresponds to the 3GPP parameter Qserach_P which is sent to the MS/UE - in the PACKET SYSTEM INFORMATION TYPE 3 messages via the PBCCH and - in the PACKET MEASUREMENT ORDER messages and PACKET CELL CHANGE ORDER messages via the PACCH. This parameter indicates and defines a threshold condition under which the Mobile shall monitor and report 3G neighbour cells. For a multi-RAT MS, cells or frequencies with other radio access technologies may also be included in the GPRS 3G Cell Reselection list to be monitored. This list may be modified by PACKET MEASUREMENT ORDER or PACKET CELL CHANGE ORDER messages sent via the PACCH. The network controls the measurements for reselection of those cells by the parameter Qsearch_P broadcast on PBCCH. Qsearch_P defines a threshold and also indicates whether these measurements shall be performed when RLA_P (RLA_P = receive level average) of the serving cell is below or above the threshold. 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 Reference: 3GPP 44.060

Random access retry, this parameter corresponds to the 3GPP parameter RANDOM_ACCESS_RETRY and 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 PACKET SYSTEM INFORMATION TYPE 3 message.



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 Reference: 3GPP 45.008

Routing area reselect hysteresis, this parameter corresponds to the 3GPP parameter RA_RESELECT_HYSTERESIS and 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.

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




Scheduling weight of priority 2, this parameter indicates the scheduling weight associated to scheduling priorities 2. Please refer to SCHWEIPRI1 for further details.





SMSINFO=1-160, object: PTPPKF format: pfiWeight - smsSDUSize range: pfiWeight: 1...32 smsSDUSize: 160..1560 (bytes) default: pfiWeight: 1 smsSDUSize: 160 bytes

PFI SMS info, this parameter represents the weight for the predefined PFI SMS. It consists of the two fields: pfiWeight and smsSDUsize.

SPFIWEI=16, object: PTPPKF range: 1...32 default: 16

Signalling PFI weight, this parameter represents the weight for predefined PFI signalling.

STREAMWEI=32, object: PTPPKF range: 1...32 default: 32

Streaming weight, this parameter represents the weight for streaming.

STGTTLLIINF=10, object: PTPPKF unit: 1s range: 10..90 default: 10 Reference:

Storage time of TLLI info, this parameter indicates the time (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: 2 Reference: 3GPP 44.060 Default value changed in BR8.0!

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 Reference: 3GPP 44.060

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 within (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 Reference: 3GPP 45.008

T average time, this parameter corresponds to the 3GPP parameter T_AVG_T and indicates the signal strength filter period for power control in packet transfer mode.

TAVGW=15, object: PTPPKF range: 0..25 default: 15 Reference: 3GPP 45.008

T average weight, this parameter corresponds to the 3GPP parameter T_AVG_W and indicates the signal strength filter period for power control in packet idle mode.

TBNCU=5, object: PTPPKF range: 1...100 default: 5

Timer back neighbour cell UMTS, this parameter defines the timer which is started relatively to a MS/UE, when this mobile has reselected a GSM/GPRS cell. Until its expiry, NC GSM/GPRS to UMTS cell reselection shall be inhibited for this MS/UE.

TDDGQO =DB00, object: PTPPKF range: ALWAYS, MDB28, MDB24, MDB20, MDB16, MDB12, MDB08, MDB04, DB00, DB04, DB08, DB12, DB16, DB20, DB24, DB28, default: DB00 reference: 3GPP 45.008 3GPP 44.060

TDD GPRS Q offset, this parameter corresponds to the 3GPP parameter TDD_GPRS_Qoffset which is broadcast on the PBCCH in the PACKET SYSTEM INFORMATION TYPE 3quater and is related multiRAT mobiles; it is used by the MS/UE for the cell re-selection algorithm from GSM to UTRAN. It defines a level offset by which the RLA_P value of an UTRAN TDD neighbour cell must exceed the RLA_P of the serving GSM cell before the UTRAN TDD neighbour cell is considered for cell reselection from GSM to UTRAN. For details about the GPRS cell reselection algorithm from GSM to UTRAN please refer to the description of parameter GFDDQMI (see below). The parameter values express a value in dB MDBxx = - xxdB (e.g. MDB20 = -20dB) DBxx = xxdB (e.g. DB20 = 20dB) The value ALWAYS indicates an infinite negative (-∞ dB) offset, so with this setting a 3G Mobile will always change to the 3G network if any acceptable 3G cell is available.

TFAILNCU=5, object: PTPPKF unit: 1s range: 1...100 default: 12

Timer failures neighbour cell UMTS, this parameter is relevant for the feature 'Network Controlled Cell Reselection from GSM/GPRS to UMTS due to UMTS Sufficient Coverage' (see parameter EUSCNCRESEL in command SET BSC [BASICS]) and defines the timer started from BSC when it has received a PACKET CELL CHANGE FAILURE message containing an UMTS cell description from a MS/UE via the PACCH. Until expiry of this timer, this UMTS neighbour cell is excluded from the UMTS Target Cell List.



TRESEL=0, object: PTPPKF range: 0..7 default: 0 Reference: 3GPP 45.008

Timer for cell reselection. This parameter corresponds to the 3GPP parameter T_RESEL which is broadcast within the PACKET SYSTEM INFORMATION TYPE 3 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

TRFPSCTRLT =5, object: PTPPKF unit: 1s range: 1..100 default: 5 Reference:

This parameter was originally supposed to define the minimum time between two consecutive NCCR procedures of an MS towards the same adjacent cell (Traffic packet switched control timer). However, the parameter was finally not implemented as intended but was 'abused' for a different purpose in the scope of CR1850 (implemented in BR7.0) which deals with a particular mobile phone problem. The parameter can thus be described as Time between two consecutive NCCR procedures on the same MS towards the same adjacent cell: During Network Controlled Cell Reselection with particular mobile types (Ericsson, NOKIA) 'ping-pong' behaviour was experienced. These mobiles receive a PACKET CELL CHANGE ORDER towards an adjacent target cell. After having accessed this target cell, mobile performs location area update but it does not perform routing area update. After that it goes back autonomously to the 'old' cell without transmitting PACKET CELL CHANGE FAILURE. To handle this wrong mobile behaviour, the existing (but not used) parameter TRFPSCTRL is employed: as long as TRFPSCTRL runs, the BSC des not to order the mobile to move again into this adjacent target cell, in spite of good radio link scenario. This action trust in the fact that mobile's TLLI used in the old serving cell and mobile's TLLI used in the adjacent target cell may differ only for one bit (bit 30th,which distinguish between local / foreign TLLI), otherwise BSC may not track mobile in its cell change. This procedure requires also that BSC stores information related to the mobile after the end of each TBF at least for the time STGTTLLIINF (storage TLLI Info). Therefore the rule

STGTTLLIINF >=TRFPSCTRL

must be applied (settings violating this rule are prevented by a database command check). Remarks: - The Maximum number of stored cells (to which a NCCR happened) is fixed to 4. - Timer TRFPSCTRL is referred to the serving PTPPKF and is applied to all the adjacent cell relations belonging to that PTPPKF; that is, it is not possible to have different timers for e.g. PTP1->PTP2 and PTP1->PTP3 adjacencies. - The CR covers also an anomalous behaviour by a NOKIA MS: after a failed cell reselection on a target cell, the MS reselects the serving cell by accessing with a single block procedure, but instead of sending a PACKET CELL CHANGE FAILURE, it sends a PACKET RESOURCE REQUEST to open a new TBF. The PACKET CELL CHANGE FAILURE is sent only after the PACKET UPLINK ASSIGNMENT sent by the BSC to open the new TBF. Restrictions: - If a cell is used by the BSC for the reselection of a given MS at time T=x, then this cell can be reused by the BSC for the reselection of the

same MS only after time T'= x + TRFPSCTRL that is, only after timer TRFPSCTRL is expired. - If a MS, after a failed network controlled cell reselection, does not send any PACKET CELL CHANGE FAILURE on the old serving cell, but it comes back by T< 15 sec starting from PACKET CELL CHANGE ORDER message, then the BSC will not choose a second target cell until it will not receive a packet measurement report message. - If a MS sends packet cell change failure message after contention resolution the BSC will not chose a second target cell until it will not receive a packet measurement report message.

Creating the LPDLR links: CREATE LPDLR This command 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 cell-specific Frequency Hopping systems for static MAIO Allocation (SMA): < Starting from BR8.0 the definition of frequency hopping systems

can be done in two different ways: a) the frequency hopping system is defined per BTS (per cell) in the FHSY object which is subordinate to the affected BTS (as done in releases before BR8.0). b) the frequency hopping system is defined per BTSM (per site) in the CFHSY object (see command CREATE CFHSY) which is subordinate to the CBTS object. Variant a) can be used for Static MAIO Allocation (SMA) only, which means that the BTS-specifically defined hopping system (FHSY) is allocated to the CHAN object together with a fixed MAIO value (see command CREATE CHAN for TCH and SDCCH) which determines the position of that particular channel in the applied hopping sequence. Starting from BR8.0, the allocation of a FHSY and MAIO can alternatively be done in the TRX object (see command CREATE TRX). Variant b) can be used for - Static MAIO Allocation (see above), which means that the BTSM-specifically defined hopping system (CFHSY) is allocated to the TRX object together with a fixed MAIO value (see command CREATE TRX) which determines the position of the channels subordinate to the TRX in the applied hopping sequence when Dynamic MAIO Allocation (DMA) is not used by the service layer assigned to that TRX. - Dynamic MAIO Allocation (see above), which means that the BTSM-specifically defined hopping system (CFHSY) is allocated to the TRX object together with a fixed MAIO value (see command CREATE TRX) which determines the position of the channels subordinate to the TRX in the hopping sequence when DMA is not enabled (see parameter ENDMA in commands CREATE CBTS and CREATE BTS [BASICS]). When DMA is enabled, the defined MAIO is no longer relevant as for the channels, MAIOs are dynamically assigned by a special algorithm. The below listed command CREATE FHSY is thus only relevant for variant (a), i.e. DMA is not used at all. In any case, starting with BR8.0, the DBAEM places the command CREATE FHSY before the CREATE TRX commands (in releases up to BR7.0 it was placed before the CREATE CHAN commands). >

CREATE FHSY: NAME= BTSM:0/BTS:0/FHSY:0,

Object path name.

HSN=10, object: FHSY range: 0..63 Reference: 3GPP 45.008 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) Reference: GSM 05.02 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 TRXs: CREATE TRX: NAME= BTSM:0/BTS:0/TRX:0,

Object path name.

GSUP cancelled in BR8.0

FHSYID=<NULL>, object: TRX range: CFHSY_0..CFHSY_1, FHSY_0..FHSY_10, <NULL> default: <NULL> Reference: GSM 05.02 GSM 04.08 GSM 12.20

Frequency hopping system identifier, by the assignment of an already existing frequency hopping system (as defined by a FHSY or CFHSY object) this parameter determines the frequency hopping law that is applied to all CHAN objects that are subrodinate to the TRX. Starting from BR8.0 the parameters FHSYID and MAIO (that in releases up to BR7.0 had been available in the CHAN object only, see command CREATE CHAN) are also available in the TRX object. When these parameters in the TRX object are used this means that for all CHAN objects subordinate to the TRX the same hopping law (with Mobile Allocation (MA) and Hopping Sequence Number (HSN) as defined in the assigned FHSY) is used - which is the usual case, especially in case of synthesizer frequency hopping. If the hopping parameters FHSYID and MAIO of the TRX object are filled, the equivalent parameters in the CHAN object must be set to the <NULL> value in this case. If the hopping system is to be defined by the CFHSY object (this is mandatory in case of Dynamic MAIO Allocation (DMA), the parameters MAIO and FHSYID must be defined in the TRX object. For further details about frequency hopping and the creation of hopping systems for Static MAIO Allocation (SMA) and Dynamic MAIO Allocation, please refer to the following commands and parameter descriptions - command CREATE FHSY - parameters FHSYID and MAIO in command CREATE CHAN - parameters HOPP and HOPMODE in command SET BTS [OPTIONS]. - commands CREATE CBTS and CREATE CFHSY

LAYERID=LY_00, object: TRX range: LY_00..LY11 default: LY_00

Service Layer ID, this parameter is used for the feature 'Service Dependent Channel Allocation' and defines the service layer this TRX belongs to. For further details, please refer to the command SET BTS [SERVICE].

LPDLMN=0, object: TRX range: 0..7

LPDLM number, this parameter defines the 'primary' LPDLM object position (PCMB number and TS LAPD number) of the LPDLR links. Background: Every TRX has an associated LPDLR channel, which is used for the radio signalling (i.e. signalling for call processing) of this particular TRX. In other words, any cell access, signalling transaction or call which involves 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 signalling 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 remaining LPDLMs in order to guarantee the availability of all TRXs of the BTSM, even if one of the PCMB connections has failed. The restrictions 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 and the limitation of the LAPD throughput capacity, which might lead to high LAPD transmission. Please see also the parameters TEI (in command CREATE BTSM), ABISCH (in command CREATE LPDLM) and the explanations provided for the command CREATE SUBTSLB.

MAIO=<NULL>, object: TRX range: 0..63, <NULL> default: <NULL> Reference: GSM 05.02 GSM 04.08

Mobile allocation index offset, this parameter determines the position of all channels subordinate to this TRX within the frequency hopping algorithm defined by the parameter FHSYID (see above). Starting from BR8.0 the parameters FHSYID and MAIO (that in releases up to BR7.0 had been available in the CHAN object only, see command CREATE CHAN) are also available in the TRX object. When these parameters in the TRX object are used this means that for all CHAN objects subordinate to the TRX the same hopping law (with Mobile Allocation (MA) and Hopping Sequence Number (HSN) as defined in the assigned FHSY) is used - which is the usual case, especially in case of synthesizer frequency hopping. If the hopping parameters FHSYID and MAIO of the TRX object are filled the equivalent parameters in the CHAN object must be set to the <NULL> value in this case. If the hopping system is to be defined by the CFHSY object (this is mandatory in case of Dynamic MAIO Allocation (DMA), the parameters MAIO and FHSYID must be defined in the TRX object. For further details about frequency hopping and the creation of hopping systems for Static MAIO Allocation (SMA) and Dynamic MAIO Allocation, please refer to the following commands and parameter descriptions - command CREATE FHSY - parameters FHSYID and MAIO in command CREATE CHAN - parameters HOPP and HOPMODE in command SET BTS [OPTIONS] - commands CREATE CBTS and CREATE CFHSY



MOEC=TRUE, 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 Reference: 3GPP 45.008

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 two different frequency bands (dual band concentric cells, or dual band standard cells, refer to parameters CELLTYP and CONCELL, see above) the use of the PWRRED might be necessary to control the coverage of the TRXs, considering the differences in the output power of the TRX HW (CU/PA) for different frequency bands and the propagation attenuation of the different used frequency. Rules: For configuration rules concerning concentric cells and dualband concentric cells please refer to the description of parameter HORXLVDLO (see command SET HAND [BASICS]).

RADIOMG=254, object: TRX unit: 1 SACCH multiframe range: 1-254 default: 254

Radio measurement granularity for measurements on Abis, this parameter is only relevant if the parameter RADIOMR is set to ON (see below) and specifies the granularity periods for retrieval of 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 pre-evaluation 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. This 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 CCALLF01.. CCALLF63 Reference: GSM 04.08 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.

USFGRAN=DISABLED, object: TRX range: ENABLED, DISABLED default: DISABLED

USF granularity, this parameter defines if USF granularity 1 is supported or not.

Enabling GPRS and EDGE in a cell: < The specific parameters related to the enabling of GPRS and

EDGE can only be entered if TRX objects were created before 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: recommended value: TRUE (if BCCH TRX is equipped with ECU)

EGPRS 8PSK on BCCH TRX, this parameter indicates if EDGE 8PSK modulation is supported on the BCCH TRX. The setting TRUE is only possible if the BCCH TRX is equipped with EDGE CU (ECU, FlexCU) 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. - The operator must consider that the BCCH-TRX is only used for EDGE, if its associated layer (see parameter LAYERID in command CREATE TRX) is included in the service layer list for EDGE (see parameter ELLPRM in command SET BTS [SERVICE]). - The operator must consider that, due to the higher power density of 8PSK modulated signals, the CU (ECU or FlexCU) cannot generate the same maximum output power for 8PSK like for GMSK. If no static power reduction (see parameter PWRRED in command CREATE TRX) is applied, the maximum power values that can be provided on 8PSK timeslots in the downlink will always be by 2..3dB smaller than the maximum power values on GMSK timeslots, depending on the type (ECU, FlexCU), issue (V2, V3 etc.) and variant (850, 900, 1800, 1900 etc.) of the used CU HW boards. If the TRX is operated with static power reduction (at least PWRRED=1(=2dB), better PWRRED=2), there is no power deviation as the (E)CU HW has enough reserves to support the 8PSK power requirement (in this case the deviations remain within the tolerances specified by the 3GPP standard). Thus, with PWRRED applied, the BTS correctly equalizes the output power levels on both 8PSK and GMSK timeslots. This may be a problem if EGPRS with 8PSK coding schemes is used on the BCCH TRX and PWRRED=0, as all BCCH TRX timeslots must transmit with equal maximum power to guarantee a stable DL level reference for neighbour cell measurements. If EGPRS with 8PSK coding schemes is allowed on the BCCH TRX, this will lead, depending on the number of timeslots busy with 8PSK coding schemes, to a slight falsification of the BCCH transmit power, i.e. the measured power will be slightly lower than it really is (on the GMSK timeslots). In this case the operator has 3 main possibilities: 1. The operator can change the PWRRED values. This, however, will reduce the coverage area and may contradict to the original coverage planning concept. 2. If the operator does not want to change the cell coverage planning (which was based on PWRRED=0) he may accept the falsification of the BCCH level and adapt the relevant ADJC handover parameters accordingly (e.g. reduce RXLEVMIN and HOM by 1dB, see corresponding parameters in command CREATE ADJC) in the surrounding cells. 3. The operator can make use of the feature Multi Service Layer Support (MSLS) to allocate EGPRS call only on non-BCCH TRXs with suitable quality figures. In this way the falsification of the BCCH



signal is avoided and no further parameter adjustment is necessary. This may, however, be a problem in cells with a small number of TRXs (e.g. 2 TRX only). For further information about MSLS please refer to command CREATE CBTS. - Some documents say that EDGE 8PSK must not be used timeslot no. 7 of the BCCH TRX due to the fact that the standard (3GPP 45.008) only allows a deviation of 2dB between a 8PSK signal (e.g. on timeslot 7) and the subsequent BCCH/CCCH timeslot (which is always GMSK coded) on timeslot 0. This statement is not correct, as the (maximum) power deviation of the Siemens HW (ECU, FlexCU) between GMSK and 8PSK is in the range of 2..3dB and 3GPP generally allows a tolerance of power values of +/- 1dB. In conclusion: also timeslot 7 (or other timeslots preceding a BCCH/CCCH timeslot) can (and do) support 8PSK signals. The mentioned deviation is in any case only relevant if no static power reduction (see parameter PWRRED in command CREATE TRX) is applied to the BCCH TRX.

EEDGE=TRUE, object: PTPPKF range: TRUE, FALSE default: FALSE Reference: recommended value: TRUE (if at least one TRX is equipped with ECU)

Enable EDGE, this parameter allows to enable/disable EGPRS (EDGE GPRS) on a per cell basis. As this parameter 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: recommended value: TRUE

Enable GPRS, this parameter allows to enable/disable GPRS on a per cell basis. As this parameter can only be set to TRUE, if at least one of the TRXs in the cell supports GPRS (this is the case if the TRX is defined as belonging to a service layer which is included in the SLL for GPRS services - please see command SET BTS [SERVICE] for further explanations).



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 Reference: GSM 05.01 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 subslot, 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: FHYS_0..FHSY_10, <NULL> default: 0 = no hopping Reference: GSM 05.02 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, <NULL> default: 0 Reference: GSM 05.02 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]) Reference: GSM 05.02 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: < Note: All the TRXs with channels of type SDCCH have to be

included in a Layer associated at least to the signaling SLL (see command SET BTS [SERVICE] for further explanations), otherwise these channels will never be used as signaling channel. >

CREATE CHAN: NAME=BTSM:0/BTS:0/ TRX:0/CHAN:1,

Object path name.

CHTYPE=SCBCH, object: CHAN range: see parameter explanations on the right Reference: GSM 05.01 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=SDCCHPOOL (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 subslot, 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.


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=FHSYID_2, object: CHAN range: FHSY_0..FHSY_10, <NULL> default: 0 = no hopping Reference: GSM 05.02 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! - The frequency hopping system can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.

MAIO=0, object: CHAN range: 0..63, , <NULL> default: 0 Reference: GSM 05.02 GSM 04.08

Mobile allocation index offset, start position of the channel in the frequency hopping algorithm. Note: - The MAIO can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.




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: NAME=BTSM:0/BTS:0/ TRX:0/CHAN:3,

Object path name.

CHTYPE=TCHF_HLF, object: CHAN range: see parameter explanations on the right Reference: GSM 05.01 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]).


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=FHSY_1, object: CHAN range: FHSY_0..FHSY_10, <NULL> default: 0 = no hopping Reference: GSM 05.02 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! - The frequency hopping system can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.

GDCH=<NULL>, object: CHAN range: <NULL> PBCCH, PCCCH, default: <NULL>

GPRS Dedicated Channel, this parameter determines the TCH configuration for GPRS usage. The following values are possible: a) PBCCH: The TCH is fixed defined as Packet BCCH. b) PCCCH: The TCH is fixed defined as Packet Common Control Channel c) <NULL> identifies a 'shared' TCH. Shared TCHs can be used for GPRS and circuit switched traffic. All TCHs (TCHFULL, TCHF_HLF and TCHSD with CHPOOLTYP=TCHPOOL) for which GDCH is set to <NULL> (and for which the superordinate TRX supports GPRS, which is the case if the TRX is defined as belonging to a service layer which is included in the SLL for GPRS services - please see command SET BTS [SERVICE] for further explanations) belong 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 BTS [BASICS]). 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.

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. Note: - The MAIO can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.

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.


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.

Note: All the TRXs with channels of type TCHSD in SDCCH_POOL, TCHSD in TCHSD_POOL have to be included in a Layer associated at least to the signaling SLL (see command SET BTS [SERVICE] for further explanations), otherwise these channels will never be used as signaling channel (TCHSD with TCHSD Pool can be used also as traffic channels). >

CREATE CHAN: NAME=BTSM:0/BTS:0/ TRX:0/CHAN:4,

Object path name.

CHTYPE=TCHSD, object: CHAN range: see parameter explanations on the right Reference: GSM 05.01 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.


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=FHSY_1, object: CHAN range: FHSY_0..FHSY_10, <NULL> default: 0 = no hopping Reference: GSM 05.02 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! - The frequency hopping system can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.

GDCH=<NULL>, object: CHAN range: <NULL> default: <NULL>

GPRS Dedicated Channel, this parameter determines the TCH configuration for GPRS usage (for further details please see 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 parameter combination CHTYP=TCHSD,CHPOOLTYP=TCHPOOL


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. Note: - The MAIO can only be defined in the CHAN object, if the hopping system is defined as FHSY, i.e. if Dynamic MAIO Allocation (DMA, for further details see command CREATE CBTS) is not used for the service layer the superordinate TRX belongs to. If the hopping system is to be defined by the CFHSY object (mandatory in case of DMA), the parameters MAIO and FHSYID must be defined in the TRX object (see command CREATE TRX) - in the CHAN object these parameters must be set to the <NULL> value in this case.




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.

ADVCMPHOOAMR =6, object: HAND [BASICS] unit: 1dB range: -30.. 30 (dB) default: 6 (dB)

Advanced compression handover offset AMR, this parameter is related to advanced compression decompression handover (parameter EADVCMPDCMHO, see below) may be used to give preference to the selection of either AMR or non-AMR calls for a compression handover. Normally of all calls fulfilling the advanced compression rules the one with the highest sum of C/I and power reduction level (PL) is being selected (per SACCH multiframe). For an AMR call additionally the value of this attribute is being added, i.e. sum of C/I + PL + ADVCMPHOOAMR before being compared to the other calls suitable for compression. Therefore positive dB values of this attribute will give preference to AMR calls (default), negative dB values to non-AMR calls and a 0dB value will rate both call types equally. A change of the attribute becomes effective in the next SACCH multiframe.

ALEVFULHO=2-1, object: HAND [BASICS] unit: 1 SACCH multiframe (averaging period) range: 1-31 (averaging period) 1-3 (DTX weight. factor) default: 2 (averaging period) 1 (DTX weighting 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, object: HAND [BASICS] unit: 1 CMR range: 1..31 default: 5 Parameter value range adapted to real range (1..31) in BR8.0!

Handover averaging parameters for AMR CODEC MODE REQUESTs, this parameter defines the size of the averaging window for downlink CODEC MODE REQUESTs (CMR) received from the MS during an AMR (Adaptive Multi Rate) 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 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, object: HAND [BASICS] 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. Attention: this distance criterion, however, is only considered, if the concentric cell is no 'dualband concentric cell' (i.e. no concentric cell with mixed frequency bands in the TRXs)! Note: If CCDIST is set to TRUE then - new calls are set up in the complete area or a handover from inner to complete area is executed if the level conditions defined by the parameters HORXLVDLO (for call setup) and HORXLVDLI (for handover) are fulfilled or if the MS-BTS distance exceeds 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>, object: HAND [BASICS] 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'. Note: The BSC only allows the 'inner-to-inner' handover if both the originating and target cell of a handover procedure are configured as concentric cells (CONCELL=TRUE in command CREATE BTS [BASICS]). This means that only in this case the BSC will start the PREFERRED AREA REQUEST procedure during inter-cell handover. This means that it is up to the operator to enter only object path names of BTS instances that are really configured correspondingly.

CCELL2=NOT_DEFINED-NOT_DEFINED, object: HAND [BASICS] 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, object: HAND [BASICS] range: TRUE, FALSE default: TRUE Reference: 3GPP 45.008

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, object: HAND [BASICS] 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 signalling 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>, object: HAND [BASICS] 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 in BR7.0. Originally, compression-decompression handover was available only for AMR calls. Moreover, while compression handover was triggered due to TCH load conditions in the serving cell, decompression handover was only triggered due to radio reasons, i.e. it was triggered to guarantee an acceptable QoS for the ongoing call in case the radio conditions deteriorate. In BR7.0, the 'advanced' option of AMR compression/decompression handover, which could be enabled by EADVCMPDCMHO, only consisted of an improved handover decision algorithm that considered level criteria in addition to quality criteria. In BR8.0, the advanced compression / decompression handover was additionally enhanced: a) Compression/decompression handover is supported not only for AMR but also for non-AMR calls (FR, EFR, HR) b) Decompression Handover is also triggered due to the current TCH load in the cell c) For compression and decompression handover that is triggered due to load conditions, a 'best call selection' mechanism is implemented in the BTS which ensures that compression and decompression handover is executed in a one-by-one manner, with - the most suitable call being selected first and - a maximum handover trigger rate of one per 480ms period. In other words, only one handover is triggered at a time and the minimum time between two consecutive handovers of the same type is 480ms. These enhancements, however, only apply when, in addition to EADVCMPDCMHO, the parameters EADVCMPHOAMR (for AMR calls) and EADVCMPHOSC (for non-AMR calls) are set to TRUE. Detailed Description Compression handover The purpose of Compression handover is, in case of high TCH load, to transfer AMR-FR or (E)FR calls with suitably good radio link quality to an AMR-HR or HR TCH by an intracell handover in order to prevent TCH blocking by providing additional TCH resources. The compression handover algorithm is not continuously enabled in the BTS, but is temporarily enabled / disabled by the BSC (by sending the Abis O&M message SET ATTRIBUTE (SATT) to the BTS) depending on a) the current radio TCH load of the cell (see parameters HRACTAMRT1 and HRACTT1 in command CREATE BTS [BASICS]) or b) the current Abis pool TCH load of the BTSM (see parameter ABISHRACTTHR in command CREATE BTSM). In other words: when the BSC detects during its cyclic TCH load check (see parameter TRFCT in command SET BSC[BASICS]) that - the TCH load in the cell has exceeded the thresholds HRACTT1(HRACTT2)/HRACTAMRT1(HRACTAMRT2) or/and - the Abis TCH load has exceeded the threshold ABISHRACTTHR, the BSC enables compression handover for the affected type of calls (AMR/non-AMR) by sending the corresponding SATT message to the BTS. If enabled by the abovementioned database flags, the BTS checks the 'best suitable call' criteria for this type of compression handover (description see below). Decompression handover Decompression can be triggered in two different scenarios: a) Decompression handover due to radio conditions b) Decompression handover due to low TCH load in the cell.



a) Decompression handover due to radio conditions When a HR or AMR-HR call suffers from poor radio conditions the BTS triggers a decompression handover from HR to E(FR) or from AMR-HR AMR-FR in order to improve the speech quality and to guarantee an acceptable QoS. Important: This type of decompression handover is continuously enabled and is completely independent of the current BTS radio TCH load or Abis pool TCH load. Moreover, the 'best suitable call' selection is not performed in this case, i.e. for each call for which the appropriate radio conditions apply, the decompression handover is triggered immediately. b) Decompression handover due to low TCH load in the cell The purpose of this type of decompression handover is, in case of sufficiently low TCH load, to transfer AMR-HR or HR to an AMR-FR or (E)FR TCH by an intracell handover in order to provide the best possible speech quality and QoS. This type of decompression handover algorithm is not continuously enabled in the BTS, but is temporarily enabled / disabled by the BSC (by sending the Abis O&M message SET ATTRIBUTE to the BTS) depending on a) the current radio TCH load of the cell (see parameters FRACTAMRTH1 and FRACTTH1 in command CREATE BTS [BASICS]) or b) the current Abis pool TCH load of the BTSM (see parameters ABISHRACTAMR and ABISHRACTTHR in command CREATE BTSM). In other words: when the BSC detects that - the TCH load in the cell has dropped below the thresholds FRACTTH1(FRACTTH2)/FRACTAMRTH1(FRACTAMRTH2) or/and - the Abis TCH load has dropped below the threshold ABISHRACTTHR, the BSC enables decompression handover for the affected type of calls (AMR/non-AMR) by sending the corresponding SATT message to the BTS. Only for this type of decompression handover the BTS checks the 'most suitable call' criteria (description see below). Please note that the basic compression/decompression handover cannot be disabled by database command (it is, however automatically disabled if HR is generally disabled in the BSC by setting the parameter HRSPEECH to FALSE (see command SET BSC [BASICS]). The parameter EADVCMPDCMHO just allows to switch between different modes of AMR compression/decompression handover (standard or advanced).

Compression/decompression handover decision Standard AMR Compression Handover (EADVCMPDCMHO=FALSE) Setting the flag EADVCMPDCMHO to FALSE simply means that the compression decompression handover is only triggered for AMR calls and that the AMR compression handover decision is done in the same way as in BR6.0, i.e. the AMR compression and decompression handover decision is solely based on quality (C/I) criteria defined by the parameters HOTHAMRCDL, HOTHAMRCUL, HOTHAMRDDL and HOTHAMRDUL (see below).

Standard AMR Compression handover decision criteria An AMR compression handover from AMR FR to AMR HR is triggered if for a particular AMR FR if a) the BTS has received the SATT message that enables this type of handover in the BTS and b) for an AMR call the following conditions are fulfilled:

(C/I_UL > HOTHAMRCUL) AND

(C/I_DL > HOTHAMRCDL)

Standard AMR Decompression handover decision criteria An AMR de-compression handover from AMR HR to AMR FR is triggered only due to radio conditions (without any enabling SATT message from the BSC) if for a particular AMR HR call the following conditions are fulfilled:

(C/I_UL < HOTHAMRDUL) OR

(C/I_DL < HOTHAMRDDL)

Advanced AMR Compression Handover The advanced compression-decompression handover algorithm is enabled for AMR calls if the database settings EADVCMPDCMHO=TRUE and EADVCMPHOAMR=TRUE are applied. As mentioned above, this setting has several effects: a) it enhances the compression/decompression handover decision algorithm by additional consideration of radio level criteria b) it extends the decompression handover with the enhanced decision algorithm also to non-AMR calls (FR, EFR, HR), compression handover for these CODEC types is only enabled if the setting EADVCMPHOSC=TRUE is applied. c) it enables the load-dependent decompression handover decision d) it enables the 'best suitable call selection' mechanism for compression and decompression handover. a) Enhanced AMR compression/decompression handover decision algorithm by level criteria (since BR7.0) The advanced AMR compression/decompression 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 current power reduction. In this context the new parameters HOTHCMPLVDL, HOTHCMPLVUL, HOTHDCMLVDL and HOTHDCMLVUL (see below) are considered. The AMR compression handover decision is based on the rules listed below: Advanced AMR Compression handover decision criteria An compression handover from AMR FR to AMR HR is triggered if a) the BTS has received the SATT message that enables this type of handover in the BTS and b) for an AMR call the following conditions are fulfilled

{[(RXLEV_UL > HOTHCMPLVUL) AND (C/I_UL >= C/Imax)] OR (C/I_UL + MS_PWRRED > HOTHAMRCUL)}

AND {[(RXLEV_DL > HOTHCMPLVDL) AND (C/I_DL >= C/Imax)]

OR (C/I_DL + BS_PWRRED > HOTHAMRCDL)}

Advanced AMR Decompression handover decision criteria A de-compression handover from AMR HR to AMR FR is triggered only due to radio conditions (without any enabling SATT message from the BSC) if for a particular AMR HR call the following conditions are fulfilled:

{[(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 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 the transient phase, irrespective of whether C/I was considered in the primary condition or not, the following additional conditions for decompression are therefore taken into account: 1. C/I is smaller than a certain threshold, e.g. C/Imax, or alternatively, averaged RXQUAL is greater than a 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 for both links but not marked as such in the following for the sake of simplicity): [(RXLEVxx > HOTHCMPLVxx) AND (C/I >= C/Imax)] OR (C/I + MS/BS_PWRRED > HOTHAMRCxx) Decompression handover is triggered if the sum of C/I and MS/BS_PWRRED (power reduction due to power control) is lower than the decompression handover threshold (see second part of OR

relation). To avoid unjustified decompression handover during the transient phase (e.g. immediately after compression handover) a further condition has to be fulfilled: C/I has to be lower than C/Imax. This avoids that in case of improper setting of the decompression handover threshold, the decompression handover is triggered immediately after allocating the call on the HR channel (PR = 0 and HOTHAMRDxx > 20 dB). An alternative condition to C/I < C/Imax is RXLEV_xx < HOTHDCMLVxx This will avoid that e.g. a MS close to the BTS will perform unjustified decompression handover. b) Extension of the advanced decision algorithm also for non-AMR calls In BR8.0, the advanced compression-decompression handover decision algorithm which was introduced in BR7.0 is also applied to non-AMR calls. The advanced compression-decompression handover algorithm is enabled for non-AMR calls if the database settings EADVCMPDCMHO=TRUE and EADVCMPHOSC=TRUE are applied. Advanced non-AMR Compression handover decision criteria An compression handover from (E)FR to HR is triggered if a) the BTS has received the SATT message that enables this type of handover in the BTS and b) for a non-AMR call the following conditions are fulfilled:

{[(RXLEV_UL > HOTHCMPLVUL) AND (C/I_UL >= C/Imax)] OR (C/I_UL + MS_PWRRED > HOTH(E)FRCUL)}

AND {[(RXLEV_DL > HOTHCMPLVDL) AND (C/I_DL >= C/Imax)]

OR (C/I_DL + BS_PWRRED > HOTH(E)FRCDL)}

Advanced non-AMR Decompression handover decision criteria A decompression handover from HR to (E)FR is triggered only due to radio conditions (without any enabling SATT message from the BSC) if for a particular HR call the following conditions are fulfilled:

{[(RXLEV_UL < HOTHDCMLVUL) OR (C/I_UL < C/Imax)] AND (C/I_UL + MS_PWRRED < HOTHHRDUL)}

OR {[(RXLEV_DL < HOTHCMPLVDL) OR (C/I_DL < C/Imax)]

AND (C/I_DL + BS_PWRRED < HOTHHRDDL)} 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

c) Load dependent decompression handover In BR8.0, the decompression handover can also be triggered due to cell load conditions. A compression handover from (E)FR to HR is triggered if a) the BTS has received the SATT message that enables this type of handover in the BTS and b) for a call the following conditions are fulfilled:

(C/I_ULavg + MS_PL – HOTHxxDUL) < HRDCMLIMTH AND

(C/I_DLavg + BS_PL – HOTHxxDDL) < HRDCMLIMTH xx = AMR-HR or HR

d) 'Best suitable call' selection mechanism This mechanism is applied for both compression and decompression

handover, however, it is executed only, if the handover was triggered by the BSC due to load reasons. If the global feature attribute EADVCMPDCMHO is set to TRUE then out of all AMR and non-AMR calls within a cell that where selected for compression or decompression HO during the length of one measurement period (480ms) one call is selected which is best-suited for the respective HO. This happens according to the following rules: Best call selection for compression HO When a call fulfils the abovementioned advanced compression checks and if EADVCMPHOAMR is TRUE for an AMR call or EADVCMPHOAMR is TRUE for a non-AMR call then BTS-internally a 'compression request' message is sent from the TRX (CU) to the core controller (COBA) containing a combined quality indicator (QI) for UL and DL as follows: QI = C/I_ULavg + MS_PL + C/I_DLavg + BS_PL (for non-AMR) QI = C/I_ULavg + MS_PL + C/I_DLavg + BS_PL + ADVCMPHOOAMR (for AMR) where MS_PL = current MS Power Level BS_PL = current BS Power Level When this message is received in the core controller a timer is started for the length of a measurement period (480ms). While the timer is running the QI's of all further incoming compression request messages from other calls within the cell will be compared against that of the currently best-suited call (which at timer start is the first call requesting a compression HO). The call with the higher QI will become (or stay) the best-suited call for compression. If both QI's are identical then the best-suited call remains unchanged. When the timer expires a 'compression ok' message is sent to the TRX (CU) of the best-suited call which will then initiate an intracell HO request to the BSC. The TRX then performs another check of the abovementioned flags, initiates the sending of the suitable INTRACELL HANDOVER CONDITION INDICATION. This leads to a rate of at maximum 1 compression HO initiation per measurement period (480ms), where the initial compression request of a call can be at most 480ms delayed (if it is the first call requesting compression and thus starting the 480ms timer on the core to collect all other possible compression requests). Best call selection for decompression HO A 'best call' selection for decompression HO is only done if a call was selected for decompression due to load conditions. A decompression HO due to radio conditions is always triggered immediately! When a call fulfils the above advanced decompression checks due to load conditions then a 'decompression request' message is sent from the TRX(CU) to the core controller (COBA) containing a selected quality indicator (QI) of UL or DL for AMR and non-AMR calls as follows: IF

((C/I_ULavg + MS_PL) <= (C/I_DLavg + BS_PL)) THEN

QI = C/I_ULavg + MS_PL ELSE QI = C/I_DLavg + BS_PL

In other words: the worst QI of UL or DL is selected. When this message is received in the core controller a timer is started for the length of a measurement period (480ms). While the timer is running the QI's of all further incoming decompression request messages from other calls within the cell will be compared against that of the currently best-suited call (which at timer start is the first call requesting a decompression HO). The call with the lower QI will become (or stay) the best-suited call for decompression. If both



QI's are identical then the best-suited call remains unchanged. When the timer expires a 'decompression ok' message is sent to the TRX (CU) of the best-suited call which will then initiate an intracell HO request to the BSC. The TRX then performs another check of the abovementioned flags, initiates the sending of the suitable INTRACELL HANDOVER CONDITION INDICATION. This leads to a rate of at maximum 1 initiation of a decompression HO due to load conditions per measurement period (480ms), where the initial decompression request of a call can be at most 480ms delayed (if it is the first call requesting decompression and thus starting the 480ms timer on the core to collect all other possible decompression requests). Necessary decompression HOs of calls due to radio conditions are triggered independently and asynchronously within the cell (decision and trigger of these HOs take place solely within the CU).

Notes on averaging With each new channel activation the channels averaging windows are initialized and in case of the HO quality averaging windows (parameter HOAVQUAL, see below) 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). As described above, the compression-decompression handover decision algorithm considers the 'MS power level' (MS_PL) and BS power level' (BS_PL). To avoid unnecessary compression-decompression handovers, both MS_PL and BS_PL are averaged in the same way as the C/I values, i.e. for the MS and BTS power values the BTS uses an averaging window with the same length like the one defined for the quality handover averaging window (HOAVQUAL). Note: To avoid a ping-pong handover from HR to FR and vice versa, which can occur due to subsequent execution of (AMR) decompression handover and intracell handover (parameter INTRACH, see below) due to quality (for a call whose quality is still poor after decompression handover), the features 'Cell load dependent activation 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.



EADVCMPHOAMR=FALSE, object: HAND [BASICS] range: TRUE, FALSE default: FALSE

Enable Advanced compression Handover for AMR, this parameter is used to enable/disable the selection of AMR calls as candidates for the most suitable call for a compression handover. If enabled AMR calls that fulfil all (advanced algorithm) compression conditions will be considered as candidates for an intracell AFR AHR compression HO. If disabled, no AMR call will be selected for compression handover. A change of the attribute becomes effective in the next SACCH multiframe. Note: This parameter is only checked during the AMR compression handover decision in the BTS - it thus only controls AMR compression handover. AMR decompression handover due to quality or due to load remains unaffected by this parameter, i.e. even if EADVCMPHOAMR=FALSE, the BTS will still trigger decompression handovers for AMR calls will still be triggered if the corresponding conditions are met.

EADVCMPHOSC=FALSE, object: HAND [BASICS] range: TRUE, FALSE default: FALSE

Enable Advanced compression Handover for speech calls (non-AMR), this parameter is used to enable/disable the selection of non-AMR speech calls (using standard FR/EFR CODECs) as candidates for the most suitable call for a compression handover. If enabled calls that fulfil all (advanced algorithm) compression conditions will be considered as candidates for an intracell (E)FR HR compression HO. If disabled, no non-AMR speech call will be selected for compression handover. A change of the attribute becomes effective in the next SACCH multiframe. Note: This parameter is only checked during the non-AMR compression handover decision in the BTS - it thus only controls compression handover for non-AMR speech calls. Decompression handover due to quality or due to load for these calls remains unaffected by this parameter, i.e. even if EADVCMPHOSC=FALSE, the BTS will still trigger decompression handovers for non-AMR calls will still be triggered if the corresponding conditions are met.



EFULHO=FALSE, object: HAND [BASICS] 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). For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document. Note: If the BTS transmits a HANDOVER COMMAND for a 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, object: HAND [BASICS] 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, object: HAND [BASICS] 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 (parameter INTRACH, see below) and compression/decompression (parameter EADVCMPDCMHO, see above). 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 the quality handover conditions persist and another quality handover is to be triggered an inter-cell handover due to quality is attempted (if no suitable neighbour cell is available, the INTERCELL HANDOVER CONDITION INDICATION contains an empty target cell list). b) Limitation of Intracell Handover due to Compression / Decompression The same mechanism as described above is also used for compression/decompression Handover (parameter EADVCMPDCMHO, see above). Tests have shown that, if the quality conditions are near to the quality thresholds for compression/decompression handover, a ping-pong between compression handover and decompression handover may occur. For the 'Limitation Compression/Decompression Handover Repetition' an own counter is implemented in the BSC, which is increased whenever the BSC executes a compression/decompression handover (i.e. sends a CHANNEL ACTIVATION after receipt of an appropriate INTRACELL HANDOVER CONDITION INDICATION). In case of decompression HO to full rate cause the internal counter is increased for each couple of compression/decompression HOs, i.e. the counter is increased by '1' after one back-and-forth compression-decompression handover FR->HR->FR. If a call is set up on a HR channel, the first decompression handover (HR -> FR) is not taken into account). If this counter reaches the threshold MAIRACHO (see below) due to repeated ping-pong between compression and decompression handover, the next CHAN ACT message the BSC sends for an intracell decompression handover (activation cause extension 'decompression' included in the message) 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 'compression' as long as the timer runs.



Handover suppression in BTS In the BTS, the handover suppression mechanism is separately managed for both handover types. In other words, the BTS manages two separate flags that indicate whether a particular type of intracell handover (quality or compression) is currently prohibited for the runtime of TINOIERCHO. However, only one of the flags can be set at a time. This is due to the fact that in the BTS no 'call context' is known but just the context of the activated channel. When a CHAN ACT message for a particular TCH is received in the BTS which contains the cause 'handover successful', the BTS starts the timer TINOIERCHO and sets the handover suppression flag for that type of handover for which the CHAN ACTIVATION was received. If in the meantime, another intracell handover due to a cause different from the suppressed one was successfully completed, the 'suppression context' is lost, as for the BTS a completely new channel context is opened. If e.g. after repeated intracell handovers due to quality the intracell quality handover was suppressed, but during the runtime of TINOIERCHO a decompression handover was executed, the new CHAN ACT for the decompression handover may contain (if the BSC counter for this handover type has reached the MAIRACHO threshold for compression handover) the cause 'handover successful' again - but this time, the BTS will only set the suppression flag for compression handovers and will thus prohibit only 'compression handovers' as long as TINOIERCHO runs. Intracell handovers due to quality are not suppressed in this case. Note: For quality intracell handover, this feature only works if the quality intra-cell HO is controlled by the BSC (LOTRACH=TRUE).

ENAQUALEVHOM=FALSE, object: HAND [BASICS] range: TRUE, FALSE default: FALSE

Enable level handover margin for quality handover, this parameter enables the feature 'level handover margin for quality handover' which implies the evaluation of the level difference between the serving cell and the neighbour cell during handover due to 'UL quality' or 'DL quality' and the comparison of this difference to a configurable handover margin (as known from power budget handover). The idea of the feature is to trigger a handover due to level only to those cells whose downlink receive level exceeds that of the serving cell by a definable margin value. This means that - if the feature is activated - in addition to the basic minimum criteria for handovers due to level (UL or DL) RXLEV_NCELL(n) > RXLEVMIN(n) + max (0,Pa) the additional requirement RXLEV_NCELL(n) > RXLEV_DL + QUALLEVHOM(n) is checked. Only those neighbour cells that fulfill both criteria are regarded as suitable target cells for the level handover and are thus inserted into the target cell list of the of the INTERCELL HANDOVER CONDITION INDICATION sent by the BTS. For the parameter QUALLEVHOM please refer to the command CREATE ADJC.



EUBCHO=FALSE, object: HAND [BASICS] 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). Setting this EUBCHO=TRUE simply means that, when 'power budget handover' is generally enabled (PBGTHO=TRUE), the BTS will also consider 3G 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). 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. Notes: - 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 (see command CREATE ADJC3G) - Different better cell criteria apply for UMTS FDD neighbour cells than for for GSM 2G neighbour cells: While for GSM neighbour cells the better cell handover margin 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. - Like for 2G-2G handover, the averaging of the reported RSCP values of the 3G neighbour cells is done on the basis of an averaging window whose length is defined by the parameter HOAVPWRB (see below). - In the handover decision algorithm, UMTS Better Cell handover has a lower priority than the UMTS Sufficient Coverage handover (parameter EUSCHO, see below). This means that when both handover types are enabled (parameter EUBCHO, see above) and the conditions for both handover types are fulfilled at the same time the BTS will al ways trigger a UMTS Sufficient Coverage handover.



EUHO=FALSE, object: HAND [BASICS] 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. These parameters determine which particular type of UMTS handover is enabled. Notes: - It is important to consider that the BTS only sends the MEASUREMENT INFORMATION messages (that are sent on the DL SACCH and which are the 3G-equivalent to SYSTEM INFORMATION TYPE 5, 5bis and 5ter, as they indicate the 3G neighbour cells to be monitored by the UE) to the UE only if the flag EUHO is set to TRUE. In other words, the UE can only report 3G neighbour cells if EUHO was set to TRUE in the cell and the UE was thus informed via the MEAS INFO messages about the 3G neighbours to be monitored during an ongoing call. - If EUHO and the associated UMTS handover types are enabled (by the flags EUBCHO, EUSCHO, EUIMPHO, see below), the handover is generally allowed for calls currently using a TCH. To allow the same type of handover also for calls currently on an SDCCH, the parameter EUSDCHO

EUIMPHO=FALSE, object: HAND [BASICS] 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 preemption and O&M intervention (see parameters ENFORCHO (SET BSC [BASICS]) and EPRE (SET BTS [OPTIONS])). Attention: 2G-3G Directed Retry does not depend on the flag EUIMPHO. In correspondence with the change request CR2313, 2G-3G Directed Retry is exclusively controlled by parameter EUSDCHO (see command SET BSC [BASICS]). The distinction between the different forced handover procedures is made on the basis of the currently used channel type. In other words: the BTS does not check the status of the EUIMP flag, if the FORCED HANDOVER REQUEST message is received for an SDCCH. If it is received for a TCH (as is the case for forced handover due to preemption and O&M intervention) the flag is checked and correspondingly considered. - 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 3G 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 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, object: HAND [BASICS] 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 CREATE BTS [BASICS]): - If FDDREPQTY is set to RSCP (level-oriented measurement reporting based on RSCP=Received Signal Code Power from UMTS), the minimum target cell level requirement is defined by the parameter USRSCP (see command CREATE ADJC3G). - If FDDREPQTY is set to ECNO (quality-oriented measurement reporting based on Ec/No=Energy chip to Noise), the minimum target cell quality requirement is defined by the parameter USECNO (see command CREATE ADJC3G). Notes: - UMTS sufficient coverage handover can also be speed-sensitive. This means that the handover decision algorithm 'penalizes' particular 3G neighbour cells for a particular time (see parameter HOMDTIME in command CREATE ADJC3G) when the 'sufficient coverage' condition is detected for the first time. Only when the SC condition is still fulfilled after expiry of HOMDTIME, the 'sufficient coverage' handover towards this 3G neighbour cell may be triggered. The 'sufficient coverage' condition is checked for a particular 3G neighbour cell only, if for the affected adjacent cell relation the setting MICROCELL=TRUE (see command CREATE ADJC3G) is applied. - In the handover decision algorithm, UMTS Better Cell handover has a lower priority than the UMTS Sufficient Coverage handover (parameter EUSCHO, see below). This means that when both handover types are enabled (parameter EUBCHO, see above) and the conditions for both handover types are fulfilled at the same time the BTS will al ways trigger a UMTS Sufficient Coverage handover.



EXTCHO=FALSE, object: HAND [BASICS] 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, object: HAND [BASICS] 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, object: HAND [BASICS] 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, object: HAND [BASICS] unit: 1 SACCH multiframe =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 continuously 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.



HOAVLEV=8-2, object: HAND [BASICS] format: averaging period - DTX weighting factor unit: 1 SACCH multiframe =480ms (averaging period) range: 1-31 (averaging period) 1-3 (DTX weight. factor) default: 8 (averaging period) 2 (DTX weighting factor)

Handover averaging parameters for level handover, this 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). Parameter format: averaging period - DTX weighting factor 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 HOAVLEV '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 'averaging period' portion of the parameter HOAVLEV). 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 a level handover even if the

0 4321 98765 3029

0 4321 00065 00sample

offset

lengthmax_av_win_size

1 2111 00012 00weight



averaging window is not yet completely filled with measurement samples. For each setting of the averaging window size there is a 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, object: HAND [BASICS] unit: 1 SACCH multiframe =480ms range: 1-31 default: 8 Reference: 3GPP 45.008

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, object: HAND [BASICS] format: averaging period - DTX weighting factor unit: 1 SACCH multiframe =480ms (averaging period) range: 1-31 (averaging period) 1-3 (DTX weight. factor) default: 6 (averaging period) 2 (DTX weighting factor)

Handover averaging parameters for quality handover, this parameter defines the averaging period and DTX weighting factor for the uplink and downlink RXQUAL measurements. Parameter format: averaging period - DTX weighting factor The settings entered for HOAVQUAL are used for the averaging and DTX weighting for all types of handover decisions that feature an evaluation of the RXQUAL or C/I values (intercell and intracell handover due to quality, compression/decompression handovers etc.). 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 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 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). For further information about the management of the DTX weighting factor please refer to the explanations provided for the parameter HOAVLEV. 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, object: HAND [BASICS] 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 concentric cell' (i.e. no concentric 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, object: HAND [BASICS] unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm default: 10 Reference: GSM 05.08

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) For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.

HOLTHLVUL=8, object: HAND [BASICS] unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm default: 8 Reference: GSM 05.08

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) For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.



HOLTHQAMRDL=8, object: HAND [BASICS] unit: 1 dB range: 0...20 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,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: 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, object: HAND [BASICS] unit: 1 dB range: 0...20 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'. Note: 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, object: HAND [BASICS] 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: 5 Reference: 3GPP 45.008

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) For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.

HOLTHQUUL=5, object: HAND [BASICS] 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: 5 Reference: 3GPP 45.008

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) For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.

HOMRGTA=4, object: HAND [BASICS] 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, object: HAND [BASICS] 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, object: HAND [BASICS] unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -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, object: HAND [BASICS] unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm default: 32

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 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 'dualband concentric cell ' with GSM 900/1800 or 850/1900 Dual Band Operation is configured, 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-inner 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 a cell is configured for two different frequency bands as 'dual band concentric cells' (refer to parameters CELLTYP and CONCELL, see above) the coverage difference is rather determined by the different transmission power values of the used CU PA modules and the different propagation attenuation in different frequency bands than by



different values of static power reduction of the TRXs. In 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. Notes: - HORXLVDLO is also evaluated during also evaluated during inter-cell handover between colocated concentric cells. For further details, please refer to the explanations provided for parameter ININHO (see below). - 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, object: HAND [BASICS] unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm default: 35 Reference: GSM 05.08

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



HOTHAMRCDL=18, object: HAND [BASICS] unit: 1 dB range: 0... 20 default: 18 Value range and Default value changed in BR8.0!

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: 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=18, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 18 Value range and Default value changed in BR8.0!

Handover threshold AMR compression uplink, this parameter represents the uplink 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) are exceeded. For further important details please refer to the description of HOTHAMRCUL (see above)!

HOTHAMRDDL=13, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 13 Value range and Default value changed in BR8.0!

Handover threshold AMR decompression downlink, this parameter represents the downlink quality threshold (as C/I value in dB) used to trigger an intracell AMR Decompression Handover 'halfrate to fullrate'. From BR7.0 on the AMR compression and decompression handover decision can be based on both quality and level conditions. The 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 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=13, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 13 Value range and Default value changed in BR8.0!

Handover threshold AMR decompression uplink, this parameter represents the uplink quality threshold (as C/I value in dB) used to trigger an intracell AMR Decompression Handover 'halfrate to fullrate'. From BR7.0 on the AMR compression and decompression handover decision can be based on both quality and level conditions. The 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 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>, object: HAND [BASICS] 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>, object: HAND [BASICS] 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). 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).

HOTHDCMLVDL=<NULL>, object: HAND [BASICS] 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 (together with defined DL quality conditions). Please note that from BR7.0 on the AMR compression and decompression handover decision can be based on both quality and level conditions. The exact conditions for the initiation of an AMR compression and decompression handover as well as references to the quality related parameters are contained in the description for the parameter EADVCMPDCMHO (see above).

HOTHDCMLVUL=<NULL>, object: HAND [BASICS] 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 (together with defined UL 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).

HOTHEFRCDL=18, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 18

Handover threshold EFR compression downlink, this parameter is used for detecting a compression Handover 'Enhanced Fullrate to Halfrate' in order to use the resources more efficiently. The handover EFR HR is triggered only if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see above), all condition checks for UL- and DL-quality (HOTHEFRCDL, HOTHEFRCUL) and UL- and DL-level (HOTHCMPLVDL, HOTHCMPLVUL) signal a possible compression and if the respective call was selected as best suitable within the cell (EADVCMPHOSC and ADVCMPHOOAMR). For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below. A change of the attribute becomes effective in the next SACCH multiframe.

HOTHEFRCUL=18, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 18

Handover threshold EFR compression uplink, this parameter is used for detecting a compression Handover 'Enhanced Fullrate to Halfrate' in order to use the resources more efficiently. The handover EFR HR is triggered only if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see above), all condition checks for UL- and DL-quality (HOTHEFRCDL, HOTHEFRCUL) and UL- and DL-level (HOTHCMPLVDL, HOTHCMPLVUL) signal a possible compression and if the respective call was selected as best suitable within the cell (EADVCMPHOSC and ADVCMPHOOAMR). For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below. A change of the attribute becomes effective in the next SACCH multiframe.



HOTHFRCDL=18, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 18

Handover threshold FR compression downlink, this parameter is used for detecting a compression Handover 'Fullrate to Halfrate' in order to use the resources more efficiently. The handover FR HR is triggered only if the advanced compression/decompression algorithm is enabled (EADVCMPDCMHO, see above), all condition checks for UL- and DL-quality (HOTHFRCDL, HOTHFRCUL) and UL- and DL-level (HOTHCMPLVDL, HOTHCMPLVUL) signal a possible compression and if the respective call was selected as best suitable within the cell (EADVCMPHOSC and ADVCMPHOOAMR). For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below. A change of the attribute becomes effective in the next SACCH multiframe.

HOTHFRCUL=18, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 18

Handover threshold FR compression uplink, this parameter is used for detecting a compression Handover 'Fullrate to Halfrate' in order to use the resources more efficiently. The handover FR HR is triggered only if the advanced compression/decompression algorithm is enabled (EADVCMPDCMHO, see above), all condition checks for UL- and DL-quality (HOTHFRCDL, HOTHFRCUL) and UL- and DL-level (HOTHCMPLVDL, HOTHCMPLVUL) signal a possible compression and if the respective call was selected as best suitable within the cell (EADVCMPHOSC and ADVCMPHOOAMR). For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below. A change of the attribute becomes effective in the next SACCH multiframe.

HOTHHRDDL =13, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 13

Handover threshold FR decompression downlink, this parameter is used attribute is used for detecting a decompression Handover 'Halfrate to (Enhanced) Fullrate' in order to provide better speech quality. The handover HR (E)FR is triggered if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see above), and either any of the condition checks for UL- and DL-quality (HOTHHRDDL, HOTHHRDUL) and UL- and DL-level (HOTHDCMLVDL, HOTHDCMLVUL) signal a necessary decompression (For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below) or a low load condition exists (FRACTTHR1, FRACTTHR2) and the respective call was selected as best suitable within the cell (HRDCMLIMTH). A change of the attribute becomes effective in the next SACCH multiframe. Note: A decompression HO of HR to EFR is preferred. If the MS is not capable of EFR or EFR is not possible in the target cell then a HO HR to FR shall be executed.

HOTHHRDUL =13, object: HAND [BASICS] unit: 1 dB range: 0...20 default: 13

Handover threshold FR decompression uplink, this parameter is used attribute is used for detecting a decompression Handover 'Halfrate to (Enhanced) Fullrate' in order to provide better speech quality. The handover HR (E)FR is triggered if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see above), and either any of the condition checks for UL- and DL-quality (HOTHHRDDL, HOTHHRDUL) and UL- and DL-level (HOTHDCMLVDL, HOTHDCMLVUL) signal a necessary decompression (For the mentioned parameters please refer to descriptions provided in this command (SET HAND [BASICS] above or below) or a low load condition exists (FRACTTHR1, FRACTTHR2) and the respective call was selected as best suitable within the cell (HRDCMLIMTH). A change of the attribute becomes effective in the next SACCH multiframe. Note: A decompression HO of HR to EFR is preferred. If the MS is not capable of EFR or EFR is not possible in the target cell then a HO HR to FR shall be executed.

HOTMSRM=34, object: HAND [BASICS] unit: 1km range: 0..35 default: 34 Reference: 3GPP 45.008

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 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, object: HAND [BASICS] 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, object: HAND [BASICS] unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -48dBm default: 35 Reference: GSM 05.08

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 . To guarantee a correct interworking of power control and intracell handover, the following rule must be fulfilled: UPTLEVU > HOTULINT For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.

HRDCMLIMTH=6, object: HAND [BASICS] unit: 1 dB range: 0...100 (dB) default: 6 (dB)

Half Rate decompression limitation threshold, this parameter is only relevant if the advanced compression / decompression algorithm is enabled (EADVCMPDCMHO, see above) and is used to limit the number of decompression handovers due to low load conditions to those of low quality. Under low load conditions a call might be selected for a decompression handover HR/AHR (E)FR/AFR, if the sum of its C/I and the power reduction level (PL) minus the threshold HOTHxxCyy (xx=HR or AMR, yy=DL or UL) is below this attributes value; i.e. C/I + PL – HOTHxxDyy < HRDCMLIMTH A change of the attribute becomes effective in the next SACCH multiframe. For the relevant parameters HOTHAMRCDL, HOTHAMRCDL, HOTHHRCDL and HOTHHRCUL please see descriptions above. Notes: Decompression handovers due to bad radio conditions are not affected by this attribute.

IERCHOSDCCH=FALSE, object: HAND [BASICS] 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=TRUE, object: HAND [BASICS] range: TRUE, FALSE default: TRUE Default value changed in BR8.0!

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 CONCELL in command CREATE BTS [BASICS]. Under normal conditions (i.e. with ININHO=FALSE) any incoming handover to a concentric cell is always executed to a TCH belonging to the complete area, even if the level and distance conditions allow an assignment of a TCH belonging to the inner area of the target cell. In this case the inter-cell handover to the complete area of the target cell is directly followed by a complete-to-inner intracell handover within the target cell. If ININHO is set to TRUE these unnecessary handovers are avoided between colocated concentric cells as described below. Which cells are to be considered as 'colocated' (i.e. for which neighbour cells the ININHO flag will be in effect) 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, among other parameters, the level threshold HORXLVDLO (see above) of the affected target cell. Based on this threshold and the measured RXLEV value of the target 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 (if available) and sends the corresponding TCH info to the MS in the HANDOVER COMMAND. In fact, when ININHO is set to TRUE, not only inner-to-inner handovers are possible, but also handovers from the complete 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. Note: The BSC only allows the 'to-inner' handover if both the originating and target cell of a handover procedure are configured as concentric cells (CONCELL=TRUE in command CREATE BTS [BASICS]). This means that only in this case the BSC will start the PREFERRED AREA REQUEST procedure during intre-cell handover. This means that it is up to the operator to enter only object path names of BTS instances that are really configured correspondingly.

complete area inner areainner-to-

inner sector 2 (colocated cell 1)

sector 3 (colocated cell 2)

sector 1 (own cell)



INTERCH=TRUE, object: HAND [BASICS] 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, object: HAND [BASICS] 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 activation 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, object: HAND [BASICS] 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, object: HAND [BASICS] 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, object: HAND [BASICS] 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, object: HAND [BASICS] 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 (parameter INTRACH, see above) or intracell handovers due to compression (parameter EADVCMPDCMHO, see above) that are permitted in the same BTS for a single connection. In the BSC, two separate counters are managed: - The first counter monitors the number of consecutive intracell quality handovers. It is increased by '1' whenever the BSC receives an ASSIGNMENT COMPLETE after having sent an CHANNEL ACTIVATION / ASSIGNMENT COMMAND for a quality intracell handover to the BTS). - The second counter monitors the number of consecutive compression-decompression back-and-forth handovers. This counter is increased by '1' after receipt of the last ASSIGNMENT COMPLETE of a back-and-forth compression-decompression handover (i.e. FR->HR->FR). MAIRACHO determines the common threshold value for both counters - however, both counters are managed separately and independently and lead to independent signalling of handover suppression towards the BTS. In other words: the BSC may a) send a CHAN ACT with cause 'handover successful' to the BTS (when the quality intracell handover counter has reached the MAIRACHO threshold) for one quality intracell handover (leading to a suppression of only quality intracell handover for the time defined by TINOIERCHO - as long as the call remains on that channel) and b) may also add the cause 'handover successful' also to the subsequent CHAN ACT to the BTS, if an INTRACELL HANDOVER CONDITION INDICATION with cause 'decompression' was received and MAIRACHO was additionally reached for the compression-decompression handover counter in the BSC. This will then lead to a suppression of only compression intracell handovers for the time defined by TINOIERCHO - as long as the call remains on that channel. Intracell quality handovers are not suppressed by the BTs at this stage. Any kind of successful intracell handover or intercell handover with a cause different from intracell quality of compression-decompression on the same connection resets the counters. Note: Due to the feature implementation actually the maximum allowed number of consecutive successful intra-cell handovers is MAIRACHO+1.

MAXFAILHO=2, object: HAND [BASICS] 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, object: HAND [BASICS] range: 0..15 default: 6 Reference: GSM 08.08 (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, object: HAND [BASICS] 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 (i.e. a handover due to level, quality or distance - see parameters RXLEVHO, RXQUALHO and DISTHO) is performed to a cell for which NOBAKHO=TRUE, 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)). Notes: - 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. - The back handover prevention mechanism can additionally be enabled for Power Budget handover (see parameter PBGTHO) using BIT41 of the MNTBMASK parameter (see command SET BSC [BASICS]). The effect of this setting is simply that the BSC also adds the IE 'Cell List Preferred' to the CHANNEL ACTIVATION messages sent for the target TCH in case of 'better cell' handover.

NOFREPHO=TRUE, object: HAND [BASICS] 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, object: HAND [BASICS] range: TRUE, FALSE default: TRUE Reference: 3GPP 45.008

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, object: HAND [BASICS] 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, object: HAND [BASICS] range: TRUE, FALSE default: TRUE Reference: 3GPP 45.008

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 HOAVLEV, HOLTHLVDL and HOLTHLVUL (see above). Note: this flag only determines whether inter-cell handovers may be executed with cause 'level'.

RXQUALHO=TRUE, object: HAND [BASICS] range: TRUE, FALSE default: TRUE Reference: 3GPP 45.008

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>, object: HAND [BASICS] range: <NULL>, 8 fields with ranges in correspondence with the PWRC parameters they 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. For further details please refer to the section 'Service dependent Handover and Power Control in the appendix of this document.

SG2HOPAR...SG14HOPAR=<NULL>, object: HAND [BASICS] range: <NULL>, n fields with ranges in correspondence with the PWRC parameters they 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. Fo further details please refer to the section 'Service dependent Handover and Power Control' in the appendix of this document.



THLEVFULHO=8, object: HAND [BASICS] unit: 1 dB range: 0..63 0 = less than -110dBm 1 = -110dBm 2 = -109dBm ... 62 = -48dBm 63 = greater than -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. For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.

THORQST=8, object: HAND [BASICS] unit: 2 SACCH multiframes range: 0..31 default: 5 Reference: 3GPP 45.008

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, object: HAND [BASICS] 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, object: HAND [BASICS] 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: 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 BTS [BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). 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 GMANPRESPRM 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 GMANPRESPRM, the currently used but 'not reserved' TCHs ('idle/shared' TCHs) are considered in correspondence with the setting of DGRSTRGY as indicated above. 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.

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




TRFHOE=TRUE, object: HAND [BASICS] 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 BHOFOT (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, object: HAND [BASICS] 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 TRFHORXLVMOFF (see command CREATE ADJC): RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + TRFHORXLVMOFF 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, object: HAND [BASICS] 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. For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.

TRFLTH=70, object: HAND [BASICS] 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: 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 BTS [BASICS]) has an influence on the radio TCH traffic load calculation if the parameter DGRSTRGYBCNT is set to ENABLED (for further details please refer to parameter DGRSTRGYBCNT in command SET BSC [BASICS]). 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 GMANPRESPRM 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.

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

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




TRFMMA=9, object: HAND [BASICS] 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, object: HAND [BASICS] 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

HOAVLEV HOLTHLVDL HOLTHLVUL

Forced HO**BSC:

ENFORCHO= ENABLE

EISDCCHHO= ENABLE

(inter-BSC DR) ADJC:

FHORLMO

Distance HO HAND:

DISTHO= TRUE

HOAVDIST HOTMSRM

Power Budget HO HAND:

PGBTHO=TRUE HOAVPWRB

ADJC: HOM

Speed Sens. HO HAND:

DPBGTHO= TRUE ADJC:

HOMSOFF HOMDTIME HOMDOFF

MICROCELL

HCS HAND:

HIERC=TRUE

HAND: PL

ADJC: PLNC

PPLNC

HCS HAND:

HIERC=TRUE

HAND: PL

ADJC: PLNC

PPLNC

Hierarchical 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: BHOFOT

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 timeslot or from single to single timeslot (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, HOAVLEV, 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

(Advanced) Compression-

Decompression HO BSC:

TRFCT HAND:

EADVCMPCMDHO EADVCMPHOAMR

EADVCMPHOSC ADVCMPHOOAMR

Compression HO HOTHxxxCDL* HOTHxxxCUL*

HOTHCMPLVDL HOTHCMPLVUL

* xxx=AMR, FR or EFR

a) Compr. HO due to radio TCH load

BTS: HRACTAMRT1 HRACTAMRT2

HRACTT1 HRACTT2

b) Compr. HO due to Abis TCH load

BTSM: ABISHRACTHR

Decompression HO HOTHyyyDDL** HOTHyyyDUL** HOTHDCMLVDL HOTHDCMLVUL

** yyy=AMR, HR

a) Decompr. HO due to radio TCH load

BTS: FRACTAMRTH1 FRACTAMRTH2

FRACTTH1 FRACTTH2

HRDCMLIMTH

b) Decompr. HO due to Abis TCH load

BTSM: ABISFRACTHR

Intracell HO

due to O&M

No

para-meters !

Setting the cell specific parameters and threshold values for 14,4kbit/s 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: RUGRDL < RDGRDL < RHOLTQDL

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: RUGRUL < RDGRUL < RHOLTQUL

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: RUGRDL < RDGRDL < RHOLTQDL

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: RUGRUL < RDGRUL < RHOLTQUL

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.

Enabling features related to ASCI, SMS-CB, Frequency Hopping, HSCSD, Call Release due to Excessive Distance and Dynamic MAIO Allocation (DMA): < The parameters listed below are basically included in the CREATE

BTS command, but the enabling of the associated features is only possible if particular preconditions are fulfilled. These preconditions mainly consist of other database objects and parameters that have to be completely and conclusively defined before the feature can be enabled. If the associated objects or configurations do not consist in the required way, the DBAEM and the BSC command interpreter will reject the feature enabling by an appropriate NACK cause. For this reason DBAEM generates - in addition to the CREATE BTS command - at an earlier point the SET BTS command again at this position with only the relevant parameters included. >

SET BTS: NAME= BTSM:0/BTS:0, Object path name. ASCISER=ASCI_DISABLED, object: BTS [CCCH] range: ASCI_DISABLED, ASCI_ENABLED default: ASCI_DISABLED

ASCI service, this attribute indicates whether for the BTS Advanced Speech Call Items (ASCI) are enabled. If ASCISER=ASCI_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 subscribers. - In case of a VGCS call, the ASCI service subscribers may not only listen but they can also talk. For this they can initiate 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 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 access, 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 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.

BTSHSCSD=FALSE, object: BTS [BASICS] range: TRUE, FALSE default: FALSE Reference: GSM 04.08

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 command SET 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 command SET BSC [BASICS]) is set to ENABLE.

EEXCDIST=FALSE, object: BTS [OPTIONS] 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.

ENDMA=FALSE, object: BTS [OPTIONS] range: TRUE, FALSE default: FALSE

Enable Dynamic MAIO Allocation, this parameter determines whether the feature 'Dynamic MAIO Allocation' is enabled for the BTS. Notes: - In the DBAEM, this parameter is listed within a SET BTS command behind the CREATE CHAN commands. In other words, the enabling of DMA is not possible together with the creation of the BTS object because for the DMA enabling both the DBAEM and the BSC command interpreter check, prior to command execution, whether all associated objects (CFHSY, TRX, CHAN etc.) have been consistently and conclusively created in the database before. - To be in effect, DMA must be enabled both in the BTS and the CBTS object. In the DBAEM, DMA is enabled in the BTS object first (see parameter ENDMA in command CREATE CBTS).

EXCDIST =35, object: BTS [OPTIONS] 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, object: BTS [OPTIONS] range: TRUE, FALSE default: FALSE Reference: GSM 04.08

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, object: BTS [OPTIONS] range: TRUE, FALSE default: FALSE Reference: GSM 04.08

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 Reference: 3GPP 45.008 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) Reference: GSM 03.03 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:nBTSM:x/BTS:n

ADJC



CELLGLID= '262'-'02'-23-111, object: TGTBTS range: MCC: 0..999 MNC: 0..999 (PCS1900) MNC: 0..99 (all others) LAC: 0..65535 CI: 0..65535 Reference: GSM 03.03 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 unit: see tables below range: 0..15 default: 0 Reference: 3GPP 45.008 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 unit: see tables below 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 unit: see tables below 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 Reference: GSM 04.08

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.

EDTMSUP=DISABLED, object: TGTPTPPKF range: ENABLED, DISABLED default: DISABLED

Enable Dual Transfer Mode support, determines whether the feature DTM (Dual Transfer Mode) is enabled in the target cell or not.


neighbour cells

external neighbour

cells TGTBTS:n

TGTBTS:n/TGTPTPPKF:m

ADJC

BTSM:x/BTS:y/PTPPKF:n

BTSM:x/BTS:y



GMSTXPMAC=2, object: TGTPTPPKF range: 0..31 default: 2 Reference: 3GPP 44.060 Default value changed in BR8.0!

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 3GPP parameter GPRS_MS_TXPWR_MAX_CCH.

GRXLAMI=6, object: TGTPTPPKF range: 0..63 default: 6 Reference: 3GPP 44.060

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 (PACKET SYSTEM INFORMATION TYPE 3). 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 3GPP 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!

BARINSYSINFO10 =NO, object: ADJC range: YES, NO default: NO

Barred in SYSINFO10, this parameter BARINSYSINFO10 is used to configure a certain cell as barred in SI_10. In SI_10 it is possible to indicate a cell as barred. If barred in SI_10 the MS will skip this cell as a possible target for cell reselection. This opportunity can be used to avoid the cell reselection of a cell belonging to a different LAC in group receive mode while still maintaining the possibility to select such a cell both in idle mode and as HO target.



BHOFOT=30, object: ADJC unit: 1s range: 1..120 default: 30

Back 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 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 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 Reference: 3GPP 45.008

GPRS hierarchical cell structure priority class, this attribute represents the Hierarchical Cell Structure priority for the cell reselection procedure. This parameter corresponds to the 3GPP parameter GPRS_HCS_PRIORITY_CLASS.

GHCSTH=10, object: ADJC unit: 2dB range: 0..31 0=-110dB, 31=-48dB default: 10 Reference: 3GPP 45.008

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 3GPP 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 3GPP 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 Reference: 3GPP 44.060

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 3GPP 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 PACKET SYSTEM INFORMATION TYPE 3 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 MEASUREMENT 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.

TGTCELL= TGTCELL=internal

neighbour cells

external neighbour

cells TGTBTS:n

TGTBTS:n/TGTPTPPKF:m

ADJC

BTSM:x/BTS:y/PTPPKF:z

BTSM:x/BTS:y



GTEMPOFF=1, object: ADJC unit: 10dB range: 0..7 7=infinity. default: 1 Reference: 3GPP 45.008

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 3GPP parameter GPRS_TEMPORARY_OFFSET.

HOM=69, object: ADJC unit: 1dB range: 0..126 0 = -63dB 126 = +63dB default: 69 (= 6dB) Reference: 3GPP 45.008 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 unit: 1 SACCH multiframe 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 a handover initiation is delayed when the conditions for a power budget handover (better cell handover) towards this adjacent (micro-)cell is detected. 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. Notes on recommended values: - If the feature is enabled, the values for HOMSOFF and HOMDOFF should be set according to the rule: HOMDOFF ≥ HOMSOFF. If mainly 'penalization' of the 'hot spot' cell is the target (without subsequent priorization after expiry of HOMDTIME), both HOMDOFF and HOMSOFF should be set to an equally high value (e.g. 20dB). - A useful setting of the HOMDTIME value should be found depending on the size of the hot spot cell and the average speed of the fast moving MSs. A suitable time can be determined by dividing the average diameter of the cell by the average speed of fast-moving MSs.

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)

Level handover margin, this parameter defines the handover margin for handovers due to uplink level or downlink level. The level handover is triggered if the UL or DL receive level of the serving cell drops below the thresholds HOLTHLVUL resp. HOLTHLVDL. If 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 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: RXLEV_NCELL(n) > RXLEV_DL + LEVHOM(n) in addition to the handover minimum condition. Attention: also in case of handovers due to uplink level, the PBGT calculation only considers the downlink levels of the serving and 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' power budget handover algorithm will be in effect for this neighbour cell. Precondition: the database flags for power budget handover and speed sensitive handover are set to 'enabled' (SET HAND [BASICS]:PBGTHO=TRUE,DPBGTHO=TRUE). For this feature also the parameters HOMDOFF, HOMDTIME and HOMSOFF (see above) are relevant.

MSTXPMAXCL=2, object: ADJC unit, range and default values see explanation to the right! Reference: GSM 05.08 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=DB05, 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 3GPP 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 3GPP 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 3GPP 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 0 = highest priority 15 = lowest priority 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 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



QUALLEVHOM=69, object: ADJC unit: 1dB range: 0..126 0 = -63dB 126 = +63dB default: 69 (= 6dB)

Level handover margin for quality handover, this parameter defines the handover margin for handovers due to uplink quality or downlink quality. The quality handover is triggered if the UL or DL receive level of the serving cell drops below of the thresholds HOLTHQUDL (for AMR: HOLTHQAMRDL) resp. HOLTHQUUL (for AMR: HOLTHQAMRUL) - for further details about the thresholds, please refer to the command SET HAND [BASICS]. If the feature 'Level handover margin for quality handover' (see parameter ENAQUALEVHOM in command SET HAND [BASICS]) is disabled (ENAQUALEVHOM=FALSE), the target cell only has to fulfil 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 quality' or 'downlink quality'. If the feature 'Level handover margin for quality handover' is enabled (ENAQUALEVHOM=TRUE), also the absolute level difference between the serving cell and the neighbour cell is considered. In this case the neighbour cell only appears in the target cell list if its power budget exceeds the entered level handover margin: RXLEV_NCELL(n) > RXLEV_DL + QUALLEVHOM(n) in addition to the handover minimum condition. Attention: also in case of handovers due to uplink quality, the level difference calculation only considers the downlink levels of the serving and the neighbour cell! For further details please refer to the section 'Handover Thresholds and Algorithms' in the appendix of this document.

RXLEVMIN=12, object: ADJC 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: 12 Reference: GSM 05.08 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).

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


neighbour cells

external neighbour

cells TGTBTS:n BTSM:x/BTS:n

ADJC



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=6, object: ADJC unit: 1dB range: -24...+24 (dB) default: 6 (dB)

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 should not have a noticeable negative impact on the current QoS provided to the subscriber, the administrable traffic handover offset defined by TRFHORXLVMOFF is considered in addition to RXLEVMIN when evaluating the DL RXLEV of a particular neighbour cell. For further 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 INACTIVE 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. - Setting USG=INACTIVE means that the neighbour cell is only signaled in the SYSTEM INFORMATION TYPE 5x in order to have the cell measured and reported by the MS - however, outgoing intercell handover to this neighbour cell is never triggered by the BTS, as the cell is only considered for measurement purposes. ??? 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 Reference: GSM 03.03

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 corresponds to the 'Diversity' bit which is sent to the MS/UE, together with the primary scrambling code (see parameter FDDSCRMC below) within the FDD_CELL_INFORMATION field which is included in - the SYSTEM INFORMATION TYPE 2quater sent on the BCCH - the MEASUREMENT INFORMATION message sent to the MS/UE via the SACCH - PACKET SYSTEM INFORMATION TYPE 3 broadcast via the PBCCH - PACKET CELL CHANGE ORDER message and PACKET MEASUREMENT ORDER message sent to the MS/UE via the PACCH This flag 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 corresponds to the 'Scrambling Code' which is sent to the MS/UE within the FDD_CELL_INFORMATION field which is included in - the SYSTEM INFORMATION TYPE 2quater sent on the BCCH - the MEASUREMENT INFORMATION message sent to the MS/UE via the SACCH - PACKET SYSTEM INFORMATION TYPE 3 broadcast via the PBCCH - PACKET CELL CHANGE ORDER message and PACKET MEASUREMENT ORDER message sent to the MS/UE via the PACCH defines the primary scrambling code used by the target FDD cell.



MSTXPMAXUMTS=11, object: TGTFDD range: 0..19 default: 11 Reference: default value changed in BR8.0!

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 value '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.

GMICROCU=FALSE, object: ADJC3G range: TRUE, FALSE default: FALSE

GPRS microcell UMTS, this parameter is relevant for the feature 'Network Controlled Cell Reselection from GSM/GPRS to UMTS due to UMTS Sufficient Coverage' (see parameter EUSCNCRESEL in command SET BSC [BASICS]) and indicates whether an UMTS neighbour cell is to be regarded as an 'UMTS microcell', i.e. whether for and MS/UE the additional condition of the Mobile Speed Sensitive (MSS) NC GSM/GPRS to UMTS cell reselection algorithm (see parameter EUMSSNCRESEL in command CREATE PTPPKF) is to be applied for this 3G adjacent cell. This parameter is the 2G-3G NCCR equivalent to parameter MICROCELL, which is valid for speed-sensitive power budget handover from 2G to 3G cells.

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 'better cell' handover. This parameter is only relevant if speed sensitive power budget handover from GSM 2G to UMTS FDD neighbour cells (see parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS] and MICROCELL (see below)) 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 unit: 1 SACCH multiframe 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 3G neighbour cells is enabled by the setting MICROCELL=TRUE (see below). This 'speed-sensitive' algorithm can be applied either a) to 2G-3G Better Cell handover (in this case further relevant parameters are EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS] and HOMSOFF, HOMDOFF and HOMDTIME (ADJC3G object, see above) or b) to 2G-3G Sufficient Coverage handover (in this case further relevant parameters are EUSCHO in command SET HAND [BASICS] and HOMDTIME (ADJC3G object, see above). Please note that 2G-3G better cell handover and 2G3G sufficient coverage handover cannot be enabled at the same time. Either one or the the other can be enabled at a time.



HOMDTIME specifies the time a handover initiation is penalized (for better cell handover) or delayed (for sufficient coverage handover) when the conditions for one of the abovementioned handovers towards this adjacent (micro-)cell are detected. General Principle of the speed sensitive handover algorithm for 2G-3G 'better cell' handover If the BTS detects a power budget handover condition for an UMTS 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. General Principle of the speed sensitive handover algorithm for 2G-3G 'sufficient coverage' handover If the BTS detects a 'sufficient coverage' handover condition for an 3G neighbour cell which is created with MICROCELL=TRUE (see below), the timer HOMDTIME is started: as long as this timer runs the sufficient coverage condition is still observed but the handover is not triggered for this adjacent 3G cell. Only if the SC condition is still fulfilled after expiry of HOMDTIME, the 'sufficient coverage' handover towards this 3G neighbour cell may be triggered. If the sufficient coverage condition disappears while the HOMDTIME timer runs, the timer is initialized. This means that, if the sufficient coverage condition is subsequently detected again, HOMDTIME is started again from scratch. For further details please refer to chapter 'Appendix', section 'Handover Thresholds & Algorithms' of this document. Notes on recommended values: - If the feature is enabled, the values for HOMSOFF and HOMDOFF should be set according to the rule: HOMDOFF ≥ HOMSOFF. If mainly 'penalization' of the 'hot spot' cell is the target (without subsequent priorization after expiry of HOMDTIME), both HOMDOFF and HOMSOFF should be set to an equally high value (e.g. 20dB). - A useful setting of the HOMDTIME value should be found depending on the size of the hot spot FDD cell and the average speed of the fast moving UEs. A suitable time can be determined by dividing the average diameter of the cell by the average speed of fast-moving UEs.

HOMSOFF=0, object: ADJC3G unit: 1dB range: 0..127 default: 0

Handover margin static offset for 2G-3G speed sensitive 'better cell' handover. This parameter is only relevant if speed sensitive power budget handover from GSM to UMTS neighbour cells (see parameters EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS] and MICROCELL (see below)) 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 3G 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. This 'speed-sensitive' algorithm can be applied either a) to 2G-3G Better Cell handover (in this case further relevant parameters are EUBCHO, PBGTHO and DPBGTHO in command SET HAND [BASICS] and HOMSOFF, HOMDOFF and HOMDTIME (ADJC3G object, see above) or b) to 2G-3G Sufficient Coverage handover (in this case further relevant parameters are EUSCHO in command SET HAND [BASICS] and HOMDTIME (ADJC3G object, see above). Please note that 2G-3G better cell handover and 2G3G sufficient coverage handover cannot be enabled at the same time. Either one or the other can be enabled at a time. For further details about the speed-sensitive handover algorithm please refer to the section 'Handover Thresholds & Algorithms' in the appendix of this document.

PLNC=0, object: ADJC3G range: 0..15 0 = highest priority 15 = lowest priority default: 0

Priority layer of 3G neighbour cell, this parameter determines the priority layer of the adjacent UMTS 3G 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 0 = highest priority 15 = lowest priority default: 0

Penalty priority layer of 3G neighbour cell, this parameter is only relevant if speed sensitive handover from GSM to 3G 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 3G 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 allow the operator to temporarily decrease the priority of the affected 3G neighbour cell to avoid handovers into this cell for fast moving MSs. Rule: PLNC(n) < PPLNC(n) n = no. of a certain ADJC3G 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 (for FDD) 15 (for TDD) Reference:

Rx level minimum of 3G neighbour cell, this parameter determines the minimum received signal level (indicated as RSCP – Received Signal Code Power) the UMTS adjacent cell must provide to be regarded as a suitable target cell for 2G-3G handover when FDDREPQTY (see CREATE BTS [BASICS]) is set to the value RSCP. 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]). Only when the 3G adjacent cell's downlink RSCP value exceeds the level defined by RXLEVMINC, it can be listed as possible target cell in the INTERCELL HANDOVER CONDITION INDICATION message. Note: RXLEVMINC represents the minimum condition for handover only, if the parameter FDDREPQTY (see command CREATE BTS [BASICS]) is set to the value RSCP. If FDDREPQTY is set to the value EC_NO, the minimum condition is defined by parameter UMECNO (see below).



TINHFAIHO=7, object: ADJC3G unit: 1s range: 1-254 default: 7

Timer to inhibit handover failure repetition for 3G 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)

TUESP=FALSE, object: ADJC3G unit: 1s range: 0 .. 100 default: 5

Timer UE speed, this parameter is related to the feature 'Network Controlled Cell Reselection from GSM/GPRS to UMTS due to UMTS Sufficient Coverage' and is only relevant if the parameter GMICROCU (see above) is set to TRUE. TUESP specifies is used Mobile Speed Sensitive Network-Controlled GSM/GPRS to UMTS cell reselection. A UMTS microcell is only included in the UMTS target cell list, if the threshold condition for 'sufficient UMTS coverage' is met during the whole timer period. A 'fast moving' mobile will violate this timer condition and therefore, NC cell reselection from a GSM/GPRS serving cell to this UMTS microcell is not performed for a 'fast moving' mobile.

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]). This parameter is an inter-system adjustment parameter that is supposed to allow the operator to have the flexibility to adjust the RXLEV_NCELL(n) of the UMTS neighbour cells (n) to the RXLEV_DL of the GSM serving cell. Prior to the 'better cell' handover decision, the BTS adds the value of UADJ to the reported RSCP value of the 3G cell (only in effect if FDDREPQTY=RSCP, see CREATE BTS[BASICS]) to adjust the DL receive level of the related UMTS FDD adjacent cell compared to the RXLEV_DL value of the serving cell as reported by the UE. Thus UADJ can be regarded as a fixed offset which is applied to all reported RSCP values of 3G neighbour cells. The UADJ value is also used for the calculation of the so-called PRIO_PBGT value, which is used for the ranking/sorting of 3G neighbour cells in the target cell list within the INTERCELL HANDOVER CONDITION INDICATION message. For further details, please refer to the section 'Handover Thresholds & Algorithms' in the appendix of this document. It is up to the operator to decide whether this parameter shall be used for particular 2G-3G neighbour cell relations or not. UADJ may be used e.g. to favour 3G neighbour cells for target cell ranking (by applying a negative dB value for UADJ) or, if desired by the operator, to 'equalize' to some extent the different reporting quantities of 2G neighbour cells (RXLEVMIN) and 3G neighbour cells (RSCP, see parameter FDDREPQTY in command CREATE BTS [BASICS]). As the BTS internally determines the real 'dBm' RSCP value from the

TGTCELL= external

UMTS FDD neighbour cell

TGTFDD:n

ADJC3G

value reported in the MEAS REP, a 'correction' via UADJ is not necessary. If the operator wants to have the reported relative level value (which is related to -110dBm for RXLEV in the 2G cells and to -115dBm for RSCP in the 3G FDD cells) considered in the handover measurement pre-processing (instead of the real dBm value), he must set UADJ=68 (=5dB) to undo the automatic level correction in the BTS. The recommended default setting is the default value UADJ=63=0dB.

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: 0dB ≤ X with X= CPICH Ec/No default: 19

UMTS minimum Ec/No, this parameter determines the minimum received Ec/No the UMTS adjacent cell must provide to be regarded as a suitable target cell for 2G-3G handover when FDDREPQTY (see CREATE BTS [BASICS]) is set to the value EC_NO. 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]). Only when the 3G adjacent cell's downlink Ec/No value exceeds the level defined by UMECNO, it can be listed as possible target cell in the INTERCELL HANDOVER CONDITION INDICATION message. Note: UMECNO represents the minimum condition for handover only, if the parameter FDDREPQTY (see command CREATE BTS [BASICS]) ist set to the value EC_NO. If FDDREPQTY is set to the value RSCP, the minimum condition is defined by parameter RXLEVMINC (see above).

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: 0dB ≤ X with X= CPICH Ec/No default: 23

UMTS sufficient Ec/No, 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_NO.

USECNONCRESEL=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: 0dB ≤ X with X= CPICH Ec/No default: 19 (= -15 ≤ Ec/No ≤ 14,5 dB)

UMTS sufficient Ec/No for Network-Controlled Cell Reselection, this parameter defines the sufficient Ec/No threshold the 3G neighbour cell must exceed for the initiation of a 'Network Controlled Cell Reselection from GSM/GPRS to UMTS due to sufficient UMTS coverage' when the parameter GFDDREPQTY (see CREATE PTPPKF) is set to the value EC_NO. This threshold is only relevant for FDD cells - in TDD cells it is never used.

USRSCP=8, object: ADJC3G unit: 1 dB range: 0.. 63 0: RSCP < - 115 dBm 1: -115dBm ≤ RSCP < -114dBm ... ... 62: -54dBm ≤ RSCP < -53dBm 63: - 53 dBm ≤ RSCP <NULL> default: 8

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.

USRSCPNCRESEL=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

UMTS FDD sufficient RSCP for Network-Controlled Cell Reselection, this parameter defines the sufficient RSCP threshold the neighbour cell must exceed for the initiation of a 'Network Controlled Cell Reselection from GSM/GPRS to UMTS due to sufficient UMTS coverage' when the parameter GFDDREPQTY (see CREATE PTPPKF) is set to the value RSCP. This threshold is relevant for both FDD and TDD 3G neighbour cells.

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, object: OPC [BASICS] 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, object: OPC [BASICS] 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, object: OPC [BASICS] range: TRUE, FALSE default: TRUE

Periodic signalling link test flag for SS7 connection to MSC, this flag determines whether the periodic signalling link test is enabled for the OPC-SPC relation or not. The signalling 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 signalling test procedure consists of a SIGNALLING LINK TEST MESSAGE (SLTM) which is sent from the BSC to the MSC which – in the positive case – answers with the SIGNALLING TEST ACKNOWLEDGE (SLTA) message. If PERTFLAG is set to TRUE, the signalling 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, object: OPC [BASICS] range: see above (OPC)

Signalling Point Code of MSC, identifies the Signalling Point Code (SPC) of the MSC. For the format please refer to the parameter OPC.

NTWIND=NAT0, object: OPC [BASICS] 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, object: OPC [BASICS] 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 Signalling 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 'NetworkClusterMember – 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, object: OPC [BASICS] range: TRUE, FALSE default: TRUE

Periodic signalling link test flag for SS7 connection to SMLC, this flag determines whether the periodic signalling link test is enabled for the BSC-SMLC CCS7 connection or not. For further details please see parameter MSCPERTFLAG. Attention: The Signalling 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, object: OPC [BASICS] range: see above (OPC)

Signalling Point Code of SMLC, identifies the Signalling Point Code (SPC) of the SMLC (Serving Mobile Location Center). For the format please refer to the parameter OPC.

SS7MTPTYP=CCITT, object: OPC [BASICS] range: CCITT; ANSI default: CCITT

SS7 MTP type, determines the type of message transfer part used by the SS7.

TCONN=3, object: OPC [BASICS] 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, object: OPC [BASICS] unit: 5s range: 0..255 default: 36 (= recommended value !)

Guard timer for adjacent Signalling Point accessibility, this parameter is used to supervise the duration of the adjacent signalling 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 signalling transaction) during the restart procedure. TGUARD is started when the adjacent signalling 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' (Signalling 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 (Signalling 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, object: OPC [BASICS] unit: 5s range: 0..255 default: 180 (= recommended value !)

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, object: OPC [BASICS] unit: 5s range: 0..255 default: 96 (= recommeded value !)

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 signalling 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, object: OPC [BASICS] unit: 5s range: 0..255 default: 36

TINT, wait to report the abnormal release to the maintenance function.

TREL=20, object: OPC [BASICS] 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, object: OPC [BASICS] 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, object: OPC [BASICS] 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 .

NAME=opc:0, Object path name. 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 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 abatement 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 'abatement' 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 abatement

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 range: CCITT: 50..1500 ANSI: 50..300 default: CCITT: 100 ANSI: 100 Default value changed in BR8.0!

M2T2, 'not aligned' timer, known as T2_timer_id in the CCITT blue book.

M2T3=10, object: OPC [MTL2] unit: 100ms range: CCITT: 10..15 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 range: CCITT: 30..60 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 (PPXL) outage. SANTIME represents a keep alive time between TDPC and PPXL. If this timer is set to 0 (disabled), no 'keep-alive' is performed. If SANTIME is set to a value different from 0, the PPXL expect a keep alive message within this time frame. If the PPXL 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 .

NAME=opc:0, Object path name. 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 signalling routes. General Background: Within the SSS, all SPCs are normally reachable via different 'signalling routes'. These 'signalling 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 'signalling link sets' to directly adjacent CCS7 signalling points (SP, i.e. network elements with CCS7 routing capability). If the adjacent signalling point represents the final target signalling point of the OPC-SPC relation, the adjacent signalling point is simultaneously the 'Signalling End Point' (SEP). If the adjacent signalling point just represents an intermediate signalling point on the way to the destination SP, it works as a 'Signalling 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 signalling route defined in its own routing tables. Application in the BSC: The only application of a 'signalling 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 signalling 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, wait to force UNINHIBIT, known as T13_timer in the CCITT blue book.

M3T14=4, object: OPC [MTL3] unit: 100ms range: 20..30 default: CCITT: 20, ANSI: 29

M3T14, wait for INHIBIT acknowledgement, known as T14_timer in the CCITT blue book.


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 SIGNALLING LINK TEST ACKNOWLEDGMENT (SLTA) message. This timer controls the signalling 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, 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 default: CCITT: 36, ANSI: 22

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 default: CCITT: 36, ANSI: 22

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 signalling link test message (SLTM). This timer determines the time period between the transmission of 2 consecutive SLTMs during the periodic signalling 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, diversion delay controlled by a timer, known as T3_timer in the CCITT blue book.


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, 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=<NULL>, object: SS7L range: ppcc-no.: 0..1 port-no.: 0..3 <NULL>

Link access, up to BR7.0, this parameter used to describe the physical port of the SS7L link at the PPCC, ppcc-no. - port-no.. If NTWCARD=NTWSNAP then LNKA must have the value <NULL>. As in BR8.0 NTWSN16 and PPCC is no longer supported, this is the only allowed value.

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 signalling 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 Signalling 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

Signalling Link Code, defines the number of the link on the A interface.

TSLA=0..16,

object: SS7L range: pcma-no.: 0..39 timeslot-no.: 1-31 (PCM30) 1-24 (PCM24)

Link on the A interface, pcma-no. - timeslot-no..

SMLC

LKSET=1 SS7L:2

BSSAP-LE signalling

SMLC<->BSC

LKSET=0 SS7L:0 SS7L:1 BSSAP

signalling 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

signalling BSC<->MSC

and BSSAP-LE signalling 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.


Reset request retry count.


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.


Call request timeout.


Reset request timeout.


Clear request timeout.


Interrupt request timeout.


Registration request timeout.

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 timeslot-no.: 1-31 (PCM30) 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.


Reset request retry count.


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.


Call request timeout.


Reset request timeout.


Clear request timeout.


Interrupt request timeout.


Registration request timeout.

Timer T4. Rule: T4 ≥ T1∗ 3

(TRACE=TRACE), object: X25A range: alphanumeric string of 10 characters default: parameter skipped

Debugging coded string.

Creating an IP Link connection: < The IPLI functional object represents the IP link which may

optionally be used as the layer 1 base for the communication between the BSC and RC (OMAL) or between BSC and CBC (CBCL) as an alternative to the X25 connection. >

CREATE IPLI: NAME=IPLI:0,

Object path name. The range for the X25D-no. is 0..0.

GATEWAY0=<NULL>, object: IPLI range: 0..15 character string, <NULL> default: <NULL>

Gateway 0, this parameter is the IP address of the default gateway connected to the MPCC copy 0. It is present only if either the RC or the CBC (or both) does not belong to the same IP sub-network of the BSC. The convention used for this value is the dotted decimal format (e.g. '172.31.21.88').

GATEWAY1=<NULL>, object: IPLI range: 0..15 character string, <NULL> default: <NULL>

Gateway 1, this parameter is the IP address of the default gateway connected to the MPCC copy 1. It is present only if either the RC or the CBC (or both) does not belong to the same IP sub-network of the BSC. The convention used for this value is the dotted decimal format (e.g. '172.31.21.88').

PRIMARYIPADDR=255.255.255.255, object: IPLI range: 7..15 character string

Primary IP address, this parameter is the IP address assigned to the 'providing service' MPCC port. The RC and CBC always use this address when calling the BSC. The convention used for this value is the dotted decimal format (e.g. '172.31.21.88').

SECONDARYIPADDR=255.255.255.255, object: IPLI range: 7..15 character string

Secondary IP address, this parameter is ap address that is assigned to the 'standby' MPCC port. The RC and CBC will never use this address when calling the BSC. It will be used in order to perform the periodical IP link test. The convention used for this value is the dotted decimal format (e.g. '172.31.21.88').

SUBNETMASK=255.255.255.255, object: IPLI range: 7..15 character string

Subnet mask, this parameter is the NetMask that is assigned to both the MPCC port copies. The value must be assigned according to the local LAN configuration. The convention used for this value is the dotted decimal format (e.g. '172.31.21.88').



Creating the O&M link for the RC connection: CREATE OMAL: NAME=OMAL:0,

Object path name. The range for the OMAL-no. is 0..1.

LINKTYPE=X25D, object: OMAL range: X25A, X25D default: X25D

X25 link 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.

Creating the Quality of Service Alarm Objects: < The feature 'Quality of Service Alarms' was introduced in BR8.0 to

allow a close an immediate supervision of the current network performance by alarms that are based on important Key Performance Indicators (KPI), such as the 'Call drop rate', 'Handover success rate' etc.. In releases before BR8.0 these KPIs could only be calculated in the framework of PM data postprocessing and thus only allowed the detection of problematic performance areas with a considerable delay. With the feature 'QoS alarms', the supervision of the KPIs is continuously done within the system during operation. For this, the same internal counters which are used for the known Performance Measurement Counters are continuously scanned and the BSC continuously calculates the current KPI values based on these counters for definable supervision periods (see parameter SUPPER in the CREATE QSMONxxx commands). When the calculated KPI values exceed particular defined thresholds for the affected KPI, the BSC generates an alarm which makes the operator immediately aware of performance figures which are not within the desired scope. The generated alarms can have the severity 'minor' or 'major', depending on the value of the calculated KPI and the configured alarm threshold. If a 'minor' QoS alarm for a particular object and KPI combination is already active, when the conditions for a 'major' alarm are fulfilled, the 'minor' alarm is cleared when the 'major' alarm is raised. The KPIs to be observed during operation are administered in different database objects for KPIs calculated - per BSC (object QSMONBSC) - per BTS (object QSMONBTS) and - per PTPPKF (object QSMONGPRS). Different thresholds can be configured for 'minor' and 'major' alarms for each KPI and the thresholds can be dynamically adapted depending on the amount of the counted events ('number of samples') on which the KPI calculation is based - in other words, the thresholds can be configured in such a way that for less reliable KPI calculation results (due to a small number of samples / counts of the affected events) the system uses more 'defensive' threshold values, while for reliable KPI calculation results (i.e. when the calculated KPI value is based on a sufficiently high number of event counts) realistic or more 'aggressive' thresholds are applied.

These settings are defined using the database object QSTHRS. Note: The QoS alarms are only raised if the KPI value really exceeds the defined threshold. If the KPI just reaches the threshold value without exceeding it, the QoS alarm is not raised. >

numberof samples

Num

Sam

ples

#3

-10%

Num

Sam

ples

#2

-10%

Num

Sam

ples

#1

-10%

ThirdThresholdSet

FirstThresholdSet

SecondThresholdSet

no alarms

Creating the Quality of Service Alarm threshold sets: < The QSTHRS object defines the threshold sets that can be

allocated to the KPIs defined with the QSMONBSC, QSMONBTS and QSMONGPRS objects. In other words, if a particular KPI is to be observed by QoS alarms, the corresponding parameter with the aforementioned database objects which represents a particular KPI will contain the reference to a created QoS alarm threshold set. For further examples, please see the CREATE QSMONxxx command descriptions below. >

CREATE QSTHRS: NAME= BSC:0/QSTHRS:0,

Object path name, object range 0..49, i.e. up to 50 QSTHRS objects (i.e. 50 sets of QoS alarm thresholds) can be defined.

THRS1=1000-98-92-95-85-2, object: QSTHRS format: 6 fields no. of samples - - threshold major high - threshold major low - threshold minor high - threshold minor low - no. of periods range: numberOfSamples: 0..65535 thresholdMajorHigh 0..100 (%) thresholdMajorLow 0..100 (%) thresholdMinorHigh 0..100 (%) thresholdMinorLow 0..100 (%) numberOfPeriods 1..12 <NULL> default: <NULL>

Threshold set 1, this parameter defines the first threshold set for the QSTHRS object based on a particular 'number of samples' value. Each threshold set consists of 6 fields: 1) Number of Samples specifies the number of relevant samples that have been counted within the supervision period (see parameter SUPPER in command CREATE QSMONxxx). The number of relevant samples corresponds to the denominator in the KPI formula (Example: the number of samples for the QoS indicator 'TCH Drop Rate' (see parameter TCHDROR in object QSMONBTS) represents the number of successful TCH seizures). 2) Threshold Major High specifies the 'high' alarm threshold for the QoS alarm with severity 'major'. In other words: when the calculated KPI value exceeds this threshold for as many supervision periods as defined by 'number of periods' (see (6)), the major QoS alarm is raised. 3) Threshold Major Low specifies the 'low' alarm threshold for the QoS alarm with severity 'major'. In other words: when the calculated KPI value drops below this threshold for as many supervision periods as defined by 'number of periods (see (6)), the major QoS alarm is ceased. 4) Threshold Minor High specifies the 'high' alarm threshold for the QoS alarm with severity 'minor'. In other words: when the calculated KPI value exceeds this threshold for as many supervision periods as defined by 'number of periods (see (6)), the minor QoS alarm is raised. 5) Threshold Minor Low specifies the 'low' alarm threshold for the QoS alarm with severity 'minor'. In other words: when the calculated KPI value drops below this threshold for as many supervision periods as defined by 'number of periods (see (6)), the minor QoS alarm is ceased. 6) Number of Periods

specifies the number of supervision periods (see parameter SUPPER in commands CREATE QSMONxxx) in which the condition for the alarm to be raised or ceased must be present. In other words, only when the alarm condition is present for as many periods as indicated by 'number of periods, the alarm is raised; only when the 'alarm ceased' condition is present for as many periods as indicated by 'number of periods', the alarm is ceased / cleared (see example diagram below, with 'Number of periods'=2).

Remark: Active alarms are also ceased if the 'number of samples' was not reached in as many consecutive supervision periods as defined by 'number of periods'.

THRS2=<NULL>, object: QSTHRS format: see THRS1 range: see THRS1 default: <NULL>

Threshold set 2, this parameter defines the second threshold set for the QSTHRS object based on a particular 'number of samples' value. Format, range and meaning of the fields are the same like for THRS1 (see above). The possibility to define different thresholds for different 'number of samples' values was implemented to allow a dynamic adaptation of the thresholds to the reliability of the calculated KPI figures - in other words, the thresholds can be configured in such a way that for less reliable KPI calculation results (due to a small number of samples) the system uses more 'defensive' threshold values, while for reliable KPI calculation results (i.e. when the calculated KPI value is based on a sufficiently high number of event counts) realistic or more 'aggressive' thresholds are applied.

THRS3=<NULL>, object: QSTHRS format: see THRS1 range: see THRS1 default: <NULL>

Threshold set 3, this parameter defines the third threshold set for the QSTHRS object based on a particular 'number of samples' value. Format, range and meaning of the fields are the same like for THRS1 (see above). For further details please refer to the parameters THRS1 and THRS2 (see above).

Creating the Quality of Service Alarm Objects for the BSC object: CREATE QSMONBSC: NAME= BSC:0/QSMONBSC:0,

Object path name.

PCUPRCSLD=BSC:0/ QSTHRS:0, object: QSMONBSC range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

PCU processor load, this parameter indicates, when its value is different from <NULL>, that the KPI 'PCU Processor Load' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'PCU Processor Load' is based on the Performance Measurement Counter BSCPRCLD and calculated as follows: PCU Processor Load = BSCPRCLDmax [subcounters 31..42] BSCPRCLDmax indicates the highest processor load that occurred within the supervision period (corresponds to 'max total time'). For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'. For this KPI the 'number of samples' portion which is defined in the QSTHRS object addressed by this parameter is not relevant - this is due to the fact that in this KPI formula no denominator exists which is normally used as reference for the 'number of samples'.

SUPPER=MINUTES_5, object: QSMONBSC range: MINUTES_5 MINUTES_10 MINUTES_15 default: MINUTES_5

Supervision period, this parameter defines the supervision period for the KPI calculation for the QoS alarms feature. During the supervision period, the BSC accumulates the counter values that are necessary for the calculation of the KPIs. When the supervision period ends, the BSC calculates the KPI values based on the accumulated counter results and triggers the output, clearance or maintenance of the QoS alarm, depending on the calculated KPI result value, the relevant configured threshold value and the relevant value of 'number of periods (see command CREATE QSTHR).

TDPCPRCSLD=BSC:0/ QSTHRS:0, object: QSMONBSC range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

TDPC processor load, this parameter indicates, when its value is different from <NULL>, that the KPI 'TDPC Processor Load' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'TDPC Processor Load' is based on the Performance Measurement Counter BSCPRCLD and calculated as follows: TDPC Processor Load = BSCPRCLDmax [subcounter 30] BSCPRCLDmax indicates the highest processor load that occurred within the supervision period (corresponds to 'max total time'). For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'. For this KPI the 'number of samples' portion which is defined in the QSTHRS object addressed by this parameter is not relevant - this is due to the fact that in this KPI formula no denominator exists which is normally used as reference for the 'number of samples'.

Creating the Quality of Service Alarm Objects for BTS objects: CREATE QSMONBTS: NAME= BSC:0/QSMONBTS:0,

Object path name.

ASSFAIR=BSC:0/QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

Assignment Failure Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'Assignment Failure Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'Assignment Failure Rate' calculation formula is based on the Performance Measurement Counters TASATT, TASSFAIL, NCLRREQ and calculated as follows:

%100*3]TASSATT[2,

2]NRCLRREQ[2 15] ,..8,10..13TASSFAIL[6 +=eAssFailRat

For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples =TASSATT [2,3] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

CLSETFAIR=BSC:0/ QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

Call Setup Failure Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'Call Setup Failure Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'Call Setup Failure Rate' calculation formula is based on the KPIs 'Immediate Assignment Failure Rate', 'SDCCH Drop Rate' and 'Assignment Failure Rate' which are in turn based numerous Performance Measurement Counters (for further details about the calculation of these KPIS please refer to the parameters IMMASSFAIR, SDCCHDROR and ASSFAIR). For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the number of successful SDCCH activations with successful seizure: Number of samples = NSUCCHPC[1..4, 9..12, 17..20] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

%100*))100

1(*)100

1(*)100

Im1(1( eAssFailRatateSDCCHDropRtemAssFAilRaailRateCallSetupF −−−−=

HANDROR=BSC:0/ QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

Handover Drop Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'Handover Drop Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'Handover Drop Rate' calculation formula is based on the total amount of handover attempts and the total amount of handover drops which are in turn based numerous Performance Measurement Counters as listed below:

%100*HoAtt

HoDrops=HoDropRate

where the parameters 'HoDrops' and 'HoAtt' are calculated by using the following formulas: HoDrops = UNIHIALC[1] + UNIHIRLC[1] + ATINBHDO[all] - SUINBHDO[all] - NRUNINHD[all] + ATOISHDO[all] - SUOISHDO[all] - UNOISHDO[all] HoAtt = ATINHIAC[all] + ATINHIRC[all] + ATINBHDO[all] + ATOISHDO[all]

In case of HoAtt = 0, HODropRate is set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = HoAtt For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

HANFAIR=BSC:0/QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

Handover Failure Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'Handover Failure Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'Handover Failure Rate' calculation formula is based on the total amount of handover attempts and the total amount of handover failures which are in turn based numerous Performance Measurement Counters as listed below:

%100*HoAtt

HoFails=HoFailRate

where the parameters HoFails and HoAtt are calculated by using the following formulas: HOFails = UNINHOIA[all]+UNINHOIE[all]+NRUNINHD[all]+UNOISHDO[all] HOAtt = ATINHIAC[all] + ATINHIRC[all] + ATINBHDO[all] + ATOISHDO[all]

In case of HoAtt = 0, HoFailRate is set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = HoAtt For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

IMMASSFAIR=BSC:0/ QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

Immediate Assignment Failure Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'Immediate Assignment Failure Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'Immediate Assignment Failure Rate' calculation formula is based on the Performance Measurement Counters ATIMASCA, NSUCCHPC as indicated below:

%100*ll]ATIMASCA[a

17..22] 9..14, ..6,NSUCCHPC[1 - ll]ATIMASCA[atemAssFailRaIm =

In case of ATIMASCA[all] = 0 the ImmAssFailRate is set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = ATIMASCA[all] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

SDCCHDROR=BSC:0/ QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

SDCCH Drop Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'SDCCH Drop Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'SDCCH Drop Rate' calculation formula is based on the Performance Measurement Counters NCLRREQ, TASSFAIL and NSUCCHPC as indicated below:

%100*..6]NSUCCHPC[1

,6,11]TASSFAIL[123..26] 9..21,NRCLRREQ[1 +=ateSDCCHDropR

In case of NSUCCHPC [1..6] = 0 the SDCCHDropRate is set 0.

For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = NSUCCHPC [1..6] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

SDCCHLOSR=BSC:0/ QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

SDCCH Loss Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'SDCCH Loss Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'SDCCH Loss Rate' calculation formula is based on the Performance Measurement Counters NCLRREQ, TASSFAIL and NSUCCHPC as indicated below:

%100*[1] NATTSDPE[1] ATSDCMBSateSDCCHLossR =

In case of NATTSDPE[1] = 0 the SDCCHLossRate shall be set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = NATTSDPE[1] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

SUPPER=MINUTES_5, object: QSMONBTS range: MINUTES_5 MINUTES_10 MINUTES_15 default: MINUTES_5


TCHDROR=BSC:0/ QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

TCH Drop Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'TCH Drop Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'TCH Drop Rate' calculation formula is based on the Performance Measurement Counters NCLRREQ and SUCTCHSE as indicated below

%100*,2]SUCTCHSE[1

14..18] 5..12, ..3,NRCLRREQ[1eTCHDropRat =

In case of SUCTCHSE [1,2] = 0 the TCHDropRate is set 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = SUCTCHSE [1,2] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

TCHLOSR=BSC:0/ QSTHRS:1, object: QSMONBTS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

TCH Loss Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'TCH Loss Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'TCH Loss Rate' calculation formula is based on the Performance Measurement Counters ATCHSMBS, NMSGDISQ and ATTCHSEI as indicated below:

%100*[all] ATTCHSEI

ll]NMSGDISQ[a ll]ATCHSMBS[aeTCHLossRat +=

In case of ATTCHSEU[all] = 0 the TCHLossRate shall be set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = NATTSDPE[1] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

Creating the Quality of Service Alarm Objects for PTPPKF objects: CREATE QSMONGPRS: NAME= BSC:0/QSMONGPRS:0,

Object path name.

NTWCONCRESFAIR=BSC:0/QSTHRS:2, object: QSMONBGPRS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

Network Controlled Cell Reselection Failure Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'Network Controlled Cell Reselection Failure Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'Network Controlled Cell Reselection Failure Rate' calculation formula is based on the Performance Measurement Counters UNCRORIG and ATCRORIG as follows:

%100*) ,2,3,9,10]ATCRORIG[1

[all]UNCRORIG teNCCRFailRa =

In case of ATCRORIG[1,2,3,9,10] = 0 the NCCRFailRate is set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = ATCRORIG[1,2,3,9,10]. For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

SUPPER=MINUTES_5, object: QSMONGPRS range: MINUTES_5 MINUTES_10 MINUTES_15 default: MINUTES_5


TBFDROR=BSC:0/ QSTHRS:2, object: QSMONBGPRS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

TBF Drop Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'TBF Drop Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'TBF Drop Rate' calculation formula is based on the Performance Measurement Counters UNSTETBF and SULACCEL as follows:

%100*,2]SULACCEL[1

2,13],2,10,11,1UNSTETBF[1eTBFDropRat =

In case of SULACCEL[1,2] = 0 the TBFDropRate shall be set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = SULACCEL[1,2] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

TBFLOSR=BSC:0/ QSTHRS:2, object: QSMONBGPRS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

TBF Loss Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'TBF Loss Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'TBF Loss Rate' calculation formula is based on the Performance Measurement Counters REJPDASS and NUACATCL as follows:

%100*[all] NUACATCLll]REJPDASS[aeTBFLossRat =

In case of NUACATCL[all] = 0 the TBFLossRate shall be set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = NUACATCL[all] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

TBFREAFAIR=BSC:0/ QSTHRS:2, object: QSMONBGPRS range: object path name of relevant QSTHR object instance, <NULL> default: <NULL>

TBF Reassignment Failure Rate, this parameter indicates, when its value is different from <NULL>, that the KPI 'TBF Reassignment Failure Rate' is observed for the feature 'Quality of service alarms'. The value entered for this parameter is the object path name of the threshold set (command CREATE QSTHR, see above) that is to be used for this KPI. The observed KPI 'TBF Reassignment Failure Rate' calculation formula is based on the Performance Measurement Counters NSUPRRE and NATPRRE as follows:

%100*) l]NATPRRE[al

[all] NSUPRRE1(eAssFailRatReTBF −=

In case of NATPRRE[all] = 0 the TBFReAssFailRate shall be set to 0. For this KPI the 'number of samples' value in the referenced QSTHRS object corresponds to the denominator of the calculation formula: Number of samples = NATPRRE[all] For further details concerning the involved PM counters please refer to the customer document 'PM:SBS Counter'.

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 128. The difference between IMSI tracing and the CTR feature is that IMSI tracing is IMSI related (resp. subscriber related) while CTR is cell related. For further details please refer 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. Starting from BR8.0, the CTR does not only record the messages from the TCH phase of the call but can also record the message events from the SDCCH phase (parameter TRACECH, see below). Differences in the recorded messages my arise due to the fact that the recording for IMSI tracing starts on explicit trigger messages from the MSC (MSC INVOKE TRACE), while for CTR the BSC starts the tracing itself. 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. Another difference between IMSI Tracing and CTR consists in the file structure: while for IMSI tracing one trace file only contains the traced messages related to one call only, a CTR file contains all traced calls within the traced cell. These single calls are separated later on in the framework of postprocessing (via the OTS application DUIT/RNA). The trace data recorded are temporarily stored in the BSC (see parameter CFS in command SET BSC SET BSC [CONTROL]) 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 and postprocessing. >

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 128 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=128, range: 1..128

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 128. 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=ALL, format: ALL or WEEKLY + <scheduling description> range: ALL, WEEKLY + ALL 0..0 weekly: <day_of_week> noSched 0..0 suPeriod: startHour 0..23 startMinute 0..59 stopHour 0..23 stopMinute 0..59 where <day_of_week> is equal Wednesday, Thursday, Friday Saturday

Period during the week, this parameter is mandatory and 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, format: day - month - year range: day: 1-31 month: 1-12 year: 1992 – 2099 default: 31-12-2099

Stop date, this parameter defines the stop date of the trace activities.

TRACECH=BOTH, range: TCH, SDCCH, BOTH default: TCH

Traced channel, this parameter determines whether CTR shall record a) only TCH events (starting from the ASSIGNMENT COMPLETE message, as was the case up to BR7.0) or b) only SDCCH messages or c) both messages and events on the TCH and SDCCH In case the options 'SDCCH' or 'BOTH' are selected, CTR does not only record calls, but also other SDCCH procedures such as Location Updates etc..

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

Enabling the data recording for the feature 'History on Dropped Calls': < Introduction

The feature History on Dropped Calls was introduced in BR8.0 as a new feature for the root cause analysis of dropped calls. The idea is to collect as much call processing information (and information about the radio conditions immediately before the call drop) as possible in order to allow conclusions for improvements in the affected cells. The history data of each call or transaction are permanently collected in a dedicated cyclic buffer in the BTS and, if the call is not abnormally released due to a call drop event, deleted on the release of the involved radio resources (SDCCH or TCH). However, if the call is terminated by a call drop event, the BSC requests the preservation and upload of the history data to the BSC within a special IE 'History Data Request' within the Abis RSL message RF CHANNEL RELEASE. Trigger events for History Data Saving The 'Call Drop' events which trigger the request of the history data from the BTS are the same as the ones which trigger the known call drop PM counters: • 'Number of lost radio links while using a TCH' (NRFLTCH):

a) transmission of a valid CONNECTION FAILURE INDICATION (BTS->BSC) for a TCH b) transmission of a valid ERROR INDICATION (BTS->BSC) for a TCH with the causes: - 'timer T200 expired N200+1 times' - 'unsolicited DM response, multiple frame established state' - 'sequence error' c) T8 expiry during outgoing Inter-BSC handover

• 'Unsuccessful internal handovers intracell with loss of MS' (UNIHIALC): expiry of the BSC timer T10 in the context of an internal intracell handover

• 'Unsuccessful internal handovers intercell with loss of MS' (UNIHIRLC): expiry of the BSC timer T8 in the context of an internal intercell handover

• 'Number of lost radio links while using a SDCCH (NRFLSDCC) a) transmission of a valid CONNECTION FAILURE INDICATION (BTS->BSC) for an SDCCH b) transmission of a valid ERROR INDICATION (BTS->BSC) for an SDCCH with the causes: - 'timer T200 expired N200+1 times' - 'unsolicited DM response, multiple frame established state' - 'sequence error'

• 'Total Number of Assignment Failures' (TASSFAIL, subcounters [6, 11]): transmission of an ASSIGNMENT FAILURE message (BSC->MSC) with cause 'radio Interface message failure' after expiry of T10 during TCH assignment.

History Data Saving and Upload by the BTS When a radio resource is abnormally released due to one of the aforementioned conditions, the BTS transmits the history data to the BSC in a new Abis RSL message called HISTORY REPORT. Depending on the amount of collected data, up to 4 HISTORY REPORT messages may be sent to deliver the complete set of data in segments to the BSC. A HDCTR HISTORY REPORT message consists of the following parts: 1) IE 'Dropped Channel Characteristics': This IE describes the type of channel that was dropped. 2) IE 'Channel History' This IE contains up to 4 CHANNEL HISTORY records (event



records) containing • MEASUREMENT REPORTs (or ENHANCED MEASUREMENT

REPORTs) containing - the complete information about the RXLEV and RXQUAL values in uplink and downlink for the serving cell including FULL and SUB values and relevant DTX flags - the current BS power level and MS power level - the current timing advance (TA) and timing offset - downlink RXLEV values of the GSM and 3G neighbour cells

• the number of measurement periods with skipped event records due to missing MEASUREMENT REPORT messages (see explanation below)(*)

• flags indicating the occurrence of DTAP RR channel change messages such as HANDOVER COMMAND, ASSIGNMENT COMMAND, HANDOVER FAILURE, ASSIGNMENT FAILURE.

Remark: The number of CHANNEL HISTORY records (event records) to be saved and uploaded is determined by the 'Number of requested event records' field which the BSC inserts into the 'History Data Request' IE within the RF CHANNEL RELEASE message. This field, in turn, is configurable and determined by the parameter MEASET (see below). 3) IE 'GSM 08.08 cause' This IE indicates the cause value of the last transmitted HANDOVER CONDITION INDICATION sent for the dropped call 4) IE 'Intracell Channel Change Information' This IE contains parts of the ASSIGNMENT COMMAND message - Description of the First Channel, after time - Power Command 5) IE 'Intercell Handover Information' This IE contains parts of the HANDOVER COMMAND message - Description of the First Channel, after time - Power Command - Cell Description (*) Organization of the Channel History data The CHANNEL HISTORY records (event records) within the 'Channel History' IE are organized in measurement periods (480ms SACCH periods), i.e. all event records are assigned to a particular measurement period. RR channel change messages received within a particular measurement period are indicated in the event record belonging to the measurement period (see record format below). In those periods where no MEAS REP messages has been received from the MS (called 'gap'), no event record is generated, but, instead, the last event record that contains a valid MEAS REP indicates the length of the 'gap' by the number of subsequent measurement periods without valid MEAS REP message. As also the RR channel change messages received during measurement periods without valid MEAS REP have to be assigned to the existing measurement periods/event records, the following approach is used: The events - INTRACELL / INTERCELL HANDOVER CONDITION INDICATION message sent - ASSIGNMENT COMMAND received - HANDOVER COMMAND received are indicated in the last event record before the gap. The events - HANDOVER FAILURE message received - ASSIGNMENT FAILURE message received are indicated in the first event record after the gap.



The 'Channel History ' IE has the following format:

When the last part of the HDCTR event records have been transmitted, the BTS closes down the radio resource by the message RF CHANNEL RELEASE ACKNOWLEDGE.

In the BSC, the history data are extracted from the received messages, extended by additional addressing data about the affected radio resource (BTS, TRX), adjacent cell data and the type of call drop that occurred and finally formatted to a complete HDCTR record which is subsequently stored on the BSC disk in the HDCTR logfile.

The complete HDCTR record file has the following format

BTS BSC

RF CHANNEL RELEASE with IE ‘History data request’

HISTORY REPORT (part 1)

call drop occurred . . .

HISTORY REPORT (part n)

.

.

RF CHAN RELEASE ACK

Message Header

First event record

nth event record

Indication for length of the subsequent mesaurement ’gap’ (if

t)

Flags indicating presence of RR channel change messages.



Activation and enabling of the feature HDCTR The feature must be generally enabled in the BSC by using the command CREATE HDCTR. In addition, the feature must be enabled per cell in the BTS object. This is done by the parameter EHDCTR in command CREATE/SET BTS [BASICS].

HDCTR file management in BSC and upload to RC When the HDCTR logfile has reached the file size determined by the parameter HDCFS (see command SET BSC [CONTROL]), it is compressed and uploaded towards the RC for further processing within the Operator Tool Set (OTS), namely the application DUIT/RNA, which is also used for the postprocessing of IMSI traces, CTR traces etc.. Upload scheduling is controlled by the parameter HDCFUPE see command SET BSC [CONTROL]).>

HDCTR File Header

Addressing data of affected channel object (BTS, TRX)

HDCTR event records as received from BTS

Adjacent cell description data

Call drop cause

Number of call drops that could not be traced due to buffer overflow in the BSC (happens only if too many call drops (max. 64) occur at the same time, value should be always ‘0’).

nth complete HDCTR record

First complete HDCTR record

CREATE HDCTR: NAME=BSC:0/ HDCTR:0,

Object path name.

MEASET=16, range: 1..16

Measurement Sets, this parameter defines the number of CHANNEL HISTORY records (event records) that shall be saved and uploaded by the BTS in the HISTORY REPORT message set of dropped calls. The BSC inserts the entered value is into the 'Number of requested event records' field within the 'History Data Request' IE within the RF CHANNEL RELEASE message.

PERWEEK=ALL, format: ALL or WEEKLY + <scheduling description> range: ALL, WEEKLY + ALL 0..0 weekly: <day_of_week> noSched 0..0 suPeriod: startHour 0..23 startMinute 0..59 stopHour 0..23 stopMinute 0..59 where <day_of_week> is equal to: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday saturday

Period during the week, this parameter is mandatory and defines the periods during which the HDCTR 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 date, this parameter defines the start date of the HDCTR trace activities.


Stop date, this parameter defines the stop date of the HDCTR trace activities.



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. For further details please refer to the descriptions provided at the top of the command description.

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. For further details please refer to the descriptions provided at the top of the command description.

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. For further details please refer to the descriptions provided at the top of the command description.

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 date, this parameter defines the start date of the data collection activities.


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 the kind of measurement 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..59range: 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 date, this parameter defines the start date of the data collection activities.


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/Inter-system Handover due to level 2.1.2.1.1 Handover Decision / Handover Trigger Conditions An Inter-cell-handover due to level is triggered by the BTS if all of the following conditions are fulfilled:

1. RXLEV_XX < L_RXLEV_XX_H XX = DL or UL

RXLEV_XX = received level average of the serving cell (the averaging is done according to the setting of HOAVLEV (SET HAND)) L_RXLEV_XX_H = HOLTHLVXX (SET HAND) = lower threshold value for level handover

→ The received level average of the serving cell is lower than the value set for HOLTHLVXX.

2. RXQUAL_XX < L_RXQUAL_XX_H XX = DL or UL

RXQUAL_XX = received quality (i.e. bit error rate) average of the serving cell (the averaging is done according to the setting of HOAVQUAL (SET HAND)) L_RXQUAL_XX_H = HOLTHQUXX (SET HAND) = lower threshold value for quality handover

→ The received quality (i.e. bit error rate) average of the serving cell is lower than the 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(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 2G neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause 'uplink strength' or 'downlink strength' if it fulfil the handover minimum condition

4. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa)

where Pa = MS_TXPWR_MAX(n) - P

For 2G-3G adjacent cell relations the handover minimum condition depends on the type of quantity which is selected for 3G neighbour cell reporting by parameter FDDREPQTY (see command CREATE BTS [BASICS]): a) If FDDREPQTY=RSCP, the minimum criterion is based on the RSCP threshold RXLEVMINC b) If FDDREPQTY=EC_NO, the minimum criterion is based on the Ec/No threshold UMECNO Thus a 3G neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the BWHCI with cause 'uplink strength' or 'downlink strength' if it fulfils the handover minimum condition

Case a) FDDREPQTY=RSCP

4. RXLEV_NCELL(n) > RXLEVMINC(n) + Max(0, Pa)

Case b) FDDREPQTY=EC_NO

4. RXLEV_NCELL(n) > UMTS_MIN_ECNO(n) + Max(0, Pa)


RXLEV_NCELL(n) = received DL RXLEV average of 2G neighbour cell (n) or DL RSCP (if FDDREPQTY=RSCP) average of 3G neighbour cell (n) or DL Ec/No (if FDDREPQTY=EC_NO) average of 3G neighbour cell (n) *

RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) RXLEVMINC(n) = RXLEVMINC (CREATE ADJC3G) = min. RSCP value of the 3G neighbour cell (n) UMTS_MIN_ECNO(n)= UMECNO (CREATE ADJC3G) = min. Ec/No value of the 3G neighbour cell (n) MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or MSTXPMAXUMTS (TGTFDD object), value in [dBm]

= max. allowed transmit power in neighbour cell (n)P = power capability of the mobile in [dBm]Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

→ The actual average of the reported quantity of the neighbour cell (RXLEV for 2G neighbour, RSCP or Ec/No for 3G neighbour) must be higher than the sum of the minimum threshold set for the neighbour cell and the correction term Max(0,Pa).

* Remarks: 1) For 'imperative handover', 3G neighbour cells are considered (and reported) only if EUHO=TRUE and

EUIMPHO=TRUE (see command SET HAND [BASICS]). For the reporting of the RSCP levels, please consider the explanations in section 'Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells'.

2) The BTS adds a 3G target cell to the BWHCI only if the IE 'Service Handover' (included in the CHANNEL ACTIVATION or FORCED HANDOVER REQUEST message) is set to a value different from 'Handover to neither UTRAN nor cdma2000 shall not be performed'.

3) The averaging of both RXLEV_DL values (2G neighbour cells) as well as RSCP values (3G neighbour cells) is done with an averaging window whose length is defined by parameter HOAVPWRB (SET HAND)



Optional feature 'Level Handover Margin for Level Handover' If the optional feature 'Level Handover Margin' is enabled (SET HAND:ELEVHOM=TRUE), the following additional condition must be fulfilled for 2G neighbour cells:

5. RXLEV_NCELL > RXLEV_DL + LEVHOM(n)

LEVHOM(n) = LEVHOM (CREATE ADJC) = level handover margin of the neighbour cell (n) in [dB]RXLEV_NCELL(n) = received DL RXLEV or DL RSCP average of the neighbour cell (n) RXLEV_DL = received level average downlink of the serving cell → The receive level average of the neighbour cell must be higher than the receive level average of

the serving cell plus the level handover margin set for the neighbour cell

2.1.2.1.3 Target Cell Ranking (HCS disabled) 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).

If the feature Hierarchical Cell Structure (HCS) is disabled (parameter HIERC=FALSE in command SET HAND [BASICS]), the sorting of the 2G and 3G target cells is done as follows: For 2G target cells, the sorting is always done based on the PRIO_PBGT criterion (for details see below). For 3G target cells, the sorting within the target cell list depends on the type of quantity which is selected for 3G neighbour cell reporting by parameter FDDREPQTY (see command CREATE BTS [BASICS]):

A) If FDDREPQTY=RSCP, 3G FDD cells and 2G cells are listed within separate 'sub-list' - in both lists, the sorting is done based on the criterion PRIO_PBGT. B) If FDDREPQTY=EC_NO, 3G FDD cells and 2G cells are listed within separate 'sub-list' - in the 2G sublist, the sorting is done based on the criterion PRIO_PBGT, in the 3G sublist, sorting is done based on Ec/No.

Case A): FDDREPQTY=RSCP Within the INTERCELL HANDOVER CONDITION INDICATION the 2G and 3G target cells included are sorted in two separate sublists, one sublist containing 2G cells and other one for 3G cells. Within each sublist, the cells are sorted in descending order of the criterion 'PRIO_PBGT' (power budget priority), which is calculated as follows:

For 2G cells, the PRIO_PBGT is calculated by:

PRIO_PBGT = PBGT(n) – HO_MARGIN(n)

PBGT (n) = power budget of the neighbour cell (n), see section 2.1.2.5 HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) in [dB]

For 3G cells, the PRIO_PBGT is calculated by:

PRIO_PBGT = PBGT(n) – HO_MARGIN(n) - UMTS_ADJUST(n)

PBGT (n) = power budget of the neighbour cell (n), see section 2.1.2.5 HO_MARGIN(n) = HOM (CREATE ADJC3G) = handover margin of the neighbour cell (n) in [dB] UMTS_ADJUST(n) = UADJ (ADJC3G) = UMTS adjust parameter of neighbour cell (n) in [dB]

For more detailed information about PBGT(n) please refer to section 2.1.2.5 (power budget handover).



Effects of 'Service Handover' Setting: Depending on the value of the IE 'Service Handover' which is originally sent from 3G MSC to BSC within the ASSIGNMENT REQUEST and HANDOVER REQUEST messages and forwarded to the BTS within the CHANNEL ACTIVATION (and, if applicable, FORCED HANDOVER REQUEST messages), either the 2G sublist or the 3G sublist is ranked at the top of the target cell list.

1. The IE 'Service Handover' is set to 'Handover to neither UTRAN nor cdma2000 should not be performed' in the abovementioned messages or this IE is missing in the mentioned A-Interface (and thus also in the Abis-interface) messages. The purpose of this setting is to keep the calls in the 2G network as long as possible.

2. The IE 'Service Handover' is set to 'Handover to either UTRAN or cdma2000 should be performed' in the abovementioned messages. The purpose of this setting is to hand over the calls to the 3G network as early as possible.

1. If the IE 'Service Handover' is set to 'Handover to neither UTRAN nor cdma2000 should not be

performed' in the abovementioned messages or if this IE is missing in the mentioned A-Interface (and thus also in the Abis-interface) messages, the 2G sublist is ranked at the top of the target cell list.

Inter-cell HCI:

target cell list

2G target cells are sorted 1. 2G neighbour cell in descending order of ... 2G neighbour cell

PRIO_PBGT(n) n. 2G neighbour cell 3G target cells are sorted 1. 3G neighbour cell

in descending order of ... 3G neighbour cell PRIO_PBGT(n) ... 3G neighbour cell

n. 3G neighbour cell

2. The IE 'Service Handover' is set to 'Handover to either UTRAN or cdma2000 should be performed'

in the mentioned A-Interface (and thus also in the Abis-interface) messages, the 3G sublist is ranked at the top of the target cell list.

.

Inter-cell HCI: target cell list



in descending order of ... 2G neighbour cell PRIO_PBGT(n) n. 2G neighbour cell


This means that the ranking algorithm considers the DL receive level of the neighbour cell (RXLEV for 2G cells and RSCP for 3G cells) as well as the configured power budget handover margin and, for 3G neighbour cells, additionally the UMTS adjustment parameter.

Remark: If the IE 'Service Handover' is set to 'Handover to either UTRAN or cdma2000 shall not be performed' in the CHANNEL ACTIVATION message, no 3G target cells are included in the target cell list at all!



Case B): FDDREPQTY=EC_NO While the 2G cells are still sorted in descending order of PRIO_PBGT, with this setting the 3G cells are sorted in descending order of Ec/No (as PRIO_PBGT cannot be calculated from the reported Ec/No value).

Effects of 'Service Handover' Setting: Depending on the value of the IE 'Service Handover' which is originally sent from 3G MSC to BSC within the ASSIGNMENT REQUEST and HANDOVER REQUEST messages and forwarded to the BTS within the CHANNEL ACTIVATION (and, if applicable, FORCED HANDOVER REQUEST messages), either the 2G sublist or the 3G sublist is ranked at the top of the target cell list.

Case 1: 'Service Handover' = 'Handover to neither UTRAN nor cdma2000 should not be performed' or the IE is missing.

- 2G target cells are included in the first sublist in the INTERCELL HANDOVER CONDITION INDICATION and are sorted in descending order of PRIO_PBGT(n) in correspondence with the calculation formula above. - 3G FDD target cells are included in the second sublist in the INTERCELL HANDOVER CONDITION INDICATION are sorted in descending order of Ec/No.




in descending order of ... 3G neighbour cell Ec/No(n) ... 3G neighbour cell


Case 2: 'Service Handover' = 'Handover to neither UTRAN nor cdma2000 should be performed' - 3G FDD target cells are included in the first sublist in the INTERCELL HANDOVER CONDITION INDICATION are sorted in descending order of Ec/No. - 2G target cells are included in the second sublist in the INTERCELL HANDOVER CONDITION INDICATION and are sorted in descending order of PRIO_PBGT(n) in correspondence with the calculation formula above.



Ec/No(n) n. 3G neighbour cell 2G target cells are sorted 1. 2G neighbour cell

in descending order of ... 2G neighbour cell PRIO_PBGT(n) ... 2G neighbour cell


Remark: If the IE 'Service Handover' is set to 'Handover to either UTRAN or cdma2000 shall not be performed' in the CHANNEL ACTIVATION message, no 3G target cells are included in the target cell list at all!



2.1.2.1.4 Target Cell Ranking with HCS If the feature Hierarchical Cell Structure (HCS) is enabled (see parameter HIERC in command SET HAND [BASICS]), the sorting of the 2G and 3G target cells is done considering the HCS priority parameters (parameter PLNC in ADJC and ADJC3G objects) as described in detail below. Also with HCS enabled, 2G target cells and 3G target cells are managed in separate sublists. Which of the sublists (2G or 3G) is ranked at the top, again depends on the setting of the 'Service Handover' IE (see descriptions in previous sections). Within the 2G and 3G sublists, the sorting is done as follows: - For 3G target cells, the sorting is determined by the priority level allocated to the 3G neighbour cell (parameter PLNC in ADJC3G object). - For 2G target cells, the sorting is determined by the 'Hierarchical Cell Ranking Flag' (parameter HIERF, see command SET HAND [BASICS]) which defines the ranking method (ranking method 0 or 1, details see below). The ranking method in turn considers both the HCS priority levels as well as the level conditions of the neighbour cell.

2.1.2.1.4.1 Ranking of 3G target cells within 3G sublist If HCS is enabled, for 'imperative' handovers the ranking of 3G target cells within the target cell sublist is simply done on the basis of the priority levels only, i.e. it is done in descending order of priority level as defined by parameter PLNC (ADJC3G).

priority

Inter-cell HCI: 3G target cell sublist

0 1. 3G neighbour cell 3G target cells are 2. 3G neighbour cell

sorted in descending order ... 3G neighbour cell of priority level ... 3G neighbour cell

15 n. 3G neighbour cell

Attention: The lower the value of the parameter PLNC, the higher the priority level! 0 = highest priority level, 15 = lowest priority level.

2.1.2.1.4.2 Ranking of 2G target cells within 2G sublist - 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 ranking of 2G target cells is done in the following way:

The cells in the 2G target cell sublist are subdivided into two further sublists:

1. The upper sublist consists of all cells with PBGT(n) - HO_MARGIN(n) > 0

2. The lower sublist consists of all cells with

PBGT(n) - HO_MARGIN(n) ≤ 0

where PBGT(n) = RXLEV_NCELL(n) - (RXLEV_DL + PWR_C_D) +Min(MS_TXPWR_MAX, P) - Min(MS_TXPWR_MAX(n),P(n))

PBGT (n) = power budget of the neighbour cell (n) HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) in [dB] RXLEV_NCELL(n) = received DL RXLEV average of the 2G 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 Control Note: In this case PWR_C_D = 0 since Power Control is disabled. MS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) value of the

serving cell (see CREATE BTS [BASICS]) in dBm = max. allowed transmit power of serving cell (n)

MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] = max. allowed transmit power in neighbour cell (n)

P = power capability of the mobile in the serving cell [dBm] P(n) = power capability of the mobile in the neighbour cell n [dBm]Min(MS_TXPWR_MAX,P) = MS_TXPWR_MAX if MS_TXPWR_MAX P

→ The power budget of the neighbour cell must be higher than the handover margin set for the neighbour cell

3. Within each sublist the cells in the target cell list HANDOVER CONDITION INDICATION are ordered according to their priority.

Cells with the same priority level are ordered according to the value of PBGT(n) - HO_MARGIN(n).

priority Inter-cell HCI: 2G target cell sublist

0 1. 2G neighbour cell upper sublist: 2. 2G neighbour cell PBGT - HO_MARGIN > 0 3. 2G neighbour cell ... 15 ... 0 n. 2G neighbour cell lower sublist: n+1. 2G neighbour cell PBGT - HO_MARGIN ≤ 0 n+2. 2G neighbour cell ... 15 ...

2.1.2.1.4.3 Ranking of 2G target cells within 2G sublist - 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 ranking of 2G target cells is done in the following way:

The cells in the 2G target cell sublist are subdivided into two further 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 DL RXLEV average of the neighbour cell (n) RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) or

= RXLEVMINC (CREATE ADJC3G) = min. RSCP value of the 3G neighbour cell (n) MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or

MSTXPMAXUMTS (TGTFDD object), value in [dBm] = max. allowed transmit power in neighbour cell (n)

P = power capability of the mobile in [dBm] Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0 LEVONC(n) = LEVONC (CREATE ADJC) = level offset of neighbour cell for ranking method 1 or = LEVONC (CREATE ADJC3G) = level offset of neighbour 3G cell for ranking method 1

3. Within each sublist the cells in the target cell list HANDOVER CONDITION INDICATION are ordered according to their priority.

Cells with the same priority level are ordered according to the value of PBGT(n) - HO_MARGIN(n).

priority Inter-cell HCI: 2G target cell sublist

upper sublist: 0 1. 2G neighbour cell RXLEV_NCELL(n) > 2. 2G neighbour cell RXLEVMIN(n) + Max(0,Pa) 3. 2G neighbour cell + LEVONC(n) 4. 2G neighbour cell 15 5. 2G neighbour cell lower sublist: 0 ... RXLEV_NCELL(n) ≤ ... RXLEVMIN(n) + Max(0,Pa) ... + LEVONC(n) ... 15 ...



2.1.2.1.4. Resulting ranking of 2G and 3G target cells and sublists As explained above, for 'imperative' handover with HCS, 2G and 3G target cells are sorted in separate sublists, the sequence of which is determined by the 'Service handover' IE.

Within the sublists, the sorting is done based on - the priority level (for the 3G target cells) - the priority level, the reported receive level and the configured 'ranking method'

So the following 4 cases have to be distinguished:

Case 1: 'Service Handover' = 'Handover to neither UTRAN nor cdma2000 should not be performed' or the IE is missing and HIERF=RANK0.

priority


2G upper sublist: 0 1. 2G neighbour cell PBGT - HO_MARGIN > 0 .. 2. 2G neighbour cell sorted in descending order .. ... 2G neighbour cell of priority level 15 ... 2G neighbour cell 2G lower sublist: 0 ... 2G neighbour cell PBGT - HO_MARGIN ≤ 0 ... ... 2G neighbour cell sorted in descending order ... ... 2G neighbour cell of priority level 15 n. 2G neighbour cell 3G sublist: 0 1. 3G neighbour cell sorted in descending order .. 2. 3G neighbour cell of priority level .. ... 2G neighbour cell 15 n. 3G neighbour cell

Case 2: 'Service Handover' = 'Handover to neither UTRAN nor cdma2000 should not be performed' or

the IE is missing and HIERF=RANK1.

priority


2G upper sublist: 0 1. 2G neighbour cell RXLEV_NCELL(n)>RXLEVMIN(n)+Max(0,Pa)+LEVONC(n) .. 2. 2G neighbour cell sorted in descending order .. ... 2G neighbour cell of priority level 15 ... 2G neighbour cell 2G lower sublist: 0 ... 2G neighbour cell RXLEV_NCELL(n)≤RXLEVMIN(n)+Max(0,Pa)+LEVONC(n) ... ... 2G neighbour cell sorted in descending order ... ... 2G neighbour cell of priority level 15 n. 2G neighbour cell 3G sublist: 0 1. 3G neighbour cell sorted in descending order .. 2. 3G neighbour cell of priority level .. ... 3G neighbour cell 15 n. 3G neighbour cell



Case 3: 'Service Handover' = 'Handover to neither UTRAN nor cdma2000 should be performed' and HIERF=RANK0.

priority


3G sublist: 0 1. 3G neighbour cell sorted in descending order .. 2. 3G neighbour cell of priority level .. ... 15 n. 3G neighbour cell 2G upper sublist: 0 1. 2G neighbour cell PBGT - HO_MARGIN > 0 .. 2. 2G neighbour cell sorted in descending order .. ... 2G neighbour cell of priority level 15 ... 2G neighbour cell 2G lower sublist: 0 ... 2G neighbour cell PBGT - HO_MARGIN ≤ 0 ... ... 2G neighbour cell sorted in descending order ... ... 2G neighbour cell of priority level 15 n. 2G neighbour cell

Case 4: 'Service Handover' = 'Handover to neither UTRAN nor cdma2000 should be performed'

and HIERF=RANK1.

priority Inter-cell HCI: target cell list

3G sublist: 0 1. 3G neighbour cell sorted in descending order .. 2. 3G neighbour cell of priority level .. ... 15 n. 3G neighbour cell 2G upper sublist: 0 1. 2G neighbour cell RXLEV_NCELL(n)>RXLEVMIN(n)+Max(0,Pa)+LEVONC(n) .. 2. 2G neighbour cell sorted in descending order .. ... 2G neighbour cell of priority level 15 ... 2G neighbour cell 2G lower sublist: 0 ... 2G neighbour cell RXLEV_NCELL(n)≤RXLEVMIN(n)+Max(0,Pa)+LEVONC(n) ... ... 2G neighbour cell sorted in descending order ... ... 2G neighbour cell of priority level 15 n. 2G neighbour cell

2.1.2.2 Intra-cell handover (quality) An Intra-cell handover (quality) is triggered by the BTS if all of the following conditions are fulfilled:

1. RXQUAL_XX > L_RXQUAL_XX_H XX = DL or UL


→ The 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 (incl. Power Control)* (the averaging is done according to the setting of HOAVLEV (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/Inter-system Handover due to quality 2.1.2.3.1 Handover Decision / Handover Trigger Conditions An Inter-cell handover (quality) is triggered by the BTS if all of the following conditions are fulfilled:

1. RXQUAL_XX > L_RXQUAL_XX_H XX = DL or UL


→ The 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 HOAVLEV (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)P = power capability of the mobile in [dBm]Min(YY_TXPWR_MAX,P) = YY_TXPWR_MAX 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)



2.1.2.3.2 Target Cell List Generation A 2G 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



For 2G-3G adjacent cell relations the handover minimum condition depends on the type of quantity which is selected for 3G neighbour cell reporting by parameter FDDREPQTY (see command CREATE BTS [BASICS]): a) If FDDREPQTY=RSCP, the minimum criterion is based on the RSCP threshold RXLEVMINC b) If FDDREPQTY=EC_NO, the minimum criterion is based on the Ec/No threshold UMECNO Thus a 3G neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the BWHCI with cause 'uplink quality' or 'downlink quality' if it fulfils the handover minimum condition
















Optional feature 'Level Handover Margin for Quality Handover' If the optional feature 'Level Handover Margin for Quality Handover' is enabled (SET HAND: ENAQUALEVHOM=TRUE), the following additional condition must be fulfilled for 2G neighbour cells:

5. RXLEV_NCELL > RXLEV-DL + QUALLEVHOM(n)

QUALLEVHOM(n) = QUALLEVHOM (CREATE ADJC) = quality level handover margin of the neighbour cell (n) in [dB] RXLEV_NCELL(n) = received DL RXLEV or DL RSCP average of the neighbour cell (n) RXLEV_DL = received level average downlink of the serving cell → The receive level average of the neighbour cell must be higher than the receive level average of the serving cell plus the level handover margin set for the neighbour cell

2.1.2.3.3 Target Cell Ranking (HCS disabled) If the feature Hierarchical Cell Structure (HCS) is disabled (parameter HIERC=FALSE in command SET HAND [BASICS]), the sorting of 2G and 3G target cells within the target cell list is done in exactly the same way as described for intercell handover due to level (see section 2.1.3.1.3).

2.1.2.3.4 Target Cell Ranking with HCS If the feature Hierarchical Cell Structure (HCS) is enabled (see parameter HIERC=TRUE in command SET HAND [BASICS]), the sorting of 2G and 3G target cells within the target cell list is done in exactly the same way as described for intercell handover due to level (see section 2.1.3.1.4).



2.1.2.4 Inter-cell/Inter-system Handover due to distance 2.1.2.4.1 Handover Decision / Handover Trigger Conditions An Inter-cell handover (distance) is triggered by the BTS if the following condition is fulfilled:

1. MS_BS_DIST > MS_RANGE_MAX

MS_BS_DIST = actual distance between MS and BTS MS_RANGE_MAX = HOTMSRM (SET HAND) = maximum distance between MS and BTS (standard cells) = HOTMSRME (SET HAND) = max. distance between MS and BTS (for extended cells)

→ The actual distance between MS and BTS is bigger than the value set for HOTMSRM (for standard cells) respectively HOTMSRME (for extended cells

2.1.2.4.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 'distance' if it fulfils the handover minimum condition



For 2G-3G adjacent cell relations the handover minimum condition depends on the type of quantity which is selected for 3G neighbour cell reporting by parameter FDDREPQTY (see command CREATE BTS [BASICS]): a) If FDDREPQTY=RSCP, the minimum criterion is based on the RSCP threshold RXLEVMINC b) If FDDREPQTY=EC_NO, the minimum criterion is based on the Ec/No threshold UMECNO Thus a 3G neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the BWHCI with cause 'distance' if it fulfils the handover minimum condition

















2.1.2.4.4 Target Cell Ranking with HCS If the feature Hierarchical Cell Structure (HCS) is enabled (parameter HIERC=TRUE in command SET HAND [BASICS]), the sorting of 2G and 3G target cells within the target cell list is done in exactly the same way as described for intercell handover due to level (see section 2.1.3.1.4).

2.1.2.5 Inter-cell/Inter-system Handover due to better cell (power budget handover) 2.1.2.5.1 Handover Decision / Handover Trigger Conditions 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) (for 2G-2G adjacent cell relations) or

1. PBGT(n) > HO_MARGIN_3G(n) + UMTS_ADJUST(n) (for 2G-3G adjacent cell relations)

where PBGT(n) = RXLEV_NCELL(n) - (RXLEV_DL + PWR_C_D) +Min (MS_TXPWR_MAX, P) - Min (MS_TXPWR_MAX(n), P(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] HO_MARGIN_3G(n) = HOM (CREATE ADJC3G) = handover margin of the 3G neighbour cell (n) in [dB] UMTS_ADJUST(n) = UADJ (CREATE ADJC3G) = UMTS adjustment offset of the 3G neighbour cell (n) in [dB] RXLEV_NCELL(n) = received DL RXLEV (2G) or DL RSCP (3G) average of the neighbour cell (n)* RXLEV_DL = received level average downlink of the serving cell (averaging is done according to the setting of HOAVPWRB (SET HAND) PWR_C_D = BS_TXPWR_MAX - BS_TXPWR = dynamic power reduction, i.e. averaged difference between the maximum downlink RF power and the actual downlink power due to Power Control MS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) value of the serving cell (see CREATE BTS [BASICS]) in dBm = max. allowed transmit power of serving cell (n) MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or

MSTXPMAXUMTS (TGTFDD object), value in [dBm] = max. allowed transmit power in neighbour cell (n) P = power capability of the mobile in the serving cell [dBm]P(n) = power capability of the mobile in the neighbour cell n [dBm]Min(MS_TXPWR_MAX,P) = MS_TXPWR_MAX if MS_TXPWR_MAX P → The power budget of the neighbour cell must be higher than the handover margin set for the neighbour cell

* Remarks: 1) For 2G-3G 'better cell' handover, 3G neighbour cells are considered (and reported) only if EUHO=TRUE

and EUBCHO=TRUE (see command SET HAND [BASICS]). For the reporting of the RSCP levels, please consider the explanations in section 'Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells'.



Important note for Dualband handovers (GSM->DCS or DCS-> GSM): In case of dualband handovers the parameterization of the Handover Margin (HOM) has to be handled 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)



2.1.2.5.2 Target Cell List Generation (HCS disabled) If the feature Hierarchical Cell Structure (HCS) is disabled (HIERC=FALSE, see command SET HAND [BASICS]), a 2G 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



As opposed to 'imperative' handovers, for 'better cell' handover only the setting FDDREPQTY=RSCP is allowed as reporting quantity for 3G cells (Ec/No is a quality value and cannot be compared to the RXLEV values reported for 2G neighbour cells, therefore a comparison between 2G and 3G cells is not possible) . Thus, for 2G-3G adjacent cell relations, the handover minimum criterion is based on the RSCP threshold RXLEVMINC: a 3G neighbour cell is regarded as a suitable target cell and is thus inserted into the target cell list of the BWHCI with cause 'better cell' if it fulfils the handover minimum condition



RXLEV_NCELL(n) = received DL RXLEV or DL RSCP average of the neighbour cell (n) * RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) RXLEVMINC(n) = RXLEVMINC (CREATE ADJC3G) = min. RSCP value of the 3G neighbour cell (n) MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or MSTXPMAXUMTS (TGTFDD object), value in [dBm]









2.1.2.5.3 Target Cell Ranking (HCS disabled) 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).

If the feature Hierarchical Cell Structure (HCS) is disabled (HIERC=FALSE, see command SET HAND [BASICS]), the 2G and 3G target cells included in the INTERCELL HANDOVER CONDITION INDICATION are sorted in a mixed manner in descending order of the so-called PRIO_PBGT (power budget priority).


1. 2G/3G neighbour cell Target cells are 2. 2G/3G neighbour cell sorted in descending 3. 2G/3G neighbour cell order of 4. 2G/3G neighbour cell PRIO_PBGT(n) 5. 2G/3G neighbour cell

... ...

For 2G cells, the PRIO_PBGT is calculated as follows:

PRIO_PBGT = PBGT(n) – HO_MARGIN(n)

PBGT (n) = power budget of the neighbour cell (n), see section 2.1.2.5 HO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) in [dB]

For 3G cells, the PRIO_PBGT is calculated as follows:

PRIO_PBGT = PBGT(n) – HO_MARGIN(n) - UMTS_ADJUST(n)

PBGT (n) = power budget of the neighbour cell (n), see section 2.1.2.5 HO_MARGIN(n) = HOM (CREATE ADJC3G) = handover margin of the neighbour cell (n) in [dB] UMTS_ADJUST(n) = UADJ (CREATE ADJC3G) = UMTS adjustment offset of the 3G neighbour cell (n) in [dB] This means that the ranking algorithm considers the DL receive level of the neighbour cell as well as the power budget handover margin and, for 3G neighbour cells, the UMTS adjustment parameter. 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.5.3.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

1. PBGT(n) > HO_MARGIN(n)

but

1.* PBGT(n) > HO_MARGIN_TIME(n)

whereHO_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

whereHO_MARGIN(n) = HOM (CREATE ADJC) = handover margin of the neighbour cell (n) or HOM (CREATE ADJC3G) = handover margin of 3G neighbour cell (n) in [dB] HO_STATIC_OFFSET(n) = HOMSOFF (CREATE ADJC) = handover static offset of the neighbour cell (n)

or HOMSOFF (CREATE ADJC) = handover static offset of 3G neighbour cell (n) HO_DYNAMIC_OFFSET(n)= HOMDOFF (CREATE ADJC) = handover dynamic offset of the neighbr. cell (n)

or HOMDOFF (CREATE ADJC) = handover dynamic offset of 3G neighbour 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 timerstart of timer*

2.1.2.5.4 Handover Initiation and Target Cell List Generation with HCS If the feature Hierarchical Cell Structure (HCS) is enabled (HIERC=TRUE, see command SET HAND [BASICS]), 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) (for 2G-2G adjacent cell relations) or

1. RXLEV_NCELL(n) > RXLEVMINC(n) + Max(0,Pa) (for 2G-3G adjacent cell relations)where Pa = MS_TXPWR_MAX(n) - P

RXLEV_NCELL(n) = received DL RXLEV (2G) or DL RSCP (3G) average of the neighbour cell (n) * RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) RXLEVMINC(n) = RXLEVMINC (CREATE ADJC3G) = min. RSCP value of the 3G neighbour cell (n) MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] = max. allowed transmit power in neighbour cell (n)P = power capability of the mobile in [dBm]Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

and

2. PBGT(n) > HO_MARGIN(n) (for 2G-2G adjacent cell relations) or

2. PBGT(n) > HO_MARGIN_3G(n) + UMTS_ADJUST(n) (for 2G-3G adjacent cell relations)

where PBGT(n) = RXLEV_NCELL(n) - (RXLEV_DL + PWR_C_D) +Min (MS_TXPWR_MAX, P) - Min (MS_TXPWR_MAX(n), P(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] HO_MARGIN_3G(n) = HOM (CREATE ADJC3G) = handover margin of the 3G neighbour cell (n) in [dB] UMTS_ADJUST(n) = UADJ (CREATE ADJC3G) = UMTS adjustment offset of the 3G neighbour cell (n) in [dB] RXLEV_NCELL(n) = received DL RXLEV or DL RSCP average of the neighbour cell (n)* RXLEV_DL = received level average downlink of the serving cell (averaging is done according to the setting of HOAVPWRB (SET HAND) PWR_C_D = BS_TXPWR_MAX - BS_TXPWR = dynamic power reduction, i.e. averaged difference between the maximum downlink RF power and the actual downlink power due to Power Control MS_TXPWR_MAX = MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) value of the serving cell (see CREATE BTS [BASICS]) in dBm = max. allowed transmit power of serving cell (n) MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or


P = power capability of the mobile in the serving cell [dBm] P(n) = power capability of the mobile in the neighbour cell n [dBm]Min(MS_TXPWR_MAX,P) = MS_TXPWR_MAX if MS_TXPWR_MAX P * Remarks: 1) For 'better cell' handover, 3G neighbour cells are considered (and reported) only if EUHO=TRUE and

EUBCHO=TRUE (see command SET HAND [BASICS]). For the reporting of the RSCP levels, please consider the explanations in section 'Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells'.

2) The BTS adds a 3G target cell to the BWHCI for 'better cell' handover only if the IE 'Service Handover' (included in the CHANNEL ACTIVATION or FORCED HANDOVER REQUEST message) is set to the value 'Handover to neither UTRAN nor cdma2000 should be performed'.

3) The averaging of both RXLEV_DL values (2G neighbour cells) as well as RSCP values (3G neighbour cells) is done with an averaging window whose length is defined by parameter HOAVPWRB (see command SET HAND [BASICS]).



and

3. PRIO_NCELL(n) ≤ PRIO_SCELL

PRIO_NCELL = PLNC (CREATE ADJC/ADJC3G) = priority layer assigned to the (3G) neighbour cell = PPLNC (CREATE ADJC/ADJC3G) = penalized priority layer assigned to

the (3G) neighbour cell (relevant only if speed sensitive handover is enabled) PRIO_SCELL = PL (SET HAND) = priority layer assigned to the serving cell

2.1.2.5.5 Target Cell Ranking with HCS If the feature Hierarchical Cell Structure (HCS) is enabled (HIERC=TRUE, see command SET HAND [BASICS]), the 2G and 3G cells in the target cell list of the HANDOVER CONDITION INDICATION message are sorted in a mixed manner according to their priority (not according to PRIO_PBGT!).


0 1. 2G/3G neighbour cell 2. 2G/3G neighbour cell 3. 2G/3G neighbour cell 4. 2G/3G neighbour cell 5. 2G/3G neighbour cell ... 15 ...

Target cells (2G or 3G) with the same priority level are ordered according to the value of PBGT(n) - HO_MARGIN(n).

2.1.2.5.6 Speed sensitive handover enabled Precondition: speed sensitive handover is enabled for the cell (SET HAND:DPBGTHO=TRUE).

For those neighbour cells for which speed sensitive handover is enabled (CREATE ADJC/CREATE ADJC3G:MICROCELL=TRUE) the power budget handover decision algorithm 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. After expiry of HOMDTIME PPLNC is again replaced by PLNC. For details please refer to the parameter description for the parameters PLNC, PPLNC and HOMDTIME in the command CREATE ADJC/CREATE ADJC3G and to section 2.1.2.5.1 (Power Budget Handover / Speed sensitive handover).

.

2.1.2.6 Inter-system Handover due to sufficient coverage 2.1.2.6.1 Handover Decision / Handover Trigger Conditions & Target Cell List Generation An inter-system handover due to sufficient UMTS coverage can be triggered based on two different criterions, depending on the type quantity which is selected for 3G neighbour cell reporting by parameter FDDREPQTY (see command CREATE BTS [BASICS]): a) If FDDREPQTY=RSCP, the 'sufficient coverage' criterion is based on the RSCP threshold USRSCP b) If FDDREPQTY=EC_NO, the 'sufficient coverage' criterion is based on the Ec/No threshold USECNO

A 3G 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 'sufficient coverage' if it fulfils the handover minimum condition as defined below:


1. RXLEV_NCELL(n) > USRSCP(n) + Max(0, Pa)


1. RXLEV_NCELL(n) > USECNO(n) + Max(0, Pa)


RXLEV_NCELL(n) = DL RSCP (if FDDREPQTY=RSCP) average of 3G neighbour cell (n) or DL Ec/No (if FDDREPQTY=EC_NO) average of 3G neighbour cell (n) *

USRSCP(n) = USRSCP (ADJC3G) = 'sufficient' RSCP value of the 3G neighbour cell (n) USECNO(n) = USECNO (ADJC3G) = 'sufficient' Ec/No value of the 3G neighbour cell (n) MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or


P = power capability of the mobile in [dBm]Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

→ The actual average of the reported quantity (RSCP or Ec/No) of the 3G neighbour cell must be higher than the sum of the 'sufficient' level set for the 3G neighbour cell plus the correction term Max(0,Pa)

* Remarks: 1) For 'sufficient coverage' handover, 3G neighbour cells are considered (and reported) only if

EUHO=TRUE and EUBCHO=TRUE (see command SET HAND [BASICS]). For the reporting of the RSCP levels, please consider the explanations in section 'Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells'.

2) The BTS adds a 3G target cell to the BWHCI for 'sufficient coverage' handover only if the IE 'Service Handover' (included in the CHANNEL ACTIVATION or FORCED HANDOVER REQUEST message) is set to the value 'Handover to neither UTRAN nor cdma2000 should be performed'.

3) The averaging of both RXLEV_DL values (2G neighbour cells) as well as RSCP values (3G neighbour cells) is done with an averaging window whose length is defined by parameter HOAVPWRB (see command SET HAND [BASICS]).



2.1.2.6.2 Target Cell Ranking (HCS disabled) If the feature Hierarchical Cell Structure (HCS) is disabled (HIERC=FALSE, see command SET HAND [BASICS]), the 3G neighbour cells that fulfil the 'sufficient coverage' condition (1.) are included in the target cell list of the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause 'sufficient coverage', unless the number of target cells is restricted by the parameter NCELL (see SET HAND).

The sorting criterion for the 3G target cells within the BWHCI depends on the type quantity which is selected for 3G neighbour cell reporting by parameter FDDREPQTY (see command CREATE BTS [BASICS]):

a) If FDDREPQTY=RSCP, the cells in the target cell list are sorted in descending order of RSCP [dB]. Inter-cell HCI:

target cell list

1. 3G neighbour cell Target cells are 2. 3G neighbour cell sorted in descending 3. 3G neighbour cell order of RSCP 4. 3G neighbour cell 5. 3G neighbour cell

... ...

b) If FDDREPQTY=EC_NO, the cells in the target cell list are sorted in descending order of Ec/No [dB].


1. 3G neighbour cell Target cells are 2. 3G neighbour cell sorted in descending 3. 3G neighbour cell order of Ec/No 4. 3G neighbour cell 5. 3G neighbour cell

... ...

The target cell ranking is different if the feature 'Hierarchical Cell Structure (HCS)' is enabled. For more details please refer to the section 2.4.1.

2.1.2.6.3 Speed sensitive handover enabled For those neighbour cells for which speed sensitive handover is enabled (this is the case if the setting CREATE ADJC3G:MICROCELL=TRUE is applied) the timer HOMDTIME (ADJC3G) is started when the 'sufficient coverage' condition (see previous page, condition 1.) is detected for the first time. As long as timer HOMDTIME runs, the handover initiation due to 'sufficient coverage' is suspended for this 3G adjacent cell, i.e. the handover condition is still checked but the affected 3G adjacent cell is excluded from any handover initiation. If the 'sufficient coverage' condition ceases during the runtime of HOMDTIME, the timer is reset and the handover is not triggered for this 3G adjacent cell. If the 'sufficient coverage' condition is detected again, HOMDTIME is started again from scratch. When the 'sufficient coverage' condition is still fulfilled after expiry of HOMDTIME, the 'sufficient coverage' handover may be triggered for this 3G neighbour cell, i.e. it may be included in the INTERCELL HANDOVER CONDITION INDICATION (BWHCI) with cause 'sufficient coverage'.



2.1.2.6.4 Target Cell Ranking with HCS If the feature Hierarchical Cell Structure (HCS) is enabled (HIERC=TRUE, see command SET HAND [BASICS]), the 3G cells in the target cell list of the HANDOVER CONDITION INDICATION message are sorted according to their priority.


0 1. 3G neighbour cell 2. 3G neighbour cell 3. 3G neighbour cell 4. 3G neighbour cell 5. 3G neighbour cell ... 15 ...

Target cells with the same priority level are ordered according to the value of PBGT(n) - HO_MARGIN(n).

2.1.2.6.5 Speed sensitive handover enabled (with HCS) The 'speed sensitive' sufficient coverage handover algorithm does not have any influence on the target cell ranking - a target cell for which the MICROCELL parameter is set to TRUE, is 'penalized' (i.e. not inserted into the target cell list) as long as HOMDTIME runs. If after expiry the sufficient coverage condition still exists, the target cell is added to the list and the handover may be performed.



2.1.2.7 Forced Handover due to directed retry, preemption or O&M intervention

2.1.2.7.1 Handover Decision / Handover Trigger Conditions 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.

2.1.2.7.2 Target Cell List Generation A 2G 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 forced handover minimum condition enhanced by an additional forced handover offset

1. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + FHO_RXLEV_MIN_OFFSET (n)


→ The actual receive level average of the neighbour cell must be higher than the sum of minimum receive level set for the neighbour cell and the correction term Max(0,Pa) plus the neighbour cell specific forced handover offset For 2G-3G adjacent cell relations the forced handover minimum condition does not feature an additional forced handover offset. In fact, and depends on the type of quantity which is selected for 3G neighbour cell reporting by parameter FDDREPQTY (see command CREATE BTS [BASICS]): a) If FDDREPQTY=RSCP, the minimum criterion is based on the RSCP threshold RXLEVMINC b) If FDDREPQTY=EC_NO, the minimum criterion is based on the Ec/No threshold UMECNO Thus a 3G neighbour cell is regarded as a suitable target cell forced handover and is thus inserted into the target cell list of the BWHCI with cause 'forced' if it fulfils the usual 'imperative' handover minimum condition







RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) RXLEVMINC(n) = RXLEVMINC (CREATE ADJC3G) = min. RSCP value of the 3G neighbour cell (n) UMTS_MIN_ECNO(n)= UMECNO (CREATE ADJC3G) = min. Ec/No value of the 3G neighbour cell (n) FHO_RXLEV_MIN_OFFSET(n)= FHORLMO (CREATE ADJC), value in [dB] = additional offset for RXLEVMIN of neighbour cell (n) to increase the minimum criteria MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] or MSTXPMAXUMTS (TGTFDD object), value in [dBm]










2.1.2.7.4 Target Cell Ranking with HCS If the feature Hierarchical Cell Structure (HCS) is enabled (parameter HIERC=TRUE in command SET HAND [BASICS]), the sorting of 2G and 3G target cells within the target cell list is done in exactly the same way as described for intercell handover due to level (see section 2.1.3.1.4).

2.1.2.8 Fast Uplink Handover (Intra-BSC only) 2.1.2.8.1 Handover Decision / Handover Trigger Conditions 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 currently reduced the UL transmit power, the fast uplink handover is triggered immediately without waiting for the Power Control algorithm to adjust the power to the maximum!

2.1.2.8.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 'fast uplink' if it fulfils the handover minimum condition enhanced by an additional fast uplink handover offset

2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + FULRXLVMOFF(n)


RXLEV_NCELL(n) = received DL RXLEV or average of the neighbour cell (n) (the averaging is done according to the setting of ALEVFULHO (SET HAND))

RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) FULRXLVMOFF(n) = FULRXLVMOFF (CREATE ADJC) = fast uplink receive level offset of the neighbour cell (n) in [dB] added to the handover minimum criteria MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm]

= max. allowed transmit power in neighbour cell (n) P = power capability of the mobile in [dBm]Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

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



2.1.2.8.3 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 descending order of PRIO_PBGT, with

PRIO_PBGT(n) = 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]

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.


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.9 Inter-cell Handover due to BSS Resource Management Criteria (Traffic HO) 2.1.2.9.1 Handover Decision / Handover Trigger Conditions 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

where PBGT(n) = RXLEV_NCELL(n) - (RXLEV_DL + PWR_C_D) +Min (MS_TXPWR_MAX, P) - Min (MS_TXPWR_MAX(n), P)

and K = m * TRFMS (with TRFMS ε K ε TRFMMA)

PBGT (n) = power budget of the neighbour cell (n) HO_MARGIN_TRAF(n) = TRFHOM (CREATE ADJC) = administrable traffic handover margin of the neighbour cell (n) in [dB] K = dynamic (time-dependent) traffic handover margin reduction term m = internal (time-dependent) counter that is increased/decreased on expiry of TRFHOT (see SET HAND) if traffic handover is currently enabled/disabled in the BTS TRFMS = traffic handover margin reduction step in [dB] TRFMMA = maximum traffic handover margin reduction in [dB] RXLEV_NCELL(n) = received DL RXLEV average of the neighbour cell (n) (averaging is done according to the setting of HOAVPWRB (SET HAND) RXLEV_DL = received level average downlink of the serving cell (averaging is done according to the setting of HOAVPWRB (SET HAND) PWR_C_D = BS_TXPWR_MAX - BS_TXPWR = dynamic power reduction, i.e. averaged difference between the maximum downlink RF power and the actual downlink power due to Power Control 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 in neighbour cell (n) P = power capability of the mobile in [dBm]Min(MS_TXPWR_MAX,P) = MS_TXPWR_MAX if MS_TXPWR_MAX P → 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 as defined by the parameter TRFMMA.

→ minimum traffic handover margin = HO_MARGIN_TRAF(n) – TRFMMA

Dynamic Traffic Handover Margin Reduction Process after traffic handover enabling by the BSC The dynamic reduction and increase of the traffic handover margin is is controlled by the BTS timer TRFHOT (see CREATE ADJC). When the BTS has received the 'traffic handover enabled' message (SET ATTRIBUTE) the traffic handover decision algorithm is started.

Traffic Handover Decision Phase 1: Traffic handover enabled, period before first expiry of 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:

2.1.2.9.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 'traffic' if it fulfils the handover minimum condition

2. RXLEV_NCELL(n) > RXLEVMIN(n) + Max(0, Pa) + Traffic_HO_Offset(n)


RXLEV_NCELL(n) = received DL RXLEV average of the neighbour cell (n) (averaging is done according to the setting of HOAVPWRB (SET HAND) RXLEVMIN(n) = RXLEVMIN (CREATE ADJC) = minimum RXLEV value of the neighbour cell (n) or

RXLEVMINC (CREATE ADJC3G) = min. RSCP value of the 3G neighbour cell (n) MS_TXPWR_MAX(n) = MSTXPMAXGSM/DCS/PCS (BTS object or TGTBTS object), value in [dBm] = max. allowed transmit power in neighbour cell (n) Traffic_HO_Offset(n) = TRFHORXLVMOFF (CREATE ADJC) = administrable traffic handover offset of

the neighbour cell (n) P = power capability of the mobile in [dBm]Max(0,Pa) = MS_TXPWR_MAX(n) - P if MS_TXPWR_MAX(n) - P > 0Max(0,Pa) = 0 if MS_TXPWR_MAX(n) - P < 0

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

2.1.2.9.3 Target Cell Ranking (HCS disabled) If the feature Hierarchical Cell Structure (HCS) is disabled (parameter HIERC=FALSE in command SET HAND [BASICS]), 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).

The target cells included in the INTERCELL HANDOVER CONDITION INDICATION are sorted in descending order of PRIO_PBGT, with




1. neighbour cell Target cells are 2. neighbour cell sorted in descending 3. neighbour cell order of 4. neighbour cell PRIO_PBGT(n) 5. 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.



2.1.2.9.4 Target Cell Ranking with HCS As without HCS enabled, the target cells included in the INTERCELL HANDOVER CONDITION INDICATION are sorted in descending order of PRIO_PBGT, with




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

Attention: The lower the value of the parameter PLNC, the higher the priority level! 0 = highest priority level, 15 = lowest priority level.

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 PRIO_PBGT(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 PRIO_PBGT(n) 5. neighbour cell, PLNC(5) = PL

... ...

2.2 Reporting, Display and BTS internal handling of RSCP values from 3G neighbour cells When the MS/UE indicates the measured RXLEV values for GSM neighbour cells in the MEASUREMENT REPORT messages, they are indicated as the difference between the actual RXLEV value in dBm and the reference value -110dBm.

The K1205/K1297 decodes and indicates these RXLEV values (assuming the reference -110dBm) in 'dBm ranges' in correspondence with the following table:

RXLEV (hex)

RXLEV (dec)

dBm value

dBm range (K1205/97)

RXLEV (hex)

RXLEV (dec)

dBm value

dBm range(K1205/97)

00 00 -110 -∞ ... ≤ -110 20 32 -78 -79 < ... ≤ -78 01 01 -109 -110 < ... ≤ -109 21 33 -77 -78 < ... ≤ -77 02 02 -108 -109 < ... ≤ -108 22 34 -76 -77 < ... ≤ -76 03 03 -107 -108 < ... ≤ -107 23 35 -75 -76 < ... ≤ -75 04 04 -106 -107 < ... ≤ -106 24 36 -74 -75 < ... ≤ -74 05 05 -105 -106 < ... ≤ -105 25 37 -73 -74 < ... ≤ -73 06 06 -104 -105 < ... ≤ -104 26 38 -72 -73 < ... ≤ -72 07 07 -103 -104 < ... ≤ -103 27 39 -71 -72 < ... ≤ -71 08 08 -102 -103 < ... ≤ -102 28 40 -70 -71 < ... ≤ -70 09 09 -101 -102 < ... ≤ -101 29 41 -69 -70 < ... ≤ -69 0A 10 -100 -101 < ... ≤ -100 2A 42 -68 -69 < ... ≤ -68 0B 11 -99 -100 < ... ≤ -99 2B 43 -67 -68 < ... ≤ -67 0C 12 -98 -99 < ... ≤ -98 2C 44 -66 -67 < ... ≤ -66 0D 13 -97 -98 < ... ≤ -97 2D 45 -65 -66 < ... ≤ -65 0E 14 -96 -97 < ... ≤ -96 2E 46 -64 -65 < ... ≤ -64 0F 15 -95 -96 < ... ≤ -95 2F 47 -63 -64 < ... ≤ -63 10 16 -94 -95 < ... ≤ -94 30 48 -62 -63 < ... ≤ -62 11 17 -93 -94 < ... ≤ -93 31 49 -61 -62 < ... ≤ -61 12 18 -92 -93 < ... ≤ -92 32 50 -60 -61 < ... ≤ -60 13 19 -91 -92 < ... ≤ -91 33 51 -59 -60 < ... ≤ -59 14 20 -90 -91 < ... ≤ -90 34 52 -58 -59 < ... ≤ -58 15 21 -89 -90 < ... ≤ -89 35 53 -57 -58 < ... ≤ -57 16 22 -88 -89 < ... ≤ -88 36 54 -56 -57 < ... ≤ -56 17 23 -87 -88 < ... ≤ -87 37 55 -55 -56 < ... ≤ -55 18 24 -86 -87 < ... ≤ -86 38 56 -54 -55 < ... ≤ -54 19 25 -85 -86 < ... ≤ -85 39 57 -53 -54 < ... ≤ -53 1A 26 -84 -85 < ... ≤ -84 3A 58 -52 -53 < ... ≤ -52 1B 27 -83 -84 < ... ≤ -83 3B 59 -51 -52 < ... ≤ -51 1C 28 -82 -83 < ... ≤ -82 3C 60 -50 -51 < ... ≤ -50 1D 29 -81 -82 < ... ≤ -81 3D 61 -49 -50 < ... ≤ -49 1E 30 -80 -81 < ... ≤ -80 3E 62 -48 -49 < ... ≤ -48 1F 31 -79 -80 < ... ≤ -79 3F 63 -47 -48 < ... + ∞

Examples:

RXLEV value calculation MS/UE reports value as decode on K1205/K1297 -90dBm -90dBm = -110dBm + 20dB 20 -91 dBm < … ≤ -90 dBm -75dBm -75dBm = -110dBm + 35dB 35 -76 dBm < … ≤ -75 dBm

Special indication of RSCP value for UTRAN neighbour cells When a multi-RAT MS is currently busy on a GSM/DCS cell, it reports the UTRAN neighbour cells (visible by the relative ARFCN number 31 in the MEASUREMENT REPORT) with their RSCP values according to the same principle, however, for UMTS FDD the reference value is -115dBm (not -110dBm).

Examples: RSCP value calculation MS/UE reports value as decode on K1205/K1297 -90dBm -90dBm = -115dBm + 25dB 25 -86 dBm < … ≤ -85 dBm -75dBm -75dBm = -115dBm + 40dB 40 -71 dBm < … ≤ -70 dBm BTS internal handling of reported RXLEV and RSP values BTS internally, the reported values (which are always relative values, which are referring to a specific reference value (-110dBm for 2G cells and -115 dBm for 3G neighbour cells) are corrected correspondingly: - All reported RXLEV values from 2G cells are taken and considered as reported by the MS/UE without ay correction. - From All reported values from 3G cells, the BTS subtracts the value '5' prior to averaging, in order to establish the 'pseudo' RXLEV value that reflects the real dBm RSCP value of the reported measurement and subsequently considers this corrected value in any further calculation or handover decision. Example: If the UE reports a value of '40' for an UTRAN neighbour cell, the BTS corrects it to '35' before averaging and further measurement processing.



2.3 Sequence of Handover Types within the Handover Decision Algorithm in the BTS

Within the BTS handover decision algorithm, the handover conditions are checked in a certain sequence, that reflects the priority (or the 'urgency') of the respective handover type (e.g. GSM denotes power budget as 'normal criterion' and the other causes such as handover due to level, quality and distance as 'alarm criteria' - these handovers are also called 'imperative handovers'. Handover decisions are taken according to the following priorities as listed in the following table:

Priority HO-Condition 1 Intercell handover due to Fast Uplink 2 Intracell handover in Extended Cell

• near -> far (single timeslot -> double timeslot) • far -> near (double timeslot -> single timeslot)

3 Intracell handover in Concentric Cell *) • inner -> complete • complete -> inner

Intracell handover in Concentric Cell (GSMDCS/GSMPCS Mixed Cell) • inner -> complete • complete -> inner

4 Intercell handover due to Quality 5 Intercell handover due to Level 6 Intercell handover due to Distance 7 Inter-System handover due to UMTS sufficient coverage 8 Intercell handover due to Power Budget ('better cell' handover) 9 Intercell handover due to Resource Management Criteria (Traffic HO) 10 Intracell handover due to Quality 11 Intercell handover due to

• Compression (FR -> HR) • Decompression (HR -> FR)

*) not used if UMTS sufficient is possible

The effect of this priority sequence is the following: If the conditions for two or more different handover types are fulfilled at the same time, the BTS will always trigger that type of handover (by checking for available target cells in the target cell list generation process and by sending a corresponding HANDOVER CONDITION INDICATION) which comes first in the priority sequence. If such a decision was made and the HANDOVER CONDITION INDICATION was sent to the BSC, the BTS suspends all further handover decisions for the time defined by the parameter THORQST (timer for handover request, see command SET HAND [BASICS]). When THORQST expires, the handover decision algorithm starts again from scratch. This means that, the same handover decision will be made by the BTS if the conditions are exactly the same as before (when the previous handover decision was made). Example: Assuming that the current RXQUAL / C/I conditions are given in such a way that both the conditions for quality intercell handover and decompression handover are fulfilled, the BTS will always trigger the quality handover first (assuming that the transmit power is at the maximum) and will stop the algorithm. Even if the target cell list generation process does not find any suitable target cell for the quality handover, the INTERCELL HANDOVER CONDITION INDICATION will be sent with an empty target cell list - no further handover decision is made until THORQST expires. If THRQST expires and the handover trigger conditions remain the same, also the new triggered handover type will be the same, as usually the intercell handover algorithm does not consider any previously made handover decisions. Only exception: the 'skip flag' (see section 'Intracell Handover due to quality'.



2.4 Power Control Thresholds & Algorithms 2.4.1 Functional Diagram: Power Control Thresholds -

Power Increase / Power Decrease (Classic Power Control)

Abbreviations: RXLEV = receive level of serving cell RXQUAL = bit error rate of serving cell 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.4.2 Rules: Power Control Thresholds: Power Increase / Power Decrease 2.4.2.1 Power Increase

The TRX Power is increased if one of the following conditions is fulfilled:

1. RXLEV_XX < L_RXLEV_XX_P XX = DL or UL

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.4.2.2 Power Decrease 1) The TRX Power is decreased if both of the following conditions are fulfilled:

1a. RXLEV_XX ≥ L_RXLev_XX_P + 2∗ POW_RED_STEP_SIZE XX = DL or UL

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

RXLEV_XX = received level average of the serving cell (the averaging is done according to the setting of PAVRLEV (SET PWRC)) 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.4.3 Classic and Adaptive Power Control 2.4.3.1 Introduction Power Control allows the increase respectively reduction of the UL and DL transmit power to react to 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.4.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!

RXLE

up_qual

low_qual

0 / 30

7 / 0 6low_lev up_lev

1

a

2 3

4 5 6

7 8 9

b

PWREDSS

+

+

+ + +

0 -

-- 0

non-AMR / AMRRXQUAL / C/I



2.4.3.3 Adaptive Power Control decision process In BR7.0 the so-called 'adaptive' power control was introduced. Adaptive power control is in effect if 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] - C = fast power decrease by: dB_diff [dB] (see explanation below)

low_lev = LOWTLEVD / LOWTLEVU up_lev = UPTLEVD / UPTLEVU low_qual = LOWTQUAD / LOWTQUAU (for non-AMR calls) = LOWTQUAMRDL / LOWTQUAMRUL (for AMR calls) up_qual = UPTQUAD / UPTQUAD (for non-AMR calls) = LOWTQUAMRDL / LOWTQUAMRUL (for AMR calls)

RXLE

up_qua

low_qual

0 /

7 / 0 6

1

a

2 3

4 5 6

7 9

b

PWREDSS

+B

+ +

0 0

-- 0

low_lev up_lev

+B

+

non-AMR / AMRRXQUAL / C/I

8

2.4.3.4 Differences between CLASSIC and ADAPTIVE power control decision Classic power increase (quadrants 8 and 9) The classic (slow) power increase (+) in the quadrants 8 and 9 (bad quality in conjunction with medium or high RXLEV values - in this scenario the bad quality is most probably caused by interference) is the same as in case of the classic power control. Only exception: the power control delay timer is not defined by the parameter PCONINT but by the length of the power control quality averaging window, extended by 1 (PAVRQUAL+1) for BS Power Control, reduced by 1 (PAVRQUAL-1) for MS Power Control (see below section 'Functional sequence of a power control procedure').

Classic power decrease (quadrant 2b) The classic (slow) power decrease in quadrant 2b (good quality in conjunction with medium or high RXLEV values) is exactly the same as in case of the classic power control. Adaptive power decrease (quadrant 3) For the power reduction in quadrant 3 a change request (CR2568) was implemented in BR8.0 to further accelerate the power reduction. In BR7.0 the acceleration was achieved by simply omitting the power control delay timer between subsequent power reduction steps (the size of which corresponded to the operator defined reduction step size PWREDSS). As opposed to that, in BR8.0 - the power reduction step is calculated based on the current level and quality conditions and - the delay timer may be applied again depending on the size of the calculated power reduction step.

In detail, in BR8.0 the power reduction in quadrant 3 is performed as follows: 1) At first the BTS determines the 'allowed maximum power reduction step based on quality criteria' ('qual_diff') by calculating the difference of the current quality to the 'medium desired quality' (RXQUAL values will be converted to C/I values in dB first):

qual_diff = current_average_qual – ((up_qual + low_qual) / 2) [Result as integer value in dB]

where up_qual = UPTQUAD / UPTQUAU [RXQUAL value converted to C/I value in dB] low_qual = LOWTQUAD / LOWTQUAU [RXQUAL value converted to C/I value in dB] current_average_qual = arithmetic mean of received RXQUAL values, mapped to C/I value in dB

Expressed in words, the above calculation considers the current quality by its C/I value and, assuming that the 'medium desired quality' is the arithmetic mean of the upper and the lower power control threshold, determines how much the power (i.e. the 'C' value of the C/I term) can be reduced without the quality dropping below the 'medium desired quality'. The resulting power reduction step is called 'qual_diff' in this calculation and can be regarded as 'allowed maximum power reduction step based on quality'.

2) Then the BTS determines the 'allowed maximum power reduction step based on level criteria' ('lev_diff') by simply calculating the difference between the current RXLEV average and the upper power control level threshold:

lev_diff = average_level – up_lev

where up_lev = UPTLEVD / UPTLEVU average_level =arithmetic mean of received RXLEV values in dB

3) Finally the BTS determines the 'allowed maximum power reduction step' ('dB_diff') by simply taking the smaller of the two values qual_diff or lev_diff.

dB_diff = MIN(qual_diff, lev_diff)

Expressed in words, the above calculation compares the previously calculated 'allowed maximum power reduction step based on quality' ('qual_diff') and 'allowed maximum power reduction step based on level' ('lev_diff'), declares the smaller of the two values as 'dB_diff' and uses this value as power reduction step in quadrant 3 instead of the decrease step size set by the operator (PWREDSS). Use of the power control delay timer in quadrant 3 If the calculated decrease step size is above 4dB, then additionally after having received the MS power level confirmation, the (existing) power control delay timer (which corresponds to the length of the power control quality averaging window PAVRQUAL+1 for BS Power Control, and PAVRQUAL-1 for MS Power Control) is started to collect new quality measurements for the complete quality averaging window to make sure that the next power control decision is based on the quality measurement data that was caused by the latest power level change. If the power decrease step is <4dB, then the delay timer is not applied, even if the resulting transmit power (after the decrease step) ends up in quadrant 2b. In other words, the decision whether the



delay timer is started (and thus applied before the next decrease step) is made simultaneously together with the power decrease decision.

Additionally, to improve the robustness against fast changing radio conditions a mechanism is implemented which, after a prior decrease step, checks whether conditions worsened so much that now an increase step would be ordered. This check is executed for the first time after the confirmation of the new power setting (which means: for BS Power Control immediately and for MS Power Control after 3 SACCH periods) and then as long as (and if) the power control delay timer (=PAVRQUAL+1 for BS Power Control, and =PAVRQUAL-1 for MS Power Control) is running. This avoids the delay of a necessary power increase step especially in cases with high power control delay timer values (e.g. in case of long averaging windows) and radio conditions that worsen considerably in the meantime. Also this mechanism is implemented for 'adaptive' PC mode only.

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.

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.4.3.5 Functional sequence of a BS and MS power control procedure 2.4.3.5.1 BS power control procedure 1) The BTS makes a power control decision (increase or power reduction) based on the currently 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 PAVRQUAL (in SACCH periods) plus 1 (= value of parameter PAVRQUAL + 1*). * The extension of the delay timer from PAVRQUAL (as used in BR7.0) to PAVRQUAL + 1 (in BR8.0) was implemented because the BTS always has to wait at least one SACCH period for MEASUREMENT REPORT which mirrors the result of the last BS Power Control order. 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 and, under specific conditions also in quadrant 3 (see above)). 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 (for further details, please see also section 'Further differences between CLASSIC and ADAPTIVE Power Control' below). 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)).

Special approach in case of missing UL SACCH frames The current value of the 'S'-Counter in the BTS is also checked in the scope of the BS power control decision: If no SACCH report was received in a particular SACCH period, no PC decision will be made for the DL (BS Power Control). If the 'missing SACCH' counter ('S'-counter, initial value defined by RDLNKTBS) is more than 2 below RDLNKTBS (i.e. either at least three SACCH reports in a row were missed or the current SACCH report is missing and additional SACCHs were missing before) then a normal BTS power increase will be commanded.



2.4.3.5.2 MS power control procedure The MS power increase or power reduction procedure includes a 'power control command' and 'power control confirmation' signalling procedure, which (compared to the BS power control process) considerably slows down the speed of the power adaptation. 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 (absolute) 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 (in SACCH periods) minus 1 (= value of parameter PAVRQUAL – 1*). * The reduction of the delay timer from PAVRQUAL (as used in BR7.0) to PAVRQUAL – 1 (in BR8.0) was implemented because at the time the delay timer is started (after having received the MS power level confirmation), the first new quality measurement is already contained in the current measurement report from the MS, so this can be subtracted from the waiting time. 5) When the 'delay timer' expires, the BTS resumes the PWRC decision process. When the waiting timer for the power confirmation from the MS (parameter PWRCONF) has expired without receipt of a power confirmation that confirms that the requested power command was actually executed, the BTS 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 and, under specific conditions also in quadrant 3 (see above)). 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.4.3.6 Comparison of timing behaviour of different Power Control types - MS Power Control, BS Power Control, classic and adaptive For MS power control, the time difference between two consecutive power control steps is 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 than a BS power control step and, consequently, the whole MS power control process reacts considerably slower than BS power control.

MS Power and BS Power Indication within the MEASUREMENT RESULT messages on Abis A verification of the executed and confirmed MS and BS power control steps is possible by checking the MEASUREMENT RESULT / MEASUREMENT REPORT messages on the Abis, especially the Information Elements (IE) 'BS Power' and 'MS Power' are relevant. These Information Elements must be interpreted in the following way:

BS Power Control The IE 'BS Power' indicates the currently ordered BS power level, i.e. it shows the BS power applied at the end of this SACCH period as a consequence of a BS power control decision. The MEASUREMENT RESULT message that contains the power level change is simultaneously the one which reflects the SACCH period in which the decision for the BS power change took place. Moreover, the downlink measurement sample contained in this MEAS RES message is the last one which was considered for the decision (last sample in the averaging window). How many previous samples were considered in addition (for averaging) depends on the length of the configured averaging windows (PAVRLEV, PAVRQUAL).

The diagram below illustrates the behaviour:

BS Power Control decision

time

SACCH period (480ms)

MEAS RES

MEAS RES ’BS power’

value changes

MEAS RES

SACCH period (480ms) SACCH period (480ms)

--- New BS power in effect ---

Downlink Measurement

Sample n

Contains the last measurement

sample (n) that was considered in the

averaging window for the BS power control decision

Downlink Measurement Sample n-1

DL measurements from MS already

reflect adjusted BS power

MEAS RES

Downlink Measurement Sample n-2

X



MS Power Control The IE 'MS Power' indicates the MS power level that was confirmed by the MS (i.e. the power change command was sent by the BTS 3 SACCH frames before). In more detail: 3) The MEAS RES message that contains the MS power level change reflects the SACCH period in which the MS sent the power confirmation. 2) The MEAS RES message before the one described under (3) reflects the SACCH period where the MS adjusted the MS power 1) The MEAS RES message before the one described under (2) reflects the SACCH period where the MS received the MS power control order. 0) The MEAS RES message before the one described under (1) reflects the SACCH period which contains the last considered uplink measurement sample for the MS power control decision. How many previous samples were considered in addition (for averaging) depends on the length of the configured averaging windows (PAVRLEV, PAVRQUAL).

The following diagrams illustrate the timing behaviour of the MEASUREMENT RESULT messages on the Abis and the associated power control events:

time

MEAS RES

’MS power’ value changes

SACCH period

MS confirms power

MEAS RES

SACCH period

MEAS RES

MEAS RES

MS adjusts power BTS sends PRWC order

SACCH period

MEAS RES

SACCH period

Uplink Measurement Sample n-1

Uplink Measurement

Sample n

X SACCH period

MS Power Control decision

Contains the last UL measurement

sample (n) that was considered in the

averaging window for the MS power control decision

RES

plink ment n-2

Power level change tracking within the MEASUREMENT RESULT messages on the Abis

Example: With the PWRC settings PAVRLEV=2-1,PAVRQUAL=2-1,PCONINT=2,PWRCONF=2 the following typical timing behaviour that can observed for the different power control types, if 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 4th MEASUREMENT RESULT = 3 SACCH periods confirmation + 1 SACCH periods delay (PAVRQUAL-1=1)

MSPRWC = ADAPTIVE (quadrants 1,4,6,7)

IE 'MS power' changes after every 3rd MEASUREMENT RESULT = 3 SACCH periods for confirmation + 0 SACCH periods delay

MSPRWC = ADAPTIVE (quadrant 3)

a) If calculated power reduction step < 4dB IE 'MS power' changes after the 3rd MEASUREMENT RESULT = 3 SACCH periods for confirmation + 0 SACCH periods delay b) If calculated power reduction step >= 4dB IE 'MS power' changes after the 4th MEASUREMENT RESULT = 3 SACCH periods confirmation + 1 SACCH periods delay (PAVRQUAL-1=1)

BSPRWC = ADAPTIVE(quadrants 2b,8,9)

IE 'BS power' changes after every 3rd MEASUREMENT RESULT = 0 SACCH periods confirmation + 3 SACCH periods delay (PAVRQUAL+1=3)

BSPRWC = ADAPTIVE(quadrants 1,4,6,7)

IE 'BS power' changes every MEASUREMENT RESULT = 0 SACCH periods for confirmation + 0 SACCH periods delay

BSPRWC = ADAPTIVE(quadrant 3)

a) If calculated power reduction step < 4dB IE 'BS power' changes every MEASUREMENT RESULT * = 0 SACCH periods for confirmation + 0 SACCH periods delay b) If calculated power reduction step >= 4dB IE 'BS power' changes after every 3rd MEASUREMENT RESULT * = 0 SACCH periods confirmation + 3 SACCH periods delay (PAVRQUAL+1=3)

2.4.3.7 Further differences between CLASSIC and ADAPTIVE Power Control If power control is set to ADAPTIVE, all sample values in the RXLEV averaging windows will be corrected 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.4.3.8 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 | 09 | 19 | 19 | 12 | 0 | +

10 | 20 | 19 | 9 | 3 |11 | 25 | 21 | 9 | 2 |12 | 25 | 22 | 9 | 1 |13 | 25 | 24 | 9 | 0 | -14 | 25 | 25 | 10 | 3 |15 | 23 | 25 | 10 | 2 |16 | 23 | 24 | 10 | 1 |17 | 23 | 24 | 10 | 0 | -18 | 23 | 23 | 11 | 3 |19 | 21 | 23 | 11 | 2 |20 | 21 | 22 | 11 | 1 |21 | 21 | 22 | 11 | 0 | -22 | 21 | 21 | 12 | 3 |23 | 19 | 21 | 12 | 2 |24 | 19 | 20 | 12 | 1 |25 | 19 | 20 | 12 | 0 | 026 | 19 | 19 | 12 | 0 | +... | ...

Notes: • *DL-RXLEV_avg is not the exact averaged value of the last n samples (n=length of the averaging

window) but the calculated value rounded to the next integer (0.5 is rounded up to 1). This is e.g. the reason why after Meas. result no. 8 a '0' decision (no increase/decrease) is made: the averaged value (19,5) is rounded to the next integer (20).

• BS-PL: the set BS-PL reflects the BS-PL set during the shown measurement period; a BS-PC 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 interval counter, set after a PC decision from (2xPCONINT); once it counted down to 0 a new PC decision will be taken.



2.5 Interworking of Handover and Power Control 2.5.1 Functional Diagram: Inter-cell Handover and Intra-cell Handover, Power

Increase and Power Decrease

Note: for clearness reasons, Fast Uplink Handover was not included in this diagram. Abbreviations: RXLEV = receive level of serving cell RXQUAL = bit error rate of serving cell GSM Parameter Name

DB parameter Name (SET HAND)

Meaning

L_RXLev_DL_H HOLTHLVDL lower threshold value for level handover downlink

L_RXLev_UL_H HOLTHLVUL lower threshold value for level handover uplink

L_RXLev_DL_IH HOTDLINT threshold value for intra BTS handover downlink

L_RXLev_UL_IH HOTULINT threshold value for intra BTS handover uplink

L_RXQual_DL_H HOLTHQUDL lower threshold value for quality handover downlink

L_RXQual_UL_H HOLTHQUUL lower threshold value for quality handover uplink

Bit-Error Rate(RxQual)

Level (RXLev)

Power-Control + Handover

L_RXQual_XX_H

L_RXQual_XX_P

L_RXLev_XX_P

L_RXLev_XX_H

U_RXLev_XX_P

U_RXQual_XX_P


HOLTHQUXX

LOWTQUAX

UPTQUAX

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.5.2 Rules The diagram on the previous page shows the interaction between Handover and Power Control in the SBS. It has to be noted that the thresholds for Handover and Power Control should be set in accordance with the diagram, because the algorithms are designed for such a threshold configuration. The main point is: imperative handovers are only triggered if dynamic Dower Control has adjusted the power to the maximum. The following rules should be followed: 1. L_RXLev_XX_H < L_RXLev_XX_P < L_RXLev_XX_P+2∗ POW_RED_STEP_SIZE < U_RXLev_XX_P

2. U_RXQual_XX_P < L_RXQual_XX_P < L_RXQual_XX_H

(XX = UL or DL)

Translated to the DB parameter names the rules are:

1. HOLTHLVXX < LOWTLEVX < LOWTLEVX+2∗PWREDSS < UPTLEVX

2. UPTQUAX < LOWTQUAX < HOLTHQUXX

(XX = UL or DL, X = U or D)

2.6 Service Dependent Handover and Power Control 2.6.1 Introduction Starting from BR7.0 it is possible to configure specific parameters (mainly thresholds) related to Power Control and Handover separately per so-called 'service group'. This means that the power control 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 represents 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 SGxxHOPAR resp. SGxxPCPAR (i.e. which parameter a specific field represents) depends on the service group as not all parameters are valid for all service groups.

2.6.2 SGxxHOPAR and SGxxPCPAR parameter values 2.6.2.1 SGxxHOPAR parameter values (Handover) The following parameters are represented by the SGxxHOPAR fields:

HAND Attribute Range Service Groups Description HOLTHLVDL 0..63 all (SG-1..SG-14) lower RXLEV HO threshold for DL HOLTHLVUL 0..63 all (SG-1..SG-14) lower RXLEV HO threshold for UL HOTDLINT 0..63 all (SG-1..SG-14) DL RXLEV threshold for intra-cell HO HOTULINT 0..63 all (SG-1..SG-14) UL RXLEV threshold for intra-cell HO HORXLVDLI 0..63 all (SG-1..SG-14) DL RXLEV threshold for concentric intra-cell HO from inner to complete cell HORXLVDLO 0..63 all (SG-1..SG-14) DL RXLEV threshold for concentric intra-cell HO from complete to inner cell HOLTHQUDL 0..7 SG-1..SG-10 lower RXQUAL HO threshold for DL HOLTHQUUL 0..7 SG-1..SG-10 lower RXQUAL HO threshold for UL HOTHEFRCDL 0..30 SG-3..SG-4 EFR Compression Handover threshold downlink HOTHEFRCUL 0..30 SG-3..SG-4 EFR Compression Handover threshold uplink HOTHFRCDL 0..30 SG-3..SG-4 FR Compression Handover threshold downlink HOTHFRCUL 0..30 SG-3..SG-4 FR Compression Handover threshold uplink HOTHHRDDL 0..30 SG-5..SG-6 non-AMR HR Decompression Handover threshold downlink HOTHHRDUL 0..30 SG-5..SG-6 non-AMR HR Decompression Handover threshold uplink RHOLTQUDL 2..7 SG-7..SG-10 RXQUAL DL threshold for intra- and inter-cell HO (of data calls only) RHOLTQUUL 2..7 SG-7..SG-10 RXQUAL UL threshold for intra- and inter-cell HO (of data calls only) HOLTHQAMRDL 0..30 SG-11..SG-14 lower C/I HO threshold for DL on AMR channels HOLTHQAMRUIL 0..30 SG-11..SG-14 lower C/I HO threshold for UL on AMR channels HOTHAMRCDL 0..30 SG-11..SG-12 AMR Compression Handover threshold downlink HOTHAMRCUL 0..30 SG-11..SG-12 AMR Compression Handover threshold uplink HOTHAMRDDL 0..30 SG-13..SG-14 AMR Decompression Handover threshold downlink HOTHAMRDUL 0..30 SG-11..SG-12 AMR Decompression Handover threshold uplink

Looking at the SGxxHOPAR parameters, the following parameter value structure is implemented in the different service groups :

Handover Service Groups for Signalling (Service Group-1, Service Group-2)

SGxxHOPAR(x=1..2, signalling)= <field 1>-<field 2>..<field 8>= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQUDL-HOLTHQUUL

Handover Sevice Groups for non-AMR FR speech calls (Service Group-3, Service Group-4)

SGxxHOPAR(x=3..6, non-AMR speech calls)= <field 1>-<field 2>..<field 8>= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQUDL-HOLTHQUUL-HOTHEFRCDL-HOTHEFRCUL-HOTHFRCDL-HOTHFRCUL

Handover Sevice Groups for non-AMR HR speech calls (Service Group-5, Service Group-6)

SGxxHOPAR(x=7..10, data calls)= <field 1>-<field 2>..<field 10>= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQUDL-HOLTHQUUL-RHOLTQDL-RHOLTQUL-HOTHHRDDL-HOTHHRDUL

Handover Sevice Groups for AMR FR speech calls (Service Group-11, Service Group-12)

SGxxHOPAR(x=11..12) == <field 1>-<field 2>..<field 10>= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO-HOLTHQAMRDL-HOLTHQAMRUL-HOTHAMRCDL-HOTHAMRCUL

Handover Sevice Groups for AMR HR speech calls (Service Group-13, Service Group-14

SGxxHOPAR(x=13..14) == <field 1>-<field 2>..<field 10>= HOLTHLVDL-HOLTHLVUL-HOTDLINT-HOTULINT-HORXLVDLI-HORXLVDLO--HOLTHQAMRDL-HOLTHQAMRUL-HOTHAMRDDL-HOTHAMRDUL

2.6.2.2 SGxxPCPAR parameter values (Power Control) The following parameters are represented by the SGxPCPAR fields:

PWRC Attribute Range Service Groups Description EBSPWRC 0..2 all (SG-1..SG-14) enables the BS power control (DISABLED/CLASSIC/ADAPTIVE). EMSPWRC 0..2 all (SG-1..SG-14) enables the MS power control (DISABLED/CLASSIC/ADAPTIVE). EPWCRLFW 0..1 all (SG-1..SG-14) enables Radio Link Failure power control. LOWTLEVD 0..63 all (SG-1..SG-14) lower DL RXLEV threshold LOWTLEVU 0..63 all (SG-1..SG-14) lower UL RXLEV threshold UPLTLEVD 0..63 all (SG-1..SG-14) upper DL RXLEV threshold UPTLEVU 0..63 all (SG-1..SG-14) upper UL RXLEV threshold PCRLFTH 0..64 all (SG-1..SG-14) threshold for the radio link failure counter RDLNKTBS 0..15 all (SG-1..SG-14) radio link timeout BS RDLNKTO 0..15 all (SG-1..SG-14) radio link timeout MS LOWTQUAD 0..7 SG-1..SG-10 lower DL quality threshold for standard calls in RXQUAL LOWTQUAU 0..7 SG-1..SG-10 lower UL quality threshold for standard calls in RXQUAL UPTQUAD 0..7 SG-1..SG-10 upper DL quality threshold for standard calls in RXQUAL UPTQUAU 0..7 SG-1..SG-10 upper UL quality threshold for standard calls in RXQUAL LOWTQUAMRDL 0..30 SG-11..SG-14 lower DL quality threshold for AMR calls in C/I LOWTQUAMRUL 0..30 SG-1..SG-10 lower UL quality threshold for AMR calls in C/I UPTQUAMRDL 0..30 SG-1..SG-10 upper DL quality threshold for AMR calls in C/I UPTQUAMRUL 0..30 SG-1..SG-10 upper UL quality threshold for AMR calls in C/I

Looking at the SGxxHOPAR parameters in separate Service Group Sets, the following parameter value structure is implemented for each Service Group Set:

Power Control Service for Signalling, non-AMR speech calls and data calls (Service Group-1..Service Group-10)

SGxxPCPAR(x=1..2, signalling)= <field 1>-<field 2>..<field 12>= EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQUAD–LOWTQUAU-UPTQUAD-UPTQUAU-RDLNKTBS-RDLNKTO

SGxxPCPAR(x=3..6, non-AMR speech calls)= <field 1>-<field 2>..<field 12>= EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQUAD–LOWTQUAU-UPTQUAD-UPTQUAU-RDLNKTBS-RDLNKTO

SGxxPCPAR(x=7..10, data calls)= <field 1>-<field 2>..<field 12>= EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQUAD–LOWTQUAU-UPTQUAD-UPTQUAU-RDLNKTBS-RDLNKTO

Power Control Sevice for AMR speech calls (Service Group-11..Service Group-14)

SGxxPCPAR(x=11..12, AMR FR calls)= <field 1>-<field 2>..<field 12>= EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQAMRDL-LOWTQAMRUL-UPTQAMRDL-UPTQAMRUL-RDLNKTBS-RDLNKTO

SGxxPCPAR(x=13..14, AMR HR calls)= <field 1>-<field 2>..<field 12>= EBSPWRC-EMSPWRC-EPWCRLFW-LOWTLEVD-LOWTLEVU-UPTLEVD-UPTLEVU-PCRLFTH-LOWTQAMRDL-LOWTQAMRUL-UPTQAMRDL-UPTQAMRUL-RDLNKTBS-RDLNKTO

2.6.2.3 Effects on Call processing In the BTS, the type of service group a particular call belongs to must be known to apply the correct 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.7 Mapping of RXQUAL and C/I values For AMR calls, the BTS algorithms for Power Control due to quality and Handover due to quality consider quality threshold values, whose values are not entered in RXQUAL values but in C/I (carrier/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.

Mapping of real RXQUAL ranges to Integer C/I values in [dB] (conversion of measured and averaged RXQUAL values)

Mapping of Integer RXQUAL to Integer C/I values in [dB] (for conversion of RXQUAL database thresholds)

RXQUAL C/I [dB] RXQUAL C/I [dB] 6,88 ... 7 1 1 19

6,63 ... 6,87 2 2 17 6,38 ... 6,62 4 3 14 6,13 ... 6,37 5 4 12 5,88 ... 6,12 6 5 9 5,63 ... 5,87 7 6 6 5,38 ... 5,62 8 7 1 5,13 ... 5,37 8 4,88 ... 5,12 9 4,63 ... 4,87 10 4,38 ... 4,62 11 4,13 ... 4,37 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.8 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: 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 In BR6.0, for AMR Half Rate (AMRHRC1..AMRHRC4) the following speech coding bit rates can be set: RATE_01: 4.75 kbit/s RATE_02: 5.15 kbit/s RATE_03: 5.90 kbit/s RATE_04: 6.70 kbit/s RATE_05: 7.40 kbit/s

When an AMR call has been set up, the BTS continuously evaluates the radio interface quality in the uplink (derived from the BER measurements performed by the BTS) and the downlink (derived from the 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 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-called '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 link adaptation 4,75kbit/s -> 5,90 kbit/s (AMRFRC1 -> AMRFRC2) takes place when C/I > upper threshold C/I > 4,15 dB link adaptation 5,90 kbit/s -> 4,75 kbit/s (AMRFRC2 -> AMRFRC1) takes place when 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: 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 link adaptation 4,75kbit/s -> 5,90 kbit/s (AMRFRC1 -> AMRFRC2) takes place when C/I > upper threshold C/I > 5,25 dB link adaptation 5,90 kbit/s -> 4,75 kbit/s (AMRFRC2 -> AMRFRC1) takes place when C/I < lower threshold C/I < 3,34 dB

AMRLKAT=200 (=100dB) Upper Thresholds for AMRLKAT=200 (=10dB)

Codec (kbit/s) 4,75 5,15 5,9 6,7 7,4 7,95 10,2 12,2

4,75 - 6,90 6,35 8,00 8,56 8,00 9,66 10,76 5,15 13,77 - 5,80 8,00 8,56 8,00 9,66 11,31 5,9 15,45 16,57 - 9,11 9,66 9,11 10,21 11,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: 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 link adaptation 4,75kbit/s -> 5,90 kbit/s (AMRFRC1 -> AMRFRC2) takes place when C/I > upper threshold C/I > 6,35 dB link adaptation 5,90 kbit/s -> 4,75 kbit/s (AMRFRC2 -> AMRFRC1) takes place when C/I < lower threshold C/I < 4,24 dB



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 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: 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 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: In BR8.0 the MNTBMASK bits 30 and 31 (see command SET BSC [BASICS]) are used to control the paging delivery rate from BSC to BTS. The paging delivery rate can be adjusted to values of 100%..130% of the Um paging throughput (considering that paging is only done with IMSI). These percentage values represent the relative percentage compared to the radio interface paging throughput which depends on the CCCH configuration (for further details please refer to the section 'BSC Overload Handling' in the appendix of this document). The two bits are used as representation of a two-digit binary value to control the setting:

BIT31 BIT30 Paging delivery rate (BSC->BTS) 0 0 130% of Um paging throughput (paging with IMSI only) 0 1 120% of Um paging throughput (paging with IMSI only) 1 0 110% of Um paging throughput (paging with IMSI only) 1 1 100% of Um paging throughput (paging with IMSI only)

In detail, the following throughput figures are achieved:

MNTBMASK BIT30-BIT31 No. of paging blocks in CCCH configuration

0 0

Delivery rate (130%)

0 1


1 0


1 1


1 1/90.00 ms 1/100.00 ms 1/106.66 ms 1/116.66 ms 2 1/45.00 ms 1/50.00 ms 1/53.33 ms 1/60.00 ms 3 1/30.00 ms 1/33.33 ms 1/35.00 ms 1/40.00 ms 4 1/22.50 ms 1/25.00 ms 1/26.66 ms 1/30.00 ms 5 1/17.50 ms 1/20.00 ms 1/20.00 ms 1/23.33 ms 6 1/15.00 ms 1/16.66 ms 1/17.50 ms 1/20.00 ms 7 1/12.50 ms 1/15.00 ms 1/15.00 ms 1/15.00 ms 8 1/10.00 ms 1/12.50 ms 1/13.33 ms 1/16.66 ms

>8 1/10.00 ms 1/10.0 ms 1/10.0 ms 1/12.50 ms

For each delivery rate, a length threshold is defined for the 'scheduling' paging queues in correspondence with the MNTBMASK bits 30 and 31 as follows:

MNTBMASK BIT30-BIT31 No. of paging blocks in CCCH configuration

0 0

Secondary queue places

0 1


1 0


1 1


1 11 10 10 9 2 22 20 18 17 3 33 30 28 25 4 44 40 37 33 5 57 50 50 43 6 67 60 57 50 7 80 67 67 60 8 100 80 75 67

>8 100 100 100 80 This means that for a 'scheduling' paging queue the maximum number of queue places depends on the CCCH configuration and MNTBMASK setting 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).



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 queuing (CI included).

Hierarchical Paging in BR8.0 To reduce the LAPD load due to PAGING COMMAND messages transmitted on Abis the feature 'Hierarchical Paging' was introduced in BR8.0. The purpose of this feature is supposed to eliminate the redundancy that consists in the delivery of one and the same PAGING COMMAND messages to a BTSM several times parallel (once per BTS that belongs to the BTSM). Assuming e.g. that a BTSM contains 3 BTSs (with all BTS having the same LAC), the BSC sends, for each paging procedure 3 PAGING COMMAND messages (1 per BTS) to the BTSM. This redundancy results in a waste of Abis LAPD bandwidth and thus increases the probability of LAPD link congestion or/and buffering delay of LAPD messages. For this reason, in BR8.0 the BSC combines the previous 3 PAGING COMMAND messages to one new message called PAGING COMMAND BTSM. This message has exactly the same format like a usual PAGING COMMAND, but contains an additional IE called 'BTSM Broadcast Info' which indicates, for each BTS/cell addressed, the relevant addressing data of the paging channel, which is a) the channel no. b) the Paging group c) the TEI of the BCCH TRX. The BTSM then re-generates the PAGIN COMMAND messages to be sent to the individual BTSs and forwards them to the relevant BTS TRXs.



Functional sequence of Gb PS paging delivery Packet pagings may occur in particular networks, e.g. when the so-called 'blackberry' application is used (this application forsees the delivery of e-mails to GPRS attached subscribers via GPRS).

General remark: the PTPPKF objects (that represent the configured GPRS cells) are distributed over the available PCUs for loadsharing reasons. The distribution is unable to guarantee a one-to-one relationship 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

1) 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. 2) 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). 3) The TDPC stores stores the PAPS messages in the BSC paging queues as described below: 3.1)From the LAC/RAC information contained in the PAPS message, the TDPC determines which 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 queues are exactly the same as in the CS domain 20 LAC/RAC * 9 delivery rates = 180 secondary queues. 3.2) 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. In networks with high PS paging volumes, this problem might induce BSC paging queue overflows, even if the total number of paged subscribers does not exceed the storage capacity of the BSC paging queue. 3.3) Together with the PAPS message contents itself, the TDPC stores the information from which PCU (and for which PTPPKF) the PAPS was received in the queue places of the primary paging queue. 4) When the PAPS is scheduled for delivery to the BTSs, the BSC checks from which PCU and for 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). BR8.0 Improvement in step 3.2) As the described implementation has the disadvantage that one and the same paging might end up several times in the secondary delivery queues (increasing the probability of BSC paging queue overload), a (patch) solution was developed in BR8.0, which checks, for each received PAPS, whether exactly this paging is already present in all the relevant secondary paging queues. If yes, the new received (redundant) PAPS is discarded and not placed into the primary paging queue anymore (as it is already present, coming from the SGSN for a different PCU). If the paging is not yet present in the secondary queues, the PAPS is stored in the primary queue and a corresponding index is set in the relevant secondary delivery queues as described above. This modification is implemented in BR8.0 via TDPC patch (please refer to the Release Documentation for the exact patch number and the associated BSC loads). The two diagrams on the subsequent pages show the differences between the old situation and the new improved solution.



Diagram - PS paging delivery in BR7.0 The diagram below shows the (BR7.0) implementation of PAPS delivery, which may lead to multiple insertion of one and the same paging into the primary and secondary paging delivery queues.

Primary queue

TDPC

PCU-0 PCU-1 PCU-11 …

SGSN

FRL-x FRL-y FRL-z FRL-w

MSC

a,e,I b,f,l c,g,m d,h,n

Secondary queues

BTS-a BTS-b

BTS-c

BTS-i BTS-l

BTS-m

BTS-e BTS-f

BTS-g

… …

RAC-x RAC-y

RAC-x RAC-y

RAC-x

BTS-d

BTS-h

BTS-n



Diagram - Improved PS paging delivery in BR8.0 The diagram below shows the improved (BR8.0) implementation of PAPS delivery, which may lead to multiple insertion of one and the same paging into the primary and secondary paging delivery queues.

TDPC

PCU-0 PCU-1 PCU-11 …

SGSN

FRL-x FRL-y FRL-z FRL-w

Primary queue

Secondary queues

BTS-a BTS-b

BTS-c

BTS-i BTS-l

BTS-m

BTS-e BTS-f

BTS-g

… …

MSC

RAC-x RAC-y

RAC-x RAC-y

RAC-x

BTS-d

BTS-h

BTS-n

a,e,I b,f,l c,g,m d,h,n

Is the received paging already present in all the

affected secondary queues ?

END

DISCARD

YES

NO

Rate 10 ms

Rate 90 ms



OVERLOAD detection conditions, notification to MSC and alarm 'BSC PAGING QUEUE OVERLOAD' An overload of the BSC paging queue occurs in the following cases 1) If a paging arrives from the A interface / Gb interface when the sum of scheduling queue buffers and the number of currently buffered pagings has already reached 360, the new paging is discarded. 2) If a paging arrives from the A interface / Gb interface when the sum of scheduling queue buffers and 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. In both cases the BSC reacts in the same way: If the percentage of discarded pagings has exceeded the threshold defined by the parameter PAGQOVLIND (see command SET BSC [BASICS]) in the last second, the alarm 'BSC PAGING QUEUE OVERLOAD' is raised and the BSSMAP OVERLOAD message is sent the MSC. The alarm 'BSC PAGING QUEUE OVERLOAD' is ceased and the BSSMAP OVERLOAD message sending is stopped if for a time period defined by timer T18 time no pagings have been discarded. Please see section 'Special overload supervision algorithm in case of BSC paging queue overflow' for further details. Congestion situation in single scheduling paging queues If a scheduling paging queue with a small CCCH configuration/delivery rate has reached the limit defined 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 'BSC PAGING QUEUE OVERLOAD' 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 'BSC PAGING QUEUE OVERLOAD' towards the O&M output media (RC, LMT, event logfile) - sends the BSSMAP message OVERLOAD (without cell identity (**see note in section 'Further important notes on BSC reactions') and with cause value 'processor overload' to the MSC (one message 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

OverloadCause still

present

- Overload level ++- Send Overload MSG to MSC

YES

Overload level --

NO

Start Timer 2sec.

OverloadLevel == 0

YESOVERLOADENDED

NO

- Overload level = 1- Send Overload MSG to MSC- Start T18

Wait T18expiration

NOTE : If T18 expirates during Overload management (i.e. when Overload Level is notzero) this timer is simply restarted.

When the overload process receives the first trigger (BSC overload detected), the BSC overload level is 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 (alarm 'BSC PAGING QUEUE OVERLOAD' output) 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. When the percentage of discarded pagings has exceeded the threshold defined by the parameter PAGQOVLIND (see command SET BSC [BASICS]) in the last second, an alarm is sent to the O&M 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 further 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 defence 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 signalling 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. 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, generally 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. Since BR8.0 a DELETE INDICATION can be also be sent, if the validity of an IMMEDIATE ASSIGNMENT (REJECT) message has already expired (see below). For the BSC the receipt of this DELETE INDICATION message is the indication for an AGCH overload situation in the BTS and, if BTS overload handling is enabled (BTSOVLH=TRUE), leads to the output of a corresponding alarm message - however, since BR8.0 the BSC will not start any traffic reduction measures in this case. In releases up to BR7.0 Paging was generally treated with priority, i.e. if both paging and IMMEDIATE ASSIGNMENT COMMAND messages were to be transmitted, the BTS used the CCCH slot for paging first. Thus the PCH traffic volume had a considerable impact on the IMMEDIATE ASSIGNMENT via the AGCH: the higher the paging traffic volume, the less CCCH space was available for IMMEDIATE ASSIGNMENT via the AGCH. To guarantee a minimum throughput of IMMEDIATE ASSIGNMENTs via the AGCH, it was only possible to reserve CCCH blocks exclusively for AGCH (see parameter NBLKACGR in command SET BTS



[CCCH]), but the drawback of this implementation was that CCCH blocks that were reserved for AGCH by NBLKACGR could never be used for PCH. This approach was replaced by a more intelligent way of CCCH block management between PCH and AGCH usage: Improvement of CCCH handling between PCH and AGCH In order to avoid AGCH shortages in time periods of high PCH load and high AGCH load, in BR8.0 a mechanism was introduced which observes the current state of the AGCH queues and dynamically priorizes the AGCH messages higher than the paging messages if the detected AGCH queue load requires it. Priorizing paging message higher than AGCH messages by any means (as it was done in releases up to BR7.0) does not make sense without reservation of CCCH-blocks for AGCH, as a paging procedure can only lead to the successful setup of an MTC, if AGCH resources are available for the SDCCH assignment, which is a precondition for the transmission of a paging response. On the other hand, the reservation of CCCH blocks for AGCH restricts the PCH throughput even if the reserved CCCH block is not used for AGCH. To make the CCCH block management more flexible the new mechanism was introduced which dynamically manages the AGCH message priority depending on the current filling state of the AGCH queue and features the 'preemption' of unreserved CCCH blocks (i.e. blocks that are shared between PCH and AGCH) for AGCH procedures even if also paging messages are queued for transmission in the BTS paging queues.

Moreover, with the new approach, the BTS observes the 'age' of the AGCH messages in the AGCH queue and a) considers this 'age' for the AGCH priority management and b) discards AGCH messages from the queue that have been delayed by processing and queuing for too long.

AGCH queue timeout mechanism Three operative states have been defined for the AGCH queue in order to tackle the statistical variability of the signaling load: NORMAL, MEDIUM and HIGH These states determine the BTS behaviour with respect to the choice whether to apply preemption on PCH blocks or not. The transitions between the states are mediated by the supervision of the following parameters, calculated on receipt of every IMMEDIATE ASSIGNMENT message:

AGCH_Q_FILLING T1 = FN (IMM ASS received) – FN (CHAN REQ received) T2 = FN (AGCH scheduled on air) S = S (TX_INT, CCCH_CONF) OVL T = Max (M * (S + TX_INT -1), TX_INT + 2 * S) with FN = frame number AGCH_Q_FILLING = the number of AGCH message pending in the AGCH queue. T1 = the time (expressed in number of frames) elapsed between the receipt of the Channel Request and the receipt of the corresponding IMMEDIATE ASSIGNMENT message from BSC T2 = the minimum time required to deliver on air the IMMEDIATE ASSIGNMENT, considering - the filling state of the AGCH queue and the availability of reserved blocks - the filling state of the different PCH queues (paging group) still to be scheduled - the state of the AGCH queue (NORMAL, MEDIUM, HIGH) S = the minimum time interval between two RACH accesses (in case of retransmission). As stated in GSM 44018 this is a function of TX_INT (derived from the parameter NSLOTST, see command SET BTS [CCCH]) and of the channel configuration (combined or not combined CCCH) and it is expressed in frame number as follows:

tx_integer td (RACH slots,

combined BCCH) td (RACH slots,

uncombined BCCH)

3, 8, 14, 50 41 (0.35 sec) 55 (0.25 sec)

4, 9, 16 52 (0.45 sec) 76 (0.35 sec)

5, 10, 20 58 (0.50 sec) 109 (0.50 sec)

6, 11, 25 86 (0.75 sec) 163(0.75 sec)

7, 12, 32 115 (1.00 sec) 217(1.00 sec)

OVL = a 16-bits bitmap taking account of the number of IMMEDIATE ASSIGNMENT message liable to delay, because of the AGCH load. This bitmap provides a 'positional' or 'one to one' representation of the delayed blocks waiting for delivery. An OVL bit is raised if and only if

T1 + T2 > S (TX_INT, CCCH_CONF) AND T1 + T2 < T i.e. it is raised for those IMM ASS (REJ) messages that are in danger of being delayed too much if not quickly delivered over the Um interface. OVL bits are lowered every time a delayed AGCH (accounted by the OVL bitmap) leaves the queue. T = the maximum time taken to repeat the last M RACH, in case, meanwhile, no IMMEDIATE ASSIGNMENT message is received by the MS. After this period any AGCH relating to one of these RACH will be ignored. In this sense T is the longest probable period the MS waits for the IMMEDIATE ASSIGNMENT, before definitely aborting the procedure. TX_INT is a parameter broadcast in SYS_INFO 1-2-3-4. M = min (MaxRetrans + 1, 3) and MaxRetrans, the number of RACH retransmissions configured by Operator (see parameter MAXRETR in command SET BTS [CCCH]).

Whatever the state is, an IMMEDIATE ASSIGNMENT or IMMEDIATE ASSIGNMENT REJECT message is only sent over the Um interface, if the condition

T1 + T2 <= T is fulfilled. T1 + T2 is the total time elapsed from the receipt of the CHANNEL REQUEST on the RACH to the expected/likely delivery of the corresponding AGCH message to the MS (the time spent on air interface is negligible in this context).

This means that this mechanism ensures that AGCH messages are not transmitted if they have been delayed for too long due to signalling processing and AGCH queuing. In other words, this mechanism guarantees that the BTS will not send an IMMEDIATE ASSIGNMENT or IMMEDIATE ASSIGNMENT REJECT message to the MS, when the waiting time of the MS for the receipt of these messages (determined by the parameters NSLOTST and MAXRETR) has already expired. If the above condition is not fulfilled (i.e. if T1 +T2 > T), the IMMEDIATE ASSIGMENT (REJECT) message are discarded in the BTS to avoid a waste of CCCH resources for AGCH messages that will in any case not be accepted by the MS anymore. The mentioned check (T1 + T2 <= T ?) is performed at two points of time in the processing: a) on receipt of the IMMEDIATE ASSIGNMENT (REJECT) from the BSC via the Abis A delay of the IMMEDIATE ASSIGNMENT (REJECT) message when received from the BSC may happen in case of long Abis link propagation time or/and in case of congestion in LAPD transmit queues in the BSC). Thus, if the IMM ASS (REJ) arrives at the BTS and the BTS check establishes that the sum of - the current delay and - the time that will additionally pass until the message can be delivered over the Um exceeds the time value 'T', the message is discarded immediately. b) immediately before transmission of the IMMEDIATE ASSIGNMENT (REJECT) via the Um The actual condition of the queues, at the moment of the delivery, could have been changed. Therefore, before sending the IMM ASS (REJ), the BTS performs the check again. If the check establishes that T1 +T2 > T, the IMM ASS (REJ) is discarded and the AGCH queue is scanned looking for the first block fulfilling the check positively. In both cases, the BTS sends a DELETE INDICATION to the BSC indicating the unsuccessful delivery of the message.

Attention: As, from the BSC point of view, these events are treated in the same way like normal AGCH overloads, the alarm 'BTS OVERLOAD DETECTED' for cause value 'AGCH overload' may occur more often than in BR7.0. In these cases, however, the alarm does not necessarily indicate an overflow of the AGCH queue but the discarding of AGCH messages that would arrive at the MS too late!

Important note for case b): As in BR8.0, the BTS may - combine two IMMEDIATE ASSIGNMENT messages into one IMMEDIATE ASSIGNMENT EXTENDED message (i.e. one message serving two subscriber requests) and - combine the IMMEDIATE ASSIGNMENT REJECT messages for up to 4 received subscriber requests, the DELETE INDICATION, which the BTS sends after the 'T' timeout detection immediately before the Um transmission and, may contain the AGCH messages as they have been enqueued in the AGCH queue, i.e. it may contain IMM ASS EXT messages for two requests or IMM ASS REJ messages for up to 4 different

subscriber requests. Thus the BTS may send only one DEL IND for several IMM ASS procedures that were started by the BSC.

AGCH/PCH preemption mechanism The priority of PCH messages before AGCH messages depends on the current AGCH queue filling state. In detail, the aforementioned operative states defined for the AGCH queue (AGCH_Q_STATE) with the values NORMAL, MEDIUM and HIGH are managed as follows:

1) AGCH_Q_STATE = NORMAL This NORMAL state value is defined by the following conditions: - No OVL bits raised and - AGCH_Q_FILLING < 12 (i.e. less than 12 of 16 AGCH queue places are currently used) PCH/AGCH management: PCH messages continue to have a higher priority than AGCH messages (there is no preemption). This implies that the IMMEDIATE ASSIGNMENT message waiting for delivery in the AGCH queue are delivered on a non-reserved block only if no PAGING REQUEST (or, eventually, PACKET DOWNLINK ASSIGNMENT) message is pending in the paging queue (see picture below). This case reflects the system behavior up to BR7.0. As mentioned above, an OVL bit is raised if and only if

T1 + T2 > S (TX_INT, CCCH_CONF) AND T1 + T2 < T In this case the AGCH_Q_STATE becomes MEDIUM.

2) AGCH_Q_STATE = MEDIUM This MEDIUM state value is defined by the following conditions: - At least one OVL bit already raised - AGCH_Q_FILLING < 12

PCH/AGCH management: Under these conditions, the preemption takes place only on those paging queues that are - Completely empty or - Half full, but not already preempted during the last CCCH cycle

As mentioned above, an OVL bit is raised if and only if T1 + T2 > S (TX_INT, CCCH_CONF) AND T1 + T2 < T

In this case the AGCH_Q_STATE becomes MEDIUM. OVL bits are lowered every time a delayed AGCH (accounted by the OVL bitmap) leaves the queue. 3) AGCH_Q_STATE = HIGH This HIGH state value is defined by the following conditions: - AGCH_Q_FILLING >= 12

PCH/AGCH management: In this case AGCH blocks have absolute precedence over PCH ones until the number of AGCH pending in queue drops again below 12. The handling of OVL bit is the same as in MEDIUM state.

BCCH AGCH AGCH PCHAGCH

PCHAGCH

PCHAGCH

PCHAGCH

PCHAGCH

PCHAGCH

PCHAGCH

16

15

14

13

12

11

10

09

08

07

06

05

04

03

02

01

02

01

Paging

Queues

SecondR

equestFirstR

equest

B0 B1 B2 B3 B4 B5 B6 B7 B8

AGCH_BUCKET_FILLING >= 12S = 41

LASTIMMASS

BCCH AGCH AGCH PCHAGCH

PCHAGCH

PCHAGCH

PCHAGCH

PCHAGCH

PCHAGCH

PCHAGCH

B0 B1 B2 B3 B4 B5 B6 B7 B8

Rec

eive

dhe

re

51 Multiframe

preempted preemptedpreempted

Automatic limitation of CCCH block preemption for AGCH messages: When the CCCH block of a particular PCH group was preempted for transmission AGCH, the BTS suspends the AGCH preemption for this paging group for the next paging group cycle, i.e. when the same paging group is scheduled again for transmission over Um, the 'shared' CCCH blocks messages cannot be preempted for AGCH again. This is done in order to not to delay the Um delivery of paging message for one paging group via the Um interface for too long. CCCH blocks of other paging groups may be preempted independently of this suspension, but, of course, the same principles apply for all paging groups.



Category C: /* Abis LAPD signalling 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 signaling 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 D: /* RACH overload */

5) The BTS has detected an overload in on the RACH.Background: A Random Access Channel (RACH) is used by the MSs to request a dedicated 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), does not lead to any overload defence action by the BSC anymore (change in BR8.0). This means, that, when the a DELETE INDICATION is received, there is no reaction from the BSC at all. Instead, the discarding of IMMEDIATE ASSIGNMENT or/and IMMEDIATE ASSIGNMENT REJECT messages is entirely left to the BTS.



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. 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) 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 defence actions in the BTS in case of PCH overload Since BR7.0 there is an additional PCH overload defence 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) - does not start any overload defence actions (change implemented in BR8.0). Instead, the discarding of IMMEDIATE ASSIGNMENT or/and IMMEDIATE ASSIGNMENT REJECT messages is entirely left to the BTS.

Case C: RACH overload (BTS sends CCCH LOAD INDICATION)

When condition (3) is detected, no overload regulation measures are applied. * Within the alarm message the BTS overload cause is indicated as follows

BTS Overload condition Overload cause value in 'BTS overload detected' alarm

Alarm output only if BTSOVLH=TRUE ?

(1) PCH overload (OVERLOAD received) 07 (CCCH congestion) yes

(2) AGCH overload (DELETE 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 .................................................................... 116 ABISFRACTTHR........................................................ 93 ABISHRACTTHR........................................................ 94 ABISTRFHITHR ......................................................... 96 ABISTRFLTHR........................................................... 97 ABUTYP ................................................................... 249 ACBQPFF................................................................. 187 ACBQPMAX ............................................................. 187 ACCEPTGDEGR........................................................ 19 ACEFLFF.................................................................. 187 ACFERMAX.............................................................. 188 ACHAN..................................................................... 398 ACLNKTYP............................................................... 188 ACMAXEFLDMA ...................................................... 188 ACMINEFLDMA ....................................................... 188 ACPER ..................................................................... 188 ADVCMPHOOAMR .................................................. 301 AECST ....................................................................... 79 AISAT ......................................................................... 20 ALACOUNT ................................................................ 58 ALARMT1................................................................... 58 ALARMT2................................................................... 58 ALARMT3................................................................... 58 ALCST........................................................................ 79 ALCTGTLEV............................................................... 79 ALEVFULHO ............................................................ 301 ALLCRIT..................................................................... 77 ALPHA...................................................................... 249 ALRMSEVBTS ........................................................... 52 ALRMSEVBTSM ........................................................ 52 ALRMSEVCBCL......................................................... 52 ALRMSEVCPEX......................................................... 55 ALRMSEVDISK .......................................................... 55 ALRMSEVDK40 ......................................................... 55 ALRMSEVEPWR........................................................ 56 ALRMSEVFRL............................................................ 52 ALRMSEVIPLI ............................................................ 52 ALRMSEVIXLT........................................................... 56 ALRMSEVLICD .......................................................... 56 ALRMSEVLICDS........................................................ 56 ALRMSEVLPDLM ...................................................... 53 ALRMSEVLPDLMTD.................................................. 53 ALRMSEVLPDLR....................................................... 53 ALRMSEVLPDLRTD .................................................. 53 ALRMSEVLPDLS ....................................................... 53 ALRMSEVME2M ........................................................ 56 ALRMSEVMEMT........................................................ 56 ALRMSEVMPCC........................................................ 56 ALRMSEVNSVC ........................................................ 53 ALRMSEVNTW .......................................................... 56 ALRMSEVOMAL ........................................................ 53 ALRMSEVPCMA ........................................................ 53 ALRMSEVPCMB ........................................................ 53 ALRMSEVPCMG........................................................ 53 ALRMSEVPCMS ........................................................ 53 ALRMSEVPCU........................................................... 54 ALRMSEVPCUTD ...................................................... 54 ALRMSEVPPXL ......................................................... 56 ALRMSEVPPXP......................................................... 56 ALRMSEVPPXT ......................................................... 57 ALRMSEVPPXU......................................................... 57 ALRMSEVPTPPKF .................................................... 54 ALRMSEVPWRD ....................................................... 57 ALRMSEVSYNC ........................................................ 57

ALRMSEVSYNE.........................................................57 ALRMSEVTDCU.........................................................54 ALRMSEVTDPC.........................................................57 ALRMSEVTRAU.........................................................54 ALRMSEVTRX ...........................................................54 ALRMSEVTRXTD.......................................................54 ALRMSEVX25A..........................................................57 ALRMSEVX25D..........................................................57 ALTH.........................................................................425 AMONTH ....................................................................20 AMRACMRDL...........................................................302 AMRFRC1 (BTS) ......................................................123 AMRFRC2 (BTS) ......................................................127 AMRFRC3 (BTS) ......................................................127 AMRFRC4 (BTS) ......................................................127 AMRFRIC (BTS) .......................................................128 AMRFRLLCOM.........................................................230 AMRFRLLPRM .........................................................230 AMRFRTH12 (BTS)..................................................128 AMRFRTH23 (BTS)..................................................129 AMRFRTH34 (BTS)..................................................129 AMRHRC1 (BTS)......................................................130 AMRHRC2 (BTS)......................................................130 AMRHRC3 (BTS)......................................................130 AMRHRC4 (BTS)......................................................131 AMRHRIC (BTS).......................................................131 AMRHRLLCOM ........................................................231 AMRHRLLPRM.........................................................231 AMRHRTH12 (BTS) .................................................131 AMRHRTH23 (BTS) .................................................132 AMRHRTH34 (BTS) .................................................132 AMRLKAT.................................................................133 ANTHOPMOD ..........................................................133 ANTHOPP ................................................................133 APLESSNBSC..........................................................383 APLESSNSMLC .......................................................383 ASCILLPRM .............................................................231 ASCIONECHMDL.......................................................21 ASCISER..................................................................354 ASCIULR ..................................................................355 ASEV ........................................................................421 ASMONTH..................................................................21 ASSFAIR ..................................................................407 ASSLAPD .................................................................122 ASTRING..................................................................421 ASUBCH.....................................................................81 ASUBISAT ..................................................................22 ATIME1.....................................................................426 ATT1...........................................................................51 ATT2..ATT8 ................................................................51 AUTOREP ................................................................425

B

BAF (PCMA) ...............................................................82 BAF (PCMB) ...............................................................71 BAF (PCMG)...............................................................89 BAF (PCMS) ...............................................................75 BAND........................................................................426 BANDOFHYS ...........................................................425 BARINSYSINFO10 ...................................................363 BAUDRATE ..............................................................396 BCCHFREQ (BTS [BASICS]) ...................................133 BCCHFREQ (TGTBTS) ............................................359 BCGRTODIFFSERV...................................................66 BCGRWEI.................................................................249 BEPAVGP.................................................................249



BEPFIDLWEI............................................................ 249 BEPFITODIFFSERV .................................................. 66 BER (PCMA) .............................................................. 82 BER (PCMB) .............................................................. 72 BER (PCMG) .............................................................. 89 BER (PCMS) .............................................................. 75 BHOFOT .................................................................. 364 BLERAVEDL ............................................................ 250 BLERAVEUL ............................................................ 250 BMONTH.................................................................. 208 BPAGCHR................................................................ 250 BPRACHR................................................................ 251 BRIDGE BSC ............................................................. 51 BSCDVMA................................................................ 251 BSCOVLH .................................................................. 22 BSCT1........................................................................ 12 BSCT10...................................................................... 12 BSCT11...................................................................... 13 BSCT11PUB............................................................... 13 BSCT11WPS.............................................................. 13 BSCT13...................................................................... 14 BSCT17...................................................................... 14 BSCT18...................................................................... 14 BSCT19...................................................................... 14 BSCT20...................................................................... 15 BSCT3........................................................................ 15 BSCT3121.................................................................. 15 BSCT4........................................................................ 16 BSCT7........................................................................ 16 BSCT8........................................................................ 17 BSCTQHO.................................................................. 18 BSCTQHOPUB .......................................................... 18 BSCTQHOWPS.......................................................... 18 BSIC (BTS [BASICS])............................................... 134 BSIC (TGTBTS)........................................................ 359 BSMONTH................................................................ 208 BSPBBLK ................................................................. 251 BSSAPSSN .............................................................. 383 BTSHSCSD.............................................................. 356 BTSOVLH................................................................... 23 BULKDCONF ............................................................. 79 BURNOFFS.............................................................. 134 BVCBHIPER............................................................. 252 BVCBLPER .............................................................. 252 BVCBMAPER........................................................... 252 BVCBSPPER............................................................ 252

C

C31H ........................................................................ 252 C32QUAL ................................................................. 252 CACKTYP................................................................. 253 CALLF01 .................................................................. 134 CALLF02..CALLF63 ................................................. 134 CBCPH....................................................................... 23 CBQ.......................................................................... 135 CCALL...................................................................... 135 CCALLF01................................................................ 113 CCALLF02..CCALLF63 ............................................ 114 CCDIST .................................................................... 303 CCELL1.................................................................... 303 CCELL2.................................................................... 303 CCHANTFACT ........................................................... 23 CELLBARR............................................................... 208 CELLGLID (BTS [BASICS])...................................... 136 CELLGLID (TGTBTS)............................................... 360 CELLGLID (TGTFDD) .............................................. 376 CELLRESH............................................................... 136 CELLTYPE ............................................................... 137 CFS ..............................................................................9

CHPOOLTYP............................................................297 CHTYPE ...........................................290, 291, 293, 297 CICFM ........................................................................23 CID............................................................................415 CITASUP ....................................................................23 CLOCK .....................................................................396 CLSETFAIR ..............................................................407 CMOBALLOC ...........................................................115 CODE (PCMA)............................................................82 CODE (PCMB)............................................................73 CODE (PCMG) ...........................................................89 CODE (PCMS)............................................................75 CONCELL.................................................................140 CONGTH ..................................................................388 CPCUN(PCU) .............................................................66 CPCUN(PTPPKF).....................................................253 CRC (PCMA) ..............................................................82 CRC (PCMB) ..............................................................72 CRC (PCMG)..............................................................89 CRC (PCMS) ..............................................................75 CREALL....................................................................209 CREATE ADJC.........................................................363 CREATE ADJC3G ....................................................378 CREATE BTS [BASICS] ...........................................123 CREATE BTSM ..........................................................93 CREATE CBCL.........................................................401 CREATE CBTS.........................................................113 CREATE CFHSY ......................................................115 CREATE CHAN (BCCH)...........................................290 CREATE CHAN (SDCCH) ........................................291 CREATE CHAN (TCH) .............................................293 CREATE CHAN (TCH/SD) .......................................297 CREATE CPCU ..........................................................59 CREATE CTRSCHED ..............................................414 CREATE ENVA ........................................................421 CREATE EPWR .........................................................57 CREATE FHSY.........................................................282 CREATE FRL .............................................................91 CREATE HDCTR......................................................420 CREATE IPLI............................................................400 CREATE LICD ............................................................58 CREATE LICDS..........................................................58 CREATE LPDLM ......................................................116 CREATE LPDLS.........................................................81 CREATE NSVC ..........................................................92 CREATE NUC ..........................................................395 CREATE OMAL ........................................................401 CREATE OPC [BASICS] ..........................................383 CREATE PCMA..........................................................82 CREATE PCMB..........................................................71 CREATE PCMG .........................................................89 CREATE PCMS..........................................................75 CREATE PCU.............................................................66 CREATE PTPPKF ....................................................249 CREATE QSMONBSC .............................................406 CREATE QSMONBTS..............................................407 CREATE QSMONGPRS...........................................411 CREATE QSTHRS ...................................................404 CREATE RFLOOP ...................................................425 CREATE SCA...........................................................426 CREATE SS7L .........................................................394 CREATE SUBTSLB..................................................122 CREATE SYNC ........................................................402 CREATE SYNE ........................................................402 CREATE TGTBTS....................................................359 CREATE TGTFDD....................................................376 CREATE TGTPTPPKF .............................................361 CREATE TRACE ......................................................413 CREATE TRAU ..........................................................77



CREATE TRX........................................................... 284 CREATE X25A ......................................................... 398 CREATE X25D ......................................................... 396 CRESELTHRINP...................................................... 253 CRESELTRHSOUT.................................................. 253 CRESOFF ................................................................ 141 CRESPARI ............................................................... 142 CRTSWDLLCOM ..................................................... 231 CRTSWDLLPRM...................................................... 232 CRTSWSPELLCOM................................................. 232 CRTSWSPELLPRM ................................................. 232 CSCE........................................................................ 143 CSCH3CSCH4SUP (BSC) ......................................... 24 CSCH3CSCH4SUP (PTPPKF)................................. 253 CUCONF .................................................................. 143

D

DEFPOOLTYP ........................................................... 82 DGRSTRGY ............................................................. 143 DGRSTRGYBCNT ..................................................... 25 DIFFSERVSUP .......................................................... 67 DIRTCHASS............................................................. 209 DISTHO.................................................................... 304 DLAPDOVL ................................................................ 25 DNLBSSPFCRET....................................................... 59 DNLBSSPFCT............................................................ 59 DPBGTHO................................................................ 304 DRXTMA .................................................................. 254 DTEDCE................................................................... 396 DTXDLFR................................................................. 211 DTXDLHR................................................................. 213 DTXUL...................................................................... 213

E

EAC .......................................................................... 188 EADVCMPDCMHO .................................................. 305 EADVCMPHOAMR .................................................. 312 EADVCMPHOSC ..................................................... 312 EANTHOP ................................................................ 145 EARCLM................................................................... 214 EAUTOREC................................................................ 55 EBCCHTRX.............................................................. 288 EBSPWCR ............................................................... 235 EBSPWRC ............................................................... 236 EBUSYCUM ............................................................. 426 EC ............................................................................ 215 EDASUP................................................................... 254 EDTMSUP(PTPPKF)................................................ 254 EDTMSUP(TGTPTPPKF) ........................................ 361 EEDGE..................................................................... 289 EEICM ...................................................................... 426 EENHDTMSUP .......................................................... 25 EEOTD ..................................................................... 146 EEXCDIST................................................................ 356 EFCRESEL............................................................... 146 EFRSUPP................................................................... 26 EFULHO................................................................... 313 EGPLGPEIGHTTS ................................................... 254 EGPLGPFIVETS ...................................................... 254 EGPLGPFOURTS .................................................... 254 EGPLGPONETS ...................................................... 254 EGPLGPSEVENTS .................................................. 255 EGPLGPSIXTS ........................................................ 255 EGPLGPTHREETS .................................................. 255 EGPLGPTWOTS...................................................... 255 EGPRS..................................................................... 289 EGWSEIGHTTS....................................................... 255 EGWSFIVETS.......................................................... 255 EGWSFOURTS........................................................ 255

EGWSONETS ..........................................................256 EGWSSEVENTS ......................................................256 EGWSSIXTS ............................................................256 EGWSTHREETS ......................................................256 EGWSTWOTS..........................................................256 EHDCTR...................................................................146 EHRACT...................................................................147 EHRACTAMR ...........................................................149 EICNF1.....................................................................426 EINTSITSYN...............................................................98 EISDCCHHO ..............................................................26 ELEVHOM ................................................................313 ELIMITCH.................................................................314 ELKADPT .................................................................256 ELLCOM...................................................................232 ELLPRM ...................................................................233 EMANPRESCOM .....................................................257 EMANPRESPRM......................................................257 EMCSFAMA1DL.......................................................257 EMCSFAMAP1DL.....................................................257 EMCSFAMB1DL.......................................................257 EMCSFAMCDL.........................................................257 EMCSFAMGDL ........................................................257 EMFA1UNIR8PSK....................................................257 EMFAP1UNIR8PSK..................................................258 EMFB1UNIR8PSK....................................................258 EMFCUNIR8PSK......................................................258 EMFCUNIRGMSK ....................................................258 EMFGUNIR8PSK .....................................................258 EMFGUNIRGMSK ....................................................258 EMSPWRC...............................................................237 EMT1 ........................................................................102 EMT2 ........................................................................102 ENANCD...................................................................198 ENAQUALEVHOM....................................................315 ENCALSUP ................................................................26 ENDMA (BTS) ..........................................................356 ENDMA (CBTS)........................................................114 ENDML .....................................................................426 ENFOIAHO.................................................................27 ENFORCHO ...............................................................27 ENHSCSD ..................................................................29 ENPERNOTDE.........................................................149 ENVANAME..............................................................421 EPA.............................................................................30 EPAT1 ......................................................................150 EPAT2 ......................................................................151 EPOOL .......................................................................31 EPRE........................................................................216 EPREHSCSD .............................................................31 EPWCRLFW.............................................................237 EQ ............................................................................217 EQPOS.......................................................................55 ERRACT.....................................................................31 ERRCORMTD ..........................................................389 ERUDGR ..................................................................352 ESUP..........................................................................31 ETFO ..........................................................................79 ETIME...........................................................................9 ETXDIVTS ................................................................151 EUBCHO ..................................................................316 EUHO .......................................................................317 EUIMPHO.................................................................317 EUMSSNCRESEL ....................................................258 EUSCHO ..................................................................318 EUSCNCRESEL.........................................................32 EUSDCHO..................................................................32 EXCDIST ..................................................................357 EXPSWV (BTSM) .....................................................102



EXPSWV (TRAU) ....................................................... 80 EXTCHO................................................................... 319 EXTMODE........................................ 290, 292, 293, 298

F

FACCHQ .................................................................. 151 FCRATE ..................................................................... 59 FDDARFCN.............................................................. 376 FDDDIV .................................................................... 376 FDDGQO.................................................................. 258 FDDMURREP........................................................... 151 FDDQMI ................................................................... 152 FDDQMIO................................................................. 152 FDDQO..................................................................... 153 FDDREPO................................................................ 153 FDDREPQTY ........................................................... 154 FDDREPTH.............................................................. 155 FDDREPTH2............................................................ 155 FDDRSCPMI ............................................................ 156 FDDSCRMC............................................................. 376 FHAMRFRC1 ........................................................... 156 FHAMRFRC2 ........................................................... 156 FHAMRFRC3 ........................................................... 156 FHAMRFRC4 ........................................................... 157 FHAMRFRIC ............................................................ 157 FHAMRFRTH12 ....................................................... 157 FHAMRFRTH23 ....................................................... 157 FHAMRFRTH34 ....................................................... 157 FHAMRHRC1 ........................................................... 158 FHAMRHRC2 ........................................................... 158 FHAMRHRC3 ........................................................... 158 FHAMRHRC4 ........................................................... 158 FHAMRHRIC ............................................................ 158 FHAMRHRTH12....................................................... 159 FHAMRHRTH23....................................................... 159 FHAMRHRTH34....................................................... 159 FHORLMO................................................................ 364 FHSYID .................................................................... 299 FHSYID (CHAN)....................................... 291, 292, 294 FHSYID (TRX).......................................................... 284 FLAPDOVLTH.......................................................... 102 FLOWCTH................................................................ 389 FPER........................................................................ 259 FRACTAMRTH1....................................................... 160 FRACTAMRTH2....................................................... 161 FRACTTH1............................................................... 161 FRACTTH2............................................................... 162 FRANOFFS .............................................................. 162 FRSTD ....................................................................... 91 FRTERM................................................................... 395 FULHOC................................................................... 365 FULRXLVMOFF ....................................................... 365

G

GAM ......................................................................... 259 GASTRABISTH ........................................................ 103 GASTRTH ................................................................ 259 GATEWAY0.............................................................. 400 GATEWAY1.............................................................. 400 GBSNS....................................................................... 67 GCELLRESH............................................................ 260 GDCH (TCH) ............................................................ 294 GDCH (TCHSD) ....................................................... 299 GEXTS ..................................................................... 162 GFDDMURREP........................................................ 260 GFDDQMI................................................................. 261 GFDDQMIO.............................................................. 261 GFDDREPQTY......................................................... 262 GFDDRSCPMI ......................................................... 262

GHCSPC (ADJC)......................................................365 GHCSPC (PTPPKF) .................................................262 GHCSTH (ADJC)......................................................365 GHCSTH (PTPPKF) .................................................263 GLK.............................................................................91 GLLCOM...................................................................233 GLLPRM...................................................................233 GMANMSAL .............................................................263 GMANPRESCOM.....................................................263 GMANPRESPRM .....................................................263 GMANRETS .............................................................263 GMICROCU..............................................................378 GMSTXPMAC (PTPPKF) .........................................264 GMSTXPMAC (TGTPTPPKF) ..................................362 GNMULBAC .............................................................264 GPATH .....................................................................265 GPDPDTCHA ...........................................................265 GPENTIME (ADJC) ..................................................366 GRESOFF (ADJC)....................................................366 GRXLAMI (PTPPKF) ................................................266 GRXLAMI (TGTPTPPKF) .........................................362 GS ............................................................................267 GSUP........................................................................366 GTDDMURREP ........................................................267 GTEMPOFF (ADJC) .................................................367 GTS ............................................................................91 GTXINT.....................................................................267 GUARMABIS ............................................................162 GUMTSSRHPRI .......................................................268

H

HANDROR................................................................408 HANFAIR ..................................................................408 HCICN ........................................................................87 HDCFS .......................................................................10 HDCFUPE ..................................................................10 HIERC.......................................................................319 HIERF.......................................................................319 HOAVDIST ...............................................................320 HOAVLEV.................................................................321 HOAVPWRB.............................................................322 HOAVQUAL..............................................................323 HOCCDIST ...............................................................324 HOLTHLVDL.............................................................324 HOLTHLVUL.............................................................324 HOLTHQAMRDL ......................................................325 HOLTHQAMRUL ......................................................326 HOLTHQUDL............................................................326 HOLTHQUUL............................................................327 HOM (ADJC).............................................................367 HOM (ADJC3G)........................................................378 HOMDOFF (ADJC)...................................................367 HOMDOFF (ADJC3G) ..............................................378 HOMDTIME (ADJC) .................................................368 HOMDTIME (ADJC3G).............................................378 HOMRGTA ...............................................................327 HOMSOFF (ADJC) ...................................................368 HOMSOFF (ADJC3G) ..............................................379 HOMSTAM ...............................................................327 HOPMODE ...............................................................220 HOPP........................................................................357 HORXLVDLI .............................................................327 HORXLVDLO............................................................328 HOSYNC ....................................................................33 HOTDLINT................................................................329 HOTHAMRCDL ........................................................330 HOTHAMRCUL ........................................................331 HOTHAMRDDL ........................................................331 HOTHAMRDUL ........................................................332



HOTHCMPLVDL ...................................................... 332 HOTHCMPLVUL ...................................................... 332 HOTHDCMLVDL ...................................................... 333 HOTHDCMLVUL ...................................................... 333 HOTHEFRCDL ......................................................... 333 HOTHFRCDL ........................................................... 334 HOTHFRCUL ........................................................... 334 HOTHHRDDL ........................................................... 334 HOTHHRDUL ........................................................... 335 HOTMSRM............................................................... 335 HOTMSRME............................................................. 335 HOTULINT................................................................ 335 HRACTAMRT1......................................................... 163 HRACTAMRT2......................................................... 165 HRACTT1................................................................. 166 HRACTT2................................................................. 168 HRDCMLIMTH ......................................................... 336 HRSPEECH................................................................ 33 HSCSDLLCOM......................................................... 233 HSCSDLLPRM ......................................................... 234 HSN.......................................................................... 282 HSN (CFHSY) .......................................................... 115

I

IERCHOSDCCH....................................................... 336 IMCSULNIR8PSK..................................................... 269 IMCSULNIRGMSK ................................................... 269 IMMASSFAIR ........................................................... 409 IMSIATDT................................................................. 221 IMSIFSIZ .................................................................... 10 INIBLER.................................................................... 269 INICSCH................................................................... 269 INIMCSDL ................................................................ 270 ININHO..................................................................... 337 INTAVEPR................................................................ 196 INTCLASS................................................................ 196 INTCTMST ................................................................. 80 INTERCH.................................................................. 338 INTINF...................................................................... 421 INTRACH.................................................................. 338 INTRTRFH1TODIFFSERV......................................... 67 INTRTRFH1WEI....................................................... 269 INTRTRFH2TODIFFSERV......................................... 67 INTRTRFH2WEI....................................................... 269 INTRTRFH3TODIFFSERV......................................... 67 INTRTRFH3WEI....................................................... 269 IRACHOSDCCH....................................................... 339

L

L1CTS ........................................................................ 72 L2WIN............................................................... 396, 398 L3PS................................................................. 396, 398 L3WIN............................................................... 396, 398 LAPDOVLT............................................................... 104 LAPDPOOL (LPDLM)............................................... 117 LAPDPOOL (LPDLS).................................................. 82 LAYERID .................................................................. 284 LCBM0...................................................................... 168 LCBM1...................................................................... 168 LCBM2...................................................................... 168 LCBM3...................................................................... 168 LCN2WC .......................................................... 396, 398 LCSMONTH ............................................................... 34 LCSNSSC................................................................... 34 LEVHOM .................................................................. 369 LEVONC................................................................... 369 LINKTYPE (CBCL) ................................................... 401 LINKTYPE (OMAL)................................................... 401 LKSET ...................................................................... 394

LNKA ........................................................................394 LOTERCH.................................................................339 LOTRACH.................................................................339 LOWBER (PCMA) ......................................................87 LOWBER (PCMB) ......................................................73 LOWBER (PCMG) ......................................................89 LOWBER (PCMS) ......................................................75 LOWTLEVD..............................................................237 LOWTLEVU..............................................................237 LOWTQUAD.............................................................238 LOWTQUAMRDL .....................................................238 LOWTQUAMRUL .....................................................239 LOWTQUAU.............................................................239 LPDLMN ...................................................................284 LPDLMSAT...............................................................104 LREDUNEQ (PCMB) ..................................................73 LREDUNEQ (PCMS) ..................................................75 LWWPSPRI ..............................................................221

M

M2T1.........................................................................389 M2T2.........................................................................390 M2T3.........................................................................390 M2T4E ......................................................................390 M2T4N......................................................................390 M2T5.........................................................................390 M2T6.........................................................................390 M2T7.........................................................................390 M3T1.........................................................................391 M3T10.......................................................................391 M3T12.......................................................................392 M3T13.......................................................................392 M3T14.......................................................................392 M3T17.......................................................................392 M3T19.......................................................................392 M3T1TM ...................................................................392 M3T2.........................................................................392 M3T22OR20 .............................................................393 M3T22OR21 .............................................................393 M3T2TM ...................................................................393 M3T3.........................................................................393 M3T4.........................................................................393 M3T5.........................................................................393 MACONN..................................................................415 MADGRLV ..................................................................34 MAFAILNCU .............................................................270 MAFIRACHO ..............................................................34 MAIO.........................................................................299 MAIO (CHAN) ...........................................291, 292, 295 MAIO (TRX) ..............................................................285 MAIRACHO ..............................................................340 MASCLOGFS .............................................................11 MAXFAILHO .............................................................340 MAXLAPDMN .............................................................34 MAXNCELL ................................................................34 MAXRETR ................................................................189 MEAEXTBCCH.........................................................169 MEASET...................................................................420 MECNT.....................................................................425 MEDAFUPE................................................................11 MEDAFUST ................................................................11 MELID...........................................................................9 MICROCELL (ADJC) ................................................369 MICROCELL (ADJC3G) ...........................................380 MINCCNT .................................................................425 MISTSTRSH...............................................................34 MNTBMASK ...............................................................35 MOBALLOC..............................................................283 MODBSSPFCRET......................................................59



MODBSSPFCT........................................................... 59 MOEC....................................................................... 286 MSBHIPER............................................................... 270 MSBLPER ................................................................ 270 MSBMAPER............................................................. 270 MSBSPPER.............................................................. 270 MSCOVLH.................................................................. 38 MSCPERTFLAG....................................................... 383 MSCPOOL.................................................................. 38 MSCSPC .................................................................. 384 MSCV ......................................................................... 38 MSRMAXU ............................................................... 271 MSTXPMAXCH ........................................................ 190 MSTXPMAXCL......................................................... 369 MSTXPMAXDCS (BTS [BASICS]) ........................... 169 MSTXPMAXDCS (TGTBTS) .................................... 360 MSTXPMAXGSM (BTS [BASICS])........................... 169 MSTXPMAXGSM (TGTBTS).................................... 360 MSTXPMAXPCS (BTS [BASICS])............................ 169 MSTXPMAXPCS (TGTBTS) .................................... 360 MSTXPMAXUMTS (TGTFDD) ................................. 377 MTU............................................................................ 67

N

N1 390 N2 391 N2WC............................................................... 396, 398 N3101......................................................................... 59 N3103......................................................................... 60 N3105......................................................................... 60 N391........................................................................... 91 N392........................................................................... 91 N393........................................................................... 92 NACCNTWCOR ......................................................... 39 NALLWACC.............................................................. 222 NAVGI ...................................................................... 271 NBLKACGR.............................................................. 190 NBVCBR..................................................................... 60 NBVCRR .................................................................... 60 NBVCUR .................................................................... 60 NCC1TH................................................................... 271 NCC1THADJC.......................................................... 370 NCDP1 ..................................................................... 199 NCDP2 ..................................................................... 199 NCELL...................................................................... 341 NCGPENTIME.......................................................... 370 NCGRESOFF........................................................... 370 NCGTEMPOFF ........................................................ 370 NCRARESH ............................................................. 271 NCRESELFLAG ......................................................... 39 NCSARA................................................................... 271 NCTRFPSCTH ......................................................... 271 NECI........................................................................... 40 NETWTYPE................................................................ 41 NFRAMEPG ............................................................. 192 NMDLATT1............................................................... 427 NMO ........................................................................... 68 NMULBAC................................................................ 171 NNSVCTSTR.............................................................. 68 NNSVCUBLR ............................................................. 69 NOBAKHO................................................................ 341 NOCHBLKN.............................................................. 193 NOCHFBLK.............................................................. 192 NOFREPHO ............................................................. 341 NOIREDA ................................................................... 80 NOIREDST................................................................. 80 NOTFACCH................................................................ 41 NRACPBLUPDRET.................................................... 60 NRLCMAX.................................................................. 61

NRPGRANT..............................................................199 NSEI ...........................................................................69 NSLOTST .................................................................193 NSVCI.........................................................................92 NSVLI .........................................................................92 NTWCARD .................................................................42 NTWCNDRXP ..........................................................272 NTWCONCRESFAIR................................................411 NTWCOR..................................................................272 NTWCREPPIDL........................................................272 NTWCREPPTR ........................................................272 NTWIND ...................................................................384 NUA (PCMA) ..............................................................87 NUA (PCMB) ..............................................................73 NUA (PCMG) ..............................................................89 NUA (PCMS) ..............................................................75 NY1...........................................................................195

O

OMCCPT (OMAL).....................................................401 OMLAPDRT..............................................................105 OPC..........................................................................384 OVLENTHR ................................................................42 OVLSTTHR.................................................................42

P

PAGCOORCLB ..........................................................42 PAGQOVLIND ............................................................42 PAVRLEV .................................................................240 PAVRQUAL ..............................................................241 PBGTHO...................................................................342 PCCCHLDI ...............................................................171 PCMBSTXPRL .........................................................242 PCMCON0................................................................106 PCMCON1................................................................106 PCMCON2................................................................107 PCMCON3................................................................107 PCMCON4................................................................107 PCMCON5................................................................107 PCMCON6................................................................107 PCMCON7................................................................107 PCMECH ..................................................................272 PCML (PCMB) ............................................................73 PCML (PCMG)............................................................90 PCML (PCMS) ............................................................75 PCMSN.......................................................................80 PCMSOBJ ................................................................402 PCMT..........................................................................87 PCMTYPE ..................................................................42 PCONINT..................................................................242 PCRLFTH .................................................................243 PCUID.........................................................................92 PCUPRCSLD............................................................406 PENTIME..................................................................172 PERSTLVPRI1 .........................................................273 PERSTLVPRI2 .........................................................273 PERSTLVPRI3 .........................................................273 PERSTLVPRI4 .........................................................273 PERWEEK(CTRSCHED)..........................................415 PERWEEK(HDCTR).................................................420 PFCBBHIPER...........................................................273 PFCBBLPER ............................................................273 PFCBBMAPER .........................................................273 PFCBBMAPPER.......................................................273 PFCBRMAXU ...........................................................274 PFCBRPER ..............................................................274 PFCFCSUP ................................................................69 PFCIBHIPER ............................................................274 PFCIBLPER..............................................................274



PFCIBMAPER .......................................................... 274 PFCIBMAPPER........................................................ 274 PFCIRMAXU ............................................................ 274 PFCIRPER ............................................................... 274 PFCSBHIPER........................................................... 275 PFCSBLPER ............................................................ 275 PFCSBMAPER......................................................... 275 PFCSBMAPPER ...................................................... 275 PFCSRMAXU ........................................................... 275 PFCSRPER.............................................................. 275 PFCSUP..................................................................... 69 PKTMEASREPCNT.................................................. 275 PKTNDEC ................................................................ 275 PKTNINC.................................................................. 276 PKTNMA................................................................... 276 PL 342 PLMNP ..................................................................... 172 PLNC (ADJC) ........................................................... 370 PLNC (ADJC3G) ...................................................... 380 PNOFACCH ............................................................. 172 POOLTYP................................................................... 88 PORT0 ....................................................................... 69 PORT1 ....................................................................... 69 PPLNC (ADJC)......................................................... 370 PPLNC (ADJC3G) .................................................... 380 PREAT ....................................................................... 61 PRIMARYIPADDR.................................................... 400 PRPBCCH................................................................ 276 PWRCONF............................................................... 243 PWREDSS ............................................................... 243 PWRINCSS .............................................................. 243 PWROFS.................................................................. 195 PWROUT.................................................................. 222 PWRRED.................................................................. 286

Q

QLPUB ..................................................................... 222 QLWPS..................................................................... 222 QSRHC..................................................................... 173 QSRHCINI ................................................................ 173 QSRHI ...................................................................... 173 QSRHPRI ................................................................. 276 QUALLEVHOM......................................................... 371

R

R20................................................................... 397, 399 R22................................................................... 397, 399 R23................................................................... 397, 399 RAARET................................................................... 276 RACHBT................................................................... 174 RACHLAS................................................................. 175 RACODE (PTPPKF)................................................. 277 RACODE (TGTPTPPKF).......................................... 362 RACOL (PTPPKF).................................................... 277 RACOL (TGTPTPPKF)............................................. 362 RADIOMG ................................................................ 286 RADIOMR................................................................. 287 RAENV ..................................................................... 277 RARESH................................................................... 277 RAVEW .................................................................... 352 RDGRUL .......................................................... 352, 353 RDLNKTBS .............................................................. 244 RDLNKTO ................................................................ 175 RECCRI.................................................................... 413 RELCMD .................................................................... 52 RELOBJ...................................................................... 52 REMAL (PCMA) ......................................................... 87 REMAL (PCMB) ......................................................... 73 REMAL (PCMG) ......................................................... 90

REMAL (PCMS)..........................................................76 REPTYP ...................................................................176 RETRY..............................................................397, 399 RFRSINDP ...............................................................197 RHOLTQDL ..............................................................353 RHOLTQUL ..............................................................353 RNCID ......................................................................377 ROUIPADD0...............................................................43 ROUIPADD1...............................................................43 RUGRDL...........................................................352, 353 RXLEVAMI................................................................178 RXLEVHO.................................................................342 RXLEVMIN ...............................................................371 RXLEVMINC.............................................................380 RXLV ........................................................................425 RXQUALHO..............................................................342

S

SALUNAME (BSCE) ...................................................55 SALUNAME (BTSM).................................................108 SALUNAME (TRAU)...................................................81 SANTIME..................................................................391 SCHWEIPRI1 ...........................................................277 SCHWEIPRI2 ...........................................................278 SCHWEIPRI3 ...........................................................278 SCHWEIPRI4 ...........................................................278 SDCCHCONGTH .....................................................179 SDCCHDROR ..........................................................409 SDCCHLOSR ...........................................................409 SECONDARYIPADDR..............................................400 SET BSC [ALARMSEV] ..............................................52 SET BSC [BASICS] ....................................................19 SET BSC [CONTROL]..................................................9 SET BSC [TIMER] ......................................................12 SET BSCE [ALARMSEV]............................................55 SET BSCE [REMINV] .................................................55 SET BTS [ADM]........................................................187 SET BTS [CCCH] .....................................................189 SET BTS [INTERF]...................................................196 SET BTS [OPTIONS]........................................208, 354 SET BTS [SERVICE] ................................................230 SET BTS [TIMER].....................................................198 SET HAND [BASICS] ...............................................301 SET HAND [DATA] ...................................................352 SET MEL ......................................................................9 SET OPC [MTL2]......................................................388 SET OPC [MTL3]......................................................391 SET PTPPKF............................................................288 SET PWRC...............................................................235 SET TSLA...................................................................88 SG10HOPAR............................................................342 SG10PCPAR ............................................................244 SG11HOPAR............................................................342 SG11PCPAR ............................................................244 SG12HOPAR............................................................342 SG12PCPAR ............................................................244 SG13HOPAR............................................................342 SG13PCPAR ............................................................244 SG14HOPAR............................................................342 SG14PCPAR ............................................................244 SG1HOPAR..............................................................342 SG1PCPAR ..............................................................244 SG2HOPAR..............................................................342 SG2PCPAR ..............................................................244 SG3HOPAR..............................................................342 SG3PCPAR ..............................................................244 SG4HOPAR..............................................................342 SG4PCPAR ..............................................................244 SG5HOPAR..............................................................342



SG5PCPAR.............................................................. 244 SG6HOPAR.............................................................. 342 SG6PCPAR.............................................................. 244 SG7HOPAR.............................................................. 342 SG7PCPAR.............................................................. 244 SG8HOPAR.............................................................. 342 SG8PCPAR.............................................................. 244 SG9HOPAR.............................................................. 342 SG9PCPAR.............................................................. 244 SHLAPDIT ................................................................ 108 SIMSCREL99 ............................................................. 43 SISGSNREL99 ........................................................... 61 SLAPDOVLTH.......................................................... 108 SLC .......................................................................... 394 SLLPRM ................................................................... 234 SMLCPERTFLAG..................................................... 384 SMLCSPC ................................................................ 384 SMSCBUSE ............................................................. 358 SMSINFO ................................................................. 278 SMSPFITODIFFSERV ............................................... 69 SNSADDRET ............................................................. 69 SNSCHWEIRET ......................................................... 69 SNSCONFRET........................................................... 70 SNSDELRET .............................................................. 70 SNSSIZERET............................................................. 70 SPEED145 ................................................................. 44 SPENLAW.................................................................. 44 SPFITODIFFSERV..................................................... 69 SPFIWEI................................................................... 278 SS7MTPTYP ............................................................ 384 START.............................................................. 425, 427 START(CTRSCHED) ............................................... 415 START(HDCTR)....................................................... 420 STGTTLLIINF........................................................... 278 STOP................................................................ 425, 427 STOP(CTRSCHED) ................................................. 415 STOP(HDCTR)......................................................... 420 STPIPEP .................................................................... 70 STREAMSUP ............................................................. 70 STREAMTODIFFSERV.............................................. 70 STREAMWEI............................................................ 278 SUBBAND ................................................................ 116 SUBNETMASK......................................................... 400 SUBNETMASK0......................................................... 44 SUBNETMASK1......................................................... 44 SUPPER................................................... 406, 410, 411 SYSID (BTS) ............................................................ 180 SYSID (TGTBTS) ..................................................... 361 SYSPACKSYSSUP .................................................... 45

T

T1 (CPCU).................................................................. 61 T1 (X25A) ................................................................. 399 T1 (X25D) ................................................................. 397 T2 (CPCU).................................................................. 62 T20 ................................................................... 397, 399 T200 ......................................................................... 199 T21 ................................................................... 397, 399 T22 ................................................................... 397, 399 T23 ................................................................... 397, 399 T26 ................................................................... 397, 399 T28 ................................................................... 397, 399 T3 (CPCU).................................................................. 62 T3101 ....................................................................... 201 T3105 ....................................................................... 202 T3109 ....................................................................... 204 T3111 ....................................................................... 204 T3122 ......................................................................... 45 T3141 ......................................................................... 62

T3168........................................................................278 T3169..........................................................................62 T3172..........................................................................62 T3191..........................................................................62 T3192........................................................................279 T3193..........................................................................62 T3195..........................................................................63 T3197..........................................................................45 T3212........................................................................223 T391............................................................................92 T4 .....................................................................398, 400 T4 (CPCU) ..................................................................63 T5 (CPCU) ..................................................................63 TAADJ ......................................................................180 TAVGT......................................................................279 TAVGW.....................................................................279 TBFDROR ................................................................411 TBFLOSR .................................................................412 TBFREAFAIR ...........................................................412 TBNCU .....................................................................279 TCBCSI.......................................................................45 TCCCHLDI................................................................181 TCHDROR................................................................410 TCHLOSR.................................................................410 TCONG.......................................................................92 TCONN.....................................................................384 TCONOFF ..................................................................92 TDDGQO..................................................................279 TDDMURREP...........................................................182 TDDQO.....................................................................182 TDDREPO ................................................................182 TDDREPTH ..............................................................182 TDPCPRCSLD .........................................................406 TDTMWIND ................................................................45 TEI (LPDLM).............................................................109 TEI (LPDLS) ...............................................................81 TEMPCH.....................................................................63 TEMPOFF.................................................................182 TEMPPDT...................................................................64 TERTCH ...................................................................295 TEXTULTBF ...............................................................64 TF 64 TF1 .............................................................................64 TFAILNCU ................................................................279 TGRANT...................................................................205 TGTCELL..........................................................372, 381 TGUARD...................................................................385 TGUARDTCHSD ........................................................46 TH...............................................................................64 THLEVFULHO ..........................................................343 THORQST ................................................................343 THPROXT.............................................................65, 71 THR ..........................................................................421 THROUGH..................................................................88 THRS1......................................................................404 THRS2......................................................................405 THRS3......................................................................405 THSULBAL .................................................................65 TIAR .........................................................................386 TIAS..........................................................................386 TIMEDTBFREL...........................................................65 TIMERFHO...............................................................372 TINHBAKHO.............................................................372 TINHFAIHO ..............................................................372 TINHFAIHO (ADJC3G).............................................381 TINHRDGR...............................................................353 TINHRUGR...............................................................353 TINOIERCHO ...........................................................343 TINT..........................................................................386



TNOCH..................................................................... 205 TNSVCBLK................................................................. 71 TNSVCPTST .............................................................. 71 TNSVCR..................................................................... 71 TNSVCTST ................................................................ 71 TOTERM .................................................................. 395 TPFCBUFF................................................................. 65 TRACE ............................................................. 398, 400 TRACECH ................................................................ 415 TRACEMG.................................................................. 47 TRACEMR.................................................................. 47 TRACERECTYP....................................................... 415 TRANSPM.................................................................. 48 TREL ........................................................................ 387 TRESEL.................................................................... 280 TRFCT........................................................................ 49 TRFHITH .................................................................. 344 TRFHOE................................................................... 345 TRFHOM .................................................................. 373 TRFHORXLVMOFF.................................................. 374 TRFHOT................................................................... 346 TRFKPRI .................................................................. 348 TRFLTH.................................................................... 348 TRFMMA .................................................................. 349 TRFMS ..................................................................... 349 TRFPS........................................................................ 50 TRFPSCTRLT .......................................................... 280 TRXAREA................................................................. 287 TRXFREQ ................................................................ 287 TRXMD..................................................................... 287 TSBS ........................................................................ 387 TSC .................................................. 291, 293, 295, 300 TSLA ........................................................................ 394 TSNPRO..................................................................... 70 TSULBAL.................................................................... 65 TSYNC (BTS [TIMER])............................................. 205 TSYNC (TRAU) .......................................................... 81 TSYNCDL................................................................. 205 TSYNCR................................................................... 206 TSYNCUL................................................................. 206 TTRAU ..................................................................... 206

TUESP......................................................................381 TUPLREP .................................................................207 TWCUSER................................................................387 TXDIVTSEXCPT.......................................................183 TXDIVTSPAR ...........................................................183 TYPOFAMC................................................................50 TYPOFETH.................................................................50 TYPOFNSVCCONF....................................................70

U

UADJ ........................................................................381 UMECNO..................................................................382 UMTSSRHPRI ..........................................................183 UPGRFREQ ...............................................................66 UPTLEVD .................................................................245 UPTLEVU .................................................................245 UPTQUAD ................................................................245 UPTQUAMRDL.........................................................246 UPTQUAMRUL.........................................................247 UPTQUAU ................................................................247 USECNO ..................................................................382 USECNONCRESEL..................................................382 USFGRAN ................................................................287 USG..........................................................................374 USRSCP...................................................................382 USRSCPNCRESEL..................................................383

V

VGRULF ...................................................................207 VOLDL........................................................................88 VOLUL........................................................................88 VQEST........................................................................81

W

WMOD..................................................................74, 76 WPSPREF ................................................................223

X

X121ADDR (CBCL) ..................................................401 X121ADDR (OMAL)..................................................401

bsc database parameter description br8.0 - updated draft

Documents