譚永全

（中國聯(lián)通廣東省分公司 廣州 510627）

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

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

1 研究背景

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

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

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

2.1 KPI分析

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

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

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

通過后臺信令跟蹤統(tǒng)計發(fā)現(xiàn)：90%的雙RAB掉話發(fā)生在CONVERSATIONAL_CS_SPEECH_12.2_12.2-INTERACTIVE_PS_64_64業(yè)務模式下。

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

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

2.2 Multi-RAB 路測與信令分析

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

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

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

從TEMS Log中我們發(fā)現(xiàn)異系統(tǒng)切換成功完成，沒有掉話產(chǎn)生。

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

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

圖3 信令流程

圖4 異系統(tǒng)切換時的RRC和RANAP網(wǎng)絡側信令流程

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

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

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

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

從B城市的測試結果看，TEMS Log中我們發(fā)現(xiàn)異系統(tǒng)切換同樣成功完成，沒有掉話產(chǎn)生。

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

在UETR中，異系統(tǒng)切換時的RRC和RANAP網(wǎng)絡側信令流程如圖6所示。

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

并且，統(tǒng)計數(shù)據(jù)中的counter pmNoSystemRab ReleaseSpeech和pmNo SystemRabReleasePacket都沒有跳轉。

圖5 Counter的值

圖6 異系統(tǒng)切換時的RRC和RANAP網(wǎng)絡側信令流程

圖7 信令流程

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

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

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

2.3 結論

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

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

3 解決建議

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

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

[1]3GPP規(guī)范：TS 125413-V3.0.0

[2]張長鋼, 李猛. WCDMA/HSDPA無線網(wǎng)絡優(yōu)化原理與實踐

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