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

中移动现网环境，不同Codec能力终端之间互连互通问题分析小结 （联芯科技 2011-10-31） 问题现象描述 联芯方案终端在南京中移动现网下进行不同型号终端之间的互连互通测试时，发现在TD网络下，存在电话被网络侧频繁挂断，导致起呼失败问题。 根据联芯多次测试分析，联芯认为网络侧存在重大缺陷。网络侧频繁挂断电话的原因是南京网络侧对不同CODEC能力终端之间的互连互通支持存在问题，具体表现为CN在不支持RAB修改的RNC上发起RAB修改导致语音呼叫失败。 问题原因分析 测试环境及协议规范要求： 地 点：南京；RNC ID0101B；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话音编解码器。” 测试过程： A手机作为主叫，B手机做被叫，进行CS语音业务。 测试现象： 主叫建立了RAB后，网络侧直接下发了Disconnect信令，Disconnect的cause_value:” Netowrk out of order”。协议流程见图 1。 图表 1 网络侧挂断主叫流程 被叫在RAB建立过程中，网络侧下发了Disconnect信令，Disconnect的cause_value:” Netowrk out of order”。协议流程见图 2。 图表 2网络侧挂断被叫流程 问题分析： 对于上述问题，分别从终端和网络侧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 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呼叫不能正常建立起来。 从以上