CDMA項(xiàng)目典型案例總結(jié)(第四期)

1、CDMA項(xiàng)目典型案例總結(jié)第四期 TIME yyyy年M月 2008年11月目 錄 TOC o 1-3 h z u HYPERLINK l _Toc189458065 1接入問(wèn)題總結(jié) PAGEREF _Toc189458065 h 4 HYPERLINK l _Toc189458066 1.1被叫建立時(shí)間過(guò)長(zhǎng)（鄧楊） PAGEREF _Toc189458066 h 4 HYPERLINK l _Toc189458067 1.2UPE某些基站被叫成功率低問(wèn)題（羅龍智） PAGEREF _Toc189458067 h 6 HYPERLINK l _Toc189458068 1.3UPE新BSC被叫建

2、立成功率低問(wèn)題 (鄧楊) PAGEREF _Toc189458068 h 10 HYPERLINK l _Toc189458069 1.4UPE A1接口失敗案例（羅龍智） PAGEREF _Toc189458069 h 12 HYPERLINK l _Toc189458070 1.5新加基站只能做主叫不能做被叫案例（田延峰） PAGEREF _Toc189458070 h 14 HYPERLINK l _Toc189458071 1.6CE License不足導(dǎo)致呼叫建立成功率下降問(wèn)題-（田明華） PAGEREF _Toc189458071 h 14 HYPERLINK l _Toc1894

3、58072 1.7BSC的一個(gè)子系統(tǒng)下大量A1接口失敗問(wèn)題（田延峰） PAGEREF _Toc189458072 h 17 HYPERLINK l _Toc189458073 1.8BSC的一個(gè)子系統(tǒng)下所有用戶無(wú)法撥打電話問(wèn)題（田延峰） PAGEREF _Toc189458073 h 17 HYPERLINK l _Toc189458074 1.9通過(guò)提高帶內(nèi)信令幀增益提高呼建成功率（徐斌斌） PAGEREF _Toc189458074 h 18 HYPERLINK l _Toc189458075 1.10GPM未攜帶缺省業(yè)務(wù)選項(xiàng)導(dǎo)致某些手機(jī)無(wú)法做被叫（徐斌斌） PAGEREF _Toc189

4、458075 h 18 HYPERLINK l _Toc189458076 1.11硬指配開(kāi)啟后各載波呼叫嘗試次數(shù)嚴(yán)重不均（徐斌斌） PAGEREF _Toc189458076 h 19 HYPERLINK l _Toc189458077 1.12通過(guò)CE資源池配置解決載波間CE分配問(wèn)題（徐斌斌） PAGEREF _Toc189458077 h 21 HYPERLINK l _Toc189458078 1.13一個(gè)BTS的指標(biāo)突然變差的解決偶然方法（田延峰） PAGEREF _Toc189458078 h 21 HYPERLINK l _Toc189458079 1.14UPE A1 接口失敗

5、問(wèn)題(鄧楊) PAGEREF _Toc189458079 h 22 HYPERLINK l _Toc189458080 1.15孖機(jī)造成話統(tǒng)統(tǒng)計(jì)“A1 Interface Failures”的問(wèn)題（李瑞昕） PAGEREF _Toc189458080 h 22 HYPERLINK l _Toc189458081 1.16最大小區(qū)半徑配置錯(cuò)誤導(dǎo)致一個(gè)載扇的資源無(wú)法建立（邸玉波） PAGEREF _Toc189458081 h 26 HYPERLINK l _Toc189458082 1.17TATA用戶接入Reliance的網(wǎng)絡(luò)造成的A1接口失敗（邸玉波） PAGEREF _Toc1894580

6、82 h 26 HYPERLINK l _Toc189458083 1.18局間鏈路不足導(dǎo)致A1接口失敗（鄭晗） PAGEREF _Toc189458083 h 27 HYPERLINK l _Toc189458084 1.19CMUX板資源吊死導(dǎo)致呼叫建立成功率低問(wèn)題（邸玉波） PAGEREF _Toc189458084 h 29 HYPERLINK l _Toc189458085 1.20326基站接入成功率低問(wèn)題（姜偉） PAGEREF _Toc189458085 h 31 HYPERLINK l _Toc189458086 2掉話問(wèn)題總結(jié) PAGEREF _Toc189458086 h

7、 32 HYPERLINK l _Toc189458087 2.1跨信令點(diǎn)手機(jī)輔助硬切換掉話分析(王一兵) PAGEREF _Toc189458087 h 32 HYPERLINK l _Toc189458088 2.2PN復(fù)用鄰區(qū)錯(cuò)配導(dǎo)致掉話率高的問(wèn)題（田明華） PAGEREF _Toc189458088 h 35 HYPERLINK l _Toc189458089 2.3新開(kāi)站PN復(fù)用距離不足導(dǎo)致周邊站點(diǎn)掉話率惡化（李向陽(yáng)） PAGEREF _Toc189458089 h 35 HYPERLINK l _Toc189458090 2.4利用PSMM優(yōu)化鄰區(qū)不當(dāng)導(dǎo)致高掉話率（剛偉） PAGE

8、REF _Toc189458090 h 37 HYPERLINK l _Toc189458091 2.5直放站參數(shù)不合理導(dǎo)致掉話率高（徐斌斌） PAGEREF _Toc189458091 h 39 HYPERLINK l _Toc189458092 2.6124基站無(wú)法與周邊基站軟切換導(dǎo)致掉話率高問(wèn)題（姜偉） PAGEREF _Toc189458092 h 40 HYPERLINK l _Toc189458093 3切換問(wèn)題總結(jié) PAGEREF _Toc189458093 h 42 HYPERLINK l _Toc189458094 3.1BSC間軟切換與呼叫遷移案例分析(王一兵) PAGER

9、EF _Toc189458094 h 42 HYPERLINK l _Toc189458095 3.2UPE Varanasi軟切換成功率低的分析(羅龍智) PAGEREF _Toc189458095 h 44 HYPERLINK l _Toc189458096 3.3框間軟切換鏈路帶寬不足導(dǎo)致軟切換比例下降和掉話率上升（李向陽(yáng)） PAGEREF _Toc189458096 h 48 HYPERLINK l _Toc189458097 3.4MSC間呼叫遷移案例(羅龍智) PAGEREF _Toc189458097 h 50 HYPERLINK l _Toc189458098 3.5PARC

10、BSC下成片基站軟切換成功率Rehoming后變差分析（田延峰） PAGEREF _Toc189458098 h 54 HYPERLINK l _Toc189458099 3.6硬切換后語(yǔ)音雙不通的問(wèn)題（田延峰） PAGEREF _Toc189458099 h 54 HYPERLINK l _Toc189458100 3.7手機(jī)輔助硬切換手機(jī)異頻搜索影響軟切換導(dǎo)致掉話（徐斌斌） PAGEREF _Toc189458100 h 54 HYPERLINK l _Toc189458101 3.8手機(jī)輔助硬切換參數(shù)配置不合理影響語(yǔ)音質(zhì)量（徐斌斌） PAGEREF _Toc189458101 h 55

11、HYPERLINK l _Toc189458102 3.9手機(jī)輔助硬切換時(shí)異頻鄰區(qū)配置過(guò)多導(dǎo)致掉話率過(guò)高（徐斌斌） PAGEREF _Toc189458102 h 56 HYPERLINK l _Toc189458103 3.10A3A7軟切換成功率降低(A3鏈路建立失敗)（吳挺智） PAGEREF _Toc189458103 h 57 HYPERLINK l _Toc189458104 3.11A3A7軟切換全部失敗問(wèn)題（吳挺智） PAGEREF _Toc189458104 h 57 HYPERLINK l _Toc189458105 3.12REHOMING后基站無(wú)法進(jìn)行軟切換和更軟切換（

12、吳挺智） PAGEREF _Toc189458105 h 58 HYPERLINK l _Toc189458106 3.13UPE某個(gè)基站軟切換成功率低問(wèn)題（鄧楊） PAGEREF _Toc189458106 h 58 HYPERLINK l _Toc189458107 4FER高問(wèn)題 PAGEREF _Toc189458107 h 59 HYPERLINK l _Toc189458108 4.1Charoda site FFER problem Analysis Case(姜偉) PAGEREF _Toc189458108 h 59 HYPERLINK l _Toc189458109 4.2

13、15L星卡問(wèn)題描述以及處理（高林祥） PAGEREF _Toc189458109 h 62 HYPERLINK l _Toc189458110 4.3搜索窗設(shè)置不當(dāng)導(dǎo)致無(wú)法軟切換，F(xiàn)ER高（鄧楊） PAGEREF _Toc189458110 h 64 HYPERLINK l _Toc189458111 4.4導(dǎo)頻污染導(dǎo)致FER高（鄧楊） PAGEREF _Toc189458111 h 65 HYPERLINK l _Toc189458112 4.5“衛(wèi)星鏈路時(shí)延調(diào)整開(kāi)關(guān)”未打開(kāi)造成前向FER高的問(wèn)題（李瑞昕） PAGEREF _Toc189458112 h 65 HYPERLINK l _To

14、c189458113 4.6FER問(wèn)題的現(xiàn)象與處理方法總結(jié) （羅龍智） PAGEREF _Toc189458113 h 68 HYPERLINK l _Toc189458114 5數(shù)據(jù)業(yè)務(wù) PAGEREF _Toc189458114 h 71 HYPERLINK l _Toc189458115 5.1UPE 數(shù)據(jù)業(yè)務(wù)呼建差案例(羅龍智) PAGEREF _Toc189458115 h 71 HYPERLINK l _Toc189458116 5.2PS CSSR 突然下降的問(wèn)題總結(jié)（李向陽(yáng)） PAGEREF _Toc189458116 h 72 HYPERLINK l _Toc18945811

15、7 5.3Kerala數(shù)據(jù)業(yè)務(wù)速率低問(wèn)題（姜偉） PAGEREF _Toc189458117 h 75 HYPERLINK l _Toc189458118 6其他問(wèn)題總結(jié) PAGEREF _Toc189458118 h 83 HYPERLINK l _Toc189458119 6.1整個(gè)BSC語(yǔ)音質(zhì)量變差的問(wèn)題（田延峰） PAGEREF _Toc189458119 h 83 HYPERLINK l _Toc189458120 6.2MAPINFO圖層坐標(biāo)系不同導(dǎo)致CAIT導(dǎo)入地圖，道路信息和站點(diǎn)信息顯示相差甚遠(yuǎn)（高林祥） PAGEREF _Toc189458120 h 83 HYPERLINK

16、 l _Toc189458121 6.3E1/T1鏈路告警查詢方法（陳世進(jìn)） PAGEREF _Toc189458121 h 87 HYPERLINK l _Toc189458122 6.4無(wú)法增加鄰區(qū)（吳挺智） PAGEREF _Toc189458122 h 91 HYPERLINK l _Toc189458123 6.5小區(qū)半徑設(shè)置不合理導(dǎo)致直放站不能工作（邸玉波） PAGEREF _Toc189458123 h 91 HYPERLINK l _Toc189458124 6.6Kinpo手機(jī)在華為網(wǎng)絡(luò)下通話中自動(dòng)重啟(徐斌斌) PAGEREF _Toc189458124 h 92 HYPE

17、RLINK l _Toc189458125 6.7How to connect two test mobiles to one Laptop（田延峰） PAGEREF _Toc189458125 h 94 HYPERLINK l _Toc189458126 6.8RSSI處理案例總結(jié)(鄭晗) PAGEREF _Toc189458126 h 95 HYPERLINK l _Toc189458127 6.9Reg_Zone配置錯(cuò)誤導(dǎo)致RSSI上升基站呼建和掉話指標(biāo)變差（屈柯） PAGEREF _Toc189458127 h 108 HYPERLINK l _Toc189458128 6.10扇區(qū)分

18、集接收沒(méi)有連接的判斷方法（王一兵） PAGEREF _Toc189458128 h 111 HYPERLINK l _Toc189458129 6.11GU控制工程質(zhì)量的經(jīng)驗(yàn)（田延峰） PAGEREF _Toc189458129 h 113 HYPERLINK l _Toc189458130 6.12利用Nastar進(jìn)行鄰區(qū)優(yōu)化的經(jīng)驗(yàn)（鄭晗） PAGEREF _Toc189458130 h 114 HYPERLINK l _Toc189458131 6.13BCKM板未插緊導(dǎo)致基站覆蓋異常（徐斌斌） PAGEREF _Toc189458131 h 115 CDMA項(xiàng)目典型案例總結(jié)第四期接入問(wèn)題

19、總結(jié)被叫建立時(shí)間過(guò)長(zhǎng)（鄧楊）【現(xiàn)象描述】在對(duì)allahabad BSC的118基站進(jìn)行主被叫測(cè)試時(shí)，發(fā)現(xiàn)被叫建立時(shí)間過(guò)長(zhǎng)，大概需要2.5秒左右，而主叫建立時(shí)間正常，基本保持在1秒左右?！締?wèn)題分析】從信令流程來(lái)看，時(shí)間主要消耗在發(fā)送ECAM消息這里，ECAM與前一條信令之間有1.5秒左右的時(shí)間間隔，選取lucknow BSC1的166基站被叫信令（主被叫均正常）與之對(duì)比（見(jiàn)下圖）圖1.Allahabad BSC的118站被叫信令流程圖2.Lucknow BSC1的166站被叫信令流程通過(guò)對(duì)比發(fā)現(xiàn)：allahabad BSC在收到MSC下發(fā)的Assignment Request之間就開(kāi)始建立Abi

20、s鏈路，而lucknow BSC1是在收到MSC下發(fā)的Assignment Request之后才開(kāi)始建立Abis鏈路，通過(guò)查詢CMM模塊30號(hào)軟參，發(fā)現(xiàn)是打開(kāi)了并行指配開(kāi)關(guān)所致，于是懷疑是信令流程的改變導(dǎo)致在下發(fā)ECAM之前有1.5秒左右的延時(shí)，在將并行指配開(kāi)關(guān)關(guān)閉之后，信令流程恢復(fù)正常，但在下發(fā)ECAM之前依然存在1.5秒左右的延時(shí)，如下圖：圖3.關(guān)閉并行指配開(kāi)關(guān)后的信令流程后將問(wèn)題提交研發(fā)定位：因?yàn)锳llahabad BSC的CCM模塊29號(hào)軟參設(shè)置為0 x7，即打開(kāi)了ECAM延遲發(fā)送開(kāi)關(guān)，導(dǎo)致被叫建立時(shí)間過(guò)長(zhǎng)?！咎幚泶胧繉⒃搮?shù)修改為“0 x00000000”之后，被叫建立時(shí)間保持在1

21、秒左右，恢復(fù)正常。如下圖：圖4.修改29號(hào)軟參后的信令流程【總結(jié)】由于CCM模塊29號(hào)軟參只對(duì)被叫起作用，因此出現(xiàn)主叫建立時(shí)間正常，而被叫建立時(shí)間過(guò)長(zhǎng)的現(xiàn)象。UPE某些基站被叫成功率低問(wèn)題（羅龍智）【現(xiàn)象描述】I國(guó)R項(xiàng)目Lucknow BSC2下的某些站點(diǎn)“CS Term Call Setup Success Ratio%”指標(biāo)不好（88%90%），但“CS Orig Call Setup Success Ratio%”卻很好（98%99%）。如下：【問(wèn)題分析】分析Runlog日志（基站所在框）主要失敗原因?yàn)椤安东@反向業(yè)務(wù)信道前導(dǎo)幀失敗”(0 x2702)此原因值按IMSI統(tǒng)計(jì)發(fā)現(xiàn)有很多IMS

22、I的失敗次數(shù)高達(dá)幾十次，非常多（如下圖所示）。于是從MSC側(cè)查詢了關(guān)于這些IMSI的信息，發(fā)現(xiàn)這些IMSI的Origination ID(OI)大部分均為244或243，說(shuō)明這些用戶大部分都是無(wú)線公話，終端類型為FWT。由于終端類型是無(wú)線公話，于是選了一個(gè)公話做測(cè)試并跟了信令流程。當(dāng)無(wú)線終端的話筒處于正常置放狀態(tài)(on-hook position)，信令流程正常，呼建成功。當(dāng)無(wú)線公話終端的話筒未放置在座機(jī)上（off-hook position），則被叫失敗，如下信令流程：從測(cè)試中我們可以看到，被叫的過(guò)程中，終端是收到了尋呼消息并響應(yīng)了尋呼，這時(shí)系統(tǒng)認(rèn)為無(wú)線公話終端處于空閑態(tài)對(duì)其下發(fā)ECAM進(jìn)行

23、資源指配，但是在此之后，無(wú)線終端并未有在Um空口上發(fā)送反向前導(dǎo)幀，等待超時(shí)后統(tǒng)計(jì)為BTS捕獲反向前導(dǎo)幀失敗，BSC向MSC發(fā)送“Assignment Failure”，而在KPI統(tǒng)計(jì)的時(shí)候卻把這種非正常的捕獲反向前導(dǎo)統(tǒng)計(jì)了進(jìn)去，使得Term CSSR變差?！究偨Y(jié)】在呼建成功率中，如果發(fā)現(xiàn)主叫呼建正常，而被叫呼建很差時(shí)，可試著分析這些基站所在框的SPU日志,看是否有某些IMSI的失敗原因?yàn)椤安蹲椒聪驑I(yè)務(wù)前導(dǎo)幀失敗”的次數(shù)很多，并查詢MSC側(cè)的OI信息判斷這些終端是否為無(wú)線公話終端FWT。如果是則說(shuō)明被叫呼建成功率低是由無(wú)線公話終端引起，并且信令流程在這種特殊情況是不合理的。以上問(wèn)題只是個(gè)別類型的

24、終端才有。對(duì)于華為固定臺(tái)，會(huì)先把呼叫流程都走完之后（BSC發(fā)送Assignment complete給MSC）再由MSC據(jù)掉，這種情況下會(huì)統(tǒng)計(jì)為呼叫建立成功。UPE新BSC被叫建立成功率低問(wèn)題 (鄧楊)【現(xiàn)象描述】Varanasi BSC3自開(kāi)通以來(lái)，出現(xiàn)大量A口失敗，被叫建立成功率非常低，只有50%多。該BSC是PARC平臺(tái)的新BSC，掛在新的Varanasi MSC1下面。【問(wèn)題分析】B側(cè)和N側(cè)查詢A口配置，均正常，也無(wú)告警。分析runlog日志，失敗原因?yàn)?704，等待指配超時(shí)。選出指配超時(shí)出現(xiàn)較多的IMSI在維護(hù)臺(tái)跟蹤，發(fā)現(xiàn)指配超時(shí)均出現(xiàn)在作被叫時(shí)。再次聯(lián)系N側(cè)查詢相關(guān)配置，發(fā)現(xiàn)該MS

25、C打開(kāi)了早尋呼開(kāi)關(guān)。以下是關(guān)閉早尋呼的局間呼叫處理流程：關(guān)閉早尋呼的情況下，被叫端MSC/VLR在收到主叫端MSC/VLR發(fā)送的入局消息(IAI/AM)之后再進(jìn)行尋呼。但是當(dāng)打開(kāi)早尋呼之后，被叫端MSC/VLR在收到HLR發(fā)送的請(qǐng)求漫游號(hào)碼消息(ROUTREQ)之后，并不是直接回送漫游號(hào)碼，而是先進(jìn)行尋呼，當(dāng)尋呼到被叫手機(jī)之后，再回送漫游號(hào)碼，那么這樣就存在兩個(gè)延時(shí)，可能會(huì)最終導(dǎo)致指配失?。河捎诒唤卸薓SC/VLR在收到HLR的請(qǐng)求漫游號(hào)碼消息(ROUTREQ)之后，先進(jìn)行尋呼，待收到尋呼響應(yīng)之后，再向HLR回送漫游號(hào)碼，也就是說(shuō)，打開(kāi)早尋呼的情況下，被叫端MSC/VLR回送漫游號(hào)碼相對(duì)于關(guān)閉

26、早尋呼情況下會(huì)有一定延時(shí)，這個(gè)延時(shí)就是MSC下發(fā)尋呼到收到尋呼響應(yīng)這段時(shí)間，通過(guò)觀察跟蹤的信令來(lái)看，大致在2-3秒，有可能在延時(shí)的2-3秒時(shí)間里，等待HLR的locreq響應(yīng)定時(shí)器和等待服務(wù)MSC的routreq響應(yīng)定時(shí)器已經(jīng)超時(shí)，那么，被叫端MSC/VLR就不會(huì)收到主叫端發(fā)送的入局消息，被叫端MSC也不會(huì)下發(fā)指配請(qǐng)求，最終BSC等待指配超時(shí)。關(guān)閉早尋呼的情況下，BSC上報(bào)了尋呼響應(yīng)之后，被叫端MSC可以直接下發(fā)指配。當(dāng)打開(kāi)早尋呼時(shí)，被叫端MSC收到尋呼響應(yīng)之后還要向HLR回送漫游號(hào)碼，HLR向主叫端MSC/VLR送路由信息，最后主叫端MSC/VLR向被叫端MSC/VLR發(fā)送入局消息，之后被叫

27、端MSC/VLR才能向BSC下發(fā)指配，那么，這里就多出了3條信令的延時(shí)，如果這3條信令的延時(shí)可能會(huì)造成指配的時(shí)間超過(guò)6秒，BSC由于等待指配超時(shí)向手機(jī)下發(fā)release order，造成被叫建立失敗?！咎幚泶胧縉側(cè)將Varanasi MSC1的早尋呼開(kāi)關(guān)關(guān)閉之后，被叫建立成功率上升到99%左右。【總結(jié)】早尋呼開(kāi)關(guān)打開(kāi)對(duì)N側(cè)的接通率指標(biāo)提升有幫助，但是對(duì)于BSC這邊的指標(biāo)影響很大，遇到此類問(wèn)題多與N側(cè)溝通，看看是否是N側(cè)那邊的相關(guān)設(shè)置導(dǎo)致A口失敗。UPE A1接口失敗案例（羅龍智）【現(xiàn)象描述】Varanasi從2007.12.11號(hào)開(kāi)始呼建中出現(xiàn)很多A1接口失?。ň唧w還可見(jiàn)附件），失敗原因?yàn)?

28、 x2704(等待MSC指配請(qǐng)求超時(shí)失敗)，特別是忙時(shí)由百次上升到了上千次。【問(wèn)題分析】關(guān)于A口失敗一般都是B側(cè)和N側(cè)數(shù)據(jù)配置可能出現(xiàn)問(wèn)題，所以當(dāng)確認(rèn)RF側(cè)各BSC級(jí)參數(shù)無(wú)問(wèn)題后，向B側(cè)與N側(cè)工程師求助聯(lián)合定位。定位過(guò)程中，N側(cè)工程師反映數(shù)據(jù)配置沒(méi)有問(wèn)題，但說(shuō)承載網(wǎng)（STP）那邊有擁塞告警和閃斷，所以懷疑是客戶的承載網(wǎng)出了問(wèn)題，準(zhǔn)備通知客戶。 通知客戶后第二天A1接口失敗次數(shù)減少到正常情況?！究偨Y(jié)】一般遇到A接口失敗，可按以下思路進(jìn)行分析：BSC與MSC間的鏈路是否出現(xiàn)了問(wèn)題，配置是否正確；BSC與MSC的配置是否做到了一致，包括鏈路雙工模式是否一致，IP配置是否一致（MSC加的IP是否包含了

29、所有BSC的IP），鏈路協(xié)商模式是否一致（包括了協(xié)議的公有和私有協(xié)義設(shè)置）MSC與HLR鏈路是否正常，HLR的定時(shí)器設(shè)置是否合理；BSC與MSC間的網(wǎng)口端口等是否自動(dòng)重啟或斷了；承載網(wǎng)是否有擁塞和閃斷；如果是PARC平臺(tái)的BSC，MSC側(cè)的早尋呼開(kāi)關(guān)是否打開(kāi)，打開(kāi)的話會(huì)影響被叫成功率，而失敗原因也多半為0 x2704等待指配請(qǐng)求超時(shí)在呼叫遷移過(guò)程中，BSC間的呼叫遷移如果出現(xiàn)A2接口失敗，請(qǐng)查看A2p格式是否為標(biāo)準(zhǔn)格式；新加基站只能做主叫不能做被叫案例（田延峰）【現(xiàn)象描述】 PAC BSC下新加基站后，發(fā)現(xiàn)只能做主叫，被叫嘗試次數(shù)為零?！締?wèn)題分析】分析基站所有參數(shù)與KPI指標(biāo)，發(fā)現(xiàn)除被叫嘗試次

30、數(shù)為零以外，其他指標(biāo)均正常；重啟BTS，問(wèn)題仍在。（曾經(jīng)發(fā)現(xiàn)實(shí)驗(yàn)站出現(xiàn)過(guò)此相同問(wèn)題，重啟后解決）。發(fā)現(xiàn)幾個(gè)具有相同問(wèn)題的基站位于同一個(gè)XPU框，且為新加基站。【處理措施】檢查MSC下添加的BSC子系統(tǒng)，發(fā)現(xiàn)此XPU框?qū)儆谛伦酉到y(tǒng)，但是在MSC下沒(méi)有添加，造成此子系統(tǒng)下的所有用戶只能做主叫，而被叫尋呼不到，從而被叫全不通。添加子系統(tǒng)后，網(wǎng)絡(luò)正常。【問(wèn)題總結(jié)】處理問(wèn)題時(shí)一定要搞清楚故障發(fā)生的范圍，是僅僅發(fā)生在某個(gè)基站，還是發(fā)生在某個(gè)框，還是發(fā)生在整個(gè)BSC，還是整個(gè)MSC。故障范圍清晰了，定位的方向也就明確了。CE License不足導(dǎo)致呼叫建立成功率下降問(wèn)題-（田明華）【現(xiàn)象描述】1月5日在對(duì)R

31、ajathan Circle 的Jaipur-bsc1進(jìn)行KPI監(jiān)控時(shí)發(fā)現(xiàn)： 351號(hào)基站（S3/3/3）3個(gè)扇區(qū)在1月2、3、4日連續(xù)三天忙時(shí)（19；00-20；00），出現(xiàn)了明顯的呼叫建立成功率降低的問(wèn)題，掉話率為1%-2%。利用nastar生成的分析表可以看出，在忙時(shí)呼叫嘗試次數(shù)明顯升高和話務(wù)量明顯增加的情況下，呼叫建立失敗的主要原因?yàn)椋褐概滟Y源失?。–S Call Resource Allocation Failures）?！締?wèn)題分析與解決】呼叫建立成功率隨時(shí)間有規(guī)律的變化，很明顯與話務(wù)量有關(guān)系。每個(gè)載扇均有此問(wèn)題，大致判斷問(wèn)題可能出現(xiàn)在鏈路，CK，CP板。查詢告警信息，無(wú)告警。檢查在

32、TCH Assignment Failures未發(fā)現(xiàn)walsh和power不足導(dǎo)致的擁塞。該基站所屬IP框下其他基站呼叫建立成功率良好，也排除FMR的問(wèn)題。檢查鏈路帶寬配置充足。檢查E1，配置兩條，而CE話務(wù)量只有235Erl左右，兩條E1是足夠的。用OMStar分析日志以檢查CE情況，存在大量原因值為212的接入失敗，原因值解釋如下：查看212原因值分布，均分布在15f（十六進(jìn)制數(shù)，轉(zhuǎn)化為十進(jìn)制為351）這個(gè)基站的三個(gè)扇區(qū)上。對(duì)該問(wèn)題時(shí)段進(jìn)行分析，主要出現(xiàn)在忙時(shí)（19：00-20：00）：隨后在維護(hù)終端利用命令：DSP CBTSLICENSE 查詢得知：該基站配置了256個(gè)CE LICENS

33、E利用命令：MOD BSCBTSINF 將256修改為512后，觀察當(dāng)日晚忙時(shí)呼叫建立成功率，發(fā)現(xiàn)恢復(fù)正常。如下：【問(wèn)題總結(jié)】目前引入了CE License，在分析指配資源失敗時(shí)需要關(guān)注。由于CE License不足導(dǎo)致的接入失敗原因值為212。查詢CE License配置的命令：DSP CBTSLICENSE，修改命令為：MOD BSCBTSINF。BSC的一個(gè)子系統(tǒng)下大量A1接口失敗問(wèn)題（田延峰）【現(xiàn)象描述】 PAC下大量基站發(fā)現(xiàn)呼叫建立成功率下降，失敗原因都是“A1接口失敗”?！締?wèn)題分析】發(fā)現(xiàn)所有存在問(wèn)題基站屬于同一個(gè)子系統(tǒng)。B側(cè)N側(cè)均未修改過(guò)任何參數(shù)。從BSC接口板 ping包到MSC

34、，發(fā)現(xiàn)有丟包現(xiàn)象。【處理措施】在嘗試了各種方法都無(wú)法解決的情況下，重新插拔BSC到LANSWITCH的E1，問(wèn)題解決。BSC的一個(gè)子系統(tǒng)下所有用戶無(wú)法撥打電話問(wèn)題（田延峰）【現(xiàn)象描述】BSC的一個(gè)子系統(tǒng)下所有用戶無(wú)法撥打電話問(wèn)題，呼叫失敗原因?yàn)椤癆1接口失敗”，呼叫建立成功率為0?！咎幚泶胧繉z查從BSC到MSC之間鏈路不通。無(wú)法解決的情況下，刪除BSC到MSC之間的鏈路，重新添加后，問(wèn)題解決。通過(guò)提高帶內(nèi)信令幀增益提高呼建成功率（徐斌斌）【案例索引關(guān)鍵詞】呼叫建立成功率、帶內(nèi)信令幀增益【案例描述】I國(guó)搬遷項(xiàng)目中，分析某BSC的總體性能指標(biāo)，發(fā)現(xiàn)整網(wǎng)接入成功率僅有96左右，主要為A口失敗和空

35、口失敗，其中空口失敗中有1/4左右是信令交互失敗。【處理過(guò)程】分析發(fā)現(xiàn)該BSC下均為郊區(qū)站點(diǎn)，站距較大。從話統(tǒng)中看到前向FER偏高。另外由于呼建失敗中信令交互失敗較多，因此分析時(shí)由于郊區(qū)的覆蓋不強(qiáng)導(dǎo)致前向誤幀高，從而影響了呼叫建立成功率。分析該BSC下各站的負(fù)荷不高，因此開(kāi)啟了帶內(nèi)信令幀提升增益功能，對(duì)所有信令交互失敗多的站提升信令幀增益3dB。調(diào)整后通過(guò)話統(tǒng)對(duì)比分析，對(duì)呼建性能大有所改善。對(duì)各個(gè)站分布做了具體分析和優(yōu)化，優(yōu)化后總體呼建達(dá)到了98以上。【結(jié)論】對(duì)于呼叫建立失敗中信令交互失敗多的場(chǎng)景，可以嘗試提高帶內(nèi)信令幀增益，以提高信令的穩(wěn)定交互，從而提升呼叫建立性能。GPM未攜帶缺省業(yè)務(wù)選項(xiàng)

36、導(dǎo)致某些手機(jī)無(wú)法做被叫（徐斌斌）【案例索引關(guān)鍵詞】主叫、被叫、業(yè)務(wù)選項(xiàng)、手機(jī)兼容性【案例描述】I國(guó)搬遷項(xiàng)目中，客戶投訴搬遷之前能夠正常呼叫的手機(jī)，在搬遷之后無(wú)法做被叫?！咎幚磉^(guò)程】通過(guò)跟蹤該客戶信令發(fā)現(xiàn)，每次收到GPM消息后，手機(jī)返回的Page Response帶上來(lái)的業(yè)務(wù)選項(xiàng)都是無(wú)效值0 x44，因此會(huì)被BSC拒掉。通過(guò)和之前的原網(wǎng)呼叫跟蹤記錄對(duì)比，發(fā)現(xiàn)原網(wǎng)在GPM中始終會(huì)攜帶業(yè)務(wù)選項(xiàng)，而華為對(duì)于缺省的語(yǔ)音業(yè)務(wù)是不攜帶業(yè)務(wù)選項(xiàng)的。這樣做是符合協(xié)議的，但由于現(xiàn)網(wǎng)的部分手機(jī)不符合協(xié)議，因此會(huì)返回?zé)o效的業(yè)務(wù)選項(xiàng)，導(dǎo)致被叫響應(yīng)被拒絕。通過(guò)修改軟參，要所有GPM都攜帶業(yè)務(wù)選項(xiàng)，該問(wèn)題解決?！窘Y(jié)論】 對(duì)

37、于無(wú)法做主叫、被叫這樣的問(wèn)題，最有用的手段就是跟蹤信令，通過(guò)信令分析問(wèn)題出現(xiàn)的環(huán)節(jié)。對(duì)于非空口的原因，就需要分析信令中的字段內(nèi)容是否正常，如果是搬遷項(xiàng)目，最直接的辦法就是對(duì)比原網(wǎng)的信令內(nèi)容，這樣能夠很快的發(fā)現(xiàn)類似的兼容性問(wèn)題。硬指配開(kāi)啟后各載波呼叫嘗試次數(shù)嚴(yán)重不均（徐斌斌）【案例索引關(guān)鍵詞】 硬指配、呼叫嘗試次數(shù)【案例描述】I國(guó)搬遷項(xiàng)目中，許多多載波邊界站點(diǎn)開(kāi)啟了硬指配功能，而且空閑時(shí)手機(jī)只在基本載波上駐留，接入后才可能會(huì)被指配到疊加載波上。割接后話統(tǒng)顯示硬指配站點(diǎn)的基本載波呼叫嘗試次數(shù)遠(yuǎn)小于疊加載波載波，客戶對(duì)此提出疑議，認(rèn)為我們的硬指配算法有問(wèn)題，無(wú)法達(dá)到負(fù)荷均衡的目的?！咎幚磉^(guò)程】選取一

38、個(gè)三載波站，該站的1、2載波為基本載波，第3載波為疊加載波。分析該站話統(tǒng)，發(fā)現(xiàn)的確1、2載波的呼叫嘗試次數(shù)只有1、200次，但第3載波的呼叫嘗試次數(shù)有1000多次。第3載波的呼叫嘗試次數(shù)是1、2載波的10倍分析該站實(shí)際的話務(wù)情況，發(fā)現(xiàn)3個(gè)載波Walsh話務(wù)量基本相當(dāng)。從總的TCH請(qǐng)求次數(shù)來(lái)看，1、2載波的次數(shù)略多于第3載波。實(shí)際上該站旁邊是2載波站，因此1、2載波的軟切換話務(wù)量較高，這點(diǎn)從TCH軟切換請(qǐng)求次數(shù)就可以看到，1、2載波的軟切換請(qǐng)求次數(shù)遠(yuǎn)高于第3載波。由于該站開(kāi)啟了硬指配功能，又由于1、2載波有很多軟切換過(guò)來(lái)的呼叫因此負(fù)荷較高，因此從該站接入的新呼叫大部分都被指配到了第3載波上。而我

39、們的話統(tǒng)統(tǒng)計(jì)呼叫嘗試時(shí)，是按指配頻點(diǎn)統(tǒng)計(jì)的，而不是用戶實(shí)際發(fā)起接入嘗試的頻點(diǎn)，因此從話統(tǒng)中的疊加載波的呼叫嘗試次數(shù)會(huì)高于基本載波。向客戶提交了說(shuō)明后，得到了客戶的認(rèn)可?！窘Y(jié)論】1. 華為的“呼叫嘗試次數(shù)”指標(biāo)，在硬指配打開(kāi)后，會(huì)統(tǒng)計(jì)到被指配的目標(biāo)載頻上，而不是用戶實(shí)際接入的的頻點(diǎn)。這一點(diǎn)在話統(tǒng)分析時(shí)要注意。2. 打開(kāi)硬指配算法后，由于呼叫會(huì)被指配到負(fù)荷低的載頻上以達(dá)到負(fù)荷均衡的目的，此時(shí)接入嘗試次數(shù)并不能正確反映話務(wù)量和負(fù)荷的分布，對(duì)于負(fù)荷均衡，需要分析各載頻的負(fù)荷和話務(wù)量指標(biāo)。通過(guò)CE資源池配置解決載波間CE分配問(wèn)題（徐斌斌）【案例索引關(guān)鍵詞】呼叫建立失敗 CE不足【案例描述】I國(guó)搬遷項(xiàng)目中

40、，某BSC下24號(hào)站晚忙時(shí)出現(xiàn)大量CE資源不足的呼建失敗?！咎幚磉^(guò)程】分析發(fā)現(xiàn)該站打開(kāi)了硬指配，由于用戶分布較近，載頻負(fù)荷不高，因此大部分用戶都在基本載波呼叫，導(dǎo)致忙時(shí)發(fā)生CE擁塞。通過(guò)降低硬指配門限，情況略有改善，但無(wú)法根除。BS工程師發(fā)現(xiàn)目前的配置是每塊信道板單獨(dú)配置為1個(gè)資源池，載波間CE無(wú)法共享。因此通過(guò)配置每2塊信道板為1個(gè)資源池，使各載波資源共享。問(wèn)題基本解決。由于1、2載波為基本載波，話務(wù)量較高，3、4載波為疊加載波，話務(wù)量較低。為了有效實(shí)現(xiàn)CE資源池的作用，將1、3載波的兩塊信道板配置成一個(gè)CE資源池，2、4載波的兩塊信道板配置成一個(gè)CE資源池。【結(jié)論】1. 目前華為的硬指配算

41、法只能保證負(fù)荷均衡，對(duì)于這種話務(wù)高但負(fù)荷很低的場(chǎng)景，硬指配算法無(wú)法保證載波間資源占用率的均衡。通常情況下只能關(guān)閉硬指配算法。2. 但對(duì)于非要使用硬指配的場(chǎng)景，可以通過(guò)配置載波間共享CE的資源池配置方法來(lái)解決該問(wèn)題。一個(gè)BTS的指標(biāo)突然變差的解決偶然方法（田延峰）【現(xiàn)象描述】 一個(gè)BTS的指標(biāo)突然變差，話務(wù)量4Erl，全天主被叫指標(biāo)全部變差。具體現(xiàn)象為：由于CS TCH Signaling Exchange Failures原因造成的呼建成功率全天2090%不定；掉話率（Too many Erasure frames）在5%以上；軟切換和更軟切換失敗由于Radio interface abnor

42、mal的原因成功率只有5090%；前向FER在7% 左右，反向FER正常；【問(wèn)題分析】1、 周圍相鄰站沒(méi)有異常；2、 排除了基站告警及各種硬件原因, 重起基站，沒(méi)有效果。3、 排除所有無(wú)線參數(shù)原因，并且把增強(qiáng)指標(biāo)的各種參數(shù)修改到最大，效果不大?！咎幚泶胧吭趪L試了各種方法都無(wú)法解決的情況下，把業(yè)務(wù)鏈路刪除，重新添加后，問(wèn)題解決。UPE A1 接口失敗問(wèn)題(鄧楊)【現(xiàn)象描述】 Kanpur BSC1 和 Kanpur BSC2 呼建成功率突然下降，存在大量A口失敗，這兩個(gè)BSC掛在Kanpur MSC1下面?！締?wèn)題分析】檢查兩個(gè)BSC的A口配置，均正常。查看修改記錄，未對(duì)全網(wǎng)作參數(shù)修改。將問(wèn)題提

43、交研發(fā)，最后定位出是MSC的一個(gè)網(wǎng)口突然激活，該網(wǎng)口激活后由于在BSC這邊找不到相應(yīng)的單板，故導(dǎo)致大量A口失敗。【處理措施】N側(cè)將該網(wǎng)口關(guān)閉后，A口失敗現(xiàn)象消失，呼建成功率恢復(fù)正常?！締?wèn)題總結(jié)】對(duì)于整個(gè)MSC出現(xiàn)A口失敗的現(xiàn)象，及時(shí)與N側(cè)聯(lián)系，讓N側(cè)檢查MSC的配置，因?yàn)檎麄€(gè)MSC都出現(xiàn)問(wèn)題的情況，一般都是N側(cè)那邊出了問(wèn)題。孖機(jī)造成話統(tǒng)統(tǒng)計(jì)“A1 Interface Failures”的問(wèn)題（李瑞昕）【問(wèn)題現(xiàn)象】分析某局話統(tǒng)時(shí)，發(fā)現(xiàn)呼叫建立失敗中有大量“A1 Interface Failures”，且數(shù)量波動(dòng)很大，有時(shí)候幾萬(wàn)次，有時(shí)候幾千次，影響呼叫建立成功率0.3個(gè)百分點(diǎn)左右，每天幾千上萬(wàn)次

44、的A1接口失敗是不正常的，在正常的網(wǎng)絡(luò)中該值應(yīng)該很少，甚至是0。Time(day)CS AttemptsTimesCS Call Setup Success Ratio%CS A1 Interface FailuresTimesCS Call Resource Allocation FailuresTimesCS Reverse TCH Preamble Acquisition FailuresTimesCS TCH Signaling Exchange FailuresTimes2007-12-11678971098.5875111162093848619152292007-12-12712

45、836098.3211233333124350814142912007178923596412525321314351200726671781539705528201516720075012177902306149201141322007-12-16657608098.6646161841367045675122872007595516279168994759213763200787071419271658234760212836200

46、7-12-19617800498.919376677859984210311882【分析思路】利用CBSSSTAR分析BSC日志，發(fā)現(xiàn)失敗都是0 x2704，也就是等待MSC指配請(qǐng)求超時(shí)：查看0 x2704失敗的框分布，扇區(qū)分布，時(shí)間分布和IMSI分布都沒(méi)有集中在個(gè)別對(duì)象上，其中失敗最多的前幾個(gè)IMSI，每天都有50次以上的失敗，明顯存在異常。于是在BSC維護(hù)臺(tái)上跟蹤失敗最多的前10個(gè)IMSI的用戶接口信令進(jìn)行分析。分析失敗最多的IMSI：404001062467315的信令發(fā)現(xiàn)，該用戶的登記有時(shí)候成功，有時(shí)候被拒絕，拒絕原因是“illegal-MS”；另外，當(dāng)作為被叫時(shí)，BSC會(huì)收到2條尋呼

47、響應(yīng)，并都發(fā)給了MSC，有時(shí)候收到MSC的指配請(qǐng)求：有時(shí)候收到“N_DISCONNECT_IND”：詳細(xì)分析登記和尋呼響應(yīng)的里的消息字段發(fā)現(xiàn)，同一個(gè)IMSI有兩個(gè)ESN，可見(jiàn)這是一個(gè)孖機(jī)，一個(gè)ESN是合法的，一個(gè)是非法的，因此登記的時(shí)候，只有合法的那個(gè)手機(jī)能夠成功：當(dāng)作被叫時(shí)，兩個(gè)手機(jī)收到尋呼消息后都會(huì)發(fā)尋呼響應(yīng)，因此BSC會(huì)收到2條尋呼響應(yīng)。至于為什么有時(shí)候被叫成功，有時(shí)候被叫被拒，經(jīng)過(guò)對(duì)比發(fā)現(xiàn)，如果是非法手機(jī)的尋呼響應(yīng)先收到，則MSC就會(huì)拒絕，而如果是先收到的是合法手機(jī)的，MSC就會(huì)發(fā)指配請(qǐng)求，呼叫建立成功。但是不管是成功還是失敗，BSC都上報(bào)了2條尋呼響應(yīng)，但是只收到一次MSC的響應(yīng)，因

48、此都會(huì)統(tǒng)計(jì)一次“等待指配請(qǐng)求超時(shí)”。利用CBSSTAR的“CSL數(shù)據(jù)分析”功能分析0 x2704失敗較多的一些IMSI，基本上都是一個(gè)IMSI對(duì)應(yīng)2個(gè)ESN，其中一個(gè)IMSI（404001056000000）更是有多達(dá)18個(gè)ESN：由此可見(jiàn)，這個(gè)網(wǎng)絡(luò)中的孖機(jī)非常多，這些孖機(jī)可以造成相當(dāng)數(shù)量的“0 x2704”失敗。（注：之所以每天有上萬(wàn)次失敗，后來(lái)分析發(fā)現(xiàn)還有承載網(wǎng)有擁塞和傳輸?shù)膯?wèn)題，因此每天的失敗次數(shù)波動(dòng)很大，另外還有非華為HLR有時(shí)候不給MSC回響應(yīng)等，這里不再分析。）【處理措施】使用BSC的過(guò)濾非法手機(jī)功能（命令：ADD BLACKLISTESN），把已知的非法ESN輸入黑名單后，再跟蹤

49、信令分析，BSC只會(huì)收到1次尋呼響應(yīng)，都來(lái)自合法的ESN，但是只能是發(fā)現(xiàn)一個(gè)手動(dòng)屏蔽一個(gè)。最大小區(qū)半徑配置錯(cuò)誤導(dǎo)致一個(gè)載扇的資源無(wú)法建立（邸玉波）【現(xiàn)象描述】I國(guó)項(xiàng)目中，監(jiān)控話統(tǒng)指標(biāo)發(fā)現(xiàn)一個(gè)兩載波站其中有一個(gè)載扇沒(méi)有話務(wù)?！締?wèn)題分析及處理措施】檢查配置（DSP RES），發(fā)現(xiàn)其中一個(gè)載扇是被閉掉的，立即解開(kāi)，但是發(fā)現(xiàn)還是不能建立起來(lái)，之后便開(kāi)始檢查發(fā)射功率，VSWR，RSSI以及告警等均未發(fā)現(xiàn)異常，之后便檢查CP板，發(fā)現(xiàn)CCPM的版本是QCK3CCPM,并檢查了基站的配置，發(fā)現(xiàn)最大小區(qū)半徑是40KM，將其改為20KM，問(wèn)題解決?！締?wèn)題總結(jié)】QCK3CCPM 該類型的芯片（6700芯片），如果最

50、大小區(qū)半徑配置為40KM，最多只能支持5個(gè)載扇同時(shí)工作。所以需要將小區(qū)半徑修改為20Km。TATA用戶接入Reliance的網(wǎng)絡(luò)造成的A1接口失?。ㄛ∮癫ǎ粳F(xiàn)象描述】I國(guó)項(xiàng)目中，分析話統(tǒng)時(shí)發(fā)現(xiàn)在某一時(shí)段總有上百次的A口失敗?！締?wèn)題分析及處理措施】分析Runlog發(fā)現(xiàn)，存在大量的等待指配請(qǐng)求超時(shí)的失敗，發(fā)現(xiàn)主要集中在某一個(gè)IMSI上，并在維護(hù)臺(tái)跟蹤，跟了好長(zhǎng)時(shí)間沒(méi)有發(fā)現(xiàn)消息上來(lái)，并想主動(dòng)給該用戶打電話跟蹤，于是查到該號(hào)碼為9229462014，并撥打該號(hào)碼回訪，但是發(fā)現(xiàn)還是沒(méi)有消息上來(lái)，詢問(wèn)客戶得知該用戶是TATA的用戶，但并不清楚為什么會(huì)接到Reliance的網(wǎng)絡(luò)下面來(lái)，因?yàn)閮杉疫\(yùn)營(yíng)商使用不

51、同的頻點(diǎn)。于是將該用戶加入到我們黑名單，命令：ADD BLACKLISTESN: ESN=xxxxxxxxxx;。使該用戶不能接入到我們的網(wǎng)絡(luò)，問(wèn)題解決。局間鏈路不足導(dǎo)致A1接口失?。ㄠ嶊希粳F(xiàn)象描述】O地區(qū)共有4個(gè)BSC分掛在兩個(gè)MSC上，其中MSC3最先開(kāi)起來(lái)，MSC4在之后兩個(gè)月左右才開(kāi)起來(lái)，待MSC3下面的兩個(gè)BSC開(kāi)了約30個(gè)BTS后每天統(tǒng)計(jì)KPI發(fā)現(xiàn)MSC4下面的兩個(gè)BSC的呼叫建立成功率較低，其中A1接口失敗次數(shù)較多而MSC3下面的兩個(gè)BSCA1接口失敗次數(shù)基本沒(méi)有，如下圖所示： 圖：A1接口失敗BSC對(duì)比圖【問(wèn)題分析】由于兩個(gè)MSC對(duì)比現(xiàn)象比較明顯，首先檢查BSC A口配置有無(wú)

52、問(wèn)題。聯(lián)系N側(cè)工程師檢查兩個(gè)MSC的參數(shù)配置是否相同確認(rèn)沒(méi)有問(wèn)題。核查MSC4失敗全天失敗次數(shù)分布發(fā)現(xiàn)基本出現(xiàn)在忙時(shí)，檢查MSC鏈路狀態(tài)發(fā)現(xiàn)忙時(shí)HW-MSC到LU-MSC的局間鏈路占用量為100%，察看兩個(gè)MSC的鏈路配置發(fā)現(xiàn)MSC3的局間鏈路配了21條均可用，而MSC4的局間鏈路配置了17條但是其中9條處于不可用狀態(tài)，懷疑由于局間鏈路較少導(dǎo)致忙時(shí)用戶打出局電話鏈路擁塞無(wú)鏈路資源造成A接口失敗?！咎幚泶胧客苿?dòng)局方增加10條MSC4到朗訊局間鏈路并整改9條不可用鏈路為可用后問(wèn)題解決。【案例小結(jié)】該案例中查詢局間鏈路命令為“DSP OFCTKC”，然后輸入GMSC和鏈路類型如下圖： 圖：查詢局間

53、鏈路方法輸入后會(huì)顯示鏈路狀態(tài)如下圖：圖：鏈路狀態(tài)示圖A接口失敗原因可能性較多，應(yīng)首先抓住問(wèn)題出現(xiàn)的特點(diǎn)進(jìn)行查詢分析，分析基本可從以下方面著手：BSC和MSC的A接口參數(shù)配置BSC和MSC硬件及鏈路配置查詢BSC和MSC告警臺(tái)狀態(tài)CMUX板資源吊死導(dǎo)致呼叫建立成功率低問(wèn)題（邸玉波）【現(xiàn)象描述】I國(guó)項(xiàng)目中，發(fā)現(xiàn)某個(gè)BSC下一個(gè)框的呼叫建立成功率在忙時(shí)非常低 Carrier GroupHours)CS Orig Call Setup Success Ratio%CS Term Call Setup Success Ratio%Module (Raipur_BSC2-1)17:00:0096.2823

54、97.4383Module (Raipur_BSC2-1)18:00:0070.948372.2797Module (Raipur_BSC2-1)19:00:0054.536954.3515Module (Raipur_BSC2-1)20:00:0057.069857.2689Module (Raipur_BSC2-1)21:00:0084.696786.5369Module (Raipur_BSC2-1)22:00:0040.261441.0736Module (Raipur_BSC2-1)23:00:0090.786192.9355【問(wèn)題分析及處理措施】從話統(tǒng)數(shù)據(jù)分析來(lái)看，失敗原因主要是C

55、S Call Resource Allocation Failures，檢查配置數(shù)據(jù)和設(shè)備沒(méi)有任何異常，通過(guò)分析Runlog數(shù)據(jù)發(fā)現(xiàn)存在好多的1464失敗原因值：Applying for FMR AAL2 failed during a callOx1464說(shuō)明MUX管理的FMR到APF之間的channel分配失敗，F(xiàn)MR到APF的channel可以通過(guò)DSP CID查詢，CID代表話路數(shù)，這個(gè)話路數(shù)與DSP USERNUM的用戶數(shù)基本一致。當(dāng)問(wèn)題發(fā)生時(shí)，查詢3框的CID，發(fā)現(xiàn)426個(gè)CID幾乎被用光，但是DSP USERNUM查詢的結(jié)果就只有話路數(shù)的一半。經(jīng)過(guò)BSC開(kāi)發(fā)定位，MUX話路數(shù)的管

56、理出現(xiàn)了吊死。如果CID被用光，那么新的呼叫建立時(shí)就無(wú)法獲取FMR到APF的channel。出問(wèn)題的版本是V2R3C03B011，BSC開(kāi)發(fā)部已經(jīng)在V2R3C03B018SP04版本中解決了這個(gè)問(wèn)題，并且這個(gè)版本已經(jīng)在Reliance升級(jí)。在29日完成升級(jí)后，將不存在此問(wèn)題。 【總結(jié)】當(dāng)遇到BSC級(jí)的呼建很低的時(shí)候，首先觀察是個(gè)別站導(dǎo)致還是很多站導(dǎo)致整個(gè)BSC的指標(biāo)差，如果是很多站導(dǎo)致，看這些站是否有什么共性，同一個(gè)框等，以便快速定位解決問(wèn)題。326基站接入成功率低問(wèn)題（姜偉）【現(xiàn)象描述】326基站和扇區(qū)的369頻點(diǎn)呼建成功率低。失敗原因主要是捕獲不到反向業(yè)務(wù)信道前導(dǎo)幀?！締?wèn)題分析】由于這兩個(gè)

57、扇區(qū)的410頻點(diǎn)呼建是正常的，所以重點(diǎn)在于找到369頻點(diǎn)和410頻點(diǎn)的差異。重點(diǎn)檢查如下方面：無(wú)下掛直放站，周圍也沒(méi)有直放站。體現(xiàn)不出兩個(gè)頻點(diǎn)的差異。周邊基站也全部都是兩載波基站，體現(xiàn)不出兩個(gè)頻點(diǎn)的差異。另外，周邊基站的呼建都是正常的，沒(méi)有哪個(gè)站369頻點(diǎn)呼建明顯差。兩個(gè)頻點(diǎn)參數(shù)設(shè)置完全一致。檢查鄰區(qū)，發(fā)現(xiàn)扇區(qū)的369頻點(diǎn)比410頻點(diǎn)多配置了一個(gè)鄰區(qū)，而這個(gè)鄰區(qū)的PN恰恰與本基站本扇區(qū)的PN相同（正常情況下如果要加一個(gè)與本扇區(qū)PN相同的扇區(qū)為鄰區(qū)，系統(tǒng)是不允許加入的，此處不知為何加入成功了），扇區(qū)也是同樣的情況。【問(wèn)題處理】將和扇區(qū)的369頻點(diǎn)中配置的與自身PN相同的鄰區(qū)刪除，呼叫建立成功率恢

58、復(fù)正常，達(dá)到98以上。【問(wèn)題總結(jié)】善用比較法，處理問(wèn)題會(huì)更加快捷。掉話問(wèn)題總結(jié)跨信令點(diǎn)手機(jī)輔助硬切換掉話分析(王一兵)【現(xiàn)象描述】BTS419掉話率突然升高。通過(guò)Nastar話統(tǒng)分析，發(fā)現(xiàn)第四載波掉話率高，除了Too many Erasure frames掉話原因外，還有許多A2 interface abnormal掉話。BtsId-CellId-SectorId-CarrierId-PN-AFRCNTime(hour)CS Call Drop Ratio%CS Call Drops (Too many Erasure frames)TimesCS Call Drops (A2 interfa

59、ce abnormal)Times419-419-0-1-57-4102007-10-08 19:00:000.36809830419-419-0-2-57-4512007-10-08 19:00:000.28985530419-419-0-3-57-3692007-10-08 19:00:000.09208110419-419-0-4-57-4922007-10-08 19:00:008.045981555419-419-1-1-225-4102007-10-08 19:00:001.69731120419-419-1-2-225-4512007-10-08 19:00:001.209191

60、00419-419-1-3-225-3692007-10-08 19:00:000.52192141419-419-1-4-225-4922007-10-08 19:00:0013.63343142419-419-2-1-393-4102007-10-08 19:00:000.54054160419-419-2-2-393-4512007-10-08 19:00:000.72202280419-419-2-3-393-3692007-10-08 19:00:001.40449150419-419-2-4-393-4922007-10-08 19:00:006.590264722【問(wèn)題分析】手機(jī)