patch: 12_application

historical

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090521/eedc47d8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12_application.patch.gz
Type: application/x-gzip
Size: 23789 bytes
Desc: 12_application.patch.gz
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090521/eedc47d8/attachment.bin>