文档库 最新最全的文档下载
当前位置:文档库 › 网络丢包现象分析处理指导书一

网络丢包现象分析处理指导书一

网络丢包现象分析处理指导书一
网络丢包现象分析处理指导书一

网络丢包现象是常见的网络故障,但引起丢包的原因却多种多样、千奇百怪。因此对于此类故障的解决,要求处理人员洞悉网络基础理论、了解不同厂家产品特性,有耐心、深入地进行分析定位。”---《网络丢包现象分析处理指导书》摘录

从今天开始,本站将陆续发布系列网络丢包问题分析处理的技术文章。该系列文章来源于《网络丢包现象分析处理指导书》,主要分成三大部分:

第一部分:讲解从产生网络丢包问题的原因来看,网络丢包问题大致可以分为六大类因素,1、网络设备软、硬件问题;2、线路传输质量差引起丢包;3、网络设备配置不合理导致丢包;4、网络设计不合理导致丢包;5、人为攻击、广播泛滥造成的丢包;6、网络环境造成的丢包。对于每类丢包原因配置以大量的案例进行详细的说明。

第二部分:主要有三方面的内容,一是深入剖析网络丢包现象并加以总结;二是网络丢包的一般处理步骤;最后就是讲解网络故障处理中相关工具使用的注意事项。

第三部分:四个故障案例处理过程分析。应该说是对前面两部分内容的一个综合应用。

该系列文章的原始版本是原GW的HB老大当年的手稿,经过与原作者协商,同意在https://www.wendangku.net/doc/925541495.html,网站上发布。为此非常感谢HB,对HB的无私精神表示深深的感谢。

网络丢包问题往往是没有规律的故障,对于没有固定规律的故障,咱们技术工程师往往有吃力不讨好的痛苦!如本手稿中环境因素导致丢包案例中的电源浪涌,时值北方的冬季,加之故障这个魔鬼出现的时间是晚上7:00-9:00这个时段,现场工程师在用户单元楼道可以用饥寒交迫来形容!在此感谢为本手册付出了无数心血的原GW技术资源部的XDJM,正是他们的加班熬夜,将经历过故障进行总结,才能有今天这份珍贵的手册。

本手册是在原《网络丢包现象分析处理指导书》基础上进行部分的改动,谨此献给所有原GW技术资源部的XDJM,献给那段美好的光阴!献给那段偶们一起共同奋斗的岁月!

网络丢包现象分类:网络设备软、硬件问题导致丢包

首先对出现过丢包的案例进行描述并给出解决办法,同时对丢包问题进行分类,主要加强大家对丢包现象的感性认识。在后续的章节中再做深入的剖析,并提供问题的解决思路。

1、uHammer24百兆光口/电口模块问题

问题描述:uHammer24 芯片为C版且PCB为2.33版的设备百兆端口模块第25口,在高温及常温下会出现严重丢包,高温条件下尤为明显。

C版(PCB v2.33)uHammer24 port 25丢包示意图

问题解释:uHammer24的硬件分B版和C版,C版uHammer24的百兆端口模块25口的接口电路(千兆端口不受影响)在高温条件下(50oC以上)不稳定,造成丢包;B版在高温条件下(达到60oC)仍不会出现丢包。

问题解决:正确识别B版和C版设备。C版设备尽量使用在不用百兆端口模块的环境,如果一定要使用百兆模块的话,则建议更换B版设备或采用PCB为2.44/2.55的设备。

备注:此类丢包由于硬件芯片(产品序列号的第九到第十二位为“A233”)离散性较大引起,产品的PCB已做修改,新生产的设备,同样为C版,如果产品序列号的第九到第十二位为“A244”或“A255”则不存在此bug。

重要提示:如果出现某个端口丢包,建议更换端口做测试,查看丢包现象是否是个别端口问题。

问题描述:部分uHammer1008v(或者VDSL modem)由于晶振品质问题,导致与uHammer3100互连,距离较长时,出现严重丢包或同步不上。

问题解释:晶振品质不好,产生的脉冲信号在长距离传输时崎变较大,使得接收端无法识别。

问题解决:uHammer1008v(VDSL modem)更换品质较好的晶振。

备注:此类丢包也属于暂时性问题,更换硬件器件后将不再复现。

网络的拓扑如下

RiverStone3000(L3)作为网络的核心交换机,Flex16i汇聚了20几台接入层交换机u2,Flex16i只作为二层透传,所有用户的网关均指向Rs3000。网络稳定运行了3天后,Flex16i 的下连用户出现5%丢包。Test pc ping 210.177.208.163或164均出现5%左右的丢包。Rs3000上ping server 出现5%的报文出现延时时间达到1秒。可以判断,客户端丢包是由于icmp报文超时的缘故。

问题解释:为了更准确地定位问题,做了如下测试环境。

用Test pc ping pc2同样出现5%的丢包率。Rs3000 ping test u2 5%报文的延时在1秒左右。在测试过程中,测试过Flex16i同一设备(510芯片)和不同设备(510芯片)下的二层用户互ping,同样出现5%丢包。显然可以排除光纤、u2等其他设备引起该问题。实

际环境和测试环境中RS3000直接pingFLex16i的IP地址均没有出现报文延时时间长的现象。但ping Flex16i下连的u2则出现5%左右的报文延时长。因此,可以判断问题出现在Flex16i的二层转发上。

问题解决:将Flex16i reboot,故障依然;将Flex16i关电重启,故障消失,网络恢复

正常!热启动和冷启动对于Flex16i来说,其硬件的初始化过程不一样,冷启动对硬件的初始化处理比较彻底,是否硬件还存在深层的Bug,需要研发人员做进一步的定位。

备注:虽然该故障定位在Flex16i上,但是是什么原因引起Flex16i的二层转发异常,并

未能给出一个圆满的答案,不能不说是个遗憾。不过,这里要强调的是故障的定位处理,事实上这样的工作已经有利于研发对产品的改进工作了。

问题描述:uHammer24 软件版本为v1.323以下的版本的部分设备存在着14、18、22端

口严重丢包,下连用户上网速度慢。在v1.323版本出现个别端口丢包的现象已很少见(到目前为止市场上反馈过2例v1.323 port 14有丢包现象),升级为v1.4版本可以彻底解决。

问题解释:某些u24的phy芯片对时钟很敏感,如果交换机主板硬件出现频差,则phy

芯片工作就不正常。目前v1.323版本中通过定期写寄存器去修正频差产生的影响。但是

V1.323中轮循的时间过长,phy芯片的寄存器没有及时得到更新,所以会产生很明显的link down现象。在v1.4版本中,缩短了轮询时间,到目前为止未发现个别端口丢包现象。

问题解决:升级到v1.4版本可彻底解决此问题。

备注:对于新上设备,要求最低可用版本V1.323。

问题描述:Flex5010 v1.0网段表设置算法缺乏考虑路由最长匹配原则,当路由条目存在

多个匹配信息时,容易出现数据包循环转发,表现为用户上网速度慢、丢包甚至网络不通。拓扑结构见下图:(为了说明问题,网络拓扑已做简化)

上图为一大型行政机关的网络拓扑图,该单位网络为专网,与Internet没有互连,采用10.0.0.0/8的地址段。其中Flex5010以千兆光口与Big800互连,Big800端分配到

10.94.0.0/16的网段,Flex5010端分配到10.95.0.0/16的网段。

Flex5010软件路由表存在的条目如下:

10.94.101.4/30直连

10.95.1.0/24直连

10.95.2.0/24下一跳10.95.1.253

10.0.0.0/8下一跳10.94.101.5

而Flex5010v1.0的硬件网段表在开机时是空白的,只有当软件路由表的路由条目使用过一次后,才将其置入硬件网段表中。同时,一个报文在Flex5010路由时,是先去匹配硬件网段表,如果匹配不到才去匹配软件路由表。

考虑一种特殊的情况:10.0.0.0/8的路由早于10.95.2.0/24置入硬件网段表。即此时的硬件网段表只有一项:

10.0.0.0/8下一跳10.94.101.5

此时,当Flex5010下连的一台主机(10.95.1.1)去与10.95.2.0/24网段的设备通信时,则会出现:10.95.1.1发给10.95.2.0/24的报文到达Flex5010后,Flex5010查找硬件网段表,首先匹配到10.0.0.0/8的条目,因此该报文转发给10.94.101.5(Big800),Big800查找路由表,发现该报文应该转发给Flex5010,Flex5010再此将报文转发给Big800,于是,此类报文在Flex5010和Big800之间循环转发,指导TTL值为0,设备才将报文丢弃。

由于大量的废弃报文在Big800和Flex5010的链路传送(一个上述的报文在该链路需要转发250多遍),因此造成链路拥塞,网络丢包、不通。

问题解释:先激活先置表的算法违背了最长匹配算法,因此,在多路由匹配的环境下会出现上述问题。

问题解决:OS为 v1.1以上版本可解决此问题。V1.1不再采用先激活先置入网段表的算

法,而是一开始则将所有路由条目置入网段表中(除了路由条目超过16条的情况);如果路由条目超过16条则放弃网段表不用完全走软路由(关于路由条目超过16条后如何充分发挥Flex5010的硬件资源请详见《Flex5010硬件表设置方案》。

备注:此类问题由于是设备软件bug引起,因此准确定位问题比较困难。往往通过捕获链

路上的数据流定位出现问题的设备,再深入分析设备的硬件、软件路由信息,任务、进程等等,最终才能确定问题所在。

最全的网络故障案例分析及解决方案

第一部:网络经脉篇2 [故事之一]三类线仿冒5类线,加上网卡出错,升级后比升级前速度反而慢2 [故事之二]UPS电源滤波质量下降,接地通路故障,谐波大量涌入系统,导致网络变慢、数据出错4 [故事之三]光纤链路造侵蚀损坏6 [故事之四]水晶头损坏引起大型网络故障7 [故事之五] 雏菊链效应引起得网络不能进行数据交换9 [故事之六]网线制作不标准,引起干扰,发生错误11 [故事之七]插头故障13 [故事之八]5类线Cat5勉强运行千兆以太网15 [故事之九]电缆超长,LAN可用,WAN不可用17 [故事之十]线缆连接错误,误用3类插头,致使网络升级到100BaseTX网络后无法上网18 [故事之十一]网线共用,升级100Mbps后干扰服务器21 [故事之十二]电梯动力线干扰,占用带宽,整个楼层速度降低24 [故事之十三]“水漫金山”,始发现用错光纤接头类型,网络不能联通27 [故事之十四]千兆网升级工程,主服务器不可用,自制跳线RL参数不合格29 [故事之十五]用错链路器件,超五类线系统工程验收,合格率仅76%32 [故事之十六]六类线作跳线,打线错误造成100M链路高额碰撞,速度缓慢,验收余量达不到合同规定的40%;34 [故事之十七]六类线工艺要求高,一次验收合格率仅80%36 第二部:网络脏腑篇39 [故事之一] 服务器网卡损坏引起广播风暴39 [故事之二]交换机软故障:电路板接触不良41 [故事之三]防火墙设置错误,合法用户进入受限44 [故事之四]路由器工作不稳定,自生垃圾太多,通道受阻47 [故事之五]PC机开关电源故障,导致网卡工作不正常,干扰系统运行49 [故事之六]私自运行Proxy发生冲突,服务器响应速度“变慢”,网虫太“勤快” 52 [故事之七]供电质量差,路由器工作不稳定,造成路由漂移和备份路由器拥塞54 [故事之八]中心DNS服务器主板“失常”,占用带宽资源并攻击其它子网的服务器57 [故事之九]网卡故障,用户变“狂人”,网络运行速度变慢60 [故事之十]PC机网卡故障,攻击服务器,速度下降62 [故事之十一]多协议使用,设置不良,服务器超流量工作65 [故事之十二]交换机设置不良,加之雏菊链效应和接头问题,100M升级失败67 [故事之十三]交换机端口低效,不能全部识别数据包,访问速度慢70 [故事之十四]服务器、交换机、工作站工作状态不匹配,访问速度慢72 第三部:网络免疫篇75 [故事之一]网络黑客程序激活,内部服务器攻击路由器,封闭网络75 [故事之二]局域网最常见十大错误及解决(转载)78 [故事之三] 浅谈局域网故障排除81 网络医院的故事 时间:2003/04/24 10:03am来源:sliuy0 整理人:蓝天(QQ:) [引言]网络正以空前的速度走进我们每个人的生活。网络的规模越来越大,结构越来越复杂,新的设备越来越多。一个正常工作的网络给人们带来方便和快捷是不言而喻的,但一个带病

LTE网络优化经典案例-重要

1 LTE优化案例分析 1.1 覆盖优化案例 1.1.1 弱覆盖 问题描述:测试车辆延长安街由东向西行驶,终端发起业务占用京西大厦1小区(PCI =132)进行业务,测试车辆继续向东行驶,行驶至柳林路口RSRP值降至-90dBm以下,出现弱覆盖区域。 问题分析:观察该路段RSRP值分布发现,柳林路口路段RSRP值分布较差,均值在-90dBm以下,主要由京西大厦1小区(PCI =132)覆盖。观察京西大厦距离该路段约200米,理论上可以对柳林路口进行有效覆盖。 通过实地观察京西大厦站点天馈系统发现,京西大厦1小区天线方位角为120度,主要覆盖长安街柳林路口向南路段。建议调整其天线朝向以对柳林路口路段加强覆盖。 调整建议:京西大厦1小区天线方位角由原120度调整为20度,机械下倾角由原6度调整为5度。 调整结果:调整完成后,柳林路口RSRP值有所改善。具体情况如下图所示。

问题描述:测试车辆延月坛南街由东向西行驶,发起业务后首先占用西城月新大厦3小区(PCI= 122),车辆继续向西行驶,终端切换到西城三里河一区2小区(PCI =115),切换后速率由原30M降低到5M。 问题分析:观察该路段无线环境,速率降低到5M时,占用西城三里河一区2小区(PCI =115)RSRP为-64dBm覆盖良好,SINR值为2.7导致速率下降。观察邻区列表中次服务小区为西城月新大厦3小区(PCI =122)RSRP为-78dBm,同样对该路段有良好覆盖。介于速率下降地点为西城三里河一区站下,西城月新大厦3小区在其站下应具有相对较好的覆盖效果,形成越区覆盖导致SINR环境恶劣,速率下降。 调整建议:为避免西城月新大厦3小区越区覆盖,建议将西城月新大厦3小区方位角由原270度调整至250度,下倾角由原6度调整为10度。 调整后 调整结果:西城三里河一区站下仅有该站内小区信号,并且SINR提升到15以上,无线环境有明显提升。

S12508由于配置URPF导致设备丢包案例分析

S12508由于配置URPF导致设备丢包案例分析 关键词: ?URPF ?丢包 ?0推荐,1495浏览 ?1收藏,我的收藏 问题现象 如下拓扑图:S12508-1和S12508-2做VRRP,现场发现从S12508-FW这台设备跨S12508-02去ping S12508-01有大量丢包,丢包很规律,每五个包只会通一个。S12508-FW直连ping S12508-2不会丢包,S12508-2与S12508-1直连互ping也不丢包。并且业务一直也不受影响,就如下两个地址互ping有丢包: 从S12508-FW的本地地址(211.138.35.34)到S12508-1(221.181.39.254) [12508-FW]ping -c 12 -a 211.138.35.34 221.181.39.254 Ping 221.181.39.254 (221.181.39.254): 56 data bytes, press CTRL_C to break Request time out Request time out Request time out Request time out Request time out 56 bytes from 221.181.39.254: icmp_seq=0 ttl=255 time=8.305 ms Request time out Request time out Request time out Request time out Request time out 56 bytes from 221.181.39.2549.1.1.2: icmp_seq=4 ttl=255 time=1.651 ms

丢包率高的原因与解决

网络链接阻塞 数据在网络传输过程中会经过很多设备和网络链接,只要其中一个网络链接在数据到达之前已经满负载了,那么数据将会在这里阻塞一段时间。如果说网络设备非常落后,那么网络链接就没有足够的等待空间给新数据,它唯一能做的就是将信息丢弃。 修复方法: A增加阻塞链接的带宽 B使用Qos(流量优先级和资源保留控制机制)优先处理实时应用。尽管这种方法并不能缓解网络链接阻塞情况,但是它可以优先处理语音和视频来降低断线的可能性。 设备性能(路由器、防火墙、交换机) 在带宽充足的情况下,如果你的路由器、防火墙、交换机不能处理流量,那么你仍然有可能面临丢包的情况。让我们考虑一个场景,流量报告显示日高峰时期流量达到了顶点,所以你将网络带宽从1Gb 升级到10Gb ,升级之后数据显示你只能达到1.5Gb。当网络数据包传送到达网络设备,但是此时网络设备的CPU,或者内存满载了,它们就会丢弃不能处理的数据包。 修复方法: 更换更好的网络硬件,或者构建集群来提高网络的利用率。

网线缆线或硬件问题 另外一个常见的导致丢包的原因可能是由物理组件故障引起的。如果硬件故障,那么通常在设备终端或者系统日志中输出错误信息。如果是网络链接错误,一般是网络接口出错,这可以在铜缆线和光纤上检测到。 修复方法: 这些是网络丢包的常见原因之一,为了准确找到问题所在,最好是做网络评估和彻底的故障排查。核实清楚后故障的硬件必须更换,故障的网络链接必须修复。 网络设备上的软件问题 我们都希望网络设备上的软件是完美的,但是事实并非如此,这些网络设备十分复杂,遇到bug只是时间问题而已。 修复方法: 需要更新软件的最新版本。

LTE网络优化案例重要

1LTE优化案例分析 1.1覆盖优化案例 1.1.1弱覆盖 问题描述:测试车辆延长安街由东向西行驶,终端发起业务占用京西大厦1小区(PCI =132)进行业务,测试车辆继续向东行驶,行驶至柳林路口RSRP值降至-90dBm以下,出现弱覆盖区域。 问题分析:观察该路段RSRP值分布发现,柳林路口路段RSRP值分布较差,均值在-90dBm 以下,主要由京西大厦1小区(PCI =132)覆盖。观察京西大厦距离该路段约200米,理论上可以对柳林路口进行有效覆盖。 通过实地观察京西大厦站点天馈系统发现,京西大厦1小区天线方位角为120度,主要覆盖长安街柳林路口向南路段。建议调整其天线朝向以对柳林路口路段加强覆盖。 调整建议:京西大厦1小区天线方位角由原120度调整为20度,机械下倾角由原6度调整为5度。 调整结果:调整完成后,柳林路口RSRP值有所改善。具体情况如下图所示。 1.1.2越区覆盖 问题描述:测试车辆延月坛南街由东向西行驶,发起业务后首先占用西城月新大厦3小区(PCI= 122),车辆继续向西行驶,终端切换到西城三里河一区2小区(PCI =115),切换后速率由原30M降低到5M。

问题分析:观察该路段无线环境,速率降低到5M时,占用西城三里河一区2小区(PCI =115)RSRP为-64dBm覆盖良好,SINR值为2.7导致速率下降。观察邻区列表中次服务小区为西城月新大厦3小区(PCI =122)RSRP为-78dBm,同样对该路段有良好覆盖。 介于速率下降地点为西城三里河一区站下,西城月新大厦3小区在其站下应具有相对较好的覆盖效果,形成越区覆盖导致SINR环境恶劣,速率下降。 调整建议:为避免西城月新大厦3小区越区覆盖,建议将西城月新大厦3小区方位角由原270度调整至250度,下倾角由原6度调整为10度。 调整后 调整结果:西城三里河一区站下仅有该站内小区信号,并且SINR提升到15以上,无线环境有明显提升。 1.1.3重叠覆盖 问题描述:测试车辆延长安街由西向东行驶,终端占用中华人民共和国科技部2小区(PC=211)进行业务,随后切换至海淀京西大厦1(PC=133)小区,业务正常保持。车辆继续向东行驶,终端又回切至中华人民共和国科技部2小区(PC=211)发生掉话。 问题分析:观察该路段切换过程,终端由中华人民共和国科技部2小区(PC=211)正常切换至海淀京西大厦2小区后又出现回切情况导致掉话。两小区RSRP值相近,相差3dBm以内,造成该路段为无主覆盖路段,发生频繁切换最终导致掉话。 调整建议:针对该路段无主覆盖问题,建议调整京西大厦2小区功率由原15降低为5,使其不会对长安街路段实行有效覆盖。

网络丢包分析案例、解决方案

网络丢包分析 数据在网络层以数据包的形式进行传输,由于各种原因,数据包在传输过程中总会存在些许损失,我们称之为丢包。 1.1. 造成丢包的原因有哪些 ?网络设备的故障 包括硬件方面的和软件方面的故障。硬件故障主要是物理层面的故障如:网卡故障,端口故障等。软件故障主要是在配置方面的问题,如错误的静态路由,主机默认网关配置错误等等。 ?网络拥塞 通常由于网络带宽过小或网络中存在异常流量时发生,比如ARP攻击,P2P等。 ?MTU配置不当 在关键设备上MTU设置不当,也会造成网络丢包(以太网:1500字节,IEEE 802.3/802.2 1492字节)。 1.2. 如何确定网络丢包的存在 通常我们利用PING x.x.x.x -t这个命令来进行测试网络中是否存在丢包 在上图中可以看到,在本机上向192.168.122.2这个不存在的地址进行长时间PING的时候,发送出去的ICMP包都丢失了,丢失率达到100%。即从本机到192.168.122.2这个实际不可达地址的路径上存在丢包。 1.3. 定位网络丢包的分析步骤 在网络丢包发生的情况下,用户会明显感受到网络速度变慢,这时候网管首先需要做的就是进行PING X.X.X.X –t来进行大致是哪个网段的诊断。在发现确实有丢失率存在的情况下,我们可以利用科来软件进行进一步分析。 在分析之前,我们有必要学习一下前置知识。 TCP协议的特点之一就是保障数据传输的可靠性,即确保数据能够正确完整传输。那么TCP究竟是如何来保障的?可以看到,TCP在传输时,有着传输确认—重传机制,即发送数据一方在传输数据时为每一个分段编制序列号(Sequence Number),接收方会向发送方发送接收到分段数据的确认(Acknowledgment),通过这种方式确认数据是否准确传送,在无法确认某分段数据被准确传送或确认某分段数据没有被准确传送时重新进行传输。

典型的网络故障分析、检测与排除

典型的网络故障分析、检测与排除 摘要: 网络故障极为普遍,故障种类也十分繁杂。如果把网络故障的常见故障进行归类查找,那么无疑能够迅速而准确的查找故障根源,解决网络故障。文章主要就网络常见故障的分类诊断及排除进行了阐述。根据网络故障的性质把网络故障分为物理故障与逻辑故障。其物理故障也就是网络设备的故障。其逻辑故障是网络中配置管理的错误。也可根据网络故障的对象把网络故障分为线路故障、路由故障和主机故障。本文主要介绍路由器故障、配置故障、及连接故障的诊断与排除。通过运用工具和方法分析出导致网络故障的主要原因,及解决方法。 关键词:计算机网络,网络故障,分析诊断,物理类故障,逻辑类故障 引言 计算机网络故障是与网络畅通相对应的一个概念,计算机网络故障主要是指计算机无法实现联网或者无法实现全部联网。引起计算机网络故障的因素多种多样但总的来说可以分为物理故障与逻辑故障,或硬件故障与软件故障。采取有效的故障防预措施网络故障目前已经成为影响计算机网络使用稳定性的重要因素之一,加强对计算机网络故障的分析和网络维护已经成为网络用户经常性的工作之一。及时进行网络故障分析和网络维护也已经成为保障网络稳定性的重要方式方法。本文从实际出发,即工作中遇到的网络故障,描述了通过运用网络知识进行故障排除。按照故障现象—>故障分析-->故障解决的研究路线阐述了如何在实际中排除网络故障,及其在网络安全的应用中的重要性。 本文着重讲解了网络故障的排除方法,通过运用解决问题的策略与排除故障的思路在故障现场很快的检测出是属于哪种故障然后再基于故障提出方案给予解决。 正文: 一、网络故障 (一)物理类故障 物理故障,是指设备或线路损坏、插头松动、线路受到严重电磁干扰等情况。比如说,网络中某条线路突然中断,这时网络管理人员从监控界面上发现

LTE网络优化经典案例

1 LTE 优化案例分析 1.1 覆盖优化案例 1.1.1 弱覆盖 问题描述:测试车辆延长安街由东向西行驶,终端发起业务占用京西大厦1 小区( PCI =132 )进行业务,测试车辆继续向东行驶,行驶至柳林路口RSRP值降至-90dBm 以下, 出现弱覆盖区域。 问题分析:观察该路段RSRP 值分布发现,柳林路口路段RSRP 值分布较差,均值在-90dBm 以下,主要由京西大厦1 小区( PCI =132)覆盖。观察京西大厦距离该路段约200 米,理论上可以对柳林路口进行有效覆盖。 通过实地观察京西大厦站点天馈系统发现,京西大厦1 小区天线方位角为120 度,主要覆盖长安街柳林路口向南路段。建议调整其天线朝向以对柳林路口路段加强覆盖。 调整建议:京西大厦1 小区天线方位角由原120 度调整为20 度,机械下倾角由原6 度调整为5 度。 调整结果:调整完成后,柳林路口RSRP 值有所改善。具体情况如下图所示。 1.1.2 越区覆盖 问题描述:测试车辆延月坛南街由东向西行驶,发起业务后首先占用西城月新大厦3 小区( PCI= 122 ),车辆继续向西行驶,终端切换到西城三里河一区2小区( PCI =115 ),切换后速率由原30M 降低到5M。 问题分析:观察该路段无线环境,速率降低到5M 时,占用西城三里河一区2 小区(PCI =115) RSRP 为-64dBm 覆盖良好,SINR 值为2.7 导致速率下降。观察邻区列表中次服务小区为西城月新大厦3 小区(PCI =122 )RSRP为-78dBm ,同样对该路段有良好覆盖。介于速率下降地点为西城三里河一区站下,西城月新大厦3 小区在其站下应具有相对较好的覆盖效果,形成越区覆盖导致SINR 环境恶劣,速率下降。 调整建议:为避免西城月新大厦3小区越区覆盖,建议将西城月新大厦3 小区方位角由原270 度调整至250 度,下倾角由原6 度调整为10 度。 调整后 调整结果:西城三里河一区站下仅有该站内小区信号,并且SINR 提升到15以上,无线环境有明显提升。 1.1.3 重叠覆盖 问题描述:测试车辆延长安街由西向东行驶,终端占用中华人民共和国科技部2 小区 ( PC=211)进行业务,随后切换至海淀京西大厦1(PC=133)小区,业务正常保持。车辆继续向东行驶,终端又回切至中华人民共和国科技部2小区( PC=211)发生掉话。 问题分析:观察该路段切换过程,终端由中华人民共和国科技部2 小区( PC=211)正常切换至海淀京西大厦2 小区后又出现回切情况导致掉话。两小区RSRP 值相近,相差3dBm 以内,造成该路段为无主覆盖路段,发生频繁切换最终导致掉话。 调整建议:针对该路段无主覆盖问题,建议调整京西大厦2小区功率由原15 降低为5,使其不会对长安街路段实行有效覆盖。 调整结果:调整后,SINR 值有明显改善,保持在20 左右,多次测试该路段不会出现频繁切换情况,避免掉话等异常事件发生。 1.2 切换优化案例

网络丢包的几种可能性1

网络丢包是我们在使用ping对目站进行询问时,数据包由于各种原因在信道中丢失的现象。ping使用了ICMP回送请求与回送回答报文。ICMP回送请求报文是主机或路由器向一个特定的目的主机发出的询问,收到此报文的机器必须给源主机发送ICMP回送回答报文。这种询问报文用来测试目的站是否可到达以及了解其状态。需要指出的是,ping是直接使用网络层ICMP的一个例子,它没有通过运输层的UDP或TCP。 网络丢包的原因主要有物理线路故障、设备故障、病毒攻击、路由信息错误等,下面我们结合具体情况进行说明。 物理线路故障 网管员发现广域网线路时通时断,发生这种情况时,有可能是线路出现故障,也可能是用户方面的原因。为了分清是否是线路故障,可以做如下测试。 如果广域网线路是通过路由器实现的,可以登录到路由器,通过扩展ping向对端路由器广域网接口发送大量的数据包进行测试。 如果线路是通过三层交换机实现,可在线路两端分别接一台计算机,并将IP地址分别设为本端三层路由交换机的广域网接口地址,使用“ping 对端计算机地址 -t”命令进行测试。 如果上述测试没有发生丢包现象,则说明线路运营商提供的线路是好的,引起故障的原因在于用户自身,需要进一步查找。 如果上述测试发生丢包现象,则说明故障是由线路供应商提供的线路引起的,需要与线路供应商联系尽快解决问题。 由物理线路引起的丢包现象还有很多,如光纤连接问题,跳线没有对准设备接口,双绞线及RJ-45接头有问题等。另外,通信线路受到随机噪声或者突发噪声造成的数据报错误,射频信号的干扰和信号的衰减等都可能造成数据包的丢失。我们可以借助网络测试仪来检查线路的质量。 设备故障 设备故障主要是指设备硬件方面的故障,不包含软件配置不当造成的丢包。如网卡是坏的,交换机的某个端口出现了物理故障,光纤收发器的电端口与网络设备接口,或两端设备接口的双工模式不匹配。

配电网故障预控措施及典型案例分析

配电网故障预控措施及典型案例分析 发表时间:2016-11-04T15:05:20.767Z 来源:《电力设备》2016年第15期作者:章勇王浩张彬彬 [导读] 笔者配网故障防范措施入手进行阐述,再通过本单位出现的典型故障案例进行分析,并提出相关整改措施及事件启示。 (国网江苏省电力公司徐州供电公司江苏徐州 221005) 摘要:随着配电电网建设发展,提高供电可靠率、减少配电网故障是一个系统工程,不仅要加强配电网络的运行维护与管理,加强配电网络的建设,还需要加大对故障情况的分析,要从多方面努力才能取得实效。供电企业在进一步提高配电网络的供电可靠性和运行经济性、为广大用户提供优质服务的同时,也为企业带来更大的社会效益和经济效益。保障配网设备的安全稳定运行,减少设备故障的发生。笔者配网故障防范措施入手进行阐述,再通过本单位出现的典型故障案例进行分析,并提出相关整改措施及事件启示。 关键词:配电网,运行,供电可靠性,故障,异常 0 引言 提高供电可靠性、减少配电网故障率,是配电运检专业一项重要基础工作和综合性很强的生产工作,需要从配电网自动化管理作为抓手,针对造成配网故障的主要影响因素,了解故障根源,采取可靠的10kV配电网的预控故障管理措施,才能将各类故障异常遏制。配电网故障的原因气候环境有较大关联,其诱因最终导致的是配网设备故障,发展至事故,首先应对配电网气候环境、设备负荷及人员管理等因素采取相应预控措施。 1 配电网故障原因分析及预控措施 1社会环境造成配网故障的主要方面 社会经济高速发展带来了楼宇建设、交通繁忙,对线路通道造成一定安全隐患,车辆碰撞杆塔导致线路故障的情况时有发生,尤其在夜间或施工场所。基建施工场所对配电网的破坏也是有发生,主要表现在以下方面:①施工机械、物料超高超长碰触带电部位或破坏杆塔;②基面开挖伤及地下敷设电缆;③修路、建房、烧砖等取用土时,对架设在田间地头电杆地段进行取土,破坏了电杆基础,造成电杆倾斜倒塌。 2社会环境因素采取的预控措施 针对道路交通造成的隐患,采取的措施非常必要,一般建议采用反光漆作为方法措施之一,离地面20cm起往上粉刷杆塔,黄黑颜色相间,各3道,色带高度为20cm则可。对屡屡遭受碰撞的杆塔,可在来车前方1m处设置防撞混凝土墩,并刷上类似的反光漆并在拉线上套上带反光标示的护筒;或迁移该类杆塔。 针对施工现场的反故障措施主要有以下几个方面:加大宣传力度,利用各种传媒长期、广泛宣传保护电力设施的重要性,解释破坏电力设施所带来的严重后果以及肇事者应负的责任;有开挖可能的地下线路,适当设置警示牌,增加巡视的次数。 3气候环境造成配网故障的主要方面 根据多年来的配网运行管理经验,耐张点的悬式绝缘子在雷击时极少发生闪络故障,故障发生点集中在针式绝缘子上,应进一步提高针式绝缘子的耐雷水平有助于提高线路的防雷能力。 在配电架空线路抗击冰冻方面,加强线路的抗倾覆能力是关键。大雪会造成线路积雪增加导线荷载,当气温下降到一定程度时,伴随着雪雨水还会在导线上形成覆冰,从而引起导线弧垂增加,受力增大造成到杆断线故障。 2气候环境因素采取的预控措施 针对雷击事故,应提高绝缘子的耐雷水平,特别是针式绝缘子的耐雷水平。安装线路避雷器,部分特殊线路段加装避雷线。提高绝缘子的绝缘等级,只是其中一个方面,还不足以保障线路在遭受雷击后能安全运行,配套措施是增加泄雷通道,而安装线路避雷器则是一个经济、简单、有效的措施。线路避雷器安装地点的确定原则是尽量安装在周围无高层建筑物、地方开阔的线路段上,尤其是雷击多发区周围有高层建筑物屏蔽雷电的线路段可不用考虑安装,以节省投资。雷电高发区的确定可参考气象部门已确定的雷区分布图另一方面可借助雷电信息定位系统的统计数据核实线路是否处于雷击多发区。 10kV线路避雷器建议选用带金属氧化物避雷器的复合绝缘子。定期检测接地网,确保接地网的接地阻值合格。确保了足够数量的泄雷通道后还应保证泄雷通道畅通无阻,而合格的接地网是保障泄雷通道畅通的一个关键原因。定期进行接地网的阻值检测期,对阻值不合格的接地网,视运行时间和实际检测的阻值情况,可分别采用重新构造接地网或增打地极的方法处理。 针对冰雪灾害天气,建议在积雪结冰或风口地段尽量减少档距和多采用耐张段,拉线设置合理,拉盘合格,尽量防止故障进一步扩大。必要时采用人工除冰的办法,尽量减少损失。 5针对设备陈旧及负荷采取的预控措施 对于重载配电网线路和公用台区应每月开展负荷监测工作。对于长期稳定过负荷的馈线建议采取预警制度,及时制定整改方案转接负荷;对于柱上断路器、跌落式熔断器、阀式避雷器、针式绝缘子、高损配变、高低压配电柜、并沟线夹等早期投运的残旧设备,应选用技术参数高的现行产品结合全年的停电计划安排轮换工作。 6针对针对运行管理方面采取的预控措施 在运行管理方面,应着重抓好巡视维护及消缺两项工作。巡视维护方面应针对不同的天气、季节特点,每月度制定巡视计划,落实责任人,确保巡视到位。巡查发现的缺陷或隐患应设专人进行分析归类,按先急后缓、是否需要停电等的条件制定计划,落实消缺工作。同时应根据单位实际清况,建立健全考核激励机制,对每条线路应独立建立档案,分线分杆进行登记,将线路运行情况、巡查记录、设备缺陷、危险点、特殊区域或地段、消缺等全面录入生产系统,作为月度绩效考核的主要依据。 2 一起配电网故障的案例分析 配电网运行管理人员,应对管理制度的执行方面,加强对典型配电故障对分析,提出改进的措施。下面一起配网断路器渗水的设备故障进行分析,并提出相关措施及事件启示。

Volte丢包率优化案例

Volte丢包率优化方案 一、概述 随着市场推广,移动VOLTE用户逐步增多,Volte丢包率对用户语音质量影响较大,为提升用户感知,现针对VOLTE上下行丢包进行优化,提升用户满意度。 二、Volte丢包率优化思路 1、影响Volte丢包率的因素 用户对语音质量的感知直接受语音编码、丢包、时延以及抖动影响。 语音编码:高速率编码消耗带宽大,低速率编码影响语音质量 丢包:数据包丢失,会显著地影响语音质量 时延:时延会带来语音变形和会话中断 抖动:效果类似丢包,某些字词听不清楚 2、Volte语音通话协议栈和接口映射 从协议上看,一个Volte语音通话的参与网元主要有:UE、eNB、SGW、IMS,既有RAN侧网元,又有传统EPC侧网元,还有IMS侧网元。其中在无线测我们需要重点关注的网元是UE和eNB以及UE 和eNB之间的Uu接口。即主要涉及的协议是PHY、MAC、RLC、PDCP。需要注意的是,IMS侧的控制面协议,在EPC是以用户面数据形式进行传输的,在IMS侧才会被拆分成控制面和用户面。 Volte语音通话涉及的协议图:

当前网络结构图: 三、Volte丢包率优化目标 梳理Volte语音通话中各设备的问题表现及对应的影响因素,即可明确无线优化手段:参数优化,覆盖优化,干扰优化,移动性能优化,邻区优化,容量优化,功能优化。

RLC 层参数优化 输承 载 传 序 大时延、抖动,丢包、乱 参数配置,容量或能力限制,传输 质量问题 1、Volte 丢包率参数优化 PDCP 层参数优化 PDCP 是对分组数据汇聚协议的一个简称。它是 UMTS 中的一个无线传输协议栈,它负责将 IP 头压 缩和解压、传输用户数据并维护为无损的无线网络服务子系统(SRNS )设置的无线承载的序列号。 涉及参数:pdb 、pdboffset 、aqmmode 、 UlPdcpSduTimerDiscardEnabled 涉及的功能:TcpOptimization 参数优化原理:通过修改相关参数,延长或缩短 PDCP 层的丢包定时器,从而控制丢包 具体步骤如 下 参数优化建议: RLC UM 接收实体设置了一个 RLC PDC 重新排列的定时器,当检测到有收到 PDU 时启动定时器,

【干货】典型网络故障案例及处理思路

【干货】典型网络故障案例及处理思路 很多朋友经常提到网络故障,其中在交换机组网时常见的故障比较多。为了便于大家排除这些故障,在此介绍一些常见的典型故障案例及处理思路。 故障1:交换机刚加电时网络无法通信 故障现象 交换机刚刚开启的时候无法连接至其他网络,需要等待一段时间才可以。另外,需要使用一段时间之后,访问其他计算机的速度才快,如果有一段时间不使用网络,再访问的时候速度又会慢下来。 故障分析 由于这台交换机是一台可网管交换机,为了避免网络中存在拓扑环,从而导致网络瘫痪,可网管交换机在默认情况下都启用生成树协议。这样即使网络中存在环路,也会只保留一条路径,而自动切断其他链路。所以,当交换机在加电启动的时候,各端口需要依次进入监听、学习和转发状态,这个过程大约需要3~5分钟时间。

如果需要迅速启动交换机,可以在直接连接到计算机的端口上启动“PortFast”,使得该端口立即并且永久转换至转发状态,这样设备可以立即连接到网络,避免端口由监听和学习状态向转发状态过渡而必须的等待时间。 故障解决 如果需要在交换机加电之后迅速实现数据转发,可以禁用扩展树协议,或者将端口设置为PortFast模式。不过需要注意的是,这两种方法虽然省略了端口检测过程,但是一旦网络设备之间产生拓扑环,将导致网络通信瘫痪。 故障2:5口交换机只能使用4口 故障现象 办公室中有4台计算机,但是只有一个信息插座,于是配置了一台5口(其中一口为UpLink端口)交换机。原以为4台计算机刚好与4个接口连接,1个UpLink端口用于连接到局域网,但是接入到网络之后,与UpLink端口相邻的1号口无法正常使用。 故障分析 UpLink 端口不能被看作是一个单独的端口,这是因为它与相邻端口其实就是一个端口,只是适用的连接对象不同而已。借助UpLink端口,集线设备可以使

TD-LTE网络优化经典案例汇编

1概述 (1) 2D频段优化案例 (1) 2.1重叠覆盖优化 (1) 2.2PCI优化 (4) 2.3邻区列表优化 (7) 2.4切换优化 (9) 2.4.1切换参数优化 (9) 2.4.2同步参数与切换 (12) 2.5功控参数优化 (16) 2.6天面问题整改 (18) 2.6.1天线抱杆 (18) 2.6.2楼层阻挡 (20) 2.7干扰问题排查 (23) 3F频段优化案例 (25) i

ii

1概述 TD-LTE无线网络要实现系统的高性能指标, 需要有合理的网络规划设计、稳定的产品性能、良好的施工工艺以及高质量的网络优化,几者缺一不可。本报告收录了XX市TD-LTE试验网建网以来遇到的一些典型优化案例,旨在为后续优化工作提供帮助和参考。 2D频段优化案例 2.1重叠覆盖优化 【问题描述】 在华兴街靠近中和路区域测试时,UE驻留在华安证券_3(频点:38050,PCI:88),RSRP: -71dBm左右,SINR:25dB左右,但DL Throughput=31Mbps。 1

【问题分析】 分析路测数据,发现在华兴街靠近中和路的区域,华安证券_2、华安证券_3小区RSRP电平值较接近,如上图所示,对该路段形成了重叠覆盖。而该区域规划的主覆盖小区为华安证券_3,现场勘察发现,华安证券_2信号经周边楼宇反射至该区域,2、3小区形成重叠覆盖,造成吞吐速率降低。 【解决措施】 调整华安证券_2方位角由120°调至155°,机械下倾角由12°调至6°。 【处理效果】 调整小区方位角后,重叠覆盖问题得到较好解决,下载速率明显提升。 小区名称方位角PCI RSRP SINR 下载速率(Mbps) 华安证券3 调整前88 -71.1 25.9 31.5 2

案例-关于VoLTE丢包率高优化处理最佳实践总结

VOLTE关于丢包率高优化处理总结 一、问题描述 上下行语音丢包率是是表征VoLTE业务的一个重要指标,与时延,抖动是影响VOLTE 语音质量的三大因素之一。监控,优化,提升上下行语音丢包率可以辅助VOLTE用户语音感知质量的提升。 PDCP层丢包对语音感知影响 VOLTE业务与GU业务不同,LTE走PS域,通过不同QCI承载来进行QoS保障,影响其VOLTE语音质量的关键指标为丢包,时延,抖动,其中丢包对MOS值基本是线性分布,一般丢包率在1%以内,MOS分都比较好;一旦丢包率大于1%后,MOS分明显下降,语音质量将会受到影响。 提取指标发现LF_H_YY余舜宇集团voLTE语音下行丢包率高达5.27%,voLTE语音上行丢包率6.24%,严重影响网络指标。

二、问题分析 丢包率定义和影响因素指标定义: VOLTE语音包关联指标分析

举例如下:若出现PUSCH MCS0阶占比和PDSCH MCS0阶占比同时恶化,弱覆盖导致的可能性较大。 ?根据关键指标关联,分析用户数问题 根据如下话统信息,判断终端所处小区的负载情况,判断是否小区语音负载大,导致不能及时调度用户,带来PDCP层丢包;

?空口丢包原理 上行空口丢包统计原理: 主要影响因素:上行调度不及时,如图中的1,会导致UE PDCP层的丢弃定时器超时,但现网值是集团规范值,不存在该问题。空口传输质量差,如图中2,MAC层多次传输错误导致丢包。

?上行空口丢包统计原理: 主要影响因素:下行丢包基本上是用户处于小区弱覆盖区域。?常见PDCP层丢包原因总结 ?常见PDCP层丢包处理总体思路

典型网络故障总结

典型网络故障总结 网络故障的一般分类 网络故障一般分为两大类:连通性问题和性能问题。它们各自故障排除的关注点如下: ?连通性问题 硬件、系统、电源、媒介故障 配置错误 不正确的相互作用 ?性能问题 网络拥塞 到目的地不是最佳路由 转发异常 路由环路 网络错误 一般网络故障的解决步骤 故障排除系统化是合理地一步一步找出故障原因并解决的总体原则。它的基本思想是系统地将由故障可能的原因所构成的一个大集合缩减(或隔离)成几个小的子集,从而使问题的复杂度迅速下降。 故障排除时有序的思路有助于解决所遇到的任何困难,下图给出了一般网络故障解决的处理流程。 网络故障排除基本步骤 我们以一个故障排除的实例来学习如何应用这些步骤。

案例:某用户网段广播包过多造成该网段的服务器FTP业务传输速度变慢 组网图如下: 某校园网的三个局域网,其中10.11.56.0为一个用户网段,10.11.56.118为一个日志服务器;10.15.0.0是一个集中了很多应用服务器的网段。 用户网段广播包过多造成该网段的服务器FTP业务传输速度慢 1. 故障现象描述 要想对网络故障做出准确的分析,首先应该了解故障表现出来的各种现象,然后才能确定可能产生这些现象的故障根源或症结。因此,对网络故障做出完整、清晰的描述是重要的一步。 如上述案例,用户反映:“日志服务器与备份服务器间备份发生问题。”这就是一个不完整不清晰的故障现象描述。因为这个描述没有讲述清楚下列问题: ●这个问题是连续出现,还是间断出现的? ●是完全不能备份,还是备份的速度慢(即性能下降)? ●哪个或哪些局域网服务器受到影响,地址是什么? 正确的故障现象描述是: 在网络的高峰期,日志服务器10.11.56.11到集中备份服务器10.15.254.253之间进行备份时,FTP传输速度很慢,大约只有0.6Mbps。 2. 故障案例相关信息收集 本步骤是搜集有助于查找故障原因的更详细的信息。主要是三种途径: ●向受影响的用户、网络人员或其他关键人员提出问题; ●根据故障描述性质,使用各种工具搜集情况,如网络管理系统、协议分析仪、相关show命令等; ●测试性能与网络基线进行比较。 如上述案例,可以向用户提问或自行收集下列相关信息: ●网络结构或配置是否最近修改过,即问题出现是否与网络变化有关? ●是否有用户访问受影响的服务器时没有问题? ●在非高峰期日志服务器和备份服务器间FTP传输速度是多少? 通过该步骤,可以收集到了下面一些相关信息: ●最近10.11.56.0网段的客户机不断在增加; ●129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps,与日志服务器间进行FTP传输时速度慢,只有0.6Mbps;

经典案例_VoLTE上行丢包率优化思路研究

VOLTE上行丢包率优化思路研究

目录 1问题分析 (1) 1.1V oLTE网管丢包率指标定义 (1) 1.2上行丢包原理 (2) 1.3丢包优化流程与思路 (3) 2分场景优化 (5) 2.1弱覆盖场景 (5) 2.1.1VOLTE上行覆盖增强 (5) 2.1.2天馈调整及功率优化 (7) 2.2大话务场景 (7) 2.2.1PDCCH CCE初始比例优化 (7) 2.2.2ROHC功能开启 (9) 2.3上行干扰场景 (11) 2.3.1基于干扰的动态功控 (11) 2.4频繁切换场景 (13) 2.5其他功能及参数优化 (15) 2.5.1PDCP层参数优化 (15) 2.5.2RLC重排序定时器 (16) 2.5.3包聚合关闭 (16) 3总结 (19)

【摘要】随着VOLTE业务的快速普及,VOLTE用户数和业务量都进入了快速上涨期,用户对语音质量要求越来越高,单通、吞字、双不通等严重影响用户感知,制约着4G业务的发展。其中“空口丢包”和“基站丢包”指标可有效表征VOLTE 语音感知,减少“空口丢包”和“基站丢包”是VOLTE语音质量优化提升的重要方向。本文将对V olte上行QCI1丢包率优化展开全面论述。 【关键词】VOLTE全面商用、QCI1上行丢包率、语音质量 1问题分析 1.1VoLTE网管丢包率指标定义

1.2上行丢包原理 VOLTE高清语音编码速率为23.85kbps,终端每20ms生成一个VOLTE语音包(使用RTP实时流媒体协议传输),再加上UDP包头、IP包头、最终打包成IP 包进行传输。在无线空口,按照协议IP包进一步被转换成PDCP包,PDCP包就是空口传输的有效数据,PDCP包在终端和基站间传输异常会导致应用层RTP包的丢失,从而引起语音感知差。 eNodeB的PDCP层接收语音包时如果检测到语音包的SN号不连续,则认为出现丢包。 上行丢包主要原因: 1)大TA/PHR受限、SR漏检、DCI漏检、RLC分段过多、上行调度不及时(上 图① )会导致UE PDCP层丢弃定时器超时丢包; 2)空口传输质量(上图② )差,MAC层多次传输错误后,失败导致丢包;

地市级10kV配网典型故障处理案例分析

地市级10kV配网典型故障处理案例分析 摘要:本文着重分析了10kV配网运行中两点同相接地、两点不同相接地、疑似单相接地等特殊故障现象,并提出正确迅速的处理方法,确保配网安全运行。 关键词:配网运行;典型故障;处理方法 一、漯河电网配网故障分析的意义 漯河配网规模越来越大,配网故障也日趋复杂,对配网的安全可靠运行要求越来越高。漯河地区10kV电网正常运行方式为中性点不接地系统。10kV单相接地故障是漯河配网的各类故障中发生几率最高的一种,单相接地故障(不包括瞬间及间隙性接地)占比80%以上。现对配网典型故障进行分析,总结规律,从而作出正确迅速处理,确保电网安全稳定运行,同时作为经验学习材料供新进学员学习。 二、10kV小电流接地系统的判断 如何判断小电流接地系统的各种故障。中性点不接地电网发生单相接地短路的现象是:故障相电压降低为零,其他两相电压升高或上升为线电压,其接地相的判别方法为: 1、如果一相电压指示为零,另两相为线电压,则为零的相即为接地相; 2、如果一相电压指示较低,另两相较高,则较低的相即为接地相; 3、如果一相电压接近线电压,另两相电压相等且这两相电压较低时,判别原则是“电压高,下相糟”,即按A\B\C相序,哪一相电压高,则其下相即可能为接地相。 各种单相接地短路的特征 故障类型各相对地电压特点故障相判别 单相完全接地一相电压为零,两相升高为线电压电压为零的相为接地相 单相不完全接地一相电压降低但不到零,两相升高但不相等,其中一相可略超过线电压电压降低相为接地相 单相断线一相电压升高,不超过 1.5Ue,两相电压降低且相等,不低于0.866Ue 电压升高相为断线相

LTE网络优化案例

L T E网络优化案例Prepared on 21 November 2021

1LTE优化案例分析 1.1覆盖优化案例 1.1.1弱覆盖 问题描述:测试车辆延长安街由东向西行驶,终端发起业务占用京西大厦1小区(PCI =132)进行业务,测试车辆继续向东行驶,行驶至柳林路口RSRP值降至-90dBm以下,出现弱覆盖区域。 问题分析:观察该路段RSRP值分布发现,柳林路口路段RSRP值分布较差,均值在-90dBm以下,主要由京西大厦1小区(PCI =132)覆盖。观察京西大厦距离该路段约200米,理论上可以对柳林路口进行有效覆盖。 通过实地观察京西大厦站点天馈系统发现,京西大厦1小区天线方位角为120度,主要覆盖长安街柳林路口向南路段。建议调整其天线朝向以对柳林路口路段加强覆盖。 调整建议:京西大厦1小区天线方位角由原120度调整为20度,机械下倾角由原6度调整为5度。 调整结果:调整完成后,柳林路口RSRP值有所改善。具体情况如下图所示。 1.1.2越区覆盖 问题描述:测试车辆延月坛南街由东向西行驶,发起业务后首先占用西城月新大厦3小区(PCI= 122),车辆继续向西行驶,终端切换到西城三里河一区2小区(PCI =115),切换后速率由原30M降低到5M。 问题分析:观察该路段无线环境,速率降低到5M时,占用西城三里河一区2小区(PCI =115)RSRP为-64dBm覆盖良好,SINR值为导致速率下降。观察邻区列表中次服务小区为西城月新大厦3小区(PCI =122)RSRP为-78dBm,同样对该路段有良好覆盖。介于速率下降地点为西城三里河一区站下,西城月新大厦3小区在其站下应具有相对较好的覆盖效果,形成越区覆盖导致SINR环境恶劣,速率下降。 调整建议:为避免西城月新大厦3小区越区覆盖,建议将西城月新大厦3小区方位角由原270度调整至250度,下倾角由原6度调整为10度。 调整后 调整结果:西城三里河一区站下仅有该站内小区信号,并且SINR提升到15以上,无线环境有明显提升。 1.1.3重叠覆盖 问题描述:测试车辆延长安街由西向东行驶,终端占用中华人民共和国科技部2小区(PC=211)进行业务,随后切换至海淀京西大厦1(PC=133)小区,业务正常保持。车辆继续向东行驶,终端又回切至中华人民共和国科技部2小区(PC=211)发生掉话。 问题分析:观察该路段切换过程,终端由中华人民共和国科技部2小区(PC=211)正常切换至海淀京西大厦2小区后又出现回切情况导致掉话。两小区RSRP值相近,相差3dBm以内,造成该路段为无主覆盖路段,发生频繁切换最终导致掉话。 调整建议:针对该路段无主覆盖问题,建议调整京西大厦2小区功率由原15降低为5,使其不会对长安街路段实行有效覆盖。 调整结果:调整后,SINR值有明显改善,保持在20左右,多次测试该路段不会出现频繁切换情况,避免掉话等异常事件发生。

精品案例_干扰导致的高丢包小区

干扰导致的高丢包小区

目录 一、问题描述 (3) 二、分析过程 (3) 三、解决措施 (7) 四、经验总结 (8)

干扰导致的高丢包小区 【摘要】本文分析于处理VoLTE高丢包小区,发现为该小区底噪水平异常升高导致,对该扇区进行干扰扫频分析,发现为用户私装放大器导致。 【关键字】VoLTE高丢包干扰放大器 【业务类别】优化方法 一、问题描述 5月处理VoLTE高丢包小区时,发现该扇区下行空口RTP丢包率(QCI=1)最高达35%,严重影响全网指标和用户使用体验。 图1:MA-市区-东方明珠东北-ZFTA-443809-55小区丢包情况 二、分析过程 对该扇区进行分析,查询该扇区的MR和站间距,该扇区覆盖情况正常,无弱覆盖情况。故对扇区质量进行分析,发现该扇区底噪水平较高,最高达-53dBm。

图2:MA-市区-东方明珠东北-ZFTA-443809-55MR覆盖图 图3:MA-市区-东方明珠东北-ZFTA-443809-55底噪情况

图4:MA-市区-东方明珠东北-ZFTA-443809-55底噪情况 对该问题扇区进行降功率和关断操作,底噪水平无明显变化,将MA-市区-东方明珠东北-ZFTA-443809-55方位角由290度调整到0度后,底噪消失。对周边站点底噪情况进行核查,发现仅仅MA-市区-东方明珠东北-ZFTA-443809-55底噪较高,其他扇区底噪正常。故问题定位为外部干扰导致,初步判断外部干扰如下图所在位置: 图5:初步判断干扰位置 对网管RB噪声水平进行统计,得到干扰波形如下所示,主要干扰前50个RB,尤其对前15个RB最为严重。

相关文档
相关文档 最新文档