速率低排查基站侧.docxVIP

业务速率类相关业务速率低TCP业务速率低BLER当速率低时首先关注BLER，尤其是残留BLER。由于FTP是双向的，因此上下行BLER都需要关注。如果初始BLER大于10%或者有残留BLER，需重点关注。对于下行BLER，需要先确认终端侧是否也有BLER。如果终端侧没有bler，则可能是基站ACK译码错误或终端没有检到PDCCH，首先检查测试小区是否配置了异频临小区，如果配置了，需确保“MAC测试开关”中的“测量GAP处理开关”为“打开”。如下图【位于小区—测试开关—MAC测试开关】如果终端侧的BLER与基站接近（TDD反馈采用bundling模式，终端侧bler比基站侧低一些也是合理的），需要确认是否空口环境较差，查看终端侧的SNR和RSRP，好点SNR应大于20；也可尝试基站关闭下行AMC，固定MCS为较低等级看BLER是否消除，如果bler随MCS降低而降低，则可基本确认是环境问题。如果BLER与MCS无关需查看是否有时钟相关告警，通过LMT查看RRU底噪上下行增益等，需提取RRU的65号日志。从LMT查看底噪，如下图提取RRU日志的方法：【菜单--日志管理—RRU日志】对于上行BLER，通过LMT查询上行IOT信息确认是否有干扰，也可以通过关闭上行AMC，固定MCS为较低等级看BLER是否消除，如果BLER随MCS降低而降低，则基本确认是环境问题。如果确认是BLER导致可以参考PL关于BLER问题定位方案。MCS如果存在BLER，则CQI修正会将MCS修低，需要先解决BLER因素。如果没有BLER但MCS较低，需要确认MAC测试开关中的AMC开关是否打开，是否限制最高MCS等级。如果开关设置无异常，需要确认终端反馈的CQI是否正常，通过基站ATP画图“码字0 CQI”可以查看。如果CQI值较低，需要确认终端上报值是否正常，还需检查“信道与信道与过程”配置中的“信道质量指示”参数中 “与ACK同时上报指示”是否设为“支持”。小区—信道过程配置—信道质量指示参数数据包如果底层正常，但速率仍然较低，通过基站ATP画图查看PDCP吞吐量。如果时间允许，可以通过上下行同时打BO进行验证，如果打BO MAC吞吐量正常的话可以基本排除底层问题。如果打BO不好操作，可以使用上下行UDP灌包进行测试。如果PDCP收到的数据量就少，需要查看基站驱动收到的数据量是否正常。驱动NP数据量查看方法：在SCTA控制台上输入命令npsc，其中有两个计数IGRESS_IP_GTPU_PKT_CNT（下行方向）和EGRESS_IP_GTPU_PKT_CNT（上行方向），这两个计数记录了gtpu包的个数，可以间隔10秒钟输入两次npsc得到两个计数cnt1和cnt2，那么粗略的计算方法为（cnt2 – cnt1）* pkt_length * 8 / time （单位：bps），其中pkt_length为报文的长度加上外层头长度，如果不确定长度可以取1500做近似计算，8为一个字节8个比特，time为10秒，这种计算方法有误差，如果误差与pdcp在10M以内，可视为一致。SCTE板卡没有npsc命令，可通过lmt查询【物理设备-机架-机框-板卡-以太网端口】如果怀疑NP有丢包，可以提取SCT板卡上的71号日志。如果怀疑传输、EPC丢包需要各方同时wireshark抓包确认。基站外因素如果上述3步都未发现异常，则需向上逐步排查，分别查看传输是否正常、核心网是否正常、服务器是否正常、终端是否正常等。列出几个常见的可能影响FTP速率的因素供参考。线程数空口环境不稳，难免有少量BLER，且FTP单线程速率随时延增大而减小，因此增大线程数能使线程间的速率互补，保证吞吐量稳定。建议使用40以上的线程数。MTUFTP包的MTU是采用的终端笔记本和服务器MTU的最小值，一般电脑默认MTU是1500，但基站NP芯片对于分片报文的处理存在瓶颈，建议修改MTU为1400。必威体育精装版版本会自动修改MTU为1400.。附MTU查询办法：在服务器或终端侧笔记本wireshark抓包，如果TCP报文的len==1460，则代表MTU是1500。时延时延在TCP协议中有重大意义。因为TCP数据包需要反馈，时延越长，线程的发包量增长速度越慢。一旦发生丢包，该线程速率恢复以及其它线程速率互补也越慢。通常来说缩短时延能提升和稳定速率。空载PING小包时延在30ms以内为宜。基站一些参数配置会影响时延，可以先为下行FTP用户打上行BO，此时的上行时延为最小值，若有速率明显提升或变稳，则可通过LMT修改以下参数来尽可能缩短上行时延：测试开关-MAC测试开关-上行最小分配PRB数：20小区-信道及过程-调度请求参数-DSR上报周期：5小区-信道及过程-BSR参数-BSR上报周期：5如果调整基站参数后pin