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

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