counters_ericsson_vs_nokia.pdf

NOKIA vs ERICSSON FORMULAS

IntroductionThe aim of this document is to give a description of how to compare Nokia statistics to Ericsson statistics. Sinceboth Ericsson and Nokia provides a lot of counters and formulas only a few key formulas are investigated here.Most of the key formulas chosen are from Nokia data warehouse since the aim is to import the Ericssoncompliant formulas to this tool. Sometimes there is no possible comparison since the Nokia and Ericssonsystems work different. It should be observed that there exists no perfect compliant for any counters, there arealways differences, small or bigger.

Conversation startedNokia formula: The raw counter 057015, Conver_Started

Nokia counter Stepped on message Ericsson compliant57015: Conver_StartedSee figures 17, 23, 27, 29 and30.

When the BSC receivesConnect acknowledged fromthe MSC, or HandoverComplete o the MSC after asuccessful Handover.

TFCASSALL is almostcompliant. It is stepped onAssignment complete to theMSC.

Remark: Both Nokia 57015 and Ericsson TFCASSALL are updated on HO Complete o the MSC. This meansthat all calls that come in to the BSC are counted as if a conversation was started.

M S BTS BSC M SCAssignment Complete

Rf Channel release

Rf Channel release ack.

Alert Alert

Connect Connect

Connect Acknowledge

Connect Acknowledge

1

2

1: Nokia 570152: Ericsson TFCASSALL

TrafficNokia formula: ave_busy_tch/res_av_denom14=2027/2028Ericsson compliant: TFTRALACC/TFNSCAN

Both Ericsson and Nokia are taking average values over a certain timeperiod. The difference is that Ericssontakes the samples each 10th second while Nokia takes them each 20th second. This is probably of minor impactfor the result.

Network call minutesThe traffic multiplied by 60.

Normalized BH TCH Utilisation (GoS=1 %):

Nokia formula: BH_TCH_Traffic (Average 3 days peak)/Norm_Util

Where Norm_Util=sum(Erl(1 %)*TCHi and

TCHi=number of defined TCH channels for a cell.

Ericsson formula:The traffic formula is described above and the Erl(1%) is taken from tables. Left is TCHi and the Ericssoncompliant for that one is TNUCHCNT.

SDCCH Access Probability (formula no 1 in call success factor):

Nokia formula 100 - SDCCH Blocking =

sum(a.sdcch_busy_att) 100 - --------------------- * 100 %=100-1001/1000*100% sum(a.sdcch_seiz_att)where

a: Traffic Measurement (ps_bsc_traffic_day/week/bh/week_bh, ps_bts_traffic_day/week/bh/week_bh)Comments

SDCCH access probability gives an indication of the congestion of the SDCCH signalling. All the SDCCH requests are counted in this since the probability of getting an SDCCH, is the same for

the different requests. Some of the possible requests are: call, location update, IMSI attach and detach, SMS.

Know problems FACCH setup is causing unnecessary blocking from the call point of view. In theory problems can be caused by 2 TRX cells, where SDCCH is configured to both TRXs. If the

first TRX is congested, the busy counter is updated even if the second TRX is offering service.

Nokia counter Stepped on message Ericsson compliant1001: Sdcch_busy_attfigures 5, 6 and 18.

Number of the timeswhen an MS attemptsto seize an SDCCHunsuccessfullybecause all SDCCHsare busy.UPDATED: When the RRMhas no SDCCHs toallocate for a callor HO attempts.Updated after Channelrequired, beforeChannel activation

CCONGS

1000: Sdcch_seiz_attfigures 2, 5, 6, 18,42, 46, 48 and 57.

Number of the timeswhen an MS attemptsto seize an SDCCH.UPDATED: When the RRMreceives requests forSDCCH from an MS asthe MS needs achannel for either acall or a HO.Updated after Channelrequired, beforeChannel activation

CCALLS

Ericsson compliant formula: 100-CCONGS/CCALLS*100%

SDCCH Success Rate (formula no 2):Nokia formula:

sum(a.tch_norm_seiz) ------------------------------------------------------ * 100 % sum(b.succ_seiz_term + b.succ_seiz_orig + b.sdcch_call_re_est + b.sdcch_emerg_call - (b.succ_sdcch_sms_est + b.unsucc_sdcch_sms_est) + c.msc_i_sdcch + c.bsc_i_sdcch - c.msc_o_sdcch - c.bsc_o_sdcch

- (a.tch_call_req - a.tch_norm_seiz))=1009/(3012+3013+3020+3021-(3028+3029)+4045+4058-4051-4066-(1026-1009))where

a: Traffic Measurement (ps_bsc_traffic_day/week/bh/week_bh, ps_bts_traffic_day/week/bh/week_bh) b: Resource Access Measurement (ps_bsc_traffic_day/week/bh/week_bh,

ps_bts_traffic_day/week/bh/week_bh) c: Handover Measuremnet (ps_bsc_traffic_day/week/bh/week_bh,

ps_bts_ho_power_day/week/bh/week_bh)Comments

SDCCH success ratio gives estimate on how SDCCH channel reservation is succeeding. It includes A-interface blocking.

Known problems There are unknown factors in the denominator: supplementary service requests and call clears before

TCH. These unknown factors can make the values look overly pessimistic. The raw measurement counters for this formula are collected from different measurement types of the

network element. If data is missing from one of them, the result may exceed 100%. Check the collectedperiod durations in this case.

Nokia counter Stepped on message Ericsson compliant3012: b.succ_seiz_termSee figure 2

Establish indication (withpaging response) on SDCCH

CMSESTAB is including 3012.CMSESTAB is updated onSCCP connection confirmed,Handover complete andHandover performed.

3013: b.succ_seiz_origSee figure 2

Establish indication (CMservice request) on SDCCH

CMSESTAB is including 3013

3020: b.sdcch_call_re_estSee figure 2

Establish indication (call re-establishment) on SDCCH


3021: b.sdcch_emerg_callSee figure 2

Establish indication (emergencycall) on SDCCH


3028: b.succ_sdcch_sms_estSee figures 10 and 11

Establish indication (MO SMS)on SDCCH or establish_confirm(MT SMS)


3029: b.unsucc_sdcch_sms_estSee figures 12 and 13

Establish indication (MO SMS)on SDCCH or establish_confirm(MT SMS)


4045: c.msc_i_sdcchSee figure 8

See fig 4,8,12,52,53HO Complete BSC to MSC

CMSESTAB is includingincoming SDCCH Handovers.Both 4045 and 4058 areincluded.

4058: c.bsc_i_sdcchSee figure 6

HO Performed CMSESTAB is includingincoming SDCCH Handovers.Both 4045 and 4058 areincluded.

4051: c.msc_o_sdcchSee figure 7

Clear Command (MSC-BSC) insource BSC.Cause code ?

CCHHOSUC is partlycompliant. It is updated on ClearCommand from the MSC, HOperformed to the MSC, andAssignment Complete to theMSC. But CMSESTAB is notincluding outgoing Handovers(on SDCCH) so no correctionhas to be done for 4051 and4066

4066: c.bsc_o_sdcchSee figure 6

Same as 4058 but differentdirection

Same info as for 4051.

1026: a.tch_call_reqSee figures 2, 3, 8, 9, 10, 11, 26,34, 51, 52, 54 and 55.

Number of the TCH requests fora normal assignment (bothsuccessful andunsuccessful).After PhysicalContext confirm, beforeChannel activation.

TASSALL (Both 1026 andTASSALL includes outgoingDirected retries)

1009: Tch_norm_seizFigures 2,3,9,51,54

Number of the successfulrequests for a TCH in a normalassignment.Updated when the RRMallocates a TCH as a response toa TCH request in a call attempt.Updated between PhysicalContext confirm and Channelactivation

TASSALL-HOASWCL

1026-1009 Both are updated After PhysicalContext confirm, beforeChannel activation.

1026 and 1009 are updated inthe some moment of the callsetup. 1026 is updated onassignment failures, which 1009is not. When taking thedifference 1026-1009 youbasically get outgoing directedretries+assignment failures, so1026-1009= TASSALL-TFCASSALL+HOASWCL

In the Nokia formula SMS messages are excluded which is not possible in CMSESTAB. CMSESTAB isincluding both SMSs and incoming SDCCH handovers.Ericsson formula : (TASSALL-HOASWCL)/ (CMSESTAB-CSMSUP-(TASSALL-TFCASSALL+HOASWCL))

M S B TS B SC M SC

1

1:N okia counters 1009 and 1026 are updated here 2: Ericsson counter TA SSA LL steps on A ss. R equest, w hile TFC A SSA LL steps on A ss. C om plete

O bserve that the m essages Physical context confirm and request does not exist in Ericsson system s

2

Sabm Establish indication

U a

A ssignm ent com plete A ssignm ent com plete

A ssignm ent com m and

C hannel activation ack.

C hannel activation

Physical context confirm

Physical context request A ssignm ent request

2

Idea behind the Ericsson formula: In the nominator Nokia has a counter which is counting what is calledsuccessful requests for a TCH in a normal assignment. Looking in the flowchart gives that the Ericsson-counter for assignment attempts (TASSALL) actually is closer than the assignment successful counter(TFCASSALL). Since TASSALL includes assignment Handovers but Nokias 1009 does not, the compliant of1009 is concluded to be TASSALL-HOASWCL.The denominator: Since the formula is based on that a TCH assignment attempt is made, SDCCH allocationsthat never end up in a TCH assignment attempt has to be removed. Nokia is compensating this by removingSMS (successful and unsuccessful). Ericsson has the similar CSMSUP. Neither Nokia nor Ericsson iscompensating for Location updates, which should be done. There are probably counters for that in theNokia MSC.Note: There is a predefined formula in Ericsson for SDCCH success rate: (CMSESTAB-CNDROP)/CMSESTAB. Nokia has chosen to count successful SDCCH rate as all normal TCHassignment attempts (directed retries not included) divided by SDCCH successful establishments.Outgoing directed retries and unsuccessful assignments are compensated for. Ericsson prefer to use (CMSESTAB-CNDROP)/CMSESTAB , but (TASSALL-HOASWCL)/(CMSESTAB-CSMSUP-(TASSALL-TFCASSALL+HOASWCL) is probably closer to the Nokia formula.

M S BTS BSC M SC

Sabm

Establish Indication

Paging R esponseU a

1

1: 3012,3013,3020,3021,3028 (stepped also on another m essage) and 30292: C M SESTA B is stepped here and also on H O C om plete and H O Perform ed

SC CP C onnection request (Ericsson)

SC CP C onnection confirm (Ericsson)2

Im m ediate A ssign

Im m ediate assign com m and

C hannel A ctivation ack.

C hannel A ctivation

C hannel required

C hannel R equestPaging R equest

PagingPaging C om m and

1000,1001 C C A LLS,C C O N G S

TCH Access Probability (formula no 3):Nokia formula:100 - TCH Call Blocking =

sum(a.tch_call_req - a.tch_norm_seiz - (b.msc_o_sdcch_tch + b.bsc_o_sdcch_tch +b.cell_sdcch_tch)

- (a.tch_rej_due_req_ch_a_if_crc - (b.bsc_i_unsucc_a_int_circ_type + b.msc_controlled_in_ho + b.ho_unsucc_a_int_circ_type))100 - ------------------------------------------------------- * 100 %= sum(a.tch_call_req - (a.tch_rej_due_req_ch_a_if_crc - (b.bsc_i_unsucc_a_int_circ_type + b.msc_controlled_in_ho + b.ho_unsucc_a_int_circ_type))

1026 - 1009- (4050 + 4065+ 4074)- (1122- (4097+ 4101+ 4098))=100 - ------------------------------------------------------------ * 100 % 1026- (1122- (4097+ 4101+ 4098))where

a: Traffic Measurement (ps_bsc_traffic_day/week/bh/week_bh, ps_bts_traffic_day/week/bh/week_bh) b: Handover Measurement (ps_bsc_traffic_day/week/bh/week_bh,

ps_bts_ho_power_day/week/bh/week_bh)

Nokia counter Updated Ericsson compliant1026-1009 Number of the TCH requests for

a normal assignment (bothsuccessful and unsuccessful).Both are updated After PhysicalContext confirm, beforeChannel activation.

1026 and 1009 are updated inthe some moment of the callsetup. 1026 is updated onassignment failures which 1009is not. When taking thedifference 1026-1009 youbasically get outgoing directedretries+assignment failures, so1026-1009= TASSALL-TFCASSALL+HOASWCL

1026: a.tch_call_reqSee figures 2, 3, 8, 9, 10, 11, 26,34, 51, 52, 54 and 55.

After Physical Context confirm,before Channel activation.

TASSALL (Both TASSALLand 1026 includes directedretries)

4050: msc_o_sdcch_tchSee figure 11

When a directed retry procedureis completedExternal directed retry in sourceBSC (Clear command fromMSC)

Directed retry is included aboveIn the counter TFCASSALLthat gives we should take awayHOSUCWCL which isreplacing 4050+4065+4074.This is already done in theformula for 1026-1009

4065: bsc_o_sdcch_tchSee figures 10 and 55

When a directed retry procedureis completed.Updated on assignmentcomplete.- When the direct access fromthe SDCCH to TCH on a super-reuse TRX is completed.- When the intelligent directedretry is completed.- When the TCH assignment toa super-reuse TRX iscompleted.

See above

4074: cell_sdcch_tchSee figures 9 and 54

Updated on assignment to IUOwhich is not used in EricssonBTSs in this network- When a channel assignment toa super-reuse TRX in an IUODR is completed.- When the direct access to asuper-reuse TRX is completed.

Underlaid/overlaid HO countersfor directed retry, but the featureis not in use in the EricssonBSC

1122:tch_rej_due_req_ch_a_if_crcSee figure 11 (This counter isrelated to halfrate)

Number of the requests for TCHrejected due to mismatchbetween the types of therequested channel and the Ainterface circuit, whetherqueuing occurred or not.Updated on the same messageas 1026,but with different cause.

TASSALL is already coveringthis Nokia counter.

4097:bsc_i_unsucc_a_int_circ_typefigures 33 and 36

UPDATED: When an internalincoming inter-cell HO attemptis interrupted because the BSCwants to change the A interfacecircuit pool before TCHallocation.Incremented after Meas result,before HO required

HO required counter for intracell HO failures. No Ericssoncompliant. If an A-interfacefailure occurs other counters insource cell will be updatedinstead. But these counters arealso updated for other thingswhich make it impossible tocompare

4101: msc_controlled_in_hofigure 34

UPDATED: When the HOattempt ends due to an attemptof TCH allocation which isunsuccessful because of themismatch between the requestedTCH channel type and the Ainterface circuit type. The causeswitch_circuit_pool is sent inthe HANDOVER_FAILUREmessage to the A interface.


4098:ho_unsucc_a_int_circ_typeFigures 32 and 35

UPDATED: When an internalintra-cell HO attempt isinterrupted because the BSCwants to change the A interfacecircuit pool before TCHallocation.After Physical context confirm,before HO required


There is no Ericsson formula that can be directly converted counter by counter from the Nokia formulafor TCH Call blocking. Nokia is counting unsuccessful TCH seizures which in Ericsson is counted assomething totally other than TCH congestion. The reason is that the Nokia counters are stepped atassignment attempts, and if there is congestion in Ericsson there will never be any assignment attempt,the call trial is interrupted before that.A suggestion of congestion formula from Ericsson for Attempt congestion is(CNRELCONG+TFNRELCONG)/(TASSALL-HOASWCL)

CNRELCONG is number of released connections on SDCCH due to TCH- and transcoder congestion.TFNRELCONG is stepped when there is a release of a TCH connection due to transcoder congestion during animmediate assignment on TCH. Immediate assignment on TCH is an Ericsson feature that allows you to set up acall without using the SDCCH.TASSALL-HOASWCL gives the number of assignment attempts that have been done in the cell whenassignment to worse cell (Nokia: directed retry) is not included.

TCH Success (4th part in the call success formula):Nokia formula:100 - TCH Drop Rate =

sum(a.tch_radio_fail + a.tch_rf_old_ho + a.tch_abis_fail_call + a.tch_abis_fail_old + a.tch_a_if_fail_call + a.tch_a_if_fail_old + a.tch_tr_fail + a.tch_tr_fail_old + a.tch_lapd_fail + a.tch_bts_fail + a.tch_user_act + a.tch_bcsu_reset + a.tch_netw_act + a.tch_act_fail_call - (b.sdcch_call_re_est + b.tch_call_re_est)) 100 - ------------------------------------------------------------- *100 % sum(a.tch_norm_seiz + c.msc_i_sdcch_tch+c.bsc_i_sdcch_tch+c.cell_sdcch_tch + a.tch_seiz_due_sdcch_con - (b.sdcch_call_re_est + b.tch_call_re_est)where

a: Traffic Measurement (ps_bsc_traffic_day/week/bh/week_bh, ps_bts_traffic_day/week/bh/week_bh) b: Resource Access Measurement (ps_bsc_traffic_day/week/bh/week_bh,

ps_bts_traffic_day/week/bh/week_bh) c: Handover Measurement (ps_bsc_traffic_day/week/bh/week_bh,

ps_bts_ho_power_day/week/bh/week_bh)Comments

TCH success ratio gives an indication about the number of calls which ended normally. Call re-establishment is compensated. Incoming directed retry is included.

Known Problems Failures which are causing call drop are included in the calculation.

Nokia counter Stepped on message Ericsson compliant1013:a.tch_radio_failSee figure 64

Radio link timeout, releaseindication from MSUpdated on assignment failure toMSC (just before Clear commandfrom MSC)

TFNDROP

1014:a.tch_rf_old_hoSee figure 31

HO failure during HO attemptUpdated on Rf channel releaseacknowledge

TFNDROP

1084: a.tch_abis_fail_callSee figures 13, 14 and 17

Abis interface failure on the oldchannel during TCH HandoverUpdated on Assignment failure

TFNDROP

1085:a.tch_abis_fail_oldNo figures

Abis interface failure on the oldchannel during TCH handoverNot possible to find where it isupdated

?

1087:a.tch_a_if_fail_callSee figure 15

A interface failure, for example:Clear command from MSC duringcall setup phase before assignmentcomplete from MS, and abnormalclear received due to air interface(reset ciruit, SCCP clear by RLSD)Updated on Rf channel releaseacknowledge (which in this casecomes after the clear command)

TFNDROP

1088:a.tch_a_if_fail_oldSee figure 39

A interface failure (handoverfailure) on the old channel duringTCH handover attempt)Updated on Rf channel releaseacknowledge

TFNDROP

1029:a.tch_tr_failSee figure 16

Transcoder failure during callattemptUpdated on Rf channel releaseacknowledge

TFNDROP

1030:a.tch_tr_fail_oldNo figures

Not possible to find where it isupdated

?

1046:a.tch_lapd_failSee figure 17

Transcoder failure on the oldchannel during a handover attempt,that is before handover/assignmentcomplete received from the MS

Blocked TRXes does not cause dropcalls. Traffic is rerouted to anotherTRX instead

1047:a.tch_bts_failSee figure 17

TRX block caused by LAPDfailure. Blocked TRX due tosignalling link fault or PCM fault


1048:a.tch_user_actSee figure 17

TRX block caused by BTS failure.Blocked TRX due to FU fault, CUfault, BTS reset, BCF reset, bothCU and FU fault, BCF fault.


1049:a.tch_bcsu_resetNo figures

TRX block caused by BCSU restart Blocked TRXes does not cause dropcalls. Traffic is rerouted to anotherTRX instead

1050:a.tch_netw_actSee figure 17

TRX block caused by failure whichlead to TRX reconfiguration.Blocked TRX in substate: blockedby system


1081:a.tch_act_fail_callSee figure 12

Failure of channel activation(channel activation nack received)in the BTSUpdated on Rf channel releaseacknowledge

TFNDROP

1009:a.tch_norm_seizSee figures 2, 3, 9, 51 and 54

Number of the successful requestsfor a TCH in a normal assignment.Updated when the RRM allocates aTCH as a response to a TCHrequest in a call attempt. Updatedbetween Physical Context confirmand Channel activation

TFCASSALL-HOASWCL

3020: sdcch_call_re_estFigure 2

UPDATED: When anESTABLISH_INDICATIONmessage for a call re-establishmentis received on SDCCH from theBTS. (Before paging response)

No Ericsson counter for that.Call re-establishment is a Nokiafeature that has no Ericssoncompliant. At the moment thisfeature is not turned on, though.

3025: tch_call_re_estfigure 3

Number of the successful seizuresof TCHs for call re-establishmentin FACCH call setup due toSDCCH congestion. If FACCHcall setup is turned off, the countervalue is zero.UPDATED: When anESTABLISH_INDICATIONmessage for a call re-establishmentis received on TCH from the BTS.

No Ericsson counter for that.Call re-establishment is a Nokiafeature that has no Ericssoncompliant. At the moment thisfeature is not turned on, though.

The closest (and only) Ericsson formula is 100-TFNDROP/TFNSCAN*100%

Observe that the old Nokia formula used in the old post-processing tool differs a little from the onedefined in Nokia Data warehouse.

SDCCH Availability PercentageNokia Formula: sum(a.ave_sdcch_sub) -------------------------------------------- * 100 % sum(a.ave_sdcch_sub + a.ave_non_avail_sdcch)where

a: Resource Availability Measurement (ps_bsc_traffic_day/week/bh/week_bh,ps_bts_traffic_day/week/bh/week_bh)

Nokia counter Stepped on message Ericsson compliant2004: ave_sdcch_subNo figures available

Average number of theSDCCHs available. This figureis received by dividing the valueof this counter by the value ofthe next counter.UPDATED:-When a TRX is deblocked-When a TRX is blocked-When an SDCCH TSL isdeblocked-When an SDCCH TSL isblockedThe counter is sampled every 20seconds.

CAVAACC/CAVASCAN

(Average number of availableSDCCHs)

2038: ave_non_avail_sdcchNo figures available

Average number of theSDCCHs not available. Thisfigure is received by dividingthe value of this counter by thevalue of the next counter.UPDATED:- When a TRX is deblocked- When a TRX is blocked- When an SDCCH TSL isdeblocked- When an SDCCH TSL isblockedThe counter is sampled every 20seconds.

CNUCHCNT-CAVAACC/CAVASCAN

Ericsson formula=CAVAACC/(CAVASCAN*CNUCHCNT)*100 %

The difference between Ericsson and Nokia counters is that Ericsson takes the samples each 10th second whileNokia takes them each 20th second. This is probably of minor impact for the result. Both Ericsson and Nokia isshowing average numbers of available channels over a certain time period.

TCH Availability PercentageNokia formula sum(a.ave_avail_full_tch) ----------------------------------------------- * 100 % sum(a.ave_avail_full_tch + a.ave_non_avail_tch)where

a: Resource Availability Measurement (ps_bsc_traffic_day/week/bh/week_bh,ps_bts_traffic_day/week/bh/week_bh)

Nokia counter Stepped on message Ericsson compliant2002: ave_avail_full_tchNo figures available

Average number of the FR radioTCHs available. This figure isreceived by dividing the valueof this counter by the value ofthe next counter.UPDATED:- When a TRX is deblocked- When a TRX is blocked- When a TCH TSL isdeblocked- When a TCH TSL is blockedThe counter is sampled every 20seconds.

TAVAACC/TAVASCAN

(Average number of availableTCHs)

2040: ave_non_avail_tchNo figures available

Average number of the TCHsnot available. This figure isreceived by dividing the valueof this counter by the value ofthe next counter.UPDATED:- When a TRX is deblocked- When a TRX is blocked- When a TCH TSL isdeblocked- When a TCH TSL is blockedThe counter is sampled every 20seconds.

TNUCHCNT-TAVAACC/TAVASCAN

Ericsson formula=TAVAACC/(TAVASCAN*TNUCHCNT)*100 %

The difference between Ericsson and Nokia counters is that Ericsson takes the samples each 10th second whileNokia takes them each 20th second. This is probably of minor impact for the result. Both Ericsson and Nokia isshowing average numbers of available channels over a certain time period.

Total Handover Failure RatioNokia formula: successful HOs (1 - -------------- ) * 100 % = HO attempts

sum(a.msc_o_succ_ho + a.bsc_o_succ_ho + a.cell_succ_ho) (1 - ----------------------------------------------------------) * 100 % sum(a.msc_o_tch_tch_at + a.msc_o_sdcch_tch_at + a.msc_o_sdcch_at + a.bsc_o_tch_tch_at + a.bsc_o_sdcch_tch_at + a.bsc_o_sdcch_at + a.cell_tch_tch_at + a.cell_sdcch_tch_at + a.cell_sdcch_at)=1- (4004+4014+4018)/(4052+4053+4054+4067+4068+4069+4076+4077+4078)where

a: Handover Measurement (ps_bsc_traffic_day/week/bh/week_bh)Comments

In a good network the value can be less than 3 per cent, while in a very bad network values higher than15 per cent may occur.

If Directed Retry is enabled, the MS may, when congestion of the source cell SDCCH occurs, bemoved from the best cell to a worse one. Then the MS tries to make a handover back but fails if thefirst cell is still congested. This leads to incrementation of the HO failure ratio.

Known Problems Blocking is included. Blocking makes this indicator show high values especially in the case of IUO,

but it does not necessarily mean that there are some technical problems. Calls that are cleared by the MS user during the HO process increases the attempt-counters but cannot

be compensated in the numerator. HO that is interrupted due to some other procedure (for example, assignment) increases the attempt-

counters but cannot be compensated in numerator. This formula works best on area and network level.

Nokia counter Stepped on message Ericsson compliant4004: msc_o_succ_hofigures: 3, 7, 11, 35, 36 and 51

Clear command from MSC tosource BSCNumber of the successful outgoingHOs controlled by the MSC.UPDATED: When the HO(SDCCH to SDCCH, SDCCH toTCH or TCH to TCH) iscompleted.

Ericsson can only count outgoingHandovers from a BSC. This means theHandover can also be to another MSC.HOVERSUC is including handovers toexternal cells (i.e. other BSCs andMSCs)HOVERSUC is stepped on Clearcommand to the MSC, HandoverPerformed, and assignment complete (tothe MSC)

4014: bsc_o_succ_hoFigure 6

Number of the successful outgoingHOs controlled by the BSC.UPDATED: When the HO(SDCCH to SDCCH, SDCCH toTCH or TCH to TCH) iscompleted.Handover performed BSC to MSC

HOVERSUC is covering handoversbetweeen internal cells.

4018: cell_succ_hoSee figures: 1, 5, 9, 47, 48 and 54

Number of the successful intra-cellHOs.UPDATED: When the HO(SDCCH to SDCCH, TCH to TCHor SDCCH to TCH) is completed.Handover performed BSC to MSC

HOINSUCStepped on message Handoverperformed to MSC.

4052: msc_o_tch_tch_atfigures 3,35,36

Between Measurement result andHandover required.

HOVERCNT=4052+4067Stepped on Handover command to theMS

4053: msc_o_sdcch_tch_atFigure 11

Between Queing indication andHandover required.

HOASWCL to external cell. In Ericssonsome parameters in the (Ericsson) MSChas to be set to allow assignmenthandovers to external cells. What aboutthe Nokia MSC?HOASWCL=4053+4068Stepped on assignment requestHOVERCNT is including 4053

4054: msc_o_sdcch_atfigure 7

Between Measurement result andHandover required.

CCHHOCNT: SDCCH handoverattempts, both to internal and externalcells. . I.e. 4054+4069=CCHHOCNTStepped on Handover command to theMS. HOVERCNT is including SDCCHhandovers.

4067: bsc_o_tch_tch_atFigures 2 and 56

Between Measurement result andchannel activation

HOVERCNT=4052+4067

4068: bsc_o_sdcch_tch_atFigures 10 and 55

Between Measurement result andchannel activation

HOASWCL to internal cells.HOASWCL=4053+4068Stepped on assignment requestHOVERCNT is including 4068

4069: bsc_o_sdcch_atFigure 6

Between queing indication andchannel activation

CCHHOCNT: SDCCH handoverattempts, both to internal and externalcells. I.e. 4054+4069=CCHHOCNTStepped on Handover command to theMS. HOVERCNT is including SDCCHhandovers

4076: cell_tch_tch_atFigure 1

TCH to TCH intra cell HandoverUpdated between Measurementresult and Physical contextrequest

HOINDQA+HOINUQA+HOINBQAThey are stepped when an allocationattempt is received (Channel activationacknowledge)

4077: cell_sdcch_tch_atFigures 9 and 54

Directed retry at intra cellhandover.Stepped after Queing indicationand before Physical context requestOR between Assignment requestand Physical context request

Directed retry at intra cell handover toUnderlaid\Overlaid does not exist inEricssons system

4078: cell_sdcch_atFig.5

Intra cell Handover on SDCCH.Between Measurement result andPhysical context request.

Intra cell Handovers are possible toobtain on SDCCH by setting parameterIHOSICH to ON.HOINDQA+HOINUQA+HOINBQA

Ericsson formula: (HOVERSUC+HOINSUC)/(HOVERCNT+HOINDQA+HOINUQA+HOINBQA)

Uplink interference measurementsEricsson has the same structure of uplink measurements as Nokia has. The interference is divided into fivebands. The range for each band is set by parameters called LIMIT1,LIMIT2, LIMIT3 and LIMIT4. To be ableto compare Nokia and Ericsson uplink interference, these parameters has to be set to the same as thecorresponding Nokia values. There is also a parameter called INTAVE that defines the time period that the ULinterference is averaged over. This should also be adapted to the Nokia setting if possible.There are one counter for each band (as long as there exist no halfrate and no overlaid cells). These counters areITFUSIB1,ITFUSIB2,ITFUSIB3,ITFUSIB4 and ITFUSIB5. To retrieve the percentage of Uplink interferencein a certain band the counter for that band is divided into the sum of the 5 counters. As an example(ITFUSIB4+ITFUSIB5)/(ITFUSIB1+ITFUSIB2+ITFUSIB3+ITFUSIB4+ITFUSIB5) gives the percentage ofsamples that are in interference band 4 and 5.

TCH Access Failure ratePercentage of failed attempts for timeslot seizure. The seizure did not occur neither at the initial cell nor at anadjacent cell.Formula: 1- (TCH_norm_seiz+succ_og_DR)/TCH_call_req

Where succ_og_DR=BSC_O_SDCCH_TCH+MSC_O_SDCCH_TCH

Nokia counter Stepped on message Ericsson compliant1009: TCH_norm_seizfigures 2, 3, 9, 51 and 54

1009 does not include DR while1026 include DR

TASSALL-HOASWCL

4065: BSC_O_SDCCH_TCHSee figures 10 and 55

Updated on Assignment complete HOSUCWCL=4065+4050

4050: MSC_O_SDCCH_TCHSee figure 11

Updated on Clear command fromMSC to BSC

HOSUCWCL=4065+4050

1026: TCH_call_reqSee figures 2, 3, 8, 9, 10, 11, 26,34, 51, 52, 54 and 55

1009 does not include DR while1026 include DRBetween Physical Context confirmand Channel activation

TASSALL

Ericsson compliant: 1-(TASSALL-HOASWCL+HOSUCWCL)/TASSALLObserve that if the feature assignment to worse cell is turned of this formula is meaningless since it will alwaysbe zero. It is at the moment not including assignment failures, only attempt failures due to congestion.

HO CAUSESObserve that Ericssons and Nokias Handover algorithms are totally different. This means that a faircomparison of handover causes in principle is impossible. Anyway, below are suggestion how to come asclose as possible.

HO Cause: Power Budget Nokia formula: cause_pbdgtNokia counter Stepped on message Ericsson compliant4032: Cause_pbdgtSee figures: 2, 3, 6 and 7.

Number of the attempts to powerbudget HO (outgoing).Updated on Measurement resultreceived in BSC.Counting TCH as well as SDCCHHandovers, both internal andexternal (Inter cell)

This is the most similar case to thenormal handover in the Ericssonsystem. Normal handover iscounted by HOTOKCL+HOTOLCL

Ericsson has handover causes that are based only on signal strength. These are the closest to thepowerbudget handovers. Formula: HOTOKCL+HOTOLCL

HO Cause: DistanceNokia formula: cause_distanceNokia counter Stepped on message Ericsson compliant4027: Cause_distanceSee figures: 1, 2, 3, 5, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by distance(outgoing).Triggered for a MS that has a longerdistance to the BTS than a certainvalue set by Nokia parameterxxx.Counting TCH as well as SDCCHHandovers, both internal andexternal (Inter cell and intra cell).

The closest counter is HOEXCTAwhich is stepped on HO commandfrom BSC to MS.TALIM has to be set similar to thecorresponding Nokia parameter.It is not stepped on intra-cellhandovers at high distance as 4027.

Closest to 4027 is HOEXCTA

HO Cause: InterferenceNokia formula: cause_intfer_dwn + cause_intfer_upNokia counter Stepped on message Ericsson compliant4030: Cause_intfer_dwnSee figures: 1, 2, 3, 5, 6 and 7.

Number of the HO attempts causedby high interference on downlink(outgoing). Updated onMeasurement result received inBSC.Triggered for interference=?The level of interference is set byparameter xxxxCounting TCH as well as SDCCHHandovers, both internal andexternal (Inter cell and intra cell).

In Ericsson there are handovers dueto bad quality. If the bad quality iscaused by interference, bad C/I orsomething else is not pointed out(since the Handover algorithm lookstotally different). There are countersfor Handover due to bad quality, seeHandover cause: Bad quality.

4029: Cause_intfer_upSee figures: 1, 2, 3, 5, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of HOattempts caused by high interferenceon uplink (outgoing).Triggered for interference=?The level of interference is set byparameter xxxxCounting TCH as well as SDCCHHandovers, both internal andexternal (Inter cell and intra cell).

See above.

There is no Ericsson formula for interference separately, but there is a formula that includes allhandovers at bad quality, i.e. reasons interference and bad quality. This formula isHODWNQA+HOUPLQA+HOINDQA+HOINUQA+HOINBQA and it corresponds to4030+4029+4025+4023.

HO Cause: LevelNokia formula: cause_down_lev + cause_up_levelNokia counter Stepped on message Ericsson compliant4026: Cause_down_levelSee figures: 2, 3, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by downlink level(outgoing).Triggered for a MS that is weakerthan a certain level that is set byparameter xxxxCounting TCH as well as SDCCHHandovers, both internal andexternal (Inter cell)

There is nothing in the EricssonHandover algorithm thatcorresponds to Nokias behaviourwith handovers if you are below acertain level. I.e. there is not anyEricsson counter for this.

4024: Cause_up_levelSee figures: 2, 3, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by uplink level(outgoing).Triggered for a MS that is weakerthan a certain level that is set byNokia parameter xxxxCounting TCH as well as SDCCHHandovers, both internal andexternal (Inter cell)

There is nothing in the EricssonHandover algorithm thatcorresponds to Nokias behaviourwith handovers if you are below acertain level. I.e. there is not anyEricsson counter for this.

These kinds of Handovers will never exist in Ericsson, since there are no predefined levels in which ahandover takes place. The mobiles which are weaker than this certain level will be sorted into causebetter K-or L-cell (Nokia cause powerbudget) or to cause bad quality or to cause excessive TA (Nokiacause distance).

HO Cause: QualityNokia formula: cause_down_qual + cause_up_qual

Nokia counter Stepped on message Ericsson compliant4025: Cause_down_qualSee figures: 1, 2, 3, 5, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by downlink quality(outgoing).Triggered for a MS that has worsequality than a certain qualitythreshold set by Nokia parameterxxxxCounting TCH as well as SDCCHHandovers, both internal andexternal (Inter cell and intra cell).

There are counters for handoversdue to bad quality.In Ericsson the stepping depends onthe setting of parameter QLIMDL inthe switch.The counter is HODWNQA which isstepped on HO command from BSCto MS. But intra cell Handovers arenot included in HODWNQAQLIMDL has to be set similar tothe corresponding Nokiaparameter.

4023: Cause_up_qualSee figures: 2, 3, 6 and 7.OBSERVE THE DIFFERENCE TO4025! NO INTRA-CELLHANDOVERS INCLUDED HERE!

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by uplink quality(outgoing).Triggered for a MS that has worsequality than a certain qualitythreshold set by parameter xxxxCounting TCH as well as SDCCHHandovers, both internal andexternal (Inter cell ).

There are counters for handoversdue to bad quality.In Ericsson the stepping depends onthe setting of parameter QLIMUL inthe switch.The counter is HOUPLQA, which isstepped on HO command from BSCto MS.QLIMUL has to be set similar tothe corresponding Nokiaparameter.

There is no Ericsson formula for interference separately, but there is a formula that includes allhandovers at bad quality, i.e. reason interference AND bad quality. This formula isHODWNQA+HOUPLQA+HOINDQA+HOINUQA+HOINBQA and it corresponds to4030+4029+4025+4023.

HO Cause: Other Nokia formula:cause_bad_ci + cause_field_drop + cause_good_ci + cause_low_distance + cause_msc_invoc + cause_ch_adm + cause_dir_retry + cause_pre_emption + cause_omc + cause_traffic + cause_umbr

Nokia counter Stepped on message Ericsson compliant4089: cause_bad_ciSee figures: 1, 2, 5 and 6.

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by a poor C/I ratioon the super-reuse frequency.

There is no feature like super reuseTRX in Ericsson.

4087: cause_field_dropSee figures: 2, 3, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by rapid field drop.

There is no Ericsson counter for this.

4090: cause_good_ciSee figures: 1, 2, 5 and 6.

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by a good C/I ratioon the super-reuse frequency.

There is no feature like super reuseTRX in Ericsson.

4088: cause_low_distanceSee figures: 1, 2, 3, 5, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of the HOattempts caused by low distance.

Low distance handovers arehandovers in the extended range cellfrom the extended range into thenormal cell area. In Ericsson thereare no handovers in such a situation.

4028: cause_msc_invocSee figures: 2, 3, 6 and 7.Remove 4035 in the HO causesother formula since 4028 isupdated always when 4035 isupdated.

Updated on Measurement resultreceived in BSC. Number of the HOattempts due to response to aninvocation from the MSC(outgoing).

This is similar to Cell Load sharinghandovers in an Ericsson system.HOATTLS is the closest, and it isupdated on Handover commandfrom BSC to MS. But HOATTLS iscovering also other Nokia countersfor example 4028

4034: cause_ch_admNo figures for this counter

Number of the HO attempts startedby channel administration(outgoing). This counter is notrelevant according to the NEDdocumentation.

No Ericsson compliant

4079: Cause_dir_retrySee figures: 9, 10 and 11.

HO attempts due to directed retry.Updated after queueing indication issent to the MSC. It is update in thesource cell.

Directed retry is similar to theEricsson feature Assignment toworse cell. HOASWCL is steppedon assignment request which isquite close.But the Nokia is only updated atcongestion. Ericsson updates also forassignment to worse because of badquality at call setup

4086: cause_pre_emptionSee figures: 1, 2, 3, 5, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of the HOattempts due to pre-emption.

HOATTPH, which is updated onHO command from BSC to MS

4033: cause_omcSee figures: 1, 2, 3, 5, 6 and 7.

Updated on Measurement resultreceived in BSC. Number of the HOattempts started by the O&M(outgoing).

HOATTBL, which is updated onHO command from BSC to MS

4035: Cause_trafficNo figures for this counter. Replacewith 4028?

No information when this counter isupdated. This counter is notrelevant according to the NEDdocumentation. Number of HOattempts started by a traffic reasonand controlled by the BSC(outgoing).

This is similar to Cell Load sharinghandovers in an Ericsson system.HOATTLS is the closest, and it isupdated on Handover commandfrom BSC to MS. But HOATTLS iscovering also other Nokia countersfor example 4028

4031: cause_umbrSee figures: 2, 3, 6, 7 and 56.

Updated on Measurement resultreceived in BSC. Number of theattempts to umbrella HO (outgoing).

There is no Ericsson counter for this.

One possible Ericsson formula for Handover cause other isHOASWCL+HOATTLS+HOATTPH+HOATTBL

Time congestion formulasNokia counter Stepped on message Ericsson compliantSDCCH congestion (s):2033: SDCCH_Cong_time

SDCCH congestion time. The timemeasurement is started when allSDCCHs are occuppied (last freeSDCCH is just seized) and stoppedwhen the first SDCCH is releasedand marked as free

CTCONGS. Incremented when thelast available channel is allocated.

TCH congestion (s):2026: TCH_CONG_TIME

Total TCH channel busy time. Thevalue gives information about totalTCH congestion time in ameasurement period. Thetimemeasurement is started when allTCH are occupied (last TCH is justseized) and stopped when the firstTCH is released and marked as free.The unit of value is 10 ms.

TFTCONGS. Incremented when thelast available channel is allocated.

TCH Holding TimeFormula in Nokia: ave_tch_hold_time/res_av_denom17=2036/(100*2037)Nokia counter Stepped on message Ericsson compliant2036: AVE_TCH_HOLD_TIMNo figures

The average full rate TCH meanholding time: The unit of value is 10ms.

Ericsson has no separate counter forTCH mean holding time. InsteadEricsson takes traffic/(no ofestablishments on TCH)

2037: RES_AV_DENOM17No figures

The denominator of the averageFTCH holding time (always>0)

No Ericsson compliant

Formula in Ericsson: TFTRALACC*Measurement time/(TFNSCAN*TFMSESTB)Measurement time is the time during which the statistics is studied. The unit is seconds so 1 hour gives 3600seconds. Without measurement time the TCH Holding time will be given in the unit of hours.

TCH Blocking percentageSee TCH access probability above.

SDCCH Blocking percentageSee SDCCH Access probability above.

TCH Drop causesNone of the drop causes mentioned in Nokia data warehouse is possible to measure in that way in an Ericssonsystem. The drop causes that exists are Drops due to Signal strength,drops due to bad quality and dropsdue to excessive timing advance. For all three there exists counters both on uplink and downlink.

Measurements of DL and UL Quality (Rxqual), Signal strength(Rxlev) and Timing AdvanceSTS has no counters for measuring Rxqual,Rxlev or TA values. But there is a function in OSS called MRR.This function is collecting the information from every measurement report that is sent up from the cell to theBSC. MRR is taking the average of the distribution during the measurement interval. One can select which cellsthat should be measured on and which information that should be stored (Rxqual and Rxlev DL/UL can bechosen as well as TA). A certain cell can not have more than one measurement ongoing simultaneously. Onesolution to gain interesting measurement results is to select the busiest hour(s) and run MRR daily on thesehours. The reports (measurements) can be scheduled in advance and the result is stored in the unix directory/var/tmos/logs/tap/eadir/fs/BSCKOZ1. The data is stored here 4 days and is then deleted. The files are binaryfiles that can then be parsed to Nokia data warehouse and postprocessed there.

Random Access measurementsEricsson has a number of counters for measuring random access performance. One of the most importantformula is Failed Random accesses of total number of Random access attemptsRAACCFA/(CNROCNT+RAACCFA)*100%. To be able to measure this the object type RANDOMACC has tobe active. In Appendix is a list of all object types in the BSC and if they are active or not. There can be seen thatRANDOMACC is already active.

Directed retry measurementsThe Nokia feature directed retry has an Ericsson compliant that is called Assignment to worse cell. Successfulassignment to worse cell (outgoing) is counted by HOSUCWCL. Number of attempts is counted byHOASWCL. Assignment to worse cell successrate can then be calculated as HOSUCWCL/HOASWCL*100 %.

Suggestion of other things that are of interest to measure:

SDCCH drop percentage Random access success rate Assignment success rate TCH drop reasons (drop reasons that are counted in Ericsson are low signal strength, bad quality,

excessive TA and other reasons)

Cell downtime (the percentage of time a cell has been out of service) CP load Traffic on SDCCH Location update performance (MSC) Paging performance (MSC)

Summary

Nokia formula Ericsson compliant (or closest possible)Dropped Calls (%) (included in TCH success) TFNDROP/TFNSCAN*100%Conversation started TFCASSALLTraffic TFTRALACC/TFNSCANNormalised BH TCH Utilisation TCHi=TNUCHCNT (the rest is taken from planning tables)SDCCH Access Probability 100 -CCONGS/CCALLS*100 %SDCCH Success Rate (TASSALL-HOASWCL)/

(CMSESTAB-CSMSUP-(TASSALL-TFCASSALL+HOASWCL))

TCH Access Probability 100- (CNRELCONG+TFNRELCONG)/(TASSALL-HOASWCL)

SDCCH Availability Percentage CAVAACC/(CAVASCAN*CNUCHCNT)*100 %TCH Availability Percentage TAVAACC/(TAVASCAN*TNUCHCNT)*100 %TCH Access failure rate 1-(TASSALL-HOASWCL+HOSUCWCL)/TASSALLTCH Holding time (TFTRALACC*Measurement time)

/(TFNSCAN*TFMSESTB)Handover failure rate 1-(HOVERSUC+HOINSUC)/

(HOVERCNT+HOINDQA+HOINUQA+HOINBQA)HO cause: Power budget HOTOKCL+HOTOLCLHO cause: Distance HOEXCTAHO causes: Interference and bad quality (not possibleto separate)

HODWNQA+HOUPLQA+HOINDQA+HOINUQA+HOINBQA

HO cause: other HOASWCL+HOATTLS+HOATTPH+HOATTBLSDCCH time congestion CTCONGSTCH time congestion TFTCONGSSuccessful Directed retries Percentage HOSUCWCL/HOASWCL*100 %

counters_ericsson_vs_nokia.pdf

Documents