21 Feb
2016
21 Feb
'16
2:10 p.m.
On 21 Feb 2016, at 11:16, Neels Hofmeyr
<nhofmeyr(a)sysmocom.de> wrote:
Not that late really, I looked at bsc_api briefly but saw that it wasn't
helping for IuCS, so I postponed dissecting the (numerous) details of it
to another day. It should come naturally when the A-interface is created.
But in fact my foggy vision so far is that the struct bsc_api will not
actually survive, since the A-interface rx, like IuCS rx, will call
functions directly instead of keeping a struct of function pointers...
IMHO A clearly structured header file would do a nicer job at highlighting
the MSC<->BSC entry points. I am also presuming that we will drop
osmo-nitb as such and replace it with "please run osmo-bsc plugged into
osmo-cscn", BTW.
The initial idea was that at the "MSC" the "Complete Layer3 message"
(the initial message) would arrive. The MSC would then create an instance of a
msc_subscriber_connection (and add a backpointer to the gsm_subscriber_connection which
then probably should be called bsc_subscriber_connection). The MM, CC and other code
should then refer to the msc_subscriber_connection. In case of osmo-cscn the
msc_subscriber_conn would point to the "Iu" definition and for osmo-nitb it
would still have the gsm_subscriber_conn backpointer.
The other part was that there should be something like msc_api inside the MM/CC code that
either directly maps to the BSC code or in case of osmo-cscn send it to the HNBGW.
anyway, you will come up with something that makes sense too
holger