【案例】BLER高导致低速率优化处理案例
LTE优化案例手册-第四章- 速率问题
第四章速率问题4.1 速率问题概述(陈佳)（注：本文所讨论的速率问题是建立在上下行时隙为DSUUD的基础上）在极好点（SINR在22dB以上）做FTP下行业务时，平均速率要求在47Mbps左右及以上，若发现速率较低，我们可进行以下方面的排查来定位问题：1、看无线环境是否稳定、包括SINR、RSRP、CQI等若UE IDLE的情况下，SINR值能在23以上，在UE 进行下载业务时，SINR会明显降低，则很可能是天馈接错或天馈系统存在问题，可进行天馈排查；2、PRB的调度是否能满现网的上下行时隙配比为2:2（3:2），则分配给下行的1s调度次数理论最大值为600，平时单站验证时应该看到的值会接近600，若出现该值较低或有的PRB没有进行调度，则需查看现网参数，看是否设置了PRB调度数量的限制等；3、查看下行双流是否存在、以及是否稳定在测试软件上可看到传输模式（TM），目前现网设置为TM3、7自适应，所以在双流时，传输模式为TM3，同时还要看CQI窗口中Rank2 Indicator Count 是否有值，有值才是真正的双流；如果出现TM模式3、7的不断更换，则下行速率肯定会受到影响，此时可看现网参数关于3、7门限是否设置合理；4、查看下行BLER值、如果误码率过高，会导致速率低5、查看DL MCS窗口，在极好点，下行编码方式绝大部分应在26及以上、主要调制方式为64QAM，若存在问题，则需检查现网相关参数；6、查看本小区上下行时隙配比以及相邻小区的时隙配置（DL：UL），现网配置为2:2（3:2），若本小区配置成2:2（3:2），相邻小区被配置成了3:1（4:1），导致服务小区的上行受到干扰，UE出现上行失步，会出现掉话，速率不高的现象；7、排查电脑问题，以及FTP服务器问题可进行电脑重启、更换FTP服务器地址、以及多开些进程等操作8、查看基站有无告警，若无，可怀疑是否存在基站或传输单元隐性故障，将基站或传输单元进行重启9、查看参数maxNrSymPdcch是否设置为3，若设置为3，则会大大影响下行速率，做单站10、进行基站全部参数的核准验证时可将此值设置为1经过以上排查，若还不能解决，则可让后台人员做本站参数和Golden 配置参数的对比，看是否存在异常；11、传输限速：找传输人员排查传输上的带宽是否设置错误，导致传输瓶颈的产生，从而影响空口的速率，标准设置为上下行双工，都为1Gbit/s12、查看SIM卡的签约信息是否有问题查看信令attach accept，其中可看到APN aggregate maximum bit rate ，其中有UE下行最大速率限制，看是否修改了SIM的签约信息；二、在极好点做FTP上传时，平均速率要求在19Mbps（RL 25）左右及以上，若发现速率较低，我们可进行以下方面的排查来定位问题：1、看无线环境是否稳定、包括SINR、RSRP等2、上行PRB的调度是否能满现网的上下行时隙配比为2:2（3:2），则分配给上行的1s调度次数理论最大值为400，平时单站验证时应该看到的值会接近400，若出现该值较低或有的RB没有进行调度，则需查看现网参数，看是否设置了PRB调度数量限制等；3、看测试软件上的PUSCH Power以及路损，极好点的路损不会很高，一般在90db左右，若此时的PUSCH Power为或者接近23，可查看现网功控参数是否设置有问题，若无问题，可怀疑是否存在天馈接错、或者天馈系统存在硬件问题，导致用户上行功率受限；4、查看上行BLER值如果UL误码率过高，会导致速率低5、查看UL MCS窗口在极好点，上行编码方式绝大部分应为24及以上、主要调制方式应为16QAM，若存在问题，则需检查现网相关参数，若为RL15的站。
精品案例_LTE下载速率低处理案例
LTE下载速率低处理案例目录一、问题描述 (3)二、分析过程 (4)三、解决措施 (6)四、经验总结 (6)LTE下载速率低处理案例【摘要】LTE下载速率低是影响用户感知的重要指标，直接影响用户体验，本案例从DT数据分析入手，通过参数优化解决异频切换问题，提升网络性能指标。
【关键字】异频切换启动异频测量门限下载速率低【业务类别】优化方法一、问题描述9月，通过RCU智能测试管理平台，派单贵池联盟基站附近高速下载速率低，通过LOG 分析发现，该地区信号异常，UE占用GC-市区-贵池联盟-ZFTA-447757-54和GC-市区-里山街道办RRU-ZFTA-447561-52，SINR值恶化，如下图，邻区中没有出现周边距离最近的基站高速出口站，下载速率低下派DT工单.测试截图二、分析过程1.下载速率低定义由上图可见，智能管理平台定义规定，下载速率低需要满足下列1个条件：*PBM下载速率小于10M，经过测试数据LOG分析发现，UE先占用GC-市区-里山街道办RRU-ZFTA-447561-52，随后切换到GC-市区-贵池联盟-ZFTA-447757-54，SINR值恶化，UE一直拖在GC-市区-贵池联盟-ZFTA-447757-54，影响下载速率。
2.无线参数核查通过网管核查贵池联盟和里山街道办基站无告警，下载速率低位置距离高速出口站-ZFTA-447883-55扇区最近，但是UE一直拖在GC-市区-贵池联盟-ZFTA-447757-54没有切换到周边的高速出口站，无线参数核查发现里山街道办RRU-ZFTA-447561-52已经配置过高速出口站-ZFTA-447883-55邻区。
专业网管核查邻区截图3.原因定位经过网管核查和参数确认，里山街道办RRU-ZFTA-447561-52已经从15M扩容到20M，频点已经从1825变成了1850，里山街道办RRU-ZFTA-447561-52切换到高速出口站-ZFTA-447883-55已经从前期的同频切换变成了异频切换，启动异频切换的门限默认值是-109dbm。
Volte-VoLTE语音质量优化案例精编个
VoLTE语音质量优化案例1：VoLTE窄带与宽带语音质量对比【问题现象】在3GPPLTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE12.2kbps）和VoLTE高清语音（或VoLTE23.85kbps）。
【问题分析】AMR-NB和AMR-WB这2种编码具有如下特点：●每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头；●每160ms生成一个SID语音静默包。
●帧长20ms；AMR-NB编码特点为：● 4.75kbps到12.2kbps共8个码率，分别为：4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；●采样率为8kHz。
AMR-WB编码特点为：● 6.6kbps到23.85kbps共8个码率，分别为：6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；●采样率为16kHz。
可见两者显着的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。
AMRNB的语音带宽范围：300－3400Hz，8KHz采样。
AMRWB 的语音带宽范围：?50－7000Hz，16KHz采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMRWB与AMRNB不同之处在于AMRWB按16kHz采样，分别按频率带50~6400Hz?和6400~7000Hz进行编码。
用来降低复杂度，AMRWB将位算法集中到更重要的频率区。
低频带使用ACELP算法进行编码。
添加几个特征来达到一个高的主观质量。
线性预测（LP）算法是在每隔20ms的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的,目的是调整与在声音基础上的低频有关的高频带.高频带的声频通过使用由低带LP过滤器产生的LP滤波器进行重建。
优化案例
1. 子帧配置导致上传速率低【现象描述】滨江电力公司在进行上传业务时发现该站点的3个扇区的速度均比较低，尤其是1、2扇区上传速率只能达到约2~5Mbps。
【问题分析】1）从DT log发现滨江电力1扇区BLER较高，MCS较低，怀疑和干扰有关；2）分析滨江电力3小区log发现该小区的子帧配比为3：1，核查参数确认滨江电力3扇区子帧确实被设置为3：1，而周边基站的子帧配比为2：2，怀疑和小区间上下行子帧相互干扰有关。
BTS Site Manager参数设置：【优化措施】调整滨江电力3小区子帧配比为2：2，和网内其它站点子帧配置相同;【优化效果】将时隙配比改为2：2后，三个扇区上传速率均达到15Mbps以上，确认了上传速率低和子帧配置有关，下行子帧干扰上行子帧导致上传速率低；2. PCI MOD 3导致掉线【现象描述】UE占用滨江国税3（PCI：108）小区进行FTP下载测试，在长河路-江南大道路口UE尝试切换到江边1（PCI：63）小区时，出现切换失败或是切换完成后掉线，最终UE重选到江边1小区。
掉线区域RSRP正常（-80dbm）但SINR较差（-8db左右）。
而且由江边1小区向滨江国税3小区切换时也会发生，切换失败和掉线，最终小区进行重选。
【问题分析】1）此处无线环境RSRP相对较好仅是SINR较差，初步判断是小区间干扰导致掉线；2） SINR值差区域在滨江国税3小区（PCI=108）和江边1小区（PCI=63）切换带上，两小区PCI的mod3余数均为0；3） LTE扰码中小区标识CellID由物理层小区标识组ID和物理层小区标识组内的小区标识ID构成。
小区标识CellID=3*物理层小区标识组ID+物理层小区标识组内的小区标识ID。
物理层小区标识组ID取值范围为0到167，用来对辅同步信号加扰,；物理层小区标识组内的小区标识ID 取值为0、1、2，用来对主同步信号进行加扰；4）因滨江国税3（PCI：108)小区和江边1（PCI：63）小区PCI mod3 结果都是0，对主同步信号的加扰方式相同，造成切换时SINR较差，同步建立困难，发生切换失败和掉线问题。
VoLTE语音质量优化案例(14个)
VoLTE语音质量优化案例1：VoLTE窄带与宽带语音质量对比【问题现象】在3GPP LTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE 12.2kbps）和VoLTE 高清语音（或VoLTE 23.85kbps）。
【问题分析】AMR-NB和AMR-WB这2种编码具有如下特点：●每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头；●每160ms生成一个SID语音静默包。
●帧长20ms；AMR-NB编码特点为：● 4.75kbps到12.2kbps共8个码率，分别为：4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；●采样率为8kHz。
AMR-WB编码特点为：● 6.6kbps到23.85kbps共8个码率，分别为：6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；●采样率为16kHz。
可见两者显著的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。
AMR NB的语音带宽范围：300－3400Hz，8KHz采样。
AMR WB的语音带宽范围：50－7000Hz，16KHz采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMR WB与AMR NB不同之处在于AMR WB按16kHz采样，分别按频率带50~6400Hz 和6400~7000Hz 进行编码。
用来降低复杂度，AMR WB将位算法集中到更重要的频率区。
低频带使用ACELP算法进行编码。
添加几个特征来达到一个高的主观质量。
线性预测（LP）算法是在每隔20ms 的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs 速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的, 目的是调整与在声音基础上的低频有关的高频带. 高频带的声频通过使用由低带LP 过滤器产生的LP 滤波器进行重建。
诺西TDLTE网络优化经验总结—优化案例集
优化结果：
•在将滨江电力3小区的时隙配比TDDframeconf改为1后，分 别验证3个小区的上传速率，均达到了15Mbps以上；
案例一：长河水产市场下载速度低 案例二：滨江电力公司上传速率低 案例三：海斯终端无法搜网 案例四：海斯终端ATTCH 失败 案例五：远见智能第1小区下载速率偏低问题 案例六：室分小区随机接入失败 案例七：基站有信号，Attach不成功 案例八：参数配置导致切换失败 案例九：修正测试规范BF Gain计算公式
案例二：滨江电力公司上传速率低
案例描述： •在对滨江电力公司进行单站验证的过程中，在进行上传业务 时发现该站点的3个扇区的速度均比较低，只能达到约 2~5Mbps，而在前期的测试中，该站的上传速度表现一直很 好达到了15Mbps以上；
案例分析：
•1.在滨江电力1扇区测试中显示 BLER较高，MCS较低；
案例一：长河水产市场下载速度低 案例二：滨江电力公司上传速率低 案例三：海斯终端无法搜网 案例四：海斯终端ATTCH 失败 案例五：远见智能第1小区下载速率偏低问题 案例六：室分小区随机接入失败 案例七：基站有信号，Attach不成功 案例八：参数配置导致切换失败 案例九：修正测试规范BF Gain计算公式
【解决方案】通过sscom32在hisi终端的bluetooth口发送命令，将hisi终 端的鉴权与基站侧的鉴权进行同步。设备连接后，通过sscom32打开终端 的bluetooth端口，发送命令：g_ulSmcControl=1，点击发送后，鼠标 移至运行窗口按enter，返回值value = 1即表示操作成功，然后关闭 bluetooth端口，如下图所示。
5G优化案例：5G波束场景设置不当导致速率低优化案例
5G 波束场景设置不当导致速率低优化案例XX【摘要】9 月份，针对河东 5G 精品网优化分析时，发现 UE 占用河东嵩ft道-HDSO-2 信号时（RSRP=-75,SINR=18 ，RANK=4，MCS=18，调度 937，下行速率 365Mbps），无线环境良好，但调度及下载速率较低。
通过修改河东嵩ft道-HDSO-0/1 小区的波束场景由扩展场景 1 修改为默认场景，同一地点复测结果有明显改善， UE 占用河东嵩ft道-HDSO- 2（RSRP=-76,SINR=20，RANK=4，MCS=18，调度 1401，下行速率 772Mbps）。
基于以上波束场景的设置来改善调度及下行速率的案例，在今后 5G 网络RF 优化中较为常见，及时对案例进行总结，并传递相关优化经验，提升 5G 网络竞争力。
【关键字】波束场景、干扰、调度、下行速率【业务类别】移动网1.问题描述9 月13 日测试时，UE 行驶在嵩ft 道上时，占用河东嵩ft 道-HDSO-2 ，RSRP=- 75,SINR=22 ，RANK=4，MCS=18，调度次数937，下行速率365M 左右。
2.分析过程➢问题排查一：前台测试发现问题后，更换其他测试UE，继续按照原路段测试，测试结果并无改变，依然是无线环境好，下行速率低。
➢问题排查二：后台查询河东嵩ft道-HDSO-2 波束场景设置为3（水平65°，垂直6°，窄波束），而本站的河东嵩ft道-HDSO-0/1 两个小区的波束场景设置均为扩展场景1（宽波束）。
➢问题排查三：同站不同小区设置两个不同的波束场景， 2 小区设置为窄波束，0、1 小区设置为宽波束。
而扩展场景1（宽波束）和默认场景及波束场景1-16 设置值的17 种波束场景（窄波束）之间互为干扰，导致无线环境良好，但调度次数、RB 数都偏低。
3.波束间干扰原理分析波束间干扰是指的是SSB 的干扰，默认波束是SSB 是7 或者8 波束，宽波束SSB 是1 个波束,这两种之间会有干扰。
常州移动LTE精细簇优化案例
1 重叠覆盖问题1.1晋陵中路部分路段重叠覆盖度高导致速率低【问题描述】：车由西南到东北方向沿青山路行驶到晋陵中路路段速率较低DL Throughput=11.3Mbit/s.该路段主服务小区检察院A小区信号RSRP-100dBm左右,SINR-1dB左右,邻区斗巷A小区信号RSRP-100dBm左右,斗巷B小区RSRP-101dBm,翠园世家B小区RSRP-106dBm，长春大厦C小区RSRP-105 dBm左右。
具体如下图：左：SINR图中：throughput图右：RSRP图【问题分析】：从信息列表中发现邻区列表中的4个邻区与主服务小区检察院A 小区的RSRP差值在6db以内，该路段重叠覆盖度高。
【处理措施】：根据实际情况作了如下调整:将检察院A小区 RS功率由32dbm调到92dbm使其作为该路段主覆盖解决该问题点。
【处理结果】：优化后DL Throughput=32.59Mbit/s，服务小区检察院A小区信号RSRP-91dBm 左右，SINR 9dB左右,邻区斗巷B小区RSRP-105dBm左右，翠园世家B小区RSRP-106dBm左右，邻区小区RSRP与主服务小区RSRP差值大于6dbm，解决了重叠覆盖高的问题，具体复测情况如下图：左：SINR图中：throughput图右：RSRP图2 PCI mod3冲突2.1武青北路与和平北路交界处模三干扰导致速率低【问题点描述】：车行驶到红梅桥到武青北路与和平北路交界处路段是速率DL Throughput=12.8Mbit/s，.该路段主服务小区新丰A小区RSRP-79dBm,SINR -6dB。
武青北路A小区RSRP-84.dBm邻区具体如下图：左：SINR图中：throughput图右：RSRP图【问题点分析】：分析发现覆盖该路段的新丰大厦A小区与武青北路A小区产生模三干扰导致该路段SINR陡降，速率明显下降。
【处理措施】：根据实际情况作了如下调整:由于该站附近小区较密集调整新丰A 小区或武青北路A小区PCI会与周围小区产生模三干扰，所以降低武青北路A 小区功率，邻区武青北路A小区与主服务小区新丰A小区RSRP值差大于10dBm，从而降低了模三干扰的影响。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
分析方向：
1、传输是否存在光衰等问题；
2、是否存在模3等干扰问题；
3、是否存在告警，设备存在隐性故障等；
4、如果是室分的话，还得考虑下直放站、无源器件等问题。
在无线网络中，一个设备（如eNodeB）是按块（block）向另一
个设备（如UE）发送数据的。
发送端使用块中的数据计算出一个CRC，并随着该块一起发送到接收端。
接收端根据收到的数据计算出一个CRC，并与接收到的CRC进行比较，如果二者相等，接收端就认为成功地收
到了正确的数据，并向发送端回复一个“ACK”；如果二者不相等，接收端就认为收到了错误的数据，并向发送端回复一个“NACK”，以要求发
送端重传该块。
如果在某个特定的周期内，发送端没有收到接收端的回复，则发送端假定之前发送的块没有到达接收端，发送端自动重发该块。
(MAC层的HARQ处理)
BLER（block error rate），即误块率，是出错的块在所有发送的块中所占的百分比（只计算初传的block）。
在实际应用中，某一特定百分比（如：LTE中数据信道的BLER要求为10%以下）的BLER并不总是必须的，因为可以重传出错的块并通过特殊的处理（如软合并等），使得接收端正确解出收到的数据。
需要测量和计算BLER时，在发送端就能够完成，因为可以通过收到的NACK数来计算BLER。
在LTE中，控制信道的目标BLER为1%，数据信道的目标BLER
位10%。
当BLER不超过10%时，UE将向eNodeB上报它所能解码的最高MCS。
LTE在无HARQ重传情况下误块率指标为10%，加入HARQ重传后误帧率（FER）大概为1%，再加上RLC层的ARQ后性能提升到10^-5数量级。
例：假设发送了500个block的数据，其中499个block回复ACK，1个block回复NACK，则BLER为1 / 500 = 0.002 * 100% = 0.2%（从这个例子可以看出，计算BLER时，是不把重传的block的ACK/NACK 计算在内的）。