3G用户在某LAC下频繁attach，且每次都能成功，但不能正常上网的问题请教

info195

问题：
用户为3G终端，在某个LAC下(其它位置均正常)，基本每隔20s中就会重新附着到网络，用户在Gb口信令上看，频繁的附着流程且均成功完成，无其它任何信令；
根据SGSN上跟踪的信令来看现象为：
用户附着完成后20s左右，收到HLR发送的“cancel-location-arg”消息，类型为“updateProcedure”，随后SGSN删除了用户MM上下文，再经过20s左右，又收到了MS发送的identity-response消息，之后就开始了第二次附着，如此反复的。
为什么只有identity-response消息但并没有identity-request消息。
有几个疑问：
1.这个identity-response怎么来的？什么情况，不会是消息没跟全吧(但是pool内的每个SGSN都同时跟了用户信令，只有一个SGSN有数据)
2.为什么HLR发送cancel-location-arg？难道是用户又在另外一个SGSN上注册或检查到用户数据不正常了？
3.网络侧应该是隐式分离了用户，用户并不知道自己已经分离(网络侧没通知用户)，那手机为什么会再次附着请求的呢？

麻烦各位专家帮忙看看，谢谢！

hycl5410

1.这个identity-response怎么来的？什么情况，不会是消息没跟全吧(但是pool内的每个SGSN都同时跟了用户信令，只有一个SGSN有数据)
这个user_trace是以IMSI做索引的吧？那么当ATTACH/RAU带上来的是P-TMSI（非本SGSN分配，SDB无该P-TMSI和IMSI映射关系的数据）时，就会抓不到ATTACH/RAU req和identity-req。

2.为什么HLR发送cancel-location-arg？难道是用户又在另外一个SGSN上注册或检查到用户数据不正常了？
一般应该是inter RAU到其他SGSN才会导致HLR发cancel-location

3.网络侧应该是隐式分离了用户，用户并不知道自己已经分离(网络侧没通知用户)，那手机为什么会再次附着请求的呢？
如果第二次的信令发的是RAU还好理解一些，发ATTACH确实比较诡异。。。

我的分析是这样的：
比较可能的情况是由于无线规划等原因造成UE在该区域乒乓RAU。

HLR发cancel-location分析：
inter-RAU到其他SGSN。这里有一个地方开始让我也很困惑--如果是inter-RAU，为什么看不到GN的sgsn-ctx-req？注意到楼主提到了pool，那么一个可能性就是UE ATTACH的SGSN（抓包的这个）恰巧不是pool里的那个gateway SGSN（不知道这个叫法对不对，但是我确实不知道叫啥），sgsn-ctx-req是发给gateway SGSN的（DNS解析old RAI只会解析到gateway SGSN的GTP-C地址），而sgsn-ctx-req带的是old P-TMSI而不是IMSI，所以在gateway SGSN上用IMSI索引是抓不到sgsn-ctx-req的。

下一步怎么查：
如果条件允许的话，交换机上抓IU-C和GN-C，通过已经注册的P-TMSI来过滤出属于这个用户的相关信令（ATTACH/RAU,sgsn-ctx-req,sgsn-ctx-resp）。过滤出相关的old P-TMSI，old SGSN GTP-C地址等，在对照网络规划搞清楚到底UE这个过程中都在干什么。然后进一步分析到底是无线规划方面出现了问题，还是SGSN自己有问题。

交换机抓包不可能的话，开工单找支持，也许打开内部跟踪（某个软参），然后有会读内部跟踪的人也许会能找到一些线索。

hycl5410

如果第二次的信令发的是RAU还好理解一些，发ATTACH确实比较诡异。。。
如果从这个有抓包的SGSN出去到另外SGSN发的RAU被reject了（时间点大概在11:27:17），那么11:27:35发的是ATTACH就对了，可是又无法解释为什么会有identity呢？按说这时的old P-TMSI还是有效的啊（抓包里第一个ATTACH CMP分配的P-TMSI）？

有点怀疑是不是pool区RAI和非pool区RAI之间发生了RAU。不管如何，把ATTACH/RAU REQ抓到了，一切就都有进一步的线索了。
补充一下，如果交换机抓包不可行，也可以尝试问问RNC是否能针对该UE抓包。

hycl5410

ATTACH/RAU REQ抓到了之后看什么？
当前RAI,OLD RAI，pool区非pool区？属于哪个SGSN？
old P-TMSI，带不带正确的NRI？

建议楼主对ATTACH CMP消息里分配的P-TMSI也检查一下，看看带不带正确的NRI？

这个case挺有意思，希望得到最终结果之后楼主会结贴告知。多谢！

hycl5410

如果从这个有抓包的SGSN出去到另外SGSN发的RAU被reject了（时间点大概在11:27:17），那么11:27:35发的是ATTACH就对了，可是又无法解释为什么会有identity呢？按说这时的old P-TMSI还是有效的啊（抓包里第一个ATTACH CMP分配的P-TMSI）？
这个分析是错的，如果reject了，就不会有HLR的cancel location了。
不乱猜了，拿到完整抓包再说吧

info195

非常感谢hycl5410的分析。
1.这个trace确实是以IMSI做跟踪的，但是如果“那么当ATTACH/RAU带上来的是P-TMSI（非本SGSN分配，SDB无该P-TMSI和IMSI映射关系的数据）时，就会抓不到ATTACH/RAU req和identity-req”，但是我从chr的日志上来看，存在前后2次attach(间隔20s)都在一个SGSN上，仍然是只看到identity-resp。
2.从iu口的信令数据统计来看，用户只有每隔20s的attach请求，并无RAU或其他的MM消息。而且每次attach基本是随机的在pool内的几个SGSN上处理。
另外有个奇怪的现象就是CHR的日志里，记录的每次attach均有old SGSN地址，应该可以说明用户attach req应该带的是P-TMSI吧，那每次(间隔20s)用户为什么又发起attach请求呢，请指教

hycl5410

既然有CHR，那么何不把相关信息都拿出来看看呢？

当前RAI,OLD RAI，pool区非pool区？属于哪个SGSN？
old P-TMSI，分配的P-TMSI，带不带正确的NRI？

另外一个很重要的事情是，只有这一个用户在该LA下存在这样的问题，还是所有用户的普遍问题？
是否换USIM卡和换终端测试过？

信息不全没有办法继续分析的。。。

hycl5410

又想到一点，有没有试过将测试UE detach掉（UE主动关机比较好，最好也拔一下卡）之后所有SGSN都RMV USR然后再重新测？

info195

这个RAI下的用户均是相同情况，从CHR的记录看，用户携带的P-TMSI均为FFFFFFFF，不是有效的P-TMSI，这是什么原因呢，

hycl5410

老大你开工单去查吧。。。
实在是没法分析，我又不能管你要所有我想要的log...
找支持的人吧，给他们所有他们要求的log然后等回复吧。
希望查清楚之后能结个贴说一下到底是怎么回事。

info195

是没配置3G寻呼表，但是不知道终端为什么会重复附着

hycl5410

是好奇怪。。。不配的话按说attach就直接reject了。R10以上版本接触很少。。。