You are on page 1of 703

GERAN-S Database Parameter Planning & Engineering Manual BR10.

0
Version 17.09.10
__________________________________________________________________________________________________________

RG20 (BR)
BSC Database Engineering Manual

Network Engineering
August 2010
For internal use only!

Authors: Eckardt Bertermann, (up to BR9.0)


Krystian Majchrowicz (BR10.0 and RG20)
Nokia Siemens Networks NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

1 / 703

Network Engineering

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Trademarks:
All designations used in this document can be trademarks, the use of which
by third parties for their own purposes could violate the rights of their owners.

Reason for Update


Summary:
Document Issue for Release BR10.0.
Details:
Chapter/Section

Reason for Update

Issue history
Issue
Number

Date of Issue

Reason for Update

1.0

08/2010

First Document Issue for Release RG20 (BR) after


NE internal review.

Authors
In addition to the author named on the cover page the following persons
have collaborated on this document:

2 / 703

Name

Department

Marcin Grygiel

NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

Piotr Grzybowski

NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

Krystian Krysmalski

NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

Sebastian Lasek

NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

Grzegorz Lehmann

NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

Sebastian ysiak

NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

Andrzej Macioek

NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

Dariusz Tomeczko

NWS LTE RA E2E Mgmt SA NE GSM & LTE Migration

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

!
IMPORTANT
This document is not officially released to customers and is designed as
quick reference document for BR BSC database parameters.
This document is a working document and is continuously modified and
enhanced with the latest information. Changes may not be explicitly marked!

The documents purpose is to


- describe and explain the meaning of the BSC database parameters
- describe and explain the parameters association to related features
- provide cross-references between parameters that logically belong
together, but are possibly distributed over different objects
- provide rules and hints that have to be considered during the decision
for the parameter values to guarantee a useful application of the parameter.
The documents purpose is NOT
- to provide binding recommendations for parameter value settings!
- to be used as a reference database with respect to the parameter
settings!!
The used settings were not verified for a live netwok application!

NO GUARANTEES FOR CORRECTNESS OF THE CONTENTS!


CONTENTS ARE NOT COMMERCIALLY BINDING!
Any comments for corrections or suggestions for improvements are welcome!

3 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

1 Database RG20 (BR)


1.1 RG20 (BR) Object Tree of functional BSC database objects

4 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

The above diagram shows the architecture of the functional objects in the BSC database, HW objects
are not considered.
Note: The objects BTSMOSUSW, TRAOSUSW, SCANCO, the scanner objects ('SCANxxxx') are not
considered in this document.

5 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Notes:
1) The parameters marked by
(compared to BR10.0).

grey background

are new in RG 20 (BR)

2) Changes of parameter values, value ranges and default values are indicated by
highlighted letters. Changes of parameter names are marked, too.
3) Notes on parameter grouping:
- For a better logical structure, the parameters are grouped in the 'pseudopackages' (e.g. CREATE BTS [BASICS], SET BTS [CCCH] etc.) as used in the
LMT GUI.
- Within each package, parameters are sorted alphabetical order.

6 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

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

object:
format:
range:

MEL
hour minute-secondday-month-year
hour 0..23
minute 0..59
second 0..59
day 1..31
month 1..12
year 1992..2099

MELID=1;
object:
range:

MEL
0..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 object entry for the BOF:

NAME= BOF:0..0,
FLIST =none

< The BOF ((Blocking Optional Features) object is added to the


configuration database with a single autocreated instance and lists
the features available for the customer.>
Object name.- address of the managed object
Feature List , this parameter defines the list of the optional feature
available for the customer.

object:
BOF
range flist1 & flist2 & ... flist200<NULL>
VALUE_N = feature - [quantity] internalStatus
feature = a32_bsc72_pcu a32_bsc120_pcu
a38_ebsc_pcu f34_ul_inc_red
f35_deriv_ho_pwr f56_amr
f71_nccr_2g_2g f72_ho_2g_3g
f74_ip_o_link f78_edge
f84_qos_streaming f85_nacc
f86_nccr_2g_3g f92_eda f93_hsgb
f94_int_echo_ctrl f95_int_noise_red
f96_int_level_ctrl f99_dtm f102_flex_gb
f103_ciphering_a53 f104_arp
f105_central_ns f106_ext_nacc
f107_ms_class_30_33
f109_gb_stream_enh f112_delayed_pwrc
f113_bsc72_trx f113_bsc120_trx
f113_ebsc_trx f114_bsc72_pdt_pcu
f114_bsc120_pdt_pcu f114_ebsc_pdt_pcu
f116_ciphering_vgcs f117_rfacch
f118_trx_test_mode f119_multi_mnc
f110_group_call_bp f621_cb_drx
f124_flex_a f125_amr_wb
f126_rep_sacch f127_enh_pcu_capacity
license_43 f130_pcu_mod_load_bal
f132_vcgs_vbs_react f133_idra

7 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
b21_ps_ctr b21_ps_imsi_tracing
f560_rtpm f122_virtual_etrau
f145_standby_trx f135_shunting_yards
f144_tom_tom license_54 f604_ibho_2g
f604_ibho_3g license_57
f164_lte_cell_resel f152_lte_interworking
f155_asci_cell_resel license_61
license_62 license_63 license_64
license_65 license_66 license_67
license_68 license_69 license_70
license_71 license_72 license_73
license_74 license_75 license_76
license_77 license_78 license_79
license_80
quantity = 0..65534
internalStatus = blocked idle active
default: none

OPC=none;
object:
range:

BOF

Originating Point Code, this parameter identifies the originating


system (BSS). It consists of three fields: NetworkClusterMember,
NetworkCluster, NetworkIdentifier.

for NetworkClusterMember: 0 - 255


(0-255 for CCITT
1-255 for ANSI)
for NetworkCluster: 0 - 255
(0-63 for CCITT
0-255 for ANSI)
for NetworkIdentifier: 1 - 254
(NO_CONFIG for CCITT
1-254 for ANSI)

default:

none

PWD =none;
object:
range:
default:

BOF
15 characters string
none

QTY =none;
object:
range:
default:

8 / 703

Password - this attribute indicates a password associated to a


feature. It is a string of 15 hexadecimal values.

Quantity - this attribute provides the Capacity Level of an optional


feature.

BOF
0 .. 65534
none

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the object entry for the RSUFW:


<The RSUFW (Replaceable Software Unit FirmWare) represents an
instance of a managed object class identifying the FW images files.
All related commands (except CREATE RSUFW) consist of two fields
but only one can be used (NAME or USER LABEL).
20 instances for this object are allowed.>
NAME= RSUFW:0..19,

Object name.- address of the managed object

ULAB =

User label, this parameter assigns a user friendly name (is a userdefined string) to the BSC Executable Software Unit DB (note it is the
same of the related BSC Reusable Software Unit DB).

object:
default:

RSUFW;
130 characters string

PROCFWID =none
object:
range:

default:

RSUFW
SMAC_FW; LIET_FW;
MCP_FW; AP_FW;
UPM_FW; LISO_FW;
SHELFMGR_FW; LME_FW;
none

SRCPATH=
object:
range:

9 / 703

Processor firmware identifier, this parameter identifies the


processor type for which the FW file is to be transferred.
Range modified in BR10.0

Source path, this attribute represents the source path of the files
which are to be copied or moved.

RSUFW

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the object entry for the RSUPCH:


<The RSUPCH (Replaceable Software Unit Patch) represents an
instance of a managed object class identifying a software patch.
The RSUPCH object also handles the unpatch (if any) associated to a
software patch. The unpatch is a particular patch that allows to
remove a patch without any system downtime. Each unpatch is
associated to a specific patch. 1200 instances for this object are
allowed (maximum 400 instances for each software load).
All related commands (except CREATE RSUPCH) consist of two
fields but only one can be used (NAME or USER LABEL SWLH).>
NAME=RSUSWLH:0..59/RSU
EXE:0..249/RSUPCH:0..399,

Object name.- address of the managed object

PERM =none;

Permanent, this parameter can be equal to TRUE or FALSE.


If it is set equal to TRUE the patch is automatically loaded at the next
"bring-up" operation; otherwise it is not loaded.

object:
range:
default:

RSUPCH
TRUE, FALSE
none

PRIOSLOTN=<NULL>;
object:
range:
default:

RSUPCH
0..65000
<NULL>

PROCTYPE=none;
object:
range:
default:

RSUPCH
GENERICEXE; SMAC; LIET;
MCP; AP; UPM; LISO; LME;
none

SRCPATH=;
object:
range:
default:

RSUPCH;

ULABSWLH=
object:
range:
default:

10 / 703

Source path, this attribute represents the source path of the files
which are to be copied or moved

RSUPCH

ULAB =
object:
default:

Priority slot number, This attribute stores an integer value; at bring


up, the loading sequence of the patches will be determined by sorting
the patches in function of the slot number.
The default value <NULL> is valid for the unpatches; a value which
will cause the patch to be loaded after the ones currently created (i.e.
the current maximum slot number plus one) for the patches.
Processor type, this parameter identifies the processor type for the
file to be transferred in the eBSC disk.

User label, this parameter assigns a user friendly name (is a userdefined string) to the BSC Executable Software Unit DB (note it is the
same of the related BSC Reusable Software Unit DB).
User label of SW load header. This parameter defines the user label
of the software load header and it consists of 30 characters string.

RSUPCH;
1..30 character string

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the object entry for the APD:


The APD (AP Dependent) board has the role to provide additional Radio Resource Management
(RRM) capabilities for large configurations in which not all sites can be mapped to APM due to
capacity needs.

SET APD :
NAME=APD:1..5

Object path name.

BLADEPOS1=,

Blade position 1. The attribute indicates the shelf/slot in the rack


where 1st (active) APD module is to be plugged in and the instance
number of the relevant object that shall be created.
Introduced in BR10.0

object:
range:

default:

APD
path name (e.g.
'BLADEPOS1=EBSCRACK:0/
SHELF:0/APD:1')
none

Blade position 2. The attribute indicates the shelf/slot in the rack


where 2nd (redundant) APD module is to be plugged in and the
instance number of the relevant object that shall be created. This
APDrange:
path name (e.g.
Application Processor does redundancy of the other one, whose
'BLADEPOS1=EBSCRACK:0/ position is set by means of BLADEPOS1.
SHELF:0/APD:2')
Introduced in BR10.0

BLADEPOS2=,
object:

default:

none

Creating the APM:


The APM (AP Master) provides the single point of access for the core
network, handles centralised algorithms and also handles an own set
of sites in terms of Radio Resource Management RRM.
CREATE APM:
NAME=APM:0..0

Object path name.

BLADEPOS1=,

Blade position 1. The attribute indicates the shelf/slot in the rack


where 1st (active) APM module is to be plugged in and the instance
number of the relevant object that shall be created.
Introduced in BR10.0

object:
range:

default:

APM
path name (e.g.
'BLADEPOS1=EBSCRACK:0/
SHELF:0/APD:2')
none

Introduced in BR10.0

Blade position 2. The attribute indicates the shelf/slot in the rack


where 2nd (redundant) APM module is to be plugged in and the
instance number of the relevant object that shall be created. This
APM
Application Processor does redundancy of the other one, whose
path name (e.g.
'BLADEPOS1=EBSCRACK:0/ position is set by means of BLADEPOS1.
SHELF:0/APD:2')
Introduced in BR10.0

BLADEPOS2=,
object:
range:

default:

none

Introduced in BR10.0

11 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

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 and 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. From 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
Radio Network Analyser ) RNA application.

object:
unit:
range:
default:

BSC [CONTROL]
1 Mbyte
1-12
1

IMSIFSIZ=30,
object:
unit:
range:
default:

BSC [CONTROL]
1 Mbyte
0..60
30

HDCFS=1,
object:
unit:
range:
default:

12 / 703

BSC [CONTROL]
1 Mbyte
1..24
1

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. From 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 Radio Network Analyser (RNA)application.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

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.

MASCLOGFS=3,
object:
unit:
range:
default:

BSC [CONTROL]
1 Mbyte
1..24
3

MEDAFUPE=UPPE_0H,
object: BSC [CONTROL]
range: UPPE_0h= no per. upl..
UPPE_15m = Upl. prd. 15 min.
UPPE_30m = Upl. prd. 30 min.
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

default:

BSC [CONTROL]
upload start hour
upload start minute
upload start hour
upload start minute

PSCFS=1;
object:
unit:
range:
default:

13 / 703

BSC [CONTROL]
1 Mbyte
1..12
1

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.

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

MEDAFUST=0-0;
object:
range:

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.

0..23
0..59
0
0

PS CTR file size, this attribute indicates the maximum size of the 'PS
Cell Traffic Recording' logfile on the BSC disk. The feature PS 'Cell
Traffic Recording' or 'PS Cell Trace' is a feature used to record cell
specific PS call events for monitoring purposes.The parameter PS
CFS specifies the maximum file size for the PS CTR trace logfiles in

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

the BSC directory. When a PS CTR tracing procedure is in progress,


the BSC writes the binary trace data to the open binary trace file. On
TBF rerlease, a trace record is generated and written to the PS CTR
trace logfile. The parameter PSCFS specifies the maximum size of
this PS CTR logfile. When the trace logfile exceeds the size specified
by PSCFS, it is closed and transferred to the BSC directory. From
there it is compressed and uploaded to the RC at the next possible
point of time (automatic upload takes place every 5 minutes). A PS
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 Radio Network Analyser )RNA
application.
Introduced in BR10.0
PSIMSIFSIZ=1;
object:
unit:
range:
default:

14 / 703

BSC [CONTROL]
1 Mbyte
0..30
1

PS IMSI file size, this parameter is associated to the feature 'PS IMSI
Tracing' (see command CREATE TRACE) and specifies the
maximum file size for the PS IMSI trace files in the BSC directory.
When an PS IMSI tracing procedure is in progress, the BSC writes
the binary trace data to the open binary trace file. The parameter
PSIMSIFSIZ specifies the maximum allowed size of this binary trace
file. When the tracing process is finished the binary trace files are
closed and compressed. Then 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 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 Radio
Network Analyser (RNA) application
Introduced in BR10.0.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.

BSCT10=HLFSEC-10,

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.

object:
unit:
range:
default:
Reference:

BSC [TIMER]
HLFSEC=0,5s
SEC5=5s
0..254
HLFSEC-10
GSM 08.08 (04.08)

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

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)

15 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

SCT11PUB=HLFSEC-16,
object:
unit:
range:
default:
Reference:

BSC [TIMER]
HLFSEC=0,5s
SEC5=5s
0..254
HLFSEC-16
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.
T11
purpose:
start:
stop:

Limitation of the queuing time for an TCH request due to Assignment


sending of the QUEUING INDICATION (BSC->MSC)
- 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.

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.

16 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

BSCT11WPS=HLFSEC-16,
object:
unit:
range:
default:

BSC [TIMER]
HLFSEC=0,5s
SEC5=5s
0..254
HLFSEC-16

BSCT14PUB=HLFSEC-16,
object:
unit:
range:
default:
FRS-No.:
SF-No.:

BSC [TIMER]
HLFSEC=0,5s
SEC5=5s
0..254
HLFSEC-16
94688
10513

BSCT14WPS=HLFSEC-16,
object:
unit:
range:
default:
FRS-No.:
SF-No.:

BSC [TIMER]
HLFSEC=0,5s
SEC5=5s
0..254
HLFSEC-16
94688
10513

BSCTAST= 5,
object:
unit:

BSC [TIMER]
s

range:
default:
FRS-No.:
SF-No.:
Reference:

1..30
5
89901
10515
GSM 08.08

17 / 703

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.

BSC timer T14 Public, this timer determines the maximum allowed
queuing time for the ASCI calls in the public queue as required by the
3GPP standard. The timer is modelled as a sequence of two fields:
TUNIT and TVALUE. The first field assumes the value of 500ms
(HLFSEC) or 5 seconds (SEC5), while second field is an integer with
range 0..254.
Introduced in BR10.0
For further details please refer to the description of parameter
EASCICRE.
BSC timer T14 WPS, this timer determines the maximum allowed
queuing time for the ASCI calls in the WPS queue as required by the
3GPP standard. The timer is modelled as a sequence of two fields:
TUNIT and TVALUE. The first field assumes the value of 500ms
(HLFSEC) or 5 seconds (SEC5), while second field is an integer with
range 0..254.
Introduced in BR10.0
For further details please refer to the description of parameter
EASCICRE.
BSCTimerTast, this timer determines the time to report periodical
information to the MSC about the cells which changed state since the
last sent report message. Applicable for an ASCI call, which the ASCI
Broadcast Point in BSS feature is being applied to
(ASCIBROADP=TRUE).
The timer is always restarted till the end of the call. The default value
has been fixed 5 seconds; higher values may cause problems in case
of an INTER-cell MSC-controlled HO of a VGCS subsequent talker in
1 Channel Model.
Introduced in BR10.0

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

BSCTQHO=HLFSEC-20,
object:
unit:
range:
default:
Reference:

BSC [TIMER]
HLFSEC=0,5s
SEC5=5s
0..254
HLFSEC-20
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.#
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.

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:
unit:
range:
default:

BSC [TIMER]
HLFSEC=0,5s
SEC5=5s
0..254
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, 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
object:
BSC [TIMER]
unit:
HLFSEC=0,5s
relevant if the feature 'Wireless Priority Service (WPS)' is applied (see
SEC5=5s
parameter BSCTQHOPUB). The parameter BSCTQHOWPS defines
range:
0..254
the queing timer TQHO (see parameter BSCTQHO which is used for
default:
HLFSEC-16
ordinary queing) for the 'WPS' queue.

18 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ENACCTREP=30,
object:
unit:
range:
default:
FRS-No.:
SF-No.:

BSC [TIMER]
1 min.
15..750
30[min]
86654, 90351
10518, 10508

Introduced in BR9.0

External NACC Timer for Repetitions, this parameter is related to

the features 'External NACC' (see parameter ENACCE in command


SET BSC [BASICS])' and 'RAN Information Management' (RIM). RIM
comprises signaling procedures (RIMApp = RIM Applications)
executed between two BSCs via the connected SGSN and which are
employed whenever the 'controlling BSC' requests particular call
processing information from the 'serving BSC'.
ENACCTREP determines the time, after which the controlling BSC
retries a particular RIM procedure (RIR, RI or RIAE - for further
details, please refer to the descriptions of parameters ENACCTRI,
ENACCTRIR and ENACCTRIAE (see below)), that were not
successfully completed even after N repetitions (N depends on the
type of message and is defined by the parameters ENACCTRICM (for
RI), ENACCTRIAECM (for RIAE) )of the original message.
T(REP) is started in the BSC when it starts the RI, RIR or RIAE
procedures towards the remote peer BSC (via the SGSN) and is
stopped when the corresponding procedure was successfully
completed. When the corresponding procedures were not
successfully completed after all attempts, i.e. no positive response or
acknowledgement was received after as many message repetitions
as defined by the repetition threshold parameters ENACCTRICM,
ENACCTRIRCM or ENACCTRIAECM (see below) and T(REP)
expires, the corresponding procedure (RI, RIR or RIAE) is attempted
again until it is either successfully completed or until the
abovementioned repetition thresholds are reached again.
Notes:
- A RIM_Failure_Indication does not stop the T(REP) timer inside the
RIM Application (in BR9.0 the only RIM Application is External
NACC); T(REP) will expire after the specified amount of time.
- The T(REP) handling is a task of the RIM Application.

19 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ENACCTRL=24,
object:
unit:
range:
default:
FRS-No.:
SF-No.:

BSC [TIMER]
1h
1..60
24[h]
86654, 90351
10518, 10508

ENACCTRI=2,
object:
BSC [TIMER]
unit:
1s
range:
2..8
default:
2[s]
FRS-No.: 86654, 90351
SF-No.:
10518, 10508
Introduced in BR9.0

ENACCTRICM=3,
object:
BSC [TIMER]
range:
1..12
default:
3
FRS-No.: 86654, 90351
SF-No.:
10518, 10508
Introduced in BR9.0

ENACCTRIAE=2,
object:
BSC [TIMER]
unit:
1s
range:
2..8
default:
2[s]
FRS-No.: 86654, 90351
SF-No.:
10518, 10508
Introduced in BR9.0

20 / 703

External NACC Timer for Repetition Long, this parameter is related


to the features 'External NACC' (see parameter ENACCE in
command SET BSC [BASICS])' and 'RAN Information Management'
(RIM). RIM comprises signaling procedures executed between two
BSCs via the connected SGSN and which are employed whenever
the 'controlling BSC' requests particular call processing information
from the 'serving BSC'.
ENACCTRL represents the maximum value of the BSC timer
T(REPL). When controlling BSC starts an RIR Procedure towards
serving BSC (please see parameter ENACCTRIR for further details),
it can happen that the serving BSC does not support the ENACC
functionality (yet). In this case the controlling BSC will receive a RAN
INFORMATION ERROR (RIE) with cause Unknown Application Id.
The timer T(REPL) is started on reception of the aforementioned
message. When T(REPL) has been started, the BSC tries to repeat
the RIR procedure on every T(REPL) timer expiry. Thus T(REPL)
timer takes care not to transmit too many RIR messages to BSCs that
do not support the RIM functionalities.
External NACC timer RI, this parameter is related to the features
'External NACC' (see parameter ENACCE in command SET BSC
[BASICS])' and 'RAN Information Management' (RIM). RIM comprises
signaling procedures executed between two BSCs via the connected
SGSN and which are employed whenever the 'controlling BSC'
requests particular call processing information from the 'serving BSC'.
ENACCTRI determines the value of the timer T(RI) which defines the
maximum waiting time for RI acknowledgement for ENACC.
RI is the abbreviation for 'RAN Information Send Procedure' which the
'serving' BSC starts to transfer the RIMApp information towards the
'controlling' BSC, that has previously requested this information via
the 'RAN Information Request Procedure' (RIR).
T(RI) is started in the serving BSC when it sends the RAN
INFORMATION (RI) message towards the controlling BSC (via the
SGSN) and is stopped when the RAN-INFORMATION ACK (RIA)
message has been received from the controlling BSC. When T(RI)
expires, the RI procedure is repeated again until the expected
response is received or until the maximum number of repetitions
(determined by parameter ENACCTRICM (see below)) is reached.
Notes:
- T(RI) is only started if an acknowledgement is required.
External NACC timer RI Counter Max, this parameter determines a
threshold that determines the maximum number of consecutive RI
procedures. The RI procedure is repeated if it could not be
successfully completed (i.e. no response / acknowledgement was
received from the remote peer BSC) on the preceding attempt. For
further details, please refer to parameter ENACCTRI (see above).
External NACC timer RIAE, this parameter is related to the features
'External NACC' (see parameter ENACCE in command SET BSC
[BASICS])' and 'RAN Information Management' (RIM). RIM comprises
signaling procedures executed between two BSCs via the connected
SGSN and which are employed whenever the 'controlling BSC'
requests particular call processing information from the 'serving BSC'.
ENACCTRIAE determines the value of the timer T(RIAE) which
defines the maximum waiting time for RIAE acknowledgement.
RIAE is the abbreviation for 'RAN Information Application Error
Procedure' which is started by the 'controlling' BSC upon detection of

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

an error in a received RIMApp information container unit.


T(RIAE) is started in the controlling BSC when it sends the
RANINFORMATION-APPLICATION-ERROR (RIAE) message
towards the serving BSC (via the SGSN) and is stopped when the
RAN-INFORMATION ACK (RIA) message has been received from
the serving BSC. When T(RIAE) expires, the RIAE procedure is
repeated again until the expected response is received or until the
maximum number of repetitions (determined by parameter
ENACCTRIAECM (see below)) is reached.
ENACCTRIAECM=3,
object:
BSC [TIMER]
range:
1..12
default:
3
FRS-No.: 86654, 90351
SF-No.:
10518, 10508
Introduced in BR9.0

ENACCTRIR=2,
object:
BSC [TIMER]
unit:
1s
range:
2..8
default:
2[s]
FRS-No.: 86654, 90351
SF-No.:
10518, 10508
Introduced in BR9.0

ENACCTRIRCM=3,
object:
BSC [TIMER]
range:
1..12
default:
3
FRS-No.: 86654, 90351
SF-No.:
10518, 10508
Introduced in BR9.0

TEMLD=HLFSEC-12,
object:
unit:

BSC [TIMER]
MS100=100ms
HLFSEC=0,5s
SEC5=5s
range:
0..255
default:
HLFSEC-12
Introduced in BR9.0

21 / 703

External NACC timer RIAE Counter Max, this parameter determines


a threshold that determines the maximum number of consecutive
RIAE procedures. The RIAE procedure is repeated if it could not be
successfully completed (i.e. no response / acknowledgement was
received from the remote peer BSC) on the preceding attempt. For
further details, please refer to parameter ENACCTRIAE (see above).
External NACC timer RIR, this parameter is related to the features
'External NACC' (see parameter ENACCE in command SET BSC
[BASICS])' and 'RAN Information Management' (RIM). RIM comprises
signaling procedures executed between two BSCs via the connected
SGSN and which are employed whenever the 'controlling BSC'
requests particular call processing information from the 'serving BSC'.
ENACCTRIR determines the value of the timer T(RIR) which defines
the maximum time the controlling BSC waits, after having sent the
RIR, for the reception of the serving BSC's response (RI).
RIR is the abbreviation for 'RAN Information Request Procedure'
which the 'controlling' BSC starts to request the RIMApp information
from the 'serving' BSC. In response, the 'serving' BSC starts the 'RAN
Information Send Procedure' (RI).
T(RIR) is started in the controlling BSC when it sends the
RANINFORMATION REQUEST (RIR) message towards the serving
BSC (via the SGSN) and is stopped when the RAN-INFORMATION
(RI) message has been received. When T(RIR) expires, the RIR
procedure is repeated again until the expected response is received
or until the maximum number of repetitions (determined by parameter
ENACCTRIRCM (see below)) is reached.
External NACC timer RIR Counter Max, this parameter determines
a threshold that determines the maximum number of consecutive RIR
procedures. The RIR procedure is repeated if could not be
successfully completed if it could not be completed (i.e. no response /
acknowledgement was received from the remote peer BSC) on the
preceding attempt. For further details, please refer to parameter
ENACCTRIR (see above).
Timer Emergency Low Delay, this parameter determines the value
of the T_RESP (Timer for Response) timer, which controls the
duration of how long LCS (Location Services) response from SMLC to
BSC on the Lb interface can be performed by the SMLC, for all LCS
procedures with client type Emergency and QoS Low Delay.
The default value of TEMLD timer is 6 seconds. TEMLD should be set
at a value lower than TEMDTOL, TNEMLD and TNEMDTOL (see
below). The TEMLD timer is independent of positioning method and
runs in the BSC. This timer is introduced by feature Configurable
T_RESP LCS Timer in BSC.
The TEMLD timer is one of four timers (TEMLD, TEMDTOL,
TNEMLD, TNEMDTOL, see below) which were introduced in BR9.0
as a solution solving problem of hard-coded (i.e. not configurable)
value of T_RESP timer = 10 seconds. This value of T_RESP did not

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

accommodate the U-TDOA positioning procedure (used by U.S.


operators) which can take 30 seconds. If the T_RESP timer expires
before response is received, BSC indicates a location failure to the
requesting entity.
Depending on requested client type (Emergency / Non-Emergency)
and QoS response time requirement (Low Delay / Delay Tolerant)
appropriate timer is chosen for T_RESP value:
Time requirement

Low Delay

Delay Tolerant

Emergency call

TEMLD

TEMDTOL

Non-Emergency call

TNEMLD

TNEMDTOL

Client type

TEMDTOL=HLFSEC-60,
object:
unit:

BSC [TIMER]
MS100=100ms
HLFSEC=0,5s
SEC5=5s
range:
0..255
default:
HLFSEC-60
Introduced in BR9.0

TNEMLD=HLFSEC-36,
object:
unit:

BSC [TIMER]
MS100=100ms
HLFSEC=0,5s
SEC5=5s
range:
0..255
default:
HLFSEC-36
Introduced in BR9.0

TNEMDTOL=HLFSEC-90,
object:
unit:

BSC [TIMER]
MS100=100ms
HLFSEC=0,5s
SEC5=5s
range:
0..255
default:
HLFSEC-90
Introduced in BR9.0

22 / 703

For call type and QoS requirement values mapping, please refer to
the feature description (Configurable T_RESP LCS Timer in BSC )
Timer Emergency Delay Tolerant, this parameter determines the
value of the T_RESP (Timer for Response) timer, which controls the
duration of how long LCS (Location Services) response from SMLC to
BSC on the Lb interface can be performed by the SMLC, for all LCS
procedures with client type Emergency and QoS Delay Tolerant.
The default value of TEMDTOL timer is 30 seconds. TEMDTOL
should be set at a value greater than TEMLD (see above) and lower
than TNEMDTOL (see below).
The TEMDTOL timer is independent of the positioning method and
runs in the BSC. This timer is introduced by feature Configurable
T_RESP LCS Timer in BSC.
For more details about T_RESP timer settings, please refer to the
description of the TEMLD timer (see above).
Timer Non-Emergency Low Delay, this parameter determines the
value of the T_RESP (Timer for Response) timer, which controls the
duration of how long LCS (Location Services) response from SMLC to
BSC on the Lb interface can be performed by the SMLC, for all LCS
procedures with client type Emergency and QoS Low Delay.
The default value of TNEMLD timer is 18 seconds. TNEMLD should
be set at a value lower than TNEMDTOL (see below) and greater
than TEMLD (see above).
The TNEMLD timer is independent of positioning method and runs in
the BSC. This timer is introduced by feature Configurable T_RESP
LCS Timer in BSC.
For more details about T_RESP timer settings, please refer to the
description of the TEMLD timer (see above).
Timer Non-Emergency Delay Tolerant, this parameter determines
the value of the T_RESP (Timer for Response) timer, which controls
the duration of how long LCS (Location Services) response from
SMLC to BSC on the Lb interface can be performed by the SMLC, for
all LCS procedures with client type Emergency and QoS Low Delay.
The default values of TNEMDTOL timer is 45 seconds. The
TNEMDTOL timer should be set at value greater than the TNEMLD
and TEMDTOL timer (see above).
The TNEMDTOL timer is independent of positioning method and runs
in the BSC. This timer is introduced by feature Configurable T_RESP
LCS Timer in BSC.
For more details about T_RESP timer settings, please refer to the
description of the TEMLD timer above.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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;

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:

object:
range:
default:

BSC [BASICS]
PER0, PER10, PER20,
PER30 ... PER90
PER0

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.

23 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ASCIBROADP=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 89901
SF-No.:
10515
Introduced in BR9.0

ASCIDTXDL=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 89901
SF-No.:
10515
Introduced in BR9.0

ASCIECR=FALSE,
object:
range:
default:
FRS-No.:

BSC [BASICS]
TRUE, FALSE
FALSE
97531

SF-No.:
10567
Introduced in RG20 (BR)

ASCIONECHMDL=FALSE,
object:
range:
default:

24 / 703

BSC [BASICS]
TRUE, FALSE
FALSE

ASCI Broadcast Point, this parameter is only relevant if the feature


ASCI is enabled (see parameter ASCISER in command SET BTS
[CCCH]) and determines whether the feature 'Group Call Broadcast
Point' is enabled (TRUE) or disabled (FALSE) is enabled in the BSC
for ASCI calls.
The implementation of the ASCI Services requires for each cell of the
ASCI service area of a call one common broadcast channel, where
the listener users in the cell are able to receive the speech of the
talker. As specified by the relevant standards, for each cell of the
ASCI call there is an equivalent channel assigned between MSC and
the BSC. With the increased number of cells using ASCI services a
lot of resources on the A Interface and Asub Interface would be
required.
With ASCIBROADP=TRUE the voice broadcast in each cell of the
BSS is now shifted to the BSC. This significantly saves channels on
the A interface and therefore also on the Asub interface. Only one
TCH channel on these interfaces is used to connect the MSC to each
BSS which is controlling cells in the service area of that ASCI call.
When the feature is enabled the time alignment in BTS for the
relevant ASCI group channels will be switched off.
Note: The feature was originally planned for BR9.0, but was finally
postponed to BR10.0. Thus, in BR9.0 the parameter is available but
has no effect.
ASCI DTX Downlink, this parameter is only relevant if the feature
ASCI is enabled (see parameter ASCISER in command SET BTS
[CCCH]) and determines whether DTX DL is enabled (TRUE) or
disabled (FALSE) for ASCI calls. If the parameter ASCIBROADP (see
above) is set to FALSE, the parameter ASCIDTXDL is ignored.
For further details about DTX DL please refer to the description of
parameter DTXDL in command SET BTS [OPTIONS].
ASCI Enhanced Cell Selection, this parameter is only relevant if the
feature ASCI is enabled (see parameter ASCISER in command SET
BTS [CCCH]) and determines if Enhanced Cell Selection feature is
active or not.
The purpose of the Enhanced Cell Reselection (ECR) procedure,
based on supporting both SI10bis and SI10ter sent upon the group
TCH downlink SACCH, is to reduce the time needed for the cell
reselection procedure executed by listener subscribers when
connected in group receive mode to an ASCI call.
ECR allows to reduce the speech gaps during the cell reselection to a
value lower than 500ms, as indicated by GSM-R requirements
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 group 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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 'twoway' TCH is occupied by the service subscriber ('1 channel mode').
ASMONTH=ENABLED(30)ENABLE(60)-ENABLED(90),
object:
range:
default:

BSC [BASICS]
ENABLED(1..100),
DISABLED
ENABLE(30) (minor)
ENABLE(60) (major)
ENABLE(90) (critical)

ASUBISAT=FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

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.
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 Abis interface (see parameter LPDLMSAT in command
CREATE/SET BTSM) can be configured as satellite link. However,

25 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.
Best effort priority PFC, this parameter is relevant for the feature
'Allocation/Retention Priority' (ARP, see parameter EARP in BSC
object
below) and defines the three 'Predefined PF Context' values
object:
BSC [BASICS]
format:
<allocation priority>- Allocation Priority
<preemption capability>- Preemption capability Indicator
<preemption vulnerability>
- Preemption vulnerability indicator
range:
allocation priority: 1..3
related to type of service 'Best Effort' as for this service the ARP
preemption capability: 0, 1
preemption vulnerability: 0,1 parameters will never be received from the SGSN via signaling.
default:
3-0-1
BSEPRIPFC is a SEQUENCE of these three aforementioned values.
FRS-No.: 89950
The ARP preemption algorithm uses the information of this parameter
SF-No.:
10506
in order to assign (to predefined 'best effort' service and to prerel99
Introduced in BR9.0
MS) the related values of allocation priority, preemption capability,
preemption vulnerability.
Any combination of Allocation priority, Preemption capability and
Preemption vulnerability values is allowed.
BSEPRIPFC=3-0-1,

BSCOVLH=TRUE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
TRUE

BTSOVLH=TRUE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
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).
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])

CBC phase, this parameter defines the type of Cell Broadcast Center
connected to the BSC. The setting of the CBCPH is related to the
object:
BSC [BASICS]
parameter 'Channel Indicator', which identifies the channel on which
range:
PH1_CBC, PH2_CBC,
the message has to be broadcast.
PH3_CBC
From the BSC side, the old CBC interface (without Channel_Indicator
default: PH1_CBC
parameter)
is still supported. In this sense the RC/LMT operator can
Range has been modified in RG20 (BR)
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 or PH3_CBC to indicate that the connected CBC
supports Enhancement of CBC Interface following 23.041 for RG20
(It is allowed only in RG20)
CBCPH = PH1_CBC,

26 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.
.
CCCHOVLTH = per130,
object:
range:
default:

BSC [BASICS]
per130;per120;per110;
per100;
per130

CCHANTFACT=FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

CCHNOACT3GPP=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 90351
SF-No.:
10508
Introduced in BR9.0

CCHNOACTLTE= FALSE,
object:
BSC
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 97715
SF-No.:
Introduced in RG20(BR)

CENNS=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 89795
SF-No.:
10507
Introduced in BR9.0

27 / 703

CCCH overload threshold - this attribute lets the decreasing of


CCCH overload (for paging messages). It 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
Note: In BR10.0 this parameter replaced the functionallity of BIT30
and BIT31 in MNTBMASK parameter
Channel change notification active, this flag determines whether
Channel Change Notification procedure (CCN) is enabled in the BSC
(TRUE) or not (FALSE).The CCN procedure has been specified for
NACC (Network Assisted Cell Change, see parameter
NCRESELFLAG below). In the CCN procedure the MS notifies the
network when a better cell is found (i.e. when the conditions for
reselection to another GSM or to a 3G cell are met) and delays the
cell reselection to let the network respond with neighbour cell system
information.
Channel Change Notification Active 3G , this parameter indicates
whether the CCN mode in the serving cell for cell reselection towards
3G cells is enabled in the BSC.
In BR9.0 this parameter was always set to FALSE.
This was changed in RG20(BR) due to FRS97715 where it is possible
to set this parameter to TRUE. Simultaneously, dependency with
External NACC feature was removed.
CCHNOACT3GPP attribute cannot be set to TRUE value if 2G- LTE
interworking license is blocked or missing.
Cell Change Notification Active LTE, this parameter indicates
whether the Cell Change Notification mode in the serving cell for cell
reselection towards LTE cells is enabled in the BSC.
CCHNOACTLTE attribute cannot be set to TRUE value if 2G- LTE
interworking license is blocked or missing.

Centralized Network Service, this parameter enables the BR9.0


feature 'Central Network Service Layer' (CNSL). CNSL means a new
BSC internal logical architecture for (E)GPRS services, i.e. it
implements a new variant of distribution of tasks among the available
PPXUs/PCUs:
Up to BR8.0, the task distribution was implemented as follows:
- Each PPXU/PCU acts on its own towards SGSN
- Each PPXU/PCU is using its own dedicated Network Service (NS)
- An NS is modeled by a corresponding dedicated Network Service
Entity (NSE).
The diagram below illustrates this configuration:

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

This task distribution (Dedicated NS mode) remains valid also in


BR9.0, if CENNS is set to FALSE.
Starting from BR9.0 a 'Central Network Service' architecture can be
configured by setting CENNS=TRUE. In this configuration, one NSE
is configured for the whole BSC:
- All PPXU/PCUs are using one common central NS
- NS is modeled by a one common NSE
- Each BSC may be configured either with Central or Dedicated NS
The diagram below illustrates this configuration:

In this configuration there is


- one central NS layer common for all PCUs of a BSC which is
located on only one PPXU/UPM board. This PPXU-NS has to
support several instances of NSEs for the feature 'Flexible Gb'
(parameter FLEXGBSUP, see below).
- one NSE per connected SGSN
- only one PPXU acting as a central NS, regardless of number of
NSEs.
Thus, the consequences of the two possible CENNS settings are
a) CENNS=FALSE
Each NSE instance is implicitly related to the PCU.
b) CENNS=TRUE
Only one common NSE can be created.
Further parameters relevant for this feature are
- parameters associated to the NSE object (see command CREATE
NSE)
- all parameters associated to the NSLEVLIP and RNSEVLIP objects
(see commands CREATE NSEVLIP and CREATE RNSEVLIP)
- parameters PCUID and NSEID (see command CREATE FRL)

28 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

CENNSOVLC=TRUE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
TRUE
FRS-No.: 89795
SF-No.:
10507
Introduced in BR9.0

Centralized Network Service Overload Control, this parameter

enables the Overload Control Function for the feature 'Central


Network Service Layer' (See also parameter CENNS). The NS
Overload Management is based on 'onset' and 'abatement'
thresholds as defined by parameter NSLOAD (see below). Also
parameter NSMEMALL (see below) is relevant.
The basic use is for testing purposes. The setting is independent of
the general overload control. However, handling may make sense
only if RMB overload control is enabled by setting EPCUOVLC
=TRUE).

CICFM=GSM,
object:
range:
default:

BSC [BASICS]
GSM, NOTSTRUCT
GSM

CITAMEASSUP=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.:
SF-No.:
Introduced in BR9.0

29 / 703

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
in command CREATE PCMA).
Cell ID Timing Advance Measurement Supported, this parameter
enables the provision of standard MS measurements (along with the
concerned neighbouring cells).
If its value is TRUE, these measurements shall be provided from BSC
to SMLC with the BSSLAP UTDOA response, with the TA response
and with the Reset Messages.
If CITAMEASSUP has the value FALSE the MS measurements
(along with the concerned neighbouring cells) shall not be provided.
Remark: The UTDOA positioning method is not supported by the
Siemens Networks SMLC (for BR9.0 release SMLC4.0 is released).
The BSS support of this method is provided, because some Siemens
BSS customers use third vendor SMLCs that deploy the UTDOA
positioning method.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

CSCH3CSCH4SUP=TRUE,
object:
range:
default:
reference:

BSC [BASICS]
TRUE, FALSE
FALSE
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 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
CS-2
CS-3
CS-4

9,05 kbit/s
13.4 kbit/s
15.6 kbit/s
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).
good radio conditions
poor radio conditions

Channel Coding
Channel Coding

Data Coding
Data Coding

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.
Attention: A parameter with the same acronym is also available in the
PTPPKF object where it can be used to enable/disable CS3/CS4

30 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

individually per BTS (see parameter CSCH3CSCH4SUP in command


CREATE PTPPKF). This parameter is especially important if the
operator wants to enable EDGE without applying CS3 and CS4 (i.e.
without applying concatenated PCU frames on the Abis). Please see
the corresponding parameter description for details.
DEF2GAUTHNID= <NULL>,
object:
range:

BSC [BASICS]
0..9, <NULL>

default:

<NULL>

Introduced in RG20 (BR)

DEF3GAUTHNID= <NULL>,,
object:
range:

BSC [BASICS]
0..9, <NULL>

default:

<NULL>

Introduced in RG20 (BR)

DENC = none,
object:
range:
default:

BSC [BASICS]
none;noVarBMapAcr0;
noEncodingAcr0;
none

DGRSTRGYBCNT=
DISABLED,
object:
range:
default:

31 / 703

BSC [FLAGS]
ENABLED, DISABLED
DISABLED

Default 2G Authorized Number Identifier, this parameter is only


relevant if IMSI based HO to GSM cell is allowed (IBHOTO2GC =
TRUE) and it indicates which Authorized Network List will be used for:
- Subscribers whose PLMN was not found (according to list of
Service Groups),
- Subscribers whose IMSI is not available.
<NULL> refers to the case where all GSM neighbours are acceptable.
Default 3G Authorized Number Identifier, this parameter is only
relevant if IMSI based HO to 3G cell is allowed (IBHOTO3GC =
TRUE) and it indicates which Authorized Network List will be used for:
- Subscribers whose PLMN was not found (according to list of
Service Groups),
- Subscribers whose IMSI is not available.
<NULL> refers to the case where all 3G neighbours are acceptable.
Disable encodings - this parameter determines encoding format of
SYSTEM INFO TYPEx messages which are sent on the Um.
noVarBMapAcr0 disables the Variable Bitmap format this option
exists since (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.
noEncodingAcr0 forces bitmap range 1024 format to be used this
option exists since there are several MSs not able to manage bitmap
format with range different from 1024 in the following scenario: mix of
frequencies in the two ranges (0, 1...124) and (975..1023) in the same
cell
Note: In BR10.0 this parameter replaced the functionallity of BIT22
and BIT27 in MNTBMASK parameter
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 (nonreserved) TCHs which are currently busy due to GPRS traffic (PDCH)
as busy (like any other TCH currently seized by a CS call) in any

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
range:
default:

BSC [BASICS]
TRUE, FALSE
TRUE

DNC2MSGPREL99 =FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

Introduced in BR10.0

EAMR=TRUE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
TRUE
Introduced in BR9.0

EAMRWB= FALSE,
object:
range:
default:

BSC [FLAGS]
TRUE, FALSE
FALSE

Introduced in BR10.0

32 / 703

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).
Disable NC2 messages to preRel99 - this parameter allows to
disables sending of Network Control Order 2 messages to pre-Rel99
MSs. In such a case Network Controlled Cell Reselection will not be
performed on legacy MSs.
Reason for introduction of this option is, that currently the operators
do not use NCCR due to the behaviour of pre-Rel99 mobiles. With the
required modification, customer can enable the functionality especially
for a more useful traffic distribution into the system.
Note: In BR10.0 this parameter replaced the functionallity of BIT35 in
MNTBMASK parameter.
Enable AMR, this parameter enables AMR speech in the BSC. When
it is set to TRUE, the BSC generally allows the use of AMR speech
codecs in the BSC when the BSC receives TCH request messages
(such as ASSIGNMENT REQUEST or HANDOVER REQUEST) that
indicate AMR codecs (indicated in the messages FR Version 3, or
HR Version 3 respectively) as allowed. Of course, the BSC considers
further cell-specific settings (such as the Service Layer definitions,
see parameters AMRFRLLPRM, AMRFRLLCOM, AMRHRLLPRM,
AMRHRLLCOM in command SET BTS [SERVICE]) before an TCH
using an AMR speech codec (and which one) can finally be allocated.
Note: If the EAMR attribute of BSC is set to FALSE then the
DEFPOOLTYP attribute (see command CREATE PCMA) cannot be
equal to POOL_23 or POOL_46.
Enable AMR Wideband, this parameter enables AMR-WB speech
codec modes in BSC.
When it is set to TRUE, the BSC allows using AMR-WB speech
codec modes when it receives TCH request messages (such as the
ASSIGNMENT REQUEST or HANDOVER REQUEST) that indicate
the AMR-WB capability of an MS.
The only configuration supported is the Config-WB-Code-0, i.e. the
TCH/WFS (GMSK and full-rate) codec modes: 6.60 kbps, 8.85 kbps
and 12.65 kbps. The 8-PSK codec modes are not supported at all.
Compared to the AMR-NB the AMR-WB codec modes achieve a
significant improvement in speech quality by:
- extension of speech bandwidth carried on a radio channel =>
sampling rate is increased from 8 kHz to 16 kHz,

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

- efficient source encoding algorithms.


In conclusion, AMR-WB offers improved intelligibility and naturalness
yielding a feeling of transparent communication. A more face-to-face
like sound sensation is perceived in a mobile communication.
As specified by the 3GPP, the AMR-WB feature offers codec modes
with five source bit rates:

The higher source bit rates (15.85 kbps and 23.85 kbps) are specified
to operate with the 8-PSK modulation and in full-rate mode only. The
three lowest source bit rates are specified for half-rate mode with 8PSK modulation, too.
The full benefit in terms of speech quality improvement of the AMRWB feature is got out only when it operates in the tandem free
operation (TFO). The TFO can be established when both connection
ends support the AMR-WB codec modes and the in-path equipment
is transparent for the TFO protocol and TFO frames. The TFO is
being established automatically there is not any parameter to
activate the TFO. The usage of the AMR-WB codec modes in the
tandem operation makes no sense, because trans-coding at TRAU(s)
means changing of sampling rate down to 8 kHz (downgrade to
narrow-band quality) to match capacity of a single PCM timeslot (64
kbps = 8 bits * 8 kHz). Therefore, it is recommended to switch the call
to the narrow-band mode (see the parameter NBNOWB for details).
The AMR-WB feature is supported by the BTS+ equipment (FCU and
ECU) and by TRAU with TRAC v7 and eTRAU with MSB.
In contrary to the AMR-NB it is not necessary to define an active
codec set (ACS) for AMR-WB, because the only allowed configuration
is the configuration Config-WB-Code-0 which is at present hardcoded and cannot be modified.
From the point of view of network dimensioning the AMR-WB feature
is not intended to increase capacity, because in contrary to the AMRNB feature the AMR-WB feature does not offer sufficiently robust
codec modes to cope with poor radio conditions. So, in poor radio
conditions it is recommended to use AMR-NB codec modes with

33 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EARP=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 89950
SF-No.:
10506
Introduced in BR9.0

EASCICRE=FALSE,
object:
range:
default:
FRS-No.:
SF-No.:

BSC [BASICS]
TRUE, FALSE
FALSE
94688
10513

Introduced in BR10.0

34 / 703

source bit rates down to 4.75 kbps. This can be achievied by dynamic
switching between AMR-NB and AMR-WB codec modes depending
on current radio conditions (and load) which is available by intra-cell
handovers: compression/decompression (AMR-WBAMR-NB HR)
HOs (see the parameters ECMPWBNB and, EDRCMPWBNB for
details) and robustness/homing (AMR-WBAMR-NB FR )HOs (see
the paremeter EROBHOMHO). In conclusion, the AMR-WB feature
intends to improve quality rather than capacity.
Enable Allocation/Retention Priority, this parameter enables the
feature Allocation/Retention Priority (ARP). ARP is related to
(E)GPRS but comparable to the CS feature preemption (see
parameter EPRE in command SET BTS [OPTIONS]) as it allows a
resource allocation priority management management of (E)GPRS
calls based on the subscriber/call priority information received from
the SGSN. Thus, ARP allows the preferred allocation of resources
e.g. for premium subscribers and emergency personnel even in case
of resource congestion.
ARP Functional Sequence
During PS connection setup, the SGSN sends the CREATE BSS
PACKET FLOW CONTEXT REQUEST to the BSC, which may
contain the optional IE Allocation Retention Priority, which in turn
consists of
- The Preemption Capability Indicator (PCI) applies to the allocation of
resources for a packet resource request and indicates if this request
is allowed 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 call transaction dependent priorities and the
associated parameter settings for the Priority IE is maintained in the
SGSN.
The abovementioned parameters are used by the BSC to decide
about the allocation priority for the individual PS calls.
Predefined PFCs
There are four so-called predefined PFContexts (SMS, TOM8,
Signalling, BestEffort), which do not require any negotiations between
BCS and SGSN. As these values will never be received from the
SGSN, the corresponding PF contexts related ARP parameter values
have to be defined in the BSC database. This is done by the
parameters BSEPRIPFC, SMSPRIPFC, TOM8PRIPFC and
SIGPRIPFC (see command CREATE PTPPKF).
In case of non-pre-defined PFCs the values are optionally provided by
the SGSN. If they are not provided (this is possible, since ARP IE is
optional) then BestEffort is taken.
Enable ASCI Call Re-establish, this parameter is only relevant if the
feature ASCI is enabled (see parameter ASCISER in command SET
BTS [CCCH]) and determines whether the feature Reactivation of
VGCS/VBS channels after service unavailability is enabled (TRUE) or
disabled (FALSE) in the BSC for ASCI calls.
When a group (VGCS) or broadcast (VBS) call is released due to
BSS generated reasons, the BSS release the resources and stop
transmitting the Notification for the ASCI call. With
ASCIBROADP=TRUE, when outage reason disappears reestablishing of the ASCI call in the cell is possible.
The ASCI calls waiting for re-establishment are stored in the queuing

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

buffer. Due to modified queuing algorithm the feature is mutually


exclusive with the Wireless Priority Service WPS feature.
As required by 3GPP standard new separate timers defining the
maximum queuing time for the ASCI calls in Public and WPS queues
(BSCT14PUB and BSCT14WPS) are introduced.
When the feature is active the standard queuing procedure is no
longer attempted, and the new ASCI call re-establishment queuing
procedure applies instead (WPS is not allowed).
When the feature is not active then the standard queuing procedure is
still applied, but the new T14 timers, BSCT14PUB and BSCT14WPS
have to be used in case of the ASCI calls instead of the BSCT11WPS
or BSCT11PUB timers.
The ASCIBROADP attribute can be set TRUE in the BSC object only
if the EASCIRE attribute has been already set TRUE in the BSC
object. On the contrary, the EASCIRE attribute can be set FALSE in
the BSC object only if the new ASCIBROADP attribute has been
already set FALSE in the BSC object.
Introduced in BR10.0
EDLDC = FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

FRS-No:

95462

EEGTLLIBLKCHC = FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

Introduced in BR10.0

35 / 703

Enable DLDC, this attribute enables/disables the Downlink Dual


Carrier feature in the BSC. DL DC allows Dual Carrier MS (3GPP
Rel.7) to be assigned radio resources on two different carriers/TRXs
(2 different frequencies in case of no fequency hopping or 2 different
sets of MAL, MAIO and HSN in case a frequency hopping is applied).
DL DC allows to assing to an MS doubled number of timeslots than it
would result from MS Multislot Class in single carrier mode, e.g. MS
Class 33 can have up to 10 (5+5) timeslots assigned while in DL DC
mode. DL DC feature increases then the achievable throughputs and
reduces latency.
Downlink Dual Carrier can be applied only to EDGE TRXs
(TRXMD=EDGE) comprising the EDGE SLL and therefore requires
appropriate configuration of the MSLS feature - EDGE layer list
defined for particular cell area (see paramteres ELLPRM and
(ELLCOM) have to contain at least two EDGE TRXs.
REMARK: EGPLGPSEVENTS and EGPLGPEIGHTTS should not be
used to set the polling periods for 7 and 8 TSL allocations. For all
allocations with a number of TSL greater than 6, the polling period will
be equal to the attribute EGPLGPSIXTS value plus hard coded
corrective factors.
Introduced in BR10.0
Enable EGPRS TLLI Block Channel Coding - this attribute
enables/disables the TLLI Blocking Channel Coding for EDGE and
forces the MS to send the first blocks in MCS1 uplink during the
contention resolution phase. Forcing MCS1 all RLC blocks containing
a TLLI in the RLC data block header results not only in better
performance of SM/GMM signalling (as in case of GPRS see
EGTLLIBLKCHC), but impacts also the delay of the first EDGE ping
or EDGE Attach duration:
- first EDGE ping decrease from 1.3-1.5s to 0.8-1s,
- EDGE Attach decrease from 1.75s to 1.5s.
Please see CR3030 for details.
Note: In BR10.0 this parameter replaced the functionallity of BIT15 in
MNTBMASK parameter.
Explanation of contention resolution procedure:
Contention resolution mechanism resolves collision problems which
may occure when two (or more) mobile stations in the same cell
transmit identical packet channel requests in the same (P)RACH with
the same
random identity number. In certain circumstances the network may be

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

able to decode one of two transmitted (on the same channel)


messages and to assign UL resoures and send packet uplink
assignemnt message. Both mobile stations may then decode packet
uplink assignment message and regard the assignment as their own
and access the assigned uplink PDCH/starts a TBF. The network
cannot decode these two simultaneous receptions at the same time
and therefore does not send acknowledgements towards MS. T3166
expires and both mobiles release TBFs.
If only one of the mobile stations has started a TBF on the first USF
allocation, then the network will decode the message, identify the
mobile station from the TLLI, and send a packet uplink ack/nack as
soon as possible. This acknowledgment is sent solely to return the
mobile stations TLLI (and stop T3166). Both mobile stations receive
this message. The mobile station receiving the wrong TLLI must
disconnect from the cell.
In case of 2-phase access the network replies to this packet channel
request with a packet uplink assignment, but assigns only one
RLC/MAC uplink block. The mobile station accesses the assigned
PDCH and sends a packet resource request, which includes the TLLI
of the mobile station. The mobile station then listens to the PACCH
for a packet UL assignment message. The network identifies the
mobile station from the TLLI sent in the packet resource request
message and returns the TLLI in the packet uplink assignment. When
both the network and the mobile station have received the TLLI, any
ambiguity is removed and the contention resolution procedure is
complete.
Introduced in BR10.0
EENHDTMSUP=DISABLED,
object:
range:
default:

Enable Enhanced DTM Support, this flag enables/disables the


Enhanced DTM Establish mode, as defined in 3GPP Release 6.

BSC [BASICS]
ENABLED, DISABLED
DISABLED

EEPTT = FALSE,
object:
range:
default:

BSC [FLAGS]
TRUE, FALSE
FALSE

FRS-No.:
SF-No.:

96747
10570

Introduced in BR10.0

EEUCRESEL= FALSE,
object:
units:
range:

BSC
TRUE, FALSE

default:

FALSE

Enable EPTT (Enhanced Push-to-Talk), this parameter is only


relevant if the feature ASCI is enabled (see parameter ASCISER in
command SET BTS [CCCH]) and determines whether the feature
Short Data Transmission during ongoing Group Call is enabled
(TRUE) or disabled (FALSE).
The feature enables transfer of the short data messages to a group
call participants without releasing the ongoing voice call. The new
functionality is limited to voice group call services (VGCS) and service
subscribers (listeners and talkers) only (voice broadcast services VBS
and dispatchers are excluded).
Enable EUTRAN Cell Reselection, this parameter is used to
enable/disable GERAN E-UTRAN Cell Reselection feature (FRS
98321) with the help of which it is possible to perform cell reselection
based on priorities to LTE and WCDMA (or WCDMA only if LTE cells
are not available as target cells please refer to FAC3Q parameter).
Please refer to parameters under EUFREQ object to get further info
about functionalities behind the feature.

FRS-No.: 98321
SF-No.:
Introduced in RG20 (BR)

36 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EFRSUPP=FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

EGTLLIBLKCHC =FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

Introduced in BR10.0

EMSC3033=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 89997
SF-No.:
10509
Introduced in BR9.0

ENACCE=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 90351
SF-No.:
10508
Introduced in BR9.0

ENACCE3GPP=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 97715
SF-No.:
Introduced in RG20 (BR)

37 / 703

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.
Enable GPRS TLLI Block Channel Coding - this attribute
enables/disables the TLLI Blocking Channel Coding for GPRS and
forces the MS to send the first blocks in CS1 uplink during the
contention resolution phase. Forcing CS1 for RLC blocks containing a
TLLI in the RLC data block header results in better performance of
SM/GMM signalling. Please see CR3030 for details.
Note: In BR10.0 this parameter replaced the functionallity of BIT15 in
MNTBMASK parameter.
Enable Multislot Classes 30-33, this parameter enables the feature
Support of MS Multislot Classes 30-33.
In case its set to true the system supports the new multislot classes
30-33. In case of false setting, the mobiles supporting these re-emp
are mapped as follows:
30  8,
31  10,
32  11,
33  12.
Further parameters relevant for this feature are MAXWDL, MAXWUL,
SMFUL, SMFDL and RTMUXBACCOM (see command CREATE
PTPPKF).
External NACC Enabled, this parameter enables the feature
External Network Assisted Cell Change. If it is set to TRUE the
External NACC is enabled in the BSC, otherwise it is disabled.
In pre-RG20(BR) the External NACC could be enabled only if CCN is
enabled, i.e. ENACCE could not be set to TRUE if parameter
CCHANTFACT (see above) is set to FALSE. This relationship is no
longer valid in RG20 (BR).
External NACC was the only RIM based functionality (i.e. RIM
Application, called RIMApp) in BR9.0 release. RIM itself is always
active in BSC and does not require any parameterization.
In RG20 (BR) distributing of SI towards RNC and eNodeB (via RIM)
was additionally introduced.
Enable Eternal NACC to 3G, indicates whether transmission of
(Packet) System Information is activated towards RNC
ENACCE3GPP attribute cannot be set to TRUE value if 2G- LTE
interworking license is blocked or missing.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ENACCELTE=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 97715
SF-No.:
Introduced in RG20 (BR)

Enable Eternal NACC to LTE, indicates whether transmission of


(Packet) System Information is activated towards eNodeB
ENACCELTE attribute cannot be set to TRUE value if 2G- LTE
interworking license is blocked or missing.

Enable DRX, this parameter allows the enabling/disabling of the DRX


functionality on BSC and BTS.
object:
BSC [BASICS]
Without Discontinuous Reception (DRX) on the Cell Broadcast
range:
TRUE, FALSE
Channel MS is forced to stay awake and monitor the SMS-CB
default:
FALSE
channel, unless it is not interested in receiving SMS messages.
FRS-No.: 90351
In DRX mode MS reads at least the first part of a Cell Broadcast
SF-No.:
10508
Introduced in RG20 (BR)
Message and then decide whether or not to read the rest of the
message.As the result of that mechanism MS has to read at least one
CBS block per 8 multiframes, thus the battery life is reduced.
The DRX foreseen the broadcasting of the Schedule Messages to
MS, providing information in advance about the CB messages that will
be sent immediately afterwards. These messages allows the MS to
ignore transmissions of CBS messages the customer is not interested
in which is helpful in minimizing battery usage.
Note: DRX mechanism is not supported on eBSC.
Supported encryption algorithms, this parameter determines the
ENCALSUP=NOENCR&
algorithms for the radio interface ciphering supported by the BSC.
GSMV1&GSMV3,
NOENCR means no ciphering,
GSMV1 represents the ciphering algorithm A5/1,
object:
BSC [BASICS]
range:
NOENCR, GSMV1, GSMV3 GSMV3 represents the ciphering algorithm A5/3.
default:
encalg1=NOENCR
Special Remarks on A5/3
encalg2=GSMV1
In BR9.0, A5/3 is implemented only for GSMK modulated CS services
encalg3..10=<not set>
(but not for HSCSD). As opposed to A5/1 and A5/2, which were
FRS-No.: 89397
SF-No.:
10505
implemented in HW (via ASIC), A5/3 is implemented purely in SW. As
the required computation performance of BTSE HW platform BTSone
Value GSMV2 removed in BR9.0!
(BTS1) is not sufficient to support the associated processing, A5/3 is
only available for BTSE HW platform BTSplus (BTS+). BTSone only
supports A5/1
Ciphering Procedure
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/3 is the
stronger and safer algorithm and is therefore preferred against A5/1,
if both are allowed) for the CIPHERING MODE COMMAND towards
the BTS.
Whether an MS supports cipher algorithm A5/3 or not, is indicated in
the Classmark 2 IE which is contained in the CLASSMARK CHANGE
message that is sent during call setup (of after explicit CLASSMARK
REQUEST). The MSC considers this capability indication prior to the
transmission of any ciphering request (that may be embedded in the
messages BSSMAP messages CIPHER MODE COMMAND or
HANDOVER REQUEST).
The fact that different BTS HW generations do not support the same
ciphering algorithms has an effect on call processing during call setup
and handover: If ENCALSUP lists A5/3 as supported ciphering
algorithm (ENCALSUP=GSMV3) on BSC level, this does not reflect
the ciphering capabilities of all BTSs of this BSC if some BTS are of
type BTSone! Therefore the BSC checks any BTS for limited cipher
algorithm capabilities via the Expected SW version attribute (see
parameter EXPSWV in command CREATE BTSM) in the following
ENADRX=FALSE,

38 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

cases:
a) on reception of the CIPHER MODE COMMAND (during any call or
re-emptio transaction setup with ciphering)
b) on reception of the HANDOVER REQUEST (during incoming MSCcontrolled handover)
c) during BSC-controlled handover towards this BTS.
If A5/3 is allowed but not supported by a BTSE, the BSC changes the
cipher algorithm to the next best one (the sequence is A5/3  A5/1
 A5/0). Any change of the ciphering algorithm during intercell
handover is re-empti to the MS via the IE Cipher Mode Setting
included in the HO COMMAND.
Ciphering Algorithms in BTSE load types
As in previous releases, the support of the different ciphering
algorithms depends on the installed BTSE load type. In BR9.0, the
following two BTSE load variants are available:

ENFOIAHO=TRUE,
object:
range:
default:

39 / 703

BSC [BASICS]
TRUE, FALSE
TRUE

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).
Notes:
- In BR9.0 the previously available value GSMV2 (representing the
algorithm A5/2), was removed, as also the complete algorithm A5/2
was removed from the BTS code. This was done as the GSM
association board has decided to no longer support A5/2 due to
serious security gaps. A5/2 was previously available as the only GSM
compliant ciphering algorithm for non-MoU countries/operators who
were not allowed to use A5/1. With the introduction of A5/3, it is
planned to allow the non-MoU countries/operators to use A5/1.
- A5/3 is an optional feature. Therefore the value GSMV3 only be set
if the corresponding license is available.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ENFORCHO=ENABLE,
object:
range:
default:

40 / 703

BSC [BASICS]
ENABLE, DISABLE
ENABLE

BTS to BSC.
Remark: It is important to point out that a similar HO is performed if a
hybrid TCHSD (i.e. a TCH in the TCHSD_POOL, see command
CREATE CHAN) is seized for a call: With the introduction of MSLS,
the use of TCHSD belonging to the TCHSD_POOL has been
changed, too. This kind of resource is now the last activated for CS
services when no normal TCH (i.e. a TCH or TCHSD belonging to
the TCH_POOL) is available, even if it was configured on the service
layer that is the most preferred one for CS services. In other words,
the BSC first allocates a TCH on a less priorized layer, before it starts
to allocate a TCHSD on the highest priorized layer. Then, when a
normal TCH (from the TCH_POOL) becomes idle, the call served by
the TCHSD is moved (if possible) towards the TCH via forced
intracell HO due to the fact the TCHSD with TCHSD_POOL is a
valuable resource (that can be used also for re-emptio). In this
condition, the counters for intracell HO are triggered with the cause
intracell HO due to preferred TRX.
Note: For both cases, (a and b) EMPROSDCA must be set to TRUE
in addition to this parameter.
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 re-emptio.
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) re-emption 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 re-emption) 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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ENHSCSD=FALSE,
object:
range:
default:

41 / 703

BSC [BASICS]
TRUE, FALSE
FALSE

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 BSCinternal and outgoing Inter-BSC directed retries, it also prevents
incoming Inter-BSC directed retries and incoming handovers due to
re-emption: 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
re-emption is only attempted, if ENFORCHO is set to ENABLE. If
this is not the case the re-emptio 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 MSs 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 re-emption 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 re-emption and O&M intervention) the flag is checked and
correspondingly considered.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.
ENOCS3CS4 =FALSE,
object:
range:
default:
FRS-No.:
SF-No.:

BSC [BASICS]
TRUE, FALSE
FALSE

Introduced in BR10.0

EDGE no CS3 and CS4 this attribute allows the activating EDGE
without CS3CS4 feature. This means that, if it is set to TRUE, 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 ENOCS3CS4 =TRUE 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

42 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

is disabled, 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 setting
ENOCS3CS4 to TRUE.

EOVH=ENABLED,
object:
range:
default:
FRS:

BSC [FLAGS]
ENABLED, DISABLED
ENABLED
88930

Introduced in BR 10.0

EPA=FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
TRUE

Note: In BR10.0 this parameter replaced the functionallity of


BIT25 in MNTBMASK parameter
Enable Overheating this attribute enables/disables the overheating
algorithm that limits number of assigned PDCHs taking the distance
between the BS and MS into account. The system evaluates the
maximum number of allowed timeslots for the given mobile from a set
of the pre-defined internal tables. The evaluation is based on the
current Timing Advance value (distance estimation), band and
modulation of operation, Multislot and Power Class of the given
mobile and type of the propagation environment (parameter CSCE).
The aim of this feature is to prevent the loss of the connection from a
(E)GPRS mobile due to possible overheating of the transmitter
circuits.
On the request of many customers the possibility of disabling of the
Overheating feature had to be implemented, since the customers
claimed that resource assignment was too restrictive (see CR4209).
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:
b) 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).
no. of radio TCH in usage state idle
no. of configured radio TCH

100

<

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

43 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

(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
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.
EPCUBMOD=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 95283 (BR10.0)
SF-No.:
Introduced in BR9.0

EPCUOVLC =TRUE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
TRUE

Introduced in BR10.0

EPDTRELI=FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

Introduced in BR10.0

44 / 703

Enable PCU Balance Mode, this parameter enables the usage of the
modified load balancing algorithm. With the modification
(EPCUBMOD=TRUE) it is possible to define (on per cell basis) a
preferred PCU the cell shall be assigned to. Without this modification
(EPCUBMOD=FALSE) all cells are fully automatically distributed
among available PCUs.
Please also see PRPTPGID in CREATE PTPPKF command.
Enable PCU Overload Control, this attribute enables/disables the
PPXU overload handling procedure.It is correlated with Centralized
Network Service Overload Control (CENNSOVLC parameter which
enables the Overload Control Function for the feature 'Central
Network Service Layer). Setting CENNSOVLC=TRUE make sense
only if overload control is enabled by EPCUOVLC parameter
Note: In BR10.0 this parameter replaced the functionallity of BIT9 in
MNTBMASK parameter.
Enable PDT Release Improvements this attribute enables/disables
the PDT release improvements. If it is set to TRUE 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 it is set to FALSE then for EMPTY PDT
purposes, SFC=0 is controlled by TEMPCH timer, while SFC>=1 is
controlled by the timer TEMPPDT (see command CREATE CPCU).
The functionality controlled by this bit aims at an improvement of
potential gaps in the data transfer exceeding TEMPPDT, impacting
GMM/SM signalling, first ping timing and upload/download times,
especially with small file size.
SFC means Sub-Frame-Counter which indicates the sub-frame
number and provides the sequence order of the 16 kbit/s channels.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EPOOL=FALSE,
object:
range:
default:

BSC [FLAGS]
TRUE, FALSE
FALSE

Introduced in BR10.0

EPREHSCSD=DISABLED,
object:
range:
default:

BSC [BASICS]
ENABLED, DISABLED
DISABLED

ERANSHR = FALSE,
object:
range:
default:

BSC [FLAGS]
TRUE, FALSE
FALSE

FRS-No.:
SF-No.:

96782

Introduced in BR10.01

45 / 703

The SFC is coded by 5 bits, which allow a maximum chain of up to 32


concatenated PCU subframes
.Note: In BR10.0 this parameter replaced the functionallity of BIT23 in
MNTBMASK parameter.
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, but it is also used to introduce a more sophisticated
management of A-interface TCH resources and the capability of the
associated TRAU to support particular services. 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:
- In case of call setup it is the MSC that is responsible for the
allocation and seizure of A-interface TCH resources. Therefore, if
pooling is enabled in the BSC and the corresponding pools are
created in the PCMA and TSLA objects, the same pools must be
configured in the database of the MSC.
- Pooling also affects the mapping of timeslots between the A- and
Asub! A TCH pool for multislot connections must map all Asubtimeslots 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.
Enable re-emption for HSCSD requests, this attribute is only
relevant if HSCSD is enabled (ENHSCSD=TRUE). If it is set to TRUE,
HSCSD calls may re-empt other calls. HSCSD calls themselves can
never be re-emptio.
Enable RAN Sharing, this parameter indicates whether the MOBSS
2G Network sharing solution feature is activated on the BSC side
or not. In order to enable this feature (ERANSHR=TRUE):
- Flexible A feature has to be disabled (FLEXAE=FALSE),
- Flexible Gb feature has to be disabled (FLEXGBSUP=FALSE),
- Multiple PCU pooling feature has to be enabled (more than one
CPCU objects are defined),
- Support of Multiple MNC in BSS has to be enabled
(F119_MULTI_MNC is installed),
MOBSS 2G Network sharing solution is BR10.01 feature with the
help of which it is possible to share the BSC, Abis and BTSE
resources between the operators. Up to ten operators could share the

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

BSC. However, only two could share particular BTSE. Core Network,
PCU pool, PCU, cell and TRX are not shared between the operators.
In the PS domain MOBSS 2G Network sharing solution feature is
based on the Multiple PCU pooling feature. Each PCU pool is
assigned to one operator only.
ERRACT=NOFILTERNOFILTER-NOFILTERNOFILTER-NOFILTER,
object:
range:

default:

BSC [BASICS]
CRITICAL
MAJOR
MINOR
WARNING
NOFILTER
FERMAINT
NOFILTER

ERTPM =FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

FRS-No.:

94612

SF-No.:
Introduced in BR10.01

ESTDBYTRX =FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

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 CommunicationQualityOfService-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.
Enable RTPM this attribute enables/disables the real time
performance monitoring feature.
Real time performance monitoring (RTPM) delivers the time evolution
charts about significant performance indicators of the selected cells in
real time. Therefore, the real time performance monitoring is useful
and important feature for mobile network operators. The operator is
able to supervise the network element in real-time and see the current
situation regarding load, performance, capacity and quality of services
to be provided. The operator can select particular KPIs (Key
Performance Indicators) and start this feature in Radio Comander
(RC). The operator can also select granularity period of KPI values
collection and reporting (10 60 sec). Based on this granularity
period the BSC will collect the particular measurement results,
it will calculate numerator and denominator of KPIs and it will transfer
these values to RC via notifications. KPI values will be calculated in
RC. All collected performance indicators will be presented
in real time with the time evolution. The maximal number of BSCs to
be observed in parallel is 4. RTPM application shall support up to 30
simultaneously observed cells in sum for all BSCs. 14 KPI values to
be defined for RTPM feature can be selected by operators.
Enable Standby TRX this atribute enables/disables Standby
TRXfeature.
Standby TRX
Configurations with only one TRX per cell are commonly requested,
especially for GSM-R projects. Up to BR9.0 in order to provide BCCHTRX redundancy in cells with only one TRX it was not possible to use
the implemented BCCH reconfiguration feature as this feature would
need a second TRX created in the BSC database. There was an
unofficial workaround solution, which required the creation of an
additional dummy TRX in the BSC database.
With Standby TRX feature transceiver redundancy is provided even
in cells with only one transceiver. It is no longer necessary to create
an additional dummy TRX in the BSC database. If transceiver
redundancy is required for a cell, just an additional Carrier Unit
(standby Carrier Unit) has to be created and equipped in the BTSE. In

46 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

case of a failure the system automatically reconfigure the BCCH-TRX


or any other failed TRX to this standby Carrier Unit. The traffic is
interrupted during reconfiguration. The status (providing service, cold
standby) of any Carrier Unit is visible via a new attribute.
The feature is especially useful for GSM-R networks but also
applicable for any other network and cell configuration.
ESTSGMMSM =FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

ESUP=FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

ETFERDERRA =FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

EUSCNCRESEL =FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

EUSDCHO=FALSE,
object:
range:
default:

47 / 703

BSC [BASICS]
TRUE, FALSE,
<NULL>
FALSE

Enable single timeslot for GMM and SM this attribute


enables/disables one downlink timeslot for both GPRS Mobility
Management and Signaling Management Procedures
Note: In BR10.0 this parameter replaced the functionallity of BIT14 in
MNTBMASK parameter
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).
Enable Transcoder FER Despite ERRACT this paramater enbles
forwarding 'Remote Transcoder Failure event message (with
originator 8100) to the Radio Commander without respect to the
settings of the ERRACT filter.
Note: In BR10.0 this parameter replaced the functionallity of BIT17 in
MNTBMASK parameter.
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).
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FLEXAE =FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE,
FALSE

FLEXGBSUP=FALSE,
object:
BSC [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 89900
SF-No.:
10503
Introduced in BR9.0

HOSYNC=NOSYNC,
object:
range:
default:
reference:

48 / 703

BSC [BASICS]
NONSYNC, SYNC
NONSYNC
GSM 04.08
GSM 05.10

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.
Flexible A enabled is the attribute which indicates if flexible-A feature
is activated or not.
Flexible A feature is CS part of Intra-domain connection of RAN
nodes to multiple CN nodes functionality, i.e. one BSC can be
connected to more than one MSC entity, what allows to obtain Core
Network resources redundancy and better fault resilience.
Enable Flexible Gb support, this parameter enables the feature
Flexible Gb.
This feature can be enabled only if the CNSL feature is enabled, i.e.
CENNS = true.
Flexible Gb feature is PS part of Intra-domain connection of RAN
nodes to multiple CN nodes functionality, i.e. one BSC can be
connected to more than one SGSN entity, what allows to obtain Core
Network resources redundancy and better fault resilience.
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

IDRAACT =FALSE,
object:
range:
default:

BSC [FLAGS]
TRUE, FALSE
FALSE

Introduced in BR10.0

49 / 703

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).
IDRA Active this parameter indicates if the Improved Downlink
Resources Allocation feature is enabled or not. The feature tries to
overcome improper Peak Throughput values defined by the operators
(common way to configure the QoS for PS domain is to require the
maximal supported multislot configuration regardless of the real
service needs).
The algorithm tries to decrease the number of assigned PDCHs it is
based on the amount of the data in the LLC queue. If the number of
the octets in the queue is below the IDTRATH threshold then the
lowest possible allocation is chosen for creation of the DL TBF
(generally 1 TS is assigned). Periodically (every IDRATSWITCH timer
expiration) the LLC queue length is checked against IDTRATH and if
the threshold is exceeded reconfiguration takes place (the
configuration calculated for improper, overstated QoS requirements
coming from HLR is used).

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
DL Timer
Expiration
TSDLSA
IDRATSWITCH
TSULBAL

DL

DL
UL

(1,1)

DL Over
Threshold

(1,1)

DL Under
Threshold

UL Timer
Expiration

Time

(5,1)

UL
Priority

(4,2)

Calculated by MSM
DL
UL

(1,2)
UL
Priority

(1,1)

Calculated by MSM

DL
UL

(1,1)

DL Over
Threshold

(5,1)

DL
Priority

(5,1)

On the figure one can see IDRA feature in action: on the left TBF is
started (3 cases are presented) with LLC queue length below
IDTRATH (and UL balanced decision about DL priority) so 1+1
configuration is chosen. After IDRATSWITCH expiration the LLC
queue is compared with IDTRATH again and reconfiguration takes
place if required (one stays with 1+1 or switch to 5+1 multislot class
33 without EDA as an example). Then the TSULBAL expires and
further tuning can be done (if UL priority then increase the number of
UL timeslot assigned) as the result of this action one can observe
4+2, 1+2 or 5+1 configurations respectively. Please note that in cases
1 and 3 IDRA is stopped (IDRA is not allowed to downgrade any
TBF). Only in the second case (1+2 configuration) IDRATSWITCH
will be run again and next check versus IDTRATH will be performed
to increase the DL configuration if required..
The feature is strongly related to the old Uplink Balanced feature.
Please note that the feature works for all mobiles only if Packet Flow
Management is disabled and only for mobiles of release 97/98 in case
PFM is enabled.
LCSMONTH=
ENABLED(30)-ENABLE(60)ENABLED(90),
object:
range:
default:

BSC [BASICS]
ENABLED(1..100),
DISABLED
ENABLE(30) (minor)
ENABLE(60) (major)
ENABLE(90) (critical)

MADGRLV=2,
object:
range:
default:

BSC [BASICS]
0..3
2

MAFIRACHO=2,
object:
range:
default:

BSC [BASICS]
1..3
2

MAXLAPDMN=5,
object:
range:

50 / 703

BSC [BASICS]
5..12

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.

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
default:

MAXNCELL=6,
object:
unit:
range:
default:

BSC [BASICS]
1
1..16
6

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

Missing timeslot threshold, this attribute defines the alarming


threshold for the feature Detection of missing timeslots on Abis.
object:
BSC [BASICS]
If the number of failed consecutive CHAN activations on one Abis
range:
1.. 40
timeslot (TSLB) exceeds this threshold, an alarm on all configured
default:
3
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.
Maintenance bit mask, this parameter was originally intended to be
MNTBMASK=<DEFAULT>,
reserved for internal use only. The idea was to set specific bits of this
parameter to enable manufacturer internal functions that require the
object:
BSC [BASICS]
unit:
1
installation of specific patches.
range:
BIT1.. BIT61
However, this parameter has also been repeatedly used to enable
<DEFAULT>, Null
and control project-specific SW modifications or modifications that
default:
1
were introduced in BR6.02 as late features. For this reason it is
urgently recommended to use this parameter only, if the operator
parameter range extended in BR8.0!
knows the exact impact of each of the bits that can be set.
Used bits modified in BR10.0 The following functions can be controlled by the MNTBMASK
due to implementation of
Parameter (for guidelines for use please see below):
FRS94645 Consolidation of
MNTBMASK=BIT4 and MNTBMASK=BIT5 are used to disable the
Maintenance bit mask
so-called YHO circuit (quasi conference bridge in DL direction)
during intercell and intracell handover that is introduced in BR9.0 in
the scope of the feature Reduced Handover Muting Gap (Sales
feature No. 10526, FRS No. 92263, further reference is CR3524).
The feature is a basic one and its enabling is useful in any case as
it improves the speech quality during handover. However, for the
(rather unrealistic) theoretical case that some settings for AMR
speech are unfavourable (e.g. inhomogeneous Initial Codec Modes
(ICM) or/and Active Codec Sets (ACS) in the BSCs cells see
parameter AMRFRC1 in command CREATE BTS [BASICS]), the
operator may decide to disable the YHO circuit deployment for
AMR calls, as (possible) CODEC mismatch on the target cell may
lead to some noise effects that are regarded as worse than the
handover speech gap itself. While setting BIT4 disables the YHO
deployment for standard codecs (EFR, FR, HR), setting BIT5
disables the YHO deployment for AMR codecs (AMR-FR, AMRHR).
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.
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 /
ASSIGNMENT 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 / ASSIGNMENT COMMAND
messages: the shorter the message (and the less layer 2
messages are needed for delivery to the MS), the smaller the
MISTSTRSH=3,

51 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

52 / 703

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 coding of the Frequency
List IE, e.g. by the usage of a variable bit map with minimum
length 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:
b) If MNTBMASK=BIT32 is set the BSC calculates the effective
length of the frequency list encoded by the variable bit map
and restricts the length of the Frequency list IE to the
minimum, instead of using a fixed length 16 bytes, which is the
case if BIT32 is not set.
2) If MNTBMASK=BIT33 is set, then, if the frequency list could
be encoded with Range128 format (possible if less than 29
frequencies have to be coded), the BSC will chose the best
encoding law between VariableBitMap and Range128 (in
terms of used bytes).
Since the two improvements are controlled by two different bits
of MNTBMASK, they could be used independently or together.
Enabling CR2870 using BIT32 and BIT33 has already proven to
have a notable effect on the call drop rate. Precondition, however,
is that the range of block-wise allocated frequencies is small
enough to allow coding with a number of octets that is reduced to
such an extent that one FACCH block can be saved. This means
that the setting of these bits is urgently recommended. Reference:
CR2870.
MNTBMASK=BIT40 is used to disable CR3149 Implementation of
3GPP CRs for ASCI, i.e. BIT40 not set means CR3149 enabled,
MNTBMASK=BIT40 disables the CR3149 changes (i.e. sending of
new messages to mobiles).
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). Reference: CR3243.
MNTBMASK=BIT42 is used to remove TCH/SD channels in the
TCHSDPOOL (see command CREATE CHAN for TCHSD) from
channels usable for DTM. Reference: CR3404.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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. Reference: CR3332.
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 doesnt 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. Reference: CR3464.
MNTBMASK=BIT48 is related to CR3902. If BIT48 is set, the
optional info element Cell selection indicator after release of all
TCH and SDCCH is added to the CHANNEL RELEASE
message.
Note: The new IE has to be sent in the CHAN REL message only
for UE MS that declare to be Release 6 compliant and only if at
least one FDD adjacent cell is created for the cell where MS is
seized.
If BIT48 is not set, the system abovementioned is not added.
MNTBMASK=BIT49 is related to CR3991. Setting BIT49 enables
Peak Throughput Control, if BIT49 is not set, the feature remains
disabled.
MNTBMASK=BIT57 activates Intelligent Selective Paging feature.
This feature allows to send a paging request to the cell where the
MS is expected and to its adjacent cells within the same location
area (instead of sending paging requests to all cells of the MSs
location area).
This functionality improves the reachability in very crowded areas
where the MSs usually do not move significantly (e.g. in a
stadium). Intelligent selective paging reduces the signalling load for
paging on the Um interface.
When the Intelligent Selective Paging feature is active, the MSC
keeps ready the Cell Identity (CI) of the last recorded cell where
the MS has been (camping cell), and the BSC pre-determines the
adjacent cells related to the CI within the location area.
When paging to the MS is required, the MSC includes the recorded
CI for this MS in the Cell Identifier List IE which also indicates that
the Location Area Code (LAC) and the Cell Identity (CI) is to be
used by the BSS to confine the cells which shall broadcast
PAGING REQUESTs. The Cell Identifier List IE is packed into the
PAGING message and sent to the BSC. The BSC sends PAGING
COMMAND messages to the BTS related to the cell with the
reported CI and to the BTSs related to the adjacent cells which

53 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

have been determined before. These BTSs then broadcast the


PAGING REQUESTs. In case the MSC does not receive the
paging response within the expected time limit, it starts a further
paging with the whole location area as paging target.
Note The MSC must support Intelligent Selective Paging
Important Hints for Use of MNTBMASK :
- 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=BIT4|BIT5).
- All bits can be reset to their original values using the setting
MNTBMASK=Null or MNTBMASK=<DEFAULT>.
MSCOVLH=TRUE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
TRUE

MSCV=PHASE2CCEFR,
object:
range:

default:

BSC [BASICS]
PHASE1
PHASE2
PHASE2CC
PHASE2EFR
PHASE2CCEFR
PHASE2CCEFR

NACCNTWCOR=nc0,
object:
range:
default:

54 / 703

BSC [BASICS]
nc0, nc1
nc0

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])
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.
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
sent towards the MS within the parameter Network Control Order
inside PACKET MEASUREMENT ORDER message.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

NCRESELFLAG=ENABLE,
object:
range:
default:

BSC [BASICS]
DISABLE, ENABLE
DISABLE

NECI=FALSE,
object:
range:
default:
reference:

BSC [BASICS]
TRUE, FALSE
FALSE
GSM 04.08

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

55 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

NOTFACCH=NOSUPP,
object:
range:

default:

56 / 703

BSC [BASICS]
NOSUPP, ALWAYS,
EQA, HIGHEQB,
HIGHEQ0, HIGHEQ1,
HIGHEQ2, HIGHEQ3,
HIGHEQ4
NOSUPP

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.
Notification on FACCH, this parameter is relevant for ASCI only 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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.
8The meaning of the values is the following:
ALWAYS
HIGHEQ4
HIGHEQ3
HIGHEQ2
HIGHEQ1
HIGHEQ0
HIGHEQB
EQA

57 / 703

(Notification/FACCH will always be sent)


(Notification/FACCH will always be sent for calls having priority
equal or higher than 4)
(Notification/FACCH will always be sent for calls having priority
equal or higher than 3)
(Notification/FACCH will always be sent for calls having priority
equal or higher than 2)
(Notification/FACCH will always be sent for calls having priority
equal or higher than 1)
(Notification/FACCH will always be sent for calls having priority
equal or higher than 0)
(Notification/FACCH will always be sent for calls having priority
equal or higher than B)
(Notification/FACCH will always be sent for calls having priority

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
equal to A)

NSMEMALL=20-25,
object:
format:
range:

default:
FRS-No.:
SF-No.:

BSC [BASICS]
<onset threshold> <abatement threshold>
onset threshold: 0..100[%]
abatement threshold:
5..100[%]
20-25
89795
10507

Network Service Memory Allocation, this parameter is related to


the feature NS Overload Control (parameter CENNSOVLC, see
above) and indicates the idle memory blocks portion of the number of
available memory blocks, under which NS is considered in overload
due to memory pool or over which NS goes out of overload.
The onset threshold value must be lower than abatement one.
See also parameter NSLOAD (below).

Introduced in BR10.0

NSLOAD=92-85,
object:
format:
range:

default:
FRS-No.:
SF-No.:

BSC [BASICS]
<onset threshold> <abatement threshold>
onset threshold: 0..100[%]
abatement threshold:
5..100[%]
92-85
89795
10507

Network Service Load, this parameter is related to the feature NS


Overload Control (see parameter CENNSOVLC above) and defines
the overload condition onset threshold and overload abatement
threshold (in terms of NS processor time usage) for the NS Overload
Control.
The onset threshold value must be lower than abatement one.
See also parameter NSMEMALL (above).

Introduced in BR10.0

NTWCARD=NTWSNAP,
object:
range:
default:

BSC [BASICS]
NTWSNAP
NTWSNAP_STLP
NTWSNAP

NTWID=262-02,
object:
format:
range:

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.
Network Identifier, this parameter defines the network the BSC
belongs to by its MCC and MNC.

BSC [BASICS]
<MCC>-<MNC>
MCC: 0..999
MNC: 0..999 (PCS1900)
MNC: 0..99 (all others)

FRS-No.:
SF-No.:
Introduced in BR9.0

OVLSTTHR=9500,
object:
unit:
range:
default:

BSC [BASICS]
1000=10%
1000..10000
9500

OVLENTHR=8500,
object:
unit:
range:
default:

BSC [BASICS]
1000=10%
7000..10000
8500

PAGCOORCLB=DISABLED,
object:
range:
default:

58 / 703

BSC [BASICS]
ENABLED, DISABLED
DISABLED

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).
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).
Paging coordination class B, this flag enables/disables paging
coordination for MS class B (MS not capable to handle an CS and PS
connections simultaneously). With this feature the MS in Packet
Transfer Mode can be paged for CS connection with Packet Paging
Request message sent via PACCH (Packet Associated Control
Channel). Please note that in case of MS class B CS paging makes
an MS to abort a PS session before CS connection setup. Without

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

paging coordination and without Gs-interface (NOM II/III) the


establishment of the CS connection while in Packet Transfer Mode for
mobile stations being incapable of decoding paging channels during
TBF (Temporary Block Flow) is not possible.
Remark: This paramter has been introduced together with Dual
Transfer Mode feature, however the paging coordination for MS class
B can be enabled also in networks without DTM license.
PAGQOVLIND=DISABLED,
object:
range:
default:

BSC [BASICS]
0..100
0

PCMTYPE=PCM30,
object:
range:
default:

BSC [BASICS]
PCM30, PCM24
PCM30

PRIOPERNOTFA= EQA,
object:
range:

default:

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.
PCM type, specifies the type of PCM system used within the network.

BSC [BASICS]
ALWAYS; HIGHEQ4;
HIGHEQ3; HIGHEQ2;
HIGHEQ1;HIGHEQ0;
HIGHEQB;EQA;NOSUPP;
EQA

Introduced in BR10.0

Priority Periodical Notification FACCH - this parameter is used to


handle the periodical notification dependent on the priority.
When the call priority is equal or higher the one defined via this
attribute, the notification FACCH is sent periodically on the broadcast
channel as well as on the dedicated channels, if on the dedicated
ones the existing parameter ENPERNOTDE is set to TRUE
(enabled).
The existing parameter NOTFACCH is used to control the single shot
notifications on broadcast and dedicated channels. In case the priority
of the call is equal or higher the priority defined by this attribute, a
single shot notification (sent directly by BSC) is sent on the broadcast
and dedicated channels for all the calls having a priority up to the one
foreseen for the parameter PRIOPERNOTFA .
This means that in the case the ENPERNOTFA is set to FALSE
(disabled) on the dedicated channel the BSC will sent the single shot
notification for the priorities up to the highest one, i.e.0.
Examples:
Scenario 1:
PRIOPERNOTFA= 0
NOTFACCH =3
ENPERNOTDE= FALSE
Network behaviour:
- on the broadcast channels:
Periodical Notification provided only for priority= 0
-Single shot notification provided for priorities 3,2,1
- on dedicated channels:
Periodical Notification not provided
Single shot notification provided for priorities 3,2,1,0
Sceanrio 2:
PRIOPERNOTFA= 0
NOTFACCH =3
ENPERNOTDE= TRUE

59 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Network behaviour:
- on the broadcast channels
Periodical Notification provided only for priority= 0
Single shot notification provided for priorities 3,2,1
- on dedicated channels
Periodical Notification provided only for priority= 0
Single shot notification provided for priorities 3,2,1
Typical case for railways would be NOTFACCH=HIGHEQPRI3 or
ALWAYS and PRIOPERNOTFA=HIGHEQPRI2.
Q3TRACEON = FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

Introduced in BR10.0

Q3TraceOn, this parametr activates Q3 BSS tracing feature. It is only


relevant for EBSC.
In the previous BSS Releases the tracing of the Q3 interface (i.e
tracing of both IP based and X.25-based O-link) was based on
external tools/equipments (like for example: Sun Solaris osi_trace,
Sun Solaris X25 trace or protocol analyzer).
In case of error related to the Q3 interface or to the IP/X.25 networks
connectivity, it was required to collect osi_trace/x25 traces on Radio
Commander (RC), X.25 protocol analyzer traces or both. In many
cases the trace collection was complicated, mainly due to the
following aspects:
- very sporadic problem on Q3 required that it was necessary to
collect traces for a short period of time
- in some cases the RC did not support the osi_trace tool for the Ipbased O-link
- protocol analyzer was required to be installed in the BSC site
- the osi_trace tools could not trace high capacity link efficiently (a lot
of packets were lost)
- the osi_trace tool traces only all the BSS links taht the RC supports.
Therefore it is not simple to detect the affected BSS link
The traces needed to complete the analysis of the occurred problems
could be provided with high delay.

Therefore the new Q3 internal tracing feature was implemented. It has


the following characteristic:
-the user does not start external tools
-the user does not need external equipments (protocol analyzer) in
most of the cases
- the feature decreases the time needed to provide analysis and
solution to the occurred problem
Q3 BSS Tracing functionality produces logs for:
Case A: specific problems detected for a single configuration
command like for example (Get, Set, Create, Delete, Action)
Case B: problems detected during the RC eBSC alignment
Case C: sporadic problems (effecting the CMIP protocol (Common
Management Information Protocol) or the IP/X.25 network itself)
Router IP address 0, this parameter indicates the Router IP address
ROUIPADD0=<NULL>,
associated to all PCU port 0 (Ethernet port on the PPXU). It is used in
order to support High speed Gb Interface.
object:
BSC [BASICS]
range:
15 character string, <NULL> The convention used for this value is the dotted decimal format (e.g.
default:
<NULL>
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

60 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

the following configuration rules apply:


- the operator sets to <NULL> both Router IP Address 0 and 1
(parameters ROUIPADD0, ROUIPADD1), so that each PPXUs
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).
Router IP address 1, this parameter indicates the Router IP address
ROUIPADD1=<NULL>,
associated to all PCU port 1.
object:
BSC [BASICS]
For further information please refer to parameter ROUIPADD0 (see
range:
15 character string, <NULL> above)
default:

<NULL>

SCHEDPER=PER_32,
object:
BSC [BASICS]
range:
PER_8, PER_16, PER_32
default: PER_32
Introduced in RG20 (BR)

Scheduled period, this parameter indicates the number of slots in a


scheduled period, except the one used for the schedule message.
The schedule period is the time frame covered by a Schedule
Message in terms of slots (1 slot corresponds to 1,883 sec.)
When DRX(ENADRX=TRUE) is enabled, BSC generates the new
Scheduled Message that indicates the planned scheduling of
transmissions for MS.A Schedule Message includes information about
a number of immediately following consecutive CB messages,
planned for that cell.The length of time covered by the CB messages
referred to in a Schedule Message is called the Schedule Period of
that message. The Schedule Message contains a Message
Description for each CB message to be broadcast during the
scheduling period, in order of transmission. The position of a CB
message is called the "message slot number" of the CB message,
and it indicates the position of the CB message within the schedule
period.Each Message Description includes various information,
including for SMSCB messages directly or indirectly all or part of their
message identifier, and whether an occurrence is a repetition or not.
After receiving the schedule message on CBCH MS use the
scheduling information, contained in the message, to restrict the
reception only to those messages the user is interested in receiving.

Signaling priority PFC, this parameter is relevant for the feature


Allocation/Retention Priority (ARP, see parameter EARP in BSC
object below) and defines the three Predefined PF Context values
object:
BSC [BASICS]
format:
<allocation priority>- Allocation Priority
< re-emption capability>- Preemption Capability Indicator
< re-emption vulnerability>
- Preemption Vulnerability Indicator
range:
allocation priority: 1..3
re-emption capability: 0, 1 related to type of service signaling, as for this service the ARP
parameters will never be received from the SGSN via signaling.
re-emption vulnerability:
0,1
BSEPRIPFC is a SEQUENCE of these three aforementioned values.
default:
3-1-0
The ARP preemption algorithm uses the information of this parameter
FRS-No.: 89950
in order to assign (to predefined signaling service and to prerel99
SF-No.:
10506
Introduced in BR9.0
MS) the related values of allocation priority, preemption capability,
preemption vulnerability.
Any combination of Allocation priority, Preemption capability and
Preemption vulnerability values is allowed.
SIGPRIPFC=3-1-0,

SIMSCREL99=TRUE,
object:
range:
default:

61 / 703

BSC [BASICS]
TRUE, FALSE
TRUE

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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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).
SMS priority PFC, this parameter is relevant for the feature
Allocation/Retention Priority (ARP, see parameter EARP in BSC
object
below) and defines the three Predefined PF Context values
object:
BSC [BASICS]
format:
<allocation priority>- Allocation Priority
< re-emption capability>- Preemption Capability Indicator
< re-emption vulnerability>
- Preemption Vulnerability Indicator
range:
allocation priority: 1..3
re-emption capability: 0, 1 related to type of service SMS as for this service the ARP
parameters will never be received from the SGSN via signaling.
re-emption vulnerability:
0,1
BSEPRIPFC is a SEQUENCE of these three aforementioned values.
default:
3-0-1
The ARP preemption algorithm uses the information of this parameter
FRS-No.: 89950
in order to assign (to predefined SMS service and to prerel99 MS)
SF-No.:
10506
Introduced in BR9.0
the related values of allocation priority, preemption capability,
preemption vulnerability.
Any combination of Allocation priority, Preemption capability and
Preemption vulnerability values is allowed.
SMSPRIPFC=3-0-1,

SPEED145=FALSE,
object:
range:
default:

62 / 703

BSC [BASICS]
TRUE, FALSE
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
range:
default:

BSC [BASICS]
A_LAW
U_LAW
A_LAW

STPPDTUPGRCONG =100,
object:
range:
default:

BSC [BASICS]
0..100
100

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 U_LAW in
the parameter value)
Stop PDT upgrade for congestion indicates a threshold relative to
the maximum percentage of busy PDT per PCU object. When the
threshold is exceeded than the number of PDTs assigned is not
upgraded despite of link adaptation behaviour.

Introduced to BSC in RG20 (BR)

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.
object:
BSC [BASICS]
range:
15 character string, <NULL> The value must be assigned according to the local LAN configuration.
default:
<NULL>
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 PPXUs
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).
Sub net mask 1, this parameter this parameter is the NetMask for IP
SUBNETMASK1=<NULL>,
address of the PPXU-External router associated to all PCU port 1
(Ethernet port on the PPXU).
object:
BSC [BASICS]
range:
15 character string, <NULL> For further details please refer to parameter SUBNETMASK0 (see
default:
<NULL>
above).
SUBNETMASK0=<NULL>,

SYSPACKSYSSUP=FALSE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

T3122=5,
object:
unit:
range:
default:
Reference:

63 / 703

BSC [BASICS]
1s
0..255
5
GSM 04.08

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.
The purpose of the PACKET PSI STATUS/PACKET SI STATUS
procedures is to allow the MS to request from the BSC the PSI/SI
which it does not already have, without having to attempt to read them
from the PBCCH/BCCH (i.e. the MS can start with the transfer of data
quicker).
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 :
unit :
range :
default:

BSC [BASICS]
0.5s
3.. 5
4

TCBCSI=1,
object:
unit:
range:
default:

BSC [BASICS]
1 minute
0..1440
1

TDTMWIND=5,
object:
unit:
range:
default:
Reference:

BSC [BASICS]
1s
0..255
5
GSM 04.08

TGUARDTCHSD=SEC10,
object:
range:

default:

64 / 703

BSC [BASICS]
SEC00, SEC10, SEC11,
SEC12, SEC13, SEC14,
SEC15
SEC10

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

65 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

command SET BTS [INTERF]) during this period, even if the TCH/SD
is still in the SDCCH_BACKUP_POOL.
TOM 8 priority PFC, this parameter is relevant for the feature
Allocation/Retention Priority (ARP, see parameter EARP in BSC
object below) and defines the three Predefined PF Context values
object:
BSC [BASICS]
format:
<allocation priority>- Allocation Priority
< re-emption capability>- Preemption Capability Indicator
< re-emption vulnerability>
- Preemption Vulnerability Indicator
range:
allocation priority: 1..3
re-emption capability: 0, 1 related to type of service TOM8 (TOM8 = Tunneling Of Messages 8,
which is a PS service related to LCS) as for this service the ARP
re-emption vulnerability:
0,1
parameters will never be received from the SGSN via signaling.
default:
3-0-1
BSEPRIPFC is a SEQUENCE of these three aforementioned values.
FRS-No.: 89950
The ARP preemption algorithm uses the information of this parameter
SF-No.:
10506
Introduced in BR9.0
in order to assign (to predefined TOM8 service and to prerel99 MS)
the related values of allocation priority, preemption capability,
preemption vulnerability.
Any combination of Allocation priority, Preemption capability and
Preemption vulnerability values is allowed.
TOM8PRIPFC=FALSE,

TRACEMG=1,
object:
range:
default:

BSC [BASICS]
1..254
1

TRACEMR=TRUE,
object:
range:
default:

BSC [BASICS]
TRUE, FALSE
TRUE

TRANSPM=FALSE,
object:
range:
default:

66 / 703

Trace measurement granularity, this parameter allows to modify the


granularity of time for trace measurement reports.

BSC [BASICS]
TRUE, FALSE
FALSE

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
unit:
range:
default:

67 / 703

BSC [BASICS]
1 halfsecond
10.. 200
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:
b) 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 cellspecific 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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
range:
default:

BSC [BASICS]
TRUE, FALSE
FALSE

TYPOFAMC=DK40,
object:
range:

BSC [BASICS]
DK40, CPEX, ES

TYPOFETH= ETHERNETII,
object:
range:
default:

Type of Ethernet, this parameter determines the type of Ethernet


adopted for the internal LAN.

BSC [BASICS]
ETHERNETII, IEEE802
ETHERNETII

ULPWRD=5,
object:
range:
unit:
default:
FRS-No.:
SF-No.:

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).
Type of Alarm Module C, this parameter defines the type of the
equipped alarm module card.

BSC
0..16
1s
5 [s]
90199
10516

Uplink Power Control Delay, this parameter is relevant only if


ULPWRDSUP=TRUE (see below) and defines the delay time (in
seconds) which is signaled to the BTS during the SDCCH and first
TCH channel activation. The BTS uses this value to initialize the UL
Power Control delay timer and suspends MS Power Control for the
affected channel as long as the timer runs.

Introduced in BR 9.0

ULPWRDSUP=FALSE,
object:
range:
unit:
default:

68 / 703

BSC
TRUE, FALSE
FALSE
FALSE

Uplink Power Control Delay Support, this parameter enables, if set


to TRUE, the feature UL Power Control Delay for Emergency Calls
(precondition: the corresponding feature license must be available!).
In other words, if this parameter is set to TRUE, the BSC will trigger
the delay of MS power control for all calls whose setup signaling
indicates emergency call by sending the IE 'UL Power Control Delay

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
FRS-No.:
SF-No.:

90199
10516

Introduced in BR 9.0

VGSDBB=FALSE,
object:
range:
default:

BSC [FLAGS]
FALSE, TRUE
FALSE

FRS-No.:
SF-No.:

96747
10570

Introduced in BR10.0

69 / 703

towards the BTS in the CHANNEL ACTIVATION message for the


SDCCH and the first assigned TCH. The delay time is defined by
parameter ULPWRD (see above).

voiceGroupCallServicesDBB, this parameter enables Immediate


data distribution by the originating BSC when the feature Short Data
Transmission during ongoing Group Call is enabled (EEPTT
=TRUE).
This option speeds up the transfer time, especially if only one BSC
controls the entire GCA, the data transfer time could be accelerated
up to 200 ms. The BTS shall broadcast the data received from the
BSC immediately on the FACCH of the relevant group channel and on
the FACCH of a dedicated channel if there is any

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Creating new database parameters without info model change:


<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.>
BRIDGE BSC:
NAME=BSC:0,

Object path name.

ATT1=<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

object:
format:
range:

default:

BSC
parameter name parameter value
parameter name:
'<15 characters string>' parameter value
<value as defined by R&D>
<NULL>

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:
format:
range:

default:

70 / 703

Attribute 2 .. Attribute 8, these parameters allow the definition of


additional parameters and values (see parameter ATT1).

BSC
parameter name parameter value
parameter name:
'<15 characters string>' parameter value
<value as defined by R&D>
<NULL>

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

RELCMD=<NULL>,
object:
range:
default:

BSC
SET, GET
<NULL>

RELOBJ=<NULL>,
object:
range:
default:

71 / 703

Related command, this parameter defines the association of the


defined attributes (ATT1..ATT5) to a particular database command.

Related object, this parameter defines the association of the defined


attributes (ATT1..ATT5) to a particular database object.

BSC
<object path name>
<NULL>

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.

ALRMSEVAFLEXPOOL
=MAJOR,

Alarm severity AFLEXPOOL indicates the alarm severity associated


to AFLEXPOOL functional object.

object:
range:
default:

BSC [ALARMSEV]
Minor, Major, Critical
Critical

Introduced in BR10.0

ALRMSEVAPD=CRITICAL,
object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default:
Critical
Introduced in BR9.0

ALRMSEVAPM=CRITICAL,
object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default:
Critical
Introduced in BR9.0

ALRMSEVBTS=CRITICAL,
object:
range:
default:

Alarm severity BTSM, determines the alarm severity of the BTSM


object.

Alarm severity CBCL, determines the alarm severity of the CBCL


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVCSCTR =MINOR,
object:
range:
default:

Alarm severity BTS, determines the alarm severity of the BTS


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVCBCL =MAJOR,
object:
range:
default:

Alarm severity APM, determines the alarm severity of the APM


object.
Note that this attribute is only relevant for the eBSC!

BSC [ALARMSEV]
Minor, Major, Critical
Critical

ALRMSEVBTSM=MAJOR,
object:
range:
default:

Alarm severity APD, determines the alarm severity of the APD


object.
Note that this attribute is only relevant for the eBSC!

Alarm severity CS CTR, represents the alarm severity for the CS


CTR object.

BSC [ALARMSEV]
Minor, Major, Critical
Minor

Introduced in BR10.0

ALRMSEVCSIMSI =MINOR,
object:
range:
default:

72 / 703

Alarm severity CS IMSI, represents the alarm severity for the


TRACE object.

BSC [ALARMSEV]
Minor, Major, Critical
Minor

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
Introduced in BR10.0

ALRMSEVDPC=MINOR,

Alarm severity DPC, determines the alarm severity of the DPC


object.

object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Minor
Introduced in BR9.0

ALRMSEVFRL=MINOR,
object:
range:
default:

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

BSC [ALARMSEV]
Minor, Major, Critical
Minor

ALRMSEVGBIPLINK=MAJOR Alarm severity GBIPLINK, determines the alarm severity of the


GBIPLINK object.
,
object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Major
Introduced in BR9.0

ALRMSEVLINKSET=MAJOR, Alarm severity GBIPLINK, determines the alarm severity of the


GBIPLINK object.
object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Major
Introduced in BR9.0

ALRMSEVLPDLM=MAJOR,
object:
range:
default:

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVLPDLR=MAJOR,
object:
range:
default:

Alarm severity LPDLS, determines the alarm severity of the LPDLS


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVPSCTR =MINOR,
object:
range:
default:

Alarm severity LPDLR, determines the alarm severity of the LPDLR


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVLPDLS=MAJOR,
object:
range:
default:

Alarm severity LPDLM, determines the alarm severity of the LPDLM


object.

Alarm severity PS CTR, represents the alarm severity for the PS


CTR object.

BSC [ALARMSEV]
Minor, Major, Critical
Minor

Introduced in BR10.0

ALRMSEVPSIMSI =MINOR,
object:
range:
default:

Alarm severity PS IMSI, represents the alarm severity for the


PSTRACE object.

BSC [ALARMSEV]
Minor, Major, Critical
Minor

Introduced in BR10.0

ALRMSEVNSE=MAJOR,

Alarm severity NSE, determines the alarm severity of the NSE


object.

object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Major
Introduced in BR9.0

73 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ALRMSEVNSEVCIP=MINOR,

Alarm severity NSEVCIP, determines the alarm severity of the


NSEVCIP object.

object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Minor
Introduced in BR9.0

ALRMSEVNSEVLIP=MINOR,

Alarm severity NSEVLIP, determines the alarm severity of the


NSEVLIP object.

object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Minor
Introduced in BR9.0

ALRMSEVNSVC=MINOR,
object:
range:
default:

BSC [ALARMSEV]
Minor, Major, Critical
Minor

ALRMSEVOMAL=MAJOR,
object:
range:
default:

Alarm severity PCU, determines the alarm severity of the PCU


object.

BSC [ALARMSEV]
Minor, Major, Critical
Critical

ALRMSEVPTPPKF=MAJOR,
object:
range:
default:

Alarm severity PCMS, determines the alarm severity of the PCMS


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVPCU=CRITICAL,
object:
range:
default:

Alarm severity PCMG, determines the alarm severity of the PCMG


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVPCMS=MAJOR,
object:
range:
default:

Alarm severity PCMB, determines the alarm severity of the PCMB


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVPCMG=MAJOR;
object:
range:
default:

Alarm severity PCMA, determines the alarm severity of the PCMA


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVPCMB=MAJOR,
object:
range:
default:

Alarm severity OMAL, determines the alarm severity of the OMAL


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVPCMA=MAJOR,
object:
range:
default:

Alarm severity NSVC, determines the alarm severity of the NSVC


object.

Alarm severity PTPPKF, determines the alarm severity of the


PTPPKF object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVSGSNPOOL=
MAJOR,

Alarm severity SGSNPOOL, determines the alarm severity of the


SGSNPOOL object.

object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Major
Introduced in BR9.0

74 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ALRMSEVSS7L=MINOR,

Alarm severity SS7L, determines the alarm severity of the SS7L


object.

object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Minor
Introduced in BR9.0

ALRMSEVSTLSB=MINOR,

Alarm severity STLSB, determines the alarm severity of the STLSB


object.

object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Minor
Introduced in BR9.0

ALRMSEVTPC=MINOR,

Alarm severity TPC, determines the alarm severity of the TPC


object.

object:
BSC [ALARMSEV]
range:
Minor, Major, Critical
default: Minor
Introduced in BR9.0

ALRMSEVTRAU=CRITICAL,
object:
range:
default:

BSC [ALARMSEV]
Minor, Major, Critical
Critical

ALRMSEVTRX=MAJOR,
object:
range:
default:

75 / 703

Alarm severity TRAU, determines the alarm severity of the TRAU


object.

Alarm severity TRX, determines the alarm severity of the TRX


object.

BSC [ALARMSEV]
Minor, Major, Critical
Major

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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',

Sales Unique Name, this attribute defines the BSC Network Element
by its unique symbolic name.
Note: the attribute is also applicable to the EBSCE object (related to
the eBSC).

object:
range:

default:

BSC [REMINV]
alphanumeric string
(11 characters)
in quotation marks
NOT_DEFINED

EQPOS='010101',
object:
range:

default:

BSC [REMINV]
alphanumeric string
(6 characters)
in quotation marks
'010101'

EAUTOREC=ENABLED,
object:
range:
default:

76 / 703

Equipment position, this attribute defines the position of the


Network Element.
Note: the attribute is also applicable to the EBSCE object (related to
the eBSC).

Enable auto recovery, this attribute enables the automatic recovery.

BSC[REMINV]
ENABLED, DISABLED
DISABLED

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

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.

object:
range:
default:

BSCE [ALARMSEV]
Minor, Major, Critical
Minor

ALRMSEVDISK=MAJOR,
object:
range:
default:

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVDK40=MAJOR,
object:
range:
default:

77 / 703

Alarm severity MEMT, determines the alarm severity of the MEMT


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVMPCC=MAJOR,
object:

Alarm severity ME2M, determines the alarm severity of the ME2M


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVMEMT=MAJOR,
object:
range:
default:

Alarm severity LICDS, determines the alarm severity of the LICDS


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Minor

ALRMSEVME2M=MAJOR,
object:
range:
default:

Alarm severity LICD, determines the alarm severity of the LICD


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Minor

ALRMSEVLICDS=MINOR,
object:
range:
default:

Alarm severity IXLT, determines the alarm severity of the IXLT


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVLICD=MINOR,
object:
range:
default:

Alarm severity EPWR, determines the alarm severity of the EPWR


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVIXLT=MAJOR,
object:
range:
default:

Alarm severity DK40, determines the alarm severity of the DK40


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVEPWR=MAJOR,
object:
range:
default:

Alarm severity DISK, determines the alarm severity of the DISK


object.

Alarm severity MPCC, determines the alarm severity of the MPCC


object.

BSCE [ALARMSEV]

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
range:
default:

Minor, Major, Critical


Major

ALRMSEVNTW=MAJOR,
object:
range:
default:

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVPPXL=MINOR,
object:
range:
default:

78 / 703

Alarm severity X25A, determines the alarm severity of the X25A


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVX25D=MAJOR;
object:
range:
default:

Alarm severity TDPC, determines the alarm severity of the TDPC


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVX25A=MAJOR,
object:
range:
default:

Alarm severity SYNE, determines the alarm severity of the SYNE


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVTDPC=MAJOR,
object:
range:
default:

Alarm severity SYNC, determines the alarm severity of the SYNC


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVSYNE=MAJOR,
object:
range:
default:

Alarm severity PWRD, determines the alarm severity of the PWRD


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVSYNC=MAJOR,
object:
range:
default:

Alarm severity PPXU, determines the alarm severity of the PPXT


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Min or

ALRMSEVPWRD=MAJOR,
object:
range:
default:

Alarm severity PPXT, determines the alarm severity of the PPXT


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Min or

ALRMSEVPPXU=MINOR,
object:
range:
default:

Alarm severity PPXP, determines the alarm severity of the PPXP


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Min or

ALRMSEVPPXT=MINOR,
object:
range:
default:

Alarm severity PPXL, determines the alarm severity of the PPXL


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

ALRMSEVPPXP=MINOR,
object:
range:
default:

Alarm severity NTW, determines the alarm severity of the NTW


object.

Alarm severity X25D, determines the alarm severity of the X25D


object.

BSCE [ALARMSEV]
Minor, Major, Critical
Major

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Creating the Power Supply:


CREATE EPWR:
NAME=EPWR:0;

Object path name.

Setting the alarm priorities of the EBSCE objects:


SET EBSCE [ALARMSEV]:
NAME=EBSCE:0,

Object path name.

ALRMSEVAP=CRITICAL,

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

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Minor
Introduced in BR9.0

ALRMSEVEDISK=MAJOR,

Alarm severity EDISK, determines the alarm severity of the EDISK


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default: Major
Introduced in BR9.0

ALRMSEVETHLINE =MINOR, Alarm severity ETHLINE, determines the alarm severity of the
ETHLINE object.
object:
range:
default:

EBSCE [ALARMSEV]
Minor, Major, Critical
Minor

Introduced in BR10.0

ALRMSEVFANE=MAJOR,

Alarm severity FANE, determines the alarm severity of the FANE


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default: Major
Introduced in BR9.0

ALRMSEVIPLI=MAJOR,
object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVLIET=MAJOR,

Alarm severity IPLI, determines the alarm severity of the IPLI object.
The object represents the IP link used for the communication between
the eBSC and RC (or CBC).

Alarm severity LIET, determines the alarm severity of the LIET


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVLIETS=MAJOR,

Alarm severity LIETS, determines the alarm severity of the LIETS


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVLISO=MAJOR,
object:
range:
default:

79 / 703

Alarm severity LISO, determines the alarm severity of the LISO


object.

EBSCE [ALARMSEV]
Minor, Major, Critical
Major

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
Introduced in BR9.0

ALRMSEVLME=MAJOR,

Alarm severity LME, determines the alarm severity of the LME


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR10.0

ALRMSEVMCP=MAJOR,

Alarm severity MCP, determines the alarm severity of the MCP


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVOPTLINE=MAJOR, Alarm severity OPTLINE, determines the alarm severity of the


OPTLINE object.
object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVSHELFMGR=MAJ
OR,

Alarm severity SHELFMGR, determines the alarm severity of the


SHELFMGR object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVSMAC=MAJOR,

Alarm severity SMAC, determines the alarm severity of the SMAC


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVSYNC=MAJOR,

Alarm severity SYNC, determines the alarm severity of the LIET


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVSYNE=MAJOR,

Alarm severity SYNE, determines the alarm severity of the SYNE


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVT04INT=MAJOR,
object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVUPM=MAJOR,

Alarm severity T04INT, determines the alarm severity of the T04INT


object.
The object models the MCLG signal which is used to synchronise the
eBSC shelves, thus it only exists in the HighEnd configuration of the
eBSC.
Alarm severity UPM, determines the alarm severity of the UPM
object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

ALRMSEVX25A=MAJOR,

Alarm severity X25A, determines the alarm severity of the X25A


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

80 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ALRMSEVX25D=MAJOR,

Alarm severity X25D, determines the alarm severity of the X25D


object.

object:
EBSCE [ALARMSEV]
range:
Minor, Major, Critical
default:
Major
Introduced in BR9.0

81 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Defining the eBSC configuration:


SET EBSCE:
NAME=EBSCE:0,

Object path name.

HCC = HIGHEND,

High capacity configuration, the attribute defines the eBSC


configuration.
BASIC and HIGHEND configurations are applicable for eBSC and
eTRAU while BASICLOWER is only applicable for the eTRAU as it is
relevant for combined eTRAU configuration where Basic eBSC and
Basic eTRAU are installed in a single rack. In such case Basic
eTRAU must be installed in the lower shelf and this fact is reflected by
setting of attribute HCC in ETARUE (!) object to BASICLOWER. The
BASICLOWER configuration is Basic-like one as it follows all its rules
except:
- possibility to install LIET in the lower shelf (if HCC =
BASICLOWER, the LIET is not in use),
- possibility to create ENVAETRAU object because environmental
alarms of the combined system are handled by the eBSC
(ENVAEBSC).
Despite BASICLOWER value of HCC is also present for eBSC, for
the time being the Basic eBSC must never reside on the lower shelf
and thus any attempt to set HCC = BASICLOWER for eBSC shall be
prevented by SW (as the option is now only available for potential
future solutions).

object:
range:

EBSCE
BASIC, HIGHEND,
BASICLOWER
default: HIGHEND
Introduced in BR9.0
Range modified in BR10.0

BLADEPOS1=,
object:
format:

default:

EBSCE
path name (e.g.
'BLADEPOS1=EBSCRACK:0/
SHELF:0/MCP:1')
none

Blade position 1. The attribute indicates the shelf/slot in the rack


where 1st (active) MCP module is to be plugged in and the instance
number of the relevant object that shall be created.

Introduced in BR10.0

Blade Position 2. The attribute indicates the shelf/slot in the rack


where 2nd (redundant) MCP module is to be plugged in and the
EBSCE
path name (e.g.
instance number of the relevant object that shall be created. This
'BLADEPOS1=EBSCRACK:0/ Main Control Processor does redundancy of the other one, whose
SHELF:0/APD:1')
position is set by means of BLADEPOS1..
none

BLADEPOS2=,
object:
range:

default:

Introduced in BR10.0

82 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the RELEBSCNE object entries (object introduced in BR10.0):


SET RELEBSCNE :

The new object allows to navigate from the eBSC panel to the eTRAU
panel on RC GUI and is related to combined eTRAU configuration.

NAME=EBSCE:0..0/RELEBS
CNE:0..0
OMCIPADDR =NULL,

Object path name.

object:
range:
default:

OMC IP address. The attribute allows to set the IP address of the


OMC (RC) being in charge of the eTRAU management.

RELEBSCNE
7..15 characters string, NULL
NULL

Introduced in BR10.0

BSSNUM =NULL,
object:
range:
default:

BSS number. The attribute allows to set the identity number of the
BSS containing the related NE.

RELEBSCNE
0..83, NULL
NULL

Introduced in BR10.0

NEPATHNAME=NULL,
object:
range:
default:

RELEBSCNE
character string, NULL
NULL

Network Entity path name. The attribute allows to indicate the


instance number of the Network Entity installed in the same rack (e.g.
from EBSCE perspective it is the instance number of the related
eTRAU, i.e. that one located on the lower shelf of the combined
system).

Introduced in BR10.0

Creating the spare PCM interface boards:


CREATE LICDS:
NAME=LICDS:0,

83 / 703

Object path name.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Creating the PCM interface boards:


CREATE LICD:
NAME=LICD:0,

Object path name.

ALACOUNT=32,

PCM alarm counter, determines the threshold for errors that lead to
a PCM alarm (see also previous parameter ALARMT3).

object:
unit:
range:
default:

LICD
1
2-254
32

ALARMT1=20,
object:
unit:
range:
default:

LICD
0,1s
2-254
200=20s

ALARMT2=2,
object:
unit:
range:
default:

LICD
0,1s
2-254
10=1s

ALARMT3=5;
object:
unit:
range:
default:

84 / 703

LICD
5 min
1-254
1

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.

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.
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 [ALARMT35] minutes

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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)
- pcun = 0,,23
eBSC (UPM)
See command CREATE PCU as well!

CCHT=1,

Expected Outage Time, this parameter is related to the Gb and Um


bandwidth increasing mechanism which is part of the feature 'Gb
streaming enhancements' and is supposed to reflect the expected cell
reselection time. The value of this parameter is used to determine the
required Gb+Um bandwidth increment after cell change.

object:
range:
step size:
default:
FRS-No.:
SF-No.:

CPCU
0..10
1s
1[s]
10512
89990

EDTBFRELGMMSM =TRUE,
object:
range:
default:

CPCU
TRUE, FALSE
TRUE

Enable Delayed TBF Release During GMM and SM, this attribute
enables/disables the "delayed TBF releasing during Mobility
Management procedures".
Note: In BR10.0 this parameter replaced the functionallity of BIT10 in
MNTBMASK parameter.

Introduced in BR10.0

EENHPCUC=FALSE,
object:
range:
default:

CPCU
TRUE, FALSE
FALSE

Introduced in BR10.0

DNLBSSPFCRET=3,
object:
range:
default:

CPCU
1.. 5
3

DNLBSSPFCT=50,
object:
unit:
range:
default:

Download BSS PFC Timer, this parameter represents the timer T6


and guards the DOWNLOADBSS-PFC procedure.

CPCU
100ms
2.. 99
50

EXTULTBFI =FALSE,
object:
range:
default:

CPCU
TRUE, FALSE
FALSE

FRS-No:

95162

85 / 703

Enable Enhanced PCU Capacity indicates if the "Enhancements of


PCU's capacity" feature is enabled or not.
The feature aims at overcome the fact that, without the feature, there
is no mechanism that would allow to use the free resources of a less
loaded PCU to take over the excessive traffic of the overloaded
(heavier loaded) one, i.e. if the PCU is fully loaded then, without the
feature, a packet request coming in the cell being under supervision
of the PCU is rejected and TBF blocking rate increases. Such
mechanism is particularly useful to cope with congestion situation
within cell area served by the PCU.Enhanced PCU capacity feature
allows to temporarily serve more PDTs than those locally available:
- when a PCU overload occurs some PDTs can be borrowed from
less loaded PCU,
when a PCU load is low enough some PDTs can be lentto another
PCU(s) suffering due to lack of Abis resources.
Download BSS PFC Retries, this parameter guards the
DOWNLOAD-BSS-PFC-RETRIES number.

Extended UplinkTBF Improvements enables or disables the


"Extended Uplink TBF Improvement" feature (FRS 95162). Without
this improvement an MS being in Extended UL TBF mode and having
no RLC/MAC data to be sent (MS RLC buffer is empty) has to
transmit PACKET UPLINK DUMMY CONTROL BLOCK messages
towards the network. With this feature MS of Rel.6 and later ones can

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
Reference:

3GPP TS 44.060

Introduced in BR 10.0

FCRATE=100,
object:
range:
default:

CPCU
0.. 100
100

IDTRATH=587,
object:
range:

CPCU
0.. 2000

unit:
default:

octets
587

refrain from sending PACKET UPLINK DUMMY CONTROL BLOCK


messages while in Extended UL TBF Mode. An MS is informed about
the feature support via EXT_UTBF_NODATA bit in the GPRS Cell
Options Information Element. If EXTULTBF=TRUE, the
EXT_UTBF_NODATA=1and the trmasmissions of unnecessary
messages can be avoided. The main goal of this feature is to reduce
interference level in the netwokr and minimize MS battery
consumption.
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).
IDRA Threshold represents the length of LLC queue (in octets)
exceeding of which shall trigger the TBF reconfiguration (please see
IDRAACT for details).
IDRA algorithm tries to decrease the number of assigned PDCHs.

FRS-No:
IDRATH

SF No:
Introduced in BR10.0

IDRATSWITCH
IDRATSWITCH

IDRATSWITCH=20,
object:
range:
default:

CPCU
0.. 100
20

IDRATSWITCH

Periodically (every IDRATSWITCH timer expiration) the LLC queue


length (illustrated on the figure as TX Buffer Level) is checked against
IDTRATH and if the threshold is exceeded reconfiguration takes
place.
IDRA Timer Switch represents the time period between checks of
the LLC queue length against IDTRATH threshold to decide about the
switch from IDRA to MSM/Peak Throughput allocation algorithm
(please see IDRAACT for details).

Introduced in BR10.0
Introduced in BR10.0

MAXNPDT=<NULL>,
object:
range:

CPCU
cBSC:
0.. 3072
eBSC:
0.. 8500

default:

<NULL>

Max number PDT, this parameter represents the maximum number


of PDT (Packet Data Terminal) that could be used for the particular
CPCU. With the help of this parameter it is possible to assure suitable
and fair distribution of PDTs between different CPCUs.
This parameter was introduced together with the implementation of
the BR10.01 feature MOBSS 2G Network Sharing Solution in order
to share the resources between different operators in a reasonable
way taking into account that number of available PDTs per BSC is
limited.

FRS-No.: 96782
SF-No.:
Introduced in BR10.01

MODBSSPFCRET=3,
object:
range:
default:

CPCU
1.. 5
3

MODBSSPFCT=50,
object:
unit:
range:

86 / 703

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

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

PCU
100ms
2.. 99

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
default:

50

N3101=20,
object:
range:
default:

CPCU
9..255
20

N3103=10,
object:
range:
default:

CPCU
1.. 255
10

N3105=10,
object:
range:
default:

CPCU
1.. 255
10

PFCFCSUP=FALSE,
object:
range:
default:

CPCU
TRUE, FALSE
FALSE

PFCSUP=DISABLED,
object:
range:
default:

CPCU
ENABLED, DISABLED
DISABLED

PREAT=20,
object:
unit:
range:
default:

CPCU
100ms
0.. 100
20

SISGSNREL99=TRUE,
object:
range:
default:

87 / 703

CPCU
TRUE, FALSE
TRUE

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.
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.
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.
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.
Note: This parameter was moved from the PCU object to the CPCU
object in BR9.0.
Packet flow context support, this parameter allows to
enable/disable the Packet Flow Context procedure support.
Note: This parameter was moved from the PCU object to the CPCU
object in BR9.0.
Preallocation timer, this parameter represents the timer guarding reutilisation of preallocated resources for Real Time Packet Flow
Context (RTPFC).

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

CPCU
0..100
100

Stop PDT upgrade for congestion indicates a threshold relative to


the maximum percentage of busy PDT per PCU object. When the
threshold is exceeded than the number of PDTs assigned is not
upgraded despite of link adaptation behaviour.

Introduced in BR10.0

STREAMSUP=DISABLED,
object:
range:
default:

CPCU
ENABLED, DISABLED
DISABLED

T3141=5,
object:
unit:
range:
default:

CPCU
1s
1.. 30
5

T3169=5,
object:
unit:
range:
default:

CPCU
1s
1.. 30
5

T3172=5,
object:
unit:
range:
default:

CPCU
1s
0..255
5

88 / 703

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

CPCU
1s
1-30
5

CPCU
100 ms
1-42
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

T3193=4,
object:
unit:
range:
default:

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. For the explanation of contention resolution mechanism see
description of EEGTLLIBLKCHC parameter.
Note: This parameter was moved from the PCU object to the CPCU
object in BR8.0.

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.

T3191=5,
object:
unit:
range:
default:

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


time streaming support.
Note: This parameter was moved from the PCU object to the CPCU
object in BR9.0.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

abandoned this TFI).


Note: This parameter was moved from the PCU object to the CPCU
object in BR8.0.
T3195=5,
object:
unit:
range:
default:

CPCU
1s
0..255
5

TCCOCCC=900,
object:
CPCU
range:
0..1000
unit:
1 ms
step size:
50 ms
default:
900 [ms]
FRS-No.: 89990
SF-No.:
10512
Introduced in BR9.0

TDABISSAT=15,
object:
CPCU
range:
10..50
unit:
1 ms
step size:
default:
15
FRS-No.:
SF-No.:
Introduced in BR9.0

TEMPCH=30,
object:
unit:
range:
default:

89 / 703

CPCU
1s
1.. 254
30

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.

PCCN-PCCO/PCCC Delay, this parameter is related to the RLC


buffer empting procedure which is a part of Gb streaming
enhancement feature.
In NCCR and NACC mode when BSS detects that a cell change is
incoming (NACC: receiving of PCCN (Packet Cell Change
Notification), NCCR: triggered by NCCR algorithm) it keeps
transmitting LLC-PDUs over radio interface till sending of the
PCCC/PCCO message. Sending of PCCO/PCCC (Packet Cell
Change Order/Packet Cell Change Continue) is delayed by the value
of TCCOCCC (PCCO/PCCC message is sent only at TCCOCC
expiry).
Exception: The PCCO/PCCC message is sent immediately if the
coding scheme used on DL is CS1/MCS1 (timer TCCOCC is stopped
and reset then).
Transfer Delay on Abis Satellite, this parameter defines the
minimum transfer delay which can be supported by the system. PFC
that requires transfer delay smaller than its value shall be not
accepted.

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 parameter
DGRSTRGY in command CREATE BTS [BASICS]).
Note:
- While the timer TEMPCH (see below) is started for the PDTCH
(GPRS radio timeslot) and one associated PDT (Abis timeslot), the
timer TEMPPDT can only be started for all additional PDTs (i.e. at the
maximum all but one). For this reason the value of TEMPPDT must
be in any case smaller than the value of TEMPCH.
- This parameter was moved from the PCU object to the CPCU object
in BR8.0.
TEMPPDT=1,
object:
unit:
range:
default:

CPCU
1s
1.. 30
15

TEXTULTBF=15,
object:
unit:
range:
default:

90 / 703

CPCU
0.1s
0.. 49
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).
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:
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. Assuming a sudden downgrade of the
coding scheme to MCS6 (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.
Notes:
- While the timer TEMPCH (see above) is started for the PDTCH
(GPRS radio timeslot) and one associated PDT (Abis timeslot), the
timer TEMPPDT can only be started for all additional PDTs (i.e. at the
maximum all but one). For this reason the value of TEMPPDT must
be in any case smaller than the value of TEMPCH.
- Field applications have shown that a careful reduction of the timer
TEMPPDT to values smaller than the default value can help to
overcome TBF blocking situations.
- This parameter was moved from the PCU object to the CPCU object
in BR8.0.
Time extended Uplink TBF, this attribute is used to delay the
release of an UL Temporary Block Flow (TBF) in Extended UL TBF
mode.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

THPROXT=500..50..550,
object:
format:
unit:

range:

default:

CPCU
thproxt1-thproxt2-thproxt3
thproxt1: 1ms
thproxt2: 1s
thproxt3: 1s
thproxt1: 10..999
thproxt2: 1..100
thproxt3: 101..1000
500..50..550

THSULBAL=587,
object:
range:
default:

CPCU
0.. 2000
587

TIMEDTBFREL=15
object:
unit:
range:
default:

CPCU
100ms
0.. 49
15

TPFCBUFF=20
object:
unit:
range:
default:

CPCU
1s
5.. 30
20

TSULBAL=20,
object:
range:
default:

CPCU
0..100
20

UPGRFREQ=SEC1-SEC1,
object:
format:
range:
default:

91 / 703

CPCU
<uplink> - <downlink>
SEC1..SEC8 (both fields)
SEC1 (both fields)

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.

92 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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)
- pcun = 0,,23
eBSC (UPM)
Note that in case of the eBSC although the pcun range is quite
extensive the max number of PCU instances is restricted to 11 (only
possible if Central NS layer enabled within the eBSC which is fully
equipped with the UPM boards otherwise the max number of PCU
instances is 10). This is connected to the fact that the creation of a
PCU implies the creation of a UPM card with the same instance
number as the PCU - and the relation between the number of UPM
instance and the number of slot in the eBSC rack is also fixed.

BLADEPOS1=,

Blade position 1. The attribute indicates the shelf/slot in the rack


where UPM module is to be installed and the instance number of the
object that shall be created.

object:
range:

PCU
path name (e.g.
'BLADEPOS1=EBSCRACK:0/
SHELF:0/UPM:1')

default:

none

Introduced in BR10.0

CPCUN=0,
object:
range:

Common PCU number, this parameter represents the CPCU object


number to which this PCU belongs.

PCU
0..11

STPPDTUPGRCONG=100,
object:

PCU

range:
default:

0.100
100

Stop PDT upgrade for congestion, it indicates a threshold relative


to the maximum percentage of busy PDT per PCU object. When the
threshold is exceeded than the number of PDTs assigned is not
upgraded despite of link adaptation behaviour.

Introduced in BR10.0

THPROXT=500..50..550,
object:
format:
unit:

range:

default:

93 / 703

PCU
thproxt1-thproxt2-thproxt3
thproxt1: 1ms
thproxt2: 1s
thproxt3: 1s
thproxt1: 10..999
thproxt2: 1..100
thproxt3: 101..1000
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!

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Creating the Network Service Entity (NSE):


< This command creates the Network Service Entities (NSE) for the
BSCs communication with the SGSN.
The way the NSEs have to be created depends on the enabling state
of the feature 'Central Network Service Layer' (CNSL, see parameter
CENNS in command SET BSC [BASICS]):
A) CNSL disabled -> Dedicated NSE applied (CENNS=FALSE)
- 1 NSE has to be created by the operator for each PCU
- 1 PPXU/UPM is auto-created by the system for each created PCU
- PPXU/UPM instance is equal to PCU instance
B) CNSL enabled -> Central NSE applied (CENNS=TRUE)
- 1 NSE has to be created by the operator
- 1 PPXU/UPM is auto-created by system per each PCU
- The PPXU/UPM supporting NSE is chosen by the system
The table below lists how many NSEs can be created per BSC,
depending on the BSC HW platform and the enabling of CNSL

>
CREATE NSE:
NAME=nse:0,

Object path name.

BARINNASNS =FALSE,

Barred in NAS node selection, this attribute indicates the usability of


the SGSN NSE in the default CN algorithm.
Please refer to BARINNASNS attribute of MSC object for further
information.

object:
range:
default:

NSE
TRUE, FALSE
FALSE

Introduced in BR10.0

BCGRTODIFFSERV=0,
object:
range:
default:

NSE
0.. 63
0

BEPFITODIFFSERV=0,
object:
range:
default:

NSE
0.. 63
0

DIFFSERVSUP=<NULL>,
object:
range:

default:
FRS-No.:
SF-No.:

94 / 703

NSE
DISABLED (0)
ENABLED (1)
<NULL>
see description
89795, 89900
10503, 10507

Background to Different Service, this parameter represents the


mapping between background class and DSCP coding.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Best effort PFI to Different Service, this parameter represents the
mapping between predefined PFI best effort parameter and DSCP
coding.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Different Service Support, the default of DIFFSERVSUP depends
on the value of GBSNS attribute:
GBSNS (value)
DIFFSERVSUP (default)

FRFIX
NULL

IPV4
DISABLED

Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

GBSNS=FRFIX,
object:
range:

default:
FRS-No.:
SF-No.:

NSE
BSC1:
FRFIX, FRVAR, IPV4ETH
eBSC:
FR_E1T1, IPv4_ETH,
IPV4_ATM
FRFIX
89795, 89900
10503, 10507

GBSUSE=FALSE,
object:
NSE
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 89990
SF-No.:
10512
Introduced in BR9.0

INTRTRFH2TODIFFSERV=0,
object:
range:
default:

NSE
0.. 63
0

INTRTRFH1TODIFFSERV=0,
object:
range:
default:

NSE
0.. 63
0

INTRTRFH3TODIFFSERV=0,
object:
range:
default:

NSE
0.. 63
0

LLCID00=
SDH:x/INTF:y/ATMVP:z/ATM
VC:j,
object:
range:
FRS-No.:
SF-No.:

95 / 703

Gb Suspend Enabled, this parameter is used to enable the Gb


SUSPEND procedure that allows to suspend the downlink
transmission from SGSN to BSS prior to the cell change. This could
make it possible for the BSS to completely transfer the BSS downlink
buffer to the MS prior to the cell change and thus to reduce or avoid
the LLC-PDUs packet losses in case of cell changes where Flush
Procedure can not be applied.
The Gb SUSPEND procedure can be enabled only if:
- at least one of the two procedures Network Assisted Cell Change
(NACC) or Network Controlled Cell Reselection (NCCR) is enabled
- if the PFC Flow Control feature is enabled i.e. the attribute GBSUSE
can be set to TRUE only if the PFCSUP (CPCU object) is set to
ENABLED.
- the LLCPDU attribute (see below) is set to ENABLED
Interactive traffic handling priority 2 to Different Service, this
parameter represents the mapping between interactive class with
traffic handling 2 and DSCP coding.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Interactive traffic handling priority 3 to Different Service, this
parameter represents the mapping between interactive class with
traffic handling 3 and DSCP coding.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Interactive traffic handling priority 1 to Different Service, this
parameter represents the mapping between interactive class with
traffic handling 1 and DSCP coding.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Link Layer Connection ID 00, this parameter is only relevant for the
eBSC HW platform and defines the pathname that identifies the
Virtual Channel for the LLCID00.

NSE
path name
89795, 89900
10503, 10507

LLCID01=
SDH:x/INTF:y/ATMVP:z/ATM
VC:j,
object:
range:
FRS-No.:
SF-No.:

Gb Subnetwork Service, this parameter indicates the sub network


service used for CPU.
Since BR9.0 there is new Gb Subnetwork Service possible for eBSC,
i.e. ATM based IP network.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.

Link Layer Connection ID 01, this parameter this parameter is only


relevant for the eBSC HW platform and defines the pathname that
identifies the Virtual Channel for the LLCID01

NSE
path name
89795, 89900
10503, 10507

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

LLCPDU=1,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
0 (= disabled)
1 (= enabled)
0 (= disabled)
89990
10512

MTRTD=300,
object:
range:
unit:
step size:
default:
FRS-No.:
SF-No.:

NSE
0.. 2000
1 ms
50 ms
300 [ms]
89990
10512

MTU=<NULL>,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
68 .. 1500
<NULL>
see description
89795, 89900
10503, 10507

LLC-PDU Discarding Policy TD Based. If this parameter set to


'enabled' then TD-Based Discarding policy is enabled.
LLC PDU discarding policy can be enabled independently from the
enabling of Gb SUSPEND procedure (to enable the Gb SUSPEND
procedure LLC PDU discarding policy must be active).

Maximum transfer delay, this parameter is related to Gb streaming


and is used to decide if the Gb SUSPEND procedure (enabled by
parameter GBSUSE, see above) is to be applied in case of DL
Streaming PFC.
The procedure is activated if TD>TDmin.
TD is indicated in the ABQP (Aggregate BSS QoS Profile).
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)
MTU (default)

FRFIX
NULL

IPV4
1500

Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
MULTD=1,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
1.. 10
1
89990
10512

NBVCBR=3,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
1.. 30
3
89795, 89900
10503, 10507

NBVCRR=3,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
1.. 30
3
89795, 89900
10503, 10507

NBVCUR=3,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
1.. 30
3
89795, 89900
10503, 10507

NMO=NMO_2,

96 / 703

Multiplier TD (Trec). If the TD-Based LLC-PDUs discarding policy is


enabled (parameter LLCPDU, see above) then, for streaming PFC
ONLY, the BSS LLC-PDUs discarding mechanism applies
considering the minimum value between Transfer Delay (TD)
parameter as defined within ABQP multiplied by Multiplier_TD
parameter and the LLC-PDU lifetime carried by LLC-PDUs
themselves.
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 CPCU object to the NSE
object in BR9.0.
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 CPCU object to the NSE
object in BR9.0.
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 CPCU object to the NSE
object in BR9.0.
Network mode of operation, this parameter determines which types
of channels the MS has to monitor for paging messages.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
object:
range:
default:

NSE
NMO_1, NMO_2, NMO_3
NMO_2

In Network Mode of Operation I (NMO_1) the network sends circuitswitched 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 packetswitched 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 circuitswitched 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.
This parameter was moved from the PCU object to the NSE object in
BR9.0.
NNSVCBLKR=3,
object:
range:
default:
FRS-No.:
SF-No.:

97 / 703

NSE
1..254
3
89795, 89900
10503, 10507

This parameter specifies the Maximum number of retries


performed in the NSVC block procedure. If the SGSN does not
answer to the block procedure, the procedure is retried for
NNSVCBLKR times.
Note: This parameter was moved from the CPCU object to the NSE
object in BR9.0.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

NNSVCRR=10,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
1..254
10
89795, 89900
10503, 10507

NNSVCTSTR=10,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
1.. 30
10
89795, 89900
10503, 10507

NNSVCUBLR=3,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
1.. 254
3
89795, 89900
10503, 10507

NSEI=<NULL>,
object:
range:
FRS-No.:
SF-No.:

NSE
0..65534
89795, 89900
10503, 10507

PORT0=<NULL>,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
string 7..15 chars
<NULL>
89795, 89900
10503, 10507

PORT1=<NULL>,
object:
range:
default:

98 / 703

NSE
string 7..15 chars
<NULL>

This parameter specifies the Maximum number of retries


performed in the NSVC reset procedure before generating any
alarm. If the SGSN does not answer to the reset procedure, the
procedure is retried infinitely but after NNSVCRR times an O&M
alarm is notified.
Note: This parameter was moved from the CPCU object to the NSE
object in BR9.0.
This parameter specifies the Number of consecutive retries
performed for the NS test procedure (exchange of NS-ALIVE/NSALIVE-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.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
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.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
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.
In case of CNSL feature enabled (CENNS = TRUE, see command
SET BSC [BASICS]) there is only one NSEI per whole BSC because
of the CNSL functionality (before BR9.0 one to one relation was kept
between PCUs and NSEI identifiers).
PPXU-NS/UPM-NS has to support several instances of NS layer
(=several NSEs), each identified with different NSEI. This is required
for the Flexible Gb functionality.
Notes:
- This parameter can be set only if the object NSE is in 'locked' state.
- This parameter was moved from the PCU object to the NSE object
in BR9.0.
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').
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
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').
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

REQRECT=5,
object:
NSE
range:
0..5
step size:
1s
default:
5[s]
FRS-No.: 10512
SF-No.:
89990
Introduced in BR9.0

SMSPFITODIFFSERV=0,
object:
range:
default:

NSE
0.. 63
0

SNSADDRET=<NULL>,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
0.. 16
<NULL>
see description
89795, 89900
10503, 10507

SNSCHWEIRET=<NULL>,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
0.. 16
<NULL>
see description
89795, 89900
10503, 10507

SNSCONFRET=<NULL>,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
0.. 16
<NULL>
see description
89795, 89900
10503, 10507

SNSDELRET=<NULL>,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
0.. 16
<NULL>
see description
89795, 89900
10503, 10507

SNSSIZERET=<NULL>,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
0.. 16
<NULL>
see description
89795, 89900
10503, 10507

SPFITODIFFSERV=0,
object:
range:
default:

NSE
0.. 63
0

STPIPEP=<NULL>,
object:

99 / 703

NSE

Required Recovery Time (Trec), this parameter defines the value of


the timer that is activated at the TBF re-establishment after cell
change. When the timer is started, the Gb+Um bandwidth increasing
mechanism is activated.
Gb+Um bandwidth increasing mechanism is stopped after the timer
expires.
Parameter should be set equal to the minimum time interval between
two subsequent cell reselections.
SMS PFI to Different Service, this parameter represents the
mapping between predefined PFI SMS parameter and DSCP coding.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Subnetwork service address retries, the default value of this
parameter depends on the value of GBSNS attribute:
GBSNS (value)
SNSADDRET (default)

FRFIX
NULL

IPV4
3

Subnetwork Service change weight retries, the default of this


parameter depends on the value of GBSNS attribute:
GBSNS (value)
SNSCHWEIRET (default)

FRFIX
NULL

IPV4
3

Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Subnetwork Service configuration retries, the default of this
parameter depends on the value of GBSNS attribute:
GBSNS (value)
SNSCONFRET (default)

FRFIX
NULL

IPV4
3

Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Subnetwork Service delete retries, the default of this parameter
depends on the value of GBSNS attribute:
GBSNS (value)
SNSDELRET (default)

FRFIX
NULL

IPV4
3

Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Subnetwork Service size retries, the default of this parameter
depends on the value of GBSNS attribute:
GBSNS (value)
SNSSIZERET (default)

FRFIX
NULL

IPV4
3

Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Signalling PFI to Different Service, this parameter represents the
mapping between predefined PFI signalling parameter and DSCP
coding.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Startup remote IP endpoint, this parameter indicates the startup
remote IP endpoint.
If FLEXGBSUP is set to TRUE (i.e. more than one SGSN connected

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
format:
range:

<ipAddress>-<udpPort>
ipAddress: string 7...15 chars
udpPort: 1024 ... 65535
default: <NULL>
FRS-No.: 89795, 89900
SF-No.: 10503, 10507

STREAMTODIFFSERV=0,
object:
range:
default:

NSE
0.. 63
0

T1=10,
object:
unit:
range:
default:

NSE
1s
2.. 29
10

T2=10,
object:
unit:
range:
default:

NSE
1s
2.. 119
10

T3=50,
object:
unit:
range:
default:

NSE
0,1s
1.. 100
50 (= 5s)

T4=10,
object:
unit:
range:
default:

NSE
0,1s
1.. 100
10 (= 1s)

T5=10,
object:
range:
default:

NSE
2.. 29
10

TF=6,
object:
range:
default:

NSE
6.. 5999
???

TF1=5,
object:
unit:
range:
default:
GSM:

NSE
1s
2.. 9
5
08.18

TH=6,
object:
range:
default:

100 / 703

NSE
6.. 5999
none

to the BSC; each SHSN is using different NSE, see command SET
BSC [BASICS]), then it has to be ensured that all NSE objects have
different startup remote IP endpoints.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Stream to Different Service, this parameter represents the mapping
between streaming class and DSCP coding.
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
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 CPCU object to the NSE
object in BR9.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 CPCU object to the NSE
object in BR9.0.
T3, this timer defines the waiting time for a response from the SGSN
after sending a SUSPEND PDU.
Note: This parameter was moved from the CPCU object to the NSE
object in BR9.0.
T4, this timer defines the waiting time for a response from the SGSN
after sending RESUME PDU.
Note: This parameter was moved from the CPCU object to the NSE
object in BR9.0.
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.
Note: This parameter was moved from the CPCU object to the NSE
object in BR9.0.
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.
Note: This parameter was moved from the CPCU object to the NSE
object in BR9.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 CPCU object to the NSE
object in BR9.0.
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.
Note: This parameter was moved from the CPCU object to the NSE

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

TNSVCBLK=3,
object:
unit:
range:
default:
FRS-No.:
SF-No.:

NSE
1s
1.. 10
3
89795, 89900
10503, 10507

TNSVCPTST=3,
object:
unit:
range:
default:
FRS-No.:
SF-No.:

NSE
1s
1.. 10
3
89795, 89900
10503, 10507

TNSVCR=3,
object:
unit:
range:
default:
FRS-No.:
SF-No.:

NSE
1s
1.. 10
3
89795, 89900
10503, 10507

TNSVCTST=30,
object:
unit:
range:
default:
FRS-No.:
SF-No.:

NSE
1s
1.. 60
30
89795, 89900
10503, 10507

TSNPRO=<NULL>,
object:
range:
default:
FRS-No.:
SF-No.:

NSE
0.. 16
<NULL>
see description
89795, 89900
10503, 10507

object in BR9.0.
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).
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
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).
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
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).
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
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 NSALIVE PDU is sent towards the SGSN every TNSVCTST seconds. If
no acknowledge arrives in time (TNSCVPTST), the test procedure is
repeated (NNSVCTSTR).
Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.
Time Subnetworks procedure, the default of this parameter
depends on the value of GBSNS attribute:
GBSNS (value)
TSNPRO (default)

FRFIX
NULL

IPV4
10

Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.

TYPOFNSVCCONF=<NULL>, Type of NSVC Configuration, this parameter indicates the method


of configuration of the NS-VCs for the IP sub network service.
object:
NSE
The default of this parameter depends on the value of GBSNS
range:
0.. 16
attribute:
<NULL>
default:
FRS-No.:
SF-No.:

see description
89795, 89900
10503, 10507

GBSNS (value)
TYPOFNSVCCONF (default)

FRFIX
NULL

IPV4
STATIC

Note: This parameter was moved from the PCU object to the NSE
object in BR9.0.

101 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Creating an SGSN Pool:


< This command creates the pool of SGSNs. This object can contain
up to 10 SGSN relations, i.e. the BSC can be served at the same time
by up to 10 SGSNs by proper configuration of this object. Only one
SGSNPOOL object can be created per BSC. Nevertheless one BSC
can belong to number of overlapping Pool Areas, which are served by
different SGSN Pools. Multiple or overlapping Pool Areas can be
created in the network by proper SGSNPOOL objects configuration
(i.e. NRIRELNSE attributes).
For more details please refer to the CNSL & Flexible Gb Planning
Rule.>
CREATE SGSNPOOL:
NAME=sgsnpool:0,

Object path name.

ESGSNPOOLARP=TRUE,

Enable SGSN Pool ARP, this parameter enables Allocation


Retention Priority (ARP, see parameter EARP in command SET BSC
[BASICS]) in the SGSN Pool. Controls the flow control strategy
chosen.
The ESGSNPOOLARP parameter can be set to TRUE only if the
'Allocation Retention Priority' feature is enabled BSC side; in other
words if parameter EARP (see command SET BSC [BASICS]) is set
to TRUE.

object:
SGSNPOOL
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 89795, 89900
SF-No.:
10503, 10507
Introduced in BR9.0

LSHRMTD = STANDARD,
object:
range:

default:

SGSNPOOL
STANDARD,
WEIGHT_PERCENTAGE,
WEIGHT_ABSOLUTE
STANDARD

Introduced in BR10.0

Load sharing method. The attribute allows to indicate a method to


choose default SGSN which is responsible in the SGSN pool for
handling of the incoming access requests that do not contain a valid
MSC identifier. In such case the system is not able to derive from
TMSI the NRI (Network Resource Identifier) that points the SGSN
where the user is registered to and thus is supposed to be served. In
order to ensure fair Core Network sharing within the SGSN pool, the
default SGSN is set temporarily (for some time or for some amount
of incoming requests) rather than permanently based on SGSN load
situation (that may vary during the time) and customer preference
using one of hereafter described methods:
- STANDARD
In the method the time of operation is divided into 20 sec intervals
during which every SGSN in the pool acts successively as the default
one for some period of time. This time, called persistency time,
depends on SGSN overload conditions as well as on the transmission
capacity available on Gb interface and is computed by means of the
following formula:

Tp i =

w i i
N

(w

20 sec

i )

i =0

where:
Tpi persistency time of i-th SGSN in the pool
N number of SGSN in the pool
wi a weight reversely proportional to the i-th SGSN overload level:
wi = 10 overloadLevel(SGSNi); overloadLevel = 09
i a factor representing the transmission capacity available on
PCMG that is equal to the number of configured TSLs which can be
used for traffic, i.e. excluding signaling, NUCs, etc.
For example: when SGSN pool comprises of 2 SGSNs and they both
are in the same overload state and have the same number of
resources available on Gb interface then persistency times of both
SGSNs are also the same and equal to 10 sec. It means that each

102 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

SGSN is default one for the period of 10 sec unless any element of
the formula above is modified (which is the case due to e.g. a CN
node failure or load change, a PCMG failure or reconfiguration).
- WEIGHT_PERCENTAGE
In this method percentage of incoming attempts only matters and no
time interval is taken into account. Therefore, instead of time interval,
an attempts interval is set to 100 to convert the percentage into the
(integer) number of attempts to be handled by the default SGSN.
Percentage (out of 100 attempts) of the incoming requests that are
routed to the i-th SGSN is defined by means of the following formula:

Pri =

w i i
N

(w

100

i )

i= 0

where:
Pri percentage of attempts to be routed to the i-th SGSN in the pool
N number of SGSNs in the pool
wi a weight reversely proportional to the i-th SGSN overload level:
wi = 10 overloadLevel(SGSNi); overloadLevel = 09
i a factor used to rank the available CN nodes: the weight of i-th
SGSN is user defined (see WEIRELSGSN<n> attribute of
SGSNPOOL object).
For example: when SGSN pool comprises of 2 SGSN and they both
are in the same overload state and have their weights set to 90% and
30% then the first SGSN will take 75 attempts and the second one 25.
Please note that sum of weights of all individual CN nodes in the
SGSN pool do not need to be equal 100.
- WEIGHT_ABSOLUTE
In this method the absolute number of incoming attempts to be routed
to the individual MSC can be defined rather than any percentage.
The number of attempts addressed to the i-th CN node is computed
by means of the following formula:

Nri = w i i
where:
Nri number of attempts to be routed to the i-th SGSN in the pool
wi a weight reversely proportional to the i-th SGSN overload level:
wi = 10 overloadLevel(SGSNi); overloadLevel = 09
i a factor used to rank the available CN nodes: the weight of i-th
SGSN is user defined (see WEIRELSGSN<n> attribute below).
Note that for this method it Is recommended to keep the sum of
weights of all individual CN nodes in the SGSN pool below 100 as in
this way it is assured that after a reasonable amount of call attempts
all SGSN are in use.
NRIRELNSE0..NRIRELNSE9= NRI Related to NSE0(..NSE9), these parameters store the
relationship information among NSE0..NSE9 (i.e. SGSNs) and NRI
<NULL>,
values. Using these parameters, up to 10 SGSN's can be assigned to
object:
SGSNPOOL
the SGSNPOOL object for BSC.
format:
(min1-max1)&
NRIs (Network Resource Identifier) are assigned by the operator to
(min2-max2)&
the Core Network entity, i.e. to the SGSN in this case. Based on

these identifiers BSC recognizes CN nodes, which are linked with


(min20-max20),
BSC by NSEI attributes of NSE object and each connected SGSN
range:
0..1023 (each field)
default:
<NULL>
has its own NSE object within the BSC.
FRS-No.: 89795, 89900
The NRI values can be indicated as several ranges. 20 ranges for
SF-No.:
10503, 10507
each relation are possible.
Introduced in BR9.0
NRIRELNSE attributes are linking NSE objects within the BSC and
NRI identifiers of CN node, allowing BSC to route messages to

103 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

different SGSNs.
NRI values described within this object are related to PS domain. In
BR10.0 there is a feature called Flexible A, which is based on NRI
values for CS domain (identification of MSCs).CS and PS
identification will be handled separately. Please refer to NRIRELMSC
attribute of AFLEXPOOL.
TLLIBITMASK=10,
object:
SGSNPOOL
range:
1..10
step size:
1
default:
10
FRS-No.: 89795, 89900
SF-No.:
10503, 10507
Introduced in BR9.0

TLLI Bit Mask, this parameter defines the number of bits used by
SGSN to represent NRI (Network Resource Identifier) values.
Number of bits required for SGSN identification is dependent on
number of SGSNs belonging to the SGSN Pool and on the number of
these pools.
NRI identifier is included in Local or Foreign TLLI. Both these
identifiers are built based on the P-TMSI which contains bits
responsible for NRI coding.
P-TMSI is assigned to the MS after GPRS Attach procedure (or after
combined IMSI & GPRS Attach procedure).
One should be aware, that bits used for NRI representation are
reducing the TMSI capacity.
The length of the NRI shall be the same in one Pool Area, i.e.
TLLIBITMASK shall also be the same in all these BSCs, in order to
correctly decode the NRI value. The same apply in cased of
overlapping Pool Areas.

WEIRELSGSN09 =<NULL>, Weight related SGSN 09, these attributes allow to define
object:
SGSNPOOL
SGSN<n> (n = 09) related weights which are meaningful for
range:
1..100, NULL
enhanced load sharing methods (i.e. when LSHRMTD is set to either
default:
NULL
WEIGHT_PERCENTAGE or WEIGHT_ABSOLUTE, otherwise
Introduced in BR10.0
WEIRELSGSN<n> must be set to NULL). The setting of
WEIRELSGSN<n> is taken into account to evaluate percentage or
absolute number of attempts to be routed to the n-th SGSN (in the
relevant formulae the attribute is represented by the factor i, please
refer to LSHRMTD attribute above).
Note, that if LSHRMTD = WEIGHT_ABSOLUTE, then the sum of the
WEIRELSGSN attributes within the SGSN pool cannot exceed 100.

104 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Creating the local NSE Virtual Link IP of an NS connection:


< This command creates the local (i.e. the BSC's) NSE Virtual Link IP.
- The NSEVLIP object replaces NSVLIP (introduced by HS Gb
feature).
- NSEVLIP represents the local IP endpoint of a NS connection.
- Up to 16 NSEVLIPs per NSE can be created.
- The pcuPort is a reference to the IP address (NSE: PORT) >
CREATE NSEVLIP:
NAME=nse:0/nsevlip:0,

Object path name.

LOCIPEP=0-5000,

Local IP Endpoint, this parameter defines the local IP endpoint.

object:
format:
range:

NSEVLIP
<pcuPort>-<udpPort>
pcuPort: 0..1
udpPort: 1024 ... 65535
FRS-No.: 89795, 89900
SF-No.: 10503, 10507
Introduced in BR9.0

WEID=10,

Weight Data, this parameter defines the weight related to local IP


endpoint for data.

object:
NSEVLIP
range:
0..255
default:
10
FRS-No.: 89795, 89900
SF-No.:
10503, 10507
Introduced in BR9.0

WEIS=10,

Weight Signaling, this parameter defines the weight related to local


IP endpoint for signaling.

object:
NSEVLIP
range:
0..255
default:
10
FRS-No.: 89795, 89900
SF-No.:
10503, 10507
Introduced in BR9.0

105 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Creating the remote NSE Virtual Link IP:


< This command creates the remote NSE Virtual Link IP.
- RNSEVLIP object replaces RNSVLIP (introduced by HS Gb
feature).
- RNSEVLIP is required only in case of static configuration.
- RNSEVLIP represents the remote IP endpoint of a NS connection.
- Max. Number of instances: 16 per NSE. >
CREATE RNSEVLIP:
NAME=nse:0/rnsevlip:0,

Object path name.

NSCONN=ALL,

Network Service Connection, this parameter defines the allowed


connections to local IP endpoints.

object:
range:

RNSEVLIP
choice
{List NSCON0 NSCON15 |
ALL}
FRS-No.: 89795, 89900
SF-No.: 10503, 10507
Introduced in BR9.0

106 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

RMTIPEP=0-5000,

Remote IP Endpoint, this parameter defines the remote IP endpoint.

object:
format:
range:

RNSEVLIP
<ipAdress>-<udpPort>
ipAddress: string 7...15 chars
udpPort: 1024 ... 65535
FRS-No.: 89795, 89900
SF-No.: 10503, 10507
Introduced in BR9.0

WEID=10,

Weight Data, this parameter defines the weight related to local IP


endpoint for data.

object:
RNSEVLIP
range:
0..255
default:
10
FRS-No.: 89795, 89900
SF-No.:
10503, 10507
Introduced in BR9.0

WEIS=10,

Weight Signaling, this parameter defines the weight related to local


IP endpoint for signaling.

object:
RNSEVLIP
range:
0..255
default:
10
FRS-No.: 89795, 89900
SF-No.:
10503, 10507
Introduced in BR9.0

107 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 (in case of the BSC1), 0..669 (in
case of the eBSC).

BAF=2,

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

object:
range:
default:

PCMB
0..255
0

BER=E10_3,
object:
range:
default:

PCMB
E10_3, E10_4, E10_5
E10_3

CRC=TRUE,
object:
range:
default:

PCMB
TRUE, FALSE
FALSE

DEV=0-DEV1-RDNON,
object:

PCMB

format:

<ethIdentifier><deviceNumber><redundancy>

range:

ethIdentifier: 0..3
deviceNumber: DEV1;
DEV2; DEV3; DEV4;
redundancy: RDNON;
RDNOFF
NULL

default:

Bit error rate, defines the bit-error-rate threshold that must be


exceeded in order to raise a PCM alarm.

CRC enabled, determines whether the cyclic redundancy check


systems CRC4 (for PCM30 lines) respectively CRC6 (for PCM24
links) is enabled.

CES device identity, this attribute is only relevant for the eBSC and
defines the LIPS number (by reference to the associated ETH FMO)
and the CES device number which emulates the PCMB line.
Note that a single PCMB line can be either connected physically to
LIET or aggregated in LISO or emulated by LIPS therefore PCMM,
VC and DEV attributes are mutually exclusive and 1 out of them must
be in use while the remaining 2 must be set to NULL (e.g. when the
PCMB is realized by means LIET then VC and DEV shall be set to
NULL).

Introduced in BR10.0

108 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

L1CTS=31-3,
object:
range:

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

BSC

QTLP
port
A
QTLP
port
B

LI
port
1

LI
BTSE port
2
0
LI
port
2

LI
port
1

LI
BTSE port
2
1

LI
BTSE port
1
n

= receive direction traffic & signalling


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

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.
LOWBER=0,
object:
range:
default:

109 / 703

Low bit error rate.

PCMB
E10_3, E10_4, E10_5, E10_6,
E10_7, E10_8, E10_9,
E10_3

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

LREDUNEQ=SIMPLEXA,
object:
range:
default:

PCMB
SIMPLEXA, SIMPLEXB
DUPLEX
SIMPLEXA

CODE=HDB3,
object:
range:
default:

PCMB
HDB3, AMI
HDB3

NUA=FALSE,
object:
range:
default:

PCMB
TRUE, FALSE
FALSE

PCML=0-0,
object:
format:
range:

PCMB
<licd-no.>-<port-no.>
licd-no. 0..9
port-no. 0..3 (QTLP)
port-no. 0..5 (STLP)

PCMM=0-0-TRUNKA,
object:
format:

PCMB
<liet-no.>-<circuit-no.>
-<trunk>
range:
liet-no. 0..8
circuit-no. 0..15
trunk-no. TRUNKA,
TRUNKB
Introduced in BR9.0

REMAL=CCITT,
object:
range:
default:

object:
range:

PCMB
sdh-no. 0..6
intf-no. 0..1
vc-no. 0..83
rdn. RDNON, RDNOFF
Introduced in BR9.0

WMOD=DOUBLE_TRUNK;

110 / 703

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.
'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).
PCM link, this parameter indentifies the physical LICD board and port
the PCMB is connected to.
Note: Parameter related only to the BSC1 (for the eBSC either PCMM
or VC or DEV are in use depending on the way the connectivity is
realized).
PCM line module identity, this attribute is only relevant for the eBSC
and defines the LIET number, the circuit number and the trunk which
the PCMB line is connected to..
Please see also parameters VC and DEV!

Remote alarm.

PCMB
CCITT
BELLCORE
CCITT

VC=0-0-0-RDNOFF,

object:
range:

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

PCMB
SINGLE_TRUNK,

Virtual Container identity, this attribute is only relevant for the eBSC
and defines the LISO number (by reference to the associated SDH
FMO), the Baby Board number (by reference to the associated INTF
FMO) and the Virtual Container which carries the PCMB line.
Note that:
- A single PCMB line can be either connected to LIET or aggregated
in LISO therefore PCMM and VC attributes are mutually exclusive
(when e.g. the PCMB is realized by means LIET then VC shall be
set to NULL and vice versa);
- When PCMTYP = PCM30, then range of vc-no. is reduced up to
0..62;
- Redundancy concept was introduced for PCMB lines carried over
optical lines: it is possible to carry either one copy (RDNOFF) or
two copies (RDNON) of the same PCMB line. If the latter, VC can
be only defined with an even vc-no. and this implies that two
consecutive virtual containers are occupied by the same PCMB
line.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
default:

DOUBLE_TRUNK
DOUBLE_TRUNK

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

111 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 (in case of
the BSC1) and 0..124 (in case of the eBSC).

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

object:
range:
default:

PCMS
0..255
0

BER=E10_3,
object:
range:
default:

PCMS
E10_3, E10_4, E10_5
E10_3

CODE=HDB3,
object:
range:
default:

PCMS
HDB3, AMI
HDB3

CRC=TRUE,
object:
range:
default:

PCMS
TRUE, FALSE
FALSE

DEV=0-DEV1-RDNON,
object:

PCMS

format:

<ethIdentifier><deviceNumber><redundancy>

range:

ethIdentifier: 0..3
deviceNumber: DEV1;
DEV2; DEV3; DEV4;
redundancy: RDNON;
RDNOFF
NULL

default:

Bit error rate, defines the bit-error-rate threshold that must be


exceeded in order to raise a PCM alarm.

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 enabled, determines whether the cyclic redundancy check
systems CRC4 (for PCM30 lines) respectively CRC6 (for PCM24
links) is enabled.

CES device identity, this attribute is only relevant for the eBSC and
defines the LIPS number (by reference to the associated ETH FMO)
and the CES device number which emulates the PCMS line.
Note that a single PCMS line can be either connected physically to
LIET or aggregated in LISO or emulated by LIPS therefore PCMM,
VC and DEV attributes are mutually exclusive and 1 out of them must
be in use while the remaining 2 must be set to NULL (e.g. when the
PCMS is realized by means LIET then VC and DEV shall be set to
NULL).

Introduced in BR10.0

L1CTS=31-3,
object:
format:

default:

PCMS
timeslot: 0..31 (for PCM30)
timeslot: 0..24 (for PCM24)
subslot: 0..3
NULL

Introduced in BR10.0

LREDUNEQ=SIMPLEXA,
object:

112 / 703

PCMS

Layer 1 control timeslot, defines the Asub timeslot to be used for


layer 1 supervision of specific Asub line configurations (e.g. '31-3'
means: layer 1 supervision in timeslot 31, subslot 3).
Layer 1 supervision is used on Asub in case of the eTRAU in order to
control a proper operation of those PCMS lines connecting the
eTRAU where the LAPD channels are not configured. Only single
(redundant) LPDLS running at 64 kbit/s is created in one PCMS line
between the (e)BSC and the eTRAU (and this channel is used for all
O&M tasks related to the eTRAU including SW handling), while for the
remaining PCMS lines (towards the same eTRAU) the L1CTS based
mechanism to detect a possible PCM line failure is adopted. L1CTS
carrying a predefined bit pattern is looped back to the BSC where the
pattern shall be recognized and confirmed. Otherwise, outage of the
E1/T1 line is reported.
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-

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
range:
default:

SIMPLEXA, SIMPLEXB
DUPLEX
SIMPLEXA

LOWBER=0,
object:
range:
default:

PCMS
TRUE, FALSE
FALSE

PCML=1-1,
object:
format:
range:

Low bit error rate.

PCMS
E10_3, E10_4, E10_5, E10_6,
E10_7, E10_8, E10_9,
E10_3

NUA=FALSE,
object:
range:
default:

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.

PCMS
<licd-no.>-<port-no.>
licd-no. 0..9
port-no. 0..3 (QTLP)
port-no. 0..5 (STLP)

PCMM=1-0-TRUNKA,
object:
format:

PCMS
<liet-no.>-<circuit-no.>
-<trunk>
range:
liet-no. 2..12
circuit-no. 0..15
trunk-no. TRUNKA,
TRUNKB
Introduced in BR9.0

'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).
PCM link, this parameter indentifies the physical LICD board and port
the PCMS is connected to.
Note: Parameter related only to the BSC1 (for the eBSC either PCMM
or VC or DEV are in use depending on the way the connectivity is
realized).
PCM line module identity, this attribute is only relevant for the eBSC
and defines the LIET number, the circuit number and the trunk which
the PCMS line is connected to..
Please see also parameters VC and DEV!

Range modified in BR10.0

REMAL=CCITT,
object:
range:
default:

PCMS
CCITT, BELLCORE
CCITT

UFORSYNC=<NULL>,
object:
range:
default:

PCMS
TRUE, FALSE, NULL
<NULL>

Introduced in BR10.0

VC=0-0-0-RDNOFF,
object:
range:

PCMS
sdh-no. 0..3
intf-no. 0..1
vc-no. 0..83
rdn. RDNON, RDNOFF
Introduced in BR9.0
Range modified in BR10.0

113 / 703

Remote alarm.

Used for synchronization. This attribute allows to define whether


the PCMS can be candidate for extraction of synchronization signal or
not if the PCMS line is handled by LIPS, i.e. the attribute is only
relevant when Pseudo-Wire emulation (PWE) is used for the PCMS
line.
Due to architecture of CES devices it is necessary to limit the amount
of PCMS lines that can be used for clock extraction up to 8. Therefore
up to 8 PCMS lines connected to the same DEV can have
UFORSYNC set to TRUE, the remaining ones must have the attribute
set to FALSE. If PCMS is not handled by LIPS then the attribute must
be set to NULL.
Virtual Container identity, this attribute is only relevant for the eBSC
and defines the LISO number (by reference to the associated SDH
FMO), the Baby Board number (by reference to the associated INTF
FMO) and the Virtual Container which carries the PCMS line.
Note that:
- A single PCMS line can be either connected to LIET or aggregated
in LISO therefore PCMM and VC attributes are mutually exclusive
(when e.g. the PCMS is realized by means LIET then VC shall be

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

WMOD=DOUBLE_TRUNK;
object:
range:
default:

PCMS
SINGLE_TRUNK,
DOUBLE_TRUNK
DOUBLE_TRUNK

set to NULL and vice versa);


- When PCMTYP = PCM30, then range of vc-no. is reduced up to
0..62;
Redundancy concept was introduced for PCMS lines carried over
optical lines: it is possible to carry either one copy (RDNOFF) or two
copies (RDNON) of the same PCMS line. If the latter, VC can be only
defined with an even vc-no. and this implies that two consecutive
virtual containers are occupied by the same PCMS line.
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).
A
DOUBLE_TRUNK mode:

QTLP
port

PCMS 0
redundant
link

T
R
A
U

With SINGLE_TRUNK setting it is possible to connect one PCMS to


each physical QTLP port
SINGLE_TRUNK mode:

114 / 703

A
QTLP
port

Network Engineering GERAN

PCMS 0
PCMS 1

T
R
A
U

T
R
A
U

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Creating the TRAU:


CREATE TRAU:
NAME=TRAU:0,

Object path name.

Allocation criteria, this attribute replaces the parameter TRANMTX


ALLCRIT=
NOT_COMPATIBLE_WITH_C 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
ROSSCONNECT,
introduction of the feature 'pooling' (see SET BSC [BASICS],
parameter
ENPOOL) the previously rigid mapping of timeslots is
object:
TRAU
replaced by a semipermanent mapping (i.e. a mapping modifiable by
range:
NOT_COMPATIBLE_
WITH_CROSSCONNECT,
configuration commands) which depends on the types and number of
COMPATIBLE_WITH_
TCH pools created on the A-interface.
CROSSCONNECT
a) The value NOT_COMPATIBLE_WITH_CROSS_CONNECT value
default:
NOT_COMPATIBLE_
can be chosen when no cross-connectors between BSC and TRAU
WITH_CROSSCONNECT,
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.

115 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Basic TRAU-mapping 1: NOT_COMPATIBLE_WITH_CROSSCONNECT (no pools


created)

PCMT-0

31

..

PCMT-1

31

..

ts31

31

..

ts1

ts0

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

R
PCMT-2

ts2

PCMS-0

U
PCMT-3

31

30

29

28

27

..

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)

31

PCMT-0

..

0
PCMS-0

31

PCMT-1

..

R
31

PCMT-2

..

ts 31

3 2 1 0 ... 3 2 1 0 3 2 1 x

ts 2

ts 1

X
ts 0

U
31

PCMT-3

..

27

26

25

24

..

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

116 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ETFO=FALSE,
object:
range:
default:
Reference:

117 / 703

TRAU
TRUE, FALSE
FALSE
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 (alaw) 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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EXPSWV=
'02-04-01-02-06-00
_98-07-30',
object:

TRAU

LPCMSCON000=0,
object:
range:

TRAU
0..47 (for legacy TRAU)
0..99 (for eTRAU with
PCMTYP=PCM30)
0..124 (for eTRAU with
PCMTYP=PCM24)
default:
none, as parameter is
mandatory
Introduced in BR9.0

LPCMSCON001..124=<NULL
>,
object:
range:

TRAU
0..99 (for eTRAU with
PCMTYP=PCM30)
0..124 (for eTRAU with
PCMTYP=PCM24)
<NULL>
default:
<NULL>
Introduced in BR9.0

MSTRCND=<NULL>,
object:
range:
default:

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.

Local PCMS Connection 0, this parameter replaces the previously


used parameter PCMSN (PCMS number) and defines a PCMS
connection(s) that interconnect this TRAU with the BSC.
LPCMSCON000 represents
a) for legacy TRAU (TRAU1):
the TRAU's one and only PCM port for the PCMS connection towards
the BSC
b) for eTRAU:
the eTRAU's first PCM port used for the PCMS connection towards
the BSC (the remaining eTRAU ports (125 on the whole) for the
PCMS connection are defined using the parameters
LPCMSCON001...LPCMSCON124 (see below)).
The entered value defines the number of the PCMS instance that
represents the BSC's PCM connection towards this TRAU port (see
command CREATE PCMS).
Note: This parameter is mandatory as it must define at least the one
and only PCMS connection connected to a legacy TRAU.
Local PCMS Connection 1..124, these parameters are only used for
configurations featuring eTRAU (it must be set to <NULL> if a legacy
TRAU is used). The number implicitly included in the parameter
acronym (<nnn> in LPCMSCON<nnn>) indicates the PCM port
number of the eTRAU (125 ports are available on the whole) that is
used for a PCMS connection towards the BSC.
The entered value for each parameter defines the number of the
PCMS instance that represents the BSC's PCM connection towards
this TRAU port (see command CREATE PCMS).
Master Candidate, this attribute indicates which role BSC would wish
to play towards to TRAU.

TRAU
TRUE, FALSE, NULL
NULL

PCMSN

Parameter deleted in BR9.0 (replaced by parameters


LPCMSCON000..124).

SALUNAME='BSC1TRAU0',

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.

object:
range:

default:

TRAU
alphanumeric string
(11 characters)
in quotation marks
NOT_DEFINED

TEI=0,
object:
range:

118 / 703

TRAU
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
unit:
range:
default:

119 / 703

TRAU
10ms
10..10000
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

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

object:
range:

LPDLS
pcms-no. 0..19
timeslot-no. 1-31 (PCM30)
timeslot-no. 1-24 (PCM24)
subslot-no. 0..3

LAPDPOOL=0,
object:
range:

LPDLS
0..1

default:

(LAPD pool is assigned


by the BSC automatically)

120 / 703

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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 (in case of
the BSC1) and 0..499 (in case of the eBSC)..

AECST =DISABLED

Acustic Echo Control Activation Status, this attribute indicates the


Acoustic Echo Control (AEC) feature.

object:
range:
default:

PCMA
DISABLED, ENABLED
DISABLED

ALACOUNT=32,
object:
range:
default:

Alarm Counter, this parameter determines the threshold for errors


that lead to a PCM alarm.

PCMA
1 - 254
32

Introduced in RG20 (BR)

ALARMT1=200,
object:
range:
default:

PCMA
2 254 (step size 0,1 s)
200

Alarm Timing1, this parameter 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 error-free seconds.
Default value 200 corresponds to 20 seconds

Introduced in RG20 (BR)

ALARMT2=10,
object:
range:
default:

PCMA
2 254 (step size 0,1 s)
10

Alarm Timing2, this parameter determines the error-free time an


disturbed PCM line is put out of service, i.e. after seconds of line
alarm the line is disabled. Default value 10 corresponds to 1 second.

Introduced in RG20 (BR)

ALARMT3=1,
object:
range:
default:

PCMA
2 254 (step size 5min)
1

Alarm Timing3, this parameter determines timeframe for the


counting of PCM line errors. A PCM line is set in 'alarmed state' if
ALACOUNT line errors are detected within 5 minutes..

Introduced in RG20 (BR)

ALCST= disabled,

Automatic Level Control Status, this attribute enables/disables the


Automatic Level Control (ALC) feature.0

object:
PCMA
range: disabled, eddonly, eduonly, edudl
default:disabled

ALCTGTLEV=m19dBM0,
object:
PCMA
range:
iTU; m23dBM0; m22dBM0;
m21dBM0; m20dBM0; m19dBM0;
m18dBM0; m17dBM0; m16dBM0;
m15dBM0; m14dBM0; m13dBM0;
m12dBM0;m11dBM0;m10dBM0;
m09dBM0;
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.
Note: Parameter moved from TRAU object to PCMA object in BR 10.0

Introduced in BR10.0

APORTN =<default>,
object:
range:

121 / 703

APortNumber , this attribute specifies the port number.

PCMA
0 - 499

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
default:

NULL

BAF=0,
object:
range:
default:

PCMA
0..255
0

BER=E10_3,
object:
range:
default:

object:
PCMA
range:
DELAY_0_ms,
DELAY_10_ms, DELAY_20_ms
DELAY_30_ms, DELAY_40_ms
DELAY_50_ms, DELAY_60_ms
DELAY_70_ms, DELAY_80_ms
DELAY_90_ms, DELAY_100_ms
DELAY_110_ms, DELAY_120_ms
DELAY_130_ms, DELAY_140_ms
DELAY_150_ms, DELAY_160_ms
DELAY_170_ms, DELAY_180_ms
DELAY_190_ms, DELAY_200_ms
DELAY_210_ms, DELAY_220_ms
DELAY_230_ms, DELAY_240_ms
DELAY_250_ms, DELAY_260_ms
DELAY_270_ms, DELAY_280_ms
DELAY_290_ms, DELAY_300_ms
DELAY_310_ms, DELAY_320_ms
DELAY_330_ms, DELAY_340_ms
DELAY_350_ms, DELAY_360_ms
DELAY_370_ms, DELAY_380_ms
DELAY_390_ms, DELAY_400_ms
DELAY_410_ms, DELAY_420_ms
DELAY_430_ms, DELAY_440_ms
DELAY_450_ms, DELAY_460_ms
DELAY_470_ms, DELAY_480_ms
DELAY_490_ms, DELAY_500_ms
DELAY_510_ms, DELAY_520_ms
DELAY_530_ms, DELAY_540_ms
DELAY_550_ms, DELAY_560_ms
DELAY_570_ms, DELAY_580_ms
DELAY_590_ms, DELAY_600_ms
DELAY_610_ms, DELAY_620_ms
DELAY_630_ms, DELAY_640_ms
DELAY_650_ms, DELAY_660_ms
DELAY_670_ms, DELAY_680_ms
DELAY_690_ms, DELAY_700_ms
DELAY_710_ms, DELAY_720_ms
DELAY_730_ms, DELAY_740_ms
DELAY_750_ms,
AUTOMATIC_LINK_DETECTION
default: DELAY_160_ms

CODE=HDB3,

122 / 703

Bit error rate, defines the bit-error-rate threshold that must be


exceeded in order to raise a PCM alarm.

PCMA
E10_3, E10_4, E10_5
E10_3

BULKDCONF=
DELAY_160_ms,

object:
range:
default:

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

PCMA
HDB3, AMI
HDB3

Bulk Delay Configuration, this attribute is used for the default


configuration of terrestrial link. The Automatic LinkDetection
monitorizes 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).

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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

CRC=TRUE,
object:
range:
default:

PCMA
TRUE, FALSE
FALSE

DEFPOOLTYP=
NOT_DEFINED,
object:
PCMA
range:
POOL_NOTDEF; POOL_01;
POOL_02; POOL_03; POOL_04
;POOL_05; POOL_06; POOL_07;
POOL_08; POOL_09; POOL_10;
POOL_11; POOL_12; POOL_13;
POOL_15 ;POOL_16; POOL_17;
POOL_18; POOL_19; POOL_20;
POOL_21; POOL_22; POOL_23;
POOL_24; POOL_25; POOL_26;
POOL_27; POOL_28; POOL_29;
POOL_30; POOL_31; POOL_32;
POOL_33; POOL_34; POOL_35;
POOL_36; POOL_37; POOL_38;
POOL_39; POOL_40; POOL_41;
POOL_42; POOL_43; POOL_44;
POOL_45; POOL_46; POOL_47;
POOL_48; POOL_49; POOL_50;
default: NOT_DEFINED

CRC enabled, determines whether the cyclic redundancy check


systems CRC4 (for PCM30) respectively CRC6 (for PCM24) is
enabled.

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.

New pool types in BR7.0 and BR10.0!

123 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Table of A-interface pool types


Coding
0000 0001

Pool
Circuit pool number 1

0000 0010

Circuit pool number 2

0000 0011

Circuit pool number 3

0000 0100

Circuit pool number 4

0000 0101

Circuit pool number 5

0000 0110

Circuit pool number 6

0000 0111

Circuit pool number 7

0000 1000
0000 1001

Circuit pool number 8


Circuit pool number 9

0000 1010

Circuit pool number 10

0000 1011
0000 1100

Circuit pool number 11


Circuit pool number 12

0000 1101

Circuit pool number 13

0000 1110

Circuit pool number 14

0000 1111
0001 0000

Circuit pool number 15


Circuit pool number 16

0001 0001

Circuit pool number 17

0001 0010

Circuit pool number 18

0001 0011

Circuit pool number 19

0001 0100

Circuit pool number 20

124 / 703

Supported channels and speech coding algorithms


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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Coding
0001 0101

Pool
Circuit pool number 21

0001 0110

Circuit pool number 22

0001 0111

Circuit pool number 23

0001 1000

Circuit pool number 24

0001 1001

Circuit pool number 25

0001 1010

Circuit pool number 26

0001 1011

Circuit pool number 27

0001 1100

Circuit pool number 28

0001 1101

Circuit pool number 29

0001 1110

Circuit pool number 30

125 / 703

Supported channels and speech coding algorithms


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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
Coding
0001 1111

Pool
Circuit pool number 31

0010 0000

Circuit pool number 32

0010 0001

Circuit pool number 33

0010 0010

Circuit pool number 34

0010 0011

Circuit pool number 35

0010 0100

Circuit pool number 36

0010 0101

Circuit pool number 37

0010 0110

Circuit pool number 38

126 / 703

Supported channels and speech coding algorithms


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)
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)
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)
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)
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)
FR speech version 4
FR speech version 5
HR speech version 4
FR speech version 3
FR speech version 4
FR speech version 5
HR speech version 3
HR speech version 4
HR speech version 6
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Coding
0010 0111

Pool
Circuit pool number 39

0010 1000

Circuit pool number 40

0010 1001

Circuit pool number 41

0010 1010
0010 1011
0010 1100

Circuit pool number 42


Circuit pool number 43
Circuit pool number 44

0010 1101

Circuit pool number 45

0010 1110

Circuit pool number 46

0010 1111

Circuit pool number 47

0011 0000

Circuit pool number 48

127 / 703

Supported channels and speech coding algorithms


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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

DPCID=,
object:
range:
default:

PCMA
0..15 (cBSC), 0..31 (eBSC)
none

DPC identifier. This attribute defines the DPC of MSC type


controlling the HCIC value and associated PCMA speech/data time
slots.

Introduced in BR10.0

HCICN=0,
object:
range:

default:

PCMA
0..2047 (if CICFM=GSM)
0..2730
(if CICFM=NOTSTRUCT)
pcma-no.

INTCTMST=DISABLED,
object:
range:
default:

PCMA
TRUE, FALSE
TRUE

LOWBER=0,
object:
range:
default:

default:

128 / 703

PCM TRAU, parameter structure:


trau-no. - no. of the PCM link between TRAU and MSC

Circuit number, this attribute defines the circuit number.

PCMA
0..3

REMAL=CCITT,
object:
range:

Low bit error rate.

PCMA
trau-no.: 0..47 (BSC1)
0..124 (eBSC)
pcm-link-no.: 0..3

RELCIRCN =,
object:
range:
default:

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

PCMA
E10_3, E10_4, E10_5, E10_6,
E10_7, E10_8, E10_9,
E10_3

PCMT=0..0,
object:
range:

Noise Reduction Status, this attribute enables/disables the Noise


Reduction (NR) feature.

PCMA
-18 - -6
-12

NUA=FALSE,
object:
range:
default:

Noise Reduction Amount, this attribute indicates the total amount of


desired noise reduction (dB).

PCMA
-18 - -6
-12

NOIREDST=FALSE,
object:
range:
default:

Integrated Cellular Telephone Modem Status, this attribute


enables/disables the integrated CTM feature.

PCMA
ENABLED, DISABLED,
DISABLED

NOIREDA=FALSE,
object:
range:
default:

High part of the CIC. The CIC (circuit identification code) is a 16bitstring 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]).

Remote alarm.

PCMA
CCITT
BELLCORE
CCITT

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the uplink and downlink volumes for specific PCMA timeslots:
SET TSLA:
NAME=pcma:0/tsla:1,

Object path name.

POOLTYP=,

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.

object:
range:

TSLA
POOL_NOTDEF;
POOL_01; POOL_02;
POOL_03; POOL_04;
POOL_05; POOL_06;
POOL_07; POOL_08;
POOL_09; POOL_10;
POOL_11; POOL_12;
POOL_13; POOL_15;
POOL_16; POOL_17;
POOL_18; POOL_19;
POOL_20; POOL_21;
POOL_22; POOL_23;
POOL_24; POOL_25;
POOL_26; POOL_27;
POOL_28; POOL_29;
POOL_30; POOL_31;
POOL_32; POOL_33;
POOL_34; POOL_35;
POOL_36; POOL_37;
POOL_38; POOL_39;
POOL_40; POOL_41;
POOL_42; POOL_43;
POOL_44; POOL_45;
POOL_46; POOL_47;
POOL_48; POOL_49;
POOL_50;

default:
New pool types in BR7.0 and BR10.0!

THROUGH=31,
object:
range:

TSLA
1-31 (PCM30)
1-24 (PCM24)

VOLDL=12,
object:
step size:
range:

default:

default:

129 / 703

Volume downlink, determines the value for the timeslot volume in


the downlink (MSC -> MS) direction.

TSLA
1dB
0..24
12 = normal link level
0 = 12dB attenuation
24 = 12dB amplification
12

VOLUL=15;
object:
step size:
range:

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.

TSLA
1dB
0..24
12 = normal link level
0 = 12dB attenuation
24 = 12dB amplification
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 MSCs capability of bit-synchronous switching. >
CREATE PCMG:
NAME=PCMG:0,

Object path name. The range for the PCMG-no. is 0..31 (in case of
the BSC1) and 0..88 (in case of the eBSC).

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

object:
range:
default:

PCMG
0..255
0

BER=E10_3,
object:
range:
default:

PCMG
E10_3, E10_4, E10_5
E10_3

CRC=TRUE,
object:
range:
default:

PCMG
TRUE, FALSE
FALSE

CODE=HDB3,
object:
range:
default:

PCMG
HDB3, AMI
HDB3

LOWBER=0,
object:
range:
default:

130 / 703

CRC enabled, determines whether the cyclic redundancy check


systems CRC4 (for PCM30) respectively CRC6 (for PCM24) is
enabled.

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

PCMG
E10_3, E10_4, E10_5, E10_6,
E10_7, E10_8, E10_9,
E10_3

NUA=FALSE,
object:
range:
default:

Bit error rate, defines the bit-error-rate threshold that must be


exceeded in order to raise a PCM alarm.

PCMG
TRUE, FALSE
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).

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

PCML=0-0-TRUNKA,
object:
format:
range:

PCMG
<licd-no.>-<port-no.>
-<trunk>
licd-no. 0..9
port-no. 0..3 (QTLP)
0..5 (STLP)
trunk TRUNKA, TRUNKB

PCMM=2-0-TRUNKA,
object:
format:

PCMG
<liet-no.>-<circuit-no.>
-<trunk>
range:
liet-no. 2..12
circuit-no. 0..15
trunk-no. TRUNKA,
TRUNKB
Introduced in BR9.0

PCM link, this parameter indentifies the physical LICD board, port
and trunk (sub-port) the PCMG is connected to.
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.
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.
PCM line module identity, this attribute is only relevant for the eBSC
and defines the LIET number, the circuit number and the trunk which
the PCMG line is connected to. The attribute is only related for the
eBSC.

Range modified in BR 10.0

REMAL=CCITT;
object:
range:
default:

131 / 703

Remote alarm.

PCMG
CCITT
BELLCORE
CCITT

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

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

object:
range:
default:

FRL
ITU, ANSI, LMI
ITU

GLK=PCMG:0,
object:
range:

FRL
PCMA:0 - PCMA:191
PCMG:0 - PCMG:31
PCMH:0 - PCMH:15

GTS=1&2,
object:
range:

FRL
1-31
max. 31 values per FRL
linked with '&';
max. 64 timeslots per PCU
if PPXX is used,

N391=6,
object:
range:
default:

FRL
1-255
6

N392=3,
object:
range:
default:

132 / 703

FRL
1-255
3

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.
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 Asubchannels 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 bitsynchronized 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, 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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

N393=4,
object:
range:
default:

FRL
1-255
4

NSEID=PCU:0,

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.
NSE Identifier, this attribute defines the instance number of the NSE
object the FRL is connected to.

object:
FRL
format:
path name of the PCU
range for CBSC : PCU:0..PCU:11
range for EBSC : 0..10
Introduced in BR9.0

PCUID=PCU:0,
object:
format:
range:

FRL
path name of the PCU
PCU:0..PCU:11

T391=10,
object:
unit:
range:
default:

FRL
1s
1-60
10

TCONG=10,
object:
unit:
range:
default:

FRL
1s
1-30
10

TCONOFF=20;
object:
unit:
range:
default:

133 / 703

FRL
1s
0, 10, 20, 30
0 = no hysteresis time used
20

PCU Identifier, this attribute defines the instance number of the PCU
object the FRL is connected to.
Note: This parameter is only applicable for BSC HW platform BSC1.
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.
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.
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

Network Service Virtual Connection Identifier, this parameter


represents the common identification of the virtual connection
between SGSN and BSS.

object:
range:

NSVC
0..65535

NSVLI=0..110;
object:
range:

134 / 703

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the object entry for the AFLEXPOOL:


The AFLEXPOOL object is automatically created when FLEXAE attribute of BSC object is set to
TRUE; when FLEXAE attribute is set to FALSE the object is automatically deleted.

SET AFLEXPOOL :
NAME=AFLEXPOOL:0..0

Object path name.

LSHRMTD = STANDARD,

Load sharing method. The attribute allows to indicate a method to


choose default MSC which is responsible in the MSC pool for
handling of the incoming access requests that do not contain a valid
MSC identifier. In such case the system is not able to derive from
TMSI the NRI (Network Resource Identifier) that points the MSC
where the user is registered to and thus is supposed to be served. In
order to ensure fair Core Network sharing within the MSC pool, the
default MSC is set temporarily (for some time or for some amount of
incoming requests) rather than permanently based on MSC load
situation (that may vary during the time) and customer preference
using one of hereafter described methods:

object:
range:

default:

AFLEXPOOL
STANDARD,
WEIGHT_PERCENTAGE,
WEIGHT_ABSOLUTE
STANDARD

Introduced in BR10.0

- STANDARD
In the method the time of operation is divided into 20 sec intervals
during which every MSC in the pool acts successively as the default
one for some period of time. This time, called persistency time,
depends on MSC overload conditions as well as on the transmission
capacity available on A interface and is computed by means of the
following formula:

Tp i =

w i i
N

(w

20 sec

i )

i =0

where:
Tpi persistency time of i-th MSC in the pool
N number of MSCs in the pool
wi a weight reversely proportional to the i-th MSC overload level:
wi = 10 overloadLevel(MSCi); overloadLevel = 09
i a factor representing the transmission capacity available on
PCMA that is equal to the number of configured TSLA which can be
used for traffic, i.e. excluding signaling, NUCs, etc.
For example: when MSC pool comprises of 2 MSCs and they both are
in the same overload state and have the same number of resources
available on A interface then persistency times of both MSCs are also
the same and equal to 10 sec. It means that each MSC is default one
for the period of 10 sec unless any element of the formula above is
modified (which is the case due to e.g. a CN node failure or load
change, a PCMA failure or reconfiguration).
- WEIGHT_PERCENTAGE
In this method percentage of incoming attempts only matters and no
time interval is taken into account. Therefore, instead of time interval,
an attempts interval is set to 100 to convert the percentage into the
(integer) number of attempts to be handled by the default MSC.
Percentage (out of 100 attempts) of the incoming requests that are
routed to the i-th MSC is defined by means of the following formula:

135 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Pri =

w i i
N

(w

100

i )

i= 0

where:
Pri percentage of attempts to be routed to the i-th MSC in the pool
N number of MSCs in the pool
wi a weight reversely proportional to the i-th MSC overload level:
wi = 10 overloadLevel(MSCi); overloadLevel = 09
i a factor used to rank the available CN nodes: the weight of i-th
MSC is user defined (see WEIREL<n> attribute of AFLEXPOOL
object).
For example: when MSC pool comprises of 2 MSC and they both are
in the same overload state and have their weights set to 90% and
30% then the first MSC will take 75 attempts and the second one 25.
Please note that sum of weights of all individual CN nodes in the MSC
pool do not need to be equal 100.
- WEIGHT_ABSOLUTE
In this method the absolute number of incoming attempts to be routed
to the individual MSC can be defined rather than any percentage.
The number of attempts addressed to the i-th CN node is computed
by means of the following formula:

Nri = w i i

NRIRELMSC09 = <NULL>,
object:

AFLEXPOOL

format:

dpcIdentifier nriRelatedToMSC
dpcIdentifier: 0...15 (cBSC) or
031 (eBSC)
nriRelatedToMSC: 120
entries of 10 bits long
<NULL>

range:

default:

Introduced in BR10.0

RRIMSIPRSP =FALSE,
object:
range:
default:

AFLEXPOOL
TRUE, FALSE
FALSE

Introduced in BR10.0

RRTMSIPRSP=FALSE,
object:
range:
default:

AFLEXPOOL
TRUE, FALSE
FALSE

Introduced in BR10.0

136 / 703

where:
Nri number of attempts to be routed to the i-th MSC in the pool
wi a weight reversely proportional to the i-th MSC overload level:
wi = 10 overloadLevel(MSCi); overloadLevel = 09
i a factor used to rank the available CN nodes: the weight of i-th
MSC is user defined (see WEIREL<n> attribute below).
Note that for this method it Is recommended to keep the sum of
weights of all individual CN nodes in the MSC pool below 100 as in
this way it is assured that after a reasonable amount of call attempts
all MSCs are in use.
NRI related to MSC 09, these attributes allow to define the
relationship between MSC<n> (n = 09) and NRI (Network Resource
Identifier) values. The NRIRELMSC<n>is composed of two fields: the
first indicates the instance number of DPC (MSC) and the second
indicates its NRI values.
NRI is used to uniquely identify an MSC within the pool, it is included
by the MSC in TMSI identities of the users who are registered in the
CN node and has flexible length of up to 10 bits (see TMSIBITMSK
attribute below). Each MSC can have up to 20 NRIs defined and NRI
codes cannot be identical within the pool, i.e. particular NRI code may
be only assigned to 1 MSC in the pool. Hence, whenever an access
request contains a valid TMSI, the NRI explicitly indicates the MSC
which the request is to be routed to (without involvment of any load
sharing method).
Please also see NRIRELNSE attribute of SGSNPOOL.
Re-route IMSI paging response. The attribute allows to cope with
MSC failure during paging response with IMSI. In such case, if
RRIMSIPRSP flag is set to TRUE, the paging response is re-routed to
the default MSC instead of discarding the paging message.
Re-route TMSI paging response. The attribute allows to cope with
MSC failure during paging response with TMSI. In such case, if
RRTMSIPRSP flag is set to TRUE, the paging response is re-routed
to the default MSC instead of discarding the paging message.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

TMSIBITMSK =10,
object:
range:
default:

AFLEXPOOL
1..10
10

TMSI bit mask.This attribute defines the number of bits used by MSC
to represent NRI values in TMSI identity.

Introduced in BR10.0

WEIREL09 =<NULL>,
object:
range:
default:

AFLEXPOOL
1..100, NULL
NULL

Introduced in BR10.0

137 / 703

Weight related 09, these attributes allow to define MSC<n> (n =


09) related weights which are meaningful for enhanced load sharing
methods (i.e. when LSHRMTD is set to either
WEIGHT_PERCENTAGE or WEIGHT_ABSOLUTE, otherwise
WEIREL<n> must be set to NULL). The setting of WEIREL<n> is
taken into account to evaluate percentage or absolute number of
attempts to be routed to the n-th MSC (in the relevant formulae the
attribute is represented by the factor i, please refer to LSHRMTD
attribute above).
Note, that if LSHRMTD = WEIGHT_ABSOLUTE, then the sum of the
WEIREL attributes within the MSC pool cannot exceed 100.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

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

object:
BTSM
unit:
1%
range:
0..100
default:
40
Default modified in BR10.0

BTSM Abis traffic load [%] =

no. of Abis pool TCH in usage state busy*


no. of Abis pool TCH in state unlocked/enabled

100

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

138 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ABISHRACTTHR=60,
object:
unit:
range:
default:

BTSM
1%
0..100
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
BTSM Abis traffic load [%] =

no. of Abis pool TCH not available for CS allocation *


no. of configured Abis pool TCHs

100

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

139 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.
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:
no. of Abis pool TCH in usage state idle *
no. of TCH configured in the Abis pool**

100

<

100% - ABISHRACTTHR[%]

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
BTSM Abis traffic load [%] =

no. of Abis pool TCH in usage state busy*

100

no. of Abis pool TCH in state unlocked/enabled

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

140 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
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 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:
unit:
range:
default:

BTSM
1%
50..100
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:
BTSM Abis traffic load [%] =

no. of Abis pool TCH in usage state busy*

100
no. of Abis pool TCH in state unlocked/enabled

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

141 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

ABISTRFLTHR=70,
object:
unit:
range:
default:

BTSM
1%
0.. 85
70

BTSM Abis traffic load [%] =

no. of Abis TCH in usage state busy*

100

no. of Abis TCH in state unlocked/enabled


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.
APN=AP_0_1,
object:

BTSM

range:
APM_0;APD_1;APD_2;APD_3;APD_4;
APD_5;
default:
AP_0
Introduced in BR9.0

142 / 703

AP number, the attribute indicates the pair (active and spare) of AP


associated the BTSM.
This attribute is only relevant for the eBSC where call processing is
distributed among several Application Processors (AP). Depending on
traffic model and call processing capacity to be achieved by the eBSC
one or more AP is needed. The cells are permanently assigned to the
AP and it is recommended to spread them in such a way that all AP
will be equally loaded.
The AP instance number depends on the number of slot is the eBSC

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

rack where the active AP is installed.

143 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EINTSITSYN=FALSE,
object:
range:
default:

BTSM
TRUE, FALSE, <NULL>
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.
cellA

BTSM
cellC

cellB

Frame n

Frame n + 1

CellA

TS0

TS1

TS2

TS3

TS4

TS5

TS6

TS7

TS0

TS1

CellB

TS0

TS1

TS2

TS3

TS4

TS5

TS6

TS7

TS0

TS1

CellC

TS0

TS1

TS2

TS3

TS4

TS5

TS6

TS7

TS0

TS1

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

144 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.
frame X-1

frame X
TS0

frame X+1
TS7

BTSA
frame X+14

frame X+15
TS0

frame X+16
TS7

BTSB
frame X+4

frame X+5
TS0

frame X+6
TS7

BTSC

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

145 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

Encrypted Bits

TSC

Encrypted Bits

Desired
burst

Encrypted Bits

TSC

Encrypted Bits

Interferer
burst

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

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

146 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 desynchronization 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.
To change the setting of EINTSITSYN, the BTSM must be 'locked'.
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
The frame-synchronicity, that is induced among the BTSEs by ISS,
is, however, only eliminated if the BTSE has been restarted after

147 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EMT1=10,
object:
unit:
range:
default:

BTSM
1min
0..360
10

EMT2=0,
object:
unit:
range:

default:

BTSM
1min
0..360
0 = switch to 'zero carrier
configuration' disabled.
0

EXPSWV='01-01-08-00..0700_98-7-21',

148 / 703

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
100% correspond to the situation when ISS was disabled, because
- all cells of the affected BTSEs remain frame-synchronized and
- due to the fact that after the disabling of EINTSITSYN also the
FRANOFFS and BURNOFFS values are ignored, the BTSEs are
also frame-number-synchronized.
In other words, by just changing the setting from
EINTSITSYN=TRUE to EINTSITSYN=FALSE (accompanied either
by a LOCK/UNLOCK BTSM or an Abis alignment in case of
database reload), the network remains in frame-synchronized
mode until a restart of the involved BTSEs occurs.
Even if the sync source is changed back to 'Abis', the situation
should not change notably - the synchronicity might only be lost
due to slow clock drift.
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.
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)).
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.
Expected SW version, this parameter determines the SW version
which should be loaded and running in the BTSE from the BSC's point

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

object:

BTSM

FLAPDOVLTH=80-60-10,
object: BTSM
format: firstLevelUpperThreshold firstLevelLowerThreshold firstLevelReductionStep
unit:
1%
range: 10..100
default: firstLevelUpperThreshold: 80
firstLevelLowerThreshold: 60
firstLevelReductionStep: 10

149 / 703

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.
EXPSWV parameter is a 26 characters string having the following
format: (SS-VV-RR-PR-LL-CL_YY-MM-DD), where:
SS System, VV - Version, RR Release, PR-Point Release, LL Load Level, CL Consolidation Level, YY-Year, MM Month, DDDay
String SS, VV, RR, LL and CL have to match with the version of the
BTSE software load or of the TRAU software load (in dependence on
the command that uses it) stored in the directory of the BSC disk. In
case of BTSE software load note that:
VV = 01 for BS-20, BS-21E, BS-22, BS-60, BS-61E.
VV = 04 for BS-240, BS-241, BS-240SR, BS-241SR, BS-240XL, BS240XLSR, BS-240XS, BS-40, BS-41, BS-82.
Regarding RR sub-field, note that:
RR = 13, 14, 15 for BR6.0 release
RR > 16 for BR7.0 release
RR > 17 for BR8.0 release
RR > 18 for BR9.0 release
RR > 19 for BR10.0 release
Regarding PR sub-field, note that:
PR = 03 for TRAU
PR = 01 (BTSPlus), o5 (eMicro), o6 (BTS240XS)
Value 00 is referred to the BTSone.
First LAPD overload threshold, this parameter represents the first
load level thresholds of the BTSE Radio Signalling links (LPDLRs). It
consists of three 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; if the signalling traffic is below
firstLevelUpperThreshold and above firstLevelLowerThreshold the
amount of MEASUREMENT RESULT (MEASUREMENT REPORT)
messages is reduced stepwise.
- firstLevelLowerThreshold
If the signalling traffic drops below this threshold the BTSE resumes
sending MEASUREMENT RESULT (MEASUREMENT REPORT)
messages on the Abis in a stepwise manner.
- firstLevelReductionStep
This field defines the step with which the amount of MEASUREMENT
RESULT (MEASUREMENT REPORT) messages is reduced or
increased depending on whether the signalling traffic is above or
below firstLevelLowerThreshold; the firstLevelReductionStep is
evaluated every LAPDOVLT0 seconds.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 and LAPDOVLT0 (see command 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, 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
object: BTSM
format: thresholdAbisHV strategy and the stop/restore of PDCH upgrading due to Abis scarcity.
thresholdAbisVH It is composed of four fields.
thresholdIdleAbisSU The first field (thresholdIdleAbisHV) defines the percentage of idle
thresholdIdleAbisRU
unit:
1%
Abis subslots (related to the available Abis subslots) under which the
range: 0..100
vertical allocation strategy due to Abis scarcity is activated. If vertical
default: thresholdAbisHV: 10
allocation is activated, new TBFs are preferably multiplexed on
thresholdAbisVH: 20
already used PDCHs. This implies that the related Abis subslots are
thresholdIdleAbisSU: 0
also shared and results in saving Abis resources.
thresholdIdleAbisRU: 10
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

150 / 703

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
range: 1..60
default: 10

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 DLAPDOVL in command SET BSC
[BASICS]).

LAPDOVLT0=1,

LAPD overload timer 0, this parameter defines the time to pass


between two consecutive LAPD OVERLOAD checks (i.e. the period
of the LAPD overload check cycle). LAPD OVERLOAD check
consists in periodical evaluation of the LAPD signalling traffic
(determined by the amount of bytes which are transmitted over Abis
during LAPDOVLT0 seconds) and comparing this traffic against
FLAPDOVLTH thresholds. Based on usage of LAPD transmission
capacity the decision is made which amount (defined by
FLAPDOVLTH) of MEASUREMENT RESULT (MEASUREMENT
REPORT) messages has to be reduced for the next cycle.
Please see also parameter FLAPDOVLTH in command CREATE
BTSM.

object: BTSM
unit:
1s
range: 0.5 .. 10.0
default: 1
Introduced in BR9.0

151 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

LPDLMSAT=FALSE,
object:
range:
default:

BTSM
TRUE, FALSE
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 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

152 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
unit:
range:
default:

BTSM
1s
3-300
30

recommended value: 17

153 / 703

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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_000PORT_0,
object:
format:

BTSM
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:
format:

BTSM
pcmbNumber1 portNumber1
value format: pcmbNumber1:
PCMB_nnn
portNumber1:
PORT_m
default:
<NULL>

PCMCON2..7=<NULL>,
object:
format:

BTSM
pcmbNumberX portNumberX
(X=2..7)
value format: pcmbNumberX:
PCMB_nnn
portNumberX:
PORT_m

154 / 703

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..7, these attribute indicate the second to seventh
auxiliary PCM connection for the given BTSM, i.e. they indicate to
which BTSM port they are 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).

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
default:

155 / 703

<NULL>

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

SALUNAME='BSC1BTSE0',
object:
range:

BTSM
alphanumeric string
(11 characters)
in quotation marks
NOT_DEFINED

default:

SHLAPDIT=15,
object:
unit:
range:
default:

BTSM
1s
3-20
15

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

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:
BTSM
secondLevelUpperThreshold - secondLevelUpperThreshold
secondLevelLowerThreshold
if the signalling traffic overcomes this threshold the BTSE starts the
1%
periodic sending of LAPD OVERLOAD messages.
10..100
secondLevelUpperThreshold: 90 - secondLevelLowerThreshold
secondLevelLowerThreshold: 80 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.

SLAPDOVLTH=90-80,
object:
format:
unit:
range:
default:

156 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

TEI=0,
object:
range:

157 / 703

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

158 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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).
MA
Random Hopping (1, 2, 10, 7, . . . )

BCCH

TRX0

MAIO = 0

TRX1

MAIO = 6

TRX2

MAIO = 12

TRX3

Time (TDMA frame)


BCCH

TRX0

BCCH

TRX0

MAIO = 4

TRX1

MAIO = 2

TRX1

MAIO = 10

TRX2

MAIO = 8

TRX2

MAIO = 16

TRX3

MAIO = 14

TRX3

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

159 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

uses and reuses all MAIOs in all sectors of the site

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 cochannel 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 - this is
always the case, unless ISS (see parameter EINTSITSYN in
command CREATE BTSM) is applied and enabled.
DMA service layers may only be included in the SLLs for speech
service. Thus, service layers that are not exclusively dedicated to
speech services (e.g. service layers that are also included in the
SLLs for data calls and (E)GPRS) can only use Static MAIO
allocation (SMA). Please see command SET BTS [SERVICE] for
further details.
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).

160 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

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

object:
range:
Reference:

161 / 703

CBTS
0..1023 each field
GSM 04.08
GSM 05.02
GSM 12.20

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

SYSID=GSM850:
SYSID=GSM850PCS:
SYSID=GSM850DCS:
SYSID=GSMR:
SYSID=PCS1900:
CCALLF02..CCALLF63
object:
range:

CBTS
0..1023 each field

ENDMA=FALSE,
object:
range:
default:

162 / 703

CBTS
TRUE, FALSE
FALSE

128..251
128..251, 512..885
128..251, 512..810
955..974
512..810

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 BTSMspecifically 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 BTSMspecifically 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/CFH
SY:0,

Object path name.

CMOBALLOC=CCALLF01&
CCALLF02&...,

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.

object:
range:
Reference:

163 / 703

CFHSY
0..1023 (each field)
GSM 05.02
GSM 04.08

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

HSN=10,
object:
range:
Reference:

CFHSY
0..63
3GPP 45.008
GSM 04.08

SUBBAND=10,
object:
range:
Reference:

164 / 703

Common Hopping sequence number, determines the hopping


sequence number commonly used in the site that is configured for
DMA.

Subordinate band, this parameter determines the frequency band to


which the CFHSY is applicable.

CFHSY
GSM850, PCS1900,
DCS1800, BB900, EB900
3GPP 45.008
GSM 04.08

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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,

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

object:
range:

165 / 703

LPDLM
pcmb-no. 0..669
timeslot-no. 1-31 (PCM30)
timeslot-no. 1-24 (PCM24)
subslot-no. 0..3

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
range:
default:

166 / 703

LPDLM
0..1
(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).

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

CS-2

CS-3

CS-4

MCS-1

MCS-2

MCS-3

MCS-4

MCS-5

MCS-6

MCS-7

MCS-8

MCS-9

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

167 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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
Service
type

1 x 16 kbit/s
- FR CS speech
- EFR CS speech
- AMR FR CS
speech
- CS data
- GPRS (CS1 and
CS2 only)

1/2 x 16 kbit/s
(= 8 kbit/s)
- HR CS speech
- AMR HR CS
speech

n x 16 kbit/s
(n = 2..5)
- 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.
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

168 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

169 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

BTSM:0
BTS:0

C
O
R
E

BTS:1

Abis pool BTSM:0


BTSM:0 subpool 1 L*
BTSM:0 subpool 2 L*

BTS:2

Abis pool BTSM:1


BTSM:1 subpool 1 L*

B
S
C

BTSM:1
Abis pool BTSM:1
BTS:0
BTS:1

C
O
R
E

BTSM:1 subpool 1 L*

BTS:2

L* = associated LAPD
(does not have to be directly
adjacent to the pool TCHs, it
must only be on the same
PCMB)

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

170 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

Object path name.

ASSLAPD=
BTSM:0/LPDLM:0,

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

object:
format:

171 / 703

SUBTSLB
object instance path name of
the associated LPDLM,
BTSM:n/LPDLM:m

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

 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 BTSMno. was changed to 0..199, the BTS-no. was changed to 0..23.

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

object:
range:

default:

BTS [BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, RATE_06,
RATE_07, RATE_08
RATE_01

good radio conditions


poor radio conditions

Channel Coding
Channel Coding

Speech Coding
Speech Coding

Active CODEC Set (ACS)


Both the speech versions AMR FR and AMR HR consist of a socalled '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

172 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

173 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 (ICM) 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 (Initial Codec Mode ICM), 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.
How is the initial AMR CODEC determined after handover?
When a handover (internal intercell or intracell) is to be performed,
the BSC by default requests the ICM in the CHANNEL ACTIVATION

174 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

message for the target channel and adds the ICM into the 'Multirate
configuration' IE that is included in the ASSIGNMENT COMMAND or
HANDOVER COMMAND. This is necessary as the BSC does not
know which codec was currently used/negotiated in-band when the
handover condition was detected. To ensure that also the TRAU uses
the ICM as the first speech codec when the call is switched to the
target channel, the originating BTS, on detection of a handover
procedure, sends a CMR to the TRAU that requests the deployment
of the ICM (As the originating BTS does not know the ICM of the
target cell, it requests its own ICM, assuming that the ICM of
originating and the target cell are the same. For this reason, it is
urgently required to configure the same ICM and ACS settings in the
entire network!). Typically the ICM is a very defensive one and
therefore does not cause problems in case of handovers under poor
radio conditions. Thus, when the MS accesses the target channel and
receives the first speech frame, it is with very good chances that this
speech frame is coded with the ICM. As on the Um the BTS sends
CMI (to indicate the used DL codec) and CMR (to request the current
UL codec) in an alternating manner, it can either happen that the first
DL speech frame contains a CMI (in this case the MS can derive the
decoding mode from the CMI immediately) or the first DL speech
frame contains a CMR - in this case it is important that the DL speech
frame uses the codec as expected by the MS (otherwise the wrong
decoding causes noises in the speech path).
Concluding: if the same ICM and ACS is configured in the entire
network, the above described mechanisms make sure that each
handovered call starts with the ICM on the target channel and thus
speech problems or noises are avoided.
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
LOWTQUAMRDL (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

175 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

default:

BTS [BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, RATE_06,
RATE_07, RATE_08,
<NULL>
RATE_03

AMRFRC3= RATE_06,
object:
range:

default:

176 / 703

BTS [BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, RATE_06,
RATE_07, RATE_08
<NULL>
RATE_06

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

case of active frequency hopping.


For further details please refer to the descriptions provided for the
parameter AMRFRC1.
AMRFRC4= RATE_08,
object:
range:

default:

BTS [BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, RATE_06,
RATE_07, RATE_08
<NULL>
RATE_08

AMRFRIC=
START_MODE_FR,
object:
range:

default:

BTS [BASICS]
START_MODE_FR
CODEC_MODE_01
CODEC_MODE_02
CODEC_MODE_03
CODEC_MODE_04
START_MODE_FR

AMRFRTH12=7-4,
object:
format:
unit:
range:
default:

177 / 703

BTS [BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 7 [3.5 dB]
hysteresis: 4 [2.0 dB]

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

thresholdAMRFRTH34 + hysteresisAMRFRTH34
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).
AMRFRTH23=12-4,
object:
format:
unit:
range:
default:

BTS [BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 12 [6.0 dB]
hysteresis: 4 [2.0 dB]

AMRFRTH34=23-4,
object:
format:
unit:
range:
default:

178 / 703

BTS [BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 23 [11.5 dB]
hysteresis: 4 [2.0 dB]

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
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
thresholdAMRFRTH34 + hysteresisAMRFRTH34
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 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
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
thresholdAMRFRTH34 + hysteresisAMRFRTH34
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

- Please be aware that this parameter only refers to the AMR


downlink CODEC mode adaptation. The corresponding uplink
thresholds are not administrable (see parameter AMRLKAT).
AMRHRC1= RATE_01,
object:
range:

default:

BTS [BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05
RATE_01

AMRHRC2= RATE_02,
object:
range:

default:

BTS [BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04
RATE_05, <NULL>
RATE_02

AMRHRC3= RATE_03,
object:
range:

179 / 703

BTS [BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04
RATE_05, <NULL>default:
RATE_03

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

AMRHRC4= RATE_04,
object:
range:

BTS [BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04
RATE_05, <NULL>default:
RATE_04

AMRHRIC=
START_MODE_HR,
object:
range:

default:

BTS [BASICS]
START_MODE_HR
CODEC_MODE_01
CODEC_MODE_02
CODEC_MODE_03
CODEC_MODE_04
START_MODE_HR

AMRHRTH12=19-4,
object:
format:
unit:
range:
default:

180 / 703

BTS [BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 19 [9.5 dB]
hysteresis: 4 [2.0 dB]

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.
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.
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
thresholdAMRHRTH34 + hysteresisAMRHRTH34

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
format:
unit:
range:
default:

BTS [BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 24 [12.0 dB]
hysteresis: 4 [2.0 dB]

AMR Half Rate Thresholds 23, this parameter defines the C/I
threshold and the associated hysteresis for the AMR downlink
CODEC mode adaptation transition from AMRHRC2 to AMRHRC3
and vice versa. The entered values are applied as follows:
a) The upward transition from AMRHRC2 to AMRHRC3 is initiated
when
C/I > thresholdAMRHRTH23 + hysteresisAMRHRTH23
b) The downward transition from AMRHRC3 to AMRHRC2 is initiated
when
C/I < thresholdAMRHRTH23
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
thresholdAMRHRTH34 + hysteresisAMRHRTH34
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 Half Rate Thresholds 34, this parameter defines the C/I
threshold and the associated hysteresis for the AMR downlink
BTS [BASICS]
CODEC mode adaptation transition from AMRHRC3 to AMRHRC4
threshold-hysteresis
and vice versa. The entered values are applied as follows:
threshold: 0.5dB
a) The upward transition from AMRHRC3 to AMRHRC4 is initiated
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
when
hysteresis: 0..15 [0..7.5dB]
C/I > thresholdAMRHRTH34 + hysteresisAMRHRTH34
threshold: 30 [15.0 dB] (BTS+)
<NULL>
(BTS1) b) The downward transition from AMRHRC4 to AMRHRC3 is initiated
hysteresis: 4 [2.0 dB]
when
C/I < thresholdAMRHRTH34
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
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

AMRHRTH34=30-4,
object:
format:
unit:
range:
default:

181 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

thresholds are not administrable (see parameter AMRLKAT).


AMRLKAT=100,
object:
unit:
range:

default:

BTS [BASICS]
0,1dB
0..200,
where
0 = -10dB, 100 = 0dB,
200 = +10dB
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 [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.

182 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

AMRLKATWFS=100,
object:
unit:
range:

default:

BTS [BASICS]
0,1dB
0..200,
where
0 = -10dB, 100 = 0dB,
200 = +10dB
100 [0dB]

Introduced in BR 10.0

AMR Link Adaption for WB AMR - this parameter controls the link
adaptation (LA) process in uplink of AMR-WB TCH/WFS codec
modes to favourite either more robust codec modes (higher values of
the parameter) or better sounding codec modes (lower values of the
parameter).
In contrary to the downlink direction the switching points and
hystereses in the LA process in uplink cannot be adjusted individualy
the distances between particular switching points and hystereses
are hard-coded. The only possibility is to shift all the switching points
on the C/I axis as shown in the examples
below:
aMRLinkAdaptationTchWfs = 0 dB

6.60 kbps

8.85 kbps

8.5 10.5

12.65 kbps

12.5

14.5

C/I [dB]

aMRLinkAdaptationTchWfs = 5 dB

6.60 kbps

8.85 kbps

13.5

15.5

17.5

12.65 kbps

19.5

C/I [dB]

In the first case better sounding codec modes are favourited


(activation at relatively small C/I of less robust codec modes). In the
second case more robust codec modes are favourited (keeping at
relatively high C/I of more robust codec modes).
AMR WB Full Rate GMSK Initial Codec, this parameter defines the
initial codec mode for the AMR-WB feature if activated (see the
parameter EAMRWB). The ACS for the AMR-WB feature is hardobject:
BTS [AMRPARAMETERS] coded and always consists of the three TCH/WFS codec modes: 6.60
range:
START_MODE_WFS;
kbps, 8.85 kbps and 12.65 kbps.
CODEC_MODE_01;
The START_MODE_WFS means the application of the GSM rule
CODEC_MODE_02;
(05.09 recommendadtion) which states that in case the ACS consists
CODEC_MODE_03;
of three codec modes the one with the lowest rate (6.60 kbps) should
default:
START_MODE_WFS
be the initial codec mode.
Introduced in BR 10.0
The parameter is applicable to the layers without frequency hopping.
The initial codec mode is allocated to the AMR-WB call at call setup.
Afterwards, it can be changed depending on the radion conditions by
the link adaptation algorithm.
The initial codec mode is on until the TFO negotaion is completed.
AMRWBFGIC=
START_MODE_WFS

AMRWBFGTH12=17-4,
object:
format:
unit:
range:
default:

183 / 703

BTS [AMRPARAMETERS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 17 [8.5 dB]

AMR WB Full Rate GMSK Threshold 12, this parameter defines the
lower threshold for switching from the AMR-WB TCH/WFS codec
mode 2 to 1 and the hysteresis value to get the higher threshold for
switching from the AMR-WB TCH/WFS codec mode 1 to 2 in the link
adaptation (LA) process in downlink. The parameter is a combination
of the threshold and hysteresis sub-fields. See also the
AMRWBFGTH23 parameter.
The following rules must be obeyed when setting the parameter:

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
hysteresis: 4 [2.0 dB]
Introduced in BR 10.0

AMRWBFGTH 12(threshold ) < AMRWBFGTH 23(threshold )


AMRWBFGTH 12(threshold ) + AMRWBFGTH 12(hysteresis) <

< AMRWBFGTH 23(threshold ) + AMRWBFGTH 23(hysteresis)

6.60 kbps

8.85 kbps

12.65 kbps
C/I [dB]

AMRWBFGTH12-Threshold

AMRWBFGTH23-Threshold

AMRWBFGTH12-Hysteresis

AMRWBFGTH23-Hysteresis

The parameter is applicable to the layers without frequency hopping.


See also the parameter FHAMRWBFGTH12.
The LA process can be executed locally when the TFO is not
established on the AMR-WB codec mode. If the TFO (the full end-toend AMR-WB connection) is successfully established, then the local
LA process is disabled, i.e. the selection of the currently used
TCH/WFS codec mode depends also on the radio conditions at the
distant radio interface:
- if radio conditions at both ends allow using different codec modes
the more robust codec mode is selected out of the codec modes used
locally as a common one,
- codec mode upgrading is possible if both radio links are good
enough,
- codec mode downgrading is necessary if at least one radio link is
not good enough
AMRWBFGTH23=25-4,
object:
format:
unit:
range:
default:

BTS [AMRPARAMETERS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 25 [12.5 dB]
hysteresis: 4 [2.0 dB]

Introduced in BR 10.0

AMR WB Full Rate GMSK Threshold 23, this parameter defines the
lower threshold for switching from the AMR-WB TCH/WFS codec
mode 3 to 2 and the hysteresis value to get the higher threshold for
switching from the AMR-WB TCH/WFS codec mode 2 to 3 in the link
adaptation (LA) process in downlink. The parameter is a combination
of the threshold and hysteresis sub-fields. See also the
AMRWBFGTH12 parameter.
The following rules must be obeyed when setting the parameter:

AMRWBFGTH 23(threshold ) > AMRWBFGTH 12(threshold )


AMRWBFGTH 23(threshold ) + AMRWBFGTH 23(hysteresis) >
< AMRWBFGTH 12(threshold ) + AMRWBFGTH 12(hysteresis)

6.60 kbps

8.85 kbps

12.65 kbps
C/I [dB]

AMRWBFGTH12-Threshold

AMRWBFGTH23-Threshold

AMRWBFGTH12-Hysteresis

AMRWBFGTH23-Hysteresis

The parameter is applicable to the layers without frequency hopping.


also the parameter FHAMRWBFGTH23.
The LA process can be executed locally when the TFO is not
established on the AMR-WB codec mode. If the TFO (the full end-toend AMR-WB connection) is successfully established, then the local

184 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

LA process is disabled, i.e. the selection of the currently used


TCH/WFS codec mode depends also on the radio conditions at the
distant radio interface:
- if radio conditions at both ends allow using different codec modes
the more robust codec mode is selected out of the codec modes used
locally as a common one,
- codec mode upgrading is possible if both radio links are good
enough,
- codec mode downgrading is necessary if at least one radio link is
not good enough
ANTHOPP = <NULL>
object:
range:

default:

BTS [BASICS]
ALL, SECOND, FOURTH,
SEQ_445, <NULL>
<NULL>
<NULL>

ARFACCHACMDF=
DISABLE(0),
object:
BTS [BASICS]
range:
TRUE, FALSE
default:
FALSE
FRS-No.: 92893
SF-No.:
10525
Introduced in BR9.0

BCCHFREQ=10,
object:
range:
Reference:

BTS [BASICS]
0..1023
GSM 04.08
GSM 05.08

BSIC=7-7,
object:
range:
Reference:

185 / 703

BTS [BASICS]
NCC: 0..7
BCC: 0..7
GSM 03.03
GSM 03.08
GSM 04.08
GSM 05.02

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).
Enable Apply R-FACCH on any command frames, this parameter
is related to the feature 'DL repeated FACCH' - it is relevant only if
parameter ERFACCHCMD (see below) was set for at least one
speech codec type (value different from DISABLE(0) ). If
ERFACCHCMD is set to TRUE, the R-FACCH functionality for those
MS that have not signaled their Repeated ACCH Capability as 1 (i.e.
R-ACCH_CAP1, those types of MS include legacy MS and new Rel6 MS that have signaled their Repeated ACCH Capability as 0) is
extended to any LAPDm command frame for the speech codecs
selected with parameter ERFACCHCMD.
For further details, please refer to parameter ERFACCHCMDF (see
below).
BCCH frequency, specifies the Um channel no.
(e.g. BCCHFREQ 10 = C10) of that carrier which contains the FCH,
SCH, BCCH and CCCH.

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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

BURNOFFS=0,
object:
BTS [BASICS]
range:
0..7, <NULL>
Default modified in BR10.0

CALLF01=60,
object:
range:
Reference:

BTS [BASICS]
0..1023 each field
GSM 04.08
GSM 05.02
GSM 12.20

CALLF02..CALLF63
object:

BTS [BASICS]

CBQ=0,
object:
range:
default:
Reference:

186 / 703

BTS [BASICS]
0= normal priority
1=low priority
0
3GPP 45.008
GSM 03.22

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).
Cell allocation frequency 1, this parameter defines the first nonBCCH 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.
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.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

considers the cell priority defined by CBQ for the selection of the cell.
CCALL=<NULL>,
object:
range:
default:

BTS [BASICS]
CCALLF<nn>, linked with '&'
<NULL>
<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.

187 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

CELLGLID='262'-'02'-10-101,
object:
range:

Reference:

BTS [BASICS]
MCC: '0..999'
MNC: '0..999' (PCS1900)
MNC: '0..99' (all others)
LAC: 0..65535
CI: 0..65535
GSM 03.03
GSM 04.08

CELLRESH=2,
object:
unit:
range:
default:
Reference:

BTS [BASICS]
2dB
0..7
2
3GPP 45.008
GSM 04.08
GSM 03.22
GSM 12.20

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.
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 = RLA_C - RXLEV_ACCESS_MIN
= <RXLEV average> - 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 nonserving 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 is only 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, as these
procedures always cause considerable signaling load in the BSS and
the core network (MSC etc.). 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.

188 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

CELLTYP=STDCELL,
object:
range:

default:

BTS [BASICS]
STDCELL
EXTCELL
DBSTDCELL
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
TRX:0
TRX:1

ts 4

ts 5

BCCH

ext

ts 1

SDCCH

ts 2

ext

ts 3

TCH

TCH

TCH

ext

TCH

ext

TCH

TCH

= near area

ts 6
TCH
TCH

ts 7
ext
TCH

= 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

189 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 CELLTYP=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

190 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 is supported both in the 900 MHz and in the
1800 MHz band, 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.

191 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

CONCELL=FALSE,
object:
range:
default:

BTS [BASICS]
TRUE, FALSE
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'.
COMPLETE area
INNER 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 CELLTYP, see above) there is a fixed
relation of concentric cell areas and particular TRXs.
Example configuration:
TRX:0
TRX:1
TRX:2

ts 0

ts 1

ts 2

ts 3

ts 4

ts 5

ts 6

ts 7

BCCH

SDCCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

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 HAND object (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. Typically, in dual band concentric cells, the coverage
differences between complete and inner area are not necessarily
determined by different PWRRED settings but by the differences in
the propagation characteristics of the used frequencies. 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.

192 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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
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 CELLTYP=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.
- For Concentric Cells a special variant of the power budget
calculation is applied for power budget handovers (see parameter
PBGTHO in command SET HAND [BASICS]) for calls that are served
by an inner area TRX. This different power budget calculation
considers the different output power figures of inner and complete
area TRX as well as the path loss difference between inner and
complete area in order to avoid undesired ping-pong handover
effects. For further details please see the section 'Inter-cell/Intersystem Handover due to better cell (power budget handover)' in the
appendix of this document.
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.

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'
object:
BTS [BASICS]
range:
0=C2 parameters not present (SYSTEM INFORMATION TYPE 3); 0=not present, 1=present.
1=C2 parameters present
The criterion C2 is an optional feature that can be enabled on a cell
default:
1
basis. It is an enhancement of the cell selection C1 (for C1 please see
Reference: 3GPP 45.008
parameter CELLRESH). C2, however, is useful for microcellGSM 03.22
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 5s. 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
CRESPARI=1,

193 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

CSCE=URBAN,
object:
range:

default:

BTS [BASICS]
URBAN, SUB_URBAN
RURAL_QUASI_OPEN,
RURAL_OPEN
URBAN

FRS:

88930

CUCONF=HOMOGENEOUS,
object:
range:

default:

BTS [BASICS]
CU_FLEXCU_BS82II,
CU_ECU_DCSPCS,
HOMOGENEOUS
HOMOGENEOUS

DEFUPRIO=3,
object:
units:
range:

BTS
0, 1, , 7

default:

FRS-No.: 98321
SF-No.:
Introduced in RG20 (BR)

194 / 703

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 reselection permanently, i.e. without any time limitation.
If CRESPARI is set to '0' the parameters CRESOFF, TEMPOFF,
PENTIME, CBQ have to be skipped.
Cell Scenario, this parameter defines the propagation environment
specific for the given cell. The value of the parameter is one of the
inputs for the Overheating algorithm, so its strongly recommended
not to use the default value, but set the proper one according to real
scenario.

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.

Default UTRAN Priority, absolute priority of the WCDMA


neighbouring cells
0 low priority, , 7 high priority
Value provides the relative priority of the WCDMA cells similarly to
priority of E-UTRAN adjacent cell (EUPRIO) and GSM cells
(GSMPRIO) taken into account in the cell reselection algorithm
It has to be different from GSM priority and LTE priority.
Priority based cell reselection algorithm (please refer to FRS 98321)
is always used in case of GSM-LTE cell reselection and for GSMWCDMA if:
- cell reselection to LTE is possible (legacy algorithm for cell
reselection to WCDMA based on cell ranking and priority

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

based cell reselection could not run simultaneously while


camped on GSM cell)or
- LTE neighbours cell are not defined but FACQ3G parameter
is set to TRUE.
DEFUQRXLEVMIN= MDB119, Default UTRAN QRXLev Min, minimum required RX level (CPICH
RSCP) for UTRAN cell taken into account in inter-RAT cell reselection
to 3G based on priorities. For details please refer to DEFUTH and
object:
BTS
units:
dBm
HPRIO.
range:
MDB119 MDB117 MDB115
Value MDB119 corresponds to 119dBm, MDB117 to 117dBm ..
MDB113 MDB111 MDB109
MDB057 to -57dBm.
MDB107 MDB105 MDB103
MDB101 MDB099 MDB097
MDB095 MDB093 MDB091
MDB089 MDB087 MDB085
MDB083 MDB081 MDB079
MDB077 MDB075 MDB073
MDB071 MDB069 MDB067
MDB065 MDB063 MDB061
MDB059 MDB057
default:

MDB119

FRS-No.: 98321
SF-No.:
Introduced in RG20 (BR)

DEFUTH=DB32,
object:
units:
range:

default:

BTS
dB
DB00 DB02 DB04 DB06
DB08 DB10 DB12 DB14
DB16 DB18 DB20 DB22
DB24 DB26 DB28 DB30
DB32 DB34 DB36 DB38
DB40 DB42 DB44 DB46
DB48 DB50 DB52 DB54
DB56 DB58 DB60 DB62
DB32

Default UTRAN threshold - reselection threshold towards UTRAN


used in priority based algorithm in case when 3G cell has higher
priority than 2G cell as well as if 3G cell has lower priority than 2G
cell. It substitutes both THRESH_XXX_high and THRESH_XXX_low
respectively.
- MS could reselect to 3G cell if following condition related to CPICH
RSCP of the 3G cell:
RSCP DEFUQRXLEVMIN> DEFUTH
is satisfied during THRESEL and assuming that 3G cell has the
highest priority among the potential target cells.

FRS-No.: 98321
SF-No.:
Introduced in RG20 (BR)

- If there are no cells with higher priority than the serving cell and
simultaneously C1 < THGSML, MS could reselect to low priority 3G
cell if:
CPICH RSCP DEFUQRXLEVMIN > DEFUTH during THRESEL
Note: For priority relationship please refer to GSMPRIO, DEFUPRIO,
EUPRIO
Downgrade strategy, this parameter defines the downgrade strategy
DGRSTRGY=
GPRS_FIRST_DOWNGRADE, for HSCSD and GPRS calls used during the resource reallocation
procedure for TCH requests for single-channel circuit switched calls.
object: BTS [BASICS]
The downgrade can be considered as a kind of preemption for
range:
HSCSD_FIRST_DOWNGRADE
resources currently seized by multi-channel calls. With the
GPRS_FIRST_DOWNGRADE
'downgrade strategy' the operator can determine how much the
DOWNGRADE_HSCSD_ONLY
DOWNGRADE_GPRS_ONLY
bandwidth and grade of service of HSCSD and GPRS is affected in
NO_DOWNGRADE
case of TCH congestion. The scenario that triggers a downgrade
default: GPRS_FIRST_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)

195 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

196 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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]).
DUMMY= "NOTDEF",
object: BTS [BASICS]
range: String Length 1...64
default: "NOTDEF"

Dummy this parameter allows to introduce alphanumeric value


(only letters and numbers), to specify cell characteristic flag (e.g.
rural, city,) in the BSC database (see CR4328).
This parameter has no impact on system behaviour.

Introduced in BR10.0
Introduced in BR 10.0

EANTHOP = FALSE,
object:
range:
default:

197 / 703

BTS [BASICS]
TRUE, FALSE
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EARCLMS3G =FALSE,
object:
range:
default:

BTS [BASICS]
TRUE, FALSE
FALSE

Introduced in BR 10.0

EEOTD=TRUE,
object:
range:
default:

BTS [BASICS]
TRUE, FALSE
FALSE

EFCRESEL=FALSE,
object:
range:
default:

198 / 703

BTS [BASICS]
TRUE, FALSE
FALSE

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. GSMCU, 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 BCCHTRX 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.
Early Classmark Sending 3G
This attribute lets to set the 3G early class mark sending restrictor
always to H value in System Info and packed system info
independently from values of EUHO (enabling UMTS handover
object).
Note: In BR10.0 this parameter replaced the functionallity of
BIT24 in MNTBMASK parameter
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.
Enable Fast Cell reselection, when this attribute is set to TRUE, the
BSC inserts the BCCH frequency of the serving cell into the 'BA list' in
the SYSTEM INFORMATION TYPE 2 message (in addition, the
relevant BSIC of the serving is cell added to the SYSTEM
INFORMATION 2quater). The 'BA list' (BA = BCCH Allocation)
indicates the BCCH frequencies that must be monitored and

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EHDCTR=FALSE,
object:
range:
default:

199 / 703

BTS [BASICS]
TRUE, FALSE
FALSE

measured both in 'idle' mode (i.e. the MS is not involved in a call) and
'active' mode (also called 'group listening mode', i.e. the MS is
currently involved in a VBS or VGCS group call, but only listening to
the DL group channel, see parameter ASCISER for further details). In
other words, when EFCRESEL=TRUE, the MS also monitors the
BCCH frequency of the currently serving cell in 'idle' mode and
'active' mode.
In 'idle' mode the BA list is referred to as 'BA(BCCH)'. In 'connected'
mode (i.e. the MS is involved in a dedicated connection) the BA list is
referred to as 'BA(SACCH)' - in this case the BA list indicates the
neighbour cell BCCHs that must be monitored for the neighbour cell
measurement reporting.
As most of the mobiles have the option to store the last known
BA(BCCH) in a non volatile storage (according to GSM 11.11), on
subsequent switch-on in that PLMN, the MS does not need to search
'on the air' in order to retrieve the currently valid BA(BCCH). Thus,
with the BCCH frequency of the serving cell added to the BA(BCCH),
the MS still 'remembers' the last best BCCH in idle mode and
therefore, if it stays in the same cell before switch-off and after switchon, the mobile attaches itself more quickly to the cell without any need
of further cell reselections. Consequently, also call setups are not
unnecessarily delayed due to the cell selection processes. This
functionality was originally required for GSM-R projects, but is
relevant in the same way for all other GSM networks.
Note: The effect of setting EFCRESEL=TRUE behaviour is similar to
the effect of setting the parameter LOTRACH=FALSE (see command
SET HAND [BASICS]) - however, the difference is that
LOTRACH=FALSE induces the enhancement of the BA List in the
SYSTEM INFORMATION TYPE 5 (i.e. BA(SACCH), for neighbour
cell monitoring in 'idle' mode) by the serving cell's BCCH frequency,
while EFCRESEL=TRUE induces the enhancement of the BA List in
the SYSTEM INFORMATION TYPE 2 (i.e. BA(BCCH) for neighbour
cell monitoring in 'connected' mode) by the serving cell's BCCH
frequency.
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].

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EHRACT=TRUE,
object:
range:
default:

BTS [BASICS]
TRUE, FALSE
TRUE

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
Traffic load [%] =

no. of radio TCH not available for CS TCH allocation


no. of configured radio TCH

100

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

200 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

As long as the traffic load remains below the threshold defined by the
parameters HRACTT1 and HRACTT2, the BSC forces the incoming
TCH seizures to FR or EFR (depending on the preference indicated in
the ASS REQ or HO REQ and the BSC/TRAU capability).
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
BTSM Abis traffic load [%] =

no. of Abis TCH not available for CS TCH allocation

100

no. of Abis TCHs configured in Abis pool

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

201 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

assigns a TCH type in correspondence with the 'establishment cause'


value received in the CHANNEL REQUIRED message.
- To avoid a ping-pong handover from HR to FR and vice versa,
which can occur due to subsequent execution of (AMR)
decompression handover (see parameter EADVCMPDCMHO in
command SET HAND [BASICS]) and intracell handover due to quality
(for a call whose quality is still poor after decompression handover),
the features 'Cell load dependent 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:
range:
default:

BTS [BASICS]
TRUE, FALSE
TRUE

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.

Introduced in BR 10.0

Enable Moving Procedure SDCA- this parameter is used to enable


or disable the HSCSD upgrade and forced intracell handover due to
preferred service layer on BTS level.
This parameter is correlated with BSC parameter ENFOIAHO which
enables forced intra-cell HO for the procedures:
a) 'Upgrade of originally downgraded multislot calls' and
b) 'Forced Handover due to preferred service layer'.
For both cases, (a and b) EMPROSDCA must be set to TRUE in
addition to ENFOIAHO parameter.
Note: In BR10.0 this parameter replaced the functionallity of BIT12 in
MNTBMASK parameter

ENPERNOTDE=
FALSE,

Enable periodic notification on dedicated channel, this parameter


enables/disables the periodical notification repetition on dedicated

EMPROSDCA = FALSE,
object:
range:
default:

202 / 703

BTS [BASICS]
TRUE, FALSE
FALSE

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

channels.
object:
range:
default:

BTS [BASICS]
TRUE, FALSE
FALSE

EPAT1=4000,
object:
unit:
range:
default:

BTS [BASICS]
0,01 %
0..10000
4000

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 CELLTYP=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).
no. of radio TCH in usage state idle *
no. of configured radio TCH

100

<

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

203 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EPAT2=4000,
object:
unit:
range:
default:

BTS [BASICS]
0,01 %
0..10000
4000

ERFACCHALPDMF=
DISABLE(0),
object:
range:

BTS [BASICS]
DISABLE(0),
ENABLE(x)
with x=
TCH_AFS,TCH_AHS,
TCH_EFS,TCH_FS,
TCH_HS, TCH_WFS
(multiple values are linked
with a 'pipe' ( | ) )
default:
DISABLE (0)
FRS-No.: 92893
SF-No.:
10525
Introduced in BR9.0
Range modified in BR 10.0 (TCH_WFS)

ERFACCHCMDF =
DISABLE(0),
object:
range:

BTS [BASICS]
DISABLE(0),
ENABLE(x)
with x=
TCH_AFS,TCH_AHS,
TCH_EFS,TCH_FS,
TCH_HS, TCH_WFS
(multiple values are linked
with a 'pipe' ( | ) )
default:
DISABLE (0)
FRS-No.: 92893
SF-No.:
10525
Introduced in BR9.0
Range modified in BR 10.0 (TCH_WFS)

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 CELLTYP=EXTCELL in command
CREATE BTS [BASICS]).
The value 100 represents 1%.
For further details please refer to parameter EPAT1 (see above).
Enable Repeated FACCH on Any LAPDm frame, this parameter
enables the feature 'DL Repeated FACCH' (R-FACCH) on any
LAPDm frames for 'Release 6' compliant mobiles that indicate their RACCH capability as '1' (R-ACCH_CAP=1).
For further details, please refer to parameter ERFACCHCMDF (see
below).
Notes:
- The feature R-FACCH is only available for BTSE HW platform
BTSplus.
- The feature 'DL R-FACCH' is combined with the feature 'Temporary
Overpower' (parameter ETOP, see below) within one sales feature
(SF-No. see left column). As this sales feature is optional, it can only
be enabled if the corresponding license is available.
Enable Repeated FACCH on Command Frames, this parameter
enables the feature 'DL Repeated FACCH' (R-FACCH) on LAPDm
command frames for legacy mobiles (i.e. mobiles of older generation)
and those 'Release 6' mobiles that do not indicate their R-ACCH
capability as '0' (R-ACCH_CAP=0).
Background
R-FACCH is a feature that is supposed to reduce call drops,
especially in AMR networks, where the robustness of the signalling
channels against bad C/I conditions does not match to the
considerably increased robustness of the AMR speech codecs.
Usually call drops should occur only if the coverage is so poor that
also the traffic channel does no longer allow an undisturbed
communication. As long as standard speech codecs (EFR, FR and
HR) are used, the robustness of the signaling channels (FACCH and
SACCH) corresponds to the one of the speech codec, which means
that the call drop reliably indicates an unacceptable quality of service
(QoS) in the user channel. In AMR networks, however, AMR call
drops may happen due to degraded signalling performance although
on the TCH the communication is still possible with an acceptably
good QoS.
R-FACCH feature summary
Network experience has shown that the vast majority of all call drops
occur during handover signaling - and this is exactly where R-FACCH
can be deployed to adapt the performance of the signalling channels
to the robustness of the AMR speech codecs: under critical radio
conditions (see below), R-FACCH applies a kind of transmit
redundancy by triggering a double transmission of FACCH messages:
The BTS transmits a FACCH messages twice in immediate

204 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

succession.

For FR calls, this repetition is done in immediate succession in


accordance with the diagram below:

Remark: An additional TDMA slot (used for an idle or SACCH frame)


may be placed between the two FACCH block copies. In this case the
repeated FACCH block would not start 8 blocks after the first one
(M+8) but 9 (M+9).
For HR calls, the two repeated FACCH frames are time-overlapped
with no further TDMA frame in between.

The actual gain of the R-FACCH transmit redundancy depends on the


mobile type.
R-FACCH Joint Decoding capability of MS
Mobiles compliant to 3GPP Release 6 are capable of performing 'joint
decoding' ('chase combining') of both received consecutive FACCH
block copies (i.e. the original one and the repeated one). This
mechanism is, however, applied if none of the two FACCH blocks can
be correctly decoded by single block decoding (if both blocks can be
successfully decoded, the repeated one is discarded, if the decoding
of only one of the two FACCH block copies fails, the MS considers the
successfully decoded one).
The capability of the MS to support R-FACCH is derived from
signaling: The R-ACCH capability of the MS is signaled to the network
via the 1-bit flag Repeated ACCH Capability (R-ACCH_CAP) which
is part of the Classmark 3 information element sent in the
CLASSMARK CHANGE message.
With respect to the R-FACCH support capabilities of the MS, the MSs
can be subdivided into three different types:
a) Mobiles older than 3GPP Release 6
For these mobiles the receipt of a repeated FACCH block simply
means the receipt of two separate FACCH blocks without any logical
relation between both blocks. As a result, these MSs will, if both the
first and the second FACCH block are correctly received, answer the
second one with a LAPDm REJ frame (as the BTS is informed about
the MS's R-ACCH capabilities vie the MS RF PCI message, it is
knows how to manage such situations correspondingly). Anyway, as
the double transmission of the FACCH block increases the probability
that one of the two is correctly received, a gain of 2dB is expected for

205 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

these MS types.
As test established that some legacy mobiles have problems to
manage repeated FACCH message different from ASSIGNMENT
COMMAND and HANDOVER COMMAND (embedded in a LAPDm
'I-frame'), the operator has the possibility to enable R-FACCH only for
this case and to prevent R-FACCH from being applied on LAPDm
command frames other than I-frames with ASS CMD and HO CMD
embedded. This is achieved by the by the parameter combination
ERFACCHCMDF=ENABLE(<speech versions list>) and
ARFACCHACMDF=FALSE
For parameter ARFACCHACMDF please see above.
Unfortunately, the 3GPP standard does not allow a distinction of
legacy mobiles (a) and the mobiles described under point (b) (see
below).
b) Release 6 mobiles with R-ACCH_CAP=0
These mobiles are capable of joint decoding ('chase combining') but
they support the reception and management of repeated FACCH
blocks only for LAPDm 'command frames' (I-frames or UI-frames),
but not for LAPDm 'response frames' (UA-frames, RR-frames, DMframes).
If the operator wants to exploit the full gain potential of these 'Release
6' compliant MSs (with R-ACCH_CAP=0), he can allow R-FACCH to
be enabled on any LAPDM command frame (I-frames or UI-frames),
including I-frames that contain layer 3 messages other than HO CMD
and ASS CMD. This is achieved by the by the parameter combination
ERFACCHCMDF=ENABLE(<speech versions list>) and
ARFACCHACMDF=TRUE
It must be considered, however, that this setting may cause problems
for some legacy mobiles (see point (a) ).
c) Release 6 mobiles with R-ACCH_CAP=1
These mobiles are capable of joint decoding ('chase combining') and
they support the reception and management of repeated FACCH
blocks for any type of LAPDm frame, i.e. both LAPDm command
frames (I-frames or UI-frames) and LAPDm 'response frames' (UAframes, RR-frames, DM-frames).
When R-FACCH is to be enabled for these mobiles, the following
parameter setting must be applied:
ERFACCHALPDMF=ENABLE(<speech versions list>)
For parameter ERFACCHALPDMF please see above. This parameter
enables R-FACCH for a special group of mobiles only and is therefore
totally independent from parameter ERFACCHCMDF. No problems
are to be expected as a result of the enabling.
R-FACCH Activation Trigger
R-FACCH is activated (and thus applied for a particular FACCH
block) on a frame-by-frame basis. If the operator has enabled RFACCH in a cell for a particular speech codec type via database
parameter, R-FACCH is applied for a speech call using this codec
type if a (timer-controlled) re-transmission of the first scheduled
FACCH block is required. Which mechanism triggers this
retransmission, is context-dependent, e.g.
 for layer 2 I-frames (e.g. HO CMD, ASS CMD etc.), the usual
trigger is the expiry of T200. (see parameter T200 in command
SET BTS [TIMER]).
 for layer 2 UI-frames (containing the PHYS INFO message), the
trigger is the expiry of T3105 (see parameter T3105 in command
SET BTS [TIMER]).
 for layer 2 UA-frames the trigger is the repeated reception of an

206 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

SABM.
R-FACCH Feature enabling
As can be seen from the parameter value range, R-FACCH can be
enabled separately per speech codec (AMR-FR, AMR-HR, EFR, FR
and HR). This is valid for both commands for ERFACCHALPDMF and
ERFACCHCMDF.

ETOP= DISABLE(0),
object:
range:

BTS [BASICS]
DISABLE(0),
ENABLE(x)
with x=
TCH_AFS,TCH_AHS,
TCH_EFS,TCH_FS,
TCH_HS, TCH_WFS
(multiple values are linked
with a 'pipe' ( | ) )
default:
DISABLE (0)
FRS-No.: 92893
SF-No.:
10525
Introduced in BR9.0
Range modified in BR 10.0 (TCH_WFS)

Notes:
- The feature R-FACCH is only available for BTSE HW platform
BTSplus.
- The feature 'DL R-FACCH' is combined with the feature 'Temporary
Overpower' (parameter ETOP, see below) within one sales feature
(SF-No. see left column). As this sales feature is optional, it can only
be enabled if the corresponding license is available.
Enable Temporary Overpower, this parameter enables the feature
'Temporary Overpower' (TOP).
Background
TOP is a feature that is supposed to reduce call drops, especially in
AMR networks, where the robustness of the signalling channels
against bad C/I conditions does not match to the considerably
increased robustness of the AMR speech codecs. Usually call drops
should occur only if the coverage is so poor that also the traffic
channel does no longer allow an undisturbed communication. As long
as standard speech codecs (EFR, FR and HR) are used, the
robustness of the signaling channels (FACCH and SACCH)
corresponds to the one of the speech codec, which means that the
call drop reliably indicates an unacceptable quality of service (QoS) in
the user channel. In AMR networks, however, AMR call drops may
happen due to degraded signalling performance although on the TCH
the communication is still possible with an acceptably good QoS.
TOP feature summary
Network experience has shown that the vast majority of all call drops
occur during handover signaling - and this is exactly where TOP can
be deployed to adapt the performance of the signalling channels to
the robustness of the AMR speech codecs: under critical radio
conditions (see below), TOP induces the temporary increase of the
DL transmission power by 2dB or 4dB on SACCH and FACCH.
Precondition, however, is that the BTS still has some 'reserves' when
it already operates at the maximum DL transmit power, and this is
only the case if static power reduction (see parameter PWRRED in
command CREATE TRX) is applied in the cell. Only if the setting
PWRRED=2 (=4dB static power reduction related to the maximum DL
TX power capability of the CU, ECU or FlexCU) is applied, the
mentioned temporary power increase of 4dB is possible. Obviously, if
PWRRED=1, the temporary power increase is limited to 2dB.
Preconditions for TOP Activation
TOP can only be applied if
- static PWRRED is applied for the TRXs (see above)
- the TCH is using a GMSK-modulated speech codec and hopping is
active with more than one frequency in the hopping pattern (if the
TCH does not use hopping (FHSYID=0) or hopping is temporarily
disabled (with pseudo-hopping on one frequency only), TOP is not
applied.
- the TCH does not belong to the BCCH TRX (this limitation arises
from the impact of overpower on the neighbour cell measurements.
Any involvement of the BCCH in the hopping pattern (only possible if
HOPMODE=BBHOP) disables TOP for the affected TCH.
TOP Activation Trigger Events
TOP is activated in the following cases

207 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

a) When bad radio link quality is detected:


The radio link quality is regarded as bad when the average DL
RXQUAL value (averaged over the complete handover quality
averaging window as defined by parameter HOAVQUAL) has
exceeded a hardcoded threshold:
When
DL_RXQUAL 6.25
an overpower or 2dB is applied on all DL FACCH and SACCH bursts.
b) When a TCH is activated, regardless of the activation reason (i.e.
no matter whether the TCH is activated for TCH assignment, Intercell
HO or Intracell HO) an overpower of 2dB is applied on all DL FACCH
and SACCH bursts.
c) If a FACCH repetition is required, i.e. after first expiry of T200 or
T3105, or on repeated receipt of SABM, an overpower of 4dB is
applied on all subsequent FACCH and SACCH bursts in downlink.
TOP Deactivation Trigger
TOP is deactivated when the average DL RXQUAL value (averaged
over the complete handover quality averaging window, see above)
has dropped below the hardcoded threshold:
DL_RXQUAL < 6.25
TOP Feature enabling
As can be seen from the parameter value range, TOP can be enabled
separately per speech codec (AMR-FR, AMR-HR, EFR, FR and HR).

ERSACCHDL=DISABLE,
object:
range:

BTS [BASICS]
DISABLE(0),
ENABLE(x)
with x=
TCH_AFS;
TCH_AHS;TCH_EFS;
TCH_FS;TCH_HS;
TCH_WFS; SIGNALLING;

default:

DISABLE (0)

FRS-No.:
SF-No.:

94171
10558

GSM:

44.004, 44.005 and 44.006

Introduced in BR10.0

Notes:
- The feature TOP is only available for BTSE HW platform BTSplus.
- The feature TOP is combined with the feature 'Repeated FACCH'
(parameter ERFACCHCMDF, see above) within one sales feature
(SF-No. see left column). As this sales feature is optional, it can only
be enabled if the corresponding license is available.
Enable R-SACCH in DL - this parameter allows to enable / disable
Repeated SACCH (R-SACCH) in DL for different codec types and / or
signaling on a cell basis for new (Rel-6) MS that have communicated
via ClassMark3 (CM3) their R-ACCH_CAP as 1.
Background
R-SACCH is a feature that is supposed to reduce call drops,
especially in AMR networks, where the robustness of the signalling
channels against bad C/I conditions does not match to the
considerably increased robustness of the AMR speech codecs.
Usually call drops should occur only if the coverage is so poor that
also the traffic channel does no longer allow an undisturbed
communication. As long as standard speech codecs (EFR, FR and
HR) are used, the robustness of the signaling channels (FACCH and
SACCH) corresponds to the one of the speech codec, which means
that the call drop reliably indicates an unacceptable quality of service
(QoS) in the user channel. In AMR networks, however, AMR call
drops may happen due to degraded signalling performance although
on the TCH the communication is still possible with an acceptably
good QoS.
R-SACCH feature summary
Repeatead SACCH procedure foresees a serial repetition of SACCH
blocks in adjacent SACCH multi-frames in order to improve the
SACCH performance.
When a SACCH message was repeated by the sending peer, the
receiving peer (MS or BTS) attempts a joint decoding (soft decision
combining) of the two received copies of the same SACCH message.
R-SACCH activation trigger events
The R-SACCH mechanism is activated in DL if:
a) when 2 consecutive SACCH frames with SRR=1 have been
received from the MS.

208 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

b)
c)

the current UL or DL RXLEV drops below a configurable


threshold (see RSACCHRXLUL and RSACCHRXLDL) or
R-FACCH DL conditions (see ERFACCHCMDF) are fulfilled
(for R-SACCH DL only)

SACCH Repetition Request (SRR) is a special bit in the SACCH layer


1 header thst is used in UL by MS in order to notify the BTS that the
decoding of the previous SACCH block in DL failed (MS sets SRR=1)
and to request its repetition. If it is set to 0 it means successful DL
SACCH decoding and no need for repetition.
R-SACCH deactivation depends on setting of Repeated SACCH Time
Out parameter (see RSACCHTOUL and RSACCHTODL).
ERSACCHUL=DISABLE,
object:
range:

BTS [BASICS]
DISABLE(0),
ENABLE(x)
with x=
TCH_AFS;
TCH_AHS;TCH_EFS;
TCH_FS;TCH_HS;
TCH_WFS; SIGNALLING;

default:

DISABLE (0)

FRS-No.:
SF-No.:

94171, SFD
10558

GSM:

44.004, 44.005 and 44.006

Introduced in BR10.0

ETXDIVTS=FALSE,
object:
range:
default:

BTS [BASICS]
TRUE, FALSE
FALSE

FACCHQ=5,
object:
unit:
range:
default:

BTS [BASICS]
1 half burst
0..7
5

FACHBT=,
object:
range:
default:

BTS [BASICS]
0..127

FRS:

94417

Introduced in BR10.0

209 / 703

Enable R-SACCH in UL- this parameter allows to enable / disable RSACCH in UL for different codec types and / or signaling on a cell
basis for new (Rel-6) MS that have communicated via CM3 their RACCH_CAP as 1.
For description of R-SACCH see description of ERSACCHDL
parameter.
R-SACCH activation trigger events
The R-SACCH mechanism is activated in UL if:
a) when 2 consecutive UL SACCH blocks could not be decoded
(in this case the BTS sets SRO=1 in the next DL SACCH
frame
b) the current UL or DL RXLEV drops below a configurable
threshold (see RSACCHRXLDL and RSACCHRXLUL)
SRO (SACCH Repetition Order) is a special bit in the SACCH layer 1
header thst is used in DL to instruct the MS to repeat the UL SACCH
block in the next SACCH period (BTS sets SRO=1).
Enable TX diversity timeshift, this parameter allows to switch
between coverage mode (enabled) and standard mode (disabled).

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.
FACCH Busy Threshold - this attribute represents threshold for the
received signal level during handover access and ASCI uplink
access. If the RXLEV value of the HO ACCESS burst is lower than
the value defined by FACHBT, the HO ACESS burst is ignored by the
BTS as a consequence, the BTS does not send a PHYSICAL INFO
message and the MS has to return to the old channel. Only if the
RXLEV of the received HO ACCESS burst exceeds the entered
threshold value, it is accepted by the BTS and the HO procedure is
continued.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Remark: This threshold is also used for the ASCI uplink access
procedure (subsequent talker access procedure) for VGCS calls.
In BR releases up to BR9.0, the parameter RACHBT determines an
RXLEV threshold that is used in two different scenarios:
- RACH access,- in this scenario the value of RACHBT determines
the RXLEV threshold for the RACH signal evaluation
- Handover access, in this scenario RACHBT determines the RXLEV
threshold for the signal strength of the HO ACCESS burst that is sent
on the FACCH of the new activated TCH during inter-cell handover.

FACQ3G= FALSE,
object:
units:
range:

BTS

default:

FALSE

TRUE, FALSE

FRS-No.: 98321
SF-No.:
Introduced in RG20(BR)

FDDMURREP=0,
object:
range:
default:
reference:

210 / 703

BTS [BASICS]
0..3
0
3GPP 44.018
3GPP 45.008

Since in previous BR releases the value of RACHBT was used for


any access burst, it is necessary that the introduction of
new
parameter FACHBT doesnt compromise the system behavior, so,
during upgrade, the database conversion tools read out the current
value of parameter RACHBT and set this value for both the
parameters RACHBT and FACHBT.
Fast acquisition 3G, if the parameter is set to TRUE AND 3G
neighbouring cell are put in the Neighbour Cell List, then 3G Priority
parameters are put in SI2quater even if there are no LTE
neighbours.
If LTE neighbours are put in SI2quater, parameter is meaningless
since either way 3G Priority parameters have to be put in SI2quater.

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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FDDQMI=MDB12,
object:
range:

BTS [BASICS]
MDB20 MDB18
MDB16 MDB14
MDB12 MDB10
MDB08 MDB06
default: MDB12
reference: 3GPP 44.018
3GPP 45.008

FDDQMIO=DB00,
object:
range:

BTS [BASICS]
DB00 DB04 DB06
DB08 DB10 DB12
DB14
default: DB00
reference: 3GPP 44.018
3GPP 45.008

211 / 703

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FDDQO=DB00,
object:
range:

BTS [BASICS]
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

FDDREPO=DB00,
object:
range:

BTS [BASICS]
DB00 DB06 DB12
DB18 DB24 DB30
DB36 DB42
default: DB00
reference: 3GPP 44.018
3GPP 45.008

212 / 703

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FDDREPQTY=RSCP,
object:
range:
default:
reference:

BTS [BASICS]
RSCP, ECNO
RSCP
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).

213 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

FDDREPTH=RXLEV_00,
object:
range:

BTS [BASICS]
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

FDDREPTH2=0,
object:
range:
default:
reference:

214 / 703

BTS [BASICS]
0.. 63
0
3GPP 45.008
3GPP 44.018

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
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.)
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 MEASUREMENT REPOR Tor 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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FDDRSCPMI=MDB101,
object:
range:

BTS [BASICS]
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

FHAMRFRC1=RATE_01,
object:
range:

default:

BTS[BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, RATE_06,
RATE_07, RATE_08,
<NULL>
RATE_01

FHAMRFRC2=RATE_03,
object:
range:

default:

BTS[BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, RATE_06,
RATE_07, RATE_08,
<NULL>
RATE_03

FHAMRFRC3=RATE_06,
object:
range:

default:

BTS[BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, RATE_06,
RATE_07, RATE_08,
<NULL>
RATE_06

FHAMRFRC4=RATE_08,
object:
range:

default:

215 / 703

BTS[BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, RATE_06,
RATE_07, RATE_08,
<NULL>
RATE_08

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FHAMRFRIC=START_MODE
_FR,
object:
range:

default:

BTS[BASICS]
START_MODE_FR
CODEC_MODE_01
CODEC_MODE_02
CODEC_MODE_03
CODEC_MODE_04
START_MODE_FR

FHAMRFRTH12=7-4,
object:
format:
unit:
range:
default:

BTS[BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 7 [3.5 dB]
hysteresis: 4 [1.0 dB]

FHAMRFRTH23=12-4,
object:
format:
unit:
range:
default:

BTS[BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 12 [3.0 dB]
hysteresis: 4 [1.0 dB]

FHAMRFRTH34=23-4,
object:
format:
unit:
range:
default:

BTS[BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 23 [12.5 dB]
hysteresis: 4 [2.0 dB]

FHAMRHRC1=RATE_01,
object:
range:

default:

216 / 703

BTS[BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, <NULL>
RATE_01

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FHAMRHRC2=RATE_02,
object:
range:

default:

BTS[BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, <NULL>
RATE_02

FHAMRHRC3=RATE_03,
object:
range:

default:

BTS[BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, <NULL>
RATE_03

FHAMRHRC4=RATE_04,
object:
range:

default:

BTS[BASICS]
RATE_01, RATE_02,
RATE_03, RATE_04,
RATE_05, <NULL>
RATE_04

FHAMRHRIC=START_MODE
_HR,
object:
range:

default:

BTS[BASICS]
START_MODE_HR
CODEC_MODE_01
CODEC_MODE_02
CODEC_MODE_03
CODEC_MODE_04
START_MODE_HR

FHAMRHRTH12=19-4,
object:
format:
unit:
range:
default:

BTS[BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 19 [9.0 dB]
hysteresis: 4 [2.0 dB]

FHAMRHRTH23=24-4,
object:
format:
unit:
range:
default:

217 / 703

BTS[BASICS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 24 [12.0 dB]
hysteresis: 4 [2.0 dB]

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

AMR Half Rate Thresholds 34 for frequency hopping, this


parameter defines the C/I threshold and the associated hysteresis for
object:
BTS[BASICS]
the AMR downlink CODEC mode adaptation transition from
format: threshold-hysteresis
AMRHRC3 to AMRHRC4 and vice versa in case of active frequency
unit:
threshold: 0.5dB
hopping (see also parameter HOPP in command SET BTS
hysteresis: 0.5dB
[OPTIONS].
range:
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
This parameter eclipses its equivalent parameter AMRHRTH34 if
default: threshold: 30 [15.0 dB] (BTS+)
frequency hopping is currently active for an AMR call.
<NULL> (BTS1)
For further details about the parameter values and AMR parameters
hysteresis: 4 [2.0 dB]
and thresholds please refer to the parameter AMRFRC1.
FHAMRWBFGIC=START_MO fhAMRWBFullrateGmskInitialCodec this parameter defines the
initial codec mode for the AMR-WB feature if activated (see the
DE_WFS,
parameter EAMRWB). The ACS for the AMR-WB feature is hardobject:
BTS[AMRPARAMETERS]
coded and always consists of the three TCH/WFS codec modes: 6.60
kbps, 8.85 kbps and 12.65 kbps.
range:
START_MODE_WFS;
The START_MODE_WFS means the application of the GSM rule
CODEC_MODE_01;
(05.09 recommendadtion) which states that in case the ACS consists
CODEC_MODE_02;
of three codec modes the one with the lowest rate (6.60 kbps) should
CODEC_MODE_03;
default: START_MODE_WFS
be the initial codec mode.
The parameter is applicable to the layers with frequency hopping.
Introduced in BR10.0
The initial codec mode is allocated to the AMR-WB call at call setup.
Afterwards, it can be changed depending on the radion conditions by
the link adaptation algorithm.
The initial codec mode is on until the TFO negotaion is completed.
FHAMRHRTH34=30-4,

FHAMRWBFGTH12 =17-4,
object:
format:
unit:
range:
default:

BTS[AMRPARAMETERS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 17 [8.5 dB]
hysteresis: 4 [2.0 dB]

Introduced in BR10.0

AMR WB Full Rate GMSK Threshold 12 for frequency hopping,


this parameter defines the lower threshold for switching from the
AMR-WB TCH/WFS codec mode 2 to 1 and the hysteresis value to
get the higher threshold for switching from the AMR-WB TCH/WFS
codec mode 1 to 2 in the link adaptation (LA) process in downlink.
The parameter is a combination of the threshold and hysteresis subfields. See also the FHAMRWBFGTH23 parameter.
The following rules must be obeyed when setting the parameter:

FHAMRWBFGT H 12(threshold ) <


< FHAMRWBFGT H 23(threshold )
FHAMRWBFGT H 12(threshold ) +

+ FHAMRWBFGT H 12(hysteresis ) <


< FHAMRWBFGT H 23(threshold ) +
+ FHAMRWBFGT H 23(hysteresis )

6.60 kbps

8.85 kbps

12.65 kbps
C/I [dB]

AMRWBFGTH12-Threshold

AMRWBFGTH23-Threshold

AMRWBFGTH12-Hysteresis

AMRWBFGTH23-Hysteresis

The parameter is applicable to the layers with frequency hopping. See


also the parameter AMRWBFGTH12.
The LA process can be executed locally when the TFO is not
established on the AMR-WB codec mode. If the TFO (the full end-toend AMR-WB connection) is successfully established, then the local
LA process is disabled, i.e. the selection of the currently used

218 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

TCH/WFS codec mode depends also on the radio conditions at the


distant radio interface:
- if radio conditions at both ends allow using different codec modes
the more robust codec mode is selected out of the codec modes used
locally as a common one,
- codec mode upgrading is possible if both radio links are good
enough,
- codec mode downgrading is necessary if at least one radio link is
not good enough
FHAMRWBFGTH23 =25-4,
object:
format:
unit:
range:
default:

BTS[AMRPARAMETERS]
threshold-hysteresis
threshold: 0.5dB
hysteresis: 0.5dB
threshold: 0..63 [0..31.5dB]
hysteresis: 0..15 [0..7.5dB]
threshold: 25 [12.5 dB]
hysteresis: 4 [2.0 dB]

Introduced in BR10.0

fhAMRWBFullrateGmskThreshold23, this parameter defines the


lower threshold for switching from the AMR-WB TCH/WFS codec
mode 3 to 2 and the hysteresis value to get the higher threshold for
switching from the AMR-WB TCH/WFS codec mode 2 to 3 in the link
adaptation (LA) process in downlink. The parameter is a combination
of the threshold and hysteresis sub-fields. See also the
FHAMRWBFGTH12 parameter.
The following rules must be obeyed when setting the parameter:

FHAMRWBFGT H 23(threshold ) >


> FHAMRWBFGT H 12(threshold )
FHAMRWBFGT H 23(threshold ) +

+ FHAMRWBFGT H 23(hysteresis ) <


< FHAMRWBFGT H 12(threshold ) +
+ FHAMRWBFGT H 12(hysteresis )

6.60 kbps

8.85 kbps

12.65 kbps
C/I [dB]

FHAMRWBFGTH12-Threshold

FHAMRWBFGTH23-Threshold

FHAMRWBFGTH12-Hysteresis

FHAMRWBFGTH23-Hysteresis

The parameter is applicable to the layers with frequency hopping. See


also the parameter AMRWBFGTH12.
The LA process can be executed locally when the TFO is not
established on the AMR-WB codec mode. If the TFO (the full end-toend AMR-WB connection) is successfully established, then the local
LA process is disabled, i.e. the selection of the currently used
TCH/WFS codec mode depends also on the radio conditions at the
distant radio interface:
- if radio conditions at both ends allow using different codec modes
the more robust codec mode is selected out of the codec modes used
locally as a common one,
- codec mode upgrading is possible if both radio links are good
enough,
- codec mode downgrading is necessary if at least one radio link is
not good enough
FRACTAMRTH1=3000,
object:
range:
default:

219 / 703

BTS [BASICS]
0.. 10000
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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
Traffic load [%] =

no. of TCH* in usage state busy**


no. of TCH in state unlocked/enabled

100

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.

220 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FRACTAMRTH2=3000,
object:
range:
default:

BTS [BASICS]
0.. 10000
3000

FRACTTH1=3000,
object:
range:
default:

BTS [BASICS]
0.. 10000
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
CELLTYP=EXTCELL in command CREATE BTS [BASICS]).
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
Traffic load [%] =

no. of TCH* in usage state busy**


no. of TCH in state unlocked/enabled

100

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-

221 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

FRACTTH2=3000,
object:
range:
default:

BTS [BASICS]
0.. 10000
3000

FRANOFFS=0
object:
range:
default:

BTS [BASICS]
0.. 255, <NULL>
0

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.
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
CELLTYP=EXTCELL in command CREATE BTS [BASICS]).
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).

Default modified in BR10.0

GPRS extension, this parameter specifies if GPRS/EGPRS is


allowed also in non-BCCH bands of a dual band standard cell
BTS [BASICS]
(parameter value CELLTYP=DBSTDCELL, see above). Please do
ALL900, ALLFREQ, <NULL> also refer to parameter SYSID (see below) for further information.

GEXTS=<NULL>,
object:
range:
default:

<NULL>

GSMPRIO=7,
object:
units:
range:

BTS
0, 1, , 7

default:

FRS-No.: 98321
SF-No.:
Introduced in RG20 (BR)

222 / 703

GSM prio, absolute priority of the serving GSM cell


0 low priority, , 7 high priority
Value provides the relative priority of the GSM cells similarly as
priority of E-UTRAN cell (EUPRIO) and UTRAN cells (DEFUPRIO)
taken into account in the cell reselection algorithm. GSM priority has
to be different from WCDMA and LTE priorities.
Value is relevant only for inter-RAT cell reselection based on priority.
Priority based cell reselection algorithm (please refer to FRS 98321)
is always used in case of GSM-LTE cell reselection and for GSMWCDMA if:
- cell reselection to LTE is possible (legacy algorithm for cell
reselection to WCDMA based on cell ranking and priority
based cell reselection could not run simultaneously while
camped on GSM cell)or
- LTE neighbours cell are not defined but FACQ3G parameter
is set to TRUE.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

GUARMABIS=0,
object:
unit:
range:
default:

BTS [BASICS]
1%
0..20
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.

Hysteresis, hysteresis used in the priority based reselection


algorithm only if there are no inter-RAT cells with higher priority that
satisfy appropriate criteria (please refer to EUHITH and DEFUTH)
object:
BTS
range:
NO_HYST, DB5, DB4, DB3 and moreover if there are no cells with lower priority that satisfy low
priority criteria (please refer to EULTH and DEFUTH)
default:
NO HYSTERESIS
Threshold related to RSRP of LTE cell that has to be satisfied then:
FRS-No.: 98321
RSRP EUQRXLEVMIN > C1 + HPRIO
SF-No.:
during THRESEL
Introduced in RG20 (BR)
In case of 3G cell:
CPICH RSCP DEFUQRXLEVMIN >
C1 + HPRIO
during THRESEL
Note that priority of LTE cell vs. WCDMA cells does not play role in
this case and only signal level is taken into account to select the
target cell
Note: This is an exception to general rule for priority based cell
reselection where signal strength of cells of various RATs are not
compared directly
DB5 corresponds to 5dB of hysteresis, DB4 to 4 dB, DB3 to 3dB.
HPRIO= NO_HYST,

HRACTAMRT1=6000,
object:
unit:
range:
default:

223 / 703

BTS [BASICS]
0,01 %
0..10000
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,

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 CELLTYP=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 are 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 service (i.e. those TRXs supporting AMR speech
services) of its cells and compares it to the threshold HRACTAMRT1.
For AMR compression handover the BSC calculates the traffic load
as follows
Traffic load [%] =

no. of TCH* in usage state busy**


no. of TCH in state unlocked/enabled

100

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.

224 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
- (**) 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 services (i.e. those TRXs supporting AMR speech
services) 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 service types services (i.e. those
TRXs supporting AMR speech services) only, separately for every
subarea (primary/complementary). Please refer to the command SET
BTS [SERVICE] for further explanations.

225 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

HRACTAMRT2=6000,
object:
unit:
range:
default:

BTS [BASICS]
0,01 %
0..10000
6000

HRACTT1=6000,
object:
unit:
range:
default:

BTS [BASICS]
0,01 %
0..10000
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
CELLTYP=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.
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 nonAMR 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
Traffic load [%] =

no. of TCH not available for CS TCH allocation*


no. of configured TCH

100

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

226 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
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
- 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 TRXs 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 load on all TCH resources that belong to
TRXs 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 non-AMR services (i.e. those TRXs supporting non-AMR
speech services) of its cells and compares it to the threshold
HRACTT1.
For non-AMR compression handover the BSC calculates the traffic
load as follows
Traffic load [%] =

227 / 703

no. of TCH* in usage state busy**


no. of TCH in state unlocked/enabled

Network Engineering GERAN

100

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 non-AMR speech services (i.e. those TRXs supporting nonAMR speech services) 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 nonAMR 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 nonAMR 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 non-AMR speech service types only, separately for
every subarea (primary/complementary). Please refer to the
command SET BTS [SERVICE] for further explanations.
HRACTT2=1000,
object:
unit:
range:
default:

BTS [BASICS]
0,01 %
0..10000
6000

LCBM0=<NULL>,
object:
format:

228 / 703

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

BTS [BASICS]
<msgid> <page>
<reprate#> - <scheme>

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____
range:

default:

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

LCBM1=<NULL>,
object:
BTS [BASICS]
format and range: see LCBM0
default:
<NULL>

LCBM2=<NULL>,
object:
BTS [BASICS]
format and range: see LCBM0
default:
<NULL>

LCBM3=<NULL>,
object:
BTS [BASICS]
format and range: see LCBM0
default:
<NULL>

MEAEXTBCCH=
FALSE,
object:
range:
default:

BTS [BASICS]
TRUE, FALSE
FALSE

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

229 / 703

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.
Local Cell Broadcast Message 2, 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.
Local Cell Broadcast Message 3, 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.
Measure extra BCCH frequencies, this parameter enables/disables
the feature 'Automatic Procedure to measure extra BCCH
Frequencies per cell'.If the feature is active it is required to define
which extra BCCH is to be measured. This can be done by defining
so called dummy neighbours i.e. adjacent cell (ADJC object) with
setting parameter USG=INACTIVE indicating that this neighbour is for
the measurement purposes only and no handover or cell reselection
to that neighbour cell is allowed.
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 parameter is applied in the following cases:
a) This parameter 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) as well as in the
'Power Command' IEs contained in the ASSIGNMENT COMMAND
and HANDOVER COMMAND messages (for BSC-controlled
handovers towards this cell). Remark: 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.
b) This parameter is also 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 (for

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

further details please see section 'Handover Thresholds and


Algorithms' in the appendix of this document).
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:
unit:
range:
default:

BTS [BASICS]
see tables below
2..15
5

MSTXPMAXPCS=0,
object:
unit:
range:
default:

230 / 703

BTS [BASICS]
see tables below
0..15, 30, 31
0

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)
This parameter is the GSM equivalent to the DCS parameter
MSTXPMAXDCS - for further information please refer to the
explanation provided for this parameter.
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.
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),
This parameter is the PCS equivalent to the DCS parameter
MSTXPMAXDCS - for further information please refer to the
explanation provided for this parameter.
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Mobile station Power Classes


Power
class

GSM 400 & GSM 900 &


GSM 850

DCS 1800

PCS 1900

Nominal Maximum
output power

Nominal Maximum
output power

Nominal Maximum
output power

------

1 W (30 dBm)

1 W (30 dBm)

8 W (39 dBm)

0,25 W (24 dBm)

0,25 W (24 dBm)

5 W (37 dBm)

4 W (36 dBm)

2 W (33 dBm)

2 W (33 dBm)

0,8 W (29 dBm)

from GSM 05.05 (3GPP 45.005), 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
Nominal Output
Control Level
Power (dBm)

0..2

39

29

36

22-29

Reserved

37

30

34

30

33

35

31

32

31

32

33

30

30

31

28

28

29

26

26

27

24

24

25

22

22

10

23

20

20

11

21

18

18

12

19

16

16

13

17

14

14

14

15

12

12

15

13

10

10

10

10

16

11

11

11

17

12

12

18

13

13

19-31

14

14

15-28

from GSM 05.05 (3GPP 45.005), MS Output power tables

231 / 703

Network Engineering GERAN

15

16-21

Reserved

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

NCIREP=FALSE,
object:
range:
default:

BTS [BASICS]
TRUE, FALSE
FALSE

FRS-No.:
SF-No.:

97531
10567

Introduced in RG20 (BR)

NEPTTREP=0,
object:
range:
default:

BTS [BASICS]
0..3
0

FRS-No.:
SF-No.:

96747
10570

Neigbour Cell Information Repetition , this parameter allows to


request the repetition (one time) on the radio interface of the
message VGCS Neighbour Cell Information, in order to prevent the
possibility that a mobile, loosing the message, performs a reselection
and starts receiving data on the channel which it thinks is the group
channel, but is not any more valid.. TRUE value means one repetition
enabled after 300ms from the first sending. The parameter is
significant only for the cells were ASCI service is enabled (ASCISER
= ASCI_ENABLED) and ASCI Enhanced Cell Reselection activated
(ASCIECR=TRUE)
No EPTTdata repetition counter , this parameter determines the
number of repetitions of the Short Data messages at the Um-interface
when the feature Short Data Transmission during ongoing Group
Call is enabled (EEPTT =TRUE). The data are broadcasted one, two
or three times with a fix repetition rate of 200 ms (e.g. for the cells
with worse radio conditions to increase the probability of reception).

Introduced in BR10.0

NMULBAC=0,
object:
range:
default:
reference:

BTS [BASICS]
0..3
0
3GPP 45.008
3GPP 44.018

PCCCHLDI=255,
object:
unit:
range:
default:

232 / 703

BTS [BASICS]
1s
0..255
255

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
3GPP 45.008
below).
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
unit:
range:
default:
Reference:

BTS [BASICS]
20s
0..31
31= TEMPOFF ignored
0
3GPP 45.008
GSM 03.22

PLMNP=255,
object:
range:
default:
Reference:

BTS [BASICS]
0..255
255
GSM 03.03
GSM 04.08
GSM 02.11
GSM 05.08

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

allowed NCCs

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.

233 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

PNOFACCH=2.5,
object:
unit:
range:
default:

BTS [BASICS]
0.5 sec
1, 1.5, 2,4.5, 5
<NULL>
2.5

QSRHC=NEVER,
object:
range:

BTS [BASICS]
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

QSRHCINI=QSEARCHI,
object:
range:
default:
reference:

BTS [BASICS]
QSEARCHI, ALWAYS
QSEARCHI
3GPP 45.008
3GPP 44.018

QSRHI=NEVER,
object:
range:

BTS [BASICS]
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

234 / 703

Period for Notification on FACCH, this parameter specifies period


(repetition rate) for the FACCH notification for a given ASCI call.

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 handover
neighbour cell monitoring (QSRHC) or/and cell selection/reselection
(QRSHI).
- 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
handover neighbour cell monitoring (QSRHC) or/and cell
selection/reselection (QRSHI).
- The value ALWAYS means the Mobile shall always consider 3G
neighbours cells for handover neighbour cell monitoring (QSRHC)
or/and cell selection/reselection (QRSHI).
- The value NEVER means the Mobile shall not consider 3G
neighbours cells for handover neighbour cell monitoring (QSRHC)
or/and cell selection/reselection (QRSHI) 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).
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).
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
unit:
range:
default:

235 / 703

BTS [BASICS]
-1dBm
0..127
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 fulfill 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 signalto-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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
unit:
range:
default:

BTS [BASICS]
1 RACH burst
102-65535
204

RDLNKTO=4,
object:
range:

default:
Reference:

BTS [BASICS]
0..15
0 = counter value 4
15 = counter value 64
4
3GPP 45.008
GSM 04.08

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

236 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

REPTYP=NORMAL,
object:
range:
default:
reference:

237 / 703

BTS [BASICS]
NORMAL, ENHANCED
NORMAL
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 determine
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 MS 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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 mean and 'coefficient of variation'
of the Bit Error Probability (BEP) measures (averaged over the
reporting period).
- 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 cannot be reported due to
lack of space in the report, then no cell with a lower value is 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.

238 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

RSACCHRXLDL=10,
object:
range:

BTS [BASICS]
0..25

default:

10

FRS-No.:
SF-No.:

94171
10558

Introduced in BR10.0

RSACCHRXLUL=7,
object:
range:
default:

BTS [BASICS]
0..25
7

FRS-No.:
SF-No.:

94171
10558

Introduced in BR10.0

RSACCHTODL=4,
object:
range:
default:

BTS [BASICS]
0..10
4

FRS-No.:
SF-No.:

94171
10558

Introduced in BR10.0

RSACCHTOUL=4,
object:
range:
default:

BTS [BASICS]
0..10
4

FRS-No.:
SF-No.:

94171
10558

Introduced in BR10.0

239 / 703

Repeated SACCH RxLev DL - this parameter allows to set the


threshold on a cell basis for the reported RXLEV_DL_SUB used as an
exception in the decision algorithm for activation of R-SACCH in both
DL and UL for those codec types and signaling for which R-SACCH in
DL and UL, respectively, has been enabled see (ERSACCHDL and
ERSACCHUL) for new (Rel-6) MS that have communicated via CM3
their R-ACCH_CAP as 1 .
Note: Setting this parameter to a high value e.g. 25 (-85 dBm) may
cause undesirable permanent activation of R-SACCH both in UL and
DL even at good DL received level!
Repeated SACCH RxLev UL - this parameter allows to set the
threshold on a cell basis for the reported RXLEV_UL_SUB used as an
exception in the decision algorithm for activation of R-SACCH in both
DL and UL for those codec types and signaling for which R-SACCH in
DL and UL, respectively, has been enabled (see ERSACCHDL and
ERSACCHUL) for new (Rel-6) MS that have communicated via CM3
their R-ACCH_CAP as 1.
Note: Setting this parameter to a high value e.g. 25 (-85 dBm) may
cause undesirable permanent activation of R-SACCH both in UL and
DL even at good UL received level!
Repeated Sacch Time Out DL - this parameter allows to set the
threshold for deactivation of R-SACCH on a cell basis for the counter
used in the decision algorithm for activation / deactivation R-SACCH
in DL for those codec types and signaling for which R-SACCH in DL
has been enabled (for new (Rel-6) MS that have communicated via
CM3 their R-ACCH_CAP as 1.
R-SACCH deactivation
R-SACCH deactivation trigger conditions depend on the SACCH
message scheduling context (not explained in detail here). Expressed
in a simplified way, when R-SACCH is currently active, the BTS
deactivates R-SACCH in DL when RSACCHTODL consecutive
SACCH frames with SRR=0 (indicating successful DL SACCH
decoding) have been received from the MS.
SACCH Repetition Request (SRR) is a special bit in the SACCH layer
1 header thst is used in UL by MS in order to notify the BTS that the
decoding of the previous SACCH block in DL failed (MS sets SRR=1)
and to request its repetition. If it is set to 0 it means successful DL
SACCH decoding and no need for repetition.
Repeated Sacch Time Out UL- this parameter allows to set the
threshold for deactivation of R-SACCH on a cell basis for the counter
used in the decision algorithm for activation / deactivation R-SACCH
in UL for those codec types and signaling for which R-SACCH in UL
has been enabled for new (Rel-6) MS that have communicated via
CM3 their R-ACCH_CAP as 1.
R-SACCH deactivation
R-SACCH deactivation trigger conditions depend on the SACCH
message scheduling context (not explained in detail here). Expressed
in a simplified way, when R-SACCH is currently active, the BTS
deactivates R-SACCH in UL when consecutive UL SACCH blocks
could be correctly decoded (in this case the BTS sets SRO=0 in the
next DL SACCH frame).
SRO (SACCH Repetition Order) is a special bit in the SACCH layer 1
header thst is used in DL to instruct the MS to repeat the UL SACCH
block in the next SACCH period (BTS sets SRO=1).

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

RXLEVAMI=6,
object:
unit:
range:

default:
Reference:

BTS [BASICS]
1 dB
0..63
0 = less than -110dBm
1 = -110dBm to -109dBm
2 = -109dBm to -108dBm
...
62 = -49dBm to -48dBm
63 = greater than -48dBm
6
3GPP 45.008
GSM 04.08
GSM 03.22

RXSIGLEVADJ=<NULL>,
object:
BTS [BASICS]
unit:
1dB
range:
-24...24[dB], <NULL>
default:
<NULL>
Introduced in BR9.0

RXSIGLEVADJC=<NULL>,
object:
BTS [BASICS]
unit:
1dB
range:
-24...24[dB], <NULL>
default:
<NULL>
Introduced in BR9.0

SDCCHCONGTH=70,
object:
unit:
range:
default:

BTS [BASICS]
1%
70..100
70

RXLEV access minimum, this parameter defines the minimum DL


receive level the MS must receive from the serving cell in order to be
allowed to access to the network via 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).
RX Signal Level Adjustment, this parameter replaces the parameter
RXLEVADJ that was previously only administrable in the BTSE
configuration database and defines the RX signal level adjustment
which shall be applied to the receive paths of transceivers using the
same frequency band as the BCCH transceiver.
For further details about the meaning and purpose of this parameter
please refer to the explanations provided for the command CREATE
RFLOOP.
RX Signal Level Adjustment Complementary, this parameter
replaces the parameter RXLEVADJ that was previously only
administrable in the BTSE configuration database and defines the RX
signal level adjustment to be applied to the transmit paths of
transceivers using the complementary frequency band. The value is
only meaningful in case of a multiband cell.
For further details about the meaning and purpose of this parameter
please refer to the explanations provided for the command CREATE
RFLOOP.
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:
SDCCH traffic load [%] =

no. of busy SDCCH subslots*

100

no. of SDCCH subslots in unlocked/enabled*

* 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,

240 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:

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.

241 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

System Indicator, indicates the frequency band used by the traffic


channels.
object:
BTS [BASICS]
If F2ONLY900 is selected only phase2 mobiles can be used, phase1
range:
BB900 (GSM baseband)
mobiles are not supported.
DCS1800
If EXT900 is selected the GSM base band is still usable for phase1
EXT900 (GSM mixed band)
mobiles,
the extension band, however, can only be used for traffic
GSMR (railway GSM),
purposes by phase2 mobiles.
PCS1900
GSMDCS
The values GSMDCS and GSM850PCS must be set if the cell is to be
GSM850
configured with TRX frequencies of two different frequency bands
GSM850PCS
(dual band concentric cells, or dual band standard cells, refer to
Reference: GSM 04.08
parameters CELLTYP and CONCELL, see above).
Parameter value F2ONLY900 removed in The value F2ONLY900 value has been removed in BR8.0 since the
BR8.0!
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.
UL Busy Repetition Rate, , this parameter determines the repetition
T3151=3,
rate of the UPLINK BUSY message at the Um interface when the
object:
BTS [BASIC]
feature Short Data Transmission during ongoing Group Call is
range:
1..9
enabled (EEPTT =TRUE).
default:
3
UPLINK BUSY message informs that uplink of the group channel is
FRS-No.: 96747
occupied. In case the 1 Channel Model is activated, the UPLINK
SF-No.:
10570
BUSY message indicates that Short Data shall be send using access
Introduced in BR10.0
via RACH procedure.
Timing advance adjust, this parameter allows to enter a correction
TAADJ=0,
term for the BTSE internal timing advance measurements (similar to
the parameter RXLECADJ, see command CREATE RFLOOP). The
object:
BTS [BASICS]
unit:
100ns
idea of this correction term is to consider the propagation delay on the
range:
0..100, <NULL>
BTSE internal signal path for the determination of the real timing
default:
0 (BTS SW BR7.0)
advance value. This is achieved by simply adding the TAADJ value to
<NULL> (BTS SW < BR7.0)
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.
SYSID=BB900,

TCCCHLDI=100,
object:
unit:
range:
default:

242 / 703

BTS [BASICS]
1%
0..100
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:

PCH load [%] =

no. of seized PCH blocks 2 no. of PCH blocks seized by only 1 MS ID*

Network Engineering
GERAN
2 Total
number of PCH blocks available**

100

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
RACH load [%] =

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


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

100

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.
TDDMURREP=0,
object:
range:
default:
reference:

243 / 703

BTS [BASICS]
0..3
0
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

BTS [BASICS]
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:
range:

BTS [BASICS]
DB00 DB06 DB12
DB18 DB24 DB30
DB36 DB42
default: DB00
reference: 3GPP 44.018
3GPP 45.008

TDDREPTH=RXLEV_00,
object:
range:

BTS [BASICS]
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

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

THGSML= ALWAYS,
object:
BTS
units:
range:
DB00, DB02, DB04, DB06,
DB08, DB10, DB12, DB14, DB16, DB18,
DB20, DB22, DB24, DB26, DB28,
ALWAYS
default:
ALWAYS

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).
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).
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.
Treshold GSM Low, value of C1 for the serving cell below which the
MS is allowed to reselect to lower priority cells. For conditions that
have to be additionally satisfied for LTE cell please refer to EULTH, for
3G cell please refer to DEFUTH.
Value DB00 corresponds to 0 dB, DB02 to 2dB..DB28 to 28 dB.

FRS-No.: 98321
SF-No.:
Introduced in RG20 (BR)

244 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Treshold Priority Search, threshold for the serving cell that controls
measurement of inter-RAT cells or frequencies with lower priority than
the priority of the serving cell. If serving cell RLA_C is higher than
object:
BTS
units:
dBm
THPRIOS MS is allowed not to perform measurements of cells with
range:
MDB98 MDB95 MDB92
lower priority.
MDB89 MDB86 MDB83 MDB80
Value MDB98 corresponds to -98 dBm, DB95 to -95dBm..MDB56 to
MDB77 MDB74 MDB71 MDB68
MDB65 MDB62 MDB59 MDB56 always -56 dBm..
THPRIOS= ALWAYS,

default:

ALWAYS

FRS-No.: 98321
SF-No.:
Introduced in RG20 (BR)

THRESEL= SEC05,
object:
units:
range:

BTS
.
SEC05, SEC10,
SEC15, SEC20

default:

SEC05

Time Hysteresis Reselection, Time hysteresis in priority based cell


reselection algorithm, used in all inter-RAT reselection scenarios.
It also replaces the hardcoded in 3GPP specs value of 5 s related to
GSM-WCDMA cell reselection algorithm based on cell ranking
Value SEC05 corresponds to 5sec.. SEC20 to 20 sec.

FRS-No.: 98321
SF-No.:
Introduced in RG20 (BR)

TXDIVTSEXCPT=NONE,
object:
range:

default:

BTS [BASICS]
NONE, SCH
BCCHTRXTS0,
BCCHTRX
NONE

TXDIVTSPAR=NONE,
object:
range:

default:

BTS [BASICS]
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
NONE

TXSIGLEVADJ=<NULL>,
object:
BTS [BASICS]
unit:
1dB
range:
-63...63[dB], <NULL>
default:
<NULL>
Introduced in BR9.0

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.

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.

TX Signal Level Adjustment, this parameter replaces the parameter


TXLEVADJ that was previously only administrable in the BTSE
configuration database and defines the TX signal level adjustment
which shall be applied to the receive paths of transceivers using the
same frequency band as the BCCH transceiver.
TX Signal Level Adjustment also defines the TX signal level
adjustment which shall be effective in case of Derived Handover

245 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Power feature enabled. It is used in the computation of the


BSPOWERtarget-max in the current TRX. In turn BSPOWERtargetmax is used to calculate BSPOWERres (converted into the power
control level) that is ordered as initial downlink TX power from Layer 1
of the TRX.
Moreover the TX signal level adjustment is used in the computation of
MSPOWERres. BSC sends the resulting MSPOWER (power control
level according 3GPP TS 45.005) to the MS as part of the Handover
Command message and the BTS inserts the resulting MSPOWER as
Ordered MS Power Level into the L1 Header of the SACCH
messages.
The TX signal level adjustment indicates the losses between BTS
Layer 3 Call Processing and Antenna.

For further details about the meaning and purpose of this parameter
please refer to the explanations provided for the command CREATE
RFLOOP.
TXSIGLEVADJC=<NULL>,
object:
BTS [BASICS]
unit:
1dB
range:
-63...63[dB], <NULL>
default:
<NULL>
Introduced in BR9.0

246 / 703

TX Signal Level Adjustment Complementary, this parameter


replaces the parameter TXLEVADJ that was previously only
administrable in the BTSE configuration database and defines the TX
signal level adjustment to be applied to the transmit paths of
transceivers using the complementary frequency band. The value is
only meaningful in case of a multiband cell.
For further details about the meaning and purpose of this parameter
please refer to the explanations provided for the command CREATE
RFLOOP.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

UMTSSRHPRI=TRUE,
object:
range:
default:
reference:

247 / 703

BTS [BASICS]
TRUE, FALSE
TRUE
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).

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:

BQP = P(FER > FERmax)


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:

BQP BQPmax
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

248 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

EFL [%] =

Mean no. of busy TCH on DMA layer *


8 Total no. of hopping frequencies on DMA layer

100

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

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.

249 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

- 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

250 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

251 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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 BTSMno. was changed to 0..199, the BTS-no. was changed to 0..23.

ACBQPFF=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 ().

object:
range:
step size:
default:

BTS [ADM]
0.1 .. 1.0, <NULL>
0.1
0.2

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:
range:
unit:
default:

BTS [ADM]
2 .. 10, <NULL>
1%
5

ACEFLFF=0.04,
object:
range:
step size:
default:

BTS [ADM]
0.02 .. 0.2, <NULL>
0.02
0.04

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.
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:
range:
unit:
default:

252 / 703

BTS [ADM]
1.0 .. 10.0, <NULL>
1%
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

ACLNKTYP=
UL_SAMPLES_ONLY,
object:
range:

default:

BTS [ADM]
uLAndDLSamplesSeparately,
uLSamplesOnly,
uLAndDLSamplesCommonly,
<NULL>
uLSamplesOnly

ACMAXEFLDMA=PER_50,
object:
range:

default:

BTS [ADM]
PER_10, PER_15,
PER_25,
PER_95, PER_100
PER_50

PER_20,

ACMINEFLDMA=PER_10,
object:
range:

default:

BTS [ADM]
PER_5, PER_10, PER_15,

PER_45, PER_50,
PER_10

ACPER=SACCH_120,
object:
range:

default:

BTS [ADM]
SACCH_020, SACCH_024,
SACCH_028, SACCH_032,
SACCH_036, SACCH_040
... SACCH_400
SACCH_120

EAC=FALSE,
object:
range:
default:

253 / 703

BTS [ADM]
TRUE, FALSE
FALSE

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.
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.
For further details please refer to the feature description above the
parameter listing.

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.
For further details please refer to the feature description above the
parameter listing.
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).
For further details please refer to the feature description above the
parameter listing.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the cell specific attributes for the CCCH:

SET BTS [CCCH]:

< All attribute values set by this command (except for NY1) have
effects on the SYSTEM INFORMATION messages on the BCCH. >
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,

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

object:
range:
default:
Reference:

254 / 703

BTS [CCCH]
ONE, TWO, FOUR,
SEVEN
FOUR
GSM 04.08
GSM 05.08

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

MSTXPMAXCH=5,
object:
range:
default:
Reference:

BTS [CCCH]
0..31
5
GSM 04.08
GSM 05.08

NBLKACGR=1,
object:
range:
default:
Reference:

255 / 703

BTS [CCCH]
0..7
1
GSM 04.08
GSM 05.02

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.
MS maximum transmit power for CCCH, indicates
- the maximum transmit power level a MS is allowed to use when it
accesses the cell on the Random Access Channel' (RACH) and
- the initial power the Ms is allowed to use on the dedicated control
channel (SDCCH or TCH) after an IMMEDIATE ASSIGNMENT. This
power level remains valid until the MS receives the first power control
order (due to dynamic Power Control, see parameter EMSPWRC in
command SET PWRC). When a TCH is assigned, the power level is
signalled via the IE 'Power Command' (see parameter
MSTXPMAXGSM (resp. MSTXPMAXDCS or MSTXPMAXPCS) in
command CREATE BTS [BASICS]). 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])).
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.

256 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

NFRAMEPG=2,
object:
range:
default:
Reference:

BTS [CCCH]
2..9
2
GSM 04.08
GSM 05.02
GSM 05.08

NOCHFBLK=1,
object:
range:
default:

257 / 703

BTS [CCCH]
1..7
1

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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
th
every N 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 on
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:
range:
default:

BTS [CCCH]
1-4
1

NSLOTST=10,
object:
range:
default:
Reference:

258 / 703

BTS [CCCH]
0..15
10
GSM 04.08

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

10

11

12

13

14

15

tr

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

td = 163 slots

first transmission with a


collision

= tx_integer
=6
trNSLOTST
= tx_integer
=6
 tr = 6

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.

259 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

NY1=50,

object:
range:
default:
Reference:

BTS [CCCH]
1-254
30
GSM 04.08

Recommended value after


implementation of BR8.0 CR CR2795:
NY1=50,
T3105=MS10-10

PWROFS=0,
object:
unit:
range:
default:
Reference:

260 / 703

BTS [CCCH]
2dB
0-3
0=feature disabled
0
GSM 04.08
GSM 05.08

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the cell attributes for the Interference Measurement of idle TCHs:

SET BTS [INTERF]:

< The parameters set with this command are used for averaging and
reporting interference levels in idle traffic channels. >
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,

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 4), these values set
the limits of the five 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 according to the following table:

object:
format:

unit:

range:
default:

Reference:

BTS [INTERF]
averaging period
- threshold boundary 1
- threshold boundary 2
- threshold boundary 3
- threshold boundary 4
averaging period:
1 SACCH multiframe
threshold boundaries:
-1dBr
1-31 (averaging period)
0..62 (threshold boundaries)
31 (averaging period)
2 (threshold boundary 1)
6 (threshold boundary 2)
12 (threshold boundary 3)
22 (threshold boundary 4)
3GPP 45.008

INTCLASS=TRUE,
object:
range:
default:

261 / 703

BTS [INTERF]
TRUE, FALSE
TRUE

Interf. Band

Involved Threshold Boundaries

0dB < RXLEV < threshold boundary 1

threshold boundary 1 < RXLEV < threshold boundary 2

threshold boundary 2 < RXLEV < threshold boundary 3

threshold boundary 3 < RXLEV < threshold boundary 4

RXLEV > threshold boundary 4

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 BTS parameter
RXSIGLEVADJ (see command CREATE BTS [BASICS] and
command CREATE RFLOOP).
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.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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:
unit:
range:
default:

262 / 703

RF resource indication period, defines the sending rate of the


RFRESIND message towards the BSC.

BTS [INTERF]
1 SACCH multiframe
1-254
60

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the cell specific timer values:

SET BTS [TIMER]:

< This command sets the timers on layer 2 and 3 of Um interface. >
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.

DTMHOMT=<NULL>,

DTM Handover Timer, this parameter is related to the feature 'DTM


Power Budget Handling' (see parameter DTMPBGTHO in command
SET HAND [BASICS]) and defines the DTM handover timer.
DTMHOMT represents a time period for the DTM Power Budget
Handover (see parameter DTMPBGTHO in command SET HAND
[BASICS]) during which special DTM related parameters are applied
for the handover triggering and ranking of target cells.
The value entered for DTMHOMT is relevant for MSs in dedicated
mode after a forced DTM Handover procedure or after a TBF release
when previously a DTM call was established. In more detail, this
parameter determines the time period during which the BTS considers
the DTM Handover Margin (see parameter DTMHOM in command
CREATE ADJC/ADJC3G) and DTM Priority Level (see DTMPL in
command SET HAND [BASICS] and DTMPL in command CREATE
ADJC/ADJC3G) values when the MS is in 'dedicated mode' after a
forced DTM Handover procedure or after a TBF release.
For further details, please refer to the description provided for
parameter DTMPBGTHO (see command SET HAND [BASICS]).
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:

object:
units:
range:
default:

BTS [TIMER]
SACCH multiframe
121,
<NULL>
4

FRS-No.: 92563
SF-No.:
Introduced in BR9.0

ENANCD=ENABLED,
object:
range:
default:

BTS [TIMER]
DISABLED, ENABLED
ENABLED

Sleeping
Cell Alarm
active

Sleeping
Cell Alarm
ceased
= succ. SDCCH assignment
(i.e. ESTIN for SDCCH received)

TNC

TNC

TNC

no successful
SDCCH ssignment

time zone

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

263 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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.

Sleeping TRX
Alarm active

Sleeping TRX
Alarm ceased

TNC

TNC

CHAN ACT ACK (TCH) EST IND (TCH) >= 8

CHAN ACT ACK (TCH) EST IND (TCH) < 8

time zone

NCDP1=H1-6,
object:
format:
unit:

range:
default:

BTS [TIMER]
StartTime1-TimerNoCall 1
StartTime1: Time in '1h'
TimerNoCall1:
Periods of 10min
StartTime1: H0..H23
TimerNoCall1: 1-432
H1-6

NCDP2=H6-1,
object:
format:
unit:

range:

default:

264 / 703

BTS [TIMER]
StartTime2-TimerNoCall2
StartTime2: Time in '1h'
TimerNoCall2:
Periods of 10min
StartTime2: NOTUSED,
H1..H23
TimerNoCall2: 1-432
H6-1

Timer 1 for 'No call in TRX/cell detection', this parameter allows to


configure the first time-frame for the 'sleeping TRX/cell detection'
procedure. StartTime1 represents the beginning of the time-frame.
TimerNoCall1 represents the observation period, expressed as
multiple of granularity period (10 minutes).
The following condition must be fulfilled:
NCDP1TIMER 6x (NCDP2STARTTIME NCDP1STARTTIME)
The aim of this condition for NCDP1TIMER is to ensure that this timer
expires before that NCDP2STARTTIME begins (6x is the conversion
factor from Hour -> 10Minutes - 1Hour = 6x 10Minutes).
The change of the default value was implemented to avoid
unnecessary 'sleeping cell' alarms during night time.
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 timeframe.TimerNoCall2 represents the observation period, expressed as
multiple of granularity period (10 minutes).
Note: If NCDP2 is used the following rules must be applied:
1) NCDP2STARTTIME > NCDP1STARTTIME
2) NCDP2TIMER 6x (24 - (NCDP2STARTTIME NCDP1STARTTIME))
As x NCDP1TIMER, the condition for NCDP2TIMER is to ensure that
this timer expires before that NCDP1STARTTIME begins (6x is the
conversion factor from Hour -> 10Minutes - 1Hour = 6x 10Minutes).
The change of the default value was implemented to avoid
unnecessary 'sleeping cell' alarms during night time.

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

NRPGRANT=20,
object:
range:
default:
reference:

BTS [TIMER]
1-254
20
GSM 04.18

T200=29-31-38-90-70-29-168,
object:
unit:

range:
default:

reference:

265 / 703

BTS [TIMER]
5ms
(for sdcchSAPI0,
facchTCHF, facchTCHH,
sdcchSAPI3)
10ms
(for sacchTCHSAPI0,
sacchSDCCH,
sacchTCHSAPI3)
0..255
29 (sdcchSAPI0)
31 (facchTCHF)
38 (facchTCHH)
90 (sacchTCHSAPI0)
70 (sacchSDCCH)
23 (sdcchSAPI3)
168 (sacchTCHSAPI3)
3GPP 44.006

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).
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 principle of Um layer 2 acknowledgments based on T200:
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 UIframes, e.g. in the downlink the SACCH messages SYSTEM
INFORMATION TYPE5 and 6 etc. and in the uplink the SACCH
messages MEASUREMENT REPORT.
Of course, the MS uses the layer 2 acknowledgement mechanisms
based on T200 in the same way as the BTS. In the MS, however, the
T200 timer values are not variable but hardcoded.
Functional Description: 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). SABM and DISC
frames are usually sent by the MS only.
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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

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

266 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

T3101=HLFSEC-6,
object:
units:

range:
default:
Reference:

BTS [TIMER]
MS100 = 100 ms
HLFSEC = 0,5 sec
SEC5 = 5s
0..255
HLFSEC-6
GSM 04.08

T3105=MS10-10
object:
units:
range:

default:
Reference:

BTS [TIMER]
MS10 = 10ms
1..254
since BR8.0 CR2795:
effective range: 1..12
MS10-10
GSM 04.08

Recommended value after


implementation of BR8.0 CR CR2795:
NY1=50,
T3105=MS10-10

enough to avoid a call drop indication during a channel change


procedure (e.g. handover).
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: 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.
T3105
purpose:
start:
stop:

period for repetition of PHYSICAL INFORMATION message


sending of PHYSICAL INFORMATION message
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.

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. The time
between two retransmissions is determined by the value of timer
T200 for this channel type which is hardcoded in the MS but which is
not unambiguously defined by the standard. In the Siemens Mobiles,
for example, for an FACCH FR repetition time T200 is 32 TDMA
frames and the number of retransmissions (N200) is restricted to 5
(for further general information about the T200-based LAPDm flow
control mechanisms please refer to the description of parameter T200
in command SET BTS [TIMER]). This means that for the resulting

267 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

time of 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:
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 BSCcontrolled 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

268 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

T3109=HLFSEC-8,
object:
units:

range:
default:
Reference:

BTS [TIMER]
MS100 = 100 ms
HLFSEC = 0,5 sec
SEC5 = 5s
0..255
HLFSEC-8
GSM 04.08

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

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

range:
default:
Reference:

BTS [TIMER]
MS100 = 100 ms
HLFSEC = 0,5 sec
SEC5 = 5s
0..255
HLFSEC-1
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.
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

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

269 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

value (HLFSEC-1).

270 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

TGRANT=4,
object:
unit:
range:
default:
reference :

BTS [TIMER]
10 ms
1-254
4
GSM 04.18

TNOCH=1,
object:
unit:
range:
default:

BTS [TIMER]
1 SACCH multiframe
1-254
1

TSYNC=1000,
object:
unit:
range:
default:

BTS [TIMER]
10ms
10..10000
1000
(recommended value >200)

TSYNCDL=1000,
object:
unit:
range:
default:

271 / 703

BTS [TIMER]
10ms
10..10000
1000

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

TSYNCR=400,
object:
unit:
range:
default:

BTS [TIMER]
10ms
10..10000
400

TSYNCUL=1000,
object:
unit:
range:
default:

BTS [TIMER]
10ms
10..10000
1000

TTRAU=1000,
object:
unit:
range:
default:

272 / 703

BTS [TIMER]
10ms
10..10000
1000
(recommended value >150)

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

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

TUPLREP=20,
object:
unit:
range:
default:

BTS [TIMER]
1s
5.. 60
20

VGRULF=1,
object:
unit:
range:
default:

BTS [TIMER]
1
1..100
1

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

273 / 703

Network Engineering GERAN

RG20 (BR) BSC Database Engineering Manual Version 1.0 17/09/2010


______________________________________________________________________________________________________
____

Setting the cell specific optional features:

SET BTS [OPTIONS]:

< Most of the values are of Boolean type and are broadcast to the
MSs on the BCCH. >
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),

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.

object:
range:
default:

BTS [OPTIONS]
ENABLED(1..100),
DISABLED
ENABLE(30) (minor)
ENABLE(60) (major)
ENABLE(90) (critical)

BSMONTH=
ENABLED(30)-ENABLE(60)ENABLED(90),
object:
range:
default:

BTS [OPTIONS]
ENABLED(1..100),
DISABLED
ENABLE(30) (minor)
ENABLE(60) (major)
ENABLE(90) (critical)

CELLBARR=FALSE,
object:
range:
default:
Reference:

274 / 703

BTS [OPTIONS]
TRUE, FALSE
FALSE
GSM 04.08
GSM 05.08

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.
Cell barred, the value TRUE indicates that the cell is barred and
camping or any other access to the ce