Network Optimization & Tuning: BR 9.0 Feature impacts analysis FRS 92893 “Repeated FACH (R-FACCH)”
Version 1.0 Document status: IUS
Au Autho thor: Krys rystia tian Majch jchrow rowicz icz SN SDC NA B1
Date:
21.03.2007
Tel.: l.: +48 71 777-74 -74441 E-mail E-mail:: krystian.majchrowicz@ krystian.majchrowicz@siemens.com siemens.com
This page is intentionally left blank
Table of contents TABLE OF CONTENTS.............................................................................................3 1
HISTORY .....................................................................................................6
2
LITERATURE REFERENCES .....................................................................7
3
INTRODUCTION.......................................................................................... 8
3.1
Repeated FACCH (R-FACCH) ........................................................................................................ 9
3.2
Prerequisites for applicability of R-FACCH ................................................................. .................. 9
3.3
When the R-FACCH applies to an on-going call .......................................................................... 10
4
NETWORK INTRODUCTION AND PARAMETERIZATION ASPECTS .... 11
5
CONTEXT OF APPLICATION AND EXPECTED BENEFIT ...................... 13
5.1
Application context ................................................................. ......................................................... 13
5.2
Expected influence of R-FACCH on the network performance .................................................. 13
5.3
Possible side effect of the introduction of R-FACCH ................................................................... 17
5.4
Cell context proposals for analysis of R-FACCH effects.............................................................. 17
6
RESULTS OF SIMULATIONS OR COLLECTED FROM FIELD ............... 18
7 VERIFICATION OF THE NETWORK IMPROVEMENT AFTER FEATURE INTRODUCTION ......................................................................................................19 8
EVALUATION OF THE FEATURE IMPACT WITH SAG TOOLS ............. 20
8.1
Feature impact on AnatomN........................................................................................................... 20
8.2
Feature impact on Radio Network Analyser (RNA)..................................................................... 20
8.3
Feature impact on Siemens PM Counters...................................................................................... 21
INDEX OF FIGURES
ABBREVIATIONS ACCH
Associated Control Channel
AFS
AMR Fullrate Speech
AHS
AMR Halfrate Speech
AMR
Adaptive Multi Rate
ASS CMD
Assignment Command
ASS CMP
Assignment Complete
BTS
Base Transceiver Station
CDR
Call Drop Rate
CGI
Cell Global Identifier
CONACK
Connection Acknowledgement
DL
Downlink
DM
Disconnect Mode
EFL
Effective Fractional Load
EFR
Enhanced Full Rate
FACCH
Fast Associated Control Channel
FR
Full Rate
GMSK
Gaussian Modulation Shift Keying
HO
Handover
HOAF
Handover Access Failure
HO CMD
Handover Command
HO CMP
Handover Complete
HSCSD
High Speed Circuit Switch Data
HR
Half Rate
I
Information frame
LAPDm
Link Access Protocol on Dm channel
MS
Mobile Station
NOT
Network Optimization and Tuning
PHYS INFO
Physical Information
RLF
Radio Link Failure
RR
Received Ready
SABM
Set Asynchronous Balance Mode
SACCH
Slow Associated Control Channel
TA
Timing Advance
UA
Unnumbered Acknowledged
UI
Unnumbered Information
UL
Uplink
1
History
Version
Date
Chapter
Changes / Reasons
0.1
18.12.2006
DRAFT_AFI
0.2
11.01.2007
Correction after first review phase
1.0
21.03.2007
Set to IUS
2
Literature references 1. [AEK92893] FRS “Repeated FACCH and Temporary Overpower on FACCH and SACCH for Reduced Call Drop Rate”, Dr. Kolio Ivanov, 07.08.2006, 2. BR 9.0 Initial Enabling (Siemens internal) ”Temporary Overpower & Repeated FACCH”, Eckardt Bertermann, 13.11.2006 3. Database Parameter Description 4. PM: SBS counter 5. [CR2745] “Maximum Capacity Booster”
3
Introduction
Originally in GSM the robustness of the signalling ACCH has been designed to match with the error protection schemes of the standard GSM FR and HR speech TCH (TCH/FS, TCH/HS). The robustness of the GSM TCH has been substantially increased by the introduction of Adaptive Multi Rate (AMR) speech codecs capable of adapting the relative amount of speech and coding to the prevailing radio conditions. The most robust AMR codec modes, e.g. TCH/AFS4.75 and TCH/AFS5.90 provide sufficient voice quality even at very low C/I levels down to 2 dB. The robustness of ACCH, however, has not been improved, yet.
Figure 1 FER vs. C/I for different coding mode for TU3 scenario (source: 3GPP TSG GERAN #19)
The analysis of the call drop statistics in real networks planned in tight reuse and operated at medium fractional load also shows that the vulnerability of ACCH especially downlink is currently the limiting factor for the network capacity. In uplink direction Interference Cancellation (UIC) has been introduced in BR8.0, capable of improving also the performance for signalling channels, i.e. no critical degradation of ACCH performance is expected in UL. Analysis of trace data and performance counters have shown that most of the call drops occur during the HO procedure. This is a strong indication that especially the HO messages sent via FACCH are causing the strong increase in call drop rate. Therefore in BR 9.0 two approaches to address the issue with ACCH on downlink has been implemented:
1. By improving the error protection schemes for FACCH implying changes in the 3GPP standard. 2. By improving the C/I on DL ACCH using a higher transmit power on FACCH and SACCH bursts. The feature “Repeated FACCH” was developed in order to improve error protection for FACCH by transmitting redundant number of FACCH block. The second approach to improve performance of signaling channel is Temporary OverPower (TOP) which is the feature described in dedicated NOT document. 3.1
Repeated FACCH (R-FACCH)
The feature ‘Repeated FACCH’ foresees, under specific defined conditions, to apply transmit redundancy by sending a FACCH block two times, the second (repeated) block being sent immediately after the first one. Which mechanism triggers this re-transmission, is context-dependent, e.g.
For layer 2 I-frames (e.g. HO CMD, ASS CMD etc.), the usual trigger is the expiry of T200. For layer 2 UI-frames (containing the PHYS INFO message), the trigger is the expiry of T3105. For layer 2 UA-frames the trigger is the repeated reception of an SABM.
The gain of this repetition mechanism on the MS side depends on the capability of the MS to exploit this transmit redundancy in the best possible way. In more detail, MSs compliant with 3GPP Rel-6, are capable of performing a ‘joint decoding’ (aka ‘chase combining’) of the two consecutively received FACCH blocks, while legacy MSs can only treat the two received FACCH blocks as two separately received blocks. When the BSS has decided to activate R-FACCH for a particular FACCH block, the repeated FACCH block is sent in such a way that, if the first burst of the DL FACCH block is sent in TDMA frame M, the first burst of the repeated downlink FACCH block is sent in TDMA frame M+8 (or M+9, if FACCH blocks are separated by a SACCH frame or an idle frame).
3.2
Prerequisites for applicability of R-FACCH
Repeated FACCH is implemented on the BTS+ hardware platform only. The feature is applicable for LAPDm frames sent in DL for TCH/F and TCH/H for GMSK modulated speech services only (not implemented for HSCSD). R-FACCH is not applied, if the TCH is in ‘signaling only mode’.
3.3
When the R-FACCH applies to an on-going call
The R-FACCH functionality is activated for a speech call in progress using the speech codec type for which R-FACCH has been enabled in the cell if a repetition of the first FACCH block is required (provided that for this LAPDm frame type R-FACCH is applicable). It is possible to apply R-FACCH on the following FACCH messages: •
LAPDm command frames, including o
o
•
I-frames (Information frames, sent in acknowledged mode (using T200)) carrying e.g. CONNECT, ALERT, CONACK messages during the call setup phase, ASSIGNMENT COMMAND, HANDOVER COMMAND during HO phase, CHANNEL RELEASE, RELEASE COMPLETE during call release phase. UI-frames (‘Unnumbered Information’ frames, unacknowledged mode) sent during the handover phase (PHYSICAL INFORMATION).
LAPDm response frames, including o
o
o
UA-frames (‘Unnumbered Ack’, used to acknowledge an SABM frame) RR-frames (‘Receive ready’ frames are transmitted, when no information is to be transmitted on higher layers) DM-frames (frames that indicate the disconnection of an established layer 2 connection)
R-FACCH functionality is immediately deactivated as soon as the transmission of the repeated FACCH block has been completed.
4
Network introduction and parameterization aspects
R-FACCH lab tests with a BTS test load and legacy mobiles revealed that R-FACCH applied on I-frames carrying ASS CMD and HO CMD has no impact on any of the tested MS. However, some MSs seem to have problems with repeated I-frames carrying e.g. the CONNECT message and/or UA-frames. In order to avoid potential problems with legacy MSs, specific enabling options were implemented that allow, for MS with R-ACCH_CAP=0, a restriction of the R-FACCH application to specific LAPDm command frame types only. The following R-FACCH enabling parameters were implemented in BR9.0: •
•
•
enableRFacchOnCmdFrames (ERFACCHCMD), enables R-FACCH for MSs with R-ACCH_CAP=0 (or legacy MSs) on I-frames containing ASS CMD and HO CMD only, separately per speech codec type. applyRFacchOnAnyCmdFrame (RFACCHCMD), enables (per boolean flag) RFACCH for MSs with R-ACCH_CAP=0 for all LAPD command frames. enableRFacchOnLapdmFrame (ERFACCHANY), enables R-FACCH on any LAPDm command and response frame for MS with R-ACCH_CAP=1, separately per speech codec type.
For R-FACCH, the operator may use the possibility to enable R-FACCH separately for specific codec types for a careful and step-wise activation of the feature for modern MS types first, as the speech versions supported by the MS quasi reflect the ‘MS generation‘:
AMR supported: new generation MS
EFR supported: medium generation MS
Only standard FR/HR supported: old generation MS
In other words, in a network that supports both AMR and non-AMR speech services, it can be assumed that MSs are served by a non-AMR codec only if they do not support AMR and that they can therefore be regarded as an MS of an older generation. According to 3GPP TS24.008 V7.4.0 the R-FACCH capability of the MS shall be signaled to the network at call setup via the 1-bit flag ‘Repeated ACCH Capability’ (R ACCH_CAP) which is part of the ‘Classmark 3’ information element sent in the CLASSMARK CHANGE message. If this bit is set to ‘1’ (R-ACCH_CAP=1), this indicates the MS’s capability to support both R-FACCH and R-SACCH (planned for BR10). Only for those MSs with R-
ACCH_CAP=1, R-FACCH is applied on LAPDm response frames (UA-, RR- and DMframes). If this bit is set to ‘0’ (R_ACCH_CAP=0), this indicates the MS’s capability to support R-FACCH on LAPDm command frames only. Unfortunately, with the standard’s specification, the BSS cannot distinguish between Rel-6 MSs with R-ACCH_CAP=0 and legacy MSs. The difference between Rel-6 MSs with R-ACCH_CAP=0 and legacy MSs is that the Rel-6 MS is capable to perform joint decoding (chase combining) of repeated FACCH blocks, while legacy mobile MSs treat these two identical FACCH blocks as two separately received blocks Due to the R-FACCH problems experienced with legacy MS (that could result in additional call drops) the operator should enable R-FACCH in the following sequence, always observing the CDR for a possible systematic increase: 1. ERFACCHALPDMF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS|TCH_HS|TCH_FS) 2. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS), ARFACCHACMDF=FALSE 3. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS), ARFACCHACMDF=TRUE 4. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS), ARFACCHACMDF=FALSE 5. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS), ARFACCHACMDF=TRUE 6. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS|TCH_FS|TCH_HS), ARFACCHACMDF=FALSE 7. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS|TCH_FS|TCH_HS), ARFACCHACMDF=TRUE Apart of the enabling options speaking about parameterization it is worth to remember that R-FACCH feature impacts the timer on BTS. For layer 2 frames sent in ‘acknowledged mode’, the timer T200 is started to observe the reception of the layer 2 acknowledgement of the transmitted layer 2 frame. If RFACCH is applied for layer 2 frames sent in ‘acknowledged mode’, the BTS starts timer T200 only for the repeated FACCH block (i.e. T200 is not started for the first FACCH block but for the second one). If the BTS transmits the PHYS INFO message, it starts T3105 to observe the receipt of the SABM message. In case of activated R-FACCH, the value of T3105 is increased by 8 or 9 TDMA frames (the latter corresponding to the case where the two FACCH blocks are separated by either a SACCH frame or an idle frame).
5
Context of application and expected benefit
5.1
Application context
Since a significant portion of call drops is caused by lost assignment and handover command messages the feature R-FACCH is expected to substantially reduce the dropped call rate both in interference and coverage limited GERAN deployments. 5.2
Expected influence of R-FACCH on the network performance
The main effect of R-FACCH is an improvement of HO performances in critical situations, which finally shall lead to a reduced call drop during HO. On the determination of the final cause of dropping during HO, of high importance is the timers configuration defined by operator for its network. Assuming a properly configured network the area of expected improvement can be identified analyzing feature employment scenarios during handover. Therefore the figure below illustrates message flow for intercell HO procedure. Marked in yellow there are these messages that are impacted by R-FACCH feature.
Figure 2 Message flow for intercell HO. The first message in HO procedure which is impacted by R-FACCH is HO CMD. This message is sent in acknowledge mode and therefore MS should send Received
Ready LAPDm response frame as acknowledgement. 1 In BTS timer T200 waits to receive the acknowledgement and if it expires it retransmits HO CMD. After N200 retransmissions BTS sends ERROR INDICATION and connection is regarded as dropped. With R-FACCH feature in case of retransmission two identical FACCH block are sent one after another what increases probability that FACCH block will be correctly decoded. This causes that the number of call drops due to T200 expiry will decrease. The second message for which the R-FACCH will increase the probability of correct decoding is Physical Information. This message is sent by BTS and timer T3105 is started. T3105 runs as long as BTS receives SABM message or it expires. After T3105 expiry BTS retransmits PHYS INFO. After NY1 retransmissions BTS sends a CONNECTION FAILURE indication with cause 'Handover access failure' to the BSC and the new allocated channels are released. In order to avoid the transmission of the CONN FAIL indication while the MS falls back to the old channel due to unsuccessful access to the target cell (thus an unjustified registration of a 'call drop') following inequality must be satisfied: NY1*T3105 >= 2 sec. As R-FACCH improves performance of downlink FACCH in case that it was activated on any LAPDm command frames (ARFACCHACMDF = TRUE) the number of call drops due to HOAF should decrease. The last message which probability of correct decoding is increased by R- FACCH is Unnumbered Acknowledgement (UA). UA frames are only sent as a response to received command frames SABM. If MS does not receive UA as response to SABM it retransmits this command frame. The time between two retransmissions is 32 TDMA frames (T200 setting on the MS side) in case of FR speech TCH (40 TDMA frames in case of HR speech TCH) and the total number of retransmissions (N200 on the MS side for SABM) is restricted to 5. If the UA-frame is correctly received the MS will send on the UL FACCH of the new channel the ASS CMP or HO CMP message concluding a successful HO procedure. If the MS was not able to correctly decode the UA-frame (after it has been retransmitted 5 times as described above) the MS returns to the old cell (handover fallback). Assuming that R-FACCH is active on any LAPDm frames (ERFACCHALPDMF = ENABLE) the better FACCH performance on UA frames will decrease number of unsuccessful HO with reversion to old cell (HO fallback) should decrease. It can happen that HO fallback will be unsuccessful (eg. SABM to the old cell does not get through). In such a case BSC receives neither HO CMP nor HO FAILURE, T8 1
In practice - whether the MS acknowledges a single I-frame on the old channel (by RR-response) before it switches over to the new channel depends on the mobile type (i.e. some mobiles do send the RR, others do not). This means that it can happen that, during an ongoing channel change procedure (HO, TCH assignment etc.) the I-frame that contains channel change message (e.g. HO CMD) is continuously repeated by the BTS due to missing layer-2 acknowledgement on the old channel. This 'T200context' is terminated: a) after successful access to the new channel: by the release of the old channel ( RF CHANNEL RELEASE received at the BTS), or b) by the receipt of a new SABM from the MS on return to the old channel after unsuccessful access to the target channel (this SABM initializes the T200 context and flushes the previous timer history).
in BSC expires and connection is released. For this reason R-FACCH on UA frames will decrease the number of Unsuccessful Internal Handovers Intercell with Loss of MS. As R- FACCH is also used in intracell HO this procedure must be also analyzed in order to find expected benefit from R-FACCH. The following picture presents message flow for intracell HO. Marked in yellow there are these messages that are impacted by R-FACCH feature.
Figure 3 Message flow for intracell HO In case of intracell HO the first message which is impacted by R-FACCH is ASSIGNMENT COMMAND. It is Information frame (one of the LAPDm command frame) which is send in acknowledgement mode. The supervision timer (which waits for reception confirmation) is T200. Therefore similar to intercell HO R-FAACH on ASS CMD message will decrease the number of call drops due to T200. The next message affected by the feature is UA. If MS does not receive UA it retransmits this SABM frame. The number of retransmissions (N200 on the MS side for SABM) is restricted to 5. If the MS was not able to correctly decode the UA-frame (after 5 retransmissions) the MS returns to the old channel. If R-FACCH is active on UA frames the number of unsuccessful HO with reversion to old channel (HO fallback) should decrease.
It can happen that HO fallback will be unsuccessful (eg. SABM to the old channel does not get through). In such a case BSC receives neither ASS CMP nor ASS FAILURE, T10 in BSC expires and connection is released. For this reason R-FACCH on UA frames will decrease the number of Unsuccessful Internal Handovers Intracell with Loss of MS. As ASS CMD is also in use during TCH assignment procedure, feature R-FACCH impacts SDCCH drop statistics. In order to better understand it, message flow for assignment procedure should be analyzed. TCH assignment is the procedure when after immediate assignment (connection on SDCCH is established) connection is switched over from SDCCH to TCH.
Figure 4 Message flow for TCH assignment procedure In case of TCH assignment R-FACCH is used on ASS CMD message the probability that SDCCH drop due to T200 expiry is decreased. It also decreases the number of assignment failure due to T10 expiry (radio interface message failure). For R-FACCH activation on UA frames the advantage is reduced number of unsuccessful TCH assignments with reversion to SDCCH.
R-FACCH was developed in order to reduce the number of call drops in the network. This is soft capacity feature as reduced CDR (as benefit from R-FACCH) allows us to go to the higher EFL. Thus the benefit in CDR figure can be easily transformed into the capacity.
5.3
Possible side effect of the introduction of R-FACCH
As described in chapter 1 R–FACCH works in this way that in need of retransmission of DL FACCH block BTS sends two identical FACCH blocks immediately (instead of the one). This improves FACCH performance but it also increases the number of redundant signaling messages. As during the intercell HO these FACCH blocks are sent at maximum power R-FACCH can slightly increase interferences. However feature impact on interference is so low that it can be neglected (specially comparing to benefit in call drop statistics). 5.4
Cell context proposals for analysis of R-FACCH effects
The effects of the introduction of R-FACCH can be verified in any cluster of cells as feature gives the benefit both in noise and interference limited scenarios.
6
Results of simulations or collected from field According to link level simulation results the expected gain for Downlink Repeated FACCH functionality is about 4dB for new MS (i.e. compliant with Rel-6), capable of performing a joint decoding (chase combining), and about 2 dB for legacy MS (due to ‘fast’ FACCH repetition). Apparently the benefit strongly depends on the penetration rate of Rel-6 compliant MS. The presented here benefit refers to C/I conditions which can now decrease about 4 dB or 2 dB correspondingly to guarantee stable connection.
7 Verification introduction
of
the
network
improvement
after
feature
In order to estimate the improvement provided by R-FACCH it is suggested to observe counters and KPI related to call drops (and call drops in relation to traffic load) before and after feature activation. It is expected that these counters should generally indicate a decrease of the call drop figures. Applying the R-FACCH feature shall result in the following changes (towards network without R_FACCH) of the certain KPIs (for definitions of specific KPIs refer to chapter 8): •
Drops due to T200 per Erlh will decrease;
•
Drops due to HOAF per Erlh will decrease;
•
Intercell HO Drops (T8 expiries) will decrease;
•
Intracell HO Drops (T10 expiries) will decrease;
•
Call drop rate, TCH drop rate, TCH Drop Erlh will decrease;
•
HO failure rate will decrease;
•
TCH Assignment failure rate will decrease;
•
SDCCH drops due to T200 per Erlh will decrease;
•
FACCH repetition rate should increase.
Additionally the feature can be verified by History on Dropped Call Traces as this functionality provides additional information about the status of the connection which was dropped as: UL and DL RxLev, UL and DL RxQual, TA, CGI of the target cell (in case of call drop during HO procedure).
8
Evaluation of the feature impact with SAG tools 8.1
Feature impact on AnatomN
The idea of this document is to present how to measure expected benefit coming from implementation of R-FACCH. In order to do this the results of PM counters before feature activation have to be collected and then compared to the results from the period after R-FACCH activation. This can be done in AnatomN with the usage of attached predefined report which can be simply saved and imported in AnatomN (this report can be updated with new BR 9.0 counters when AnatomN v2.1 with BR 9.0 counters is available).
R-FACCH feature verfication.arp
Figure 5 AnatomN predefined report presenting KPIs which should be observed in order to verify benefit from R-FACCH activation. 8.2
Feature impact on Radio Network Analyser (RNA)
Radio Network Analyzer provides the History on Dropped Call functionality which allows tracing of the number of calls which were dropped with cause of drop and additional information as RxQual, RxLev, TA and CGI of the target cell (if drop
occurred during handover). Therefore this tool can be used as the crosscheck option for the analysis performed in post processing offline PM tool (like AnatomN). 8.3
Feature impact on Siemens PM Counters
The implementation of R-FACCH will have significant impact on the network performance. This impact will obviously influence the results of Performance Measurement counters in Siemens SBS. Here below listed all counters which results will change after introducing R-FACCH which stay behind the formulas of the KPIs included in AnatomN report enclosed in chapter 8.1. FACCHSUP - FACCH Supervision - this is new BR 9.0 measurement which provides the number of transmitted I (ASSHOCMD), UI (PHYS INFO) and UA frames as well as it gives the number of transmitted FACCH blocks utilized to send these frames (I, UA and UI) over the radio interface. It differentiates for 5 codec types: FR, HR, EFR, AFS and AHS thus all together there are 10 new subcounters. Based on them KPI FACCH Repetition Rate can be calculated as: FACCH Repetition Rate = 1 - FACCHSUP(k)/ FACCHSUP(k+5), k=1,….5 where k represents subcounter number dedicated for a specific codec type KPI interpretation: Let assume that there were 8 different HO CMD received by BTS which were segmented into 8 FACCH blocks. For one FACCH block retransmission was needed as T200 expired. This retransmitted block was sent twice due to R-FACCH functionality. All together 10 FACCH blocks were sent on the air interface while only 8 HO CMD were received by the BTS. In such a case FACCH Repetition Rate = 2/10 what means that 10 FACCH blocks including 2 retransmissions. As R-FACCH sends two identical FACCH blocks twice (when retransmission is needed) it is expected that after feature activation KPI FACCH Repetition Rate will considerable increase. Impact on call drop statistics NRFLTCH [1,10] – Number of lost TCH connection - this measurement determines the total number of lost connections (while using TCH/F or TCH/H) due to T200 expiry. Based on this counter, KPI which gives the relation between drops due to T200 expiry and carried traffic can be calculated. Drops_T200_Erlh = NRFLTCH[1,10] / MEBUSTCH[1..4] where MEBUSTCH = Mean Number of Busy TCHs counters; With enabled R-FACCH it is expected that the value of this KPI will significantly decrease.
NRFLTCH [6,15] – Number of lost TCH connection - this measurement determines the
total number of lost connections (while using TCH/F or TCH/H) due to handover access failure (T3105 expires NY+1 times and MS does not succeed to return to the old cell with HO FAIL). Based on this counter, KPI which gives the relation between HOAF drops and carried traffic can be calculated. Drops_T200_Erlh = NRFLTCH[6, 15] / MEBUSTCH[1..4] With activated R-FACCH it is expected that the value of this KPI will significantly decrease. NRFLTCH [9,18] - Number of lost TCH connection - this measurement determines the
total number of lost connections (while using TCH/F or TCH/H) due to unspecified cause”. It is triggered by the expiry of the timer BSCT8 in the context of an MSCcontrolled intercell or intracell TCH-TCH handover or the expiry of the timer BSCT3121 in the context of an outgoing 3G-MSC-controlled 2G-3G handover. Based on this counter, KPI which gives the relation between these drops and carried traffic can be calculated. Drops_Other_Erlh = NRFLTCH [9, 18] / MEBUSTCH[1..4] With activated R-FACCH it is expected that the value of this KPI will significantly decrease. UNIHIALC - Unsuccessful Internal Handovers Intracell with Loss of MS - this
measurement determines the number of intracell handover failures where connection with the MS was lost and T8 expired. From this counter the rate between intercell HO drops and the traffic can be estimnated. HO_Drops_Erlh = UNIHIALC / MEBUSTCH[1..4] With enabled R-FACCH it is expected that the value of this KPI will significantly decrease. UNIHIRLC - Unsuccessful Internal Handovers Intercell with Loss of MS - this measurement determines the number of intercell handover failures where connection with the MS was lost and BSC timer T10 expired. From this counter the rate between intercell HO drops and the traffic can be estimnated. HO_Drops_Erlh = UNIHIRLC / MEBUSTCH[1..4] With enabled R-FACCH it is expected that the value of this KPI will significantly decrease. The counters presented above are included in the call drop statics as: CDR, TCH Drop Rate and TCH Drop Erlh. Since these counters are impacted by R_FACCH
feature these call drop statiscs (mentioned above) will decrease together with the counter values. Impact on handover statistics When R-FACCH is active it is expected that following counters related to unsuccessful HO procedure will reduce their values: UNINHOIA [1..14] - Unsuccessful Internal Handovers Intracell - this measurement
provides the total number of unsuccessful intracell handovers with reversion to old channel. UNINHOIE [1..11] - Unsuccessful Internal Handovers Intercell - this measurement provides the number of unsuccessful intra-BSC-HOs per cell with reversion to old cell. NRUNINHD [1..10*n] - Unsuccessful Outgoing Inter-BSC Handovers - this measurement provides the number of unsuccessful inter-BSC-HOs with reversion to old cell. (n – represents number of neighbour relation per cell) UNOISHDO [1 .. 10*n] - Number of Unsuccessful Outgoing Intersystem Handovers - this measurement provides the number of unsuccessful handovers from the observed GSM cell to a neighbour UMTS (cell controlled by a different system) with reversion to old cell. (n – represents number of neighbour relation per cell)
Based on above listed counters HO Failure Rate can be calculated as relation between unsuccessful HOs (intracell, intercell intra BSC, intercell inter BSC, intersystem) to all attempted HO. HO Failure Rate =( UNINHOIA [1..14] + UNINHOIE [1..11] + NRUNINHD [1..10*n] + UNOISHDO [1 .. 10*n])/ (ATINHIAC [1..14] + ATINHIRC [1..11]+ ATINBHDO [1..10*n] + ATOISHDO [1 .. 10*n]) Repeated FACCH functionality will reduce the value of this KPI. Impact on assignment statistics: TASSFAIL [6,7,11,12] - (number of times an assignment attempt of a TCH or SDCCH
failed due to radio interface message failure or due to radio interface failure reversion to old channel) should decrease. Based on this counter TCH Assignment Failure Rate can be calculated: TCH Assignment Failure Rate = TASSFAIL [6,7,11,12] / TASSATT [1..3] Impact on SDCCH drop statistics: NRFLSDCC [1] – Number of lost SDCCH connection - this measurement determines
the total number of lost connections (while using SDCCH) due to T200 expiry. Based on this counter, KPI which gives the relation between drops due to T200 expiry and carried traffic on SDCCH can be calculated. SDCCH_Drops_T200_Erlh = NRFLSDCC [1] / MBUSYSDC
where MBUSYSDC = Mean Number of Busy SDCCHs; With enabled R-FACCH it is expected that the value of this KPI will significantly decrease.
