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

iscehsj

在进行网络设备测试之时，遇到问题,对关于GGSN重复发起Update PDP Context procedure的流程有些疑问，麻烦指点。
背景描述：
UE在正常attach并激活一个PDP context后，用户发起一个HTTP请求。在GGSN侧，GGSN根据该HTTP业务请求检测到该业务能匹配到某一个Qos，则GGSN往SGSN发起update PDP context request以修改该PDP context的Qos。SGSN在收到GGSN的请求后，会根据自己情况确定一个negotiated-Qos（比GGSN请求的Qos低），之后返回update PDP context response给GGSN完成修改Qos的过程。这样，UE的HTTP业务可正常进行。
相关协议描述：（29.060）
The QoS values supplied in the Update PDP Context Request may be negotiated downwards by the SGSN. The negotiated values or the original value from GGSN is inserted in the Quality of Service Profile information element. This information element shall be included if the Cause contains the value "Request accepted" and a QoS information element was supplied in the corresponding request message.

问题描述：
如果用户在完成一个HTTP业务后，将其断开；然后又请求建立同一个HTTP业务，又断开；又请求建立相同的HTTP连接。。。因为我们不能排除用户侧存在这样的重复建立HTTP连接的情况，如果来看，根据协议，则GGSN会不断发起update PDP context request去请求修改Qos，网络都要不断完成这个修改Qos的流程。这样的话，不是会导致网络资源消耗？

疑问1: 3GPP 协议有没有规定GGSN的行为，来避免这样的异常情况导致的网络资源浪费？
疑问2：GGSN针对同一个业务请求重复发起QoS修改的行为是否符合规范？
疑问3：这个问题是属于设备实现的问题吗？能否通过产品实现避免这个行为？

谢谢！

爱卫生

回复 iscehsj 的帖子

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

iscehsj

谢谢回复！
我之前说的情况，指的是将HTTP连接完全断开的情形，譬如说关闭IE浏览器。
后来我想了想，觉得是不是HLR配置的UE签约QoS与在GGSN上请求的QoS不一致的问题呢？譬如，用户签约的QoS class为background的，而UE由于请求某HTTP业务，GGSN为其请求一个QoS class为streaming。
我觉得，除非RAN侧、SGSN出现overload了，一般情况也不会降低GGSN发过来的QoS请求吧；另外，对于同一个PDP context，其修改的QoS应该不能高于其签约的QoS。
欢迎继续讨论。

jianglibing

回复 iscehsj 的帖子

就算HLR签约的和用户请求的不一样，这个很正常啊，反正你在做激活的时候要进行Qos协商嘛，到时候取最小的不就行了嘛。其次的话你说的GGSN发过来的Qos请求，啥意思？是不是说GGSN上协商后的Qos，一般这个Qos SGSN不会再去降低，但是就像你说的，假如就来个特殊情况，SGSN这边突然就过载了，支持不了协商后的Qos了，那这个时候SGSN会降低Qos的，并给GGSN发PDP更新请求。

iscehsj

Hi jianglibing,

谢谢你的回复！
我在贴中所说的GGSN发过来的QoS请求，是由于用户在浏览HTTP业务中，又请求了一个新的业务如点击了某视频流，这个时候GGSN根据这个业务的特性进行QoS检测，该业务映射到某QoS，而GGSN根据自身网络情况可以提供这样的QoS服务；此时，由于之前建立的PDP context的QoS不能满足该业务需求，所以GGSN会发起一个修改QoS的流程，发送Update PDP Context Request给SGSN。

爱卫生

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

iscehsj

回复 爱卫生 的帖子

爱总的分析很有道理！

那如果是没有关闭IE 浏览器，而是点击其中一个视频链接，然后关闭该视频并点击另外一个视频链接呢？在这样的情形下，其primary PDP context应该没有去激活，这样的行为是不是会触发GGSN重复发起QoS修改的流程呢？（假设SGSN由于自身overload而不能提供GGSN请求的QoS的需求）

谢谢!

wangcmh

在29.060文档里面看到，讲update pdp request消息的时候，说有ggsn发起更新请求的情况，原文如下：

The GGSN-initiated Update PDP Context Request can also be used to provide a PDP address to the SGSN (and MS). The latter shall be used by GGSN when it acts as a DHCP Relay Agent or Mobile IP Foreign Agent.

这句话不能理解，这种GGSN发起的更新请求，且携带了用户IP，用来给SGSN，或者MS提供IP，这是什么情况？难道这时候用户IP被更新掉了？

我的理解是建立PDP连接后，用户IP不会改变，不知道对不对？什么情况下用户IP在没有断开连接的情况下会变化呢？

盼各位大侠赐教，在线等回复~~

爱卫生

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

多谢爱总的回复。

我从GN口上的包看到，UPDATE PDP RESPONSE有更新了GGSN IP的情况，包括GGSN-C和GGSN-U，这种情况下，GGSN发生了切换，那么用户IP还是不变的吗？新的GGSN上，这个用户IP是否已经占用了呢？切换前后的2个GGSN之间，是怎么协商用户IP，和传递用户数据的呢？

在线盼爱总答复。

wangcmh

补充：这种情况下，更新响应的包里，会带新的TEID-U，新的GGSN-C 和GGSN -U的IP，却没有带新的TEID-C，这也是挺奇怪的一点，为什么控制面的GGSN都变化了，却没有新分配TEID-C？

爱卫生

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其实没有变。

ithinc

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

The  ...

我的理解是建立PDP连接后，用户IP不会改变，不知道对不对？什么情况下用户IP在没有断开连接的情况下会变化呢？

用户IP不会变。GGSN-initiated UpdatePDP Context Request是初始分配IP地址用的。

ithinc

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

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

不太相信，眼不见不为实。按规范，GGSN-C的地址是不能改变的。

The GGSN shall also include a GGSN address for control plane, which shall not differ from that provided at PDP context setup time and shall remain unchanged for the life time of the PDP context.

ithinc

嗯，SGSN地址可以改，GGSN-U也可以改，唯独GGSN-C不能改。