OpenBSC

openbsc@lists.osmocom.org

16 participants
4280 discussions

Fwd: Location Area Updates missed during calls
by Luca Valtulina 21 Mar '14

21 Mar '14

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

1 0

3 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 21 Mar '14

21 Mar '14

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

1 0

[PATCH] sms_test: Use C99 initializers.
by Alexander Chemeris 21 Mar '14

21 Mar '14

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

2 1

[PATCH 1/2 openggsn] gtp: fix wrong binary layout for struct gtp0_header in x86_64
by pablo＠gnumonks.org 21 Mar '14

21 Mar '14

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> struct gtp0_header needs __attribute__((packed)) to make sure that gcc doesn't add a hole of 4 bytes to align the 64-bits teid, resulting in 24 bytes instead of 20 bytes. This was breaking gtpv0 in my gprs testbed with my x86_64 laptop. While at it, add also attribute packed to other headers just to make sure that gcc doesn't pad the structures with holes. --- If no objections, I'll push this to master. gtp/gtp.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gtp/gtp.h b/gtp/gtp.h index 54af96e..39a902f 100644 --- a/gtp/gtp.h +++ b/gtp/gtp.h @@ -161,7 +161,7 @@ struct gtp0_header { /* Descriptions from 3GPP 09.60 */ uint8_t spare2; /* 11 Spare */ uint8_t spare3; /* 12 Spare */ uint64_t tid; /* 13 Tunnel ID */ -}; /* 20 */ +} __attribute__((packed)); /* 20 */ struct gtp1_header_short { /* Descriptions from 3GPP 29060 */ uint8_t flags; /* 01 bitfield, with typical values */ @@ -174,7 +174,7 @@ struct gtp1_header_short { /* Descriptions from 3GPP 29060 */ uint8_t type; /* 02 Message type. T-PDU = 0xff */ uint16_t length; /* 03 Length (of IP packet or signalling) */ uint32_t tei; /* 05 - 08 Tunnel Endpoint ID */ -}; +} __attribute__((packed)); struct gtp1_header_long { /* Descriptions from 3GPP 29060 */ uint8_t flags; /* 01 bitfield, with typical values */ @@ -190,7 +190,7 @@ struct gtp1_header_long { /* Descriptions from 3GPP 29060 */ uint16_t seq; /* 10 Sequence Number */ uint8_t npdu; /* 11 N-PDU Number */ uint8_t next; /* 12 Next extension header type. Empty = 0 */ -}; +} __attribute__((packed)); struct gtp0_packet { struct gtp0_header h; -- 1.7.10.4

3 4

Location Area Updates missed during calls
by Luca Valtulina 21 Mar '14

21 Mar '14

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

3 2

2 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 20 Mar '14

20 Mar '14

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

1 0

2 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 19 Mar '14

19 Mar '14

1 0

2 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 18 Mar '14

18 Mar '14

1 0

2 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 17 Mar '14

17 Mar '14

1 0

[PATCH] sysmobts: Add a magic number to the hLayer2 to differentiate it
by Holger Hans Peter Freyther 17 Mar '14

17 Mar '14

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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC