诺基亚与华为速率掉坑问题以及高丢包问题分析
电信异厂家边界基站VOLTE下行高丢包率问题分析优化总结
电信异⼚家边界基站VOLTE下⾏⾼丢包率问题分析优化总结异⼚家边界基站VOLTE下⾏⾼丢包率问题分析优化总结温州电信⽆线维护中⼼2019年4⽉⽬录⼀、问题描述 (4)⼆、分析过程 (4)三、解决措施 (7)四、成效 (8)五、总结 (8)⼀、问题描述温州市LTE南北⽚分别是诺基亚与华为两个⼚家的基站设备，位于边界处的瑞安场桥信⽤社基站VOLTE丢包率较⾼，⼏乎是全⽹的两倍。
⼆、分析过程丢包对VoLTE语⾳质量的影响较⼤，当丢包率⼤于10%时，已不能接受，⽽在丢包率为5%时，基本可以接受。
因此，要求IP 承载⽹的丢包率⼩于5%。
VoLTE丢包率是MOS值的⼀个重要影响因素，严重的丢包影响通话质量，甚⾄导致掉话，导致⽤户感知降低。
查询瑞安场桥信⽤社基站的故障告警、拥塞、⼲扰等，⽆异常，且在该⼩区下多次测试均正常。
怀疑可能与跨⼚家切换有关系。
查看跨⼚家切换时的交互信令发现，龙湾埭头祥和路基站默认ACK/NACK反馈机制为Multiplexing，⽽瑞安场桥信⽤社则固定为bundling模式，源龙湾埭头祥和路基站在Handover Request⾥不含有ue-ConfigRelease-r10的字段(该字段表⽰当前UE配置的RRC 协议版本，如果不包含该字段，⽬标瑞安场桥信⽤社基站将默认为当前UE配置的RRC协议版本为r8)。
致使⽬标瑞安场桥信⽤社基站在处理该切换请求时默认认为UE为r8终端，导致瑞安场桥信⽤社ENB给龙湾埭头祥和路ENB 发送的HO request ack⾥没有PUCCH-ConfigDedicated-v1020这个字段，根据协议36.331相关说明，实际⽀持r10版本的终端在⽬标主服务⼩区不⽀持相关配置时将出现两者的协作兼容问题，该案例中具体表现为⽆法按切换命令中所要求的从Multiplexing模式切换到bundling模式，造成UE “NACK/ACK”反馈模式与ENB要求的反馈模式不⼀致，导致导致下⾏⾼丢包，如下：2.1问题定位分析2.1.1瑞安场桥信⽤社向龙湾埭头祥和路切换时通过对log的解析发现，当终端析从瑞安场桥信⽤社1⼩区切换到龙湾埭头祥和路3⼩区，ACK/NCK反馈模式可能发⽣变化。
VOLTE问题分析RTP丢包率
RTP丢包率问题分析一、问题分析1、弱覆盖:主要由于道路弱覆盖RSRP持续偏低，导致RTP丢包率偏高；现网部分路段由于覆盖较差，导致SINR值较高，无线环境不良，UE在此路段建立通话时，存在一定程度丢包现象。
●网格6被叫UE京杭运河A1路段时，由于该道路缺少站点覆盖，UE占用Z730046中山大厦_2小区，RSRP在-116左右SINR在-9左右属于弱覆盖路段，UE不断发送测量报告触发A3事件。
在此期间对RTP丢包率影响较大，该路段丢包率为24.13%。
优化建议：该区域缺少基站覆盖，需要新建站点解决弱覆盖问题。
●网格6被叫UE在进过纵一路由南往北行驶途中，UE占用Z736782嘉兴梁林帆影庄南_1小区，随着UE与该小区距离不断增加，UE最终在13:34:17.014重选到G网，此时UE的RSRP为-116.18，SINR为-7.8。
在此期间对RTP丢包率影响较大，该路段丢包率为6.6%。
优化建议：该区域缺少基站覆盖，需要新建站点解决弱覆盖问题，结合北边A1路段的弱覆盖情况，可以再紫色区域新建站点解决此路段弱覆盖问题。
网格4被叫UE在中港路由东往西行驶过程中，经过与云东路交叉的十字路口后信号变差，此时UE占用Z730391嘉兴中港城东区_2小区，信号不断衰弱到RSRP位-109.87，邻区列表中也无较强信号小区。
在此期间对RTP丢包率影响较大，该路段丢包率为4.84%。
优化建议：该路段可能存在遮挡情况，可以通过现场核实后进行天馈调整来增强该路段的信号覆盖。
DCP分析：扫频此段路Z730391嘉兴中港城东区_2小区最低-99（个别点），基本在-89至-93只能。
建议从切换重选门限值去考虑。
2、Mod3干扰：问题路段，进行无线干扰优化提升指标。
网格4 Mod3干扰问题：由于MOD3干扰，被叫UE行驶至该路段时，Z730261嘉兴江淮汽车_1 PCI 44与Z730127嘉兴国际电器城_3 PCI 395，存在Mod3干扰影响UE正常切换，在此期间RTP丢包率达到40%较为严重，影响整体指标。
丢包解决方案
丢包解决方案一、问题描述在网络通信中，丢包是指数据包在传输过程中丢失或者未能按时到达目的地的情况。
丢包问题严重影响了网络通信的质量和稳定性，给用户的使用体验带来了很大困扰。
因此，需要制定一套丢包解决方案，以提高网络通信的可靠性和稳定性。
二、问题原因分析1. 网络拥堵：网络中的数据传输量超过了网络设备的处理能力，导致数据包丢失。
2. 网络故障：网络设备或者链路浮现故障，导致数据包无法正常传输。
3. 网络延迟：网络延迟过高，导致数据包在传输过程中超时丢失。
4. 网络颤动：网络信号不稳定，导致数据包在传输过程中丢失。
三、解决方案针对丢包问题，可以采取以下解决方案，以提高网络通信的可靠性和稳定性。
1. 网络设备升级对于网络拥堵和故障问题，可以考虑进行网络设备的升级。
升级后的设备具有更高的处理能力和更好的稳定性，能够更好地应对大流量和故障情况，减少丢包的发生。
2. 网络链路优化通过优化网络链路，可以减少丢包的发生。
可以使用链路聚合技术，将多个链路进行聚合，提高网络带宽和稳定性；同时，可以使用网络负载均衡技术，将网络流量均衡地分配到多条链路上，减少单条链路的负载，降低丢包的概率。
3. 数据包重传机制在网络通信中，可以引入数据包重传机制，以解决丢包问题。
当发现数据包丢失时，发送端可以主动进行数据包的重传，确保数据包能够成功到达目的地。
同时，可以使用序列号和确认机制，确保数据包的有序传输。
4. 网络质量监测建立网络质量监测系统，实时监测网络的延迟、颤动和丢包率等指标。
一旦发现网络质量异常，及时采取措施进行排查和修复，以减少丢包问题的发生。
5. 数据压缩和加密对于需要传输的数据，可以使用数据压缩技术，减少数据包的大小，降低丢包的概率。
同时，可以使用数据加密技术，保护数据的安全性，在传输过程中防止数据包被篡改或者截获。
6. 容灾备份建立容灾备份系统，实现数据的冗余存储和备份。
在发生丢包问题时，可以及时从备份系统中恢复数据，减少数据丢失的影响。
LTE高掉线小区问题分析_NOKIA
LTE高掉线小区问题1、问题现象从5月6日起，宝山区的宝镇泰NL1H、镇泰NL1H、杨开NL1H等基站相关小区开始出现高掉线现象，尤其是宝镇泰NL1H_11小区基本每日15忙时都存在高掉线现象，小时最高掉线次数达一百多次以上，严重影响全区指标。
2、问题分析通过对高掉线最差小区宝镇泰NL1H_11进行信令分析，从信令跟踪结果来看，宝镇泰NL1H_11确实存在大量的RRC Rel Cause为other，S1 Rel Cause为4116的高掉线情况。
通过对每一条记录进行详细分析，可以看出release的原因均为:transport:unspecified，具体详情如下：信令跟踪宝镇泰NL1H_11高掉线情况宝镇泰NL1H_11高掉线详细信令截图从宝镇泰NL1H_11小区高掉线的详细信令来看，应该都是跨MME POOL切换后导致的掉线。
具体情况为从周边小区切换入宝镇泰NL1H_11小区后，UE马上发起TAU更新，更新完成后，ENB突然向MME发送UE上下文释放请求，释放原因均为：transport:unspecified。
由于UE在进行跨MME POOL的切换后，会相应先进行SGW的切换，然后再进行TAU更新。
现在怀疑可能是ENB到某个SGW的传输链路存在问题所致，于是对相应涉及到的SGW进行了汇总。
宝镇泰NL1H_11涉及SGW图由于怀疑宝镇泰NL1H高掉线可能是ENB到某个SGW的传输链路存在问题所致，于是通过对PathSwitchRequestAcknowledge信令对应的SGW地址进行提取汇总，同时对相应的SGW进行了相应PING操作。
涉及的SGW地址如下所示：对涉及的SGW进行ping SGW地址 -s1400 -c100命令操作后，相关SGW都正常，平均时延都在2.8ms左右。
root@FCTB:~ >ping 100.71.254.69 -s1400 -c100PING 100.71.254.69 (100.71.254.69) 1400(1428) bytes of data.1408 bytes from 100.71.254.69: icmp_seq=1 ttl=252 time=2.83 ms1408 bytes from 100.71.254.69: icmp_seq=2 ttl=252 time=2.81 ms1408 bytes from 100.71.254.69: icmp_seq=3 ttl=252 time=2.82 ms1408 bytes from 100.71.254.69: icmp_seq=5 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=6 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=7 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=8 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=9 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=10 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=11 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=12 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=13 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=14 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=15 ttl=252 time=2.84 ms 1408 bytes from 100.71.254.69: icmp_seq=16 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=17 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=18 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=19 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=20 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=21 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=22 ttl=252 time=2.86 ms 1408 bytes from 100.71.254.69: icmp_seq=23 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=24 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=25 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=26 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=27 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=28 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=29 ttl=252 time=2.85 ms 1408 bytes from 100.71.254.69: icmp_seq=30 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=31 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=32 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=33 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=34 ttl=252 time=2.82 ms 1408 bytes from 100.71.254.69: icmp_seq=35 ttl=252 time=2.78 ms 1408 bytes from 100.71.254.69: icmp_seq=36 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=37 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=38 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=39 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=40 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=41 ttl=252 time=2.83 ms 1408 bytes from 100.71.254.69: icmp_seq=42 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=43 ttl=252 time=2.82 ms 1408 bytes from 100.71.254.69: icmp_seq=44 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=45 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=46 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=47 ttl=252 time=3.07 ms1408 bytes from 100.71.254.69: icmp_seq=49 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=50 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=51 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=52 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=53 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=54 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=55 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=56 ttl=252 time=2.78 ms 1408 bytes from 100.71.254.69: icmp_seq=57 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=58 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=59 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=60 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=61 ttl=252 time=2.82 ms 1408 bytes from 100.71.254.69: icmp_seq=62 ttl=252 time=2.78 ms 1408 bytes from 100.71.254.69: icmp_seq=63 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=64 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=65 ttl=252 time=2.78 ms 1408 bytes from 100.71.254.69: icmp_seq=66 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=67 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=68 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=69 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=70 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=71 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=72 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=73 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=74 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=75 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=76 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=77 ttl=252 time=2.78 ms 1408 bytes from 100.71.254.69: icmp_seq=78 ttl=252 time=2.82 ms 1408 bytes from 100.71.254.69: icmp_seq=79 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=80 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=81 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=82 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=83 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=84 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=85 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=86 ttl=252 time=2.81 ms 1408 bytes from 100.71.254.69: icmp_seq=87 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=88 ttl=252 time=2.79 ms 1408 bytes from 100.71.254.69: icmp_seq=89 ttl=252 time=2.80 ms 1408 bytes from 100.71.254.69: icmp_seq=90 ttl=252 time=2.78 ms 1408 bytes from 100.71.254.69: icmp_seq=91 ttl=252 time=2.80 ms1408 bytes from 100.71.254.69: icmp_seq=93 ttl=252 time=2.79 ms1408 bytes from 100.71.254.69: icmp_seq=94 ttl=252 time=2.78 ms1408 bytes from 100.71.254.69: icmp_seq=95 ttl=252 time=2.80 ms1408 bytes from 100.71.254.69: icmp_seq=96 ttl=252 time=2.81 ms1408 bytes from 100.71.254.69: icmp_seq=97 ttl=252 time=2.79 ms1408 bytes from 100.71.254.69: icmp_seq=98 ttl=252 time=2.80 ms1408 bytes from 100.71.254.69: icmp_seq=99 ttl=252 time=2.80 ms1408 bytes from 100.71.254.69:icmp_seq=100 ttl=252 time=2.80ms 通过多次PING大包操作，丢包率都为0，平均时延在2.8ms左右，暂时排除ENB与上述7个SGW的传输链路问题，相关问题需继续排查。
诺基亚LTE top小区处理意见
top小区处理意见低流量以及流量异常小区处理低流量小区是重要的KPI指标之一，指标反映了网络的移动性，指标直接影响到用户感知。
处理步骤：1. 首先核查是否为目标基站故障导致流量异常，查看当时站点的状态正常（基站是否存在故障）2. 现网核查参数等相关，发现参数设置无异常3. 与前台沟通后现场查看，无线环境正常，主覆盖区域为公路，上站检查无异常，更换光纤、光模块后观察流量依旧较低，后更换FBBA板，观察，流量恢复正常；总结：低流量以及流量异常小区优化首先排除外部干扰，基站故障等情况以外，还要针对基站相关参数、无线环境等进行进行核查，排除参数以及无线环境问题，之后利用前台实测数据分析，逐一排查问题根源，再进行处理。
零流量小区针对现场一个月的零流量小区统计情况分析，干扰、用户少、基站故障、人为调测、工程问题等都是导致零流量小区的原因：故障问题：电源：设备掉电端站，BBU掉电硬件告警：X2接口故障，系统时钟不可用，驻波等传输：传输光纤接口异常，BBU接口异常，射频R口接口异常覆盖、干扰问题：室外站点覆盖景区，景区冬季人少室外站点覆盖农村空旷公路室外站点不合理，如周围有村庄，密集人群活动区域，但天线覆盖方向不合理的.用户行为问题：活动场所：偶尔有活动，但周期比较长的。
随着季节变化，室外用户变少的.确实是用户过少的.工程原因：新建站处理故障期间，流量比较低小区未激活，导致零流量无线接通率低处理意见接入失败通常有三大类原因：无线侧参数配置问题、信道环境影响以及核心网侧配置问题。
因此遇到无法接入的情况，可以大致按以下步骤进行排查。
1.通过话统分析是否出现接入成功率低的问题，当前RRCeRAB接通率指标一般为98%，也可根据局点对接入成功率指标的特殊要求启动问题定位。
2.确认是否全网指标恶化，如果是全网指标恶化，需要检查操作，告警，是否存在网络变动和升级行为。
3.如果是部分站点指标恶化，拖累全网指标，需要寻找TOP站点。
诺基亚SAEGW软件BUG导致抚州HTTP下载速率低分析报告
诺基亚SAEGW软件BUG导致抚州HTTP下载速率低分析报告一、问题描述省公司公布4月份劳动竞赛指标HTTP下载速率，抚州在全省排名倒数，低于省公司挑战值，全省各个地市4月份HTTP下载速率指标如下：数据来源：2016年网络质量劳动竞赛评定-4月份二、问题分析1）诺基亚EPC核心网下的地市HTTP下载速率都低核查4月份承载在诺基亚EPC核心网下赣州、抚州、鹰潭4G页面下载速率，三个地市在全省排名都靠后，三个地市存在的共同点——ENODEB都是下挂在诺基亚EPC核心网下面。
2）SAEGW升级前后页面下载速率分析提取3月6日-4月3日诺基亚EPC核心网4G下载速率进行比对，发现3月23日后4G 下载速率明显呈下降趋势，核查现网调整记录，发现3月17日-3月23日期间对诺基亚8台SAEGW设备进行了NG3.15.1版本升级，升级前平均下载速率为3175Kbps，升级后2321 Kbps，升级后三地市平均下载速率下降854Kbps，具体如下图：对比诺基亚8台SAEGW版本升级前后HTTP页面下载速率，可知，升级后，诺基亚EPC 核心网下面的地市，页面下载速率都出现了大幅度下降。
3）4G手机现场测试分析1、4G手机正常驻留在4G上面，用SmartTest软件进行下载速率测试，下载速率为15Mbps。
2、将4G手机锁在2G网络上面，然后再让手机重选回4G（模拟手机从4G到2G又到4G的过程），发现4G手机SmartTest测试的下载速率一直在2Mbps以内，速率一直上不起，需重启手机或者飞行模式一下才可恢复到正常下载速率。
3、抚州公司组织多批次人员在多个不同厂家ENODEB环境下，以及使用不同的终端，不同的测试软件都验证了4G手机从2G回到4G后，页面下载速率不会超过2M这个问题。
4）省公司抓包验证分析为查明以上问题产生的原因，省公司进行了各场景测试抓包，发现SGW给PGW发送modify bearer command消息用来更新用户从2&3G切换到4G的QOS（100M）。
丢包解决方案
丢包解决方案一、问题描述在网络通信过程中，丢包是指在数据传输过程中部分或全部数据包丢失的情况。
丢包问题严重影响了网络通信的稳定性和可靠性，需要采取相应的解决方案来解决丢包问题。
二、丢包原因分析1. 网络拥堵：网络中的数据流量过大，导致网络设备无法及时处理所有数据包，从而造成丢包现象。
2. 网络延迟：网络传输过程中的延迟，如高延迟、抖动等，可能导致数据包在传输过程中丢失。
3. 网络故障：网络设备故障、线路故障等都可能导致数据包丢失。
4. 网络不稳定：网络的不稳定性也是丢包问题的常见原因，如信号干扰、无线网络信号弱等。
三、丢包解决方案针对丢包问题，可以采取以下解决方案来提高网络通信的可靠性和稳定性：1. 网络优化- 使用高质量的网络设备和线缆，确保网络设备的稳定性和可靠性。
- 对网络进行合理规划和优化，避免网络拥堵和延迟现象的发生。
- 使用流量控制和拥塞控制技术，有效管理网络流量，避免网络拥堵。
2. 引入冗余机制- 使用冗余路径和冗余设备来传输数据，当其中一个路径或设备发生故障时，可以自动切换到备用路径或设备，避免数据丢失。
- 使用数据冗余技术，如数据备份、数据镜像等，确保数据的可靠性和完整性。
3. 优化传输协议- 使用可靠传输协议，如TCP协议，它具有重传机制和数据校验机制，可以确保数据的可靠传输。
- 针对特定应用场景，可以选择适合的传输协议，如实时传输需要低延迟的场景可以选择UDP协议。
4. 监控和诊断- 安装网络监控系统，实时监测网络状态和性能，及时发现丢包问题，并进行相应的诊断和处理。
- 使用网络分析工具，对网络进行深入分析，找出丢包问题的具体原因，并采取相应的措施进行修复。
5. 加强安全措施- 针对网络攻击和恶意行为，加强网络安全措施，如防火墙、入侵检测系统等，避免因安全问题导致的丢包现象。
6. 定期维护和更新- 对网络设备进行定期维护和更新，确保设备的正常运行和性能稳定。
- 及时更新网络设备的固件和软件，修复已知的丢包问题和漏洞。
NOKIA网络问题小区分析及处理
概述
切换成功率是无线网络中一项重要的统计指 标。高切换成功率显示了网络的某一方面的正 常运转。因此，优化切换参数，降低切换失败 次数，从而提高切换成功率是网络优化中关键 的工作项目之一。我们今天主要阐述小区级切 换成功率的优化分析及处理方法。
影响切换差的因素
相邻小区存在同频同BSIC，导致误切换。 弱覆盖导致切换失败。 硬件故障导致切换失败。 邻区问题：邻区关系不完整、邻区参数不合理导致切换失 败。 干扰问题: 频点干扰，系统设备老化等因素造成的自激干 扰，直放站干扰，外部干扰等等导致切换失败。 拥塞问题: 小区话务拥塞导致切换失败。 孤岛效应导致切换失败。 其他。
道北东1 10 8 6 4 2 0
1 1 月 2 7 日
1 1 月 2 8 日
1 1 月 2 9 日
1 1 月 3 0 日
1 2 月 1 日
1 2 月 2 日
1 2 月 3 日
1 2 月 4 日
1 2 月 5 日
三：切换差小区分析及处理
概述 影响切换差的因素 切换失败具体分析思路 切换差小区相关案例分析
现场勘察、测试1
基站勘察：
是否高站：由于建网初期很多基站选址很高，高站覆盖范围很大， 需求根据实际覆盖距离检查频率是否干净、邻区是否完整。 天馈老化 ：天馈的老化驻波比过高影响覆盖和通话质量 小区接反、收发天线是否在同一方向，收发是否接反：收发天线不 在同一平面上分集接收效果不好。
现场测试：
切换是否正常 有无频率干扰 是否越区覆盖
。
参数设置
影响掉话的参数主要有切换参数和相邻小区参数。如：PMRG设置过高或相邻小区参数做错都会导 致掉话。
小区高掉话处理流程：
硬件故障
告警：
丢包解决方案
丢包解决方案一、问题描述在网络传输过程中，由于各种原因，会出现数据包丢失的情况。
这种丢包现象会导致网络传输不稳定，影响数据的完整性和可靠性。
为了解决这一问题，我们需要制定相应的丢包解决方案。
二、丢包原因分析1. 网络拥堵：当网络流量过大时，网络设备无法及时处理所有数据包，从而导致丢包现象的发生。
2. 网络延迟：当网络延迟较高时，数据包的传输时间会增加，从而增加了丢包的风险。
3. 网络故障：网络设备故障、线路中断等原因都可能导致数据包丢失。
4. 数据包冲突：当多个数据包同时发送到同一个目标地址时，可能会发生数据包冲突，导致部分数据包丢失。
三、丢包解决方案针对上述丢包原因，我们提出以下解决方案：1. 网络拥堵解决方案a. 提升网络带宽：增加网络带宽可以有效减少网络拥堵，降低丢包率。
b. 优化网络设备配置：合理配置网络设备的缓存、队列等参数，提升网络设备的处理能力。
c. 使用流量控制技术：通过使用流量控制技术，如拥塞控制算法，可以在网络拥堵时自动调整发送速率，减少丢包现象的发生。
2. 网络延迟解决方案a. 优化网络拓扑结构：合理规划网络拓扑结构，减少数据包传输的跳数，降低网络延迟。
b. 使用负载均衡技术：通过使用负载均衡技术，将网络流量均衡分配到多个服务器上，减少单个服务器的负载，降低网络延迟。
c. 选择低延迟的网络传输协议：选择低延迟的网络传输协议，如UDP协议，可以减少数据包传输的时延。
3. 网络故障解决方案a. 实施网络设备冗余：通过实施网络设备冗余，如使用冗余路由器、交换机等设备，当某个设备发生故障时，能够自动切换到备用设备，减少丢包率。
b. 定期维护和检修网络设备：定期维护和检修网络设备，及时发现和解决潜在故障，减少丢包的发生。
4. 数据包冲突解决方案a. 使用流量调度技术：通过使用流量调度技术，如队列调度算法，可以合理调度数据包的发送顺序，减少数据包冲突，降低丢包率。
b. 增加数据包重传机制：在数据包冲突发生时，增加数据包的重传机制，确保数据包的可靠传输。
华为下载速率波动案例
渝北水木青华HL测试有两个现象：（1）业务过程中出现业务中断的现象；（2）业务过程速率不稳定，有比较严重的毛刺现象。
流程图：业务过程中出现业务中断的现象：在正常业务过程中上行干扰不高，但是出现异常。
速率掉坑时候，上行RSSI达到－15db左右，突发的上行干扰很大，此时UE掉线并且频繁尝试重建，过一段时间后，干扰消失，业务恢复正常。
解决措施首先现场测试观察RSRP，SINR，误码率，CQI，MCS阶数等，排查到上行RSSI达到-15db左右,上行干扰较高，采取了如下解决步骤：（1）查询站点告警情况，站点未出现任何告警；（2）上站检查站点链接线，也未有接头错误或者松动问题；（3）用驻波比仪器进行测试，未发现异常，基本排除硬件故障；（4）进行服务器性能测试，灌包测试。
通过iperf灌包测试，后台跟踪基站的来水量，观察前台实际测试速率，排查从服务器到基站，基站到UE接口是否正常。
通过测试后台跟踪基站的来水量正常，排除了服务器的不稳定情况；（5）确认不是传输侧的问题；（6）最终使用前台多次测试验证，均存在比较严重的毛刺现象，说明了该问题的存在于空口。
问题定位后，确认问题出现在空口，对测试数据进行分析，由于下行PDCCH偶尔出现误码率较高，上行也出现误码率较高的现象，导致下载速率出现波动。
进行扫频测试，确实发现存在一定的外部干扰，但未发现周边有TD站点等干扰源，只能采取参数优化来对问题进行解决。
修改下行PDCCH CCE聚合级别、PDCCH功率值，增强PDCCH下行信道抗干扰能力，上行Bler目标值收敛到5％，增强上行抗干扰能力。
通过参数用户增强信道的抗干扰能力，然后测试观察，速率已经稳定在70M以上，毛刺现象基本消失；测试近1小时没有再出现掉坑的现象。
在日常的测试工作中，速率波动或者速率较低等异常问题时常出现，为了确保一次性解决掉问题，我们在对此问题处理时需要逐步的排查分析，并精准定位，导致此问题有可能为空口问题，硬件问题（天线自激），传输资源不足，参数配置错误等，需要逐一排查和验证，最终定位并处理问题，同时采取最优手段，处理时间快，问题复发性小，耗费资源小，处理问题思路清晰明确。
丢包解决方案
丢包解决方案【丢包解决方案】一、问题描述在网络通信中，丢包是指在数据传输过程中，部份数据包无法正常到达目的地。
丢包问题严重影响了网络通信的稳定性和数据传输的可靠性。
为了解决丢包问题，我们需要制定相应的解决方案。
二、原因分析1. 网络拥堵：当网络流量过大，网络设备无法及时处理所有数据包时，会造成部份数据包丢失。
2. 网络故障：网络设备故障、链路断开等问题会导致数据包无法正常传输。
3. 传输延迟：过高的传输延迟会增加数据包丢失的可能性。
4. 网络丢包率高：某些网络环境下，丢包率本身就较高，如无线网络环境。
三、解决方案针对丢包问题，我们提出以下解决方案：1. 网络优化通过对网络进行优化，可以减少丢包问题的发生。
具体措施包括：- 增加带宽：提升网络带宽可以减少网络拥堵，降低丢包率。
- 优化路由：合理规划网络路由，减少数据包在传输过程中的跳数，降低丢包风险。
- 部署QoS（Quality of Service）：通过配置QoS策略，优先保障重要数据包的传输，减少其丢包率。
2. 数据包重传机制为了保证数据的可靠传输，可以采用数据包重传机制。
具体措施包括：- 使用TCP协议：TCP协议具有可靠性，能够自动进行数据包的重传，确保数据的完整性。
- 设置超时重传机制：在传输过程中，如果发送方没有收到确认应答，就会触发超时重传机制，重新发送数据包。
3. 错误检测和纠正为了防止数据包丢失后无法恢复，可以采用错误检测和纠正技术。
具体措施包括：- 使用校验和：发送方在发送数据包时计算校验和，接收方在接收数据包后进行校验，如果校验和不匹配，则说明数据包可能发生错误，需要进行重传。
- 使用前向纠错码：通过添加冗余信息，接收方可以根据冗余信息对数据包进行纠正，从而减少丢包的影响。
4. 网络监控和故障排查定期进行网络监控和故障排查，可以及时发现丢包问题并进行解决。
具体措施包括：- 使用网络监控工具：通过监控网络设备的运行状态、流量等信息，及时发现异常情况。
诺西WCDMA测试分析案例
诺西WCDMA测试分析案例诺基亚公司是全球领先的通信技术公司之一，其WCDMA （Wideband Code Division Multiple Access）测试系统被广泛应用于无线通信领域。
本文将通过一个实际案例，阐述WCDMA测试分析的应用。
案例背景：一家移动通信运营商在部署WCDMA网时，发现网络内部存在一些收发通道出现错误或者丢包的情况。
这导致用户的通话质量和数据传输速率下降，需要找到问题的根源并及时解决，以保证网络的稳定性和可靠性。
解决方法：诺基亚公司提供了完整的WCDMA测试系统，可以对网络进行全面的测试和分析。
首先，通过系统的监测功能，运营商可以对网络性能进行实时监测，并收集相关数据。
然后，通过数据分析工具，运营商可以深入分析数据，找到错误和丢包的原因。
最后，运营商可以采取相应的措施，解决这些问题。
具体操作：1. 监测网络性能运营商可以使用WCDMA测试系统的监测功能，实时监测网络性能。
例如，运营商可以监测下行信道的RSSI（接收信号强度指标），CBER（信道误比特率）和BLER（帧误比特率）等指标。
同时，也可以监测上行信道的发射功率、TBF使用情况和HSDPA （高速下行数据传输）用户的连接和传输速率等数据。
2. 分析数据通过WCDMA测试系统收集的数据，运营商可以使用数据分析工具对数据进行深入分析。
例如，运营商可以采用多种方式对数据进行可视化分析，显示数据的分布情况和变化趋势。
此外，还可以采用不同的分析方法，例如回归分析、熵分析、聚类分析等，以找出异常或者错误的数据。
3. 解决问题通过上述步骤，运营商可以找到网络存在的问题，例如丢包率较高、信号强度不稳定或者TBF被占用过多等。
运营商可以采取不同的方法解决这些问题。
例如，优化网络配置参数、增加基站数量、采用智能天线技术等方法，以提高网络的性能和可靠性。
结论：WCDMA测试分析是保证移动通信网络稳定和可靠的重要手段，可以有效地监测网络性能、分析数据、解决问题，并提升用户的通话品质和数据传输速率。
丢包解决方案
丢包解决方案一、问题描述在网络通信中，丢包是指在传输过程中数据包丢失或者无法到达目的地的情况。
丢包问题会导致数据传输的不稳定，影响网络性能和用户体验。
因此，解决丢包问题对于保障网络通信质量至关重要。
二、原因分析1. 网络拥堵：当网络流量过大或者网络设备负载过高时，会导致数据包丢失。
2. 网络故障：网络设备故障、路线故障等问题会导致数据包丢失。
3. 网络延迟：高延迟会增加数据包丢失的风险，特殊是在实时性要求较高的应用中。
4. 网络安全策略：某些网络安全策略可能会导致数据包被过滤或者阻挠，从而引起丢包问题。
三、解决方案针对丢包问题，可以采取以下解决方案：1. 网络优化a. 增加带宽：通过增加带宽，可以有效减少网络拥堵导致的丢包问题。
b. 负载均衡：使用负载均衡器将网络流量均匀分配到多个服务器上，避免单一服务器负载过高导致的丢包。
c. QoS（Quality of Service）配置：优先级管理和流量控制可以匡助确保重要数据的传输，减少丢包的可能性。
2. 网络设备优化a. 更新固件：及时更新网络设备的固件可以修复已知的丢包问题和安全漏洞。
b. 优化路由器设置：合理配置路由器参数，如MTU（Maximum Transmission Unit）大小、缓冲区大小等，可以减少丢包的发生。
c. 检查硬件故障：定期检查网络设备的硬件状态，确保设备正常工作，避免硬件故障引起的丢包问题。
3. 网络监控与故障排除a. 使用网络监控工具：通过实时监测网络流量、延迟、丢包率等指标，及时发现丢包问题并采取相应措施。
b. 故障排除：对于丢包问题，可以通过Ping命令、Traceroute命令等工具进行故障排查，确定丢包发生的具体位置和原因。
4. 网络安全策略调整a. 配置防火墙规则：确保防火墙的规则设置合理，不会误判合法数据包导致丢包。
b. 避免过滤合法数据包：对于某些安全策略，需要确保不会过滤掉合法的数据包，避免引起丢包问题。
华为PTN传输隐性故障导致诺基亚LTE网络特定IP地址段eNB基站速率异常
故障描述：2015年1月27日中午14点30分，接到宁波余姚移动分公司投诉，余姚分公司有两个室分站，其中1个站点可正常上网，另一个站点上网异常，现场测试下载速率峰值只有1Mbps。
后经过对问题区域的拉网测试和一系列分析最终确定是由于华为PTN传输隐性故障导致诺基亚LTE网络特定IP地址段eNB基站下载速率异常，并且导致的一些用户投诉问题.在此次故障中，存在一下几个特征：（1）故障的表象从单个站点开始，排查具备片面性；该故障最初有宁波余姚分公司投诉开始，单个站点上网速率较低，分公司反映这类站点共计有5个，最初排障主要集中在单个站点的排障测试中，没能第一时间从全网考虑出发。
（2）无线主设备状态正常，无告警，排障具有隐蔽性；由于LTE网络的扁平化，用户感知的体验不好的排障由无线侧发起，在无线侧没有相关告警提示的情况下，增大了对站点排障的难度，拉长了故障处理时间。
（3）故障处理过程专业跨度较大，排障具有较强的不便性；本次故障涉及网优（具体指标查看）、无线（站点排查）、传输（定位故障原因落地侧）三个专业，故障处理过程专业跨度较大，在排障中具有很强的不便性。
流程图问题分析：❖首先对用户投诉的“NBYY移动新综合楼2ESTL”基站进行了初步分析排查:1、核查基站状态正常无告警，提取历史告警信息，也无任何历史告警；2、核查基站参数配置，问题发生时未进行过任何修改，参数配置核查亦无异常；3、后台查看指标情况，正常工作日上午会有峰值出现，峰值速率一般在50Mbps以上。
后台指标上看当天上午最大速率只有7Mbps，见下图-1：图-14、从指标上看，最大速率明显较日常下降很多，对基站进行重启操作后，无法恢复；采取TDS和TDL进行双重启同样无法恢复，且TDS侧站点指标均正常；❖1月27日余姚区域日常拉网测试时也反映发现下载速率异常:❖从余姚区域测试拉网结果来看，速率下降问题已经不是单个eNB站的问题而是区域性存在问题:1、15点后台跟踪基站LOG时发现有一个站点的LOG无法提取，后台ping该基站地址，发现时延非常大（2000ms左右，正常ping包时延不会超过10ms），对发现异常的站点均进行了Ping时延验证，发现都存在时延大的问题。
速率掉坑问题优化措施
速率掉坑问题优化措施速率掉坑问题优化分析一关键词低速率、上行RLC重传、rrc重建、乒乓切换二案例分类1、问题分类：用户感知、覆盖问题2、手段分类：前台DT测试、空口信令分析、参数优化三优化背景深圳移动精品线路位于福田区域，由信息大厦出发，经深南大道-益田路-福中三路-金田路-福中路-彩田路-笋岗西路-皇岗路-深南大道，最后返回信息大厦。
本次优化涉及客户演示，需重点优化覆盖及下行速率。
四问题现象精品线路DT测试，在皇岗路中段速率由171Mbit/s瞬间掉落到10Mbps。
五问题分析前台测试速率分析：测试车辆从北向南行驶，在皇岗路中段和皇岗技校站下(如图标记)，速率由171Mbit/s瞬间掉落到10Mbit/s以下，经过分析，排除了设备原因和服务器下载结束导致速率掉坑。
1、测试指标分析总体指标：本次测试无掉话和切换失败事件，整体RANK只有2.3，致使下载速率低。
SSBMAXRSRP(d Bm)CSIAvgSINR(dB)DLAvgMCS下行IBLER(%)DLResidualBLER(%)下行平均速率平均CQI平均流数弱覆盖/掉次/切换失败次数-80.0826.6713.7310.661.5115312.42.302、异常事件分析第一次速率掉坑，时间点15:29:12，原因是CPE有发生RRC 重建，引起重建原因是nrrlcomreportlinkfail，上行RLC达到最大重传次数。
3、覆盖分析地图上看，gNBID=35691（深圳皇岗中D-HRH）站点的3号小区信号已经远远越区覆盖到gNBID=35686（深圳皇岗技校D-HRH）的3号小区覆盖的主路径上，建议调整深圳皇岗中D-HRH站点的3号小区的天线方位角和下倾角，并适当降低功率。
4、切换分析第二次速率掉坑，15:30:25~15:30:31几秒钟之内，35686_67（PCI=266）与35691_67（PCI=427）反复发生了4次乒乓切换。
【诺西外场华为外场】测试速率问题定位结果
【诺西Band40室内分布场景】峰值测试速率偏低1.1 问题描述【诺西band40室内分布场景】_SUR-TL00_CA峰值测试速率偏低1.2 问题分析1.2.1 问题复现:1、宁波外场在测试环境一致的情况下，三星S6下行FTP平均速率可以达到200M以上（由于在速率达到200M以上时，电脑硬件配置并不支持导致卡机的情况，故速率软件记录为250M并不准确，但速率至少也有200M以上），然而华为SUR-TL00的FTP速率只有160M左右。
SUR_TL00速率：三星S6 速率：2、杭州华为基站外场CA环境，使用与宁波相同FTP和版本，SUR-TL00下行FTP平均速率201.5Mbps1.2.2 问题分析:1)宁波外场物理层处理分析UE上下行误码正常，MCS基本保持最大值，但RB时域调度不满。
UE下行误码正常，Bler低于0.5%UE上行误码低于0.3%由于误码较低，网侧调度的MCS基本维持在最大值28小区子帧配比为2，正常时域调度每秒为800次，但实际下行RB是不满的：从以上分析来看，UE底层未发现异常，调度不满原因为TCP时延较大导致。
2)TCP时延大的分析现象描述：CA速率不能达到峰值的原因是诺西环境配置特殊，导致UE部分数据堵在A核上，不能及时将TCP确认数据发送到网侧，TCP时延变长。
根因发现：对比诺西和华为网络参数，发现诺西UL RLC（AM模式）配置的Poll PDU（64）值和PollByte（750KB）大于华为网络配置的Poll PDU（32）值和PollByte（25KB），这种配置会导致UE上行数据堵在A核。
解决方案：增加缓存数据内存，SUR-TL00在诺西外场下行FTP可以达到200Mbps以上。
详细分析过程如下：1）诺西网络RLC AM模式参数配置对TCP时延影响：华为网络RLC AM模式的参数配置：按照诺西网络配置，Poll PDU和Poll byte 配置越大，UE的RLC发端未得到收端确认的PDU越多，那么UE UL RLC层需要更多内存来缓存数据。
诺基亚LTE性能恶化小区分析处理
诺基亚LTE性能恶化小区分析处理1.RRC连接建立成功率RRC连接建立成功率公式定义指标优化思路a)查看RRC接入失败原因Counter，看导致RRC失败的主要因素是什么。
RRC接入失败相关Counter：3项是由于接入用户数达到参数限定的最大接入用户数而产生的拒绝。
b)如果是由于用户限制而导致的接入失败，需要优化有接入用户数相关的参数，或控制覆盖范围，减少小区内的用户数。
接入用户数相关参数：区覆盖范围，减小小区用户量。
c)参数核查，检查参数是否在建议值范围内。
d)统计小区PUSCH的上行的干扰电平、SINR、UE的Power Headroom和下行CQI，看一下小区是否存在干扰，上下行质量如何。
如果小区的存在上下行的无线问题，需要进行无线优化。
e)Msg2/4鲁棒性优化，通过增加PDCCH中MSG2和MSG4的CCE聚合数量以及降低其在空口的最大编码效率，提升这两个消息在空口的抗干扰能力，降低误码率，从而提升接入成功率。
f)优化小区最小接入电平qrxlevimin，减小小区边缘无线环境很差的用户的接入。
g)现场无线测试，测试可能存在的弱覆盖、高干扰和质差区域，进行RF优化。
2.E-RAB建立成功率E-RAB建立成功率公式定义指标优化思路a)查看ERAB建立失败原因Counter，看导致ERAB建立失败的主要因素是什么。
ERAB建立失败相关Counter：c)如果是资源受限原因失败，检查资源数相关参数，根据实际情况进行调整。
如果已经达到系统设计的最大值，建议调整小区覆盖，降低小区负荷。
d)对于其他原因的失败，对小区进行Emil信令跟踪，通过信令分析发现导致ERAB建立失败的原因。
e)对于无线原因的ERAB建立失败，请参照“RRC连接建立成功率”中的无线优化措施。
3.无线掉线率无线掉线率公式定义指标优化思路a)检查天线的校准情况。
天线校准失败，或者天线权值设置问题，导致在波束赋形中，产生偏差，因此在TM模式转换时会导致掉话。
VOLTE问题分析RTP丢包率
RTP丢包率问题分析一、问题描述第一轮VOLTE测试工作已完成，通过后台指标统计发现全网RTP丢包率为1.98%，导致该指标的原因主要有4点：基站故障、弱覆盖、无线干扰、重叠覆盖；为此对全网丢包率较高的路段、小区进行问题分析及处理。
二、问题分析1、基站故障:主要由于基站退服导致主被叫呼叫建立时延较久或建立失败，导致RTP丢包率偏高；●主叫UE在集宁朗庭洗浴中心附近时，由于集宁朗庭洗浴-ZLHF退服导致UE占用集宁多经办-2小区，RSRP为-120.56dbm，SINR为-1.6，集宁多经办-2小区信号达到-110dbm以下，开始启动Event A2系统测量，进行B2切换，集宁多经办-2小区切换至2G小区，但是通过层3信令提示“cs-FallbackIndicator= false“说明重选2G失败，导致被叫脱网，在此期间对RTP丢包率影响较大，该路段丢包率为3.455%。
2、弱覆盖：现网部分路段由于覆盖较差，导致SINR值较高，无线环境不良，UE在此路段建立通话时，存在一定程度丢包现象。
●现网弱覆盖主要问题区域集中在4个地方，现已有规划街道站、新建站，目前尚未正式开通，具体区域及覆盖情况如下：3、无线干扰：本次VOLTE测试的主要受2方面影响，一是内部（MOD3）干扰；二是外部干扰器；导致呼叫建立时延较久，RTP丢包率较大；通过对主要路段进行分析确定问题路段，进行无线干扰优化提升指标。
●内部Mod3干扰问题：由于MOD3干扰，主叫UE行驶至该路段时，由集宁联通-3小区切换至集宁博物馆-3小区，并在完成RRC建立、ERAB建立及EPS 承载建立后，开始频繁切换2次（集宁博物馆-3→集宁联通-3→集宁教育局2），在此期间RTP丢包率较差，影响整体指标。
●外部干扰问题：由于外部干扰导致RTP丢包率较大路段一处；位于杜尔伯特路与迎宾路交叉口（集宁一中校区）时，由于上行干扰主叫UE未能正常切换至2G网络，引起掉话；在此期间RTP丢包率较大，主叫被迫脱网。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
NOKIA与HW速率掉坑问题以及高丢包问题分析
1.问题描述
某市有大面积的华为微站插花在诺基亚基站区域，插花在诺基亚基站区域的华为微站丢包异常高，造成volte丢包率下行异常高，volte下行丢包无法达到考核值，诺基亚基站和其他未插花华为基站总体丢包率较低，已经达到考核值，而插花在诺基亚区域的华为微站丢包偏高造成全网下行丢包率在0.4%左右，是考核值0.2%的两倍。
路测过程中发现当诺基亚基站向华为基站切花时或者特定场景诺基亚基站向华为基站切换时，存在切换后高误块的场景，造成下载速率偏低，远远达不到正常的下载速率，需要等待一会以后，下载速率才能达到正常值。
以上问题均发生在异厂家基站切换时。
但在子帧配比和特殊子帧配比SA2/SSP5配置下不存在该问题.
2.问题分析
2.1 ACK/NCK反馈模式
TDD中一个上行子帧可能要反馈多个下行子帧的ACK/NACK，协议采用了两种上报模式，Bundling和Multiplexing。
∙Bundling模式
将同一个用户不同下行子帧相同码字的ACK/NACK进行逻辑AND操作，发送1bit或者2bit 的ACK/NACK。
优点是比特数少，节约资源，用于下行信道质量较好，上行信道质量较差的情形；缺点是重传的数据量大。
--用较少的bit传输；
∙Multiplexing模式
将同一用户同一子帧的不同码字进行空间Bundling，即对两个码字的ACK反馈进行逻辑AND操作，传输最大4bit的ACK/NACK反馈。
优点是可以区分每个子帧的结果，有利于重传，用于下行信道质量差，上行信道质量好的情行；缺点是比特数大，占据较多资源。
--用较多的bit传输
对于ACK/NCK的反馈模式，华为网络在SA2/SSP6和SA2/SSP7配置下，会参考小区中当前用户数，为终端配置bundling或multiplexing模式。
使用multiplexing模式主要是基于频谱效率的考虑。
另外，3GPP 36331协议中规定，如果终端和系统协商出来的版本是R8/R9，则终端和系统间ACK/NACK反馈模式是通过RRC_CONN_RECFG中的tdd-AckNackFeedbackMode 信元表征；
如果终端和系统协商出来的版本是R10，对于Multiplexing模式且使用36213中的表格10.1.3-5, 10.1.3-6, and 10.1.3-7（R10协议引入）时，系统使用pucch-Format信元表征反馈模式，而不携带tdd-AckNackFeedbackMode信元；其他场景则使用
tdd-AckNackFeedbackMode信元表征反馈模式。
2.2各厂家反馈模式说明
Multiplexing反馈较bundling准确，但耗费PUCCH码道资源要多；Bundling反馈较Multiplexing不准，耗费重传资源较多，但占用PUCCH的码道资源少，因此各有优缺点。
协议没有明确规定Bundling和Multiplexing的选择场景，只要终端和eNodeB协议版本支持，则反馈模式可以由eNodeB厂家自行选择，然后通过RRC信令携带给终端，各个厂商实现不同。
对于华为产品
在TDD反馈模式配置优化开关（TddAckFbModeCfgOptSwitch）关闭的情况下，判断时隙配比、小区下前两个用户、非高铁、非CA用户则选择Multiplexing，反之则是Bundling；在TDD反馈模式配置优化开关打开的情况下，用户接入初始反馈模式配置为Multiplexing 模式，然后eNodeB根据小区级的PDCCH的负荷高于一定门限时，将用户重配置为Bundling模式，即轻载网络用户基本上都配置为Multiplexing模式。
华为网络在SA2/SSP6和SA2/SSP7配置下，会参考小区中当前用户数，为终端配置bundling或multiplexing模式。
对于诺基亚产品
只支持bundling模式。
注：若终端与基站使用的ack、nack反馈模式不一致，将造成终端与基站无法正常交互信令和数据。
2.3 问题分析说明
2.3.1诺基亚向华为切换时
当终端从诺基亚小区切换到华为小区，ACK/NCK反馈模式可能发生变化。
当从bundling 模式变为multiplexing模式时，系统会下发包含pucch-Format信元的切换信令，指示终端使用multiplexing模式，如下图所示：
根据分析，怀疑终端收到该信令后，并未使用multiplexing模式，或者不支持 R10协议36213中的表格10.1.3-5, 10.1.3-6,10.1.3-7，仍然使用bundling模式，并未使用multiplexing 模式，从而导致下行高丢包。
2.3.2 华为向诺基亚切换时
当终端从华为小区切向诺基亚小区时，分析切换的信令发现，切换前在华为站点使用的是Multiplexing，而切换到诺基亚站点后，诺基亚站点指定的反馈模式为Bundling模式，但是没有携带空的pucch-ConfigDedicated-v1020，导致终端和诺基亚站点侧使用的HARQ反馈模式不一致，导致下行高丢包。
正确的Multiplexing切换为Bundling模式的切换命令如下格式：
注：华为网络在SA2/SSP5配置下没有问题，是因为此配置下只使用bundling模式；
3 解决措施
基于以上分析，目前的规避方法：
1、规避华为丢包：
MODCELLALGOSWITCH:LOCALCELLID=xx,HARQALGOSWITCH=TddAckFbModeCfgOptSwitch-1;
华为TDD HARQ-ACK反馈模式配置优化开关为开，根据小区PDCCH负荷和UE业务情况，自适应配置UE的HARQ-ACK反馈模式，改善下行丢包。
（7月试验修改华为插花站点丢包改善效果明显，但是周边诺基亚基站丢包异常增长，故回退关闭）
2、规避诺基亚丢包：
MOD GLOBALPROCSWITCH:PROTOCOLCOMPATIBILITYSW=CaHoReqWithR9ConfigSwitch-1;
华为基站打开CA切换携带R9信元开关：开关用于控制源基站发起切换时切换请求是否携带特定的R9信元，当开关为打开时，基站在切换请求消息中携带sourceOtherConfig-r9和ue-ConfigRelease-r9信元，目的是：在切换命令中除了‘tdd-AckNackFeedbackMode bundling’，增加一个内容为空的pucch-ConfigDedicated-v1020字段，从而删除ChannelSelection-r10参数。
最终解决措施需要诺基亚提供版本支持HARQ-Multiplexing模式解决。
4.说明
以下为部分场景下切换模式说明，部分测试场景不全，可以看到ACK开关影响了诺基亚向华为切换时所使用的模式（规避华为丢包）、R9开关并未影响华为向诺基亚基站的切换模式，但在切换命令中除了‘tdd-AckNackFeedbackMode bundling’，增加一个内容为空的pucch-ConfigDedicated-v1020字段，从而删除ChannelSelection-r10参数，否则虽然切换中指示切换到诺基亚基站后使用bundling模式，但如果没有内容为空的pucch-ConfigDedicated-v1020字段，终端仍然无法从华为基站切换到诺基亚基站时使用bundling模式。