- This topic has 8 replies, 1 voice, and was last updated 14 years, 3 months ago by John008.
25th April 2008 at 04:54 #52132m12Guest
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.25th April 2008 at 06:05 #52133PixGuest
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 ?25th April 2008 at 06:19 #52134m12Guest
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…25th April 2008 at 19:09 #52135PixGuest
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.26th April 2008 at 18:43 #52136katGuest
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,…?
Danke26th April 2008 at 19:22 #52137PixGuest
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.29th April 2008 at 09:08 #52138VanderleyGuest
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…29th April 2008 at 11:57 #52139Da ArchitectGuest
make sure that parameter CS = yes for co-sited cells.5th May 2008 at 08:24 #52140John008Guest
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.