鼎利LOG处理教程.docVIP

PAGE 3 PAGE 1 关于鼎利软件对LOG的处理，理论上前台与后台都能对LOG进行裁剪和分割，但我觉得用前台对LOG进行处理比较方便，这里暂讲诉一下个人的经验，如有不正确的地方还请指正。  短呼测试LOG的处理 首先我们打开鼎利鼎力后台软件，并导入本次短呼拉测LOG，并导出指标，结合指标筛选出指标不达标的LOG。 省公司对短呼LOG有项接通率的考核，所有此时我们已经筛选除了部分接通率非常差的LOG，接下来在后台软件中找到这些LOG并打开信令。以其中名为“UMTS2达州-周期拉网-WG-WGS短呼-祝佳-H1-（1）(1)”的处理过程为例。 由于测试短呼时为主被叫相互拨打测试，因此我们需要同时打开两个端口的信令进行对比，找到未接通标识，并记录下我们需要裁减的时间段，而且这个时间段应为两个端口所裁时间的合并集，否则可能出现遗留下为裁减完全的信令而导致裁减不彻底，因为短呼的整个流程时间不算长，所以我们处理这个未接通选择直接裁掉整个呼叫流程，这里需要裁减的时间段为，10:38:12~10:38:28。接下来打开鼎利前台软件。 导入问题LOG并选择按时间裁减。 找到我们开始记录下的10:38:12~10:38:28，裁减LOG时我们能直接看到LOG的起始和结束时间，因此这里的时间段设置应为 10：02：09~10：38：11 10：38：12~10：38：28（本段时间为需要裁减段） 10：38：29~10：46：54 点击OK。 点击裁减并选择存储位置。 LOG已被裁为三段，删除中间段。并合并剩余两个LOG，本次对未接通的处理就完成了。 同样，将剩余两部分LOG添加进去，点击合并项并保存，新生成的LOG就没有了开始的未接通。 其他有多个未接通的处理方法类似，记录下每个未接通的时间段，而且每段时间的前后不能相同， 例如像10:38:12~10:38:27 10:38:27~10:40:12 上面这种就不行，第二段时间的起始时间应比上一段时间的结束时间多一秒。 对于覆盖类的裁减问题其大致相同，找到图中若覆盖部分，点击其中一个点查看当时正在进行的信令流程，则我们应选择既为红色且信令为空闲状态的部分进行裁减，如果红色部分有短呼呼叫，要么就不裁剪要么就直接裁掉整个流程，不能破坏其信令完整性。 图上部分为弱覆盖部分的空闲时间段。裁掉差ECIO部分与此相同。 数据测试LOG的处理 1、对数据业务LOG的处理与短呼类似，找到上传或者下载建立失败的时间段，并直接裁掉整个信令流程。需保持如下流程的完整性。 通常我们看速率分布是否达标也需要导出指标。 2、红色方框内的值决定了我们是否需要裁掉速率低的采样点。此次拉测中，省公司对上传下载的速率分布进行红线指标标志，在处理上传下载速率分布的过程中，我们将速率值的分级在鼎利后台软件中设置好。 将值设为省公司要求的红线指标值。 找到下载速率低的部分，记录下时间段，并裁掉对应的下载流程。 三、长呼测试LOG处理流程 1、长呼LOG处理起来相对较简单，弱覆盖和ECIO过差的区域直接裁掉就可以了。 2、对掉话的裁减，与短呼一样，导出指标，在信令掉话率一栏中筛选出有掉话的log，同样需要在后台软件中打开其信令。裁掉掉话尾部与下一次起呼的信令就可以了。 找到掉话点， 裁掉掉话尾部与下次起呼开始的信令，记录下时间段裁掉，合并，OK.，本次掉话的裁减就圆满完成了。