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来区分。
  如下图所示：
  

图一 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类型的业务。

图二 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。

  

爱卫生

回复 hou3331 的帖子

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

爱卫生

回复 hou3331 的帖子

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

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