CDMA異廠家問硬切換互聯機制問題定位與分析

吳東鋒 原 杰

1異廠家硬切換原理

1.1接口與協議

在一次完整的CDMA通話中，手機從一個MSC切換到另外一個MSC，其中涉及到Um口、A口與E口(圖1)，各接口上承載的協議如表1所示，其中E口上承載的協議為MAP協議。

1.2同頻硬切換

目前華為BSC與中興BSC之間的硬切換屬于同頻硬切換類型。

華為廠家的算法如下：

軟切換目標激活集測量強度為SHOTargEclo，同頻硬切換目標激活集測量強度為HHOTargEclo，當BSC收到PSMM／PPSMM消息時。將分別計算這兩個值，若滿足下面任一條件，即觸發同頻硬切換：

(1)SHOTa rgEclo≤同頻硬切換服務載頻門限，HHOTargEclo≥同頻硬切換目標載頻門限，并且當前激活集導頻的最小RTD≥同頻硬切換最大環路時延門限；

(2)HHOTargEclo-SHOTargEclo>同頻硬切換相對門限，并且當前激活集目標導頻的最小RTD≥同頻硬切換最大環路時延門限。

中興廠家的算法如下：

(1)如果BSS間硬切換導頻集的強度比BSS內硬切換導頻集的強度高T—COMP_FOREIGN，并且比軟切換導頻集的強度高(LCOMP_FOREIGN+T_COMP_HARD)，則進行BSS間硬切換；

(2)如果BSS內硬切換導頻集的強度比軟切換導頻集的強度高T_COMP HARD，則進行BSS內硬切換，否則進行軟切換。

1.3局間硬切換

移動臺的跨MSC切換，分為前向切換、后向切換和第三方切換。

前向切換是指移動臺在振鈴態、等待振鈴態或者通話態，從服務MSC覆蓋的區域移動到目標MSC(鄰近MSC)的覆蓋區域，基站在進行信號收集、處理、判斷后。決定向目標MSC發起前向切換。服務MSC收到目標MSC的MSONCH消息后，前向切換成功。

后向切換是指移動臺在前向切換成功以后，繼續通話，在這個過程中，移動臺又從服務MSC的覆蓋范圍返回到先前發起前向切換的MSC的覆蓋范圍。由于是企圖原路返回，所以向目標MSC發起后向切換，后向切換成功后，目標MSC主動發起釋放請求，釋放原來與服務MSC的話路連接，新的目標MSC變成了服務MSC。

2肇慶佛山邊界案例分析處理

2.1現象描述

問題區域出現在佛山與肇慶邊界，有用戶投訴此區域掉話嚴重。從后臺指標來看，肇慶四會馬房站的指標無異常。佛山河口歐文萊站硬切換出成功率很低。經過測試發現，掉話主要集中在佛山(華為)和肇慶(中興)的硬切換區域，Ec／Io良好。

從信令回放來看，多次掉話都有一個共同特點，從佛山基站河口歐文萊往肇慶基站切換時。切換不成功導致掉話。具體信令流程分析如圖4。終端已經收到目標小區即肇慶基站上報的PN，并收到服務小區即佛山基站的切換指示，進行切換，上行上報切換完成消息，但此時下行沒有對切換完成消息進行響應。由于不斷上報的上行切換完成消息沒有收到響應，從而產生掉話，終端重新同步到肇慶基站{該基站正好是掉話前切換完成消息中的基站小區)。

2.2無線側分析定位

(1)中興側3秒定時器

檢查了華為與中興兩邊的硬切換數據配置，無異常。對相關的基站進行了天饋調整，控制發生硬切換的區域。使該區域Ec，Io得到了很好的改善。用戶投訴的掉話區域得到了轉移和縮小，但掉話現象依然存在，并且有規律地出現在華為切換到中興的單方向上，華為側硬切換出成功率很低。從信令跟蹤發現，華為向中興切換時，中興無線側給出大量切換拒絕，如表2所示：

中興無線側有一個防止乒乓切換的定時器，設為3秒。即從中興切換出去以后。3秒內如果對端要切換回來。中興無線側會拒絕。考慮到切換拒絕消息出現頻繁，首先關閉中興側3秒定時器。經觀察，華為側硬切換出成功率有較大改善，信令跟蹤上中興側不再出現切換拒絕。但現場DT測試依舊出現掉話。從信令上看掉話規律一致。掉話問題沒有得到徹底解決。從DT的信令回放上看，掉話都出現在河口歐文萊切換到四會馬房以后，終端切換成功后向四會馬房站發送切換完成消息，但一直得不到基站側應答。超時后掉話并重新同步。

(2)華為硬切換宏分集與中興側異常釋放

再次對后臺跟蹤的信令進行分析。從中興無線側信令跟蹤來看，中興網絡側收到了空口終端上來的切換完成消息，并沒有給終端應答，卻馬上在內部Aba接口發SDM去退消息，在尋找SDM失敗消息后，前向發起釋放。多次掉話都有此規律。

中興研發解釋為：佛山(華為)側發過來的切換請求消息中包含兩個小區，肇慶(中興)側分別對這兩個小區分配了資源，然后通過應答消息通知佛山側。但是佛山(華為)側給終端下發的切換指示消息中卻只包含一個小區，于是終端回給肇慶(中興)側的切換完成消息中只帶有一個小區，中興系統判斷切換完成的小區和切換請求的小區不匹配。于是發起釋放導致掉話。

局方從多次掉話的信令回放分析發現，中興研發部門給出的解釋現象確實存在。當華為側切換請求為1個小區時，不會出現異常釋放現象，切換成功并且無掉話；掉話都是因為切換請求小區個數與切換完成小區個數不一致而導致的異常釋放。

產生上述現象的原因主要為一個多月前，華為側開啟的硬切換宏分集功能，允許在做硬切換時同時上報多個小區，主要是為了改善華為BSC內部呼叫遷移帶來的硬切換性能。

至此，原因定位為華為側硬切換宏分集功能的打開，導致與中興多小區硬切換時切換請求小區個數與切換完成小區個數不一致。華為無線側跟蹤信令發現，這是因為核心側下發的切換指示只帶有1個小區信息，因此。需要核心網部門介入詳細分析。

2.3核心側分析定位

經過華為核心側與中興核心側多次聯合分析與定位，最終發現雙方在E口的MAP41協議上存在分歧，通過圖5可以解釋：

綠色信令攜帶了2個小區，黃色信令攜帶了1個小區，紅色信令中興認為攜帶了2個小區，華為認為沒有帶有效小區信息，于是把MSC儲存的小區信息的第一個下發給華為無線側。

造成以上分歧的原因是雙方對MAP41E版本的協議理解存在分歧，具體是對handback2Ul自應消息的處理機制存在分歧。handback2n向應消息有以下參數單元，如圖6協議截圖所示。

華為認為切換的目標小區信息應該放在CDMA2000HandoffResponselOSData的參數中。而中興認為應該放在CDMA2000CodeChannelList中。協議本身沒有明確規定一定要放在哪個參數中，只是說明兩個參數都可以攜帶小區信息。這樣導致了雙方在此信令的處理機制上有所不同。對于切換中只有一個小區的情況，由于是按照沒有攜帶信息就按照原來存儲的小區信息中的第一個下發給BSC的機制來處理的。因此，當切換目標小區為一個時，還可以成功進行切換；但當開啟硬切換宏分集功能，并且切換時申請多個小區時，就會導致上述現象出現。廠家反映類似問題在江蘇也出現過，當時是前向切換FacDir2REQ消息。因此，協議本身不明確導致不同廠家的處理機制存在分歧是本案例的主要原因。

2.4解決辦法

佛山側關閉了河口歐文萊基站所屬BSC的宏分集功能，現場DT測試，沒有再出現之前有規律的掉話，至此問題得到暫時性解決。但由于此解決辦法是以犧牲部分宏分集的性能為代價的，要根本解決此類問題，還需要制定協議的補充規范，把有關細節描述清楚，請相關廠家研發人員共同討論通過。然后再讓各廠家依照執行。

3結論

CDMA通信協議標準有一個發展和演進的過程，在應用的時候存在一定的漏洞或者模糊不清的地方。各廠家在按照協議對設備產品進行開發時，要積極向相關組織或部門提出，要求對協議進行澄清或修改。如不能及時修改，在算法的研發上也應盡量考慮多種可能性，做到對多方的兼容，這樣的設備生產出來才是實用的好設備。

中國電信目前作為全球最大的CDMA網絡運營商，在網絡的優化維護過程中，會碰到一些協議層面的系統性問題。相關研發單位需定期收集，深入研究，并及時出臺電信內部的標準補充規范；電信要做好各廠家間的裁判工作，積極推動各設備商的設備互聯互通。才能打造更優秀的CDMA網絡。