问：P-TMSI相关问题

爱卫生

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 20:09
关机后不会清除P-TMSI啊？

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

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

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

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

爱卫生

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

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

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

爱卫生

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: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-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看起来是符合规范的。