问：P-TMSI相关问题

yonka

P-TMSI组成有哪些呢？
网络侧下发的P-TMSI的话

SGSN 组pool情况下，下发的P-TMSI是否带NRI


什么情况下手机用P-TMSI发起附着/RAU？
什么情况下用IMSI？


关机重启后是用IMSI还是P-TMSI？
如果是核心网侧对用户发起去附着流程呢？（比如指令），是否保留P-TMSI？

P-TMSI是保存在手机中还是SIM卡中？



谢谢

爱卫生

P-TMSI组成有哪些呢？

（可以参考下SGSN POOL版块，有NRI，CS/PS位，用户标识位等，32 bit）

网络侧下发的P-TMSI的话SGSN 组pool情况下，下发的P-TMSI是否带NRI。

（带）

什么情况下手机用P-TMSI发起附着/RAU？

（非首次使用GPRS业务时）

什么情况下用IMSI？

（首次使用GPRS业务或P-TMSI被清除）

关机重启后是用IMSI还是P-TMSI？

（P-TMSI）

如果是核心网侧对用户发起去附着流程呢？（比如指令），是否保留P-TMSI？

（看厂家实现，有些厂家是保留的）

P-TMSI是保存在手机中还是SIM卡中？

（应该是手机）

yonka

爱卫生 发表于 2012-5-19 19:57
P-TMSI组成有哪些呢？ （可以参考下SGSN POOL版块，有NRI，CS/PS位，用户标识位等，32 bit）网络侧下发的P- ...

关机后不会清除P-TMSI啊？

P-TMSI在哪些情形下被清除呢？如何清除？

如果关机重启后还是使用P-TMSI的话，那是不是绝大部分情形下都使用P-TMSI附着了？要不要比较一下RA变化再选择使用P-TMSI？

爱卫生

yonka 发表于 2012-5-19 20:09
关机后不会清除P-TMSI啊？

P-TMSI在哪些情形下被清除呢？如何清除？

关机后不会清除P-TMSI啊？(不一定会清除，也可能会被清除，看厂家实现）。

P-TMSI在哪些情形下被清除呢？如何清除？（看厂家实现）

如果关机重启后还是使用P-TMSI的话，那是不是绝大部分情形下都使用P-TMSI附着了？要不要比较一下RA变化再选择使用P-TMSI？（是的，大部分是P-TMSI，和RA无关，P-TMSI只有一种。不像TLLI）。

wuwu

yonka 发表于 2012-5-19 20:09
关机后不会清除P-TMSI啊？

P-TMSI在哪些情形下被清除呢？如何清除？

网络侧手动删除用户数据的时候，下次一定使用IMSI

yonka

wuwu 发表于 2012-5-20 08:30
网络侧手动删除用户数据的时候，下次一定使用IMSI

你确定么？

我手动去附着用户后，用户还是上同一个SGSN啊。组pool的情况
说明应该是用P-TMSI撒

wuwu

yonka 发表于 2012-5-20 08:54
你确定么？

我手动去附着用户后，用户还是上同一个SGSN啊。组pool的情况

POOL的情况下没测试过，非POOL的情况下抓包过，确定；理论上感觉POOL下也应该是这样的，
即使你是POOL情况用户数据也是只存在某个SGSN啊，删除了网络上也就没了

爱卫生

yonka 发表于 2012-5-20 08:54
你确定么？

我手动去附着用户后，用户还是上同一个SGSN啊。组pool的情况

通常来讲是这样的。你可以做一个测试。就是SGSN上执行用户命令将MS的MM上下文删除，SGSN将发起去附着。这时候再在SGSN上查一遍会看到SGSN上已经没有用户的MM上下文了，也就是说网络侧都不认识这个MS的P-TMSI了，如果下次MS还携带这个P-TMSI做附着，那一定会附着失败的，因为这个值毕竟是网络侧分的，是否有效要网络侧说了算。

yonka

爱卫生 发表于 2012-5-20 11:35
通常来讲是这样的。你可以做一个测试。就是SGSN上执行用户命令将MS的MM上下文删除，SGSN将发起去附着。这 ...

这个就相当奇怪了
我确实是用gsh delete_subscriber -msidsn XXX来删除用户的
也确实看到之后MM上下文没有了，gsh get_subscriber -msisdn XXX无内容

是否指定需要重新附着对结果有影响吗？

Mr_Muscle

爱卫生 发表于 2012-5-20 11:35
通常来讲是这样的。你可以做一个测试。就是SGSN上执行用户命令将MS的MM上下文删除，SGSN将发起去附着。这 ...

我之前也做过同样的测试，对这个问题也是很困惑，我这边是在SGSN pool的环境下，我在手机附着上的SGSN删除了该手机的MM上下文，但是手机下次附着时依旧会登陆到这台SGSN上，试了多次都是这个现象。要是这个手机关机后一两天，再次附着的时候就有可能附着到pool内的其他台SGSN上了。是不是手动删除与系统自动删除MM的效果不一致呢？
还有一个问题就是：
在SGSN pool的环境下，BSC是根据用户带上来的P-TMSI中的NRI进行选择SGSN的吧？如上的测试，手机上带的P-TMSI中的NRI应该都是指向同一台SGSN的，为何在关机一两天之后会出现不一样的情况？难道过了一两天手机把P-TMSI给删除了，自己带上IMSI字段重新选择SGSN？

爱卫生

Mr_Muscle 发表于 2012-5-20 13:21
我之前也做过同样的测试，对这个问题也是很困惑，我这边是在SGSN pool的环境下，我在手机附着上的SGSN删除 ...

手动和自动删除的效果应该是一样的，结果都是在网络侧SGSN处删除了分配给MS的P-TMSI。所以，后续，如果MS还使用该P-TMSI附着，肯定会失败的。因此如果是网络侧发起的去附着流程（包括SGSN、HLR发起的），MS通常都应该要将P-TMSI删除。接下来用IMSI附着，但实际的网络中，去附着通常是MS发起，SGSN发起的去附着通常比较少，但POOL情况除外，例如POOL内部要迁移用户，做维护升级等操作，可能都会触发SGSN发起的去附着，这时候MS应该后续是用IMSI附着的。

如果MS是用IMSI来进行附着，则BSC侧是根据负荷均衡算法选择服务的SGSN并将消息分发到相应的SGSN。所以，这里应该和MS是否关机没有关系。可以看下是不是做了POOL内的相关维护操作。关机后再开机，MS应该不会删除P-TMSI，还是使用P-TMSI执行附着。

但在POOL内做迁移时，SGSN可以给BSC指明期望迁移到某个具体的SGSN上，实现有目标的迁移。

Mr_Muscle

爱卫生 发表于 2012-5-20 13:40
手动和自动删除的效果应该是一样的，结果都是在网络侧SGSN处删除了分配给MS的P-TMSI。所以，后续，如果MS ...

在SGSN pool情况下，像我之前说的现象和yonka说的现象，都说明了在删除了MS的MM后，MS仍然保留着原来的P-TMSI，这样才能解释为何MS再次附着时会登陆到同一台SGSN上，像您说的，在SGSN删除MM后，网络侧没有关于这个MS的用户信息，但是网络侧仍然可以向MS要求上传IMSI，然后再根据IMSI去索取用户的签约信息，还是可以继续附着到这台SGSN上。
还有就是在SGSN进行用户拆卸或者迁移操作时，它应该是通过重新附着的用户携带NNRI来让RAN 根据‘load balance’算法选择的，不是用户重新附着带IMSI来实现的，至少我们这边的厂商是这么实现的。

yonka

爱卫生 发表于 2012-5-20 13:40
手动和自动删除的效果应该是一样的，结果都是在网络侧SGSN处删除了分配给MS的P-TMSI。所以，后续，如果MS ...

看到有个说法是规范中说明P-TMSI在RA内唯一，离开该RA后则由RAI+P-TMSI共同进行唯一标识。
那么如果关机后MS不清楚P-TMSI的话，开机重启附着时...仍使用原来的P-TMSI？

yonka

“(1) 如果用户没有合法的P-TMSI，用户会带上IMSI；如果用户有合法的P-TMSI用户应该使用P-TMSI和配对的路由区标识。”

这里“匹配的RAI”的说法是指P-TMSI与RAI在MS中是对应的么？

爱卫生

Mr_Muscle 发表于 2012-5-20 13:58
在SGSN pool情况下，像我之前说的现象和yonka说的现象，都说明了在删除了MS的MM后，MS仍然保留着原来的P- ...

建议抓包验证看MS有没有删。我的观点没有变，网络侧删除MM上下文后，应该MS是要删的。因为如果MS没有删，则MS使用P-TMSI附着的同时，还会带上old rai，由于MS的位置没有发生变化（假设是原地开机关机，没有位置移动），那old rai也是当前SGSN分配的，也就是SGSN意识到自己是这个RA的管理者，但却不认识对应的P-TMSI。这时，SGSN不会去向MS要IMSI了，而是会直接拒绝。因为是有矛盾的，MS说我在你的RA下你给我分配了P-TMSI，但SGSN发现RA是我管的，但对应的P-TMSI却查询不到，因此按照正常的逻辑是要拒绝的，不管是出于安全考虑，还是加强网络侧控制的角度。同样的道理，在附着流程中，new sgsn给old sgsn发送indentification request消息中，也是要求携带old RAI的，这也说明old rai也是作为一个查询条件的。

   另外，经过验证，如果是在SGSN（某厂家）上手动删除用户的MM上下文，则SGSN会发起去附着请求给MS，并且携带的是CC7（GPRS Service not allowed），按照TS24.008章节4.7.4.2.2的说明，MS如果在去附着中收到了CC7，应该执行以下流程：

# 7  (GPRS services not allowed);  The MS shall set the GPRS update status to GU3 ROAMING NOT ALLOWED (and shall store it according to subclause 4.1.3.2) and shall delete any P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number. The SIM/USIM shall be considered as invalid for GPRS services until switching off or the SIM/USIM is removed. The new state is GMM-DEREGISTERED.

按照上述说明，也说明了MS应该删除P-TMSI、RAI等参数。并且可能需要重新开机才可以。

关于迁移用户，可能误解了。我并没有说靠MS用IMSI来附着实现，但也没说得太清楚。通常是在MS附着时，SGSN为MS分配一个non-broadcast RAI并设置一个很短的T3312时间（默认可能是4秒），使MS在很短时间内意识到RA不同，执行RAU流程，再由BSC/RNC来根据一定的比例重新选择SGSN。

Mr_Muscle

爱卫生 发表于 2012-5-20 15:01
建议抓包验证看MS有没有删。我的观点没有变，网络侧删除MM上下文后，应该MS是要删的。因为如果MS没有删， ...

对于在SGSN pool下，手动再网络侧删除MM上下文，我拿了3个手机来测试，并且进行多次测试，都是发现手机再次附着时登陆到之前的SGSN上，个人觉得这个都只能用手机再次附着时是用P-TMSI来附着才能解释的通，至于您说的抓包检验MS有没有删除P-TMSI，是指用电脑通过手机上网，然后在电脑上打开wireshark进行抓包，当在网络侧删除了MM后，检查手机有没有收到网络侧发起的去激活流程？
向您从规范中指出的这个CC7，在手机欠费的时候网络侧会发起这个流程，但是在网络侧删除MM时，网络侧不会发送这个CC7给手机吧，因为我测试的三个手机都是正规的手机，在网络侧删除掉MM后再次激活，根本不需要重新开关机或者拔掉SIM才能继续上网，而是直接可以上网了。

爱卫生

Mr_Muscle 发表于 2012-5-22 10:45
对于在SGSN pool下，手动再网络侧删除MM上下文，我拿了3个手机来测试，并且进行多次测试，都是发现手机再 ...

结合你看到的现象和我原来做的实验以及再查找了下规范，理解如下。

1）先说下我看到的实验现象：

  正规手机，正规SGSN。

手机正常激活，看视频。SGSN上删除MS的MM上下文触发去激活和去附着流程，detach request消息里携带了GMM Cause 7。手机上看到的现象是视频中断。然后MS无法发起后续的附着流程，即没有任何消息发出，自然也不能执行PDP激活了。将MS关机开机后，重新附着（这时看到是用IMSI做的附着）再激活后，又可以看视频了。

2）规范：

    仔细查了，TS24.008中，detach request消息里的GMM Cause实际上是一个可选的字段，我用的SGSN正好携带了CC7，当然不带Cause code也是符合规范的。而如果MS收到了CC7，是一定要删除P-TMSI的（TS24.008的4.7.4.2.2中有明确说明）。但如果你用的SGSN没有回CC7或根本就没有带GMM Cause，MS是可以保留P-TMSI的。因此，这个和SGSN的厂家以及软件版本有关系。如果MS没有删除P-TMSI，后续附着仍然用P-TMSI附着到同一个SGSN，就不足为奇了。如果你能抓到包，不是在电脑和手机侧抓，如果你有权限的话，在SGSN侧抓，或看log或对单个用户追踪，主要是看attach request是否带了P-TMSI，并且看detach request里是否带了GMM Cause，如果带了的话，是多少？

   除了CC7以外，还有一些CC，MS收到后也要删除P-TMSI，例如CC6等等。具体请参考TS24.008的4.7.4.2.2。

  

   所以，总结一下，你看到的现象可能是对的。我看到的现象可能也是对的。都是符合规范的。不用纠结。关键是detach request里的GMM Cause值。就真相大白了。MS看起来是符合规范的。