CC29 User authentication failed 对应Gn接口CC209用户认证失败 案例

爱卫生

   以下为现网实例来介绍CC29。用户认证失败这个Cause Code。其中CC209是Gn接口的Cause Code，对应Gb接口的CC是29。
   图一：
   IUPS接口：Activate PDP Context Reject所带的原因为29 User authentication failed

   图二：

   Gn接口：Create PDP Context Response所带的原因为209 User authentication failed

   对应的信令流程如下：

图例：CC29的PDP激活流程

- MS (IMSI 460019202745037) 向SGSN发起Activate PDP Context Request；
- SGSN向GGSN发送的Create PDP Context Request，用户计费类型为预付费；
- GGSN返回Create PDP Context Response，携带原因值User authentication failed（209）；
- SGSN向MS发送Activate PDP Context Reject消息，携带原因值为User Authentication Failed(29)。

    综上所述，预付费用户欠费或过期是导致PDP激活失败的原因。

优化建议：

   利用网优平台提取发生“用户鉴权失败”的用户，整理出欠费用户清单，提交给市场部门参考。

yonka

回复 爱卫生 的帖子

问一下，认证失败的话一定是欠费吗？
有没有其他原因？

yonka

回复 爱卫生 的帖子

还有就是你这样的解释很容易让人产生一种感觉：
CC29就是来自CC209~

可是在激活PDP请求阶段，SGSN不是也会对用户进行鉴权么？如果鉴权失败的话是不是也应该返回CC29？

还是SGSN只在attach时对用户鉴权而在激活PDP请求时不鉴权?

爱卫生

yonka 发表于 2011-11-18 15:59
回复 爱卫生 的帖子

问一下，认证失败的话一定是欠费吗？

  除此之外，还有一些企业APN也是需要认证的。例如银行、电力等。认证通过了，PDP激活才能成功。

爱卫生

yonka 发表于 2011-11-21 00:47
回复 爱卫生 的帖子

还有就是你这样的解释很容易让人产生一种感觉：

1 CC29基本上确实从CC209来的。基本可以对应。只不过前者是MS---SGSN侧的Cause code，后者是Gn口的Cause code。分别在TS24.008和TS29.060中定义。
2 你误解了一个概念。对GPRS网络的鉴权和对APN网络的认证。前者是SGSN做的，后者是Gi接口后面的RADIUS服务器做的。前者的鉴权是对用户接入GPRS网络的验证，附着就要做。后者是对PDN网络的认证，看用户有没有访问这个APN网络的权限。举例来说就是，大部分手机只要IMSI没有被仿冒以及开通了GPRS业务，基本上都能和SGSN鉴权成功接入到GPRS网络来。但只有极小部分的终端（例如ATM机）可以完成银行这个APN网络的认证从而接入到银行的内网里面来，这个认证是由RADIUS来做的。
   所以这是两个词汇，鉴权是用于识别用户身份是否假冒，认证是看用户有没有访问网络的权限。也就是说前者做的就是证明你是谁，后者是确认你的权限能做什么。

DUT_RAY

爱老板最后的总结非常给力，学习之~

爱卫生

        这里放上产生CC29对应的信令流程。

（1）MS发送Activate PDP Context Request消息给SGSN，消息中包含了用于外部PDN网络鉴权的用户名、口令。

（2）SGSN向GGSN发起Create PDP Context Reuqest消息用于为MS请求建立到某个PDN网络的连接，并将用于外部PDN网络鉴权的用户名、口令透明传递给GGSN。

（3）GGSN向位于PDN网络的RADIUS服务器发起Access Request消息用于请求对MS进行鉴权。

（4）RADIUS给GGSN返回Access Reject消息，通知GGSN，关于MS的鉴权失败。

（5）GGSN给SGSN返回带有GTP原因代码CC209的Create PDP Context Response消息，通知SGSN是因为外部PDN网络鉴权失败的原因导致的PDP上下文激活失败。

（6）SGSN给MS发送带有CC29的Activate PDP Context Reject消息拒绝MS本次的PDP上下文激活。

姚丹1988

学习了

onlyybj

爱总 有没有实例 讲解下CC32_33啊！32和33里的SPAI

爱卫生

onlyybj 发表于 2012-6-4 13:24
爱总 有没有实例 讲解下CC32_33啊！32和33里的SPAI

33有啊！http://www.gprshome.com/forum.php?mod=viewthread&tid=44&extra=page%3D1。
32比较少见，代表MS请求的业务该PLMN不支持。可能是在国际漫游的场景吧，有些业务是归属地PLMN支持，但拜访地PLMN不支持，可能就会回这个。但这个是个人理解，我没有CC32的报文！

爱卫生

onlyybj 发表于 2012-6-4 13:24
爱总 有没有实例 讲解下CC32_33啊！32和33里的SPAI

这里有一个CC32。
http://www.gprshome.com/forum.php?mod=viewthread&tid=288&page=1#pid11594
是因为SGSN上的IPV6功能关闭了，而MS请求的PDP type是IPV6，所以SGSN没转给GGSN处理，直接拒绝了PDP激活，并携带CC32。代表当前PLMN不支持IPV6。

onlyybj

爱卫生 发表于 2012-6-4 20:24
33有啊！http://www.gprshome.com/forum.php?mod=viewthread&tid=44&extra=page%3D1。
32比较少见，代表 ...

谢了 爱总

onlyybj

爱卫生 发表于 2012-6-4 20:29
这里有一个CC32。
http://www.gprshome.com/forum.php?mod=viewthread&tid=288&page=1#pid11594
是因为 ...

现在CC32_33是一个统计项，每小时几千个。。。影响含用户原因的PDP激活成功率

爱卫生

onlyybj 发表于 2012-6-5 14:21
现在CC32_33是一个统计项，每小时几千个。。。影响含用户原因的PDP激活成功率

CC33是用户原因啊，有很多是正常的。需要协调用户解决。

但CC32不应该有太多，应该是可以解决的。应该CC33比CC32要多很多吧！

onlyybj

爱卫生 发表于 2012-6-5 19:19
CC33是用户原因啊，有很多是正常的。需要协调用户解决。 但CC32不应该有太多，应该是可以解决的。应该CC3 ...

是啊 统计的是32和33一起的sum，没注意单个统计的

ccc123

学习了，非常感谢。。。