Hey guys,
back in January I added ref-counting to the lchan and it has worked to some degree, and we have seen ref-leaks as well (fixed thanks to Andreas). Currently I'm working on integrating OpenBSC into a real MSC at on-waves.com and this has made me read the GSM08.08 specification a bit more.
I would like to implement the following. - Remove the refcount from lchan - Replace it with the "transaction" concept. On certain 04.08 messgaes (e.g. paging response, various MM messages) open a transaction from BSC to MSC code. The channel is bound to the transaction.
The lchan is getting released when the transaction is finished, in case of the "RSL chan" is going away too early there will be a "clear" signal/method called from the BSC and the MSC side is asked to let it go.
The benefit of this: - BSC and MSC are better separated - My MSC code could wrap the transaction into a SCCP connection - Channel leak == transaction_free not getting called.
regards holger
Hi,
On Wed, Sep 30, 2009 at 4:12 AM, Holger Freyther zecke@selfish.org wrote:
I would like to implement the following. - Remove the refcount from lchan - Replace it with the "transaction" concept. On certain 04.08 messgaes (e.g. paging response, various MM messages) open a transaction from BSC to MSC code. The channel is bound to the transaction.
Are you talking about the transaction in transaction.c ?
Because for SMS for examples, we re-use the same lchan for consecutive transactions when delivering multiple SMS back to back and your approach would make that impossible if I understand correctly ?
The lchan is getting released when the transaction is finished, in case of the "RSL chan" is going away too early there will be a "clear" signal/method called from the BSC and the MSC side is asked to let it go.
On Wednesday 30 September 2009 14:08:16 Sylvain Munaut wrote:
Hi,
On Wed, Sep 30, 2009 at 4:12 AM, Holger Freyther zecke@selfish.org wrote:
I would like to implement the following. - Remove the refcount from lchan - Replace it with the "transaction" concept. On certain 04.08 messgaes (e.g. paging response, various MM messages) open a transaction from BSC to MSC code. The channel is bound to the transaction.
Are you talking about the transaction in transaction.c ?
Partially yes. I'm talking about GSM08.08 "§ 3.2.1.32 COMPLETE LAYER 3 INFORMATION". In which the MSC is getting informed that it is in charge now (only the MSC is closing the SCCP connection...)
Because for SMS for examples, we re-use the same lchan for consecutive transactions when delivering multiple SMS back to back and your approach would make that impossible if I understand correctly ?
Well, it is up to the MSC to decide when to close the "transaction"/SCCP connection. So if the MSC policy is to send multiple SMS it will still work.
The general change is that the MSC is completely controlling the lchan lifetime. If the radio resource is freed, but the MSC still occupies the channel it will not be reused.
holger
Hi Zecke,
On Wed, Sep 30, 2009 at 04:12:36AM +0200, Holger Freyther wrote:
I would like to implement the following.
- Remove the refcount from lchan
- Replace it with the "transaction" concept. On certain 04.08 messgaes (e.g. paging response, various MM messages) open a transaction from BSC to MSC code. The channel is bound to the transaction.
yes, this makes a lot of sense, of course.
The lchan is getting released when the transaction is finished, in case of the "RSL chan" is going away too early there will be a "clear" signal/method called from the BSC and the MSC side is asked to let it go.
well, what we need to somehow ensure is a situation where multiple transactions are pending / ongoing for one MS, i.e. a call is already established (or in the process of being established), while another call is to be signalled, or while SMS are to be delivered, etc.
How would this fit into your new concept?
The benefit of this:
- BSC and MSC are better separated
- My MSC code could wrap the transaction into a SCCP connection
- Channel leak == transaction_free not getting called.
There is one additional benefit: faster clearing of channels. Right now, we still keep the lchan open for a very long time even after e.g. location update or MT SMS have completed. In a real network, those timeouts are at least a factor of 10 faster. This also means that we're more susceptible to DoS until we have quicker closing of lchans.
Regards,
On Wednesday 30 September 2009 19:25:13 Harald Welte wrote:
Hi Zecke,
Ni Hao Laforge,
The lchan is getting released when the transaction is finished,in case of the "RSL chan" is going away too early there will be a "clear" signal/method called from the BSC and the MSC side is asked to let it go.
well, what we need to somehow ensure is a situation where multiple transactions are pending / ongoing for one MS, i.e. a call is already established (or in the process of being established), while another call is to be signalled, or while SMS are to be delivered, etc.
How would this fit into your new concept?
I think there is no change to the problem above as it is mostly policy (e.g. two phone MS terminated calls at the same time) or to queue SMS submit and then phone call.
What is currently in the tree but unused is the "subscr_get" and "subscr_put" methods that implement queuing on top of the paging layer. The current implementation will close the channel on _put and initiate paging again. This could/should be tweaked to issue a channel modify and then pass on the transaction from one subsystem to another. Once everything has been handled the "CLEAR REQUEST"/transaction end would be signalized and the radio resource would be freed.
does this make sense to you? holger
-
Harald Welte -
Holger Freyther -
Sylvain Munaut