This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Luca Valtulina valtulina.luca at gmail.comHi holger, What is a network-initiated Location Area Update? Do you talk about > the NITB/BSC advertizing periodic updating? With Location Area Update I refer to the Location Update procedure (I made confusion with the UMTS protocol where "Area" has been added in-between). I also have to apologies about that "network-initiated" which is clearly wrong since is the MS which triggers the procedure by sending a location update request signal (what I meant is that the T3212 timer is provided to the MS by the network). > > I find this behavior annoying mostly in scenarios where the T3212 (LAU > > timer) has been setup to a low value. > > About which software and which versions do you talk? mmm, I didn't quite get your question here. After performing further testing I can wrap up the issue as following: when a MS ends a call after the expire_lu time, it will be considered expired in the HLR (because two LUs were missed by the network). When the (now expired) MS initiates a call, the CM service will be rejected by the network with cause 4 (GSM48_REJECT_IMSI_UNKNOWN_IN_VLR). Needless to say that when a different MS tries to establish a call towards the (now expired) MS, this call will also be dropped because the destination MS is (seen as) detached from the BTS. Now I think that if we want to have a more precise location management, a lower expiration interval is a possibilities: this can be achieved by either lowering down the t3212 value and keeping the same expire_lu calculation (2 times t3212 + 1 minute) or by modifying the expire_lu calculation. In this scenarios the issue described above is more likely to happen (higher probability of having ~10 minutes calls than > 60 minutes). So indeed, is this behavior expected by the GSM protocol? I think that update the HLR whenever an MS exits a call will be a costless procedure which can avoid the annoyance of having the first next call dropped if this happens prior to the triggering of the LU by the interested MS. luca -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140321/0873a33d/attachment.htm>