51学通信技术论坛

标题: 求助爱立信SGSN关于失败counter的问题 [打印本页]

作者: lizq8285 时间: 2011-6-13 15:49:14 标题: 求助爱立信SGSN关于失败counter的问题

当GGSN返回的GTP的cause：#211 All dynamic PDP addresses occupied#199 No resource available收到后SGSN会下发reject给ms，那么SGSN的记录的对应的counter是哪个啊？或者说失败码？

作者: lizq8285 时间: 2011-6-13 15:56:35

SM.UnsuccActPdpContextCC26.G

This measurement provides the number of unsuccessful primary PDP context Activation procedures per SGSN due to cause code 26 (Insufficient resources). The reject can be caused due to, for example, sustained high processor load on one or more GPBs or IBxxs (used as AP) handling signaling.
这个是对应211还是199呢？

作者: 爱卫生 时间: 2011-6-13 16:07:03

lizq8285 发表于 2011-6-13 15:56
SM.UnsuccActPdpContextCC26.G

This measurement provides the number of unsuccessful primary PDP co ...

这个是对应CC211的。有包为证。#3中GGSN回了一个Create PDP Context Response，带的CC就是199，在Gb接口的#4号包中，SGSN就回了一个Activate PDP Context Reject,CC为26。
以上设备是爱立信SGSN。供参考。[attach]444[/attach]

作者: lizq8285 时间: 2011-6-13 16:24:14

你刚刚发的附件包我看到了，是211的cause啊。那#199 No resource available呢？？也是归类到cc26吗？

作者: lizq8285 时间: 2011-6-13 16:27:07

在线等答复。。

作者: 爱卫生 时间: 2011-6-13 16:39:58

lizq8285 发表于 2011-6-13 16:24
你刚刚发的附件包我看到了，是211的cause啊。那#199 No resource available呢？？也是归类到cc26吗？

是的。我这有CC199的包。但可惜的是Gb接口的加密未去掉。因此看不到内容。但这个CC199的包是由于GGSN上的PDP上下文限制数超出而抓到的。这和CC26的定义是吻合的。所以是归到CC26.

作者: lizq8285 时间: 2011-6-13 16:58:03

有199的信令包吗，给我下行吗？

作者: lizq8285 时间: 2011-6-13 17:00:05

我现在要的资料就是要证明211和199都归类到一起了，

作者: lizq8285 时间: 2011-6-13 17:01:40

由于我们在gn口统计到的211和199的错误码有点大，但是呢SGSN上的countercc26却跟我们的统计有很大的出入啊！！顺便问下坛主，这是怎么回事呢？

作者: 爱卫生 时间: 2011-6-13 17:03:10

本帖最后由爱卫生于 2011-6-13 19:50 编辑

回复 lizq8285 的帖子

  没问题。我先把包给你哈。[attach]445[/attach]
  这个CC211和CC199(GTP协议的Cause Code）是可以对应到到CC26（Gb接口的Cause Code)的。因为：
1 CC211你已经通过包看到了。在Gb接口就是通过CC26告诉MS的。
2 关于CC199，这个包是我抓的。方法很简单，就是在GGSN上设置将GGSN上的PDP上下文限制设置1，然后用2台手机去做激活。就得到了这个CC199。然后，你再去查文档，会发现对CC26的描述是：“This measurement provides the number of unsuccessful primary PDP context Activation procedures per SGSN due to cause code 26 (Insufficient resources). The reject can be caused due to, for example, if the hard limit for maximum number of PDP contexts is reached. ”
  另外有一些CC，也可以关注啊有个专区“Cause Code大全”版块！也期待你的分享哈！{:soso_e100:}

作者: 爱卫生 时间: 2011-6-13 19:57:34

lizq8285 发表于 2011-6-13 17:01
由于我们在gn口统计到的211和199的错误码有点大，但是呢SGSN上的countercc26却跟我们的统计有很大的出入啊！ ...

你的意思是说Gn接口的CC211和CC199加起来的统计，要远远比SGSN上的CC26的计数器值要得多吗？

作者: lizq8285 时间: 2011-6-13 21:42:42

是啊，这个问题比较怪异喔。

作者: lizq8285 时间: 2011-6-13 21:43:43

SGSN上的CC26的计数器的机制是怎么样的？

作者: 爱卫生 时间: 2011-6-13 21:53:40

本帖最后由爱卫生于 2011-6-13 22:22 编辑

回复 lizq8285 的帖子

那确实比较奇怪哦。关于CC26的计数机制我没有准确的文档，不敢乱说哦。看gprssanling大侠有什么要说的。
但不对呀，SGSN上应该没有GTP的CC199和CC211的计数器才对呀。你说的CC199和CC211应该是在GGSN上采集的吧。那这两个值加起来和SGSN上的CC26的值肯定不一定相等啊。一个SGSN可以对应多个GGSN啊。

作者: lizq8285 时间: 2011-6-13 22:55:57

是这样的，我们采集了2个SGSN的数据，在gn口上统计出来的是GTP的cause为199和211的状态码。当SGSN收到GGSN给的状态码后，应该会在gb口体现reject消息，并携带SM的cause，按照你的说法，这两个数值加起来与SGSN上的counter-cc26相比较，应该比cc26小才是？

作者: 爱卫生 时间: 2011-6-14 15:51:59

回复 lizq8285 的帖子

想问一下，你提到的“在gn口上统计出来的是GTP的cause为199和211的状态码”是怎么采集的？是通过抓包软件统计的吗？如果是这样，有没有可能在做以太网交换机端口镜像的时候同时抓了上行和上行口，抓到的包会乘以2呢？我就碰到过这样的情况，所有的包都是发2遍。实际上只发了一遍，因为端口镜像了两个端口所造成的。
另外，假设GTP CC199的值为A，CC211为B，CC26的值为C。现在结论是A+B远大于C。但单个值比较呢？如果B也>C，那就不对了，因为Gn接口CC211已经可以明确是归到Gb接口的CC26的。有上面的包为证。

作者: gprssanling 时间: 2011-6-14 19:03:39

http://www.gprshome.com/forum.ph ... 5&highlight=pdp请参考。有CC26的讲解。

作者: gprssanling 时间: 2011-6-14 23:16:19

明确一下，CC199和CC211的确都归在CC26里面。
抓包要对比CC的统计值需要注意：1、抓Gn最好在SGSN这一侧的接口，如果镜像把SGSN/GGSN两侧的Gn口都镜像到了一个目标端口上，那结果不在2备之下；2、过滤条件最好匹配( gtp.cause==199 or gtp.cause==211 ) and udp.dst == SGSN-gtp-c-ip；3、选择两个相邻时间段中间的包，如12:00-13:00之间的包，则SGSN上选择对应时间段SM.UnsuccActPdpContextCC26.G的差值。好像没有其他需要注意的了，结果应该前者<后者才是。

作者: lizq8285 时间: 2011-6-15 11:46:39

首先，我们是在gn口采集到的数据，是采用现网架设TAP设备方式。
其次从数据库统计到的由于211和199造成的PDP失败数量级跟CC26根本不是同一级别的，我们统计到的是超过万，而cc26是个数，或者最大是十的级别。

作者: lizq8285 时间: 2011-6-15 16:00:06

现在我觉得应该取Gb的信令包来证明了，如果确实是那么多的c26的话，爱立信就要自己找问题了吧？

作者: 爱卫生 时间: 2011-6-15 20:02:27

回复 lizq8285 的帖子

  我觉得"gprssanling"版主对CC26做了很详细的解释。至少从原理的角度来看，我们能确认的就是，CC199和CC211都是归到CC26。所以Gn接口CC199+CC211应该和Gb接口的CC26是差不多的。
  如果你能确定抓包的各个CC统计没有问题的话，我的建议就是，那就赶紧开Case找爱立信或者二线支持吧。

作者: lizq8285 时间: 2011-7-5 17:20:51

对于199资源不足的GTP cause目前只找到一个Gb信令案例：结论是当GGSN返回199失败给SGSN的时候，它会马上在向另外一个GGSN发起PDP激活请求，不会在GB影响到用户PDP的失败，经咨询，要发起3次才算一次失败。

作者: 爱卫生 时间: 2011-7-5 22:51:11

回复 lizq8285 的帖子

这个特性不错哦。应该这样子才合适哦！请问是哪条配置指令开启这个特性啊？还是哪个Lincense属性呢？也就是说在SGSN上用什么命令打开这个功能？谢谢！

作者: lizq8285 时间: 2011-7-5 23:38:38

移动客户说的，我也正在求证啊。大家一起想想办法，呵呵

作者: Win㊣ 时间: 2011-7-18 17:15:31

lizq8285 发表于 2011-7-5 17:20
对于199资源不足的GTP cause目前只找到一个Gb信令案例：结论是当GGSN返回199失败给SGSN的时候，它会马上在向 ...

我所知道的是：

如果SGSN收到一个有效的创建PDP上下文响应消息为以下的GTP原因值之一

，将尝试向下一个GGSN尝试：#199
#200
#204
#211
#212
#219
#220

当然你的SGSN配置了1对多个ggsn，要么采用轮询方式，要么采用dns sortlist指定一个ggsn优先。
至于尝试多少次，应该是你dns能解析出多少个GGSN，就不停的向下一个GGSN激活，直到能够激活的那个ggsn为止，当所有GGSN都不能激活时，则本次激活失败。

作者: lizq8285 时间: 2011-7-18 23:07:13

应该也是受控于T3N3参数吧？

作者: zyzai605 时间: 2012-4-11 14:42:46

应该是#38

作者: zyzai605 时间: 2012-4-11 14:43:25

记错，一个是#26

作者: will 时间: 2013-9-24 15:46:17

请教楼主，我从现网抓一个爱立信GGSN Gn口的包约一个小时有100多次Response 199的资源不足
GGSN PDP不到Licence总数的一半 IP地址池也充足根据抓到的IMSI对应SGSN 分析EBM也没有这个IMSI CC26的错误再从哪里入手查这个199错误原因呢？多谢

作者: will 时间: 2013-9-26 17:38:37

will 发表于 2013-9-24 15:46
请教楼主，我从现网抓一个爱立信GGSN Gn口的包约一个小时有100多次Response 199的资源不足
GGSN PDP不到 ...

GGSN的健康检查没有发现什么有帮助性的内容
让同事分析了抓包，他认为有2点：
1，同一个SGSN，1分钟之前发送了一个PDP激活，然后一分钟后又对同一个用户发送了一个相同naspi的pdp激活，就是说在第二次发送这个pdp激活的时候，这个用户的同一个naspi还在GGSN上；
这个可以从抓包中看到；
2，涉及到RAU的问题，用户在华为SGSN下面做了一个update pdp到我们GGSN，我们GGSN接受了这个PDP，之后这个手机漫游到了我们SGSN下面，然后由于某种原因RAU失败，于是手机再次发送了create pdp request，这个时候，巧合的是，我们的SGSN也把这个pdp发送到了我们的GGSN07上面，而这个时候GGSN07上是还有这个用户的，所以GGSN拒绝了这个pdp激活。
第二个分析楼主认为？谢谢

作者: 爱卫生 时间: 2013-9-26 22:15:03

will 发表于 2013-9-26 17:38
GGSN的健康检查没有发现什么有帮助性的内容
让同事分析了抓包，他认为有2点：
1，同一个SGSN，1分钟之前 ...

你说的情况和论坛的一个帖子类似，都是出现相同的NSAPI=5。帖子：http://gprshome.com/thread-509-1-2.html。

但该例PDP激活失败的原因代码是CC30。所以你提到的2点可以看下Gn口的抓包是CC199吗？比较奇怪，照道理如果NSAPI相同的话，不应该是资源不足才对。

作者: ccc123 时间: 2014-5-28 00:26:39

我也遇到相同的问题了。。

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)