B9B10-Nonregression CS Ed03

8/11/2019 B9B10-Nonregression CS Ed03

1/41

ED 3 RELEASED

WBG B9B10-nonregression_CS_ed03.doc 2009-07-09 3DF 01906 8011 WAZZA 1/41

All

rightsreserved.

Passingonandcopyingofthis

document,

useandcommunicationofitscontentsnotpermittedwithout

writtenauthorizationfromA

lcatel-Lucen

t.

Domain : NETWORK OPTIMIZATION

Product : GSM B10

Division : METHODS

Rubric : MIGRATION

Type : GUIDELINE

Distrib. codes Internal: External:

PREDISTRIBUTION

NE F. ColinNE France M. Palumbo NE Egypt M. SayedNE Romania I. Inta NE Portugal P. Henriques

ABSTRACTThe aim of this document is to explain how to set the B10 GSM parameters in order to obtain thesame behavior than in B9 release.

KEYWORDSB10, non-regression, QoS, 2G, 3G, AMR, BSC, counters, parameters, mCCCH, MX capacityimprovement, STM1

Approvals

NE F.COLIN NE France M.PALUMBODate: Signature: Date: Signature:

Site

VELIZY

Carrier Business Group

MOBILE ACCESS / PSS TI / NETWORK ENGINEERING

Originator

TIS / Network EngineeringB9-B10 migration : non-regression of the circuit mode


2/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

HISTORY

Edition Status Date Comments

01 RELEASED 11/02/2008 Creation of the document

02 RELEASED 04/11/2008 Updated paragraphs:MX BSC CAPACITY IMPROVEMENTOPTIMZED HR CONNECTIVITYMCCCHCOUNTERS/PARAMETERS IMPROVEMENTS

New paragraph:DIFFERENTIATED RADIOLINK TIMEOUT FOR AMRCALLS

03 RELEASED 09/07/2009 Addition of STM1, new B10MR2ed7 counters/indicators,QoS variations

REFERENCED DOCUMENTS

Table 1: Referenced Documents

Cross-Reference

Document Title Document Number

[DocTemp]1 PCS Document Template 3DF 01900 0000 PTZZA

[Layout] Alcatel-Lucent Forms, Sizes and Layout 1AA 00014 0000 ASZZA

[SFD] Multiple CCCH 3BK 10204 0028 DTZZA

[RFD] Compressed Inter RAT HO info 3BKA55CBR194412

[SFD] MX capacity improvement 3BK 10204 031 DTZZA[memo] Analysis of Proposals from PCS for B10 release MRD/TD/SYT/205402

[SFD] SFD STM-1 impact for TC 3BK 10204 0067 DTZZA

1The cross reference may be in format like [1] or in words like [DocTemp]


3/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

TABLE OF CONTENTS

1 SCOPE........................................................................................... 5

1.1 PURPOSE OF THE DOCUMENT ................................................................................. 5

1.2 AREA OF APPLICATION........................................................................................... 5

2 OVERVIEW...................................................................................... 5

2.1 B10 FEATURES ..................................................................................................... 5

3 MX BSC CAPACITY IMPROVEMENT.......................................................... 63.1 1000 TRX AND HSL ............................................................................................... 63.1.1 FEATURE DESCRIPTION........................................................................................................ 63.1.2 FEATURE ACTIVATION ......................................................................................................... 63.1.3 PARAMETERS .................................................................................................................... 73.1.4 COUNTERS...................................................................................................................... 73.1.5 MIGRATION RULES ............................................................................................................. 73.1.6 FIELD FEEDBACK............................................................................................................... 8

3.2 OPTIMIZED HR CONNECTIVITY ................................................................................ 103.2.1 FEATURE DESCRIPTION....................................................................................................... 103.2.2 FEATURE ACTIVATION ........................................................................................................ 113.2.3 PARAMETERS ................................................................................................................... 113.2.4 COUNTERS..................................................................................................................... 12

3.2.5 MIGRATION RULES ............................................................................................................ 12

4 MULTIPLE CCCH ..............................................................................13

4.1 FEATURE DESCRIPTION..........................................................................................13

4.2 FEATURE ACTIVATION ...........................................................................................13

4.3 PARAMETERS ...................................................................................................... 13

4.4 COUNTERS........................................................................................................ 14

4.5 MIGRATION RULES...............................................................................................18

5 2G INTEROPERABILITY .......................................................................19

5.1 2G TO 3G HANDOVER BASED ON 2G LOAD AND SERVICE CRITERIA...................................195.1.1 FEATURE DESCRITPION....................................................................................................... 19

5.1.2 FEATURE ACTIVATION ........................................................................................................ 205.1.3 PARAMETERS ................................................................................................................... 205.1.4 COUNTERS..................................................................................................................... 205.1.5 MIGRATION RULES ............................................................................................................ 23

5.2 SUPPORT OF COMPRESSED INTER-RAT INFO ELEMENT .................................................... 235.2.1 FEATURE DESCRITPION....................................................................................................... 235.2.2 FEATURE ACTIVATION ........................................................................................................ 235.2.3 PARAMETERS ................................................................................................................... 235.2.4 COUNTERS..................................................................................................................... 235.2.5 MIGRATION RULES ............................................................................................................ 23

6 COUNTERS / PARAMETERS IMPROVEMENTS .............................................24

6.1 CALL SETUP SUCCESS RATE METRIC........................................................................... 246.1.1 FEATURE DESCRIPTION....................................................................................................... 246.1.2 FEATURE ACTIVATION ........................................................................................................ 246.1.3 PARAMETERS ................................................................................................................... 246.1.4 NEW COUNTERS .............................................................................................................. 246.1.5 NEW INDICATOR.............................................................................................................. 256.1.6 MIGRATION RULES ............................................................................................................ 26

6.2 PARAMETERS IMPROVEMENTS .................................................................................. 266.2.1 FEATURE DESCRIPTION....................................................................................................... 266.2.2 FEATURE ACTIVATION ........................................................................................................ 26


4/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

6.2.3 PARAMETERS ................................................................................................................... 266.2.4 COUNTERS..................................................................................................................... 266.2.5 MIGRATION RULES ............................................................................................................ 26

6.3 NEW COUNTERS FOR CALL DROP WITH SPECIFIC RADIO CAUSES ......................................276.3.1 FEATURE DESCRIPTION....................................................................................................... 276.3.2 FEATURE ACTIVATION ........................................................................................................ 286.3.3 PARAMETERS ................................................................................................................... 286.3.4 COUNTERS..................................................................................................................... 286.3.5 MIGRATION RULES ............................................................................................................ 29

6.4 NEW COUNTERS FOR SDCCH ASSIGNMENT SUCCESS RATE .............................................306.4.1 FEATURE DESCRIPTION....................................................................................................... 306.4.2 FEATURE ACTIVATION ........................................................................................................ 306.4.3 NEW COUNTERS .............................................................................................................. 306.4.4 NEW INDICATORS............................................................................................................. 316.4.5 RELATED PARAMETERS ........................................................................................................ 316.4.6 MIGRATION RULES ............................................................................................................ 31

6.5 NEW COUNTERS FOR SDCCH ASSIGNMENT REQUEST FOR LOCATION UPDATE ..................... 316.5.1 FEATURE DESCRIPTION....................................................................................................... 316.5.2 FEATURE ACTIVATION ........................................................................................................ 326.5.3 NEW COUNTER............................................................................................................... 326.5.4 NEW INDICATORS............................................................................................................. 326.5.5 RELATED PARAMETERS ........................................................................................................ 33

6.5.6 MIGRATION RULES ............................................................................................................ 33

7 DIFFERENTIATED RADIOLINK TIMEOUT FOR AMR CALLS...............................34



7.3 PARAMETERS ...................................................................................................... 35

7.4 COUNTERS........................................................................................................ 35

7.5 MIGRATION RULES...............................................................................................35

8 STM1 CONNECTIVITY IN TC ................................................................37



8.3 PARAMETERS ...................................................................................................... 388.4 COUNTERS / INDICATORS...................................................................................... 38

8.5 MIGRATION RULES...............................................................................................38

9 GENERAL B10 QOS FEEDBACK.............................................................39

9.1 PARAMETERS VARIATIONS .......................................................................................399.1.1 PARAMETERS INSTANCE CHANGES......................................................................................... 39

9.2 QOS VARIATIONS ................................................................................................399.2.1 BULGARIA...................................................................................................................... 399.2.2 GERMANY ....................................................................................................................... 40


5/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

1 SCOPE

1.1 PURPOSE OF THE DOCUMENT

The target group is: engineers optimizing GSM radio networks.

1.2 AREA OF APPLICATION

The aim of this document is to explain how to set the B10 GSM parameters in order to obtain thesame behavior than in B9 release.The services described in this document are applicable for networks where Alcatel is the currentsupplier for BSS.This document is valid for B10 release up to B10MR2ed7.

2 OVERVIEW

This document presents the differences between B9 and B10 releases and explains how to set the B10GSM parameters in order to have the same behavior as in B9 release after a B9 to B10 migration.

It describes the main new features and algorithms evolutions that can have an impact on the circuitQoS during a B9 to B10 migration. For features that are activated automatically in B10, a field resultis given when available.Finally this document contains a last part giving a general feedback on QoS variation.

2.1 B10 FEATURES

Feature ActivationMX Capacity improvement

1000 TRX Optional

HSL OptionalOptimized HR connectivity Optional

Multiple CCCH Optional

2G interoperability

2G-3G HO based on 2G load & service criteria Optional

Support of compressed inter-rat info element Optional

Counters/parameters improvements

Call setup success rate metrics Automatic

Parameters Automatic

Call drop specific cause Automatic

Differentiated RLT for AMR calls Optional

TC-STM1 Optional


6/41


7/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

3.1.3 PARAMETERS

Name Instance Range/Default

Definition

EN_HSL BSC [0;1];0 Enables SS7 HSL (High speedSignalling Link).

MAX_CELLS_GP MFS 500Maximum number of cells configuredby GP board (Mx-MFS)

MAX_CELLS_GPUAB MFS 240Maximum number of cells configuredby GPUAB board (MFS)

MAX_CELLS_GPUAC MFS 264Maximum number of cells configuredby GPUAC board (MFS)

MAX_TCH_PER_CCP BSC 1100Maximum number of active TCHs perCCP board

MTP_Sequence_Number_Format BSC0=Normal,1=ExtendedDefault 0

Defines the format to be used for thesequence number of MTP2

3.1.4 COUNTERS

There is one new counter added:

Ref. name Mnemonic Definition Trigger condition

MC926 TCH_BLOCKING_OCCURENCES_BSC

Number of TCH channelallocation rejected for cause:Maximum TCH processingcapacity of CCP reached.

Whenever a TCH cannot beallocated due to the TCHprocessing capacity of CCPreaches the limit defined bythe MAX_TCH_PER_CCPparameter.

Based on this counter one indicator has been defined:

Ref. name Mnemonic Definition Formula

GTCRRCGTSN

TCH_block_BSC_cong Number of TCH channel allocationrejected for cause Maximum TCHcapacity of theBSC reached at BSC level.

MC926

3.1.5 MIGRATION RULES

No migration rules can be defined for this feature as it is automatically activated during migration toB10.

However, it is important to know the following limitations which may occur in case of MxBSCextension:

The TP GSM board capacity is of 512 HDLC in TPv1, and is extended to 1024 HDLC in TPv3.In Mx BSC, for each HDLC logical link, e.g. RSL, OML, GSL and PPP there is a logical HDLCchannel number and a physical HDLC device number associated. HDLC channels for RSL andOML are assigned dynamically in the range [40..480], so only 441 HDLC channels are


8/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

available in TPv1. All signalling links that are not multiplexed or that are statically multiplexedhave their own logical HDLC channel. All signalling links that are statistically multiplexed sharethe same logical HDLC channel. The max number of DR TRE which may be mapped on TPv1,if Statistical multiplexing is used, is up to 882 with low signalling load and up to 441 with highsignalling load. With TPv3, the max number of DR TRE which may be mapped, if Statisticalmultiplexing is used, is up to 984 with high signalling load. So, the Statistical multiplexing withMCB64K is strongly recommended.

The CIC numbering scheme defined in ITUT Q.763 is coded on 12-bits field, permitting to

address a maximum of 4096 circuits between MSC and BSC elements. The BSC Evolutionsupports CIC-numbers coded on 16 bits from release B10 onwards. It must be connected toan MSC also supporting coding on 16 bits, such as the A5060 Spatial Atrium Call Server(NGN solution from Alcatel-Lucent) in order to address more than 4096 CICs.

The HSL usage may become mandatory for more than 600 TRX mapped on MxBSC.Introduction of HSL (High Speed Signaling Link) is possible with the next conditions:

The HSL links are physically connected on two LIU ports, corresponding to Atermux CS; The Atermux for HSL are directly cabled to MSC; These two links will work on load sharing mode, not active/standby mode. Mixed mode (LSL+HSL) is not allowed; There is no Qmux configured on the Atermux for HSL

Any Atermux defined in the BSC configuration could be used to support HSL, but the BSCchecks that these two Atermux:

Do not carry Qmux (Atermux 1 and 2, Atermux 7 and 8, ) Are configured for CS traffic only, Are on two different LIU boards, and each LIU boards must be available in BSC. HSL is always defined on the first Atrunk of the selected Atermux.

If HSL is actived, N7 can have 2 different frame formats: Normal frame format (MSU contains 6 bytes as fix part + SIF&SIO as variable part). Extended frame format (MSU contains 9 bytes as fix part + SIF&SIO as variable part).

The MxBSC is supporting both formats. Extended format may not be used if HSL is notactivated. To be checked which format is supported by MSC.

The Alcatel-Lucent Core Network elements supporting the HSL feature are RCP A8362M +Umax EP6 or above, and NGN release W4.21.

NE Recommendations: Estimate the final load in terms of traffic and connectivity before BSC extension Check if HSL is needed and may be supported by CN Traffic follow-up during the cutover process Check the BSC and CCP load after cutover Check the Mux rule used on Abis and Change it to StatisticMux64 to reduce the HDLC

occupancy

3.1.6 FIELD FEEDBACK

The Feature MxBSC Capacity improvement was tested in B10 China first off. The plan was to reach

more than 800 TRX per BSC. The BTSs were moved from old BSCs to the new MxBSC.

After last cutover, the MxBSC with 5+1 CCP boards has reached the following configuration:- 157 cells (31.4% of total capacity);- 156 BTSs (61.18% of total capacity);- 158 Abis links (89.77% of total capacity);- 834 TRXs (803 FR TRX + 31 HR TRX), so 865 FReq TRXs (86.5% of total capacity);- 30 AterMux CS links (28 for CS traffic + 2 for HSL);


9/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

- 18 AterMux PS links;- 4 GP boards.

The max traffic values reached during BH, after last cutover, were:- Max TCH traffic = 1239.56 Erlang- Max Nb of TCH needed = 1509- Max SCCP traffic = 1469.69 Erlang- Max Nb of SS7 TS needed = 18

- Max GCH traffic = 1472.1 Erlang- Max Nb of GCH needed = 1832- Max Nb of GP boards needed = 2

QoS Follow-up for CS

QoS IndicatorBefore 3rd

cutoverAfter 3nd

cutoverDelta

% SDCCH Assign Congestion 2.14% 2.34% 0.20%

% SDCCH Assign Fail 4.92% 5.57% 0.65%

% SDCCH Drop 0.72% 0.91% 0.19%

SDCCH Traffic Erl Total 3372 3575 204RTCH Traffic Erl Total 13852 14112 259

% RTCH Assign Congestion 0.02% 0.01% -0.02%

% RTCH Assign Success 99.51% 99.31% -0.20%

%Call Setup Suc 98.79% 98.41% -0.38%

% RTCH fail Radio 0.46% 0.67% 0.20%

% Call Drop 0.34% 0.38% 0.04%

% RTCH Drop 0.17% 0.19% 0.02%

% HO Inc Intra Fail 2.51% 4.86% 2.35%

% HO Inc Intra Cong 0.30% 0.17% -0.13%

% HO Inc Intra Success 96.99% 94.83% -2.16%

% HO Out Intra ROC 2.34% 4.72% 2.38%

% HO Out Intra Drop 0.16% 0.20% 0.04%

% HO Out Intra Success 97.00% 94.79% -2.21%

% HO Inc Inter Fail 5.51% 11.84% 6.33%

% HO Inc Inter Cong 0.22% 0.30% 0.07%

% HO Inc Inter Success 94.25% 87.85% -6.40%

% HO Out Inter ROC 3.53% 3.56% 0.02%

% HO Out Inter Drop 0.06% 0.07% 0.01%

% HO Out Inter Success (*) 70.88% 57.85% -13.03%

%HO Better Cell 56.92% 55.38% -1.53%

(*) recovered after 5 days to initial value


10/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

QoS Follow-up for PS

QoS IndicatorBefore3rd

cutoverAfter 3rd

cutoverDelta

%DL TBF Success 95.88% 97.25% 1.37%

%DL TBF Fail Radio 3.70% 2.32% -1.37%

%UL TBF Success 84.27% 86.27% 2.00%

%UL TBF Fail Radio 15.11% 13.12% -1.98%%GPRS DL Resource ReallocationSuccess

58.27% 54.75% -3.51%

%GPRS UL Resource ReallocationSuccess

75.84% 73.73% -2.11%

% DL TBF Drop 4.12% 3.36% -0.76%

% DL TBF Acc Release 0.61% 0.59% -0.02%

% DL TBF Norm Release 95.27% 96.05% 0.78%

% UL TBF Drop 2.73% 1.99% -0.74%

% UL TBF Acc Release 0.03% 0.03% 0.00%

% UL TBF Norm Release 97.25% 97.98% 0.74%

DL CSx retr rate 3.88% 3.25% -0.63%DL MCSx retr ratio 15.98% 16.20% 0.22%

UL CSx retr rate 0.78% 0.82% 0.04%

UL MCSx retr rate 3.54% 3.41% -0.13%

The QoS follow-up, based on unitary and statistical tests, shown non regression for CS and PSservices. No issues related to MxBSC have been discovered.

3.2 OPTIMIZED HR CONNECTIVITY

3.2.1 FEATURE DESCRIPTION

In B9, the number of TREs that can be mapped to a CCP board of the MX BSC depends on the typeof TRE (FR or DR). 50 VTCUs are allocated per CCP and per VTCU it is possible to map:

- four FR TREs or- two DR TREs or- one DR TREs and two FR TREs

With these rules up to 200 FR TREs can be mapped on a CCP with VTCU handling FR TREs while onlyup to 100 DR TREs can be mapped to a CCP with VTCU handling DR TREs and with mixed FR/DR

VTCUs configurations the number of TREs that can be mapped on a CCP is in between these twovalues.Therefore the number of TREs a CCP can handle (i.e. the connectivity of the CCP) decreases when thenumber of VTCUs mapped with DR TREs increases.

Furthermore when a CCP board is added on a MX BSC or when a BTS is removed from a MX BSC,the load is not reshuffled between the boards and therefore it may happens that some boards arehighly loaded while some others are not loaded.


11/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

In B10, the maximum number of TREs mapped to a CCP shall be independent on whether the TREsare FR or DR. It shall be always possible to map up to four TREs (FR and/or DR) per VTCU, i.e. up to200 TREs per CCP.

The load on a CCP board shall be kept at the same level as in B9. For that reason the maximumnumber of TCH a CCP can handle shall be limited to MAX_TCH_PER_CCP. The PDCHs channelsused for PS traffic are not taken into account in the evaluation of the load. To avoid havingunbalanced load between the CCP boards when a CCP board is added on a MX BSC or when a BTS

is removed from a MX BSC, it is requested to have a remap-bts-on-ccp command at the OMC-R tospread the load between the CCPs boards.This feature is optional.

This feature shall be supported by TP GSM V1 and TP GSM V3.

3.2.2 FEATURE ACTIVATION

The removal of HR impact on BSC connectivity feature is optional

For mapping the TREs on a TCU, two mapping rules are supported: The B9 rules and a new B10rule.For an operator who has bought the feature, it shall be possible to activate/deactivate the feature

from the OMC-R (i.e. it can choose the mapping rule it wants).

The maximum number of TREs mapped to a CCP shall be independent on whether the TREs are FR orDR. This maximum number shall be 200.

It shall be possible to map up to four TREs on a VTCU independently whether they are FR or DR.

The command remap-bts-on-ccp is not optional and shall be supported at the OMC-R.

It shall be possible to trigger the command remap-bts-on-ccp at any time, e.g. when a BTS isremoved or when a CCP is added. The call can be lost during BTS remapping.

As this feature is optional a new parameter EN_4_DR_TRE_PER_TCU is received from the OMC-R toenable/disable the feature. This parameter defines if the limitation of TRE (per CCP board) is static ordynamic:

- For static limitation B9 rule is applied.- For dynamic limitation new B10 rule is applied.- Range / default value: False = Static or 0 ; True = Dynamic or 1

This parameter is used only by the O&M part of the MX BSC. It should be possible for the telecompart of the MX BSC to use the new algorithm to count the active TCH whatever the feature is active ornot.

3.2.3 PARAMETERS


Definition

EN_4_DR_TRE_PER_TCU BSC [0;1]; 0 Defines if the limitation of TRE is static ordynamic.For static limitation onlyNb FR TRE + 2 x DR TRE < 200 is allowed.For dynamic limitation only


12/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

Nb TRE < 200 is allowed.

3.2.4 COUNTERSNo specific counters or indicators.


For ... Parameter name in B9 Parameter valuein B9

Parameter name in B10 Parameter valuein B10

BSC EN_4_DR_TRE_PER_TCU Default=0Activated=1

The Optimized HR connectivity feature activation is impacting the CCP board capacity. It isextended from 100 DR TRX to 200 DR TRX. The feature has no impact on TP GSM capacity.

The limitation factors presented in case of MxBSC Capacity Improvement feature must be followedalso for this feature activation.

NE Recommendations: Estimate the final load of BSC in terms of connectivity before feature activation User and Signaling Traffic follow-up before and after feature activation Check the BSC load after activation


13/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

4 MULTIPLE CCCH

4.1 FEATURE DESCRIPTION

The multiple CCCH is required to support the increasing signalling load on the common channels,due to either big CS cells with high peak throughput or to PS traffic.

In circuit mode the mobile station listens to the CCCH and the BCCH channels. A mobile in packettransfer or idle mode must also listen to the BCCH and CCCH.

The multiple CCCH feature is implemented in both G2BSC and MxBSC. Only TS0 and TS2 onbeacon TRX will be used for multiple CCCH. When there is only one CCCH, it is on TS0 only.

The number of CCCH is given by configuration. No dynamic algorithm is implemented to change thenumber of CCCH as a function of the CCCH load.

It is not allowed to active a second CCCH when the CCCH in the cell is combined with SDCCH.Duplicating system information messages on TS0 and TS2 BCCH blocks is performed by the BTS tosave RSL resources.

Computing of CCCH_Groups to determine on which CCCH TS0 or TS2 to send the AGCH messageis done by BSC, because BTS does not have any knowledge of IMSI.

4.2 FEATURE ACTIVATION

Feature activation may be obtained using the parameter CCCH_CONFwhich indicates theorganization of the common control channels at cell level:

4.3 PARAMETERS


Definition

CCCH_CONF Cell [0;2];0 Configuration of the CCCH.0 = "one CCCH not combined"1 = "one CCCH combined"2 = "two CCCH not combined"

NB_MAX_MSG_MULTIPLE_PAGING_CMD

BSC [1;10];5 Number of paging messages that shallbe included in the Abis messageMULTIPLE PAGING COMMAND beforesending it to the BTS (except ifT_SEND_MULTIPLE_PAGING_CMDexpires before this limit is reached).

T_SEND_MULTIPLE_PAGI

NG_CMD

BSC [50;250];5

0

Maximum time between two sendings of

MULTIPLE PAGING COMMANDmessage (i.e. atT_SEND_MULTIPLE_PAGING_CMDexpiry, the message is sent even if itdoes not contain yetNB_MAX_MSG_MULTIPLE_PAGING_CMD messages).


14/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

4.4 COUNTERS

There are several new counters added:

Ref.name

Mnemonic Definition Trigger condition

MC925a

NB_AGCH_USEFUL_BLOCKS_SENT

Number of useful blockssent on AGCH channel(The dummy blocks arenot counted).

This counter is increased each timean IMMEDIATE ASSIGNMENT orIMMEDIATE ASSIGNMENTEXTENDED or IMMEDIATE

ASSIGNMENT REJECT or PACKETUPLINK ASSIGNMENT or PACKETDOWNLINK ASSIGNMENTmessage is taken from one AGCHqueue and put on AGCH channel.

MC925

b

NB_PCH_USEFUL_BL

OCKS_SENT

Number of useful blocks

sent on PCH channel(The dummy blocks arenot counted).

This counter is increased each time

a PAGING REQUEST message istaken from one Paging_GroupFIFO and put on PCH channel.

MC925c

NB_BUSY_RACH_SLOTS

Number of busy RACHslots.

Each 51-multiframes the Layer 1reports the load on the RACH viatheRACH_MEASUREMENTS_RESULTSmessage, which contains thefollowing information:- N_VRACH: number of AccessBursts successfully decoded- N_BUSY: number of RACH busyslots

On reception of this message, thefollowing counters are updated:- NB_BUSY_RACH_SLOTS =NB_BUSY_RACH_SLOTS +N_BUSY

MC925d

NB_CHANNEL_RQ_RADIO

Number of channelrequest messagesreceived on the radiointerface or number ofaccess bursts successfullydecoded.

Each 51-multiframes the Layer 1reports the load on the RACH viatheRACH_MEASUREMENTS_RESULTSmessage, which contains thefollowing information:- N_VRACH: number of Access

Bursts successfully decoded- N_BUSY: number of RACH busyslots

On reception of this message, thefollowing counters are updated:- NB_CHANNEL_RQ_RADIO =NB_CHANNEL_RQ_RADIO +


15/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

Ref.name


N_VRACH

MC925e

NB_ASSIGN_CMD_RECEIVED_ABIS

Number of 48.058IMMEDIATE ASSIGNCOMMAND messagesreceived by the BTS on

Abis and had to be sentfor CS and PS traffic tothe MS.

This counter is increased each timean IMMEDIATE ASSIGNMENTCOMMAND message is receivedon Abis interface.

MC925f

NB_ASSIGN_CMD_DISCARDED

Number of 48.058IMMEDIATE ASSIGNCOMMAND messagesreceived by the BTS on

Abis and discarded dueto congestion.

This counter is increased each timean IMMEDIATE ASSIGNMENTCOMMAND messages is discardedon detection of AGCH FIFOoverload.

MC925g

NB_PAGING_CMD_RECEIVED_ABIS

Number of PAGINGCOMMAND received bythe BTS on Abis and had

to be sent for CS and PStraffic to the MS.

1) Applicable to the legacy BSConly: this counter is increased byone each time a PAGING

COMMAND message is receivedon Abis interface.2) Applicable to the BSC Evolutiononly:a) This counter is increased by oneeach time a PAGING COMMANDmessage is received on Abisinterface.b) This counter is increased by "n"each time a MULTIPLE PAGINGCOMMAND message is receivedon Abis interface ("n" is the number

of PAGING COMMAND containedin the received MULTIPLE PAGINGCOMMAND message).

MC925h

NB_PAGING_CMD_DISCARDED

Number of PAGINGCOMMAND received bythe BTS on Abis anddiscarded due tocongestion.

1) Applicable to the legacy BSConly: this counter is increased byone each time a PAGINGCOMMAND is discarded ondetection of Paging_Group FIFOoverload.2) Applicable to the BSC Evolutiononly:This counter is increased by oneeach time a PAGING COMMAND

is discarded on detection of PagingGroup FIFO overloaded (Note 1).Note 1: It does not matter whetherthe discarded (and counted)PAGING COMMAND was receivedin an individual PAGINGCOMMAND message or if it was


16/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

Ref.name


received (as one of severalPAGING COMMANDs) within aMULTIPLE PAGING COMMANDmessage.

MC930 NB_ABIS_PAGING_MESSAGE_RECEIVED

Number of PAGINGCOMMAND / MULTIPLE

PAGING COMMANDmessage received by theBTS on Abis.

For legacy BSC, the value of thiscounter shall be set to "0".

For BSC EVOLUTION:a) This counter is increased by oneeach time a PAGING COMMANDmessage is received on Abisinterface.b) This counter is increased by oneeach time a MULTIPLE PAGINGCOMMAND message is receivedon Abis interface.

Based on this counters several indicators have been defined:


GCCIARQUSN CCCH_AGCH_useful_blocks_sent

Number of useful blocks sent on AGCHchannel.

MC925a

GCCPGRQUSN

CCCH_PCH_useful_blocks_sent

Number of useful blocks sent on PCHchannel.

MC925b

GCCRARQBUN

CCCH_RACH_busy_slots

Number of busy RACH slots. MC925c

GCCRACRQN CCCH_channel_request_radio

Number of channel request messagesreceived on the radio interface ornumber of access bursts successfullydecoded.

MC925d

GCCIACMABN CCCH_Immediate_Assign_Command_Abis

Number of 48.058 IMMEDIATE ASSIGNCOMMAND messages received by theBTS on Abis and had to be sent for CSand PS traffic to the MS.

MC925e

GCCIACMACN

CCCH_Immediate_Assign_Command_Abis_discarded_cong

Number of 48.058 IMMEDIATE ASSIGNCOMMAND messages received by theBTS on Abis and discarded due tocongestion.

MC925f

GCCPGRQABN

CCCH_Paging_Command_received_Abis

Number of 48.058 PAGINGCOMMAND messages received by theBTS on Abis and had to be sent for CSand PS traffic to the MS.

MC925g

GCCPGRQACN

CCCH_Paging_Command_Abis_discarded_cong

Number of 48.058 PAGINGCOMMAND messages received by theBTS on Abis and discarded due tocongestion.

MC925h

GCCMPGRQABN

CCCH_Paging_Multiple_Paging_Command_rec

Number of PAGING COMMAND /MULTIPLE PAGING COMMANDmessage received by the BTS on Abis.

MC930


17/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.


eived_AbisGCCPGRQACR

CCCH_Paging_Command_Abis_discarded_cong_rate

Rate of discarded "PAGINGCOMMAND" messages received by theBTS on Abis interface over the numberof "48.058 PAGING COMMAND"messages received by the BTS on Abisand had to be sent for CS and PS traffic

to the MS.

NZ(MC925h)/(MC925g)

GCCIACMACR CCCH_Immediate_Assign_Command_Abis_discarded_cong_rate

Rate of discarded "IMMEDIATE ASSIGNCOMMAND" messages received by theBTS on Abis interface over the numberof "48.058 IMMEDIATE ASSIGNCOMMAND" messages received by theBTS on Abis and had to be sent for CSand PS traffic to the MS.

NZ(MC925f)/NZ(MC925e)

GCCRARQER CCCH_RACH_efficiency_radio_rate

Rate of decoded RACH requests inrelation to the Number of busy RACHslots.

NZ(MC925d)/NZ(MC925c)

GCCPGRQO CCCH_PCH_load_radio

Load of the Paging Channel. MC925g/((1000/235)*(N1-BS_AG_BLK_RES)*GSM_obs_period * N2)N1=9 forBCCH noncombN1=3 forBCCH combN2=3

GCCPGRQO_MA

CCCH_PCH_load_radio_max

Max Nb of Paging Commands receivedon Abis / PCHcapacity

Max value forpreviousformula

GCCIARQRO CCCH_AGCH_load_radio

Load of the Access Grant Channel forCS traffic on radio interface.

MC925a/((1000/235)*BS_AG_BLK_RES*GSM_obs_period)

GCCIARQRO_MA

CCCH_AGCH_load_radio_max

Max Nb of AGCH useful blocks sent /AGCH Capacity


GCCRARQRO CCCH_RACH_load_radio

Load of the Random Access Channel inradio interface.

MC925d/((1000/235)*N1*GSM_obs_period)

GCCRARQRO_MA

CCCH_RACH_load_radio_max

Max Nb of Channel requests on RACH/RACH capacity



18/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

4.5 MIGRATION RULES

The feature must be activated in all cells inside a LAC in order to take benefit from more resourcesavailable on CCCH.

For ... Parameter name in B9 Parametervalue in B9

Parameter name in B10 Parametervalue in B10

Cell CCCH_CONF 0 and 1 CCCH_CONF 0, 1 and 2Activated=2


19/41


20/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

5.1.2 FEATURE ACTIVATIONThe feature may be activated or not on a per cell basis, by the O&M parameter:EN_2G_3G_HO_NO_SERVICE_HO

5.1.3 PARAMETERS

Parameter Description RangeObjectConditions/Rules

EN_2G_3G_HO_NO_SERVICE_HOAllows handovers towards 3G cellsfor a given MS when I.E. ServiceHandover is missing and the loadin the serving cell is high

0:Disable1:Enable

Cell

THR_CELL_LOAD_3G_REJECT Load threshold on the serving cellbelow which handovers towards3G cells are forbidden when I.E.Service Handover is missing andEN_2G_3G_HO_NO_SERVICE_HO= 1

0-100%

Cell 0 = disable(default)

5.1.4 COUNTERSRef. name Mnemonic Definition

R118,R218,R318 toR818

SCRAMBLING_CODE The scrambling code of a 3G FDDneighboring cell

R119.R219,R319 to

R819

FDD_FREQ The UTRAN Absolute RadioFrequency Number of a 3G FDDneighboring cell

R120,R220,R320 toR820

AV_ECNO The average receive Ec/No of a 3GFDD neighboring cell as seen bythe Mobile

HO1101,HO2101,HO3101to HO8101

SCRAMBLING_CODE The scrambling code of a 3G FDDneighboring cell

HO1102,HO2102,HO3102to HO8102

FDD_FREQ The UTRAN Absolute RadioFrequency Number of a 3G FDDneighboring cell

HO1103,HO2103,HO3103to HO8103

AV_ECNO The average receive Ec/No of a 3GFDD neighboring cell as seen bythe Mobile

MC924b NB_OUT_2G_3G_HO_REQ Number of outgoing 2G to 3Ghandover requests

MC924c NB_OUT_2G_3G_HO_SUC Number of outgoing 2G to 3G


21/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

Ref. name Mnemonic Definition

C handover successes towards a 3Gneighbor cell

MC924d NB_OUT_2G_3G_HO_ATPT

Number of outgoing 2G to 3Ghandover attempts

MC924e NB_OUT_2G_3G_HO_EXEC_FAIL_NO_REV

Number of outgoing 2G to 3Ghandover execution failures withoutreversion to old channel

MC924f NB_OUT_2G_3G_HO_EXEC_FAIL_REV

Number of outgoing 2G to 3Ghandover execution failures withreversion to old channel

MC924g NB_OUT_2G_3G_HO_PREP_FAIL

Number of outgoing 2G to 3Ghandover preparation failures

MC924h NB_2G_3G_HO_8 Provision for 2G to 3G HOMC924i NB_2G_3G_HO_9 Provision for 2G to 3G HOMC924j NB_2G_3G_HO_10 Provision for 2G to 3G HOMC924k NB_2G_3G_HO_11 Provision for 2G to 3G HO

Based on the counters defined several indicators are now available in B10 to check the featurebehavior:


HOOMSUUN

HO_Out_MSC_2G_3G_success

Number of Outgoing External 2G->3G HO successes (TCH).Thisincludes both inter-PLMN andintra-PLMN events.

MC924c

HOOMSUUR

HO_Out_MSC_2G_3G_success_rate

Rate of Outgoing External 2G->3G HO successes (TCH).Thisincludes both inter-PLMN andintra-PLMN events.

MC924c /MC924b

HOOMCDUN

HO_Out_MSC_2G_3G_drop

Number of Outgoing External 2G->3G HO execution failures due toBSS problems (transmission) andradio problem (TCH). As theproblem is located on the servingcell, the call is dropped. Thisincludes both inter-PLMN andintra-PLMN events.

MC924d-MC924c-MC924e-MC924f+MC924e

HOOMCDUR

HO_Out_MSC_2G_3G_drop_rate

Rate of Outgoing External 2G->3G HO execution failures due toBSS problems (transmission ) andradio problem (TCH). As theproblem is located on the servingcell, the call is dropped. Thisincludes both inter-PLMN and

intra-PLMN events

(MC924d-MC924c-MC924e-MC924f+MC924e) /MC924d

HOOMCDBUN

HO_Out_MSC_2G_3G_drop_BSS

Number of Outgoing External 2G->3G HO execution failures due toBSS problems (transmission)(TCH). As the problem is locatedon the serving cell, the call isdropped. This includes both inter-

MC924d-MC924c-MC924e-MC924f


22/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.


PLMN and intra-PLMN events.HOOMCDRUN

HO_Out_MSC_2G_3G_drop_radio

Number of Outgoing External 2G->3G HO execution failures due toradio problem (TCH). As theproblem is located on the servingcell, the call is dropped. Thisincludes both inter-PLMN and

intra-PLMN events.

MC924e

HOOMEFUR

HO_Out_MSC_2G_3G_efficiency_rate

Rate of Outgoing 2G->3Ghandovers successes over the totalamount of outgoing handoversrequests. This includes both inter-PLMN and intra-PLMN events.

MC924c /MC924d

HOOMCGUN

HO_Out_MSC_2G_3G_prep_fail

Number of Outgoing External 2G->3G HO preparation failures(TCH). This includes both inter-PLMN and intra-PLMN events.

MC924g

HOOMFLPUR

HO_Out_MSC_2G_3G_prep_fail_rate

Outgoing External 2G->3G HOpreparation failure rate (TCH). Thisincludes both inter-PLMN andintra-PLMN events.

MC924g /MC924b

HOOMPFUR

HO_Out_MSC_2G_3G_prep_fail_reject_rate

Rate of outgoing TCH HOpreparation failures due to Cause"HANDOVER REQUIRED REJECT"over the number of OutgoingExternal 2G->3G HO required.This includes both inter-PLMN andintra-PLMN events.

MC924g /MC924b

HOOMRQUN

HO_Out_MSC_2G_3G_request

Number of Outgoing External 2G->3G HO requests (TCH).Thisincludes both inter-PLMN andintra-PLMN events.

MC924d

HOOMRQTO

HO_Out_MSC_2G_3G_request_ratio

Ratio of Outgoing external 2G 3GHO in relation to all external HO.

MC924d /(MC924d +MC650)

HOOMRDUN

HO_Out_MSC_2G_3G_required

Number of Outgoing External 2G->3G HO required (TCH).Thisincludes both inter-PLMN andintra-PLMN events.

MC924b

HOOMOCUN

HO_Out_MSC_2G_3G_ROC

Number of Outgoing External 2G->3G HO execution failures due toto radio problem with reversion ofthe mobile to the old channel.(TCH). This includes both inter-

PLMN and intra-PLMN events.

MC924f

HOOMOCUR

HO_Out_MSC_2G_3G_ROC_rate

Rate of Return to old Channel inExternal 2G 3G HO in relation tothe 2G 3G Ho requests.

MC924f /MC924d


23/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

5.1.5 MIGRATION RULESFor ... Parameter name in B9 Parameter

value inB9

Parameter name in B10 Parametervalue inB10

Allcells

---- ---- EN_2G_3G_HO_NO_SERVICE_HO Disabled

5.2 SUPPORT OF COMPRESSED INTER-RAT INFO ELEMENT

5.2.1 FEATURE DESCRITPIONThe main objective of this feature is reduction of call setup time for dual mode mobiles. Enhance End user perception. Avoid loading SDCCH.In Rel5, a mandatory change is introduced for reduction of InterRAT Handover INFO message size. In the Immediate Assignment message, the Compressed_Inter_RAT_HO_INFO_IND indicates to

the MS whether a compressed version of the InterRAT Handover Info message shall be used ornot.

5.2.2 FEATURE ACTIVATIONThe feature may be activated or not on a per cell basis, by the O&M parameter:EN_Compressed_InterRAT_HO_Info

5.2.3 PARAMETERS

Parameter Description Range ObjectConditions/Rules

EN_Compressed_InterRAT_HO_InfoEnables the BSSto require theusage by a dualmode mobile ofthe compressed

format of INTERRAT HO INFO IE(when supportedby the mobile)

1 -compressedformat ofINTER RATHO INFO IE is

required fromthe MS.0 -compressedformat ofINTER RATHO INFO IE isnot requiredfrom the MS;

BSC Only ifEN_3G_HO = 1Shall be set to 1only if all RNCsneighbor to this

BSS support thefeature.

5.2.4 COUNTERS

See Countersparagraph of 2G to 3G handover based on 2G load and service criteria

5.2.5 MIGRATION RULESFor ... Parameter name in B9 Parameter

value inB9

Parameter name in B10 Parametervalue inB10

Allcells

---- ---- EN_Compressed_InterRAT_HO_Info 0


24/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

6 COUNTERS / PARAMETERS IMPROVEMENTS

6.1 CALL SETUP SUCCESS RATE METRIC


The goal is to provide a new metric, giving a view of the call setup success rate from the end userpoint-of-view. This means that the event call established would be compared to the event call

requested, instead of combining metrics related to the protocol mechanisms like it is done today(SDCCH drops, TCH allocation and assignation, etc.).

Operators would have a global view of the end-user perceived quality of their GSM network,whatever the problems encountered. Fastest detection and correction of problems would be possible,leading to improved quality.

Unlike the current implementation of Call Setup Success Rate indicator in B9 (CSSR = (1 -SDCCH_drop_rate) * (1 - RTCH_assign_unsuccess_rate)), the new B10 metric includes all failures thatcould impact the end-user call setup even those related to core network problems.


Automatic

6.1.3 PARAMETERS

None

6.1.4 NEW COUNTERS


25/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

C191 (type 19) becomes MC191(type 110): Number of Mobile Terminating SMS connections onSDCCH.

6.1.5 NEW INDICATOR

The formula used for the new indicator End_to_End_Call_setup_success_rate =

[RTCH_assign_success + DR_Out_internal_success + DR_Out_external_success] /[(MT_SDCCH_assign_success - SDCCH_SMS_MT_PP_connection) + SDCCH_success_Call_reestab +SDCCH_success_LU_follow_on + SDCCH_success_other_MO + SDCCH_success_NA_Emergency)].

This formula excludes SDCCH HO (HO_SDCCH_INHIBIT=1)

From counters perspective, this formula can be written as follows:

Where:

MC718:Number of TCH (HR or FR) normal assignment successes, per TRX. This counter also takesinto account normal assignment successes for TCH establishment in signalling mode (FR usage only),for DTM

MC142e=C142a+C142c:Number of outgoing normal or forced internal directed retry (towards aTCH channel in HR or FR usage) successes

MC142f=C142b+C142d:Number of outgoing normal or forced external directed retry (towards aTCH channel in HR or FR usage) successesMC01:Number of immediate assignment plus SDCCH normal assignment successes for MobileTerminating procedure

MC191:Number of Mobile Terminating SMS connections on SDCCH

MC02e:Number of SDCCHs successfully seized for Call Re-establishment

MC02d:Number of SDCCHs successfully seized for LU with follow-on bit set to 1 (means that theSDCCH phase will be followed by a TCH assignment for speech call establishment)

MC02f: number of immediate assignment successes for Mobile Originating procedure, in case of L3Info (within 48.058 ESTABLISH INDICATION) unknown by the BSC but transferred to the MSC

MC02h: Number of SDCCHs successfully seized for Normal or Emergency call

The new indicator is available in the Call_Success view within the NPO report Alc_Mono_call;here is an extract:

Short

name name Definition

MC191

NB_SMS_PP_CON_MT_SDCC

H

Number of Mobile Terminating

SMS connections on SDCCH.


26/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

Call success - BSC: Stuttgart124_O ( Stuttgart124_O ) - 05/12/2008 To 05/25/2008 (Working

Zone: Global - Medium)

0

1000

2000

3000

4000

5000

6000

05/12/2008

05/13/2008

05/14/2008

05/15/

200

8

05/16/2008

05/17/

2008

05/18/2008

05/19/

2008

05/20/2008

05/21/2008

05/22/2008

05/23/2008

05/24/200

8

05/25/

2008

nb

95.5%

96.%

96.5%

97.%

97.5%

98.%

98.5%

99.%

99.5%

100.%

%

Assign Unsucc

Call drop

SDCCH drop

% End to End Call setup

% Call success% Call setup

As the new indicator provides an end-user perception of call setup phase, taking into account thepossible core network problems; it is normal that E2E CSSR values are less than those provided byclassical CSSR. Indeed, the strong benefit of this new feature comes from the fact that all failures areconsidered (unlike classical CSSR)


None

6.2 PARAMETERS IMPROVEMENTS


EN_AMR_CA shall be removed and replaced by 2 parameters: EN_AMR_CA_FR_HR andEN_AMR_CA_HR_FR. These parameters shall have the same configuration as EN_AMR_CA.HO algorithms in the BSC shall be modified so that cause 26 and cause 27 are enabled separately.


Cause 26 and cause 27 are enabled separately with EN_AMR_CA_FR_HR and EN_AMR_CA_HR_FR.

6.2.3 PARAMETERS

HMI name Definition

Sub-

system Instance

OMC-R

access Type

Def

value Range Unit

EN_AMR_CA_FR_HR

This flag enables/disables intracell HO

for AMR channel adaptation

(Handover Cause 27). BSC cell

Changeab

le Flag 0 [0,1] None

EN_AMR_CA_HR_FR

s ag ena es sa es n r ace

for AMR channel adaptation

(Handover Cause 26). BSC cell

Changeab

le Flag 0 [0,1] None

6.2.4 COUNTERSNone


Shall be initiated at migration to the value given to EN_AMR_CA in B9.


27/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

6.3 NEW COUNTERS FOR CALL DROP WITH SPECIFIC RADIO CAUSES


Each time a BSS triggered call release happens, the BSC shall use the last valid measurementsreceived for this MS to compute what is the probable cause of the drop (according to some thresholdsto be defined, which are the same as those used for emergency handover causes). This information(bad level DL, bad quality UL, etc.) could then be used to increment the appropriate counters.

Notes:

1. The goal is not to modify the way the CLEAR REQUEST is triggered. It shall still be based onmissing SACCH measurements. However, the last measurements received before the drop(and before the SACCH measurements are missing of course) should be stored to computewhat is the probable cause of the drop (according to some thresholds to be defined).

2. If parameters used in the equations are not correctly tuned (e.g. the corresponding HO causeis not enabled), then it will result in incorrect reporting.

3. The window sizes used to calculate the averaged RxLev/RxQual measurements are based onthe HO window sizes: A_QUAL_HO, A_LEV_HO and A_RANGE_HO.

4. "Last valid measurements" mean the last received 48.058 MEASUREMENT RESULT messages

with S-BFI flag set to 0.

5. The new counters are triggered by BOTHTCH drop due to radio link failure (radio drops)ANDTCH drop during internal/external handover without reversion to old channel (handoverdrops).

This new feature would provide a fast and efficient way to know the cause of radio related call drops,and therefore to know which actions should be taken (parameters tuning, frequency planning, site re-engineering, etc.) to solve these call drop issues.

The below table shows the conditions that should be fulfilled in order to trigger the correspondingradio cause (the O&M parameters acting as thresholds are marked in blue).

Condition verified by last MS measurementsCause to bereported in

countersPriority

AV_RXQUAL_UL_HO > L_RXQUAL_UL_H+OFFSET_RXQUAL_FH

And

AV_RXLEV_UL_HO L_RXQUAL_DL_H+OFFSET_RXQUAL_FH

And

AV_RXLEV_DL_HO


28/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

AV_RXQUAL_UL_HO THR_RXQUAL_CAUSE_15 +OFFSET_RXQUAL_FH

AndAV_RXLEV_UL_HO > RXLEV_UL_IH

Too high interference

in the uplink

7

AV_RXQUAL_DL_HO > THR_RXQUAL_CAUSE_16 +OFFSET_RXQUAL_FH

And

AV_RXLEV_DL_HO > RXLEV_DL_IH

Too high interferencein the downlink

8


Automatic

6.3.3 PARAMETERS

None

6.3.4 COUNTERS

9 new counters (MC928a, MC928b, MC928c, MC928d, MC928e, MC928f, MC928g, MC928h andMC928i) at cell level in type 110:


29/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

Short Name Name Definition

MC928a

NB_TCH_DROP_CAUSE_TOO_LOW_QUALITY_

UL

Number of TCH drops due to Cause 2 (Too low

quality in UL).

MC928b NB_TCH_DROP_CAUSE_TOO_LOW_LEVEL_UL


level in UL).

MC928c

NB_TCH_DROP_CAUSE_TOO_LOW_QUALITY_

DL


quality on the downlink).

MC928d NB_TCH_DROP_CAUSE_TOO_LOW_LEVEL_DL


level in DL).

MC928eNB_TCH_DROP_CAUSE_TOO_LONG_MS_BS_DISTANCE

Number of TCH drops due to Cause 6 (Too longMS-BS distance).

MC928f

NB_TCH_DROP_CAUSE_TOO_SHORT_MS_BS_

DISTANCE

Number of TCH drops due to Cause 22 (Too short

MS-BS distance).

MC928g

NB_TCH_DROP_CAUSE_TOO_HIGH_INTERFER

ENCE_UPLINK

Number of TCH drops due to Cause 15 (Too high

interference level on the uplink).

MC928h

NB_TCH_DROP_CAUSE_TOO_HIGH_INTERFER

ENCE_DOWNLINK

Number of TCH drops due to Cause 16 (Too high

interference level on the downlink).

MC928i NB_TCH_DROP_OTHER_CAUSES

um er o rops ue o o er causes an

Cause 2 (Too low quality in UL), Cause 3 (Too low

level in UL), Cause 4 (Too low quality on the

downlink), Cause 5 (Too low level in DL), Cause 6

(Too long MS-BS distance), Cause 15 (Too high

interference level

The new counters are available on a new NPO report Alc_Mono_Drop_Causes, here is an exampleof Call drop radio causes view embedded in this report.


None

Call drop radio causes - CELL2G: S-Sued-B27-Weinsteige_1_B (28934/37576) (

262/F01/28934/37576 ) - 05/19/2008 To 05/21/2008 (Working Zone:

BSC_Stuttgart124_O_and_Stuttgart163_K - Medium)

0

2

4

6

8

10

12

14

16

05/19/2008 05/20/2008 05/21/2008

nb

.%

.5%

1.%

1.5%

2.%

2.5%

3.%

%

DL_Quality

DL_Level

DL_Interference

UL_Quality

UL_Level

UL_Interference

Short_Distance

Other_Causes

Long_Distance

% Call_drop_radio


30/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

6.4 NEW COUNTERS FOR SDCCH ASSIGNMENT SUCCESS RATE


Based on CMCC requirement (CR 3BKA20CBR243517), new counters were defined to better monitorSDCCH establishment phase taking into account invalid 48.058 CHANNEL REQUIRED messagesreceived by the BSC.

These counters are available from B10MR2Ed7 release.

Before B10 MR2 Ed7, the available counters used to monitor SDCCH allocation phase are:

1. MC8b (NB_IMM_ASS_CMD): Number of 48.058 IMMEDIATE ASSIGN COMMANDmessages (for non-(E)GPRS related establishment cause) sent on Abis to the MS

2. MC8c (NB_CELL_CHAN_REQD): Number of 48.058 CHANNEL REQUIRED received via theselected cell (for all establishment cause)

3. MC959 (NB_PS_CHAN_REQD): Number of 48.058 CHANNEL REQUIRED (for packetservice) received via the selected cell

4. MC960 (NB_DISCARDED_PS_CHAN_REQD_BECAUSE_GSL_CONGESTION): Numberof 48.058 CHANNEL REQUIRED (for packet service) received and discarded by the BSC incase of GSL congestion

Accordingly, it was not possible to detect invalid CHANNEL REQUIRED messages. One possibility toestimate the number of such messages was to apply the following formula:

Number of Invalid CS CHANNEL REQUIRED messages = (MC8c MC959) MC04 MC148,where MC04 counts the number of SDCCH channel rejections due to congestion and MC148 countsthe number of SDCCH allocations.

The figure below shows a part of successful SDCCH establishment procedure and the related existingcounters.

With the new counters provided in Ed7, it is now possible to count all the invalid CHANNELREQUIRED messages for both CS and PS establishments.

It is also possible to count the number of Non PS Channel Requests discarded due to congestion.The detailed description of new counters is presented in next section.


Automatic

6.4.3 NEW COUNTERS

MC962 (NB_INVALID_CHAN_REQD_RECEIVED_BY_BSC): Number of invalid 48.058CHANNEL REQUIRED (for all establishment cause) received by the BSC


31/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

MC963 (NB_NON_PS_CHAN_REQD_DISCRADED_BECAUSE_CONGESTION): Numberof valid 48.058 CHANNEL REQUIRED (for non-(E)GPRS related establishment cause)discarded by the BSC due to the congestion

6.4.4 NEW INDICATORS

Indicator Ref name Indicator Long Name Formula

GCCRAINVN CCCH_RACH_invalid MC962

GCCRACSCGN CCCH_RACH_discarded_CS_cong MC963

GCCRARQVAN CCCH_RACH_valid CCCH_RACH - CCCH_RACH_invalid

6.4.5 RELATED PARAMETERS

The following parameters are strongly linked to the new counter MC963:

WI_OP: Value of Wait Indication for Establishment cause = Location updating or Otherprocedures which can be completed with an SDCCH

WI_EC: Value of Wait Indication for Establishment cause = Emergency call

WI_CR: Value of Wait Indication for Establishment cause = Call Re-establishment

WI_OC: Value of Wait Indication for Establishment cause = Originating call

MC963 is incremented only if WI_OP, WI_EC, WI_CR & WI_OC are 255.

If these parameters are set to be 255, MC04 (which also counts the number of immediate assignmentpreparation failures due to congestion) should be equal to MC963.


Counters are available only starting from B10MR2Ed7.

No specific migration rules.

6.5 NEW COUNTERS FOR SDCCH ASSIGNMENT REQUEST FOR LOCATIONUPDATE


Based on Orange requirement (CR 3BKA20CBR260411), a new counter was created in B10MR2Ed7to monitor SDCCH establishment requests for Location Update procedure.

The existing counter (MC02A) provides the number of successful SDCCH seizure for Location Update.This corresponds to LU traffic, but there was no information before B10MR2Ed7 about the number of

LU requests.Thus, with the new counter (MC964), it will be possible to calculate the SDCCH success rate for LU.

Moreover, it will be possible to compare SDCCH assign success with and without Location update.This will be useful to analyze the impact of some bugged mobiles (not correctly managing LUprocedure between 3G and 2G) on global SDCCH assignment success rate.


32/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

Below is a comparison of SDCCH assign success with & without LU from a BSC in Ed7.

BSC : TARNOVO_9 (TARNOVO_9) - 05/01/2009 to 05/31/2009 (Working Zone:

Global - Medium)

.%

20.%

40.%

60.%

80.%

100.%

120.%

05/01/20

09

05/03/20

09

05/05/20

09

05/07/20

09

05/09/20

09

05/11/20

09

05/13/20

09

05/15/20

09

05/17/20

09

05/19/20

09

05/21/20

09

05/23/20

09

05/25/20

09

05/27/20

09

05/29/20

09

05/31/20

09

%

SDCCH_assign_success_rate(GSDNASUR) SDCCH_assign_success_wo_lu_rate(GSDNAWLUSUR)

It is clear that SDCCH assignment success rate is better when LU is not included.


Automatic

6.5.3 NEW COUNTER

MC964 (NB_VALID_LOCATION_UPDATE_RECEIVED_BY_BSC): Number of valid 48.058CHANNEL REQUIRED message, received by the BSC, indicating the location update in their"establishment cause For future usage.

6.5.4 NEW INDICATORS

Indicator B10-refname

Long Name NPO Formula

GSDNARQLUN SDCCH_assign_request_lu MC964

GSDNALUFLN SDCCH_assign_fail_lu SDCCH_assign_request_lu - SDCCH_traffic_lu

GSDNALUSUR SDCCH_assign_success_lu_rate SDCCH_traffic_lu / SDCCH_assign_request_lu

GSDNAWLUSUR SDCCH_assign_success_wo_lu_rate(SDCCH_assign_success - SDCCH_traffic_lu) /

(SDCCH_assign_request - SDCCH_assign_request_lu)


33/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

6.5.5 RELATED PARAMETERS

None


Counters are available only starting from B10MR2Ed7.

No specific migration rules.


34/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

7 DIFFERENTIATED RADIOLINK TIMEOUT FOR AMR CALLS


The main objective of the feature is to allow operators to fully enable AMR in their network,including the most robust AMR-FR codecs.

The use of AMR in B9 and previous releases networks is limited. This is mainly because in these

releases an increase of call drops with radio or handover causes was generally observed afteractivation of AMR, especially AMR-FR. This is a known issue, which was acknowledge by 3GPP in thedocument GP-041926.

This is because the signalling channels are less robust than some of the AMR voice codecs, whichleads to call drops (cause: radio link failure) in bad radio conditions, where the SACCH frames arenot decoded but the voice quality is still correct. Consequently, the call drop rate for AMR-FR calls ishigher than for EFR calls.

In such bad radio conditions, the voice quality in AMR-FR can still be fair where as in EFR, it is poorand the end-user ends the call himself in most cases.

Here below is the level of redundancy of EFR, AMR-FR and AMR-HR codecs:

Codec Redundancy

EFR (12.2 kb/s) 46.5%

AMR-FR 12.2 kb/s 46.5%

AMR-FR 10.2 kb/s 55.3%

AMR-FR 7.95 kb/s 65.1%

AMR-FR 7.40 kb/s 67.5%

AMR-FR 6.70 kb/s 70.6%

AMR-FR 5.90 kb/s 74.1%

AMR-FR 5.15 kb/s 77.4%

AMR-FR 4.75 kb/s 79.2%

AMR-HR 7.95 kb/s 30.3%

AMR-HR 7.40 kb/s 35.1%

AMR-HR 6.70 kb/s 41.2%

AMR-HR 5.90 kb/s 48.2%

AMR-HR 5.15 kb/s 54.8%

AMR-HR 4.75 kb/s 58.3%

The AMR-FR codecs 4.75 kb/s to 7.95 kb/s (highlighted in yellow in the above table) are more robustthan the SACCH frames which have a 60% redundancy.

In B9, the BSS uses the same Radio Link Timeout value for all calls. There are two parameters:RADIOLINK_TIMEOUT for the counter on MS side and RADIOLINK_TIMEOUT_BS for the BSS one.

The solution in B10MR2 was to differentiate the Radio Link Timeout for AMR calls (both AMR-FR andAMR-HR) versus the one for FR, EFR and HR calls. The Radio Link Timeout can thus be increased


35/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

specifically for AMR calls to delay the detection of the radio link failure. Consequently, the end-userbehaviour can be closer than with FR, EFR and HR.


The Radio Link Timeout for AMR is set on a per-cell basis.The feature is automatically activated upon migration to or installation of B10. Starting from this

release, one set of parameter defines the Radio Link Timeout for legacy codecs (FR, HR and EFR i.e.speech versions 1 and 2) and another set defines the Radio Link Timeout for AMR calls.On the other hand, the feature is disabled from a technical point of view as soon as the same valuesare set for the Radio Link Timeout for AMR and for legacy codecs.

7.3 PARAMETERS

Parameter name Definition Sub-system

Instance OMC-RCategory

Defaultvalue

Range Type

RADIOLINK_TIMEOUT_AMR Initial and maxvalue of MS radiolink counter,

when an AMRcodec is used.

OMC-R 2G cell changeable 16 4..64 Number

RADIOLINK_TIMEOUT_BS_AMR Initial and maxvalue of BSSradio linkcounter, when anAMR codec isused.

OMC-R 2G cell changeable 18 1..128 Threshold

Notes:

o The HMI name of RADIOLINK_TIMEOUT_BS_AMR is: RADIOLINK_FAILURE_THRES_AMR

o RADIOLINK_TIMEOUT_AMR is coded from 0 to 15 (0 = 4 Samfr, 1 = 8 Samfr ... 15 = 64Samfr); the step size is 1 = 4 Samfr

7.4 COUNTERS

No counter specific to this feature.

Standard CS Quality of Service and stability follow-up of the network should be performed duringmigration.

7.5 MIGRATION RULES

At migration from B9 to B10, the feature is actually idle as logical parametersRADIOLINK_TIMEOUT_AMR and respectively RADIOLINK_TIMEOUT_BS_AMR take the values of

RADIOLINK_TIMEOUT and respectively RADIOLINK_TIMEOUT_BS.

For Parametername in B9

Parametervalue inB9

Parameter name in B10 Parameter value inB10

Allcells

N/A N/A RADIOLINK_TIMEOUT_AMR Same asRADIOLINK_TIMEOUT


36/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

Allcells

N/A N/A RADIOLINK_TIMEOUT_BS_AMR Same asRADIOLINK_TIMEOUT_BS


37/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

8 STM1 CONNECTIVITY IN TC


This feature aims at reducing transmission cost which usually represents a significant part of the TotalCost of Ownership for a Network Operator. Traditionally based on E1 transport links, solutions for theGSM transport network have evolved to other technologies, such as SDH. This feature allows STM1connectivity at transcoder level.

STM-1 is available to the A and the Ater interfaces. However, depending on the operator's network,STM-1 transport may be used over the A interface only until there is a native support of STM-1 by theBSC (in B11MR1), alternatively an ADM equipment may be used for the Ater interface.

The speech transcoding function remains handled by the MT120 board (legacy MT120, or MT120-NB or MT120-WB), there is therefore no foreseeable impact on speech QoS. Any possible impact ofSTM-1 is limited to the QoS of the transmission over the A interface, and possibly of the Ater interfacewhen applicable.

The new JBTC-STM1 board offers four STM-1 (155Mb/s) optical interfaces to the TC A9125transcoder. The JBTC-STM1 boards are always paired off to provide a 1+1 redundancy, known as

Automatic Protection Switching (APS).

The board can be used in a mixed mode where a subset of its optical interfaces is used while part ofthe TC A9125 E1 interfaces remain in service. The granularity is at MT120 board level i.e. the whole

A interface of an MT120 board has to be transported over STM-1. The granularity is applicable to Aand Ater interfaces.

The OMC-R can supervise the JBTC-STM1 board and the STM-1 interface.

TC-STM1 feature is supported only by TC G2.5; it is available from B10MR2Ed7 release.

This feature doesnt offer telecom gains; only operational gains are offered, described below.

Feature benefits:

Integrated STM-1 interfaces on the BSS network elements help to:

Reduce cost on interface equipment to SDH network: Removal of E1 to STM-1 boards toconnect the TC to the SDH network (CAPEX saving).

Reduce drastically time/error of installation/cabling: Only 4 STM-1 interfaces are needed inTC to replace the 192 E1 links for A interface and 48 E1 links for Ater interface (OPEX saving).

Reduce the space needed for cables and distribution frames: The 8 STM1 fibers use much lesscable ways and distribution frames than the 252 PCM links (OPEX saving).

Simplify cabling & assignment changes: Modification of routing of a VC12 can be doneremotely by computer command, as there is no cabling change (OPEX saving).

Increase the reliability and availability: STM-1 connectivity provides excellent availabilitythanks to the combination of APS (Automatic Protection Switching) & EPS (EquipmentProtection Switching), as well as its benefit from the reliability of SDH network architecture(OPEX saving). Due to the high traffic per STM-1 link, protection is done by APS in

unidirectional/non-revertive configuration (this means that over longer time a link can bedistributed over two TCIF), coupled with EPS 1+1 for transmission board protection, providinghigh reliability and availability of the transmission links.


38/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.


This feature is optional from commercial point of view. It is activated as soon as the following actionsare completed:

Installation of JBTC-STM1 board, optical cables, HSI (High Speed Links)

STM1 configuration through the TC NEM

Declaration of STM1 links at OMC-R

8.3 PARAMETERS

Among the different parameters related to this feature; the below ones are those that can be relevantfor this documents reader. Other TC parameters are set by TC-NEM during TC-STM1 featurecommissioning.

Parameter name DefinitionSub-

systemInstance

OMC-RCategory

Defaultvalue

Range Type

Max-Number-STM1-Interface

Indicates the maximumnumber of STM1 interfacesallowed to be declared in theconsidered OMC

OMC-R OMC-R SITE (CAE) 0[0

None]Number

WarnThreshold-Limited-Features

Threshold above which awarning message shall bedisplayed to the user. It isexpressed as percentage ofthe upper limits defined forthelocked features.When the number of objectsconfigured with any of thelocked features exceeds thisthreshold, but is still below theupper limit, the user receivesawarning message

OMC-R OMC-R SITE (CAE) 95% [0100] Threshold

8.4 COUNTERS / INDICATORS

No new PM counters / indicators

8.5 MIGRATION RULES

None


39/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

9 GENERAL B10 QOS FEEDBACK

9.1 PARAMETERS VARIATIONS

9.1.1 PARAMETERS INSTANCE CHANGES

In B10 some parameters has changed its instance. For the further list, special attention should begiven after BSC migration to obtain the same parameterization as previous release,launching a MLU / PRC action if needed. Otherwise some variation might be observed in QoSindicators.

EN_DTM - This parameter changed instance from BSS -> cell T200_TF - This parameter became OMC-R changeable and changed instance from BTS ->

cell T200_TH - This parameter became OMC-R changeable and changed instance from BTS ->

cell

9.2 QOS VARIATIONS

9.2.1 BULGARIA

9.2.1.1 from B10MR2Ed3QD6 to B10MR2Ed6QD2

in Veliko Tarnovo, pilot area consists in 1 BSC : Tarvono_9.

QoS feedback: All KPIs are stable before and after the migration, no regression was observed CS domain.

9.2.1.2 from B10MR2Ed6QD2 to Ed7a then to ED7QD1

in Veliko Tarnovo, pilot area consists in 1 BSC : Tarvono_9.

QoS feedback: along different s/w versions All main KPIs are stable, for CS domains and PS domains A interface measurements show stable performances voice quality results confirmed non regression

9.2.1.3 from B10MR2Ed3QD6 to Ed7a then to Ed7QD1 then to Ed7QD2

pilot on BSC : Varna_96

QoS feedback: Main CS indicators are stable along different s/w versions CS indicators remain stable in Ed7QD2


40/41

ED 3 RELEASED


All

rightsreserved.


document,



lcatel-Lucen

t.

9.2.2 GERMANY

9.2.2.1 from B9MR4ed7 to B10MR2

the call drop remote TC was affected by the migration from B9MR4ed7 to B10MR2ed3.1

while it remains unaffected on the non migrated BSCs (Stuttgart179_M) still in B9.

the root cause was not found, no clear link with B10 relesase as been identified.

Call Drop BSS Remote TC - BSC - 14/07/2008 to 17/08/2008

0

50

100

150

200

250

300

14-07-20

08

16-07-20

08

18-07-20

08

20-07-20

08

22-07-20

08

24-07-20

08

26-07-20

08

28-07-20

08

30-07-20

08

01-08-20

08

03-08-20

08

05-08-20

08

07-08-20

08

09-08-20

08

11-08-20

08

13-08-20

08

15-08-20

08

17-08-20

08

nb

Stuttgart156_L

Stuttgart_Esslingen135_I

Stuttgart179_M

BSC

BSC : Stuttgart156_L - 27/07/2008 00:00 to 05/08/2008 23:00

0

5

10

15

20

25

30

35

40

45

27-07-2008

00:00

28-07-2008

00:00

29-07-2008

00:00

30-07-2008

00:00

31-07-2008

00:00

01-08-2008

00:00

02-08-2008

00:00

03-08-2008

00:00

04-08-2008

00:00

05-08-2008

00:00

nb

Call_drop_BSS_remote_TC(GQSCDBTN)

BSC


41/41

All

rightsreserved.


document,



lcatel-Lucen

t.

After migration, only peaks of Drop BSS RTC were observed, as opposed to the regular distributionover traffic hours observed in B9 (see example here above of hourly distribution for Stuttgart156_L).

All cells having Drop BSS RTC in B9 improved after migration.

The same improvement was observed on other pilot BSCs areas.

END OF DOCUMENT