- OpenBSC - lists.osmocom.org

WG: patches again
by Andreas.Eversberg 29 Jun '09

29 Jun '09

> I don't use mISDN on Linux (I use Cygwin on Windows with my custom driver). However I had to adjust my custom driver to see the measurement reports in bsc_hack. The reason is that the measurement reports are sent as LAPD UI-Frames and not as LAPD I-Frames and I did not yet take care of UI-Frames. Maybe there is a similar problem with mISDN and UI-Frames. hi dieter, this is indeed a good thing to check. i can enable frame debugging on hfc-e1, so i can see every frame in hex. also i can sniff frames using an mISDN userland tool. with that i can see if there are any frames. if so i will check why the driver does not report UI frames in this case, and fix it.. regards, andreas

1 0

Re: patches again
by Holger Freyther 29 Jun '09

29 Jun '09

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote: > patch 38: still i use this little hacked install patch to install > library and include files, so other applications like LCR can use > openbsc without refering to the openbsc source directory. i use that > install-hook, because i don't know much about autoconf. maybe there is a > better way to do that. There is. Currently all the libraries are noinst libraries.. I did sent a patch to the mailinglist you could attempt to extent and make ready? z.

1 0

MSC split out progress
by Holger Freyther 29 Jun '09

29 Jun '09

Hey, just a small head up. I rebased the holger/msc branch and also moved the mncc bits into the libmsc. I'm currently in Essen and should be able to test these patches tomorrow. One thing that keeps me from pushing (after having tested) is the following observation. For going from layer3 to layer4 we currently have a queue, for my patches when going from layer2 to layer3 I have a direct callback. Should I change that to use the same queuing approach? holger

1 0

move tall_bsc_ctx WAS: Re: patches again
by Holger Freyther 29 Jun '09

29 Jun '09

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote: > patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not > to include file. seems sensible.

1 0

abnormal channel release WAS: Re: patches again
by Holger Freyther 29 Jun '09

29 Jun '09

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote: > patch 40: in case of a channel breakdown, the signal handler for > releasing lchan is called. the wrong pointer was used as lchan. (see > last hunk) also we don't need to check use counter of lchan, if we > receive an "cause 22 error". the lchan gets released anyway, if use > counter becomes 0. (see first hunk). also i think we can force channel > release when we receive an error indication. this can easily be tested: > remove the battery during active call, then send a message to the mobile > station (hang up on the remote). the message cannot be delivered, so the > BTS send us an error indication, the channels and the call process gets > released. Okay. As stupid as it might sound please split that into three patches. 1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for making you suffer from it and thanks for fixing it. 2.) static int rsl_rx_rll_err_ind(struct msgb *msg) 3.) Explain why +// if (msg->lchan->use_count > 0) { +// } is a good change and should be applied? thanks

1 0

Re: patches again
by Dieter Spaar 29 Jun '09

29 Jun '09

Hello Harald, On Sun, 28 Jun 2009 23:23:01 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > However, since Dieter has been seeing the measurement reports, I would hope he > is able to verify wether it works for him with the current git version of > OpenBSC, or what kind of changes he needs to make it work. Sorry :( I tested it with the git version from yesterday. The TRX0 is configured properly, I can see that the attributes are set as they should. I can also see the measurement reports in my custom traces (I set NM_ATT_BS11_RADIO_MEAS_GRAN to 0x05). I don't use mISDN on Linux (I use Cygwin on Windows with my custom driver). However I had to adjust my custom driver to see the measurement reports in bsc_hack. The reason is that the measurement reports are sent as LAPD UI-Frames and not as LAPD I-Frames and I did not yet take care of UI-Frames. Maybe there is a similar problem with mISDN and UI-Frames. One other thing is that decoding the measurement report might not yet work properly, bsc_hack says that the reports are invalid but for the MA10 Analyzer they are fine. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

MSC split out progress
by Holger Hans Peter Freyther 29 Jun '09

29 Jun '09

Hey, just a small head up. I rebased the holger/msc branch and also moved the mncc bits into the libmsc. I'm currently in Essen and should be able to test these patches tomorrow. One thing that keeps me from pushing (after having tested) is the following observation. For going from layer3 to layer4 we currently have a queue, for my patches when going from layer2 to layer3 I have a direct callback. Should I change that to use the same queuing approach? holger

1 0

Re: AW: AW: BS/MS power summary
by Dieter Spaar 26 Jun '09

26 Jun '09

Hello Andreas, On Fri, 26 Jun 2009 10:38:54 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > i tested the suggested values: > > > NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05, > > NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01, > > no measurement reports during calls, never seen one before. maybe i have > the wrong firmware load? i also get errors after starting bsc-hack on > the lmt. i will try to load a different firmware this weekend. This is what I use: Safety Load: HS010876.SWL SW Load: HS011106.SWL Just one other thing, I am watching the measurement reports in custom E1 traces. I guess this should not care and bsc_hack will show them too. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Some initial investigation on GPRS support
by Harald Welte 26 Jun '09

26 Jun '09

Hi! I've started to analyze GPRS and was actually even starting to write some code for it, but then have given up for the time being - it's much more work than anticipated. Given the long todo list of OpenBSC right now, I think I'll have put aside GPRS for some time :( Based on looking at protocol traces, I have figured out the nanoBTS GPRS/EDGE implementation roughly looks as follows: * make sure we allow the BTS to activate the GPRS software components in abis_nm / OML activation! * BTS will use a UDP connection on port 23000 for the GPRS related frames. The GSM specs will consider this type of connection between the PCU (part of the nanoBTS) and the SGSN. The establishment/configuration of the UDP port number and SGSN ip address has not yet been identified. Probably similar to how the RSL link is activated via OML. The protocol stack looks like: IP : UDP : NSIP : BSSGP : LLC : higher-layer IP and UDP you should know and/or not care about ;) NSIP is a IP-enabled version of NS as specified in TS 08.16 BSSGP is specified in TS 08.18 LLC is as specified in TS 04.64 the higher-layer depends on the SAPI value of the LLC and can be * GMM (GPRS Mobility Management as specified in 04.08) * User Data (actual IP packets, e.g.) * SMS So what is weird about this is that the GPRS MM is actually part of 04.08, but it is not terminated at the BSC but rather at the SGSN. Also, the deep stack comprised of many headers is really weird. Furthermore, it seems that a lot of the packet scheduling and timeslot allocation is happening inside the nanoBTS - very unlike the GSM side of things. I have not yet managed to figure out how to allocate/dedicate resources to GPRS.. after all, the BTS needs to know how many timeslots it can use for it, etc. If anyone wants to dig deeper, you're most welcome to do so. A list of relevant specs: 01.61 GPRS cipher algorithm requirements 03.60 Overall GRPS logical architecture (above RL and MAC) 03.64 GPRS radio interface 04.60 RLC/MAC on PDCH 04.64 MS-SGSN LLC spec (on top of RLC/MAC) 04.65 SGSN SNDCP 08.14 BSS SGSN Gb Layer 1 08.16 BSS SGSN Gb Layer 2 08.18 BSS SGSN BSS GPRS protocol 09.95 Interworking between modified PLMN supporting legacy GPRS and GPRS mobiles 22.060 GPRS Service Spec 23.060 GPRS Radio Service Spec 29.016 SGSN - VLR Interface Gs network interface spec 29.018 SGSN - VLR Interface Gs layer3 interface spec 29.060 GPRS Tunneling (GTP) over Gn and Gp Happy hacking, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

AW: AW: BS/MS power summary
by Andreas.Eversberg 26 Jun '09

26 Jun '09

hi, i tested the suggested values: > NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05, > NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01, no measurement reports during calls, never seen one before. maybe i have the wrong firmware load? i also get errors after starting bsc-hack on the lmt. i will try to load a different firmware this weekend. regards, andreas

1 0