CS语音杂音问题的排查指导.doc

CS语音杂音问题的排查指导 CS语音问题排查思路 CS语音 出现杂音，情况比较复杂，牵涉的网元比较多，分析比较麻烦。为及时定位这种疑难问题，我们需要一些正确的排查步骤。以便在复现故障的时候，及时找到问题所在。 主要考虑： 1 是否为加密情况下出现的噪音，具体是什么样的噪音。 如果是系统加密开关打开(CN配置了加密，RNC也打开了加密)状态下出现的噪音，而且噪音是伴随有尖锐声音的流水声，或者是频率波动很大的叽里呱啦的声音，那么很有可能是加解密失败出现的问题。可以将加密关闭看看是否 现象消失。 如果现象没有消失，就是说在非加密情况下也出现了噪音，那么可以用下面提供的CS环回工具，确定问题的网元，可能牵涉到CN, RNC, UE。确定网元后，最好能在该网元的输入输出接口上抓取报文，获得直接证据，反馈给研发。 附件为典型的加密问题引起的杂音。基本上，如果加密有问题，导致的杂音都是这样的。 2 如果确认是加密的问题。需要有以下的信息 反馈给研发分析： A: 主被叫UE的RNC的信令跟踪(包括RNLC-RNLU 内部消息, 即RNLC_UE_CELL任务中选中RNLC-RNLU消息是否跟踪)，需要跟踪到从起呼时刻到 杂音出现的时刻。 B: 可以尝试IUUP环回的方式 确定具体的网元。 C: 如果是高通芯片手机，并且可以抓UE Log，那么抓UE Log，并且用高通QXDM的回放功能听UE 接收的具体声音。 D: 采用Iu/Iub 口抓包(如果Iu/Iub口为IP承载，可以在交换机上抓包，否则可以在RNC的UIMU 上抓包)， 或者采用RNLU的码流跟踪。抓到Iu口的码流，并恢复成语音。 操作步骤： 1 如果是现场测试出现的问题，即噪音第一次出现并且电话保持，那么立即采用环回测试的排查方法，确定网元。注意如果现场启动了加密，那么只能采用IUUP环回的方法。 2 如果是投诉，需要现场人员复现，那么在执行复现过程中注意尽可能的抓取研发所需要的信息：主被叫的RNC的信令跟踪(包括RNLC-RNLU内部消息)，UE Log; Iu/Iub 口抓包报文；RNLU的码流跟踪等。复现出来后，在电话保持过程中可以采用环回的方式确定网元。 3 如果是短时间噪音的问题，如利比亚主叫接通瞬间出现的噪音，那么可以采用呼叫前先设置环回，跟踪呼叫过程中是否出现改短时噪音。同时需要跟踪RNC的信令。 CS环回功能介绍 【】 图 213 CS环回任务发起 下图是任务详细设置选框 图 214 CS环回测试的任务详细信息设置界面 CS的环回目前支持八种环回，点击“CS业务换回测试”，弹出具体设置选择框。 图中环回测试有8种，分别对应Iuup层上/下行环回且环回后数据是否继续按原来方向发送，以及Fp的上下行环回且环回后数据是否继续按原来方向发送。 CS环回介绍 下面对各种环回结合图例做简单介绍，假定当前UE1和UE2打CS电话，图中红线是来自UE1的数据流,蓝线是来自UE2的数据流。 需要注意的是，在加密情况下，只能采取IUUP的环回测试方法，不能采用FP环回测试的方法。 UE2上行CS数据在IUUP回环，同时发送数据到CN，此时UE2的上行数据在RNC2的IUUP层被直接当做UE2的下行数据下发，并且上行方向继续UE1传递，同时从UE1的数据在到达RNC2的IUUP层时被丢弃，不下发给UE2。 图 215 上行数据在Iuup回环，同时发数据到CN UE2上行CS数据在IUUP回环，此时UE2的上行数据在RNC2的IUUP层被直接当做UE2的下行数据下发，且上行方向不继续UE1传递，同时从UE1的数据在到达RNC2的IUUP层时被丢弃，不下发给UE2。 图 216 上行数据在Iuup回环 UE2上行CS数据在FP回环，同时发送数据到CN，此时UE2的上行数据在RNC2的FP层被直接当做UE2的下行数据下发，并且上行方向继续UE1传递，同时从UE1的数据在到达RNC2的FP层时被丢弃，不下发给UE2。 图 217 上行数据在FP回环，同时发数据到CN UE2上行CS数据在FP回环，此时UE2的上行数据在RNC2的FP层被直接当做UE2的下行数据下发，并且上行方向不再往UE1传递，同时UE1的数据在到达RNC2的FP层时被丢弃，不下发给UE2。 图 218 上行数据在FP回环 UE1下行CS数据在IUUP回环，同时发送到UE1，此时UE2的下行数据在传递到RNC2的IUUP层时被直接当做UE1的上行数据向CN方向传递，返回给UE2，并且下行方向继续往UE1传递，同时真正的UE1上行数据在到达RNC1的IUUP层时被丢弃，不往UE2传递。 图 219 下行数据在Iuup回环，同时发数据到NodeB UE1下行CS数据在IUUP回环，此时UE2的下行数据在传递到RNC1