<div dir="ltr">Hi holger, <br><div class="gmail_quote"><div dir="ltr"><div><br><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

What is a network-initiated Location Area Update? Do you talk about<br>
the NITB/BSC advertizing periodic updating?</blockquote><div><br></div></div><div>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 <span style="color:rgb(51,51,51);font-family:Trebuchet,'Trebuchet MS',Arial,sans-serif;font-size:13px;line-height:16.71875px">location update request signal (what I meant is that the T3212 timer is provided to the MS by the network).</span></div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
> I find this behavior annoying mostly in scenarios where the T3212 (LAU<br>
> timer) has been setup to a low value.<br>
<br>
</div>About which software and which versions do you talk?</blockquote><div><br></div></div><div>mmm, I didn't quite get your question here. </div><div><br></div><div>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.</div>
<div><br></div><div>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).<br>
</div>
<div><br></div><div>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.</div>
<span class=""><font color="#888888">
</font></span></div><span class=""><font color="#888888"><br></font></span></div></div><span class=""><font color="#888888"><div class="gmail_extra">luca</div></font></span></div>
</div><br></div>