下载文档原格式
电信异⼚家边界基站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反馈模式可能发⽣变化。
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高掉线小区问题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的传输链路问题，相关问题需继续排查。
top小区处理意见低流量以及流量异常小区处理低流量小区是重要的KPI指标之一，指标反映了网络的移动性，指标直接影响到用户感知。
处理步骤：1. 首先核查是否为目标基站故障导致流量异常，查看当时站点的状态正常（基站是否存在故障）2. 现网核查参数等相关，发现参数设置无异常3. 与前台沟通后现场查看，无线环境正常，主覆盖区域为公路，上站检查无异常，更换光纤、光模块后观察流量依旧较低，后更换FBBA板，观察，流量恢复正常；总结：低流量以及流量异常小区优化首先排除外部干扰，基站故障等情况以外，还要针对基站相关参数、无线环境等进行进行核查，排除参数以及无线环境问题，之后利用前台实测数据分析，逐一排查问题根源，再进行处理。
零流量小区针对现场一个月的零流量小区统计情况分析，干扰、用户少、基站故障、人为调测、工程问题等都是导致零流量小区的原因：故障问题：电源：设备掉电端站，BBU掉电硬件告警：X2接口故障，系统时钟不可用，驻波等传输：传输光纤接口异常，BBU接口异常，射频R口接口异常覆盖、干扰问题：室外站点覆盖景区，景区冬季人少室外站点覆盖农村空旷公路室外站点不合理，如周围有村庄，密集人群活动区域，但天线覆盖方向不合理的.用户行为问题：活动场所：偶尔有活动，但周期比较长的。
随着季节变化，室外用户变少的.确实是用户过少的.工程原因：新建站处理故障期间，流量比较低小区未激活，导致零流量无线接通率低处理意见接入失败通常有三大类原因：无线侧参数配置问题、信道环境影响以及核心网侧配置问题。
因此遇到无法接入的情况，可以大致按以下步骤进行排查。
1.通过话统分析是否出现接入成功率低的问题，当前RRCeRAB接通率指标一般为98%，也可根据局点对接入成功率指标的特殊要求启动问题定位。
2.确认是否全网指标恶化，如果是全网指标恶化，需要检查操作，告警，是否存在网络变动和升级行为。
3.如果是部分站点指标恶化，拖累全网指标，需要寻找TOP站点。
诺基亚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. 定期维护和更新- 对网络设备进行定期维护和更新，确保设备的正常运行和性能稳定。
- 及时更新网络设备的固件和软件，修复已知的丢包问题和漏洞。
丢包解决方案一、问题描述在网络传输过程中，由于各种原因，会出现数据包丢失的情况。
这种丢包现象会导致网络传输不稳定，影响数据的完整性和可靠性。
为了解决这一问题，我们需要制定相应的丢包解决方案。
二、丢包原因分析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小时没有再出现掉坑的现象。
在日常的测试工作中，速率波动或者速率较低等异常问题时常出现，为了确保一次性解决掉问题，我们在对此问题处理时需要逐步的排查分析，并精准定位，导致此问题有可能为空口问题，硬件问题（天线自激），传输资源不足，参数配置错误等，需要逐一排查和验证，最终定位并处理问题，同时采取最优手段，处理时间快，问题复发性小，耗费资源小，处理问题思路清晰明确。
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模式。
