【資料名稱】：PCHR信令碼詳細(xì)解析及問(wèn)題分析

【資料作者】：藍(lán)田玉

【資料日期】：2010-10-10

【資料語(yǔ)言】：中文

【資料格式】：DOC

【資料目錄和簡(jiǎn)介】：

RELOC PSOUT IU REL CMD TIMEOUT(436930520)
原因是3G網(wǎng)絡(luò)上進(jìn)行CS/PS并發(fā)業(yè)務(wù)時(shí)，CS業(yè)務(wù)順利切換至2G網(wǎng)絡(luò)，PS不能進(jìn)行3G向2G的切換，會(huì)被掛起，當(dāng)CS業(yè)務(wù)結(jié)束后，PS業(yè)務(wù)重新被激活。
CORRM OLPC ERROR(420579281)
一般是由于目標(biāo)小區(qū)擁塞或不可用，導(dǎo)致切換失敗。
RR_ERR_UU_IRCFC_PHY_CHANEL_FAIL(437127236)
這個(gè)就簡(jiǎn)單了，一般是無(wú)線鏈路質(zhì)量不佳，導(dǎo)致切換中物理信道重配失敗�？赡苡捎谠葱�區(qū)下行口空質(zhì)量差導(dǎo)致UE未收到RNC下發(fā)了重配指令，也可能目標(biāo)小區(qū)上行質(zhì)量差，導(dǎo)致UE無(wú)法與目標(biāo)小區(qū)同步或UE上報(bào)的物理信道重配完成消息沒(méi)有被目標(biāo)RNC收到。需要根據(jù)切換時(shí)源/目標(biāo)小區(qū)的電平、ISCP、上/下行鏈路錯(cuò)包率綜合判斷。
RELOC SYS HO UU HO FAIL(437127145)
是由于PS業(yè)務(wù)切換過(guò)程中存在小區(qū)更新導(dǎo)致。
DEL OLD CCB(437127121)
一般發(fā)生在2/3G切換過(guò)程中或跨RNC切換過(guò)程中。具體是否切換失敗需要看信令流程中是否存在RNC發(fā)起的IURelease消息。
RR_ERR_UU_IRCFC_UNSPECIFUED(437127238)
一般是由于終端原因?qū)е虑袚Q失敗。
SUCCESS(0)
這個(gè)原因，不知道你就查字典吧。
RB WAIT UE RB CFG TIMEOUT(437127148)
由于UE不返回RB建立完成消息而導(dǎo)致UE空口配置響應(yīng)定時(shí)器超時(shí)，導(dǎo)致的RAB失敗
CN GTPU FAILURE
UE去激活PDP請(qǐng)求后，還在用戶面上發(fā)數(shù)據(jù)，而CN由于收到終端的去激活PDP請(qǐng)求后，會(huì)釋放GTPU隧道，所以這時(shí)CN會(huì)認(rèn)為終端上發(fā)的用戶面數(shù)據(jù)非法，把這個(gè)信息告知RNC，RNC則會(huì)發(fā)起RAB釋放。(UE與CN兼容問(wèn)題導(dǎo)致PS掉話問(wèn)題)

DEL OLD CCB
詳細(xì)解釋處理建議
RNC下發(fā)RRC CON SETUP，在RRC等待響應(yīng)定時(shí)器超時(shí)前沒(méi)有收到RRC CON Complete消息1) 如果存在弱覆蓋，優(yōu)化重選參數(shù)；
2) 如果上行存在干擾，檢查是否集中到每個(gè)載頻和時(shí)隙，打開載波均分和時(shí)隙均分
Ø DEL OLD CCB原因的掉話是網(wǎng)絡(luò)側(cè)未釋放資源的情況下UE已主動(dòng)釋放，UE檢測(cè)到狀態(tài)異常發(fā)起位置更新，觸發(fā)RNC側(cè)的“資源重疊”，從而發(fā)起Iu釋放。其根本原因是由于無(wú)線環(huán)境導(dǎo)致失步，但是網(wǎng)絡(luò)側(cè)與UE側(cè)對(duì)于失步判決不嚴(yán)格一致，出現(xiàn)兩端狀態(tài)不一致的情況。從無(wú)線環(huán)境優(yōu)化入手減少失步情況發(fā)生。
RNC下發(fā)PHY CHAN RECFG，收到了UE發(fā)上的PHY CHAN FAILURE


RB CU OVERLAP BACK(437127150)
RB建立和CELLUPDATE嵌套　UE下行沒(méi)有收到RB SETUP，發(fā)生了CELLUPDATE，一般發(fā)生在弱覆蓋地方優(yōu)化重選參數(shù)



PDCP Failure
When there is no TEID, a PDCP failure cause is transmitted to the PDCP and the user data are abandoned at step S 720 .
When the tunnel is created and an up-link user data are received from eNodeB at step S 711 , an up-link protocol message (UL_UNIT_DATA) is decoded and the tunnel state of the tunnel management table is checked for validity of the received TEID at step S 713 .
As checked, when the tunnel state of the received TEID is idle, which is not valid, a transmission failure cause is transmitted to the eNodeB 721 .

RLC Failure SRB Reset
RLC Failure TRB Reset
UE SECU MODE TIMEOUT
如果僅僅是根據(jù)CHR查看的話，應(yīng)該是看不到整個(gè)呼叫流程的。如果你確定是掉話的話，可能是在這種情況下發(fā)生的：
之前一直進(jìn)行的是CS的長(zhǎng)呼業(yè)務(wù)，此時(shí)并發(fā)進(jìn)行ps業(yè)務(wù)，又恰好在此時(shí)UE進(jìn)行了跨RNC的切換,在重新進(jìn)行安全模式鑒定時(shí)超時(shí)。在PS域默認(rèn)為一次未接通，但在CS域則記為一次掉話，最后在CHR里呈現(xiàn)的時(shí)候，呈現(xiàn)為一次掉話。（具體為什么呈現(xiàn)掉話而不是未接通，有待繼續(xù)深究）。
在現(xiàn)網(wǎng)中，如果存在2個(gè)以上核心網(wǎng)的話，在跨RNC同時(shí)跨核心網(wǎng)側(cè)的時(shí)候有可能會(huì)出現(xiàn)這種原因的掉話，掉話原因?yàn)閁E security mode time out，但究其為什么掉話，應(yīng)該是核心網(wǎng)側(cè)的問(wèn)題，暫時(shí)由于學(xué)疏無(wú)法解答。

IUB RL FAILURE IND(436996134)
NODE B發(fā)NBAP RLFAIL IND。 雙擊該信令我們就會(huì)看到他所攜帶的同步失敗的信息：Cause為radioNetwork：synchronlsation-failure。處理定位：首先看是否存在硬件故障，后臺(tái)觀察是否存在干擾（如ISCP），觀察該小區(qū)參數(shù)（如SIR、干擾余量）與其它小區(qū)的區(qū)別。定位解決問(wèn)題。