拉网测试LOG分析报告1
网络设备日志分析报告
网络设备日志分析报告概述网络设备日志是网络管理中非常重要的一部分，通过对日志的分析可以帮助管理员了解网络设备的状态、检测异常行为以及解决问题。
本报告将介绍如何使用日志分析来提升网络设备管理的效率和安全性。
步骤 1：日志收集网络设备通常会生成大量的日志信息，包括系统日志、访问日志和安全日志等。
首先，需要确保网络设备的日志功能已经开启，并配置正确的日志级别。
日志级别决定了生成日志的详细程度，一般包括调试、信息、警告和错误等级别。
根据实际需求，选择合适的日志级别。
步骤 2：日志存储将网络设备生成的日志信息定期地存储起来非常重要。
可以使用专门的日志管理系统或者将日志导出到外部存储设备中。
存储的方式可以选择使用本地磁盘、远程服务器或者云存储等，根据网络设备的规模和需求来选择合适的存储方案。
步骤 3：日志解析接下来需要对存储的日志进行解析。
日志解析的目的是将原始的日志信息转化为结构化的数据，方便后续的分析和检索。
使用日志解析工具可以帮助自动化这一过程，常见的工具包括ELK（Elasticsearch, Logstash, Kibana）、Splunk等。
根据实际情况选择合适的工具进行日志解析。
步骤 4：日志分析一旦日志解析完成，就可以进行日志分析了。
日志分析可以帮助管理员了解网络设备的运行状况、检测异常行为以及发现潜在的安全问题。
具体的分析方法包括：•事件关联分析：通过分析日志中的事件关系，可以了解事件之间的因果关系，帮助排查问题和定位故障。
•异常行为检测：通过定义正常行为的模式，可以检测到与正常行为不符的异常行为，及时发现潜在的安全问题。
•性能监控：通过分析网络设备的性能日志，可以监控设备的负载情况、网络吞吐量和响应时间等指标，及时进行性能优化和故障排查。
步骤 5：报告生成日志分析的结果需要以报告的形式进行呈现，帮助管理员更好地理解网络设备的状态和问题。
报告应该清晰、简洁，并提供关键的分析结果和建议。
可以使用Markdown等格式来生成报告，方便阅读和分享。
网络设备日志分析报告
网络设备日志分析报告引言网络设备日志是网络运维中重要的信息来源，通过对日志的深度分析可以帮助我们了解网络的运行状况、发现潜在问题和解决网络故障。
本报告将以网络设备日志分析为主题，介绍日志分析的重要性以及常用的分析方法和工具。
日志分析的重要性网络设备日志记录了设备的运行状态、事件和错误信息等关键数据，通过对日志的分析可以帮助我们： 1. 监测网络设备的运行状况，及时发现异常情况； 2. 追踪网络故障的原因，快速定位和解决问题； 3. 支持网络安全事件的调查和溯源； 4. 优化网络设备的配置和性能。
常见的日志分析方法和工具1. 关键字搜索关键字搜索是最简单也是最常用的日志分析方法之一。
通过在日志中搜索关键字，可以快速定位与特定事件或问题相关的日志条目。
例如，我们可以搜索特定的错误代码、IP地址或关键字来查找与网络故障相关的日志记录。
2. 日志过滤日志过滤是一种基于规则的分析方法，通过定义过滤条件来筛选出特定类型的日志。
过滤可以帮助我们排除无关信息，只关注与特定事件或问题相关的日志。
常见的日志过滤条件包括时间范围、日志级别、设备名称等。
3. 日志可视化日志可视化是将日志数据以图表、图形等形式展示的方法。
通过可视化可以更直观地理解和分析日志数据。
常见的日志可视化工具有Elasticsearch、Kibana等。
通过这些工具，我们可以创建仪表盘、图表和地图等，对日志数据进行可视化分析。
4. 机器学习算法机器学习算法在日志分析中也有广泛的应用。
通过对大量的日志数据进行训练和学习，机器学习算法可以自动识别和分类不同类型的日志，帮助我们更高效地分析和处理日志。
常见的机器学习算法有聚类、分类和异常检测等。
日志分析工具的选择选择合适的日志分析工具可以提高分析效率和准确性。
以下是一些常见的日志分析工具： - ELK Stack: ELK是Elasticsearch、Logstash和Kibana的组合，可以用于实时日志分析和可视化。
VoLTE测试未接通问题分析
VoLTE测试未接通问题分析
一、【问题现象】
VoLTE拉网测试时，在洞山中路与淮河大道交叉口占用立交桥-440706_51小区信号，主叫终端起呼后未接通，导致blocked call。
VOLTE未接通信令LOG图
二、【问题分析】
查看立交桥-440706站点无告警，无干扰。
分析流程：
原因分析：
1、从EVENT事件看，主叫起呼之后，占用问题小区多次上报A3事件未发生切换。
2、从message层三信令分析，上报A3不切换后，在9:49:04左右，主叫终端两次掉线重建，RRC 重配之后没有建立专有承载。
3、当前VoLTE通话需要在LTE小区建立默认承载（QCI=5，交互SIP信令）和专有承载（QCI=1，传输语音数据包），查看服务小区报慈浜LF_C当前RSRP -110dBm、SINR -4dB，无线环境较差。
怀疑无线问题导致专有承载无法正常建立。
三、【问题处理】
调整立交桥-440706天线方位角，增加该路段覆盖，并调整PCI，减少MOD3干扰，提升信号质量，调整后，复测正常。
四、【经验总结】
在我们日常的VoLTE语音优化中，除了关注VoLTE新功能开关、相关参数一致性外，传统LTE优化的重叠覆盖、弱覆盖、模三干扰等问题也需要重点关注。
无线环境的好坏关系到VoLTE信令，VoLTE语音数据包能否正常传输，各项承载能否成功建立，对VoLTE呼叫成功率、掉话率有重大影响。
因此，在对网格进行VoLTE测试前，建议提前解决网格内的无线问题点，保证VoLTE测试指标。
RRC连接失败处理案例
从客户角度来说，存在两种情况：1）用户拨打电话会出现不能一次拨打成功的问题。具体表现在：用户拨打电话，手机显示在拨打，手机听筒中无声音，然后8秒钟左右就直接中断，返回拨号的界面，未接通后就中断了，用户需要再次拨打。若用户有拨号之后就将手机放在耳边的习惯，出现这种问题时，用户感知更差。2）用户接听不到部分电话，其他人拨打用户电话会有“您拨打的用户暂时无法接通”的语音提示。
5、检查发现，13222-青山村2区与18412-广大环球2区，同频同扰码(频点:10112；CPI:68)。两站相距2240米左右，且无邻区关系。
图8
至此可以确定在UE侧上发rrcConnectionRequest后，由于青山村2区与UE驻留的广大环球2区是同频同扰，青山村2区在该处存在虚假信号，导致UE根据频点和扰码解析的小区为青山村2区，而不是UE驻留的广大环球2区。RNC侧收到的rrcConnectionRequest信令每次都有2条，且相差为10毫秒级（图7），应该为UE在青山村2区与广大环球2区均上发rrcConnectionRequest，但解析的小区为青山村2区。RNC侧收到UE上发的rrcConnectionRequest并进行解析，在青山村2区下发rrcConnectionSetup，而UE驻留的小区为广大环球2区，导致UE未收到，最终导致未接通。
检查18412-广大环球2区出现问题时段的上行时隙干扰情况，如下图：
图6
从上图可以看出，18412-广大环球2区不存在上行时隙干扰。
4、既然18412-广大环球2区不存在上行时隙干扰，那一般情况下，不存在RNC侧收不到的问题。我们再回过头来，详细的检查CT，看是否有遗漏。
路测LOG分析
路测LOG分析一、实验目的1.了解TD-LTE网络系统的优化方法和流程，路测的目标、路测的方法2.掌握TD-LTE网络优化路测设备连接3.了解如何分析网络覆盖情况，并对覆盖类问题导致失败业务进行分析二、实验原理网络工程建设完毕后，网络按照规划设计在实际中很难达到预期的效果，主要由于物理环境的改变和网络参数设置的不合理，无法直接给用户良好的网络体验。
所以需要网络优化针对于网络部署的实际情况，有针对性的提升网络质量和用户感受。
三、实验内容1.弱覆盖问题描述：拉网测试过中，测试车辆沿宇雷路由南向北行驶至大猷路至囿山路路段时，由于附近没有站点主覆盖该路段，UE先后占用距离较远的D780105莲都城市规划馆F-1（PCI:327）小区与D780048莲都梅山中学F-3（PCI：161）小区，RSRP值维持在-105dBm 以下，弱覆盖。
调整前覆盖图：调整思路：问题路段没有站点覆盖，考虑到附近为密集居民区，建议在问题路段新建站点。
调整方案：在问题路段附近新建站点。
调整结果：已通过移动审核，计划在问题路段新建站点2.覆盖不合理问题描述：拉网测试过中，测试车辆沿括苍南路行驶至小水门大桥路段时，UE先后占用D780345莲都小水门大桥D-2小区（PCI：439）✂D780345莲都小水门大桥D-3（PCI：440）✂D780111莲都小水门大桥F-2小区（PCI：346）✂D780028莲都丽水水南F-3（PCI：26）✂D780111莲都小水门大桥F-2小区（PCI：346）✂D780028莲都丽水水南F-1（PCI：24）✂D780028莲都丽水水南F-3（PCI：26），由于覆盖不合理，造成小区间频繁切换，影响网络指标。
调整前覆盖图：调整思路：该路段由D780345莲都小水门大桥D-2小区（PCI：439）、D780028莲都丽水水南F-3小区（PCI：26）覆盖较合理，建议调整D780345莲都小水门大桥D-3小区方位角及机械下倾角，控制其旁瓣覆盖，调整D780345莲都小水门大桥D-2小区方位角，加强其在该路段的覆盖，调整D780028莲都丽水水南F-3小区（PCI：26）方位角，加强其在该路段的覆盖。
【切换专题】MR不处理总结文档v1
1 MR不处理问题总体分析对5月20日拉网log进行分析，共有1295次MR上报，发生了690次切换尝试。
经过逐一分析，共有617次MR没有经过处理。
（注：从终端log中，有多次切换尝试没有对应的A3测量事件，原因为Log中有A3事件的MR上报，但没Assistant没有统计进来，或发生在log的开头位置等，本文不进行分析）。
即有47.5%的MR没有被处理。
MR不处理的总体原因分布如图：说明：配置问题：专指由于网络没有配置邻区，或者有重复PCI，导致MR不处理的情况。
发生重建：多次上报MR（一般大于三次）后，网络没有响应，随后发生RRC连接重建立的情况。
缺少日志：由于终端log是在5月20日拉网得到，没有网络侧log，并且由于时间久远，eNB 上DBG日志已经被冲掉，并且网络配置也有可能被更改过，造成目前无法定位。
未明确：从现在终端log中，难以准确定位出问题所在。
下行失步：指由于终端连续一段时间收不到有效信号后，造成掉线或者RRC连接重建立。
正常周期上报：现行网络除了配置A3事件上报外，还配置了周期上报的测量，上报内容为最强邻区。
在RRC连接重配中可以看到，此测量ID不用于A3事件的测量ID。
此时上报的MR不是A3事件，故网络不进行切换。
流程嵌套：在上一次切换重配还没有完成，专用资源还没有重配完毕时又发生MR上报情况，或者已经下发切换的RRC连接重配，但尚未发送RRC连接重配完成消息时，又有MR上报给原小区。
丢失：专指终端上报2~3次相同内容的MR，但往往最后一个会被处理，前一个或第二个没有被处理2 具体分析2.1 配置问题2.1.1现象以2:06:36发生的8次MR没有响应为例。
终端服务小区为三台山2，每隔200ms上报一次A3事件的MR，前8次上报的邻区PCI都为144，为苏堤南口2小区。
最后的MR中RSRP比服务小区RSRP高7dB。
而最后一次MR中，增加了一个邻区，PCI为145，RSRP比服务小区高5dB仅接着，网络下方了向PCI为145小区切换到的重配命令。
织金县城ATU拉网测试报告.(20141124)
织金县城语音DT测试分析报告2014-11-24概述：为了解织金县城区网络覆盖情况，今日对织金县城区进行了DT语音拉网测试，其中覆盖率为99.97%，接通率为96.43%，掉话率为0.00%，织金县城区全路段测试中发现，在中康医院附近路段，因干扰导致主叫MS出现一次未接通；在师范至火车站路段，因干扰导致MS出现5-7级质差。
详细看下面指标分析：一、测试KPI指标：测试地点集团KPI呈现网格常规统计指标全程呼叫成功率(%)接通率(%)掉话率(%)RxQuality质量0-5GSM语音质量2013覆盖率1800M占比（%）MOS均值车速(KM)织金县城96.43 96.43 0.00 98.34 96.75 99.97 59.36 3.89 12.2 汇总96.43 96.43 0.00 98.34 96.75 99.97 59.36 3.89 12.2二、织金县城测试Rxlev、Rxquality、MOS覆盖图➢织金县城Rxlev覆盖图Rxquality覆盖图MOS覆盖图三、事件列表问题路段事件问题分析解决方案众康医院附近路段未接通测试车辆行驶至织金众康医院附近路段时，MS占用越区小区7ZJ_火车站_bts1（LAC：34302 CI：7371）进行通话，其中RxLev平均在-71dBm左右，此时出现未接通。
信令跟踪查看，此时已经分配TCH，接着主叫MS一直上传测量报告，却没有收到回复，通过MaPInfo查看得知，本小区收到邻区干扰严重，造成载干比很低，C/I=3.24dB，干扰导造成出现连续7级质差，最终导致主叫MS未接通1、降低7ZJ_火车站_bts1小区下倾角2、将7ZJ_火车站_bts1小区的第57号频点改为18号频点四、问题分析1、众康医院附近路段出现未接通问题分析：测试车辆行驶至织金众康医院附近路段时，MS占用越区小区7ZJ_火车站及邻区干扰图（图2）：（图1）（图2）问题分析：测试车辆从织金师范行驶至火车站路段时，MS占用7ZJ_火车站拉远_bts1（LAC：34,302 CI：26,541）进行通话，其中RxLev平均在-75dBm左右，出现5-7级质差，通过MaPInfo查看得知，本小区受到邻区干扰严重，干扰致使载干比很低，C/I=4.06dB，最终干扰导致出现连续5-7级质差。
TDSCDMA网络温州TD网络鹿城拉网问题点
一测试概况2020年8月13、14号我方对鹿城区做了一次较为全面细致的拉网测试，这次拉网测试业务类型为CS 的AMR语音业务，要紧关注的指标为掉话率和起呼成功率。
鹿城城区高楼较多，信号衰减大，十字路口信号比较复杂，拐角效应较为明显。
由于这次拉网的线路较为密集，一些隐藏的问题也暴露出来了。
要紧问题仍是起呼失败和掉话问题点较多，在2/3G互操作方面，TD网缺少G网邻区关系，致使切换失败。
在分析拉网log的基础上，结合实际情形，给出了一些解决问题的可行的建议和方式。
二问题点的分析和解决方案1 起呼失败问题UE在东瓯大桥未接通现象描述：主叫UE由南往北行驶，在东瓯大桥北部路段，占用GSM小区（BCCH:22，BSIC:4,CellID：11601），进行起呼，在起呼进程中，被叫UE刚由GSM重选回到TD-SCDMA，在被叫UE呼唤成立进程中，进行位置区更新，致使该次未接通事件。
图1图2图3告警信息：无问题分析：主叫UE由南往北行驶，在东瓯大桥北部路段，占用GSM小区（BCCH:22，BSIC:4,CellID：11601），进行起呼，在起呼进程中，被叫UE刚由GSM重选回到TD-SCDMA，在被叫UE呼唤成立进程中，进行位置区更新，致使该次未接通事件。
由上图2可见被叫UE所占用GSM小区（BCCH:51，BSIC:70,CellID：30097）并非该路段主覆盖GSM小区，该路段主覆盖GSM小区应为GSM小区（BCCH:22，BSIC:4,CellID：11601），因此建议添加GSM小区（BCCH:22，BSIC:4,CellID：11601）作为TD江心西屿-3（10088，6）小区的GSM邻区，增加TD江心西屿-3（10088，6）小区在该路段的23G互操作成功率。
另外由上图2可知，该路段TD信号较差，PCCPCH RSCP在-100dbm左右，这也是致使该次未接通事件的要紧缘故之一，而该路段TD-SCDMA信号太差，不该该由GSM重选至TD-SCDMA，因此建议将GSM小区（BCCH:51，BSIC:70,CellID：30097）至TD-SCDMA的重选门限，修改至-88dbm左右，即当TD-SCDMA信号强度在-88dbm时，才由GSM重选至TD-SCDMA，该项修改可通过修改TDD_QOFFSET进行（若是TDD_QOFFSET采纳绝对值门限，那么还需修改该路段的GSM主覆盖小区）。
L800M上下行同时测试上行速率低问题处理案例分析
河北电信保定L800M下行测试影响上行测试速率低问题处理目录1案例标签 (1)2问题描述 (1)3问题分析 (3)3.1.1QCI验证 (3)3.1.2MTS跟踪定位 (4)4处理方式 (5)5处理结果 (6)6小结 (8)1案例标签上下行同时测试、上行速率接近0、CCE聚合度2问题描述保定区域L800M站点建设已基本完成，市区L800M全部为3M带宽，有部分县城农村为5M带宽，保定与其他地市的边界处为1.4M带宽，在对市区L800M站点拉网验证时发现一台825C终端做FTP上传时，均值速率达6.08Mbps，如图-1所示。
但是当两台825C终端连接2台电脑分别在该小区的近点同时做上传和下载FTP测试，那么上传速率下降，上传速率不到1M，只有几百kbps，如果下载FTP停止，上传速率马上恢复正常，均值有6.04Mbps。
图-1以下为2台825C终端A和B同时做上下行FTP业务时的上下行均值速率情况：如图-2所示，A终端825C在FTP下载时下行速率均值为15.7Mbps：图-2如图-3所示，B终端825C在FTP上传时上行速率均值只有931.3kbps：图-33问题分析3.1.1QCI验证排除2个终端的QCI是否一样，经排查2个终端的QCI值都为9，排除该可能。
A终端detach和attach后，查询QCI值为9，如下图-4:图-4B终端detach和attach后，查询QCI值也为9，如下图-5:图-53.1.2MTS跟踪定位前台2台825C终端进行上下行测试，并进行MTS跟踪，首先由A终端先做FTP上传测试2分钟，然后B终端再做FTP下载，2台终端同时进行。
从MTS跟踪情况来看，前面2分钟，终端A单独做FTP上传测试的时候，均值有6.08Mbps，在终端B开始做FTP下载时，此时终端A的上行速率从原来的6.08Mbps下降到几百k的速率，而终端B的下行速率有15.7Mbps。
上行速率差的原因主要为是RB资源不足，调度次数也相对较少。
拉网排查情况汇报
拉网排查情况汇报尊敬的领导：根据上级要求，我对公司网络安全进行了一次拉网排查，并就此情况做出了汇报。
在此次排查中，我们主要对公司内部网络进行了全面的检查，以确保网络安全和数据保护工作的有效开展。
首先，我们对公司内部网络设备进行了全面的检查和排查。
通过检查发现，大部分网络设备运行正常，但也发现了部分设备存在安全隐患，如未及时更新补丁、密码设置过于简单等问题。
针对这些问题，我们已经立即采取了相应的措施，加强了设备的安全防护，确保网络设备的正常运行和安全性。
其次，我们对公司内部网络进行了全面的漏洞扫描和排查。
通过漏洞扫描，我们发现了部分系统存在漏洞和安全隐患，如未及时更新补丁、未加强访问控制等问题。
针对这些问题，我们已经立即进行了漏洞修复和安全加固，确保系统的安全性和稳定性。
另外，我们还对公司内部网络进行了全面的安全监控和日志审计。
通过安全监控和日志审计，我们发现了部分异常行为和安全事件，如未经授权的访问、异常登录行为等问题。
针对这些问题，我们已经立即采取了相应的处置措施，加强了网络安全防护，确保网络的安全和稳定。
总的来说，通过此次拉网排查，我们发现了一些网络安全隐患和问题，并已经采取了相应的措施加以解决。
但也要看到，网络安全工作是一项系统工程，需要我们不断加强和完善。
下一步，我们将进一步加强网络安全宣传教育，提高员工的安全意识；加强网络安全技术研发和应用，不断提升网络安全防护能力；加强网络安全监控和应急响应，及时发现和处置安全事件。
相信在公司领导的关心支持下，我们一定能够做好网络安全工作，确保公司网络安全和数据保护工作的有效开展。
此次排查情况的汇报到此结束，如有不足之处，还请领导批评指正。
感谢领导对我们工作的关心和支持！此致。
敬礼。
log数据研究报告
log数据研究报告1. 引言本报告旨在研究和分析log数据，以深入了解系统的运行情况，从而为系统的优化和问题排查提供数据支持。
log数据是通过记录系统运行过程中的事件和状态而生成的日志文件，其中包含了系统运行的各种信息。
通过分析log数据，我们可以发现系统中的异常行为、性能瓶颈以及潜在的问题。
2. 数据采集log数据的采集是研究的第一步。
根据研究目标和系统特点，我们需要选择适合的数据采集工具和方法，并设计合理的采集方案。
常见的log数据采集方法包括但不限于：•日志记录器：在系统的关键代码段中插入记录器，用于在发生关键事件时生成日志条目。
•事件触发器：根据系统定义的事件规则，当特定事件发生时自动生成日志条目。
•摄像头图像分析：在视频监控系统中，通过分析摄像头图像中的运动和特定目标的出现次数来生成日志数据。
•性能监控工具：使用性能监控工具来记录系统在不同负载下的性能指标，例如响应时间、CPU利用率和内存使用等。
3. 数据存储与处理log数据的存储和处理是研究的关键环节。
我们需要选择合适的存储方式和处理工具来高效地存储和分析大量的log数据。
常用的存储方式包括：•数据库：使用关系型数据库或非关系型数据库存储log数据，便于索引和查询。
•分布式文件系统：通过分布式文件系统来存储log数据，可以实现高容量和高可扩展性。
•日志集中化平台：使用日志集中化平台来统一管理和存储log数据，方便查询和分析。
log数据的处理通常包括以下几个步骤：•数据清洗：去除不需要的字段和异常数据，保留有效的数据。
•数据转换：对数据进行转换和标准化，以便后续的分析和计算。
•数据聚合：根据需求将数据进行聚合，生成汇总信息和统计报告。
4. 数据分析与可视化log数据分析主要包括对数据的统计、挖掘和建模，以从中发现有价值的信息和模式。
常用的log数据分析方法包括：•统计分析：对log数据的关键指标进行统计分析，例如事件发生次数、响应时间分布和异常占比等。
案例-VoLTE未接通分析优化处理
VoLTE未接通分析优化处理【摘要】：8月份省公司组织VoLTE对标拉网测试，在进行LOG分析时，发现一部分未接通是由于在切换过程中发起了业务起呼，最终造成语音未接通。
分析得出主要因为切换和语音建立冲突，造成VoLTE的QCI=1的承载异常释放造成，通过调整呼叫过程中切换延时定时器解决此问题。
【关键字】切换承载释放【故障现象】：8月份省公司组织进行VoLTE拉网测试，分析LOG时发现很多未接通发生在切换过程中，如下图。
图1：主叫未接通截图【原因分析】：对LOG进行分析处理，发现主叫于11:21:22.901发起起呼。
图2：主叫起呼然后在11:21:23.103承载建立成功。
图3：承载建立完成最终在在一次切换后上报未接通事件，同时反馈SIP 503信令，被叫反馈SIP 580信令。
图4：主叫未接通上报SIP 503 图5：被叫上报SIP 580查询资料得知在VoLTE未接通发生事件中，存在切换和建立冲突导致的未接通，主要原因有2个：1、主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，导致专载被释放，终端回复invite580，呼叫未接通，具体原因如下：终端建立专载成功，回复重配完成并上发NAS确认消息，但基站CTS信令显示NAS消息没有收到，造成切换中MME发给目标小区的HandoverRequest消息里面e_RABToBeSetupListHOReq少了QCI1的承载，所以Release QCI1的承载。
2、主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，导致专载被释放，终端回复invite580，呼叫未接通，具体原因如下：终端建立专载成功，回复重配完成并上发NAS确认消息，基站CTS信令显示NAS已收到并上发给MME，但由于切换流程在前，MME收到NAS消息之前，MME已经发给目标小区的HandoverRequest消息，里面e_RABToBeSetupListHOReq少了QCI1的承载，所以Release QCI1的承载。
网络设备日志分析报告
网络设备日志分析报告1. 引言网络设备的日志是网络运维人员进行故障排除和性能优化的重要依据。
通过对网络设备日志的分析，我们可以及时发现潜在的故障点，并采取相应的措施进行修复，从而保证网络的稳定性和可靠性。
本文将介绍如何对网络设备日志进行分析，并提供一些常用的分析方法和工具。
2. 收集日志首先，我们需要从网络设备上收集日志。
通常，网络设备会将日志保存在本地或者通过Syslog等协议发送到远程服务器。
我们可以通过Telnet、SSH等方式登录到网络设备，并使用命令行工具将日志保存为文本文件。
3. 日志格式分析网络设备的日志格式各不相同，因此在进行分析之前，我们需要了解日志的格式和字段含义。
通常，网络设备的日志包含时间戳、日志级别、设备名称、日志内容等字段。
我们可以使用正则表达式等工具，对日志进行解析和提取。
4. 日志过滤与过滤规则在分析大量的日志数据时，为了提高效率，我们可以根据具体需求制定过滤规则，只分析关注的日志。
例如，我们可以根据日志级别过滤出仅包含错误和警告信息的日志。
同时，我们也可以根据关键词过滤出特定类型的日志，如网络连接失败、设备重启等。
5. 日志统计与可视化对于大规模的日志数据，我们可以通过统计和可视化的方式，更好地理解和分析数据。
例如，我们可以统计每个设备的日志数量，以及各个日志级别的分布情况。
同时，我们可以使用折线图、柱状图等图表，直观地展示日志的趋势和变化。
6. 异常检测与故障排除通过对网络设备日志的分析，我们可以发现潜在的异常情况和故障点。
例如，我们可以通过分析网络连接失败的日志，找到网络故障的原因，并采取相应的措施进行修复。
同时，我们还可以通过对设备重启日志的分析，找到设备稳定性的问题，并进行相应的优化。
7. 日志存档与备份为了方便后续的分析和查询，我们可以将日志进行存档和备份。
通常，我们可以将日志按照时间进行归档，并设置适当的保留期限。
同时，我们还可以定期将日志备份到远程服务器或云存储，以防止日志的丢失和损坏。
LTE-覆盖率好但下行速率优良比不达标问题分析报告
覆盖率好但下行速率优良比不达标问题分析上海电信无线网络优化中心1.问题描述在对某些簇进行拉网测试后，发现部分簇存在覆盖率好但是下行速率优良比不达标的情况。
覆盖率：RSRP≥-105&SINR≥-3的采样点/总采样点下行速率优良比：下行速率大于12M的比例。
以A簇为例，测试指标见下表，该簇的RSRP均值达到-87.79，覆盖率为96.53%，属于较好水平。
但是速率优良比为76.93，处于很差水平。
2.问题分析对于覆盖率好但速率优良比的问题，由于RSRP和覆盖率都处于较好的水平，因此首先需要查看SINR的水平。
第一种情况：SINR处于较好水平，则有可能是调度效率低引起的。
这种情况目前多数是由于用户多引起的。
第二种情况：SINR处于较差水平，则速率优良比较差是由于SINR低引起的。
这种情况是我们分析的重点。
对于第二种情况，覆盖好，SINR差，速率优良比低。
需要这种情况下找出SINR低的原因，从而提升速率优良比。
在这种情况下，主要有以下几类原因会引起SINR低。
(1)邻区漏配。
由于邻区漏配，导致无法切换，从而导致SINR低。
(2)切换参数配置错误。
导致无法切换，从而导致SINR低。
(3)天线越区覆盖。
天线越区可能引起邻小区RSRP较大，“主服小区”信号强度与“邻小区信号强度差值”RSRPDelta较小。
从而导致SINR低。
(4)存在模3干扰问题，导致覆盖好，SINR低。
下文将对这几种情况举例说明。
3. 案例描述3.1邻区漏配导致速率优良比低案例（1）问题现象在拉网测试的过程中，发现某路段RSRP 处于较好的水平，但是存在下行PDCP 层速率很低，低于10Mbps 。
（如下图粉色圆圈处）。
且现SINR 较差的情况。
如下图：（2）问题分析进一步分析，查看log 发现信号占用卢重庆_6（PCI 59）往卢雪豹_1（PCI 216），卢雪豹_2（PCI 217）的时候，卢雪豹_1（PCI 216），卢雪豹_2（PCI 217）的RSRP 比卢重庆_6（PCI 59）的RSRP 大很多（14dBm ）的时候，虽然UE 上报Measurement Report 消息，但是没有收到RRC Connection Reconfiguration 消息，导致无法切换。
10.3拉网测试报告撰写[24页]
![10.3拉网测试报告撰写[24页]](https://img.taocdn.com/s3/m/b4a6cf54f78a6529647d53b8.png)
指标要求
指标
室外>-110dBm
99.42%
室外>-3dB
97.06%
请求11次，接入成功10次
90.91%
RRC 建立成功率*ERAB建立成功率 95.45%
请求18次，接入成功18次
100.00%
（1）拉网 RSRP 覆盖情况....................................................................................................4 （2）拉网 SINR 覆盖情况.....................................................................................................5 （3）PDCP DL Throughput （视实际拉网 FTP 要求项输出）..........................................6 （4）PDCP UP Throughput（视实际拉网 FTP 要求项输出）.............................................7 （5）网络 KPI 分析 ................................................................................................................7
①短呼 KPI 统计...............................................................................................................8 ②长呼 KPI 统计 ..............................................................................................................8 3.拉网问题点分析............................................................................................................................9 （1）拉网问题区域分布.........................................................................................................9 （2）拉网问题点列表.............................................................................................................9 （3）问题点分析.....................................................................................................................9 ①沙园路切换异常事件...................................................................................................9 4.遗留问题与求助..........................................................................................................................12 5.优化调整记录..............................................................................................................................12
江苏移动南通分公司启东乡镇拉网测试报告-20100621
江苏移动南通分公司启东市拉网测试报告江苏建工局网络优化小组2011-06-21目录1启东市DT测试 (2)1.1测试概况 (2)1.2测试条件 (2)1.3测试指标统计 (3)1.4启东市乡镇网络覆盖情况 (3)2问题分析 (4)2.1启东塘坊_A小区越区覆盖 (4)2.2D大江中学_A小区天馈接反 (5)2.3茅家港_A小区天线方位角问题 (6)2.4边防村_C小区越区覆盖 (6)2.5启东塘坊_C小区越区覆盖导致掉话 (7)3拉网测试小结 (8)1 启东市DT测试1.1 测试概况2011年6月21日对启东市乡镇间道路进行移动语音DT测试，测试范围：南通市乡镇间主要交通干道。
南通市测试里程大约400余公里，测试时间18小时左右，经过此次语音DT测试，对启东市网络情况进行摸底。
本次测试结果覆盖率为99.20%，语音质量为96.21%。
1.2 测试条件测试软件：TEMS8.0.3测试设备：索爱K790手机2部、GPS一部、笔记本电脑一台后台分析：TEMS8.0.3、MCOM、MAPINFO测试时间：2011年6月21日测试路线：启东市乡镇之间主要道路测试方法：手机置于车内后座，沿路进行拨打测试，接续时长180秒间隔20秒。
1.3 测试指标统计1.4 启东市乡镇网络覆盖情况启东市乡镇RxLev覆盖图启东市乡镇RxQul覆盖图2 问题分析2.1 启东塘坊_A小区越区覆盖用启东塘坊_A小区（6366A）,RxLev=-72dBm左右，车辆当前位置距离启东塘坊站点约4.3km。
问题分析：分析发现启东塘坊_A小区天线正对道路方向，由于信号传播途径无任何阻挡，该小区覆盖范围较远。
解决方案：将启东塘坊_1小区（6366A）天线下倾角增大3度。
2.2 D大江中学_A小区天馈接反测试现象：测试车辆沿道路自南向北行驶，在新义站点附近时，主叫MS占用D 大江中学_A小区（D63031A）,RxLev=-72dBm左右，车辆当前位置距离D大江中学站点约1.6km。
拉网测试LOG分析报告
拉网测试LOG分析报告1《拉网测试LOG分析报告》涉及信息：编号类别文件名包含信息1 Outum基站表基站表.xls 基站信息2 路测log Outum.log 无线侧UU信息3 KPI报表4 故障告警1. 主要异常分析说明1.1. 接入异常分析1.1.1.未接通分类通过OUTUM对事件的统计，获知被叫未接通1次。
未接通原因分类个数百分比备注导频污染 1 100%1.1.2.未接通异常分析1.2.2.1UE1在汽车六队-1未接通1.无线侧现象测试车辆自西向东行驶，UE1占用电器厂-1（RNC1421，ARFCN 10088，Cell ID 10451）起呼，收到网络侧下发的“Alerting”后，经过几次切换，最后切换至汽车六队-1（RNC1421，ARFCN 10080，Cell ID10411），收到CN下发Disconnect，原因为正常释放，导致UE1未接通。
如图所示。
我们再来关注UE2侧的信令流程，UE2占用电器厂-1（RNC1421，ARFCN 10088，Cell ID 10451）收到寻呼，并且在发出call confirmed后，读取系统消息，在五交化商场_3小区，触发小区重选为原因的小区更新，小区更新失败，UE2回到IDLE状态，导致本次未接通事件。
2.问题定位1)首先关注UE2在发出call confirmed后的无线环境,我们看到,覆盖和干扰均很好,但邻小区信号五交化商场_3信号较强,其它邻小区也较强,存在导频污染,如图所示,由于UE处于CELL-FACH状态,当满足小区重选条件时,就会发生小区重选为原因的小区更新.2)从无线环境的角度,在UE起呼的过程中,需要尽量减少小区更新的次数,因为如果小区更新发生,并且与RB建立过程并发,网络侧就会释放这条链路.如何减少小区更新的次数呢?从事件点处测量离各基站的距离,发现距离都很近,离最远的五交化商场站为244米.所以建议调整五交化商场-3的天馈，控制其覆盖范围3)建议调整后对事件发生的路段进行复测，同时关注UE在占用主服务小区和邻区信号强度情况1.2. 掉话分析1.2.1.掉话问题分类掉话分类个数百分比备注干扰150%1、雪淇食品-1与东关支局-1距离约500米，且雪淇食品雪淇食品-1与东关支局-1均向同一段荆河路上覆盖；2、 雪淇食品-1与东关支局-1频点相同（10080），故关支局-1对雪淇食品-1产生一定程度的同频干扰。
精品案例_NR不下发B1测量导致无法接入5G问题
NR不下发B1测量导致无法接入5G目录一、问题描述 (3)二．问题分析 (3)三．测试验证 (6)四．总结 (8)NR不下发B1测量导致无法接入5G【摘要】铜陵电信城区NR拉网测试中发现部分路段5G覆盖异常，多处道路无5G覆盖，通过测试分析，发现问题路段站点EMC开关开启，EMC开启后小区下用户被识别为紧急呼叫用户，核心网需确认用户位置信息更新，紧急呼叫用户在下发B1频点的时候不会根据PLMN 进行过滤，而普通用户会根据PLMN进行过滤后下发B1频点。
所以出现了测试中掉线5G，且不再下发B1事件的现象，EMC开关关闭后，终端正常接入5G。
【关键字】B1、EMC【业务类别】参数优化一、问题描述NR拉网测试中发现部分路段5G覆盖异常，多处道路无5G覆盖，根据前期单验测试情况NR站点覆盖正常，核查现网5G站点无告警。
二、分析过程通过Probe Log分析发现，在占用其他锚点5G测试正常占用，切换到福景东方城锚点小区后，信令显示NRSCellNormalRelease LTE Handover，LTE切换到顺风家园切换成功，NR 辅载波释放，且释放后再无发起B1事件。
后台查询指标发现该站锚点1小区连续无用户触发添加SCG，2和3小区存在用户触发添加SCG，次数较少。
再结合测试LOG判断，该站点锚点概率性可以触发添加SCG。
通过参数核查，LTE侧锚点开关已打开，DC分流开关已打开，QCI6-9 DC分流模式配置无误，LTE和NR不活动定时器设置为10或20无问题，通过信令跟踪发现，此问题为单个站点问题，现场通过S1标口信令跟踪了解到主要为UE-INACTIVITY导致了UE掉话，且不再下发B1事件，未下发B1事件为EmcDefaultBearerAPP（统计UE承载的APP和紧急呼叫默认承载配置的APP相同的次数）。
通过performance文件记录的信息主要为3月29日8PM发生指标下降的情况，通过核查对应时间点CHR发现，UE发生了频率统计错误，发生由统计失败造成的掉线。
贵州朗捷毕节项目城区拉网测试报告-网格一(20150716)
Rxlev 覆盖图
Rxquality 覆盖图 贵州朗捷科技有限公司毕节项目组
MOS 覆盖图
四、问题分析
贵州朗捷科技有限公司毕节项目组
1、 卫校地段
问题分析：
测试车辆由北向南行驶在卫校校园内路段，主叫 MS占用 7BJ_麻园卫校宿舍 楼 A 栋 3 楼 S_bts6（LAC: 34161,CI: 8049,BCCH:50,BSIC:20 ）通话，RxlevelSub ＝ -85dBm，RxQualSub＝7，主叫在此出现连续 7 等级质差， 回放 log 数据分析发 现 , 在该段路主叫占用室分小区信号电平强度突降，导致质差拖死掉话。
接通率 掉话率 RxQuality
(%)
(%) 质量 0-5
GSM语 音质量 2013
网格常规统计指标
ቤተ መጻሕፍቲ ባይዱ
覆盖
MOS均
率
1800M 占比
值
车速 (KM)
网格 1 98.57 100.00 1.43
99.09
二、网格测试 Rxlev 、Rxquality 、 MOS覆盖图
? 网格 1
98.47 100 91.12 3.91 9.54
解决方案：
1、建议修改切换参数迟滞切入 7BJ_麻园卫校宿舍楼 A 栋 3 楼 S_bts6 。
五、 遗留问题
1、卫校校园内路段修改参数后进行复测。
贵州朗捷科技有限公司毕节项目组
网格一语音 DT测试分析报告
2015-07-16
概述： 为了解毕节市城区网格一 DT语音拉网测试，其中覆盖率为 详细发现如下：
一、 测试 KPI 指标：
DT 网络覆盖情况，今日对网格一主干道进行了 100，接通率为 100 %，掉话率为 1.43%。测试中
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
拉网测试LOG分析报告1
《拉网测试LOG分析报告》涉及信息：
编号类别文件名包含信息
1 Outum基站表基站表.xls 基站信息
2 路测log Outum.log 无线侧UU信息
3 KPI报表
4 故障告警
1. 主要异常分析说明
1.1. 接入异常分析
1.1.1.未接通分类
通过OUTUM对事件的统计，获知被叫未接通1次。
未接通原因分类个数百分比备注导频污染 1 100%
1.1.
2.未接通异常分析
1.2.2.1UE1在汽车六队-1未接通
1.无线侧现象
测试车辆自西向东行驶，UE1占用电器厂-1（RNC1421，ARFCN 10088，Cell ID 10451）起呼，收到网络侧下发的“Alerting”后，经过几次切换，最后切换至汽车六队-1（RNC1421，ARFCN 10080，Cell ID10411），收到CN下发Disconnect，原因为正常释放，导致UE1未接通。
如图所示。
我们再来关注UE2侧的信令流程，UE2占用电器厂-1（RNC1421，ARFCN 10088，Cell ID 10451）收到寻呼，并且在发出call confirmed后，读取系统消息，在五交化商场_3小区，触发小区重选为原因的小区更新，小区更新失败，UE2回到IDLE状态，导致本次未接通事件。
2.问题定位
1)首先关注UE2在发出call confirmed后的无线环境,我们看到,覆盖和干扰均很
好,但邻小区信号五交化商场_3信号较强,其它邻小区也较强,存在导频污染,如图所示,由于UE处于CELL-FACH状态,当满足小区重选条件时,就会发生小区重选
为原因的小区更新.
2)从无线环境的角度,在UE起呼的过程中,需要尽量减少小区更新的次数,因为如
果小区更新发生,并且与RB建立过程并发,网络侧就会释放这条链路.
如何减少小区更新的次数呢?从事件点处测量离各基站的距离,发现距离都很近,离最远的五交化商场站为244米.所以建议调整五交化商场-3的天馈，控制其覆盖范围
3)建议调整后对事件发生的路段进行复测，同时关注UE在占用主服务小区和邻
区信号强度情况
1.2. 掉话分析
1.2.1.掉话问题分类
掉话分类个数百分比备注
干扰
1
50%
1、
雪淇食品-1与东关支局-1距离约500米，且雪淇食品雪淇食品-1与东关支局-1均向同一段荆河路上覆盖；
2、 雪淇食品-1与东关支局-1频点相同（10080），故关支局-1对
雪淇食品-1产生一定程度的同频干扰。
覆盖问题
1
50%
1、
汇鑫大厦-2和地税局-3距离滕州市鑫宇市政分别约750米和
370米，汇鑫大厦基站位于5
层楼顶的20米铁塔上，地税局-3前方比较
空旷，故均产生一定程度的越区覆盖； 2、
汇鑫大厦-2和税局-3主频点相同（10088），故税局-3对汇鑫
大厦-2产生一定程度的同频干扰；
1.2.2. 掉话问题分析
1.2.2.1 主叫占用雪淇食品-1掉话 1. 无线侧现象
测试车辆自西向东行驶至如图所示处，UE1在进行通话的过程中从东关支局-1（RNC1421，ARFCN 10080，Cell ID 10061）切换至雪淇食品-1（RNC1421，ARFCN 10080，Cell ID 10901）。
切换成功后，UE1上发“测量报告”回应网络侧下发的“测量控制”后，进入读系统信息状态，发生掉话事件。
掉话前UE1占用的主服务小区PCCPCH RSCP 在-93dBm ，C/I=-11。
2.问题定位
1.观察基站地图，雪淇食品-1与东关支局-1距离约500米，且雪淇食品-1与东关支局-1均向同一段荆河路上覆盖。
✓存在一定程度的弱覆盖问题,对雪淇食品-1进行天馈调整，解决其对本区域的覆盖范围。
✓雪淇食品-1与东关支局-1频点相同（10080）扰码分别为31和86,属于同一基扰码组，故关支局-1对雪淇食品-1产生一定程度的同频干扰
类别频率码字后果严重程
度
是否需规
避
第一邻区间（非本站）有频率相同
（包括主频
和辅频）
同复合
码组
两小区距离较近时
可能在辅频上产生
同频干扰
中尽量规避
为避免同频干扰。
（1）将雪淇食品-1的主频点从10080进行修改；具体修改的值请与机房确认,因为在无线侧目前无法获得辅频点信息.
雪淇食品-1扰码为31, 修改雪淇食品-1扰码为33;
雪淇食品-2扰码为120, 雪淇食品-3扰码为112,112与120属于L组,修
改雪淇食品-2扰码为119,;
1.2.2.2被叫占用地税局-3掉话
1.无线侧现象
测试车辆自南向北行驶至如图所示处，UE2占用地税局-3（RNC1421，ARFCN 10088，Cell ID 10423）进行业务的过程中向网络侧上发“测量报告”后向滕州市鑫宇市政-2（RNC1421，ARFCN 10096，Cell ID 11742）切换失败进入读系
统信息状态，发生掉话事件。
掉话前UE2占用主服务小区PCCPCH RSCP在-76dBm，C/I=4。
2.问题定位
a、首先关注掉话点处的无线环境,覆盖与干扰均很好.
专用信道的测量情况:
专用信道干扰较大,怀疑频点扰码规划不合理导致
1）滕州市中心人民医院、滕州市粮食局，所有小区扰码为零，频点不正确，请确认这两个站是否存在？如果存在，在基站表中更正频点
扰码等信息，并且配置相关的邻区；如果不存在，去掉这些站的
信息，周围基站的天馈需要做一定的调整，目前怀疑这两个站未
开通。
2）其它小区频点扰码规划；下面两个小区虽然扰码属于同一下行导频码，但主频点不同，所以符合要求。
3）通过全网拉线图，如下：
考虑从覆盖方面调整地税局-3小区的天馈下倾角，使得UE2从汇鑫大厦先切换至滕州市鑫宇市政-2小区。
4）对第一点核查后，复测确认是否解决该问题。
1.3. 切换分析
此LOG没有切换问题
3. 覆盖、干扰详细分析
3.1. 覆盖分析
对测试log的弱覆盖P-CCPCH RSCP<-90dBm的路段进行分析。
主要从“越区覆盖、超远覆盖和无主覆盖、背向过覆盖”进行分析。
并提出具体优化思路；
3.1.1.弱覆盖
问题描述：
通过UE2的PCCPCH RSCP全网拉线图：
问题分析及解决思路：通过查看信令，获知UE2重选至2G网络又重选回TD。
所以，建议通过调整东关支局_1小区的天馈解决此问题。
3.2. 干扰分析
对测试log P-CCPCH RSCP>-90dBm ,C/I<-3dB的路段进行分析。
主要从同频同码干扰、GPS跑偏干扰、邻区漏配干扰、设备异常故障干扰角度分析。
3.2.1.干扰
问题描述：通过UE2的PCCPCH C/I:
问题分析及解决思路：问题区域与覆盖分析中弱覆盖区域一致,不再详述.。