KPI指标提升案例.docx

KPI指标提升案例.docx

《KPI指标提升案例.docx》由会员分享，可在线阅读，更多相关《KPI指标提升案例.docx（19页珍藏版）》请在冰豆网上搜索。

KPI指标提升案例

起呼问题的处理流程：

Ø信号快衰造成未接通：

【事件描述】

国力大酒店3小区在丰潭路上有快衰现象，在该路段国力大酒店3小区信号迅速衰减至-90dBm，造成起呼失败。

信号快衰导致重选不及时

【解决措施】

现场调整国力大酒店3小区的机械下倾角由原来的6°→10°

【优化结果】

调整之后在丰潭路复测多次，此问题路段已不会切至国力大酒店3小区。

调整后切换关系图

Ø

跨RNC迁移时，被叫connect消息没有直传导致未接通

【事件描述】

在中河北路上，主叫呼被叫，被叫响应寻呼。

22：

33：

26，被叫向网络侧发起connect消息时，被叫正在从同发财富1小区跨RNC迁移到文苑宾馆2小区，被叫connect消息不能直传到CN而导致主叫未接通。

被叫路测截图

被叫在源RNC上没有上报connect直传消息，如下：

被叫在目标RNC上没有上报connect直传消息，如下：

【事件原因】

在起呼过程中，主被叫完成RAB建立，但是被叫发生了跨RNC切换，被叫在目标RNC发出送的connect消息，主叫在源RNC收不到CN下发的connect消息。

【解决措施】

需针对RNC边界进行优化（也即进行LAC区优化）。

RNC规划的推荐原则：

在规划RNC区时，需要尽可能的利用环境因素，减少RNC间的信令/数据流量，避免出现频繁的跨RNC间切换。

（注：

此种情况一定要注意，像杭州一个RNC一个MSC出现频繁的跨RNC重选或切换会带来主叫在起呼过程中RAB建立完成发生切换至另外一个RNC导致收不到被叫发送的connect而导致未接通）

如果存在两个以上的RNC区，在高话务的大城市，可以利用市区中山体、河流等地形因素来作为RNC区的边界，减少两个RNC区下不同小区的交叠深度。

如果不存在这样的地理环境，RNC区的划分尽量不要以街道为界，边界不要放在话务量很高的地方（比如商场）。

一般要求RNC区边界不与街道平行或垂直，而是斜交。

在市区和城郊交界区域，一般将RNC区的边界放在城郊区域外围一线话务量相对小的基站处，而不是放在话务密集的城郊结合部，避免结合部用户出现频繁的跨RNC间切换。

ØIMSIUNKNOWNINVLR导致未接通

【事件描述】

车辆由南向北行驶在丰谭路上，在丰谭路左转至天目山路路口处，主叫UE由亚洲城2（40701）重选至国力大酒店2（40262），未能及时进行位置更新即起呼，造成CMSERVICEREJECT，cause为IMSIUNKNOWNINVLR。

主叫路测截图

【事件原因】

该用户在其他的Server上做了位置更新，且HLR通知了本Server删除掉用户数据。

由于该用户没有在本Server上做位置更新，也就是说，本Server上是没有该用户的数据的，所以当该用户在本Server上发起呼叫时，核心网直接拒掉，拒绝原因值为”IMSIUnknowninVLR”。

【解决措施】

关于该问题，核心网的MAP功能配置里有个选项可以解决此问题：

该开关的说明如下：

IFVLRLU

支持主叫无用户数据时发起独立位置更新操作

当漫游到本局的移动用户向网络发起主叫业务接入请求时，如果MSOFTX3000在向本局VLR查询该移动用户的用户数据时发现该数据处于“未证实”状态，该参数用于指示MSOFTX3000是否重新发起位置更新操作以获取用户数据，系统初始设置值为“不支持”。

对于上述情况下的呼叫，若将该参数设为“不支持”，则MSOFTX3000将直接拒绝该移动用户的业务接入请求；若将该参数设为“支持”，则MSOFTX3000将重新发起位置更新操作以获取该移动用户的用户数据、在获取用户数据后将继续接续本次呼叫。

使用的效果如下：

若将该参数设为“是”，则当移动用户向网络发起位置更新请求时，如果正常的由HLR执行的位置更新操作出现失败的情况，MSOFTX3000可以直接通过VLR继续执行位置更新流程。

确保了UE进行重新登记。

即：

如果遇到”IMSIUnknowninVLR”的现象，则本次呼叫不会直接拒绝掉，而是由VLR发起一次位置更新，位置更新成功后，呼叫继续，确保了用户可以正常接入。

因此，该参数的修改是可以提高AMR和VP的接通率的。

注：

此开关的打开只适用于华为的交换，此开关的打开可能会带来充值出错、串话的问题，此开关的打开要慎重，此可以在集团测试期间打开即可

Ø2/3G位置更新导致主叫未接通

【事件描述】

测试车辆沿文二西路由西向东行驶，UE在西湖区政府服务中心2（频点：

10096，扰码：

67）起呼成功，进入振铃状态，持续20秒钟未与被叫建立通话，导致主叫未接通。

【事件原因】

通过对主被叫信令分析知，在起呼的过程中，被叫正在从GSM重选回TD，未完成位置区更新导致收不到网络侧下发的Paging消息导致起呼失败。

【解决及规避措施】

1.增强覆盖，较小23G重选和切换次数

2.如果是华为交换可以采取以下的方法来进行规避

✧将TD同GSM割接到同一个目标交换上（在同一个MSC下，TDRNC的覆盖区域同GSM的BSC覆盖区域一致）

✧打开CN侧软参P1100Bit1

含义解释：

控制是否启动位置更新与寻呼同时进行，以提高寻呼成功率。

如果位置更新失败、或者是位置更新过程有手机发送的followon消息，则寻呼失败。

=0：

启动。

=1：

不启动。

默认值：

1。

应用场景场景1：

当手机在进行位置更新，这个时候该手机做被叫；设置该该软参bit1值为1，则该手机做被叫失败，呼叫不能接通；设置该软参bit1值为0，MSCServer会在手机位置更新完成后，下寻呼接通呼叫。

场景2：

当手机做被叫时，开始位置更新。

设置该软参bit1值为1，则该手机做被叫失败，呼叫不能接通。

设置该软参bit1值为0，MSCServer会在手机位置更新完成后，下寻呼接通呼叫。

设置该软参bit1值为0，能提高寻呼成功率。

注：

手机发送followon的场景是用户在按键拨号的时候，手机自动发起位置更新。

这个时候手机会发送followon消息，通知MSCServer，让后续的呼叫接通。

修改脚本：

修改P1100Bit1为0

MODMSFP:

ID=P1100,MODTYPE=P1,BIT=1,BITVAL=0;

✧2、针对3G位置区增加寻呼策略

功能说明：

目前现网2G寻呼策略为寻呼2次，间隔4S，而3G向2G进行小区重选过程中，重选时间较长，超过4S，导致第一次寻呼无响应，此时可适当增加第一次寻呼时长解决，修改为6S。

修改脚本：

增加3G位置区寻呼策略

ADDPGCTRL:

LAI="46000D505",TYPE=ALL,TIMES=2,FIRSTD=6,SECONDD=4,IMSI=FIRST-0&SECOND-0,ALLRAN=FIRST-0&SECOND-0;

ØUPPCH存在干扰导致起呼失败

【事件描述】

现场工程师在路测过程中，发现某个小区无法正常建立业务；该小区在多次呼叫中，均失败，从前台路测仪看，UE上报4条RRCCONNECTREQUEST消息后接收系统消息，后台信令跟踪没有任何信令。

【事件原因】

从现场的测试反馈来看，起呼失败的原因为UE发送的RRCCONNECTREQUESTRNC收不到，导致起呼失败，从现场判断初步怀疑是UP收到干扰，从后台查询该小区的UPPCHISCP为－92dbm，存在一定的干扰。

UP存在干扰导致UE无法同NODEB进行上行同步,，虽然路测仪上出现RRCCONNECTREQUEST消息，是UEL3吐在路测仪上的，实际是没有发送的。

上行同步的流程如下：

【解决及规避措施】

采用upshifting技术，将UP位置从“0”调整为“22”。

修改命令：

MODUPPCH

UP位置调整后，通过查询UPPCHISCP为－108dbm,现场测试起呼正常。

Ø上行ISCP设置较小导致起呼失败

【事件描述】

现场工程师在路测过程中，发现在某小区下信号质量良好（PCCPCHRSCP=-65dbm,C/I=10db）起呼过程中RRC连接建立出现大量的超时，从路测仪上看UE发送RRCconnectcomplete后直解接收系统消息导致RRC建立失败，从后台的信令跟踪看，RNC没有收到UE发送的RRCconnectcomplete。

【事件分析】

✧从现象看，是NODEB无法解调UE发送的RRCconnectcomplete消息，初步怀疑是该小区上行存在干扰或上行发射功率过小。

✧后台查询该小区TS1、TS2的上行ISCP为－109dbm，正常不存在干扰。

✧通过现场的拨测发现，UE在发送在RRCconnectcomplete消息是UE的发射功率为－35dbm，发射功率过小。

✧上行开环功率计算UE的发射功率的公式如下：

UE的初始发射功率＝initialSIRtarget+UL_ISCP+UL_Margin+Lpccpch（路损）

通过后台的查询LDM中ISCP测量是关闭，在计算上行初始发身功率时采用后台上行ISCP设置，查询得默认ISCP=-1000dbm,UL_Margin=3db,Lpccpch＝115，通过查看参数设置上行的ISCP设置过小

【解决及规避措施】

通过前期的测试上行ISCP一般设置为－90dbm，最好是打开LDM中上行ISCP的测量（命令：

ADDCELLLDM），打开测量计算上行的发射功率更加准确一点，通过参数调整后，现场拨测起呼成功率为100％。

【总结】

针对接通率指标的提升，有以下几个问题需要注意：

ØLAC区、RNC边界的合理划分

Ø良好的覆盖（包括切换合理），尽量较少23G的互操作次数和重选次数

Ø上行功控参数的合理设置

Ø空口质量良好（PCCPCH>-90dbm,C/I>0），杜绝紧密邻区出现同频

Ø故障站点的及时排障

现网中造成掉话的主要原因包括：

弱覆盖导致的掉话、切换失败导致的掉话（尤其是同频切换）、异系统切换失败导致的掉话、干扰掉话（包括系统内、系统间干扰）、邻区漏配、SRB复位等原因

掉话分析流程如下：

Ø未及时重选导致掉话

【事件描述】

时间：

20：

20：

12，UE由南向北行驶在石祥路上时，右转到上塘路时，刚好完成上次呼叫，UE没有重选至G网小区重选到瓜山造纸3小区，而选到信号较差的名城左岸1小区后起呼，被叫UE在收到寻呼消息时,PCCPCHRSCP在-105dbm左右,C/I-10db。

被叫UE掉话。

【事件原因】

UE因为没能由G网小区重选到最佳T小区，导致UE占用信号较弱小区起呼，导致掉话。

（UE占用G网小区，重选到T网前）

（UE由G网重选回T网，没能重选到最佳的小区）

【解决措施】

通过调整覆盖避免重选后占用小区信号过弱

Ørelease-due-to-utran-generated-reason导致掉话

【事件描述】

11:

26:

45，UE由西向东行驶在凤起路上，UE占用五鑫大酒店3小区信号，切换到1小区后，主叫UE掉话。

【事件原因】

查看RNC侧信令IU-release，其原因值为：

release-due-to-utran-generated-reason。

主叫UE图

RNC信令图

Ø

先报1g后报2a导致掉话

【事件描述】

1:

24:

57，车辆由西向东行驶在机场高速上，车辆路过宁新村基站，主叫占用宁新村3（52252）进行起呼，起呼时RSCP=-75，RAB指配完成后，RSCP=-96，同频切换至较远的新中村1（2888），造成掉话。

【事件原因】

1g切换判决先于2A发送，导致首先触发1g事件未至最优小区宁新村2（42252）。

UE测试图

【解决措施】

1，更换同频小区的频点

2，调整1g事件触发门限为8

23G切换失败

ØLAC漏配导致2G3G互操作中2G到3GPS域业务切换失败问题分析

【事件描述】

在某TD商用网与GSM网络互操作测试中，我们发现在某一基站下，2G到3G网络的重选和3G到2G的重选，以及3G到2G的PS域业务的切换都成功了，但是在2G到3G的PS域业务切换中发生了异常。

测试所用的手机为大唐DT8120，软件为NTAS Professional Tester 2.2.0.630版。

经检查，软件和手机功能正常，排除设备问题。

因此怀疑网络参数配置问题。

【事件原因】

1.首先我们要了解在PS域业务切换过程中，终端在收到切换命令后，使用重选过程来辅助PS业务的切换，之后进行相应的位置区更新和路由区更新，最后进行用户面的业务恢复。

2.在软件信令图中我们看到了Location Updating Accept，说明位置区更新成功，由于位置区更新是在目标MSC中进行，所以我们排除3G MSC中参数配置错误的可能性。

3.之后UE目标RNC、核心网建立信令连接，并触发路由区更新。

此时发生路由区更新失败，路由区更新是3G-SGSN与UE之间建立的，因此我们问题定位在3G SGSN核心网侧。

【解决措施】

与3G SGSN工程师沟通后确认3G漏配了对应2G邻区的LAC导致身份认证操作失败，路由区更新被拒绝，3G SGSN补全数据配置后路由区更新成功。

Ø2G邻区中频点配置错误导致TD至G网无法切换

【事件描述】

在簇18进行PS业务2G3G互操作测试时，在TD信号已达到-95dB以下时，网络侧已下发3A测量控制，但手机迟迟不发3A测量报告，依然无法切换。

【事件原因】

1、开始出现此现象时在路测软件上没有看到2G邻区，立即联系后台维护人员，经确认，邻区已添加；行驶十几米后，路测软件和手机显示确有2G邻区。

2、尝试在旁边的另外一个小区进行相同测试，问题依然存在，排除是偶然现象的可能；

3、后来发现一个规律，在路测软件上显示的2G邻区只有一个，且频点一直是93（BCCH），通过观察信令log，发现在3A的测量控制中的2G信息中NCC、BCC几次都在变，只有频点一直为93。

可以肯定，后台在配置2G邻区时频点配置错误。

后与后台维护人员联系确认，在配置2G邻区时将同RNC所有频点都错配为93。

导致手机无法测量频点为非93的2G邻区。

【总结】

针对3G2G切换成功率提升需要以下几点：

Ø配置合理的2G邻区

Ø配置的2G邻区的总数不能超过8个

Ø针对失败的切换点要同2G人员共同测试，如果手机的版本不存在问题，一般

3G2G切换失败都是由于没有切换至最优的2G小区或2G小区存在问题。

Ø被叫43秒钟没有读取广播信息，没有响应寻呼

【事件描述】

10：

40：

06，在胡墅南路上，从北向南，在物资大厦1，主叫呼被叫，被叫43秒钟没有读取广播信息，没有响应寻呼。

主叫信息

被叫第一次解析出“SB1”消息的时间是10：

39：

32，被叫第二次解析出“SB1”消息的时间是10：

40：

15，两次的时间间隔是43秒。

详细如下：

被叫信息

【事件原因】

UE原因，导致UE没有及时解读出系统消息。

ØGSM协议错误导致主叫未接通

【事件描述】

车辆由东向西行驶在南山路上，主叫UE占用GSM小区10261，RxLev=-88，RxQual=6，指配TCH过程中，UE上发AssignmentFailure，原因为Protocolerrorunspecified。

UE测试图

被叫信息

【事件原因】

UE原因，导致UE没有及时解读出系统消息。