OpenBSC June 2009

openbsc@lists.osmocom.org

17 participants
103 discussions

Re: Some notes about BS-11 clock calibration

by Dieter Spaar

Hello Harald, On Mon, 8 Jun 2009 16:28:54 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > The various clock related issues that people have been describing already gave > me a lot of headache. With the method you described in your mail we now have a > documented way how to make sure the BS-11 runs on the 'right' frequency. Thank you, I hope that together with the description and tool from Andreas it will help to solve any issues related to the BS-11 clock. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

16 years, 2 months

AW: isdnsync

by Andreas.Eversberg

the "g" is missing. maybe i lost the "g" while copying. i prefer OpenBSC svn because the tool is currently usefull for OpenBSC only. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Montag, 8. Juni 2009 11:56 An: openbsc(a)lists.gnumonks.org Betreff: Re: isdnsync Cool, two small questions. Do you mind if I add a "g" to your name in the isdnsync.c, or did I always misspell your name? The second one is if the OpenBSC svn is to be preferred over misdn-utils? z.

16 years, 2 months

Re: Trying to understanding the source

by Nordin

Hi guys, I'm a bit ashamed to ask, but I'll ask anyway, could someone help me explaining the OpenBSC source? make_sock(): I didn't know it's possible to call select() on a read signal to finally call the accept() for the socket_fd. Logically seen, socket_fd receives something (in this case a new connection), so it works. I just thought select() is only used for reading/writing data (or an except) on file descriptors. Why is OpenBSC written to work synchronously and not multihtreaded? If somewhere in the chain hangs (by a bug), telnet for example won't respond, right? What is the idea behind this concept? Is it a popular concept in the Linux world (so I can be familiar with)? Which other functions does timer.c has besides returning a timevalue for the select() call (nearest_timer) time-out. I mean what more other purposes has timer.c Cause I don't really understand why timer_values also be put in a doubly linked list... That's all for now, I might ask some more questions, but after some studying :s Thank you. P.S: I do have experience in C/C++ programming....in Bill Gates environment. I know.....I'm sorry.

16 years, 2 months

(no subject)

by Andreas.Eversberg

hi, this small tool is used to enable layer 1 and 2 on a given isdn card. the card can be used to retrieve clock signal from a network. layer 2 (PTP) is required to keep layer 1 without interruption. this tool works on e1 and s0 cards. to use the clock signal with other cards, interconnection with a clock-slave-card is required. this tool is GPL v2. the import to the subversion server on bs11-abis.gnumonks.org is welcome. a documentation with card interconnection howto does not exist, but if someone really successfully connects two cards (HFC-S PCI and HFC-E1), we can write one from these experiences. regards, andreas

16 years, 2 months

Some notes about BS-11 clock calibration

by Dieter Spaar

Hello, I did a few tests with the BS-11 clock. I wanted to find out how accurate the clock of the BS-11 is and how the calibration value influences the clock. This is only about one BS-11, but I guess the others are similar. To control the BS-11 clock I used a slightly modified HFC-E1 card, instead of the 32.768 MHz oscillator of the card an external signal from an accurate and stable clock source is used. The BS-11 "PLL Mode" is set to "Locked" so that it locks to the E1 clock. I am observing the PLL "Work Value" which is the actual value used by the PLL. I also measured the RF frequency of the BS-11. HFC-E1 clock is 32.768 MHz: PLL Work Value is 1024 HFC-E1 clock is 32.768 MHz + 0.1 ppm: PLL Work Value is 941 HFC-E1 clock is 32.768 MHz - 0.1 ppm: PLL Work Value is 1116 So a lower PLL calibration value means a higher frequency. Another observation is that the actual RF frequency is following the E1 clock slowly. For example if the E1 clock is changed by 0.1 ppm, the RF frequency is slowly changing until after several minutes it has also changed by 0.1 ppm. The PLL "Working Value" is following even slower, it takes nearly an hour until is has settled to a stable value. The clock of the BS-11 is very stable, if set to "Stand Alone" the RF frequency is not changing very much, its much less than the required 0.05 ppm from the GSM specification for a BTS. Another interesting thing is that the factory PLL calibration of this BS-11 is 1016, very close to 1024 of the measured value. What does that all mean ? If you want to calibrate the clock of your BS-11 by using a HFC-E1 card which is synchronized from a stable and accurate clock (Andreas explained how this can be done with a second ISDN card) I would recommend to do the following: - let the BS-11 warm up for at least one hour - set the "PLL Mode" to "Locked" with bs11_config - start bsc_hack and let it run for an hour so that the PLL can adjust to the E1 clock and the PLL "Work Value" settles (you can use bs11_config to watch the value). - set the "PLL Mode" to "Stand Alone" with bs11_config, this makes sure that the PLL "Work Value" will no longer change and is used next time, even if the HFC-E1 clock is no longer synchronized. The BS-11 oscillator should be stable enough so that there is no need for continuous synchronisation with an external reference. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

16 years, 2 months

[PATCH 0/3] Updated Channel Allocation Code

by Holger Freyther

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(-)

16 years, 2 months

Re: WG: patch 12 14, 15, 16

by Dieter Spaar

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

16 years, 2 months

WG: patch 12 14, 15, 16

by Andreas.Eversberg

-----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

16 years, 2 months

AW: [PATCH 3/3] lchan: Handle the abnormal case of channel getting closed

by Andreas.Eversberg

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

16 years, 2 months

AW: patch 24: output

by Andreas.Eversberg

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?

16 years, 2 months

← Newer
1
...
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2009