排查思路和方法)
本文档分速率不达标问题话音mos值低ue接入失败等问题分为无线测试和有线测试单ue测试和多ue测试。其中速率问题涉及因素较多需要重点分析无线速率测试主要从BLER开始关注有线速率测试到不了峰值,一般BLER的影响较小可以从RB利用率开始排查。单UE要达到峰值必须要达到以下条件频带利用接近占满全带宽即RB 100/75/50/25大量数据待发送、时间上占满全部发送子帧、发送的TBS最大无BLER各层无重传消耗RB资源下面从eNB基站的角度来具体分析问题如何定位。上行速率问题1 不能到峰值的影响因素1. 1 BLER首先需要定位的是BLER影响上行BLER或CRC失败的因素有很多与控制信令相关确认上行衰减是否合适确认是否噪声过大接收信号功率小是否有频偏接收信号质量差同步位置较差TA不准小PRB解码性能问题初传TB的有效信道码率尝试关闭上行AMC固定MCS为较低等级看BLER是否消除如果BLER随MCS降低而降低则基本确认是环境问题,解调能力受限查看FAPI VSM_MEAS_IND消息的NI值确认是否受到了同频邻区干扰如果BLER不变需要从上述可能的原因逐个分析排除。还有一种排除环境问题的情况方法就是同样的基站换一种带宽测试确认有无同样的现象。如果没有则可确认是在此带宽下才出的问题问题和PDCP RLC上层无关。若UE与基站侧BLER不一致基站侧有BLERUE侧无BLERUE对于DCI0解码错误或者没有收到DCI0尝试修改CCE 8增大PDCCH聚合等级。2 RB利用率看频谱宽度占满情况这个可以从路测终端或者ue模拟器的RB利用率显示窗口直接观察到此外还有L2 current 打印ulSelUeNum ulRbNum。对于多UE的上行业务FDD制式单帧调度4ue ulSelUeNum就是10s接近40000次 RB利用ulRbNum达不到100%是合理的除开对PUCCH PRACH的RB资源预留还存在上行分配RB的限制这也可能导致多UE上行 RB分配的空洞。3 MCS确保MCS能选到最高阶使发送的TBS最大频谱效率最高这部分跟UE能力有关例如我们的基站支持100RB ,cat4 的UE要达峰值的话MCS23TBSIZE51024。如果存在上行BLERAMC会将MCS修低需要先解决BLER因素。如果没有BLER但MCS较低且一直是固定值需要确认是否限制固定了MCS等级具体见基站cli参数。4 BSR1若BLER问题不大则需要查看是否数据源充足其次看基站侧的调度是否满足了UE的需求是否存在上行上报了缓存而不调度的情况比如多UE时pdcch资源申请失败此时注意一下CFI配置情况通过cli查看下面参数Device.Services.FAPService.1.CellConfig.LTE.RAN.PHY.X_001710_SelfConfigurationEnabled设置为falseCFI默认配置为1开关设置为trueL3会根据带宽和OperationMode动态配置CFI我们需要关注UE上报的BSR不能存在BSR很小的情况具体打印见基站新增log。2尝试修改SR/BSR周期查看速率有无明显改观BSR周期最好是10ms或5ms如果单UE测试FTP性能SR周期最好是5ms。5其它因素对于BLER正常MCS无限制或者SNR或ulCQI较好的情况下主要排查上层或者测试传输环境问题具体的参考第3章。2 多UE综合速率很低的测试场景按照上述步骤查看单个UE的情况如果没有BLER或者极少则存在RB利用率或者DCI0调度不够的问题在按照下表逐个排除可能原因怀疑对象分配RB不足/DCI0调度不足数据源不足速率环境排查/FTP服务器设置/UDP流量SR/BSR周期调整控制信道影响PRACH/PUCCH/PUSCH资源重叠预留资源不够功控功控算法选择RSSI/PHRUE发射功率限制(P0)多UE并发业务公平性不满足UE速率不均衡QCI等级不一致调度算法选择(PF/RR/MAXCI)RB利用率小ICIC打开跳频QOS速率EPC或者UE限速AMBR基站DSP处理能力单帧解码超时/数据丢弃2. 下行速率问题下行吞吐基本围绕BLER、 MCS 、RB分配、单帧调度ue数等因素展开分析但下行速率能否上去也与上行链路质量(反馈)也有很大的关系。2.1 不能到峰值的影响因素2.1.1 下行BLER当速率低时首先关注BLER尤其是配置为UM模式时有残留BLER影响会比较大。由于FTP是双向的因此上下行BLER都需要关注。如果初始BLER大于10%或者重传几次都解码不对可能有协议问题首先查看基站log是否有调度过程的错误打印。对于下行BLER需要先确认终端侧是否也有BLER。如果终端侧没有BLER则可能是基站ACK译码错误或终端没有检到PDCCH。还有就是初传 TB 的有效信道码率不能大于 dl 0.93。如果终端侧的BLER与基站接近需要确认是否空口环境较差查看终端侧的SNR和RSRP好的测试点SNR应大于20尝试基站关闭下行AMC固定MCS为较低等级看BLER是否消除如果BLER随MCS降低而降低则可基本确认是环境问题。如果BLER与MCS无关,且无论降低到多少都存在固定的BLER则应该是SCH或L1的问题需具体分析。如果返回的是DTX 而UE侧无BLER则是ACK反馈L1解码有问题通过FAPI抓包和基站日志确认是PUCCH上的反馈有问题还是PUSCH上携带的ACK解码有问题查看PUCCH的功率是否异常如果返回的是NACK则需要查看重传的次数是重传一次能解对还是重传3次都解码不对还是全都是重传一次就解码对了其次看子帧是不是只是某一个子帧的都是NACK其余子帧的都能解对寻找出规律更容易解决问题。2.1.2 下行MCS如果存在BLER则AMC会将MCS修低需要先解决BLER因素。如果没有BLER但MCS较低且一直是固定值需要确认是否限制了最高MCS等级见基站cli配置如果设置无异常需要确认终端反馈的CQI是否正常见L2 current。如果CQI值较低需要确认终端上报值是否正常或者基站设置的RS参考功率设置很小导致UE上报的就很小。2.1.3 下行数据量如果底层正常但速率仍然较低通过基站新增打印查看RLC报的缓存报告BO如果要达峰值理论上每次的缓存量应较大。若tbsize1的值为0则表示当前调度为单码字确认TM模式及UE返回的RI是否1。如果环境允许可以通过下行大数据量UDP灌包进行缓存测试。如果缓存一直不够或者时大时小则按照本文第3部分的介绍排查上层或测试环境。2.2 速率低的原因列举未达峰值速率/多UE总吞吐低可能原因怀疑对象BLER干扰/其它数据源不足速率环境排查/FTP服务器设置/UDP流量PDCP discardTimer设置是否合理(1500ms)测试点是否合适CQI反馈是否较小/UE处于高速移动CQI不稳UE能力CAT等级比较小多UE并发业务公平性不满足UE速率不均衡QCI等级不一致调度算法选择(PF/QOS/MAXCI)RB利用率小下行频选打开/ICIC打开DRX功能打开/PDCCH漏检CCE分配失败多UE处理超时基站DSP处理能力L2加解密/单帧L1解码超时/调度不及时下行数据丢弃QOS速率EPC或者UE限速AMBRMIMO模式参数传输模式设置TM3未调度双码字/UE上报RANK 2(双天线RSRP相差不大于3dB应该都上报2)上行反馈通道PUCCH预留资源不够导致HARQ反馈解码错误/功控能否改善上行信道质量3. 上层和环境因素如果从空口的角度均未发现异常则需向上逐步排查分别查看S1U PDCP RLC传输是否正常、核心网是否正常、服务器是否正常、终端是否正常等。列出几个常见的可能影响FTP速率的因素供参考。0 )L2协议实现加密队列满丢包 循环队列丢包 pdcp队列满丢包 内存门限丢包 lateDatReq过高 收到ue rlcStatusReport少下行dlrlcNackNum rlcRetxSize macPadSize S1U收到GTP包SN不连续上行 ulrlcNackNum观察各节点速率统计是否匹配1 )线程数空口环境不稳难免有少量BLER且FTP单线程速率随时延增大而减小因此增大线程数能使线程间的速率互补保证吞吐量稳定。建议使用10以上的线程数下载。检查iperf命令参数。2) MTU设置FTP包的MTU是采用的终端笔记本和服务器MTU的最小值一般电脑默认MTU是1500但不同基站对于分片报文的处理也许存在瓶颈建议将MTU或MSS改小,规避分片和重组引发的异常。在服务器或终端侧笔记本wireshark抓包如果TCP报文的len1460一般代表MTU是1500。(Fragmented IP protocol、TCP segment of a reassembled PDU)3)时延时延在TCP协议中有重大意义。因为TCP数据包需要反馈时延越长线程的发包量增长速度越慢。一旦发生丢包该线程速率恢复以及其它线程速率互补也越慢。通常来说缩短时延能提升和稳定速率。空载PING小包时延在30ms以内为宜。基站一些参数配置会影响时延比如打开预调度功能此时的上行时延为最小值若有速率明显提升或变稳则可通过基站CLI修改SR/BSR参数来尽可能缩短上行时延如果调整基站参数后ping时延仍然很大需排查EPC跟基站的网线连接核心网和服务器之间传输的时延一般较小服务器ping核心网一般在1ms级别。4)服务器首先需确认服务器是千兆网卡其次需确认当前服务器是否有很多用户同时下载服务器负荷较重可能影响速率如果条件允许建议尝试使用空闲服务器进行测试或同时使用两个FTP软件从两个服务器同时下载。如果服务器长时间未重启建议重启服务器。5)核心网如果上下行BLER很小但从终端侧、S1的核心网出口或基站入口wireshark抓包发现很多out-of-order或retransmission包时可以怀疑核心网问题。其次核心网配置是否进行了EPC参数修改限速了参数没改回导致测试速率上不去。如果连接同一核心网的其他多个站点服务器均能正常峰速则可初步排除核心网问题。6)终端笔记本性能终端笔记本性能对FTP速率也有较大影响曾多次出现UDP灌包能到峰速但FTP到不了的情况然后什么都不变更换终端笔记本后FTP速率提升20M的情况。请尽量使用性能好的笔记本,如果条件允许出现速率低问题后建议更换终端笔记本看速率是否改善。7)调试工具对于linux平台运行的协议栈可通过top和Ftrace等命令查看各线程占用CPU的负荷情况以及各线程抢占多核的情况wireshark抓包的专家信息和图形统计有时候很有用(dup ack/tcp fast retransmission等)查看hexgon和krait之间FIFO通信是否有异常统计4 . 话音质量问题如果出现VOLTE话音质量差的现象则肯定是带宽、时延、丢包率、抖动哪一方面没有达到要求一般从下面的步骤进行查看查看基站log的信令流程是否存在切换重建立专用承载建立失败掉线甚至重定向重选等这些过程对语音的影响大于对数据的影响确定流程是否合理确定eSRVCC的2G3G邻区或参数是否配置合理在LTE覆盖边缘是否平滑切换到CS域避免掉话或重定向查看4G邻区或门限等参数是否配置合理查看基站log的数据面统计查看L2上层统计是否正常具体见第3章分析查看QCI1流量是否正常关注GBR MBR参数设置根据错误打印或统计确定ROHC流程是否有问题查看基站oam V1或网管导出的qci1 kpi统计,里面有网络侧和空口统计确定是网络侧问题还是空口问题结合在基站网口或IMS SBC等关键节点进行wireshark抓包分析RTP数据的时延(是否超过100ms)丢包或抖动情况分析SIP信令情况如果是空口问题导致的丢包或时延问题则需要关注基站的覆盖和干扰实测结果表明RSRP大于-113dBmSINR大于-3dB可以达到理想的VoLTE语音质量解决PCI冲突重叠覆盖等问题适当增强RS功率。查看基站BLER或CRC统计如果失败率比较高可以先关闭DRX功能和固定低MCS等方式验证更多具体见第1章和第2章空口问题的排查分析。如果是网络侧问题导致则和基站无关只需配合如果是rohc流程失败导致的问题可以通过修改头压缩算法关闭加解密功能进行验证问题在家里复现调试。5. 随机接入问题查看基站log分析信令流程确定ue接入失败最直接的原因是否是SIM未开LTE功能用户过多拥塞参数配置错误等原因是否被叫未收到paging如果接入信令过程到了msg5左右因为RLC最大重传导致失败则关注覆盖差干扰大等因素具体见上面几个章节关于空口介绍如果接入信令过程只到了msg3附近或没有收到msg3则需要关注随机接入过程的有关参数查看fapi log到了哪一步查看基站cellCb-rachThreshold接入门限参数查看SIB2的prach-ConfigIndex 3 和 prach-FreqOffset5参数(任意sfn,sf 1,preamble format 0:占一个子帧)PRACH Mask Index , numberOfRA_Preambles 12, messageSizeGroupA, ResponseWindowSize10, maxHARQ_Msg3Tx4等参数是否被修改过是否是默认配置关注随机接入功率有关参数是否合理比如lte-rrc.preambleInitialReceivedTargetPowerlte-rrc.powerRampingStep等通过基站错误打印结合fapi确定上述哪个参数存在问题或哪个代码流程有问题在家里复现调试验证如果还是不能确定原因则外场打开新增log开关或将rlog打印等级改成6获得msg1 msg2 msg3 msg4的统计或打印详细信息查看随机接入详细流程如果还是不能看出问题则进行对比测试重启或更换手机等具体细节请看第3章和第6章先发现规律再定位原因6. 确认环境问题的方法6.1 UDP灌包进行下行UDP灌包如果达到峰速说明下行通路正常同时进行上行UDP灌包如果也能正常峰速同时结合基站ping包打印功能如果时延也正常则80%排除基站问题。重点关注终端、核心网、传输。6.2 更换基站对比测试使用不同厂家或硬件平台基站同一服务器进行测试能达到峰速则基本排除核心网和服务器问题。重点关注基站和终端、传输。6.3 更换终端对比测试如果使用其他终端或其他终端笔记本在同一地点进行测试能达到峰速则基本排除网络问题。重点关注终端或终端笔记本、传输。6.4 排查传输线缆如果通过上述方法基本排除基站、终端、核心网问题则需重点关注传输。一是传输可能丢包需多方(EPC、ENB进出)同时wireshark抓包确认.
LTE/5G常见业务问题(比如速率低 /MOS＜3/随机接入失败等 )排查思路和方法
发布时间：2026/5/21 3:59:03
本文档分速率不达标问题话音mos值低ue接入失败等问题分为无线测试和有线测试单ue测试和多ue测试。其中速率问题涉及因素较多需要重点分析无线速率测试主要从BLER开始关注有线速率测试到不了峰值,一般BLER的影响较小可以从RB利用率开始排查。单UE要达到峰值必须要达到以下条件频带利用接近占满全带宽即RB 100/75/50/25大量数据待发送、时间上占满全部发送子帧、发送的TBS最大无BLER各层无重传消耗RB资源下面从eNB基站的角度来具体分析问题如何定位。上行速率问题1 不能到峰值的影响因素1. 1 BLER首先需要定位的是BLER影响上行BLER或CRC失败的因素有很多与控制信令相关确认上行衰减是否合适确认是否噪声过大接收信号功率小是否有频偏接收信号质量差同步位置较差TA不准小PRB解码性能问题初传TB的有效信道码率尝试关闭上行AMC固定MCS为较低等级看BLER是否消除如果BLER随MCS降低而降低则基本确认是环境问题,解调能力受限查看FAPI VSM_MEAS_IND消息的NI值确认是否受到了同频邻区干扰如果BLER不变需要从上述可能的原因逐个分析排除。还有一种排除环境问题的情况方法就是同样的基站换一种带宽测试确认有无同样的现象。如果没有则可确认是在此带宽下才出的问题问题和PDCP RLC上层无关。若UE与基站侧BLER不一致基站侧有BLERUE侧无BLERUE对于DCI0解码错误或者没有收到DCI0尝试修改CCE 8增大PDCCH聚合等级。2 RB利用率看频谱宽度占满情况这个可以从路测终端或者ue模拟器的RB利用率显示窗口直接观察到此外还有L2 current 打印ulSelUeNum ulRbNum。对于多UE的上行业务FDD制式单帧调度4ue ulSelUeNum就是10s接近40000次 RB利用ulRbNum达不到100%是合理的除开对PUCCH PRACH的RB资源预留还存在上行分配RB的限制这也可能导致多UE上行 RB分配的空洞。3 MCS确保MCS能选到最高阶使发送的TBS最大频谱效率最高这部分跟UE能力有关例如我们的基站支持100RB ,cat4 的UE要达峰值的话MCS23TBSIZE51024。如果存在上行BLERAMC会将MCS修低需要先解决BLER因素。如果没有BLER但MCS较低且一直是固定值需要确认是否限制固定了MCS等级具体见基站cli参数。4 BSR1若BLER问题不大则需要查看是否数据源充足其次看基站侧的调度是否满足了UE的需求是否存在上行上报了缓存而不调度的情况比如多UE时pdcch资源申请失败此时注意一下CFI配置情况通过cli查看下面参数Device.Services.FAPService.1.CellConfig.LTE.RAN.PHY.X_001710_SelfConfigurationEnabled设置为falseCFI默认配置为1开关设置为trueL3会根据带宽和OperationMode动态配置CFI我们需要关注UE上报的BSR不能存在BSR很小的情况具体打印见基站新增log。2尝试修改SR/BSR周期查看速率有无明显改观BSR周期最好是10ms或5ms如果单UE测试FTP性能SR周期最好是5ms。5其它因素对于BLER正常MCS无限制或者SNR或ulCQI较好的情况下主要排查上层或者测试传输环境问题具体的参考第3章。2 多UE综合速率很低的测试场景按照上述步骤查看单个UE的情况如果没有BLER或者极少则存在RB利用率或者DCI0调度不够的问题在按照下表逐个排除可能原因怀疑对象分配RB不足/DCI0调度不足数据源不足速率环境排查/FTP服务器设置/UDP流量SR/BSR周期调整控制信道影响PRACH/PUCCH/PUSCH资源重叠预留资源不够功控功控算法选择RSSI/PHRUE发射功率限制(P0)多UE并发业务公平性不满足UE速率不均衡QCI等级不一致调度算法选择(PF/RR/MAXCI)RB利用率小ICIC打开跳频QOS速率EPC或者UE限速AMBR基站DSP处理能力单帧解码超时/数据丢弃2. 下行速率问题下行吞吐基本围绕BLER、 MCS 、RB分配、单帧调度ue数等因素展开分析但下行速率能否上去也与上行链路质量(反馈)也有很大的关系。2.1 不能到峰值的影响因素2.1.1 下行BLER当速率低时首先关注BLER尤其是配置为UM模式时有残留BLER影响会比较大。由于FTP是双向的因此上下行BLER都需要关注。如果初始BLER大于10%或者重传几次都解码不对可能有协议问题首先查看基站log是否有调度过程的错误打印。对于下行BLER需要先确认终端侧是否也有BLER。如果终端侧没有BLER则可能是基站ACK译码错误或终端没有检到PDCCH。还有就是初传 TB 的有效信道码率不能大于 dl 0.93。如果终端侧的BLER与基站接近需要确认是否空口环境较差查看终端侧的SNR和RSRP好的测试点SNR应大于20尝试基站关闭下行AMC固定MCS为较低等级看BLER是否消除如果BLER随MCS降低而降低则可基本确认是环境问题。如果BLER与MCS无关,且无论降低到多少都存在固定的BLER则应该是SCH或L1的问题需具体分析。如果返回的是DTX 而UE侧无BLER则是ACK反馈L1解码有问题通过FAPI抓包和基站日志确认是PUCCH上的反馈有问题还是PUSCH上携带的ACK解码有问题查看PUCCH的功率是否异常如果返回的是NACK则需要查看重传的次数是重传一次能解对还是重传3次都解码不对还是全都是重传一次就解码对了其次看子帧是不是只是某一个子帧的都是NACK其余子帧的都能解对寻找出规律更容易解决问题。2.1.2 下行MCS如果存在BLER则AMC会将MCS修低需要先解决BLER因素。如果没有BLER但MCS较低且一直是固定值需要确认是否限制了最高MCS等级见基站cli配置如果设置无异常需要确认终端反馈的CQI是否正常见L2 current。如果CQI值较低需要确认终端上报值是否正常或者基站设置的RS参考功率设置很小导致UE上报的就很小。2.1.3 下行数据量如果底层正常但速率仍然较低通过基站新增打印查看RLC报的缓存报告BO如果要达峰值理论上每次的缓存量应较大。若tbsize1的值为0则表示当前调度为单码字确认TM模式及UE返回的RI是否1。如果环境允许可以通过下行大数据量UDP灌包进行缓存测试。如果缓存一直不够或者时大时小则按照本文第3部分的介绍排查上层或测试环境。2.2 速率低的原因列举未达峰值速率/多UE总吞吐低可能原因怀疑对象BLER干扰/其它数据源不足速率环境排查/FTP服务器设置/UDP流量PDCP discardTimer设置是否合理(1500ms)测试点是否合适CQI反馈是否较小/UE处于高速移动CQI不稳UE能力CAT等级比较小多UE并发业务公平性不满足UE速率不均衡QCI等级不一致调度算法选择(PF/QOS/MAXCI)RB利用率小下行频选打开/ICIC打开DRX功能打开/PDCCH漏检CCE分配失败多UE处理超时基站DSP处理能力L2加解密/单帧L1解码超时/调度不及时下行数据丢弃QOS速率EPC或者UE限速AMBRMIMO模式参数传输模式设置TM3未调度双码字/UE上报RANK 2(双天线RSRP相差不大于3dB应该都上报2)上行反馈通道PUCCH预留资源不够导致HARQ反馈解码错误/功控能否改善上行信道质量3. 上层和环境因素如果从空口的角度均未发现异常则需向上逐步排查分别查看S1U PDCP RLC传输是否正常、核心网是否正常、服务器是否正常、终端是否正常等。列出几个常见的可能影响FTP速率的因素供参考。0 )L2协议实现加密队列满丢包 循环队列丢包 pdcp队列满丢包 内存门限丢包 lateDatReq过高 收到ue rlcStatusReport少下行dlrlcNackNum rlcRetxSize macPadSize S1U收到GTP包SN不连续上行 ulrlcNackNum观察各节点速率统计是否匹配1 )线程数空口环境不稳难免有少量BLER且FTP单线程速率随时延增大而减小因此增大线程数能使线程间的速率互补保证吞吐量稳定。建议使用10以上的线程数下载。检查iperf命令参数。2) MTU设置FTP包的MTU是采用的终端笔记本和服务器MTU的最小值一般电脑默认MTU是1500但不同基站对于分片报文的处理也许存在瓶颈建议将MTU或MSS改小,规避分片和重组引发的异常。在服务器或终端侧笔记本wireshark抓包如果TCP报文的len1460一般代表MTU是1500。(Fragmented IP protocol、TCP segment of a reassembled PDU)3)时延时延在TCP协议中有重大意义。因为TCP数据包需要反馈时延越长线程的发包量增长速度越慢。一旦发生丢包该线程速率恢复以及其它线程速率互补也越慢。通常来说缩短时延能提升和稳定速率。空载PING小包时延在30ms以内为宜。基站一些参数配置会影响时延比如打开预调度功能此时的上行时延为最小值若有速率明显提升或变稳则可通过基站CLI修改SR/BSR参数来尽可能缩短上行时延如果调整基站参数后ping时延仍然很大需排查EPC跟基站的网线连接核心网和服务器之间传输的时延一般较小服务器ping核心网一般在1ms级别。4)服务器首先需确认服务器是千兆网卡其次需确认当前服务器是否有很多用户同时下载服务器负荷较重可能影响速率如果条件允许建议尝试使用空闲服务器进行测试或同时使用两个FTP软件从两个服务器同时下载。如果服务器长时间未重启建议重启服务器。5)核心网如果上下行BLER很小但从终端侧、S1的核心网出口或基站入口wireshark抓包发现很多out-of-order或retransmission包时可以怀疑核心网问题。其次核心网配置是否进行了EPC参数修改限速了参数没改回导致测试速率上不去。如果连接同一核心网的其他多个站点服务器均能正常峰速则可初步排除核心网问题。6)终端笔记本性能终端笔记本性能对FTP速率也有较大影响曾多次出现UDP灌包能到峰速但FTP到不了的情况然后什么都不变更换终端笔记本后FTP速率提升20M的情况。请尽量使用性能好的笔记本,如果条件允许出现速率低问题后建议更换终端笔记本看速率是否改善。7)调试工具对于linux平台运行的协议栈可通过top和Ftrace等命令查看各线程占用CPU的负荷情况以及各线程抢占多核的情况wireshark抓包的专家信息和图形统计有时候很有用(dup ack/tcp fast retransmission等)查看hexgon和krait之间FIFO通信是否有异常统计4 . 话音质量问题如果出现VOLTE话音质量差的现象则肯定是带宽、时延、丢包率、抖动哪一方面没有达到要求一般从下面的步骤进行查看查看基站log的信令流程是否存在切换重建立专用承载建立失败掉线甚至重定向重选等这些过程对语音的影响大于对数据的影响确定流程是否合理确定eSRVCC的2G3G邻区或参数是否配置合理在LTE覆盖边缘是否平滑切换到CS域避免掉话或重定向查看4G邻区或门限等参数是否配置合理查看基站log的数据面统计查看L2上层统计是否正常具体见第3章分析查看QCI1流量是否正常关注GBR MBR参数设置根据错误打印或统计确定ROHC流程是否有问题查看基站oam V1或网管导出的qci1 kpi统计,里面有网络侧和空口统计确定是网络侧问题还是空口问题结合在基站网口或IMS SBC等关键节点进行wireshark抓包分析RTP数据的时延(是否超过100ms)丢包或抖动情况分析SIP信令情况如果是空口问题导致的丢包或时延问题则需要关注基站的覆盖和干扰实测结果表明RSRP大于-113dBmSINR大于-3dB可以达到理想的VoLTE语音质量解决PCI冲突重叠覆盖等问题适当增强RS功率。查看基站BLER或CRC统计如果失败率比较高可以先关闭DRX功能和固定低MCS等方式验证更多具体见第1章和第2章空口问题的排查分析。如果是网络侧问题导致则和基站无关只需配合如果是rohc流程失败导致的问题可以通过修改头压缩算法关闭加解密功能进行验证问题在家里复现调试。5. 随机接入问题查看基站log分析信令流程确定ue接入失败最直接的原因是否是SIM未开LTE功能用户过多拥塞参数配置错误等原因是否被叫未收到paging如果接入信令过程到了msg5左右因为RLC最大重传导致失败则关注覆盖差干扰大等因素具体见上面几个章节关于空口介绍如果接入信令过程只到了msg3附近或没有收到msg3则需要关注随机接入过程的有关参数查看fapi log到了哪一步查看基站cellCb-rachThreshold接入门限参数查看SIB2的prach-ConfigIndex 3 和 prach-FreqOffset5参数(任意sfn,sf 1,preamble format 0:占一个子帧)PRACH Mask Index , numberOfRA_Preambles 12, messageSizeGroupA, ResponseWindowSize10, maxHARQ_Msg3Tx4等参数是否被修改过是否是默认配置关注随机接入功率有关参数是否合理比如lte-rrc.preambleInitialReceivedTargetPowerlte-rrc.powerRampingStep等通过基站错误打印结合fapi确定上述哪个参数存在问题或哪个代码流程有问题在家里复现调试验证如果还是不能确定原因则外场打开新增log开关或将rlog打印等级改成6获得msg1 msg2 msg3 msg4的统计或打印详细信息查看随机接入详细流程如果还是不能看出问题则进行对比测试重启或更换手机等具体细节请看第3章和第6章先发现规律再定位原因6. 确认环境问题的方法6.1 UDP灌包进行下行UDP灌包如果达到峰速说明下行通路正常同时进行上行UDP灌包如果也能正常峰速同时结合基站ping包打印功能如果时延也正常则80%排除基站问题。重点关注终端、核心网、传输。6.2 更换基站对比测试使用不同厂家或硬件平台基站同一服务器进行测试能达到峰速则基本排除核心网和服务器问题。重点关注基站和终端、传输。6.3 更换终端对比测试如果使用其他终端或其他终端笔记本在同一地点进行测试能达到峰速则基本排除网络问题。重点关注终端或终端笔记本、传输。6.4 排查传输线缆如果通过上述方法基本排除基站、终端、核心网问题则需重点关注传输。一是传输可能丢包需多方(EPC、ENB进出)同时wireshark抓包确认.
