- This topic has 10 replies, 1 voice, and was last updated 11 years, 1 month ago by chan.
10th October 2008 at 08:22 #54113OlivierGuest
I’ve observed a clear difference in how long mobiles will wait for a location update procedure to complete before they give up depending on the channel combinations of the BTS.
Basically, it seems like when using SDCCH/8, mobiles wait only 10 seconds for the LU procedure to complete before giving up, while when using bcchCombined, they wait 20 seconds.
Does anybody know why this is, and if so where in the GSM specs I could find a reference to this behaviour?
Many thanks!12th October 2008 at 17:50 #54114pixGuest
in 3GPP 24.008, it states that the MS shall wait for a response from the network (accept or reject) during T3210 (20s). If it is not received, then a second timer is triggered (T3211) for 15s.
At expiry, the Ms will restart a new location update.
The summary is at chapter “Timers for mobility management”.
What you’re saying is different though. It’s strange that the facto to be on SDCCH/8 or SDCCH/4 would change anything. The preiodicity of the SACCH is still the same (about 471ms), so that should not impact the radio link timeout.
When you do a trace with your drivetest tool, what are the layer 3 messages exchanged ?
pix13th October 2008 at 08:48 #54115Olivier DemeGuest
Basically when using mainBCCH, we see that the uplink RXLEV within the measurement reports coming from the BTS drop to 0 after 10 seconds after reception of the location update request (no reply sent from the MSC).
While when using bcchCombined, we see that the measurement reports are fine and then after 20 seconds we see a release indication for sapi 0, indicating that the MS has explicitely released layer 2.
This behaviour has been observed with all or handsets.
(We are currently testing the particular behaviour whereby the mobile doesn’t get an answer for a LU request).13th October 2008 at 10:23 #54116pixGuest
Great details, thanks ! There is one inconsistency in your post, so let’s clarify:
What is the reason of the drop ? You are saying the BTS doesn’t send measurement report anymore… but the BTS never sent measurement reports, ever. Those meas reports are UL messages, sent by the MS to the BTS.
Do you mean the MS does not receive the DL SACCH blocks, therefore its Radio Link Timeout reaches 0, provoking a radio drop ? The MS does not send any message to the BTS, prior to the drop ?
the release indication is sent BY the MS ? that looks like this is the correct behaviour: at expiry of T3210, the connection is released.
So the problem is with the mainBCCH, you got to find the reason of the drop… If the BTS does not send DL SACCH anymore, it’s not normal at all. I can’t imagine why the BTS would not send those SACCH… but you can verify this on layer 3. You can also check the value of the Radio Link Counter “S”, it should appear in the drivetest as well.
Pix13th October 2008 at 11:46 #54117OlivierGuest
When a radio channel is allocated to a mobile, the BTS reports the signal quality seen by the mobile by transmitting periodically 08.58 measurement results.
If using mainBcch, when a mobile initiates a location update but doesn’t get an accept/reject from the network, after 10 seconds we see that the RXLEV-FULL-up and RXLEV-SUB-up contained in the 08.58 measurement results drop to 0, indicating that the mobile is not transmitting any 04.08 measurement reports anymore.
In other words, the mobile is not even listening on that radio channel after these 10 seconds. The mobile didn’t release sapi 0 as we would expect.
This behaviour has been seen consistently with different mobile manufacturers.
Similarly, consistently if we use bcchCombined, we see that the mobile gives up only after 20 seconds and that it cleanly releases SAPI 0 when it does so.
Maybe this behaviour is linked to the BTS model?13th October 2008 at 12:18 #54118fedemGuest
do you see a Connection Failure Indication coming from BTS to BSC (if this message is present in your proprietary Abis interface) ?
In this case you can see a “cause” of the aborted connection.
Federico13th October 2008 at 13:43 #54119OlivierGuest
We see a connection failure only if we try to send something to the mobile after these 10 seconds. The cause value is “radio link failure”.13th October 2008 at 18:22 #54120pixGuest
Thanks for the clarifications, now I understand 🙂
You have to perform a Air interface trace (drivetest) in order to see what is the MS doing. Does it still receive SACCH blocks from the BTS or not ?
What’s the value of the “S” counter ?
This can’t be seen on Abis interface.
If the BTS doesn’t send measurement results, it probably means it doesn’t receive measurement reports from the MS… but it’s weird that ALL ms have a faulty behaviour.14th October 2008 at 15:57 #54121OlivierGuest
Unfortunately, I don’t have the right equipment to debug the air interface right now.
I may be able to get access to such equipment at some stage.
Thanks for your help.12th August 2010 at 07:32 #54122beeyaarGuest
I am working with BSS. I have iwo issues in my network.
1. while making a call MS showing network busy
2. Sometimes MS not latching to network.21st October 2010 at 07:17 #54123chanGuest
How can i latch a ms to a particular bts only?