Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

Low HO SR due to ROC

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • 5th March 2012 at 09:22 #67960
    milo
    Guest

    Hi,
    have the above mentioned problem in Alcatel. Not frequency dependant, HW is ok. HO reason – better cell (above 85%). No interference. Target cell with DCS. Only outgoing HO is affected.Trace on abis – no fails, but strange intracell HO between 1800/900 – bad quality.
    I will appreciate any help or suggestions.

    Thank you.
    BR, Emilov

    5th March 2012 at 15:42 #67961
    pix
    Guest

    hi emilov,

    there is HO failures from 900 to 1800 cells ?
    or also from 1800 to 1800 cells ?

    There are also a lot of HO from 1800 to 900 due to bad quality ?

    From 900 to 1800, please provide values for those indicators:

    HO_Out_2G_2G_prep_fail_rate
    HO_Out_2G_2G_drop_radio_rate
    HO_Out_2G_2G_drop_BSS_rate
    HO_Out_2G_2G_ROC_rate
    HO_Out_2G_2G_required

    Does it happen on 1 cell, few cells, or many cells ?

    Most common cause for outgoing HO failures is poor radio conditions (bad rxlev or bad rxqual).
    It is further confirmed by the high amount of HO QUAL measured in 1800 cells.

    It proves that 1800 frequencies are quite interfered or provide a low coverage, which result in:
    1/ hard to keep HO from 900 to 1800
    2/ happy to trigger HO from 1800 to 900 due to bad quality.

    Cheers
    pix

    6th March 2012 at 12:11 #67962
    milo
    Guest

    Hi, Pix
    The fails are between co-sited cells both dualband in an urban area with perfect coverage.From time to time 1 or 2 more cells fail against the same one. Fails are not distributed – sometimes all are in one hour, sometimes during the whole day. I dont know if HO are triggered from 900 or 1800 but RTCH_HO_Out_ROC has values for both bands. Abis showed that after camping on target cell 1800 TCH, after a couple of meas rpt the RxQ gets bad (BER >12,8%) and then a intraHO is triggered. The level of 900 is good enough and HO to preffered band is triggered again. And so on until channel release.
    HO_Out_2G_2G_prep_fail_rate = 0.18
    HO_Out_2G_2G_drop_radio_rate = 0.09
    HO_Out_2G_2G_drop_BSS_rate = 0
    HO_Out_2G_2G_ROC_rate = 25.29 number of roc = 287
    HO_Out_2G_2G_required = 1137
    (daily)
    No interference is measured. And locking DSC on similar situation didnt have any effect. Frequency changes on 1800 were executed and some parameters tuned (MS to enter 1800 on better levels)-no result.
    HO causes – BC-95%; DLL-0.8;ULL-1.4:ULQ-1.2;DLQ-0.6;INTERF-1.8
    DT is on its way.

    CR, Emilov

    6th March 2012 at 15:05 #67963
    pix
    Guest

    hi emilov,

    I think you are looking at a ping-pong HO between 900 and 1800, due to “better conditions”.

    The bad Quality is not reflected on the HO : 95% of HO are BC !!

    Therefore you are probably looking at a parameter issue.

    On the other hand, you are saying that the problem appears randomly, as “peaks” during the day. Which would suggest that this is a software problem…

    So I don’t know.. based on QoS stats from NPO, can you specify the problem a little better ?
    I don’t think Abis or drive test would help here : you should be able to find much more info from NPO indicators.

    Regards
    pix

    6th March 2012 at 15:43 #67964
    milo
    Guest

    Thank you.
    For sure will be done 🙂
    Can you suggest where to look for information about ROC because I’m unable to find some valuable one?
    CR, Emilov

    6th March 2012 at 16:19 #67965
    pix
    Guest

    sure, ROC means that :
    1/ the HO was detected (due to any condition : bad level, bad qual , BC, etc etc)
    2/ the target cell was found and is not congested (= a tch could be seized by the BSC to welcome the incoming MS)
    3/ the serving cell send a HO CMD to the MS
    4/ the target cell was not able to connect with the MS (due to bad radio conditions, in 99.9% of the cases)
    –> that is the HO failure
    5/ the MS succesfully manages to go back to the initial source cell.
    —> that is the “Reversion to Old Channel (ROC)”

    So your problem is mostly due to radio in the target cell.
    The main problem, in my opinion, is WHY are there so many HO detected in the source cell (are there too many HO per call ?? please confirm on this one …)

    6th March 2012 at 17:31 #67966
    Aakrit
    Guest

    Hey Pix !!!!

    HO Per Call seems to be intresting comment,How it can be checked in ALU system, Can i check this from any NPO reports??

    6th March 2012 at 18:30 #67967
    pix
    Guest

    hi,

    look in the list of cell indicators “ho_per_call”, you can’t miss it.

    i don’t know in which report it appears, but that’s easy : from the indicator list, just drag and drop into the “report tab”, that will highlight all reports in which this indicator is used.

    cheers
    pix

    7th March 2012 at 07:44 #67968
    milo
    Guest

    Hello Pix,

    HOPC (source) = 0.59-0.87 (range of values for the last month; 0.61 for 05.03)
    HOPC (target) = 0.62-0.89; 0.69 for 05.03).

    CR, Emilov

    7th March 2012 at 17:36 #67969
    pix
    Guest

    there is less than one HO per call… so definitely no ping pong here.

  • Author
    Posts
Viewing 10 posts - 1 through 10 (of 10 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.