问：SGSN如何知道BSS是否支持PFC 信令？

yonka

“ SGSN---BSS之间的QoS协商的前提是BSS支持BSS PFC信令，否则SGSN将不会发起BSS PFC协商”

SGSN如何知道BSS是否支持？

在BSSGP层的初始化流程中告知？能否详细介绍一下？

谢谢

yonka

爱总能帮忙回答一下吗？

admin

yonka 发表于 2012-9-24 20:27
爱总能帮忙回答一下吗？

根据规范的说明，并没有说BSS和SGSN之间要协商是否支持PFC。只规定了BSS和MS之间要协商。

“Network support of packet flow context (PFC) procedures is indicated by the PFC_FEATURE_MODE parameter that is broadcast on either the BCCH or PBCCH. If the PFC_FEATURE_MODE field indicates that the network does not support PFC procedures then a mobile station shall not indicate a PFI value during uplink TBF establishment. If the PFC_FEATURE_MODE field indicates that the network supports PFC procedures then a mobile station may indicate a PFI value during uplink TBF establishment. The PFI value identifies the initial PFC used during the TBF.”

MS在附着请求的"MS Network Capability"信息元素字段中携带是否支持PFC通知网络侧。BSS通过BCCH或PBCCH广播信道中携带PFC_FEATURE_MODE参数通知MS，BSS侧是否支持PFC。如果两边都支持，MS才可以在建立TBF的时候携带PFI用于标识PFC。

然后PFC的创建流程参考TS23.060的12.6.3.5.1。“The BSS receives a request to transfer an uplink or downlink user data LLC PDU for which it currently does not have a BSS packet flow context. In the uplink case, TLLI, Radio Priority, and Packet Flow Id are received from the MS as defined in TS 44.060 [77]. In the downlink case, TLLI and Packet Flow Id are received from the SGSN as defined in TS 48.018 [78]. If Packet Flow Id does not indicate a pre-defined value the BSS sends a Download BSS Packet Flow Context Request (RAI, TLLI, Packet Flow Id) message to the SGSN. Until the BSS receives the BSS packet flow context, the BSS shall handle uplink and downlink transfers according to a default aggregate BSS QoS profile. ”

根据上文，BSS在转发上下行用户数据（LLC PDU）时如果发现当前没有BSS PFC对应（此时，Gn接口的PDP上下文已经建立即SGSN已经收到GGSN返回的Create PDP Context Response消息），则可以发送Download BSS PFC Request消息给SGSN请求获取一个PFC。如果是转发上行方向的用户数据，则Download BSS PFC Request消息中的PFI由MS提供。如果转发下行LLC PDU，则PFI由SGSN提供。

后续的信令流程是，SGSN发送Create BSS PFC Request消息给BSS，虽然是请求，但实际上是SGSN给BSS下发PFC，如果BSS和SGSN完成PFC内的Qos参数协商，BSS发送Create BSS PFC Accept消息通知SGSN协商完成。

但如果BSS不能支持SGSN下发的PFC中的Qos的话（例如当前利用率过高），那根据TS48.018，BSS将发送CREATE-BSS-PFC-NACK消息给SGSN通知其PFC创建失败。例如：“If a BSS not supporting ARP handling is unable to create the PFC then a CREATE-BSS-PFC-NACK PDU is returned with a cause value (e.g. Cause value: PFC create failure). The SGSN shall stop the Create BSS PFC procedure.” “The BSS may return a CREATE-BSS-PFC-NACK with a cause if it is unable to create or modify the PFC”。

yonka

admin 发表于 2012-9-25 21:41
根据规范的说明，并没有说BSS和SGSN之间要协商是否支持PFC。只规定了BSS和MS之间要协商。“Network suppo ...

谢谢爱总的详细解释

对BSS于MS侧的协议流程没有了解，所以只能试着去理解你说的，麻烦爱总看下是否理解对了。

1、MS在附着请求的"MS Network Capability"信息元素字段中携带是否支持PFC通知网络侧；而BSS通过BCCH或PBCCH广播信道中携带PFC_FEATURE_MODE参数通知MS，BSS侧是否支持PFC。   这样的话MS就可以知道是否双方都是否支持PFC。如果都支持，MS在建立TBF的时候携带PFI用于标识PFC。

2、只有在BSS收到来自MS的PFI后，才会向SGSN发起download-pfc流程。（现网看到的情况，挺多没有download-pfc这个消息，而是在激活PDP请求发到SGSN后，SGSN发起create-pfc流程。这是表示该PFI在BSS上存在吗？）

附件中的《0614_处理投诉时的包_PFC流程正常》包中，可以看到，前面是 PDP激活请求---create-pfc请求---create-pfc-ack---PDP激活接受（序号13~16）。后面一些可以看到是 PDP激活请求---download-bss-pfc---create-pfc---create-pfc-ack---PDP激活接受（序号85~...最后）。  
为什么前后不一样呢？后面多了一步download-pfc，能结合这几步讲一下吗？
另外，并没有看到实际的PFI，似乎都是一样的？signaling和dynamically assigned ，并没有看到实际的值，这是为什么呢？

admin

非常感谢补充！之前的答复有些失误已更正，PFC流程的创建准确来说不是在PDP上下文创建完后，而是在Gn接口的PDP上下文已经建立即SGSN已经收到GGSN返回的Create PDP Context Response消息后发起的。download-pfc本身在规范中是一个可选的消息。这两个报文我个人感觉没什么太多区别，但PFI是不同的。Signaling应该是一直都有带的，可惜没看到Attach Request消息，如果有的话，那附着请求的BSSGP层应该也携带了PFI=1及Signaling。这是因为该MS支持PFC流程所以可以携带。而另外一个报文应该是MS不支持PFC流程，因此在建立TBF的时候和BSS协商没有通过因此没有在上行消息中携带TFI。

这两个包中的PFI值是有区别的。规范规定PFI有4个预留的值，取值分别为0、1、2、3，对应Best effort、Signaling、SMS、TOM（Tunnel of Message）。PFI值的长度有7个bit，Gb接口的下行方向的TFI是由SGSN分配的，本例分配的是8。而那个Signaling的TFI应该是MS发出时就携带的（建TBF的过程中，抓包的话在Um接口的RLC/MAC层）。

ccc123

没看明白pfc的含义。。。

hrbqby

ccc123 发表于 2014-2-13 23:21
没看明白pfc的含义。。。

12.6.3.5.1 BSS Packet Flow Context Creation Procedure   请阅读 3GPP-23.060

ccc123

一定拜读。。。谢谢。。。

华仔

介绍的很详细，学习了，多谢！！