- This topic has 25 replies, 1 voice, and was last updated 13 years, 1 month ago by paraHO.
11th March 2008 at 05:56 #51455MKTGuest
A MS in dedicated mode continuously sends the measurement reports over SACCH to the BTS. Based on these reports BSC takes the decision and orders the handover(if necessary).
I want to know…
A MS continuously measures the Rxlev of “neighboring” BCCH frequencies and sends them over SACCH. Now the “neighboring” refers to what?-
a) Is it the list of those BCCH frequencies which were told to MS by the BTS that here is the list of your neighbors. And the MS will do the MEASUREMENTS only on these frequencies/neighbors.
But if above mentioned case is true..then why a HANDOVER FAILURE will occur?
Since a MS will never send a report for a BCCH which is not present in its neighbor list. Thus the BSC will never order for the handover to that frquency. And if there is no order there will be no attempt. So how does the question of handover failure arises?
Regards11th March 2008 at 09:40 #51456PixGuest
a) yes, the MS measures only the neighbour BCCHs transmitted in the system information messages SI2 (or SI5 ? i can never remember).
HO Fail can occur if
1- the BCCH(n) is good, then the HO is trigerred,
a) the target TCH is on the BCCH TRX : the RxLev is known to be good, but RxQual can be poor –> interference. The HO ACCESS can’t be heard by the target, or the reply BTS->MS can’t be heard by the MS.
–> poor Rx sensitivity of the BCCH TRX
–> hardware problem : TCH can’t be allocated on the timeslot, etc…
b) actually the HO COMMAND message from serving cell -> MS contains the reference of a target “TCH timeslot” that is not on the BCCH TRX. So the MS will jump onto a TCH, which is not on the BCCH TRX.
–> interference on TCH TRX
–> poor tx power of this TRX
–> poor Rx sensitivity of this TRX
–> hardware problem : TCH can’t be allocated on the timeslot, etc…
c) the measured BCCH(n) does not belong to a neighbor defined in OMCR (same BCCH, but different cells ! bad frequency planning, yes !)
Bad luck, it is also using the same BSIC as the real neighbor.
For the BSC point of view, this fake neighbor is the real neighbor. The HO COMMAND is sent to MS, but MS cannot access this “fake” cell : the BSC didn’t prepare the fake neighbour to receive this MS, it prepared the real one only.
–> Poor BSIC/BCCH planning
pix11th March 2008 at 13:18 #51457paraHOGuest
SI2 is for MS in idle mode, SI5 as you correctly say is for MS in dedicated mode11th March 2008 at 16:38 #51458PixGuest
thx 🙂13th March 2008 at 04:02 #51459MKTGuest
Thanks for your reply.
But I am not satisfied with the replies. Confusion is still there. Let me take it further with your views one by one.
A HANDOVER is triggered if the BCCH(n) is found to be better then the serving BCCH.
And as per your point no.(c)
“the measured BCCH(n) does not belong to a neighbor defined in OMCR”
Since i have not defined a cell with BCCH frequency BCCH(n) as the neighbour of current serving cell then…..Why the MS has performed the measurements on BCCH(n)(may be fake or true one, doesn’t matter)??
Also iam assuming that a MS will use the SI2 list for cell reselection purpose and SI5 list for handover purpose. Thus if SI5 list doesn’t contain a BCCH(n) as per our case then how things will go please explan.
Regards13th March 2008 at 05:49 #51460ManiGuest
You are right for Handover to be performed the BCCH should be in SI5 List. The problem occurs if there are two neighbours with that BCCH one is defined in the serving cell and the other is not defined. then it measures the BCCH and since the same BCCH is used twice in the vacinity there is chances of it being interfered.
Scenario 1. A has C but no B and C has B.
Now for a case where imidiate neighbours BCCH is not in the list then. In DT you might notice Twin HOs. Lets say Serving Cell is A
best B and second Best C
1st HO from the the serving cell A to the second best neighbour C as the B’s BCCH is not added.
2nd HO from the second best neighbour C to B as C has B defined in BA list and B is the best based on leavel and so a PBGT HO will be trigerred.
A does not have B and C does not have B.
For this case handover shall not be initiated towards B. Worst case lets say a new site comes on air with ZERO neighbours then it will not take any handover traffic.13th March 2008 at 08:51 #51461pixGuest
yes, in c), i assume the following :
serving cell has CELL B defined as neighbour, with BCCH=12 and BSIC=01
The MS in the serving cell receives a SI5 containg the list of BCCH to measure. It includes ARFCN=12.
The MS measures the RxLev of frequency 12 and decodes the BSIC.
The MS reports the following to the BSC :
ARFCN=12, BSIC=01, RXLEV=-70dBm
The BSC will look at this report and guess that the reported cell is the CELL B.
But in fact, the MS has measured CELL Z, which is located 20km away, and is defined with BCCH=12 and BSIC=01 also.13th March 2008 at 09:54 #51462MKTGuest
i think this type of case will lead to CALL DROP.
What happens in the cases where CALL is not dropped. I mean MS attempts for a handover but fails to do so. And we see a crossed hand type of symbol in TEMS.
What is this case.
I mean how do they came to know from the handover failure that the target is not defined as the neighbour in OMCR.
Regards13th March 2008 at 10:46 #51463BilalGuest
Handover failure does not necessarily lead to a call drop. MS is mostly successful in reverting back to the original cell especially in the case of a Better Cell Handover.
Co-BCCH/BSIC case: MS will receive a Handover Command for the cell which is defined as a neighbor instead of the stronger but undefined cell with same BCCH/BSIC. Now MS will try tuning to the new channel of the undefined cell(stronger) but will fail because the info sent in the Handover Command such as MAIO, HSN, TSC etc is not for this cell and BSC hasn’t allocated any channel in this cell. Result is a handover failure with possibility to reversion to old channel.
I am somehow getting a perception that you think handover failure only occurres due to missing definition in OMCR. But this is not the case. Handover failure has many other reasons as explained by Pix in point a and b.13th March 2008 at 11:02 #51464MKTGuest
Missing defination of a neighbour can never ever lead to handover failure ——-this is my perception.
Just prove it wrong!13th March 2008 at 11:08 #51465MKTGuest
Let us take an example
MS is in CELL 1.
CELL 2 is the immediate neighbour of CELL 1.
MS is moving towards CELL 2.
CELL 2 is not defined as a neighbour if CELL 1 in OMCR.
Can you say that a HANDOVER FAILURE can occur from CELL 1 TO CELL 2.
I will say NEVER.
Regards13th March 2008 at 11:47 #51466BilalGuest
Yes, you are perfectly all right. We were talking about a completely different scenario i.e. Cell 1 has a defined neighbor Cell 3 with same BCCH and BSIC as of Cell 2. This will cause a handover failure between Cell 1 and Cell 3. There is absolutely no point of a handover failure between two cells who are not defined as neighbors 🙂13th March 2008 at 12:17 #51467pixGuest
yes, it’s what bilal said : it will NEVER happens. We all agree here.
in the co-BCCH/co-BSIC situation i described in my previous post, it will lead to a HO failure, certainly with a reversion to previous TCH channel. So, no drop.
So problem of HO failure as reported in TEMS :
1. HO COMMAND is received by the MS
2. HO ACCESS is sent to the target cell
3. but no answer from the target cell.
After a while (timer expiry), the MS will try to go back to previous cell.
If reversion succesful, then there is a ho failure without drop
If reversion failed, then there is a ho failure with drop.13th March 2008 at 15:22 #51468paraHOGuest
So this handover failure condition would it be one of these:
Cause value = 101 No cell allocation available;
indicates that an assignment or handover is unsuccessful because the MS has no current CA.
Cause value = 8 Handover impossible, timing advance out of range; indicates that a handover is unsuccessful because the target BTS is beyond the normal range and the target BTS would not accept an out of range timing advance.13th March 2008 at 17:01 #51469pixGuest
there are more causes than this in the message HO FAILURE, aren’t they ?
what i see in a A interface trace is mostly “HO FAIL – cause : abnormal unspecified” 🙂