关于GGSN重复发起Update PDP Context procedure的疑问

爱卫生

回复 iscehsj 的帖子

  我讨论下。
  “如果用户在完成一个HTTP业务后，将其断开”，请问你说的断开，是指将某个页面关闭，还是将整个浏览器关闭呢？这是不一样的。前者不会去激活PDP上下文，后者则会去激活PDP上下文。如果是前者，那PDP上下文还在，你继续访问其他的网页页面，则还是同一种HTTP业务，应该是不需要更新Qos的。如果是后者，则需要重新激活PDP上下文，通常是点击浏览器输入某个页面触发，那这时候在PDP激活的时候就会协商好Qos了。后续不需要再做Qos的update，这应该是一种正常的行为。除非是有用户不断的开、关IE浏览器，但这也应看作一个正常行为。
   除非是这样一种情况，用户是通过手机QQ触发的PDP激活，然后将QQ放到后台执行，打开了一个HTTP页面，触发了Qos的更新。但也不会总是update啊。不管他做什么操作，无论是关闭浏览器也好，关闭网页也好。

爱卫生

回复 iscehsj 的帖子

  我这边做了个测试。发现是这样的。
  手机点击一个RSTP的视频进行播放。首先会触发一个Primary PDP激活流程，获取一个基础的Qos，因为到RSTP服务器的页面也需要打开。然后测试中可以看到，在Primary PDP激活完成之后，会立即进行一个二次激活。请求一个更高的Qos（并且带上TFT来描述这个新的应用类别）专门为了后续的RSTP的视频播放（一个mp4格式文件）。通过抓包可以看到。在二次激活请求中携带的Requested Qos IE中，不管是请求一个更高的下行方向的GBR，并且traffic class的值也变成了steaming class。而Primary PDP激活里的steaming class取值为000，代表是background类别的。参考帖子：http://www.gprshome.com/forum.php?mod=viewthread&tid=240&extra=page%3D1
  所以回到这里例子里，HTTP应该是背景类的，这时如果手机在访问时突然点击了一个视频，那应该会触发一个二次激活流程来请求一个新的Qos。不会涉及到Update PDP的情形。但运营商处于保护自由业务的考虑，可能将HTTP和一些非自营业务的视频业务例如QQ视频都放入背景类，这样这些定制手机可能就不会发起二次激活了。这时候GGSN就有可能需要调整Qos，发送Update PDP Context Request给SGSN请求进行重新协商。那这应该是符合规范的。
  但如果是你说的将浏览器关闭，通常就会执行PDP的去激活流程。你再使用HTTP业务时，则需要重新进行激活，也不会涉及到GGSN侧update PDP了。

爱卫生

wangcmh 发表于 2012-8-30 15:25
在29.060文档里面看到，讲update pdp request消息的时候，说有ggsn发起更新请求的情况，原文如下：

The  ...

分两种情况看。从技术上说，PDP地址是允许通过update流程由GGSN发起更新的。但从实际网络来看，这种情况基本上不存在。因为IP变了，那业务肯定就会断，影响用户体验。刚才你引用的规范也提到了，这主要发生在DHCP Relay和Mobile IP的场景下。现网都是GGSN直接分配IP地址。如果说一定要举例说现网可能出现的情况，那就是一个行业用户，买了GPRS的带宽为出差的移动用户提供局域网访问服务，并且采用DHCP的方式分配地址给员工。DHCP分配IP地址是有有效期的，如果这个IP地址被某个其他用户突然占用了或DHCP上配置变了，可能由DHCP通知GGSN为UE更改IP。

爱卫生

wangcmh 发表于 2012-9-5 10:39
多谢爱总的回复。

我从GN口上的包看到，UPDATE PDP RESPONSE有更新了GGSN IP的情况，包括GGSN-C和GGSN-U ...

这种情况下，其实并没有发生GGSN的切换啊。只是控制面的GTP-C地址和TEID更新了。GGSN上有多个处理GTP-C的板卡，就可以有多个GTP-C的地址，这是允许通过update消息进行更新的。并不能因为update response消息里的GTP-C地址变了，就判断GGSN变了。另外，GTP-C地址和TEID的变化和分配给UE的IP地址是完全分离即无关的，也就是UE的IP地址是没有变的。（这三者是通过3个完全不同的GTP协议的信息元素携带）。UE的IP地址变了肯定会影响用户体验，肯定要避免的。

所以，后面你所提到的GGSN变了，GTP-C IP地址却没有分配就不奇怪了，因为GGSN其实没有变。