AW: 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 15:30:29 UTC 2010


On Tue, Jun 15, 2010 at 04:15:58PM +0800, Holger Freyther wrote:

> Regarding new (SMS) code, the main lesson to learn is probably: Have
> Success/Failure/Timeout in mind and free the channel in any of these
> states...

sure. The current SMS implementation was always only a quick hack to make
it work at all.  

At some point, new code should be written with MAP SMS semantics in mind, i.e.
anticipate that SMS are sent from an external process by procedures that
resemble the SMS-MAP as defined in Section 4 of 03.47.  I'm not referring to
the actual encoding, but by the flow of events / procedures, i.e. :
* Forward MT SMS
* Forward MO SMS
* SC Alert

This basically means an external entity (the Service Center SC) sends a SMS to
the MSC, identifying the subscriber by its MSISDN.  The MSC needs to decide if
there is already a radio channel or if it needs to do paging. It does the
paging (if needed), delivers the message and if everything works fine, it
reports back to the SC.  The timer at the SC side is specified between 15 to
180 seconds in total.

MO-SMS is relatively similar, but in inverse direction.

The SC Alert seems to be used for notifying the SC that a MS (that previously
was unreachable or had a memory-full condition) is now available again.

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