異系統切換中的并發業務（Multi-RAB）掉話研究和優化

譚永全

（中國聯通廣東省分公司 廣州 510627）

WCDMA網絡以其優越的3G制式，給用戶帶來前所未有的體驗感受，高速的上網速率、豐富多彩的增值業務是吸引用戶的重要因素。而且WCDMA支持多業務同時進行，可以實現話音與上網同時使用，在WCDMA通信術語中通常叫做Multi-RAB，中文一般叫并發業務。

但目前由于3G處于建網初期，網絡覆蓋不完善，WCDMA網絡暫時不能實現連續覆蓋，所以在WCDMA信號較差時需要切換到2G網絡，就涉及到2G/3G互操作的問題，由于GSM網絡不支持多業務同時進行，這就引出本文的研究課題。本文就并發業務（Multi-RAB）在進行2G/3G互操作時造成的掉話進行分析和研究，找出異系統切換時造成掉話的原因并給出調整建議。

1 研究背景

目前中國聯通的WCDMA語音掉話率的目標值為 0.7%，圖1為廣東某地市（下稱A城市）的CS域掉話率走勢，由于目前用戶基數較少，在完成鄰區優化后掉話發生的小區仍比較分散并且有部分日期不達標,關于掉話率的分析我們在下文中做了進一步研究。

此地市為愛立信設備，RNC版本是CXP9012995_R6EB/32 P7.0。

2 問題分析定位和解決措施

2.1 KPI分析

A地市從2010年04月15～25日晚忙時在KPI統計中總共有132 次語音掉話。通過愛立信的優化工具GPEH跟蹤同一時間段中找到了134次語音RAB相關的system release事件，從GPEH的事件來分析掉話的原因。

圖2 語音RAB相關的system release事件分布

從圖2中可以看出大約20%的掉話是在 Multi-RAB的情況下發生的，也就是多業務并發的時候發生。由于其它80%的掉話比較分散，每天的掉話小區都沒有規律性，而且在一個小時內的掉話非常少，很難在短期內解決。對于掉話率的優化考慮在20%的Multi-RAB的掉話上。

通過后臺信令跟蹤統計發現：90%的雙RAB掉話發生在CONVERSATIONAL_CS_SPEECH_12.2_12.2-INTERACTIVE_PS_64_64業務模式下。

在這些 Multi-RAB(SPEECH_12.2+PS)的system release中，大多數的原因是Unspecified。所以我們不能直接從GPEH的信息中找到掉話原因。但是如果把這些Multi-RAB 掉話事件與異系統切換（IRAT Handover）執行事件結合起來，我們可以發現兩者之間有一定的聯系。

從圖3中可以看出，同一個Multi-RAB (SPEECH_12.2+PS)用戶在做完一次異系統切換（IRAT Handover）之后，緊接著就會發生一次掉話。而掉話的原因又是Unspecified。可見異系統切換（IRAT Handover）與這些掉話之間肯定有一定的關系。為了驗證這種猜測，接下來做了路測和信令分析。

2.2 Multi-RAB 路測與信令分析

首先通過模擬Multi-RAB異系統切換的場景進行了路測分析。

路測的場景是UE撥打語音電話之后開始做R99數據業務，然后在保持兩種業務的情況下做異系統間切換。

路測中使用愛立信OSS系統的UETR進行后臺跟蹤和TEMS 做前臺記錄，對比兩者進行分析。

從TEMS Log中我們發現異系統切換成功完成，沒有掉話產生。

但在UETR中，異系統切換時的RRC和RANAP網絡側信令流程如圖4所示。

在UETR中，在發生異系統切換到2G的信令后，核心網發送的IU release command信令(RAN發起的IU release request的回應) 帶的cause全部都是release-due-to-utran-generated-reason。

圖3 信令流程

圖4 異系統切換時的RRC和RANAP網絡側信令流程

同時，愛立信的統計數據中的兩個計數器 pmNo SystemRabReleaseSpeech和pmNoSystemRab ReleasePacket都發生了跳轉，（注：根據KPI公式，pmNoSystemRabReleaseSpeech代表語音掉話，pmNoSystemRabReleasePacket代表數據業務掉話），Counter的值如圖5所示。

RNC側收到核心網的release-due-to-utrangenerated-reason的釋放請求，認為是異常的掉話，將雙RAB中的CS域和PS域都計算為掉話。按照正常的流程，由于2G不支持雙RAB業務，在雙RAB業務進行3G->2G的切換時，應該CS域正常切換，PS域掛起。問題定位在核心網下發的Release的原因值上。

由于無線網發Iu-ReleaseRequest（原因值為successful-relocation）后，SGSN返回Iu-Release Command消息，原因值是release-due-to-utrangenerated-reason。也就是說核心網下發的原因值與無線側的原因值不一致。

目前廣東省在廣州和深圳都有SGSN，其中廣州SGSN是中興設備，而深圳SGSN是華為設備。上述的A城市是與廣州的中興SGSN相連。為了進一步驗證，我們選擇了連接深圳華為SGSN的B城市做同樣的測試。

從B城市的測試結果看，TEMS Log中我們發現異系統切換同樣成功完成，沒有掉話產生。

但是UETR的網絡側信令卻與A城市的結果有所不同。

在UETR中，異系統切換時的RRC和RANAP網絡側信令流程如圖6所示。

在UETR中，核心網發送的IU release command信令(RAN發起的IU release request的回應) 帶的cause是 successful-relocation，與無線網發的原因值一樣。

并且，統計數據中的counter pmNoSystemRab ReleaseSpeech和pmNo SystemRabReleasePacket都沒有跳轉。

圖5 Counter的值

圖6 異系統切換時的RRC和RANAP網絡側信令流程

圖7 信令流程

所以，在Multi-RAB的異系統切換中，如果核心網發送的IU release command信令(RAN發起的IU release request的回應) 帶的cause是release-due-to-utran-generated-reason,那么即使異系統切換成功，system RAB release（指示掉話）counter還是會跳轉。如果核心網發送的IU release command信令(RAN發起的IU release request的回應) 帶的原因值是successful-relocation，那么如果異系統切換成功，則system RAB release（指示掉話）counter正常，不會發生跳轉。

問題已經定位，是由于中興SGSN下發的release原因值與無線側的不一致，RNC側認為下發的原因值為release-due-to-utran-generated-reason的釋放指示后，認為是異常釋放而發生掉話的計數器跳轉。

查看3GPP資料，規范沒明確規定在這種情況下SGSN應該返回什么原因值，但從邏輯上講，華為SGSN的處理更合乎邏輯(華為的返回原因值與無線上報原因值一致)。

2.3 結論

從以上分析可知，在異系統成功切換之后，懷疑中興的SGSN發送的IU release command信令(RAN發起的IU release request的回應) 帶的release-due-to-utran-generated-reason cause，引起掉話計數器（pmNoSystemRabReleaseSpeech pmNoSystemRabReleasePacket）跳轉的問題。

而華為的SGSN發送的IU release command信令(RAN 發起的IU release request的回應) 帶的successful-relocation cause，則沒有此問題。

3 解決建議

建議中興SGSN把在異系統切換成功后回復IU release request的IU release command信令的cause從release-due-to-utran-generated-reason 改 為successful-relocation。其信令流程如圖7所示。

目前已定位問題所在，也得到中興和愛立信的雙方認可。由于SGSN的修改不能通過修改參數解決，需要打補丁進行整改，目前中興SGSN研發已列入開發計劃，在下一個版本中解決。

[1]3GPP規范：TS 125413-V3.0.0

[2]張長鋼, 李猛. WCDMA/HSDPA無線網絡優化原理與實踐

[3]愛立信參考文檔：Iu Release RANAP procedure