KPI指标提升案例.doc

起呼问题的处理流程： 信号快衰造成未接通： 【事件描述】 国力大酒店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间切换。 IMSI UNKNOWN IN VLR导致未接通 【事件描述】 车辆由南向北行驶在丰谭路上，在丰谭路左转至天目山路路口处，主叫UE由亚洲城2(40701)重选至国力大酒店2(40262)，未能及时进行位置更新即起呼，造成CM SERVICE REJECT，cause为IMSI UNKNOWN IN VLR。 主叫路测截图 【事件原因】 该用户在其他的Server上做了位置更新，且HLR通知了本Server删除掉用户数据。由于该用户没有在本Server上做位置更新，也就是说，本Server上是没有该用户的数据的，所以当该用户在本Server上发起呼叫时，核心网直接拒掉，拒绝原因值为”IMSI Unknown in VLR”。 【解决措施】 关于该问题，核心网的MAP功能配置里有个选项可以解决此问题： 该开关的说明如下： IFVLRLU 支持主叫无用户数据时发起独立位置更新操作 当漫游到本局的移动用户向网络发起主叫业务接入请求时，如果MSOFTX3000在向本局VLR查询该移动用户的用户数据时发现该数据处于“未证实”状态，该参数用于指示MSOFTX3000是否重新发起位置更新操作以获取用户数据，系统初始设置值为“不支持”。对于上述情况下的呼叫，若将该参数设为“不支持”，则MSOFTX3000将直接拒绝该移动用户的业务接入请求；若将该参数设为“支持”，则MSOFTX3000将重新发起位置更新操作以获取该移动用户的用户数据、在获取用户数据后将继续接续本次呼叫。 使用的效果如下： 若将该参数设为“是”，则当移动用户向网络发起位置更新请求时，如果正常的由HLR执行的位置更新操作出现失败的情况，MSOFTX3000可以直接通过VLR继续执行位置更新流程。”IMSI Unknown in VLR”的现象，则本次呼叫不会直接拒绝掉，而是由VLR发起一次位置更新，位置更新成功后，呼叫继续，确保了用户可以正常接入。 因此，该参数的修改是可以提高AMR和VP的接通率的。 注：此开关的打开只适用于华为的交换，此开关的打开可能会带来充值出错、串话的问题，此开关的打开要慎重，此可以在集团测试期间打开即可 2/3G位置更新导致主叫未接通 【事件描述】 测试车辆沿文二西路由西向东行驶，UE在西湖区政府服务中心2（频点：10096 ，扰码：67）起呼成功，进入振铃状态，持续20秒钟未与被叫建立通话，导致主叫未接通。 【事件原因】 通过对主被叫信令分析知，在起呼的过程中，被叫正在从GSM重选回TD，未完成位置区更新导致收不到网络侧下发的Paging消息导致起呼失败。 【解决及规避措施】 增强覆盖，较小23G重选和切换