Hi,
I have finally an idea on how to go from varpoware "oh I need to merge that" to actually merging stuff and started to work on that.
The one goal I have is to create a BSC/MSC split inside our codebase and to make MSC functionality only communicate via a given BSC API. This move will allow to do some things transparently to the MSC code, it includes automatic RLL establishes for SAPI, very early/early assignment will become transparent and in the future I can roll out my "subscriber task" scheduler to do stuff like SMS submit during a voice call...
Here is my plan on how to get there...
1.) Create a new structure for the MS Connection. This would happen on a GSM 0808 Complete Layer3 Information message (e.g. CM Service Request, Paging Response). The name I picked is total rubish but can easily changed later.
I have embedded this connection into the struct gsm_lchan and moved all MSC attributes into this new structure. So right now we have a 1:1 mapping between a GSM LCHAN and the Subscriber Connection.
2.) Moved transaction code to work on this new structure instead of the lchan, I verified MT-SMS, MO-SMS, MT-Call, MO-Call. So the plan is to remove the occurence of GSM LCHAN from the MSC code paths, this will also mean to remove direct calls to RSL, RLL, paging.c.
3.) I picked gsm_04_11.c as the first file from the MSC (actually SMSC) code to go without the lchan. I have removed the direct call to RSL and placed it behind a new GSM0808 DTAP API. This would be the place where we figure out the real LCHAN..
This is all working and I can build on top of that until I reach the goal at which point I can forward port some of my code from the On Waves branch and instead of playing MSC myself, put it into SCCP...
<- now comes the stuff that I want to complete by the end of next month ->
4.) Currently when compiling you see a "BROKEN" warning, this is more that it is broken conceptually as the code handles paging and RLL establishment by itself. So the idea will be to move my "bssap.c" code to master and handle the RLL establishment and paging inside the new BSC API. This would involve queuing of messages...
5.) Remove the callback for SMS from abis_rsl.c and create a bsc_api_init with callbacks for various things (mostly Create Connection, Clear Request, Data). At this point the gsm_04_11.c will be free of BSC code.
6.) Move it to gsm_04_08. This will involve adding new commands (resembling the GSM 08.08) message names, sharing some callbacks between SAPI=0 and SAPI=3 and having a dispatch. E.g. later we should have a handler for new connection which would run authentication and then dispatch the handling of the connection to a task, on task completion close the channel or give it to the next task. After this we should magically be able to switch between very early/early assignment in the BSC code and the MSC will not recognize this, also TCH/H handling with be mostly transparent.
7.) Remove the 1:1 mapping of of GSM LChan to the new struct. Actually the new struct should include two lchan's (in case of handover or assignment), I will have to figure out on how to marry the handover code with that...
8.) I could rebuild my bsc_msc_ip.c on top of the new BSC API and all I need to do is to handle MSC. We could also create a msc_bsc_ip.c which takes these SCCP messages and sticks it into the MSC code of ours and we have a MSC.
as usual... any help is more than welcome.
z.
Hi zecke,
On Thu, Mar 25, 2010 at 10:44:50AM +0100, Holger Freyther wrote:
I have finally an idea on how to go from varpoware "oh I need to merge that" to actually merging stuff and started to work on that.
thanks, this is much anticipated by me.
As far as I can understand the implications of your approach, I completely agree with it. We need that BSC/MSC split and the resulting split of bsc-side lchan and msc-side structure.
1.) Create a new structure for the MS Connection. This would happen on a GSM 0808 Complete Layer3 Information message (e.g. CM Service Request, Paging Response). The name I picked is total rubish but can easily changed later.
my (not final) suggestion for the name would be 'struct ms_context' or something like that.
<- now comes the stuff that I want to complete by the end of next month ->
4.) Currently when compiling you see a "BROKEN" warning, this is more that it is broken conceptually as the code handles paging and RLL establishment by itself. So the idea will be to move my "bssap.c" code to master and handle the RLL establishment and paging inside the new BSC API.
Makes perfect sense.
This would involve queuing of messages...
can you illustrate why that is required? I don't doubt it, but I can't seem to figure out why...
7.) Remove the 1:1 mapping of of GSM LChan to the new struct. Actually the new struct should include two lchan's (in case of handover or assignment), I will have to figure out on how to marry the handover code with that...
I also cannot tell right now what's the best way to 'marry' handover, but I'm happy to have a look at (and do or at least comment on) the handover part once your other code is at a point where you want to do this step. Simply drop me a message once that is the case.
8.) I could rebuild my bsc_msc_ip.c on top of the new BSC API and all I need to do is to handle MSC. We could also create a msc_bsc_ip.c which takes these SCCP messages and sticks it into the MSC code of ours and we have a MSC.
sounds like fun.
By the way: One comment regarding naming. I would like to move OpenBSC into the namespace of Osmocom. One thing that will happen is that the URL of the homepage will change from openbsc.gnumonks.org to openbsc.osmocom.org (with rediects in place, of course).
Also, the standalone SGSN code that I'm working on is already called osmo_sgsn. I'm willing to expand it to osmocom_sgsn (or change from _ to -)if you think it's a better idea.
So once we really have separate BSC and MSC executables, I'd appreciate if their naming would also somehow include the osmocom/osmo prefix in them.
Regards, Harald
On Monday 29 March 2010 04:25:02 Harald Welte wrote:
Hi LaF0rge,
As far as I can understand the implications of your approach, I completely agree with it. We need that BSC/MSC split and the resulting split of bsc-side lchan and msc-side structure.
thanks.
This would involve queuing of messages...
can you illustrate why that is required? I don't doubt it, but I can't seem to figure out why...
I see why you are wondering. All the messages seem to work with sending a request and then getting an ack. So besides queuing the one message that starts transmitting on a new SAPI in theory we should not need to queue.
I have a queue in the on-waves/bsc-master branch just because I have a MSC that was sending more commands even when something like ASSIGNMENT, CIPHER MODE, or SAPI establishment was not yet completed.
So once we really have separate BSC and MSC executables, I'd appreciate if their naming would also somehow include the osmocom/osmo prefix in them.
I see no issue in putting a osmo_ in front of the executable names and joining all of the different GSM subsystems into the "osmocom" umbrella.