Generic selectors
Exact matches only
Search in title
Search in content

Co-site HO Failures

  • This topic is empty.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #52132 Reply
    m12
    Guest

    greetings,

    I’m on a network using Ericsson BSS and i’ve a problem with some cells failing to handover to co-site neighbours.

    parameters are OK with the cell being on the same LAYER and LAYERTHR.

    #52133 Reply
    Pix
    Guest

    hello m12,

    what do you mean by “failing” : are you seeing this during drive-tests, or on QoS statistics ?
    During drive-tests : there is handover failures, or just there is no ho while you’re expecting one to occur ?

    With QoS : do you see HO Request, HO Command, HO Success ? If there is a failure, what is the cause of the failure ? Congestion, Radio problem, with or without Reversion to Old Channel ?
    What about the target cell : does it accept HO from other cells ? Without failures ?

    #52134 Reply
    m12
    Guest

    thanx Pix,

    i have observed poor HO success Rate from Stats, BO reports to be specific.

    from the report, apart from HOSR, there is number of HO attempts as well as PingPong HO (%).

    the target seems to successfully accept HO’s from other cells.

    unfortunately the reports i have does not give a breakdown of causes for poor HOSR.

    more ideas please…

    #52135 Reply
    Pix
    Guest

    ok, thanks for the details.
    thanks to that, we can say that :
    the bsc gets measurements from the MS about the target cell
    the target cell is candidate for the handover
    from that point, there are two possibilities :

    1. the ms receives a ho command from the BSC, with target ARFCN and target TS, but when MS sends the HO ACCESS to these ARFCN/TS, nothing happens.

    2. the BSC cannot activate a radio resource on the target cell (typically, because of congestion)

    can you have the split of outgoing HO successes per target cell, from the serving cell ?
    or the split of incoming HO successes per serving cell, from the target cell ?
    is the HO successes between our two cells = 0, or is it greater than 0.
    What about HO success in the other direction ?

    Anyway, that’s interesting to investigate, but in my opinion the problem is hardware. Before that, perhaps you could ensure the couple BCCH/BSIC of target is unique in the vicinity ? Or ensure the couple TCH/BSIC is different than the BCCH/BSIC of another cell in vicinity ?
    Regarding hardware, perhaps change the synchronization/control card (called “SUM” in alcatel) in target or in serving would help ? Of course, this is troubleshooting, I gues ericsson experts could have a better idea than mine.

    #52136 Reply
    kat
    Guest

    Hi,
    Pix I understand that you want to ensure the unicity of BCCH/BSIC of the target cell in vicinity but I dont really see why you are interested in TCH/BSIC !!
    In all cases I join you and I suspect that it is a hardware problem unless a special tuning is set for co-site cells in this network 🙂

    In fact anyone have a general strategy to optimize neighbourhood relations : when adding/deleting HO relation, which creteria, inputs,…?

    Danke

    #52137 Reply
    Pix
    Guest

    Hello Kat,

    During a handover, the MS receives a HO COMMAND from the BSC, describing the target cell “A”. In fact, it describes the target “TCH” (frequency = 54, bsic = 11)

    Then, the MS must try to access the target TCH, by sending the access burst “HO ACCESS”, towards this TCH. If there is a cell “B” somewhere that uses the frequency 11 as BCCH frequency, with BSIC = 11, then it will decode the access burst “HO ACCESS” as a “CHANNEL REQUEST”, and it will therefore allocate a SDCCH channel.
    Of course, this is a mistake, because the MS is not trying to send a CHANNEL REQUEST to cell “B”, but it is sending HO ACCESS to cell “A”.

    But ok, I don’t know for sure if that can lead to some HO failures, in some weird ways, as described by m12.

    #52138 Reply
    Vanderley
    Guest

    Hi Kat,
    some people use mixed BCCH/TCH alocation, so it could happens that the BCCH of a cell is equal to TCH of another cell. The MS is not decoding the BCCH every time so it could be misleaded for the signal strengh from the TCH, report it and to receive a HO command from the BSC to go to a cell that has this frequency as BCCH. Then a HO fail…

    #52139 Reply
    Da Architect
    Guest

    Dear m12,

    make sure that parameter CS = yes for co-sited cells.

    #52140 Reply
    John008
    Guest

    Hello m12,

    I also witness such a co-site HO failure on our network some moonths ago.

    In order to solve the issue, I’ll advice you to check the followings:

    1. Check the BCCH frequencies of the cells
    2. Check the BA lists of the cells (Confirm if the BCCH of the target cell is present in the BA lists of the serving and vice-versa)
    3. Check the HO Relation definition btween the 2 cells (Mainly the CS parameter as suggested by Da Architect)
    4. Run a drive test in the area to check interferrence levels
    5. Make relevant corrections in the BA list;

    Moreover, If you are used to the OSS, please initiate a Consistency Job in the CNA. This will surely help you to clean up you network BA List wise.

    Stay Cool,

Viewing 9 posts - 1 through 9 (of 9 total)
Reply To: Reply #52137 in Co-site HO Failures
Your information:




<a href="" title="" rel="" target=""> <blockquote cite=""> <code> <pre class=""> <em> <strong> <del datetime="" cite=""> <ins datetime="" cite=""> <ul> <ol start=""> <li> <img src="" border="" alt="" height="" width="">