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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)