1.
測試發(fā)現(xiàn)某站點3個小區(qū)HSDPA、HSUPA、PS384均不可用，從測試軟件看出PDP上下文激活失敗，測試時RSCP、EC/IO均正常。

1.
更換終端，USIM卡測試問題依舊，檢查APN設(shè)置無誤，需檢查測試時無線環(huán)境。

2.
對數(shù)據(jù)卡進(jìn)行H業(yè)務(wù)時CDT跟蹤如下：

UE發(fā)射功率-25dbm，下行傳輸信道誤塊率0且RSCP、EC/IO正常，可以判斷測試時上下行無線質(zhì)量良好。
3.
通過信令還可以看出 CN RAB指配之后，RNC通知NODEB進(jìn)行無線鏈路重配置（RL_RECFG），在先前建立的RL中上行新建EDCH、下行HSDSCH信道且規(guī)定了相關(guān)傳輸信道及物理信道參數(shù)，同時也下發(fā)了RNC側(cè)傳輸層地址，為用戶面搭建數(shù)據(jù)通路在底層做好準(zhǔn)備。但是NODEB回應(yīng)RL_RECFG_FAIL原因值為：unspecified。由于RAB建立失敗所以PDP激活失敗，問題出在IUB口。
4.
分析RNC下發(fā)給NODEB的RL重配置準(zhǔn)備信令，消息截圖如下：

據(jù)此不難判斷在IUB口RNC決定將傳輸承載建立在FE上，這一點從IP地址我們可以清楚的看出，由于FE口故障所以RL 重配置失敗。
但是FE口存在故障告警，RNC為什么會將承載建立在IPPATH上？

5.
登錄RNC查詢傳輸資源映射表（LST TRMMAP）發(fā)現(xiàn)數(shù)據(jù)業(yè)務(wù)主用path為IPPATH，備用為AAL2PATH。但是當(dāng)主用PATH故障時應(yīng)切換至備用PATH。很明顯RNC側(cè)判斷IPPATH狀態(tài)正常故未能進(jìn)行主備倒換。

6.
RNC是根據(jù)IPPATH的ping檢測功能對其狀態(tài)進(jìn)行監(jiān)控，進(jìn)一步檢查IPPATH的ping檢測開關(guān)已經(jīng)打開，手動ping檢測發(fā)現(xiàn)RNC側(cè)ping NODEB正常，反向則超時失敗。很明顯FE口故障應(yīng)該ping不通，但是RNC側(cè)ping NODEB卻能成功，懷疑目的Nodeb IP地址不唯一。

7.
檢查NODEB側(cè)ETH地址設(shè)置發(fā)現(xiàn)該地址不唯一導(dǎo)致RNC誤ping至另一IPPATH正常的NODEB，修改NODEB側(cè)ETH地址。

處理結(jié)果：