OpenBSC

openbsc@lists.osmocom.org

14 participants
4198 discussions

Re: Re: GPRS branch status updates
by Dieter Spaar 03 Nov '09

03 Nov '09

Hello Sylvain, On Tue, 03 Nov 2009 07:03:15 +0000, 246tnt(a)gmail.com wrote: > > Initially I had a segfault when receiving a GMM ATTACH. The MCC/MNC in the > CELL ID transmitted in the GMM ATTACH REQUEST are not the one I set in > openbsc.cfg, they seem hardcoded to 001/01 but I haven't found from where > yet. So currently you need to set 1/1 in your openbsc.cfg as well. Its in bsc_init.c, the variable "nanobts_attr_bts": NM_ATT_IPACC_CGI, 0, 7, 0x00, 0xf1, 0x10, 0x00, 0x01, 0x00, 0x00, I did modify patch_nm_tables() and added: // this overwrites nanobts_attr_bts[54], but we set it later anyway gsm48_ra_id_by_bts(&nanobts_attr_bts[49], bts); nanobts_attr_bts[54] = htons(bts->cell_identity) & 0xFF; nanobts_attr_bts[55] = (htons(bts->cell_identity) >> 8) & 0xFF; Additionally I fixed setting the BSIC: nanobts_attr_bts[45] = bts->bsic; I have not yet provided a patch because its not fully tested, however Harald is informed. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: GPRS branch status updates
by Dieter Spaar 03 Nov '09

03 Nov '09

Hello Sylvain, On Mon, 2 Nov 2009 01:05:20 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > > I found out the problem. > > In gprs_bssgp_tx_dl_ud, then length encoded in the PDU TLV is > incorect. It uses msg->len but at that point it already did a > msgb_push to add space for the header so msg->len is already too big. > You need to save the size of msg->len before the msgb_push and then > use that when encoding the PDU TLV length. Thanks for the info, I tried it here but it did not help for the "GMM ATTACH REQUEST", the nanoBTS still reboots when it receives the data of the "GPRS IDENTITY REQUEST" which is sent afterwards. I finally found the reason for this behaviour (at least I hope it is the reason), I had to specify the correct BVCI parameter for the call to gprs_ns_sendmsg() in gprs_bssgp_tx_dl_ud(). If I use "925" instead of "0" it works. The phone sends an "GMM IDENITY RESPONSE" and continues to send "GMM ATTACH REQUEST" because it does not yet receive an accept. > BTW, do you sometimes hangout in #openbsc ? No, usually not (its a bit difficult for me to do my work and look at what is happing on IRC). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 3

Re: question about cell broadcast estimate
by Harald Welte 02 Nov '09

02 Nov '09

Dear Tim! I hope you don't mind I'm Cc'ing the mailing list. This means that other people can get involved in the discussion - and also means that I only have to write my summary about what needs to be done once, even if you for some reason are unable to complete the actual implementation :) On Mon, Nov 02, 2009 at 01:25:13PM -0500, Newman, Timothy wrote: > I'm working at Virginia Tech and it looks like we are going to start playing > with the cell broadcast gsm stuff. I'd like to just go ahead and add it into > openbsc. This is great news, thanks. Which BTS type are you using with OpenBSC? > Other than the brief read through of some of the 3GPP documents related to > cell broadcast, I'm not too familiar with the interworkings of it. It's not really difficult. What needs to be done 1) enable a channel configuration that adds a CBCH to one of the SDCCH/4 in a combined CCCH, or one of the SDCCH/8. I'd prefer the SDCCH/4, since that is supported by both BS-11 and nanoBTS. However, feel free to implement both options 2) encode the CBCH message (very similar to SMS encoding) TS 03.38 / 03.41 3) have a function to send the CBCH to the BTS over RSL (TS 08.58) 4) later: Implement the Scheduling (Chapter 2.1 of TS 04.12) for DRX There's two options for cell broadcast: 1) you can set a default cell broadcast message once by the BSC. The BTS then transmit that CB in every idle fame of the CBCH (TS 08.58 SMS BROADCAST CMD) 2) you want to sent multiple different CB messages, then the BSC needs to do the scheduling and send them to the BTS's (TS 08.58 SMS BROADCAST REQ) > I'm a little unclear how long this may take to add this functionality into > openbsc. If you had to estimate how long it would take (e.g. 1, 2, 6, 12 > months), what would you say? Just give me your estimate and I'll multiply > this by 4 because it will be students working on the project and they need a > little (a lot) of ramp of time for this also. If I or any other of the OpenBSC developers was doing it, I would say this is a matter of days, one week max for all of the options described above. However, you need to consider that your studends also have to read up the 3GPP specs, are unfamiliar with the terminlology, don't know the OpenBSC codebase, probably have not that much experience with "plain C" programming in an select-loop single threaded design, ... so a factor of four might not be sufficient. Regards, Harald p.s.: I would be interested in learning what you're using OpenBSC for at Virginia Tech. If you have a minute to elaborate on that, I'm very curious. Other people on the mailing list might share that interest, especially those users from academic institutions. If you prefer to respond privately, that would also be OK with me. -- - 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

special offer - nanoBTS
by WoMax 02 Nov '09

02 Nov '09

Special offer for the last nanoBTS type 139, Siemens (MOGIS) branded, new in box, but without POE-Adapter! Only one available, only 1900 Euro plus shipment. Contact me at womax(at)gmx(dot)ch

1 0

Re: GPRS branch status updates
by Dieter Spaar 02 Nov '09

02 Nov '09

Hello Sylvain, On Sun, 1 Nov 2009 21:17:26 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > > - In gprs_bssgp.c the function bssgp_rx_ul_ud calls : > > bts = gsm48_bts_by_ra_id( > TLVP_VAL(&tp, BSSGP_IE_CELL_ID), > TLVP_LEN(&tp, BSSGP_IE_CELL_ID)); > > But gsm48_bts_by_ra_id defined in gsm_04_08_gprs.c takes 3 arguments > the gsm_network as first one then the buffer and lenght. Since the > function was implicitely defined in gprs_bssgp.c, it compiled but of > course segfaulted as soon as it got there ... I don't even understand > how it worked for you. At the time I made the trace, I did not yet have connected with a GPRS phone. In the meantime I made a temporary workaround by referencing the global "bsc_gsmnet" and using it for the first parameter. > <0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT > <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT > > But as soon as the REJECT is sent to the BTS, it reboots ... no error > no message nothing ... I get a "GMM Attach Request" with my phone and the same behaviour afterwards, the nanoBTS reboots. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 2

lots of new BS11 internals pictures
by Bjoern Heller 02 Nov '09

02 Nov '09

Hi, we made lots of pictures of the bs11 pcbs. Maybe they will help you during disassembly or are interesting in an technical aspect. http://www.flickr.com/photos/hellercom/sets/72157619296925571/ regards Bjoern - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Björn Heller Jabber: tec(a)jabber.hellercom.de

1 0

Re: GPRS branch status updates
by Dieter Spaar 01 Nov '09

01 Nov '09

Hello Sylvain, On Sun, 1 Nov 2009 11:05:31 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > > I searched for what could be wrong but I didn't see anything obvious. > Could you provide a trace of a working startup so I can compare ? Maybe my trace is usefull too, I modified the two IP addresses and set "timeslot 7" to "phys_chan_config TCH/F_PDCH". I only noticed that it did not work immediately after the nanoBTS has been powered on, I had to start bsc_hack a second time (not sure if this can be reproduced). The trace is in the attached ZIP file, its from a Cygwin system. Best regards, Dieter Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

GPRS branch status updates
by Harald Welte 01 Nov '09

01 Nov '09

Hi all! I've pushed the current state of GPRS support into the 'gprs' branch. All the 'core' changes related to GPRS are already in master, so it mainly really adds the GPRS protocols (gprs_{ns,bssgp,llc}.[ch]) as well as the handling of the most importnat 04.08 GMM messages (gsm_04_08_gprs.[ch]) as well as the state management for the SGSN MM context (gprs_sgsn.[ch]). The status of the code is as follows: * NS link and BSSGP link are established between OpenBSC and the nanoBTS * LLC frames from the MS get delivered to the OpenBSC LLC code * GMM messages sent over LLC are delivered to the GMM code * The GMM code tries to respond with useful answers, permitting GPRS attach as well as routing area update What's missing: * any kind of GGSN functionality, i.e. gatewaying to PPP daemon for actual user payloads * persistant storage of SGSN MM context information, especially the attach/detach status, routing area and P-TMSI of a subscriber * PDP context activation/deactivation * flow control for the BTS as well as for each MS (BSSGP level) * retransmissions and things like acknowledged mode of LLC * support for multiple BTS There's really only one extremely ugly hack in the code right now, and that is that the IP address of the BTS is hard-coded in the ipac_gprs_send() function. You will have to enter the IP address of your BTS there to make packets in the SGSN->BTS direction delivered. Apart from that, I think the code is at a state where other interested developers can start playing with it. I am leaving to Korea on a customer assingment tomorrow and will unlikely have time to work on any GPRS code throughout the next two weeks. To get the code going, you should do the following things: * chceck out the gprs branch * hard-code your ip address into ipac_gprs_send() as indicated above * change your openbsc.cfg to use the last timeslot (TS 7) as "TCH/F_PDCH" instead of just "TCH/F" Patches / Bug reports / ... welcome Regards, Harald -- - 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 4

AW: OpenBSC RTP / MNCC integration
by Andreas.Eversberg 31 Oct '09

31 Oct '09

hi harald, > sorry for not getting back earlier. I honestly did not realize that there > was a second attachment to your mail. We typically use inline patches, and one > patch per mail on this list. Once again, sorry for the delay. next time i will send the patches inline... > I'm now looking at the code in detail, I shall be getting back to you at some > point during the next days. in order to remove md5 code, you can use a simple XOR to mix the input data. i think it is good enough to not select the same random number as the base station. regards, andreas

2 1

OpenBSC unsubscribe notification
by mailman-bounces＠lists.gnumonks.org 31 Oct '09

31 Oct '09

xavier.carcelle(a)openpattern.org has been removed from OpenBSC.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC