关于QOS协商

zglaojiang

版主什么时候有空能不能详细讲一下QOS协商的过程，不着急，你什么时候方便就什么时候讲一下，我说的是华为的SGSN9810。

爱卫生

    不好意思。我对华为的设备不了解。如果你的问题只是QOS协商的话，我可以用规范来回答你。但如果你的问题是想了解QOS协商在设备中的实现，例如QOS profile和哪块板卡实现及存储的，这我可能帮不了你，或者以后我再帮你查查华为的文档。也希望能有别的论坛同行们来补充。
    根据TS23.060的定义，QOS的协商是隐含在PDP Context的激活流程中的。这里，我用TS23.060 V10.2.0来做说明。
    在9.2.2中介绍了激活流程。按照原文中的顺序说明如下：
1）MS发送Activate PDP Context Request ，里面包含了QoS Requested。这个指明了MS对所请求的业务（例如一个网页或视频业务）所期望的QOS（MBR等信息）。原文如下:
     QoS Requested indicates the desired QoS profile. For an E-UTRAN capable UE, the QoS requested shall include interactive or background traffic class in this message. If the UE is not E-UTRAN capable, in this release the QoS requested should include interactive or background traffic class in this message.
4)  SGSN要验证MS的PDP上下文激活请求，也包括请求的QOS。原文是这么说的：The SGSN may restrict the requested QoS attributes given its capabilities and the current load, and it shall restrict the requested QoS attributes according to the subscribed QoS profile.也就是说SGSN可以根据自己的支持能力和符合情况，并且也可以根据从HLR过来的用户签约的QOS来进行限制。实际上就是在用户签约QOS、SGSN支持的QOS、MS请求的QOS三者取最小值。
     SGSN接下来发送Create PDP Context Request给GGSN，并携带QoS Negotiated（写上的QOS也就是上面提到的QOS最小值）。
     接下来，GGSN在收到SGSN的Create PDP Context Request后，要验证这个请求，包括这个协商的QOS。规范原文如下：
    The GGSN may restrict QoS Negotiated given its capabilities and the current load or increase the QoS Negotiated based on any external input (e.g. policy control). 也就是说GGSN也可以根据自己的支持能力或者根据外部的策略控制（PCRF）来限制这个协商的QOS。也就是在GGSN所支持的QOS和收到的这个协商的QOS比较，然后取最小值,然后返回Create PDP Context Response消息给SGSN，消息里也包含了QoS Negotiated，即刚提到的最小值。
    接下来，规范接着有说：
    The SGSN shall re-verify and may restrict the QoS Negotiated received in the response from the GGSN against the subscribed QoS profile and additionally restrict the QoS negotiated based on its capabilities and current load. The SGSN shall use this updated QoS Negotiated for the subsequent steps.
    也就是说SGSN从GGSN收到了这个协商的QOS后，与自己的支持能力再做比较，如果不匹配还可以限制（例如在收到response消息的时候，SGSN的符合突然增大了）。但如果没有问题，SGSN将使用这个更新的QOS用于后续的步骤。
    接下来，在A/Gb模式下，执行BSS packet flow context流程。在Iu模式下，执行RAB建立流程。
    如果在建立RAB时，QOS被降级，则SGSN应发送update pdp context消息给GGSN做为更新，而GGSN不能重新协商。
    做为总结，简单来说，QOS的协商实际上在MS请求的、SGSN支持的、GGSN支持的、MS的签约数据里的QOS profile以及无线侧的QOS支持能力里取最小值。

自由风

佩服，爱总对规范很熟悉啊，请问如何根据问题去查规范？和怎么要查找规范？有没有中文规范的资料？

lsjier

懂 了~~~~·······

arrowbroken

透彻，厉害

zhanghenjs

请问对于BSS packet flow control流程中BSS返回的CREATE BSS PFC ACK消息中带有的ABQP(Aggressive BSS Qos Profile)，SGSN该如何处理，如何将其与PDP context中的QOS相联系？

爱卫生

回复 zhanghenjs 的帖子

  这个帖子里有介绍 http://www.gprshome.com/forum.php?mod=viewthread&tid=440 。

skyever

QOS的协商实际上在MS请求的、SGSN支持的、GGSN支持的、MS的签约数据里的QOS profile以及无线侧的QOS支持能力里取最  已学习

oliverchang

回复 爱卫生 的帖子

“实际上就是在用户签约QOS、SGSN支持的QOS、MS请求的QOS三者取最小值”
爱总，对于用户而言其在HLR签约的QOS Profile就是应该保证其一定的速率即GBR，但是如果SGSN支持的QOS比用户签约的QOS小，然后采用SGSN的QOS这样的情况下是不是有忽悠客户，欺骗消费者之嫌？

hycl5410

回复 oliverchang 的帖子

HLR签约，MBR和GBR是分开的。
MBR协商几乎没有遇到过用户签约大于设备支持的情况，9810,9811都不会，不影响协商，资源不够的时候PDP激活不了。而且从逻辑上讲，也不应该出现，因为MBR只是尽力而为。
GBR则需要设备支持，那么运营商在给客户签约之前必然要在厂商那里拿到设备相应的支持，不管是license形式还是其他什么形式。然后就是容量规划等等一系列动作。严格意义上说，就算出现问题也应该是运营商没有规划好，不能定位为欺诈。

enjoying007

谢谢分享。很强大！！

enjoying007

hycl5410 发表于 2012-3-23 14:18
回复 oliverchang 的帖子

HLR签约，MBR和GBR是分开的。

MBR协商几乎没有遇到过用户签约大于设备支持的情况，9810,9811都不会，不影响协商，资源不够的时候PDP激活不了。而且从逻辑上讲，也不应该出现，因为MBR只是尽力而为。


如果下行MBR为384k，但基站只提供CS4编码，MS最多分4个时隙，21.4*4也满足不了384k，此时不对MBR做降速吗？

hycl5410

enjoying007 发表于 2012-7-25 22:02
MBR协商几乎没有遇到过用户签约大于设备支持的情况，9810,9811都不会，不影响协商，资源不够的时候PDP激活 ...

在没有PFC的情况下，2G下，核心网QOS MBR协商是不管BSC侧的。也就是说，仍然只是请求/签约/核心网设备支持三者协商的结果。此时是不会对MBR降速的，全部扔给无线。
至于打开PFC的情况，由于没有遇到过，所以抱歉没有办法回答。