0250_08

ED8 RELEASED BSS TELECOM PARAMETERS - RELEASE B12

3BK 11203 0250 DSZZA 1/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

Site

VELIZY Wireless Division

Originators C. LEJEUNE

BSS TELECOM PARAMETERS

RELEASE B12

System : Alcatel-Lucent GSM/GPRS/EDGE BSS Sub-system : SYS-TLA Document Category : Product Definition

ABSTRACT This document lists and defines all parameters and timers that are specified by BSS telecom specification documents.

Approvals Name App.

MICHEL ROBERT SYT team leader

ZHANG HUA BSC DPM

NOEMI KIRELY SU BO

MFS DPM Name App.

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 Review Report 211101 Ed.01 Proposal 03 2011/03/18 Review Report 211105 Ed.01 Proposal 04 2011/05/26 Review Report 211122 Ed 01 Released 2011/06/29 Review Report 211146


3BK 11203 0250 DSZZA 2/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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 The following B12 features are taken into account: - A user plane over IP (sfd 163) The following modifications have also been added: - 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 The following modifications have also been added: - comments of rereading review (see report 211101) - 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)


3BK 11203 0250 DSZZA 3/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

Ed.01 proposal 04 2011/03/18 The following B12 features are taken into account: - Boosted GP: according to the MFS memo 2011-5674 (x4 in TDM) The following changes have been added: - comments of rereading review (see report 211105) - CR307499: VAMOS allowed training sequence codes (TSC and TSC_1_2)

Ed.01 proposal 05 2011/05/26 The following changes have been added: - comments of rereading review (see report 211122) - CR308749_v3: PAIRING_PRIORITIES in 1..6

Ed.01 Released 2011/06/29 The following changes have been added: - comments of rereading review (see report 211146) - 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


3BK 11203 0250 DSZZA 4/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

Ed.03 Released 2011/11/10 Alignment with BTP B11 Ed20rel done: - 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 Alignment with BTP B11 Ed21rel done: - 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 The following CR B12 are included: - 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.


3BK 11203 0250 DSZZA 5/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

Ed.04 Proposal01 (for Light Radio)

2011/11/25 • 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 (for Light Radio)

2012/01/27 • 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”

Ed.04 Proposal03

2012/03/23 • HPC CAE template modified to take into account single

EGSM, concentric EGSM and concentric EGSM-DCS1800. • The following CR B12 are included: - 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 6/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

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

Ed.04 Released

2012/06/11 • 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

• The following CR B11 are included: − 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) • 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)

Ed.05 Released (for Light Radio)

2012/07/05 • 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 7/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent − Gb over FR parameters: external added

− TRAFFIC_MODE (_xxx) : RFC4666 added Ed.06 Released

2012/08/30 • 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


3BK 11203 0250 DSZZA 8/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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


3BK 11203 0250 DSZZA 9/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent INTERNAL REFERENCED DOCUMENTS

Not applicable

REFERENCED DOCUMENTS

GSM References [1] 3GPP TS 03.41 Technical realisation of Short Message Service Cell Broadcast

(SMSCB) [2] 3GPP TS 03.49 Example protocol stacks for interconnecting Cell Broadcast

Center (CBC) and Base Station Controller (BSC) [3] 3GPP TS 44.006 MS-BSS interface data link layer specification

[4] 3GPP TS 44.008 Mobile radio interface - Layer 3 specification

[5] 3GPP TS 44.012 Short Message Service Cell Broadcast (SMSCB) support on the mobile radio interface

[6] 3GPP TS 44.060 GPRS MS-BSS interface. RLC/MAC 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 Signalling transport mechanism specification for the BSS-MSC interface

[10] 3GPP TS 48.008 MSC-BSS interface - Layer 3 specification

[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 Inband control of remote transcoders and rate adaptors for Enhanced Full Rate (EFR) and full rate traffic channels

[14] 3GPP TS 48.061 In-band control of remote transcoders and rate adaptors for half rate traffic channels


3BK 11203 0250 DSZZA 10/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent CCITT/ITU References

[15] CCITT Q.703 (Blue Book) SS7 - Signalling link

[16] CCITT Q.704 (Blue Book) SS7 - Signalling network functions and messages

[17] CCITT Q.707 (Blue Book) SS7 - Testing and maintenance

[18] CCITT Q.714 (Blue Book) SS7 - Signalling Connection Control Part procedures

[19] CCITT Q.921 (Blue Book) ISDN user-network interface - Link layer specification


3BK 11203 0250 DSZZA 11/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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


3BK 11203 0250 DSZZA 12/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

[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 (Gb 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


3BK 11203 0250 DSZZA 13/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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


3BK 11203 0250 DSZZA 14/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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


3BK 11203 0250 DSZZA 15/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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


3BK 11203 0250 DSZZA 16/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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

Code Meaning

GSM Needed for GSM circuit


3BK 11203 0250 DSZZA 17/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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:


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:



3BK 11203 0250 DSZZA 18/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent


3BK 11203 0250 DSZZA 19/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent Table : Instances

Instance Meaning cell there is one instance of the parameter for each cell

3G cell there is one instance of the parameter for each 3G cell

adj there is one instance of the parameter for each declared adjacent cell

BTS there is one instance of the parameter for each BTS BSS 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

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

MFS there is one instance of the parameter for the PCU function. In the pure GSM, it represents the MFS. 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.

MSC there is one instance of the parameter for each MSC, connected to the BSC.

BC there is one instance of the parameter for each Frame Relay Bearer Channel in the MFS. This instance name is not relevant in LightRadio.

BSCproc there is one instance of the parameter for each 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 Trunk there is one instance of the parameter for each A

trunk TRX there is one instance of the parameter for each TRX N7ch there is one instance of the parameter for each N7

signalling link ACH there is one instance of the parameter for each A

interface circuit OMC there is one instance of the parameter for the OMC-R

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

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


3BK 11203 0250 DSZZA 20/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent BVC There is one instance of the parameter for each BVC

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

PDCH There is one instance of the parameter for each PDCH PDCH group There is one instance of the parameter for each PDCH

group PVC There is one instance of the parameter for each PVC

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

segment Abis group 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.

SCTP EndPoint 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)

IP-GSL 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)


3BK 11203 0250 DSZZA 21/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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. In the PCU, one NSE is defined per PMU for each SGSN connected to the BSS

SGSN-IPEndPoint 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 pre-configured IP endpoint.

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

LTE cell 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 - Values are limited to the following list:


3BK 11203 0250 DSZZA 22/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

Config. Meaning SITE (CAE) (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)

Network (CDE) (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).

System (CST) 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:


Config. Meaning

None (DLS) 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.

None (DLS & Restricted)

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.

None (not in DLS) Hard coded parameters, can not be modified Changeable the parameter is present in the BSC or MFS

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 23/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

Config. Meaning

Displayed the parameter is present in the BSC or MFS 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 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.

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

Set by create the parameter is present in the BSC or MFS database and in the MIB. Its value is set during the creation of the relative object and can not be modified afterwards.

Set by create and changeable

the parameter is present in the BSC or MFS 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 24/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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 OMC-R access Changeable Migration comments

None (DLS) In DLS None (not in DLS) Parameter hard

coded

System(CST)

Displayed

NO NO

None (DLS) Set by create

Network(CDE)

Displayed

Value can be customised at initialisation via the CDE-table.

NO (Migration only in extraordinary cases)

None(DLS) Yes (DLS migration)

Parameters depending on the type of connected MSC

Displayed

Value not changeable, but default value might be customised via the CDE-table if it is a new parameter.

Yes

Changeable Yes Yes None (DLS & restricted)

No Yes (DLS migration)

Access restricted to Alcatel Lucent team

Virtual changeable

Value might be changed by changing value(s) of the parameter(s) it is depending on.

Yes

Site (CAE)

Virtual (DLS) No No

See 2.25.1 for more detail about the migration rules of BSC parameters.


3BK 11203 0250 DSZZA 25/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 2.9.2 Sub-System: MFS

Category OMC-R access Changeable Migration comments None (DLS) In MFS data base System(CST) None (not in DLS)

NO NO Hard coded

None (DLS) Value might be customised via BUL files

by MFS No real migration, since the value is customized (so no rule is specified in the BTP)

Network(CDE)

Set by create Default value is

set by OMC or the MFS at creation of the corresponding instance.

Yes. the “owner” of the object instance is also responsible for the migration of the related parameters.

Displayed Depending on the case

Depending on the case

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.

Site (CAE)

Changeable Yes Yes. OMC migrates radio data (via re-init+re-synchro) that are present at OMC/ MFS itf. MFS migrates ater/ Gb/ HW data (via data conversion scim) that are present at OMC/ MFS itf.

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 26/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent Virtual

changeable Value might be changed by changing value(s) of the parameter(s) it is depending on

Yes

None (DLS) Default value is set by the MFS

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 OMC-R access Changeable Migration Comments

Site (CAE) Changeable Yes Yes No migration rules defined in the BSS telecom parameters

2.9.4 Sub-System: BTS


System (CST) None (not in DLS) No No Hard coded

Network (CDE) None (not in DLS) No No Parameter configured via 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 Sub-System: TC


System (CST) None (not in DLS) No No Hard coded


3BK 11203 0250 DSZZA 27/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

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


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 28/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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. - Values are limited to the following list:

Table : Units

Unit Meaning

None- No unit byte byte kbit kbit

kbit/s kbit/s mn minute s second


3BK 11203 0250 DSZZA 29/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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


3BK 11203 0250 DSZZA 30/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent - 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 - Same format is used for “Minimum value”, “Maximum value” and “Default value” fields.

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” - Same format is used for “Minimum value”, “Maximum value” and “Default value” fields.


3BK 11203 0250 DSZZA 31/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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


3BK 11203 0250 DSZZA 32/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

2.19 Internal comments Definition:

This field contains any additional comments relevant for the parameter, for internal use. Constraints:

- Optional - String with no length constraints - 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


3BK 11203 0250 DSZZA 33/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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 - String with length < 255 characters

2.22 Rec ref Definition:

This field indicates, if applicable, in which GSM recommendation or ITU-T recommendation the parameter is specified.

Constraints: - Optional - String with length < 255 characters

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 - String with no length constraints

2.24 Spec ref Definition:

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


3BK 11203 0250 DSZZA 34/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent - Optional

- String with length < 255 characters

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 Present in Old Rel

Present in New Rel

Migration Type

Old -> New

No Yes None Not applicable System (CST)

Yes Yes None Not applicable No Yes None Not applicable

Network (CDE) Yes Yes None (note1) Not applicable No Yes None (note2) Not applicable

Site (CAE) 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


3BK 11203 0250 DSZZA 35/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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 Present in Old Rel

Present in New Rel

Migration Type

Old -> New

No Yes None Not applicable System (CST)

Yes Yes None Not applicable No Yes None Not applicable

Network (CDE) Yes Yes None (note1) Not applicable No Yes Migration of new

Bx MFS parameters by the MFS (note2)

New default value OR new coded default value

Site (CAE) + Not “OMC changeable” OR Site (CAE) + “OMC changeable” + <>(BSS/Cell/Adj)

Yes Yes Migration of common Bx-1/Bx MFS parameters by the MFS

“Value of previous release” OR Explicit rule (note3)

Site (CAE) + “OMC changeable” + =(BSS/Cell/Adj)

No Yes Migration of new Bx MFS parameters by the OMC (note2)

New default value OR new coded default value


3BK 11203 0250 DSZZA 36/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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.


3BK 11203 0250 DSZZA 37/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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. Parameters such as cell or sub-system identifiers SHALL NOT be included in the list; 2. Parameters enables / disables a new feature SHALL NOT be included in the list. 3. 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).


3BK 11203 0250 DSZZA 38/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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.


3BK 11203 0250 DSZZA 39/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent

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


3BK 11203 0250 DSZZA 40/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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


3BK 11203 0250 DSZZA 41/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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). Location : DTC controlling the SCCP connection

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. Location : DTC controlling the SCCP connection

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. Location : DTC controlling the SCCP connection

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. Location : DTC controlling the SCCP connection


3BK 11203 0250 DSZZA 42/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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


3BK 11203 0250 DSZZA 43/43

All ri

ghts

reserv

ed. P

assing

on an

d cop

ying o

f this

do

cume

nt, us

e and

comm

unica

tion o

f its c

onten

ts no

t pe

rmitt

ed w

ithou

t writ

ten au

thoriz

ation

from

Alca

tel-Lu

cent 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

0250_08

Documents

review report

ip en b12

ip bss transport parameters

following b12 features

bsc new b11 sitecae

b11 mr3

bsc cae parameters

b11 migration rules