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