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

此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 CDMA项目典型案例总结项目典型案例总结 第四期第四期 2020 年年 3 月月 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 目 录 1接入问题总结 4 1 11 1被叫建立时间过长 邓杨 建立时间过长 邓杨 4 1 2UPE某些基站被叫成功率低问题 罗龙智 6 1 3UPE新BSC被叫建立成功率低问题 邓杨 10 1 4UPE A1接口失败案例 罗龙智 接口失败案例 罗龙智 12 1 5新加基站只能做主叫不能做被叫案例 田延峰 14 1 6CE License不足导致呼叫建立成功率下降问题呼叫建立成功率下降问题 田明华 田明华 14 1 7BSC的一个子系统下大量A1接口失败问题 田延峰 17 1 8BSC的一个子系统下所有用户无法拨打电话问题 田延峰 17 1 9通过提高带内信令帧增益提高呼建成功率 徐斌斌 18 1 10GPM未携带缺省业务选项导致某些手机无法做被叫 徐斌斌 18 1 11硬指配开启后各载波呼叫尝试次数严重不均 徐斌斌 19 1 12通过CE资源池配置解决载波间CE分配问题 徐斌斌 21 1 13一个BTS的指标突然变差的解决偶然方法 田延峰 21 1 14UPE A1 接口失败问题接口失败问题 邓杨邓杨 22 1 15孖机造成话统统计 A1 Interface Failures 的问题 李瑞昕 22 1 16最大小区半径配置错误导致一个载扇的资源无法建立 邸玉波 最大小区半径配置错误导致一个载扇的资源无法建立 邸玉波 26 1 17TATA用户接入用户接入Reliance的网络造成的的网络造成的A1接口失败 邸玉波 接口失败 邸玉波 26 1 18局间链路不足导致局间链路不足导致A1接口失败 郑晗 接口失败 郑晗 27 1 19CMUX板资源吊死导致板资源吊死导致呼叫建立成功率低问题 邸玉波 建立成功率低问题 邸玉波 29 1 20326基站接入成功率低问题 姜伟 基站接入成功率低问题 姜伟 31 2掉话问题总结 32 2 1跨信令点手机辅助硬切换掉话分析 王一兵 32 2 2PN复用 邻区错配导致掉话率高的问题 田明华 35 2 3新开站PN复用距离不足导致周边站点掉话率恶化 李向阳 35 2 4利用PSMM优化邻区不当导致高掉话率 刚伟 37 2 5直放站参数不合理导致掉话率高 徐斌斌 39 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 2 6124基站无法与周边基站软切换导致掉话率高问题 姜伟 40 3切换问题总结 42 3 1BSC间软切换与呼叫迁移案例分析间软切换与呼叫迁移案例分析 王一兵王一兵 42 3 2UPE Varanasi软切换成功率低的分析 罗龙智 44 3 3框间软切换链路带宽不足导致软切换比例下降和掉话率上升 李向阳 48 3 4MSC间呼叫迁移案例间呼叫迁移案例 罗龙智罗龙智 50 3 5PARC BSC下成片基站软切换成功率Rehoming后变差分析 田延峰 54 3 6硬切换后语音双不通的问题 田延峰 54 3 7手机辅助硬切换手机异频搜索影响软切换导致掉话 徐斌斌 54 3 8手机辅助硬切换参数配置不合理影响语音质量 徐斌斌 55 3 9手机辅助硬切换时异频邻区配置过多导致掉话率过高 徐斌斌 56 3 10A3A7软切换成功率降低 A3链路建立失败 吴挺智 57 3 113 11A3A7A3A7软切换全部失败问题 吴挺智 软切换全部失败问题 吴挺智 57 3 123 12REHOMING后基站无法进行软切换和更软切换 吴挺智 基站无法进行软切换和更软切换 吴挺智 58 3 13UPE某个基站软切换成功率低问题 邓杨 58 4FER高问题 59 4 1Charoda site FFER problem Analysis Case 姜伟 59 4 215L星卡问题描述以及处理 高林祥 62 4 3搜索窗设置不当导致无法软切换 搜索窗设置不当导致无法软切换 FER高 邓杨 高 邓杨 64 4 4导频污染导致导频污染导致FER高 邓杨 高 邓杨 65 4 5 卫星链路时延调整开关 未打开造成前向造成前向FER高的问题 李瑞昕 高的问题 李瑞昕 65 4 6FER问题的现象与处理方法总结问题的现象与处理方法总结 罗龙智 罗龙智 68 5数据业务 71 5 1UPE 数据业务呼建差案例 罗龙智 71 5 2PS CSSR 突然下降的问题总结 李向阳 72 5 3Kerala数据业务速率低问题 姜伟 75 6其他问题总结 83 6 1整个BSC语音质量变差的问题 田延峰 83 6 2MAPINFO图层坐标系不同导致CAIT导入地图 道路信息和站点信息显示 相差甚远 高林祥 83 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 6 3E1 T1链路告警查询方法 陈世进 87 6 46 4无法增加邻区 吴挺智 增加邻区 吴挺智 91 6 5小区半径设置不合理导致直放站不能工作 邸玉波 小区半径设置不合理导致直放站不能工作 邸玉波 91 6 6Kinpo手机在华为网络下通话中自动重启 徐斌斌 92 6 7How to connect two test mobiles to one Laptop 田延峰 94 6 8RSSI处理案例总结处理案例总结 郑晗郑晗 95 6 9Reg Zone配置错误导致RSSI上升基站呼建和掉话指标变差 屈柯 108 6 10扇区分集接收没有连接的判断方法 王一兵 111 6 11GU控制工程质量的经验 田延峰 113 6 12利用Nastar进行邻区优化的经验 郑晗 114 6 13BCKM板未插紧导致基站覆盖异常 徐斌斌 115 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 CDMA项目典型案例总结项目典型案例总结 第四期第四期 1 接入问题总结接入问题总结 1 11 1被叫建立时间过长 邓杨 建立时间过长 邓杨 现象描述 在对allahabad BSC的118基站进行主被叫测试时 发现被叫建立时间过长 大概需要 2 5秒左右 而主叫建立时间正常 基本保持在1秒左右 问题分析 从信令流程来看 时间主要消耗在发送ECAM消息这里 ECAM与前一条信令之间有 1 5秒左右的时间间隔 选取lucknow BSC1的166基站被叫信令 主被叫均正常 与之对比 见下图 图1 Allahabad BSC的118站被叫信令流程 图2 Lucknow BSC1的166站被叫信令流程 通过对比发现 allahabad BSC在收到MSC下发的Assignment Request之间就开始建立 Abis链路 而lucknow BSC1是在收到MSC下发的Assignment Request之后才开始建立Abis链 路 通过查询CMM模块30号软参 发现是打开了并行指配开关所致 于是怀疑是信令流程 的改变导致在下发ECAM之前有1 5秒左右的延时 在将并行指配开关关闭之后 信令流程 恢复正常 但在下发ECAM之前依然存在1 5秒左右的延时 如下图 图3 关闭并行指配开关后的信令流程 后将问题提交研发定位 因为Allahabad BSC的CCM模块29号软参设置为0 x7 即打开 了ECAM延迟发送开关 导致被叫建立时间过长 处理措施 将该参数修改为 0 x00000000 之后 被叫建立时间保持在1秒左右 恢复正常 如下 图 图4 修改29号软参后的信令流程 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 总结 由于CCM模块29号软参只对被叫起作用 因此出现主叫建立时间正常 而被叫建立时 间过长的现象 1 2UPE 某些基站被叫成功率低问题 罗龙智 现象描述现象描述 I国R项目Lucknow BSC2下的某些站点 CS Term Call Setup Success Ratio 指标不好 88 90 但 CS Orig Call Setup Success Ratio 却很好 98 99 如下 问题分析问题分析 分析Runlog日志 基站所在框 主要失败原因为 捕获反向业务信道前导帧失败 0 x2702 此原因值按IMSI统计发现有很多IMSI的失败次数高达几十次 非常多 如下图所示 于是从MSC侧查询了关于这些IMSI的信息 发现这些IMSI的Origination ID OI 大 部分均为244或243 说明这些用户大部分都是无线公话 终端类型为FWT 由于终端类型是无线公话 于是选了一个公话做测试并跟了信令流程 1 当无线终端的话筒处于正常置放状态 on hook position 信令流程正常 呼建 成功 2 当无线公话终端的话筒未放置在座机上 off hook position 则被叫失败 如 下信令流程 从测试中我们可以看到 被叫的过程中 终端是收到了寻呼消息并响应了寻呼 这时 系统认为无线公话终端处于空闲态对其下发ECAM进行资源指配 但是在此之后 无线终 端并未有在Um空口上发送反向前导帧 等待超时后统计为BTS捕获反向前导帧失败 BSC 向MSC发送 Assignment Failure 而在KPI统计的时候却把这种非正常的捕获反向前导 统计了进去 使得Term CSSR变差 总结总结 在呼建成功率中 如果发现主叫呼建正常 而被叫呼建很差时 可试着分析这些基站 所在框的SPU日志 看是否有某些IMSI的失败原因为 捕捉反向业务前导帧失败 的次数 很多 并查询MSC侧的OI信息判断这些终端是否为无线公话终端FWT 如果是则说明被 叫呼建成功率低是由无线公话终端引起 并且信令流程在这种特殊情况是不合理的 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 以上问题只是个别类型的终端才有 对于华为固定台 会先把呼叫流程都走完之后 BSC发送Assignment complete给MSC 再由MSC据掉 这种情况下会统计为呼叫建 立成功 1 3UPE 新 BSC 被叫建立成功率低问题 邓杨 现象描述 Varanasi BSC3自开通以来 出现大量A口失败 被叫建立成功率非常低 只有50 多 该BSC是PARC平台的新BSC 挂在新的Varanasi MSC1下面 问题分析 1 B侧和N侧查询A口配置 均正常 也无告警 2 分析runlog日志 失败原因为2704 等待指配超时 3 选出指配超时出现较多的IMSI在维护台跟踪 发现指配超时均出现在作被叫时 4 再次联系N侧查询相关配置 发现该MSC打开了早寻呼开关 以下是关闭早寻呼的局间呼叫处理流程 关闭早寻呼的情况下 被叫端MSC VLR在收到主叫端MSC VLR发送的入局消息 IAI AM 之后再进行寻呼 但是当打开早寻呼之后 被叫端MSC VLR在收到HLR发送的请 求漫游号码消息 ROUTREQ 之后 并不是直接回送漫游号码 而是先进行寻呼 当寻呼到 被叫手机之后 再回送漫游号码 那么这样就存在两个延时 可能会最终导致指配失败 a 由于被叫端MSC VLR在收到HLR的请求漫游号码消息 ROUTREQ 之后 先进行 寻呼 待收到寻呼响应之后 再向HLR回送漫游号码 也就是说 打开早寻呼的 情况下 被叫端MSC VLR回送漫游号码相对于关闭早寻呼情况下会有一定延时 这个延时就是MSC下发寻呼到收到寻呼响应这段时间 通过观察跟踪的信令来看 大致在2 3秒 有可能在延时的2 3秒时间里 等待HLR的locreq响应定时器和等待 服务MSC的routreq响应定时器已经超时 那么 被叫端MSC VLR就不会收到主叫 端发送的入局消息 被叫端MSC也不会下发指配请求 最终BSC等待指配超时 b 关闭早寻呼的情况下 BSC上报了寻呼响应之后 被叫端MSC可以直接下发指配 当打开早寻呼时 被叫端MSC收到寻呼响应之后还要向HLR回送漫游号码 HLR 向主叫端MSC VLR送路由信息 最后主叫端MSC VLR向被叫端MSC VLR发送入 局消息 之后被叫端MSC VLR才能向BSC下发指配 那么 这里就多出了3条信 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 令的延时 如果这3条信令的延时可能会造成指配的时间超过6秒 BSC由于等待 指配超时向手机下发release order 造成被叫建立失败 处理措施 N侧将Varanasi MSC1的早寻呼开关关闭之后 被叫建立成功率上升到99 左右 总结 早寻呼开关打开对N侧的接通率指标提升有帮助 但是对于BSC这边的指标影响很大 遇到此类问题多与N侧沟通 看看是否是N侧那边的相关设置导致A口失败 1 4UPE A1 接口失败案例 罗龙智 接口失败案例 罗龙智 现象描述现象描述 Varanasi从2007 12 11号开始呼建中出现很多A1接口失败 具体还可见附件 失败原 因为0 x2704 等待MSC指配请求超时失败 特别是忙时由百次上升到了上千次 问题分析问题分析 关于A口失败一般都是B侧和N侧数据配置可能出现问题 所以当确认RF侧各BSC级参 数无问题后 向B侧与N侧工程师求助联合定位 定位过程中 N侧工程师反映数据配置没 有问题 但说承载网 STP 那边有拥塞告警和闪断 所以怀疑是客户的承载网出了问题 准备通知客户 通知客户后第二天A1接口失败次数减少到正常情况 总结总结 一般遇到A接口失败 可按以下思路进行分析 1 BSC 与 MSC 间的链路是否出现了问题 配置是否正确 2 BSC 与 MSC 的配置是否做到了一致 包括链路双工模式是否一致 IP 配置 是否一致 MSC 加的 IP 是否包含了所有 BSC 的 IP 链路协商模式是否一致 包 括了协议的公有和私有协义设置 3 MSC 与 HLR 链路是否正常 HLR 的定时器设置是否合理 4 BSC 与 MSC 间的网口端口等是否自动重启或断了 5 承载网是否有拥塞和闪断 6 如果是 PARC 平台的 BSC MSC 侧的早寻呼开关是否打开 打开的话会影 响被叫成功率 而失败原因也多半为 0 x2704 等待指配请求超时 7 在呼叫迁移过程中 BSC 间的呼叫迁移如果出现 A2 接口失败 请查看 A2p 格式是否为标准格式 1 5新加基站只能做主叫不能做被叫案例 田延峰 现象描述 PAC BSC下新加基站后 发现只能做主叫 被叫尝试次数为零 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 问题分析 1 分析基站所有参数与 KPI 指标 发现除被叫尝试次数为零以外 其 他指标均正常 2 重启 BTS 问题仍在 曾经发现实验站出现过此相同问题 重启 后解决 3 发现几个具有相同问题的基站位于同一个 XPU 框 且为新加基站 处理措施 1 检查 MSC 下添加的 BSC 子系统 发现此 XPU 框属于新子系统 但是在 MSC 下没有添加 造成此子系统下的所有用户只能做主叫 而被叫寻呼不到 从而被叫全不通 添加子系统后 网络正常 问题总结 处理问题时一定要搞清楚故障发生的范围 是仅仅发生在某个基站 还是发生在 某个框 还是发生在整个 BSC 还是整个 MSC 故障范围清晰了 定位的方向 也就明确了 1 6CE License 不足导致呼叫建立成功率下降问题呼叫建立成功率下降问题 田明华 田明华 现象描述 1月5日在对Rajathan Circle 的Jaipur bsc1进行KPI监控时发现 351号基站 S3 3 3 3 个扇区在1月2 3 4日连续三天忙时 19 00 20 00 出现了明显的呼叫建立成功率降 低的问题 掉话率为1 2 利用nastar生成的分析表可以看出 在忙时呼叫尝试次数明显 升高和话务量明显增加的情况下 呼叫建立失败的主要原因为 指配资源失败 CS Call Resource Allocation Failures 问题分析与解决 呼叫建立成功率随时间有规律的变化 很明显与话务量有关系 每个载扇均有此问题 大致判断问题可能出现在链路 大致判断问题可能出现在链路 CK CP板 板 查询告警信息 无告警 无告警 检查在TCH Assignment Failures未发现walsh和power不足导致的拥塞 该基站所属IP框下其他基站呼叫建立成功率良好 也排除FMR的问题 检查链路带宽配置充足 检查E1 配置两条 而CE话务量只有235Erl左右 两条E1是足够的 用OMStar分析日志以检查CE情况 存在大量原因值为212的接入失败 原因值解释如 下 查看212原因值分布 均分布在15f 十六进制数 转化为十进制为351 这个基站的三 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 个扇区上 对该问题时段进行分析 主要出现在忙时 19 00 20 00 随后在维护终端利用命令 DSP CBTSLICENSE 查询得知 该基站配置了256个CE LICENSE 利用命令 MOD BSCBTSINF 将256修改为512后 观察当日晚忙时呼叫建立成功率 发现恢复正常 如下 问题总结问题总结 1 目前引入了CE License 在分析指配资源失败时需要关注 2 由于CE License不足导致的接入失败原因值为212 3 查询CE License配置的命令 DSP CBTSLICENSE 修改命令为 MOD BSCBTSINF 1 7BSC 的一个子系统下大量 A1 接口失败问题 田延峰 现象描述 PAC下大量基站发现呼叫建立成功率下降 失败原因都是 A1接口失败 问题分析 1 发现所有存在问题基站属于同一个子系统 2 B 侧 N 侧均未修改过任何参数 3 从 BSC 接口板 ping 包到 MSC 发现有丢包现象 处理措施 在尝试了各种方法都无法解决的情况下 重新插拔BSC到LANSWITCH的E1 问题解 决 1 8BSC 的一个子系统下所有用户无法拨打电话问题 田延峰 现象描述 BSC的一个子系统下所有用户无法拨打电话问题 呼叫失败原因为 A1 接口失败 呼叫建立成功率为0 处理措施 将检查从BSC到MSC之间链路不通 无法解决的情况下 删除BSC到MSC之间的链路 重新添加后 问题解决 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 1 9通过提高带内信令帧增益提高呼建成功率 徐斌斌 案例索引关键词 呼叫建立成功率 带内信令帧增益 案例描述 I国搬迁项目中 分析某BSC的总体性能指标 发现整网接入成功率仅有96 左右 主 要为A口失败和空口失败 其中空口失败中有1 4左右是信令交互失败 处理过程 分析发现该BSC下均为郊区站点 站距较大 从话统中看到前向FER偏高 另外由于 呼建失败中信令交互失败较多 因此分析时由于郊区的覆盖不强导致前向误帧高 从而影 响了呼叫建立成功率 分析该BSC下各站的负荷不高 因此开启了带内信令帧提升增益功能 对所有信令交 互失败多的站提升信令帧增益3dB 调整后通过话统对比分析 对呼建性能大有所改善 对各个站分布做了具体分析和优 化 优化后总体呼建达到了98 以上 结论 对于呼叫建立失败中信令交互失败多的场景 可以尝试提高带内信令帧增益 以提高 信令的稳定交互 从而提升呼叫建立性能 1 10GPM 未携带缺省业务选项导致某些手机无法做被叫 徐斌斌 案例索引关键词 主叫 被叫 业务选项 手机兼容性 案例描述 I国搬迁项目中 客户投诉搬迁之前能够正常呼叫的手机 在搬迁之后无法做被叫 处理过程 通过跟踪该客户信令发现 每次收到GPM消息后 手机返回的Page Response带上来的 业务选项都是无效值0 x44 因此会被BSC拒掉 通过和之前的原网呼叫跟踪记录对比 发现原网在GPM中始终会携带业务选项 而华 为对于缺省的语音业务是不携带业务选项的 这样做是符合协议的 但由于现网的部分手 机不符合协议 因此会返回无效的业务选项 导致被叫响应被拒绝 通过修改软参 要所有GPM都携带业务选项 该问题解决 结论 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 对于无法做主叫 被叫这样的问题 最有用的手段就是跟踪信令 通过信令分析问题 出现的环节 对于非空口的原因 就需要分析信令中的字段内容是否正常 如果是搬迁项 目 最直接的办法就是对比原网的信令内容 这样能够很快的发现类似的兼容性问题 1 11硬指配开启后各载波呼叫尝试次数严重不均 徐斌斌 案例索引关键词 硬指配 呼叫尝试次数 案例描述 I国搬迁项目中 许多多载波边界站点开启了硬指配功能 而且空闲时手机只在基本载 波上驻留 接入后才可能会被指配到叠加载波上 割接后话统显示硬指配站点的基本载波 呼叫尝试次数远小于叠加载波载波 客户对此提出疑议 认为我们的硬指配算法有问题 无法达到负荷均衡的目的 处理过程 选取一个三载波站 该站的1 2载波为基本载波 第3载波为叠加载波 分析该站话统 发现的确1 2载波的呼叫尝试次数只有1 200次 但第3载波的呼叫尝试次数有1000多次 分析该站实际的话务情况 发现3个载波Walsh话务量基本相当 从总的TCH请求次数 来看 1 2载波的次数略多于第3载波 实际上该站旁边是2载波站 因此1 2载波的软切换话务量较高 这点从TCH软切换请 求次数就可以看到 1 2载波的软切换请求次数远高于第3载波 由于该站开启了硬指配功能 又由于1 2载波有很多软切换过来的呼叫因此负荷较高 因此从该站接入的新呼叫大部分都被指配到了第3载波上 而我们的话统统计呼叫尝试时 是按指配频点统计的 而不是用户实际发起接入尝试的频点 因此从话统中的叠加载波的 第3载波的呼叫尝试次数是 1 2载波的10倍 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 呼叫尝试次数会高于基本载波 向客户提交了说明后 得到了客户的认可 结论 1 华为的 呼叫尝试次数 指标 在硬指配打开后 会统计到被指配的目标载频上 而不是用户实际接入的的频点 这一点在话统分析时要注意 2 打开硬指配算法后 由于呼叫会被指配到负荷低的载频上以达到负荷均衡的目的 此时接入尝试次数并不能正确反映话务量和负荷的分布 对于负荷均衡 需要分析各载频 的负荷和话务量指标 1 12通过 CE 资源池配置解决载波间 CE 分配问题 徐斌斌 案例索引关键词 呼叫建立失败 CE不足 案例描述 I国搬迁项目中 某BSC下24号站晚忙时出现大量CE资源不足的呼建失败 处理过程 分析发现该站打开了硬指配 由于用户分布较近 载频负荷不高 因此大部分用户都 在基本载波呼叫 导致忙时发生CE拥塞 通过降低硬指配门限 情况略有改善 但无法根除 BS工程师发现目前的配置是每块信道板单独配置为1个资源池 载波间CE无法共享 因此通过配置每2块信道板为1个资源池 使各载波资源共享 问题基本解决 由于1 2载波为基本载波 话务量较高 3 4载波为叠加载波 话务量较低 为了有 效实现CE资源池的作用 将1 3载波的两块信道板配置成一个CE资源池 2 4载波的两 块信道板配置成一个CE资源池 结论 1 目前华为的硬指配算法只能保证负荷均衡 对于这种话务高但负荷很低的场景 硬 指配算法无法保证载波间资源占用率的均衡 通常情况下只能关闭硬指配算法 2 但对于非要使用硬指配的场景 可以通过配置载波间共享CE的资源池配置方法来解 决该问题 1 13一个 BTS 的指标突然变差的解决偶然方法 田延峰 现象描述 一个BTS的指标突然变差 话务量4Erl 全天主被叫指标全部变差 具 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 体现象为 由于CS TCH Signaling Exchange Failures原因造成的呼建成功率全天 20 90 不定 掉话率 Too many Erasure frames 在5 以上 软切换和更软切换 失败由于Radio interface abnormal的原因成功率只有50 90 前向FER在7 左右 反向FER正常 问题分析 1 周围相邻站没有异常 2 排除了基站告警及各种硬件原因 重起基站 没有效果 3 排除所有无线参数原因 并且把增强指标的各种参数修改到最大 效果不大 处理措施 在尝试了各种方法都无法解决的情况下 把业务链路删除 重新添加后 问题解决 1 14UPE A1 接口失败问题接口失败问题 邓杨邓杨 现象描述 Kanpur BSC1 和 Kanpur BSC2 呼建成功率突然下降 存在大量A口失败 这两个BSC 挂在Kanpur MSC1下面 问题分析 1 检查两个 BSC 的 A 口配置 均正常 2 查看修改记录 未对全网作参数修改 3 将问题提交研发 最后定位出是 MSC 的一个网口突然激活 该网口激活后由于 在 BSC 这边找不到相应的单板 故导致大量 A 口失败 处理措施 N 侧将该网口关闭后 A 口失败现象消失 呼建成功率恢复正常 问题总结 对于整个 MSC 出现 A 口失败的现象 及时与 N 侧联系 让 N 侧检查 MSC 的配置 因为整个 MSC 都出现问题的情况 一般都是 N 侧那边出了问题 1 15孖机造成话统统计 A1 Interface Failures 的问题 李瑞昕 问题现象 分析某局话统时 发现呼叫建立失败中有大量 A1 Interface Failures 且数量波动很 大 有时候几万次 有时候几千次 影响呼叫建立成功率0 3个百分点左右 每天几千上万 次的A1接口失败是不正常的 在正常的网络中该值应该很少 甚至是0 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 Time day CS Attempts Times CS Call Setup Success Ratio CS A1 Interface Failures Tim es CS Call Resource Allocation Failures Tim es CS Reverse TCH Preamble Acquisition Failures Times CS TCH Signaling Exchange Failures Times 2007 12 11678971098 587511116209384861915229 2007 12 12712836098 321123333312435081414291 2007 12178923596412525321314351 2007 12266717815397055282015167 2007 12501217790230614920114132 2007 12 16657608098 664616184136704567512287 2007 12595516279168994759213763 2007 1287071419271658234760212836 2007 12 19617800498 919376677859984210311882 分析思路 利用CBSSSTAR分析BSC日志 发现失败都是0 x2704 也就是等待MSC指配请求超时 查看0 x2704失败的框分布 扇区分布 时间分布和IMSI分布都没有集中在个别对象上 其中失败最多的前几个IMSI 每天都有50次以上的失败 明显存在异常 于是在BSC维护 台上跟踪失败最多的前10个IMSI的用户接口信令进行分析 分析失败最多的IMSI 404001062467315的信令发现 该用户的登记有时候成功 有 时候被拒绝 拒绝原因是 illegal MS 另外 当作为被叫时 BSC会收到2条寻呼响应 并都发给了MSC 有时候收到MSC 的指配请求 有时候收到 N DISCONNECT IND 详细分析登记和寻呼响应的里的消息字段发现 同一个IMSI有两个ESN 可见这是一 个孖机 一个ESN是合法的 一个是非法的 因此登记的时候 只有合法的那个手机能够 成功 当作被叫时 两个手机收到寻呼消息后都会发寻呼响应 因此BSC会收到2条寻呼响应 至于为什么有时候被叫成功 有时候被叫被拒 经过对比发现 如果是非法手机的寻呼响 应先收到 则MSC就会拒绝 而如果是先收到的是合法手机的 MSC就会发指配请求 呼 叫建立成功 但是不管是成功还是失败 BSC都上报了2条寻呼响应 但是只收到一次MSC 的响应 因此都会统计一次 等待指配请求超时 利用CBSSTAR的 CSL数据分析 功能分析0 x2704失败较多的一些IMSI 基本上都是 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 一个IMSI对应2个ESN 其中一个IMSI 404001056000000 更是有多达18个ESN 由此可见 这个网络中的孖机非常多 这些孖机可以造成相当数量的 0 x2704 失败 注 之所以每天有上万次失败 后来分析发现还有承载网有拥塞和传输的问题 因 此每天的失败次数波动很大 另外还有非华为HLR有时候不给MSC回响应等 这里不再分 析 处理措施 使用BSC的过滤非法手机功能 命令 ADD BLACKLISTESN 把已知的非法ESN 输入黑名单后 再跟踪信令分析 BSC只会收到1次寻呼响应 都来自合法的ESN 但是只 能是发现一个手动屏蔽一个 1 16最大小区半径配置错误导致一个载扇的资源无法建立 邸玉波 最大小区半径配置错误导致一个载扇的资源无法建立 邸玉波 现象描述 I国项目中 监控话统指标发现一个两载波站其中有一个载扇没有话务 问题分析及处理措施 检查配置 DSP RES 发现其中一个载扇是被闭掉的 立即解开 但是发现还是不 能建立起来 之后便开始检查发射功率 VSWR RSSI以及告警等均未发现异常 之后便 检查CP板 发现CCPM的版本是QCK3CCPM 并检查了基站的配置 发现最大小区半径是 40KM 将其改为20KM 问题解决 问题总结 QCK3CCPM 该类型的芯片 6700芯片 如果最大小区半径配置为40KM 最多只能 支持5个载扇同时工作 所以需要将小区半径修改为20Km 1 17TATA 用户接入用户接入 Reliance 的网络造成的的网络造成的 A1 接口失败 邸玉波 接口失败 邸玉波 现象描述 I国项目中 分析话统时发现在某一时段总有上百次的A口失败 问题分析及处理措施 分析Runlog发现 存在大量的等待指配请求超时的失败 发现主要集中在某一个IMSI上 并在维护台跟踪 跟了好长时间没有发现消息上来 并想主动给该用户打电话跟踪 于是查到该号码为9229462014 并拨打该号码回访 但是 发现还是没有消息上来 询问客户得知该用户是TATA的用户 但并不清楚为什么会接到 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 Reliance的网络下面来 因为两家运营商使用不同的频点 于是将该用户加入到我们黑名单 命令 ADD BLACKLISTESN ESN xxxxxxxxxx 使该用户不能接入到我们的网络 问 题解决 1 18局间链路不足导致局间链路不足导致 A1 接口失败 郑晗 接口失败 郑晗 现象描述现象描述 O地区共有4个BSC分挂在两个MSC上 其中MSC3最先开起来 MSC4在之后两个月左右 才开起来 待MSC3下面的两个BSC开了约30个BTS后每天统计KPI发现MSC4下面的两个 BSC的呼叫建立成功率较低 其中A1接口失败次数较多而MSC3下面的两个BSCA1接口失 败次数基本没有 如下图所示 图 A1接口失败BSC对比图 问题分析问题分析 1由于两个 MSC 对比现象比较明显 首先检查 BSC A 口配置有无问题 2联系 N 侧工程师检查两个 MSC 的参数配置是否相同确认没有问题 3核查 MSC4 失败全天失败次数分布发现基本出现在忙时 检查 MSC 链路状 态发现忙时 HW MSC 到 LU MSC 的局间链路占用量为 100 察看两个 MSC 的链路 配置发现 MSC3 的局间链路配了 21 条均可用 而 MSC4 的局间链路配置了 17 条但是 其中 9 条处于不可用状态 怀疑由于局间链路较少导致忙时用户打出局电话链路拥塞 无链路资源造成 A 接口失败 处理措施处理措施 推动局方增加10条MSC4到朗讯局间链路并整改9条不可用链路为可用后问题解决 案例小结案例小结 该案例中查询局间链路命令为 DSP OFCTKC 然后输入GMSC和链路类型如下图 图 查询局间链路方法 输入后会显示链路状态如下图 图 链路状态示图 A接口失败原因可能性较多 应首先抓住问题出现的特点进行查询分析 分析基本可 从以下方面着手 BSC 和 MSC 的 A 接口参数配置 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 BSC 和 MSC 硬件及链路配置 查询 BSC 和 MSC 告警台状态 1 19CMUX 板资源吊死导致板资源吊死导致呼叫建立成功率低问题 邸玉波 建立成功率低问题 邸玉波 现象描述 I国项目中 发现某个BSC下一个框的呼叫建立成功率在忙时非常低 Carrier GroupHours CS Orig Call Setup Success Ratio CS Term Call Setup Success Ratio Module Raipur BSC2 1 17 00 0096 282397 4383 Module Raipur BSC2 1 18 00 0070 948372 2797 Module Raipur BSC2 1 19 00 0054 536954 3515 Module Raipur BSC2 1 20 00 0057 069857 2689 Module Raipur BSC2 1 21 00 0084 696786 5369 Module Raipur BSC2 1 22 00 0040 261441 0736 Module Raipur BSC2 1 23 00 0090 786192 9355 问题分析及处理措施 从话统数据分析来看 失败原因主要是CS Call Resource Allocation Failures 检查配置 数据和设备没有任何异常 通过分析Runlog数据发现存在好多的1464失败原因值 ApplyingApplying forfor FMRFMR AAL2AAL2 failedfailed duringduring a a callcall Ox1464说明MUX管理的FMR到APF之间的channel分配失败 FMR到APF的channel可 以通过DSP CID查询 CID代表话路数 这个话路数与DSP USERNUM的用户数基本一致 当问题发生时 查询3框的CID 发现426个CID几乎被用光 但是DSP USERNUM查询的结 果就只有话路数的一半 经过BSC开发定位 MUX话路数的管理出现了吊死 如果CID被 用光 那么新的呼叫建立时就无法获取FMR到APF的channel 出问题的版本是 V2R3C03B011 BSC开发部已经在V2R3C03B018SP04版本中解决了这个问题 并且这个版 本已经在Reliance升级 在29日完成升级后 将不存在此问题 总结 当遇到BSC级的呼建很低的时候 首先观察是个别站导致还是很多站导致整 个BSC的指标差 如果是很多站导致 看这些站是否有什么共性 同一个框等 以便快速 定位解决问题 1 20326 基站接入成功率低问题 姜伟 基站接入成功率低问题 姜伟 现象描述 326基站 和 扇区的369频点呼建成功率低 失败原因主要是捕获不 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 到反向业务信道前导帧 问题分析 由于这两个扇区的410频点呼建是正常的 所以重点在于找到369频点和410频点的 差异 重点检查如下方面 1 无下挂直放站 周围也没有直放站 体现不出两个频点的差异 2 周边基站也全部都是两载波基站 体现不出两个频点的差异 另外 周边基站 的呼建都是正常的 没有哪个站369频点呼建明显差 3 两个频点参数设置完全一致 4 检查邻区 发现 扇区的369频点比410频点多配置了一个邻区 而这个邻区 的PN恰恰与本基站本扇区的PN相同 正常情况下如果要加一个与本扇区PN相 同的扇区为邻区 系统是不允许加入的 此处不知为何加入成功了 扇区 也是同样的情况 问题处理 将 和 扇区的369频点中配置的与自身PN相同的邻区删除 呼叫建立成功率恢复正 常 达到98 以上 问题总结 善用比较法 处理问题会更加快捷 2 掉话问题总结掉话问题总结 2 1跨信令点手机辅助硬切换掉话分析 王一兵 现象描述 BTS419掉话率突然升高 通过Nastar话统分析 发现第四载波掉话率高 除了Too many Erasure frames掉话原因外 还有许多A2 interface abnormal掉话 BtsId CellId SectorId CarrierId PN AFRCNTime hour CS Call Drop Ratio CS Call Drops Too many Erasure frames Times CS Call Drops A2 interface abnormal Times 419 419 0 1 57 4102007 10 08 19 00 000 36809830 419 419 0 2 57 4512007 10 08 19 00 000 28985530 419 419 0 3 57 3692007 10 08 19 00 000 09208110 419 419 0 4 57 4922007 10 08 19 00 008 045981555 419 419 1 1 225 4102007 10 08 19 00 001 69731120 419 419 1 2 225 4512007 10 08 19 00 001 20919100 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 419 419 1 3 225 3692007 10 08 19 00 000 52192141 419 419 1 4 225 4922007 10 08 19 00 0013 63343142 419 419 2 1 393 4102007 10 08 19 00 000 54054160 419 419 2 2 393 4512007 10 08 19 00 000 72202280 419 419 2 3 393 3692007 10 08 19 00 001 40449150 419 419 2 4 393 4922007 10 08 19 00 006 590264722 问题分析 手机从第四载波向其他载波的切换方式 我们采用的是手机辅助硬切换 手机辅助 硬切换的请求和失败 在Nastar中是记录在Intra SP Hard HO within same BS 或Inter SP Hard HO within same BS 上 检查BTS419的话统 发现BTS419有大量 Inter SP Hard HO within same BS 即跨信令点的硬切换请求 BTS419硬切换请求次数很多 失败率为 100 失败次数与A2 interface abnormal掉话次数相当 我们可以确认 BTS419第四载波 掉话是手机辅助硬切换失败导致的掉话 BtsId CellId SectorId CarrierId PN AFRCNTime hour CS Call Drops A2 interface abnormal Times Inter SP Hard HO within same BS Requests Times Inter SP Hard HO within same BS Failures Other causes Times 419 419 0 4 57 4922007 10 08 19 00 00554040 419 419 1 4 225 4922007 10 08 19 00 00142148148 419 419 2 4 393 4922007 10 08 19 00 00222121 419 419 0 4 57 4922007 10 09 19 00 00353131 419 419 1 4 225 4922007 10 09 19 00 00139157157 419 419 2 4 393 4922007 10 09 19 00 00212828 在通常情况下 手机辅助硬切换成功率在80 以上 但是BTS419的成功率为0 通常 手机辅助硬切换在Nastar中记录在Intra SP Hard HO within same BS 但是BTS419的手机 辅助硬切换请求和失败都记录在Inter SP Hard HO within same BS 即跨信令点的手机辅 助硬切换 因此我们把问题转向对信令点进行分析 BTS419原来属于IP框6 为了均衡框间话务量 客户调整了部分基站的框归属 基站 调框除了BSC要配置数据外 如果框归属信令点发生变化 MSC也要修改数据 BTS419从 6框调整到10框 框归属信令点发生变化 但是MSC没有作相应调整 导致许多Inter SP Hard HO within same BS Failures Other causes 的发生 有一个概念需要澄清 如果软切换失败 不一定导致掉话 只不过缺少一个软切换 分支 Best Ec Io和FFER可能会变差一些 但是硬切换一旦失败 则必然导致掉话 因为 此时原通话链路已经被释放掉了 BTS419第四载波的掉话正是这种情况 此文档收集于网络 如有侵权 请联系网站删除 此文档仅供学习与交流 解决方案 一共有3种解决方案 1 在MSC修改调框基站有关信令点数据 2 调整手机辅助硬切换门限 降低硬切换请求次数 3 删除手机辅助硬切换邻区 禁止硬切换 第一种方案当然是最好的 但是需要等待一段时间 第二种和第三种方案均可行 最后我们选择了最后一种方案 既删除手机辅助硬切换邻区 禁止硬切换 下表是在删除手机辅助硬切换邻区前后掉话率的对比 可以看到跨信令点的硬切换 请求次数已经为0 掉话率指标明显好转 BtsId CellId SectorId CarrierId PN AFRCNTime hour CS Call Drop Ratio CS Call Drops Too many Erasure frames Times CS Call Drops A2 interface abnormal Times Inter SP Hard HO within same BS Requests Time s Inter SP Hard HO within same BS Failures Other causes Times 419 419 0 4 57 4922007 10 08 19 00 008 0459815554040 419 419 1 4 225 4922007 10 08 19 00 0013