Bss Telecom Parameter B12

All rights reserved.
Passing on and copying of this

document, use and communication of its contents not
permitted without written authorization from Alcatel-Lucent
Site
Wireless Division
VELIZY
Originators
BSS TELECOM PARAMETERS
C. LEJEUNE
RELEASE B12
System
Sub-system
Document Category
:
:
:
Alcatel-Lucent GSM/GPRS/EDGE BSS

SYS-TLA
Product Definition
ABSTRACT
This document lists and defines all parameters and timers that are specified by BSS telecom specification
documents.
Name
App.
Name
App.
Approvals
MICHEL ROBERT
SYT team leader
ZHANG HUA
BSC DPM
NOEMI KIRELY
SU BO
MFS DPM
RAIMUND SABELLEK
BTS DPM
ROBERTO ALBU
OMC DPM
MICHEL WU
SYT DPM
REVIEW
Ed. 01 Proposal 01
2010/12/17
Review Report 210084
Ed.01 Proposal 02
2011/02/25
Ed.01 Proposal 03
2011/03/18
Ed.01 Proposal 04
2011/05/26
Ed 01 Released
2011/06/29
ED8 RELEASED
BSS TELECOM PARAMETERS - RELEASE B12

3BK 11203 0250 DSZZA
1/43
All rights reserved. Passing on and copying of this

HISTORY
Ed. 01 Proposal 01
2010/11/26
Based on the BTP B11 (3BK 11203 0172 DSZZA) Edition 18

version.
The following B12 features are taken into account:
- Support of VAMOS (sfd 678)
- LTE to GSM handover for voice calls (memo 209098_4)
The following modifications have also been added:

- the new B12 logical names are upper cases
- the 229 IP BSS transport parameters are B10 unselected (80 BSC
+ 106 MFS + 31 BTS + 12 TC)
- 140 BSC CAE parameters were new in B11 (80 from B11 MR3):
their migration rules have been updated
- 29 MFS CAE parameters were new in B11 (12 from B11 MR3):
their migration rules have been updated
- Clean up of the special B10 to B11 migration rules
- Clean up of B11 MR in visible fields (like comments and rules)
- 47 BSC new B11 site(CAE) parameters removed from CDE table
NOT DONE (will be in next proposal)
- A user plane over IP (sfd 163)
Ed.01 proposal 02
2010/12/17

- A user plane over IP (sfd 163)
- comments of rereading review (see report 210084)
Ed.01 proposal 03
2011/02/25
The following changes about VAMOS have been added:

- alignment with VAMOS sfd Ed1 released
- CR306471: UL_VAMOS_PC_CORRECTION_FACTOR
- CR306504: EN_VAMOS_UNPAIRING_CA
- CR306646: EN_TEST_FOR_NON_SAIC
- CR306938: SCPIR_MODIF_VAMOS_CCCH
- CR306731: changes upon A user plane over IP.
- the POLO name of all the 131 BSC Network(CDE) is set empty
(POLO does not handle them)
The following points will be handled later in another delivery:
- re-synchronization with BTP B11
- Boosted GP: (x4 in TDM) en B12.1 and (x10 in IP) en B12.2
- the consequence of move of IP BSS transport from B11 to B12
(229 parameters to check)
ED8 RELEASED

3BK 11203 0250 DSZZA
2/43

Ed.01 proposal 04
2011/03/18

- Boosted GP: according to the MFS memo 2011-5674 (x4 in TDM)
The following changes have been added:
- CR307499: VAMOS allowed training sequence codes (TSC and
TSC_1_2)
Ed.01 proposal 05
2011/05/26

- CR308749_v3: PAIRING_PRIORITIES in 1..6
Ed.01 Released
2011/06/29

- mdb color template changed
- The naming rules of the MFS dimensioning constant, related to
GP boosted, updated in $2.1
-BS_TXPWR_MAX (BSC) and (MFS) and BS_TXPWR_MAX_INNER
(BSC) kept in B12 as useless (clean up skipped)
In the header file, it is specified that the parameters reference
of the legacy MFS is the BTP B11.
The impact of the feature Ater GCH equity (memo 211135)
will be included in a further edition.
Ed.02 Released
2011/08/11
Alignment with BTP B11 Ed19rel done:

- CR307727_3(=301845): reboot GP when @IP GSL link is changed
- CR307728_2(=302029): BTS_RSL_TID up to 6 (MC module)
- CR307729_3(=302192): recommended rules on MTU
- CR307730_2(=302859): LTE FDD frequencies TMO (3GPPrel9)
- CR307731_3: LTE FDD frequencies (band 11 & band 6 changed)
The following CR B12 are included:
- CR309234_2: T_MAX_HOLD for MUXTRAUP and MUXRTP
- CR310684_2: T_RTP_PNRT for packet not received (AUPoIP)
- CR310727_2: HMI names updated for AUPoIP
ED8 RELEASED

3BK 11203 0250 DSZZA
3/43

Ed.03 Released
2011/11/10

- CR307732_1(=303060-legacy): avoid DL PDU lifetime reordering
- CR307733_4(=304319): unicity of SGSN IP endpoints per GP
- CR307734_2(=304732): RFD304026 besteffort QoS Handling (QQ)
- CR307735_1(=306529): TsyncU and TsyncD values
- CR307736_3: ARFCN_3G/LTE(FDD) & FDD_ARFCN_LIST ranges
- CR311802_1(=307592-legacy): RFD296268 (+6 Gps per BSS)
- CR311815_2(=308752): unit of FDD_REPORTING_OFFSET
- CR311854_4(=308848): impact of RMS improvements (CMCC)
- CR312049_6(=308301): RFD306784 suppression of Clear request
- CR311817_5(=309920): up to 4 CCCHs per cell (memo 211102)
- CR311818_4(=310104): PCC step2 -improved QQ (memo 211139)
- CR314148_1(=309619): BSS_SEND_CM_ENQUIRY clarification
- CR314149_2(=310484): EN_ASSIGN_FAIL_CIC_USED_NO_ACTION
With no PoloName
- CR314150_1(=310488): impact of one logical cell (sfd679)
- CR314151_1(=310857): EN_4_DR_TRE_PER_TCU dynamic->static
- CR314152_1(=311293): LOCAL_ASIG_SCTP_ENDPOINT_PORT only
- CR310655_3: Ater GCH equity per GP
- CR312606_1: default value of GAMMA_TNx
- CR312809_1: new default values for VAMOS parameters
- CR313832_1: FR sv1 mandatory in AUPoIP supported codec list
- T(sst): migration rule updated (to remove B11 scope)
- The Not used (NU) parameters, N2301_C and T200_SD and
T200_ST are B12 unselected
- The form Parameters_CRQ changed to display the SFD field
in the CRQ search result view.
ED8 RELEASED

3BK 11203 0250 DSZZA
4/43

Ed.04 Proposal01
2011/11/25
(for Light Radio)
new LR flag set to yes for 1680 parameters

(CAE+CDE+CST)= 1097 BSC parameters + 583 MFS
parameters.
new LR flag set to No when:

- a (MFS) parameter is already kown by the (BSC) related one, or
- a parameter, BSC or MFS, is linked to the LCS in MFS(sfd 0540),
or to the TDM transport mode only, or to the Master PDCH, or to
the Gb over Frame Relay
- a parameter, BSC or MFS, is linked to IPGSL or GSL (the BSCGP
level parameters are kept in LR)
- a BSC parameter is specific to G2 BSC
71 CDE MFS are added in the new CDE table for LR

The a.pdf file generated for LR BSC
OP1 : the MFS parameters (IP@ and port) for GBoIP and IPGCH
have to be managed by the LR BSC as for the other IP interfaces
of the BSC)
OP2: POLO and CAE template will manage the CAE PS parameters
applicable to LR
OP3: editorial change in text fields to avoid MFS , BSCGP, or
GP/GPU in LR PS parameters
OP4: list of CS features non applicable to LR (TDM mode,
max_tch_per_ccp, etc.) to be completed
OP5: to generate a single new GCD table for LR parameters (step
1 of the converged LR)
Ed.04 Proposal02
2012/01/27
(for Light Radio)
Ed.04 Proposal03
2012/03/23
ED8 RELEASED
The report Parameter_output updated with the new LR flag

Multi_GPU_INFO_BROADCAST_PERIOD
and
PACKET_LOAD_BROADCAST_PERIOD are redundant. Last one
is kept for GSM (and a new _LRC is added as specific)
Clean up (TDM mode/Frame Relay unselected in LRC) and
description updated for the parameters applicable in IP
mode
OP3 closed: editorial changes in text for LR consistency
Chapter 2.6 , instance description, updated for LightRadio.
OP3 closed: when applicable, the MFS renamed with the
generic and standardized term the PCU (packet control
unit); GP/GPU with PMU and BSC with BSC CS
applications
HPC CAE template modified to take into account single
EGSM, concentric EGSM and concentric EGSM-DCS1800.
CR309347_3: GERAN#49 impact: introduction of random fill
bits in SI6 (GP-110384)
CR311128_1: TSC combinations for SAIC-SAIC VAMOS pairing
CR314157_1: impact of 4 E1 per BTS (TDM) and 36 TRX per
BTS (TDM and IPoEth)
CR589681_1: VAMOS and Antenna diversity constraint
3BK 11203 0250 DSZZA
5/43

Ed.04 Released
2012/06/11

CR315734_3(=313355): limitation of Paging rate on A itf
The following CR B12 hare included:

CR315590_1: new default value for MSCR and SGSNR
CR602335_1: impact of DPVA (rfd 314485)
CR605005_2: new Type B counter requirements (#157939)
CR621059_3: reduction of transmitted PDDCB (#157185)
CR626898_1: full AUPoIP and Abis/Ater flexibility
CR640548_1: MS to betested procedure (#131918)
CR644803_4: packet Downlink Power Control (#155878)
CR648614_1: VARIOUS_IP_PRIORITY
CR670806_3: delay Ho for AMR-NB calls with TrFO (#158569)
CR675446_3: black-list mgt of substandard SAIC (#163246)
CR723451_1: correction of VAMOS parameters
CR731677_1: distinguish TBF delayed in RRM (#162463)
CR731695_3: increased weight for long TBF (#162464)
CR731702_2: flexible TBF delay timer (#162465)
CR732532_1: configurable Link-mapping table (#158200)
CR733185_2: new AMR-specific PC thresholds (#158199)
CR733542_1: 900/1800 dual-band networks (#159123)
CR735762_1: Max thres for AMR-HR usage per BSC (#162461)
(for Light Radio)
ED8 RELEASED
2012/07/05
HPC CAE template: SINGLE EGSM and CONCENTRIC EGSM

renamed with E-GSM (BSC inputs)
CDE table changed for SAI_LTE: min&max changed from
None to 0 (due to POLO issue)
OP5 closed: the GCD tables (B12 and LRC) have been
regenerated. For Light radio, only parameters of the LRC (ie
BSC or MFS) are considered, not of the BSS (BTS, TC, )
The CAE template value has been added in the extraction
results of the Keyword Search form
Ed.05 Released
CR617635_1: T_RTP_PNRT minimum value different from 0

CR625973_1: IP priority configuration in the BTS
CR631082_1: Asig over IP multi-homing in BSC
CR642194_2: change of T_TC_BTS_LINK_POLLING
OP2 closed: a POLO name has been added for all the 240 MFS
parameters (CAE changeable, instance <> adj) applicable to
LRC
Alignment with FR20/314331 : 170 (AA) changed into 165

(A5) for an AMR codec mode in AMR_FR_SUBSET
T_MAX_HOLD_MUXTRAUP : max value changed from 20 to 5
(due to TCIF constraint)
The following CR are included:

CR634935_2: Gb configuration in LRC
The following Changes are included:

EN_SPECIFIC_PM: block number removed from the internal
3BK 11203 0250 DSZZA
6/43

Ed.06 Released
2012/08/30
Gb over FR parameters: external added

TRAFFIC_MODE (_xxx) : RFC4666 added
The following CR are included:

CR627617_2: default values for PD_xL_TBF_VOLUME_THR
CR654547_1: L2 priority change
CR760812_2: PMO coding for 2G to 3G TDD cell reselection
CR764036_1: GAMMA_TNx default value
The following Changes are included:
- EN_DPVA: optional (per PA quantity) removed, as per TRX.
- The table GCD_Delta_BSS_Tel_B12_LRC is not generated
anymore (not needed)
- GB_ENDPOINT_IP_ADDRESS_1 history updated
TFD
table
B13:
PCU
function
into
BSC
=
GSM/SYS/APR/036782
- WI_PR and WI_PR_CPU_OVERLOAD: HMI names aligned on OMC
- TRAFFIC_MODE: parameter change aligned on SED method
(FR20/313132)
- NB_TS_MPDCH: clean up in mandatory of parameters for LRC
- EN_PREFERRED_BAND_FORCED_DR: reco QUEUE_ANYWAY
added
Ed.07 Released
2012/12/12
The following CR B12.2 are included:

CR742935_2: new GSL_LOSS_RESET_DATA as CDE
CR778797_2: EN_GB_FLEX from 8 to 16 SGSNSs
CR818335_1: T_DELAY_HP_COMMAND for HO AMR-FR to AMR-HR
CR820591_1: BSS_DL_MUXTRAUP_UDP_PORT parameter change
CR828204_1: Change of start IP address and BSC reset
The following changes are also included:
SUB_SAIC_BLACKLIST: up to 300 TACs removed (B12 limitation)
HMI name of EN_RMS_IMPROVED changed to EN_RMSI
Ed.08 released
2013/02/08
The following CR B12.2 Ed2 are included:

CR880927_1:T_DELAY_HO_COMMAND
CR883876_2: Ater GCH Equity deployment
The following CR B12.2 Ed3 are included:
CR665628_1: Inter-RAT cell reselection
CR841554_2: Enhanced. reported UL Interference measurement
CR860526_1: new default value for T(sst) (MX BSC)
CR875246_1: 4 CCCH - default paging rate at 245 p/s
CR893153_1: PMU cpu overload threshold (GP2 vs GP3)
CR899603_1: MSCR for G2 BSC
The following changes are also included:
T(sst) (G2 BSC) has been added
EN_INTFBD_PM is sent to the BTS in BTS_CONF_DATA
CELL_RESELECT_OFFSET is independent of cell type and BTS type
ED8 RELEASED

3BK 11203 0250 DSZZA
7/43

TABLE OF CONTENTS
INTERNAL REFERENCED DOCUMENTS................................................................................... 9
1 INTRODUCTION ........................................................................................................ 14
2 EXPLANATION OF THE TABLE ...................................................................................... 15

2.1 Logical name..................................................................................................... 15
2.2 HMI Name......................................................................................................... 16
2.3 Definition......................................................................................................... 16
2.4 Application domain............................................................................................. 16
2.5 Sub-system ....................................................................................................... 17
2.6 Instance........................................................................................................... 17
2.7 Category .......................................................................................................... 21
2.8 OMC-R access .................................................................................................... 22
2.9 Authorised constellations of Categories and OMC-R accesses ......................................... 24
2.9.1 Sub-system: BSC........................................................................................... 24
2.9.2 Sub-System: MFS .......................................................................................... 25
2.9.3 Sub-System: OMC ......................................................................................... 26
2.9.4 Sub-System: BTS .......................................................................................... 26
2.9.5 Sub-System: TC............................................................................................ 26
2.10 Cell Type dependent........................................................................................... 27
2.11 Nb TRX dependent ............................................................................................. 27
2.12 Type ............................................................................................................... 27
2.13 Unit ................................................................................................................ 28
2.14 Minimum value .................................................................................................. 29
2.15 Maximum value ................................................................................................. 30
2.16 Default value .................................................................................................... 30
2.17 Coding rules...................................................................................................... 31
2.18 Coded Min, Coded Default and Coded Max ................................................................ 31
2.19 Internal comments ............................................................................................. 32
2.20 External comments............................................................................................. 32
2.21 Mandatory and recommended rules ........................................................................ 33
2.22 Rec ref ............................................................................................................ 33
2.23 Feature ........................................................................................................... 33
2.24 Spec ref ........................................................................................................... 33
2.25 Migration rules .................................................................................................. 34
2.25.1 Sub-system: BSC........................................................................................... 34
2.25.2 Sub-System: MFS .......................................................................................... 35
2.25.3 Sub-System: OMC ......................................................................................... 36
2.25.4 Sub-System: BTS .......................................................................................... 36
2.25.5 Sub-System: TC............................................................................................ 36
2.26 CDE ASCII TABLE ................................................................................................ 37
2.27 CAE templates ................................................................................................... 38
3 GLOSSARY .............................................................................................................. 39
ED8 RELEASED

3BK 11203 0250 DSZZA
8/43

INTERNAL REFERENCED DOCUMENTS

Not applicable
REFERENCED DOCUMENTS
GSM References
[1]
3GPP TS 03.41
[2]
3GPP TS 03.49
[3]
3GPP TS 44.006
[4]
3GPP TS 44.008
Mobile radio interface - Layer 3 specification
[5]
3GPP TS 44.012
[6]
3GPP TS 44.060
Short Message Service Cell Broadcast (SMSCB) support on the

mobile radio interface
[7]
3GPP TS 45.002
Multiplexing and multiple access on the radio path
[8]
3GPP TS 45.008
Radio Subsystem Link Control
[9]
3GPP TS 48.006
[10]
3GPP TS 48.008
Signalling transport mechanism specification for the BSS-MSC

interface
[11]
3GPP TS 48.056
BSC-BTS interface - Layer 2 specification
[12]
3GPP TS 48.058
BSC-BTS Interface - Layer 3 specification
[13]
3GPP TS 48.060
[14]
3GPP TS 48.061
Inband control of remote transcoders and rate adaptors for

Enhanced Full Rate (EFR) and full rate traffic channels
ED8 RELEASED
Technical realisation of Short Message Service Cell Broadcast

(SMSCB)
Example protocol stacks for interconnecting Cell Broadcast

Center (CBC) and Base Station Controller (BSC)
MS-BSS interface data link layer specification
GPRS MS-BSS interface. RLC/MAC interface
MSC-BSS interface - Layer 3 specification
In-band control of remote transcoders and rate adaptors for

half rate traffic channels

3BK 11203 0250 DSZZA
9/43

CCITT/ITU References
[15]
CCITT Q.703 (Blue Book)
SS7 - Signalling link
[16]
SS7 - Signalling network functions and messages
[17]
SS7 - Testing and maintenance
[18]
SS7 - Signalling Connection Control Part procedures
[19]
ISDN user-network interface - Link layer specification
ED8 RELEASED

3BK 11203 0250 DSZZA
10/43

Proprietary documents
[20]
3BK 11202 0538 DSZZA
Handover preparation
[21]
3BK 11202 0495 DSZZA
Paging and access grant control
[22]
3BK 11202 0547 DSZZA
Radio and link establishment
[23]
3BK 11202 0533 DSZZA
Normal Assignment
[24]
3BK 11202 0488 DSZZA
Ciphering procedure
[25]
3BK 11202 0534 DSZZA
Call release
[26]
3BK 11202 0535 DSZZA
Channel modification
[27]
3BK 11202 0546 DSZZA
Classmark handling
[28]
3BK 11202 0108 DSZZA
Transparent message routing
[29]
3BK 11202 0062 DSZZA
Short Message Service point-to-point
[30]
3BK 11202 0551 DSZZA
Radio measurements
[31]
3BK 11202 0553 DSZZA
DTX functional specification
[32]
3BK 11202 0552 DSZZA
Radio measurements data processing
[33]
3BK 11202 0535 DSZZA
Power control and radio link supervision
[34]
3BK 11202 0421 DSZZA
BSS Overload control
[35]
3BK 11202 0173 DSZZA
Protocol error handling
[36]
3BK 11202 0069 DSZZA
FB Management of Trace Services
[37]
3BK 11202 0451 DSZZA
BSS initialisation of the telecom part
[38]
3BK 11202 0416 DSZZA
BSS Global reset
[39]
3BK 11202 0539 DSZZA
Reset circuit and blocking and unequipped circuit
[40]
3BK 11202 0388 DSZZA
Frequency encoding algorithm
[41]
3BK 11202 0329 DSZZA
Short Message Service Cell Broadcast
ED8 RELEASED

3BK 11203 0250 DSZZA
11/43

[42]
3BK 11202 0548 DSZZA
LAPDm functional specification
[43]
3BK 11202 0505 DSZZA
System Information Management
[44]
3BK 11202 0545 DSZZA
TC/BTS Interface (TDM and IP modes)
[45]
3BK 11202 0330 DSZZA
Abis Signalling Link Multiplexing
[46]
3BK 11202 0464 DSZZA
LapD Management
[47]
3BK 11202 0549 DSZZA
Resource allocation and management
[48]
3BK 11202 0537 DSZZA
Handover management
[49]
3BK 11202 0536 DSZZA
External channel changes
[50]
3BK 11202 0541 DSZZA
Internal channel changes
[51]
3BK 11206 0313 DSZZA
BSC Data Dictionary
[52]
3BK 11204 0035 DSZZA
OMC-BSS MIB specification
[53]
3BK 11204 0034 DSZZA
O&M coding rules
[54]
3BK 11202 0527 DSZZA
(E)GPRS Radio interface - RRM Sublayer (PRH)
[55]
3BK 11202 0496 DSZZA
(E)GPRS Radio interface - RRM Sublayer (PCC)
[56]
3BK 11202 0507 DSZZA
(E)GPRS MFS-BSC interface - BSCGP Layer
[57]
3BK 11202 0261 DSZZA
(E)GPRS MFS-BSC interface - GSL Stack
[58]
3BK 11202 258 DSZZA
(E)GPRS Gb interface - Network Service Control Sublayer

(Gb over FR)
[59]
3BK 11202 259 DSZZA
(E)GPRS Gb interface - SubNetwork Service Sublayer

over FR)
[60]
3BK 11202 0467 DSZZA
(E)GPRS MFS-BTS interface - MEGCH stack
[61]
3BK 11202 0526 DSZZA
(E)GPRS Radio interface - MAC Sublayer
[62]
3BK 11202 0525 DSZZA
(E)GPRS Radio interface - RLC Sublayer
[63]
3BK 11202 0506 DSZZA
(E)GPRS Gb interface - BSSGP Layer
ED8 RELEASED
(Gb

3BK 11203 0250 DSZZA
12/43

[64]
3BK 11203 0170 DSZZA
GPRS traffic model and capacity
[65]
3BK 11202 0485 DSZZA
TFO Functional Specification
[66]
3BK 11202 0482 DSZZA
GPU Overload and CPU Power Budget Management
[67]
3BK 11206 0921 DSZZA
NPO/RNP POLO LOGICAL PARAMETER FILE INTERFACE
[68]
3BK 11202 0459 DSZZA
(E)GPRS Gb over IP interface - Network Service Control

Sublayer
[69]
3BK 11202 0461 DSZZA
IPGCH, MFS BTS interface on IP
[70]
3BK 11202 0509 DSZZA
TC/BSC Interface over IP
RELATED DOCUMENTS
None
PREFACE
None.
ED8 RELEASED

3BK 11203 0250 DSZZA
13/43

INTRODUCTION
The aim of this document is to provide complete information for Telecom system parameters
implementation.
This document provides for each parameter: its accessibility, its instantiation, its allowed logical values and
its possible relationships with other parameters. The coding of the parameters is indicated wherever it is
relevant.
In the main part of the document, parameters have been grouped by sub-system (BSC, BTS, MFS and
transcoder), and are listed in alphabetical order.
Default values for parameters depending on the type of cell or on the number of TRX are given at the end of
the document, before the index.
Coding rules reflect the coding of the parameters in the external interfaces (when applicable). This coding
shall be respected as far as possible in the internal interfaces.
However, if the coding of the internal interface is different from what is expressed in the coding rule (i.e.
the external interface), the min., max. CODED values that are additionally indicated in the BSS telecom
parameters catalogue will reflect the internal values.
NB : with the introduction of the BSS over IP feature, several parameters have been introduced, and with
them the question about their catalogue, BTP or BOP ? It has been decided to add the new parameters
(addresses, ports, timers, thresholds) in the right catalogue according to their related protocol: in the
BOP for the O&M protocol (OML, TCSL, BSC O&M, MFS O&M) and in the BTP for the telecom protocol (RSL,
IPTCH, IPGCH, Asig, A user plane, GSL). This rule is not retroactive.
NB: From B12, the new parameters are applicable to Evolution products only.
NB: Inside a B12 network, the parameters of a legacy MFS are not described in the present B12 BTP, but in
the B11 one. But for the BSC G2, on contrary to the MFS, their parameters are described in the present
B12 BTP, because a G2 BSC of a B12 network offers a B12 interface; although it remains internally with a
B11 functionnal level. When some restrictions or specific behaviors are required, they are described in the
present B12 BTP.
ED8 RELEASED

3BK 11203 0250 DSZZA
14/43

EXPLANATION OF THE TABLE
This section gives a short explanation for each field describing the parameters.
The complete description of parameters is given in the file 0250_xxa.doc. The parameters are sorted by
sub-system, and then in alphabetical order.
2.1 Logical name

Definition:
Name of the parameter as used in the system specifications.
Constraints:
- Mandatory
- Upper case string with length < 100 characters
- Square brackets ([ and ]) are allowed only for describing the element of an array
- semi-colons (;) are not allowed.
- Hyphens (-) shall be avoided (use _ instead)
- name beginning with number (ie. 0..9) is forbidden (due to MIB constraint)
Some parameters are duplicated in BSC and MFS. In this case, the NE concerned is indicated between
brackets at the end of the name.
Note that from the OMC point of view, there is only one parameter, whose value is sent to BSC and MFS.
Note: agreed naming rule, applicable to the system (CST) dimensioning parameters of the MFS:
- Such parameter is named xxx_GP3 when a specific value is applicable to boosted GP board (ie. GP3)
only.
- Such parameter is named (or renamed in case xxx_GP was existing in B11) xxx_GP2 when a specific
value is applicable to old GP board (ie. GP2) only.
- Such parameter is named xxx_GP when a common value is applicable to both boards, boosted GP and
old GP (ie. GP2 and GP3). In such case, it may happen that the new following DSP/PTU naming
convention is not followed (DSP remaining, as inherited from the previous release)
In addition, depending on the processor where the PTU/SW is hosted, the following DSP/PTU additionnal
naming rule applied:
- In IP mode:
PTU/SW is hosted in the BTS on a TRE (either G3/G4/G5/MC), and _PTU_xx_IP_ is included in the name
(DSP replaced by PTU_xx_IP).
- In TDM mode:
On GP3,the RLC/MAC part of the PTU is hosted on the multicore processor (and the MEGCH part of the
PTU is still on the DSP), then _PTU_ is included in the name (DSP replaced by PTU) when the parameter
value comes from a limitation of the RLC/MAC part .
On GP2, the PTU/SW is hosted on the DSP, then _DSP_ is included in the name; but DSP is then replaced
by PTU in order to keep the same prefix as GP3 one (PTU is more generic than DSP).
ED8 RELEASED

3BK 11203 0250 DSZZA
15/43

2.2 HMI Name

Definition:
If the parameter is to be displayed at OMC-R, the name that shall appear on the OMC-R screen is
given in the field HMI name.
Constraints:
- Optional
- String with length < 100 characters
- Square brackets ([ and ]) and semi-colons (;) are not allowed.

In some case, an empty HMI name is allowed, e.g. for the flag parameters whose value is displayed as an
on/off button; the button itself has no name, only the value is displayed.
2.3 Definition
Definition:
Textual definition of the parameter.
Constraints:
- Mandatory
- String with no length constraint
2.4 Application domain

Definition:
This field indicates if the parameter is related to GPRS (GSM packet) or to GSM circuit.
Constraints:
- Mandatory
- Values are limited to the following list:
Table : Domains
ED8 RELEASED
Code
Meaning
GSM
Needed for GSM circuit

3BK 11203 0250 DSZZA
16/43

GPRS
Needed for GSM packet (GPRS)
E-GPRS
Needed for GPRS on EDGE
2G-3G
Needed for 2G-3G Inter-working
LCS
Needed for LCS
VGCS
Needed for VGCS-eMLPP
IP
Needed for all topics on IP (eg. IP

transport in the BSS, Gb over IP, A
signaling over IP, Aflex, GBflex )
DTM
Needed for Dual Transfer Mode
2G-LTE
Needed for 2G-LTE Inter-working
2.5 Sub-system
Definition:
This field indicates which sub-system uses the parameter.
Constraints:
- Mandatory
BSC : even for the parameters used by the BTS and which are sent by the BSC to the BTS (via
RSL or OML).
BTS
MFS
TC
OMC
2.6 Instance
Definition:
Instance of the parameter.
Constraints:
- Mandatory
ED8 RELEASED

3BK 11203 0250 DSZZA
17/43
ED8 RELEASED
3BK 11203 0250 DSZZA
18/43


Table : Instances
Instance
Meaning
cell
there is one instance of the parameter for each cell
adj
there is one instance of the parameter for each

declared adjacent cell
3G cell
BTS
BSS
BSC
MFS
there is one instance of the parameter for each 3G

cell
there is one instance of the parameter for each BTS
the parameter could have been defined on a per cell

basis, but, as its value shall be the same for all the
cells in the BSS, there is only one instance of the
parameter for the BSC
there is one instance of the parameter for the BSC.
In pure GSM, the BSC is responsible for the CS

application
In converged LightRadio, the BSC managed both CS

and PS applications
there is one instance of the parameter for the PCU
function.
In the pure GSM, it represents the MFS.
MSC
BC
BSCproc
In the converged LightRadio, it is still used just for

the parameters inherited from the GSM, the instance
BSC shall then be preferred for the LR parameters.
there is one instance of the parameter for each MSC,
connected to the BSC.
Frame Relay Bearer Channel in the MFS.
This instance name is not relevant in LightRadio.

processor in the BSC (i.e. each TCU, CPR, PMU or PCU
instance, and DTC)
TRAU
there is one instance of the parameter for the TRAU
TRX
there is one instance of the parameter for each TRX
ACH
there is one instance of the parameter for each A

interface circuit
Trunk
N7ch
OMC
GPU
there is one instance of the parameter for each A

trunk
there is one instance of the parameter for each N7
signalling link
there is one instance of the parameter for the OMC-R

(and possibly all the BSS managed by this OMC-R)
there is one instance of the parameter for each GPU

(or GP) in MFS.
This instance name is not relevant in LightRadio.
ED8 RELEASED

3BK 11203 0250 DSZZA
19/43

BVC
DSP
PDCH
PDCH group
PVC
Abis link
Abis segment
Abis group
SCTP EndPoint
IP-GSL
There is one instance of the parameter for each BVC
There is one instance of the parameyet for each DSP

in the MFS.
This instance name is not relevant in LightRadio
There is one instance of the parameter for each PDCH
There is one instance of the parameter for each PDCH

group
There is one instance of the parameter for each PVC
PCM link on Abis interface
There is one instance of the parameter for each

segment
There is one instance of the parameter for each Abis

group.
An Abis group (or Abis BTS group, or Telecom Abis
group) is defined as follows :
if IPoEthernet, it corresponds to the O&M Abis
group (this corresponds to an integer number
of cells),
if IPoE1, with a 1-Abis BTS : set of BTSs
connected on this E1 (! This does not
correspond to an integer number of cells due
to cell shared),
if IPoE1, with a 2-Abis BTS: the BTS
connected on these two E1. (! This does not
correspond to an integer number of cells due
to cell shared). The bandwidth is the sum of
the bandwidth provided by each E1.
The telecom Abis group does not exist for BTS
connected on an Abis TDM.
Termination of one SCTP association, of one ASL (A

Signalling Link) in either the BSC or the MSC. One
SCTP association is an association between two IPSPs
(IP Server Process) of two different AS (Application
server, a BSC is an AS, a MSC is also an AS)
It represents the GSL link (ie the TCP connection)

between the BSC and the MFS in IP mode. There is
one such link per GP.
This instance name is not relevant in LightRadio,

where the interface between CS and PS applications
is an internal interface of the LRC)
ED8 RELEASED

3BK 11203 0250 DSZZA
20/43

NSE
There is one instance of the parameter for each NS

entity in the PCU function. The NSE on PCU side and
the peer NSE on SGSN side have both the same
identifier across the Gb interface.
In the MFS, one NSE is defined per GP/GPU for each
SGSN connected to the BSS.
SGSN-IPEndPoint
IPEndPoint
LTE cell
In the PCU, one NSE is defined per PMU for each SGSN
connected to the BSS
IP endpoint defined on the SGSN side for GboIP: An IP

endpoint is defined by its IP address and UDP port.
In case of static configuration, an SGSN IP endpoint
can be a data endpoint and/or a signalling endpoint.
There is one instance of the parameter for each SGSN
IP endpoint.
In case of dynamic configuration, an SGSN IP endpoint
is used to exchange the configuration with the SGSN.
It is a pre-configured IP endpoint in this case. There
is one instance of the parameter for each preconfigured IP endpoint.
Generic instance representing the termination point
in a network element, used either for signalling or for
traffic usage. It has been first introduced for
modelling the Gb endpoints, on remote SGSN side and
on local LRC side.
there is one instance of the parameter for each LTE
cell
Note that for all parameters per adjacency, the OMC does not verify the mandatory rules. For these
parameters, the OMC only verifies that the value corresponds to the one of the target cell.
2.7 Category
Definition:
This field indicates if each instance of a parameter may take the same value throughout the
network, or if there is the necessity for different instances to take different values. It also shows the
nature of the changeability of the parameter by operator procedures.
Constraints:
- Mandatory
ED8 RELEASED

3BK 11203 0250 DSZZA
21/43

Config.
SITE (CAE)
Network (CDE)
System (CST)
Meaning
(Customer Application Engineering parameter).
Parameter which can be different from one
instance to another instance (e.g. cell to cell or
from BSC to BSC or from MFS to MFS)
(Customer Design Engineering parameter).
Parameter which can be specific for a customer
and valid for the complete network (even if that
network is composed of several own PLMNs).
Constant data. Parameter that cannot or shall not
be modified by the operator (This parameter can
be hard coded or defined in a config file read at
the NE restart. It is not known by the operator)..
2.8 OMC-R access

Definition:
Indicates how the parameter is handled by the OMC-R.
Constraints:
- Mandatory
Config.
None (DLS)
None
(DLS & Restricted)
None (not in DLS)

Changeable
ED8 RELEASED
Meaning
the parameter is present in the BSC or MFS
database, but not in the BSS-OMC interface
(MIB). As a consequence, its modification
requires a data base reload.
The parameter is present in the BSC database,

but not managed by the operator (neither from
the OMC, nor from the BSC terminal). So, not
present in GCD tables. It is manageable by
Alcatel-Lucent team only, from BSC terminal
with a restricted access.
Hard coded parameters, can not be modified

database and in the BSS-OMC interface (MIB). It
is modifiable from the OMC-R.
OMC
parameters
that
are
marked
as
changeable are local parameters at the OMC,
changeable by the operator. Used to compute
parameters sent to the BSC and/or MFS.
3BK 11203 0250 DSZZA
22/43

Config.
Meaning
Displayed

database and in the BSS-OMC interface (MIB) but
is only displayable at the OMC-R. As a
consequence, its modification requires a data
base reload.
OMC
parameters
that
are
marked
as
displayed are local parameters at the OMC, only
displayed to the operator. Used to compute
parameters sent to the BSC and/or MFS.
Virtual, Displayed
Virtual, Changeable
Set by create
Set by create and

changeable
ED8 RELEASED
the parameter is virtual, it is deduced by the

OMC-R from other parameters. It is displayed.
BSC/MFS parameters that are virtual
displayed are computed by the OMC from a local
displayed OMC parameter, and given to the
BSC/MFS.
the parameter is virtual, it is deduced by the

OMC-R from other parameters. It is changeable.
BSC/MFS
parameters
that
are
virtual
changeable are computed by the OMC from a
local changeable OMC parameter, and given to
the BSC/MFS.
database and in the MIB. Its value is set during
the creation of the relative object and can not
be modified afterwards.

database and in the MIB. Its value is set during
the creation of the relative object and can be
modified afterwards.
OMC local display
the parameter is not in the DLS nor in the MIB.

Its default value is used locally by the OMC-R for
display purposes or to populate other parameters
Virtual (DLS)
The parameter is present in a sub-system

database, is transmitted on the interface with
the OMC but not displayed by the OMC.

3BK 11203 0250 DSZZA
23/43

2.9 Authorised constellations of Categories and OMC-R accesses

Definition:
Among all possible constellations only the ones listed in the tables below are permitted. They depend
on the sub-system (e.g. BSC, MFS). The tables below indicate also the consequences in terms of
migration and if the value of a parameter of such a kind can be modified / customised.
2.9.1
Sub-system: BSC
Category
System(CST)
OMC-R access
Changeable
None (DLS)
NO
Migration
NO
comments
In DLS
None (not in DLS)
Parameter hard
coded
Displayed
Network(CDE)
None (DLS)
Value can be
customised
at
initialisation via
the CDE-table.
NO
(Migration
only
in
extraordinar
y cases)
Value
not
changeable, but
default
value
might
be
customised
via
the CDE-table if
it is a new
parameter.
Yes
(DLS
migration)
Yes
Yes
No
Yes
(DLS
migration)
Virtual
changeable
Value might be
changed
by
changing value(s)
of
the
parameter(s) it is
depending on.
Yes
Virtual (DLS)
No
No
Set by create
Displayed
Site (CAE)
None(DLS)
Displayed
Changeable
None (DLS
restricted)
&
Parameters
depending
on
the
type
of
connected MSC
Yes
Access restricted
to
Alcatel
Lucent team
See 2.25.1 for more detail about the migration rules of BSC parameters.
ED8 RELEASED

3BK 11203 0250 DSZZA
24/43

2.9.2
Sub-System: MFS
Category
System(CST)
OMC-R access
Changeable
Migration
Network(CDE)
None (DLS)
None (not in DLS)
None (DLS)
Site (CAE)
Set by create
Default value is
set by OMC or
the
MFS
at
creation of the
corresponding
instance.
Yes.
Displayed
Depending
the case
Depending
on the case
Changeable
Yes
ED8 RELEASED
NO
NO
Value might be
customised
via
BUL files
by MFS
on
Yes.
OMC
migrates
radio
data
(via
reinit+resynchro) that
are present
at
OMC/
MFS itf.
MFS
migrates
ater/ Gb/ HW
data
(via
data
conversion
scim)
that
are present
at
OMC/
MFS itf.
comments
In MFS data base

Hard coded
No
real
migration, since
the
value
is
customized (so
no
rule
is
specified in the
BTP)
the owner of
the
object
instance is also
responsible for
the migration of
the
related
parameters.
For example: a
parameter that
is calculated by
the MFS and
displayed
at
OMC cannot be
customised and
will
not
be
migrated by the
OMC of course.
The
migration
type, specified
in the BTP, gives
the sub-system
responsible for
the migration of
the parameter
value:
- in case of new
parameter: for
the initialisation
with the default
value;
- in case of old
parameter: for
the application
of the specified
migration rule

3BK 11203 0250 DSZZA
25/43

Virtual
changeable
None (DLS)
Value might be
changed
by
changing value(s)
of
the
parameter(s) it is
depending on
Default value is
set by the MFS
Yes
By MFS
Parameter
unknown
from
the OMC
See 2.25.2 for more detail about the migration rules of MFS parameters.
2.9.3
Sub-System: OMC
Category
Site (CAE)
2.9.4
OMC-R access
Changeable
Changeable
Yes
Migration
Yes
Comments
No
migration
rules defined in
the BSS telecom
parameters
Sub-System: BTS
Category
OMC-R access
Changeable
Migration
Comments
System (CST)
None (not in DLS)
No
No
Hard coded
Network (CDE)
None (not in DLS)
No
No
Parameter
configured
FU.CPF file
Site (CAE)
None (not in DLS)
No
No
Depending
on
the case (FU.CPF
file or deduced
from
another
parameter)
2.9.5
via
Sub-System: TC
Category
System (CST)
ED8 RELEASED
OMC-R access
None (not in DLS)
Changeable
No
Migration
No
Comments
Hard coded

3BK 11203 0250 DSZZA
26/43

2.10 Cell Type dependent

Definition:
This field indicates if the default value depends on the cell type. If yes, these default values shall be
given in a specific table.
Constraints:
- Mandatory (default = no)
- Possible values: No, Yes
2.11 Nb TRX dependent

Definition:
This field indicates if the default value depends on the number of TRX in the cell. If yes, these
default values shall be given in a specific table.
Constraints:
- Mandatory (default = no)
- Possible values: No, Yes
2.12 Type
Definition:
Describes the type of the parameter.
Constraints:
- Mandatory
ED8 RELEASED
Type
Description
Flag
Flag : mainly used to

enabled/disabled a feature, a
mechanism.
Like a boolean, can be set to 0 or 1
Timer
Timer
Threshold
Threshold
Number
Number

3BK 11203 0250 DSZZA
27/43

Reference
Unique identifier of an object

instance
List of numbers
List of numbers composed of several

number, like an array of number
Abstract
parameter
Abstract parameter
An abstract parameter results from
the combination of several
parameters (like a structure)
Bitmap
List of bits, where each of them can

be set to 0 or 1
IP address
IP address or IP subnet mask, coded

on 15 characters string,displayed by
the OMC following the format
www.xxx.yyy.zzz
(ex: 255.245.247.001)
Enumerated
Number which is one of a predefined

and fixed list (of numbers)
2.13 Unit
Definition:
Unit of the parameter.
Constraints:
- Mandatory.
Table : Units
ED8 RELEASED
Unit
Meaning
None-
No unit
byte
byte
kbit
kbit
kbit/s
kbit/s
mn
minute
second
3BK 11203 0250 DSZZA
28/43

ms
millisecond
percent
dB
dB
dBm
dBm
SAmfr
SACCH multiframe duration

it corresponds to about 471.1 ms on SDCCH
and to about 480.4 ms on TCH
2xSAmfr
Two time SACCH multiframe duration

it corresponds to about 942.2 ms on SDCCH
and to about 960.8 ms on TCH
51mfr
51 frames multiframe duration

it corresponds to about 235.6 ms
bper
bit period
it corresponds to 48/13 s,
and a distance of about 550m
CBper
Cell Broadcast period duration

it corresponds to the duration of 8 x 51
frames multiframe, namely about 1.88 s
kbyte
kbyte
km
km
ppb
Parts per billion (1ppb = 1E-9)
2.14 Minimum value

Definition:
Minimum value of the parameter.
Constraints :
- Mandatory
ED8 RELEASED

3BK 11203 0250 DSZZA
29/43

- Numerical value: integer or floating point

- Same format is used for Minimum value, Maximum value and Default value fields.
2.15 Maximum value

Definition:
Maximum value of the parameter.
Constraints:
- Mandatory
- Numerical value: integer or floating point
2.16 Default value

Definition:
Default value of the parameter.
If the value depends on the configuration, the default value shall be given for a normal GSM900 cell,
with terrestrial A-bis link. If this value is still not precise enough, the default value given in the DLS
or in the MIB shall be indicated here. The values to be applied, depending on the configuration shall
be written in the field External comments. (# has been used, in the past, when no default value
can be specified as the value of the parameter depends on the configuration. This special character
may still be encountered).
When the default value is accompanied by a '*' character, this means that the parameter is always
populated with that default value and the operator is not allowed to modify the parameter, even if
the parameter is declared as OMC-changeable.
When no default value can be defined, because the parameter value depends on the customer
network configuration (like for distant IP address and port which usually have to be customized by
the customer), the corresponding default value is specified as None. In case of list of parameters
which elements have to be customized by the operator, the empty list (meaning length = 0) is used
(and preferred, when possible, to the list with one dummy element).
Sometimes, for implementation purpose a coded default value may be needed even if no default has
been defined previously (see 2.18 for more details).
Constraints:
- Mandatory
- Numerical value : integer or floating point or None
ED8 RELEASED

3BK 11203 0250 DSZZA
30/43

2.17 Coding rules

Definition:
indicates, as far as system is concerned, how the parameter value is coded.
If this column is empty, it implicitly means that the step size between two consecutive values is 1.
Coding rules reflect the coding of the parameters in the external interfaces (when applicable). This
coding shall be respected as far as possible in the internal interfaces.
When a coded default value is needed for implementation purpose, that dummy/particular value is
indicated in the present field.
Constraints:
- Optional
- String with no length constraints
2.18 Coded Min, Coded Default and Coded Max

Definition:
Coded Min indicates coded value of minimum value of parameter (see 2.14).
Coded_default indicates coded value of default value of parameter (see 2.16), or is empty.
Coded Max indicates coded value of maximum value of parameter (see 2.15).
Remark: the coded values (Coded Min, Coded_default and Coded Max) describe how the parameter is
coded inside the software. The coded value may be different than its corresponding real value: for
example, the (real) minimum value of MAX_GPRS_CS is 2 (means CS-2) and its Coded Min is 1 (coded
in two bits: 01).
When the default value is None, for implementation purpose, a coded default value may be
specified (e.g. a coded default value may be needed when the relative object is created before the
operator customized the parameter value) or not (e.g. the parameter is mandatory at the object
creation time). In case of not empty coded default value, the OMC shall not display that dummy
coded default value and highlight the missing configuration to the operator. Two ways may be used
to define, in the BTP, that dummy value: 1) that value is defined outside the coded range of validity
(but is included in the MIB); or 2) that value is defined inside the coded range of validity, which has
been extended with that particular value included.
Constraints:
- Mandatory
- Coded value shall conform to the coding rules (2.17).
ED8 RELEASED

3BK 11203 0250 DSZZA
31/43

2.19 Internal comments

Definition:
This field contains any additional comments relevant for the parameter, for internal use.
Constraints:
- Optional
- Semi-colons (;) are not allowed.
The internal comment is also used to map the parameters on to the MRs of the release. For exemple:
a new parameter, introduced in MR1 (ie not present in MR0), will be tagged This parameter is a
MR1 parameter.
an old parameter, removed from MR1 (but still present in MR0), will be tagged This parameter is
not relevant from MR1
a parameter, existing from the first MR of the release (either coming from previous release or
linked to a new feature supported from the first MR of the relase) will not be tagged
The extraction of the customer parameters managed by GCD is based on this tag. Nothing prevents the
other subsystems to use it, if needed.
2.20 External comments

Definition:
This field may contain further explanations about the parameter (use, configuration, if the
parameter change has any impact on the telecom service, if an operator action is required before or
after any parameter modification...).
If the default value of the parameter depends on the configuration, this shall be specified here
(Default value given in the default value field is for implementation purposes only).
The parameter may depend on MSC type, operator...
Constraints:
- optional
- string with no length constraints
- semi-colons (;) are not allowed
ED8 RELEASED

3BK 11203 0250 DSZZA
32/43

2.21 Mandatory and recommended rules

Definition:
indicates possible relationship rules with other parameters and whether these rules are
recommended or mandatory
Remark: mandatory rules have to be checked by the relevant entities (OMC-R, DLS population tools,
etc.).
Recommended rules are purely informative and shall not be checked (because the check cannot be
performed due to unavailability of the value or the check is not required for a pure
recommendation).
Constraints:
- Optional
2.22 Rec ref

Definition:
This field indicates, if applicable, in which GSM recommendation or ITU-T recommendation the
parameter is specified.
Constraints:
- Optional
2.23 Feature
Definition:
This field indicates the feature the parameter is related to. It usually refers to the SFD (or the RFD)
that first introduced this parameter.
Constraints:
- Optional
2.24 Spec ref

Definition:
This field indicates, if applicable, the doctree document in which the parameter is specified.
Constraints:
ED8 RELEASED

3BK 11203 0250 DSZZA
33/43

- Optional
2.25 Migration rules

For the parameters applicable to LRC, the sub-system can be either the BSC (for CS parameters or specific
PS parameters, not inherited from the MFS) or the MFS (for PS parameters inherited from the MFS). As
consequence the two following sections are still relevant for Light radio, depending on the inheritance of
the concerned parameter.
2.25.1 Sub-system: BSC
Only the parameters present in the DLS may be migrated by the BSC OEF tool from an old release to a
new release (the OMC uploads the migrated values during the audit phase following the migration).
The present table summarizes the migration rules defined in the BTP, according to category of the
parameter.
Category
System (CST)
Network (CDE)
Site (CAE)
Present
in Old Rel
Present
in New Rel
Migration
Type
Old -> New
No
Yes
None
Not applicable
Yes
Yes
None
Not applicable
No
Yes
None
Not applicable
Yes
Yes
None
(note1)
Not applicable
No
Yes
None
(note2)
Not applicable
Yes
Yes
OEF migration for

BSC parameters
Value of previous
release
OR
Explicit rule
(note3)
Note1: Migration by OEF may happen only in extraordinary cases

Note2: The term migration is not applicable to the new parameters introduced in the New release. There
is no migration performed by OEF for such parameters, which can be customized by the operator in the
CDE table, which content is used to initialize the new parameters. For some parameters, like the IP
addresses or the TCP/UDP ports, parameters closed to the HW network configuration, the default value
present in the BTP is meaningless. As consequence, those parameters are not included in the CDE table.
Note3: The explicit rule generally involves parameters present in the Old release.
An explicit rule is also specified when several migration paths (coming from different MR of the Old
release) are existing
ED8 RELEASED

3BK 11203 0250 DSZZA
34/43

When a mandatory rule is added in New release, an explicit rule may be required in order to ensure that
that new mandatory rule is fulfilled for any valid value (customized or changed by the operator) used in
the previous Old release.
2.25.2 Sub-System: MFS
The Site (CAE) MFS parameters are either migrated by the OMC or by the MFS itself.
Of course, a parameter could be migrated by the OMC, only if it is OMC changeable by the OMC, ie:Site
(CAE) and <> None and <> Displayed
The MFS considers two types of CAE parameters:
The parameters with (BSS, or Cell or Adj) as instance: these parameters are migrated by the OMC,
which then downloads the migrated value into the MFS. In the past, they were used to be
identified as related to the radio domain, but the applicable domain has been enlarged to other
domains (like Gb, Gb flex, ); so now on, they are identified by their related object instance,
which is persisted by the OMC between different releases.
The parameters with other instance (like PVC, NSE, IP-GSL,): the others site (CAE) parameters
are migrated by the MFS itself and then the OMC uploads then the migrated values
The present table summarizes the migration rules defined in the BTP, according to category of the
parameter.
Category
System (CST)
Network (CDE)
Site (CAE) +
Not OMC
changeable
OR
Present
in Old Rel
Present
in New Rel
ED8 RELEASED
Old -> New
No
Yes
None
Not applicable
Yes
Yes
None
Not applicable
No
Yes
None
Not applicable
Yes
Yes
None
No
Yes
Migration of new
Bx MFS parameters
by the MFS
(note2)
New default value

OR new coded
default value
Yes
Yes
Migration
of
common Bx-1/Bx
MFS parameters by
the MFS
Value of previous
release
Migration of new
Bx MFS parameters
by the OMC (note2)
New default value

OR new coded
default value
Site (CAE) + OMC

changeable +
<>(BSS/Cell/Adj)
Site (CAE) + OMC
changeable
+
=(BSS/Cell/Adj)
Migration
Type
No
Yes
(note1)
Not applicable
OR
Explicit rule
(note3)

3BK 11203 0250 DSZZA
35/43

Yes
Yes
Migration
of
common Bx-1/Bx
MFS parameters by
the OMC
Value of previous
release
OR
Explicit rule
(note3)
Note1: At each New release, a new customer BUL fiel is generated by the MFS. The values of the Old file
are not migrated.
Note2: We cannot talk about real migration for new parameters, but rather about initialisation with the
default value (when any is defined) or with the coded default value (when no default value is specified in
the BTP, because the value is customer network dependent, like the bases for IP addresses and for
TCP/UDP ports). As soon as a parameter is initialized by a sub-system (OMC or MFS), it is used to be
migrated also by that sub-system in the next release.
Note3: The explicit rule generally involves parameters present in the Old release.
An explicit rule is also specified when several migration paths (coming from different MR of the Old
release) are existing
When a mandatory rule is added in New release, an explicit rule may be required in order to ensure that
that new mandatory rule is fulfilled for any valid value (customized or changed by the operator) used in
the previous Old release.
2.25.3 Sub-System: OMC
No migration rules defined in the BSS telecom parameters
2.25.4 Sub-System: BTS
No parameter is migrated, since none is in the DLS.
2.25.5 Sub-System: TC
No parameter is migrated, since none is in the DLS.
ED8 RELEASED

3BK 11203 0250 DSZZA
36/43

2.26 CDE ASCII TABLE

The flag CMA script within the O&M detailed information table ("O&Mdetailed") allows to indicate if the
parameter shall be included in the CDE ASCII table. In this table, each parameter is identified by its
(logical) name (as defined in 2.1).
The CDE ASCII table shall contain:
all BSC CDE parameters of a given release
all NEW BSC CAE parameters of a given release with the following exceptions:
1.
2.
3.
Parameters such as cell or sub-system identifiers SHALL NOT be included in the list;
Parameters enables / disables a new feature SHALL NOT be included in the list.
Parameters in DLS and Restricted
When the default value is defined to None, the CDE table contains the corresponding coded default
value (ex: the parameters that shall be initialized by the operator, and for which a default value is
meaningless).
ED8 RELEASED

3BK 11203 0250 DSZZA
37/43

2.27 CAE templates

Only the BSC parameters of the category "Site(CAE)" are concerned (except the DLS & Restricted ones),
defined at BSC, BSS or cell level.
There are 8 templates for cell parameters and one template for BSS parameter:
The table "CAE_Templates"' defines the contents of the following eight CAE template files: sel, pag, hpc,
hoc, chc, dir, rrm, gpr and bss. The contents of the CAE template "chc" is defined by the table called
"CAE_template_CHC_info".
Templates are used for initial DLS construction (via Polo) and on OMC for cell creation.
The information given in these tables are in line with the specification: "RNO/RNP POLO LOGICAL
PARAMETER FILE INTERFACE".
In these tables, each parameter is identified by its POLO name.
The range of values (and default value, if present) is the one, the operator used to manage, ie the one
described in 2.14 and 2.15 (of the general sheet of the access database).
NB : when the coded range (2.18) is different, POLO shall perform the required translation, according to
the coding rule (2.17).
When using Polo, a parameter can be populated in the BSC with 2 main different ways:
-on a per instance basis: the operator defines the value per object (eg per cell). There is only a subset of cell
parameters managed in this way. Those parameters are qualified as 'cell design' parameters,
- via CAE template .
Additionally, there is the possibility to define 'exceptions' applied on top of the templates.
The criteria to set a parameter in a CAE template file follow:
-The parameter shall have a default value, which is meaningful (different of "None" and a value really
significant for the customer).
Usually, feature activation flags do not fulfill that criteria; for them the cell design way is advised.
Addresses, frequencies, neighboring cells... are not part of templates.
- The advised default value shall be meaningful for several cells (either valid for all cells of the BSS or
valid for some types of cell, or some frequency ranges). Thresholds, timers used in algorithms are
generally part of CAE templates.
If the value is really cell specific (different values in different cells), the other way is advised.
ED8 RELEASED

3BK 11203 0250 DSZZA
38/43

GLOSSARY
AGCH
Access Grant CHannel
ARFCN
Absolute Radio Frequency Channel Number
BCCH
Broadcast Control CHannel
BLKS
BLocKS
BSC
Base Station Controller
BSCGP
BSC GPRS Protocol
BSS
Base Station Subsystem (BSC+n*BTS)
BTS
Base Transceiver Station
CCCH
Common Control CHannel
CHAN.
Channel
CND
Configuration Data
CRC
Cyclic Redundancy Check
CS
Circuit Switched
DPC
Destination Point Code
DTX
Discontinuous Transmission
FACCH
Fast Associated Control Channel
GPRS
General Packet Radio Service
GSL
GPRS Signalling Link
IE
Information Element
LAPD
Link Access Procedure on the D-channel
LCS
LoCation Services
LR
Light Radio
LRC
LR Controler/Cloud element
LSB
Less Significant Bit
MFS
Multi-Function Server (GPRS)
ED8 RELEASED

3BK 11203 0250 DSZZA
39/43

MSB
Most Significant Bit
MSC
Mobile Switching Centre
MTP
Message Transfer Part
NA
Not Applicable
OIE
Optional Information Element
OML
Operations and Maintenance Link
OPC
Originating Point Code
PCH
Paging Channel
PCU
Packet Control Unit
PS
Packet Switched
RACH
Random Access CHannel
RRM
Radio Resource Management (GPRS)
RSL
Radio Signalling Link
RX
Receiver
SACCH
Slow Associated Control CHannel
SCCP
Signalling Connection Control Part
SCH
Synchronisation CHannel
SDCCH
Stand alone Dedicated Control CHannel
SMSCB
Short Message Service Cell Broadcast
SPI
Signalling Point Inaccessible
SSF
Sub Service Field
SPA
Signalling Point Accessible
SSP/SSA
SubSystem Prohibited/SubSystem Allowed
TCH
Traffic Channel
TS
Time slot
ED8 RELEASED

3BK 11203 0250 DSZZA
40/43

A - ANNEX : INTERNAL TIMERS

A.1 - BSSAP TIMERS
T_SZE_CH
It is started when sending SEIZE_CHANNEL to the DH_DTC waiting for the reply SEIZE_CHANNEL_ACK.
If the timer expires then an ASS_FAIL or HND_FAIL will be returned to the MSC depending upon the
reason for the seizure of the CIC.
Location : DTC controlling the SCCP connection
T_CH_ACT
It is started at the transmission of SEL_CH to the TCH RM requesting the selection of a TCH channel.
It is stopped at the reception of TCH_ACT_ACK from the RFMNGT.
It is started at the transmission of SELECT_SDCCH to the SDCCH RM requesting the selection of an

SDCCH channel. It is stopped at the reception of DCH_ACT_ACK from the RFMNGT.
If the timer expires then the assignment or handover will fail with an appropriate message being
returned to the MSC depending upon the reason for attempted radio channel seizure. If the failed
radio channel seizure was associated with an internal handover then the attempt will fail and the
next cell in the preferred cell list will be attempted (if allowed).
T_SMS_EST_CNF
It is started when sending the first short message to the RFMNGT. It is stopped at the reception of
the message SMS_EST_CNF. If the timer expires then the set-up of the SAPI 3 connection will fail and
an appropriate failure message will be sent to the MSC.
T_DEL_RLS
It is started when the MSC starts the release procedure (CLEAR_REQ not sent to the MSC), provided
that the speech/data path across the BSC is established. It is used to prevent the RFMNGT controlling
the connected radio channel receiving the RLS_REQ from the DH_TCU before the CLEAR_CMND
message is received from the BSSAP.
T_MOD_REQ
It is started at the beginning of the in call modification procedure when the BSSAP triggers the
RFMNGT to send the MODE_MODIFY message to the BTS. It is stopped at the reply from the RFMNGT.
If the timer expires the in call modification procedure will fail and an ASS_FAIL message will be
returned to the MSC.
ED8 RELEASED

3BK 11203 0250 DSZZA
41/43

A.2 - RFMNGT TIMERS

T_A
It is started during the immediate assignment and SDCCH handover procedures after the successful
selection of an SDCCH channel by the SDCCH RM. It will be stopped when the confirmation is received
of the successful or unsuccessful activation of the selected SDCCH channel. If the timer expires the
selected SDCCH channel will be set to FREE in the SDCCH resource manager function and be available
for selection once more when the next CHANNEL_REQUIRED message is received over the random
access channel.
Location : Broadcast TCU (RFMNGT_C_HANDLER)
T_B
It is started at the end of the immediate assignment procedure waiting for the confirm message from
the selected BSSAP. The confirm message will be sent by the selected BSSAP in parallel to the
sending of the SCCP_CONN_REQ message to the MSC. If the timer expires then the seized radio
channel will be released using the normal release procedure towards the MS and BTS and locally
within the BSC.
Location : TCU controlling the SDCCH channel seized by the MS in response to the earlier
transmission of the immediate assignment message
T_C
It is started during the normal assignment procedure and the internal intra-cell handover procedure
(TCH or SDCCH) after the channel activation. It is stopped at the reception of the EST_IND from the
BTS or the reception of a clearing message (CLEAR_CMND, RELEASE_CH) from the BSSAP. If the timer
expires then the activated radio channel will be released towards the BTS and locally within the BSC
using the normal release procedure.
Location : TCU controlling the selected and activated TCH or SDCCH channel
T_I
It is started when either the ASS_CMND or the HND_CMND is sent to the MS. It is stopped either at the
reception of a clearing message from the BSSAP (CLEAR_CMND or RELEASE_CH) or at the reception of
the EST_IND from the BTS. If the timer expires then the old radio channel will be released using the
normal release procedure towards the MS and BTS and locally within the BSC.
Location : TCU controlling the serving (old) TCH or SDCCH channel
T_C_INTER
It is used during the internal inter-cell handover and external handover procedures. It is started after
the activation of the channel waiting for EST_IND message from the BTS. This timer is equivalent in
function to timer T_C but is used as a protection timer when an inter-cell handover is involved
(internal or external) whilst timer T_C is used as a protection timer during normal assignments and
intra-cell handovers. If the timer expires then the activated radio channel will be released towards
the BTS and locally within the BSC using the normal release procedure.
Location : TCU controlling the selected and successfully activated target TCH or SDCCH channel
ED8 RELEASED

3BK 11203 0250 DSZZA
42/43

A.3 - RULES INVOLVING INTERNAL TIMERS

T8 < T_I
T3103 < T_C_INTER

T3103 < T_I
T3107 < T_C

T3107 < T_I
T9103 + T9108 < T_A
T9103 + T9108 < T_CH_ACT

T9103 < T_MOD_REQ
T9105 < T_B
T9113 < T_C_INTER
T_BTS_EST_CNF < T_SMS_EST_CNF

T_C < T_I
T_CH_ACT > T11
END OF DOCUMENT
ED8 RELEASED

3BK 11203 0250 DSZZA
43/43

Bss Telecom Parameter B12

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bss Telecom Parameter B12

Uploaded by

Copyright:

Available Formats

All rights reserved.

Passing on and copying of this

BSS TELECOM PARAMETERS

Alcatel-Lucent GSM/GPRS/EDGE BSS

Review Report 210084

Review Report 211101

Review Report 211105

Review Report 211122

Review Report 211146

BSS TELECOM PARAMETERS - RELEASE B12

All rights reserved. Passing on and copying of this

Based on the BTP B11 (3BK 11203 0172 DSZZA) Edition 18

The following modifications have also been added:

The following B12 features are taken into account:

The following changes about VAMOS have been added:

BSS TELECOM PARAMETERS - RELEASE B12

All rights reserved. Passing on and copying of this

The following B12 features are taken into account:

The following changes have been added:

The following changes have been added:

Alignment with BTP B11 Ed19rel done:

BSS TELECOM PARAMETERS - RELEASE B12

All rights reserved. Passing on and copying of this

Alignment with BTP B11 Ed20rel done:

BSS TELECOM PARAMETERS - RELEASE B12

All rights reserved. Passing on and copying of this

(for Light Radio)

new LR flag set to yes for 1680 parameters

new LR flag set to No when:

71 CDE MFS are added in the new CDE table for LR

(for Light Radio)

The report Parameter_output updated with the new LR flag

All rights reserved. Passing on and copying of this

The following CR B11 are included:

The following CR B12 hare included:

(for Light Radio)

HPC CAE template: SINGLE EGSM and CONCENTRIC EGSM

CR617635_1: T_RTP_PNRT minimum value different from 0

Alignment with FR20/314331 : 170 (AA) changed into 165

The following CR are included:

The following Changes are included:

All rights reserved. Passing on and copying of this

Gb over FR parameters: external added

The following CR are included:

The following CR B12.2 are included:

The following CR B12.2 Ed2 are included:

BSS TELECOM PARAMETERS - RELEASE B12

All rights reserved. Passing on and copying of this

2 EXPLANATION OF THE TABLE ...................................................................................... 15

BSS TELECOM PARAMETERS - RELEASE B12

All rights reserved. Passing on and copying of this

INTERNAL REFERENCED DOCUMENTS

Mobile radio interface - Layer 3 specification

Short Message Service Cell Broadcast (SMSCB) support on the

Multiplexing and multiple access on the radio path

Radio Subsystem Link Control

Signalling transport mechanism specification for the BSS-MSC

BSC-BTS interface - Layer 2 specification

BSC-BTS Interface - Layer 3 specification

Inband control of remote transcoders and rate adaptors for

Technical realisation of Short Message Service Cell Broadcast

Example protocol stacks for interconnecting Cell Broadcast

GPRS MS-BSS interface. RLC/MAC interface

MSC-BSS interface - Layer 3 specification