51学通信技术论坛

标题: BSS PFC定义及流程（含简单实例） [打印本页]

作者: 爱卫生 时间: 2011-6-21 19:57:49 标题: BSS PFC定义及流程（含简单实例）

  BSS packet flow context，故名思义，就是指的在BSS上的基于不同的packet flow的上下文。说的更加直白一点，这个PFC实际上是针对MS的多个PDP上下文按照Qos的不同而进行的一种分类，来匹配不同的Qos。如果这个MS激活了多个PDP上下文，则具有相同或类似Qos profile的PDP上下文将由SGSN来组合在一起，构成一个PFC。并且SGSN将和BSS一起为这个PFC来协商所需要的Qos，这个Qos由ABQP参数来进行描述。如果PDP上下文的Qos不同，则需要使用不同的PFC来区分。
  如下图所示：

[attach]543[/attach]

图一 MS中的PFC和PDP上下文关系示意

  PFC通过PFI(Packet Flow Id)来标识。这个PFI由SGSN来分配。（TS23.060 12.6.3.5)
  MS对PFC的支持能力在“MS Network Capability”IE中描述。网络侧对PFC的支持能力在“PFC_FEATURE_MODE”参数中提供，并通过BCCH或PBCCH（来自TS44.060）。
  这样，BSS就可以基于PFC这个级别来处理流控，也可以使得BSS可以根据每个PFC来执行流量监管以及资源分配。
  如果PFC在SGSN和BSC侧都启用了，则SGSN会和BSC来协商ABQP（Aggregated BSS QoS Profile ),ABQP是一组描述Qos需求参数的集合。SGSN将为每个PFC生成一个ABQP，并通过Create BSS PFC request消息发送给BSS。BSS可以协商SGSN生成的ABQP，并响应一个Create BSS PFC Accept消息。ABQP协商完成后，后续所有和这个类别流量相关的用户面数据都将按照ABQP约定的Qos在Gb接口中进行传递。
  需要注意的是，有3个预定义的PFI，SGSN不会和BSS协商这3种PFI对应的流量进行PFC的协商。这3种流量是背景类的、SMS、信令。SGSN不为这3种类型的流量协商ABQP。
  下面通过一个实例来看PFC和ABQP在网络中的使用。
  这个例子是一个MS在支持GPRS的小区中激活使用interactive类型的业务。

[attach]542[/attach]

图二 MS在GPRS小区中激活Interative类业务

通过截图会发现，通过SGSN和BSS的PFC协商流程，SGSN侧请求的ABQP为384kbps/64kbps，但BSC回的确认消息里认为只能提供48kbps/24kbps的ABQP，所以最终这个MS得到的ABQP就是48kbps/24kbps。
反过来，在上例中，如果MS在一个支持EDGE的小区中附着后，同样激活使用interactive类型的业务，则BSC会确认384kbps/64kbps的ABQP，最终MS的Qos也可以得到384kbps/64kbps。

作者: johnwey 时间: 2011-8-18 15:29:32

如果SGSN在create PDP context request时已和GGSN协商成功384kbps/64kbps, 通过什么方式把现在已经降级的Qos通知到GGSN？

作者: johnwey 时间: 2011-8-18 15:40:54

应该激活后就又有一个modify PDP context的过程

作者: johnwey 时间: 2011-8-18 15:52:24

Sorry，规范里标准PDP激活流程就提到了

9.2.2.1
PDP Context Activation Procedure
[attach]815[/attach]

7)
In A/Gbmode, BSS packet flow context procedures may be executed. These procedures aredefined in clause "BSS Context".

8)
In casethe QoS attributes, used as input to step 5 for Iu mode or step 7 forA/Gb mode, have been downgraded during those steps, the SGSN may inform theGGSN about the downgraded QoS attributes by sending an Update PDP ContextRequest to the affected GGSN. The GGSN shall not attempt to renegotiate the QoSattributes. The No QoS negotiation indication is set in Update PDP ContextRequest to indicate to the GGSN that the SGSN does not upgrade the previouslynegotiated QoS attributes and that the GGSN shall accept the provided QoSattributes without negotiation. The GGSN confirms the new QoS attributes bysending an Update PDP Context Response to the SGSN. If the SGSN establishedDirect Tunnel in step 5 it shall send Update PDP Context Request andinclude the RNC's Address for User Plane, TEID for downlink data, No QoSnegotiation indication and the DTI. DTI is used to instruct the GGSN to applyDirect Tunnel specific error handling as described in clause 13.8. TheGGSN(s) shall not include a PCO in the Update PDP Context Response if the NoQoS negotiation indication is set.

作者: zhanghenjs 时间: 2011-12-2 14:45:19

BSS返回的Create BSS PFC ACK消息里带有的是ABQP，而ABQP是一组QOS的集合，因此，如何将BSS返回的ABQP中参数转换成PDP context的Qos参数？如何实现？

作者: 三国杀小王子 时间: 2012-1-31 23:48:47

谢谢分享。

作者: xiaodong.hn 时间: 2012-5-4 10:36:56

纯英文啊，呵呵

作者: hou3331 时间: 2012-5-5 14:57:15

楼主，现网中碰到一个问题，HLR签约qos只有10kbps，但实际路测时有20几kbps，不知qos协商的过程完成后，是具体哪个网元在负责速率控制哦？BSC/SGSN/GGSN？

作者: 爱卫生 时间: 2012-5-6 19:39:40

回复 hou3331 的帖子

Qos是在PDP上下文激活流程中，由MS、HLR的签约数据还有SGSN、GGSN来共同决定。最终协商好的Qos将由Activate PDP Context Accept消息通知给MS。如果发生了Qos的变更，则触发了PDP上下文修改流程对Qos进行更新。

作者: hou3331 时间: 2012-5-7 15:49:50

楼主，我想问的是假如qos协商完成了是10kbps，但实际测试时却有20几kbps，是哪个网元出错了？

作者: hou3331 时间: 2012-5-7 15:50:41

楼主，我想问的是假如qos协商完成了是10kbps，但实际测试时却有20几kbps，是哪个网元出错了？

作者: 爱卫生 时间: 2012-5-7 20:42:34

回复 hou3331 的帖子

这种场景确实感觉有问题啊。因为MS实际得到的带宽绝对不可能超过签约的带宽的，除非是瞬时的突发。如果是这样，那运营商就亏死了。就像家里ADSL宽带一样，买的2M。但PPPOE拨号完后，一直可以到4M。那就没人买4M了。

如果BSS支持PFC的话，则BSS、SGSN、GGSN都需要参与带宽控制。如果BSS不支持PFC，则BSS不参与。

作者: hou3331 时间: 2012-5-8 16:31:25

我问过SGSN侧的R&D，说是sgsn侧除了协商，没做速率的限制的。假如没有PFC的话，BSS是无法知道最终协商速率的吧？

作者: karllv 时间: 2012-6-19 19:18:53

mark{:soso_e192:}

作者: yonka 时间: 2012-7-6 12:20:08

爱卫生发表于 2012-5-7 20:42
回复 hou3331 的帖子

这种场景确实感觉有问题啊。因为MS实际得到的带宽绝对不可能超过签约的带宽的，除非是 ...

"我问过SGSN侧的R&D，说是sgsn侧除了协商，没做速率的限制的。假如没有PFC的话，BSS是无法知道最终协商速率的吧？"

我的问题也是同样，如果BSC侧没开PFC的话，SGSN则不会与BSC进行协商，那么在协商QOS这一步就少了BSS的参与。这样理解对么？

然后~BSC侧就会不知道协商后的QOS，对么？

那是不是说这种情况下就没有网元对用户实际速率进行限制呢？除了空口资源外~

作者: enjoying007 时间: 2012-7-25 17:29:18

谢谢分享。很强大！！

作者: ck01722007 时间: 2013-6-12 18:41:13

本帖最后由 ck01722007 于 2013-6-12 18:42 编辑

ck01722007 现网2G PDP激活过程中并没有BSS与SGSN交互PFC 的procdure，如何理解BSC(PCU)中没有MS的packet flow context (QOS)的问题？

作者: chenxiaoan503 时间: 2013-6-29 21:58:47

yonka 发表于 2012-7-6 12:20
"我问过SGSN侧的R&D，说是sgsn侧除了协商，没做速率的限制的。假如没有PFC的话，BSS是无法知道最终协商速 ...

根据MS SGSN GGSN 的QOS的协商数据呀，当然如果现在有了PCRF，也可以通过PCRF来控制速率，更加多样化。

作者: ccc123 时间: 2014-2-9 23:45:26

赞一下了。谢谢。。。

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)