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

爱卫生

回复 lizq8285 的帖子

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

爱卫生

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就不知道了。那如果上述假设成立的话，出现你问题的情况就不奇怪了。个人猜想，仅供参考。