> On 21 Feb 2016, at 11:16, Neels Hofmeyr <[email protected]> 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
