I know bruv, i can see everything in ur snapshot... but the snapshot which u have attached for this question is having 2 information, neighbors and serving both. You are mismatching the same cell id in two different places.
Remember:
Whether you are in dedicated mode or idle mode, your NEIGHBOURs will remain idle. So supposing that you are doing a dedicated mode call test, you are still receiving the idle mode signals of your neighbors !!!
In Layer3 snapshot, your rxlev of first neighbor is good enough to be served that is why in your 2nd window it was served by that neighbor. The difference of moving from 1st neighbour to served cell is really quck. Check for the handover message reported in TEMs !
David has shown you the nice picture, pls review it, i hope it answers your question now !
Last edited by venom; 2009-03-21 at 11:43 AM
dear
TA for serving cell is 1
Neighbor window is using values directly from layer3 messages, there is no other source for that window, so this difference is because of "like(110-80=40)". if you check the values in neighbour window changes by every new measurment report, when ms gets new measurment report, tems is updating that window
Last edited by timedomain; 2009-04-22 at 05:19 PM
dear timedomain
Thanks for your explanation
BR
You should also check if you have defined all the neighbors' ARFCN in MBCCHNO parameter.
The RXLEV values must be typically between -98 to -106 dBm.
The HO would depend on HANDOVER MARGIN (must be atleast -24 DB)
Regards,
Amit
agarwalamit081@gmail.com
the neighbour RxLev in Layer 3 is using "index"...
the value range is between 0 - 63.
0 = -110 dBm
1 = -109 dBm
.
.
.
63 = -47 dBm
a slight difference in your neighbour level ( -61 dBm in neighbour window) perhaps due to power control. but your serving cell pointing the correct value ( 30 in layer 3 then -80 dBm in neighbour window).
The Example from hassen should clear things up..
BR,
nevy_14
Very good info from nevy_14 and hassan of course...sincerely i neva knew this 'Index' thingy.
Bookmarks