GPRS - local and foreign TLLIs

historical

Hi Luca,

On Fri, Jan 21, 2011 at 06:44:03AM +0100, Luca Melette wrote:

> after setting up a nanoBTS with OpenBSC/SGSN/GGSN,
> I had some troubles trying to connect my smartphone
> to the GPRS cell.
> 
> Investigating the BTS-to-SGSN traffic, I saw that the
> frames sent by the SGSN were all marked with the same
> N(U) value (at LLC layer), the value was 0.
> 
> With some debug, I found that the there was a mismatch
> in the TLLI storage, used to keep the status of attached
> terminals.

This is probably related to some recent changes like
f6bd340df6bcac716da78da8e35f379a7b853027 where I tried to fix the TLLI lookup
in case a MS moves from one RA to another.  It seems instead of fixing it,
I have made things worse.  Try to revert that patch...

> My question is about foreign and local TLLIs.
> I patched the lookup, avoiding the conversion, so that the
> LLE is found and everything works fine... but...
> 
> What is the sense of the conversion?
> 
> Should the TLLI be always stored as a local one?
> 
> Can this problem be solved with another foreign2local
> while allocating new entries?

It is a hard problem that has caused already quite a lot of headaches to me.

1) we should never create a new TLLI in our map on outgoing transfers

2) we need to get all the TLLI transitions/translations right (from
   GMM -> LLC layer.  Special care has to be taken in the case that two
   different TLLI values are acceptable for the same MS, e.g. in case
   of TMSI reallocation or some message losses (remember: as opposed to MM,
   GMM messages can be dropped by the lower layers).

> Actually, my problem has been solved with that workaround.
> But I'm curious to know what is the right way.

I am very happy to get your input on the problem.  As indicated, I've already
spent a number of hours trying to come up with a solution that's correct in all
cases, but have failed to do so.   Prior to my December 23rd changes, it was
working fine with a single BTS in a single RA.  But once you start to see
MS moving betwen RA, the old code did not correctly resolve the foreign TLLI
in the new RA to the old 'local' TLLI.

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)