掉话优化思路

掉话优化思路
掉话优化思路

1 网优类

1.1 掉话类

掉话排查总体思路流程图

1.1.1 CS掉话类问题处理流程

现网的掉话监测分成RNC级的掉话与小区级的掉话两个方面,若出现网元大

面积掉话,可能由RNC硬件故障引起。但还有一种情况是全网所有的RNC

掉话率都较高,此时可以考虑可能是由于CN的故障或是由其它系统原因造成,

比如系统升级。

造成RNC掉话升级的原因可以有以下几种:

1. 参数配置错误:这有两个方面参数配置存在问题,一是RNC中的全局参

数配置存在问题,另一方面是由CN中对RNC的参数配置存在问题。

2. RNC硬件故障问题:需要通过对RNC告警的检查以及对RNC日志的检

查来确定是否是由硬件故障引起。

小区级掉话率较高,造成小区掉话的原因较多,主要有以下几种:

1. 干扰造成的掉话:(同频干扰、相关性较强的扰码引起的干扰、导频污

染、上下行交叉时隙干扰、上下行导频间干扰、系统间干扰、其它无线

设置的干扰)

2. 切换造成的掉话:(硬件故障导致切换异常、同频同扰码小区越区覆盖

导致切换异常、越区孤岛切换问题、目标小区上行同步失败导致切换失

败、无线参数设置不合理导致切换不及时)

3. 基站硬件故障造成的掉话

4. 终端问题造成的掉话

5. 链路失衡造成的掉话

6. 参数配置错误造成的掉话

覆盖问题造成的掉话(覆盖空洞造成的掉话、越区覆盖造成的掉话、孤岛效应

导致的掉话、导频杂乱导致的掉话、阴影衰落导致的掉话)

1.1.1.1 RNC级问题处理思路

1. 确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。

2. 出现RNC级掉话后,首先需确定该RNC级的掉话是由多个小区引起的,

还是由个别高掉话的小区所导致。如果是由个别小区引起的,应进行小

区级的掉话处理步骤,否则进入网元级的掉话处理过程。

3. 检查RNC的系统告警,检查是否存在相关硬件的告警信息,如果存在单

板的告警,则需要进行排除。

4. 检查RNC的系统日志,对其中不正常部分进行检查。

5. 检查CT数据中掉话部分的信令,分析其错误代码,常见的RNC级参数

设置错误引起的掉话主要有以下几种:

其中:unknown_target_rnc则表明CN中对RNC的SGSN解析地址定

义错误,此时容易造成PS业务RNC间切换失败,从而引起掉话的产生。

而user_plane_versions_not_supported则主要是由于版本问题造成的

失败;如果产生release_due_to_utran_generated_reason原因则主要

是由于硬件故障造成。

1.1.1.2 小区级问题处理思路

1. 确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。

2. 出现小区级掉话时,首先查看该小区是否有硬件故障告警,如果有,首

先要求用服人员解决硬件故障问题。

3. 检查切出成功率是否正常,如果切换成功率较低,检查邻区关系以及是

否存在同频同码的情况。

-邻小区关系中是否存在同频同扰码的现象,这种情况在路测中也可

以发现,一般是在邻区表中出现两条相同的邻小区关系,这里需要

注意的是业务同频同扰的现象,它无法在路测中发现,一般需要对

信令进行分析,此时虽然两个小区主载频异频,但measurement

report却上报了1G事件,针对这种情况需要通过修改频点和扰码

解决(可以通过系统自带的全局参数合法性检查工具进行检查)-邻小区关系中是否存在同频同码组的现象,这种情况在路测中也可

以发现,一般情况是它是影响到终端的测量结果,此时测量结果不

准确,造成终端上报系统后系统判断错误,针对这种情况则需要修

改频点和扰码解决(可以通过系统自带的全局参数合法性检查工具

进行检查)

-是否存在单边邻小区关系,如果存在,添加单边邻区,单边小区的

检查可以使用NOP-T工具进行,也可以通过对性能统计指标中的

小区对切换统计指标来检查。

-是否存在异频邻小区个数过多的现象(异频邻区数超过8个),

如果存在,删除不必要的邻区,这种情况可以使用NOP-T工具进

行检查,也可以使用办公软件进行检查。

-是否存在切换开关设置的问题(有部分HOM开关可能被关掉或在

外部小区定义中的切入开关设为禁止)。如果存在,打开切换开关

-切换相关的事件定义是否准确,不区引用是否正确,如果存在,修改引用

-PS切换失败是否存完整性算法问题,如果存在,将RNC、CN之间的完整性开关设成一致

-是否存在邻区漏配的情况。需要用SCANNER路测发现是否存在漏配的情况。如果存在,添加邻区。

-目标小区拥塞造成的掉话,由于目标小区的资源不足,而本小区的覆盖又越来越差,此时造成掉话。常见的错误代码为

no_resource_available或RRM_CellOverload_Release

4. 检查时隙转换点配置是否正确,是否存在交叉时隙干扰。如果存在,修

改时隙转换点。

5. 检查UP时隙和上行业务时隙的干扰电平,是否存在上行干扰导致掉话。

如果存在,进行干扰排查

6. 根据性能指标统计,如果PS域和CS域的BLER都比较高则有可能存在

干扰,然后再结合载频时隙干扰统计指标来判断是否确实存在干扰,另外通过对信令的分析如存在干扰则一般信令流程正常,未有切换事件或其它事件,但RNC进行了IURELEASE,原因一般为无线链路的原因。

(比如无线链路错误等),有时也会发生CELLUPDATE 原因为RLCunrecoverable error如果确实存在则需要现场排除,现场测试时如果存在干扰则有以下几个方面的显示

-C/I较差:系统内同频的干扰较为严重,发生掉话时会存在终端发射功率较高,的现象,同时覆盖也相对较好,表现在RSCP值上,

一般都在-90dBm以上,另外一表现象就是起呼比较困难,而起呼

成功率后也很容易掉话

-终端发射功率较高,基本上满功率发射,一般都在20以上

-系统外的干扰造成的掉话同样具有终端发射功率较高的现象,也一般都都在20以上

-系统外干扰造成掉话时也可以通过误块率指标进行判断,此时无论

是进行CS业务还是进行PS业务,BLER都比较高,并且保持时

间较长

-系统外干扰语音业务判断,此时进行通话会出现断字、吞字、金属

声等现象,比较难以进行通话。

7. 通过对性能指标的统计,主要是对RRC连接成功率的统计,这其中的统

计包括业务相关和非业务相关的统计,如果两种统计都较差,则有可能

存在覆盖问题,此时可以检查CT数据中RRC CONNECTION

REQUEST中的PCCPCH的值,则说明存在弱覆盖现象,需要进行功率

参数、天线方向角、下倾角的调整。

8. 如果上述都检查不出原因,可能是载波、时隙的隐性故障,此时可以尝

试闭解载波时隙,或者强行闭载波、时隙观察掉话率的变化。

9. 终端问题,一般是通过对大量的性能数据统计,发现掉话高的小区,然

后依据小区性能数据分析信令,可以看出掉话常发生的用户,而后进行

处理。目前常见的终端问题为UP同步存在问题,此时容易在切换时产生

Ue_Operate_fail_physicalchannelfailure错误。

1.1.1.3 按问题原因错误码处理思路

上表为目前TD外场CS域掉话原因最多的4种原因(错误码),占全部掉话

总量的92%左右。下面我们针对每个原因的掉话情况进行排查分析说明,排

查大概思路是从无线到设备,从外部到内部,从软(空口环境、参数设置)到

硬(硬件故障)。

本节中涉及到的覆盖排查、干扰排查在前面的1.1节中都有详细描述,故本节

中对此类排查不予详细描述。

UCIU_error

错误原因机制:

UCIU error表示RLC(无线链路控制层)不可恢复性错误。从结构模型看,

RLC层是比物理层高。发生UCIU error故障(掉话),说明链路的物理层是

正常的,RLC层出现故障。

当RLC层发生传递失败后,会首先进行重传尝试,如果重传成功,链路的RLC 层恢复;

当重传达到最大次数后RLC层仍没有传递成功,发送端可发起RLC层的复位,恢复RLC的全部初始参数,如果复位能够成功,那么RLC重新开始向接收端作重传尝试;

当复位达到最大次数后,复位仍不成功,发送端认为RLC发生了不可恢复性错误。(UCIU error)。

RNC作UCIU error释放,意味着下行链路的RLC发生了不可恢复性错误。

排查思路:

-确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。

-检查这些小区的状态和告警信息,包括RRU的驻波比等,看是否由于设备原因导致UCIU_error。Iub口传输质量不好导致的严重丢

包。一般来讲,由于设备侧异常会导致整个NodeB的小区掉话率

非常高,比较易于从后台KPI指标发现并且处理优先级高,现网

中这种情况应该较少。

-无线参数核查,利用网管自带小区参数模板核查功能进行参数核查(重点关注问题小区与正常小区有出入的参数配置,同时要甄别一

些日常网优调整的常规参数如小区个性偏移、迟滞值等)。

-确定事件发生时间点上当时的场强情况,可能由于弱场导致下行RLC发生不可恢复性错误。

-对系统内、外的上、下行干扰情况进行排查。跟踪后台这些小区的LMT载波测量,同时跟踪这些小区的信令,或者采集后台的CT

数据,将信令时间和LMT时间对齐(计算出差值),对于后台CT

中由于UCIU_error掉话的业务对照LMT数据进行分析,主要关

注业务所在载波的上行的ISCP值和下行的TCP值,上行ISCP

过高或者是有突变,说明是上行干扰过大导致ACK不能反馈上来,

下行TCP过大,说明UE需要的功率过大,表明有弱覆盖或者是

下行强干扰。

-更换终端进行测试,排除特定问题终端因素。

RNLC_Ue_IntraRNCHo_TimeOut

错误原因机制:

该原因的掉话从信令流程上看是由于RNC下发RNC内切换的物理信道重配置或者RB重配消息后,启动一个定时器,在定时器超时前没有收到物理信道重配置完成或者RB重配完成消息,则RNC发起IU释放请求。

排查思路:

-确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。

-查看告警,排查告警问题。

-无线参数核查,利用网管自带小区参数模板核查功能进行参数核查。

-NodeB、传输等数据配置核查。

-RNC下发的物理信道重配置或者RB重配消息,终端没有正常接收到。排查覆盖情况、下行干扰情况。用LMT跟踪小区TCP,若

TCP过大说明终端需要的下行发射功率很大,可判断下行弱覆盖

或者有干扰。

-终端收到了RNC下发的物理信道重配置或者RB重配消息,上报了物理信道重配置完成或者RB重配完成消息,RNC没有收到,

首先排查上行干扰情况。用LMT跟踪小区上行ISCP,如果上行

ISCP过高或者有突变则可判定存在上行干扰。

-更换终端进行测试,排除特定问题终端因素。

-排查NodeB硬件故障。

RNLC_Ue_Cellupdate_TimeOut

错误原因机制:

UE发送cellupdate,RNC响应后下发cellupdate confirm并设置等待定时器,定时器默认长度为5s,定时器超前如果未收到终端的物理信道重配完成消息,则发起Iu Release Request。

排查思路:

-确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。

-查看告警,排查告警问题。

-无线参数核查,利用网管自带小区参数模板核查功能进行参数核查。

-NodeB、传输等数据配置核查。

-RNC下发的cellupdate confirm消息,终端没有正常接收到。排查覆盖情况、下行干扰情况。用LMT跟踪小区上行ISCP,如果上

行ISCP过高或者有突变则可判定存在上行干扰。

-终端收到了RNC下发的cellupdate confirm消息,上报了物理信道重配置完成消息,RNC没有收到,首先排查上行干扰情况。主

要关注业务所在载波的上行的ISCP值和下行的TCP值,对于上

行的ISCP值较高的(暂定为-95dBm,具体数值可以通过路损来

推测,或者有突变的),归结为上行干扰,对于下行TCP值较高

的(由于LMT跟踪的是发射功率的百分比,暂定为80/载波个数

或者有突变的),归结为下行干扰。

-使用不同的测试终端、商用终端进行复测;排除由于个别终端导致的问题。

-排查NodeB硬件故障。

●RlFail_Report

错误原因机制:

网络侧上行失步导致异常,网络侧向CN发送Iu Release Request时,需要填写此原因。出现该原因错误码的掉话,都是源自上行失步,至于是终端原因还是网络侧原因需继续排查。

排查思路:

-确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。

-查看告警,排查设备告警问题。

-无线参数核查,利用网管自带小区参数模板核查功能进行参数核查。

-NodeB、传输等数据配置核查。

-上行干扰排查。主要关注业务所在载波的上行的ISCP值和下行的TCP值,对于上行的ISCP值较高的(暂定为-95dBm,具体数值

可以通过路损来推测,或者有突变的),归结为上行干扰,对于下

行TCP值较高的(由于LMT跟踪的是发射功率的百分比,暂定为

80/载波个数或者有突变的),归结为下行干扰。

-使用不同的测试终端、商用终端进行复测;排除由于个别终端导致的问题。

●SecurityModeRsp_TimeOut

错误原因机制:

终端没有相应网络侧的安全模式命令//业务保持过程中由于位置区更新的安全模式超时,业务保持过程中,出现位置区更新,CN下发安全模式命令(SecurityModeCommand),等待UE回安全模式响应超时,导致网络侧发起业务释放,业务掉话。

排查思路:

-确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。

-查看告警,排查告警问题。

-无线参数核查,利用网管自带小区参数模板核查功能进行参数核查。

-NodeB、传输等数据配置核查。

-RNC下发的SecurityModeCommand消息,终端没有正常接收到。

排查覆盖情况、下行干扰情况,主要关注业务所在载波的上行的

ISCP值和下行的TCP值,对于上行的ISCP值较高的(暂定为

-95dBm,具体数值可以通过路损来推测,或者有突变的),归结

为上行干扰,对于下行TCP值较高的(由于LMT跟踪的是发射功

率的百分比,暂定为80/载波个数或者有突变的),归结为下行干

扰。

-终端收到了RNC下发的SecurityModeCommand消息,上报了完成消息,RNC没有收到,首先排查上行干扰情况,主要关注业务

所在载波的上行的ISCP值和下行的TCP值,对于上行的ISCP

值较高的(暂定为-95dBm,具体数值可以通过路损来推测,或者

有突变的),归结为上行干扰,对于下行TCP值较高的(由于LMT

跟踪的是发射功率的百分比,暂定为80/载波个数或者有突变的),

归结为下行干扰。

-使用不同的测试终端、商用终端进行复测;排除由于个别终端导致的问题。

-排查NodeB硬件故障

1.1.2 PS掉话类问题处理流程

1.1.

2.1 RNC级问题处理思路

1. 出现RNC级掉话后,首先需确定该RNC级的掉话是由多个小区引起的,

还是由个别高掉话的小区所导致。如果是由个别小区引起的,应进行小

区级的掉话处理步骤,否则进入网元级的掉话处理过程。

2. 检查RNC的系统告警,检查是否存在相关硬件的告警信息,如果存在单

板的告警,则需要进行排除。

3. 从流量、HS的RAB增加数量、HS的掉话数量几个方面看,整体PS掉

话率是否和HSDPA用户增加,HS高掉话率有关。厦门、深圳PS掉话

率急剧抬升就是由于HS用户/HS业务量增加有关,而HS掉话率高又和

终端不成熟有关,需要推动终端改进。

4. 在OMM上对PS掉话的原因进行统计,重点分析是哪种原因突然增多。

如果突然出现RL Fail、RNLC Unknow则很大的可能性是由于终端问题

造成,需要进行用户回访,了解终端型号。

5. 检查CT数据中掉话部分的信令,分析其错误代码,常见的RNC级参数

设置错误引起的掉话主要有以下几种:

其中:unknown_target_rnc则表明CN中对RNC的SGSN解析地址定义错

误,此时容易造成PS业务RNC间切换失败,从而引起掉话的产生。而

user_plane_versions_not_supported则主要是由于版本问题造成的失败;如

果产生release_due_to_utran_generated_reason原因则主要是由于硬件故

障造成。

1.1.

2.2 小区级问题处理思路

1. 基站小区的告警日志检查

本着先硬后软的原则,如果是某个小区存在掉线率较高的情况,则需要

先检查一下此小区是否存在硬件故障,同时请注意此时小区的CS业务同

样存在问题。

2. 基站小区干扰统计

小区的干扰统计主要包括两个方面的干扰统计,目前此类指标已经可以在后台进行统计,也可以算做是PI指标统计的一部分,通过判断小区时隙上的平均时隙干扰功率(15分钟粒度、并在晚上4点左右取数据)、最大时隙干扰功率(15分钟粒度、并在晚上4点左右取数据)、UpPCH POS0~15上的干扰统计(15分钟粒度、并在晚上4点左右取数据),通过此项判断是否存在干扰(注:如果存在干扰,则小区的CS掉话也较高)。

3. 检查PS切换成功率是否正常,如切换成功率较低,则:

-邻小区关系中是否存在同频同扰码的现象,这种情况在路测中也可以发现,一般是在邻区表中出现两条相同的邻小区关系,这里需要

注意的是业务同频同扰的现象,它无法在路测中发现,一般需要对

信令进行分析,此时虽然两个小区主载频异频,但measurement

report却上报了1G事件,针对这种情况需要通过修改频点和扰码

解决(可以通过系统自带的全局参数合法性检查工具进行检查)-邻小区关系中是否存在同频同码组的现象,这种情况在路测中也可以发现,一般情况是它是影响到终端的测量结果,此时测量结果不

准确,造成终端上报系统后系统判断错误,针对这种情况则需要修

改频点和扰码解决(可以通过系统自带的全局参数合法性检查工具

进行检查)。

-是否存在单边邻小区关系,如果存在,添加单边邻区,单边小区的检查可以使用NOP-T工具进行,也可以通过对性能统计指标中的

小区对切换统计指标来检查。

-是否存在异频邻小区个数过多的现象(异频邻区数超过8个),如果存在,删除不必要的邻区,这种情况可以使用NOP-T工具进

行检查,也可以使用办公软件进行检查。

-是否存在切换开关设置的问题(有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止)。如果存在,打开切换开关-切换相关的事件定义是否准确,不区引用是否正确,如果存在,修改引用

-PS切换失败是否存完整性算法问题,如果存在,将RNC、CN之间的完整性开关设成一致

-是否存在邻区漏配的情况。需要用SCANNER路测发现是否存在漏配的情况。如果存在,添加邻区。

-切换目标小区拥塞造成的掉话,由于目标小区的资源不足,而本小

区的覆盖又越来越差,此时造成掉话。常见的错误代码为

no_resource_available或RRM_CellOverload_Release。,对于

容量原因造成的掉话,如果是拥塞业务较小,可以通过对负荷算法

进行调整来,但如果拥塞率较高的情况,建议对小区进行扩容,增

加业务载频的个数或是进行小区分裂(增加基站、增加小区)。

-切换时的业务种类,比如切换时的PS384业务、HSDPA业务,

对于PS384业务很容易由于目标小区的资源问题造成切换失败后

掉话,而HADPA业务则有可能由于R5业务的不连续覆盖造成掉

话(注意HSPA业务为硬切换)。对于R5业务不连续的情况,一

般的建议为增加R5的覆盖区域,将之进行连续覆盖。

4. 掉线发生时的大致场强:

主要是判断当时是否存在弱场覆盖,此项指标可以在Measurement Report

或RRC Connection Request中得出PCCPCH-RSCP的协议值(绝对值=协

议值+(-116))。

5. 检查掉线时的是否发生并发业务类型:

目前的并发业务主要有以下几种

-PS+PS业务并发,主要是进行PS业务时可能有彩信等背景类PS

业务发生

-PS+CS业务并发,在进行PS业务时有电话接入或是在进行电话

时有彩信等背景类PS业务发生。

-CS+CS并发,主要是进行CS业务时有短信业务发生

如果存在则有可能是终端多业务性能较差造成,也有可能是由于并发业

务相关参数设置存在问题(比如没有打开2个PS业务并)等造成。

6. 掉线发生时的时隙和码道位置,主要是时隙位置:

可以判断是否由于某一个时隙上的原因造成的,有可能是由于交叉时隙

干扰或室内分布系统中干放时隙转换点与Node B上设置不同造成的,或

是否发生了同频同时隙的切换。

1.1.

2.3 按问题原因错误码处理思路

UCIU_error

RLC的传输分为三种模式,UM模式,AM模式和TM模式,其中只有AM模式才可能产生UCIU_Error现象。当RLC采用AM模式发送时,为了保证数据的可靠传输,在定期的对已经传输的数据进行状态查询,以确定UE已经收到了系统侧发送的数据包,如果UE侧不回响应,则系统侧会重发此数据包,重发次数由系统侧参数决定,如果达到最大发送次数后,UE侧仍然无响应,则系统测会发Reset状态包,UE收到Reset包后,应该回复Reset Confirm 状态包,如果系统侧没有收到Reset Confirm状态包,会连续发送Reset,知道达到最大从发次数为止。当达到最大重发次数后,RLC侧会通知控制面释放RRC连接。采用AM模式发送的是:大部分的空口信令,PS业务的数据包。

因此,发生UCIU_Error的原因较多,主要可能的原因及排查思路:-确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。

-检查这些小区的状态和告警信息,包括RRU的驻波比等,看是否由于设备原因导致UCIU_error。Iub口传输质量不好导致的严重丢

包。一般来讲,由于设备侧异常会导致整个NodeB的小区掉话率

非常高,比较易于从后台KPI指标发现并且处理优先级高,现网

中这种情况应该较少。

-无线参数核查,利用网管自带小区参数模板核查功能进行参数核查(重点关注问题小区与正常小区有出入的参数配置,同时要甄别一

些日常网优调整的常规参数如小区个性偏移、迟滞值等)。

-确定事件发生时间点上当时的场强情况,可能由于弱场导致下行RLC发生不可恢复性错误。

-对系统内、外的上、下行干扰情况进行排查。跟踪后台这些小区的LMT载波测量,同时跟踪这些小区的信令,或者采集后台的CT

数据,将信令时间和LMT时间对齐(计算出差值),对于后台CT

中由于UCIU_error掉话的业务对照LMT数据进行分析,主要关

注业务所在载波的上行的ISCP值和下行的TCP值,上行ISCP

过高或者是有突变,说明是上行干扰过大导致ACK不能反馈上来,

下行TCP过大,说明UE需要的功率过大,表明有弱覆盖或者是

下行强干扰。

更换终端进行测试,排除特定问题终端因素。

通过统计查看是否主要是HS掉话居多。目前经验来看,主要是HS载频时隙间干扰过大引起UCIU ERROR触发的掉话。其他的掉话类似,都是CRC错

包过多,TRB RESET发送次数超过最大值引起的。对于因时隙间干扰过大引起的此类掉话,现场可通过覆盖调优和HS-SCCH配置时隙交叉(将SCCH 和下行A-DPCH所在时隙在相邻小区间错开(可参考各小区主频),规避同频同时隙干扰,提高SCCH和下行A-DPCH的收对概率)。

RlFail_Report

产生RLFail的直接原因是RNC判断上行失败造成,从目前的优化经验来看,主要有三个方面造成了这种原因

(1)终端侧出现异常

当终端发生异常,没有上发信号,导致基站侧检测不到上行信号而

报无线链路失败,终端侧的异常包括:

-终端本身出现异常,比如死机。

-终端与电脑的连接出现异常,比如连接线、USB插口、插槽因为松动而断线,或终端在电脑上的驱动程序出现异常。

-终端在电脑上的应用程序出现异常。

-电脑出现异常导致终端方面异常。

如果终端侧出现异常,要重新作起业务,一般要对终端进行重启,

终端重启后将会进行一次Location Update过程,这从系统侧后台

信令上可以观察到,并且从上次RL Failure导致掉话到下次重新

作起业务来也将会有较大的时延,通常要超过30秒。

从之前厦门攻关看,90%以上的RLFail都是由于终端异常造成。

(2)无线信道环境出现深衰落或者强干扰

无线信道环境出现深衰落或强干扰时,会导致基站没有解对终端发

出的上行信号而报RL Failure,如果是出现深衰落,下行链路的无

线信道环境跟上行链路一样,信道质量变差,下行功率会抬升得比

较高,并且UE会上报Cell Update。这种情况需要进行用户回访

和复测才能发现,用户往往出在室内弱场区域,解决方案是加强覆

盖,减少干扰。

(3)基站侧出现异常

基站解错上行信号或接收不到上行信号而报无线链路失败。此时基

站应该会出现告警,且基本上不能接入和保持住包括PS在内的任

何业务或终端了。

RNLC_Ue_RBC_timeout

当RNC发起RBC调速的时候,即下发RadioBearerReconfiguration消息后启

动一个定时器,在该定时器超时前若RNC未收到RadioBearerReconfigurationComplete消息,则发起释放IU链路流程,掉话原因即为UE_RBC_timeout.

分析思路:

(1)结合前台测试信令,查看终端是否收到RadioBearerReconfiguration消息,若终端未收到该消息,则检

查下行链路状况(包括干扰、NodeB、传输等)。用LMT跟踪小

区TCP,若TCP过大说明终端需要的下行发射功率很大,可判断

下行弱覆盖或者有干扰。

(2)结合前台测试信令,终端收到RadioBearerReconfiguration消息后是否上报了RadioBearerReconfigurationComplete消息,若终

端上报该消息,则检查上行链路状况(包括干扰、NodeB、传输

等)。用LMT跟踪小区上行ISCP,如果上行ISCP过高或者有突

变则可判定存在上行干扰。

(3)3、结合前台测试信令,终端收到RadioBearerReconfiguration消息后是否上报了RadioBearerReconfigurationComplete消息,若

终端未上报该消息,则可能个别终端有问题,更换多款终端进行

多次测试。

解决问题的方法问题解决七步法

解决问题的方法问题解 决七步法 Document number:BGCG-0857-BTDO-0089-2022

解决问题的方法--问题解决七步法 俗话说:授人以鱼,不如授人以渔。 教人解决一个问题,不如教人解决问题的方法。 问题解决七步法作为开展现场改善的基本方法,要解决的就不只是单个问题,而是如何去解决成百上千问题的思路。 将通常进行改善的PDCA过程,细分成七个关键的步骤,整理出来形成指导改善开展的方法,就是问题解决七步法。 有问题就应该解决,似乎顺理成章,然而,很多时候问题并未得到有效解决。究其原因,一是欠缺解决问题的意识,二是缺少解决问题的方法。而七步法在这方面有其良好的效果。一方面,问题解决七步法为你提供了解决问题的方法,特别是当你遇到有较大不确定因素的问题,没有太多相似案例可以借鉴时,七步法很容易派上用场,它告诉你的是一种有效的思维逻辑。另一方面,当你需要借助解决问题的过程,培养员工的问题意识和解决问题的能力时,问题解决七步法更能体现其价值。因为仅仅解决单个问题不过是就事论事,养成解决问题的习惯才是一个团队学习能力的体现。 以下对七个步骤加以简单介绍。 STEP-1现状把握 >>>说明: 现状把握告诉我们在解决问题之前,首先要明白问题之所在,这是有效解决所有问题的前提。仅仅笼统地说这里不好、那里不好,并不能帮你更好地分析问题。以下三点有助你更准确地把握问题之所在: 1、从习惯找“问题”到习惯找“问题点” 问题:零件摆放混乱

问题点:待检/合格/不良等不同状态的零件未明确区分 问题:工作台脏乱差 问题点:边角料和工具配件随手扔、灰尘污垢未清扫 问题:工人效率低 问题点:搬运作业时间长,所占作业比重过大 2、从习惯“统述问题”到习惯“分述问题(现象+影响)” 统述问题: 每天出入库都有木踏板被损坏,严重点的通常都丢掉了,浪费了不少钱,也不利于节约资源,不利于环保,破损轻点的又弃之可惜,有几次随产品出货还被海外客户投诉了。 分述问题:(现象+影响) 1)有部分损坏的木踏板全部废弃,耗费资源; 2)每天约废弃18块,成为环境污染源,不利于环保; 3)整个木踏板大部分完好未再利用,浪费公司资金; 4)木踏板有少部分损坏弃之可惜,出货至海外后引起投诉。 3、从习惯“抽象”谈问题到习惯“量化”谈问题 抽象: 1)操作时行程较远 2)生产效率低。 量化: 1)操作时单程平均距离1米(1PCS) 生产数:1800PCS/日 员工每日来回行程:1800×1×2=3600米 2)生产1PCS行走约5秒 每天生产1800PCS 花在行走的时间: 1800×5×264工作日/年=660小时

掉话专题

掉话分析 一、概述 本地网规划与优化服务的掉话研究的主要内容是掉话计数器跳转的原因及话务统计掉话率的真实性,并分析各种类型掉话的原因。主要结论如下: l BSC掉话计数器跳转非常明确,只有实际掉话时才会跳转。话务统计的掉话率也是真实的,数量与BSC内部实际掉话相符。 l 突然掉话(SUDLOS)是超TA、弱信号与质量差三个条件都不符合的掉话,而掉话原因是太多测量报告丢失,或T200定时器超时等。 l 切换掉话只计源BSC的一次掉话。研究结果也确认各种原因与实际情况关系,其中原因主要是MS LOST。 l 网络中其它原因(Other Reason)的掉话原因主要是MSC与BSC之间的切换掉话及由于交换硬件所引起的掉话。 l BSC的4个阀值:LOWSSDL、LOWSSUL、BADQDL与BADQUL,对掉话计数器的跳转起了决定性的作用,而阀值需根据BSC信号强度分布设置。 l 半速率TCH在比较差的无线环境下有可能出现比全速率TCH更高的掉话率。 二、BSC掉话分析研究 掉话是指通话的非正常终止,掉话率是指掉话次数在接通总次数中的比例,它是衡量网络可用性的一个重要指标。无线网络的掉话可分为两种:一种是在SDCCH信道上的掉话,另一种是在TCH信道上的掉话。SDCCH掉话是指在BSC给MS分配了SDCCH信道,而TCH信道还没有分配成功期间发生的掉话。TCH掉话是指在BSC给MS成功分配了TCH信道后,发生的不正常TCH释放。BSC掉话研究主要研究发生掉话的原因和掉话统计真实性。 2.1 呼叫连接释放过程的分析 正常情况下,若主叫先挂机,则MS利用FACCH信道向MSC发出“DISCONNECT”消息。MSC收到该信息后,随即清除业务信道在网络中的连接,并向MS发出“RELEASE”消息,释放

问题解决思路讲解

解决问题的方法--问题解决七步法 俗话说:授人以鱼,不如授人以渔。 教人解决一个问题,不如教人解决问题的方法。问题解决七步法作为开展现场改善的基本方法,要解决的就不只是单个问题,而是如何去解决成百上千 问题的思路。将通常进行改善的PDCA过程,细分成七个关键的步骤,整理出来形成指导改善开展的方法,就是问题解决七步法。有问题就应该解决,似乎顺理成章,然而,很多时候问题并未得到有效解决。究其原因,一是欠缺解决问题的意识,二是缺少解决问题的方法。而七步法在这方面有其良好的效果。一方面,问题解决七步法为你提供了解决问题的方法,特别是当你遇到有较大不确定因素的问题,没有太多相似案例可以借鉴时,七步法很容易派上用场,它告诉你的是一种有效的思维逻辑。另一方面,当你需要借助解决问题的过程,培养员工的问题意识和解决问题的能力时,问题解决七步法更能体现其价值。因为仅仅解决单个问题不过是就事论事,养成解决问题的习惯才是一个团队学习能力的体现。 以下对七个步骤加以简单介绍。 STEP-1现状把握 说明:现状把握告诉我们在解决问题之前,首先要明白问题之所在,这是有效解决所有问题的前提。仅仅笼统地说这里不好、那里不好,并不能帮你更好地分析问题。以下三点有助你更准确地把握问题之所在: 1、从习惯找“问题”到习惯找“问题点” 问题:零件摆放混乱 问题点:待检/合格/不良等不同状态的零件未明确区分 问题:工作台脏乱差 问题点:边角料和工具配件随手扔、灰尘污垢未清扫 问题:工人效率低 问题点:搬运作业时间长,所占作业比重过大 2、从习惯“统述问题”到习惯“分述问题(现象+影响)” 统述问题:

每天出入库都有木踏板被损坏,严重点的通常都丢掉了,浪费了不少钱,也不利于节约资源,不利于环保,破损轻点的又弃之可惜,有几次随产品出货还被海外客户投诉了。 分述问题:(现象+影响) 1)有部分损坏的木踏板全部废弃,耗费资源; 2)每天约废弃18块,成为环境污染源,不利于环保; 3)整个木踏板大部分完好未再利用,浪费公司资金; 4)木踏板有少部分损坏弃之可惜,出货至海外后引起投诉。 3、从习惯“抽象”谈问题到习惯“量化”谈问题 抽象: 1)操作时行程较远 2)生产效率低。 量化: 1)操作时单程平均距离1米(1PCS) 生产数:1800PCS/日 员工每日来回行程:1800×1×2=3600米 2)生产1PCS行走约5秒每天生产1800PCS 花在行走的时间: 1800×5×264工作日/年=660小时 当然问题的关键还在于员工是否有兴趣去发现问题,也就是我们常说的问题意识。我认为有两方面值得 关注: 1、上级对待问题的态度所营造的氛围 2、责任人自身对手头工作的热爱程度。 >>>方法:

详细讲解WCDMA掉话问题分析及优化方法

WCDMA 掉话问题分析 第一章掉话分类定义 第一节正常释放流程 一个CS正常释放信令流程 1.UE发RRC_UL_DIR_TRANSF消息给RNC,消息中nasmessage是0325,表示是call control 子层的disconnect消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN,消息中naspdu是0325,表示是call control 子层的disconnect消息。 3. CN发RANAP_DIRECT_TRANSFER消息给RNC,消息中naspdu是832d,表示是call control 子层的release消息。 4.RNC发RRC_DL_DIRECT_TRANSF消息给UE,消息中nasmessage是832d,表示是call control子层的release消息。 5.UE发RRC_UL_DIR_TRANSF消息给RNC,消息中nasmessage是032a,表示是call control 子层的release complete消息。 6. RNC发RANAP_DIRECT_TRANSFER消息给CN,消息中naspdu是032a,表示是call control 子层的release complete消息。

https://www.360docs.net/doc/2a2216157.html,发RANAP_IU_RELEASE_COMMAND消息给RNC,开始释放Iu口资源,包括RANAP 层和ALCAP层资源。 8. RNC发RANAP_IU_RELEASE_COMPLETE消息给RNC。 9.RNC发RRC_RRC_CONN_REL消息给UE,开始释放RRC连接。 10. UE发RRC_RRC_CONN_REL_CMP消息给RNC。 11.RNC发NBAP_RL_DEL_REQ消息给NODEB,开始释放Iub口资源,包括NBAP层和ALCAP 层,PHY层资源。 12. NODEB发NBAP_RL_DEL_RSP消息给RNC,整个释放过程结束。 一个PS正常释放信令流程 1.UE发RRC_UL_DIR_TRANSF消息给RNC,消息中nasmessage是0a46,表示是session management子层的deactivate PDP context request消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN,消息中naspdu是0a46,表示是session management子层的deactivate PDP context request消息。 3. CN发RANAP_DIRECT_TRANSFER消息给RNC,消息中naspdu是8a47,表示是session management子层的deactivate PDP context accept消息。 4. CN发RANAP_RAB_ASSIGNMENT_REQ消息给RNC,消息中给出要释放的RAB list,其中包含了要释放的RAB ID。 5. RNC发RRC_DL_DIRECT_TRANSF消息给UE,消息中nasmessage是8a47,表示是session management子层的deactivate PDP context accept消息。 6. RNC发NBAP_RL_RECFG_PREP消息给NODEB。 7. NODEB发NBAP_RL_RECFG_READY消息给RNC, 8. RNC发RRC_RB_REL消息给UE,释放业务RB。 9. NODEB发NBAP_RL_RECFG_COMMIT消息给RNC,

L掉线专题分析指导V

东莞LTE掉线指标专题分析指导 1、概述 本文主要结合东莞移动LTE现网无线掉线指标情况,根据现网数据统计分析,重点介绍了LTE系统内掉线率指标的优化思路、分析方法、定位手段及典型案例;影响掉线指标的原因主要包括:弱覆盖、干扰、故障及参数设置、异常TOP终端等。 2、无线掉线率定义及分析 2.1无线掉线指标定义 无线掉线率= eNB异常请求释放上下文数/初始上下文建立成功次数*100%。 (eNB请求释放上下文数=eNodeB发起的UE Context释放次数+eNodeB发起的S1 RESET 导致的UE Context释放次数

无线掉线率该指标指示了UE CONTEXT异常释放的比例。异常请求释放上下文数通过UE CONTEXT RELEASE REQUEST中包含异常原因的消息个数统计;初始上下文建立成功次数通过包含建立成功信息的Initial Context Setup Response 消息个数。 如图1中A点所示,当eNodeB向MME发送UE CONTEXT RELEASE REQUEST 消息,会释放UE的所有E-RAB。当释放原因不为“Normal Release”,“Detach”,“User Inactivity”,“CS Fallback triggered”,“UE Not Available for PS Service”,“Inter-RAT Redirection” ,“Time Critical Handover”,“Handover Cancelled”时,测量指标L.UECNTX.AbnormRel加1 如图2中A点所示,当eNodeB向MME发送S1 RESET消息时,根据包含的上下文个数,指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。

公司运作系统改善方案

公司运作系统改善案 自然法则,物竞天择。随着世界经济一体化的来临,企业的运作平台日趋国际化,同时互联网和最新信息科学的广泛应用,使企业之间的竞争更加白炽化,一时风生云起,未辩谁是真正行业霸主!鉴于公司的快速发展及市场全国化经济环境下,公司面临的不确定性日益增多,为提升公司的核心竞争力,使公司能始终处在洁具行业的潮头浪尖,引领新时代的风范,特根据公司目前的现状,提出以下分析及改善方案,供陈董您参考。 一、改善思路 流程化、规范化、标准化、文本化、数据化管理是公司经营步入正轨、管理成熟的重要标志,也是众多公司追求的目标,因应公司目前产品少量多样、变化较频繁的特点,特制订以下改善思路:理顺公司流程,合理组织架构,分清部门职责,紧密部门之间的衔接,强化营运执行力,切实提高运作绩效(效率*效果),建立反应迅速,以有效开拓市场创造客户核心价值为中心的公司经营系统作为改善方向,秉持以质量提升客户的信誉度,以规模拓展市场,以管理促进效益的企业持续改善思路,加强内部整合管理,精耕细作,通过适应市场、感悟市场,并主动出击,不断拓展外贸市场及国内营销通路,利用快捷反应来为顾客提供细致服务,不断前进,为公司创造竞争优势。 二、公司现状 公司自创立以来,已历时几年,在董事长正确决策及高效引导下,取得目前的成就。但是目前公司的运作方式主要还处于一种传统的生产管理模式,内部的管理系统较不完善。公司必须要制定明确的企业品质方针及企业文化,并沉淀形成一支有专业经验的管理技术队伍,现用“SWOT”方法,对公司的优势、劣势、潜在风险与机会进行研判,详如下表所示:

综合结论:公司尚处在快速发展之轨道,有很好的发展前景,员工对公司文化的认同,部门之间的衔有待进一步加强,团队凝聚力有待进一步提升,公司如能在短时间内有效提升管理组织执行力,则公司还能以更稳定、更快捷的步伐前进。 三、公司运作系统改善案 立足现实,直面是挑战,方能把握未来。公司的运作主体必须包含研、产、供、销等分系统,具体涉及研发技术、财务、生管、采购、生产、品管、销售、人力资源、后勤总务、信息、财务、生产技术及设备工程等功能模块,运作过程包括策划及执行二部分,改善须从运作环节的短板开始加强,渐进式拓展至整个系统,提高效率,现针对公司各功能模块提出建议如下: 1)市场模块:适应市场,快速反应。满足客户需求,首先利用各种手段进行市场调查(包括对客户需求的了解),分析市场、把握市场需求变化,提 高客户需求反馈速度及服务效率,以80%的资源服务于20%的优质客户,并重点做好客户的服务工作,使核心客户价值最大化,要加强化同生产部 门、研发部门的沟通与协调,市场部门要加强对产品特色、生产周期及生 产工艺、技术开发流程的了解,更好地起到公司内部与客户的桥梁作用。 2)研发技术模块:产品开发注重功能、结构、参数等方面。目前根据公司的产品特点,需要专业的工业设计师,使公司在外观造型款式上多样化、 个性化、设计思路时尚化,了解客户的需求,但产品内部零部件设计要尽 量标准化、简洁化、针对不同的市场要求及价格定位,确认相应所选用的 设计方式以降低采购、生产的工艺技术难度,并提高生产效率以控制生产 成本,这就要求:一,新进技术人员首先要了解公司的设计思路及方式, 尽快度过磨合期,融入公司设立团队;二,每个工程师的设计结构、参数

EVDO掉话优化思路详解

目录 1 整网问题分析思路 (2) 2 TOP小区优化思路 (4) 3 掉话常见原因及处理方法 (7) 3.1 异常用户 (7) 3.2 1X/DO互操作 (11) 3.3 告警 (12) 3.4RSSI异常 (13) 3.5 邻区配置不合理 (14) 3.6 PN复用不合理 (14) 3.7 参数设置不合理 (15) 3.8 AN间切换失败 (16) 3.9覆盖差 (16)

掉话问题分析处理思路 1 整网问题分析思路 1、采集相关数据。 a)话统(包括BSC级、载频级,至少一周的数据,包括全天指标、忙时 指标、各个时段指标,包括关联指标如:连接成功次数、各种原因值 的连接释放次数、软切换成功率、AN间切换成功率、RSSI等) b)日志/CDR c)告警 d)后续根据分析的需要再采集其他相关数据,如操作记录、参数、邻区、 路测数据等。 2、分析话统、日志或CDR,获得整体认识(先整体再局部),检查问题存在 的规律,如分布范围、原因值分布、IMSI分布、时间相关性等。 a)问题范围及分布规律:通过查询话统(如需要可结合日志、CDR)分 析掉话分布的范围,是全局分布还是集中在某些载频?其分布范围有 什么规律,如是否全网所有基站都有此类问题?还是集中在某个 MSC?还是集中在某个BSC?还是集中在某个IP框?或集中在某块 FMR单板?或集中在连片的区域?或集中在某个频点?或集中在某个 基站?或集中在某个LAC?或集中在某个信令点?或集中在BSC边 界?或集中在多载波基站?或集中在硬切换区域?或集中在某种类型 的基站?或集中在XX类型星卡的基站?或集中在XX类型信道板的基 站?或集中在XX软件版本的区域? b)时间相关性:该指标从什么时间开始变差的?还是一直就差?还是只 是在某个时间段变差?如果有明显的时间相关性,那么就需要重点分 析在指标变差的时间段,进行了哪些操作(如参数调整、新开基站、 传输割接、版本升级、BSC/BTS故障等)?或者在指标差的时间段有哪 些特点(如大型活动、某时间段有特殊的资费政策、话务量过高等)?

GSM常见掉话原因分析

目录 第一章前言 第二章造成掉话的多种原因 一、频率干扰 二、覆盖问题 三、硬件问题 四、其它问题 第三章路测掉话的原因分析及解决 一、关于掉话的描述 1)射频掉话 2)切换掉话 二、在路测时发现的掉话问题时,我们应从哪些方面进行考虑? 三、对掉话现象进行分析以及可能的原因 1)频率干扰 2)缺少邻区&目标小区话务信道拥塞严重 3)覆盖问题(Poor level & Overshooting) 4)有线口的信道释放造成的掉话 5)硬件故障直接导致的掉话 6)BSS参数设置不当 7)切换掉话 8)手机问题 9)交换机参数设置问题 第四章路测中见到的典型的掉话现象 一、频率干扰 二、载频误码率高 三、载频低功 四、同频负切 结束语 第一章前言 在移动通信中,掉话是指在分配了话音信道(TCH)或独立专用控制信道(SDCCH)后,由于某种原因,使呼叫丢失或中断,正常通话无法进行的现象。掉话对系统接通率等指标虽没有重大影响,但却给用户造成许多不便,是目前用户投诉的热点。掉话是用户衡量企业运营质量和水平的重要标志,企业必须予以重视。 道路测试(Driver Test)是优化工作中必不可少的一项工作。测试工程师通过使用测试工具(笔记本电脑、测试软件、测试手机、GPS等)驱车进行通话状态和空闲状态的测试,通过记录下来的各种数据(场强、通话质量、小区参数、手机的瞬时状态等)进行现场或后期的分析,查找并解决网络问题。 随着网络的发展路测的工作方法和工作思路也应该逐步开阔和深入。一直沿用老的办法和固有的思维定式去分析日益复杂的网络问题是越来越难了。我们想通过对过去路测工作中所遇到的掉话问题的总结分析,给大家一个日常工作的指导,另外也希望能够使大家开阔思路,

掉话优化思路

1 网优类 1.1 掉话类 掉话排查总体思路流程图

1.1.1 CS掉话类问题处理流程 现网的掉话监测分成RNC级的掉话与小区级的掉话两个方面,若出现网元大 面积掉话,可能由RNC硬件故障引起。但还有一种情况是全网所有的RNC 掉话率都较高,此时可以考虑可能是由于CN的故障或是由其它系统原因造成, 比如系统升级。

造成RNC掉话升级的原因可以有以下几种: 1. 参数配置错误:这有两个方面参数配置存在问题,一是RNC中的全局参 数配置存在问题,另一方面是由CN中对RNC的参数配置存在问题。 2. RNC硬件故障问题:需要通过对RNC告警的检查以及对RNC日志的检 查来确定是否是由硬件故障引起。 小区级掉话率较高,造成小区掉话的原因较多,主要有以下几种: 1. 干扰造成的掉话:(同频干扰、相关性较强的扰码引起的干扰、导频污 染、上下行交叉时隙干扰、上下行导频间干扰、系统间干扰、其它无线 设置的干扰) 2. 切换造成的掉话:(硬件故障导致切换异常、同频同扰码小区越区覆盖 导致切换异常、越区孤岛切换问题、目标小区上行同步失败导致切换失 败、无线参数设置不合理导致切换不及时) 3. 基站硬件故障造成的掉话 4. 终端问题造成的掉话 5. 链路失衡造成的掉话 6. 参数配置错误造成的掉话 覆盖问题造成的掉话(覆盖空洞造成的掉话、越区覆盖造成的掉话、孤岛效应 导致的掉话、导频杂乱导致的掉话、阴影衰落导致的掉话) 1.1.1.1 RNC级问题处理思路 1. 确定问题小区的分布情况(比如是否集中在同一框的某一单板上)。 2. 出现RNC级掉话后,首先需确定该RNC级的掉话是由多个小区引起的, 还是由个别高掉话的小区所导致。如果是由个别小区引起的,应进行小 区级的掉话处理步骤,否则进入网元级的掉话处理过程。 3. 检查RNC的系统告警,检查是否存在相关硬件的告警信息,如果存在单 板的告警,则需要进行排除。 4. 检查RNC的系统日志,对其中不正常部分进行检查。 5. 检查CT数据中掉话部分的信令,分析其错误代码,常见的RNC级参数 设置错误引起的掉话主要有以下几种:

运维故障处理思路

事件/故障处理应该要有什么思路 导读: 在讲解事件、故障处理思路前,我先讲一个故障场景(以呼叫中心系统作为一 例子): 业务人员反映呼叫中心系统运行缓慢,部份电话在自助语言环节系统处理超时,话务转人工座席,人工座席出现爆线情况。 运维人员开始忙活了,查资源使用情况、查服务是否正常、查日志是否报错、 查交易量还有没有……时间不知不觉的在敲键盘、敲键盘、敲键盘中过去,但 是原因还未定位。 经理过来了解情况:“系统恢复了吗?”、“故障影响是什么?”、“交易中 断了吗?”…… 运维人员赶紧敲键盘,写sql,看交易量;敲键盘,写命令,看系统资源、情况…… 最终,定位到问题原因是其中一个功能没有控制返回数量,导致内存泄露。 针对这个故障,业务希望运维能否更快的解决故障的恢复,经理希望制定优化 呼叫中心故障处理流程,做了以下几件事: 1.优先故障处理过程的时间——”能通过鼠标完成的工作,不要用键盘“ 2.提前发现故障,加强监控——“技术早于业务发现问题,监控不仅是报 警,还要协助故障定位” 3.完善故障应急方案——“应急方案是最新的、准确的、简单明了的” 4.长远目标:故障自愈——”能固化的操作自动化,能机器做的让机器做 “ 下面将从故障常见的处理方法开始介绍,再从故障前的准备工作(完善监控、 制定应急方案等方式)来解决经理提出的问题,并提出未来解决故障的想法。 1、常见的方法: 1)确定故障现象并初判问题影响 在处理故障前,运维人员首先要知道故障现象,故障现象直接决定故障应急方 案的制定,这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。

确认了故障现象后,才能指导运维人员初判断故障影响。 2)应急恢复 运维最基本的指标就是系统可用性,应急恢复的时效性是系统可用性的关键指标。 有了上述故障现象与影响的判断后,就可以制定故障应急操作,故障应急有很多,比如: 服务整体性能下降或异常,可以考虑重启服务; 应用做过变更,可以考虑是否需要回切变更; 资源不足,可以考虑应急扩容; 应用性能问题,可以考虑调整应用参数、日志参数; 数据库繁忙,可以考虑通过数据库快照分析,优化SQL; 应用功能设计有误,可以考虑紧急关闭功能菜单; 还有很多…… 另外,需要补充的是,在故障应急前,在有条件的情况需要保存当前系统场景,比如在杀进程前,可以先抓个CORE文件或数据库快照文件。 3)快速定位故障原因 是否为偶发性、是否可重现 故障现象是否可以重现,对于快速解决问题很重要,能重现说明总会有办法或 工具帮助我们定位到问题原因,而且能重现的故障往往可能是服务异常、变更 等工作导致的问题。 但,如果故障是偶发性的,是有极小概率出现的,则比较难排查,这依赖于系 统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。 是否进行过相关变更 大部份故障是由于变更导致,确定故障现象后,如果有应的变更,有助于从变 更角度出现分析是否是变更引起,进而快速定位故障并准备好回切等应急方案。 是否可缩小范围 一方面应用系统提倡解耦,一支交易会流经不同的应用系统及模块;另一方面,故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时 应该避免全面性的排查,建议先把问题范围缩小到一定程序后再开始协调关联 团队排查。 关联方配合分析问题

掉话专题优化

掉话专题优化 1覆盖引起的掉话 原因分析: ● 服务小区由于各种原因(如无线环境好,功率过高,站点设置太高)产生越区覆 盖,导致UE 在移动到被越区覆盖的小区后,因无邻区关系配置,导致掉话。 ● 越区覆盖导致的频率干扰和扰码相关性问题。 ● 波导效应和湖面效应会使服务小区覆盖过远,引起干扰或切换判断混乱,产生掉 话。 ● 由于孤岛效应,处于孤岛的UE 无法切换出去,产生掉话。 ● 由于一个地方没有一个足够强的主导频,出现导频污染,手机通话过程中,乒乓 切换会比较严重,导致掉话率上升。 ● 两个小区交接部分出现明显的无信号覆盖的漏洞,UE移动出覆盖范围,产生掉话。 ● 由于高大建筑物遮挡产生的阴影效应。 解决措施: ● 消除漂移信号的影响 对覆盖区进行定期路测,查找覆盖不规范的基站,通过调整该站的下倾角,方位 角,或降低它的最大发射功率等方法来优化覆盖区域,同时避免基站天线沿街道或湖 面覆盖,避免街道效应和湖面效应等产生难以控制的信号,消除漂移信号对其它基站的影响. ● 查找覆盖不足的地区 通过用户投诉和路测来查明覆盖不足的地方,看是否可以通过调整下倾角,方位 角,挂高,以及发射功率等方法增大覆盖范围(这需要综合考虑频率、扰码规划以及 其它方位覆盖的情况)。如果弱场区处于商场、隧道、地下停车场、地铁入口、高层建 筑等特殊场合,则需要增加RRU,或室内分布来解决。 ● 排查硬件故障 如果掉话率突然上升,则需要检查本小区和相邻小区此时是否工作正常,通过 OMC-B检查本小区和相邻小区告警,并检查小区各通道输出功率是否正常,排除因为 硬件原因产生的小区功率收缩。 ● 检查邻小区是否定义完整 根据整个网络结构,结合路测情况,在OMC-R 数据库检查是否存在漏配邻区的 情况,特别是不同省市相邻边界处应经常对照相邻小区数据。 2切换引起的掉话 原因分析: 切换原因导致的掉话包括: ● 硬件故障导致切换异常引起掉话; ● 同频同扰码小区越区覆盖导致切换异常引起掉话; ● 越区孤岛切换问题引起掉话。 在环境比较复杂时,由于较近小区的信号阻挡产生一定损耗,而其他小区可能会 从建筑物夹缝中透露出来,形成较强越区孤岛。由于该区域的小区和该越区小区之间 不会互配置邻小区,在干扰没有严重到导致下行失步时,UE 将不会选择到该小区上。 但在服务小区信号较弱时,UE 很可能会重选到该越区孤岛上。当在该小区上通话(建 立其他的DPCH 也是一样)后,将会导致无法切换从而掉话的现象。 ● 目标邻小区负荷过高导致切换失败引起掉话 当目标邻小区的负荷过高时,切换将无法完成。另外,当目标小区的部分传输通

航天生产系统改进思路思考

航天生产系统改进思路的思考 摘要:本文通过对军工体制调整、任务变动趋势、航天生产特点等背景材料的分析,阐述了进行生产系统改进的必要性和迫切性;针对现有生产系统存在的不足,提出了主要的改进方面的建议及相应的意义和作用;根据单元化生产的思想,介绍了生产系统改进的思路;为保证以单元为特点的生产系统的有效运行,提出了主要的配套机制建议。 关键词:单元化;生产系统;改进 我国的航天事业经历多年发展,取得了辉煌的成就,尤其是近年来成功实现了载人航天和深空探测,在国际上取得了相对优势。然而面临军工研制体制调整的大环境、建设航天科技工业新体系的新要求、以及现有生产能力不能完全满足型号任务增长需要的现实情况,要求航天企业积极应对、提前筹划,强化危机意识,立足长远发展,因此基于企业现状,如何应用先进制造的技术方法和管理手段,对企业生产系统进行合理调整和改进,挖掘生产潜力、扩大生产能力、提高生产效率、提升快速响应能力、增强企业核心竞争力成为必须面对的课题。 本文通过对军工体制调整、任务变动趋势、航天生产特点等背景材料的分析,阐述了进行生产系统改进的必要性和迫切性;针对现有生产系统存在的不足,提出了主要的改进方面的建议及相应的意义和作用;根据单元化生产的思想,介绍了生产系统改进的思路;为保证以单元为特点的生产系统的有效运行,提出了主要的配套机制建议。 一、生产系统改进的背景分析 (一)适应军工研制体制调整,迎接国内外竞争挑战 航天是我国军工体系的重要组成部分,其成长和发展始终依赖于国家的扶植和支持,得益于我国军工研制体制的成功运行。为了适应改革开放的持续深入,更好的服务于国家的国防需要、经济建设和社会发展,我国军工体制面临重大调整。在已发布的对我国国防科技体制和军工企业发展具有战略性指导意义的多项规划和纲要中,能够归纳出军工研制体制调整的目标和基本方向,体现在以下方面: ●目标调整: 加快国防科技工业转型升级,建设模式由任务型向任务能力结合型转变:把完成武器装备科研生产任务与能力建设有机结合起来,在完成国家任务的同时,不断提高自身发展能力,实现平稳、协调、可持续发展,全面推进任务能力结合型军工建设。对于航天领域,要求推进航天产业由试验应用型向业务服务型转变,发展通信、导航、遥感等卫星及其应用,形成空间、地面与终端产品制造、运营服务的航天产业链。 ●体制调整: 建设和完善军民结合、平战结合、军民共用、寓军于民的机制:深化国防科研体制改革,促进军民科技资源统筹配置、有效共享;加强军民结合的统筹和协调,改革军民分离的科技管理体制,加强军民两用技术研发和产品开发,促进军用和民用科技的双向转移以及军民两用技术的产业化;

质量问题分析与解决思路

质量问题的分析与解决思路 所谓品质管理,就是过程管理中,处理异常的事情,而正常的事情不需要加以管理。管理者就是要工作现场出现问题时,能及时、有效的排除异常问题。企业工作现场的活动是很复杂的,其中可能包含了很多繁琐的流程。因此,在工作现场将会遇到很多方面的问题。 管理者在对问题的理解上会有不同的意识差别,现状与目标或预期的差别。 企业各级管理人员的日常工作重点就是推进课题改善,通过有预见性地发现问题、分析与解决问题,消除日常管理中的主要障碍,推动企业业绩的提升。 解决问题的过程就是提高能力的过程,问题就是机会,是改进的机会,是教育当事人及员工的机会。有了这样的问题意识,管理人员就能利用每一次解决问题的过程,提高自身管理能力,同时提高企业经营绩效水平。 通常的解决方法往往只是解决表面问题,经过一段时间,问题又可能重复发生。 例如,发生重大事故时企业就将所有的管理人员集中在一起开会,讨论了很长时间才拿出临时改善方案,到最后却发现问题依然存在。这是好多企业都面临的的现实问题。 实际上,很多管理人员并没有仔细地分析问题,没有意识到问题产生的根源,采取的措施常常过于表面化,而不能使问题得到真正的、实质性的改善和解决。 例如,当产能不够时,往往是因为能利用率不高所造成的,直接增加作业人员并不会对产能利用率的提高有任何改善。正确的方法应是在招聘作业人员时就事先注意择优录用,优秀的作业人员的个人绩效高,企业能最大限度地发挥这些作业人员的技能,整体的产能自然也就可能得大大提高。所以企业管理人员必须了解问题的结构,学会系统思维的方法,运用各种分析手法和工具,熟悉解决问题的流程,方能真正有效遏制问题的发生,从根源上有效解决问题。 想必大家都知道“冰山原理”,它是美国作家海明威创作的方法和艺术风格,他认为:一部作品好比一座冰山,露出水面的是1/8,而有7/8是在水面之下,写作只需表现“水面上”的部分,而让读者自己去理解“水面下”的部分。问题的结构有如冰山一般,通常工作人员或管理人员只能发现一些问题的表面现象,所以要求相关人员在面对问题和改善问题时应该具备系统思维能力,包括逻辑思维,推理思维,系统思维和创造性思维等能力。只有运具备了系统思维的能力,才能发现问题的根源,运用行之有效的工具和手法,从治本的角度有效地改善问题,防止问题的发生和再发生。这就是在8D工作方法中为什么会存在“防止问题再发生措施”这一项了。当然逻辑思维也是在解决问题时不可缺少的一种思维方式。 利用专业标准发现问题。 例如:在IE工业工程技术中有一个专业标准,一般来说,生产线的平衡损失率在5%--15%以内是可以接受的,否则就要进行改善。我们可以通过线性平衡分析评价班组的工序能力状态,找到瓶颈进行改善。 工作就是不断发现问题,分析问题,最终解决问题的一个过程。工作中遇到问题,积极的人

关于某xxx公司管理系统高质量管理系统体系改进计划清单方案设计

XXX菌物科技股份公司质量管理体系改进计 划方案 一、指导思想 为进一步落实ISO9001-2008和ISO22000-2005管理体系,严格执行其相对应的条款,根据公司实际情况,建立和完善公司质量与食品安全管理机制,增加全员有效控制潜在风险因素的能力,从而全面提升公司经营管理体系的整体建设。 二、目前质量管理体系现状 近期,公司部组织各条线管理体系检查和外部认证机构对公司质量管理体系(包括ISO22000)进行复审,反映出目前公司质量管理体系存在比较严重问题的基本情况。无论是公司部检查,还是机构复审,可以将问题归类为以下几个方面: 1、质量管理意识淡薄。在检查和复审过程中,在公司各级员工中,普遍不知道公司的质量方针和质量目标,尤其是中高层管理人员对于其所担负的质量管理职责不清楚,各条线对于如何运用和执行质量管理体系所涉及的流程和控制方法基本不知道。此类现象需要引起公司高度重视。 2、质量管理组织机构僵化。目前公司成文的质量管理机构尚是2011年构建,没有及时随着公司经营管理机构的调整进行优化,存在严重职责分工缺失的问题,单纯地认为质量管理体系就是品保部部

门的责任,没有放在公司运营管理层面进行考虑设置,尤其是管理中心的企管职能没有强化其核心作用。 3、质量管理体系的了解和掌握存在严重缺陷。通过部检查和机构复审,公司大多数人员不熟悉质量管理体系的基本知识,缺少专业知识的管理人员,同时,存在对质量管理体系和整个公司的经营管理体系关系的认识不清问题,甚至,在公司高层管理人员存在以质量管理体系覆盖整个公司经营管理的误区。 4、质量管理体系文件滞后。无论是质量手册、程序文件、作业指导书及记录表单,都或多或少存在形式与容不一致的问题,形式主义严重,基本上是拿来主义,基本上没有结合公司实际情况考虑文件的有效性和符合性;在文件的管理上,更是如此,无论是文件的发放、修正、存档等,除了技术研发、品保部和生产中心做到部分要求,公司其它部门基本没有相应的程序文件和作业指导书,只是几个记录表单而已。 5、质量管理执行监管严重缺失。在机构复审时所反映出来的41个问题,除了体系本身的问题外,如产品的检验标准不明确等,更为关键的是公司对质量管理体系执行是盲目和被动的,缺少应有的质量全面主动的检查活动机制,尤其缺少对一线的质量体系实际情况的经常性检查,没有在公司层面设置质量管理体系策划与控制管理安排;同时,对于日常工作中所暴露出来的问题,没有采取有效的分析和纠正预防措施,以致问题重复出现。

经典案例-VoLTE掉话问题处理思路与优化方法

VoLTE掉话问题处理思路与优化方法VoLTE掉话问题处理思路与优化方法

目录 VoLTE掉话问题处理思路与优化方法 (1) 1概述 (3) 2VoLTE掉话率问题定界排查 (3) 2.1VoLTE掉话问题定界思路 (4) 2.2VoLTE掉线率TOPN小区定位排查思路 (5) 3VoLTE掉线信令流程以及相关指标 (6) 4VOLTE掉话无线问题优化方法 (7) 4.1由于ENB的无线链路失败 (7) 4.2由于ENB重建立失败 (9) 4.3由于小区关断或复位 (11) 4.4ENB由于S1链路故障发起释放 (11) 4.5由于UE切换失败 (14) 4.6由于UE不在线导致释放 (14) 4.7由于ENB小区拥塞导致的释放 (14) 4.8由于ENB过载控制导致的释放 (14) 5VOLTE掉话处理案例 (15) 5.1邻区漏配导致的掉话问题处理案例 (15) 5.2弱覆盖导致的掉话问题处理案例 (18) 5.3切换失败导致的掉话问题处理案例 (19) 6总结 (20)

1 概述 目前萍乡电信VoLTE商用在即,VoLTE作为LTE网络实现语音通话的最终方案,用户对VoLTE高清语音的需求将越来越大,但目前由于电信Volte没有实现弱覆盖情况下的异系统切换,所以在弱覆盖区域存在较大的掉话风险。伴随着网络规模的进一步扩大以及网络结构的日渐复杂,处理VoLTE的掉线问题即将成为日常网络维护中一项重要的工作。本文通过研究VoLTE掉话问题定位及处理方法,主要从无线链路失败、切换失败、拥塞等方面展开分析,并总结VoLTE掉话问题处理优化经验。 2 VoLTE掉话率问题定界排查 VoLTE掉话率指在移动通信的过程中,终端在VoLTE的通信意外中断的几率。 在信令监测平台上,VoLTE掉话指标取自于Rx接口和Mw接口,公式如下: VoLTE语音掉话率=VoLTE语音掉话次数/((VoLTE语音始呼应答次数+VoLTE语音终呼应答次数)) VoLTE语音掉话次数指SBC(不区分主叫域和被叫域)收到PCRF发送媒体类型为语音的ASR(下图消息1)的次数,且ASR中Abort Cause为“PS to CS Handover”不含在内。如下图所示: 信令监测指标判断应答次数在Mw口统计,掉话次数在RX口统计,有ASR/ASA 消息(会话中断消息)且ASR消息中携带的abort cause值不为3(3 表示ESRVCC切换)。信令

山西电信cdma网络掉话问题专题山西案例

中国电信CDMA网络掉话问题专题 张玉亮 (中国电信山西分公司无线网优中心) 【摘要】:随着移动通信业务的迅速发展,用户对网络质量的要求也越来越高,运营商对网络的管理也从对信号覆盖的定性要求转变为对网络性能指标的定量要求。而网络掉话既是反映网络性能的一项重要指标,也是影响用户对网络使用感受的重要因素。本文根据作者在网络优化过程中处理掉话的经验,结合路测和话统数据分析造成掉话的各种原因。 分析其掉话原因,主要发生在以下四种情况下:(1)切换掉话,主要是由于邻居关系的缺失或搜索窗大小设置不当;(2)干扰掉话;(3)覆盖弱掉话;(4)导频污染掉话。 【关键词】: PN 搜索窗TEK YBT250 掉话率等。 CDMA2000标准中只定义了手机的掉话机制:(1)手机连续收到12个错帧,停止发射功率。(2)手机连续收到2个好帧,开启发射功率、衰落定时器清零。(3)手机收到错帧开启衰落定时器(时长5S),衰落定时器到时后掉话。 主要发生在以下四种情况下:(1)切换掉话,主要是由于邻居关系的缺失或搜索窗大小设置不当;(2)干扰掉话;(3)覆盖弱掉话;(4)导频污染掉话。 1、切换掉话 1.1由邻区参数设置不当引起的掉话 1.1.1由于地型问题_漏配邻区引起的掉话 掉话前主导频为市区农机公司CELL0、CELL2小区,导频分别为39、375。由于此处的掉话位置地型较低,在掉话前激活集中一直只有PN39、375导频做主导,MS检测到北阎庄PN57大于T_ADD,并且上报了PSMM消息,但由于市区北阎庄CELL0未将市区农机公司CELL0、CELL2小区配置成邻区,导致基站不能下发HDM消息,手机未切换至北阎庄PN57形成强干扰,随着PN39的不断衰落FER达到100%,此时MS与基站基本上已经断链,造成掉话。详见下面前台测试与后台数据配置图:

水电站自动控制系统的设计及改进思路研究

水电站自动控制系统的设计及改进思路研究 【摘要】在科学技术的不断发展过程中,人们对电力系统的可靠性以及自动化程度的要求越来越严格,对此文章主要对水电站自动控制系统进行了改造,希望可以提升整个水电站的安全性、稳定性,进而增强其整体的经济价值与效益。 【关键词】水电站;自动控制系统;设计及改进;思路研究 水电站自动控制的主要目的就是要保障水电站水轮发电机组的可靠性、稳定性、运行的安全性,保障整个水电站区域电网以及电网运行的稳定性以及安全性,真正的实现水电站的“无人值班、关门运行”的效果。 1、水位监测系统 在发电系统中,不仅仅需要电气数据,也需要传感器,这样才可以实现对其他相关数据进行的有效测量。但是在多数的水电站中并没有远程的水位监测系统,没有实现与导叶开度的联控,同时在电网允许的状况之下,其整体的来水量要小于发电用水量的时候,发电机组单位水量的发电量就会显著下降;其来水量高于发电的用水量的时候,整个发电机组则没有实现全负荷的运行,导致其多余的水量被浪费掉,直接的降低了用户的整体经济效益。 而水位监测系统在实践中主要就是通过具有高度的可靠性以及高分辨率的智能化的仪表开展作业,可以实现持续的、无间断的对前池液位的实际变化数值的采集,在通过通讯以及远传信号将其传送到自动化控制的系统中使其完成量化以及智能化的计算,这样就可以为导叶的开度以及机组的运行数量提供较为重要的数据信息支撑。 2、水轮机转速测量系统 在传统的水电站自动控制系统中并没有水轮机转速测量的控制系统,直接导致其转速并不是

稳定的状态,同时因为励磁系统为恒磁场运行模式,导致整个供电站的服务质量相对较低。水轮轮转速无法及时有效的检测,如果在一些失磁以及電网负荷出现剧变的状况之下,就会导致较为严重的安全隐患问题。 现阶段我国对于电力系统的正常频率标准进行了规定,而水轮机转速与发电的频率有着直接的关系。稳定、可靠的转速测量可以为电网提供较为稳定的支持。转速在整个发电系统中有着重要的作用,在整个发电系统的启动、停机以及运行过程中有着积极的作用与影响。在启动的过程中,合适的转速就会可以稳定电压,保障电网的稳定性。在运行过程中,可以直接的反应其实际的负荷变化状况,进而有效的避免出现飞车问题。而在停机的过程中,转速测量数值可以为手动制动动飞轮提供相关数据支撑,加强对导叶控制机构的管理,进而做到自动关闭导叶,提升整体操作的安全性。 3、励磁调节系统 在传统的控制中并没有自动的励磁调节系统,无法基于电网与机组的实际状况的变化而产生变化,无法保障其整体的功率比,进而导致供电功率因数无法满足实际的电网需求,导致其供电质量的降低,考核标准无法达标。 励磁系统是整个发电机机组中较为关键的调节设备,其主要技术就是选择合适的励磁装置。将原有的恒磁场励磁力方式变为磁场自动励磁。只要通过一键启动的方式就可以实现励磁控制的全自动,可以真正的实现无人值守。 4、导叶开度控制系统 导叶的开度控制系统在实践中可以与水位监测、智能采集、励磁等相关系统可以实现共同的联动,可以在出现水头、负载、机组运行状态等变化中对其进行及时的调整,进而保障整个机组的安全性、稳定性以及高效性。在实践中基于经济性的基础原则,可以通过三相异步交流电动机作为主要的执行机构,而三相电就是利用电源切换开关的方式对电网电源的状况进

相关文档
最新文档