RAU reject cause分析

z36306610

楼主，你好，有时间讲一下RAU的流程，通过Gb口抓包分析发现reject cause主要有以下几个1、MS id cannot be derived by network 2、Network failure 3、Implicitly detached，请问这些cause值的可能原因有哪些，用什么方法去解决！先谢过！

爱卫生

回复 z36306610 的帖子

  恩。好的。这个RAU流程我会录制相关的视频并在信令流程版块介绍的。但关于RAU的规范部分对应的翻译已经完成，你可以参考TS23.060规范专区的帖子6.9 位置管理功能看下规范中关于RAU流程的说明。
  至于问题，还是先请本版版主gprssanling来回答吧。他比我这方面更有经验。呵呵，我也先谢谢他了。
  另外，你的这些案例能和大家一起分享吗？比如一些抓包啊等等。或者你也可以隐去一些信息再上传等等。论坛主要关注具体的流程、原理。不关注厂家软硬件。并且这样，也能帮你分析得更具体一些。因为有时候一些案例，光凭现象描述，只能凭经验判断可能的原因，准确定位还需要看一些抓包并做相应的测试。
  你也可以参考本版的一些其他现网case，都隐去了现网的信息，但又能让希望了解信令过程的人增进理解。
  谢谢了哈！

爱卫生

回复 z36306610 的帖子

  这里的话，我先给出规范TS24.008中关于上述你说的几种RAU失败的原因说明，如下：
- Cause value = 9 MS identity cannot be derived by the network
This cause is sent to the MS when the network cannot derive the MS's identity from the P-TMSI in case of inter-SGSN routing area update.
- Cause value = 10 Implicitly detached
This cause is sent to the MS either if the network has implicitly detached the MS, e.g. some while after the Mobile reachable timer has expired, or if the GMM context data related to the subscription dose not exist in the SGSN e.g. because of a SGSN restart.
  关于CC38=Network Faiure的情况，版块有篇帖子来描述。CC38-Network Failure。
  这里放上规范中关于RAU的信令流程。如下：

爱卫生

  结合RAU的信令流程，我先说下关于上述几个故障的我的理解，请版主"gprssanling"补充。谢谢！
  其实你说的这3种拒绝失败的cause，都是RAU比较常见的情况，但他们3个实际上有个共同点，就是和信令流程中的第2步和第3步，即New SGSN向Old SGSN去要MS的MM Context信息有关。如下：
1 MS id cannot be derived by network
  --- 这是因为在RAU的流程中，New SGSN在第4步（参见上图信令流程）要对MS做鉴权，那就必须要用IMSI做为一个输入。但RAU Request消息里，MS上报的身份信息肯定是P-TMSI。因此New SGSN将根据这个P-TMSI去向Old SGSN去要和这个P-TMSI对应的IMSI是什么，拿到以后就可以用于MS的鉴权了。因为鉴权不能用临时身份标识来鉴权。但如果Old SGSN上因为某种原因不能从P-TMSI推出这个用户的IMSI，那就走不下去了。这就是"MS id cannot be derived by network"。
2 Network failure
---- New SGSN去向Old SGSN要MM上下文的场景，发生在Gn接口，这个接口可能需要穿越运营商的IP承载网。因此，如果运营商IP承载网故障，则New SGSN无法向Old SGSN得到用户的MM上下文信息。从而无法完成第4步的鉴权。这就是"Network Failure"。
3 Implicitly detached
----- 这种情况也非常普遍。为了说明问题，做个假设。New SGSN管RA2，Old SGSN管RA1。MS来到New SGSN的RA2之前，由于在Old SGSN管理的RA1中，无线信号不好例如在地铁中，导致SGSN中的隐式去附着计时器超时，Old SGSN将把MS的MM状态标记为IDLE或PMM-DETACHED，并且在Old SGSN中会将MS/UE的信息删除。但隐式去附着是不通知用户的。MS/UE会还认为自己是和网络侧保持了连接。这时，MS/UE来到了RA2，则New SGSN会向Old SGSN去要MS/UE的上下文信息（包含了IMSI），但Old SGSN上已经没有了。自然就无法完成第4步的鉴权了。前面还提到，Old SGSN如果重启了，也可能没有MS/UE的上下文信息了。这种情况就是"Implicitly detached"。
    以上这3种情况，应该都是信令流程走到第3步，第4步的鉴权就走不下去了。New SGSN在收到Old SGSN回的SGSN Context Response消息(第2种情况Network Failure也可能收不到)，则New SGSN将给MS/UE回RAU Reject。并给出原因。

z36306610

附件是ms cant drived by network的流程，24小时的抓包数据中一个用户共发生500多次拒绝，由于流程中无法知道用户imsi，所以向这种问题有什么解决办法吗？

z36306610

忘传附件了

爱卫生

回复 z36306610 的帖子

  首先，需要说明的是，这个问题的原因是在Old SGSN（也就是RAI=460-0-25579-1对应的SGSN）上找不到P-TMSI对应的IMSI所引起的。这种情况有很多种原因，例如Old SGSN重启过，或者时间太长删除了MS的MM上下文信息等。但也有可能是3G到2G切换的RAU中，因为防火墙的问题，使得原来那个Old 3G-SGSN不能识别2G SGSN发过来的用户的P-TMSI。但有可能在Old 3G-SGSN上MM上下文并没删，但经过了防火墙后，P-TMSI的值可能变了就无法识别了。
  但这是一个个体现象。不会出现在大部分手机中。因为查了TS24.008对应的规范，可以确定这台手机没有按照规范的要求来进行设计。TS24.008 V7.1.0的4.7.5.1.4章节明确说明了MS在收到网络侧的RAU Reject消息后应该怎么做，但这台MS并没有这样执行。而是每隔15秒，不断发送RAU 请求给网络侧，然后不断的被拒绝。
  规范这么说的：
The MS shall then take different actions depending on the received reject cause value:
# 9  (MS identity cannot be derived by the network);
The MS shall set the GPRS update status to GU2 NOT UPDATED (and shall store it according to subclause 4.1.3.2), enter the state GMM-DEREGISTERED, and shall delete any P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number. Subsequently, the MS may automatically initiate the GPRS attach procedure.
   
4.1.3.2中关于GU2的说明如下：GU1代表成功Updated
GU2: NOT UPDATED
The last GPRS attach or routing area updating attempt failed procedurally, i.e. no response was received from the network. This includes the cases of failures or congestion inside the network.
In this case, the SIM/USIM may contain the RAI of the routing area (RA) to which the subscriber was attached, and possibly also a valid P-TMSI, GPRS GSM ciphering key, GPRS UMTS ciphering key, GPRS UMTS integrity key and GPRS ciphering key sequence number. For compatibility reasons, all these fields shall be set to the "deleted" value if the RAI is deleted. However, the presence of other values shall not be considered an error by the MS.
  因此正确的做法应该是，在收到网络侧的RAU Reject后应将P-TMSI，RAI信息删除，进入GMM-DEREGISTERED状态，并重新发起GPRS附着流程。如果这个MS在收到RAU Reject之后执行了附着流程，就不会有这么多RAU Reject，就天下太平了。
  另外，如果有可能，能否提供Gn口上，在Old SGSN这一侧的抓包。主要是看New SGSN给Old SGSN发SGSN Context Reuqest里面携带的P-TMSI在Old SGSN上收到的时候，是否和Gb接口上收到的P-TMSI一致。如果不一致，就证明被防火墙改了。
  当然，如果上述RAU只发生在两个2G-SGSN之间，就可以忽略防火墙的检查了。但也有可能是在Old SGSN上未配置相邻的RAI。所以最好还能提供下Gn接口的抓包。然后基本上就应该可以定位出来了。

z36306610

现在无GN接口数据，如果有GN接口数据的话如何关联Gb和GN的流程呢？根据用户的ip地址吗？

爱卫生

回复 z36306610 的帖子

RAU不涉及到会话管理，所以不能用IP地址来标识。需要用P-TMSI来关联。

gprssanling

回复 爱卫生 的帖子

关于G网路由更新的三类失败原因值：

#9 MS  identity cannot be derived by the network：由于网络无法获取IMSI导致路由更新（RAu/ISRAu）失败：
>未知的old RA。有可能是new SGSN中没有配置old SGSN的RA为协作路由区cRA。
>SGSN GMM上下文中PTMSI签名不匹配，或者PTMSI/IMSI不可知。
>GTP相关的消息错误也会引起ISRAu失败。

#10 Implicitly detached：由于用户隐式分离导致的路由更新（RAu/ISRAu）失败：
>没有附着的用户发起路由更新。有厂家SGSN支持用#10代替#9返回失败原因值，并要求MS进行附着流程。

#17 Network failure：由于网络侧失败导致路由更新（RAu/ISRAu）失败：
>HLR和SGSN之间map消息发送不正常。需要检查Gr接口状态、以及IMSI序列、GT rule、SS7 routing等配置。
>鉴权失败。TC-abort、map错误，HLR可能会发送空白消息给SGSN，需要挂表分析。
>身份验证失败。RIL3消息错误也会导致身份验证无法通过。

gprssanling

回复 爱卫生 的帖子

不要抬举偶哟。大家一起讨论嘛。

有些终端附着失败超过允许的最大次数后，会把网络列入黑名单，不再尝试选择此网络进行附着，直到下次开关机、插拔SIM卡。对于个案RAI=460-0-25579-1，CauseCode #9，路由更新失败超过允许的最大次数（<<500），应该从standby状态进入idle状态；不知为何异常，没有见过类似case。

gprssanling

回复 z36306610 的帖子

麻烦一下，我需要你这次抓包的部分文件，随便分割出来几十兆，不做筛选的，打个包，我邮箱gprssanling@gprshome.com。可以吗？

z36306610

邮件已经发了，收到了吗？

z36306610

9 MS  identity cannot be derived by the network：由于网络无法获取IMSI导致路由更新（RAu/ISRAu）失败：
>未知的old RA。有可能是new SGSN中没有配置old SGSN的RA为协作路由区cRA。
这个应该配置了，因为统计中这两个lac有rau成功的。
>SGSN GMM上下文中PTMSI签名不匹配，或者PTMSI/IMSI不可知。
这个如何理解，可以举个例子吗？

gprssanling

回复 z36306610 的帖子

没有收到你发的邮件。

z36306610

又发了一遍，收到了吗，邮件发送比较慢，方便的话QQ传也行。

gprssanling

回复 z36306610 的帖子

收到了。谢谢先。

至于CC9，P-TMSI（签名）相关的失败，平时也是isRAU更新失败的重要原因，也是它在KPI中是算做用户原因之所在。你现网中，用户路由更新请求中只上报的P-TMSI签名，oldSGSN用来验证P-TMSI签名的一致性，如果不一致，拒绝并返回CC9；也有可能由不一致引起的鉴权流程，如果鉴权不通过，拒绝并返回CC9；或者鉴权通过而在oldSGSN中为未知，拒绝并返回CC9；TLLI冲突也会导致失败返回CC9。事实上，newSGSN由于RA数据配置缺失或者错误而找不到oldSGSN，依然拒绝并返回CC9。问题是，什么情况下终端会报错误的P-TMSI签名呢？

爱卫生

gprssanling 发表于 2011-6-13 01:55
回复 z36306610 的帖子
问题是，什么情况下终端会报错误的P-TMSI签名呢？

  我个人觉得MS上报错误的P-TMSI签名可能性不大，除非是手机出现了Bug。如果排除这种现象的话，那我的假设就是MS在RAU过来的P-TMSI签名是对的，另外假设这个P-TMSI签名是A，但由于Gn接口需要穿越相对不那么可靠的IP网络，New SGSN通过SGSN Context Request消息将P-TMSI签名发给Old SGSN时，发出去是A，但Old SGSN收到却是B。这样当前就是P-TMSI签名不匹配了。但Gn接口并没有断，只是质量不好。所以不应该回Network Failure。
  我有这样的怀疑，是因为我经常在高速移动的环境中（例如高速公路的出租车上）使用GPRS上网。发现，有时是可以的，网页可以打开，但看到的文字是乱码。那这显然是在接收的时候是掉了几个bit导致的。重组不成功。
  只是个人理解。