Iu: flimsy TMSI

historical

Hi Neels,

On Thu, Mar 17, 2016 at 02:05:32AM +0100, Neels Hofmeyr wrote:
> about our difficulty in maintaining a prolonged link with the UE, I found
> a bit of discrepancy concerning the TMSIs used.
> 
> 1) UE sends TMSI in "(GMM) Attach Request"     (PS)
> 2) SGSN sends TMSI in "(GMM) Attach Accept"    (PS)

PS uses P-TMSI

> 3) CSCN sends TMSI in "Location Update Accept" (CS)

CS uses TMSI

P-TMSI and TMSI are in completely different namespaces.

> All these TMSIs differ.

1+2 should be the same.  '3' should be different.

> For 3), according to the RRC log, it seems that the UE expects to see the
> very same TMSI in CS that it sent to PS -- that'd be a problem. On the
> other hand, when noting that, in the Location Updating Request, the UE
> identified itself using the IMSI and not a TMSI, it may be indeed the
> correct choice to disable TMSI use for CS?

It might be the case that our network does something that implies we
support a 'combined CS+PS attach', which we don't.

In an (unsupported) combind CS+PS attach, the SGSN would send an ATTACH
ACCEPT with IEs for both TMSI and P-TMSI.

If you're looking for more information on TMSI/IMSI/P-TMSI, 04.08 is the
wrong place. Check 23.003, it contains thins like

"In areas where both MSC-based services and SGSN-based services are
 provided, some discrimination is needed between the allocation of TMSIs
 for MSC-based services and the allocation of TMSIs for SGSN-based
 services. The discrimination shall be done on the 2 most significant
 bits, with values 00, 01, and 10 being used by the VLR, and 11 being
 used by the SGSN."

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)