- This topic has 8 replies, 1 voice, and was last updated 10 years, 4 months ago by JZ.
24th September 2010 at 13:47 #64418JZGuest
A network is running baseband hopping (BCCH included) with SDCCH allocated on TCH. Consider two nearby cells: BCCH1=TCH2 and BSIC1=BSIC2. Problems with SDCCH timeouts are encountered and they go away when BSIC1 or BSIC2 is changed.
I don’t have explanation for this. BSIC is broadcast on BCCH and only co-BCCH/co-BSIC reuse should be relevant. Can anyone comment potential co-BCCH/TCH + co-BSIC reuse? Where could problems be coming from?
Thank you in advance.4th October 2010 at 10:52 #64419MustaffGuest
In baseband hopping Co-Bcch/TCH will create a problem since our dedicated timeslot hops in between BCCH and all TCH channels available.
Even with different Bsic, using co-bcch/tch can create a problem.
Best Regards;4th October 2010 at 11:03 #64420pixGuest
indeed, when a MS goes to the cell n2 by doing a Incoming HO, a HO ACCESS is sent to TCH(n2) with BSIC(n2)
will be understood as a CHANNEL REQUEST on BCCH(n1) with BSIC(n1) = BSIC(n2)
This will happen because the TCH(n2), on the TS4 -let’s say-, is scheduled at the same time as the TS0 of TRX1 of the cell n2. The 2 cells are not synchronized. When MS sends HO ACCESS to TS4 of n2, it will also be heard in cell n1, in the TS0.
pix4th October 2010 at 11:17 #64421MFGuest
in dedicate mode, channel number(ARFCN) is important for both MS and BSC. it is not important if the serving channel is bcch or tch. in any case it will suffer interference.4th October 2010 at 21:01 #64422pixGuest
we’re talking about sdcch timeouts 🙂6th October 2010 at 02:21 #64423JZGuest
Thank you very much, makes perfect sense.
Can you comment on anything vendor-specific that could help? For example, better error coding on the message ID, so HO_Access is not misinterpreted as Channel_Request? In other words, would you expect this effect to depend on equipment vendor?
Thank you in advance6th October 2010 at 06:16 #64424pixGuest
no, all those air-interface protocols are fully described and full frozen in the 3GPP (because they are ms-dependent)
I can give you two solutions :
– don’t do handovers (…)
– *more seriously, i promise* optimize the rach_ta_filter in n1 : the ho access from n2 arrives at random toa (time of advance) in the cell n1, because the 2 cells are not sync. The TOA here does not indicate the distance between MS and the n1, it is just a random value. For n2, of course, it represents the distance MS to n2.
By setting rach ta filter(n1) = 32 instead of 64 (limiting the call setup coverage at 18km instead of 36km, which sounds reasonnable in an urban environment), you will reject 50% of the HO ACCESS.
Not a bad solution, considering it is only 8am 🙂
pix6th October 2010 at 06:18 #64425pixGuest
“you will reject 50% of the HO ACCESS” , i am talking about ho access from MS doing incoming HO to n2.
… and more generally, all “ghost” ho access that are heard on bcch(n1)/bsic(n1).7th October 2010 at 08:03 #64426JZGuest
Actually excellent solution regardless of time od day :).