iPhone5s刷新微信朋友圈超时分析报告

你还在为手机刷不了朋友圈而烦恼吗？...

背景

某项目的UMTS网络下，客户投诉使用Iphone5s后，经常出现刷新微信朋友圈超时，界面提示”网络连接不成功”， 本文描述了问题排查思路和过程，将涉及到的网元和因素排查了一遍，最终定位为代码问题。解决思路

首先通过不同终端的大量测试发现，当UE在DCH、FACH、PCH状态之间频繁切换后，复现的几率比较大。

分析出问题时的码流，发现UE和RNC两边信令收发是正常的，但是若UE从FACH转到PCH后开始刷新朋友圈，UE会转回FACH，此时就收不到业务数据包，此时若刷新微信朋友圈或者浏览网页都会出现超时情况。

经过代码确认，在UE第一次从FACH转到PCH后，由于代码处理有误，会将一个参数置0，而从PCH转回FACH时不会重配这个参数，从而无法下发数据。实践情况

3.1 控制面信令分析

用iPhone5s和另外款手机复现了5次问题，都是DCH-PCH-FACH-PCH-FACH后出现。

RNC侧失败流程解析

UE经历了DCH-PCH-FACH-PCH-FACH后开始做业务， 1分多钟的时间内不断尝试上网，刷朋友圈都失败。



正常情况下，UE在DCH-PCH-FACH后开始刷新朋友圈，此时上行数据可以连续发送，UE会报4a转入DCH态。



排除上行PRACH解调问题

从UE log里看PRACH前导部分都被基站成功接收，因为AICH Status反馈为MSG_Done。另外站点2块BPC，总共只有3个OTSR-2小区，硬条件处理能力足够，并且基站业务失败统计中没有关于PRACH丢包的统计。

另外，该终端出问题时其他在FACH态的用户上网正常，进而排除PRACH解调问题。



另外，测试的60111和60112小区15分钟力度的RACH信道的利用率到最高只有70%，RACH误码率2%，而且实时PMS测量看在线用户数和RTWP也不高。

RNC侧统计的丢弃的RACH包数是0，所以RNC 接收但是因为 RACH BUFF溢出的丢弃，也为0。



排除上行收包问题

从UE log看，在上不了网的1分多钟，UE上行从SN165发到了SN=170的包。



再结合RNC信令中的收发包统计往前看， iCurrentVrR=171，表示RNC收到了171之前的包，也就是说UE发的171之前的上行包，RNC都收到了，但iCurrentVtA=7，表示RNC下行只发到了SN6的包，就一直没有下发。



从UE来看，UE收到下行的包就是SN为6的包。所以问题出在下行



确定下行发包问题

从UE log看问题时段一直没收到下行的RLC包，1.5分钟后UE 报上行的RLC reset，之后才开始收到下行RLC包，从FACH转回DCH，业务立刻恢复。

从逐级的分析来看应该是PCH-FACH-PCH-FACH之后下行数据包在RNC内部的某个环节卡住了。





3.2 用户面码流分析

由于RNLU下行buffter满足条件会报4a，所以RNC是可以主动检测下行的buffer判决是否让UE转DCH的，该现象应该是都没有发足够的下行数据buffer，否则RNLU会报4a。从而需要从用户面信令进一步确认上行的包是否被用户面正确接收，接收后是否有发下行包。

1

PCH迁入FACH后，RB5上行收到很多包数据（iRlcReceiveFrameNum = 225），但是用户面始终没有发过数据（iRlcSendFrameNum = 0）。

TUciuHelloForwardAck.tUcpmcRbRlcPmRptList.tUcpmcRbRlcPmRptList0.n = 5

TUciuHelloForwardAck.tUcpmcRbRlcPmRptList.tUcpmcRbRlcPmRptList0.elem[0].iRbId = 5

TUciuHelloForwardAck.tUcpmcRbRlcPmRptList.tUcpmcRbRlcPmRptList0.elem[0].iRlcSendFrameNum = 0

TUciuHelloForwardAck.tUcpmcRbRlcPmRptList.tUcpmcRbRlcPmRptList0.elem[0].iRlcReceiveFrameNum = 225

2

RB5的流控可能限制住了，RLC没有发送能力

TUciuHelloForwardAckDbg.tUcpmcRbRlcPmRptListDbg.tUcpmcRbRlcPmRptList0Dbg.elem[0].tAmRlcStats.iRlcRemainBitsNum = 0

TUciuHelloForwardAckDbg.tUcpmcRbRlcPmRptListDbg.tUcpmcRbRlcPmRptList0Dbg.elem[0].tAmRlcStats.iRlcCanSendBitsNum = 0

3

先怀疑是不是FACH流控有问题，是否CMAC流控限制住了。可是从CMAC的统计看给这个FACH用户分配credit为284没有问题。

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iCmCH_PI = 1

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iUciuReqUsrBufSize = 201978

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iCciuAllotCredits = 284

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iUciuReqNum = 517

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iCciuRespNum = 129

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iCciuRecvSduNum = 0

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iCciuRecvPduNum = 0

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iCciuSendSduNum = 46

TCciuUeHelloForwardAckDbg.tCciuUePmStatList.elem[1].iCciuSendPduNum = 46

4

进一步走查代码发现wTbSize被限制到0：

（1）DMAC在数据发送的时候，先要向RLC查询待发送的数据量，如果发现RLC没有数据则不会给CMAC发送数据。

（2）而判断是否有数据的条件是包数和包长是否为0，其中数据包长度来自于逻辑信道下的变量ptLoCh->wTbSize

（3）FACH->PCH 的时候，释放了RB5的RLC逻辑信道的相关缓存，然后在PCH->FACH的时候，会执行下面的函数调用链，将wTbSize 设置为0;

（4）因为这种场景下RB5的RLC无需重建，导致wTbSize不会重新赋值，那么就一直维持为错误的数值0。解决与预防

由于函数LogiChQueueInit 只在从PCH态迁出恢复RLC内存以及新建RLC逻辑信道的时候才调用，新建RLC逻辑信道随后就对ptLoCh->wTbSize 赋值，因此没有影响，针对问题修改了代码发在补丁中发布。总结

当前版本的PCH内存优化功能增加了逻辑信道缓存的释放，导致引入了此故障。

影响范围：同时包含下面两种流程时会触发

1、CELL-DCH->PCH->FACH的下行RLC size 是336。

2、FACH->PCH->FACH，下行RLC size不变，RLC不重配。

    关注 无限性能COP