《CDMA项目典型案例总结（第一期）》由会员分享，可在线阅读，更多相关《CDMA项目典型案例总结（第一期）（28页珍藏版）》请在金锄头文库上搜索。
1、Reliance CDMA 搬迁网优工作计划2018-1-11 第 1 页 , 共 28 页1CDMA项目典型案例总结第一期2018 年 1 月Reliance 项目疑难问题总结（第一期）2018-1-11 第 1 页 , 共 28 页目 录1 接入问题总结 .21.1 64号基站忙时Abis资源不足导致指配资源失败问题（高林祥） .21.2 呼叫建立时A1接口失败问题（凌太兵） .41.3 A1接口失败问题（姜伟） .51.4 直放站下起呼困难问题（田延峰） .81.5 割接后149号基站无法打电话（陈世进） .92 切换问题总结 .112.1 Inter Vendor同频硬切换失败系列问题
2、定位（凌太兵） .112.1.1 Inter Vendor同频硬切换失败问题定位 1 .112.1.2 Inter Vendor同频硬切换失败问题定位 2 .112.2 两基站无法软切换问题（陈世进） .123 掉话问题总结 .133.1 252、309号站Abis接口异常掉话问题（高林祥） .133.2 47号站Abis接口异常掉话问题（凌太兵） .154 拥塞问题总结 .164.1 Kanpur BSC1 指配资源失败问题（姜伟） .165 其他问题总结 .205.1 DTMF检测开关打开导致手机扬声器自动开启（高林祥） .205.2 LG手机自动重启问题（凌太兵） .225.3 三方通话
3、异常问题（高林祥） .255.4 割接后主被叫全部静音问题（姜伟） .255.5 C506手机空闲态搜网问题（田延峰） .266 下期内容： .27Reliance 项目疑难问题总结（第一期）2018-1-11 第 2 页 , 共 28 页CDMA项目典型案例总结第一期1 接入问题总结1.1 64 号基站忙时 Abis 资源不足导致指配资源失败问题（高林祥）【现象描述】Kanpur BSC1 64号站(S2/2/2) 基站搬迁以后，该基站3个扇区呼叫建立成功率在晚忙时(18:0022:00) 仅仅为50% 左右，软切换成功率仅仅为60%左右，但掉话率指标12%。呼叫建立成功率低仅仅在晚忙时才会
4、出现，白天其他时段不会出现。如下图：【问题分析】Reliance 项目疑难问题总结（第一期）2018-1-11 第 3 页 , 共 28 页呼叫建立成功率随时间有规律的变化，很明显与话务量有关系。每个载扇均有此问题，大致判断问题可能出现在链路，CK，CP板。查询告警信息，无告警。用NASTAR查看话统，呼叫建立失败集中在CS Call Resource Allocation Failures，软切换失败原因为Requested Abis resources unavailable。用CBSSSTAR分析该基站24，25日(19:0021;00)忙时掉话原因值,发现存在大量0XF1F异常呼叫失败
5、，该原因值解释为：等ABIS_BTS_SETUP_ACK超时Cause:(1)abis链路闪断(2)abis信令带宽配得不够,造成信令链路拥塞(3)定时器长度设置过短.查看异常呼叫失败原因值扇区分布，均分布在64号基站3个扇区：查看64号基站信令链路带宽配置(LST BTSLNK) ，配置为110K 。信令链路配置不足，根据“ABIS链路配置带宽 ”约等于“载频数”乘33K，修改为 210K。【处理措施】26日晚修改64号基站信令链路带宽为210k。注意：如果直接修改信令链路带宽，需要重新启动SPU板，会影响整个框的业务。如果采用先删除该信令链路，再添加的方法，可以不重新启动SPU板。命令如下
6、：RMV BTSSIGLNK: BTSID=64,congfirm=y;ADD BTSSIGLNK: BTSID=64, FN=5, SN=SN0, LM=MLPPP, MLPPPGRP=3, LNKBW=BW210K,confirm=y;继续观察话统，呼叫成功率在27日晚忙时已经达到98%以上，软切换成功率也上升到Reliance 项目疑难问题总结（第一期）2018-1-11 第 4 页 , 共 28 页98%以上。【问题总结】1. 严格遵守技术通知的要求，在ABIS接口配置业务链路和信令链路带宽时应按公司给出的建议值：“业务链路配置带宽”约等于“ 信道板反向 CE个数”乘20K；“ABIS
7、链路配置带宽” 约等于“载频数”乘33K 来进行配置。2. 在修改信令链路带宽的时候，可以采用先删除再添加的方法避免SPU重启。1.2 呼叫建立时 A1 接口失败问题（凌太兵）【现象描述】印度Reliance UPE Kanpur下的两个BSC内总存在A1接口问题，即是BSC等待指配请求超时。呼叫成功率为99%，而因这而导致的呼叫失败率就达到0.1%0.5% 。【问题分析】BSC等待指配请求超时可能有三个原因造成：1. 等待指配定时器设置过短，MSC还没来得及发送，BSC 这侧就已等待超时了；2. A接口丢消息，MSC已经发出指配请求，但BSC侧没有收到； 3. MSC没有向BSC侧发送指配请
8、求。【处理措施】检查BSC侧等待指配定时器设置，在维护台查询 CCM 0号软参LST SOFTPARA: SRVMN=CCM, PRMNO=0; 设置为6s，正常。检查A接口是否丢消息，在同一段时间内，在 BSC观察尝试次数、等待指配请求超时的次数，在MSC侧观察收到尝试次数、等待指配完成的次数，两边统计不一致，因此这个方法作罢。从SPU Runlog找到失败原因2704（即是指配超时失败）次数最频繁的 10个IMSI 号，在BSC侧跟踪Subscriber Trace，在 MSC侧跟踪内部接口信令，信令保存选择自动保存，否则后面的信令会将前面的信令冲掉。跟踪两个小时后，到SPU Runlog
9、 中根据提取这段时间内释放原因为2704的IMSI后，观察是否存在跟踪信令的IMSI号存在，如有，则观察在什么时间失败的。打开BSC侧和MSC信令跟踪，找到失败的时间点的记录，观察到BSC发送CM Service Request，6秒内没有确实没有收到Assignment Request。在MSC侧观察，MSC 收到CM Service Request后，到VLR未查到该用户，后向HLR发起 Regiter Notification消息，但HLR未回超时，该定时器为12秒，BSC 侧等待指配定时器为6秒，从而导致指配超时。由于HLR是属于局方的，至于为何没回信息，需要进一步跟局方沟通。Reli
10、ance 项目疑难问题总结（第一期）2018-1-11 第 5 页 , 共 28 页【问题总结】首先分析等待指配超时的可能原因，并一一分析排除。对于A1接口失败的真正原因，很难从话统上得出结论，需要具体跟踪到失败用户的BSS侧和核心网侧信令进行具体分析。由于该原因导致的呼叫失败率就达为0.1%0.5% ，并不是每个用户以及每次通话都会出现该问题，因此需要进行筛选，跟踪那些出现次数较多的用户以及多跟踪一些用户，这样发现问题的概率就会增加。1.3 A1 接口失败问题（姜伟）【现象描述】分析Kanpur BSC1和BSC2话统发现，在6月8日晚忙时（19：0023：00），A1接口导致的失败次数非常
11、多，影响BSC1 呼叫建立成功率大约3 4个百分点, 对BSC2 影响大约49个百分点。BSC 名称 Time CS AttemptsTimesCS A1 Interface FailuresTimesCS Call Setup Success Ratio%WALSH Traffic DensityErlA1 接口失败对BSC 呼叫建立成功率的影响Kanpur BSC1 17:00:00 129842 28 98.8347 1876.69 0.02%Kanpur BSC1 18:00:00 148269 42 98.9506 2013.05 0.03%Kanpur BSC1 19:00:00 194939 3560 97.1022 2334.
