51学通信技术论坛

 找回密码
 立即注册
搜索
查看: 7790|回复: 14
打印 上一主题 下一主题

pdp激活成功后较短时间网络侧去激活 [复制链接]

Rank: 2Rank: 2

跳转到指定楼层
楼主
发表于 2011-9-21 11:46:56 |只看该作者 |倒序浏览
一键分享 一键分享
现在遇到另外一种case比较奇怪,pdp激活成功后很短的时间内网络侧发起去激活,出现这种情况均是外地上网卡(北京的数据卡最多),怀疑几种可能性。1、用户欠费,某些省份为做指标对于欠费用户允许pdp激活成功,但很快会去激活?(不知有这个情况没),但通过traffic发现这些用户一天中也有几次pdp激活成功后做业务(这个用户一天总共pdp激活去激活大概5000次),由于是漫游用户所以无法查询是否欠费。
       2、radius 服务器问题,pdp激活成功后ggsn与wap网关之间有radius过程,如果这个过程不成功的话网络侧会发起去激活,前提是pdp激活是3gwap,用户的apn设置为空,gn口看到create pdp消息中sgsn分配的3gnet,所以比较奇怪?
附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册

Rank: 9Rank: 9

懒

沙发
发表于 2011-9-21 23:40:51 |只看该作者
回复 z36306610 的帖子

  能不能再做一些确认呢?我说下我的理解。
  首先确认下这个网络侧发起的去激活是HLR发起的、SGSN发起的还是GGSN发起的。然后再去做定位。因为在你的抓包里没有看到GGSN发给SGSN的delete pdp context request消息,如果包都齐的话,那这个网络侧发起的去激活就不是GGSN发起的。但你说的两种原因,例如欠费或者RADIUS服务器的问题,都应该是GGSN发起的去激活。但又没看到有抓到的包。欠费发起的去激活,是针对预付费的用户(通过PDP激活请求消息里的CC可以知道这个用户是个预付费用户),用户在访问具体业务的时候,GGSN向OCS申请额度,但因为欠费没有额度了。所以发起了一个去激活(但又没有看到有用户面的包)。如果是RADIUS的问题,分成两种,如果是access request消息,则激活都不会成功。如果是accouting request消息,应该不会造成去激活。
  你说的某些省份追求激活成功率指标而放欠费用户激活,是有可能的,但设备是机器是死的。GGSN怎么感知到这个用户欠费的呢?由于是预付费的用户并且需要感知到这个用户欠费。因此,肯定在Gy接口和OCS有交互消息,不知道能否抓到。(不过联通是回归属地GGSN激活,可能不太好抓,但至少SGSN上应该能抓到GGSN过来的delete pdp context request消息)
  最后,发现去激活的原因是CC36 regular deactivation,所以并不是由网络故障引起的。正常的去激活。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

板凳
发表于 2011-9-22 09:55:07 |只看该作者
不好意思GN数据忘记关联进去了,deactivate pdp是GGSN发起的
附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册

使用道具 举报

Rank: 2Rank: 2

地板
发表于 2011-9-22 09:56:45 |只看该作者
不好意思GN接口忘记关联进去,PDPdeactivate是由GGSN发起的,这些用户均是外地上网卡
附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册

使用道具 举报

Rank: 2Rank: 2

5#
发表于 2011-9-22 10:20:23 |只看该作者
联通策略是不是欠费attach的时候就应该拒绝了呢?

使用道具 举报

Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7

版主

6#
发表于 2011-9-22 14:16:48 |只看该作者
北京的无线上网卡欠费也是能激活的,只是做不来业务。而且会发短消息告知用户已经欠费了。

SM Cause: Regular deactivation (36)是正常的去激活,不是网络层发起的去激活。多和终端相关。

没有看到radius消息呢?

使用道具 举报

Rank: 2Rank: 2

7#
发表于 2011-9-22 14:38:50 |只看该作者
激活cmwap不需要radius吧?

使用道具 举报

Rank: 9Rank: 9

懒

8#
发表于 2011-9-22 22:32:35 |只看该作者
z36306610 发表于 2011-9-22 10:20
联通策略是不是欠费attach的时候就应该拒绝了呢?

   这个我觉得肯定不会,一般运营商不会这么傻。有钱不去赚。通常的做法是,附着让你成功,在做PDP激活的时候也让你成功。这样两个重要指标都不影响。但在你访问具体业务的时候,将你的流量重定向到一个交费的页面,告诉你余额不足。要你充值后使用。
  另外,如果要在附着阶段就因为欠费而拒绝用户附着,从技术角度来看。只有可能是在HLR上做这个的用户数据,将他的PS业务关闭。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 9Rank: 9

懒

9#
发表于 2011-9-22 22:34:51 |只看该作者
z36306610 发表于 2011-9-22 14:38
激活cmwap不需要radius吧?

   激活cmwap可能不需要radius的鉴权功能,即access request消息。但accouting request消息一定有,这是用作计费目的的。但没看到抓到的包里有。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

10#
发表于 2011-9-23 08:44:23 |只看该作者
access request消息。这条消息是在Gi接口的吗?

使用道具 举报

Rank: 9Rank: 9

懒

11#
发表于 2011-9-23 21:09:05 |只看该作者
z36306610 发表于 2011-9-23 08:44
access request消息。这条消息是在Gi接口的吗?

  是啊。RADIUS的消息都在Gi口。但如果是透明接入的业务例如cmwap里边的很多业务,都不需要做鉴权,所以也就没有access request消息了。但accouting request消息是用于计费目的的,所以应该还是有的。

点评

onlyybj  #36 Regular deactivation包含下面2个原因 40 Removal of Subscription data in HLR GSM, WCDMA Deactivate success 240 Signaling interference WCDMA Deactivate success  发表于 2012-6-13 15:29:01
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

12#
发表于 2012-6-12 17:51:37 |只看该作者
爱卫生 发表于 2011-9-23 21:09
是啊。RADIUS的消息都在Gi口。但如果是透明接入的业务例如cmwap里边的很多业务,都不需要做鉴权,所以也 ...

#36不是心灵干扰 和HLR 移除用户说明信息么?

点评

爱卫生  没有啊。就是一个正常的去激活原因代码。  发表于 2012-6-12 19:48:10

使用道具 举报

Rank: 9Rank: 9

懒

13#
发表于 2012-6-13 20:59:25 |只看该作者
onlyybj 发表于 2012-6-12 17:51
#36不是心灵干扰 和HLR 移除用户说明信息么?

谢谢!不过这个是厂家的特性吧!至少TS24.008里没有这样说的。而且HLR移除用户签约数据一般是在欠费情况下,这种情况通常是CC7的,至少不应该CC36吧。能否提供详细点的说明呢?包括信令干扰这个原因,有点笼统了!

www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

14#
发表于 2012-6-14 10:22:57 |只看该作者
爱卫生 发表于 2012-6-13 20:59
谢谢!不过这个是厂家的特性吧!至少TS24.008里没有这样说的。而且HLR移除用户签约数据一般是在欠费情况下 ...

哦 我也是看alex里有这个CC36的,前几天也遇到过然后在alex里查的,问了下hlr,
他们说也有可能有这种原因,但是他们解释在相当特定的条件下会出 ,说的我没明白!

使用道具 举报

Rank: 3Rank: 3Rank: 3

15#
发表于 2012-12-23 18:18:31 |只看该作者
attach 和 PDP 都让它通过,在访问业务的时候才提醒欠费,这种策略会不会浪费无线侧很多资源呢?

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-5-6 00:34 , Processed in 0.035857 second(s), 14 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部