Packet Flow(PFC)管理信令流程

爱卫生

7.1 BSS PFC创建流程
  如果BSS收到一个要发送上行或下行LLC PDU的请求，该请求没有BSS分组流量上下文（PFC），并且PFI没有指示最有效/SMS/信令，则该BSS可向SGSN发送DOWNLOAD-BSS-PFC PDU并启动定时器T6。上行中，从MS收到的TLLI、可选无线优先级、可选PFI由04.60协议定义。在BSS收到BSS PFC之前，BSS应综合BSS QoS文件、按照最有效缺省方式来处理上行和下行传输。对于上行传输，最有效缺省文件由无线优先级等级来详细说明。
  如果BSS没有从MS收到PFI（如R97/R98版本的MS），BSS不会向SGSN发送DOWNLOAD-BSS-PFC PDU，此时应利用QoS文件的消息元素来替代。
  收到DOWNLOAD-BSS-PFC PDU后，SGSN应向提出综合BSS QoS文件（Aggregate BSS QoS Profile，ABQP）请求的BSS发送CREATE-BSS-PFC PDU并启动定时器T7。BSS收到CREATE-BSS-PFC PDU后，停止定时器T6并以包含协商ABQP的CREATE-BSS-PFC-ACK PDU来响应。BSS可通过给定的自身能力和当前负荷情况来限制请求的ABQP。
  SGSN也可发起创建BSS PFC流程。即SGSN在发送CREATE-BSS-PFC请求之前，不要求收到DOWNLOAD-BSS-PFC PDU。
  BSS如果不能创建或修改此PFC，可回带原因值的CREATE-BSS-PFC-NACK 。 SGSN收到CREATE-BSS-PFC-ACK或CREATE-BSS-PFC-NACK PDU后停止定时器T7。
  分组流量定时器（PFT）由SGSN提供给BSS。该定时器定义了某个PFC去激活期间BSS可保持该PFC的最大时间。该定时器在收到CREATE-BSS-PFC PDU时启动，并在传送完针对该PFC的上行PDU后重启。
  如果BSS收到针对某个在该BSS内已有BSS PFC的MS的 CREATE-BSS-PFC PDU，则BSS认为这是修改已存在的PFC的请求。
异常情况处理：
- SGSN如果收到未知PFI的 DOWNLOAD-BSS-PFC PDU，就不会发送CREATE-BSS-PFC PDU。
- 如果在T6秒内没有收到针对某个DOWNLOAD-BSS-PFC PDU 的CREATE-BSS-PFC PDU，则该DOWNLOAD-BSS-PFC PDU 可被重复尝试发送DOWNLOAD-BSS-PFC-RETRIES次。在重复尝试 DOWNLOAD-BSS-PFC- RETRIES + 1次后，仍未收到相应响应，则停止该流程并告知O&M系统。BSS如果没有收到BSS PFC，应按照最有效的缺省ABQP来处理上、下行传输。
  如果T7秒内没有收到响应CREATE-BSS-PFC PDU的CREATE-BSS-PFC- ACK或CREATE-BSS-PFC-NACK PDU，则该CREATE-BSS-PFC PDU最大可被重复尝试CREATE-BSS-PFC-RETRIES次。在尝试发送CREATE-BSS-PFC-RETRIES+1次后，仍未收到响应信息，则停止该流程并告知O&M。
  BSS如果不能创建PFC，则回带原因值的CREATE-BSS-PFC-NACK PDU（如原因值：PFC创建失败）。之后，SGSN停止创建BSS PFC流程。

7.2 BSS PFC修改流程
  BSS可在任何时刻（例如在BSS可用资源变更的时候）通过MODIFY-BSS-PFC PDU 来请求对已存在的BSS PFC上下文的修改。BSS发送MODIFY-BSS-PFC PDU并启动定时器T8。SGSN将MODIFY-BSS-PFC PDU中修改的参数嵌入相关的PDP上下文中。SGSN以MODIFY-BSS-PFC-ACK PDU来响应修改请求。分组流量定时器（PFT）由SGSN提供给BSS。该定时器在收到 MODIFY-BSS-PFC-ACK PDU时启动或重启，并在传送完该PFC的上行PDU后重启。在收到一个此修改流程的响应后，BSS停止定时器T8。
  SGSN能够通过一个包含之前的ABQP的 MODIFY-BSS-PFC-ACK PDU 来拒绝由BSS提交的QoS文件。SGSN可在任何时刻（如激活、修改或去激活一个PDP上下文时）通过CREATE-BSS-PFC PDU来请求对BSS PFC上下文的修改。SGSN不能采用 MODIFY-BSS-PFC PDU。如果BSS PFC已存在，BSS应认为该消息为一个修改请求，并以CREATE-BSS-PFC-ACK来响应。BSS可给定其自身的能力和当前的负荷来限制请求的ABQP。

异常情况处理：
  如果在T8秒内没有收到MODIFY-BSS-PFC PDU的响应消息MODIFY-BSS- PFC-ACK时，则MODIFY-BSS-PFC PDU最大可被重复尝试发送MODIFY- BSS-PFC-RETRIES次。在尝试发送MODIFY BSS-PFC-RETRIES+1次后仍未收到响应，则停止该流程并告知O&M。

7.3 BSS PFC删除流程
  SGSN可在任何时刻采用DELETE-BSS-PFC PDU来请求删除一个BSS PFC。BSS应以DELETE-BSS-PFC-ACK PDU来响应。BSS可在任何时刻删除一个BSS分组流量上下文，而不必通知SGSN。

GPRS_2

记得好像BSS还可以通过MS FLOW CONTROL来通知SGSN停止下发LLC PDU的这么一个过程，然后更新什么漏桶计数器B等等。

爱卫生

回复 GPRS_2 的帖子

第一个问题：
  根据规范，在GSM/EDGE环境下，GPRS只关注下行方向的流控。没有上行方向的流控。因为在早期还没有出现P-2-P的应用，仍然是上下行流量不对称，下行流量比上行流量要大得多。所以流控是单向的。都是由BSS发给SGSN要求做流程的flow control消息。只包含两个参数，一个是R代表峰值速率，一个是Bmax代表的是最大的缓冲容量。没有别的参数了。SGSN可以根据BSS发过来的flow control消息中的R和Bmax值，来调整下行方向的发送速率。参见TS48.018.

第二个问题：
  是的。根据TS48.018规范的8.2章节关于流控的描述如下：
“The model of the algorithm is that an LLC-PDU is passed by the algorithm as long as the bucket counter (B) plus the length of the LLC-PDU does not exceed the bucket size Bmax. When the LLC-PDU is passed, the LLC-PDU length is added to B. Any PDU not transmitted is delayed until B plus the LLC-PDU length is less than Bmax.”
  上面提到的B全名是bucket counter,初始值为0.虽然较counter，但实际上是缓冲区的容量，单位是字节。缓冲区不能太大，否则就会有延迟，也不能太小，否则就会有丢包。关于B的设置可以参考另一篇帖子。 http://www.gprshome.com/forum.php?mod=viewthread&tid=121&extra=page%3D1 “Gb接口的流量控制”或TS48.018的8.2章节关于流控的描述。

skyever

学习了.......................

yonka

爱总，我想问下PFC修改和流控是不是一回事，作用是不是一样呢？

另外，BSC侧根据自己的资源情况发起modify-pfc流程是否会导致SGSN发起PDP上下文修改流程？
比如BSC根据...决定降低PFC，然后SGSN发起PDP修改，降低QoS；之后BSC资源使用情况改善，....，QoS升高？
会不会这样呢？

PFC是否会在之后使用过程中影响GMM层的QoS重协商？

yonka

爱卫生  规范中原话是:"The SGSN may at any time request the modification of the contents of an existing BSS packet flow context, e.g. due to the activation, modification, or deactivation of a PDP context.   发表于 4 分钟前
如你所提到的，BSC也会根据自己 的资源情况发起modify-pfc的流程啊

爱卫生  PFC只是一个带有Qos参数的用户上下文，类似MM和PDP上下文。本身不会影响GMM层Qos协商。除非BSC觉得有需要修改PFC中的某个参数，就会通知SGSN，这样才会影响GMM层Qos重协商。  发表于 4 分钟前
这么说，也是会有BSC发起modify-pfc流程修改PFC中的参数然后触发GMM QoS重协商的情况对吗？

爱卫生  不是一回事。PFC发生在PDP激活流程中，多方参与共同协商好的Qos参数。流控是在用户面转发下行（Gb口的流控只针对下行方向）由BSC请求进行流量控制即可以调整下行发送速率。降低PFC应该会触发PDP修改流程的。  发表于 8 分钟前
比如原先协商好MBR为256k，过一段时间后BSC发起modify-pfc流程触发gmm层qos重协商 qos降低为128，然后再过一段时间BSC资源使用情况改善，再发起同样的流程使得qos恢复为256。  这样理解对吗？如果是的话BSC根据什么来判断修改后的数值呢？要改成多少。