- This topic has 10 replies, 1 voice, and was last updated 14 years, 2 months ago by
.
-
Posts
-
Hi,
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!
hello,
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 ?
regards
pixBasically 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).Hello Olivier,
Great details, thanks ! There is one inconsistency in your post, so let’s clarify:
with mainBCCH:
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 ?
with combinedBCCH:
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.
Regards
PixWhen 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?
Hi Olivier,
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.
Regards,
FedericoWe 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”.
olivier,
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.
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.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.How can i latch a ms to a particular bts only?
- The forum ‘Telecom Design’ is closed to new topics and replies.
