【正文】 硬件設(shè)備故障，導(dǎo)致覆蓋盲區(qū)。在實(shí)踐工作和維護(hù)中，對(duì)于硬件設(shè)備故障導(dǎo)致的覆蓋不合理，主要有Sleeping cell 和SITE OOS等情況，另外，還有Cell 越區(qū)覆蓋問(wèn)題。下面，對(duì)這些問(wèn)題進(jìn)行逐一分析： SLEEPING CELL(一） 怎樣判斷Sleeping cell Sleeping Cell 就是沒(méi)有呼叫進(jìn)程的Cell。沒(méi)有呼叫進(jìn)程的cell的定義是：此cell內(nèi)沒(méi)有任何事件、告警和呼叫。如果有事件表明一個(gè)DRI為DU，此情況不認(rèn)為為沒(méi)有呼叫進(jìn)程的cell。如果TOTAL_CALLS=0這并不表明此cell內(nèi)沒(méi)有執(zhí)行呼叫。也可能切換發(fā)生而進(jìn)入此cell。(二） 分析sleeping cell 產(chǎn)生的原因1， 收集數(shù)據(jù)當(dāng)此問(wèn)題發(fā)生時(shí)收集以下數(shù)據(jù)： 1。描述問(wèn)題發(fā)生時(shí)任何可能的操作（如數(shù)據(jù)庫(kù)下載、site reset等）。 2。收集在問(wèn)題發(fā)生前一個(gè)小時(shí)到問(wèn)題消失間的event log。 3。下面所列的統(tǒng)計(jì)數(shù)據(jù)。 4。收集下面所要求的數(shù)據(jù)。 5。呼叫失敗的TEMS logs。 數(shù)據(jù)收集過(guò)程： 1。描述發(fā)現(xiàn)沒(méi)有呼叫進(jìn)程的site時(shí)發(fā)生的所有可能事件（ database download, site reset, network audit, resync等其它用戶覺(jué)得可能對(duì)問(wèn)題有幫助的事件） 2 。收集在問(wèn)題發(fā)生前一個(gè)小時(shí)到問(wèn)題消失間的event log。 3。在沒(méi)有呼叫進(jìn)程的site中鍵入：disp_equipment site 4。disp_processor site 5。確定哪個(gè)LCF控制此site，顯示此LCF的配置情況，例如display_equipment bsc lcf 1 0 6。disp_active_alarm site 7。顯示PATH/CELL/RSL 的狀態(tài)，例如：state bsc path 1 0 d 8。state site all 9。顯示此site中BTP和所有DRI/DHP/RSLs的狀態(tài)和配置信息。例如：state site btp 0 0 disp_equipment site btp 0 0 10。disp_cell_status site 11。使用disp_rtf_channel 命令顯示此cell內(nèi)所有RTF的信道，例如：disp_rtf_channel site 1 0 12。將此site內(nèi)所有GPROC的SWFM都dump下來(lái)。 13。將控制此site的LCF內(nèi)SWFM都dump下來(lái)。 14。收集TEMS的log：MS做主叫，被叫、切換進(jìn)入、切換出cell的所有情況（包含所有Layer 2 和Layer 3消息）。 15。確定此cell內(nèi)哪個(gè)載頻/時(shí)隙沒(méi)有呼叫進(jìn)程執(zhí)行?？墒褂肨EMS手機(jī)。 16。收集以下統(tǒng)計(jì)數(shù)據(jù)： OK_ ACC_PROC_SUC_RACH ACCESS_PER_RACH CHAN_REQ_MS_BLK CHAN_REQ_MS_FAIL INV_EST_CAUSE_ON_RACH SDCCH_CONGESTION ALLOC_SDCCH ALLOC_SDCCH_FAIL SDCCH_MEAN_HOLDING_TIME OK_ACC_PROC_CM_SERV OK_ACC_PROC_PAGE_RSP OK_ACC_PROC_CM_REEST OK_ACC_PROC_LOC_UPD OK_ACC_PROC_IMSI_DET CONN_REQ_MSC CONN_REFUSED MA_REQ_FROM_MSC MA_CMD_TO_MS MA_CMD_TO_MS_BLKD MA_CMD_TO_MS_FAIL PAGE_REQ_FROM_MSC CIPHER_MODE_FAIL IN_INTRA_BSS_HO IN_INTER_HO HO_REQ_MSC_OK BUSY_TCH_MAX TOTAL_CALLS RF_LOSSES_SD RF_LOSSES_TCH 2， 分析數(shù)據(jù)首先，我們先分析如下幾項(xiàng)： 1．BCCH RTF是否分配了。 2．BCCH載頻是否發(fā)射。 3．MS是否可以占上此cell。 4．在此cell內(nèi)是否可執(zhí)行位置更新。 如果顯示沒(méi)有BCCH RTF分配則此問(wèn)題可更換載頻或重新下載code來(lái)解決；如果BCCH載頻發(fā)射，并且cell為unbarred，則可以通過(guò)TEMS來(lái)發(fā)現(xiàn)問(wèn)題所在。 其次，我們分析一下呼叫流程，看一看呼叫失敗的一些描述： 在呼叫建立時(shí)的各個(gè)環(huán)節(jié)都可能引起呼叫fail。要確定失敗的點(diǎn)和問(wèn)題發(fā)生時(shí)的上下行的消息流程。 以下在TEMS上的一個(gè)成功呼叫一般消息流程： BTS Layer 2 Layer 3 Direction (CHANNEL) Mobile Channel Request (RACH) Immediate Assignment (AGCH) SABMCMD CM Service Request (SDCCH) UARSP (SDCCH) ICMD Ciphering mode mand (SDCCH) ICMD Ciphpering mode plete (SDCCH) RRRSP (SDCCH) ICMD Setup (SDCCH) ICMD Identity Request (SDCCH) ICMD Identity Response (SDCCH) RRRSP (SDCCH) ICMD Call Proceeding (SDCCH) RRRSP (SDCCH) ICMD Assignment Command (SDCCH) SABMCMD (TCHFACCH) UARSM (TCHFACCH) ICMD Assignment Complete (TCHFACCH) RRRSP (TCHFACCH) ICMD Progress (TCHFACCH) RRRSP (TCHFACCH) ICMD Connect (TCHFACCH) RRRSP (TCHFACCH) ICMD Connect Acknowledge (TCHFACCH) RRRSP (TCHFACCH) 可以進(jìn)行以下的分析：Channel Request/Immediate Assignment 此時(shí)呼叫失敗有以下一些原因：MS根本沒(méi)有收到 Immediate assignment消息。(Type 2)在Immediate Assignment消息中的隨機(jī)參考數(shù)與Channel Request中的隨機(jī)參考數(shù)不同。在Immediate Assignment消息中的T1, T2 amp。 T3計(jì)數(shù)器與Channel Request(Type 1) 中的不同。此只能通過(guò)查看TEMS log的L3消息。 Assignment（例如Immediate Assignment Reject）。 (注意：如果MS無(wú)法發(fā)送RACH,需要做路測(cè)，分析TEMS log可以查看是否BCCH是否廣播。) 在MS轉(zhuǎn)向SDCCH時(shí)呼叫失敗有以下一些原因： 。此時(shí)MS會(huì)重發(fā)SABM消息(Type 3)。 (Type 6). 。 除了Assignment Command外的其它消息使得呼叫中斷。 3. TCHFACCH 。此時(shí)MS會(huì)重發(fā)SABM消息。 。(三) 有關(guān)的解決方法一般的解決方法如下： *在有問(wèn)題的cell中測(cè)試在每個(gè)載頻和時(shí)隙的呼叫。 *收集從控制有問(wèn)題DRI的GPROC和BTP的SWFM。 *使用disp_rtf_channel顯示此DRI的時(shí)隙配置狀態(tài)。 具體的方法如下： SDCCH所在的時(shí)隙，使得SDCCH時(shí)隙重新配置。例如：lock site pchn 0 0 0 。 ，將DRI reset。此會(huì)使得CCDSP重新下載code。 ，lock/unlock RSL。 ，lock/unlock BCCH DRI。 ，將BTS reset。 ，將控制此site的LCF reset。 ，著也許為硬件問(wèn)題。首先，用能正常工作的DRI來(lái)替換有問(wèn)題的 DRI，更換RCU。如果這樣解決了此問(wèn)題，將此TCU送往返修。 SITE OOS在工程維護(hù)中，SITE OOS的情況對(duì)整個(gè)系統(tǒng)性能的影響很大，會(huì)導(dǎo)致一部分區(qū)域的盲區(qū)。對(duì)于此種情況，一般有兩方面的原因：1. SITE 本身存在硬件上的故障。2. 傳輸問(wèn)題。我們可以通過(guò)用PCMCIA卡起站來(lái)判斷SITE的好壞，如果是SITE本身的問(wèn)題，可以通過(guò)進(jìn)一步的分析來(lái)判斷，并通過(guò)更換硬件來(lái)解決。這里，我們重點(diǎn)分析一下傳輸問(wèn)題。（一），怎樣判斷是否傳輸問(wèn)題如果SITE能夠用PCMCIA卡起來(lái)，可初步判定不是站的問(wèn)題。但為確定是否是傳輸問(wèn)題，我們可以從BTS的MIP中，對(duì)之進(jìn)行進(jìn)一步的確認(rèn)。在BTS啟動(dòng)時(shí)，我們可以進(jìn)入第三層emon狀態(tài)，對(duì)MIP狀態(tài)進(jìn)行必要的分析，如下：MIP: Starting Micro IPMIP: In slot 0MIP: csfp_swap = 39。NO_CSFP_SWAP39。MIP: Reset type is xa0000003.MIP: Performing Hard Reset.MIP: Disable phase detector 1 and 2MIP: SYNC pulse the phase det strobeMIP: 1015 is master MCU……MIP: Sending CA polling messageNG EXEC_DLSP process_hdlc_msg: NIU_START on channel 1. Ignoring, Mailbox already unlocked.NG EXEC_DLSP process_hdlc_msg: NIU_START on channel 5. Ignoring, Mailbox already unlocked.MIP: MDL error 6 on channel 0.MIP: Update links returned error 23.MIP: Sending CA polling messageNG EXEC_DLSP process_hdlc_msg: NIU_START on channel 1. Ignoring, Mailbox already unlocked.NG EXEC_DLSP process_hdlc_msg: NIU_START on channel 5. Ignoring, Mailbox already unlocked.MIP: MDL error 6 on channel 0.MIP: Update links returned error 23.MIP: Sending CA polling message……MIP: Sending CA polling messageMIP: frame 0, slot 0 Disconnect Ind for LAPD link x1001MIP: Reestablishing LAPD for frame 0, s