Hey Guys,
some of us started to look into the various 08.0x specs and even SCCP (not me yet) and I think our common goal is to go towards a more "normal" BSS/MSC and in the same way keeping the spirit of bsc_hack to allow to run a whole network with one executable.
A rough split up of BSC vs. MSC would be:
BSC has the secret of: - init hardware, bcch, oml/rsl setup - paging - channel allocation/management
MSC has most of the policies: - HLR/VLR and who to allow into the network - call handling etc...
To keep this short ('m quite tired at the moment) my goal/approach is to create a libmsc.a and move the db.c, gsm_subscriber.c and on the way to move policy out of gsm_04_08.c to the libmsc.a. bsc and msc would communicate with an API that resembles the DTAP, BSSMAP interface. The MNCC use case Andreas and Harald are working on should remain supported, same as the bsc_hack.c. The goal of having an interface like DTAP and BSSMAP is to allow implementing the A-Interface.
I will start this work in a branch called holger/msc and will seek for feedback once I have something that is worthwhile to share.
good night z.
Hi Holger!
On Wed, Jun 10, 2009 at 04:51:47PM +0200, Holger Freyther wrote:
some of us started to look into the various 08.0x specs and even SCCP (not me yet) and I think our common goal is to go towards a more "normal" BSS/MSC and in the same way keeping the spirit of bsc_hack to allow to run a whole network with one executable.
exactly.
To keep this short ('m quite tired at the moment) my goal/approach is to create a libmsc.a and move the db.c, gsm_subscriber.c and on the way to move policy out of gsm_04_08.c to the libmsc.a. bsc and msc would communicate with an API that resembles the DTAP, BSSMAP interface. The MNCC use case Andreas and Harald are working on should remain supported, same as the bsc_hack.c.
yes. Basically the split you are introducing is below the MNCC and the bsc_hack application cases. They both use [parts of] MSC and BSC functionality, i.e. can be implemented on top of the libmsc + libbsc combination that you're aiming for.
I will start this work in a branch called holger/msc and will seek for feedback once I have something that is worthwhile to share.
great. good luck!
On Wednesday 10 June 2009 16:51:47 Holger Freyther wrote:
I will start this work in a branch called holger/msc and will seek for feedback once I have something that is worthwhile to share.
Just a quick status update on the above named branch. First of all it exists now and has the first bits of the abstraction...
The problems: - We use gsm_subscriber and the db in places were we should not (find_by_tmsi, find_by_imsi...) - We do channel management in layer3 code were we should not (lchan_put, lchan_auto_release)
What was done so far: - Create libmsc.a - Move db.c, telnet_interface.c there initially - Move functionality of gsm_subscriber.c that uses a DB to the MSC - Move high level part of paging response to MSC (the BSC part needs to be that way but is a violation of the spec...) - Move location updating request handling to msc_loc.c
What needs to be done: - Move CC and SMS part to the MSC layer (I wait for harald to finish the mncc stuff first to avoid a big merge catastrophe) - Change paging to be internal to the BSC. When to stop/retire a paging request? In one way the BSC is not supposed to look at the PAGING RESPONSE (see 08.08), but I could not find a "stop" paging... so we will have to tell the paging layer somehow to stop... without doing it too early (that is what currently happens...)
The interface: - BSC to MSC passes struct msgb* from gsm_04_08.c via a gsm layer3 callback that is stored in the gsm_network - MSC to BSC work by sending a struct msgb* using the existing send msg function.
please take a look and scream if you think it goes in the wrong direction...
z.
-
Harald Welte -
Holger Freyther