Future of Iu branches (was Re: [PATCH 1/4] gprs_gmm: ensure llme present upon Attach Req) #57686)

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Apr 28 12:52:12 UTC 2016


Hi Neels,

I'm a bit troubled by the following statements:

On Thu, Apr 28, 2016 at 01:27:11PM +0200, Neels Hofmeyr wrote:
> The merge-Iu-to-master review will be ... extreme, probably. Daniel and I
> should at some point take a look at refactoring the commit sequence to
> group by semantics and iron out trial-and-error commits.
> 
> But it won't happen without an A-interface, I guess, so it is quite far
> down the line at this point (unless we keep NITB somehow, which would
> probably also be a bit of work).

It was clearly not the intention to keep the code out of master for more
than the time it takes to implement those features.

So yes, very clearly, for the CS side the NITB has to stay intact after
a merge of the Iu, until the A interface is implemented.  So please
don't think of this as something "far down the line".

For the PS side, I don't see any reason at all why a merge to master
should be postponed much longer (after it works end-to-end, with GSUP
and external HLR).  The newly-introduced libiu should be easy to add
without any risk to break existing code.  And the decisions about Gb vs.
IuPS are all made at runtime when looking at the respective subscriber /
mm_context.

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)



More information about the OpenBSC mailing list