KPI指标提升案例Word格式.docx
- 文档编号:20692142
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:19
- 大小:1.24MB
KPI指标提升案例Word格式.docx
《KPI指标提升案例Word格式.docx》由会员分享,可在线阅读,更多相关《KPI指标提升案例Word格式.docx(19页珍藏版)》请在冰豆网上搜索。
被叫在源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,能提高寻呼成功率。
手机发送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:
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:
15,两次的时间间隔是43秒。
详细如下:
被叫信息
UE原因,导致UE没有及时解读出系统消息。
GSM协议错误导致主叫未接通
车辆由东向西行驶在南山路上,主叫UE占用GSM小区10261,RxLev=-88,RxQual=6,指配TCH过程中,UE上发AssignmentFailure,原因为Protocolerrorunspecified。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- KPI 指标 提升 案例