OpenBSC

openbsc@lists.osmocom.org

13 participants
4246 discussions

[PATCH 0/3] Updated Channel Allocation Code
by Holger Freyther 06 Jun '09

06 Jun '09

Hey, I posted some of these patches some time ago and started to rebase them now. The main idea is to make the "paging" layer more internal and only request to open a channel (of a specific type) to a certain subscriber. The internal handling would find the right bts in the lac ("new" requirement and not yet implemented), will make sure that we assign as many as possible channels to the subscriber but will not lose any request (act as a queue). I would like to merge the first two patches as I think they are moving in the right direction and are unlikely to break anything and plan to test the third patch later this week (if I get access to a BTS). So if you will see a regression in call handling, shout at me.. z. include/openbsc/gsm_data.h | 2 include/openbsc/gsm_subscriber.h | 9 ++ src/bsc_hack.c | 1 src/gsm_04_08.c | 6 - src/gsm_subscriber.c | 139 ++++++++++++++++++++++++++++++++++++++- 5 files changed, 153 insertions(+), 4 deletions(-)

1 3

Re: WG: patch 12 14, 15, 16
by Dieter Spaar 06 Jun '09

06 Jun '09

Hello Harald, On Sat, 6 Jun 2009 10:03:38 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > In other words: IMSI ATTACH/DETACH is only used in addition to regular Location > Update, and it is used in situations where a MS on a network with ATT=0 would > not perform any signalling with the network at all. I have read at some places that the idea of IMSI ATTACH/DETACH is to save resources of the network, if its is know that an MS is off (IMSI DETACH was sent) there is no need to allocate resources for paging the MS. IMSI ATTACH is the reverse, it tells the network that the phone is back again. Its up to the operator to use this feature. I am not sure if this is the real motivation, but it makes sense for me. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

WG: patch 12 14, 15, 16
by Andreas.Eversberg 06 Jun '09

06 Jun '09

-----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther >I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover, so >far the detach path was written in a way that even a sequence like: > new BTS ATTACHED > old BTS DETACHED hi holger, here is what happens: BTS(new LAC) ATTACH -> DB = new LAC BTS(old LAC) DETACH -> DB = 0 the mobile attaches to the new LAC, so the database stores the new LAC number. next, the mobile detaches from the old LAC and the database stores 0 for 'not attached'. the database now holds a wrong value. to solve this, we may only allow detach, if the mobile is not already attached to a different location area: if (DB == old LAC) then DB = 0 else ignore! so the mobile can only detach from a BTS with the location it is currently attached. i checked the code yesterday. i saw that the subscriber is associated to a LAC and a bts when attaching. when detaching, the association to the bts is removed, if not already attached to a different one. is this correct? as far as i know, the attached subscriber is associated to a LAC only. it may silently change the BTS without location update, if the MCC/MNC/LAC is equal on this BTS. when we page a mobile, we must do it on all BTS of that location area, as far as i know. (see patch 27) if the mobile requests a channel, it chooses one of the BTS. i think we must remove the "current_bts" pointer from the subscriber structure. andreas

3 5

AW: [PATCH 3/3] lchan: Handle the abnormal case of channel getting closed
by Andreas.Eversberg 05 Jun '09

05 Jun '09

ok, i understand now. the location update is a subinstance of lchan, so you "signal" an error to gsm_04_08.c to release all instances related to lchan. i will test that and modify the patch 27 (application) this weekend, so the signal handler also releases the transactions of that lchan ("transactions" will replace the "call" process). i must upgrade patch 27, because it depends on earlier patches. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Freitag, 5. Juni 2009 04:19 An: openbsc(a)lists.gnumonks.org Betreff: [PATCH 3/3] lchan: Handle the abnormal case of channel getting closed The abnormal case is that lchan_free ist getting called due a RSL_MT_CHAN_REL_ACK in the RSL but the refcount of this channel is not zero. This means that some "logical operation" is still going on that needs to be cancelled. Instead of always queuing up all operations in the struct lchan use the signal framework to inform higher layers about this abnormal case. In gsm_04_08.c a signal handler is installed and in the abnormal case the location updating request operation is freed. --- include/openbsc/signal.h | 10 ++++++++++ src/chan_alloc.c | 4 +++- src/gsm_04_08.c | 18 ++++++++++++++++++ 3 files changed, 31 insertions(+), 1 deletions(-) diff --git a/include/openbsc/signal.h b/include/openbsc/signal.h index c2cf46a..ca16296 100644 --- a/include/openbsc/signal.h +++ b/include/openbsc/signal.h @@ -37,6 +37,7 @@ enum signal_subsystems { SS_SMS, SS_ABISIP, SS_NM, + SS_LCHAN, }; /* SS_PAGING signals */ @@ -55,6 +56,15 @@ enum signal_nm { S_NM_FAIL_REP, /* GSM 12.21 failure event report */ }; +/* SS_LCHAN signals */ +enum signal_lchan { + /* + * The lchan got freed with refcount != 0 and error + * recovery needs to happen right now. + */ + S_LCHAN_UNEXPECTED_RELEASE, +}; + typedef int signal_cbfn(unsigned int subsys, unsigned int signal, void *handler_data, void *signal_data); diff --git a/src/chan_alloc.c b/src/chan_alloc.c index fa07273..77a4f57 100644 --- a/src/chan_alloc.c +++ b/src/chan_alloc.c @@ -31,6 +31,7 @@ #include <openbsc/abis_nm.h> #include <openbsc/abis_rsl.h> #include <openbsc/debug.h> +#include <openbsc/signal.h> static void auto_release_channel(void *_lchan); @@ -193,8 +194,9 @@ void lchan_free(struct gsm_lchan *lchan) lchan->subscr = 0; } - /* We might kill an active channel... FIXME: call cancellations */ + /* We might kill an active channel... */ if (lchan->use_count != 0) { + dispatch_signal(SS_LCHAN, S_LCHAN_UNEXPECTED_RELEASE, lchan); lchan->use_count = 0; } diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c index 18371b5..3dfa780 100644 --- a/src/gsm_04_08.c +++ b/src/gsm_04_08.c @@ -182,6 +182,24 @@ static void allocate_loc_updating_req(struct gsm_lchan *lchan) memset(lchan->loc_operation, 0, sizeof(*lchan->loc_operation)); } +static int gsm0408_handle_lchan_signal(unsigned int subsys, unsigned int signal, + void *handler_data, void *signal_data) +{ + if (subsys != SS_LCHAN || signal != S_LCHAN_UNEXPECTED_RELEASE) + return 0; + + /* give up on the loc_operation in case of error */ + struct gsm_lchan *lchan = (struct gsm_lchan *)handler_data; + release_loc_updating_req(lchan); + + return 0; +} + +static __attribute__((constructor)) void on_load_0408(void) +{ + register_signal_handler(SS_LCHAN, gsm0408_handle_lchan_signal, NULL); +} + static void to_bcd(u_int8_t *bcd, u_int16_t val) { bcd[2] = val % 10; -- 1.6.3.1

1 0

AW: patch 24: output
by Andreas.Eversberg 05 Jun '09

05 Jun '09

the two "empty" DEBUGPC do terminate the line ("\n"). never mind, if i find some more distorted debug output during test in the future, i will post them here. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Donnerstag, 4. Juni 2009 16:00 An: openbsc(a)lists.gnumonks.org Betreff: Re: patch 24: output On Wednesday 03 June 2009 09:41:13 Andreas.Eversberg wrote: > the reason for moving "subscr_get_by_tmsi" behind the "DEBUGPC" function is > to finish the debug line (using end-of-line) before calling the > "subscr_get_by_tmsi" function. the "subscr_get_by_tmsi" function may also > do debug output (currently uses printf). without changing it, the debug > gets distorted. Applied, I assume you agree that omitting the other two "empty" DEBUGPC is good enough as well?

1 0

[PATCH 0/3] lchan/location updating request robustnes
by Holger Freyther 05 Jun '09

05 Jun '09

Hey, in patch22 Andreas pointed out that we might have unbalanced ref count in the location updating request path(s) and these patches try to fix some possible reliable issues, handle spoofing to a certain degree and recover from error (abnormal channel close). include/openbsc/signal.h | 10 ++++++++++ src/chan_alloc.c | 4 +++- src/gsm_04_08.c | 32 ++++++++++++++++++++++++-------- 3 files changed, 37 insertions(+), 9 deletions(-)

1 3

AW: WG: patch 12 14, 15, 16
by Andreas.Eversberg 04 Jun '09

04 Jun '09

>> is this correct? as far as i know, the attached subscriber is associated to >> a LAC only. it may silently change the BTS without location update, > >You are right. It is wrong. I assumed that BTS <-> LAC map 1:1 but that is not >the case. Could you prepare a change to gsm_subscriber to store the LAC + CELL >ID and remove the struct gsm_bts pointer or would you be willing to test one? >Maybe even carry out the change in the db.c to store/restore the that >information (e.g. check my "VLR" patches as this is what we are building). i can test this. i will remove bts pointer and only check lac when detaching. when paging, i will loop all bts and add a paging request to all bts with that pointer. if the paging responds, we receive the lchan and then stop paging requests to other bts' (if any). if we receive resonse, we ignore them, if we already received an lchan. (error case when two mobiles share same imsi or other error cases). what about the "VLR" patch? where is it? why do you need a VLR? (HLR??) >For the future we would have something like this: > 1.) Call +123323 > 2.) Find the gsm_subscriber and load it from the db > 3.) Check the VLR where we currently think it is > struct gsm_bts* bts = bts_resolve(subscr->lac, subscr->cell_id); > and then page... > >z. check out the patch 27 (application). there is a loop when start paging. it already loops all bts with the LAC. there is an error in that: the current_bts pointer is changed for every paging request. this would be removed, if the bts pointer is removed. also the stopping of parallel paging requests (same subscriber, different bts) is not realized. if you aggree with that, i will implement it this weekend.

2 2

AW: patch 24: output
by Andreas.Eversberg 04 Jun '09

04 Jun '09

the reason for moving "subscr_get_by_tmsi" behind the "DEBUGPC" function is to finish the debug line (using end-of-line) before calling the "subscr_get_by_tmsi" function. the "subscr_get_by_tmsi" function may also do debug output (currently uses printf). without changing it, the debug gets distorted. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c index d585aae..9a2a00a 100644 --- a/src/gsm_04_08.c +++ b/src/gsm_04_08.c @@ -797,9 +797,9 @@ static int gsm48_rx_mm_serv_req(struct msgb *msg) } mi_to_string(mi_string, sizeof(mi_string), mi, mi_len); - subscr = subscr_get_by_tmsi(mi_string); DEBUGPC(DMM, "serv_type=0x%02x mi_type=0x%02x M(%s)\n", req->cm_service_type, mi_type, mi_string); + subscr = subscr_get_by_tmsi(mi_string); /* FIXME: if we don't know the TMSI, inquire abit IMSI and allocate new TMSI */ if (!subscr) @@ -831,9 +831,11 @@ static int gsm48_rx_mm_imsi_detach_ind(struct msgb *msg) switch (mi_type) { case GSM_MI_TYPE_TMSI: + DEBUGPC(DMM, "\n"); subscr = subscr_get_by_tmsi(mi_string); break; case GSM_MI_TYPE_IMSI: + DEBUGPC(DMM, "\n"); subscr = subscr_get_by_imsi(mi_string); break; case GSM_MI_TYPE_IMEI:

2 1

Some very handy telecom call flow pdfs
by Nordin 04 Jun '09

04 Jun '09

I found some good call-flow schematics according to GSM protocol with some explanation included. Check out this link: http://www.eventhelix.com/RealtimeMantra/Telecom/ It has some valuable and clear information how parts of GSM work. I hope you like it, at least I do :)

1 0

Re: Possible to control the radio strength of a nanoBTS?
by Dieter Spaar 04 Jun '09

04 Jun '09

Hello Harald, On Wed, 3 Jun 2009 23:24:50 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > The BS-11 has 3W max output. I think we have 2 Watt maximum, 3 Watt is the maximum for the 1800/1900 variant of the BS-11. > That's quite obvious if you understand the details of the cell selection > algorithm. If you've been registered to an actual cell of the operator > before, then that ARFCN/LAC is stored on the SIM card even when you shut > off the phone. Let me add a few more detail (I sent this to the list a while ago). There are two EFs (Elementary Files) on the SIM which contain this information: - EF_BCCH contains the cell allocation information from "SYSTEM INFORMATION 2". - EF_LOCI contains the TMSI, Location Update Timer, LAI and the status of the location update. If those EFs are set to the correct values used by the test cell, the phone will immediately look for the test cell when powered on and also consider to be "registered" if no "IMSI Attach" is required. > So yes, typically the translation of mcc/mnc happens in a table on the SIM > card, and if that fails in a table that is included at compile time into the > GSM firmware of the handset. It seems that the mapping of MCC/MNC to names on the SIM was introduced with GSM 31.102 (USIM for UMTS), GSM 11.11 did not have it. So it depends on the SIM if it has this mapping. I looked at some phone firmware, in this special case the mapping is done by looking at the SIM first (if it is an USIM), than at an optional table in the phone filesystem and finally at the table in the firmware. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC