OpenBSC

openbsc@lists.osmocom.org

4317 discussions

patch: 1_timer
by Andreas.Eversberg 23 May '09

23 May '09

this patch renames the timer functions to avoid name collisions with libmisdn. the return value of bsc_update_timers() is required for applications to find out if a timer was fired. (this is required for later patches).

2 1

patch: 3_llist
by Andreas.Eversberg 23 May '09

23 May '09

This patch chnages the variable "new" to "_new" in order to include it in C++ code. The define "container_of" will cast pointer before assigning. Compiler with stricter options require this.

2 1

patch: 2_misdn
by Andreas.Eversberg 23 May '09

23 May '09

This patch corrects the inclusion of mISDN headers. Also the mISDNif.h is updated.

2 1

patch: 13_install
by Andreas.Eversberg 22 May '09

22 May '09

This patch moves telnet interface from bsc_hack to libbsc, so it can be used by applications also. If this makes sense, must be decided by you. This patch also includes the quick and dirty installation hook. This must be changed also.

2 1

Problem : RS232 link
by Eric Cathelinaud 21 May '09

21 May '09

Hi, I am now trying to configure the bs11 using bs11_config and I had a problem connecting via serial port. I tried then to use an USB adaptator as you did but I don't have any ttyUSB in my /dev/ I only have /dev/usbdev*.*_ep** (2 per USB port and 6 new ones appeared after connecting the USB adaptator). lsusb give me the following result: # lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 413c:3012 Dell Computer Corp. Optical Wheel Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 013: ID 9710:7715 MosChip Semiconductor Printer cable Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub where "MosChip Semiconductor Printer cable" is my adaptator (for printer and DB9) #lsmod ... usbserial 26348 1 visor usbcore 118068 7 visor,usbserial,usb_storage,usbhid,uhci_hcd,ehci_hcd ... Does anyone know why I can't see any ttyUSB? Best regards, Eric Cathelinaud

3 5

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC