OpenBSC May 2009

openbsc@lists.osmocom.org

14 participants
50 discussions

patch: 12_application
by Andreas.Eversberg 21 May '09

21 May '09

This interface is introduced to allow other applications than bsc_hack to be used with libbsc. The built-in application for call forwarding from mobile to mobile calls has been moved out of gsm_04_08.c to mncc.c and stays part of libbsc. The most messages on this interface begin with MNCC_ and end with _REQ (layer 4 requests) _CNF (layer 3 reply) _IND (layer 3 requests) _RSP (layer 4 replies). Other messages are used to control TRAU traffic or channel modification. More commands may be added in the future. The handling of messages from the mobile side (MMCC) and from the application (MNCC) is done by a state machine. (See Fig. 5.1b TS 04.08) The "datastate" list handles messages from the mobile side. The "downstate" list handles messages from the application. The timers are handled by a special timeout function. When a message is received, the downstate list or datastate list is checked for the current state and the message. If there is a match, for a current state and a message, it's handler called. Inside this handler, timers can be started and stopped, states can be changed, messages can be forwarded and replied, and so on. All information elements are parsed or created in gsm_04_08.c. A special "upqueue" is used to forward messages from gsm_04_08.c to the application. The dequeue function is called by the application in the main loop (before select function). If the application sends a message to BSC, it calls the "mncc_send" function of gsm_04_08.c. The process of this maessage in gsm_04_08.c may result in messages back to the application. The queue prevents libbsc from calling the application's "mncc_recv" function, while the application calls the "mncc_send" function. The upqueue makes sure that messages created by gsm_04_08.c during "mncc_send" is processed AFTER the application has finished it's processing. The call instance of the application is called "gsm_call". This has moved out of gsm_04_08.c into mncc.c. The gsm_04_08.c uses a "llist" of transactions: "struct gsm_trans". The transaction can be associated with a logical channel: "lchan". The use-counter of lchan is increased for every transaction assoicated to. After freeing of transaction, the use-counter is decremented. If lchan breaks down, all transactions are released. The application receives a "released indication" message. Multiple transactions for an lchan provide the ability to hold a call and receive/make another call. This has been successfully tested on LCR application and is not yet implemented in mncc.c, but very easy todo. A message between libbsc and application consists of a message type (mgs_type), a call reference (callref), and information elements within the same structure. Each information element has an additional flag, to indicati if it exists in the message. The message is defined in mncc.h The A transaction can have a logical channel (lchan) or not. At least it has a subscriber (subscr). If a transaction is created, the subscriber is checked. If no transaction with this subscriber exists, paging is started. If another transaction exists with an lchan, this lchan is also used for the transaction (already established). If another transaction of this subscriber exists, but no lchan, the paging is already stated, nothing is done until paging response. After a paging response, the transactions with the same subscribers are associated to the lchan. If paging failed, all transactions associated with the subscriber are released. (no user responding).

1 0

AW: patches for openbsc
by Andreas.Eversberg 21 May '09

21 May '09

>At least at that point, applications using libbsc (in your context, i.e. lcr >like applications) don't need to know any details, agreed. >The applications that I have in mind in fact need to know a lot more about the >details, on the other hand... hi harald, if libbsc is a toolbox not only for MSC applilcations, but applications that e.g. trigger paging or send O&M messages, it makes sense to export most internal functions and data structures. in this case it does not make sense to create a header file "openbsc/openbsc.h" for all applications. instead it makes sense to create a header file especially for the application interface "openbsc/mncc.h". only MSC application and MNCC interface require to include this header file. other applications include other header files. i would like to keep include files as is and add openbsc/mncc.h instead. what do you think? andreas

2 1

Musings on public API
by Holger Freyther 20 May '09

20 May '09

Hey Harald, Andreas, I just tried to come up with a patch to prefix the timer functions with bsc_ and started to think about public API. The thing is we only need to properly prefix symbols we intend to export. I don't think we will export timers. So the questions I think of are: what are we going to export? how are we going to export it? On the what question it mostly depends on Andreas and what he needs for his application, from what I understand that is the MNCC stuff that will come as one of his patches. For the other question of how we are going to export it we have at least two approaches, symbol filter and visibility attributes of the gcc. I prefer the later and have cooked up an example patch... comments welcome z. PS: I'm sorry to use libtool... the GNU documentation tries to hide other ways PPS: With the 2nd patch in place I don't think we need to rename the timer symbols (we still can as a matter of cleaning it up) PPS: With the 2nd patch we have everything in place for installable API...

4 5

Re: patches for openbsc
by Andreas.Eversberg 19 May '09

19 May '09

dear holger, dear harald, don't worry about little communication problems. the difference between being offensive and being contructive is only determined by the sound of voice, i think. we can't hear the "tone" in emails, so we try to imagine the tone when we read mails. so your constructive arguments can be easily understand wrong. let's get back to the patches. first, i decided to use one big patch, because the application interface requires almost all other parts to work. what i can do is to provide single patches that will work stand-allone, but some are dependant of earlier patches. harald already did a list of parts in it's order: * timer rename throughout the existing code * llist header changes (why were they made? c++?) * the transmit delay timer * introduction of trau interface * bsc_select_main(polling) * paging extension with cbfn BTS pointer * the actual MNCC interface * installation of libbsc (this should be last, since before the other changes it is of no use) i will start this week to apply the changes to the latest SVN snapshot, one by one. i will test it by calling from one mobile station to another station. (i think that is enough.) i will create a diff and announce it on the mailing list. (i can also put it on home.eversberg.eu or on the wiki, if you whish). after that i will continue with the next step, test it and provide the next diff. also, i need to know about "openbsc/openbsc.h" include file, i would like to add. it shall only include functions and definitions relevant for the application to use libbsc. because the application does not need to know about libbsc internals, the pointer to the "struct gsm_net" is of type "void". example in the first parameter of mncc_send(): int mncc_send(void *net, int msg_type, void *arg); this header file contains structures that are used by application and libbsc also, like: enum gsm_bts_type currently i copied the bootstrap code from bsc_hack.c into my LCR application, so i need to incude more than openbsc.h there. in my case i use a file called "bootstrap.c" which takes all the parameters to initiate gsm network an controls bootstrapping. i think this should be part ob libbsc in the future. if bootstrapping would be part of libbsc, there is no need to include more than openbsc.h to use the MNCC interface. what do you think? best regards, andreas

3 2

AW: patches for openbsc
by Andreas.Eversberg 19 May '09

19 May '09

hi holger, these patches are not the "final" patch. some things must be discussed before of yourse. i removed the out commented code from the patch. some comments like "// todo ..." are not removed. when you look at the file http://home.eversberg.eu/stage1.html, you will see the new version. whenever there is something to complain about, i will change it, until we have patches that all of us agree. please ask if you don't fully understand the patch. especially for the BSC<->application interface, i was too lazy to describe all details. you will find mncc.c usefull to see how the interface is handled. regards, andres -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Sonntag, 17. Mai 2009 09:35 An: openbsc(a)lists.gnumonks.org Betreff: Re: patches for openbsc On Friday 15 May 2009 12:37:50 Andreas.Eversberg wrote: > hi, > > finally my patch is documented (almost). you will find the > documentation of the patch: > > http://home.eversberg.eu/stage1.html > > the patch in plain text fromat: > > http://home.eversberg.eu/stage1.patch > > it also includes the changes i posted here before. if you have > questions, ask. Hi Andreas, thank you for the patches. Let me start to review the patches one by one as replies to this one. One general thing with this and the previous patch. I'm quite picky when it comes to commented out code, and left overs from debugging.... please try to avoid leaving that in. z.

4 4

Re: TRX #2
by Dieter Spaar 15 May '09

15 May '09

Hello Andreas, On Fri, 15 May 2009 16:11:06 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > i like to use TRX 2. to create objects, i need a password. any idea? The original password set by the manufacturer depends on the serial number of the BS-11. However "bs11_config" contains everything needed to set a new password and create TRX2. If you want to use LMT, you should run "bs11_config" first and than use LMT, the new password is in the source code of "bs11_config". Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

TRX #2
by Andreas.Eversberg 15 May '09

15 May '09

hi, i like to use TRX 2. to create objects, i need a password. any idea? i think that openbsc requires more changes than adding more timeslots. also the bootstrap process must be improved, i think. for multiple trx i would suggest to use an array of frequencies for each trx when calling boostrap_network() for multiple bts i would suggest to call bootstrap_network() again to configure the second bts. for multiple bts on the same E1 interface, is for further study. andreas

1 0

RJ45 cable
by Eric Cathelinaud 15 May '09

15 May '09

Hi, I just saw you added to the wiki a "step by step" guide to build the RJ45. I was wondering why you are saying you use green white / green cables for pin1&2. I actually pluged in my twinax orange white / orange cables. Are you using a crossed cable? Best regards Eric Cathelinaud

2 2

Re: Problem with installing OpenBSC on Centos 4
by Dieter Spaar 15 May '09

15 May '09

Hello Nordin, On Thu, 14 May 2009 17:26:22 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > > Than I executed the bsc_hack for the nanoBTS (thus I give the > appropriate parameters as described on the webpage), and I get the > following error: > DB: Database initialized. > DB: Database prepared. > mi_setup could not open socket Address family not supported by protocol Do you really provide the correct parameters to bsc_hack ? The current version of bsc_hack requires the parameter "-t nanobts900" or "-t nanobts1800", depending on the type of the nanoBTS you have. If you don't specify the type, the BS-11 is used. Additionally be sure to specify the ARFCN for a nanoBTS 1800 because otherwise the default GSM900 channel 123 will be used which does not work for DCS1800. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

SMS interface
by Andreas.Eversberg 15 May '09

15 May '09

hi, i know that there is an SMS application interface to come. but currently i like to send SMS via vty interface. i don't know much about the interface structure of the vty interface. here is what i actually want: a daemon checks the hlr for unauthorized subscribers. for the first entry found, a subscriber extension is assign. additionally an SMS is sent to the subscriber, to inform about the assigned number, the network, and dial plan. the subscriber will sen be authorized in the hlr. this daemon shall run every minute. regards, andreas p.s. the application interface patch is on its way. maybe this weekend.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2009