SGSN与BSC的PFC协商流程，是否存在一个参数控制这个流程

snap0127

近期测试发现，诺基亚终端上网设置“需要时在线”其PDP激活流程长达8秒以上，经过抓包分析发现了PFC流程异常，如下图所示：
1、正常流程，PDP激活过程中进行QOS协商，SGSN发起PFC，BSC回复SGSN，协商流程结束，PDP激活完成。



2、异常流程，PDP激活过程中SGSN发起PFC流程，BSC也回复了SGSN，但SGSN不理会该回复，待2s超时后SGSN继续发送PFC，连续发送4次（SGSN那个参数控制这个次数？），使用户的PDP激活流程长达8s以上，请诺西分析下原因。


3、原始数据包如附件。

admin

重试次数和等待时间都有的。有关于等待对方报文的等待时间，BSS侧是T6计时器（发送DOWNLOAD-BSS-PFC PDU 启动 ，收到CREATE-BSS-PFC PDU后停止），SGSN侧是T7计时器（发送CREATE-BSS-PFC-ACK PDU启动，收到CREATE-BSS-PFC-NACK PDU停止）。

SGSN的重试次数是：“If a CREATE-BSS-PFC-ACK or CREATE-BSS-PFC-NACK PDU is not received in response to a CREATE-BSS-PFC PDU within T7 seconds, then the CREATE-BSS-PFC PDU shall be repeated a maximum of CREATE-BSS-PFC-RETRIES attempts. After CREATE-BSS-PFC-RETRIES+1 attempts the procedure is stopped and the O&M is informed.”

也就是SGSN上有一个叫做CREATE-BSS-PFC-RETRIES的重传次数定义的。

BSS上也有一个，如下“If a CREATE-BSS-PFC PDU is not received for a DOWNLOAD-BSS-PFC PDU within T6 seconds, then the DOWNLOAD-BSS-PFC PDU shall be repeated a maximum of DOWNLOAD-BSS-PFC-RETRIES attempts. After DOWNLOAD-BSS-PFC-RETRIES + 1 attempts the procedure is stopped and the O&M system is informed. If a BSS PFC is not received then the BSS shall handle uplink and downlink transfers according to a best-effort default aggregate BSS QoS profile.”

叫做DOWNLOAD-BSS-PFC-RETRIES计时器。

但这里的问题是SGSN为什么要重发BSS-PFC PDU？因为上面的计时器是指收不到BSS的BSS-PFC-ACK PDU来重发的，本例是已经收到了，所以最好有抓包看看，是不是协商有什么问题。

yonka

有没有可能BSC对QOS重新negotiation但是不符合SGSN要求？

snap0127

上面的消息，是从哪个3GPP上的，能说明下吗？我再去找找

snap0127

从我的包上来看，SGSN发送“CREATE-BSS-PFC”到收到“CREATE-BSS-PFC-ACK”结束。而你说“发送CREATE-BSS-PFC-ACK PDU启动”，这个“ACK”是SGSN发送的吗？

爱卫生

snap0127 发表于 2012-7-16 11:18
从我的包上来看，SGSN发送“CREATE-BSS-PFC”到收到“CREATE-BSS-PFC-ACK”结束。而你说“发送CREATE-BSS-P ...

原话是这样的“Following a DOWNLOAD-BSS-PFC PDU if there is not an ongoing Delete PFC procedure for that corresponding PFI, the SGSN shall send a CREATE-BSS-PFC PDU to the BSS with a requested Aggregate BSS QoS Profile and start timer T7. ”。

规范是TS48.018 BSSGP协议。

enjoying007

学习了~~~~~~~~