Operation management in the MSC code

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Tue Jun 15 08:20:35 UTC 2010


On Tue, Jun 15, 2010 at 12:59:21PM +0800, Holger Freyther wrote:
 
> I would like to make the radical proposal to solve that.
> 
> 1.) kill the transaction...
> 2.) generalize it with the "operation". Right now we do have two
> operations, one for LU, one for AUTH, we should have them for USSD, SMS
> and CC as well.

I think location updating and authentication (as well as anything else
that is part of MM or RR) need to be treated differently than the
real transactions (like SMS, CC, SS, ...)

For one part: they don't have a transaction identifier, so you can never
have multiple of them at the same time.  For the other part: They occur
at specific times as mandated by the specification, so they cannot happen
in any order like SMS transfers or call related transactions.

> Each gsm_subscriber_connection (MSC data) has an operation manager, when
> a lchan is opened we will attempt to create an operation for the initial
> message, at the end of one operation the operation manager will check if
> all operations are completed and then send a clear using the BSC API.

how would you take care of ordering / sequencing? How to decide which operation
is exclusive and which operations can operate simultaneously?  Especially
in CC, eight call control 'operations' would be able to exist at the same
time...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list