The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
Indeed the problem has been already solved in the master branch by adding
the "expire_timer_stopped" attributes to a gsm_subscriber_connection and
then checking it upon expiration of the expire_lu timer for an active
subscriber.
Sorry to have re-raised the issue.
luca
Hi 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
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
Hi Holger,
On Sun, Mar 16, 2014 at 1:55 PM, Holger Hans Peter Freyther
<holger(a)freyther.de> wrote:
> E.g. in one
> of the testcases I noticed that you don't use C99 initializers but the
> old/error prone way of initializing. :)
Yes, I think in this particular case the old way is more compact and
thus more readable.
I added C99 initializers to the test (see the patch attached or
achemeris/sms-fixes branch) and to me it looks less readable and thus
more error prone. If you see any benefits of this patch - feel free to
merge it, though.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co