無線網(wǎng)絡(luò)優(yōu)化經(jīng)驗研究報告系列報告-SDCCH擁塞率高的分析處理

-.zSDCCH擁塞率高的分析處理目錄TOC\o"1-6"\h\z\uSDCCH擁塞率高的分析處理〕直到小區(qū)不再出現(xiàn)AGCH或SDCCH信道過載情況。根據(jù)上述原則，可以確定T值的取值*圍〔對應(yīng)參數(shù)S的每個取值參數(shù)T可以取數(shù)個〕，當(dāng)小區(qū)RACH沖突數(shù)較大時，應(yīng)取較大的T值〔在上述*圍內(nèi)〕；在RACH沖突數(shù)較少〔定量分析需在實驗以后進展〕的情況下，應(yīng)使T值盡可能小。注意：移動T*_integer(T)的默認值為“12〞即20個RACH時隙。2、RACH的流量控制：系統(tǒng)通過RSS來監(jiān)測在一定的時間內(nèi)〔rach_load_period〕收到的channelrequest消息個數(shù)。如果收到的個數(shù)超過門限r(nóng)ach_load_threshold，則RSS向callprocessing發(fā)負載指示消息。一旦收到負載指示消息，callprocessing將隨機BAR住一個接入級別(0-9)的手機。同時CP啟動計時器T1和T2(flow_control_t1和flow_control_t2)。當(dāng)T1超時后，假設(shè)CP再收到從BSS系統(tǒng)傳來的負載指示消息，則CP將再BAR住另一個級別的手機。假設(shè)在T2的時長內(nèi)，CP沒有再收到從BSS傳來的負載指示消息則系統(tǒng)將UNBAR一個級別的手機。T2的取值必須大于T1。FigureRACHflowcontrol第一個被BAR住的級別是由CP隨機選擇的，此后被BAR住的級別遵循循環(huán)的原則，從低級別到高級別。隨后被UNBAR的級別在其它所有級別均被BAR過前，不會再被BAR住。第一個被UNBAR的級別是BAR住時間最長的級別。計時器rach_load_period和ccch_load_period都是235.5mS(1*51frame)的整數(shù)倍。rach_load_period決定了rachload監(jiān)測的時間周期。只有在前一個周期內(nèi)(RACHorCCCH)觸發(fā)了過載條件ccch_load_period才會開場計時。門限r(nóng)ach_load_threshold由下面的公式計算得到：RACHloadthreshold=Totalnumberofchannels(TCH/SDCCH)*100NoofRACHsinperiod*NoofRACHtimeslots其中：分子是小區(qū)內(nèi)配置的SDCCH子時隙和TCH的個數(shù)。分母是在4*51幀的復(fù)幀周期內(nèi)可用的RACH時隙數(shù)。這個值取決于ccch_conf的設(shè)置。結(jié)果為rach_load_threshold，以0.01%為間隔。注意：由于移動的網(wǎng)絡(luò)不支持用戶的分級，所以上述RACH的流量控制實際效用不大。3、啟動立即指配拒絕功能緩解SDCCH擁塞：在GSM規(guī)*中定義了立即指配拒絕的功能：當(dāng)目前網(wǎng)絡(luò)沒有可以分配的SDCCH信道時，就可以通過發(fā)送給手機一條立即指派拒絕〔immediateassignmentreject〕的消息來拒絕手機的信道申請，并且在系統(tǒng)規(guī)定的時間內(nèi)〔Wait_indication_parameters即T3122〕制止手機接入網(wǎng)絡(luò)，通過這種功能可防止在系統(tǒng)沒有SDCCH資源的情況下用戶頻繁的發(fā)送信道請求的消息，而不必要地增大網(wǎng)絡(luò)的負荷。Wait_indication_parameters：BSS小區(qū)級參數(shù)，即定時參數(shù)T3122；參數(shù)“等待指示〞的取值*圍是0～255的整數(shù)，以秒為單位，表示手機必須等待的時間。參數(shù)“等待指示〞包含于下行消息“立即指配拒絕〞之中。當(dāng)網(wǎng)絡(luò)收到手機發(fā)送的信道請求消息后，假設(shè)沒有空閑的SDCCH信道分配給手機，則網(wǎng)絡(luò)通過AGCH信道發(fā)送“立即指配拒絕消息〞給手機。為了防止手機不斷進展信道請求而造成無線信道的進一步阻塞，在立即指配拒絕消息中包含定時參數(shù)T3122，即所謂的等待指示信息單元。手機在收到立即指配拒絕消息后必須經(jīng)過T3122指示的時間后才能發(fā)起新的呼叫。參數(shù)“等待指示〞〔T3122〕實際上是當(dāng)網(wǎng)絡(luò)中的無線資源缺乏時，強制手機在一次試呼失敗后、發(fā)起新一次試呼前必須等待的時間。因此它的取值對網(wǎng)絡(luò)性能的影響較大。T3122設(shè)置過短，則在無線信道負荷較大時容易引起信道的進一步阻塞；但假設(shè)T3122設(shè)置過大則使網(wǎng)絡(luò)的平均接入時間增加而導(dǎo)致網(wǎng)絡(luò)平均的效勞性能下降。注意：T3122設(shè)置的原則是：在網(wǎng)絡(luò)的公共控制信道〔CCCH〕不發(fā)生過載的情況下，應(yīng)使T3122盡可能小。一般建議T3122的一般設(shè)置為10～15秒，在業(yè)務(wù)量密集地區(qū)設(shè)置為15～25秒。但是，由于在T3122生效的時間內(nèi)用戶的手機外表看沒有任何反響，此參數(shù)的設(shè)置一般不要取值過大，防止引起用戶的強烈反映。案例分析：為了減小SD的擁塞，4月21日，我們對全網(wǎng)的T_3122參數(shù)進展了嘗試性調(diào)整，將局部SDCCH擁塞率較高的基站的T_3122由8秒調(diào)整到了15秒。從4月17日與4月24日的統(tǒng)計比照來看全網(wǎng)的SDCCH的擁塞率有所減少。全網(wǎng)SDCCH成功分配次數(shù)SDCCH分配失敗次數(shù)SDCCH話務(wù)量SDCCH擁塞率4月17日2078197797342186.863.69％4月24日2135049300972228.111.39％增大SDCCH配置緩解由于增值業(yè)務(wù)量的增加導(dǎo)致的擁塞現(xiàn)在的GSM網(wǎng)絡(luò)所提供的業(yè)務(wù)中，有一局部增值業(yè)務(wù)是由SDCCH信道承載，例如短信消息等。如果增值業(yè)務(wù)在時間上集中引入，很可能導(dǎo)致網(wǎng)絡(luò)SDCCH信道出現(xiàn)突發(fā)且較大面積的擁塞情況。2001年5月17日，移動開通了神州行手機用戶的短信息業(yè)務(wù)，由于當(dāng)時移動已經(jīng)擁有了相當(dāng)規(guī)模的神州行用戶，且公司前期市場宣傳工作做的比擬到位，當(dāng)天大量神州行用戶嘗試使用短信息，引起網(wǎng)絡(luò)內(nèi)短信息的收發(fā)次數(shù)激增，無線側(cè)引發(fā)了大量的小區(qū)SDCCH擁塞。cm_req_smssms_inisial_on_sdSD_BLKSDCCH話務(wù)量sum5月16日23032472730.814168.545月17日923031480491.664402.21出現(xiàn)這種情況后，只能及時增加具體每個出現(xiàn)SDCCH信道擁塞的小區(qū)的SDCCH配置，以緩解網(wǎng)絡(luò)擁塞情況。但為了盡可能防止類似的事件再次發(fā)生，應(yīng)加強網(wǎng)絡(luò)運行維護部門與市場部門的溝通，有預(yù)見性地采取一些預(yù)防措施。承受此次教訓(xùn)后，我們在此后的節(jié)假日等易于引起短信息等增值業(yè)務(wù)突發(fā)的時候，及時且適量地調(diào)整了網(wǎng)絡(luò)的配置，防止了上述在無線側(cè)擁塞情況的再次發(fā)生。存在覆蓋或話務(wù)的不均衡問題當(dāng)出現(xiàn)SDCCH信道擁塞后，分析得出SDCCH的擁塞率與TCH的擁塞率不均衡，或者基站的覆蓋與周邊基站的覆蓋沒有合理地進展控制，則可以采用以下的均衡方法進展處理：假設(shè)TCH信道很閑，可以開啟SDCCH的重配功能，調(diào)整本小區(qū)的SDCCH與TCH的信道比例；假設(shè)開啟了SDCCH的重配功能，但參數(shù)設(shè)置不合理或不正確也可能造成SDCCH的擁塞；由于基站的覆蓋過大，引起SDCCH擁塞，可以對用戶的起呼進展距離上的限制；假設(shè)基站的C2設(shè)置不合理，可能造成基站過多地吸收了話務(wù)，從而導(dǎo)致基站SDCCH擁塞率比TCH的高?；維DCCH與TCH信道配置不合理假設(shè)TCH信道很閑，可以開啟SDCCH的重配功能，調(diào)整本小區(qū)的SDCCH與TCH的信道比例由于在基站的資源分配中，SDCCH與TCH均要占用基站的物理信道資源，在基站構(gòu)造配置中實際上存在SDCCH與TCH的平衡問題，通常SDCCH與TCH在開站時被固定分給一定的信道，但由于網(wǎng)絡(luò)承載的話務(wù)是不斷變化開展的，為了適應(yīng)這種變化，保持SDCCH與TCH在資源的使用上的合理分配，啟用基站的SDCCH信道重配功能，可以有效地、動態(tài)地根據(jù)實時的用戶需求，調(diào)整SDCCH與TCH之間的資源分配，盡可能地防止出現(xiàn)二者忙閑不均的情況。信道重配：在呼叫處理的過程中BSS的軟件CRM進程可以進展動態(tài)信道重配，例如：SDCCH信道的使用比例很大，同時還繼續(xù)有SDCCH信道的申請，此時當(dāng)滿足一定門限后，CRM可以將TCH信道重新配置成SDCCH信道，以滿足SDCCH的需求。涉及到的BSS參數(shù)：ccch_conf：BSS小區(qū)級參數(shù)；參數(shù)ccch_conf由3比特組成，常用的取值有：0表示non－bined方式，CCCH使用一個根本的物理信道，不與SDCCH共用；1表示bined方式，CCCH使用一個根本的物理信道，與SDCCH共用。根據(jù)一般的經(jīng)歷，對于小區(qū)中的載頻數(shù)為1個或2個的情況，建議公共控制信道的配置采用一個根本物理信道且與SDCCH共用；小區(qū)中的載頻數(shù)超過2個的情況，建議公共控制信道的配置采用一個根本物理信道且不與SDCCH共用。Channel_Reconfiguration_Swith：BSS小區(qū)級參數(shù)；參數(shù)的取值可以決定CRM可否進展動態(tài)信道重配。Number_Sdcchs_Preferred：BSS小區(qū)級參數(shù)；定義了在系統(tǒng)重啟時CRM配置SDCCH的個數(shù)，同時小區(qū)SDCCH的信道個數(shù)。這個參數(shù)的取值受限于該小區(qū)的信道配置方式是bined或non－bined。Ma*_number_of_sdcch：BSS小區(qū)級參數(shù)；定義了信道重配后SDCCH的最大個數(shù)。發(fā)生TCH至SDCCH信道重配的條件：信道重配后SDCCH的最大個數(shù)不能超過Ma*_number_of_sdcch；空閑的SDCCH信道個數(shù)要少于sdcch_need_high_water_mark；當(dāng)前空閑的TCH信道個數(shù)要大于tch_full_need_low_water_mark；發(fā)生SDCCH至TCH信道重配的條件：重配后的SDCCH信道個數(shù)不能少于Number_Sdcchs_Preferred；當(dāng)前空閑的SDCCH信道個數(shù)要大于sdcch_need_low_water_mark；SDCCH信道的配置一般遵循以下原則：在小區(qū)載頻數(shù)<2的情況下，此時CCCH配置方式一般為bine方式，因為SDCCH要與CCCH共享BCCH載頻的TS0，這種情況下的SDCCH的實際個數(shù)為n×8＋4，其中n代表除BCCH外又給SDCCH配置的時隙個數(shù)。對于這樣的小配置基站，n取值一般為1，SDCCH最小值則為12；SDCCH最大值可以為20。載頻個數(shù)在2到4之間的小區(qū)，CCCH配置方式一般為nonbine方式，SDCCH的實際個數(shù)為n×8，n取值一般為2，SDCCH最小值則為16；SDCCH最大值可以為24。載頻個數(shù)>4之間的小區(qū)，CCCH配置方式一般為nonbine方式，SDCCH的實際個數(shù)為n×8，n取值一般為3，SDCCH最小值則為24；SDCCH最大值可以為32。注意：sdcch_need_low_water_mark>=Number_Sdcchs_Preferred；sdcch_need_low_water_mark－sdcch_need_high_water_mark>=9；在日常的優(yōu)化中，要觀察每天的SDCCH和TCH擁塞的情況，對于不正常的配置情況要及時糾正，防止出現(xiàn)一邊空閑，一邊擁塞的現(xiàn)象。從全網(wǎng)統(tǒng)計到的數(shù)據(jù)按照SDCCH擁塞作為主關(guān)鍵字，TCH擁塞作為次關(guān)鍵字，進展從高到低排序，在TCH信道無擁塞，而SDCCH信道擁塞嚴重時，可考慮將一個TCH信道重配為8個SDCCH信道。案例分析：1、由于近幾周全網(wǎng)SDCCH擁塞狀況有上升趨勢，我們選定局部典型基站做實驗性修改，翻開CELLRECONFIGURATIONSWITCH。啟用SDCCH動態(tài)分配原則，Preferred_number_of_sdcch按通常的規(guī)劃方法設(shè)定,并設(shè)定相關(guān)參數(shù)：Channel_reconfiguration_switch=1Ma*_number_of_sdcch=24Sdcch_need_high_water_mark=2Sdcch_need_low_water_mark=12Tch_need_low_water_mark=3結(jié)果說明擁塞狀況有明顯改善，前后比照見下表。現(xiàn)在全網(wǎng)除個別基站外，此功能均已翻開。下表是全網(wǎng)改動前后的性能比擬：date_and_timesum_alloc_sdcch_failsum_alloc_sdcchsum_alloc_tchsum_alloc_tch_failTCH擁塞率SDCCH擁塞率8-204534377508374561412677914.535.528-234148480985271461510825513.154.878-206425082793675787815872817.317.208-232755981210375380113326615.023.282、西三旗和五棵松村在一定程度上存在TCH與SDCCH忙閑不均的情況，采取以下措施后這些小區(qū)的TCH擁塞與SDCCH擁塞得到了均衡。CID786：將Ma*_number_of_sdcchs從32增加到48，number_sdcchs_preferred從24增加到32；CID840：將Ma*_number_of_sdcchs從32增加到48，number_sdcchs_preferred從16增加到24。site_namecell_nameSDCCH擁塞CALL_SETUP_SUCCESS_RATETCH擁塞TOTAL_CALLSavail_tch_ma*erl/chantimeWuKeSongCun_16460-00-4112-8407.3296.6701047370.473-1WuKeSongCun_16460-00-4112-8401.7696.080.031104360.583-2*iSanQi_6460-00-4110-7867.4496.860990360.583-1*iSanQi_6460-00-4110-7862.6697.100.051107340.583-23、萬柳橋西北DCSCID30289的SDCCH擁塞較高，但TCH不存在擁塞情況，話務(wù)掉話比擬低。處理過程：將number_sdcchs_preferred：16——32；ma*_number_of_sdcchs：32——48；site_namecell_name掉話次數(shù)sd擁塞TCH話務(wù)量date_and_timeWanLiuQiao*iBeiDCS460-00-4144-3028917.281.516-25WanLiuQiao*iBeiDCS460-00-4144-3028910.001.356-284、在11月18日對網(wǎng)上所有CELL的channel_reconfig及其有關(guān)參數(shù)進展了相應(yīng)的調(diào)整，減小了TCH和SD擁塞，同時提高呼叫成功率，也可以使當(dāng)前的無線資源能有更高的利用率，防止了由于TCH,SD分配不合理，造成的一方擁塞而另一方空閑的資源浪費。改動的具體參數(shù)如下：number_sdcch_preferred:8,16,24ma*_number_of_sdcchs:16,24sdcch_low_water_mark:10,18,26sdcch_high_water_mark:2tch_full_need_low_water_mark:3改動前后小區(qū)性能變化如下：SDCCH11-1611-25cell_nameSDCCH擁塞SDCCH話務(wù)量SDCCH擁塞SDCCH話務(wù)量460-00-4160-75950.969.070.1610.74460-00-4130-8150.357.059.5411.38460-00-4130-7948.967.0412.8112.02460-00-4160-54831.435.910.475.01460-00-4120-12228.4813.664.3216.07460-00-4170-62624.106.821.226.11460-00-4170-62151.6618.0229.9221.93460-00-4170-62223.8713.902.6813.41TCH11-1611-25cell_nameTCH擁塞TCH話務(wù)量avail_tch_ma*TCH擁塞TCH話務(wù)量avail_tch_ma*460-00-4142-78526.4317.43216.6515.6022460-00-4172-69824.9124.97295.7222.0130460-00-4172-96427.3525.17298.8122.9830460-00-4160-91743.4126.712925.7925.7230開啟了SDCCH的重配功能，但參數(shù)設(shè)置不合理或不正確如果優(yōu)化人員在配置SDCCH的重配功能時，沒有滿足BSS的約束條件，則可能發(fā)生SDCCH不能正常重配的情況，很可能會出現(xiàn)SDCCH擁塞的現(xiàn)象。與周邊基站相比本小區(qū)的覆蓋不合理相對自身信道配置以及與鄰區(qū)話務(wù)來說，如果基站的實際覆蓋*圍過大，可能導(dǎo)致它實際承載了過多的手機的網(wǎng)絡(luò)效勞需求，這樣很容易產(chǎn)生SDCCH信道擁塞。當(dāng)出現(xiàn)這種情況后，針對基站覆蓋偏大的情況，采取有效措施來收縮基站的覆蓋，從而降低基站承載的用戶數(shù)，減小SDCCH信道的擁塞。常用的方法有：在距離上限制距基站較遠的用戶接入本基站；調(diào)整基站的小區(qū)重選的參數(shù)設(shè)置。人為限制手機接入的距離收縮基站實際覆蓋*圍緩解SDCCH擁塞對于偏遠的地區(qū)，由于基站建立力度不夠，在有些距離基站較遠的地方手機信號較弱，如果手機在這些地方嘗試向網(wǎng)絡(luò)發(fā)起效勞請求或響應(yīng)網(wǎng)絡(luò)的尋呼，由于距離基站過于遠，信號衰減較大，手機接收質(zhì)量很差，這樣手機很可能不能正常地接入到網(wǎng)絡(luò)中，反而由于手機頻繁嘗試發(fā)起接入請求而造成網(wǎng)絡(luò)資源被大量占用。為防止這種距離基站過遠的手機接入到基站中，我們可以翻開網(wǎng)絡(luò)限制，將這些資源請求拒絕掉。涉及到的參數(shù)有：poor_initial_assignment：BSS級參數(shù)；該參數(shù)的置位可以讓BSS在收到手機發(fā)來的RACH消息后，分析其TA值，假設(shè)超出ms_ma*_range的*圍后，則網(wǎng)絡(luò)將該RACH請求放棄掉，而不作任何響應(yīng)，這樣做可以將一些距離較遠、質(zhì)量可能較差的RACH消息限制在網(wǎng)絡(luò)承受*圍之外；ms_ma*_range：BSS小區(qū)級參數(shù)；當(dāng)手機和基站的距離超過一定門限時，網(wǎng)絡(luò)應(yīng)啟動切換過程，以維持一定的通信質(zhì)量，減小小區(qū)間的干擾。參數(shù)“手機最大距離〞規(guī)定了手機距離的最大門限；當(dāng)超越該門限時，基站將啟動切換過程；注意：開啟了BSS的poorinitialassignment功能后，可以限制信號質(zhì)量較差的用戶接入網(wǎng)絡(luò)的請求，從而在一定程度上防止了這些用戶可能的頻繁資源請求。但是，這只是一種暫時的方法，為了根本解決問題，及時地解決網(wǎng)絡(luò)覆蓋缺乏的問題以及合理調(diào)整基站的覆蓋*圍才是最終的解決方法。C2設(shè)置不合理導(dǎo)致基站實際覆蓋過大對于有些基站由于基站的站址比擬偏遠或基站位置過矮，為了吸收話務(wù)量，優(yōu)化人員有時開啟C2。但是，如果C2的設(shè)置過大，且鄰區(qū)的切換門限沒有做及時的調(diào)整，也容易造成SDCCH擁塞。案例分析：6月21日，化工研究院DCS由于話務(wù)量過低，我們將該站的C2翻開，設(shè)置的該cell參數(shù)cell_reselect_offset設(shè)為15，即30dB。C2翻開后該小區(qū)的呼叫次數(shù)增加比擬明顯，但由于當(dāng)時未將該站的出鄰區(qū)的切換門限適當(dāng)增高，造成相當(dāng)數(shù)量的呼叫在此小區(qū)建立后，很快切換至別的小區(qū)。從統(tǒng)計上看基站的totalcall很多，但話務(wù)量卻不高，還存在一定數(shù)量的SDCCH擁塞。當(dāng)我們將該站的C2關(guān)閉后，基站的SDCCH擁塞率下降為0。datesite_namecell_nameSDCCH擁塞率SDCCH話務(wù)量TCH擁塞TCH話務(wù)量TOTAL_CALLSavail_tch_ma*erl/chanCell話務(wù)掉話比6-21HuaGongYanJiuYuanDCS311090.122.700.002.42617.00290.0820.786-22HuaGongYanJiuYuanDCS311090.000.160.000.8612.00290.0351.42手機過多的位置更新占用了基站的SDCCH信道當(dāng)基站發(fā)生SDCCH信道擁塞后，對用戶申請SDCCH信道的原因進展分析后，假設(shè)基站大量SDCCH的分配是被用于手機進展位置區(qū)的更新，則在采取其他措施的同時，盡可能地降低不必要的手機位置更新的次數(shù)，可以大幅度降低SDCCH信道的占用，從而減少SDCCH信道的擁塞情況。要降低LAC更新的次數(shù)，可以從LAC的劃分是否合理、位置區(qū)更新滯后參數(shù)的設(shè)置等方面進展檢查，分析問題所在。LAC劃分不合理導(dǎo)致手機頻繁位置更新在進展網(wǎng)絡(luò)LAC區(qū)規(guī)劃時，如果LAC區(qū)的交界被選擇在手機用戶數(shù)較多，用戶移動性較大的地區(qū)，則會導(dǎo)致頻繁的手機位置更新，這樣會占用大量的SDCCH信道，很可能引起SDCCH的擁塞。同時，由于大量的位置區(qū)更新會造成手機經(jīng)常不在效勞區(qū)的現(xiàn)象。所以，在對網(wǎng)絡(luò)的LAC分區(qū)進展劃分時，要充分考慮具體的道路信息、手機用戶分布信息、基站的位置信息等，將LAC交界避開主干道路和話務(wù)密集的地區(qū)，減少不必要的位置更新，從而降低頻繁位置更新對SDCCH信道資源過度的占用。分析SDCCH擁塞率較高的基站其占用資源的原因，如果大量是由于位置更新造成的，則要分析LAC交界的具體情況，采取調(diào)整基站的覆蓋，以較少基站覆蓋的不必要交疊，適當(dāng)?shù)臅r候要增加CRH來降低發(fā)生位置更新的幾率，或者考慮增加SDCCH信道的個數(shù)。在有些時候，可能出現(xiàn)基站的SDCCH信道已經(jīng)到達最大配置，基站的覆蓋已經(jīng)調(diào)整得比擬合理，CRH的取值也到達最大的情況，這種情況下只能檢查LAC的劃分是否合理，重新調(diào)整LAC的分區(qū)，來避開高話務(wù)地區(qū)。LAC分界處的基站覆蓋交疊過大且此處的手機用戶密度較大在LAC分界的基站如果覆蓋交疊過大或用戶密度較大，可能存在大量的位置更新。在調(diào)整基站覆蓋使之趨于合理的同時，通過調(diào)整網(wǎng)絡(luò)參數(shù)可以在一定程度上緩解頻繁位置更新的發(fā)生。當(dāng)手機進展小區(qū)重選時，假設(shè)原小區(qū)和目標(biāo)小區(qū)屬不同的位置區(qū)，則手機在小區(qū)重選后必須啟動一次位置更新過程。由于無線信道的衰落特性，通常在跨LAC的相鄰小區(qū)交界處，測量得到的兩個小區(qū)的C2值會有較大的波動，從而使手機頻繁地進展小區(qū)重選。盡管按照GSM規(guī)*，手機兩次小區(qū)重選的間隔時間不會小于15秒，但對位置更新發(fā)生在手機用戶數(shù)量較多的地區(qū)時,15秒的保護時間還是不夠的。手機用戶過多的位置更新不但使網(wǎng)絡(luò)的信令流量大大增加、無線資源得不到充分利用，并且由于手機在位置更新的過程中無法響應(yīng)尋呼，因而使系統(tǒng)的接通率降低。為了減小這一問題的影響，GSM規(guī)*設(shè)立了一個參數(shù)，稱為小區(qū)重選滯后cell_reselect_hysteresis。此參數(shù)是BSS小區(qū)級參數(shù)；它要求鄰區(qū)〔位置區(qū)與本小區(qū)不同〕信號電平必須比本區(qū)信號電平大，其差值必須大于小區(qū)重選滯后規(guī)定的值，并且要保持5秒以上，手機才再啟動小區(qū)重選。小區(qū)重選滯后包含于信息單元“小區(qū)選擇參數(shù)〔CellSelectionParameter〕〞中。該信息單元在每個小區(qū)播送的系統(tǒng)消息中周期性發(fā)送。選擇適宜的小區(qū)重選滯后電平對網(wǎng)絡(luò)優(yōu)化有重要的意義。小區(qū)重選滯后通常建議設(shè)置為8dB或10dB。在以下情況下建議作適當(dāng)?shù)恼{(diào)整：當(dāng)*地區(qū)的業(yè)務(wù)量很大，經(jīng)常出現(xiàn)信令流量過載現(xiàn)象，建議將該地區(qū)中屬于不同LAC的相鄰小區(qū)的小區(qū)重選滯后參數(shù)增大。假設(shè)屬于不同位置區(qū)的相鄰小區(qū)其重疊覆蓋*圍較大時，建議增大小區(qū)重選滯后參數(shù)。假設(shè)屬于不同LAC的相鄰小區(qū)在鄰接處的覆蓋較差，即出現(xiàn)覆蓋的“縫隙〞時，或這種鄰接處地理位置處于高速公路等慢速移動物體較少的地區(qū)，建議將小區(qū)重選滯后參數(shù)設(shè)置在2～6dB之間。注意：小區(qū)重選滯后〔CRH〕的設(shè)置一般應(yīng)結(jié)合小區(qū)重選C2的取值，統(tǒng)一考慮。另外，對于網(wǎng)絡(luò)調(diào)整尤其是割接比擬頻繁的情況，應(yīng)及時觀察網(wǎng)絡(luò)以及小區(qū)SDCCH擁塞率的變化，隨著網(wǎng)絡(luò)LAC分區(qū)的改變來調(diào)整位于LAC交界的小區(qū)的SDCCH信道配置，并且調(diào)整這些小區(qū)的CRH參數(shù)的設(shè)置。案例分析：1、8月20日和26日，我們對局部處于LAC邊界，LOCATIONUPDATE次數(shù)較多的個別小區(qū)進展了分析，考慮到用戶停留在這些小區(qū)時，要占用相對較多的SDCCH信道進展位置區(qū)更新。鑒于此，我們對這些小區(qū)的SDCCH信道進展了進一步調(diào)整〔參數(shù)如下〕。例如：廣外關(guān)廂、豐臺東大橋、龐各莊。調(diào)整后這些小區(qū)的SDCCH擁塞率得到下降，前后比照方下：Channel_reconfig_switch=1；Ma*_number_of_sdcch=48〔將最大SDCCH信道數(shù)增至最大〕；Tch_need_low_water_mark=2；BSSNameSiteNamegsmcelliddate_and_timeSDCCH擁塞率SDCCH到達率TCH擁塞率busy_sdcchalloc_sdcchalloc_sdcch_failBSS19PangGeZhuang_3460-00-4170-68325-81.27774.0000.9485711BSS19PangGeZhuang_3460-00-4170-68327-80.00675.0000.887460BSS19PangGeZhuang_3460-00-4170-68330-80.23846.0000.838722BSSNameSiteNamegsmcelliddate_and_timeSDCCH擁塞率SDCCH到達率TCH擁塞率busy_sdcchalloc_sdcchalloc_sdcch_failBSS51GuangWaiGuan*iang_8460-00-4182-67825-82.498425.0009.419209235BSS51GuangWaiGuan*iang_8460-00-4182-67827-81.528183.0009.108818136BSS51GuangWaiGuan*iang_8460-00-4182-67830-81.618445.000.19.389143150BSSNameSiteNamegsmcelliddate_and_timeSDCCH擁塞率SDCCH到達率TCH擁塞率busy_sdcchalloc_sdcchalloc_sdcch_failBSS55FengTaiDongDaQiao_18460-00-4192-22025-82.032708.0002.88294361BSS55FengTaiDongDaQiao_18460-00-4192-22027-80.002292.0002.4425800BSS55FengTaiDongDaQiao_18460-00-4192-22030-80.002407.0002.46268102、考慮到德寶飯店第三方向SDCCH擁塞嚴重，且多數(shù)申請SDCCH的原因是用于位置更新，所以我們將與德寶飯店第三方向不同LAC的鄰區(qū)北站第三方向、西直門飯店三個小區(qū)的參數(shù)cell_reselet_hysteresis由10dB改為14dB，前后性能比照方下：site_namecell_nameSDCCHTCH話務(wù)量TOTAL_CALLdate_and_time成功分配次數(shù)分配失敗次數(shù)擁塞成功分配次數(shù)分配失敗次數(shù)擁塞北站3460-00-4112-2604070065000.004.001998-9460-00-4112-2605880090700.004.222488-11西直門飯店1460-00-4112-4813870076600.004.832158-9460-00-4112-4814160069900.003.562028-11西直門飯店2460-00-4112-482253700194320.1016.317298-9460-00-4112-482260700214500.0015.198658-11西直門飯店3460-00-4112-48355400108400.006.142788-9460-00-4112-48361000123400.006.523438-11德寶飯店3460-00-4132-7773688777467.8215991390689.6922.0015588-9460-00-4132-777218240.1829992487.6416.378718-11基站不能正常分配SDCCH信道當(dāng)基站的軟件或硬件出現(xiàn)故障后，就可能導(dǎo)致在立即指配過程中，基站無法正常分配SDCCH信道，在統(tǒng)計上表達為SDCCH信道的擁塞。通常有以下的這些情況：硬件問題導(dǎo)致基站時隙退出效勞從而降低小區(qū)的可用資源基站出現(xiàn)硬件故障的情況，主要是指基站的載頻出現(xiàn)單個或幾個時隙退出效勞，甚至整個或幾個載頻不能正常提供效勞的情況。當(dāng)出現(xiàn)這種硬件故障后，很可能直接導(dǎo)致基站的SDCCH和TCH話務(wù)擁塞。要根本解決這種原因引起的話務(wù)擁塞，必須首先處理硬件故障。案例分析：9月1日半壁店的SDCCH擁塞聚增到17%，主要由于該基站的DRI出現(xiàn)[46]，[45]號告警，導(dǎo)致大量時隙OOS。INS該站有問題的DRI后恢復(fù)。同時鑒于該站SDCCH，TCH擁塞不平衡，調(diào)整該站的MA*_NUMBER_OF_SDCCH=48后，其SDCCH擁塞下降為0.99%。但是9月6日該站再次出現(xiàn)大量時隙OOS，致使SDCCH擁塞再次上升。NameDateOK_ACC_PROCSDCCH_CONGESTION_KEYSDCCH_TRAFFICTCH_CONGESTION_KEYTCH_TRAFFICBanBiDian_10CI＝6331-994217.891.204.042-99123.371.0504.53-99927.421.20.193.964-98680.740.9204.055-910750.991.2704.416-910369.661.2903.26基站傳輸閃斷增加SDCCH分配失敗次數(shù)基站傳輸閃斷在很大程度上會影響到SDCCH等信道的分配，對于閃斷嚴重，尤其是在話務(wù)頂峰閃斷嚴重的情況，該站的SDCCH擁塞率會大幅度增加。案例分析：長纓樓賓館基站閃斷嚴重1800M全天閃斷510次，900M全天閃斷300次，造成該站SDCCH和TCH擁塞嚴重，同時也影響到周圍其他基站。僅長纓樓賓館一個站的SDCCH擁塞就高達81%，SDCCH分配失敗次數(shù)增加到38268次，嚴重影響SDCCH的接通率。該站所在BSC的SDCCH擁塞率由平時的0%增加到37%，也使全網(wǎng)的SDCCH的擁塞率從原來的0.1%增長到0.95%，增加了近1個百分點。所以直接導(dǎo)致全網(wǎng)指標(biāo)的下降。site_namecell_nameSDCCH成功分配次數(shù)SDCCH分配失敗次數(shù)SDCCH擁塞SDCCH平均占用時長射頻喪失率話務(wù)量dateChangYingLouBinGuan8272333187081.5012.170.7722.523-12ChangYingLouBinGuan826352410.645.690.699.373-11SLEEPINGCELL現(xiàn)象引起SDCCH的擁塞SLEEPINGCELL是摩托羅拉公司BSS基站設(shè)備在*些版本、*些運行情況下，出現(xiàn)的一種軟件運行故障。簡要地說，SLEEPINGCELL一般定義為沒有明顯基站告警，但實際基站已經(jīng)不能為手機提供根本的通話效勞的情況，從統(tǒng)計上看基站TOTAL_CALL個數(shù)為0、SDCCH擁塞率可能較高、呼叫建立成功率可能較低。一旦出現(xiàn)這種情況，實際現(xiàn)場用戶反映會比擬強烈，很可能造成一定*圍內(nèi)的負面影響。所以應(yīng)該盡可能實時監(jiān)控網(wǎng)絡(luò)中基站的性能統(tǒng)計，盡早排除SLEEPINGCELL。由于SLEEPINGCELL很可能導(dǎo)致SDCCH擁塞率異常，所以我們應(yīng)定期根據(jù)全網(wǎng)統(tǒng)計查看SDCCH的擁塞率，如果異常增高，需要判斷改小區(qū)是否存在SLEEPINGCELL的現(xiàn)象。在每天提取的低話務(wù)量統(tǒng)計數(shù)據(jù)中，如果發(fā)現(xiàn)既無話務(wù)量又無TOTAL_CALLS的CELL，而且不是斷站又沒有嚴重的告警，這時應(yīng)立即統(tǒng)計此CELL收到的RACH數(shù)，以進一步確認該CELL是否為SLEEPINGCELL，查看該小區(qū)的統(tǒng)計項：ACCESS_PER_RACH、ALLOC_SDCCH、ALLOC_SDCCH_FAIL、ALLOC_TCH、ALLOC_TCH_FAIL、OK_ACC_PROC_SUC_RACH等，分析此時段內(nèi)該CELL收到RACH數(shù)，正確解出的RACH數(shù)，分配SDCCH、TCH的次數(shù)和分配SDCCH、TCH的失敗次數(shù)，得到統(tǒng)計數(shù)據(jù)后，假設(shè)符合以下幾種情況，則可確認為SLEEPINGCELL：收到的RACH次數(shù)為0或與前一段時間相比有非常明顯的減少；收到的RACH數(shù)較多，但無法正確解出RACH；收到的RACH數(shù)較多，也可以正確解出RACH，但無法分配SDCCH；收到的RACH數(shù)較多，也可以正確解出RACH，分配SDCCH，但無法分配TCH；確認該CELL為SLEEPINGCELL后，用MMI方式進入相應(yīng)BSS內(nèi)，鍵入chg_level進入第二層，INS該CELL中BCCH所在的DRI，一般SLEEPINGCELL的現(xiàn)象即可恢復(fù)。案例分析：由于周末BSS軟件版本升級，從第二天凌晨2點開場，BSS16的蔣家墳第一個小區(qū)出現(xiàn)與升級前表現(xiàn)不盡一樣，但后果更為嚴重的SLEEPINGCELL。該基站有成功的RACH請求幾千次，但沒有成功分配SDCCH的次數(shù)，致使CALLSETUPSUCCESSRATE為0，TOTAL-CALL為0，TCH-TRAFFIC為0〔數(shù)據(jù)如下表〕，發(fā)現(xiàn)問題后優(yōu)化人員于下午INSBCCH所在DRI，基站得到恢復(fù)，工作正常。TimeACCESS_PER_RACHALLOC_SDCCHALLOC_SDCCH_FAILALLOC_TCH9:0083518076465010:00881180810170ALLOC_TCH_FAILOK_ACC_PROC_SUC_RACHTCH_TRAFFICTOTAL_CALLS9:001989764670010:0017468101900SDCCH信道吊死導(dǎo)致基站不能正常分配與SDCCH擁塞率相關(guān)的統(tǒng)計項，其中有一項為哪一項SDCCH平均占用時長，假設(shè)*個CELL的SDCCH平均占用時長比其他CELL明顯大出很多，不合常理，則該CELL的SDCCH有可能吊死在那兒。這種情況與SLEEPINGCELL比擬類似，但稍有不同，發(fā)生SDCCH吊死的情況時，該基站還能分配一些資源供手機使用，但在分配SDCCH時成功率非常低。從基站的實時運行狀態(tài)看，該基站的絕大局部SDCCH均長期被占有，而無正常釋放。但尚存在個別SDCCH能夠被正常的呼叫建立所使用。出現(xiàn)這種情況后，應(yīng)INS該CELLBCCH所在的DRI，通常基站都可恢復(fù)正常工作。RTF與DRI的對應(yīng)關(guān)系發(fā)生紊亂由于基站軟件運行故障，在BSS1614的軟件版本中，存在軟件BUG，有基站RTF與DRI的對應(yīng)關(guān)系發(fā)生紊亂的情況，尤其是小區(qū)BCCH載頻的RTF與DRI關(guān)系不正常，主要表達為小區(qū)內(nèi)出現(xiàn)多個BCCH的RTF。出現(xiàn)這種情況時，通常該小區(qū)的SDCCH擁塞率會受影響。案例分析：以下是兆麟大廈在6月4日出現(xiàn)RTF與DRI的對應(yīng)關(guān)系發(fā)生紊亂的案例，下面是該基站的當(dāng)時狀態(tài)查詢和性能統(tǒng)計數(shù)據(jù)〔有刪減〕：MMI-RAM0217->state10dri**DEVICESTATUSINFORMATIONFORLOCATION10:DeviceStateReasondd/mmhh:mm:ssFunctionDRI000B-UNOREASON03/0615:32:13RTF020DRI010B-UNOREASON03/0610:57:19RTF010DRI020B-UNOREASON03/0610:56:18RTF000DRI030B-UNOREASON03/0610:51:06RTF000MMI-RAM0217->state10rtf**FUNCTIONSTATUSINFORMATIONFORLOCATION10:FunctionStateReasondd/mmhh:mm:ssDeviceRTF000B-ENOREASON03/0610:55:53DRI020RTF010B-ENOREASON03/0610:57:01DRI010RTF020B-ENOREASON03/0615:31:54DRI000RTF030E-ENOREASON03/0610:50:07NoneMMI-RAM0217->disp_cell_s10MCC460460460MNC000000LAC4150(1036h)4150(1036h)4150(1036h)CI55(0037h)56(0038h)57(0039h)StatusUnbarredUnbarredUnbarredFREEINUSEUNAVLFREEINUSEUNAVLFREEINUSEUNAVLSDCCH10300221002480NormTCH/F1310212028110E*tTCH/F000000000PDCHANNEL400400400下表是該小區(qū)的性能統(tǒng)計，該小區(qū)在6月3日出現(xiàn)了RTF與DRI關(guān)系紊亂的故障，從path_balance的統(tǒng)計值可以看出，出現(xiàn)故障后，該小區(qū)有問題的RTF〔即RTF00〕的path_balance異常增高，且SDCCH的擁塞次數(shù)大幅度增加。datesite_namecell_namecarrierber_meanrf_losspath_balance_mean6-1ZhaoLinDaSha460-00-4150-55RTF-00-000.330107.606-4ZhaoLinDaSha460-00-4150-55RTF-00-001.873129.67site_namecell_nameSD成功分配次數(shù)SD分配失敗次數(shù)SDCCH擁塞SDCCH平均占用時長射頻喪失率話務(wù)量dateZhaoLinDaSha460-00-4150-551387004.600.321.605-31ZhaoLinDaSha460-00-4150-55132793852.8226.287.4010.666-3ZhaoLinDaSha460-00-4150-55144115593.7332.808.8611.316-4出現(xiàn)這種情況后，一般將出現(xiàn)故障的RTF所對應(yīng)的DRI進展INS操作后，問題即可解決。手機不能正常占用SDCCH，引起手機重新申請網(wǎng)絡(luò)效勞在立即指配完成后，網(wǎng)絡(luò)會在指定的時間內(nèi)等待手機占用SDCCH信道，但是，有時會發(fā)生因為各種原因而導(dǎo)致手機不能正常地占用SDCCH的情況，并且現(xiàn)象的存在假設(shè)比擬嚴重的話，可能引起手機在屢次立即指配不成功的情況下，屢次申請網(wǎng)絡(luò)效勞，引起大量的SDCCH資源請求，從統(tǒng)計上看SDCCH擁塞率較高。一般造成這種現(xiàn)象的原因有：小區(qū)載頻硬件問題由于小區(qū)硬件問題導(dǎo)致系統(tǒng)分配完SDCCH后，手機無法占上SDCCH信道，從統(tǒng)計上看，表現(xiàn)為chan_req_ms_fail的值較高。此時，手機在收到ImmediateAssignment消息后嘗試占用SDCCH，在網(wǎng)絡(luò)參數(shù)T3101規(guī)定的時間內(nèi)手機占用SDCCH卻不成功，這樣呼叫就沒有建立起來。出現(xiàn)這種情況，很可能導(dǎo)致手機在屢次申請網(wǎng)絡(luò)效勞不成功后，繼續(xù)申請資源，從而引起不必要的SDCCH分配，可能造成SDCCH信道的擁塞。此問題一般是由于基站的*個或*幾個載頻故障導(dǎo)致：在現(xiàn)場測試時可以發(fā)現(xiàn)，當(dāng)手機被分配給固定的*個載頻的TCH時隙后，在試圖占用時總是出現(xiàn)占用不成功的現(xiàn)象；假設(shè)要從OMC統(tǒng)計上觀察，則可以通過將該小區(qū)的信道盤逐個LOCK住，觀察每個TCU在被LOCK住后，小區(qū)性能統(tǒng)計chan_req_ms_fail的統(tǒng)計值是否還很高。如果在閉掉*個TCU后，chan_req_ms_fail的值恢復(fù)正常，則可以判斷問題出在該載頻上。當(dāng)發(fā)生這種問題后，在進展故障定位的根底上，只需將該載頻更換即可。參數(shù)設(shè)置錯誤問題由于網(wǎng)絡(luò)在向手機發(fā)送ImmediateAssignment消息后，開場計時〔T3101〕，手機要在此計時器規(guī)定的時間內(nèi)接入網(wǎng)絡(luò)，假設(shè)計時器超時而手機還未成功接入，此時系統(tǒng)將觸發(fā)統(tǒng)計項chan_req_ms_fail。T3101：BSS中小區(qū)級參數(shù)；它的取值定義了系統(tǒng)從發(fā)送ImmediateAssignment消息后，等待手機建立SDCCH連接的時間。這個參數(shù)的大小要綜合考慮手機占上SDCCH平均所需的時間和基站SDCCH信道擁塞情況。取值過大可能造成基站資源浪費，取值過小將可能引起大量手機不能正常占上SDCCH的現(xiàn)象。現(xiàn)在移動全網(wǎng)大局部基站的此參數(shù)取值為1500〔1.5秒〕。存在頻率干擾的問題如果基站存在嚴重的系統(tǒng)內(nèi)部或系統(tǒng)外部的干擾時，手機在進展SDCCH的接續(xù)時，可能由于存在頻率的干擾而收不到系統(tǒng)發(fā)來的ImmediateAssignment消息，或者收到該消息后，在接入系統(tǒng)的時候由于干擾，網(wǎng)絡(luò)無法正確解出手機發(fā)來的ImmediateAssignment消息，從而最終造成手機無法占用系統(tǒng)為其所分配的SDCCH資源。這樣，在一定程度上會引起手機屢次申請網(wǎng)絡(luò)效勞，造成系統(tǒng)資源的擁塞。要解決干擾問題，首先要判斷干擾來自本系統(tǒng)內(nèi)，還是系統(tǒng)外的干擾。這可以通過OMC統(tǒng)計觀察該站的空閑情況下的干擾統(tǒng)計IOI，如果24小時均很高，則干擾很可能來自系統(tǒng)外；如果IOI只是隨著網(wǎng)絡(luò)的話務(wù)量增長而增值，則問題很可能來自系統(tǒng)內(nèi)的頻率規(guī)劃。對于系統(tǒng)外的干擾，要具體查找干擾源，一般是電臺、電力設(shè)備、非法直放站等所造成；對于系統(tǒng)內(nèi)的干擾，則要檢查該站的頻率規(guī)劃是否存在問題。由于基站異常原因?qū)е掠脩纛l繁重新申請網(wǎng)絡(luò)資源當(dāng)基站存在比擬明顯的單通或無聲時，手機用戶在打時假設(shè)感覺到?jīng)]有聲音，在最初發(fā)現(xiàn)時，用戶一般會再撥打幾次才會放棄嘗試。當(dāng)用戶話務(wù)量相比照擬集中時，假設(shè)遇到這種基站單通或無聲的問題，則很容易發(fā)生大量用戶頻繁申請網(wǎng)絡(luò)效勞的現(xiàn)象，基站的SDCCH擁塞率指標(biāo)會比基站工作正常時有所提高。MSC側(cè)等有線局部原因造成基站SDCCH信道擁塞SDCCH擁塞率較高，通常是由于無線局部的原因造成的。但是，在*些特殊情況下，由于MSC的資源狀態(tài)設(shè)置或參數(shù)設(shè)置等不正確，也會造成無線局部的SDCCH信道擁塞。這種情況一般發(fā)生在基站割接、新BSC或新站入網(wǎng)的時候，此時出現(xiàn)異常的SDCCH擁塞，則需要關(guān)注MSC或A接口的設(shè)置。MSC上基站參數(shù)設(shè)置不正確，造成基站SDCCH信道擁塞在網(wǎng)絡(luò)割接調(diào)整時，可能發(fā)生小區(qū)的LAC在割接后有了變化，但是在MSC中卻未更改，造成用戶手機有信號，但無法通話；從統(tǒng)計上看，SDCCH擁塞率很高。具表達象：撥打測試中發(fā)現(xiàn)測試小區(qū)有信號，但無法做主叫，被叫，不能正常切換，從OMC上觀測該小區(qū)狀態(tài)可發(fā)現(xiàn)該小區(qū)長時間只有SDCCH分配，沒有TCH分配〔如圖一所示〕。圖一：MMI-RAM0213->disp_cell_st1StartofreportforLOCATION1:GSMCELLIDMCC460460460MNC000000LAC4144(1030h)4144(1030h)4144(1030h)CI3121(0C31h)3122(0C32h)3123(0C33h)RAC139(008Bh)139(008Bh)139(008Bh)FrequencyTypePGSMPGSMPGSMBCCHFrequency263237StatusUnbarredUnbarredUnbarredFREEINUSEUNAVLFREEINUSEUNAVLFREEINUSEUNAVLSDCCH364022201510NormTCH/F300042004300E*tTCH/F000000000PDCHANNEL200200200EndofReport.從統(tǒng)計看，則表現(xiàn)為該小區(qū)的total_calls為0。產(chǎn)生原因：通常在割接時由于基站LAC重新分配，但其他數(shù)據(jù)沒有變動，只是LAC更改，但MSC卻沒有及時修改MSC上的基站數(shù)據(jù)，從而造成MSC數(shù)據(jù)與BSC數(shù)據(jù)不一致。解決方法：核查MSC中該小區(qū)數(shù)據(jù)，將錯誤LAC更正后即可。MSC上未及時在基站開通后做該站的數(shù)據(jù)造成基站SD擁塞這種情況表現(xiàn)出來的現(xiàn)象以及處理方法與1〕類似。MSC上基站操作維護狀態(tài)設(shè)置不正確，造成基站SD信道擁塞在網(wǎng)絡(luò)基站割接時，可能由于工作疏忽，會出現(xiàn)有個別的小區(qū)在MSC上的操作維護狀態(tài)為LOCK，造成無線側(cè)表現(xiàn)為用戶手機有信號，但無法通話；從統(tǒng)計上看SDCCH擁塞率會很高。具表達象：現(xiàn)場撥打測試中發(fā)現(xiàn)被測試小區(qū)有足夠可以通信的信號，卻無法做主叫和被叫；但是可以進展局部切換〔即切換過程中不需要MSC參與的切換在這種情況下可以進展〕。在OMC上觀測該小區(qū)統(tǒng)計可發(fā)現(xiàn)SDCCH占用很多，但TCH占用較少，甚至沒有占用。如果在OMC上對該小區(qū)進展call_trace則可發(fā)現(xiàn)trace到的call均為切換的情況，沒有主叫和被叫的call。另外，從統(tǒng)計指標(biāo)上看，該小區(qū)的total_calls為0，即沒有MOC和MTC。解決方法：核查MSC中該小區(qū)數(shù)據(jù)，查看該小區(qū)在MSC中的狀態(tài)是否為LOCK或者查看在相應(yīng)的MSC中是否有該小區(qū)的正確數(shù)據(jù)。如果狀態(tài)為LOCK則UNLOCK即可，如果無此小區(qū)數(shù)據(jù)，則參加該小區(qū)數(shù)據(jù)即可。MSC側(cè)CIC被異常BAR住，造成基站SD信道擁塞具表達象：撥打測試發(fā)現(xiàn)測試小區(qū)有信號，但無法主、被叫，也無法進展切換。從OMC觀察小區(qū)狀態(tài)發(fā)現(xiàn)該小區(qū)只有SDCCH分配，無TCH分配，具表達象如圖一所示。在OMC上對該小區(qū)做Call_trace發(fā)現(xiàn)手機的呼叫沒有得到CIC電路的分配，信令流程在SETUP消息后，立刻從網(wǎng)絡(luò)側(cè)發(fā)送Disconnect[即：Disconnect(network->MS)：Cause-Resourceunavailable；Requestedcircuit/channelnotavailable.]，具體log見下面〔正常情況和非正常情況的比照，中間局部信令流程省略〕。從統(tǒng)計看，該BSC中所有小區(qū)TCH分配次數(shù)為0，total_calls為0。產(chǎn)生原因：通常是由于一個新的BSC初次投入使用時，由于沒有及時將所帶的CIC電路翻開，而造成在該BSC下的基站開通后，CIC電路仍被BAR的情況。解決方法：在MSC中將該BSC的CIC電路設(shè)為工作狀態(tài)即可。資源分配異常的接續(xù)情況：___________________________________________________________________________TIMESTAMP:30/10/200101:48:52.210CALLDURATION00:00:00.000LAC:04182CI:00678CARRIER31MESSAGE:BSSMAP:pletelayer3information(BSS->MSC).Cell-LAC:04182CI:00678(RR:Pagingresponse(MS->network).)___________________________________________________________________________TIMESTAMP:30/10/200101:48:52.245CALLDURATION00:00:00.035LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Setup(network->MS)Speech.Circuitmode.___________________________________________________________________________TIMESTAMP:30/10/200101:48:52.905CALLDURATION00:00:00.695LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Callconfirmed(MS->network):Causenotavailable.___________________________________________________________________________TIMESTAMP:30/10/200101:48:52.930CALLDURATION00:00:00.720LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Disconnect(network->MS):Cause-Resourceunavailable;Requestedcircuit/channelnotavailable.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.615CALLDURATION00:00:01.405LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Release(MS->network):Cause-Normalevent;Normalcallclearing.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.630CALLDURATION00:00:01.420LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Releaseplete(network->MS):Causenotavailable.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.635CALLDURATION00:00:01.425LAC:04182CI:00678CARRIER31MESSAGE:BSSMAP:Clearmand(MSC->BSS)Cause-Normalevent;Callcontrol.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.695CALLDURATION00:00:01.485LAC:04182CI:00678CARRIER31MESSAGE:RR:Channelrelease(network->MS):RRCause-Normalevent.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.710CALLDURATION00:00:01.500LAC:04182CI:00678CARRIER31MESSAGE:ABIS:DeactivateSACCH(BSC->BTS):Timeslot:1Channel:SDCCH/8+ACCH___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.720CALLDURATION00:00:01.510LAC:04182CI:00678CARRIER31MESSAGE:BSSMAP:Clearplete(BSS->MSC).正常的接續(xù)過程：___________________________________________________________________________TIMESTAMP:25/10/200115:19:13.725CALLDURATION00:00:00.000LAC:04124CI:00786CARRIERHoppingMESSAGE:BSSMAP:pletelayer3information(BSS->MSC).Cell-LAC:04124CI:00786(RR:Pagingresponse(MS->network).)___________________________________________________________________________TIMESTAMP:25/10/200115:19:13.755CALLDURATION00:00:00.030LAC:04124CI:00786CARRIERHoppingMESSAGE:DTAP:Setup(network->MS)Speech.Circuitmode.NumberofCaller-Type:National.Number:___________________________________________________________________________TIMESTAMP:25/10/200115:19:13.900CALLDURATION00:00:00.175LAC:04124CI:00786CARRIERHoppingMESSAGE:BSSMAP:Classmarkupdate.___________________________________________________________________________TIMESTAMP:25/10/200115:19:13.925CALLDURATION00:00:00.200LAC:04124CI:00786CARRIERHoppingMESSAGE:RR:Classmarkchange(MS->network).___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.360CALLDURATION00:00:00.635LAC:04124CI:00786CARRIERHoppingMESSAGE:DTAP:Callconfirmed(MS->network):Causenotavailable.___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.385CALLDURATION00:00:00.660LAC:04124CI:00786CARRIERHoppingMESSAGE:BSSMAP:Assignmentrequest(MSC->BSS)CIC=859___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.445CALLDURATION00:00:00.720LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Physicalconte*trequest(BSC->BTS):Timeslot:3Channel:SDCCH/8+ACCH___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.460CALLDURATION00:00:00.735LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Physicalconte*tconfirm(BTS->BSC):Timeslot:3Channel:SDCCH/8+ACCHBSPowerPn-4MSPower-10(33dBmforGSM900,20dBmforDCS1800)TimingAdvance:3___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.490CALLDURATION00:00:00.765LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Channelactivation(BSC->BTS):Timeslot:0Channel:Bm+ACCH'sIntra-cellchannelchange(Normalassignment)UplinkDT*isnotapplied.DownlinkDT*isnotapplied.Speech.HalfrateTCHchannelLmGSMspeechcodingalgorithmversion1BSPowerPn-4MSPower-10(33dBmforGSM900,20dBmforDCS1800)TimingAdvance:3___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.525CALLDURATION00:00:00.800LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Channelactivationacknowledge(BSC->BTS):Timeslot:0Channel:Bm+ACCH'sFrameNumber:9813___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.555CALLDURATION00:00:00.830LAC:04124CI:00786CARRIERHoppingMESSAGE:RR:Assignmentmand(network->MS)Carrier:HoppingTimeslot0TypeTCH/F+FACCH/FandSACCH/F___________________________________________________________________________TIMESTAMP:25/10/200115:19:15.080CALLDURATION00:00:01.355LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Establishindication(BTS->BSC):Timeslot:0Channel:Bm+ACCH'sSAPI:0Channeltype:FACCHorSDCCH___________________________________________________________________________TIMESTAMP:25/10/200115:19:15.210CALLDURATION00:00:01.485LAC:04124CI:00786CARRIERHoppingMESSAGE:RR:Assignmentplete(MS->network):RR