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

iscehsj

Hi jianglibing,

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

iscehsj

回复 爱卫生 的帖子

爱总的分析很有道理！

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

谢谢!