第一篇：不同Codec能力終端之間互連互通問題分析小結

聯芯科技有限公司

中移動現網環境，不同Codec能力終端之間互連互通問題分析小結

（聯芯科技 2011-10-31）

1.問題現象描述

聯芯方案終端在南京中移動現網下進行不同型號終端之間的互連互通測試時，發現在TD網絡下，存在電話被網絡側頻繁掛斷，導致起呼失敗問題。

根據聯芯多次測試分析，聯芯認為網絡側存在重大缺陷。網絡側頻繁掛斷電話的原因是南京網絡側對不同CODEC能力終端之間的互連互通支持存在問題，具體表現為CN在不支持RAB修改的RNC上發起RAB修改導致語音呼叫失敗。

2.問題原因分析

2.1 測試環境及協議規范要求：

地

點：南京；RNC ID：'01010100 0101'B；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能力，原文如下：

地址：上海市浦東新區明月路1258號（201206）電話: 0086-021-31271000 傳真: 0086-021-31271010

聯芯科技有限公司

“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。

地址：上海市浦東新區明月路1258號（201206）電話: 0086-021-31271000 傳真: 0086-021-31271010

聯芯科技有限公司

圖表 2網絡側掛斷被叫流程

2.4 問題分析：

對于上述問題，分別從終端和網絡側log進行分析。終端流程分析：

從終端的log上看不出網絡側為什么下發Disconnect信令。因此做了新的試驗：將A手機配置成只支持AMR，然后和B手機（只支持AMR）在同一個地點進行多次呼叫測試，沒有出現呼叫失敗問題。

終端是否配置AMR或者AMR2通過終端發送的SETUP信令可以檢查。圖3對應的是配置支持AMR2和AMR的SETUP信令；圖4是配置只支持AMR的SETUP信令；

圖表 3支持 AMR2和AMR能力的SETUP信令

地址：上海市浦東新區明月路1258號（201206）電話: 0086-021-31271000 傳真: 0086-021-31271010

聯芯科技有限公司

圖表 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”。

地址：上海市浦東新區明月路1258號（201206）電話: 0086-021-31271000 傳真: 0086-021-31271010

聯芯科技有限公司

圖表 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修改”；

地址：上海市浦東新區明月路1258號（201206）電話: 0086-021-31271000 傳真: 0086-021-31271010

聯芯科技有限公司

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側解決

? 方法四：RNC側解決這個問題，則需要設備廠家確認為什么不支持RAB修改的原因，如RNC支持RAB

地址：上海市浦東新區明月路1258號（201206）電話: 0086-021-31271000 傳真: 0086-021-31271010

聯芯科技有限公司

修改，也是可以解決這個問題的。

地址：上海市浦東新區明月路1258號（201206）電話: 0086-021-31271000 傳真: 0086-021-31271010