RE: Location Area Updates missed during calls

Not exactly your issue, and mainly a testbed situation, nothing for the real world, but at least with OpenBTS I ran into similar issues when I stopped for some reason the BTS and restarted it immediately without keeping the TMSI assignment list. In this case the mobiles were not yet on extensive network search, so no registration attempts on other networks, registration flag still valid in the ME, no expired T3212. This leads to strange effects with GPRS and with incoming calls and short messages. I can imagine it may be similar with the openbsc family of BTSs. But as I have said, more an academic issue in lab tests, a real BTS runs all the time and is not restarted every few minutes :) Under what circumstances does the network initiate a LU procedure? Up to now I was not aware of this possibility. Ralph. From: openbsc-bounces(a)lists.osmocom.org [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of Luca Valtulina Sent: Thursday, March 20, 2014 2:40 PM To: openbsc(a)lists.osmocom.org Subject: Location Area Updates missed during calls Hi list, when a MS is in a call it misses the network-initiated Location Area Update procedure(s). This inconvenience can lead (if the call ends after the expire_lu time) to having an attached (and active) subscriber marked as expired in the HLR. Furthermore if at this point the MS initiates a new call, the call will be dropped and (as expected) a new Location Area Update procedure will be initiated by the BSC. I find this behavior annoying mostly in scenarios where the T3212 (LAU timer) has been setup to a low value. To tackle this issue I thought of triggering a subscriber update when a call get released (either by the network or by the MS) for each of the MS involved in the call. The code can also be optimized by checking whether the subscriber is expired before performing the update. I can provide a patch if you also consider the above as a misbehavior of OpenBSC. cheers luca