CDMA项目典型案例总结（第一期）.doc

Reliance CDMA 搬迁网优工作计划 2020 2 4第 1 页 共 28 页1 CDMA项目典型案例总结项目典型案例总结 第一期第一期 2020 年年 2 月月 Reliance 项目疑难问题总结 第一期 2020 2 4第 1 页 共 28 页 目 录 1接入问题总结 2 1 164号基站忙时Abis资源不足导致指配资源失败问题 高林祥 2 1 2呼叫建立时A1接口失败问题 凌太兵 4 1 3A1接口失败问题 姜伟 5 1 4直放站下起呼困难问题 田延峰 8 1 5割接后149号基站无法打电话 陈世进 9 2切换问题总结 11 2 1Inter Vendor同频硬切换失败系列问题定位 凌太兵 11 2 1 1Inter Vendor同频硬切换失败问题定位 1 11 2 1 2Inter Vendor同频硬切换失败问题定位 2 11 2 2两基站无法软切换问题 陈世进 12 3掉话问题总结 13 3 1252 309号站Abis接口异常掉话问题 高林祥 13 3 247号站Abis接口异常掉话问题 凌太兵 15 4拥塞问题总结 16 4 1Kanpur BSC1 指配资源失败问题 姜伟 16 5其他问题总结 20 5 1DTMF检测开关打开导致手机扬声器自动开启 高林祥 20 5 2LG手机自动重启问题 凌太兵 22 5 3三方通话异常问题 高林祥 25 5 4割接后主被叫全部静音问题 姜伟 25 5 5C506手机空闲态搜网问题 田延峰 26 6下期内容 27 Reliance 项目疑难问题总结 第一期 2020 2 4第 2 页 共 28 页 CDMA项目典型案例总结项目典型案例总结 第一期第一期 1 接入问题总结接入问题总结 1 164 号基站忙时 Abis 资源不足导致指配资源失败问题 高林祥 现象描述 Kanpur BSC1 64号站 S2 2 2 基站搬迁以后 该基站3个扇区呼叫建立成 功率在晚忙时 18 00 22 00 仅仅为50 左右 软切换成功率仅仅为60 左右 但掉话率指标 1 2 呼叫建立成功率低仅仅在晚忙时才会出现 白天其他时段不会出现 如下图 问题分析 Reliance 项目疑难问题总结 第一期 2020 2 4第 3 页 共 28 页 呼叫建立成功率随时间有规律的变化 很明显与话务量有关系 每个载扇均有此问题 大致判断问题可能出现在链路 CK CP板 查询告警信息 无告警 用NASTAR查看话统 呼叫建立失败集中在CS Call Resource Allocation Failures 软切 换失败原因为Requested Abis resources unavailable 用CBSSSTAR分析该基站24 25日 19 00 21 00 忙时掉话原因值 发现存在大量0XF1F 异常呼叫失败 该原因值解释为 等ABIS BTS SETUP ACK超时 Cause 1 abis链路闪断 2 abis信令带宽配得不够 造成信令链路拥塞 3 定时器长度设置过短 查看异常呼叫失败原因值扇区分布 均分布在64号基站3个扇区 查看64号基站信令链路带宽配置 LST BTSLNK 配置为110K 信令链路配置不 足 根据 ABIS链路配置带宽 约等于 载频数 乘 33K 修改为210K 处理措施 26日晚修改64号基站信令链路带宽为210k 注意 如果直接修改信令链路带宽 需要重新启动SPU板 会影响整个框的业务 如 果采用先删除该信令链路 再添加的方法 可以不重新启动SPU板 命令如下 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 项目疑难问题总结 第一期 2020 2 4第 4 页 共 28 页 98 以上 问题总结 1 严格遵守技术通知的要求 在ABIS接口配置业务链路和信令链路带宽时应按公 司给出的建议值 业务链路配置带宽 约等于 信道板反向CE个数 乘 20K ABIS链路配置带宽 约等于 载频数 乘 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侧发送指配请求 处理措施 检查BSC侧等待指配定时器设置 在维护台查询CCM 0号软参 LST SOFTPARA SRVMN CCM PRMNO 0 设置为6s 正常 检查A接口是否丢消息 在同一段时间内 在BSC观察尝试次数 等待指配请求超时 的次数 在MSC侧观察收到尝试次数 等待指配完成的次数 两边统计不一致 因此这个 方法作罢 从SPU Runlog找到失败原因2704 即是指配超时失败 次数最频繁的10个IMSI号 在 BSC侧跟踪Subscriber Trace 在MSC侧跟踪内部接口信令 信令保存选择自动保存 否则 后面的信令会将前面的信令冲掉 跟踪两个小时后 到SPU Runlog中根据提取这段时间内 释放原因为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是 属于局方的 至于为何没回信息 需要进一步跟局方沟通 Reliance 项目疑难问题总结 第一期 2020 2 4第 5 页 共 28 页 问题总结 首先分析等待指配超时的可能原因 并一一分析排除 对于A1接口失败的真正原因 很难从话统上得出结论 需要具体跟踪到失败用户的 BSS侧和核心网侧信令进行具体分析 由于该原因导致的呼叫失败率就达为0 1 0 5 并 不是每个用户以及每次通话都会出现该问题 因此需要进行筛选 跟踪那些出现次数较多 的用户以及多跟踪一些用户 这样发现问题的概率就会增加 1 3A1 接口失败问题 姜伟 现象描述 分析Kanpur BSC1和BSC2话统发现 在6月8日晚忙时 19 00 23 00 A1接口导 致的失败次数非常多 影响BSC1呼叫建立成功率大约3 4个百分点 对BSC2影响大约4 9 个百分点 BSC 名称 Time CS Attempts Times CS A1 Interface Failures Times CS Call Setup Success Ratio WALSH Traffic Density Erl A1 接口失败对 BSC 呼叫建立 成功率的影响 Kanpur BSC117 00 001298422898 83471876 690 02 Kanpur BSC118 00 001482694298 95062013 050 03 Kanpur BSC119 00 00194939356097 10222334 221 83 Kanpur BSC120 00 002386451111394 3852518 544 66 Kanpur BSC121 00 00174320525795 97872385 413 02 Kanpur BSC122 00 00136331251189 91433177 641 84 Kanpur BSC123 00 0048018696 69712256 750 01 Kanpur BSC217 00 00468432598 5014572 2770 05 Kanpur BSC218 00 00554314798 4467634 1540 08 Kanpur BSC219 00 0069519280294 6144671 0244 03 Kanpur BSC220 00 0072077660689 668616 8079 17 Kanpur BSC221 00 0043953275892 5602513 8916 27 Kanpur BSC222 00 0025461117594 0026592 1874 61 Kanpur BSC223 00 008269098 7181391 4580 00 选取6月8日19 00 22 00的数据 按IP框进行分析 发现在Kanpur BSC1和BSC2所 有框 不管话务量高低 全部存在A1接口失败问题 且各框中 A1接口失败次数 呼叫尝 试次数 的比例基本相当 Reliance 项目疑难问题总结 第一期 2020 2 4第 6 页 共 28 页 按基站进行分析 发现Kanpur BSC1和BSC2所有已开通的基站 均存在该问题 且 A1接口失败次数 呼叫尝试次数 的比例基本相当 通过Mainex分析 A1接口失败对应原因值为 2704 CCB FAIL ASSG REQ TIMEOUT 等指配请求超时 BSC2也是同样的现象 问题分析 在6月6日曾经在Kanpur BSC1出现过大量A1接口失败 但只影响BSC1 BSC2话务量 尚不到1000Erl BSC1达到两千以上 且与IP框关系密切 在话务量最高的两个IP框表现 最为明显 其他IP框失败次数很少 此问题已经定位 并且于6月7日凌晨将A接口CAPF接 口从半双工模式修改为全双工模式后解决 通过6月7日晚忙时话统观察 A1接口失败次数 已经大幅降低 恢复正常 通过两次A1接口失败的对比可以看出 6月8日出现的A1接口失败与6月6日的A1接口 失败现象有所不同 Reliance 项目疑难问题总结 第一期 2020 2 4第 7 页 共 28 页 6月6日A1接口失败6月8日A1接口失败 与IP框话务量强相关 在话务量最高的两 个IP框表现最明显 与IP框话务量无关 各框均有 而且比例 大致相当 话务量最高的两个框下面所挂基站存在该 问题 与基站话务量无关 已开通基站全部存在 该问题 不同点 只在Kanpur BSC1出现该问题 Kanpur BSC1和BSC2均出现该问题 挂在同 一个MSC下面 共同点 在晚忙时出现 在6月6日凌晨割接4个基 站后 Kanpur BSC1在6月6日晚忙时walsh 话务量达到1800 2300Erl Kanpur BSC2 晚忙时walsh话务量在500 700Erl 在晚忙时出现 在6月8日凌晨割接6个基站 后 Kanpur BSC1在6月8日晚忙时walsh话 务量创新高 达到2300 3100Erl Kanpur BSC2晚忙时walsh话务量在500 700Erl 从MSC话统里可以看出 在6月6日晚忙时8点 A接口出现问题的时候 MOC TCH Assignment Timeout 达到26784 但是6月8日晚忙时却只有290次 因此从BSC这侧统计等 待指配超时不是同样的A接口超时问题 而是MSC没有下发指配 在BSC侧跟踪信令 发现BSC向MSC发送CM SERVICE REQUEST后 没有收到MSC 的指配请求 在6秒钟后定时器超时释放呼叫 N侧工程师分析话统发现 6月8日晚上18 00以后去往HLR的消息无响应次数异常增 多 且无响应次数与BSC侧统计到的A1接口失败次数完全吻合 故确认问题所在 可能是 由于局方的链路拥塞或者HLR问题 HLR非华为设备 所致 处理措施 完成问题分析报告 由N侧工程师正式提交客户处理 Reliance 项目疑难问题总结 第一期 2020 2 4第 8 页 共 28 页 该问题提交客户后 客户对我们主动分析网络性能并指出他们的问题非常认可并表示 感谢 并承诺尽快解决该问题 问题总结 1 问题现象的分析非常重要 不能简单的就描述为 A1接口失败 而需要进一步 筛选 检查到底问题发生在哪个基站 哪个框 哪个信令点 哪个BSC 甚至于 哪个MSC 尤其是在需要N侧和B侧联合定位的情况下 更需要明确现象 以判 断问题所在 2 对于由于客户问题导致的指标恶化 一定要及时 主动及时 主动提交相应的报告 在客户 发现问题之前 知会给客户 占据战略上的主动 避免客户发现指标恶化时 不分青红皂白先投诉一把 即使我们最后能够证明是客户的问题 但恶劣影响已 经造成 洗也洗不干净 1 4直放站下起呼困难问题 田延峰 现象描述 客户投诉几个站下起呼困难 问题分析 检查这几个基站 下面均挂有直放站 怀疑与直放站有关 检查相关参 数 发现搜索窗较小 并且报头长度 PAM SZ 只有2 设置较小 需要修改 处理措施 1 将报头长度 Header Length 由2改为4 MOD ACH CN X SCTID X CRRID X PAMLEN 4 ATCHMODSIGN FFFFFFFF 查询命令LST CMFINF CN X SCTID X CRRID X CMFINF ACH 2 把扇区的搜索窗修改为 226 226 226 MOD HO CN X SCTID X CRRID X SRCHWINA CHIPS226 SRCHWINN CHIPS226 SRCHWINR CHIPS226 查询命令 LST RRMINF CN X SCTID X CRRID X RRMINF HO 修改完毕后进行测试 已经可以正常起呼 问题总结 对于下挂直放站的基站需要关注 1 搜索窗 Reliance 项目疑难问题总结 第一期 2020 2 4第 9 页 共 28 页 2 报头长度 3 邻区 4 RSSI 1 5割接后 149 号基站无法打电话 陈世进 现象描述 149号基站 3606E S222 割接后 现场人员反馈在基站底下也无法打 电话 维护台上查询功率发射 RSSI都正常 149号基站挂在12号框底下 目前该框只有 这一个基站 问题分析 时间大约在早上6点左右 话务量不高 既然功率发射正常 RSSI也正常 在基站底 下还是不能打电话 可以检查以下几个方面 A 传输 B 参数设置 如接入参数 SID NID等 C 基站时钟状态 D 信令和业务链路状态 E 硬件故障 F 其它原因 处理措施 A 查看基站告警 发现有E1 T1 Bit Error Rate Too High告警 怀疑时传输问题导致无 法打电话 B 定位并且解决了传输问题后E1 T1 Bit Error Rate Too High告警消息 但是现场仍然 反馈基站底下无法打电话 C 检查接入参数 链路配置 NID SID等 没有发现异常 D 检查基站时钟状态 GPS锁星正常 时钟没有问题 E 跟踪几部手机的信令 发现都是在空口下发ECAM消息后 BSC向MSC上报 Assignment Failure消息 Reliance 项目疑难问题总结 第一期 2020 2 4第 10 页 共 28 页 F 分析话统发现 所有呼叫全部失败 检查该框下面其他站性能 发现该框下面只 挂有这一个站 G 分析12框的SPU板日志 发现大量的0 x0c8b SDU ADD LINK FAIL 接入失败 原因值 这是SDU CCM ADD LINK CNF返回失败 可能FMR板有故障 H 考虑到12号框底下目前只有149号基站 而且是早上非话务高峰期 在征得客户统 同意的情况下重启了12号框 重启后问题得到了解决 问题总结 1 基站起来后不能打电话和很多因素有关 传输故障 时钟不同步 功率发射不 正常 参数配置错误 硬件故障等都能导致基站下不能打电话 遇到这种问题 可以参考以下顺序处理 A 在维护台上跟踪基站发射功率 RSSI VSWR等 B 查看告警 检查是否有传输 时钟同步 硬件等告警 C 检查参数配置 包括接入参数 SID NID 链路等 D 分析日志 找出主要的接入失败原因值 当然 最快速定位问题的方法是跟踪用户信令 Reliance 项目疑难问题总结 第一期 2020 2 4第 11 页 共 28 页 2 要确认问题影响范围 是单个基站还是整个IP框还是整个BSC 以快速定位问 题所在 2 切换问题总结切换问题总结 2 1Inter Vendor 同频硬切换失败系列问题定位 凌太兵 2 1 1Inter Vendor 同频硬切换失败问题定位 1 现象描述 印度Reliance UPW局点 华为到Lucent的IVHO 在华为的网络下搜索 Lucent目标小区信号 有时信号很弱 有时搜索不到 导致无法发起切换请求 问题分析 Lucent邻区信号有时很弱有时搜索不到 可能跟三个原因有关 1 Lucent 信号在该区域内覆盖很差 2 华为或者 Lucent GPS 失锁 导致时钟产生很大偏移 已超过邻区搜索窗口 大小 3 Lucent 基站距离过远 而华为设置的邻区搜索窗口过小 处理措施 1 降低华为服务小区的 SectorGain 搜索 Lucent 信号 仍然是有时弱 有时搜 索不到 2 闭掉华为服务小区信号 从 Lucent 小区接入 Ec Io 能达到 7dB 应该说信 号正常 3 由于邻区信号有时能收到有时收不到 怀疑 GPS 失锁 查询后 BTS 能搜到 10 颗星 4 怀疑跟相邻集搜索窗口设置小有关 缺省值为 60Chip 将搜索窗口设置成 100Chip Lucent 邻区信号能正常被收到 BSC 发起了切换请求 从终端上 报的 PSMM 消息中 PN 偏移达到了 65Chip 问题总结 对于切换空口失败的问题 通常空口信号 无线资源和搜索窗口等方面的原因 一一 进行排查 就可找出问题真正原因 2 1 2Inter Vendor 同频硬切换失败问题定位 2 现象描述 印度Reliance UPW局点 华为到Lucent的IVHO 在华为的网络下搜索 Lucent目标小区信号 有时信号很弱 有时搜索不到 导致无法发起切换请求 在增大邻 Reliance 项目疑难问题总结 第一期 2020 2 4第 12 页 共 28 页 区搜索窗口后 能正常搜到Lucent信号 华为BSC向MSC发起了Handoff Required 收到 Handoff Command后下发UHDM消息 但一直未收到终端返回MS Ack order message 切换 失败 问题分析 下发UHDM后一直未收到MS Ack Order Message 说明空口切换未成功 可能跟以下几个原因有关 1 Lucent 在该区域内前反向覆盖较差 导致空口建立失败 2 UHDM 中下发的频点 PN Walsh 码错误 3 Lucent 通过切换命令发过来的相邻集搜索窗口过小 导致搜索不到邻区 处理措施 1 切换时 Lucent 前向 Ec Io 为 4dB 华为前向 Ec Io 为 6 5dB 信号很好 2 检查 UHDM 中的频点 PN Walsh 码分配 没有问题 3 怀疑 Lucent 的相邻集搜索窗口设置过小 从 PSMM 消息中可以看到 邻区 PN429 朗讯基站 的偏移达到了 65 个 Chip 也就是说相邻集搜索窗设置 应该超过 65 以上才可以 但从 Lucent 发过来的 Handoff command 携带了 对端的搜索窗口 消息中 激活集和相邻集的搜索窗口设置为 40 个 Chip 说明 在收到说明 在收到 Handoff command 消息之前 终端将根据华为设置的消息之前 终端将根据华为设置的 搜索窗口进行搜索 而收到搜索窗口进行搜索 而收到 Handoff command 之后 将根据对端的搜索窗之后 将根据对端的搜索窗 口设置进行搜索口设置进行搜索 导致终端在收到该消息后 只在 40 个 Chip 的范围内搜 索 PN429 的信号 但是没有搜索到 所以导致空口没有建立成功 4 Lucent 增大了相邻集搜索窗口 切换成功 问题总结 1 在收到Handoff command消息之前 终端将根据华为设置的搜索窗口进行搜 索 而收到Handoff command之后 将根据对端的搜索窗口设置进行搜索 2 对于切换空口失败的问题 通常空口信号 无线资源和搜索窗口等方面的原 因 一一进行排查 就可找出问题真正原因 2 2两基站无法软切换问题 陈世进 现象描述 26号基站 3601C 2 ODU S111 和66号基站 3601C 2 ODU S111 均为新建基站 两基站相距10Km 路测时发现两基站相互之间的软切换不 成功 问题分析 软切换不成功一般和以下几点有关 1 没有配置软切换邻区关系 2 T ADD T DROP 等切换参数设置不当 Reliance 项目疑难问题总结 第一期 2020 2 4第 13 页 共 28 页 3 搜索窗参数设置不当 4 基站时钟不同步 5 如果两基站分属不同的框 还需检查框间软切换链路 6 其它未知原因 处理措施 1 检查邻区关系是否配置 发现两个基站已经互配了软切换邻区关系 相关命令 LST NBRCDMACH 2 检查时钟 发现 66 号基站使用内部时钟 而且使用北京时间 GMT 08 30 将其时钟改为 GPS 时钟 时间改为印度时间 GMT 05 30 相关命令 DSP MBTSBRDSPECSTAT BTSID 66 BRDTP MBPB 3 重新测试发现还是切换失败 分析路测数据 终端已经上发了 Pilot Strength Mesurement Message 消息 表明切换参数 搜索窗设置不是失败原因 4 在维护台上查询发现 26 号基站属于 13 框 66 号基站属于 14 框 而且这两个框 之间没有配置软切换链路 增加 13 和 14 两框的框间软切换后再次测试 软切 换成功 相关命令 LST CELL 可查询基站的模块属性 LST SHOLINK HOLNKTP IBSC FN 13 查询框间软切换链路 ADD SHOLINK HOLNKTP IBSC FN 13 NBRFN 14 LNKNO 0 LNKTYP CDMA1X BANDWIDTH1X BW3 0M 增加框间软切换链路 问题总结 遇到软切换失败问题 一般都可以从邻区配置 切换参数和搜索窗设置 基站时钟配 置及框间软切换链路配置这几点入手寻找原因所在 比较能快速定位问题的方法是分析信 令 看信令走到哪一步 然后参照一次软切换的完整信令过程定位问题 3 掉话问题总结掉话问题总结 3 1252 309 号站 Abis 接口异常掉话问题 高林祥 现象描述 Kanpur BSC2除了空口掉话外 一直始终存在Abis接口异常导致的掉话 从载频级话统分析 主要是252号站和309号站存在Abis接口异常掉话 并且该异常掉话全 天存在 Reliance 项目疑难问题总结 第一期 2020 2 4第 14 页 共 28 页 问题分析 用NASTAR分析话统数据 252号站和309号站确实存在Abis接口异常掉话 见下图 查看基站告警 均存在Abis链路出现BER of E1 T1 Link Too High告警 分析Kanpur BSC1 Runlog数据 该BSC掉话原因值存在大量0X220异常值 并且主要分 布在252号基站和309号基站 该异常掉话原因值解释为由于信道板或TRX不可用引起删除 小区的操作 将问题移交B侧处理 B侧工程师求助总部研发 经研发分析BTS日志定位 BCKM单 板软件版本为最老的V300R001C04B022 存在主控和CP资源核查接口不一致问题 主控将 CP上报的核查消息丢掉 呼叫控制块核查标记没被改写 超时后向BSC发起呼叫释放 BCKM单板软件版本需要升级到V300R001C04B022CPC0001 后台查询仍是C04B022 或 以后的版本 需要注意的是 BTS3606E的版本一共给前方发了两个V3R1C04B022 从后台查询 第一个版本用于现网调试和实验室测试 应该是2月14日的版本 第二个版本是正式商用 版本 版本号V3R1C03CPC0001 但由于客户不允许升级 所以做了一点小小的设置 使 得后台查询时仍然显示C04B022 4月份发布的版本 一定要保证所有基站的版本升级到 商用版本 并保持一致 两个版本区别可以从日志中查到 版本的日期不同 处理措施 5月25日晚对252号站和309号站BCKM单板进行升级 命令 DLDC CBTSALLSW 并选用LDOPTION ALL 这样子才能保证全部升级 注意 不能采用差异化加载 即选用LDOPTION DIFF 这样子可能导致升级不成功 Reliance 项目疑难问题总结 第一期 2020 2 4第 15 页 共 28 页 由于BTS是老版本的B022 后台是新的B022 查看5月26日数据 发现252号基站和309号基站仍然存在Abis接口异常掉话 经总部研 发确认是由于只对BCKM板进行升级 其他单板没有升级 各单板版本不匹配导致 5月26日晚对252号站和309号站全部单板进行升级 查看5月27月话统数据 Abis接口异常掉话现象消失 问题得到解决 见下图 问题总结 1 这个问题的出现主要是版本控制 前方一定要做好版本控制 不要把自己人也搞 糊涂 一定要保证所有基站的所有单板版本升级到商用版本 并保持一致 2 对于此类前后台版本一致的升级 一定不能选择差异性加载 否则可能导致升级 失败 需要采用强制加载的方式 命令 DLDC CBTSALLSW 并选用LDOPTION ALL 3 247 号站 Abis 接口异常掉话问题 凌太兵 现象描述 从话统分析看 47号基站各个扇区下均发生了Abis口异常掉话 见下 问题分析 1 从话统中可以看出 在同一时间范围内 同BTS下不同扇区均发生了Abis口异 常掉话 由此可以断定Abis链路或者BTS在这一段时间内出现了异常 2 从BAM的Runlog目录下获取该BTS所在框的SPU的当天运行日志 根据csl将终 Reliance 项目疑难问题总结 第一期 2020 2 4第 16 页 共 28 页 端释放记录选择 并通过CSL分析工具对这些记录进行分析 根据接入小区将 该BTS下的释放记录筛选出来 在呼叫释放原因中观察都有那些释放原因 并 将跟Abis相关记录挑选出来 从下表中 释放原因值为220 CDR释放原因表 说明是由于信道板或TRX不可用引起删除小区的操作 时间段为12 50 55到 13 47 53之间 3 查看告警记录 观察这一段时间内BTS是否发生了异常 观察告警有三种方式 一是进入Alarm Management System 在 Alarm Query 中选择 Query BTS Alarm 在BTS Normal Option中选择BTS出现异常的时间段 在BTS Detail Option中选择BTS 二是通过维护台命令 LST NEALMLOG 三是远程登陆 BTS 用LST HISTROY ALARM 这里就不详述了 4 告警日志显示如下 可以看出BTS47在这一段时间内出现了异常 而且出现异 常的时间与CSL中释放的时间一致 5 分析告警 MLPPP中配置了两条PPP Link 其中一条产生了环回 导致BTS定 期重启 处理措施 通知B侧处理该故障 解决后Abis接口异常掉话问题不再出现 问题总结 遇到性能问题 一定要结合基站告警进行分析 Reliance 项目疑难问题总结 第一期 2020 2 4第 17 页 共 28 页 4 拥塞问题总结拥塞问题总结 4 1Kanpur BSC1 指配资源失败问题 姜伟 Issue Description When analyze Kanpur BSC1 KPI we found that Call Resource Allocation Failures seriously decrease our KPI in busy hour BSC NameDateTime CS Attempt s Times CS Call Setup Success Ratio CS Call Resource Allocation Failures T imes CS Reverse TCH Preamble Acquisition Failures Ti mes CS TCH Signaling Exchange Failures Tim es Kanpur BSC12007 6 918 00 0015209398 9309189989412 Kanpur BSC12007 6 919 00 0021398698 67753701389703 Kanpur BSC12007 6 920 00 0024147598 43795321580789 Kanpur BSC12007 6 921 00 0017761497 45632471131556 Kanpur BSC12007 6 922 00 0012742591 64219336892414 Kanpur BSC12007 6 923 00 004229498 581429321295 Kanpur BSC12007 6 1018 00 0014936098 3697741012570 Kanpur BSC12007 6 1019 00 0020427497 946914261415840 Kanpur BSC12007 6 1020 00 0021847297 040437181482922 Kanpur BSC12007 6 1021 00 0014460198 6936443955461 Kanpur BSC12007 6 1022 00 0010843281 951818515727324 Kanpur BSC12007 6 1023 00 003694795 1633149721668 Analyze After further analysis we found Call Resource Allocation Failures most caused by Site Tehsil 通过上述操作可以过滤掉下行的DTMF消息 执行上述操作以后 继续拿LG手机 华为C300手机测试 扬声器开启和重启现象均消 失 问题得到解决 问题总结 1 遇到客户投诉某些手机出现奇怪现象 一般原因均是该手机不符合标准协议 一 定要找一部问题手机来实际测试 跟踪信令 拨打使现象同现 查看跟踪的信令 发现异常之处 2 找到问题所在 需要过滤某些消息时候 询问N侧 B侧有没有对应的软参或者开 关 3 一定要考虑清楚过滤掉某些消息是否会影响一些业务 在该例子中 手机接收 DTMF消息并没有实际作用 故可以过滤掉 5 2LG 手机自动重启问题 凌太兵 现象描述 Reliance用户投诉在HUAWEI网络下通话过程中LG终端会频繁发生异常 重启现象 而之前也有同事在曾经遇到过此类现象 问题分析 Reliance 项目疑难问题总结 第一期 2020 2 4第 23 页 共 28 页 遇到这种问题 一定要充分测试 掌握问题出现的规律 并且跟踪信令 找出问题出 现时的原因所在 处理措施 1 华为网络下两个终端互打 尝试了几十次一直未重现 与客户与同事反馈不一致 2 仔细询问同事 了解到在打长途比较容易出现该类问题 3 考虑到拨打长途 对端是在其它设备商的网络下 有可能在与其它设备兼容性上 存在问题 4 在BSC侧跟踪用户信令 并拨打长途到Lucent网络的用户 5 果然在华为网络下的终端频繁发生重启现象 6 分析信令 每次终端重启前都会收到DTMF消息 并且DTMF消息中的IE digits 为0 xd 见下图 Reliance 项目疑难问题总结 第一期 2020 2 4第 24 页 共 28 页 7 在终端上按键 当按 1 9 时 会发送DTMF 消息 IE digits 为 0 x1 0 x9 当 按 0 时 会发送DTMF 消息 IE digits 为 0 xa 当按 会发送DTMF 消息 IE digits 为 0 xb 当按 会发送DTMF 消息 IE digits 为 0 xc 没有其它 任何键可以产生DTMF 消息IE digits 为 0 xd 这是一个非法字段 是导致LG重 启的根本原因 由于在HUAWEI内部两个终端互打 一致未重现 而跟Lucent网络 通话就会出现 由此可判断该非法字段是从Lucent网络传过来的 但是如何产生存 在疑问 8 修改CCM 31号软参 可过滤BCD码的码流 将不属于BCD码的0 x0D 0 x0E 0 x0F码 流过滤掉 不发送往手机 该问题未重现 MOD SOFTPARA SRVMN CCM PRMNO 16 PRMV 0 x00000200 问题总结 Reliance 项目疑难问题总结 第一期 2020 2 4第 25 页 共 28 页 1 Lucent网络传来非法字段导致手机收到异常DTMF消息 引起终端重启 2 请其他局点检查并对照修改 5 3三方通话异常问题 高林祥 现象描述 客户投诉 某一新开基站下 A给B打电话 在A B通话状态下 C再给 B打电话 C听到忙音 此后B不能听到A的声音 但A可以听到B的声音 处理措施 此问题发生跟手机终端有关 部分型号手机不支持我们下发的Flash消息中的signal信 元 所以导致此问题 在MSC侧按照以下步骤处理 1 修改 UMG 上面的参数 将呼叫等待音对应的 TONE 修改为混音 SET TONEMIX 2 修改 C9 软参 P156 的 BIT12 为 0 3 修改 C9 软参 P165 的 BIT2 改为 0 不携带 SINGAL