不同Codec能力终端之间互连互通问题分析小结.doc

联芯科技有限公司中移动现网环境，不同Codec能力终端之间互连互通问题分析小结（联芯科技 2011-10-31）1. 问题现象描述联芯方案终端在南京中移动现网下进行不同型号终端之间的互连互通测试时，发现在TD网络下，存在电话被网络侧频繁挂断，导致起呼失败问题。根据联芯多次测试分析，联芯认为网络侧存在重大缺陷。网络侧频繁挂断电话的原因是南京网络侧对不同CODEC能力终端之间的互连互通支持存在问题，具体表现为CN在不支持RAB修改的RNC上发起RAB修改导致语音呼叫失败。2. 问题原因分析2.1 测试环境及协议规范要求：地 点：南京；RNC ID：01010100 0101B；TD小区ARFCN：10063；TD小区BMN：86;测试手机：联芯方案终端A和联芯方案终端B；手机CODEC能力配置如下： A手机配置支持两种能力：AMR2和AMR； B手机只配置了一种能力：AMR；协议规范要求：3GPP TS 26.103和23.153表明了终端需要支持AMR2；在做CS语音业务时，终端会通过信令向网络侧上报终端的能力。主叫端通过SETUP信令上报CODEC能力； 中国移动TD-SCDMA终端设备总体技术要求(R7)中规定AMR2为终端必须支持CODEC能力，原文如下：“6.1.2. 话音业务话音业务采用AMR话音编解码器，共有8种AMR速率（12.2Kbps 4.75Kbps）。要求终端必须支持静态配置8种速率，同时要求支持动态速率调整。此外，对于支持3GPP R5的R5（HSDPA）终端和支持3GPP R7的R7（HSUPA）终端，话音业务必须支持AMR2话音编解码器。”2.2 测试过程：A手机作为主叫，B手机做被叫，进行CS语音业务。2.3 测试现象： 主叫建立了RAB后，网络侧直接下发了Disconnect信令，Disconnect的cause_value:” Netowrk out of order”。协议流程见图 1。图表 1 网络侧挂断主叫流程 被叫在RAB建立过程中，网络侧下发了Disconnect信令，Disconnect的cause_value:” Netowrk out of order”。协议流程见图 2。图表 2网络侧挂断被叫流程2.4 问题分析： 对于上述问题，分别从终端和网络侧log进行分析。终端流程分析：从终端的log上看不出网络侧为什么下发Disconnect信令。因此做了新的试验：将A手机配置成只支持AMR，然后和B手机（只支持AMR）在同一个地点进行多次呼叫测试，没有出现呼叫失败问题。终端是否配置AMR或者AMR2通过终端发送的SETUP信令可以检查。图3对应的是配置支持AMR2和AMR的SETUP信令；图4是配置只支持AMR的SETUP信令；图表 3支持 AMR2和AMR能力的SETUP信令图表 4只支持AMR能力的SETUP信令网络侧log分析：从终端的对比测试及相关log分析，联芯初步判断网络侧对AMR2支持存在问题。我们又抓取了主叫Iu口的信令流程，见图 5。网络侧log过程如下： pos.1032 CN发了一条资源配置请求消息RANAP_RAB_ASSIGNMENT_REQ; pos.1042 CN收到资源配置响应RANAP_RAB_ASSIGNMENT_RESP；但是,紧接着，pos.1044,CN又发了一遍资源配置请求消息RANAP_RAB_ASSIGNMENT_REQ，内容和Pos.1032的相同，IMEI也确认过、就是这个UE的；导致: pos.1046 CN收到了资源配置失败响应rAB-FailedItem.rAB-ID=00000001； pos.1048 给UE发送了DISCONNECT network out of order。图表 5主叫Iu口信令流程导致以上问题的网络过程为：MMC呼叫建立过程中，主叫终端上报支持种语音CODEC能力AMR和AMR2，由于南京CN设备采用的是后向承载建立的方式，所以是在被叫侧的CODEC能力尚没有获得的情况下，CN有可能选择AMR2, 完成了主叫侧的用户面承载的建立过程，这就是在以上网络侧截图中看到的第1个RAB指派的过程；当被叫侧终端通过Call Confirm将CODEC能力(AMR)发送给CN时，CN发现主被叫的CodeC不匹配，需要调整；目前南京CN目前的处理是，在主叫侧重新发起了RAB建立的过程，以完成编码方式的匹配，这就是我们在Iu口上可以看到的第2次RAB指派的过程，实际是对前一个RAB的修改过程，但是与CN设备对接的南京华为RNC不支持这个RAB的修改过程，返回了失败的结果，从而导致了MMC呼叫不能正常建立起来。从以上过程可以看出，导致这个问题发生的条件是：1）CN配置为后向承载建立；2）CN配置为既支持UMTS_AMR,也支持UMTS_AMR2；3）CN配置为“RNC支持RAB修改”；4）CN的实现是通过RAB修改解决语音编码不匹配的情况；5）RNC不支持RAB修改6）不同语音CODEC能力的终端之间建立呼叫3. 影响分析如果网络侧不在CN或者RNC设备上解决以上问题，不同语音CODEC能力的终端之间不能正常进行呼叫，严重影响用户体验。该问题不但在南京中移动现网存在，很可能在其他城市和地区的中移动现网存在，严重影响用户体验。4. 建议修改点当不同CODEC能力终端之间发起语音呼叫被网络侧异常释放链路的问题，建议网络针对进行进一步确认和检查，找到最佳的解决问题的方法。我们推荐网络侧可以通过下面的措施解决该问题：CN侧解决 方法一：将目前的语音呼叫建立过程中的CN设备用户面后向承载建立，调整为前向承载建立，这样CN侧会在完成编解码匹配之后再进行RAB的建立，就不会有下面的问题； 方法二：CN侧关闭发起RAB修改的开关，这样强制在CN侧引入编码变换，这样就不会在Iu口上发起RAB修改的过程，也就不会出现问题； 方法三：CN侧可以配置为只支持UMTS_AMR,不支持UMTS_AMR2，由于所有3G终端都是支持UMTS_AMR的，也可规避这个3G终端之间的互连互通问题RNC侧解