- OpenBSC - lists.osmocom.org

Whether to include a cells own BCCH in the BCCH Allocation
by Harald Welte 28 Mar '10

28 Mar '10

Hi! I don't exactly remember in which context I was last communicating with whom of you about the question whether or not the BA of a cell should include its own BCCH frequency or not. I think from commercial networks we could see both behaviors, and it was thus unclear what we should do for OpenBSC. I've now found a reference for this in the GMS specs: GSM 3.22 Chapter 4.8: > NOTE: The PLMN operator cannot expect the ME to store the BCCH or > CPBCCH carrier frequency of the serving cell in the SIM unless the > BA(BCCH) includes the BCCH or CPBCCH carrier frequency on which it is > broadcast. So now we know at least the difference when it comes to those two options. 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)

1 0

Re: layer3 work / issues
by Dieter Spaar 28 Mar '10

28 Mar '10

Hello Harald, On Sun, 28 Mar 2010 13:16:36 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > as far as I know, it has to change on every retransmission. Dieter is > probably the person who knows all RACH aspects in detail, maybe he can > comment on this. According to the specification the random value has to change on every transmission: a random reference which is drawn randomly from a uniform probability distribution for every new transmission. In the TSM30 firmware this is done by having a table with random values and an index into the table which is initialised to a random value when the Immediate Assignment Procedure is started and incremented with every random number taken for a retransmission. The table has 32 values because the random reference is not larger than 5 bits. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

layer3 work / issues
by Harald Welte 28 Mar '10

28 Mar '10

Hi Andreas, some comments regarding your issues.txt: > must random value in chan_request change on every resend or only on > every RR establishment? (currently it changes on every RR > establishment only.) as far as I know, it has to change on every retransmission. Dieter is probably the person who knows all RACH aspects in detail, maybe he can comment on this. > must be expanded: struct osmocom_ms: no problem here, expand it how you see fit. I just generally prefer caller-allocated structures to callee-allocated ones, and I'd like to use static allocation whenever possible. So if there's only one 'struct rrlayer' per ms, then we should simply include 'struct rrlayer' as sub-structure of 'struct osmocom_ms', rather than having two structures and pointers between them. > OpenBSC: if tx-msg fails during process, the msg must be freed to > avoid memory leak. I don't understand, can you please explain this further? > random acces via RSL? I think we simply add some new / non-standard primitives, as it does not have any notion of RACH bursts. It might also be possible to encode it as UNIT DATA REQUEST for channel (chan_nr) RACH (CCCH uplink), but then we still cannot specify details like at which frame number, etc. From what I can see, your RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom RSLms message and nothing specified in the original RSLms spec. Cheers, 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)

1 0

JFYI: moving 'debug.[ch]' to libosmocore
by Harald Welte 25 Mar '10

25 Mar '10

Hi! One of the bigger missing parts in libosmocore is the debug support that we have in OpenBSC, including support for multiple debug categories, log levels, log targets, filters, context, etc. I'm currently half-way through splitting/generalizing the core code from the OpenBSC specific bits (like IMSI context/filter). It's coming along quite nicely - actually less of a problem than I originally thought. The purpose of this is (as usual) to enable OsmocomBB to use the same codebase as OpenBSC for logging/debugging. So this mail is simply a heads-up that some changes will be visible in this area, once again requiring you to update + build libosmocore and OpenBSC after the changes have been committed. The good news, at least it should fail gracefully now, as the OpenBSC autotools magic is now requesting a certain libosmocore version during ./configure. Cheers, 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)

1 0

Problem with bs11_config
by Marcus Specht 25 Mar '10

25 Mar '10

Hi, i have a problem with bs11_config. When i start it, i get this: --------------------------------------------------------- # ./bs11_config -p /dev/ttyS0 /path/to/BTSBMC76.SWI bs11_config (C) 2009 by Harald Welte and Dieter Spaar This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY Invalid length in hdr: 0 Speicherzugriffsfehler --------------------------------------------------------- Thanks Marcus -- Marcus Specht open|MVNO c/o Cyber-Dynamix Gesellschaft für Systemintegration GmbH Heiner-Stuhlfauth-Str. 28 90480 Nürnberg Tel.: 0911 / 1809105 Fax.: 0911 / 1809109 Geschäftsführer: Heiko Thierbach, Gerhard Feder Sitz der Gesellschaft ist Nürnberg Amtsgericht Nürnberg, HRB 16704 Ust-Id.-Nr. DE204640808 ------------------------------------------------------------------------------ Diese Nachricht ist eine nicht öffentliche Mitteilung. Sollten Sie diese Nachricht versehentlich erhalten haben und nicht der gewünschte Empfänger sein, so bitten wir Sie, diese Nachricht zu löschen, keine Kopien anzufertigen und nicht weiterzuleiten. Bitte informieren Sie uns per eMail über den Zustellungsfehler und entschuldigen Sie die Unannehmlichkeit. Bitte beachten Sie: Unabhängig vom Inhalt stellt diese Nachricht keinerlei vertragliche Verpflichtung, Zusicherung, Bestellung, Angebot oder ähnliches dar, solange keine schriftliche Bestätigung von uns vorliegt.

3 2

Re: IMPORTANT: Building OpenBSC with libosmocore
by Holger Freyther 23 Mar '10

23 Mar '10

On Saturday 06 March 2010 00:58:50 Harald Welte wrote: > > I think OpenBSC has been quite useful and stable for quite some time, it > would be great to make something like an 1.0 release at some point soon. > Maybe zecke and myself can do this in the next couple of weeks. Shall we pick 1.0.0 for both OpenBSC and libosmocore?

2 1

cannot execute OpenBSC programs
by AHMET GÜLTEKİN 23 Mar '10

23 Mar '10

Hi, I have downloaded and compiled both libosmocore and OpenBSC. However, when I try to execute an OpenBSC program (for example ipaccess-find) I see the following error ~/openbsc/openbsc/src# ./ipaccess-find eth0 ./ipaccess-find: error while loading shared libraries: libosmocore.so.0: cannot open shared object file: No such file or directory could you help me. Thanks. Ahmet

3 2

Re: IMPORTANT: Building OpenBSC with libosmocore
by Holger Freyther 23 Mar '10

23 Mar '10

On Saturday 06 March 2010 00:58:50 Harald Welte wrote: > > I think OpenBSC has been quite useful and stable for quite some time, it > would be great to make something like an 1.0 release at some point soon. > Maybe zecke and myself can do this in the next couple of weeks. Shall we pick 1.0.0 for both OpenBSC and libosmocore?

1 0

IMPORTANT: Building OpenBSC with libosmocore
by Harald Welte 22 Mar '10

22 Mar '10

Hi All Just to clarify this (since we've had another question on the ML) On Wed, Mar 03, 2010 at 10:15:44AM +0100, Holger Freyther wrote: > You are using the latest version of libosmocore but not the one of OpenBSC. You always need to use latest OpenBSC with latest libosmocore. We really cannot afford to spend more time in supporting any kind of forward/backward compatibility on a commit level. However, what we should do, is to make official releases of both the library and the OpenBSC program. OpenBSC will then require a particular version of libosmocore, and the configure script will notice if it is not available. I think OpenBSC has been quite useful and stable for quite some time, it would be great to make something like an 1.0 release at some point soon. Maybe zecke and myself can do this in the next couple of weeks. > libosmocore is a rather new library and we move stuff from OpenBSC into this > library, which means if you have a new version of libosmocore and a bit older > one of OpenBSC your compiler will see stuff twice. This will probably still be the case for the weeks to come, while even more stuff (e.g. 04.08 call control IE parsing / generation) moves into libosmocore. So please, always do a full cycle of * "git pull" on libosmocore * "git pull" on openbsc * "./configure && make install" on libosmocore * "./configure && make" on openbsc This way you'll get a consistent build. Thanks for your understanding, 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 1

BS-11 multidrop problem
by till 20 Mar '10

20 Mar '10

Hi, i want to operate two BS-11 via one E1-card. And i did it almost like here: http://lists.gnumonks.org/pipermail/openbsc/2009-August/000733.html But i dont know how to configure the bport1 object for multidrop and how to use the hfcmulti module to get two interfaces (for lcr i compiled misdn_l1loop but i think this isnt the right here ;)). So atm i am not able to communicate with the second BS11 :/. Any idea? Thx & Greets Till

1 0