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

lizq8285

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

lizq8285

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呢？

爱卫生

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

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

lizq8285

在线等答复。。

爱卫生

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

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

lizq8285

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

lizq8285

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

lizq8285

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

爱卫生

回复 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

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

lizq8285

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

爱卫生

回复 lizq8285 的帖子

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

lizq8285

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

爱卫生

回复 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

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

gprssanling

明确一下，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的差值。好像没有其他需要注意的了，结果应该前者<后者才是。