30 Jul
2013
30 Jul
'13
7:25 p.m.
Hi 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)