- This topic is empty.
18th October 2011 at 18:49 #67384manojGuest
I’m facing problem on half of the SDCCH assignments are failed due to T3101 timer expiry though it is set to 8sec.
We i went on trace i came to know there is a huge delay on IMM assignment command sent from BSC to MS around 1000ms.
hence it is satellite link again delay of 500ms will be added, so it comes around 1.5sec on IMM assignment .
Since this is the delay, I could see more no. of RACH REQ received between IMM assignment and previous RACH. this also leading to high RACH req(600/hr).
So my request, is there any way i can reduce these T3101 expiry on the network.
here are some current informations:
RACH retransmit is 2
no. of slots for retransmit is 32
AGCH is 2
t3101 is 8000ms
Main BCCH in TS0, SDCCH8 in TS1
any help is highly appreciated..
Thanks in advance.19th October 2011 at 13:05 #67385pixGuest
abis or ater over satellite will always lead to this situation. The problem is that the MS sends 2 RACH req, because it didn’t receive an answer soon enough (either an accept or a reject)
the 1st rach will get the IMM
the second RACH will also get a IMM but this IMM won’t be “ack” by the MS -> it is this second RACH which is seen as a failure !
what you can try to do is set
RACH retransmit = 0
that should solve your KPI’s issues. but but but… users might experience more “call setup failures”, which won’t be counted in the KPI’s. The 1st RACH request is not received by the BTS (let’s say a noise or a collision with another RACH) – the MS will NOT repeat this RACH. Therefore, the user experiences a failure. But from BSS side, no indicator is incremented.
pix21st October 2011 at 12:42 #67386manojGuest
I have forwarded this to the backhaul
team regarding high latency in the link.
however in our system we can’t set RACH retransmission to ‘0’, by default atleast it should be ‘1’
Any idea on what would be the MS rollback time for second RACH request, if it is 32 in numbers of slots used to spread transmission.21st October 2011 at 14:47 #67387pixGuest
manoj, it would be too short anyway, compared to the link latency.
Don’t worry about this, countless radio optimizers have worked on this *fake* problem over the past 20 years. There is no solution.
It is *not* a problem. The KPI is higher than it should, but it doesn’t impact customers at all… so why bother? Go investigate a *real* problem 😉