在update中GGSN返回不存在PDP上下文（Non-existent）的原因？

lizq8285

在SGSN发起的update流程中，GGSN返回GTP cause为NON-existent的失败码，统计一天24小时的数量也大，大概有10000多。查了相关协议，没有什么收获。协议解析：

3GPP 29.060协议规范对此错误解析如下：If the SGSN receives an Update PDP Context Response with a Cause value ‘Non-existent', it shall
delete the PDP Context。

3GPP 23.060协议规范解析为：If the new SGSN is unable to update the PDP context in one or more GGSNs, the new SGSN shall deactivate the corresponding PDP contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area update.

    在真实的信令流程中，也看到终端重新PDP激活了。

lizq8285

不知道大家分析过此类问题么有？虽说不会影响到路由更新成功率，但是会影响到用户感知，并且下线了再PDP激活。

lizq8285

发错地方了！没人懂的？

爱卫生

回复 lizq8285 的帖子

  从这个CauseCode来看的话，是GGSN找不到对应的PDP上下文了。那要么是GGSN自己把它删了，要么是其他网元通过信令要求GGSN删除了。这里最有可能的是GGSN自己把它删了。
  各个厂家的GGSN一般都可以设置一个Timer，用于监管PDP上下文的存活性。如果MS激活后很长时间没有流量，例如用户正在上网的过程中突然掉电或死机了。那GGSN就可以通过这个timer来监管。
  只是个人理解哈。
  这里附上一个同样原因的包。供参考。这是因为PDP上下文不存在所引发的去激活。
  如果方便，你也可以附上一个你的包供大家参考讨论。谢谢！

lizq8285

卫总：你给出的包SGSN向GGSN发起了delete，但是协议上不是说SGSN向ms发起的吧？而且此次是由于在update的过程中GGSN已经返回了non-existent的原因吗，应该就不比向GGSN发起了吧？不知道说的对不对？
第二：我查到2个GGSN参数供大家讨论，
一是IDLE-TIMEOUT,参数作用说明：
为了防止个别用户激活PDP上下文后，长时间不使用PS业务而占用系统资源，GGSN
应当可以配置一个最大空闲时间，在这个时间内如果用户没有流量，则GGSN 可以主动去
激活此PDP上下文。-----------目前我看到地市本地的GGSN是设置为30分钟。
二是session-timeout，参数说明如下：
GGSN 允许的PDP 上下文最大存活时间。-------------目前我看到地市本地的GGSN没有设置此参数。
log如下：
pdp-context {
            creation unblocked;
            limit 500000;
---(more)---
                    
            payload-limit 525000;
            session-control {
                idle-timeout {
                    default timeout 30;
                }
            }
            signaling ggsn-deletes-per-second 50;

爱卫生

lizq8285 发表于 2011-8-15 08:49
卫总：你给出的包SGSN向GGSN发起了delete，但是协议上不是说SGSN向ms发起的吧？而且此次是由于在update的过 ...

  我的包只是举一个例子。和你的update pdp context的例子不匹配，主要是想说明212这个cause code。
  delete pdp context request消息属于GTP信令，只能是SGSN给GGSN或反过来，而不会是SGSN和MS之间。MS和SGSN之间叫deactivation pdp context request/response。名称不一样。
  如果是你的例子中，SGSN和GGSN做update，GGSN回了个CC212，SGSN就不会发delete消息给GGSN了。
  另外，我觉得你的这个例子的问题，是不是就是由GGSN的IDLE-TIMEOUT引起的呢？我只是猜想哈。就是正常来说，用户关闭浏览器的动作会触发一个去激活PDP上下文，但很多手机是多任务的。用户上完网后，浏览器没有关而是切换到另外一个窗口去听音乐或看书什么的，浏览器还在后台运行，这种情况下GGSN上关于这个用户的PDP上下文就很可能在30分钟后会被删除，前提是这个用户在30分钟内不上网的话，但这种现象很常见。
  另外，我还查了24008的规范，发delete pdp context request给对方GSN节点有几个原因值，包括：
# 8: Operator Determined Barring;
# 25: LLC or SNDCP failure (A/Gb mode only);
# 36: regular  deactivation;
# 38: network failure; or
# 39: reactivation requested.
  但上述并没有提到inactive pdp context,因此GGSN即使在PDP上下文变成inactive的时候，也可能不会给SGSN发delete消息，这样SGSN就不知道了。那如果上述假设成立的话，出现你问题的情况就不奇怪了。个人猜想，仅供参考。

luoyufeizhu

爱卫生 发表于 2011-8-15 20:36
我的包只是举一个例子。和你的update pdp context的例子不匹配，主要是想说明212这个cause code。
  d ...

弱弱的问一句，照你的说法由IDLE-timeout引起的GGSN主动去激活此PDP上下文，GGSN就不会告知SGSN这个动作么？信令上也不会有体现？

hycl5410

idle-timeout时，GGSN确定发delete pdp给SGSN。前几天刚看的一个case。

@楼主，没有数据包，没有场景描述，没有统计...就这么几句文字描述很难说清楚问题的。update pdp也不只是在inter-RAU才会出现；可能某一个或者几个用户重复进行操作也可以造成统计值比较大...可能性太多了，不是没人懂而是没人知道情况到底是什么样。
去开CSR吧...

lizq8285

回复 hycl5410 的帖子

楼上的朋友能给我个数据包或者分析吗，我正在做这个分析，不知道咋回事呢？

lizq8285

hycl5410 发表于 2012-3-25 11:13
idle-timeout时，GGSN确定发delete pdp给SGSN。前几天刚看的一个case。

@楼主，没有数据包，没有场景描述 ...

急求case的信息或者资料啊，证明IDLE-TIMEOUT时，GGSN是会下发DELETE PDP给SGSN的啊。我找得好辛苦，都没找到有的。

hycl5410

我只有Gn的抓包，没有整个流程的user trace。而且Gn抓包软件设置原因导致delete pdp req里连个cause都没有。一线确定是idle-timeout造成的GGSN去激活。