NOKIA vs ERICSSON FORMULAS

Introduction
The aim of this document is to give a description of how to compare Nokia statistics to Ericsson statistics. Since
both 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 Ericsson
compliant formulas to this tool. Sometimes there is no possible comparison since the Nokia and Ericsson
systems work different. It should be observed that there exists no perfect compliant for any counters, there are
always differences, small or bigger.
Conversation started
Nokia formula: The raw counter 057015, Conver_Started
Nokia counter Stepped on message Ericsson compliant
57015: Conver_Started
See figures 17, 23, 27, 29 and
30.
When the BSC receives
Connect acknowledged from
the MSC, or Handover
Complete o the MSC after a
successful Handover.
TFCASSALL is almost
compliant. It is stepped on
Assignment complete to the
MSC.
Remark: Both Nokia 57015 and Ericsson TFCASSALL are updated on HO Complete o the MSC. This means
that all calls that come in to the BSC are counted as if a conversation was started.
M S
BTS BSC M SC
Assignment Complete
Rf Channel release
Rf Channel release ack.
Alert Alert
Connect Connect
Connect Acknowledge
Connect Acknowledge
1
2
1: Nokia 57015
2: Ericsson TFCASSALL
Traffic
Nokia formula: ave_busy_tch/res_av_denom14=2027/2028
Ericsson compliant: TFTRALACC/TFNSCAN
Both Ericsson and Nokia are taking average values over a certain timeperiod. The difference is that Ericsson
takes the samples each 10
th
second while Nokia takes them each 20
th
second. This is probably of minor impact
for the result.
Network call minutes
The 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 Ericsson
compliant 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 compliant
1001: Sdcch_busy_att
figures 5, 6 and 18.
Number of the times
when an MS attempts
to seize an SDCCH
unsuccessfully
because all SDCCHs
are busy.
UPDATED: When the RRM
has no SDCCHs to
allocate for a call
or HO attempts.
Updated after Channel
required, before
Channel activation
CCONGS
1000: Sdcch_seiz_att
figures 2, 5, 6, 18,
42, 46, 48 and 57.
Number of the times
when an MS attempts
to seize an SDCCH.
UPDATED: When the RRM
receives requests for
SDCCH from an MS as
the MS needs a
channel for either a
call or a HO.
Updated after Channel
required, before
Channel 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 collected
period durations in this case.
Nokia counter Stepped on message Ericsson compliant
3012: b.succ_seiz_term
See figure 2
Establish indication (with
paging response) on SDCCH
CMSESTAB is including 3012.
CMSESTAB is updated on
SCCP connection confirmed,
Handover complete and
Handover performed.
3013: b.succ_seiz_orig
See figure 2
Establish indication (CM
service request) on SDCCH
CMSESTAB is including 3013
3020: b.sdcch_call_re_est
See figure 2
Establish indication (call re-
establishment) on SDCCH
CMSESTAB is including 3020
3021: b.sdcch_emerg_call
See figure 2
Establish indication (emergency
call) on SDCCH
CMSESTAB is including 3021
3028: b.succ_sdcch_sms_est
See figures 10 and 11
Establish indication (MO SMS)
on SDCCH or establish_confirm
(MT SMS)
CMSESTAB is including 3028
3029: b.unsucc_sdcch_sms_est
See figures 12 and 13
Establish indication (MO SMS)
on SDCCH or establish_confirm
(MT SMS)
CMSESTAB is including 3029
4045: c.msc_i_sdcch
See figure 8
See fig 4,8,12,52,53
HO Complete BSC to MSC
CMSESTAB is including
incoming SDCCH Handovers.
Both 4045 and 4058 are
included.
4058: c.bsc_i_sdcch
See figure 6
HO Performed CMSESTAB is including
incoming SDCCH Handovers.
Both 4045 and 4058 are
included.
4051: c.msc_o_sdcch
See figure 7
Clear Command (MSC-BSC) in
source BSC.Cause code ?
CCHHOSUC is partly
compliant. It is updated on Clear
Command from the MSC, HO
performed to the MSC, and
Assignment Complete to the
MSC. But CMSESTAB is not
including outgoing Handovers
(on SDCCH) so no correction
has to be done for 4051 and
4066
4066: c.bsc_o_sdcch
See figure 6
Same as 4058 but different
direction
Same info as for 4051.
1026: a.tch_call_req
See figures 2, 3, 8, 9, 10, 11, 26,
34, 51, 52, 54 and 55.
Number of the TCH requests for
a normal assignment (both
successful and
unsuccessful).After Physical
Context confirm, before
Channel activation.
TASSALL (Both 1026 and
TASSALL includes outgoing
Directed retries)
1009: Tch_norm_seiz
Figures 2,3,9,51,54
Number of the successful
requests for a TCH in a normal
assignment.
Updated when the RRM
allocates a TCH as a response to
a TCH request in a call attempt.
Updated between Physical
Context confirm and Channel
activation
TASSALL-HOASWCL
1026-1009 Both are updated After Physical
Context confirm, before
Channel activation.
1026 and 1009 are updated in
the some moment of the call
setup. 1026 is updated on
assignment failures, which 1009
is not. When taking the
difference 1026-1009 you
basically get outgoing directed
retries+assignment failures, so
1026-1009=TASSALL-
TFCASSALL+HOASWCL
In the Nokia formula SMS messages are excluded which is not possible in CMSESTAB. CMSESTAB is
including 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 called
successful 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 of
1009 is concluded to be TASSALL-HOASWCL.
The denominator: Since the formula is based on that a TCH assignment attempt is made, SDCCH allocations
that never end up in a TCH assignment attempt has to be removed. Nokia is compensating this by removing
SMS (successful and unsuccessful). Ericsson has the similar CSMSUP. Neither Nokia nor Ericsson is
compensating for Location updates, which should be done. There are probably counters for that in the
Nokia 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 TCH
assignment 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 esponse
U a
1
1: 3012,3013,3020,3021,3028 (stepped also on another m essage) and 3029
2: 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 equest
Paging R equest
Paging Paging 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 compliant
1026-1009 Number of the TCH requests for
a normal assignment (both
successful and unsuccessful).
Both are updated After Physical
Context confirm, before
Channel activation.
1026 and 1009 are updated in
the some moment of the call
setup. 1026 is updated on
assignment failures which 1009
is not. When taking the
difference 1026-1009 you
basically get outgoing directed
retries+assignment failures, so
1026-1009=TASSALL-
TFCASSALL+HOASWCL
1026: a.tch_call_req
See figures 2, 3, 8, 9, 10, 11, 26,
34, 51, 52, 54 and 55.
After Physical Context confirm,
before Channel activation.
TASSALL (Both TASSALL
and 1026 includes directed
retries)
4050: msc_o_sdcch_tch
See figure 11
When a directed retry procedure
is completed
External directed retry in source
BSC (Clear command from
MSC)
Directed retry is included above
In the counter TFCASSALL
that gives we should take away
HOSUCWCL which is
replacing 4050+4065+4074.
This is already done in the
formula for 1026-1009
4065: bsc_o_sdcch_tch
See figures 10 and 55
When a directed retry procedure
is completed.
Updated on assignment
complete.
- When the direct access from
the SDCCH to TCH on a super-
reuse TRX is completed.
- When the intelligent directed
retry is completed.
- When the TCH assignment to
a super-reuse TRX is
completed.
See above
4074: cell_sdcch_tch
See figures 9 and 54
Updated on assignment to IUO
which is not used in Ericsson
BTSs in this network
- When a channel assignment to
a super-reuse TRX in an IUO
DR is completed.
- When the direct access to a
super-reuse TRX is completed.
Underlaid/overlaid HO counters
for directed retry, but the feature
is not in use in the Ericsson
BSC
1122:
tch_rej_due_req_ch_a_if_crc
See figure 11 (This counter is
related to halfrate)
Number of the requests for TCH
rejected due to mismatch
between the types of the
requested channel and the A
interface circuit, whether
queuing occurred or not.
Updated on the same message
as 1026,but with different cause.
TASSALL is already covering
this Nokia counter.
4097:
bsc_i_unsucc_a_int_circ_type
figures 33 and 36
UPDATED: When an internal
incoming inter-cell HO attempt
is interrupted because the BSC
wants to change the A interface
circuit pool before TCH
allocation.
Incremented after Meas result,
before HO required
HO required counter for intra
cell HO failures. No Ericsson
compliant. If an A-interface
failure occurs other counters in
source cell will be updated
instead. But these counters are
also updated for other things
which make it impossible to
compare
4101: msc_controlled_in_ho
figure 34
UPDATED: When the HO
attempt ends due to an attempt
of TCH allocation which is
unsuccessful because of the
mismatch between the requested
TCH channel type and the A
interface circuit type. The cause
switch_circuit_pool is sent in
the HANDOVER_FAILURE
message to the A interface.
HO required counter for intra
cell HO failures. No Ericsson
compliant. If an A-interface
failure occurs other counters in
source cell will be updated
instead. But these counters are
also updated for other things
which make it impossible to
compare
4098:
ho_unsucc_a_int_circ_type
Figures 32 and 35
UPDATED: When an internal
intra-cell HO attempt is
interrupted because the BSC
wants to change the A interface
circuit pool before TCH
allocation.
After Physical context confirm,
before HO required
HO required counter for intra
cell HO failures. No Ericsson
compliant. If an A-interface
failure occurs other counters in
source cell will be updated
instead. But these counters are
also updated for other things
which make it impossible to
compare
There is no Ericsson formula that can be directly converted counter by counter from the Nokia formula
for TCH Call blocking. Nokia is counting unsuccessful TCH seizures which in Ericsson is counted as
something totally other than TCH congestion. The reason is that the Nokia counters are stepped at
assignment 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 an
immediate assignment on TCH. Immediate assignment on TCH is an Ericsson feature that allows you to set up a
call without using the SDCCH.
TASSALL-HOASWCL gives the number of assignment attempts that have been done in the cell when
assignment to worse cell (Nokia: directed retry) is not included.
TCH Success (4
th
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 compliant
1013:a.tch_radio_fail
See figure 64
Radio link timeout, release
indication from MS
Updated on assignment failure to
MSC (just before Clear command
from MSC)
TFNDROP
1014:a.tch_rf_old_ho
See figure 31
HO failure during HO attempt
Updated on Rf channel release
acknowledge
TFNDROP
1084: a.tch_abis_fail_call
See figures 13, 14 and 17
Abis interface failure on the old
channel during TCH Handover
Updated on Assignment failure
TFNDROP
1085:a.tch_abis_fail_old
No figures
Abis interface failure on the old
channel during TCH handover
Not possible to find where it is
updated
?
1087:a.tch_a_if_fail_call
See figure 15
A interface failure, for example:
Clear command from MSC during
call setup phase before assignment
complete from MS, and abnormal
clear received due to air interface
(reset ciruit, SCCP clear by RLSD)
Updated on Rf channel release
acknowledge (which in this case
comes after the clear command)
TFNDROP
1088:a.tch_a_if_fail_old
See figure 39
A interface failure (handover
failure) on the old channel during
TCH handover attempt)
Updated on Rf channel release
acknowledge
TFNDROP
1029:a.tch_tr_fail
See figure 16
Transcoder failure during call
attempt
Updated on Rf channel release
acknowledge
TFNDROP
1030:a.tch_tr_fail_old
No figures
Not possible to find where it is
updated
?
1046:a.tch_lapd_fail
See figure 17
Transcoder failure on the old
channel during a handover attempt,
that is before handover/assignment
complete received from the MS
Blocked TRXes does not cause drop
calls. Traffic is rerouted to another
TRX instead
1047:a.tch_bts_fail
See figure 17
TRX block caused by LAPD
failure. Blocked TRX due to
signalling link fault or PCM fault
Blocked TRXes does not cause drop
calls. Traffic is rerouted to another
TRX instead
1048:a.tch_user_act
See figure 17
TRX block caused by BTS failure.
Blocked TRX due to FU fault, CU
fault, BTS reset, BCF reset, both
CU and FU fault, BCF fault.
Blocked TRXes does not cause drop
calls. Traffic is rerouted to another
TRX instead
1049:a.tch_bcsu_reset
No figures
TRX block caused by BCSU restart Blocked TRXes does not cause drop
calls. Traffic is rerouted to another
TRX instead
1050:a.tch_netw_act
See figure 17
TRX block caused by failure which
lead to TRX reconfiguration.
Blocked TRX in substate: blocked
by system
Blocked TRXes does not cause drop
calls. Traffic is rerouted to another
TRX instead
1081:a.tch_act_fail_call
See figure 12
Failure of channel activation
(channel activation nack received)
in the BTS
Updated on Rf channel release
acknowledge
TFNDROP
1009:a.tch_norm_seiz
See figures 2, 3, 9, 51 and 54
Number of the successful requests
for a TCH in a normal assignment.
Updated when the RRM allocates a
TCH as a response to a TCH
request in a call attempt. Updated
between Physical Context confirm
and Channel activation
TFCASSALL-HOASWCL
3020: sdcch_call_re_est
Figure 2
UPDATED: When an
ESTABLISH_INDICATION
message for a call re-establishment
is received on SDCCH from the
BTS. (Before paging response)
No Ericsson counter for that.
Call re-establishment is a Nokia
feature that has no Ericsson
compliant. At the moment this
feature is not turned on, though.
3025: tch_call_re_est
figure 3
Number of the successful seizures
of TCHs for call re-establishment
in FACCH call setup due to
SDCCH congestion. If FACCH
call setup is turned off, the counter
value is zero.
UPDATED: When an
ESTABLISH_INDICATION
message for a call re-establishment
is received on TCH from the BTS.
No Ericsson counter for that.
Call re-establishment is a Nokia
feature that has no Ericsson
compliant. At the moment this
feature 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 one
defined in Nokia Data warehouse.
SDCCH Availability Percentage
Nokia 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 compliant
2004: ave_sdcch_sub
No figures available
Average number of the
SDCCHs available. This figure
is received by dividing the value
of this counter by the value of
the next counter.
UPDATED:
-When a TRX is deblocked
-When a TRX is blocked
-When an SDCCH TSL is
deblocked
-When an SDCCH TSL is
blocked
The counter is sampled every 20
seconds.
CAVAACC/CAVASCAN
(Average number of available
SDCCHs)
2038: ave_non_avail_sdcch
No figures available
Average number of the
SDCCHs not available. This
figure is received by dividing
the value of this counter by the
value of the next counter.
UPDATED:
- When a TRX is deblocked
- When a TRX is blocked
- When an SDCCH TSL is
deblocked
- When an SDCCH TSL is
blocked
The counter is sampled every 20
seconds.
CNUCHCNT-
CAVAACC/CAVASCAN
Ericsson formula=CAVAACC/(CAVASCAN*CNUCHCNT)*100 %
The difference between Ericsson and Nokia counters is that Ericsson takes the samples each 10
th
second while
Nokia takes them each 20
th
second. This is probably of minor impact for the result. Both Ericsson and Nokia is
showing average numbers of available channels over a certain time period.
TCH Availability Percentage
Nokia 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 compliant
2002: ave_avail_full_tch
No figures available
Average number of the FR radio
TCHs available. This figure is
received by dividing the value
of this counter by the value of
the next counter.
UPDATED:
- When a TRX is deblocked
- When a TRX is blocked
- When a TCH TSL is
deblocked
- When a TCH TSL is blocked
The counter is sampled every 20
seconds.
TAVAACC/TAVASCAN
(Average number of available
TCHs)
2040: ave_non_avail_tch
No figures available
Average number of the TCHs
not available. This figure is
received by dividing the value
of this counter by the value of
the next counter.
UPDATED:
- When a TRX is deblocked
- When a TRX is blocked
- When a TCH TSL is
deblocked
- When a TCH TSL is blocked
The counter is sampled every 20
seconds.
TNUCHCNT-
TAVAACC/TAVASCAN
Ericsson formula=TAVAACC/(TAVASCAN*TNUCHCNT)*100 %
The difference between Ericsson and Nokia counters is that Ericsson takes the samples each 10
th
second while
Nokia takes them each 20
th
second. This is probably of minor impact for the result. Both Ericsson and Nokia is
showing average numbers of available channels over a certain time period.
Total Handover Failure Ratio
Nokia 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 than
15 per cent may occur.
If Directed Retry is enabled, the MS may, when congestion of the source cell SDCCH occurs, be
moved from the best cell to a worse one. Then the MS tries to make a handover back but fails if the
first 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 compliant
4004: msc_o_succ_ho
figures: 3, 7, 11, 35, 36 and 51
Clear command from MSC to
source BSC
Number of the successful outgoing
HOs controlled by the MSC.
UPDATED: When the HO
(SDCCH to SDCCH, SDCCH to
TCH or TCH to TCH) is
completed.
Ericsson can only count outgoing
Handovers from a BSC. This means the
Handover can also be to another MSC.
HOVERSUC is including handovers to
external cells (i.e. other BSCs and
MSCs)
HOVERSUC is stepped on Clear
command to the MSC, Handover
Performed, and assignment complete (to
the MSC)
4014: bsc_o_succ_ho
Figure 6
Number of the successful outgoing
HOs controlled by the BSC.
UPDATED: When the HO
(SDCCH to SDCCH, SDCCH to
TCH or TCH to TCH) is
completed.
Handover performed BSC to MSC
HOVERSUC is covering handovers
betweeen internal cells.
4018: cell_succ_ho
See figures: 1, 5, 9, 47, 48 and 54
Number of the successful intra-cell
HOs.
UPDATED: When the HO
(SDCCH to SDCCH, TCH to TCH
or SDCCH to TCH) is completed.
Handover performed BSC to MSC
HOINSUC
Stepped on message Handover
performed to MSC.
4052: msc_o_tch_tch_at
figures 3,35,36
Between Measurement result and
Handover required.
HOVERCNT=4052+4067
Stepped on Handover command to the
MS
4053: msc_o_sdcch_tch_at
Figure 11
Between Queing indication and
Handover required.
HOASWCL to external cell. In Ericsson
some parameters in the (Ericsson) MSC
has to be set to allow assignment
handovers to external cells. What about
the Nokia MSC?
HOASWCL=4053+4068
Stepped on assignment request
HOVERCNT is including 4053
4054: msc_o_sdcch_at
figure 7
Between Measurement result and
Handover required.
CCHHOCNT: SDCCH handover
attempts, both to internal and external
cells. . I.e. 4054+4069=CCHHOCNT
Stepped on Handover command to the
MS. HOVERCNT is including SDCCH
handovers.
4067: bsc_o_tch_tch_at
Figures 2 and 56
Between Measurement result and
channel activation
HOVERCNT=4052+4067
4068: bsc_o_sdcch_tch_at
Figures 10 and 55
Between Measurement result and
channel activation
HOASWCL to internal cells.
HOASWCL=4053+4068
Stepped on assignment request
HOVERCNT is including 4068
4069: bsc_o_sdcch_at
Figure 6
Between queing indication and
channel activation
CCHHOCNT: SDCCH handover
attempts, both to internal and external
cells. I.e. 4054+4069=CCHHOCNT
Stepped on Handover command to the
MS. HOVERCNT is including SDCCH
handovers
4076: cell_tch_tch_at
Figure 1
TCH to TCH intra cell Handover
Updated between Measurement
result and Physical context
request
HOINDQA+HOINUQA+HOINBQA
They are stepped when an allocation
attempt is received (Channel activation
acknowledge)
4077: cell_sdcch_tch_at
Figures 9 and 54
Directed retry at intra cell
handover.
Stepped after Queing indication
and before Physical context request
OR between Assignment request
and Physical context request
Directed retry at intra cell handover to
Underlaid\Overlaid does not exist in
Ericssons system
4078: cell_sdcch_at
Fig.5
Intra cell Handover on SDCCH.
Between Measurement result and
Physical context request.
Intra cell Handovers are possible to
obtain on SDCCH by setting parameter
IHOSICH to ON.
HOINDQA+HOINUQA+HOINBQA
Ericsson formula: (HOVERSUC+HOINSUC)/(HOVERCNT+HOINDQA+HOINUQA+HOINBQA)
Uplink interference measurements
Ericsson has the same structure of uplink measurements as Nokia has. The interference is divided into five
bands. The range for each band is set by parameters called LIMIT1,LIMIT2, LIMIT3 and LIMIT4. To be able
to compare Nokia and Ericsson uplink interference, these parameters has to be set to the same as the
corresponding Nokia values. There is also a parameter called INTAVE that defines the time period that the UL
interference 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 are
ITFUSIB1,ITFUSIB2,ITFUSIB3,ITFUSIB4 and ITFUSIB5. To retrieve the percentage of Uplink interference
in 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 of
samples that are in interference band 4 and 5.
TCH Access Failure rate
Percentage of failed attempts for timeslot seizure. The seizure did not occur neither at the initial cell nor at an
adjacent 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 compliant
1009: TCH_norm_seiz
figures 2, 3, 9, 51 and 54
1009 does not include DR while
1026 include DR
TASSALL-HOASWCL
4065: BSC_O_SDCCH_TCH
See figures 10 and 55
Updated on Assignment complete HOSUCWCL=4065+4050
4050: MSC_O_SDCCH_TCH
See figure 11
Updated on Clear command from
MSC to BSC
HOSUCWCL=4065+4050
1026: TCH_call_req
See figures 2, 3, 8, 9, 10, 11, 26,
34, 51, 52, 54 and 55
1009 does not include DR while
1026 include DR
Between Physical Context confirm
and Channel activation
TASSALL
Ericsson compliant: 1-(TASSALL-HOASWCL+HOSUCWCL)/TASSALL
Observe that if the feature assignment to worse cell is turned of this formula is meaningless since it will always
be zero. It is at the moment not including assignment failures, only attempt failures due to congestion.
HO CAUSES
Observe that Ericssons and Nokias Handover algorithms are totally different. This means that a fair
comparison of handover causes in principle is impossible. Anyway, below are suggestion how to come as
close as possible.
HO Cause: Power Budget
Nokia formula: cause_pbdgt
Nokia counter Stepped on message Ericsson compliant
4032: Cause_pbdgt
See figures: 2, 3, 6 and 7.
Number of the attempts to power
budget HO (outgoing).
Updated on Measurement result
received in BSC.
Counting TCH as well as SDCCH
Handovers, both internal and
external (Inter cell)
This is the most similar case to the
normal handover in the Ericsson
system. Normal handover is
counted by HOTOKCL+HOTOLCL
Ericsson has handover causes that are based only on signal strength. These are the closest to the
powerbudget handovers. Formula: HOTOKCL+HOTOLCL
HO Cause: Distance
Nokia formula: cause_distance
Nokia counter Stepped on message Ericsson compliant
4027: Cause_distance
See figures: 1, 2, 3, 5, 6 and 7.
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by distance
(outgoing).
Triggered for a MS that has a longer
distance to the BTS than a certain
value set by Nokia parameterxxx.
Counting TCH as well as SDCCH
Handovers, both internal and
external (Inter cell and intra cell).
The closest counter is HOEXCTA
which is stepped on HO command
from BSC to MS.
TALIM has to be set similar to the
corresponding Nokia parameter.
It is not stepped on intra-cell
handovers at high distance as 4027.
Closest to 4027 is HOEXCTA
HO Cause: Interference
Nokia formula: cause_intfer_dwn + cause_intfer_up
Nokia counter Stepped on message Ericsson compliant
4030: Cause_intfer_dwn
See figures: 1, 2, 3, 5, 6 and 7.
Number of the HO attempts caused
by high interference on downlink
(outgoing). Updated on
Measurement result received in
BSC.
Triggered for interference=?
The level of interference is set by
parameter xxxx
Counting TCH as well as SDCCH
Handovers, both internal and
external (Inter cell and intra cell).
In Ericsson there are handovers due
to bad quality. If the bad quality is
caused by interference, bad C/I or
something else is not pointed out
(since the Handover algorithm looks
totally different). There are counters
for Handover due to bad quality, see
Handover cause: Bad quality.
4029: Cause_intfer_up
See figures: 1, 2, 3, 5, 6 and 7.
Updated on Measurement result
received in BSC. Number of HO
attempts caused by high interference
on uplink (outgoing).
Triggered for interference=?
The level of interference is set by
parameter xxxx
Counting TCH as well as SDCCH
Handovers, both internal and
external (Inter cell and intra cell).
See above.
There is no Ericsson formula for interference separately, but there is a formula that includes all
handovers at bad quality, i.e. reasons interference and bad quality. This formula is
HODWNQA+HOUPLQA+HOINDQA+HOINUQA+HOINBQA and it corresponds to
4030+4029+4025+4023.
HO Cause: Level
Nokia formula: cause_down_lev + cause_up_level
Nokia counter Stepped on message Ericsson compliant
4026: Cause_down_level
See figures: 2, 3, 6 and 7.
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by downlink level
(outgoing).
Triggered for a MS that is weaker
than a certain level that is set by
parameter xxxx
Counting TCH as well as SDCCH
Handovers, both internal and
external (Inter cell)
There is nothing in the Ericsson
Handover algorithm that
corresponds to Nokias behaviour
with handovers if you are below a
certain level. I.e. there is not any
Ericsson counter for this.
4024: Cause_up_level
See figures: 2, 3, 6 and 7.
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by uplink level
(outgoing).
Triggered for a MS that is weaker
than a certain level that is set by
Nokia parameter xxxx
Counting TCH as well as SDCCH
Handovers, both internal and
external (Inter cell)
There is nothing in the Ericsson
Handover algorithm that
corresponds to Nokias behaviour
with handovers if you are below a
certain level. I.e. there is not any
Ericsson counter for this.
These kinds of Handovers will never exist in Ericsson, since there are no predefined levels in which a
handover takes place. The mobiles which are weaker than this certain level will be sorted into cause
better K-or L-cell (Nokia cause powerbudget) or to cause bad quality or to cause excessive TA (Nokia
cause distance).
HO Cause: Quality
Nokia formula: cause_down_qual + cause_up_qual
Nokia counter Stepped on message Ericsson compliant
4025: Cause_down_qual
See figures: 1, 2, 3, 5, 6 and 7.
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by downlink quality
(outgoing).
Triggered for a MS that has worse
quality than a certain quality
threshold set by Nokia parameter
xxxx
Counting TCH as well as SDCCH
Handovers, both internal and
external (Inter cell and intra cell).
There are counters for handovers
due to bad quality.
In Ericsson the stepping depends on
the setting of parameter QLIMDL in
the switch.
The counter is HODWNQA which is
stepped on HO command from BSC
to MS. But intra cell Handovers are
not included in HODWNQA
QLIMDL has to be set similar to
the corresponding Nokia
parameter.
4023: Cause_up_qual
See figures: 2, 3, 6 and 7.
OBSERVE THE DIFFERENCE TO
4025! NO INTRA-CELL
HANDOVERS INCLUDED HERE!
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by uplink quality
(outgoing).
Triggered for a MS that has worse
quality than a certain quality
threshold set by parameter xxxx
Counting TCH as well as SDCCH
Handovers, both internal and
external (Inter cell ).
There are counters for handovers
due to bad quality.
In Ericsson the stepping depends on
the setting of parameter QLIMUL in
the switch.
The counter is HOUPLQA, which is
stepped on HO command from BSC
to MS.
QLIMUL has to be set similar to
the corresponding Nokia
parameter.
There is no Ericsson formula for interference separately, but there is a formula that includes all
handovers at bad quality, i.e. reason interference AND bad quality. This formula is
HODWNQA+HOUPLQA+HOINDQA+HOINUQA+HOINBQA and it corresponds to
4030+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 compliant
4089: cause_bad_ci
See figures: 1, 2, 5 and 6.
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by a poor C/I ratio
on the super-reuse frequency.
There is no feature like super reuse
TRX in Ericsson.
4087: cause_field_drop
See figures: 2, 3, 6 and 7.
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by rapid field drop.
There is no Ericsson counter for this.
4090: cause_good_ci
See figures: 1, 2, 5 and 6.
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by a good C/I ratio
on the super-reuse frequency.
There is no feature like super reuse
TRX in Ericsson.
4088: cause_low_distance
See figures: 1, 2, 3, 5, 6 and 7.
Updated on Measurement result
received in BSC. Number of the HO
attempts caused by low distance.
Low distance handovers are
handovers in the extended range cell
from the extended range into the
normal cell area. In Ericsson there
are no handovers in such a situation.
4028: cause_msc_invoc
See figures: 2, 3, 6 and 7.
Remove 4035 in the HO causes
other formula since 4028 is
updated always when 4035 is
updated.
Updated on Measurement result
received in BSC. Number of the HO
attempts due to response to an
invocation from the MSC
(outgoing).
This is similar to Cell Load sharing
handovers in an Ericsson system.
HOATTLS is the closest, and it is
updated on Handover command
from BSC to MS. But HOATTLS is
covering also other Nokia counters
for example 4028
4034: cause_ch_adm
No figures for this counter
Number of the HO attempts started
by channel administration
(outgoing). This counter is not
relevant according to the NED
documentation.
No Ericsson compliant
4079: Cause_dir_retry
See figures: 9, 10 and 11.
HO attempts due to directed retry.
Updated after queueing indication is
sent to the MSC. It is update in the
source cell.
Directed retry is similar to the
Ericsson feature Assignment to
worse cell. HOASWCL is stepped
on assignment request which is
quite close.
But the Nokia is only updated at
congestion. Ericsson updates also for
assignment to worse because of bad
quality at call setup
4086: cause_pre_emption
See figures: 1, 2, 3, 5, 6 and 7.
Updated on Measurement result
received in BSC. Number of the HO
attempts due to pre-emption.
HOATTPH, which is updated on
HO command from BSC to MS
4033: cause_omc
See figures: 1, 2, 3, 5, 6 and 7.
Updated on Measurement result
received in BSC. Number of the HO
attempts started by the O&M
(outgoing).
HOATTBL, which is updated on
HO command from BSC to MS
4035: Cause_traffic
No figures for this counter. Replace
with 4028?
No information when this counter is
updated. This counter is not
relevant according to the NED
documentation. Number of HO
attempts started by a traffic reason
and controlled by the BSC
(outgoing).
This is similar to Cell Load sharing
handovers in an Ericsson system.
HOATTLS is the closest, and it is
updated on Handover command
from BSC to MS. But HOATTLS is
covering also other Nokia counters
for example 4028
4031: cause_umbr
See figures: 2, 3, 6, 7 and 56.
Updated on Measurement result
received in BSC. Number of the
attempts to umbrella HO (outgoing).
There is no Ericsson counter for this.
One possible Ericsson formula for Handover cause other is
HOASWCL+HOATTLS+HOATTPH+HOATTBL
Time congestion formulas
Nokia counter Stepped on message Ericsson compliant
SDCCH congestion (s):
2033: SDCCH_Cong_time
SDCCH congestion time. The time
measurement is started when all
SDCCHs are occuppied (last free
SDCCH is just seized) and stopped
when the first SDCCH is released
and marked as free
CTCONGS. Incremented when the
last available channel is allocated.
TCH congestion (s):
2026: TCH_CONG_TIME
Total TCH channel busy time. The
value gives information about total
TCH congestion time in a
measurement period. The
timemeasurement is started when all
TCH are occupied (last TCH is just
seized) and stopped when the first
TCH is released and marked as free.
The unit of value is 10 ms.
TFTCONGS. Incremented when the
last available channel is allocated.
TCH Holding Time
Formula in Nokia: ave_tch_hold_time/res_av_denom17=2036/(100*2037)
Nokia counter Stepped on message Ericsson compliant
2036: AVE_TCH_HOLD_TIM
No figures
The average full rate TCH mean
holding time: The unit of value is 10
ms.
Ericsson has no separate counter for
TCH mean holding time. Instead
Ericsson takes traffic/(no of
establishments on TCH)
2037: RES_AV_DENOM17
No figures
The denominator of the average
FTCH 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 3600
seconds. Without measurement time the TCH Holding time will be given in the unit of hours.
TCH Blocking percentage
See TCH access probability above.
SDCCH Blocking percentage
See SDCCH Access probability above.
TCH Drop causes
None of the drop causes mentioned in Nokia data warehouse is possible to measure in that way in an Ericsson
system. The drop causes that exists are Drops due to Signal strength,drops due to bad quality and drops
due 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 Advance
STS 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 the
BSC. MRR is taking the average of the distribution during the measurement interval. One can select which cells
that should be measured on and which information that should be stored (Rxqual and Rxlev DL/UL can be
chosen as well as TA). A certain cell can not have more than one measurement ongoing simultaneously. One
solution to gain interesting measurement results is to select the busiest hour(s) and run MRR daily on these
hours. 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 binary
files that can then be parsed to Nokia data warehouse and postprocessed there.
Random Access measurements
Ericsson has a number of counters for measuring random access performance. One of the most important
formula is Failed Random accesses of total number of Random access attempts
RAACCFA/(CNROCNT+RAACCFA)*100%. To be able to measure this the object type RANDOMACC has to
be active. In Appendix is a list of all object types in the BSC and if they are active or not. There can be seen that
RANDOMACC is already active.
Directed retry measurements
The Nokia feature directed retry has an Ericsson compliant that is called Assignment to worse cell. Successful
assignment to worse cell (outgoing) is counted by HOSUCWCL. Number of attempts is counted by
HOASWCL. 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 TFCASSALL
Traffic TFTRALACC/TFNSCAN
Normalised 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)/TASSALL
TCH Holding time (TFTRALACC*Measurement time)
/(TFNSCAN*TFMSESTB)
Handover failure rate 1-(HOVERSUC+HOINSUC)/
(HOVERCNT+HOINDQA+HOINUQA+HOINBQA)
HO cause: Power budget HOTOKCL+HOTOLCL
HO cause: Distance HOEXCTA
HO causes: Interference and bad quality (not possible
to separate)
HODWNQA+HOUPLQA+HOINDQA+HOINUQA+
HOINBQA
HO cause: other HOASWCL+HOATTLS+HOATTPH+HOATTBL
SDCCH time congestion CTCONGS
TCH time congestion TFTCONGS
Successful Directed retries Percentage HOSUCWCL/HOASWCL*100 %