请教背景类和交互类的QoS协商

enjoying007

按照23.107中的QoS profile，只有会话和流业务支持GBR参数，背景类和交互类是不支持GBR的。因此这两类业务应该不用考虑GBR的协商？
问题1：现网中背景和交互类业务，CN发来的QOS参数中GBR是否有值，但是BSS侧对其忽略不做协商？
问题2： BSS侧，背景和交互类 MBR的协商是如何处理？按照小区最大的编码速率*手机对多分配的时隙数？

yonka

也正是我想了解的~

爱卫生

说下我的理解：

正如你所说，只有会话和流业务支持GBR参数，背景类和交互类是不支持GBR的。查阅了23.107关于这几个类别关于GBR的说明，其中会话类、流媒体业务类别都提到了一句话：“Minimum resource requirement is determined by guaranteed bitrate (When a conversational source generates less traffic than allocated for the bearer, the unused resources can of course be used by other bearers).”也就是说这两类确实是需要网络侧能提供GBR保障的，当然如果没有相应的这两类业务运行，可以分配给其他bearer使用。但交互类是这么说的：“There is a definite need to differentiate between quality for bearers within the interactive class. One alternative would be to set absolute guarantees on delay, bitrate etc, which however at present seems complex to implement within RAN/CN. Instead, traffic handling priority is used. SDUs of a UMTS bearer with higher traffic handling priority is given priority over SDUs of other bearers within the interactive class, through UMTS-internal scheduling.”3GPP认为，如果要为交互类提供bearer的Qos保障，采用GBR及延迟来保障在RAN/CN实现起来过于复杂，不利实施。因此取而代之的是用THP来实现，并且提到是由UMTS的内部调度机制实现的，各厂家不一样。

最后是背景类，这么说的：“UMTS only transfers background class SDUs when there is definite spare capacity in the network. ”也就是说背景类是尽力而为，什么都不保障，只有在网络侧有足够容量带宽的情况下才会传送背景类，不提供任何形式的资源预留。

但对于MBR还是有限制的。对于交互类和背景类，都有这么一句话：“To be able to limit the delivered data rate for applications and external networks by traffic conditioning, maximum bitrate is included.”因此，网络侧是需要根据MBR来进行限制的。

综上所述：

问题1：目前现网大部分应该都不支持BSS的PFC（packet flow context）流程即BSC不参与Qos协商，也就没有这个问题的存在了。如果参与，那么应该也是忽略的。

问题2：BSS侧肯定要对背景和交互类的MBR进行限制及内部调度。后一个问题属于内部实现，各厂家应该不一样。不大清楚了！

enjoying007

多谢爱总分析，好像明白了点