CC9-MS Identity cannot derived by the network(网络无法获取用户身份)案例分享

爱卫生

   本案例分享的是一个现网CC30-由GGSN拒绝的激活的例子。
一 故障现象
用户发起RAU失败。CC原因为9，代表MS Identity cannot derived by the network(网络无法获取用户身份)。如图一所示。

图一 CC9的故障现象

二 故障分析过程
   通过CHR日志的失败原因看，对应“网络无法获取用户身份”的失败原因是“DNS_RSP_INFO_ERROR” 。
SGSN根据旧路由区构造域名到DNS解析MS之前所在的SGSN，但是解析不到。分析CHR日志发现，这种失败的用户携带的OLD RAI都不是中国联通的RAI，DNS上不会配置，所以解析错误，解析失败信令流程图如下：

图二 失败的信令流程图

   利用网优平台梳理出这类失败原因的RAI，以2010-9-26 10:20～11:20 RAU数据为例，解析失败的路由区主要是以MCC/MNC 45400，45403，45404，45406，45416，45419，46000开头的路由区，他们分别是来自香港的CSL，3HK，Orange，SmartTone，PCCW的路由区和中国移动CMCC的路由区，统计结果如下：

图三 他网路由区更新比例分布情况

图四 RA失败统计

    其中46001开头的路由区，例如46001A53602归属联通网络，需要进一步检查分析。路由区02归属SZ，在SZ-SGSN中的PAGING范围列表中查询位置区A536不存在，无线优化和规划的台账也没有查到位置区A536信息。导出SZ基站后台数据，发现存在该LAC区，其所属基站是RNC15，站点名称是“布吉铁西路”。经过无线配合检查，布吉铁西路应该配置LAC=A535，代维错配成了A536，已要求无线侧修改错配信息。下面是导出的现网无线侧配置信息表截图，建议无线侧将SZ全网基站后台数据导出和规划台账进行核对，排查路由区信息的错配、漏配的情况，减少失败的发生。

danes

版主想问下，像那种RAU请求中带的是异网RAI导致DNS解析错误而返回的RAU拒绝失败，你们是怎样解决啊？

爱卫生

danes 发表于 2011-7-2 16:05
版主想问下，像那种RAU请求中带的是异网RAI导致DNS解析错误而返回的RAU拒绝失败，你们是怎样解决啊？

  想问下异网RAI是指的同一个PLMN的Old RAI吗？因为RAU和附着不一样，附着有可能会涉及到不同国家的PLMN之间SGSN的交互。而RAU不会，一定是同一个PLMN的运营商之内的节点间的交互。移动和联通之间也不会发生RAU，如果用户从移动的小区覆盖移动到了联通的小区覆盖范围，则要做PLMN的重新选择重新选网啦。
  而一个PLMN内部的两个SGSN之间的切换，如果DNS解析导致的RAU拒绝。则需要去定位下问题，如果是到DNS Server的IP网络故障，可以用traceroute、ping等工具来初步定位下是哪一个节点的问题。如果IP承载网恢复不了，则SGSN上也是可以定义RAI和SGSN的静态配置的。可以临时解决问题。
  个人观点，谨供参考。

danes

爱卫生 发表于 2011-7-4 20:24
想问下异网RAI是指的同一个PLMN的Old RAI吗？因为RAU和附着不一样，附着有可能会涉及到不同国家的PLMN之 ...

版主，我说的异网的RAI并不是同一个的PLMN的RAI，是版主文中提到的例子中的那种情况“分析CHR日志发现，这种失败的用户携带的OLD RAI都不是中国联通的RAI，DNS上不会配置，所以解析错误”，下图中就是就是这种情况，不清楚手机因没有因接收到拒绝的消息，而每个15秒重复一次RAU请求；还是因为手机没有按协议设计导致接收到决绝消息（原因为“隐式分离”）而没有发起附着流程。针对这种情况，版主是怎样解决？

爱卫生

回复 danes 的帖子

  上述是个转载帖。我觉得不错就转载到论坛了。并不是我做的，所以我只能说下我的看法和思路。
  首先，关于异网RAU中的RAI解析。首先要了解下异网RAU的场景，RAU是用户走着走着，（当然也可能是高速移动例如火车等）然后来到了另外一个PLMN的RA，所发起的RAU。因此，即使跨了PLMN的RA，但实际上这两个PLMN的RA在物理位置上非常相近的。就像例子中提到的排名第一位的异网RAU来自于PLMN中国移动。这很明显，是用户移动中，离开了中国移动的小区覆盖来到联通的小区覆盖所发起的RAU。后面几位异网RAU的统计都来自香港，因此这很可能是用户在深圳罗湖和香港边界乘坐地铁所导致的。
  但异网RAU不用怎么处理，因为这不是一个问题。中国移动和中国联通肯定没签漫游协议。所以被拒也应是正常的。即使签了漫游协议，RAU被拒以后，按照流程规范TS24.008 V7.1.0的4.7.5.1.4章节明确说明了MS在收到网络侧的RAU Reject消息后应该怎么做，摘录如下：
"
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，就天下太平了。
  但确实有很多手机是这样，和你的截图是完全一样的。每次间隔15秒重发RAU，最后被拒。
  当然，一个折中的解决方案就是在DNS Server上将和联通签了国际漫游的运营商相邻的RAI配置进去，这也不多。例如在深圳SGSN上，增加几个边界上和香港CSL的RAI的配置就可以解决问题。也不会带来运维的负担。
  可以参考下这个帖子RAU reject cause分析。里面还有一个和你截图一样的抓包文件。
   以上是个人理解，谨供参考哈！