速率低排查基站侧详解.docx
《速率低排查基站侧详解.docx》由会员分享，可在线阅读，更多相关《速率低排查基站侧详解.docx（34页珍藏版）》请在冰豆网上搜索。
速率低排查基站侧详解
1.1业务速率类相关
1.1.1业务速率低
1.1.1.1TCP业务速率低
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画图“码字0CQI”可以查看。
如果CQI值较低，需要确认终端上报值是否正常，还需检查“信道与信道与过程”配置中的“信道质量指示”参数中“与ACK同时上报指示”是否设为“支持”。
小区—信道过程配置—信道质量指示参数
数据包
如果底层正常，但速率仍然较低，通过基站ATP画图查看PDCP吞吐量。
如果时间允许，可以通过上下行同时打BO进行验证，如果打BOMAC吞吐量正常的话可以基本排除底层问题。
如果打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以上的线程数。
MTU
FTP包的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
如果调整基站参数后ping时延仍然很大，需排查核心网和服务器（传输的时延一般较小）。
服务器
首先需确认服务器是千M网卡。
其次需确认当前服务器是否有很多用户同时下载，服务器负荷较重可能影响速率，如果条件允许建议尝试使用空闲服务器进行测试，或同时使用两个FTP软件从两个服务器同时下载。
如果服务器长时间未重启，建议重启服务器（之前出过重启服务器后ping时延缩短10ms的情况）。
核心网
如果上下行BLER很小，但从终端侧、S1的核心网出口或基站入口wireshark抓包发现很多out-of-order或retransmission包时，可以怀疑核心网问题。
核心网配置错误也会影响TCP速率，参看近期定位的一个问题“【问题描述】研究院要求多用户FTP业务下载，要进行400UE的TCP业务压力测试从目前看FTP业务速率仅能达到40M左右。
【问题定位】当前配置，S1U接口和SS58接口都会对外呈现，并且网段是一样的都是192.168.172.x这样又变成了一个负荷分担模式，数据也有可能从ss58绕出去，形成环路，从而影响TCP业务速率”
如果连接同一核心网的其他多个站点均能正常峰速，则可初步排除核心网问题。
终端笔记本性能
终端笔记本性能对FTP速率也有较大影响，曾多次出现UDP灌包能到峰速但FTP到不了的情况，然后什么都不变更换终端笔记本后FTP速率提升20M的情况。
请尽量使用性能好的笔记本。
如果条件允许，出现速率低问题后建议更换终端笔记本看速率是否改善。
定位手段
1.抄送ATPlog.O_MACDL_CCH_DATA_INFO、O_MACDL__PDSCH_PARA_DATA_INFOO_MACDE_PUCCH_INFO、O_CCMAC_PUSCH_DATA_CRC_IND、O_MACDE_PUSCH_INFO、O_CCMAC_PUCCH_ACK_IND、O_CCMAC_PUSCH_ACK_IND
2.配置L2的远程日志类型为Ping日志，提取67号日志。
1.1.1.2UDP业务速率低
1.1.1.2.1下行BLER高导致速率业务低。
现象一：
FTP业务速率低，通过ATP或终端查看下行BLER比较高，特别是还存在残留BLER。
1）此现象多是空口质量问题导致的，可以通过尝试关闭AMC，并将MCS固定为16（16QAM）、9（QPSK）等频谱效率比较低的值，看能否降低下行BLER；
2）如果通过降低MCS的方法可以消除BLER，那么可以通过修改LMT->小区小区算法->调度->MAC下行算法参数->设置下行初始BLER。
其默认值是10（较新版本是5）将其值降低。
现象二：
终端位置非常好（SNR23~30、RSRP80~95），曾经测试过程中无BLER且到达过峰值速率，周边环境未发生变化，但就是存在BLER。
此时可能机房操作人员修改过参数，导致异常出现，因此需要核对如下参数。
1）查看当前的MCS（通过ATP查看），查看MCS与BLER的变化趋势，看MCS降低是否可以使BLER降低。
2）当前的反馈模式为Bundling还是Multiplexing（LMT->小区->信道过程配置->PUCCH信道->ACK反馈模式）；在目前测试场景中，一般默认配置为Bundling；如果配置成了Multiplexing，一定要问询终端是否支持Multiplexing，如果不支持肯定会出现反馈异常。
3）当前是否支持CQI与ACK同时上报（LMT->小区->信道过程配置->信道质量指示参数->与ACK同时上报指示）；大数情况NB配置为支持；当配置为不支持时，有些终端可能会出现处理上的异常，CQI修正修的不准，MCS较高，容易引起BLER。
4）在LMT查看告警是否存在L2有关MACDE、ACK反馈异常或PL有关PUCCH、PUSCH相关字样的告警，由软件引起的异常告警会非常频繁。
5）在LMT上查看是否存在RRU通道故障告警
6）抓取ATPlog，抄出一下消息
O_MACDLCFG_CCH_DATA_INFO（6203）
O_MACDLCFG_PDSCH_PARA_DATA_INFO（6204）
O_MACDE_PUCCH_INFO（6205）
O_MACDE_PUSCH_INFO（6206）（存在上行时需要）
O_CCMAC_PUCCH_ACK_IND（6207）
O_CCMAC_PUSCH_ACK_IND（6209）（存在上行时需要）
注：
a.如果上行业务满调度（看ATP上行调度次数画图），这时看下行业务的反馈就只需要看O_CCMAC_PUSCH_ACK_IND（6209）；
b.如果没有上行业务，此时反馈只需抄消息O_CCMAC_PUCCH_ACK_IND（6207）；
c.如果既有上行也有下行，像FTP这种类型的业务，就需要两个消息同时抄送了。
LOG分析：
1.1.1.2.2占用的PRB数目少导致速率业务低。
1）需要看该UE的调度次数是否为满调度
●如果调度不满：
很多情况下由于业务模型的限制导致下行RLC报给MAC的BO值波动范围较大，如果BO值较低（可以从ATP画图中下行BO图形来看），那么自然不需要MAC分配较多的资源
●如果调度次数为满调度：
此时看PRB个数，目前的商用终端在SFBC的情况是可以分配到100个PRB，如果不到100也正常，因为此时系统需要调度广播和TA，这些周期调度的元素会导致在ATP上看来PRB不到100（大概会在98～100之间浮动，需要看SIB内容的多少和TA的周期）；在两码字时，由于终端上报UE能力的限制，一个TTI内两个码字的数据和不能超过对应的限制，因此PRB不会到100（在UE能力为3时两个码字大概占用70～80个PRB）
2）检查关键参数
●LMT->小区->系统带宽：
确定当前系统带宽（20M为100PRB；10M为50个PRB）
看在当前带宽下是否已经分配满PRB了而误认为没有满
●LMT->小区->测试开关->MAC测试开关->下行PRB限制值（默认48，指资源分配时最高不能超过48个PRB）+LMT>小区->测试开关->MAC测试开关-PRB限制开关是否同时打开（对于商用终端一般不限制PRB，如果是NBT需要打开并限制为48个PRB）
打开了PRB限制开关且下行PRB限制值本身就比较小，就会出现PRB一直很小的情况。
●LMT->小区->测试开关->MAC测试开关->下行ICIC开关+LMT->小区->小区算法->小区干扰协调->ICIC算法开关是否同时打开
●
查看是否打开了ICIC开关，由于算法上的限制，PRB也会导致无法分配满带宽（一般来说终端处于小区边缘时，如果当前配置为静态，那最多调33个PRB，这个是默认值，可以进行修改）
●LMT->小区->测试开关->MAC测试开关->下行流控开关
如果打开了下行流控开关，PRB个数也不会调满（系统如果限制了AMBR或GBR且速率限制非常小，当打开流控后MAC会用交少的资源进行资源分配以保证不会超过限制值）
在最新的版本中还存在软件容量许可功能，也会控制UE的吞吐量，也可能会导致PRB较少。
3）ATPlog
如果排查了以上原因还没有解决，抄出以下ATPlog：
O_MACDLCFG_CCH_DATA_INFO（6203）
O_MACDLCFG_PDSCH_PARA_DATA_INFO（6204）
分析LOG：
O_MACDLCFG_CCH_DATA_INFO（6203）消息中的
mac_pdcch_para.data.MAC_CchDci1a_10M.bMcs=0x00000004指示了当前MCS的大小
O_MACDLCFG_PDSCH_PARA_DATA_INFO（6204）消息中的
.dl_ue[0].codeword_num=0x00000001字段可以看出此时是几个码字传输
.dl_ue[0].mac_dl_codeword_para[0].tb_size=0x00000E28字段可以看出tbsize大小
.dl_ue[0].mac_dl_codeword_para[0].modu_type字段可以看出调制方式
.dl_ue[0].mac_dl_codeword_para[0].vrb_num=0x00000032PRB分配的个数
.dl_ue[0].mac_dl_codeword_para[0].vrb_index[]={...}PRB的分布状况
根据Log可以看出MAC下行分配的PRB和具体VRB分配情况。
4）在其他手段不方便或打算进一步分析问题时，也可以通过L2远程日志，V320版本的LMT上记录8：
下行资源分配主流程和9：
行资源分配异常两项，并在LMT->日志管理->设备日志->板卡日志对应的位置找到MAC的处理器（V310是BPOE1处理器，V320是DSPCORE5），提前67号日志。
通过提取的日志可以查看如下打印：
DLTFRCFINISH:
CurHalf=0,CurSub04=0,AirHalf=0,AirSub04=3,CellId=0,UeId=0,ProcId=0,mimotype=0,elementType=9,PrbNum=48
......RetxFlag0=0,Mcs0=27,Rv0=0,RetxFlag1=0,Mcs1=0,Rv1=0
ProcId=0Harq进程号
mimotype=0当前的MIMO方式为SFBC
elementType=9当前的元素为新数据
PrbNum=48资源分配为48
RetxFlag0=0为新传
Mcs0=27当前码字MCS为27
通过上面的打印来查看资源分配的情况。
1.1.1.2.3调度不满导致的业务速率低：
1）一般做FTP下载业务时可能由于BLER或服务器等原因造成调度不满，此时可以通过服务器下行灌UDP包的方式查看是否能满调度，如果灌UDP包能够满调度，说明不是软件问题。
2）检查关键参数
●查看LMT->小区->上下行子帧配置及LMT->小区->特殊子帧配置，根据子帧配置看是否已经满调度了
当前系统的子帧配置和特殊子帧配置：
DSUUD特殊子帧不限制满调度600次，DSUDD特殊子帧不限制满调度800次，如果特殊子帧限制例如配置成（3：
9：
2）那下行调度分别为400次和600次；
●LMT->小区->测试开关->MAC测试开关->下行流控开关
是否打开了流控开关，若打开了流控开关调度不满是正常现象
●LMT->小区->测试开关->MAC测试开关->测量GAP处理开关+LMT->小区->小区异频载波信息中查询是否存在异频邻区
●
如果存在异频邻小区打开测量GAP的时候，也会出现调度不满，因为在终端异频测量时不会处理下行数据，这样会出现调度次数不满
●对于FTP业务经常由于下载流程数少、上下行出现高残留BLER、MTU、服务器发包少等原因造成下行调度不满，此时要将下载进程增大，采取手段降低上下行BLER，核查MTU，通过抓包捕获服务器发包异常情况。
3）ATPlog
如果排查了以上原因还没有解决，抄出以下ATPlog：
O_MACDLCFG_CCH_DATA_INFO（6203）
O_MACDLCFG_PDSCH_PARA_DATA_INFO（6204）
O_CCMAC_PUCCH_ACK_IND（6207）
O_CCMAC_PUSCH_ACK_IND（6209）
1.1.1.2.4上行BLER高导致业务速率低
现象一：
上行BLER过大如100%、过小如10%以下，BLER不是稳定值
1）调衰减
2）可能是因为PL在检测小PRB的时候，比如4，5这么小的PRB的时候它的性能不太好，可以从L2MAC测试开关上将上行最小调度PRB个数设置成12这种稍微大点的值，如果仍然没有改善，寻找PL的同事来协助定位
现象二：
上行BLER值比较固定，比如20%、15%
1）调衰减
2）如果调衰减也不管用很有可能是调度出了问题，抄送6203（O_MACDLCFG_CCH_DATA_INFO），6212（O_CCMAC_PUSCH_DATA_IND）消息;抄送方法如下：
1.登陆ATP，打开消息跟踪-->测试消息设置
2．L2接口消息抄送-->L2测试消息输出控制，将右侧O_CCMAC_PUSCH_DATA_IND、O_MACDLCFG_CCH_DATA_INFO消息前画“√”，然后点击确定。
Ø分析LOG，查看LOG中6212（O_CCMAC_PUSCH_DATA_IND）消息中CRC译错的子帧是不是有规律的。
消息结构如下：
crci=0表示正确，crci=1表示译错。
CRC译错的子帧是不是有规律指的是不是都在一个子帧译错、或者隔几个子帧就译错等。
如果是有规律的，计算出周期是多少，看是否与CQI，SR，SRS，测量GAP的任何一种周期一样。
如果是测量GAP导致的BLER，这样应该是L2的MAC测试开关的测量上报开关给关了，但是高层又配置了测量GAP，这个时候把L2这个开关打开就行，并且还要和测试人员问清楚他是不是想配测量GAP；如果CRC出错和CQI，SR，SRS的周期一致了，这个很有可能是MAC调度的问题，找MAC内部人员分析一下LOG，走查一下代码。
Ø如果用户比较多，抄送LOG或者日志（打开5：
上行TB内容异常开关），观测是固定某几个用户出错，还是全面出错，然后再具体分析一下，不过也是要带上PL的同事一起分析
2.上行PRB个数少定位步骤
Ø检查LMT上MAC测试开关中“上行PRB限制值”是不是过小，一般这个值设置的是48。
如果过小的话首先要询问测试人员将其调小的意图，如果没有特别需求的话，将这个值放大。
甚至如果终端不是NBT的话，这个值调整成不限制。
Ø如果不是上述原因，用ATP抄出6203（O_MACDLCFG_CCH_DATA_INFO），6212（O_CCMAC_PUSCH_DATA_IND）消息，看终端上报的BSR是否正常，过小的话说明终端向上传输的数据本身就不是很多，上行PRB也不会调度很大。
可以试着打个上行BO看值又没有改变。
看终端上报的BSR是否正常方法如下：
看终端上报的BSR是否正常方法如下：
下图为ATP抄出的6212（O_CCMAC_PUSCH_DATA_IND）消息，红色标出的MAC_LCID_SHORT_BSR=0xff，其中低六位是终端上报的BSR，最大是63。
BSR越大说明终端数据越饱满，如果BSR较小，则说明终端数据本身就不是很多，所以上行PRB也不会调度很大。
Ø确定终端的用户能力等级，小于3的能力等级，是没有能力调度过高的PRB的，用户能力过小的原因有可能是真的小，也有可能是高层配置问题，这个需要和测试人员沟通一下终端是什么,一般来说终端都是不会太低的用户等级，然后就是打开日志，从日志中能看到上行的用户能力
Ø如果以上问题都排除，则抄送MAC的67号日志（打开3：
上行资源分配异常抄送开关），发给MAC同事进一步分析
Ø
Ø如果用户比较多，抄送LOG或者日志（打开3：
上行资源分配异常抄送开关），观测是哪个用户的PRB少了。
方法如下：
ATP抄出6206（O_MACDE_PUSCH_INFO）消息，通过分析消息中每个用户的first_prb_index与prb_num分析到底是哪个用户PRB少了，如果每个子帧都占满了带宽的PRB，只是对于某个用户在某个子帧调度PRB少了，正常现象；如果单子帧总的PRB个数都没占满的话，观测是不是调度了Sr触发的调度，这种调度的特点是周期的出现调不满PRB，这样就需要分析SR触发的原因，周期的大小大概是100多MS以上，如果SR过多，找PL的同学；如果周期是几十MS，可能是虚检问题，这个时候抄送6203，6212消息，观测SR触发的调度上行数据内容是否饱满（方法参考本节步骤二），饱满的话证明不是虚检，不饱满的话需要找PL的同事来确认虚检问题。
如果不是虚检问题，调整一下单子帧上行调度的PRB上限
3.上行调度不满定位步骤
Ø首先打开ATP画图中“上行调度次数”画图，查看调度次数到底是多少，离调满差多少。
满调度计算方法（如DSUDD）：
5ms调一次--->1秒200次
Ø用ATP抄出6203（O_MACDLCFG_CCH_DATA_INFO），6212（O_CCMAC_PUSCH_DATA_IND）消息，观测终端上报的BSR值是不是正常（方法参照1.2节所讲）或是观测MAC数据内容里面PADING是不是比较多（即看LOG里6212消息中u8data字段是不是有很多的0），如果BSR过小或是PADING过多那么调度是会不满，让测试人员灌大包，或者我们打个上行BO
Ø如果调度次数只是少了一些，可以调整一下CCE大小，调整成4，或者加大CFI
Ø调度次数是否稳定（比如DSUUD格式下为400），可能是配置了GAP，需要检查该小区是否配置了异频临小区。
Ø检查是否配置了DRX，可以直接关闭LMT->小区->信道及过程配置->DRX参数中的DRX配置有效性开关来确认当前调度不满是否与DRX相关。
Ø确认AMBR参数，目的是为了确认调度不饱满是受流控影响，可先通过LMT的MAC测试开关关闭流控功能确认。
4.上行MCS过低定位步骤
Ø在ATP上打开上行MCS画图，查看MCS到底是多少（最大值23）。
如果MCS低了，确定是否有BLER，BLER越高，MCS越低。
如果BLER高了，参照1.1节首先解决BLER问题。
Ø若没有BLER，看是否是SR调度的比较多，若是，则关闭MAC测试开关中SRB的MCS限制开关。
看SR调度比较多的方法：
用ATP抄出6206（O_MACDE_PUSCH_INFO）消息，查看消息中MCS等级，如果MCS等级为6通常都是SR调度比较多。
消息如下所示：
Ø若没有BLER，MCS只比预期的最大值少1，确认sounding是否配在上行子帧（LMT->信道及过程配置->探测参考信号参数->SRS时域发送位置->仅up位置发送）
Ø如果用户比较多，抄送LOG或者日志（打开3：
上行资源分配异常抄送开关）， 观测是哪个子帧或者哪个用户上行MCS少了，具体分析。
对于UDP业务而言，除了可以提取Ping日志外，还可以提取18:
tfrcexception|调度及资源分配过程中的异常/。
在外场维护的过程中，遇到无法解决的问题，在时间允许的情况下，尽量帮忙将下表信息填完整，发回给研发分析。
信息类别
信息名称
填写内容
测试场景相关
基站站型（宏站或室分）
版本信息
测试场景及用户数量
终端型号
下行的RSRP（终端测查看
升级会员 