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
The OpenBSC(a)lists.osmocom.org mailing list has 2 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
The OpenBSC(a)lists.osmocom.org mailing list has 2 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
The OpenBSC(a)lists.osmocom.org mailing list has 2 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
The OpenBSC(a)lists.osmocom.org mailing list has 2 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 Hans Peter Freyther <holger(a)moiji-mobile.com>
The DSP/FPGA appears to report bogus PhDataInd with hlayer2 == 0.
Currently this would match the TRX==0,TS==0 and SS=0 and then we
report bad measurement reports. Add a magic number to the lower
eight bit of the hLayer2 to differentiate valid numbers.
Addresses:
<0004> measurement.c:97 (bts=0,trx=0,ts=0,ss=0) measurement during state: NONE
<0004> measurement.c:102 (bts=0,trx=0,ts=0,ss=0) no space for uplink measurement
---
src/osmo-bts-sysmo/oml.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/osmo-bts-sysmo/oml.c b/src/osmo-bts-sysmo/oml.c
index 596680f..7fcd4c6 100644
--- a/src/osmo-bts-sysmo/oml.c
+++ b/src/osmo-bts-sysmo/oml.c
@@ -704,17 +704,24 @@ err:
uint32_t l1if_lchan_to_hLayer(struct gsm_lchan *lchan)
{
- return (lchan->nr << 8) | (lchan->ts->nr << 16) | (lchan->ts->trx->nr << 24);
+ return 0xBB
+ | (lchan->nr << 8)
+ | (lchan->ts->nr << 16)
+ | (lchan->ts->trx->nr << 24);
}
/* obtain a ptr to the lapdm_channel for a given hLayer */
struct gsm_lchan *
l1if_hLayer_to_lchan(struct gsm_bts_trx *trx, uint32_t hLayer2)
{
+ uint8_t magic = hLayer2 & 0xff;
uint8_t ts_nr = (hLayer2 >> 16) & 0xff;
uint8_t lchan_nr = (hLayer2 >> 8)& 0xff;
struct gsm_bts_trx_ts *ts;
+ if (magic != 0xBB)
+ return NULL;
+
/* FIXME: if we actually run on the BTS, the 32bit field is large
* enough to simply put a pointer inside. */
if (ts_nr >= ARRAY_SIZE(trx->ts))
--
1.9.0