1.1 业务速率类相关1.1.1 业务速率低1.1.1.1 TCP业务速率低 | 当速率低时首先关注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问题定位方案。 | | 如果存在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以上的线程数。 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网卡。 其次需确认当前服务器是否有很多用户同时下载，服务器负荷较重可能影响速率，如果条件允许建议尝试使用空闲服务器进行测试，或同时使用两个FTPApp从两个服务器同时下载。 如果服务器长时间未重启，建议重启服务器（之前出过重启服务器后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.2 UDP业务速率低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相关字样的告警，由App引起的异常告警会非常频繁。 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的调度次数是否为满调度 l 如果调度不满：很多情况下由于业务模型的限制导致下行RLC报给MAC的BO值波动范围较大，如果BO值较低(可以从ATP画图中下行BO图形来看)，那么自然不需要MAC分配较多的资源 l 如果调度次数为满调度：此时看PRB个数，目前的商用终端在SFBC的情况是可以分配到100个PRB，如果不到100也正常，因为此时系统需要调度广播和TA，这些周期调度的元素会导致在ATP上看来PRB不到100（大概会在98～100之间浮动，需要看SIB内容的多少和TA的周期）；在两码字时，由于终端上报UE能力的限制，一个TTI内两个码字的数据和不能超过对应的限制，因此PRB不会到100（在UE能力为3时两个码字大概占用70～80个PRB） 2) 检查关键参数 l LMT->小区->系统带宽：确定当前系统带宽（20M为100PRB；10M为50个PRB） 看在当前带宽下是否已经分配满PRB了而误认为没有满 l LMT->小区->测试开关->MAC测试开关->下行PRB限制值（默认48，指资源分配时最高不能超过48个PRB） + LMT>小区->测试开关->MAC测试开关-PRB限制开关是否同时打开（对于商用终端一般不限制PRB，如果是NBT需要打开并限制为48个PRB） 打开了PRB限制开关且下行PRB限制值本身就比较小，就会出现PRB一直很小的情况。 l LMT->小区->测试开关->MAC测试开关->下行ICIC开关 + LMT->小区->小区算法->小区干扰协调->ICIC算法开关是否同时打开 l 查看是否打开了ICIC开关，由于算法上的限制，PRB也会导致无法分配满带宽（一般来说终端处于小区边缘时，如果当前配置为静态，那最多调33个PRB，这个是默认值，可以进行修改） l LMT->小区->测试开关->MAC测试开关->下行流控开关 如果打开了下行流控开关，PRB个数也不会调满（系统如果限制了AMBR或GBR且速率限制非常小，当打开流控后MAC会用交少的资源进行资源分配以保证不会超过限制值） 在最新的版本中还存在App容量许可功能，也会控制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=0x00000032 PRB分配的个数 .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是DSP CORE5），提前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=0 Harq进程号 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包能够满调度，说明不是App问题。 2) 检查关键参数 l 查看LMT->小区->上下行子帧配置及LMT->小区->特殊子帧配置，根据子帧配置看是否已经满调度了 当前系统的子帧配置和特殊子帧配置：DSUUD特殊子帧不限制满调度600次， DSUDD特殊子帧不限制满调度800次，如果特殊子帧限制例如配置成（3：9：2）那下行调度分别为400次和600次； l LMT->小区->测试开关->MAC测试开关->下行流控开关 是否打开了流控开关，若打开了流控开关调度不满是正常现象 l LMT->小区->测试开关->MAC测试开关->测量GAP处理开关 + LMT->小区->小区异频载波信息中查询是否存在异频邻区 l 如果存在异频邻小区打开测量GAP的时候，也会出现调度不满，因为在终端异频测量时不会处理下行数据，这样会出现调度次数不满 l 对于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的时候它的性能不太好，可以从L2 MAC测试开关上将上行最小调度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的同事一起分析
| 
发表于 2015-12-11 16:12:21
