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).
>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
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...
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
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.
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
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
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
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
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.
