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.orgHi Holger,
On Tue, Jul 30, 2013 at 09:20:38AM +0200, Holger Hans Peter Freyther wrote:
> The engineer in me.. used git gui blame on the file and I found the commit
> that added the foreign tlli lookup.
thanks.
> 1.) I do the lookup based on the tlli...
> 2.) if the tlli is foreign.. I convert it and make another lookup
> 3.) I create the LLME on the fly or return NULL
seems reasonable.
> Or shall we do this... "oh we know this subscriber already" at a
> higher level in GMM? E.g. notice that it is a routing area update...
> and then free the new llme and do a tlli assignment for the foreign
> tlli?
That is probably the cleaner approach. I'm wondering why there is no
information in the spec regarding that case, or at least why I haven't
been stumbling accross it.
If it is done at LLC level, it seems the more 'defensive' / tolerant
approach, because we don't expect the first LLC message on a new BTS to
be a GMM/RAU message. I'm not sure if this is guaranteed by the specs.
If the first LLC message on the new cell is a user data message, then
the GMM/RAU based approach of adressing this problem would not work.
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)