不同Codec能力終端之間互連互通問(wèn)題分析小結(jié).doc

聯(lián)芯科技有限公司中移動(dòng)現(xiàn)網(wǎng)環(huán)境，不同Codec能力終端之間互連互通問(wèn)題分析小結(jié)（聯(lián)芯科技 2011-10-31）1. 問(wèn)題現(xiàn)象描述聯(lián)芯方案終端在南京中移動(dòng)現(xiàn)網(wǎng)下進(jìn)行不同型號(hào)終端之間的互連互通測(cè)試時(shí)，發(fā)現(xiàn)在TD網(wǎng)絡(luò)下，存在電話被網(wǎng)絡(luò)側(cè)頻繁掛斷，導(dǎo)致起呼失敗問(wèn)題。根據(jù)聯(lián)芯多次測(cè)試分析，聯(lián)芯認(rèn)為網(wǎng)絡(luò)側(cè)存在重大缺陷。網(wǎng)絡(luò)側(cè)頻繁掛斷電話的原因是南京網(wǎng)絡(luò)側(cè)對(duì)不同CODEC能力終端之間的互連互通支持存在問(wèn)題，具體表現(xiàn)為CN在不支持RAB修改的RNC上發(fā)起RAB修改導(dǎo)致語(yǔ)音呼叫失敗。2. 問(wèn)題原因分析2.1 測(cè)試環(huán)境及協(xié)議規(guī)范要求：地 點(diǎn)：南京；RNC ID：01010100 0101B；TD小區(qū)ARFCN：10063；TD小區(qū)BMN：86;測(cè)試手機(jī)：聯(lián)芯方案終端A和聯(lián)芯方案終端B；手機(jī)CODEC能力配置如下： A手機(jī)配置支持兩種能力：AMR2和AMR； B手機(jī)只配置了一種能力：AMR；協(xié)議規(guī)范要求：3GPP TS 26.103和23.153表明了終端需要支持AMR2；在做CS語(yǔ)音業(yè)務(wù)時(shí)，終端會(huì)通過(guò)信令向網(wǎng)絡(luò)側(cè)上報(bào)終端的能力。主叫端通過(guò)SETUP信令上報(bào)CODEC能力； 中國(guó)移動(dòng)TD-SCDMA終端設(shè)備總體技術(shù)要求(R7)中規(guī)定AMR2為終端必須支持CODEC能力，原文如下：“6.1.2. 話音業(yè)務(wù)話音業(yè)務(wù)采用AMR話音編解碼器，共有8種AMR速率（12.2Kbps 4.75Kbps）。要求終端必須支持靜態(tài)配置8種速率，同時(shí)要求支持動(dòng)態(tài)速率調(diào)整。此外，對(duì)于支持3GPP R5的R5（HSDPA）終端和支持3GPP R7的R7（HSUPA）終端，話音業(yè)務(wù)必須支持AMR2話音編解碼器?！?.2 測(cè)試過(guò)程：A手機(jī)作為主叫，B手機(jī)做被叫，進(jìn)行CS語(yǔ)音業(yè)務(wù)。2.3 測(cè)試現(xiàn)象： 主叫建立了RAB后，網(wǎng)絡(luò)側(cè)直接下發(fā)了Disconnect信令，Disconnect的cause_value:” Netowrk out of order”。協(xié)議流程見(jiàn)圖 1。圖表 1 網(wǎng)絡(luò)側(cè)掛斷主叫流程 被叫在RAB建立過(guò)程中，網(wǎng)絡(luò)側(cè)下發(fā)了Disconnect信令，Disconnect的cause_value:” Netowrk out of order”。協(xié)議流程見(jiàn)圖 2。圖表 2網(wǎng)絡(luò)側(cè)掛斷被叫流程2.4 問(wèn)題分析： 對(duì)于上述問(wèn)題，分別從終端和網(wǎng)絡(luò)側(cè)log進(jìn)行分析。終端流程分析：從終端的log上看不出網(wǎng)絡(luò)側(cè)為什么下發(fā)Disconnect信令。因此做了新的試驗(yàn)：將A手機(jī)配置成只支持AMR，然后和B手機(jī)（只支持AMR）在同一個(gè)地點(diǎn)進(jìn)行多次呼叫測(cè)試，沒(méi)有出現(xiàn)呼叫失敗問(wèn)題。終端是否配置AMR或者AMR2通過(guò)終端發(fā)送的SETUP信令可以檢查。圖3對(duì)應(yīng)的是配置支持AMR2和AMR的SETUP信令；圖4是配置只支持AMR的SETUP信令；圖表 3支持 AMR2和AMR能力的SETUP信令圖表 4只支持AMR能力的SETUP信令網(wǎng)絡(luò)側(cè)log分析：從終端的對(duì)比測(cè)試及相關(guān)log分析，聯(lián)芯初步判斷網(wǎng)絡(luò)側(cè)對(duì)AMR2支持存在問(wèn)題。我們又抓取了主叫Iu口的信令流程，見(jiàn)圖 5。網(wǎng)絡(luò)側(cè)log過(guò)程如下： pos.1032 CN發(fā)了一條資源配置請(qǐng)求消息RANAP_RAB_ASSIGNMENT_REQ; pos.1042 CN收到資源配置響應(yīng)RANAP_RAB_ASSIGNMENT_RESP；但是,緊接著，pos.1044,CN又發(fā)了一遍資源配置請(qǐng)求消息RANAP_RAB_ASSIGNMENT_REQ，內(nèi)容和Pos.1032的相同，IMEI也確認(rèn)過(guò)、就是這個(gè)UE的；導(dǎo)致: pos.1046 CN收到了資源配置失敗響應(yīng)rAB-FailedItem.rAB-ID=00000001； pos.1048 給UE發(fā)送了DISCONNECT network out of order。圖表 5主叫Iu口信令流程導(dǎo)致以上問(wèn)題的網(wǎng)絡(luò)過(guò)程為：MMC呼叫建立過(guò)程中，主叫終端上報(bào)支持種語(yǔ)音CODEC能力AMR和AMR2，由于南京CN設(shè)備采用的是后向承載建立的方式，所以是在被叫側(cè)的CODEC能力尚沒(méi)有獲得的情況下，CN有可能選擇AMR2, 完成了主叫側(cè)的用戶面承載的建立過(guò)程，這就是在以上網(wǎng)絡(luò)側(cè)截圖中看到的第1個(gè)RAB指派的過(guò)程；當(dāng)被叫側(cè)終端通過(guò)Call Confirm將CODEC能力(AMR)發(fā)送給CN時(shí)，CN發(fā)現(xiàn)主被叫的CodeC不匹配，需要調(diào)整；目前南京CN目前的處理是，在主叫側(cè)重新發(fā)起了RAB建立的過(guò)程，以完成編碼方式的匹配，這就是我們?cè)贗u口上可以看到的第2次RAB指派的過(guò)程，實(shí)際是對(duì)前一個(gè)RAB的修改過(guò)程，但是與CN設(shè)備對(duì)接的南京華為RNC不支持這個(gè)RAB的修改過(guò)程，返回了失敗的結(jié)果，從而導(dǎo)致了MMC呼叫不能正常建立起來(lái)。從以上過(guò)程可以看出，導(dǎo)致這個(gè)問(wèn)題發(fā)生的條件是：1）CN配置為后向承載建立；2）CN配置為既支持UMTS_AMR,也支持UMTS_AMR2；3）CN配置為“RNC支持RAB修改”；4）CN的實(shí)現(xiàn)是通過(guò)RAB修改解決語(yǔ)音編碼不匹配的情況；5）RNC不支持RAB修改6）不同語(yǔ)音CODEC能力的終端之間建立呼叫3. 影響分析如果網(wǎng)絡(luò)側(cè)不在CN或者RNC設(shè)備上解決以上問(wèn)題，不同語(yǔ)音CODEC能力的終端之間不能正常進(jìn)行呼叫，嚴(yán)重影響用戶體驗(yàn)。該問(wèn)題不但在南京中移動(dòng)現(xiàn)網(wǎng)存在，很可能在其他城市和地區(qū)的中移動(dòng)現(xiàn)網(wǎng)存在，嚴(yán)重影響用戶體驗(yàn)。4. 建議修改點(diǎn)當(dāng)不同CODEC能力終端之間發(fā)起語(yǔ)音呼叫被網(wǎng)絡(luò)側(cè)異常釋放鏈路的問(wèn)題，建議網(wǎng)絡(luò)針對(duì)進(jìn)行進(jìn)一步確認(rèn)和檢查，找到最佳的解決問(wèn)題的方法。我們推薦網(wǎng)絡(luò)側(cè)可以通過(guò)下面的措施解決該問(wèn)題：CN側(cè)解決 方法一：將目前的語(yǔ)音呼叫建立過(guò)程中的CN設(shè)備用戶面后向承載建立，調(diào)整為前向承載建立，這樣CN側(cè)會(huì)在完成編解碼匹配之后再進(jìn)行RAB的建立，就不會(huì)有下面的問(wèn)題； 方法二：CN側(cè)關(guān)閉發(fā)起RAB修改的開(kāi)關(guān)，這樣強(qiáng)制在CN側(cè)引入編碼變換，這樣就不會(huì)在Iu口上發(fā)起RAB修改的過(guò)程，也就不會(huì)出現(xiàn)問(wèn)題； 方法三：CN側(cè)可以配置為只支持UMTS_AMR,不支持UMTS_AMR2，由于所有3G終端都是支持UMTS_AMR的，也可規(guī)避這個(gè)3G終端之間的互連互通問(wèn)題RNC側(cè)解