求助爱立信SGSN关于失败counter的问题

爱卫生

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。供参考。

爱卫生

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

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

爱卫生

回复 lizq8285 的帖子

  没问题。我先把包给你哈。
  这个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:}

爱卫生

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

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

爱卫生

回复 lizq8285 的帖子

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

爱卫生

回复 lizq8285 的帖子

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

爱卫生

回复 lizq8285 的帖子

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

爱卫生

回复 lizq8285 的帖子

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

爱卫生

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相同的话，不应该是资源不足才对。