17 Mar
2016
17 Mar
'16
11:11 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)