Merge plan for the On-Waves branch to master

[Harald Welte]

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